Git-TFS czy Git-TF – który wybrać?

Dla wszystkich biednych duszyczek zmuszonych do korzystania z TfuFSa jako narzędzia do utraty kontroli nad wersją dobre kilkadziesiąt miesięcy temu narodził się projekt Git-TFS pozwalający na użycie lokalnie Gita w tym celu. O tym narzędziu już pisałem w poście “git-tfs – lek na prawie całe zło” (i jeszcze przy paru innych okazjach).

Microsoft nie mógł pozostać dłużny i pół roku temu zrobił swoją wersję: Git-TF, o czym można więcej poczytać na blogu Briana Harry’ego (a dokładniej tu i tu).

Zanim zacznie się rant że “znowu MS robi coś po swojemu od zera zamiast skorzystać z cudzych doświadczeń!” muszę uprzedzić: mieli powód. Oni chcieli stworzyć narzędzie działające na różnych platformach (żeby TfuFS jak dżuma ogarnął cały świat, good luck with that), podczas gdy Git-TFS działa tylko na Windows i jego autor nie był zainteresowany współpracą z MS w celu zmiany tego ograniczenia.

Niedawno natknąłem się na ograniczenie w Git-TFS (chodzi o obsługę opisywanego sparse checkout). Skłoniło mnie to do przetestowania Git-TF… a poniżej moje spostrzeżenia.

Pierwsze co rzuca się w oczy już w momencie instalacji to wymaganie, które może dziwić: Java! Ta zła, okrutna, umierająca na stacjach klienckich Java. Przełknąłem tą zniewagę i zainstalowałem, chociaż łatwo nie było. W sumie jest to zrozumiałe jeśli chce się mieć produkt cross-platform.

Po drugie, co sprawdziłem od razu: zachowuje się poprawnie przy sparse checkout.

Hurra? Nie do końca. Bo wydajność tego czegoś leży, kwiczy i dławi się własnymi wymiocinami. Jakikolwiek kontakt z TfuFSem trwa dosłownie z 50x dłużej niż przy Git-TFS. Co gorsza, zespół o tym wie od dawna, podjęli tą decyzję świadomie, i nic z tym nie robią. Dodałem im motywacyjnie nowego buga w związku z tym.

Co mnie dodatkowo zdziwiło to domyślne doklejanie do commit msg masy śmieci. Są to metadane commita z Git… ale po co je tam ładować ot tak, bez pytania? Na szczęście w następnej wersji zostanie to zmienione i ta opcja będzie domyślnie wyłączona – tak jak powinno być. Jest już commit do tego, tyle że nie wpakowano go jeszcze do kolejnego release. Od momentu napisania posta do jego publikacji upłynęło trochę wody w muszli i już wyszła nowa wersja.

Ciekawie rozwiązano oznaczanie “który commit w Git jest którym commitem w TfuFS” – Git-TF dodaje tagi do repozytorium Gita. Git-TFS dokleja te dane do gitowego commit msg. Nie wiem co lepsze a co gorsze, dobrze że ludzie mają różne pomysły.

Podczas naszego krótkiego randewu natknąłem się na irytującego buga (zgłoszonego, jak się okazuje, dawno temu): tylko ostatni z wysyłanych commitów jest linkowany z podanym taskiem. Wszystkie inne nie otrzymują żadnego połączenia do obiektu w TfuFS, biedne sierotki, więc musiałem potem ręcznie je linkować. Biedna sierotka.

Werdykt: Git-TF, przy obecności tak znakomitej alternatywy jak Git-TFS, jest bezużyteczny jeśli pracuje się na Windows. A jeśli pracuje się na czymkolwiek innym to tym bardziej, bo kto używa na czymkolwiek innym TfuFSa? Przed zespołem jeszcze sporo pracy.

Jedyny problem jaki miałem z Git-TFS, czyli obsługa sparse checkout, da się w Git-TFS rozwiązać inaczej. A to klonując tylko część repozytorium z TfuFS, a to stosując komendę checkintool zamiast rcheckin (do czego i tak byłbym zmuszony w Git-TF z powodu buga z associate). Wracam więc do niego, kthxbye.