(+cc: Pat Thoyts, git-gui maintainer) Hi, Johannes Schindelin wrote: > 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@xxxxxx> > Reviewed-by: Jonathan Nieder <jrnieder@xxxxxxxxx> > --- 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 > .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