Git 1.7.0.8

Signed-off-by: Junio C Hamano <gitster@pobox.com>

.gitignore

@@ -112,7 +112,6 @@
 /git-remote-https
 /git-remote-ftp
 /git-remote-ftps
-/git-remote-testgit
 /git-repack
 /git-replace
 /git-repo-config
@@ -156,9 +155,7 @@
 /git-write-tree
 /git-core-*/?*
 /gitk-git/gitk-wish
-/gitweb/GITWEB-BUILD-OPTIONS
 /gitweb/gitweb.cgi
-/gitweb/static/gitweb.min.*
 /test-chmtime
 /test-ctype
 /test-date
@@ -166,17 +163,12 @@
 /test-dump-cache-tree
 /test-genrandom
 /test-index-version
-/test-line-buffer
 /test-match-trees
-/test-obj-pool
 /test-parse-options
 /test-path-utils
 /test-run-command
 /test-sha1
 /test-sigchain
-/test-string-pool
-/test-svn-fe
-/test-treap
 /common-cmds.h
 *.tar.gz
 *.dsc
@@ -185,13 +177,6 @@
 *.exe
 *.[aos]
 *.py[co]
-.depend/
-*.gcda
-*.gcno
-*.gcov
-/coverage-untested-functions
-/cover_db/
-/cover_db_html/
 *+
 /config.mak
 /autom4te.cache

Documentation/Makefile

@@ -6,7 +6,7 @@ MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \
 	gitrepository-layout.txt
 MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \
 	gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \
-	gitdiffcore.txt gitrevisions.txt gitworkflows.txt
+	gitdiffcore.txt gitworkflows.txt
 
 MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
 MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
@@ -279,7 +279,7 @@ $(patsubst %,%.html,$(API_DOCS) technical/api-index): %.html : %.txt
 XSLT = docbook.xsl
 XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css
 
-user-manual.html: user-manual.xml $(XSLT)
+user-manual.html: user-manual.xml
 	$(QUIET_XSLTPROC)$(RM) $@+ $@ && \
 	xsltproc $(XSLTOPTS) -o $@+ $(XSLT) $< && \
 	mv $@+ $@

Documentation/RelNotes-1.5.6.3.txt

@@ -4,7 +4,7 @@ GIT v1.5.6.3 Release Notes
 Fixes since v1.5.6.2
 --------------------
 
-* Setting core.sharedrepository to traditional "true" value was supposed to make
+* Setting core.sharerepository to traditional "true" value was supposed to make
   the repository group writable but should not affect permission for others.
   However, since 1.5.6, it was broken to drop permission for others when umask is
   022, making the repository unreadable by others.

Documentation/RelNotes-1.6.0.2.txt

@@ -17,7 +17,7 @@ Fixes since v1.6.0.1
 * Many commands did not use the correct working tree location when used
   with GIT_WORK_TREE environment settings.
 
-* Some systems need to use compatibility fnmatch and regex libraries
+* Some systems needs to use compatibility fnmach and regex libraries
   independent from each other; the compat/ area has been reorganized to
   allow this.
 

Documentation/RelNotes-1.6.4.3.txt

@@ -11,7 +11,7 @@ Fixes since v1.6.4.2
   been deprecated.
 
 * "git fetch" and "git clone" had an extra sanity check to verify the
-  presence of the corresponding *.pack file before downloading *.idx
+  presense of the corresponding *.pack file before downloading *.idx
   file by issuing a HEAD request.  Github server however sometimes
   gave 500 (Internal server error) response to HEAD even if a GET
   request for *.pack file to the same URL would have succeeded, and broke

Documentation/RelNotes-1.6.5.4.txt

@@ -26,7 +26,7 @@ Fixes since v1.6.5.3
    future versions, but not in this release,
 
  * "git merge -m <message> <branch>..." added the standard merge message
-   on its own after user-supplied message, which should have overridden the
+   on its own after user-supplied message, which should have overrided the
    standard one.
 
 Other minor documentation updates are included.

Documentation/RelNotes-1.6.5.7.txt

@@ -10,7 +10,7 @@ Fixes since v1.6.5.6
   an older version of git should just ignore them.  Instead we diagnosed
   it as an error.
 
-* With help.autocorrect set to non-zero value, the logic to guess typos
+* With help.autocorrect set to non-zero value, the logic to guess typoes
   in the subcommand name misfired and ran a random nonsense command.
 
 * If a command is run with an absolute path as a pathspec inside a bare

Documentation/RelNotes-1.6.6.txt

@@ -29,7 +29,7 @@ or adjust to the new behaviour, on the day their sysadmin decides to install
 the new version of git.  When we switched from "git-foo" to "git foo" in
 1.6.0, even though the change had been advertised and the transition
 guide had been provided for a very long time, the users procrastinated
-during the entire transition period, and ended up panicking on the day
+during the entire transtion period, and ended up panicking on the day
 their sysadmins updated their git installation.  We are trying to avoid
 repeating that unpleasantness in the 1.7.0 release.
 
@@ -94,7 +94,7 @@ users will fare this time.
  * "git diff" traditionally treated various "ignore whitespace" options
    only as a way to filter the patch output.  "git diff --exit-code -b"
    exited with non-zero status even if all changes were about changing the
-   amount of whitespace and nothing else.  and "git diff -b" showed the
+   ammount of whitespace and nothing else.  and "git diff -b" showed the
    "diff --git" header line for such a change without patch text.
 
    In 1.7.0, the "ignore whitespaces" will affect the semantics of the

Documentation/RelNotes-1.7.0.txt

@@ -202,7 +202,7 @@ release, unless otherwise noted.
    the branch is fully merged to its upstream branch if it is not merged
    to the current branch.  It now deletes it in such a case.
 
- * "filter-branch" command incorrectly said --prune-empty and --filter-commit
+ * "fiter-branch" command incorrectly said --prune-empty and --filter-commit
    were incompatible; the latter should be read as --commit-filter.
 
  * When using "git status" or asking "git diff" to compare the work tree

Documentation/RelNotes-1.7.1.1.txt

