La mossa di Mercurial cambia in un nuovo ramo


Risposte:


153

Come suggerito da Mark, MqExtension è una soluzione per il tuo problema. IMHO un flusso di lavoro più semplice consiste nell'usare l' estensione rebase . Supponi di avere una storia come questa:

@  changeset:   2:81b92083cb1d
|  tag:         tip
|  summary:     my new feature: edit file a
|
o  changeset:   1:8bdc4508ac7b
|  summary:     my new feature: add file b
|
o  changeset:   0:d554afd54164
   summary:     initial

Ciò significa che la revisione 0è la base su cui hai iniziato a lavorare sulla tua funzionalità. Ora vuoi avere le revisioni 1-2su un ramo con nome, diciamo my-feature. Aggiorna alla revisione 0e crea quel ramo:

$ hg up 0
$ hg branch my-feature
$ hg ci -m "start new branch my-feature"

La cronologia ora assomiglia a questa:

@  changeset:   3:b5939750b911
|  branch:      my-feature
|  tag:         tip
|  parent:      0:d554afd54164
|  summary:     start new branch my-feature
|
| o  changeset:   2:81b92083cb1d
| |  summary:     my new feature: edit file a
| |
| o  changeset:   1:8bdc4508ac7b
|/   summary:     my new feature: add file b
|
o  changeset:   0:d554afd54164
   summary:     initial

Utilizzare il rebasecomando per spostare le revisioni 1-2in revisione 3:

$ hg rebase -s 1 -d 3

Ciò si traduce nel seguente grafico:

@  changeset:   3:88a90f9bbde7
|  branch:      my-feature
|  tag:         tip
|  summary:     my new feature: edit file a
|
o  changeset:   2:38f5adf2cf4b
|  branch:      my-feature
|  summary:     my new feature: add file b
|
o  changeset:   1:b5939750b911
|  branch:      my-feature
|  summary:     start new branch my-feature
|
o  changeset:   0:d554afd54164
   summary:     initial

Questo è tutto .. come menzionato nei commenti alla risposta di Mark, spostare i changeset già inviati in genere è una cattiva idea, a meno che tu non lavori in un piccolo team dove sei in grado di comunicare e imporre la manipolazione della tua cronologia.


4
IMHO lo svantaggio di questa soluzione è che introduce un commit fittizio "start new branch my-feature" (cioè uno che non modifica alcun file).
sschuberth

