On Thu, Jun 26, 2014 at 8:19 AM, Bojan Stankovic <bstankov1...@gmail.com> wrote:
> Hello!
> I have a situation with a larger project that has lots of modules/libraries
> with their respective repos. Most of these modules are dependencies of other
> modules which are than dependencies of a project. And now it has come to the
> point where the main project has several sub-projects and many of modules
> are being shared. Some dependencies are more than 3-4 levels deep.
> I have read that it is possible to update/pull submodules inside of a
> project, but that works only for 1st level of submodules. Let's say that
> those submodules have their own submodules (2nd level) and that some 1st
> level submodules share the same 2nd level submodules. Also, 2nd lvl
> submodules have their submodules (lvl3), etc. Now what I should do is to
> firstly push changes made in 3rd level, than update submodules in 2nd level
> modules and push those, now I can go to 1st level, update and push, and
> finally update my project submodules and push those.
> This is now not only more work, but it still doesn't solve my problem why I
> need something like this and that is to be able to easily push and pull
> multiple repositories when changes were being made to those that dependent
> on each other. It can easily happen that someone in a team pushes changes in
> 4 of 5 repos, and when other members pull all except this one production
> line stops until error has been found.
> What can I do about this? Maybe some advices about workflow, has anyone else
> encountered this problem or is there some feature in Git that solves this.

To me it sounds like the project has reached a point where something
like git sub{modules,trees} might not offer the best solution.  You
might need to think more generally about configuration management.
How do you tie all the subprojects together with your build system?
How do you want to record "good combinations" of projects?  Most
importantly, how do you want to record "officially good combinations",
i.e. releases, of projects?

For instance, if you want your CI to be able to experimentally build
the latest-of-all, you probably want to record *exactly* what
combinations where successful and what combinations weren't.  You
might also want the ability to freeze specific subprojects and let
others float.  Recording this is git might be just what you want, or
you might find it a bit too rigid.  It's also likely to generate *a
lot* of tags/branches/etc.  So maybe you'll be happier with keeping
that outside git (e.g. manifests of SHAs).

You might come to the conclusion that this is complete overkill for
your project and that git sub* is perfect for your needs, but thinking
a little about it up front is better than putting together something
that turns out to be inadequate already from the start.  It also might
make it easier to recognise that you are about to outgrow your earlier


Magnus Therning                      OpenPGP: 0xAB4DFBA4
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe               http://therning.org/magnus

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to