¿Por qué se requiere la marca "–cached" cuando se ingresan los resultados de "git diff" después de agregar el file (git add) a GIT?

[gdaniel@vnc23 sx_fit_regression]$ git status On branch master Your branch is ahead of 'origin/master' by 4 commits. 

Cambios a cometer: (use "git reset HEAD …" para abandonar la escena)

  new file: eth/fdb/configuration/eth_fdb_cli/eth_fdb_cli.cases new file: eth/fdb/configuration/eth_fdb_cli/specific_test.py new file: eth/fdb/configuration/eth_fdb_cli/test_suit_runner.py new file: eth/fdb/configuration/eth_fdb_cli/test_wrapper.py modified: eth/utilities/eth_constants.py modified: eth/utilities/eth_fdb_tools.py modified: libs/tools/string_manipulation_tools.py Untracked files:# (use "git add <file>..." to include in what will be committed) .project .pydevproject eth/utilities/Test.py 

[gdaniel @ vnc23 sx_fit_regression] $

 [gdaniel@vnc23 sx_fit_regression]$ git diff --color eth/utilities/eth_constants.py [gdaniel@vnc23 sx_fit_regression]$< Blank Output> [gdaniel@vnc23 sx_fit_regression]$ git diff --color --cached eth/utilities/eth_constants.py diff --git a/eth/utilities/eth_constants.py b/eth/utilities/eth_constants.py index 9c0df62..c94f04e 100755 --- a/eth/utilities/eth_constants.py +++ b/eth/utilities/eth_constants.py Output omitted... 

Por favor aclara

Gracias,

QWERTY

Porque Git normalmente compara el tree de trabajo con el índice. Una vez que agrega un file al índice (área de ensayo), no hay diferencia. git diff --cached sin embargo, compara el índice (área de preparación) con la última confirmación ( HEAD ).

A veces, la syntax de git es un poco confusa, ¿verdad?

git diff genera el diff en su copy de trabajo. Cuando agrega --staged , o --cached , le dice a git que diferencie los files ya agregados en su lugar. Puede tratarlos como dos commands diferentes, si tiene sentido para usted.

Además, si desea ver también los files nuevos, primero debe agregarlos.

--cached es un poco engañoso aquí. Es un sinónimo de – --staged .

Entonces, git diff te muestra cambios no git diff --cached , git diff --cached te muestra los cambios en etapas / en caching.

El ajuste

Dos lugares de información están en la image aquí:

  • El tree de trabajo: ahí es donde se guardan sus files, donde los modifica y desde donde realiza los cambios que ha realizado.
  • El área de ensayo (también conocida como "el índice" o "el caching" 1 ).

Los commits normalmente se crean a partir de los contenidos del área de ensayo.

Tenga en count que tanto el tree de trabajo como el área de ensayo están (normalmente) basados ​​en la misma confirmación única, la que señala el punto de reference HEAD .

El command git diff

El command git diff sin arguments especiales (pero puede ser con arguments que especifiquen routes concretas a considerar) compara el área de ensayo con el tree de trabajo.

Esto es lógico porque muestra los cambios que quizás desee realizar y luego confirmar.

Por extensión, una vez que realiza un cambio, y ahora está en el área de preparación, git diff deja de mostrar este cambio porque el tree de trabajo y el área de transición ahora contienen información idéntica.

Si, por el contrario, quieres preguntarle a Git "¿qué se comprometería si lo hago ahora?" tienes que ejecutar git diff --cached o git diff --staged para hacer que Git compare la git diff --staged básica, HEAD , con el contenido del área de preparación.

Tenga en count que si ha organizado solo algunos de los cambios que tiene en el tree de trabajo, ahora tiene tres diferencias posibles a considerar:

  • La diferencia entre el área de ensayo y el tree de trabajo: "cambios no planificados".

    Usa git diff para verlos.

  • La diferencia entre el compromiso de base, HEAD y el área de ensayo: "lo que se comprometerá".

    Usa git diff --cached o git diff --staged para verlos.

  • La diferencia entre la confirmación básica, HEAD y el tree de trabajo: "cambios totales no confirmados".

    Usa git diff HEAD para verlos.


1 Originalmente, la idea básica del área de ensayo era proporcionar un almacenamiento de datos con acceso muy rápido que hiciera reference a todos los metadatos que comprenden los files extraídos en el tree de trabajo, así como sus contenidos modificados (cambios organizados para el siguiente compromiso). Como se trataba de una memory caching de los metadatos (permite que el git status y las operaciones similares sean rápidas como el rayo incluso en treees que contienen grandes cantidades de files), este nombre se usó y atascó. IIRC, luego se lo conoció como "el índice" y luego se le cambió el nombre por el de "área de preparación" para ayudar a los meros mortales a captar el concepto más fácilmente.