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
'programing tip' 카테고리의 다른 글
뛰어난 Common Lisp 코드의 예? (0) | 2020.12.05 |
---|---|
새로운 Backbone.Model () 대 Backbone.Model.extend () (0) | 2020.12.05 |
Swift Error : 자체 초기 값 내에서 사용되는 변수 (0) | 2020.12.05 |
애니메이터와 애니메이션의 차이점은 무엇입니까? (0) | 2020.12.05 |
conda environment.yml과 pip requirements.txt 결합 (0) | 2020.12.05 |