Whitespace and bullying

[ronnie sahlberg]

We are talking about this expression for a git hook, right?  "^\+.*[ \t]$"

On Sat, Apr 7, 2018 at 6:25 PM, ronnie sahlberg
<ronniesahlberg at gmail.com> wrote:
> 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
>>