Dividing up a large merge.

[davidb@quicinc.com]

I'm trying to figure out a better way of dividing up the effort
involved in a merge amongst a group of people.  Right now, I
basically describe the merge to each of them, and ask them to
merge their part, and then 'git checkout HEAD' the other parts.
They tell me about the commits, along with the files that they've
merged correctly.  When everybody is done, I make a real merge
commit, and pull in all of their files.  It's a lot for me to
track, and confusing for each person.

I'd like to create a branch we can all push to that we gradually
work to become the result of a resolved merge.  Not only does git
not want to help me do the merge, but seems to actively be
fighting against me doing this.

What I thought of was something like telling people to do:

  $ git merge v2.6.30
  resolve some files
  $ git checkout HEAD ...rest of files...
  $ git commit; git push

but that 'rest of files' is fairly large and complicated.  I can
think of two ideas:

  - Something that basically does a partial 'git reset --hard
    HEAD' to put many of the files back.

  - The ability to specify subpaths on the 'git merge' to do the
    merge work but limited to a directory or set of files.

Obviously, either case will require someone to still track the
overall effort and make sure the final state of the tree really
represents the total merge.

Is there anything that can parse the output of 'git merge-tree'?
Even just splitting this up and then applying parts of it would
be helpful.  Would it be useful to write something that can apply
the results output of 'git merge-tree'?

Thanks,
David