Sì, si hanno due buone opzioni:
Graft: nuovo in Mercurial 2.0
Questa versione ha introdotto il graft command che può backport cambiamenti in modo intelligente. L ' "intelligenza" è che si userà unioni internamente e questo significa che si ottiene
Supporto per rinomina: Immaginate che si fissa il bug nel file di foo.c
sul ramo di sviluppo. Nel ramo di manutenzione precedente foo.c
è stato chiamato bar.c
. Utilizzando hg graft
, la modifica a foo.c
può essere unita correttamente al vecchio bar.c
.
Unioni a tre vie: L'innesto comprende twisting the graph around e la fusione in tale grafico temporaneo. Il vantaggio delle unioni a tre è che è possibile utilizzare il normale strumento di unione grafica per risolvere i conflitti.
Per copiare la punta di default
su old-branch
è sufficiente eseguire
$ hg update old-branch
$ hg graft default
Transplant: anziani versioni
Prima abbiamo avuto il comando di innesto, la transplant extension era la strada da percorrere. Questa semplice estensione esporterà un changeset come patch e cercherà di applicare la patch su qualche altra revisione.
Poiché abbiamo a che fare con patch "stupide", cose come la rinomina non verranno prese in considerazione e non otterrete il supporto per il vostro strumento di unione poiché non c'è un'unione a tre. Nonostante ciò, ho trovato che il trapianto funziona davvero bene nella pratica.
Utilizzando trapianto è semplice:
$ hg update old-branch
$ hg transplant default
Questo è molto vicino a correre
$ hg update old-branch
$ hg export default | hg import -
la differenza che il trapianto aggiunge anche un pezzo di meta-dati che registra il changeset originale nel changeset trapiantato. Questo può essere usato per saltare i futuri trapianti.
fonte
2012-04-24 07:22:09
http://stackoverflow.com/questions/854930/mercurial-cherry-picking-change-for-commit – zerkms
Lo trovo più semplice se il "ramo di sviluppo principale" è di per sé un albero, in cui diversi cambiamenti sono a loro volta ("anonimo") rami che crescono e vengono rimessi in ... –
(non una risposta, quindi il commento) * "Penso che sarebbe stato meglio apportare la modifica sul ramo più vecchio" * ...È * forse * stato ancora meglio applicare quel bugfix come una "correzione daggy": si ripristina il punto in cui è stato introdotto il bug, si commette la correzione e si fonde a monte. Applicandolo "il prima possibile" * potrebbe * essere anche meglio applicare prima al tuo "ramo più vecchio" (qualunque cosa sia). Per piccole correzioni di errori, daggy fix fa totalmente rock (IMHO): http://mercurial.selenic.com/wiki/DaggyFixes – TacticalCoder