Re: Notes on Using Git with Subprojects

hoi :)

On Wed, Sep 27, 2006 at 02:01:11PM +0200, Johannes Schindelin wrote:

On Wed, 27 Sep 2006, Martin Waitz wrote:

quoted

On Wed, Sep 27, 2006 at 11:55:22AM +0200, Johannes Schindelin wrote:

quoted

quoted

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

Taking this a step further, you could make subproject/.git/refs/heads a 
symbolic link to .git/refs/heads/subproject, with the benefit that fsck 
Just Works.

in fact it is done this way (more or less).

With the difference, that if you store the refs outside of 
<root>/.git/refs, you have to take extra care that prune does not delete 
the corresponding objects.

that's why there is .git/refs/module/modulname -> .gitmodule/modulename.

quoted

You can accumulate as many changes in different subprojects until you
get to a state that is worth committing in the parent project.
All these changes are then seen as one atomic change to the whole
project.

AFAICT this is not the idea of subprojects-in-git. If you have to track 
the subprojects in the root project manually anyway, you don't need _any_ 
additional tool (you _can_ track files in a subdirectory containing a .git 
subdirectory).

But then you loose the fine grained commits of your subprojects.
You only store the tree of the subproject when committing to the parent,
not the entire history.

I think having the "commit subproject changes to parent" step as a
manual action makes sense in the same way as you have to trigger a
commit to a repository by hand, too. You are not storing every little
change to your filesystem in the database.

-- 
Martin Waitz