▷Cómo entender git log --graph ✔️ Foro Ayuda 【 2024 】

Este grupo de especialistas luego de muchos días de trabajo y recopilación de de información, hallamos la solución, queremos que te sea de utilidad para tu plan.

Solución:

Git trabaja desde el compromiso actual mirando a los antepasados. Las ramas no son “entidades”, son referencias (móviles). No hay forma de que git log (o gitk que tiene un esquema de color diferente pero es análogo a git log –graph o tig) sepa si la rama actual es descendiente de la rama A o la rama B. Solo conoce a los padres. Desde man git-log:

   git log -p -m --first-parent
       Shows the history including change diffs, but only from the "main 
       branch"   perspective, skipping commits that come from merged
       branches, and showing full diffs of changes introduced by the merges. 
       This makes sense only when following a strict policy of merging
       all topic branches when staying on a single integration branch.

De alguna manera abordaría su preocupación. git log por defecto usa la confirmación actual extraída como referencia (idéntica a ejecutar git log HEAD

Si bien personalmente creo que la página de manual es bastante clara para git, es posible que desee echar un vistazo a gitk o tig. La primera es una interfaz gráfica, la última es una herramienta gitk mínima similar a un terminal. Utilizo ambos dependiendo de lo que quiero hacer.

Con Git 2.25 (Q1 2020), la implementación de “git log --graph“se refactorizó y luego su salida se simplificó.

Eso a su vez puede arreglar el color en algunos casos.
A continuación se proporciona una ilustración sobre cómo se gestionan los colores y los bordes con git log --graph.

Consulte la confirmación d784d97 (12 de noviembre de 2019) de Denton Liu (Denton-L).
Ver confirmar bbb13e8, confirmar 92beecc, confirmar 479db18, confirmar 0195285, confirmar d62893e, confirmar 0f0f389, confirmar 458152c, confirmar ee7abb5, confirmar 46ba2ab, confirmar a551fd5, confirmar 9157a2a, confirmar 210179a, confirmar fbccf25 (15 de octubre de 2019)jcoglan).
^{(Fusionada por Junio C Hamano – gitster – en commit 0be5caf, 01 dic 2019)}

graph: arregla la coloración de las rayas de pulpo

^{Firmado por: James Coglan}

En 04005834ed (“log: corregir el color de ciertas formas de fusión de pulpo “, 2018-09-01, Git v2.20.0-rc0 – fusión enumerada en el lote n. ° 6), hay una solución para la coloración de los guiones después de una fusión de pulpo.
Hace una distinción entre el caso en el que todos los padres introducen una nueva columna y el caso en el que el primer padre se colapsa en una columna existente:
| *-.           | *-.
| |           | | 
| | | |         |/ / /
El último caso significa que las columnas para los padres de combinación comienzan un lugar a la izquierda en el new_columns array en comparación con el caso anterior.

Sin embargo, la implementación solo funciona si los padres de la confirmación se mantienen en orden a medida que se asignan a las columnas visuales, ya que obtenemos los colores iterando sobre new_columns mientras imprimimos los guiones.
En general, los padres de la confirmación pueden fusionarse arbitrariamente con columnas existentes y cambiar su orden en el proceso.

Por ejemplo, en el siguiente diagrama, el número de cada columna indica qué padre de confirmación aparece en cada columna.
| | *---.
| | |  
| | |/ / /
| |/| | /
| |_|_|/
|/| | |
3 1 0 2
Si las columnas son de color (rojo, verde, amarillo, azul), los guiones serán actualmente de color amarillo y azul, mientras que deberían ser de color azul y rojo.

Para solucionar este problema, debemos buscar cada columna en el mapping array, que antes del GRAPH_COLLAPSING estado indica qué columna lógica se muestra en cada columna visual.
Esta implementación es más simple ya que no tiene casos extremos, y también maneja cómo se muestran ahora los primeros padres sesgados a la izquierda:
| *-.
|/| 
| | | |
0 1 2 3
El color de los primeros guiones es siempre el color que se encuentra en mapping dos columnas a la derecha del símbolo de confirmación. Debido a que las confirmaciones se muestran después de que todos los bordes se han contraído y las columnas visuales coinciden con las lógicas, podemos encontrar el desplazamiento visual del símbolo de confirmación usando commit_index.

Con respecto a los bordes (todavía con Git 2.25, Q1 2020):

graph: apariencia suave de los bordes colapsados en las líneas de compromiso

^{Firmado por: James Coglan}

