Junio C Hamano <gitster@xxxxxxxxx> writes: > Christian Holtje <docwhat@xxxxxxxxx> 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. -- To unsubscribe from this list: 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
