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