Re: error: core.autocrlf=input conflicts with core.eol=crlf

["Torsten Bögershausen" <tboegi@web.de>]

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,