mercurial - tutorial - Marcar los cambios como ya fusionados o ignorados deliberadamente con hg pull/push/merge/graft?

mercurial repository tutorial

Question

Estoy haciendo la transición a Mercurial desde Subversion, donde estoy acostumbrado a usar svnmerge.py para rastrear cambios que ya se han fusionado o que se han bloqueado para que no se combinen:

# Mark change 123 as having already been merged; it will not be merged again, even if a range
# that contains it is subsequently specified.
svnmerge.py merge -M -r123
#
# Block change 326 from being considered for merges.
svnmerge.py merge -X -r326
#
# Show changes that are available for merging from the source branch.
svnmerge.py avail
#
# Do a catchall merge of the remaining changes. Neither change 123 nor change 326 will be
# considered for merging.
svnmerge.py merge

Quiero ser capaz de hacer algo similar para hg pull / push / merge / graft, de modo que si sé que no quiero fusionar un cambio dado, puedo bloquearlo para que no se tenga en cuenta, haciendo un posterior "cherry picking", fusión, etc., en un asunto más de fuego y olvido. He hecho muchas búsquedas en Google, pero no he encontrado la forma de hacerlo.

También parece que no hay forma de ver una lista de cambios aún no implantados.

Como a menudo estoy ordenando a otros desarrolladores y ayudándoles con sus fusiones, es inmensamente útil poder hacer este tipo de cosas, que uno podría considerar como "inversión inversa"; es decir, marcar cambios que NO desea fusionar, y luego hacer una fusión masiva del resto.

Answer 1

Los sistemas basados ​​en DAG como Mercurial y Git son todo o nada: cuando fusionas dos ramas, haces una fusión de tres vías del ancestro común y las dos ramas.

La combinación de tres vías solo se refiere a la etapa final de cada rama. Por ejemplo, no importa si realiza los cambios en 10 o 1000 pasos: el resultado de la fusión será el mismo.

Esto implica que la única forma de ignorar un conjunto de cambios es retroceder antes de la fusión:

$ hg backout BAD

Eso cancelará el conjunto de cambios en la rama, haciendo que parezca que nunca se hizo desde la perspectiva de la combinación de tres vías.

Si tiene una rama completa que desea fusionar, pero ignorar, puede hacer una combinación ficticia :

$ hg merge --tool internal:local --non-interactive
$ hg revert --all --rev .

Eso pasa por la fusión, pero vuelve al estado anterior antes de comprometerse.

El mejor consejo que puedo darte es estructurar tu flujo de trabajo para que los retrocesos anteriores no sean necesarios. Esto significa comprometer una corrección de errores en la rama aplicativa más antigua . Si se encuentra un error al crear la característica X, entonces use hg bisect para descubrir cuándo se introdujo el error. Ahora actualizado de nuevo a la rama más antigua donde todavía desea corregir el error:

$ hg update 2.0
# fix bug
$ hg commit -m "Fixed issue-123"

luego fusiona la corrección de errores en todas las ramas posteriores:

$ hg update 2.1
$ hg merge 2.0
$ hg commit -m "Merge with 2.0 to get bugfix for issue-123"
$ hg update 2.2
$ hg merge 2.1
$ hg commit -m "Merge with 2.1 to get bugfix for issue-123"

Si la corrección de error ya no se aplica, entonces aún debe fusionarse , pero descartar los cambios no relacionados:

$ hg update 3.0
$ hg merge 2.2 --tool internal:local --non-interactive
$ hg revert --all --rev .
$ hg commit -m "Dummy merge with 2.2"

Eso asegura que siempre puedes usar

$ hg log -r "::2.2 - ::3.0"

para ver los conjuntos de cambios en la rama 2.2 que aún no se han fusionado en 3.0.