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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html