version-control mercurial merge push

version control - ¿Cuál es la forma más fácil de enviar y enviar un solo archivo dejando otras modificaciones en paz?



version-control mercurial (6)

Como dijo más fácil, a menudo uso hg commit -i (-interactive) incluso cuando se comprometen archivos completos. Con --interactive puede simplemente seleccionar el archivo (s) que desea en lugar de escribir su (s) ruta (s) completa (s) en la línea de comando. Como una ventaja adicional, puede incluso incluir / excluir fragmentos dentro de los archivos.

Y luego simplemente hg push para empujar esa confirmación recién creada.

Puse más detalles sobre el uso de hg commit --interactive en esta respuesta: https://stackoverflow.com/a/47931672/255961

Soy relativamente nuevo en Mercurial y mi equipo lo está probando ahora como reemplazo de Subversion.

¿Cómo puedo enviar y enviar un único archivo a otro repositorio sin dejar otras modificaciones en mi directorio de trabajo sin confirmar (o al menos no enviarlas al otro repositorio)?

Esto sucede para nosotros con las migraciones de bases de datos. Queremos comprometer la migración al control de origen para que un administrador de bases de datos pueda verlo y editarlo mientras trabajamos en las modificaciones del código para que coincidan con la migración de la base de datos. Los cambios aún no están listos para comenzar, así que no queremos expulsarlos a todos.

En subversión, simplemente lo haría:

svn add my_migration.sql # commit only the migration, but not the other files I''m working on svn commit -m "migration notes" my_mygration.sql

y continuar trabajando localmente

Esto no funciona con mercurial como cuando lo estoy enviando al otro repositorio, si hay cambios que no he bajado, quiere que los tire hacia abajo, los fusione y comprometa esa fusión con el repositorio. Las confirmaciones posteriores a una combinación no le permiten omitir archivos, por lo que le obliga a confirmar todo en su repositorio local.

Lo más fácil que puedo averiguar es enviar el archivo a mi repositorio local, clonar mi repositorio local, buscar cualquier cambio nuevo del repositorio real, fusionarlos y comprometer esa combinación, y ellos eliminan mis cambios.

hg add my_migration.sql hg commit -m "migration notes" my_migration.sql cd .. hg clone project project-clone cd project-clone hg fetch http://hg/project hg push http://hg/project

Esto funciona, pero parece que me falta algo más fácil, una forma de decirle a mercurial que ignore los archivos que ya están en mi directorio de trabajo, simplemente realice la fusión y envíe los archivos. Sospecho que las colas mercuriales pueden hacer esto, pero aún no sé mucho de mq.

Gracias a Josh Matthews a continuación, el comando de archivar es exactamente lo que estoy buscando. No vi ninguna gran instrucción de instalación con Google, aquí están las cosas combinadas que utilicé para que funcione:

Consíguelo con:

hg clone http://freehg.org/u/tksoh/hgshelve/ hgshelve

El único archivo (actualmente) en el proyecto es el archivo hgshelve.py.

Modifique su ~ / .hgrc para agregar la extensión de estantería, señalando dónde clonó el repositorio:

[extensions] hgshelve=/Users/ted/Documents/workspace/hgshelve/hgshelve.py

Entonces puede hacer hg unshelve y hg unshelve para guardar temporalmente los cambios. Le permite trabajar en el nivel "parche de parche" para seleccionar y elegir los artículos que desea guardar. No parecía guardar un archivo en la lista para agregar, solo los archivos que ya están en el repositorio con modificaciones.


Han pasado casi 2 años desde que originalmente planteé esta pregunta. Lo haría de manera diferente ahora (como mencioné en un comentario anterior a la pregunta anterior). Lo que haría ahora sería en cambio enviar mis cambios al único archivo en mi repositorio local (puede usar la extensión de registro hg para solo comprometer partes de un archivo):

hg commit -m "commit message" filename

Entonces solo empuja hacia afuera.

hg push

Si hay un conflicto porque se han realizado otros cambios en el repositorio que necesito fusionar primero, actualizaría a la revisión principal (vista con "hg parents -r." Si no sabes de qué se trata), confirma mis otros cambios allí, así que tengo 2 cabezas. A continuación, vuelva a la confirmación original de archivo único y tire / fusione los cambios en esa versión. Luego presiona los cambios con

hg push --rev .

Para expulsar solo el archivo único y la fusión de esa revisión. Entonces puedes fusionar las dos cabezas que tienes localmente.

De esta forma se deshace de las cosas de mq y del potencial de trozos rechazados y mantiene todo controlado por el control de la fuente. También puede realizar revisiones de "hg strip" si luego decide que no las quiere.


