On Mon, Apr 25, 2011 at 4:03 PM, Greg Stark <gsstark@mit.edu> wrote:
> On Mon, Apr 25, 2011 at 3:45 PM, Tom Lane <tgl@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