Finn Arne Gangstad wrote: > I'll try to boil this down to the simplest case possible. If > submodules can do this I'll be really happy :) > > Developer A makes a change in submodule1 and in submodule2 > Developer B makes a change in submodule2 and in submodule3 And committed changes to submodules and supermodule, I guess, so developer A has submodule1 in state 1a, submodule2 in state 2a. sumbodule3 in state 3, and supermodule in state [1a, 2a, 3], while developer B has submodule1 in state 1, submodule2 in state 2b, submodule3 in state 3b, and supermodule in state [1, 2b, 3b]. > A and B don't know about eachother. They send their modifications > somewhere (push to a shared repository with a well chosen branch name, > for example), or send a mail "please pull from my repo" to the patch > queue manager. > > It is absolutely crucial that for each developer, either both their > modifications go in, or none of them. Git should make picking only > one of their modifications hard. Git treats submodules as whole, so merging A and B supermodules will result in [1a, CONFLICT(2a/2b), 3b]. 2a/2b _might_ resolve cleanly to 2ab, but this requires submodule2 to be checked out. I'm not sure what git does in such case, but it is not much different from the case when both sides A and B modified the same file, but it merges on file-level cleanly; here we have subprojects and tree-level in-subproject clean merge. [...] By the way, submodules in supermodule should be thought as on 'detached HEAD'. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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
