Re: Dividing up a large merge.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]