programing tip

git : 매달려있는 얼룩

itbloger 2020. 12. 5. 09:23
반응형

git : 매달려있는 얼룩


최근 git fsck --lost-found에 내 저장소에서 실행 했습니다.

나는 내가 재설정 한 몇 가지 매달린 커밋을 볼 것으로 예상했다 HEAD.

그러나 수천 개가 넘는 dangling blob 메시지를 볼 수 있다는 사실에 놀랐습니다.

내 저장소에 문제가 있다고 생각하지 않지만 이러한 매달려있는 얼룩의 원인이 무엇인지 궁금합니다. 저장소에서 작업하는 사람은 두 명 뿐이며 우리는 평범한 일을 한 적이 없습니다.

git이 기록을 표시 할 수 있도록 두 blob을 모두 보유해야하기 때문에 이전 버전의 파일이 새 파일로 대체되어 생성되었다고 생각하지 않습니다.

생각해 보면 실수로 아주 큰 디렉토리 (수천 개의 파일)를 프로젝트에 추가 한 다음 제거했습니다. 이것이 모든 매달려있는 얼룩의 근원일까요?

이 미스터리에 대한 통찰력을 찾고 있습니다.


지난번 에이 스레드 , 특히이 부분을 ​​발견했습니다.

팩에 매달려있는 물체로 끝날 수도 있습니다. 해당 팩이 재 포장되면 해당 개체는 풀린 다음 위에 언급 된 규칙에 따라 결국 만료됩니다. 그러나 gc가 항상 오래된 팩을 다시 포장하지는 않는다고 생각합니다. 많은 팩을 가질 때까지 새 팩을 만든 다음 모두 결합합니다 (적어도 "gc --auto"가 수행하는 작업입니다. "git gc"만 동일한 규칙을 따르는 지 기억 나지 않습니다).

그래서 그것은 정상적인 행동이며 결국 수집됩니다.

편집 : Daniel에 따라 다음을 실행하여 즉시 수집 할 수 있습니다.

git gc --prune="0 days"

나는 정말 참을성이 없었고 사용했습니다.

git gc --prune="0 days"

add인덱스에 파일을 추가 할 때마다 해당 파일의 콘텐츠가 Git의 개체 데이터베이스에 Blob으로 추가됩니다. 그런 다음 reset/ rm --cached해당 파일을 사용하면 blob이 계속 존재합니다 (다음에 실행할 때 가비지 수집 됨 gc).

그러나 이러한 파일이 커밋의 일부이고 나중에 reset히스토리로 결정 하면 이전 커밋은 여전히 ​​Git의 리플 로그에서 도달 할 수 있으며 일정 기간 (일반적으로 한 달, iirc) 후에 만 ​​가비지 수집됩니다. 이러한 객체는 여전히 reflog에서 참조되므로 매달린 것으로 표시되지 않아야합니다.

참고 URL : https://stackoverflow.com/questions/9955713/git-dangling-blobs

반응형