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

From: "Kristoffer Haugsbakk" <[email-masked]>
Date: Thu, 02 Oct 2025 19:14:44 +0200

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

-- 
Kristoffer