Re: Should we have a commit size guideline? (was: builds are getting slower?)

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 15 Dec 2015 13:48:28 +0000
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> > This is a very, very large commit.  It should have been split into
> > multiple commits addressing separate issues.
> 
> When commiting changes, I usually group them into the smallest
> possible commits while still leaving everything in a consistent state
> (i.e., not defining a function that's only used in later commits, not
> changing a function without making the necessary changes in other
> places that call this function). I find that this helps with both
> git-bisect and git-revert.
> 
> If we have a different policy (maybe we should) I'm happy to adhere.

I generally prefer to see the commits in one go, rather than split.
It makes it easier for me to review it.