env:
Wheng I git commit
, it says:
warning: LF will be replaced by CRLF.
Is this warning tail backward?
I edit file in Windows, the end of line is CRLF
, just like this pic:
And git changes it to LF
for committing to repo.
So I think the correct warning is:
warning: CRLF will be replaced by LF.
warning: LF will be replaced by CRLF.
Depending on the editor you are using, a text file with LF wouldn't necessary be saved with CRLF: recent editors can preserve eol style. But that git config setting insists on changing those...
Simply make sure that (as I recommend here ):
git config --global core.autocrlf false
That way, you avoid any automatic transformation, and can still specify them through a .gitattributes
file and core.eol
directives .
windows git "LF will be replaced by CRLF"
Is this warning tail backward?
No: you are on Windows, and the git config
help page does mention
Use this setting if you want to have
CRLF
line endings in your working directory even though the repository does not have normalized line endings.
As described in " git replacing LF with CRLF ", it should only occur on checkout (not commit), with core.autocrlf=true
.
repo
/ \
crlf->lf lf->crlf
/ \
As mentioned in XiaoPeng 's answer , that warning is the same as:
warning: (If you check it out/or clone to another folder with your current
core.autocrlf
configuration,) LF will be replaced by CRLF
The file will have its original line endings in your (current) working directory.
As mentioned in git-for-windows/git
issue 1242 :
I still feel this message is confusing, the message could be extended to include a better explanation of the issue, for example: "LF will be replaced by CRLF in
file.json
after removing the file and checking it out again".
Note: Git 2.19 (Sept 2018), when using core.autocrlf
, the bogus "LF will be replaced by CRLF" warning is now suppressed .
As quaylar rightly comments , if there is a conversion on commit, it is to LF
only.
That specific warning " LF will be replaced by CRLF
" comes from convert.c#check_safe_crlf() :
if (checksafe == SAFE_CRLF_WARN)
warning("LF will be replaced by CRLF in %s.
The file will have its original line endings
in your working directory.", path);
else /* i.e. SAFE_CRLF_FAIL */
die("LF would be replaced by CRLF in %s", path);
It is called by convert.c#crlf_to_git()
, itself called by convert.c#convert_to_git()
, itself called by convert.c#renormalize_buffer()
.
And that last renormalize_buffer()
is only called by merge-recursive.c#blob_unchanged()
.
So I suspect this conversion happens on a git commit
only if said commit is part of a merge process.
Note: with Git 2.17 (Q2 2018), a code cleanup adds some explanation.
See commit 8462ff4 (13 Jan 2018) by Torsten Bögershausen ( tboegi
) .
(Merged by Junio C Hamano -- gitster
-- in commit 9bc89b1 , 13 Feb 2018)
convert_to_git(): safe_crlf/checksafe becomes int conv_flags
When calling
convert_to_git()
, thechecksafe
parameter defined what should happen if the EOL conversion (CRLF --> LF --> CRLF
) does not roundtrip cleanly.
In addition, it also defined if line endings should be renormalized (CRLF --> LF
) or kept as they are.
checksafe was an
safe_crlf
enum with these values:
SAFE_CRLF_FALSE: do nothing in case of EOL roundtrip errors
SAFE_CRLF_FAIL: die in case of EOL roundtrip errors
SAFE_CRLF_WARN: print a warning in case of EOL roundtrip errors
SAFE_CRLF_RENORMALIZE: change CRLF to LF
SAFE_CRLF_KEEP_CRLF: keep all line endings as they are
Note that a regression introduced in 8462ff4 (" convert_to_git()
: safe_crlf/checksafe
becomes int conv_flags
", 2018-01-13, Git 2.17.0) back in Git 2.17 cycle caused autocrlf
rewrites to produce a warning message despite setting safecrlf=false
.
See commit 6cb0912 (04 Jun 2018) by Anthony Sottile ( asottile
) .
(Merged by Junio C Hamano -- gitster
-- in commit 8063ff9 , 28 Jun 2018)
YES the warning is backwards.
And in fact it shouldn't even be a warning in the first place. Because all this warning is saying (but backwards unfortunately) is that the CRLF characters in your file with Windows line endings will be replaced with LF's on commit. Which means it's normalized to the same line endings used by *nix and MacOS.
Nothing strange is going on, this is exactly the behavior you would normally want.
This warning in it's current form is one of two things:
;)
--Update on 9th July---
Removed "It is correct and accurate" as commented by @mgiuca
======
NO . It is NOT talking about your files currently with CRLF
. It is instead talking about files with LF
.
It should read:
warning: ( If you check it out/or clone to another folder with your current core.autocrlf configuration ,)LF will be replaced by CRLF
The file will have its original line endings in your ( current ) working directory.
All of this assumes core.autocrlf=true
Original error:
warning: LF will be replaced by CRLF
The file will have its original line endings in your working directory.
What the error SHOULD read:
warning: LF will be replaced by CRLF in your working directory
The file will have its original LF line endings in the git repository
Explanation here :
The side-effect of this convenient conversion, and this is what the warning you're seeing is about, is that if a text file you authored originally had LF endings instead of CRLF, it will be stored with LF as usual, but when checked out later it will have CRLF endings. For normal text files this is usually just fine. The warning is a "for your information" in this case, but in case git incorrectly assesses a binary file to be a text file, it is an important warning because git would then be corrupting your binary file.
Basically, a local file that was previously LF will now have CRLF locally
git config --global core.autocrlf false
works well for global settings.
But if you are using Visual Studio, might also need to modify .gitattributes
for some type of projects ( eg c# class library application ):
* text=auto
This happens because the configuration for GitHub Desktop on Windows assumes CRLF but the text editor may be using LF. You can change your local repository settings to use lf
instead.
Navigate to the root of the git repo and execute this in exact same order
git config core.eol lf
git config core.autocrlf input
After I set core.autocrlf=true
I was getting "LF will be replaced by CRLF" (note not "CRLF will be replaced by LF") when I was git add
ing (or perhaps it was it on git commit
?) edited files in windows on a repository (that does use LF) that was checked out before I set core.autocrlf=true
.
I made a new checkout with core.autocrlf=true
and now I'm not getting those messages.
I faced similar issue and using vscode(v1.57) on windows tried solutions defined in other answers but didn't worked.
So for me following steps worked:
end_of_line = lf
with end_of_line = crlf
git rm --cached
and warning gone!!Make sure you added unnecessary files or folders in .gitignore
file.
eg node_modules
if still face then run this command
``git config --global core.autocrlf false```
Close Visual Studio
If you get the error, a simple fix is closing Visual Studio and you can commit to main, it is that easy. I had this same problem and that was how I fixed it. It is caused because the files you want to open are open in another programm.
Is this warning tail backward?
The warning is first and foremost confusing.
Git 2.37 (Q3 2022) rewords and clarifies it.
See commit c970d30 (07 Apr 2022) by Alex Henrie ( alexhenrie
) .
(Merged by Junio C Hamano -- gitster
-- in commit 0a88638 , 20 May 2022)
convert
: clarify line ending conversion warningSigned-off-by: Alex Henrie
The warning about converting line endings is extremely confusing.
LF will be replaced by CRLF in ... The file will have its original line endings in your working directory.
Its two sentences each use the word "will" without specifying a timeframe, which makes it sound like both sentences are referring to the same timeframe.
On top of that, it uses the term "original line endings" without saying whether "original" means LF or CRLF.Rephrase the warning to be clear about when the line endings will be changed and what they will be changed to.
On a platform whose native line endings are not CRLF (eg Linux), the " git add
" ( man ) step in the following sequence triggers the new message in question (no more warning):
$ git config core.autocrlf true
$ echo 'Hello world!' >hello.txt
$ git add hello.txt
In the working copy of 'hello.txt', CRLF will be replaced by LF
the next time Git touches it.
And on a platform whose native line endings are not LF (eg Windows ), the " git add
" ( man ) step in the following sequence triggers the new message in question (no more warning):
$ git config core.autocrlf true
$ echo 'Hello world!' >hello.txt
$ git add hello.txt
In the working copy of 'hello.txt', LF will be replaced by CRLF
the next time Git touches it.
Unity user
In case you face this, and the error "permission denied" is shown. The problem was coming from having the unity editor open and trying to commit. I simply closed it and I was able to commit
Do just simple thing:
If you are using Visual Studio 2017, 2019, you can:
[core]
autocrlf = false
[filter "lfs"]
required = true
clean = git-lfs clean -- %f
smudge = git-lfs smudge -- %f
process = git-lfs filter-process
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.