On Tue, Aug 19, 2014 at 10:52 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
That's debatable. Given a set of closely related patches, I often find it more efficient to review them all at one go rather than one at a time. In this case it also happened to be easier for me to generate and perhaps I'm biased by that, but there it is.
I understand that they're easier to generate; I often generate mine in one go, and then split them out with git add -i.
More generally, I would rather avoid the bureaucratic overhead of splitting patches unless there's a significant win in doing so. Many patches that I write could technically be split into dozens of niggling little independent changes, but the overall utility of doing it that way would be negative -- certainly for me, and I expect even when reviewer labor is taken into account.
I've always found that review time on single-purpose refactoring patches is exponentially less than the review time on the combined patch, and I also don't see much overhead in doing it that way. But I guess it depends on what tools you use. Cheers, Dirkjan