Cuando un gráfico contiene bordes que están en proceso de colapsar hacia la izquierda, pero esos bordes cruzan una línea de compromiso, el efecto es que los bordes tienen una apariencia irregular:
*
|
| *
|  
*-. 
|  
| | * |
| * | |
| |/ /
* | |
|/ /
* |
|/
*
Ya tomamos medidas para suavizar los bordes como este cuando se expanden; cuando aparece un borde a la derecha de un marcador de compromiso de fusión en un GRAPH_COMMIT línea inmediatamente después de un GRAPH_POST_MERGE línea, la representamos como una :
* 
| 
| * 
| | 
Podemos hacer una mejora similar al colapso de los bordes, haciéndolos más fáciles de seguir y dando al gráfico general una sensación de mayor simetría:
*
|
| *
|  
*-. 
|  
| | * |
| * | |
| |/ /
* / /
|/ /
* /
|/
*
Para hacer esto, presentamos un nuevo caso especial para bordes en GRAPH_COMMIT líneas que siguen inmediatamente a GRAPH_COLLAPSING línea.
Al retener una copia del mapping array utilizado para renderizar el GRAPH_COLLAPSING línea en el old_mapping array, podemos determinar que un borde se está colapsando a través del GRAPH_COMMIT línea y debe suavizarse.

Más generalmente:

graph: confirma y post-fusión líneas para fusiones sesgadas a la izquierda

^{Firmado por: James Coglan}

Siguiendo el introducción de fusiones “sesgadas a la izquierda”, que son fusiones cuyo primer padre se fusiona con otro borde a su izquierda, tenemos algunos casos de borde más tratar en la visualización de las líneas de confirmación y posterior a la fusión.

El código de gráfico actual maneja los siguientes casos de bordes que aparecen a la derecha de la confirmación (*) en las líneas de compromiso.

Una combinación bidireccional suele ir seguida de líneas verticales:
| | |
| * |
| | 
Una combinación de pulpo (más de dos padres) siempre va seguida de bordes inclinados hacia la derecha:
| |            | |    
| *-.          | *---. 
| |          | |   
Una combinación bidireccional va seguida de un borde inclinado hacia la derecha si la línea de confirmación sigue inmediatamente a una línea posterior a la combinación para una confirmación que aparece en la misma columna que la confirmación actual, o cualquier columna a la izquierda de esa:
| *             | * |
| |            | | 
| *            | | * 
| |           | | | 
Esta confirmación presenta los siguientes casos nuevos para las líneas de confirmación. Si una combinación bidireccional se inclina hacia la izquierda, los bordes de la derecha son siempre líneas verticales, incluso si la confirmación sigue una línea posterior a la combinación:
| | |           | |
| * |           | * |
|/| |           |/| |
Una confirmación con 3 padres que se inclina hacia la izquierda va seguida de bordes verticales:
| | |
| * |
|/| 
Si aparece una confirmación de fusión de 3 vías sesgada a la izquierda inmediatamente después de una línea posterior a la fusión, entonces se pueden seguir los bordes inclinados a la derecha, al igual que una fusión de 2 direcciones que no está sesgada.
| |
| * 
|/| 
Las combinaciones de pulpo con 4 o más padres que se inclinan hacia la izquierda siempre irán seguidas de bordes inclinados a la derecha, porque las columnas existentes deben expandirse alrededor de la combinación.
| |  
| *-. 
|/|  
En las líneas posteriores a la fusión, generalmente todos los bordes siguen la pendiente de compromiso actual hacia la derecha:
| * | |
| |  
Sin embargo, si la confirmación es una combinación bidireccional sesgada a la izquierda, los bordes a su derecha permanecen verticales.
También necesitamos mostrar un espacio después de la línea vertical que desciende del marcador de confirmación, mientras que esta línea normalmente iría seguida de una barra invertida.
| * | |
|/| | |
Si una combinación sesgada a la izquierda tiene más de 2 padres, los bordes de la derecha todavía están inclinados a medida que se doblan alrededor de los bordes introducidos por la combinación.
| * | |
|/|  
Para manejar estos nuevos casos, necesitamos saber no solo cuántos padres tiene cada confirmación, sino cuántas columnas nuevas agrega a la pantalla; esta cantidad se registra en el edges_added campo para la confirmación actual, y prev_edges_added campo para la confirmación anterior.

Aquí, “columna” se refiere a columnas visuales, no a las columnas lógicas del columns array.
Esto se debe a que incluso si todos los padres de la confirmación terminan fusionándose con los bordes existentes, inicialmente introducen bordes distintos en las líneas de confirmación y posterior a la fusión antes de que esos bordes colapsen.

Por ejemplo, una combinación de 3 vías cuyos padres segundo y tercero se fusionan con los bordes existentes todavía introduce 2 columnas visuales que afectan la visualización de los bordes a su derecha.
| | |  
| | *-. 
| | |  
| |_|/ / /
|/| | / /
| | |/ /
| |/| |
| | | |
Esta fusión no introduce ningún lógico columnas; hay 4 bordes antes y después de esta confirmación una vez que todos los bordes se han colapsado. Pero inicialmente introduce 2 nuevos bordes que deben ser acomodados por los bordes a su derecha.

La salida clásica se ha simplificado:

graph: ejemplo de salida de gráfico que se puede simplificar

^{Firmado por: James Coglan}

Las confirmaciones que siguen a este introducen una serie de mejoras en el diseño de los gráficos, arreglando algunos casos extremos, a saber:

fusionar cuyo primer padre se fusiona con una columna existente a la izquierda

fusionar cuyo último padre se fusiona con su vecino inmediato a la derecha

bordes que colapsan hacia la izquierda por encima y por debajo de una línea de compromiso

Este caso de prueba ejemplifica estos casos y proporciona un ejemplo motivador del tipo de historia que pretendo aclarar.

El primer padre de la fusión E es el mismo que el padre de H, por lo que esos bordes se fusionan.
* H
|
| *-.   E
| | 
|/ / /
|
* B
Podemos “sesgar” la visualización de esta combinación para que no introduzca columnas adicionales que colapsen inmediatamente:
* H
|
| *   E
|/|
|
* B
El último padre de E es D, lo mismo que el padre de F, que es el borde a la derecha de la combinación.
* F
|
 
.    E
  
 / /
| /
|/
* D
Los dos bordes que conducen a D podrían fusionarse antes: en lugar de expandir el borde F alrededor de la fusión y luego dejar que los bordes colapsen, el borde F podría fusionarse con el borde E en la línea posterior a la fusión:
* F
|
 
. | E
 |
 /
|
* D
Si esto se combina con el efecto “sesgado” anterior, obtenemos una visualización del gráfico mucho más limpia para estos bordes:
* F
|
| E
|
|
* D
Finalmente, el borde que va de C a A aparece irregular al pasar por la línea de compromiso para B:
| * | C
| |/
* | B
|/
* A
Esto se puede suavizar para que dichos bordes sean más fáciles de leer:
| * | C
| |/
* / B
|/
* A

Desde las actualizaciones recientes del código de representación del gráfico de registro, la elaboración de ciertas fusiones comenzó a activar una afirmación en una condición que ya no se mantendría true, que se ha corregido con Git 2.25 (Q1 2020).

Ver commit a1087c9, commit 0d251c3 (07 de enero de 2020) por Derrick Stolee (derrickstolee).
^{(Fusionada por Junio C Hamano – gitster – en el compromiso 1f5f3ff, 08 de enero de 2020)}

graph: suelte assert () para fusionar con dos padres que colapsan

^{Ayudado por: Jeff King}
^{Reportado por: Bradley Smith}
^{Firmado por: Derrick Stolee}

