Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.48.1 → 2.49.0 no changes
-
2.48.0
2025-01-10
- 2.46.1 → 2.47.2 no changes
-
2.46.0
2024-07-29
-
2.45.3
2024-11-26
- 2.45.1 → 2.45.2 no changes
-
2.45.0
2024-04-29
- 2.44.1 → 2.44.3 no changes
-
2.44.0
2024-02-23
- 2.43.1 → 2.43.6 no changes
-
2.43.0
2023-11-20
- 2.42.2 → 2.42.4 no changes
-
2.42.1
2023-11-02
-
2.42.0
2023-08-21
- 2.41.1 → 2.41.3 no changes
-
2.41.0
2023-06-01
- 2.40.1 → 2.40.4 no changes
-
2.40.0
2023-03-12
- 2.37.3 → 2.39.5 no changes
-
2.37.2
2022-08-11
- 2.36.1 → 2.37.1 no changes
-
2.36.0
2022-04-18
- 2.35.1 → 2.35.8 no changes
-
2.35.0
2022-01-24
- 2.34.1 → 2.34.8 no changes
-
2.34.0
2021-11-15
- 2.33.1 → 2.33.8 no changes
-
2.33.0
2021-08-16
- 2.32.1 → 2.32.7 no changes
-
2.32.0
2021-06-06
- 2.31.1 → 2.31.8 no changes
-
2.31.0
2021-03-15
- 2.30.1 → 2.30.9 no changes
-
2.30.0
2020-12-27
- 2.29.1 → 2.29.3 no changes
-
2.29.0
2020-10-19
- 2.28.1 no changes
-
2.28.0
2020-07-27
- 2.25.2 → 2.27.1 no changes
-
2.25.1
2020-02-17
-
2.25.0
2020-01-13
- 2.24.1 → 2.24.4 no changes
-
2.24.0
2019-11-04
- 2.22.1 → 2.23.4 no changes
-
2.22.0
2019-06-07
- 2.21.1 → 2.21.4 no changes
-
2.21.0
2019-02-24
- 2.20.1 → 2.20.5 no changes
-
2.20.0
2018-12-09
- 2.19.1 → 2.19.6 no changes
-
2.19.0
2018-09-10
- 2.18.1 → 2.18.5 no changes
-
2.18.0
2018-06-21
- 2.17.1 → 2.17.6 no changes
-
2.17.0
2018-04-02
-
2.16.6
2019-12-06
-
2.15.4
2019-12-06
-
2.14.6
2019-12-06
-
2.13.7
2018-05-22
-
2.12.5
2017-09-22
-
2.11.4
2017-09-22
- 2.10.5 no changes
-
2.9.5
2017-07-30
-
2.8.6
2017-07-30
- 2.7.6 no changes
-
2.6.7
2017-05-05
-
2.5.6
2017-05-05
-
2.4.12
2017-05-05
-
2.3.10
2015-09-28
- 2.1.4 → 2.2.3 no changes
-
2.0.5
2014-12-17
RESUMO
git diff-index [-m] [--cached] [--merge-base] [<opções-comuns-ao-diff>] <árvore> [<caminho>…]
DESCRIÇÃO
Compare o conteúdo e o modo das bolhas encontradss num objeto árvore com os arquivos rastreados correspondentes na árvore de trabalho ou com os caminhos correspondentes no índice. Quando os argumentos <caminho> estiverem presentes, compare apenas os caminhos que correspondem a estes padrões. Caso contrário, todos os arquivos serão comparados.
OPÇÕES
Warning
|
Missing See original version for this content. |
- <tree-ish>
-
A identificação de um objeto de árvore com a qual fazer o "diff".
- --cached
-
Não considere de forma alguma o arquivo no disco.
- --merge-base
-
Em vez de fazer a comparação direta de
<tree-ish>
, use a base mesclada entre<tree-ish>
eHEAD
. O<tree-ish>
deve ser um commit. - -m
-
É predefinido que os arquivos registrados no índice, mas sem verificação, serão relatados como excluídos. Esta opção faz com que o comando git diff-index diga que todos os arquivos não verificados estão atualizados.
Warning
|
Missing See original version for this content. |
MODOS DE OPERAÇÃO
Você pode escolher se deseja confiar totalmente no arquivo no índice (usando o a opção --cached
) ou solicitar que a lógica do diff mostre todos os arquivos que não correspondam ao estado de estatísticas como sendo "provisoriamente alterados". Ambas as operações são realmente úteis.
MODO EM CACHE
Caso --cached
seja utilizado, será permitido que você pergunte:
mostre-me as diferenças atuais entre o HEAD e o índice teor (os que eu escreveria utilizando 'git write-tree')
Digamos que você trabalhou no seu diretório de trabalho por exemplo e atualizou alguns arquivos no índice e está pronto para fazer o commit. Caso queira ver exatamente o quê será feito no commit, sem precisar escrever um novo objeto árvore e compará-lo dessa maneira, faça
git diff-index --cached HEAD
Exemplo: digamos que eu tenha renomeado o arquivo commit.c
para git-commit.c
e tenha feito um update-index
para tornar isso efetivo no índice do arquivo. O comando git diff-files
não mostraria nada, pois o índice do arquivo corresponde ao meu diretório de trabalho. Porém, ao o comando git diff-index ele faz:
torvalds@ppc970:~/git> git diff-index --cached HEAD :100644 000000 4161aecc6700a2eb579e842af0b7f22b98443f74 0000000000000000000000000000000000000000 D commit.c :000000 100644 0000000000000000000000000000000000000000 4161aecc6700a2eb579e842af0b7f22b98443f74 A git-commit.c
É possível ver facilmente que o item acima foi renomeado.
De fato, o comando git diff-index --cached
deve sempre ser totalmente equivalente a fazer um git write-tree
e comparar. Exceto que este é muito melhor para o caso onde você queira apenas averiguar onde você está.
Portanto, fazer um git diff-index --cached
é basicamente muito mais útil quando você está se perguntando "o quê eu já marquei para ser feito o commit e qual a diferença com uma árvore anterior".
MODO SEM CACHE
O modo "non-cached" adota uma abordagem diferente sendo potencialmente o mais útil dos dois, pois o que ele faz não pode ser emulado com um git write-tree + git diff-tree. Assim sendo, este é o modo predefinido. A versão sem cache faz questiona:
mostre-me as diferenças entre o `HEAD` e o que foi verificado tree - índice do conteúdo _e_ os arquivos que não estão atualizados
o que obviamente também é uma pergunta muito útil, pois isso indica qual commit você poderia fazer. Novamente, a saída coincidente à saída git diff-tree -r para um "tee", mas com uma desvantagem.
A desvantagem é que, caso algum arquivo não coincida com o índice, nós não temos uma uma estrutura de armazenamento para tanto e utilizamos a mágica do sha1 "zerado" para exibi-los. Então, digamos que você editou o arquivo kernel/sched.c
, mas ainda não fez um git update-index
nele - ainda não há um "objeto" associado a nova condição obtendo:
torvalds@ppc970:~/v2.6/linux> git diff-index --abbrev HEAD :100644 100644 7476bb5ba 000000000 M kernel/sched.c
isto é, exiba que a árvore mudou, que o kernel/sched.c
não está atualizado e pode haver novas coisas. O sha1 zerado significa que, para obter um "diff" real, é necessário olhar diretamente para o objeto no diretório de trabalho, em vez de um "diff" de objeto para objeto.
Note
|
Como em outros comandos desse tipo, o git diff-index não analisa de forma alguma o conteúdo do arquivo. Então talvez o kernel/sched.c não tenha realmente mudado, e é só que você mexeu. Em ambos os casos, é importante observar que você precisa fazer um git update-index para sincronizar o índice.
|
Note
|
Você pode exibir junto uma mistura de arquivos como "foi atualizado" e "ainda está sujo no diretório de trabalho". Você sempre pode dizer qual arquivo está em qual condição, uma vez que os que "foram atualizados" exibam um sha1 válido e os "que não estão sincronizados com o índice" sempre terão o sha1 especial, zerados. |
GIT
Parte do conjunto git[1]