Namikaze Minato <LLoydsensei+git@xxxxxxxxx> 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.
