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 przez HEAD 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 oraz receive.denyDeleteCurrent na ignore 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 zmiennej sendemail.chainreplyto na true.

  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 polecenia git 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 przez HEAD (czyli ścieżki do plików, które uległy zmianie w stosunku do drzewa reprezentowanego przez commit wskazywany w HEAD i zostały wystawione (ang. staged) do późniejszych operacji [git ls-files --stage vs git 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 komendzie git commit). Szczególnie nowi użytkownicy mogli mieć z tym problemy. Siłą rzeczy git 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łówek diff --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 zmienne diff.*.command lub diff.*.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 komendy git repack, git pack-objects i git fast-import. Dotychczas traktowano ów argument jak wyrażony w MiB, zamiast w bajtach z obsługą sufiksów k (2^10), m (2^20) i g (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 do git reset i git 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 komendy git 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ę?