Dirección de flechas en el libro ProGit

¿Por qué en todas las imágenes que muestran la queue de confirmaciones en las flechas del libro pro git conduce a la dirección opuesta?

Es para mostrar la relación de los padres. En Git, un compromiso particular sabe sobre sus padres, pero no necesariamente sobre sus hijos. (Obviamente, esa información se puede derivar de los enlaces principales, pero no creo que esté almacenada directamente en el object de confirmación).

Las flechas reflejan la dirección seguida por un DAG, gráfico acíclico dirigido que representa aquí el historial de confirmaciones en Git (del más reciente al más antiguo).

Esa representación no es "perfecta", como detalla Eric Sink en su artículo :

Una de las mejores cosas acerca de las herramientas de control de versiones basadas en DAG es que el DAG es una expresión de la historia de fusión. Interpretamos flechas en el DAG para decir "'Tengo esto".

texto alternativo

Entonces, cuando llega el momento de fusionar de 5b a la twig (a), podemos usar información en el DAG para saber que 3b y 2b ya están hechos


El mismo artículo detalla el límite de esa representación:

Cosecha de la cereza

Pero un DAG es solo una implementación de la historia de fusión, y definitivamente no es perfecto.

Una flecha en un control de versiones DAG va de niño a padre. Nos dice que el niño contiene todos los cambios en el padre . Y sus abuelos Y sus bisabuelos. Y así.

Pero, ¿y si esto no es verdad?

Considera la siguiente image:

texto alternativo

Quiero crear el set de cambios 4.
Quiero comenzar en el set de cambios 1, y luego quiero aplicar los cambios del set de cambios 3, pero NO las cosas en el set de cambios 2.
Esta operación a veces se llama "cherrypicking". No quiero fusionar todos los cambios de una twig a otra. Solo quiero arrancar un set de cambios (o una parte de un set de cambios) y aplicarlo como un parche a otro lugar.

¿Cómo represento esto en el DAG?

No puedo

  • Podría dibujar una flecha de 4 a 3 (que se muestra arriba en rojo). Esto diría correctamente que 4 contiene los cambios en 3, pero INCORRECTAMENTE afirmaría que 4 contiene los cambios en 2.
  • O bien, no podría dibujar ninguna flecha. Efectivamente, mi historial de fusión simplemente no registraría el hecho de que 4 es realmente 3 convertido a un parche y aplicado a 1.

En cualquier caso, algo malo va a suceder la próxima vez que me fusiono de una twig a otra:

  • Si dibujo esa flecha mentirosa, no tendré la oportunidad de aplicar el set de cambios 2, porque la historia de fusión cree que ya lo hice.
  • Si no dibujo ninguna flecha, la herramienta esperará que trate el set de cambios 3, porque no hay un historial de fusión que registre el hecho de que ya lo hice.

Ninguno de estos problemas es tan desastroso como para hacer las noticias de la noche, pero aún así.

Es por eso que una rebase nunca está lejos después de una operación de selección de cereza para recuperar un DAG más clásico.