Jeffrey Hutzelman wrote:
The guiding principal I've often seen and used is typically expressed as "one change per patch; one patch per change". That is, the fundamental property of interest is not size, but the number of logically separate changes which are part of the same patch. The correct number is always exactly one.
I agree. I haven't always done that myself, but it's a good idea.
There is, of course, some grey here. Some projects prefer to get things like reindent or warning elimination in larger chunks, arguing that such changes are related even if not interdependent, and are actually easier to merge and review in large batches. Alan has clearly indicated his preference to be the opposite, and around here, he gets to decide.
:) I've always wondered why git doesn't have advisory information for patches. Like "created by running 'indent options'". That way when a merge fails, it can try to run indent on the branch to be merged, and *then* merge the patch.
Similarly, it may often be possible to take a large set of changes to add a complex new feature, and break it down into smaller parts, each building on the last. Such things are often easier to review and test, which is always a good thing.
And should likely go on a development branch, too. (i.e. no fast-forward merge.) That way you have the best of both worlds: "diff master branch" to get the whole feature, and then a set of smaller patches which make merges easier. If it's OK with you, I'll take your email with minor edits && put it on git.freeradius.org as "how to do patches". :) Alan DeKok.