We check only that get_sha1_hex() doesn't complain, which means we'd
match an all-hex name with trailing cruft after it. This probably
doesn't matter much in practice, since there shouldn't be anything else
ni the rr-cache directory, but it could possibly cause us to mix up sha1
and sha256 entries (which also shouldn't be intermingled, but could be
leftovers from a repository conversion).
Note that "get_sha1_hex()" is a confusing historical name. It is
actually using the_hash_algo, so it would be sha256 in a sha256 repo.
We'll switch to using parse_oid_hex(), because that conveniently
advances our pointer. But it also gets rid of the sha1 name. Arguably
it's a little funny to use "object_id" here for something that isn't
actually naming an object, but it's unlikely to be a problem (and is
contained in a single function).
Signed-off-by: Jeff King <peff@xxxxxxxx>
---
This is mostly just an oddity I noticed while touching the code, and
I've never seen triggered in real life.
rerere.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/rerere.c b/rerere.c
index 7b0c262ac6..e92e305f96 100644
--- a/rerere.c
+++ b/rerere.c
@@ -1181,8 +1181,9 @@ static void prune_one(struct rerere_id *id,
/* Does the basename in "path" look plausibly like an rr-cache entry? */
static int is_rr_cache_dirname(const char *path)
{
- unsigned char hash[GIT_MAX_RAWSZ];
- return !get_sha1_hex(path, hash);
+ struct object_id oid;
+ const char *end;
+ return !parse_oid_hex(path, &oid, &end) && !*end;
}
void rerere_gc(struct repository *r, struct string_list *rr)
--
2.30.0.758.gfe500d6872
