Georg Brandl writes:
Am 04.07.2010 17:26, schrieb Antoine Pitrou:
On Sun, 04 Jul 2010 15:46:53 +0200 Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
Fourth, one-patch-per-issue is too restrictive. Small commits are useful because they're way easier to review. Concatenate several small commits leading up to a single issue fix into a single patch and it gets much harder to read.
I don't agree with that. The commits obviously won't be independent because they will be motivated by each other (or even dependent on each other), therefore you have to remember what the other commits do when reviewing one of them. What's more, when reading "hg log" months or years later, it is hard to make sense of a single commit because you don't really know what issue it was meant to contribute to fix.
I know that's how Mercurial devs do things, but I don't really like it.
I think the best of both worlds is to encourage contributors to send more complicated patches in a series of easy-to-review steps, but when committing to Python, make one changeset out of them.
I don't see how this addresses Antoine's problem of connecting commits to issues at all. Some ways to address it are (1) require issue numbers in log messages, if there is an applicable issue (for non-committers, there should be a patch issue on the tracker, right?) and (2) require that the commits addressing a single issue be done on a single separate branch, then merged (which doesn't connect issues to commits, but does connect a series of commits). I don't really see why commits should take place in a lump, either. That makes bisecting less accurate, for one thing. Nor does it help with review; the review is already done by the time the commit takes place, no? OTOH, people who have a specific interest and want to review ex post are often going to want the bite-size patches, just as the original reviewer did, no?