{"thread":{"id":"38117","subject":"error: core.autocrlf=input conflicts with core.eol=crlf","startedAt":"2014-12-05T05:42:05Z","lastAt":"2014-12-05T16:33:58Z","messageCount":3,"participants":["Alex Stangl","Torsten Bögershausen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"253151","messageId":"20141205054205.GA71681@scout.stangl.us","threadId":"38117","inReplyTo":null,"subject":"error: core.autocrlf=input conflicts with core.eol=crlf","fromName":"Alex Stangl","fromEmail":"alex@stangl.us","sentAt":"2014-12-05T05:42:05Z","receivedAt":"2014-12-05T05:42:05Z","isPatch":false,"sender":{"key":"alex@stangl.us","avatar":null},"body":"Hi,\n\nThere seems to be problems with the checks in the git code for conflicts\nbetween config values of core.autocrlf and core.eol. Because the various\nconfig files are read in separate passes, and the conflict check happens\non the fly, it creates a situation where the order of the config file\nentries matters. This seems like a bug or at least a POLA violation --\nordering of lines within a section of a config file is not usually\nsignificant.\n\nExample: User has core.autocrlf=input in his ~/.gitconfig. In his\nproject-level .git/config he wants to set core.autocrlf=false and\ncore.eol=crlf. If the core.autocrlf=false comes first, then all is\nwell and no conflict is reported. If the core.eol=crlf line comes\nfirst, then at the time this line is getting parsed, core.autocrlf\nis still set at \"input\" from ~/.gitconfig, and execution aborts:\n\nerror: core.autocrlf=input conflicts with core.eol=crlf\n\nIt seems like the conflict check should be made at the end of the\nconfig file parsing, not on the fly. I was tempted to create a patch,\nhowever I am unfamilar with the codebase, and didn't understand all\nthe places where the config file parsing is called, so I'm not sure\nof the ramifications of any proposed change. A benefit of the current\napproach is that it reports the line number where it aborted in the\nconfig file. Trying to retain this and at the same time defer the\ncheck until the end could get complicated.\n\nBesides interaction between multiple levels of config files, the\nsame sort of ordering issue can arise in conjunction with command-line\nconfig overrides.\n\nExample: User has core.autocrlf=input in his project-level .git/config.\nThis command works fine:\n$ git -c core.autocrlf=false -c core.eol=crlf status\nThis command blows up with conflict error:\n$ git -c core.eol=crlf -c core.autocrlf=false status\n\nI tested with git versions 1.9.3 and 2.1.0.\n\nAlex\n"},{"id":"253167","messageId":"5481D587.2050103@web.de","threadId":"38117","inReplyTo":"54816863.90208@web.de","subject":"Re: error: core.autocrlf=input conflicts with core.eol=crlf","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2014-12-05T15:55:51Z","receivedAt":"2014-12-05T15:55:51Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 12/05/2014 09:10 AM, Torsten Bögershausen wrote:\n> On 05.12.14 06:42, Alex Stangl wrote:\n>> Hi,\n>>\n>> There seems to be problems with the checks in the git code for conflicts\n>> between config values of core.autocrlf and core.eol. Because the various\n>> config files are read in separate passes, and the conflict check happens\n>> on the fly, it creates a situation where the order of the config file\n>> entries matters. This seems like a bug or at least a POLA violation --\n>> ordering of lines within a section of a config file is not usually\n>> significant.\n>>\n>> Example: User has core.autocrlf=input in his ~/.gitconfig. In his\n>> project-level .git/config he wants to set core.autocrlf=false and\n>> core.eol=crlf. If the core.autocrlf=false comes first, then all is\n>> well and no conflict is reported. If the core.eol=crlf line comes\n>> first, then at the time this line is getting parsed, core.autocrlf\n>> is still set at \"input\" from ~/.gitconfig, and execution aborts:\n>>\n>> error: core.autocrlf=input conflicts with core.eol=crlf\n>>\n>> It seems like the conflict check should be made at the end of the\n>> config file parsing, not on the fly. I was tempted to create a patch,\n>> however I am unfamilar with the codebase, and didn't understand all\n>> the places where the config file parsing is called, so I'm not sure\n>> of the ramifications of any proposed change. A benefit of the current\n>> approach is that it reports the line number where it aborted in the\n>> config file. Trying to retain this and at the same time defer the\n>> check until the end could get complicated.\n>>\n>> Besides interaction between multiple levels of config files, the\n>> same sort of ordering issue can arise in conjunction with command-line\n>> config overrides.\n>>\n>> Example: User has core.autocrlf=input in his project-level .git/config.\n>> This command works fine:\n>> $ git -c core.autocrlf=false -c core.eol=crlf status\n>> This command blows up with conflict error:\n>> $ git -c core.eol=crlf -c core.autocrlf=false status\n>>\n>> I tested with git versions 1.9.3 and 2.1.0.\n>>\nYes, this is a bug, if someone has a patch: it is welcome.\nOr a test case showing the problem is welcome too.\n\nBeside that, I am working on a patch to remove this restriction completely.\nI think that it is a legal combination to have a .gitattributes file like this:\n\n*.txt text\n\nAnd then set\n\ncore.autocrlf=input # to avoid CRLF in the repo for e.g. *.c files,\nand core.eol=crlf # to have *.txt in CRLF in the working tree\n\n\n\nWhich means do not touch any files,\n"},{"id":"253168","messageId":"20141205163358.GA77231@scout.stangl.us","threadId":"38117","inReplyTo":"5481D587.2050103@web.de","subject":"Re: error: core.autocrlf=input conflicts with core.eol=crlf","fromName":"Alex Stangl","fromEmail":"alex@stangl.us","sentAt":"2014-12-05T16:33:58Z","receivedAt":"2014-12-05T16:33:58Z","isPatch":false,"sender":{"key":"alex@stangl.us","avatar":null},"body":"On Fri, Dec 05, 2014 at 04:55:51PM +0100, Torsten B?gershausen wrote:\n> On 12/05/2014 09:10 AM, Torsten B?gershausen wrote:\n> Or a test case showing the problem is welcome too.\n\nI mentioned some examples in my previous post. Here they are in\ncondensed form. They assume core.eol isn't set in your global config.\n\nThese work fine:\n$ mkdir -p /tmp/ex1_$$;cd /tmp/ex1_$$;git init;git config --global core.autocrlf input;git config core.autocrlf false;git config core.eol crlf;git status                                                                                                                                                                                                     \n$ mkdir -p /tmp/ex3_$$;cd /tmp/ex3_$$;git init;git config --global core.autocrlf input;git -c core.autocrlf=false -c core.eol=crlf status\n\nThese equivalents fail:\n$ mkdir -p /tmp/ex2_$$;cd /tmp/ex2_$$;git init;git config --global core.autocrlf input;git config core.eol crlf;git config core.autocrlf false;git status\n$ mkdir -p /tmp/ex4_$$;cd /tmp/ex4_$$;git init;git config --global core.autocrlf input;git -c core.eol=crlf -c core.autocrlf=false status\n\nAlex\n"}]}