Re: Lessons from commit fest - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Lessons from commit fest
Date
Msg-id 200804162009.m3GK9Rr06344@momjian.us
Whole thread Raw
In response to Re: Lessons from commit fest  (Chris Browne <cbbrowne@acm.org>)
List pgsql-hackers
Chris Browne wrote:
> >> Would it be a terrible idea to...
> >> 
> >> - Draw the indent code from NetBSD into src/tools/pgindent
> >> - Build it _in place_ inside the code tree (e.g. - don't assume 
> >>   it will get installed in /usr/local/bin)
> >> - Thus have the ability to run it in place?
> >
> > Yes, but it bloats our code and people still need to generate the
> > typedefs and follow the instructions.  The other problem is if they run
> > it on a file they have modified, it is going to adjust places they
> > didn't touch, thereby making the patch harder to review.
> 
> The bloat is 154K, on a project with something around 260MB of code.
> I don't think this is a particlarly material degree of bloat.

You mean 37kb vs 13MB, right?  That is the tarball sizes I see.

> If we ran pgindent really frequently, there would admittedly be the
> difference that there would be a lot of little cases of
> changes-from-pgindent being committed along the way, but [1] might it
> not be cheaper to accept that cost, with the concomittant benefit that
> you could tell patchers "Hey, run pgindent before submitting that
> patch, and that'll clean up a number of of the issues."  Yes, it
> doesn't address code changes like typedef generation, but that never
> was an argument against running pgindent...

That is much a more radical use of pgindent than it has had in the past
but it is certainly possible.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: How to submit a patch
Next
From: Bruce Momjian
Date:
Subject: Re: How to submit a patch