Re: [PATCH] RFC: switch: allow same-commit switch during merge if conflicts resolved

>
> Elijah Newren <newren@gmail.com> writes:
>
> > By the way, it was a problem that git-checkout wasn't updated to have
> > the same safety that git-switch has.  We should fix that.  (It's on my
> > todo list, along with adding other
> > prevent-erroneous-command-while-in-middle-of-other-operation cases.)
>
> Yes.
>
> > I'm worried this is likely to lead us into confusing UI mismatches,
> > and makes it harder to understand the appropriate rules of what can
> > and cannot be done.  A very simple "no switching branches in the
> > middle of operations" is a very simple rule, and saves users from lots
> > of headaches.
> >
> > Granted, expert users may understand that with the commit being the
> > same, there is no issue.  But expert users can use `git update-ref` to
> > tweak HEAD, or edit .git/HEAD directly, and accept the consequences.
> > Why do we need to confuse the UI for the sake of expert users who
> > already have an escape hatch?
> >
> > More importantly, though...
> >
> >> Change the behavior of "git switch" and "git checkout" to no longer delete
> >> merge metadata, nor prohibit the switch, if a merge is in progress and the
> >> commit being switched to is the same commit the HEAD was previously set to.
> >
> > Even if there are conflicts?  For rebases, cherry-picks, ams, and
> > reverts too?  (Does allowing this during rebases and whatnot mean that
> > --abort becomes really funny?  Does it mean that some commits are
> > applied to one branch, and all commits are applied to another?  What
> > about autostashes?  Does it interact weirdly with --update-refs?
> > etc.)
> >
> > I think this change is premature unless it discusses all these cases,
>
> It is pretty much what I wanted to say about why we haven't done
> this in <https://lore.kernel.org/git/xmqqpm7k6ojz.fsf@gitster.g/>,
> so it makes two of us ;-).  I didn't look at Tao's RFC patch but if
> the way it determines "we are in a middle of conflicted merge and
> we'll allow switching to the same commit only in this case" were
> "the index has an unmerged entry", then it is an overly broad test
> and the consequences of allowing the switch for these other merge-y
> operations that are ongoing must be evaluated.