summaryrefslogtreecommitdiff
path: root/t/t0027-auto-crlf.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-02-23convert.c: correct attr_action()Libravatar Torsten Bögershausen1-7/+26
df747b81 (convert.c: refactor crlf_action, 2016-02-10) introduced a bug to "git ls-files --eol". The "text" attribute was shown as "text eol=lf" or "text eol=crlf", depending on core.autocrlf or core.eol. Correct this and add test cases in t0027. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-08t0027: add tests for get_stream_filter()Libravatar Torsten Bögershausen1-135/+146
When a filter is configured, a different code-path is used in convert.c and entry.c via get_stream_filter(), but there are no test cases yet. Add tests for the filter API by configuring the ident filter. The result of the SHA1 conversion is not checked, this is already done in other TC. Add a parameter to checkout_files() in t0027. While changing the signature, add another parameter for the eol= attribute. This is currently unused, tests for e.g. "* text=auto eol=lf" will be added in a separate commit. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-18ls-files: add eol diagnosticsLibravatar Torsten Bögershausen1-21/+100
When working in a cross-platform environment, a user may want to check if text files are stored normalized in the repository and if .gitattributes are set appropriately. Make it possible to let Git show the line endings in the index and in the working tree and the effective text/eol attributes. The end of line ("eolinfo") are shown like this: "-text" binary (or with bare CR) file "none" text file without any EOL "lf" text file with LF "crlf" text file with CRLF "mixed" text file with mixed line endings. The effective text/eol attribute is one of these: "", "-text", "text", "text=auto", "text eol=lf", "text eol=crlf" git ls-files --eol gives an output like this: i/none w/none attr/text=auto t/t5100/empty i/-text w/-text attr/-text t/test-binary-2.png i/lf w/lf attr/text eol=lf t/t5100/rfc2047-info-0007 i/lf w/crlf attr/text eol=crlf doit.bat i/mixed w/mixed attr/ locale/XX.po to show what eol convention is used in the data in the index ('i'), and in the working tree ('w'), and what attribute is in effect, for each path that is shown. Add test cases in t0027. Helped-By: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-12t0027: improve test for not-normalized filesLibravatar Torsten Bögershausen1-34/+157
When a text file with mixed line endings is commited into the repo, it is called "not normalized" (or NNO) in t0027. The existing test case using repoMIX did not fully test all combinations: (Especially when core.autocrlf = true) Files with NL are not converted at commit, but at checkout, so a warning NL->CRLF is given. Files with CRLF are not converted at all (so no warning will be given), unless they are marked as "text" or "auto". Remove repoMIX introduced in commit 8eeab92f02, and replace it with a combination of NNO tests. Signed-off-by: Torsten Bögershausen <tboegi@web.de>
2015-04-25t0027: Add repoMIX and LF_nulLibravatar Torsten Bögershausen1-72/+85
"new safer autocrlf handling": - Check if eols in a file are converted at commit, when the file has CR (or CRLF) in the repo (technically speaking in the index). - Add a test-file repoMIX with mixed line-endings. - When converting LF->CRLF or CRLF->LF: check the warnings checkout_files(): - Checking out CRLF_nul and checking for eol coversion does not make much sense (CRLF will stay CRLF). - Use the file LF_nul instead: It is handled a binary in "auto" modes, and when declared as text the LF may be replaced with CRLF, depending on the configuration. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-18t0027: support NATIVE_CRLF platformsLibravatar Torsten Bögershausen1-10/+22
t0027 expects the native end-of-lines to be a single line feed character. On Windows, however, we set it to a carriage return character followed by a line feed character. Thus, we have to modify t0027 to expect different warnings depending on the end-of-line markers. Adjust the check of the warnings and use these macros: WILC: Warn if LF becomes CRLF WICL: Warn if CRLF becomes LF WAMIX: Mixed line endings: either CRLF->LF or LF->CRLF Improve the information given by check_warning(). Use test_cmp to show which warning is missing (or shouldn't be there). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-18t0027: cleanup: rename functions; avoid non-leading TABsLibravatar Torsten Bögershausen1-92/+92
Make more clear what the tests are doing: commit_check_warn(): Commit files and checks for conversion warnings. Old name: create_file_in_repo() checkout_files(): Checkout files from the repo and check if they have the appropriate line endings in the work space. Old name: check_files_in_ws() Replace non-leading TABS with spaces Signed-off-by: Torsten Bögershausen <tboegi@web.de> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-05t0027: check the eol conversion warningsLibravatar Torsten Bögershausen1-16/+66
Depending on the file content, eol parameters and .gitattributes "git add" may give a warning when the eol of a file will change when the file is checked out again. There are 2 different warnings, either "CRLF will be replaced..." or "LF will be replaced...". Let t0027 check for these warnings by adding new parameters to create_file_in_repo(), which tells what warnings are expected. When a file has eol=lf or eol=crlf in .gitattributes, it is handled as text and should be normalized. Add tests for these cases that were not covered. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-28t0027: Tests for core.eol=native, eol=lf, eol=crlfLibravatar Torsten Bögershausen1-100/+120
Add test cases for core.eol "native" and "" (unset). (MINGW uses CRLF, all other systems LF as native line endings) Add test cases for the attributes "eol=lf" and "eol=crlf" Other minor changes: - Use the more portable 'tr' instead of 'od -c' to convert '\n' into 'Q' and '\0' into 'N' - Style fixes for shell functions according to the coding guide lines - Replace "txtbin" with "attr" Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-08t0027: combinations of core.autocrlf, core.eol and textLibravatar Torsten Bögershausen1-0/+265
Historically there are 3 different parameters controlling how line endings are handled by Git: - core.autocrlf - core.eol - the "text" attribute in .gitattributes There are different types of content: - (1) Files with only LF - (2) Files with only CRLF - (3) Files with mixed LF and CRLF - (4) Files with LF and/or CRLF with CR not followed by LF - (5) Files which are binary (e.g. have NUL bytes) Recently the question came up, how files with mixed EOLs are handled by Git (and libgit2) when they are checked out and core.autocrlf=true. See http://git.661346.n2.nabble.com/The-different-EOL-behavior-between-libgit2-based-software-and-official-Git-td7613670.html#a7613801 Add the EXPENSIVE t0027-auto-crlf.sh to test all combination of files and parameters for both "git add/commit" and "git checkout". Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>