Re: [PATCH v2 07/10] submodule: error out if gitdir name is too long

From: Jeff King <peff@peff.net>
Date: Sep 8, 2025, 15:51 UTC
Message-ID: <20250908155146.GA1308482@coredump.intra.peff.net>
In-Reply-To: <20250908140117.262205-8-adrian.ratiu@collabora.com>

On Mon, Sep 08, 2025 at 05:01:14PM +0300, Adrian Ratiu wrote:

Show 8 quoted lines

> Encoding submodule names increases their name size, so there is an
> increased risk to hit the max filename length in the gitdir path.
> (the likelihood is still rather small, so it's an acceptable risk)
> 
> This gitdir file-name-too-long corner case can be be addressed in
> multiple ways, including sharding or trimming, however for now, just
> add the portable logic (suggested by Peff) to detect the corner case
> then error out to avoid comitting to a specific policy (or policies).

Thanks, the compat logic here looks reasonable to me.

As somebody who has not really been looking into or thought about the topic at all, though, I wondered how necessary pathconf() is here. That is, I can imagine two alternatives:

 - just try to use the path, and we either get an error from
   open()/mkdir() or we don't. This would end up with roughly the same
   outcome as the current code which calls die(), though it would not
   help with eventually fulfilling your TODO.

 - set some arbitrary but sane limit (say, 255?). That would make the
   behavior consistent across platforms, though it does mean you might
   be prevented from using very long submodule names on systems that
   could support it.

I dunno. Like I said, this is not a problem I thought a lot about, so feel free to ignore. Mostly I just notice that we have lived for 20+ years without pathconf, I think mostly by following the philosophy of the first bullet point above.

-Peff