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

[Elijah Newren <newren@gmail.com>]

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 -- 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.  :-)