[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should we have a commit size guideline? (was: builds are getting slo
From: |
Eli Zaretskii |
Subject: |
Re: Should we have a commit size guideline? (was: builds are getting slower?) |
Date: |
Tue, 15 Dec 2015 18:16:36 +0200 |
> Date: Tue, 15 Dec 2015 13:48:28 +0000
> From: Artur Malabarba <address@hidden>
> Cc: emacs-devel <address@hidden>
>
> > 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.