Matthijs Melchior <mmelchior@xxxxxxxxx> writes:
> 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 release
showing 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.
>>> - 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.
>> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
