From: Elijah Newren Date: Tue, 09 Sep 2025 07:13:53 GMT Subject: Re: [PATCH 0/2] replay: add --update-refs option Message-ID: In-Reply-To: <20250908043620.57848-1-siddharthasthana31@gmail.com> On Sun, Sep 7, 2025 at 9:36 PM Siddharth Asthana wrote: > > This patch series adds a --update-refs option to git replay. Right now, > when you use git replay, you need to pipe its output to git update-ref > like this: > > git replay --onto main topic1..topic2 | git update-ref --stdin > > This works fine, but it means running two commands and doesn't give you > atomic transactions by default. The new --update-refs option lets you do > the ref updates directly: > > git replay --update-refs --onto main topic1..topic2 > > I discussed this feature with Christian Couder earlier, and we agreed that > it would be useful for server-side operations where you want atomic updates. Seems fair...but why not make --update-refs the default and add an option for those that just want the update commands? > The way it works: > - By default, it uses atomic transactions (all refs get updated or none do) > - There's a --batch option if you want some updates to succeed even if > others fail > - It works with bare repositories, which is important for server operations > like Gitaly > - When it succeeds, it doesn't print anything (just like git update-ref > --stdin) Seems fair. > This should help with git replay's goal of being good for server-side > operations. I'm slightly confused by this statement; there's multiple ways to interpret it -- various antecedents of "This", questions about whether you are saying git replay has one goal or you are just helping with one of its goals, and leaves to the reader to guess which part is helpful (is it the ergonomics -- why does that matter server-side? Is it the atomicity? Then why did you also add --batch and --update? Is it something else?) Perhaps this sentence can be dropped or completely rewritten? > It also makes the command simpler to use since you don't need > the pipeline anymore, and the atomic behavior is better for reliability. Yeah, makes sense...but why not just make it the default behavior instead of requiring an extra flag? (The command is marked as experimental...)