Git migration

[Kacper Kornet]

On Sat, Jun 23, 2012 at 08:21:17PM +0200, Jacek Konieczny wrote:
> On Sat, Jun 23, 2012 at 03:41:57PM +0200, Kacper Kornet wrote:
> > Załóżmy teraz taką sytuację, że chcę popracować nad jakąś rozwojową
> > wersją na branchu DEVEL. Potem ten branch jest włączony, albo i nie to
> > master. Ale w każdym wypadku to oznacza, że nazwa DEVEL na branch w
> > danym pakiecie jest już na zawsze zajęta.

> 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. Jak coś zostało
zmergowane do master, to branch jest usuwany. A Twoim podejściu jego
nazwa zostaje na zawsze w repo 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.

> > Zgadzam się z zakazem rewrite
> > na master, ale na innych branchach powinno to być dozwolone.

> Pytanie: po co w ogóle te branche? Jeżeli są ???prywatną developerską
> robótką???, to mogą siedzieć w prywatnym branchu, czy repo. Jeśli
> współdzielonym ???topic branchem???, to resety będą bruździć (bo
> współdzielony), a nazwę można dobrać tak, żeby nie było problemu, że
> zajęta.

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

> Podejrzewam, że w niektórych przypadkach nie tylko branch 'master'
> będzie miał szczególne znaczenie, tak że różne automaty będą z niego
> korzystać, czy zdalne forki??? reset na czymś takim narobi zamieszania,
> które tylko ręczna interwencja rozwiąże. To potem będziemy ustalać które
> branche są ważne a które mniej?

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.

> > Drugi problem, to byś w ten sposób wymusił na glenie inny sposób
> > prowadzenie gałęzi AC-branch niż jest teraz.

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

> > Mnie się to nie podoba. Bo jak chcesz zdecydować co jest prywatnym a co
> > nie branchem. Chcę popracować nad jakimś pomysłem i chcę żeby inni mieli
> > możliwość zobaczenia tego, to powinienem móc to umieścić w oficjalnym
> > repo.

> A co za problem umieścić to w swoim repo na tym samym serwerze? Zamiast
> 'git checkout' będzie tylko 'git remote add' i 'git fetch' wcześniej.
> A w oficjalnym repo będzie jak najmniej psucia i będzie wiadomo, że co
> się stamtąd wzięło to już tam jest.

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

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

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

> 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? Wydaje mi
się, że trochę się martwimy na zapas. Jak się pojawią konflikty 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.

-- 
  Kacper