‘git status’는 변경된 파일을 보여 주지만 ‘git diff’는 그렇지 않습니다 서버 (Git 1.8.1이 설치된 Solaris)에서

나는 비슷한 질문을 모두 보았습니다. 그러나, 나는 두 번 확인했고 이상한 일이 분명히 일어나고 있습니다.

한 서버 (Git 1.8.1이 설치된 Solaris)에서 Git 리포지토리를 복제 한 다음 .git 폴더를 기존 라이브 파일로 복사했습니다. 이 완벽하게 작동, 나는 실행할 수 있습니다

git status

그때

git diff [filename]

다른 파일을 확인하십시오.

다른 서버 (Git 1.7.6이 설치된 Solaris)에서 나는 정확히 똑같은 일을하고 있습니다.

git diff [filename]

파일 내용이 확실히 다르더라도 아무것도 표시하지 않습니다. 또한 새 파일 추가, 커밋 및 편집을 테스트했습니다. 같은 문제로 git status파일이 변경된 것으로 git diff표시 되지만 아무것도 표시되지 않습니다. 변경된 파일을 다운로드하고 로컬에서 diff를 실행하면 diff 출력이 표시됩니다.



답변

파일을 색인에 추가했습니다 .

git add file_name

그런 다음 실행했습니다.

git diff --cached file_name

여기서 git diff에 대한 설명을 볼 수 있습니다 .

git add를 취소 해야하는 경우 여기를 참조하십시오 : 커밋하기 전에 ‘git add’를 취소하는 방법은 무엇입니까?


답변

git status차이를 보일 git diff수 있지만 그렇지 않을 수 있는 몇 가지 이유 가 있습니다 .

  • 파일의 모드 (권한 비트)가 예를 들어 777에서 700으로 변경되었습니다.

  • 줄 바꿈 스타일이 CRLF (DOS)에서 LF (UNIX)로 변경되었습니다.

어떤 일이 git format-patch HEAD^발생했는지 확인하는 가장 쉬운 방법 은 생성 된 패치의 내용을 확인하고 실행 하는 것입니다.


답변

나에게는 파일 권한과 관련이 있습니다. 내 프로젝트에 Mac / Linux를 가진 사람이 Windows git 클라이언트가 재현하지 못한 기본 권한이 아닌 일부 파일을 커밋하는 것 같습니다. 나를위한 해결책은 git에게 파일 권한을 무시하도록 지시하는 것이 었습니다.

git config core.fileMode false

다른 통찰력 : Git이 파일 모드 (chmod) 변경을 무시하도록하려면 어떻게합니까?


답변

일부 프로그램에서 수백 줄 끝이 수정 git diff되어 모든 소스 파일이 변경된 것으로 나열 되는 문제가있었습니다 . 줄 끝 git status을 수정 한 후에도 여전히 파일을 수정 된 것으로 나열했습니다.

모든 파일을 색인에 추가 한 다음 색인을 재설정하여이 문제를 해결할 수있었습니다.

git add -A
git reset

core.filemode 거짓으로 설정되었습니다.


답변

Git 설치 또는 저장소에 문제가 있다고 생각합니다.

달리기를 시도하십시오.

GIT_TRACE=2 git <command>

유용한 정보가 있는지 확인하십시오. 그래도 도움이되지 않으면 strace를 사용하여 무엇이 잘못되었는지 확인하십시오.

strace git <command>

답변

나는 비슷한 문제가 있었다 : git diff차이점을 보여주지 만 git diff <filename>그렇지 않다. ( )을 LESS포함한 문자열로 설정 한 것으로 나타났습니다 . 해당 플래그를 제거하면 문제가 해결되었습니다.-F--quit-if-one-screen


답변

이전 답변 에서 이미 언급 했듯이이 상황은 줄 끝 문제 (CR / LF 대 LF)로 인해 발생할 수 있습니다. 이 명령 으로이 문제 (Git 버전 2.22.0에서)를 해결했습니다.

git add --renormalize .

매뉴얼에 따르면 :

       --renormalize
           Apply the "clean" process freshly to all tracked files to
           forcibly add them again to the index. This is useful after
           changing core.autocrlf configuration or the text attribute in
           order to correct files added with wrong CRLF/LF line endings.
           This option implies -u.