Re: Partial checkouts / submodules

From: Finn Arne Gangstad <finnag@pvv.org>
Date: Nov 20, 2007, 19:22 UTC
Message-ID: <20071120192231.GA23240@pvv.org>
In-Reply-To: <Pine.LNX.4.64.0711201336530.32410@iabervon.org>

On Tue, Nov 20, 2007 at 01:59:41PM -0500, Daniel Barkalow wrote:

Show 21 quoted lines

> 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