Re: Cherry picking instead of merges.

[Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>]

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