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

From: Siddharth Asthana <siddharthasthana31@gmail.com>
Date: Oct 8, 2025, 20:02 UTC
Message-ID: <38742a2f-5c5b-48f8-a9fd-acea47b7ce71@gmail.com>
In-Reply-To: <6d19a0c4-f000-43f5-b2e1-f84f341063a9@app.fastmail.com>

On 04/10/25 00:35, Kristoffer Haugsbakk wrote:

Show 72 quoted lines

> Good evening Siddharth
>
> On Fri, Oct 3, 2025, at 01:36, Siddharth Asthana wrote:
>> On 02/10/25 22:44, Kristoffer Haugsbakk wrote:
>>>> [snip]
>>> On the topic of changing experimental commands: I really like the
>>> git-for-each-ref(1) (git-FER) output format design.  It just outputs refs and
>>> related data.  It’s not a command for “bulk delete refs” or “check for
>>> merge conflicts between these refs and upstream (git-merge-tree(1)”—it
>>> just supports all of that through `--format` and its atoms.
>>>
>>> And for this command it seems to, at the core, output a mapping from old
>>> to new commits.
>>>
>>> Now, I’ve thought that a “client-side”[1] in-memory rebase-like command
>>> would need to support outputting data for the `post-rewrite` hook.  And
>>> is that not straightforward if you can use `--format` with `from` and
>>> `to` atoms?  (I ask because I have never called hooks with git-hook(1).)
>>>
>>> I just think that (naively maybe) a `--format` command like git-FER with
>>> all the quoting modes might be a good fit for this command.  Then you
>>> can compose all the steps you need yourself:
>>>
>>> 1. Call the exact git-update-ref(1) `--batch`/`--stdin` or whatever mode
>>>      you need
>>> 2. Write a message to each reflog if you want
>>> 3. Call the `post-rewrite` hook
>>>
>>> † 1: c.f. server-side which I get the impression only wants to do cheap
>>>        rebases
>>
>> Hi Kristoffer,
>>
>> That's an interesting perspective on using --format for composability,
>> similar to git-for-each-ref's design.
>>
>> The constraint right now is that git replay's output needs to work
>> directly with update-ref --stdin, which has a specific format. Adding
>> --format would let users customize the output, but then they'd need to
>> transform it to the update-ref format anyway for the most common case,
>> which seems like extra work.
> git-FER has a default format and could still use that (either the
> current one or your proposal).
>
> git-replay(1) could also concievably support ready-made formats, similar
> to “pretty” formats that git-log(1) & co.
>
>> Your point about post-rewrite hook support is well-taken though. As this
>> command evolves toward client-side interactive rebase (which was Elijah's
>> original design goal), we will definitely need hook integration. At that
>> point, a --format approach with atoms like %(old) and %(new) could make
>> sense for letting users extract the commit mapping in whatever form they
>> need for hooks or other tooling.
>>
>> For this iteration I am focusing on the simpler atomic update case, but
>> I will
>> keep the --format idea in mind for future work.
>>
>> [replying to this part
>>
>> Do you see a specific use case right now where --format would help, or
>> is this more about future-proofing the design for when we add
>> client-side features?
> 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!

Show 14 quoted lines

>
> Beyond that though I’ve been thinking about more hypothetical “client-
> side” concerns.  I mentioned writing to the reflog.  I imagine that
> server programs that just want to be able to efficiently “rebase”
> branches to the upstream don’t need that.  But client-side programs
> might want to write to the reflog because they want to mark what the
> update is for; you could have many kinds of client-side “update ref”
> programs and want to leave breadcrumbs about what was done.  There is
> more experimentation.  Whereas I imagine that a forge has maybe a small
> set of “update branch” commands.  I don’t know, maybe I’m rambling at
> this point.
>
>> Thanks for the thoughtful feedback!
> Thanks for the consideration and reply!