index 8b6a953c03aa7971f8f7e6e7b7573c4b0fa64007..2df581c2c9e598c676fcb95c35c91209d15562ca 100644 (file)
git-diff-index(1)
=================
git-diff-index(1)
=================
-v0.1, May 2005
NAME
----
NAME
----
-git-diff-index - Compares content and mode of blobs between the cache and repository
+git-diff-index - Compares content and mode of blobs between the index and repository
SYNOPSIS
SYNOPSIS
DESCRIPTION
-----------
Compares the content and mode of the blobs found via a tree
DESCRIPTION
-----------
Compares the content and mode of the blobs found via a tree
-object with the content of the current cache and, optionally
+object with the content of the current index and, optionally
ignoring the stat state of the file on disk. When paths are
specified, compares only those named paths. Otherwise all
ignoring the stat state of the file on disk. When paths are
specified, compares only those named paths. Otherwise all
-entries in the cache are compared.
+entries in the index are compared.
OPTIONS
-------
OPTIONS
-------
-----------
If '--cached' is specified, it allows you to ask:
-----------
If '--cached' is specified, it allows you to ask:
- show me the differences between HEAD and the current cache
+ show me the differences between HEAD and the current index
contents (the ones I'd write with a "git-write-tree")
For example, let's say that you have worked on your working directory, updated
contents (the ones I'd write with a "git-write-tree")
For example, let's say that you have worked on your working directory, updated
-some files in the cache and are ready to commit. You want to see eactly
-*what* you are going to commit is without having to write a new tree
+some files in the index and are ready to commit. You want to see exactly
+*what* you are going to commit, without having to write a new tree
object and compare it that way, and to do that, you just do
object and compare it that way, and to do that, you just do
- git-diff-index --cached $(cat .git/HEAD)
+ git-diff-index --cached HEAD
Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
done an "git-update-index" to make that effective in the index file.
"git-diff-files" wouldn't show anything at all, since the index file
matches my working directory. But doing a "git-diff-index" does:
Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
done an "git-update-index" to make that effective in the index file.
"git-diff-files" wouldn't show anything at all, since the index file
matches my working directory. But doing a "git-diff-index" does:
- torvalds@ppc970:~/git> git-diff-index --cached $(cat .git/HEAD)
+ torvalds@ppc970:~/git> git-diff-index --cached HEAD
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c
-You can trivially see that the above is a rename.
+You can see easily that the above is a rename.
In fact, "git-diff-index --cached" *should* always be entirely equivalent to
actually doing a "git-write-tree" and comparing that. Except this one is much
In fact, "git-diff-index --cached" *should* always be entirely equivalent to
actually doing a "git-write-tree" and comparing that. Except this one is much
you *could* commit. Again, the output matches the "git-diff-tree -r"
output to a tee, but with a twist.
you *could* commit. Again, the output matches the "git-diff-tree -r"
output to a tee, but with a twist.
-The twist is that if some file doesn't match the cache, we don't have
+The twist is that if some file doesn't match the index, we don't have
a backing store thing for it, and we use the magic "all-zero" sha1 to
show that. So let's say that you have edited `kernel/sched.c`, but
have not actually done a "git-update-index" on it yet - there is no
"object" associated with the new state, and you get:
a backing store thing for it, and we use the magic "all-zero" sha1 to
show that. So let's say that you have edited `kernel/sched.c`, but
have not actually done a "git-update-index" on it yet - there is no
"object" associated with the new state, and you get:
- torvalds@ppc970:~/v2.6/linux> git-diff-index $(cat .git/HEAD )
+ torvalds@ppc970:~/v2.6/linux> git-diff-index HEAD
*100644->100664 blob 7476bb......->000000...... kernel/sched.c
*100644->100664 blob 7476bb......->000000...... kernel/sched.c
-ie it shows that the tree has changed, and that `kernel/sched.c` has is
+i.e., it shows that the tree has changed, and that `kernel/sched.c` has is
not up-to-date and may contain new stuff. The all-zero sha1 means that to
get the real diff, you need to look at the object in the working directory
directly rather than do an object-to-object diff.
not up-to-date and may contain new stuff. The all-zero sha1 means that to
get the real diff, you need to look at the object in the working directory
directly rather than do an object-to-object diff.
actually look at the contents of the file at all. So maybe
`kernel/sched.c` hasn't actually changed, and it's just that you
touched it. In either case, it's a note that you need to
actually look at the contents of the file at all. So maybe
`kernel/sched.c` hasn't actually changed, and it's just that you
touched it. In either case, it's a note that you need to
-"git-upate-cache" it to make the cache be in sync.
+"git-update-index" it to make the index be in sync.
NOTE: You can have a mixture of files show up as "has been updated"
and "is still dirty in the working directory" together. You can always
NOTE: You can have a mixture of files show up as "has been updated"
and "is still dirty in the working directory" together. You can always