Subject: Re: [PATCH v6 00/10] Add submodulePathConfig extension and gitdir encoding

From: Ben Knoble <[email-masked]>
Date: Wed, 17 Dec 2025 22:43:36 -0500

> Le 15 déc. 2025 à 11:29, Adrian Ratiu <[email-masked]> a écrit :
> 
> On Sat, 13 Dec 2025, Ben Knoble <[email-masked]> wrote:
>>>> Le 13 déc. 2025 à 03:09, Adrian Ratiu <[email-masked]> 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.

Thanks! That helped, and I am not in either case ;) I agree with Junio’s downthread points about docs.