Re: Sharing a massive distributed merge
- From
Alex Riesen <raa.lkml@gmail.com>
- Date
- Mar 17, 2011, 08:53 UTC
- Message-ID
- <AANLkTimTKbKWmf80u-kgnvQ2gT8hx2KTm6HGbWejt3eg@mail.gmail.com>
- In-Reply-To
- <20110317063816.GD11931@sigill.intra.peff.net>
On Thu, Mar 17, 2011 at 07:38, Jeff King <peff@peff.net> wrote:
Show 21 quoted lines
> 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.