On 12/05/2014 09:10 AM, Torsten Bögershausen wrote: > On 05.12.14 06:42, Alex Stangl wrote: >> Hi, >> >> There seems to be problems with the checks in the git code for conflicts >> between config values of core.autocrlf and core.eol. Because the various >> config files are read in separate passes, and the conflict check happens >> on the fly, it creates a situation where the order of the config file >> entries matters. This seems like a bug or at least a POLA violation -- >> ordering of lines within a section of a config file is not usually >> significant. >> >> Example: User has core.autocrlf=input in his ~/.gitconfig. In his >> project-level .git/config he wants to set core.autocrlf=false and >> core.eol=crlf. If the core.autocrlf=false comes first, then all is >> well and no conflict is reported. If the core.eol=crlf line comes >> first, then at the time this line is getting parsed, core.autocrlf >> is still set at "input" from ~/.gitconfig, and execution aborts: >> >> error: core.autocrlf=input conflicts with core.eol=crlf >> >> It seems like the conflict check should be made at the end of the >> config file parsing, not on the fly. I was tempted to create a patch, >> however I am unfamilar with the codebase, and didn't understand all >> the places where the config file parsing is called, so I'm not sure >> of the ramifications of any proposed change. A benefit of the current >> approach is that it reports the line number where it aborted in the >> config file. Trying to retain this and at the same time defer the >> check until the end could get complicated. >> >> Besides interaction between multiple levels of config files, the >> same sort of ordering issue can arise in conjunction with command-line >> config overrides. >> >> Example: User has core.autocrlf=input in his project-level .git/config. >> This command works fine: >> $ git -c core.autocrlf=false -c core.eol=crlf status >> This command blows up with conflict error: >> $ git -c core.eol=crlf -c core.autocrlf=false status >> >> I tested with git versions 1.9.3 and 2.1.0. >> Yes, this is a bug, if someone has a patch: it is welcome. Or a test case showing the problem is welcome too. Beside that, I am working on a patch to remove this restriction completely. I think that it is a legal combination to have a .gitattributes file like this: *.txt text And then set core.autocrlf=input # to avoid CRLF in the repo for e.g. *.c files, and core.eol=crlf # to have *.txt in CRLF in the working tree Which means do not touch any files, -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html