Pretty date option for git tag?

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

dloewenherz@gmail.com venit, vidit, dixit 18.05.2009 17:14:

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

On Mon, 18 May 2009, Michael J Gruber wrote:

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

On Mon, May 18, 2009 at 10:20:49AM -0700, Linus Torvalds 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. 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.

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(-)

Jeff King wrote:

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?

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

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