From: Jeff King <peff@peff•net>
To: Patrick Steinhardt <ps@pks•im>
Cc: Junio C Hamano <gitster@pobox•com>, git@vger•kernel.org
Subject: Re: What's cooking in git.git (Aug 2025, #01; Sun, 3)
Date: Tue, 5 Aug 2025 09:44:54 -0400 [thread overview]
Message-ID: <20250805134454.GA1340331@coredump.intra.peff.net> (raw)
In-Reply-To: <aJIBlIDto33lJEuK@pks.im>
On Tue, Aug 05, 2025 at 03:05:24PM +0200, Patrick Steinhardt wrote:
> 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
next prev parent reply other threads:[~2025-08-05 13:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-04 8:23 What's cooking in git.git (Aug 2025, #01; Sun, 3) Junio C Hamano
2025-08-04 9:47 ` Patrick Steinhardt
2025-08-04 14:29 ` Junio C Hamano
2025-08-04 14:51 ` Patrick Steinhardt
2025-08-04 15:41 ` Jeff King
2025-08-05 0:34 ` Junio C Hamano
2025-08-05 12:51 ` Jeff King
2025-08-05 17:08 ` Junio C Hamano
2025-08-05 18:48 ` Jeff King
2025-08-05 13:05 ` Patrick Steinhardt
2025-08-05 13:44 ` Jeff King [this message]
2025-08-05 17:10 ` Junio C Hamano
2025-08-05 1:22 ` D. Ben Knoble
2025-08-05 10:24 ` Junio C Hamano
2025-08-05 16:23 ` D. Ben Knoble
2025-08-05 16:30 ` D. Ben Knoble
2025-08-05 19:06 ` Junio C Hamano
2025-08-05 19:18 ` Ben Knoble
2025-08-06 17:28 ` Lucas Seiki Oshiro
2025-08-06 18:34 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250805134454.GA1340331@coredump.intra.peff.net \
--to=peff@peff$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox