Re: Cherry picking instead of merges.

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 4, 2008, 00:39 UTC
Message-ID: <alpine.LFD.1.10.0807031735330.2815@woody.linux-foundation.org>
In-Reply-To: <20080703223949.GA23092@old.davidb.org>

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.

Show 5 quoted lines

> 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