summaryrefslogtreecommitdiff
path: root/t/t0027-auto-crlf.sh
AgeCommit message (Collapse)Author
2016-08-14convert: Correct NNO tests and missing `LF will be replaced by CRLF`Torsten Bögershausen
When a non-reversible CRLF conversion is done in "git add", a warning is printed on stderr (or Git dies, depending on checksafe) The function commit_chk_wrnNNO() in t0027 was written to test this, but did the wrong thing: Instead of looking at the warning from "git add", it looked at the warning from "git commit". This is racy because "git commit" may not have to do CRLF conversion at all if it can use the sha1 value from the index (which depends on whether "add" and "commit" run in a single second). Correct t0027 and replace the commit for each and every file with a commit of all files in one go. The function commit_chk_wrnNNO() should be renamed in a separate commit. Now that t0027 does the right thing, it detects a bug in covert.c: This sequence should generate the warning `LF will be replaced by CRLF`, but does not: $ git init $ git config core.autocrlf false $ printf "Line\r\n" >file $ git add file $ git commit -m "commit with CRLF" $ git config core.autocrlf true $ printf "Line\n" >file $ git add file "git add" calls crlf_to_git() in convert.c, which calls check_safe_crlf(). When has_cr_in_index(path) is true, crlf_to_git() returns too early and check_safe_crlf() is not called at all. Factor out the code which determines if "git checkout" converts LF->CRLF into will_convert_lf_to_crlf(). Update the logic around check_safe_crlf() and "simulate" the possible LF->CRLF conversion at "git checkout" with help of will_convert_lf_to_crlf(). Thanks to Jeff King <peff@peff.net> for analyzing t0027. Reported-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>
2016-07-06convert: unify the "auto" handling of CRLFTorsten Bögershausen
Before this change, $ echo "* text=auto" >.gitattributes $ echo "* eol=crlf" >>.gitattributes would have the same effect as $ echo "* text" >.gitattributes $ git config core.eol crlf Since the 'eol' attribute had higher priority than 'text=auto', this may corrupt binary files and is not what most users expect to happen. Make the 'eol' attribute to obey 'text=auto' and now $ echo "* text=auto" >.gitattributes $ echo "* eol=crlf" >>.gitattributes behaves the same as $ echo "* text=auto" >.gitattributes $ git config core.eol crlf In other words, $ echo "* text=auto eol=crlf" >.gitattributes has the same effect as $ git config core.autocrlf true and $ echo "* text=auto eol=lf" >.gitattributes has the same effect as $ git config core.autocrlf input Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-25convert.c: ident + core.autocrlf didn't workTorsten Bögershausen
When the ident attributes is set, get_stream_filter() did not obey core.autocrlf=true, and the file was checked out with LF. Change the rule when a streaming filter can be used: - if an external filter is specified, don't use a stream filter. - if the worktree eol is CRLF and "auto" is active, don't use a stream filter. - Otherwise the stream filter can be used. Add test cases in t0027. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-25t0027: test cases for combined attributesTorsten Bögershausen
Add more test cases for the not normalized files ("NNO"). The "text" attribute is most important, use it as the first parameter. "ident", if set, is the second paramater followed by the eol attribute. The eol attribute overrides core.autocrlf, which overrides core.eol. indent is not yet used, this will be done in the next commit. Use loops to test more combinations of attributes, like "* text eol=crlf" or especially "*text=auto eol=crlf". Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-25t0027: make commit_chk_wrnNNO() reliableTorsten Bögershausen
When the content of a commited file is unchanged and the attributes are changed, Git may not detect that the next commit must treat the file as changed. This happens when lstat() doesn't detect a change, since neither inode, mtime nor size are changed. Add a single "Z" character to change the file size and content. When the files are compared later in checkout_files(), the "Z" is removed before the comparison. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-23convert.c: correct attr_action()Torsten Bögershausen
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()Torsten Bögershausen
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-19ls-files: add eol diagnosticsTorsten Bögershausen
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 filesTorsten Bögershausen
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_nulTorsten Bögershausen
"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 platformsTorsten Bögershausen
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 TABsTorsten Bögershausen
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 warningsTorsten Bögershausen
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=crlfTorsten Bögershausen
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 textTorsten Bögershausen
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>