W jaki sposób git oblicza skróty plików?

Skróty SHA1 przechowywane w obiektach drzewa (zwrócone przez git ls-tree) nie pasują do skrótów SHA1 zawartości pliku (zwróconych przez sha1sum)

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

W jaki sposób git oblicza skróty plików? Czy kompresuje zawartość przed obliczeniem skrótu?

Git poprzedza obiekt ciągiem „blob”, po którym następuje długość (jako czytelna dla człowieka liczba całkowita), po której następuje znak NUL

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

Źródło: http://alblue.bandlem.com/2011/08/git-tip-of-week-objects.html

Rozszerzam tylko odpowiedź @Leif Gruenwoldti szczegółowo opisuję, co jest w referencji dostarczonej przez@Leif Gruenwoldt

Zrób to sam..

• Krok 1. Utwórz pusty dokument tekstowy (nazwa nie ma znaczenia) w swoim repozytorium
• Krok 2. Przygotuj i zatwierdź dokument
• Krok 3. Zidentyfikuj skrót obiektu BLOB, wykonując git ls-tree HEAD
• Krok 4. Znajdź hash obiektu blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
• Krok 5. Wyrwij się z zaskoczenia i przeczytaj poniżej

Jak GIT oblicza skróty zatwierdzeń

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

Tekst blob⎵jest stałym przedrostkiem, a \0także jest stały i jest NULLznakiem. <size_of_file>I <contents_of_file>różnią się w zależności od pliku.

Zobacz: Jaki jest format pliku obiektu git commit?

I to wszystko ludzie!

Ale poczekaj! , czy zauważyłeś, że <filename>parametr nie jest używany do obliczenia skrótu? Dwa pliki mogą potencjalnie mieć ten sam skrót, jeśli ich zawartość jest taka sama, niezależnie od daty i godziny ich utworzenia oraz nazwy. Jest to jeden z powodów, dla których Git radzi sobie z przenoszeniem i zmianą nazw lepiej niż inne systemy kontroli wersji.

Zrób to sam (rozszerzenie)

• Krok 6. Utwórz kolejny pusty plik z innym filenamew tym samym katalogu
• Krok 7. Porównaj skróty obu plików.

Uwaga:

Odnośnik nie wspomina o tym, jak treeobiekt jest zahaszowany. Nie jestem pewien algorytmu i parametrów, ale z moich obserwacji prawdopodobnie wylicza hash na podstawie wszystkich blobsi trees(prawdopodobnie ich hashów), które zawiera

git hash-object

To szybki sposób na zweryfikowanie metody testowej:

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

Wynik:

f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f
f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f  -

gdzie sha1sumjest w GNU Coreutils.

Następnie sprowadza się do zrozumienia formatu każdego typu obiektu. Już omówiliśmy trywialne blob, oto inne:

• commit: Jaki jest format pliku obiektu git commit?
• tree: Jaki jest format wewnętrzny obiektu drzewa git?
• tag: W jaki sposób tworzony jest obiekt znacznika Git SHA1?

Opierając się na odpowiedzi Leifa Gruenwoldta , oto substytut funkcji powłoki 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/ .*$//'
}

Test:

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

Potrzebowałem tego do niektórych testów jednostkowych w Pythonie 3, więc pomyślałem, że zostawię to tutaj.

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()

\nWszędzie trzymam się końcówek linii, ale w niektórych okolicznościach Git może również zmieniać zakończenia linii przed obliczeniem tego skrótu, więc możesz .replace('\r\n', '\n')tam również potrzebować .