From: Jeff King <peff@peff.net>
Date: Thu, 29 May 2014 19:49:32 GMT
Subject: Re: [BUG REPORT] Git log pretty date
Message-ID: <20140529194932.GA16665@sigill.intra.peff.net>
In-Reply-To: <xmqq7g54begk.fsf@gitster.dls.corp.google.com>

On Thu, May 29, 2014 at 11:57:15AM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > ...
> > to at least make --format date output consistent with the rest of git
> > (and to make "%at" consistent with "%ad" and --date=raw). That still
> > doesn't address Rodrigo's concern, though (we would print "0 +0000").
> [...]
> 
> I actually am not very much interested in deciding what to show for
> a broken timestamp.  An empty string is just as good as any random
> cruft.

I was thinking specifically of the first part I quoted above. We are not
consistent between various methods of parsing/printing the date. That
may fall into the "if were doing it from scratch..." category, though;
it's possible that people currently using "--format=%ad" prefer and
expect the empty string to denote a bogus value. I'm OK with leaving it.

> I agree with you that it would be nice to have one escape
> hatch to let the users see what garbage is recorded, if only for
> diagnostic purposes, and DATE_RAW may be one good way to do so (but
> I'd rather recommend "cat-file commit" for real diagnostics).

Yeah, in case I wasn't clear, I don't actually like DATE_RAW as a way to
do that. I'd prefer "--pretty=raw" or "cat-file commit", which already
work.

> I would be more interested to see whatever broken tool that created
> such a commit gets fixed.  Do we know where it came from?

I don't think it has been said yet in the thread. Rodrigo?

-Peff