Jeff King <peff@xxxxxxxx> writes: > Certainly I think it _could_ be a valid state. But traditionally it > caused "clone --recursive" to barf. And from what Stefan and Brandon > have said, we are moving in the opposite direction entirely, with > .gitmodules becoming the source of truth. > > I could see arguments for going in either direction (gitlinks versus > .gitmodules as source of truth for submodules). But it bothers me that > it's so easy to create a state that will behave in a confusing manner. > ... > Allowing both is not in itself wrong. But because we provide no > guidance for the expert route, it's easy to shoot yourself in the foot > and not even realize it. Which is why I suggested a warning and not > forbidding the operation. Or better still, an advise() block that tells > you how to recover (probably "git submodule add", though it might need > to learn to handle already-present gitlinks). And which can be disabled > if you really are an expert user. Yeah, the current situation is bad in that having both .gitmodules file and gitlinks in a tree allows for redundant pieces of information to go out of sync and result in contradiction. A gitlink without an entry in the .gitmodules file is an obvious example. An entry in .gitmodules file whose path does not have a gitlink in the tree would also be a broken case. While "git submodule" was the only/primary interface to the submodule, it was rather easy to explain that ".gitmodules need to be consistent with the index and the tree iff you do 'git submodule' thing" (implying "if you only use gitlinks to bind two or more projects locally without sharing with others, you do not need 'git submodule' and you do not need .gitmodules"), but with the recent push to add "--recurse-submodules" to everything, the extent of what was historically "iff you do 'git submodule' thing" is getting larger and it becomes more and more important to keep .gitmodules consistent with gitlinks in the tree that house it. I find it a bit sad, but I do not think of a better way X-<.