From: Chris Packham <judge.packham@gmail.com>
Date: Mon, 11 Aug 2014 04:59:15 GMT
Subject: Sharing merge conflict resolution between multiple developers
Message-ID: <CAFOYHZCiKC4TR4jFVUB=W5qbDG8XvB2Obx1ZfTH8OF3E_c5BnA@mail.gmail.com>

Hi List,

At $dayjob we maintain internal forks of the a number of upstream repositories.

Unsurprisingly updating these forks can be extremely problematic,
especially when it's only one person doing the merge. Fortunately most
of us are in the same physical location so it is possible to drag in
someone who knows more about the code than the person merging but I
can't see that scaling with remote developers.

Is there any way where we could share the conflict resolution around
but still end up with a single merge commit. I'm thinking of something
like the following workflow

developer A:
  git merge $upstream
  <conflicts>
  git mergetool ...
  <resolves some of the conflicts>
  git commit -m "WIP: Merge upstream" --something-like--all-but-not

developer B:
  git pull developer_A
  git reset HEAD^
  <at this point it's be nice if developer B's work tree and index
were in the same state as developer A's before they ran 'git commit'>
  git mergetool ...
  <resolves the conflicts that they know about>
  git commit -m "WIP: Merge upstream" --something-like--all-but-not

developer A:
  git pull developer_B
  git reset HEAD^
  git mergetool ....
  <finishes off anything left>
  git commit
  <It'd be really nice if MERGE_MSG was retained through all of this>
  git push

Any thoughts on if something like this is currently possible? Is this
something other git users would find useful?

Thanks,
Chris