Re: git merge <tag> behavior

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 19, 2013, 16:19 UTC
Message-ID: <7vfvzrjrad.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1363704914.6289.39.camel@test.quest-ce.net>

Yann Droneaud <ydroneaud@opteya.com> writes:

Show 9 quoted lines

> 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.

Show 6 quoted lines

> 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)

Show 5 quoted lines

> 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.