[PATCH 0/6] doc: replace "alice" and "bob" examples

I suggested in [1] that the "alice" and "bob" examples in our
documentation would be better written without a reference to such
fictional characters, for reasons that have nothing to do with trying
to bend over backwards to avoid any reference to people's gender. It
just makes for better documentation.

Since it's clear that Derrick's not interested in picking up that task
in his parallel series[2] here a brief series to implement that. This
leaves the only occurances of "alice" and "bob" (and "david" and
"cindy") at the bottom of giteveryday(7). Those could also be changed,
but I didn't think doing so provided a clear benefit, unlike the
changes being made here.

1. https://lore.kernel.org/git/875yyp4fun.fsf@evledraar.gmail.com/
2. pull.975.v3.git.1623766273.gitgitgadget@gmail.com

Ævar Arnfjörð Bjarmason (6):
  gittutorial doc: replace "alice" and "bob" with "you" and "www-data"
  gitcvs-migration doc: replace "alice" and "bob" with "you" and
    "www-data"
  daemon doc + code comments: reword "alice" example
  fast-import doc: change "bob" in an example to "file.txt"
  doc: replace "alice" and "bob" with "jdoe" and "msmith"
  pack-protocol doc: use "www-data" in place of "alice"

 Documentation/git-credential.txt          |   2 +-
 Documentation/git-daemon.txt              |  13 ++-
 Documentation/git-fast-import.txt         |  14 ++-
 Documentation/git-imap-send.txt           |   4 +-
 Documentation/git-interpret-trailers.txt  |  22 ++--
 Documentation/gitcvs-migration.txt        |  18 +--
 Documentation/gittutorial.txt             | 128 +++++++++++-----------
 Documentation/technical/pack-protocol.txt |   4 +-
 daemon.c                                  |  10 +-
 9 files changed, 112 insertions(+), 103 deletions(-)

-- 
2.32.0.555.g0268d380f7b

Rephrase the tutorial text added in 927a503cd07 (New tutorial,
2006-01-22) to talk about a repository "you" have, and which you'd
like to deploy a local copy of to a "www-data" user, and what it'll
take to pull and push changes between the two.

There's been some parallel work to get rid of gendered language in the
Git documentation[1] which has suggested that examples of "Alice and
Bob" should be excluded, as they're commonly used examples in
technical documentation, especially documentation that deals with
cryptography.

I don't think such an example is problematic per-se, and it certainly
has its place. But if all we're trying to achieve is a generic example
of pushing and pulling between two UIDs on the same (or different)
machine(s) it's needlessly verbose, especially to a reader who's not
in the know about the meaning of the names in crypto documentation (I
daresay that's the vast majority of our users, especially those
reading the tutorial).

To those in the know it's needlessly distracting. I for one tend do
read such documentation half-distracted as I try to remember what the
particular implicit meaning of that cast of characters is (if any). Is
there going to be an "Eve" at some point who'll serve as a stand-in
for the eavesdropper[2]?

In this case the answer is "no"; so let's replace the whole thing with
a less verbose and I think more common example of wanting to deploy a
repository in /home to some other user (the most common of which is
probably this www-data example), and pulling and pushing between the
two.

This commit also fixes the related issue of referring to an
"alice.org" domain, we really should use the RFC 2606 domain names
instead of potentially being a cause of spam to innocent bystander's
E-Mail addresses.

1. http://lore.kernel.org/git/f06092a9053e40d93c4ec94b7fbbb1b8d563957b.1623766273.git.gitgitgadget@gmail.com
2. https://en.wikipedia.org/wiki/Alice_and_Bob#Cast_of_characters

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
 Documentation/gittutorial.txt | 128 +++++++++++++++++-----------------
 1 file changed, 63 insertions(+), 65 deletions(-)

diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 59ef5cef1f0..7848888b40b 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt

@@ -280,79 +280,79 @@ out.
 Using Git for collaboration
 ---------------------------
 
-Suppose that Alice has started a new project with a Git repository in
-/home/alice/project, and that Bob, who has a home directory on the
-same machine, wants to contribute.
+Suppose that you've started a new project with a Git repository in
+/home/you/project, and you'd like another user on the same local
+machine to be able to contribute to it. E.g. a www-data user to serve
+the content up with a webserver.
 
-Bob begins with:
+As the `www-data` user do:
 
 ------------------------------------------------
-bob$ git clone /home/alice/project myrepo
+www-data$ git clone /home/you/project /var/www-data/deployment
 ------------------------------------------------
 
-This creates a new directory "myrepo" containing a clone of Alice's
+This creates a new directory "deployment" containing a clone of your
 repository.  The clone is on an equal footing with the original
 project, possessing its own copy of the original project's history.
 
-Bob then makes some changes and commits them:
+As `www-data` you then makes some changes and commit them:
 
 ------------------------------------------------
 (edit files)
-bob$ git commit -a
+www-data$ git commit -a
 (repeat as necessary)
 ------------------------------------------------
 
-When he's ready, he tells Alice to pull changes from the repository
-at /home/bob/myrepo.  She does this with:
+You can then pull those changes to the checkout in your home directory
+at /home/you/project:
 
 ------------------------------------------------
-alice$ cd /home/alice/project
-alice$ git pull /home/bob/myrepo master
+you$ cd /home/you/project
+you$ git pull /var/www-data/deployment master
 ------------------------------------------------
 
