W związku z tym, że mój zespół korzysta z troszkę dziwnego formatowania źródeł (przez eclipse, z którego nie korzystam) a inne IDE nie do końca idealnie potrafią odtworzyć zachowanie tego formattera, czasami zdarzało mi się wcommitować kilka(naście) linii gdzie jedyną zmianą była na przykład różnica o jedną spację. Korzystałem przez pewien czas z pluginu external-formatter do IntellJ IDEA jednak przy moim dość częstym wykorzystywaniu automatycznego formatowania kodu okazało się to „trochę” nie wydajne i irytujące…
Na szczęście od pewnego czasu przerzuciłem się na git-svn i mogę sobie obecnie lokalnie pozwolić na wykorzystywanie jego pełnego potencjału. Jedną z sztuczek którą podsuwa nam pod nos git są tak zwane „client-side-hooks” oraz komenda „git alias„, o wiadomym wydaje mi się przeznaczeniu :-) Hooki, w dwóch słowach, to podobnie jak w innych SCMach, „skrypty wołane w pewnych momentach flow takiego systemu kontroli wersji”. W git możemy je również instalować również po stronie klienta – w dodatku, jest to bardzo proste: umieszczamy odpowiednio nazwany plik wykonywalny (skrypt) w folderze .git/hooks/ i gotowe.
Ponieważ nie dałem za wygraną z korzystaniem z tego samego formattera co reszta zespołu, pierwszym pomysłem był właśnie hook, który by to przed każdym commitem formatował wszystkie moje źródła eclipsowym narzędziem. Nie wołałbym go aż tak często jak w przypadku formatowania wewnątrz IDE podczas pisania, a mimo wszystko od repo trafiałby jedynie legalnie sformatowany kod. Kilka linijek niżej został umieszczony wspomniany skrypcik. Aby został „zobaczony” przez git’a wystarcza go odpowiednio nazwać i umieścić w folderze .git/hooks/ a konkretniej: „.git/hooks/pre-commit” i tyle, git zajmie się resztą.
Aby rozwiać wątpliwości co do pliczku org.eclipse.jdt.core.prefs – pochodzi on z projektu eclipse’owego w którym przy formaterze zaznaczymy aby „korzystał z osobnych ustawień formattera dla tego projektu. Ten pliczek zostanie wówczas wygenerowany do folderu .settings. Wracając do meritum posta, zobaczmy jak ten skrypt się sprawdza:
Mimo braku wspominanych przezemnie dziwnych elementów tego formatowania w tej przykładowej klasie – wyraźnie widać iż nasz hook zadziałał jakbyśmy się tego spodziewali. Niestety to również okazało się troszkę za wolne jak na mój typowy flow, gdzie bardzo często commituję, a do svn wypycham jedynie „większe spójne całości”, kolejnym krokiem było przepisanie tego hook’a na własne polecenie git’a. Konfiguracja tego jest jeszcze prostsza niż ustawienie hooka:
git config --global alias.eclipse-formatter '!~/git-hook-eclipse-formatter'
Warto zauważyć składnię !command którą git alias wspiera od wersji 1.5.0. Działa, jak zapewne już się domyśliliście po prostu pozwalając na wykonanie dowolnego programu (zanim wprowadzono obsługę składni !command możliwe było jedynie wołanie innych komend git’a). Zobaczmy czy działa to tak jakbyśmy się tego spodziewali:
I rzeczywiście, nie dość, że uzyskałem teraz wygodny dostęp do formattera kodu mojego zespołu to dostęp ten jest „globalny”, w sensie „w każdym repozytorium git mogę wykonać tą komendę”. Sama operacja aliasowania nie musi być wcale wykonywana przez git, jak widać polega ona przecież tylko na dopisaniu odpowiedniej linijki w pliku ~/.gitconfig albo, gdybyśmy chcieli uzyskać to samo na poziomie projektu (a nie „globalnie”) do .git/config. Wisienką na torcie jest iż bash poprawnie będzie podpowiadał naszą komendę… :-)
To by było na tyle… Happy hacking!
0
komentarzy