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

On Thu, May 4, 2023 at 7:01 AM Tao Klerks <tao@klerks.biz> wrote:

Having reviewed the commit by Nguyễn Thái Ngọc Duy that introduced the
"can_switch_when_in_progress" boolean in 2019 (as part of the broader
introduction of "git switch" and "git restore"), it looks like I
should change my proposal here. I thought it made sense to continue to
support --force because we can, but I now think this is wrong,
because:
1. the fact that --force does not work in git switch is *intentional*
2. even though making it work for "merging" states would be trivial,
making it work during rebase would not be
3. the blocking of --force is not a significant inconvenience, as the
error message clearly tells you what to do (--quit), to continue on
your way

So I will set about trying to understand how to make this one-line change work. I already see that some tests rely on "git checkout -f" bulldozing through an ongoing merge, so those tests will need to be adjusted at least.

Are there any recommendations or processes around breaking changes for the git project anywhere? The specific behaviors that we would be changing here appear to be undocumented (I've looked through https://git-scm.com/docs/git-checkout at least and find no mention or expectation that switching during a merge, or rebase, etc is supported; nor do I see any explicit mention in https://git-scm.com/docs/git-switch that it is UNsupported)

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?