On 2014-06-20 18.33, Junio C Hamano wrote:
> Torsten Bögershausen <tbo...@web.de> writes:
> tb@Linux:~/EOL_Test/TestAutoCrlf$ t=LF.txt && rm -f $t && git -c
> core.eol=CRLF checkout $t && od -c $t
> 0000000 L i n e 1 \n l i n e ( 2 ) \n
> 0000020 l i n e 3 . \n t h i s i s
> 0000040 l i n e 4 \n l i n e N
> 0000060 o . 5 \n L i n e N u m b e r
> 0000100 6 \n \n
> In Documentation/config.txt, we find:
> 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
or checked in, unless the .gitattributes say that the file is text.
And libgit2 should do the same.
However, I was confused by this
(My comments inline with ##)
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
## 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