Hg: Cómo hacer un rebase como el rebase de git

En Git puedo hacer esto:

1. Comience a trabajar en una nueva función:
$ git co -b newfeature-123 # (una rama de desarrollo de características locales)
hacer algunas confirmaciones (M, N, O)

maestro A --- B --- C
                \
novedad-123 M --- N --- O

2. Extraiga nuevos cambios del maestro ascendente:
$ git pull
(maestro actualizado con ff-commits)

maestro A --- B --- C --- D --- E --- F
                \
novedad-123 M --- N --- O

3. Rebase fuera de master para que mi nueva característica 
se puede desarrollar contra los últimos cambios ascendentes:
(de newfeature-123)
$ git rebase master

maestro A --- B --- C --- D --- E --- F
                            \
novedad-123 M --- N --- O

Quiero saber cómo hacer lo mismo en Mercurial, y busqué en la web una respuesta, pero lo mejor que pude encontrar fue: git rebase: ¿puedo hacer eso?

Ese enlace proporciona 2 ejemplos:
1. Admito que esto: (reemplazando las revisiones del ejemplo con las de mi propio ejemplo)

hg arriba -CF  
hg branch -f newfeature-123  
hg transplant -a -b newfeature-123 

no es tan malo, excepto que deja atrás el MNO previo al rebase como una cabeza no fusionada y crea 3 nuevos commits M ', N', O 'que los representan ramificándose de la línea principal actualizada.

Básicamente, el problema es que termino con esto:

maestro A --- B --- C --- D --- E --- F
                \ \
novedad-123 \ M '--- N' --- O '
                  \
novedad-123 M --- N --- O

esto no es bueno porque deja compromisos locales no deseados que deberían descartarse.

2. La otra opción del mismo enlace es

hg qimport -r M: O
hg qpop -a
hg arriba F
hg branch newfeature-123
hg qpush -a
hg qdel -r qbase: qtip

y esto da como resultado el gráfico deseado:

maestro A --- B --- C --- D --- E --- F
                            \
novedad-123 M --- N --- O

pero estos comandos (¡los 6 de ellos!) parecen mucho más complicados que

$ git rebase master

Quiero saber si este es el único equivalente en Hg o si hay alguna otra forma disponible que sea simple como Git.

VonC tiene la respuesta que estás buscando , la extensión Rebase. Sin embargo, vale la pena pasar un segundo o dos pensando por qué ni mq ni rebase están habilitados por defecto en mercurial: porque mercurial se trata de conjuntos de cambios indelebles. Cuando trabajo de la manera que estás describiendo, que es casi a diario, aquí está el patrón que tomo:

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

y eso es realmente todo lo que es necesario. Termino con un nuevo clon de 123 características que puedo empujar fácilmente a la línea principal cuando estoy contento con él. Lo más importante, sin embargo, nunca cambié la historia . Alguien puede mirar mis conjuntos y ver contra qué se codificaron originalmente y cómo reaccioné a los cambios en la línea principal a lo largo de mi trabajo. No todos piensan que eso tiene valor, pero creo firmemente que es el trabajo del control de la fuente mostrarnos no lo que deseamos que hubiera sucedido, sino lo que realmente sucedió: cada diablo y cada refactor deberían dejar un rastro indeleble y un rebase y otras técnicas de edición de historia lo ocultan.

Ahora ve a buscar la respuesta de VonC mientras guardo mi caja de jabón. :)

Quizás estés buscando la extensión Rebase . (implementado como parte del SummerOfCode 2008 )

En esos casos, puede ser útil "separar" los cambios locales, sincronizar el repositorio con la corriente principal y luego agregar los cambios privados además de los nuevos cambios remotos. Esta operación se llama rebase.

Llegando desde :

a:

Como se comenta a continuación por steprobe :

En el caso de que no esté aplicando los cambios y tenga las dos ramas en su repositorio, puede hacer ( usandokeepbranches ):

hg up newfeature-123 
hg rebase -d master --keepbranches

( --keepbranches: Hereda el nombre de la sucursal original).

Mojca menciona:

Me gusta usar hg rebase --source {L1's-sha} --dest {R2's-sha}, pero no sabía que podía agregar --keepbranchesal final.

Como se ilustra a continuación por Jonathan Blackburn :

 hg rebase -d default --keepbranches

Suponiendo que tiene una instalación moderna de Hg, simplemente puede agregar:

[extensions]
rebase = 

a ~ / .hgrc.

A continuación, puede utilizar los comandos hg rebase, hg pull --rebaseo hg help rebase.

No creo que las respuestas anteriores logren el objetivo del OP, que era mantener su rama de tareas, simplemente se basaron en un punto posterior en la rama principal.

Digamos que empiezo con este gráfico (generado usando la extensión de Graphlog. Serio amor geek por Graphlog).

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

Si estoy en la rama de feature3 y quiero volver a basarlo en el nuevo compromiso, entiendo que me ejecutaría hg rebase -d default. Esto tiene el siguiente resultado:

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

¿Misión cumplida? No lo creo. El problema es que cuando los commits en la rama feature3 se volvieron a basar de nuevo, se eliminó la rama feature3 . Mis confirmaciones se han movido a la rama predeterminada, que era lo que estaba tratando de evitar en primer lugar.

En Git, el resultado se vería así:

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

Tenga en cuenta que la rama de feature3 todavía existe, las dos confirmaciones todavía están en la rama de feature3 y no están visibles por defecto. Sin preservar la rama de tareas, no veo cómo esto es funcionalmente diferente de una fusión.

ACTUALIZACIÓN : descubrí la --keepbranchesbandera compatible con hg rebase, y estoy feliz de informar que todo es okey-dokey. Utilizando hg rebase -d default --keepbranches, reproduzco exactamente el comportamiento de Git que ansiaba. Un par de alias más tarde y estoy rebatiendo como si no fuera asunto de nadie.

Dado que algunas personas han intervenido diciendo que piensan que es bueno mantener cada iteración de todo, señalaré que para proyectos de código abierto más grandes, aceptar cambios llenos de fusiones e iteraciones de desarrollo crearía un desordenado historial de revisión de la línea principal, y el historial de revisión es menos útil para ver cómo llegó la versión actual.

Esto funciona bien cuando los cambios enviados son revisados ​​por personas que no los escribieron, antes de que sean aceptados, por lo que los cambios que entran en la línea principal generalmente se depuran y funcionan. Luego, cuando retrocede al origen de una línea, ve todos los cambios que la acompañan, no algún punto en el medio del desarrollo del cambio del que forma parte.

La página de contribuyentes x265 explica cómo volver a confirmar un conjunto de cambios en los que está trabajando, para prepararlos para su envío al proyecto x265. (Incluyendo el uso de TortoiseHG para confirmar algunos, pero no todos, los cambios en un archivo individual, como stage / unstage diff hunk de git gui para commit).

El proceso consiste en actualizar hg a la sugerencia ascendente y luego obtener todos los cambios sin confirmar en el directorio de trabajo. Guarde los que no sean parte de lo que desea enviar, luego divida el resto en tantos commits separados como sea apropiado, con buenos mensajes de commit.

Supongo que copiaría / pegaría y luego editaría los mensajes de confirmación de las iteraciones anteriores de un conjunto de parches que está revisando. O tal vez podría injertar sus antiguas confirmaciones (selección de cereza en lenguaje git), y luego modificarlas una por una, para obtener sus antiguos mensajes de confirmación como punto de partida para la edición.