Re: PgJDBC: code reformat

From: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>
To: Kevin Wooten <kdubb(at)me(dot)com>
Cc: danap <danap(at)itstriangle(dot)com>, PostgreSQL JDBC <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: PgJDBC: code reformat
Date: 2015-12-27 18:16:26
Message-ID: CAB=Je-E8t6MJea7JGsMmPyofwhcUXdCnLpM8Muc-Z_t7-=w=vg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

>Good luck finding the “bug fix” in a whole file reformat

Do you mean "git blame" kind of thing?

If the final state is the same, then there is no difference if it
comes in a single commit or from a series of commits.
"git blame" would be broken anyway, thus we'd better break it sooner.

If you mean bugs introduced by the reformat itself, I believe there
should not be many as there were just a few places where I had to
change code manually.

All the rules that involve some brain like "variable naming", "public
static final order", etc rules are disabled and they are subject to
other PRs.

I think the way to go there is to enable the rules, execute checkstyle
and enjoy all the 100500 errors. Then we configure
<maxAllowedViolations>100500</maxAllowedViolations>. That would make
sure new code is using proper names while the old one is either
deleted eventually or updated.

> with whole file reformats, e.g. “Fixed bug in generated SQL & formatted file to follow conventions”.

I think it is undesired as it would definitely create lots of merge conflicts.

> I should stop with my opinions here… that being said…

Lack of feedback would be much worse.

Vladimir

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Kevin Wooten 2015-12-27 18:31:16 Re: PgJDBC: code reformat
Previous Message Kevin Wooten 2015-12-27 18:00:01 Re: PgJDBC: code reformat