worktree: use 'worktree' over 'working tree'
It is helpful to distinguish between a 'working tree' and a 'worktree'. A worktree contains a working tree plus additional metadata. This metadata includes per-worktree refs and worktree-specific config. This is the third of multiple changes to git-worktree.txt, restricted to the OPTIONS section. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Derrick Stolee committed
Feb 23, 2022 at 14:29 UTC
6036be14581878c42158407a9f3344d63f090057
1 file changed
+21
-21
Documentation/git-worktree.txt
+21
-21
@@ -160,25 +160,25 @@ OPTIONS
160
161
-f::
162
--force::
163
- By default, `add` refuses to create a new working tree when
163
+ By default, `add` refuses to create a new worktree when
164
`<commit-ish>` is a branch name and is already checked out by
165
- another working tree, or if `<path>` is already assigned to some
166
- working tree but is missing (for instance, if `<path>` was deleted
165
+ another worktree, or if `<path>` is already assigned to some
166
+ worktree but is missing (for instance, if `<path>` was deleted
167
manually). This option overrides these safeguards. To add a missing but
168
- locked working tree path, specify `--force` twice.
168
+ locked worktree path, specify `--force` twice.
169
+
170
-`move` refuses to move a locked working tree unless `--force` is specified
171
-twice. If the destination is already assigned to some other working tree but is
170
+`move` refuses to move a locked worktree unless `--force` is specified
171
+twice. If the destination is already assigned to some other worktree but is
172
missing (for instance, if `<new-path>` was deleted manually), then `--force`
173
allows the move to proceed; use `--force` twice if the destination is locked.
174
+
175
-`remove` refuses to remove an unclean working tree unless `--force` is used.
176
-To remove a locked working tree, specify `--force` twice.
175
+`remove` refuses to remove an unclean worktree unless `--force` is used.
176
+To remove a locked worktree, specify `--force` twice.
177
178
-b <new-branch>::
179
-B <new-branch>::
180
With `add`, create a new branch named `<new-branch>` starting at
181
- `<commit-ish>`, and check out `<new-branch>` into the new working tree.
181
+ `<commit-ish>`, and check out `<new-branch>` into the new worktree.
182
If `<commit-ish>` is omitted, it defaults to `HEAD`.
183
By default, `-b` refuses to create a new branch if it already
184
exists. `-B` overrides this safeguard, resetting `<new-branch>` to
@@ -186,7 +186,7 @@ To remove a locked working tree, specify `--force` twice.
186
187
-d::
188
--detach::
189
- With `add`, detach `HEAD` in the new working tree. See "DETACHED HEAD"
189
+ With `add`, detach `HEAD` in the new worktree. See "DETACHED HEAD"
190
in linkgit:git-checkout[1].
191
192
--[no-]checkout::
@@ -212,7 +212,7 @@ This can also be set up as the default behaviour by using the
212
`--track` in linkgit:git-branch[1] for details.
213
214
--lock::
215
- Keep the working tree locked after creation. This is the
215
+ Keep the worktree locked after creation. This is the
216
equivalent of `git worktree lock` after `git worktree add`,
217
but without a race condition.
218
@@ -237,22 +237,22 @@ This can also be set up as the default behaviour by using the
237
With `list`, output additional information about worktrees (see below).
238
239
--expire <time>::
240
- With `prune`, only expire unused working trees older than `<time>`.
240
+ With `prune`, only expire unused worktrees older than `<time>`.
241
+
242
-With `list`, annotate missing working trees as prunable if they are
243
-older than `<time>`.
242
+With `list`, annotate missing worktrees as prunable if they are older than
243
+`<time>`.
244
245
--reason <string>::
246
- With `lock` or with `add --lock`, an explanation why the working tree is locked.
246
+ With `lock` or with `add --lock`, an explanation why the worktree
247
+ is locked.
248
249
<worktree>::
249
- Working trees can be identified by path, either relative or
250
- absolute.
250
+ Worktrees can be identified by path, either relative or absolute.
251
+
252
-If the last path components in the working tree's path is unique among
253
-working trees, it can be used to identify a working tree. For example if
254
-you only have two working trees, at `/abc/def/ghi` and `/abc/def/ggg`,
255
-then `ghi` or `def/ghi` is enough to point to the former working tree.
252
+If the last path components in the worktree's path is unique among
253
+worktrees, it can be used to identify a worktree. For example if you only
254
+have two worktrees, at `/abc/def/ghi` and `/abc/def/ggg`, then `ghi` or
255
+`def/ghi` is enough to point to the former worktree.
256
257
REFS
258
----