Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx/ > > "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.
