{"thread":{"id":"1185","subject":"tag referring to a commit but not directly?","startedAt":"2005-07-09T10:00:44Z","lastAt":"2005-07-11T15:14:53Z","messageCount":3,"participants":["Junio C Hamano","Jon Seymour"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"5854","messageId":"7v7jg0wb77.fsf@assigned-by-dhcp.cox.net","threadId":"1185","inReplyTo":null,"subject":"tag referring to a commit but not directly?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-09T10:00:44Z","receivedAt":"2005-07-09T10:00:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I was playing with a tag that refers to another tag which refers\nto a commit, and found out that some things did not work as I\nexpected.\n\nIs it a PEBCAK on my part to expect tag-to-tag-to-commit to\nbehave the same way as a bare commit (or a tag to commit), or is\nthis just a bug?  I think the following two would fix what I\nfound, but I am not sure if I am using the \"struct object\" and\nfriends the way they are expected to be used.  I am uncertain\nabout what the expected behaviour should be either for that\nmatter; I admit that tags are new to me.\n\n---\n\n*** To find whom to ask about the thing I am butchering, I\n*** used the following pickaxe:\n\ngit-rev-list linus |\ngit-diff-tree --stdin -v -s \\\n-S'\tif (obj->type == tag_type)\n\t\tobj = ((struct tag *)obj)->tagged;'\n\ngit-rev-list linus |\ngit-diff-tree --stdin -v -s \\\n-S'\t/*\n\t * Tag object? Look what it points to..\n\t */\n\tif (object->type == tag_type) {'\n\n------------\ncd /opt/packrat/playpen/public/in-place/git/git.junio/\njit-diff 0:5\n# - master: format-patch: fix skipping of blank-lines (take 2)\n# + 5: tag deref until we get non tag\ndiff --git a/commit.c b/commit.c\n--- a/commit.c\n+++ b/commit.c\n@@ -52,8 +52,9 @@ struct commit *lookup_commit_reference(c\n \n \tif (!obj)\n \t\treturn NULL;\n-\tif (obj->type == tag_type)\n-\t\tobj = ((struct tag *)obj)->tagged;\n+\twhile (obj->type == tag_type)\n+\t\tobj = parse_object(((struct tag *)obj)->tagged->sha1);\n+\n \treturn check_commit(obj, sha1);\n }\n \ndiff --git a/rev-list.c b/rev-list.c\n--- a/rev-list.c\n+++ b/rev-list.c\n@@ -354,12 +354,12 @@ static struct commit *get_commit_referen\n \t/*\n \t * Tag object? Look what it points to..\n \t */\n-\tif (object->type == tag_type) {\n+\twhile (object->type == tag_type) {\n \t\tstruct tag *tag = (struct tag *) object;\n \t\tobject->flags |= flags;\n \t\tif (tag_objects && !(object->flags & UNINTERESTING))\n \t\t\tadd_pending_object(object, tag->tag);\n-\t\tobject = tag->tagged;\n+\t\tobject = parse_object(tag->tagged->sha1);\n \t}\n \n \t/*\n\nCompilation finished at Sat Jul  9 02:37:16\n"},{"id":"5936","messageId":"7v8y0dx24j.fsf@assigned-by-dhcp.cox.net","threadId":"1185","inReplyTo":"7v7jg0wb77.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Dereference tag repeatedly until we get a non-tag.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-11T06:55:56Z","receivedAt":"2005-07-11T06:55:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When we allow a tag object in place of a commit object, we only\ndereferenced the given tag once, which causes a tag that points\nat a tag that points at a commit to be rejected.  Instead,\ndereference tag repeatedly until we get a non-tag.\n\nThis patch makes change to two functions:\n\n - commit.c::lookup_commit_reference() is used by merge-base,\n   rev-tree and rev-parse to convert user supplied SHA1 to that of\n   a commit.\n - rev-list uses its own get_commit_reference() to do the same.\n\nDereferencing tags this way helps both of these uses.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n*** Whether having a tag pointing at another tag is a separate\n*** issue, but I do not see a reason to forbid it.  Maybe it\n*** is used to represent a chain of trust.\n\n commit.c   |    5 +++--\n rev-list.c |    4 ++--\n 2 files changed, 5 insertions(+), 4 deletions(-)\n\n0dc9377363ee73c5e3f3711d6f82e49886ce8c6a\ndiff --git a/commit.c b/commit.c\n--- a/commit.c\n+++ b/commit.c\n@@ -52,8 +52,9 @@ struct commit *lookup_commit_reference(c\n \n \tif (!obj)\n \t\treturn NULL;\n-\tif (obj->type == tag_type)\n-\t\tobj = ((struct tag *)obj)->tagged;\n+\twhile (obj->type == tag_type)\n+\t\tobj = parse_object(((struct tag *)obj)->tagged->sha1);\n+\n \treturn check_commit(obj, sha1);\n }\n \ndiff --git a/rev-list.c b/rev-list.c\n--- a/rev-list.c\n+++ b/rev-list.c\n@@ -367,12 +367,12 @@ static struct commit *get_commit_referen\n \t/*\n \t * Tag object? Look what it points to..\n \t */\n-\tif (object->type == tag_type) {\n+\twhile (object->type == tag_type) {\n \t\tstruct tag *tag = (struct tag *) object;\n \t\tobject->flags |= flags;\n \t\tif (tag_objects && !(object->flags & UNINTERESTING))\n \t\t\tadd_pending_object(object, tag->tag);\n-\t\tobject = tag->tagged;\n+\t\tobject = parse_object(tag->tagged->sha1);\n \t}\n \n \t/*\n"},{"id":"5956","messageId":"2cfc40320507110814256bef25@mail.gmail.com","threadId":"1185","inReplyTo":"7v8y0dx24j.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Dereference tag repeatedly until we get a non-tag.","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-07-11T15:14:53Z","receivedAt":"2005-07-11T15:14:53Z","isPatch":true,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"This seems reasonable to me. I have thought this would be useful on\nseveral occasions and haven't yet conceived of a counterexample where\nit would break something.\n\nOn 7/11/05, Junio C Hamano <junkio@cox.net> wrote:\n> When we allow a tag object in place of a commit object, we only\n> dereferenced the given tag once, which causes a tag that points\n> at a tag that points at a commit to be rejected.  Instead,\n> dereference tag repeatedly until we get a non-tag.\n> \n> This patch makes change to two functions:\n> \n>  - commit.c::lookup_commit_reference() is used by merge-base,\n>    rev-tree and rev-parse to convert user supplied SHA1 to that of\n>    a commit.\n>  - rev-list uses its own get_commit_reference() to do the same.\n> \n> Dereferencing tags this way helps both of these uses.\n> \n> Signed-off-by: Junio C Hamano <junkio@cox.net>\n> ---\n> \n> *** Whether having a tag pointing at another tag is a separate\n> *** issue, but I do not see a reason to forbid it.  Maybe it\n> *** is used to represent a chain of trust.\n> \n>  commit.c   |    5 +++--\n>  rev-list.c |    4 ++--\n>  2 files changed, 5 insertions(+), 4 deletions(-)\n> \n> 0dc9377363ee73c5e3f3711d6f82e49886ce8c6a\n> diff --git a/commit.c b/commit.c\n> --- a/commit.c\n> +++ b/commit.c\n> @@ -52,8 +52,9 @@ struct commit *lookup_commit_reference(c\n> \n>         if (!obj)\n>                 return NULL;\n> -       if (obj->type == tag_type)\n> -               obj = ((struct tag *)obj)->tagged;\n> +       while (obj->type == tag_type)\n> +               obj = parse_object(((struct tag *)obj)->tagged->sha1);\n> +\n>         return check_commit(obj, sha1);\n>  }\n> \n> diff --git a/rev-list.c b/rev-list.c\n> --- a/rev-list.c\n> +++ b/rev-list.c\n> @@ -367,12 +367,12 @@ static struct commit *get_commit_referen\n>         /*\n>          * Tag object? Look what it points to..\n>          */\n> -       if (object->type == tag_type) {\n> +       while (object->type == tag_type) {\n>                 struct tag *tag = (struct tag *) object;\n>                 object->flags |= flags;\n>                 if (tag_objects && !(object->flags & UNINTERESTING))\n>                         add_pending_object(object, tag->tag);\n> -               object = tag->tagged;\n> +               object = parse_object(tag->tagged->sha1);\n>         }\n> \n>         /*\n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n\n\n-- \nhomepage: http://www.zeta.org.au/~jon/\nblog: http://orwelliantremors.blogspot.com/\n"}]}