From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 19 Mar 2013 16:19:38 GMT
Subject: Re: git merge <tag> behavior
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:

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