git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: git@vger.kernel.org
Cc: "Duy Nguyen" <pclouds@gmail.com>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Taylor Blau" <me@ttaylorr.com>,
	"Martin Ågren" <martin.agren@gmail.com>,
	"Eric Sunshine" <sunshine@sunshineco.com>
Subject: [PATCH v2 2/5] git-worktree.txt: consistently use term "working tree"
Date: Mon,  3 Aug 2020 20:55:32 -0400	[thread overview]
Message-ID: <20200804005535.5126-3-sunshine@sunshineco.com> (raw)
In-Reply-To: <20200804005535.5126-1-sunshine@sunshineco.com>

As originally composed, git-worktree.txt employed a mix of "worktree"
and "working tree" which was inconsistent and potentially confusing to
readers. bc483285b7 (Documentation/git-worktree: consistently use term
"linked working tree", 2015-07-20) undertook the task of employing the
term "working tree" consistently throughout the document and avoiding
"worktree" altogether for descriptive text. Since that time, some
instances of "worktree" have crept back in. Continue the work of
bc483285b7 by transforming these to "working tree", as well.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
---
 Documentation/git-worktree.txt | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index f7c1bd34f8..926f4662ee 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -70,20 +70,20 @@ branches from there if `<branch>` is ambiguous but exists on the
 linkgit:git-config[1].
 +
 If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
-then, as a convenience, the new worktree is associated with a branch
+then, as a convenience, the new working tree is associated with a branch
 (call it `<branch>`) named after `$(basename <path>)`.  If `<branch>`
 doesn't exist, a new branch based on `HEAD` is automatically created as
 if `-b <branch>` was given.  If `<branch>` does exist, it will be
-checked out in the new worktree, if it's not checked out anywhere
-else, otherwise the command will refuse to create the worktree (unless
+checked out in the new working tree, if it's not checked out anywhere
+else, otherwise the command will refuse to create the working tree (unless
 `--force` is used).
 
 list::
 
-List details of each worktree.  The main worktree is listed first, followed by
-each of the linked worktrees.  The output details include if the worktree is
-bare, the revision currently checked out, and the branch currently checked out
-(or "detached HEAD" if none).
+List details of each working tree.  The main working tree is listed first,
+followed by each of the linked working trees.  The output details include
+if the working tree is bare, the revision currently checked out, and the
+branch currently checked out (or "detached HEAD" if none).
 
 lock::
 
@@ -202,7 +202,7 @@ This can also be set up as the default behaviour by using the
 	absolute.
 +
 If the last path components in the working tree's path is unique among
-working trees, it can be used to identify worktrees. For example if
+working trees, it can be used to identify working trees. For example if
 you only have two working trees, at `/abc/def/ghi` and `/abc/def/ggg`,
 then `ghi` or `def/ghi` is enough to point to the former working tree.
 
@@ -221,7 +221,7 @@ shared.
 
 Refs that are per working tree can still be accessed from another
 working tree via two special paths, `main-worktree` and `worktrees`. The
-former gives access to per-worktree refs of the main working tree,
+former gives access to per-working tree refs of the main working tree,
 while the latter to all linked working trees.
 
 For example, `main-worktree/HEAD` or `main-worktree/refs/bisect/good`
@@ -335,8 +335,8 @@ Porcelain Format
 The porcelain format has a line per attribute.  Attributes are listed with a
 label and value separated by a single space.  Boolean attributes (like `bare`
 and `detached`) are listed as a label only, and are only present if and only
-if the value is true.  The first attribute of a worktree is always `worktree`,
-an empty line indicates the end of the record.  For example:
+if the value is true.  The first attribute of a working tree is always
+`worktree`, an empty line indicates the end of the record.  For example:
 
 ------------
 $ git worktree list --porcelain
-- 
2.28.0.236.gb10cc79966


  parent reply	other threads:[~2020-08-04  0:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03  5:36 [PATCH 0/4] git-worktree documentation cleanups Eric Sunshine
2020-08-03  5:36 ` [PATCH 1/4] git-worktree.txt: employ fixed-width typeface consistently Eric Sunshine
2020-08-03  5:36 ` [PATCH 2/4] git-worktree.txt: consistently use term "working tree" Eric Sunshine
2020-08-03  5:36 ` [PATCH 3/4] git-worktree.txt: fix minor grammatical issues Eric Sunshine
2020-08-03  5:36 ` [PATCH 4/4] git-worktree.txt: make start of new sentence more obvious Eric Sunshine
2020-08-03 16:11 ` [PATCH 0/4] git-worktree documentation cleanups Taylor Blau
2020-08-03 17:14   ` Junio C Hamano
2020-08-03 17:57 ` Martin Ågren
2020-08-03 23:54   ` Eric Sunshine
2020-08-04  0:15     ` Junio C Hamano
2020-08-04  0:55 ` [PATCH v2 0/5] " Eric Sunshine
2020-08-04  0:55   ` [PATCH v2 1/5] git-worktree.txt: employ fixed-width typeface consistently Eric Sunshine
2020-08-04  0:55   ` Eric Sunshine [this message]
2020-08-04  0:55   ` [PATCH v2 3/5] git-worktree.txt: fix minor grammatical issues Eric Sunshine
2020-08-04  0:55   ` [PATCH v2 4/5] git-worktree.txt: make start of new sentence more obvious Eric Sunshine
2020-08-04  0:55   ` [PATCH v2 5/5] git-wortkree.txt: link to man pages when citing other Git commands Eric Sunshine
2020-08-04  1:10   ` [PATCH v2 0/5] git-worktree documentation cleanups Taylor Blau
2020-08-04  4:28   ` Martin Ågren
2020-08-04  4:44     ` Eric Sunshine
2020-08-04  5:23       ` Martin Ågren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200804005535.5126-3-sunshine@sunshineco.com \
    --to=sunshine@sunshineco.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=martin.agren@gmail.com \
    --cc=me@ttaylorr.com \
    --cc=pclouds@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).