9
@sschuberth: Penso che essere espliciti sia una buona cosa qui. Se il changeset extra è un problema per te, combinalo con quello successivo (ad esempio usando il foldcomando dell'estensione histedit ora incorporata ).
Oben Sonne

6
@AmirRachum: hg log -G( GraphlogExtension ). Ho rimosso alcune righe manualmente, ma avrebbe anche potuto essere renderizzato in modo completamente automatico utilizzando stili di registro personalizzati .
Oben Sonne


1
@sschuberth Sono d'accordo. La mia soluzione alternativa è riassegnare i tuoi commit non fittizi al genitore del commit fittizio con il flag --keepbranches, e quindi rimuovere il tuo commit fittizio. È molto faticoso cambiare il nome di un ramo, ma a volte Mercurial è stupido in questo modo.
weberc2

30

Puoi usare MqExtension . Supponiamo che i changeset da spostare siano le revisioni 1-3:

hg qimport -r 1:3    # convert revisions to patches
hg qpop -a           # remove all them from history
hg branch new        # start a new branch
hg qpush -a          # push them all back into history
hg qfin -a           # finalize the patches

Voglio importare 63:64 e 66:68. Ricevo la revisione 65 non è il genitore di 64
Casebash

Cosa vuoi fare con 65? Mq può convertire solo changeset consecutivi da una testina. Trasforma i changeset normalmente immutabili in patch mutabili che possono essere modificati. Questo cambia gli hash (che interessano tutti i bambini), quindi non puoi saltare.
Mark Tolonen

Ho una serie di modifiche (incluse 65) che ho apportato al ramo principale e
inviato

1
Non modificare i changeset che sono stati inviati. Mq cambia gli hash in modo che siano effettivamente nuovi changeset. Modifica solo la cronologia che non è stata trasferita.
Mark Tolonen

Se hai già spinto 65, non dovresti assolutamente muoverti 63 e 64 e accontentarti di muoverti 66:68 (di nuovo, solo se non li hai spinti).
Matt

9

Preferisco la soluzione patch descritta qui da Mark Tolonen

Quello che ho:

hg log -G

#default branch
@  changeset:   3:cb292fcdbde1
|
o  changeset:   2:e746dceba503
|
o  changeset:   1:2d50c7ab6b8f
|
o  changeset:   0:c22be856358b

Quello che voglio:

  @  changeset:   3:0e85ae268e35
  |  branch:      feature/my_feature
  |
  o  changeset:   2:1450cb9ec349
  |  branch:      feature/my_feature
  |
  o  changeset:   1:7b9836f25f28
  |  branch:      feature/my_feature
  |
 /
|
o  changeset:   0:c22be856358b

comandi mercurials:

hg export -o feature.diff 1 2 3
hg update 0
hg branch feature/my_feature
hg import feature.diff

Ecco lo stato del mio repository locale

@  changeset:   6:0e85ae268e35
|  branch:      feature/my_feature
|
o  changeset:   5:1450cb9ec349
|  branch:      feature/my_feature
|
o  changeset:   4:7b9836f25f28
|  branch:      feature/my_feature
|
| o  changeset:   3:cb292fcdbde1
| |
| o  changeset:   2:e746dceba503
| |
| o  changeset:   1:2d50c7ab6b8f
|/
|
o  changeset:   0:c22be856358b

Ora devo eliminare le revisioni 1 2 e 3 dal mio ramo predefinito. Puoi farlo con il comando strip dall'estensione di mq. hg striprimuove il changeset e tutti i suoi discendenti dal repository.

Abilita l'estensione aggiungendo le seguenti righe al tuo file di configurazione (.hgrc o Mercurial.ini):

vim ~/.hgrc e aggiungi :

[extensions]
mq =

E ora elimina questo repository nella revisione 1.

hg strip 1

ed eccoci qui

@  changeset:   3:0e85ae268e35
|  branch:      feature/my_feature
|
o  changeset:   2:1450cb9ec349
|  branch:      feature/my_feature
|
o  changeset:   1:7b9836f25f28
|  branch:      feature/my_feature
|
o  changeset:   0:c22be856358b

nota: i changeset sono diversi ma le revisioni sono le stesse


5

Per coloro che sono inclini a utilizzare la GUI

  1. Vai a Tortoise Hg-> File-> Settingsquindi seleziona rebase.

inserisci qui la descrizione dell'immagine

  1. Riavvia l'interfaccia utente della tartaruga

  2. Crea un nuovo ramo in cui sposterai le modifiche. Fai clic sul nome del ramo corrente -> scegli Open a new named branch-> scegli il nome del ramo.

inserisci qui la descrizione dell'immagine

  1. Se i cambiamenti che vuoi spostare non sono stati fatti public(es. draft) Vai al 5. (Se i cambiamenti sono già stati pubblicati e non sei uno sviluppatore senior dovresti parlare con qualcuno senior (prendi un capro espiatorio) perché potresti rovinare le cose alla grande , Non mi assumo alcuna responsabilità :)).

Vai a View-> Show Console(o Ctrl+ L) quindi scrivi in ​​console hg phase -f -d 2- dove 2 è la revisione più bassa che ti sposterai in un nuovo ramo.

  1. Vai a ramo e revisione (dovrebbe essere la revisione più in alto se stai spostando le modifiche a un nuovo ramo creato nel passaggio 3.) Right Mouse->Update

  2. Vai al ramo e revsion da cui sposterai le modifiche Right Mouse-> Modify History->Rebase

inserisci qui la descrizione dell'immagine

  1. Clicca Rebasee prega che non ci siano conflitti, unisci se devi.

  2. Cambiamenti push, a questo punto tutte le revisioni dovrebbero essere ancora draft.

  3. Vai alla revisione più in alto nel ramo in cui stavi spostando le modifiche Right Mouse-> Change Phase to-> Public.

inserisci qui la descrizione dell'immagine

Spero che questo ti faccia risparmiare tempo.


Ottimo lavoro! ci proverò, solo una domanda però: perché cambiare la fase in pubblico alla fine? "Tutti i changeset visti in un repository remoto sono pubblici" quindi quando esegui il push non sarebbe comunque impostato come pubblico?
Joshua Duxbury,

@JoshLeeDucks Quando spingono non cambiano publicpiù in automagicamente (almeno per me non lo fanno).
Matas Vaitkevicius
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.