-This merges the changes from Bob's "master" branch into Alice's
-current branch.  If Alice has made her own changes in the meantime,
-then she may need to manually fix any conflicts.
+This merges the changes from the deployment repo's "master" branch into your
+current branch.  If you've made other changes there in the meantime,
+you may need to manually fix any conflicts.
 
 The "pull" command thus performs two operations: it fetches changes
 from a remote branch, then merges them into the current branch.
 
-Note that in general, Alice would want her local changes committed before
-initiating this "pull".  If Bob's work conflicts with what Alice did since
-their histories forked, Alice will use her working tree and the index to
+In general you'd want changes in your home directory to be committed before
+initiating this "pull".  If your www-data work conflicts with them you
+can use your working tree and the index to
 resolve conflicts, and existing local changes will interfere with the
 conflict resolution process (Git will still perform the fetch but will
-refuse to merge --- Alice will have to get rid of her local changes in
+refuse to merge --- You'll have to get rid of your local changes in
 some way and pull again when this happens).
 
-Alice can peek at what Bob did without merging first, using the "fetch"
-command; this allows Alice to inspect what Bob did, using a special
-symbol "FETCH_HEAD", in order to determine if he has anything worth
+You can look at those changes merging first, using the "fetch"
+command; this allows you to inspect the remote state, using a special
+symbol "FETCH_HEAD", in order to determine if there's anything worth
 pulling, like this:
 
 ------------------------------------------------
-alice$ git fetch /home/bob/myrepo master
-alice$ git log -p HEAD..FETCH_HEAD
+$ git fetch /var/www-data/deployment master
+you$ git log -p HEAD..FETCH_HEAD
 ------------------------------------------------
 
-This operation is safe even if Alice has uncommitted local changes.
+This operation is safe even if you've got uncommitted local changes.
 The range notation "HEAD..FETCH_HEAD" means "show everything that is reachable
 from the FETCH_HEAD but exclude anything that is reachable from HEAD".
-Alice already knows everything that leads to her current state (HEAD),
-and reviews what Bob has in his state (FETCH_HEAD) that she has not
-seen with this command.
+You know about everything that leads to your current state (HEAD),
+and can review the state of the www-data repoistory (FETCH_HEAD).
 
-If Alice wants to visualize what Bob did since their histories forked
-she can issue the following command:
+If you want to visualize that difference
+you can issue the following command:
 
 ------------------------------------------------
 $ gitk HEAD..FETCH_HEAD
 ------------------------------------------------
 
-This uses the same two-dot range notation we saw earlier with 'git log'.
+This uses the same two-dot range notation that 'git log' does.
 
-Alice may want to view what both of them did since they forked.
-She can use three-dot form instead of the two-dot form:
+To see commits from both repositories did since they forked.
+use three-dot form instead of the two-dot form:
 
 ------------------------------------------------
 $ gitk HEAD...FETCH_HEAD

@@ -364,11 +364,11 @@ exclude anything that is reachable from both of them".
 Please note that these range notation can be used with both gitk
 and "git log".
 
-After inspecting what Bob did, if there is nothing urgent, Alice may
-decide to continue working without pulling from Bob.  If Bob's history
-does have something Alice would immediately need, Alice may choose to
-stash her work-in-progress first, do a "pull", and then finally unstash
-her work-in-progress on top of the resulting history.
+After inspecting the difference you may
+decide to continue working without pulling from www-data.  If that history
+does have something you need you can
+stash your work-in-progress first, do a "pull", and then finally unstash
+it on top of the resulting history.
 
 When you are working in a small closely knit group, it is not
 unusual to interact with the same repository over and over

@@ -376,79 +376,77 @@ again.  By defining 'remote' repository shorthand, you can make
 it easier:
 
 ------------------------------------------------
-alice$ git remote add bob /home/bob/myrepo
+you$ git remote add deployment /var/www-data/deployment
 ------------------------------------------------
 
-With this, Alice can perform the first part of the "pull" operation
-alone using the 'git fetch' command without merging them with her own
-branch, using:
+With this, you can use the "deployment" name for that remote
+as an argument to 'git pull' or 'git fetch':
 
 -------------------------------------
-alice$ git fetch bob
+you$ git fetch deployment
 -------------------------------------
 
-Unlike the longhand form, when Alice fetches from Bob using a
+Unlike the longhand form, when you fetch using a
 remote repository shorthand set up with 'git remote', what was
 fetched is stored in a remote-tracking branch, in this case
-`bob/master`.  So after this:
+`deployment/master`.  So after this:
 
 -------------------------------------
-alice$ git log -p master..bob/master
+you$ git log -p master..deployment/master
 -------------------------------------
 
-shows a list of all the changes that Bob made since he branched from
-Alice's master branch.
+shows a list of all the changes in deployment/master since it branched
+off from your master branch.
 
-After examining those changes, Alice
-could merge the changes into her master branch:
+After examining those changes, you can merge them into your master branch:
 
 -------------------------------------
-alice$ git merge bob/master
+you$ git merge deployment/master
 -------------------------------------
 
-This `merge` can also be done by 'pulling from her own remote-tracking
-branch', like this:
+This `merge` can also be done by 'pulling from the remote-tracking
+branch':
 
 -------------------------------------
-alice$ git pull . remotes/bob/master
+you$ git pull . remotes/deployment/master
 -------------------------------------
 
 Note that git pull always merges into the current branch,
 regardless of what else is given on the command line.
 
-Later, Bob can update his repo with Alice's latest changes using
+Later, the www-data clone can be updated with your latest changes using
 
 -------------------------------------
-bob$ git pull
+www-data$ git pull
 -------------------------------------
 
