On Mon, May 12, 2025 at 6:02 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > K Jayatheerth <jayatheerthkulkarni2005@xxxxxxxxx> writes: > > > When a submodule is added at a path that previously hosted another submodule > > (e.g., 'child'), Git reuses the submodule name derived from the path and > > updates the corresponding entry in .gitmodules. This can silently overwrite > > existing configuration if the old submodule was only moved (e.g., to > > 'child_old') without renaming the submodule. > > > > This patch improves the `module_add()` logic by checking whether the > > submodule name already exists in the config but maps to a different path. > > Quite sensible description of the problem and the proposed course of > improvement. > > I do not think `--force` that allows the same name to be reused a > good idea at all, though. We shouldn't encourage its use to resolve > such a case. If what used to be called `child` now sits elsewhere, > perhaps because the tree structure was reorganized due to mass > renaming, but if it still is being used in the project, there is no > good reason to nuke the configuration recorded for that existing > module. > > The module name used in .git/config is purely local so the user > should just give a new one a name that does not conflict, or even > better yet, perhaps the tool should pick a unique and nonconflicting > name automatically, no? > That makes sense I see the point in using --force to resolve name conflicts might not be ideal, especially when the previous submodule config may still be valid and in use. As a potential improvement, I was thinking of mimicking how duplicate filenames are handled: if the default submodule name (derived from the path) already exists and maps to a different path, we could automatically append an incrementing number (foo, foo1, foo2, etc.) until a non-conflicting name is found. -Jayatheerth
