2013-07-09 6 views
3

나는 repo가 ​​커질 때 git가 느려질 것이라는 것을 알고있다.
하지만 왜?
git는 파일을 .git에 별도의 디렉토리 및 파일로 저장하기 때문에 작업이 왜 느려지는지 알 수 없습니다. 작업을 보겠습니다. 최근에, 나는 webkit repo와 master로부터 브랜치를 복제했다. 그리고 나는 2k 브랜치에 파일을 커밋한다. 그러나 나는 그것이 나의 작은 레포에서하는 것보다 느린 것을 느낀다.
git 소스 코드를 읽지 않았기 때문에 커밋 작업이 디스크에 파일 저장, 커밋 로그 삽입, 인덱스 업데이트 및 HEAD을 파일의 sha 값으로 업데이트하는 것으로 생각됩니다.왜 repo가 ​​커지면 git 작업이 느려지 는가

쓰기가 빠릅니다.
삽입이 빠릅니다. (삽입 작업이 파일에 로그를 추가하는 경우)
업데이트 색인이 빠릅니다.
업데이트 HEAD가 빠릅니다.

왜 느린가요? 아무에게도 설명해 줄 수 있습니까?
감사합니다.

일부 답변은 도움이되지만 아주 설득력이 떨어지며,이를 지원할 수있는 몇 가지 코드 스 니펫을 제공하는 것이 좋습니다.

답변

4

트리를 커밋하는 작업은 새로운 커밋 개체 (git write-tree)를 만들고 HEAD ref를 업데이트하기 만하면되므로 시간이 일정해야합니다.

내가 과거에 다른 SCM들의 벤치 마크를하고 git commit이 실제로 커밋 ID 이후 등

+0

나무 크기, 저장소 크기, 역사의 길이에 의해 영향을받지 않았다 그것의 SHA-1은 현재의 repo 스냅 샷입니다 일정 시간 일 수 없다. – Tordek

+3

커밋 ID는 커밋 개체 콘텐츠의 SHA1입니다. 내용은 상위 커밋 SHA1 해시, 트리의 해시 ('git add' 중에 생성됨) 및 커밋 메시지 텍스트를 포함합니다. 미치지 않게 긴 커밋 메시지가 없으면 중요하지 않습니다. – knittl

+0

나는 본다. 'add '연산을하는 동안 여전히 전체 트리를 해쉬하고있는 것이다. 원래의 대답이 명시 적으로이 단계를 피하지 않는 한, 여전히 관련성이 있어야합니다. – Tordek

관련 문제