Whitespace and bullying

[ronnie sahlberg]

On Sat, Apr 7, 2018 at 4:44 PM, Martin Schwenke via samba-technical
<samba-technical at lists.samba.org> wrote:
> On Sat, 07 Apr 2018 17:55:00 +1200, Andrew Bartlett via samba-technical
> <samba-technical at lists.samba.org> wrote:
>
>> On Sat, 2018-04-07 at 15:07 +1200, Douglas Bagnall wrote:
>> > On 07/04/18 11:36, Timur I. Bakeyev via samba-technical wrote:
>> > >
>> > > Just to up-vote for the automated git-hook solution - we are using Travis
>> > > and flake8 for our Python code(Samba also has some .py files, right?) on
>> > > commits and though it caused some anticipation in the beginning, now our
>> > > code looks much cleaner and consistent in style.
>> >
>> > We actually already have a test that rejects trailing whitespace in Python, at
>> > python/samba/tests/source.py:185, run by autobuild and `make tests TESTS=source`.
>> >
>> > There is also a `make pep8` that runs the less interesting subset of flake8.
>> > Anyone who runs it sees over seven thousand lines of complaint and decides to
>> > focus on something else.
>>
>> I agree a process similar to the TESTS=source would be the best, and
>> like the warning-free builds we now enforce.
>>
>> I suggest that it be done per-subsystem.  If this is as serious as is
>> suggested, then it should not be a problem to make each subsystem
>> comply and then set (or remove) a flag so it can't regress, like we do
>> for warnings.
>
> One problem is that if a subsystem has a lot of failures (perhaps even
> just trailing whitespace in comments?), then the flag will be off for a
> long time (forever?) and we won't catch new problems.
>
>> This would allow good control so we don't cover third_party, heimdal
>> etc, where we would wish to keep code identical.
>>
>> The implementation detail that is key is ensuring that whatever we do:
>>  - handles exceptions (above)
>>  - works via autobuild, so it shows up in manual autobuild, travis CI
>> and gitlab CI, ideally via make test
>>
>> (The git commit hook will be too late as we are trying to solve this
>> with emotionless computers so it needs to be automated).
>
> I think a git hook is the right place to do it but a buggy git hook is
> worse than no git hook.

A buggy git hook should not be all that hard to fix.
The problem space you are looking at is not overly complex.


>
> I know we're trying to keep the emotion out, but I still don't
> understand what's wrong with using highlighting in an editor.  Another
> thing is that "git show" (or log, or whatever) highlights trailing
> whitespace... so provided the submitter looks at the changes using a
> tool like this then they will see the trailing whitespace.
>
> peace & happiness,
> martin
>