On Mon, Feb 13, 2023 at 05:58:06PM -0500, Eric Sunshine wrote:
> I am able to reproduce the broken behavior on maOS 10.13.
That's helpful.
> > Are your on-disk bytes different?
>
> I get the exact same results (on HFS+) as you show:
Hmm, so we can probably rule out HFS weirdness (and anyway, I guess we'd
be getting the name from the HEAD file, which would be stored verbatim).
If you do something like the patch below:
diff --git a/refs.c b/refs.c
index e31dbcda59..2fa53fef7f 100644
--- a/refs.c
+++ b/refs.c
@@ -1350,7 +1350,8 @@ char *refs_shorten_unambiguous_ref(struct ref_store *refs,
return xstrdup(refname);
/* buffer for scanf result, at most refname must fit */
- short_name = xstrdup(refname);
+ warning("strlen(refname) = %d", (int)strlen(refname));
+ short_name = xcalloc(1, 2*strlen(refname));
/* skip first rule, it will always match */
for (i = nr_rules - 1; i > 0 ; --i) {
@@ -1362,6 +1363,7 @@ char *refs_shorten_unambiguous_ref(struct ref_store *refs,
continue;
short_name_len = strlen(short_name);
+ warning("strlen(short_name) = %d", (int)short_name_len);
/*
* in strict mode, all (except the matched one) rules
Does it help at all? And if so, is short_name_len longer than we might
expect it to be (I get 39 for the full refname and 28 for the scanf'd
name). I'm having trouble coming up with a reason that the scanf value
_would_ be unexpectedly long, but just trying to rule things out.
-Peff
