Wydanie kontroli źródła Git 2.39

Po dwóch miesiącach prac wypuszczono rozproszony system kontroli źródła Git 2.39. Git to jeden z najpopularniejszych, niezawodnych i wydajnych systemów kontroli wersji, zapewniający elastyczne narzędzia do nieliniowego programowania oparte na rozgałęzianiu i łączeniu. Aby zapewnić integralność historii i odporność na zmiany wsteczne, w każdym zatwierdzeniu stosowane jest ukryte hashowanie całej poprzedniej historii, możliwe jest także certyfikowanie poszczególnych tagów i zatwierdzeń cyfrowymi podpisami programistów.

W porównaniu do poprzedniej wersji, nowa wersja zawierała 483 zmiany, przygotowane przy udziale 86 programistów, z czego 31 brało udział w tworzeniu po raz pierwszy. Główne innowacje:

  • Komenda „git shortlog”, służąca do wyświetlania podsumowań wraz ze statystykami z historii zmian, dodała opcję „-group” pozwalającą na dowolne grupowanie zatwierdzeń według pól, nie ograniczając się do autora ani autora. Przykładowo, aby wyświetlić listę programistów z informacją o liczbie zmian, biorąc pod uwagę pomocników wymienionych w polu „Współautor”, możesz użyć polecenia: git shortlog -ns --group=author - -group=trailer:współautorem

    Dane wyjściowe Shortlog można agregować za pomocą specyfikatorów formatowania, a opcja „--group” może znacznie uprościć tworzenie skomplikowanych raportów i wyeliminować potrzebę stosowania dodatkowych poleceń sortowania. Na przykład, aby utworzyć raport z informacją o tym, ile zatwierdzeń dla danej wersji zostało zaakceptowanych w każdym miesiącu, możesz podać: git shortlog v2.38.0.. —date='format:%Y-%m' —group=' %cd' -s 2 2022-08 47 2022-09 405 2022-10 194 2022-11 5 2022-12 Wcześniej, aby wykonać podobną operację, konieczne było użycie narzędzi sort i uniq: git log v2.38.0 .. —data='format:%Y -%m' —format='%cd' | sortuj | uniq -c

  • Rozszerzono możliwości mechanizmu „cruft packs”, przeznaczonego do pakowania nieosiągalnych obiektów, do których nie ma odniesienia w repozytorium (nie odwołują się do nich gałęzie ani tagi). Obiekty nieosiągalne są usuwane przez moduł zbierający elementy bezużyteczne, ale pozostają w repozytorium przez pewien czas, zanim zostaną usunięte, aby uniknąć sytuacji wyścigowych. Mechanizm „cruft packs” pozwala na przechowywanie wszystkich nieosiągalnych obiektów w jednym pliku paczki, a dane o czasie modyfikacji każdego obiektu wyświetlają w osobnej tabeli, zapisanej w osobnym pliku z rozszerzeniem „.mtimes”, dzięki czemu nie nie pokrywają się z całkowitym czasem modyfikacji.

    Długość czasu, przez jaki nieosiągalne obiekty pozostają w repozytorium, zanim zostaną faktycznie usunięte, określa opcja „—prune=” " Jednakże, chociaż opóźnienie przed usunięciem jest dość skutecznym i praktycznym sposobem zapobiegania uszkodzeniu repozytorium z powodu warunków wyścigowych, nie jest ono w 100% niezawodne. Aby ułatwić przywracanie uszkodzonego repozytorium, nowa wersja zapewnia możliwość zapisywania brakujących obiektów poprzez dodanie opcji „--expire-to” do polecenia „git repack”, która pozwala określić plik do utworzenia zewnętrznego repozytorium kopię wszystkich usuniętych obiektów. Na przykład, aby zapisać w pliku Backup.git nieosiągalne obiekty, które nie uległy zmianie w ciągu ostatnich 5 minut, możesz użyć polecenia: git repack --cruft --cruft-expiration=5.minuty.ago -d --expire -to=../backup.git

  • Znacząco zwiększono (do 70%) szybkość operacji „git grep -cached” podczas wyszukiwania w obszarach, które korzystają z częściowego klonowania (sparse-checkout) i dla których istnieją częściowe indeksy (sparse Index). Poprzednio przy określeniu opcji „-cached” wyszukiwanie odbywało się najpierw w indeksie zwykłym, a następnie w indeksach częściowych, co skutkowało zauważalnymi opóźnieniami przy przeszukiwaniu dużych repozytoriów.
  • Przyspieszono weryfikację przez serwer spójności nowych obiektów przed umieszczeniem ich w repozytorium podczas operacji „git push”. Dzięki przejściu na rozliczanie przy sprawdzaniu tylko zadeklarowanych linków, w repozytorium testowym liczącym 7 milionów linków, z czego tylko 3% objętych jest operacją push, wprowadzone optymalizacje pozwoliły skrócić czas sprawdzania 4.5-krotnie.
  • Aby zabezpieczyć się przed potencjalnym przepełnieniem kodu w postaci liczb całkowitych, polecenie „git Apply” ogranicza maksymalny rozmiar poprawek, które można przetworzyć. Jeśli rozmiar poprawki przekracza 1 GB, zostanie wyświetlony błąd.
  • Aby zabezpieczyć się przed potencjalnymi podatnościami, wprowadzono zmiany polegające na oczyszczeniu niepotrzebnych informacji z nagłówków ustawianych podczas korzystania z modułu h2h3 z opcją GIT_TRACE_CURL=1 lub GIT_CURL_VERBOSE=1 wraz z HTTP/2.
  • Podczas sprawdzania gałęzi będącej dowiązaniem symbolicznym do innej gałęzi polecenie „git symbolic-ref HEAD” wyświetla teraz nazwę gałęzi docelowej, a nie nazwę dowiązania symbolicznego.
  • Dodano obsługę argumentu @{-1} do opcji „--edit-description” („git Branch —edit-description @{-1}”) do edycji opisu poprzedniej gałęzi.
  • Dodano polecenie „git merge-tree --stdin”, aby przekazać listę opcji poprzez standardowe wejście.
  • W sieciowych systemach plików procedura obsługi fsmonitor, która monitoruje zmiany w systemie plików, jest domyślnie wyłączona.

Źródło: opennet.ru

Dodaj komentarz