Re: [BUG] "fatal: bad object .alternate" during fetch with alternates

[Jeff King <peff@peff.net>]

On Wed, Nov 06, 2019 at 08:48:05PM +0100, Johannes Schindelin wrote:

> Now, I think the two factors that trigger this bug over here are:
> 
> - I had all the objects locally already, as I had pushed from a topic
>   branch to `master` [*1*].
> 
> - My worktree's `.git/objects` is connected to an alternate that is
>   connected to the current Git repository (yes, it is circular, long
>   story...) and has refs pointing to commits its alternate that have
>   been gc'ed away.

I think this second one is the crux of the issue. Your alternate is a
corrupt repository, and I don't think that's something we ought to be
worried about supporting in general.

That said, those alternate objects should be used as UNINTERESTING
traversal tips. And rev-list usually tries to avoid bailing out for
missing UNINTERESTING objects. I suspect it's less aggressive about
doing so for the actual tips (because usually for_each_ref()'s internal
logic would skip broken refs entirely).

> So I see two problems with this error message:
> 
> - It is not helpful. It should not say `.alternate`, it should mention
>   the ref itself, and ideally even the path of the alternate.

It doesn't know the refname. The data transfer between the alternate and
the borrowing repo was tightened to just pass over object names. We
could probably pass the alternate path, though.

> - Shouldn't the code be made smart enough to simply ignore (maybe with a
>   warning) refs that point to gc'ed commits?

I'll take a look at the rev-list thing I mentioned above.

-Peff