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

From: Siddharth Asthana <siddharthasthana31@gmail.com>
Date: Oct 2, 2025, 23:36 UTC
Message-ID: <61107972-5755-49b9-a126-9442418ddff0@gmail.com>
In-Reply-To: <f0abdc27-6850-4b9d-b4eb-a1c92f731142@app.fastmail.com>

On 02/10/25 22:44, Kristoffer Haugsbakk wrote:

Show 47 quoted lines

> On Sat, Sep 27, 2025, at 01:08, Siddharth Asthana wrote:
>> This is v2 of the git-replay atomic updates series.
>>
>> Based on the extensive community feedback from v1, I've completely redesigned
>> the approach. Instead of adding new --update-refs options, this version makes
>> atomic ref updates the default behavior of git replay.
>>
>> Why this change makes sense:
>> - git replay is explicitly marked as EXPERIMENTAL with behavior changes
>> expected
>> - The command is primarily used server-side where atomic transactions
>> are crucial
>> - Current pipeline approach (git replay | git update-ref --stdin)
>> creates
>>    coordination complexity and lacks atomic guarantees by default
>> - Patrick Steinhardt noted performance issues with individual ref
>> updates
>>    in reftable backend
>> - Elijah Newren and Junio Hamano endorsed making the better behavior
>> default
>>
>> [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.

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

Thanks for the thoughtful feedback!