Jeff KingIn get_sha1_basic, we parse a string like
HEAD@{10 seconds ago}:path/to/fileinto its constituent ref, reflog date, and path components. We never actually munge the string itself, but instead keep offsets into the string with their associated lengths.
When we call approxidate on the contents inside braces, however, we pass just a string without a length. This means that approxidate could sometimes look past the closing brace and (erroneously) interpret the rest of the string as part of the date.
Signed-off-by: Jeff King <peff@peff.net> --- Sorry, I don't have a concise way of writing a test-case. Geoff's example shows the bug when parsing:
HEAD{10 seconds ago}:data/node/node.newds1but it works OK with:
HEAD{10 seconds ago}:data/nodeI didn't track down the exact conditions that cause approxidate to not like the string, since it seems wrong to be sending it a non-terminated string anyway.
sha1_name.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)
Show changes to sha1_name.c +5 −2
diff --git a/sha1_name.c b/sha1_name.c index 491d2e7..b0b2167 100644 --- a/sha1_name.c +++ b/sha1_name.c @@ -351,8 +351,11 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1) } if (0 <= nth) at_time = 0; - else - at_time = approxidate(str + at + 2); + else { + char *tmp = xstrndup(str + at + 2, reflog_len); + at_time = approxidate(tmp); + free(tmp); + } if (read_ref_at(real_ref, at_time, nth, sha1, NULL, &co_time, &co_tz, &co_cnt)) { if (at_time)
-- 1.5.5.1.178.gc1eb9.dirty