Comment Git (Hub) gère-t-il les collisions possibles avec les SHA courts?

Git et GitHub affichent tous deux des versions courtes des SHA – seulement les 7 premiers caractères au lieu de tous les 40 – et Git et GitHub prennent tous deux en charge ces arguments SHA courts.

Ex. git show 962a9e8

Par exemple: https://github.com/joyent/node/commit/962a9e8

Étant donné que l’espace de possibilité est maintenant beaucoup plus faible, “juste” 268 millions , comment Git et GitHub protègent-ils contre les collisions ici? Et comment les traitent-ils?

Ces formes courtes ne sont que pour simplifier la reconnaissance visuelle et vous faciliter la vie. Git ne tronque pas vraiment quoi que ce soit, en interne tout sera traité avec la valeur complète. Vous pouvez utiliser un SHA-1 partiel à votre convenance, bien que:

Git est assez intelligent pour déterminer ce que vous vouliez taper si vous fournissez les premiers caractères, à condition que votre SHA-1 soit au moins quatre caractères de long et sans ambiguïté, c’est-à-dire qu’un seul object du référentiel actuel commence par ce SHA-1 partiel.

J’ai un repository qui a un commit avec un identifiant de 000182eacf99cde27d5916aa415921924b82972c .

 git show 00018 

montre la révision, mais

 git show 0001 

estampes

 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 repository git pour git lui-même, celui-ci est celui de Linus Torvalds en 2005.)

Deux notes ici:

  • Si vous tapez y n’importe où sur la page GitHub affichant un commit, vous verrez les 40 octets complets de ce commit.
    Cela illustre le point en relief: GitHub ne tronque rien.

  • Et 7 chiffres hexadécimaux (28 bits) ne suffisent plus depuis 2010.
    Voir commettre dce9648 par Linus Torwalds lui-même (oct 2010, git 1.7.4.4):

La valeur par défaut de 7 provient assez tôt du développement de git, lorsque sept chiffres hexadécimaux étaient nombreux (cela couvre environ 250 millions de valeurs de hachage). À l’époque, je pensais que les révisions de 65k étaient beaucoup (c’était ce que nous étions sur le sharepoint bash en BK), et chaque révision était d’environ 5-10 nouveaux objects, donc un million d’objects était un grand nombre.

(BK = BitKeeper)

De nos jours, le kernel n’est même pas le plus gros projet git, et même le kernel a environ 220 000 révisions ( bien plus que le BK) et nous approchons de deux millions d’objects. À ce stade, sept chiffres hexadécimaux sont encore uniques pour beaucoup d’entre eux, mais lorsque nous parlons d’une différence de deux ordres de grandeur entre le nombre d’objects et la taille de hachage, il y aura des collisions dans les valeurs de hachage tronquées. Ce n’est même plus proche de l’irréalisme – cela arrive tout le temps.

Nous devrions tous deux augmenter l’abréviation par défaut qui était irréaliste et append un moyen pour que les gens définissent leur propre projet par défaut dans le fichier de configuration git.