On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote: > On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote: > > "git checkout" doing too many things is a source of confusion for many > > users (and it even bites old timers sometimes). To remedy that, the > > command will be split into two new ones: switch and > > something-to-checkout-paths. > > I think this is a good idea, thanks for working on it. I wonder if it > would be a good idea to have the new command refuse to checkout a new > branch if there is a cherry-pick/revert/merge/rebase in progress (with > an option to override the check) as switching branches in the middle of > one of those is likely to be confusing to users (if I do it it is > normally because I've forgotten that I've not run 'git whatever > --continue'). Guys, I'm sorry for bringing this up again. Apparently I'm not quite done with 'git switch' yet (not sure if I will ever be). There is an interesting behavior in git-checkout (and of couse git-switch). When you do a successful switch, CHERRY_PICK_HEAD, REVERT_HEAD, MERGE_HEAD, MERGE_RR, MERGE_MSG, MERGE_MODE and SQUAHS_MSG, if exists, will be removed. This basically means that if you switch away, any cherry-pick, merge or revert in progress is destroyed (in the sense of "--quit" not "--abort" of course). All of this, I believe, involves merge conflicts so you can't easily switch away unless you allow to destroy unmerged entries. So it's still quite safe. However, it leaves me a funny feeling because some "work-in-progress" operations are destroyed, but some others (bisect, rebase) are not. This is git-checkout behavior and I will not change that. But do we want the same behavior in git-switch? Or do we want no-destroy-in-progress-whatsoever? Or destroy-all-commands-in-progress? It may also be a good idea to attempt to describe the behavior we want in git-switch.txt. I think if the description gets too complicated, we're heading a wrong way. The current behavior so far could still be described as "work-in-progress operations related to merge conflicts are destroyed", or something along that line. But I'm not quite convinced it's easily understood. PS. git-reset shares the same behavior, but it's in a different boat, I think. Or maybe I should scrap/replace that one as well. PPS. It may get trickier with cherry-pick which can pick a range of commits now, not just one. But I never used that feature much to know what I'm talking about. -- Duy
