Re: [PATCH] pretty: add format specifiers: %gr, %gt, %gI, gi

From: Jeff King <peff@peff.net>
Date: Jul 10, 2016, 06:16 UTC
Message-ID: <20160710061644.GA19640@sigill.intra.peff.net>
In-Reply-To: <20160710055402.32684-1-tytso@mit.edu>

On Sun, Jul 10, 2016 at 01:54:02AM -0400, Theodore Ts'o wrote:

Show 5 quoted lines

> Add new format specifiers which allow the printing of reflog
> timestamp.  This allows us to know when operations which change HEAD
> take place (e.g., guilt pop -a, which does the equivalent of a "git
> reset --hard commit"), since using %cr will display when the commit
> was originally made, instead of when HEAD was moved to that commit.

Hrm. You can already get dates like:

  git log --date=relative -g --format=%gd

(or --date=iso, or whatever). But:

  1. It's always branch@{...date...}, not just ...date...

  2. It takes over %gd, so this:

> git log -g --pretty=format:'%Cred%h%Creset %gd %gs %Cgreen(%gr)%Creset %s' --abbrev-commit

can't be done (you cannot show both HEAD@{0} and "5 minutes ago").

So the status quo definitely isn't as flexible as it could be. I'm just not excited about adding a bunch more obscure two-character codes that don't even cover all of the possible date formats (I know we have the same problem for the author/committer timestamps, but we are stuck with those for historical reasons).

I wonder if a better approach would be:

  1. In the short term, add specific designators for the fields you'd
     want. One for HEAD@{n} that is unaffected by date, as %gd is (or
     even one for the branch-name and one for "n"). And one for the
     reflog date, by itself, in whatever format --date= asked for.

     That would let you do your format above, though it does not let you
     show the reflog date in multiple formats.

  2. In the long term, teach log's pretty formatter to handle less
     obscure syntax, that can include arguments. The pretty-printer in
     for-each-ref can already do "%(authordate:relative)", and accepts
     any date-format that git knows about. We should do the same here.

I dunno. Your patch does not make either of those paths _harder_, and it is not like there isn't precedent. It just bloats the user-visible interface with stuff that would later become redundant (but that we can't get rid of because of backwards compatibility).

-Peff