¿Hay un comando de Mercurial que se puede usar después de hg pull
para ver una lista de todos los archivos que se necesitarán fusionar manualmente (es decir: que tienen conflictos) al hacer un hg merge
?Mercurial: consulte la lista de archivos que deben combinarse manualmente.
Respuesta
hg resolve --list
Desde el documentation:
se fusiona con conflictos no resueltos son a menudo el resultado de la fusión no interactiva con el interior: fusionar ajuste de configuración, o una herramienta de combinación de línea de comandos como diff3. El comando de resolución se usa para administrar los archivos involucrados en una combinación, después de que se haya ejecutado hg merge, y antes de ejecutar hg commit (es decir, el directorio de trabajo debe tener dos padres).
Editar 5 enero de 2012:
(. He recibido un voto para esta respuesta hoy, así que volvió a visitar que descubrí que no he entendido bien la pregunta.)
La pregunta es "Realicé una extracción desde un repositorio remoto y aún no se han realizado. ¿Puedo ver qué conflictos se crearán al realizar la fusión?"
Mi respuesta anterior es claramente incorrecta. Después de leer la documentación vinculada, no creo que haya un método incorporado para hacerlo. Sin embargo, hay una manera de hacerlo sin arruinar su árbol fuente de trabajo.
Vamos a suponer que ha clonado repositorio Un de una fuente remota al repositorio B en el sistema local, es decir hg clone http://hg.example.com/A B
. Después de hacerlo, realiza cambios en su repositorio local, B, que implica al menos una confirmación. Mientras tanto, se han realizado cambios en el repositorio A de modo que cuando hagas una extracción recibas un mensaje que indique que se han agregado nuevos conjuntos de cambios y se han creado los cabezales.
En este punto, puede hacer hg heads
para listar los dos conjuntos de cambios que estarán involucrados en una fusión. A partir de esta información, puede emitir un comando de estado para enumerar las diferencias entre los encabezados. Suponiendo que los números de revisión en su repositorio B, de acuerdo con la lista de cabezas, son "1" y "2", entonces puede hacer hg status --rev 1:2
para ver una lista de los cambios.
Por supuesto, esto realmente no te dice si ocurrirán conflictos cuando haces una fusión. Como no hay un comando que le muestre esto, tendrá que "previsualizar" la fusión clonando en un nuevo repositorio y haciendo la fusión allí. Entonces, hg clone B C && cd C && hg merge
. Si está satisfecho con el resultado de esta combinación, puede hacer hg com -m 'Merging complete' && hg push && cd ../ && rm -rf C
.
Es un proceso un poco largo, pero mantiene su árbol fuente actual limpio si la combinación resulta ser un desastre. También puede encontrar útil this description de trabajar con repositorios públicos.
Mi primera respuesta fue incorrecta. –
Leí mal la pregunta de la misma manera que lo hizo, así que su respuesta fue correcta para mí. – MasterScrat
Creo que hg status
es lo que estás buscando.
Es posible que desee leer este capítulo de Mercurial: La guía definitiva
hg estado simplemente muestra "M" para todos los archivos modificados, ya sea en conflicto o no. Sin embargo, hg resolve --list funciona de hecho. –
Puede utilizar la opción --rev de hg stat con un par de revisiones para ver qué archivo existen diferencias entre los dos. A continuación encontrará un ejemplo un poco prolijo pero detallada:
En primer lugar, empezar por hacer un nuevo repositorio:
[gkeramidas /tmp]$ hg init foo
[gkeramidas /tmp]$ cd foo
A continuación, agregue un solo archivo llamado foo.txt
al nuevo repositorio:
[gkeramidas /tmp/foo]$ echo foo > foo.txt
[gkeramidas /tmp/foo]$ hg commit -Am 'add foo'
adding foo.txt
[gkeramidas /tmp/foo]$ hg glog
@ 0[tip] b7ac7bd864b7 2011-01-30 18:11 -0800 gkeramidas
add foo
Ahora agregue un segundo archivo, llamado bar.txt
como revisión 1:
[gkeramidas /tmp/foo]$ echo bar > bar.txt
[gkeramidas /tmp/foo]$ hg commit -Am 'add bar'
adding bar.txt
Regrese a la revisión 0 y agregue un tercer archivo en otra cabeza . Esto se hace para simular un tirón de otra persona que se había clonado el mismo repositorio en su revisión de partida:
[gkeramidas /tmp/foo]$ hg up -C 0
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
[gkeramidas /tmp/foo]$ echo koko > koko.txt
[gkeramidas /tmp/foo]$ hg commit -Am 'add koko'
adding koko.txt
created new head
[gkeramidas /tmp/foo]$ hg glog
@ 2[tip]:0 e5d80abdcb06 2011-01-30 18:12 -0800 gkeramidas
| add koko
|
| o 1 a2d0d0e66ce4 2011-01-30 18:12 -0800 gkeramidas
|/ add bar
|
o 0 b7ac7bd864b7 2011-01-30 18:11 -0800 gkeramidas
add foo
Ahora puede utilizar hg stat para ver qué archivos existen diferencias entre cualquier par de revisiones, p.ej los cambios de revoluciones de 0 a 1 rev añade 'bar.txt' a la lista de archivos:
[gkeramidas /tmp/foo]$ hg stat --rev 0:1
A bar.txt
Los cambios de revoluciones de 0 a rev2 añaden 'koko.txt' a la lista de archivos:
[gkeramidas /tmp/foo]$ hg stat --rev 0:2
A koko.txt
Pero, lo que es más interesante, los cambios de rev 1 a rev 2 implican dos cambios en el archivo de manifiesto. (1) 'koko.txt' se agregó en rev 2, y (2) 'bar.txt' existe en la versión 1 pero falta en la versión 2, por lo que se muestra como un archivo 'eliminado':
[gkeramidas /tmp/foo]$ hg stat --rev 1:2
A koko.txt
R bar.txt
A menos que me malinterprete, las respuestas anteriores no parecen abordar la pregunta que creo que se hace: tengo dos ramas en mi repositorio que me gustaría fusionar, y quiero saber qué conflictos surgirán (p. ej., antes de pasar a través de las resoluciones de conflictos uno a uno.)
Para hacer esto, me fusionaría con la herramienta :merge3
(que intenta fusionarse automáticamente, pero deja confl icts no resuelto) y luego use hg resolve --list
- o simplemente mire la salida del comando merge - para ver los conflictos.
hg merge <otherbranch> --tool :merge3
hg resolve -l
Si en realidad no desea combinar en el final (si lo que desea es ver lo que entraría en conflicto) puede ejecutar hg update -C
después de deshacer la combinación.
Si desea terminar la fusión, puede ejecutar hg resolve <filepath>
para cada archivo, o simplemente hg resolve --all
para pasar por todo lo que queda de conflictos, antes de hg commit
el conjunto de cambios de combinación.
- 1. Recursos que deben limpiarse manualmente en C#?
- 2. Consulte una revisión mercurial relativa a una revisión nombrada
- 3. Cómo obtener la lista de archivos que se vieron afectados desde una revisión específica en Mercurial
- 4. Mercurial que muestra archivos modificados incorrectamente
- 5. ¿Qué archivos/carpetas en una solución C# de Visual Studio 2010 deben ir a Mercurial DVCS?
- 6. ¿Cómo hacer que mercurial ignore todos los archivos ocultos?
- 7. Consulte 'Archivos de programa' en una máquina de 64 bits
- 8. Mercurial: restaurar archivos
- 9. Mercurial: Ignorar globalmente archivos
- 10. Mercurial: enumere archivos "hg diff"
- 11. ¿Se puede decir que no se deben analizar ciertos archivos?
- 12. diffing solamente archivos en Mercurial
- 13. ¿Por qué Mercurial cree que mis archivos SQL son binarios?
- 14. dinámicamente crear archivos WIX sin tener que editar manualmente los archivos de Wix
- 15. Mercurial - no puede cometer errores fusionarse con archivos que faltan
- 16. Lista de caracteres Unicode que se deben filtrar en la salida?
- 17. ¿Los archivos .dmg deben estar firmados?
- 18. Criterios JPA Consulte distinta
- 19. Consulte la ventana activa en WPF?
- 20. Consulte ActionBarSherlock de una biblioteca
- 21. Caracteres que se deben escapar en Tsql
- 22. extraer archivos de una revisión específica - mercurial
- 23. Mercurial, cómo etiquetar la versión anterior de los archivos
- 24. Mercurial: forma sencilla de volver .orig archivos?
- 25. Mercurial: ¿todos los archivos que cambiaron en un conjunto de cambios?
- 26. Cuando dos tablas son muy similares, ¿cuándo deberían combinarse?
- 27. Consulte la pila de llamadas durante la depuración en Pydev
- 28. ¿Cómo aumenta el número de archivos que se muestran en la lista de archivos Recientemente abiertos?
- 29. Commitir solo algunos archivos en Mercurial
- 30. mercurial .hgignore - no ignorará los archivos
Sé que ha pasado casi un año, pero me acabo de dar cuenta de que mi respuesta no era del todo correcta para su pregunta. Lo he actualizado a una respuesta que podría ser satisfactoria. –