¿Qué es lo opuesto a `git diff HEAD ^`?

Question

En git, puedo especificar la revisión anterior diciendo HEAD^ o HEAD~1. ¿Qué hay de ir por el otro camino? Supongamos que estoy en la revisión X, y hago git checkout X^. ¿Cómo vuelvo?

¿Algo como git checkout X+?

Answer 1

Realmente no se puede hacer precisamente eso. La historia en git es un gráfico acíclico dirigido: cada confirmación contiene referencias a sus padres, pero los padres no tienen referencias sobre sus hijos.

El problema aquí debería volverse obvio cuando piensas en un commit del que has creado varias ramas. ¿Qué "siguiente compromiso" quieres decir? Con los padres, puede desvincularse (un compromiso de fusión normal tiene un primer y segundo padre), pero ¿cómo lo hace con los niños? Incluso si usted sabe qué rama que está tratando de ser activado (por ejemplo, que se haya registrado a cabo master~4 y ahora quiere mirar master~3) no es bien definido - usted podría estar en una situación como esta:

- X (HEAD) - o - o - o - Y (master) 
    \     /
    o - o - o ---------- 

dicho esto, en casos sencillos, se podría hacer algo como esto:

git checkout $(git rev-list HEAD..master | tail -n 1) 

Es evidente que va a trabajar muy bien con la historia lineal. Con fusiones ... rev-list funciona de presente a pasado en la historia, siguiéndolo hacia atrás. Creo que sigue primero al primer padre, por lo que la última cosa impresa será la confirmación después del HEAD que se encontró al seguir a todos los últimos padres.

Editar: Eso supone que usted sabe a qué rama desea avanzar. Si no lo hace ... bueno, estás bastante atrapado mirando en todos los árbitros para las confirmaciones que tienen HEAD y como padre - probablemente grepping la salida de git rev-parse:

git rev-list --all --children | grep ^$(git rev-parse HEAD) 

Luego agarra la otra SHA1 de la línea (use awk, lo que sea) Tendrás que inspeccionar manualmente o hacer una elección arbitraria si hay resultados múltiples ...

Answer 2

No creo que esto sea posible, ya que un commit de Git solo almacena su parent commit, pero no sus hijos.

Imagine a commit almacenar sus hijos. ¿Qué pasaría si crearas varias ramas fuera de este compromiso, por lo que las múltiples confirmaciones tienen este compromiso como primario? ¿Qué sería entonces "HEAD +"? Esto es ambiguo e incorrecto.

Hablando en lo que sé de estructuras de datos: Git almacena el historial como una lista de enlaces únicos, mientras que su operación necesitaría una lista doblemente vinculada.

Answer 3

Por lo que yo sé, no hay una forma simbólica de referirse a los hijos de una confirmación.

Lo mejor que puedo darte ahora es la opción --children de git rev-list. Aquí pido que los cuatro commits más recientes sean bastante impresos, más información sobre sus hijos. Tenga en cuenta que en la línea "confirmar" de cada entrada (que no sea la más reciente) hay un número de confirmación extra, que especifica el hijo de ese nodo. Podrías agarrar eso manualmente o a través de algunas secuencias de comandos de shell para llegar al niño.

$ git rev-list --children --pretty HEAD~3... 

commit 20dba296ad1d48ec90f9319e2c13b245e849f698 
Author: Somebody <____@____.net> 
Date: Thu May 6 19:10:38 2010 -0400 

    Support for complex trig/pow. 

commit 9d42b5bac1721a847a39c25672e577c7101c8ff0 20dba296ad1d48ec90f9319e2c13b245e849f698 
Author: Somebody <____@____.net> 
Date: Wed May 5 21:55:07 2010 -0400 

    Fix doc formatting warning. 

commit 72bed3baa9df71cb224dfa8388b5969d50f5567c 9d42b5bac1721a847a39c25672e577c7101c8ff0 
Merge: b8244cb61491c9cdb83d36e57f8eb49773e44f6b 899c3dd3f9f419f200b84ca0abe59d7ac3d5bb53 
Author: Somebody <____@____.net> 
Date: Wed May 5 21:54:59 2010 -0400 

    Merge branch 'master' 

commit 899c3dd3f9f419f200b84ca0abe59d7ac3d5bb53 72bed3baa9df71cb224dfa8388b5969d50f5567c 
Author: Somebody <____@____.net> 
Date: Wed May 5 21:19:11 2010 -0400 

    Fix link