Re: Regression (?) in core.safecrlf=false messaging

From: Torsten Bögershausen <tboegi@web.de>
Date: Jun 4, 2018, 07:38 UTC
Message-ID: <20180604073855.GA20922@tor.lan>
In-Reply-To: <CA+dzEBm_doNMjEs_OWwia_mm7u3ztAFpCpaFJP3DRpFhEo93jg@mail.gmail.com>

(as usual, no top-posting here, please see my answers at the end)

On Sun, Jun 03, 2018 at 10:54:00PM -0700, Anthony Sottile wrote:

Show 91 quoted lines

> I'm a bit unclear if I was depending on undocumented behaviour or not
> here but it seems the messaging has recently changed with respect to
> `core.safecrlf`
> 
> My reading of the documentation
> https://git-scm.com/docs/git-config#git-config-coresafecrlf (I might
> be wrong here)
> 
> - core.safecrlf = true -> fail hard when converting
> - core.safecrlf = warn -> produce message when converting
> - core.safecrlf = false -> convert silently
> 
> (note that these are all only relevant when `core.autocrlf = true`)
> 
> I've created a small script to demonstrate:
> 
> ```
> set -euxo pipefail
> 
> git --version
> 
> rm -rf repo
> git init repo
> cd repo
> git config core.autocrlf input
> git config core.safecrlf false
> echo -en 'foo\r\nbar\r\n' > f
> git add f
> ```
> 
> When run against 2.16.4:
> 
> ```
> $ PATH=$PWD/prefix/bin:$PATH bash test.sh
> + git --version
> git version 2.16.4
> + rm -rf repo
> + git init repo
> Initialized empty Git repository in /tmp/git/repo/.git/
> + cd repo
> + git config core.autocrlf input
> + git config core.safecrlf false
> + echo -en 'foo\r\nbar\r\n'
> + git add f
> ```
> 
> (notice how there are no messages about crlf conversion while adding
> -- this is what I expect given I have core.safecrlf=false)
> 
> 
> When run against master:
> 
> ```console
> $ PATH=$PWD/prefix/bin:$PATH bash test.sh
> + git --version
> git version 2.18.0.rc0.42.gc2c7d17
> + rm -rf repo
> + git init repo
> Initialized empty Git repository in /tmp/git/repo/.git/
> + cd repo
> + git config core.autocrlf input
> + git config core.safecrlf false
> + echo -en 'foo\r\nbar\r\n'
> + git add f
> warning: CRLF will be replaced by LF in f.
> The file will have its original line endings in your working directory.
> ```
> 
> A `git bisect` shows this as the first commit which breaks this
> behaviour: 8462ff43e42ab67cecd16fdfb59451a53cc8a945
> 
> https://github.com/git/git/commit/8462ff43e42ab67cecd16fdfb59451a53cc8a945
> 
> The commit appears to be a refactor (?) that shouldn't have changed behaviour?
> 
> Here's the script I was using to bisect:
> https://i.fluffy.cc/2L4ZtqV3cHfzNRkKPbHgTcz43HMQJxdK.html
> 
> ```
> git bisect start
> git bisect bad v2.17.0
> git bisect good v2.16.4
> git bisect run ./test.sh
> ```
> 
> Noticed this due to test failures here:
> https://github.com/pre-commit/pre-commit/pull/762#issuecomment-394236625
> 
> Thanks,
> 
> Anthony

Thanks so much for the report, and the detailed analyzes that has been done. Good work, I would say.

This looks very much as an (unplanned) regression. I will have a look within the next days, as soon as my time allows it.