Обсуждение: Source reindenting
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
+# * -k3 - align pointer or reference operators
+# Also add the -n to make it not save .orig files (we have git for that)
+style:
+ astyle -n -p -b -S -s4 -k3 `find . -name "*.cpp" -o -name
"*.h" | egrep -v "(wx-build|xrcDialogs|pgscript/test)"`
diffstat for the whole thing is:
631 files changed, 36590 insertions(+), 30757 deletions(-)
And yes, it is smart enough not to edit things if I run it again - phew.
I've pushed a branch to github for your reviewing pleasure:
https://github.com/mhagander/pgadmin3/compare/master...reindent
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?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
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? > 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? :-) -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Dec 29, 2010 at 18:44, Dave Page <dpage@pgadmin.org> wrote: > 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? I went by Guillaume's statement, which was that spaces was the last we said but there was some discussion about tabs that didn't really go anyway. I'm all for tabs on the basis that pg uses it. However, the diff is a lot bigger: 631 files changed, 87029 insertions(+), 81196 deletions(-) which indicates that we are using spaces a lot more today. >> 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? :-) Because we haven't decided on tabs vs spaces yet? ;) Anyway, when that's done... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Wed, Dec 29, 2010 at 6:16 PM, Magnus Hagander <magnus@hagander.net> wrote: > On Wed, Dec 29, 2010 at 18:44, Dave Page <dpage@pgadmin.org> wrote: >> 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? > > I went by Guillaume's statement, which was that spaces was the last we > said but there was some discussion about tabs that didn't really go > anyway. > > I'm all for tabs on the basis that pg uses it. However, the diff is a > lot bigger: > 631 files changed, 87029 insertions(+), 81196 deletions(-) > > which indicates that we are using spaces a lot more today. > > >>> 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? :-) > > Because we haven't decided on tabs vs spaces yet? ;) Anyway, when that's done... Well, yeah. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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). >> 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. -- Guillaume http://www.postgresql.fr http://dalibo.com
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? >>> 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? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On 12/30/10, Magnus Hagander <magnus@hagander.net> wrote: > 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? > > >>>> 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? > Not unless you add a VC++ build step to do it too... -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Dec 30, 2010 at 10:38, Dave Page <dpage@pgadmin.org> wrote: > On 12/30/10, Magnus Hagander <magnus@hagander.net> wrote: >> 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? >> >> >>>>> 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? >> > > Not unless you add a VC++ build step to do it too... Ah, wasn't aware you actually committed from Windows. Thought you worked kind of like I do for the pg backend work which is do all windows stuff on a separate branch and then fold it into my local git repository and clean it up on linux before committing anything (which is where I clean up things like linebreaks and indention). There's an astyle package for windows. It's officially maintained. While I don't think it would be too easy to create a VS build step for it, it would probably be easy to create a .BAT file you could run prior to commit, if that would be enough? (Do you do your actual git work from inside VS as well? Daring!) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
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. >>>> 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. I would like this to be done on master and 1.12 branch, because I work on both. -- Guillaume http://www.postgresql.fr http://dalibo.com
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.. >>>>> 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. > 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? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
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
On Thu, Dec 30, 2010 at 10:02 AM, Magnus Hagander <magnus@hagander.net> wrote: >> Not unless you add a VC++ build step to do it too... > > Ah, wasn't aware you actually committed from Windows. Thought you > worked kind of like I do for the pg backend work which is do all > windows stuff on a separate branch and then fold it into my local git > repository and clean it up on linux before committing anything (which > is where I clean up things like linebreaks and indention). I keep my Windows and other repos entirely independent of one another. Typically, I do commit new work from Windows though, as that's where I mostly develop, and patches from OSX, as that's more convenient for testing other people's work. > There's an astyle package for windows. It's officially maintained. > While I don't think it would be too easy to create a VS build step for > it, it would probably be easy to create a .BAT file you could run > prior to commit, if that would be enough? (Do you do your actual git > work from inside VS as well? Daring!) I don't use git from inside VC++ - but if you want astyle to be run prior to every commit, then I'll want a batch file or something that's easy to remember to call (note, if it's a batch file, it's easy to add as a pre-build step - though it may be annoying if it changes anything). Or, we could just do it the PostgreSQL way - try to get it right throughout the cycle, and then have a pgindent run prior to release to be sure. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Dec 31, 2010 at 02:39, Dave Page <dpage@pgadmin.org> wrote: > On Thu, Dec 30, 2010 at 10:02 AM, Magnus Hagander <magnus@hagander.net> wrote: >>> Not unless you add a VC++ build step to do it too... >> >> Ah, wasn't aware you actually committed from Windows. Thought you >> worked kind of like I do for the pg backend work which is do all >> windows stuff on a separate branch and then fold it into my local git >> repository and clean it up on linux before committing anything (which >> is where I clean up things like linebreaks and indention). > > I keep my Windows and other repos entirely independent of one another. > Typically, I do commit new work from Windows though, as that's where I > mostly develop, and patches from OSX, as that's more convenient for > testing other people's work. Ok. >> There's an astyle package for windows. It's officially maintained. >> While I don't think it would be too easy to create a VS build step for >> it, it would probably be easy to create a .BAT file you could run >> prior to commit, if that would be enough? (Do you do your actual git >> work from inside VS as well? Daring!) > > I don't use git from inside VC++ - but if you want astyle to be run > prior to every commit, then I'll want a batch file or something that's > easy to remember to call (note, if it's a batch file, it's easy to add > as a pre-build step - though it may be annoying if it changes > anything). I'm sure you're capable of writing such a batch file, since it's a single line command on unix... And I agree it shouldn't be run as a pre-build step, since that might cause rebuilds. You want it pre-*commit*. And it shouldn't be automated, it should be run-on-need. > Or, we could just do it the PostgreSQL way - try to get it right > throughout the cycle, and then have a pgindent run prior to release to > be sure. I would suggest a combination - run it before commit when possible, but then also have a run prior to release to clean up what was missed. Yes, that differs from what you said in that it's not just "try to get it right", it's "try to remember to run the tool" :-) But we're definitely going to forget to run the tool now and then, so the cleanup step is still required. But the less stuff that goes in the cleanup step, the less likely that you'll get conflicts for people. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Thursday, December 30, 2010 6:33:14 PM UTC+1, Guillaume Lelarge wrote: > Le 30/12/2010 11:24, Magnus Hagander a �crit : > > On Thu, Dec 30, 2010 at 11:13, Guillaume Lelarge <guil...@lelarge.info> wrote: > >> Le 30/12/2010 09:52, Magnus Hagander a �crit : (...) > >>> 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 I am happy you made it tabs as I, too, prefer tabs over spaces. Not that I've done a lot of coding here. :) Regards Erwin