Git migration

[Kacper Kornet]

On Sun, Jun 24, 2012 at 10:25:38AM +0200, Jacek Konieczny wrote:
> 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.

Chodziło mi, że obecnie nie ma konfliktów o nazwę branchy. 

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

Dla jasności. Niech mamy historię jak tutaj:

   A---B---C
    \
     X---Y---Z

gdzie D jest na gałęzi master, a Z na DEVEL. Teraz następuje merge i
DEVEL do master i mamy historię:

  A---B---C--D
   \        /
    X--Y--Z 

W commitlogu D jest wyjaśnienie co zostało zmergowane. Więc zwykle sam
branch DEVEL nie jest już potrzebny.  Ale jak nie pozwolimy robić
żadnego rewrite, to branch DEVEL na zawsze pozostanie na commicie Z i
nadal będzie widoczny u każdego po git-clone. Tak więc jak dla mnie
musi być przynajmniej możliwość usuwania gałęzi zmergowanych gdzie
indziej.

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

Ale jak robisz git-clone to ściągasz wszystkie branche. W Twoim
podejściu nawet te już dawno nieaktualne bo zmergowane gdzie indziej. 

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

No dobrze. Zrobię sobie lokalnie rebase, potem ładny fast-forward merge
do master, zrobię push i lokalnie mogę się pozbyć tej gałęzi. Ale w
publicznym repo ona nadal zostaje.

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

Master jest zabezpieczony. Tak samo jest wszystkie tagi auto-*.

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

Nie musi. Ale w ten sposób mam większą szansę, że np. qboosh wyłapie
jakiś nietrafiony pomysł na wczesnym etapie ;-)

> > > 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 :)

Widać jeszcze nie za moich czasów. Jak to nieznajomość historii
człowieka gubi ;-).

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

Tu zgoda. To co na razie proponuję to:

gałąź master - zakaz reset
tagi auto-ac- - zakaz kasowania, tylko odpowiedni builder może je Tworzyć
gałąź RA-branch i tagi RA-* - tylko do odczytu
gałęzie i tagi AC-*, Ti-* - decyzja odpowiednich RM, co z nimi zrobić.

-- 
  Kacper