{"thread":{"id":"8395","subject":"[PATCH] Add option -L to git-tag.","startedAt":"2007-06-02T08:37:45Z","lastAt":"2007-06-03T00:04:06Z","messageCount":5,"participants":["Matthijs Melchior","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"43791","messageId":"1180773465209-git-send-email-mmelchior@xs4all.nl","threadId":"8395","inReplyTo":null,"subject":"[PATCH] Add option -L to git-tag.","fromName":"Matthijs Melchior","fromEmail":"mmelchior@xs4all.nl","sentAt":"2007-06-02T08:37:45Z","receivedAt":"2007-06-02T08:37:45Z","isPatch":true,"sender":{"key":"mmelchior@xs4all.nl","avatar":null},"body":"  This will list the selected tags and include annotations, if any.\n\nSigned-off-by: Matthijs Melchior <mmelchior@xs4all.nl>\n---\n\nThis patch has been created to allow me to easily see the annotations with tags.\nI have not found any other way to do this...\n\nSome remarks on the new bit of code:\n - Sorting the tag names resulting from git-rev-parse is not nessecary since\n   the list of tags is already deliverd in sorted order.\n - Using git-cat-file -t on every tag is expensive, but there is no alternative\n\n  -Matthijs\n\n Documentation/git-tag.txt |    5 ++++-\n git-tag.sh                |   24 +++++++++++++++++-------\n 2 files changed, 21 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt\nindex 4e3e027..441f361 100644\n--- a/Documentation/git-tag.txt\n+++ b/Documentation/git-tag.txt\n@@ -11,7 +11,7 @@ SYNOPSIS\n [verse]\n 'git-tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]  <name> [<head>]\n 'git-tag' -d <name>...\n-'git-tag' -l [<pattern>]\n+'git-tag' [-l | -L] [<pattern>]\n 'git-tag' -v <name>\n \n DESCRIPTION\n@@ -41,6 +41,9 @@ GnuPG key for signing.\n `-l <pattern>` lists tags that match the given pattern (or all\n if no pattern is given).\n \n+`-L <pattern>` lists tags, including their annotations, that match\n+the given pattern (or all if no pattern is given).\n+\n OPTIONS\n -------\n -a::\ndiff --git a/git-tag.sh b/git-tag.sh\nindex 6f0b7a7..45c4253 100755\n--- a/git-tag.sh\n+++ b/git-tag.sh\n@@ -1,7 +1,7 @@\n #!/bin/sh\n # Copyright (c) 2005 Linus Torvalds\n \n-USAGE='-l [<pattern>] | [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg>] <tagname> [<head>]'\n+USAGE='[-l | -L] [<pattern>] | [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg>] <tagname> [<head>]'\n SUBDIRECTORY_OK='Yes'\n . git-sh-setup\n \n@@ -26,13 +26,23 @@ do\n     -f)\n \tforce=1\n \t;;\n-    -l)\n-\tcase \"$#\" in\n-\t1)\n-\t\tset x . ;;\n-\tesac\n+    -l|-L)\n+\tTAGSONLY=true\n+\t[ \"$1\" = -L ] && TAGSONLY=false\n+\t[ \"$#\" = 1 ] && set x .\n \tshift\n-\tgit rev-parse --symbolic --tags | sort | grep \"$@\"\n+\tgit rev-parse --symbolic --tags | grep \"$@\" |\n+\t    while read TAG\n+\t    do\n+\t\techo \"$TAG\"\n+\t\t$TAGSONLY && continue\n+\t\tOBJTYPE=$(git cat-file -t \"$TAG\")\n+\t\tcase $OBJTYPE in\n+\t\t    tag)    git cat-file $OBJTYPE \"$TAG\" |\n+\t\t\t\tsed '1,/^$/d;/^-----BEGIN PGP SIGNATURE-----$/Q;s/^/    /'\n+\t\t\t    ;;\n+\t\tesac\n+\t    done\n \texit $?\n \t;;\n     -m)\n-- \n1.5.2\n"},{"id":"43795","messageId":"7vfy5avf89.fsf@assigned-by-dhcp.cox.net","threadId":"8395","inReplyTo":"1180773465209-git-send-email-mmelchior@xs4all.nl","subject":"Re: [PATCH] Add option -L to git-tag.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-06-02T10:10:46Z","receivedAt":"2007-06-02T10:10:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthijs Melchior <mmelchior@xs4all.nl> writes:\n\n>   This will list the selected tags and include annotations, if any.\n>\n> Signed-off-by: Matthijs Melchior <mmelchior@xs4all.nl>\n> ---\n>\n> This patch has been created to allow me to easily see the annotations with tags.\n> I have not found any other way to do this...\n\nHmmmm.  This feature ought to belong to git-show, but that\ncommand already has its own interpretation of how a tag should\nbe shown.\n\nDo we care about the \"one line summary\"?  Perhaps...\n\n\t$ git tag --pretty=short -L v2.6.11-tree\n\tv2.6.11-tree\n            This is the 2.6.11 tree object.\n\n\t$ git tag -L v2.6.11-tree\n\tv2.6.11-tree\n            This is the 2.6.11 tree object.\n\n\t    NOTE! There's no commit for this, since it happened...\n\nThe answer to this question would really depend on why we would\nwant to have this feature.  \"git-tag\" started as a way to\n\"create\", and then it gained -l to \"list\" and -v to \"verify\".  I\nthink your -L is meant to be an extension to \"list\", but I\nsuspect that while you are listing many things you would keep\nthe annotation short-and-sweet, and you would want to view the\nfull description when your interest is focused at a single one.\nMaybe we would want a separate \"print\" action for the full\ncontents and use the short one for \"list but more verbosely than\nusual\"?\n\nI dunno; I've never been very good at the user interfaces.\n\n>  - Sorting the tag names resulting from git-rev-parse is not nessecary since\n>    the list of tags is already deliverd in sorted order.\n\nThis I am a bit reluctant about, as that sorting done by\nrev-parse is purely by accident (i.e. it is an implementation\ndetail).\n\n>  - Using git-cat-file -t on every tag is expensive, but there is no alternative\n\nThis is Ok, as we have somebody working on doing git-tag as a\nbuilt-in, and once that happens, we do not have to pay the\nperformance penalty.  So I would think at this point we should\nconcentrate on discussing the usefulness of this new feature and\ncorrectness of your implementation, as that would set the course\nfor the future.  On the other hand, \"cat-file -t\" performance\nissues will not stay with us forever.\n\n> @@ -26,13 +26,23 @@ do\n>      -f)\n>  \tforce=1\n>  \t;;\n> -    -l)\n> -\tcase \"$#\" in\n> -\t1)\n> -\t\tset x . ;;\n> -\tesac\n> +    -l|-L)\n> +\tTAGSONLY=true\n> +\t[ \"$1\" = -L ] && TAGSONLY=false\n> +\t[ \"$#\" = 1 ] && set x .\n>  \tshift\n> +\tgit rev-parse --symbolic --tags | grep \"$@\" |\n> +\t    while read TAG\n> +\t    do\n> +\t\techo \"$TAG\"\n> +\t\t$TAGSONLY && continue\n> +\t\tOBJTYPE=$(git cat-file -t \"$TAG\")\n> +\t\tcase $OBJTYPE in\n> +\t\t    tag)    git cat-file $OBJTYPE \"$TAG\" |\n> +\t\t\t\tsed '1,/^$/d;/^-----BEGIN PGP SIGNATURE-----$/Q;s/^/    /'\n> +\t\t\t    ;;\n> +\t\tesac\n\nMicronit.  If you already know it is a tag, you do not have to\nsay \"cat-file $OBJTYPE\".\n\nStyle.  Please indent the case arm to the same level as, not\ndeeper than, case/esac.\nThis is the same as C's switch() { case ...: } indentation rule.\n\nPlease do not feed multiple expressions concatenated with\nsemicolon to sed, as it is one of the often observed portability\nissues (not all the world is GNU yet).  Write it like this\ninstead:\n\n        case \"$OBJTYPE\" in\n        tag)\n                git cat-file tag \"$TAG\" |\n                sed -e '1,/^$/d' \\\n                    -e '/^-----BEGIN PGP SIGNATURE-----$/Q' \\\n                    -e s/^/    /'\n                ;;\n        esac\n\n> +\t    done\n>  \texit $?\n\nWhat does this command exit with now?  It used to be that\n\n\t$ git tag -l no-such-tag-at-all ; echo $?\n\nsaid \"1\", I think, because grep did not match.\n"},{"id":"43804","messageId":"46616C19.4020800@xs4all.nl","threadId":"8395","inReplyTo":"7vfy5avf89.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add option -L to git-tag.","fromName":"Matthijs Melchior","fromEmail":"mmelchior@xs4all.nl","sentAt":"2007-06-02T13:09:45Z","receivedAt":"2007-06-02T13:09:45Z","isPatch":true,"sender":{"key":"mmelchior@xs4all.nl","avatar":null},"body":"Junio C Hamano wrote:\n> Matthijs Melchior <mmelchior@xs4all.nl> writes:\n>\n>   \n>>   This will list the selected tags and include annotations, if any.\n>>\n>> Signed-off-by: Matthijs Melchior <mmelchior@xs4all.nl>\n>> ---\n>>\n>> This patch has been created to allow me to easily see the annotations with tags.\n>> I have not found any other way to do this...\n>>     \n>\n> Hmmmm.  This feature ought to belong to git-show, but that\n> command already has its own interpretation of how a tag should\n> be shown.\n>\n> Do we care about the \"one line summary\"?  Perhaps...\n>\n> \t$ git tag --pretty=short -L v2.6.11-tree\n> \tv2.6.11-tree\n>             This is the 2.6.11 tree object.\n>\n> \t$ git tag -L v2.6.11-tree\n> \tv2.6.11-tree\n>             This is the 2.6.11 tree object.\n>\n> \t    NOTE! There's no commit for this, since it happened...\n>\n> The answer to this question would really depend on why we would\n> want to have this feature.  \"git-tag\" started as a way to\n> \"create\", and then it gained -l to \"list\" and -v to \"verify\".  I\n> think your -L is meant to be an extension to \"list\", but I\n> suspect that while you are listing many things you would keep\n> the annotation short-and-sweet, and you would want to view the\n> full description when your interest is focused at a single one.\n> Maybe we would want a separate \"print\" action for the full\n> contents and use the short one for \"list but more verbosely than\n> usual\"?\n>\n> I dunno; I've never been very good at the user interfaces.\n>   \nYes, since I have this command and have seen the tag annotations in the\ngit repository, I think we need this extra parameter.\nI propose to give the number of lines you want to see, with 0 gives all.\nSo it will be --pretty=<max-number-lines> to limit the output and be\nable to find interesting stuff before looking at the complete message.\n\nIn the project where I wanted this, the tag annotations are only a few\nlines max...\nI have used this to remember special status of of a commit, such as release\nversion and date.  In order to quickly find such a thing I wanted to see\nall the annotations.\n>   \n>>  - Sorting the tag names resulting from git-rev-parse is not nessecary since\n>>    the list of tags is already deliverd in sorted order.\n>>     \n>\n> This I am a bit reluctant about, as that sorting done by\n> rev-parse is purely by accident (i.e. it is an implementation\n> detail).\n>   \nThis accident can be repaired by documenting it.... :)\n>   \n>>  - Using git-cat-file -t on every tag is expensive, but there is no alternative\n>>     \n>\n> This is Ok, as we have somebody working on doing git-tag as a\n> built-in, and once that happens, we do not have to pay the\n> performance penalty.  So I would think at this point we should\n> concentrate on discussing the usefulness of this new feature and\n> correctness of your implementation, as that would set the course\n> for the future.  On the other hand, \"cat-file -t\" performance\n> issues will not stay with us forever.\n>\n>   \n>> @@ -26,13 +26,23 @@ do\n>>      -f)\n>>  \tforce=1\n>>  \t;;\n>> -    -l)\n>> -\tcase \"$#\" in\n>> -\t1)\n>> -\t\tset x . ;;\n>> -\tesac\n>> +    -l|-L)\n>> +\tTAGSONLY=true\n>> +\t[ \"$1\" = -L ] && TAGSONLY=false\n>> +\t[ \"$#\" = 1 ] && set x .\n>>  \tshift\n>> +\tgit rev-parse --symbolic --tags | grep \"$@\" |\n>> +\t    while read TAG\n>> +\t    do\n>> +\t\techo \"$TAG\"\n>> +\t\t$TAGSONLY && continue\n>> +\t\tOBJTYPE=$(git cat-file -t \"$TAG\")\n>> +\t\tcase $OBJTYPE in\n>> +\t\t    tag)    git cat-file $OBJTYPE \"$TAG\" |\n>> +\t\t\t\tsed '1,/^$/d;/^-----BEGIN PGP SIGNATURE-----$/Q;s/^/    /'\n>> +\t\t\t    ;;\n>> +\t\tesac\n>>     \n>\n> Micronit.  If you already know it is a tag, you do not have to\n> say \"cat-file $OBJTYPE\".\n>   \nYes, this was left over from an older prototype.....\n> Style.  Please indent the case arm to the same level as, not\n> deeper than, case/esac.\n> This is the same as C's switch() { case ...: } indentation rule.\n>\n> Please do not feed multiple expressions concatenated with\n> semicolon to sed, as it is one of the often observed portability\n> issues (not all the world is GNU yet).  Write it like this\n> instead:\n>\n>         case \"$OBJTYPE\" in\n>         tag)\n>                 git cat-file tag \"$TAG\" |\n>                 sed -e '1,/^$/d' \\\n>                     -e '/^-----BEGIN PGP SIGNATURE-----$/Q' \\\n>                     -e s/^/    /'\n>                 ;;\n>         esac\n>\n>   \n>> +\t    done\n>>  \texit $?\n>>     \nOK, I'll use this style.\n> What does this command exit with now?  It used to be that\n>\n> \t$ git tag -l no-such-tag-at-all ; echo $?\n>\n> said \"1\", I think, because grep did not match.\n>   \nIt will always exit 0, either from sed or git-cat.\n\nI will send a new patch with better style, a --pretty=n option and\nagain exit code from grep.\n (maybe the exit code is not worth the added complexity...).\n\n\nThanks.\n\n-- \nRegards,\n----------------------------------------------------------------  -o)\nMatthijs Melchior                                       Maarssen  /\\\\\nmmelchior@xs4all.nl                                  Netherlands _\\_v\n---------------------------------------------------------------- ----\n"},{"id":"43817","messageId":"7vvee6qkr4.fsf@assigned-by-dhcp.cox.net","threadId":"8395","inReplyTo":"46616C19.4020800@xs4all.nl","subject":"Re: [PATCH] Add option -L to git-tag.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-06-02T18:22:39Z","receivedAt":"2007-06-02T18:22:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthijs Melchior <mmelchior@xs4all.nl> writes:\n\n> Junio C Hamano wrote:\n> ...\n>> I dunno; I've never been very good at the user interfaces.\n>>   \n> Yes, since I have this command and have seen the tag annotations in the\n> git repository, I think we need this extra parameter.\n> I propose to give the number of lines you want to see, with 0 gives all.\n> So it will be --pretty=<max-number-lines> to limit the output and be\n> able to find interesting stuff before looking at the complete message.\n\nPlease do not use the same word used elsewhere ('pretty') and\nmake it mean something different (they are 'short', 'oneline', etc.\nin other places).\n\nRegardless of how we might do a single-liner output, I suspect that\nInstead of showing them like this (your patch):\n\n\t$ git tag -L v2.6.1* | head -n 6\n\tv2.6.11\n            This is the 2.6.11 tree object.\n\tv2.6.11-tree\n            This is the 2.6.11 tree object.\n\tv2.6.12\n            This is the final 2.6.12 release\n\nshowing them in this way might be more pleasant:\n\n\t$ git tag -L v2.6.1* | head -n 3\n\tv2.6.11      This is the 2.6.11 tree object.\n\tv2.6.11-tree This is the 2.6.11 tree object.\n\tv2.6.12      This is the final 2.6.12 release\n\nThis matches the way \"git branch -v\" without other arguments,\nwhich I think is the moral equivalent for branches to your \"git\ntag -L\", shows a bit more information than the usual (we could\neven say \"git tag -l -v\" but -v is already taken -- we could\nstill do \"git tag --list --verbose\" and leave the short '-v' to\nmean 'verify' but I dunno).\n\nThis is a slightly related tangent, but I've been wanting to\nextend the \"the first line is special 'one-line summary',\nseparated by a blank line from the rest of the more descriptive\nmessage\" convention used in the commit log message formatter.\nWhen somebody asks for --pretty=oneline, instead of showing the\n\"first line\", we would give the first paragraph, with LFs\nreplaced with SPs to make it a single line.  This would not\naffect commit log messages that follow the above convention.\n\nIf your tags have a few lines to describe what the commits are\nabout, it might make it easier to get the overview by applying\nthe same \"first paragraph squashed down to a single line\" logic,\ngrab the first paragraph, present it as a one-liner\" in the\nformat shown above.\n\n>>>  - Sorting the tag names resulting from git-rev-parse is not nessecary since\n>>>    the list of tags is already deliverd in sorted order.\n>>\n>> This I am a bit reluctant about, as that sorting done by\n>> rev-parse is purely by accident (i.e. it is an implementation\n>> detail).\n>>   \n> This accident can be repaired by documenting it.... :)\n\nThat would cast the implementation in stone, avoidance of which\nwas the point of my comment.\n\n>> What does this command exit with now?  It used to be that\n>>\n>> \t$ git tag -l no-such-tag-at-all ; echo $?\n>>\n>> said \"1\", I think, because grep did not match.\n>>   \n> It will always exit 0, either from sed or git-cat.\n>\n> ...\n>\n>  (maybe the exit code is not worth the added complexity...).\n\nThat's 40% satisfactory answer.\n\nI do not speak for others, but when I comment on a patch, saying\n\"This might be better done this other way\", or \"This change\nmight be bad\", I do not necessarily expect/want you to agree\nwith me on all counts.  I would very much be happier to get a\ncounter argument back -- that's how we both learn things and\nmake progress.\n\nUnlike Linus, I am not always right ;-)\n\nBut more seriously, I sometimes deliberately make suggestions\nthat I know are not optimal, because I want to involve other\npeople (not necessarily the author of the patch, but others on\nthe list) in the process of making improvements.\n\nThe \"40%\" satisfactory part comes from that you correctly\nanswered that your version now always exits zero while the\noriginal diagnosed the \"no such tag whatsoever\" situation with\nnon-zero exit, with a slight hint that you think it might be\nbetter not to differenciate the \"no match\" case.\n\nWhat I would prefer to see is to make that \"slight hint\" more\nexplicit.  As you say, \"is not worth the added complexity\" is a\npossible justification, but in this particular case, I think we\ncould (and probably should) even argue that the current exit\ncode is not so useful.  It might go like this...\n\n    Although \"git tag -l <pattern>\" currently signals non-match\n    with its exit code, \"git tag -l do-i-have-this-tag\" is not\n    the right way to ask that question to begin with, because\n    the tagname parameter is always taken as a pattern.  For\n    that, \"git show-ref --verify refs/tags/do-i-have-this-tag\"\n    is much better.  I do not think the current exit status from\n    \"git-tag -l <pattern>\" is useful, and we should change it to\n    exit with 0 unless we see other errors (e.g. \"not a git\n    repository\"), regardless of the addition of -L option.\n\nand you would have got the remaining 60% ;-).\n\nI care about documenting the change in behaviour and justifying\nwhy we changed the behavikour in the commit log.\n"},{"id":"43836","messageId":"f3t0hn$siq$1@sea.gmane.org","threadId":"8395","inReplyTo":"7vvee6qkr4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add option -L to git-tag.","fromName":"Matthijs Melchior","fromEmail":"mmelchior@xs4all.nl","sentAt":"2007-06-03T00:04:06Z","receivedAt":"2007-06-03T00:04:06Z","isPatch":true,"sender":{"key":"mmelchior@xs4all.nl","avatar":null},"body":"Junio C Hamano wrote:\n> Matthijs Melchior <mmelchior@xs4all.nl> writes:\n> \n>> Junio C Hamano wrote:\n>> ...\n>>> I dunno; I've never been very good at the user interfaces.\n>>>   \n>> Yes, since I have this command and have seen the tag annotations in the\n>> git repository, I think we need this extra parameter.\n>> I propose to give the number of lines you want to see, with 0 gives all.\n>> So it will be --pretty=<max-number-lines> to limit the output and be\n>> able to find interesting stuff before looking at the complete message.\n> \n> Please do not use the same word used elsewhere ('pretty') and\n> make it mean something different (they are 'short', 'oneline', etc.\n> in other places).\n> \n> Regardless of how we might do a single-liner output, I suspect that\n> Instead of showing them like this (your patch):\n> \n> \t$ git tag -L v2.6.1* | head -n 6\n> \tv2.6.11\n>             This is the 2.6.11 tree object.\n> \tv2.6.11-tree\n>             This is the 2.6.11 tree object.\n> \tv2.6.12\n>             This is the final 2.6.12 release\n> \n> showing them in this way might be more pleasant:\n> \n> \t$ git tag -L v2.6.1* | head -n 3\n> \tv2.6.11      This is the 2.6.11 tree object.\n> \tv2.6.11-tree This is the 2.6.11 tree object.\n> \tv2.6.12      This is the final 2.6.12 release\n> \n> This matches the way \"git branch -v\" without other arguments,\n> which I think is the moral equivalent for branches to your \"git\n> tag -L\", shows a bit more information than the usual (we could\n> even say \"git tag -l -v\" but -v is already taken -- we could\n> still do \"git tag --list --verbose\" and leave the short '-v' to\n> mean 'verify' but I dunno).\n\nYes, this is a good idea.\nI have dropped the -L option, and in stead introduced the -n option.\nThe -n option specifies how many lines of annotation you want to see.\nNot using -n gives the old -l behavior, just -n gives the tag and\nfirst annotation line together, and -n 9999 gives the full annotation.\n\nI think this is better than having two different list options.\n\n> \n> This is a slightly related tangent, but I've been wanting to\n> extend the \"the first line is special 'one-line summary',\n> separated by a blank line from the rest of the more descriptive\n> message\" convention used in the commit log message formatter.\n> When somebody asks for --pretty=oneline, instead of showing the\n> \"first line\", we would give the first paragraph, with LFs\n> replaced with SPs to make it a single line.  This would not\n> affect commit log messages that follow the above convention.\n> \n> If your tags have a few lines to describe what the commits are\n> about, it might make it easier to get the overview by applying\n> the same \"first paragraph squashed down to a single line\" logic,\n> grab the first paragraph, present it as a one-liner\" in the\n> format shown above.\n\nI will leave this for another time...\n\n> \n>>>>  - Sorting the tag names resulting from git-rev-parse is not nessecary since\n>>>>    the list of tags is already deliverd in sorted order.\n>>> This I am a bit reluctant about, as that sorting done by\n>>> rev-parse is purely by accident (i.e. it is an implementation\n>>> detail).\n>>>   \n>> This accident can be repaired by documenting it.... :)\n> \n> That would cast the implementation in stone, avoidance of which\n> was the point of my comment.\n> \n\nYes, I understand. It would be good if the manual page for rev-parse\nsaid something about the order in which the arguments are processed or\ngenerated. Currently this is not mentioned, so I was not surprised\nto find the generated names were sorted.\n\n>>> What does this command exit with now?  It used to be that\n>>>\n>>> \t$ git tag -l no-such-tag-at-all ; echo $?\n>>>\n>>> said \"1\", I think, because grep did not match.\n>>>   \n>> It will always exit 0, either from sed or git-cat.\n>>\n>> ...\n>>\n>>  (maybe the exit code is not worth the added complexity...).\n> \n> That's 40% satisfactory answer.\n> \n> I do not speak for others, but when I comment on a patch, saying\n> \"This might be better done this other way\", or \"This change\n> might be bad\", I do not necessarily expect/want you to agree\n> with me on all counts.  I would very much be happier to get a\n> counter argument back -- that's how we both learn things and\n> make progress.\n> \n> Unlike Linus, I am not always right ;-)\n> \n> But more seriously, I sometimes deliberately make suggestions\n> that I know are not optimal, because I want to involve other\n> people (not necessarily the author of the patch, but others on\n> the list) in the process of making improvements.\n> \n> The \"40%\" satisfactory part comes from that you correctly\n> answered that your version now always exits zero while the\n> original diagnosed the \"no such tag whatsoever\" situation with\n> non-zero exit, with a slight hint that you think it might be\n> better not to differenciate the \"no match\" case.\n> \n> What I would prefer to see is to make that \"slight hint\" more\n> explicit.  As you say, \"is not worth the added complexity\" is a\n> possible justification, but in this particular case, I think we\n> could (and probably should) even argue that the current exit\n> code is not so useful.  It might go like this...\n> \n>     Although \"git tag -l <pattern>\" currently signals non-match\n>     with its exit code, \"git tag -l do-i-have-this-tag\" is not\n>     the right way to ask that question to begin with, because\n>     the tagname parameter is always taken as a pattern.  For\n>     that, \"git show-ref --verify refs/tags/do-i-have-this-tag\"\n>     is much better.  I do not think the current exit status from\n>     \"git-tag -l <pattern>\" is useful, and we should change it to\n>     exit with 0 unless we see other errors (e.g. \"not a git\n>     repository\"), regardless of the addition of -L option.\n> \n> and you would have got the remaining 60% ;-).\n> \n> I care about documenting the change in behaviour and justifying\n> why we changed the behavikour in the commit log.\n> \n\nTake 3 of the patch is forthcoming.\n - A new -n option is introduced, specifying the number of\n   annotation lines to print. The default value is 0.\n - The <pattern> is now a shell pattern, and not a list if grep\n   parameters. It is called a pattern and not re, after all.\n - The -l <pattern> may be repeated with a different <pattern>\n - The exit code for -l is now always 0.\n\n\nThanks.\n\nRegards,\n\tMatthijs Melchior.\n"}]}