Help breaking up a large merge.

Say we have a tree that we've been working on for a few months. An outside vendor has also been working on the same tree during this time, and we need to merge with their work.

The difficulty I'm having is that there are a lot of conflicts resulting from the merge (expected), and it would be nice to somehow be able to work on a smaller set of these conflicts at a time.

Some of the conflicts are caused by a single change in the other tree. This is easy to cherry-pick into my tree, resolve, and then test those changes independently.

But other conflicts are caused by groups of commits that are interleaved with others.

Ideally, I'd like to be able to divide this conflict resolution work up among a small group of people, have everybody work on part, test their part, and then I could bring all of the resolved versions together, test that, and make that the actual merge commit in our repo. I've had a few ideas, but none really seem to work all that well.

   - Do "git merge -s ours their-tree".  Then, in another branch try
     the merge, and resolve a group of files that go together.  Put
     these into the 'ours' tree and ammend these changes to the merge
     commit.  The problem here is that this misses all of the merges
     that would happen automatically.

   - "git branch -b tmp $(git merge-base our-head their-tree)", and
     then: "git checkout their-tree filenames" for a small group of
     conflicting files.  Commit this, then in my regular tree, cherry
     pick this change and resolve the conflict.  Then, when finally
     doing the merge with their tree, these files can be resolved by
     just using our version.  This still requires doing some tracking.

Any other ideas?

In the future, we're going to try and work more closely with the vendor, but we have to get to the point of having something common to start that.

Thanks, David