From: Siddharth Asthana Date: Wed, 15 Oct 2025 04:57:13 GMT Subject: Re: [PATCH v3 0/3] replay: make atomic ref updates the default Message-ID: In-Reply-To: On 14/10/25 01:09, Junio C Hamano wrote: > Siddharth Asthana 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= for extensibility** >> >> Phillip suggested that separate boolean flags (--output-commands, >> --allow-partial) were limiting for future expansion. The --update-refs= >> 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=` - `push.default` ↔ (implicit push behavior) - `log.decorate` ↔ `--decorate=` 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.