On Sat, Jul 24, 2010, skillzero@xxxxxxxxx wrote: > On Fri, Jul 23, 2010 at 6:20 PM, Avery Pennarun <apenwarr@xxxxxxxxx> wrote: >> On Fri, Jul 23, 2010 at 8:58 PM, <skillzero@xxxxxxxxx> wrote: >>> On Fri, Jul 23, 2010 at 3:50 PM, Avery Pennarun <apenwarr@xxxxxxxxx> wrote: >> This is indeed a problem with large repositories. Of course, >> splitting them with git-submodule is kind of cheating, because it just >> makes git-status *not look* to see if those files are dirty or not. >> If they are dirty and you forget to commit them, you'll never know >> until someone tells you later. It would be functionally equivalent to >> just have git-status not look inside certain subdirs of a single >> repository. > > I think it's only cheating if you're using all of the submodules. The > main purpose of submodules for me (although I don't currently use > submodules) would be so I don't need to keep modules on disk that I > don't care about. If a developer is working on an app, they don't need > the OS directories/modules so they get much faster git status/etc and > there wouldn't be other directories to have dirty files in. [...] There are two issues that make submodules or git-subtree a better solution. If you work with subprojects via upstream subproject repository, and you don't always need / want all subprojects, git-submodule is better. If you always have checked out all subprojects, and you edit them in superproject, git-subtree is better. -- Jakub Narebski Poland -- 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