bash prompt: combine 'git rev-parse' executions in the main code path
[gitweb.git] / Documentation / git-checkout.txt
index 6f04d22f5e15ea0805fb44c9c856952d759bc050..ca118ac6bfff9f837d06de37f99f457f6d38916b 100644 (file)
@@ -131,9 +131,9 @@ entries; instead, unmerged entries are ignored.
        "--track" in linkgit:git-branch[1] for details.
 +
 If no '-b' option is given, the name of the new branch will be
-derived from the remote-tracking branch.  If "remotes/" or "refs/remotes/"
-is prefixed it is stripped away, and then the part up to the
-next slash (which would be the nickname of the remote) is removed.
+derived from the remote-tracking branch, by looking at the local part of
+the refspec configured for the corresponding remote, and then stripping
+the initial part up to the "*".
 This would tell us to use "hack" as the local branch when branching
 off of "origin/hack" (or "remotes/origin/hack", or even
 "refs/remotes/origin/hack").  If the given name has no slash, or the above
@@ -180,6 +180,12 @@ branch by running "git rm -rf ." from the top level of the working tree.
 Afterwards you will be ready to prepare your new files, repopulating the
 working tree, by copying them from elsewhere, extracting a tarball, etc.
 
+--ignore-skip-worktree-bits::
+       In sparse checkout mode, `git checkout -- <paths>` would
+       update only entries matched by <paths> and sparse patterns
+       in $GIT_DIR/info/sparse-checkout. This option ignores
+       the sparse patterns and adds back any files in <paths>.
+
 -m::
 --merge::
        When switching branches,
@@ -333,7 +339,7 @@ a---b---c---d  branch 'master' (refers to commit 'd')
   tag 'v2.0' (refers to commit 'b')
 ------------
 
-In fact, we can perform all the normal git operations. But, let's look
+In fact, we can perform all the normal Git operations. But, let's look
 at what happens when we then checkout master:
 
 ------------
@@ -350,7 +356,7 @@ a---b---c---d  branch 'master' (refers to commit 'd')
 
 It is important to realize that at this point nothing refers to commit
 'f'. Eventually commit 'f' (and by extension commit 'e') will be deleted
-by the routine git garbage collection process, unless we create a reference
+by the routine Git garbage collection process, unless we create a reference
 before that happens. If we have not yet moved away from commit 'f',
 any of these will create a reference to it: