On Sun, Nov 22, 2015 at 03:09:39PM -0600 I heard the voice of David Champion, and lo! it spake thus: > > +1 to both. Commenting the code and reformatting the code are > separate tasks, and should be committed separately. Comments are > reviewable, and I can support that without argument. Reformatting > will impose a lot of catch-up burden on a lot of people in a short > time. That is something to approach carefully. An tool would make > this more predictable and more auditable.
As a data point, I did this last year with ctwm[0], which is an even older and cruftier codebase than mutt (it was only in the last decade or so that it was de-K&R'd, for instance). I wound up choosing Artistic Style, and we worked up a config everybody could live with. With careful execution, it wasn't too hard to handle doing it reasonably cleanly against outstanding branches; a similar dance can work with plain patches as well. The process went something like: 1) Commit a revision with the tool config and a makefile target (could use a sh script or whatever) to run it. Call this rev 123. 2) Run the target. 3) Commit the reindented code. Call this rev 124. Now, anybody with an outstanding branch could merge up to 123 like normal, dealing with any conflicts as necessary. Then do the 'make indent' in their local branch, and commit those results. Then merge up to 124; this will generally cause a lot of conflicts, but they should all be spurious, because there are no content changes between 123..124, only the results of the 'make indent', which are stable. So you throw away the actual file changes and commit that merge, which means your local commit has no file changes from the previous (after you ran the local indent), but now you're in sync. A similar thing should work for patches. Check out 123, apply your existing patch (fixing/testing as necessary), run the 'make indent', and diff that result against 124. Now you have a patch that should apply going forward. It's generally pretty easy to test before/afters; since code formatting shouldn't change the generated code, comparing the .o files should show no changes. Main false positive there is stuff that embeds line numbers like assert(), so you may have to build with NDEBUG or some other options to get rid of that noise. [0] http://article.gmane.org/gmane.comp.window-managers.ctwm/1445 -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
