From: Erik Faye-Lund <hidden> Date: 2016-06-15 22:50:15
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.
From: René Scharfe <hidden> Date: 2016-06-15 22:50:21
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
quoted
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(-)
From: Erik Faye-Lund <hidden> Date: 2016-06-15 22:50:21
On Sat, Jan 8, 2011 at 2:35 PM, René Scharfe
[off-list ref] wrote:
Am 15.12.2010 23:32, schrieb Erik Faye-Lund:
quoted
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
quoted
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)
From: René Scharfe <hidden> Date: 2016-06-15 22:50:21
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é
From: Erik Faye-Lund <hidden> Date: 2016-06-15 22:50:21
On Sun, Jan 9, 2011 at 1:52 PM, René Scharfe
[off-list ref] wrote:
Am 08.01.2011 18:28, schrieb Erik Faye-Lund:
quoted
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:
[...]
quoted
$ 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?
From: Erik Faye-Lund <hidden> Date: 2016-06-15 22:50:21
On Mon, Jan 10, 2011 at 1:11 PM, Erik Faye-Lund [off-list ref] 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.
From: René Scharfe <hidden> Date: 2016-06-15 22:50:22
Am 10.01.2011 14:00, schrieb Erik Faye-Lund:
On Mon, Jan 10, 2011 at 1:11 PM, Erik Faye-Lund [off-list ref] wrote:
quoted
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?
@@ -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