Re: the war on trailing whitespace

[Peter Williams <pwil3058@bigpond.net.au>]

Junio C Hamano wrote:
> Andrew Morton <akpm@osdl.org> writes:
> 
> 
>>That's not a good reason.  People will discover that git has started
>>shouting at them and they'll work out how to make it stop.
>>
>>The problem is getting C users to turn the check on, not in getting python
>>users to turn it off.
> 
> 
> This whitespace policy should be at least per-project (people
> working on both kernel and other things may have legitimate
> reason to want trailing whitespace in the other project),

I'd be interested to hear these reasons.  My experience is that people 
don't put trailing white space in deliberately (or even tolerate it if 
they notice it) and it's usually there as a side effect of the way their 
text editor works (and that's also the reason that they don't usually 
notice it).  But if my experience is misleading me and there are valid 
reasons for having trailing white space I'm genuinely interested in 
knowing what they are.

> so we
> would need some configurability; the problem is *both*.
> 
> We could do one of two things, at least.
> 
>  - I modify the git-apply that is in the "next" branch further
>    to make --whitespace=error the default, and push it out.  You
>    convince people who feed things to you to update to *that*
>    version or later.
> 
>  - I already have the added whitespace detection hook (a fixed
>    one that actually matches what I use) shipped with git.  You
>    convince people who feed things to you to update to *that*
>    version or later, and to enable that hook.
> 
> I think you are arguing for the first one.  I am reluctant to do
> so because it would not help by itself *anyway*.  In any case
> you need to convince people who feed things to you to do
> something to prevent later changes fed to you from being
> contaminated with trailing whitespaces.
> 
> Having said that, I have a third solution, which consists of two
> patches that come on top of what are already in "next" branch:
> 
>  - apply: squelch excessive errors and --whitespace=error-all
>  - apply --whitespace: configuration option.
> 
> With these, git-apply used by git-applymbox and git-am would
> refuse to apply a patch that adds trailing whitespaces, when the
> per-repository configuration is set like this:
> 
>         [apply]
>                 whitespace = error
> 
> (Alternatively,
> 
> 	$ git repo-config apply.whitespace error
> 
> would set these lines there for you).
> 
> I think there are three kinds of git users.
> 
>  * Linus, you, and the kernel subsystem maintainers.  The
>    whitespace policy with this version of git-apply (with the
>    configuration option set to apply.whitespace=error) gives
>    would help these people by enforcing the SubmittingPatches
>    and your "perfect patch" requirements.
> 
>  * People who feed patches to the above people.  They are helped
>    by enabling the pre-commit hook that comes with git to
>    conform to the kernel whitespace policy -- they need to be
>    educated to do so.
> 
>  * People outside of kernel community, using git in projects to
>    which the kernel whitespace policy does not have any
>    relevance.
> 
> While I do consider the kernel folks a lot more important
> customers than other users, I have to take flak from the third
> kind of users, and to them, authority by Linus or you does not
> weigh as much as the first two classes of people.  Making the
> default to --whitespace=error means that you are making me
> justify this kernel project policy as something applicable to
> projects outside the kernel.  That is simply not fair to me.
> 
> You have to convince people you work with to update to at least
> to this version anyway, so I do not think it is too much to ask
> from you, while you are at it, to tell the higher echelon folks
> to do:
> 
> 	$ git repo-config apply.whitespace error
> 
> in their repositories (and/or set that in their templates so new
> repositories created with git-init-db would inherit it).
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce