Re: Dividing up a large merge.

From: davidb@quicinc.com <davidb@quicinc.com>
Date: Jul 15, 2009, 00:29 UTC
Message-ID: <20090715002926.GA26630@huya.quicinc.com>
In-Reply-To: <3e8340490907141716j77df346es1f894d6a7f6cb0aa@mail.gmail.com>

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

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

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

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

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

Thanks, David