Hay una extensión de Mercurial que implementa comandos de archivar y desenmascarar, que le brindan una manera interactiva de especificar cambios para almacenar hasta un momento posterior: Shelve .


Lo que uso generalmente es el uso para confirmar un solo archivo:

hg commit -m "commit message" filename

En el caso posterior, tengo un conflicto de fusión y todavía no estoy listo para enviar mis cambios, siga estos pasos:

1) Crea un archivo de parche.

hg diff > changes.patch

2) Revertir todos los cambios no confirmados pendientes, solo después de verificar el archivo de parche.

hg revert --all

3) Tire, actualice y fusione a la última revisión

hg pull -u hg merge hg commit -m "local merge"

4) Ahora simplemente importe su parche nuevamente y obtenga sus cambios.

hg import --no-commit changes.patch

Recuerde utilizar la opción -no-commit de la confirmación automática de los cambios.


Otra opción si no desea confiar en las extensiones es mantener un clon de su repositorio de subida localmente que solo utilice para este tipo de tareas de integración.

En su ejemplo, simplemente puede extraer / fusionar su cambio en el repositorio de integración / aguas arriba y enviarlo directamente al servidor remoto.


tl; dr: Mi explicación original parece complicada, pero espero que explique completamente cómo usar una cola de parches. Aquí está la versión corta:

$ hg qnew -m "migration notes" -f migration my_migration.sql $ hg qnew -f working-code # make some changes to your code $ hg qrefresh # update the patch with the changes you just made $ hg qfinish -a # turn all the applied patches into normal hg commits

Mercurial Queues hace este tipo de cosas una brisa, y hace posible una manipulación más compleja de conjuntos de cambios. Vale la pena aprender

En esta situación, primero probablemente quiera guardar lo que está en su directorio actual antes de tirar los cambios:

# create a patch called migration containing your migration $ hg qnew -m "migration notes" -f migration.patch my_migration.sql $ hg qseries -v # the current state of the patch queue, A means applied 0 A migration.patch $ hg qnew -f working-code.patch # put the rest of the code in a patch $ hg qseries -v 0 A migration.patch 1 A working-code.patch

Ahora hagamos un trabajo adicional en el código de trabajo. Voy a seguir haciendo qseries solo para ser explícito, pero una vez que construyas un modelo mental de colas de parches, no tendrás que seguir mirando la lista.

$ hg qtop # show the patch we''re currently editing working-code.patch $ ...hack, hack, hack... $ hg diff # show the changes that have not been incorporated into the patch blah, blah $ hg qrefresh # update the patch with the changes you just made $ hg qdiff # show the top patch''s diff

Debido a que ahora todo su trabajo se guarda en la cola de parches, puede desaplicar esos cambios y restaurarlos después de haber realizado los cambios remotos. Normalmente, para quitar la aplicación de todos los parches, simplemente haz hg qpop -a . Solo para mostrar el efecto sobre la fila de parches, los mostraré uno a la vez.

$ hg qpop # unapply the top patch, U means unapplied $ hg qseries -v 0 A migration.patch 1 U working-code.patch $ hg qtop migration.patch $ hg qpop $ hg qseries -v 0 U migration.patch 1 U working-code.patch

En este punto, es como si no hubiera cambios en su directorio. Haz la hg fetch . Ahora puede volver a activar los cambios en la cola de parches y fusionarlos si hay algún conflicto. Esto es conceptualmente algo similar a la rebase de git.

$ hg qpush # put the first patch back on $ hg qseries -v 0 A migration.patch 1 U working-code.patch $ hg qfinish -a # turn all the applied patches into normal hg commits $ hg qseries -v 0 U working-code.patch $ hg out migration.patch commit info... blah, blah $ hg push # push out your changes

En este punto, has expulsado la migración mientras mantienes tus otros cambios locales. Sus otros cambios están en un parche en la cola. Hago la mayor parte de mi desarrollo personal utilizando una cola de parches para ayudarme a estructurar mejor mis cambios. Si desea deshacerse de la cola de parches y volver a un estilo normal, tendrá que exportar los cambios y volver a importarlos en mercurial "normal".

$ hg qpush $ hg qseries -v 0 A working-code.patch $ hg export qtip > temp.diff $ rm -r .hg/patches # get rid of mq from the repository entirely $ hg import --no-commit temp.diff # apply the changes to the working directory $ rm temp.diff

Soy muy adicto a las colas de parches para el desarrollo y mq es una de las mejores implementaciones que hay. La capacidad de crear varios cambios al mismo tiempo realmente mejora la concentración y la limpieza de sus compromisos. Lleva un tiempo acostumbrarse, pero va increíblemente bien con un flujo de trabajo DVCS.