다른 운영 체제 간 git core.autocrlf에서 행 끝 변환이 작동하는 방식

core.autocrlf 설정 작동 방식 에 대한 자식 문서 뿐만 아니라 스택 오버플로에 대한 다양한 질문과 답변을 읽었습니다 .

이것은 내가 읽은 내용을 이해 한 것입니다.

Unix 및 Mac OSX (OSX 이전 버전에서는 CR 사용) 클라이언트는 LF 줄 끝을 사용합니다.
Windows 클라이언트는 CRLF 줄 끝을 사용합니다.

클라이언트에서 core.autocrlf가 true로 설정되면 git 저장소는 항상 파일을 LF 줄 끝 형식으로 저장하고 클라이언트에서 파일의 줄 끝은 체크 아웃 / 커밋시 클라이언트 (예 : Windows)에서 앞뒤로 변환됩니다. -LF 라인 엔딩 (라인 엔딩 파일이 클라이언트에 어떤 형식으로되어 있는지에 관계없이 팀 타임 (Tim Clem)의 정의에 동의하지 않음-아래 업데이트 참조)

다음은 줄 끝 변환 동작이 확실하지 않은 물음표가있는 core.autocrlf의 '입력'및 '거짓'설정에 대해 동일하게 문서화하는 행렬입니다.

내 질문은 :

1. 물음표는 무엇이어야합니까?
2. 이 매트릭스가 "물음표"가 아닌가?

컨센서스가 형성된 것처럼 답변에서 물음표를 업데이트합니다.

                       core.autocrlf 값
            참 입력 거짓
-------------------------------------------------- --------
커밋 | 변환? ?
새로운 | LF로 (LF로 변환 하시겠습니까?) (전환 없음?)

커밋 | 로 변환하다 ? 아니
기존 | LF (LF로 변환?) 변환

결제 | 로 변환하다 ? 아니
기존 | CRLF (전환 없음) 전환

나는 다양한 환경의 장단점에 대한 의견을 실제로 찾고 있지 않습니다. git이 세 가지 설정 각각에서 작동하는 방법을 분명히하는 데이터를 찾고 있습니다.

-

업데이트 04/17/2012 : 주석에서 JJD로 링크 된 Tim Clem의 기사를 읽은 후 위의 표에서 "알 수없는"값의 일부 값을 수정하고 "기존의 체크 아웃 | true로 변경 클라이언트로 전환하는 대신 CRLF로 다음은 그가 제공 한 정의이며 다른 곳에서 본 것보다 명확합니다.

core.autocrlf = 거짓

이것이 기본값이지만 대부분의 사람들은이를 즉시 변경하도록 권장합니다. false를 사용하면 Git이 파일의 줄 끝을 엉망으로 만들지 않습니다. LF 또는 CRLF 또는 CR 또는이 세 가지를 임의로 혼합하여 파일을 체크인 할 수 있으며 Git은 신경 쓰지 않습니다. 이로 인해 diff를 읽기 어렵고 병합하기가 더 어려워 질 수 있습니다. 유닉스 / 리눅스 세계에서 일하는 대부분의 사람들은 CRLF 문제가없고 파일이 객체 데이터베이스에 쓰여지거나 작업 디렉토리에 쓰여질 때마다 Git이 추가 작업을 수행 할 필요가 없기 때문에이 값을 사용합니다.

core.autocrlf = true

즉, Git은 모든 텍스트 파일을 처리하고 파일을 객체 데이터베이스에 쓸 때 CRLF가 LF로 바뀌고 작업 디렉토리에 쓸 때 모든 LF를 다시 CRLF로 바꿉니다. 작업 디렉토리에 CRLF를 유지하면서 다른 플랫폼에서 저장소를 사용할 수 있으므로 Windows에서 권장되는 설정입니다.

core.autocrlf = 입력

