Re: run pgindent on a regular basis / scripted manner - Mailing list pgsql-hackers

From Jelte Fennema
Subject Re: run pgindent on a regular basis / scripted manner
Date
Msg-id CAGECzQRXMa-HcApdsPL+bLbZahvWCdspM8GZ_ObFt0_LFdbDGw@mail.gmail.com
Whole thread Raw
In response to Re: run pgindent on a regular basis / scripted manner  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: run pgindent on a regular basis / scripted manner
List pgsql-hackers
> As a concrete example, suppose Alice commits some code that uses "foo"
> as a variable name, and more or less concurrently, Bob commits something
> that defines "foo" as a typedef.  Bob's change is likely to have
> side-effects on the formatting of Alice's code.  If they're working in
> well-separated parts of the source tree, nobody is likely to notice
> that for awhile --- but whoever next touches the files Alice touched
> will be in for a surprise, which will be more or less painful depending
> on whether we've installed brittle processes.

Sounds like this conflict could be handled fairly easily by
having a local git hook rerunning pgindent whenever
you rebase a commit:
1. if you changed typedefs.list the hook would format all files
2. if you didn't it only formats the files that you changed

> As another example, the mechanisms we use to create the typedefs list
> in the first place are pretty squishy/leaky: they depend on which
> buildfarm animals are running the typedef-generation step, and on
> whether anything's broken lately in that code --- which happens on
> a fairly regular basis (eg [1]).  Maybe that could be improved,
> but I don't see an easy way to capture the set of system-defined
> typedefs that are in use on platforms other than your own.  I
> definitely do not want to go over to hand maintenance of that list.

Wouldn't the automatic addition-only solution that Andres suggested
solve this issue? Build farms could still remove unused typedefs
on a regular basis, but commits would at least add typedefs for the
platform that the comitter uses.

> I think we need to be content with a "soft", it's more-or-less-right
> approach to indentation.

I think that this would already be a significant improvement over the
current situation. My experience with the current situation is that
indentation is more-or-less-wrong.

> As I explained to somebody upthread, the
> main benefit of this for most people is avoiding the need for a massive
> once-a-year reindent run that causes merge failures for many pending
> patches.

Merge failures are one issue. But personally the main benefit that
I would be getting is being able to run pgindent on the files
I'm editing and get this weird +12 columns formatting correct
without having to manually type it. Without pgindent also
changing random parts of the files that someone else touched
a few commits before me.



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: CREATEROLE users vs. role properties
Next
From: Greg Stark
Date:
Subject: Re: Unicode grapheme clusters