On Sun, Feb 20, 2022 at 05:54:27PM +0000, Derrick Stolee via GitGitGadget wrote: > @@ -404,14 +404,14 @@ $ git worktree list --verbose > /path/to/linked-worktree abcd1234 [master] > /path/to/locked-worktree-no-reason abcd5678 (detached HEAD) locked > /path/to/locked-worktree-with-reason 1234abcd (brancha) > - locked: working tree path is mounted on a portable device > + locked: worktree path is mounted on a portable device I thought this might have been an over-zealous find-and-replace, since I had assumed that the "locked: working tree path ..." message came from Git. But my assumption was wrong, and this is the `<reason>` in `git worktree --reason=<reason> <worktree>`. So it makes sense to update here along with the rest of these other instances. > /path/to/prunable-worktree 5678abc1 (detached HEAD) > prunable: gitdir file points to non-existent location > ------------ > > Note that the annotation is moved to the next line if the additional > information is available, otherwise it stays on the same line as the > -working tree itself. > +worktree itself. > > Porcelain Format > ~~~~~~~~~~~~~~~~ > @@ -420,7 +420,7 @@ label and value separated by a single space. Boolean attributes (like `bare` > and `detached`) are listed as a label only, and are present only > if the value is true. Some attributes (like `locked`) can be listed as a label > only or with a value depending upon whether a reason is available. The first > -attribute of a working tree is always `worktree`, an empty line indicates the > +attribute of a worktree is always `worktree`, an empty line indicates the > end of the record. For example: > > ------------ > @@ -470,9 +470,9 @@ EXAMPLES > You are in the middle of a refactoring session and your boss comes in and > demands that you fix something immediately. You might typically use > linkgit:git-stash[1] to store your changes away temporarily, however, your > -working tree is in such a state of disarray (with new, moved, and removed > +worktree is in such a state of disarray (with new, moved, and removed This one should probably remain as "working tree", since the example being given here is focused on disarray in the working tree itself, not in the worktree's metadata. > files, and other bits and pieces strewn around) that you don't want to risk > -disturbing any of it. Instead, you create a temporary linked working tree to > +disturbing any of it. Instead, you create a temporary linked worktree to > make the emergency fix, remove it when done, and then resume your earlier > refactoring session. But this one is in the context of "create a _worktree_", which makes sense and should probably be updated as you have done here. Thanks, Taylor