즉, Git은 모든 텍스트 파일을 처리하고 해당 파일을 객체 데이터베이스에 쓸 때 CRLF가 LF로 바뀌어야합니다. 그러나 그 반대는 아닙니다. 오브젝트 데이터베이스에서 파일을 다시 읽고 작업 디렉토리에 파일을 쓰면 여전히 줄 끝을 나타내는 LF가 있습니다. 이 설정은 일반적으로 CRLF가 저장소에 작성되지 않도록 Unix / Linux / OS X에서 사용됩니다. 아이디어는 웹 브라우저에서 코드를 붙여 넣고 실수로 CRLF를 파일 중 하나에 넣은 경우 Git은 객체 데이터베이스에 쓸 때 LF로 대체되었는지 확인하는 것입니다.

Tim의 기사는 훌륭하지만, 내가 생각할 수없는 유일한 것은 저장소가 LF 형식이라고 가정한다는 것입니다. 특히 Windows 전용 프로젝트의 경우 반드시 사실은 아닙니다.

jmlane이 팀의 기사를 가장 많이 투표 한 답변과 비교하면 실제 및 입력 설정에 대한 완벽한 동의와 잘못된 설정에 대한 의견 불일치가 표시됩니다.

core.autocrlf작동 방식에 대한 최상의 설명은 속성 섹션 의 gitattributes 매뉴얼 페이지에서 찾을 수 text있습니다.

이것은 core.autocrlf현재 (또는 적어도 v1.7.2 이후 내가 알고있는 것) 작동 하는 것처럼 보입니다.

• core.autocrlf = true
  1. 문자 만있는 저장소에서 체크 아웃 된 텍스트 파일 LF은 CRLF작업 트리에서 정규화됩니다 . CRLF저장소에 포함 된 파일은 건드리지 않습니다
  2. 단지이 텍스트 파일 LF저장소의 문자에서 정규화 CRLF에 LF저장소에 때 최선을 다하고 다시. CRLF저장소에 포함 된 파일은 그대로 커밋됩니다.
• core.autocrlf = input
  1. 저장소에서 체크 아웃 된 텍스트 파일은 작업 트리에 원본 EOL 문자를 유지합니다.
  2. 작업 트리에서 CRLF문자가 있는 텍스트 파일 LF은 저장소로 다시 커밋 될 때 정규화됩니다 .
• core.autocrlf = false
  1. core.eol 작업 트리의 텍스트 파일에서 EOL 문자를 나타냅니다.
  2. core.eol = native기본적으로 이는 Windows EOL이 CRLF있고 * nix EOL이 LF작업 트리에 있음을 의미합니다.
  3. 리포지토리 gitattributes설정은 리포지토리 커밋에 대한 EOL 문자 정규화를 결정합니다 (기본값은 LF문자에 대한 정규화 ).

나는 최근 에이 문제를 연구했으며 상황이 매우 복잡하다는 것을 알았습니다. 이 core.eol설정은 git이 EOL 문자를 처리하는 방법을 분명히하는 데 도움이되었습니다.

혼합 플랫폼 프로젝트에서 EOL 문제는 오랫동안 내 인생을 비참하게 만들었습니다. 이미 다른 혼합 EOLs의 파일이있을 때 문제는 일반적으로 발생하는 이미 의 repo한다. 이것은 다음을 의미합니다.

1. 저장소에는 EOL이 다른 파일이있을 수 있습니다.
2. REPO에서 일부 파일의 조합 예 혼합 EOL이있을 수 있습니다 CRLF와 LF같은 파일을.

이 문제가 발생하는 방식은 여기서 문제가 아니지만 발생합니다.

다양한 모드와 그 조합에 대해 Windows에서 일부 변환 테스트를 실행했습니다.
다음은 약간 수정 된 테이블에서 얻은 것입니다.

                 | 결과 변환 | 결과 변환
                 | 다양한 파일 커밋 | FROM 저장소 확인-
                 | 저장소로 EOL 및 | 파일이 혼합되어 있고
                 | core.autocrlf 값 : | core.autocrlf 값 :           
-------------------------------------------------- ------------------------------
파일 | 참 | 입력 | 거짓 | 참 | 입력 | 그릇된
-------------------------------------------------- ------------------------------
Windows-CRLF | CRLF-> LF | CRLF-> LF | 있는 그대로 | 있는 그대로 | 있는 그대로 | 그대로
유닉스 -LF | 있는 그대로 | 있는 그대로 | 있는 그대로 | LF-> CRLF | 있는 그대로 | 그대로
맥 -CR | 있는 그대로 | 있는 그대로 | 있는 그대로 | 있는 그대로 | 있는 그대로 | 그대로
혼합 CRLF + LF | 있는 그대로 | 있는 그대로 | 있는 그대로 | 있는 그대로 | 있는 그대로 | 그대로
혼합 CRLF + LF + CR | 있는 그대로 | 있는 그대로 | 있는 그대로 | 있는 그대로 | 있는 그대로 | 그대로

