Yann Droneaud <ydrone...@opteya.com> writes: > 1) there's no mention of the git merge <tag> behavior in git-merge.1 > > 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.1. > It should be documented as an exception of "FAST-FORWARD MERGE" section > and "--ff" option description.
Yes; we welcome documentation patches. > 2) git merge <tag> VS git merge <object-id> > > If <tag> is an object (not a lightweight/reference tag), git merge <tag> > ... > But, if you use the tag object-id instead of its name, for example using > git merge `git show-ref <tag>`, "git show-ref <tag>" gives you something like 572a535454612a046e7dd7404dcca94d6243c788 refs/tags/v1.8.2 which is an invalid thing to merge with. Perhaps you meant git merge $(git rev-parse v1.12.2) > signature is not checked. Git still create a merge commit, but doesn't > prepare a commit message with the tag message and the signature: > > It would be great to have Git using the tag message and check the > signature. Perhaps, but if you feed the $(git rev-parse v1.12.2) to merge, your subject will not be able to say "Merge tag 'v1.12.2'" in the first place, so I do not think you would want to encourage such usage in the first place. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html