163 votos

HG: Cómo hacer un rebase como git ' rebase s

En Git puedo hacer esto:

1. Empezar a trabajar en nueva característica:
$ git co-b newfeature-123 # (un local de la función de desarrollo de la rama)
unos pocos se compromete a (M, N, O)

master A---B---C
\
newfeature-123 M---N---O

2. Tire de nuevo los cambios de aguas maestro:
$ git pull
(master actualizado con ff-commits)

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

3. Reajuste de la principal para que mi nueva característica de 
puede ser desarrollado en contra de la última aguas arriba de los cambios:
(de newfeature-123)
$ git rebase maestro

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 web para una respuesta, pero la mejor que pude encontrar fue: git rebase - puede hg hacer que

Que el enlace le ofrece 2 ejemplos:
1. He de admitir que esta: (en sustitución de la revisión en el ejemplo con los de mi propio ejemplo)

hg hasta-C F 
hg branch-f newfeature-123 
hg trasplante-a-b newfeature-123 

no es tan malo, excepto que se deja atrás la pre-reajuste de la M-N-O como una anulación de fusión de la cabeza y crea 3 nuevos commits M',N',O' que representan a ellos se ramificaban de la actualización de la línea principal.

Básicamente el problema es que yo termino 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 detrás de local, no deseados se compromete a que deberían ser descartados.

  1. La otra opción desde el mismo enlace es
hg qimport-r M:O
hg qpop-un
hg hasta F
hg branch newfeature-123
hg qpush-un
hg qdel-r qbase:qtip

y este es el resultado en el gráfico deseado:

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

pero estos comandos (todos los 6 de ellos!) parece mucho más complicado de lo que

$ git rebase maestro

Quiero saber si esta es la única equivalente en Hg o si hay alguna otra manera que sea sencilla, como la de Git.

187voto

Ry4an Puntos 56453

VonC tiene la respuesta que usted está buscando, el Reajuste de la Extensión. Es, sin embargo, vale la pena pasar una o dos segundos a pensar acerca de por qué ni mq ni rebase están activado por defecto en mercurial: porque mercurial es todo acerca de la indeleble conjuntos de cambios. Cuando yo trabajo en la manera que usted describe, que es casi a diario, he aquí el modelo que se tome:

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 una newfeature-123 clon que fácilmente se puede empujar hacia atrás a la línea principal cuando estoy feliz con ella. Lo que es más importante, sin embargo, yo nunca cambió la historia. Alguien puede mirar en mi csets y ver lo que originalmente fueron codificados en contra y cómo he reaccionado a los cambios en la línea principal a lo largo de mi trabajo. No todo el mundo piensa que tiene valor, pero soy un firme creyente de que el trabajo de control de código fuente para mostrar que no nos lo hemos querido que había sucedido, pero lo que en realidad sucedió, cada deadend y cada refactorizar debería dejar un rastro imborrable, y del reajuste y otros de la historia de las técnicas de edición de ocultar eso.

Ahora ir a buscar VonC la respuesta de mientras pongo mi tribuna de distancia. :)

83voto

VonC Puntos 414372

Lo que está mal con el Reajuste de la Extensión? (implementados como parte de la SummerOfCode 2008)

En aquellos casos en los que puede ser útil para "separar" los cambios locales, sincronizar el repositorio con la corriente principal y, a continuación, añadir los privados cambios en la parte superior de los nuevos cambios de distancia. Esta operación se llama reajuste.

Llegar desde:

alt text

a:

alt text

36voto

sblom Puntos 15074

Asumiendo que usted tiene una instalación moderna de Hg, simplemente puedes añadir:

[extensions]
rebase = 

a ~ / .hgrc.

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

13voto

No creo que las respuestas anteriores alcanzar el OP del objetivo, que era mantener su tarea rama, apenas rebasada en contra de un punto posterior en el branch principal.

Digamos que voy a empezar con este gráfico (generado mediante el graphlog extensión. Seria geek amor 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 el feature3 rama y quieres reajuste de la againagainagain cometer, entiendo que me iba a correr 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? Yo no lo creo. El problema es que cuando el cometa en el feature3 rama se reajusta en againagainagain, el feature3 rama fue eliminado. Mi cometa se han trasladado a la rama predeterminada, que era lo que yo estaba tratando de evitar en primer lugar.

En Git, el resultado sería parecido a este:

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

Observe que el feature3 rama todavía existe, los dos comete todavía están en el feature3 rama, y no visibles por defecto. Sin la preservación de la tarea de la rama, no veo cómo esto es funcionalmente diferente de una combinación.

ACTUALIZACIÓN: he descubierto la --keepbranches bandera apoyada por hg de reajuste, y me alegra informar de que todo está okey-dokey. Utilizando hg rebase -d default --keepbranches, me replican exactamente a la Git comportamiento que ansiaba. Un par de alias más tarde y estoy de reajuste como nadie.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X