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

From: Kristoffer Haugsbakk <code@khaugsbakk.name>
Date: Oct 3, 2025, 19:05 UTC
Message-ID: <6d19a0c4-f000-43f5-b2e1-f84f341063a9@app.fastmail.com>
In-Reply-To: <61107972-5755-49b9-a126-9442418ddff0@gmail.com>

Good evening Siddharth

On Fri, Oct 3, 2025, at 01:36, Siddharth Asthana wrote:

Show 39 quoted lines

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

Show 16 quoted lines

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

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!