Subject: Re: [PATCH 0/2] replay: add --update-refs option

From: Siddharth Asthana <[email-masked]>
Date: Tue, 9 Sep 2025 12:06:45 +0530

On 08/09/25 11:37, Christian Couder wrote:
> On Mon, Sep 8, 2025 at 6:36 AM Siddharth Asthana
> <[email-masked]> 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
> Thanks for working on this.
>
>> 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.
> Yeah, right. This is something the Git team at GitLab has been
> interested in for some time.
>
>> 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)
>> - You can't use --update-refs with the existing --update option
> There is no existing --update option. This series also introduces the
> --update option.
You are right that was confusing wording in my cover letter. Both 
--update and --update-refs are new in this series.
>
>> This should help with git replay's goal of being good for server-side
>> operations. It also makes the command simpler to use since you don't need
>> the pipeline anymore, and the atomic behavior is better for reliability.
> I have commented only on the documentation patch for now as I think
> it's better to review the design of the new options first, and the
> documentation looks like a good place for that.
>
> Thanks again.