On Tue, Nov 20, 2007 at 01:59:41PM -0500, Daniel Barkalow wrote: > On Tue, 20 Nov 2007, 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 > > > > 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. > > This is the case; if developer A changes 2 from 2-O to 2-A, and developer > B changes 2 from 2-O to 2-B, merging both supermodule commits gets a > conflict, which requires a merge in submodule 2 before the supermodule > merge can be committed. And this is partly why I wanted to branch all the involved modules: In ~99% of the cases, 2-A and 2-B modify different files, or at least wildly different parts of the same file, so the merge should be trivial/automatic. Therefore, the supermodule merge should also be a trivial/automatic merge - but it isn't, is it? - Finn Arne - 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
