Re: Managing submodules on large multi-user projects

[Avery Pennarun <apenwarr@gmail.com>]

On Fri, May 29, 2009 at 4:09 PM, R. Tyler Ballance <tyler@slide.com> wrote:
> On Fri, May 29, 2009 at 03:53:26PM -0400, Avery Pennarun wrote:
>> 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.

That makes sense.

>> 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?

git-subtree is my own little project that hasn't been accepted into
git proper yet.  It does work with git 1.6.1 (and also git 1.5.4, at
least) just by dropping the script into your PATH.  Google "git
subtree" for more.

AFAIK, the particular issues you outlined with submodules continue to
exist in latest git.  They are certainly fixable (they aren't
*fundamental* problems), but nobody has fixed them yet.  I looked at
the issues for a long time and failed miserably to find a good general
solution, but that's just me.

Have fun,

Avery