복제 된 원격 저장소의 일부 마크 다운 파일을 편집하고 있으며 한 분기에서 다른 분기로 패치 생성 및 적용을 테스트하고 싶었습니다. 그러나 변경을 할 때마다 다음 메시지가 표시됩니다 git apply.
0001-b.patch:16: trailing whitespace.
warning: 1 line adds whitespace errors.
(이것은 내 Mac에서 발생하며 원본 코드가 생성 된 위치를 모릅니다.)
경고 메시지는 무엇을 의미하며주의해야합니까?
답변
신경 쓸 필요가 없습니다.
이 경고는 많은 프로그래머가 관심을 갖는 유형 인 공백과 관련하여 텍스트 파일의 청결 표준을 제정합니다. 로 매뉴얼을 설명합니다 :
공백 오류로 간주되는 것은 core.whitespace 구성에 의해 제어됩니다. 기본적으로 후행 공백 (공백으로 만 구성된 행 포함)과 행의 첫 들여 쓰기 내에서 바로 뒤에 탭 문자가 오는 공백 문자는 공백 오류로 간주됩니다.
기본적으로이 명령은 경고 메시지를 출력하지만 패치를 적용합니다.
따라서 “오류”는 변경으로 인해 후행 공백, 공백 전용 줄 또는 탭 앞에 공백이 있음을 의미합니다. 그 외에는 변경 사항에 오류가 없으며 깨끗하고 올바르게 적용됩니다. 즉, “잘못된”공백에 대해 신경 쓰지 않는 경우 경고를 무시하거나를 사용하여 해제 할 수 git config apply.whitespace nowarn있습니다.
답변
합법적으로주의 할 수있는 한 가지 경우는 “오래된”whitespase 오류 (레거시 이유로 유지하고 싶을 수 있음)와 “새로운”공백 오류 (피하고 싶은)를 구분하려는 경우입니다.
이를 위해 Git 2.5+ (2015 년 2 분기)는 공백 감지를위한보다 구체적인 옵션을 제안 할 것입니다.
참조는 0e383e1 커밋 , 0ad782f 및 d55ef3e 에 의해 [2015 5월 26일] Junio C 하마노을 ( gitster) .
( 2015 년 6 월 11 일 커밋 709cd91 에서 Junio 에 의해 병합 됨 )
diff.c:--ws-error-highlight=<kind>옵션전통적으로 우리는 새 줄에 도입 된 공백 파손에만 신경을 썼습니다.
어떤 사람들은 오래된 줄에도 공백을 칠하고 싶어합니다. 새 줄에서 공백이 깨지는 것을 볼 때 해당 이전 줄에서 동일한 종류의 공백이 깨지는 것을 발견하고 “아, 그 깨지는 부분이 있지만 원본에서 상속되었으므로 만지지 말자. 지금.”소개
--ws-error-highlight=<kind>그들을 쉼표 구분 된 목록에 합격 할 수 있다는 옵션을old,new그리고context에 공백 하이라이트에 오류가 어떤 선을 지정할 수 있습니다.
--ws-error-highlight=<kind>
에 지정된
<kind>색상으로 지정된 행의 공백 오류를 강조 표시 합니다color.diff.whitespace.
<kind>콤마 분리 된리스트는old,new,context.
이 옵션을 지정하지 않으면new줄의 공백 오류 만 강조 표시됩니다.예를 들어
--ws-error-highlight=new,old삭제 및 추가 된 줄 모두에서 공백 오류를 강조 표시합니다.
all의 약어로 사용할 수 있습니다old,new,context.
예를 들어, 이전 커밋에는 공백 오류 ( bbb) 가 하나 있었지만 새 오류에만 집중할 수 있습니다 ( still bbb및 끝에 있음 ccc).
(이후에 수행 된 테스트 t/t4015-diff-whitespace.sh)
Git 2.26 (2020 년 1 분기)에서는 diff-*배관 하위 명령 계열이 diff.wsErrorHighlight이전에 무시되었던 구성에 주의를 기울입니다 . 이를 통해 ” git add -p“은 (는) 최종 사용자에게 공백 문제를 표시 할 수도 있습니다.
Jeff King ( )의 commit da80635 (2020 년 1 월 31 일)를 참조하십시오 . (Merged by Junio C Hamano — in commit df04a31 , 14 Feb 2020)peff
gitster
diff: diff.wsErrorHighlight를 “기본”구성으로 이동서명자 : Jeff King
에서 diff.wsErrorHighlight를 구문 분석합니다
git_diff_ui_config(). 즉, 배관 명령에는 적용되지 않고git diff자체 와 같은 도자기에만 적용 됩니다.
이것은add--interactive사용자가 볼 수있는 색상 차이를 생성 하는와 같은 스크립트 가 옵션을 존중하지 않음을 의미하므로 약간 성가신 일입니다 .우리는 그 스크립트가 설정을 파싱
--ws-error-highlight하고 diff plumbing에 전달하도록 가르 칠 수 있습니다. 그러나 더 간단한 해결책이 있습니다.색상이 활성화 된 경우에만 시작되므로 배관이이 옵션을 존중하는 것이 합리적으로 안전해야합니다. 색상 화 된 출력을 파싱하는 사람은 누구나
color.diff.*자신이 보는 정확한 출력을 변경할 수 있다는 사실을 이미 처리해야합니다 . 이러한 옵션은 9a1805a872 ( “기본”diff 구성 콜백, 2008-01-04, Git v1.5.4-rc3 추가)git_diff_basic_config()에서 처음부터 일부가되었습니다 .따라서
add--interactive배관 사용자에게 피해를 줄 위험이 매우 낮은 동일한 보트의 다른 스크립트와 함께을 수정하는 “기본”구성으로 이동할 수 있습니다 .
답변
시각적 이미지의 공백 오류가 여기에 표시됩니다.
http://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines
답변
라인 TAB이 SPACE. 패치 파일로 이동 TAB하여 SPACE. 예를 들어 vim on line + 패치 파일 유형 x에서 공백을 제거하고 부호 +를 제거하지 않고 eqiv의 공백 (CTRL)을 원래 크기로 삽입합니다.
답변
