Re: [PATCH 0/2] replay: add --update-refs option
- From
Christian Couder <christian.couder@gmail.com>
- Date
- Sep 9, 2025, 07:47 UTC
- Message-ID
- <CAP8UFD3GU5Xwq7WMihmHtpWc-GjB-guTU6JHG7BdkhxukMihNQ@mail.gmail.com>
- In-Reply-To
- <CABPp-BG6A_mwxQheE5ED5HQj7STVtf1_9NhSmjmzRPB7QkdWyg@mail.gmail.com>
On Tue, Sep 9, 2025 at 9:14 AM Elijah Newren <newren@gmail.com> wrote:
> > On Sun, Sep 7, 2025 at 9:36 PM Siddharth Asthana > <siddharthasthana31@gmail.com> wrote:
> Seems fair...but why not make --update-refs the default and add an > option for those that just want the update commands?
If this patch series had been sent a few months after `git replay` was introduced, I would have been fine with this series making `git replay` update the refs by default while adding an option that only outputs the commands. Unfortunately `git replay` seems to have been introduced in v2.44.0 (Feb 22, 2024), so more than 18 months ago. So even if it is marked as experimental, it's perhaps a bit late to make such a relatively big change in it?
Show 22 quoted lines
> > 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?
The way I understood this sentence is that `git replay` is already useful on the server side (because it performs all the operations in memory and doesn't need a work tree), and the new feature added by the patch series reinforces this because atomic operations are often better on the server side.
Thanks.