{"thread":{"id":"14603","subject":"[PATCH] Respect crlf attribute even if core.autocrlf has not been set","startedAt":"2008-07-22T21:56:04Z","lastAt":"2008-08-04T16:06:30Z","messageCount":58,"participants":["Johannes Schindelin","Dmitry Potapov","Junio C Hamano","Steffen Prohaska","Joshua Jensen","Avery Pennarun","Robin Rosenberg","Eyvind Bernhardsen","Tarmigan"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"84386","messageId":"alpine.DEB.1.00.0807222255450.8986@racer","threadId":"14603","inReplyTo":null,"subject":"[PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-22T21:56:04Z","receivedAt":"2008-07-22T21:56:04Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWhen a file's crlf attribute is explicitely set, it does not make sense\nto ignore it, just because the config variable core.autocrlf has not\nbeen set.\n\nThis patch does not affect the case when the crlf attribute is unset.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tThere have been no comments on this patch so far, however I think\n\tthat this is a valid fix which should be in 1.6.0.\n\n convert.c | 2 +-\n t/t0020-crlf.sh | 10 ++++++++++\n 2 files changed, 11 insertions(+), 1 deletions(-)\n\ndiff --git a/convert.c b/convert.c\nindex 78efed8..d038d2f 100644\n--- a/convert.c\n+++ b/convert.c\n@@ -126,7 +126,7 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n \tstruct text_stat stats;\n \tchar *dst;\n \n-\tif ((action == CRLF_BINARY) || !auto_crlf || !len)\n+\tif ((action == CRLF_BINARY) || (!auto_crlf && action < 0) || !len)\n \t\treturn 0;\n \n \tgather_stats(src, len, &stats);\ndiff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh\nindex 1be7446..0bb3e6f 100755\n--- a/t/t0020-crlf.sh\n+++ b/t/t0020-crlf.sh\n@@ -436,4 +436,14 @@ test_expect_success 'invalid .gitattributes (must not crash)' '\n \n '\n \n+test_expect_success 'attribute crlf is heeded even without core.autocrlf' '\n+\n+\techo \"allcrlf crlf=input\" > .gitattributes &&\n+\tgit config --unset core.autocrlf &&\n+\tgit add allcrlf &&\n+\tgit show :allcrlf | append_cr > expect &&\n+\ttest_cmp allcrlf expect\n+\n+'\n+\n test_done\n-- \n1.6.0.rc0.22.gf2096d.dirty\n"},{"id":"84396","messageId":"20080722231153.GN2925@dpotapov.dyndns.org","threadId":"14603","inReplyTo":"alpine.DEB.1.00.0807222255450.8986@racer","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-22T23:11:53Z","receivedAt":"2008-07-22T23:11:53Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, Jul 22, 2008 at 10:56:04PM +0100, Johannes Schindelin wrote:\n> \n> When a file's crlf attribute is explicitely set, it does not make sense\n> to ignore it, just because the config variable core.autocrlf has not\n> been set.\n\nHmm... About a week ago, I was about to propose the same change, but\nafter reading documentation and some thinking I was not able to convince\nmyself that this change would be the right thing to do.\n\nFirst, let's look at what Git's documentation says:\n\n===\n`crlf`\n^^^^^^\n\nThis attribute controls the line-ending convention.\n\nSet::\n\n\tSetting the `crlf` attribute on a path is meant to mark\n\tthe path as a \"text\" file. 'core.autocrlf' conversion\n\ttakes place without guessing the content type by\n\tinspection.\n\n\n\nThe `core.autocrlf` conversion\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nIf the configuration variable `core.autocrlf` is false, no\nconversion is done.\n===\n\nSo, my reading is that if I set the `crlf` attribute on some path, but\nI have core.autocrlf=false, there will be no conversion.\n\nAnd this can be used to mark text files in .gitattribute, which is\nstored in the repository and thus it is shared among users with\ndifferent end-of-line ending, i.e. you can have something like this\nin .gitattribute:\n\n*.[ch] crlf\n*.txt crlf\n\nbut on Unix, you have core.autocrlf=false, so no conversion is done,\nwhile, on Windows, you set core.autocrlf=true, so you will have crlf\nconversion without any guessing.\n\nNow, I can agree with you that using the 'crlf' attribute to mark text\nfiles may appear not very intuitive (you may expect that crlf means that\nthose files always need crlf conversion), but right now we do not have\nany better way to mark text files and the using crlf in this role is\nexplicitly suggested by documentation. See above.\n\n\n> diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh\n> index 1be7446..0bb3e6f 100755\n> --- a/t/t0020-crlf.sh\n> +++ b/t/t0020-crlf.sh\n> @@ -436,4 +436,14 @@ test_expect_success 'invalid .gitattributes (must not crash)' '\n> \n> '\n> \n> +test_expect_success 'attribute crlf is heeded even without core.autocrlf' '\n\ns/heeded/needed/\n\n\nDmitry\n"},{"id":"84399","messageId":"alpine.DEB.1.00.0807230019480.8986@racer","threadId":"14603","inReplyTo":"20080722231153.GN2925@dpotapov.dyndns.org","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-22T23:23:27Z","receivedAt":"2008-07-22T23:23:27Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 23 Jul 2008, Dmitry Potapov wrote:\n\n> On Tue, Jul 22, 2008 at 10:56:04PM +0100, Johannes Schindelin wrote:\n> > \n> > When a file's crlf attribute is explicitely set, it does not make \n> > sense to ignore it, just because the config variable core.autocrlf has \n> > not been set.\n> \n> Hmm... About a week ago, I was about to propose the same change, but \n> after reading documentation and some thinking I was not able to convince \n> myself that this change would be the right thing to do.\n\nWell, I have a shared repository, where I set the attribute. Now, every \nonce in a while, people check in text _with_ CR/LF. Yes, that is right, I \nmarked it explicitely as crlf, yet I am on the whim of the people choosing \nto set the config variable or not.\n\nAnd I could not care less what the documentation says: if it does not make \nsense, it does not make sense.\n\n> > +test_expect_success 'attribute crlf is heeded even without core.autocrlf' '\n> \n> s/heeded/needed/\n\nNope. \"heeded\" is what I meant. I am not a native speaker, so this could \nbe wrong. But \"needed\" is not what I meant (the sentence would not make \nsense with \"needed\").\n\nCiao,\nDscho\n"},{"id":"84410","messageId":"7vy73tihl6.fsf@gitster.siamese.dyndns.org","threadId":"14603","inReplyTo":"alpine.DEB.1.00.0807222255450.8986@racer","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-23T00:12:37Z","receivedAt":"2008-07-23T00:12:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> When a file's crlf attribute is explicitely set, it does not make sense\n> to ignore it, just because the config variable core.autocrlf has not\n> been set.\n\nI am not sure if I agree with that reasoning.\n\nAttribute defines what each path is. Is it a text file, is it a binary?\nThe nature of the contents does not change between people on POSIX and\nWindows, and that is why it is described in .gitattributes and cloned\nacross repositories.\n\nOn the other hand, the configuration defines what to do with contents with\nvarious attributes in this particular repository. Do I want to see a text\nfile checked out with CRLF endings, or LF?\n\nSo it is perfectly valid and normal for a cross-platform minded project to\nuse the crlf atttribute to say \"These files are text\" and expect them to\nbe checked out with LF endings on POSIX while making sure they are checked\nout with CRLF on Windows. Adding CR at the end of line for such files on\nPOSIX systems is positively a wrong thing to do in such a case.\n\nProjects like the kernel that originate from LF side of the world may not\nbother marking things as such, though.\n"},{"id":"84412","messageId":"20080723001445.GO2925@dpotapov.dyndns.org","threadId":"14603","inReplyTo":"alpine.DEB.1.00.0807230019480.8986@racer","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-23T00:14:45Z","receivedAt":"2008-07-23T00:14:45Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Jul 23, 2008 at 12:23:27AM +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 23 Jul 2008, Dmitry Potapov wrote:\n> \n> > On Tue, Jul 22, 2008 at 10:56:04PM +0100, Johannes Schindelin wrote:\n> > > \n> > > When a file's crlf attribute is explicitely set, it does not make \n> > > sense to ignore it, just because the config variable core.autocrlf has \n> > > not been set.\n> > \n> > Hmm... About a week ago, I was about to propose the same change, but \n> > after reading documentation and some thinking I was not able to convince \n> > myself that this change would be the right thing to do.\n> \n> Well, I have a shared repository, where I set the attribute. Now, every \n> once in a while, people check in text _with_ CR/LF. Yes, that is right, I \n> marked it explicitely as crlf, yet I am on the whim of the people choosing \n> to set the config variable or not.\n> \n> And I could not care less what the documentation says: if it does not make \n> sense, it does not make sense.\n\nIf you think that the current documentation does not make sense, why\ndon't you write something that will make sense? Really, the current\nbehavior may not be the best one, but at least it is consistent with\ndocumentation, while your change may confuse users, because they may\nexpect one behavior, but git will act differently.\n\nIf I understand your change correctly, you take into account the crlf\nattribute unconditionally only in worktree-to-git conversion, while you\nstill ignore it if core.autocrlf=false on checkout. Is it correct? If\nso, I think your patch does make sense, and it should not break anything\ntoo badly, because you still respect core.autocrlf on checkout, but you\nshould have said that in your commit message.\n\nDmitry\n"},{"id":"84423","messageId":"alpine.DEB.1.00.0807230203350.8986@racer","threadId":"14603","inReplyTo":"7vy73tihl6.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-23T01:10:07Z","receivedAt":"2008-07-23T01:10:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 22 Jul 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > When a file's crlf attribute is explicitely set, it does not make \n> > sense to ignore it, just because the config variable core.autocrlf has \n> > not been set.\n> \n> I am not sure if I agree with that reasoning.\n> \n> Attribute defines what each path is. Is it a text file, is it a binary? \n> The nature of the contents does not change between people on POSIX and \n> Windows, and that is why it is described in .gitattributes and cloned \n> across repositories.\n> \n> On the other hand, the configuration defines what to do with contents with\n> various attributes in this particular repository. Do I want to see a text\n> file checked out with CRLF endings, or LF?\n\nActually, I now see that I expressed myself badly. Extremely badly.\n\nThe whole issue is about _check in_, as can be seen from the test case I \nprovided.\n\nAnd I think it is even a bug in crlf handling, as gitattributes.txt has \nthis to say about crlf=input:\n\n This is similar to setting the attribute to `true`, but\n also forces git to act as if `core.autocrlf` is set to\n `input` for the path.\n\nIt suggests to this coder that core.autocrlf is not even looked at when \ncrlf=input.\n\n> So it is perfectly valid and normal for a cross-platform minded project \n> to use the crlf atttribute to say \"These files are text\" and expect them \n> to be checked out with LF endings on POSIX while making sure they are \n> checked out with CRLF on Windows. Adding CR at the end of line for such \n> files on POSIX systems is positively a wrong thing to do in such a case.\n> \n> Projects like the kernel that originate from LF side of the world may not\n> bother marking things as such, though.\n\nI fully agree.\n\nHowever, if you want to avoid CRs to _enter_ the repository, when you have \na lot of binary files tracked, you _do_ want to force all repositories to \ncrlf=input.\n\nNow, if you look at the patch, you will see that it _only_ touches \ncrlf_to_git(), but not only for crlf=input, but also for crlf=true.\n\nI maintain that this respects the law of least surprise, namely that if \nyou set the attribute crlf=true, and some person forgets to set \ncore.autocrlf=true, at _check in_ CRs are stripped, but at _check out_, no \nCR is added (as the person did not ask for core.autocrlf, but that should \nnot punish all the others who do not want to have CRs in the repository).\n\nBut yes, the commit message, and the oneline in particular are severely \nlacking.\n\nTomorrow,\nDscho\n"},{"id":"84430","messageId":"alpine.DEB.1.00.0807230229410.8986@racer","threadId":"14603","inReplyTo":"alpine.DEB.1.00.0807230203350.8986@racer","subject":"[PATCH] Respect crlf attribute in \"git add\" even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-23T01:31:38Z","receivedAt":"2008-07-23T01:31:38Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWhen a file's crlf attribute is explicitely set, it does not make sense\nto ignore it when adding the file, just because the config variable\ncore.autocrlf has not been set.\n\nThe alternative would be risking to get CR/LF files into the repository\njust because one user forgot to set core.autocrlf.\n\nThis patch does not affect the case when the crlf attribute is unset,\nor when checking files out.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOkay, so I lied and did not go to sleep (but that part comes \n\tnow). Only the wording in the commit message has changed.\n\n convert.c | 2 +-\n t/t0020-crlf.sh | 10 ++++++++++\n 2 files changed, 11 insertions(+), 1 deletions(-)\n\ndiff --git a/convert.c b/convert.c\nindex 78efed8..d038d2f 100644\n--- a/convert.c\n+++ b/convert.c\n@@ -126,7 +126,7 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n \tstruct text_stat stats;\n \tchar *dst;\n \n-\tif ((action == CRLF_BINARY) || !auto_crlf || !len)\n+\tif ((action == CRLF_BINARY) || (!auto_crlf && action < 0) || !len)\n \t\treturn 0;\n \n \tgather_stats(src, len, &stats);\ndiff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh\nindex 1be7446..0bb3e6f 100755\n--- a/t/t0020-crlf.sh\n+++ b/t/t0020-crlf.sh\n@@ -436,4 +436,14 @@ test_expect_success 'invalid .gitattributes (must not crash)' '\n \n '\n \n+test_expect_success 'attribute crlf is heeded even without core.autocrlf' '\n+\n+\techo \"allcrlf crlf=input\" > .gitattributes &&\n+\tgit config --unset core.autocrlf &&\n+\tgit add allcrlf &&\n+\tgit show :allcrlf | append_cr > expect &&\n+\ttest_cmp allcrlf expect\n+\n+'\n+\n test_done\n-- \n1.6.0.rc0.22.gf2096d.dirty\n"},{"id":"84438","messageId":"719E03C0-E8C3-4C35-AE9C-9BD5A7BCDF03@zib.de","threadId":"14603","inReplyTo":"alpine.DEB.1.00.0807230229410.8986@racer","subject":"Re: [PATCH] Respect crlf attribute in \"git add\" even if core.autocrlf has not been set","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-07-23T05:49:20Z","receivedAt":"2008-07-23T05:49:20Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 23, 2008, at 3:31 AM, Johannes Schindelin wrote:\n\n> When a file's crlf attribute is explicitely set, it does not make \n> sense\n> to ignore it when adding the file, just because the config variable\n> core.autocrlf has not been set.\n\nYour patch is not about core.autocrlf unset, but about \ncore.autocrlf=false.\nOn Unix, the two cases seem to be identical, but on Windows they are \nnot.\n(see below).\n\n\n> The alternative would be risking to get CR/LF files into the \n> repository\n> just because one user forgot to set core.autocrlf.\n\nGit could help the user *and* the maintainer of the repository if we\nchose core.autocrlf=input as the default on Unix. We would never\nlet CR/LF enter the repository unless explicitly requested to do so\nby core.autocrlf=false. This setting however would not be recommended\nto the average user.\n\nBut with Unix' default core.autocrlf=false, it makes sense to let the\nmaintainer of a repository enforce stripping CR from all files if not\nexplicitly configured otherwise for specific paths. Setting \n\"crlf=input\"\nin .gitattribute seems to be the documented way to do so --- although\nthe documentation in gitattributes.txt is a bit complex to read.\n\n\n> This patch does not affect the case when the crlf attribute is unset,\n> or when checking files out.\n>\n> Signed-off-by: Johannes Schindelin \n> ---\n>\n> \tOkay, so I lied and did not go to sleep (but that part comes\n> \tnow). Only the wording in the commit message has changed.\n>\n> convert.c | 2 +-\n> t/t0020-crlf.sh | 10 ++++++++++\n> 2 files changed, 11 insertions(+), 1 deletions(-)\n>\n> diff --git a/convert.c b/convert.c\n> index 78efed8..d038d2f 100644\n> --- a/convert.c\n> +++ b/convert.c\n> @@ -126,7 +126,7 @@ static int crlf_to_git(const char *path, const \n> char *src, size_t len,\n> \tstruct text_stat stats;\n> \tchar *dst;\n>\n> -\tif ((action == CRLF_BINARY) || !auto_crlf || !len)\n> +\tif ((action == CRLF_BINARY) || (!auto_crlf && action < 0) || !len)\n\nI think we should strictly follow the documentation, so this should read\n\n+ if ((action == CRLF_BINARY) || (!auto_crlf && action != \nCRLF_INPUT) || !len)\n\n\n\n>\n> \t\treturn 0;\n>\n> \tgather_stats(src, len, &stats);\n> diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh\n> index 1be7446..0bb3e6f 100755\n> --- a/t/t0020-crlf.sh\n> +++ b/t/t0020-crlf.sh\n> @@ -436,4 +436,14 @@ test_expect_success 'invalid .gitattributes \n> (must not crash)' '\n>\n> '\n>\n> +test_expect_success 'attribute crlf is heeded even without \n> core.autocrlf' '\n> +\n> +\techo \"allcrlf crlf=input\" > .gitattributes &&\n> +\tgit config --unset core.autocrlf &&\n\nYou should set core.autocrlf explicitly to false:\n\n git config core.autocrlf false\n\nOtherwise the test would pick up the user's global default.\n\n\n>\n> +\tgit add allcrlf &&\n> +\tgit show :allcrlf | append_cr > expect &&\n> +\ttest_cmp allcrlf expect\n> +\n> +'\n> +\n> test_done\n> -- \n> 1.6.0.rc0.22.gf2096d.dirty\n\n\n... and we should verify that we only treat crlf=input specially, but \nnot \"crlf\".\nThe following changes could be applied on top of yours. (Apologies if \nlines are\nwrapped. I am composing this mail with the wrong email client.)\n\n\ndiff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh\nindex b37059b..e51e810 100755\n--- a/t/t0020-crlf.sh\n+++ b/t/t0020-crlf.sh\n@@ -436,7 +436,7 @@ test_expect_success 'invalid .gitattributes (must \nnot crash)' '\n\n '\n\n-test_expect_success 'attribute crlf is heeded even without \ncore.autocrlf' '\n+test_expect_success 'attribute crlf=input is heeded even with \ncore.autocrlf=false' '\n\n echo \"allcrlf crlf=input\" > .gitattributes &&\n git config core.autocrlf false &&\n@@ -446,4 +446,15 @@ test_expect_success 'attribute crlf is heeded \neven without core.autocrlf' '\n\n '\n\n+test_expect_success 'attribute crlf is ignored with \ncore.autocrlf=false' '\n+\n+ echo \"allcrlf crlf\" > .gitattributes &&\n+ git config core.autocrlf false &&\n+ git read-tree --reset HEAD &&\n+ git add allcrlf &&\n+ git show :allcrlf > expect &&\n+ test_cmp allcrlf expect\n+\n+'\n+\n test_done\n"},{"id":"84448","messageId":"alpine.DEB.1.00.0807231051200.2830@eeepc-johanness","threadId":"14603","inReplyTo":"719E03C0-E8C3-4C35-AE9C-9BD5A7BCDF03@zib.de","subject":"Re: [PATCH] Respect crlf attribute in \"git add\" even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-23T09:02:08Z","receivedAt":"2008-07-23T09:02:08Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 23 Jul 2008, Steffen Prohaska wrote:\n\n> On Jul 23, 2008, at 3:31 AM, Johannes Schindelin wrote:\n> \n> >When a file's crlf attribute is explicitely set, it does not make sense \n> >to ignore it when adding the file, just because the config variable \n> >core.autocrlf has not been set.\n> \n> Your patch is not about core.autocrlf unset, but about \n> core.autocrlf=false.\n\nNo, no, no!\n\nIt is about autocrlf _unset_, i.e. when the user was _not_ explicit!\n\n> >The alternative would be risking to get CR/LF files into the repository \n> >just because one user forgot to set core.autocrlf.\n> \n> Git could help the user *and* the maintainer of the repository if we\n> chose core.autocrlf=input as the default on Unix.\n\nNO!\n\nThe machinery behind core.autocrlf _does_ slow down Git, even if only by a \nfew percent. But with patch queues as maintainers of busy projects \nencounter frequently, this makes a difference.\n\nSo no, I am _totally_ opposed to punishing Unix users for Windows' faults. \nTotally.\n\n> >diff --git a/convert.c b/convert.c\n> >index 78efed8..d038d2f 100644\n> >--- a/convert.c\n> >+++ b/convert.c\n> >@@ -126,7 +126,7 @@ static int crlf_to_git(const char *path, const char *src,\n> >size_t len,\n> > struct text_stat stats;\n> > char *dst;\n> >\n> >-\tif ((action == CRLF_BINARY) || !auto_crlf || !len)\n> >+\tif ((action == CRLF_BINARY) || (!auto_crlf && action < 0) || !len)\n> \n> I think we should strictly follow the documentation, so this should read\n> \n> + if ((action == CRLF_BINARY) || (!auto_crlf && action != CRLF_INPUT) ||\n> !len)\n\nNO!\n\nYour version would break action == CRLF_TEXT.\n\n> >diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh\n> >index 1be7446..0bb3e6f 100755\n> >--- a/t/t0020-crlf.sh\n> >+++ b/t/t0020-crlf.sh\n> >@@ -436,4 +436,14 @@ test_expect_success 'invalid .gitattributes (must not\n> >crash)' '\n> >\n> >'\n> >\n> >+test_expect_success 'attribute crlf is heeded even without core.autocrlf' '\n> >+\n> >+\techo \"allcrlf crlf=input\" > .gitattributes &&\n> >+\tgit config --unset core.autocrlf &&\n> \n> You should set core.autocrlf explicitly to false:\n> \n> git config core.autocrlf false\n\nBut this is _not_ what I want! I want it to be _unset_. Yes, at the \nmoment, auto_crlf is initialized to 0. But I do not _care_ what it is \nset. I want this test to succeed when the user did _not_ set autocrlf.\n\n> Otherwise the test would pick up the user's global default.\n\nIt will not. We went to great pains not to pick up global defaults in the \ntest suite.\n\n> ... and we should verify that we only treat crlf=input specially, but not\n> \"crlf\".\n\nUmm... Why? Why should a file marked \"crlf=true\" be allowed to be checked \nin _with_ CRs?\n\nCiao,\nDscho\n"},{"id":"84469","messageId":"20080723114022.GP2925@dpotapov.dyndns.org","threadId":"14603","inReplyTo":"719E03C0-E8C3-4C35-AE9C-9BD5A7BCDF03@zib.de","subject":"Re: [PATCH] Respect crlf attribute in \"git add\" even if core.autocrlf has not been set","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-23T11:40:22Z","receivedAt":"2008-07-23T11:40:22Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Jul 23, 2008 at 07:49:20AM +0200, Steffen Prohaska wrote:\n> \n> On Jul 23, 2008, at 3:31 AM, Johannes Schindelin wrote:\n> \n> >\n> >-\tif ((action == CRLF_BINARY) || !auto_crlf || !len)\n> >+\tif ((action == CRLF_BINARY) || (!auto_crlf && action < 0) || !len)\n> \n> I think we should strictly follow the documentation, so this should read\n> \n> + if ((action == CRLF_BINARY) || (!auto_crlf && action != \n> CRLF_INPUT) || !len)\n\nWell, your expression is correct if we choose to strictly follow to what\nthe current documentation says, but it is not well written in this place,\nand, more importantly, I don't see any use case where you would want to\nset crlf=input in .gitattributes, because it is shared among users on\ndifferent platforms. What you want to specify in it is whether a file is\ntext or binary. If crlf is set, it means a text file; if unset, it is a\nbinary file. Regardless of what autocrlf value, I don't see why a text\nfile should be checked in with CRs. So, Dscho's patch makes more sense\nto me. This requires correction to the documentation though:\n\ndiff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt\nindex d7b4114..448857b 100644\n--- a/Documentation/gitattributes.txt\n+++ b/Documentation/gitattributes.txt\n@@ -99,9 +99,9 @@ This attribute controls the line-ending convention.\n Set::\n \n \tSetting the `crlf` attribute on a path is meant to mark\n-\tthe path as a \"text\" file. 'core.autocrlf' conversion\n-\ttakes place without guessing the content type by\n-\tinspection.\n+\tthe path as a \"text\" file. Line endings in a text file\n+\tare converted to LF upon checkin, and if 'core.autocrlf'\n+\tis true then to CRLF upon checkout.\n \n Unset::\n \n\nDmitry\n"},{"id":"84550","messageId":"7vej5kfs0w.fsf@gitster.siamese.dyndns.org","threadId":"14603","inReplyTo":"alpine.DEB.1.00.0807230203350.8986@racer","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-23T17:07:43Z","receivedAt":"2008-07-23T17:07:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> However, if you want to avoid CRs to _enter_ the repository, when you have \n> a lot of binary files tracked, you _do_ want to force all repositories to \n> crlf=input.\n\nIf you are on a sane system, you do not even want to pay the price of\nconversion. Only people on systems with CRLF line endings should pay the\nprice (because your aim is to convert on such systems). Are we throwing\nthat out of the window when the project decides to use gitattributes?\n\nHow about setting autocrlf automatically on mingw/msys/cygwin versions,\nperhaps via templates or a patch to init-db? Would that, combined with\nuser education, be a viable alternative?\n"},{"id":"84557","messageId":"alpine.DEB.1.00.0807231817460.8986@racer","threadId":"14603","inReplyTo":"7vej5kfs0w.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-23T17:22:51Z","receivedAt":"2008-07-23T17:22:51Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 23 Jul 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > However, if you want to avoid CRs to _enter_ the repository, when you \n> > have a lot of binary files tracked, you _do_ want to force all \n> > repositories to crlf=input.\n> \n> If you are on a sane system, you do not even want to pay the price of \n> conversion. Only people on systems with CRLF line endings should pay \n> the price (because your aim is to convert on such systems). Are we \n> throwing that out of the window when the project decides to use \n> gitattributes?\n\nWell, if you do not want that, why do you set crlf in the gitattributes to \nbegin with?\n\n> How about setting autocrlf automatically on mingw/msys/cygwin versions, \n> perhaps via templates or a patch to init-db? Would that, combined with \n> user education, be a viable alternative?\n\nOn msys we do that. A few users decided they know better and switched it \noff. Me for example. But I wouldn't do something as stupid as editing a \nfile with an editor that tries to be helpful and adds CR/LFs.\n\nHowever, Cygwin? No, they don't. I don't see them change it, either.\n\nThe _only_ way we could do that is by setting auto_crlf in environment, \ndepending on the platform.\n\nHOWEVER: as you can see from the git-svn post this morning, there are \nknown issues with autocrlf.\n\nWe also had much fun (not!) with a lot of users who were really happy to \ninsult us for the change to set autocrlf to true by default (via \n/etc/gitconfig) in msysGit.\n\nCiao,\nDscho\n"},{"id":"84563","messageId":"488772BC.80207@workspacewhiz.com","threadId":"14603","inReplyTo":"alpine.DEB.1.00.0807231817460.8986@racer","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Joshua Jensen","fromEmail":"jjensen@workspacewhiz.com","sentAt":"2008-07-23T18:04:44Z","receivedAt":"2008-07-23T18:04:44Z","isPatch":true,"sender":{"key":"jjensen@workspacewhiz.com","avatar":"https://avatars.githubusercontent.com/u/111687?v=4"},"body":"----- Original Message -----\nFrom: Johannes Schindelin\nDate: 7/23/2008 11:22 AM\n> On msys we do that. A few users decided they know better and switched it \n> off. Me for example. But I wouldn't do something as stupid as editing a \n> file with an editor that tries to be helpful and adds CR/LFs.\n> \nThere are certain file formats, such as a Visual Studio .sln file, that \nMUST be CRLF. When a .sln file is not CRLF, Visual Studio refuses to \nread it. I want to be able to set into the committed .gitattributes \nfile the list of files that must be translated to the proper format \nregardless of the autocrlf setting. An example is below:\n\n*.bat crlf\n*.def crlf\n*.dsp crlf\n*.dsw crlf\n*.rc crlf\n*.sln crlf\n*.vcproj crlf\n*.vcp crlf\n*.vcw crlf\n\nI'm not sure your patch was intended to accomplish the forced crlf \nsettings above, but certainly, this functionality would be useful, if \nnot critical.\n\nThanks.\n\nJosh\n"},{"id":"84569","messageId":"32541b130807231133x37083278u1badd82b5c48e57b@mail.gmail.com","threadId":"14603","inReplyTo":"488772BC.80207@workspacewhiz.com","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-23T18:33:54Z","receivedAt":"2008-07-23T18:33:54Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/23/08, Joshua Jensen wrote:\n> There are certain file formats, such as a Visual Studio .sln file, that\n> MUST be CRLF. [...]\n\nIt seems like what people really want is some additional file attributes:\n\n1. always CRLF on all platforms (eg. for .bat files)\n2. always LF on all platforms (eg. for shell scripts and perl scripts)\n3. just leave it alone no matter what (eg. for binary files)\n4. convert line endings to LF on checkin, native on checkout (eg. for\nmost source files)\n\nWhere \"native\" is defined by some config option, but the choice of #1\nthrough #4 is defined by .gitattributes. Thus, the config option\naffects only mode #4 (and perhaps the default mode, as it does now).\n\nThe current system works for #3. With Dscho's patch, #4 works too. I\nthink more kinds of per-file attributes are needed in order to get #1\nand #2.\n\nAvery\n"},{"id":"84573","messageId":"alpine.DEB.1.00.0807231956280.8986@racer","threadId":"14603","inReplyTo":"32541b130807231133x37083278u1badd82b5c48e57b@mail.gmail.com","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-23T18:57:29Z","receivedAt":"2008-07-23T18:57:29Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 23 Jul 2008, Avery Pennarun wrote:\n\n> 1. always CRLF on all platforms (eg. for .bat files)\n> 2. always LF on all platforms (eg. for shell scripts and perl scripts)\n> 3. just leave it alone no matter what (eg. for binary files)\n\nThese are not different, but equal. \"Do no harm to the contents of this \nfile\".\n\nHth,\nDscho\n"},{"id":"84598","messageId":"FB7ABDC5-8505-4FD1-8082-9BB5013E73C6@orakel.ntnu.no","threadId":"14603","inReplyTo":"alpine.DEB.1.00.0807231956280.8986@racer","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind-git@orakel.ntnu.no","sentAt":"2008-07-23T19:20:48Z","receivedAt":"2008-07-23T19:20:48Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 23. juli. 2008, at 20.57, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Wed, 23 Jul 2008, Avery Pennarun wrote:\n>\n>> 1. always CRLF on all platforms (eg. for .bat files)\n>> 2. always LF on all platforms (eg. for shell scripts and perl \n>> scripts)\n>> 3. just leave it alone no matter what (eg. for binary files)\n>\n> These are not different, but equal. \"Do no harm to the contents of \n> this\n> file\".\n\nThat is only true until someone edits the file in an editor which \nprefers the wrong end-of-line marker, and converts to it when saving. \nIt will be obvious that this has happened if the user does a \"git \ndiff\" before committing, but I think the intent of nos. 1 and 2 is for \ngit to automatically convert the line endings back instead of kicking \nup a fuss.\n\nMight be too magical, though.\n\nEyvind Bernhardsen\n"},{"id":"84587","messageId":"200807232122.38471.robin.rosenberg.lists@dewire.com","threadId":"14603","inReplyTo":"488772BC.80207@workspacewhiz.com","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2008-07-23T19:22:38Z","receivedAt":"2008-07-23T19:22:38Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"onsdagen den 23 juli 2008 20.04.44 skrev Joshua Jensen:\n> ----- Original Message -----\n> From: Johannes Schindelin\n> Date: 7/23/2008 11:22 AM\n> > On msys we do that. A few users decided they know better and switched it \n> > off. Me for example. But I wouldn't do something as stupid as editing a \n> > file with an editor that tries to be helpful and adds CR/LFs.\n> > \n> There are certain file formats, such as a Visual Studio .sln file, that \n> MUST be CRLF. When a .sln file is not CRLF, Visual Studio refuses to \n> read it. I want to be able to set into the committed .gitattributes \n> file the list of files that must be translated to the proper format \n> regardless of the autocrlf setting. An example is below:\n> \n> *.bat crlf\n> *.def crlf\n> *.dsp crlf\n> *.dsw crlf\n> *.rc crlf\n> *.sln crlf\n> *.vcproj crlf\n> *.vcp crlf\n> *.vcw crlf\n\nWouldn't \"*bat -crlf \" etc be good for these, and thus store CRLF in the repo.\n\n-- robin\n"},{"id":"84586","messageId":"7vhcagcsmj.fsf@gitster.siamese.dyndns.org","threadId":"14603","inReplyTo":"alpine.DEB.1.00.0807231817460.8986@racer","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-23T19:23:00Z","receivedAt":"2008-07-23T19:23:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Wed, 23 Jul 2008, Junio C Hamano wrote:\n> ...\n>> If you are on a sane system, you do not even want to pay the price of \n>> conversion. Only people on systems with CRLF line endings should pay \n>> the price (because your aim is to convert on such systems). Are we \n>> throwing that out of the window when the project decides to use \n>> gitattributes?\n>\n> Well, if you do not want that, why do you set crlf in the gitattributes to \n> begin with?\n\nIt is not _me_ but the project upstream that needs to interact also with\nWindows people who manages gitattributes. And me personally knows my\neditors are not helpful to add CR at the end of lines, so I do not need\nthe conversion.\n\nThat was the situation I had in mind.\n"},{"id":"84589","messageId":"37fcd2780807231233o6e71303doeea53c8f4e5aab67@mail.gmail.com","threadId":"14603","inReplyTo":"488772BC.80207@workspacewhiz.com","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-23T19:33:36Z","receivedAt":"2008-07-23T19:33:36Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Jul 23, 2008 at 10:04 PM, Joshua Jensen\n wrote:\n>\n> There are certain file formats, such as a Visual Studio .sln file, that MUST\n> be CRLF. When a .sln file is not CRLF, Visual Studio refuses to read it.\n\nI wonder what exactly version of Visual Studio you use? All version that\nI have seen had no problem reading .sln with LF ending, though they always\nwrote it back with CRLF. In any case, you can define as binary, so Git will\nnot do anything about their EOLs.\n\nDmitry\n"},{"id":"84591","messageId":"7vd4l4cs24.fsf@gitster.siamese.dyndns.org","threadId":"14603","inReplyTo":"200807232122.38471.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-23T19:35:15Z","receivedAt":"2008-07-23T19:35:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robin Rosenberg writes:\n\n>> There are certain file formats, such as a Visual Studio .sln file, that \n>> MUST be CRLF. When a .sln file is not CRLF, Visual Studio refuses to \n>> read it. I want to be able to set into the committed .gitattributes \n>> file the list of files that must be translated to the proper format \n>> regardless of the autocrlf setting. An example is below:\n>> \n>> *.bat crlf\n>...\n>> *.vcw crlf\n>\n> Wouldn't \"*bat -crlf \" etc be good for these, and thus store CRLF in the repo.\n\nI'd agree. And I do not think we would want to introduce \"crlf=force\"\nthat converts working tree files that could be LF terminated to CRLF upon\nchecking in. That is as bad as some helpful editors that adds CR at the\nend of line without being asked.\n"},{"id":"84594","messageId":"alpine.DEB.1.00.0807232040320.8986@racer","threadId":"14603","inReplyTo":"7vd4l4cs24.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-23T19:41:48Z","receivedAt":"2008-07-23T19:41:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 23 Jul 2008, Junio C Hamano wrote:\n\n> Robin Rosenberg writes:\n> \n> >> There are certain file formats, such as a Visual Studio .sln file, \n> >> that MUST be CRLF. When a .sln file is not CRLF, Visual Studio \n> >> refuses to read it. I want to be able to set into the committed \n> >> .gitattributes file the list of files that must be translated to the \n> >> proper format regardless of the autocrlf setting. An example is \n> >> below:\n> >> \n> >> *.bat crlf\n> >...\n> >> *.vcw crlf\n> >\n> > Wouldn't \"*bat -crlf \" etc be good for these, and thus store CRLF in \n> > the repo.\n> \n> I'd agree. And I do not think we would want to introduce \"crlf=force\" \n> that converts working tree files that could be LF terminated to CRLF \n> upon checking in. That is as bad as some helpful editors that adds CR \n> at the end of line without being asked.\n\nYou can say that only because you are not in the situation having a lot of \nCR/LF files in your _public_ repository _in spite of_ setting the \ngitattributes correctly.\n\nThat seriously sucks.\n\nCiao,\nDscho\n"},{"id":"84595","messageId":"alpine.DEB.1.00.0807232041570.8986@racer","threadId":"14603","inReplyTo":"FB7ABDC5-8505-4FD1-8082-9BB5013E73C6@orakel.ntnu.no","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-23T19:44:21Z","receivedAt":"2008-07-23T19:44:21Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 23 Jul 2008, Eyvind Bernhardsen wrote:\n\n> On 23. juli. 2008, at 20.57, Johannes Schindelin wrote:\n> \n> >On Wed, 23 Jul 2008, Avery Pennarun wrote:\n> >\n> > >1. always CRLF on all platforms (eg. for .bat files)\n> > >2. always LF on all platforms (eg. for shell scripts and perl scripts)\n> > >3. just leave it alone no matter what (eg. for binary files)\n> >\n> >These are not different, but equal. \"Do no harm to the contents of this\n> >file\".\n> \n> That is only true until someone edits the file in an editor which \n> prefers the wrong end-of-line marker, and converts to it when saving. \n> It will be obvious that this has happened if the user does a \"git diff\" \n> before committing, but I think the intent of nos. 1 and 2 is for git to \n> automatically convert the line endings back instead of kicking up a \n> fuss.\n> \n> Might be too magical, though.\n\nI deem it not, uhm, magical. By your reasoning there should be a way for \nGit to convert a file to UTF-8 when some entertaining person converted the \nworking directory file to ISO-8859-15.\n\nReally, either it is CR/LF on all platforms (and then the project members \nhave to live by it), or it is not. You cannot have both.\n\nIf it is CR/LF on all platforms, you just _commit_ it as CR/LF. No \nconversion, not even a brain required.\n\nCiao,\nDscho\n"},{"id":"84600","messageId":"alpine.DEB.1.00.0807232105470.8986@racer","threadId":"14603","inReplyTo":"7vhcagcsmj.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-23T20:07:10Z","receivedAt":"2008-07-23T20:07:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 23 Jul 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Wed, 23 Jul 2008, Junio C Hamano wrote:\n> > ...\n> >> If you are on a sane system, you do not even want to pay the price of \n> >> conversion. Only people on systems with CRLF line endings should pay \n> >> the price (because your aim is to convert on such systems). Are we \n> >> throwing that out of the window when the project decides to use \n> >> gitattributes?\n> >\n> > Well, if you do not want that, why do you set crlf in the \n> > gitattributes to begin with?\n> \n> It is not _me_ but the project upstream that needs to interact also with \n> Windows people who manages gitattributes. And me personally knows my \n> editors are not helpful to add CR at the end of lines, so I do not need \n> the conversion.\n\nI know you do. And I know those users don't. They do not even know that \nthey should set autocrlf = input in their cygwin Git.\n\nOr at least, now they do. After a few hundred commits that have been \npublished _after_ their broken checkins.\n\nSigh,\nDscho\n"},{"id":"84674","messageId":"FCAEAB20-750E-47B9-B58D-9BB0CB1EEAFF@zib.de","threadId":"14603","inReplyTo":"20080723114022.GP2925@dpotapov.dyndns.org","subject":"Re: [PATCH] Respect crlf attribute in \"git add\" even if core.autocrlf has not been set","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-07-24T06:06:29Z","receivedAt":"2008-07-24T06:06:29Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 23, 2008, at 1:40 PM, Dmitry Potapov wrote:\n\n> On Wed, Jul 23, 2008 at 07:49:20AM +0200, Steffen Prohaska wrote:\n>>\n>> On Jul 23, 2008, at 3:31 AM, Johannes Schindelin wrote:\n>>\n>>>\n>>> -\tif ((action == CRLF_BINARY) || !auto_crlf || !len)\n>>> +\tif ((action == CRLF_BINARY) || (!auto_crlf && action < 0) || !len)\n>>\n>> I think we should strictly follow the documentation, so this should \n>> read\n>>\n>> + if ((action == CRLF_BINARY) || (!auto_crlf && action !=\n>> CRLF_INPUT) || !len)\n>\n> Well, your expression is correct if we choose to strictly follow to \n> what\n> the current documentation says, but it is not well written in this \n> place,\n> and, more importantly, I don't see any use case where you would want \n> to\n> set crlf=input in .gitattributes, because it is shared among users on\n> different platforms. What you want to specify in it is whether a \n> file is\n> text or binary. If crlf is set, it means a text file; if unset, it \n> is a\n> binary file. Regardless of what autocrlf value, I don't see why a text\n> file should be checked in with CRs. So, Dscho's patch makes more sense\n> to me. This requires correction to the documentation though:\n\nOk, this and Dscho's earlier mail convinced me. My patch does not\nmake sense at all. I should have had thought a bit harder ;-)\n\nI have however a related question:\n\nDscho,\nIs the following your use case?\n\n \"I am the maintainer of this project. I know that this project needs\n crlf conversion, because it is a cross-platform project. Therefore,\n I want to force crlf conversion for this specific project, even if\n the user did not configure core.autocrlf=input on Unix.\"\n\nYour patch provides a solution, though not a very comfortable one. With\nyour patch applied, you could explicitly list all files (or filetypes)\nthat are text and mark them with 'crlf'. Git would not let CRLFs enter\nthe repository for these files. You could also specify 'crlf=input',\nbut I don't understand why you want to specify this. Anyway, you would\nneed to explicitly list all text filetypes and explicitly *not list* the\nbinary filetypes because they must not be converted. This is no very\ncomfortable, no?\n\nI think what you really want to do is to tell git that the *automatic*\ncrlf detection shall be used for all files of your specific project,\neven if the user did not configure core.autocrlf=input. This would\navoid listing each filetype separately.\n\nMaybe we could allow 'crlf=guess' in .gitattributes with the following\ndocumentation:\n\n-- 8< --\nSet to string value \"guess\"::\n\n\tSetting `guess` tells git to apply conversion upon checkin\n if the file content looks like text. On checkout, however,\n git applies the conversion specified in `core.autocrlf`.\n Setting `guess` can be useful to force automatic file type\n detection for a specific project.\n-- >8 --\n\n\n> diff --git a/Documentation/gitattributes.txt b/Documentation/ \n> gitattributes.txt\n> index d7b4114..448857b 100644\n> --- a/Documentation/gitattributes.txt\n> +++ b/Documentation/gitattributes.txt\n> @@ -99,9 +99,9 @@ This attribute controls the line-ending convention.\n> Set::\n>\n> \tSetting the `crlf` attribute on a path is meant to mark\n> -\tthe path as a \"text\" file. 'core.autocrlf' conversion\n> -\ttakes place without guessing the content type by\n> -\tinspection.\n> +\tthe path as a \"text\" file. Line endings in a text file\n> +\tare converted to LF upon checkin, and if 'core.autocrlf'\n> +\tis true then to CRLF upon checkout.\n>\n> Unset::\n\nMakes sense.\n\n\tSteffen\n"},{"id":"84707","messageId":"alpine.DEB.1.00.0807241334340.8986@racer","threadId":"14603","inReplyTo":"FCAEAB20-750E-47B9-B58D-9BB0CB1EEAFF@zib.de","subject":"Re: [PATCH] Respect crlf attribute in \"git add\" even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-24T12:39:34Z","receivedAt":"2008-07-24T12:39:34Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 24 Jul 2008, Steffen Prohaska wrote:\n\n> Dscho,\n> Is the following your use case?\n> \n> \"I am the maintainer of this project. I know that this project needs\n> crlf conversion, because it is a cross-platform project. Therefore,\n> I want to force crlf conversion for this specific project, even if\n> the user did not configure core.autocrlf=input on Unix.\"\n\nNo.\n\nMy use case is this: a few users work on Windows (Cygwin), others on \nMacOSX, yet others on Linux.\n\nWe often integrate files from somewhere else, and them Windows guys love \nto edit their files with their anachronistic proprietary crap tools that \nadd CRs where CRs no belongee.\n\nAlso, the Windows guys (being Windows guys) cannot be bothered to read \ndocumentation, so they did not set autocrlf.\n\n> Your patch provides a solution, though not a very comfortable one. With\n> your patch applied, you could explicitly list all files (or filetypes)\n> that are text and mark them with 'crlf'.\n\nWhy should I want to do that? I do not _want_ CRs. And them Windows guys \ndo not need them either; they are often not even aware that their crap \ntools introduce them.\n\n> You could also specify 'crlf=input', but I don't understand why you want \n> to specify this.\n\nThat's what I do. And _I_ need to understand why ;-)\n\nWell, seems I will just continue shouting \"why did you commit that \nCR-ridden file?\" and get shouted back with \"why does this §&%&%&!° Git \ntool not fix it for me automatically? Even _Subversion_ can do it.\"\n\nCiao,\nDscho"},{"id":"84720","messageId":"20080724140959.GU2925@dpotapov.dyndns.org","threadId":"14603","inReplyTo":"FCAEAB20-750E-47B9-B58D-9BB0CB1EEAFF@zib.de","subject":"Re: [PATCH] Respect crlf attribute in \"git add\" even if core.autocrlf has not been set","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-24T14:09:59Z","receivedAt":"2008-07-24T14:09:59Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Thu, Jul 24, 2008 at 08:06:29AM +0200, Steffen Prohaska wrote:\n> \n> I have however a related question:\n> \n> Dscho,\n> Is the following your use case?\n> \n> \"I am the maintainer of this project. I know that this project needs\n> crlf conversion, because it is a cross-platform project. Therefore,\n> I want to force crlf conversion for this specific project, even if\n> the user did not configure core.autocrlf=input on Unix.\"\n\nI suspect that most problems with crlf is caused by Windows users who\nhave core.autocrlf=false for whatever reason (I suspect without a good\nreason in most cases). But perhaps having core.autocrlf=input as default\non Unix and Mac will be better than the current core.autocrlf=false.\n\n> Maybe we could allow 'crlf=guess' in .gitattributes with the following\n> documentation:\n\nPlease, no. It feels wrong to complicate crlf settings to workaround\nincorrect user configuration. I don't think that many people really will\nbe able to benefit from that. In most cases, people end up with the\nincorrect value autocrlf just because the documentation is complicated\nand it is difficult to understand from it what autocrlf does.\n\nSo I believe the real solution is providing more reasonable defaults\nfor autocrlf and more clear and simple explanation, i.e. to have\nsomething like in the introduction section describing how to set up\nyour own repository:\n\n===\nIf you work on Windows, you are most likely use text files with CRLF\nendings. To ensure that your line endings will be correctly represented\non other platforms, you should set core.autocrlf=true.\n\nIf you prefer to have LF endings in your text files, you may want to set\ncore.autocrlf=input to ensure that files with inconsistent end-of-lines\nwill not enter into your repository.\n\nautocrlf conversion will automatically detect text files and convert\nline endings accordingly to the specified settings. In very rare cases,\nheuristic may be wrong[*], so you may want to specify what files should\nbed considered as text and what as binary explicitly. You can do that by\nsetting the crlf attribute in .gitattributes, like this:\n\n*.exe -crlf\n*.c crlf\n\nThe above says that all files with the .exe extension should be treated\nas binary and all files with the .c extension should treated as text.\n\n[*] You do not have to worry too much about heuristic being wrong,\nbecause you will be warned if conversion for a file is irreversible.\nSee core.safecrlf in linkgit:gitattributes[5] for more information.\n===\n\nWe should not expect every users to read everything written in\ngitattributes just to get autocrlf correctly.\n\nDmitry\n"},{"id":"84722","messageId":"alpine.DEB.1.00.0807241537000.8986@racer","threadId":"14603","inReplyTo":"20080724140959.GU2925@dpotapov.dyndns.org","subject":"Re: [PATCH] Respect crlf attribute in \"git add\" even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-24T14:38:39Z","receivedAt":"2008-07-24T14:38:39Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 24 Jul 2008, Dmitry Potapov wrote:\n\n> On Thu, Jul 24, 2008 at 08:06:29AM +0200, Steffen Prohaska wrote:\n> > \n> > I am the maintainer of this project. I know that this project needs \n> > crlf conversion, because it is a cross-platform project. \n> > Therefore, I want to force crlf conversion for this specific \n> > project, even if the user did not configure core.autocrlf=input on \n> > Unix.\n> \n> I suspect that most problems with crlf is caused by Windows users who \n> have core.autocrlf=false for whatever reason (I suspect without a good \n> reason in most cases).\n\nAlmost correct. It is _unset_! And it should be perfectly valid for \nusers not having to set anything there.\n\n> But perhaps having core.autocrlf=input as default on Unix and Mac will \n> be better than the current core.autocrlf=false.\n\nHave you read Junio's reply? If so, how can you suggest any change for \nUnix and Mac?\n\nCiao,\nDscho\n"},{"id":"84727","messageId":"465DE5CD-DA13-42B4-B0D8-961F3D118F59@zib.de","threadId":"14603","inReplyTo":"alpine.DEB.1.00.0807241537000.8986@racer","subject":"Re: [PATCH] Respect crlf attribute in \"git add\" even if core.autocrlf has not been set","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-07-24T14:52:05Z","receivedAt":"2008-07-24T14:52:05Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 24, 2008, at 4:38 PM, Johannes Schindelin wrote:\n\n> On Thu, 24 Jul 2008, Dmitry Potapov wrote:\n>\n>> On Thu, Jul 24, 2008 at 08:06:29AM +0200, Steffen Prohaska wrote:\n>>>\n>>> I am the maintainer of this project. I know that this project \n>>> needs\n>>> crlf conversion, because it is a cross-platform project.\n>>> Therefore, I want to force crlf conversion for this specific\n>>> project, even if the user did not configure core.autocrlf=input on\n>>> Unix.\n>>\n>> I suspect that most problems with crlf is caused by Windows users who\n>> have core.autocrlf=false for whatever reason (I suspect without a \n>> good\n>> reason in most cases).\n>\n> Almost correct. It is _unset_! And it should be perfectly valid for\n> users not having to set anything there.\n\nWhy is it unset? Since 1.5.5, our installer sets core.autocrlf=true\non Windows. So we *do* set a sane default for Windows users.\n\nIn the projects I am using git, the problematic platform is *Unix*.\nTo work around the default on Unix (core.autocrlf=false), I deliver\na custom script to our developers that verifies the setup on Unix and\ncomplains if core.autocrlf is not set to \"input\". Since I do this,\nI haven't seen any further problems.\n\n\tSteffen\n"},{"id":"84738","messageId":"32541b130807240944s6b4abd60j4ff95eccf7017770@mail.gmail.com","threadId":"14603","inReplyTo":"465DE5CD-DA13-42B4-B0D8-961F3D118F59@zib.de","subject":"Re: [PATCH] Respect crlf attribute in \"git add\" even if core.autocrlf has not been set","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-24T16:44:33Z","receivedAt":"2008-07-24T16:44:33Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/24/08, Steffen Prohaska wrote:\n> Why is it unset? Since 1.5.5, our installer sets core.autocrlf=true\n> on Windows. So we *do* set a sane default for Windows users.\n\nWell, if you've been following the thread, not everyone uses msysGit,\nand cygwin Git doesn't set autocrlf by default, and changing such\nthings behind people's backs can be really nasty.\n\nSo I can't decide if I mean the following as a joke or not ;)\n\ndiff --git a/builtin-init-db.c b/builtin-init-db.c\nindex 38b4fcb..91b79dd 100644\n--- a/builtin-init-db.c\n+++ b/builtin-init-db.c\n@@ -314,10 +314,19 @@ int init_db(const char *template_dir, unsigned int flags)\n \t}\n\n \tif (!(flags & INIT_DB_QUIET))\n+\t{\n \t\tprintf(\"%s%s Git repository in %s/\\n\",\n \t\t reinit ? \"Reinitialized existing\" : \"Initialized empty\",\n \t\t shared_repository ? \" shared\" : \"\",\n \t\t get_git_dir());\n+#ifdef _WIN32\n+\t\tif (!auto_crlf)\n+\t\t\tprintf(\"WARNING: You're using Windows but core.autocrlf is not set!\\n\");\n+#else\n+\t\tif (auto_crlf)\n+\t\t\tprintf(\"WARNING: You're not using Windows but core.autocrlf is set!\\n\");\n+#endif\n+\t}\n\n \treturn 0;\n }\n"},{"id":"84739","messageId":"alpine.DEB.1.00.0807241742220.8986@racer","threadId":"14603","inReplyTo":"465DE5CD-DA13-42B4-B0D8-961F3D118F59@zib.de","subject":"Re: [PATCH] Respect crlf attribute in \"git add\" even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-24T16:45:07Z","receivedAt":"2008-07-24T16:45:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 24 Jul 2008, Steffen Prohaska wrote:\n\n> On Jul 24, 2008, at 4:38 PM, Johannes Schindelin wrote:\n> \n> >On Thu, 24 Jul 2008, Dmitry Potapov wrote:\n> >\n> > >On Thu, Jul 24, 2008 at 08:06:29AM +0200, Steffen Prohaska wrote:\n> > > >\n> > > > I am the maintainer of this project. I know that this project \n> > > > needs crlf conversion, because it is a cross-platform project. \n> > > > Therefore, I want to force crlf conversion for this specific \n> > > > project, even if the user did not configure core.autocrlf=input on \n> > > > Unix.\n> > >\n> > >I suspect that most problems with crlf is caused by Windows users who \n> > >have core.autocrlf=false for whatever reason (I suspect without a \n> > >good reason in most cases).\n> >\n> >Almost correct. It is _unset_! And it should be perfectly valid for \n> >users not having to set anything there.\n> \n> Why is it unset? Since 1.5.5, our installer sets core.autocrlf=true\n> on Windows. So we *do* set a sane default for Windows users.\n\nAs I mentioned earlier, these users use Cygwin's Git. And they do not \nupdate frequently.\n\n> In the projects I am using git, the problematic platform is *Unix*. To \n> work around the default on Unix (core.autocrlf=false), I deliver a \n> custom script to our developers that verifies the setup on Unix and \n> complains if core.autocrlf is not set to \"input\". Since I do this, I \n> haven't seen any further problems.\n\nThat is exactly the use case I had in mind for my patch. If we already \nbother to mark the files with crlf=input in .gitattributes, then Git could \nbe so nice to respect it.\n\nHowever, I see Junio's point: on sane platforms you have to work hard to \nget CR-damaged files. And the regular sane platform user should not be \npunished for the brain/CR damage a certain monopolist has brought over \nthis planet.\n\nCiao,\nDscho\n"},{"id":"84742","messageId":"20080724165335.GW2925@dpotapov.dyndns.org","threadId":"14603","inReplyTo":"7vej5kfs0w.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-24T16:53:35Z","receivedAt":"2008-07-24T16:53:35Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Jul 23, 2008 at 10:07:43AM -0700, Junio C Hamano wrote:\n> Johannes Schindelin writes:\n> \n> > However, if you want to avoid CRs to _enter_ the repository, when you have \n> > a lot of binary files tracked, you _do_ want to force all repositories to \n> > crlf=input.\n> \n> If you are on a sane system, you do not even want to pay the price of\n> conversion. \n\nIf you do not have CRLF then there will be no conversion, so you pay only\nthe price of check. The relative cost of that check obviously depends on\nwhat other operations are. I believe that the worst case for this check\nwill be when there is no other operations, just re-reading files, so I\ndid:\n\n# touch all files to force git re-read them...\ngit ls-files | xargs touch\ntime git status\n\nHere is the average based on 3 attempts:\n0.232s with autocrlf=false\n0.265s with autocrlf=input (14% increase)\n\nOf course, without touching files, git-status will take the same time in\nboth cases (about 0.026s in my testing), and touching all files not very\ninteresting from the practical point of view.\n\nSo, I decided to do something more practical, like applying 100 patches.\nHere are my results:\n\n false input\n ------ -------\n 7.409s 7.603s\n 7.592s 7.239s\n 7.617s 7.402s\n ------ -------\nAverage: 7.539s 7.415s\n\nautocrlf=input turned out to be even slightly faster, but the difference\nis not statistically significant.\n\nSo, though it is obvious that autocrlf=input clearly adds some overhead,\nI believe it is negligable in most practical cases as there are much\nmore expensive operations. And you can always turn autocrlf off, if you\nare sure that you never have files with the wrong line ending.\n\n> Only people on systems with CRLF line endings should pay the\n> price (because your aim is to convert on such systems).\n\nUnfortunately, it is not so clearly cut. Some people may work on Unix\nbut share files with Windows using network shares or emails.\n\n> Are we throwing\n> that out of the window when the project decides to use gitattributes?\n\nI am not sure that I understand your question. In any case, Dscho's\npatch did not change the default, so it did not penalize anyone except\nexplicitly asked about that by setting crlf on some files. I would like\nalso to notice that setting crlf on some files (in contrast to unsetting\nit!) is rarely necessary in practice if all users have sane settings for\nautocrlf.\n\n> \n> How about setting autocrlf automatically on mingw/msys/cygwin versions,\n> perhaps via templates or a patch to init-db? Would that, combined with\n> user education, be a viable alternative?\n\nPerhaps, it is good compromise for now, considering that Windows users\nhave most troubles with that... I really don't mind seeing 'input' as\ndefault on other platforms, but I won't insist on that.\n\n\nDmitry\n"},{"id":"84747","messageId":"20080724170553.GX2925@dpotapov.dyndns.org","threadId":"14603","inReplyTo":"alpine.DEB.1.00.0807241334340.8986@racer","subject":"Re: [PATCH] Respect crlf attribute in \"git add\" even if core.autocrlf has not been set","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-24T17:05:53Z","receivedAt":"2008-07-24T17:05:53Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Thu, Jul 24, 2008 at 01:39:34PM +0100, Johannes Schindelin wrote:\n> \n> Well, seems I will just continue shouting \"why did you commit that \n> CR-ridden file?\" and get shouted back with \"why does this §&%&%&!° Git \n> tool not fix it for me automatically? Even _Subversion_ can do it.\"\n\nActually, no... With Subversion, if you do not have correct auto-props\nthen every newly added file will have incorrect end-of-lines. So, each\nuser has to manually add all possible text extensions in the auto-props\nsection of his/her subversion config file. In practice, it means that\nwith SVN you have far less problems with EOLs in first few days when\nusers just existing files, but then the problem reemerge every time when\nsomeone adds a new file... So, it is not much better...\n\nIn constrast, Git provides automatic text detection and EOL conversion,\nbut it is not enabled where it should... at least, on Windows, and for\nthose who copies file directly from Windows through network shares or by\nother means.\n\nDmitry\n"},{"id":"84750","messageId":"alpine.DEB.1.00.0807241811580.8986@racer","threadId":"14603","inReplyTo":"20080724165335.GW2925@dpotapov.dyndns.org","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-24T17:14:09Z","receivedAt":"2008-07-24T17:14:09Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 24 Jul 2008, Dmitry Potapov wrote:\n\n> If you do not have CRLF then there will be no conversion, so you pay \n> only the price of check. The relative cost of that check obviously \n> depends on what other operations are. I believe that the worst case for \n> this check will be when there is no other operations, just re-reading \n> files, so I did:\n> \n> # touch all files to force git re-read them...\n> git ls-files | xargs touch\n> time git status\n> \n> Here is the average based on 3 attempts:\n> 0.232s with autocrlf=false\n> 0.265s with autocrlf=input (14% increase)\n\nAnd you tested... on git.git? One of the smallest serious Git users?\n\nIf you want to come close to the hard cases (that you would punish with \nsetting autocrlf = input, not yourself of course), test _at least_ the \nLinux kernel.\n\nTo come closer you should test on OpenOffice.org or KDE.\n\nHth,\nDscho\n"},{"id":"84758","messageId":"20080724175513.GY2925@dpotapov.dyndns.org","threadId":"14603","inReplyTo":"alpine.DEB.1.00.0807241811580.8986@racer","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-24T17:55:13Z","receivedAt":"2008-07-24T17:55:13Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Thu, Jul 24, 2008 at 06:14:09PM +0100, Johannes Schindelin wrote:\n> On Thu, 24 Jul 2008, Dmitry Potapov wrote:\n> > \n> > Here is the average based on 3 attempts:\n> > 0.232s with autocrlf=false\n> > 0.265s with autocrlf=input (14% increase)\n> \n> And you tested... on git.git? One of the smallest serious Git users?\n\nIf you take a huge repo, you are going to be bound by disk IO unless\nhuge amount memory, so all files reside in the filesystem cache.\n\n> \n> If you want to come close to the hard cases (that you would punish with \n> setting autocrlf = input, not yourself of course), test _at least_ the \n> Linux kernel.\n\nfalse input\n6.913s 8.426s\n6.922s 8.337s\n6.969s 8.335s\n6.975s 8.386s\n6.939s 8.435s\n6.954s 8.320s\n\nautocrlf=input takes 20% more than autocrlf=false, which is rather\nstrange, because I clearly saw some disk activity... so I expected\nit to be less...\n\nIn any case, this test is rather artificial, and the real one should\nbe is of course applying patches... Maybe I will try that later...\n\nDmitry\n"},{"id":"84795","messageId":"200807242244.04799.robin.rosenberg.lists@dewire.com","threadId":"14603","inReplyTo":"alpine.DEB.1.00.0807241742220.8986@racer","subject":"Re: [PATCH] Respect crlf attribute in \"git add\" even if core.autocrlf has not been set","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2008-07-24T20:44:04Z","receivedAt":"2008-07-24T20:44:04Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"torsdagen den 24 juli 2008 18.45.07 skrev Johannes Schindelin:\n> However, I see Junio's point: on sane platforms you have to work hard to \n> get CR-damaged files. And the regular sane platform user should not be \n> punished for the brain/CR damage a certain monopolist has brought over \n> this planet.\n\nThat wasn't hard at all :) Eclipse did it all by itself for JEE MANIFEST.MF files.\nWe got into some strange problems on windows with msysgit after that where git\n(status) detected the files as changed, but no actual content change and refused\nto change it's mind. I think we had actually fixed the files on Windows prior to that.\nOnly after converting the checkout to autocrlf=input did msysgit enter a sane state\nagain. I was not able to repeat the problem at the time.\n\nMaybe I'll try again in a few weeks time.\n\n-- robin\n"},{"id":"84798","messageId":"3B9933A6-9637-41AE-9133-9B6EA9204E6B@orakel.ntnu.no","threadId":"14603","inReplyTo":"alpine.DEB.1.00.0807232041570.8986@racer","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind-git@orakel.ntnu.no","sentAt":"2008-07-24T21:30:50Z","receivedAt":"2008-07-24T21:30:50Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 23. juli. 2008, at 21.44, Johannes Schindelin wrote:\n\n[...]\n\n> I deem it not, uhm, magical. By your reasoning there should be a \n> way for\n> Git to convert a file to UTF-8 when some entertaining person \n> converted the\n> working directory file to ISO-8859-15.\n\nUm, what? This discussion is about figuring out when Git should mess \nwith the line endings a user is trying to commit. Why are you \nbringing character encodings into it? Git does not (to my knowledge) \nhave any \"utf8\" setting that converts all files to UTF-8, and \ncertainly not one that is enabled by default on Windows.\n\nBeing able to mark a file with an \"enforce crlf line endings on this \nfile\" flag is useful _given that Git messes with line endings_, and a \n\"do not mess with line endings in this file\" flag does not achieve the \nsame purpose. Okay?\n\nIf you want my personal opinion on autocrlf, I was happier when Git \nleft line endings alone so I didn't have to worry about the files I \ncommit being mangled (however reversibly).\n\nI think \"autocrlf=input\" can make sense on a per-repository basis, but \nI would have it somewhere versioned like .gitattributes, so that (a) \nit is propagated when the repository is cloned, and (b) it is possible \nto take an existing repository with checked-in CRLFs and do a one-time \nconversion that also adds the \"autocrlf=input\" setting \nto .gitattributes (or wherever the setting ends up going).\n\nI don't use \"autocrlf=true\", even on Windows, so I don't have any \nopinion on it other than thinking it should be a per-user setting \nrather than per-repository (but with a per-platform default :). I \ndon't see how it could work unless the repository has normalised line \nendings, though.\n\nMy background: I have a ton of repositories imported from CVS with a \nsordid mix of CR and CRLF (occasionally in the same file!). Using \nthese repositories with \"autocrlf=true\" is a pain in the arse since \nCRLFs in the repository cause spurious changes after a clean checkout, \nmerge troubles, etc. The code is supposed to build on Windows as well \nas Unix, so I got bit by this when msysgit changed the default \nautocrlf setting. [1]\n\nMy workaround is simply to set autocrlf=false; another solution might \nbe to filter-branch all CRLFs out of the repository, but then I'd be \nmessing with a lot of history, possibly breaking the files that \nactually need CRLFs, and for no real upside. No thanks.\n\nOkay, this turned into a longer rant than I intended; what I'm trying \nto say is that I think autocrlf(=true) as it is currently implemented \nis pretty useless, and that a setting that is versioned and cloneable \nwould be better. Phew!\n-- \nEyvind Bernhardsen\n\n\nFootnote:\n1. Your impression that people were rude when \"autocrlf=true\" was made \nthe default on msysgit might be related to the fact that nobody had \nconsidered what would happen to existing repositories before making \nthe change? Steffen Prohaska wrote in response to one such complaint:\n\n> Unfortunately, existing repositories that contain the wrong line \n> endings\n> suffer from the problems you described above. This can be handled\n> either by switching off autocrlf, as you propose, or by cleaning up \n> the\n> line endings.\n\n(http://groups.google.com/group/msysgit/browse_thread/thread/978a3435c1cb0c81/70bac514a8b438ef?lnk=gst#70bac514a8b438ef \n)\n\nSteffen went on to propose a patch to make autocrlf a sticky per- \nrepository setting, but I think you shot it down.\n"},{"id":"84810","messageId":"alpine.DEB.1.00.0807250157370.4140@eeepc-johanness","threadId":"14603","inReplyTo":"200807242244.04799.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] Respect crlf attribute in \"git add\" even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-24T23:58:24Z","receivedAt":"2008-07-24T23:58:24Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 24 Jul 2008, Robin Rosenberg wrote:\n\n> torsdagen den 24 juli 2008 18.45.07 skrev Johannes Schindelin:\n> > However, I see Junio's point: on sane platforms you have to work hard \n> > to get CR-damaged files. And the regular sane platform user should \n> > not be punished for the brain/CR damage a certain monopolist has \n> > brought over this planet.\n> \n> That wasn't hard at all :) Eclipse did it all by itself for JEE \n> MANIFEST.MF files. We got into some strange problems on windows with \n> msysgit after that where git (status) detected the files as changed, but \n> no actual content change and refused to change it's mind. I think we had \n> actually fixed the files on Windows prior to that. Only after converting \n> the checkout to autocrlf=input did msysgit enter a sane state again. I \n> was not able to repeat the problem at the time.\n> \n> Maybe I'll try again in a few weeks time.\n\nThat would be rather useful, because without a way to reproduce, you leave \nme with a rather frustrating situation.\n\nHth,\nDscho\n"},{"id":"84811","messageId":"alpine.DEB.1.00.0807250159420.4140@eeepc-johanness","threadId":"14603","inReplyTo":"3B9933A6-9637-41AE-9133-9B6EA9204E6B@orakel.ntnu.no","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-25T00:01:56Z","receivedAt":"2008-07-25T00:01:56Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 24 Jul 2008, Eyvind Bernhardsen wrote:\n\n> On 23. juli. 2008, at 21.44, Johannes Schindelin wrote:\n> \n> [...]\n> \n> >I deem it not, uhm, magical. By your reasoning there should be a way \n> >for Git to convert a file to UTF-8 when some entertaining person \n> >converted the working directory file to ISO-8859-15.\n> \n> Um, what? This discussion is about figuring out when Git should mess \n> with the line endings a user is trying to commit.\n\nThis discusion is about when Git should mess with _content_ at all.\n\nIt is not limited to line endings.\n\nCiao,\nDscho \"who personally could not care less about CR if it was not for M$' \nstupidity\"\n"},{"id":"84876","messageId":"E0666371-5C5E-4AA9-B67A-16C42477865B@orakel.ntnu.no","threadId":"14603","inReplyTo":"alpine.DEB.1.00.0807250159420.4140@eeepc-johanness","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind-git@orakel.ntnu.no","sentAt":"2008-07-25T12:30:16Z","receivedAt":"2008-07-25T12:30:16Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 25. juli. 2008, at 02.01, Johannes Schindelin wrote:\n\n>> Um, what? This discussion is about figuring out when Git should mess\n>> with the line endings a user is trying to commit.\n>\n> This discusion is about when Git should mess with _content_ at all.\n>\n> It is not limited to line endings.\n\nFair enough. Did you read the rest of my email to see when I think \nGit should mess with content? I've thought about it, and being able \nto do stuff like this in .gitattributes would work for me:\n\n* eol=auto\n*.bat eol=crlf\nMakefile eol=lf\nbin/magic-binary eol=none\n\nI.e. \"detect line endings and do CRLF->LF conversion on all files \nexcept *.bat (*->CRLF), Makefile (*->LF) and bin/magic-binary (do \nnothing)\".\n\nThe closest you can get today is by setting core.autocrlf to \"input\" \nand having this in .gitattributes:\n\n*.bat -crlf\nbin/magic-binary -crlf\n\n...but \"core.autocrlf\" is not versioned and applies to _all_ \nrepositories, and anyone who doesn't have the correct setting can mess \nthe repository up. There's also no way of saying \"this file should \nhave LF line endings, even with autocrlf=true\".\n\nOne problem is that the autocrlf setting mixes \"I want LF only in my \nrepositories\" and \"I like to have CRLFs in my working directory\" into \none config variable. Instead, I'd like to have a config setting that \nspecifies which line ending form I prefer: \"when a text file is marked \neol=auto, convert LFs to CRLFs on checkout\".\n\nDoes this make sense to anyone but me?\n\n> Ciao,\n> Dscho \"who personally could not care less about CR if it was not for \n> M$'\n> stupidity\"\n\nWell, we agree on that.\n-- \nEyvind Bernhardsen\n"},{"id":"84884","messageId":"20080725140142.GB2925@dpotapov.dyndns.org","threadId":"14603","inReplyTo":"E0666371-5C5E-4AA9-B67A-16C42477865B@orakel.ntnu.no","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-25T14:01:42Z","receivedAt":"2008-07-25T14:01:42Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Fri, Jul 25, 2008 at 02:30:16PM +0200, Eyvind Bernhardsen wrote:\n> \n> Fair enough. Did you read the rest of my email to see when I think \n> Git should mess with content? I've thought about it, and being able \n> to do stuff like this in .gitattributes would work for me:\n> \n> * eol=auto\n> *.bat eol=crlf\n> Makefile eol=lf\n> bin/magic-binary eol=none\n> \n> I.e. \"detect line endings and do CRLF->LF conversion on all files \n> except *.bat (*->CRLF), Makefile (*->LF) and bin/magic-binary (do \n> nothing)\".\n\nI suppose \"* eol=auto\" means to convert CRLF->LF on checkin and\nLF->native on checkout?\n\nAlso, perhaps, it should be also possible to explicitly specify:\n*.txt eol=native\nwhich is the same as 'auto' but without guessing whether it is text\nor not.\n\n> ...but \"core.autocrlf\" is not versioned and applies to _all_ \n> repositories, and anyone who doesn't have the correct setting can mess \n> the repository up.\n\nI think the real issue here is not as much about being or not being\nversioned, but about forcing and not forcing anything on users.\n\nIf we had core.autocrlf=input as default then clueless users will not\ncheckin files with the incorrect ending. But there is an objection to\nthat -- you penalize those who always have good endings. And even the\nfact that is merely default value that you can easily change to false\ndoes not convince everyone.\n\nThe same can be said about your\n* eol=auto\nIt forces conversion on everyone, even on those who do not need it.\nOf course, you can say those projects that do not have the problem with\nclueless users putting text files with incorrect end-of-lines will not\nhave lines like that in their .gitattribute. Yet, if I participate in\nthat project, why do I have to pay the price for this conversion just\nbecause someone stupid can mess up line-endings?\n\n> There's also no way of saying \"this file should \n> have LF line endings, even with autocrlf=true\".\n\nActually, there is\n\n*.sh crlf=input\n\ni.e. I want my shell files to have LF even I normally use CRLF for\nall other files (on Windows).\n\n> \n> One problem is that the autocrlf setting mixes \"I want LF only in my \n> repositories\" and \"I like to have CRLFs in my working directory\" into \n> one config variable. Instead, I'd like to have a config setting that \n> specifies which line ending form I prefer: \"when a text file is marked \n> eol=auto, convert LFs to CRLFs on checkout\".\n\nFollowing your style above, I believe it should be defined as\nnative-eol=crlf\n\nbut there are people who do not want to pay any price for conversion.\nCurrently, \"core.autocrlf=false\" means to do nothing about end-of-lines,\nand even to ignore setting in .gitattributes. Should it be possible to\ndisable *any* conversion on checkin and checkout? Should this be that\nvalue be the default, which most users use?\n\nDmitry\n--\nIf you write a program that any idiot can use, only idiots will use it.\n"},{"id":"84948","messageId":"42C252B2-85B9-4D05-B3A2-2A0250D7F5D6@orakel.ntnu.no","threadId":"14603","inReplyTo":"20080725140142.GB2925@dpotapov.dyndns.org","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind-git@orakel.ntnu.no","sentAt":"2008-07-25T21:05:33Z","receivedAt":"2008-07-25T21:05:33Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 25. juli. 2008, at 16.01, Dmitry Potapov wrote:\n\n> On Fri, Jul 25, 2008 at 02:30:16PM +0200, Eyvind Bernhardsen wrote:\n>>\n>> Fair enough. Did you read the rest of my email to see when I think\n>> Git should mess with content? I've thought about it, and being able\n>> to do stuff like this in .gitattributes would work for me:\n>>\n>> * eol=auto\n>> *.bat eol=crlf\n>> Makefile eol=lf\n>> bin/magic-binary eol=none\n>>\n>> I.e. \"detect line endings and do CRLF->LF conversion on all files\n>> except *.bat (*->CRLF), Makefile (*->LF) and bin/magic-binary (do\n>> nothing)\".\n>\n> I suppose \"* eol=auto\" means to convert CRLF->LF on checkin and\n> LF->native on checkout?\n\nThat's the idea, yes, with \"native\" being configurable.\n\n> Also, perhaps, it should be also possible to explicitly specify:\n> *.txt eol=native\n> which is the same as 'auto' but without guessing whether it is text\n> or not.\n\nYes! Good catch, that needs to be possible.\n\n>> ...but \"core.autocrlf\" is not versioned and applies to _all_\n>> repositories, and anyone who doesn't have the correct setting can \n>> mess\n>> the repository up.\n>\n> I think the real issue here is not as much about being or not being\n> versioned, but about forcing and not forcing anything on users.\n\nThe reason I want versioning is to fix the problem of enforcing \nnormalised line endings in repositories with checked-in CRLFs; I'm not \nsure how to solve it any other way, but I'm open to suggestions.\n\n> If we had core.autocrlf=input as default then clueless users will not\n> checkin files with the incorrect ending. But there is an objection to\n> that -- you penalize those who always have good endings. And even the\n> fact that is merely default value that you can easily change to false\n> does not convince everyone.\n\nThat is an excellent argument for why setting \"autocrlf=true\" by \ndefault on Windows was a bad idea. Thanks! :)\n\n> The same can be said about your\n> * eol=auto\n> It forces conversion on everyone, even on those who do not need it.\n> Of course, you can say those projects that do not have the problem \n> with\n> clueless users putting text files with incorrect end-of-lines will not\n> have lines like that in their .gitattribute. Yet, if I participate in\n> that project, why do I have to pay the price for this conversion just\n> because someone stupid can mess up line-endings?\n\nIt's about correctness: if the repository isn't supposed to have CRs \nin any text files, that needs to be enforced. You might not be \nstupid, but that doesn't mean you won't ever take a file that was \ncreated on Windows and commit it to the repository on Linux. If the \ntool used to create the file was CR-damaged, there goes the \nrepository's LF-only policy.\n\nAs you say, the reason I want the setting to be per-repository is that \nI don't think the cost is worthwhile for every repository. The case \nwhere it _is_ worthwhile is when the repository will be shared between \nWindows users and Linux users, and the Windows users want CRLFs in \ntheir working directories. I think it's worthwhile to actually make \nGit work right in that case.\n\nAs a side note, there's a lot of complaining about the cost of \nenforcing LF-only input, but I can't remember seeing any actual \nnumbers. Is it really that bad?\n\n>> There's also no way of saying \"this file should\n>> have LF line endings, even with autocrlf=true\".\n>\n> Actually, there is\n>\n> *.sh crlf=input\n>\n> i.e. I want my shell files to have LF even I normally use CRLF for\n> all other files (on Windows).\n\nWon't they still be converted to CRLF on checkout when autocrlf=true \non Windows?\n\n>> One problem is that the autocrlf setting mixes \"I want LF only in my\n>> repositories\" and \"I like to have CRLFs in my working directory\" into\n>> one config variable. Instead, I'd like to have a config setting that\n>> specifies which line ending form I prefer: \"when a text file is \n>> marked\n>> eol=auto, convert LFs to CRLFs on checkout\".\n>\n> Following your style above, I believe it should be defined as\n> native-eol=crlf\n\nYes, that sounds right.\n\n> but there are people who do not want to pay any price for conversion.\n> Currently, \"core.autocrlf=false\" means to do nothing about end-of- \n> lines,\n> and even to ignore setting in .gitattributes. Should it be possible to\n> disable *any* conversion on checkin and checkout? Should this be that\n> value be the default, which most users use?\n\nWell, there's no reason why Git repositories used only on Windows \nmachines shouldn't store CRLFs, so why should all msysgit users pay \nthe cost on every checkin _and_ checkout?\n\nThis is the reason the setting needs to be a per-repository policy and \nnot a user configuration; users should not be able to configure away \ncorrectness, but they shouldn't be penalised unnecessarily for it, \neither.\n-- \nEyvind Bernhardsen\n"},{"id":"84980","messageId":"alpine.DEB.1.00.0807260407170.11976@eeepc-johanness","threadId":"14603","inReplyTo":"42C252B2-85B9-4D05-B3A2-2A0250D7F5D6@orakel.ntnu.no","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-26T02:09:41Z","receivedAt":"2008-07-26T02:09:41Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 25 Jul 2008, Eyvind Bernhardsen wrote:\n\n> That is an excellent argument for why setting \"autocrlf=true\" by default \n> on Windows was a bad idea. Thanks! :)\n\nWell, these days, I tend to give a flying nothing to opinions that are not \nbacked up by any effort toward the project.\n\nIn other words, if you have not participated in the community process to \nfind what is best for Git, you could just as well say that you want the \nmoon to be green, and I could not care less (in both cases).\n\nCiao,\nDscho\n"},{"id":"85473","messageId":"20080729134619.GB7008@dpotapov.dyndns.org","threadId":"14603","inReplyTo":"42C252B2-85B9-4D05-B3A2-2A0250D7F5D6@orakel.ntnu.no","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-29T13:46:19Z","receivedAt":"2008-07-29T13:46:19Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Fri, Jul 25, 2008 at 11:05:33PM +0200, Eyvind Bernhardsen wrote:\n> \n> The reason I want versioning is to fix the problem of enforcing \n> normalised line endings in repositories with checked-in CRLFs; I'm not \n> sure how to solve it any other way, but I'm open to suggestions.\n\nYou clearly want *enforcing* and versioning for you is just means to do\nthat. Regardless, what is the best way to achieve that, the *main*\nquestion is whether we want this enforcing and if yet then in what form\nand to what degree...\n\n> \n> >If we had core.autocrlf=input as default then clueless users will not\n> >checkin files with the incorrect ending. But there is an objection to\n> >that -- you penalize those who always have good endings. And even the\n> >fact that is merely default value that you can easily change to false\n> >does not convince everyone.\n> \n> That is an excellent argument for why setting \"autocrlf=true\" by \n> default on Windows was a bad idea. Thanks! :)\n\nI am sorry, but I don't see connection here.\n\n> \n> >The same can be said about your\n> >* eol=auto\n> >It forces conversion on everyone, even on those who do not need it.\n> >Of course, you can say those projects that do not have the problem \n> >with\n> >clueless users putting text files with incorrect end-of-lines will not\n> >have lines like that in their .gitattribute. Yet, if I participate in\n> >that project, why do I have to pay the price for this conversion just\n> >because someone stupid can mess up line-endings?\n> \n> It's about correctness: if the repository isn't supposed to have CRs \n> in any text files, that needs to be enforced. You might not be \n> stupid, but that doesn't mean you won't ever take a file that was \n> created on Windows and commit it to the repository on Linux. If the \n> tool used to create the file was CR-damaged, there goes the \n> repository's LF-only policy.\n\nAgain, why should people who do not use Windows and other CR-damaged\ntools be penalized? No one can prevent me from putting in *my* own \nrepository whatever I want anyway. Thus, if we agreed having this\nconversion/check is useful, remaining questions are:\n1. whether this check should be possible to turn off\n2. whether this check should be turned off by default for people\n who use Git on other system than Windows?\nThe current status is:\n1. Yes, it is possible to turn of this conversion\n2. It is turned off by default for anyone but MSYS/GIT users.\n\nAnd the main argument for having that in this way is that people with LF\ntext files should be unnecessary penalized for Windows being different.\n\n> \n> As you say, the reason I want the setting to be per-repository is that \n> I don't think the cost is worthwhile for every repository.\n\nSide note: Personally, I am not very concerned about this cost, but some\npeople are...\n\n> The case \n> where it _is_ worthwhile is when the repository will be shared between \n> Windows users and Linux users, and the Windows users want CRLFs in \n> their working directories. I think it's worthwhile to actually make \n> Git work right in that case.\n\nWindows users who want CRLF should set autocrlf=true\nWindows users who prefer LF should set autocrlf=input\nNon-Windows users who copy file directly from Windows should also\nset autocrlf=input\nAll other users who do not touch Windows may have autocrlf=false.\n\nFiles that do not need conversion (such as *.bat) should be marked as\n\"-crlf\" in .gitattributes.\n\nOf course, those who are very careful and have good editors can set\nautocrlf=false even on Windows...\n\n> \n> As a side note, there's a lot of complaining about the cost of \n> enforcing LF-only input, but I can't remember seeing any actual \n> numbers. Is it really that bad?\n\nNo, it is not bad. In most practical cases, you will not notice any\ndifference. I've posted some numbers in this thread. You can find\nthem here:\nhttp://article.gmane.org/gmane.comp.version-control.git/89908\n\n> \n> >>There's also no way of saying \"this file should\n> >>have LF line endings, even with autocrlf=true\".\n> >\n> >Actually, there is\n> >\n> >*.sh crlf=input\n> >\n> >i.e. I want my shell files to have LF even I normally use CRLF for\n> >all other files (on Windows).\n> \n> Won't they still be converted to CRLF on checkout when autocrlf=true \n> on Windows?\n\nautocrlf=true works in the same way on Linux and Windows, and I have\ntested it right now, and it works as I said above.\n\n> >but there are people who do not want to pay any price for conversion.\n> >Currently, \"core.autocrlf=false\" means to do nothing about end-of- \n> >lines,\n> >and even to ignore setting in .gitattributes. Should it be possible to\n> >disable *any* conversion on checkin and checkout? Should this be that\n> >value be the default, which most users use?\n> \n> Well, there's no reason why Git repositories used only on Windows \n> machines shouldn't store CRLFs, so why should all msysgit users pay \n> the cost on every checkin _and_ checkout?\n\n1. You may want to use on other platforms later. In any case, it makes\n much sense to have the default that compatible with other systems.\n2. Conversion cost is not significant (I suppose much less than gzip\n compression used for all objects) and it also saves some space.\n3. Internally, Git considers only LF as true end of line. CR is just\n like an extra space before end-of-line. Is any good reason to have\n it inside of your repo anyway?\n4. This is what other VCSes do on Windows. CVS converts all text files\n on checkin. SVN does the same for files having svn:eol-style=native.\n\nIn fact, if you read the discussion we had here some time ago, you may\nfind some other arguments too.\n\n> \n> This is the reason the setting needs to be a per-repository policy and \n> not a user configuration;\n\nWhat exactly?\n\n> users should not be able to configure away \n> correctness,\n\nWhy not? *Every* user has him/her own repository, so he/she can do\n*anything* with it, in principle.\n\n> but they shouldn't be penalised unnecessarily for it, \n> either.\n\nThe problem is how to determine when it is necessary and when it is\nnot. If I never commit with wrong EOLs, I don't think it is necessary\nfor me to have this conversion... On the other hand, I don't mind having\nthis check as default. It does not really bother me much, and if I can\nturn it off, it is fine with me. But I suppose other people may feel\ndifferently about this issue.\n\n\nDmitry\n"},{"id":"85502","messageId":"164D011C-D862-43F6-8DAC-1309AC0E91F4@orakel.ntnu.no","threadId":"14603","inReplyTo":"alpine.DEB.1.00.0807260407170.11976@eeepc-johanness","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind-git@orakel.ntnu.no","sentAt":"2008-07-29T19:11:05Z","receivedAt":"2008-07-29T19:11:05Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"\nOn 26. juli. 2008, at 04.09, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Fri, 25 Jul 2008, Eyvind Bernhardsen wrote:\n>\n>> That is an excellent argument for why setting \"autocrlf=true\" by \n>> default\n>> on Windows was a bad idea. Thanks! :)\n>\n> Well, these days, I tend to give a flying nothing to opinions that \n> are not\n> backed up by any effort toward the project.\n\nYeah, sorry, I'll stop complaining about this until I have actual code \nto back me up.\n-- \nEyvind Bernhardsen\n"},{"id":"85517","messageId":"A8BF9951-AB9D-4391-A6CB-E9778064F4A8@orakel.ntnu.no","threadId":"14603","inReplyTo":"20080729134619.GB7008@dpotapov.dyndns.org","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind-git@orakel.ntnu.no","sentAt":"2008-07-29T21:17:23Z","receivedAt":"2008-07-29T21:17:23Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 29. juli. 2008, at 15.46, Dmitry Potapov wrote:\n\n> On Fri, Jul 25, 2008 at 11:05:33PM +0200, Eyvind Bernhardsen wrote:\n>\n> You clearly want *enforcing* and versioning for you is just means to \n> do\n> that. Regardless, what is the best way to achieve that, the *main*\n> question is whether we want this enforcing and if yet then in what \n> form\n> and to what degree...\n\nThe versioning has nothing to do with the enforcing per se, it just \nmakes it possible to convert a repository with CRLFs to one that's LF- \nonly without having to rewrite history. See below.\n\n>>> If we had core.autocrlf=input as default then clueless users will \n>>> not\n>>> checkin files with the incorrect ending. But there is an objection \n>>> to\n>>> that -- you penalize those who always have good endings. And even \n>>> the\n>>> fact that is merely default value that you can easily change to \n>>> false\n>>> does not convince everyone.\n>>\n>> That is an excellent argument for why setting \"autocrlf=true\" by\n>> default on Windows was a bad idea. Thanks! :)\n>\n> I am sorry, but I don't see connection here.\n\nMy point was that autocrlf penalises Windows users just as much as it \ndoes Linux users, so why should it be turned on by default on \nWindows? But I've promised not to complain any more about this until \nI have cold, hard code to back me up.\n\n> Again, why should people who do not use Windows and other CR-damaged\n> tools be penalized? No one can prevent me from putting in *my* own\n> repository whatever I want anyway. Thus, if we agreed having this\n> conversion/check is useful, remaining questions are:\n> 1. whether this check should be possible to turn off\n> 2. whether this check should be turned off by default for people\n> who use Git on other system than Windows?\n> The current status is:\n> 1. Yes, it is possible to turn of this conversion\n> 2. It is turned off by default for anyone but MSYS/GIT users.\n>\n> And the main argument for having that in this way is that people \n> with LF\n> text files should be unnecessary penalized for Windows being \n> different.\n\nI know, but my point is that I don't like to be unnecessarily \npenalised any more when I am using Windows than when I'm using Linux \nor OS X. I would like the default to be \"no conversion\", and for \nconversion to be enabled not based on platform, but as a policy \ndecision on the repositories where it actually matters.\n\nYou can have anything you like in _your_ repository, of course, but if \nyou're not publishing it anywhere, who cares what your line endings \nare? Your line endings only matter when you publish. That's why I \nwant a setting that is propagated: so that when you clone a repository \nwith a LF-only policy, Git knows what to do.\n\n>> As you say, the reason I want the setting to be per-repository is \n>> that\n>> I don't think the cost is worthwhile for every repository.\n>\n> Side note: Personally, I am not very concerned about this cost, but \n> some\n> people are...\n\nYeah :)\n\nI think the real penalty is that with autocrlf enabled, Git no longer \nstores exactly what I committed.\n\n>> The case\n>> where it _is_ worthwhile is when the repository will be shared \n>> between\n>> Windows users and Linux users, and the Windows users want CRLFs in\n>> their working directories. I think it's worthwhile to actually make\n>> Git work right in that case.\n>\n> Windows users who want CRLF should set autocrlf=true\n> Windows users who prefer LF should set autocrlf=input\n> Non-Windows users who copy file directly from Windows should also\n> set autocrlf=input\n> All other users who do not touch Windows may have autocrlf=false.\n>\n> Files that do not need conversion (such as *.bat) should be marked as\n> \"-crlf\" in .gitattributes.\n\nYes, and I see you checked that \"crlf=input\" does actually work when \nyou want LF-only, sorry about that. The syntax is _horrible_, though.\n\n> Of course, those who are very careful and have good editors can set\n> autocrlf=false even on Windows...\n\nRight, or who know that the repository they're using will only be \nshared with other Windows users. But with \"autocrlf=false\" in their \nconfig, they would have to remember to set \"autocrlf=true\" in .git/ \nconfig in any new repositories they want to share with Linux users. \nI'd like to make that per-repository configuration automatic.\n\n>> As a side note, there's a lot of complaining about the cost of\n>> enforcing LF-only input, but I can't remember seeing any actual\n>> numbers. Is it really that bad?\n>\n> No, it is not bad. In most practical cases, you will not notice any\n> difference. I've posted some numbers in this thread. You can find\n> them here:\n> http://article.gmane.org/gmane.comp.version-control.git/89908\n\nOh, thanks! I missed that post, and I agree that those numbers don't \nlook particularly worrying.\n\n[...]\n\n>>> but there are people who do not want to pay any price for \n>>> conversion.\n>>> Currently, \"core.autocrlf=false\" means to do nothing about end-of-\n>>> lines,\n>>> and even to ignore setting in .gitattributes. Should it be \n>>> possible to\n>>> disable *any* conversion on checkin and checkout? Should this be \n>>> that\n>>> value be the default, which most users use?\n>>\n>> Well, there's no reason why Git repositories used only on Windows\n>> machines shouldn't store CRLFs, so why should all msysgit users pay\n>> the cost on every checkin _and_ checkout?\n>\n> 1. You may want to use on other platforms later. In any case, it makes\n> much sense to have the default that compatible with other systems.\n\nThis is why I want the setting to be versioned. If you decide to \nshare with other platforms later, you just enable the setting and \"git \ncommit -a\" (untested! Recursive touching is probably required \nfirst). No history has to be rewritten, and new checkouts will work \nproperly (as will old checkouts, but for a slightly different value of \n\"properly\").\n\n> 2. Conversion cost is not significant (I suppose much less than gzip\n> compression used for all objects) and it also saves some space.\n> 3. Internally, Git considers only LF as true end of line. CR is just\n> like an extra space before end-of-line. Is any good reason to have\n> it inside of your repo anyway?\n\nInternally, Git doesn't really care, does it? The only reason to keep \nthe line endings I committed is \"because that's what I committed\", but \nI think it's quite a good reason.\n\n> 4. This is what other VCSes do on Windows. CVS converts all text files\n> on checkin. SVN does the same for files having svn:eol-style=native.\n\nHeh. Where I work, we hacked CVS for Windows to get away from that \nbehaviour :)\n\n> In fact, if you read the discussion we had here some time ago, you may\n> find some other arguments too.\n\nYep, but I think I'm doing this backwards. Instead of rehashing old \narguments, I need to implement something that does what I want and let \nthe list decide if it's useful or not.\n\n>> This is the reason the setting needs to be a per-repository policy \n>> and\n>> not a user configuration;\n>\n> What exactly?\n>\n>\n>> users should not be able to configure away\n>> correctness,\n>\n> Why not? *Every* user has him/her own repository, so he/she can do\n> *anything* with it, in principle.\n>\n>> but they shouldn't be penalised unnecessarily for it,\n>> either.\n>\n> The problem is how to determine when it is necessary and when it is\n> not. If I never commit with wrong EOLs, I don't think it is necessary\n> for me to have this conversion... On the other hand, I don't mind \n> having\n> this check as default. It does not really bother me much, and if I \n> can\n> turn it off, it is fine with me. But I suppose other people may feel\n> differently about this issue.\n\nWell, what I want is to be able to say \"it is necessary to do eol \nconversion in this repository\", allowing the default to be \"don't do \neol conversion\" on Windows, too. For a setting like that to be \nuseful, it has to be propagated when the repository is cloned.\n\nI want it to be versioned because you might want to change it without \nmessing with the content that's already in the repository. This is \nactually my main motivation, since I have lots of CRLF-infused CVS \nhistory to deal with.\n\nIt should apply on Linux as well as Windows because there is always \nthe chance that a user will manage to commit a CRLF on Linux (a \ncolleague of mine once complained that CVS on Linux doesn't do eol \nconversion; he edited files on Windows, but checked them in on \nLinux). It would probably be okay to have a setting that turns all \nconversion off, but wouldn't that be kind of rude?\n\nThanks, all, for your help in getting my ideas straight; now to find \nout if I'm coder enough to implement them. If not, I'll just stick \nwith setting \"autocrlf=false\" on Windows and stop whining.\n-- \nEyvind Bernhardsen\n"},{"id":"85578","messageId":"80518F08-A9A9-4190-9AC4-D24DD6A1188B@zib.de","threadId":"14603","inReplyTo":"A8BF9951-AB9D-4391-A6CB-E9778064F4A8@orakel.ntnu.no","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-07-30T05:35:19Z","receivedAt":"2008-07-30T05:35:19Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 29, 2008, at 11:17 PM, Eyvind Bernhardsen wrote:\n\n>>> As you say, the reason I want the setting to be per-repository is \n>>> that\n>>> I don't think the cost is worthwhile for every repository.\n>>\n>> Side note: Personally, I am not very concerned about this cost, but \n>> some\n>> people are...\n>\n> Yeah :)\n>\n> I think the real penalty is that with autocrlf enabled, Git no \n> longer stores exactly what I committed.\n\nGit does *never* exactly store what you committed. Git compresses\nyour data and creates packs containing many of your individual\nfiles in a single pack.\n\nWhat matters is that git gives you exactly back what you committed. It\ndoes so with core.autocrlf=true, unless you check out with a different\nsetting for autocrlf. There is a small chance that git decides that\na file is text even though it should be binary and that the content of\nthis file does not allow for reversible CRLF-conversion. In this case\ngit warns about the irreversible conversion and the user gets a chance\nto correct git's choice.\n\nWe accept this slight chance of irreversible conversion because we do\nwant to handle line-endings of text files for cross-platform use. For\nthis, the goal of \"giving you *exactly* back what you committed\" is\nmodified. Instead, we want to give you exactly back what you committed,\nexcept for line-endings (in text files), which should be converted to\nthe platform-dependent line-endings (LF or CRLF), depending on the \nuser's\nsetting.\n\nBecause of a design choice we made, CRLF must be converted on Windows.\nWe decided that the token that git uses *internally* to represent\na line-ending in a text file is LF. We made this choice because git\noriginally supported only Unix and so we chose the Unix line-ending for\nrepresenting line-endings internally. Now, Windows uses CRLF to\nindicate line-endings but git internally uses LF, so we must convert\nthem. Note that if we had users that completely ignored their native\nWindows environment and only used well-selected tools, all configured to\n*never* write native Windows line-ending, for these users we could set\nautocrlf=false and the repository would nonetheless only contain LFs.\nThose exceptional super-expert users could manually modify their\nsettings. The average user (including me) will not be able to guarantee\nthat he will never create CRLF in text files on Windows. Those users\nsimply accept that they work on Windows and use the native line-endings\n(CRLF) and because we care about these average users we set \nautocrlf=true.\n\nIn contrast, setting autocrlf=input on Unix is only a safety valve. The\naverage user who is only working on Unix will most likely *never* create\nCRLF line-endings. In a Unix-only environment it is actually very hard\nto create CRLF line-endings. Thus, the current default (autocrlf unset)\nassumes that all text files on Unix contain only LF, and git wants LF\ninternally, which means we do not need to convert the line-endings. In\ncross-platform environments however, our assumption that all files on\nUnix contain only LFs probably no longer holds. In a cross-platform\nenvironment you can easily copy files from Windows to Unix and thus\n*easily* create files on Unix that contains CRLF. In this case\nautocrlf=input can save you, by correcting the line-endings for you. In\nthis case, git *does not* give you exactly back what you committed, but\ngives you back the very same text you committed however with the native\nLF line-endings.\n\nPersonally I believe that our assumption that it is virtually impossible\nto unintentionally create CRLF line-endings on Unix is wrong; but the\nprevailing opinion on the list is different. Personally, I believe that\nautocrlf=input should be the default on Unix to shield the repository\nfrom CRLFs. I am using autocrlf=input for some time now and it has\nalready saved me several times. Note that I am not working in a\nUnix-only environment, but in a mixed Unix/Mac/Windows environment, so\nunintentionally creating CRLFs is quite easy.\n\nAnother valid concern is speed. But the timings that Dmitry presented\nindicate that the overhead of autocrlf is so small that it is hard to\nmeasure in practice. I think we should stop raising this concern unless\nsomeone comes up with timings that indicate a larger overhead than\nmeasured by Dmitry.\n\n\tSteffen\n"},{"id":"85661","messageId":"32541b130807301133w4bfc8288oa2d15911b2317dca@mail.gmail.com","threadId":"14603","inReplyTo":"80518F08-A9A9-4190-9AC4-D24DD6A1188B@zib.de","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-30T18:33:51Z","receivedAt":"2008-07-30T18:33:51Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/30/08, Steffen Prohaska wrote:\n> On Jul 29, 2008, at 11:17 PM, Eyvind Bernhardsen wrote:\n> > I think the real penalty is that with autocrlf enabled, Git no longer\n> > stores exactly what I committed.\n>\n> Git does *never* exactly store what you committed. Git compresses\n> your data and creates packs containing many of your individual\n> files in a single pack.\n\nThis is not really an argument; making perfectly reversible changes as\npart of the storage process, then reversing them as part of the\nretrieval process, doesn't count as not storing what I committed.\n\n> What matters is that git gives you exactly back what you committed. It\n> does so with core.autocrlf=true, unless you check out with a different\n> setting for autocrlf.\n\nYou can tell that this statement isn't quite true because if you have\na file with mixed LF and CRLF line endings, which I do (thanks,\nWindows!) then CRLF->LF conversion is not a reversible operation.\nInterestingly LF->CRLF still is (because an LF->CRLF'd file will never\nhave a bare LF, and on such a subset of files, CRLF->LF is\nreversible).\n\nAlso note that core.autocrlf=input is *definitely* not a perfectly\nreversible operation.\n\nAnd so here's the problem: svn hands you a file. It may or may not\nhave CRLFs in it, and the line endings may actually be a random mix of\nLF and CRLF, as I am actually experiencing at the moment in a\nparticular repository at work. If core.autocrlf is anything other\nthan \"false\", git will modify the file, and git-svn won't be apply the\ndiff on the next revision.\n\nIt's conceivable that core.autocrlf=true will work if your svn\nrepository is pure and svn hands you files only with CRLF endings.\nIt's somewhat unlikely that most svn repositories are in that state\n(remember: it has to be perfect in *every revision* for git-svn to\nwork).\n\nSo anyway, I can't see how git-svn can possibly work in the general\ncase if core.autocrlf is anything other than false *at git-svn fetch\ntime*. And that's what I do, and it works great, modulo a bunch of\nstupid CRLFs that sneak into the repo via svn, but those can be fixed.\n Someday we'll stop using svn, and git-filter-branch can fix them all\nretroactively so that \"blame\" will work right.\n\nPerhaps git-svn needs to actually ignore the core.autocrlf setting?\n\nHave fun,\n\nAvery\n"},{"id":"85672","messageId":"56C07978-D6C9-4219-8B92-6217BD33F6D4@zib.de","threadId":"14603","inReplyTo":"32541b130807301133w4bfc8288oa2d15911b2317dca@mail.gmail.com","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-07-30T19:25:58Z","receivedAt":"2008-07-30T19:25:58Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 30, 2008, at 8:33 PM, Avery Pennarun wrote:\n\n> On 7/30/08, Steffen Prohaska wrote:\n>\n>> What matters is that git gives you exactly back what you \n>> committed. It\n>> does so with core.autocrlf=true, unless you check out with a \n>> different\n>> setting for autocrlf.\n>\n> You can tell that this statement isn't quite true because if you have\n> a file with mixed LF and CRLF line endings, which I do (thanks,\n> Windows!) then CRLF->LF conversion is not a reversible operation.\n> Interestingly LF->CRLF still is (because an LF->CRLF'd file will never\n> have a bare LF, and on such a subset of files, CRLF->LF is\n> reversible).\n>\n> Also note that core.autocrlf=input is *definitely* not a perfectly\n> reversible operation.\n\nYou are absolutely right. The files your describe are modified by git,\nbecause they are \"invalid\" text files, as git defines them. For git's\nautocrlf mechanism to work, a text file is only allowed to have a\n*single* type of line endings. Otherwise it is broken and git tries to\nhelp you fixing it.\n\n\n> And so here's the problem: svn hands you a file. It may or may not\n> have CRLFs in it, and the line endings may actually be a random mix of\n> LF and CRLF, as I am actually experiencing at the moment in a\n> particular repository at work. If core.autocrlf is anything other\n> than \"false\", git will modify the file, and git-svn won't be apply the\n> diff on the next revision.\n\nThis sound like a specific problem with svn, not a general problem\nof git's autocrlf concept. I work with a git-only workflow and I\nnever see the problems you describe.\n\n\n> It's conceivable that core.autocrlf=true will work if your svn\n> repository is pure and svn hands you files only with CRLF endings.\n> It's somewhat unlikely that most svn repositories are in that state\n> (remember: it has to be perfect in *every revision* for git-svn to\n> work).\n>\n> So anyway, I can't see how git-svn can possibly work in the general\n> case if core.autocrlf is anything other than false *at git-svn fetch\n> time*.\n\nThat might be the case. Note though that I cannot contribute\nmuch to this discussion because I never use git-svn.\n\n\n> And that's what I do, and it works great, modulo a bunch of\n> stupid CRLFs that sneak into the repo via svn, but those can be fixed.\n> Someday we'll stop using svn, and git-filter-branch can fix them all\n> retroactively so that \"blame\" will work right.\n>\n> Perhaps git-svn needs to actually ignore the core.autocrlf setting?\n\n From what you describe, I get the impression that git-svn's handling\nof line endings could certainly be improved.\n\n\tSteffen\n"},{"id":"85688","messageId":"32541b130807301407m59eef936m5e07dd33a4eb5b04@mail.gmail.com","threadId":"14603","inReplyTo":"56C07978-D6C9-4219-8B92-6217BD33F6D4@zib.de","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-30T21:07:49Z","receivedAt":"2008-07-30T21:07:49Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/30/08, Steffen Prohaska wrote:\n> > And so here's the problem: svn hands you a file. It may or may not\n> > have CRLFs in it, and the line endings may actually be a random mix of\n> > LF and CRLF, as I am actually experiencing at the moment in a\n> > particular repository at work. If core.autocrlf is anything other\n> > than \"false\", git will modify the file, and git-svn won't be apply the\n> > diff on the next revision.\n>\n> This sound like a specific problem with svn, not a general problem\n> of git's autocrlf concept. I work with a git-only workflow and I\n> never see the problems you describe.\n\nMy apologies, I think I got this thread mixed up with a different\nthread about the fact that git-svn doesn't work with autocrlf.\n\nFWIW, this problem would apply to any system that incrementally\nimports into git from another system using binary deltas.\n\nHave fun,\n\nAvery\n"},{"id":"85696","messageId":"20080730214521.GC7008@dpotapov.dyndns.org","threadId":"14603","inReplyTo":"A8BF9951-AB9D-4391-A6CB-E9778064F4A8@orakel.ntnu.no","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-30T21:45:22Z","receivedAt":"2008-07-30T21:45:22Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, Jul 29, 2008 at 11:17:23PM +0200, Eyvind Bernhardsen wrote:\n> \n> My point was that autocrlf penalises Windows users just as much as it \n> does Linux users, so why should it be turned on by default on \n> Windows? \n\nBecause it does make sense on Windows (I mentioned some reasons for that\nin my previous email), and it does NOT make any sense on Linux unless\nyou copy files from Windows.\n\n> >\n> >And the main argument for having that in this way is that people \n> >with LF\n> >text files should be unnecessary penalized for Windows being \n> >different.\n> \n> I know, but my point is that I don't like to be unnecessarily \n> penalised any more when I am using Windows than when I'm using Linux \n> or OS X.\n\nIt seems you still have not realized that from the very day when you\nstarted to use Windows, you are penalized for that day-in, day-out.\nLet's take something simple. For instance, the hello-world program:\ncat <<=== > hello.c\n#include \nint main() {\n\tprintf (\"Hello world!\\n\");\n\treturn 0;\n}\n===\n\nYou can compile it on Linux and Windows (using Microsoft Visual C).\nNow, if you run it on Linux, it will print 13 symbols (exactly\nas many as there are symbols in the printf string) while on Windows\nyou will get 14 bytes. It means that printf and as many other C\nfunction on Windows does conversion and penalize you already!\n\n> I would like the default to be \"no conversion\", and for \n> conversion to be enabled not based on platform, but as a policy \n> decision on the repositories where it actually matters.\n\nIf Microsoft C library did not do any conversion, I suspect we would\nhave this CRLF conversion at all!\n\n> You can have anything you like in _your_ repository, of course, but if \n> you're not publishing it anywhere, who cares what your line endings \n> are? Your line endings only matter when you publish. \n\nYou can publish only what you have. So, it must decided before.\n\n> That's why I \n> want a setting that is propagated: so that when you clone a repository \n> with a LF-only policy, Git knows what to do.\n\nLF-only policy is the only sane policy for any text files. It has nothing\nto do with clone.\n\n> \n> I think the real penalty is that with autocrlf enabled, Git no longer \n> stores exactly what I committed.\n\nAnd what is wrong with that? In any case, Git deltifies and compress\nyour files. Why does it not bother you? So, what matters here is\nwhether you are able to get back exactly what you put or not. That's\nwhy Git has this safecrlf option! Of course, it is guarantee to get\nexactly the same back only if you have the same autocrlf setting,\nbut if you have different autocrlf settings, it means that you want\n*different* representation of text files!\n\n> >Files that do not need conversion (such as *.bat) should be marked as\n> >\"-crlf\" in .gitattributes.\n> \n> Yes, and I see you checked that \"crlf=input\" does actually work when \n> you want LF-only, sorry about that. The syntax is _horrible_, though.\n> \n> >Of course, those who are very careful and have good editors can set\n> >autocrlf=false even on Windows...\n> \n> Right, or who know that the repository they're using will only be \n> shared with other Windows users.\n\nWRONG! Using storing CRLF in text files is a completely idiotic idea.\nThose who do so asked for troubles, so they should not complain!\n\n> \n> Internally, Git doesn't really care, does it?\n\nIt DOES!!! Such things like merges and diffs and many other every day\ncommands do care about end-of-lines and the ONLY end-of-line they\nrecognize is '\\n'. In fact, there are more than 400 places in Git where\n'\\n' is used. Of course, not all of them may be qualified as internals\nbut many of them do.\n\nSo, as long as Git internally consider only LF as the end-of-line.\n\n> \n> Heh. Where I work, we hacked CVS for Windows to get away from that \n> behaviour :)\n\nMaybe, you used Cygwin version of CVS, which had LF, but those Windows\nversions of CVS I used produced CRLF on Windows.\n\n> >\n> >The problem is how to determine when it is necessary and when it is\n> >not. If I never commit with wrong EOLs, I don't think it is necessary\n> >for me to have this conversion... On the other hand, I don't mind \n> >having\n> >this check as default. It does not really bother me much, and if I \n> >can\n> >turn it off, it is fine with me. But I suppose other people may feel\n> >differently about this issue.\n> \n> Well, what I want is to be able to say \"it is necessary to do eol \n> conversion in this repository\",\n\nYou always can do that in _your_ repository:\ngit config core.autocrlf ...\n\n> allowing the default to be \"don't do \n> eol conversion\" on Windows, too. For a setting like that to be \n> useful, it has to be propagated when the repository is cloned.\n\nWhy? Other people may have other preferences.\n\n> I want it to be versioned because you might want to change it without \n> messing with the content that's already in the repository. This is \n> actually my main motivation, since I have lots of CRLF-infused CVS \n> history to deal with.\n\nWell, you can try to use .gitattributes, but I believe it would be far\nmore reasonable to clean this mess with line-ending than finding a\nway to continue insanity with different ending in different text files.\n\n> \n> It should apply on Linux as well as Windows because there is always \n> the chance that a user will manage to commit a CRLF on Linux (a \n> colleague of mine once complained that CVS on Linux doesn't do eol \n> conversion; he edited files on Windows, but checked them in on \n> Linux).\n\nFor those who need it, Git provides autocrlf=input. But the question\nhere is what should be default. I don't think that those who copies\nfiles directly from Windows to Linux are majority. OTOH, I don't\nmind autocrlf=input as default. If it can be turned off, it is fine\nwith me :)\n\n> It would probably be okay to have a setting that turns all \n> conversion off, but wouldn't that be kind of rude?\n\nHow so?\n\n\nDmitry\n"},{"id":"85697","messageId":"20080730220236.GD7008@dpotapov.dyndns.org","threadId":"14603","inReplyTo":"32541b130807301407m59eef936m5e07dd33a4eb5b04@mail.gmail.com","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-30T22:02:36Z","receivedAt":"2008-07-30T22:02:36Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Jul 30, 2008 at 05:07:49PM -0400, Avery Pennarun wrote:\n> \n> FWIW, this problem would apply to any system that incrementally\n> imports into git from another system using binary deltas.\n\nNot necessary. It depends on how import is done. You should not apply\nthis binary deltas to your working tree, but to files in the repo. And\nobviously those files that are imported should be stored as is without\nany conversion. In the same way as if you clone some git repo, you do\nnot apply any commit conversion to any existing commit. This conversion\nshould be done for *new* commits that you create locally.\n\nSo, the problem with git-svn is mostly due to how the import is done. Of\ncourse, the other part of that problem is that conversion setting in Git\nand SVN for text files specified very differently.\n\nDmitry\n"},{"id":"85698","messageId":"32541b130807301514j43e98003gf1da1b61dbee499@mail.gmail.com","threadId":"14603","inReplyTo":"20080730220236.GD7008@dpotapov.dyndns.org","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-30T22:14:38Z","receivedAt":"2008-07-30T22:14:38Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/30/08, Dmitry Potapov wrote:\n> On Wed, Jul 30, 2008 at 05:07:49PM -0400, Avery Pennarun wrote:\n> > FWIW, this problem would apply to any system that incrementally\n> > imports into git from another system using binary deltas.\n>\n> Not necessary. It depends on how import is done. You should not apply\n> this binary deltas to your working tree, but to files in the repo. And\n> obviously those files that are imported should be stored as is without\n> any conversion. In the same way as if you clone some git repo, you do\n> not apply any commit conversion to any existing commit. This conversion\n> should be done for *new* commits that you create locally.\n>\n> So, the problem with git-svn is mostly due to how the import is done. Of\n> course, the other part of that problem is that conversion setting in Git\n> and SVN for text files specified very differently.\n\nHmm, if your first paragraphis true (do not apply any commit\nconversion to any existing commit), then in fact SVN's method for\nspecifying text files doesn't really matter, right? It's just a bug\nin git-svn.\n\nIs it possible to have git-svn override core.autocrlf temporarily? If\nsomeone can give me a hint how to do that, I don't mind working up a\npatch for that. I can't see any situation where *not* doing so would\neven work (unless core.autocrlf=false already, of course).\n\nHave fun,\n\nAvery\n"},{"id":"85978","messageId":"3687C337-63B7-4F3E-9682-8B140FFB4D53@orakel.ntnu.no","threadId":"14603","inReplyTo":"20080730214521.GC7008@dpotapov.dyndns.org","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind-git@orakel.ntnu.no","sentAt":"2008-08-02T12:51:28Z","receivedAt":"2008-08-02T12:51:28Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 30. juli. 2008, at 23.45, Dmitry Potapov wrote:\n\n> On Tue, Jul 29, 2008 at 11:17:23PM +0200, Eyvind Bernhardsen wrote:\n>>\n>> My point was that autocrlf penalises Windows users just as much as it\n>> does Linux users, so why should it be turned on by default on\n>> Windows?\n>\n> Because it does make sense on Windows (I mentioned some reasons for \n> that\n> in my previous email), and it does NOT make any sense on Linux unless\n> you copy files from Windows.\n\nIt doesn't make any more sense on Windows than it does on Linux, \nunless the user is careless about CRLFs and the repository will be \nshared with Linux users. If you have to work with undisciplined \nWindows users but don't actually use Windows yourself, it might _seem_ \nto make sense, but that is an illusion.\n\n>>> And the main argument for having that in this way is that people\n>>> with LF\n>>> text files should be unnecessary penalized for Windows being\n>>> different.\n>>\n>> I know, but my point is that I don't like to be unnecessarily\n>> penalised any more when I am using Windows than when I'm using Linux\n>> or OS X.\n>\n> It seems you still have not realized that from the very day when you\n> started to use Windows, you are penalized for that day-in, day-out.\n> Let's take something simple. For instance, the hello-world program:\n> cat <<=== > hello.c\n> #include \n> int main() {\n> \tprintf (\"Hello world!\\n\");\n> \treturn 0;\n> }\n> ===\n>\n> You can compile it on Linux and Windows (using Microsoft Visual C).\n> Now, if you run it on Linux, it will print 13 symbols (exactly\n> as many as there are symbols in the printf string) while on Windows\n> you will get 14 bytes. It means that printf and as many other C\n> function on Windows does conversion and penalize you already!\n\nBut I don't use printf to store files. What does printf have to do \nwith anything?\n\nBtw, I'm not actually a \"natural\" Windows user; I have a Mac on my \ndesktop, and I prefer Linux to Windows on my own PCs. I often use \nWindows at work, though, and I'm trying to make Git work as well as \npossible when I do.\n\n>> I would like the default to be \"no conversion\", and for\n>> conversion to be enabled not based on platform, but as a policy\n>> decision on the repositories where it actually matters.\n>\n> If Microsoft C library did not do any conversion, I suspect we would\n> have this CRLF conversion at all!\n\nSurely, but unfortunately, I don't live in happy fairy land.\n\n>> You can have anything you like in _your_ repository, of course, but \n>> if\n>> you're not publishing it anywhere, who cares what your line endings\n>> are? Your line endings only matter when you publish.\n>\n> You can publish only what you have. So, it must decided before.\n\nYes! Someone should decide that the repository should only have LFs \nin it, then flag it as such so that Git can respect that decision.\n\n>> That's why I\n>> want a setting that is propagated: so that when you clone a \n>> repository\n>> with a LF-only policy, Git knows what to do.\n>\n> LF-only policy is the only sane policy for any text files. It has \n> nothing\n> to do with clone.\n\nGah! So close, but so far. What about a repository which already has \nCRLFs in it? You're telling me that it shouldn't have CRLFs in it, \nwhich is almost entirely unhelpful.\n\n>> I think the real penalty is that with autocrlf enabled, Git no longer\n>> stores exactly what I committed.\n>\n> And what is wrong with that? In any case, Git deltifies and compress\n> your files. Why does it not bother you? So, what matters here is\n> whether you are able to get back exactly what you put or not. That's\n> why Git has this safecrlf option! Of course, it is guarantee to get\n> exactly the same back only if you have the same autocrlf setting,\n> but if you have different autocrlf settings, it means that you want\n> *different* representation of text files!\n\nMy point is that if I commit two files with different line endings, I \nwant Git to store them that way. Works on Linux by default, doesn't \nwork on Windows by default. Deltification and compression are \nirrelevant since they don't change the content. autocrlf does.\n\nYou only want to normalise text files if you (a) have undisciplined \ncommitters, and (b) need to share the repository between Windows and \nUnix. Right now, the default configuration of Git assumes that all \nWindows users are undisciplined, and that they will always be sharing \nrepositories with Unix users.\n\n>>> Of course, those who are very careful and have good editors can set\n>>> autocrlf=false even on Windows...\n>>\n>> Right, or who know that the repository they're using will only be\n>> shared with other Windows users.\n>\n> WRONG! Using storing CRLF in text files is a completely idiotic idea.\n> Those who do so asked for troubles, so they should not complain!\n\nBut some text files need CRLFs, the autocrlf mechanism even caters for \nthem. And it's not like the extra CR actually hurts anything; I use \nGit on Windows with \"autocrlf=false\", and I've yet to see any problems \nwith it. The reason I've changed from the default \"autocrlf=true\" is \nthat I've seen plenty of problems with that.\n\n>> Internally, Git doesn't really care, does it?\n>\n> It DOES!!! Such things like merges and diffs and many other every day\n> commands do care about end-of-lines and the ONLY end-of-line they\n> recognize is '\\n'. In fact, there are more than 400 places in Git \n> where\n> '\\n' is used. Of course, not all of them may be qualified as internals\n> but many of them do.\n\nBuh? That's crazy talk. The only time CRLFs cause trouble with git \nis when autocrlf is enabled. Try this:\n\n\ngit init\necho -n \"testing\\r\\ntesting 2\\r\\n\" > testing\ngit add testing\ngit commit\ngit config --bool --add core.autocrlf true\ntouch testing\ngit diff\n\n\nFile with CRLF in the repository, file with CRLF in the working \ndirectory, so where does the difference come from? The same thing \nhappens with \"autocrlf=input\", and the problem is obviously a lot \nbigger when you're trying to merge.\n\nNow I've shown you when autocrlf is a problem, you show me a case \nwhere CRLFs cause trouble with autocrlf=false.\n\n> So, as long as Git internally consider only LF as the end-of-line.\n\nBah. To the extent it \"cares\", Git just sees CR as an extra white \nspace character before the end-of-line LF, and you know it.\n\n>> Heh. Where I work, we hacked CVS for Windows to get away from that\n>> behaviour :)\n>\n> Maybe, you used Cygwin version of CVS, which had LF, but those Windows\n> versions of CVS I used produced CRLF on Windows.\n\nNo, we just compiled our own, precisely because we didn't want CVS to \nmangle our data, even on Windows. The CVS repositories are used by \nLinux and Windows clients, and some developers had their working \ndirectories on cross-platform network shares, so eol conversion just \ncaused unnecessary problems.\n\n>> Well, what I want is to be able to say \"it is necessary to do eol\n>> conversion in this repository\",\n>\n> You always can do that in _your_ repository:\n> git config core.autocrlf ...\n\nI can, except that (a) any CRLFs already in the repository will cause \ntrouble, and (b) everyone who clones from me has to make the same \nsetting manually, or they won't follow the same convention.\n\n>> allowing the default to be \"don't do\n>> eol conversion\" on Windows, too. For a setting like that to be\n>> useful, it has to be propagated when the repository is cloned.\n>\n> Why? Other people may have other preferences.\n\nYes. Other people may have other preferences which will lead them to \npush CRLFs to my repository. That is why the setting should be \npropagated.\n\n>> I want it to be versioned because you might want to change it without\n>> messing with the content that's already in the repository. This is\n>> actually my main motivation, since I have lots of CRLF-infused CVS\n>> history to deal with.\n>\n> Well, you can try to use .gitattributes, but I believe it would be far\n> more reasonable to clean this mess with line-ending than finding a\n> way to continue insanity with different ending in different text \n> files.\n\nBut I'd rather not change the historical data in every repository. So \nyes, I think it's a good idea to clean up the line endings, but I \nwould like to do it in a way that allows me to check out an old \nversion with mixed line endings while still ensuring that newly \ncommitted files are normalised.\n\n>> It should apply on Linux as well as Windows because there is always\n>> the chance that a user will manage to commit a CRLF on Linux (a\n>> colleague of mine once complained that CVS on Linux doesn't do eol\n>> conversion; he edited files on Windows, but checked them in on\n>> Linux).\n>\n> For those who need it, Git provides autocrlf=input. But the question\n> here is what should be default. I don't think that those who copies\n> files directly from Windows to Linux are majority. OTOH, I don't\n> mind autocrlf=input as default. If it can be turned off, it is fine\n> with me :)\n\nYeah, if autocrlf is set, it probably makes sense to use it, i.e. \nanyone who doesn't want line ending conversion at all can set \n\"autocrlf=false\".\n\n>> It would probably be okay to have a setting that turns all\n>> conversion off, but wouldn't that be kind of rude?\n>\n> How so?\n\nYou're explicitly saying \"I don't care if I commit CRLFs into a \nrepository that requests only LFs\". So you're probably only saying it \nbecause you know you won't commit CRLFs anyway, but since the cost is \nso low, why not make sure?\n-- \nEyvind Bernhardsen\n"},{"id":"86083","messageId":"20080803162133.GO7008@dpotapov.dyndns.org","threadId":"14603","inReplyTo":"3687C337-63B7-4F3E-9682-8B140FFB4D53@orakel.ntnu.no","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-08-03T16:21:33Z","receivedAt":"2008-08-03T16:21:33Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sat, Aug 02, 2008 at 02:51:28PM +0200, Eyvind Bernhardsen wrote:\n> On 30. juli. 2008, at 23.45, Dmitry Potapov wrote:\n> \n> >On Tue, Jul 29, 2008 at 11:17:23PM +0200, Eyvind Bernhardsen wrote:\n> >>\n> >>My point was that autocrlf penalises Windows users just as much as it\n> >>does Linux users, so why should it be turned on by default on\n> >>Windows?\n> >\n> >Because it does make sense on Windows (I mentioned some reasons for \n> >that\n> >in my previous email), and it does NOT make any sense on Linux unless\n> >you copy files from Windows.\n> \n> It doesn't make any more sense on Windows than it does on Linux, \n> unless the user is careless about CRLFs and the repository will be \n> shared with Linux users.\n\nIt does, because LF is the only EOL that Git recognize internally,\nand if CRLF sometimes works, but it is an artifact. With the same\nsuccess you can rely on a value of uninitialized variable or any\nother kind of undefined behavior.\n\n> If you have to work with undisciplined \n> Windows users but don't actually use Windows yourself, it might _seem_ \n> to make sense, but that is an illusion.\n\nIllusion? Is the most logical objection that you capable to produce\nto all my explanation? I think it is very convenient approach, but\nshall we follow it a bit further and declare all your problem with\nline endings just an illusion...\n\n> >You can compile it on Linux and Windows (using Microsoft Visual C).\n> >Now, if you run it on Linux, it will print 13 symbols (exactly\n> >as many as there are symbols in the printf string) while on Windows\n> >you will get 14 bytes. It means that printf and as many other C\n> >function on Windows does conversion and penalize you already!\n> \n> But I don't use printf to store files. What does printf have to do \n> with anything?\n\nYou missed the point entirely, did you? LF is the standard EOL in C (as\nwell as in many other languages that is used by Git developers). Thus,\nnaturally Git internally considers only LF as the only true EOL, and if\nit happened that you store files with different EOLs, they should be\nconverted during import to the Git repository. And, yes, C programs\ndo use printf and other C library functions to write text files...\nWhy do you think Microsoft C library does convert CRLF on reading and\nwriting for text files? Or that is another illusion?\n\n> >>You can have anything you like in _your_ repository, of course, but \n> >>if\n> >>you're not publishing it anywhere, who cares what your line endings\n> >>are? Your line endings only matter when you publish.\n> >\n> >You can publish only what you have. So, it must decided before.\n> \n> Yes! Someone should decide that the repository should only have LFs \n> in it, then flag it as such so that Git can respect that decision.\n\nWhat is your point?! Git *does* respect your autocrlf choice. But it\nalso respects *other* people choice to have what they want in *their*\nrepositories.\n\n> \n> >>That's why I\n> >>want a setting that is propagated: so that when you clone a \n> >>repository\n> >>with a LF-only policy, Git knows what to do.\n> >\n> >LF-only policy is the only sane policy for any text files. It has \n> >nothing\n> >to do with clone.\n> \n> Gah! So close, but so far. What about a repository which already has \n> CRLFs in it? You're telling me that it shouldn't have CRLFs in it, \n> which is almost entirely unhelpful.\n\nWhat I am saying is that having CRLF for text files is a mistake, and it\nshould be dealt as that. Perhaps, something can be added to help people\nto deal with their past mistakes, but by no means, we should encourage\nto produce more crap... So far, I have not heard any rational suggestion,\nlet alone seeing your code that implements it.\n\n> \n> My point is that if I commit two files with different line endings, I \n> want Git to store them that way.\n\nIf you want something insane, you can have that, but the insane mode is\nnot for normal users. So, it should not be default.\n\n> Works on Linux by default, doesn't \n> work on Windows by default.\n\nSo what? Sane people do NOT store text files with different endings,\nespecially on Linux...\n\n> >>>Of course, those who are very careful and have good editors can set\n> >>>autocrlf=false even on Windows...\n> >>\n> >>Right, or who know that the repository they're using will only be\n> >>shared with other Windows users.\n> >\n> >WRONG! Using storing CRLF in text files is a completely idiotic idea.\n> >Those who do so asked for troubles, so they should not complain!\n> \n> But some text files need CRLFs, the autocrlf mechanism even caters for \n> them. And it's not like the extra CR actually hurts anything; I use \n> Git on Windows with \"autocrlf=false\", and I've yet to see any problems \n> with it. The reason I've changed from the default \"autocrlf=true\" is \n> that I've seen plenty of problems with that.\n\nWhat problems? Isn't true that these problems were caused in the first\nplace by having autocrlf=false? If you prefer CRLF for your text files\nwhat exactly is your problem with having crlf=true? Your old history?\nBut why should other users suffer because you have messed up file\nendings in your repository?\n\nPerhaps, it would be nicer if Git saved autocrlf when created a new\nrepository, so if the global setting is changed, it will not affect\nalready existing repositories. I believe something like that can be\nadded. In fact, Junio mentioned about this possibility before, but\nyou do not seem to care to do _anything_ to improve the situation,\nand when I say to do something, I don't mean just empty flame.\n\n> \n> >>Internally, Git doesn't really care, does it?\n> >\n> >It DOES!!! Such things like merges and diffs and many other every day\n> >commands do care about end-of-lines and the ONLY end-of-line they\n> >recognize is '\\n'. In fact, there are more than 400 places in Git \n> >where\n> >'\\n' is used. Of course, not all of them may be qualified as internals\n> >but many of them do.\n> \n> Buh? That's crazy talk. The only time CRLFs cause trouble with git \n> is when autocrlf is enabled. Try this:\n> \n> \n> git init\n> echo -n \"testing\\r\\ntesting 2\\r\\n\" > testing\n> git add testing\n> git commit\n> git config --bool --add core.autocrlf true\n> touch testing\n> git diff\n\nThat is *exactly* why autocrlf=true should be default on Windows, as you\nwant to have at the very moment when a new repository is created! Thanks!\n\nAnd, yes, the file is shown changed. You can have the same effect with\nSVN if you did not set svn:eol-style=native when added a file and then\nchange it to svn:eol-style=native later. The issue here is that you have\nwrong ending for text files in the first place.\n\n> >So, as long as Git internally consider only LF as the end-of-line.\n> \n> Bah. To the extent it \"cares\", Git just sees CR as an extra white \n> space character before the end-of-line LF, and you know it.\n\nI know, and I also know that I don't like crap in my repository and\nI don't like any tool that encourages users to put every crap in it.\nAnd, no, I don't think that that check-in-all-crap-I-have should be\nthe default mode for Git. If you like that mode, you probably can set\nautocrlf=false and also create some nice alias for git commit -a, so\nyou check-in all crap crap at once, but I can't care less about all\nproblems that you'll have after that.\n\n> \n> >>Heh. Where I work, we hacked CVS for Windows to get away from that\n> >>behaviour :)\n> >\n> >Maybe, you used Cygwin version of CVS, which had LF, but those Windows\n> >versions of CVS I used produced CRLF on Windows.\n> \n> No, we just compiled our own, precisely because we didn't want CVS to \n> mangle our data, even on Windows.\n\n*Shrug* All I can say I don't remember any problem like this with CVS,\nand it did conversion automatically for us. Unfortunately, it converted\nbinary files too, so new users had to be taught about using 'cvs -kb'\nor their binary files would be mutilated. So, I am pretty sure about\nthis. Perhaps, the difference was that we has always had our CVS server\non Linux, but we have not recompiled anything.\n\n> The CVS repositories are used by \n> Linux and Windows clients, and some developers had their working \n> directories on cross-platform network shares, so eol conversion just \n> caused unnecessary problems.\n\nSharing working directories is a real issue. I hit it myself once with\nCVS. Fortunately, git provides a good solution: autocrlf=input.\n\n> \n> >>Well, what I want is to be able to say \"it is necessary to do eol\n> >>conversion in this repository\",\n> >\n> >You always can do that in _your_ repository:\n> >git config core.autocrlf ...\n> \n> I can, except that (a) any CRLFs already in the repository will cause \n> trouble,\n\nSure, they will. It is insane ending to store in your repo. It was\nexactly my point all way along, but somehow you missed that...\n\n> and (b) everyone who clones from me has to make the same \n> setting manually, or they won't follow the same convention.\n\nIf people follow sane settings, they do not have to change anything\nmanually, and they can edit file using *their* preferable EOLs. However,\nif you publish a repo with CRLF for text files, *you* create problems\nfor other people, and they have every right to blame you for that.\n\n> \n> Yes. Other people may have other preferences which will lead them to \n> push CRLFs to my repository. That is why the setting should be \n> propagated.\n\nAdd the update hook, which will prevent pushes with the wrong ending.\n\n> \n> >>I want it to be versioned because you might want to change it without\n> >>messing with the content that's already in the repository. This is\n> >>actually my main motivation, since I have lots of CRLF-infused CVS\n> >>history to deal with.\n> >\n> >Well, you can try to use .gitattributes, but I believe it would be far\n> >more reasonable to clean this mess with line-ending than finding a\n> >way to continue insanity with different ending in different text \n> >files.\n> \n> But I'd rather not change the historical data in every repository. So \n> yes, I think it's a good idea to clean up the line endings, but I \n> would like to do it in a way that allows me to check out an old \n> version with mixed line endings while still ensuring that newly \n> committed files are normalised.\n\nWell, I don't see much historical value in seeing what files had\nwhat ending and at what time. So, usually, it is a good idea to\nclean up them when you convert your repo into Git. But as I said\nabove, you can try to use .gitattributes.\n\nAnyway, autocrlf=true makes much more sense as default, because\nnewly created repositories and files in them will have the correct\nending.\n\n> >>It would probably be okay to have a setting that turns all\n> >>conversion off, but wouldn't that be kind of rude?\n> >\n> >How so?\n> \n> You're explicitly saying \"I don't care if I commit CRLFs into a \n> repository that requests only LFs\".\n\nNaw! autocrlf=false means you take responsibility for EOL in files that\nyou check in. In fact, no version control system that can verify that\nall what you check-in makes sense. So it can only _facilitate_ you in\ncreating good patches, but it cannot force you to do things in the right\nway. Thus, any option that helps people to do their job is good, but you\ncannot foresee all use cases, so it should be always choice to turn this\nautomatically thing off when it is necessary.\n\n> So you're probably only saying it \n> because you know you won't commit CRLFs anyway, but since the cost is \n> so low, why not make sure?\n\nWho are you to tell what cost is high and low? Why do you think that\nyou should dictate your idea of cost to *everyone*?\n\n\nDmitry\n"},{"id":"86085","messageId":"905315640808030954j7487a010p136c73406298ee29@mail.gmail.com","threadId":"14603","inReplyTo":"56C07978-D6C9-4219-8B92-6217BD33F6D4@zib.de","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Tarmigan","fromEmail":"tarmigan+git@gmail.com","sentAt":"2008-08-03T16:54:42Z","receivedAt":"2008-08-03T16:54:42Z","isPatch":true,"sender":{"key":"tarmigan+git@gmail.com","avatar":null},"body":"On Wed, Jul 30, 2008 at 12:25 PM, Steffen Prohaska wrote:\n>\n> On Jul 30, 2008, at 8:33 PM, Avery Pennarun wrote:\n>\n>> On 7/30/08, Steffen Prohaska wrote:\n>>\n>>> What matters is that git gives you exactly back what you committed. It\n>>> does so with core.autocrlf=true, unless you check out with a different\n>>> setting for autocrlf.\n>>\n>> You can tell that this statement isn't quite true because if you have\n>> a file with mixed LF and CRLF line endings, which I do (thanks,\n>> Windows!) then CRLF->LF conversion is not a reversible operation.\n>> Interestingly LF->CRLF still is (because an LF->CRLF'd file will never\n>> have a bare LF, and on such a subset of files, CRLF->LF is\n>> reversible).\n>>\n>> Also note that core.autocrlf=input is *definitely* not a perfectly\n>> reversible operation.\n>\n> You are absolutely right. The files your describe are modified by git,\n> because they are \"invalid\" text files, as git defines them.\n\nFor all I care, git can consider the files as binary, but by *default*\nI should get back the same as I put in.\n\n[For the rest of my rant, I am referring to the default configuration\nof autocrlf on windows]\n\n> For git's\n> autocrlf mechanism to work, a text file is only allowed to have a\n> *single* type of line endings.\n\nGit's autocrlf mechanism can be a nice feature. But by default it\nshould not be on (even on windows) because it can modify screw up my\nfiles.\n\nTo be clear: when I say \"git checkout\" I want to get EXACTLY the same\nbits as went in when I did \"git add\" and \"git commit\". Any other\ndefault is broken.\n\n> Otherwise it is broken and git tries to\n> help you fixing it.\n\nMy files were NOT broken when I put them into git. I committed them\nknown good state. If msysgit changes them by *default* , then msysgit\nis broken.\n\nIF you are working on a cross platform project, then setting autocrlf\non windows might be nice. But having it on by *default* is broken.\n\nThanks,\nTarmigan\n"},{"id":"86089","messageId":"20080803173339.GQ7008@dpotapov.dyndns.org","threadId":"14603","inReplyTo":"905315640808030954j7487a010p136c73406298ee29@mail.gmail.com","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-08-03T17:33:39Z","receivedAt":"2008-08-03T17:33:39Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, Aug 03, 2008 at 09:54:42AM -0700, Tarmigan wrote:\n> \n> For all I care, git can consider the files as binary, but by *default*\n> I should get back the same as I put in.\n\nSorry, but Git is a source control system, and by definition the\nmain focus is on *text* files. Storying binary files is *exception*\nnot the rule. And the default settings should respect exactly that\nfact.\n\n> > For git's\n> > autocrlf mechanism to work, a text file is only allowed to have a\n> > *single* type of line endings.\n> \n> Git's autocrlf mechanism can be a nice feature. But by default it\n> should not be on (even on windows) because it can modify screw up my\n> files.\n> \n> To be clear: when I say \"git checkout\" I want to get EXACTLY the same\n> bits as went in when I did \"git add\" and \"git commit\". Any other\n> default is broken.\n\nYou will get exactly the same unless you change your autocrlf settings.\nThere are very rare situation where automatic heuristic can be wrong,\nbut even then you will be warned about that the file you are going to\ncheckout different. See core.safecrlf.\n\n> \n> > Otherwise it is broken and git tries to\n> > help you fixing it.\n> \n> My files were NOT broken when I put them into git. I committed them\n> known good state. If msysgit changes them by *default* , then msysgit\n> is broken.\n\nText files committed with CRLF inside of your repository is BROKEN by\ndefinition! So you had BROKEN state in the first place.\n\nOf course, changing the global autocrlf setting should not change\nautocrlf settings in already existing repositories, as it currently\ndoes. Care to provide patch?\n\n\nDmitry\n"},{"id":"86093","messageId":"905315640808031154j28778cd6pee75e6b008304941@mail.gmail.com","threadId":"14603","inReplyTo":"20080803173339.GQ7008@dpotapov.dyndns.org","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Tarmigan","fromEmail":"tarmigan+git@gmail.com","sentAt":"2008-08-03T18:54:34Z","receivedAt":"2008-08-03T18:54:34Z","isPatch":true,"sender":{"key":"tarmigan+git@gmail.com","avatar":null},"body":"On Sun, Aug 3, 2008 at 10:33 AM, Dmitry Potapov wrote:\n> On Sun, Aug 03, 2008 at 09:54:42AM -0700, Tarmigan wrote:\n>>\n>> For all I care, git can consider the files as binary, but by *default*\n>> I should get back the same as I put in.\n>\n> Sorry, but Git is a source control system,\n\nI think this is the heart of the disagreement. What I love about git\nis that git trusts me, the user, and it trusts my files. It doesn't\nchange the encoding of my filenames by default. It doesn't do keyword\nexpansion by default. It doesn't change the case of filenames by\ndefault.\n\nIf git is not willing to change the encoding/case of file*names* by\ndefault, how is it acceptable to change the *content* of the files\nthemselves?\n\nYes, some systems that define themselves as \"source control\nmanagement\" systems make these changes for you. But that sometimes\nleads to frustrating and hard to understand (to the user) behavior.\nGit has a very simple and transparent mental model, which is one of\nit's greatest strengths. In my humble opinion, autocrlf breaks this\nsimple \"content tracker\" model.\n\nBreaking this mental model bothers me much more than the practical\nissues involved with autocrlf, so I'm just going to drop that line of\nargument.\n\nThanks,\nTarmigan\n"},{"id":"86211","messageId":"20080804160630.GW7008@dpotapov.dyndns.org","threadId":"14603","inReplyTo":"905315640808031154j28778cd6pee75e6b008304941@mail.gmail.com","subject":"Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-08-04T16:06:30Z","receivedAt":"2008-08-04T16:06:30Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, Aug 03, 2008 at 11:54:34AM -0700, Tarmigan wrote:\n> On Sun, Aug 3, 2008 at 10:33 AM, Dmitry Potapov wrote:\n> > On Sun, Aug 03, 2008 at 09:54:42AM -0700, Tarmigan wrote:\n> >>\n> >> For all I care, git can consider the files as binary, but by *default*\n> >> I should get back the same as I put in.\n> >\n> > Sorry, but Git is a source control system,\n> \n> I think this is the heart of the disagreement.\n\nI guess so... Because for me it is very important that most of files I\nstore are text files. In fact, such operations as diff and merge would\nnot make much sense for binary files, would they? IOW, Git is a revision\ncontrol system, not a versioning file system.\n\n> What I love about git\n> is that git trusts me, the user, and it trusts my files.\n\nSure, git trusts you. You can always turn off some features if you don't\nlike them; but the issue having the right defaults. autocrlf=true is the\nright default if you want to have CRLF in your work directory. And as\nlong as text heuristic is right (and it works pretty damn good), you get\nexactly what you put in it. In very very rare cases where the heuristic\nis wrong, it will warn you about that you are not going to have back what\nyou put. So, you can tell Git explicitly that you want this file stored\nas binary. But this situation is very unlikely unless you store in it\nsomething like svndump files, but storying such files in not the main\npurpose of Git.\n\nSo, I don't think that this CRLF conversion is a real issue, except that\nthe fact that changing the global autocrlf value should not have changed\nautocrlf in already existing repositories. Because autocrlf is not just\na preference, but also determines in what format your files in the working\ndirectory are stored. So, I believe it should be corrected. But even in\nthis case, you do not really lose anything.\n\n> It doesn't change the encoding of my filenames by default.\n\nAnd not by default? Currently, does not support encoding filenames\nfrom your local encoding to UTF-8. And that will be a problem at\nsome point if you store file names in non UTF-8 encoding. But it is\na separate issue connected to i18n support. I don't think it makes\nsense to go into it right now as it is completely irrelevant to the\nproblem we discuss.\n\nWhat is relevant is that Git *does* change filename representation.\nFor instance, if you try to add a file with a name 'foo\\bar', Git\nwill actually add 'foo/bar'. You see, on check-in, Git converts the\ndirectory separator from its Windows form ('\\') to the format it uses\ninternally ('/').\n\nSo, it is logical to do the same text files, because text files are\nsequences of lines separated by line-separator, which is CRLF on\nWindows, but its internal representation in Git is LF.\n\n> It doesn't do keyword expansion by default.\n\nBecause keyword expansion is almost always meaningless thing to do\nin your working directory. It just makes things slower and you do\nnot win *anything*. Arguably, there are some cases when you may\nwant some expansion during export your sources to archive, but even\nthat is very uncommon.\n\n> It doesn't change the case of filenames by default.\n\nChange case? Would it not be a completely insane thing to do? People put\nsome meaning in what registry of letters when wrote names, why would you\nwant Git (or any source control system) to mess up with that?\n\n> If git is not willing to change the encoding/case of file*names* by\n> default, how is it acceptable to change the *content* of the files\n> themselves?\n\nIt does not change the content, it changes the EOL marker from its\nexternal to internal representation. It does the same thing as what C\nlibrary on Windows does when you read or write files in the text mode.\nThis should be completely transparent to users as long as autocrlf is\nnot changed.\n\n\nDmitry\n"}]}