Hg: kaip perskaičiuoti, pvz., „Git rebase“

Git'e galiu tai padaryti:

 1. Pradėkite dirbti su nauja funkcija: $ git co -b newfeature-123 # (vietinės funkcijos kūrimo skyrius) padaryti keletą įsipareigojimų (M, N, O) meistras A --- B --- C \ T newfeature-123 M --- N --- O 2. Ištraukite naujus pakeitimus iš aukštesniojo kapitono: $ git pull (kapitonas atnaujintas ff-commits) meistras A --- B --- C --- D --- E --- F \ T newfeature-123 M --- N --- O 3. Iš naujo išjunkite valdiklį taip, kad mano nauja funkcija  gali būti sukurta atsižvelgiant į naujausius pakeitimus: (nuo newfeature-123) $ git rebase master meistras A --- B --- C --- D --- E --- F \ T newfeature-123 M --- N --- O


Noriu žinoti, kaip tai padaryti Mercurial, ir aš ieškojau interneto, kad galėčiau atsakyti, bet geriausia, ką galėjau rasti: „ git rebase“ - ar gali tai padaryti

Šioje nuorodoje yra 2 pavyzdžiai:
1. Pripažįstu, kad tai yra: (pvz., Pavyzdžių auditai pakeičiami mano pavyzdžiu)

 hg iki -CF hg filialas -f newfeature-123   hg transplantacija -a -b newfeature-123 

ne taip blogai, išskyrus tai, kad MNO vėl paliekama kaip laisva galva ir sukuria 3 naujus įsipareigojimus M ', N', O ', kurie yra atnaujintos pagrindinės linijos filialai.

Iš esmės problema yra ta, kad gaunu:

 meistras A --- B --- C --- D --- E --- F \ T newfeature-123 M '--- N' --- O '   \ T newfeature-123 M --- N --- O

tai nėra gera, nes palieka vietinius nepageidaujamus įsipareigojimus, kuriuos reikia išmesti.

  1. Kita parinktis iš tos pačios nuorodos -
 hg qimport -r M: O hg qpop -a hg up f hg filialas newfeature-123 hg qpush -a hg qdel -r qbase: qtip

ir tai lemia norimą tvarkaraštį:

 meistras A --- B --- C --- D --- E --- F \ T newfeature-123 M --- N --- O

tačiau šios komandos (visos 6 iš jų!) atrodo daug sudėtingesnės nei

 $ git rebase master

Noriu žinoti, ar tai vienintelis ekvivalentas Hg, ar yra koks nors kitas būdas, kuris yra toks pat paprastas kaip „Git“.

192
20 апр. nustatė jpswain balandžio 20 d 2010-04-20 06:34 '10, 6:34, 2010-04-20 06:34
@ 5 atsakymai

VonC turi atsakymą, kurį ieškote , „Rebase“ plėtinį. Tačiau verta paminėti antrą ar du, kad galvotumėte, kodėl nei mq, nei rebase nėra įtraukti į gyvsidabrio, nes gyvsidabris yra susijęs su neištrinamais pakeitimais. Kai dirbau taip, kaip jūs apibūdintumėte beveik kasdien, čia yra pavyzdys, kurį aš paimsiu:

 1. Start working on a new feature: $ hg clone mainline-repo newfeature-123 do a few commits (M, N, O) master A---B---C \ newfeature-123 M---N---O 2. Pull new changes from upstream mainline: $ hg pull master A---B---C---D---E---F \ newfeature-123 M---N---O 3. merge master into my clone so that my new feature can be developed against the latest upstream changes: (from newfeature-123) $ hg merge F master A---B---C---D---E---F \ \ newfeature-123 M---N---O---P 

ir tai tikrai viskas, ko reikia. Aš galų gale su nauja-123 klonu, galiu lengvai grįžti į kamieną, kai esu patenkintas. Tačiau svarbiausia, kad niekada nepasikeitiau istorijų. Kažkas gali pažvelgti į mano rinkinius ir pamatyti, ką jie iš pradžių kodavo, ir kaip aš per savo darbą reagavau į pagrindinės linijos pokyčius. Ne visi mano, kad tai svarbu, bet aš tvirtai tikiu, kad kontroliuojant šaltinį mums reikia ne parodyti, ką norėjome, bet kas iš tikrųjų atsitiko - kiekviena klaida ir kiekvienas refaktorius turėtų palikti neištrinamą ženklą. ir iš naujo įdiegti ir kitus istorijų redagavimo metodus jį slėpti.

Dabar grįžkite į VonC atsakymą, kol ištrauksiu muilo krepšelį. :)

211
20 апр. atsakymas pateikiamas Ry4an Brase 20 balandžio. 2010-04-20 07:14 '10, 7:14, 2010-04-20 07:14

Gali būti ieškoma „ Rebase Extension“ . (įgyvendinta kaip „ SummerOfCode 2008“ dalis )

Tokiais atvejais gali būti naudinga „atskirti“ vietinius pakeitimus, sinchronizuoti saugyklą su pagrindine sistema, o po to pridėti naujus nuotolinius pakeitimus. Ši operacija vadinama perkelti.

Išeiti iš :

2019

