Pourquoi git utilise-t-il des hachages au lieu des numéros de révision?

Je me suis toujours demandé pourquoi Git préférait le hachage aux numéros de révision. Les numéros de révision sont beaucoup plus clairs et plus faciles à consulter (à mon avis): il y a une différence entre dire à quelqu'un de regarder la révision 1200 ou de commettre 92ba93e! (Juste pour donner un exemple).

Alors, y a-t-il une raison pour cette conception?

Un numéro de révision unique et croissant de façon monotone n'a de sens que pour un système de contrôle de version centralisé, dans lequel toutes les révisions sont transmises à un seul endroit pouvant suivre et attribuer des numéros. Une fois que vous entrez dans le monde DVCS, où de nombreuses copies du référentiel existent et où des modifications sont extraites et insérées dans des flux de travail arbitraires, le concept ne s'applique tout simplement pas. (Par exemple, il n’existe pas d’endroit unique pour attribuer des numéros de révision. Si je modifie votre référentiel et que vous décidez un an plus tard d’extraire mes modifications, comment un système peut-il garantir que nos numéros de révision ne sont pas en conflit?)

Vous avez besoin de hachages dans un système distribué. Supposons que vous et un collègue travaillez tous les deux sur le même référentiel et que vous validez un changement localement, puis que vous le poussez. Qui est le numéro de révision 1200 et qui est le numéro de révision 1201 si aucune des parties ne se connaît mutuellement? La seule solution technique réaliste consiste à créer un hachage des modifications à l'aide d'une méthode connue et à relier les éléments en conséquence.

Fait intéressant, HG prend en charge les numéros de version, mais ils sont explicitement réservés aux utilisateurs locaux. Votre référentiel a un jeu. Le référentiel de votre collègue aura un jeu différent en fonction de la manière dont ils ont été poussés et extraits. Cela rend l’utilisation de la ligne de commande un peu plus conviviale que Git.

Intégrité des données.

Je suis respectueusement en désaccord avec les réponses actuelles. Les hachages ne sont pas nécessaires pour un DVCS, voir la méthode Bazaar . Vous pouvez également utiliser n'importe quel autre identifiant global unique. Les hachages sont une mesure permettant de garantir l’intégrité des données: ils représentent un condensé des informations contenues dans l’objet (commit, arbres, ...) référencés par le hachage. Modifier le contenu sans altérer le hachage (c.-à-d. Une attaque par pré-image ou une attaque par collision ) est considéré comme difficile, bien que pas impossible. (Si vous y tenez vraiment, jetez un coup d'œil au papier de Marc Stevens publié en 2011 ).

Par conséquent, la référence aux objets par leur hachage SHA permet de vérifier si le contenu a été altéré. Et, étant donné qu'ils sont (presque) garantis d'être uniques, ils peuvent également être utilisés en tant qu'identificateurs de révision.

Voir le chapitre 9 du livre Git pour plus de détails.

En termes simples:

• Les hachages sont destinés à être presque universellement uniques. Ce n'est PAS garanti, mais il est extrêmement improbable que les mêmes SHA soient générés pour un contenu différent. En termes pratiques pour un projet donné, vous pouvez le considérer comme unique.
• Avec les numéros de révision, vous devez utiliser un espace de noms pour pouvoir vous reporter spécifiquement à la révision 1200.
• Git peut travailler à la fois distribué et / ou centralisé. Alors, comment obtenir des numéros de révision corrects et uniques?
• De plus, l'utilisation de numéros de révision créerait une fausse interprétation selon laquelle les révisions les plus récentes devraient avoir des nombres plus élevés, ce qui ne serait pas le cas en raison de la création de branches, de la fusion, du changement de base, etc.
• Vous avez toujours la possibilité de mettre des balises sur les commits.

En termes mathématiques:

• Une commande totale sur les commits de Git serait nécessaire pour que le nombre de versions augmente de façon monotone.
• Les commits de Git forment un graphe acyclique dirigé (DAG) qui ne peut être ordonné que partiellement / topologiquement .

Hash n'est pas la solution unique pour VCS distribué. Mais lorsque vous travaillez avec un système distribué, seul un classement partiel des événements peut être enregistré. (Pour VCS, l'événement peut être une validation.) C'est pourquoi il est impossible de conserver un numéro de révision croissant de manière monotone. Habituellement, nous adoptons quelque chose comme une horloge vectorielle (ou timestamp vectoriel) pour enregistrer une telle relation d'ordre partiel. C'est la solution utilisée à Bazaar .

Mais pourquoi Git n'utilise pas d'horloge vectorielle mais de hachage? Je pense que la cause fondamentale est le choix des cerises . Lorsque nous effectuons un tri sélectif sur un référentiel, la commande partielle des commits est en train de changer. Certaines horloges vectorielles de commits doivent être réaffectées pour représenter le nouvel ordre partiel. Cependant, une telle réaffectation dans un système distribué induirait des horloges vectorielles incohérentes. C’est le vrai problème qui se pose avec les hashes.