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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html