편집하다:

편집하다:

git에서 구성 파일을 커밋하기 전에 필터를 사용하여 주석을 제거합니다.

$ cat .git/config
[filter "stripcomments"]
clean = "stripcomments"

$ cat .git/info/attributes 
/etc/* filter=stripcomments

커밋되지 않은 파일이 있으면 색상을 변경하는 쉘 프롬프트도 있습니다. 나에게 관련 부분은 다음과 같습니다 .zshrc.

[[ -n "$(git status --porcelain 2> /dev/null | tail -n1)" ]] && git_c=220 || git_c=34

내가 겪고 있는 문제는 주석을 추가하여 파일을 변경할 때 필터가 주석을 제거하고 git용 파일은 변경되지 않은 상태로 유지되어야 한다는 것입니다. 별 차이가 없음 을 확인할 수 있습니다 git diff. 그러나 git status파일이 변경되었음을 표시하므로 내 쉘에는 커밋되지 않은 변경 사항을 나타내는 노란색 프롬프트가 표시됩니다.

이 문제를 해결하려면 무엇을 사용해야 합니까?

편집하다:

더 나쁜 점은 이렇게 하면 git status수정된 파일이 표시된다는 것입니다. 이렇게 하면 git diff아무런 변화도 나타나지 않습니다. 이렇게 하면 git commit할 일이 없다는 메시지가 나타납니다.

즉, git status변경된 파일이 표시되지만 커밋할 수는 없습니다.

답변1

git status파일 크기를 변경하지 않고 주석을 변경하는 경우(예: 한 문자를 변경하거나 두 개의 단일 줄 주석을 사용하여 전환하는 경우) 전체 파일 길이나 필터링된 결과를 변경하지 않는 모든 항목은 예상대로 작동합니다.

동일한 크기의 수정된(mtime) 파일의 경우 git status해당 내용을 읽고 필터를 실행하고 비교합니다. 댓글 변경사항이 필터링되는 한 변경사항은 없습니다.

그러나 파일 크기가 다를 경우에는 git status필터가 전혀 실행되지 않으며 파일 내용도 조회되지 않습니다. 파일 크기만 변경해도 git status파일이 변경된 것으로 간주하기에 충분합니다.

파일 내용보다는 파일 크기를 비교하는 것이 일반적인 최적화입니다. 이 경우에는 좋지 않습니다. 그리고 끌 수 있는 옵션은 없는 것 같습니다.

core.checkStat = minimal거의 모든 기능을 비활성화하는 것이 있습니다와는 별개로파일 크기 확인. 그래서 막다른 골목입니다. 이 문제와 관련된 다른 옵션이 있으면 찾을 수 없습니다.

git status그래서 행동을 바꾸는 적절한 해결책이 없습니다 .

완전히 다른 명령으로 전환해야 할 수도 있습니다(실행 git diff? git commit --dry-run그렇지 않으면 실제로 커밋되지 않습니까?). 이러한 도구는 변경 사항을 비교/커밋하기 위해 실제로 파일 내용을 확인해야 하기 때문에 필터를 실행하고 아무 작업도 수행하지 않습니다. 그렇지 않으면 실행하여 git addgit에서 캐시 파일 크기를 업데이트하시겠습니까? (제출 관련 없음)

또 다른 (이상한) 옵션은 파일 크기 문제를 강제로 발생시키는 것입니다. 텍스트 파일의 경우 주석을 추가한 다음 항상 동일한 크기를 갖도록 파일을 자릅니다. 따라서 파일 크기는 절대 변경되지 않으며 git status파일 내용을 확인해야 합니다.

이는 git status귀하의 사용 사례에 적합하지만 실용적이지 않습니다.


보다 급진적인 접근 방식은 git자가 치유입니다.

diff --git a/read-cache.c b/read-cache.c
index 35e5657877..4e087ca3f5 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -213,7 +213,7 @@ int match_stat_data(const struct stat_data *sd, struct stat *st)
 #endif

        if (sd->sd_size != (unsigned int) st->st_size)
-               changed |= DATA_CHANGED;
+               changed |= MTIME_CHANGED;

        return changed;
 }

이는 크기 변경이 단지 시간 변경인 것처럼 가장합니다(그런 다음 나중에 파일 내용 비교를 시작합니다). 그러나 이는 로컬에서만 작동하며 매우 위험합니다. 결국 이 기능은 git 저장소의 무결성을 담당하므로 그러한 변경이 안전한지 여부를 간단히 알 수 없습니다.

이와 같은 작업을 수행하는 경우 이름을 Frankengit로 지정하고 저장소를 전혀 수정할 수 없는지 확인해야 합니다(적어도 --no-optional-locksstatus 명령에 추가).


9년 전에도 같은 질문이 제기되었습니다.

Git 메일링 리스트 토론:

분명히 아무것도 나오지 않았지만 이 기능에 관심이 있다면 어쨌든 메일링 리스트에 대해 다시 생각해봐야 합니다. 그렇지 않으면 9년 후에도 같은 문제가 계속 발생할 것입니다. ;-)

관련 정보