보시다시피 커밋에서 변환이 발생하는 경우는 2 가지입니다 (왼쪽 열 3 개). 나머지 경우 파일은 그대로 커밋됩니다.

결제시 (오른쪽 열 3 개) 다음 경우에 전환이 발생하는 경우는 1 가지입니다.

1. core.autocrlf이다 true 와
2. 저장소의 파일에는 LFEOL이 있습니다.

나에게 가장 놀라운 것은 많은 EOL 문제의 원인이 CRLF+ 와 같은 혼합 EOL LF이 정규화 되는 구성이 없다는 것입니다 .

또한 "오래된"Mac EOL CR도 변환되지 않습니다.
이 수단은 심하게 작성 EOL 변환 스크립트 시도가있는 혼합 엔딩 파일을 변환하는 경우 있음 CRLF의 + LF단지로 변환하여,들 LF에들 CRLF들, 그것은 "외로운"로 혼합 모드에서 파일을 떠나 CRA는 곳이야 CRLF로 변환되었다 CRCRLF.
Git은 true모드 에서도 아무 것도 변환하지 않으며 EOL 혼란은 계속됩니다. 일부 편집자와 컴파일러 (예 : VS2010)는 Mac EOL을 좋아하지 않기 때문에 실제로 이런 일이 생겨서 파일이 엉망이되었습니다.

난 정말이 문제를 처리 할 수있는 유일한 방법에 추측 때때로 에있는 모든 파일을 확인하여 정상화 전체의 repo input또는 false적절한 정상화와 재 투입 변경된 파일 (있는 경우)를 실행하는 모드. Windows에서는 아마도 작업을 다시 시작 core.autocrlf true합니다.

곧 출시 될 Git 1.7.2 와 함께 "eol conversion"이 바뀌고 있습니다 .

새로운 구성 설정 core.eol이 추가 / 진행되고 있습니다 :

이것은 core.eol현재 pu(내 시리즈의 마지막 것)에 있는 ' " "구성 변수 추가 커밋을 대체합니다 .
" core.autocrlf=true"가 " "의 대체품이라는 것을 암시하는 대신 * text=auto, 텍스트 파일 정규화가없는 저장소의 작업 디렉토리에서 CRLF를 사용하려는 사용자에게만 해당된다는 사실을 명시합니다autocrlf .
활성화되면 "core.eol"이 무시됩니다.

core.eol사용자가 작업 디렉토리에서 줄 끝 정규화 파일에 사용할 줄 끝을 설정할 수 있는 새로운 구성 변수 " "를 소개합니다 .
기본값은 " native"입니다. 이는 Windows에서 CRLF를 의미하고 다른 곳에서는 LF를 의미합니다. " core.autocrlf"는 우선 core.eol합니다.
이것은 다음을 의미합니다.

[core]
  autocrlf = true

core.eol" lf" 로 설정되어 있어도 작업 디렉토리에 CRLF를 넣습니다 .

core.eol:

text특성이 설정된 파일의 작업 디렉토리에서 사용할 행 끝 유형을 설정합니다.
대안은 플랫폼의 기본 줄 끝을 사용하는 'lf', 'crlf'및 'native'입니다.
기본값은 native입니다.

다른 진화 가 고려되고 있습니다 :

1.8의 경우 core.autocrlf정규화를 켜고 작업 디렉토리 줄 끝 결정을 core.eol로 남겨 두는 것이 사람들의 설정 을 손상시킵니다.

git 2.8 (2016 년 3 월)은 core.autocrlfeol에 영향을 미치는 방식 을 개선합니다 .

