Git의 손상된 파일

최근에 다음 명령을 사용하여 git repos 기록에서 일부 폴더를 제거했습니다.

git filter-branch --index-filter 'git rm -r --cached var' -- --all

불행히도이 repos에서 더 이상 가져올 수 없습니다. 이것은 내가 얻는 오류 세트입니다.

git pull
remote: Counting objects: 3953, done.
remote: Compressing objects: 100% (2810/2810), done.
error: garbage at end of loose object '4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0'
fatal: object 4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0 is corrupted
fatal: index-pack failed

어떤 종류의 영혼 이 자동으로 (그리고 더 철저하게) 이것을 수행 하는 스크립트 를 작성 했지만 복구 프로세스는 기본적으로 다음과 같습니다.

1. 16 진 덤프와 함께 가비지를보고하는 파일을 검사하십시오.

   $ hexdump .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
   

   넓은 범위의 0이있는 파일의 일부를 찾고 있습니다. 그러한 범위가 여러 개인 경우 작은 제로가 아닌 데이터가 포함 된 경우에도 첫 번째 거대한 제로 세트를 고려할 때 운이 좋았습니다 (N = 2). 이것은 자식이 불평하는 "쓰레기"입니다.

   ...
   0000500 0532 0302 0000 0000 0000 0000 0000 0000    # <-- Beginning here...
   0000510 0000 0000 0000 0000 0000 0000 0000 0000
   *
   0001000             # ... almost 3kb of zeros.
   

   이로부터 객체 의 실제 크기를 결정할 수 있습니다 . 여기서는 0x504 또는 1,284 바이트입니다.

2. 오브젝트의 백업 사본을 작성하십시오. 잘못된 제로 세트를 선택한 경우 다른 세트로 다시 시도 할 수 있습니다.

   $ cp .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0 ~/old_4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
   

3. 파일을 적절한 길이로 자릅니다.

   $ truncate -s 1284 .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
   

손상된 개체가 수정되었습니다. 그것이 유일하다고 가정하면, 리포지토리의 복제 / 푸시 / 풀링은 이제 예상대로 작동합니다.

내 출처를 인용하면 동일한 문제가 발생했지만 우분투 10.4 (커널 2.6.32-23- 일반)를 사용한다고 생각합니다. 이 경우 아직 추적되지 않은 파일 시스템 버그입니다. 이 주제 에 대한 ecryptfs 및 관련 유즈넷 스레드 에 대한 공개 문제가 있습니다 . 솔루션으로가는 동안 StackOverflow에 대한 편리한 답변과 요약 을 찾았습니다 . 링크 된 기사는 내가 궁극적으로 다른 길을 갔다하지만, 매우 흥미로웠다.