git-archive and core.eol

git-archive and core.eol

[Erik Faye-Lund]

I recently tried the following on Windows:

$ git init
Initialized empty Git repository in c:/Users/kusma/test/.git/
$ echo "foo
bar" > test.txt
$ git -c core.autocrlf=true add test.txt
warning: LF will be replaced by CRLF in test.txt.
The file will have its original line endings in your working directory.
$ git commit -m.
 1 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 test.txt
$ git -c core.autocrlf=true -c core.eol=lf archive --format=tar HEAD > test.tar
$ tar xvf test.tar
$ od -c test.txt
0000000   f   o   o  \r  \n   b   a   r  \r  \n
0000012

Just to be sure, I checked this:

$ git show HEAD:test.txt | od -c
0000000   f   o   o  \n   b   a   r  \n
0000010

Yep, the file has LF in the repo, as expected... the warning from
git-add is a bit confusing, but OK.

Hmm, so git-archive writes CRLF even if I said I wanted LF. But then I
tried this on Linux:

$ git init
Initialized empty Git repository in /home/kusma/src/test/.git/
$ echo "foo
bar" > test.txt
$ git add test.txt
$ git commit -m.
[master (root-commit) c6f195e] .
 1 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 test.txt
$ git -c core.autocrlf=true -c core.eol=crlf archive --format=tar HEAD
> test.tar
$ tar xvf test.tar
test.txt
$ od -c test.txt
0000000   f   o   o  \r  \n   b   a   r  \r  \n
0000012

This leaves me a bit puzzled. On Linux, I can override the default
new-line style CRLF for git-archive, but I can't override it to LF on
Windows?

I expected it to work because sha1_file_to_archive calls
convert_to_working_tree. I've tried stepping through the code, but I
don't quite understand where it goes wrong. Or even how the code is
supposed to work :P

Does anyone have any clue what's going on? I'm running with the
current master, git version 1.7.3.3.585.g74f6e.

Re: git-archive and core.eol

[René Scharfe]

Am 15.12.2010 23:32, schrieb Erik Faye-Lund:
> I recently tried the following on Windows:
> 
> $ git init
> Initialized empty Git repository in c:/Users/kusma/test/.git/
> $ echo "foo
> bar" > test.txt
> $ git -c core.autocrlf=true add test.txt
> warning: LF will be replaced by CRLF in test.txt.
> The file will have its original line endings in your working directory.
> $ git commit -m.
>  1 files changed, 2 insertions(+), 0 deletions(-)
>  create mode 100644 test.txt
> $ git -c core.autocrlf=true -c core.eol=lf archive --format=tar HEAD > test.tar
> $ tar xvf test.tar
> $ od -c test.txt
> 0000000   f   o   o  \r  \n   b   a   r  \r  \n
> 0000012
> 
> Just to be sure, I checked this:
> 
> $ git show HEAD:test.txt | od -c
> 0000000   f   o   o  \n   b   a   r  \n
> 0000010
> 
> Yep, the file has LF in the repo, as expected... the warning from
> git-add is a bit confusing, but OK.
> 
> Hmm, so git-archive writes CRLF even if I said I wanted LF. But then I
> tried this on Linux:
> 
> $ git init
> Initialized empty Git repository in /home/kusma/src/test/.git/
> $ echo "foo
> bar" > test.txt
> $ git add test.txt
> $ git commit -m.
> [master (root-commit) c6f195e] .
>  1 files changed, 2 insertions(+), 0 deletions(-)
>  create mode 100644 test.txt
> $ git -c core.autocrlf=true -c core.eol=crlf archive --format=tar HEAD
>> test.tar
> $ tar xvf test.tar
> test.txt
> $ od -c test.txt
> 0000000   f   o   o  \r  \n   b   a   r  \r  \n
> 0000012
> 
> This leaves me a bit puzzled. On Linux, I can override the default
> new-line style CRLF for git-archive, but I can't override it to LF on
> Windows?
> 
> I expected it to work because sha1_file_to_archive calls
> convert_to_working_tree. I've tried stepping through the code, but I
> don't quite understand where it goes wrong. Or even how the code is
> supposed to work :P
> 
> Does anyone have any clue what's going on? I'm running with the
> current master, git version 1.7.3.3.585.g74f6e.

I can't seem to replicate this (1.7.4-rc1); see below for the test script
I tried to come up with.  It should test all combinations of the relevant
config variables and the text attribute.  I cheated by simply setting the
expectations to match the results on Linux; I didn't check if these are
indeed the correct results.  The test passes for me on MinGW, too, though.

