git-switch history and checkout compatibility

Hello,

I have been waiting for people to report this but it never came so I'm doing it:

I have trouble with getting used to git-switch instead of git-checkout, but have even more trouble to get people to adopt it.

Please consider the two following git-switch statements:

git switch remote/branch # fatal: a branch is expected, got remote branch 'remote/branch' #and git switch -d remote/branch git switch master git switch - # fatal: a branch is expected, got commit 'commit_id_here'

Both as retro-compatibility with checkout and for user-friendliness, I would expect both to work. Maybe a setting checkout.autoDetach could control such behavior if the current implementation should be kept?

What do you think?

Kind regards, Minato

Namikaze Minato <LLoydsensei+git@gmail.com> writes:

I wasn't among the primary advocates to add "switch/restore" pair for those people who felt "checkout" was overloaded, and I may be misremembering why they decided to deviate from what "checkout" (one that checks out a branch, not the one that checks out paths) did in these two cases. Having said that ...

 * I suspect that requiring an explicit "--detach" is deliberate, as
   they were trying to make "newbie friendlier" version of checkout.

 * I am on the fence about the latter one.  While I think it is a
   bug if "switch -" and "switch @{-1}" did not work exactly like
   "checkout @{-1}", combined with the previous point of requiring
   to be explicit when detaching HEAD, "switch -" that tries to go
   back to a detached state may be justifiable---it stops you in
   order to avoid accidental detaching of HEAD.

Personally, I think those who are familiar with and expert enough on Git and do not feel uneasy working on detached HEAD can and should just use "checkout" not "switch/restore", but that may be just me.

Thanks.

On Wed, 28 Jun 2023 at 18:39, Junio C Hamano <gitster@pobox.com> wrote:

Yes, I also believe this is deliberate. I do not think however it makes it newbie-friendly. As I said, on the contrary, I am having a hard time to get newbies to start using switch precisely because it behaves differently from checkout.

You are right, it may be justifiable. But unexpected behavior for both newbies and experts may not be desirable.

Isn't checkout supposed to become deprecated at some point? Does it mean I can safely ignore the fact that switch exists and continue advocating for checkout instead? I am missing the point for the introduction of git-switch entirely then. And as you said you were not among the primary advocates to add it, I guess we should wait for someone else to reply about this?

And I still would love to have a checkout.autoDetach or switch.autoDetach option :)

In any case, thank you already for this reply <3 Minato

Namikaze Minato <LLoydsensei+git@gmail.com> writes:

Deprecating "checkout" hurts those who are confused by what the split "switch/restore" pair of commands do (cf. this very discussion we are having), and folks who are happily using "checkout". On the other hand, those who are happy with "switch/restore" would not be affected by the existence of "checkout". So, no, I do not think it is part of the map to deprecate the command. At least not until the split "switch/restore" pair of commands become less confusing and lose their "experimental" state, that is.

There are things "switch/restore" pair do differently relative to "checkout". Some of them (like "restore" allowing checking out paths from tree only to the working tree files while not touching the index, which is not possible with "checkout") are very much welcome improvement, but some others (cf. this very discussion we are having on "switch") may simply not make any sense. Those who advocated and pushed the split "switch/restore" pair should be able to explain why they chose to do things differently much better than I would be (some differences may simply be bugs waiting to be fixed by them).