@@ -1,96 +0,0 @@
-Git v1.7.1.1 Release Notes
-==========================
-
-Fixes since v1.7.1
-------------------
-
- * Authentication over http transport can now be made lazily, in that the
-   request can first go to a URL without username, get a 401 response and
-   then the client will ask for the username to use.
-
- * We used to mistakenly think "../work" is a subdirectory of the current
-   directory when we are in "../work-xyz".
-
- * The attribute mechanism now allows an entry that uses an attribute
-   macro that set/unset one attribute, immediately followed by an
-   overriding setting; this makes attribute macros much easier to use.
-
- * We didn't recognize timezone "Z" as a synonym for "UTC" (75b37e70).
-
- * In 1.7.0, read-tree and user commands that use the mechanism such as
-   checkout and merge were fixed to handle switching between branches one
-   of which has a file while the other has a directory at the same path
-   correctly even when there are some "confusing" pathnames in them.  But
-   the algorithm used for this fix was suboptimal and had a terrible
-   performance degradation especially in larger trees.
-
- * "git am -3" did not show diagnosis when the patch in the message was corrupt.
-
- * After "git apply --whitespace=fix" removed trailing blank lines in an
-   patch in a patch series, it failed to apply later patches that depend
-   on the presence of such blank lines.
-
- * "git bundle --stdin" segfaulted.
-
- * "git checkout" and "git rebase" overwrote paths that are marked "assume
-   unchanged".
-
- * "git commit --amend" on a commit with an invalid author-name line that
-   lacks the display name didn't work.
-
- * "git describe" did not tie-break tags that point at the same commit
-   correctly; newer ones are preferred by paying attention to the
-   tagger date now.
-
- * "git diff" used to tell underlying xdiff machinery to work very hard to
-   minimize the output, but this often was spending too many extra cycles
-   for very little gain.
-
- * "git diff --color" did not paint extended diff headers per line
-   (i.e. the coloring escape sequence didn't end at the end of line),
-   which confused "less -R".
-
- * "git fetch" over HTTP verifies the downloaded packfiles more robustly.
-
- * The memory usage by "git index-pack" (run during "git fetch" and "git
-   push") got leaner.
-
- * "GIT_DIR=foo.git git init --bare bar.git" created foo.git instead of bar.git.
-
- * "git log --abbrev=$num --format='%h' ignored --abbrev=$num.
-
- * "git ls-files ../out/side/cwd" refused to work.
-
- * "git merge --log" used to replace the custom message given by "-m" with
-   the shortlog, instead of appending to it.
-
- * "git notes copy" without any other argument segfaulted.
-
- * "git pull" accepted "--dry-run", gave it to underlying "git fetch" but
-   ignored the option itself, resulting in a bogus attempt to merge
-   unrelated commit.
-
- * "git rebase" did not faithfully reproduce a malformed author ident, that
-   is often seen in a repository converted from foreign SCMs.
-
- * "git reset --hard" started from a wrong directory and a working tree in
-   a nonstandard location is in use got confused.
-
- * "git send-email" lacked a way to specify the domainname used in the
-   EHLO/HELO exchange, causing rejected connection from picky servers.
-   It learned --smtp-domain option to solve this issue.
-
- * "git send-email" did not declare a content-transfer-encoding and
-   content-type even when its payload needs to be sent in 8-bit.
-
- * "git show -C -C" and other corner cases lost diff metainfo output
-   in 1.7.0.
-
- * "git stash" incorrectly lost paths in the working tree that were
-   previously removed from the index.
-
- * "git status" stopped refreshing the index by mistake in 1.7.1.
-
- * "git status" showed excess "hints" even when advice.statusHints is set to false.
-
-And other minor fixes and documentation updates.

Documentation/RelNotes-1.7.1.2.txt

@@ -1,28 +0,0 @@
-Git v1.7.1.2 Release Notes
-==========================
-
-Fixes since v1.7.1.1
---------------------
-
- * "git commit" did not honor GIT_REFLOG_ACTION environment variable, resulting
-   reflog messages for cherry-pick and revert actions to be recorded as "commit".
-
- * "git clone/fetch/pull" issued an incorrect error message when a ref and
-   a symref that points to the ref were updated at the same time.  This
-   obviously would update them to the same value, and should not result in
-   an error condition.
-
- * "git diff" inside a tree with many pathnames that have certain
-   characters has become very slow in 1.7.0 by mistake.
-
- * "git rev-parse --parseopt --stop-at-non-option" did not stop at non option
-   when --keep-dashdash was in effect.
-
- * An overlong line after ".gitdir: " in a git file caused out of bounds
-   access to an array on the stack.
-
- * "git config --path conf.var" to attempt to expand a variable conf.var
-   that uses "~/" short-hand segfaulted when $HOME environment variable
-   was not set.
-
-And other minor fixes and documentation updates.

Documentation/RelNotes-1.7.1.txt

@@ -1,89 +0,0 @@
-Git v1.7.1 Release Notes
-========================
-
-Updates since v1.7.0
---------------------
-
- * Eric Raymond is the maintainer of updated CIAbot scripts, in contrib/.
-
- * gitk updates.
-
- * Some commands (e.g. svn and http interfaces) that interactively ask
-   for a password can be told to use an external program given via
-   GIT_ASKPASS.
-
- * Conflict markers that lead the common ancestor in diff3-style output
-   now have a label, which hopefully would help third-party tools that
-   expect one.
-
- * Comes with an updated bash-completion script.
-
- * "git am" learned "--keep-cr" option to handle inputs that are
-   a mixture of changes to files with and without CRLF line endings.
-
- * "git cvsimport" learned -R option to leave revision mapping between
-   CVS revisions and resulting git commits.
-
- * "git diff --submodule" notices and describes dirty submodules.
-
- * "git for-each-ref" learned %(symref), %(symref:short) and %(flag)
-   tokens.
-
- * "git hash-object --stdin-paths" can take "--no-filters" option now.
-
- * "git init" can be told to look at init.templatedir configuration
-   variable (obviously that has to come from either /etc/gitconfig or
-   $HOME/.gitconfig).
-
- * "git grep" learned "--no-index" option, to search inside contents that
-   are not managed by git.
-
- * "git grep" learned --color=auto/always/never.
-
- * "git grep" learned to paint filename and line-number in colors.
-
- * "git log -p --first-parent -m" shows one-parent diff for merge
-   commits, instead of showing combined diff.
-
- * "git merge-file" learned to use custom conflict marker size and also
-   to use the "union merge" behaviour.
-
- * "git notes" command has been rewritten in C and learned many commands
-   and features to help you carry notes forward across rebases and amends.
-
- * "git request-pull" identifies the commit the request is relative to in
-   a more readable way.
-
- * "git reset" learned "--keep" option that lets you discard commits
-   near the tip while preserving your local changes in a way similar
-   to how "git checkout branch" does.
-
- * "git status" notices and describes dirty submodules.
-
- * "git svn" should work better when interacting with repositories
-   with CRLF line endings.
-
- * "git imap-send" learned to support CRAM-MD5 authentication.
-
- * "gitweb" installation procedure can use "minified" js/css files
-   better.
-
- * Various documentation updates.
-
-Fixes since v1.7.0
-------------------
-
-All of the fixes in v1.7.0.X maintenance series are included in this
-release, unless otherwise noted.
-
- * "git add frotz/nitfol" did not complain when the entire frotz/ directory
-   was ignored.
-
- * "git diff --stat" used "int" to count the size of differences,
-   which could result in overflowing.
-
- * "git rev-list --pretty=oneline" didn't terminate a record with LF for
-   commits without any message.
-
- * "git rev-list --abbrev-commit" defaulted to 40-byte abbreviations, unlike
-   newer tools in the git toolset.

Documentation/RelNotes-1.7.2.1.txt

@@ -1,25 +0,0 @@
-Git v1.7.2.1 Release Notes
-==========================
-
-Fixes since v1.7.2
-------------------
-
- * "git instaweb" wasn't useful when your Apache was installed under a
-   name other than apache2 (e.g. "httpd").
-
- * Similarly, "git web--browse" (invoked by "git help -w") learned that
-   chrome browser is sometimes called google-chrome.
-
- * An overlong line after ".gitdir: " in a git file caused out of bounds
-   access to an array on the stack.
-
- * "git config --path conf.var" to attempt to expand a variable conf.var
-   that uses "~/" short-hand segfaulted when $HOME environment variable
-   was not set.
-
- * Documentation on Cygwin failed to build.
-
- * The error message from "git pull blarg" when 'blarg' is an unknown
-   remote name has been improved.
-
-And other minor fixes and documentation updates.

Documentation/RelNotes-1.7.2.2.txt

@@ -1,22 +0,0 @@
-Git v1.7.2.2 Release Notes
-==========================
-
-Fixes since v1.7.2.1
---------------------
-
- * Object transfer over smart http transport deadlocked the client when
-   the remote HTTP server returned a failure, instead of erroring it out.
-
- * git-gui honors custom textconv filters when showing diff and blame;
-
- * git diff --relative=subdir (without the necessary trailing /) did not
-   work well;
-
- * "git diff-files -p --submodule" was recently broken;
-
- * "git checkout -b n ':/token'" did not work;
-
- * "git index-pack" (hence "git fetch/clone/pull/push") enabled the object
-   replacement machinery by mistake (it never should have);
-
-And other minor fixes and documentation updates.

Documentation/RelNotes-1.7.2.3.txt

@@ -1,39 +0,0 @@
-Git v1.7.2.3 Release Notes
-==========================
-
-Fixes since v1.7.2.2
---------------------
-
- * When people try insane things such as delta-compressing 4GiB files, we
-   threw an assertion failure.
-
- * "git archive" gave the full commit ID for "$Format:%h$".
-
- * "git fetch --tags" did not fetch tags when remote.<nick>.tagopt was set
-   to --no-tags.  The command line option now overrides the configuration
-   setting.
-
- * "git for-each-ref --format='%(objectname:short)'" has been completely
-   broken for a long time.
-
- * "git gc" incorrectly pruned a rerere record that was created long
-   time ago but still is actively and repeatedly used.
-
- * "git log --follow -M -p" was seriously broken in 1.7.2, reporting
-   assertion failure.
-
- * Running "git log" with an incorrect option started pager nevertheless,
-   forcing the user to dismiss it.
-
- * "git rebase" did not work well when the user has diff.renames
-   configuration variable set.
-
- * An earlier (and rather old) fix to "git rebase" against a rebased
-   upstream broke a more normal, non rebased upstream case rather badly,
-   attempting to re-apply patches that are already accepted upstream.
-
- * "git submodule sync" forgot to update the superproject's config file
-   when submodule URL changed.
-
- * "git pack-refs --all --prune" did not remove a directory that has
-   become empty.

Documentation/RelNotes-1.7.2.txt

@@ -1,151 +0,0 @@
-Git v1.7.2 Release Notes
-========================
-
-Updates since v1.7.1
---------------------
-
- * core.eol configuration and text/eol attributes are the new way to control
-   the end of line conventions for files in the working tree.
-
- * core.autocrlf has been made safer - it will now only handle line
-   endings for new files and files that are LF-only in the
-   repository. To normalize content that has been checked in with
-   CRLF, use the new eol/text attributes.
-
- * The whitespace rules used in "git apply --whitespace" and "git diff"
-   gained a new member in the family (tab-in-indent) to help projects with
-   policy to indent only with spaces.
-
- * When working from a subdirectory, by default, git does not look for its
-   metadirectory ".git" across filesystems, primarily to help people who
-   have invocations of git in their custom PS1 prompts, as being outside
-   of a git repository would look for ".git" all the way up to the root
-   directory, and NFS mounts are often slow.  DISCOVERY_ACROSS_FILESYSTEM
-   environment variable can be used to tell git not to stop at a
-   filesystem boundary.
-
- * Usage help messages generated by parse-options library (i.e. most
-   of the Porcelain commands) are sent to the standard output now.
-
- * ':/<string>' notation to look for a commit now takes regular expression
-   and it is not anchored at the beginning of the commit log message
-   anymore (this is a backward incompatible change).
-
- * "git" wrapper learned "-c name=value" option to override configuration
-   variable from the command line.
-
- * Improved portability for various platforms including older SunOS,
-   HP-UX 10/11, AIX, Tru64, etc. and platforms with Python 2.4.
-
- * The message from "git am -3" has been improved when conflict
-   resolution ended up making the patch a no-op.
-
- * "git blame" applies the textconv filter to the contents it works
-   on, when available.
-
- * "git checkout --orphan newbranch" is similar to "-b newbranch" but
-   prepares to create a root commit that is not connected to any existing
-   commit.
-
- * "git cherry-pick" learned to pick a range of commits
-   (e.g. "cherry-pick A..B" and "cherry-pick --stdin"), so did "git
-   revert"; these do not support the nicer sequencing control "rebase
-   [-i]" has, though.
-
- * "git cherry-pick" and "git revert" learned --strategy option to specify
-   the merge strategy to be used when performing three-way merges.
-
- * "git cvsserver" can be told to use pserver; its password file can be
-   stored outside the repository.
-
- * The output from the textconv filter used by "git diff" can be cached to
-   speed up their reuse.
-
- * "git diff --word-diff=<mode>" extends the existing "--color-words"
-   option, making it more useful in color-challenged environments.
-
- * The regexp to detect function headers used by "git diff" for PHP has
-   been enhanced for visibility modifiers (public, protected, etc.) to
-   better support PHP5.
-
- * "diff.noprefix" configuration variable can be used to implicitly
-   ask for "diff --no-prefix" behaviour.
-
- * "git for-each-ref" learned "%(objectname:short)" that gives the object
-   name abbreviated.
-
- * "git format-patch" learned --signature option and format.signature
-   configuration variable to customize the e-mail signature used in the
-   output.
-
- * Various options to "git grep" (e.g. --count, --name-only) work better
-   with binary files.
-
- * "git grep" learned "-Ovi" to open the files with hits in your editor.
-
- * "git help -w" learned "chrome" and "chromium" browsers.
-
- * "git log --decorate" shows commit decorations in various colours.
-
- * "git log --follow <path>" follows across copies (it used to only follow
-   renames).  This may make the processing more expensive.
-
- * "git log --pretty=format:<template>" specifier learned "% <something>"
-   magic that inserts a space only when %<something> expands to a
-   non-empty string; this is similar to "%+<something>" magic, but is
-   useful in a context to generate a single line output.
-
- * "git notes prune" learned "-n" (dry-run) and "-v" options, similar to
-   what "git prune" has.
-
- * "git patch-id" can be fed a mbox without getting confused by the
-   signature line in the format-patch output.
-
- * "git remote" learned "set-branches" subcommand.
-
- * "git rev-list A..B" learned --ancestry-path option to further limit
-   the result to the commits that are on the ancestry chain between A and
-   B (i.e. commits that are not descendants of A are excluded).
-
- * "git show -5" is equivalent to "git show --do-walk 5"; this is similar
-   to the update to make "git show master..next" walk the history,
-   introduced in 1.6.4.
-
- * "git status [-s] --ignored" can be used to list ignored paths.
-
- * "git status -s -b" shows the current branch in the output.
-
- * "git status" learned "--ignore-submodules" option.
-
- * Various "gitweb" enhancements and clean-ups, including syntax
-   highlighting, "plackup" support for instaweb, .fcgi suffix to run
-   it as FastCGI script, etc.
-
- * The test harness has been updated to produce TAP-friendly output.
-
- * Many documentation improvement patches are also included.
-
-
-Fixes since v1.7.1
-------------------
-
-All of the fixes in v1.7.1.X maintenance series are included in this
-release, unless otherwise noted.
-
- * We didn't URL decode "file:///path/to/repo" correctly when path/to/repo
-   had percent-encoded characters (638794c, 9d2e942, ce83eda, 3c73a1d).
-
- * "git clone" did not configure remote.origin.url correctly for bare
-   clones (df61c889).
-
- * "git diff --graph" works better with "--color-words" and other options
-   (81fa024..4297c0a).
-
- * "git diff" could show ambiguous abbreviation of blob object names on
-   its "index" line (3e5a188).
-
- * "git reset --hard" started from a wrong directory and a working tree in
-   a nonstandard location is in use got confused (560fb6a1).
-
- * "git read-tree -m A B" used to switch to branch B while retaining
-   local changes added an incorrect cache-tree information (b1f47514).

Documentation/RelNotes-1.7.3.txt

@@ -1,73 +0,0 @@
-Git v1.7.3 Release Notes (draft)
-================================
-
-Updates since v1.7.2
---------------------
-
- * git-gui got various updates and a new maintainer, Pat Thoyts.
-
- * Gitweb allows its configuration to change per each request; it used to
-   read the configuration once upon startup.
-
- * When git finds a corrupt object, it now reports the file that contains
-   it.
-
- * "git checkout -B <it>" is a shorter way to say "git branch -f <it>"
-   followed by "git checkout <it>".
-
- * When "git checkout" or "git merge" refuse to proceed in order to
-   protect local modification to your working tree, they used to stop
-   after showing just one path that might be lost.  They now show all,
-   in a format that is easier to read.
-
- * "git clean" learned "-e" ("--exclude") option.
-
- * Hunk headers produced for C# files by "git diff" and friends show more
-   relevant context than before.
-
- * diff.ignoresubmodules configuration variable can be used to squelch the
-   differences in submodules reported when running commands (e.g. "diff",
-   "status", etc.) at the superproject level.
-
- * http.useragent configuration can be used to lie who you are to your
-   restrictive firewall.
-
- * "git rebase --strategy <s>" learned "-X" option to pass extra options
-   that are understood by the chosen merge strategy.
-
- * "git rebase -i" learned "exec" that you can insert into the insn sheet
-   to run a command between its steps.
-
- * "git rebase" between branches that have many binary changes that do
-   not conflict should be faster.
-
- * "git rebase -i" peeks into rebase.autosquash configuration and acts as
-   if you gave --autosquash from the command line.
-
-
-Also contains various documentation updates.
-
-
-Fixes since v1.7.2
-------------------
-
-All of the fixes in v1.7.2.X maintenance series are included in this
-release, unless otherwise noted.
-
- * "git merge -s recursive" (which is the default) did not handle cases
-   where a directory becomes a file (or vice versa) very well.
-
- * "git fetch" and friends were accidentally broken for url with "+" in
-   its path, e.g. "git://git.gnome.org/gtk+".
-
----
-exec >/var/tmp/1
-echo O=$(git describe master)
-O=v1.7.2.2-268-g7e42332
-O=v1.7.2
-git shortlog --no-merges $O..master ^maint
-exit 0
-
-What did we want to do with...
-
-1e3d411 (Enable custom schemes for column colors in the graph API, 2010-07-13)

Documentation/RelNotes/1.7.0.8.txt

@@ -0,0 +1,10 @@
+Git v1.7.0.8 Release Notes
+==========================
+
+This is primarily to backport support for the new "add.ignoreErrors"
+name given to the existing "add.ignore-errors" configuration variable.
+
+The next version, Git 1.7.4, and future versions, will support both
+old and incorrect name and the new corrected name, but without this
+backport, users who want to use the new name "add.ignoreErrors" in
+their repositories cannot use older versions of Git.

Documentation/SubmittingPatches

@@ -7,16 +7,17 @@ Checklist (and a short version for the impatient):
 	  before committing
 	- do not check in commented out code or unneeded files
 	- the first line of the commit message should be a short
-	  description (50 characters is the soft limit, see DISCUSSION
-	  in git-commit(1)), and should skip the full stop
+	  description and should skip the full stop
 	- the body should provide a meaningful commit message, which:
 		- uses the imperative, present tense: "change",
 		  not "changed" or "changes".
 		- includes motivation for the change, and contrasts
 		  its implementation with previous behaviour
-	- add a "Signed-off-by: Your Name <you@example.com>" line to the
-	  commit message (or just use the option "-s" when committing)
-	  to confirm that you agree to the Developer's Certificate of Origin
+	- if you want your work included in git.git, add a
+	  "Signed-off-by: Your Name <you@example.com>" line to the
+	  commit message (or just use the option "-s" when
+	  committing) to confirm that you agree to the Developer's
+	  Certificate of Origin
 	- make sure that you have tests for the bug you are fixing
 	- make sure that the test suite passes after your commit
 
@@ -40,7 +41,6 @@ Checklist (and a short version for the impatient):
 	  maintainer (gitster@pobox.com) if (and only if) the patch
 	  is ready for inclusion. If you use git-send-email(1),
 	  please test it first by sending email to yourself.
-	- see below for instructions specific to your mailer
 
 Long version:
 
@@ -53,34 +53,6 @@ But the patch submission requirements are a lot more relaxed
 here on the technical/contents front, because the core GIT is
 thousand times smaller ;-).  So here is only the relevant bits.
 
-(0) Decide what to base your work on.
-
-In general, always base your work on the oldest branch that your
-change is relevant to.
-
- - A bugfix should be based on 'maint' in general. If the bug is not
-   present in 'maint', base it on 'master'. For a bug that's not yet
-   in 'master', find the topic that introduces the regression, and
-   base your work on the tip of the topic.
-
- - A new feature should be based on 'master' in general. If the new
-   feature depends on a topic that is in 'pu', but not in 'master',
-   base your work on the tip of that topic.
-
- - Corrections and enhancements to a topic not yet in 'master' should
-   be based on the tip of that topic. If the topic has not been merged
-   to 'next', it's alright to add a note to squash minor corrections
-   into the series.
-
- - In the exceptional case that a new feature depends on several topics
-   not in 'master', start working on 'next' or 'pu' privately and send
-   out patches for discussion. Before the final merge, you may have to
-   wait until some of the dependent topics graduate to 'master', and
-   rebase your work.
-
-To find the tip of a topic branch, run "git log --first-parent
-master..pu" and look for the merge commit. The second parent of this
-commit is the tip of the topic branch.
 
 (1) Make separate commits for logically separate changes.
 
@@ -198,16 +170,17 @@ patch, format it as "multipart/signed", not a text/plain message
 that starts with '-----BEGIN PGP SIGNED MESSAGE-----'.  That is
 not a text/plain, it's something else.
 
-Unless your patch is a very trivial and an obviously correct one,
-first send it with "To:" set to the mailing list, with "cc:" listing
-people who are involved in the area you are touching (the output from
-"git blame $path" and "git shortlog --no-merges $path" would help to
-identify them), to solicit comments and reviews.  After the list
-reached a consensus that it is a good idea to apply the patch, re-send
-it with "To:" set to the maintainer and optionally "cc:" the list for
-inclusion.  Do not forget to add trailers such as "Acked-by:",
-"Reviewed-by:" and "Tested-by:" after your "Signed-off-by:" line as
-necessary.
+Note that your maintainer does not necessarily read everything
+on the git mailing list.  If your patch is for discussion first,
+send it "To:" the mailing list, and optionally "cc:" him.  If it
+is trivially correct or after the list reached a consensus, send
+it "To:" the maintainer and optionally "cc:" the list for
+inclusion.
+
+Also note that your maintainer does not actively involve himself in
+maintaining what are in contrib/ hierarchy.  When you send fixes and
+enhancements to them, do not forget to "cc: " the person who primarily
+worked on that hierarchy in contrib/.
 
 
 (4) Sign your work
@@ -546,28 +519,12 @@ Gmail
 
 GMail does not appear to have any way to turn off line wrapping in the web
 interface, so this will mangle any emails that you send.  You can however
-use "git send-email" and send your patches through the GMail SMTP server, or
-use any IMAP email client to connect to the google IMAP server and forward
-the emails through that.
+use any IMAP email client to connect to the google imap server, and forward
+the emails through that.  Just make sure to disable line wrapping in that
+email client.  Alternatively, use "git send-email" instead.
 
-To use "git send-email" and send your patches through the GMail SMTP server,
-edit ~/.gitconfig to specify your account settings:
-
-[sendemail]
-	smtpencryption = tls
-	smtpserver = smtp.gmail.com
-	smtpuser = user@gmail.com
-	smtppass = p4ssw0rd
-	smtpserverport = 587
-
-Once your commits are ready to be sent to the mailing list, run the
-following commands:
-
-  $ git format-patch --cover-letter -M origin/master -o outgoing/
-  $ edit outgoing/0000-*
-  $ git send-email outgoing/*
-
-To submit using the IMAP interface, first, edit your ~/.gitconfig to specify your
+Submitting properly formatted patches via Gmail is simple now that
+IMAP support is available. First, edit your ~/.gitconfig to specify your
 account settings:
 
 [imap]
@@ -581,12 +538,14 @@ account settings:
 You might need to instead use: folder = "[Google Mail]/Drafts" if you get an error
 that the "Folder doesn't exist".
 
-Once your commits are ready to be sent to the mailing list, run the
-following commands:
+Next, ensure that your Gmail settings are correct. In "Settings" the
+"Use Unicode (UTF-8) encoding for outgoing messages" should be checked.
 
-  $ git format-patch --cover-letter -M --stdout origin/master | git imap-send
+Once your commits are ready to send to the mailing list, run the following
+command to send the patch emails to your Gmail Drafts folder.
 
-Just make sure to disable line wrapping in the email client (GMail web
-interface will line wrap no matter what, so you need to use a real
-IMAP client).
+	$ git format-patch -M --stdout origin/master | git imap-send
+
+Go to your Gmail account, open the Drafts folder, find the patch email, fill
+in the To: and CC: fields and send away!
 

Documentation/asciidoc.conf

@@ -16,11 +16,8 @@ plus=+
 caret=^
 startsb=[
 endsb=]
-backslash=\
 tilde=~
-apostrophe='
 backtick=`
-litdd=--
 
 ifdef::backend-docbook[]
 [linkgit-inlinemacro]

Documentation/blame-options.txt

@@ -90,9 +90,9 @@ of lines before or after the line given by <start>.
 	running extra passes of inspection.
 +
 <num> is optional but it is the lower bound on the number of
-alphanumeric characters that git must detect as moving/copying
+alphanumeric characters that git must detect as moving
 within a file for it to associate those lines with the parent
-commit. The default value is 20.
+commit.
 
 -C|<num>|::
 	In addition to `-M`, detect lines moved or copied from other
@@ -105,11 +105,9 @@ commit. The default value is 20.
 	looks for copies from other files in any commit.
 +
 <num> is optional but it is the lower bound on the number of
-alphanumeric characters that git must detect as moving/copying
+alphanumeric characters that git must detect as moving
 between files for it to associate those lines with the parent
-commit. And the default value is 40. If there are more than one
-`-C` options given, the <num> argument of the last `-C` will
-take effect.
+commit.
 
 -h::
 --help::

Documentation/config.txt

@@ -128,7 +128,7 @@ advice.*::
 		when writing commit messages. Default: true.
 	commitBeforeMerge::
 		Advice shown when linkgit:git-merge[1] refuses to
-		merge to avoid overwriting local changes.
+		merge to avoid overwritting local changes.
 		Default: true.
 	resolveConflict::
 		Advices shown by various commands when conflicts
@@ -196,17 +196,20 @@ core.quotepath::
 	quoted without `-z` regardless of the setting of this
 	variable.
 
-core.eol::
-	Sets the line ending type to use in the working directory for
-	files that have the `text` property set.  Alternatives are
-	'lf', 'crlf' and 'native', which uses the platform's native
-	line ending.  The default value is `native`.  See
-	linkgit:gitattributes[5] for more information on end-of-line
-	conversion.
+core.autocrlf::
+	If true, makes git convert `CRLF` at the end of lines in text files to
+	`LF` when reading from the work tree, and convert in reverse when
+	writing to the work tree.  The variable can be set to
+	'input', in which case the conversion happens only while
+	reading from the work tree but files are written out to the work
+	tree with `LF` at the end of lines.  A file is considered
+	"text" (i.e. be subjected to the autocrlf mechanism) based on
+	the file's `crlf` attribute, or if `crlf` is unspecified,
+	based on the file's contents.  See linkgit:gitattributes[5].
 
 core.safecrlf::
-	If true, makes git check if converting `CRLF` is reversible when
-	end-of-line conversion is active.  Git will verify if a command
+	If true, makes git check if converting `CRLF` as controlled by
+	`core.autocrlf` is reversible.  Git will verify if a command
 	modifies a file in the work tree either directly or indirectly.
 	For example, committing a file followed by checking out the
 	same file should yield the original file in the work tree.  If
@@ -216,7 +219,7 @@ core.safecrlf::
 	irreversible conversion but continue the operation.
 +
 CRLF conversion bears a slight chance of corrupting data.
-When it is enabled, git will convert CRLF to LF during commit and LF to
+autocrlf=true will convert CRLF to LF during commit and LF to
 CRLF during checkout.  A file that contains a mixture of LF and
 CRLF before the commit cannot be recreated by git.  For text
 files this is the right thing to do: it corrects line endings
@@ -240,25 +243,15 @@ converting CRLFs corrupts data.
 +
 Note, this safety check does not mean that a checkout will generate a
 file identical to the original file for a different setting of
-`core.eol` and `core.autocrlf`, but only for the current one.  For
-example, a text file with `LF` would be accepted with `core.eol=lf`
-and could later be checked out with `core.eol=crlf`, in which case the
+`core.autocrlf`, but only for the current one.  For example, a text
+file with `LF` would be accepted with `core.autocrlf=input` and could
+later be checked out with `core.autocrlf=true`, in which case the
 resulting file would contain `CRLF`, although the original file
 contained `LF`.  However, in both work trees the line endings would be
 consistent, that is either all `LF` or all `CRLF`, but never mixed.  A
 file with mixed line endings would be reported by the `core.safecrlf`
 mechanism.
 
-core.autocrlf::
-	Setting this variable to "true" is almost the same as setting
-	the `text` attribute to "auto" on all files except that text
-	files are not guaranteed to be normalized: files that contain
-	`CRLF` in the repository will not be touched.  Use this
-	setting if you want to have `CRLF` line endings in your
-	working directory even though the repository does not have
-	normalized line endings.  This variable can be set to 'input',
-	in which case no output conversion is performed.
-
 core.symlinks::
 	If false, symbolic links are checked out as small plain files that
 	contain the link text. linkgit:git-update-index[1] and
@@ -418,7 +411,7 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.
 
 core.deltaBaseCacheLimit::
 	Maximum number of bytes to reserve for caching base objects
-	that may be referenced by multiple deltified objects.  By storing the
+	that multiple deltafied objects reference.  By storing the
 	entire decompressed base objects in a cache Git is able
 	to avoid unpacking and decompressing frequently used base
 	objects multiple times.
@@ -488,8 +481,6 @@ core.whitespace::
   error (enabled by default).
 * `indent-with-non-tab` treats a line that is indented with 8 or more
   space characters as an error (not enabled by default).
-* `tab-in-indent` treats a tab character in the initial indent part of
-  the line as an error (not enabled by default).
 * `blank-at-eof` treats blank lines added at the end of file as an error
   (enabled by default).
 * `trailing-space` is a short-hand to cover both `blank-at-eol` and
@@ -527,21 +518,29 @@ check that makes sure that existing object files will not get overwritten.
 
 core.notesRef::
 	When showing commit messages, also show notes which are stored in
-	the given ref.  The ref must be fully qualified.  If the given
-	ref does not exist, it is not an error but means that no
-	notes should be printed.
+	the given ref.  This ref is expected to contain files named
+	after the full SHA-1 of the commit they annotate.
 +
-This setting defaults to "refs/notes/commits", and it can be overridden by
-the 'GIT_NOTES_REF' environment variable.  See linkgit:git-notes[1].
+If such a file exists in the given ref, the referenced blob is read, and
+appended to the commit message, separated by a "Notes:" line.  If the
+given ref itself does not exist, it is not an error, but means that no
+notes should be printed.
++
+This setting defaults to "refs/notes/commits", and can be overridden by
+the `GIT_NOTES_REF` environment variable.
 
 core.sparseCheckout::
 	Enable "sparse checkout" feature. See section "Sparse checkout" in
 	linkgit:git-read-tree[1] for more information.
 
 add.ignore-errors::
+add.ignoreErrors::
 	Tells 'git add' to continue adding files when some files cannot be
 	added due to indexing errors. Equivalent to the '--ignore-errors'
-	option of linkgit:git-add[1].
+	option of linkgit:git-add[1].  Older versions of git accept only
+	`add.ignore-errors`, which does not follow the usual naming
+	convention for configuration variables.  Newer versions of git
+	honor `add.ignoreErrors` as well.
 
 alias.*::
 	Command aliases for the linkgit:git[1] command wrapper - e.g.
@@ -560,13 +559,6 @@ it will be treated as a shell command.  For example, defining
 executed from the top-level directory of a repository, which may
 not necessarily be the current directory.
 
-am.keepcr::
-	If true, git-am will call git-mailsplit for patches in mbox format
-	with parameter '--keep-cr'. In this case git-mailsplit will
-	not remove `\r` from lines ending with `\r\n`. Can be overridden
-	by giving '--no-keep-cr' from the command line.
-	See linkgit:git-am[1], linkgit:git-mailsplit[1].
-
 apply.ignorewhitespace::
 	When set to 'change', tells 'git apply' to ignore changes in
 	whitespace, in the same way as the '--ignore-space-change'
@@ -690,39 +682,14 @@ color.diff.<slot>::
 	(highlighting whitespace errors). The values of these variables may be
 	specified as in color.branch.<slot>.
 
-color.decorate.<slot>::
-	Use customized color for 'git log --decorate' output.  `<slot>` is one
-	of `branch`, `remoteBranch`, `tag`, `stash` or `HEAD` for local
-	branches, remote tracking branches, tags, stash and HEAD, respectively.
-
 color.grep::
 	When set to `always`, always highlight matches.  When `false` (or
 	`never`), never.  When set to `true` or `auto`, use color only
 	when the output is written to the terminal.  Defaults to `false`.
 
-color.grep.<slot>::
-	Use customized color for grep colorization.  `<slot>` specifies which
-	part of the line to use the specified color, and is one of
-+
---
-`context`;;
-	non-matching text in context lines (when using `-A`, `-B`, or `-C`)
-`filename`;;
-	filename prefix (when not using `-h`)
-`function`;;
-	function name lines (when using `-p`)
-`linenumber`;;
-	line number prefix (when using `-n`)
-`match`;;
-	matching text
-`selected`;;
-	non-matching text in selected lines
-`separator`;;
-	separators between fields on a line (`:`, `-`, and `=`)
-	and between hunks (`--`)
---
-+
-The values of these variables may be specified as in color.branch.<slot>.
+color.grep.match::
+	Use customized color for matches.  The value of this variable
+	may be specified as in color.branch.<slot>.
 
 color.interactive::
 	When set to `always`, always use colors for interactive prompts
@@ -804,8 +771,6 @@ diff.mnemonicprefix::
 	standard "a/" and "b/" depending on what is being compared.  When
 	this configuration is in effect, reverse diff output also swaps
 	the order of the prefixes:
-diff.noprefix::
-	If set, 'git diff' does not show any source or destination prefix.
 `git diff`;;
 	compares the (i)ndex and the (w)ork tree;
 `git diff HEAD`;;
@@ -826,12 +791,6 @@ diff.renames::
 	will enable basic rename detection.  If set to "copies" or
 	"copy", it will detect copies, as well.
 
-diff.ignoreSubmodules::
-	Sets the default value of --ignore-submodules. Note that this
-	affects only 'git diff' Porcelain, and not lower level 'diff'
-	commands such as 'git diff-files'. 'git checkout' also honors
-	this setting when reporting uncommitted changes.
-
 diff.suppressBlankEmpty::
 	A boolean to inhibit the standard behavior of printing a space
 	before each empty output line. Defaults to false.
@@ -892,22 +851,14 @@ format.headers::
 	Additional email headers to include in a patch to be submitted
 	by mail.  See linkgit:git-format-patch[1].
 
-format.to::
 format.cc::
-	Additional recipients to include in a patch to be submitted
-	by mail.  See the --to and --cc options in
-	linkgit:git-format-patch[1].
+	Additional "Cc:" headers to include in a patch to be submitted
+	by mail.  See the --cc option in linkgit:git-format-patch[1].
 
 format.subjectprefix::
 	The default for format-patch is to output files with the '[PATCH]'
 	subject prefix. Use this variable to change that prefix.
 
-format.signature::
-	The default for format-patch is to output a signature containing
-	the git version number. Use this variable to change that default.
-	Set this variable to the empty string ("") to suppress
-	signature generation.
-
 format.suffix::
 	The default for format-patch is to output files with the suffix
 	`.patch`. Use this variable to change that suffix (make sure to
@@ -968,19 +919,13 @@ gc.pruneexpire::
 	unreachable objects immediately.
 
 gc.reflogexpire::
-gc.<pattern>.reflogexpire::
 	'git reflog expire' removes reflog entries older than
-	this time; defaults to 90 days.  With "<pattern>" (e.g.
-	"refs/stash") in the middle the setting applies only to
-	the refs that match the <pattern>.
+	this time; defaults to 90 days.
 
 gc.reflogexpireunreachable::
-gc.<ref>.reflogexpireunreachable::
 	'git reflog expire' removes reflog entries older than
 	this time and are not reachable from the current tip;
-	defaults to 30 days.  With "<pattern>" (e.g. "refs/stash")
-	in the middle, the setting applies only to the refs that
-	match the <pattern>.
+	defaults to 30 days.
 
 gc.rerereresolved::
 	Records of conflicted merge you resolved earlier are
@@ -1005,15 +950,13 @@ gitcvs.logfile::
 	various stuff. See linkgit:git-cvsserver[1].
 
 gitcvs.usecrlfattr::
-	If true, the server will look up the end-of-line conversion
-	attributes for files to determine the '-k' modes to use. If
-	the attributes force git to treat a file as text,
-	the '-k' mode will be left blank so CVS clients will
-	treat it as text. If they suppress text conversion, the file
+	If true, the server will look up the `crlf` attribute for
+	files to determine the '-k' modes to use. If `crlf` is set,
+	the '-k' mode will be left blank, so cvs clients will
+	treat it as text. If `crlf` is explicitly unset, the file
 	will be set with '-kb' mode, which suppresses any newline munging
-	the client might otherwise do. If the attributes do not allow
-	the file type to be determined, then 'gitcvs.allbinary' is
-	used. See linkgit:gitattributes[5].
+	the client might otherwise do. If `crlf` is not specified,
+	then 'gitcvs.allbinary' is used. See linkgit:gitattributes[5].
 
 gitcvs.allbinary::
 	This is used if 'gitcvs.usecrlfattr' does not resolve
@@ -1249,15 +1192,6 @@ http.noEPSV::
 	support EPSV mode. Can be overridden by the 'GIT_CURL_FTP_NO_EPSV'
 	environment variable. Default is false (curl will use EPSV).
 
-http.useragent::
-	The HTTP USER_AGENT string presented to an HTTP server.  The default
-	value represents the version of the client git such as git/1.7.1.
-	This option allows you to override this value to a more common value
-	such as Mozilla/4.0.  This may be necessary, for instance, if
-	connecting through a firewall that restricts HTTP connections to a set
-	of common USER_AGENT strings (but not including those like git/1.7.1).
-	Can be overridden by the 'GIT_HTTP_USER_AGENT' environment variable.
-
 i18n.commitEncoding::
 	Character encoding the commit messages are stored in; git itself
 	does not care per se, but this information is necessary e.g. when
@@ -1273,10 +1207,6 @@ imap::
 	The configuration variables in the 'imap' section are described
 	in linkgit:git-imap-send[1].
 
-init.templatedir::
-	Specify the directory from which templates will be copied.
-	(See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
-
 instaweb.browser::
 	Specify the program that will be used to browse your working
 	repository in gitweb. See linkgit:git-instaweb[1].
@@ -1290,9 +1220,7 @@ instaweb.local::
 	be bound to the local IP (127.0.0.1).
 
 instaweb.modulepath::
-	The default module path for linkgit:git-instaweb[1] to use
-	instead of /usr/lib/apache2/modules.  Only used if httpd
-	is Apache.
+	The module path for an apache httpd used by linkgit:git-instaweb[1].
 
 instaweb.port::
 	The port number to bind the gitweb httpd to. See
@@ -1306,18 +1234,10 @@ interactive.singlekey::
 	ignored if portable keystroke input is not available.
 
 log.date::
-	Set the default date-time mode for the 'log' command.
-	Setting a value for log.date is similar to using 'git log''s
-	`\--date` option.  Possible values are `relative`, `local`,
-	`default`, `iso`, `rfc`, and `short`; see linkgit:git-log[1]
-	for details.
-
-log.decorate::
-	Print out the ref names of any commits that are shown by the log
-	command. If 'short' is specified, the ref name prefixes 'refs/heads/',
-	'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is
-	specified, the full ref name (including prefix) will be printed.
-	This is the same as the log commands '--decorate' option.
+	Set default date-time mode for the log command. Setting log.date
+	value is similar to using 'git log'\'s --date option. The value is one of the
+	following alternatives: {relative,local,default,iso,rfc,short}.
+	See linkgit:git-log[1].
 
 log.showroot::
 	If true, the initial commit will be shown as a big creation event.
@@ -1387,53 +1307,6 @@ mergetool.keepTemporaries::
 mergetool.prompt::
 	Prompt before each invocation of the merge resolution program.
 
-notes.displayRef::
-	The (fully qualified) refname from which to show notes when
-	showing commit messages.  The value of this variable can be set
-	to a glob, in which case notes from all matching refs will be
-	shown.  You may also specify this configuration variable
-	several times.  A warning will be issued for refs that do not
-	exist, but a glob that does not match any refs is silently
-	ignored.
-+
-This setting can be overridden with the `GIT_NOTES_DISPLAY_REF`
-environment variable, which must be a colon separated list of refs or
-globs.
-+
-The effective value of "core.notesRef" (possibly overridden by
-GIT_NOTES_REF) is also implicitly added to the list of refs to be
-displayed.
-
-notes.rewrite.<command>::
-	When rewriting commits with <command> (currently `amend` or
-	`rebase`) and this variable is set to `true`, git
-	automatically copies your notes from the original to the
-	rewritten commit.  Defaults to `true`, but see
-	"notes.rewriteRef" below.
-
-notes.rewriteMode::
-	When copying notes during a rewrite (see the
-	"notes.rewrite.<command>" option), determines what to do if
-	the target commit already has a note.  Must be one of
-	`overwrite`, `concatenate`, or `ignore`.  Defaults to
-	`concatenate`.
-+
-This setting can be overridden with the `GIT_NOTES_REWRITE_MODE`
-environment variable.
-
-notes.rewriteRef::
-	When copying notes during a rewrite, specifies the (fully
-	qualified) ref whose notes should be copied.  The ref may be a
-	glob, in which case notes in all matching refs will be copied.
-	You may also specify this configuration several times.
-+
-Does not have a default value; you must configure this variable to
-enable note rewriting.
-+
-This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
-environment variable, which must be a colon separated list of refs or
-globs.
-
 pack.window::
 	The size of the window used by linkgit:git-pack-objects[1] when no
 	window size is given on the command line. Defaults to 10.
@@ -1517,16 +1390,6 @@ pager.<cmd>::
 	it takes precedence over this option.  To disable pagination for
 	all commands, set `core.pager` or `GIT_PAGER` to `cat`.
 
-pretty.<name>::
-	Alias for a --pretty= format string, as specified in
-	linkgit:git-log[1]. Any aliases defined here can be used just
-	as the built-in pretty formats could. For example,
-	running `git config pretty.changelog "format:{asterisk} %H %s"`
-	would cause the invocation `git log --pretty=changelog`
-	to be equivalent to running `git log "--pretty=format:{asterisk} %H %s"`.
-	Note that an alias with the same name as a built-in format
-	will be silently ignored.
-
 pull.octopus::
 	The default merge strategy to use when pulling multiple branches
 	at once.
@@ -1551,9 +1414,6 @@ rebase.stat::
 	Whether to show a diffstat of what changed upstream since the last
 	rebase. False by default.
 
-rebase.autosquash::
-	If set to true enable '--autosquash' option by default.
-
 receive.autogc::
 	By default, git-receive-pack will run "git-gc --auto" after
 	receiving data from git-push and updating refs.  You can stop
@@ -1579,12 +1439,8 @@ receive.denyDeletes::
 	If set to true, git-receive-pack will deny a ref update that deletes
 	the ref. Use this to prevent such a ref deletion via a push.
 
-receive.denyDeleteCurrent::
-	If set to true, git-receive-pack will deny a ref update that
-	deletes the currently checked out branch of a non-bare repository.
-
 receive.denyCurrentBranch::
-	If set to true or "refuse", git-receive-pack will deny a ref update
+	If set to true or "refuse", receive-pack will deny a ref update
 	to the currently checked out branch of a non-bare repository.
 	Such a push is potentially dangerous because it brings the HEAD
 	out of sync with the index and working tree. If set to "warn",
@@ -1646,11 +1502,7 @@ remote.<name>.uploadpack::
 
 remote.<name>.tagopt::
 	Setting this value to \--no-tags disables automatic tag following when
-	fetching from remote <name>. Setting it to \--tags will fetch every
-	tag from remote <name>, even if they are not reachable from remote
-	branch heads. Passing these flags directly to linkgit:git-fetch[1] can
-	override this setting. See options \--tags and \--no-tags of
-	linkgit:git-fetch[1].
+	fetching from remote <name>
 
 remote.<name>.vcs::
 	Setting this to a value <vcs> will cause git to interact with
@@ -1714,7 +1566,6 @@ sendemail.smtppass::
 sendemail.suppresscc::
 sendemail.suppressfrom::
 sendemail.to::
-sendemail.smtpdomain::
 sendemail.smtpserver::
 sendemail.smtpserverport::
 sendemail.smtpuser::
@@ -1761,28 +1612,6 @@ status.submodulesummary::
 	summary of commits for modified submodules will be shown (see
 	--summary-limit option of linkgit:git-submodule[1]).
 
-submodule.<name>.path::
-submodule.<name>.url::
-submodule.<name>.update::
-	The path within this project, URL, and the updating strategy
-	for a submodule.  These variables are initially populated
-	by 'git submodule init'; edit them to override the
-	URL and other values found in the `.gitmodules` file.  See
-	linkgit:git-submodule[1] and linkgit:gitmodules[5] for details.
-
-submodule.<name>.ignore::
-	Defines under what circumstances "git status" and the diff family show
-	a submodule as modified. When set to "all", it will never be considered
-	modified, "dirty" will ignore all changes to the submodules work tree and
-	takes only differences between the HEAD of the submodule and the commit
-	recorded in the superproject into account. "untracked" will additionally
-	let submodules with modified tracked files in their work tree show up.
-	Using "none" (the default when this option is not set) also shows
-	submodules that have untracked files in their work tree as changed.
-	This setting overrides any setting made in .gitmodules for this submodule,
-	both settings can be overridden on the command line by using the
-	"--ignore-submodules" option.
-
 tar.umask::
 	This variable can be used to restrict the permission bits of
 	tar archive entries.  The default is 0002, which turns off the

Documentation/diff-generate-patch.txt

@@ -56,8 +56,7 @@ combined diff format
 
 "git-diff-tree", "git-diff-files" and "git-diff" can take '-c' or
 '--cc' option to produce 'combined diff'.  For showing a merge commit
-with "git log -p", this is the default format; you can force showing
-full diff with the '-m' option.
+with "git log -p", this is the default format.
 A 'combined diff' format looks like this:
 
 ------------

Documentation/diff-options.txt

@@ -21,7 +21,6 @@ endif::git-format-patch[]
 ifndef::git-format-patch[]
 -p::
 -u::
---patch::
 	Generate patch (see section on generating patches).
 	{git-diff? This is the default.}
 endif::git-format-patch[]
@@ -118,48 +117,18 @@ any of those replacements occurred.
 	option and lists the commits in that commit range like the 'summary'
 	option of linkgit:git-submodule[1] does.
 
---color[=<when>]::
+--color::
 	Show colored diff.
-	The value must be always (the default), never, or auto.
 
 --no-color::
 	Turn off colored diff, even when the configuration file
 	gives the default to color output.
-	Same as `--color=never`.
 
---word-diff[=<mode>]::
-	Show a word diff, using the <mode> to delimit changed words.
-	By default, words are delimited by whitespace; see
-	`--word-diff-regex` below.  The <mode> defaults to 'plain', and
-	must be one of:
+--color-words[=<regex>]::
+	Show colored word diff, i.e., color words which have changed.
+	By default, words are separated by whitespace.
 +
---
-color::
-	Highlight changed words using only colors.  Implies `--color`.
-plain::
-	Show words as `[-removed-]` and `{+added+}`.  Makes no
-	attempts to escape the delimiters if they appear in the input,
-	so the output may be ambiguous.
-porcelain::
-	Use a special line-based format intended for script
-	consumption.  Added/removed/unchanged runs are printed in the
-	usual unified diff format, starting with a `+`/`-`/` `
-	character at the beginning of the line and extending to the
-	end of the line.  Newlines in the input are represented by a
-	tilde `~` on a line of its own.
-none::
-	Disable word diff again.
---
-+
-Note that despite the name of the first mode, color is used to
-highlight the changed parts in all modes if enabled.
-
---word-diff-regex=<regex>::
-	Use <regex> to decide what a word is, instead of considering
-	runs of non-whitespace to be a word.  Also implies
-	`--word-diff` unless it was already enabled.
-+
-Every non-overlapping match of the
+When a <regex> is specified, every non-overlapping match of the
 <regex> is considered a word.  Anything between these matches is
 considered whitespace and ignored(!) for the purposes of finding
 differences.  You may want to append `|[^[:space:]]` to your regular
@@ -171,10 +140,6 @@ The regex can also be set via a diff driver or configuration option, see
 linkgit:gitattributes[1] or linkgit:git-config[1].  Giving it explicitly
 overrides any diff driver or configuration setting.  Diff drivers
 override configuration settings.
-
---color-words[=<regex>]::
-	Equivalent to `--word-diff=color` plus (if a regex was
-	specified) `--word-diff-regex=<regex>`.
 endif::git-format-patch[]
 
 --no-renames::
@@ -206,46 +171,14 @@ endif::git-format-patch[]
 	the diff-patch output format.  Non default number of
 	digits can be specified with `--abbrev=<n>`.
 
--B[<n>][/<m>]::
-	Break complete rewrite changes into pairs of delete and
-	create. This serves two purposes:
-+
-It affects the way a change that amounts to a total rewrite of a file
-not as a series of deletion and insertion mixed together with a very
-few lines that happen to match textually as the context, but as a
-single deletion of everything old followed by a single insertion of
-everything new, and the number `m` controls this aspect of the -B
-option (defaults to 60%). `-B/70%` specifies that less than 30% of the
-original should remain in the result for git to consider it a total
-rewrite (i.e. otherwise the resulting patch will be a series of
-deletion and insertion mixed together with context lines).
-+
-When used with -M, a totally-rewritten file is also considered as the
-source of a rename (usually -M only considers a file that disappeared
-as the source of a rename), and the number `n` controls this aspect of
-the -B option (defaults to 50%). `-B20%` specifies that a change with
-addition and deletion compared to 20% or more of the file's size are
-eligible for being picked up as a possible source of a rename to
-another file.
+-B::
+	Break complete rewrite changes into pairs of delete and create.
 
--M[<n>]::
-ifndef::git-log[]
+-M::
 	Detect renames.
-endif::git-log[]
-ifdef::git-log[]
-	If generating diffs, detect and report renames for each commit.
-	For following files across renames while traversing history, see
-	`--follow`.
-endif::git-log[]
-	If `n` is specified, it is a is a threshold on the similarity
-	index (i.e. amount of addition/deletions compared to the
-	file's size). For example, `-M90%` means git should consider a
-	delete/add pair to be a rename if more than 90% of the file
-	hasn't changed.
 
--C[<n>]::
+-C::
 	Detect copies as well as renames.  See also `--find-copies-harder`.
-	If `n` is specified, it has the same meaning as for `-M<n>`.
 
 ifndef::git-format-patch[]
 --diff-filter=[ACDMRTUXB*]::
@@ -353,18 +286,8 @@ endif::git-format-patch[]
 --no-ext-diff::
 	Disallow external diff drivers.
 
---ignore-submodules[=<when>]::
-	Ignore changes to submodules in the diff generation. <when> can be
-	either "none", "untracked", "dirty" or "all", which is the default
-	Using "none" will consider the submodule modified when it either contains
-	untracked or modified files or its HEAD differs from the commit recorded
-	in the superproject and can be used to override any settings of the
-	'ignore' option in linkgit:git-config[1] or linkgit:gitmodules[5]. When
-	"untracked" is used submodules are not considered dirty when they only
-	contain untracked content (but they are still scanned for modified
-	content). Using "dirty" ignores all changes to the work tree of submodules,
-	only changes to the commits stored in the superproject are shown (this was
-	the behavior until 1.7.0). Using "all" hides all changes to submodules.
+--ignore-submodules::
+	Ignore changes to submodules in the diff generation.
 
 --src-prefix=<prefix>::
 	Show the given source prefix instead of "a/".

Documentation/docbook.xsl

@@ -1,8 +1,5 @@
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
 		version='1.0'>
  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl"/>
- <xsl:output method="html"
-     encoding="UTF-8" indent="no"
-     doctype-public="-//W3C//DTD HTML 4.01//EN"
-     doctype-system="http://www.w3.org/TR/html4/strict.dtd" />
+ <xsl:output method="html" encoding="UTF-8" indent="no" />
 </xsl:stylesheet>

Documentation/everyday.txt

@@ -1,8 +1,13 @@
 Everyday GIT With 20 Commands Or So
 ===================================
 
-<<Individual Developer (Standalone)>> commands are essential for
-anybody who makes a commit, even for somebody who works alone.
+<<Basic Repository>> commands are needed by people who have a
+repository --- that is everybody, because every working tree of
+git is a repository.
+
+In addition, <<Individual Developer (Standalone)>> commands are
+essential for anybody who makes a commit, even for somebody who
+works alone.
 
 If you work with other people, you will need commands listed in
 the <<Individual Developer (Participant)>> section as well.
@@ -15,6 +20,46 @@ administrators who are responsible for the care and feeding
 of git repositories.
 
 
+Basic Repository[[Basic Repository]]
+------------------------------------
+
+Everybody uses these commands to maintain git repositories.
+
+  * linkgit:git-init[1] or linkgit:git-clone[1] to create a
+    new repository.
+
+  * linkgit:git-fsck[1] to check the repository for errors.
+
+  * linkgit:git-gc[1] to do common housekeeping tasks such as
+    repack and prune.
+
+Examples
+~~~~~~~~
+
+Check health and remove cruft.::
++
+------------
+$ git fsck <1>
+$ git count-objects <2>
+$ git gc <3>
+------------
++
+<1> running without `\--full` is usually cheap and assures the
+repository health reasonably well.
+<2> check how many loose objects there are and how much
+disk space is wasted by not repacking.
+<3> repacks the local repository and performs other housekeeping tasks.
+
+Repack a small project into single pack.::
++
+------------
+$ git gc <1>
+------------
++
+<1> pack all the objects reachable from the refs into one pack,
+then remove the other packs.
+
+
 Individual Developer (Standalone)[[Individual Developer (Standalone)]]
 ----------------------------------------------------------------------
 
@@ -22,8 +67,6 @@ A standalone individual developer does not exchange patches with
 other people, and works alone in a single repository, using the
 following commands.
 
-  * linkgit:git-init[1] to create a new repository.
-
   * linkgit:git-show-branch[1] to see where you are.
 
   * linkgit:git-log[1] to see what happened.

Documentation/fetch-options.txt

@@ -34,7 +34,6 @@ ifndef::git-pull[]
 	Allow several <repository> and <group> arguments to be
 	specified. No <refspec>s may be specified.
 
--p::
 --prune::
 	After fetching, remove any remote tracking branches which
 	no longer exist	on the remote.
@@ -49,9 +48,7 @@ ifndef::git-pull[]
 endif::git-pull[]
 	By default, tags that point at objects that are downloaded
 	from the remote repository are fetched and stored locally.
-	This option disables this automatic tag following. The default
-	behavior for a remote may be specified with the remote.<name>.tagopt
-	setting. See linkgit:git-config[1].
+	This option disables this automatic tag following.
 
 -t::
 --tags::
@@ -60,9 +57,7 @@ endif::git-pull[]
 	objects reachable from the branch heads that are being
 	tracked will not be fetched by this mechanism.  This
 	flag lets all tags and their associated objects be
-	downloaded. The default behavior for a remote may be
-	specified with the remote.<name>.tagopt setting. See
-	linkgit:git-config[1].
+	downloaded.
 
 -u::
 --update-head-ok::
@@ -83,16 +78,9 @@ ifndef::git-pull[]
 -q::
 --quiet::
 	Pass --quiet to git-fetch-pack and silence any other internally
-	used git commands. Progress is not reported to the standard error
-	stream.
+	used git commands.
 
 -v::
 --verbose::
 	Be verbose.
 endif::git-pull[]
-
---progress::
-	Progress status is reported on the standard error stream
-	by default when it is attached to a terminal, unless -q
-	is specified. This flag forces progress status even if the
-	standard error stream is not directed to a terminal.

Documentation/git-add.txt

@@ -10,8 +10,7 @@ SYNOPSIS
 [verse]
 'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
 	  [--edit | -e] [--all | [--update | -u]] [--intent-to-add | -N]
-	  [--refresh] [--ignore-errors] [--ignore-missing] [--]
-	  [<filepattern>...]
+	  [--refresh] [--ignore-errors] [--] [<filepattern>...]
 
 DESCRIPTION
 -----------
@@ -58,8 +57,7 @@ OPTIONS
 
 -n::
 --dry-run::
-	Don't actually add the file(s), just show if they exist and/or will
-	be ignored.
+        Don't actually add the file(s), just show if they exist.
 
 -v::
 --verbose::
@@ -133,12 +131,6 @@ subdirectories.
 	them, do not abort the operation, but continue adding the
 	others. The command shall still exit with non-zero status.
 
---ignore-missing::
-	This option can only be used together with --dry-run. By using
-	this option the user can check if any of the given files would
-	be ignored, no matter if they are already present in the work
-	tree or not.
-
 \--::
 	This option can be used to separate command-line options from
 	the list of files, (useful when filenames might be mistaken
@@ -157,14 +149,14 @@ those in info/exclude.  See linkgit:gitrepository-layout[5].
 EXAMPLES
 --------
 
-* Adds content from all `*.txt` files under `Documentation` directory
+* Adds content from all `\*.txt` files under `Documentation` directory
 and its subdirectories:
 +
 ------------
 $ git add Documentation/\*.txt
 ------------
 +
-Note that the asterisk `*` is quoted from the shell in this
+Note that the asterisk `\*` is quoted from the shell in this
 example; this lets the command include the files from
 subdirectories of `Documentation/` directory.
 
@@ -220,7 +212,7 @@ binary so line count cannot be shown) and there is no
 difference between indexed copy and the working tree
 version (if the working tree version were also different,
 'binary' would have been shown in place of 'nothing').  The
-other file, git-add{litdd}interactive.perl, has 403 lines added
+other file, git-add--interactive.perl, has 403 lines added
 and 35 lines deleted if you commit what is in the index, but
 working tree file has further modifications (one addition and
 one deletion).
@@ -274,9 +266,9 @@ patch::
 
        y - stage this hunk
        n - do not stage this hunk
-       q - quit; do not stage this hunk nor any of the remaining ones
-       a - stage this hunk and all later hunks in the file
-       d - do not stage this hunk nor any of the later hunks in the file
+       q - quit, do not stage this hunk nor any of the remaining ones
+       a - stage this and all the remaining hunks in the file
+       d - do not stage this hunk nor any of the remaining hunks in the file
        g - select a hunk to go to
        / - search for a hunk matching the given regex
        j - leave this hunk undecided, see next undecided hunk

Documentation/git-am.txt

@@ -9,7 +9,7 @@ git-am - Apply a series of patches from a mailbox
 SYNOPSIS
 --------
 [verse]
-'git am' [--signoff] [--keep] [--keep-cr | --no-keep-cr] [--utf8 | --no-utf8]
+'git am' [--signoff] [--keep] [--utf8 | --no-utf8]
 	 [--3way] [--interactive] [--committer-date-is-author-date]
 	 [--ignore-date] [--ignore-space-change | --ignore-whitespace]
 	 [--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
@@ -39,13 +39,6 @@ OPTIONS
 --keep::
 	Pass `-k` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
 
---keep-cr::
---no-keep-cr::
-	With `--keep-cr`, call 'git mailsplit' (see linkgit:git-mailsplit[1])
-	with the same option, to prevent it from stripping CR at the end of
-	lines. `am.keepcr` configuration variable can be used to specify the
-	default behaviour.  `--no-keep-cr` is useful to override `am.keepcr`.
-
 -c::
 --scissors::
 	Remove everything in body before a scissors line (see

Documentation/git-apply.txt

@@ -26,10 +26,6 @@ with the `--cache` option the patch is only applied to the index.
 Without these options, the command applies the patch only to files,
 and does not require them to be in a git repository.
 
-This command applies the patch but does not create a commit.  Use
-linkgit:git-am[1] to create commits from patches generated by
-linkgit:git-format-patch[1] and/or received by email.
-
 OPTIONS
 -------
 <patch>...::
@@ -246,12 +242,6 @@ If `--index` is not specified, then the submodule commits in the patch
 are ignored and only the absence or presence of the corresponding
 subdirectory is checked and (if possible) updated.
 
-
-SEE ALSO
---------
-linkgit:git-am[1].
-
-
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org>

Documentation/git-archimport.txt

@@ -44,7 +44,7 @@ archives that it imports, it is also possible to specify git branch names
 manually.  To do so, write a git branch name after each <archive/branch>
 parameter, separated by a colon.  This way, you can shorten the Arch
 branch names and convert Arch jargon to git jargon, for example mapping a
-"PROJECT{litdd}devo{litdd}VERSION" branch to "master".
+"PROJECT--devo--VERSION" branch to "master".
 
 Associating multiple Arch branches to one git branch is possible; the
 result will make the most sense only if no commits are made to the first
@@ -85,8 +85,8 @@ OPTIONS
 -o::
 	Use this for compatibility with old-style branch names used by
 	earlier versions of 'git archimport'.  Old-style branch names
-	were category{litdd}branch, whereas new-style branch names are
-	archive,category{litdd}branch{litdd}version.  In both cases, names given
+	were category--branch, whereas new-style branch names are
+	archive,category--branch--version.  In both cases, names given
 	on the command-line will override the automatically-generated
 	ones.
 

Documentation/git-bisect-lk2009.txt

@@ -873,7 +873,7 @@ c * N * T + b * M * log2(M) tests
 where c is the number of rounds of test (so a small constant) and b is
 the ratio of bug per commit (hopefully a small constant too).
 
-So of course it's much better as it's O(N * T) vs O(N * T * M) if
+So of course it's much better as it's O(N \* T) vs O(N \* T \* M) if
 you would test everything after each commit.
 
 This means that test suites are good to prevent some bugs from being
@@ -971,7 +971,7 @@ logical change in each commit.
 The smaller the changes in your commit, the most effective "git
 bisect" will be. And you will probably need "git bisect" less in the
 first place, as small changes are easier to review even if they are
-only reviewed by the committer.
+only reviewed by the commiter.
 
 Another good idea is to have good commit messages. They can be very
 helpful to understand why some changes were made.

Documentation/git-branch.txt

@@ -8,7 +8,7 @@ git-branch - List, create, or delete branches
 SYNOPSIS
 --------
 [verse]
-'git branch' [--color[=<when>] | --no-color] [-r | -a]
+'git branch' [--color | --no-color] [-r | -a]
 	[-v [--abbrev=<length> | --no-abbrev]]
 	[(--merged | --no-merged | --contains) [<commit>]]
 'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
@@ -88,14 +88,12 @@ OPTIONS
 -M::
 	Move/rename a branch even if the new branch name already exists.
 
---color[=<when>]::
+--color::
 	Color branches to highlight current, local, and remote branches.
-	The value must be always (the default), never, or auto.
 
 --no-color::
 	Turn off branch colors, even when the configuration file gives the
 	default to color output.
-	Same as `--color=never`.
 
 -r::
 	List or delete (if used with -d) the remote-tracking branches.

Documentation/git-bundle.txt

@@ -9,7 +9,7 @@ git-bundle - Move objects and refs by archive
 SYNOPSIS
 --------
 [verse]
-'git bundle' create <file> <git-rev-list-args>
+'git bundle' create <file> <git-rev-list args>
 'git bundle' verify <file>
 'git bundle' list-heads <file> [refname...]
 'git bundle' unbundle <file> [refname...]
@@ -34,58 +34,57 @@ OPTIONS
 -------
 
 create <file>::
-	Used to create a bundle named 'file'.  This requires the
-	'git-rev-list-args' arguments to define the bundle contents.
+       Used to create a bundle named 'file'.  This requires the
+       'git rev-list' arguments to define the bundle contents.
 
 verify <file>::
-	Used to check that a bundle file is valid and will apply
-	cleanly to the current repository.  This includes checks on the
-	bundle format itself as well as checking that the prerequisite
-	commits exist and are fully linked in the current repository.
-	'git bundle' prints a list of missing commits, if any, and exits
-	with a non-zero status.
+       Used to check that a bundle file is valid and will apply
+       cleanly to the current repository.  This includes checks on the
+       bundle format itself as well as checking that the prerequisite
+       commits exist and are fully linked in the current repository.
+       'git bundle' prints a list of missing commits, if any, and exits
+       with a non-zero status.
 
 list-heads <file>::
-	Lists the references defined in the bundle.  If followed by a
-	list of references, only references matching those given are
-	printed out.
+       Lists the references defined in the bundle.  If followed by a
+       list of references, only references matching those given are
+       printed out.
 
 unbundle <file>::
-	Passes the objects in the bundle to 'git index-pack'
-	for storage in the repository, then prints the names of all
-	defined references. If a list of references is given, only
-	references matching those in the list are printed. This command is
-	really plumbing, intended to be called only by 'git fetch'.
+       Passes the objects in the bundle to 'git index-pack'
+       for storage in the repository, then prints the names of all
+       defined references. If a list of references is given, only
+       references matching those in the list are printed. This command is
+       really plumbing, intended to be called only by 'git fetch'.
 
-<git-rev-list-args>::
-	A list of arguments, acceptable to 'git rev-parse' and
-	'git rev-list' (and containg a named ref, see SPECIFYING REFERENCES
-	below), that specifies the specific objects and references
-	to transport.  For example, `master{tilde}10..master` causes the
-	current master reference to be packaged along with all objects
-	added since its 10th ancestor commit.  There is no explicit
-	limit to the number of references and objects that may be
-	packaged.
+[git-rev-list-args...]::
+       A list of arguments, acceptable to 'git rev-parse' and
+       'git rev-list', that specifies the specific objects and references
+       to transport.  For example, `master\~10..master` causes the
+       current master reference to be packaged along with all objects
+       added since its 10th ancestor commit.  There is no explicit
+       limit to the number of references and objects that may be
+       packaged.
 
 
 [refname...]::
-	A list of references used to limit the references reported as
-	available. This is principally of use to 'git fetch', which
-	expects to receive only those references asked for and not
-	necessarily everything in the pack (in this case, 'git bundle' acts
-	like 'git fetch-pack').
+       A list of references used to limit the references reported as
+       available. This is principally of use to 'git fetch', which
+       expects to receive only those references asked for and not
+       necessarily everything in the pack (in this case, 'git bundle' acts
+       like 'git fetch-pack').
 
 SPECIFYING REFERENCES
 ---------------------
 
 'git bundle' will only package references that are shown by
 'git show-ref': this includes heads, tags, and remote heads.  References
-such as `master{tilde}1` cannot be packaged, but are perfectly suitable for
+such as `master\~1` cannot be packaged, but are perfectly suitable for
 defining the basis.  More than one reference may be packaged, and more
 than one basis can be specified.  The objects packaged are those not
 contained in the union of the given bases.  Each basis can be
-specified explicitly (e.g. `^master{tilde}10`), or implicitly (e.g.
-`master{tilde}10..master`, `--since=10.days.ago master`).
+specified explicitly (e.g. `^master\~10`), or implicitly (e.g.
+`master\~10..master`, `--since=10.days.ago master`).
 
 It is very important that the basis used be held by the destination.
 It is okay to err on the side of caution, causing the bundle file
@@ -155,7 +154,7 @@ machineB$ git pull
 If you know up to what commit the intended recipient repository should
 have the necessary objects, you can use that knowledge to specify the
 basis, giving a cut-off point to limit the revisions and objects that go
-in the resulting bundle. The previous example used the lastR2bundle tag
+in the resulting bundle. The previous example used lastR2bundle tag
 for this purpose, but you can use any other options that you would give to
 the linkgit:git-log[1] command. Here are more examples:
 
@@ -195,7 +194,7 @@ references when fetching:
 $ git fetch mybundle master:localRef
 ----------------
 
-You can also see what references it offers:
+You can also see what references it offers.
 
 ----------------
 $ git ls-remote mybundle

Documentation/git-cat-file.txt

@@ -9,15 +9,14 @@ git-cat-file - Provide content or type and size information for repository objec
 SYNOPSIS
 --------
 [verse]
-'git cat-file' (-t | -s | -e | -p | <type> | --textconv ) <object>
+'git cat-file' (-t | -s | -e | -p | <type>) <object>
 'git cat-file' (--batch | --batch-check) < <list-of-objects>
 
 DESCRIPTION
 -----------
 In its first form, the command provides the content or the type of an object in
 the repository. The type is required unless '-t' or '-p' is used to find the
-object type, or '-s' is used to find the object size, or '--textconv' is used
-(which implies type "blob").
+object type, or '-s' is used to find the object size.
 
 In the second form, a list of objects (separated by linefeeds) is provided on
 stdin, and the SHA1, type, and size of each object is printed on stdout.
@@ -27,7 +26,7 @@ OPTIONS
 <object>::
 	The name of the object to show.
 	For a more complete list of ways to spell object names, see
-	the "SPECIFYING REVISIONS" section in linkgit:gitrevisions[1].
+	the "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
 
 -t::
 	Instead of the content, show the object type identified by
@@ -52,11 +51,6 @@ OPTIONS
 	or to ask for a "blob" with <object> being a tag object that
 	points at it.
 
---textconv::
-	Show the content as transformed by a textconv filter. In this case,
-	<object> has be of the form <treeish>:<path>, or :<path> in order
-	to apply the filter to the content recorded in the index at <path>.
-
 --batch::
 	Print the SHA1, type, size, and contents of each object provided on
 	stdin. May not be combined with any other options or arguments.

Documentation/git-check-ref-format.txt

@@ -49,7 +49,7 @@ git imposes the following rules on how references are named:
 These rules make it easy for shell script based tools to parse
 reference names, pathname expansion by the shell when a reference name is used
 unquoted (by mistake), and also avoids ambiguities in certain
-reference name expressions (see linkgit:gitrevisions[1]):
+reference name expressions (see linkgit:git-rev-parse[1]):
 
 . A double-dot `..` is often used as in `ref1..ref2`, and in some
   contexts this notation means `{caret}ref1 ref2` (i.e. not in

Documentation/git-checkout-index.txt

@@ -13,7 +13,7 @@ SYNOPSIS
 		   [--stage=<number>|all]
 		   [--temp]
 		   [-z] [--stdin]
-		   [--] [<file>]*
+		   [--] [<file>]\*
 
 DESCRIPTION
 -----------

Documentation/git-checkout.txt

@@ -9,58 +9,39 @@ SYNOPSIS
 --------
 [verse]
 'git checkout' [-q] [-f] [-m] [<branch>]
-'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
+'git checkout' [-q] [-f] [-m] [-b <new_branch>] [<start_point>]
 'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
 'git checkout' --patch [<tree-ish>] [--] [<paths>...]
 
 DESCRIPTION
 -----------
-Updates files in the working tree to match the version in the index
-or the specified tree.  If no paths are given, 'git checkout' will
-also update `HEAD` to set the specified branch as the current
+
+When <paths> are not given, this command switches branches by
+updating the index, working tree, and HEAD to reflect the specified
 branch.
 
-'git checkout' [<branch>]::
-'git checkout' -b|-B <new_branch> [<start point>]::
+If `-b` is given, a new branch is created and checked out, as if
+linkgit:git-branch[1] were called; in this case you can
+use the --track or --no-track options, which will be passed to `git
+branch`.  As a convenience, --track without `-b` implies branch
+creation; see the description of --track below.
 
-	This form switches branches by updating the index, working
-	tree, and HEAD to reflect the specified branch.
-+
-If `-b` is given, a new branch is created as if linkgit:git-branch[1]
-were called and then checked out; in this case you can
-use the `--track` or `--no-track` options, which will be passed to
-'git branch'.  As a convenience, `--track` without `-b` implies branch
-creation; see the description of `--track` below.
-+
-If `-B` is given, <new_branch> is created if it doesn't exist; otherwise, it
-is reset. This is the transactional equivalent of
-+
-------------
-$ git branch -f <branch> [<start point>]
-$ git checkout <branch>
-------------
-+
-that is to say, the branch is not reset/created unless "git checkout" is
-successful.
+When <paths> or --patch are given, this command does *not* switch
+branches.  It updates the named paths in the working tree from
+the index file, or from a named <tree-ish> (most often a commit).  In
+this case, the `-b` and `--track` options are meaningless and giving
+either of them results in an error. The <tree-ish> argument can be
+used to specify a specific tree-ish (i.e. commit, tag or tree)
+to update the index for the given paths before updating the
+working tree.
 
-'git checkout' [--patch] [<tree-ish>] [--] <pathspec>...::
-
-	When <paths> or `--patch` are given, 'git checkout' *not* switch
-	branches.  It updates the named paths in the working tree from
-	the index file or from a named <tree-ish> (most often a commit).  In
-	this case, the `-b` and `--track` options are meaningless and giving
-	either of them results in an error. The <tree-ish> argument can be
-	used to specify a specific tree-ish (i.e. commit, tag or tree)
-	to update the index for the given paths before updating the
-	working tree.
-+
-The index may contain unmerged entries because of a previous failed merge.
-By default, if you try to check out such an entry from the index, the
+The index may contain unmerged entries after a failed merge.  By
+default, if you try to check out such an entry from the index, the
 checkout operation will fail and nothing will be checked out.
-Using `-f` will ignore these unmerged entries.  The contents from a
+Using -f will ignore these unmerged entries.  The contents from a
 specific side of the merge can be checked out of the index by
-using `--ours` or `--theirs`.  With `-m`, changes made to the working tree
-file can be discarded to re-create the original conflicted merge result.
+using --ours or --theirs.  With -m, changes made to the working tree
+file can be discarded to recreate the original conflicted merge result.
 
 OPTIONS
 -------
@@ -86,12 +67,6 @@ entries; instead, unmerged entries are ignored.
 	Create a new branch named <new_branch> and start it at
 	<start_point>; see linkgit:git-branch[1] for details.
 
--B::
-	Creates the branch <new_branch> and start it at <start_point>;
-	if it already exists, then reset it to <start_point>. This is
-	equivalent to running "git branch" with "-f"; see
-	linkgit:git-branch[1] for details.
-
 -t::
 --track::
 	When creating a new branch, set up "upstream" configuration. See
@@ -115,31 +90,6 @@ explicitly give a name with '-b' in such a case.
 	Create the new branch's reflog; see linkgit:git-branch[1] for
 	details.
 
---orphan::
-	Create a new 'orphan' branch, named <new_branch>, started from
-	<start_point> and switch to it.  The first commit made on this
-	new branch will have no parents and it will be the root of a new
-	history totally disconnected from all the other branches and
-	commits.
-+
-The index and the working tree are adjusted as if you had previously run
-"git checkout <start_point>".  This allows you to start a new history
-that records a set of paths similar to <start_point> by easily running
-"git commit -a" to make the root commit.
-+
-This can be useful when you want to publish the tree from a commit
-without exposing its full history. You might want to do this to publish
-an open source branch of a project whose current tree is "clean", but
-whose full history contains proprietary or otherwise encumbered bits of
-code.
-+
-If you want to start a disconnected history that records a set of paths
-that is totally different from the one of <start_point>, then you should
-clear the index and the working tree right after creating the orphan
-branch by running "git rm -rf ." from the top level of the working tree.
-Afterwards you will be ready to prepare your new files, repopulating the
-working tree, by copying them from elsewhere, extracting a tarball, etc.
-
 -m::
 --merge::
 	When switching branches,
@@ -186,10 +136,6 @@ edits from your current working tree.
 As a special case, the `"@\{-N\}"` syntax for the N-th last branch
 checks out the branch (instead of detaching).  You may also specify
 `-` which is synonymous with `"@\{-1\}"`.
-+
-As a further special case, you may use `"A\...B"` as a shortcut for the
-merge base of `A` and `B` if there is exactly one merge base. You can
-leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
 
 <new_branch>::
 	Name for the new branch.
@@ -280,7 +226,7 @@ the above checkout would fail like this:
 +
 ------------
 $ git checkout mytopic
-error: You have local changes to 'frotz'; not switching branches.
+fatal: Entry 'frotz' not uptodate. Cannot merge.
 ------------
 +
 You can give the `-m` flag to the command, which would try a

Documentation/git-cherry-pick.txt

@@ -3,28 +3,24 @@ git-cherry-pick(1)
 
 NAME
 ----
-git-cherry-pick - Apply the changes introduced by some existing commits
+git-cherry-pick - Apply the change introduced by an existing commit
 
 SYNOPSIS
 --------
-'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit>...
+'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] <commit>
 
 DESCRIPTION
 -----------
-
-Given one or more existing commits, apply the change each one
-introduces, recording a new commit for each.  This requires your
-working tree to be clean (no modifications from the HEAD commit).
+Given one existing commit, apply the change the patch introduces, and record a
+new commit that records it.  This requires your working tree to be clean (no
+modifications from the HEAD commit).
 
 OPTIONS
 -------
-<commit>...::
-	Commits to cherry-pick.
-	For a more complete list of ways to spell commits, see
-	linkgit:gitrevisions[1].
-	Sets of commits can be passed but no traversal is done by
-	default, as if the '--no-walk' option was specified, see
-	linkgit:git-rev-list[1].
+<commit>::
+	Commit to cherry-pick.
+	For a more complete list of ways to spell commits, see the
+	"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
 
 -e::
 --edit::
@@ -59,10 +55,10 @@ OPTIONS
 
 -n::
 --no-commit::
-	Usually the command automatically creates a sequence of commits.
-	This flag applies the changes necessary to cherry-pick
-	each named commit to your working tree and the index,
-	without making any commit.  In addition, when this
+	Usually the command automatically creates a commit.
+	This flag applies the change necessary to cherry-pick
+	the named commit to your working tree and the index,
+	but does not make the commit.  In addition, when this
 	option is used, your index does not have to match the
 	HEAD commit.  The cherry-pick is done against the
 	beginning state of your index.
@@ -74,51 +70,6 @@ effect to your index in a row.
 --signoff::
 	Add Signed-off-by line at the end of the commit message.
 
---ff::
-	If the current HEAD is the same as the parent of the
-	cherry-pick'ed commit, then a fast forward to this commit will
-	be performed.
-
-EXAMPLES
---------
-git cherry-pick master::
-
-	Apply the change introduced by the commit at the tip of the
-	master branch and create a new commit with this change.
-
-git cherry-pick ..master::
-git cherry-pick ^HEAD master::
-
-	Apply the changes introduced by all commits that are ancestors
-	of master but not of HEAD to produce new commits.
-
-git cherry-pick master\~4 master~2::
-
-	Apply the changes introduced by the fifth and third last
-	commits pointed to by master and create 2 new commits with
-	these changes.
-
-git cherry-pick -n master~1 next::
-
-	Apply to the working tree and the index the changes introduced
-	by the second last commit pointed to by master and by the last
-	commit pointed to by next, but do not create any commit with
-	these changes.
-
-git cherry-pick --ff ..next::
-
-	If history is linear and HEAD is an ancestor of next, update
-	the working tree and advance the HEAD pointer to match next.
-	Otherwise, apply the changes introduced by those commits that
-	are in next but not HEAD to the current branch, creating a new
-	commit for each new change.
-
-git rev-list --reverse master \-- README | git cherry-pick -n --stdin::
-
-	Apply the changes introduced by all commits on the master
-	branch that touched README to the working tree and index,
-	so the result can be inspected and made into a single new
-	commit if suitable.
 
 Author
 ------
@@ -128,10 +79,6 @@ Documentation
 --------------
 Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
 
-SEE ALSO
---------
-linkgit:git-revert[1]
-
 GIT
 ---
 Part of the linkgit:git[1] suite

Documentation/git-clean.txt

@@ -8,7 +8,7 @@ git-clean - Remove untracked files from the working tree
 SYNOPSIS
 --------
 [verse]
-'git clean' [-d] [-f] [-n] [-q] [-e <pattern>] [-x | -X] [--] <path>...
+'git clean' [-d] [-f] [-n] [-q] [-x | -X] [--] <path>...
 
 DESCRIPTION
 -----------
@@ -45,12 +45,6 @@ OPTIONS
 	Be quiet, only report errors, but not the files that are
 	successfully removed.
 
--e <pattern>::
---exclude=<pattern>::
-	Specify special exceptions to not be cleaned.  Each <pattern> is
-	the same form as in $GIT_DIR/info/excludes and this option can be
-	given multiple times.
-
 -x::
 	Don't use the ignore rules.  This allows removing all untracked
 	files, including build products.  This can be used (possibly in

Documentation/git-clone.txt

@@ -102,8 +102,7 @@ objects from the source repository into a pack in the cloned repository.
 
 --verbose::
 -v::
-	Run verbosely. Does not affect the reporting of progress status
-	to the standard error stream.
+	Run verbosely.
 
 --progress::
 	Progress status is reported on the standard error stream
@@ -150,7 +149,8 @@ objects from the source repository into a pack in the cloned repository.
 
 --template=<template_directory>::
 	Specify the directory from which templates will be used;
-	(See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
+	if unset the templates are taken from the installation
+	defined default, typically `/usr/share/git-core/templates`.
 
 --depth <depth>::
 	Create a 'shallow' clone with a history truncated to the

Documentation/git-commit-tree.txt

@@ -8,7 +8,7 @@ git-commit-tree - Create a new commit object
 
 SYNOPSIS
 --------
-'git commit-tree' <tree> [-p <parent commit>]* < changelog
+'git commit-tree' <tree> [-p <parent commit>]\* < changelog
 
 DESCRIPTION
 -----------

Documentation/git-commit.txt

@@ -10,7 +10,7 @@ SYNOPSIS
 [verse]
 'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
 	   [(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]
-	   [--allow-empty] [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
+	   [--allow-empty] [--no-verify] [-e] [--author=<author>]
 	   [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--]
 	   [[-i | -o ]<file>...]
 
@@ -95,11 +95,10 @@ OPTIONS
 	read the message from the standard input.
 
 --author=<author>::
-	Override the commit author. Specify an explicit author using the
-	standard `A U Thor <author@example.com>` format. Otherwise <author>
-	is assumed to be a pattern and is used to search for an existing
-	commit by that author (i.e. rev-list --all -i --author=<author>);
-	the commit author is then copied from the first such commit found.
+	Override the author name used in the commit.  You can use the
+	standard `A U Thor <author@example.com>` format.  Otherwise,
+	an existing commit that matches the given string and its author
+	name is used.
 
 --date=<date>::
 	Override the author date used in the commit.
@@ -130,13 +129,7 @@ OPTIONS
 	Usually recording a commit that has the exact same tree as its
 	sole parent commit is a mistake, and the command prevents you
 	from making such a commit.  This option bypasses the safety, and
-	is primarily for use by foreign SCM interface scripts.
-
---allow-empty-message::
-       Like --allow-empty this command is primarily for use by foreign
-       SCM interface scripts. It allows you to create a commit with an
-       empty commit message without using plumbing commands like
-       linkgit:git-commit-tree[1].
+	is primarily for use by foreign scm interface scripts.
 
 --cleanup=<mode>::
 	This option sets how the commit message is cleaned up.

Documentation/git-cvsimport.txt

@@ -13,7 +13,7 @@ SYNOPSIS
 	      [-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>]
 	      [-C <git_repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
 	      [-a] [-m] [-M <regex>] [-S <regex>] [-L <commitlimit>]
-	      [-r <remote>] [-R] [<CVS_module>]
+	      [-r <remote>] [<CVS_module>]
 
 
 DESCRIPTION
@@ -157,22 +157,6 @@ It is not recommended to use this feature if you intend to
 export changes back to CVS again later with
 'git cvsexportcommit'.
 
--R::
-	Generate a `$GIT_DIR/cvs-revisions` file containing a mapping from CVS
-	revision numbers to newly-created Git commit IDs.  The generated file
-	will contain one line for each (filename, revision) pair imported;
-	each line will look like
-+
----------
-src/widget.c 1.1 1d862f173cdc7325b6fa6d2ae1cfd61fd1b512b7
----------
-+
-The revision data is appended to the file if it already exists, for use when
-doing incremental imports.
-+
-This option may be useful if you have CVS revision numbers stored in commit
-messages, bug-tracking systems, email archives, and the like.
-
 -h::
 	Print a short usage message and exit.
 
@@ -188,7 +172,7 @@ ISSUES
 ------
 Problems related to timestamps:
 
- * If timestamps of commits in the CVS repository are not stable enough
+ * If timestamps of commits in the cvs repository are not stable enough
    to be used for ordering commits changes may show up in the wrong
    order.
  * If any files were ever "cvs import"ed more than once (e.g., import of
@@ -201,7 +185,7 @@ Problems related to branches:
 
  * Branches on which no commits have been made are not imported.
  * All files from the branching point are added to a branch even if
-   never added in CVS.
+   never added in cvs.
  * This applies to files added to the source branch *after* a daughter
    branch was created: if previously no commit was made on the daughter
    branch they will erroneously be added to the daughter branch in git.

Documentation/git-cvsserver.txt

@@ -72,6 +72,9 @@ plugin. Most functionality works fine with both of these clients.
 LIMITATIONS
 -----------
 
+Currently cvsserver works over SSH connections for read/write clients, and
+over pserver for anonymous CVS access.
+
 CVS clients cannot tag, branch or perform GIT merges.
 
 'git-cvsserver' maps GIT branches to CVS modules. This is very different
@@ -81,7 +84,7 @@ one or more directories.
 INSTALLATION
 ------------
 
-1. If you are going to offer CVS access via pserver, add a line in
+1. If you are going to offer anonymous CVS access via pserver, add a line in
    /etc/inetd.conf like
 +
 --
@@ -98,38 +101,6 @@ looks like
    cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
 
 ------
-
-Only anonymous access is provided by pserve by default. To commit you
-will have to create pserver accounts, simply add a gitcvs.authdb
-setting in the config file of the repositories you want the cvsserver
-to allow writes to, for example:
-
-------
-
-   [gitcvs]
-	authdb = /etc/cvsserver/passwd
-
-------
-The format of these files is username followed by the crypted password,
-for example:
-
-------
-   myuser:$1Oyx5r9mdGZ2
-   myuser:$1$BA)@$vbnMJMDym7tA32AamXrm./
-------
-You can use the 'htpasswd' facility that comes with Apache to make these
-files, but Apache's MD5 crypt method differs from the one used by most C
-library's crypt() function, so don't use the -m option.
-
-Alternatively you can produce the password with perl's crypt() operator:
------
-   perl -e 'my ($user, $pass) = @ARGV; printf "%s:%s\n", $user, crypt($user, $pass)' $USER password
------
-
-Then provide your password via the pserver method, for example:
-------
-   cvs -d:pserver:someuser:somepassword <at> server/path/repo.git co <HEAD_name>
-------
 No special setup is needed for SSH access, other than having GIT tools
 in the PATH. If you have clients that do not accept the CVS_SERVER
 environment variable, you can rename 'git-cvsserver' to `cvs`.
@@ -366,16 +337,19 @@ CRLF Line Ending Conversions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 By default the server leaves the '-k' mode blank for all files,
-which causes the CVS client to treat them as a text files, subject
-to end-of-line conversion on some platforms.
+which causes the cvs client to treat them as a text files, subject
+to crlf conversion on some platforms.
 
-You can make the server use the end-of-line conversion attributes to
-set the '-k' modes for files by setting the `gitcvs.usecrlfattr`
-config variable.  See linkgit:gitattributes[5] for more information
-about end-of-line conversion.
+You can make the server use `crlf` attributes to set the '-k' modes
+for files by setting the `gitcvs.usecrlfattr` config variable.
+In this case, if `crlf` is explicitly unset ('-crlf'), then the
+server will set '-kb' mode for binary files. If `crlf` is set,
+then the '-k' mode will explicitly be left blank.  See
+also linkgit:gitattributes[5] for more information about the `crlf`
+attribute.
 
 Alternatively, if `gitcvs.usecrlfattr` config is not enabled
-or the attributes do not allow automatic detection for a filename, then
+or if the `crlf` attribute is unspecified for a filename, then
 the server uses the `gitcvs.allbinary` config for the default setting.
 If `gitcvs.allbinary` is set, then file not otherwise
 specified will default to '-kb' mode. Otherwise the '-k' mode

Documentation/git-diff.txt

@@ -68,11 +68,11 @@ for the last two forms that use ".." notations, can be any
 <tree-ish>.
 
 For a more complete list of ways to spell <commit>, see
-"SPECIFYING REVISIONS" section in linkgit:gitrevisions[1].
+"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
 However, "diff" is about comparing two _endpoints_, not ranges,
 and the range notations ("<commit>..<commit>" and
 "<commit>\...<commit>") do not mean a range as defined in the
-"SPECIFYING RANGES" section in linkgit:gitrevisions[1].
+"SPECIFYING RANGES" section in linkgit:git-rev-parse[1].
 
 OPTIONS
 -------

Documentation/git-fast-export.txt

@@ -90,16 +90,10 @@ marks the same across runs.
 	resulting stream can only be used by a repository which
 	already contains the necessary objects.
 
---full-tree::
-	This option will cause fast-export to issue a "deleteall"
-	directive for each commit followed by a full list of all files
-	in the commit (as opposed to just listing the files which are
-	different from the commit's first parent).
-
 [git-rev-list-args...]::
        A list of arguments, acceptable to 'git rev-parse' and
        'git rev-list', that specifies the specific objects and references
-       to export.  For example, `master{tilde}10..master` causes the
+       to export.  For example, `master\~10..master` causes the
        current master reference to be exported along with all objects
        added since its 10th ancestor commit.
 

Documentation/git-fast-import.txt

@@ -439,7 +439,7 @@ Marks must be declared (via `mark`) before they can be used.
 * A complete 40 byte or abbreviated commit SHA-1 in hex.
 
 * Any valid Git SHA-1 expression that resolves to a commit.  See
-  ``SPECIFYING REVISIONS'' in linkgit:gitrevisions[1] for details.
+  ``SPECIFYING REVISIONS'' in linkgit:git-rev-parse[1] for details.
 
 The special case of restarting an incremental import from the
 current branch value should be written as:
@@ -482,11 +482,9 @@ External data format::
 	'M' SP <mode> SP <dataref> SP <path> LF
 ....
 +
-Here usually `<dataref>` must be either a mark reference (`:<idnum>`)
+Here `<dataref>` can be either a mark reference (`:<idnum>`)
 set by a prior `blob` command, or a full 40-byte SHA-1 of an
-existing Git blob object.  If `<mode>` is `040000`` then
-`<dataref>` must be the full 40-byte SHA-1 of an existing
-Git tree object or a mark reference set with `--import-marks`.
+existing Git blob object.
 
 Inline data format::
 	The data content for the file has not been supplied yet.
@@ -511,8 +509,6 @@ in octal.  Git only supports the following modes:
 * `160000`: A gitlink, SHA-1 of the object refers to a commit in
   another repository. Git links can only be specified by SHA or through
   a commit mark. They are used to implement submodules.
-* `040000`: A subdirectory.  Subdirectories can only be specified by
-  SHA or through a tree mark set with `--import-marks`.
 
 In both formats `<path>` is the complete path of the file to be added
 (if not already existing) or modified (if already existing).

Documentation/git-fmt-merge-msg.txt

@@ -9,8 +9,8 @@ git-fmt-merge-msg - Produce a merge commit message
 SYNOPSIS
 --------
 [verse]
-'git fmt-merge-msg' [-m <message>] [--log | --no-log] <$GIT_DIR/FETCH_HEAD
-'git fmt-merge-msg' [-m <message>] [--log | --no-log] -F <file>
+'git fmt-merge-msg' [--log | --no-log] <$GIT_DIR/FETCH_HEAD
+'git fmt-merge-msg' [--log | --no-log] -F <file>
 
 DESCRIPTION
 -----------
@@ -38,11 +38,6 @@ OPTIONS
 	Synonyms to --log and --no-log; these are deprecated and will be
 	removed in the future.
 
--m <message>::
---message <message>::
-	Use <message> instead of the branch names for the first line
-	of the log message.  For use with `--log`.
-
 -F <file>::
 --file <file>::
 	Take the list of merged objects from <file> instead of

Documentation/git-for-each-ref.txt

@@ -9,7 +9,7 @@ SYNOPSIS
 --------
 [verse]
 'git for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl]
-		   [--sort=<key>]* [--format=<format>] [<pattern>...]
+		   [--sort=<key>]\* [--format=<format>] [<pattern>...]
 
 DESCRIPTION
 -----------
@@ -86,7 +86,6 @@ objectsize::
 
 objectname::
 	The object name (aka SHA-1).
-	For a non-ambiguous abbreviation of the object name append `:short`.
 
 upstream::
 	The name of a local ref which can be considered ``upstream''

Documentation/git-format-patch.txt

@@ -13,13 +13,12 @@ SYNOPSIS
 		   [--no-thread | --thread[=<style>]]
 		   [(--attach|--inline)[=<boundary>] | --no-attach]
 		   [-s | --signoff]
-		   [--signature=<signature> | --no-signature]
 		   [-n | --numbered | -N | --no-numbered]
 		   [--start-number <n>] [--numbered-files]
 		   [--in-reply-to=Message-Id] [--suffix=.<sfx>]
 		   [--ignore-if-in-upstream]
 		   [--subject-prefix=Subject-Prefix]
-		   [--to=<email>] [--cc=<email>]
+		   [--cc=<email>]
 		   [--cover-letter]
 		   [<common diff options>]
 		   [ <since> | <revision range> ]
@@ -39,7 +38,7 @@ There are two ways to specify which commits to operate on.
    that leads to the <since> to be output.
 
 2. Generic <revision range> expression (see "SPECIFYING
-   REVISIONS" section in linkgit:gitrevisions[1]) means the
+   REVISIONS" section in linkgit:git-rev-parse[1]) means the
    commits in the specified range.
 
 The first rule takes precedence in the case of a single <commit>.  To
@@ -163,10 +162,6 @@ will want to ensure that threading is disabled for `git send-email`.
 	allows for useful naming of a patch series, and can be
 	combined with the `--numbered` option.
 
---to=<email>::
-	Add a `To:` header to the email headers. This is in addition
-	to any configured headers, and may be used multiple times.
-
 --cc=<email>::
 	Add a `Cc:` header to the email headers. This is in addition
 	to any configured headers, and may be used multiple times.
@@ -181,12 +176,6 @@ will want to ensure that threading is disabled for `git send-email`.
 	containing the shortlog and the overall diffstat.  You can
 	fill in a description in the file before sending it out.
 
---[no]-signature=<signature>::
-	Add a signature to each message produced. Per RFC 3676 the signature
-	is separated from the body by a line with '-- ' on it. If the
-	signature option is omitted the signature defaults to the git version
-	number.
-
 --suffix=.<sfx>::
 	Instead of using `.patch` as the suffix for generated
 	filenames, use specified suffix.  A common alternative is
@@ -213,8 +202,8 @@ CONFIGURATION
 -------------
 You can specify extra mail header lines to be added to each message,
 defaults for the subject prefix and file suffix, number patches when
-outputting more than one patch, add "To" or "Cc:" headers, configure
-attachments, and sign off patches with configuration variables.
+outputting more than one patch, add "Cc:" headers, configure attachments,
+and sign off patches with configuration variables.
 
 ------------
 [format]
@@ -222,7 +211,6 @@ attachments, and sign off patches with configuration variables.
 	subjectprefix = CHANGE
 	suffix = .txt
 	numbered = auto
-	to = <email>
 	cc = <email>
 	attach [ = mime-boundary-string ]
 	signoff = true

Documentation/git-gc.txt

@@ -88,16 +88,6 @@ commits prior to the amend or rebase occurring.  Since these changes
 are not part of the current project most users will want to expire
 them sooner.  This option defaults to '30 days'.
 
-The above two configuration variables can be given to a pattern.  For
-example, this sets non-default expiry values only to remote tracking
-branches:
-
-------------
-[gc "refs/remotes/*"]
-	reflogExpire = never
-	reflogexpireUnreachable = 3 days
-------------
-
 The optional configuration variable 'gc.rerereresolved' indicates
 how long records of conflicted merge you resolved earlier are
 kept.  This defaults to 60 days.
@@ -137,13 +127,6 @@ If you are expecting some objects to be collected and they aren't, check
 all of those locations and decide whether it makes sense in your case to
 remove those references.
 
-HOOKS
------
-
-The 'git gc --auto' command will run the 'pre-auto-gc' hook.  See
-linkgit:githooks[5] for more information.
-
-
 SEE ALSO
 --------
 linkgit:git-prune[1]

Documentation/git-grep.txt

@@ -14,11 +14,10 @@ SYNOPSIS
 	   [-E | --extended-regexp] [-G | --basic-regexp]
 	   [-F | --fixed-strings] [-n]
 	   [-l | --files-with-matches] [-L | --files-without-match]
-	   [(-O | --open-files-in-pager) [<pager>]]
 	   [-z | --null]
 	   [-c | --count] [--all-match] [-q | --quiet]
 	   [--max-depth <depth>]
-	   [--color[=<when>] | --no-color]
+	   [--color | --no-color]
 	   [-A <post-context>] [-B <pre-context>] [-C <context>]
 	   [-f <file>] [-e] <pattern>
 	   [--and|--or|--not|(|)|-e <pattern>...]
@@ -105,13 +104,6 @@ OPTIONS
 	For better compatibility with 'git diff', `--name-only` is a
 	synonym for `--files-with-matches`.
 
--O [<pager>]::
---open-files-in-pager [<pager>]::
-	Open the matching files in the pager (not the output of 'grep').
-	If the pager happens to be "less" or "vi", and the user
-	specified only one pattern, the first file is positioned at
-	the first match automatically.
-
 -z::
 --null::
 	Output \0 instead of the character that normally follows a
@@ -122,14 +114,12 @@ OPTIONS
 	Instead of showing every matched line, show the number of
 	lines that match.
 
---color[=<when>]::
+--color::
 	Show colored matches.
-	The value must be always (the default), never, or auto.
 
 --no-color::
 	Turn off match highlighting, even when the configuration file
 	gives the default to color output.
-	Same as `--color=never`.
 
 -[ABC] <context>::
 	Show `context` trailing (`A` -- after), or leading (`B`
@@ -191,11 +181,11 @@ OPTIONS
 Examples
 --------
 
-git grep {apostrophe}time_t{apostrophe} \-- {apostrophe}*.[ch]{apostrophe}::
+git grep 'time_t' -- '*.[ch]'::
 	Looks for `time_t` in all tracked .c and .h files in the working
 	directory and its subdirectories.
 
-git grep -e {apostrophe}#define{apostrophe} --and \( -e MAX_PATH -e PATH_MAX \)::
+git grep -e \'#define\' --and \( -e MAX_PATH -e PATH_MAX \)::
 	Looks for a line that has `#define` and either `MAX_PATH` or
 	`PATH_MAX`.
 

Documentation/git-hash-object.txt

@@ -10,7 +10,7 @@ SYNOPSIS
 --------
 [verse]
 'git hash-object' [-t <type>] [-w] [--path=<file>|--no-filters] [--stdin] [--] <file>...
-'git hash-object' [-t <type>] [-w] --stdin-paths [--no-filters] < <list-of-paths>
+'git hash-object' [-t <type>] [-w] --stdin-paths < <list-of-paths>
 
 DESCRIPTION
 -----------
@@ -49,7 +49,7 @@ OPTIONS
 
 --no-filters::
 	Hash the contents as is, ignoring any input filter that would
-	have been chosen by the attributes mechanism, including the end-of-line
+	have been chosen by the attributes mechanism, including crlf
 	conversion. If the file is read from standard input then this
 	is always implied, unless the --path option is given.
 

Documentation/git-help.txt

@@ -55,9 +55,9 @@ other display programs (see below).
 +
 The web browser can be specified using the configuration variable
 'help.browser', or 'web.browser' if the former is not set. If none of
-these config variables is set, the 'git web{litdd}browse' helper script
+these config variables is set, the 'git web--browse' helper script
 (called by 'git help') will pick a suitable default. See
-linkgit:git-web{litdd}browse[1] for more information about this.
+linkgit:git-web--browse[1] for more information about this.
 
 CONFIGURATION VARIABLES
 -----------------------
@@ -80,7 +80,7 @@ help.browser, web.browser and browser.<tool>.path
 The 'help.browser', 'web.browser' and 'browser.<tool>.path' will also
 be checked if the 'web' format is chosen (either by command line
 option or configuration variable). See '-w|--web' in the OPTIONS
-section above and linkgit:git-web{litdd}browse[1].
+section above and linkgit:git-web--browse[1].
 
 man.viewer
 ~~~~~~~~~~

Documentation/git-imap-send.txt

@@ -73,10 +73,6 @@ imap.preformattedHTML::
 	option causes Thunderbird to send the patch as a plain/text,
 	format=fixed email.  Default is `false`.
 
-imap.authMethod::
-	Specify authenticate method for authentication with IMAP server.
-	Current supported method is 'CRAM-MD5' only.
-
 Examples
 ~~~~~~~~
 

Documentation/git-init.txt

@@ -28,8 +28,14 @@ current working directory.
 
 --template=<template_directory>::
 
-Specify the directory from which templates will be used.  (See the "TEMPLATE
-DIRECTORY" section below.)
+Provide the directory from which templates will be used.  The default template
+directory is `/usr/share/git-core/templates`.
+
+When specified, `<template_directory>` is used as the source of the template
+files rather than the default.  The template files include some directory
+structure, some suggested "exclude patterns", and copies of non-executing
+"hook" files.  The suggested patterns and hook files are all modifiable and
+extensible.
 
 --shared[={false|true|umask|group|all|world|everybody|0xxx}]::
 
@@ -100,25 +106,6 @@ of the repository, such as installing the default hooks and
 setting the configuration variables.  The old name is retained
 for backward compatibility reasons.
 
-TEMPLATE DIRECTORY
-------------------
-
-The template directory contains files and directories that will be copied to
-the `$GIT_DIR` after it is created.
-
-The template directory used will (in order):
-
- - The argument given with the `--template` option.
-
- - The contents of the `$GIT_TEMPLATE_DIR` environment variable.
-
- - The `init.templatedir` configuration variable.
-
- - The default template directory: `/usr/share/git-core/templates`.
-
-The default template directory includes some directory structure, some
-suggested "exclude patterns", and copies of sample "hook" files.
-The suggested patterns and hook files are all modifiable and extensible.
 
 EXAMPLES
 --------

Documentation/git-instaweb.txt

@@ -29,7 +29,7 @@ OPTIONS
 	The HTTP daemon command-line that will be executed.
 	Command-line options may be specified here, and the
 	configuration file will be added at the end of the command-line.
-	Currently apache2, lighttpd, mongoose, plackup and webrick are supported.
+	Currently apache2, lighttpd, mongoose and webrick are supported.
 	(Default: lighttpd)
 
 -m::
@@ -44,23 +44,20 @@ OPTIONS
 -b::
 --browser::
 	The web browser that should be used to view the gitweb
-	page. This will be passed to the 'git web{litdd}browse' helper
+	page. This will be passed to the 'git web--browse' helper
 	script along with the URL of the gitweb instance. See
-	linkgit:git-web{litdd}browse[1] for more information about this. If
+	linkgit:git-web--browse[1] for more information about this. If
 	the script fails, the URL will be printed to stdout.
 
-start::
 --start::
 	Start the httpd instance and exit.  This does not generate
 	any of the configuration files for spawning a new instance.
 
-stop::
 --stop::
 	Stop the httpd instance and exit.  This does not generate
 	any of the configuration files for spawning a new instance,
 	nor does it close the browser.
 
-restart::
 --restart::
 	Restart the httpd instance and exit.  This does not generate
 	any of the configuration files for spawning a new instance.
@@ -82,7 +79,7 @@ You may specify configuration in your .git/config
 
 If the configuration variable 'instaweb.browser' is not set,
 'web.browser' will be used instead if it is defined. See
-linkgit:git-web{litdd}browse[1] for more information about this.
+linkgit:git-web--browse[1] for more information about this.
 
 Author
 ------

Documentation/git-log.txt

@@ -23,6 +23,9 @@ each commit introduces are shown.
 OPTIONS
 -------
 
+:git-log: 1
+include::diff-options.txt[]
+
 -<n>::
 	Limits the number of commits to show.
 
@@ -31,14 +34,10 @@ OPTIONS
 	either <since> or <until> is omitted, it defaults to
 	`HEAD`, i.e. the tip of the current branch.
 	For a more complete list of ways to spell <since>
-	and <until>, see linkgit:gitrevisions[1].
+	and <until>, see "SPECIFYING REVISIONS" section in
+	linkgit:git-rev-parse[1].
 
---follow::
-	Continue listing the history of a file beyond renames
-	(works only for a single file).
-
---no-decorate::
---decorate[=short|full|no]::
+--decorate[=short|full]::
 	Print out the ref names of any commits that are shown. If 'short' is
 	specified, the ref name prefixes 'refs/heads/', 'refs/tags/' and
 	'refs/remotes/' will not be printed. If 'full' is specified, the
@@ -55,9 +54,9 @@ OPTIONS
 	paths.  With this, the full diff is shown for commits that touch
 	the specified paths; this means that "<path>..." limits only
 	commits, and doesn't limit diff for those commits.
-+
-Note that this affects all diff-based output types, e.g. those
-produced by --stat etc.
+
+--follow::
+	Continue listing the history of a file beyond renames.
 
 --log-size::
 	Before the log message print out its size in bytes. Intended
@@ -72,11 +71,6 @@ produced by --stat etc.
 	to be prefixed with "\-- " to separate them from options or
 	refnames.
 
-Common diff options
-~~~~~~~~~~~~~~~~~~~
-
-:git-log: 1
-include::diff-options.txt[]
 
 include::rev-list-options.txt[]
 
@@ -124,62 +118,11 @@ git log master --not --remotes=*/master::
 	Shows all commits that are in local master but not in any remote
 	repository master branches.
 
-git log -p -m --first-parent::
-
-	Shows the history including change diffs, but only from the
-	"main branch" perspective, skipping commits that come from merged
-	branches, and showing full diffs of changes introduced by the merges.
-	This makes sense only when following a strict policy of merging all
-	topic branches when staying on a single integration branch.
-
-
 Discussion
 ----------
 
 include::i18n.txt[]
 
-Configuration
--------------
-
-See linkgit:git-config[1] for core variables and linkgit:git-diff[1]
-for settings related to diff generation.
-
-format.pretty::
-	Default for the `--format` option.  (See "PRETTY FORMATS" above.)
-	Defaults to "medium".
-
-i18n.logOutputEncoding::
-	Encoding to use when displaying logs.  (See "Discussion", above.)
-	Defaults to the value of `i18n.commitEncoding` if set, UTF-8
-	otherwise.
-
-log.date::
-	Default format for human-readable dates.  (Compare the
-	`--date` option.)  Defaults to "default", which means to write
-	dates like `Sat May 8 19:35:34 2010 -0500`.
-
-log.showroot::
-	If `false`, 'git log' and related commands will not treat the
-	initial commit as a big creation event.  Any root commits in
-	`git log -p` output would be shown without a diff attached.
-	The default is `true`.
-
-mailmap.file::
-	See linkgit:git-shortlog[1].
-
-notes.displayRef::
-	Which refs, in addition to the default set by `core.notesRef`
-	or 'GIT_NOTES_REF', to read notes from when showing commit
-	messages with the 'log' family of commands.  See
-	linkgit:git-notes[1].
-+
-May be an unabbreviated ref name or a glob and may be specified
-multiple times.  A warning will be issued for refs that do not exist,
-but a glob that does not match any refs is silently ignored.
-+
-This setting can be disabled by the `--no-standard-notes` option,
-overridden by the 'GIT_NOTES_DISPLAY_REF' environment variable,
-and supplemented by the `--show-notes` option.
 
 Author
 ------

Documentation/git-ls-files.txt

@@ -10,14 +10,14 @@ SYNOPSIS
 --------
 [verse]
 'git ls-files' [-z] [-t] [-v]
-		(--[cached|deleted|others|ignored|stage|unmerged|killed|modified])*
-		(-[c|d|o|i|s|u|k|m])*
+		(--[cached|deleted|others|ignored|stage|unmerged|killed|modified])\*
+		(-[c|d|o|i|s|u|k|m])\*
 		[-x <pattern>|--exclude=<pattern>]
 		[-X <file>|--exclude-from=<file>]
 		[--exclude-per-directory=<file>]
 		[--exclude-standard]
 		[--error-unmatch] [--with-tree=<tree-ish>]
-		[--full-name] [--abbrev] [--] [<file>]*
+		[--full-name] [--abbrev] [--] [<file>]\*
 
 DESCRIPTION
 -----------
@@ -106,16 +106,8 @@ OPTIONS
 	with `-s` or `-u` options does not make any sense.
 
 -t::
-	This feature is semi-deprecated. For scripting purpose,
-	linkgit:git-status[1] `--porcelain` and
-	linkgit:git-diff-files[1] `--name-status` are almost always
-	superior alternatives, and users should look at
-	linkgit:git-status[1] `--short` or linkgit:git-diff[1]
-	`--name-status` for more user-friendly alternatives.
-+
-This option identifies the file status with the following tags (followed by
-a space) at the start of each line:
-
+	Identify the file status with the following tags (followed by
+	a space) at the start of each line:
 	H::	cached
 	S::	skip-worktree
 	M::	unmerged
@@ -140,12 +132,6 @@ a space) at the start of each line:
 	lines, show only a partial prefix.
 	Non default number of digits can be specified with --abbrev=<n>.
 
