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[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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to