Re: Notes on Using Git with Subprojects

Martin Waitz wrote:
[...]

My current approach is like this:

 * create a .gitmodules file which lists all the directories
   which contain a submodule.
 * the .git/refs/heads directory of the submodule gets stored in
   .gitmodule/<modulename> inside the parent project
 * both things above should be tracked in the parent project.
   This way you always store the current state of each submodule
   in each commit of the parent project.  And you don't have to
   create a new parent commit for each change.  You can commit
   to the parent project when you think that all your modules are
   in a good state.

This means that modules are not separate, stand alone projects but, 
rather, just a sub part of your bigger project. Very useful and 
applicable in some situations but other situations want/need separate, 
stand alone subprojects.

 * When checking out a project, all submodules listen in .gitmodules
   get checked out, too.
 * If there is a merge conflict in the module list or its refs/heads,
   this is handled specially, e.g. by triggering a new merge inside
   the submodule.
 * The object directory is shared between the parent and all modules.
   To make fsck-objects happy, the parent gets a refs/module link
   pointing to .gitmodule/ and all submodules get a refs/parent
   link pointing to the refs directory of the parent.

[...]

By storing the complete refs/heads directory for each submodule instead
of only one head, it is possible to track multiple branches of a
subproject.  I'm don't know yet how this works out in praktice but I
think that it can be nice to be able to atomically commit to several
branches of one submodule (perhaps one branch per customer, per
hardware platform, whatever).

It's not immediately clear to me if tracking several long term 
(globally) visible branches in a checkout sub module is generally useful 
or only useful in special situations. I need to think about this...

[...]

You solved a similar problem to the one I'm working on; and one that is 
applicable to a number of projects. Namely, projects where all the parts 
are under the control of the same entity. For projects looking to escape 
  CVS, that use CVS modules, this looks like a Git solution.

The problem I'm working on is how to deal with the sub parts of a larger 
project when those sub parts are controlled by different entity. Silly 
example: the kernel is controlled by Linus; glibc is controlled by the 
GNU folks, gcc is controlled by some other GNU folks, the web server is 
controlled by the Apache Foundation, the X server is controlled by Xorg, 
etc.