On 2015-06-22 18.11, Junio C Hamano wrote: > Torsten Bögershausen <tboegi@xxxxxx> 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 ;-)? In short: Good idea, patches follow within the next weeks/months -- 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