used - Hg: cómo hacer una rebase como la rebase de git

rebase strategy git (5)

En Git puedo hacer esto:

1. Start working on new feature: $ git co -b newfeature-123 # (a local feature development branch) do a few commits (M, N, O) master A---B---C / newfeature-123 M---N---O 2. Pull new changes from upstream master: $ git pull (master updated with ff-commits) master A---B---C---D---E---F / newfeature-123 M---N---O 3. Rebase off master so that my new feature can be developed against the latest upstream changes: (from newfeature-123) $ git rebase master master A---B---C---D---E---F / newfeature-123 M---N---O

Quiero saber cómo hacer lo mismo en Mercurial, y he buscado en la red una respuesta, pero lo mejor que pude encontrar fue: git rebase - hg puede hacer eso

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

hg up -C F hg branch -f newfeature-123 hg transplant -a -b newfeature-123

no está tan mal, excepto que deja atrás el MNO anterior a la rebase como una cabeza no combinada y crea 3 nuevos M, N '', O'' confirmados que los representan bifurcando de la línea principal actualizada.

Básicamente el problema es que acabo con esto:

master A---B---C---D---E---F / / newfeature-123 / M''---N''---O'' / newfeature-123 M---N---O

Esto no es bueno porque deja atrás los compromisos locales no deseados que se deben eliminar.

La otra opción desde el mismo enlace es

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

y esto da lugar a la gráfica deseada:

master A---B---C---D---E---F / newfeature-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.

Dado que algunas personas han dicho que creen que es bueno mantener cada iteración de todo, señalaré que para proyectos más grandes de código abierto, aceptar cambios llenos de fusiones y una iteración de desarrollo daría lugar a un historial de revisión de línea principal desordenado, y El historial de revisiones es menos útil para ver cómo llegó allí la versión actual.

Esto funciona bien cuando los cambios enviados son revisados por personas que no los escribieron, antes de ser aceptados, por lo que los cambios que entran en la línea principal generalmente se depuran y funcionan. Luego, cuando retrocedes hacia el origen de una línea, ves todos los cambios que la acompañan, no un punto en el medio del desarrollo del cambio del que forma parte.

La página de colaboradores de 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 cometer algunos cambios, pero no todos, en un archivo individual, como el escenario de git gui / hage diff hunk para cometer).

El proceso consiste en obtener hg actualizado a la punta de flujo ascendente y, a continuación, obtener todos los cambios sin confirmar en el directorio de trabajo. Declare cualquiera que no forme parte de lo que desea enviar, luego divida el resto en tantas confirmaciones separadas que sean apropiadas, con buenos mensajes de confirmación.

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 antiguos compromisos (pizca en el lenguaje de git), y luego corregirlos uno por uno, para obtener sus antiguos mensajes de confirmación como punto de inicio para la edición.

No creo que las respuestas anteriores alcancen el objetivo del OP, que era mantener su rama de tareas, simplemente volver a basarse en un punto posterior en la rama principal.

Digamos que empiezo con este gráfico (generado mediante la extensión graphlog. Serious geek love for graphlog).

Si estoy en la rama feature3 y quiero volver a borrarlo del nuevo compromiso, entiendo que 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 las confirmaciones 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 intentaba 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

Observe que la rama feature3 todavía existe, las dos confirmaciones aún están en la rama feature3 y no están visibles en forma predeterminada. Sin preservar la rama de tareas, no veo cómo esto es funcionalmente diferente de una combinación.

ACTUALIZACIÓN : descubrí la bandera de " --keepbranches soportada por hg rebase, y estoy feliz de informar que todo es okey-dokey. Usando hg rebase -d default --keepbranches , hg rebase -d default --keepbranches exactamente el comportamiento Git que ansiaba. Un par de alias más tarde y estoy cambiando de base como el asunto de nadie.

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 sobre los nuevos cambios remotos. Esta operación se llama rebase.

Obteniendo de :

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

[extensions] rebase =

a ~ / .hgrc.

Luego puede usar los comandos hg rebase , hg pull --rebase , o hg help rebase .

VonC tiene la respuesta que estás buscando , la extensión Rebase. Sin embargo, vale la pena pasar uno o dos segundos pensando en por qué ni mq ni rebase están habilitados de forma predeterminada en mercurial: porque mercurial se trata de conjuntos de cambios indelebles. Cuando trabajo de la manera que estás describiendo, que es casi diaria, 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. Terminé con un nuevo clon 123 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 csets y ver contra qué fueron codificados 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 el control de la fuente es la tarea de demostrarnos que no sucedió lo que deseamos, sino lo que realmente sucedió: cada punto muerto y todo refactor debería dejar una huella indeleble, y volver a basarnos. y otras técnicas de edición de historia ocultan eso.

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