Warning lf will be replaced by crlf in css style css

VSCode warning: LF will be replaced by CRLF in

I thought it’s a warning but my commit didn’t go through. I check and try to find a place to configure GIT inside VSCode. I read some advice like:

git config --get core.autocrlf 

I try to find some options in VSCode settings, but I just could not find a way to configure this in VSCode. What’s the correct way to configure this ? Thanks very much.

4 Answers 4

Outside VSCode, git config —global core.autocrlf false is a good option, as I mentioned here.

Inside VSCode, make sure the EOL (end of line) indicator (bottom right corner in the status bar) is the right one.
If your file has mixed line ending, there is no option to opt out of line ending normalisation for files, meaning, upon saving a file edited with VS Code, it appears to perform line ending normalisation automatically and without user notification of any sort.

Note: the warning message changes with Git 2.37 (Q3 2022) and becomes:

In the working copy of 'hello.txt', LF will be replaced by CRLF the next time Git touches it. 

I’m using Git inside VSCode to commit, not on the command line. I don’t know how to change the option git uses. How do I change it inside VSCode ?

Thanks for the reply. I was thinking of using the versioning feature in VSCode to run GIT and therefore, I could configure the options inside. Is that possible for this issue ? Thanks.

@DataT Yes, you can configure Git from the terminal. And add a .gitattributes file to your source code in order to specify the EOL you want for specific files, as I have done before. For any other Git operation, I use the GitLens VSCode extension.

If you’re working on Windows, you need to decide what line endings you want in your sandbox, and what line endings you want in your repos. The «right» choice for the autocrlf setting is not the same for everyone.

autocrlf=false: don’t mess with my files!

@VonC’s answer is the right answer if you just don’t want Git to mess with line endings — an autocrlf set to false means take files in and out of Git verbatim.

This is arguably the only correct setting for autocrlf , because as @VonC pointed out, files like Windows .bat files will get broken by newline conversions, and you really do not want line-end conversions to happen in binary files either (that .jpg file might not be recoverable once you’ve accidentally done a CRLF->LF conversion on it. )

autocrlf=input: fix my mistakes when I create files

My usual answer on Windows is different, however: in my repos, I want Unix-style newlines, always. But on my Windows machine a number of pesky tools create files with Windows-style newlines. Yes, you can (and should) set your editor to use the right line endings, but an autocrlf set to input catches my «mistakes», e.g., when a file is generated by a Python script on a Windows machine, it usually ends up with CRLF line endings. In my Windows configurations, I always use git config —global core.autocrlf input , and that means my files always get committed with Unix style newlines, but they get checked out as they exist in the repo.

What about .bat and binary files? When this settings causes a conversion, Git issues a warning for me, so if it were to happen on a file where it should not, I’d get a warning and could fix the situation for that commit. I don’t remember ever having had a problem with this, however, but my Git repos are pretty much exclusively portable source code and text files where I really, really want LF endings.

I think this is a nice setting if you’re working on a Linux- or Mac-oriented project from a Windows PC.

autocrlf=true: I really always want CRLF in my checked out files

I mention this one for completeness, but would generally advise against it. If you always want your files with CRLF line endings when you’re working on them, setting autocrlf to true will do that, but commit them in Unix-style LF line endings. This makes sense in some cases, but it can cause trouble in many cases.

Make your choice and save it globally

From the message you got, I’m guessing true was your setting, so you probably want to decide which of false or input is best for you, and set that globally, by running one of these two commands in your Git Bash prompt:

git config --global core.autocrlf false 

git config --global core.autocrlf input 

Wish-list for Git developers:

What I would really like is an autocrlf=prompt setting: ask me what to do any time I try to commit a file with a CRLF in it. I guess I should make myself a pre-commit hook for it.

Источник

Git fatal: LF would be replaced by CRLF

Подскажите, как необходимо настроить git , чтобы избавиться от данной ошибки?

4 ответа 4

скорее всего, в результате выполнения этого действия:

в файле всё-таки остался хотя бы один «одиночный» символ lf .

как необходимо настроить git что бы избавиться от данной ошибки?

совсем «избавиться» от сообщения можно, вернув значение по умолчанию:

$ git config --global core.safecrlf false 

заменить же сообщение об ошибке на предупреждение можно так:

$ git config --global core.safecrlf warn 

дополнительные сведения можно почерпнуть в man-странице git-config.

спасибо за ответ, на текущий момент в данном решении установил autocrlf в false . я тоже подумал о том что notepad++ что то пропустил но как узнать где я не придумал

если у вас есть «под рукой» операционная система gnu/linux, можно воспользоваться программой hexdump для просмотра файла в «шестнадцатиричном» виде: $ hexdump -C файл | less .

Если вы работаете в jetBrains idea:

1) внизу справа, увидите такой значок

Здесь вы можете поменять формат для текущего файла на crlf , а затем повторить git push

2) Если хотите изменить формат всех файлов, то в верхнем меню идеи найдите:

File > Line Separators > CRLF.

git config core.autocrlf input 

Думаю настройки менять не стоит, сам использую такие же.

