git-switch history and checkout compatibility

git-switch history and checkout compatibility

[Namikaze Minato]

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

Re: git-switch history and checkout compatibility

[Junio C Hamano]

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

> 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.

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.

> Maybe a setting checkout.autoDetach could control such behavior if the
> current implementation should be kept?
>
> What do you think?

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.

Re: git-switch history and checkout compatibility

[Namikaze Minato]

On Wed, 28 Jun 2023 at 18:39, Junio C Hamano <gitster@pobox.com> wrote:
>  * I suspect that requiring an explicit "--detach" is deliberate, as
>    they were trying to make "newbie friendlier" version of checkout.
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.

>  * 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.
You are right, it may be justifiable. But unexpected behavior for both
newbies and experts may not be desirable.

> 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.
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

Re: git-switch history and checkout compatibility

[Junio C Hamano]

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

> Isn't checkout supposed to become deprecated at some point?

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.

> ... 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?

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).