Comment Git (Hub) gère-t-il les éventuelles collisions de SHA courts?

Question

Les deux Git et GitHub l'affichage de la version courte de la SHAs-juste les 7 premiers caractères au lieu de 40 -- et les deux Git et GitHub prise en charge de ces courtes SHAs comme arguments.

E. g. git show 962a9e8

E. g. https://github.com/joyent/node/commit/962a9e8

Étant donné que la possibilité de l'espace est maintenant ordres de grandeur plus faible, il "suffit" de 268 millions de dollars, comment Git et GitHub protéger contre les collisions ici? Et comment gèrent-ils entre eux?

Answer 1

Ces formes ne sont là que pour simplifier la reconnaissance visuelle et de rendre votre vie plus facile. Git n'a pas vraiment de tronquer quoi que ce soit, à l'interne, tout sera traitée avec la valeur complète. Vous pouvez utiliser une partielle SHA-1, à votre convenance, si:

Git est assez intelligent pour comprendre ce que commettre vous tapez si vous fournissez les premiers caractères, aussi longtemps que vos partielle SHA-1 est d'au moins quatre caractères et sans ambiguïté - qui est, un seul objet dans le référentiel actuel commence avec qu'une partie de l'algorithme SHA-1.

Answer 2

J'ai un référentiel qui a un commit avec un identifiant de 000182eacf99cde27d5916aa415921924b82972c .

 git show 00018
 

montre la révision, mais

 git show 0001
 

empreintes

 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
 

(Si vous êtes curieux, c'est un clone du référentiel git pour git lui-même; ce commit a été créé par Linus Torvalds en 2005.)

Answer 3

Deux remarques ici:

• Si vous tapez y n'importe où sur la page GitHub de l'affichage d'un commit, vous pourrez voir l'intégralité de 40 octets dit de s'engager.
  Qui illustre estampagepoint: GitHub ne pas tronquer quoi que ce soit.

• Et 7 bits n'est pas assez depuis 2010, de toute façon.
  Voir commettre dce9648 par Linus Torwalds lui-même (Oct 2010, git 1.7.4.4):

La valeur par défaut de 7 vient assez tôt dans git développement, lorsque sept chiffres hexadécimaux a beaucoup (elle s'étend sur près de 250 millions de valeurs de hachage). À l'époque, je pensais que 65k les révisions a beaucoup (c'est ce que nous avons été sur le point de frapper dans BK), et chaque révision tend à être d'environ 5 à 10 de nouveaux objets ou tellement, tellement d'un million d'objets a été un grand nombre.

(BK = BitKeeper)

Ces jours-ci, le noyau n'est même pas le plus grand projet git, et même le noyau a propos de 220k révisions (beaucoup plus grand que le BK arbre l'a jamais été) et que nous nous approchons de deux millions d'objets. À ce stade, de sept chiffres hex est encore unique pour beaucoup d'entre eux, mais quand nous sommes parler seulement de deux ordres de grandeur de différence entre le nombre d'objets et le hachage de taille, il va être collisions dans tronquée des valeurs de hachage. Il n'est même plus proche de irréalistes, il arrive tout le temps.

Il convient à la fois d'augmenter la valeur par défaut abrév qui était trop petite, et ajouter un moyen pour les personnes à créer leur propre défaut par projet dans le git fichier de configuration.