참조 817a0c7 커밋 (2016년 2월 23일를) 6e336a5 커밋 , df747b8 커밋 , df747b8 커밋 (2016년 2월 10일를) df747b8 커밋 , df747b8 커밋 (2016년 2월 10일을), 및 4b4024f 커밋 , bb211b4 커밋 , 92cce13 커밋 , 320d39c 커밋 , 4b4024f 커밋 , commit bb211b4 , commit 92cce13 , commit 320d39c (2016 년 2 월 05 일) by Torsten Bögershausen ( tboegi) .
^{( Junio ​​C gitsterHamano 에 의해 합병) - 커밋 c6b94eb, 2016 년 2 월 26 일)}

convert.c: 리 팩터 crlf_action

의 결정 및 사용을 리팩터링하십시오 crlf_action.
현재 crlf파일에 " "속성이 설정 되지 않은 경우 crlf_action로 설정됩니다 CRLF_GUESS. CRLF_UNDEFINED대신 사용 하고 이전과 같이 " text"또는 " eol"를 검색 하십시오 .

이전 CRLF_GUESS사용법을 바꾸십시오.

CRLF_GUESS && core.autocrlf=true -> CRLF_AUTO_CRLF
CRLF_GUESS && core.autocrlf=false -> CRLF_BINARY
CRLF_GUESS && core.autocrlf=input -> CRLF_AUTO_INPUT

다음을 정의하여 더 명확하고 무엇을 정의하십시오.

- CRLF_UNDEFINED : No attributes set. Temparally used, until core.autocrlf
                   and core.eol is evaluated and one of CRLF_BINARY,
                   CRLF_AUTO_INPUT or CRLF_AUTO_CRLF is selected
- CRLF_BINARY    : No processing of line endings.
- CRLF_TEXT      : attribute "text" is set, line endings are processed.
- CRLF_TEXT_INPUT: attribute "input" or "eol=lf" is set. This implies text.
- CRLF_TEXT_CRLF : attribute "eol=crlf" is set. This implies text.
- CRLF_AUTO      : attribute "auto" is set.
- CRLF_AUTO_INPUT: core.autocrlf=input (no attributes)
- CRLF_AUTO_CRLF : core.autocrlf=true  (no attributes)

으로 torek는 추가 의견에 :

이러한 모든 변환 (또는 EOL 변환 eol=또는 autocrlf설정 및 " clean"필터) 은 파일이 작업 트리에서 index로 이동할 때 ( 즉, 시간이 git add아닌 동안 ) 실행됩니다git commit .
( git commit -a또는 그 시점에서 --only또는 --include색인에 파일을 추가하십시오.)

이에 대한 자세한 내용은 " autocrlf와 eol의 차이점은 무엇입니까?를 참조하십시오. .

core.autocrlf값은 OS 유형에 의존하지 않지만 Windows의 기본값은 trueLinux- input입니다. 커밋 및 체크 아웃 사례에 대해 3 가지 가능한 값을 탐색했으며 결과 테이블입니다.

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║               ║ LF   => LF   ║ LF   => LF   ║ LF   => LF   ║
║ git commit    ║ CR   => CR   ║ CR   => CR   ║ CR   => CR   ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => LF   ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║               ║ LF   => LF   ║ LF   => LF   ║ LF   => CRLF ║
║ git checkout  ║ CR   => CR   ║ CR   => CR   ║ CR   => CR   ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

누군가를 도울 수 있도록 지금까지 이해했습니다.

core.autocrlf=true 과 core.safecrlf = true

당신은이 모든 라인 엔딩이 같은 저장소를 ,하지만 당신은 다른 플랫폼에서 작동합니다. 힘내 줄 끝을 플랫폼의 기본값으로 변환합니다. 이것이 왜 중요한가? 새 파일을 작성한다고 가정 해 봅시다. 플랫폼의 텍스트 편집기는 기본 줄 끝을 사용합니다. 체크인 할 때 core.autocrlf가 true로 설정되지 않은 경우, 플랫폼에서 다른 줄 끝으로 기본 설정되는 누군가를 위해 줄 끝 불일치를 도입했습니다. crlf 작업이 가역적임을 알고 싶습니다. 이 두 설정을 사용하면 git은 파일을 수정하지만 수정 사항을 되돌릴 수 있는지 확인합니다 .

core.autocrlf=false