---debug::
-	After each line that describes a file, add more data about its
-	cache entry.  This is intended to show as much information as
-	possible for manual inspection; the exact format may change at
-	any time.
-
 \--::
 	Do not interpret any more arguments as options.
 

Documentation/git-mailinfo.txt

@@ -40,16 +40,16 @@ OPTIONS
 -u::
 	The commit log message, author name and author email are
 	taken from the e-mail, and after minimally decoding MIME
-	transfer encoding, re-coded in the charset specified by
-	i18n.commitencoding (defaulting to UTF-8) by transliterating
+	transfer encoding, re-coded in UTF-8 by transliterating
 	them.  This used to be optional but now it is the default.
 +
 Note that the patch is always used as-is without charset
 conversion, even with this flag.
 
 --encoding=<encoding>::
-	Similar to -u.  But when re-coding, the charset specified here is
-	used instead of the one specified by i18n.commitencoding or UTF-8.
+	Similar to -u but if the local convention is different
+	from what is specified by i18n.commitencoding, this flag
+	can be used to override it.
 
 -n::
 	Disable all charset re-coding of the metadata.

Documentation/git-mailsplit.txt

@@ -7,7 +7,7 @@ git-mailsplit - Simple UNIX mbox splitter program
 
 SYNOPSIS
 --------
