On Tue, 20 Nov 2007, Finn Arne Gangstad wrote: > 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? It's an automatic merge if you've got the submodule; if you don't have the submodule, you can't tell that the merge would be trivial, because you can't even see the order of the history in the submodule, let alone which files change and how. This just means that the patch queue manager is going to have to have all of the submodules, which is probably reasonable if the patch queue manager is responsible for making sure that the combination works. -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