-Note that he doesn't need to give the path to Alice's repository;
-when Bob cloned Alice's repository, Git stored the location of her
-repository in the repository configuration, and that location is
+Note that you don't need to supply the path to the original repository;
+when you cloned it the path was stored in
+the repository configuration, and that location is
 used for pulls:
 
 -------------------------------------
-bob$ git config --get remote.origin.url
-/home/alice/project
+www-data$ git config --get remote.origin.url
+/home/you/project
 -------------------------------------
 
 (The complete configuration created by 'git clone' is visible using
 `git config -l`, and the linkgit:git-config[1] man page
 explains the meaning of each option.)
 
-Git also keeps a pristine copy of Alice's master branch under the
+That cloned repository also keeps a copy of its remote master branch under the
 name "origin/master":
 
 -------------------------------------
-bob$ git branch -r
+www-data$ git branch -r
   origin/master
 -------------------------------------
 
-If Bob later decides to work from a different host, he can still
+If you decide to move that deployment clone to a diffeent host, you can still
 perform clones and pulls using the ssh protocol:
 
 -------------------------------------
-bob$ git clone alice.org:/home/alice/project myrepo
+www-data$ git clone you.example.org:/home/you/project myrepo
 -------------------------------------
 
 Alternatively, Git has a native protocol, or can use http;

-- 
2.32.0.555.g0268d380f7b

Continue the work started in the last commit and change the cast of
characters introduced in cd976f5c526 (Documentation: reorganize
cvs-migration.txt, 2006-12-06) to refer to the "you" and "www-data"
examples the gittutorial documentation now uses.

In addition to the reasons for this in the last commit, this also
brings the gitcvs-migration documentation in line with the example in
the tutorial, which was added by the same author at a around the same
time in 927a503cd07 (New tutorial, 2006-01-22).

Aside from talking about a bare repository here and a non-bare
checkout in the tutorial we use the same paths, and make explicit
reference to the more extended documentation in the tutorial here and
its relevance to this example.

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
 Documentation/gitcvs-migration.txt | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt
index 1cd1283d0f8..f2ff379886e 100644
--- a/Documentation/gitcvs-migration.txt
+++ b/Documentation/gitcvs-migration.txt

@@ -86,17 +86,21 @@ possibly created from scratch or from a tarball (see
 linkgit:gittutorial[7]), or imported from an already existing CVS
 repository (see the next section).
 
-Assume your existing repo is at /home/alice/myproject.  Create a new "bare"
-repository (a repository without a working tree) and fetch your project into
-it:
+Assume your existing repo is at /home/you/project.  Create a new "bare"
+repository (a repository withoupt a working tree) and fetch your project into
+it. 
 
 ------------------------------------------------
-$ mkdir /pub/my-repo.git
-$ cd /pub/my-repo.git
+$ mkdir /var/www-data/deployment.git
+$ cd /var/www-data/deployment.git
 $ git --bare init --shared
-$ git --bare fetch /home/alice/myproject master:master
+$ git --bare fetch /home/you/project master:master
 ------------------------------------------------
 
