Git migration

[Jacek Konieczny]

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.

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

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?

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

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

Bo co zrobisz jak ktoś ci zrobi 'git reset' i wrzuci swoje commity na
'twoim' branchu w oficjalnym repo?

Można dla wyjątkowych sytuacji zostawić prawo do git reset itp.
adminowi, ale to ewidentnie do cofania głupich błędów, biorąc pod uwagę
konsekwencje.

Pozdrowienia,
        Jacek