Re: Notes on Using Git with Subprojects

From: A Large Angry SCM <gitzilla@gmail.com>
Date: Sep 27, 2006, 16:58 UTC
Message-ID: <451AADC3.40201@gmail.com>
In-Reply-To: <20060927080652.GA8056@admingilde.org>

Martin Waitz wrote: [...]

Show 12 quoted lines

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

Show 10 quoted lines

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

[...]

Show 6 quoted lines

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