On Thu, 3 Jul 2008, David Brown wrote: > > I'm still not clear how the one-commit-at-a-time resolution gets recorded > anywhere (except in the cherry-picking branch). For merges, the _only_ thing that matters from a "resolution" standpoint is that the history joins together. And it doesn't matter if it joins together fifty times or once - only the last point is relevant, since that becomes the last point of shared state. > It seems to be that I would need to do multiple merges, one at each point > where there is a conflict that I had to resolved. I would remember this as > I did each cherry picked change, but after the fact, I would have to > compare the cherry picked change with the one it came from, and figure out > where conflicts had to be resolved. No, because you simply don't care. You only care about the final result. With a single merge, there is only a single merge-point, and a single result. The advantage of doing the cherry-pick is just that it splits the decision on how to merge up into many smaller decisions (that is often the _dis_advantage of cherry-picking too - it often makes for more work, even if the individual work may be simpler). But once you've done all the small cherry-pick decisions, you'd only make one final merge that takes that final result as-is. Any future work will then know about the fact that you have a new common base point. Linus -- 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
