Re: [PATCH v3 1/6] Fix build with core.autocrlf=true

From: Jonathan Nieder <jrnieder@gmail.com>
Date: May 22, 2017, 17:57 UTC
Message-ID: <20170522175709.GC17710@aiede.svl.corp.google.com>
In-Reply-To: <6bc890b10de8a59f90005462f8767d6b022b0749.1494334366.git.johannes.schindelin@gmx.de>

(+cc: Pat Thoyts, git-gui maintainer) Hi,

Johannes Schindelin wrote:

Show 41 quoted lines

> On Windows, the default line endings are denoted by a Carriage Return
> byte followed by a Line Feed byte, while Linux and MacOSX use a single
> Line Feed byte to denote a line ending.
>
> To help with this situation, Git introduced several mechanisms over the
> last decade, most prominently the `core.autocrlf` setting.
>
> Sometimes, however, a single setting is incorrect, e.g. when certain
> files in the source code are to be consumed by software that can handle
> only LF line endings, while other files can use whatever is appropriate
> for the current platform.
>
> To allow for that, Git added the `eol` option to its .gitattributes
> handling, expecting every user of Git to mark their source code
> appropriately.
>
> Bash assumes that line-endings of scripts are denoted by a single Line
> Feed byte. Therefore, shell scripts in Git's source code are one example
> where that `eol=lf` option is *required*.
>
> When generating common-cmds.h, the Unix tools we use 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). Therefore, we
> have to mark the input files as LF-only: command-list.txt and
> Documentation/git-*.txt.
>
> Quite a bit belatedly, this patch brings Git's own source code in line
> with those expectations by setting those attributes to allow for a
> correct build even when core.autocrlf=true.
>
> This patch can be validated even on Linux, by using this cadence:
>
> 	git config core.autocrlf true
> 	rm .git/index && git stash
> 	make -j15 DEVELOPER=1
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
> ---

Thanks again for writing this patch. One bit of administrivia I missed before:

Pat, would you mind picking up this .gitattributes change for git-gui?

Junio, how do you prefer to handle this in git.git? Would you need to amend the patch to remove the git-gui/.gitattributes change and wait to get it from Pat, or is getting the same change twice okay? If I understand git-gui/GIT-VERSION-GEN correctly, then either way, once you perform a subtree merge from git://repo.or.cz/git-gui the "version" file will be okay.

Patch left unsnipped for reference.

Thanks, Jonathan

Show 28 quoted lines

>  .gitattributes         | 8 +++++++-
>  git-gui/.gitattributes | 1 +
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/.gitattributes b/.gitattributes
> index 320e33c327c..8ce9c6b8888 100644
> --- a/.gitattributes
> +++ b/.gitattributes
> @@ -1,3 +1,9 @@
>  * whitespace=!indent,trail,space
>  *.[ch] whitespace=indent,trail,space diff=cpp
> -*.sh whitespace=indent,trail,space
> +*.sh whitespace=indent,trail,space eol=lf
> +*.perl eol=lf
> +*.pm eol=lf
> +/Documentation/git-*.txt eol=lf
> +/command-list.txt eol=lf
> +/GIT-VERSION-GEN eol=lf
> +/mergetools/* eol=lf
> diff --git a/git-gui/.gitattributes b/git-gui/.gitattributes
> index 33d07c06bd9..59cd41dbff7 100644
> --- a/git-gui/.gitattributes
> +++ b/git-gui/.gitattributes
> @@ -2,3 +2,4 @@
>  *           encoding=US-ASCII
>  git-gui.sh  encoding=UTF-8
>  /po/*.po    encoding=UTF-8
> +/GIT-VERSION-GEN eol=lf