+(See the "Using Git for collaboration" section in
+linkgit:gittutorial[7] for an extended version of this example that
+doesn't use a bare repository.)
+
 Next, give every team member read/write access to this repository.  One
 easy way to do this is to give all the team members ssh access to the
 machine where the repository is hosted.  If you don't want to give them a

@@ -107,7 +111,7 @@ Put all the committers in the same group, and make the repository
 writable by that group:
 
 ------------------------------------------------
-$ chgrp -R $group /pub/my-repo.git
+$ chgrp -R $group /var/www-data/deployment.git
 ------------------------------------------------
 
 Make sure committers have a umask of at most 027, so that the directories

-- 
2.32.0.555.g0268d380f7b

Improve on the "alice" example added in 603968d22b1 (daemon: extend
user-relative path notation., 2006-02-04). I found the previous
version of this documentation a bit confusing, and had to read the
code to see what it was doing.

I think explicitly spelling out that the --user-path option can be
user to provide an infix to stash in-between what we'll resolve
"~user" and the path after that is clearer, especially when coupled
with explicit examples of path resolution.

Finally, the previous documentation didn't mention that `path/foo`
could actually resolve to `path/foo.git`. That's implicitly covered
earlier in the documentation, let's make an explicit reference to that
here.

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
 Documentation/git-daemon.txt | 13 ++++++++-----
 daemon.c                     | 10 +++++-----
 2 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index fdc28c041c7..a109189756d 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt

@@ -139,11 +139,14 @@ otherwise `stderr`.
 --user-path=<path>::
 	Allow {tilde}user notation to be used in requests.  When
 	specified with no parameter, requests to
-	git://host/{tilde}alice/foo is taken as a request to access
-	'foo' repository in the home directory of user `alice`.
-	If `--user-path=path` is specified, the same request is
-	taken as a request to access `path/foo` repository in
-	the home directory of user `alice`.
+	git://host/{tilde}user/foo is taken as a request to access
+	'foo' repository in the home directory of user `user`.
++
+If `--user-path=infix` is specified, the `infix` is appended to the path
+found with the {tilde}user notation. E.g. a request to access a `some/foo`
+repository (git://host/{tilde}user/some/foo) will resolve to (assuming that
+`$HOME` is `/home`) either `/home/user/infix/some/foo` (or `[...]/foo.git`
+etc., see `--strict-paths` above).
 
 --verbose::
 	Log details about the incoming connections and requested files.

diff --git a/daemon.c b/daemon.c
index 5c4cbad62d0..a939e5ee0e0 100644
--- a/daemon.c
+++ b/daemon.c

@@ -46,8 +46,8 @@ static const char *interpolated_path;
 static int base_path_relaxed;
 
 /* If defined, ~user notation is allowed and the string is inserted
- * after ~user/.  E.g. a request to git://host/~alice/frotz would
- * go to /home/alice/pub_git/frotz with --user-path=pub_git.
+ * after ~user/.  E.g. a request to git://host/~user/frotz would
+ * go to /home/user/pub_git/frotz with --user-path=pub_git.
  */
 static const char *user_path;
 

@@ -188,9 +188,9 @@ static const char *path_ok(const char *directory, struct hostinfo *hi)
 			return NULL;
 		}
 		if (*user_path) {
-			/* Got either "~alice" or "~alice/foo";
-			 * rewrite them to "~alice/%s" or
-			 * "~alice/%s/foo".
+			/* Got either "~user" or "~user/foo";
+			 * rewrite them to "~user/%s" or
+			 * "~user/%s/foo".
 			 */
 			int namlen, restlen = strlen(dir);
 			const char *slash = strchr(dir, '/');

-- 
2.32.0.555.g0268d380f7b

The example added in e7e5170f804 (Update fast-import documentation to
discuss crash reports, 2008-02-14) is a bit confusing in that we're
referring to a "bob" when we really just need a placeholder name for a
file that has bad mode bits, let's use "file.txt" instead.

Let's also use "<<-" in the here-doc so this'll work if the reader
copies this from e.g. a tab-indented manual page, none of the content
needs leading whitespace, so that won't break anything if the content
isn't indented.

The fast-import error message and other output has also changed
slightly since 2008, let's update the relevant parts of it, while
retaining the original PID, time etc. of the 2007-era example.

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
 Documentation/git-fast-import.txt | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 39cfa05b28b..ddaa8e5d755 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt

@@ -1277,7 +1277,7 @@ must be applied manually if the update is needed.
 An example crash:
 
 ====
-	$ cat >in <<END_OF_INPUT
+	$ cat >in <<-END_OF_INPUT
 	# my very first test commit
 	commit refs/heads/master
 	committer Shawn O. Pearce <spearce> 19283 -0400

@@ -1289,12 +1289,13 @@ An example crash:
 	data <<EOF
 	.gitignore
 	EOF
-	M 777 inline bob
+	M 777 inline file.txt
 	END_OF_INPUT
 
 	$ git fast-import <in
-	fatal: Corrupt mode: M 777 inline bob
+	fatal: Corrupt mode: M 777 inline file.txt
 	fast-import: dumping crash report to .git/fast_import_crash_8434
+	Unpacking objects: 100% (1/1), 32 bytes | 32.00 KiB/s, done.
 
 	$ cat .git/fast_import_crash_8434
 	fast-import crash report:

@@ -1302,7 +1303,7 @@ An example crash:
 	    parent process     : 1391
 	    at Sat Sep 1 00:58:12 2007
 
-	fatal: Corrupt mode: M 777 inline bob
+	fatal: Corrupt mode: M 777 inline file.txt
 
 	Most Recent Commands Before Crash
 	---------------------------------

@@ -1313,7 +1314,7 @@ An example crash:
 	  data <<EOF
 	  M 644 inline .gitignore
 	  data <<EOF
-	* M 777 inline bob
+	* M 777 inline file.txt
 
 	Active Branch LRU
 	-----------------

@@ -1334,6 +1335,9 @@ An example crash:
 	  last pack   :
 
 
+	Marks
+	-----
+
 	-------------------
 	END OF CRASH REPORT
 ====

-- 
2.32.0.555.g0268d380f7b

Change the "Alice" and "Bob" generic example users to jdoe@example.com
and msmith@example.com.

The former is widely used in RFC 5322 as an example E-Mail address,
the latter is not, but "Mary Smith [off-list ref]". It has been
claimed that any reference to people's gender in our documentation is
distracting to some readers[1]. In this case it's easy enough to tweak
the example in such a way that the reader can insert their own
stand-in for "M.".

1. https://lore.kernel.org/git/pull.975.v3.git.1623766273.gitgitgadget@gmail.com/

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
 Documentation/git-credential.txt         |  2 +-
 Documentation/git-imap-send.txt          |  4 ++--
 Documentation/git-interpret-trailers.txt | 22 +++++++++++-----------
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/Documentation/git-credential.txt b/Documentation/git-credential.txt
index 206e3c5f407..86b4c32affa 100644
--- a/Documentation/git-credential.txt
+++ b/Documentation/git-credential.txt

@@ -69,7 +69,7 @@ information it has):
 
 	protocol=https
 	host=example.com
-	username=bob
+	username=jdoe
 	password=secr3t
 +
 In most cases, this means the attributes given in the input will be

diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
index 63cf498ce9f..902f0e8ed34 100644
--- a/Documentation/git-imap-send.txt
+++ b/Documentation/git-imap-send.txt

@@ -72,7 +72,7 @@ Using direct mode:
 [imap]
     folder = "INBOX.Drafts"
     host = imap://imap.example.com
-    user = bob
+    user = jdoe
     pass = p4ssw0rd
 .........................
 

@@ -82,7 +82,7 @@ Using direct mode with SSL:
 [imap]
     folder = "INBOX.Drafts"
     host = imaps://imap.example.com
-    user = bob
+    user = jdoe
     pass = p4ssw0rd
     port = 123
     ; sslVerify = false

diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt
index 956a01d184f..17a19960ba3 100644
--- a/Documentation/git-interpret-trailers.txt
+++ b/Documentation/git-interpret-trailers.txt

