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
git log
which shows just the log messages, or if we want to see the log together
-whith the associated patches use the more complex (and much more
+with the associated patches use the more complex (and much more
powerful)
git-whatchanged -p --root
can explore on your own.
- Copoying archives
+ Copying archives
-----------------
-Git arhives are normally totally self-sufficient, and it's worth noting
+Git archives are normally totally self-sufficient, and it's worth noting
that unlike CVS, for example, there is no separate notion of
"repository" and "working tree". A git repository normally _is_ the
working tree, with the local git information hidden in the ".git"
repository.
To create your own local live copy of such a "raw" git repository, you'd
-first create your own subdirectory for the project, adn then copy the
+first create your own subdirectory for the project, and then copy the
raw repository contents into the ".git" directory. For example, to
create your own copy of the git repository, you'd do the following
git-checkout-cache -u -a
where the "-u" flag means that you want the checkout to keep the index
-up-to-date (so that you don't have to refresh it afterwards), and the
+up-to-date (so that you don't have to refresh it afterward), and the
"-a" file means "check out all files" (if you have a stale copy or an
older version of a checked out tree you may also need to add the "-f"
file first, to tell git-checkout-cache to _force_ overwriting of any old
files).
-You have now successfully copied somebody elses (mine) remote
+You have now successfully copied somebody else's (mine) remote
repository, and checked it out.
[ to be continued.. cvs2git, tagging versions, branches, merging.. ]