Torsten Bögershausen <tbo...@web.de> writes: > eol=lf or eol=crlf are the only useful settings. > Everything else is ignored because it does not make sense. > > See convert.c: > static enum eol git_path_check_eol()
That makes me wonder... The original reasoning behind the current behaviour that we ignore unknown values given to configuration variables and attributes is so that people can use the same file that has values that are understood by newer versions of Git with older versions of Git. You may be trying the eol=cleverLF setting introduced in Git version 47-prerelease by adding it to .git/info/attributes, and may have found it useful. But you may also have to use the same repository on another machine that you didn't install that future version of Git over the network filesystem. Barfing and not proceeding when we see unknown eol=cleverLF does not sound like a nice thing to do, which is why we just ignore and behave as if the setting was not there. Ideally, however, I think we should ignore an unknown setting as long as it does not matter (i.e. we do not come to the codepath that wants to know eol settings for the path, e.g. running "git log" to show only the commit log messages and the topology of the history), but we should error out when the unknown setting possibly matters (i.e. we do need the eol setting for the path in order to correctly convert the contents to end-user's liking). Thoughts (and patches ;-)? -- To unsubscribe from this list: send the line "unsubscribe git" in
