Cuando Linus comenzó a escribir git, su objetivo era que le permitirá reproduce cada estado intermedio producido por su flujo de trabajo original "tarball y parches" que usó antes de los días de BitKeeper.
A partir de un tarball 2.6.12, pone en cola el parche-1, el parche-2, ... así que el 2.6.12 mismo, el 2.6.12 con el parche-1 aplicado, el 2.6.12 con el parche-1 y el parche-2 aplicado, conviértase en tres versiones.
Pero esto obviamente no se escalará si tiene que mezclar cientos de parches por día. Entonces él inventó "caché de directorio"; como concepto, esto corresponde aproximadamente a los objetos "de árbol" en el git de hoy: una colección de registros, cada uno de los cuales es una representación compacta de lo que contiene una estructura de directorio completa.
La forma de compilarlo era "agregar el contenido a la memoria caché o actualizar los contenidos en la memoria caché".
El directorio de control para alojar la recopilación de dichos registros de control de versiones se llamó ".dircache" (esto se renombró a ".git" después de algún tiempo).
Hubo un archivo llamado ".dircache/index", y el contenido de este archivo fue leído y manipulado en un conjunto de variables en C que fueron nombradas después de un sustantivo, "cache".
En aquel entonces, el concepto de lo que hoy llamamos el índice, un área de memoria intermedia para crear la colección de contenidos que pretende escribir como un objeto de árbol, se llamó "caché".
Todo el mundo hablaba de "caché" e "índice" indistintamente, ya que el archivo que registra lo que está en "cache" se llamaba "index". Era (y sigue siendo) un índice que le permite encontrar los contenidos en la memoria caché al darle una ruta de acceso.
Como cada vez más personas comenzaron a usar git sin tener que leer su código en absoluto, el uso de la palabra "índice" se ha vuelto más frecuente por razones obvias.
Como algo que está en el sistema de archivos, es mucho más visible que el nombre de la variable en el código fuente C.
Eventualmente, dejamos de usar "caché" como nombre para nombrar lo que llamamos "el índice" hoy cuando explicamos el uso de git como usuario final.
Sin embargo, la palabra "caché" todavía se utiliza como sustantivo cuando queremos hablar sobre la estructura de datos interna en el contexto de la discusión de la implementación de git (por ejemplo, "Permitamos que los programas funcionen con más de un caché en al mismo tiempo").
En el nivel de usuario final, "caché" solo se usa como adjetivo en estos días; "caché", que significa "contenido almacenado en caché en el índice, no el contenido en el árbol de trabajo".
Podríamos haberlo llamado "indexado", pero "contenido en caché" era una frase ya establecida desde los primeros días para significar ese concepto exacto, y no necesitábamos otra palabra que significara lo mismo.
[...] En los primeros días, existía una distinción entre "agregar un nuevo archivo al índice" y "actualizar un archivo que ya está en el índice con nuevos contenidos".
[...] Las versiones modernas (y medievales) de git usan "git add" para ambos. Podríamos haber sido honestos y llamar a la acción de actualizar o agregar al índice "add", pero algunas personas en la industria de "git training" comenzaron a enseñar el índice como "el área de preparación para el siguiente compromiso", y como consecuencia inevitable, un verbo "to stage" comenzó a aparecer en muchos documentos para significar "el acto de agregar contenidos al índice".
A veces uso este verbo, pero eso es solo cuando sospecho que la audiencia podría haber aprendido primero de estas nuevas personas. Estrictamente hablando, esta es una palabra redundante y bastante reciente en el vocabulario de git.
En realidad, a veces me he preguntado esto también a mí mismo: D –
en realidad, solo quiero saber si el área de preparación tiene otra funcionalidad especial que no conozco. Desde la primera vez que conocí esta palabra en Git, creo que es una cuestión muy compleja que debo manejar ... –
No. AFAIK es solo el estado del código que se va a cometer. – Abizern