Subject: Re: [PATCH v2 0/1] replay: make atomic ref updates the default behavior

From: Siddharth Asthana <[email-masked]>
Date: Thu, 9 Oct 2025 02:48:46 +0530

On 09/10/25 02:26, Elijah Newren wrote:
> On Wed, Oct 8, 2025 at 1:02 PM Siddharth Asthana
> <[email-masked]> wrote:
>> On 04/10/25 00:35, Kristoffer Haugsbakk wrote:
>>> Good evening Siddharth
>>>
> [...]
>>> I have been using git-rebase(1) for a while with a post-rewrite script.
>>> This is used for interactive rebases but also just keeping up with
>>> upstream, i.e. a regular rebase.  Then I was idly thinking that
>>> git-replay(1) would be faster for the plain rebase case—but it doesn’t
>>> support that hook directly.  Okay, but I can get around that: I can
>>> parse the output, yank the commit OIDs, and run git-rev-list(1) on both
>>> of them to get the mapping I want.  But it would be really nice to just
>>> declare the correct post-rewrite format and be done, without having to
>>> parse anything. :)
>>
>> Ah, that's a concrete use case! You are using post-rewrite hooks with
>> rebase and want git replay to support that workflow without needing to
>> parse output.
>>
>> That makes sense for the client-side evolution of the command. Right now
>> the focus is server-side where hooks aren't typically needed, but as this
>> moves toward replacing interactive rebase, proper hook support (including
>> post-rewrite) will be essential.
>>
>> I think --format with atoms would work well for that - you could get
>> exactly the format post-rewrite expects without parsing. For now I'll keep
>> the simple update-ref format, but this is good motivation for adding
>> --format support when we tackle the client-side features.
>>
>> Thanks for the concrete example!
> Let's be *very* careful before we add any hooks to replay.
> pre-rebase, for example, forced the assumption of only one ref being
> involved.  The early implementation of rebase as a shell script on top
> of other commands forced assumptions that it played with pre-commit,
> post-commit, and post-checkout, and forces us today to continue to
> check out every intermediate commit to the working copy even when the
> rebase could otherwise be done entirely in-memory without touching the
> index or working copy.  post-rewrite seems more sane than most other
> hooks, but I still want to avoid painting ourselves into a corner, and
> hooks are very much about defined and established APIs through which
> we communicate to other processes, which means it's exactly the kind
> of thing that could paint us into a corner.  We'll probably want that
> kind of extensibility eventually, but it's way too early right now.

That's a really important point. I wasn't thinking about how hooks lock
in API decisions.

For this series, I will stay completely away from hooks. The --format
discussion with Kristoffer is interesting for future work, but you are
right that it's way too early. We need to understand the client-side use
cases much better before committing to any hook interfaces.

I will keep the focus narrow: just making ref updates the default with a
clean way to get the old behavior.