Re: Partial checkouts / submodules

From: Jakub Narebski <jnareb@gmail.com>
Date: Nov 21, 2007, 00:04 UTC
Message-ID: <fhvslp$9jr$1@ger.gmane.org>
In-Reply-To: <20071120181932.GA20705@pvv.org>

Finn Arne Gangstad wrote:

Show 5 quoted lines

> 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].

Show 8 quoted lines

> 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