@@ -277,13 +277,13 @@ $ cat msg.txt
 subject
 
 message
-$ cat msg.txt | git interpret-trailers --trailer 'sign: Alice <alice@example.com>' --trailer 'sign: Bob <bob@example.com>'
+$ cat msg.txt | git interpret-trailers --trailer 'sign: J. Doe <jdoe@example.com>' --trailer 'sign: M. Smith <msmith@example.com>'
 subject
 
 message
 
-Signed-off-by: Alice <alice@example.com>
-Signed-off-by: Bob <bob@example.com>
+Signed-off-by: J. Doe <jdoe@example.com>
+Signed-off-by: M. Smith <msmith@example.com>
 ------------
 
 * Use the `--in-place` option to edit a message file in place:

@@ -294,15 +294,15 @@ subject
 
 message
 
-Signed-off-by: Bob <bob@example.com>
-$ git interpret-trailers --trailer 'Acked-by: Alice <alice@example.com>' --in-place msg.txt
+Signed-off-by: M. Smith <msmith@example.com>
+$ git interpret-trailers --trailer 'Acked-by: J. Doe <jdoe@example.com>' --in-place msg.txt
 $ cat msg.txt
 subject
 
 message
 
-Signed-off-by: Bob <bob@example.com>
-Acked-by: Alice <alice@example.com>
+Signed-off-by: M. Smith <msmith@example.com>
+Acked-by: J. Doe <jdoe@example.com>
 ------------
 
 * Extract the last commit as a patch, and add a 'Cc' and a

@@ -311,7 +311,7 @@ Acked-by: Alice <alice@example.com>
 ------------
 $ git format-patch -1
 0001-foo.patch
-$ git interpret-trailers --trailer 'Cc: Alice <alice@example.com>' --trailer 'Reviewed-by: Bob <bob@example.com>' 0001-foo.patch >0001-bar.patch
+$ git interpret-trailers --trailer 'Cc: J. Doe <jdoe@example.com>' --trailer 'Reviewed-by: M. Smith <msmith@example.com>' 0001-foo.patch >0001-bar.patch
 ------------
 
 * Configure a 'sign' trailer with a command to automatically add a

@@ -326,12 +326,12 @@ $ git config trailer.sign.command 'echo "$(git config user.name) <$(git config u
 $ git interpret-trailers <<EOF
 > EOF
 
-Signed-off-by: Bob <bob@example.com>
+Signed-off-by: M. Smith <msmith@example.com>
 $ git interpret-trailers <<EOF
-> Signed-off-by: Alice <alice@example.com>
+> Signed-off-by: J. Doe <jdoe@example.com>
 > EOF
 
-Signed-off-by: Alice <alice@example.com>
+Signed-off-by: J. Doe <jdoe@example.com>
 ------------
 
 * Configure a 'fix' trailer with a key that contains a '#' and no

-- 
2.32.0.555.g0268d380f7b

Replace the example of "alice" in the pack-protocol.txt documentation
added in b31222cfb7f (Update packfile transfer protocol documentation,
2009-11-03) with "www-data". This is now consistent with the recently
changed examples in the tutorial and git-daemon documentation.

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
 Documentation/technical/pack-protocol.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt
index e13a2c064d1..0f43a290e59 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt

@@ -136,10 +136,10 @@ directory, because the Git client will run:
 The exception is if a '~' is used, in which case
 we execute it without the leading '/'.
 
-      ssh://user@example.com/~alice/project.git,
+      ssh://user@example.com/~www-data/project.git,
 		     |
 		     v
-   ssh user@example.com "git-upload-pack '~alice/project.git'"
+   ssh user@example.com "git-upload-pack '~www-data/project.git'"
 
 Depending on the value of the `protocol.version` configuration variable,
 Git may attempt to send Extra Parameters as a colon-separated string in

-- 
2.32.0.555.g0268d380f7b

On Tue, 15 Jun 2021, Ævar Arnfjörð Bjarmason wrote:

I suggested in [1] that the "alice" and "bob" examples in our
documentation would be better written without a reference to such
fictional characters, for reasons that have nothing to do with trying
to bend over backwards to avoid any reference to people's gender. It
just makes for better documentation.

  no, it doesn't ... and wikipedia explains it nicely:

https://en.wikipedia.org/wiki/Alice_and_Bob

"In cryptography, Alice and Bob are fictional characters commonly used
as placeholders in discussions about cryptographic protocols or
systems, and in other science and engineering literature where there
are several participants in a thought experiment. The Alice and Bob
characters were invented by Ron Rivest, Adi Shamir, and Leonard
Adleman in their 1978 paper "A Method for Obtaining Digital Signatures
and Public-key Cryptosystems".[1] Subsequently, they have become
common archetypes in many scientific and engineering fields, such as
quantum cryptography, game theory and physics.[2] As the use of Alice
and Bob became more widespread, additional characters were added,
sometimes each with a particular meaning. These characters do not have
to refer to humans; they refer to generic agents which might be
different computers or even different programs running on a single
computer."

  if you want to make the docs better, have at it, but please don't do
something as meaningless as replacing "bob" and "alice" because you're
feeling politically correct, or woke, or whatever the hell the kids
call it these days.

  jesus ...

rday

Ævar Arnfjörð Bjarmason wrote:

I suggested in [1] that the "alice" and "bob" examples in our
documentation would be better written without a reference to such
fictional characters, for reasons that have nothing to do with trying
to bend over backwards to avoid any reference to people's gender. It
just makes for better documentation.

I'm fond of Alice and Bob, and I'm saddened they are the latest casualty
of the culture war, but if we are avoiding gender of examples, it makes
sense to let them go.

