Git 파일을 커밋하려고하지만 :: 치명적 : LF가 CRLF로 대체됩니다.
일부 변경된 파일을 커밋하려고하면 TortoiseGit에서 다음과 같은 오류 메시지가 나타납니다.
fatal: LF would be replaced by CRLF in <some file in the repo>
이제 일반적인 LF vs CRLF
답변을 받기 전에 토론이 무엇인지 알고 이해합니다. 둘째, 전역 설정도 다음과 같이 설정했습니다.
core.autocrlf true
셋째, 내가있어 .gitattributes
파일을 .
그래서 나는 또는 파일이 CRLF
.
내가 이해하지 못하는 것은 그것이 말하고 FATAL
계속하는 것을 막고 있다는 것 입니다. 경고? 확실한! 내가 무엇을 하려는지 알고 있습니까? 나는한다!
나는 단지 조용히 STFU로 변환하기를 원합니다 .
또는 강제로 나를 차단해야하는 경우 리포지토리의 모든 파일을으로 업데이트 할 수있는 방법 CRLF
이 있습니까? 그러면이 경고가 손실 될 수 있습니다.
이러한 저장소는 비공개이므로 Windows + Visual Studio 외부에서 개발되지 않습니다.
누구든지에이 스레드를 폄하하지 않고 도움을 주시겠습니까 autocrlf TRUE
대 autocrlf FALSE
종교 전쟁.
core.safecrlf
치명적인 오류가 아닌 경고 만 원하는 경우 "warn" 으로 설정할 수 있습니다 .
에서 " git config
옴 페이지" :
core.safecrlf
true이면 줄 끝 변환이 활성화되어있을 때 CRLF 변환이 되돌릴 수 있는지 git에서 확인합니다. Git은 명령이 작업 트리의 파일을 직접 또는 간접적으로 수정하는지 확인합니다.
예를 들어 파일을 커밋 한 다음 동일한 파일을 체크 아웃하면 작업 트리에 원본 파일이 생성됩니다. core.autocrlf의 현재 설정에 해당하지 않는 경우 git은 파일을 거부합니다 .
변수는 "warn"으로 설정 될 수 있습니다.이 경우 git은 되돌릴 수없는 변환에 대해서만 경고하고 작업을 계속합니다.CRLF 변환은 약간의 데이터 손상 가능성이 있습니다.
활성화되면 git은 커밋 중에 CRLF를 LF로, 체크 아웃 중에 LF를 CRLF로 변환합니다.
커밋 전에 LF와 CRLF가 혼합 된 파일은 git로 다시 만들 수 없습니다 .
텍스트 파일의 경우 이것이 옳은 일입니다. 저장소에 LF 줄 끝만 있도록 줄 끝을 수정합니다.
그러나 실수로 텍스트로 분류 된 바이너리 파일의 경우 변환으로 인해 데이터가 손상 될 수 있습니다 .이러한 손상을 조기에 인식 한 경우에서 명시 적으로 변환 유형을 설정하여 쉽게 수정할 수 있습니다
.gitattributes
.
커밋 한 직후 작업 트리에 원본 파일이 남아 있으며이 파일은 아직 손상되지 않았습니다. 이 파일이 바이너리이고 git이 파일을 적절하게 처리 할 것임을 명시 적으로 git에 알릴 수 있습니다.안타깝게도 줄 끝이 혼합 된 텍스트 파일 정리의 원하는 효과와 바이너리 파일 손상의 원하지 않는 효과를 구분할 수 없습니다.
두 경우 모두 CRLF는 되돌릴 수없는 방식으로 제거됩니다. 텍스트 파일의 경우 CRLF가 줄 끝이고 바이너리 파일의 경우 CRLF를 변환하면 데이터가 손상되기 때문에 올바른 작업입니다.
나는 .gitattributes
파일로만 eol을 강제하고 ( core.eol
당신이 가지고있는 설정으로) 정확한 파일 또는 파일 유형을 식별하고 autocrlf
false로 두는 것을 선호합니다 .
eol이 혼합 된 텍스트 파일의 경우이 블로그 게시물 은 예를 들어 다음을 제안합니다.
컴퓨터에 Notepad ++가 설치되어있는 경우 다음 단계를 따르십시오.
- 치명적인 문제가있는 파일을 엽니 다.
- 클릭
Edit -> EOL Conversion
한 다음 Windows 형식을 선택하거나 커밋하는 데 문제가있는 항목을 선택합니다.
에 도입 된 회귀 : 당신이 망할 놈의 2.17 또는 2.18있는 경우, 경고 8462ff4는 ( " convert_to_git()
: safe_crlf/checksafe
이된다 int conv_flags
", 2018년 1월 13일, 힘내 2.17.0) 힘내 다시는 2.17주기 인한 autocrlf
재 작성하면 경고 메시지를 생성하는 설정에도 불구하고safecrlf=false
.
Anthony Sottile ( )의 commit 6cb0912 (2018 년 6 월 4 일)를 참조하십시오 . (Merged by Junio C Hamano -- in commit 8063ff9 , 28 Jun 2018)asottile
gitster
git config --global core.safecrlf false
이것은 crlf 치명적인 경고를 비활성화합니다.
git config core.autocrlf false
git config core.safecrlf false
저장소는 비공개이므로 다음 git-config
과 같이 설정할 수 있습니다 .
git config --global core.autocrlf false
더 궁금한 점이 있으면 《Pro git》을 읽을 수 있습니다 .
Windows 전용 프로젝트를 수행하는 Windows 프로그래머라면 이 기능을 끄고 config 값을 false 로 설정하여 저장소에 캐리지 리턴을 기록 할 수 있습니다 .
$ git config --global core.autocrlf false
그러나 공동 작업 할 때는 아래에서 더 잘 수행해야합니다.
- add
.gitattributes
, Github help-Dealing with line endings will be helpful. git config --global core.safecrlf true
-
- windows:
git config --global core.autocrlf true
- mac or linux:
git config --global core.autocrlf input
- windows:
You may want to Read Git docs-git config for more info.
git config --global core.autocrlf false
will checkin files with CRLF, that is not used to.
I've noticed on Windows, that with core.autocrlf true
git doesn't like files with LF and core.autocrlf input
doesn't like CRLF.
So: commit CRLF files with core.autocrlf true
and LF files with core.autocrlf input
(or convert them to CRLF).
Usually files with LF is autogenerated by code generators (e.g. https://start.spring.io or http://yeoman.io/)
With .gitattributes file, use
*.h text=auto
*.cpp text=auto
*.txt text=auto
as is documented in https://git-scm.com/docs/gitattributes.
'Programing' 카테고리의 다른 글
applyBindings에서 Knockout 발생 클릭 바인딩 (0) | 2020.12.12 |
---|---|
Golang의 웹 서버가 동시 요청을 처리하지 않는 이유는 무엇입니까? (0) | 2020.12.12 |
매우 큰 'n'에 대한 n 번째 피보나치 수 찾기 (0) | 2020.12.11 |
브라우저 닫기 이벤트 감지 시도 (0) | 2020.12.11 |
차이점 ?? (0) | 2020.12.11 |