Re: Should we have a commit size guideline?

[Paul Eggert <eggert@cs.ucla.edu>]

John Wiegley wrote:
> The best of both worlds should be: A commit series from a feature branch,
> merged into the target branch.

I generally find it a waste of time to split a small or medium-sized patch into 
the maximum number of patchlets that can be applied one at a time without 
breaking the build. Of course it's not OK to amalgamate unrelated patches 
together into one huge commit. Still, for a relatively small and coherent patch 
such as the one that prompted this thread, we've already wasted more time 
discussing how to split it up than any possible benefit that would have accrued 
by splitting it.

That being said, it is annoying when part of a patch consists entirely of 
changing tabs to spaces or vice versa, as this one did, as this wastes the time 
of reviewers for no good reason. I wish we'd stop doing that. This particular 
botch was undoubtedly caused by the line "(emacs-lisp-mode . ((indent-tabs-mode 
. nil)))" in .dir-locals.el, which was recently inserted in the (vain) attempt 
to get rid of all the tabs in .el source files, and we should probably remove 
that line as in practice it really causes more trouble than it's worth.