Martin Waitz <tali@xxxxxxxxxxxxxx> writes: > Your working tree now contains a complete git repository which has > features which are not available for normal files. Notable, you > have the possibility to create branches in the submodule. > If you insist in using HEAD you throw away those submodule capabilities. Why? If you are working in the parent module (e.g integration) and notice breakage due to a bug in a submodule, it is very plausible that you would want to cd into the directory you have the submodule checked out, which has its own .git/ as its repository, and perform a fix-up there, with the goal of coming up with a commit usable by the parent project pointed at by the HEAD of the submodule repository. And while working toward that goal, you will use branches, rebase, rewind or use StGIT there in that submodule repository. It does not forbid you from using any of these things -- as long as you end up with a good commit at HEAD that the supermodule can use. Once you come up with a suitable commit sitting at HEAD of the submodule repository, you cd up to the parent module. Top-level git-diff would notice that the commit recorded at the submodule path has been updated (because you now have a good commit at HEAD of the submodule repository, while earlier the one in your index was a dud). So it is not clear to me what your argument about throwing away capabilities is. - 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