git-svn: update documentation for multi-{init|fetch}

[git.git] / Documentation / tutorial.txt

diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index cb808d924be51e111b3e57b1b6e007cdf9f451bb..79884d9c74d3175e179dc5a83e9163908242d6ca 100644 (file)
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -65,16 +65,19 @@ Try modifying some files, then run
 $ git diff
 ------------------------------------------------
 
-to review your changes.  When you're done,
+to review your changes.  When you're done, tell git that you
+want the updated contents of these files in the commit and then
+make a commit, like this:
 
 ------------------------------------------------
-$ git commit file1 file2...
+$ git add file1 file...
+$ git commit
 ------------------------------------------------
 
-will again prompt your for a message describing the change, and then
+This will again prompt your for a message describing the change, and then
 record the new versions of the files you listed.  It is cumbersome
-to list all files and you can say `-a` (which stands for 'all')
-instead.
+to list all files and you can say `git commit -a` (which stands for 'all')
+instead of running `git add` beforehand.
 
 ------------------------------------------------
 $ git commit -a
@@ -84,7 +87,7 @@ A note on commit messages: Though not required, it's a good idea to
 begin the commit message with a single short (less than 50 character)
 line summarizing the change, followed by a blank line and then a more
 thorough description.  Tools that turn commits into email, for
-example, use the first line on the Subject line and the rest of the
+example, use the first line on the Subject: line and the rest of the
 commit in the body.
 
 
@@ -142,6 +145,13 @@ If you also want to see complete diffs at each step, use
 $ git log -p
 ------------------------------------------------
 
+Often the overview of the change is useful to get a feel of
+each step
+
+------------------------------------------------
+$ git log --stat --summary
+------------------------------------------------
+
 Managing branches
 -----------------
 
@@ -222,6 +232,15 @@ $ gitk
 
 will show a nice graphical representation of the resulting history.
 
+At this point you could delete the experimental branch with
+
+------------------------------------------------
+$ git branch -d experimental
+------------------------------------------------
+
+This command ensures that the changes in the experimental branch are
+already in the current branch.
+
 If you develop on a branch crazy-idea, then regret it, you can always
 delete the branch with
 
@@ -323,20 +342,25 @@ $ git pull
 
 Note that he doesn't need to give the path to Alice's repository;
 when Bob cloned Alice's repository, git stored the location of her
-repository in the file .git/remotes/origin, and that location is used
-as the default for pulls.
-
-Bob may also notice a branch in his repository that he didn't create:
+repository in the repository configuration, and that location is
+used for pulls:
 
 -------------------------------------
-$ git branch
-* master
-  origin
+$ git repo-config --get remote.origin.url
+/home/bob/myrepo
 -------------------------------------
 
-The "origin" branch, which was created automatically by "git clone",
-is a pristine copy of Alice's master branch; Bob should never commit
-to it.
+(The complete configuration created by git-clone is visible using
+"git repo-config -l", and the gitlink:git-repo-config[1] man page
+explains the meaning of each option.)
+
+Git also keeps a pristine copy of Alice's master branch under the
+name "origin/master":
+
+-------------------------------------
+$ git branch -r
+  origin/master
+-------------------------------------
 
 If Bob later decides to work from a different host, he can still
 perform clones and pulls using the ssh protocol:
@@ -376,7 +400,7 @@ commit.
 $ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
 -------------------------------------
 
-But there other ways to refer to commits.  You can use any initial
+But there are other ways to refer to commits.  You can use any initial
 part of the name that is long enough to uniquely identify the commit:
 
 -------------------------------------
@@ -386,8 +410,8 @@ $ git show HEAD             # the tip of the current branch
 $ git show experimental        # the tip of the "experimental" branch
 -------------------------------------
 
-Every commit has at least one "parent" commit, which points to the
-previous state of the project:
+Every commit usually has one "parent" commit
+which points to the previous state of the project:
 
 -------------------------------------
 $ git show HEAD^  # to see the parent of HEAD
@@ -505,10 +529,10 @@ of the file:
 $ git diff v2.5:Makefile HEAD:Makefile.in
 -------------------------------------
 
-You can also use "git cat-file -p" to see any such file:
+You can also use "git show" to see any such file:
 
 -------------------------------------
-$ git cat-file -p v2.5:Makefile
+$ git show v2.5:Makefile
 -------------------------------------
 
 Next Steps