¿La resolución de conflictos de combinación de git es más eficiente que otros SCM y herramientas de fusión?

Question

¿Es git la resolución de conflictos de fusión inherentemente más eficiente que otros SCM (CVS, Subversion, etc.), y también herramientas de fusión independientes? Si es así, ¿por qué?

Aclaración: aquí Estoy más interesado en el algoritmo en sí, ¿es diferente de un método simple diff3?
Algunas herramientas afirman ser más inteligentes en eso (por ejemplo, Guiffy), ¿vale la pena usar una como herramienta de combinación git? ¿Es Git más inteligente para descifrar fragmentos de texto movidos dentro o entre archivos? (en lugar de informar conflictos ruidosos ... tuve una vaga impresión de eso en la charla de Linus).

Antecedentes: acaba de hacer una gran fusión usando git-svn que resultó en la mitad de los conflictos que obtuve con simple svn merge (primera fusión sin seguimiento) .. así que me gustaría entender por qué.

---

El son similares Qs/Como en todo, pero son más sobre el panorama general del proceso, y cómo encaja en la fusión que de forma más natural. A tal fin, se git 'optimizado para fusiones' (en oposición a solamente ramificación), significa en realidad:

1. conflictos menos manuales - mejores algoritmos de auto-resolución (. Por ejemplo el cambio de nombre se maneja muy bien)
2. una operación más segura - auto-resolución deja más únicos conflictos/real y menos falsas alertas
3. más rápida operación - por ejemplo, debido a la magra & significa modelo de objetos
4. mejor utillaje - lo que hace que la experiencia sea menos dolorosa, por ejemplo, seguimiento basado en la combinación de DAG, mergetool, consulta la historia/visualización, escondite, rebase, etc ...
5. algo más
6. una combinación de los anteriores

? Ahora, estoy más que interesado en 1 & 2.

Answer 1

Me encantaría que se demuestre que estoy equivocado en esta respuesta pero ... viniendo de forzado ... esta área de git está un poco subdesarrollada.

1. Combinación automática en git es inexistente. La última versión tiene soporte básico para realizar una combinación usando sus cambios o sus cambios, pero eso es todo. Básicamente, si editas una parte de un archivo y otra persona edita la misma parte de un archivo ... estás solo para la resolución de fusión. El formato diff3 está disponible (fusión de 3 vías) pero creo que el estándar es un formato unificado de diferencias. De hecho, uso araxis como la herramienta de fusión y lo tengo configurado para usar merge 3 vías cuando se ejecuta "git mergetool". Aunque vengo de forzado ... siento que Git está muy atrás en esta área.

2. N/A

actualización RE: Comentarios

no he cavado lo suficientemente profundo en exactamente lo Git es un conflicto y es exactamente lo p4 piensa que es un conflicto, pero aquí es lo que he experimentado en ambos.

• Git no ignora el espacio en blanco al hacer una fusión ... aunque se habla de esto en el futuro para git. p4 puede hacer esto ahora. No ignorar el espacio en blanco es un gran problema a menos que todos en el equipo acuerden usar espacios o pestañas y si desea cambiar la sangría de un archivo ... (por ejemplo, agregar un nodo xml alrededor de otros nodos) entonces esto se hace viejo rápido .
• Siento que cuando encuentro conflictos de fusión en un archivo ... las partes que git dice están en conflicto usando su formato de diferencia unificada son más grandes. Cuando solo cambia una parte de una línea, marcará porciones más grandes según se modifiquen y deberá buscar visualmente los cambios entre las dos áreas de la salida de diff unificada. Sin embargo, puedes evitar esto usando una herramienta de mezcla. p4 puede resolver automáticamente conflictos incluso si edita la misma línea.
• Si está fusionando ramas temáticas de larga vida, entonces se encontrará con un verdadero placer. Sin rerere activado (que está desactivado de forma predeterminada), git olvidará que ya fusionó ese archivo que estuvo en conflicto hace una semana y le pedirá que lo fusione de nuevo. p4 hace esto con facilidad

Mis respuestas aquí son un poco subjetivas ... pero echo mucho de menos la fusión que tuve con forzosamente.

Answer 2

Además, este more recent thread (2012) detalla la noción de "auto-resolución" con Git:

Mi definición de "auto-determinación":
"Durante una combinación, los archivos del árbol de trabajo se actualizan a reflejar el resultado de la combinación ... Cuando ambas partes realizaron cambios en diferentes áreas del mismo archivo, git selecciona ambas partes automáticamente, y deja su decisión para asegurarse de que revise los resultados de la fusión para verificar que sean correctos después de que git haya realizado la fusionar commit ".

IOW, una "resolución automática" significa específicamente que ambos lados (el nuestro y el de ellos) hicieron cambios a file(a) ya que la versión de ancestro común de file(a), y git eligieron ambos lados sin provocar un conflicto de combinación.
(La razón por la que surgió el término "resolución automática" se debe a que en el resultado git-merge el término "Combinación automática" también puede indicar que solo un lado (el suyo) cambió file(a) ya que el antepasado común y ese git es . simplemente "avance rápido" de ellos file(a) en la parte superior de común ancestro file(a))

Junio C Hamano plantea como respuesta un punto importante:

• saber Git es estúpida y yerra en el lado seguro, pateando cualquier cosa remotamente compleja;
• saben que los conflictos textuales que ocurren en el mismo archivo tienen el mismo riesgo de tener conflictos semánticos en diferentes archivos, por lo que señalar "tocó el mismo archivo pero no entró en conflicto" es inútil, pero en cualquier caso, la posibilidad de tener un conflicto de este tipo es lo suficientemente pequeña como para completar la combinación (y otras fusiones) primero y luego verificar el resultado general, es un uso más eficiente de tu tiempo, porque tienes que mirar el resultado al menos una vez antes de sacarlo.