From: Jeff King Date: Thu, 27 Apr 2023 08:17:24 GMT Subject: [PATCH v3 4/4] parse_commit(): describe more date-parsing failure modes Message-ID: <20230427081724.GB1478467@coredump.intra.peff.net> In-Reply-To: <20230427081330.GA1461786@coredump.intra.peff.net> 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 --- commit.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/commit.c b/commit.c index 8dfe92cf37..e2e4fd2db9 100644 --- a/commit.c +++ b/commit.c @@ -148,6 +148,15 @@ static timestamp_t parse_commit_date(const char *buf, const char *tail) /* * We know there is at least one digit (or dash), so we'll begin * parsing there and stop at worst case at eol. + * + * Note that we may feed parse_timestamp() extra characters here if the + * commit is malformed, and it will parse as far as it can. For + * example, "123foo456" would return "123". That might be questionable + * (versus returning "0"), but it would help in a hypothetical case + * like "123456+0100", where the whitespace from the timezone is + * missing. Since such syntactic errors may be baked into history and + * hard to correct now, let's err on trying to make our best guess + * here, rather than insist on perfect syntax. */ return parse_timestamp(dateptr, NULL, 10); } -- 2.40.1.663.g410c33770c.dirty