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