Note: you can ask git rev-parse --short pour obtenir le SHA1 le plus court et pourtant unique.
Voir "git obtenir un hachage court à partir d'un hachage régulier"
git rev-parse --short=4 921103db8259eb9de72f42db8b939895f5651489
92110
Comme vous pouvez le voir dans mon exemple, le SHA1 a une longueur de 5 même si j'ai spécifié une longueur de 4.
Pour les grands dépôts, 7 n'est pas suffisant depuis 2010, et commit dce9648 par Linus Torvalds lui-même (git 1.7.4.4, oct 2010) :
La valeur par défaut de 7 provient des premiers stades de développement de git, quand sept chiffres héxadécimaux représentait beaucoup (cela couvre environ 250+ millions de valeurs de hachage).
À l'époque, je pensais que 65k révisions étaient beaucoup (c'était ce que nous étions sur le point d'atteindre dans BK), et chaque révision tend à être d'environ 5-10 nouveaux objets environ, donc un million d'objets était un grand nombre.
(BK = BitKeeper)
De nos jours, le noyau n'est même pas le plus grand projet git, et même le noyau a environ 220k révisions (beaucoup plus grand que l'arbre BK n'a jamais été) et nous approchons de deux millions d'objets.
À ce stade, sept chiffres héxadécimaux sont encore uniques pour beaucoup d'entre eux, mais quand nous parlons d'une différence de seulement deux ordres de grandeur entre le nombre d'objets et la taille du hachage, il y aura des collisions dans les valeurs de hachage tronquées.
Ce n'est plus du tout irréaliste - cela arrive tout le temps.
Nous devrions à la fois augmenter l'abrégé par défaut qui était irréaliste petit, et ajouter un moyen pour les gens de définir leur propre valeur par défaut par projet dans le fichier de configuration de git.
core.abbrev
Définir la longueur à laquelle les noms des objets sont abrégés.
Si non spécifiée, de nombreuses commandes abrègent à 7 chiffres héxadécimaux, ce qui peut ne pas être suffisant pour que les noms d'objets abrégés restent uniques pendant suffisamment longtemps.
environment.c:
int minimum_abbrev = 4, default_abbrev = 7;
Note: Comme commenté ci-dessous par marco.m, core.abbrevLength a été renommé en core.abbrev dans ce même Git 1.7.4.4 dans commit a71f09f
Renommer core.abbrevlength en core.abbrev
Cela correspond à l'option en ligne de commande --abbrev=$n après tout.
Plus récemment, Linus a ajouté dans commit e6c587c (pour Git 2.11, T4 2016) :
(comme mentionné dans la réponse de Matthieu Moy ici)
Dans les premiers jours, nous avons décidé d'abréger les noms d'objets en 7 chiffres héxadécimaux, mais à mesure que les projets grandissent, il est de plus en plus probable de voir des noms d'objets aussi courts fabriqués dans les premiers jours et enregistrés dans les messages de journal ne sont plus uniques.
Actuellement, le projet du noyau Linux a besoin de 11 à 12 chiffres héxadécimaux, tandis que Git lui-même a besoin de 10 chiffres héxadécimaux pour identifier de manière unique les objets qu'ils possèdent, tandis que de nombreux projets plus petits peuvent encore être satisfaits par la valeur par défaut de 7 chiffres héxadécimaux originales. Une seule taille ne convient à tous les projets.
Introduire un mécanisme, où nous estimons le nombre d'objets dans le dépôt à la première demande d'abréviation d'un nom d'objet avec le réglage par défaut et définir une valeur par défaut raisonnable pour le dépôt. Basé sur l'idée que nous verrions des collisions dans un dépôt avec 2^(2N) objets en utilisant des noms d'objets raccourcis sur les premiers N bits, utiliser un nombre suffisant de chiffres héxadécimaux pour couvrir le nombre d'objets dans le dépôt.
Chaque chiffre héxadécimal (4 bits) que nous ajoutons au nom abrégé nous permet d'avoir quatre fois (2 bits) autant d'objets dans le dépôt.
Voir le commit e6c587c (01 Oct 2016) par Linus Torvalds (torvalds).
Voir commit 7b5b772, commit 65acfea (01 Oct 2016) par Junio C Hamano (gitster).
(Fusionné par Junio C Hamano -- gitster -- dans commit bb188d0, 03 Oct 2016)
Cette nouvelle propriété (deviner une valeur d'abrégé raisonnable pour les valeurs SHA1) a un effet direct sur la façon dont Git calcule sa propre numéro de version pour la publication.
