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.
On Sat, Oct 24, 2009 at 8:50 PM, Junio C Hamano [off-list ref] wrote:
Is this meant to replace the previous one that is already queued: a0c0ecb
(user-manual: use 'fast-forward', 2009-10-11)?
Yes.
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 manually replaced each instance, and reviewed the patch myself. Most
of the changes are essentially the same, except a few instances:
"Fast forward" -> fast-forward
Fast Forward Only -> Fast-forward Only
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;
There wasn't such.
(2) what criteria was used to choose between leaving the mechanical
change as-is and rewording them manually; and
If it wasn't straight forward. I considered the following straightforward:
fast forward -> fast-forward
fast forwarded -> fast-forwarded
fast forwarding -> fast-forwarding
fast forwardable -> fast-forwardable
non-fast forward -> non-fast-forward
Fast forward -> Fast-forward
Fast forwarding -> Fast-forwarding
(3) where these non-mechanical changes are.
Mentioned on the second comment.
Here are the list of paths I looked at (during this sitting which did
not go til the end of the patch):
quoted
diff --git a/Documentation/config.txt b/Documentation/config.txt
OK
quoted
diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt
OK
quoted
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
OK, except for two hunks below I am not absolutely sure.
quoted
@@ -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?
Yes. AFAIK.
quoted
@@ -342,9 +342,9 @@ git push origin :experimental::
Likewise.
quoted
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
@@ -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'.
I couldn't parse that. From what I can see "Fast forward" was
emphasized because the author thought the words didn't make much sense
separated. Now that the word is fast-forward, there's no need to
emphasize.
Cheers.
--
Felipe Contreras