On Tue, Jun 9, 2015 at 09:56:13PM -0400, Robert Haas wrote:
What I really don't want to do is apply the pgindent diff somewhat
blindly, without really knowing how many cases we're improving and how
many cases we're making worse. The number of times we've run pgindent
and then realized later
On Tue, May 26, 2015 at 2:55 PM, Robert Haas robertmh...@gmail.com wrote:
This is kind of why I think that reindenting the back branches is
unlikely to be productive: it only helps if you can get pgindent to do
the same thing on all branches, and I bet that's going to be tough.
...but having
On Tue, May 26, 2015 at 04:32:42PM -0300, Alvaro Herrera wrote:
Robert Haas wrote:
But every time we pgindent, especially with slightly different
settings, we cause tools like 'git blame' to return less useful
answers. And that sucks.
I've wondered a few times whether there's a way to
Andres Freund and...@anarazel.de writes:
But really, the typedef list is the minor part what annoys me about
pgindent. That it completely butchers so many constructs (e.g. function
pointer typedefs, inline asm as extreme examples) is much worse.
These are all things we might try to fix (where
On 05/27/2015 11:53 AM, Bruce Momjian wrote:
On Wed, May 27, 2015 at 02:31:07AM +0200, Andres Freund wrote:
But really, the typedef list is the minor part what annoys me about
pgindent. That it completely butchers so many constructs (e.g. function
pointer typedefs, inline asm as extreme
On Wed, May 27, 2015 at 02:31:07AM +0200, Andres Freund wrote:
But really, the typedef list is the minor part what annoys me about
pgindent. That it completely butchers so many constructs (e.g. function
pointer typedefs, inline asm as extreme examples) is much worse. It's
also neigh on
On 5/26/15 8:31 PM, Andres Freund wrote:
I actually think both are relatively easy to figure out without a
typedef list. There's harder cases though, e.g. (char *) foo in an
expression is already more complicated.
Well, if you know of a way to fix this, let's see it. Others have been
trying
On 05/27/2015 05:19 PM, Peter Eisentraut wrote:
And even if we got to the point where all commits should be perfectly
pgindented, it wouldn't work, because under the current workflow the
updated typedef list isn't available until after the commit (on an
unpredictable schedule). (This problem
On 5/27/15 2:55 PM, Tom Lane wrote:
These are all things we might try to fix (where fix could include
replace it with another tool) if the back-patching pain created by even
minor changes of the formatting rules weren't so great. But at this point
I despair of getting to consensus on a way to
On 2015-05-27 16:55:45 -0400, Peter Eisentraut wrote:
On 5/26/15 8:31 PM, Andres Freund wrote:
I actually think both are relatively easy to figure out without a
typedef list. There's harder cases though, e.g. (char *) foo in an
expression is already more complicated.
Well, if you know of
On 5/27/15 5:08 PM, Andres Freund wrote:
I don't think I need to. clang-format has apparently done pretty much
what I described:
Well, that appears to work reasonably well in practice, which is all we
can hope for. Unfortunately, clang-format makes a bit of a mess of some
of our code, so it
On 2015-05-26 20:25:24 -0400, Peter Eisentraut wrote:
On 5/25/15 7:15 PM, Andres Freund wrote:
On 2015-05-25 19:01:28 -0400, Bruce Momjian wrote:
A longer-term fix would be to make pgindent less stupid about this sort
of usage, but nobody's yet volunteered to dig into the guts of that code.
On 5/25/15 7:15 PM, Andres Freund wrote:
On 2015-05-25 19:01:28 -0400, Bruce Momjian wrote:
A longer-term fix would be to make pgindent less stupid about this sort
of usage, but nobody's yet volunteered to dig into the guts of that code.
I assume a typedefs list is going to be a requirement
On Tue, May 26, 2015 at 3:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Realistically, with merge.conflictstyle = diff3 (why is this not the
default?), resolving whitespace conflicts that occur when you try to
cherry-pick is typically not very difficult.
On 5/25/15 5:51 PM, Alvaro Herrera wrote:
Tom Lane wrote:
A longer-term fix would be to make pgindent less stupid about this sort
of usage, but nobody's yet volunteered to dig into the guts of that code.
We've discussed in the past that we could use something other than BSD's
indent --
On Mon, May 25, 2015 at 5:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
Something is wrong. See aclchk.c changes.
Yes, this is what I was concerned about. aclitem was a typedef in 9.0
and
Robert Haas wrote:
But every time we pgindent, especially with slightly different
settings, we cause tools like 'git blame' to return less useful
answers. And that sucks.
I've wondered a few times whether there's a way to make pgindent commits
transparent to git blame, i.e. blame their
On 05/25/2015 05:34 PM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
Something is wrong. See aclchk.c changes.
Yes, this is what I was concerned about. aclitem was a typedef in 9.0
and 9.1, and the use of that as a
Robert Haas robertmh...@gmail.com writes:
Realistically, with merge.conflictstyle = diff3 (why is this not the
default?), resolving whitespace conflicts that occur when you try to
cherry-pick is typically not very difficult.
Really? The problems I have generally come from places where
On Tue, May 26, 2015 at 3:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Realistically, with merge.conflictstyle = diff3 (why is this not the
default?), resolving whitespace conflicts that occur when you try to
cherry-pick is typically not very
On 2015-05-26 16:32:42 -0300, Alvaro Herrera wrote:
I've wondered a few times whether there's a way to make pgindent commits
transparent to git blame, i.e. blame their modified lines to whatever
commits modified them immediately before.
You can make blame ignore whitespace changes with -w --
* Andres Freund (and...@anarazel.de) wrote:
On 2015-05-20 11:47:15 -0400, Robert Haas wrote:
On Tue, May 19, 2015 at 10:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
To do it before every minor release would require re-indenting HEAD
as well (since the whole point is to keep HEAD and the back
On 2015-05-20 11:47:15 -0400, Robert Haas wrote:
On Tue, May 19, 2015 at 10:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
To do it before every minor release would require re-indenting HEAD
as well (since the whole point is to keep HEAD and the back branches
consistent). I think we'd get too
On Sat, May 23, 2015 at 12:32:34PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Are we ready for a pgindent run? Back branches?
I think we could do it in HEAD, but it doesn't seem like we have consensus
about whether to touch the back branches. Suggest just HEAD for now
Bruce Momjian br...@momjian.us writes:
Here is a re-run of pgindent on 9.4:
http://momjian.us/expire/pgindent-9.4.diff
Some of those diffs would disappear if you'd used an up-to-date typedefs
list ... not a lot, but some.
That is rather a lot of diffs, but the thing I think people ought
Bruce Momjian br...@momjian.us writes:
If we wanted to do this on backbranches, I think we would create a diff
file of the minor release just before running pgindent and stamping so
users could see the non-pgindent content of the release.
What for? Those who want to see that can look at our
Bruce Momjian br...@momjian.us writes:
On Mon, May 25, 2015 at 03:03:00PM -0400, Tom Lane wrote:
As we discussed upthread, if we're trying to minimize cross-branch
pgindent differences then we probably need to use the same typedefs
list in all branches. I believe Andrew's already set up
On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
OK, makes sense. You can see the old and 'all' diffs here:
http://momjian.us/expire/
Something is wrong. See aclchk.c changes.
Yes, this is what I was concerned about. aclitem was a typedef in
Bruce Momjian wrote:
OK, makes sense. You can see the old and 'all' diffs here:
http://momjian.us/expire/
Something is wrong. See aclchk.c changes.
Also, sometime ago we changed pgindent rules so that dot-space-space is
not turned into dot-tab in comments anymore, and many places
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
FWIW the multixact code is now slightly different between HEAD and
9.3/9.4, also. So if that needs further patches, they will be fun to
backpatch.
Well, sure, intentional cross-branch changes are always a hazard.
But
Bruce Momjian wrote:
One issue I discussed is doing a pgindent-only release so users doing a
diff would not have pgindent diffs mixed with fixes.
I doubt anyone is reading hand-generated diffs these days. Those that
want to read diffs are much better served by looking at the git repo
Andres Freund and...@anarazel.de writes:
On 2015-05-20 11:47:15 -0400, Robert Haas wrote:
On Tue, May 19, 2015 at 10:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
To do it before every minor release would require re-indenting HEAD
as well (since the whole point is to keep HEAD and the back
Tom Lane wrote:
What we need to consider right now is whether to include back branches
in the existing practice of reindenting between development cycles.
This is somewhat urgent because we already did HEAD, so we have already
created a divergence from HEAD to 9.4 which is going to cause us
On Mon, May 25, 2015 at 12:49:41PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
If we wanted to do this on backbranches, I think we would create a diff
file of the minor release just before running pgindent and stamping so
users could see the non-pgindent content of the
On 2015-05-25 14:55:54 -0400, Bruce Momjian wrote:
One issue I discussed is doing a pgindent-only release so users doing a
diff would not have pgindent diffs mixed with fixes.
I find a pgindent only release a pretty pointless goal. That's what git
is for.
--
Sent via pgsql-hackers mailing
Alvaro Herrera alvhe...@2ndquadrant.com writes:
FWIW the multixact code is now slightly different between HEAD and
9.3/9.4, also. So if that needs further patches, they will be fun to
backpatch.
Well, sure, intentional cross-branch changes are always a hazard.
But pgindent diffs are a hazard
On Mon, May 25, 2015 at 03:03:00PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, May 25, 2015 at 01:10:04PM -0400, Tom Lane wrote:
Some of those diffs would disappear if you'd used an up-to-date typedefs
list ... not a lot, but some.
Uh, you mean a current 9.4.X
On Mon, May 25, 2015 at 03:12:24PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, May 25, 2015 at 03:03:00PM -0400, Tom Lane wrote:
As we discussed upthread, if we're trying to minimize cross-branch
pgindent differences then we probably need to use the same typedefs
Bruce Momjian br...@momjian.us writes:
On Mon, May 25, 2015 at 03:12:24PM -0400, Tom Lane wrote:
The point is for the back branches to absorb pgindent-induced changes that
have already happened in HEAD, so I'm not sure what you're getting at.
My point is uses of new typedefs names added in
On Mon, May 25, 2015 at 03:20:47PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, May 25, 2015 at 03:12:24PM -0400, Tom Lane wrote:
The point is for the back branches to absorb pgindent-induced changes that
have already happened in HEAD, so I'm not sure what you're
On Mon, May 25, 2015 at 09:00:25PM +0200, Andres Freund wrote:
On 2015-05-25 14:55:54 -0400, Bruce Momjian wrote:
One issue I discussed is doing a pgindent-only release so users doing a
diff would not have pgindent diffs mixed with fixes.
I find a pgindent only release a pretty pointless
On Mon, May 25, 2015 at 01:10:04PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Here is a re-run of pgindent on 9.4:
http://momjian.us/expire/pgindent-9.4.diff
Some of those diffs would disappear if you'd used an up-to-date typedefs
list ... not a lot, but some.
Uh,
Bruce Momjian br...@momjian.us writes:
On Mon, May 25, 2015 at 01:10:04PM -0400, Tom Lane wrote:
Some of those diffs would disappear if you'd used an up-to-date typedefs
list ... not a lot, but some.
Uh, you mean a current 9.4.X typedef list? Should I try that?
As we discussed upthread, if
On Mon, May 25, 2015 at 01:28:16PM -0400, Tom Lane wrote:
What we need to consider right now is whether to include back branches
in the existing practice of reindenting between development cycles.
This is somewhat urgent because we already did HEAD, so we have already
created a divergence from
Tom Lane wrote:
A longer-term fix would be to make pgindent less stupid about this sort
of usage, but nobody's yet volunteered to dig into the guts of that code.
We've discussed in the past that we could use something other than BSD's
indent -- astyle has been mentioned. It seems that with
On 2015-05-25 19:01:28 -0400, Bruce Momjian wrote:
A longer-term fix would be to make pgindent less stupid about this sort
of usage, but nobody's yet volunteered to dig into the guts of that code.
I assume a typedefs list is going to be a requirement of any decent C
indenting tool.
Maybe
Bruce Momjian br...@momjian.us writes:
On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
Something is wrong. See aclchk.c changes.
Yes, this is what I was concerned about. aclitem was a typedef in 9.0
and 9.1, and the use of that as a typedef in 9.4 is certainly odd:
-
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
A longer-term fix would be to make pgindent less stupid about this sort
of usage, but nobody's yet volunteered to dig into the guts of that code.
We've discussed in the past that we could use something other than BSD's
indent --
On Mon, May 25, 2015 at 05:34:12PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
Something is wrong. See aclchk.c changes.
Yes, this is what I was concerned about. aclitem was a typedef in 9.0
and 9.1, and
Bruce Momjian br...@momjian.us writes:
On Tue, May 26, 2015 at 01:15:17AM +0200, Andres Freund wrote:
Maybe I'm missing something major here, but why? Afaict it's just only
used for formatting decisions that could be made without it just as well?
Uh, well, formatting decisions is what
On Mon, May 25, 2015 at 06:48:47PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
OK, makes sense. You can see the old and 'all' diffs here:
http://momjian.us/expire/
On Tue, May 26, 2015 at 01:15:17AM +0200, Andres Freund wrote:
On 2015-05-25 19:01:28 -0400, Bruce Momjian wrote:
A longer-term fix would be to make pgindent less stupid about this sort
of usage, but nobody's yet volunteered to dig into the guts of that code.
I assume a typedefs list
Bruce Momjian wrote:
On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
OK, makes sense. You can see the old and 'all' diffs here:
http://momjian.us/expire/
Something is wrong. See aclchk.c changes.
Yes, this is what I was concerned
On 05/23/2015 11:37 PM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Sun, May 24, 2015 at 04:16:07AM +0200, Andres Freund wrote:
- if (IsA(node, Aggref) || IsA(node, GroupingFunc))
+ if (IsA(node, Aggref) ||IsA(node, GroupingFunc))
There's a bunch of changes like this. Looks
Andrew Dunstan and...@dunslane.net writes:
On 05/23/2015 11:37 PM, Tom Lane wrote:
No, pgindent has *always* been wonky about lines that contain a typedef
name but are not variable declarations.
Well, that sounds like something we should try to patch, doesn't it?
(No, I'm not volunteering.)
On Sat, May 23, 2015 at 11:37:30PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Sun, May 24, 2015 at 04:16:07AM +0200, Andres Freund wrote:
- if (IsA(node, Aggref) || IsA(node, GroupingFunc))
+ if (IsA(node, Aggref) ||IsA(node, GroupingFunc))
There's a bunch of
On Sat, May 23, 2015 at 12:32:34PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Are we ready for a pgindent run? Back branches?
I think we could do it in HEAD, but it doesn't seem like we have consensus
about whether to touch the back branches. Suggest just HEAD for now
On 2015-05-23 21:36:50 -0400, Bruce Momjian wrote:
pgindent run on HEAD and committed.
- if (IsA(node, Aggref) || IsA(node, GroupingFunc))
+ if (IsA(node, Aggref) ||IsA(node, GroupingFunc))
There's a bunch of changes like this. Looks rather odd to me? I don't
recall seing much code looking
On Sun, May 24, 2015 at 04:16:07AM +0200, Andres Freund wrote:
On 2015-05-23 21:36:50 -0400, Bruce Momjian wrote:
pgindent run on HEAD and committed.
- if (IsA(node, Aggref) || IsA(node, GroupingFunc))
+ if (IsA(node, Aggref) ||IsA(node, GroupingFunc))
There's a bunch of changes like
On Fri, May 22, 2015 at 12:02:11PM -0400, Tom Lane wrote:
I guess in the
scenario you're describing, the most helpful thing would be if the
pgindent commit put the typedef list it had used into the tree, and then
we just use that (plus manual additions) when generating the I' commit.
I have
Bruce Momjian br...@momjian.us writes:
Are we ready for a pgindent run? Back branches?
I think we could do it in HEAD, but it doesn't seem like we have consensus
about whether to touch the back branches. Suggest just HEAD for now and
we can continue to argue about the back branches.
Bruce Momjian br...@momjian.us writes:
On Sun, May 24, 2015 at 04:16:07AM +0200, Andres Freund wrote:
- if (IsA(node, Aggref) || IsA(node, GroupingFunc))
+ if (IsA(node, Aggref) ||IsA(node, GroupingFunc))
There's a bunch of changes like this. Looks rather odd to me? I don't
recall seing
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas wrote:
On Tue, May 19, 2015 at 10:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
To do it before every minor release would require re-indenting HEAD
as well (since the whole point is to keep HEAD and the back branches
consistent). I
Robert Haas wrote:
On Tue, May 19, 2015 at 10:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
To do it before every minor release would require re-indenting HEAD
as well (since the whole point is to keep HEAD and the back branches
consistent). I think we'd get too much push-back from developers
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I believe it's possible to mechanically rebase a patch over an indent
run of the underlying branch with half a dozen commands or less. +1 for
reindenting all branches before each minor release, FWIW.
Yeah? Can you show an
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I believe it's possible to mechanically rebase a patch over an indent
run of the underlying branch with half a dozen commands or less. +1 for
reindenting all branches before each
On Tue, May 19, 2015 at 10:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
To do it before every minor release would require re-indenting HEAD
as well (since the whole point is to keep HEAD and the back branches
consistent). I think we'd get too much push-back from developers
whose pending patches
On 05/18/2015 08:06 PM, Andrew Dunstan wrote:
On 05/18/2015 07:04 PM, Bruce Momjian wrote:
On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian br...@momjian.us
wrote:
There was talk last time of
On Mon, May 18, 2015 at 6:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I am personally not excited about that. I would rather leave the
back-branches alone.
It would be awfully nice though if we didn't have to deal with random
cross-branch indenting differences. I've lost, maybe not years off
Robert Haas robertmh...@gmail.com writes:
On Mon, May 18, 2015 at 6:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Would it alleviate your concern any if we eased into this, like say only
apply the back-branch pgindent run to 9.5 and later branches? Then at
least I could foresee the end of that
Andrew Dunstan and...@dunslane.net writes:
Tom, if you want to get dromedary reporting on all branches, just
remove the branches = [ 'HEAD' ], from the config.
dromedary is a pretty slow machine, so I'm going to pass on that unless
there's a good reason to think it would find typedefs your
On Sat, May 16, 2015 at 01:05:27PM -0400, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Sat, May 16, 2015 at 5:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
With feature freeze behind us, I'd like to propose that now is a good
time for a pgindent run.
+1, except I suggest
On Mon, May 18, 2015 at 07:10:00PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote:
(BTW, one practical issue is where would we get typedef lists relevant
to the back branches. I'm not sure if the buildfarm
On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian br...@momjian.us wrote:
There was talk last time of pgindent-ing head and all back branches,
because a patch applied to head and back branches
On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian br...@momjian.us wrote:
On Sat, May 16, 2015 at 01:05:27PM -0400, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Sat, May 16, 2015 at 5:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
With feature freeze behind us, I'd like to propose
Robert Haas robertmh...@gmail.com writes:
On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian br...@momjian.us wrote:
There was talk last time of pgindent-ing head and all back branches,
because a patch applied to head and back branches was historically only
pgindented in head, meaning that any
Bruce Momjian br...@momjian.us writes:
On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote:
(BTW, one practical issue is where would we get typedef lists relevant
to the back branches. I'm not sure if the buildfarm infrastructure is
capable of collecting branch-specific data, or if we'd
On 05/18/2015 07:04 PM, Bruce Momjian wrote:
On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian br...@momjian.us wrote:
There was talk last time of pgindent-ing head and all back branches,
Magnus Hagander mag...@hagander.net writes:
On Sat, May 16, 2015 at 5:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
With feature freeze behind us, I'd like to propose that now is a good
time for a pgindent run.
+1, except I suggest we at least delay it until we have wrapped the new
minor
On Sat, May 16, 2015 at 5:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
With feature freeze behind us, I'd like to propose that now is a good
time for a pgindent run. It's possible we'd need another one before
9.5 is branched off from HEAD, but a run now ought to take care of 95%
of the cleanup
On Sat, May 16, 2015 at 11:58:59AM -0400, Tom Lane wrote:
With feature freeze behind us, I'd like to propose that now is a good
time for a pgindent run. It's possible we'd need another one before
9.5 is branched off from HEAD, but a run now ought to take care of 95%
of the cleanup needed. I
81 matches
Mail list logo
