git-send-email: Document configuration options

[git.git] / Documentation / core-tutorial.txt

diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 7317489cfcdda369e7e296ff9032c36848efe11e..9c28bea62e5848e30137c063ca8fa91de737ca01 100644 (file)
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -624,7 +624,7 @@ name for the state at that point.
 Copying repositories
 --------------------
 
-git repositories are normally totally self-sufficient and relocatable
+git repositories are normally totally self-sufficient and relocatable.
 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`
@@ -1118,7 +1118,7 @@ You could do without using any branches at all, by
 keeping as many local repositories as you would like to have
 branches, and merging between them with `git pull`, just like
 you merge between branches. The advantage of this approach is
-that it lets you keep set of files for each `branch` checked
+that it lets you keep a set of files for each `branch` checked
 out and you may find it easier to switch back and forth if you
 juggle multiple lines of development simultaneously. Of
 course, you will pay the price of more disk usage to hold
@@ -1130,7 +1130,7 @@ the remote repository URL in the local repository's config file
 like this:
 
 ------------------------------------------------
-$ git repo-config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
+$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
 ------------------------------------------------
 
 and use the "linus" keyword with `git pull` instead of the full URL.
@@ -1300,7 +1300,7 @@ differences since stage 2 (i.e. your version).
 Publishing your work
 --------------------
 
-So we can use somebody else's work from a remote repository; but
+So, we can use somebody else's work from a remote repository, but
 how can *you* prepare a repository to let other people pull from
 it?
 
@@ -1469,8 +1469,8 @@ Working with Others
 Although git is a truly distributed system, it is often
 convenient to organize your project with an informal hierarchy
 of developers. Linux kernel development is run this way. There
-is a nice illustration (page 17, "Merges to Mainline") in Randy
-Dunlap's presentation (`http://tinyurl.com/a2jdg`).
+is a nice illustration (page 17, "Merges to Mainline") in
+link:http://tinyurl.com/a2jdg[Randy Dunlap's presentation].
 
 It should be stressed that this hierarchy is purely *informal*.
 There is nothing fundamental in git that enforces the "chain of