Skip site navigation (1) Skip section navigation (2)

Re: Source reindenting

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: Guillaume Lelarge <guillaume(at)lelarge(dot)info>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Source reindenting
Date: 2010-12-31 09:57:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
On Fri, Dec 31, 2010 at 02:39, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> On Thu, Dec 30, 2010 at 10:02 AM, Magnus Hagander <magnus(at)hagander(dot)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).

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

In response to

pgadmin-hackers by date

Next:From: Magnus HaganderDate: 2010-12-31 11:43:52
Subject: Re: Support for unlogged tables
Previous:From: Magnus HaganderDate: 2010-12-31 09:54:22
Subject: Re:

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group