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

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Feb 15, 2022, 20:37 UTC
Message-ID: <CAPig+cSY7E_XQC1gHzDJxoDGGmgWDmNz9Ys=CwbhLkCt+DQf-A@mail.gmail.com>
In-Reply-To: <11bf1541-c46a-fcf5-f8d4-0d144b942d59@gmail.com>

On Tue, Feb 8, 2022 at 9:34 PM Derrick Stolee <stolee@gmail.com> wrote:

Show 21 quoted lines

> On 2/8/2022 5:20 PM, Junio C Hamano wrote:
> > "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
> >> +extensions.worktreeConfig::
> >> +    If enabled, then worktrees will load config settings from the
> >> +    `$GIT_DIR/config.worktree` file in addition to the
> >> +    `$GIT_COMMON_DIR/config` file. Note that `$GIT_COMMON_DIR` and
> >> +    `$GIT_DIR` are the same for the main working tree, while other
> >> +    working trees have `$GIT_DIR` equal to
> >> +    `$GIT_COMMON_DIR/worktrees/<id>/`. The settings in the
> >
> > The mixed use of "worktree" and "working tree" in this paragraph
> > might confuse readers into thinking that the paragraph is being
> > careful to make distinction between the two.  All references to
> > "working tree" in the above paragraph should actually be "worktree",
> > I would think.
>
> 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).

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.