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

[Junio C Hamano <gitster@pobox.com>]

Eric Sunshine <sunshine@sunshineco.com> writes:

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