[PATCH 1/4] Documentation: use singular they when appropriate

["Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com>]

From: Derrick Stolee <dstolee@microsoft.com>

There are several instances in our documentation where we refer to an
anonymous user as "a contributor" or "an integrator" or similar. To
avoid repeating this role, pronouns are used. Previous examples
chose a gender for this user, using "he/him" or "she/her" arbitrarily.

Replace these uses with "they/them" to ensure that these documentation
examples apply to all potential users without exception.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
---
 Documentation/SubmittingPatches               |  2 +-
 Documentation/git-push.txt                    |  4 +-
 .../using-signed-tag-in-pull-request.txt      | 38 +++++++++----------
 Documentation/user-manual.txt                 |  2 +-
 4 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 55287d72e0ef..b518d3157f70 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -373,7 +373,7 @@ If you like, you can put extra tags at the end:
 . `Acked-by:` says that the person who is more familiar with the area
   the patch attempts to modify liked the patch.
 . `Reviewed-by:`, unlike the other tags, can only be offered by the
-  reviewer and means that she is completely satisfied that the patch
+  reviewer and means that they are completely satisfied that the patch
   is ready for application.  It is usually offered only after a
   detailed review.
 . `Tested-by:` is used to indicate that the person applied the patch
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index a953c7c38790..2f25aa3a291b 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -244,8 +244,8 @@ Imagine that you have to rebase what you have already published.
 You will have to bypass the "must fast-forward" rule in order to
 replace the history you originally published with the rebased history.
 If somebody else built on top of your original history while you are
-rebasing, the tip of the branch at the remote may advance with her
-commit, and blindly pushing with `--force` will lose her work.
+rebasing, the tip of the branch at the remote may advance with their
+commit, and blindly pushing with `--force` will lose their work.
 +
 This option allows you to say that you expect the history you are
 updating is what you rebased and want to replace. If the remote ref
diff --git a/Documentation/howto/using-signed-tag-in-pull-request.txt b/Documentation/howto/using-signed-tag-in-pull-request.txt
index bbf040eda8af..e9ad0b4ff8e0 100644
--- a/Documentation/howto/using-signed-tag-in-pull-request.txt
+++ b/Documentation/howto/using-signed-tag-in-pull-request.txt
@@ -1,8 +1,8 @@
 From: Junio C Hamano <gitster@pobox.com>
 Date: Tue, 17 Jan 2011 13:00:00 -0800
 Subject: Using signed tag in pull requests
-Abstract: Beginning v1.7.9, a contributor can push a signed tag to her
- publishing repository and ask her integrator to pull it. This assures the
+Abstract: Beginning v1.7.9, a contributor can push a signed tag to their
+ publishing repository and ask their integrator to pull it. This assures the
  integrator that the pulled history is authentic and allows others to
  later validate it.
 Content-type: text/asciidoc
@@ -11,9 +11,9 @@ How to use a signed tag in pull requests
 ========================================
 
 A typical distributed workflow using Git is for a contributor to fork a
-project, build on it, publish the result to her public repository, and ask
-the "upstream" person (often the owner of the project where she forked
-from) to pull from her public repository. Requesting such a "pull" is made
+project, build on it, publish the result to their public repository, and ask
+the "upstream" person (often the owner of the project where they forked
+from) to pull from their public repository. Requesting such a "pull" is made
 easy by the `git request-pull` command.
 
 Earlier, a typical pull request may have started like this:
@@ -32,7 +32,7 @@ followed by a shortlog of the changes and a diffstat.
 
 The request was for a branch name (e.g. `for-xyzzy`) in the public
 repository of the contributor, and even though it stated where the
-contributor forked her work from, the message did not say anything about
+contributor forked their work from, the message did not say anything about
 the commit to expect at the tip of the for-xyzzy branch. If the site that
 hosts the public repository of the contributor cannot be fully trusted, it
 was unnecessarily hard to make sure what was pulled by the integrator was
@@ -57,7 +57,7 @@ integrator, using Git v1.7.9 or later.
 A contributor or a lieutenant
 -----------------------------
 
-After preparing her work to be pulled, the contributor uses `git tag -s`
+After preparing their work to be pulled, the contributor uses `git tag -s`
 to create a signed tag:
 
 ------------
@@ -73,7 +73,7 @@ to justify why it is worthwhile for the integrator to pull it, as this
 message will eventually become part of the final history after the
 integrator responds to the pull request (as we will see later).
 
-Then she pushes the tag out to her public repository:
+Then they push the tag out to their public repository:
 
 ------------
  $ git push example.com:/git/froboz.git/ +frotz-for-xyzzy
@@ -94,10 +94,10 @@ The contributor then prepares a message to request a "pull":
 
 The arguments are:
 
-. the version of the integrator's commit the contributor based her work on;
-. the URL of the repository, to which the contributor has pushed what she
-  wants to get pulled; and
-. the name of the tag the contributor wants to get pulled (earlier, she could
+. the version of the integrator's commit the contributor based their work on;
+. the URL of the repository, to which the contributor has pushed what they
+  want to get pulled; and
+. the name of the tag the contributor wants to get pulled (earlier, they could
   write only a branch name here).
 
 The resulting msg.txt file begins like so:
@@ -130,7 +130,7 @@ command, the reader should notice that:
 
 The latter is why the contributor would want to justify why pulling her
 work is worthwhile when creating the signed tag.  The contributor then
-opens her favorite MUA, reads msg.txt, edits and sends it to her upstream
+opens their favorite MUA, reads msg.txt, edits and sends it to their upstream
 integrator.
 
 
@@ -163,20 +163,20 @@ In the editor, the integrator will see something like this:
 
 Notice that the message recorded in the signed tag "Completed frotz
 feature" appears here, and again that is why it is important for the
-contributor to explain her work well when creating the signed tag.
+contributor to explain their work well when creating the signed tag.
 
 As usual, the lines commented with `#` are stripped out. The resulting
 commit records the signed tag used for this validation in a hidden field
 so that it can later be used by others to audit the history. There is no
-need for the integrator to keep a separate copy of the tag in his
+need for the integrator to keep a separate copy of the tag in their
 repository (i.e. `git tag -l` won't list the `frotz-for-xyzzy` tag in the
-above example), and there is no need to publish the tag to his public
+above example), and there is no need to publish the tag to their public
 repository, either.
 
-After the integrator responds to the pull request and her work becomes
+After the integrator responds to the pull request and their work becomes
 part of the permanent history, the contributor can remove the tag from
-her public repository, if she chooses, in order to keep the tag namespace
-of her public repository clean, with:
+their public repository, if they choose, in order to keep the tag namespace
+of their public repository clean, with:
 
 ------------
  $ git push example.com:/git/froboz.git :frotz-for-xyzzy
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index f9e54b867417..4fe9be117c4a 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2792,7 +2792,7 @@ A fast-forward looks something like this:
 
 In some cases it is possible that the new head will *not* actually be
 a descendant of the old head.  For example, the developer may have
-realized she made a serious mistake, and decided to backtrack,
+realized they made a serious mistake, and decided to backtrack,
 resulting in a situation like:
 
 ................................................
-- 
gitgitgadget