Junio C Hamano wrote:
Andrew Morton <akpm@xxxxxxxx> 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).
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Peter Williams pwil3058@xxxxxxxxxxxxxx
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html