Robert Dailey <rcdailey.lists@xxxxxxxxx> writes: > The gitmodules documentation[1] states that the .gitmodules file is at > the root. However, it would be nice if this could be supported in any > directory similar to how .gitignore works. I have a mild suspicion that there would be a huge impedance mismatch between what gitmodules file is meant to do and the way ignore/attribute setting is done. When the mechanism is primarily about expressing a few generic traits that are shared by things that can be grouped by paths (e.g. "all paths whose pathnames match '*.py' pattern contain text", "all paths in sub/ directory are ignored"), it may make sense to spread the information across multiple .gitignore files and make the closest one take precedence over the further ones. Even though allowing multiple sources of information spread over the tree leads to end-user confusion (e.g. "why is this path ignored?", which triggered the debugging aid "git check-ignore"), such a grouping by pattern matching on paths (which is what makes "closest file take precedence" meaningful) to assign generic traits (e.g. "it's text") makes it worthwhile by allowing to express the rules more concisely. Compared to that, what .gitmodules file expresses is more specific to each submodule---no two submodules in your single superproject would share the same URL, unless you are doing something quite unusual, for example. Having a single file also means that updating is much simpler---"git submodule add" and other things do not have to choose among .gitmodules, a/.gitmodules and a/b/.gitmodules when they update an entry for the submodule at path "a/b/c". Having said that, I do not think the current ".gitmodules must be at the top and nothing else matters" is ideal. A possible change that I suspect may make more sense is to get rid of .gitmodules file, instead of spreading more of them all over the tree. The current gitlink implementation records only the "what commit from the subproject history is to be checked out at this path?" and nothing else, by storing a single SHA-1 that happens to be the name of the commit object (but the superproject does not even care the fact that it is a commit or a random string). We could substitute that with the name of a blob object that belongs to the superproject history and records the information about the submodule at the path (e.g. "which repository the upstream project recommends to clone the subproject from?", "what commit object is to be checked out"). When you see a single tree of a superproject, you need to see what commit is to be checked out from the tree object and everything else needs to be read from the .gitmodules file in that tree in the current system, but it does not have to be that way.
