Re: What's cooking in git.git (Aug 2025, #01; Sun, 3)

From: Patrick Steinhardt <ps@pks.im>
Date: Aug 5, 2025, 13:05 UTC
Message-ID: <aJIBlIDto33lJEuK@pks.im>
In-Reply-To: <xmqqectq4ne9.fsf@gitster.g>

On Mon, Aug 04, 2025 at 05:34:22PM -0700, Junio C Hamano wrote:

Show 19 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > I just left a rather lengthy review of the split-HEAD patch in v4. I
> > think hit has a few bugs that we need to address.
> >
> > I'm not sure if the right answer is to just go back to the v3 version
> > that simply rejected the racy HEAD update (since that's more or less
> > what happens now and nobody complains).
> >
> > If we do want to stick with the "silently skip the racy HEAD update"
> > strategy from v4, I left some fixes there. But I'd worry more about
> > maintainability and regressions in the future. I'm not sure if my hacky
> > "pretend the HEAD is this for splitting" patch is something we'd want to
> > carry or not. But if so, I think we could at least get a little coverage
> > in the test suite.
> 
> Between the "honestry admit we failed and reject" and "silently
> pretend nothing bad happened", I'd have to say that the former may
> be more preferrable, and I hope people would agree.

I am a bit torn overall. We _are_ talking about a race, even though it is an implicit race because the user didn't explicitly ask for the ref to be updated. So aborting the transaction is reasonable from my perspective. But as Peff noted the user didn't ask for it explicitly, so it may be surprising if we abort due to a concurrent update of HEAD.

Ultimately I'd claim that no end user will ever see this happen in practice. You'd have to change HEAD at the same point in time as you write a new commit directly to the branch that it's pointing to. That is, git-commit(1) wouldn't even be able to trigger this case as that command commits to HEAD, not to its target. And just to confirm my claim: setting a breakpoint in `split_head_update()` and then executing "git commit" doesn't trigger that function.

So with that knowledge I'd rather do the safe thing and abort the transaction. It requires less hard-to-test logic and feels safer overall.

If we agree on that I can send a final reroll that reverts back to the logic we had in v3, which did abort the transaction.

Patrick