자식 필터 분기로 줄 끝을 수정하려고하지만 운이 없습니다.

git의 Windows / Linux 줄 끝 문제에 물 렸습니다. GitHub, MSysGit 및 기타 소스를 통해 가장 좋은 해결책은 로컬 repos가 Linux 스타일 줄 끝을 사용하도록 설정하지만로 설정 core.autocrlf하는 것 같습니다 true. 불행히도, 나는 이것을 조기에 충분히하지 않았으므로 이제는 변경 사항을 가져올 때마다 줄 끝이 지워집니다.

나는 여기서 대답을 찾았다 고 생각 했지만 나에게 도움이되지는 못한다. 내 Linux 명령 줄 지식은 기껏해야 제한되어 있으므로 "xargs fromdos"줄이 그의 스크립트에서 무엇을하는지 잘 모르겠습니다. 해당 파일이나 디렉토리가 존재하지 않는다는 메시지가 계속 표시되고 기존 디렉토리를 가리킬 때 권한이 없음을 알려줍니다.

Windows의 MSysGit과 Mac OS X 터미널을 통해이 작업을 시도했습니다.

gitattributes에 대한 자식 문서는 이제 프로젝트의 모든 줄 끝을 "고정"하거나 정규화하는 또 다른 접근 방식을 문서화합니다. 다음은 요점입니다.

$ echo "* text=auto" >.gitattributes
$ git add --renormalize .
$ git status        # Show files that will be normalized
$ git commit -m "Introduce end-of-line normalization"

정규화되지 않아야하는 파일이 git 상태로 표시되면 git add -u를 실행하기 전에 해당 텍스트 속성을 설정 해제하십시오.

manual.pdf -text

반대로 git이 감지하지 못하는 텍스트 파일은 정규화를 수동으로 활성화 할 수 있습니다.

weirdchars.txt text

이것은 --renormalize2018 년 1 월에 출시 된 git v2.16.0에 추가 된 새로운 플래그를 활용합니다. 이전 버전의 git에는 몇 가지 단계가 더 있습니다.

$ echo "* text=auto" >>.gitattributes
$ rm .git/index     # Remove the index to force git to
$ git reset         # re-scan the working directory
$ git status        # Show files that will be normalized
$ git add -u
$ git add .gitattributes
$ git commit -m "Introduce end-of-line normalization"

이 문제를 해결하는 가장 쉬운 방법은 모든 줄 끝을 수정하는 하나의 커밋을 만드는 것입니다. 수정 된 파일이 없다고 가정하면 다음과 같이 할 수 있습니다.

# From the root of your repository remove everything from the index
git rm --cached -r .

# Change the autocrlf setting of the repository (you may want 
#  to use true on windows):
git config core.autocrlf input

# Re-add all the deleted files to the index
# (You should get lots of messages like:
#   warning: CRLF will be replaced by LF in <file>.)
git diff --cached --name-only -z | xargs -0 git add

# Commit
git commit -m "Fixed crlf issue"

# If you're doing this on a Unix/Mac OSX clone then optionally remove
# the working tree and re-check everything out with the correct line endings.
git ls-files -z | xargs -0 rm
git checkout .

줄 끝을 처리하는 나의 절차는 다음과 같습니다 (많은 repos에서 전투 테스트)

새로운 저장소를 만들 때 :

• 넣어 .gitattributes에 매우 첫째, 다른 일반적인 같은 파일과 함께 커밋 .gitignore및README.md

기존 리포지토리를 처리 할 때 :

• .gitattributes그에 따라 생성 / 수정
• git commit -a -m "Modified gitattributes"
• git rm --cached -r . && git reset --hard && git commit -a -m 'Normalize CRLF' -n"
  • -n( --no-verify미리 커밋 후크를 건너 뛰는 것입니다)
  • 별칭으로 정의하기에 충분할 정도로 자주 수행해야합니다. alias fixCRLF="..."
• 이전 명령을 반복
  • 그렇습니다. 부두교이지만 일반적으로 명령을 두 번 실행해야합니다. 처음에는 일부 파일을 정규화 할 때, 두 번째로 더 많은 파일을 처리해야합니다. 일반적으로 새로운 커밋이 생성되지 않을 때까지 반복하는 것이 가장 좋습니다. :)
• 이전 (정규화 직전)과 새 분기간에 몇 번 앞뒤로 이동합니다. 브랜치를 전환 한 후 때때로 git은 재 정규화해야하는 더 많은 파일을 찾을 수 있습니다!

