undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
8ecf0c8382
git-commit-vandalism/t/.gitattributes

25 lines
444 B
Plaintext
Raw Normal View History

t/.gitattributes: only ignore whitespace errors in test files Only ignore whitespace errors in t/tNNNN-*.sh and the t/tNNNN subdirectories. Other files (like test libraries) should still be checked. Also fix a whitespace error in t/test-lib.sh. Signed-off-by: Lea Wiemann <LeWiemann@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-13 00:35:59 +02:00
t[0-9][0-9][0-9][0-9]/* -whitespace
chainlint: fix for core.autocrlf=true The `chainlint` target compares actual output to expected output, where the actual output is generated from files that are specifically checked out with LF-only line endings. So the expected output needs to be checked out with LF-only line endings, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-15 16:33:44 +02:00
/chainlint/*.expect eol=lf
Fix the remaining tests that failed with core.autocrlf=true The test suite is mainly developed on Linux and MacOSX, which is the reason that nobody thought to mark files as LF-only as needed. The symptom is a test suite that fails left and right when being checked out using Git for Windows (which defaults to core.autocrlf=true). Mostly, the problems stem from Git's (LF-only) output being compared to hard-coded files that are checked out with line endings according to core.autocrlf (which is of course incorrect). This includes the two test files in t/diff-lib/, README and COPYING. This patch can be validated even on Linux by using this cadence: git config core.autocrlf true rm .git/index && git stash make -j15 DEVELOPER=1 test Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-09 14:54:27 +02:00
/diff-lib/* eol=lf
/t0110/url-* binary
range-diff: add tests These are essentially lifted from https://github.com/trast/tbdiff, with light touch-ups to account for the command now being named `git range-diff`. Apart from renaming `tbdiff` to `range-diff`, only one test case needed to be adjusted: 11 - 'changed message'. The underlying reason it had to be adjusted is that diff generation is sometimes ambiguous. In this case, a comment line and an empty line are added, but it is ambiguous whether they were added after the existing empty line, or whether an empty line and the comment line are added *before* the existing empty line. And apparently xdiff picks a different option here than Python's difflib. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-13 13:33:16 +02:00
/t3206/* eol=lf
Fix the remaining tests that failed with core.autocrlf=true The test suite is mainly developed on Linux and MacOSX, which is the reason that nobody thought to mark files as LF-only as needed. The symptom is a test suite that fails left and right when being checked out using Git for Windows (which defaults to core.autocrlf=true). Mostly, the problems stem from Git's (LF-only) output being compared to hard-coded files that are checked out with line endings according to core.autocrlf (which is of course incorrect). This includes the two test files in t/diff-lib/, README and COPYING. This patch can be validated even on Linux by using this cadence: git config core.autocrlf true rm .git/index && git stash make -j15 DEVELOPER=1 test Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-09 14:54:27 +02:00
/t3900/*.txt eol=lf
/t3901/*.txt eol=lf
/t4034/*/* eol=lf
/t4013/* eol=lf
/t4018/* eol=lf
t4051: mark supporting files as requiring LF-only line endings The test t4051-diff-function-context.sh passes on Linux when core.autocrlf=true even without marking its support files as LF-only, but they fail when core.autocrlf=true in Git for Windows' SDK. The reason is that `grep ... >file.c.new` will keep CR/LF line endings on Linux (obviously treating CRs as if they were regular characters), but will be converted to LF-only line endings with MSYS2's grep that is used in Git for Windows. As we do not want to validate the way the available `grep` works, let's just mark the input as LF-only and move on. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-09 14:54:32 +02:00
/t4051/* eol=lf
Fix the remaining tests that failed with core.autocrlf=true The test suite is mainly developed on Linux and MacOSX, which is the reason that nobody thought to mark files as LF-only as needed. The symptom is a test suite that fails left and right when being checked out using Git for Windows (which defaults to core.autocrlf=true). Mostly, the problems stem from Git's (LF-only) output being compared to hard-coded files that are checked out with line endings according to core.autocrlf (which is of course incorrect). This includes the two test files in t/diff-lib/, README and COPYING. This patch can be validated even on Linux by using this cadence: git config core.autocrlf true rm .git/index && git stash make -j15 DEVELOPER=1 test Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-09 14:54:27 +02:00
/t4100/* eol=lf
/t4101/* eol=lf
/t4109/* eol=lf
/t4110/* eol=lf
/t4135/* eol=lf
/t4211/* eol=lf
/t4252/* eol=lf
/t5100/* eol=lf
/t5515/* eol=lf
/t556x_common eol=lf
/t7500/* eol=lf
/t8005/*.txt eol=lf
/t9*/*.dump eol=lf
Reference in New Issue Copy Permalink