이미 줄 끝이 혼합 되어있는 저장소가 있고 잘못된 줄 끝을 수정하면 다른 문제가 발생할 수 있습니다. 이 경우 git에게 줄 끝을 변환하도록 지시하지 않는 것이 가장 좋습니다. 그러면 해결하기 위해 설계된 문제를 악화시킬 수 있습니다. 이 설정을 사용하면 git은 파일을 수정하지 않습니다 .

core.autocrlf=input

그 이유는 기본적으로 LF 줄 끝으로 플랫폼에 CRLF 줄 끝이있는 파일을 만든 사용 사례를 다루기 때문에 이것을 사용하지 않습니다. 대신 텍스트 편집기에서 항상 플랫폼의 줄 끝 기본값으로 새 파일을 저장하는 것을 선호합니다.

아니요, @jmlane 답변이 잘못되었습니다.

의 경우 Checkin (git add, git commit):

1. 경우 text속성입니다Set, Set value to 'auto' 인 파일이 'CRLF'로 커밋 된 후 변환이 발생합니다.
2. 경우 text속성입니다Unset : 아무것도 들어 enen을 발생하지Checkout
3. 경우에 text재산은 Unspecified, 변환에 따라 달라집니다core.autocrlf
   1. 만약 autocrlf = input or autocrlf = true 리포지토리의 파일이 'LF'인 경우에만 변환이 발생하고 'CRLF'인 경우 아무 작업도 수행되지 않습니다.
   2. 인 경우 autocrlf = false아무 일도 일어나지 않습니다

의 경우 Checkout:

1. 경우 text속성입니다Unset : 아무 반응이 없습니다.
2. 경우 text속성이 있습니다 Set, Set value to 'auto: 그것은에 따라 core.autocrlf,core.eol .
   1. core.autocrlf = 입력 : 아무 일도 일어나지 않습니다
   2. core.autocrlf = true : 저장소의 파일이 'LF', 'LF'-> 'CRLF'인 경우에만 변환이 수행됩니다.
   3. core.autocrlf = false : 저장소의 파일이 'LF', 'LF'-> 인 경우에만 변환이 수행됩니다. core.eol
3. 경우 text속성입니다 Unspecified, 그것은에 따라 달라집니다 core.autocrlf.
   1. 와 동일 2.1
   2. 와 동일 2.2
   3. 아무 일도 일어나지 않습니다. core.eol은 text속성이 유효하지 않을 때 효과적이지 않습니다.Unspecified

기본 행동

기본 동작은 그래서 text호텔입니다 Unspecified과 core.autocrlf = false:

1. 체크인을 위해 아무 일도 일어나지 않습니다
2. 결제를 위해 아무 일도 일어나지 않습니다

결론

1. 만약 text 속성을 설정, 동작을한다 체크인하는 것은 autocrlf에, 그 자체에 있지 따라
2. autocrlf 또는 core.eol은 체크 아웃 동작을위한 것이며 autocrlf> core.eol

리눅스와 윈도우에서 모두 테스트했습니다. LF로 끝나는 줄과 CRLF로 끝나는 줄을 포함하는 테스트 파일을 사용합니다.
파일이 커밋되고 제거 된 다음 체크 아웃됩니다. core.autocrlf의 값은 커미트 전과 체크 아웃 전에 설정됩니다. 결과는 아래와 같습니다.

commit core.autocrlf false, remove, checkout core.autocrlf false: LF=>LF   CRLF=>CRLF  
commit core.autocrlf false, remove, checkout core.autocrlf input: LF=>LF   CRLF=>CRLF  
commit core.autocrlf false, remove, checkout core.autocrlf true : LF=>LF   CRLF=>CRLF  
commit core.autocrlf input, remove, checkout core.autocrlf false: LF=>LF   CRLF=>LF  
commit core.autocrlf input, remove, checkout core.autocrlf input: LF=>LF   CRLF=>LF  
commit core.autocrlf input, remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF  
commit core.autocrlf true, remove, checkout core.autocrlf false: LF=>LF   CRLF=>LF  
commit core.autocrlf true, remove, checkout core.autocrlf input: LF=>LF   CRLF=>LF  
commit core.autocrlf true,  remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF