Comparando las diferencias a través de una rebase en Git

Question

Supongamos que acabo de actualizar la rama foo en master, con conflictos. Quiero asegurarme de no dañar accidentalmente el contenido de foo durante la resolución de conflictos introduciendo cambios adicionales o perdiendo cambios (que no sean los adecuados para la resolución de conflictos). He hecho esto a través de:

diff -u <(git diff `git merge-base master foo@{1}` foo@{1}) \ 
     <(git diff `git merge-base master foo ` foo ) 

(actualización o la sintaxis equivalente ... para git-diff la que acabo de ser recordado :)

diff -u <(git diff master...foo@{1}) <(git diff master...foo) | mate 

Esto me muestra todos los cambios que se han producido a master..foo considerado como un parche, que es exactamente lo que quiero comprobar para ser mínimo. Sin embargo, la invocación es compleja y el resultado no es completamente sencillo de interpretar.

¿Hay una manera mejor de llevar a cabo esta tarea? ¿Proporcionar la misma información, pero con un mejor método o formato? ¿O debería simplemente tomar lo anterior y finalizarlo en un script?

Answer 1

Las diferencias entre el maestro y foo porcentualizada:

git diff master..foo

vs

Las diferencias de pre-rebase foo después se desvía maestro (tenga en cuenta tres puntos):

git diff master...foo@{1}

?

Answer 2

Dado que es una base de datos y no una fusión, es posible que desee comparar foo consigo mismo, pero antes de la fusión. Si recuerdo correctamente foo@{1} obtendrá el padre de la confirmación actual para foo, y tal vez esto no es lo que está buscando.

Creo que se puede hacer algo como lo siguiente (suponiendo que no haya hecho un git gc):

En la rama foo después de que el rebase:

$ git reflog 

Esto le mostrará cómo la cabeza de su rama ha sido movido. Debería ver algunos registros de este tipo (dependiendo si se rebase de manera interactiva o no):

64d3c9e HEAD@{15}: rebase -i (finish): returning to refs/heads/master 
64d3c9e HEAD@{16}: rebase -i (fixup): Fixes external dependencies 
049169e HEAD@{17}: rebase -i (fixup): updating HEAD 
d4c2e69 HEAD@{18}: rebase -i (pick): Fixes external dependencies 
049169e HEAD@{19}: rebase -i (fixup): Imports futures 
e490bed HEAD@{20}: rebase -i (fixup): updating HEAD 
... 
etc 
... 

mirar hacia adelante a la última de comprometerse de foo antes de la fusión. Dependiendo de lo que hayas hecho, puede ser difícil o no. Es por eso que no he proporcionado un script do-it.

Recoja el ID de confirmación que tiene la última confirmación para foo antes de la rebase y luego compare con esa identificación de confirmación. Dicen que es Commit Identificación: XXXX:

git diff XXXX...foo 

Tal vez eso es lo que quiere.

Answer 3

Un enfoque ligeramente diferente: Git tiene un buen soporte para mostrar esto en el caso de fusiones. es decir"¿Qué cambió en relación con parent-1 que no puede ser explicado por parent-2?"

Hay un par de maneras que usted puede aprovechar que el apoyo a su rebase:

Opción 1:

1. Haga una de usar y tirar fusionar primero (en lugar de un rebase). Luego, la pantalla de fusión normal mostrará qué cambió. Comprueba que esto es lo que querías.

2. Retroceda y vuelva a calcular, y compare la punta rebasada con el resultado de la combinación: deben ser idénticos.

Opción 2 (si cambio de base es más fácil que la fusión):

1. Haz lo rebase.
2. Usa un injerto para que parezca una combinación local/temporal.

Para ello, crear un .git/info/injertos con una sola línea:

TIP UPSTREAM OLDTIP 

Dónde TIP es el ID de cometer su sucursal porcentualizada y los otros son los dos padres deseados (es decir, las dos cosas que te hubieras fusionado, si hubieras estado fusionándote). Luego examínelo como si fuera una fusión real.

No estoy seguro acerca de la automatización; Tiendo a hacer esto con gitk abierto, porque hace que la comparación de las revisiones correctas sea fácil (usando el menú contextual).

Si realmente quiere comparar dos diffs, entonces puede que quiera ver interdiff (1), pero no estoy seguro de qué tan bien hará frente a los archivos base que son diferentes.

Answer 4

git-cherry busca confirmaciones en una rama que no están en otra. Tendrá que utilizar como:

git cherry -v OLDTIP TIP UPSTREAM 

es decir, buscar confirmaciones que estaban en OLDTIP pero que no son en UPSTREAM..TIP. Mira la firma del parche para ver si se incluye un parche, por lo que si se agregó un parche, se descartó o se modificó durante la rebase, aparecerá en la lista. Las cosas que se aplicaron sin cambios no aparecerán.

Se puede lograr un efecto similar regresando a OLDTIP y haciendo git rebase -i TIP, ya que utiliza la misma lógica para completar la lista de confirmaciones.

Answer 5

Lo que realmente queremos mostrar es la diferencia combinada de conflicto que se genera como si hubiésemos hecho una combinación para obtener de (a) a (b) donde (a) estaba basado previamente (en sentido ascendente) y (b) ahora se basa en (upstream-new).

No queremos solo una diferencia directa.

En su lugar, básicamente podemos hacer la fusión, pero forzar al árbol resultante a ser $ b^{tree}, que ya sabemos que es el punto "final" correcto de lo que queremos.

Más o menos, vamos a suponer que tenemos

newcommit -> the new version of the series 
oldcommit -> the old version of the series 
upstream -> the (new) version of the base of the series 

podemos generar la fusión a través de

git commit-tree newcommit^{tree} -p oldcommit -p upstream -m "message" 

y luego mostrar el resultado de "mostrar git" y esto generará un diff combinado formato que muestra todos los bits necesarios como una resolución de conflicto que ignora automáticamente los cambios que no fueron parte de la resolución de conflictos.

Esto funciona incluso para simplemente ammending un cambio así, y se puede hacer un poco más de trabajo para asegurarse de que la fusión generada cometer tiene autor exacta y marcas temporales para que sea consistente a lo largo de varias llamadas (ya que somos almacenamiento una referencia suelta en la base de datos de objetos).

Desafortunadamente no he podido averiguar cómo hacer que "git diff" difiera de la misma forma sin generar un árbol todavía. No estoy seguro de qué argumentos tendríamos que pasar para llegar a ese punto.