Re: [PATCH v2] pre-commit hook should ignore carriage returns at EOL

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Christian Holtje <docwhat@gmail.com> writes:
>
>>> I suggested using "diff --check" (and possibly teaching "diff --check"
>>> other things the scripted example checks, such as conflict markers),
>>> which would know to honor the line endings specified per path via
>>> gitattributes(5), instead of building on top of the big Perl script,
>>> and I
>>> had an impression that you agreed to the approach.
>>
>> I'm completely confused how gitattributes and core.autocrlf interact,
>> etc.
>
> Here is a series I just cooked up so that we can remove the whole Perl
> script and replace it by adding --check to "diff-index" used there. 
>
> The first three are code clean-ups and the last two implements necessary
> new features to "diff --check".  The whole series somewhat depend on the
> fix to 'maint' not to lose the exit status I sent earlier.
>
> [PATCH 1/5] diff --check: explain why we do not care whether old side is binary
> [PATCH 2/5] check_and_emit_line(): rename and refactor
> [PATCH 3/5] checkdiff: pass diff_options to the callback
> [PATCH 4/5] Teach "diff --check" about a new blank lines at end
> [PATCH 5/5] diff --check: detect leftover conflict markers

With these enhancements in place, I think the pre-commit hook to find
problematic change would become essentially a one-liner, something like:

	git diff-index --check -M --cached

and the checking will obey what you configured with core.whitespace, which
globally defines what kind of whitespace breakages are "problematic",
and/or whitespace attribute which determines the same per path.

If you have for example Python source files that you would want all the
default whitespace checks (that is, trailing whitespaces are not allowed,
initial indentation part should not have SP followed by HT), you would
have

	*.py whitespace=trail,space-before-tab

in your .gitattributes, and the above command would catch such a
breakage.  If you further want to catch indentation with more than 8
SPs that can be replaced with HTs in your C sources, you would say:

	*.[ch] whitespace=indent-with-no-tab,trail,space-before-tab

You could choose to have CRLF line endings in the repository [*1*], and
for such projects, diff output would have tons of lines that end with
CRs.  To consider these CRs part of the line terminator, add cr-at-eol
to the value of whitespace attribute, like so:

	*.py whitespace=trail,space,cr-at-eol
	*.[ch] whitespace=indent,trail,space,cr-at-eol

[Footnote]

*1* I do not do Windows, but my understanding is that this practice is not
recommended because it would hurt cross-platform use of the project.  You
would instead keep your repository copy with LF line endings, and make
your checkouts have CRLF line endings by core.autocrlf configuration.