Re: [PATCH] Use 'fast-forward' all over the place
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:47:36
Is this meant to replace the previous one that is already queued: a0c0ecb
(user-manual: use 'fast-forward', 2009-10-11)?
It seems that these mostly match a mechanical token replacement
"s/([fF])ast forward/$1ast-forward/g" in the Documentation area,
but I suspect there may be some manual fixes.
Token-replace is much harder to review than to produce, as the result of
such mechanical substitution needs to be examined to see if each change
makes sense individually.
I suspect the patch would have been much easier to the reviewers it it
stated somewhere in the log message:
(1) how the mechanical change was produced;
(2) what criteria was used to choose between leaving the mechanical
change as-is and rewording them manually; and
(3) where these non-mechanical changes are.
Here are the list of paths I looked at (during this sitting which did
not go til the end of the patch):
quoted hunk
diff --git a/Documentation/config.txt b/Documentation/config.txt
OK
quoted hunk
diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt
OK
quoted hunk
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
OK, except for two hunks below I am not absolutely sure.
quoted hunk
@@ -60,7 +60,7 @@ EXAMPLES below for details. Pushing an empty <src> allows you to delete the <dst> ref from the remote repository. + -The special refspec `:` (or `{plus}:` to allow non-fast forward updates) +The special refspec `:` (or `{plus}:` to allow non-fast-forward updates) directs git to push "matching" branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name already exists on the remote side. This is the default operation mode
Hmm, is non-fast-forward a yet another compound word?
quoted hunk
@@ -342,9 +342,9 @@ git push origin :experimental::
Likewise.
quoted hunk
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
OK, except for this hunk I am not sure about.
quoted hunk
@@ -2115,7 +2115,7 @@ $ git checkout release && git pull Important note! If you have any local changes in these branches, then this merge will create a commit object in the history (with no local -changes git will simply do a "Fast forward" merge). Many people dislike +changes git will simply do a fast-forward merge). Many people dislike the "noise" that this creates in the Linux history, so you should avoid doing this capriciously in the "release" branch, as these noisy commits will become part of the permanent history when you ask Linus to pull
It may be Ok not to emphasize this word but that is not about "fast forward" vs "fast-forward". It is more about "in this context, this word does not have to be emphasized" kind of copy-editing which does not have to be limited to the case where the "word" is 'fast-forward'. It is my policy not to look at one patch for more than 30 minutes in one sitting, because I'll get sloppier toward the end, so I'll stop here for now. Help in reviewing the rest is appreciated.