The NATIVE_CRLF option in config.mak.uname defines whether the platform uses CRLF as a native EOL marker. This in particular defines how the core.eol=native git option setting is interpreted. This option defines which line endings are used when checking out files to the working area and native means use the native EOL style. Given that native is the default value for this option, this means that NATIVE_CRLF defines whether checked out files will have LF or CRLF by default (this only relates to "normalized" text files, i.e. files that git considers to be text and which use LF when stored in the repository database).
Currently, NATIVE_CRLF is only set on Windows, OS/2 doesn't set it. And I'm really not sure that we should set it on OS/2 as most of our repos and development tools come from the Linux world where LF is the native line separator. (and the majority of native OS/2 programs supports LN quite well). This ticket is to have a record on this topic. We may simply decide to close it later.
The NATIVE_CRLF option in config.mak.uname defines whether the platform uses CRLF as a native EOL marker. This in particular defines how the core.eol=native git option setting is interpreted. This option defines which line endings are used when checking out files to the working area and native means use the native EOL style. Given that native is the default value for this option, this means that NATIVE_CRLF defines whether checked out files will have LF or CRLF by default (this only relates to "normalized" text files, i.e. files that git considers to be text and which use LF when stored in the repository database).
Currently, NATIVE_CRLF is only set on Windows, OS/2 doesn't set it. And I'm really not sure that we should set it on OS/2 as most of our repos and development tools come from the Linux world where LF is the native line separator. (and the majority of native OS/2 programs supports LN quite well). This ticket is to have a record on this topic. We may simply decide to close it later.