Con Mercurial, ¿cómo puedo "comprimir" una serie de conjuntos de cambios en uno antes de presionar?

push compression

Question

Digamos que tengo un repositorio Mercurial local y remoto. Ahora, empiezo a trabajar en una característica. Trabajo en eso, y cuando pienso que ya está hecho, me comprometo con el conjunto de cambios. Probándolo un poco más, me parece que podría mejorar aún más esta característica ajustando algo en el código. Hago el cambio y me comprometo. 20 minutos después, descubro que hay un error en esta nueva función, así que lo soluciono y lo confirmo también.

Ahora tengo 3 conjuntos de cambios que realmente me gustaría enviar al repositorio remoto como un conjunto de cambios con el mensaje "Implementación de la característica X", por ejemplo.

¿Cómo puedo hacer esto sin mucha molestia? Creo que podría hacerlo con parches, pero parece mucho trabajo.

Answer 1

¿Por qué no solo hg strip --keep command?

Entonces puedes comprometer todos los cambios como un commit.

Answer 2

¿Qué hay de la extensión colapso ?

Answer 3

HistEdit hará lo que quieras, pero probablemente sea excesivo. Si lo único que necesita es doblar algunos conjuntos de cambios, Collapse Extension hará el trabajo.

Answer 4

La extensión histedit es exactamente lo que estás buscando.

hg histedit -o

o

hg histedit --outgoing

mostrará una lista de los conjuntos de cambios salientes. De la lista puedes

• Doble 2 o más conjuntos de cambios creando un solo conjunto de cambios
• Drop changesets quitándolos del historial
• Reordena los conjuntos de cambios como quieras.

histedit le pedirá el nuevo mensaje de confirmación de los conjuntos de cambios doblados, que se predetermina a los dos mensajes con "/ n *** / n" separándolos.

También puede obtener resultados similares utilizando la extensión mq, pero es mucho más difícil.

También puede usar la extensión de colapso para simplemente doblar, pero no proporciona una interfaz de usuario tan agradable y no proporciona una forma de editar el mensaje de confirmación resultante. Editar el mensaje de confirmación resultante también permite limpiar el mensaje final, que es algo que siempre termino utilizando.

Answer 5

Mi método preferido para usar mq para este plegado es usar TortoiseHg como se describe aquí . Sin embargo, se puede hacer fácilmente desde la línea de comandos de esta manera:

hg qimport -r <first>:<last>
-- where <first> and <last> are the first and last changesets
-- in the range of revisions you want to collapse
hg qpop <first>.diff
-- remove all except for the first patch from the queue
-- note: mq names patches <#>.diff when it imports them, so we''re using that here
hg qfold <next>.diff
-- where <next> is <first>+1, then <first>+2, until you''ve reached <last>
hg qfinish -a
-- apply the folded changeset back into the repository

(Puede haber una forma mejor de hacer el paso qfold, pero no estoy al tanto, ya que suelo usar TortoiseHg para esa operación).

Parece un poco complicado al principio, pero una vez que haya comenzado a usar mq, es bastante sencillo y natural, ¡además de que puede hacer todo tipo de cosas con mq que pueden ser muy útiles!

Answer 6

Nunca he usado Mercurial, pero esto se parece mucho a lo que Martin Fowler estaba hablando en su blog no hace mucho tiempo:

http://martinfowler.com/bliki/MercurialSquashCommit.html

Answer 7

Sí, puedes hacerlo con parches: supongamos que tu trabajo está en los conjuntos de cambios del 100 al 110, inclusive

1. Crea un parche:

   % hg export -o mypatch 100:110 --git

2. Actualización a 99:

   % hg update 99

3. Aplique el parche con --no-commit (de lo contrario, recuperará todos sus conjuntos de cambios):

   % hg import --no-commit mypatch

4. Confirme todos los cambios a la vez:

   % hg commit

5. Ahora tiene dos cabezales (110 y 111) que deberían ser equivalentes en términos de archivos que producen en su directorio de trabajo; tal vez diferenciérselos por cordura antes de quitar los anteriores:

   % hg strip 100

OK, ahora que lo he deletreado todo, parece largo, pero habiéndolo hecho un montón de veces, no me parece demasiado tarea ...

Answer 8

Si está usando TortoiseHg, el uso puede simplemente seleccionar dos revisiones (use CTRL para seleccionar las que no sean posteriores), haga clic derecho y seleccione "Compress History" .

Después de eso obtendrá una nueva lista de cambios en el nuevo encabezado a partir del primer cambio que seleccionó antes, contendrá todas las listas de cambios descendentes entre las que seleccionó.

Simplemente puede quitar viejas listas de cambios si ya no las necesita: use extensiones MQ para ello. De nuevo, en TortoiseHg: haga clic con el botón derecho en la primera lista de cambios que se debe quitar con todos sus descendientes, "Modificar historial -> Franja" .

Answer 9

Supongamos que tiene dos THIS y THAT inéditos que se comprometen en Mercurial y les gusta unirse en una única confirmación en THIS punto:

... --> THIS --> ... --> THAT --> ... --> LAST

Verifica que tus confirmaciones no estén publicadas ::

$ hg glog -r "draft() & ($THIS | $THAT)"

Actualizar a LAST commit ::

$ hg up

e importar confirma hasta THIS en MQ ::

$ hg qimport $THIS::.

Deseleccione todos los parches y aplique solo primero THIS ::

$ hg qpop -a
$ hg qpush
$ hg qapplied
... THIS ...

Únete con THAT ::

$ hg qfold $THATNAME

NOTA Para encontrar el nombre THATNAME use ::

$ hg qseries

Aplique todos los parches y muévalos a la historia del repositorio ::

$ hg qpush -a
$ hg qfinish -a

La publicación de mi blog sobre el tema es unir dos commits en Mercurial .

Answer 10

hg collapse y hg histedit son las mejores formas. O, mejor dicho, serían las mejores formas, si funcionasen de manera confiable ... Me puse a histedit que se histedit con un volcado de pila en tres minutos. Collapse no es mucho mejor.

Pensé que podría compartir otros dos BKM:

1. hg rebase --collapse

   Esta extensión se distribuye con Mercurial. No he tenido problemas con eso todavía. Puede que tenga que jugar algunos juegos para evitar las limitaciones de hg rebase ; básicamente, no le gusta volver a establecer una base de datos para un ancestro en la misma rama, nombrado o predeterminado, aunque sí lo permite si se rebase entre ramas (con nombre).

2. Mueva el repositorio ( foo/.hg ) al directorio de trabajo ( bar ) y sus archivos. No de la otra manera.

Algunas personas han hablado sobre la creación de dos árboles clon y la copia de archivos entre ellos. O parcheando entre ellos. En cambio, es más fácil mover los directorios .hg .

hg clone project work
... lots of edits
... hg pull, merge, resolve
hg clone project, clean
mv work/.hg .hg.work
mv clean/.hg work/.hg
cd work
... if necessary, pull, nerge, reconcile - but that would only happen because of a race
hg push

Esto funciona siempre que los repositorios verdaderos, los árboles .hg , sean independientes del directorio de trabajo y sus archivos.

Si no son independientes ...