Re: [PATCH v2 1/1] replay: make atomic ref updates the default behavior
- From
Elijah Newren <newren@gmail.com>
- Date
- Oct 8, 2025, 21:30 UTC
- Message-ID
- <CABPp-BEuK1MWxmRc-a=1aPqLbXEZVF0qgHtYv_Z-1mXm3Ag5_w@mail.gmail.com>
- In-Reply-To
- <ea7aa170-400c-47fa-b3f0-2623fcbfcaea@gmail.com>
On Wed, Oct 8, 2025 at 1:06 PM Siddharth Asthana <siddharthasthana31@gmail.com> wrote:
>
[...]
> Elijah's --format idea from Kristoffer might be a third mode eventually
?
That was in no way my idea; it was all Kristoffer's.
The --format idea might eventually be useful, but to me the --format thing seems like something you'd add to a very stable command, like for-each-ref. I think it wouldn't make sense to add to something like replay in its current state since replay is "four times more experimental than any other command"[1], where we're changing the basic output format, where we bail on any conflicts or merge commits, where we recently discussed whether to support first-class conflicts and using that for handling conflicts instead of halting upon the first one like rebase does, etc. I feel much the same as when a similar flag was suggested for merge-tree (in order to let users control the exact output layout of the information it was already printing, when it was known that the information provided was insufficient to solve the user's problems)[2] -- it's premature.
[1] that might be slightly over the top, but it's still a fun "statistic" of sorts -- see https://lore.kernel.org/git/CABPp-BHWjyRv_f_HKkz10Q_cOZKPvpgf=SEUR1ThmbttkQT+Uw@mail.gmail.com/ [2] https://lore.kernel.org/git/CABPp-BG25_TutatgNmK6vgq3akxpYHQ8QBnz-65_F_3oCA1nJA@mail.gmail.com/