On 26/03/2019 15:48, Elijah Newren wrote: > 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 I think that could be the way to go for merges and cherry-picks, or possibly require --discard-changes as well. The only time I use checkout like this is during a rebase if I want to rewind it - I edit the todo list with the output of 'git log --pretty="pick %h %s" --reverse' and do 'git checkout' followed by 'git rebase --continue' Though these days I could add a 'reset' line to the todo list and skip the checkout. > -- 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. :-) The missing documentation is odd but I think it makes sense. 'reset --hard' throws away all the changes in the index and worktree so it would be confusing if MERGE_HEAD was left behind. 'reset --mixed' throws away the changes in the index and you cannot do a partial commit if MERGE_HEAD or CHERRY_PICK_HEAD exist so it probably makes sense there as well (although if you do 'git reset && git commit -a' it wont remember the merge/cherry-pick). Some of the other reset modes (--soft and --keep I think) detect on in progress merge and refuse to run, I've got a patch somewhere that extends that to cherry-picks. I should probably extend it to handle --merge as well (are there any other modes, I only ever use --hard/--mixed/--soft as I'm never sure what the others will do) Best Wishes Phillip
