Git migration

[Paweł Sikora]

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.