Re: [PATCH 11/11] worktree: use 'worktree' over 'working tree'

> 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.