Re: [PATCH v5 4/7] submodule: add extension to encode gitdir paths
From: Junio C Hamano <hidden>
Date: 2025-12-05 22:48:00
Adrian Ratiu [off-list ref] writes:
quoted
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 ;-).