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

[Patrick Steinhardt <ps@pks.im>]

On Mon, Aug 04, 2025 at 05:34:22PM -0700, Junio C Hamano wrote:
> 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