On 2012-12-02, Sebastian Biały <h...@p...onet.pl> wrote:
>> No ale widzisz, w svn robisz zmiany, potem kompilujesz i wypada puscic testy
>> i dopiero commit. W git juz jak sie kompiluje sprawdzam cale zmiany
>> i robie commit. Jak sie nie skompiluje lub nie dziala, poprawiam juz
>> zrobiony commit ("--amend") - nikt nigdy nie zobaczy schrzanionego commita.
>
> Dlaczego ma nie zobaczyć? Albo rewertujesz albo commitujesz fixa. Nie
> rozumie, dlaczego wśród gitowców jest tak powszechne oszukiwanie (tu nie
^^^^^^^-- kto nie rozumie? czy "ja nie rozumię"?
> bylo żadnego commita!). Praca z repo z rewizjami wymaga pewnej higieny
> która wychodzi na zdrowie.

Praca z rewizjami wymaga pewnej higieny. Taką higieną jest nietrzymanie
pomyłki po wsze czasy, tylko (o ile nie została jeszcze opublikowana)
poprawienie jej w miejscu.

Kwestia przyjętej strategii. W Subversion nie poprawiasz, tylko łatasz,
bo nie masz wyboru. W gicie to kwestia polityki.

> Dalej nie jestem przekonany, twoje argumenty nie pokazują żadnej
> lepszosci gita nad svnem w przypadku o który chodziło (jak się okazuje)
> autorowi wątku.

Bo Edek nie przemyślał swoich argumentów. To, jak zauważyłem, normalne
przy dyskusjach o systemach kontroli wersji. Nikt zachwalający swój
ulubiony system kontroli wersji nie potrafi pokazać, dlaczego jest on
(naj)bardziejszy.

> Przyznaje, że jestem gotowy przejśc na gita pod
> warunkiem natrafienia na jeden killer-feature vs svn, bo drobnostki w
> svn są upierdliwe.

W podstawowym zastosowaniu git nie ma specjalnej przewagi nad
Subversion, wyjąwszy pracę odłączoną. Ja zaczynałem naukę gita od mostka
git-svn, żeby móc pracować na nie-zawsze-połączonym-z-internetem-laptopie
nad kodem znajdującym się oryginalnie w Subversion.

W porównaniu z Subversion git ma znacznie lepsze mechanizmy śledzenia
operacji merge. Ja na ten przykład do tej pory nie nauczyłem się, jaka
jest realna różnica między `svn merge' i `svn merge --reintegrate' na
długo żyjących branchach (z czasem następuje zamiana ról i merge
z trunka do brancha musi dostać --reintegrate; nadal nie wiem dlaczego
ani kiedy).

Informacja o merge'ach nie jest czymś dosztukowanym za pomocą atrybutów,
tylko jedną z podstawowych cech commita, przez co trudniej o głupią
pomyłkę. Zdarzyło mi się parę razy zacommitować merge bez katalogu
głównego, przez co svn:mergeinfo poszło w pizdu. Owszem, da się w SVN
z tego wycofać, ale dlaczego to w ogóle było możliwe?

Obliczanie różnic między commitami odbywa się na lokalnej maszynie,
a nie na serwerze, który służy do współdzielenia kodu. Przy większych
repozytoriach jest to istotna różnica.

W sytuacji, gdy praca nad kodem odbywa się w sieci, która nie ma żadnego
połączenia z siecią, gdzie ten kod pracuje produkcyjne, łatwiej jest
przerzucać commity. Mam taki specjalny workflow, który mi pakuje różnice
między tym, co powinno być w sieci produkcyjnej i bieżącym stanem,
a potem te zmiany przenoszę "na pendrajwie"[*], gdzie je wciągam do
produkcji.

[*] W rzeczywistości w nieco inny sposób, ale zgodnie z tym samym
schematem.

Przepisywanie historii w gicie pozwala mi na następujący sposób pracy
z gałęziami: wszystkie commity lokalne dla brancha są nałożone *na*
brancha źródłowego, a nie z nim *wymieszane*. W historii widać to tak,
że najpierw czyta się wyłącznie lokalne zmiany, a od pewnego momentu już
są same commity z oryginalnego brancha.
Jeśli mam tylko dwa-trzy commity w lokalnym branchu i ta liczba się nie
zwiększy drastycznie (np. w webaplikacji z raportami dodany jest dla
wygody jeden URL do dokumentacji), to łatwiej jest porównywać branch
oryginalny z lokalnym i wciągać zmiany z oryginalnego (tzn. nie
"konflikty są mniejsze", tylko "łatwiej znaleźć, które commity były tu,
a które tam i co jeszcze nie zostało zmerge'owane").

Git ma wbudowaną możliwość składania podpisów GPG pod commitami. Jeszcze
z tego nie korzystałem, ale gdy będę potrzebować systemu dystrybucji
informacji, w którym odbiorca ufa nie źródłu informacji (serwerowi),
a samym informacjom, w gicie będzie mi to łatwiej zrobić niż w SVN.

--
Secunia non olet.
Stanislaw Klekot