Subject: Re: Notes on Using Git with Subprojects

From: Martin Waitz <[email-masked]>
Date: Wed, 27 Sep 2006 14:46:04 +0200

hoi :)

On Wed, Sep 27, 2006 at 02:01:11PM +0200, Johannes Schindelin wrote:
> 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.

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

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