* Re: [BUG(s)?] dangling symref breaks filter-branch
2009-07-18 2:11 [BUG(s)?] dangling symref breaks filter-branch Christian Jaeger
@ 2009-07-18 5:28 ` Björn Steinbrink
0 siblings, 0 replies; 2+ messages in thread
From: Björn Steinbrink @ 2009-07-18 5:28 UTC (permalink / raw)
To: Christian Jaeger; +Cc: git
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
^ permalink raw reply related [flat|nested] 2+ messages in thread