On Wed, 18 Oct 2006 03:28:30 +0200, Jakub Narebski wrote: > > 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
Attachment:
pgp3E9tmnxWrS.pgp
Description: PGP signature