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`
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
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.
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?
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