From: Adrian Ratiu Date: Mon, 08 Dec 2025 09:10:11 GMT Subject: Re: [PATCH v5 4/7] submodule: add extension to encode gitdir paths Message-ID: <87qzt5uyoc.fsf@collabora.com> In-Reply-To: On Sat, 06 Dec 2025, Patrick Steinhardt wrote: > On Sat, Dec 06, 2025 at 07:47:56AM +0900, Junio C Hamano wrote: >> Adrian Ratiu writes: >> >> >> It feels somewhat fragile to me that we unconditionally handle these >> >> cases and try to find old submodule directories. If the extension is >> >> enabled I'd expect that the submodule configuration is the _only_ source >> >> of truth. >> >> >> >> May I propose that we instead always error out in case the submodule >> >> configuration does not exist? In the best case we'd then give the user a >> >> nice error message that tells them how to run the migration manually. >> > >> > Junio told me to not do any kind of manual migration and just attempt >> > new names until one works and then use it consistently. >> >> Indeed, but I do not think that has much relevance to Patrick's >> comment. What I meant say was >> >> - With extension, we know that the repository will use the >> configuration item as the sole source of truth. Unlike the "we >> now store submodule dirs to munged paths" design that we saw long >> ago, which would have required us to sometimes move the existing >> directories to match the munging scheme, we do not have to >> manually migrate the existing directories. Instead, we can just >> record the pathnames they already use. >> >> - And with extension, when we add a new submodule, we would need to >> give them an entry in the configuration that does not conflict >> with those used by the existing submodules. As Patrick mentions, >> this name does not have to be done with any reversible mapping, >> and third-party software and Git reimplementations can always >> refer to the configuration to learn the path without knowing how >> the path is chosen themselves. >> >> - The above two would ensure that the configuration would always >> exist once a submodule enters our system (and "git submodule init" >> is done to cause its gitdir created). >> >> So, unless I am missing some corner case that still exists while >> bootstrapping a new style repository with extension, Patrick's >> "error when configuration is missing" sounds quite sensible to me. >> >> I am officially still on vacation, so I'd stop here for now ;-). > > I guess the one edge case is when somebody manually turns on the > extension after they have already initialized submodules. In that case > the gitdir paths would of course not exist in the gitconfig. But I think > blindly falling back to a source of truth different than the > configuration is wrong, as it would mean that the we have "a single > source of truth unless we don't". It would kind of defeat the whole > purpose of the extension in my opinion, as implementations cannot rely > on it. Haven't thought about it that way and indeed it makes a lot of sense. 100% agreed. > > Maybe the right approach would be to tell users to never manually enable > the extension and instead to provide a command that both: > > - Persists the submodule gitdirs for any populated submodules in the > gitconfig. > > - Enables the repsitory extension. > > If we had that then we could count on the submodule gitdirs to exist in > the gitconfig, and if they don't we would die with an error message that > indicates that the repository is broken, maybe even with a hint for the > user on how to fix it. Thank you Patrick for clarifying this, really appreciate it. I will implement this design in v6.