Re: [RFC PATCH] switch: provide configurable detach

[Junio C Hamano <gitster@pobox.com>]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

> On the other hand, the BreakingChanges document does call
> git-checkout(1) “superseded”.  And in that light I do understand why
> people want to actively avoid git-checkout(1), including implementing
> replacements for all relevant checkout-use cases in git-switch(1).
>
>     Superseded features that will not be deprecated
>
>     [...]
>
>     • The features git-checkout(1) offers are covered by the pair of
>       commands git-restore(1) and git-switch(1). Because the use of
>       git-checkout(1) is still widespread, and it is not expected that
>       this will change anytime soon, all three commands will stay.

Perhaps a good first step would be to stop calling checkout
"superseded".  As they stand, all three are equally viable.  In
other words, I would not exactly call "switch/restore" a failed
experiment, but it wasn't a clear success story, either.

I think "still" and "anytime soon" in the above paragraph are doing
disservice by implying that somehow we want to remove checkout but
we cannot yet, when the reality is that we wanted to be able to
replace checkout with switch/restore in the distant past, but that
was a misguided attempt and did not work very well.

It is not like switch/restore pair did not work well or anything,
and in that sense switch/restore themselves are by no means
failures, but it was a failed experiment to introduce these two as a
way to replace and kill checkout.  For those users to whom both
"checking out files" and "checkout out a branch" appear as clear
concepts, there is no reason to abandon checkout.