Re: [PATCH v6 1/6] Documentation: add extensions.worktreeConfig details

Eric Sunshine [off-list ref] writes:

quoted

I generally agree. This was changed in the most-recent re-roll
based on a request by Eric [1]. I'm happy to take whichever
version the two of you settle on.

[1] https://lore.kernel.org/git/CAPig+cS-3CxxyPGcy_vkeN_WYTRo1b-ZhJNdPy8ARZSNKkF1Xg@mail.gmail.com/ (local)

"request" is perhaps too strong a word considering that I led in with:

    A few minor comments, which can be addressed later or not
    at all, and likely are not worth holding up the series...

I mentioned "worktree vs. working tree" only to point out the
terminology inconsistency being introduced by the new patch; the same
sort of inconsistency which had bothered Michael Haggerty enough to do
something about it in bc483285b7 (Documentation/git-worktree:
consistently use term "linked working tree", 2015-07-20).

Yup, it seems both of us found mixed use of these two terms
disturbing.  Michael's old commit was mostly about "worktree" vs
"working tree", even though 2 changes among 13 changes to the file
were about updating "working directory" to "working tree", and to me
it seems to made the terminology straightened up.  E.g. a hunk from
the change uses "a linked working tree and its administrative files"

    -- `remove` to remove a linked worktree and its administrative files (and
    -  warn if the worktree is dirty)
    -- `mv` to move or rename a worktree and update its administrative files
    -- `list` to list linked worktrees
    +- `remove` to remove a linked working tree and its administrative files (and
    +  warn if the working tree is dirty)
    +- `mv` to move or rename a working tree and update its administrative files
    +- `list` to list linked working trees
     - `lock` to prevent automatic pruning of administrative files (for instance,
    -  for a worktree on a portable device)
    +  for a working tree on a portable device)

which clearly refers to things above .git as "working tree".

I, personally, prefer the term "worktree" for both convenience and
because it better encapsulates the overall "thing" which is
manipulated by the git-worktree command unlike the term "working tree"
which, as Junio points out, has (perhaps) a more narrow meaning. As
such, I would not be opposed to a patch series which changes "working
tree" to "worktree" in documentation where appropriate, but that's
outside the scope of this series.

I would welcome such changes where appropriate in both directions (I
think I updated a few places in the glossary).  I agree that this
topic is not a place to do so.