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.
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 |