user-manual: use pithier example commit
[gitweb.git] / Documentation / tutorial-2.txt
index 2f4fe1217a3cd6d9d958130ca5e03c68b027abc1..5c39a165f5587859750ba924623e817941ef0f71 100644 (file)
@@ -17,18 +17,19 @@ Let's start a new project and create a small amount of history:
 ------------------------------------------------
 $ mkdir test-project
 $ cd test-project
-$ git init-db
-defaulting to local storage area
+$ git init
+Initialized empty Git repository in .git/
 $ echo 'hello world' > file.txt
 $ git add .
 $ git commit -a -m "initial commit"
-Committing initial tree 92b8b694ffb1675e5975148e1121810081dbdffe
+Created initial commit 54196cc2703dc165cbd373a65a4dcf22d50ae7f7
+ create mode 100644 file.txt
 $ echo 'hello world!' >file.txt
 $ git commit -a -m "add emphasis"
+Created commit c4d59f390b9cfd4318117afde11d601c1085f241
 ------------------------------------------------
 
-What are the 40 digits of hex that git responded to the first commit
-with?
+What are the 40 digits of hex that git responded to the commit with?
 
 We saw in part one of the tutorial that commits have names like this.
 It turns out that every object in the git history is stored under
@@ -38,13 +39,25 @@ the same data twice (since identical data is given an identical SHA1
 name), and that the contents of a git object will never change (since
 that would change the object's name as well).
 
+It is expected that the content of the commit object you created while
+following the example above generates a different SHA1 hash than
+the one shown above because the commit object records the time when
+it was created and the name of the person performing the commit.
+
 We can ask git about this particular object with the cat-file
-command--just cut-and-paste from the reply to the initial commit, to
-save yourself typing all 40 hex digits:
+command. Don't copy the 40 hex digits from this example but use those
+from your own version. Note that you can shorten it to only a few
+characters to save yourself typing all 40 hex digits:
 
 ------------------------------------------------
-$ git cat-file -t 92b8b694ffb1675e5975148e1121810081dbdffe
-tree
+$ git-cat-file -t 54196cc2
+commit
+$ git-cat-file commit 54196cc2
+tree 92b8b694ffb1675e5975148e1121810081dbdffe
+author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+
+initial commit
 ------------------------------------------------
 
 A tree can refer to one or more "blob" objects, each corresponding to
@@ -101,8 +114,7 @@ $ find .git/objects/
 
 and the contents of these files is just the compressed data plus a
 header identifying their length and their type.  The type is either a
-blob, a tree, a commit, or a tag.  We've seen a blob and a tree now,
-so next we should look at a commit.
+blob, a tree, a commit, or a tag.
 
 The simplest commit to find is the HEAD commit, which we can find
 from .git/HEAD:
@@ -215,7 +227,7 @@ $ git diff
 @@ -1 +1,2 @@
  hello world!
 +hello world, again
-$ git update-index file.txt
+$ git add file.txt
 $ git diff
 ------------------------------------------------
 
@@ -248,7 +260,7 @@ hello world!
 hello world, again
 ------------------------------------------------
 
-So what our "git update-index" did was store a new blob and then put
+So what our "git add" did was store a new blob and then put
 a reference to it in the index file.  If we modify the file again,
 we'll see that the new modifications are reflected in the "git-diff"
 output:
@@ -331,8 +343,8 @@ And, as you can see with cat-file, this new entry refers to the
 current contents of the file:
 
 ------------------------------------------------
-$ git cat-file blob a6b11f7a
-goodbye, word
+$ git cat-file blob 8b9743b2
+goodbye, world
 ------------------------------------------------
 
 The "status" command is a useful way to get a quick summary of the
@@ -340,22 +352,21 @@ situation:
 
 ------------------------------------------------
 $ git status
-#
-# Updated but not checked in:
-#   (will commit)
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
 #
 #       new file: closing.txt
 #
-#
 # Changed but not updated:
-#   (use git-update-index to mark for commit)
+#   (use "git add <file>..." to update what will be committed)
 #
 #       modified: file.txt
 #
 ------------------------------------------------
 
 Since the current state of closing.txt is cached in the index file,
-it is listed as "updated but not checked in".  Since file.txt has
+it is listed as "Changes to be committed".  Since file.txt has
 changes in the working directory that aren't reflected in the index,
 it is marked "changed but not updated".  At this point, running "git
 commit" would create a commit that added closing.txt (with its new
@@ -368,7 +379,7 @@ in the index file is identical to the one in the working directory.
 In addition to being the staging area for new commits, the index file
 is also populated from the object database when checking out a
 branch, and is used to hold the trees involved in a merge operation.
-See the link:core-tutorial.txt[core tutorial] and the relevant man
+See the link:core-tutorial.html[core tutorial] and the relevant man
 pages for details.
 
 What next?
@@ -380,6 +391,9 @@ with the commands mentioned in link:everyday.html[Everyday git].  You
 should be able to find any unknown jargon in the
 link:glossary.html[Glossary].
 
+The link:user-manual.html[Git User's Manual] provides a more
+comprehensive introduction to git.
+
 The link:cvs-migration.html[CVS migration] document explains how to
 import a CVS repository into git, and shows how to use git in a
 CVS-like way.