Wydanie rozproszonego systemu kontroli źródła Git 2.26
Do dyspozycji wydanie rozproszonego systemu kontroli źródła Git 2.26.0. Git to jeden z najpopularniejszych, niezawodnych i wydajnych systemów kontroli wersji, który zapewnia elastyczne nieliniowe narzędzia programistyczne oparte na rozgałęzianiu i łączeniu gałęzi. Aby zapewnić integralność historii i odporność na zmiany wsteczne, w każdym zatwierdzeniu stosowany jest niejawny hasz całej poprzedniej historii, możliwa jest również weryfikacja poszczególnych tagów i zatwierdzeń za pomocą podpisów cyfrowych od programistów.
W porównaniu do poprzedniej wersji, nowa wersja zawierała 504 zmiany, przygotowane przy udziale 64 programistów, z czego 12 wzięło udział w tworzeniu po raz pierwszy. Głównyminnowacje:
Wartość domyślna została zmieniona na druga wersja Protokół komunikacyjny Git, który jest używany, gdy klient zdalnie łączy się z serwerem Git. Druga wersja protokołu wyróżnia się możliwością filtrowania gałęzi i tagów po stronie serwera, zwracając skróconą listę linków do klienta. Wcześniej każde polecenie pull zawsze wysyłało klientowi pełną listę odniesień w całym repozytorium, nawet jeśli klient aktualizował tylko jedną gałąź lub sprawdzał, czy jego kopia repozytorium jest aktualna. Kolejną godną uwagi innowacją jest możliwość dodawania nowych możliwości do protokołu w miarę udostępniania nowych funkcji w zestawie narzędzi. Kod klienta pozostaje zgodny ze starym protokołem i może nadal współpracować zarówno z nowymi, jak i starymi serwerami, automatycznie powracając do pierwszej wersji, jeśli serwer nie obsługuje drugiej.
Do polecenia „git config” dodana została opcja „-show-scope”, ułatwiająca identyfikację miejsca, w którym zdefiniowano określone ustawienia. Git umożliwia definiowanie ustawień w różnych miejscach: w repozytorium (.git/info/config), w katalogu użytkownika (~/.gitconfig), w ogólnosystemowym pliku konfiguracyjnym (/etc/gitconfig) oraz poprzez polecenie opcje linii i zmienne środowiskowe. Podczas wykonywania „git config” dość trudno jest zrozumieć, gdzie dokładnie zdefiniowano żądane ustawienie. Aby rozwiązać ten problem, dostępna była opcja „--show-origin”, ale pokazuje ona tylko ścieżkę do pliku, w którym zdefiniowano ustawienie, co jest przydatne, jeśli zamierzasz edytować plik, ale nie pomaga, jeśli należy zmienić wartość poprzez „git config” przy użyciu opcji „--system”, „--global” lub „-local”. Nowa opcja „--show-scope” wyświetla kontekst definicji zmiennej i może być używana w połączeniu z opcją -show-origin:
W ustawieniach wiązania referencje Dozwolone jest używanie masek w adresach URL. Wszelkie ustawienia HTTP i dane uwierzytelniające w Git można ustawić zarówno dla wszystkich połączeń (http.extraHeader, credential.helper), jak i dla połączeń opartych na adresach URL (credential.https://example.com.helper, credential.https: //example. com.helper). Do tej pory symbole wieloznaczne, takie jak *.example.com, były dozwolone tylko w ustawieniach HTTP, ale nie były obsługiwane w przypadku wiązania poświadczeń. W Git 2.26 te różnice zostały wyeliminowane i na przykład, aby powiązać nazwę użytkownika ze wszystkimi subdomenami, możesz teraz określić:
[poświadczenie „https://*.example.com”]
nazwa użytkownika = taylorr
Kontynuowany jest rozwój eksperymentalnego wsparcia klonowania częściowego (klony częściowe), umożliwiającego przeniesienie tylko części danych i pracę z niekompletną kopią repozytorium. W nowej wersji dodano nowe polecenie „git sparse-checkout add”, które umożliwia dodanie poszczególnych katalogów w celu zastosowania operacji „checkout” tylko do części drzewa roboczego, zamiast jednoczesnego wyświetlania wszystkich takich katalogów za pomocą polecenia „git zestaw sparse-checkout” (możesz dodawać katalogi jeden po drugim, bez konieczności ponownego określania całej listy za każdym razem).
Na przykład, aby sklonować repozytorium git/git bez zatwierdzania obiektów BLOB, ograniczając pobieranie tylko do katalogu głównego kopii roboczej i oddzielnie zaznaczając pobieranie dla katalogów „t” i „Dokumentacja”, możesz określić:
$ git sparse-checkout dodaj t
....
$ git sparse-checkout dodaj dokumentację
....
$ git lista sparse-checkout
Dokumenty
t
Znacząco poprawiono wydajność polecenia „git grep”, służącego do przeszukiwania zarówno bieżącej zawartości repozytorium, jak i wersji historycznych. Aby przyspieszyć wyszukiwanie, możliwe było przeskanowanie zawartości drzewa roboczego przy użyciu wielu wątków („git grep –threads”), ale wyszukiwanie w wersjach historycznych było jednowątkowe. Teraz to ograniczenie zostało usunięte poprzez wdrożenie możliwości równoległego odczytu z pamięci obiektowej. Domyślnie liczba wątków jest równa liczbie rdzeni procesora, co w większości przypadków nie wymaga obecnie jawnego ustawiania opcji „-threads”.
Dodano obsługę autouzupełniania wprowadzania podpoleceń, ścieżek, łączy i innych argumentów polecenia „git worktree”, co pozwala na pracę z kilkoma działającymi kopiami repozytorium.
Dodano obsługę jasnych kolorów, które mają sekwencje specjalne ANSI. Na przykład w ustawieniach kolorów podświetlenia „git config –color” lub „git diff –color-moved” możesz określić „%C(brightblue)” za pomocą opcji „--format” dla jasnego błękitu.
Dodano nową wersję skryptu fsmonitor-watchman, zapewniając integrację z mechanizmem Strażnik Facebooka aby przyspieszyć śledzenie zmian w plikach i pojawianie się nowych plików. Po aktualizacji wymagany jest git wymienić zaczep w repozytorium.
Dodano optymalizacje przyspieszające częściowe klonowanie podczas korzystania z bitmap
(maszyna bitmapowa), aby uniknąć pełnego przeszukiwania wszystkich obiektów podczas filtrowania danych wyjściowych. Sprawdzanie obiektów blob (—filter=blob:none i —filter=blob:limit=n) podczas częściowego klonowania jest teraz wykonywane
znacznie szybciej. GitHub ogłosił poprawki z tymi optymalizacjami i eksperymentalną obsługą częściowego klonowania.
Polecenie „git rebase” zostało przeniesione do innego backendu, który używa domyślnego mechanizmu „scalania” (wcześniej używanego dla „rebase -i”) zamiast „łatka+zastosuj”. Backendy różnią się pod pewnymi względami, na przykład po kontynuowaniu operacji po rozwiązaniu konfliktu (git rebase --continue) nowy backend oferuje możliwość edycji komunikatu zatwierdzenia, podczas gdy stary po prostu korzystał ze starego komunikatu. Aby powrócić do starego zachowania, możesz użyć opcji „--apply” lub ustawić zmienną konfiguracyjną „rebase.backend” na „apply”.
Przykład procedury obsługi parametrów uwierzytelniania określonych za pośrednictwem .netrc został zredukowany do postaci nadającej się do użycia po wyjęciu z pudełka.
Dodano ustawienie gpg.minTrustLevel umożliwiające ustawienie minimalnego poziomu zaufania dla różnych elementów przeprowadzających weryfikację podpisu cyfrowego.
Dodano opcję „--pathspec-from-file” do „git rm” i „git stash”.
Kontynuowano udoskonalanie zestawów testów w ramach przygotowań do przejścia na algorytm mieszający SHA-2 zamiast SHA-1.