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
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
*what* you are going to commit is without having to write a new tree
object and compare it that way, and to do that, you just do
*what* you are going to commit is without having to write a new tree
object and compare it that way, and to do that, you just do
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:
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c
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.
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:
*100644->100664 blob 7476bb......->000000...... kernel/sched.c
ie it shows that the tree has changed, and that `kernel/sched.c` has is
*100644->100664 blob 7476bb......->000000...... kernel/sched.c
ie it shows that the tree has changed, and that `kernel/sched.c` has is
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
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