¿Por qué aparecen los blobs en un repository antes de confirmar?

Así que me encontré con el siguiente pasaje en la sección 3.1 de Pro Git:

"Asummos que usted tiene un directory que contiene tres files, y los pone en escena y confirma. El almacenamiento en etapas de los files computa una sum de comprobación para cada uno (el hash SHA-1 que mencionamos en Getting Started), almacena esa versión del file en El repository de Git (Git se refiere a ellos como blobs) y agrega esa sum de comprobación al área de ensayo "

Mi pregunta es esta: ¿por qué git "almacena una versión del file en el repository de Git" antes de que yo haya cometido esos files?

Por qué las preguntas siempre son complicadas

Hay una respuesta muy mecánica (que veo mencionada en un comentario ): la estructura interna del índice de Git, ese misterioso object que Git usa para build la siguiente confirmación, almacena solo identificadores de hash blob. Por lo tanto, para tener una copy del file en el índice (para que esté en la próxima confirmación), debe estar en el repository como un object blob.

Hay una respuesta de performance: almacenando identificadores hash en el índice, Git realiza nuevos commits muy rápidamente.

Hay una respuesta de recuperación de datos (que es un poco débil): almacenando el blob en el repository por adelantado, puedes recuperarlo por un time, a través de git fsck --lost-found , si accidentalmente le haces algo malo. . (Las debilidades aquí son, o incluyen, que si el blob coincide con un blob existente en el repository, no aparece en la búsqueda de objects perdidos y se pierde el nombre del file, que a menudo es importante para comprender su contenido).

Hay una respuesta estética de layout: tal vez Linus pensó que git add file al file en el repository desde el principio era más bonito que hacerlo después.

¡Puedes elegir cualquiera de estas respuestas o devisete la tuya!