Vlákno názorů k článku GIT: naše první vydání od Jazz - Jen technická poznámka. Rebase mění kód, takže to...

Jen technická poznámka. Rebase mění kód, takže to co vznikne po "refreshi" není to samé, co jsme tam vkládali. Hodně ňami při velkých regresních testech. p.s. prakticky jsem to zatím neověřoval.. radši

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".

Rebase snad mění kód stejně jako merge, tzn v příkladu A'=merge(G, A), B'=merge(G, B),... nebo se pletu?

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 ^_^

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).