Duy Nguyen <pclouds@xxxxxxxxx> writes: > I think we should stop the ok-to-replace feature when submodules are > involved, we consider submdules much more valuable than symlinks. Hmm, I am not sure "valuable" is a good criterion to decide what should happen, though. The push to use ".git" that is a file pointing at a repository that is safely stored away is a move to make valuable submodule more easily removable from the working tree without losing information, so that we can remove it from the working tree when the user instructs us to, just like we can remove a symlink safely without losing information. The only thing we need to be careful is that that the path that corresponds to the index entry is not "dirty". That is, for a symlink, if you make it point at something different without doing "git add" it, you would lose that working-tree-only change when we "kill" that symbolic link in order to replace it with a regular directory. For a submodule, if you have uncommitted changes in the submodule working tree, you would lose that the same way when we "kill" that submodule in order to replace that directory as part of the superproject's working tree. There may need some more safety implemented (i.e. how we detect the "dirty"-ness and when we stop the operation based on that), but I would imagine there is nothing fundamentally special about submodule that does not apply to a symlink or a normal blob. -- 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