Open GoogleCodeExporter opened 8 years ago
[deleted comment]
Please a find a log (already attached to issue #135) that show the step to
reproduce the problem: merging the object id of a tag is different from merging
the tag itself.
$ git show branch-ac22c7ae2e652f63366b65ee23122292d3564fff
commit 57dc3d47074b116453acd611a863acc85e332ffa
Merge: 91f011a 45d2168
Author: Yann Droneaud <yann@droneaud.fr>
Date: Wed Mar 13 12:00:34 2013 +0100
Merge commit 'ac22c7ae2e652f63366b65ee23122292d3564fff' into branch-ac22c7ae2e652f63366b65ee23122292d3564fff
$ git show branch-v1.12.2
commit d9eb89911acb05b099ee9ddc9054ba76a4c3debd
Merge: 91f011a 45d2168
Author: Yann Droneaud <yann@droneaud.fr>
Date: Wed Mar 13 11:59:02 2013 +0100
Merge tag 'v1.12.2' into branch-v1.12.2
repo 1.12.2
As you can see, the message from the tag is added in the merge commit message.
Additionally, when git spawn the editor, the message template is filled with
the output of GPG to report the key used to sign the commit:
Merge tag 'v1.12.2' into branch-v1.12.2
repo 1.12.2
# gpg: Signature made Fri Mar 1 18:36:42 2013 CET using DSA key ID 920F5C65
# gpg: Good signature from "Repo Maintainer <repo@android.kernel.org>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 8BB9 AD79 3E8E 6153 AF0F 9A44 1653 0D5E 920F 5C65
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
Regards.
Original comment by yann@droneaud.fr
on 13 Mar 2013 at 11:36
Attachments:
Hi,
git v1.8.3 will behave differently regarding this issue: the tag payload
(annotation) will be reported.
From: https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.3.txt
"
* "git merge $(git rev-parse v1.8.2)" behaved quite differently from
"git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did
not pay much attention to the annotated tag payload. Make the code
notice the type of the tag object, in addition to the dwim_ref()
based classification the current code uses (i.e. the name appears
in refs/tags/) to decide when to special-case tag merging.
"
But still, git-repo should use the tag name instead of its object-id.
Regards.
Original comment by yann@droneaud.fr
on 28 May 2013 at 10:34
support for parsing tag object was added to git 1.8.3 as part of the following
commit:
https://github.com/git/git/commit/499231d9f157d0987d8bdad258ce4cfd9f4c3d1f
"
Merge branch 'jc/merge-tag-object' into maint
"git merge $(git rev-parse v1.8.2)" behaved quite differently from
"git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did
not pay much attention to the annotated tag payload. Make the code
notice the type of the tag object, in addition to the dwim_ref()
based classification the current code uses (i.e. the name appears in
refs/tags/) to decide when to special case merging of tags.
* jc/merge-tag-object:
t6200: test message for merging of an annotated tag
t6200: use test_config/test_unconfig
merge: a random object may not necssarily be a commit
"
Original comment by yann@droneaud.fr
on 28 May 2013 at 11:01
Original issue reported on code.google.com by
yann@droneaud.fr
on 12 Mar 2013 at 5:00