From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Wed, 27 Sep 2006 12:01:11 GMT
Subject: Re: Notes on Using Git with Subprojects
Message-ID: <Pine.LNX.4.63.0609271358100.14200@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <20060927113813.GC8056@admingilde.org>

Hi.

On Wed, 27 Sep 2006, Martin Waitz wrote:

> On Wed, Sep 27, 2006 at 11:55:22AM +0200, Johannes Schindelin 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
> > 
> > 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.

> > Nevertheless, you have to take care of the fact that you need to commit 
> > the state of the root project just after committing to any subproject.
> 
> why?
> 
> 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).

Ciao,
Dscho