On Mon, Apr 25, 2011 at 4:03 PM, Greg Stark <gsst...@mit.edu> wrote: > On Mon, Apr 25, 2011 at 3:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> One small issue that would have to be resolved before branching is >> whether and when to do a "final" pgindent run for 9.1. Seems like the >> alternatives would be: >> > > If the tools become easy to run is it possible we cold get to the > point where we do an indent run on every commit? This wold require a > stable list of system symbols plus the tool would need to add any new > symbols added by the patch. As long as the tool produced consistent > output I don't see that it would produce the spurious merge conflicts > we've been afraid of in the past. Those would only occur if a patch > went in without pgindent being run, someone developed a patch against > that tree, then pgindent was run before merging that patch. As long as > it's run on every patch on commit it shouldn't cause those problems > since nobody could use a non-pgindented code as their base. > > Personally I've never really liked the pgindent run. White-space > always seemed like the least interesting of the code style issues, > none of which seemed terribly important compared to the more important > things like staying warning-clean and defensive coding rules. But if > we're going to do it letting things diverge for a whole release and > then running it once a year seems the worst of both worlds.
+1 to get rid of the pgindent run I'd rather have an automatic checker telling me I need to check my commits than to ignore any weirdness for 6 months and then fix everything at once. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
