Comment git calcule-t-il les hachages de fichiers?

Les hachages SHA1 stockés dans les objets de l'arborescence (tels que renvoyés par git ls-tree) ne correspondent pas aux hachages SHA1 du contenu du fichier (tels que renvoyés par sha1sum)

$ git cat-file blob 4716ca912495c805b94a88ef6dc3fb4aff46bf3c | sha1sum
de20247992af0f949ae8df4fa9a37e4a03d7063e  -

Comment git calcule-t-il les hachages de fichiers? Compresse-t-il le contenu avant de calculer le hachage?

Git préfixe l'objet avec "blob", suivi de la longueur (comme un entier lisible par l'homme), suivi d'un caractère NUL

$ echo -e 'blob 14\0Hello, World!' | shasum 8ab686eafeb1f44702738c8b0f24f2567c36da6d

Source: http://alblue.bandlem.com/2011/08/git-tip-of-week-objects.html

Je ne fais que développer la réponse @Leif Gruenwoldtet détailler ce qui se trouve dans la référence fournie par@Leif Gruenwoldt

Fais le toi-même..

• Étape 1. Créez un document texte vide (le nom n'a pas d'importance) dans votre référentiel
• Étape 2. Mettre en scène et valider le document
• Étape 3. Identifiez le hachage de l'objet blob en exécutant git ls-tree HEAD
• Étape 4. Recherchez le hachage de l'objet blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
• Étape 5. Sortez de votre surprise et lisez ci-dessous

Comment GIT calcule ses hachages de commit

    Commit Hash (SHA1) = SHA1("blob " + <size_of_file> + "\0" + <contents_of_file>)

Le texte blob⎵est un préfixe constant et \0est également constant et est le NULLcaractère. Les <size_of_file>et <contents_of_file>varient en fonction du fichier.

Voir: Quel est le format de fichier d'un objet git commit?

Et c'est tout le monde!

Mais attendez! , avez-vous remarqué que le <filename>n'est pas un paramètre utilisé pour le calcul de hachage? Deux fichiers peuvent potentiellement avoir le même hachage si leur contenu est le même indépendamment de la date et de l'heure de création et de leur nom. C'est l'une des raisons pour lesquelles Git gère mieux les déplacements et les renomme que les autres systèmes de contrôle de version.

Faites-le vous-même (Ext)

• Étape 6. Créez un autre fichier vide avec un autre filenamedans le même répertoire
• Étape 7. Comparez les hachages de vos deux fichiers.

Remarque:

Le lien ne mentionne pas comment l' treeobjet est haché. Je ne suis pas certain de l'algorithme et des paramètres, mais d'après mon observation, il calcule probablement un hachage basé sur tous les blobset trees(leurs hachages probablement) qu'il contient

git hash-object

C'est un moyen rapide de vérifier votre méthode de test:

s='abc'
printf "$s" | git hash-object --stdin
printf "blob $(printf "$s" | wc -c)\0$s" | sha1sum

Production:

f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f
f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f  -

où sha1sumest dans GNU Coreutils.

Ensuite, il s'agit de comprendre le format de chaque type d'objet. Nous avons déjà couvert le trivial blob, voici les autres:

• commit: Quel est le format de fichier d'un objet git commit?
• tree: Quel est le format interne d'un objet git tree?
• tag: Comment un objet tag Git SHA1 est-il créé?

Basé sur la réponse de Leif Gruenwoldt , voici un substitut de la fonction shell à git hash-object:

git-hash-object () { # substitute when the `git` command is not available
    local type=blob
    [ "$1" = "-t" ] && shift && type=$1 && shift
    # depending on eol/autocrlf settings, you may want to substitute CRLFs by LFs
    # by using `perl -pe 's/\r$//g'` instead of `cat` in the next 2 commands
    local size=$(cat $1 | wc -c | sed 's/ .*$//')
    ( echo -en "$type $size\0"; cat "$1" ) | sha1sum | sed 's/ .*$//'
}

Tester:

$ echo 'Hello, World!' > test.txt
$ git hash-object test.txt
8ab686eafeb1f44702738c8b0f24f2567c36da6d
$ git-hash-object test.txt
8ab686eafeb1f44702738c8b0f24f2567c36da6d

J'en avais besoin pour certains tests unitaires dans Python 3, alors j'ai pensé le laisser ici.

def git_blob_hash(data):
    if isinstance(data, str):
        data = data.encode()
    data = b'blob ' + str(len(data)).encode() + b'\0' + data
    h = hashlib.sha1()
    h.update(data)
    return h.hexdigest()

Je m'en tiens aux \nfins de ligne partout, mais dans certaines circonstances, Git peut également changer vos fins de ligne avant de calculer ce hachage, vous pouvez donc en avoir besoin .replace('\r\n', '\n').