Re: "Cannot fetch git.git" (worktrees at fault? or origin/HEAD) ?

From: Jeff King <peff@peff.net>
Date: Oct 20, 2017, 03:16 UTC
Message-ID: <20171020031630.44zvzh3d2vlhglv4@sigill.intra.peff.net>
In-Reply-To: <CAGZ79kYP0z1G_H3nwfmSHraWHMBOcik5LepUXKj0nveeBrihiw@mail.gmail.com>

On Thu, Oct 19, 2017 at 06:43:57PM -0700, Stefan Beller wrote:

Show 8 quoted lines

> So I ran "git fetch --all" inside git.git that you are all familiar with.
> All fetches failed with a similar error as:
> Fetching kernelorg
> fatal: bad object HEAD
> error: https://kernel.googlesource.com/pub/scm/git/git did not send
> all necessary objects
> 
> error: Could not fetch kernelorg

I ran into this a while back with worktrees, too. In my case I had a worktree which was "owned" by multiple repositories[1]. One would write the HEAD, but the other did not necessarily have those objects.

I don't quite recall how I ended up there. Doing "git worktree add" multiple times does seem to complain about the directory already existing. My case did involve relative symlinks in both repositories, so maybe that confused things. Anyway, I can't seem to replicate it now.

Show 14 quoted lines

> And here we go, I do use worktrees nowadays!
> $ git worktree list
> /usr/local/google/home/sbeller/OSS/git                   117ddefdb4
> (detached HEAD)
> /u/git                                                   d0c39a49cc
> (detached HEAD)
> /usr/local/google/home/sbeller/OSS/git_origin_master     b14f27f917
> (detached HEAD)
> /usr/local/google/home/sbeller/OSS/submodule_remote_dot  3d9025bd69
> (detached HEAD)
> 
> $ git show 3d9025bd69
> fatal: ambiguous argument '3d9025bd69': unknown revision or path not
> in the working tree.

So maybe you've ended up in the same situation and somehow "reused" submodule_remote_dot.

But I think until that commit you mentioned (d0c39a49cc), "gc" in the parent repo could drop objects accessible only from the worktree. So if that happened _before_ d0c39a49cc, then at that point your worktree was corrupted. And now of course further operations will complain.

Show 8 quoted lines

> ok, so I presume I just delete that working tree to "fix my copy of git"
> sbeller@sbeller:/u/git$ rm -rf
> /usr/local/google/home/sbeller/OSS/submodule_remote_dot
> sbeller@sbeller:/u/git$ git worktree prune
> sbeller@sbeller:/u/git$ git worktree list
> /usr/local/google/home/sbeller/OSS/git                117ddefdb4 (detached HEAD)
> /u/git                                                d0c39a49cc (detached HEAD)
> /usr/local/google/home/sbeller/OSS/git_origin_master  b14f27f917 (detached HEAD)

So that's the right immediate workaround (and hoping there was nothing valuable in that worktree!).

> Any idea which direction we need to heading for a real fix?

If my analysis above is correct, then it's already fixed. You just had leftover corruption.

-Peff