Re: [PATCH v3 0/3] replay: make atomic ref updates the default

[Siddharth Asthana <siddharthasthana31@gmail.com>]

On 14/10/25 01:09, Junio C Hamano wrote:
> Siddharth Asthana <siddharthasthana31@gmail.com> writes:
>
>> **Removed --allow-partial option**
>>
>> After discussion with Elijah and Junio, we couldn't identify a concrete
>> use case for partial failure tolerance. The traditional pipeline with
>> git-update-ref already provides partial update capabilities when needed
>> through its transaction commands. Removing this option simplifies the API
>> and avoids committing to behavior without clear real-world use cases.
> Ack.
>
>> **Changed to --update-refs=<mode> for extensibility**
>>
>> Phillip suggested that separate boolean flags (--output-commands,
>> --allow-partial) were limiting for future expansion. The --update-refs=<mode>
>> design allows future modes without option proliferation:
>>    - --update-refs=yes (default): atomic ref updates
>>    - --update-refs=print: pipeline output
>>    - Future modes can be added as additional values
>>
>> This API pattern prevents the need for multiple incompatible flags and
>> provides a cleaner interface for users.
> Ack.
>
>> **Added replay.defaultAction configuration option**
> If a configuration option is added, please consider and think hard
> if its relationship with the command lineoption can be made obvious.
> I do not think it is obvious to anybody that replay.defaultAction is
> somehow tied to "git replay --update-refs" at all.  Either the
> variable should be renamed to include words like "update" and/or
> "ref" to hint its link to the option, or the option should be
> renamed to use the word "action" to hint its link to the variable.


You are absolutely right - the disconnect between `replay.defaultAction` and
`--update-refs` makes the relationship unclear. I chose `defaultAction` 
thinking
it would be more extensible if we add other behaviors in the future, but 
that
came at the cost of discoverability.

Looking at how other Git commands handle this, I see a few patterns:
- `commit.cleanup` ↔ `--cleanup=<mode>`
- `push.default` ↔ (implicit push behavior)
- `log.decorate` ↔ `--decorate=<mode>`

Given your feedback in the other thread about `--ref-action` potentially 
being
clearer than `--update-refs`, would it make sense to align both?

Option 1: `replay.refAction` ↔ `--ref-action=(update|print)`
Option 2: `replay.updateRefs` ↔ `--update-refs=(yes|print)`

I am leaning toward Option 1 because:
- "ref-action" clearly conveys "what action to take on refs"
- The config name `replay.refAction` directly mirrors the option
- It's more obvious what the relationship is

What do you think? I am happy to go with either approach or a different 
naming
scheme if you have a preference.

Thanks,
Siddharth


>
>> The command-line --update-refs option overrides the config, allowing users
>> to set a preference while maintaining per-invocation control.
> That would follow the standard practice of configuration giving the
> default that can be overriden via the command line option per
> invocation, which would match end-user expectations.  Good.
>
> Thanks.