Re: Source reindenting

Le 30/12/2010 11:24, Magnus Hagander a écrit :
> On Thu, Dec 30, 2010 at 11:13, Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:
>> Le 30/12/2010 09:52, Magnus Hagander a écrit :
>>> On Thu, Dec 30, 2010 at 00:45, Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:
>>>> Le 29/12/2010 18:44, Dave Page a écrit :
>>>>> On Wed, Dec 29, 2010 at 5:30 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>>>>> I just did a testrun with astyle to reindent and restyle the code. I
>>>>>> created a rule in Makefile.am per:
>>>>>>
>>>>>> diff --git a/Makefile.am b/Makefile.am
>>>>>> index be6af45..8266f8d 100644
>>>>>> --- a/Makefile.am
>>>>>> +++ b/Makefile.am
>>>>>> @@ -65,3 +65,13 @@ endif
>>>>>> # We need to ensure the help cache is world writeable
>>>>>> install-data-hook:
>>>>>> chmod 0666 $(help_cache)
>>>>>> +
>>>>>> +# Perform astyle cleanup per rules:
>>>>>> +# * -p - insert space around parenthesis
>>>>>> +# * -b - bracket style
>>>>>> +# * -S - indent switches
>>>>>> +# * -s4 - intent with spaces, 4 of them
>>>>>
>>>>> Didn't we say we were going to move to tabs?
>>>>>
>>>>
>>>> Yes. Magnus probably forgot that part when I talked with him on IM this
>>>> morning (well, yesterday morning now).
>>>
>>> Do you also prefer tabs in the end, and just bite the even bigger bullet now?
>>>
>>
>> I prefer spaces. But my initial complaint was the mixing of spaces and
>> tabs. IOW, I don't care what we choose, but I would love that we choose
>> one and keep with it. It helps having a good indentation on $EDITOR.
>>
>> So, as many would prefer tabs, I'm OK with it.
>>
>> So, go for tabs.
>
> There's no "many" :-P Dave prefers tabs, I slightly prefer tabs, you
> prefer spaces.
>
> But the main thing is we need a decision - whichever way :-) So let's
> go with tabs..
>

+1

>>>>>> It's going to cause merge conflicts like hell. but it's going to do
>>>>>> that whenever we run it. So should we just go ahead and run it?
>>>>>
>>>>> Why not? :-)
>>>>>
>>>>
>>>> The only patches not yet commited that I know of are the GSoC projects.
>>>> I know it won't be an issue for the database designer. Could be one for
>>>> your project.
>>>
>>> Yeah, it should only have an effect on modifications to *existing*
>>> files. Obviously, you'll want to run a "make style" over the new files
>>> before they are committed, but it shouldn't cause conflicts.
>>>
>>> Which, btw, is my suggested policy - always run "make style" before
>>> you commit (or at least before you push - but don't do it as a
>>> separate commit, so amend it into an existing commit in case it's done
>>> later). It only takes a couple of seconds over the whole tree... Seems
>>> reasonable?
>>>
>>
>> Seems quite reasonable. I expect we'll miss some, but it'll be easy to fix.
>
> Yes, we should of course also have a "style run" before releases, like
> we have for pgindent on the backend.
>

+1

>> I would like this to be done on master and 1.12 branch, because I work
>> on both.
>
> Yeah, that would make backpatches easier. We don't actually do any
> patching at all on pre-1.12 at this point, do we?
>

Nope. I don't, I won't. I already have enough troubles finding time to
fix 1.12 bugs. If we find a bug on an earlier releases, the only thing I
will do is check if it's also affecting 1.12. And fix it if it does. But
I won't fix the earlier releases.

--
Guillaume
http://www.postgresql.fr
http://dalibo.com