Cuando “git log --graph“muestra una confirmación de fusión que tiene dos líneas que se contraen, como:
| | | | *
| |_|_|/|
|/| | |/
| | |/|
| |/| |
| * | |
* | | |
activamos un assert ():
graph.c:1228: graph_output_collapsing_line: Assertion
              `graph->mapping[i - 3] == target' failed.
La aserción fue introducida por eaf158f8 (“API de gráficos: use líneas horizontales para gráficos más compactos”, 2009-04-21, Git v1.6.4-rc0 – merge), que es bastante antiguo.
Esta afirmación intenta decir que cuando completamos una línea horizontal con una sola barra, es porque hemos alcanzado nuestro objetivo.

En realidad es el _second_ línea colapsada que golpea esta afirmación.
La razón por la que estamos en esta ruta de código es porque estamos colapsando la primera línea y, en ese caso, estamos alcanzando nuestro objetivo ahora que la línea horizontal está completa.
Sin embargo, la segunda línea no puede ser una línea horizontal, por lo que colapsará sin líneas horizontales. En este caso, no es apropiado afirmar que hemos alcanzado nuestro objetivo, ya que debemos continuar por otra columna antes de alcanzar el objetivo.
Dejar caer la afirmación es seguro aquí.

los nuevo comportamiento en 0f0f389f12 (“graph: ordenar la visualización de fusiones sesgadas a la izquierda “, 2019-10-15, Git v2.25.0-rc0 – la fusión enumerada en el lote n. ° 2) provocó el cambio de comportamiento que hizo posible esta falla de aserción.
Además de hacer posible la afirmación, también cambió la forma en que se colapsan varios bordes.

En un ejemplo más grande, el código actual generará un colapso de la siguiente manera:
| | | | | | *
| |_|_|_|_|/|
|/| | | | |/ /
| | | | |/| /
| | | |/| |/
| | |/| |/|
| |/| |/| |
| | |/| | |
| | * | | |
Sin embargo, el colapso previsto debería permitir múltiples líneas horizontales de la siguiente manera:
| | | | | | *
| |_|_|_|_|/|
|/| | | | |/ /
| | |_|_|/| /
| |/| | | |/
| | | |_|/|
| | |/| | |
| | * | | |
Este comportamiento no se corrige con este cambio, pero se indica para una actualización posterior.

Representación por “git log --graph“de las líneas de ascendencia que conducen a un compromiso de fusión se hicieron subóptimas para desperdiciar un poco el espacio vertical con una actualización reciente, que se corrigió con Git 2.26 (Q1 2020).

Ver commit c958d3b, commit 8588932 (08 de enero de 2020) por Derrick Stolee (derrickstolee).
^{(Fusionada por Junio C Hamano – gitster – en commit d52adee, 30 de enero de 2020)}

graph: corregir el colapso de varios bordes

^{Firmado por: Derrick Stolee}

Esta corrección resuelve el agregado previamente test_expect_failure en t4215-log-skewed-merges.sh.

El problema radica en el “else“condición al actualizar el mapeo en el interior graph_output_collapsing_line().
En 0f0f389f (“graph: ordenar la visualización de fusiones sesgadas a la izquierda “, 2019-10-15, Git v2.25.0-rc0 – fusión enumerada en el lote n. ° 2), la salida de las fusiones sesgadas a la izquierda se modificó para permitir un borde horizontal inmediato en el primer padre, salida por graph_output_post_merge_line() en lugar de por graph_output_collapsing_line().
Esto condensó el comportamiento de la primera línea de la siguiente manera:

Antes de 0f0f389f:
| | | | | | *-.
| | | | | | | 
| |_|_|_|_|/ | |
|/| | | | | / /
Después de 0f0f389f:
| | | | | | *
| |_|_|_|_|/|
|/| | | | |/ /
| | | | |/| /
Sin embargo, surgió un problema muy sutil cuando el segundo y tercer borde principal se contrajeron en pasos posteriores. El segundo borde principal ahora está inmediatamente adyacente a un borde vertical. Esto significa que la condición
} else if (graph->mapping[i - 1] < 0) {
en graph_output_collapsing_line() evalúa como false. El bloque para esta condición fue el único lugar donde conectamos la columna de destino con la posición actual con marcadores de borde horizontal.

En este caso, la final "else"se ejecuta el bloque y el borde se marca como horizontal, pero no rellena las columnas en blanco entre el objetivo y el borde actual.
Dado que el segundo borde principal está marcado como horizontal, el tercer borde principal no está marcado como horizontal.
Esto hace que la salida continúe de la siguiente manera:

Antes de este cambio:
| | | | | | *
| |_|_|_|_|/|
|/| | | | |/ /
| | | | |/| /
| | | |/| |/
| | |/| |/|
| |/| |/| |
| | |/| | |
Al agregar la lógica para "llenar" un borde horizontal entre la columna de destino y la columna actual, podemos resolver el problema.

Después de este cambio:
| | | | | | *
| |_|_|_|_|/|
|/| | | | |/ /
| | |_|_|/| /
| |/| | | |/
| | | |_|/|
| | |/| | |
Esta salida coincide correctamente con la combinación esperada del comportamiento del borde antes de 0f0f389f y la representación de confirmación de combinación de 0f0f389f.

Calificaciones y comentarios

Tienes la opción de secundar nuestro análisis ejecutando un comentario y valorándolo te damos las gracias.

¡Haz clic para puntuar esta entrada!

(Votos: 0 Promedio: 0)

Tags : Git / Git Log /

Cómo entender git log –graph

Solución:

`graph`: arregla la coloración de las rayas de pulpo

`graph`: apariencia suave de los bordes colapsados en las líneas de compromiso

`graph`: confirma y post-fusión líneas para fusiones sesgadas a la izquierda

`graph`: ejemplo de salida de gráfico que se puede simplificar

`graph`: suelte assert () para fusionar con dos padres que colapsan

`graph`: corregir el colapso de varios bordes

Calificaciones y comentarios

Utiliza Nuestro Buscador

Preguntas Relacionadas:

Solución:

graph: arregla la coloración de las rayas de pulpo

graph: apariencia suave de los bordes colapsados ​​en las líneas de compromiso

graph: confirma y post-fusión líneas para fusiones sesgadas a la izquierda

graph: ejemplo de salida de gráfico que se puede simplificar

graph: suelte assert () para fusionar con dos padres que colapsan

graph: corregir el colapso de varios bordes

Calificaciones y comentarios

Utiliza Nuestro Buscador

Preguntas Relacionadas:

`graph`: arregla la coloración de las rayas de pulpo

`graph`: apariencia suave de los bordes colapsados en las líneas de compromiso

`graph`: confirma y post-fusión líneas para fusiones sesgadas a la izquierda

`graph`: ejemplo de salida de gráfico que se puede simplificar

`graph`: suelte assert () para fusionar con dos padres que colapsan

`graph`: corregir el colapso de varios bordes