On Thu, Oct 19, 2017 at 06:43:57PM -0700, Stefan Beller wrote: > 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. > 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. > 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
