Wprowadzono wydanie rozproszonego systemu zarządzania kodem źródłowym Git 2.54. 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 zmiany „wstecz”, wykorzystuje się ukryte haszowanie całej poprzedniej historii w każdym commicie, a także uwierzytelnianie cyfrowymi podpisami deweloperów poszczególnych tagów i commitów. Kod Git jest rozpowszechniany na licencji GPLv2+.
W porównaniu do poprzedniego wydania, nowa wersja zawiera 770 zmian, przygotowanych przez 137 deweloperów (66 z nich po raz pierwszy wzięło udział w rozwoju Gita). Główne nowości:
- Zrealizowano polecenie „git history”, które oferuje eksperymentalne możliwości przepisania historii zmian, łatwiejsze i bezpieczniejsze w użyciu niż rebase commitów za pomocą polecenia „git rebase”. Oferowane są dwie operacje:
- „git history reword ” do przepisania wiadomości w wskazanym commicie bez zmiany roboczej kopii i indeksu (z wyjątkiem adnotacji, reszta pozostaje nietknięta). Na przykład, w celu poprawy literówki.
- „git history split ” do interaktywnego podziału wskazanego commita na dwa różne commity z przeniesieniem wybranych części z oryginalnego commita do dodatkowego commita.
W przyszłych wydaniach planowane jest dodanie dodatkowych poleceń: „git history fixup” do poprawy commita, „git history drop” do usunięcia commita, „git history reorder” do zmiany kolejności commitów oraz „git history squash” do scalania commitów.
- Zrealizowano nową metodę definiowania handlerów (hook) w plikach konfiguracyjnych. Zamiast umieszczania skryptów z handlerami w katalogu „.git/hooks” w każdym repozytorium, komendy do wywołania handlerów można teraz definiować bezpośrednio w plikach konfiguracyjnych. Ustawienia można przypisywać do repozytoriów lub wskazywać w plikach konfiguracyjnych, które obowiązują dla wszystkich repozytoriów (/etc/gitconfig) lub repozytoriów użytkownika (~/.gitconfig). Możliwe jest przypisanie kilku handlerów do jednego zdarzenia. Skrypty z „.git/hooks” nadal są wywoływane, ale uruchamiane po handlerach z plików konfiguracyjnych. Aby wyświetlić listę handlerów, należy użyć komendy „git hook list”, a aby selektywnie wyłączyć wywołanie handlerów — ustawienie „hook..enabled = false”. [hook „linter”] event = pre-commit command = ~/bin/linter —cpp20 [hook „no-leaks”] event = pre-commit command = ~/bin/leak-detector $ git hook list pre-commit global linter ~/bin/linter —cpp20 local no-leaks ~/bin/leak-detector
- W komendzie „git maintenance” domyślnie wykorzystywana jest strategia „geometric” („git config set maintenance.strategy geometric”), która pozwala skrócić czas konserwacji dużych monorepozytoriów. W porównaniu do wcześniej stosowanej strategii, która wykorzystywała logikę jak w komendzie „git gc”, nowa strategia unika przeupakowania wszystkich obiektów i wyklucza nadmiernie zasobożerne operacje, takie jak łączenie wszystkich plików pakietów (po możliwym łączeniu dokonywanym częściami bez oczyszczania usuniętych obiektów).
- Baza danych obiektów (ODB) oraz związane z nią API zostały przeniesione na nową architekturę opartą na użyciu wtykowych backendów. Przeprowadzona restrukturyzacja abstrahuje format przechowywania obiektów i w przyszłości pozwoli wdrożyć takie możliwości, jak alternatywne backendy i formaty obiektów, na przykład do bardziej efektywnego przechowywania dużych plików binarnych lub do optymalizacji działania dużych git-hostingów.
- W zespole „git repo structure”, wyświetlającym informacje o strukturze repozytorium, zapewniono pokazanie nie tylko całkowitego rozmiaru, ale także największych obiektów każdego typu, co pozwala ocenić rozmiar bez użycia zewnętrznego narzędzia git-sizer. $ git repo structure … | * Największe obiekty | | | * Commity | | | * Maksymalny rozmiar [1] | 17,23 KiB | | * Maksymalna liczba rodziców [2] | 10 | | * Drzewa | | | * Maksymalny rozmiar [3] | 58,85 KiB | | * Maksymalna liczba wpisów [4] | 1,18 k | | * Bloby | | | * Maksymalny rozmiar [5] | 1019,51 KiB | | * Tagi | | | * Maksymalny rozmiar [6] | 7,13 KiB |
- W zespole „git replay”, stosowanym zamiast „git rebase” do odtwarzania historii w serwerze bez roboczego drzewa, domyślnie włączono atomowe aktualizacje referencji (zamiast wyświetlania listy poleceń update-ref do ręcznego wykonania), wprowadzono opcję „—revert” do cofania zmian z serii commitów, a także zapewniono odrzucanie wynikowych pustych commitów oraz możliwość odtwarzania historii aż do korzennego commita.
- Do „git rev-list” i podobnych poleceń dodano opcję „—maximal-only” do pokazywania tylko commitów, które nie są osiągalne przez inne commity.
- Do zespołu „git repo info” dodano opcję „—keys” do wyświetlania listy wszystkich znanych kluczy.
- W zespole „git add -p” w trakcie nawigacji między blokami kodu za pomocą klawiszy „J” i „K” zapewniono oznaczanie już zatwierdzonych i pominiętych bloków. Dodano opcję „—no-auto-advance” do wyłączenia automatycznego przechodzenia do następnego pliku, aby mieć możliwość powrotu do wcześniejszych plików przed commitem.
- Przeprowadzono optymalizację interfejsu webowego „gitweb” do pracy na urządzeniach mobilnych.
- W zespole „git apply —directory” przed użyciem zapewniono normalizację ścieżek plików, takich jak „./un/../normalized/path”.
- Udokumentowano możliwość dodawania własnych podkomend przez umieszczanie plików „git-<cmd>” w katalogu z plikami wykonywalnymi.
- Do zespołu „git send-email” dodano wsparcie dla certyfikatów klienckich.
- Dla zespołu „git status” wdrożono ustawienie „status.compareBranches”, dzięki któremu można określić gałęzie, z którymi będzie przeprowadzane porównanie bieżącej gałęzi. [status] compareBranches = @{upstream} @{push}
- W „git rebase” dodano opcję „—trailer” do uproszczenia dodawania metadanych do wszystkich commitów. git rebase —trailer „Reviewed-by: Test <test@example.com>”
- Do zespołu „git fast-import” dodano możliwość zamiany podpisów dla commitów, które stały się nieważne po imporcie.
- Dodano wsparcie dla pakowania (compaction) wielopakietowych indeksów MIDX (multi-pack index), w którym drobne warstwy indeksu MIDX z informacjami o dostępności obiektów są łączone z powiązanymi plikami bitmap, co pozwala zmniejszyć liczbę warstw gromadzących się w od dawna istniejących repozytoriach.
- W poleceniu „git backfill” wprowadzono możliwość wskazywania rewizji (zakresów commitów) oraz masek ścieżek (pathspec) w celu ograniczenia ładowanych części historii zmian. git backfill main~100..main git backfill — ‘*.c’
- Dodano alternatywne formy wywołania polecenia „git config list” — „git config -l” i „git config —list”.
- Zezwolono na użycie znaków nie-ASCII w nazwach aliasów poleceń określanych w pliku konfiguracyjnym. [alias „pobierz”] command = fetch
- Zmieniono sposób wyświetlania podpisów, dla których wygasły klucze GPG, ale które były ważne w momencie podpisania commita. Takie podpisy są teraz wyświetlane jako poprawne z adnotacją o wygaśnięciu klucza (wcześniej były podświetlane na czerwono, co sugerowało ich niepoprawność).
- Podczas korzystania z repozytoriów przez HTTP zapewniono obsługę błędu z kodem 429 (Too Many Requests). Zapytania zakończone takim błędem są teraz traktowane nie jako problem krytyczny, lecz jako błąd tymczasowy, który należy ponowić po pewnym czasie. Opóźnienie przed ponownym wysłaniem określa opcja „http.retryAfter”, liczba prób — „http.maxRetries”, czas oczekiwania — „http.maxRetryTime”.
Źródło: opennet.ru
