¿Cómo divido el trabajo en varios parches con colas mercuriales?

10

Si llevo un tiempo borrando el código y olvidé crear una serie de parches sobre la marcha, ¿cómo creo la serie de parches de forma retroactiva? Hasta ahora, lo único que viene a la mente es:¿Cómo divido el trabajo en varios parches con colas mercuriales?

# Prepare and test the first batch of changes. 
$ hg qrecord -m 'first batch' 1.patch 
$ hg qnew -m 'stash downstream changes' stash-1.patch 
$ hg qdelete -k temp-1.patch 
$ make hello 
cc  hello.c -o hello 
hello.c: In function ‘main’: 
hello.c:4: error: syntax error at end of input 
make: *** [hello] Error 1 
$ echo '}' >> hello.c 
$ make hello 
cc  hello.c -o hello 
$ hg qrefresh 

# Recover the stashed changes. 
$ patch -p1 < .hg/patches/last.patch 

# And around we go again! 
$ hg qrecord -m 'second batch' 2.patch 
$ hg qnew -m 'stash downstream changes' stash-2.patch 
$ hg qdelete -k stash-2.patch 
$ make hello 
...

Este enfoque muy engorroso también es peligroso. Puede que olvide el -k en qdelete, momento en el que golpearé mi frente contra una pared de ladrillo durante varios minutos, o podría incluir demasiado o muy poco durante la operación de grabación.

¿Hay una manera mejor?

(Lo que realmente me gustaría es poder hg qpop justo antes de un parche que quiero dividir, y utilizar un comando actualmente inexistente, hg qunrecord, para absorber de forma interactiva los cambios del parche en mi directorio de trabajo Una vez que estoy contento con los cambios, hg qnew -f podría apretar un nuevo parche frente al anterior.)

Fuente

2010-01-26 Marcelo Cantos

+0

¿Se trata de dividir en diferentes parches por archivo? Es decir. los cambios para un archivo dado no se dividen en varios parches. Porque si es así, uno puede hacerlo mejor que el enfoque que describió anteriormente. Esta es una vieja pregunta, pero aún relevante. –

+0

@FaheemMitha: Cambié a Git hace bastante tiempo, por lo que no es particularmente relevante para mí.Pero para el registro, ciertamente quiero diferenciar los cambios dentro de los archivos, especialmente los archivos de proyectos de alto nivel que a menudo contienen adiciones/eliminaciones de archivos no relacionados. De hecho, esto es casi la norma más que la excepción. –

+0

Ok. Gracias por los comentarios, Marcelo. –

6

El MQTutorial explica cómo dividir los parches. Por lo tanto, podría crear un parche de su trabajo actual y dividirlo en varios parches.

Fuente

2010-01-31 13:40:38 wierob

+0

Gracias. Esa no es una solución ideal, pero es mucho mejor de lo que he estado haciendo hasta ahora. –

+3

Lo que suelo hacer es usar dos repositorios y una buena herramienta de diferencia visual como Beyond Compare. Usando los nombres en el tutorial, comienzo con el repositorio A con OP aplicado, y clono A a B. Luego, en AI 'qpop -a', diff A y B, selecciono los cambios para P1 para copiar de B a A , 'qnew -f P1', luego copia el resto,' qnew -f P2'. –

2

Creo que crecord extension te permitirá hacerlo. Te ofrece una interfaz interactiva basada en curses donde puedes elegir exactamente lo que está en una confirmación.

Fuente

2010-01-26 00:57:30 RyanWilcox

+0

Basado en una lectura superficial, crecord parece ser un recurso basado en maldiciones equivalente a la extensión de registro. Gracias por señalar esta extensión, ya que parece bastante útil. Sin embargo, no parece reducir el número de pasos que debo realizar; solo hace que el primer paso sea más agradable. –

+1

@MarceloCantos, qcrecord reduce los pasos. Mientras qrecord casi siempre me dice "no puedo editar el parche para todo el archivo", qcrecord me permite alegremente excluir trozos y líneas arbitrarios en mis parches. –

2

TortoiseHg tiene característica muy útil "Trozo de selección" en diálogo de confirmación para la clase de este trabajo:
http://tortoisehg.bitbucket.io/manual/2.0/commit.html#change-selection

Fuente

2010-01-26 06:20:45 kuy

+0

La mayor parte de mi trabajo no está en Windows, pero lo uso ocasionalmente, así que gracias por la sugerencia. Desafortunadamente, al igual que con la sugerencia de @ RyanWilcox, esto parece ayudar con el primer paso en mi proceso, en lugar de simplificar el proceso en general. –

+2

FYI: Si es necesario, puede ejecutar TortoiseHg en Linux y Mac OS :) http://bitbucket.org/tortoisehg/stable/wiki/install – kuy

+0

¡No tenía ni idea! Eso es genial saber –

1

Habilitar incorporados en las extensiones:

[extensions] 
mq= 
record= 
shelve=

a continuación, pasar MQ en cambios de árboles y de división de trabajo y eliminar parche original:

$ hg qpop my.patch 
$ patch -p1 <.hg/patches/my.patch 

$ hg qnew -i my1.patch 
.... 
$ hg qnew -i my2.patch 
.... 
$ hg qnew myN.patch # last without interactive stuff 

$ hg qdelete --keep my.patch

Entre my$i.patch y my$((i+1)).patch puede utilizar hg shelve/hg unshelve para probar si el proyecto se construyó y pasar las pruebas en la parte superior de my$i.patch sin cambios posteriores!

Si encuentra que falta algo en esta etapa, utilice hg qref en cambios archivados o hg qref -i en cambios no protegidos.

Ver también Mercurial: move MQ patch to shelve?

Fuente

2015-01-08 15:33:19 gavenkoa

0

En primer lugar, instale crecord porque es sólo una manera manera más agradable de división cambia hacia arriba.

$ hg qcrecord part1 
$ hg qnew part2 # ok, slightly a lie at this point 
$ hg qpop 
$ echo "}" >> hello.c 
$ hg qrefresh 
$ hg qpush 
$ hg qcrefresh # Keep just what you want in part2 
$ ...

Lo único especial para crecord aquí es el comando qcrefresh. Si no eres un fan de curses, puedes hacer todas las mismas cosas aquí, solo reemplaza qcrefresh con hg qrefresh -X 're:.'. O hg qrefresh -I aauuuuuggghhh si lo prefiere. (Es su "uncommit" usando -X o -I.)

Fuente

2015-10-29 18:12:40 sfink

¿Cómo divido el trabajo en varios parches con colas mercuriales?

Respuesta

Cuestiones relacionadas