Re: Dividing up a large merge.

[Avery Pennarun <apenwarr@gmail.com>]

On Tue, Jul 14, 2009 at 9:19 PM, <davidb@quicinc.com> wrote:
> On Tue, Jul 14, 2009 at 05:34:26PM -0700, Avery Pennarun wrote:
>> How about having one person do the merge, then commit it (including
>> conflict markers), then have other people just make a series of
>> commits removing the conflict markers?
>
> I guess this helps in some sense, but the intermediate result
> isn't going to build, and things like mergetool aren't going to
> work.  It's helpful for the individuals to have the full merge
> conflict available, or at least the stages of the files in
> question.

It sounds like you're going in circles a bit here.  You want the full
merge conflict available - but you want it to be able to build.

It sounds like the "git reset the unwanted subdirs" solution suggested
earlier is the only option that will really work.  You could simplify
life for your co-workers by writing a script to automate the steps, I
suppose.

You probably want all the individuals to use merge --squash, so that
you don't mark the history as merged until you're done.  Then you
combine all their work at the end and mark the commit as done using
'git merge -s ours'.

Avery