Re: Dividing up a large merge.

On Wed, Jul 15, 2009 at 11:57:59AM -0700, Daniel Barkalow wrote:

It sounds to me like you're maintaining an internal version that everybody 
merges their stuff into, and you periodically merge that with the mainline 
kernel (generating a lot of conflicts which have to be resolved at the 
same time). Instead of merging the branch that contains a lot of merges, 
it would probably be easier to merge into a clone of mainline each of the 
things that was merged before. That is, instead of merging less than all 
of two trees, you'd merge commits which are not the newest commit on the 
branch, choosing ones that individuals can resolve.

That's part of it, although I have a pretty good handle on that
part.

The place where this comes up is that people in company X are
working on an internal version and company Y are working on a
similar internal version.  We need to share back and forth
between these more frequently than stuff gets into the mainline.

We do rebase at various points, but it takes quite a bit of work,
and it's fairly different work than the conflicts I'm concerned
with here.

Thanks,
David