On Thu, Mar 17, 2011 at 07:38, Jeff King <peff@xxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html