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

[Alex Stangl <alex@stangl.us>]

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.

Alex