On 26/03/2019 15:48, Elijah Newren wrote:

On Tue, Mar 26, 2019 at 8:24 AM Duy Nguyen [off-list ref] wrote:

quoted

On Tue, Mar 26, 2019 at 10:01 PM Elijah Newren [off-list ref] wrote:

quoted

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.

quoted

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.

quoted

quoted

quoted

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