W dniu poniedziałek, 3 grudnia 2012 16:13:34 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:

> 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.

Ja tylko dyskutowalem z argumentami, o innych przewagach gita to ja moglbym
walnac kilka tak dlugich postow.

PGP uzywam: jak administruje systemami to robie checkout odpowiedniej wersji
i dzieki PGP wiem, ze to oryginal, choc trzymam to na malo pewnej stronie.
Wolalbym nie miec rootkita w domyslnej konfiguracji. No i wszystko mam
wersjonowane, czyli moge cherry-pickiem przerzucic jedna zmiane pomiedzy
branchami czyli konfiguracjami.

Wybrane:
mam lokalna konfiguracje rozwijanego systemu, sciezki, rozmiary i takie tam.
A w zasadzie dwie konfiguracje, klaster na laptopa i zwykla.

Dodatkowo mam swoje lokalne instrumentalizacje kodu do debuggowania. To
sporo plikow, mod systemu builda i pare innych.

I teraz co daje git: powiedzmy, ze mam zgloszenie, ze w wersji 4.5.43 jest
blad. Robie tak:
git checkout -b test1 <odpowiedni commit>
git merge moj_lokalny_konfig
git merge instrumentalizacja

... i mam wszystko gotowe do zbudowania i testow, podczas gdy recznie
- zajeloby mi to z pol godziny
- moglbym cos nadpisac, np. zmiany w globalnym konfigu, a git sprawdzi,
czy nie ma konfliktow
- w svn gdyby kazdy trzymal takie rzeczy w publicznym bylby smietnik.
A mamy master, kilka tagow, branche release, i chyba ze 3-4 inne branche
- jak ktos chce moj lokalny konfig, moge mu wyslac branch mailem jedna
komenda i to faktycznie dziala.

Rowniez, w tym samym celu, mam drugie lokalne repo ze wszystkimi kombinacjami
konfigow, instrumentalizacji i wersji release. Wiec jak mam przetestowac
ostatnie zmiany robie "git pull" i mam wszystkie wersje skonfigurowane
tak jak lubie w 5 sekund na odpowiednich branchach.

Itd. itp.

--
Edek