freshlybakedca.ke
Git fork
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>
authored by
Jean-Noël Avila
and committed by
Junio C Hamano
3d26ec17
845c48a1
+121
-121
+7
-7
Documentation/config/checkout.adoc
+7
-7
Documentation/config/checkout.adoc
···
1
-
checkout.defaultRemote::
1
+
`checkout.defaultRemote`::
2
2
When you run `git checkout <something>`
3
3
or `git switch <something>` and only have one
4
4
remote, it may implicitly fall back on checking out and
5
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
7
reference. This setting allows for setting the name of a
8
8
preferred remote that should always win when it comes to
9
9
disambiguation. The typical use-case is to set this to
···
12
12
Currently this is used by linkgit:git-switch[1] and
13
13
linkgit:git-checkout[1] when `git checkout <something>`
14
14
or `git switch <something>`
15
-
will checkout the `<something>` branch on another remote,
15
+
will checkout the _<something>_ branch on another remote,
16
16
and by linkgit:git-worktree[1] when `git worktree add` refers to a
17
17
remote branch. This setting might be used for other checkout-like
18
18
commands or functionality in the future.
19
19
20
-
checkout.guess::
20
+
`checkout.guess`::
21
21
Provides the default value for the `--guess` or `--no-guess`
22
22
option in `git checkout` and `git switch`. See
23
23
linkgit:git-switch[1] and linkgit:git-checkout[1].
24
24
25
-
checkout.workers::
25
+
`checkout.workers`::
26
26
The number of parallel workers to use when updating the working tree.
27
27
The default is one, i.e. sequential execution. If set to a value less
28
28
than one, Git will use as many workers as the number of logical cores
···
30
30
all commands that perform checkout. E.g. checkout, clone, reset,
31
31
sparse-checkout, etc.
32
32
+
33
-
Note: Parallel checkout usually delivers better performance for repositories
33
+
NOTE: Parallel checkout usually delivers better performance for repositories
34
34
located on SSDs or over NFS. For repositories on spinning disks and/or machines
35
35
with a small number of cores, the default sequential checkout often performs
36
36
better. The size and compression level of a repository might also influence how
37
37
well the parallel version performs.
38
38
39
-
checkout.thresholdForParallelism::
39
+
`checkout.thresholdForParallelism`::
40
40
When running parallel checkout with a small number of files, the cost
41
41
of subprocess spawning and inter-process communication might outweigh
42
42
the parallelization gains. This setting allows you to define the minimum
+114
-114
Documentation/git-checkout.adoc
+114
-114
Documentation/git-checkout.adoc
···
7
7
8
8
SYNOPSIS
9
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
20
21
21
DESCRIPTION
22
22
-----------
23
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
25
also update `HEAD` to set the specified branch as the current
26
26
branch.
27
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
30
the index and the files in the working tree, and by pointing
31
31
`HEAD` at the branch. Local modifications to the files in the
32
32
working tree are kept, so that they can be committed to the
33
-
`<branch>`.
33
+
_<branch>_.
34
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
37
`--no-guess` is not specified, treat as equivalent to
38
38
+
39
39
------------
40
40
$ git checkout -b <branch> --track <remote>/<branch>
41
41
------------
42
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
44
"check out the current branch", which is a glorified no-op with
45
45
rather expensive side-effects to show only the tracking information,
46
46
if it exists, for the current branch.
47
47
48
-
'git checkout' -b|-B <new-branch> [<start-point>]::
48
+
`git checkout (-b|-B) <new-branch> [<start-point>]`::
49
49
50
50
Specifying `-b` causes a new branch to be created as if
51
51
linkgit:git-branch[1] were called and then checked out. In
52
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
54
`--track` without `-b` implies branch creation; see the
55
55
description of `--track` below.
56
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
58
is reset. This is the transactional equivalent of
59
59
+
60
60
------------
···
67
67
just the current branch stays the same, but the branch is not reset to
68
68
the start-point, either).
69
69
70
-
'git checkout' --detach [<branch>]::
71
-
'git checkout' [--detach] <commit>::
70
+
`git checkout --detach [<branch>]`::
71
+
`git checkout [--detach] <commit>`::
72
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
74
(see "DETACHED HEAD" section), and updating the index and the
75
75
files in the working tree. Local modifications to the files
76
76
in the working tree are kept, so that the resulting working
77
77
tree will be the state recorded in the commit plus the local
78
78
modifications.
79
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
81
be used to detach `HEAD` at the tip of the branch (`git checkout
82
82
<branch>` would check out that branch without detaching `HEAD`).
83
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
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
88
89
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
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
94
+
95
95
The index may contain unmerged entries because of a previous failed merge.
96
96
By default, if you try to check out such an entry from the index, the
···
100
100
using `--ours` or `--theirs`. With `-m`, changes made to the working tree
101
101
file can be discarded to re-create the original conflicted merge result.
102
102
103
-
'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]::
103
+
`git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...]`::
104
104
This is similar to the previous mode, but lets you use the
105
105
interactive interface to show the "diff" output and choose which
106
106
hunks to use in the result. See below for the description of
···
108
108
109
109
OPTIONS
110
110
-------
111
-
-q::
112
-
--quiet::
111
+
`-q`::
112
+
`--quiet`::
113
113
Quiet, suppress feedback messages.
114
114
115
-
--progress::
116
-
--no-progress::
115
+
`--progress`::
116
+
`--no-progress`::
117
117
Progress status is reported on the standard error stream
118
118
by default when it is attached to a terminal, unless `--quiet`
119
119
is specified. This flag enables progress reporting even if not
120
120
attached to a terminal, regardless of `--quiet`.
121
121
122
-
-f::
123
-
--force::
122
+
`-f`::
123
+
`--force`::
124
124
When switching branches, proceed even if the index or the
125
125
working tree differs from `HEAD`, and even if there are untracked
126
126
files in the way. This is used to throw away local changes and
···
129
129
When checking out paths from the index, do not fail upon unmerged
130
130
entries; instead, unmerged entries are ignored.
131
131
132
-
--ours::
133
-
--theirs::
132
+
`--ours`::
133
+
`--theirs`::
134
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
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
139
branch the changes are rebased onto, while `--theirs` gives the
140
140
version from the branch that holds your work that is being rebased.
141
141
+
···
149
149
on your side branch as `theirs` (i.e. "one contributor's work on top
150
150
of it").
151
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
155
see linkgit:git-branch[1] for details.
156
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
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
162
see linkgit:git-branch[1] for details.
163
163
164
-
-t::
165
-
--track[=(direct|inherit)]::
164
+
`-t`::
165
+
`--track[=(direct|inherit)]`::
166
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
168
+
169
169
If no `-b` option is given, the name of the new branch will be
170
170
derived from the remote-tracking branch, by looking at the local part of
···
176
176
guessing results in an empty name, the guessing is aborted. You can
177
177
explicitly give a name with `-b` in such a case.
178
178
179
-
--no-track::
179
+
`--no-track`::
180
180
Do not set up "upstream" configuration, even if the
181
181
`branch.autoSetupMerge` configuration variable is true.
182
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
187
matching name, treat as equivalent to
188
188
+
189
189
------------
···
192
192
+
193
193
If the branch exists in multiple remotes and one of them is named by
194
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
196
unique across all remotes. Set it to
197
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
199
'origin' remote. See also `checkout.defaultRemote` in
200
200
linkgit:git-config[1].
201
201
+
···
204
204
The default behavior can be set via the `checkout.guess` configuration
205
205
variable.
206
206
207
-
-l::
207
+
`-l`::
208
208
Create the new branch's reflog; see linkgit:git-branch[1] for
209
209
details.
210
210
211
-
-d::
212
-
--detach::
211
+
`-d`::
212
+
`--detach`::
213
213
Rather than checking out a branch to work on it, check out a
214
214
commit for inspection and discardable experiments.
215
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
217
below for details.
218
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
222
new branch will have no parents and it will be the root of a new
223
223
history totally disconnected from all the other branches and
224
224
commits.
225
225
+
226
226
The index and the working tree are adjusted as if you had previously run
227
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
229
`git commit -a` to make the root commit.
230
230
+
231
231
This can be useful when you want to publish the tree from a commit
···
235
235
code.
236
236
+
237
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
239
clear the index and the working tree right after creating the orphan
240
240
branch by running `git rm -rf .` from the top level of the working tree.
241
241
Afterwards you will be ready to prepare your new files, repopulating the
242
242
working tree, by copying them from elsewhere, extracting a tarball, etc.
243
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
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
249
250
-
-m::
251
-
--merge::
250
+
`-m`::
251
+
`--merge`::
252
252
When switching branches,
253
253
if you have local modifications to one or more files that
254
254
are different between the current branch and the branch to
···
269
269
+
270
270
When switching branches with `--merge`, staged changes may be lost.
271
271
272
-
--conflict=<style>::
272
+
`--conflict=<style>`::
273
273
The same as `--merge` option above, but changes the way the
274
274
conflicting hunks are presented, overriding the
275
275
`merge.conflictStyle` configuration variable. Possible values are
276
-
"merge" (default), "diff3", and "zdiff3".
276
+
`merge` (default), `diff3`, and `zdiff3`.
277
277
278
-
-p::
279
-
--patch::
278
+
`-p`::
279
+
`--patch`::
280
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
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
284
+
285
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
287
section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
288
288
+
289
289
Note that this option uses the no overlay mode by default (see also
290
290
`--overlay`), and currently doesn't support overlay mode.
291
291
292
-
--ignore-other-worktrees::
292
+
`--ignore-other-worktrees`::
293
293
`git checkout` refuses when the wanted branch is already checked
294
294
out or otherwise in use by another worktree. This option makes
295
295
it check the branch out anyway. In other words, the branch can
296
296
be in use by more than one worktree.
297
297
298
-
--overwrite-ignore::
299
-
--no-overwrite-ignore::
298
+
`--overwrite-ignore`::
299
+
`--no-overwrite-ignore`::
300
300
Silently overwrite ignored files when switching branches. This
301
301
is the default behavior. Use `--no-overwrite-ignore` to abort
302
302
the operation when the new branch contains ignored files.
303
303
304
-
--recurse-submodules::
305
-
--no-recurse-submodules::
304
+
`--recurse-submodules`::
305
+
`--no-recurse-submodules`::
306
306
Using `--recurse-submodules` will update the content of all active
307
307
submodules according to the commit recorded in the superproject. If
308
308
local modifications in a submodule would be overwritten the checkout
···
311
311
Just like linkgit:git-submodule[1], this will detach `HEAD` of the
312
312
submodule.
313
313
314
-
--overlay::
315
-
--no-overlay::
314
+
`--overlay`::
315
+
`--no-overlay`::
316
316
In the default overlay mode, `git checkout` never
317
317
removes files from the index or the working tree. When
318
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
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
326
quoted as explained for the configuration variable `core.quotePath`
327
327
(see linkgit:git-config[1]). See also `--pathspec-file-nul` and
328
328
global `--literal-pathspecs`.
329
329
330
-
--pathspec-file-nul::
330
+
`--pathspec-file-nul`::
331
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
333
literally (including newlines and quotes).
334
334
335
335
<branch>::
···
343
343
branch/commit checked out using "git checkout" operation. You may
344
344
also specify `-` which is synonymous to `@{-1}`.
345
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
349
350
-
<new-branch>::
350
+
_<new-branch>_::
351
351
Name for the new branch.
352
352
353
-
<start-point>::
353
+
_<start-point>_::
354
354
The name of a commit at which to start the new branch; see
355
355
linkgit:git-branch[1] for details. Defaults to `HEAD`.
356
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
360
361
-
<tree-ish>::
361
+
_<tree-ish>_::
362
362
Tree to checkout from (when paths are given). If not specified,
363
363
the index will be used.
364
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
368
369
-
\--::
369
+
`--`::
370
370
Do not interpret any more arguments as options.
371
371
372
-
<pathspec>...::
372
+
`<pathspec>...`::
373
373
Limits the paths affected by the operation.
374
374
+
375
375
For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
···
391
391
------------
392
392
393
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
395
parent is commit `c`, and then updates branch `master` to refer to new
396
396
commit `d`. `HEAD` still refers to branch `master` and so indirectly now refers
397
397
to commit `d`:
···
510
510
-----------------------
511
511
512
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
515
or a directory whose name is "abc" exists), Git would usually ask
516
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
518
in such a situation. Use `git checkout -- <pathspec>` if you want
519
519
to checkout these paths out of the index.
520
520