Jeff King <> 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").
> 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?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to