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
