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

From: Duy Nguyen <pclouds@gmail.com>
Date: Mar 26, 2019, 15:57 UTC
Message-ID: <CACsJy8B0ZWHWGbaE8eDAO_+xzATZRkwJTBGLZnQkR7jSrTv9-g@mail.gmail.com>
In-Reply-To: <CABPp-BFTyALWmnJ=dT1xNivjcQhtKak15ydfkYjEsEC-j4BD9w@mail.gmail.com>

On Tue, Mar 26, 2019 at 10:48 PM Elijah Newren <newren@gmail.com> wrote:

Show 17 quoted lines

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

Don't tempt me. Elsewhere in some discussion with Ævar I wrote it's better to add "git-ng" instead of going through the deprecation process to change behavior of current commands, which also means that you better design git-ng well because you can't just go "oops, i did it again" and add "git-nng". And I'm slowly realizing that 'switch' and 'restore' are just "git-ng checkout" in disguise. That already increases my stress level a bit.

-- 
Duy