Robin Rosenberg wrote: > lördag 02 december 2006 21:16 skrev Jakub Narebski: >> >> The problem with submodule as separate git repository is that if you >> move submodule (subproject) somewhere else in the repository (or just >> rename it), you have to update alternates file... and this happens not >> only on move itself, but also on checkout and reset. But that can be >> managed by having in alternates all possible places the submodule ends >> into. I don't know if it is truly a problem. > > A nasty problem with separate repositories for submodules is that when you > screw up and git complains about everything you try do do, you previously > could do rm -rf *; git reset --hard and retry whatever you were trying to do. > With separate repositories your submodules will be resting in /dev/null, > unless you're very, very careful. The solution to this concern could be having GIT_DIR for submodule outside it's working area, for example somewhere in GIT_DIR of the supermodule, and use either symlink or (to be coded) .gitlink symbolic reference to GIT_DIR file. Disadvantage of that is that it moves troubles with moving subproject (although there are no troubles with simple subproject directory renaming) from alternates file to GIT_DIR link representation in submodule. As Linus said, there are advantages to having submodule repository use separate object database (clone and other operation scaling, index size), and I think they outweight the troubles with moving/renaming the directory submodule resides in. P.S. I think that the problem with bad performance of too large index is similar to the problems filesystems have with directories with large number of files; some filesystems solved this problem. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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