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
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 |