On Thu, Nov 12 2020, Taylor Blau wrote:
> Hi Caspar,
>
> On Mon, Nov 02, 2020 at 08:12:07PM +0100, herr.kaste wrote:
>> A
>>
>> $ git commit-graph write
>>
>> did the trick.
>>
>> Let me know if you think there could be something useful to reproduce,
>> somewhere.
>
> I think this is worth trying to reproduce. The first message you're
> seeing about the commit-graph-chain.lock already existing is a
> red-herring: it's likely that the last time you tried to generate a
> commit-graph, that it hit that same BUG() and left the stale lock laying
> around. (I can't remember off the top of my head whether we still run
> the atexit handlers upon a BUG(), but even still, I could believe that
> some other stray process left it laying around, too).
>
> So, what's interesting is why your commit graph ended up in a state that
> it got some commit without all of its parents. If you could reproduce
> that state, that would be interesting.
No matter how it got to that point we shouldn't be dying on a "git pull"
just because the commit-graph code had a hickup. I thought I'd addressed
this in 43d3561805 ("commit-graph write: don't die if the existing graph
is corrupt", 2019-03-25) and related commits, but I see that's not the
case.
That code really needs to learn how to operate in two different
modes. One in the write/verify codepath where we're the primary command
being called, and one where we're just being called on
fetch/pull/status/whatever when we shouldn't hard die just because we
can't access the commit-graph side data.
