¿Cómo comparar los sets de cambios en Git?

Git hace que sea muy fácil comparar las diferencias entre commits, usando por ejemplo los commands git diff y difftool. También en TortoiseGit solo seleccionas dos commits para compararlos.

Pero, ¿hay alguna manera de comparar los sets de cambios ? En otras palabras: para ver las diferencias entre las diferencias de un set de confirmaciones y las difs de otro set de confirmaciones.

Esto sería muy útil para comparar (sets de) confirmaciones que se seleccionan o se han vuelto a establecer.

Quizás diff <(git show rev1) <(git show rev2) hará lo que quieras?

Creo que, en general, para get lo que desea, tendrá que hacer algún tipo de operación de combinación / rebase para crear algo con lo que comparar.

Cuando realmente piensas en ello, la idea de una diferencia entre los sets de cambios es difusa. Supongo que estás en una situación como esta:

 [other history] [ "changeset 1" ] o - o - o - o - o ( - o - o - o - o) \ (o - o - o - o - o) [ "changeset 2" ] 

Entonces, ¿qué significa comparar esos dos? Tal vez en su caso, las diferencias en la otra historia son completamente disjuntas de las de los dos sets de cambios, pero en general, el contenido del set de cambios 1 puede depender de esa otra historia. Esto significa que no hay una buena manera general para que git realice una operación como esta; para hacerlo correctamente, tendría que decir esencialmente "¿cuál sería la diferencia entre los dos extremos si se actualiza?" En otras palabras, creo que la única definición razonable de la diferencia entre los sets de cambios es la diferencia entre los compromisos finales resultantes si se vuelven a establecer para tener un antecesor común. Y, por supuesto, si eso es lo que quieres, entonces tendrás que realizar una operación en el tree de trabajo: no hay otra manera de research con dificultades como esta. Lo más obvio sería volver a establecer la base y comparar los nuevos puntos finales (twigs):

 [other history] [ "changeset 1" ] o - o - o - o - o ( - o - o - o - o) \ (o - o - o - o - o) [ "changeset 2'" ] 

Sin embargo, las rebases no siempre son las más divertidas, y puedo pensar en una pequeña forma de evitar esto. El tree de trabajo resultante de la rebase, suponiendo que resuelva los conflictos de forma adecuada, debe ser el mismo que el resultado de una fusión:

 [other history] [ "changeset 1" ] o - o - o - o - o ( - o - o - o - o) \ \ \ ------ \ \ (o - o - o - o - o) - X [ "changeset 2" ] 

De modo que podría realizar esa fusión temporal y comparar la confirmación resultante con la confirmación final del otro set de cambios. Eso será mucho más rápido que hacer la rebase. (De cualquier forma, por supuesto, usarás una twig desechable, no la verdadera para el set de cambios 2).

Esto es lo que funcionó para mí para comparar dos sets de cambios:

 git diff [base_sha_a]..[final_sha_a] > ./a.diff git diff [base_sha_b]..[final_sha_b] > ./b.diff diff ./a.diff ./b.diff 

Si el resultado del command diff está vacío, los sets de cambios son los mismos. De lo contrario, verás la diferencia entre las dos diferencias.

 git diff end_rev_1...end_rev_2 

Tomado de: http://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html

Una notación similar r1 … r2 se llama diferencia simétrica de r1 y r2 y se define como r1 r2 –not $ (git merge-base –todo r1 r2). Es el set de confirmaciones accesibles desde cualquiera de r1 o r2 pero no desde ambos.

Y de la ayuda de git diff:

 git diff [--options] <commit>...<commit> [--] [<path>...] This form is to view the changes on the branch containing and up to the second <commit>, starting at a common ancestor of both <commit>. "git diff A...B" is equivalent to "git diff $(git-merge-base AB) B". You can omit any one of <commit>, which has the same effect as using HEAD instead. 

Eso funciona para ti?