Jonathan Nieder [off-list ref] writes:
Nice and clear, but doesn't this contradict b5c9f1c1b0ed (merge: do
not create a signed tag merge under --ff-only option, 2012-02-05)?
It does X-<. Here is a replacement.
The "--ff-only v1.2.3 will fail" can be left unsaid because it would
fail (and succeed) under the same condition "-ff-only v1.2.3^0"
would.
Documentation/git-merge.txt | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index df2d28d..d1f3df9 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -179,19 +179,18 @@ the commit message template is prepared with the tag message.
Additionally, the signature check is reported as a comment
if the tag is signed. See also linkgit:git-tag[1].
-Consequently a request `git merge --ff-only v1.2.3` to merge such a
-tag would fail.
-
When you want to just integrate with the work leading to the commit
that happens to be tagged, e.g. synchronizing with an upstream
-release point, you may not want to make an unnecessary merge commit
-especially when you do not have any work on your own. In such a
-case, you can "unwrap" the tag yourself before feeding it to `git
-merge`, e.g.
+release point, you may not want to make an unnecessary merge commit.
+
+In such a case, you can "unwrap" the tag yourself before feeding it
+to `git merge`, or pass `--ff-only` when you do not have any work on
+your own. e.g.
---
git fetch origin
-git merge [--ff-only] v1.2.3^0
+git merge v1.2.3^0
+git merge --ff-only v1.2.3
---