-'git mailsplit' [-b] [-f<nn>] [-d<prec>] [--keep-cr] -o<directory> [--] [<mbox>|<Maildir>...]
+'git mailsplit' [-b] [-f<nn>] [-d<prec>] -o<directory> [--] [<mbox>|<Maildir>...]
 
 DESCRIPTION
 -----------
@@ -43,9 +43,6 @@ OPTIONS
 	Skip the first <nn> numbers, for example if -f3 is specified,
 	start the numbering with 0004.
 
---keep-cr::
-	Do not remove `\r` from lines ending with `\r\n`.
-
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org>

Documentation/git-merge-base.txt

@@ -8,9 +8,7 @@ git-merge-base - Find as good common ancestors as possible for a merge
 
 SYNOPSIS
 --------
-[verse]
-'git merge-base' [-a|--all] [--octopus] <commit> <commit>...
-'git merge-base' --independent <commit>...
+'git merge-base' [-a|--all] <commit> <commit>...
 
 DESCRIPTION
 -----------
@@ -22,12 +20,12 @@ that does not have any better common ancestor is a 'best common
 ancestor', i.e. a 'merge base'.  Note that there can be more than one
 merge base for a pair of commits.
 
-Unless `--octopus` is given, among the two commits to compute the merge
-base from, one is specified by the first commit argument on the command
-line; the other commit is a (possibly hypothetical) commit that is a merge
-across all the remaining commits on the command line.  As the most common
-special case, specifying only two commits on the command line means
-computing the merge base between the given two commits.
+Among the two commits to compute the merge base from, one is specified by
+the first commit argument on the command line; the other commit is a
+(possibly hypothetical) commit that is a merge across all the remaining
+commits on the command line.  As the most common special case, specifying only
+two commits on the command line means computing the merge base between
+the given two commits.
 
 As a consequence, the 'merge base' is not necessarily contained in each of the
 commit arguments if more than two commits are specified. This is different
