Re: git merge <tag> behavior

From: Yann Droneaud <ydroneaud@opteya.com>
Date: Mar 20, 2013, 18:04 UTC
Message-ID: <1363802682.6289.46.camel@test.quest-ce.net>
In-Reply-To: <7vfvzrjrad.fsf@alter.siamese.dyndns.org>

Hi,

Le mardi 19 mars 2013 à 09:19 -0700, Junio C Hamano a écrit :

> Yann Droneaud <ydroneaud@opteya.com> writes:
> 
> > 1) there's no mention of the git merge <tag> behavior in git-merge.1

> Yes; we welcome documentation patches.
>

Sent.

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 parse-rev <tag>`,

[EDIT]

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

I think if someone want to merge the tag object-id instead of the tag, the commit subject/message should probably not make a reference to the tag.

The only use case for such tag merging by commit-id would be to get consistent behavior in case of tag deletion. The named tag could be recreated to point to another point in time. So when looking at the merge commit message and searching for the tag (by name) could be misleading.

PS: and what about my third issue ?

Regards.

-- 
Yann Droneaud
OPTEYA