On Tue, Mar 26, 2019 at 10:48 PM Elijah Newren <new...@gmail.com> wrote:
> > > > 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

Reply via email to