parse_commit(): describe more date-parsing failure modes
The previous few commits improved the parsing of dates in malformed commit objects. But there's one big case left implicit: we may still feed garbage to parse_timestamp(). This is preferable to trying to be more strict, but let's document the thinking in a comment. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King committed
Apr 27, 2023 at 04:17 UTC
90ef0f14eb1410747885806d8e55725053572654
1 file changed
+9
commit.c
+9
@@ -143,6 +143,15 @@ static timestamp_t parse_commit_date(const char *buf, const char *tail)
143
/*
144
* We know there is at least one digit (or dash), so we'll begin
145
* parsing there and stop at worst case at eol.
146
+ *
147
+ * Note that we may feed parse_timestamp() extra characters here if the
148
+ * commit is malformed, and it will parse as far as it can. For
149
+ * example, "123foo456" would return "123". That might be questionable
150
+ * (versus returning "0"), but it would help in a hypothetical case
151
+ * like "123456+0100", where the whitespace from the timezone is
152
+ * missing. Since such syntactic errors may be baked into history and
153
+ * hard to correct now, let's err on trying to make our best guess
154
+ * here, rather than insist on perfect syntax.
155
*/
156
return parse_timestamp(dateptr, NULL, 10);
157
}