On Thu, May 4, 2023 at 7:01 AM Tao Klerks <tao@xxxxxxxxxx> wrote: > > Please let me know whether you would be comfortable with a patch that: > * Fixed checkout to be more restrictive (except still allowing --force > at least on a merging state) > [...] 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?
