Subject: Re: [PATCH 6/9] submodule: encode gitdir paths to avoid conflicts

From: Jeff King <[email-masked]>
Date: Wed, 20 Aug 2025 15:29:47 -0400

On Sun, Aug 17, 2025 at 12:36:39AM +0300, Adrian Ratiu wrote:

> @@ -2632,5 +2633,23 @@ void submodule_name_to_gitdir(struct strbuf *buf, struct repository *r,
>  	/* New style (encoded) paths go under submodules/<encoded>. */
>  	strbuf_reset(buf);
>  	repo_git_path_append(r, buf, "submodules/");
> -	strbuf_addstr(buf, submodule_name);
> +	base_len = buf->len;
> +
> +	/* URL-encode then case case-encode A to _a, B to _b and so on */
> +	strbuf_addstr_urlencode(&tmp, submodule_name, is_rfc3986_unreserved);
> +	strbuf_addstr_case_encode(&encoded_sub_name, tmp.buf);
> +	strbuf_release(&tmp);
> +	strbuf_addbuf(buf, &encoded_sub_name);
> +
> +	/* Ensure final path length is below NAME_MAX after encoding */
> +	name_max = pathconf(buf->buf, _PC_NAME_MAX);
> +	if (name_max == -1)
> +		name_max = NAME_MAX;

This patch seems to break the Windows CI builds, as they don't have
pathconf() there. I guess we'd need a compat wrapper that returns -1 in
this case. And likewise protects _PC_NAME_MAX from being seen on systems
that don't have it.

> +	encoded_len = buf->len - base_len;
> +	if (encoded_len >= name_max)
> +		die(_("encoded submodule name '%s' is too long (%zu bytes, limit is %ld)"),
> +		    encoded_sub_name.buf, encoded_len, name_max);

It also complained about %z here. I think you have to use PRIuMAX
instead. Likewise size_t is a "long long" on Windows (LLP64). So "%ld"
probably also needs to be PRIuMAX.

I also saw failures on the osx jobs for t7527.62 (submodule
absorbgitdirs implicitly starts daemon). I didn't dig in, but I can
guess they may be related to this series.

-Peff