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

[Duy Nguyen <pclouds@gmail.com>]

On Tue, Mar 26, 2019 at 10:01 PM Elijah Newren <newren@gmail.com> wrote:
>
> On Tue, Mar 26, 2019 at 5:50 AM Duy Nguyen <pclouds@gmail.com> wrote:
> > On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
> > > On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
> > > > "git checkout" doing too many things is a source of confusion for many
> > > > users (and it even bites old timers sometimes). To remedy that, the
> > > > command will be split into two new ones: switch and
> > > > something-to-checkout-paths.
> > >
> > > I think this is a good idea, thanks for working on it. I wonder if it
> > > would be a good idea to have the new command refuse to checkout a new
> > > branch if there is a cherry-pick/revert/merge/rebase in progress (with
> > > an option to override the check) as switching branches in the middle of
> > > one of those is likely to be confusing to users (if I do it it is
> > > normally because I've forgotten that I've not run 'git whatever
> > > --continue').
> >
> > Guys, I'm sorry for bringing this up again. Apparently I'm not quite
> > done with 'git switch' yet (not sure if I will ever be).
> >
> > There is an interesting behavior in git-checkout (and of couse
> > git-switch). When you do a successful switch, CHERRY_PICK_HEAD,
> > REVERT_HEAD, MERGE_HEAD, MERGE_RR, MERGE_MSG, MERGE_MODE and
> > SQUAHS_MSG, if exists, will be removed.
> >
> > This basically means that if you switch away, any cherry-pick, merge
> > or revert in progress is destroyed (in the sense of "--quit" not
> > "--abort" of course). All of this, I believe, involves merge conflicts
> > so you can't easily switch away unless you allow to destroy unmerged
> > entries. So it's still quite safe.
> >
> > However, it leaves me a funny feeling because some "work-in-progress"
> > operations are destroyed, but some others (bisect, rebase) are not.
> > This is git-checkout behavior and I will not change that. But do we
> > want the same behavior in git-switch? Or do we want
> > no-destroy-in-progress-whatsoever? Or
> > destroy-all-commands-in-progress?
>
> I thought we already decided that we'd abort the switch if there was
> any operation-in-progress state?  Or are you asking what should we do
> if the user explicitly overrides this error with e.g.
> --ignore-in-progress?  In that case, I'd say that the reasonable thing
> to do would be to leave all the state files alone.  If we make it
> clear out the state, we're simply combining uncommon commands for the
> user (<operation> --quit + git switch), which seems like a bad UI path
> to go down.  Allowing them to switch to some other branch while
> keeping all state files is something they can't do with any other
> command, and while I hope people wouldn't want to do that much,
> switching while keeping state files is something that can't be done
> with combining other commands and thus at least makes sense as
> something to consider providing.

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.

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.

Will wait a while for people to comment (and work on that 'git switch
--recurse-submodules', which seems also needs some work) before
resubmitting.

> > It may also be a good idea to attempt to describe the behavior we want
> > in git-switch.txt. I think if the description gets too complicated,
> > we're heading a wrong way. The current behavior so far could still be
> > described as "work-in-progress operations related to merge conflicts
> > are destroyed", or something along that line. But I'm not quite
> > convinced it's easily understood.
> >
> > 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.
-- 
Duy