{"thread":{"id":"20150","subject":"[BUG(s)?] dangling symref breaks filter-branch","startedAt":"2009-07-18T02:11:44Z","lastAt":"2009-07-18T05:28:31Z","messageCount":2,"participants":["Christian Jaeger","Björn Steinbrink"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"118216","messageId":"20090718021144.162050@gmx.net","threadId":"20150","inReplyTo":null,"subject":"[BUG(s)?] dangling symref breaks filter-branch","fromName":"Christian Jaeger","fromEmail":"pflanze@gmx.ch","sentAt":"2009-07-18T02:11:44Z","receivedAt":"2009-07-18T02:11:44Z","isPatch":false,"sender":{"key":"pflanze@gmx.ch","avatar":null},"body":"Hello\n\n$ git branch -a\n  master\n* stablepatches\n  work\n  remotes/origin/origin/master\n  remotes/origin/stablepatches\n  remotes/origin/work\n\n$ git filter-branch --env-filter '..somecode..'\nfatal: missing object 0000000000000000000000000000000000000000 for refs/remotes/origin/HEAD\n\nSame thing happened with whatever additional argument (rev-list) I would give to git filter-branch.\n\nWhen I cloned this repo and run the filter-branch in the clone, it worked.\n\ngit fsck --all on the faulty repo reported nothing but a couple dangling objects.\n\nI used git version 1.6.3.3 and then 1.6.4.rc1 (same problem). Further digging has revealed:\n\n$ cat .git/refs/remotes/origin/HEAD\nref: refs/remotes/origin/master\n$ cat .git/refs/remotes/origin/master\ncat: .git/refs/remotes/origin/master: No such file or directory\n\n$ git rev-parse refs/remotes/origin/HEAD\nsaid \"dangling symref refs/remotes/origin/HEAD.\"\n\n$ rm .git/refs/remotes/origin/HEAD\nhas made filter-branch work again.\n\n\nSo, 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.\n\nIssue 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).\n\n(Issue three, maybe, why fsck didn't report any problem.)\n\nChristian.\nNote: I'm not subscribed to the ml currently.\n\n-- \nJetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 -\nsicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser\n"},{"id":"118219","messageId":"20090718052831.GA11825@atjola.homenet","threadId":"20150","inReplyTo":"20090718021144.162050@gmx.net","subject":"Re: [BUG(s)?] dangling symref breaks filter-branch","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-07-18T05:28:31Z","receivedAt":"2009-07-18T05:28:31Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.07.18 04:11:44 +0200, Christian Jaeger wrote:\n> Hello\n> \n> $ git branch -a\n>   master\n> * stablepatches\n>   work\n>   remotes/origin/origin/master\n>   remotes/origin/stablepatches\n>   remotes/origin/work\n> \n> $ git filter-branch --env-filter '..somecode..'\n> fatal: missing object 0000000000000000000000000000000000000000 for refs/remotes/origin/HEAD\n\nThis comes from the for-each-ref call that checks whether the backup\nnamespace is empty. This is probably be fixed like this:\n\n\ndiff --git a/git-filter-branch.sh b/git-filter-branch.sh\nindex 37e044d..7809db4 100755\n--- a/git-filter-branch.sh\n+++ b/git-filter-branch.sh\n@@ -227,7 +227,7 @@ GIT_WORK_TREE=.\n export GIT_DIR GIT_WORK_TREE\n \n # Make sure refs/original is empty\n-git for-each-ref > \"$tempdir\"/backup-refs || exit\n+git for-each-ref $orig_namespace > \"$tempdir\"/backup-refs || exit\n while read sha1 type name\n do\n \tcase \"$force,$name\" in\n\nBut I'm not sure if this is wanted, and this also breaks test\nt7003-filter-branch.sh, because test 6 relies on the fact that all refs\nare listed. While this looks like a wrong assumption in the test to me,\nI have no idea how to fix the test. :-(\n\n> Same thing happened with whatever additional argument (rev-list) I\n> would give to git filter-branch.\n> \n> When I cloned this repo and run the filter-branch in the clone, it\n> worked.\n> \n> git fsck --all on the faulty repo reported nothing but a couple\n> dangling objects.\n> \n> I used git version 1.6.3.3 and then 1.6.4.rc1 (same problem). Further\n> digging has revealed:\n> \n> $ cat .git/refs/remotes/origin/HEAD\n> ref: refs/remotes/origin/master\n> $ cat .git/refs/remotes/origin/master\n> cat: .git/refs/remotes/origin/master: No such file or directory\n\nThe second \"cat\" doesn't tell much, the ref might be stored in\n.git/packed-refs. (Though it didn't exist at all in this case, as can be\nseen from the \"git branch -a\" output above).\n\n> $ git rev-parse refs/remotes/origin/HEAD\n> said \"dangling symref refs/remotes/origin/HEAD.\"\n> \n> $ rm .git/refs/remotes/origin/HEAD\n> has made filter-branch work again.\n> \n> \n> So, issue one I'm wondering about: how comes I had this dangling\n> symbolic ref? If it makes git tools break, shouldn't those refs be\n> updated in a safe way (so that interruption can't leave those behind),\n> or maybe should the tools be fixed for not handling them correctly.\n\nThe symref was most likely created by \"git clone\". It references the\nremote tracking branch for the remote's branch that was referenced by\nthe remote's HEAD at the time of the clone. Its purpose is to serve as a\nshortcut for the remote's \"primary\" branch. Instead of origin/HEAD, you\ncan just write \"origin\", so you can do \"git log origin..\" instead of,\nfor example, \"git log origin/master..\".\n\nAs we reconstructed on IRC, you cloned the repo while it still had a\nbranch head called \"master\", and that was the primary branch. So\norigin/HEAD was created as a symref to origin/master. In the meantime,\nthe \"origin\" repo got changed and the \"master\" branch head was deleted.\nA call to \"git remote prune\" then killed \"origin/master\" locally and the\nsymref got broken.\n\nRegarding your \"rm .git/refs/remotes/origin/HEAD\" fix, this can nowadays\nbe done using \"git remote set-head\". That command can create, updated or\ndelete the <remote>/HEAD symrefs, without requiring the user to use\nplumbing (git symbolic-ref) or knowing about how and where the refs are\nstored within .git.\n\nHTH\nBjörn\n"}]}