David Brown schrieb: > Say we have a tree that we've been working on for a few months. An > outside vendor has also been working on the same tree during this > time, and we need to merge with their work. > > The difficulty I'm having is that there are a lot of conflicts > resulting from the merge (expected), and it would be nice to somehow > be able to work on a smaller set of these conflicts at a time. > > Some of the conflicts are caused by a single change in the other tree. > This is easy to cherry-pick into my tree, resolve, and then test those > changes independently. > > But other conflicts are caused by groups of commits that are > interleaved with others. In a similar situation I was thinking about this approach: 1. Do the merge. 2. Resolve conflicts in an area that can be tested in isolation. 3. Undo all other changes that the merge brought in. 4. Commit. 5. Install a graft that removes the second parent of the merge commit. 6. Rinse and repeat. 7. Finally, remove the grafts, and perhaps collapse the merge commits. I didn't test this, yet. Hmm, thinking a bit more about this, 1 and 5 can probably be replaced by a mere 'git merge --squash'. -- Hannes -- 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
