Re: suggestion for improved docs on autocrlf

From: Torsten Bögershausen <tboegi@web.de>
Date: Aug 11, 2019, 12:10 UTC
Message-ID: <20190811121004.guygurnopwwggvsp@tb-raspi4>
In-Reply-To: <0c1b48c9fad641689ead69fdd9f72d63@bofa.com>

On Fri, Aug 09, 2019 at 03:34:05PM +0000, Yagnatinsky, Mark wrote:

> After correcting spelling of renormalize, the end result of the script you gave is that line endings in working directory are CRLF,
> and in the repo are LF.
> Is that expected?

Yes. "git add" does typically not touch the files on disk at all.

> Surprising?

May be. Typically the CRLF is done in the .gitattributes file, which is commited and pushed/pulled between the different machines. In opposite, core.autocrlf is just local, and different contributors may use different settings, leading to all kind of CRLF frustrations.

Having said that, the .gitattributes file is established early in the lifetime of a project (=repo). I typically set up the .gitattributes file as the first commit, before adding any other files.

If, however, the .gitattributes file is added to a repo later (better late than never), and the developer messes it up for some reasons, then the original files are still in the working tree on disk.

Correcttions can be made after looking at 'git ls-files --eol' or other diagnostics.

>Not sure what you were trying to test there.

There ? I probably lost the script.

Show 23 quoted lines

>I also fixed my script to use printf, new version is:
> (using copy/paste this time, instead typing from memory like last time; learned my lesson).
>
> mkdir empty
> cd empty
> git init
> git config core.autocrlf false
> printf '1\r\n2' > test.txt
> git add .
> git commit -m test
> git config core.autocrlf input
> cp test.txt t2.txt
> printf 'a\r\nb' > test.txt
> git add .
>
> Thank you for ls-files, I've been resorting to deleting from working directory and then doing a checkout.
> And also thank you for the gem of "od -c"!
> The output of ls-files after running my script is:
>
> i/lf    w/crlf  attr/                   t2.txt
> i/crlf  w/crlf  attr/                   test.txt
>
> So I'm still confused.  Why didn't test.txt lose its CRs while t2.txt did?

This is because the "auto" feature does not change the line endings, when a file had been commited with CRLF. They may be there on purpose, or not. Git can not make this decision - the user can.

This is why we have 'git add --renormalize".