¿Cuál es la diferencia entre una confirmación y una revisión en Git?

Hay una serie de comandos de git, como git clone --depth 10 <repo>que requieren el número de revisiones [git help revisions] que debe darse.

¿Cuál es la distinción entre una confirmación y una revisión (en git, en lugar de decir svn)?

¿O solo aparece en plural cuando se trata de contar revisiones/confirmaciones, por ejemplo, que las revisiones deben contarse recorriendo el DAG (gráfico acíclico dirigido) de confirmaciones y sus padres, o alguna otra distinción cuidadosa?

Ver “ESPECIFICACIÓN DE REVISIONES” de git rev-parse:

Un parámetro de revisión <rev> típicamente, pero no necesariamente, nombra un objeto de confirmación.
Utiliza lo que se llama una sintaxis SHA1 extendida, [and includes] varias formas de deletrear nombres de objetos.

Entonces, “revisión” se refiere a la identificación que puede usar como parámetro para referencia un objeto en git (generalmente una confirmación).

HEAD@{5 minutes ago} es una revisión que hace referencia al compromiso presente hace 5 minutos.

gitrevision menciona:

[…] algunos comandos de Git (como git show) también toma parámetros de revisión que denotan otros objetos además de las confirmacionesp.ej manchas (“archivos”) o árboles (“directorios de archivos”).

Por ejemplo, el siguiente parámetro rev no hace referencia a una confirmación:

<rev>:<path>, e.g. HEAD:README, :README, master:./README

un sufijo : seguido de una ruta nombra el blob o el árbol en la ruta dada en el objeto tipo árbol nombrado por la parte antes de los dos puntos.

---

Un “commit” en Git generalmente designa un “commit objeto“(como se describe en git commit-tree por ejemplo):

Una confirmación encapsula:

• todos los identificadores de objetos principales
• nombre del autor, correo electrónico y fecha
• nombre y correo electrónico del confirmador y la hora de confirmación.

---

Entonces:

• un compromiso designa uno de los objetos git (otros son blobs, tree, tags, notes),
• una revisión es una forma de hacer referencia a un objeto git.

---

En tu caso (git clone) --depth <n> hace:

Cree un clon superficial con un historial truncado al número especificado de revisiones.

Es para todas las confirmaciones accesibles a esa profundidad, hasta n revisiones por ruta en el DAG.
Dado que el resultado puede ser más que n confirma, el término revisión se adapta más aquí para enfatizar que no solo desea n confirmaciones, pero cualquier confirmación referenciada por un máximo de n revisiones accesibles.

Sin embargo, en este contexto, las revisiones hacen referencia claramente solo a las confirmaciones (como se ilustra a continuación) accesibles (como mencionó en “¿Es git clone --depth 1 (clon superficial) ¿más útil de lo que parece?”).

La pregunta es “accesible desde qué”?

usted hizo referencia este hilo que incluía:

IIRC, --depth=<n> no es “profundizar por <n>“, pero “Asegúrate de tener al menos <n> de los consejos actualizados“.
El truco de la clonación superficial le brinda una semántica bastante inútil (aunque puede ser internamente consistente) si realizó una clonación superficial en el pasado y la obtuvo con --depth después de que el otro lado agregó muchas más confirmaciones que <n>ya que no puede adivinar cuál es el valor correcto de <n> debería ser sin realmente ir a buscar sin --depth.

Interesante. No me había encontrado con esta distinción antes, pero al hojear la documentación y mi propia experiencia, una confirmación en git es un objeto que apunta a un punto específico en el tiempo en la historia del proyecto (junto con información sobre cómo llegó allí) . Una revisión es un superconjunto de esto que habla sobre diferentes formas de hacer referencia a una confirmación o un rango de confirmaciones.