[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should we have a commit size guideline?

From: Paul Eggert
Subject: Re: Should we have a commit size guideline?
Date: Tue, 15 Dec 2015 16:13:48 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]