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
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"
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, 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.. ]