Sí, tiene dos buenas opciones:
injerto: en nuevos Mercurial 2.0
Esta versión introdujo el graft command que puede acondicionarlo cambios de una manera inteligente. La "inteligencia" es que va a utilizar fusiones internamente y esto significa que se obtiene
Soporte para renombrado: Imagínese que usted ha solucionado el error en el archivo foo.c en la rama de desarrollo. En la rama de mantenimiento anterior foo.c se llamaba bar.c. Con hg graft, el cambio a foo.c se puede combinar correctamente en el antiguo bar.c.
Combinación de tres vías: Injerto implica twisting the graph around y la fusión en ese gráfico temporal. La ventaja de las combinaciones a tres bandas es que puedes usar tu herramienta de fusión gráfica normal para resolver conflictos.
Para copiar la punta de default en old-branch sólo tiene que ejecutar
$ hg update old-branch
$ hg graft default
Trasplante: las versiones anteriores
Antes de tener el comando del injerto, la transplant extension era el camino a seguir. Esta simple extensión exportará un conjunto de cambios como un parche y tratará de aplicar el parche a alguna otra revisión.
Como estamos tratando con parches "tontos", no se tendrán en cuenta los cambios de nombre, por ejemplo, y no obtendrá soporte para su herramienta de combinación, ya que no existe una combinación de tres vías. A pesar de esto, he descubierto que el trasplante funciona muy bien en la práctica.
El uso de trasplante es simple:
$ hg update old-branch
$ hg transplant default
Esto es muy cerca de quedarse
$ hg update old-branch
$ hg export default | hg import -
excepto que el trasplante también añade un trozo de meta datos que registra el conjunto de cambios original en el conjunto de cambios trasplantado. Esto se puede usar para omitir trasplantes futuros.
http://stackoverflow.com/questions/854930/mercurial-cherry-picking-changes-for-commit – zerkms
Me resulta más fácil si la "rama de desarrollo principal" es en sí misma un árbol, donde los cambios son diferentes en sí mismos ("anónimo") ramas que crecen y luego vuelven a ponerse en ... –
(no es una respuesta, de ahí el comentario) * "Creo que hubiera sido mejor hacer el cambio en la rama anterior" * ...Es * posible * que haya sido incluso mejor aplicar esa corrección de errores como una "corrección de daggy": se retrocede al lugar donde se introdujo el error, se compromete la solución y se fusiona en sentido ascendente. Aplicarlo "lo antes posible" * puede * incluso ser mejor que aplicarlo primero a su "rama anterior" (lo que sea que sea). Para pequeñas correcciones de errores daggy fix hacer totalmente rock (en mi humilde opinión): http://mercurial.selenic.com/wiki/DaggyFixes – TacticalCoder