git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Managing submodules on large multi-user projects

From
Avery Pennarun <apenwarr@gmail.com>
Date
May 29, 2009, 19:53 UTC
Message-ID
<32541b130905291253k3fa1d675yde1dddb5e8090ef9@mail.gmail.com>
In-Reply-To
<20090529184125.GE11222@starfruit.corp.slide.com>
On Fri, May 29, 2009 at 2:41 PM, R. Tyler Ballance <tyler@slide.com> wrote:
Show 8 quoted lines
> 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?

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.)

Have fun,
Avery
Previous: R. Tyler BallanceNext: R. Tyler Ballance
Message 2 of 7 in “Managing submodules on large multi-user projects”
  1. R. Tyler BallanceMay 29, 2009
  2. Avery PennarunMay 29, 2009
  3. R. Tyler BallanceMay 29, 2009
  4. Avery PennarunMay 29, 2009
  5. Felipe ContrerasMay 29, 2009
  6. R. Tyler BallanceJun 23, 2009
  7. Alex RiesenMay 31, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.