Re: [BUG REPORT] Git log pretty date

From: Junio C Hamano <gitster@pobox.com>
Date: May 29, 2014, 18:57 UTC
Message-ID: <xmqq7g54begk.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20140529161628.GB3763@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 22 quoted lines

> ...
> 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").
>
> For that, we would want on top:
>
>   1. Teach split_ident_line to return _something_ for his malformed
>      case.
>
>   2. Teach show_ident_line to treat DATE_RAW to truly output raw
>      content, even if it is malformed.
>
> I am not sure whether those are a good idea or not. The current code
> provides some level of sanitization, so that a parser of log output will
> not get malformed cruft. And DATE_RAW may mean "show me what is in the
> raw commit, even if it is broken". Or it may just mean "show me the date
> in unix timestamp format, because that is easy to parse".
>
> I'd argue that if somebody really wants the former, they should be using
> "--pretty=raw", which will show the raw commit headers, without any
> parsing or fixup at all.

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

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