From: Siddharth Asthana Date: Wed, 08 Oct 2025 21:18:46 GMT Subject: Re: [PATCH v2 0/1] replay: make atomic ref updates the default behavior Message-ID: In-Reply-To: On 09/10/25 02:26, 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. > 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. That's a really important point. I wasn't thinking about how hooks lock in API decisions. For this series, I will stay completely away from hooks. The --format discussion with Kristoffer is interesting for future work, but you are right that it's way too early. We need to understand the client-side use cases much better before committing to any hook interfaces. I will keep the focus narrow: just making ref updates the default with a clean way to get the old behavior.