Re: [PATCH] Add option -L to git-tag.
Matthijs Melchior <mmelchior@xs4all.nl> writes:
Show 9 quoted lines
> Junio C Hamano wrote:
> ...
>> I dunno; I've never been very good at the user interfaces.
>>
> Yes, since I have this command and have seen the tag annotations in the
> git repository, I think we need this extra parameter.
> I propose to give the number of lines you want to see, with 0 gives all.
> So it will be --pretty=<max-number-lines> to limit the output and be
> able to find interesting stuff before looking at the complete message.
Please do not use the same word used elsewhere ('pretty') and make it mean something different (they are 'short', 'oneline', etc. in other places).
Regardless of how we might do a single-liner output, I suspect that Instead of showing them like this (your patch):
$ git tag -L v2.6.1* | head -n 6
v2.6.11
This is the 2.6.11 tree object.
v2.6.11-tree
This is the 2.6.11 tree object.
v2.6.12
This is the final 2.6.12 releaseshowing them in this way might be more pleasant:
$ git tag -L v2.6.1* | head -n 3
v2.6.11 This is the 2.6.11 tree object.
v2.6.11-tree This is the 2.6.11 tree object.
v2.6.12 This is the final 2.6.12 release
This matches the way "git branch -v" without other arguments, which I think is the moral equivalent for branches to your "git tag -L", shows a bit more information than the usual (we could even say "git tag -l -v" but -v is already taken -- we could still do "git tag --list --verbose" and leave the short '-v' to mean 'verify' but I dunno).
This is a slightly related tangent, but I've been wanting to extend the "the first line is special 'one-line summary', separated by a blank line from the rest of the more descriptive message" convention used in the commit log message formatter. When somebody asks for --pretty=oneline, instead of showing the "first line", we would give the first paragraph, with LFs replaced with SPs to make it a single line. This would not affect commit log messages that follow the above convention.
If your tags have a few lines to describe what the commits are about, it might make it easier to get the overview by applying the same "first paragraph squashed down to a single line" logic, grab the first paragraph, present it as a one-liner" in the format shown above.
Show 8 quoted lines
>>> - Sorting the tag names resulting from git-rev-parse is not nessecary since
>>> the list of tags is already deliverd in sorted order.
>>
>> This I am a bit reluctant about, as that sorting done by
>> rev-parse is purely by accident (i.e. it is an implementation
>> detail).
>>
> This accident can be repaired by documenting it.... :)
That would cast the implementation in stone, avoidance of which was the point of my comment.
Show 11 quoted lines
>> What does this command exit with now? It used to be that
>>
>> $ git tag -l no-such-tag-at-all ; echo $?
>>
>> said "1", I think, because grep did not match.
>>
> It will always exit 0, either from sed or git-cat.
>
> ...
>
> (maybe the exit code is not worth the added complexity...).
That's 40% satisfactory answer.
I do not speak for others, but when I comment on a patch, saying "This might be better done this other way", or "This change might be bad", I do not necessarily expect/want you to agree with me on all counts. I would very much be happier to get a counter argument back -- that's how we both learn things and make progress.
Unlike Linus, I am not always right ;-)
But more seriously, I sometimes deliberately make suggestions that I know are not optimal, because I want to involve other people (not necessarily the author of the patch, but others on the list) in the process of making improvements.
The "40%" satisfactory part comes from that you correctly answered that your version now always exits zero while the original diagnosed the "no such tag whatsoever" situation with non-zero exit, with a slight hint that you think it might be better not to differenciate the "no match" case.
What I would prefer to see is to make that "slight hint" more explicit. As you say, "is not worth the added complexity" is a possible justification, but in this particular case, I think we could (and probably should) even argue that the current exit code is not so useful. It might go like this...
Although "git tag -l <pattern>" currently signals non-match
with its exit code, "git tag -l do-i-have-this-tag" is not
the right way to ask that question to begin with, because
the tagname parameter is always taken as a pattern. For
that, "git show-ref --verify refs/tags/do-i-have-this-tag"
is much better. I do not think the current exit status from
"git-tag -l <pattern>" is useful, and we should change it to
exit with 0 unless we see other errors (e.g. "not a git
repository"), regardless of the addition of -L option.and you would have got the remaining 60% ;-).
I care about documenting the change in behaviour and justifying why we changed the behavikour in the commit log.