However, I want to defend this usage a little.

  1. Alice and Bob are familiar, so it requires less cogntive load from
     the user.
  2. Alice and Bob promote the usage of git as a distributed VCS, where
     unlike centralized VCS, you directly use the repositories of your
     colleagues.
  3. They provide some relief to an otherwise sterile landscape.

I don't think these changes make for a necessarily better documentation,
just a more sterile one.

Cheers.

-- 
Felipe Contreras

On Tue, Jun 15 2021, Robert P. J. Day wrote:

On Tue, 15 Jun 2021, Ævar Arnfjörð Bjarmason wrote:

quoted

I suggested in [1] that the "alice" and "bob" examples in our
documentation would be better written without a reference to such
fictional characters, for reasons that have nothing to do with trying
to bend over backwards to avoid any reference to people's gender. It
just makes for better documentation.

  no, it doesn't ... and wikipedia explains it nicely:

It doesn't make for better documentation? Maybe not, but can you comment
on specific parts of the changes in this series that make it worse?

https://en.wikipedia.org/wiki/Alice_and_Bob

"In cryptography, Alice and Bob are fictional characters commonly used
as placeholders in discussions about cryptographic protocols or
systems, and in other science and engineering literature where there
are several participants in a thought experiment. The Alice and Bob
characters were invented by Ron Rivest, Adi Shamir, and Leonard
Adleman in their 1978 paper "A Method for Obtaining Digital Signatures
and Public-key Cryptosystems".[1] Subsequently, they have become
common archetypes in many scientific and engineering fields, such as
quantum cryptography, game theory and physics.[2] As the use of Alice
and Bob became more widespread, additional characters were added,
sometimes each with a particular meaning. These characters do not have
to refer to humans; they refer to generic agents which might be
different computers or even different programs running on a single
computer."

  if you want to make the docs better, have at it, but please don't do
something as meaningless as replacing "bob" and "alice" because you're
feeling politically correct, or woke, or whatever the hell the kids
call it these days.

  jesus ...

I believe that the commit message of 1/6 addresses the point you're
raising here:
http://lore.kernel.org/git/patch-1.6-abbb5b9ba13-20210615T161330Z-avarab@gmail.com

On Tue, Jun 15 2021, Felipe Contreras wrote:

Ævar Arnfjörð Bjarmason wrote:

quoted

I suggested in [1] that the "alice" and "bob" examples in our
documentation would be better written without a reference to such
fictional characters, for reasons that have nothing to do with trying
to bend over backwards to avoid any reference to people's gender. It
just makes for better documentation.

I'm fond of Alice and Bob, and I'm saddened they are the latest casualty
of the culture war, but if we are avoiding gender of examples, it makes
sense to let them go.

However, I want to defend this usage a little.

  1. Alice and Bob are familiar, so it requires less cogntive load from
     the user.
  2. Alice and Bob promote the usage of git as a distributed VCS, where
     unlike centralized VCS, you directly use the repositories of your
     colleagues.
  3. They provide some relief to an otherwise sterile landscape.

I don't think these changes make for a necessarily better documentation,
just a more sterile one.

Fair enough, for what it's worth I wouldn't recommend against using
these names in general, I would think you'd actively seek out those
actors in e.g. cryptography documentation.

But as I argue in 1/6 I think these references go over the head of most
of our users, and those users are better served by more succinct
documentation.

The diffstat for the series as a whole increases line count, but it's
because of e.g. 3/6 elaborating on the function of the --user-path
switch, in the case of 1/6 we've got a reduction in lines and number of
words.

And as argued in 1/6 for those users who /are/ aware of "Alice and Bob"
it's needless distraction. Maybe it's just me, but whenever I read
references to them I keep waiting for the cryptography angle to be
introduced. None of the uses in our documentation reflect that canonical
usage.

There's also just weird things in our documentation fixed by this
series, such as referring to a random file tracked by git as "bob"
instead of the more obvious "file.txt".

On 15/06/21 23.17, Ævar Arnfjörð Bjarmason wrote:

-Suppose that Alice has started a new project with a Git repository in
-/home/alice/project, and that Bob, who has a home directory on the
-same machine, wants to contribute.
+Suppose that you've started a new project with a Git repository in
+/home/you/project, and you'd like another user on the same local
+machine to be able to contribute to it. E.g. a www-data user to serve
+the content up with a webserver.
  
-Bob begins with:
+As the `www-data` user do:
   >   ------------------------------------------------
-bob$ git clone /home/alice/project myrepo
+www-data$ git clone /home/you/project /var/www-data/deployment
  ------------------------------------------------

This assumes that we're on Debian or its derivatives, however many users 
run Git on other distributions (Fedora, Arch, Gentoo, openSUSE, etc.), 
so `www-data` user may not be present there. Also, `www-data` is system 
account, as opposed to normal user account, so you can't log in to it; 
you need as root `chown -R www-data:www-data /somewhere/`.

This also assumes that we use Apache HTTPD. The setup for other 
webservers may be different. For example, if NGINX is used (installed 
from upstream packages rather than from Debian package repository), you 
need to make site root (the path specified in `root` directive) readable 
by `nginx` user.

-This creates a new directory "myrepo" containing a clone of Alice's
+This creates a new directory "deployment" containing a clone of your
  repository.  The clone is on an equal footing with the original
  project, possessing its own copy of the original project's history.
 

But the scenario is we're cloning from local repo, so `git clone` here 
implies --local (and bypasses normal Git transport mechanism), so to get 
clone experience similar to when using remote repo, we can use 
--no-local instead.

