From: Adrian Ratiu <adrian.ratiu@collabora.com>
Date: Mon, 15 Dec 2025 16:28:56 GMT
Subject: Re: [PATCH v6 00/10] Add submodulePathConfig extension and gitdir encoding
Message-ID: <87pl8flnef.fsf@gentoo.mail-host-address-is-not-set>
In-Reply-To: <34DD8798-5C69-4092-B6C9-6609E688FBE8@gmail.com>

On Sat, 13 Dec 2025, Ben Knoble <ben.knoble@gmail.com> wrote:
>> Le 13 déc. 2025 à 03:09, Adrian Ratiu <adrian.ratiu@collabora.com> a écrit :
>> 
>> Hello everyone,
>> 
>> For those new to the series, we're implementing a submodule gitdir
>> extension which allows us to have a unified way to determine gitdirs
>> and do things like encode submodule paths to avoid FS conflicts.
>
> Hi there, I admit I haven’t followed this series closely. I use submodules quite a bit but haven’t yet peered into the depths of the implementation.
>
> I read over the documentation changes in this series, and it’s not clear to me how or why I would use this new feature (I don’t mean there’s no benefit! Just that I’m having a hard time parsing it out.). By “how” I mean: I can see how to set config and run the migrator; what does that unlock for me to now go and do?
>
> Does one of the previous cover letters explain how this is useful to submodule users? If so which, and perhaps the docs could also contain a “here’s when/why you might want this extension enabled and what it allows you to do”?
>
> Or maybe this is meant to be not too user-facing, in which case I’m curious who would turn this on and why still :)
>
> Again, I am mostly curious, so please don’t read this as an attempt to hold the series hostage! :)

It's perfectly ok to ask, no problem. :)

This series is for the minority of users who either:

1. Encounter errors like the following in submodule.c:
   die(_("refusing to create/use '%s' in another submodule's "...)

   These errors can happen due to a number of factors, like
   case-insensitive filesystems or submodule layouts.

2. Need to specify non-standard gitdir repository paths, different from
   the currently hardcoded .git/modules/<plain-name> location.

   With this series, the gitdir config becomes the unified way to
   set/get the gitdir paths, so you can move them around as needed.
   It also helps other git implementations who don't need to exactly
   match git's behaviour: the config becomes the standard interface.

If you are not in one of the two above cases, then there is no reason to
enable this and it won't affect you.

Hope this is clear, maybe we could spell it out better in the
documentation (suggestions welcome btw) or even tell users in the error
messages to enable this extension.