On Tue, May 6, 2014 at 08:55:07AM -0400, Bruce Momjian wrote:
> On Sat, May 3, 2014 at 02:20:27PM -0400, Bruce Momjian wrote:
> > I am planning to run pgindent in a few days to prepare for beta. Does
> > anyone have major patches that you are planning to apply soon? If so, I
> > can delay pgind
On Sat, May 3, 2014 at 02:20:27PM -0400, Bruce Momjian wrote:
> I am planning to run pgindent in a few days to prepare for beta. Does
> anyone have major patches that you are planning to apply soon? If so, I
> can delay pgindent until you are done.
>
> This run will also have a tabs-in-commen
I am planning to run pgindent in a few days to prepare for beta. Does
anyone have major patches that you are planning to apply soon? If so, I
can delay pgindent until you are done.
This run will also have a tabs-in-comments removal phase which will also
be run on supported back branches.
--
Andrew Dunstan writes:
> Peter Eisentraut wrote:
>> On Wednesday 10 June 2009 23:54:41 Tom Lane wrote:
>>> At a quick look, I'm not sure that any of these are in code that hasn't
>>> been edited since the 8.3 pgindent run.
>>
>> So what does that mean then? Surely pgindent doesn't keep track of
Peter Eisentraut wrote:
On Wednesday 10 June 2009 23:54:41 Tom Lane wrote:
Peter Eisentraut writes:
I think it usually does that already ...
Um, attached you will find a bunch of counterexamples.
At a quick look, I'm not sure that any of these are in code that has
On Wednesday 10 June 2009 23:54:41 Tom Lane wrote:
> Peter Eisentraut writes:
> >>> I think it usually does that already ...
> >
> > Um, attached you will find a bunch of counterexamples.
>
> At a quick look, I'm not sure that any of these are in code that hasn't
> been edited since the 8.3 pginde
On Thu, Jun 11, 2009 at 2:13 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> I confirmed the aix problem on 4.3.3. Installed the patches and
>> updated postgres 8.4b2 removing the aix hack. Server starts fine:
>
>> $ LOG: could not bind IPv6 socket: Addr family not supported by protocol
>> HINT:
Merlin Moncure writes:
> I confirmed the aix problem on 4.3.3. Installed the patches and
> updated postgres 8.4b2 removing the aix hack. Server starts fine:
> $ LOG: could not bind IPv6 socket: Addr family not supported by protocol
> HINT: Is another postmaster already running on port 5432? If
Alvaro Herrera wrote:
BTW if we had an "official" typedef list that could be used for the
length of a whole major release, we could run pgindent on a regular
basis (say fortnightly or monthly); patch submitters would just need to
run it on their own trees to avoid merge conflicts.
(Hmm, but I'
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> Do we have any TODO items concerning pgindent at this point? Y
>>
>
> Yes, we will make the buildfarm and standalone find-typedefs run from a
> common pieces of code so they are always in sync.
BTW if we had an "official" typedef list that could
Tom Lane wrote:
Do we have any TODO items concerning pgindent at this point? Y
Yes, we will make the buildfarm and standalone find-typedefs run from a
common pieces of code so they are always in sync.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Bruce Momjian writes:
> OK, pgindent run with updated list and applied to CVS HEAD. I eyeballed
> the patch and it looked clean, and it tested successfully. Thanks.
Do we have any TODO items concerning pgindent at this point? You had
mentioned wanting to research its behavior for 'struct foo v
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > Andrew Dunstan wrote:
> >
> >> Bruce Momjian wrote:
> >>
> The consolidated list comes from Windows(mingw) and Linux. My Cygwin
> run broke for some reason, and 'objdump --stabs' doesn't seem to do what
> we need on FB
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
The consolidated list comes from Windows(mingw) and Linux. My Cygwin
run broke for some reason, and 'objdump --stabs' doesn't seem to do what
we need on FBSD, so the output there was empty. If someone knows how to
get
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> >> The consolidated list comes from Windows(mingw) and Linux. My Cygwin
> >> run broke for some reason, and 'objdump --stabs' doesn't seem to do what
> >> we need on FBSD, so the output there was empty. If someone knows how to
> >> get the ty
Andrew Dunstan writes:
> Bruce Momjian wrote:
>> I will check on our Postgres shell server right away.
> OK, so we got that working, and the consolidated list now contains FBSD
> data as well.
Um, let's *go* guys. RC1 wrap is scheduled for 18 hours from now.
That means it is already too late t
Bruce Momjian wrote:
The consolidated list comes from Windows(mingw) and Linux. My Cygwin
run broke for some reason, and 'objdump --stabs' doesn't seem to do what
we need on FBSD, so the output there was empty. If someone knows how to
get the typedefs out via objdump on FBSD would they pleas
Andrew Dunstan wrote:
>
>
> Andrew Dunstan wrote:
> >
> >
> > I am doing runs as requested on various platforms to extract the
> > typedef lists. Linux is done, Windows (mingw) is running, FBSD and
> > Cygwin to come.
> >
> > Results in a few hours. The buildfarm will have a consolidated list
Andrew Dunstan wrote:
I am doing runs as requested on various platforms to extract the
typedef lists. Linux is done, Windows (mingw) is running, FBSD and
Cygwin to come.
Results in a few hours. The buildfarm will have a consolidated list.
The consolidated list comes from Windows(ming
On Wed, Jun 10, 2009 at 9:54 PM, Tom Lane wrote:
> Peter Eisentraut writes:
I think it usually does that already ...
>
>> Um, attached you will find a bunch of counterexamples.
>
> At a quick look, I'm not sure that any of these are in code that hasn't
> been edited since the 8.3 pgindent run
Peter Eisentraut writes:
>>> I think it usually does that already ...
> Um, attached you will find a bunch of counterexamples.
At a quick look, I'm not sure that any of these are in code that hasn't
been edited since the 8.3 pgindent run.
regards, tom lane
--
Sent via
On Wednesday 10 June 2009 22:50:15 Bruce Momjian wrote:
> Tom Lane wrote:
> > Peter Eisentraut writes:
> > > Btw., can you make pgindent remove whitespace at the end of lines?
> >
> > I think it usually does that already ...
>
> Yes.
Um, attached you will find a bunch of counterexamples.
Index:
Tom Lane wrote:
> Greg Stark writes:
> > Out of curiosity how different is the output if we don't pass the
> > typedef list at all? I'm wondering if the formatting differences are
> > things we actually care much about anyways.
>
> It tends to put extra spaces in variable declarations that are us
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > I did a diff, attached, and found some typedefs that don't appear, like
> > PortalData. That is defined in our code as:
> >
> > typedef struct PortalData *Portal;
> >
> > typedef struct PortalData
> > {
> > /* Bookkeep
Tom Lane wrote:
> Peter Eisentraut writes:
> > Btw., can you make pgindent remove whitespace at the end of lines?
>
> I think it usually does that already ...
Yes.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life
Peter Eisentraut writes:
> Btw., can you make pgindent remove whitespace at the end of lines?
I think it usually does that already ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
On Tuesday 09 June 2009 20:21:35 Bruce Momjian wrote:
> It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
> running it at zero-hour GMT tomorrow, meaning five hours from now.
> Any objections?
Btw., can you make pgindent remove whitespace at the end of lines?
--
Sent via pgsql-ha
Greg Stark writes:
> Out of curiosity how different is the output if we don't pass the
> typedef list at all? I'm wondering if the formatting differences are
> things we actually care much about anyways.
It tends to put extra spaces in variable declarations that are using
the typedef. Not sure a
Bruce Momjian wrote:
I did a diff, attached, and found some typedefs that don't appear, like
PortalData. That is defined in our code as:
typedef struct PortalData *Portal;
typedef struct PortalData
{
/* Bookkeeping data */
...
b
Out of curiosity how different is the output if we don't pass the
typedef list at all? I'm wondering if the formatting differences are
things we actually care much about anyways.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > Bruce Momjian writes:
> >
> >> I am unclear why struct pointers are not being formatted properly in
> >> function headers but will research it.
> >>
> >
> > Yeah, if we can fix that directly without adding the names to the
> > typedef list,
Tom Lane wrote:
Bruce Momjian writes:
I am unclear why struct pointers are not being formatted properly in
function headers but will research it.
Yeah, if we can fix that directly without adding the names to the
typedef list, it would be better. But not something to do right now.
Bruce Momjian writes:
>> Have you started the pgindent run yet? I have a patch ready for
>> the cursor stability issue, but will hold off committing if it might
>> create a merge problem for you.
> I am waiting for Andrew to tell me he is ready with updated lists for
> his platforms. His CGI ou
Tom Lane wrote:
> Bruce Momjian writes:
> > I am unclear why struct pointers are not being formatted properly in
> > function headers but will research it.
>
> Yeah, if we can fix that directly without adding the names to the
> typedef list, it would be better. But not something to do right now.
Bruce Momjian writes:
> I am unclear why struct pointers are not being formatted properly in
> function headers but will research it.
Yeah, if we can fix that directly without adding the names to the
typedef list, it would be better. But not something to do right now.
Have you started the pgind
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, I have found the cause of the script error, and it was my fault. A
> > month after we ran pgindent for 8.3 (December 2007), I received this
> > issue from Tom:
>
> > http://archives.postgresql.org/pgsql-hackers/2007-12/msg00800.php
> >> Something I
Bruce Momjian writes:
> OK, I have found the cause of the script error, and it was my fault. A
> month after we ran pgindent for 8.3 (December 2007), I received this
> issue from Tom:
> http://archives.postgresql.org/pgsql-hackers/2007-12/msg00800.php
>> Something I noticed the other day is that
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> >
> > Good point. Here is another diff I need you to make to the pl file.
> >
>
> Done. Linux run under way.
>
> > If you want to make your pl file the official version and replace the
> > shell script in CVS, that is fine with me. Do you
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > I saw a few odd things. Most importantly, it seems 'stat' was
> > > introduced as a typedef on _both_ lists, yielding weird changes like:
> >
> > The standard headers do define "struct stat". I wonder whether the
> > objdump
Bruce Momjian wrote:
Good point. Here is another diff I need you to make to the pl file.
Done. Linux run under way.
If you want to make your pl file the official version and replace the
shell script in CVS, that is fine with me. Do you want me to do that?
It needs to be done in
Andrew Dunstan wrote:
> Well, sometimes I build it and they don't come ;-).
>
> I don't have every platform under the sun that I can run this on,
> although I do now have an FBSD VM that I didn't have when I worked on
> this previously. If you're actually going to use it I'll set it up as a
> b
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
OK, Andrew, would you use the find_typedef file that is in CVS HEAD and
run that. I think that will fix our problem and then I can use the
buildfarm version. How often does that run and does it pull the script
from CVS
Bruce Momjian writes:
> Tom Lane wrote:
>> We don't have a lot of time for research. Maybe the best thing is to
>> just manually remove stat from the typedef list (along with anything
>> else that clearly shouldn't be there)?
> I agree we are running out of time so I will be running pgindent in
Tom Lane wrote:
> Bruce Momjian writes:
> > I saw a few odd things. Most importantly, it seems 'stat' was
> > introduced as a typedef on _both_ lists, yielding weird changes like:
>
> The standard headers do define "struct stat". I wonder whether the
> objdump kluge we are using is unable to di
Simon Riggs writes:
> On Tue, 2009-06-09 at 13:21 -0400, Bruce Momjian wrote:
>> It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
>> running it at zero-hour GMT tomorrow, meaning five hours from now.
> Why don't we do this automatically after each individual commit?
It's not ve
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > OK, Andrew, would you use the find_typedef file that is in CVS HEAD and
> > run that. I think that will fix our problem and then I can use the
> > buildfarm version. How often does that run and does it pull the script
> > from CVS HEAD?
> >
On Tue, 2009-06-09 at 13:21 -0400, Bruce Momjian wrote:
> It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
> running it at zero-hour GMT tomorrow, meaning five hours from now.
> Any objections?
Why don't we do this automatically after each individual commit? That
way each commi
Bruce Momjian wrote:
OK, Andrew, would you use the find_typedef file that is in CVS HEAD and
run that. I think that will fix our problem and then I can use the
buildfarm version. How often does that run and does it pull the script
from CVS HEAD?
The buildfarm does not run the find-type
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> We don't have a lot of time for research. Maybe the best thing is to
> >> just manually remove stat from the typedef list (along with anything
> >> else that clearly shouldn't be there)?
>
> > Do you want me to just run with my old
Bruce Momjian writes:
> Tom Lane wrote:
>> We don't have a lot of time for research. Maybe the best thing is to
>> just manually remove stat from the typedef list (along with anything
>> else that clearly shouldn't be there)?
> Do you want me to just run with my old typedef list now and apply it
Tom Lane wrote:
> Bruce Momjian writes:
> > I saw a few odd things. Most importantly, it seems 'stat' was
> > introduced as a typedef on _both_ lists, yielding weird changes like:
>
> The standard headers do define "struct stat". I wonder whether the
> objdump kluge we are using is unable to di
Tom Lane wrote:
> Bruce Momjian writes:
> > I saw a few odd things. Most importantly, it seems 'stat' was
> > introduced as a typedef on _both_ lists, yielding weird changes like:
>
> The standard headers do define "struct stat". I wonder whether the
> objdump kluge we are using is unable to di
Bruce Momjian writes:
> I saw a few odd things. Most importantly, it seems 'stat' was
> introduced as a typedef on _both_ lists, yielding weird changes like:
The standard headers do define "struct stat". I wonder whether the
objdump kluge we are using is unable to distinguish typedef names
from
Bruce Momjian wrote:
> The typedef is coming from the indicated line, and from
> /usr/include/sys/stat.h, where there is no typedef for stat. Obviously
> Linux or the buildfarm is finding the same issue, but I have no idea
> why.
>
> My only guess right now is that we are linking postgres differe
Bruce Momjian wrote:
> It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
> running it at zero-hour GMT tomorrow, meaning five hours from now.
> Any objections?
I ran pgindent and was concerned enough about the results so I am
posting here rather than applying any changes. I used
It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
running it at zero-hour GMT tomorrow, meaning five hours from now.
Any objections?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive,
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > It is about time to run pgindent before we enter beta testing. Is this
> > weekend good for everyone?
>
> I think we should wait until the fate of the GUC patch is determined
> --- if we want to apply it, a pgindent run is going to c
Bruce Momjian <[EMAIL PROTECTED]> writes:
> It is about time to run pgindent before we enter beta testing. Is this
> weekend good for everyone?
I think we should wait until the fate of the GUC patch is determined
--- if we want to apply it, a pgindent run is going to cause some
unnecessary work,
It is about time to run pgindent before we enter beta testing. Is this
weekend good for everyone?
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
I have completed the pgindent run for 8.0.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 1907
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Should I run pgindent tomorrow in preparation for final release?
>
> I've been intending to mention that you should do that, and the
> copyright year bump bit too, pretty soon. We aren't going to
> have a lower level of pending patch
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Should I run pgindent tomorrow in preparation for final release?
I've been intending to mention that you should do that, and the
copyright year bump bit too, pretty soon. We aren't going to
have a lower level of pending patches later than we do now.
To
Should I run pgindent tomorrow in preparation for final release?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Squ
I just committed another pgindent run with updated typedefs.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square,
I am going to run pgindent in 8 hours, in preparation for 7.4 beta.
I am completing the list of release changes and should be done in 8-12
hours.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard d
All done. Thanks guys.
> I recently ran pgindent, which had some fixes from the 7.1 version that
> were suggested by Tom Lane. Unfortunately, some of my fixes had bad
> side effects, and I would like to run pgindent again to correct those
> problems Tom has found.
>
> The changes should be mi
I recently ran pgindent, which had some fixes from the 7.1 version that
were suggested by Tom Lane. Unfortunately, some of my fixes had bad
side effects, and I would like to run pgindent again to correct those
problems Tom has found.
The changes should be minimal, mostly related to indenting of
> On Thu, 25 Oct 2001, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > > If we aren'g putting that Packaging stuff into v7.2, can we get it into
> > > beta as contrib also? Before I do the first packagingof the beta?
> >
> > Uh ... what?
> >
> > I just meant to wait a li
> On Thu, 25 Oct 2001, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > > If we aren'g putting that Packaging stuff into v7.2, can we get it into
> > > beta as contrib also? Before I do the first packagingof the beta?
> >
> > Uh ... what?
> >
> > I just meant to wait a li
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> If we aren'g putting that Packaging stuff into v7.2, can we get it into
> beta as contrib also? Before I do the first packagingof the beta?
Uh ... what?
I just meant to wait a little bit on wrapping the tarball while I make
this last(?) catalog u
On Thu, 25 Oct 2001, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > If we aren'g putting that Packaging stuff into v7.2, can we get it into
> > beta as contrib also? Before I do the first packagingof the beta?
>
> Uh ... what?
>
> I just meant to wait a little bit on wrappi
D'oh ...
Okay, will hold off on packaging, but have already tag'd it ...
If we aren'g putting that Packaging stuff into v7.2, can we get it into
beta as contrib also? Before I do the first packagingof the beta?
On Thu, 25 Oct 2001, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have run pgindent on the C files and run pgjindent on the jdbc files
> as requested by the jdbc list. You can package up beta now. I will
> update the HISTORY file tomorrow with recent changes.
Please hold on that packaging until I add the int2<->in
I have run pgindent on the C files and run pgjindent on the jdbc files
as requested by the jdbc list. You can package up beta now. I will
update the HISTORY file tomorrow with recent changes.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
OK, I see my email got through to the list. Running pgindent now and
will commit changes.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your
I have been asked to run pgindent in preparation for beta starting
tomorrow. In this run, I will also reformat the jdbc files as agreed to
by the jdbc list. I don't have much time to wait before starting the
pgindent run. I hope people don't have outstanding patches sitting
around.
--
Bruc
Christopher Sawtell <[EMAIL PROTECTED]> writes:
> Can't the contributors themselves run pgindent on the files which they
> have changed _just_ before creating the patch which is to be contributed?
That would require everyone to have a working copy of BSD indent (gnu
indent does not behave the s
Greetings,
I have been following along with the thread and would just like to say a
few paragraphs.
Can't the contributors themselves run pgindent on the files which they
have changed _just_ before creating the patch which is to be contributed?
Thus, patching a "pure" pgindented file from
> Bruce Momjian wrote:
> >
> > You don't notice the value of pgindent until you have some code that
> > hasn't been run through it. For example, ODBC was not run through until
> > this release, and I had a terrible time trying to understand the code
> > because it didn't _look_ like the rest of
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Please tell me how to prevent pgindent from changing
> comments.
Put dashes at the start and end of the comment block, eg
/*--
* comment here
*--
*/
I'm not sure exactly how many dashes are needed ---
Bruce Momjian wrote:
>
> You don't notice the value of pgindent until you have some code that
> hasn't been run through it. For example, ODBC was not run through until
> this release, and I had a terrible time trying to understand the code
> because it didn't _look_ like the rest of the code. No
> * Bruce Momjian <[EMAIL PROTECTED]> [010322 07:12] wrote:
> > > It seems that you guys are dead set on using this pgindent tool,
> > > this is cool, we'd probably use some indentation tool on the FreeBSD
> > > sources if there was one that met our code style(9) guidelines.
> >
> > I would liken
* Bruce Momjian <[EMAIL PROTECTED]> [010322 07:12] wrote:
> > It seems that you guys are dead set on using this pgindent tool,
> > this is cool, we'd probably use some indentation tool on the FreeBSD
> > sources if there was one that met our code style(9) guidelines.
>
> I would liken running pgi
> > You don't notice the value of pgindent until you have some code that
> > hasn't been run through it. For example, ODBC was not run through until
> > this release, and I had a terrible time trying to understand the code
> > because it didn't _look_ like the rest of the code. Now that pgindent
* Bruce Momjian <[EMAIL PROTECTED]> [010322 06:49] wrote:
> > * Bruce Momjian <[EMAIL PROTECTED]> [010321 21:14] wrote:
> > > > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > > > > and most times, those have to be merged into the source tree due to
> > > > > extensive changes anyway ... maybe w
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think early beta is the time to
> > do this next time. That has the fewest patches crossing over time.
>
> That would work too, particularly if you give people a few days' notice.
> ("Get your patches in now, or expect to have to reformat...")
Y
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think early beta is the time to
> do this next time. That has the fewest patches crossing over time.
That would work too, particularly if you give people a few days' notice.
("Get your patches in now, or expect to have to reformat...")
> > Hey, I am open to whatever people want to do. Just remember that we
> > accumulate lots of patches/development during the slow time before
> > development, and those patches become harder to apply. Peter E has some
> > already.
>
> This argument seems irrelevant when given the choice of bef
Bruce Momjian writes:
> > >> Are there any severely mis-indented files?
> >
> > There are some new contrib modules that are nowhere close to our
> > indent conventions; also a good deal of foreign-key-related stuff
> > in the parser that needs to be cleaned up. So we should run it.
> >
> > I've
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > cvs annotate is a really, really handy tool, unfortunetly these
> > indent runs remove this very useful tool as well as do a major job
> > of obfuscating the code changes.
> >>
> >> I think this is a
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> cvs annotate is a really, really handy tool, unfortunetly these
> indent runs remove this very useful tool as well as do a major job
> of obfuscating the code changes.
>>
>> I think this is a good reason f
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > cvs annotate is a really, really handy tool, unfortunetly these
> > indent runs remove this very useful tool as well as do a major job
> > of obfuscating the code changes.
>
> I think this is a good reason for *not* applying pgindent on an
> incr
> It seems that you guys are dead set on using this pgindent tool,
> this is cool, we'd probably use some indentation tool on the FreeBSD
> sources if there was one that met our code style(9) guidelines.
I would liken running pgindent to having a nice looking store or
website. No one is going to
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> cvs annotate is a really, really handy tool, unfortunetly these
> indent runs remove this very useful tool as well as do a major job
> of obfuscating the code changes.
I think this is a good reason for *not* applying pgindent on an
incremental basis,
> * Bruce Momjian <[EMAIL PROTECTED]> [010321 21:14] wrote:
> > > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > > > and most times, those have to be merged into the source tree due to
> > > > extensive changes anyway ... maybe we should just get rid of the use of
> > > > pgindent altogether?
>
* Bruce Momjian <[EMAIL PROTECTED]> [010321 21:14] wrote:
> > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > > and most times, those have to be merged into the source tree due to
> > > extensive changes anyway ... maybe we should just get rid of the use of
> > > pgindent altogether?
> >
> > I
> > The problem is that the small ones don't apply cleanly if they don't
> > match the indenting in the source.
>
> but ... if they are small, manually merging isn't that big of a deal ...
> and if anyone else has been working in that code since release, there is a
> chance it won't mergef cleanl
On Thu, 22 Mar 2001, Bruce Momjian wrote:
> > > > and most times, those have to be merged into the source tree due to
> > > > extensive changes anyway ... maybe we should just get rid of the use of
> > > > pgindent altogether? its not something that I've ever seen required on
> > > > other proje
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > and most times, those have to be merged into the source tree due to
> > extensive changes anyway ... maybe we should just get rid of the use of
> > pgindent altogether?
>
> I think pgindent is a good thing; the style of different parts of the
>
> > > and most times, those have to be merged into the source tree due to
> > > extensive changes anyway ... maybe we should just get rid of the use of
> > > pgindent altogether? its not something that I've ever seen required on
> > > other projects I've worked on ... in general, most projects se
1 - 100 of 125 matches
Mail list logo
