Re: [RFC PATCH] switch: provide configurable detach

["Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>]

On Mon, Apr 6, 2026, at 18:36, Junio C Hamano wrote:
> Thibaud CANALE <thican@thican.net> writes:
>>[snip]
>>  3 files changed, 46 insertions(+), 3 deletions(-)
>
> Sorry, but I am fairly negative on this change.
>
>[snip]
>
> FWIW, "git checkout" that knows what is and what is not a branch
> name and does not require "--detach" when detaching to anything that
> is not a branch name is always available and will not be going away.

On the one hand, I personally mostly use git-checkout(1) because I never
use it to check out files and I like the detach behavior. So from that
perspective I don’t understand Git users who interject when you provide
examples for something and you (incidental to the example and point) use
git-checkout(1) because that’s what you are used to. And they interject
because git-checkout(1) is “obsolete” or something and you are setting a
bad example (or something).

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.

https://git-scm.com/docs/BreakingChanges