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