Re: [PATCH/RFC v2 0/7] Introduce new commands switch-branch and checkout-files

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 29, 2018, 06:14 UTC
Message-ID: <xmqqwoowo1fk.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CAPL8ZivFJXQw=yLXjOPxsjabwN5XAP_qe0LK3sODO4NkgCjZag@mail.gmail.com>

Stefan Xenos <sxenos@google.com> writes:

> So - IMO - detaching should always be an explicit action. Some options
> that occur to me:
>
> git switch-branch --detach

That is the most obvious way to spell it, and it is why we have "git checkout --detach". If we were to split one half of "checkout" into "switch-branch", I would support the idea to make switch-branch only take a branch name and nothing else, allow it to take any commit-ish to detach the HEAD at that commit in the history graph with the --detach option". I also do not think anybody minds explaining the resulting state to be "on an unnamed branch" (or is it "the" unnamed branch? Given that HEAD@{} reflog is a singleton, perhaps the right mental model is that there is only one unnamed branch per worktree).

> git detach

The detached HEAD state is not all that special to deserve a separate command. After all, all history growing commands like "commit", "cherry-pick", "rebase", "merge", etc. work the same way on the unnamed branch.

> git switch-branch HEAD

I do not think this one is acceptable. "git checkout HEAD" does not detach but works as if you said "git checkout master" (when on the 'master' branch). And you do not want "git switch-branch HEAD^0" to be that explicit way to tell Git to detach the HEAD as that will take us back to square one ("git checkout HEAD^0" is the more concise and time-honored way to say "git checkout --detach HEAD").