Git Commit Generation Numbers

Question

¿Qué son los números de generación de confirmación de git (hacker news link) y cuál es su significado?

Answer 1

sólo para añadir a siri 's answer, "Encomienda Números Generación" son:

• explained here:

Una confirmación de generación es su altura en el gráfico de la historia, como medido desde la raíz más lejana. Se define como:

• Si el commit no tiene padres, entonces su generación es 0.
• De lo contrario, su generación es 1 más que el máximo de sus padres generaciones.

• un viejo tema que ya se ha mencionado en la creación de Git en 2005:

Linus Torwald (antaño 14 de julio):
Ok, así que no veo que el viejo la discusión sobre los números de generación ha resurgido.
Y tengo que decir que con seis años de uso de git, creo que no es una coincidencia que la noción de números de generación haya surgido varias veces en los últimos años: creo que la falta de ellos es literalmente el único error de diseño real que tener.
[...]
En realidad, apareció en julio de 2005, por lo que el "vamos a usar números de generación en commits" es realmente anterior.

• sobre la cuestión de sabiendo rápidamente si una confirmación es un antepasado de cometer otra (sin tener que caminar de regreso al DAG - el gráfico de confirmaciones -):

Creo que es completamente razonable decir que el problema básicamente se reduce a una pregunta de git: "puede comprometer a X ser un ancestro del compromiso Y" (como una forma de limitar básicamente ciertos algoritmos de tener que caminar completamente hacia abajo). Hemos utilizado las fechas de compromiso, y realmente ha funcionado muy bien. Pero siempre fue una heurística rota.

Así que sí, personalmente veo los contadores de generación como una forma de hacer las comparaciones de fechas de confirmación correctas. Y sería perfectamente correcto decir "si no hay números de generación, usaremos los sellos de fecha y sabremos que podrían ser incorrectos".

Esa opción de "usar la marca de fecha y hora" puede implicar toda la heurística que ya hacemos (es decir, verificar que los sellos parezcan cuerdos y no confiar solo en uno).

Como el hilo de noticias Hacker menciones:

números Generation son la consecuencia del estado del árbol, mientras que las marcas de tiempo se derivan del ambiente entorno desde el que el commit era (y potencialmente incorrecto!) hecho.

Por el momento, cada confirmación almacena una referencia al árbol principal.
Al analizar ese árbol y leer el completo historial puede obtener una jerarquía de confirmaciones.
Debido a que necesita ordenar confirmaciones en muchas situaciones, leer todo el historial es extremadamente ineficiente, por lo que git usa marcas de tiempo para determinar el orden de las confirmaciones.
Esto, por supuesto, falla si el reloj del sistema en una máquina determinada está apagado.
Con un número de generación, puede obtener un pedido localmente a partir de los últimos commits, sin tener que depender de las marcas de tiempo o leer todo el árbol.

Cuando se tiene una confirmación con la generación n, ningún commit posteriores que lo incluyen heridas tienen generación >n, por así decir la relación entre compromete, sólo es necesario mirar tan atrás como n, y se puede obtener de inmediato la orden de cualquier compromiso intermedio.
No tiene nada que ver con "fácil de recordar". Se trata de hacer git más eficiente y robusto

• no redundante:

números de generación son completamente redundante con la estructura real de la historia representada por los Consejos para los Padres.

Linus:

No es cierto. Eso solo es cierto si agrega "... si analiza toda la historia" a esa afirmación.
Y nunca hemos analizado toda la historia, porque es demasiado cara y no escala. Así que ahora dependemos de fechas de compromiso con algunos hacks.
Así que no, los números de generación no son para nada redundantes. Ellos son fundamentales. Es por eso que tuvimos esta discusión hace seis años.

---

Todavía hay un debate acerca de dónde almacenar en caché esa información (o si se debe almacenar en caché), pero por el punto de vista del usuario, todavía se trata de un poco de "fácil de recordar" la información (que no es el objetivo de cometer número de generación):

lo que es casi, pero no del todo, al igual que los números de revisión a todos los demás siempre ha tenido?

Sí - casi, pero no del todo.
Si usted y yo cada uno crea una rama de un cometen con Gen #123, entonces, como yo lo entiendo, las confirmaciones posteriores en mi sucursal serían #124, #125, etc., y sus confirmaciones en su sucursal también serían #124 , #125, etc.

Contraste esto: - con CVS, donde tendría 1.124.1.1, 1.124.1.2, etc., y que tendría 1.124.2.1, 1.124.2.2, o - con Subversion, donde podría obtener las revisiones 125, 128 y 129, mientras que el servidor dio sus confirmaciones #124, 127 y 130, y alguien más, en una parte totalmente diferente del proyecto obtuvo #126.

Mientras el desarrollo avanza linealmente, en una sola rama, entonces sí, se trata de guardar como números de revisión en un RCS centralizado; una vez que comienzas a ramificar y fusionar, representa un concepto completamente distinto.

Para un único repositorio, tiene una interpretación muy similar a, por ejemplo, svn revnos.
Puede hablar de la "revisión n. ° 125 de una rama" en un repositorio específico. Que es, en general, exactamente lo que necesita para la comunicación de persona a persona sobre el desarrollo.
"¿Puedes ver si ese error está en el r125 de inestable?" "Tengo todos los cambios hasta r245 de prod"
Supongo que el aspecto confuso sería si "r245 de prod" en el servidor central era "r100 de prod" en mi repositorio local porque no he clonado el completo ¿historia?

Answer 2

El problema (como se deduce en el hilo en git@vger.kernel.org) es que la dirección DAG que confianza se cuenta en la dirección inversa, de la cabeza rama de nuevo a través de la paternidad. Los números de generación (incluso si se registraron en el momento de la confirmación) se cuentan a través de descendientes. Además, nos equivocamos con la historia percibida a menudo en nuestros diferentes repositorios (distribuidos), de ahí todos los problemas.

---

Basta con leer de latest Linus, aparte de su mala interpretación acerca de los cambios de nombre (Creo que George Spelvin estaba de acuerdo con él - No grabe renombra dentro del repositorio, simplemente tomar instantáneas), que pone de relieve que:

el diseño muy básico de git es todo acerca de incompleto DAG transversal. La parte DAG recorrido es bastante obvio y simple, pero la parcial lo que realmente es muy, muy importante. ".

lo tanto esencialmente un pregrabado cometer 'generación de números' sería dirá qué tan lejos (el máximo) todavía tiene que ir a la parte inferior (raíz), por lo que si puede confiar en él, entonces puede tomar la decisión de detener DAG transversal incompleta. Sin ella tendría que ir todo el camino hasta la raíz, que es ineficiente.

Así que creo que he cambiado de opinión ahora que me doy cuenta de que es un criterio de detención. Eso no quiere decir que una caché (localmente calculada) pueda no acelerar algunas búsquedas.