{"thread":{"id":"34211","subject":"[PATCH] peel_onion(): add support for <rev>^{tag}","startedAt":"2013-06-19T01:39:06Z","lastAt":"2013-06-20T18:03:39Z","messageCount":5,"participants":["Richard Hansen","Junio C Hamano","Ramkumar Ramachandra"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"221311","messageId":"1371605946-32565-1-git-send-email-rhansen@bbn.com","threadId":"34211","inReplyTo":null,"subject":"[PATCH] peel_onion(): add support for <rev>^{tag}","fromName":"Richard Hansen","fromEmail":"rhansen@bbn.com","sentAt":"2013-06-19T01:39:06Z","receivedAt":"2013-06-19T01:39:06Z","isPatch":true,"sender":{"key":"rhansen@rhansen.org","avatar":null},"body":"gitrevisions(7) implies that <rev>^{tag} should work, but before now\nit did not:\n\n    $ git rev-parse --verify v1.8.3.1^{tag}\n    fatal: Needed a single revision\n\nThis commit fixes the omission:\n\n    $ git rev-parse --verify v1.8.3.1^{tag}\n    4bc068950abec778a02ebf3ee73cf0735affabb4\n\nOther object type names work as expected:\n\n    $ git rev-parse --verify v1.8.3.1^{commit}\n    362de916c06521205276acb7f51c99f47db94727\n    $ git rev-parse --verify v1.8.3.1^{tree}\n    c1fef48675edd74e9af19405339e8bdaebd56b0c\n    $ git rev-parse --verify v1.8.3.1^{blob}\n    error: v1.8.3.1^{blob}: expected blob type, but the object dereferences to tree type\n    fatal: Needed a single revision\n\nNote that <rev>^{tag} is not the same as <rev>^{object} when <rev> is\nnot a tag:\n\n    $ git rev-parse --verify v1.8.3.1^{}^{object}\n    362de916c06521205276acb7f51c99f47db94727\n    $ git rev-parse --verify v1.8.3.1^{}^{tag}\n    error: v1.8.3.1^{}^{tag}: expected tag type, but the object dereferences to tree type\n    fatal: Needed a single revision\n\nSigned-off-by: Richard Hansen <rhansen@bbn.com>\n---\n sha1_name.c | 2 ++\n 1 file changed, 2 insertions(+)\n\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 90419ef..68fd0e4 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -677,6 +677,8 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)\n \tsp++; /* beginning of type name, or closing brace for empty */\n \tif (!strncmp(commit_type, sp, 6) && sp[6] == '}')\n \t\texpected_type = OBJ_COMMIT;\n+\telse if (!strncmp(tag_type, sp, 3) && sp[3] == '}')\n+\t\texpected_type = OBJ_TAG;\n \telse if (!strncmp(tree_type, sp, 4) && sp[4] == '}')\n \t\texpected_type = OBJ_TREE;\n \telse if (!strncmp(blob_type, sp, 4) && sp[4] == '}')\n-- \n1.8.3.1\n"},{"id":"221393","messageId":"7vvc5aymhd.fsf@alter.siamese.dyndns.org","threadId":"34211","inReplyTo":"1371605946-32565-1-git-send-email-rhansen@bbn.com","subject":"Re: [PATCH] peel_onion(): add support for <rev>^{tag}","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-19T18:38:38Z","receivedAt":"2013-06-19T18:38:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Richard Hansen <rhansen@bbn.com> writes:\n\n> gitrevisions(7) implies that <rev>^{tag} should work,...\n\nDoes it?  Is it possible that that should be fixed?\n\nWhat does it even _mean_ to peel something to a TAG?\n\nA commit, a tree or a blob cannot be peeled to a tag---none of them\ncan contain a tag.\n\nWhen you have a tag that points at something else, what you have is\nalready a tag, so <that-tag>^{tag} would be <that-tag> itself.\n\nEven more confusingly, when you have a tag that points at another\ntag, what does <that-outer-tag>^{tag} mean?  The outer tag itself,\nor do you need to peel at least once to reveal the inner-tag?  What\nif that inner-tag points at yet another tag?\n\nThe patch does not touch peel_to_type(), so your answer to the above\nquestion seems to be \"if T is already a tag, T^{tag} is T itself\",\nbut then that operation does not look all that useful.\n\nConfused...\n\n> diff --git a/sha1_name.c b/sha1_name.c\n> index 90419ef..68fd0e4 100644\n> --- a/sha1_name.c\n> +++ b/sha1_name.c\n> @@ -677,6 +677,8 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)\n>  \tsp++; /* beginning of type name, or closing brace for empty */\n>  \tif (!strncmp(commit_type, sp, 6) && sp[6] == '}')\n>  \t\texpected_type = OBJ_COMMIT;\n> +\telse if (!strncmp(tag_type, sp, 3) && sp[3] == '}')\n> +\t\texpected_type = OBJ_TAG;\n>  \telse if (!strncmp(tree_type, sp, 4) && sp[4] == '}')\n>  \t\texpected_type = OBJ_TREE;\n>  \telse if (!strncmp(blob_type, sp, 4) && sp[4] == '}')\n"},{"id":"221406","messageId":"51C20FD1.4090203@bbn.com","threadId":"34211","inReplyTo":"7vvc5aymhd.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] peel_onion(): add support for <rev>^{tag}","fromName":"Richard Hansen","fromEmail":"rhansen@bbn.com","sentAt":"2013-06-19T20:08:49Z","receivedAt":"2013-06-19T20:08:49Z","isPatch":true,"sender":{"key":"rhansen@rhansen.org","avatar":null},"body":"On 2013-06-19 14:38, Junio C Hamano wrote:\n> Richard Hansen <rhansen@bbn.com> writes:\n> \n>> gitrevisions(7) implies that <rev>^{tag} should work,...\n> \n> Does it?  Is it possible that that should be fixed?\n\nDepends on whether you think ^{tag} is a useful feature or not; see below.\n\n> \n> What does it even _mean_ to peel something to a TAG?\n\nIt's the same as peeling something to any other object type:  If the\nobject is that type, done.  Otherwise dereference and try again.  If it\ncan't be dereferenced, barf.\n\n> \n> A commit, a tree or a blob cannot be peeled to a tag---none of them\n> can contain a tag.\n\nRight, so all of those would barf.\n\n> \n> When you have a tag that points at something else, what you have is\n> already a tag, so <that-tag>^{tag} would be <that-tag> itself.\n\nExactly, just like <object>^{object} is <object> itself.\n\n> \n> Even more confusingly, when you have a tag that points at another\n> tag, what does <that-outer-tag>^{tag} mean?  The outer tag itself,\n> or do you need to peel at least once to reveal the inner-tag?  What\n> if that inner-tag points at yet another tag?\n> \n> The patch does not touch peel_to_type(), so your answer to the above\n> question seems to be \"if T is already a tag, T^{tag} is T itself\",\n> but then that operation does not look all that useful.\n\nBarfing on non-tags is the feature this adds.  It's otherwise useless,\njust like <object>^{object} is useless except to barf when <object>\ndoesn't exist.\n\nIt's a sometimes-convenient way to assert that an object specifier\nrefers to a tag object and not something else.  For example, instead of:\n\n   fatal() { printf %s\\\\n \"ERROR: $*\" >&2; exit 1; }\n\n   type=$(git cat-file -t \"$1\") || fatal \"$1 is not a valid object\"\n   [ \"${type}\" = tag ] || fatal \"$1 is not a tag object\"\n   use \"$1\" here\n\nyou can do:\n\n   use \"$1\"^{tag} here\n\n-Richard\n\n\n> \n> Confused...\n> \n>> diff --git a/sha1_name.c b/sha1_name.c\n>> index 90419ef..68fd0e4 100644\n>> --- a/sha1_name.c\n>> +++ b/sha1_name.c\n>> @@ -677,6 +677,8 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)\n>>  \tsp++; /* beginning of type name, or closing brace for empty */\n>>  \tif (!strncmp(commit_type, sp, 6) && sp[6] == '}')\n>>  \t\texpected_type = OBJ_COMMIT;\n>> +\telse if (!strncmp(tag_type, sp, 3) && sp[3] == '}')\n>> +\t\texpected_type = OBJ_TAG;\n>>  \telse if (!strncmp(tree_type, sp, 4) && sp[4] == '}')\n>>  \t\texpected_type = OBJ_TREE;\n>>  \telse if (!strncmp(blob_type, sp, 4) && sp[4] == '}')\n> \n"},{"id":"221496","messageId":"CALkWK0n5NMBFC_eE8V_Avy57RrBOgDuUs+V_VMvNY6VkBBZyBQ@mail.gmail.com","threadId":"34211","inReplyTo":"1371605946-32565-1-git-send-email-rhansen@bbn.com","subject":"Re: [PATCH] peel_onion(): add support for <rev>^{tag}","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-20T17:14:27Z","receivedAt":"2013-06-20T17:14:27Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Richard Hansen wrote:\n> --- a/sha1_name.c\n> +++ b/sha1_name.c\n> @@ -677,6 +677,8 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)\n>         sp++; /* beginning of type name, or closing brace for empty */\n>         if (!strncmp(commit_type, sp, 6) && sp[6] == '}')\n>                 expected_type = OBJ_COMMIT;\n> +       else if (!strncmp(tag_type, sp, 3) && sp[3] == '}')\n> +               expected_type = OBJ_TAG;\n\nInteresting.\n\n> gitrevisions(7) implies that <rev>^{tag} should work, but before now\n> it did not:\n\nThe wording (especially of <rev>^{}) special-cases tags as \"objects to\ndereference\".\n\n>     $ git rev-parse --verify v1.8.3.1^{}^{object}\n>     362de916c06521205276acb7f51c99f47db94727\n>     $ git rev-parse --verify v1.8.3.1^{}^{tag}\n>     error: v1.8.3.1^{}^{tag}: expected tag type, but the object dereferences to tree type\n>     fatal: Needed a single revision\n\nAnd the points out the problem: while ^{object} means \"expect\nOBJ_ANY\", ^{} means \"expect OBJ_NONE\".  What does that even mean?  See\nsha1_name.c:704 where this is handled sneakily: it just calls\nderef_tag(), bypassing peel_to_type() altogether.  If anything, ^{} is\nalready a poor-man's version of your ^{tag}; the reason it's a\npoor-man's version is precisely because it doesn't error out when\n<rev> isn't a tag, while your ^{tag} does.  I would argue that ^{} is\nvery poorly done and must be deprecated in favor of your ^{tag}.  What\nis the point of using ^{} if you can't even be sure that what you get\nis a deref?  peel_to_type() already does the right thing by not using\nderef_tag(), and explicitly checking.\n\nYour commit message needs some tweaking, but I'm happy with your patch\notherwise.\n\nThanks.\n"},{"id":"221498","messageId":"7v4ncswtfo.fsf@alter.siamese.dyndns.org","threadId":"34211","inReplyTo":"51C20FD1.4090203@bbn.com","subject":"Re: [PATCH] peel_onion(): add support for <rev>^{tag}","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-20T18:03:39Z","receivedAt":"2013-06-20T18:03:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Richard Hansen <rhansen@bbn.com> writes:\n\n> Barfing on non-tags is the feature this adds.  It's otherwise useless,\n> just like <object>^{object} is useless except to barf when <object>\n> doesn't exist.\n\nThanks.\n\nI could buy that.  And after re-reading the proposed log message,\nyou do not quite have anything to say that.  Instead, you have this:\n\n    Note that <rev>^{tag} is not the same as <rev>^{object} when <rev> is\n    not a tag:\n\n        $ git rev-parse --verify v1.8.3.1^{}^{object}\n        362de916c06521205276acb7f51c99f47db94727\n        $ git rev-parse --verify v1.8.3.1^{}^{tag}\n        error: v1.8.3.1^{}^{tag}: expected tag type, but the object deref...\n        fatal: Needed a single revision\n\nThe latter peels v1.8.3.1 to a non-tag (i.e. a commit) and then asks\nto peel that commit to a tag, which will of course fail, but that is\nnot a good example.  \n\nPerhaps something like this instead.\n\n    Note that <rev>^{tag} can be used to make sure <rev> names a tag:\n\n        $ git rev-parse --verify v1.8.3.1^{tag}\n        $ git rev-parse --verify master^{tag}\n\n    The former succeeds, while the latter fails.\n"}]}