rahedges / git-repo

Automatically exported from code.google.com/p/git-repo
Apache License 2.0
0 stars 0 forks source link

repo: repo sync should use the tag name instead of object identifier of the tag #136

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Hi,

After updating a manifest project revision, switching from a previous tag 
(v1.12.1) to a newer tag (v1.12.2) on the same branch, repo sync makes git 
merge (by recursive method) the newer tag into the local repository. In this 
case, git spawn an editor to create a merge commit message.

In this case, the default commit message is about merging the object identifier 
(ac22c7ae2e652f63366b65ee23122292d3564fff) instead of the newer tag (v1.12.2) 
making it hard to understand what's get updated/merged. Additionally 
ac22c7ae2e652f63366b65ee23122292d3564fff is the object identifier of the tag 
(signed) while the first commit to be merged will be 
45d21685b93f80b67239849b2d2cfe6b217e335a instead, which is very disappointing.

Additionally, when the tag name is used, git will check the PGP/GPG signature 
of the signed tag. It doesn't happen when the object identifier of the signed 
tag is used.

This problem happen when the tag to be merged is a signed/annotated tag, eg 
it's an object with an identifier. 
This doesn't happen when a branch or a tag reference/lightweight tag is to be 
merged: a fast-forward merge is done and no merge commit is created.

repo sync should use the tag name (reference) to do the merge and not the 
object identifier.

(This was wrongly reported at 
http://code.google.com/p/gerrit/issues/detail?id=1823 )

Original issue reported on code.google.com by yann@droneaud.fr on 12 Mar 2013 at 5:00

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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