Did I miss a variable or are some of the expectations wrong?

Thanks,
René


 t/t5002-archive-eol.sh |   86 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 86 insertions(+), 0 deletions(-)

diff --git a/t/t5002-archive-eol.sh b/t/t5002-archive-eol.sh
new file mode 100755
index 0000000..50f80f7
--- /dev/null
+++ b/t/t5002-archive-eol.sh
@@ -0,0 +1,86 @@
+#!/bin/sh
+
+test_description='git archive EOL tests'
+
+. ./test-lib.sh
+
+prepare() {
+	tfile="autocrlf_$1-eol_$2.tar"
+	dir="autocrlf_$1-eol_$2.d"
+	test_expect_success "archive with autocrlf=$1 eol=$2" "
+		git -c core.autocrlf=$1 -c core.eol=$2 archive HEAD >$tfile &&
+		(mkdir $dir && cd $dir && \"$TAR\" xf -) <$tfile
+	"
+}
+
+expect_success() {
+	file="autocrlf_$2-eol_$3.d/autocrlf_$1/$4"
+	desc="add autocrlf=$1, archive autocrlf=$2 eol=$3"
+	test_expect_success "$desc: $4 => $5" "test_cmp $5 $file"
+}
+
+test_expect_success 'setup' '
+	printf "1\\n2\\n" >lf &&
+	printf "1\\r\\n2\\r\\n" >crlf &&
+
+	echo "*.txt text" >.gitattributes &&
+	git add .gitattributes &&
+
+	mkdir autocrlf_false &&
+	cp lf crlf autocrlf_false/ &&
+	cp lf autocrlf_false/lf.txt &&
+	cp crlf autocrlf_false/crlf.txt &&
+	git -c core.autocrlf=false add autocrlf_false/ &&
+
+	mkdir autocrlf_true &&
+	cp lf crlf autocrlf_true/ &&
+	cp lf autocrlf_true/lf.txt &&
+	cp crlf autocrlf_true/crlf.txt &&
+	git -c core.autocrlf=true add autocrlf_true/ &&
+
+	git commit -m.
+'
+
+#	core.autocrlf	core.eol
+prepare	false		crlf
+prepare	true		crlf
+prepare	false		lf
+prepare	true		lf
+
+#		core.autocrlf	core.eol	original	expect
+#		(add)	(archive)
+expect_success	false	false	crlf		crlf		crlf
+expect_success	false	false	crlf		lf		lf
+expect_success	false	false	lf		crlf		crlf
+expect_success	false	false	lf		lf		lf
+expect_success	false	true	crlf		crlf		crlf
+expect_success	false	true	crlf		lf		crlf
+expect_success	false	true	lf		crlf		crlf
+expect_success	false	true	lf		lf		crlf
+expect_success	true	false	crlf		crlf		lf
+expect_success	true	false	crlf		lf		lf
+expect_success	true	false	lf		crlf		lf
+expect_success	true	false	lf		lf		lf
+expect_success	true	true	crlf		crlf		crlf
+expect_success	true	true	crlf		lf		crlf
+expect_success	true	true	lf		crlf		crlf
+expect_success	true	true	lf		lf		crlf
+
+expect_success	false	false	crlf		crlf.txt	crlf
+expect_success	false	false	crlf		lf.txt		crlf
+expect_success	false	false	lf		crlf.txt	lf
+expect_success	false	false	lf		lf.txt		lf
+expect_success	false	true	crlf		crlf.txt	crlf
+expect_success	false	true	crlf		lf.txt		crlf
+expect_success	false	true	lf		crlf.txt	crlf
+expect_success	false	true	lf		lf.txt		crlf
+expect_success	true	false	crlf		crlf.txt	crlf
+expect_success	true	false	crlf		lf.txt		crlf
+expect_success	true	false	lf		crlf.txt	lf
+expect_success	true	false	lf		lf.txt		lf
+expect_success	true	true	crlf		crlf.txt	crlf
+expect_success	true	true	crlf		lf.txt		crlf
+expect_success	true	true	lf		crlf.txt	crlf
+expect_success	true	true	lf		lf.txt		crlf
+
+test_done

Re: git-archive and core.eol

[Erik Faye-Lund]

On Sat, Jan 8, 2011 at 2:35 PM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
> Am 15.12.2010 23:32, schrieb Erik Faye-Lund:
>> I recently tried the following on Windows:
>>
>> $ git init
>> Initialized empty Git repository in c:/Users/kusma/test/.git/
>> $ echo "foo
>> bar" > test.txt
>> $ git -c core.autocrlf=true add test.txt
>> warning: LF will be replaced by CRLF in test.txt.
>> The file will have its original line endings in your working directory.
>> $ git commit -m.
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>  create mode 100644 test.txt
>> $ git -c core.autocrlf=true -c core.eol=lf archive --format=tar HEAD > test.tar
>> $ tar xvf test.tar
>> $ od -c test.txt
>> 0000000   f   o   o  \r  \n   b   a   r  \r  \n
>> 0000012
>>
>> Just to be sure, I checked this:
>>
>> $ git show HEAD:test.txt | od -c
>> 0000000   f   o   o  \n   b   a   r  \n
>> 0000010
>>
>> Yep, the file has LF in the repo, as expected... the warning from
>> git-add is a bit confusing, but OK.
>>
>> Hmm, so git-archive writes CRLF even if I said I wanted LF. But then I
>> tried this on Linux:
>>
>> $ git init
>> Initialized empty Git repository in /home/kusma/src/test/.git/
>> $ echo "foo
>> bar" > test.txt
>> $ git add test.txt
>> $ git commit -m.
>> [master (root-commit) c6f195e] .
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>  create mode 100644 test.txt
>> $ git -c core.autocrlf=true -c core.eol=crlf archive --format=tar HEAD
>>> test.tar
>> $ tar xvf test.tar
>> test.txt
>> $ od -c test.txt
>> 0000000   f   o   o  \r  \n   b   a   r  \r  \n
>> 0000012
>>
>> This leaves me a bit puzzled. On Linux, I can override the default
>> new-line style CRLF for git-archive, but I can't override it to LF on
>> Windows?
>>
>> I expected it to work because sha1_file_to_archive calls
>> convert_to_working_tree. I've tried stepping through the code, but I
>> don't quite understand where it goes wrong. Or even how the code is
>> supposed to work :P
>>
>> Does anyone have any clue what's going on? I'm running with the
>> current master, git version 1.7.3.3.585.g74f6e.
>
> I can't seem to replicate this (1.7.4-rc1); see below for the test script
> I tried to come up with.  It should test all combinations of the relevant
> config variables and the text attribute.  I cheated by simply setting the
> expectations to match the results on Linux; I didn't check if these are
> indeed the correct results.  The test passes for me on MinGW, too, though.
>
> Did I miss a variable or are some of the expectations wrong?
>
> Thanks,
> René
>


Really? I haven't looked through what the test actually does (I'm out
sick right now, and don't have many working brain-cells), but every
single test fails for me:

not ok - 1 setup
#	
#		printf "1\\n2\\n" >lf &&
#		printf "1\\r\\n2\\r\\n" >crlf &&
#	
#		echo "*.txt text" >.gitattributes &&
#		git add .gitattributes &&
#	
#		mkdir autocrlf_false &&
#		cp lf crlf autocrlf_false/ &&
#		cp lf autocrlf_false/lf.txt &&
#		cp crlf autocrlf_false/crlf.txt &&
#		git -c core.autocrlf=false add autocrlf_false/ &&
#	
#		mkdir autocrlf_true &&
#		cp lf crlf autocrlf_true/ &&
#		cp lf autocrlf_true/lf.txt &&
#		cp crlf autocrlf_true/crlf.txt &&
#		git -c core.autocrlf=true add autocrlf_true/ &&
#	
#		git commit -m.
#	
not ok - 2 archive with autocrlf=false eol=crlf
#	
#			git -c core.autocrlf=false -c core.eol=crlf archive HEAD
>autocrlf_false-eol_crlf.tar &&
#			(mkdir autocrlf_false-eol_crlf.d && cd autocrlf_false-eol_crlf.d
&& "tar" xf -) <autocrlf_false-eol_crlf.tar
#		
not ok - 3 archive with autocrlf=true eol=crlf
#	
#			git -c core.autocrlf=true -c core.eol=crlf archive HEAD
>autocrlf_true-eol_crlf.tar &&
#			(mkdir autocrlf_true-eol_crlf.d && cd autocrlf_true-eol_crlf.d &&
"tar" xf -) <autocrlf_true-eol_crlf.tar
#		
not ok - 4 archive with autocrlf=false eol=lf
#	
#			git -c core.autocrlf=false -c core.eol=lf archive HEAD
>autocrlf_false-eol_lf.tar &&
#			(mkdir autocrlf_false-eol_lf.d && cd autocrlf_false-eol_lf.d &&
"tar" xf -) <autocrlf_false-eol_lf.tar
#		
not ok - 5 archive with autocrlf=true eol=lf
#	
#			git -c core.autocrlf=true -c core.eol=lf archive HEAD
>autocrlf_true-eol_lf.tar &&
#			(mkdir autocrlf_true-eol_lf.d && cd autocrlf_true-eol_lf.d &&
"tar" xf -) <autocrlf_true-eol_lf.tar
#		
not ok - 6 add autocrlf=false, archive autocrlf=false eol=crlf: crlf => crlf
#	test_cmp crlf autocrlf_false-eol_crlf.d/autocrlf_false/crlf
not ok - 7 add autocrlf=false, archive autocrlf=false eol=crlf: lf => lf
#	test_cmp lf autocrlf_false-eol_crlf.d/autocrlf_false/lf
not ok - 8 add autocrlf=false, archive autocrlf=false eol=lf: crlf => crlf
#	test_cmp crlf autocrlf_false-eol_lf.d/autocrlf_false/crlf
not ok - 9 add autocrlf=false, archive autocrlf=false eol=lf: lf => lf
#	test_cmp lf autocrlf_false-eol_lf.d/autocrlf_false/lf
not ok - 10 add autocrlf=false, archive autocrlf=true eol=crlf: crlf => crlf
#	test_cmp crlf autocrlf_true-eol_crlf.d/autocrlf_false/crlf
not ok - 11 add autocrlf=false, archive autocrlf=true eol=crlf: lf => crlf
#	test_cmp crlf autocrlf_true-eol_crlf.d/autocrlf_false/lf
not ok - 12 add autocrlf=false, archive autocrlf=true eol=lf: crlf => crlf
#	test_cmp crlf autocrlf_true-eol_lf.d/autocrlf_false/crlf
not ok - 13 add autocrlf=false, archive autocrlf=true eol=lf: lf => crlf
#	test_cmp crlf autocrlf_true-eol_lf.d/autocrlf_false/lf
not ok - 14 add autocrlf=true, archive autocrlf=false eol=crlf: crlf => lf
#	test_cmp lf autocrlf_false-eol_crlf.d/autocrlf_true/crlf
not ok - 15 add autocrlf=true, archive autocrlf=false eol=crlf: lf => lf
#	test_cmp lf autocrlf_false-eol_crlf.d/autocrlf_true/lf
not ok - 16 add autocrlf=true, archive autocrlf=false eol=lf: crlf => lf
#	test_cmp lf autocrlf_false-eol_lf.d/autocrlf_true/crlf
not ok - 17 add autocrlf=true, archive autocrlf=false eol=lf: lf => lf
#	test_cmp lf autocrlf_false-eol_lf.d/autocrlf_true/lf
not ok - 18 add autocrlf=true, archive autocrlf=true eol=crlf: crlf => crlf
#	test_cmp crlf autocrlf_true-eol_crlf.d/autocrlf_true/crlf
not ok - 19 add autocrlf=true, archive autocrlf=true eol=crlf: lf => crlf
#	test_cmp crlf autocrlf_true-eol_crlf.d/autocrlf_true/lf
not ok - 20 add autocrlf=true, archive autocrlf=true eol=lf: crlf => crlf
#	test_cmp crlf autocrlf_true-eol_lf.d/autocrlf_true/crlf
not ok - 21 add autocrlf=true, archive autocrlf=true eol=lf: lf => crlf
#	test_cmp crlf autocrlf_true-eol_lf.d/autocrlf_true/lf
not ok - 22 add autocrlf=false, archive autocrlf=false eol=crlf:
crlf.txt => crlf
#	test_cmp crlf autocrlf_false-eol_crlf.d/autocrlf_false/crlf.txt
not ok - 23 add autocrlf=false, archive autocrlf=false eol=crlf: lf.txt => crlf
#	test_cmp crlf autocrlf_false-eol_crlf.d/autocrlf_false/lf.txt
not ok - 24 add autocrlf=false, archive autocrlf=false eol=lf: crlf.txt => lf
#	test_cmp lf autocrlf_false-eol_lf.d/autocrlf_false/crlf.txt
not ok - 25 add autocrlf=false, archive autocrlf=false eol=lf: lf.txt => lf
#	test_cmp lf autocrlf_false-eol_lf.d/autocrlf_false/lf.txt
not ok - 26 add autocrlf=false, archive autocrlf=true eol=crlf: crlf.txt => crlf
#	test_cmp crlf autocrlf_true-eol_crlf.d/autocrlf_false/crlf.txt
not ok - 27 add autocrlf=false, archive autocrlf=true eol=crlf: lf.txt => crlf
#	test_cmp crlf autocrlf_true-eol_crlf.d/autocrlf_false/lf.txt
not ok - 28 add autocrlf=false, archive autocrlf=true eol=lf: crlf.txt => crlf
#	test_cmp crlf autocrlf_true-eol_lf.d/autocrlf_false/crlf.txt
not ok - 29 add autocrlf=false, archive autocrlf=true eol=lf: lf.txt => crlf
#	test_cmp crlf autocrlf_true-eol_lf.d/autocrlf_false/lf.txt
not ok - 30 add autocrlf=true, archive autocrlf=false eol=crlf: crlf.txt => crlf
#	test_cmp crlf autocrlf_false-eol_crlf.d/autocrlf_true/crlf.txt
not ok - 31 add autocrlf=true, archive autocrlf=false eol=crlf: lf.txt => crlf
#	test_cmp crlf autocrlf_false-eol_crlf.d/autocrlf_true/lf.txt
not ok - 32 add autocrlf=true, archive autocrlf=false eol=lf: crlf.txt => lf
#	test_cmp lf autocrlf_false-eol_lf.d/autocrlf_true/crlf.txt
not ok - 33 add autocrlf=true, archive autocrlf=false eol=lf: lf.txt => lf
#	test_cmp lf autocrlf_false-eol_lf.d/autocrlf_true/lf.txt
not ok - 34 add autocrlf=true, archive autocrlf=true eol=crlf: crlf.txt => crlf
#	test_cmp crlf autocrlf_true-eol_crlf.d/autocrlf_true/crlf.txt
not ok - 35 add autocrlf=true, archive autocrlf=true eol=crlf: lf.txt => crlf
#	test_cmp crlf autocrlf_true-eol_crlf.d/autocrlf_true/lf.txt
not ok - 36 add autocrlf=true, archive autocrlf=true eol=lf: crlf.txt => crlf
#	test_cmp crlf autocrlf_true-eol_lf.d/autocrlf_true/crlf.txt
not ok - 37 add autocrlf=true, archive autocrlf=true eol=lf: lf.txt => crlf
#	test_cmp crlf autocrlf_true-eol_lf.d/autocrlf_true/lf.txt
# failed 37 among 37 test(s)
1..37

