* [PATCH] Add option -L to git-tag.
@ 2007-06-02 8:37 Matthijs Melchior
2007-06-02 10:10 ` Junio C Hamano
0 siblings, 1 reply; 7+ messages in thread
From: Matthijs Melchior @ 2007-06-02 8:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthijs Melchior
This will list the selected tags and include annotations, if any.
Signed-off-by: Matthijs Melchior <mmelchior@xs4all.nl>
---
This patch has been created to allow me to easily see the annotations with tags.
I have not found any other way to do this...
Some remarks on the new bit of code:
- Sorting the tag names resulting from git-rev-parse is not nessecary since
the list of tags is already deliverd in sorted order.
- Using git-cat-file -t on every tag is expensive, but there is no alternative
-Matthijs
Documentation/git-tag.txt | 5 ++++-
git-tag.sh | 24 +++++++++++++++++-------
2 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 4e3e027..441f361 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git-tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <name> [<head>]
'git-tag' -d <name>...
-'git-tag' -l [<pattern>]
+'git-tag' [-l | -L] [<pattern>]
'git-tag' -v <name>
DESCRIPTION
@@ -41,6 +41,9 @@ GnuPG key for signing.
`-l <pattern>` lists tags that match the given pattern (or all
if no pattern is given).
+`-L <pattern>` lists tags, including their annotations, that match
+the given pattern (or all if no pattern is given).
+
OPTIONS
-------
-a::
diff --git a/git-tag.sh b/git-tag.sh
index 6f0b7a7..45c4253 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -1,7 +1,7 @@
#!/bin/sh
# Copyright (c) 2005 Linus Torvalds
-USAGE='-l [<pattern>] | [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg>] <tagname> [<head>]'
+USAGE='[-l | -L] [<pattern>] | [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg>] <tagname> [<head>]'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
@@ -26,13 +26,23 @@ do
-f)
force=1
;;
- -l)
- case "$#" in
- 1)
- set x . ;;
- esac
+ -l|-L)
+ TAGSONLY=true
+ [ "$1" = -L ] && TAGSONLY=false
+ [ "$#" = 1 ] && set x .
shift
- git rev-parse --symbolic --tags | sort | grep "$@"
+ git rev-parse --symbolic --tags | grep "$@" |
+ while read TAG
+ do
+ echo "$TAG"
+ $TAGSONLY && continue
+ OBJTYPE=$(git cat-file -t "$TAG")
+ case $OBJTYPE in
+ tag) git cat-file $OBJTYPE "$TAG" |
+ sed '1,/^$/d;/^-----BEGIN PGP SIGNATURE-----$/Q;s/^/ /'
+ ;;
+ esac
+ done
exit $?
;;
-m)
--
1.5.2
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] Add option -L to git-tag.
2007-06-02 8:37 Matthijs Melchior
@ 2007-06-02 10:10 ` Junio C Hamano
2007-06-02 13:09 ` Matthijs Melchior
0 siblings, 1 reply; 7+ messages in thread
From: Junio C Hamano @ 2007-06-02 10:10 UTC (permalink / raw)
To: Matthijs Melchior; +Cc: git
Matthijs Melchior <mmelchior@xs4all.nl> writes:
> This will list the selected tags and include annotations, if any.
>
> Signed-off-by: Matthijs Melchior <mmelchior@xs4all.nl>
> ---
>
> This patch has been created to allow me to easily see the annotations with tags.
> I have not found any other way to do this...
Hmmmm. This feature ought to belong to git-show, but that
command already has its own interpretation of how a tag should
be shown.
Do we care about the "one line summary"? Perhaps...
$ git tag --pretty=short -L v2.6.11-tree
v2.6.11-tree
This is the 2.6.11 tree object.
$ git tag -L v2.6.11-tree
v2.6.11-tree
This is the 2.6.11 tree object.
NOTE! There's no commit for this, since it happened...
The answer to this question would really depend on why we would
want to have this feature. "git-tag" started as a way to
"create", and then it gained -l to "list" and -v to "verify". I
think your -L is meant to be an extension to "list", but I
suspect that while you are listing many things you would keep
the annotation short-and-sweet, and you would want to view the
full description when your interest is focused at a single one.
Maybe we would want a separate "print" action for the full
contents and use the short one for "list but more verbosely than
usual"?
I dunno; I've never been very good at the user interfaces.
> - 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).
> - Using git-cat-file -t on every tag is expensive, but there is no alternative
This is Ok, as we have somebody working on doing git-tag as a
built-in, and once that happens, we do not have to pay the
performance penalty. So I would think at this point we should
concentrate on discussing the usefulness of this new feature and
correctness of your implementation, as that would set the course
for the future. On the other hand, "cat-file -t" performance
issues will not stay with us forever.
> @@ -26,13 +26,23 @@ do
> -f)
> force=1
> ;;
> - -l)
> - case "$#" in
> - 1)
> - set x . ;;
> - esac
> + -l|-L)
> + TAGSONLY=true
> + [ "$1" = -L ] && TAGSONLY=false
> + [ "$#" = 1 ] && set x .
> shift
> + git rev-parse --symbolic --tags | grep "$@" |
> + while read TAG
> + do
> + echo "$TAG"
> + $TAGSONLY && continue
> + OBJTYPE=$(git cat-file -t "$TAG")
> + case $OBJTYPE in
> + tag) git cat-file $OBJTYPE "$TAG" |
> + sed '1,/^$/d;/^-----BEGIN PGP SIGNATURE-----$/Q;s/^/ /'
> + ;;
> + esac
Micronit. If you already know it is a tag, you do not have to
say "cat-file $OBJTYPE".
Style. Please indent the case arm to the same level as, not
deeper than, case/esac.
This is the same as C's switch() { case ...: } indentation rule.
Please do not feed multiple expressions concatenated with
semicolon to sed, as it is one of the often observed portability
issues (not all the world is GNU yet). Write it like this
instead:
case "$OBJTYPE" in
tag)
git cat-file tag "$TAG" |
sed -e '1,/^$/d' \
-e '/^-----BEGIN PGP SIGNATURE-----$/Q' \
-e s/^/ /'
;;
esac
> + done
> exit $?
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Add option -L to git-tag.
2007-06-02 10:10 ` Junio C Hamano
@ 2007-06-02 13:09 ` Matthijs Melchior
2007-06-02 18:22 ` Junio C Hamano
0 siblings, 1 reply; 7+ messages in thread
From: Matthijs Melchior @ 2007-06-02 13:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano wrote:
> Matthijs Melchior <mmelchior@xs4all.nl> writes:
>
>
>> This will list the selected tags and include annotations, if any.
>>
>> Signed-off-by: Matthijs Melchior <mmelchior@xs4all.nl>
>> ---
>>
>> This patch has been created to allow me to easily see the annotations with tags.
>> I have not found any other way to do this...
>>
>
> Hmmmm. This feature ought to belong to git-show, but that
> command already has its own interpretation of how a tag should
> be shown.
>
> Do we care about the "one line summary"? Perhaps...
>
> $ git tag --pretty=short -L v2.6.11-tree
> v2.6.11-tree
> This is the 2.6.11 tree object.
>
> $ git tag -L v2.6.11-tree
> v2.6.11-tree
> This is the 2.6.11 tree object.
>
> NOTE! There's no commit for this, since it happened...
>
> The answer to this question would really depend on why we would
> want to have this feature. "git-tag" started as a way to
> "create", and then it gained -l to "list" and -v to "verify". I
> think your -L is meant to be an extension to "list", but I
> suspect that while you are listing many things you would keep
> the annotation short-and-sweet, and you would want to view the
> full description when your interest is focused at a single one.
> Maybe we would want a separate "print" action for the full
> contents and use the short one for "list but more verbosely than
> usual"?
>
> 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.
In the project where I wanted this, the tag annotations are only a few
lines max...
I have used this to remember special status of of a commit, such as release
version and date. In order to quickly find such a thing I wanted to see
all the annotations.
>
>> - 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.... :)
>
>> - Using git-cat-file -t on every tag is expensive, but there is no alternative
>>
>
> This is Ok, as we have somebody working on doing git-tag as a
> built-in, and once that happens, we do not have to pay the
> performance penalty. So I would think at this point we should
> concentrate on discussing the usefulness of this new feature and
> correctness of your implementation, as that would set the course
> for the future. On the other hand, "cat-file -t" performance
> issues will not stay with us forever.
>
>
>> @@ -26,13 +26,23 @@ do
>> -f)
>> force=1
>> ;;
>> - -l)
>> - case "$#" in
>> - 1)
>> - set x . ;;
>> - esac
>> + -l|-L)
>> + TAGSONLY=true
>> + [ "$1" = -L ] && TAGSONLY=false
>> + [ "$#" = 1 ] && set x .
>> shift
>> + git rev-parse --symbolic --tags | grep "$@" |
>> + while read TAG
>> + do
>> + echo "$TAG"
>> + $TAGSONLY && continue
>> + OBJTYPE=$(git cat-file -t "$TAG")
>> + case $OBJTYPE in
>> + tag) git cat-file $OBJTYPE "$TAG" |
>> + sed '1,/^$/d;/^-----BEGIN PGP SIGNATURE-----$/Q;s/^/ /'
>> + ;;
>> + esac
>>
>
> Micronit. If you already know it is a tag, you do not have to
> say "cat-file $OBJTYPE".
>
Yes, this was left over from an older prototype.....
> Style. Please indent the case arm to the same level as, not
> deeper than, case/esac.
> This is the same as C's switch() { case ...: } indentation rule.
>
> Please do not feed multiple expressions concatenated with
> semicolon to sed, as it is one of the often observed portability
> issues (not all the world is GNU yet). Write it like this
> instead:
>
> case "$OBJTYPE" in
> tag)
> git cat-file tag "$TAG" |
> sed -e '1,/^$/d' \
> -e '/^-----BEGIN PGP SIGNATURE-----$/Q' \
> -e s/^/ /'
> ;;
> esac
>
>
>> + done
>> exit $?
>>
OK, I'll use this style.
> 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.
I will send a new patch with better style, a --pretty=n option and
again exit code from grep.
(maybe the exit code is not worth the added complexity...).
Thanks.
--
Regards,
---------------------------------------------------------------- -o)
Matthijs Melchior Maarssen /\\
mmelchior@xs4all.nl Netherlands _\_v
---------------------------------------------------------------- ----
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] Add option -L to git-tag.
@ 2007-06-02 13:10 Matthijs Melchior
2007-06-02 14:49 ` Frank Lichtenheld
0 siblings, 1 reply; 7+ messages in thread
From: Matthijs Melchior @ 2007-06-02 13:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthijs Melchior
This will list the selected tags and include annotations, if any.
Signed-off-by: Matthijs Melchior <mmelchior@xs4all.nl>
---
Version 2 of the git-tag -L patch.
It implements better style,
a new --pretty=n option and
an interresting exit code.
-Matthijs
Documentation/git-tag.txt | 5 ++++-
git-tag.sh | 24 +++++++++++++++++-------
2 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 4e3e027..441f361 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git-tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <name> [<head>]
'git-tag' -d <name>...
-'git-tag' -l [<pattern>]
+'git-tag' [-l | -L] [<pattern>]
'git-tag' -v <name>
DESCRIPTION
@@ -41,6 +41,9 @@ GnuPG key for signing.
`-l <pattern>` lists tags that match the given pattern (or all
if no pattern is given).
+`-L <pattern>` lists tags, including their annotations, that match
+the given pattern (or all if no pattern is given).
+
OPTIONS
-------
-a::
diff --git a/git-tag.sh b/git-tag.sh
index 6f0b7a7..45c4253 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -1,7 +1,7 @@
#!/bin/sh
# Copyright (c) 2005 Linus Torvalds
-USAGE='-l [<pattern>] | [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg>] <tagname> [<head>]'
+USAGE='[-l | -L] [<pattern>] | [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg>] <tagname> [<head>]'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
@@ -26,13 +26,23 @@ do
-f)
force=1
;;
- -l)
- case "$#" in
- 1)
- set x . ;;
- esac
+ -l|-L)
+ TAGSONLY=true
+ [ "$1" = -L ] && TAGSONLY=false
+ [ "$#" = 1 ] && set x .
shift
- git rev-parse --symbolic --tags | sort | grep "$@"
+ git rev-parse --symbolic --tags | grep "$@" |
+ while read TAG
+ do
+ echo "$TAG"
+ $TAGSONLY && continue
+ OBJTYPE=$(git cat-file -t "$TAG")
+ case $OBJTYPE in
+ tag) git cat-file $OBJTYPE "$TAG" |
+ sed '1,/^$/d;/^-----BEGIN PGP SIGNATURE-----$/Q;s/^/ /'
+ ;;
+ esac
+ done
exit $?
;;
-m)
--
1.5.2
>From f0123e2f1c4bd8a15e8d190dc1e0c2745db60278 Mon Sep 17 00:00:00 2001
From: Matthijs Melchior <mmelchior@xs4all.nl>
Date: Sat, 2 Jun 2007 15:04:46 +0200
Subject: [PATCH] git-tag -L, version 2
style. --pretty=n and exit code
---
git-tag.sh | 20 +++++++++++++++-----
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/git-tag.sh b/git-tag.sh
index 45c4253..dafa083 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -13,6 +13,7 @@ message=
username=
list=
verify=
+LINES=3
while case "$#" in 0) break ;; esac
do
case "$1" in
@@ -26,24 +27,33 @@ do
-f)
force=1
;;
+ --pretty=*)
+ LINES=$(expr "$1" : '--pretty=\(.*\)')
+ ;;
-l|-L)
TAGSONLY=true
[ "$1" = -L ] && TAGSONLY=false
[ "$#" = 1 ] && set x .
shift
- git rev-parse --symbolic --tags | grep "$@" |
+ [ "$LINES" -le 0 ] && LINES=999999
+ TAGLIST=$(git rev-parse --symbolic --tags | grep "$@")
+ RC=$? # from grep
+ printf "%s" "$TAGLIST" |
while read TAG
do
echo "$TAG"
$TAGSONLY && continue
OBJTYPE=$(git cat-file -t "$TAG")
case $OBJTYPE in
- tag) git cat-file $OBJTYPE "$TAG" |
- sed '1,/^$/d;/^-----BEGIN PGP SIGNATURE-----$/Q;s/^/ /'
- ;;
+ tag) git cat-file tag "$TAG" |
+ sed -e '1,/^$/d' \
+ -e '/^-----BEGIN PGP SIGNATURE-----$/Q' \
+ -e 's/^/ /' |
+ sed -e "${LINES}q"
+ ;;
esac
done
- exit $?
+ exit $RC
;;
-m)
annotate=1
--
1.5.2
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] Add option -L to git-tag.
2007-06-02 13:10 [PATCH] Add option -L to git-tag Matthijs Melchior
@ 2007-06-02 14:49 ` Frank Lichtenheld
0 siblings, 0 replies; 7+ messages in thread
From: Frank Lichtenheld @ 2007-06-02 14:49 UTC (permalink / raw)
To: Matthijs Melchior; +Cc: Junio C Hamano, git
On Sat, Jun 02, 2007 at 03:10:48PM +0200, Matthijs Melchior wrote:
> +`-L <pattern>` lists tags, including their annotations, that match
> +the given pattern (or all if no pattern is given).
>From the descriptions it is not clear to me if the pattern is applied to
the tag names, the annotations or both. Maybe one could reorder that
sentence to make it less confusing?
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Add option -L to git-tag.
2007-06-02 13:09 ` Matthijs Melchior
@ 2007-06-02 18:22 ` Junio C Hamano
2007-06-03 0:04 ` Matthijs Melchior
0 siblings, 1 reply; 7+ messages in thread
From: Junio C Hamano @ 2007-06-02 18:22 UTC (permalink / raw)
To: Matthijs Melchior; +Cc: git
Matthijs Melchior <mmelchior@xs4all.nl> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Add option -L to git-tag.
2007-06-02 18:22 ` Junio C Hamano
@ 2007-06-03 0:04 ` Matthijs Melchior
0 siblings, 0 replies; 7+ messages in thread
From: Matthijs Melchior @ 2007-06-03 0:04 UTC (permalink / raw)
To: git
Junio C Hamano wrote:
> Matthijs Melchior <mmelchior@xs4all.nl> 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).
Yes, this is a good idea.
I have dropped the -L option, and in stead introduced the -n option.
The -n option specifies how many lines of annotation you want to see.
Not using -n gives the old -l behavior, just -n gives the tag and
first annotation line together, and -n 9999 gives the full annotation.
I think this is better than having two different list options.
>
> 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.
I will leave this for another time...
>
>>>> - 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.
>
Yes, I understand. It would be good if the manual page for rev-parse
said something about the order in which the arguments are processed or
generated. Currently this is not mentioned, so I was not surprised
to find the generated names were sorted.
>>> 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.
>
Take 3 of the patch is forthcoming.
- A new -n option is introduced, specifying the number of
annotation lines to print. The default value is 0.
- The <pattern> is now a shell pattern, and not a list if grep
parameters. It is called a pattern and not re, after all.
- The -l <pattern> may be repeated with a different <pattern>
- The exit code for -l is now always 0.
Thanks.
Regards,
Matthijs Melchior.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2007-06-03 0:04 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-06-02 13:10 [PATCH] Add option -L to git-tag Matthijs Melchior
2007-06-02 14:49 ` Frank Lichtenheld
-- strict thread matches above, loose matches on Subject: below --
2007-06-02 8:37 Matthijs Melchior
2007-06-02 10:10 ` Junio C Hamano
2007-06-02 13:09 ` Matthijs Melchior
2007-06-02 18:22 ` Junio C Hamano
2007-06-03 0:04 ` Matthijs Melchior
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).