{"thread":{"id":"23789","subject":"[RFC/PATCH v3 4/5] Rename \"crlf\" attribute as \"eolconv\"","startedAt":"2010-05-12T23:00:50Z","lastAt":"2010-05-16T13:32:59Z","messageCount":27,"participants":["Eyvind Bernhardsen","Linus Torvalds","Robert Buck","Jonathan Nieder","Dmitry Potapov","Tait"],"isPatch":true,"patchVersion":3,"patchTotal":5},"messages":[{"id":"141551","messageId":"cover.1273700831.git.eyvind.bernhardsen@gmail.com","threadId":"23789","inReplyTo":null,"subject":"[PATCH v3 0/5] End-of-line normalization, redesigned","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-12T23:00:50Z","receivedAt":"2010-05-12T23:00:50Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"After Finn Arne's bombshell of a patch, I was almost ready to throw in\nthe towel on this series. Then I realized that just because autocrlf\nis safe to use now doesn't mean it solves my CRLF-related problems.\n\nThe reason is that since autocrlf doesn't require your text files to\nbe normalized any more, it also doesn't guarantee that they are. If\nyou need to interoperate with some other SCM, have tools that require\na specific line ending, or you just like your repository free of CR\ncharacters, autocrlf doesn't do that.\n\nThis series does that. There have been some changes since v2:\n\n- Series is now based on Finn Arne's \"safe autocrlf\" patch (I took the\n one from \"pu\" since Junio seems to have fixed some whitespace\n damage).\n\n- Removed core.eolStyle. This gets more explanation below.\n\n- Added \"crlf=lf\" and \"crlf=crlf\"; they turn on normalization and\n convert line endings to LF or CRLF on checkout, respectively. Yes,\n I know.\n\n- RFC patch: As promised, rename \"crlf\" attribute as \"eolconv\",\n keeping \"crlf\" as an alias for backwards compatibility. I think\n this one might be worth it, but perhaps not as implemented (see the\n fix I made for git-cvsserver.perl to understand why).\n\n- RFC patch: Rename \"core.autocrlf\" as \"core.eolconv\". This one is\n mainly for fun, not so much for inclusion: it might have the same\n problems as adding an alias for \"crlf\" and I'm not too bothered\n about the name any more anyway, as I'll explain below.\n\n\nSo if I've removed eolStyle, how does the user say what line endings\nto use for a normalized text file in the working directory? Using\n\"core.autocrlf\". There are three reasons why that isn't completely\ninsane:\n\n1. A user who wants CRLFs in text files probably doesn't want them\n just in files that happen to have normalized line endings.\n\n2. You can force CRLF in the working directory now, so if you just\n want .vcproj files and the like to have CRLFs, you check in a\n .gitattributes containing \"*.vcproj crlf=crlf\" or add that line to\n your .git/info/attributes. No need to use autocrlf at all.\n\n3. With the \"safe autocrlf\" patch, core.autocrlf is actually safe to\n use in a non-normalized repository, so \"core.autocrlf=true\" is no\n longer an insane default.\n\nGiven the intended usage for autocrlf it's not even a particularly bad\nname any more: \"I don't care how you do it, I just want CRLFs in my\ntext files\". Even \"autocrlf=input\" isn't that bad if you squint a\nbit. After a few beers.\n\nSummary: the new \"core.autocrlf\" is for when you don't want to mess up\nan existing repository with unwanted CRLFs, and the new \"crlf\"\nmechanisms are for normalizing text files.\n\n\nEyvind Bernhardsen (4):\n Add tests for per-repository eol normalization\n Add per-repository eol normalization\n Rename \"crlf\" attribute as \"eolconv\"\n Rename \"core.autocrlf\" config variable as \"core.eolconv\"\n\nFinn Arne Gangstad (1):\n autocrlf: Make it work also for un-normalized repositories\n\n Documentation/config.txt | 26 ++++---\n Documentation/gitattributes.txt | 157 ++++++++++++++++++++++++++++++---------\n attr.c | 2 +-\n cache.h | 9 ++-\n config.c | 13 ++-\n convert.c | 115 +++++++++++++++++++++++-----\n environment.c | 2 +-\n git-cvsserver.perl | 8 ++-\n t/t0020-crlf.sh | 106 ++++++++++++++++++++++++++\n t/t0025-crlf-auto.sh | 134 +++++++++++++++++++++++++++++++++\n 10 files changed, 497 insertions(+), 75 deletions(-)\n create mode 100755 t/t0025-crlf-auto.sh\n"},{"id":"141552","messageId":"4dc62dfef759eca02dd7debd833b25ac47956370.1273700831.git.eyvind.bernhardsen@gmail.com","threadId":"23789","inReplyTo":"cover.1273700831.git.eyvind.bernhardsen@gmail.com","subject":"[PATCH v3 1/5] autocrlf: Make it work also for un-normalized repositories","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-12T23:00:51Z","receivedAt":"2010-05-12T23:00:51Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"From: Finn Arne Gangstad \n\nPreviously, autocrlf would only work well for normalized\nrepositories. Any text files that contained CRLF in the repository\nwould cause problems, and would be modified when handled with\ncore.autocrlf set.\n\nChange autocrlf to not do any conversions to files that in the\nrepository already contain a CR. git with autocrlf set will never\ncreate such a file, or change a LF only file to contain CRs, so the\n(new) assumption is that if a file contains a CR, it is intentional,\nand autocrlf should not change that.\n\nThe following sequence should now always be a NOP even with autocrlf\nset (assuming a clean working directory):\n\ngit checkout \ntouch *\ngit add -A . (will add nothing)\ngit commit (nothing to commit)\n\nPreviously this would break for any text file containing a CR.\n\nSome of you may have been folowing Eyvind's excellent thread about\ntrying to make end-of-line translation in git a bit smoother.\n\nI decided to attack the problem from a different angle: Is it possible\nto make autocrlf behave non-destructively for all the previous problem cases?\n\nStealing the problem from Eyvind's initial mail (paraphrased and\nsummarized a bit):\n\n1. Setting autocrlf globally is a pain since autocrlf does not work well\n with CRLF in the repo\n2. Setting it in individual repos is hard since you do it \"too late\"\n (the clone will get it wrong)\n3. If someone checks in a file with CRLF later, you get into problems again\n4. If a repository once has contained CRLF, you can't tell autocrlf\n at which commit everything is sane again\n5. autocrlf does needless work if you know that all your users want\n the same EOL style.\n\nI belive that this patch makes autocrlf a safe (and good) default\nsetting for Windows, and this solves problems 1-4 (it solves 2 by being\nset by default, which is early enough for clone).\n\nI implemented it by looking for CR charactes in the index, and\naborting any conversion attempt if this is found.\n\nSigned-off-by: Finn Arne Gangstad \nSigned-off-by: Junio C Hamano \nSigned-off-by: Eyvind Bernhardsen \n---\n convert.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++\n t/t0020-crlf.sh | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 101 insertions(+), 0 deletions(-)\n\ndiff --git a/convert.c b/convert.c\nindex 4f8fcb7..46622b0 100644\n--- a/convert.c\n+++ b/convert.c\n@@ -120,6 +120,43 @@ static void check_safe_crlf(const char *path, int action,\n \t}\n }\n \n+static int has_cr_in_index(const char *path)\n+{\n+\tint pos, len;\n+\tunsigned long sz;\n+\tenum object_type type;\n+\tvoid *data;\n+\tint has_cr;\n+\tstruct index_state *istate = &the_index;\n+\n+\tlen = strlen(path);\n+\tpos = index_name_pos(istate, path, len);\n+\tif (pos < 0) {\n+\t\t/*\n+\t\t * We might be in the middle of a merge, in which\n+\t\t * case we would read stage #2 (ours).\n+\t\t */\n+\t\tint i;\n+\t\tfor (i = -pos - 1;\n+\t\t (pos < 0 && i < istate->cache_nr &&\n+\t\t !strcmp(istate->cache[i]->name, path));\n+\t\t i++)\n+\t\t\tif (ce_stage(istate->cache[i]) == 2)\n+\t\t\t\tpos = i;\n+\t}\n+\tif (pos < 0)\n+\t\treturn 0;\n+\tdata = read_sha1_file(istate->cache[pos]->sha1, &type, &sz);\n+\tif (!data || type != OBJ_BLOB) {\n+\t\tfree(data);\n+\t\treturn 0;\n+\t}\n+\n+\thas_cr = memchr(data, '\\r', sz) != NULL;\n+\tfree(data);\n+\treturn has_cr;\n+}\n+\n static int crlf_to_git(const char *path, const char *src, size_t len,\n struct strbuf *buf, int action, enum safe_crlf checksafe)\n {\n@@ -145,6 +182,13 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n \t\t */\n \t\tif (is_binary(len, &stats))\n \t\t\treturn 0;\n+\n+\t\t/*\n+\t\t * If the file in the index has any CR in it, do not convert.\n+\t\t * This is the new safer autocrlf handling.\n+\t\t */\n+\t\tif (has_cr_in_index(path))\n+\t\t\treturn 0;\n \t}\n \n \tcheck_safe_crlf(path, action, &stats, checksafe);\n@@ -203,6 +247,11 @@ static int crlf_to_worktree(const char *path, const char *src, size_t len,\n \t\treturn 0;\n \n \tif (action == CRLF_GUESS) {\n+\t\t/* If we have any CR or CRLF line endings, we do not touch it */\n+\t\t/* This is the new safer autocrlf-handling */\n+\t\tif (stats.cr > 0 || stats.crlf > 0)\n+\t\t\treturn 0;\n+\n \t\t/* If we have any bare CR characters, we're not going to touch it */\n \t\tif (stats.cr != stats.crlf)\n \t\t\treturn 0;\ndiff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh\nindex c3e7e32..234a94f 100755\n--- a/t/t0020-crlf.sh\n+++ b/t/t0020-crlf.sh\n@@ -453,5 +453,57 @@ test_expect_success 'invalid .gitattributes (must not crash)' '\n \tgit diff\n \n '\n+# Some more tests here to add new autocrlf functionality.\n+# We want to have a known state here, so start a bit from scratch\n+\n+test_expect_success 'setting up for new autocrlf tests' '\n+\tgit config core.autocrlf false &&\n+\tgit config core.safecrlf false &&\n+\trm -rf .????* * &&\n+\tfor w in I am all LF; do echo $w; done >alllf &&\n+\tfor w in Oh here is CRLFQ in text; do echo $w; done | q_to_cr >mixed &&\n+\tfor w in I am all CRLF; do echo $w; done | append_cr >allcrlf &&\n+\tgit add -A . &&\n+\tgit commit -m \"alllf, allcrlf and mixed only\" &&\n+\tgit tag -a -m \"message\" autocrlf-checkpoint\n+'\n+\n+test_expect_success 'report no change after setting autocrlf' '\n+\tgit config core.autocrlf true &&\n+\ttouch * &&\n+\tgit diff --exit-code\n+'\n+\n+test_expect_success 'files are clean after checkout' '\n+\trm * &&\n+\tgit checkout -f &&\n+\tgit diff --exit-code\n+'\n+\n+cr_to_Q_no_NL () {\n+ tr '\\015' Q | tr -d '\\012'\n+}\n+\n+test_expect_success 'LF only file gets CRLF with autocrlf' '\n+\ttest \"$(cr_to_Q_no_NL < alllf)\" = \"IQamQallQLFQ\"\n+'\n+\n+test_expect_success 'Mixed file is still mixed with autocrlf' '\n+\ttest \"$(cr_to_Q_no_NL < mixed)\" = \"OhhereisCRLFQintext\"\n+'\n+\n+test_expect_success 'CRLF only file has CRLF with autocrlf' '\n+\ttest \"$(cr_to_Q_no_NL < allcrlf)\" = \"IQamQallQCRLFQ\"\n+'\n+\n+test_expect_success 'New CRLF file gets LF in repo' '\n+\ttr -d \"\\015\" < alllf | append_cr > alllf2 &&\n+\tgit add alllf2 &&\n+\tgit commit -m \"alllf2 added\" &&\n+\tgit config core.autocrlf false &&\n+\trm * &&\n+\tgit checkout -f &&\n+\ttest_cmp alllf alllf2\n+'\n \n test_done\n-- \n1.7.1.3.g448cb.dirty\n"},{"id":"141550","messageId":"430831ddc7262b7b9675c18fee8c6ecc9d43831d.1273700831.git.eyvind.bernhardsen@gmail.com","threadId":"23789","inReplyTo":"cover.1273700831.git.eyvind.bernhardsen@gmail.com","subject":"[PATCH v3 2/5] Add tests for per-repository eol normalization","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-12T23:00:52Z","receivedAt":"2010-05-12T23:00:52Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"Signed-off-by: Eyvind Bernhardsen \n---\n t/t0025-crlf-auto.sh | 121 ++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 121 insertions(+), 0 deletions(-)\n create mode 100755 t/t0025-crlf-auto.sh\n\ndiff --git a/t/t0025-crlf-auto.sh b/t/t0025-crlf-auto.sh\nnew file mode 100755\nindex 0000000..40048a7\n--- /dev/null\n+++ b/t/t0025-crlf-auto.sh\n@@ -0,0 +1,121 @@\n+#!/bin/sh\n+\n+test_description='CRLF conversion'\n+\n+. ./test-lib.sh\n+\n+has_cr() {\n+\ttr '\\015' Q <\"$1\" | grep Q >/dev/null\n+}\n+\n+test_expect_success setup '\n+\n+\tgit config core.autocrlf false &&\n+\n+\tfor w in Hello world how are you; do echo $w; done >one &&\n+\tfor w in I am very very fine thank you; do echo ${w}Q; done | q_to_cr >two &&\n+\tgit add . &&\n+\n+\tgit commit -m initial &&\n+\n+\tone=`git rev-parse HEAD:one` &&\n+\ttwo=`git rev-parse HEAD:two` &&\n+\n+\tfor w in Some extra lines here; do echo $w; done >>one &&\n+\tgit diff >patch.file &&\n+\tpatched=`git hash-object --stdin .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\t# Note, \"normalized\" means that git will normalize it if added\n+\thas_cr two &&\n+\ttwodiff=`git diff two` &&\n+\ttest -n \"$twodiff\"\n+'\n+\n+test_expect_failure 'crlf=crlf gives a normalized file CRLFs with autocrlf=false' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf false &&\n+\techo \"one crlf=crlf\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\thas_cr one &&\n+\tonediff=`git diff one` &&\n+\ttest -z \"$onediff\"\n+'\n+\n+test_expect_failure 'crlf=crlf gives a normalized file CRLFs with autocrlf=input' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf input &&\n+\techo \"one crlf=crlf\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\thas_cr one &&\n+\tonediff=`git diff one` &&\n+\ttest -z \"$onediff\"\n+'\n+\n+test_expect_failure 'crlf=lf gives a normalized file LFs with autocrlf=true' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf true &&\n+\techo \"one crlf=lf\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\t! has_cr one &&\n+\tonediff=`git diff one` &&\n+\ttest -z \"$onediff\"\n+'\n+\n+test_expect_success 'autocrlf=true does not normalize CRLF files' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf true &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\thas_cr one &&\n+\thas_cr two &&\n+\tonediff=`git diff one` &&\n+\ttwodiff=`git diff two` &&\n+\ttest -z \"$onediff\" -a -z \"$twodiff\"\n+'\n+\n+test_expect_failure 'crlf=auto, autocrlf=true _does_ normalize CRLF files' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf true &&\n+\techo \"* crlf=auto\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\thas_cr one &&\n+\thas_cr two &&\n+\tonediff=`git diff one` &&\n+\ttwodiff=`git diff two` &&\n+\ttest -z \"$onediff\" -a -n \"$twodiff\"\n+'\n+\n+# look through the logic changes and find the corner cases\n+\n+test_done\n-- \n1.7.1.3.g448cb.dirty\n"},{"id":"141548","messageId":"0d500b523d9c184fe2a2e12c8772ac3d316fe7d1.1273700831.git.eyvind.bernhardsen@gmail.com","threadId":"23789","inReplyTo":"cover.1273700831.git.eyvind.bernhardsen@gmail.com","subject":"[PATCH v3 3/5] Add per-repository eol normalization","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-12T23:00:53Z","receivedAt":"2010-05-12T23:00:53Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"Change the semantics of the \"crlf\" attribute so that it enables\nend-of-line normalization when it is set, regardless of \"core.autocrlf\".\n\nAdd new settings for \"crlf\": \"auto\", which enables end-of-line\nconversion but does not override the automatic text file detection, and\n\"crlf\" and \"lf\", which force normalization of the file and set which\nline ending it should have in the working directory.\n\nThe effect of this change is that a project can enable end-of-line\nnormalization for all files. This is similar to the \"core.autocrlf\"\nconfiguration variable, but since the setting is part of the content, it\nis cloned when the project is cloned and can be changed if a previously\nun-normalized repository is normalized.\n\nThe line ending style to be used for normalized text files in the\nworking directory is set using \"core.autocrlf\". When it is set to\n\"true\", CRLFs are used in the working directory; when set to \"input\" or\n\"false\", LFs are used.\n\nSigned-off-by: Eyvind Bernhardsen \n---\n Documentation/config.txt | 4 +-\n Documentation/gitattributes.txt | 142 +++++++++++++++++++++++++++++++--------\n cache.h | 9 ++-\n config.c | 2 +-\n convert.c | 71 ++++++++++++-------\n environment.c | 2 +-\n t/t0025-crlf-auto.sh | 10 ++--\n 7 files changed, 176 insertions(+), 64 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 92f851e..4d3c472 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -208,8 +208,8 @@ core.autocrlf::\n \tbased on the file's contents. See linkgit:gitattributes[5].\n \n core.safecrlf::\n-\tIf true, makes git check if converting `CRLF` as controlled by\n-\t`core.autocrlf` is reversible. Git will verify if a command\n+\tIf true, makes git check if converting `CRLF` is reversible when\n+\tend-of-line conversion is active. Git will verify if a command\n \tmodifies a file in the work tree either directly or indirectly.\n \tFor example, committing a file followed by checking out the\n \tsame file should yield the original file in the work tree. If\ndiff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt\nindex d892e64..bb3b446 100644\n--- a/Documentation/gitattributes.txt\n+++ b/Documentation/gitattributes.txt\n@@ -95,50 +95,136 @@ repository upon 'git add' and 'git commit'.\n `crlf`\n ^^^^^^\n \n-This attribute controls the line-ending convention.\n+This attribute enables and controls end-of-line normalization. When a\n+text file is normalized, its line endings are converted to LF in the\n+repository. Text files can have their line endings converted to\n+CRLF in the working directory, using the `crlf` attribute for\n+individual files or the `core.autocrlf` configuration variable for all\n+files.\n \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+\tSetting the `crlf` attribute on a path enables end-of-line\n+\tnormalization and marks the path as a text file. End-of-line\n+\tconversion takes place without guessing the content type.\n \n Unset::\n \n \tUnsetting the `crlf` attribute on a path tells git not to\n \tattempt any end-of-line conversion upon checkin or checkout.\n \n-Unspecified::\n+Set to string value \"auto\"::\n+\n+\tWhen `crlf` is set to \"auto\", the path is marked for automatic\n+\tend-of-line normalization. If git decides that the content is\n+\ttext, its line endings are normalized to LF on checkin.\n \n-\tUnspecified `crlf` attribute tells git to apply the\n-\t`core.autocrlf` conversion when the file content looks\n-\tlike text.\n+Set to string value \"crlf\"::\n \n-Set to string value \"input\"::\n+\tThis is similar to setting the attribute to `true`, but forces\n+\tgit to convert line endings to CRLF when the file is checked\n+\tout, regardless of `core.autocrlf`.\n+\n+Set to string value \"lf\"::\n \n \tThis is similar to setting the attribute to `true`, but\n-\talso forces git to act as if `core.autocrlf` is set to\n-\t`input` for the path.\n+\tprevents git from converting line endings to CRLF when the\n+\tfile is checked out, regardless of `core.autocrlf`. \"input\"\n+\tis an alias for \"lf\".\n \n-Any other value set to `crlf` attribute is ignored and git acts\n-as if the attribute is left unspecified.\n+Unspecified::\n \n+\tLeaving the `crlf` attribute unspecified tells git to apply\n+\tend-of-line normalization only if the `core.autocrlf`\n+\tconfiguration variable is set, the content appears to be text,\n+\tand the file is either new or already normalized in the\n+\trepository.\n \n-The `core.autocrlf` conversion\n-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n+Any other value causes git to act as if `crlf` has been left\n+unspecified.\n+\n+\n+End-of-line conversion\n+^^^^^^^^^^^^^^^^^^^^^^\n+\n+While git normally leaves file contents alone, it can be configured to\n+normalize line endings to LF in the repository and, optionally, to\n+convert them to CRLF when files are checked out.\n+\n+Here is an example that will make git normalize .txt, .vcproj and .sh\n+files, ensure that .vcproj files have CRLF and .sh files have LF in\n+the working directory, and prevent .jpg files from being normalized\n+regardless of their content.\n+\n+------------------------\n+*.txt\t\tcrlf\n+*.vcproj\tcrlf=crlf\n+*.sh\t\tcrlf=lf\n+*.jpg\t\t-crlf\n+------------------------\n+\n+Other source code management systems normalize all text files in their\n+repositories, and there are two ways to enable similar automatic\n+normalization in git.\n \n-If the configuration variable `core.autocrlf` is false, no\n-conversion is done.\n+If you simply want to have CRLF line endings in your working directory\n+regardless of the repository you are working in, you can set the\n+config variable \"core.autocrlf\" without changing any attributes.\n \n-When `core.autocrlf` is true, it means that the platform wants\n-CRLF line endings for files in the working tree, and you want to\n-convert them back to the normal LF line endings when checking\n-in to the repository.\n+------------------------\n+[core]\n+\tautocrlf = true\n+------------------------\n+\n+This does not force normalization of all text files, but does ensure\n+that text files that you introduce to the repository have their line\n+endings normalized to LF when they are added, and that files that are\n+already normalized in the repository stay normalized. You can also\n+set `autocrlf` to \"input\" to have automatic normalization of new text\n+files without conversion to CRLF in the working directory.\n+\n+If you want to interoperate with a source code management system that\n+enforces end-of-line normalization, or you simply want all text files\n+in your repository to be normalized, you should instead set the `crlf`\n+attribute to \"auto\" for _all_ files.\n+\n+------------------------\n+*\tcrlf=auto\n+------------------------\n \n-When `core.autocrlf` is set to \"input\", line endings are\n-converted to LF upon checkin, but there is no conversion done\n-upon checkout.\n+This ensures that all files that git considers to be text will have\n+normalized (LF) line endings in the repository.\n+\n+NOTE: When `crlf=auto` normalization is enabled in an existing\n+repository, any text files containing CRLFs should be normalized. If\n+they are not they will be normalized the next time someone tries to\n+change them, causing unfortunate misattribution. From a clean working\n+directory:\n+\n+-------------------------------------------------\n+$ echo \"* crlf=auto\" >>.gitattributes\n+ # ...this should be the first line in .gitattributes\n+$ rm .git/index # Remove the index to force git to\n+$ git reset # re-scan the working directory\n+$ git status # Show files that will be normalized\n+$ git add -u\n+$ git add .gitattributes\n+$ git commit -m \"Introduce end-of-line normalization\"\n+-------------------------------------------------\n+\n+If any files that should not be normalized show up in 'git status',\n+unset their `crlf` attribute before running 'git add -u'.\n+\n+------------------------\n+manual.pdf\t-crlf\n+------------------------\n+\n+Conversely, text files that git does not detect can have normalization\n+enabled manually.\n+\n+------------------------\n+weirdchars.txt\tcrlf\n+------------------------\n \n If `core.safecrlf` is set to \"true\" or \"warn\", git verifies if\n the conversion is reversible for the current setting of\ndiff --git a/cache.h b/cache.h\nindex 5eb0573..d1f669e 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -547,7 +547,6 @@ extern int core_compression_seen;\n extern size_t packed_git_window_size;\n extern size_t packed_git_limit;\n extern size_t delta_base_cache_limit;\n-extern int auto_crlf;\n extern int read_replace_refs;\n extern int fsync_object_files;\n extern int core_preload_index;\n@@ -561,6 +560,14 @@ enum safe_crlf {\n \n extern enum safe_crlf safe_crlf;\n \n+enum auto_crlf {\n+\tAUTO_CRLF_FALSE = 0,\n+\tAUTO_CRLF_TRUE = 1,\n+\tAUTO_CRLF_INPUT = -1,\n+};\n+\n+extern enum auto_crlf auto_crlf;\n+\n enum branch_track {\n \tBRANCH_TRACK_UNSPECIFIED = -1,\n \tBRANCH_TRACK_NEVER = 0,\ndiff --git a/config.c b/config.c\nindex 6963fbe..b60a1ff 100644\n--- a/config.c\n+++ b/config.c\n@@ -461,7 +461,7 @@ static int git_default_core_config(const char *var, const char *value)\n \n \tif (!strcmp(var, \"core.autocrlf\")) {\n \t\tif (value && !strcasecmp(value, \"input\")) {\n-\t\t\tauto_crlf = -1;\n+\t\t\tauto_crlf = AUTO_CRLF_INPUT;\n \t\t\treturn 0;\n \t\t}\n \t\tauto_crlf = git_config_bool(var, value);\ndiff --git a/convert.c b/convert.c\nindex 46622b0..0eb3d4b 100644\n--- a/convert.c\n+++ b/convert.c\n@@ -8,13 +8,17 @@\n * This should use the pathname to decide on whether it wants to do some\n * more interesting conversions (automatic gzip/unzip, general format\n * conversions etc etc), but by default it just does automatic CRLF<->LF\n- * translation when the \"auto_crlf\" option is set.\n+ * translation when the \"crlf\" attribute or \"auto_crlf\" option is set.\n */\n \n-#define CRLF_GUESS\t(-1)\n-#define CRLF_BINARY\t0\n-#define CRLF_TEXT\t1\n-#define CRLF_INPUT\t2\n+enum action {\n+\tCRLF_GUESS = -1,\n+\tCRLF_BINARY = 0,\n+\tCRLF_TEXT,\n+\tCRLF_INPUT,\n+\tCRLF_CRLF,\n+\tCRLF_AUTO,\n+};\n \n struct text_stat {\n \t/* NUL, CR, LF and CRLF counts */\n@@ -89,13 +93,14 @@ static int is_binary(unsigned long size, struct text_stat *stats)\n \treturn 0;\n }\n \n-static void check_safe_crlf(const char *path, int action,\n+static void check_safe_crlf(const char *path, enum action action,\n struct text_stat *stats, enum safe_crlf checksafe)\n {\n \tif (!checksafe)\n \t\treturn;\n \n-\tif (action == CRLF_INPUT || auto_crlf <= 0) {\n+\tif (action == CRLF_INPUT ||\n+\t (action == CRLF_GUESS && auto_crlf == AUTO_CRLF_INPUT)) {\n \t\t/*\n \t\t * CRLFs would not be restored by checkout:\n \t\t * check if we'd remove CRLFs\n@@ -106,7 +111,8 @@ static void check_safe_crlf(const char *path, int action,\n \t\t\telse /* i.e. SAFE_CRLF_FAIL */\n \t\t\t\tdie(\"CRLF would be replaced by LF in %s.\", path);\n \t\t}\n-\t} else if (auto_crlf > 0) {\n+\t} else if (action == CRLF_CRLF ||\n+\t\t (action == CRLF_GUESS && auto_crlf == AUTO_CRLF_TRUE)) {\n \t\t/*\n \t\t * CRLFs would be added by checkout:\n \t\t * check if we have \"naked\" LFs\n@@ -157,18 +163,23 @@ static int has_cr_in_index(const char *path)\n \treturn has_cr;\n }\n \n+static int should_guess_text(enum action action) {\n+\treturn (action == CRLF_GUESS || action == CRLF_AUTO);\n+}\n+\n static int crlf_to_git(const char *path, const char *src, size_t len,\n- struct strbuf *buf, int action, enum safe_crlf checksafe)\n+\t\t struct strbuf *buf, enum action action, enum safe_crlf checksafe)\n {\n \tstruct text_stat stats;\n \tchar *dst;\n \n-\tif ((action == CRLF_BINARY) || !auto_crlf || !len)\n+\tif (action == CRLF_BINARY ||\n+\t (action == CRLF_GUESS && auto_crlf == AUTO_CRLF_FALSE) || !len)\n \t\treturn 0;\n \n \tgather_stats(src, len, &stats);\n \n-\tif (action == CRLF_GUESS) {\n+\tif (should_guess_text(action)) {\n \t\t/*\n \t\t * We're currently not going to even try to convert stuff\n \t\t * that has bare CR characters. Does anybody do that crazy\n@@ -183,12 +194,14 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n \t\tif (is_binary(len, &stats))\n \t\t\treturn 0;\n \n-\t\t/*\n-\t\t * If the file in the index has any CR in it, do not convert.\n-\t\t * This is the new safer autocrlf handling.\n-\t\t */\n-\t\tif (has_cr_in_index(path))\n-\t\t\treturn 0;\n+\t\tif (action == CRLF_GUESS) {\n+\t\t\t/*\n+\t\t\t * If the file in the index has any CR in it, do not convert.\n+\t\t\t * This is the new safer autocrlf handling.\n+\t\t\t */\n+\t\t\tif (has_cr_in_index(path))\n+\t\t\t\treturn 0;\n+\t\t}\n \t}\n \n \tcheck_safe_crlf(path, action, &stats, checksafe);\n@@ -201,7 +214,7 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n \tif (strbuf_avail(buf) + buf->len < len)\n \t\tstrbuf_grow(buf, len - buf->len);\n \tdst = buf->buf;\n-\tif (action == CRLF_GUESS) {\n+\tif (should_guess_text(action)) {\n \t\t/*\n \t\t * If we guessed, we already know we rejected a file with\n \t\t * lone CR, and we can strip a CR without looking at what\n@@ -224,13 +237,13 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n }\n \n static int crlf_to_worktree(const char *path, const char *src, size_t len,\n- struct strbuf *buf, int action)\n+\t\t\t struct strbuf *buf, enum action action)\n {\n \tchar *to_free = NULL;\n \tstruct text_stat stats;\n \n \tif ((action == CRLF_BINARY) || (action == CRLF_INPUT) ||\n-\t auto_crlf <= 0)\n+\t (action != CRLF_CRLF && auto_crlf != AUTO_CRLF_TRUE))\n \t\treturn 0;\n \n \tif (!len)\n@@ -246,11 +259,13 @@ static int crlf_to_worktree(const char *path, const char *src, size_t len,\n \tif (stats.lf == stats.crlf)\n \t\treturn 0;\n \n-\tif (action == CRLF_GUESS) {\n-\t\t/* If we have any CR or CRLF line endings, we do not touch it */\n-\t\t/* This is the new safer autocrlf-handling */\n-\t\tif (stats.cr > 0 || stats.crlf > 0)\n-\t\t\treturn 0;\n+\tif (should_guess_text(action)) {\n+\t\tif (action == CRLF_GUESS) {\n+\t\t\t/* If we have any CR or CRLF line endings, we do not touch it */\n+\t\t\t/* This is the new safer autocrlf-handling */\n+\t\t\tif (stats.cr > 0 || stats.crlf > 0)\n+\t\t\t\treturn 0;\n+\t\t}\n \n \t\t/* If we have any bare CR characters, we're not going to touch it */\n \t\tif (stats.cr != stats.crlf)\n@@ -591,8 +606,12 @@ static int git_path_check_crlf(const char *path, struct git_attr_check *check)\n \t\treturn CRLF_BINARY;\n \telse if (ATTR_UNSET(value))\n \t\t;\n-\telse if (!strcmp(value, \"input\"))\n+\telse if (!strcmp(value, \"input\") || !strcmp(value, \"lf\"))\n \t\treturn CRLF_INPUT;\n+\telse if (!strcmp(value, \"crlf\"))\n+\t\treturn CRLF_CRLF;\n+\telse if (!strcmp(value, \"auto\"))\n+\t\treturn CRLF_AUTO;\n \treturn CRLF_GUESS;\n }\n \ndiff --git a/environment.c b/environment.c\nindex 876c5e5..db4a5e9 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -38,7 +38,7 @@ const char *pager_program;\n int pager_use_color = 1;\n const char *editor_program;\n const char *excludes_file;\n-int auto_crlf = 0;\t/* 1: both ways, -1: only when adding git objects */\n+enum auto_crlf auto_crlf = AUTO_CRLF_FALSE;\n int read_replace_refs = 1;\n enum safe_crlf safe_crlf = SAFE_CRLF_WARN;\n unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;\ndiff --git a/t/t0025-crlf-auto.sh b/t/t0025-crlf-auto.sh\nindex 40048a7..f11fee4 100755\n--- a/t/t0025-crlf-auto.sh\n+++ b/t/t0025-crlf-auto.sh\n@@ -41,7 +41,7 @@ test_expect_success 'default settings cause no changes' '\n \ttest -z \"$onediff\" -a -z \"$twodiff\"\n '\n \n-test_expect_failure 'crlf=true causes a CRLF file to be normalized' '\n+test_expect_success 'crlf=true causes a CRLF file to be normalized' '\n \n \trm -f .gitattributes tmp one two &&\n \techo \"two crlf\" > .gitattributes &&\n@@ -53,7 +53,7 @@ test_expect_failure 'crlf=true causes a CRLF file to be normalized' '\n \ttest -n \"$twodiff\"\n '\n \n-test_expect_failure 'crlf=crlf gives a normalized file CRLFs with autocrlf=false' '\n+test_expect_success 'crlf=crlf gives a normalized file CRLFs with autocrlf=false' '\n \n \trm -f .gitattributes tmp one two &&\n \tgit config core.autocrlf false &&\n@@ -65,7 +65,7 @@ test_expect_failure 'crlf=crlf gives a normalized file CRLFs with autocrlf=false\n \ttest -z \"$onediff\"\n '\n \n-test_expect_failure 'crlf=crlf gives a normalized file CRLFs with autocrlf=input' '\n+test_expect_success 'crlf=crlf gives a normalized file CRLFs with autocrlf=input' '\n \n \trm -f .gitattributes tmp one two &&\n \tgit config core.autocrlf input &&\n@@ -77,7 +77,7 @@ test_expect_failure 'crlf=crlf gives a normalized file CRLFs with autocrlf=input\n \ttest -z \"$onediff\"\n '\n \n-test_expect_failure 'crlf=lf gives a normalized file LFs with autocrlf=true' '\n+test_expect_success 'crlf=lf gives a normalized file LFs with autocrlf=true' '\n \n \trm -f .gitattributes tmp one two &&\n \tgit config core.autocrlf true &&\n@@ -102,7 +102,7 @@ test_expect_success 'autocrlf=true does not normalize CRLF files' '\n \ttest -z \"$onediff\" -a -z \"$twodiff\"\n '\n \n-test_expect_failure 'crlf=auto, autocrlf=true _does_ normalize CRLF files' '\n+test_expect_success 'crlf=auto, autocrlf=true _does_ normalize CRLF files' '\n \n \trm -f .gitattributes tmp one two &&\n \tgit config core.autocrlf true &&\n-- \n1.7.1.3.g448cb.dirty\n"},{"id":"141547","messageId":"6dd7bef7811283b03b8b9dac93c9a264d007bcb0.1273700831.git.eyvind.bernhardsen@gmail.com","threadId":"23789","inReplyTo":"cover.1273700831.git.eyvind.bernhardsen@gmail.com","subject":"[RFC/PATCH v3 4/5] Rename \"crlf\" attribute as \"eolconv\"","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-12T23:00:54Z","receivedAt":"2010-05-12T23:00:54Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"As discussed at length on the list, \"crlf\" is a pretty bad name for an\nattribute that enables end-of-line conversion, and the addition of \"lf\"\nand \"crlf\" values for it doesn't help.\n\nRename the attribute \"eolconv\", but fall back to \"crlf\" for backwards\ncompatibility if \"eolconv\" is not set.\n\nSigned-off-by: Eyvind Bernhardsen \n---\n Documentation/gitattributes.txt | 51 ++++++++++++++++++++------------------\n attr.c | 2 +-\n convert.c | 15 ++++++++---\n git-cvsserver.perl | 8 ++++-\n t/t0025-crlf-auto.sh | 31 ++++++++++++++++-------\n 5 files changed, 67 insertions(+), 40 deletions(-)\n\ndiff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt\nindex bb3b446..2887f85 100644\n--- a/Documentation/gitattributes.txt\n+++ b/Documentation/gitattributes.txt\n@@ -92,30 +92,33 @@ such as 'git checkout' and 'git merge' run. They also affect how\n git stores the contents you prepare in the working tree in the\n repository upon 'git add' and 'git commit'.\n \n-`crlf`\n-^^^^^^\n+`eolconv`\n+^^^^^^^^^\n \n This attribute enables and controls end-of-line normalization. When a\n text file is normalized, its line endings are converted to LF in the\n repository. Text files can have their line endings converted to\n-CRLF in the working directory, using the `crlf` attribute for\n+CRLF in the working directory, using the `eolconv` attribute for\n individual files or the `core.autocrlf` configuration variable for all\n files.\n \n+For compatibility with older versions of git, `crlf` is an alias for\n+this attribute.\n+\n Set::\n \n-\tSetting the `crlf` attribute on a path enables end-of-line\n+\tSetting the `eolconv` attribute on a path enables end-of-line\n \tnormalization and marks the path as a text file. End-of-line\n \tconversion takes place without guessing the content type.\n \n Unset::\n \n-\tUnsetting the `crlf` attribute on a path tells git not to\n+\tUnsetting the `eolconv` attribute on a path tells git not to\n \tattempt any end-of-line conversion upon checkin or checkout.\n \n Set to string value \"auto\"::\n \n-\tWhen `crlf` is set to \"auto\", the path is marked for automatic\n+\tWhen `eolconv` is set to \"auto\", the path is marked for automatic\n \tend-of-line normalization. If git decides that the content is\n \ttext, its line endings are normalized to LF on checkin.\n \n@@ -134,13 +137,13 @@ Set to string value \"lf\"::\n \n Unspecified::\n \n-\tLeaving the `crlf` attribute unspecified tells git to apply\n+\tLeaving the `eolconv` attribute unspecified tells git to apply\n \tend-of-line normalization only if the `core.autocrlf`\n \tconfiguration variable is set, the content appears to be text,\n \tand the file is either new or already normalized in the\n \trepository.\n \n-Any other value causes git to act as if `crlf` has been left\n+Any other value causes git to act as if `eolconv` has been left\n unspecified.\n \n \n@@ -157,10 +160,10 @@ the working directory, and prevent .jpg files from being normalized\n regardless of their content.\n \n ------------------------\n-*.txt\t\tcrlf\n-*.vcproj\tcrlf=crlf\n-*.sh\t\tcrlf=lf\n-*.jpg\t\t-crlf\n+*.txt\t\teolconv\n+*.vcproj\teolconv=crlf\n+*.sh\t\teolconv=lf\n+*.jpg\t\t-eolconv\n ------------------------\n \n Other source code management systems normalize all text files in their\n@@ -185,24 +188,24 @@ files without conversion to CRLF in the working directory.\n \n If you want to interoperate with a source code management system that\n enforces end-of-line normalization, or you simply want all text files\n-in your repository to be normalized, you should instead set the `crlf`\n+in your repository to be normalized, you should instead set the `eolconv`\n attribute to \"auto\" for _all_ files.\n \n ------------------------\n-*\tcrlf=auto\n+*\teolconv=auto\n ------------------------\n \n This ensures that all files that git considers to be text will have\n normalized (LF) line endings in the repository.\n \n-NOTE: When `crlf=auto` normalization is enabled in an existing\n+NOTE: When `eolconv=auto` normalization is enabled in an existing\n repository, any text files containing CRLFs should be normalized. If\n they are not they will be normalized the next time someone tries to\n change them, causing unfortunate misattribution. From a clean working\n directory:\n \n -------------------------------------------------\n-$ echo \"* crlf=auto\" >>.gitattributes\n+$ echo \"* eolconv=auto\" >>.gitattributes\n # ...this should be the first line in .gitattributes\n $ rm .git/index # Remove the index to force git to\n $ git reset # re-scan the working directory\n@@ -213,17 +216,17 @@ $ git commit -m \"Introduce end-of-line normalization\"\n -------------------------------------------------\n \n If any files that should not be normalized show up in 'git status',\n-unset their `crlf` attribute before running 'git add -u'.\n+unset their `eolconv` attribute before running 'git add -u'.\n \n ------------------------\n-manual.pdf\t-crlf\n+manual.pdf\t-eolconv\n ------------------------\n \n Conversely, text files that git does not detect can have normalization\n enabled manually.\n \n ------------------------\n-weirdchars.txt\tcrlf\n+weirdchars.txt\teolconv\n ------------------------\n \n If `core.safecrlf` is set to \"true\" or \"warn\", git verifies if\n@@ -309,11 +312,11 @@ Interaction between checkin/checkout attributes\n In the check-in codepath, the worktree file is first converted\n with `filter` driver (if specified and corresponding driver\n defined), then the result is processed with `ident` (if\n-specified), and then finally with `crlf` (again, if specified\n+specified), and then finally with `eolconv` (again, if specified\n and applicable).\n \n In the check-out codepath, the blob content is first converted\n-with `crlf`, and then `ident` and fed to `filter`.\n+with `eolconv`, and then `ident` and fed to `filter`.\n \n \n Generating diff text\n@@ -717,7 +720,7 @@ You do not want any end-of-line conversions applied to, nor textual diffs\n produced for, any binary file you track. You would need to specify e.g.\n \n ------------\n-*.jpg -crlf -diff\n+*.jpg -eolconv -diff\n ------------\n \n but that may become cumbersome, when you have many attributes. Using\n@@ -730,7 +733,7 @@ the same time. The system knows a built-in attribute macro, `binary`:\n \n which is equivalent to the above. Note that the attribute macros can only\n be \"Set\" (see the above example that sets \"binary\" macro as if it were an\n-ordinary attribute --- setting it in turn unsets \"crlf\" and \"diff\").\n+ordinary attribute --- setting it in turn unsets \"eolconv\" and \"diff\").\n \n \n DEFINING ATTRIBUTE MACROS\n@@ -741,7 +744,7 @@ at the toplevel (i.e. not in any subdirectory). The built-in attribute\n macro \"binary\" is equivalent to:\n \n ------------\n-[attr]binary -diff -crlf\n+[attr]binary -diff -eolconv\n ------------\n \n \ndiff --git a/attr.c b/attr.c\nindex f5346ed..7f924bc 100644\n--- a/attr.c\n+++ b/attr.c\n@@ -287,7 +287,7 @@ static void free_attr_elem(struct attr_stack *e)\n }\n \n static const char *builtin_attr[] = {\n-\t\"[attr]binary -diff -crlf\",\n+\t\"[attr]binary -diff -eolconv\",\n \tNULL,\n };\n \ndiff --git a/convert.c b/convert.c\nindex 0eb3d4b..b46f85d 100644\n--- a/convert.c\n+++ b/convert.c\n@@ -438,11 +438,13 @@ static int read_convert_config(const char *var, const char *value, void *cb)\n \n static void setup_convert_check(struct git_attr_check *check)\n {\n+\tstatic struct git_attr *attr_eolconv;\n \tstatic struct git_attr *attr_crlf;\n \tstatic struct git_attr *attr_ident;\n \tstatic struct git_attr *attr_filter;\n \n \tif (!attr_crlf) {\n+\t\tattr_eolconv = git_attr(\"eolconv\");\n \t\tattr_crlf = git_attr(\"crlf\");\n \t\tattr_ident = git_attr(\"ident\");\n \t\tattr_filter = git_attr(\"filter\");\n@@ -452,6 +454,7 @@ static void setup_convert_check(struct git_attr_check *check)\n \tcheck[0].attr = attr_crlf;\n \tcheck[1].attr = attr_ident;\n \tcheck[2].attr = attr_filter;\n+\tcheck[3].attr = attr_eolconv;\n }\n \n static int count_ident(const char *cp, unsigned long size)\n@@ -639,7 +642,7 @@ static int git_path_check_ident(const char *path, struct git_attr_check *check)\n int convert_to_git(const char *path, const char *src, size_t len,\n struct strbuf *dst, enum safe_crlf checksafe)\n {\n-\tstruct git_attr_check check[3];\n+\tstruct git_attr_check check[4];\n \tint crlf = CRLF_GUESS;\n \tint ident = 0, ret = 0;\n \tconst char *filter = NULL;\n@@ -647,7 +650,9 @@ int convert_to_git(const char *path, const char *src, size_t len,\n \tsetup_convert_check(check);\n \tif (!git_checkattr(path, ARRAY_SIZE(check), check)) {\n \t\tstruct convert_driver *drv;\n-\t\tcrlf = git_path_check_crlf(path, check + 0);\n+\t\tcrlf = git_path_check_crlf(path, check + 3);\n+\t\tif (crlf == CRLF_GUESS)\n+\t\t\tcrlf = git_path_check_crlf(path, check + 0);\n \t\tident = git_path_check_ident(path, check + 1);\n \t\tdrv = git_path_check_convert(path, check + 2);\n \t\tif (drv && drv->clean)\n@@ -669,7 +674,7 @@ int convert_to_git(const char *path, const char *src, size_t len,\n \n int convert_to_working_tree(const char *path, const char *src, size_t len, struct strbuf *dst)\n {\n-\tstruct git_attr_check check[3];\n+\tstruct git_attr_check check[4];\n \tint crlf = CRLF_GUESS;\n \tint ident = 0, ret = 0;\n \tconst char *filter = NULL;\n@@ -677,7 +682,9 @@ int convert_to_working_tree(const char *path, const char *src, size_t len, struc\n \tsetup_convert_check(check);\n \tif (!git_checkattr(path, ARRAY_SIZE(check), check)) {\n \t\tstruct convert_driver *drv;\n-\t\tcrlf = git_path_check_crlf(path, check + 0);\n+\t\tcrlf = git_path_check_crlf(path, check + 3);\n+\t\tif (crlf == CRLF_GUESS)\n+\t\t\tcrlf = git_path_check_crlf(path, check + 0);\n \t\tident = git_path_check_ident(path, check + 1);\n \t\tdrv = git_path_check_convert(path, check + 2);\n \t\tif (drv && drv->smudge)\ndiff --git a/git-cvsserver.perl b/git-cvsserver.perl\nindex 13751db..ede47a6 100755\n--- a/git-cvsserver.perl\n+++ b/git-cvsserver.perl\n@@ -2369,8 +2369,12 @@ sub kopts_from_path\n if ( defined ( $cfg->{gitcvs}{usecrlfattr} ) and\n $cfg->{gitcvs}{usecrlfattr} =~ /\\s*(1|true|yes)\\s*$/i )\n {\n- my ($val) = check_attr( \"crlf\", $path );\n- if ( $val eq \"set\" )\n+ my ($val) = check_attr( \"eolconv\", $path );\n+ if ( $val eq \"unspecified\" )\n+ {\n+ $val = check_attr( \"crlf\", $path );\n+ }\n+ if ( $val =~ /^(set|crlf|lf)$/ )\n {\n return \"\";\n }\ndiff --git a/t/t0025-crlf-auto.sh b/t/t0025-crlf-auto.sh\nindex f11fee4..05e5725 100755\n--- a/t/t0025-crlf-auto.sh\n+++ b/t/t0025-crlf-auto.sh\n@@ -41,9 +41,22 @@ test_expect_success 'default settings cause no changes' '\n \ttest -z \"$onediff\" -a -z \"$twodiff\"\n '\n \n-test_expect_success 'crlf=true causes a CRLF file to be normalized' '\n+test_expect_success 'eolconv=true causes a CRLF file to be normalized' '\n \n \trm -f .gitattributes tmp one two &&\n+\techo \"two eolconv\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\t# Note, \"normalized\" means that git will normalize it if added\n+\thas_cr two &&\n+\ttwodiff=`git diff two` &&\n+\ttest -n \"$twodiff\"\n+'\n+\n+test_expect_success 'crlf=true also causes a CRLF file to be normalized' '\n+\n+\t# Backwards compatilibity check\n+\trm -f .gitattributes tmp one two &&\n \techo \"two crlf\" > .gitattributes &&\n \tgit read-tree --reset -u HEAD &&\n \n@@ -53,11 +66,11 @@ test_expect_success 'crlf=true causes a CRLF file to be normalized' '\n \ttest -n \"$twodiff\"\n '\n \n-test_expect_success 'crlf=crlf gives a normalized file CRLFs with autocrlf=false' '\n+test_expect_success 'eolconv=crlf gives a normalized file CRLFs with autocrlf=false' '\n \n \trm -f .gitattributes tmp one two &&\n \tgit config core.autocrlf false &&\n-\techo \"one crlf=crlf\" > .gitattributes &&\n+\techo \"one eolconv=crlf\" > .gitattributes &&\n \tgit read-tree --reset -u HEAD &&\n \n \thas_cr one &&\n@@ -65,11 +78,11 @@ test_expect_success 'crlf=crlf gives a normalized file CRLFs with autocrlf=false\n \ttest -z \"$onediff\"\n '\n \n-test_expect_success 'crlf=crlf gives a normalized file CRLFs with autocrlf=input' '\n+test_expect_success 'eolconv=crlf gives a normalized file CRLFs with autocrlf=input' '\n \n \trm -f .gitattributes tmp one two &&\n \tgit config core.autocrlf input &&\n-\techo \"one crlf=crlf\" > .gitattributes &&\n+\techo \"one eolconv=crlf\" > .gitattributes &&\n \tgit read-tree --reset -u HEAD &&\n \n \thas_cr one &&\n@@ -77,11 +90,11 @@ test_expect_success 'crlf=crlf gives a normalized file CRLFs with autocrlf=input\n \ttest -z \"$onediff\"\n '\n \n-test_expect_success 'crlf=lf gives a normalized file LFs with autocrlf=true' '\n+test_expect_success 'eolconv=lf gives a normalized file LFs with autocrlf=true' '\n \n \trm -f .gitattributes tmp one two &&\n \tgit config core.autocrlf true &&\n-\techo \"one crlf=lf\" > .gitattributes &&\n+\techo \"one eolconv=lf\" > .gitattributes &&\n \tgit read-tree --reset -u HEAD &&\n \n \t! has_cr one &&\n@@ -102,11 +115,11 @@ test_expect_success 'autocrlf=true does not normalize CRLF files' '\n \ttest -z \"$onediff\" -a -z \"$twodiff\"\n '\n \n-test_expect_success 'crlf=auto, autocrlf=true _does_ normalize CRLF files' '\n+test_expect_success 'eolconv=auto, autocrlf=true _does_ normalize CRLF files' '\n \n \trm -f .gitattributes tmp one two &&\n \tgit config core.autocrlf true &&\n-\techo \"* crlf=auto\" > .gitattributes &&\n+\techo \"* eolconv=auto\" > .gitattributes &&\n \tgit read-tree --reset -u HEAD &&\n \n \thas_cr one &&\n-- \n1.7.1.3.g448cb.dirty\n"},{"id":"141549","messageId":"d739aefee3d015b739b41e1db549c19472c3dd5a.1273700831.git.eyvind.bernhardsen@gmail.com","threadId":"23789","inReplyTo":"cover.1273700831.git.eyvind.bernhardsen@gmail.com","subject":"[RFC/PATCH v3 5/5] Rename \"core.autocrlf\" config variable as \"core.eolconv\"","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-12T23:00:55Z","receivedAt":"2010-05-12T23:00:55Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"As asserted by myself and not vigourously contested on the list,\n\"autocrlf\" is a pretty bad name. Rename the variable \"core.eolconv\",\nbut also accept \"core.autocrlf\" for backwards compatibility.\n\nAlso add aliases \"crlf\" for \"true\" and \"lf\" for \"input\".\n\nSigned-off-by: Eyvind Bernhardsen \n---\n Documentation/config.txt | 22 ++++++++-------\n Documentation/gitattributes.txt | 16 ++++++------\n config.c | 11 ++++++--\n t/t0020-crlf.sh | 54 +++++++++++++++++++++++++++++++++++++++\n 4 files changed, 82 insertions(+), 21 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 4d3c472..6814e23 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -196,16 +196,18 @@ core.quotepath::\n \tquoted without `-z` regardless of the setting of this\n \tvariable.\n \n-core.autocrlf::\n-\tIf true, makes git convert `CRLF` at the end of lines in text files to\n+core.eolconv::\n+\tIf true or 'crlf', makes git convert `CRLF` at the end of lines in text files to\n \t`LF` when reading from the work tree, and convert in reverse when\n \twriting to the work tree. The variable can be set to\n-\t'input', in which case the conversion happens only while\n+\t'input' or 'lf', in which case the conversion happens only while\n \treading from the work tree but files are written out to the work\n \ttree with `LF` at the end of lines. A file is considered\n-\t\"text\" (i.e. be subjected to the autocrlf mechanism) based on\n+\t\"text\" (i.e. subject to the eolconv mechanism) based on\n \tthe file's `crlf` attribute, or if `crlf` is unspecified,\n \tbased on the file's contents. See linkgit:gitattributes[5].\n+\tFor backwards compatibility, `core.autocrlf` is an alias of\n+\tthis variable.\n \n core.safecrlf::\n \tIf true, makes git check if converting `CRLF` is reversible when\n@@ -214,12 +216,12 @@ core.safecrlf::\n \tFor example, committing a file followed by checking out the\n \tsame file should yield the original file in the work tree. If\n \tthis is not the case for the current setting of\n-\t`core.autocrlf`, git will reject the file. The variable can\n+\t`core.eolconv`, git will reject the file. The variable can\n \tbe set to \"warn\", in which case git will only warn about an\n \tirreversible conversion but continue the operation.\n +\n CRLF conversion bears a slight chance of corrupting data.\n-autocrlf=true will convert CRLF to LF during commit and LF to\n+eolconv=true will convert CRLF to LF during commit and LF to\n CRLF during checkout. A file that contains a mixture of LF and\n CRLF before the commit cannot be recreated by git. For text\n files this is the right thing to do: it corrects line endings\n@@ -243,9 +245,9 @@ converting CRLFs corrupts data.\n +\n Note, this safety check does not mean that a checkout will generate a\n file identical to the original file for a different setting of\n-`core.autocrlf`, but only for the current one. For example, a text\n-file with `LF` would be accepted with `core.autocrlf=input` and could\n-later be checked out with `core.autocrlf=true`, in which case the\n+`core.eolconv`, but only for the current one. For example, a text\n+file with `LF` would be accepted with `core.eolconv=input` and could\n+later be checked out with `core.eolconv=true`, in which case the\n resulting file would contain `CRLF`, although the original file\n contained `LF`. However, in both work trees the line endings would be\n consistent, that is either all `LF` or all `CRLF`, but never mixed. A\n@@ -991,7 +993,7 @@ gitcvs.allbinary::\n \tas binary files, which suppresses any newline munging it\n \totherwise might do. Alternatively, if it is set to \"guess\",\n \tthen the contents of the file are examined to decide if\n-\tit is binary, similar to 'core.autocrlf'.\n+\tit is binary, similar to 'core.eolconv'.\n \n gitcvs.dbname::\n \tDatabase used by git-cvsserver to cache revision information\ndiff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt\nindex 2887f85..7d02146 100644\n--- a/Documentation/gitattributes.txt\n+++ b/Documentation/gitattributes.txt\n@@ -99,7 +99,7 @@ This attribute enables and controls end-of-line normalization. When a\n text file is normalized, its line endings are converted to LF in the\n repository. Text files can have their line endings converted to\n CRLF in the working directory, using the `eolconv` attribute for\n-individual files or the `core.autocrlf` configuration variable for all\n+individual files or the `core.eolconv` configuration variable for all\n files.\n \n For compatibility with older versions of git, `crlf` is an alias for\n@@ -126,19 +126,19 @@ Set to string value \"crlf\"::\n \n \tThis is similar to setting the attribute to `true`, but forces\n \tgit to convert line endings to CRLF when the file is checked\n-\tout, regardless of `core.autocrlf`.\n+\tout, regardless of `core.eolconv`.\n \n Set to string value \"lf\"::\n \n \tThis is similar to setting the attribute to `true`, but\n \tprevents git from converting line endings to CRLF when the\n-\tfile is checked out, regardless of `core.autocrlf`. \"input\"\n+\tfile is checked out, regardless of `core.eolconv`. \"input\"\n \tis an alias for \"lf\".\n \n Unspecified::\n \n \tLeaving the `eolconv` attribute unspecified tells git to apply\n-\tend-of-line normalization only if the `core.autocrlf`\n+\tend-of-line normalization only if the `core.eolconv`\n \tconfiguration variable is set, the content appears to be text,\n \tand the file is either new or already normalized in the\n \trepository.\n@@ -172,18 +172,18 @@ normalization in git.\n \n If you simply want to have CRLF line endings in your working directory\n regardless of the repository you are working in, you can set the\n-config variable \"core.autocrlf\" without changing any attributes.\n+config variable \"core.eolconv\" without changing any attributes.\n \n ------------------------\n [core]\n-\tautocrlf = true\n+\teolconv = true\n ------------------------\n \n This does not force normalization of all text files, but does ensure\n that text files that you introduce to the repository have their line\n endings normalized to LF when they are added, and that files that are\n already normalized in the repository stay normalized. You can also\n-set `autocrlf` to \"input\" to have automatic normalization of new text\n+set `eolconv` to \"input\" to have automatic normalization of new text\n files without conversion to CRLF in the working directory.\n \n If you want to interoperate with a source code management system that\n@@ -231,7 +231,7 @@ weirdchars.txt\teolconv\n \n If `core.safecrlf` is set to \"true\" or \"warn\", git verifies if\n the conversion is reversible for the current setting of\n-`core.autocrlf`. For \"true\", git rejects irreversible\n+`core.eolconv`. For \"true\", git rejects irreversible\n conversions; for \"warn\", git only prints a warning but accepts\n an irreversible conversion. The safety triggers to prevent such\n a conversion done to the files in the work tree, but there are a\ndiff --git a/config.c b/config.c\nindex b60a1ff..a5f445e 100644\n--- a/config.c\n+++ b/config.c\n@@ -459,12 +459,17 @@ static int git_default_core_config(const char *var, const char *value)\n \t\treturn 0;\n \t}\n \n-\tif (!strcmp(var, \"core.autocrlf\")) {\n-\t\tif (value && !strcasecmp(value, \"input\")) {\n+\tif (!strcmp(var, \"core.eolconv\") || !strcmp(var, \"core.autocrlf\")) {\n+\t\tif (value && (!strcasecmp(value, \"input\") ||\n+\t\t\t !strcasecmp(value, \"lf\"))) {\n \t\t\tauto_crlf = AUTO_CRLF_INPUT;\n \t\t\treturn 0;\n \t\t}\n-\t\tauto_crlf = git_config_bool(var, value);\n+\t\tif (value && !strcasecmp(value, \"crlf\") ||\n+\t\t git_config_bool(var, value))\n+\t\t\tauto_crlf = AUTO_CRLF_TRUE;\n+\t\telse\n+\t\t\tauto_crlf = AUTO_CRLF_FALSE;\n \t\treturn 0;\n \t}\n \ndiff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh\nindex 234a94f..52c2b71 100755\n--- a/t/t0020-crlf.sh\n+++ b/t/t0020-crlf.sh\n@@ -135,9 +135,35 @@ test_expect_success 'update with autocrlf=true' '\n \n '\n \n+test_expect_success 'checkout with eolconv=crlf' '\n+\n+\trm -f tmp one dir/two three &&\n+\tgit config --unset-all core.autocrlf &&\n+\tgit config core.eolconv crlf &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\tfor f in one dir/two\n+\tdo\n+\t\tremove_cr <\"$f\" >tmp && mv -f tmp $f &&\n+\t\tgit update-index -- $f || {\n+\t\t\techo \"Eh? $f\"\n+\t\t\tfalse\n+\t\t\tbreak\n+\t\t}\n+\tdone &&\n+\ttest \"$one\" = `git hash-object --stdin \n> ------------------------\n> -*.txt crlf\n> -*.vcproj crlf=crlf\n> -*.sh crlf=lf\n> -*.jpg -crlf\n> +*.txt eolconv\n> +*.vcproj eolconv=crlf\n> +*.sh eolconv=lf\n> +*.jpg -eolconv\n> ------------------------\n...\n> ------------------------\n> -*\tcrlf=auto\n> +*\teolconv=auto\n> ------------------------\n\nIf you are doing the renaming, then I seriously object to this.\n\nIt makes no sense to say \"eolconv=crlf\" and then say \"eolconv=auto\". They \nare two totally different things. One is _how_ line endings should look \nlike, and the other is _whether_ line endings exist or not.\n\nAnd \"eolconv=crlf\" makes no sense anyway. I assume \"conv\" is\nconversion, but a conversion implies a from and a to. That's just a\n\"to\", and it would make much more sense to just say \"eol=crlf\" for that\ncase. \n\nNow, it _does_ make sense to say \"eolconv=auto\", but that's because it's\nthat totally different case: it's not about what the line ending\ncharacter is, it's about whether any eol conversion is done at all. So\nfor _that_ case, it makes sense to use \"eolconv\", although even for that\ncase I think the name is not very _good_. \nSo if you rename these things, keep them separate. Make the \"am I a\ntext-file\" boolean be a boolean (plus \"auto\"), and just call it \"text\". \nAnd make the \"what end of line to use\" be just \"eol\" then.\n\nSo you can have\n\n\t*\ttext=auto,eol=crlf\n\nthat means \"autodetect whether it is text, and use crlf as eol\".\n\nNow, I'd further suggest:\n\n - \"eol=xyz\" with no \"text\" attribute automatically implies \"text\" being \n true.\n - \"text=xyz\" with no \"eol\" attribute implies \"eol=native\"\n\nso now you can write:\n\n\t*.jpg -text\n\t*.txt text\n\t*.vcproj eol=crlf\n\t*.sh eol=lf\n\t* text=auto\n\nand that means:\n\n - jpg files are binary\n - *.txt files are text, and we use the default (\"native\") line ending for \n them (implicit, since we don't have any matcing eol rule)\n - *.vcproj files are text (implicit), and we use CRLF line endings\n - *.sh files are text (implicit), and we use UNIX style line endings\n - everything else is auto-detected, and we implicitly use native line \n endings for them\n\nDoesn't that look finally sane?\n\nBecause if we really renaem the attributes, let's rename them _right_.\n\n\t\t\tLinus\n"},{"id":"141569","messageId":"AANLkTilQjSKNYq8NEabcsZc5WWF86kWMWxnTy-mShVgS@mail.gmail.com","threadId":"23789","inReplyTo":"alpine.LFD.2.00.1005121824260.3711@i5.linux-foundation.org","subject":"Re: [RFC/PATCH v3 4/5] Rename \"crlf\" attribute as \"eolconv\"","fromName":"Robert Buck","fromEmail":"buck.robert.j@gmail.com","sentAt":"2010-05-13T09:39:03Z","receivedAt":"2010-05-13T09:39:03Z","isPatch":true,"sender":{"key":"buck.robert.j@gmail.com","avatar":"https://gravatar.com/avatar/1686742e8ac2595378aac67f26fd638ddaf494194f9af0cb6082c4a7eca1a366?d=mp&s=160"},"body":"[...]\n\n> Now, it _does_ make sense to say \"eolconv=auto\", but that's because it's\n> that totally different case: it's not about what the line ending\n> character is, it's about whether any eol conversion is done at all.  So\n> for _that_ case, it makes sense to use \"eolconv\", although even for that\n> case I think the name is not very _good_.\n> So if you rename these things, keep them separate.  Make the \"am I a\n> text-file\" boolean be a boolean (plus \"auto\"), and just call it \"text\".\n> And make the \"what end of line to use\" be just \"eol\" then.\n>\n> So you can have\n>\n>        *       text=auto,eol=crlf\n>\n> that means \"autodetect whether it is text, and use crlf as eol\".\n>\n> Now, I'd further suggest:\n>\n>  - \"eol=xyz\" with no \"text\" attribute automatically implies \"text\" being\n>   true.\n>  - \"text=xyz\" with no \"eol\" attribute implies \"eol=native\"\n>\n> so now you can write:\n>\n>        *.jpg -text\n>        *.txt text\n>        *.vcproj eol=crlf\n>        *.sh eol=lf\n>        * text=auto\n>\n> and that means:\n>\n>  - jpg files are binary\n>  - *.txt files are text, and we use the default (\"native\") line ending for\n>   them (implicit, since we don't have any matcing eol rule)\n>  - *.vcproj files are text (implicit), and we use CRLF line endings\n>  - *.sh files are text (implicit), and we use UNIX style line endings\n>  - everything else is auto-detected, and we implicitly use native line\n>   endings for them\n>\n> Doesn't that look finally sane?\n>\n> Because if we really rename the attributes, let's rename them _right_.\n>\n>                        Linus\n>\n\nLove it!\n"},{"id":"141570","messageId":"AANLkTimCraGNet9lCuJGmFNR5JcDRQBTz1yME6GQFo4B@mail.gmail.com","threadId":"23789","inReplyTo":"AANLkTilQjSKNYq8NEabcsZc5WWF86kWMWxnTy-mShVgS@mail.gmail.com","subject":"Re: [RFC/PATCH v3 4/5] Rename \"crlf\" attribute as \"eolconv\"","fromName":"Robert Buck","fromEmail":"buck.robert.j@gmail.com","sentAt":"2010-05-13T09:58:45Z","receivedAt":"2010-05-13T09:58:45Z","isPatch":true,"sender":{"key":"buck.robert.j@gmail.com","avatar":"https://gravatar.com/avatar/1686742e8ac2595378aac67f26fd638ddaf494194f9af0cb6082c4a7eca1a366?d=mp&s=160"},"body":"Quick question here, while people would be in the convert.c functions\nwhen making the above changes. This question is related to detecting\nwhether a file is text, but the question could be spun off to a\ndifferent thread if you so wish...\n\nHave you considered skipping the UTF8 BOM and provided that the\nremaining content is considered text allow auto conversions? The check\nis simple, and would cover at least 50% of latin-derived languages.\nSince you have the buffer at hand, and are in the same file\n(convert.c), simply check for an initial EF BB BF. This would fix some\ntext files created on Windows (someone had mentioned Notepad I\nbelieve). Out of the box experience for eol and text detection for\nWindows users would be improved.\n\nBob\n"},{"id":"141571","messageId":"961B7250-F65E-4C67-8C5C-6701F68C2FC0@gmail.com","threadId":"23789","inReplyTo":"alpine.LFD.2.00.1005121824260.3711@i5.linux-foundation.org","subject":"Re: [RFC/PATCH v3 4/5] Rename \"crlf\" attribute as \"eolconv\"","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-13T10:59:15Z","receivedAt":"2010-05-13T10:59:15Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 13. mai 2010, at 03.38, Linus Torvalds wrote:\n\n> so now you can write:\n> \n> \t*.jpg -text\n> \t*.txt text\n> \t*.vcproj eol=crlf\n> \t*.sh eol=lf\n> \t* text=auto\n\n[...]\n\n> Doesn't that look finally sane?\n> \n> Because if we really renaem the attributes, let's rename them _right_.\n\nBeautiful.\n\nDo you agree that \"native\" eol should only be CRLF if autocrlf is true? Otherwise, if .gitattributes looks like this:\n\n\t*.txt text\n\ngit will put CRLFs in .txt files but LFs in .c files, and I don't think that makes much sense.\n-- \nEyvind\n"},{"id":"141575","messageId":"014C9B00-800C-465D-A0B9-98BEEB7D7A96@gmail.com","threadId":"23789","inReplyTo":"AANLkTimCraGNet9lCuJGmFNR5JcDRQBTz1yME6GQFo4B@mail.gmail.com","subject":"Re: [RFC/PATCH v3 4/5] Rename \"crlf\" attribute as \"eolconv\"","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-13T11:47:45Z","receivedAt":"2010-05-13T11:47:45Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 13. mai 2010, at 11.58, Robert Buck wrote:\n\n> Quick question here, while people would be in the convert.c functions\n> when making the above changes. This question is related to detecting\n> whether a file is text, but the question could be spun off to a\n> different thread if you so wish...\n> \n> Have you considered skipping the UTF8 BOM and provided that the\n> remaining content is considered text allow auto conversions? The check\n> is simple, and would cover at least 50% of latin-derived languages.\n> Since you have the buffer at hand, and are in the same file\n> (convert.c), simply check for an initial EF BB BF. This would fix some\n> text files created on Windows (someone had mentioned Notepad I\n> believe). Out of the box experience for eol and text detection for\n> Windows users would be improved.\n\nI just did a quick test with a plain text file; it was detected as text both with and without a utf8 BOM. Looking at the code, characters >= 128 are considered printable so the BOM shouldn't make any difference at all. Do you have an example utf8 text file that is misdetected as binary?\n-- \nEyvind\n"},{"id":"141588","messageId":"AANLkTikat4Da_XXz8xYH9La_I3n31THIhGA_onGGm0VU@mail.gmail.com","threadId":"23789","inReplyTo":"014C9B00-800C-465D-A0B9-98BEEB7D7A96@gmail.com","subject":"Re: [RFC/PATCH v3 4/5] Rename \"crlf\" attribute as \"eolconv\"","fromName":"Robert Buck","fromEmail":"buck.robert.j@gmail.com","sentAt":"2010-05-13T13:19:15Z","receivedAt":"2010-05-13T13:19:15Z","isPatch":true,"sender":{"key":"buck.robert.j@gmail.com","avatar":"https://gravatar.com/avatar/1686742e8ac2595378aac67f26fd638ddaf494194f9af0cb6082c4a7eca1a366?d=mp&s=160"},"body":"On Thu, May 13, 2010 at 7:47 AM, Eyvind Bernhardsen\n wrote:\n> On 13. mai 2010, at 11.58, Robert Buck wrote:\n>\n>> Quick question here, while people would be in the convert.c functions\n>> when making the above changes. This question is related to detecting\n>> whether a file is text, but the question could be spun off to a\n>> different thread if you so wish...\n>>\n>> Have you considered skipping the UTF8 BOM and provided that the\n>> remaining content is considered text allow auto conversions? The check\n>> is simple, and would cover at least 50% of latin-derived languages.\n>> Since you have the buffer at hand, and are in the same file\n>> (convert.c), simply check for an initial EF BB BF. This would fix some\n>> text files created on Windows (someone had mentioned Notepad I\n>> believe). Out of the box experience for eol and text detection for\n>> Windows users would be improved.\n>\n> I just did a quick test with a plain text file; it was detected as text both with and without a utf8 BOM.  Looking at the code, characters >= 128 are considered printable so the BOM shouldn't make any difference at all.  Do you have an example utf8 text file that is misdetected as binary?\n\nSorry, my bad. I misread a line in convert.c. It handles UTF-8 beautifully.\n"},{"id":"141618","messageId":"alpine.LFD.2.00.1005131438330.3711@i5.linux-foundation.org","threadId":"23789","inReplyTo":"961B7250-F65E-4C67-8C5C-6701F68C2FC0@gmail.com","subject":"Re: [RFC/PATCH v3 4/5] Rename \"crlf\" attribute as \"eolconv\"","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-13T21:45:14Z","receivedAt":"2010-05-13T21:45:14Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 13 May 2010, Eyvind Bernhardsen wrote:\n> \n> Do you agree that \"native\" eol should only be CRLF if autocrlf is true? \n\nNot really. We're trying to get _away_ from .gitattributes depending on \nautocrlf, aren't we?\n\n> Otherwise, if .gitattributes looks like this:\n> \n> \t*.txt text\n> \n> git will put CRLFs in .txt files but LFs in .c files, and I don't think \n> that makes much sense.\n\nWell, but that's what you asked for, isn't it? And I don't see why you say \n*.c files would have LF's, since that depends on what you put in them: and \nunder Windows, that might well be CRLF.\n\nAnd I do think it's perfectly reasonable to override the \"native\" mode in \nyour .git/config. If we're renaming the attributes, we might as well then \nintroduce a \n\n\t[core]\n\t\teol=lf\n\nto set the \"native\" EOL for that repo, exactly because presumably a number \nof Windows people would like to see the saner LF-only model rather than \nthe traditional native CRLF.\n\nIn fact, maybe it would even make sense to just make LF the default \n\"native\" end-of-line sequence even on windows, so that Windows people who \nactually want CRLF would have to set core.eol=crlf. Whatever. That would \nbe for the Windows git users to fight out, I don't care.\n\nBut if we are going to clean up text attribute handling, then I really \nthink we want to totally break that old \"core.autocrlf\" dependency. \n\n\t\t\tLinus\n"},{"id":"141622","messageId":"AANLkTil1i_vFAvT1CotYdK47LnufVKc17-1168rOVcMX@mail.gmail.com","threadId":"23789","inReplyTo":"alpine.LFD.2.00.1005131438330.3711@i5.linux-foundation.org","subject":"Re: [RFC/PATCH v3 4/5] Rename \"crlf\" attribute as \"eolconv\"","fromName":"Robert Buck","fromEmail":"buck.robert.j@gmail.com","sentAt":"2010-05-14T02:34:27Z","receivedAt":"2010-05-14T02:34:27Z","isPatch":true,"sender":{"key":"buck.robert.j@gmail.com","avatar":"https://gravatar.com/avatar/1686742e8ac2595378aac67f26fd638ddaf494194f9af0cb6082c4a7eca1a366?d=mp&s=160"},"body":"Probably a newbie question, lots to read, lots already read, but I\nreally want to verify if I have this correct. So in a nutshell, in the\ngitattributes file\n\n* text\n*.foo binary\n\nmeans autoconvert everything regardless of the autocrlf setting,\nexcept for .foo files ? So now we can dispense with the autocrlf\nattribute altogether if we so wish?\n\n- Bob\n"},{"id":"141632","messageId":"20100514045646.GA2433@progeny.tock","threadId":"23789","inReplyTo":"AANLkTil1i_vFAvT1CotYdK47LnufVKc17-1168rOVcMX@mail.gmail.com","subject":"Re: [RFC/PATCH v3 4/5] Rename \"crlf\" attribute as \"eolconv\"","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-05-14T04:56:46Z","receivedAt":"2010-05-14T04:56:46Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Bob,\n\nRobert Buck wrote:\n\n> * text\n> *.foo binary\n> \n> means autoconvert everything regardless of the autocrlf setting,\n> except for .foo files ? So now we can dispense with the autocrlf\n> attribute altogether if we so wish?\n\nIf I understand correctly, there is no autocrlf attribute, just a\nconfiguration item. If you put\n\n * crlf\n *.foo -crlf\n\nin your .gitattributes with current git, this means:\n\n - if the '[core] autocrlf' configuration is not set, do not convert\n anything;\n\n - otherwise, convert everything except for .foo files\n\nEyvind’s series improves that in a few ways.\n\n - [from Finn Arne Gangstad] If the in-repository copy of a file\n contains any carriage returns, do not try to convert it. This\n makes it easier to deal with mistakes.\n\n - For files with crlf enabled through attributes, always convert,\n whether '[core] autocrlf' is enabled or not.\n\n - Use the '[core] autocrlf' setting to determine the desired\n line-ending for checked-out files (\\r\\n if true, \\n otherwise).\n A new eol attribute is provided to override that setting.\n\n - The crlf attribute gets a new synonym \"text\" to avoid confusion.\n\nThere is also some change to the result of file type autodetection,\nbut as long as your .gitattributes uses '* crlf' or '* -crlf', there\nis no need to worry about this.\n\nHope that helps,\nJonathan\n"},{"id":"141661","messageId":"20100514101648.GB6212@dpotapov.dyndns.org","threadId":"23789","inReplyTo":"014C9B00-800C-465D-A0B9-98BEEB7D7A96@gmail.com","subject":"utf8 BOM","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-05-14T10:16:48Z","receivedAt":"2010-05-14T10:16:48Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Thu, May 13, 2010 at 01:47:45PM +0200, Eyvind Bernhardsen wrote:\n> \n> I just did a quick test with a plain text file; it was detected as\n> text both with and without a utf8 BOM. Looking at the code,\n> characters >= 128 are considered printable so the BOM shouldn't make\n> any difference at all. Do you have an example utf8 text file that is\n> misdetected as binary?\n\nThough UTF-8 BOM does not present any problem for automatic text\ndetector, it is another piece from Microsoft that creates some\ninteroperability issues when you work with non-ASCII text files.\nIn short:\n\n1. Microsoft editors and tools like to add utf8 BOM to files, and\n you cannot turn this behavior off.\n2. Many tools (such as Microsoft compiler) incapable to recognize\n UTF-8 files without BOM, so they screw up all non-ASCII chars.\n\n#1 is a problem, because it creates changes consisting solely of adding\nutf8 BOM. Moreover, users of non-Windows platforms are not exactly\nthrilled with having utf8 BOM at the beginning of every text file.\n\nProbably, ability of automatic add utf8 BOM on Windows to text files\n(which are marked as \"unicode\") can be helpful, but it is just a part\nof the problem of how to deal with text files in \"legacy\" encoding,\nwhich are still widely used on Windows.\n\n\n\nDmitry\n"},{"id":"141698","messageId":"7DF58EB2-F6A0-47FB-BC89-72757B29FAE6@gmail.com","threadId":"23789","inReplyTo":"alpine.LFD.2.00.1005131438330.3711@i5.linux-foundation.org","subject":"Re: [RFC/PATCH v3 4/5] Rename \"crlf\" attribute as \"eolconv\"","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-14T21:16:29Z","receivedAt":"2010-05-14T21:16:29Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 13. mai 2010, at 23.45, Linus Torvalds wrote:\n\n> On Thu, 13 May 2010, Eyvind Bernhardsen wrote:\n>> \n>> Do you agree that \"native\" eol should only be CRLF if autocrlf is true? \n> \n> Not really. We're trying to get _away_ from .gitattributes depending on \n> autocrlf, aren't we?\n\nI'm not sure we still are. I certainly was when I started this series, but that was because autocrlf just plain didn't work with many existing repositories. When \"safe autocrlf\" fixed that, I decided that the extra complexity of core.eolStyle wasn't worth it.\n\nI could be wrong, and I'd be happy to add it later. I don't think this series requires it, though.\n\nI'd like to make my terms explicit: when I say \"core.autocrlf\", I mean a config value that makes git normalize all text files automagically. \"core.eol\" would be a different config value that simply tells git what line endings to put in files that are explicitly flagged as \"text\" (or automatically detected by \"text=auto\").\n\n>> Otherwise, if .gitattributes looks like this:\n>> \n>> \t*.txt text\n>> \n>> git will put CRLFs in .txt files but LFs in .c files, and I don't think \n>> that makes much sense.\n> \n> Well, but that's what you asked for, isn't it? And I don't see why you say \n> *.c files would have LF's, since that depends on what you put in them: and \n> under Windows, that might well be CRLF.\n\nThat's not an interesting problem. If you're okay with CRLFs in your repository there's no need for you to use text file normalization at all, and you're certainly not going to bother to set any text attributes. Everything will Just Work.\n\nTo make it more relevant, let's consider what would happen if you suddenly wanted to share that repository with a Linux user. You would clearly have been better off if the text files had been normalized, but I can only see three ways this could happen:\n\n1. You set \"* text=auto\" when you created the repository\n2. text=auto is the default for all files\n3. autocrlf=true is set by default on Windows\n\nThe first option is unrealistic, and we probably agree that the second one is a bad idea. That's why, once Finn Arne fixed autocrlf, I realized it's not all that bad.\n\n> And I do think it's perfectly reasonable to override the \"native\" mode in \n> your .git/config. If we're renaming the attributes, we might as well then \n> introduce a \n> \n> \t[core]\n> \t\teol=lf\n> \n> to set the \"native\" EOL for that repo, exactly because presumably a number \n> of Windows people would like to see the saner LF-only model rather than \n> the traditional native CRLF.\n\nBut they can equally easily set \"core.autocrlf=false\". Although the name still grates.\n\n> In fact, maybe it would even make sense to just make LF the default \n> \"native\" end-of-line sequence even on windows, so that Windows people who \n> actually want CRLF would have to set core.eol=crlf. Whatever. That would \n> be for the Windows git users to fight out, I don't care.\n\nThis is the crux of the problem. It's possible that I'm just being prejudiced, but I think that if someone wants CRLF as a _default_ they probably want it to be the default for all text files, not just normalized ones.\n\n> But if we are going to clean up text attribute handling, then I really \n> think we want to totally break that old \"core.autocrlf\" dependency.\n\n\"core.autocrlf=true\" is exactly equivalent to \"core.eol=crlf\" in a repository with \"* text=auto\" (setting the \"text\" attribute disables the index check).\n\nIn a repository that doesn't care, \"core.autocrlf=true\" will normalize your text files and put CRLFs in them, while \"core.eol=crlf\" won't do a thing.\n\nUnless you're simply arguing for renaming autocrlf to eol?\n-- \nEyvind\n"},{"id":"141699","messageId":"A9FDBDB6-61D0-4FD2-BF1E-D5B802D2880E@gmail.com","threadId":"23789","inReplyTo":"20100514045646.GA2433@progeny.tock","subject":"Re: [RFC/PATCH v3 4/5] Rename \"crlf\" attribute as \"eolconv\"","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-14T21:21:53Z","receivedAt":"2010-05-14T21:21:53Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 14. mai 2010, at 06.56, Jonathan Nieder wrote:\n\n[Lots of good answers cut]\n\n> - The crlf attribute gets a new synonym \"text\" to avoid confusion.\n\nI would prefer to phrase that as \"the text attribute has the synonym 'crlf' for backwards compatilibity\". If I wanted to avoid confusion I wouldn't have renamed it ;)\n-- \nEyvind\n"},{"id":"141702","messageId":"alpine.LFD.2.00.1005141421560.3711@i5.linux-foundation.org","threadId":"23789","inReplyTo":"7DF58EB2-F6A0-47FB-BC89-72757B29FAE6@gmail.com","subject":"Re: [RFC/PATCH v3 4/5] Rename \"crlf\" attribute as \"eolconv\"","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-14T21:27:57Z","receivedAt":"2010-05-14T21:27:57Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 14 May 2010, Eyvind Bernhardsen wrote:\n\n> On 13. mai 2010, at 23.45, Linus Torvalds wrote:\n> \n> > On Thu, 13 May 2010, Eyvind Bernhardsen wrote:\n> >> \n> >> Do you agree that \"native\" eol should only be CRLF if autocrlf is true? \n> > \n> > Not really. We're trying to get _away_ from .gitattributes depending on \n> > autocrlf, aren't we?\n> \n> I'm not sure we still are. I certainly was when I started this series, \n> but that was because autocrlf just plain didn't work with many existing \n> repositories. When \"safe autocrlf\" fixed that, I decided that the extra \n> complexity of core.eolStyle wasn't worth it.\n\nThe thing is, I disagree with your notion of \"safe autocrlf\". I think it's \nugly, and I don't think it's safe at all. It adds a _feeling_ of safety \nthat isn't actually safe.\n\nIn short:\n\n - core.autocrlf is _always_ dangerous. Your \"safe\" thing isn't any safer \n at all, since it depends on something that isn't reliable (previous \n state).\n\n Example: new binary files, or changed files, or renames.\n\n - so if you want text conversion, but you want it to be truly safe, and \n only happen for certain files, YOU MUST NOT ENABLE autocrlf.\n\n - Ergo: if you make the .gitattributes behaviour depend on autocrlf, \n you're still screwed, and you've not actually improved on anything at \n all in the end.\n\nIt's really that simple. I think \"autocrlf\" actually works pretty well, \nbut at the same time, I think we made mistakes in the initial design. \nLet's not make them again.\n\n\t\tLinus\n"},{"id":"141703","messageId":"13750F09-B5F9-421E-9479-4C50CC0E59A1@gmail.com","threadId":"23789","inReplyTo":"AANLkTil1i_vFAvT1CotYdK47LnufVKc17-1168rOVcMX@mail.gmail.com","subject":"Re: [RFC/PATCH v3 4/5] Rename \"crlf\" attribute as \"eolconv\"","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-14T21:32:03Z","receivedAt":"2010-05-14T21:32:03Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 14. mai 2010, at 04.34, Robert Buck wrote:\n\n> Probably a newbie question, lots to read, lots already read, but I\n> really want to verify if I have this correct. So in a nutshell, in the\n> gitattributes file\n> \n> * text\n\nI missed this when I replied to Jonathan, but you probably want \"* text=auto\" here. \"* text\" would force git to treat all files as text files.\n\nAlso, as Jonathan said, if you want CRLF line endings you currently have to have core.autocrlf set to \"true\" (which is the default on Windows).\n-- \nEyvind\n"},{"id":"141744","messageId":"61355CFC-EB9E-4B76-9450-F2DF1B2903C0@gmail.com","threadId":"23789","inReplyTo":"20100514101648.GB6212@dpotapov.dyndns.org","subject":"Re: utf8 BOM","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-15T20:23:52Z","receivedAt":"2010-05-15T20:23:52Z","isPatch":false,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 14. mai 2010, at 12.16, Dmitry Potapov wrote:\n\n> Probably, ability of automatic add utf8 BOM on Windows to text files\n> (which are marked as \"unicode\") can be helpful, but it is just a part\n> of the problem of how to deal with text files in \"legacy\" encoding,\n> which are still widely used on Windows.\n\nSounds like something a clean/smudge filter should be able to do. The clean filter converts legacy encoded text to utf8 and strips any utf8 BOM before checking the file in, and the smudge filter writes the file out as utf8 with a BOM (which hopefully works no matter what your code page is? I don't know much about Windows i18n).\n\nAdding this to convert.c would be more difficult, at least politically, since I assume it would be Windows-specific code.\n-- \nEyvind\n"},{"id":"141745","messageId":"1273956445-67531-1-git-send-email-eyvind.bernhardsen@gmail.com","threadId":"23789","inReplyTo":"alpine.LFD.2.00.1005141421560.3711@i5.linux-foundation.org","subject":"[PATCH] Add \"core.eol\" variable to control end-of-line conversion","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-15T20:47:25Z","receivedAt":"2010-05-15T20:47:25Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"Introduce a new configuration variable, \"core.eol\", that allows the user\nto set which line endings to use for end-of-line-normalized files in the\nworking directory. It defaults to \"native\", which means CRLF on Windows\nand LF everywhere else.\n\nFor backwards compatibility, \"core.autocrlf\" will override core.eol if\ncore.eol is left unset. This means that\n\n[core]\n\tautocrlf = true\n\nwill give CRLFs in the working directory even on platforms with LF as\ntheir native line ending.\n\nIf core.eol is set explicitly (including setting it to \"native\"), it\nwill override core.autocrlf so that\n\n[core]\n autocrlf = true\n eol = lf\n\nnormalizes all files that look like text, but does not put CRLFs in the\nworking directory.\n\nSigned-off-by: Eyvind Bernhardsen \n---\n\nIt turns out that my resistance to \"core.eol\" was mostly laziness, so I\njust implemented it.\n\nI decided that \"core.autocrlf\" has to override the native line ending if\n\"core.eol\" isn't set explicitly, which gives some extra complexity in\nconvert.c.\n\nFor 1.8 I would consider making core.autocrlf just turn on normalization\nand leave the working directory line ending decision to core.eol, but\nthat _will_ break people's setups.\n\nPatch is on top of my latest series.\n-- \nEyvind\n\n Documentation/config.txt | 8 ++++\n Documentation/gitattributes.txt | 6 ++-\n Makefile | 3 +\n cache.h | 13 ++++++\n config.c | 12 ++++++\n convert.c | 39 +++++++++++-------\n environment.c | 1 +\n t/t0026-eol-config.sh | 83 +++++++++++++++++++++++++++++++++++++++\n 8 files changed, 149 insertions(+), 16 deletions(-)\n create mode 100755 t/t0026-eol-config.sh\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 207351b..7cc15a4 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -207,6 +207,14 @@ core.autocrlf::\n \tthe file's `text` attribute, or if `text` is unspecified,\n \tbased on the file's contents. See linkgit:gitattributes[5].\n \n+core.eol::\n+\tSets the line ending type to use in the working directory for\n+\tfiles that have the `text` property set. Alternatives are\n+\t'lf', 'crlf' and 'native', which uses the platform's native\n+\tline ending. The default value is `native`. See\n+\tlinkgit:gitattributes[5] for more information on end-of-line\n+\tconversion.\n+\n core.safecrlf::\n \tIf true, makes git check if converting `CRLF` is reversible when\n \tend-of-line conversion is active. Git will verify if a command\ndiff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt\nindex 25753b7..8268c09 100644\n--- a/Documentation/gitattributes.txt\n+++ b/Documentation/gitattributes.txt\n@@ -207,7 +207,11 @@ attribute to \"auto\" for _all_ files.\n ------------------------\n \n This ensures that all files that git considers to be text will have\n-normalized (LF) line endings in the repository.\n+normalized (LF) line endings in the repository. The `core.eol`\n+configuration variable controls which line endings git will use for\n+normalized files in your working directory; the default is to use the\n+native line ending for your platform, or CRLF if `core.autocrlf` is\n+set.\n \n NOTE: When `text=auto` normalization is enabled in an existing\n repository, any text files containing CRLFs should be normalized. If\ndiff --git a/Makefile b/Makefile\nindex 910f471..419532e 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -224,6 +224,8 @@ all::\n #\n # Define CHECK_HEADER_DEPENDENCIES to check for problems in the hard-coded\n # dependency rules.\n+#\n+# Define NATIVE_CRLF if your platform uses CRLF for line endings.\n \n GIT-VERSION-FILE: FORCE\n \t@$(SHELL_PATH) ./GIT-VERSION-GEN\n@@ -989,6 +991,7 @@ ifeq ($(uname_S),Windows)\n \tNO_CURL = YesPlease\n \tNO_PYTHON = YesPlease\n \tBLK_SHA1 = YesPlease\n+\tNATIVE_CRLF = YesPlease\n \n \tCC = compat/vcbuild/scripts/clink.pl\n \tAR = compat/vcbuild/scripts/lib.pl\ndiff --git a/cache.h b/cache.h\nindex d1f669e..ac6bfbd 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -568,6 +568,19 @@ enum auto_crlf {\n \n extern enum auto_crlf auto_crlf;\n \n+enum eol {\n+\tEOL_UNSET,\n+\tEOL_CRLF,\n+\tEOL_LF,\n+#ifdef NATIVE_CRLF\n+\tEOL_NATIVE = EOL_CRLF\n+#else\n+\tEOL_NATIVE = EOL_LF\n+#endif\n+};\n+\n+extern enum eol eol;\n+\n enum branch_track {\n \tBRANCH_TRACK_UNSPECIFIED = -1,\n \tBRANCH_TRACK_NEVER = 0,\ndiff --git a/config.c b/config.c\nindex b60a1ff..4edd940 100644\n--- a/config.c\n+++ b/config.c\n@@ -477,6 +477,18 @@ static int git_default_core_config(const char *var, const char *value)\n \t\treturn 0;\n \t}\n \n+\tif (!strcmp(var, \"core.eol\")) {\n+\t\tif (value && !strcasecmp(value, \"lf\"))\n+\t\t\teol = EOL_LF;\n+\t\telse if (value && !strcasecmp(value, \"crlf\"))\n+\t\t\teol = EOL_CRLF;\n+\t\telse if (value && !strcasecmp(value, \"native\"))\n+\t\t\teol = EOL_NATIVE;\n+\t\telse\n+\t\t\teol = EOL_UNSET;\n+\t\treturn 0;\n+\t}\n+\n \tif (!strcmp(var, \"core.notesref\")) {\n \t\tnotes_ref_name = xstrdup(value);\n \t\treturn 0;\ndiff --git a/convert.c b/convert.c\nindex a309e07..b7ee469 100644\n--- a/convert.c\n+++ b/convert.c\n@@ -20,12 +20,6 @@ enum action {\n \tCRLF_AUTO,\n };\n \n-enum eol {\n-\tEOL_UNSET,\n-\tEOL_LF,\n-\tEOL_CRLF,\n-};\n-\n struct text_stat {\n \t/* NUL, CR, LF and CRLF counts */\n \tunsigned nul, cr, lf, crlf;\n@@ -244,12 +238,27 @@ static int crlf_to_worktree(const char *path, const char *src, size_t len,\n \tchar *to_free = NULL;\n \tstruct text_stat stats;\n \n-\tif ((action == CRLF_BINARY) || (action == CRLF_INPUT) ||\n-\t (action != CRLF_CRLF && auto_crlf != AUTO_CRLF_TRUE))\n+\tif (!len)\n \t\treturn 0;\n \n-\tif (!len)\n+\tswitch (action) {\n+\tcase CRLF_CRLF:\n+\t\tbreak;\n+\tcase CRLF_BINARY:\n+\tcase CRLF_INPUT:\n \t\treturn 0;\n+\tcase CRLF_GUESS:\n+\t\tif (auto_crlf == AUTO_CRLF_FALSE)\n+\t\t\treturn 0;\n+\t\t/* fall through */\n+\tcase CRLF_TEXT:\n+\tcase CRLF_AUTO:\n+\t\tif (eol == EOL_LF ||\n+\t\t (eol == EOL_UNSET &&\n+\t\t (auto_crlf == AUTO_CRLF_INPUT ||\n+\t\t auto_crlf == AUTO_CRLF_FALSE && EOL_NATIVE == EOL_LF)))\n+\t\t\treturn 0;\n+\t}\n \n \tgather_stats(src, len, &stats);\n \n@@ -670,7 +679,7 @@ int convert_to_git(const char *path, const char *src, size_t len,\n {\n \tstruct git_attr_check check[5];\n \tenum action action = CRLF_GUESS;\n-\tenum eol eol = EOL_UNSET;\n+\tenum eol eol_attr = EOL_UNSET;\n \tint ident = 0, ret = 0;\n \tconst char *filter = NULL;\n \n@@ -682,7 +691,7 @@ int convert_to_git(const char *path, const char *src, size_t len,\n \t\t\taction = git_path_check_crlf(path, check + 0);\n \t\tident = git_path_check_ident(path, check + 1);\n \t\tdrv = git_path_check_convert(path, check + 2);\n-\t\teol = git_path_check_eol(path, check + 3);\n+\t\teol_attr = git_path_check_eol(path, check + 3);\n \t\tif (drv && drv->clean)\n \t\t\tfilter = drv->clean;\n \t}\n@@ -692,7 +701,7 @@ int convert_to_git(const char *path, const char *src, size_t len,\n \t\tsrc = dst->buf;\n \t\tlen = dst->len;\n \t}\n-\taction = determine_action(action, eol);\n+\taction = determine_action(action, eol_attr);\n \tret |= crlf_to_git(path, src, len, dst, action, checksafe);\n \tif (ret) {\n \t\tsrc = dst->buf;\n@@ -705,7 +714,7 @@ int convert_to_working_tree(const char *path, const char *src, size_t len, struc\n {\n \tstruct git_attr_check check[5];\n \tenum action action = CRLF_GUESS;\n-\tenum eol eol = EOL_UNSET;\n+\tenum eol eol_attr = EOL_UNSET;\n \tint ident = 0, ret = 0;\n \tconst char *filter = NULL;\n \n@@ -717,7 +726,7 @@ int convert_to_working_tree(const char *path, const char *src, size_t len, struc\n \t\t\taction = git_path_check_crlf(path, check + 0);\n \t\tident = git_path_check_ident(path, check + 1);\n \t\tdrv = git_path_check_convert(path, check + 2);\n-\t\teol = git_path_check_eol(path, check + 3);\n+\t\teol_attr = git_path_check_eol(path, check + 3);\n \t\tif (drv && drv->smudge)\n \t\t\tfilter = drv->smudge;\n \t}\n@@ -727,7 +736,7 @@ int convert_to_working_tree(const char *path, const char *src, size_t len, struc\n \t\tsrc = dst->buf;\n \t\tlen = dst->len;\n \t}\n-\taction = determine_action(action, eol);\n+\taction = determine_action(action, eol_attr);\n \tret |= crlf_to_worktree(path, src, len, dst, action);\n \tif (ret) {\n \t\tsrc = dst->buf;\ndiff --git a/environment.c b/environment.c\nindex db4a5e9..83d38d3 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -40,6 +40,7 @@ const char *editor_program;\n const char *excludes_file;\n enum auto_crlf auto_crlf = AUTO_CRLF_FALSE;\n int read_replace_refs = 1;\n+enum eol eol = EOL_UNSET;\n enum safe_crlf safe_crlf = SAFE_CRLF_WARN;\n unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;\n enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;\ndiff --git a/t/t0026-eol-config.sh b/t/t0026-eol-config.sh\nnew file mode 100755\nindex 0000000..5b6c297\n--- /dev/null\n+++ b/t/t0026-eol-config.sh\n@@ -0,0 +1,83 @@\n+#!/bin/sh\n+\n+test_description='CRLF conversion'\n+\n+. ./test-lib.sh\n+\n+has_cr() {\n+\ttr '\\015' Q <\"$1\" | grep Q >/dev/null\n+}\n+\n+test_expect_success setup '\n+\n+\tgit config core.autocrlf false &&\n+\n+\techo \"one text\" > .gitattributes\n+\n+\tfor w in Hello world how are you; do echo $w; done >one &&\n+\tfor w in I am very very fine thank you; do echo $w; done >two &&\n+\tgit add . &&\n+\n+\tgit commit -m initial &&\n+\n+\tone=`git rev-parse HEAD:one` &&\n+\ttwo=`git rev-parse HEAD:two` &&\n+\n+\techo happy.\n+'\n+\n+test_expect_success 'eol=lf puts LFs in normalized file' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.eol lf &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\t! has_cr one &&\n+\t! has_cr two &&\n+\tonediff=`git diff one` &&\n+\ttwodiff=`git diff two` &&\n+\ttest -z \"$onediff\" -a -z \"$twodiff\"\n+'\n+\n+test_expect_success 'eol=crlf puts CRLFs in normalized file' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.eol crlf &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\thas_cr one &&\n+\t! has_cr two &&\n+\tonediff=`git diff one` &&\n+\ttwodiff=`git diff two` &&\n+\ttest -z \"$onediff\" -a -z \"$twodiff\"\n+'\n+\n+test_expect_success 'eol=lf overrides autocrlf=true' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.eol lf &&\n+\tgit config core.autocrlf true &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\t! has_cr one &&\n+\t! has_cr two &&\n+\tonediff=`git diff one` &&\n+\ttwodiff=`git diff two` &&\n+\ttest -z \"$onediff\" -a -z \"$twodiff\"\n+'\n+\n+test_expect_success 'autocrlf=true overrides unset eol' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config --unset-all core.eol &&\n+\tgit config core.autocrlf true &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\thas_cr one &&\n+\thas_cr two &&\n+\tonediff=`git diff one` &&\n+\ttwodiff=`git diff two` &&\n+\ttest -z \"$onediff\" -a -z \"$twodiff\"\n+'\n+\n+test_done\n-- \n1.7.1.5.gd739a\n"},{"id":"141756","messageId":"20100516051927.GA17200@dpotapov.dyndns.org","threadId":"23789","inReplyTo":"61355CFC-EB9E-4B76-9450-F2DF1B2903C0@gmail.com","subject":"Re: utf8 BOM","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-05-16T05:19:27Z","receivedAt":"2010-05-16T05:19:27Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sat, May 15, 2010 at 10:23:52PM +0200, Eyvind Bernhardsen wrote:\n> On 14. mai 2010, at 12.16, Dmitry Potapov wrote:\n> \n> > Probably, ability of automatic add utf8 BOM on Windows to text files\n> > (which are marked as \"unicode\") can be helpful, but it is just a part\n> > of the problem of how to deal with text files in \"legacy\" encoding,\n> > which are still widely used on Windows.\n>\n> Sounds like something a clean/smudge filter should be able to do.\n\nYes, it should if you handful files that need such conversion. However,\nif you want it for every text file, running filters are slow (especially\non Windows), and they are not capable to autodetect text.\n\n> (which hopefully works no matter what your code\n> page is? I don't know much about Windows i18n).\n\nYes, it does. I am not an expert on Windows either, but as far as I\nknow, BOM are used to mark unicode files, which could be either UTF-8\nor UTF-16. BTW, UTF-16 are treated by Git as \"binary\" now, which may\nnot always convenient, because impossible to do \"merge\" or \"diff\".\n\n> Adding this to convert.c would be more difficult, at least\n> politically, since I assume it would be Windows-specific code.\n\nI don't think it needs any Windows-specific code. We already have some\nfunctions to convert text from different charsets, which could be used.\nBut this feature should be developed and tested by people who work on\nWindows regularly and need this feature, because there is no substitute\nfor testing and experience of how well it works in practice. Currently,\nI rarely use Windows and can get by clean/smudge filters.\n\n\nDmitry\n"},{"id":"141765","messageId":"00E0B9AC-2A2E-4F95-9B35-F3F63EBC3CF3@gmail.com","threadId":"23789","inReplyTo":"20100516051927.GA17200@dpotapov.dyndns.org","subject":"Re: utf8 BOM","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-16T10:37:54Z","receivedAt":"2010-05-16T10:37:54Z","isPatch":false,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 16. mai 2010, at 07.19, Dmitry Potapov wrote:\n\n> On Sat, May 15, 2010 at 10:23:52PM +0200, Eyvind Bernhardsen wrote:\n>> (which hopefully works no matter what your code\n>> page is? I don't know much about Windows i18n).\n> \n> Yes, it does. I am not an expert on Windows either, but as far as I\n> know, BOM are used to mark unicode files, which could be either UTF-8\n> or UTF-16. BTW, UTF-16 are treated by Git as \"binary\" now, which may\n> not always convenient, because impossible to do \"merge\" or \"diff\".\n\nOkay, so something that checks text files to see if they're utf16 (maybe just accept anything with a utf16 BOM as utf16?) and converts them to utf8 might be useful on any platform. Stripping utf8 BOMs and optionally re-adding them on output would be a natural extension. \"core.autoutf\", anyone?\n\n>> Adding this to convert.c would be more difficult, at least\n>> politically, since I assume it would be Windows-specific code.\n> \n> I don't think it needs any Windows-specific code. We already have some\n> functions to convert text from different charsets, which could be used.\n> But this feature should be developed and tested by people who work on\n> Windows regularly and need this feature, because there is no substitute\n> for testing and experience of how well it works in practice. Currently,\n> I rarely use Windows and can get by clean/smudge filters.\n\nYeah, the problem is finding someone who needs the feature _and_ is able/willing to implement it. I try to keep a Unix-like experience on Windows, so I don't usually run into utf8 BOMs.\n-- \nEyvind\n"},{"id":"141766","messageId":"AANLkTin-KO8n591Hz7BuJCaHCe4osfCvUhH4ua0beyXt@mail.gmail.com","threadId":"23789","inReplyTo":"1273956445-67531-1-git-send-email-eyvind.bernhardsen@gmail.com","subject":"Re: [PATCH] Add \"core.eol\" variable to control end-of-line conversion","fromName":"Robert Buck","fromEmail":"buck.robert.j@gmail.com","sentAt":"2010-05-16T10:39:57Z","receivedAt":"2010-05-16T10:39:57Z","isPatch":true,"sender":{"key":"buck.robert.j@gmail.com","avatar":"https://gravatar.com/avatar/1686742e8ac2595378aac67f26fd638ddaf494194f9af0cb6082c4a7eca1a366?d=mp&s=160"},"body":"On Sat, May 15, 2010 at 4:47 PM, Eyvind Bernhardsen\n wrote:\n> Introduce a new configuration variable, \"core.eol\", that allows the user\n> to set which line endings to use for end-of-line-normalized files in the\n> working directory.  It defaults to \"native\", which means CRLF on Windows\n> and LF everywhere else.\n>\n> For backwards compatibility, \"core.autocrlf\" will override core.eol if\n> core.eol is left unset.  This means that\n>\n> [core]\n>        autocrlf = true\n>\n> will give CRLFs in the working directory even on platforms with LF as\n> their native line ending.\n>\n> If core.eol is set explicitly (including setting it to \"native\"), it\n> will override core.autocrlf so that\n>\n> [core]\n>        autocrlf = true\n>        eol = lf\n>\n> normalizes all files that look like text, but does not put CRLFs in the\n> working directory.\n>\n> Signed-off-by: Eyvind Bernhardsen \n> ---\n>\n> It turns out that my resistance to \"core.eol\" was mostly laziness, so I\n> just implemented it.\n>\n> I decided that \"core.autocrlf\" has to override the native line ending if\n> \"core.eol\" isn't set explicitly, which gives some extra complexity in\n> convert.c.\n>\n> For 1.8 I would consider making core.autocrlf just turn on normalization\n> and leave the working directory line ending decision to core.eol, but\n> that _will_ break people's setups.\n>\n> Patch is on top of my latest series.\n> --\n> Eyvind\n\nLooking forward to this change. In terms of usability it is really\nnice. Eager to see it in a release.\n"},{"id":"141767","messageId":"20100516112612.GV2480@ece.pdx.edu","threadId":"23789","inReplyTo":"00E0B9AC-2A2E-4F95-9B35-F3F63EBC3CF3@gmail.com","subject":"Re: utf8 BOM","fromName":"Tait","fromEmail":"git.git@t41t.com","sentAt":"2010-05-16T11:26:12Z","receivedAt":"2010-05-16T11:26:12Z","isPatch":false,"sender":{"key":"git.git@t41t.com","avatar":null},"body":"> Okay, so something that checks text files to see if they're utf...\n> \"core.autoutf\", anyone?\n\nThis (and crlf-conversion, for that matter) strikes me as something best \nhandled outside of git core, such as through checkout/commit hooks. Perhaps \nexamples of such hooks could be provided and adapted by each project and \nuser as that user/project sees fit for their specific choice of repository \nformat and development environment.\n\nGiven that git already chose not to screw around with encodings or define \na canonical encoding for the on-disk format (it's just a string of bytes), \nit would be consistent and reasonable to not mess with these other things, \ntoo.\n\nTait\n"},{"id":"141770","messageId":"20100516133259.GC17200@dpotapov.dyndns.org","threadId":"23789","inReplyTo":"20100516112612.GV2480@ece.pdx.edu","subject":"Re: utf8 BOM","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-05-16T13:32:59Z","receivedAt":"2010-05-16T13:32:59Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, May 16, 2010 at 04:26:12AM -0700, Tait wrote:\n> > Okay, so something that checks text files to see if they're utf...\n> > \"core.autoutf\", anyone?\n> \n> This (and crlf-conversion, for that matter) strikes me as something best \n> handled outside of git core, such as through checkout/commit hooks. Perhaps \n> examples of such hooks could be provided and adapted by each project and \n> user as that user/project sees fit for their specific choice of repository \n> format and development environment.\n\nThere are a few problems with using filters for crlf conversion:\n\n1. It is a way too slow... Running a script for each file is in a repo\nis even slow on Linux, and on Windows, it is going to be horrible slow.\n\n2. You have to install this filter in every clone, and by the time when\nyou install it, your repository is already checked out with the wrong\nending. So, you need to fix it.\n\nWhile using scripts is good where you need flexibility, it is not the\ncase with crlf conversion. Users want it to just work, and they want\nsimple and easy to understand rules how to mark what files should and\nshould not be converted. If every project is going with itw own rules\nand scripts, it is going to be a big mess.\n\nNow, when we speak about charset encoding, it could make sense to try\nthis new feature as a filter, but if it is something that is to be used\nwidely, it should be eventually re-written in C.\n\n\nDmitry\n"}]}