On Tue, Mar 26, 2019 at 8:24 AM Duy Nguyen <pclouds@xxxxxxxxx> wrote: > On Tue, Mar 26, 2019 at 10:01 PM Elijah Newren <newren@xxxxxxxxx> wrote: > 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. Yes, and in the middle of a cherry-pick with a range you've added some commits to one branch and some to another. In the middle of a revert you're doing similar. It sounds like crazytown to me (and maybe we shouldn't provide the --ignore-in-process flag unless users clamor for it -- or maybe we should print a big warning whenever people use it much like we've traditionally done when people checkout a commit rather than a branch), but it at least makes sense what is happening and users had to explicitly state they wanted the in-progress state to just be ignored and switch anyway. > 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. Combining that with some kind of warning about weird effects of applying a mid-operation process across branches seems like a good idea to me if we're going to have that flag. > > > 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. Yeah that is slightly odd -- but that at least provides a small silver lining: it makes it easier to decide to change it and move all the mid-operation-state-clearing to other commands. :-)
