On Wed, 18 Oct 2006 03:28:30 +0200, Jakub Narebski wrote:
quoted text
>
> Isn't it easier to review than "bundle", aka. mega-patch?

There are even more important reasons to prefer a series of
micro-commits over a mega-patch than just ease of merging.

In the cairo project, I've often reviewed a single patch and said:

	"This all looks like perfectly good code and I'd be happy to
	have it all in the tree. But please rebuild this as a series
	of independent patches (perhaps along the lines of a, b, c,
	...)"

I do that not just to make the history "look nice" but because code
history is something we _use_ a lot and separate commits for separate
actions just make the history so much more usable.

We have great tools like bisect to identify commits that introduce
bugs. I know that I'd be delighted to see bisect comes back pointing
at some minimal commit as causing a bug, (which would make finding the
bug so much easier).

But it's also been my experience that the largest commits are also the
most likely to be the things returned by bisect. Big commits really do
introduce bugs more frequently than small commits.

Finally, if someone had gone through the useful work to create small,
independent changes, (and likely finding and fixing bugs in the
process), what a horrible shame it would be to throw away that work
and merge it as a single patch, (welcome to the pain of CVS branch
merging).

Now, I do admit that it is often useful to take the overall view of a
patch series being submitted. This is often the case when a patch
series is in some sub-module of the code for which I don't have as
much direct involvement. In cases like that I will often do review
only of the diff between the tips of the mainline and the branch of
interest, (or if I trust the maintainer enough, perhaps just the
diffstat between the two). But I'm still very glad that what lands in
the history is the series of independent changes, and not one mega
commit.

-Carl