-Bob then makes some changes and commits them:
+As `www-data` you then makes some changes and commit them:
  
  ------------------------------------------------
  (edit files)
-bob$ git commit -a
+www-data$ git commit -a
  (repeat as necessary)
  ------------------------------------------------
  
-When he's ready, he tells Alice to pull changes from the repository
-at /home/bob/myrepo.  She does this with:
+You can then pull those changes to the checkout in your home directory
+at /home/you/project:
  
  ------------------------------------------------
-alice$ cd /home/alice/project
-alice$ git pull /home/bob/myrepo master
+you$ cd /home/you/project
+you$ git pull /var/www-data/deployment master
  ------------------------------------------------
  

The resulting rewrite until this point makes no sense for me. Previously 
we have Alice and Bob working the project, but now you do the same, one 
as normal user account and one as system user `www-data`. Honestly I 
would like keeping the status quo.

-- 
An old man doll... just what I always wanted! - Clara

On 15/06/21 23.17, Ævar Arnfjörð Bjarmason wrote:

  ------------------------------------------------
-$ mkdir /pub/my-repo.git
-$ cd /pub/my-repo.git
+$ mkdir /var/www-data/deployment.git
+$ cd /var/www-data/deployment.git
  $ git --bare init --shared
-$ git --bare fetch /home/alice/myproject master:master
+$ git --bare fetch /home/you/project master:master
  ------------------------------------------------
  

Normally you need to mkdir there as root.

-- 
An old man doll... just what I always wanted! - Clara

Ævar Arnfjörð Bjarmason wrote:

On Tue, Jun 15 2021, Felipe Contreras wrote:

quoted

Ævar Arnfjörð Bjarmason wrote:

quoted

I suggested in [1] that the "alice" and "bob" examples in our
documentation would be better written without a reference to such
fictional characters, for reasons that have nothing to do with trying
to bend over backwards to avoid any reference to people's gender. It
just makes for better documentation.

I'm fond of Alice and Bob, and I'm saddened they are the latest casualty
of the culture war, but if we are avoiding gender of examples, it makes
sense to let them go.

However, I want to defend this usage a little.

  1. Alice and Bob are familiar, so it requires less cogntive load from
     the user.
  2. Alice and Bob promote the usage of git as a distributed VCS, where
     unlike centralized VCS, you directly use the repositories of your
     colleagues.
  3. They provide some relief to an otherwise sterile landscape.

I don't think these changes make for a necessarily better documentation,
just a more sterile one.

Fair enough, for what it's worth I wouldn't recommend against using
these names in general, I would think you'd actively seek out those
actors in e.g. cryptography documentation.

I have not read cryptography documentation, so for me Alice and Bob are
simply two illustrative colleagues.

And as argued in 1/6 for those users who /are/ aware of "Alice and Bob"
it's needless distraction. Maybe it's just me, but whenever I read
references to them I keep waiting for the cryptography angle to be
introduced. None of the uses in our documentation reflect that canonical
usage.

It's probably not just you, but the vast majority of readers are
likely not aware of any cryptographic reference.

There's also just weird things in our documentation fixed by this
series, such as referring to a random file tracked by git as "bob"
instead of the more obvious "file.txt".

OK, _that_ I agree it's unequivocally an improvement.

Cheers.

-- 
Felipe Contreras

Bagas Sanjaya wrote:

On 15/06/21 23.17, Ævar Arnfjörð Bjarmason wrote:

quoted

-Suppose that Alice has started a new project with a Git repository in
-/home/alice/project, and that Bob, who has a home directory on the
-same machine, wants to contribute.
+Suppose that you've started a new project with a Git repository in
+/home/you/project, and you'd like another user on the same local
+machine to be able to contribute to it. E.g. a www-data user to serve
+the content up with a webserver.
  
-Bob begins with:
+As the `www-data` user do:
   >   ------------------------------------------------
-bob$ git clone /home/alice/project myrepo
+www-data$ git clone /home/you/project /var/www-data/deployment
  ------------------------------------------------

This assumes that we're on Debian or its derivatives,

True, and not all derivatives. In Ubuntu it's /var/www/.

-- 
Felipe Contreras

Felipe Contreras [off-list ref] writes:

I have not read cryptography documentation, so for me Alice and Bob are
simply two illustrative colleagues.

I have read cryptography documentation and seen Alice and Bob used
commonly.  Am I supposed to be confused if I see those names used in
documentation for non cryptographic software?  If Alice and Bob work
there, why should they not be used here?  Am I missing something?

quoted

And as argued in 1/6 for those users who /are/ aware of "Alice and Bob"
it's needless distraction. Maybe it's just me, but whenever I read
references to them I keep waiting for the cryptography angle to be
introduced. None of the uses in our documentation reflect that canonical
usage.

It's probably not just you, but the vast majority of readers are
likely not aware of any cryptographic reference.

I find it surprising that anyone would be upset that the names Alice and
Bob were being used in a non cryptographic context.

quoted

There's also just weird things in our documentation fixed by this
series, such as referring to a random file tracked by git as "bob"
instead of the more obvious "file.txt".

OK, _that_ I agree it's unequivocally an improvement.

Yea, a file probably shouldn't be called bob... I would probably have
gone with "foo.txt" ( but file.txt is just fine too ).

On Wed, Jun 16 2021, Bagas Sanjaya wrote:

On 15/06/21 23.17, Ævar Arnfjörð Bjarmason wrote:

quoted

