Czy binarny algorytm diff git (delta storage) jest ustandaryzowany?

Myślę, że diff algo używany dla pack files był powiązany z jednym z delta encoding tam: początkowo (2005) xdelta , a następnie libXDiff.
Ale potem, jak szczegółowo poniżej, przeniósł się do niestandardowej realizacji.

W każdym razie, jak wspomniano tutaj :

Git usuwa tylko w plikach packfiles.
Ale po wciśnięciu przez SSH git wygeneruje plik pack z commitami druga strona nie mają, a te paczki są cienkie, więc mają też delty... ale zdalna strona dodaje bazy do tych cienkich paczek, czyniąc je samodzielnymi.

(uwaga: tworzenie wielu plików packfile, lub pobieranie informacji w ogromnych plikach packfile jest kosztowne , i wyjaśnia dlaczego git nie radzi sobie dobrze z ogromnymi plikami lub ogromnymi repo.
Zobacz więcej w " git z dużymi plikami")

Ten wątek przypomina nam również:

Faktycznie packfiles i deltification (LibXDiff, a nie xdelta) było, z tego co pamiętam i Rozumiem, pierwotnie ze względu na przepustowość sieci (która jest znacznie droższa niż miejsce na dysku), i wydajność I/O użycia pojedynczego pliku mmapped zamiast bardzo dużej liczby luźnych obiektów.

LibXDiff jest wspomniany w tym 2008 wątku.

Jednak od tego czasu algo ewoluowało, prawdopodobnie w niestandardowym, jak ten 2011 wątek ilustruje, a jako nagłówek diff-delta.c wyróżnia się:

Tak więc, ściśle mówiąc, obecny kod w Git nie przypomina w ogóle kodu libxdiff.
Jednak podstawowy algorytm stojący za obydwoma implementacjami jest taki sam .
Studiowanie wersji libxdiff jest prawdopodobnie łatwiejsze, aby zrozumieć, jak to działa.

/*
 * diff-delta.c: generate a delta between two buffers
 *
 * This code was greatly inspired by parts of LibXDiff from Davide Libenzi
 * http://www.xmailserver.org/xdiff-lib.html
 *
 * Rewritten for GIT by Nicolas Pitre <[email protected]>, (C) 2005-2007
 */

Więcej o packfiles the Git Book :

Git 2.18 dodaje do opisu delty w nowej sekcji dokumentacja , która obecnie (II kwartał 2018) stwierdza:

Typy obiektów

Poprawne typy obiektów to:

• OBJ_COMMIT (1)
• OBJ_TREE (2)
• OBJ_BLOB (3)
• OBJ_TAG (4)
• OBJ_OFS_DELTA (6)
• OBJ_REF_DELTA (7)

Typ 5 jest zarezerwowany dla przyszłej rozbudowy. Typ 0 jest nieprawidłowy.

Reprezentacja Deltyfikowana

Koncepcyjnie istnieją tylko cztery typy obiektów: commit, tree, tag i blob.
jednak aby zaoszczędzić miejsce, obiekt może być przechowywany jako" delta" kolejny obiekt "bazowy".
Reprezentacje te mają przypisane nowe typy s-delta i ref-delta, które są ważne tylko w pliku pack.

Zarówno ofs-delta jak i ref-delta przechowują "deltę", która ma być zastosowana do inny obiekt (zwany "obiektem bazowym") do rekonstrukcji obiektu.
Różnica między nimi wynosi,

• ref-delta bezpośrednio koduje 20-bajtową nazwę obiektu bazowego.
  • jeśli obiekt bazowy znajduje się w tym samym pakiecie, ofs-delta koduje przesunięcie obiektu bazowego w pakiecie.

Obiekt bazowy może być również deltyfikowany, jeśli znajduje się w tym samym opakowaniu.
Ref-delta może również odnosić się do obiektu spoza pakietu (tj. tak zwane "cienkie opakowanie") . W przypadku przechowywania na dysku należy jednak być samodzielnym, aby uniknąć cyklicznego zależność.

Dane delta to sekwencja instrukcji do rekonstrukcji obiektu z obiektu podstawowego.
Jeśli obiekt bazowy jest deltyfikowany, musi być najpierw przekonwertowany do postaci kanonicznej. Każda instrukcja dołącza coraz więcej danych do obiektu docelowego, dopóki nie zostanie ukończona.
Do tej pory istnieją dwie obsługiwane instrukcje:

• jeden do kopiowania zakresu bajtów z obiektu źródłowego i
• jeden do wstawiania nowych danych osadzonych w Instrukcja sama w sobie.

Każda instrukcja ma zmienną długość. Określa się Typ instrukcji do siódmego bitu pierwszego oktetu. Następujące diagramy Konwencja w RFC 1951 (Deflate compressed data format).