Yann Droneaud <ydroneaud@xxxxxxxxxx> 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[4].
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html