Re: [PATCH] RFC: switch: allow same-commit switch during merge if conflicts resolved

From: Elijah Newren <newren@gmail.com>
Date: May 7, 2023, 02:57 UTC
Message-ID: <CABPp-BGtRF68YJaN+nQ6bCqeh4R-dC9a6mBZvAFkX9YbkFR3sQ@mail.gmail.com>
In-Reply-To: <CAPMMpoi7+rdQzQPyVB8T9Pb+f332c68QvWLkwBdJZw=BcP0jbQ@mail.gmail.com>

On Thu, May 4, 2023 at 10:06 PM Tao Klerks <tao@klerks.biz> wrote:

[...]

> ASIDE: I realized today that the warnings in
> die_if_some_operation_in_progress() suggest "--quit" (potentially
> leaving a conflicted index) and do not mention "--abort". Is there any
> objection to beefing up these messages a bit to offer both options?

Honestly, I'd prefer to just change them to --abort.

--quit is for very unusual expert situations (I did the operation, forgot I was in the middle, did all kinds of funny resets and tweaks and who-knows-what, and then later discovered there was an in-progress operation I had forgotten, but I decided I liked my totally munged state better and want to keep it while somehow marking the operation as over.[1]) I think recommending it to users is a bit of a disservice. If someone feels strongly about keeping it, I'd argue for having both --abort and --quit, with --abort more prominent.

But my first vote would be for changing these to mention --abort. And adding some scary warnings to the places where --quit is documented, to recommend users consider --abort instead.

[1] That might sound like an exaggeration, but I think that's exactly how it was advertised originally: 9512177b682 ("rebase: add --quit to cleanup rebase, leave everything else untouched", 2016-11-12)