Po dwóch miesiącach rozwoju opublikowano wydanie rozproszonego systemu zarządzania kodem źródłowym Git 2.45. Git jest jednym z najpopularniejszych, niezawodnych i wydajnych systemów kontroli wersji, oferującym elastyczne narzędzia do nieliniowego rozwoju, oparte na rozgałęzaniu i scalaniu gałęzi. Aby zapewnić integralność historii oraz odporność na zmiany „wstecz”, stosowane jest niejawne haszowanie całej poprzedniej historii w każdym commicie, a także możliwe jest uwierzytelnianie cyfrowymi podpisami deweloperów dla wybranych tagów i commitów. Kod Git jest dystrybuowany na licencji GPLv2+.
W porównaniu z poprzednim wydaniem w nowej wersji wprowadzono 540 zmian, przygotowanych przez udział 96 deweloperów, z których 35 po raz pierwszy brało udział w pracach. Główne nowości:
- Dodano wstępną obsługę backendu „reftable” dla efektywnego przechowywania w repozytorium linków do gałęzi i tagów. Nowy backend wykorzystuje zdalne przechowywanie używane przez projekt JGit i zoptymalizowane do przechowywania bardzo dużej liczby linków (tradycyjne formaty przechowywania linków prowadzą w repozytoriach z dużą liczbą linków do znacznych kosztów operacyjnych z powodu umieszczania bardzo dużej liczby plików w jednym katalogu w przypadku przechowywania linków w katalogu $GIT_DIR/refs lub potrzeby przepisania jednego dużego pliku przy każdej aktualizacji w przypadku przechowywania linków w pliku $GIT_DIR/packed_refs). Nowy backend jest włączany przez zdefiniowanie opcji „—ref-format=reftable” podczas inicjalizacji repozytorium („git init —ref-format=reftable /path/to/repo”) i umożliwia przyspieszenie wyszukiwania, odczytu i zapisów w repozytoriach z dużą liczbą linków.
- Dostarczono narzędzia do zapewnienia przenośności między identyfikatorami obiektów opartymi na haszach SHA-1 i SHA-256. Aby umożliwić pracę z haszami SHA-1 i SHA-256 w jednym repozytorium podczas stopniowej migracji na hasze SHA-256, zaproponowano nowy format obiektów „compatibility”, który pozwala na odniesienie do obiektów nie tylko według głównego hasza, określonego podczas inicjalizacji repozytorium, ale także według zapasowego hasza. Na przykład, podczas inicjalizacji repozytorium można wybrać format SHA-256, a jako zapasowy określić hasz SHA-1: git init —object-format=sha256 /path/to/repo cd /path/to/repo git config extensions.compatObjectFormat sha1
- Do zespołu „git rev-list” dodana została możliwość wyświetlania identyfikatorów obiektów, które są niedostępne w lokalnym repozytorium, nawet jeśli są nieosiągalne w gałęzi lub tagu, co można wykorzystać do diagnozowania uszkodzenia repozytorium: git rev-list —missing=print —all | grep ‘^?’ ?70678e7afeacdcba1242793c3d3d28916a2fd152
- Dodano nową komendę „git reflog list” do wyświetlania znanych reflogów oraz odpowiadających im linków do tagów i gałęzi.
- Umożliwiono definiowanie alternatywnych prefiksów dla wyjścia „git diff”, które są wyświetlane przed ścieżką do pliku i oznaczają stan przed i po danej wersji pliku (domyślnie używane są prefiksy „a/” i „b/”). Aby zdefiniować własne prefiksy, dodano nowe opcje diff.srcPrefix i diff.dstPrefix do konfiguracji.
- Dodano parametr core.commentString do definiowania linii separatora, która będzie używana zamiast znaku „#” do ignorowania komentarzy w wiadomości dla commita. Dotychczasowa opcja core.commentChar została dostosowana do obsługi znaków wielobajtowych jako separatorów komentarzy (wcześniej wspierane były tylko znaki ASCII).
- Do komendy „git config” dodano opcję „—comment”, która pozwala na zapisywanie komentarzy w pliku .gitconfig w celu wyjaśnienia istoty niektórych ustawień. git config —comment ‘to show the merge base’ merge.conflictStyle diff3 tail -n 2 .git/config [merge] conflictStyle = diff3 # to show the merge base
- Do komendy „git cherry-pick” dodano opcję „—empty” do automatycznego usuwania zbędnych commitów, analogicznie do opcji „—empty” w git-rebase oraz git-am.
- W komendzie „git checkout -p” zezwolono na używanie symbolu „@” jako synonimu nazwy „HEAD”.
Źródło: opennet.ru
