user-manual: rewrap, fix heading levels

Fix some heading levels that prevented compile; rewrap some stuff.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>

1 files changed, 23 insertions, 17 deletions

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index eeec2cdce..369cdad4f 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -770,7 +770,7 @@ Examples
 --------
 
 Check whether two branches point at the same history
-----------------------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Suppose you want to check whether two branches point at the same point
 in history.
@@ -802,7 +802,7 @@ $ git log origin...master
 will return no commits when the two branches are equal.
 
 Check which tagged version a given fix was first included in
-------------------------------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Suppose you know that the commit e05db0fd fixed a certain problem.
 You'd like to find the earliest tagged release that contains that
@@ -1723,14 +1723,15 @@ Notes and todo list for this manual
 This is a work in progress.
 
 The basic requirements:
-	- It must be readable in order, from beginning to end, by someone
-	  intelligent with a basic grasp of the unix commandline, but
-	  without any special knowledge of git.  If necessary, any other
-	  prerequisites should be specifically mentioned as they arise.
-	- Whenever possible, section headings should clearly describe the
-	  task they explain how to do, in language that requires no more
-	  knowledge than necessary: for example, "importing patches into a
-	  project" rather than "the git-am command"
+	- It must be readable in order, from beginning to end, by
+	  someone intelligent with a basic grasp of the unix
+	  commandline, but without any special knowledge of git.  If
+	  necessary, any other prerequisites should be specifically
+	  mentioned as they arise.
+	- Whenever possible, section headings should clearly describe
+	  the task they explain how to do, in language that requires
+	  no more knowledge than necessary: for example, "importing
+	  patches into a project" rather than "the git-am command"
 
 Think about how to create a clear chapter dependency graph that will
 allow people to get to important topics without necessarily reading
@@ -1748,20 +1749,25 @@ Scan email archives for other stuff left out
 Scan man pages to see if any assume more background than this manual
 provides.
 
-Simplify beginning by suggesting disconnected head instead of temporary
-branch creation.
+Simplify beginning by suggesting disconnected head instead of
+temporary branch creation.
 
 Explain how to refer to file stages in the "how to resolve a merge"
 section: diff -1, -2, -3, --ours, --theirs :1:/path notation.  The
-"git ls-files --unmerged --stage" thing is sorta useful too, actually.  And
-note gitk --merge.  Also what's easiest way to see common merge base?
+"git ls-files --unmerged --stage" thing is sorta useful too,
+actually.  And note gitk --merge.  Also what's easiest way to see
+common merge base?  Note also text where I claim rebase and am
+conflicts are resolved like merges isn't generally true, at least by
+default--fix.
 
-Add more good examples.  Entire sections of just cookbook examples might
-be a good idea; maybe make an "advanced examples" section a standard
-end-of-chapter section?
+Add more good examples.  Entire sections of just cookbook examples
+might be a good idea; maybe make an "advanced examples" section a
+standard end-of-chapter section?
 
 Include cross-references to the glossary, where appropriate.
 
+Add quickstart as first chapter.
+
 To document:
 	reflogs, git reflog expire
 	shallow clones??  See draft 1.5.0 release notes for some documentation.