When asking Git to merge a tag (such as a signed tag or annotated tag),
it will always create a merge commit even if fast-forward was possible.
It's like having --no-ff present on the command line.
It's a difference from the default behavior described in git-merge.txt.
It should be documented as an exception of "FAST-FORWARD MERGE" section
and "--ff" option description.
Signed-off-by: Yann Droneaud <redacted>
---
Documentation/git-merge.txt | 9 +++++++++
Documentation/merge-options.txt | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index c852a26..84bc873 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -170,6 +170,15 @@ happens:
If you tried a merge which resulted in complex conflicts and
want to start over, you can recover with `git merge --abort`.
+MERGING TAG
+-----------
+
+When merging a tag (annotated or signed), Git will create a merge commit
+even if a fast-forward merge is possible (see above).
+The commit message template will be created from the tag message.
+Additionally, the signature check will be reported as a comment
+if the tag was signed. See also linkgit:git-tag[1].
+
HOW CONFLICTS ARE PRESENTED
---------------------------
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 0bcbe0a..70d1ec0 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -26,7 +26,7 @@ set to `no` at the beginning of them.
--ff::
When the merge resolves as a fast-forward, only update the branch
pointer, without creating a merge commit. This is the default
- behavior.
+ behavior (except when merging a tag).
--no-ff::
Create a merge commit even when the merge resolves as a
--
1.7.11.7