+Jeff King On 13 November 2017 at 22:15, Stefan Beller <sbel...@google.com> wrote: > On Mon, Nov 13, 2017 at 2:03 PM, Luke Diamand <l...@diamand.org> wrote: >> On 13 November 2017 at 19:51, Luke Diamand <l...@diamand.org> wrote: >>> Hi! >>> >>> I think there may be a regression caused by this change which means >>> that "git fetch origin" doesn't work: >>> >>> commit d0c39a49ccb5dfe7feba4325c3374d99ab123c59 (refs/bisect/bad) >>> Author: Nguyễn Thái Ngọc Duy <pclo...@gmail.com> >>> Date: Wed Aug 23 19:36:59 2017 +0700 >>> >>> revision.c: --all adds HEAD from all worktrees >>> >>> $ git fetch origin >>> fatal: bad object HEAD >>> error: ssh://my_remote_host/reponame did not send all necessary objects >>> >>> I used git bisect to find the problem, and it seems pretty consistent. >>> "git fetch" with the previous revision works fine. >>> >>> FWIW, I've got a lot of git worktrees associated with this repo, so >>> that may be why it's failing. The remote repo is actually a git-p4 >>> clone, so HEAD there actually ends up pointing at >>> refs/remote/p4/master. >>> >>> Thanks, >>> Luke >> >> Quite a few of the worktrees have expired - their head revision has >> been GC'd and no longer points to anything sensible >> (gc.worktreePruneExpire). The function other_head_refs() in worktree.c >> bails out if there's an error, which I think is the problem. I wonder >> if it should instead just report something and then keep going. > > Also see > https://public-inbox.org/git/cagz79kyp0z1g_h3nwfmshrawhmbocik5lepuxkj0nveebri...@mail.gmail.com/
So is this a bug or user error on my part? Surely at the very least "git fetch" shouldn't give a cryptic error message just because one of my git worktrees has expired!
