On Friday 29 of June 2012 21:14:50 Kacper Kornet wrote: > On Fri, Jun 29, 2012 at 06:57:55PM +0200, Paweł Sikora wrote: > > On Sunday 24 of June 2012 20:12:15 Paweł Sikora wrote: > > > On Sunday 24 of June 2012 16:17:18 Kacper Kornet wrote: > > > > 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 > > > > na zawsze? dlaczego po merge devel->master, nie mozna niby zrobic merge > > > master->devel? > > > w ten sposob bez poprawiania historii nadal mozna ciagnac devel z nowymi > > > bajerami. > > > > * 03dbac5 (HEAD, master) f > > > | * 09354a5 (devel) e > > > |/ > > > * 6b690f7 d > > > |\ > > > | * 2ddc926 z > > > | * 0754883 y > > > | * 74a4198 x > > > * | f31db31 c > > > * | c22b088 b > > > |/ > > > * 59ee956 a > > > > no to jak panowie, jaki w koncu model odgalezien przyjmujemy dla glownego > > nurtu pld-th? > > > 1). > > dzialamy na 2 galeziach master/devel ze wzajemnym scalaniem (tak jak > > pokazalem wyzej) > > i nie nadpisujemy/kasujemy devel. > > Ale żeby osiągnąć to co naszkicowałeś wyżej to trzeba właśnie resetować > DEVEL. A dokładnie trzeba wykonać coś takiego: > > git checkout master > git merge DEVEL > git checkout DEVEL > git reset --hard master > (dalsze komity na master i DEVEL). > > Jak zrobisz krzyżowy merge: > > git checkout master > git merge DEVEL > git checkout DEVEL > git merger master > > to dostaniesz historię: > > A--B--C--D-I--K--(master) > \ / \ > E--F--G----J--L--(DEVEL) > > To ja wolę historię z pierwszego wariantu.
zeby osiagnac to co wrzucilem (git log --graph), nie uzylem zadnego reset/hard. prosty krzyzowy merge master/devel wystarczyl. nie wiem skad ta krawedz grafu miedzy G-J w twoim szkicu. _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