에서 .gitattributes내가 LF EOL있는 것으로 명시 적으로 모든 텍스트 파일을 선언 하기 때문에 일반적으로 윈도우 도구는 Windows 이외의 도구가 CRLF와 호환되지 않습니다 동안 LF와 호환 (심지어 많은 nodejs이 줄 도구가 LF를 가정하고 따라서 파일의 EOL을 변경할 수 있습니다 명령).

내용 .gitattributes

내 .gitattributes보통은 다음과 같습니다

*.html eol=lf
*.js   eol=lf
*.json eol=lf
*.less eol=lf
*.md   eol=lf
*.svg  eol=lf
*.xml  eol=lf

현재 리포지토리에서 git이 추적하는 고유 한 확장을 확인하려면 여기를 참조하십시오.

정규화 후 문제

이 작업이 끝나면 일반적인 경고가 하나 더 있습니다.

귀하 master가 이미 최신 상태이고 정규화되었다고 확인한 다음 체크 아웃하십시오 outdated-branch. 그 지점을 체크 아웃 한 직후에 git은 많은 파일을 수정 된 것으로 표시합니다.

해결책은 가짜 커밋 ( git add -A . && git commit -m 'fake commit') 을 수행하는 것 git rebase master입니다. 리베이스가 끝나면 가짜 커밋이 사라집니다.

git status --short|grep "^ *M"|awk '{print $2}'|xargs fromdos

설명:

• git status --short

  이것은 git이 알고 있고 모르는 각 줄을 표시합니다. git 제어가없는 파일은 줄의 시작 부분에 '?'로 표시됩니다. 수정 된 파일은 M으로 표시됩니다.

• grep "^ *M"

  수정 된 파일 만 필터링합니다.

• awk '{print $2}'

  마커가없는 파일 이름 만 표시합니다.

• xargs fromdos

  이전 명령에서 파일 이름을 가져 와서 줄 끝을 변환하기 위해 'fromdos'유틸리티를 통해 파일 이름을 실행합니다.

다음을 사용하여 전체 기록에서 모든 줄 끝을 수정하는 방법은 다음과 같습니다 git filter-branch. ^M문자를 사용하여 입력 할 필요가 CTRL-V+를 CTRL-M. dos2unix바이너리 파일을 자동으로 건너 뛰기 때문에 파일을 변환하는 데 사용 했습니다.

$ git filter-branch --tree-filter 'grep -IUrl "^M" | xargs -I {} dos2unix "{}"'

"| xargs fromdos"는 표준 입력 (파일이 find찾은 것)을 읽어 명령의 인수 fromdos로 사용하여 줄 끝을 변환합니다. (그러한 환경의 표준은 있습니까? dos2unix에 익숙합니다). xargs 사용을 피할 수 있습니다 (특히 인수 목록이 xargs에 대해 너무 긴 파일이 충분한 경우에 유용합니다).

find <path, tests...> -exec fromdos '{}' \;

또는

find <path, tests...> | while read file; do fromdos $file; done

오류 메시지가 확실하지 않습니다. 이 방법을 성공적으로 테스트했습니다. 각각의 프로그램은 무엇입니까? 어떤 파일 / 디렉토리에 대한 권한이 없습니까? 그러나 여기에 무엇이 있는지 추측 할 수있는 방법이 있습니다.

스크립트에서 '파일을 찾을 수 없음'오류를 얻는 쉬운 방법 중 하나는 상대 경로를 사용하는 것입니다. 절대 경로를 사용하십시오. 마찬가지로 스크립트를 실행 가능하게하지 않으면 (chmod + x) 권한 오류가 발생할 수 있습니다.

의견을 추가하면 도움이 될 것입니다.

좋아 ... cygwin에서 우리는 쉽게 사용할 수있는 fromdo를 가지고 있지 않으며 수정 된 파일 (우리가 가진)의 경로에 공백이 있으면 awk substeb이 당신의 얼굴에 날아갑니다. 그래서 나는 약간 다르게해야했습니다.

git status --short | grep "^ *M" | sed 's/^ *M//' | xargs -n 1 dos2unix

이 솔루션의 대부분에 대한 @lloyd의 kudos

다른 답변이 도움이되지 않으면 다음 단계를 따르십시오.

1. Windows를 사용하는 경우 git config --global core.autocrlf true; 유닉스에 있다면git config core.autocrlf input
2. 운영 git rm --cached -r .
3. 파일 삭제 .gitattributes
4. 운영 git add -A
5. 운영 git reset --hard

그럼 당신의 지역은 지금 깨끗해야합니다.