On 2009.07.18 04:11:44 +0200, Christian Jaeger wrote: > Hello > > $ git branch -a > master > * stablepatches > work > remotes/origin/origin/master > remotes/origin/stablepatches > remotes/origin/work > > $ git filter-branch --env-filter '..somecode..' > fatal: missing object 0000000000000000000000000000000000000000 for refs/remotes/origin/HEAD This comes from the for-each-ref call that checks whether the backup namespace is empty. This is probably be fixed like this: diff --git a/git-filter-branch.sh b/git-filter-branch.sh index 37e044d..7809db4 100755 --- a/git-filter-branch.sh +++ b/git-filter-branch.sh @@ -227,7 +227,7 @@ GIT_WORK_TREE=. export GIT_DIR GIT_WORK_TREE # Make sure refs/original is empty -git for-each-ref > "$tempdir"/backup-refs || exit +git for-each-ref $orig_namespace > "$tempdir"/backup-refs || exit while read sha1 type name do case "$force,$name" in But I'm not sure if this is wanted, and this also breaks test t7003-filter-branch.sh, because test 6 relies on the fact that all refs are listed. While this looks like a wrong assumption in the test to me, I have no idea how to fix the test. :-( > Same thing happened with whatever additional argument (rev-list) I > would give to git filter-branch. > > When I cloned this repo and run the filter-branch in the clone, it > worked. > > git fsck --all on the faulty repo reported nothing but a couple > dangling objects. > > I used git version 1.6.3.3 and then 1.6.4.rc1 (same problem). Further > digging has revealed: > > $ cat .git/refs/remotes/origin/HEAD > ref: refs/remotes/origin/master > $ cat .git/refs/remotes/origin/master > cat: .git/refs/remotes/origin/master: No such file or directory The second "cat" doesn't tell much, the ref might be stored in .git/packed-refs. (Though it didn't exist at all in this case, as can be seen from the "git branch -a" output above). > $ git rev-parse refs/remotes/origin/HEAD > said "dangling symref refs/remotes/origin/HEAD." > > $ rm .git/refs/remotes/origin/HEAD > has made filter-branch work again. > > > So, issue one I'm wondering about: how comes I had this dangling > symbolic ref? If it makes git tools break, shouldn't those refs be > updated in a safe way (so that interruption can't leave those behind), > or maybe should the tools be fixed for not handling them correctly. The symref was most likely created by "git clone". It references the remote tracking branch for the remote's branch that was referenced by the remote's HEAD at the time of the clone. Its purpose is to serve as a shortcut for the remote's "primary" branch. Instead of origin/HEAD, you can just write "origin", so you can do "git log origin.." instead of, for example, "git log origin/master..". As we reconstructed on IRC, you cloned the repo while it still had a branch head called "master", and that was the primary branch. So origin/HEAD was created as a symref to origin/master. In the meantime, the "origin" repo got changed and the "master" branch head was deleted. A call to "git remote prune" then killed "origin/master" locally and the symref got broken. Regarding your "rm .git/refs/remotes/origin/HEAD" fix, this can nowadays be done using "git remote set-head". That command can create, updated or delete the <remote>/HEAD symrefs, without requiring the user to use plumbing (git symbolic-ref) or knowing about how and where the refs are stored within .git. HTH Björn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html