On Mon, 26 Mar 2007, Martin Waitz wrote: > 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). I tried that yesterday, but I fail reading comprehension; I lost the "module2" bit by the time I actually fetched. I'll look into this. > 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. That's what I remember. But it's only an issue with super-scale projects (i.e., where your subprojects are full-sized projects in their own right, and you've got a hundred of them), right? I'm working on the other end (factoring out the common bit from a bunch of similar small projects), so I should be fine with respect to scalability of the implementation. Would you guess that a patch series to complete the module2 user interface adaptation would also apply to module3 and therefore be useful in the future? > 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.) So, I had the nutty idea that it would be convenient if I could make different files in a single directory come from different projects. But I can't think of a sane user interface, so I think that this isn't practical from that direction, so it's probably not worth worrying about from the data structure end, either. (Answer for the usecase: "ln -s make/Makefile Makefile; git add Makefile", and mock systems that don't handle symlinks). But, just to be clear, the semantics of having a commit abcd at a path foo are, with respect to the tree this represents, that abcd:* appears at foo/*. Right? Are there any standards we should discuss with respect to refs related to subprojects? I've updated the wiki page with this information. -Daniel *This .sig left intentionally blank* - 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