hoi :) On Sun, Mar 25, 2007 at 01:37:25PM -0400, Daniel Barkalow wrote: > I remember that last time I checked, there were a number of designs for > subprojects and at least a couple of implementations, but none that was > complete to the point of being mergeable. Are there any subproject > implementations available that haven't run into unsolveable problems? I'm > presently only looking at stuff that totals to a reasonable single project > size and rate of growth, so I'm not worried about the large-scale storage > requirement issue. You can try to play with my prototype: git.admingilde.org/tali/git.git, branch module2 (to get an example of how to use it, look at the test script in t/t7500-submodule.sh). The core operations should work, but not all the user interface is adapted to support submodules. E.g. git-status will not show if a submodule has dirty changes, it will only show submodule changes which are already commited to the submodule but not yet to the supermodule. But at least simple merges do work with submodules. I abondoned this branch (no further work, only occasionally pulling in updates from upstream git.git) as it has scalability problems with large projects. At the moment I'm working on the module3 branch, which tries to address the scalability problem by separating the object store. This is still in the phase of early prototyping, just to see if it can work. But I am already at the point that I am confident to be able to finish it this way. The objects created by the module2 and module3 branches are the same, module3 only moves those belonging to the submodule to another location. So If you start using module2 branch now you should be able to upgrade later. But to be extra sure, we should have some discussion about the object format here. (There is nothing new here, really: Just one more tree entry file mode which says that this is not a file or directory entry, but a submodule, represented by one commit.) -- Martin Waitz
Attachment:
signature.asc
Description: Digital signature