-Suppose that Alice has started a new project with a Git repository in
-/home/alice/project, and that Bob, who has a home directory on the
-same machine, wants to contribute.
+Suppose that you've started a new project with a Git repository in
+/home/you/project, and you'd like another user on the same local
+machine to be able to contribute to it. E.g. a www-data user to serve
+the content up with a webserver.
  -Bob begins with:
+As the `www-data` user do:
   >   ------------------------------------------------
-bob$ git clone /home/alice/project myrepo
+www-data$ git clone /home/you/project /var/www-data/deployment
  ------------------------------------------------

This assumes that we're on Debian or its derivatives, however many
users run Git on other distributions (Fedora, Arch, Gentoo, openSUSE,
etc.), so `www-data` user may not be present there. Also, `www-data`
is system account, as opposed to normal user account, so you can't log
in to it; you need as root `chown -R www-data:www-data /somewhere/`.

This also assumes that we use Apache HTTPD. The setup for other
webservers may be different. For example, if NGINX is used (installed 
from upstream packages rather than from Debian package repository),
you need to make site root (the path specified in `root` directive)
readable by `nginx` user.

I meant www-data merely as an example, the user is expected to fill in
the blanks as Junio noted downthread. Not all *nix systems even have
$HOME in /home.

But clearly it's confusing to some, do you think calling it
s/www-data/website/g and otherwise making it non-distro specific would
be better?

quoted

-This creates a new directory "myrepo" containing a clone of Alice's
+This creates a new directory "deployment" containing a clone of your
  repository.  The clone is on an equal footing with the original
  project, possessing its own copy of the original project's history.
 

But the scenario is we're cloning from local repo, so `git clone` here
implies --local (and bypasses normal Git transport mechanism), so to
get clone experience similar to when using remote repo, we can use 
--no-local instead.

Well spotted, I believe that was the behavior when this was writen at
927a503cd0 (New tutorial, 2006-01-22), so this bug has probably always
been there...

quoted

-Bob then makes some changes and commits them:
+As `www-data` you then makes some changes and commit them:
    ------------------------------------------------
  (edit files)
-bob$ git commit -a
+www-data$ git commit -a
  (repeat as necessary)
  ------------------------------------------------
  -When he's ready, he tells Alice to pull changes from the
repository
-at /home/bob/myrepo.  She does this with:
+You can then pull those changes to the checkout in your home directory
+at /home/you/project:
    ------------------------------------------------
-alice$ cd /home/alice/project
-alice$ git pull /home/bob/myrepo master
+you$ cd /home/you/project
+you$ git pull /var/www-data/deployment master
  ------------------------------------------------
  

The resulting rewrite until this point makes no sense for
me. Previously we have Alice and Bob working the project, but now you
do the same, one as normal user account and one as system user
`www-data`. Honestly I would like keeping the status quo.

Collectively we're a sample size of two, so it doesn't say much either
way, but FWIW I've worked at two companies in the past that had some
version of the pattern discussed in this article. I.e. you'd login to
some machine, have a repo in $HOME, and used that as your staging area
to another repo on the same machine also under your control (either
permanently or exclusively, or you'd "lock" it for the duration).

I don't think I've once in all my time using git been in the position to
be logged into a machine, and pulling/pushing to another repo in someone
else's $HOME or equivalent.

In any case, I do think for the purposes of the example in the guide
replacing Alice & Bob with You & another version of you removes a lot of
potential confusion, we don't need to cover permissions, the other user
doing unexpected things like non-ff updates, pruning branches you may
have relied on through the --local clone etc.

It's implicit that both "users" are you, so we only have to discuss the
point of the actual example, how to pull and push between two different
repos, the "different users" in this case was always a distraction.

On Thu, Jun 17 2021, Phillip Susi wrote:

Felipe Contreras [off-list ref] writes:

quoted

I have not read cryptography documentation, so for me Alice and Bob are
simply two illustrative colleagues.

I have read cryptography documentation and seen Alice and Bob used
commonly.  Am I supposed to be confused if I see those names used in
documentation for non cryptographic software?  If Alice and Bob work
there, why should they not be used here?  Am I missing something?

quoted

quoted

And as argued in 1/6 for those users who /are/ aware of "Alice and Bob"
it's needless distraction. Maybe it's just me, but whenever I read
references to them I keep waiting for the cryptography angle to be
introduced. None of the uses in our documentation reflect that canonical
usage.

It's probably not just you, but the vast majority of readers are
likely not aware of any cryptographic reference.

I find it surprising that anyone would be upset that the names Alice and
Bob were being used in a non cryptographic context.

Who's upset? Not the author of this patch series, as noted in 1/6 I just
think it makes for less confusing reading, since Alice & Bob in
particular have implicit meanings you might guess at[1], and aside from
that I think it simplifies the example the guide is getting at [2].

quoted

quoted

There's also just weird things in our documentation fixed by this
series, such as referring to a random file tracked by git as "bob"
instead of the more obvious "file.txt".

OK, _that_ I agree it's unequivocally an improvement.

Yea, a file probably shouldn't be called bob... I would probably have
gone with "foo.txt" ( but file.txt is just fine too ).

Git's documentation is read by all sorts of audiences, "foo" and "bar"
are programmer jargon not obvious to everyone. I wouldn't say don't use
it at all, but when a self-descriptive alternative such as file.txt or
whatever works perfectly fine as in the case changed in this series,
it's better to go with that.

1. http://lore.kernel.org/git/patch-1.6-abbb5b9ba13-20210615T161330Z-avarab@gmail.com
2. https://lore.kernel.org/git/875yyc5i6x.fsf@evledraar.gmail.com/