@@ -39,18 +37,6 @@ OPTIONS
 --all::
 	Output all merge bases for the commits, instead of just one.
 
---octopus::
-	Compute the best common ancestors of all supplied commits,
-	in preparation for an n-way merge.  This mimics the behavior
-	of 'git show-branch --merge-base'.
-
---independent::
-	Instead of printing merge bases, print a minimal subset of
-	the supplied commits with the same ancestors.  In other words,
-	among the commits given, list those which cannot be reached
-	from any other.  This mimics the behavior of 'git show-branch
-	--independent'.
-
 DISCUSSION
 ----------
 
@@ -110,12 +96,6 @@ Documentation
 --------------
 Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
 
-See also
---------
-linkgit:git-rev-list[1],
-linkgit:git-show-branch[1],
-linkgit:git-merge[1]
-
 GIT
 ---
 Part of the linkgit:git[1] suite

Documentation/git-merge-file.txt

@@ -10,7 +10,7 @@ SYNOPSIS
 --------
 [verse]
 'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
-	[--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
+	[--ours|--theirs] [-p|--stdout] [-q|--quiet]
 	<current-file> <base-file> <other-file>
 
 
@@ -35,10 +35,9 @@ normally outputs a warning and brackets the conflict with lines containing
 	>>>>>>> B
 
 If there are conflicts, the user should edit the result and delete one of
-the alternatives.  When `--ours`, `--theirs`, or `--union` option is in effect,
-however, these conflicts are resolved favouring lines from `<current-file>`,
-lines from `<other-file>`, or lines from both respectively.  The length of the
-conflict markers can be given with the `--marker-size` option.
+the alternatives.  When `--ours` or `--theirs` option is in effect, however,
+these conflicts are resolved favouring lines from `<current-file>` or
+lines from `<other-file>` respectively.
 
 The exit value of this program is negative on error, and the number of
 conflicts otherwise. If the merge was clean, the exit value is 0.
@@ -68,9 +67,8 @@ OPTIONS
 
 --ours::
 --theirs::
---union::
 	Instead of leaving conflicts in the file, resolve conflicts
-	favouring our (or their or both) side of the lines.
+	favouring our (or their) side of the lines.
 
 
 EXAMPLES

Documentation/git-merge-index.txt

@@ -8,7 +8,7 @@ git-merge-index - Run a merge for files needing merging
 
 SYNOPSIS
 --------
-'git merge-index' [-o] [-q] <merge-program> (-a | [--] <file>*)
+'git merge-index' [-o] [-q] <merge-program> (-a | [--] <file>\*)
 
 DESCRIPTION
 -----------

Documentation/git-merge.txt

@@ -58,12 +58,7 @@ include::merge-options.txt[]
 
 -m <msg>::
 	Set the commit message to be used for the merge commit (in
-	case one is created).
-
-	If `--log` is specified, a shortlog of the commits being merged
-	will be appended to the specified message.
-
-	The 'git fmt-merge-msg' command can be
+	case one is created). The 'git fmt-merge-msg' command can be
 	used to give a good default for automated 'git merge'
 	invocations.
 

Documentation/git-mergetool--lib.txt

@@ -1,5 +1,5 @@
-git-mergetool{litdd}lib(1)
-==========================
+git-mergetool--lib(1)
+=====================
 
 NAME
 ----
@@ -16,11 +16,11 @@ This is not a command the end user would want to run.  Ever.
 This documentation is meant for people who are studying the
 Porcelain-ish scripts and/or are writing new ones.
 
-The 'git-mergetool{litdd}lib' scriptlet is designed to be sourced (using
+The 'git-mergetool--lib' scriptlet is designed to be sourced (using
 `.`) by other shell scripts to set up functions for working
 with git merge tools.
 
-Before sourcing 'git-mergetool{litdd}lib', your script must set `TOOL_MODE`
+Before sourcing 'git-mergetool--lib', your script must set `TOOL_MODE`
 to define the operation mode for the functions listed below.
 'diff' and 'merge' are valid values.
 

Documentation/git-mergetool.txt

@@ -72,16 +72,6 @@ success of the resolution after the custom tool has exited.
 	This is the default behaviour; the option is provided to
 	override any configuration settings.
 
-TEMPORARY FILES
----------------
-`git mergetool` creates `*.orig` backup files while resolving merges.
-These are safe to remove once a file has been merged and its
-`git mergetool` session has completed.
-
-Setting the `mergetool.keepBackup` configuration variable to `false`
-causes `git mergetool` to automatically remove the backup as files
-are successfully merged.
-
 Author
 ------
 Written by Theodore Y Ts'o <tytso@mit.edu>

Documentation/git-notes.txt

@@ -3,284 +3,57 @@ git-notes(1)
 
 NAME
 ----
-git-notes - Add or inspect object notes
+git-notes - Add/inspect commit notes
 
 SYNOPSIS
 --------
 [verse]
-'git notes' [list [<object>]]
-'git notes' add [-f] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>]
-'git notes' copy [-f] ( --stdin | <from-object> <to-object> )
-'git notes' append [-F <file> | -m <msg> | (-c | -C) <object>] [<object>]
-'git notes' edit [<object>]
-'git notes' show [<object>]
-'git notes' remove [<object>]
-'git notes' prune [-n | -v]
-
+'git notes' (edit [-F <file> | -m <msg>] | show) [commit]
 
 DESCRIPTION
 -----------
-Adds, removes, or reads notes attached to objects, without touching
-the objects themselves.
+This command allows you to add notes to commit messages, without
+changing the commit.  To discern these notes from the message stored
+in the commit object, the notes are indented like the message, after
+an unindented line saying "Notes:".
 
-By default, notes are saved to and read from `refs/notes/commits`, but
-this default can be overridden.  See the OPTIONS, CONFIGURATION, and
-ENVIRONMENT sections below.  If this ref does not exist, it will be
-quietly created when it is first needed to store a note.
-
-A typical use of notes is to supplement a commit message without
-changing the commit itself. Notes can be shown by 'git log' along with
-the original commit message. To distinguish these notes from the
-message stored in the commit object, the notes are indented like the
-message, after an unindented line saying "Notes (<refname>):" (or
-"Notes:" for `refs/notes/commits`).
-
-To change which notes are shown by 'git log', see the
-"notes.displayRef" configuration in linkgit:git-log[1].
-
-See the "notes.rewrite.<command>" configuration for a way to carry
-notes across commands that rewrite commits.
+To disable commit notes, you have to set the config variable
+core.notesRef to the empty string.  Alternatively, you can set it
+to a different ref, something like "refs/notes/bugzilla".  This setting
+can be overridden by the environment variable "GIT_NOTES_REF".
 
 
 SUBCOMMANDS
 -----------
 
-list::
-	List the notes object for a given object. If no object is
-	given, show a list of all note objects and the objects they
-	annotate (in the format "<note object> <annotated object>").
-	This is the default subcommand if no subcommand is given.
-
-add::
-	Add notes for a given object (defaults to HEAD). Abort if the
-	object already has notes (use `-f` to overwrite an
-	existing note).
-
-copy::
-	Copy the notes for the first object onto the second object.
-	Abort if the second object already has notes, or if the first
-	object has none (use -f to overwrite existing notes to the
-	second object). This subcommand is equivalent to:
-	`git notes add [-f] -C $(git notes list <from-object>) <to-object>`
-+
-In `\--stdin` mode, take lines in the format
-+
-----------
-<from-object> SP <to-object> [ SP <rest> ] LF
-----------
-+
-on standard input, and copy the notes from each <from-object> to its
-corresponding <to-object>.  (The optional `<rest>` is ignored so that
-the command can read the input given to the `post-rewrite` hook.)
-
-append::
-	Append to the notes of an existing object (defaults to HEAD).
-	Creates a new notes object if needed.
-
 edit::
-	Edit the notes for a given object (defaults to HEAD).
+	Edit the notes for a given commit (defaults to HEAD).
 
 show::
-	Show the notes for a given object (defaults to HEAD).
+	Show the notes for a given commit (defaults to HEAD).
 
-remove::
-	Remove the notes for a given object (defaults to HEAD).
-	This is equivalent to specifying an empty note message to
-	the `edit` subcommand.
-
-prune::
-	Remove all notes for non-existing/unreachable objects.
 
 OPTIONS
 -------
--f::
---force::
-	When adding notes to an object that already has notes,
-	overwrite the existing notes (instead of aborting).
-
 -m <msg>::
---message=<msg>::
 	Use the given note message (instead of prompting).
-	If multiple `-m` options are given, their values
-	are concatenated as separate paragraphs.
-	Lines starting with `#` and empty lines other than a
-	single line between paragraphs will be stripped out.
+	If multiple `-m` (or `-F`) options are given, their
+	values are concatenated as separate paragraphs.
 
 -F <file>::
---file=<file>::
 	Take the note message from the given file.  Use '-' to
 	read the note message from the standard input.
