From: Alex Riesen Date: Thu, 17 Mar 2011 08:53:21 GMT Subject: Re: Sharing a massive distributed merge Message-ID: In-Reply-To: <20110317063816.GD11931@sigill.intra.peff.net> On Thu, Mar 17, 2011 at 07:38, Jeff King 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.