Re: git-switch history and checkout compatibility

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 28, 2023, 16:39 UTC
Message-ID: <xmqqa5wjee25.fsf@gitster.g>
In-Reply-To: <CACmJb3xWh+0BR_V6sxfMK7iMSdWfvY9d2rjt1hnZhFw70zWweA@mail.gmail.com>

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

Show 15 quoted lines

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