Git 2.54

Git 2.54

Przedstawiony wydanie systemu rozproszonego zarządzania kodem źródłowym Git 2.54. Git różni się wysoką wydajnością i zapewnia narzędzia do nieliniowego rozwoju, oparte na rozgałęzianiu i scalaniu gałęzi. Aby zapewnić integralność historii i odporność na zmiany „wstecz”, stosuje się niejawne haszowanie całej poprzedniej historii w każdym commicie oraz uwierzytelnianie cyfrowe podpisami deweloperów poszczególnych tagów i commitów. Kod Git rozpowszechniany na licencji GPLv2+.

W porównaniu do poprzedniego wydania w nowej wersji wprowadzono 770 zmian, przygotowanych przy udziale 137 deweloperów (66 po raz pierwszy wzięło udział w rozwoju Git).

Podstawowe nowości:

  • Wprowadzono polecenie „git history”, które oferuje eksperymentalne możliwości rewizji historii zmian, prostsze i bezpieczniejsze w użyciu, niż rebase commitów przez polecenie git rebase. Oferowane są dwie operacje:

    • git history reword do zmiany wiadomości w podanym commicie bez zmiany drzewa roboczego i indeksu (oprócz notatki, reszta pozostaje nietknięta). Na przykład, w celu poprawienia literówki.
    • git history split do interaktywnego podziału podanego commita na dwa różne commity z przeniesieniem wybranych części z pierwotnego 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 i git history squash do łączenia commitów.

  • Wprowadzono nową metodę definiowania handlerów (hook) w plikach konfiguracyjnych. Zamiast umieszczać skrypty z obsługą w katalogu .git/hooks w każdym repozytorium, polecenia do wywoływania obsługi można teraz ustawiać bezpośrednio w plikach konfiguracyjnych. Ustawienia można przypisać do repozytorium lub określić w plikach konfiguracyjnych obowiązujących dla wszystkich repozytoriów (/etc/gitconfig) lub repozytoriów użytkownika (~/.gitconfig). Możliwe jest przypisanie wielu obsług do jednego zdarzenia. Skrypty z .git/hooks wciąż są wywoływane, ale uruchamiane po obsługach z plików konfiguracyjnych. Aby zobaczyć listę obsług, należy użyć polecenia git hook list, a aby wyłączyć wywoływanie niektórych obsług – ustawienia 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 poleceniu „git maintenance” domyślnie zastosowana jest strategia geometric (git config set maintenance.strategy geometric), która pozwala na skrócenie czasu konserwacji dużych monorepozytoriów. W porównaniu do wcześniej stosowanej strategii, która korzystała z logiki jak w poleceniu git gc, nowa strategia unika ponownego pakowania wszystkich obiektów i wyklucza zbyt zasobożerne operacje, takie jak scalanie wszystkich plików pack (jeżeli to możliwe, łączenie odbywa się częściowo i bez czyszczenia usuniętych obiektów).
  • Baza danych obiektów (ODB) oraz powiązane z nią API zostały przeniesione na nową architekturę opartą na wykorzystaniu wtyczkowych backendów. Przeprowadzona restrukturyzacja abstrakcyjnie przedstawia format przechowywania obiektów i w przyszłości umożliwi realizację takich możliwości, jak alternatywne backendy i formaty obiektów, na przykład w celu bardziej efektywnego przechowywania dużych plików binarnych lub w celu optymalizacji pracy dużych git-hostingów.
  • W poleceniu „struktura repozytoriów git”, produkującej informacje o strukturze repozytoriów, zapewnia wyświetlanie nie tylko całkowitego rozmiaru, ale także pokazuje największe obiekty każdego rodzaju, co pozwala na ocenę rozmiaru bez korzystania z zewnętrznych narzędzi. 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 poleceniu „git replay», stosowane zamiast git rebase do odtwarzania historii na serwerze bez drzewa roboczego, domyślnie włączono atomowe aktualizacje referencji (zamiast wyprowadzania listy poleceń update-ref do ręcznej realizacji), wprowadzono opcję —revert do cofania zmian od serii commitów, zapewniono odrzucanie wynikowych pustych commitów oraz pojawiła się możliwość odtwarzania historii aż do korzennego commitu.
  • W „git rev-list» i podobne polecenia dodano opcję —maximal-only do wyświetlania tylko commitów, które nie są osiągalne z innych commitów.
  • Do polecenia «git repo info» dodano opcję —keys do wyprowadzania listy wszystkich znanych kluczy.
  • W poleceniu „git add -p» podczas nawigacji między blokami kodu za pomocą klawiszy „J” i „K” zapewniono oznaczenie już zatwierdzonych i pominiętych bloków. Dodano opcję —no-auto-advance, aby wyłączyć automatyczne przechodzenie do następnego pliku, aby mieć możliwość powrotu do wcześniejszych plików przed commitem.
  • Przeprowadzono optymalizację interfejsu webowego „gitweb» do pracy z urządzeń mobilnych.
  • W poleceniu „git apply –directory» przed użyciem zapewniono normalizację ścieżek plików, takich jak .\/un\/..\/normalized\/path.
  • Udokumentowano możliwość dodawania własnych podkomend poprzez umieszczenie plików git-<cmd> w katalogu z plikami wykonywalnymi.
  • Do polecenia «git send-email» dodano wsparcie dla certyfikatów klienta.
  • Dla polecenia „git status» wprowadzono konfigurację status.compareBranches, za pomocą której można określić gałęzie, z którymi będzie przeprowadzana 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 polecenia «git fast-import» dodano możliwość zastąpienia podpisów dla commitów, które stały się nieważne po imporcie.
  • Dodano wsparcie dla kompresji (compaction) wielopakowych indeksów MIDX (multi-pack index), w którym małe warstwy indeksu MIDX z informacjami o dostępności obiektów i związane z nimi pliki bitmapowe są łączone, co pozwala na zmniejszenie liczby nagromadzonych warstw w starych repozytoriach.
  • W zespole git backfill wdrożono możliwość określenia rewizji (zakresów commitów) oraz masek ścieżek (pathspec) w celu ograniczenia pobieranych części historii zmian:

git backfill main~100..main git backfill — ‘*.c’

  • Dodano alternatywne formy wywołania polecenia git config list – git config -l oraz git config —list.
  • Zezwolono na używanie znaków nie-ASCII w nazwach aliasów poleceń definiowanych 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 dostępu do repozytoriów przez HTTP zapewniono obsługę błędu o kodzie 429 (Too Many Requests). Żądania zakończone takim błędem są teraz traktowane nie jako problem krytyczny, ale jako błąd tymczasowy, dla którego należy spróbować ponownie po pewnym czasie. Opóźnienie przed ponowną próbą ustala się za pomocą opcji http.retryAfter, liczba powtórzeń – http.maxRetries, czas oczekiwania – http.maxRetryTime.

Źródło: linux.org.ru

Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS 🔥 Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS | ProHoster