Po dwóch miesiącach prac deweloperskich został zaprezentowany wydanie rozproszonego systemu zarządzania kodem źródłowym Git 2.51. Git wyróżnia się wysoką wydajnością i oferuje narzędzia do nieliniowego rozwoju oparte na gałęzieniu i scalaniu. Aby zapewnić integralność historii i odporność na tzw. "zmiany wsteczne", wykorzystywane jest niejawne haszowanie całej poprzedniej historii w każdym commicie, a także uwierzytelnienie cyfrowymi podpisami deweloperów poszczególnych tagów i commitów. Kod Git jest dystrybuowany na licencji GPLv2+.
W porównaniu do poprzedniego wydania do nowej wersji wprowadzono 506 zmian, przygotowanych przy udziale 91 dewelopera (21 z nich po raz pierwszy wzięło udział w rozwoju Git). Główne nowości (1, 2, 3):
- Zwiększono wydajność poleceń „git push” i „git fetch” w repozytoriach z dużą liczbą odniesień. Przyspieszenie osiągnięto dzięki aktualizacji odniesień w trybie pakietowym, w którym w jednej transakcji przetwarzanych jest kilka odniesień, zamiast tworzenia osobnej transakcji dla aktualizacji każdego odniesienia. Optymalizacja znacznie zwiększyła wydajność backendu „reftable”, który teraz przewyższa wydajność backendu „files”. Na przykład w testowym repozytorium z 10 tysiącami odniesień wydajność „git fetch” przy użyciu backendu „reftable” wzrosła 22 razy, a przy użyciu backendu „files” — 1,25 razy. Dla „git push” wzrost wyniósł odpowiednio 18 i 1,21 raza.
- Proponowana jest nowa metoda pakowania w plikach pack części repozytoriów, które nie są związane ze śledzeniem niedostępnych obiektów, do których w repozytorium brak odniesień (które nie są powiązane z gałęziami lub tagami). Informacje o niedostępnych obiektach są przechowywane w osobnych plikach pack („cruft packs”), co prowadziło do konieczności ich odzwierciedlenia w wielu pakietowych indeksach MIDX (multi-pack index), aby objąć obiekty, które początkowo były niedostępne i przechowywane tylko w cruft-packu, ale stały się dostępne po referencyjnym commitcie.
W nowej wersji przy repakowaniu plików pack zapewniono zachowanie dodatkowych kopii osiągalnych obiektów, przechowywanych tylko w plikach cruft. Takie zmiany gwarantują, że w zestawie plików pack, używanych do przechowywania osiągalnych obiektów, nie znajdują się obiekty, które odnoszą się do innych obiektów przechowywanych poza tym zestawem. Aby wykluczyć niedostępne zawartości plików cruft z indeksów wieloplikowych (MIDX), wprowadzono ustawienie „repack.MIDXMustContainCruft”, które znacznie redukuje rozmiar takich indeksów. Włączenie tego ustawienia w repozytorium GitHub pozwoliło na zredukowanie rozmiaru indeksów MIDX o 38%, przyspieszenie zapisu w indeksach MIDX o 35% i zwiększenie wydajności odczytu o 5%.
- Do komendy „git pack-objects” dodano opcję „—path-walk”, która włącza nową metodę zbierania informacji o obiektach podczas repakowania plików pack. Zamiast przechodzić przez obiekty w porządku rewizji, w trybie „—path-walk” obiekty są iterowane przez ścieżki plików, co pozwala na jednoczesne pakowanie wszystkich obiektów mających tę samą ścieżkę pliku. Takie podejście pozwala na wyeliminowanie heurystyki, wykorzystującej haszowanie do określenia związku obiektu z jego ścieżką pliku, oraz pozbycie się sortowania obiektów przed pakowaniem. W trybie „—path-walk” rozmiar generowanych plików pack jest znacznie mniejszy niż przy grupowaniu obiektów za pomocą haszy.
- Określono format wymiany zapisanych stanów roboczej gałęzi i indeksów w repozytorium, tworzone przy pomocy komendy „git stash”. Nowy format umożliwia kodowanie zapisanych zmian (zapisy stash) w postaci sekwencji commitów. Do importu i eksportu zaproponowano podkomendy „git stash import” i „git stash export”, które można wykorzystać do przenoszenia zapisanych stanów z jednego systemu do drugiego oraz wykonywania operacji push lub pull z tymi stanami jak z normalnymi gałęziami lub tagami. git stash export —to-ref refs/stashes/my-stash git push origin refs/stashes/my-stash … git fetch origin ‘+refs/stashes/*:refs/stashes/*’ git stash import refs/stashes/my-stash
- W zespole „git cat-file”, który wyświetla zawartość określonych obiektów, zrealizowano możliwość wyświetlania informacji o brakujących obiektach (na przykład z powodu uszkodzenia repozytorium) i submodułach, przy użyciu opcji „—batch” i „—batch-check”. Wcześniej, przy podaniu ścieżki do submodułu, polecenie „git cat-file —batch-check” zwracało „missing”, a teraz pokaże identyfikator obiektu.
- W poleceniu „git log” zastosowano optymalizacje oparte na filtrach Blooma w celu przyspieszenia wyszukiwania w historii zmian przy użyciu filtrów z wieloma ścieżkami plików, na przykład „git log — path/to/a path/to/b”.
- Ustalono stabilność poleceń „git switch” i „git restore”, które od 2019 roku były traktowane jako eksperymentalne. Polecenia są przedstawiane jako nowoczesne odpowiedniki „git checkout”, oddzielające takie mało powiązane możliwości tej komendy, jak manipulacja gałęziami (przełączanie się i tworzenie) oraz przywracanie plików w katalogu roboczym.
- Zostało ogłoszone jako przestarzałe i planowane do usunięcia w gałęzi Git 3.0 polecenie „git whatchanged”, równoważne z „git log —raw”.
- Do polecenia „git for-each-ref” dodano opcję „—start-after”, która może być używana wraz z opcją „—count” do organizacji stronicowego wyjścia.
- Do poleceń „git merge” i „git pull” dodano opcję „—compact-summary” do wykorzystania skompaktowanego formatu podsumowania zmian zamiast formatu diffstat.
- W bazie kodu Git zezwolono na użycie słowa kluczowego „bool”, które pojawiło się w standardzie C99. Udokumentowano również niektóre możliwości C99, eksperymentalnie używane w Git (na przykład w połowie 2026 roku planowane jest zezwolenie na stosowanie konstrukcji „(struct foo){ .member = value };”). Kompilator z obsługą C99 jest obowiązkowy dla Git od 2021 roku, jednak możliwości specyfikacji C99 wprowadzane są wyjątkowo ostrożnie, aby zachować zgodność z kompilatorami, które tylko częściowo wspierają ten standard.
- W zasadach przyjmowania patchy wprowadzono zmiany, które umożliwiają przesyłanie patchy pod pseudonimem, a nie tylko pod prawdziwym imieniem dewelopera. Zmiana ta odpowiada zasadom przyjmowania patchy do rdzenia Linux.
- Zaktualizowano listę zmian, które mogą wpływać na zgodność, które zostaną zastosowane w gałęzi Git 3.0. Wśród istotnych zmian w nadchodzącej wersji Git 3.0 zauważalne jest przejście na identyfikatory obiektów oparte na algorytmie haszowania SHA-256 w czasie inicjacji nowych repozytoriów oraz wykorzystanie formatu „reftable” do przechowywania linków do gałęzi i tagów w repozytorium (wykorzystano magazyn blokowy z projektu JGit, zoptymalizowany do przechowywania bardzo dużej liczby linków).
Źródło: opennet.ru
