doc: convert git-checkout manpage to new style
- Switch the synopsis to a synopsis block which will automatically format placeholders in italics and keywords in monospace - Use _<placeholder>_ instead of <placeholder> in the description - Use `backticks` for keywords and more complex option descriptions. The new rendering engine will apply synopsis rules to these spans. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jean-Noël Avila committed
May 25, 2025 at 20:27 UTC
3d26ec171567ef205648380fb621ab0369f910e1
2 files changed
+121
-121
Documentation/config/checkout.adoc
+7
-7
@@ -1,9 +1,9 @@
1
-checkout.defaultRemote::
1
+`checkout.defaultRemote`::
2
When you run `git checkout <something>`
3
or `git switch <something>` and only have one
4
remote, it may implicitly fall back on checking out and
5
tracking e.g. `origin/<something>`. This stops working as soon
6
- as you have more than one remote with a `<something>`
6
+ as you have more than one remote with a _<something>_
7
reference. This setting allows for setting the name of a
8
preferred remote that should always win when it comes to
9
disambiguation. The typical use-case is to set this to
@@ -12,17 +12,17 @@ checkout.defaultRemote::
12
Currently this is used by linkgit:git-switch[1] and
13
linkgit:git-checkout[1] when `git checkout <something>`
14
or `git switch <something>`
15
-will checkout the `<something>` branch on another remote,
15
+will checkout the _<something>_ branch on another remote,
16
and by linkgit:git-worktree[1] when `git worktree add` refers to a
17
remote branch. This setting might be used for other checkout-like
18
commands or functionality in the future.
19
20
-checkout.guess::
20
+`checkout.guess`::
21
Provides the default value for the `--guess` or `--no-guess`
22
option in `git checkout` and `git switch`. See
23
linkgit:git-switch[1] and linkgit:git-checkout[1].
24
25
-checkout.workers::
25
+`checkout.workers`::
26
The number of parallel workers to use when updating the working tree.
27
The default is one, i.e. sequential execution. If set to a value less
28
than one, Git will use as many workers as the number of logical cores
@@ -30,13 +30,13 @@ checkout.workers::
30
all commands that perform checkout. E.g. checkout, clone, reset,
31
sparse-checkout, etc.
32
+
33
-Note: Parallel checkout usually delivers better performance for repositories
33
+NOTE: Parallel checkout usually delivers better performance for repositories
34
located on SSDs or over NFS. For repositories on spinning disks and/or machines
35
with a small number of cores, the default sequential checkout often performs
36
better. The size and compression level of a repository might also influence how
37
well the parallel version performs.
38
39
-checkout.thresholdForParallelism::
39
+`checkout.thresholdForParallelism`::
40
When running parallel checkout with a small number of files, the cost
41
of subprocess spawning and inter-process communication might outweigh
42
the parallelization gains. This setting allows you to define the minimum
Documentation/git-checkout.adoc
+114
-114
@@ -7,54 +7,54 @@ git-checkout - Switch branches or restore working tree files
7
8
SYNOPSIS
9
--------
10
-[verse]
11
-'git checkout' [-q] [-f] [-m] [<branch>]
12
-'git checkout' [-q] [-f] [-m] --detach [<branch>]
13
-'git checkout' [-q] [-f] [-m] [--detach] <commit>
14
-'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new-branch>] [<start-point>]
15
-'git checkout' [-f] <tree-ish> [--] <pathspec>...
16
-'git checkout' [-f] <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul]
17
-'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [--] <pathspec>...
18
-'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<file> [--pathspec-file-nul]
19
-'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]
10
+[synopsis]
11
+git checkout [-q] [-f] [-m] [<branch>]
12
+git checkout [-q] [-f] [-m] --detach [<branch>]
13
+git checkout [-q] [-f] [-m] [--detach] <commit>
14
+git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new-branch>] [<start-point>]
15
+git checkout [-f] <tree-ish> [--] <pathspec>...
16
+git checkout [-f] <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul]
17
+git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [--] <pathspec>...
18
+git checkout [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<file> [--pathspec-file-nul]
19
+git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...]
20
21
DESCRIPTION
22
-----------
23
Updates files in the working tree to match the version in the index
24
-or the specified tree. If no pathspec was given, 'git checkout' will
24
+or the specified tree. If no pathspec was given, `git checkout` will
25
also update `HEAD` to set the specified branch as the current
26
branch.
27
28
-'git checkout' [<branch>]::
29
- To prepare for working on `<branch>`, switch to it by updating
28
+`git checkout [<branch>]`::
29
+ To prepare for working on _<branch>_, switch to it by updating
30
the index and the files in the working tree, and by pointing
31
`HEAD` at the branch. Local modifications to the files in the
32
working tree are kept, so that they can be committed to the
33
- `<branch>`.
33
+ _<branch>_.
34
+
35
-If `<branch>` is not found but there does exist a tracking branch in
36
-exactly one remote (call it `<remote>`) with a matching name and
35
+If _<branch>_ is not found but there does exist a tracking branch in
36
+exactly one remote (call it _<remote>_) with a matching name and
37
`--no-guess` is not specified, treat as equivalent to
38
+
39
------------
40
$ git checkout -b <branch> --track <remote>/<branch>
41
------------
42
+
43
-You could omit `<branch>`, in which case the command degenerates to
43
+You could omit _<branch>_, in which case the command degenerates to
44
"check out the current branch", which is a glorified no-op with
45
rather expensive side-effects to show only the tracking information,
46
if it exists, for the current branch.
47
48
-'git checkout' -b|-B <new-branch> [<start-point>]::
48
+`git checkout (-b|-B) <new-branch> [<start-point>]`::
49
50
Specifying `-b` causes a new branch to be created as if
51
linkgit:git-branch[1] were called and then checked out. In
52
this case you can use the `--track` or `--no-track` options,
53
- which will be passed to 'git branch'. As a convenience,
53
+ which will be passed to `git branch`. As a convenience,
54
`--track` without `-b` implies branch creation; see the
55
description of `--track` below.
56
+
57
-If `-B` is given, `<new-branch>` is created if it doesn't exist; otherwise, it
57
+If `-B` is given, _<new-branch>_ is created if it doesn't exist; otherwise, it
58
is reset. This is the transactional equivalent of
59
+
60
------------
@@ -67,30 +67,30 @@ successful (e.g., when the branch is in use in another worktree, not
67
just the current branch stays the same, but the branch is not reset to
68
the start-point, either).
69
70
-'git checkout' --detach [<branch>]::
71
-'git checkout' [--detach] <commit>::
70
+`git checkout --detach [<branch>]`::
71
+`git checkout [--detach] <commit>`::
72
73
- Prepare to work on top of `<commit>`, by detaching `HEAD` at it
73
+ Prepare to work on top of _<commit>_, by detaching `HEAD` at it
74
(see "DETACHED HEAD" section), and updating the index and the
75
files in the working tree. Local modifications to the files
76
in the working tree are kept, so that the resulting working
77
tree will be the state recorded in the commit plus the local
78
modifications.
79
+
80
-When the `<commit>` argument is a branch name, the `--detach` option can
80
+When the _<commit>_ argument is a branch name, the `--detach` option can
81
be used to detach `HEAD` at the tip of the branch (`git checkout
82
<branch>` would check out that branch without detaching `HEAD`).
83
+
84
-Omitting `<branch>` detaches `HEAD` at the tip of the current branch.
84
+Omitting _<branch>_ detaches `HEAD` at the tip of the current branch.
85
86
-'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>...::
87
-'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]::
86
+`git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>...`::
87
+`git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]`::
88
89
Overwrite the contents of the files that match the pathspec.
90
- When the `<tree-ish>` (most often a commit) is not given,
90
+ When the _<tree-ish>_ (most often a commit) is not given,
91
overwrite working tree with the contents in the index.
92
- When the `<tree-ish>` is given, overwrite both the index and
93
- the working tree with the contents at the `<tree-ish>`.
92
+ When the _<tree-ish>_ is given, overwrite both the index and
93
+ the working tree with the contents at the _<tree-ish>_.
94
+
95
The index may contain unmerged entries because of a previous failed merge.
96
By default, if you try to check out such an entry from the index, the
@@ -100,7 +100,7 @@ specific side of the merge can be checked out of the index by
100
using `--ours` or `--theirs`. With `-m`, changes made to the working tree
101
file can be discarded to re-create the original conflicted merge result.
102
103
-'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]::
103
+`git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...]`::
104
This is similar to the previous mode, but lets you use the
105
interactive interface to show the "diff" output and choose which
106
hunks to use in the result. See below for the description of
@@ -108,19 +108,19 @@ file can be discarded to re-create the original conflicted merge result.
108
109
OPTIONS
110
-------
111
--q::
112
---quiet::
111
+`-q`::
112
+`--quiet`::
113
Quiet, suppress feedback messages.
114
115
---progress::
116
---no-progress::
115
+`--progress`::
116
+`--no-progress`::
117
Progress status is reported on the standard error stream
118
by default when it is attached to a terminal, unless `--quiet`
119
is specified. This flag enables progress reporting even if not
120
attached to a terminal, regardless of `--quiet`.
121
122
--f::
123
---force::
122
+`-f`::
123
+`--force`::
124
When switching branches, proceed even if the index or the
125
working tree differs from `HEAD`, and even if there are untracked
126
files in the way. This is used to throw away local changes and
@@ -129,13 +129,13 @@ OPTIONS
129
When checking out paths from the index, do not fail upon unmerged
130
entries; instead, unmerged entries are ignored.
131
132
---ours::
133
---theirs::
132
+`--ours`::
133
+`--theirs`::
134
When checking out paths from the index, check out stage #2
135
- ('ours') or #3 ('theirs') for unmerged paths.
135
+ (`ours`) or #3 (`theirs`) for unmerged paths.
136
+
137
-Note that during `git rebase` and `git pull --rebase`, 'ours' and
138
-'theirs' may appear swapped; `--ours` gives the version from the
137
+Note that during `git rebase` and `git pull --rebase`, `ours` and
138
+`theirs` may appear swapped; `--ours` gives the version from the
139
branch the changes are rebased onto, while `--theirs` gives the
140
version from the branch that holds your work that is being rebased.
141
+
@@ -149,22 +149,22 @@ as `ours` (i.e. "our shared canonical history"), while what you did
149
on your side branch as `theirs` (i.e. "one contributor's work on top
150
of it").
151
152
--b <new-branch>::
153
- Create a new branch named `<new-branch>`, start it at
154
- `<start-point>`, and check the resulting branch out;
152
+`-b <new-branch>`::
153
+ Create a new branch named _<new-branch>_, start it at
154
+ _<start-point>_, and check the resulting branch out;
155
see linkgit:git-branch[1] for details.
156
157
--B <new-branch>::
158
- Creates the branch `<new-branch>`, start it at `<start-point>`;
159
- if it already exists, then reset it to `<start-point>`. And then
157
+`-B <new-branch>`::
158
+ Creates the branch _<new-branch>_, start it at _<start-point>_;
159
+ if it already exists, then reset it to _<start-point>_. And then
160
check the resulting branch out. This is equivalent to running
161
- "git branch" with "-f" followed by "git checkout" of that branch;
161
+ `git branch` with `-f` followed by `git checkout` of that branch;
162
see linkgit:git-branch[1] for details.
163
164
--t::
165
---track[=(direct|inherit)]::
164
+`-t`::
165
+`--track[=(direct|inherit)]`::
166
When creating a new branch, set up "upstream" configuration. See
167
- "--track" in linkgit:git-branch[1] for details.
167
+ `--track` in linkgit:git-branch[1] for details.
168
+
169
If no `-b` option is given, the name of the new branch will be
170
derived from the remote-tracking branch, by looking at the local part of
@@ -176,14 +176,14 @@ off of `origin/hack` (or `remotes/origin/hack`, or even
176
guessing results in an empty name, the guessing is aborted. You can
177
explicitly give a name with `-b` in such a case.
178
179
---no-track::
179
+`--no-track`::
180
Do not set up "upstream" configuration, even if the
181
`branch.autoSetupMerge` configuration variable is true.
182
183
---guess::
184
---no-guess::
185
- If `<branch>` is not found but there does exist a tracking
186
- branch in exactly one remote (call it `<remote>`) with a
183
+`--guess`::
184
+`--no-guess`::
185
+ If _<branch>_ is not found but there does exist a tracking
186
+ branch in exactly one remote (call it _<remote>_) with a
187
matching name, treat as equivalent to
188
+
189
------------
@@ -192,10 +192,10 @@ $ git checkout -b <branch> --track <remote>/<branch>
192
+
193
If the branch exists in multiple remotes and one of them is named by
194
the `checkout.defaultRemote` configuration variable, we'll use that
195
-one for the purposes of disambiguation, even if the `<branch>` isn't
195
+one for the purposes of disambiguation, even if the _<branch>_ isn't
196
unique across all remotes. Set it to
197
e.g. `checkout.defaultRemote=origin` to always checkout remote
198
-branches from there if `<branch>` is ambiguous but exists on the
198
+branches from there if _<branch>_ is ambiguous but exists on the
199
'origin' remote. See also `checkout.defaultRemote` in
200
linkgit:git-config[1].
201
+
@@ -204,28 +204,28 @@ linkgit:git-config[1].
204
The default behavior can be set via the `checkout.guess` configuration
205
variable.
206
207
--l::
207
+`-l`::
208
Create the new branch's reflog; see linkgit:git-branch[1] for
209
details.
210
211
--d::
212
---detach::
211
+`-d`::
212
+`--detach`::
213
Rather than checking out a branch to work on it, check out a
214
commit for inspection and discardable experiments.
215
This is the default behavior of `git checkout <commit>` when
216
- `<commit>` is not a branch name. See the "DETACHED HEAD" section
216
+ _<commit>_ is not a branch name. See the "DETACHED HEAD" section
217
below for details.
218
219
---orphan <new-branch>::
220
- Create a new unborn branch, named `<new-branch>`, started from
221
- `<start-point>` and switch to it. The first commit made on this
219
+`--orphan <new-branch>`::
220
+ Create a new unborn branch, named _<new-branch>_, started from
221
+ _<start-point>_ and switch to it. The first commit made on this
222
new branch will have no parents and it will be the root of a new
223
history totally disconnected from all the other branches and
224
commits.
225
+
226
The index and the working tree are adjusted as if you had previously run
227
`git checkout <start-point>`. This allows you to start a new history
228
-that records a set of paths similar to `<start-point>` by easily running
228
+that records a set of paths similar to _<start-point>_ by easily running
229
`git commit -a` to make the root commit.
230
+
231
This can be useful when you want to publish the tree from a commit
@@ -235,20 +235,20 @@ whose full history contains proprietary or otherwise encumbered bits of
235
code.
236
+
237
If you want to start a disconnected history that records a set of paths
238
-that is totally different from the one of `<start-point>`, then you should
238
+that is totally different from the one of _<start-point>_, then you should
239
clear the index and the working tree right after creating the orphan
240
branch by running `git rm -rf .` from the top level of the working tree.
241
Afterwards you will be ready to prepare your new files, repopulating the
242
working tree, by copying them from elsewhere, extracting a tarball, etc.
243
244
---ignore-skip-worktree-bits::
245
- In sparse checkout mode, `git checkout -- <paths>` would
246
- update only entries matched by `<paths>` and sparse patterns
244
+`--ignore-skip-worktree-bits`::
245
+ In sparse checkout mode, `git checkout -- <path>...` would
246
+ update only entries matched by _<paths>_ and sparse patterns
247
in `$GIT_DIR/info/sparse-checkout`. This option ignores
248
- the sparse patterns and adds back any files in `<paths>`.
248
+ the sparse patterns and adds back any files in `<path>...`.
249
250
--m::
251
---merge::
250
+`-m`::
251
+`--merge`::
252
When switching branches,
253
if you have local modifications to one or more files that
254
are different between the current branch and the branch to
@@ -269,40 +269,40 @@ used when checking out paths from a tree-ish.
269
+
270
When switching branches with `--merge`, staged changes may be lost.
271
272
---conflict=<style>::
272
+`--conflict=<style>`::
273
The same as `--merge` option above, but changes the way the
274
conflicting hunks are presented, overriding the
275
`merge.conflictStyle` configuration variable. Possible values are
276
- "merge" (default), "diff3", and "zdiff3".
276
+ `merge` (default), `diff3`, and `zdiff3`.
277
278
--p::
279
---patch::
278
+`-p`::
279
+`--patch`::
280
Interactively select hunks in the difference between the
281
- `<tree-ish>` (or the index, if unspecified) and the working
281
+ _<tree-ish>_ (or the index, if unspecified) and the working
282
tree. The chosen hunks are then applied in reverse to the
283
- working tree (and if a `<tree-ish>` was specified, the index).
283
+ working tree (and if a _<tree-ish>_ was specified, the index).
284
+
285
This means that you can use `git checkout -p` to selectively discard
286
-edits from your current working tree. See the ``Interactive Mode''
286
+edits from your current working tree. See the "Interactive Mode"
287
section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
288
+
289
Note that this option uses the no overlay mode by default (see also
290
`--overlay`), and currently doesn't support overlay mode.
291
292
---ignore-other-worktrees::
292
+`--ignore-other-worktrees`::
293
`git checkout` refuses when the wanted branch is already checked
294
out or otherwise in use by another worktree. This option makes
295
it check the branch out anyway. In other words, the branch can
296
be in use by more than one worktree.
297
298
---overwrite-ignore::
299
---no-overwrite-ignore::
298
+`--overwrite-ignore`::
299
+`--no-overwrite-ignore`::
300
Silently overwrite ignored files when switching branches. This
301
is the default behavior. Use `--no-overwrite-ignore` to abort
302
the operation when the new branch contains ignored files.
303
304
---recurse-submodules::
305
---no-recurse-submodules::
304
+`--recurse-submodules`::
305
+`--no-recurse-submodules`::
306
Using `--recurse-submodules` will update the content of all active
307
submodules according to the commit recorded in the superproject. If
308
local modifications in a submodule would be overwritten the checkout
@@ -311,25 +311,25 @@ Note that this option uses the no overlay mode by default (see also
311
Just like linkgit:git-submodule[1], this will detach `HEAD` of the
312
submodule.
313
314
---overlay::
315
---no-overlay::
314
+`--overlay`::
315
+`--no-overlay`::
316
In the default overlay mode, `git checkout` never
317
removes files from the index or the working tree. When
318
specifying `--no-overlay`, files that appear in the index and
319
- working tree, but not in `<tree-ish>` are removed, to make them
320
- match `<tree-ish>` exactly.
319
+ working tree, but not in _<tree-ish>_ are removed, to make them
320
+ match _<tree-ish>_ exactly.
321
322
---pathspec-from-file=<file>::
323
- Pathspec is passed in `<file>` instead of commandline args. If
324
- `<file>` is exactly `-` then standard input is used. Pathspec
325
- elements are separated by LF or CR/LF. Pathspec elements can be
322
+`--pathspec-from-file=<file>`::
323
+ Pathspec is passed in _<file>_ instead of commandline args. If
324
+ _<file>_ is exactly `-` then standard input is used. Pathspec
325
+ elements are separated by _LF_ or _CR_/_LF_. Pathspec elements can be
326
quoted as explained for the configuration variable `core.quotePath`
327
(see linkgit:git-config[1]). See also `--pathspec-file-nul` and
328
global `--literal-pathspecs`.
329
330
---pathspec-file-nul::
330
+`--pathspec-file-nul`::
331
Only meaningful with `--pathspec-from-file`. Pathspec elements are
332
- separated with NUL character and all other characters are taken
332
+ separated with _NUL_ character and all other characters are taken
333
literally (including newlines and quotes).
334
335
<branch>::
@@ -343,33 +343,33 @@ You can use the `@{-N}` syntax to refer to the N-th last
343
branch/commit checked out using "git checkout" operation. You may
344
also specify `-` which is synonymous to `@{-1}`.
345
+
346
-As a special case, you may use `A...B` as a shortcut for the
347
-merge base of `A` and `B` if there is exactly one merge base. You can
348
-leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
346
+As a special case, you may use `<rev-a>...<rev-b>` as a shortcut for the
347
+merge base of _<rev-a>_ and _<rev-b>_ if there is exactly one merge base. You can
348
+leave out at most one of _<rev-a>_ and _<rev-b>_, in which case it defaults to `HEAD`.
349
350
-<new-branch>::
350
+_<new-branch>_::
351
Name for the new branch.
352
353
-<start-point>::
353
+_<start-point>_::
354
The name of a commit at which to start the new branch; see
355
linkgit:git-branch[1] for details. Defaults to `HEAD`.
356
+
357
-As a special case, you may use `"A...B"` as a shortcut for the
358
-merge base of `A` and `B` if there is exactly one merge base. You can
359
-leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
357
+As a special case, you may use `<rev-a>...<rev-b>` as a shortcut for the
358
+merge base of _<rev-a>_ and _<rev-b>_ if there is exactly one merge base. You can
359
+leave out at most one of _<rev-a>_ and _<rev-b>_, in which case it defaults to `HEAD`.
360
361
-<tree-ish>::
361
+_<tree-ish>_::
362
Tree to checkout from (when paths are given). If not specified,
363
the index will be used.
364
+
365
-As a special case, you may use `"A...B"` as a shortcut for the
366
-merge base of `A` and `B` if there is exactly one merge base. You can
367
-leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
365
+As a special case, you may use `<rev-a>...<rev-b>` as a shortcut for the
366
+merge base of _<rev-a>_ and _<rev-b>_ if there is exactly one merge base. You can
367
+leave out at most one of _<rev-a>_ and _<rev-b>_, in which case it defaults to `HEAD`.
368
369
-\--::
369
+`--`::
370
Do not interpret any more arguments as options.
371
372
-<pathspec>...::
372
+`<pathspec>...`::
373
Limits the paths affected by the operation.
374
+
375
For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
@@ -391,7 +391,7 @@ a---b---c branch 'master' (refers to commit 'c')
391
------------
392
393
When a commit is created in this state, the branch is updated to refer to
394
-the new commit. Specifically, 'git commit' creates a new commit `d`, whose
394
+the new commit. Specifically, `git commit` creates a new commit `d`, whose
395
parent is commit `c`, and then updates branch `master` to refer to new
396
commit `d`. `HEAD` still refers to branch `master` and so indirectly now refers
397
to commit `d`:
@@ -510,11 +510,11 @@ ARGUMENT DISAMBIGUATION
510
-----------------------
511
512
When there is only one argument given and it is not `--` (e.g. `git
513
-checkout abc`), and when the argument is both a valid `<tree-ish>`
514
-(e.g. a branch `abc` exists) and a valid `<pathspec>` (e.g. a file
513
+checkout abc`), and when the argument is both a valid _<tree-ish>_
514
+(e.g. a branch `abc` exists) and a valid _<pathspec>_ (e.g. a file
515
or a directory whose name is "abc" exists), Git would usually ask
516
you to disambiguate. Because checking out a branch is so common an
517
-operation, however, `git checkout abc` takes "abc" as a `<tree-ish>`
517
+operation, however, `git checkout abc` takes "abc" as a _<tree-ish>_
518
in such a situation. Use `git checkout -- <pathspec>` if you want
519
to checkout these paths out of the index.
520