Po dwóch miesiącach prac nad rozwojem zaprezentowano wydanie rozproszonego systemu zarządzania tekstami źródłowymi Git 2.51. Git wyróżnia się wysoką wydajnością i oferuje narzędzia do nielinearnego rozwoju, oparte na gałęzieniu i scalaniu. Aby zapewnić integralność historii i odporność na zmiany „wstecz”, stosuje się niejawne haszowanie całej poprzedniej historii w każdym commitencie, a także cyfrowe podpisy, które potwierdzają poszczególne tagi i commity. Kod Git jest rozpowszechniany na licencji GPLv2+.
W porównaniu do poprzedniej wersji w nowej wersji wprowadzono 506 zmian, przygotowanych przez 91 dewelopera (21 z nich wzięło udział w rozwijaniu Git po raz pierwszy). Główne nowości (1, 2, 3):
- Zwiększona 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 jednocześnie kilka odniesień, zamiast tworzyć oddzielną transakcję dla aktualizacji każdej odniesienia. Optymalizacja znacząco 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” zysk wyniósł odpowiednio 18 i 1,21 razy.
- Zaproponowano nową metodę pakowania w plikach pack części repozytorium, które nie są związane z śledzeniem niedostępnych obiektów, na które w repozytorium brak odniesień (nie są powiązane żadnymi gałęziami ani tagami). Informacje o niedostępnych obiektach są przechowywane w osobnych plikach pack („cruft packs”), co prowadziło do konieczności ich odzwierciedlenia w wielopakietowych indeksach MIDX (multi-pack index), aby objąć obiekty, które pierwotnie były niedostępne i przechowywane tylko w cruft-paku, ale stały się dostępne po związanym z nimi commicie.
W nowej wersji przy ponownym pakowaniu 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 treści z indeksów wielopakietowych (MIDX) plików cruft, zaproponowano ustawienie „repack.MIDXMustContainCruft”, które pozwala znacznie zmniejszyć rozmiar takich indeksów. Włączenie tego ustawienia w repozytorium GitHub pozwoliło zmniejszyć rozmiar indeksów MIDX o 38%, przyspieszyć zapis do indeksów MIDX o 35% i poprawić wydajność odczytu o 5%.
- Do polecenia „git pack-objects” dodano opcję „—path-walk”, wprowadzającą nową metodę zbierania informacji o obiektach podczas ponownego pakowania plików pack. Zamiast przeszukiwać obiekty w kolejności rewizji, w trybie „—path-walk” obiekty są przeszukiwane poprzez ścieżki plików, co pozwala na jednoczesne pakowanie wszystkich obiektów z tą samą ścieżką pliku. Takie podejście pozwala wyeliminować heurystykę, która wykorzystuje haszowanie do określenia związku obiektu z jego ścieżką pliku, a także pozbyć 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 zachowanych stanów drzewa roboczego i indeksów w repozytorium, tworzonych za pomocą polecenia „git stash”. Nowy format umożliwia kodowanie zachowanych zmian (zapisy stash) jako sekwencji commitów. Do importu i eksportu zaproponowano podpolecenia „git stash import” oraz „git stash export”, które można wykorzystać do przenoszenia zachowanych stanów z jednego systemu na inny 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 poleceniu „git cat-file”, które wyświetla zawartość określonych obiektów, wprowadzono 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, w przypadku wskazania ś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 Bloom, aby przyspieszyć wyszukiwanie w historii zmian przy wskazaniu filtrów z wieloma ścieżkami do plików, na przykład „git log — path/to/a path/to/b”.
- Ustabilizowano polecenia „git switch” i „git restore”, które od 2019 roku były traktowane jako eksperymentalne. Polecenia te przedstawiane są jako nowoczesne odpowiedniki „git checkout”, rozdzielające takie mało powiązane możliwości tej komendy jak manipulacja gałęziami (przełączanie i tworzenie) oraz przywracanie plików w katalogu roboczym.
- Ogłoszono ostatecznie przestarzałe i planowane do usunięcia w gałęzi Git 3.0 polecenie „git whatchanged”, ekwiwalentne do „git log —raw”.
- Do polecenia „git for-each-ref” dodano opcję „—start-after”, która może być używana razem z opcją „—count” do organizacji paginacji wyników.
- Do poleceń „git merge” i „git pull” dodano opcję „—compact-summary”, aby stosować skompaktowany format 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. Dokumentowane są także niektóre możliwości C99, eksperymentalnie stosowane w Gicie (na przykład w połowie 2026 roku planowane jest zezwolenie na stosowanie konstrukcji „(struct foo){ .member = value };”). Kompilator obsługujący C99 jest obowiązkowy dla Gita od 2021 roku, ale możliwości specyfikacji C99 wprowadzane są bardzo ostrożnie, aby zachować zgodność z kompilatorami, które jedynie częściowo obsługują ten standard.
- Do zasad przyjmowania poprawek wprowadzono zmiany, które pozwalają na wysyłanie poprawek pod pseudonimem, a nie tylko pod prawdziwym imieniem dewelopera. Zmiana ta jest zgodna z zasadami przyjmowania poprawek do jądra Linux.
- Zaktualizowano listę niezgodnych zmian, które zostaną zastosowane w gałęzi Git 3.0. Wśród znaczących zmian w nadchodzącej wersji Git 3.0 zauważalny jest domyślny przejście na identyfikatory obiektów oparte na algorytmie haszowania SHA-256 podczas inicjalizacji nowych repozytoriów oraz wykorzystanie formatu „reftable” do przechowywania w repozytorium odniesień do gałęzi i tagów (wykorzystano magazyn blokowy z projektu JGit, zoptymalizowany do przechowywania bardzo dużej liczby odniesień).
Źródło: opennet.ru
