Re: [PATCH 0/5] Abide by our own rules regarding line endings

From: Junio C Hamano <gitster@pobox.com>
Date: May 4, 2017, 05:19 UTC
Message-ID: <xmqqpofp9p1r.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <cover.1493728172.git.johannes.schindelin@gmx.de>

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

> For starters, those files include shell scripts: the most prevalent
> shell interpreter in use (and certainly used in Git for Windows) is
> Bash, and Bash does not handle CR/LF line endings gracefully.

Good to know. I am not sure if it is OK for shell scripts not to honor the platform convention, though.

Stated from the opposite angle, I would not be surprised if your shell scripts do not work on Linux if you set core.autocrlf to true. Git may honor it, but shells on Linux (or BSD for that matter) do not pay attention to core.autocrlf and they are within their rights to complain on an extra CR at the end of the line. IOW, I would doubt that it should be our goal to set core.autocrlf on a platform whose native line endings is LF and make the tests to pass.

Show 6 quoted lines

> Related to shell scripts: when generating common-cmds.h, we use tools
> that generally operate on the assumption that input and output
> deliminate their lines using LF-only line endings. Consequently, they
> would happily copy the CR byte verbatim into the strings in
> common-cmds.h, which in turn makes the C preprocessor barf (that
> interprets them as MacOS-style line endings).

This indeed is a problem. "add\r" is not a name of a common command, obviously, regardless of how the text file that lists the names of the commands is encoded. I am undecided if it is a problem in the source text (i.e. command-list.txt is not a platform neutral "text" but has to be encoded with LF endings) or the bug in the tools used in the generate-cmdlist.sh script, though. Shouldn't the tools be aware of the platform convention of what text files are and how their eol looks like?