Git migration

[Jacek Konieczny]

On Sat, Jun 23, 2012 at 11:14:35PM +0200, Kacper Kornet wrote:
> > To może wybór nazwy nie był najlepszy? Ta rozwojowa wersja pewnie ma
> > swój numerek lub nazwę upstream.
> 
> Może tak, może nie. Zobacz jak to teraz działa w CVS.

Generalna zasada przy migracji z CVS czy SVN do git, opisana chyba w
każdym HOWTO na ten temat: zapomnij co było w CVS/SVN i naucz się od
razu po gitowemu.

> Jak coś zostało
> zmergowane do master, to branch jest usuwany. A Twoim podejściu jego
> nazwa zostaje na zawsze w repo

Razem z dokładną informacją co i gdzie było zmergowane. Właściwie, jak
zostało zmergowane, to branch w historii zostaje na zawsze, nawet jak
się jego nazwę usunie…

> i każdy kto będzie robił git-clone nawet
> długi czas po tym nadal go dostanie - zupełnie niepotrzebnie. Według
> mnie będzie już wtedy zupełnie niepotrzebnie zaśmiecał tylko przestrzeń
> nazw.

Trochę racji w tym jest. Ale jak nazwy to będą np. 'gdb-2.31' a nie
'DEVEL', to trudno będzie o pomyłkowe ściągnięcie czegoś nieaktualnego.

> Ja bym zostawił tą wolność developerom. Bo np. niektórzy mą chcieć
> zrobić git-rebase dla bocznej gałęzi. A tak im tego zabronisz.

Nie jestem pewien, czy 'git-rebase' w 'publicznym repo' jest rozsądne.
Jeśli tylko chodzi o rebase przed nałożeniem na główny branch, to
przecież można zrobić to w tymczasowym branchu w lokalnym repo.

> I to wyjdzie w praniu. Jakoś nie ma z tym obecnie jakoś dużo problemów.
> Dla przykładu zobacz zresztą jak jest prowadzone repozytorium git. Tam
> gałąź pu (takie totalne devel) jest często przewijana i resetowana i
> jakoś nikt nie ma z tym problemu. A jak będzie taka potrzeba do dodanie
> odpowiednich acl jest szybkie.

Dobra… może to być przydatne, użyteczne i akceptowalne, ale jak zasady
będą jasne. Pewnie można w niektórych przypadkach dopuścić, ale na pewno
nie na 'master' i raczej zasadą powinno być, żeby tego unikać.

> > A jaki jest teraz sposób prowadzenia tej gałęzi?
> 
> Mogę być w błędzie. Ale chyba są przypadki gdzie stary branch AC-branch
> jest likwidowany i tworzony nowy oparty o inne rewizje plików. W innych
> przypadkach to jest tak naprawdę tag, a nie branch. No ale to już
> ułomność CVS i możliwe, że po przejściu na git się to zmieni. Ale to już
> sprawa RM Ac.

Zwyczaje z CVS trzeba sobie i tak pozmieniać. A RM z zasady będzie miał
większe prawa… ale myślę, że bez resetów też sobie poradzi.

> > Zamiast w git://carme.pld-linux.org/packages/screen.git twój prywatny
> > branch leżał by w
> > git://carme.pld-linux.org/developers/draenog/screen.git i tam sam byś
> > odpowiadał za spójność historii.
> 
> 1) W tedy nikt inny tam pewnie nie zajrzy. Chyba, że commitlogi stamtąd
> też będą leciały na listę. 

Zajrzy, gdy rzucisz linkiem do konkretnego brancha. Nie zawsze o czymś
ciekawym musi informować automat.

> 2) Mogę chcieć go mieć w oficjalnym repo, żeby sprawdzić, czy buduje się
> na builderach

To jest jakiś argument.

> 3) Mniej ważny argument: marnotrawienie miejsca na dysku.

To byłby problem dopiero gdyby każdy developer robił swoje repo dla
każdego pakietu. W praktyce takie prywatne repo zajmowałyby
nieporównywalnie mniej miejsca niż wszystkie oficjalne.

> > Bo co zrobisz jak ktoś ci zrobi 'git reset' i wrzuci swoje commity na
> > 'twoim' branchu w oficjalnym repo?
> 
> A był kiedykolwiek problem, że ktoś komuś zlikwidował brancha?

W PLD? Tak. Kiedyś ktoś jakiegoś ważnego taga czy brancha nam z całego
repo przez pomyłkę usunął i trzeba było całość z backupu przywracać ;)
Ale w GIT nie dało by się tego spieprzyć aż tak jak wtedy w CVS :)

> Wydaje mi się, że trochę się martwimy na zapas.

Pewnie tak ;)

> Jak się pojawią konflikty to wtedy bym się martwił.

Jak się pojawi potrzeba resetu brancha w oficjalnym repo, to wtedy bym
się martwił ;)

> A tak to bym zostawił deweloperom wolność, czy
> np. na danej gałęzi wolą włączać niezbędne zmiany z master przez
> git-merge czy przez git-rebase.

Ale fajnie by było, jakby było wiadomo czego z której gałęzi można
oczekiwać.

Pozdrowienia,
        Jacek