Re: git-switch history and checkout compatibility

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

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.