From: Kristoffer Haugsbakk Date: Wed, 08 Oct 2025 21:16:47 GMT Subject: Re: [PATCH v2 0/1] replay: make atomic ref updates the default behavior Message-ID: <84715a9a-f1d2-4baf-a025-46490052a27b@app.fastmail.com> In-Reply-To: On Wed, Oct 8, 2025, at 22:56, Elijah Newren wrote: > On Wed, Oct 8, 2025 at 1:02 PM Siddharth Asthana > wrote: >> >> On 04/10/25 00:35, Kristoffer Haugsbakk wrote: >> > Good evening Siddharth >> > > [...] >> > 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! > > Let's be *very* careful before we add any hooks to replay. The hypothetical case I was talking about was using custom formatting output to drive git-hook(1). Not adding anything hook-related to git-replay(1).