Re: [GSoC 11 submodule] Status update
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:51:32
Phil Hord [off-list ref] 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.