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
Attachment:
signature.asc
Description: Digital signature