¿Por qué Mercurial no necesita una "estrategia de fusión recursiva"?

La estrategia de fusión pnetworkingeterminada de AFAIK git es "recursiva", lo que significa que cuando más de un "antecesor común" termine siendo un "buen candidato", git los fusionará y creará un nuevo "ancestro común virtual" para los contribuyentes. Básicamente, ayuda a resolver situaciones en las que los files ya se fusionaron y evita fusionarlos de nuevo o generar contribuidores de combinación incorrectos.

Mi pregunta es: si Mercurial no usa "recursivo", ¿cómo maneja la misma situación?

Gracias

La mayoría de los sistemas de control de versiones no saben cómo manejar una situación en la que hay múltiples versiones base para una fusión. La ecuación de fusión matemática es

Result = Destination + SumOf(I=1-N)(Base(I) - Source(I))

En la mayoría de los casos, N = 1 y obtiene una fusión clásica con las versiones de origen, destino y base que puede manejar una herramienta típica de combinación de 3 vías. Aunque muchos sistemas de control de fuente no tienen, incluso en este caso simple, un algorithm correcto para encontrar la versión Base. Para hacerlo, debe rastrear el tree de versiones subiendo las flechas de fusión, hasta que se encuentre con un ancestro común. Pero a veces el ancestro común está demasiado lejos, no se ajusta a la ecuación anterior para N = 1 y en ese caso es necesario encontrar múltiples ancestros comunes para fusiones parciales múltiples.

Ejemplo sería un caso en el que una twig se fusiona hacia abajo y hacia arriba varias veces, luego intentamos fusionar los cambios de esta twig a otra. En tal caso, N> 1, pero menor que el número de fusiones en la twig fuente.

Esta es una de las cosas más difíciles de hacer en la fusión de sucursales y no conozco un sistema de control de fuente que realmente lo haga correctamente.