Re: BUG: commit-graph.c:1068 when doing `git pull`

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Nov 12, 2020, 16:27 UTC
Message-ID: <871rgyh76x.fsf@evledraar.gmail.com>
In-Reply-To: <X61J7bWDXO/r7Ob5@nand.local>

On Thu, Nov 12 2020, Taylor Blau wrote:

Show 23 quoted lines

> 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.