$ git --version
git version 1.7.4.rc1.3196.gfd693

(This is the current 'devel'-branch from
git://repo.or.cz/git/mingw/4msysgit.git)

Re: git-archive and core.eol

[René Scharfe]

Am 08.01.2011 18:28, schrieb Erik Faye-Lund:
> Really? I haven't looked through what the test actually does (I'm out
> sick right now, and don't have many working brain-cells), but every
> single test fails for me:
[...]
> $ git --version
> git version 1.7.4.rc1.3196.gfd693
> 
> (This is the current 'devel'-branch from
> git://repo.or.cz/git/mingw/4msysgit.git)

I cloned it, but even though it reports a different version string for
me we probably use the same (fd6937e0e6ccb78eb4347c427248e25c2d6739c8):

	$ ./git version
	git version 1.7.3.4.3902.gfd693

And all the tests succeed for me (on Windows Vista Home Premium x64)
with that one.

I'm especially interested in how the setup step manages to fail for you.
 But first, get well soon!

René

Re: git-archive and core.eol

[Erik Faye-Lund]

On Sun, Jan 9, 2011 at 1:52 PM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
> Am 08.01.2011 18:28, schrieb Erik Faye-Lund:
>> Really? I haven't looked through what the test actually does (I'm out
>> sick right now, and don't have many working brain-cells), but every
>> single test fails for me:
> [...]
>> $ git --version
>> git version 1.7.4.rc1.3196.gfd693
>>
>> (This is the current 'devel'-branch from
>> git://repo.or.cz/git/mingw/4msysgit.git)
>
> I cloned it, but even though it reports a different version string for
> me we probably use the same (fd6937e0e6ccb78eb4347c427248e25c2d6739c8):
>
>        $ ./git version
>        git version 1.7.3.4.3902.gfd693
>

This is probably just because you haven't pulled junio's repo
recently, which contains the 1.7.4.rc1 tag. The tip is the same,
indeed.

> And all the tests succeed for me (on Windows Vista Home Premium x64)
> with that one.
>

I'm on Vista 64 if that matters. And I'm using msysGit e59039e.

> I'm especially interested in how the setup step manages to fail for you.

It's the line "git add .gitattributes" is the first that fails in
'setup'. Actually, all git-commands seems to fail.

But now I also observe that just trying to run t0000-basic fails:

$ ./t0000-basic.sh
./t0000-basic.sh: line 24: ../git: is a directory
You do not seem to have built git yet.

Now this is suspicious:
$ ls ../git.exe
../git.exe*

$ ls ../git
Debug/  git.vcproj  git.vcproj.Hue-PC.kusma.user  git.wwdb

Aha! The MSVC project generator creates a folder called 'git' at the
root, so anything trying to execute '../git' fails!

$ ../git help
sh.exe": ../git: is a directory

After deleting that folder, t0000-basic passes again. As does your
test. So now I've got to figure out what is different between your
test and mine. Perhaps I misdiagnosed to begin with?

Re: git-archive and core.eol

[Erik Faye-Lund]

On Mon, Jan 10, 2011 at 1:11 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> test. So now I've got to figure out what is different between your
> test and mine. Perhaps I misdiagnosed to begin with?
>

No, it doesn't quite seem like I misdiagnosed, but your test had
different expectations than I have after reading the documentation. I
expected core.autocrlf=true + core.eol=lf to pretty much be identical
to core.autocrlf=false, but only because LF->LF conversion is a NOP.

'core.autocrlf' is documented as meaning the same as setting the
'text' attribute to 'auto' for all files, plus "files that contain
CRLF in the repository will not be touched". I figured that last part
shouldn't affect me as I only had LFs in the repository.

If I disable core.autocrlf, I get what I want (no matter what I set
core.eol to, it seems). But I still don't understand WHY
core.autocrlf=true + core.eol=lf outputs CRLF.

It seems to me that there's a big gap between what the documentation
claims and what actually happens here.

Re: git-archive and core.eol

[René Scharfe]

Am 10.01.2011 14:00, schrieb Erik Faye-Lund:
> On Mon, Jan 10, 2011 at 1:11 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>> test. So now I've got to figure out what is different between your
>> test and mine. Perhaps I misdiagnosed to begin with?
>>
> 
> No, it doesn't quite seem like I misdiagnosed, but your test had
> different expectations than I have after reading the documentation. I
> expected core.autocrlf=true + core.eol=lf to pretty much be identical
> to core.autocrlf=false, but only because LF->LF conversion is a NOP.
> 
> 'core.autocrlf' is documented as meaning the same as setting the
> 'text' attribute to 'auto' for all files, plus "files that contain
> CRLF in the repository will not be touched". I figured that last part
> shouldn't affect me as I only had LFs in the repository.
> 
> If I disable core.autocrlf, I get what I want (no matter what I set
> core.eol to, it seems). But I still don't understand WHY
> core.autocrlf=true + core.eol=lf outputs CRLF.
> 
> It seems to me that there's a big gap between what the documentation
> claims and what actually happens here.

Having stared a bit at the test results, I think you only need to accept
that setting core.autocrlf=true during output overrules any core.eol
setting and gives you CRLF line endings no matter what's in the repository.

core.autocrlf=input overrules core.eol, too, in that no output conversion
takes place, no matter what the latter is set to.

I don't know if this is intended or even useful -- I don't use the options
myself, so I don't grok the possible use cases.  Perhaps something like
this can help?  Or do we need code changes?


diff --git a/Documentation/config.txt b/Documentation/config.txt
index ff7c225..6082f77 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -202,7 +202,7 @@ core.eol::
 	'lf', 'crlf' and 'native', which uses the platform's native
 	line ending.  The default value is `native`.  See
 	linkgit:gitattributes[5] for more information on end-of-line
-	conversion.
+	conversion.  This variable is ignored if `core.autocrlf` is set.
 
 core.safecrlf::
 	If true, makes git check if converting `CRLF` is reversible when
@@ -257,7 +257,8 @@ core.autocrlf::
 	setting if you want to have `CRLF` line endings in your
 	working directory even though the repository does not have
 	normalized line endings.  This variable can be set to 'input',
-	in which case no output conversion is performed.
+	in which case no output conversion is performed.  This variable
+	overrules `core.eol`.
 
 core.symlinks::
 	If false, symbolic links are checked out as small plain files that