93
20 апр. Atsakymą pateikė VonC 20 balandis. 2010-04-20 06:57 '10, 6:57, 2010-04-20 06:57

Darant prielaidą, kad įdiegtas šiuolaikinis „Hg“ įrenginys, galite tiesiog pridėti:

 [extensions] rebase = 

į ~ / .hgrc.

Tada galite naudoti hg rebase , hg pull --rebase arba hg help rebase .

41
20 апр. atsakymas pateikiamas 20 d. 2010-04-20 07:02 '10 at 7:02 2010-04-20 07:02

Nemanau, kad pirmiau minėti atsakymai pasiektų OP tikslą, kuris turėjo remti jos užduotį, paprasčiausiai persvarstyti vėlesnį patronuojančios filialo tašką.

Tarkime, aš pradedu nuo šio grafiko (sukuriamas naudojant grafiko plėtinį). Rimta geek meilė grafikai).

 @ 9a4c0eb66429 Feature 3 commit 2 tip feature3 | | o af630ccb4a80 default againagainagain | | o | 98bdde5d2185 Feature 3 branch commit 1 feature3 |/ o e9f850ac41da foo 

Jei esu funkcijoje3 ir noriu iš naujo įdiegti jį dar kartą, suprantu, kad hg rebase -d default . Tai turi tokį rezultatą:

 @ 89dada24591e Feature 3 commit 2 tip | o 77dcce88786d Feature 3 branch commit 1 | o af630ccb4a80 default againagainagain | o e9f850ac41da foo 

Misija įvykdyta? Aš taip nemanau. Problema yra ta, kad kai funkcijų3 filialui priskirti įsipareigojimai buvo atstatyti į reagentą, funkcija3 pašalinta . Mano įsipareigojimai buvo perkelti į numatytąjį filialą, kurį bandžiau išvengti.

„Git“ rezultatas bus toks:

 @ 9a4c0eb66429 Feature 3 commit 2 tip | o 98bdde5d2185 Feature 3 branch commit 1 **feature3** | o af630ccb4a80 default againagainagain | o e9f850ac41da foo 

Atkreipkite dėmesį, kad funkcijų3 filialas vis dar egzistuoja, dvi funkcijos dar yra funkcijos3 šakoje ir nėra rodomos pagal numatytuosius nustatymus. Neišsaugojus užduočių šakų, nematau, kaip ši funkcija skiriasi nuo sujungimo.

UPDATE . Radau vėliavą „ --keepbranches palaikomą„ hg rebase “, ir man malonu pranešti, kad visa tai yra gerai. Naudodamiesi hg rebase -d default --keepbranches - tiksliai atkartojau Git elgseną, kurią aš trokiau. Vėliau yra keletas slapyvardžių, ir aš atkursiu kaip niekas kitas.

19
19 апр. Atsakyti Jonathan Blackburn balandžio 19 d 2013-04-19 19:05 '13, 07:05 pm 2013-04-19 19:05

Kai kurie žmonės žaidžia pokštą, sakydami, kad manau, kad yra gera taupyti kiekvieną visko iteraciją, ir norėčiau pažymėti, kad dėl didelių atviro kodo projektų, priimant pakeitimus, užbaigus susijungimus ir vystymosi iteracijas, įvyko nepatogus pasikeitimų bagažinėje istorija, ir Padarykite pakeitimų istoriją mažiau naudingą, kad peržiūrėtumėte dabartinės versijos rodymą.

Tai gerai veikia, kai pateiktus pakeitimus tikrina žmonės, kurie jų nepriima prieš juos priimant, todėl pakeitimai, įtraukti į pagrindinę liniją, paprastai derinami ir atliekami. Tada, kai grįšite į linijos pradžią, pamatysite visus su juo susijusius pokyčius, o ne kai kuriuos pokyčių raidos taškus, kurių dalis ji yra.

X265skelbėjų puslapyje paaiškinama, kaip pakartotinai atlikti pakeitimų rinkinį, kuriuo dirbate, kad jie būtų pasirengę pateikti projektą x265. (Įskaitant „TortoiseHG“ panaudojimą tam tikriems, bet ne visiems atskiriems failams, pvz., „Git gui“ etapui / „nestabilioms skirtumams“, priskirti, kad būtų įvykdyti).

Procesas yra atnaujinti hg į viršutinį viršūnę ir tada gauti visus pakeitimus, kurie neleidžiami darbiniame kataloge. Įdėkite viską, kas nėra dalis to, ką norite pateikti, o po to padalinkite likusią dalį tiek daug atskirų įsipareigojimų, kad tinka, su gerais pranešančiais pranešimais.

Darau prielaidą, kad nukopijavote / įklijuojote ir tada redagavote pranešimus iš ankstesnių pataisų rinkinio iteracijų, kuriuos peržiūrite. O gal jūs galite perkelti savo senus įsipareigojimus (vyšnių pasirinkimą į gitą) ir tada juos keisti po vieną, kad jūsų senieji pranešimai taptų pradiniu redagavimo tašku.

0
15 дек. Atsakymą pateikė Peter Cordes gruodžio 15 d. 2014-12-15 06:48 '14, 6:48 2014-12-15 06:48