From: Ben Knoble Date: Thu, 18 Dec 2025 03:43:36 GMT Subject: Re: [PATCH v6 00/10] Add submodulePathConfig extension and gitdir encoding Message-ID: <351D4D02-AF90-4209-85D6-6C3C80C99C8A@gmail.com> In-Reply-To: <87pl8flnef.fsf@gentoo.mail-host-address-is-not-set> > Le 15 déc. 2025 à 11:29, Adrian Ratiu a écrit : > > On Sat, 13 Dec 2025, Ben Knoble wrote: >>>> Le 13 déc. 2025 à 03:09, Adrian Ratiu 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/ 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.