Re: Source reindenting - Mailing list pgadmin-hackers
From | Guillaume Lelarge |
---|---|
Subject | Re: Source reindenting |
Date | |
Msg-id | 4D1CC25A.4020107@lelarge.info Whole thread Raw |
In response to | Re: Source reindenting (Magnus Hagander <magnus@hagander.net>) |
Responses |
Re: Source reindenting
|
List | pgadmin-hackers |
Le 30/12/2010 11:24, Magnus Hagander a écrit : > On Thu, Dec 30, 2010 at 11:13, Guillaume Lelarge <guillaume@lelarge.info> wrote: >> Le 30/12/2010 09:52, Magnus Hagander a écrit : >>> On Thu, Dec 30, 2010 at 00:45, Guillaume Lelarge <guillaume@lelarge.info> wrote: >>>> Le 29/12/2010 18:44, Dave Page a écrit : >>>>> On Wed, Dec 29, 2010 at 5:30 PM, Magnus Hagander <magnus@hagander.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
pgadmin-hackers by date: