From: Elijah Newren Date: Tue, 09 Sep 2025 09:19:03 GMT Subject: Re: [PATCH 0/2] replay: add --update-refs option Message-ID: In-Reply-To: On Tue, Sep 9, 2025 at 12:47 AM Christian Couder wrote: > > On Tue, Sep 9, 2025 at 9:14 AM Elijah Newren wrote: > > > > On Sun, Sep 7, 2025 at 9:36 PM Siddharth Asthana > > 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? I don't think so; we marked it as experimental much more prominently than other commands -- in the .c file, and three separate places in the documentation. All other commands appear to have only been marked as experimental in one place and never the C file, so this one is four times more experimental than any other command. Plus, the worry about it being set in stone and the need to make it malleable was *exactly* why the requests were made to be so much more clear that this command needed the flexibility to change (https://lore.kernel.org/git/CABPp-BFrVfGHOrBk7g=4TkGxDv=oSqF1FOkhp6WVbxUV-2yveQ@mail.gmail.com/). Plus, it's currently only used server-side, so it'd probably only mean GitLab (you), GitHub (me), and a few other users would need to update, all of whom should be aware of the warnings. We could add a config setting to allow defaulting to --no-update-refs or whatever we want to call it. > > > 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. You often word things well; I like that sentence. The original makes me guess and wonder whether something like that is the intent; can we replace the original sentence with your description?