Re: Run pgindent now?

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Run pgindent now?
Date: 2015-05-26 21:13:08
Message-ID: CAC_2qU-z8T24X2eGCwynf6yr-_TkGzXHqsK=gi11hQnk_=vHsw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 26, 2015 at 3:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > Realistically, with merge.conflictstyle = diff3 (why is this not the
> > default?), resolving whitespace conflicts that occur when you try to
> > cherry-pick is typically not very difficult.
>
> Really? The problems I have generally come from places where pgindent
> has changed the line breaks, not just horizontal spacing. I haven't
> seen anything that copes with this, certainly not git.
>

Iif pgindet were easy to run, committers could start complaining if patch
submissions don't abide by pg coding style conventions.

Part of submitting a patch would be making sure that an "pgindent run"
after the patch has been applied is still a no-op... A reviewer could
easily check it, and a committer could easily squash the "pgindent run"
result in if they wanted to be nice to a 1st time submitter...

If every patch were "pgindent clean", then you would never end up with
these huge pgindent commits causing pain...

a.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-05-26 21:19:42 Re: Run pgindent now?
Previous Message Paul Smith 2015-05-26 20:55:59 Re: ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound