(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: > 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.
