Re: Cherry picking instead of merges.

[Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>]

On Thu, 3 Jul 2008, David Brown wrote:
> 
> 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
--
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