Re: pgindent (was Re: [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

Piotr Stefaniak <postgres@piotr-stefaniak.me> writes:
>> * const unsigned(*TABLE_index)[2];
>> * OffsetNumber(*findChildPtr) (GinBtree, Page, BlockNumber, OffsetNumber);
>> * an overlength comment line is simply busted altogether

> Fixed and pushed to my github repository.

I'm pretty confused by your github repo.  It doesn't have a master
branch, and what seems to be the HEAD branch is called "pass3", but
when I tried to "git pull" just now I got


>From https://github.com/pstef/freebsd_indent
 + b7b74cb...e4ccc02 pass3      -> origin/pass3  (forced update)
First, rewinding head to replay your work on top of it...
Applying: [bugfix] Don't add unneeded space in function pointer declaration.
Using index info to reconstruct a base tree...
M       indent.c
M       tests/declarations.0.stdout
Falling back to patching base and 3-way merge...
Auto-merging indent.c
CONFLICT (content): Merge conflict in indent.c
Failed to merge in the changes.
Patch failed at 0001 [bugfix] Don't add unneeded space in function pointer declaration.
The copy of the patch that failed is found in:
   /home/postgres/freebsd_indent/.git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".


... which is pretty odd because there were no local changes.  It should
have just done a fast-forward, I'd think.

Being lazy, I just wiped my copy and re-cloned, but it still seems the
same as before ... last commit on the pass3 branch is from Mar 4.
What branch should I be paying attention to?

> Note that indent won't wrap
> long lines like links or paths anymore. But obviously it can't join
> parts of long links that have been wrapped by previous pgindent runs.

Check, I wouldn't expect it to.  I'll probably make a manual pass to sew
split-up URLs in comments back together.

>> * the comments get formatted differently for -ts4 than -ts8
>> * extra spacing getting inserted for fairly long labels
>> * some enum declarations get the phony extra indentation
>> * comments on the same line are now run together
>> * surplus indentation for SH_ELEMENT_TYPE * data;

> Please tell me if the list of your complaints above is incomplete. I
> will analyze those next.

There's also the portability issues: __FBSDID() and bcopy() and
<sys/cdefs.h>.

			regards, tom lane