* git-archive and core.eol
@ 2010-12-15 22:32 Erik Faye-Lund
2011-01-08 13:35 ` René Scharfe
0 siblings, 1 reply; 7+ messages in thread
From: Erik Faye-Lund @ 2010-12-15 22:32 UTC (permalink / raw)
To: Git Mailing List, msysGit; +Cc: eyvind.bernhardsen
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: git-archive and core.eol 2010-12-15 22:32 git-archive and core.eol Erik Faye-Lund @ 2011-01-08 13:35 ` René Scharfe 2011-01-08 17:28 ` Erik Faye-Lund 0 siblings, 1 reply; 7+ messages in thread From: René Scharfe @ 2011-01-08 13:35 UTC (permalink / raw) To: kusmabite; +Cc: Git Mailing List, msysGit, eyvind.bernhardsen 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: git-archive and core.eol 2011-01-08 13:35 ` René Scharfe @ 2011-01-08 17:28 ` Erik Faye-Lund 2011-01-09 12:52 ` René Scharfe 0 siblings, 1 reply; 7+ messages in thread From: Erik Faye-Lund @ 2011-01-08 17:28 UTC (permalink / raw) To: René Scharfe; +Cc: Git Mailing List, msysGit, eyvind.bernhardsen 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) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git-archive and core.eol 2011-01-08 17:28 ` Erik Faye-Lund @ 2011-01-09 12:52 ` René Scharfe 2011-01-10 12:11 ` Erik Faye-Lund 0 siblings, 1 reply; 7+ messages in thread From: René Scharfe @ 2011-01-09 12:52 UTC (permalink / raw) To: kusmabite; +Cc: Git Mailing List, msysGit, eyvind.bernhardsen 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é ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git-archive and core.eol 2011-01-09 12:52 ` René Scharfe @ 2011-01-10 12:11 ` Erik Faye-Lund 2011-01-10 13:00 ` Erik Faye-Lund 0 siblings, 1 reply; 7+ messages in thread From: Erik Faye-Lund @ 2011-01-10 12:11 UTC (permalink / raw) To: René Scharfe; +Cc: Git Mailing List, msysGit, eyvind.bernhardsen 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git-archive and core.eol 2011-01-10 12:11 ` Erik Faye-Lund @ 2011-01-10 13:00 ` Erik Faye-Lund 2011-01-11 19:24 ` René Scharfe 0 siblings, 1 reply; 7+ messages in thread From: Erik Faye-Lund @ 2011-01-10 13:00 UTC (permalink / raw) To: René Scharfe; +Cc: Git Mailing List, msysGit, eyvind.bernhardsen 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git-archive and core.eol 2011-01-10 13:00 ` Erik Faye-Lund @ 2011-01-11 19:24 ` René Scharfe 0 siblings, 0 replies; 7+ messages in thread From: René Scharfe @ 2011-01-11 19:24 UTC (permalink / raw) To: kusmabite; +Cc: Git Mailing List, msysGit, eyvind.bernhardsen 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-01-11 19:24 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-12-15 22:32 git-archive and core.eol Erik Faye-Lund 2011-01-08 13:35 ` René Scharfe 2011-01-08 17:28 ` Erik Faye-Lund 2011-01-09 12:52 ` René Scharfe 2011-01-10 12:11 ` Erik Faye-Lund 2011-01-10 13:00 ` Erik Faye-Lund 2011-01-11 19:24 ` René Scharfe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).