Re: Cherry picking instead of merges.

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 4, 2008, 05:30 UTC
Message-ID: <alpine.LFD.1.10.0807032221190.2815@woody.linux-foundation.org>
In-Reply-To: <20080704044032.GA4445@old.davidb.org>

On Thu, 3 Jul 2008, David Brown wrote:

Show 6 quoted lines

> 
> A cherry-picked tree would allow for an easy bisect, since all of the
> intermediary versions would work.  If I somehow knew magical points within
> the other tree I could do some number of merges and the bisect would still
> work.  I suppose I could do the merges one at a time, but it would make the
> history rather verbose.

Why do you want to worry so much about bisecting the merge?

You should basically expect that normally, a merge doesn't cause new bugs in itself. And if it does, the most common case is a fairly obvious mismerge (we've had a number of those in the kernel, but they weren't all that mysterious). So _planning_ for a subtle bisection failure sounds a bit strange and counter-productive.

So don't plan for it, and don't make it a primary issue for your workflow.

Then, *after* you have a merge, and the unlucky thing happens where the merge is actually the thing that introduces the bug, and it's not obvious what the exact interaction is, and bisection didn't help you pinpoint it (because it really was the merge), *that* is when you might then choose to re-do the rebase in a temporary branch, and then bisect that re-linearized history.

So basically:

 - keep the history clean and obvious

 - make it fairly straightforward and don't worry about the unlikely case.

 - don't do something painful just because bad things _can_ happen (they 
   can happen regardless of what you do)

 - because in the unlikely situation that bad things happen, you can 
   always then go back and do things the other way around and pinpoint 
   where the fault is that way.

IOW, let's say that you really do bisect things down to a merge and cannot see what the fault in that merge is, you can literally do

	# create a test-branch with the 'remote' side of the merge
	git checkout -b test-branch merge^2

	# rebase that remote side on top of the local side
	git rebase merge^

and now you've linearized the merge temporarily just to be able to bisect in that temporary branch what the bad interaction is. But once you've bisected it, the temporary branch is again just junk - there's no real value in saving it, because once you know _why_ the bug happened, you're just better off going back to the original history and just fixing it (and documenting the bug through the fix, rather than by addign extra-ugly history).

		Linus