Re: [msysGit] Re: The different EOL behavior between libgit2-based software and official Git
Torsten Bögershausen tbo...@web.de writes: No, it hadn't, under my Linux box. (And I had a .gittatributes file on the Mac OS box, which I forgot about. OK, that explains the difference; thanks for double-checking. Files with mixed LF CRLF in the repo are not changed by Git, when the checkout out or checked in, unless the .gitattributes say that the file is text. Hmph, I would have thought, after reading the Does anybody do that crazy stuff comment in convert.c, that we refrain from attempting to convert a file with a mixed mess, even if the file is marked as text, because it is unclear what it means to have both LF and CRLF in a file that is text. Is A\rB\nC\r\n a line terminated with a CRLF that happens to have a lone CR and then LF in between? You may be looking at a bug in a corner case that is so irrelevant that nobody has even noticed, let alone attempted to fix. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: The different EOL behavior between libgit2-based software and official Git
On 2014-06-20 18.33, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: tb@Linux:~/EOL_Test/TestAutoCrlf$ t=LF.txtrm -f $t git -c core.eol=CRLF checkout $t od -c $t 000 L i n e 1 \n l i n e ( 2 ) \n 020 l i n e 3 . \n t h i s i s 040 l i n e 4 \n l i n e N 060 o . 5 \n L i n e N u m b e r 100 6 \n \n In Documentation/config.txt, we find: core.eol:: Sets the line ending type to use in the working directory for files that have the `text` property set. Alternatives are ... Does that file $t in your practice have the `text` property set? No, it hadn't, under my Linux box. (And I had a .gittatributes file on the Mac OS box, which I forgot about. I am really sorry for the confusion and saying that Git behaves different under Linux and Mac OS). You are pointing into the right direction: Files with mixed LF CRLF in the repo are not changed by Git, when the checkout out or checked in, unless the .gitattributes say that the file is text. And libgit2 should do the same. However, I was confused by this https://www.kernel.org/pub/software/scm/git/docs/git-config.html (My comments inline with ##) --- core.autocrlf Setting this variable to true is almost the same as setting the text attribute to auto on all files except that text files are not guaranteed to be normalized: files that contain CRLF in the repository will not be touched. ## And is this line still valid: Use this setting if you want to have CRLF line endings in your working directory even though the repository does not have normalized line endings. ## In 2010 the the new safer autocrlf handling was introduced, ## and it looks as if commits fd6cce9e and c4805393 are involved here. ## When the file in the repo has only LF, it will have CRLF in the work tree ## When the file in the repo has mixed LF and CRLF, it will not be changed in the work tree ## and will have mixed line endings in the work tree ## When the file in the repo has only CRLF, it will not be changed in the work tree ## and will have CRLF in the work tree as well as in the repo. ##Should this line simply be dropped in the documentation ? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: The different EOL behavior between libgit2-based software and official Git
Wow! P.S. libgit2 just has a PR that try to be identical with official git. See https://github.com/libgit2/libgit2/pull/2432 Yue Lin Ho I am not sure how much problems Git/libgit2 have with files contains mixed LF-CRLF, as I have the same problem with the LF.txt The handling, according to my understandig, is: When core.eol is CRLF (or native under Windows) and core.autocrlf is true, and a file is checked out: If a file has CRLF in one line in the repo, nothing is changed. If a file has LF in one line in the repo, LF is converted into CRLF in the workspace. But here at my systems this doesn't seem to work as expected either for LF.txt: tb@mac:~/EOL_Test/TestAutoCrlf t=LF.txtrm -f $t git -c core.eol=CRLF checkout $t od -c $t 000L i n e 1 \r \n l i n e ( 2 ) 020 \r \n l i n e 3 . \r \n t h i s 040i s l i n e 4 \r \n l i n 060e N o . 5 \r \n L i n e N 100u m b e r 6 \r \n \r \n == tb@Linux:~/EOL_Test/TestAutoCrlf$ t=LF.txtrm -f $t git -c core.eol=CRLF checkout $t od -c $t 000 L i n e 1 \n l i n e ( 2 ) \n 020 l i n e 3 . \n t h i s i s 040 l i n e 4 \n l i n e N 060 o . 5 \n L i n e N u m b e r 100 6 \n \n -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: The different EOL behavior between libgit2-based software and official Git
Torsten Bögershausen tbo...@web.de writes: tb@Linux:~/EOL_Test/TestAutoCrlf$ t=LF.txtrm -f $t git -c core.eol=CRLF checkout $t od -c $t 000 L i n e 1 \n l i n e ( 2 ) \n 020 l i n e 3 . \n t h i s i s 040 l i n e 4 \n l i n e N 060 o . 5 \n L i n e N u m b e r 100 6 \n \n In Documentation/config.txt, we find: core.eol:: Sets the line ending type to use in the working directory for files that have the `text` property set. Alternatives are ... Does that file $t in your practice have the `text` property set? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
