Whitespace and bullying

Martin Schwenke martin at meltin.net
Sat Apr 7 06:44:37 UTC 2018

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.

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,

More information about the samba-technical mailing list