From: Jakub Narebski Date: Mon, 26 Jul 2010 13:13:53 GMT Subject: Re: Avery Pennarun's git-subtree? Message-ID: <201007261513.57045.jnareb@gmail.com> In-Reply-To: On Sat, Jul 24, 2010, skillzero@gmail.com wrote: > On Fri, Jul 23, 2010 at 6:20 PM, Avery Pennarun wrote: >> On Fri, Jul 23, 2010 at 8:58 PM,   wrote: >>> On Fri, Jul 23, 2010 at 3:50 PM, Avery Pennarun 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