Martin Waitz <tali@xxxxxxxxxxxxxx> wrote: > I am currently working on adding submodule support to GIT. > Here I am presenting some prototyping work to show how submodules could > be implemented in GIT. Aside from a GUI for Git that I can give to a non-technical user and have them be productive with (and without getting "this sucks!" complaints from them), submodule support is the next highest priority feature for me in Git. So as soon as I can get git-gui to that point I'll probably redirect as much of my "Git time" as I can to testing your submodule implementation. > When a merge in the parent has to resolve changes in the submodule, > then it does exactly the same as for files: at first it is tried to resolve > it in the index and if this is not possible it will have store stages 1-3 > in the index and tries a content merge. The only difference with submodules > is that the content merge is not possible with a simple diff3 call, but > that the GIT merge machinery has to recurse into the submodule. Right. And what's really cool about that is many times a subproject merge will be trivial, so top level project merges will be still be trivial in index merges. But what's complicated about that is you need to make sure the subproject working directory is fast-forwarded to the new commit. :) > The most important next step is to commit to some object database format > for submodules. So please, do give feedback about the proposed changes > to the tree object. I think the S_IFSOCK approach is the right way to go here, and thus I'm reasonably happy with this repository format. But Linus and Junio do tend to be better at this than I... :-) -- Shawn. - 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