From: Elijah Newren Date: Wed, 08 Oct 2025 20:56:35 GMT Subject: Re: [PATCH v2 0/1] replay: make atomic ref updates the default behavior Message-ID: In-Reply-To: <38742a2f-5c5b-48f8-a9fd-acea47b7ce71@gmail.com> 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. pre-rebase, for example, forced the assumption of only one ref being involved. The early implementation of rebase as a shell script on top of other commands forced assumptions that it played with pre-commit, post-commit, and post-checkout, and forces us today to continue to check out every intermediate commit to the working copy even when the rebase could otherwise be done entirely in-memory without touching the index or working copy. post-rewrite seems more sane than most other hooks, but I still want to avoid painting ourselves into a corner, and hooks are very much about defined and established APIs through which we communicate to other processes, which means it's exactly the kind of thing that could paint us into a corner. We'll probably want that kind of extensibility eventually, but it's way too early right now.