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
_______________________________________________
pld-devel-pl mailing list
[email protected]
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
