Re: branching for 9.2devel

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: branching for 9.2devel
Дата
Msg-id 2095.1304482791@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: branching for 9.2devel  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: branching for 9.2devel
Re: branching for 9.2devel
Список pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 05/03/2011 09:53 PM, David Blewett wrote:
>> On Tue, May 3, 2011 at 9:51 PM, David Blewett<david@dawninglight.net>  wrote:
>> That should read: ... but maybe it'd be easiest to take it a step
>> further and have an additional, automatically created patch file that
>> is run through pgindent when a patch is added to the commitfest app.

> You can't indent patches, only patched files. And that's the problem 
> with this happy scheme. For it to work at all sanely we'd need to keep 
> the committed code that the patch is to be applied against strictly 
> pgindent clean, presumably via some automated process such as a commit 
> hook. That's been suggested in the past, but hasn't met with universal 
> approval, IIRC.

Another point here is that insisting on perfectly indented results can
often be counterproductive for the readability of the patch.  Consider
a patch that does

+    if (new-condition)
+    {
+        do something new;
+    }
+    else
+    {large existing block of code;
+    }

Now, obviously, the large existing block of code is going to have to be
pushed one tab stop to the right eventually.  But it is no service to
the readability of the patch to insist that that be part of the
submitted diff.  It's much better if that happens separately.

Mind you, I've read more than enough horribly-formatted patches to wish
that we could do something about this.  But I doubt that a mechanical
reformatting pass before reviewing will be a net plus.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: branching for 9.2devel
Следующее
От: "Johann 'Myrkraverk' Oskarsson"
Дата:
Сообщение: Re: DLL export with mingw-w64: currently a no-op