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):
> diff --git a/Documentation/config.txt b/Documentation/config.txt
OK
> diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt
OK
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
OK, except for two hunks below I am not absolutely sure.
> @@ -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?
> @@ -342,9 +342,9 @@ git push origin :experimental::
Likewise.
> 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.
> @@ -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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html