Git (Hub)는 짧은 SHA에서 발생할 수 있는 충돌 처리

Git (Hub)는 짧은 SHA에서 발생할 수있는 충돌을 어떻게 처리합니까?

---

Git과 GitHub는 모두 40 개가 아닌 처음 7자인 SHA의 짧은 버전을 표시하며 Git과 GitHub 모두 이러한 짧은 SHA를 인수로 사용하는 것을 지원합니다.

예 git show 962a9e8

예 : https://github.com/joyent/node/commit/962a9e8

가능성 공간이 이제 2 억 6,800 만 "단"몇 배 더 낮다는 점을 감안할 때 Git과 GitHub는 여기서 충돌을 어떻게 방지할까요? 그리고 그들은 어떻게 처리합니까?

---

이러한 짧은 형식은 시각적 인식을 단순화하고 삶을 더 쉽게 만들기위한 것 입니다. Git은 실제로 아무것도 자르지 않으며 내부적으로 모든 것이 완전한 값으로 처리됩니다. 하지만 편의에 따라 부분 SHA-1을 사용할 수 있습니다.

Git은 부분 SHA-1이 4 자 이상이고 모호하지 않은 한 처음 몇 문자를 제공하면 입력하려는 커밋을 파악할 수있을만큼 똑똑합니다. 즉, 현재 저장소에서 하나의 객체 만 다음으로 시작합니다. 그 부분적인 SHA-1.

---

ID가있는 커밋이있는 저장소가 있습니다 000182eacf99cde27d5916aa415921924b82972c.

git show 00018

개정판을 보여 주지만

git show 0001

인쇄물

error: short SHA1 0001 is ambiguous.
error: short SHA1 0001 is ambiguous.
fatal: ambiguous argument '0001': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

(궁금하신다면 git 저장소의 복제본입니다. 그 커밋은 Linus Torvalds가 2005 년에 만든 커밋입니다.)

---

여기에 두 가지 메모 :

• y커밋을 표시하는 GitHub 페이지의 아무 곳에 나 입력 하면 해당 커밋의 전체 40 바이트가 표시됩니다.
  이것은 emboss 의 요점을 보여줍니다 : GitHub는 아무것도 자르지 않습니다.

• 2010 년 이후로 7 자리 16 진수 (28 비트)로는 충분하지 않습니다. Linus Torwalds 자신이 작성한 commit dce9648
  참조 (2010 년 10 월, git 1.7.4.4) :

기본값 7은 7 개의 16 진수 숫자가 많았던 git 개발 초기 (약 2 억 5 천만 개 이상의 해시 값 포함)에서 비롯됩니다. 그 당시 나는 65k 개정이 많았고 (우리가 BK에서하려고했던 것이 었습니다), 각 개정은 약 5-10 개의 새로운 객체 인 경향이 있으므로 백만 개의 객체가 큰 숫자라고 생각했습니다.

(BK = BitKeeper)

요즘 커널은 가장 큰 git 프로젝트도 아니고, 심지어 커널에도 약 220k 개정 ( BK 트리보다 훨씬 큼 )이 있으며 우리는 2 백만 개의 객체에 접근하고 있습니다. 그 시점에서 7 개의 16 진수는 여전히 많은 숫자에 대해 고유하지만 객체 수와 해시 크기 사이의 크기 차이가 2 배에 불과 하면 잘린 해시 값에 충돌이 발생합니다. 더 이상 비현실적에 가깝지 않습니다. 항상 발생합니다.

우리는 모두 비현실적으로 작았 기본 약칭을 증가해야 하고 사람들이 자식 설정 파일에 당 프로젝트 자신의 기본값을 설정할 수있는 방법을 추가 할 수 있습니다.

참조 URL : https://stackoverflow.com/questions/7128444/how-does-github-handle-possible-collisions-from-short-shas