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

¿La resolución de conflictos de fusión de git es 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 algorithm 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 conectar una como una herramienta de combinación git? ¿Es Git más inteligente para descifrar fragments de text movidos dentro o entre files? (en lugar de informar conflictos ruidosos … tuve una vaga printing de eso en la charla de Linus).

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


Las Qs / As son similares, pero se tratan más de la image general del process y de cómo la fusión se ajusta de forma más natural. Para eso, al ser 'optimizado para fusionarse' (en lugar de solo ramificarse), ¿significa en realidad:

  1. less conflictos manuales: mejores algorithms de resolución automática (por ejemplo, el cambio de nombre se maneja muy bien)
  2. operación más segura: la resolución automática deja más / solo conflictos reales y less alertas falsas
  3. operación más rápida, por ejemplo, debido al model de objects magros y medios
  4. mejores herramientas, lo que hace que la experiencia sea less dolorosa, por ejemplo, seguimiento de fusión basado en DAG, herramienta de combinación de merge, consulta / visualización de historial, ocultación, rebase, etc.
  5. algo más
  6. Una combinación de lo anterior

? Ahora, estoy principalmente interesado en 1 y 2.

Me encantaría que se demuestre lo contrario en esta respuesta, pero … viniendo de forzosamente … esta área de git está un poco subdesarrollada.

  1. La fusió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 file y otra persona edita la misma parte de un file … estás solo para la resolución de fusión. El formatting diff3 está disponible (fusión de 3 vías) pero creo que el estándar es un formatting 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

Actualizar RE: comentarios

No he profundizado lo suficiente en lo que git piensa que es un conflicto y exactamente lo que p4 piensa que es un conflicto, pero esto 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 less que todos en el equipo acuerden usar espacios o tabs y si desea cambiar la sangría de un file … (por ejemplo, agregar un nodo xml alnetworkingedor de otros nodos) entonces esto se hace viejo rápido .
  • Siento que cuando encuentro conflictos de fusión en un file … las partes que git dice están en conflicto usando su formatting 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á search 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 twigs temáticas de larga vida, entonces se encontrará con un verdadero placer. Sin rerere activado (que está desactivado de forma pnetworkingeterminada), git olvidará que ya fusionó ese file que estuvo en conflicto hace una semana y le pedirá que lo fusione de nuevo. p4 lo hace con facilidad

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

Además, este hilo más reciente (2012) detalla la noción de "auto-resolución" con Git:

Mi definición de "resolución automática":
"Durante una fusión, los files del tree de trabajo se actualizan para reflejar el resultado de la combinación … Cuando ambas partes realizaron cambios en diferentes áreas del mismo file, git selecciona ambas partes automáticamente y deja su tarea para asegurarse de que revise los resultados de la fusión para ver si son correctos después de que git haya confirmado la fusión ".

IOW, una "resolución automática" significa específicamente que ambos lados (el nuestro y el suyo) hicieron cambios en el file(a) desde la versión del antecesor común del file(a) , y git escogió ambos lados sin generar un conflicto de combinación.
(La razón por la que se me ocurrió el término "resolución automática" es porque en la salida de git-merge , el término "Combinación automática" también puede indicar que solo un lado (el suyo) cambió el file(a) desde el ancestro común y ese git solo está "reenviando rápidamente" el file(a) ellos file(a) sobre el file(a) ancestro común file(a) .

Junio ​​C Hamano plantea en respuesta un punto importante:

  • saber que git es estúpido y se equivoca en el lado seguro , pateando cualquier cosa remotamente compleja;
  • Sabemos que los conflictos textuales que ocurren en el mismo file tienen el mismo riesgo de tener conflictos semánticos en diferentes files, por lo que señalar "tocó el mismo file pero no entró en conflicto", cualquier especial no tiene sentido, pero en cualquier caso, la posibilidad de tener tal conflicto es tan pequeño que completar la combinación (y otras fusiones) primero y luego verificar el resultado general es un uso más eficiente de tu time, porque tienes que mirar el resultado al less una vez antes de sacarlo.
    Intereting Posts