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

From: Junio C Hamano <[email-masked]>
Date: Mon, 13 Oct 2025 12:39:57 -0700

Siddharth Asthana <[email-masked]> 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.

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