Phil Hord <hordp@xxxxxxxxx> writes: > It frightens me because it seems like a fundamental break from the > current submodule functionality. Today a submodule exists as a git > repository with no knowledge that it is a submodule or who its > super-repository is. The use of .git that is a text file that records where the real directory is not limited to submodules. Placing that "real directory" somewhere in the .git directory of the superproject is merely a convention. In other words, it does not change anything fundamental. > Once it finds it, it will > (safely, today) assume that is the .git directory relating to its > files. After this change, the tool will be broken. Then it is already broken if it does not pay attention to .git that is not a directory but is a text file that records where the real directory is. > I think I can answer my other concerns now. Do these answers sound right? > > - What happens if the submodule working directory is dirty? > - But what if the submodule working directory is 'clean' after considering > .gitignore? Do untracked/ignored files also get deleted? > - What if a 'git checkout' results in the submodule being removed? > - What if a 'git checkout' or 'git merge' results in submodule 'foo' being > added where there is already a file named 'foo'? These "different" questions are answered exactly the same way, which is: > Treat it the same as git does for its own working directory. When switching to another branch, a directory that does not exist in the switched-to branch needs to be removed, but we would refrain from "rm -fr" that directory if it has any leftover cruft in it (untracked and unignored files). A submodule directory should behave in the same way. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html