On Tue, Mar 26, 2019 at 10:01 PM Elijah Newren <newren@xxxxxxxxx> wrote: > > On Tue, Mar 26, 2019 at 5:50 AM Duy Nguyen <pclouds@xxxxxxxxx> wrote: > > 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? > > I thought we already decided that we'd abort the switch if there was > any operation-in-progress state? Or are you asking what should we do > if the user explicitly overrides this error with e.g. > --ignore-in-progress? In that case, I'd say that the reasonable thing > to do would be to leave all the state files alone. If we make it > clear out the state, we're simply combining uncommon commands for the > user (<operation> --quit + git switch), which seems like a bad UI path > to go down. Allowing them to switch to some other branch while > keeping all state files is something they can't do with any other > command, and while I hope people wouldn't want to do that much, > switching while keeping state files is something that can't be done > with combining other commands and thus at least makes sense as > something to consider providing. Yeah.. --ignore-in-process does not necessarily mean aborting something when you just want to get out to examine some other commit. And I agree doing nothing seems like the best (or least confusing/surprising) option. There will be some funny thing. Like if you commit after switching away and MERGE_HEAD is there, I think you will be creating a merge commit. But I guess if you choose --ignore-in-progress, you're pretty much on your own. We could improve "git commit" and friends to realize that the current state is unlikely safe to resume whatever in-progress operations. But that's separate and I don't want to dig another hole to bury myself in while there's still 'git restore' to take care of. Or maybe I'll just suggest "git <verb> --quit" when the switch is successful with --ignore-in-progress. Will wait a while for people to comment (and work on that 'git switch --recurse-submodules', which seems also needs some work) before resubmitting. > > 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. > > reset has traditionally been the home of > how-to-clear-in-progress-state. e.g. aborting a merge or cherry-pick > or revert was 'reset --hard' (or later 'reset --merge'), skipping a > become-empty cherry-pick or rebase is still 'reset', etc. So it's not > that surprising to me that it clears out state. > ... Yeah but it was surprising to me that this is not even mentioned anywhere in git-reset.txt. You learn by examples basically, or by experience. But I digress. -- Duy
