Pretty date option for git tag?

Pretty date option for git tag?

[dloewenherz]

It is relatively hard to verify the date a tag was created unless it was been
gpg/pgp-signed at the time of creation, no? I suppose that the Unix timestamp
included in each tag file is useful for sorting, but it's not very easy for
people to digest.  Additionally, we have our `log.date` config, why not use it
here for some sort of option, like `--pretty=date` to make it easy to see when
a tag was created?

I.e.

$ git tag -l --pretty=date
...
Mon, 13 Apr 2009 00:06:25: v1.6.3-rc0
Sat, 18 Apr 2009 22:11:00: v1.6.3-rc1 
Sat, 25 Apr 2009 06:01:13: v1.6.3-rc2 
Sun, 26 Apr 2009 23:43:48: v1.6.3-rc3 
Sat, 02 May 2009 06:32:21: v1.6.3-rc4 
Wed, 13 May 2009 05:30:37: v1.6.3.1

I don't know if this is feasible. Perhaps there already exists a feature for
this that I'm unaware of. Or maybe this would be a waste of time.

Dan

Re: Pretty date option for git tag?

[Michael J Gruber]

dloewenherz@gmail.com venit, vidit, dixit 18.05.2009 17:14:
> It is relatively hard to verify the date a tag was created unless it was been
> gpg/pgp-signed at the time of creation, no? I suppose that the Unix timestamp
> included in each tag file is useful for sorting, but it's not very easy for
> people to digest.  Additionally, we have our `log.date` config, why not use it
> here for some sort of option, like `--pretty=date` to make it easy to see when
> a tag was created?
> 
> I.e.
> 
> $ git tag -l --pretty=date
> ...
> Mon, 13 Apr 2009 00:06:25: v1.6.3-rc0
> Sat, 18 Apr 2009 22:11:00: v1.6.3-rc1 
> Sat, 25 Apr 2009 06:01:13: v1.6.3-rc2 
> Sun, 26 Apr 2009 23:43:48: v1.6.3-rc3 
> Sat, 02 May 2009 06:32:21: v1.6.3-rc4 
> Wed, 13 May 2009 05:30:37: v1.6.3.1
> 
> I don't know if this is feasible. Perhaps there already exists a feature for
> this that I'm unaware of. Or maybe this would be a waste of time.

You might want to experiment with

git log --tags --simplify-by-decoration --pretty="format:%ai %s"

which may show a few more commits than just the tags but comes close to
the output you envisage.

Michael

Re: Pretty date option for git tag?

[Linus Torvalds]

On Mon, 18 May 2009, Michael J Gruber wrote:
> 
> You might want to experiment with
> 
> git log --tags --simplify-by-decoration --pretty="format:%ai %s"
> 
> which may show a few more commits than just the tags but comes close to
> the output you envisage.

Ooh, evil. I like it.

It's a rather expensive operation, but it does have the really nice 
property that it will show the date of the commit the tag is pointing to, 
rather than necessarily the date of the tag itself (which is not 
well-defined unless the tag is signed).

As you mention, "--simplify-by-decoration" will show merges too (unless it 
can linearize the tag history), but you can work around that by making the 
format be "format:%ai %d" where that '%d' shows the decoration of the 
commit, rather than the commit summary. Now the merges that aren't tagged 
stand out very clearly.

Of course, the above will just work for commit tags. If you've tagged a 
tree or a blob, the above gives you bubkis.

			Linus

Re: Pretty date option for git tag?

[Jeff King]

On Mon, May 18, 2009 at 10:20:49AM -0700, Linus Torvalds wrote:

> It's a rather expensive operation, but it does have the really nice 
> property that it will show the date of the commit the tag is pointing to, 
> rather than necessarily the date of the tag itself (which is not 
> well-defined unless the tag is signed).

It seems like you should be able to script around for-each-ref and
remain efficient, but I don't think there is a way to convince it to
dereference tags. Something like:

  git for-each-ref --format='%(refname)
  Tag: %(taggername) %(taggeremail) %(taggerdate)
  Commit: %(authorname) %(authoremail) %(authordate)
  ' refs/tags

almost works, but the commit fields are always empty. So I think you
would have to parse and manually rev-parse each one.

-Peff

PS The for-each-ref command above caused a segfault when run in git.git.
   Patch to follow.

[PATCH] for-each-ref: fix segfault in copy_email

[Jeff King]

You can trigger a segfault in git.git by doing:

  git for-each-ref --format='%(taggeremail)' refs/tags/v0.99

The v0.99 tag is special in that it contains no "tagger"
header.

The bug is obvious in copy_email, which carefully checks to
make sure the result of a strchr is non-NULL, but only after
already having used it to perform other work. The fix is to
move the check up.

Signed-off-by: Jeff King <peff@peff.net>
---
 builtin-for-each-ref.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index 91e8f95..d091e04 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -339,8 +339,11 @@ static const char *copy_name(const char *buf)
 static const char *copy_email(const char *buf)
 {
 	const char *email = strchr(buf, '<');
-	const char *eoemail = strchr(email, '>');
-	if (!email || !eoemail)
+	const char *eoemail;
+	if (!email)
+		return "";
+	eoemail = strchr(email, '>');
+	if (!eoemail)
 		return "";
 	return xmemdupz(email, eoemail + 1 - email);
 }
-- 
1.6.3.1.137.g9019.dirty

Re: Pretty date option for git tag?

[Thomas Rast]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

Jeff King wrote:
> It seems like you should be able to script around for-each-ref and
> remain efficient, but I don't think there is a way to convince it to
> dereference tags.

Actually there's the * operator.  For example

  git$ git for-each-ref --format="%(objecttype) %(*objecttype)" refs/tags/v1.6.0
  tag commit

Does that solve the problem at hand?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Pretty date option for git tag?

[Jeff King]

On Mon, May 18, 2009 at 11:11:37PM +0200, Thomas Rast wrote:

> Jeff King wrote:
> > It seems like you should be able to script around for-each-ref and
> > remain efficient, but I don't think there is a way to convince it to
> > dereference tags.
> 
> Actually there's the * operator.  For example
> 
>   git$ git for-each-ref --format="%(objecttype) %(*objecttype)" refs/tags/v1.6.0
>   tag commit
> 
> Does that solve the problem at hand?

Oh, right, thanks. I missed that when reading the manual (I was looking
for "dereference" or "peel", but those words are never used). So you can
do:

  git for-each-ref --format='%(refname)
  Tag: %(taggername) %(taggeremail) %(taggerdate)
  Commit: %(*authorname) %(*authoremail) %(*authordate)
  ' refs/tags

to show both.

That could go in an alias, though it isn't exactly what the original
poster asked for. Besides not being a one-line format, it has refs/tags/
cruft at the beginning of each ref. I think what the OP asked for
exactly is:

  eval "`git for-each-ref --shell --format='
    r=%(refname)
    d=%(taggerdate)
    T=${r#refs/tags/}
    echo "$T $d"
    ' refs/tags`"

Though as Linus said, I think the actual commit date is also interesting
(and you could expand that shell snippet to show it instead, in addition
to, or whatever).

And before anyone says anything, yes, I think building a shell script
and eval'ing it is a little ugly compared to a "--show-date" option to
"git tag". If this is something a lot of people want to do, it wouldn't
be that hard an option to add (in fact, it would be really nice to unify
the show-ref and pretty=format substitutions, and extend them into "git
tag --format='%r %td'" or whatever).

-Peff