Re: Dividing up a large merge.

On Tue, 14 Jul 2009, davidb@quicinc.com wrote:

On Tue, Jul 14, 2009 at 05:16:54PM -0700, Bryan Donlan wrote:

quoted

What do you mean by describing a merge? git is designed to have all
the information needed for a merge inherent in the repository history.

Yes, provided you can actually do the merge all at once.

quoted

Why are there so many conflicts to make this an issue?

Because I have to work in the "real world".

quoted

If the commits are isolated to small changes, rebasing the developer
topic branches instead of merging may help, by allowing you to take
conflicts one commit at a time. For example, if your problems are
primarily conflicts between developer branches and upstream:

No real developer branches with conflicts (I make those be
fixed), but several upstreams.  We have many developers busily
doing work, and one or more other companies is also working on
the same code.  Meanwhile, the mainline kernel advances at it's
own astounding rate.

Unfortunately, paying customers will always get priority of work,
even when that position is actually somewhat shortsighted and it
makes for a lot of merge effort later.

The real issue is that there isn't any single individual who
understands all of the code that conflicts.  It has to be divided
up somehow, I'm just trying to figure out a better way of doing
it.

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.

This also has the advantage where, if two of the changes affect an API 
that's used in various different places, one person will get the 
responsibility of resolving each of those conflicts, despite them being in 
the middle of code they don't really understand, because they understand 
what happened with the API and therefore what has to be done in that 
little spot. Dividing the merge up by parts of the content would split 
this work among people who aren't looking at the conflict in the 
definition of the API.

	-Daniel
*This .sig left intentionally blank*