Re: [PATCH v3 10/21] checkout: split part of it to new command 'switch'

[Phillip Wood <phillip.wood123@gmail.com>]

On 26/03/2019 15:48, Elijah Newren wrote:
> On Tue, Mar 26, 2019 at 8:24 AM Duy Nguyen <pclouds@gmail.com> wrote:
>> On Tue, Mar 26, 2019 at 10:01 PM Elijah Newren <newren@gmail.com> 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