Git에서 core.autocrlf = true를 사용해야하는 이유는 무엇입니까?

Windows와 OS X에서 모두 액세스 할 수있는 Git 저장소가 있으며 CRLF 줄 끝이있는 파일이 이미 포함되어 있음을 알고 있습니다. 내가 알 수있는 한, 이것을 처리하는 두 가지 방법이 있습니다.

1. 설정 core.autocrlf에 false사방,

2. 의 지시에 따라 여기 에만 LF 라인 엔딩을 포함하는 저장소를 변환 (GitHub의의 도움말 페이지에 에코), 그 후에 설정 core.autocrlf을 trueWindows에서와 input이 일에 대한 문제는 OS X에서 그 나는 저장소에 이진 파일이있는 경우 그:

   1. gitattributes에서 이진으로 올바르게 표시되지 않습니다.
   2. CRLF와 LF를 모두 포함하는 경우

   그들은 손상 될 것입니다. 내 저장소에 이러한 파일이 포함되어있을 수 있습니다.

그렇다면 왜 Git의 줄 끝 변환을 끄지 않아야합니까? 웹에는 core.autocrlf전원을 끄고 문제를 일으키는 것에 대한 모호한 경고가 많이 있지만 특정 경고는 거의 없습니다. 내가 지금까지 찾은 유일한 것은 kdiff3가 CRLF 결말을 처리 할 수없고 (나에게 문제가되지 않음) 일부 텍스트 편집기에는 줄 끝 문제가 있습니다 (나에게도 문제가되지 않음).

이 저장소는 회사 내부에 있으므로 다른 autocrlf 설정 또는 줄 끝 요구 사항을 가진 사람들과 공유하는 것에 대해 걱정할 필요가 없습니다.

내가 알지 못하는 줄 끝을 그대로 두는 데 다른 문제가 있습니까?

설정해야하는 유일한 이유는 다음 autocrlf과 true같습니다.

• Unix 기반 EOL Git 저장소를 Windows로 복제 할 때 자동 EOL 변환으로 인해 git status모든 파일이 표시 되지 않도록 modified하십시오 ( 예 : 문제 83 참조 )
• 및 코딩 도구는 어떻게 든에 따라 기본 파일에서 EOL 스타일의 웰빙 선물 :
  • 예를 들어 네이티브 EOL을 탐지하기 위해 하드 코딩 된 코드 생성기
  • 네이티브 EOL을 탐지하도록 regexp 또는 코드가 설정된 기타 외부 배치 (리포지토리 외부)
  • 일부 Eclipse 플러그인은 플랫폼에 관계없이 CRLF로 파일을 생성 할 수 있다고 생각합니다. 이는 문제가 될 수 있습니다.
  • Notepad.exe로 코딩합니다 ( 메모장이 감지 된 EOL 문자를 존중하는 Windows 10 2018.09+를 사용하지 않는 경우 ).

특정 치료를 볼 수 있습니다하지 않는 해야한다 네이티브 EOL 처리를, 당신이 떨어져 더 나은 떠나 autocrlf에false ( git config --global core.autocrlf false).

이 구성은 로컬 구성입니다 (config가 repo에서 repo로 푸시되지 않기 때문에)

해당 리포지토리를 복제하는 모든 사용자에 대해 동일한 구성을 원하면 파일 의 속성을 사용하여 " git과 함께 최고의 CRLF처리 전략은 무엇입니까 ? "를 확인 하십시오 .text.gitattributes

예:

*.vcproj    text eol=crlf
*.sh        text eol=lf

참고 : git 2.8 (2016 년 3 월)부터 병합 마커는 더 이상 CRLF 파일에 혼합 줄 끝 (LF)을 도입 하지 않습니다 .
자세한 내용은 " <<<<<<< HEAD"병합 라인의에서 힘내 사용 CRLF합니다 " "

저는 .NET 개발자이며 몇 년 동안 Git과 Visual Studio를 사용해 왔습니다. 내 추천은 줄 끝을 참으로 설정하는 것입니다. 리포지토리 수명 동안 최대한 빨리 수행하십시오.

즉, Git이 줄 끝을 바꾸는 것을 싫어합니다. 소스 컨트롤은 내가하는 작업 만 저장하고 검색해야하며 수정해서는 안됩니다. 이제까지. 그러나 그렇습니다.

모든 개발자가 true로 설정되지 않은 경우 어떻게됩니까? 한 명의 개발자가 결국 true로 설정됩니다. 그러면 모든 파일의 줄 끝이 리포지토리의 LF로 변경됩니다. 그리고 사용자가 잘못된 것으로 설정하면 Visual Studio가 경고하고 변경하도록 요청합니다. 두 가지 일이 매우 빨리 발생합니다. 하나, 더 많은 경고를받을수록 팀이 커질수록 더 커집니다. 두 번째로 더 나쁜 것은 모든 수정 된 파일의 모든 줄이 변경되었음을 보여줍니다 (모든 줄의 줄 끝은 실제 사람에 의해 변경되기 때문입니다). 결국에는 더 이상 리포지토리의 변경 사항을 더 이상 확실하게 추적 할 수 없습니다. 모든 사람을 거짓으로 유지하는 것보다 모든 사람을 진실하게 유지하는 것이 훨씬 쉽고 깨끗합니다. 신뢰할 수있는 소스 컨트롤이하지 말아야 할 일을하고 있다는 사실에 따라 사는 것이 끔찍합니다. 이제까지.

업데이트 2 :

Xcode 9는 파일의 현재 줄 끝을 무시하고 대신 줄을 파일에 삽입 할 때 기본 줄 끝 설정을 사용하여 줄 끝이 혼합 된 파일을 만드는 "기능"이있는 것 같습니다.

나는이 버그가 Xcode 7에 존재하지 않았다고 확신한다. Xcode 8에 대해서는 잘 모르겠습니다. 좋은 소식은 Xcode 10에서 수정 된 것으로 보입니다.

그것이 존재하는 시간 동안,이 버그는 내가 질문에서 언급 한 코드베이스에 약간의 양대를 유발했으며 (오늘날 사용합니다 autocrlf=false) 많은 "EOL"커밋 메시지와 결국 git pre-commithook을 작성 하여 확인했습니다. 혼합 라인 엔딩 도입 / 방지.

업데이트 :

참고 : VonC에서 언급 한 것처럼 Git 2.8부터 병합 마커 는 Windows 스타일 파일에 Unix 스타일 줄 끝을 도입 하지 않습니다 .

원본 :

이 설정에서 알아 차린 작은 딸꾹질은 병합 충돌이있을 때 차이 파일을 표시하기 위해 줄 git가 추가 하여 파일의 나머지 부분이 있더라도 Windows 줄 끝 이 없다는 것을 의미합니다. 줄 끝이 혼합 된 파일이있는 경우, 예 :

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

이것은 우리에게 아무런 문제를 일으키지 않습니다 (두 가지 유형의 줄 끝을 처리 할 수있는 도구가 혼합 줄 끝을 처리 할 수 ​​있다고 생각합니다-분명히 우리가 사용하는 모든 것).

다른 것은 ^* 우리가 발견 한이입니다 사용할 때 git diff윈도우 라인 엔딩, 따라서 디스플레이 그들의 캐리지 리턴을 추가 한 라인을 가진 파일의 변경 사항을 볼 수 있습니다 :

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

_{* "문제"라는 용어는 실제로 가치가 없습니다.}