Namikaze Minato [off-list ref] 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.