From: Siddharth Asthana <siddharthasthana31@gmail.com>
Date: Wed, 08 Oct 2025 21:16:25 GMT
Subject: Re: [PATCH v2 1/1] replay: make atomic ref updates the default behavior
Message-ID: <5307ed25-b041-4a68-ad75-466f63851b01@gmail.com>
In-Reply-To: <CABPp-BHyKM9hVvTiPx=n9HzO7Mf9oHrJvWcvVi+HxxMXWqMekA@mail.gmail.com>


On 09/10/25 02:29, Elijah Newren wrote:
> On Wed, Oct 8, 2025 at 1:09 PM Siddharth Asthana
> <siddharthasthana31@gmail.com> wrote:
>> On 08/10/25 19:31, Phillip Wood wrote:
>>> Hi Siddharth
>>>
>>> On 02/10/2025 23:20, Siddharth Asthana wrote:
>>>> On 30/09/25 15:35, Phillip Wood wrote:
>>>>> On 27/09/2025 00:08, Siddharth Asthana wrote:
>>>>>> The git replay command currently outputs update commands that must be
>>>>>> piped to git update-ref --stdin to actually update references:
>>>> The actual advantages of the new default aren't about atomicity (that
>>>> already exists), but rather:
>>>> - Eliminating the pipeline for the common case
>>>> - Better ergonomics for users who just want refs updated
>>>> - Simpler server-side automation
>>>>
>>>> I will rewrite the commit message to accurately reflect this. Elijah
>>>> provided a good suggested structure that captures the real trade-offs
>>>> without false claims.
>>> That's great. I agree that having replay update the refs itself is a
>>> useful improvement.
>>>
>>>>>> +--allow-partial::
>>>>>> +    Allow some ref updates to succeed even if others fail. By
>>>>>> default,
>>>>>> +    ref updates are atomic (all succeed or all fail). With this
>>>>>> option,
>>>>>> +    failed updates are reported as warnings rather than causing
>>>>>> the entire
>>>>>> +    command to fail. The command exits with code 0 only if all
>>>>>> updates
>>>>>> +    succeed; any failures result in exit code 1. Cannot be used with
>>>>>> +    `--output-commands`.
>>>>> Rather than having two incompatible options perhaps we could have a
>>>>> single "--update-refs=(yes|print|allow-partial-updates)" argument. I
>>>>> think the name "--allow-partial" is rather ambiguous as it does not
>>>>> say what it is allowing to be partial.
>>>> After thinking about this and Elijah's feedback, I am leaning toward
>>>> dropping --allow-partial entirely since I don't have a concrete use case
>>>> for it. That simplifies things to just: default atomic updates vs
>>>> --output-commands for the traditional pipeline.
>>>>
>>>> Would you still prefer a --update-refs=<mode> style, or is the simpler
>>>> --output-commands flag sufficient given that --allow-partial is going
>>>> away?
>>> The advantage of --update-refs=<mode> is that it allows for future
>>> extensions such as adding support for partial in a way that does not
>>> add conflicting options.
>>
>> That's a good point about extensibility. Elijah suggested
>> --[no-]update-refs
>> which is simpler but less extensible.
>>
>> Between:
>> - --[no-]update-refs (simple, covers current needs)
>> - --update-refs=<mode> (extensible for future modes)
>>
>> I am inclined toward the simpler --[no-]update-refs for now since we don't
>> have concrete plans for other modes. But if you think the extensibility is
>> important, I can go with the =<mode> style. What do you think?
> I like Phillip's suggestion more than my own.


Got it. I will go with --update-refs=<mode> then:
- --update-refs=yes (or just --update-refs as shorthand): atomic updates
- --update-refs=print: output commands
- (future) --update-refs=allow-partial or other modes

This keeps the design extensible without adding conflicting options later.

For the config, I will use replay.updateRefs with string values matching 
the
command line modes. That keeps them consistent.