Re: [BUG REPORT] Git log pretty date

From: Rodrigo Fernandes <rtfrodrigo@gmail.com>
Date: May 29, 2014, 19:57 UTC
Message-ID: <CACJZPBs2_htD=zS1K3fOW+DZ323+2+iwupWuyNDArg2XF6Qx5g@mail.gmail.com>
In-Reply-To: <20140529194932.GA16665@sigill.intra.peff.net>

Jeff, I have no idea what was the tool. The repo is not mine. I found the problem when I was doing some tests and the commit parsing was failing on that repo.

Cumprimentos, Rodrigo Fernandes

On Thu, May 29, 2014 at 8:49 PM, Jeff King <peff@peff.net> wrote:

Show 35 quoted lines

> 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