Merge branch 'master' into np/dreflog

This is to resolve conflicts early in preparation for possible
inclusion of "reflog on detached HEAD" series by Nico, as having
it in 1.5.0 would really help us remove confusion between
detached and attached states.

Signed-off-by: Junio C Hamano <junkio@cox.net>

.gitignore

@@ -23,6 +23,7 @@ git-clean
 git-clone
 git-commit
 git-commit-tree
+git-config
 git-convert-objects
 git-count-objects
 git-cvsexportcommit
@@ -41,6 +42,7 @@ git-findtags
 git-fmt-merge-msg
 git-for-each-ref
 git-format-patch
+git-fsck
 git-fsck-objects
 git-gc
 git-get-tar-commit-id

Documentation/Makefile

@@ -17,7 +17,7 @@ ARTICLES += hooks
 ARTICLES += everyday
 ARTICLES += git-tools
 # with their own formatting rules.
-SP_ARTICLES = glossary howto/revert-branch-rebase
+SP_ARTICLES = glossary howto/revert-branch-rebase user-manual
 
 DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES))
 
@@ -99,6 +99,12 @@ clean:
 %.xml : %.txt
 	asciidoc -b docbook -d manpage -f asciidoc.conf $<
 
+user-manual.xml: user-manual.txt user-manual.conf
+	asciidoc -b docbook -d book $<
+
+user-manual.html: user-manual.xml
+	xmlto html-nochunks $<
+
 glossary.html : glossary.txt sort_glossary.pl
 	cat $< | \
 	perl sort_glossary.pl | \

Documentation/cmd-list.perl

@@ -97,7 +97,7 @@ sub format_one {
 git-fmt-merge-msg                       purehelpers
 git-for-each-ref                        plumbinginterrogators
 git-format-patch                        mainporcelain
-git-fsck-objects                        ancillaryinterrogators
+git-fsck	                        ancillaryinterrogators
 git-gc                                  mainporcelain
 git-get-tar-commit-id                   ancillaryinterrogators
 git-grep                                mainporcelain
@@ -144,7 +144,7 @@ sub format_one {
 git-reflog                              ancillarymanipulators
 git-relink                              ancillarymanipulators
 git-repack                              ancillarymanipulators
-git-repo-config                         ancillarymanipulators
+git-config                              ancillarymanipulators
 git-request-pull                        foreignscminterface
 git-rerere                              ancillaryinterrogators
 git-reset                               mainporcelain

Documentation/config.txt

@@ -39,7 +39,7 @@ in the section header, like in example below:
 
 Subsection names can contain any characters except newline (doublequote
 '`"`' and backslash have to be escaped as '`\"`' and '`\\`',
-respecitvely) and are case sensitive.  Section header cannot span multiple
+respectively) and are case sensitive.  Section header cannot span multiple
 lines.  Variables may belong directly to a section or to a given subsection.
 You can have `[section]` if you have `[section "subsection"]`, but you
 don't need to.
@@ -62,7 +62,7 @@ The values following the equals sign in variable assign are all either
 a string, an integer, or a boolean.  Boolean values may be given as yes/no,
 0/1 or true/false.  Case is not significant in boolean values, when
 converting value to the canonical form using '--bool' type specifier;
-`git-repo-config` will ensure that the output is "true" or "false".
+`git-config` will ensure that the output is "true" or "false".
 
 String values may be entirely or partially enclosed in double quotes.
 You need to enclose variable value in double quotes if you want to
@@ -250,23 +250,29 @@ color.branch.<slot>::
 	Use customized color for branch coloration. `<slot>` is one of
 	`current` (the current branch), `local` (a local branch),
 	`remote` (a tracking branch in refs/remotes/), `plain` (other
-	refs), or `reset` (the normal terminal color).  The value for
-	these configuration variables can be one of: `normal`, `bold`,
-	`dim`, `ul`, `blink`, `reverse`, `reset`, `black`, `red`,
-	`green`, `yellow`, `blue`, `magenta`, `cyan`, or `white`.
+	refs).
++
+The value for these configuration variables is a list of colors (at most
+two) and attributes (at most one), separated by spaces.  The colors
+accepted are `normal`, `black`, `red`, `green`, `yellow`, `blue`,
+`magenta`, `cyan` and `white`; the attributes are `bold`, `dim`, `ul`,
+`blink` and `reverse`.  The first color given is the foreground; the
+second is the background.  The position of the attribute, if any,
+doesn't matter.
 
 color.diff::
 	When true (or `always`), always use colors in patch.
 	When false (or `never`), never.  When set to `auto`, use
 	colors only when the output is to the terminal.
 
 color.diff.<slot>::
-	Use customized color for diff colorization.  `<slot>`
-	specifies which part of the patch to use the specified
-	color, and is one of `plain` (context text), `meta`
-	(metainformation), `frag` (hunk header), `old` (removed
-	lines), or `new` (added lines).  The values of these
-	variables may be specified as in color.branch.<slot>.
+	Use customized color for diff colorization.  `<slot>` specifies
+	which part of the patch to use the specified color, and is one
+	of `plain` (context text), `meta` (metainformation), `frag`
+	(hunk header), `old` (removed lines), `new` (added lines),
+	`commit` (commit headers), or `whitespace` (highlighting dubious
+	whitespace).  The values of these variables may be specified as
+	in color.branch.<slot>.
 
 color.pager::
 	A boolean to enable/disable colored output when the pager is in

Documentation/core-intro.txt

@@ -82,7 +82,7 @@ size> + <byte\0> + <binary object data>.
 
 The structured objects can further have their structure and
 connectivity to other objects verified. This is generally done with
-the `git-fsck-objects` program, which generates a full dependency graph
+the `git-fsck` program, which generates a full dependency graph
 of all objects, and verifies their internal consistency (in addition
 to just verifying their superficial consistency through the hash).
 

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

Documentation/cvs-migration.txt

@@ -36,7 +36,7 @@ them first before running git pull.
 ================================
 The `pull` command knows where to get updates from because of certain
 configuration variables that were set by the first `git clone`
-command; see `git repo-config -l` and the gitlink:git-repo-config[1] man
+command; see `git config -l` and the gitlink:git-config[1] man
 page for details.
 ================================
 

Documentation/diff-format.txt

@@ -159,7 +159,7 @@ or like this (when '--cc' option is used):
        deleted file mode <mode>,<mode>
 +
 The `mode <mode>,<mode>..<mode>` line appears only if at least one of
-the <mode> is diferent from the rest. Extended headers with
+the <mode> is different from the rest. Extended headers with
 information about detected contents movement (renames and
 copying detection) are designed to work with diff of two
 <tree-ish> and are not used by combined diff format.