LF를 CRLF로 대체하는 자식

LF를 CRLF로 대체하는 자식

---

bash를 사용하여 Windows XP 시스템에서 git 실행 SVN에서 내 프로젝트를 내 보낸 다음 베어 저장소를 복제했습니다.

그런 다음 내보내기를 베어 리포지토리 디렉토리에 붙여넣고 다음을 수행했습니다.

git add -A

그런 다음 다음과 같은 메시지 목록을 받았습니다.

LF는 CRLF로 대체됩니다.

이 전환의 결과는 무엇입니까? 이것은 Visual Studio의 .NET 솔루션입니다.

---

이러한 메시지는 core.autocrlfWindows 에서의 잘못된 기본값 때문 입니다.

의 개념은 autocrlf줄 끝 변환을 투명하게 처리하는 것입니다. 그리고 그렇습니다!

나쁜 소식 : 값을 수동으로 구성해야합니다.
좋은 소식 : git 설치 당 한 번만 수행해야합니다 (프로젝트 설정도 가능).

어떻게 autocrlf작동 :

core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:

        repo                     repo                     repo
      ^      V                 ^      V                 ^      V
     /        \               /        \               /        \
crlf->lf    lf->crlf     crlf->lf       \             /          \      
   /            \           /            \           /            \

여기 crlf= win-style end-of-line 마커, lf= unix-style (및 mac osx).

( cr위의 세 가지 옵션에 영향을 미치지 않는 pre-osx )

이 경고는 언제 표시됩니까 (Windows에서)

    – autocrlf= 파일 중 하나에 true유닉스 스타일이 lf있는 경우 (= 드물게),
    – autocrlf= 파일 중 하나에 inputwin 스타일이 crlf있는 경우 (= 거의 항상),
    – autocrlf= false– 절대!

이 경고는 무엇을 의미합니까?

경고 " LF를 CRLF로 대체 될 것이다 "당신은 (가지고 있다고 autocrlf= true커밋 체크 아웃주기 (이 창 스타일 CRLF로 대체됩니다) 후 유닉스 스타일의 LF를 잃게됩니다). Git은 Windows에서 유닉스 스타일 LF를 사용할 것으로 기대하지 않습니다.

" CRLF가 LF로 대체 될 것입니다 "라는 경고 는 커밋 체크 아웃주기 후에 ( autocrlf=가있는 input) Windows 스타일의 CRLF를 잃게 될 것입니다 (유닉스 스타일 LF로 대체 됨). input창문 아래에서 사용하지 마십시오 .

autocrlf작동 방식을 보여주는 또 다른 방법

1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x

여기서 x 는 CRLF (windows 스타일) 또는 LF (unix 스타일)이고 화살표는

file to commit -> repository -> checked out file

어떻게 고치는 지

의 기본값 core.autocrlf은 git 설치 중에 선택되며 시스템 전체 gitconfig ( %ProgramFiles(x86)%\git\etc\gitconfig)에 저장됩니다 . 또한 (다음 순서로 계단식) 있습니다.

   -에있는 "글로벌"(사용자 별) gitconfig ~/.gitconfig, 또 다른
   -에서 "글로벌"(사용자 별) gitconfig $XDG_CONFIG_HOME/git/config또는 $HOME/.config/git/config과
   에서 "로컬"(당 REPO) gitconfig - .git/config작업 디렉토리입니다.

따라서 git config core.autocrlf작업 디렉토리에 작성 하여 현재 사용되는 값을 확인하고

   – autocrlf=false시스템 전체 gitconfig에 추가 # 시스템 별 솔루션
   – git config --global core.autocrlf false            # 사용자 별 솔루션
   – git config --local core.autocrlf false              # 프로젝트 별 솔루션

경고
– git config설정은 설정에 의해 무시 될 수 있습니다 gitattributes.
– crlf -> lf변환은 새 파일을 추가 할 때만 발생 crlf하며 리포지토리에 이미있는 파일은 영향을받지 않습니다.

도덕적 (Windows 용) :
    -사용 core.autocrlf= trueUnix에서도이 프로젝트를 사용하려는 경우 (그리고 편집기 / IDE에서 unix 줄 끝을 사용하도록 구성하지 않으려는 경우),
    -사용 core.autocrlf= falseWindows에서만이 프로젝트를 사용하려는 경우 ( 또는 유닉스 라인 엔딩을 사용하도록 편집기 / IDE를 구성했습니다.)
    - 합당한 이유가없는 한 =를 사용 하지 마십시오 ( 예 : Windows에서 유닉스 유틸리티를 사용하거나 메이크 파일 문제 가 발생한 경우).core.autocrlfinput

