{"thread":{"id":"21333","subject":"feature \"git tag -r\" to show tags and commits they are pointing to","startedAt":"2009-10-22T21:24:20Z","lastAt":"2009-10-23T14:48:57Z","messageCount":5,"participants":["Eugene Sajine","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"125746","messageId":"76c5b8580910221424n220449b9vda26f032174b6fa7@mail.gmail.com","threadId":"21333","inReplyTo":null,"subject":"feature \"git tag -r\" to show tags and commits they are pointing to","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2009-10-22T21:24:20Z","receivedAt":"2009-10-22T21:24:20Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"Hi,\n\nCurrently there is no way you can get the commits your tags are\npointing to by using git tag.\nThe only way i found is to use rev-parse (which is by the way not\nsupported by the bash_completion)\n\nIt seems reasonable to have upper level command like:\n\n$ git tag -r\n\nto output\n\nv0.1  8794hke84f9e8h9ef9eh949793...\nv0.2  jhkd934398e9f499f47w9789o97...\n\n$ git tag -n -r\n\nv0.1 \"super message\"     8794hke84f9e8h9ef9eh949793...\nv0.2  \"another message\" jhkd934398e9f499f47w9789o9f...\n\n$ git tag -r v0.2\nv0.2  jhkd934398e9f499f47w9789o9f...\n\n\nWhat do you think?\n\nThanks,\nEugene\n"},{"id":"125748","messageId":"7vr5svf6x9.fsf@alter.siamese.dyndns.org","threadId":"21333","inReplyTo":"76c5b8580910221424n220449b9vda26f032174b6fa7@mail.gmail.com","subject":"Re: feature \"git tag -r\" to show tags and commits they are pointing to","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-22T21:35:46Z","receivedAt":"2009-10-22T21:35:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eugene Sajine <euguess@gmail.com> writes:\n\n> Hi,\n>\n> Currently there is no way you can get the commits your tags are\n> pointing to by using git tag.\n> The only way i found is to use rev-parse (which is by the way not\n> supported by the bash_completion)\n>\n> It seems reasonable to have upper level command like:\n>\n> $ git tag -r\n>\n> to output\n>\n> v0.1  8794hke84f9e8h9ef9eh949793...\n> v0.2  jhkd934398e9f499f47w9789o97...\n>\n> $ git tag -n -r\n>\n> v0.1 \"super message\"     8794hke84f9e8h9ef9eh949793...\n> v0.2  \"another message\" jhkd934398e9f499f47w9789o9f...\n>\n> $ git tag -r v0.2\n> v0.2  jhkd934398e9f499f47w9789o9f...\n>\n>\n> What do you think?\n\nNot intereseted at all, as this does not look anything more than \"because\nI could\", not \"because this is useful and sorely lacking\".\n\nThe \"super message\" and such are actually useful to humans, but \"v0.1\" is\nmuch more useful than 8794hke to humans, and these tag names are just as\nusable as the hexadecimal commit object names to the tools.  You can say\n\"git show v0.1^0\" and \"git show 8794hke\" and get the same thing.\n\nHeck, \"8794hke\" is not even hexadecimal, and the fact that you did not\neven notice it is a _S*RE_ sign that they are not useful to humans.\n\nIf you _are_ a human, that is ;-)\n\nIn other words, please do not justify such a proposal with \"I want to have\n'git tag' command to show the commit object name\".  Rather, justify _why_\n(1) you _need_ to show the commit object name to begin with, and (2) the\noutput _has_ to come from 'git tag' and not 'git rev-parse'.\n"},{"id":"125763","messageId":"76c5b8580910221930s4b31b180t8298c262d9d9f421@mail.gmail.com","threadId":"21333","inReplyTo":"7vr5svf6x9.fsf@alter.siamese.dyndns.org","subject":"Re: feature \"git tag -r\" to show tags and commits they are pointing to","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2009-10-23T02:30:37Z","receivedAt":"2009-10-23T02:30:37Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"Please, disregard...\n\nI was looking for this info in order to create second tag for the same\ncommit. For example if the first tag created by somebody or\nautomatically (CI, release system), so i could add a verbose tag.\n\nBut i just realized that i don't need commit id for that - just tag\nthe tag, stupid...\n\nThanks,\nEugene\n\n\nOn 10/22/09, Junio C Hamano <gitster@pobox.com> wrote:\n> Eugene Sajine <euguess@gmail.com> writes:\n>\n>> Hi,\n>>\n>> Currently there is no way you can get the commits your tags are\n>> pointing to by using git tag.\n>> The only way i found is to use rev-parse (which is by the way not\n>> supported by the bash_completion)\n>>\n>> It seems reasonable to have upper level command like:\n>>\n>> $ git tag -r\n>>\n>> to output\n>>\n>> v0.1  8794hke84f9e8h9ef9eh949793...\n>> v0.2  jhkd934398e9f499f47w9789o97...\n>>\n>> $ git tag -n -r\n>>\n>> v0.1 \"super message\"     8794hke84f9e8h9ef9eh949793...\n>> v0.2  \"another message\" jhkd934398e9f499f47w9789o9f...\n>>\n>> $ git tag -r v0.2\n>> v0.2  jhkd934398e9f499f47w9789o9f...\n>>\n>>\n>> What do you think?\n>\n> Not intereseted at all, as this does not look anything more than \"because\n> I could\", not \"because this is useful and sorely lacking\".\n>\n> The \"super message\" and such are actually useful to humans, but \"v0.1\" is\n> much more useful than 8794hke to humans, and these tag names are just as\n> usable as the hexadecimal commit object names to the tools.  You can say\n> \"git show v0.1^0\" and \"git show 8794hke\" and get the same thing.\n>\n> Heck, \"8794hke\" is not even hexadecimal, and the fact that you did not\n> even notice it is a _S*RE_ sign that they are not useful to humans.\n>\n> If you _are_ a human, that is ;-)\n>\n> In other words, please do not justify such a proposal with \"I want to have\n> 'git tag' command to show the commit object name\".  Rather, justify _why_\n> (1) you _need_ to show the commit object name to begin with, and (2) the\n> output _has_ to come from 'git tag' and not 'git rev-parse'.\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"},{"id":"125770","messageId":"7v8wf2ejna.fsf@alter.siamese.dyndns.org","threadId":"21333","inReplyTo":"76c5b8580910221930s4b31b180t8298c262d9d9f421@mail.gmail.com","subject":"Re: feature \"git tag -r\" to show tags and commits they are pointing to","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-23T05:58:33Z","receivedAt":"2009-10-23T05:58:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eugene Sajine <euguess@gmail.com> writes:\n\n> I was looking for this info in order to create second tag for the same\n> commit. For example if the first tag created by somebody or\n> automatically (CI, release system), so i could add a verbose tag.\n>\n> But i just realized that i don't need commit id for that - just tag\n> the tag, stupid...\n\nYou do not have to live with a tag that points at another tag that points\nat a commit.\n\nYou can still tag the commit directly with your new tag, and you do not\nneed to have the exact commit object name to do so.  You just tell the\ntool to follow the tag chain to get to the pointed-to object, like this:\n\n    $ git tag -a -m \"my message\" newtag oldtag^0\n\nThis assumes [*1*] that the old tag points at (strictly speaking, \"might\npoint at\") a commit object, and uses \"^0\" (zeroth parent of) operator to\nmake sure that the object the newtag points at (the last argument to the\n\"git tag\" command, i.e. \"oldtag^0\" in this example) is a commit object,\nnot an annotated tag \"oldtag\" itself.\n\nThat is what I meant by \"just as usable as hexadecimal to the tools\".\n\n>> ... \"v0.1\" is\n>> much more useful than 8794hke to humans, and these tag names are just as\n>> usable as the hexadecimal commit object names to the tools.  You can say\n>> \"git show v0.1^0\" and \"git show 8794hke\" and get the same thing.\n\n[Footnote]\n\n*1* A tag can point at any object, not necessarily a commit.  If oldtag\npoints at a tree object (or a blob object), oldtag^0 will fail, because\nthe operator \"^0\" is \"zeroth parent of\", and is applicable only to a\ncommit.  In general, you can write\n\n    $ git tag -a -m \"my message\" newtag oldtag^{}\n\nThe \"^{}\" operator is a special case of \"^{type}\" operator; the former\nmeans \"dereference the tag repeatedly until it becomes something that is\nnot a tag\", and the latter means \"dereference the tag repeatedly until it\nbecomes something of that type\".  I.e. \"oldtag^0\" is \"oldtag^{commit}\".\n"},{"id":"125786","messageId":"76c5b8580910230748n620ad3a8o58811732be7c369f@mail.gmail.com","threadId":"21333","inReplyTo":"7v8wf2ejna.fsf@alter.siamese.dyndns.org","subject":"Re: feature \"git tag -r\" to show tags and commits they are pointing to","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2009-10-23T14:48:57Z","receivedAt":"2009-10-23T14:48:57Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"> You do not have to live with a tag that points at another tag that points\n> at a commit.\n>\n> You can still tag the commit directly with your new tag, and you do not\n> need to have the exact commit object name to do so.  You just tell the\n> tool to follow the tag chain to get to the pointed-to object, like this:\n>\n>    $ git tag -a -m \"my message\" newtag oldtag^0\n>\n> This assumes [*1*] that the old tag points at (strictly speaking, \"might\n> point at\") a commit object, and uses \"^0\" (zeroth parent of) operator to\n> make sure that the object the newtag points at (the last argument to the\n> \"git tag\" command, i.e. \"oldtag^0\" in this example) is a commit object,\n> not an annotated tag \"oldtag\" itself.\n>\n> That is what I meant by \"just as usable as hexadecimal to the tools\".\n>\n>>> ... \"v0.1\" is\n>>> much more useful than 8794hke to humans, and these tag names are just as\n>>> usable as the hexadecimal commit object names to the tools.  You can say\n>>> \"git show v0.1^0\" and \"git show 8794hke\" and get the same thing.\n>\n> [Footnote]\n>\n> *1* A tag can point at any object, not necessarily a commit.  If oldtag\n> points at a tree object (or a blob object), oldtag^0 will fail, because\n> the operator \"^0\" is \"zeroth parent of\", and is applicable only to a\n> commit.  In general, you can write\n>\n>    $ git tag -a -m \"my message\" newtag oldtag^{}\n>\n> The \"^{}\" operator is a special case of \"^{type}\" operator; the former\n> means \"dereference the tag repeatedly until it becomes something that is\n> not a tag\", and the latter means \"dereference the tag repeatedly until it\n> becomes something of that type\".  I.e. \"oldtag^0\" is \"oldtag^{commit}\".\n>\n\nJunio,\n\nThank you very much for such detailed explanation! I do appreciate it.\n\n\nEugene\n"}]}