Documentation/git-worktree: consistently use term "linked working tree"
Sometimes linked working trees were called "linked working directories" or "linked worktrees". Always refer to them as "linked working trees" for consistency. [es: fix additional occurrences] Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Haggerty committed
Jul 20, 2015 at 01:29 UTC
bc483285b79c880b606bdffc0fffec3850458aca
2 files changed
+23
-23
Documentation/git-worktree.txt
+18
-18
@@ -3,7 +3,7 @@ git-worktree(1)
3
4
NAME
5
----
6
-git-worktree - Manage multiple worktrees
6
+git-worktree - Manage multiple working trees
7
8
9
SYNOPSIS
@@ -15,7 +15,7 @@ SYNOPSIS
15
DESCRIPTION
16
-----------
17
18
-Manage multiple worktrees attached to the same repository.
18
+Manage multiple working trees attached to the same repository.
19
20
A git repository can support multiple working trees, allowing you to check
21
out more than one branch at a time. With `git worktree add` a new working
@@ -31,9 +31,9 @@ The working tree's administrative files in the repository (see
31
`git worktree prune` in the main or any linked working tree to
32
clean up any stale administrative files.
33
34
-If you move a linked working directory to another file system, or
34
+If you move a linked working tree to another file system, or
35
within a file system that does not support hard links, you need to run
36
-at least one git command inside the linked working directory
36
+at least one git command inside the linked working tree
37
(e.g. `git status`) in order to update its administrative files in the
38
repository so that they do not get automatically pruned.
39
@@ -64,22 +64,22 @@ OPTIONS
64
65
-f::
66
--force::
67
- By default, `add` refuses to create a new worktree when `<branch>`
68
- is already checked out by another worktree. This option overrides
67
+ By default, `add` refuses to create a new working tree when `<branch>`
68
+ is already checked out by another working tree. This option overrides
69
that safeguard.
70
71
-b <new-branch>::
72
-B <new-branch>::
73
With `add`, create a new branch named `<new-branch>` starting at
74
- `<branch>`, and check out `<new-branch>` into the new worktree.
74
+ `<branch>`, and check out `<new-branch>` into the new working tree.
75
If `<branch>` is omitted, it defaults to HEAD.
76
By default, `-b` refuses to create a new branch if it already
77
exists. `-B` overrides this safeguard, resetting `<new-branch>` to
78
`<branch>`.
79
80
--detach::
81
- With `add`, detach HEAD in the new worktree. See "DETACHED HEAD" in
82
- linkgit:git-checkout[1].
81
+ With `add`, detach HEAD in the new working tree. See "DETACHED HEAD"
82
+ in linkgit:git-checkout[1].
83
84
-n::
85
--dry-run::
@@ -91,7 +91,7 @@ OPTIONS
91
With `prune`, report all removals.
92
93
--expire <time>::
94
- With `prune`, only expire unused worktrees older than <time>.
94
+ With `prune`, only expire unused working trees older than <time>.
95
96
DETAILS
97
-------
@@ -139,9 +139,9 @@ EXAMPLES
139
You are in the middle of a refactoring session and your boss comes in and
140
demands that you fix something immediately. You might typically use
141
linkgit:git-stash[1] to store your changes away temporarily, however, your
142
-worktree is in such a state of disarray (with new, moved, and removed files,
143
-and other bits and pieces strewn around) that you don't want to risk
144
-disturbing any of it. Instead, you create a temporary linked worktree to
142
+working tree is in such a state of disarray (with new, moved, and removed
143
+files, and other bits and pieces strewn around) that you don't want to risk
144
+disturbing any of it. Instead, you create a temporary linked working tree to
145
make the emergency fix, remove it when done, and then resume your earlier
146
refactoring session.
147
@@ -164,12 +164,12 @@ checkouts of a superproject.
164
git-worktree could provide more automation for tasks currently
165
performed manually, such as:
166
167
-- `remove` to remove a linked worktree and its administrative files (and
168
- warn if the worktree is dirty)
169
-- `mv` to move or rename a worktree and update its administrative files
170
-- `list` to list linked worktrees
167
+- `remove` to remove a linked working tree and its administrative files (and
168
+ warn if the working tree is dirty)
169
+- `mv` to move or rename a working tree and update its administrative files
170
+- `list` to list linked working trees
171
- `lock` to prevent automatic pruning of administrative files (for instance,
172
- for a worktree on a portable device)
172
+ for a working tree on a portable device)
173
174
GIT
175
---
Documentation/gitrepository-layout.txt
+5
-5
@@ -251,9 +251,9 @@ modules::
251
Contains the git-repositories of the submodules.
252
253
worktrees::
254
- Contains worktree specific information of linked
255
- checkouts. Each subdirectory contains the worktree-related
256
- part of a linked checkout. This directory is ignored if
254
+ Contains working tree specific information of linked
255
+ working trees. Each subdirectory contains the working tree-related
256
+ part of a linked working tree. This directory is ignored if
257
$GIT_COMMON_DIR is set and "$GIT_COMMON_DIR/worktrees" will be
258
used instead.
259
@@ -265,9 +265,9 @@ worktrees/<id>/gitdir::
265
updated every time the linked repository is accessed.
266
267
worktrees/<id>/locked::
268
- If this file exists, the linked repository may be on a
268
+ If this file exists, the linked working tree may be on a
269
portable device and not available. It does not mean that the
270
- linked repository is gone and `worktrees/<id>` could be
270
+ linked working tree is gone and `worktrees/<id>` could be
271
removed. The file's content contains a reason string on why
272
the repository is locked.
273