{"thread":{"id":"23749","subject":"[PATCH/RFC v2 0/4] End-of-line normalization, take 2 (now only slightly scary)","startedAt":"2010-05-08T21:46:17Z","lastAt":"2010-05-10T18:33:39Z","messageCount":37,"participants":["Eyvind Bernhardsen","Linus Torvalds","Dmitry Potapov","hasen j","Finn Arne Gangstad","Robert Buck","Jay Soffian","Junio C Hamano"],"isPatch":true,"patchVersion":2,"patchTotal":4},"messages":[{"id":"141262","messageId":"cover.1273352819.git.eyvind.bernhardsen@gmail.com","threadId":"23749","inReplyTo":null,"subject":"[PATCH/RFC v2 0/4] End-of-line normalization, take 2 (now only slightly scary)","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-08T21:46:17Z","receivedAt":"2010-05-08T21:46:17Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"Okay, here's a second shot at my end-of-line conversion sanification\nseries. The main change is that instead of introducing a new attribute,\nI've added a new mode to the \"crlf\" attribute: \"crlf=auto\".\n\nThe semantics of \"crlf\" have also been modified slightly in that the\nattribute now enables end-of-line normalization whenever it is set,\ninstead of simply amending what happens when \"core.autocrlf\" is enabled\nas it did before.\n\nI think this version is a step in a direction that everyone can agree\non. The new config variable seems to be a point of contention, but\nwhile I'm not married to the name \"core.eolStyle\" by any means, I don't\nthink \"core.crlf\" explains what it is, and I don't think \"input\" and\n\"true\" are good ways of describing what it does.\n\nI agree with Linus that \"crlf=input\" seems crazy, and I agree with\nDmitry that \"crlf\" is a bad name for the attribute to begin with. This\nisn't bikeshedding: git has lost a lot of its sharp edges recently, but\nthis one remains, and is quite an important one for Windows users.\n\nFor now, though, I'd like the focus for this patch series to be creating\na mechanism that allows a project to enforce line ending normalization\nfor all contributors to the repository, while letting the user decide\nwhat line endings he likes to see in his working directory. If we end\nup not shooting anybody in the head, all the better.\n\nThanks for all your inputs. I was worried that nobody would even notice\nthis series :) I've expanded the Cc list a bit, hope that's okay.\n\nEyvind Bernhardsen (4):\n Add \"core.eolStyle\" variable to control end-of-line conversion\n Add tests for per-repository eol normalization\n Pass eol conv mode as an argument instead of using global auto_crlf\n Add per-repository eol normalization\n\n Documentation/config.txt | 11 ++-\n Documentation/gitattributes.txt | 71 +++++++++++-----\n Makefile | 3 +\n cache.h | 19 ++++\n config.c | 16 +++-\n convert.c | 52 +++++++++---\n environment.c | 1 +\n t/t0025-crlf-auto.sh | 180 +++++++++++++++++++++++++++++++++++++++\n 8 files changed, 317 insertions(+), 36 deletions(-)\n create mode 100755 t/t0025-crlf-auto.sh\n"},{"id":"141263","messageId":"c8ef28b72709013f17e093954a0f4e2ad1fb9652.1273352819.git.eyvind.bernhardsen@gmail.com","threadId":"23749","inReplyTo":"cover.1273352819.git.eyvind.bernhardsen@gmail.com","subject":"[PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-08T21:46:18Z","receivedAt":"2010-05-08T21:46:18Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"Introduce a new configuration variable, \"core.eolStyle\", that allows the\nuser to set which line endings to use for end-of-line-normalized files\nin the working directory. It defaults to \"native\", which means CRLF on\nWindows and LF everywhere else.\n\nSigned-off-by: Eyvind Bernhardsen \n---\n Documentation/config.txt | 7 +++++++\n Makefile | 3 +++\n cache.h | 19 +++++++++++++++++++\n config.c | 16 +++++++++++++++-\n environment.c | 1 +\n 5 files changed, 45 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 92f851e..3956ff7 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -207,6 +207,13 @@ core.autocrlf::\n \tthe file's `crlf` attribute, or if `crlf` is unspecified,\n \tbased on the file's contents. See linkgit:gitattributes[5].\n \n+core.eolStyle::\n+\tSets the line ending type to use for text files in the working\n+\tdirectory when the `auto-eol` property is set. Alternatives are\n+\t'lf', 'crlf', 'native' and 'false'. 'native', the default, uses\n+\tthe platform's native line ending. 'false' disables `auto-eol`\n+\tline ending conversion. 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\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 5eb0573..690511e 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -561,6 +561,25 @@ 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+enum eol_style {\n+\tEOL_STYLE_FALSE = AUTO_CRLF_FALSE,\n+\tEOL_STYLE_CRLF = AUTO_CRLF_TRUE,\n+\tEOL_STYLE_LF = AUTO_CRLF_INPUT,\n+#ifdef NATIVE_CRLF\n+\tEOL_STYLE_NATIVE = EOL_STYLE_CRLF,\n+#else\n+\tEOL_STYLE_NATIVE = EOL_STYLE_LF,\n+#endif\n+};\n+\n+extern enum eol_style eol_style;\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..8a11052 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);\n@@ -477,6 +477,20 @@ static int git_default_core_config(const char *var, const char *value)\n \t\treturn 0;\n \t}\n \n+\tif (!strcmp(var, \"core.eolstyle\")) {\n+\t\tif (value && !strcasecmp(value, \"lf\"))\n+\t\t\teol_style = EOL_STYLE_LF;\n+\t\telse if (value && !strcasecmp(value, \"crlf\"))\n+\t\t\teol_style = EOL_STYLE_CRLF;\n+\t\telse if (value && !strcasecmp(value, \"native\"))\n+\t\t\teol_style = EOL_STYLE_NATIVE;\n+\t\telse if (! git_config_bool(var, value))\n+\t\t\teol_style = EOL_STYLE_FALSE;\n+\t\telse\n+\t\t\treturn error(\"Malformed value for %s\", var);\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/environment.c b/environment.c\nindex 876c5e5..05cd1d5 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -40,6 +40,7 @@ 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 int read_replace_refs = 1;\n+enum eol_style eol_style = EOL_STYLE_NATIVE;\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;\n-- \n1.7.1.3.gb95c9\n"},{"id":"141265","messageId":"8372bad8c69c3d6a14ee7c18e0757710e1be2297.1273352819.git.eyvind.bernhardsen@gmail.com","threadId":"23749","inReplyTo":"cover.1273352819.git.eyvind.bernhardsen@gmail.com","subject":"[PATCH/RFC v2 2/4] Add tests for per-repository eol normalization","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-08T21:46:19Z","receivedAt":"2010-05-08T21:46:19Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"\nSigned-off-by: Eyvind Bernhardsen \n---\n t/t0025-crlf-auto.sh | 180 ++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 180 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..367b459\n--- /dev/null\n+++ b/t/t0025-crlf-auto.sh\n@@ -0,0 +1,180 @@\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 autocrlf=true' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf false &&\n+\tgit config core.eolstyle crlf &&\n+\techo \"* crlf=auto\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\tunset missing_cr &&\n+\n+\tfor f in one two\n+\tdo\n+\t\tif ! has_cr \"$f\"\n+\t\tthen\n+\t\t\techo \"Eh? $f\"\n+\t\t\tmissing_cr=1\n+\t\t\tbreak\n+\t\tfi\n+\tdone &&\n+\ttest -z \"$missing_cr\"\n+'\n+\n+test_expect_failure 'crlf=auto, eolStyle=lf <=> autocrlf=input' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf false &&\n+\tgit config core.eolstyle lf &&\n+\techo \"* crlf=auto\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\tif has_cr one || ! has_cr two\n+\tthen\n+\t\techo \"Eh? $f\"\n+\t\tfalse\n+\tfi &&\n+\tonediff=`git diff one` &&\n+\ttwodiff=`git diff two` &&\n+\ttest -z \"$onediff\" -a -n \"$twodiff\"\n+'\n+\n+test_expect_success 'crlf=auto, eolStyle=false <=> autocrlf=false' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf false &&\n+\tgit config core.eolstyle false &&\n+\techo \"* crlf=auto\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\tif has_cr one || ! has_cr two\n+\tthen\n+\t\techo \"Eh? $f\"\n+\t\tfalse\n+\tfi\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 crlf=auto, eolStyle=lf' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf true &&\n+\tgit config core.eolstyle lf &&\n+\techo \"* crlf=auto\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\tunset missing_cr &&\n+\n+\tfor f in one two\n+\tdo\n+\t\tif ! has_cr \"$f\"\n+\t\tthen\n+\t\t\techo \"Eh? $f\"\n+\t\t\tmissing_cr=1\n+\t\t\tbreak\n+\t\tfi\n+\tdone &&\n+\ttest -z \"$missing_cr\"\n+'\n+\n+test_expect_success 'autocrlf=input overrides crlf=auto, eolStyle=crlf' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf input &&\n+\tgit config core.eolstyle crlf &&\n+\techo \"* crlf=auto\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\tif has_cr one || ! has_cr two\n+\tthen\n+\t\techo \"Eh? $f\"\n+\t\tfalse\n+\tfi &&\n+\tonediff=`git diff one` &&\n+\ttwodiff=`git diff two` &&\n+\ttest -z \"$onediff\" -a -n \"$twodiff\"\n+'\n+\n+test_expect_success 'autocrlf=true overrides crlf=auto, eolStyle=false' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf true &&\n+\tgit config core.eolstyle false &&\n+\techo \"* crlf=auto\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\tunset missing_cr &&\n+\n+\tfor f in one two\n+\tdo\n+\t\tif ! has_cr \"$f\"\n+\t\tthen\n+\t\t\techo \"Eh? $f\"\n+\t\t\tmissing_cr=1\n+\t\t\tbreak\n+\t\tfi\n+\tdone &&\n+\ttest -z \"$missing_cr\"\n+'\n+\n+test_done\n-- \n1.7.1.3.gb95c9\n"},{"id":"141264","messageId":"de1db7b41b76dae815988590dbb707e2fa101440.1273352819.git.eyvind.bernhardsen@gmail.com","threadId":"23749","inReplyTo":"cover.1273352819.git.eyvind.bernhardsen@gmail.com","subject":"[PATCH/RFC v2 3/4] Pass eol conv mode as an argument instead of using global auto_crlf","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-08T21:46:20Z","receivedAt":"2010-05-08T21:46:20Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"This patch has no semantic changes, but makes the next commit easier to\nreview.\n\nSigned-off-by: Eyvind Bernhardsen \n---\n convert.c | 22 ++++++++++++----------\n 1 files changed, 12 insertions(+), 10 deletions(-)\n\ndiff --git a/convert.c b/convert.c\nindex 4f8fcb7..2eef2f6 100644\n--- a/convert.c\n+++ b/convert.c\n@@ -90,12 +90,13 @@ static int is_binary(unsigned long size, struct text_stat *stats)\n }\n \n static void check_safe_crlf(const char *path, int action,\n- struct text_stat *stats, enum safe_crlf checksafe)\n+\t\t\t struct text_stat *stats, enum safe_crlf checksafe,\n+\t\t\t int eol_conversion)\n {\n \tif (!checksafe)\n \t\treturn;\n \n-\tif (action == CRLF_INPUT || auto_crlf <= 0) {\n+\tif (action == CRLF_INPUT || eol_conversion <= 0) {\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 +107,7 @@ 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 (eol_conversion > 0) {\n \t\t/*\n \t\t * CRLFs would be added by checkout:\n \t\t * check if we have \"naked\" LFs\n@@ -121,12 +122,13 @@ static void check_safe_crlf(const char *path, int action,\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, int action, enum safe_crlf checksafe,\n+\t\t int eol_conversion)\n {\n \tstruct text_stat stats;\n \tchar *dst;\n \n-\tif ((action == CRLF_BINARY) || !auto_crlf || !len)\n+\tif ((action == CRLF_BINARY) || !eol_conversion || !len)\n \t\treturn 0;\n \n \tgather_stats(src, len, &stats);\n@@ -147,7 +149,7 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n \t\t\treturn 0;\n \t}\n \n-\tcheck_safe_crlf(path, action, &stats, checksafe);\n+\tcheck_safe_crlf(path, action, &stats, checksafe, eol_conversion);\n \n \t/* Optimization: No CR? Nothing to convert, regardless. */\n \tif (!stats.cr)\n@@ -180,13 +182,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, int action, int eol_conversion)\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 eol_conversion <= 0)\n \t\treturn 0;\n \n \tif (!len)\n@@ -591,7 +593,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-\tret |= crlf_to_git(path, src, len, dst, crlf, checksafe);\n+\tret |= crlf_to_git(path, src, len, dst, crlf, checksafe, auto_crlf);\n \tif (ret) {\n \t\tsrc = dst->buf;\n \t\tlen = dst->len;\n@@ -621,7 +623,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-\tret |= crlf_to_worktree(path, src, len, dst, crlf);\n+\tret |= crlf_to_worktree(path, src, len, dst, crlf, auto_crlf);\n \tif (ret) {\n \t\tsrc = dst->buf;\n \t\tlen = dst->len;\n-- \n1.7.1.3.gb95c9\n"},{"id":"141266","messageId":"abe2e2efb3c4e35270a08b912d0aa49aa600e5bc.1273352819.git.eyvind.bernhardsen@gmail.com","threadId":"23749","inReplyTo":"cover.1273352819.git.eyvind.bernhardsen@gmail.com","subject":"[PATCH/RFC v2 4/4] Add per-repository eol normalization","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-08T21:46:21Z","receivedAt":"2010-05-08T21:46:21Z","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. Add a new setting, \"auto\",\nwhich enables end-of-line conversion but does not override the automatic\nbinary file detection.\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\nSince the line ending style to be used in the working directory is a\nuser preference, the configuration variable \"core.eolStyle\" controls it.\n\n\"core.autocrlf\" can still be used to enable conversion, and every effort\nhas been taken to avoid backwards incompatibility. There is one small\nsemantic change: if \"crlf\" is set on a path, that file will now have its\nline endings normalized. Previously, they would only be normalized if\n\"core.autocrlf\" was also set.\n\nSigned-off-by: Eyvind Bernhardsen \n---\n Documentation/config.txt | 4 +-\n Documentation/gitattributes.txt | 71 +++++++++++++++++++++++++++-----------\n convert.c | 34 ++++++++++++++++--\n t/t0025-crlf-auto.sh | 4 +-\n 4 files changed, 84 insertions(+), 29 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 3956ff7..7bbf8a0 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -215,8 +215,8 @@ core.eolStyle::\n \tline ending conversion. 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..18b07f6 100644\n--- a/Documentation/gitattributes.txt\n+++ b/Documentation/gitattributes.txt\n@@ -92,17 +92,28 @@ 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+\n `crlf`\n ^^^^^^\n \n-This attribute controls the line-ending convention.\n+This attribute enables and controls end-of-line normalization. When\n+normalization is enabled for a file, its line endings are converted to\n+LF when it is checked in, and the configuration variable\n+`core.eolStyle` decides whether to convert line endings to CRLF on\n+checkout.\n+\n+Set to string value \"auto\"::\n+\n+\tWhen `crlf` is set to \"auto\", the file is marked for automatic\n+\tend-of-line normalization. If git detects that the file is\n+\ta text file, its line endings are normalized to LF on checkin.\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.\n+\tEnd-of-line conversion takes place without guessing the\n+\tcontent type by inspection.\n \n Unset::\n \n@@ -111,34 +122,52 @@ Unset::\n \n Unspecified::\n \n-\tUnspecified `crlf` attribute tells git to apply the\n-\t`core.autocrlf` conversion when the file content looks\n-\tlike text.\n+\tUnspecified `crlf` attribute tells git to apply end-of-line\n+\tconversion only if the `core.autocrlf` configuration variable\n+\tis set.\n \n Set to string value \"input\"::\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 the line endings to CRLF when the\n+\tfile is checked out.\n \n Any other value set to `crlf` attribute is ignored and git acts\n as if the attribute is left unspecified.\n \n \n-The `core.autocrlf` conversion\n-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n-\n-If the configuration variable `core.autocrlf` is false, no\n-conversion is done.\n+End-of-line conversion\n+^^^^^^^^^^^^^^^^^^^^^^\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+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. Binary files are\n+detected automatically and will not be modified; this detection can be\n+overridden with the `crlf` attribute.\n+\n+NOTE: This normalization requires the repository to be free of text\n+files containing CRLFs. When it is enabled on an existing repository,\n+the index should be rebuilt to find any such files, and these files\n+should either have their `crlf` attribute set to false (\"-crlf\"), or\n+they should be checked in to the repository in normalized form.\n+\n+This example shows how to convert an existing repository with a mix of\n+LF and CRLF contents into one with normalized line endings. From a\n+clean working directory:\n+\n+-------------------------------------------------\n+$ echo \"* crlf=auto\" >.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 in `.gitattributes` before 'git add -u'.\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 \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/convert.c b/convert.c\nindex 2eef2f6..6871896 100644\n--- a/convert.c\n+++ b/convert.c\n@@ -15,6 +15,7 @@\n #define CRLF_BINARY\t0\n #define CRLF_TEXT\t1\n #define CRLF_INPUT\t2\n+#define CRLF_AUTO\t3\n \n struct text_stat {\n \t/* NUL, CR, LF and CRLF counts */\n@@ -392,6 +393,17 @@ static void setup_convert_check(struct git_attr_check *check)\n \tcheck[2].attr = attr_filter;\n }\n \n+static int choose_eol_conversion(int auto_eol)\n+{\n+\tif (auto_crlf)\n+\t\treturn auto_crlf;\n+\n+\tif (auto_eol)\n+\t\treturn eol_style;\n+\n+\treturn 0;\n+}\n+\n static int count_ident(const char *cp, unsigned long size)\n {\n \t/*\n@@ -546,6 +558,8 @@ static int git_path_check_crlf(const char *path, struct git_attr_check *check)\n \t\t;\n \telse if (!strcmp(value, \"input\"))\n \t\treturn CRLF_INPUT;\n+\telse if (!strcmp(value, \"auto\"))\n+\t\treturn CRLF_AUTO;\n \treturn CRLF_GUESS;\n }\n \n@@ -575,7 +589,7 @@ int convert_to_git(const char *path, const char *src, size_t len,\n {\n \tstruct git_attr_check check[3];\n \tint crlf = CRLF_GUESS;\n-\tint ident = 0, ret = 0;\n+\tint ident = 0, ret = 0, auto_eol = 0;\n \tconst char *filter = NULL;\n \n \tsetup_convert_check(check);\n@@ -586,6 +600,11 @@ int convert_to_git(const char *path, const char *src, size_t len,\n \t\tdrv = git_path_check_convert(path, check + 2);\n \t\tif (drv && drv->clean)\n \t\t\tfilter = drv->clean;\n+\t\tif (crlf > 0) {\n+\t\t\tauto_eol = 1;\n+\t\t\tif (crlf == CRLF_AUTO)\n+\t\t\t\tcrlf = CRLF_GUESS;\n+\t\t}\n \t}\n \n \tret |= apply_filter(path, src, len, dst, filter);\n@@ -593,7 +612,8 @@ 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-\tret |= crlf_to_git(path, src, len, dst, crlf, checksafe, auto_crlf);\n+\tret |= crlf_to_git(path, src, len, dst, crlf, checksafe,\n+\t\tchoose_eol_conversion(auto_eol));\n \tif (ret) {\n \t\tsrc = dst->buf;\n \t\tlen = dst->len;\n@@ -605,7 +625,7 @@ int convert_to_working_tree(const char *path, const char *src, size_t len, struc\n {\n \tstruct git_attr_check check[3];\n \tint crlf = CRLF_GUESS;\n-\tint ident = 0, ret = 0;\n+\tint ident = 0, ret = 0, auto_eol = 0;\n \tconst char *filter = NULL;\n \n \tsetup_convert_check(check);\n@@ -616,6 +636,11 @@ int convert_to_working_tree(const char *path, const char *src, size_t len, struc\n \t\tdrv = git_path_check_convert(path, check + 2);\n \t\tif (drv && drv->smudge)\n \t\t\tfilter = drv->smudge;\n+\t\tif (crlf > 0) {\n+\t\t\tauto_eol = 1;\n+\t\t\tif (crlf == CRLF_AUTO)\n+\t\t\t\tcrlf = CRLF_GUESS;\n+\t\t}\n \t}\n \n \tret |= ident_to_worktree(path, src, len, dst, ident);\n@@ -623,7 +648,8 @@ 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-\tret |= crlf_to_worktree(path, src, len, dst, crlf, auto_crlf);\n+\tret |= crlf_to_worktree(path, src, len, dst, crlf,\n+\t\tchoose_eol_conversion(auto_eol));\n \tif (ret) {\n \t\tsrc = dst->buf;\n \t\tlen = dst->len;\ndiff --git a/t/t0025-crlf-auto.sh b/t/t0025-crlf-auto.sh\nindex 367b459..e8e76f5 100755\n--- a/t/t0025-crlf-auto.sh\n+++ b/t/t0025-crlf-auto.sh\n@@ -60,7 +60,7 @@ test_expect_success 'no crlf=auto, explicit eolstyle=native causes no changes' '\n \ttest -z \"$onediff\" -a -z \"$twodiff\"\n '\n \n-test_expect_failure 'crlf=auto, eolStyle=crlf <=> autocrlf=true' '\n+test_expect_success 'crlf=auto, eolStyle=crlf <=> autocrlf=true' '\n \n \trm -f .gitattributes tmp one two &&\n \tgit config core.autocrlf false &&\n@@ -81,7 +81,7 @@ test_expect_failure 'crlf=auto, eolStyle=crlf <=> autocrlf=true' '\n \ttest -z \"$missing_cr\"\n '\n \n-test_expect_failure 'crlf=auto, eolStyle=lf <=> autocrlf=input' '\n+test_expect_success 'crlf=auto, eolStyle=lf <=> autocrlf=input' '\n \n \trm -f .gitattributes tmp one two &&\n \tgit config core.autocrlf false &&\n-- \n1.7.1.3.gb95c9\n"},{"id":"141268","messageId":"alpine.LFD.2.00.1005081455450.3711@i5.linux-foundation.org","threadId":"23749","inReplyTo":"c8ef28b72709013f17e093954a0f4e2ad1fb9652.1273352819.git.eyvind.bernhardsen@gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-08T21:57:24Z","receivedAt":"2010-05-08T21:57:24Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 8 May 2010, Eyvind Bernhardsen wrote:\n>\n> Introduce a new configuration variable, \"core.eolStyle\", that allows the\n> user to set which line endings to use for end-of-line-normalized files\n> in the working directory. It defaults to \"native\", which means CRLF on\n> Windows and LF everywhere else.\n\nSo I at least agree with the semantics now, but I think that we really \nwould be better off just calling it \"core.crlf\". I don't _care_ whether \npeople think it's a bad name - much worse than a bad name is to use a name \nthat is not consistent. \n\nHaving two config variables named \"core.autocrlf\" and \"core.crlf\" at least \nis consistent. Having \"autocrlf\" and \"eolStyle\" is just messed up.\n\n\t\tLinus\n"},{"id":"141270","messageId":"E2A9C4D2-010F-44B2-BF6A-627DE8B72FB5@gmail.com","threadId":"23749","inReplyTo":"alpine.LFD.2.00.1005081455450.3711@i5.linux-foundation.org","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-08T22:17:24Z","receivedAt":"2010-05-08T22:17:24Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 8. mai 2010, at 23.57, Linus Torvalds wrote:\n\n> Having two config variables named \"core.autocrlf\" and \"core.crlf\" at \n> least\n> is consistent. Having \"autocrlf\" and \"eolStyle\" is just messed up.\n\nI see your point, but \"crlf=lf\" makes no sense and \"crlf=input\" is \nhideous. It's bad enough that autocrlf uses \"true\" and \"input\"; this \nis a chance to reduce the insanity, not perpetuate it.\n\nI'll try to think of a better name.\n-- \nEyvind\n"},{"id":"141272","messageId":"BFFD3CAC-E7D9-49D8-9B67-C3F5157646F3@gmail.com","threadId":"23749","inReplyTo":"E2A9C4D2-010F-44B2-BF6A-627DE8B72FB5@gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-08T22:53:17Z","receivedAt":"2010-05-08T22:53:17Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 9. mai 2010, at 00.17, Eyvind Bernhardsen wrote:\n\n> I'll try to think of a better name.\n\nHeh. How about \"localcrlf={true,false,native}\"?\n\nIt breaks down a bit if we ever decide to support old-school-Mac-style \nCR line endings, but at that point you're approaching the borders of \nmadness anyway.\n-- \nEyvind\n"},{"id":"141273","messageId":"alpine.LFD.2.00.1005081600490.3711@i5.linux-foundation.org","threadId":"23749","inReplyTo":"BFFD3CAC-E7D9-49D8-9B67-C3F5157646F3@gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-08T23:08:20Z","receivedAt":"2010-05-08T23:08:20Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 9 May 2010, Eyvind Bernhardsen wrote:\n> \n> Heh. How about \"localcrlf={true,false,native}\"?\n\nI really don't understand that. What would it even mean?\n\nAn you _do_ realize that like it or not, we already have \"crlf=input\" as \nthe syntax in our .gitattributes files? So that exact syntax already \nexists in one place.\n\nAs mentioned, I really can understand people not liking the name, but we \nalready _have_ that name, and that syntax. I think it makes more sense to \ntry to have a unified syntax than have two different strings for the same \nthing.\n\nSo I think we'd be better off with good documentation with a couple of \nreal examples (and easily findable), so that the naming is at least \nsomething people can look up and see the semantics for. The \"eol\" vs \n\"crlf\" thing is just bike shedding, and we already ended up with \"crlf\". \nIn contrast, making docs understandable is more than bikeshedding.\n\n\t\t\tLinus\n"},{"id":"141294","messageId":"20100509070043.GB14069@dpotapov.dyndns.org","threadId":"23749","inReplyTo":"BFFD3CAC-E7D9-49D8-9B67-C3F5157646F3@gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-05-09T07:00:43Z","receivedAt":"2010-05-09T07:00:43Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, May 09, 2010 at 12:53:17AM +0200, Eyvind Bernhardsen wrote:\n> On 9. mai 2010, at 00.17, Eyvind Bernhardsen\n> wrote:\n> \n> >I'll try to think of a better name.\n> \n> Heh. How about \"localcrlf={true,false,native}\"?\n\nIMHO, the 'local' prefix certainly does not improve anything. Also,\nI would rather call default as \"default\" instead of \"native\". So,\nwhy not use \"core.crlf={true, false, default}\"?\n\nThough crlf is not my preferable name, I think consistency is important,\nand we should use the same name here as in git attributes.\n\n\nDmitry\n"},{"id":"141295","messageId":"o2h600158c31005090030uba3686e3v8bfe0be02bf2283d@mail.gmail.com","threadId":"23749","inReplyTo":"20100509070043.GB14069@dpotapov.dyndns.org","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"hasen j","fromEmail":"hasan.aljudy@gmail.com","sentAt":"2010-05-09T07:30:10Z","receivedAt":"2010-05-09T07:30:10Z","isPatch":true,"sender":{"key":"hasan.aljudy@gmail.com","avatar":"https://gravatar.com/avatar/47314b4bfcc6ba6685a811d9697fe60e90602acec0e24b9bf48bd0a97307f7c2?d=mp&s=160"},"body":"On 9 May 2010 01:00, Dmitry Potapov wrote:\n> [...] Also,\n> I would rather call default as \"default\" instead of \"native\". So,\n> why not use \"core.crlf={true, false, default}\"?\n\ndefault and native have completely different connotations. default\nmakes me think \"one of true or false, which ever happens to be the\ndefault\". native is a better fit here.\n"},{"id":"141298","messageId":"A5422145-63E1-4AF4-9184-7A6D15E9C2B6@gmail.com","threadId":"23749","inReplyTo":"alpine.LFD.2.00.1005081600490.3711@i5.linux-foundation.org","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-09T08:13:10Z","receivedAt":"2010-05-09T08:13:10Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 9. mai 2010, at 01.08, Linus Torvalds wrote:\n\n> On Sun, 9 May 2010, Eyvind Bernhardsen wrote:\n>> \n>> Heh. How about \"localcrlf={true,false,native}\"?\n> \n> I really don't understand that. What would it even mean?\n\nSorry, I should have explained it. I chided you for \"crlf=input\" being crazy, but then I realized that \"crlf=true\" really isn't too bad a config variable for saying that you want CRLFs. Just \"crlf\" seems a bit obscure still, so I came up with \"localcrlf\": if it's \"true\" it means you want CRLFs locally (in your working directory), if it's \"false\" you want LFs.\n\nIt helps to think about the situations where you're likely to change this. If you're on Linux but you want CRLFs in your working directory, set \"localcrlf=true\". If you're on Windows but don't want CRLFs, \"localcrlf=false\". Thinking about it, \"input\" could be an alias for \"false\", which would make it _exactly_ what you suggested except for a slight clarification in the name.\n\n> An you _do_ realize that like it or not, we already have \"crlf=input\" as \n> the syntax in our .gitattributes files? So that exact syntax already \n> exists in one place.\n\nI'm sorry. Are you the same Linus Torvalds who wrote this:\n\n> Btw, since we're discussing this, I do think that our current \"crlf=input\" \n> syntax for .gitattributes is pretty dubious.\n\n? I agree with that sentiment. \"crlf=input\" is silly; if you have a file that always has to be LF no matter what, just set it to \"-crlf\" and make sure you don't accidentally introduce any CRs. That is what you have to do for a file that always has to be CRLF, after all. As always, I'm not suggesting getting rid of \"crlf=input\"; I would keep it for backwards compatibility, but not emphasize it in the documentation.\n\n> As mentioned, I really can understand people not liking the name, but we \n> already _have_ that name, and that syntax. I think it makes more sense to \n> try to have a unified syntax than have two different strings for the same \n> thing.\n\nI agree with this! I just don't agree that the unified syntax should be married to the old, poor syntax, and \"crlf=input\" is a straw man. It's both ugly and unnecessary.\n\n> So I think we'd be better off with good documentation with a couple of \n> real examples (and easily findable), so that the naming is at least \n> something people can look up and see the semantics for. The \"eol\" vs \n> \"crlf\" thing is just bike shedding, and we already ended up with \"crlf\". \n> In contrast, making docs understandable is more than bikeshedding.\n\nMaking the docs understandable is important. I have changed the docs, and I will keep trying to improve them. But making the configuration understandable is _also_ important! It's not just the colour of the bike shed, it's how it _works_. This discussion is not a waste of time.\n\nBut if you insist, here's how it looks to me: I'm the one trying to build a new bike shed from the parts of the grotty one that nobody really likes to use, and you're the one saying I need to paint it in the same 70s brown-and-mustard colour scheme as the old one.\n\nThe frustrating thing is that you're also coming up with some interesting colour combinations elsewhere, but you seem resigned to the idea that we're stuck with the ugliness. I don't think we are.\n-- \nEyvind\n"},{"id":"141300","messageId":"B840F421-1037-4628-99FA-3A1F2A9A9DC3@gmail.com","threadId":"23749","inReplyTo":"20100509070043.GB14069@dpotapov.dyndns.org","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-09T08:34:23Z","receivedAt":"2010-05-09T08:34:23Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 9. mai 2010, at 09.00, Dmitry Potapov wrote:\n\n> On Sun, May 09, 2010 at 12:53:17AM +0200, Eyvind Bernhardsen wrote:\n>> On 9. mai 2010, at 00.17, Eyvind Bernhardsen\n>> wrote:\n>> \n>>> I'll try to think of a better name.\n>> \n>> Heh. How about \"localcrlf={true,false,native}\"?\n> \n> IMHO, the 'local' prefix certainly does not improve anything. Also,\n> I would rather call default as \"default\" instead of \"native\". So,\n> why not use \"core.crlf={true, false, default}\"?\n> \n> Though crlf is not my preferable name, I think consistency is important,\n> and we should use the same name here as in git attributes.\n\nBut the attribute does something different! The attribute turns eol conversion on and off, the configuration variable decides which line endings to use when conversion is on. They should be related, but making them identical doesn't make any kind of sense.\n\nTo be consistent, I would expect a variable called \"core.crlf\" to do the same thing as the attribute, so \"core.crlf=auto\" would replace \"core.autocrlf={true,input}\", allowing you to turn on line ending conversion without having to modify the repository.\n\nIf we added this consistently named \"core.crlf\", we'd still need a separate config variable to decide between LFs and CRLFs in the working directory, so what should that variable be called?\n\n\"localcrlf\" at least conveys the idea that this is a local setting, so it's not too much of a stretch to guess that it controls the working directory.\n-- \nEyvind\n"},{"id":"141303","messageId":"20100509092123.GA18774@pvv.org","threadId":"23749","inReplyTo":"BFFD3CAC-E7D9-49D8-9B67-C3F5157646F3@gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2010-05-09T09:21:25Z","receivedAt":"2010-05-09T09:21:25Z","isPatch":true,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Sun, May 09, 2010 at 12:53:17AM +0200, Eyvind Bernhardsen wrote:\n> On 9. mai 2010, at 00.17, Eyvind Bernhardsen \n> wrote:\n>\n>> I'll try to think of a better name.\n>\n> Heh. How about \"localcrlf={true,false,native}\"?\n>\n> It breaks down a bit if we ever decide to support old-school-Mac-style \n> CR line endings, but at that point you're approaching the borders of \n> madness anyway.\n\nIt seems that autocrlf is currently so troublesome that most people end up\ndisabling it, and handling it in other ways (we certainly do).\n\nInstead of keeping the names and trying to graft on something that is\nalmost backwards compatible, and forever live with names that we agree\nare bad, what about:\n\nDeprecate core.autocrlf and the crlf attribute.\n\nMake these instead:\n\nConfigs:\ncore.eol = lf, crlf, native [default=native]\ncore.eolconversion = true, false, auto [default=unset]\n\nAttribute:\neolconversion = true, false, auto [default=core.eolconversion]\n\n- Finn Arne\n"},{"id":"141305","messageId":"CD080D38-811C-4BBF-A5CB-6B613555FE72@gmail.com","threadId":"23749","inReplyTo":"20100509070043.GB14069@dpotapov.dyndns.org","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-09T10:42:17Z","receivedAt":"2010-05-09T10:42:17Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"I guess I should nail my flag to the mast: Here's what I would have done, with the benefit of plenty of hindsight, had we not had core.autocrlf, and also what I think we should do to approach that ideal.\n\nPlease don't get hung up too much on the names, they were chosen to not match anything suggested so far so that I can refer back to them unambiguously.\n\nMy user interface would have been:\n\n- an attribute \"eolconv\" that enables or disables line ending conversion\n- a config variable \"core.eolconv\" that sets \"eolconv\" for all files where it is unset\n- a config variable \"core.localeol\" that decides whether LF or CRLF is preferred\n\nThis provides the means to enable normalization on a per-project (\"eolconv\") or per-repository (\"core.eolconv\") basis, and allows the user to override the platform native line ending when normalization is in effect.\n\n\nNow, how does that compare to Git's current implementation of autocrlf?\n\n- The config variable \"core.autocrlf\" enables or disables line ending conversion and decides if conversion occurs in \"both\" directions (\"autocrlf=true\") or just towards the repository (\"autocrlf=input\").\n\n- The attribute \"crlf\" allows the automatic detection of binary files to be overridden, and forcing one-way conversion even if \"core.autocrlf\" is true (\"crlf=input\"). It only has an effect when \"core.autocrlf\" is enabled.\n\nI think I've stated my case against these settings before, but just to be clear, I think the biggest problem is that there's no way to tell if a repository is normalized from the contents of the repository, and it's not safe to enable autocrlf if the repository isn't normalized.\n\nThe second biggest problem is that \"true\" and \"input\" are bad names for \"normalize and put CRLFs in my working directory\" and \"normalize and put LFs in my working directory\", respectively.\n\n\nSo how to progress from here?\n\nAs Junio observed, the \"crlf\" attribute can act just like my hypothetical \"eolconv\" if you squeeze its semantics a bit and add a new setting. Disregarding \"crlf=input\" makes it exactly equivalent to \"eolconv\". The name is a bit off, but it's not monstrous.\n\n\"core.localeol\" has no equivalent in the current implementation. Using \"core.autocrlf\" as a stand in would not work, since that setting is expected to actually enable normalization, so if we want a moral equivalent of \"eolconv\", we need a new setting. \"core.crlf\" has been suggested to match the \"crlf\" attribute, but that causes confusion: why doesn't setting \"core.crlf=auto\" mean the same thing as setting \"crlf=auto\" on all files? I think a new variable is needed.\n\n\"core.autocrlf\" is problematic because it mixes up two things: you use it to turn on normalization _and_ to decide which line endings you prefer, and to maintain backwards compatibility its semantics can't be changed too much. A new setting \"core.autocrlf=auto\" (meaning the same as \"eolconv=auto\" on all files where \"eolconv\" isn't explicitly set) is a possibility, if kind of ugly. Another alternative is to make \"core.autocrlf=true\" respect \"core.localeol\", but that would be a v1.8.0 kind of change.\n\n\nMy current thinking on how to change my series now runs along these lines:\n\n- keep the current \"crlf=auto\" change\n- rename \"core.eolStyle\" to \"core.localcrlf\"\n- add a \"core.crlf\" that sets the \"crlf\" attribute on paths where it isn't explicitly configured\n- keep \"core.autocrlf\" for backwards compatibility, but make \"core.autocrlf=input\" and \"core.autocrlf=true\" complain if they are in conflict with the other config settings.\n\n\n\nAn apology: I know I've said a lot of nasty things about autocrlf, but I haven't had to touch a thing about its implementation, which works very well. My only beef is with its user interface (which probably made sense when it was implemented); the reason I don't think I'm just whining about the colour of the bike shed is that a lot of other people trip over that interface, to the point where the standard recommendation is simply to disable the feature, and I'd like to make it both more functional and more understandable.\n\nIn short, I'm burning autocrlf to save it :)\n-- \nEyvind\n"},{"id":"141309","messageId":"AANLkTikRJ6Hl_fRNRZbxeNNgwv9UTm2fPrOKv4GbT0qJ@mail.gmail.com","threadId":"23749","inReplyTo":"CD080D38-811C-4BBF-A5CB-6B613555FE72@gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Robert Buck","fromEmail":"buck.robert.j@gmail.com","sentAt":"2010-05-09T11:14:12Z","receivedAt":"2010-05-09T11:14:12Z","isPatch":true,"sender":{"key":"buck.robert.j@gmail.com","avatar":"https://gravatar.com/avatar/1686742e8ac2595378aac67f26fd638ddaf494194f9af0cb6082c4a7eca1a366?d=mp&s=160"},"body":"> My user interface would have been:\n>\n> - an attribute \"eolconv\" that enables or disables line ending conversion\n> - a config variable \"core.eolconv\" that sets \"eolconv\" for all files where it is unset\n> - a config variable \"core.localeol\" that decides whether LF or CRLF is preferred\n>\n\n[...]\n\n> My current thinking on how to change my series now runs along these lines:\n>\n> - keep the current \"crlf=auto\" change\n> - rename \"core.eolStyle\" to \"core.localcrlf\"\n> - add a \"core.crlf\" that sets the \"crlf\" attribute on paths where it isn't explicitly configured\n> - keep \"core.autocrlf\" for backwards compatibility, but make \"core.autocrlf=input\" and \"core.autocrlf=true\" complain if they are in conflict with the other config settings.\n\nSo, the meanings of these would become...\n\ncore.crlf [ auto | input | false ] : 'auto' means to enable\nbidirectional normalization, and 'false' would mean do not\nnormalization, and 'input' would mean normalize on input only,\notherwise output lf. Is this true?\ncore.localcrlf [ crlf | lf ] : this is obvious, and use-friendly\n\nFor the above case have you considered using 'core.crlflocal' instead?\nUsability-wise the related properties start with the same name prefix.\n\n>From a usability standpoint, I personally prefer something similar to\nwhat you (see \"my user interface would have been\") specified, slight\nadjustment to the names only:\n\ncore.eolconv [ true | false ] - whether or not to turn on conversions\ncore.eoltype [ lf | crlf ] - by default what to convert to for text files\n\nI like this purely because, from the users standpoint, saying\nsomething like \"localcrlf crlf\" is strange; meaning the term \"crlf\" is\non both sides of the assignment. I do prefer \"eol... crlf\", where eol\nrefers to the applicability of the property and crlf is only one such\nvalue.\n"},{"id":"141316","messageId":"u2p76718491005091002v516429ddrf118c35f3312c3ab@mail.gmail.com","threadId":"23749","inReplyTo":"CD080D38-811C-4BBF-A5CB-6B613555FE72@gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-05-09T17:02:34Z","receivedAt":"2010-05-09T17:02:34Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Sun, May 9, 2010 at 6:42 AM, Eyvind Bernhardsen\n wrote:\n> I guess I should nail my flag to the mast: Here's what I would have done, with the benefit of plenty of hindsight, had we not had core.autocrlf, and also what I think we should do to approach that ideal.\n>\n> Please don't get hung up too much on the names, they were chosen to not match anything suggested so far so that I can refer back to them unambiguously.\n>\n> My user interface would have been:\n>\n> - an attribute \"eolconv\" that enables or disables line ending conversion\n> - a config variable \"core.eolconv\" that sets \"eolconv\" for all files where it is unset\n> - a config variable \"core.localeol\" that decides whether LF or CRLF is preferred\n>\n> This provides the means to enable normalization on a per-project (\"eolconv\") or per-repository (\"core.eolconv\") basis, and allows the user to override the platform native line ending when normalization is in effect.\n>\n> [...]\n>\n> My current thinking on how to change my series now runs along these lines:\n>\n> - keep the current \"crlf=auto\" change\n> - rename \"core.eolStyle\" to \"core.localcrlf\"\n> - add a \"core.crlf\" that sets the \"crlf\" attribute on paths where it isn't explicitly configured\n> - keep \"core.autocrlf\" for backwards compatibility, but make \"core.autocrlf=input\" and \"core.autocrlf=true\" complain if they are in conflict with the other config settings.\n\nBah. I think relegating the old names to \"deprecated, for\ncompatibility\" is absolutely the right thing to do. Is there a use\ncase where the existing crlf setup is preferable? If not, why not just\nmark them as deprecated in the documentation and say \"see ...\"\npointing to the new functionality and use the new names as you\nsuggest.\n\n$0.02. :-)\n\nj.\n"},{"id":"141319","messageId":"o2h76718491005091043x9d8249f1gf6f44a32287ced18@mail.gmail.com","threadId":"23749","inReplyTo":"u2p76718491005091002v516429ddrf118c35f3312c3ab@mail.gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-05-09T17:43:53Z","receivedAt":"2010-05-09T17:43:53Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"One more point, which I'm sure will be inflammatory. After all, it has\nnothing to do with anything, but let's look at how svn deals with EOL\nissues:\n\n1) A property for whether a file is binary or text\n2) A property for the EOL style which applies only to text files:\n\nhttp://svnbook.red-bean.com/en/1.5/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style\n\nAnd Mercurial's plan to deal with it:\n\nhttp://mercurial.selenic.com/wiki/EOLTranslationPlan\n\n:-)\n\nj.\n"},{"id":"141320","messageId":"7v632x9dfk.fsf@alter.siamese.dyndns.org","threadId":"23749","inReplyTo":"CD080D38-811C-4BBF-A5CB-6B613555FE72@gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-09T17:45:35Z","receivedAt":"2010-05-09T17:45:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eyvind Bernhardsen writes:\n\n> My user interface would have been:\n>\n> - an attribute \"eolconv\" that enables or disables line ending conversion\n> - a config variable \"core.eolconv\" that sets \"eolconv\" for all files where it is unset\n> - a config variable \"core.localeol\" that decides whether LF or CRLF is preferred\n\nI am puzzled about this second item; what is its type and what is its\npurpose? If it is to allow project-wide default to be specified, then\nisn't having \"* eolconv=true\" in .gitattributes a much better option and\nis already supported by the first item?\n"},{"id":"141321","messageId":"alpine.LFD.2.00.1005091046570.3711@i5.linux-foundation.org","threadId":"23749","inReplyTo":"A5422145-63E1-4AF4-9184-7A6D15E9C2B6@gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-09T18:11:08Z","receivedAt":"2010-05-09T18:11:08Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 9 May 2010, Eyvind Bernhardsen wrote:\n> \n> I'm sorry. Are you the same Linus Torvalds who wrote this:\n> \n> > Btw, since we're discussing this, I do think that our current \"crlf=input\" \n> > syntax for .gitattributes is pretty dubious.\n\nYes, it's dubious. But as with the kernel, we need to support backwards \ncompatibility for things that have reasonably been used (and \"input\" has).\n\nI really brought it up as an example of things that weren't necessarily \nall that well designed.\n\nThat said, it looks like people actually do want per-file line-ending \nsettings, ie not just a global \"I want CRLF vs LF\". So it looks like \ncrlf=input is actually useful in a .gitattributes files, if only because \nsome people seem to want to mix CRLF and just LF in the same repository.\n\nIt also sounds like people actually want to have the reverse (ie not just \n\"input\", but have a mode where LF may be the default, but then some \nparticular files must always be CRLF even if most files are normal text).\n\nSo I suspect we want to really have support for all four combinations \n_both_ in the .git/config file, _and_ in the .gitattributes file.\n\nThe four cases would be \"none\" (\"binary\" or \"-crlf\"), \"lf\" (\"input\" or \n\"crlf=input\"), \"system default\", and \"force crlf\".\n\nHonestly, I would personally have preferred to have just a repo-wide \"this \nis the line ending\". Not some path-specific endings like \"crlf=input\" in \nthe .gitattributes. But people do seem to want it.\n\n\t\t\tLinus\n"},{"id":"141322","messageId":"20100509181853.GA4676@pvv.org","threadId":"23749","inReplyTo":"7v632x9dfk.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2010-05-09T18:18:53Z","receivedAt":"2010-05-09T18:18:53Z","isPatch":true,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Sun, May 09, 2010 at 10:45:35AM -0700, Junio C Hamano wrote:\n> Eyvind Bernhardsen writes:\n> \n> > My user interface would have been:\n> >\n> > - an attribute \"eolconv\" that enables or disables line ending conversion\n> > - a config variable \"core.eolconv\" that sets \"eolconv\" for all files where it is unset\n> > - a config variable \"core.localeol\" that decides whether LF or CRLF is preferred\n> \n> I am puzzled about this second item; what is its type and what is its\n> purpose? If it is to allow project-wide default to be specified, then\n> isn't having \"* eolconv=true\" in .gitattributes a much better option and\n> is already supported by the first item?\n\nThe way I understood it core.eolconv has exactly the same possible\nvalues as the \"eolconv\" attribute, and serves as a default value for\n\"eolconv\" if it isn't set. This would (mostly, I guess) be for Windows\nusers who would like to check out a project that is primarily\ndeveloped on Unix and didn't bother to set any eolconv attributes, and\nstill get CRLF line endings. core.eolconv has some of the drawbacks\nof autocrlf, so shouldn't really be used if you can convince projects\nto add eolconv attributes instead.\n\nAre you thinking we could live completely without it? Most other\npopular vcs-systems have eol-conversion/normalisation on by default,\nwhile git has it disabled by default. The config variable can change\nthe default behaviour, but is isn't as helpful as it should have been\nperhaps.\n\nTo do a better job with old un-normalised repos, we could for each\nfile remember what their eol-style was (CR, LF, CRLF, mixed), and then\neven if doing output conversion on checkout, convert back to the same\neol style on commit. This would perhaps break down a bit for renames,\nbut would be lovely if it worked for merges for example...\n\n- Finn Arne\n"},{"id":"141326","messageId":"E6434515-5357-4FF4-8049-5E4FCE8B29E4@gmail.com","threadId":"23749","inReplyTo":"AANLkTikRJ6Hl_fRNRZbxeNNgwv9UTm2fPrOKv4GbT0qJ@mail.gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-09T18:59:04Z","receivedAt":"2010-05-09T18:59:04Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 9. mai 2010, at 13.14, Robert Buck wrote:\n\n> So, the meanings of these would become...\n> \n> core.crlf [ auto | input | false ] : 'auto' means to enable\n> bidirectional normalization, and 'false' would mean do not\n> normalization, and 'input' would mean normalize on input only,\n> otherwise output lf. Is this true?\n\nNo, \"auto\" means to enable normalization for files git doesn't identify as text files, \"true\" means to always normalize, and \"false\" means never normalize. I probably wouldn't implement \"input\" unless there was a lot of demand. The idea is to make it act exactly like the \"crlf\" attribute, even though \"core.crlf=true/false\" would probably be used very rarely... I'm having second thoughts, actually.\n\n> core.localcrlf [ crlf | lf ] : this is obvious, and use-friendly\n\nWell, yes. I was thinking \"true|false\" (ie \"I want crlf\" or \"I don't want crlf\"), but I'm having second thoughts about that, too.\n\n> For the above case have you considered using 'core.crlflocal' instead?\n> Usability-wise the related properties start with the same name prefix.\n\nI didn't think too much about the name, so a completely different name might be even better.\n\nBecause of this and my second thoughts, I'm going to wait a few days before I make any more changes to allow good ideas to appear and give them time to sink in.\n\n> From a usability standpoint, I personally prefer something similar to\n> what you (see \"my user interface would have been\") specified, slight\n> adjustment to the names only:\n> \n> core.eolconv [ true | false ] - whether or not to turn on conversions\n> core.eoltype [ lf | crlf ] - by default what to convert to for text files\n\nAgreed, but I think getting this feature included is more important than getting the user interface exactly right. A compromise between backwards compatibility and user friendliness is okay.\n\n> I like this purely because, from the users standpoint, saying\n> something like \"localcrlf crlf\" is strange; meaning the term \"crlf\" is\n> on both sides of the assignment. I do prefer \"eol... crlf\", where eol\n> refers to the applicability of the property and crlf is only one such\n> value.\n\nYes, my \"localcrlf\" would be true/false instead of crlf/lf. It's definitely a compromise :)\n-- \nEyvind\n"},{"id":"141328","messageId":"20100509200935.GA22563@pvv.org","threadId":"23749","inReplyTo":"CD080D38-811C-4BBF-A5CB-6B613555FE72@gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2010-05-09T20:09:37Z","receivedAt":"2010-05-09T20:09:37Z","isPatch":true,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Sun, May 09, 2010 at 12:42:17PM +0200, Eyvind Bernhardsen wrote:\n\n> I guess I should nail my flag to the mast: Here's what I would have\n> done, with the benefit of plenty of hindsight, had we not had\n> core.autocrlf, and also what I think we should do to approach that\n> ideal.\n> [...]\n\nAfter some meditation, I think the following:\n\nThe most important thing is how we can fix git on Windows to operate\nwell by default. This is what we really should try to fix.\n\nThe way git on Windows would work best, while at the same time cause\nthe minimum amount of damage, would IMHO be:\n\n- Convert LF-only text files to CRLF on checkout\n- Convert those same files (but only those!) back to LF on commit\n- Optionally: Convert new CRLF text files to LF on commit\n\nAnd all this should happen without setting any configuration, and not\nsetting any attributes.\n\nSo maybe, just maybe, we can make everything sufficiently good by\nrepairing \"core.autocrlf = {input,true}\" so that git will not convert\na CRLF already in the repo. This would make autocrlf = true a safe\ndefault value (and probably input too, but you'd have to \"do\nsomething\" to get a new text file with CRLF into the repo then).\n\nThen we go from a situation that didn't work, to a working situation,\nand break nothing that used to work. You no longer have to normalise\nyour repos to work from Windows.\n\n- Finn Arne\n"},{"id":"141331","messageId":"06EEFAAE-31E7-4DAD-9FD3-D9809B16BCD9@gmail.com","threadId":"23749","inReplyTo":"alpine.LFD.2.00.1005091046570.3711@i5.linux-foundation.org","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-09T20:11:01Z","receivedAt":"2010-05-09T20:11:01Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 9. mai 2010, at 20.11, Linus Torvalds wrote:\n\n> On Sun, 9 May 2010, Eyvind Bernhardsen wrote:\n>> \n>> I'm sorry. Are you the same Linus Torvalds who wrote this:\n>> \n>>> Btw, since we're discussing this, I do think that our current \"crlf=input\" \n>>> syntax for .gitattributes is pretty dubious.\n> \n> Yes, it's dubious. But as with the kernel, we need to support backwards \n> compatibility for things that have reasonably been used (and \"input\" has).\n\nOh, absolutely. I'm not suggesting removing support for it, I just don't think it's a good reason to keep the old naming alive.\n\n> I really brought it up as an example of things that weren't necessarily \n> all that well designed.\n> \n> That said, it looks like people actually do want per-file line-ending \n> settings, ie not just a global \"I want CRLF vs LF\". So it looks like \n> crlf=input is actually useful in a .gitattributes files, if only because \n> some people seem to want to mix CRLF and just LF in the same repository.\n> \n> It also sounds like people actually want to have the reverse (ie not just \n> \"input\", but have a mode where LF may be the default, but then some \n> particular files must always be CRLF even if most files are normal text).\n\nMy plan was to \"support\" that by disabling conversion for those files; git wouldn't enforce the line endings, but at least it wouldn't break them.\n\nI guess there's no reason not to have the option to enforce in there if there is a huge demand for that.\n\n> So I suspect we want to really have support for all four combinations \n> _both_ in the .git/config file, _and_ in the .gitattributes file.\n> \n> The four cases would be \"none\" (\"binary\" or \"-crlf\"), \"lf\" (\"input\" or \n> \"crlf=input\"), \"system default\", and \"force crlf\".\n\nWell, \"crlf=crlf\" and \"crlf=lf\" would look silly, but no more than I could live with. .gitconfig is already covered in my series.\n-- \nEyvind\n"},{"id":"141332","messageId":"2AC4CFCB-F715-46B1-9F62-0ED190281A5F@gmail.com","threadId":"23749","inReplyTo":"7v632x9dfk.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-09T20:25:39Z","receivedAt":"2010-05-09T20:25:39Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 9. mai 2010, at 19.45, Junio C Hamano wrote:\n\n> Eyvind Bernhardsen writes:\n> \n>> My user interface would have been:\n>> \n>> - an attribute \"eolconv\" that enables or disables line ending conversion\n>> - a config variable \"core.eolconv\" that sets \"eolconv\" for all files where it is unset\n>> - a config variable \"core.localeol\" that decides whether LF or CRLF is preferred\n> \n> I am puzzled about this second item; what is its type and what is its\n> purpose? If it is to allow project-wide default to be specified, then\n> isn't having \"* eolconv=true\" in .gitattributes a much better option and\n> is already supported by the first item?\n\nYes, but if the repository maintainers don't want to make that change (for whatever reason), it might be nice for the user to be able to enable normalization locally. It would be a boolean, and setting it would mean the equivalent of \"crlf=auto\" on all files where \"crlf\" is not explicitly set.\n-- \nEyvind\n"},{"id":"141333","messageId":"AANLkTikg7Tc6zJvfBELBQoeAxebFenNLivEs92j8c83D@mail.gmail.com","threadId":"23749","inReplyTo":"E6434515-5357-4FF4-8049-5E4FCE8B29E4@gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Robert Buck","fromEmail":"buck.robert.j@gmail.com","sentAt":"2010-05-09T20:46:37Z","receivedAt":"2010-05-09T20:46:37Z","isPatch":true,"sender":{"key":"buck.robert.j@gmail.com","avatar":"https://gravatar.com/avatar/1686742e8ac2595378aac67f26fd638ddaf494194f9af0cb6082c4a7eca1a366?d=mp&s=160"},"body":"> On 9. mai 2010, at 13.14, Robert Buck wrote:\n>\n>> So, the meanings of these would become...\n>>\n>> core.crlf [ auto | input | false ] : 'auto' means to enable\n>> bidirectional normalization, and 'false' would mean do not\n>> normalization, and 'input' would mean normalize on input only,\n>> otherwise output lf. Is this true?\n>\n> No, \"auto\" means to enable normalization for files git doesn't identify as text files, \"true\" means to always normalize, and \"false\" means never normalize.\n\nI probably missed something. The part that confuses me in this\nstatement is that you said \"for files git doesn't identify as text\nfiles\". The convert.c source is the heart of this, and if a file is\nnot identified as text it is presumed to be binary. The statement made\nseems to imply you'd auto-convert PDF files? I know you did not mean\nthat, but it could have been read that way.\n\nWhat specifically happens in the three modes? Would it be precise to\nsay the following?\n\n \"Files subject to EOL conversion are those that are explicitly\nidentified through attributes to be text files, or those\nalgorithmically determined to be text files which happen to not bear\nthe \"text\" file attribute. Otherwise the default value, \"false\",\napplies and no EOL conversions occur.\"\n\n-Bob\n"},{"id":"141335","messageId":"7vwrvc91r8.fsf@alter.siamese.dyndns.org","threadId":"23749","inReplyTo":"20100509181853.GA4676@pvv.org","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-09T21:57:47Z","receivedAt":"2010-05-09T21:57:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Finn Arne Gangstad writes:\n\n> Are you thinking we could live completely without it?\n\nYes, and your description makes it sound like it doesn't buy us anything\nthat an entry '* eolconv=true\" in .git/info/attributes wouldn't.\n"},{"id":"141344","messageId":"91F47297-A1B5-4AE5-8835-E3A8E452FB8A@gmail.com","threadId":"23749","inReplyTo":"AANLkTikg7Tc6zJvfBELBQoeAxebFenNLivEs92j8c83D@mail.gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-10T04:33:24Z","receivedAt":"2010-05-10T04:33:24Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 9. mai 2010, at 22.46, Robert Buck wrote:\n\n>> No, \"auto\" means to enable normalization for files git doesn't \n>> identify as text files, \"true\" means to always normalize, and \n>> \"false\" means never normalize.\n>\n> I probably missed something. The part that confuses me in this\n> statement is that you said \"for files git doesn't identify as text\n> files\". The convert.c source is the heart of this, and if a file is\n> not identified as text it is presumed to be binary. The statement made\n> seems to imply you'd auto-convert PDF files? I know you did not mean\n> that, but it could have been read that way.\n\nDoh! I meant to write \"files git _does_ identify as text files\". Sorry \nfor the confusion.\n\n> What specifically happens in the three modes? Would it be precise to\n> say the following?\n>\n> \"Files subject to EOL conversion are those that are explicitly\n> identified through attributes to be text files, or those\n> algorithmically determined to be text files which happen to not bear\n> the \"text\" file attribute. Otherwise the default value, \"false\",\n> applies and no EOL conversions occur.\"\n\nVery close, but my thinko threw you off. The \"algorithmic \ndetermination\" of text files is only performed when crlf=auto, either \nby the attribute or the config variable being set that way.\n\nThe point of the \"core.crlf\" config variable would be to provide a \ndefault value for the \"crlf\" attribute.\n-- \n>\nEyvind\n"},{"id":"141345","messageId":"3AD575F0-D29E-4E2B-96EA-862C167F7FDC@gmail.com","threadId":"23749","inReplyTo":"7vwrvc91r8.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-10T05:14:21Z","receivedAt":"2010-05-10T05:14:21Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 9. mai 2010, at 23.57, Junio C Hamano wrote:\n\n> Finn Arne Gangstad writes:\n> \n>> Are you thinking we could live completely without it?\n> \n> Yes, and your description makes it sound like it doesn't buy us anything\n> that an entry '* eolconv=true\" in .git/info/attributes wouldn't.\n\nI'm not sure I even knew about .git/info/attributes, but it makes a lot of sense. The config variable would allow a user to turn on normalization globally, I guess, but that's probably not worth it.\n-- \nEyvind\n"},{"id":"141352","messageId":"20100510071607.GC14069@dpotapov.dyndns.org","threadId":"23749","inReplyTo":"o2h600158c31005090030uba3686e3v8bfe0be02bf2283d@mail.gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-05-10T07:16:07Z","receivedAt":"2010-05-10T07:16:07Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, May 09, 2010 at 01:30:10AM -0600, hasen j wrote:\n> On 9 May 2010 01:00, Dmitry Potapov wrote:\n> > [...] Also,\n> > I would rather call default as \"default\" instead of \"native\". So,\n> > why not use \"core.crlf={true, false, default}\"?\n> \n> default and native have completely different connotations. default\n> makes me think \"one of true or false, which ever happens to be the\n> default\". native is a better fit here.\n\nbut indeed core.crlf=default means that it is either true or false\nwhatever happened the system default, as well as \"default\" means the\nsame as if it would be if it is not specified at all. If it were\neol=native, it would be okay, but crlf=native looks strange to me.\n\n\nDmitry\n"},{"id":"141355","messageId":"20100510081358.GD14069@dpotapov.dyndns.org","threadId":"23749","inReplyTo":"20100509200935.GA22563@pvv.org","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-05-10T08:13:58Z","receivedAt":"2010-05-10T08:13:58Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, May 09, 2010 at 10:09:37PM +0200, Finn Arne Gangstad wrote:\n> \n> So maybe, just maybe, we can make everything sufficiently good by\n> repairing \"core.autocrlf = {input,true}\" so that git will not convert\n> a CRLF already in the repo. This would make autocrlf = true a safe\n> default value (and probably input too, but you'd have to \"do\n> something\" to get a new text file with CRLF into the repo then).\n\nFirst of autocrlf is safe as it is implemented now. Second, to do\nsomething to get a new with CRLF into the repo is really stupid.\nThe whole point of autocrlf is being automatic and do not have the\nuser to worry about CRLF when he adds a new file.\n\nThe only real problem I am aware of is that some repository are not\ncompatible with autocrlf conversion, because they store text files\nwith different endings and do not have appropriate .gitatributes to\ndescrible what text files should and should not be converted. So, each\nuser has to disable autocrlf in them manually and then re-checkout all\nfiles using (rm -rf * && git checkout -f), which is confusing for many\nusers. In fact, you do not have to disable autocrlf, you can add a few\nlines to .git/info/attributes to make it autocrlf compatible, but again\nmany users even not aware about this file, let alone what needs to be\nadded. Further, the problem amplified by the fact that you have to do\nthe same procedure every time when you do cloning, and though cloning\nis not most common operation, it happens often enough to annoy many\nusers.\n\nI believe that the right solution is to be able to enable autocrlf but\nonly for those repositories that are marked as autocrlf compatible by\nupstream.\n\n\nDmitry\n"},{"id":"141382","messageId":"20100510111438.GA15206@pvv.org","threadId":"23749","inReplyTo":"20100510081358.GD14069@dpotapov.dyndns.org","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2010-05-10T11:14:39Z","receivedAt":"2010-05-10T11:14:39Z","isPatch":true,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Mon, May 10, 2010 at 12:13:58PM +0400, Dmitry Potapov wrote:\n> \n> First of autocrlf is safe as it is implemented now.\n\nNo, it isn't. autocrlf as it is implemented now is destructive for any\nfile that contains CRLF in the repo (it also gives dirty files after\ncheckout and so on).\n\n> I believe that the right solution is to be able to enable autocrlf but\n> only for those repositories that are marked as autocrlf compatible by\n> upstream.\n\nYes absolutely. But how do you tell autocrlf that the repository is\ncompatible with it? This is what is causing all the problems.\n\nNow, I propose to change autocrlf in such a way that it will work as\nbefore for all repositories that are \"compatible with it\", but _also_\nso that it works reasonably with those that aren't.\n\n- Finn Arne\n"},{"id":"141387","messageId":"AANLkTilDiP_5Q9HrssB0lyf-jsE8LAF2ULGwEMO4BzdQ@mail.gmail.com","threadId":"23749","inReplyTo":"91F47297-A1B5-4AE5-8835-E3A8E452FB8A@gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Robert Buck","fromEmail":"buck.robert.j@gmail.com","sentAt":"2010-05-10T11:43:55Z","receivedAt":"2010-05-10T11:43:55Z","isPatch":true,"sender":{"key":"buck.robert.j@gmail.com","avatar":"https://gravatar.com/avatar/1686742e8ac2595378aac67f26fd638ddaf494194f9af0cb6082c4a7eca1a366?d=mp&s=160"},"body":"On Mon, May 10, 2010 at 12:33 AM, Eyvind Bernhardsen\n wrote:\n> On 9. mai 2010, at 22.46, Robert Buck wrote:\n>\n>>> No, \"auto\" means to enable normalization for files git doesn't identify\n>>> as text files, \"true\" means to always normalize, and \"false\" means never\n>>> normalize.\n>>\n>> I probably missed something. The part that confuses me in this\n>> statement is that you said \"for files git doesn't identify as text\n>> files\". The convert.c source is the heart of this, and if a file is\n>> not identified as text it is presumed to be binary. The statement made\n>> seems to imply you'd auto-convert PDF files? I know you did not mean\n>> that, but it could have been read that way.\n>\n> Doh! I meant to write \"files git _does_ identify as text files\". Sorry for\n> the confusion.\n>\n>> What specifically happens in the three modes? Would it be precise to\n>> say the following?\n>>\n>>   \"Files subject to EOL conversion are those that are explicitly\n>> identified through attributes to be text files, or those\n>> algorithmically determined to be text files which happen to not bear\n>> the \"text\" file attribute. Otherwise the default value, \"false\",\n>> applies and no EOL conversions occur.\"\n>\n> Very close, but my thinko threw you off. The \"algorithmic determination\" of\n> text files is only performed when crlf=auto, either by the attribute or the\n> config variable being set that way.\n>\n> The point of the \"core.crlf\" config variable would be to provide a default\n> value for the \"crlf\" attribute.\n\nOkay, so that makes sense...\n\n \"Files subject to EOL conversion are those that are explicitly\n identified through attributes to be text files, or provided core.crlf is\nset to auto, those files algorithmically determined to be text files\nwhich happen to not bear\n the \"text\" file attribute. Otherwise the default value, \"false\",\napplies and no EOL conversions occur. When conversions occur the EOL\ncharacter changes from the internal LF format to the format specified\nby core.crlftype.\"\n\nThis would work out well if file type maps were ever introduced. Type\nmaps would not short circuit the explicit attributes identified by the\nfirst clause, then for those files without attributes you'd check the\nfile-type maps, then fall back to the algorithmic if auto is enabled.\n\nI like that.\n"},{"id":"141397","messageId":"AANLkTikYUypxH5WhCOMby_zpHsnHEFyix5MGpD96FVWD@mail.gmail.com","threadId":"23749","inReplyTo":"AANLkTilDiP_5Q9HrssB0lyf-jsE8LAF2ULGwEMO4BzdQ@mail.gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Robert Buck","fromEmail":"buck.robert.j@gmail.com","sentAt":"2010-05-10T13:25:11Z","receivedAt":"2010-05-10T13:25:11Z","isPatch":true,"sender":{"key":"buck.robert.j@gmail.com","avatar":"https://gravatar.com/avatar/1686742e8ac2595378aac67f26fd638ddaf494194f9af0cb6082c4a7eca1a366?d=mp&s=160"},"body":"Today I am writing up some documentation related to Git use at the\ncompany, and planning to check in all the data from Git vs Hg testing,\nand all on-boarding/first-day documentation related to Git use. So\nwithin the directory containing all these files I init-ed the\nrepository and got this when I attempted to add multiple files. Mind\nyou, this is on Linux!\n\n \"warning: LF will be replaced by CRLF\"\n\nThis _really_ of scares me being that this was on Linux. Is this one\nof the problem spots that the topic of this thread attempts to\nresolve?\n\nBob\n"},{"id":"141398","messageId":"20100510134655.GE14069@dpotapov.dyndns.org","threadId":"23749","inReplyTo":"20100510111438.GA15206@pvv.org","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-05-10T13:46:55Z","receivedAt":"2010-05-10T13:46:55Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, May 10, 2010 at 01:14:39PM +0200, Finn Arne Gangstad wrote:\n> On Mon, May 10, 2010 at 12:13:58PM +0400, Dmitry Potapov wrote:\n> > \n> > First of autocrlf is safe as it is implemented now.\n> \n> No, it isn't. autocrlf as it is implemented now is destructive for any\n> file that contains CRLF in the repo (it also gives dirty files after\n> checkout and so on).\n\nIt may give dirty files in your working tree, but you do not lose any\ninformation silently (as it happened with CVS), so it is safe in this\nrespect.\n\n> \n> > I believe that the right solution is to be able to enable autocrlf but\n> > only for those repositories that are marked as autocrlf compatible by\n> > upstream.\n> \n> Yes absolutely. But how do you tell autocrlf that the repository is\n> compatible with it? This is what is causing all the problems.\n\nI suppose the original design assumption of autocrlf was that nearly all\nrepo should be compatible, because autocrlf is very good on detecting\ntext files. The problem with that is that many people want to store text\nfiles with different endings, but they cannot be bothered to add a few\nlines to .gitattributes. And while it is possible now to disable autocrlf\nin any repo just by adding one line to .gitattributes:\n* -crlf\nbut it is impossible to say the opposite.\n\nSo, I believe we should add \"crlf=auto\" as Eyvind proposed, as well as\nto do eol conversion for files marked as \"crlf\" even if autocrlf is not\nset as Linus suggested earlier. (Certainly, \"eolconv\" would be a better\nname than \"crlf\", but maybe it is not the right time to replace it right\nnow).\n\n> \n> Now, I propose to change autocrlf in such a way that it will work as\n> before for all repositories that are \"compatible with it\", but _also_\n> so that it works reasonably with those that aren't.\n\nNo, you proposed something different. You said that conversion for new\nfiles would become optional. I don't know what exactly you mean by\noptional, but it sounds incompatible with what we have now. In fact,\nwhat I really like about autocrlf is that I do not need to think about\nwhen I add a new file.\n\nMoreover, you said \"Convert LF-only text files to CRLF on checkout\",\nwhich raises two questions:\n\n1. Where should information about what file was and what was not\nconverted be stored? (Storying it in the index can make the index\nincompatible with old versions of Git).\n\n2. How does it solve the problem with new files? (Just saying that\nthis conversation will be optional, does not it mean that it will be\nright for this particular repo.)\n\n\n\nDmitry\n"},{"id":"141400","messageId":"20100510140321.GF14069@dpotapov.dyndns.org","threadId":"23749","inReplyTo":"AANLkTikYUypxH5WhCOMby_zpHsnHEFyix5MGpD96FVWD@mail.gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-05-10T14:03:21Z","receivedAt":"2010-05-10T14:03:21Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, May 10, 2010 at 09:25:11AM -0400, Robert Buck wrote:\n> Today I am writing up some documentation related to Git use at the\n> company, and planning to check in all the data from Git vs Hg testing,\n> and all on-boarding/first-day documentation related to Git use. So\n> within the directory containing all these files I init-ed the\n> repository and got this when I attempted to add multiple files. Mind\n> you, this is on Linux!\n> \n> \"warning: LF will be replaced by CRLF\"\n\nIt looks like you set core.autocrlf to true on Linux.\n\nThe problem is core.autocrlf says two things -- whether you want to\nenable automatic eol conversion for text files and whether you have CRLF\nfor text files. Only if the answer is \"yes\" to both then you should set\nit to true. In other words, you should never set it to true on Linux.\n\nYou may want use core.autocrlf=input on Linux to avoid text files being\naccidentally commit with a wrong encoding, when they were copied from\nWindows directly.\n\n> \n> This _really_ of scares me being that this was on Linux. Is this one\n> of the problem spots that the topic of this thread attempts to\n> resolve?\n\nYes, we want to have a separate setting, whihc will tell what is EOL on\nyour system, and it should have sensible default, i.e. LF on Linux and\nCRLF on Windows.\n\n\nDmitry\n"},{"id":"141426","messageId":"809F5FF0-B8C9-41A1-A862-3FABD4184A5C@gmail.com","threadId":"23749","inReplyTo":"u2p76718491005091002v516429ddrf118c35f3312c3ab@mail.gmail.com","subject":"Re: [PATCH/RFC v2 1/4] Add \"core.eolStyle\" variable to control end-of-line conversion","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-10T18:33:39Z","receivedAt":"2010-05-10T18:33:39Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 9. mai 2010, at 19.02, Jay Soffian wrote:\n\n> Bah. I think relegating the old names to \"deprecated, for\n> compatibility\" is absolutely the right thing to do. Is there a use\n> case where the existing crlf setup is preferable? If not, why not just\n> mark them as deprecated in the documentation and say \"see ...\"\n> pointing to the new functionality and use the new names as you\n> suggest.\n\nI don't know if it would get accepted, but I'll add a commit that does that to the next iteration :)\n-- \nEyvind\n"}]}