Jeff King <p...@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").
> For that, we would want on top:
> 1. Teach split_ident_line to return _something_ for his malformed
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html