Commit processes

[Alan DeKok]

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.