13 lutego Junio C Hamano poinformował na listach mailingowych gita oraz jądra Linux o wydaniu nowej wersji, zdobywającego coraz większą popularność, rozproszonego systemu kontroli wersji.
Dokładniej o nadchodzącej wersji 1.7 byliśmy informowani m.in. z wydaniem wersji 1.6.6 pod koniec zeszłego roku, gdzie zapowiedziano istotne zmiany w domyślnym zachowaniu podstawowych komend, aby sprawiały mniej problemów. Już od pewnego czasu w najnowszych wersjach gita byliśmy ostrzegani o nich w trakcie wykonywania stosownych komend, łącznie z podaniem wskazówek jak można zachować (ustawić na sztywno) obecne zachowanie. Miało to na celu uniknięcie problemów znanych z poprzednich dużych zmian, kiedy to użytkownicy zwlekali z wcześniejszym dostosowaniem się do nich.
Jakie więc zaszły istotne zmiany?
git push
(wysyłanie obiektów do zdalnego repozytorium) do gałęzi, która jest używana w katalogu roboczym (tj. wskazywana przezHEAD
w nieczystym (ang. not bare) repozytorium) jest teraz domyślnie zabroniony. Analogicznie nie uda się też usuwanie (git push repo :gałąź
) takiej gałęzi.Przywrócenie starego i niezdrowego zachowania uzyskujemy poprzez przestawienie zmiennych
receive.denyCurrentBranch
orazreceive.denyDeleteCurrent
naignore
w repozytorium docelowym.Małym uzupełnieniem może być tu odpowiedź w GitFaq na pytanie: Dlaczego nie zobaczę zmian w zdalnym repozytorium po wykonaniu
git push
?git send-email
nie tworzy już domyślnie głębokich wątków (ang. deep threads), wysyłając cały zestaw łat (ang. patch) jako odpowiedź na pierwszy mail, tzw. list motywacyjny (ang. cover letter).Stare zachowanie gwarantuje parametr
--chain-reply-to
albo przestawienie w konfiguracji zmiennejsendemail.chainreplyto
natrue
.Płytkie wątki (ang.
shallow threads
) jako czytelniejsze i tak były zdecydowanie częściej używane na różnego rodzaju listach mailingowych, toteż ta drobna zmiana może nawet się wydawać nieco spóźniona.git status
przestał naśladowaćgit commit
z pominięciem etapu commitowania (do czego powinniśmy używać tożsamego poleceniagit commit --dry-run
obecnego od wersji 1.6.5) i pokazuje jedynie stan naszego katalogu roboczego, tzn. różnice między plikiem indeksu a aktualnym commitem wskazywanym przezHEAD
(czyli ścieżki do plików, które uległy zmianie w stosunku do drzewa reprezentowanego przez commit wskazywany wHEAD
i zostały wystawione (ang. staged) do późniejszych operacji [git ls-files --stage
vsgit ls-tree -r HEAD
]), ścieżki do śledzonych plików z naszego katalogu roboczego, które nie mają zgodnych wpisów w pliku indeksu (inaczej mówiąc, dotyczące je zmiany nie zostały wystawione) i wreszcie ścieżki do nieśledzonych plików, które nie spełniają wzorców ignorowania.Jest to istotna poprawa, ponieważ podając ścieżkę do
git status
zawężamy jedynie obszar jego działania, zamiast, jak to miało miejsce dotychczas, definiować, które ze śledzonych plików mają zostać zacommitowane (co było efektem domyślnie aktywnej opcji--only
w komendziegit commit
). Szczególnie nowi użytkownicy mogli mieć z tym problemy. Siłą rzeczygit status
przestał teraz obsługiwać parametry commitowania, które wcześniej cicho ignorował.Jeżeli zależy nam na starym zachowaniu, to jak już wcześniej wspomniano, wystarczy zastąpić
git status
komendągit commit --dry-run
.git diff
zmienił swoje działanie jeżeli stosujemy ignorowanie białych znaków (--ignore-space-at-eol
,--ignore-space-change
/-b
lub--ignore-all-space
/-w
). Jeżeli pliki różnią się jedynie ignorowanymi znakami, wówczas na wyjściu nie pojawi się dla nich nawet nagłówekdiff --git a/ścieżka/plik b/ścieżka/plik
, a przy użyciu dodatkowo opcji--exit-code
, kodem wyjścia będzie 0.- Dla zachowania spójności z innymi programami wykonywanymi przez gita, programy pomocnicze typu diff i textconv są teraz wykonywane z pomocą powłoki (ang. shell), pozwalając na przekazywanie do nich parametrów linii komend (ang. command-line parameters). Oznacza to, że jeżeli używaliśmy zmiennej środowiskowej
GIT_EXTERNAL_DIFF
lub ustawialiśmy zmiennediff.*.command
lubdiff.*.textconv
w pliku konfiguracyjnym, to w przypadku zawierania się w zdefiniowanych tam ścieżkach spacji lub innych metaznaków, muszą zostać wzięte w cytat. - Ostatnia już zmiana to modyfikacja interpretacji argumentu przekazywanego do opcji
--max-pack-size
używanej przez komendygit repack
,git pack-objects
igit fast-import
. Dotychczas traktowano ów argument jak wyrażony w MiB, zamiast w bajtach z obsługą sufiksówk
(2^10),m
(2^20) ig
(2^30), jak ma to miejsce w przypadku różnych zmiennych w konfiguracji czy innych opcji przyjmujących rozmiar jako argument.
Oprócz powyższej listy mamy jeszcze także mniejsze usprawnienia, z których co najmniej kilka pozwolę sobie odnotować:
- poprawiono nieco wydajność w msysgitowym porcie (przeznaczonym dla użytkowników systemu Windows),
- dodano obsługę opcji
--quiet
i--[no-]progress
do większej liczby komend (np. odpowiednio dogit reset
igit clone
), - uzupełniono transfer po HTTP o obsługę uwierzytelniania dostępu z pomocą schematów innych niż podstawowy (ang. basic), który przesyła hasła czystym tekstem (ang. plaintext) – aby móc z tego skorzystać, musimy ustawić zmienną
http.authAny
w konfiguracji, a jeżeli interesuje nas konkretnie uwierzytelnianie typu digest, potrzebujemy curla w wersji co najmniej 7.18.1 (z powodu błędów we wcześniejszych wersjach związanych z tym mechanizmem), - dodano opcję
--set-upstream
do komendygit branch
umożliwiającą zmianę upstreamu, - uzupełniono składnię o obsługę zapisu
gałąź@{upstream}
pozwalającego na podmianę upstreamu gałęzi, a pominięcie w nim gałęzi jest tożsame z podaniem bieżącej, git grep
nie polega już na zewnętrznym grepie i potrafi działać w oparciu o więcej niż jeden wątek aby przyspieszyć operację przeszukiwania.
Zmian jest oczywiście więcej i o wszystkich możecie przeczytać w stosownym anonsie. Źródła jak i dokumentację można znaleźć na stronie git-scm.com.
Na koniec dla tych, co nie śledzą uważnie rozwoju gita, ale mają z nim pewną styczność, chciałbym zauważyć, że istnieje komenda git notes
pozwalająca dodawać notatki do commitów bez ich zmieniania. Dla trzymających “żywą dokumentację” w svn-ie, dotychczasowa trudność związana ze zmianą opisu commita (i jej konsekwencje) w gicie była argumentem przeciwko migracji do niego. Problem ten jest rozwiązany począwszy od wersji 1.6.6. Prawda, że wielu z Was przeoczyło tę ciekawą komendę?
Dodaj komentarz