Re: Sharing a massive distributed merge

[Alex Riesen <raa.lkml@gmail.com>]

On Thu, Mar 17, 2011 at 07:38, Jeff King <peff@peff.net> wrote:
> I don't think you need to do anything so drastic. You can just have
> everybody do the partial merge, commit, and then push their result.  And
> then as you suggest below, one person does the real merge, uses checkout
> to install the desired result state from each person's partial tree, and
> then everybody throws away their partial merges.
>
> The trick is that each person will resolve some conflicts and commit,
> but you need to know which ones they resolved. They can't leave things
> unmerged in the final commit. So they would have to provide such a list
> to you; one way is in the commit message[1].
>
> So let's say you have three devs, Alice, Bob, and Charlie, and one
> integrator, Matt, who will do the merge. Each of the developers does:
>
>  git checkout -b partial-merge
>  git merge old-topic
>  git mergetool ;# or manually resolve and git add
>
> Eventually they get tired of the conflicts and give up. So they record
> the list of resolved paths, either manually or with something like[2]:
>
...
>
> And then they stage the rest of it (knowing it will be ignored by Matt)
> and commit:
>

What if they just revert the rest? Reset the files to their states before
merge. Than Matt can just collect the partial merges with a merge on
his side and take care of the conflicts left, which should be fewer.