Unlike "git-diff-files", which showed the difference between the index
file and the working directory, "git-diff-cache" shows the differences
-between a committed _tree_ and the index file. In other words,
-git-diff-cache wants a tree to be diffed against, and before we did the
-commit, we couldn't do that, because we didn't have anything to diff
-against.
+between a committed _tree_ and either the the index file or the working
+directory. In other words, git-diff-cache wants a tree to be diffed
+against, and before we did the commit, we couldn't do that, because we
+didn't have anything to diff against.
But now we can do
(where "-p" has the same meaning as it did in git-diff-files), and it
will show us the same difference, but for a totally different reason.
-Now we're not comparing against the index file, we're comparing against
-the tree we just wrote. It just so happens that those two are obviously
-the same.
-
-"git-diff-cache" also has a specific flag "--cached", which is used to
-tell it to show the differences purely with the index file, and ignore
-the current working directory state entirely. Since we just wrote the
-index file to HEAD, doing "git-diff-cache --cached -p HEAD" should thus
-return an empty set of differences, and that's exactly what it does.
+Now we're comparing the working directory not against the index file,
+but against the tree we just wrote. It just so happens that those two
+are obviously the same, so we get the same result.
+
+In other words, "git-diff-cache" normally compares a tree against the
+working directory, but when given the "--cached" flag, it is told to
+instead compare against just the index cache contents, and ignore the
+current working directory state entirely. Since we just wrote the index
+file to HEAD, doing "git-diff-cache --cached -p HEAD" should thus return
+an empty set of differences, and that's exactly what it does.
+
+[ Digression: "git-diff-cache" really always uses the index for its
+ comparisons, and saying that it compares a tree against the working
+ directory is thus not strictly accurate. In particular, the list of
+ files to compare (the "meta-data") _always_ comes from the index file,
+ regardless of whether the --cached flag is used or not. The --cached
+ flag really only determines whether the file _contents_ to be compared
+ come from the working directory or not.
+
+ This is not hard to understand, as soon as you realize that git simply
+ never knows (or cares) about files that it is not told about
+ explicitly. Git will never go _looking_ for files to compare, it
+ expects you to tell it what the files are, and that's what the index
+ is there for. ]
However, our next step is to commit the _change_ we did, and again, to
understand what's going on, keep in mind the difference between "working
can just leave an empty message. Otherwise git-commit-script will commit
the change for you.
-(Btw, current versions of git will consider the change in question to be
-so big that it's considered a whole new file, since the diff is actually
-bigger than the file. So the helpful comments that git-commit-script
-tells you for this example will say that you deleted and re-created the
-file "a". For a less contrived example, these things are usually more
-obvious).
-
You've now made your first real git commit. And if you're interested in
looking at what git-commit-script really does, feel free to investigate:
it's a few very simple shell scripts to generate the helpful (?) commit
known state (you don't know _what_ they've done and not yet checked in),
so usually you'll precede the "git-update-cache" with a
- git-read-tree HEAD
+ git-read-tree --reset HEAD
git-update-cache --refresh
-which will force a total index re-build from the tree pointed to by
-HEAD.
+which will force a total index re-build from the tree pointed to by HEAD
+(it resets the index contents to HEAD, and then the git-update-cache
+makes sure to match up all index entries with the checked-out files).
+
+The above can also be written as simply
+
+ git reset
+
+and in fact a lot of the common git command combinations can be scripted
+with the "git xyz" interfaces, and you can learn things by just looking
+at what the git-*-script scripts do ("git reset" is the above two lines
+implemented in "git-reset-script", but some things like "git status" and
+"git commit" are slightly more complex scripts around the basic git
+commands).
-In fact, many public remote repositories will not contain any of the
-checked out files or even an index file, and will _only_ contain the
-actual core git files. Such a repository usually doesn't even have the
+NOTE! Many (most?) public remote repositories will not contain any of
+the checked out files or even an index file, and will _only_ contain the
+actual core git files. Such a repository usually doesn't even have the
".git" subdirectory, but has all the git files directly in the
-repository.
+repository.
To create your own local live copy of such a "raw" git repository, you'd
first create your own subdirectory for the project, and then copy the