On Fri, May 29, 2009 at 03:53:26PM -0400, Avery Pennarun wrote: > On Fri, May 29, 2009 at 2:41 PM, R. Tyler Ballance <tyler@xxxxxxxxx> wrote: > > As some of you may recall from my last swath of emails to the list > > regarding memory usage and repository size, we have quite a large > > repository. About a month ago, I added a submodule to the primary repo > > in an effort to start to segment where possible, particularly around > > third party modules. > > > > I've noticed that keeping submodules updated is an absolute pain, > > particularly with a large multiuser setup with *lots* of branches. > > Just so I understand, is the reason you're splitting into submodules > *just* to avoid memory usage / repository size issues? I can sort of > understand the memory usage issues - sort of - but how does it reduce > repository size if you need to need to check out all the submodule > repositories along with the main project anyway? I've got an eye on submodules as a way of avoiding the need to require a whole tree clone to just work on parts of it, but that's not really relevant to my query, just explaining our environment and setting the stage ;) We're using submodules right now similar to how we used svn externals in the past (except better, clearly), to incorporate outside components (like open source projects) that our stack depends on. > Just looking to clarify for myself. (I'm continuing my work on > git-subtree, which is getting more and more positive feedback. It > solves all the *other* problems that you listed vs. submodules, but it > certainly doesn't resolve any repository size issues.) Good to know, we're still on Git 1.6.1, are there any benefits or additional features in more recent releases of Git that help alleviate the submodules issues I outlined at the top of the thread? Cheers -- -R. Tyler Ballance Slide, Inc.
Attachment:
pgp58PXLPAvQ6.pgp
Description: PGP signature