Re: [PATCH v2 1/1] replay: make atomic ref updates the default behavior

> 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.