From: Siddharth Asthana Date: Thu, 02 Oct 2025 23:36:45 GMT Subject: Re: [PATCH v2 0/1] replay: make atomic ref updates the default behavior Message-ID: <61107972-5755-49b9-a126-9442418ddff0@gmail.com> In-Reply-To: On 02/10/25 22:44, Kristoffer Haugsbakk wrote: > 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!