Vlákno názorů k článku
GIT: naše první vydání
alblaho (neregistrovaný)
26. 5. 2008 10:51
Re: rebase
Rebase je zajímavý. Já zběžně znám Bazaar a žiju v tom, že k přijímání patchů z upsteramu slouží "merge".
Jirka P (neregistrovaný)
26. 5. 2008 18:37
Re: rebase
Rebase snad mění kód stejně jako merge, tzn v příkladu A'=merge(G, A), B'=merge(G, B),... nebo se pletu?
Jazz (neregistrovaný)
26. 5. 2008 23:25
Re: rebase
Abych přiznal barvu, tak na tuto poznámku jsem narazil někde mezi porcelain/core dokumentací a on-line příspěvky na internetu. Myslím, že to dokonce řekl sám Linus, ale musel bych ten materiál dohledat.
Samotného mě to dost zarazilo.
Vzhledem ktomu, že jsem to doteď rebase nepotřeboval použít,
tím pádem jsem si to ani hlouběji nestudoval.
Každopádně bych rád věděl jak to je ^_^
Samotného mě to dost zarazilo.
Vzhledem ktomu, že jsem to doteď rebase nepotřeboval použít,
tím pádem jsem si to ani hlouběji nestudoval.
Každopádně bych rád věděl jak to je ^_^
gapon (neregistrovaný)
27. 5. 2008 10:55
Re: rebase
Ja myslim, ze rebase slouzi k tomu, kdyz ma clovek svou sadu patchu, kterou mu bud nechteji autori programu prijmout zpet nebo ji proste nechce zverejnovat - pak:
- mam zdrojaky programu (branch main), na to hodim ty svoje patche (branch topic)
- pullnu main, tudiz moje topic branch uz neni "nad" aktualnima zdrojakama programu, ale nekde uvnitr (pro vizualizaci lze pouzit #gitk --all) - mam ted dve moznosti - merge main nebo rebase - protoze ale chci ty svoje patche stale "nad" aktualnim mainem, abych vedel, ze ty patche mi stale funguji oproti posledni verzi programu - a presne k tomu slouzi rebase.
Rozdil oproti merge tedy je, ze merge vam ty vase patche zaintegruje nekde "dovnitr" mezi existujici commity.
Hmm, snad je mi rozumet :)
PS: Presne k tomuhle slouzi v hg rozsireni mq - zajemce odkazuji na hgbook, kapitola 12 a 13
(http://hgbook.red-bean.com/hgbookch12.html#x16-26700012).
- mam zdrojaky programu (branch main), na to hodim ty svoje patche (branch topic)
- pullnu main, tudiz moje topic branch uz neni "nad" aktualnima zdrojakama programu, ale nekde uvnitr (pro vizualizaci lze pouzit #gitk --all) - mam ted dve moznosti - merge main nebo rebase - protoze ale chci ty svoje patche stale "nad" aktualnim mainem, abych vedel, ze ty patche mi stale funguji oproti posledni verzi programu - a presne k tomu slouzi rebase.
Rozdil oproti merge tedy je, ze merge vam ty vase patche zaintegruje nekde "dovnitr" mezi existujici commity.
Hmm, snad je mi rozumet :)
PS: Presne k tomuhle slouzi v hg rozsireni mq - zajemce odkazuji na hgbook, kapitola 12 a 13
(http://hgbook.red-bean.com/hgbookch12.html#x16-26700012).
27. 5. 2008 10:56
Re: rebase
Jen technická poznámka. Rebase mění kód, takže to co vznikne po "refreshi" není to samé, co jsme tam vkládali.Pochopitelne, ze rebasovane patche nejsou uplne stejne (i pokud se nemeni vlastni kod tak minimalne SHA-1 rodice je jine takze pak je jiny i kazdy jeho potomek apod.). A pokud neco menilo kod na ktery se "refreshne" patch tak je pochopitelne jiny i kod, atd.
Hodně ňami při velkých regresních testech. p.s. prakticky jsem to zatím neověřoval.. radšiMoc nechapu. Proc delat rebase je v clanku napsano. Jinak debata na toto tema: http://kerneltrap.org/Linux/Git_Management

