[BUG(s)?] dangling symref breaks filter-branch

[BUG(s)?] dangling symref breaks filter-branch

[Christian Jaeger]

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

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

$ 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.

Issue two (maybe not an issue) is why git filter-branch thought it should look at refs/remotes/origin/HEAD at all--I didn't tell it to, after all (right? I've spent time going through my config because I thought it would be taking this idea from there somehow, but couldn't see anything obvious).

(Issue three, maybe, why fsck didn't report any problem.)

Christian.
Note: I'm not subscribed to the ml currently.

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

Re: [BUG(s)?] dangling symref breaks filter-branch

[Björn Steinbrink]

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