Git fork

doc: git-checkout: deduplicate --detach explanation

From user feedback: several users say they don't understand the use case
for `--detach`. It's probably not realistic to explain the use case for
detached HEAD state here, but we can improve the situation.

Explain how `git checkout --detach` is different from
`git checkout <branch>` instead of copying over the description from
`git checkout <branch>`, since `git checkout <branch>` will be a
familiar command to many readers.

Signed-off-by: Julia Evans <julia@jvns.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

authored by

Julia Evans and committed by
Junio C Hamano
0dd71f60 042d6f34

+3 -10
+3 -10
Documentation/git-checkout.adoc
··· 66 66 `git checkout --detach [<branch>]`:: 67 67 `git checkout [--detach] <commit>`:: 68 68 69 - Prepare to work on top of _<commit>_, by detaching `HEAD` at it 70 - (see "DETACHED HEAD" section), and updating the index and the 71 - files in the working tree. Local modifications to the files 72 - in the working tree are kept, so that the resulting working 73 - tree will be the state recorded in the commit plus the local 74 - modifications. 75 - + 76 - When the _<commit>_ argument is a branch name, the `--detach` option can 77 - be used to detach `HEAD` at the tip of the branch (`git checkout 78 - <branch>` would check out that branch without detaching `HEAD`). 69 + The same as `git checkout <branch>`, except that instead of pointing 70 + `HEAD` at the branch, it points `HEAD` at the commit ID. 71 + See the "DETACHED HEAD" section below for more. 79 72 + 80 73 Omitting _<branch>_ detaches `HEAD` at the tip of the current branch. 81 74