On Sun, Jul 4, 2010 at 6:56 PM, Georg Brandl firstname.lastname@example.org wrote:
Am 04.07.2010 17:26, schrieb Antoine Pitrou:
On Sun, 04 Jul 2010 15:46:53 +0200 Dirkjan Ochtman email@example.com 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.
Exactly, so one bugfix or one feature comes in a single changeset that contains ideally the code change + the doc change + the tests.
Like Thomas has suggested, I'll start a "how to contribute" wiki page with the best practices, and give the url here so everyone can contribute/correct it.