Atascado con dos ramas predeterminadas en Mercurial después de confirmaciones de rama quebradas

Question

Me encontré con una dificultad en el trabajo (como se presenta en el siguiente esquema simplificado). Durante la creación de una rama, el valor predeterminado, por algún motivo, quedó atascado como padre en una sucursal, pero manteniendo una sucursal predeterminada por separado (esa es la sucursal predeterminada que estamos usando en el futuro). Esto nos ha dejado dos ramas predeterminadas.

Alguien confundió la manera de realizar cambios antes de la bifurcación, por lo que terminamos fusionando los cambios realizados en la rama1 en una rama2.

He estado buscando en Mercurial: the definitive guide para ver si este es un problema que se puede resolver, pero no he podido averiguar qué comandos sobre la retirada o el cierre podrían ayudar. La forma más fácil sería si de alguna manera es posible cambiar el nombre de la rama predeterminada sobrante.

¿Cuál es la mejor y más fácil manera de resolver esto?

Estoy preparando la fusión de las ramas de desarrollo en la rama predeterminada correcta y quiero tener este dolor de cabeza reparado antes de comenzar cualquier fusión importante que podría hacer que sea aún más difícil arreglar esto en el futuro.

Answer 1

Recuerde que los nombres de rama solo son etiquetas ponen en las confirmaciones - no hay nada realmente rota sobre su gráfico. Los nombres de las sucursales no afectan lo que sucede cuando se fusiona, solo el contenido del archivo es importante al fusionarse.

Dicho esto, se puede cerrar la cabeza extra en default, la de abajo branch1:

$ hg update "min(heads(branch(default)))" 
$ hg commit --close-branch -m "closing this head" 

que dejará una estrecha conjunto de cambios que cuelga en el gráfico, lo cual está bien. El cambio cercano ocultará el encabezado de hg heads y comandos como hg merge ya no sugerirán fusionarse con este encabezado.

Answer 2

Pregunta anterior, pero pensé que esto podría ser útil para alguien.

.. Esto ocurre cuando una sola bifurcación se produce, generalmente cuando alguien hace un hg push -f en lugar de tirar y actualizar. En su caso, la cabeza forzada pasa a estar también en otra rama, pero esto también puede suceder en una sola rama. Mi solución sería dejarla reposar hasta que las sucursales se fusionen, al menos, si hay un plan para fusionarlas en algún momento. Esta solución es más limpia que cerrar la cabeza errónea, en mi opinión.

Sin embargo, al hacer hg update default lo llevará a la confirmación más reciente con el nombre 'predeterminado'. Aunque creo que esta idea es la correcta en su caso, esto se debe a que el "valor predeterminado" que realmente desea es la confirmación más reciente con el nombre de la rama "predeterminada", por lo que no debería haber ningún problema. Sin embargo, si la cabeza errónea fuera más reciente, hg update default llevaría a la gente a la cabeza errónea, lo que podría ser bastante confuso.

En cualquiera de los casos, esto podría resolver el problema:

hg update <revision number of correct 'default' head> 
hg merge <branch the erroneous 'default' head is on> 

lo tanto, en este caso, hg update default se actualizará a la cabeza errónea:

1-2(default) 
\ 
    3(default)-4(branch1) 

que tendría que hacer:

hg update 2 
hg merge branch1 
# results in this graph: 
# 1-2---5(default) 
# \ /
# 3-4(branch1) 

mientras que debajo, hg update default se actualizará al que usted actúa dualmente quieren de todos modos:

1-2------------5(default) 
\ 
    3(default)-4(branch1) 

..y sólo podía pasar por alto el valor predeterminado errónea, porque no va a afectar a cualquiera. ..entonces, una vez que alguien hace un hg update default; hg merge branch1, la cabeza errónea desaparecerá silenciosamente, porque en ese punto es un antepasado del 'valor predeterminado' erróneo. ..which resultaría en algo como esto:

1-2-5----------11(default) 
\   /
    3-4-[...]-10(branch1) 

.you podría también hacer un inútil cometen en su defecto deseada, y entonces será el más nuevo, y sería el un pueblo obtienen cuando lo hacen hg update default, pero realmente no me gusta tener commits de basura en la historia.