From 2f99710cfe2aacce077c510f93b51edd9ba16a0d Mon Sep 17 00:00:00 2001 From: "J. Bruce Fields" Date: Sun, 14 Jan 2007 22:43:47 -0500 Subject: [PATCH] user-manual: rewrap, fix heading levels Fix some heading levels that prevented compile; rewrap some stuff. Signed-off-by: "J. Bruce Fields" --- Documentation/user-manual.txt | 40 ++++++++++++++++++++--------------- 1 file changed, 23 insertions(+), 17 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index eeec2cdce0..369cdad4fa 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. -- 2.47.1