Show 45 quoted lines
> Le 15 déc. 2025 à 11:29, Adrian Ratiu <adrian.ratiu@collabora.com> a écrit :
>
> 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.Ben Knoble <ben.knoble@gmail.com>