Akela_wolf на Habr (Git for Windows: работа с параметром core.autocrlf): «Если коротко: в Windows надо всегда ставить autocrlf=true. Это означает что в репозитории всегда будет храниться LF. А при извлечении из репозитория — произойдет преобразование в CRLF. И это обеспечит консистентность если в будущем появится еще один разработчик, работающий в Linux или MacOS. Или если даже единственный разработчик вдруг возьмет макбук/установит Linux и т.д. Остальное — как правило ненужная гибкость, которая востребована если вы точно понимаете что и зачем делаете.»

А чтоб ошибка «fatal: LF..» не появлялась, необходимо будет настроить редактор как уже здесь посоветовала Julia Usanova. В VS Code это делается так же просто.

Эксперимент третий. Для начала немного предыстории. Git я использую под Windows (сборку msysgit) для переноса исходников из дома на работу. Но иногда получалась ситуация, когда приношу измененные исходники в главном репозитории, делаю git pull, чтобы обновить исходники в рабочей копии, команда без проблем выполняется, но затем, если даже ничего не трогать, то некоторые файлы помечаются как измененные. Я долго не мог понять в чем дело, просмотр изменений по сравнению с предыдущей версией показывал, что якобы изменились все строки в файлах, причем сами на себя. Команда git reset —hard ничего не меняла, даже откат изменений с помощью git checkout — ничего не давал, файлы оставались помечены как измененные. Сразу закралась мысль о переводах строк, но повторить ситуацию в лабораторных условиях, чтобы точно определить когда такое происходит, удалось только недавно, также случайно нашлось решение этой проблемы, но вопрос почему это происходит до сих пор открыт.

Источник

Git, adding files to repository gives fatal error for LF ->CRLF

I’m new to git and I need some help. I’m using msysgit on windows. When I execute the command git add [folderName] I get the response:

fatal: LF would be replaced by CRLF in [.css file or .js file] 

$ git commit # On branch master # # Initial commit # # Untracked files: # (use "git add . " to include in what will be committed) # # so01/ nothing added to commit but untracked files present (use "git add" to track) 

Some of these css/js files were downloaded from the net so I guess that’s why the have LF. If I open the file and cut/paste the content, then I get the error on the next file and so on. Any help will be much appreciated. Edit Setting core.autocrlf to false seems to solve the problem, but I read on many posts not to set this option to false. Can somebody point me where can I find out what problems may arise in this situation?

No. I am working on a small app that I will put on appharbor. So far everything is good, but I wanted to know what’s the difference in those options. After i finish the app i do plan to do some reasrch but in the mean time i though i’ll use SO for a quick solution.

Then all the more reason to set autocrlf to false. You don’t need the headache. Have the files committed as is. It’s too bad that the default settings when installing msysgit take the worst option.

4 Answers 4

very new to this so setting core.autocrlf to false didn’t make too much sense to me. So for other newbies, go to the config file in you .git folder and add:

Trust the code editors to manipulate your line endings. Auto crlf should be false. Don’t let source control get too smart. If don’t need to have your source control tool to change your line endings, don’t. This will hurt.

To reiterate from an accepted answer: «Unless you can see specific treatment which must deal with native eol, you are better off leaving autocrlf to false.»

Also from the progit book at the end of the section on autocrlf:

«If you’re a Windows programmer doing a Windows-only project, then you can turn off this functionality, recording the carriage returns in the repository by setting the config value to false»

The only other help I can give is that if you take the other route, get familiar with vim -b which will show special characters such as the CR in MSysGit, and git show HEAD:path/to/your/file.txt which should show you the file in the way that git stored it.

Set core.whitespace cr-at-eol to have patches and diffs not highlight CRs as possible problematic whitespace.

Not worth the hassle. Store as-is.

Источник

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pushing not working: «LF will be replaced by CRLF» #37

Pushing not working: «LF will be replaced by CRLF» #37

Comments

Whenever I try to push, this error shows up:

Uncaught (in promise) Error: warning: LF will be replaced by CRLF in .obsidian/plugins/obsidian-citation-plugin/main.js. The file will have its original line endings in your working directory warning: LF will be replaced by CRLF in .obsidian/plugins/obsidian-citation-plugin/styles.css. The file will have its original line endings in your working directory warning: LF will be replaced by CRLF in .obsidian/plugins/templater-obsidian/main.js. The file will have its original line endings in your working directory warning: LF will be replaced by CRLF in .obsidian/workspace. The file will have its original line endings in your working directory warning: LF will be replaced by CRLF in proton.md. 

the error message goes on for lots of files, possibly every file in the vault, and ends on this:

warning: LF will be replaced by CRLF in fonction (math).mapp.js:1), :2304:85) at GitExecutorChain.eval (eval at (app.js:1), :2295:28) at Generator.throw () at rejected (eval at (app.js:1), :2249:65) 

The initial commit worked, and I checked and realized that no push ever worked since.
Any help/idea is appreciated.
on Windows 10 x64

The text was updated successfully, but these errors were encountered:

Источник