Jens Lehmann wrote: > 1) Switching branches, merging, rebasing and resetting in the > superproject must result in a checkout of the matching submodule > work tree Switching branches can change the HEAD commit of an already checked out submodule, and switching branches can change the list of submodules. For the latter, maybe it would make sense to introduce ‘git checkout --recursive’ which runs ‘submodule update --init --recursive’ after checkout. IMHO, in git 2.0 this even ought to be made the default. One could use --no-recursive to access the more flexible traditional behavior. > 2) On "git clone" the submodules must be cloned and checked out too Does ‘git clone --recursive’ take care of it? The Makefile would need to be tweaked to give a reasonable message when the caller forgets to check out an important submodule. > 3) Switching between commits in the superproject where a directory > is replaced by a submodule or vice versa doesn't work right now. > Submodules should handle this situation, otherwise the commit > putting gitk and git gui into submodules would become a barrier. Yes, this is the fatal problem imho since it would affect basic maintainance tasks. I consider maintainance of the branch (rather than consumption) the most important piece to begin with; for a branch not in next, usability problems can be resolved over time. > I am working on these issues, but that will take some time. But when > they are solved, me too thinks that these two should become submodules. Thanks for the explanation. -- 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