-	Lines starting with `#` and empty lines other than a
-	single line between paragraphs will be stripped out.
-
--C <object>::
---reuse-message=<object>::
-	Take the note message from the given blob object (for
-	example, another note).
-
--c <object>::
---reedit-message=<object>::
-	Like '-C', but with '-c' the editor is invoked, so that
-	the user can further edit the note message.
-
---ref <ref>::
-	Manipulate the notes tree in <ref>.  This overrides
-	'GIT_NOTES_REF' and the "core.notesRef" configuration.  The ref
-	is taken to be in `refs/notes/` if it is not qualified.
-
--n::
---dry-run::
-	Do not remove anything; just report the object names whose notes
-	would be removed.
-
--v::
---verbose::
-	Report all object names whose notes are removed.
-
-
-DISCUSSION
-----------
-
-Commit notes are blobs containing extra information about an object
-(usually information to supplement a commit's message).  These blobs
-are taken from notes refs.  A notes ref is usually a branch which
-contains "files" whose paths are the object names for the objects
-they describe, with some directory separators included for performance
-reasons footnote:[Permitted pathnames have the form
-'ab'`/`'cd'`/`'ef'`/`'...'`/`'abcdef...': a sequence of directory
-names of two hexadecimal digits each followed by a filename with the
-rest of the object ID.].
-
-Every notes change creates a new commit at the specified notes ref.
-You can therefore inspect the history of the notes by invoking, e.g.,
-`git log -p notes/commits`.  Currently the commit message only records
-which operation triggered the update, and the commit authorship is
-determined according to the usual rules (see linkgit:git-commit[1]).
-These details may change in the future.
-
-It is also permitted for a notes ref to point directly to a tree
-object, in which case the history of the notes can be read with
-`git log -p -g <refname>`.
-
-
-EXAMPLES
---------
-
-You can use notes to add annotations with information that was not
-available at the time a commit was written.
-
-------------
-$ git notes add -m 'Tested-by: Johannes Sixt <j6t@kdbg.org>' 72a144e2
-$ git show -s 72a144e
-[...]
-    Signed-off-by: Junio C Hamano <gitster@pobox.com>
-
-Notes:
-    Tested-by: Johannes Sixt <j6t@kdbg.org>
-------------
-
-In principle, a note is a regular Git blob, and any kind of
-(non-)format is accepted.  You can binary-safely create notes from
-arbitrary files using 'git hash-object':
-
-------------
-$ cc *.c
-$ blob=$(git hash-object -w a.out)
-$ git notes --ref=built add -C "$blob" HEAD
-------------
-
-Of course, it doesn't make much sense to display non-text-format notes
-with 'git log', so if you use such notes, you'll probably need to write
-some special-purpose tools to do something useful with them.
-
-
-CONFIGURATION
--------------
-
-core.notesRef::
-	Notes ref to read and manipulate instead of
-	`refs/notes/commits`.  Must be an unabbreviated ref name.
-	This setting can be overridden through the environment and
-	command line.
-
-notes.displayRef::
-	Which ref (or refs, if a glob or specified more than once), in
-	addition to the default set by `core.notesRef` or
-	'GIT_NOTES_REF', to read notes from when showing commit
-	messages with the 'git log' family of commands.
-	This setting can be overridden on the command line or by the
-	'GIT_NOTES_DISPLAY_REF' environment variable.
-	See linkgit:git-log[1].
-
-notes.rewrite.<command>::
-	When rewriting commits with <command> (currently `amend` or
-	`rebase`), if this variable is `false`, git will not copy
-	notes from the original to the rewritten commit.  Defaults to
-	`true`.  See also "`notes.rewriteRef`" below.
-+
-This setting can be overridden by the 'GIT_NOTES_REWRITE_REF'
-environment variable.
-
-notes.rewriteMode::
-	When copying notes during a rewrite, what to do if the target
-	commit already has a note.  Must be one of `overwrite`,
-	`concatenate`, and `ignore`.  Defaults to `concatenate`.
-+
-This setting can be overridden with the `GIT_NOTES_REWRITE_MODE`
-environment variable.
-
-notes.rewriteRef::
-	When copying notes during a rewrite, specifies the (fully
-	qualified) ref whose notes should be copied.  May be a glob,
-	in which case notes in all matching refs will be copied.  You
-	may also specify this configuration several times.
-+
-Does not have a default value; you must configure this variable to
-enable note rewriting.
-+
-Can be overridden with the 'GIT_NOTES_REWRITE_REF' environment variable.
-
-
-ENVIRONMENT
------------
-
-'GIT_NOTES_REF'::
-	Which ref to manipulate notes from, instead of `refs/notes/commits`.
-	This overrides the `core.notesRef` setting.
-
-'GIT_NOTES_DISPLAY_REF'::
-	Colon-delimited list of refs or globs indicating which refs,
-	in addition to the default from `core.notesRef` or
-	'GIT_NOTES_REF', to read notes from when showing commit
-	messages.
-	This overrides the `notes.displayRef` setting.
-+
-A warning will be issued for refs that do not exist, but a glob that
-does not match any refs is silently ignored.
-
-'GIT_NOTES_REWRITE_MODE'::
-	When copying notes during a rewrite, what to do if the target
-	commit already has a note.
-	Must be one of `overwrite`, `concatenate`, and `ignore`.
-	This overrides the `core.rewriteMode` setting.
-
-'GIT_NOTES_REWRITE_REF'::
-	When rewriting commits, which notes to copy from the original
-	to the rewritten commit.  Must be a colon-delimited list of
-	refs or globs.
-+
-If not set in the environment, the list of notes to copy depends
-on the `notes.rewrite.<command>` and `notes.rewriteRef` settings.
+	If multiple `-F` (or `-m`) options are given, their
+	values are concatenated as separate paragraphs.
 
 
 Author
 ------
-Written by Johannes Schindelin <johannes.schindelin@gmx.de> and
-Johan Herland <johan@herland.net>
+Written by Johannes Schindelin <johannes.schindelin@gmx.de>
 
 Documentation
 -------------
-Documentation by Johannes Schindelin and Johan Herland
+Documentation by Johannes Schindelin
 
 GIT
 ---

Documentation/git-prune.txt

@@ -31,12 +31,10 @@ OPTIONS
 -------
 
 -n::
---dry-run::
 	Do not remove anything; just report what it would
 	remove.
 
 -v::
---verbose::
 	Report all removed objects.
 
 \--::

Documentation/git-pull.txt

@@ -8,82 +8,29 @@ git-pull - Fetch from and merge with another repository or a local branch
 
 SYNOPSIS
 --------
-'git pull' [options] [<repository> [<refspec>...]]
+'git pull' <options> <repository> <refspec>...
 
 
 DESCRIPTION
 -----------
+Runs 'git fetch' with the given parameters, and calls 'git merge'
+to merge the retrieved head(s) into the current branch.
+With `--rebase`, calls 'git rebase' instead of 'git merge'.
 
-Incorporates changes from a remote repository into the current
-branch.  In its default mode, `git pull` is shorthand for
-`git fetch` followed by `git merge FETCH_HEAD`.
+Note that you can use `.` (current directory) as the
+<repository> to pull from the local repository -- this is useful
+when merging local branches into the current branch.
 
-More precisely, 'git pull' runs 'git fetch' with the given
-parameters and calls 'git merge' to merge the retrieved branch
-heads into the current branch.
-With `--rebase`, it runs 'git rebase' instead of 'git merge'.
+Also note that options meant for 'git pull' itself and underlying
+'git merge' must be given before the options meant for 'git fetch'.
 
-<repository> should be the name of a remote repository as
-passed to linkgit:git-fetch[1].  <refspec> can name an
-arbitrary remote ref (for example, the name of a tag) or even
-a collection of refs with corresponding remote tracking branches
-(e.g., refs/heads/*:refs/remotes/origin/*), but usually it is
-the name of a branch in the remote repository.
-
-Default values for <repository> and <branch> are read from the
-"remote" and "merge" configuration for the current branch
-as set by linkgit:git-branch[1] `--track`.
-
-Assume the following history exists and the current branch is
-"`master`":
-
-------------
-	  A---B---C master on origin
-	 /
-    D---E---F---G master
-------------
-
-Then "`git pull`" will fetch and replay the changes from the remote
-`master` branch since it diverged from the local `master` (i.e., `E`)
-until its current commit (`C`) on top of `master` and record the
-result in a new commit along with the names of the two parent commits
-and a log message from the user describing the changes.
-
-------------
-	  A---B---C remotes/origin/master
-	 /         \
-    D---E---F---G---H master
-------------
-
-See linkgit:git-merge[1] for details, including how conflicts
-are presented and handled.
-
-In git 1.7.0 or later, to cancel a conflicting merge, use
-`git reset --merge`.  *Warning*: In older versions of git, running 'git pull'
+*Warning*: Running 'git pull' (actually, the underlying 'git merge')
 with uncommitted changes is discouraged: while possible, it leaves you
-in a state that may be hard to back out of in the case of a conflict.
-
-If any of the remote changes overlap with local uncommitted changes,
-the merge will be automatically cancelled and the work tree untouched.
-It is generally best to get any local changes in working order before
-pulling or stash them away with linkgit:git-stash[1].
+in a state that is hard to back out of in the case of a conflict.
 
 OPTIONS
 -------
 
-Options meant for 'git pull' itself and the underlying 'git merge'
-must be given before the options meant for 'git fetch'.
-
--q::
---quiet::
-	This is passed to both underlying git-fetch to squelch reporting of
-	during transfer, and underlying git-merge to squelch output during
-	merging.
-
--v::
---verbose::
-	Pass --verbose to git-fetch and git-merge.
-
 Options related to merging
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 

Documentation/git-push.txt

@@ -41,7 +41,7 @@ OPTIONS[[OPTIONS]]
 +
 The <src> is often the name of the branch you would want to push, but
 it can be any arbitrary "SHA-1 expression", such as `master~4` or
-`HEAD` (see linkgit:gitrevisions[1]).
+`HEAD` (see linkgit:git-rev-parse[1]).
 +
 The <dst> tells which ref on the remote side is updated with this
 push. Arbitrary expressions cannot be used here, an actual ref must
@@ -146,21 +146,14 @@ useful if you write an alias or script around 'git push'.
 	receiver share many of the same objects in common. The default is
 	\--thin.
 
--q::
---quiet::
-	Suppress all output, including the listing of updated refs,
-	unless an error occurs. Progress is not reported to the standard
-	error stream.
-
 -v::
 --verbose::
 	Run verbosely.
 
---progress::
-	Progress status is reported on the standard error stream
-	by default when it is attached to a terminal, unless -q
-	is specified. This flag forces progress status even if the
-	standard error stream is not directed to a terminal.
+-q::
+--quiet::
+	Suppress all output, including the listing of updated refs,
+	unless an error occurs.
 
 include::urls-remotes.txt[]
 
@@ -200,29 +193,16 @@ summary::
 	For a successfully pushed ref, the summary shows the old and new
 	values of the ref in a form suitable for using as an argument to
 	`git log` (this is `<old>..<new>` in most cases, and
-	`<old>\...<new>` for forced non-fast-forward updates).
-+
-For a failed update, more details are given:
-+
---
-rejected::
-	Git did not try to send the ref at all, typically because it
-	is not a fast-forward and you did not force the update.
-
-remote rejected::
-	The remote end refused the update.  Usually caused by a hook
-	on the remote side, or because the remote repository has one
-	of the following safety options in effect:
-	`receive.denyCurrentBranch` (for pushes to the checked out
-	branch), `receive.denyNonFastForwards` (for forced
-	non-fast-forward updates), `receive.denyDeletes` or
-	`receive.denyDeleteCurrent`.  See linkgit:git-config[1].
-
-remote failure::
-	The remote end did not report the successful update of the ref,
-	perhaps because of a temporary error on the remote side, a
-	break in the network connection, or other transient error.
---
+	`<old>...<new>` for forced non-fast-forward updates). For a
+	failed update, more details are given for the failure.
+	The string `rejected` indicates that git did not try to send the
+	ref at all (typically because it is not a fast-forward). The
+	string `remote rejected` indicates that the remote end refused
+	the update; this rejection is typically caused by a hook on the
+	remote side. The string `remote failure` indicates that the
+	remote end did not report the successful update of the ref
+	(perhaps because of a temporary error on the remote side, a
+	break in the network connection, or other transient error).
 
 from::
 	The name of the local ref being pushed, minus its

Documentation/git-read-tree.txt

@@ -412,13 +412,6 @@ turn `core.sparseCheckout` on in order to have sparse checkout
 support.
 
 
-BUGS
-----
-In order to match a directory with $GIT_DIR/info/sparse-checkout,
-trailing slash must be used. The form without trailing slash, while
-works with .gitignore, does not work with sparse checkout.
-
-
 SEE ALSO
 --------
 linkgit:git-write-tree[1]; linkgit:git-ls-files[1];

Documentation/git-rebase.txt

@@ -199,9 +199,6 @@ rebase.stat::
 	Whether to show a diffstat of what changed upstream since the last
 	rebase. False by default.
 
-rebase.autosquash::
-	If set to true enable '--autosquash' option by default.
-
 OPTIONS
 -------
 <newbase>::
@@ -209,10 +206,6 @@ OPTIONS
 	--onto option is not specified, the starting point is
 	<upstream>.  May be any valid commit, and not just an
 	existing branch name.
-+
-As a special case, you may use "A\...B" as a shortcut for the
-merge base of A and B if there is exactly one merge base. You can
-leave out at most one of A and B, in which case it defaults to HEAD.
 
 <upstream>::
 	Upstream branch to compare against.  May be any valid commit,
@@ -253,13 +246,6 @@ on top of the <upstream> branch using the given strategy, using
 the 'ours' strategy simply discards all patches from the <branch>,
 which makes little sense.
 
--X <strategy-option>::
---strategy-option=<strategy-option>::
-	Pass the <strategy-option> through to the merge strategy.
-	This implies `\--merge` and, if no strategy has been
-	specified, `-s recursive`.  Note the reversal of 'ours' and
-	'theirs' as noted in above for the `-m` option.
-
 -q::
 --quiet::
 	Be quiet. Implies --no-stat.
@@ -288,16 +274,9 @@ which makes little sense.
 -f::
 --force-rebase::
 	Force the rebase even if the current branch is a descendant
-	of the commit you are rebasing onto.  Normally non-interactive rebase will
+	of the commit you are rebasing onto.  Normally the command will
 	exit with the message "Current branch is up to date" in such a
 	situation.
-	Incompatible with the --interactive option.
-+
-You may find this (or --no-ff with an interactive rebase) helpful after
-reverting a topic branch merge, as this option recreates the topic branch with
-fresh commits so it can be remerged successfully without needing to "revert
-the reversion" (see the
-link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details).
 
 --ignore-whitespace::
 --whitespace=<option>::
@@ -309,7 +288,6 @@ link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details).
 --ignore-date::
 	These flags are passed to 'git am' to easily change the dates
 	of the rebased commits (see linkgit:git-am[1]).
-	Incompatible with the --interactive option.
 
 -i::
 --interactive::
@@ -320,11 +298,6 @@ link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details).
 -p::
 --preserve-merges::
 	Instead of ignoring merges, try to recreate them.
-+
-This uses the `--interactive` machinery internally, but combining it
-with the `--interactive` option explicitly is generally not a good
-idea unless you know what you are doing (see BUGS below).
-
 
 --root::
 	Rebase all commits reachable from <branch>, instead of
@@ -336,7 +309,6 @@ idea unless you know what you are doing (see BUGS below).
 	instead.
 
 --autosquash::
---no-autosquash::
 	When the commit log message begins with "squash! ..." (or
 	"fixup! ..."), and there is a commit whose title begins with
 	the same ..., automatically modify the todo list of rebase -i
@@ -344,23 +316,7 @@ idea unless you know what you are doing (see BUGS below).
 	commit to be modified, and change the action of the moved
 	commit from `pick` to `squash` (or `fixup`).
 +
-This option is only valid when the '--interactive' option is used.
-+
-If the '--autosquash' option is enabled by default using the
-configuration variable `rebase.autosquash`, this option can be
-used to override and disable this setting.
-
---no-ff::
-	With --interactive, cherry-pick all rebased commits instead of
-	fast-forwarding over the unchanged ones.  This ensures that the
-	entire history of the rebased branch is composed of new commits.
-+
-Without --interactive, this is a synonym for --force-rebase.
-+
-You may find this helpful after reverting a topic branch merge, as this option
-recreates the topic branch with fresh commits so it can be remerged
-successfully without needing to "revert the reversion" (see the
-link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details).
+This option is only valid when '--interactive' option is used.
 
 include::merge-strategies.txt[]
 
@@ -474,30 +430,6 @@ sure that the current HEAD is "B", and call
 $ git rebase -i -p --onto Q O
 -----------------------------
 
-Reordering and editing commits usually creates untested intermediate
-steps.  You may want to check that your history editing did not break
-anything by running a test, or at least recompiling at intermediate
-points in history by using the "exec" command (shortcut "x").  You may
-do so by creating a todo list like this one:
-
--------------------------------------------
-pick deadbee Implement feature XXX
-fixup f1a5c00 Fix to feature XXX
-exec make
-pick c0ffeee The oneline of the next commit
-edit deadbab The oneline of the commit after
-exec cd subdir; make test
-...
--------------------------------------------
-
-The interactive rebase will stop when a command fails (i.e. exits with
-non-0 status) to give you an opportunity to fix the problem. You can
-continue with `git rebase --continue`.
-
-The "exec" command launches the command in a shell (the one specified
-in `$SHELL`, or the default shell if `$SHELL` is not set), so you can
-use shell features (like "cd", ">", ";" ...). The command is run from
-the root of the working tree.
 
 SPLITTING COMMITS
 -----------------
@@ -655,28 +587,6 @@ The ripple effect of a "hard case" recovery is especially bad:
 case" recovery too!
 
 
-BUGS
-----
-The todo list presented by `--preserve-merges --interactive` does not
-represent the topology of the revision graph.  Editing commits and
-rewording their commit messages should work fine, but attempts to
-reorder commits tend to produce counterintuitive results.
-
-For example, an attempt to rearrange
-------------
-1 --- 2 --- 3 --- 4 --- 5
-------------
-to
-------------
-1 --- 2 --- 4 --- 3 --- 5
-------------
-by moving the "pick 4" line will result in the following history:
-------------
-	3
-       /
-1 --- 2 --- 4 --- 5
-------------
-
 Authors
 ------
 Written by Junio C Hamano <gitster@pobox.com> and

Documentation/git-reflog.txt

@@ -40,7 +40,7 @@ see linkgit:git-log[1].
 The reflog is useful in various git commands, to specify the old value
 of a reference. For example, `HEAD@\{2\}` means "where HEAD used to be
 two moves ago", `master@\{one.week.ago\}` means "where master used to
-point to one week ago", and so on. See linkgit:gitrevisions[1] for
+point to one week ago", and so on. See linkgit:git-rev-parse[1] for
 more details.
 
 To delete single entries from the reflog, use the subcommand "delete"

Documentation/git-relink.txt

@@ -7,7 +7,7 @@ git-relink - Hardlink common objects in local repositories
 
 SYNOPSIS
 --------
-'git relink' [--safe] <dir> [<dir>]* <master_dir>
+'git relink' [--safe] <dir> [<dir>]\* <master_dir>
 
 DESCRIPTION
 -----------

Documentation/git-remote-helpers.txt

@@ -3,69 +3,20 @@ git-remote-helpers(1)
 
 NAME
 ----
-git-remote-helpers - Helper programs to interact with remote repositories
+git-remote-helpers - Helper programs for interoperation with remote git
 
 SYNOPSIS
 --------
-'git remote-<transport>' <repository> [<URL>]
+'git remote-<transport>' <remote>
 
 DESCRIPTION
 -----------
 
-Remote helper programs are normally not used directly by end users,
-but they are invoked by git when it needs to interact with remote
-repositories git does not support natively.  A given helper will
-implement a subset of the capabilities documented here. When git
-needs to interact with a repository using a remote helper, it spawns
-the helper as an independent process, sends commands to the helper's
-standard input, and expects results from the helper's standard
-output. Because a remote helper runs as an independent process from
-git, there is no need to re-link git to add a new helper, nor any
-need to link the helper with the implementation of git.
-
-Every helper must support the "capabilities" command, which git will
-use to determine what other commands the helper will accept.  Other
-commands generally concern facilities like discovering and updating
-remote refs, transporting objects between the object database and
-the remote repository, and updating the local object store.
-
-Helpers supporting the 'fetch' capability can discover refs from the
-remote repository and transfer objects reachable from those refs to
-the local object store. Helpers supporting the 'push' capability can
-transfer local objects to the remote repository and update remote refs.
-
-Git comes with a "curl" family of remote helpers, that handle various
-transport protocols, such as 'git-remote-http', 'git-remote-https',
-'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities
-'fetch', 'option', and 'push'.
-
-INVOCATION
-----------
-
-Remote helper programs are invoked with one or (optionally) two
-arguments. The first argument specifies a remote repository as in git;
-it is either the name of a configured remote or a URL. The second
-argument specifies a URL; it is usually of the form
-'<transport>://<address>', but any arbitrary string is possible.
-
-When git encounters a URL of the form '<transport>://<address>', where
-'<transport>' is a protocol that it cannot handle natively, it
-automatically invokes 'git remote-<transport>' with the full URL as
-the second argument. If such a URL is encountered directly on the
-command line, the first argument is the same as the second, and if it
-is encountered in a configured remote, the first argument is the name
-of that remote.
-
-A URL of the form '<transport>::<address>' explicitly instructs git to
-invoke 'git remote-<transport>' with '<address>' as the second
-argument. If such a URL is encountered directly on the command line,
-the first argument is '<address>', and if it is encountered in a
-configured remote, the first argument is the name of that remote.
-
-Additionally, when a configured remote has 'remote.<name>.vcs' set to
-'<transport>', git explicitly invokes 'git remote-<transport>' with
-'<name>' as the first argument. If set, the second argument is
-'remote.<name>.url'; otherwise, the second argument is omitted.
+These programs are normally not used directly by end users, but are
+invoked by various git programs that interact with remote repositories
+when the repository they would operate on will be accessed using
+transport code not linked into the main git binary. Various particular
+helper programs will behave as documented here.
 
 COMMANDS
 --------
@@ -74,8 +25,8 @@ Commands are given by the caller on the helper's standard input, one per line.
 
 'capabilities'::
 	Lists the capabilities of the helper, one per line, ending
-	with a blank line. Each capability may be preceded with '*',
-	which marks them mandatory for git version using the remote
+	with a blank line. Each capability may be preceded with '*'.
+	This marks them mandatory for git version using the remote
 	helper to understand (unknown mandatory capability is fatal
 	error).
 
@@ -84,27 +35,27 @@ Commands are given by the caller on the helper's standard input, one per line.
 	[<attr> ...]". The value may be a hex sha1 hash, "@<dest>" for
 	a symref, or "?" to indicate that the helper could not get the
 	value of the ref. A space-separated list of attributes follows
-	the name; unrecognized attributes are ignored. The list ends
-	with a blank line.
+	the name; unrecognized attributes are ignored. After the
+	complete list, outputs a blank line.
 +
 If 'push' is supported this may be called as 'list for-push'
 to obtain the current refs prior to sending one or more 'push'
 commands to the helper.
 
 'option' <name> <value>::
-	Sets the transport helper option <name> to <value>.  Outputs a
+	Set the transport helper option <name> to <value>.  Outputs a
 	single line containing one of 'ok' (option successfully set),
 	'unsupported' (option not recognized) or 'error <msg>'
-	(option <name> is supported but <value> is not valid
+	(option <name> is supported but <value> is not correct
 	for it).  Options should be set before other commands,
-	and may influence the behavior of those commands.
+	and may how those commands behave.
 +
 Supported if the helper has the "option" capability.
 
 'fetch' <sha1> <name>::
 	Fetches the given object, writing the necessary objects
 	to the database.  Fetch commands are sent in a batch, one
-	per line, terminated with a blank line.
+	per line, and the batch is terminated with a blank line.
 	Outputs a single blank line when all fetch commands in the
 	same batch are complete. Only objects which were reported
 	in the ref list with a sha1 may be fetched this way.
@@ -116,7 +67,7 @@ suitably updated.
 Supported if the helper has the "fetch" capability.
 
 'push' +<src>:<dst>::
-	Pushes the given local <src> commit or branch to the
+	Pushes the given <src> commit or branch locally to the
 	remote branch described by <dst>.  A batch sequence of
 	one or more push commands is terminated with a blank line.
 +
@@ -140,9 +91,6 @@ Supported if the helper has the "push" capability.
 	by applying the refspecs from the "refspec" capability to the
 	name of the ref.
 +
-Especially useful for interoperability with a foreign versioning
-system.
-+
 Supported if the helper has the "import" capability.
 
 'connect' <service>::
@@ -171,11 +119,16 @@ CAPABILITIES
 ------------
 
 'fetch'::
+	This helper supports the 'fetch' command.
+
 'option'::
+	This helper supports the option command.
+
 'push'::
+	This helper supports the 'push' command.
+
 'import'::
-'connect'::
-	This helper supports the corresponding command with the same name.
+	This helper supports the 'import' command.
 
 'refspec' 'spec'::
 	When using the import command, expect the source ref to have
@@ -187,6 +140,9 @@ CAPABILITIES
 	all, it must cover all refs reported by the list command; if
 	it is not used, it is effectively "*:*"
 
+'connect'::
+	This helper supports the 'connect' command.
+
 REF LIST ATTRIBUTES
 -------------------
 
@@ -202,19 +158,19 @@ REF LIST ATTRIBUTES
 OPTIONS
 -------
 'option verbosity' <N>::
-	Changes the verbosity of messages displayed by the helper.
-	A value of 0 for N means that processes operate
-	quietly, and the helper produces only error output.
-	1 is the default level of verbosity, and higher values
+	Change the level of messages displayed by the helper.
+	When N is 0 the end-user has asked the process to be
+	quiet, and the helper should produce only error output.
+	N of 1 is the default level of verbosity, higher values
 	of N correspond to the number of -v flags passed on the
 	command line.
 
 'option progress' \{'true'|'false'\}::
-	Enables (or disables) progress messages displayed by the
+	Enable (or disable) progress messages displayed by the
 	transport helper during a command.
 
 'option depth' <depth>::
-	Deepens the history of a shallow repository.
+	Deepen the history of a shallow repository.
 
 'option followtags' \{'true'|'false'\}::
 	If enabled the helper should automatically fetch annotated
@@ -230,15 +186,11 @@ OPTIONS
 	helpers this only applies to the 'push', if supported.
 
 'option servpath <c-style-quoted-path>'::
-	Sets service path (--upload-pack, --receive-pack etc.) for
-	next connect. Remote helper may support this option, but
-	must not rely on this option being set before
+	Set service path (--upload-pack, --receive-pack etc.) for
+	next connect. Remote helper MAY support this option. Remote
+	helper MUST NOT rely on this option being set before
 	connect request occurs.
 
-SEE ALSO
---------
-linkgit:git-remote[1]
-
 Documentation
 -------------
 Documentation by Daniel Barkalow and Ilari Liusvaara

Documentation/git-remote.txt

@@ -10,11 +10,10 @@ SYNOPSIS
 --------
 [verse]
 'git remote' [-v | --verbose]
-'git remote add' [-t <branch>] [-m <master>] [-f] [--tags|--no-tags] [--mirror] <name> <url>
+'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
 'git remote rename' <old> <new>
 'git remote rm' <name>
 'git remote set-head' <name> (-a | -d | <branch>)
-'git remote set-branches' <name> [--add] <branch>...
 'git remote set-url' [--push] <name> <newurl> [<oldurl>]
 'git remote set-url --add' [--push] <name> <newurl>
 'git remote set-url --delete' [--push] <name> <url>
@@ -52,12 +51,6 @@ update remote-tracking branches <name>/<branch>.
 With `-f` option, `git fetch <name>` is run immediately after
 the remote information is set up.
 +
-With `--tags` option, `git fetch <name>` imports every tag from the
-remote repository.
-+
-With `--no-tags` option, `git fetch <name>` does not import tags from
-the remote repository.
-+
 With `-t <branch>` option, instead of the default glob
 refspec for the remote to track all branches under
 `$GIT_DIR/remotes/<name>/`, a refspec to track only `<branch>`
@@ -111,18 +104,6 @@ remote set-head origin master" will set `$GIT_DIR/refs/remotes/origin/HEAD` to
 `refs/remotes/origin/master` already exists; if not it must be fetched first.
 +
 
-'set-branches'::
-
-Changes the list of branches tracked by the named remote.
-This can be used to track a subset of the available remote branches
-after the initial setup for a remote.
-+
-The named branches will be interpreted as if specified with the
-`-t` option on the 'git remote add' command line.
-+
-With `--add`, instead of replacing the list of currently tracked
-branches, adds to that list.
-
 'set-url'::
 
 Changes URL remote points to. Sets first URL remote points to matching

Documentation/git-rerere.txt

@@ -7,7 +7,7 @@ git-rerere - Reuse recorded resolution of conflicted merges
 
 SYNOPSIS
 --------
-'git rerere' ['clear'|'forget' [<pathspec>]|'diff'|'status'|'gc']
+'git rerere' ['clear'|'diff'|'status'|'gc']
 
 DESCRIPTION
 -----------
@@ -40,11 +40,6 @@ This resets the metadata used by rerere if a merge resolution is to be
 aborted.  Calling 'git am [--skip|--abort]' or 'git rebase [--skip|--abort]'
 will automatically invoke this command.
 
-'forget' <pathspec>::
-
-This resets the conflict resolutions which rerere has recorded for the current
-conflict in <pathspec>.  The <pathspec> is optional.
-
 'diff'::
 
 This displays diffs for the current state of the resolution.  It is

Documentation/git-reset.txt

@@ -8,50 +8,40 @@ git-reset - Reset current HEAD to the specified state
 SYNOPSIS
 --------
 [verse]
+'git reset' [--mixed | --soft | --hard | --merge] [-q] [<commit>]
 'git reset' [-q] [<commit>] [--] <paths>...
 'git reset' --patch [<commit>] [--] [<paths>...]
-'git reset' [--soft | --mixed | --hard | --merge | --keep] [-q] [<commit>]
 
 DESCRIPTION
 -----------
-In the first and second form, copy entries from <commit> to the index.
-In the third form, set the current branch to <commit>, optionally
-modifying index and worktree to match.  The <commit> defaults to HEAD
-in all forms.
+Sets the current head to the specified commit and optionally resets the
+index and working tree to match.
 
-'git reset' [-q] [<commit>] [--] <paths>...::
-	This form resets the index entries for all <paths> to their
-	state at the <commit>.  (It does not affect the worktree, nor
-	the current branch.)
-+
-This means that `git reset <paths>` is the opposite of `git add
-<paths>`.
+This command is useful if you notice some small error in a recent
+commit (or set of commits) and want to redo that part without showing
+the undo in the history.
 
-'git reset' --patch|-p [<commit>] [--] [<paths>...]::
-	Interactively select hunks in the difference between the index
-	and <commit> (defaults to HEAD).  The chosen hunks are applied
-	in reverse to the index.
-+
-This means that `git reset -p` is the opposite of `git add -p` (see
-linkgit:git-add[1]).
+If you want to undo a commit other than the latest on a branch,
+linkgit:git-revert[1] is your friend.
+
+The second and third forms with 'paths' and/or --patch are used to
+revert selected paths in the index from a given commit, without moving
+HEAD.
+
+
+OPTIONS
+-------
+--mixed::
+	Resets the index but not the working tree (i.e., the changed files
+	are preserved but not marked for commit) and reports what has not
+	been updated. This is the default action.
 
-'git reset' [--<mode>] [<commit>]::
-	This form points the current branch to <commit> and then
-	updates index and working tree according to <mode>, which must
-	be one of the following:
-+
---
 --soft::
 	Does not touch the index file nor the working tree at all, but
 	requires them to be in a good order. This leaves all your changed
 	files "Changes to be committed", as 'git status' would
 	put it.
 
---mixed::
-	Resets the index but not the working tree (i.e., the changed files
-	are preserved but not marked for commit) and reports what has not
-	been updated. This is the default action.
-
 --hard::
 	Matches the working tree and index to that of the tree being
 	switched to. Any changes to tracked files in the working tree
@@ -62,30 +52,161 @@ linkgit:git-add[1]).
 	and updates the files that are different between the named commit
 	and the current commit in the working tree.
 
---keep::
-	Reset the index to the given commit, keeping local changes in
-	the working tree since the current commit, while updating
-	working tree files without local changes to what appears in
-	the given commit.  If a file that is different between the
-	current commit and the given commit has local changes, reset
-	is aborted.
---
-
-If you want to undo a commit other than the latest on a branch,
-linkgit:git-revert[1] is your friend.
-
-
-OPTIONS
--------
+-p::
+--patch::
+	Interactively select hunks in the difference between the index
+	and <commit> (defaults to HEAD).  The chosen hunks are applied
+	in reverse to the index.
++
+This means that `git reset -p` is the opposite of `git add -p` (see
+linkgit:git-add[1]).
 
 -q::
 --quiet::
 	Be quiet, only report errors.
 
+<commit>::
+	Commit to make the current HEAD. If not given defaults to HEAD.
 
-EXAMPLES
+DISCUSSION
+----------
+
+The tables below show what happens when running:
+
+----------
+git reset --option target
+----------
+
+to reset the HEAD to another commit (`target`) with the different
+reset options depending on the state of the files.
+
+In these tables, A, B, C and D are some different states of a
+file. For example, the first line of the first table means that if a
+file is in state A in the working tree, in state B in the index, in
+state C in HEAD and in state D in the target, then "git reset --soft
+target" will put the file in state A in the working tree, in state B
+in the index and in state D in HEAD.
+
+      working index HEAD target         working index HEAD
+      ----------------------------------------------------
+       A       B     C    D     --soft   A       B     D
+				--mixed  A       D     D
+				--hard   D       D     D
+				--merge (disallowed)
+
+      working index HEAD target         working index HEAD
+      ----------------------------------------------------
+       A       B     C    C     --soft   A       B     C
+				--mixed  A       C     C
+				--hard   C       C     C
+				--merge (disallowed)
+
+      working index HEAD target         working index HEAD
+      ----------------------------------------------------
+       B       B     C    D     --soft   B       B     D
+				--mixed  B       D     D
+				--hard   D       D     D
+				--merge  D       D     D
+
+      working index HEAD target         working index HEAD
+      ----------------------------------------------------
+       B       B     C    C     --soft   B       B     C
+				--mixed  B       C     C
+				--hard   C       C     C
+				--merge  C       C     C
+
+      working index HEAD target         working index HEAD
+      ----------------------------------------------------
+       B       C     C    D     --soft   B       C     D
+				--mixed  B       D     D
+				--hard   D       D     D
+				--merge (disallowed)
+
+      working index HEAD target         working index HEAD
+      ----------------------------------------------------
+       B       C     C    C     --soft   B       C     C
+				--mixed  B       C     C
+				--hard   C       C     C
+				--merge  B       C     C
+
+"reset --merge" is meant to be used when resetting out of a conflicted
+merge. Any mergy operation guarantees that the work tree file that is
+involved in the merge does not have local change wrt the index before
+it starts, and that it writes the result out to the work tree. So if
+we see some difference between the index and the target and also
+between the index and the work tree, then it means that we are not
+resetting out from a state that a mergy operation left after failing
+with a conflict. That is why we disallow --merge option in this case.
+
+The following tables show what happens when there are unmerged
+entries:
+
+      working index HEAD target         working index HEAD
+      ----------------------------------------------------
+       X       U     A    B     --soft  (disallowed)
+				--mixed  X       B     B
+				--hard   B       B     B
+				--merge  B       B     B
+
+      working index HEAD target         working index HEAD
+      ----------------------------------------------------
+       X       U     A    A     --soft  (disallowed)
+				--mixed  X       A     A
+				--hard   A       A     A
+				--merge  A       A     A
+
+X means any state and U means an unmerged index.
+
+Examples
 --------
 
+Undo a commit and redo::
++
+------------
+$ git commit ...
+$ git reset --soft HEAD^      <1>
+$ edit                        <2>
+$ git commit -a -c ORIG_HEAD  <3>
+------------
++
+<1> This is most often done when you remembered what you
+just committed is incomplete, or you misspelled your commit
+message, or both.  Leaves working tree as it was before "reset".
+<2> Make corrections to working tree files.
+<3> "reset" copies the old head to .git/ORIG_HEAD; redo the
+commit by starting with its log message.  If you do not need to
+edit the message further, you can give -C option instead.
++
+See also the --amend option to linkgit:git-commit[1].
+
+Undo commits permanently::
++
+------------
+$ git commit ...
+$ git reset --hard HEAD~3   <1>
+------------
++
+<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad
+and you do not want to ever see them again.  Do *not* do this if
+you have already given these commits to somebody else.  (See the
+"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for
+the implications of doing so.)
+
+Undo a commit, making it a topic branch::
++
+------------
+$ git branch topic/wip     <1>
+$ git reset --hard HEAD~3  <2>
+$ git checkout topic/wip   <3>
+------------
++
+<1> You have made some commits, but realize they were premature
+to be in the "master" branch.  You want to continue polishing
+them in a topic branch, so create "topic/wip" branch off of the
+current HEAD.
+<2> Rewind the master branch to get rid of those three commits.
+<3> Switch to "topic/wip" branch and keep working.
+
 Undo add::
 +
 ------------
@@ -109,53 +230,6 @@ remain there.
 <4> Then you can pull and merge, leaving frotz.c and filfre.c
 changes still in the working tree.
 
-Undo a commit and redo::
-+
-------------
-$ git commit ...
-$ git reset --soft HEAD^      <1>
-$ edit                        <2>
-$ git commit -a -c ORIG_HEAD  <3>
-------------
-+
-<1> This is most often done when you remembered what you
-just committed is incomplete, or you misspelled your commit
-message, or both.  Leaves working tree as it was before "reset".
-<2> Make corrections to working tree files.
-<3> "reset" copies the old head to .git/ORIG_HEAD; redo the
-commit by starting with its log message.  If you do not need to
-edit the message further, you can give -C option instead.
-+
-See also the --amend option to linkgit:git-commit[1].
-
-Undo a commit, making it a topic branch::
-+
-------------
-$ git branch topic/wip     <1>
-$ git reset --hard HEAD~3  <2>
-$ git checkout topic/wip   <3>
-------------
-+
-<1> You have made some commits, but realize they were premature
-to be in the "master" branch.  You want to continue polishing
-them in a topic branch, so create "topic/wip" branch off of the
-current HEAD.
-<2> Rewind the master branch to get rid of those three commits.
-<3> Switch to "topic/wip" branch and keep working.
-
-Undo commits permanently::
-+
-------------
-$ git commit ...
-$ git reset --hard HEAD~3   <1>
-------------
-+
-<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad
-and you do not want to ever see them again.  Do *not* do this if
-you have already given these commits to somebody else.  (See the
-"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for
-the implications of doing so.)
-
 Undo a merge or pull::
 +
 ------------
@@ -251,140 +325,6 @@ $ git add frotz.c                           <3>
 <2> This commits all other changes in the index.
 <3> Adds the file to the index again.
 
-Keep changes in working tree while discarding some previous commits::
-+
-Suppose you are working on something and you commit it, and then you
-continue working a bit more, but now you think that what you have in
-your working tree should be in another branch that has nothing to do
-with what you committed previously. You can start a new branch and
-reset it while keeping the changes in your work tree.
-+
-------------
-$ git tag start
-$ git checkout -b branch1
-$ edit
-$ git commit ...                            <1>
-$ edit
-$ git checkout -b branch2                   <2>
-$ git reset --keep start                    <3>
-------------
-+
-<1> This commits your first edits in branch1.
-<2> In the ideal world, you could have realized that the earlier
-    commit did not belong to the new topic when you created and switched
-    to branch2 (i.e. "git checkout -b branch2 start"), but nobody is
-    perfect.
-<3> But you can use "reset --keep" to remove the unwanted commit after
-    you switched to "branch2".
-
-
-DISCUSSION
-----------
-
-The tables below show what happens when running:
-
-----------
-git reset --option target
-----------
-
-to reset the HEAD to another commit (`target`) with the different
-reset options depending on the state of the files.
-
-In these tables, A, B, C and D are some different states of a
-file. For example, the first line of the first table means that if a
-file is in state A in the working tree, in state B in the index, in
-state C in HEAD and in state D in the target, then "git reset --soft
-target" will put the file in state A in the working tree, in state B
-in the index and in state D in HEAD.
-
-      working index HEAD target         working index HEAD
-      ----------------------------------------------------
-       A       B     C    D     --soft   A       B     D
-				--mixed  A       D     D
-				--hard   D       D     D
-				--merge (disallowed)
-				--keep  (disallowed)
-
-      working index HEAD target         working index HEAD
-      ----------------------------------------------------
-       A       B     C    C     --soft   A       B     C
-				--mixed  A       C     C
-				--hard   C       C     C
-				--merge (disallowed)
-				--keep   A       C     C
-
-      working index HEAD target         working index HEAD
-      ----------------------------------------------------
-       B       B     C    D     --soft   B       B     D
-				--mixed  B       D     D
-				--hard   D       D     D
-				--merge  D       D     D
-				--keep  (disallowed)
-
-      working index HEAD target         working index HEAD
-      ----------------------------------------------------
-       B       B     C    C     --soft   B       B     C
-				--mixed  B       C     C
-				--hard   C       C     C
-				--merge  C       C     C
-				--keep   B       C     C
-
-      working index HEAD target         working index HEAD
-      ----------------------------------------------------
-       B       C     C    D     --soft   B       C     D
-				--mixed  B       D     D
-				--hard   D       D     D
-				--merge (disallowed)
-				--keep  (disallowed)
-
-      working index HEAD target         working index HEAD
-      ----------------------------------------------------
-       B       C     C    C     --soft   B       C     C
-				--mixed  B       C     C
-				--hard   C       C     C
-				--merge  B       C     C
-				--keep   B       C     C
-
-"reset --merge" is meant to be used when resetting out of a conflicted
-merge. Any mergy operation guarantees that the work tree file that is
-involved in the merge does not have local change wrt the index before
-it starts, and that it writes the result out to the work tree. So if
-we see some difference between the index and the target and also
-between the index and the work tree, then it means that we are not
-resetting out from a state that a mergy operation left after failing
-with a conflict. That is why we disallow --merge option in this case.
-
-"reset --keep" is meant to be used when removing some of the last
-commits in the current branch while keeping changes in the working
-tree. If there could be conflicts between the changes in the commit we
-want to remove and the changes in the working tree we want to keep,
-the reset is disallowed. That's why it is disallowed if there are both
-changes between the working tree and HEAD, and between HEAD and the
-target. To be safe, it is also disallowed when there are unmerged
-entries.
-
-The following tables show what happens when there are unmerged
-entries:
-
-      working index HEAD target         working index HEAD
-      ----------------------------------------------------
-       X       U     A    B     --soft  (disallowed)
-				--mixed  X       B     B
-				--hard   B       B     B
-				--merge  B       B     B
-				--keep  (disallowed)
-
-      working index HEAD target         working index HEAD
-      ----------------------------------------------------
-       X       U     A    A     --soft  (disallowed)
-				--mixed  X       A     A
-				--hard   A       A     A
-				--merge  A       A     A
-				--keep  (disallowed)
-
-X means any state and U means an unmerged index.
-
-
 Author
 ------
 Written by Junio C Hamano <gitster@pobox.com> and Linus Torvalds <torvalds@osdl.org>

Documentation/git-rev-parse.txt

@@ -74,7 +74,7 @@ OPTIONS
 	properly quoted for consumption by shell.  Useful when
 	you expect your parameter to contain whitespaces and
 	newlines (e.g. when using pickaxe `-S` with
-	'git diff-{asterisk}'). In contrast to the `--sq-quote` option,
+	'git diff-\*'). In contrast to the `--sq-quote` option,
 	the command input is still interpreted as usual.
 
 --not::
@@ -112,15 +112,14 @@ OPTIONS
 +
 If a `pattern` is given, only refs matching the given shell glob are
 shown.  If the pattern does not contain a globbing character (`?`,
-`{asterisk}`, or `[`), it is turned into a prefix match by
-appending `/{asterisk}`.
+`\*`, or `[`), it is turned into a prefix match by appending `/\*`.
 
 --glob=pattern::
 	Show all refs matching the shell glob pattern `pattern`. If
 	the pattern does not start with `refs/`, this is automatically
 	prepended.  If the pattern does not contain a globbing
-	character (`?`, `{asterisk}`, or `[`), it is turned into a prefix
-	match by appending `/{asterisk}`.
+	character (`?`, `\*`, or `[`), it is turned into a prefix
+	match by appending `/\*`.
 
 --show-toplevel::
 	Show the absolute path of the top-level directory.
@@ -175,7 +174,202 @@ appending `/{asterisk}`.
 	Flags and parameters to be parsed.
 
 
-include::revisions.txt[]
+SPECIFYING REVISIONS
+--------------------
+
+A revision parameter typically, but not necessarily, names a
+commit object.  They use what is called an 'extended SHA1'
+syntax.  Here are various ways to spell object names.  The
+ones listed near the end of this list are to name trees and
+blobs contained in a commit.
+
+* The full SHA1 object name (40-byte hexadecimal string), or
+  a substring of such that is unique within the repository.
+  E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both
+  name the same commit object if there are no other object in
+  your repository whose object name starts with dae86e.
+
+* An output from 'git describe'; i.e. a closest tag, optionally
+  followed by a dash and a number of commits, followed by a dash, a
+  `g`, and an abbreviated object name.
+
+* A symbolic ref name.  E.g. 'master' typically means the commit
+  object referenced by refs/heads/master.  If you
+  happen to have both heads/master and tags/master, you can
+  explicitly say 'heads/master' to tell git which one you mean.
+  When ambiguous, a `<name>` is disambiguated by taking the
+  first match in the following rules:
+
+  . if `$GIT_DIR/<name>` exists, that is what you mean (this is usually
+    useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD` and `MERGE_HEAD`);
+
+  . otherwise, `refs/<name>` if exists;
+
+  . otherwise, `refs/tags/<name>` if exists;
+
+  . otherwise, `refs/heads/<name>` if exists;
+
+  . otherwise, `refs/remotes/<name>` if exists;
+
+  . otherwise, `refs/remotes/<name>/HEAD` if exists.
++
+HEAD names the commit your changes in the working tree is based on.
+FETCH_HEAD records the branch you fetched from a remote repository
+with your last 'git fetch' invocation.
+ORIG_HEAD is created by commands that moves your HEAD in a drastic
+way, to record the position of the HEAD before their operation, so that
+you can change the tip of the branch back to the state before you ran
+them easily.
+MERGE_HEAD records the commit(s) you are merging into your branch
+when you run 'git merge'.
++
+Note that any of the `refs/*` cases above may come either from
+the `$GIT_DIR/refs` directory or from the `$GIT_DIR/packed-refs` file.
+
+* A ref followed by the suffix '@' with a date specification
+  enclosed in a brace
+  pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1
+  second ago\}' or '\{1979-02-26 18:30:00\}') to specify the value
+  of the ref at a prior point in time.  This suffix may only be
+  used immediately following a ref name and the ref must have an
+  existing log ($GIT_DIR/logs/<ref>). Note that this looks up the state
+  of your *local* ref at a given time; e.g., what was in your local
+  `master` branch last week. If you want to look at commits made during
+  certain times, see `--since` and `--until`.
+
+* A ref followed by the suffix '@' with an ordinal specification
+  enclosed in a brace pair (e.g. '\{1\}', '\{15\}') to specify
+  the n-th prior value of that ref.  For example 'master@\{1\}'
+  is the immediate prior value of 'master' while 'master@\{5\}'
+  is the 5th prior value of 'master'. This suffix may only be used
+  immediately following a ref name and the ref must have an existing
+  log ($GIT_DIR/logs/<ref>).
+
+* You can use the '@' construct with an empty ref part to get at a
+  reflog of the current branch. For example, if you are on the
+  branch 'blabla', then '@\{1\}' means the same as 'blabla@\{1\}'.
+
+* The special construct '@\{-<n>\}' means the <n>th branch checked out
+  before the current one.
+
+* The suffix '@\{upstream\}' to a ref (short form 'ref@\{u\}') refers to
+  the branch the ref is set to build on top of.  Missing ref defaults
+  to the current branch.
+
+* A suffix '{caret}' to a revision parameter means the first parent of
+  that commit object.  '{caret}<n>' means the <n>th parent (i.e.
+  'rev{caret}'
+  is equivalent to 'rev{caret}1').  As a special rule,
+  'rev{caret}0' means the commit itself and is used when 'rev' is the
+  object name of a tag object that refers to a commit object.
+
+* A suffix '{tilde}<n>' to a revision parameter means the commit
+  object that is the <n>th generation grand-parent of the named
+  commit object, following only the first parent.  I.e. rev~3 is
+  equivalent to rev{caret}{caret}{caret} which is equivalent to
+  rev{caret}1{caret}1{caret}1.  See below for a illustration of
+  the usage of this form.
+
+* A suffix '{caret}' followed by an object type name enclosed in
+  brace pair (e.g. `v0.99.8{caret}\{commit\}`) means the object
+  could be a tag, and dereference the tag recursively until an
+  object of that type is found or the object cannot be
+  dereferenced anymore (in which case, barf).  `rev{caret}0`
+  introduced earlier is a short-hand for `rev{caret}\{commit\}`.
+
+* A suffix '{caret}' followed by an empty brace pair
+  (e.g. `v0.99.8{caret}\{\}`) means the object could be a tag,
+  and dereference the tag recursively until a non-tag object is
+  found.
+
+* A colon, followed by a slash, followed by a text: this names
+  a commit whose commit message starts with the specified text.
+  This name returns the youngest matching commit which is
+  reachable from any ref.  If the commit message starts with a
+  '!', you have to repeat that;  the special sequence ':/!',
+  followed by something else than '!' is reserved for now.
+
+* A suffix ':' followed by a path; this names the blob or tree
+  at the given path in the tree-ish object named by the part
+  before the colon.
+
+* A colon, optionally followed by a stage number (0 to 3) and a
+  colon, followed by a path; this names a blob object in the
+  index at the given path.  Missing stage number (and the colon
+  that follows it) names a stage 0 entry. During a merge, stage
+  1 is the common ancestor, stage 2 is the target branch's version
+  (typically the current branch), and stage 3 is the version from
+  the branch being merged.
+
+Here is an illustration, by Jon Loeliger.  Both commit nodes B
+and C are parents of commit node A.  Parent commits are ordered
+left-to-right.
+
+........................................
+G   H   I   J
+ \ /     \ /
+  D   E   F
+   \  |  / \
+    \ | /   |
+     \|/    |
+      B     C
+       \   /
+        \ /
+         A
+........................................
+
+    A =      = A^0
+    B = A^   = A^1     = A~1
+    C = A^2  = A^2
+    D = A^^  = A^1^1   = A~2
+    E = B^2  = A^^2
+    F = B^3  = A^^3
+    G = A^^^ = A^1^1^1 = A~3
+    H = D^2  = B^^2    = A^^^2  = A~2^2
+    I = F^   = B^3^    = A^^3^
+    J = F^2  = B^3^2   = A^^3^2
+
+
+SPECIFYING RANGES
+-----------------
+
+History traversing commands such as 'git log' operate on a set
+of commits, not just a single commit.  To these commands,
+specifying a single revision with the notation described in the
+previous section means the set of commits reachable from that
+commit, following the commit ancestry chain.
+
+To exclude commits reachable from a commit, a prefix `{caret}`
+notation is used.  E.g. `{caret}r1 r2` means commits reachable
+from `r2` but exclude the ones reachable from `r1`.
+
+This set operation appears so often that there is a shorthand
+for it.  When you have two commits `r1` and `r2` (named according
+to the syntax explained in SPECIFYING REVISIONS above), you can ask
+for commits that are reachable from r2 excluding those that are reachable
+from r1 by `{caret}r1 r2` and it can be written as `r1..r2`.
+
+A similar notation `r1\...r2` is called symmetric difference
+of `r1` and `r2` and is defined as
+`r1 r2 --not $(git merge-base --all r1 r2)`.
+It is the set of commits that are reachable from either one of
+`r1` or `r2` but not from both.
+
+Two other shorthands for naming a set that is formed by a commit
+and its parent commits exist.  The `r1{caret}@` notation means all
+parents of `r1`.  `r1{caret}!` includes commit `r1` but excludes
+all of its parents.
+
+Here are a handful of examples:
+
+   D                G H D
+   D F              G H I J D F
+   ^G D             H D
+   ^D B             E I J F B
+   B...C            G H D E B C
+   ^D B C           E I J F B C
+   C^@              I J F
+   F^! D            G H D F
 
 PARSEOPT
 --------
@@ -185,13 +379,10 @@ scripts the same facilities C builtins have. It works as an option normalizer
 (e.g. splits single switches aggregate values), a bit like `getopt(1)` does.
 
 It takes on the standard input the specification of the options to parse and
-understand, and echoes on the standard output a string suitable for `sh(1)` `eval`
+understand, and echoes on the standard output a line suitable for `sh(1)` `eval`
 to replace the arguments with normalized ones.  In case of error, it outputs
 usage on the standard error stream, and exits with code 129.
 
-Note: Make sure you quote the result when passing it to `eval`.  See
-below for an example.
-
 Input Format
 ~~~~~~~~~~~~
 
@@ -248,7 +439,7 @@ bar=      some cool option --bar with an argument
   An option group Header
 C?        option C with an optional argument"
 
-eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"
+eval `echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?`
 ------------
 
 SQ-QUOTE

Documentation/git-revert.txt

@@ -3,22 +3,20 @@ git-revert(1)
 
 NAME
 ----
-git-revert - Revert some existing commits
+git-revert - Revert an existing commit
 
 SYNOPSIS
 --------
-'git revert' [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>...
+'git revert' [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>
 
 DESCRIPTION
 -----------
+Given one existing commit, revert the change the patch introduces, and record a
+new commit that records it.  This requires your working tree to be clean (no
+modifications from the HEAD commit).
 
-Given one or more existing commits, revert the changes that the
-related patches introduce, and record some new commits that record
-them.  This requires your working tree to be clean (no modifications
-from the HEAD commit).
-
-Note: 'git revert' is used to record some new commits to reverse the
-effect of some earlier commits (often only a faulty one).  If you want to
+Note: 'git revert' is used to record a new commit to reverse the
+effect of an earlier commit (often a faulty one).  If you want to
 throw away all uncommitted changes in your working directory, you
 should see linkgit:git-reset[1], particularly the '--hard' option.  If
 you want to extract specific files as they were in another commit, you
@@ -28,13 +26,10 @@ both will discard uncommitted changes in your working directory.
 
 OPTIONS
 -------
-<commit>...::
-	Commits to revert.
+<commit>::
+	Commit to revert.
 	For a more complete list of ways to spell commit names, see
-	linkgit:gitrevisions[1].
-	Sets of commits can also be given but no traversal is done by
-	default, see linkgit:git-rev-list[1] and its '--no-walk'
-	option.
+	"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
 
 -e::
 --edit::
@@ -64,11 +59,11 @@ more details.
 
 -n::
 --no-commit::
-	Usually the command automatically creates some commits with
-	commit log messages stating which commits were
-	reverted.  This flag applies the changes necessary
-	to revert the named commits to your working tree
-	and the index, but does not make the commits.  In addition,
+	Usually the command automatically creates a commit with
+	a commit log message stating which commit was
+	reverted.  This flag applies the change necessary
+	to revert the named commit to your working tree
+	and the index, but does not make the commit.  In addition,
 	when this option is used, your index does not have to match
 	the HEAD commit.  The revert is done against the
 	beginning state of your index.
@@ -80,20 +75,6 @@ effect to your index in a row.
 --signoff::
 	Add Signed-off-by line at the end of the commit message.
 
-EXAMPLES
---------
-git revert HEAD~3::
-
-	Revert the changes specified by the fourth last commit in HEAD
-	and create a new commit with the reverted changes.
-
-git revert -n master\~5..master~2::
-
-	Revert the changes done by commits from the fifth last commit
-	in master (included) to the third last commit in master
-	(included), but do not create any commit with the reverted
-	changes. The revert only modifies the working tree and the
-	index.
 
 Author
 ------
@@ -103,10 +84,6 @@ Documentation
 --------------
 Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
 
-SEE ALSO
---------
-linkgit:git-cherry-pick[1]
-
 GIT
 ---
 Part of the linkgit:git[1] suite

Documentation/git-rm.txt

@@ -78,8 +78,7 @@ a file that you have not told git about does not remove that file.
 
 File globbing matches across directory boundaries.  Thus, given
 two directories `d` and `d2`, there is a difference between
-using `git rm {apostrophe}d{asterisk}{apostrophe}` and
-`git rm {apostrophe}d/{asterisk}{apostrophe}`, as the former will
+using `git rm \'d\*\'` and `git rm \'d/\*\'`, as the former will
 also remove all of directory `d2`.
 
 REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM
@@ -136,11 +135,11 @@ git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached
 
 EXAMPLES
 --------
-git rm Documentation/\*.txt::
-	Removes all `*.txt` files from the index that are under the
+git rm Documentation/\\*.txt::
+	Removes all `\*.txt` files from the index that are under the
 	`Documentation` directory and any of its subdirectories.
 +
-Note that the asterisk `*` is quoted from the shell in this
+Note that the asterisk `\*` is quoted from the shell in this
 example; this lets git, and not the shell, expand the pathnames
 of files and subdirectories under the `Documentation/` directory.
 

Documentation/git-send-email.txt

@@ -101,15 +101,6 @@ See the CONFIGURATION section for 'sendemail.multiedit'.
 +
 The --to option must be repeated for each user you want on the to list.
 
---8bit-encoding=<encoding>::
-	When encountering a non-ASCII message or subject that does not
-	declare its encoding, add headers/quoting to indicate it is
-	encoded in <encoding>.  Default is the value of the
-	'sendemail.assume8bitEncoding'; if that is unspecified, this
-	will be prompted for if any non-ASCII files are encountered.
-+
-Note that no attempts whatsoever are made to validate the encoding.
-
 
 Sending
 ~~~~~~~
@@ -128,13 +119,6 @@ Sending
 	value reverts to plain SMTP.  Default is the value of
 	'sendemail.smtpencryption'.
 
---smtp-domain=<FQDN>::
-	Specifies the Fully Qualified Domain Name (FQDN) used in the
-	HELO/EHLO command to the SMTP server.  Some servers require the
-	FQDN to match your IP address.  If not set, git send-email attempts
-	to determine your FQDN automatically.  Default is the value of
-	'sendemail.smtpdomain'.
-
 --smtp-pass[=<password>]::
 	Password for SMTP-AUTH. The argument is optional: If no
 	argument is specified, then the empty string is used as
@@ -316,21 +300,6 @@ sendemail.confirm::
 	in the previous section for the meaning of these values.
 
 
-Use gmail as the smtp server
-----------------------------
-
-Add the following section to the config file:
-
-	[sendemail]
-		smtpencryption = tls
-		smtpserver = smtp.gmail.com
-		smtpuser = yourname@gmail.com
-		smtpserverport = 587
-
-Note: the following perl modules are required
-      Net::SMTP::SSL, MIME::Base64 and Authen::SASL
-
-
 Author
 ------
 Written by Ryan Anderson <ryan@michonline.com>

Documentation/git-shortlog.txt

@@ -9,7 +9,7 @@ SYNOPSIS
 --------
 [verse]
 git log --pretty=short | 'git shortlog' [-h] [-n] [-s] [-e] [-w]
-'git shortlog' [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] <commit>...
+'git shortlog' [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] [<committish>...]
 
 DESCRIPTION
 -----------
@@ -19,11 +19,6 @@ the first line of the commit message will be shown.
 
 Additionally, "[PATCH]" will be stripped from the commit description.
 
-If no revisions are passed on the command line and either standard input
-is not a terminal or there is no current branch, 'git shortlog' will
-output a summary of the log read from standard input, without
-reference to the current repository.
-
 OPTIONS
 -------
 
@@ -44,14 +39,6 @@ OPTIONS
 --email::
 	Show the email address of each author.
 
---format[='<format>']::
-	Instead of the commit subject, use some other information to
-	describe each commit.  '<format>' can be any string accepted
-	by the `--format` option of 'git log', such as '{asterisk} [%h] %s'.
-	(See the "PRETTY FORMATS" section of linkgit:git-log[1].)
-
-	Each pretty-printed commit will be rewrapped before it is shown.
-
 -w[<width>[,<indent1>[,<indent2>]]]::
 	Linewrap the output by wrapping each line at `width`.  The first
 	line of each entry is indented by `indent1` spaces, and the second

Documentation/git-show-branch.txt

@@ -9,7 +9,7 @@ SYNOPSIS
 --------
 [verse]
 'git show-branch' [-a|--all] [-r|--remotes] [--topo-order | --date-order]
-		[--current] [--color[=<when>] | --no-color] [--sparse]
+		[--current] [--color | --no-color] [--sparse]
 		[--more=<n> | --list | --independent | --merge-base]
 		[--no-name | --sha1-name] [--topics]
 		[<rev> | <glob>]...
@@ -32,7 +32,7 @@ no <rev> nor <glob> is given on the command line.
 OPTIONS
 -------
 <rev>::
-	Arbitrary extended SHA1 expression (see linkgit:gitrevisions[1])
+	Arbitrary extended SHA1 expression (see linkgit:git-rev-parse[1])
 	that typically names a branch head or a tag.
 
 <glob>::
@@ -117,15 +117,13 @@ OPTIONS
 	When no explicit <ref> parameter is given, it defaults to the
 	current branch (or `HEAD` if it is detached).
 
---color[=<when>]::
+--color::
 	Color the status sign (one of these: `*` `!` `+` `-`) of each commit
 	corresponding to the branch it's in.
-	The value must be always (the default), never, or auto.
 
 --no-color::
 	Turn off colored output, even when the configuration file gives the
 	default to color output.
-	Same as `--color=never`.
 
 Note that --more, --list, --independent and --merge-base options
 are mutually exclusive.
@@ -168,10 +166,10 @@ $ git show-branch master fixes mhf
 ------------------------------------------------
 
 These three branches all forked from a common commit, [master],
-whose commit message is "Add {apostrophe}git show-branch{apostrophe}".
-The "fixes" branch adds one commit "Introduce "reset type" flag to
-"git reset"". The "mhf" branch adds many other commits.
-The current branch is "master".
+whose commit message is "Add \'git show-branch\'". The "fixes"
+branch adds one commit "Introduce "reset type" flag to "git reset"".
+The "mhf" branch adds many other commits. The current branch
+is "master".
 
 
 EXAMPLE

Documentation/git-show-ref.txt

@@ -73,8 +73,8 @@ OPTIONS
 --exclude-existing[=<pattern>]::
 
 	Make 'git show-ref' act as a filter that reads refs from stdin of the
-	form "^(?:<anything>\s)?<refname>(?:{backslash}{caret}\{\})?$"
-	and performs the following actions on each:
+	form "^(?:<anything>\s)?<refname>(?:\^\{\})?$" and performs the
+	following actions on each:
 	(1) strip "^{}" at the end of line if any;
 	(2) ignore if pattern is provided and does not head-match refname;
 	(3) warn if refname is not a well-formed refname and skip;
@@ -163,15 +163,9 @@ flag, so you can do
 
 to get a listing of all tags together with what they dereference.
 
-FILES
------
-`.git/refs/*`, `.git/packed-refs`
-
 SEE ALSO
 --------
-linkgit:git-ls-remote[1],
-linkgit:git-update-ref[1],
-linkgit:gitrepository-layout[5]
+linkgit:git-ls-remote[1]
 
 AUTHORS
 -------

Documentation/git-show.txt

@@ -36,7 +36,7 @@ OPTIONS
 <object>...::
 	The names of objects to show.
 	For a more complete list of ways to spell object names, see
-	"SPECIFYING REVISIONS" section in linkgit:gitrevisions[1].
+	"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
 
 include::pretty-options.txt[]
 

Documentation/git-stash.txt

@@ -104,22 +104,18 @@ tree's changes, but also the index's ones. However, this can fail, when you
 have conflicts (which are stored in the index, where you therefore can no
 longer apply the changes as they were originally).
 +
-When no `<stash>` is given, `stash@\{0}` is assumed, otherwise `<stash>` must
-be a reference of the form `stash@\{<revision>}`.
+When no `<stash>` is given, `stash@\{0}` is assumed.
 
 apply [--index] [-q|--quiet] [<stash>]::
 
-	Like `pop`, but do not remove the state from the stash list. Unlike `pop`,
-	`<stash>` may be any commit that looks like a commit created by
-	`stash save` or `stash create`.
+	Like `pop`, but do not remove the state from the stash list.
 
 branch <branchname> [<stash>]::
 
 	Creates and checks out a new branch named `<branchname>` starting from
 	the commit at which the `<stash>` was originally created, applies the
-	changes recorded in `<stash>` to the new working tree and index.
-	If that succeeds, and `<stash>` is a reference of the form
-	`stash@{<revision>}`, it then drops the `<stash>`. When no `<stash>`
+	changes recorded in `<stash>` to the new working tree and index, then
+	drops the `<stash>` if that completes successfully. When no `<stash>`
 	is given, applies the latest one.
 +
 This is useful if the branch on which you ran `git stash save` has
@@ -136,9 +132,7 @@ clear::
 drop [-q|--quiet] [<stash>]::
 
 	Remove a single stashed state from the stash list. When no `<stash>`
-	is given, it removes the latest one. i.e. `stash@\{0}`, otherwise
-	`<stash>` must a valid stash log reference of the form
-	`stash@\{<revision>}`.
+	is given, it removes the latest one. i.e. `stash@\{0}`
 
 create::
 

Documentation/git-status.txt

@@ -27,10 +27,6 @@ OPTIONS
 --short::
 	Give the output in the short-format.
 
--b::
---branch::
-	Show the branch and tracking info even in short-format.
-
 --porcelain::
 	Give the output in a stable, easy-to-parse format for scripts.
 	Currently this is identical to --short output, but is guaranteed
@@ -53,21 +49,6 @@ See linkgit:git-config[1] for configuration variable
 used to change the default for when the option is not
 specified.
 
---ignore-submodules[=<when>]::
-	Ignore changes to submodules when looking for changes. <when> can be
-	either "none", "untracked", "dirty" or "all", which is the default.
-	Using "none" will consider the submodule modified when it either contains
-	untracked or modified files or its HEAD differs from the commit recorded
-	in the superproject and can be used to override any settings of the
-	'ignore' option in linkgit:git-config[1] or linkgit:gitmodules[5]. When
-	"untracked" is used submodules are not considered dirty when they only
-	contain untracked content (but they are still scanned for modified
-	content). Using "dirty" ignores all changes to the work tree of submodules,
-	only changes to the commits stored in the superproject are shown (this was
-	the behavior before 1.7.0). Using "all" hides all changes to submodules
-	(and suppresses the output of submodule summaries when the config option
-	`status.submodulesummary` is set).
-
 -z::
 	Terminate entries with NUL, instead of LF.  This implies
 	the `--porcelain` output format if no other format is given.
@@ -139,10 +120,6 @@ Ignored files are not listed.
     ?           ?    untracked
     -------------------------------------------------
 
-If -b is used the short-format status is preceded by a line
-
-## branchname tracking info
-
 There is an alternate -z format recommended for machine parsing.  In
 that format, the status field is the same, but some other things
 change.  First, the '->' is omitted from rename entries and the field
@@ -151,7 +128,7 @@ order is reversed (e.g 'from -> to' becomes 'to from'). Second, a NUL
 and the terminating newline (but a space still separates the status
 field from the first filename).  Third, filenames containing special
 characters are not specially formatted; no quoting or
-backslash-escaping is performed. Fourth, there is no branch line.
+backslash-escaping is performed.
 
 CONFIGURATION
 -------------

Documentation/git-submodule.txt

@@ -9,7 +9,7 @@ git-submodule - Initialize, update or inspect submodules
 SYNOPSIS
 --------
 [verse]
-'git submodule' [--quiet] add [-b branch] [-f|--force]
+'git submodule' [--quiet] add [-b branch]
 	      [--reference <repository>] [--] <repository> [<path>]
 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
 'git submodule' [--quiet] init [--] [<path>...]
@@ -145,12 +145,10 @@ summary::
 
 foreach::
 	Evaluates an arbitrary shell command in each checked out submodule.
-	The command has access to the variables $name, $path, $sha1 and
-	$toplevel:
+	The command has access to the variables $name, $path and $sha1:
 	$name is the name of the relevant submodule section in .gitmodules,
 	$path is the name of the submodule directory relative to the
-	superproject, $sha1 is the commit as recorded in the superproject,
-	and $toplevel is the absolute path to the top-level of the superproject.
+	superproject, and $sha1 is the commit as recorded in the superproject.
 	Any submodules defined in the superproject but not checked out are
 	ignored by this command. Unless given --quiet, foreach prints the name
 	of each submodule before evaluating the command.
@@ -183,11 +181,6 @@ OPTIONS
 --branch::
 	Branch of repository to add as submodule.
 
--f::
---force::
-	This option is only valid for the add command.
-	Allow adding an otherwise ignored submodule path.
-
 --cached::
 	This option is only valid for status and summary commands.  These
 	commands typically use the commit found in the submodule HEAD, but

Documentation/git-svn.txt

@@ -243,7 +243,7 @@ where <name> is the name of the SVN repository as specified by the -R option to
 
 --username;;
 	Specify the SVN username to perform the commit as.  This option overrides
-	the 'username' configuration property.
+	configuration property 'username'.
 
 --commit-url;;
 	Use the specified URL to connect to the destination Subversion
@@ -646,12 +646,6 @@ svn.brokenSymlinkWorkaround::
 	revision fetched.  If unset, 'git svn' assumes this option to
 	be "true".
 
-svn.pathnameencoding::
-	This instructs git svn to recode pathnames to a given encoding.
-	It can be used by windows users and by those who work in non-utf8
-	locales to avoid corrupted file names with non-ASCII characters.
-	Valid encodings are the ones supported by Perl's Encode module.
-
 Since the noMetadata, rewriteRoot, rewriteUUID, useSvnsyncProps and useSvmProps
 options all affect the metadata generated and used by 'git svn'; they
 *must* be set in the configuration file before any history is imported

Documentation/git-update-index.txt

@@ -12,7 +12,7 @@ SYNOPSIS
 'git update-index'
 	     [--add] [--remove | --force-remove] [--replace]
 	     [--refresh] [-q] [--unmerged] [--ignore-missing]
-	     [--cacheinfo <mode> <object> <file>]*
+	     [--cacheinfo <mode> <object> <file>]\*
 	     [--chmod=(+|-)x]
 	     [--assume-unchanged | --no-assume-unchanged]
 	     [--skip-worktree | --no-skip-worktree]
@@ -21,7 +21,7 @@ SYNOPSIS
 	     [--info-only] [--index-info]
 	     [-z] [--stdin]
 	     [--verbose]
-	     [--] [<file>]*
+	     [--] [<file>]\*
 
 DESCRIPTION
 -----------
@@ -93,6 +93,8 @@ OPTIONS
 This option can be also used as a coarse file-level mechanism
 to ignore uncommitted changes in tracked files (akin to what
 `.gitignore` does for untracked files).
+You should remember that an explicit 'git add' operation will
+still cause the file to be refreshed from the working tree.
 Git will fail (gracefully) in case it needs to modify this file
 in the index e.g. when merging in a commit;
 thus, in case the assumed-untracked file is changed upstream,

Documentation/git-web--browse.txt

@@ -1,5 +1,5 @@
-git-web{litdd}browse(1)
-=======================
+git-web--browse(1)
+==================
 
 NAME
 ----
@@ -7,7 +7,7 @@ git-web--browse - git helper script to launch a web browser
 
 SYNOPSIS
 --------
-'git web{litdd}browse' [OPTIONS] URL/FILE ...
+'git web--browse' [OPTIONS] URL/FILE ...
 
 DESCRIPTION
 -----------
@@ -71,7 +71,7 @@ browser.<tool>.cmd
 When the browser, specified by options or configuration variables, is
 not among the supported ones, then the corresponding
 'browser.<tool>.cmd' configuration variable will be looked up. If this
-variable exists then 'git web{litdd}browse' will treat the specified tool
+variable exists then 'git web--browse' will treat the specified tool
 as a custom command and will use a shell eval to run the command with
 the URLs passed as arguments.
 

Documentation/git.txt

@@ -12,7 +12,6 @@ SYNOPSIS
 'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path]
     [-p|--paginate|--no-pager] [--no-replace-objects]
     [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]
-    [-c name=value]
     [--help] COMMAND [ARGS]
 
 DESCRIPTION
@@ -44,21 +43,6 @@ unreleased) version of git, that is available from 'master'
 branch of the `git.git` repository.
 Documentation for older releases are available here:
 
-* link:v1.7.2.3/git.html[documentation for release 1.7.2.3]
-
-* release notes for
-  link:RelNotes-1.7.2.3.txt[1.7.2.3],
-  link:RelNotes-1.7.2.2.txt[1.7.2.2],
-  link:RelNotes-1.7.2.1.txt[1.7.2.1],
-  link:RelNotes-1.7.2.txt[1.7.2].
-
-* link:v1.7.1.2/git.html[documentation for release 1.7.1.2]
-
-* release notes for
-  link:RelNotes-1.7.1.2.txt[1.7.1.2],
-  link:RelNotes-1.7.1.1.txt[1.7.1.1],
-  link:RelNotes-1.7.1.txt[1.7.1].
-
 * link:v1.7.0.7/git.html[documentation for release 1.7.0.7]
 
 * release notes for
@@ -240,12 +224,6 @@ displayed. See linkgit:git-help[1] for more information,
 because `git --help ...` is converted internally into `git
 help ...`.
 
--c <name>=<value>::
-	Pass a configuration parameter to the command. The value
-	given will override values from configuration files.
-	The <name> is expected in the same format as listed by
-	'git config' (subkeys separated by dots).
-
 --exec-path::
 	Path to wherever your core git programs are installed.
 	This can also be controlled by setting the GIT_EXEC_PATH
@@ -489,7 +467,7 @@ HEAD::
 	(i.e. the contents of `$GIT_DIR/refs/heads/<head>`).
 
 For a more complete list of ways to spell object names, see
-"SPECIFYING REVISIONS" section in linkgit:gitrevisions[1].
+"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
 
 
 File/Directory Structure
@@ -556,16 +534,6 @@ git so take care if using Cogito etc.
 	a GIT_DIR set on the command line or in the environment.
 	(Useful for excluding slow-loading network directories.)
 
-'GIT_DISCOVERY_ACROSS_FILESYSTEM'::
-	When run in a directory that does not have ".git" repository
-	directory, git tries to find such a directory in the parent
-	directories to find the top of the working tree, but by default it
-	does not cross filesystem boundaries.  This environment variable
-	can be set to true to tell git not to stop at filesystem
-	boundaries.  Like 'GIT_CEILING_DIRECTORIES', this will not affect
-	an explicit repository directory set via 'GIT_DIR' or on the
-	command line.
-
 git Commits
 ~~~~~~~~~~~
 'GIT_AUTHOR_NAME'::
@@ -729,13 +697,6 @@ The documentation for git suite was started by David Greaves
 <david@dgreaves.com>, and later enhanced greatly by the
 contributors on the git-list <git@vger.kernel.org>.
 
-Reporting Bugs
---------------
-
-Report bugs to the Git mailing list <git@vger.kernel.org> where the
-development and maintenance is primarily done.  You do not have to be
-subscribed to the list to send a message there.
-
 SEE ALSO
 --------
 linkgit:gittutorial[7], linkgit:gittutorial-2[7],

Documentation/gitattributes.txt

@@ -92,154 +92,53 @@ such as 'git checkout' and 'git merge' run.  They also affect how
 git stores the contents you prepare in the working tree in the
 repository upon 'git add' and 'git commit'.
 
-`text`
+`crlf`
 ^^^^^^
 
-This attribute enables and controls end-of-line normalization.  When a
-text file is normalized, its line endings are converted to LF in the
-repository.  To control what line ending style is used in the working
-directory, use the `eol` attribute for a single file and the
-`core.eol` configuration variable for all text files.
+This attribute controls the line-ending convention.
 
 Set::
 
-	Setting the `text` attribute on a path enables end-of-line
-	normalization and marks the path as a text file.  End-of-line
-	conversion takes place without guessing the content type.
+	Setting the `crlf` attribute on a path is meant to mark
+	the path as a "text" file.  'core.autocrlf' conversion
+	takes place without guessing the content type by
+	inspection.
 
 Unset::
 
-	Unsetting the `text` attribute on a path tells git not to
+	Unsetting the `crlf` attribute on a path tells git not to
 	attempt any end-of-line conversion upon checkin or checkout.
 
-Set to string value "auto"::
-
-	When `text` is set to "auto", the path is marked for automatic
-	end-of-line normalization.  If git decides that the content is
-	text, its line endings are normalized to LF on checkin.
-
 Unspecified::
 
-	If the `text` attribute is unspecified, git uses the
-	`core.autocrlf` configuration variable to determine if the
-	file should be converted.
+	Unspecified `crlf` attribute tells git to apply the
+	`core.autocrlf` conversion when the file content looks
+	like text.
 
-Any other value causes git to act as if `text` has been left
-unspecified.
+Set to string value "input"::
 
-`eol`
-^^^^^
+	This is similar to setting the attribute to `true`, but
+	also forces git to act as if `core.autocrlf` is set to
+	`input` for the path.
 
-This attribute sets a specific line-ending style to be used in the
-working directory.  It enables end-of-line normalization without any
-content checks, effectively setting the `text` attribute.
+Any other value set to `crlf` attribute is ignored and git acts
+as if the attribute is left unspecified.
 
-Set to string value "crlf"::
 
-	This setting forces git to normalize line endings for this
-	file on checkin and convert them to CRLF when the file is
-	checked out.
+The `core.autocrlf` conversion
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Set to string value "lf"::
+If the configuration variable `core.autocrlf` is false, no
+conversion is done.
 
-	This setting forces git to normalize line endings to LF on
-	checkin and prevents conversion to CRLF when the file is
-	checked out.
+When `core.autocrlf` is true, it means that the platform wants
+CRLF line endings for files in the working tree, and you want to
+convert them back to the normal LF line endings when checking
+in to the repository.
 
-Backwards compatibility with `crlf` attribute
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-For backwards compatibility, the `crlf` attribute is interpreted as
-follows:
-
-------------------------
-crlf		text
--crlf		-text
-crlf=input	eol=lf
-------------------------
-
-End-of-line conversion
-^^^^^^^^^^^^^^^^^^^^^^
-
-While git normally leaves file contents alone, it can be configured to
-normalize line endings to LF in the repository and, optionally, to
-convert them to CRLF when files are checked out.
-
-Here is an example that will make git normalize .txt, .vcproj and .sh
-files, ensure that .vcproj files have CRLF and .sh files have LF in
-the working directory, and prevent .jpg files from being normalized
-regardless of their content.
-
-------------------------
-*.txt		text
-*.vcproj	eol=crlf
-*.sh		eol=lf
-*.jpg		-text
-------------------------
-
-Other source code management systems normalize all text files in their
-repositories, and there are two ways to enable similar automatic
-normalization in git.
-
-If you simply want to have CRLF line endings in your working directory
-regardless of the repository you are working with, you can set the
-config variable "core.autocrlf" without changing any attributes.
-
-------------------------
-[core]
-	autocrlf = true
-------------------------
-
-This does not force normalization of all text files, but does ensure
-that text files that you introduce to the repository have their line
-endings normalized to LF when they are added, and that files that are
-already normalized in the repository stay normalized.
-
-If you want to interoperate with a source code management system that
-enforces end-of-line normalization, or you simply want all text files
-in your repository to be normalized, you should instead set the `text`
-attribute to "auto" for _all_ files.
-
-------------------------
-*	text=auto
-------------------------
-
-This ensures that all files that git considers to be text will have
-normalized (LF) line endings in the repository.  The `core.eol`
-configuration variable controls which line endings git will use for
-normalized files in your working directory; the default is to use the
-native line ending for your platform, or CRLF if `core.autocrlf` is
-set.
-
-NOTE: When `text=auto` normalization is enabled in an existing
-repository, any text files containing CRLFs should be normalized.  If
-they are not they will be normalized the next time someone tries to
-change them, causing unfortunate misattribution.  From a clean working
-directory:
-
--------------------------------------------------
-$ echo "* text=auto" >>.gitattributes
-$ rm .git/index     # Remove the index to force git to
-$ git reset         # re-scan the working directory
-$ git status        # Show files that will be normalized
-$ git add -u
-$ git add .gitattributes
-$ git commit -m "Introduce end-of-line normalization"
--------------------------------------------------
-
-If any files that should not be normalized show up in 'git status',
-unset their `text` attribute before running 'git add -u'.
-
-------------------------
-manual.pdf	-text
-------------------------
-
-Conversely, text files that git does not detect can have normalization
-enabled manually.
-
-------------------------
-weirdchars.txt	text
-------------------------
+When `core.autocrlf` is set to "input", line endings are
+converted to LF upon checkin, but there is no conversion done
+upon checkout.
 
 If `core.safecrlf` is set to "true" or "warn", git verifies if
 the conversion is reversible for the current setting of
@@ -317,17 +216,6 @@ command is "cat").
 	smudge = cat
 ------------------------
 
-For best results, `clean` should not alter its output further if it is
-run twice ("clean->clean" should be equivalent to "clean"), and
-multiple `smudge` commands should not alter `clean`'s output
-("smudge->smudge->clean" should be equivalent to "clean").  See the
-section on merging below.
-
-The "indent" filter is well-behaved in this regard: it will not modify
-input that is already correctly indented.  In this case, the lack of a
-smudge filter means that the clean filter _must_ accept its own output
-without modifying it.
-
 
 Interaction between checkin/checkout attributes
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -335,34 +223,11 @@ Interaction between checkin/checkout attributes
 In the check-in codepath, the worktree file is first converted
 with `filter` driver (if specified and corresponding driver
 defined), then the result is processed with `ident` (if
-specified), and then finally with `text` (again, if specified
+specified), and then finally with `crlf` (again, if specified
 and applicable).
 
 In the check-out codepath, the blob content is first converted
-with `text`, and then `ident` and fed to `filter`.
-
-
-Merging branches with differing checkin/checkout attributes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-If you have added attributes to a file that cause the canonical
-repository format for that file to change, such as adding a
-clean/smudge filter or text/eol/ident attributes, merging anything
-where the attribute is not in place would normally cause merge
-conflicts.
-
-To prevent these unnecessary merge conflicts, git can be told to run a
-virtual check-out and check-in of all three stages of a file when
-resolving a three-way merge by setting the `merge.renormalize`
-configuration variable.  This prevents changes caused by check-in
-conversion from causing spurious merge conflicts when a converted file
-is merged with an unconverted file.
-
-As long as a "smudge->clean" results in the same output as a "clean"
-even on files that are already smudged, this strategy will
-automatically resolve all filter-related conflicts.  Filters that do
-not act in this way may cause additional merge conflicts that must be
-resolved manually.
+with `crlf`, and then `ident` and fed to `filter`.
 
 
 Generating diff text
@@ -475,8 +340,6 @@ patterns are available:
 
 - `cpp` suitable for source code in the C and C++ languages.
 
-- `csharp` suitable for source code in the C# language.
-
 - `html` suitable for HTML/XHTML documents.
 
 - `java` suitable for source code in the Java language.
@@ -497,7 +360,7 @@ patterns are available:
 Customizing word diff
 ^^^^^^^^^^^^^^^^^^^^^
 
-You can customize the rules that `git diff --word-diff` uses to
+You can customize the rules that `git diff --color-words` uses to
 split words in a line, by specifying an appropriate regular expression
 in the "diff.*.wordRegex" configuration variable.  For example, in TeX
 a backslash followed by a sequence of letters forms a command, but
@@ -551,26 +414,6 @@ because it quickly conveys the changes you have made), you
 should generate it separately and send it as a comment _in
 addition to_ the usual binary diff that you might send.
 
-Because text conversion can be slow, especially when doing a
-large number of them with `git log -p`, git provides a mechanism
-to cache the output and use it in future diffs.  To enable
-caching, set the "cachetextconv" variable in your diff driver's
-config. For example:
-
-------------------------
-[diff "jpg"]
-	textconv = exif
-	cachetextconv = true
-------------------------
-
-This will cache the result of running "exif" on each blob
-indefinitely. If you change the textconv config variable for a
-diff driver, git will automatically invalidate the cache entries
-and re-run the textconv filter. If you want to invalidate the
-cache manually (e.g., because your version of "exif" was updated
-and now produces better output), you can remove the cache
-manually with `git update-ref -d refs/notes/textconv/jpg` (where
-"jpg" is the name of the diff driver, as in the example above).
 
 Performing a three-way merge
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -788,7 +631,7 @@ You do not want any end-of-line conversions applied to, nor textual diffs
 produced for, any binary file you track.  You would need to specify e.g.
 
 ------------
-*.jpg -text -diff
+*.jpg -crlf -diff
 ------------
 
 but that may become cumbersome, when you have many attributes.  Using
@@ -801,7 +644,7 @@ the same time.  The system knows a built-in attribute macro, `binary`:
 
 which is equivalent to the above.  Note that the attribute macros can only
 be "Set" (see the above example that sets "binary" macro as if it were an
-ordinary attribute --- setting it in turn unsets "text" and "diff").
+ordinary attribute --- setting it in turn unsets "crlf" and "diff").
 
 
 DEFINING ATTRIBUTE MACROS
@@ -812,7 +655,7 @@ at the toplevel (i.e. not in any subdirectory).  The built-in attribute
 macro "binary" is equivalent to:
 
 ------------
-[attr]binary -diff -text
+[attr]binary -diff -crlf
 ------------
 
 

Documentation/gitcore-tutorial.txt

@@ -110,7 +110,7 @@ An 'object' is identified by its 160-bit SHA1 hash, aka 'object name',
 and a reference to an object is always the 40-byte hex
 representation of that SHA1 name. The files in the `refs`
 subdirectory are expected to contain these hex references
-(usually with a final `\n` at the end), and you should thus
+(usually with a final `\'\n\'` at the end), and you should thus
 expect to see a number of 41-byte files containing these
 references in these `refs` subdirectories when you actually start
 populating your tree.
@@ -310,7 +310,7 @@ and this will just output the name of the resulting tree, in this case
 ----------------
 
 which is another incomprehensible object name. Again, if you want to,
-you can use `git cat-file -t 8988d...` to see that this time the object
+you can use `git cat-file -t 8988d\...` to see that this time the object
 is not a "blob" object, but a "tree" object (you can also use
 `git cat-file` to actually output the raw object contents, but you'll see
 mainly a binary mess, so that's less interesting).
@@ -436,8 +436,8 @@ $ git update-index hello
 (note how we didn't need the `\--add` flag this time, since git knew
 about the file already).
 
-Note what happens to the different 'git diff-{asterisk}' versions here.
-After we've updated `hello` in the index, `git diff-files -p` now shows no
+Note what happens to the different 'git diff-\*' versions here. After
+we've updated `hello` in the index, `git diff-files -p` now shows no
 differences, but `git diff-index -p HEAD` still *does* show that the
 current state is different from the state we committed. In fact, now
 'git diff-index' shows the same difference whether we use the `--cached`
@@ -494,7 +494,7 @@ and it will show what the last commit (in `HEAD`) actually changed.
 [NOTE]
 ============
 Here is an ASCII art by Jon Loeliger that illustrates how
-various 'diff-{asterisk}' commands compare things.
+various diff-\* commands compare things.
 
                       diff-tree
                        +----+
@@ -958,11 +958,11 @@ $ git show-branch --topo-order --more=1 master mybranch
 The first two lines indicate that it is showing the two branches
 and the first line of the commit log message from their
 top-of-the-tree commits, you are currently on `master` branch
-(notice the asterisk `{asterisk}` character), and the first column for
+(notice the asterisk `\*` character), and the first column for
 the later output lines is used to show commits contained in the
 `master` branch, and the second column for the `mybranch`
 branch. Three commits are shown along with their log messages.
-All of them have non blank characters in the first column (`{asterisk}`
+All of them have non blank characters in the first column (`*`
 shows an ordinary commit on the current branch, `-` is a merge commit), which
 means they are now part of the `master` branch. Only the "Some
 work" commit has the plus `+` character in the second column,
@@ -971,7 +971,7 @@ commits from the master branch.  The string inside brackets
 before the commit log message is a short name you can use to
 name the commit.  In the above example, 'master' and 'mybranch'
 are branch heads.  'master^' is the first parent of 'master'
-branch head.  Please see linkgit:gitrevisions[1] if you want to
+branch head.  Please see linkgit:git-rev-parse[1] if you want to
 see more complex cases.
 
 [NOTE]
@@ -1092,7 +1092,7 @@ Downloader from http and https URL
 first obtains the topmost commit object name from the remote site
 by looking at the specified refname under `repo.git/refs/` directory,
 and then tries to obtain the
-commit object by downloading from `repo.git/objects/xx/xxx...`
+commit object by downloading from `repo.git/objects/xx/xxx\...`
 using the object name of that commit object.  Then it reads the
 commit object to find out its parent commits and the associate
 tree object; it repeats this process until it gets all the
@@ -1420,7 +1420,7 @@ packed, and stores the packed file in `.git/objects/pack`
 directory.
 
 [NOTE]
-You will see two files, `pack-{asterisk}.pack` and `pack-{asterisk}.idx`,
+You will see two files, `pack-\*.pack` and `pack-\*.idx`,
 in `.git/objects/pack` directory. They are closely related to
 each other, and if you ever copy them by hand to a different
 repository for whatever reason, you should make sure you copy

Documentation/gitdiffcore.txt

@@ -227,8 +227,8 @@ changes that touch a specified string, and is controlled by the
 commands.
 
 When diffcore-pickaxe is in use, it checks if there are
-filepairs whose "result" side has the specified string and
-whose "origin" side does not.  Such a filepair represents "the
+filepairs whose "original" side has the specified string and
+whose "result" side does not.  Such a filepair represents "the
 string appeared in this changeset".  It also checks for the
 opposite case that loses the specified string.
 

Documentation/githooks.txt

@@ -317,44 +317,6 @@ This hook is invoked by 'git gc --auto'. It takes no parameter, and
 exiting with non-zero status from this script causes the 'git gc --auto'
 to abort.
 
-post-rewrite
-~~~~~~~~~~~~
-
-This hook is invoked by commands that rewrite commits (`git commit
---amend`, 'git-rebase'; currently 'git-filter-branch' does 'not' call
-it!).  Its first argument denotes the command it was invoked by:
-currently one of `amend` or `rebase`.  Further command-dependent
-arguments may be passed in the future.
-
-The hook receives a list of the rewritten commits on stdin, in the
-format
-
-  <old-sha1> SP <new-sha1> [ SP <extra-info> ] LF
-
-The 'extra-info' is again command-dependent.  If it is empty, the
-preceding SP is also omitted.  Currently, no commands pass any
-'extra-info'.
-
-The hook always runs after the automatic note copying (see
-"notes.rewrite.<command>" in linkgit:git-config.txt) has happened, and
-thus has access to these notes.
-
-The following command-specific comments apply:
-
-rebase::
-	For the 'squash' and 'fixup' operation, all commits that were
-	squashed are listed as being rewritten to the squashed commit.
-	This means that there will be several lines sharing the same
-	'new-sha1'.
-+
-The commits are guaranteed to be listed in the order that they were
-processed by rebase.
-
-There is no default 'post-rewrite' hook, but see the
-`post-receive-copy-notes` script in `contrib/hooks` for an example
-that copies your git-notes to the rewritten commits.
-
-
 GIT
 ---
 Part of the linkgit:git[1] suite

Documentation/gitignore.txt

@@ -83,20 +83,16 @@ Patterns have the following format:
 
  - If the pattern does not contain a slash '/', git treats it as
    a shell glob pattern and checks for a match against the
-   pathname relative to the location of the `.gitignore` file
-   (relative to the toplevel of the work tree if not from a
-   `.gitignore` file).
+   pathname without leading directories.
 
  - Otherwise, git treats the pattern as a shell glob suitable
    for consumption by fnmatch(3) with the FNM_PATHNAME flag:
    wildcards in the pattern will not match a / in the pathname.
-   For example, "Documentation/{asterisk}.html" matches
-   "Documentation/git.html" but not "Documentation/ppc/ppc.html"
-   or "tools/perf/Documentation/perf.html".
-
- - A leading slash matches the beginning of the pathname.
-   For example, "/{asterisk}.c" matches "cat-file.c" but not
-   "mozilla-sha1/sha1.c".
+   For example, "Documentation/\*.html" matches
+   "Documentation/git.html" but not
+   "Documentation/ppc/ppc.html".  A leading slash matches the
+   beginning of the pathname; for example, "/*.c" matches
+   "cat-file.c" but not "mozilla-sha1/sha1.c".
 
 An example: