aland at deployingradius.com
Tue Feb 2 07:57:00 CET 2010
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". :)
More information about the Freeradius-Devel