Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > ... (at least when it concerns their work tree, the > gitfile effort is trying to introduce some superproject awareness). I don't think so. The "gitfile effort" just makes it more convenient and potentially safer for superproject to remove submodule working tree by running an equivalent of "rm -fr submodule". The submodule shouldn't even care where its .git metadirectory is by looking at the "gitfile: " line, nor should it assume that location its .git metadirectory moved out of its working tree has some fixed relationship with its supermodule's repository. E.g. the superproject could choose to store it under $HOME/cache or /var/state as long as it knows where to point it back to after it runs "rm -rf submodule" and then it has to re-instantiate the submodule. IOW, the superproject must be aware of that location, but submodule shouldn't depend on what convention the superproject chose to use. After all, there may not even be a superproject when gitfile is in use, so running "test -f .git" and assuming that it is used as a submodule of somebody else is already a bogus test. -- 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