PS Windows 용 git을 설치할 때 무엇을 선택해야합니까?
Unix에서 프로젝트를 사용 하지 않으 려면 기본 첫 번째 옵션에 동의 하지 마십시오 . 세 번째 항목 (있는 그대로 체크 아웃,있는 그대로 커밋 )을 선택합니다. 이 메시지는 표시되지 않습니다. 이제까지.

PPS 내 개인적인 취향이 구성되어 편집기 / IDE 유닉스 스타일의 엔딩을 사용, 그리고 설정 core.autocrlf에 false.

---

Git에는 줄 끝을 처리하는 방법에 대한 세 가지 모드가 있습니다.

$ git config core.autocrlf
# that command will print "true" or "false" or "input"

위의 명령 줄 에 true또는 의 추가 매개 변수를 추가하여 사용할 모드를 설정할 수 있습니다 false.

이 core.autocrlftrue로 설정 되면 git이 텍스트 파일이라고 생각하는 git repo에 파일을 추가 할 때마다 커밋에 저장하기 전에 모든 CRLF 줄 끝을 LF로 바꾼다는 의미입니다. 당신이 git checkout무언가를 할 때마다 모든 텍스트 파일은 자동으로 LF 줄 끝이 CRLF 끝으로 변환됩니다. 이것은 라인 엔딩 스타일이 항상 일관되게 LF이기 때문에 각 에디터가 라인 엔딩 스타일을 변경하기 때문에 커밋하지 않고 다른 라인 엔딩 스타일을 사용하는 플랫폼에서 프로젝트를 개발할 수 있습니다.

이 편리한 변환의 부작용은 사용자가보고있는 경고입니다. 원래 작성한 텍스트 파일에 CRLF 대신 LF 엔딩이 있으면 평소와 같이 LF와 함께 저장되지만 확인하면 나중에 CRLF 엔딩이 있습니다. 일반 텍스트 파일의 경우 일반적으로 괜찮습니다. 이 경우 경고는 "정보 용"이지만 git이 바이너리 파일을 텍스트 파일로 잘못 평가 한 경우 git이 바이너리 파일을 손상시킬 것이기 때문에 중요한 경고입니다.

이 core.autocrlffalse로 설정 되면 줄 끝 변환이 수행되지 않으므로 텍스트 파일이있는 그대로 체크인됩니다. 모든 개발자가 Linux 또는 모두 Windows에있는 한 일반적으로 정상적으로 작동합니다. 그러나 내 경험상 여전히 문제를 일으키는 혼합 된 줄 끝이있는 텍스트 파일을 얻는 경향이 있습니다.

My personal preference is to leave the setting turned ON, as a Windows developer.

See http://kernel.org/pub/software/scm/git/docs/git-config.html for updated info that includes the "input" value.

---

If you already have checked out the code, the files are already indexed. After changing your git settings you should refresh the indexes with

git rm --cached -r . 

and re-write git index with

git reset --hard

https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings

---

git config core.autocrlf false

---

Both unix2dos and dos2unix is available in windows with gitbash. You can use the following command to perform UNIX(LF) -> DOS(CRLF) conversion. Hence, you will not get the warning.

unix2dos filename

or

dos2unix -D filename

But, don't run this command on any existing CRLF file, then you will get empty newlines every second line.

dos2unix -D filename will not work with every operating system. Please check this link for compatibility.

If for some reason you need to force the command then use --force. If it says invalid then use -f.

---

I think @Basiloungas's answer is close but out of date (at least on Mac).

Open the ~/.gitconfig file and set safecrlf to false

[core]
       autocrlf = input
       safecrlf = false

That *will make it ignore the end of line char apparently (worked for me, anyway).

---

A GitHub's article on line endings is commonly mentioned when talking about this topic.

My personal experience with using the often recommended core.autocrlf config setting was very mixed.

I'm using Windows with Cygwin, dealing with both Windows and UNIX projects at different times. Even my Windows projects sometimes use bash shell scripts, which require UNIX (LF) line endings.

Using GitHub's recommended core.autocrlf setting for Windows, if I check out a UNIX project (which does work perfectly on Cygwin - or maybe I'm contributing to a project that I use on my Linux server), the text files are checked out with Windows (CRLF) line endings, creating problems.

Basically, for a mixed environment like I have, setting the global core.autocrlf to any of the options will not work well in some cases. This option might be set on a local (repository) git config, but even that wouldn't be good enough for a project that contains both Windows- and UNIX-related stuff (e.g. I have a Windows project with some bash utility scripts).

