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

From: Jeff King <peff@peff.net>
Date: Aug 5, 2025, 13:44 UTC
Message-ID: <20250805134454.GA1340331@coredump.intra.peff.net>
In-Reply-To: <aJIBlIDto33lJEuK@pks.im>

On Tue, Aug 05, 2025 at 03:05:24PM +0200, Patrick Steinhardt wrote:

Show 13 quoted lines

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

Yes, I think it's pretty unlikely on the client, where almost all of your ref updates are either via HEAD (because you're committing), or to remote tracking branches via fetch (and we never point HEAD there).

The more likely case is a server where one user is pushing and another updates HEAD (to set the default branch for clones, etc). But those sorts of updates to HEAD are going to be rather rare there, as well.

So I agree it's not that likely to come up much in practice.

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

I'm OK with that.

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

Yep, sounds good.

-Peff