Make the name of a pack-file depend on the objects packed there-in.
[git.git] / Documentation / tutorial.txt
index 6faf743..957ea96 100644 (file)
@@ -371,13 +371,6 @@ this point (you can continue to edit things and update the cache), you
 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
@@ -488,17 +481,29 @@ repositories you often want to make sure that the index cache is in some
 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