The best choice I've found is to create per-repository .gitattributes files. The GitHub article mentions it.
Example from that article:

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

In one of my project's repository:

* text=auto

*.txt         text eol=lf
*.xml         text eol=lf
*.json        text eol=lf
*.properties  text eol=lf
*.conf        text eol=lf

*.awk  text eol=lf
*.sed  text eol=lf
*.sh   text eol=lf

*.png  binary
*.jpg  binary

*.p12  binary

It's a bit more things to set up, but do it once per project, and any contributor on any OS should have no troubles with line endings when working with this project.

---

In vim open the file (e.g.: :e YOURFILEENTER), then

:set noendofline binary
:wq

---

I had this problem too.

SVN doesn't do any line ending conversion, so files are committed with CRLF line endings intact. If you then use git-svn to put the project into git then the CRLF endings persist across into the git repository, which is not the state git expects to find itself in - the default being to only have unix/linux (LF) line endings checked in.

When you then check out the files on windows, the autocrlf conversion leaves the files intact (as they already have the correct endings for the current platform), however the process that decides whether there is a difference with the checked in files performs the reverse conversion before comparing, resulting in comparing what it thinks is an LF in the checked out file with an unexpected CRLF in the repository.

As far as I can see your choices are:

1. Re-import your code into a new git repository without using git-svn, this will mean line endings are converted in the intial git commit --all
2. Set autocrlf to false, and ignore the fact that the line endings are not in git's preferred style
3. Check out your files with autocrlf off, fix all the line endings, check everything back in, and turn it back on again.
4. Rewrite your repository's history so that the original commit no longer contains the CRLF that git wasn't expecting. (The usual caveats about history rewriting apply)

---

Footnote: if you choose option #2 then my experience is that some of the ancillary tools (rebase, patch etc) do not cope with CRLF files and you will end up sooner or later with files with a mix of CRLF and LF (inconsistent line endings). I know of no way of getting the best of both.

---

Removing the below from the ~/.gitattributes file

* text=auto

will prevent git from checking line-endings in the first-place.

---

It should read:

warning: (If you check it out/or clone to another folder with your current core.autocrlf being true,)LF will be replaced by CRLF

The file will have its original line endings in your (current) working directory.

This picture should explain what it means.

---

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/

echo "* -crlf" > .gitattributes 

Do this on a separate commit or git might still see whole files as modified when you make a single change (depending on if you have changed autocrlf option)

This one really works. Git will respect the line endings in mixed line ending projects and not warning you about them.

---

I don't know much about git on Windows, but...

Appears to me that git is converting the return format to match that of the running platform (Windows). CRLF is the default return format in Windows, while LF is the default return format for most other OSes.

Chances are, the return format will be adjusted properly when the code is moved to another system. I also reckon git is smart enough to keep binary files intact rather than trying to convert LFs to CRLFs in, say, JPEGs.

In summary, you probably don't need to fret too much over this conversion. However, if you go to archive your project as a tarball, fellow coders would probably appreciate having LF line terminators rather than CRLF. Depending on how much you care (and depending on you not using Notepad), you might want to set git to use LF returns if you can :)

Appendix: CR is ASCII code 13, LF is ASCII code 10. Thus, CRLF is two bytes, while LF is one.

---

1. Open the file in the Notepad++.
2. Go to Edit/EOL Conversion.
3. Click to the Windows Format.
4. Save the file.

---

OP's question is windows related and I could not use others without going to the directory or even running file in Notepad++ as administrator did not work.. So had to go this route:

C:\Program Files (x86)\Git\etc>git config --global core.autocrlf false

---

Make sure that you have installed the latest git.
I did as above git config core.autocrlf false, when used git (version 2.7.1), but it did not work.
Then it works now when upgrade git (from 2.7.1 to 2.20.1).

---

In a GNU/Linux shell prompt, dos2unix & unix2dos commands allow you to easely convert/format your files coming from MS Windows

---

Many text-editors allow you to change to LF, see Atom instructions below. Simple and explicit.

---

Click CRLF on bottom right:

Select LF in dropdown on top:

---

CRLF could cause some problem while using your "code" in two different OS (Linux and Windows). My python script was written in Linux docker container and then pushed using Windows git-bash. It gave me the warning that LF will be replaced by CRLF. I didn't give it much thought but then when I started the script later, it said /usr/bin/env: 'python\r': No such file or directory. Now that an \r for ramification for you. Windows uses "CR" - carriage return - on top of '\n' as new line character - \n\r. That's something you might have to consider.

참고URL : https://stackoverflow.com/questions/1967370/git-replacing-lf-with-crlf