cvsserver: avoid warning about active db handles

Turns out that DBD::SQLite does not favour preparing statements which are
never executed. So, turn all 4 statements, which were prepared _always_,
into methods, like the other 12 prepared statements.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

.gitignore

@@ -1,6 +1,9 @@
+GIT-CFLAGS
+GIT-VERSION-FILE
 git
 git-add
 git-am
+git-annotate
 git-apply
 git-applymbox
 git-applypatch
@@ -13,20 +16,22 @@ git-checkout
 git-checkout-index
 git-cherry
 git-cherry-pick
+git-clean
 git-clone
-git-clone-pack
 git-commit
 git-commit-tree
 git-convert-objects
 git-count-objects
 git-cvsexportcommit
 git-cvsimport
+git-cvsserver
 git-daemon
 git-diff
 git-diff-files
 git-diff-index
 git-diff-stages
 git-diff-tree
+git-describe
 git-fetch
 git-fetch-pack
 git-findtags
@@ -38,8 +43,10 @@ git-grep
 git-hash-object
 git-http-fetch
 git-http-push
+git-imap-send
 git-index-pack
 git-init-db
+git-instaweb
 git-local-fetch
 git-log
 git-lost-found
@@ -51,6 +58,7 @@ git-mailsplit
 git-merge
 git-merge-base
 git-merge-index
+git-merge-tree
 git-merge-octopus
 git-merge-one-file
 git-merge-ours
@@ -58,6 +66,7 @@ git-merge-recursive
 git-merge-resolve
 git-merge-stupid
 git-mktag
+git-mktree
 git-name-rev
 git-mv
 git-pack-redundant
@@ -69,6 +78,7 @@ git-prune
 git-prune-packed
 git-pull
 git-push
+git-quiltimport
 git-read-tree
 git-rebase
 git-receive-pack
@@ -76,16 +86,19 @@ git-relink
 git-repack
 git-repo-config
 git-request-pull
+git-rerere
 git-reset
 git-resolve
 git-rev-list
 git-rev-parse
 git-revert
+git-rm
 git-send-email
 git-send-pack
 git-sh-setup
 git-shell
 git-shortlog
+git-show
 git-show-branch
 git-show-index
 git-ssh-fetch
@@ -94,6 +107,7 @@ git-ssh-push
 git-ssh-upload
 git-status
 git-stripspace
+git-svn
 git-svnimport
 git-symbolic-ref
 git-tag
@@ -104,6 +118,7 @@ git-update-index
 git-update-ref
 git-update-server-info
 git-upload-pack
+git-upload-tar
 git-var
 git-verify-pack
 git-verify-tag
@@ -112,11 +127,14 @@ git-write-tree
 git-core-*/?*
 test-date
 test-delta
+test-dump-cache-tree
+common-cmds.h
 *.tar.gz
 *.dsc
 *.deb
 git-core.spec
 *.exe
-libgit.a
+*.[ao]
-*.o
 *.py[co]
+config.mak
+git-blame

Documentation/.gitignore

@@ -4,3 +4,4 @@
 *.7
 howto-index.txt
 doc.dep
+README

Documentation/Makefile

@@ -1,15 +1,21 @@
-MAN1_TXT=$(wildcard git-*.txt) gitk.txt
+MAN1_TXT= \
+	$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
+		$(wildcard git-*.txt)) \
+	gitk.txt
 MAN7_TXT=git.txt
 
 DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT))
 
 ARTICLES = tutorial
+ARTICLES += tutorial-2
+ARTICLES += core-tutorial
 ARTICLES += cvs-migration
 ARTICLES += diffcore
 ARTICLES += howto-index
 ARTICLES += repository-layout
 ARTICLES += hooks
 ARTICLES += everyday
+ARTICLES += git-tools
 # with their own formatting rules.
 SP_ARTICLES = glossary howto/revert-branch-rebase
 
@@ -40,15 +46,16 @@ all: html man
 
 html: $(DOC_HTML)
 
+$(DOC_HTML) $(DOC_MAN1) $(DOC_MAN7): asciidoc.conf
 
 man: man1 man7
 man1: $(DOC_MAN1)
 man7: $(DOC_MAN7)
 
 install: man
-	$(INSTALL) -d -m755 $(DESTDIR)/$(man1) $(DESTDIR)/$(man7)
+	$(INSTALL) -d -m755 $(DESTDIR)$(man1) $(DESTDIR)$(man7)
-	$(INSTALL) $(DOC_MAN1) $(DESTDIR)/$(man1)
+	$(INSTALL) $(DOC_MAN1) $(DESTDIR)$(man1)
-	$(INSTALL) $(DOC_MAN7) $(DESTDIR)/$(man7)
+	$(INSTALL) $(DOC_MAN7) $(DESTDIR)$(man7)
 
 
 #
@@ -61,22 +68,25 @@ doc.dep : $(wildcard *.txt) build-docdep.perl
 
 -include doc.dep
 
-git.7: ../README
+git.7: README
+
+README: ../README
+	cp $< $@
 
 
 clean:
-	rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep
+	rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep README
 
 %.html : %.txt
 	asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
 
 %.1 %.7 : %.xml
-	xmlto man $<
+	xmlto -m callouts.xsl man $<
 
 %.xml : %.txt
 	asciidoc -b docbook -d manpage -f asciidoc.conf $<
 
-git.html: git.txt ../README
+git.html: git.txt README
 
 glossary.html : glossary.txt sort_glossary.pl
 	cat $< | \

Documentation/SubmittingPatches

@@ -4,8 +4,8 @@ it for the core GIT to make sure people understand what they are
 doing when they write "Signed-off-by" line.
 
 But the patch submission requirements are a lot more relaxed
-here, because the core GIT is thousand times smaller ;-).  So
+here on the technical/contents front, because the core GIT is
-here is only the relevant bits.
+thousand times smaller ;-).  So here is only the relevant bits.
 
 
 (1) Make separate commits for logically separate changes.
@@ -18,13 +18,19 @@ repository.  It is a good discipline.
 
 Describe the technical detail of the change(s).
 
-If your description starts to get long, that's a sign that you
+If your description starts to get too long, that's a sign that you
 probably need to split up your commit to finer grained pieces.
 
+Oh, another thing.  I am picky about whitespaces.  Make sure your
+changes do not trigger errors with the sample pre-commit hook shipped
+in templates/hooks--pre-commit.
 
-(2) Generate your patch using git/cogito out of your commits.
 
-git diff tools generate unidiff which is the preferred format.
+(2) Generate your patch using git tools out of your commits.
+
+git based diff tools (git, Cogito, and StGIT included) generate
+unidiff which is the preferred format.
+
 You do not have to be afraid to use -M option to "git diff" or
 "git format-patch", if your patch involves file renames.  The
 receiving end can handle them just fine.
@@ -33,20 +39,22 @@ Please make sure your patch does not include any extra files
 which do not belong in a patch submission.  Make sure to review
 your patch after generating it, to ensure accuracy.  Before
 sending out, please make sure it cleanly applies to the "master"
-branch head.
+branch head.  If you are preparing a work based on "next" branch,
+that is fine, but please mark it as such.
 
 
 (3) Sending your patches.
 
-People on the git mailing list needs to be able to read and
+People on the git mailing list need to be able to read and
 comment on the changes you are submitting.  It is important for
 a developer to be able to "quote" your changes, using standard
 e-mail tools, so that they may comment on specific portions of
-your code.  For this reason, all patches should be submitting
+your code.  For this reason, all patches should be submitted
-e-mail "inline".  WARNING: Be wary of your MUAs word-wrap
+"inline".  WARNING: Be wary of your MUAs word-wrap
-corrupting your patch.  Do not cut-n-paste your patch.
+corrupting your patch.  Do not cut-n-paste your patch; you can
+lose tabs that way if you are not careful.
 
-It is common convention to prefix your subject line with
+It is a common convention to prefix your subject line with
 [PATCH].  This lets people easily distinguish patches from other
 e-mail discussions.
 
@@ -258,8 +266,8 @@ This recipe appears to work with the current [*1*] Thunderbird from Suse.
 The following Thunderbird extensions are needed:
 	AboutConfig 0.5
 		http://aboutconfig.mozdev.org/
-	External Editor 0.5.4
+	External Editor 0.7.2
-		http://extensionroom.mozdev.org/more-info/exteditor
+		http://globs.org/articles.php?lng=en&pg=8
 
 1) Prepare the patch as a text file using your method of choice.
 

Documentation/asciidoc.conf

@@ -9,6 +9,8 @@
 
 [attributes]
 caret=^
+startsb=[
+endsb=]
 
 ifdef::backend-docbook[]
 [gitlink-inlinemacro]
@@ -18,6 +20,16 @@ ifdef::backend-docbook[]
 {0#</citerefentry>}
 endif::backend-docbook[]
 
+ifdef::backend-docbook[]
+# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this.
+[listingblock]
+<example><title>{title}</title>
+<literallayout>
+|
+</literallayout>
+{title#}</example>
+endif::backend-docbook[]
+
 ifdef::backend-xhtml11[]
 [gitlink-inlinemacro]
 <a href="{target}.html">{target}{0?({0})}</a>

Documentation/callouts.xsl

@@ -0,0 +1,16 @@
+<!-- callout.xsl: converts asciidoc callouts to man page format -->
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
+<xsl:template match="co">
+	<xsl:value-of select="concat('\fB(',substring-after(@id,'-'),')\fR')"/>
+</xsl:template>
+<xsl:template match="calloutlist">
+	<xsl:text>.sp&#10;</xsl:text>
+	<xsl:apply-templates/>
+	<xsl:text>&#10;</xsl:text>
+</xsl:template>
+<xsl:template match="callout">
+	<xsl:value-of select="concat('\fB',substring-after(@arearefs,'-'),'. \fR')"/>
+	<xsl:apply-templates/>
+	<xsl:text>.br&#10;</xsl:text>
+</xsl:template>
+</xsl:stylesheet>

Documentation/config.txt

@@ -0,0 +1,248 @@
+CONFIGURATION FILE
+------------------
+
+The git configuration file contains a number of variables that affect
+the git command's behavior. They can be used by both the git plumbing
+and the porcelains. The variables are divided into sections, where
+in the fully qualified variable name the variable itself is the last
+dot-separated segment and the section name is everything before the last
+dot. The variable names are case-insensitive and only alphanumeric
+characters are allowed. Some variables may appear multiple times.
+
+The syntax is fairly flexible and permissive; whitespaces are mostly
+ignored. The '#' and ';' characters begin comments to the end of line,
+blank lines are ignored, lines containing strings enclosed in square
+brackets start sections and all the other lines are recognized
+as setting variables, in the form 'name = value'. If there is no equal
+sign on the line, the entire line is taken as 'name' and the variable
+is recognized as boolean "true". String values may be entirely or partially
+enclosed in double quotes; some variables may require special value format.
+
+Example
+~~~~~~~
+
+	# Core variables
+	[core]
+		; Don't trust file modes
+		filemode = false
+
+	# Our diff algorithm
+	[diff]
+		external = "/usr/local/bin/gnu-diff -u"
+		renames = true
+
+Variables
+~~~~~~~~~
+
+Note that this list is non-comprehensive and not necessarily complete.
+For command-specific variables, you will find a more detailed description
+in the appropriate manual page. You will find a description of non-core
+porcelain configuration variables in the respective porcelain documentation.
+
+core.fileMode::
+	If false, the executable bit differences between the index and
+	the working copy are ignored; useful on broken filesystems like FAT.
+	See gitlink:git-update-index[1]. True by default.
+
+core.gitProxy::
+	A "proxy command" to execute (as 'command host port') instead
+	of establishing direct connection to the remote server when
+	using the git protocol for fetching. If the variable value is
+	in the "COMMAND for DOMAIN" format, the command is applied only
+	on hostnames ending with the specified domain string. This variable
+	may be set multiple times and is matched in the given order;
+	the first match wins.
++
+Can be overridden by the 'GIT_PROXY_COMMAND' environment variable
+(which always applies universally, without the special "for"
+handling).
+
+core.ignoreStat::
+	The working copy files are assumed to stay unchanged until you
+	mark them otherwise manually - Git will not detect the file changes
+	by lstat() calls. This is useful on systems where those are very
+	slow, such as Microsoft Windows.  See gitlink:git-update-index[1].
+	False by default.
+
+core.preferSymlinkRefs::
+	Instead of the default "symref" format for HEAD
+	and other symbolic reference files, use symbolic links.
+	This is sometimes needed to work with old scripts that
+	expect HEAD to be a symbolic link.
+
+core.logAllRefUpdates::
+	If true, `git-update-ref` will append a line to
+	"$GIT_DIR/logs/<ref>" listing the new SHA1 and the date/time
+	of the update.	If the file does not exist it will be
+	created automatically.	This information can be used to
+	determine what commit was the tip of a branch "2 days ago".
+	This value is false by default (no logging).
+
+core.repositoryFormatVersion::
+	Internal variable identifying the repository format and layout
+	version.
+
+core.sharedRepository::
+	If true, the repository is made shareable between several users
+	in a group (making sure all the files and objects are group-writable).
+	See gitlink:git-init-db[1]. False by default.
+
+core.warnAmbiguousRefs::
+	If true, git will warn you if the ref name you passed it is ambiguous
+	and might match multiple refs in the .git/refs/ tree. True by default.
+
+core.compression::
+	An integer -1..9, indicating the compression level for objects that
+	are not in a pack file. -1 is the zlib and git default. 0 means no
+	compression, and 1..9 are various speed/size tradeoffs, 9 being
+	slowest.
+
+core.legacyheaders::
+	A boolean which enables the legacy object header format in case
+	you want to interoperate with old clients accessing the object
+	database directly (where the "http://" and "rsync://" protocols
+	count as direct access).
+
+alias.*::
+	Command aliases for the gitlink:git[1] command wrapper - e.g.
+	after defining "alias.last = cat-file commit HEAD", the invocation
+	"git last" is equivalent to "git cat-file commit HEAD". To avoid
+	confusion and troubles with script usage, aliases that
+	hide existing git commands are ignored. Arguments are split by
+	spaces, the usual shell quoting and escaping is supported.
+	quote pair and a backslash can be used to quote them.
+
+apply.whitespace::
+	Tells `git-apply` how to handle whitespaces, in the same way
+	as the '--whitespace' option. See gitlink:git-apply[1].
+
+diff.color::
+	When true (or `always`), always use colors in patch.
+	When false (or `never`), never.  When set to `auto`, use
+	colors only when the output is to the terminal.
+
+diff.color.<slot>::
+	Use customized color for diff colorization.  `<slot>`
+	specifies which part of the patch to use the specified
+	color, and is one of `plain` (context text), `meta`
+	(metainformation), `frag` (hunk header), `old` (removed
+	lines), or `new` (added lines).  The value for these
+	configuration variables can be one of: `normal`, `bold`,
+	`dim`, `ul`, `blink`, `reverse`, `reset`, `black`,
+	`red`, `green`, `yellow`, `blue`, `magenta`, `cyan`, or
+	`white`.
+
+diff.renameLimit::
+	The number of files to consider when performing the copy/rename
+	detection; equivalent to the git diff option '-l'.
+
+diff.renames::
+	Tells git to detect renames.  If set to any boolean value, it
+	will enable basic rename detection.  If set to "copies" or
+	"copy", it will detect copies, as well.
+
+format.headers::
+	Additional email headers to include in a patch to be submitted
+	by mail.  See gitlink:git-format-patch[1].
+
+gitcvs.enabled::
+	Whether the cvs pserver interface is enabled for this repository.
+	See gitlink:git-cvsserver[1].
+
+gitcvs.logfile::
+	Path to a log file where the cvs pserver interface well... logs
+	various stuff. See gitlink:git-cvsserver[1].
+
+http.sslVerify::
+	Whether to verify the SSL certificate when fetching or pushing
+	over HTTPS. Can be overridden by the 'GIT_SSL_NO_VERIFY' environment
+	variable.
+
+http.sslCert::
+	File containing the SSL certificate when fetching or pushing
+	over HTTPS. Can be overridden by the 'GIT_SSL_CERT' environment
+	variable.
+
+http.sslKey::
+	File containing the SSL private key when fetching or pushing
+	over HTTPS. Can be overridden by the 'GIT_SSL_KEY' environment
+	variable.
+
+http.sslCAInfo::
+	File containing the certificates to verify the peer with when
+	fetching or pushing over HTTPS. Can be overridden by the
+	'GIT_SSL_CAINFO' environment variable.
+
+http.sslCAPath::
+	Path containing files with the CA certificates to verify the peer
+	with when fetching or pushing over HTTPS. Can be overridden
+	by the 'GIT_SSL_CAPATH' environment variable.
+
+http.maxRequests::
+	How many HTTP requests to launch in parallel. Can be overridden
+	by the 'GIT_HTTP_MAX_REQUESTS' environment variable. Default is 5.
+
+http.lowSpeedLimit, http.lowSpeedTime::
+	If the HTTP transfer speed is less than 'http.lowSpeedLimit'
+	for longer than 'http.lowSpeedTime' seconds, the transfer is aborted.
+	Can be overridden by the 'GIT_HTTP_LOW_SPEED_LIMIT' and
+	'GIT_HTTP_LOW_SPEED_TIME' environment variables.
+
+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
+	importing commits from emails or in the gitk graphical history
+	browser (and possibly at other places in the future or in other
+	porcelains). See e.g. gitlink:git-mailinfo[1]. Defaults to 'utf-8'.
+
+merge.summary::
+	Whether to include summaries of merged commits in newly created
+	merge commit messages. False by default.
+
+pack.window::
+	The size of the window used by gitlink:git-pack-objects[1] when no
+	window size is given on the command line. Defaults to 10.
+
+pull.octopus::
+	The default merge strategy to use when pulling multiple branches
+	at once.
+
+pull.twohead::
+	The default merge strategy to use when pulling a single branch.
+
+show.difftree::
+	The default gitlink:git-diff-tree[1] arguments to be used
+	for gitlink:git-show[1].
+
+showbranch.default::
+	The default set of branches for gitlink:git-show-branch[1].
+	See gitlink:git-show-branch[1].
+
+tar.umask::
+	By default, git-link:git-tar-tree[1] sets file and directories modes
+	to 0666 or 0777. While this is both useful and acceptable for projects
+	such as the Linux Kernel, it might be excessive for other projects.
+	With this variable, it becomes possible to tell
+	git-link:git-tar-tree[1] to apply a specific umask to the modes above.
+	The special value "user" indicates that the user's current umask will
+	be used. This should be enough for most projects, as it will lead to
+	the same permissions as git-link:git-checkout[1] would use. The default
+	value remains 0, which means world read-write.
+
+user.email::
+	Your email address to be recorded in any newly created commits.
+	Can be overridden by the 'GIT_AUTHOR_EMAIL' and 'GIT_COMMITTER_EMAIL'
+	environment variables.  See gitlink:git-commit-tree[1].
+
+user.name::
+	Your full name to be recorded in any newly created commits.
+	Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME'
+	environment variables.  See gitlink:git-commit-tree[1].
+
+whatchanged.difftree::
+	The default gitlink:git-diff-tree[1] arguments to be used
+	for gitlink:git-whatchanged[1].
+
+imap::
+	The configuration variables in the 'imap' section are described
+	in gitlink:git-imap-send[1].

Documentation/cvs-migration.txt

@@ -1,126 +1,182 @@
 git for CVS users
 =================
 
-Ok, so you're a CVS user. That's ok, it's a treatable condition, and the
+So you're a CVS user. That's OK, it's a treatable condition.  The job of
-first step to recovery is admitting you have a problem. The fact that
+this document is to put you on the road to recovery, by helping you
-you are reading this file means that you may be well on that path
+convert an existing cvs repository to git, and by showing you how to use a
-already.
+git repository in a cvs-like fashion.
 
-The thing about CVS is that it absolutely sucks as a source control
+Some basic familiarity with git is required.  This
-manager, and you'll thus be happy with almost anything else. git,
+link:tutorial.html[tutorial introduction to git] should be sufficient.
-however, may be a bit 'too' different (read: "good") for your taste, and
-does a lot of things differently. 
 
-One particular suckage of CVS is very hard to work around: CVS is
+First, note some ways that git differs from CVS:
-basically a tool for tracking 'file' history, while git is a tool for
-tracking 'project' history.  This sometimes causes problems if you are
-used to doing very strange things in CVS, in particular if you're doing
-things like making branches of just a subset of the project.  git can't
-track that, since git never tracks things on the level of an individual
-file, only on the whole project level. 
 
-The good news is that most people don't do that, and in fact most sane
+  * Commits are atomic and project-wide, not per-file as in CVS.
-people think it's a bug in CVS that makes it tag (and check in changes)
-one file at a time.  So most projects you'll ever see will use CVS
-'as if' it was sane.  In which case you'll find it very easy indeed to
-move over to git. 
 
-First off: this is not a git tutorial. See
+  * Offline work is supported: you can make multiple commits locally,
-link:tutorial.html[Documentation/tutorial.txt] for how git
+    then submit them when you're ready.
-actually works. This is more of a random collection of gotcha's
-and notes on converting from CVS to git.
 
-Second: CVS has the notion of a "repository" as opposed to the thing
+  * Branching is fast and easy.
-that you're actually working in (your working directory, or your
-"checked out tree").  git does not have that notion at all, and all git
-working directories 'are' the repositories.  However, you can easily
-emulate the CVS model by having one special "global repository", which
-people can synchronize with.  See details later, but in the meantime
-just keep in mind that with git, every checked out working tree will
-have a full revision control history of its own.
 
+  * Every working tree contains a repository with a full copy of the
+    project history, and no repository is inherently more important than
+    any other.  However, you can emulate the CVS model by designating a
+    single shared repository which people can synchronize with; see below
+    for details.
 
 Importing a CVS archive
 -----------------------
 
-Ok, you have an old project, and you want to at least give git a chance
+First, install version 2.1 or higher of cvsps from
-to see how it performs. The first thing you want to do (after you've
+link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make
-gone through the git tutorial, and generally familiarized yourself with
+sure it is in your path.  The magic command line is then
-how to commit stuff etc in git) is to create a git'ified version of your
-CVS archive.
 
-Happily, that's very easy indeed. git will do it for you, although git
+-------------------------------------------
-will need the help of a program called "cvsps":
+$ git cvsimport -v -d <cvsroot> -C <destination> <module>
+-------------------------------------------
 
-	http://www.cobite.com/cvsps/
+This puts a git archive of the named CVS module in the directory
+<destination>, which will be created if necessary.  The -v option makes
+the conversion script very chatty.
 
-which is not actually related to git at all, but which makes CVS usage
+The import checks out from CVS every revision of every file.  Reportedly
-look almost sane (ie you almost certainly want to have it even if you
+cvsimport can average some twenty revisions per second, so for a
-decide to stay with CVS). However, git will want 'at least' version 2.1
+medium-sized project this should not take more than a couple of minutes.
-of cvsps (available at the address above), and in fact will currently
+Larger projects or remote repositories may take longer.
-refuse to work with anything else.
 
-Once you've gotten (and installed) cvsps, you may or may not want to get
+The main trunk is stored in the git branch named `origin`, and additional
-any more familiar with it, but make sure it is in your path. After that,
+CVS branches are stored in git branches with the same names.  The most
-the magic command line is
+recent version of the main trunk is also left checked out on the `master`
+branch, so you can start adding your own changes right away.
 
-	git cvsimport -v -d <cvsroot> -C <destination> <module>
+The import is incremental, so if you call it again next month it will
+fetch any CVS updates that have been made in the meantime.  For this to
+work, you must not modify the imported branches; instead, create new
+branches for your own changes, and merge in the imported branches as
+necessary.
 
-which will do exactly what you'd think it does: it will create a git
+Development Models
-archive of the named CVS module. The new archive will be created in the
+------------------
-subdirectory named <destination>; it'll be created if it doesn't exist.
-Default is the local directory.
 
-It can take some time to actually do the conversion for a large archive
+CVS users are accustomed to giving a group of developers commit access to
-since it involves checking out from CVS every revision of every file,
+a common repository.  In the next section we'll explain how to do this
-and the conversion script is reasonably chatty unless you omit the '-v'
+with git.  However, the distributed nature of git allows other development
-option, but on some not very scientific tests it averaged about twenty
+models, and you may want to first consider whether one of them might be a
-revisions per second, so a medium-sized project should not take more
+better fit for your project.
-than a couple of minutes.  For larger projects or remote repositories,
-the process may take longer.
 
-After the (initial) import is done, the CVS archive's current head
+For example, you can choose a single person to maintain the project's
-revision will be checked out -- thus, you can start adding your own
+primary public repository.  Other developers then clone this repository
-changes right away.
+and each work in their own clone.  When they have a series of changes that
+they're happy with, they ask the maintainer to pull from the branch
+containing the changes.  The maintainer reviews their changes and pulls
+them into the primary repository, which other developers pull from as
+necessary to stay coordinated.  The Linux kernel and other projects use
+variants of this model.
 
-The import is incremental, i.e. if you call it again next month it'll
+With a small group, developers may just pull changes from each other's
-fetch any CVS updates that have been happening in the meantime. The
+repositories without the need for a central maintainer.
-cut-off is date-based, so don't change the branches that were imported
-from CVS.
 
-You can merge those updates (or, in fact, a different CVS branch) into
+Emulating the CVS Development Model
-your main branch:
+-----------------------------------
 
-	git resolve HEAD origin "merge with current CVS HEAD"
+Start with an ordinary git working directory containing the project, and
+remove the checked-out files, keeping just the bare .git directory:
 
-The HEAD revision from CVS is named "origin", not "HEAD", because git
+------------------------------------------------
-already uses "HEAD". (If you don't like 'origin', use cvsimport's
+$ mv project/.git /pub/repo.git
-'-o' option to change it.)
+$ rm -r project/
+------------------------------------------------
 
+Next, give every team member read/write access to this repository.  One
+easy way to do this is to give all the team members ssh access to the
+machine where the repository is hosted.  If you don't want to give them a
+full shell on the machine, there is a restricted shell which only allows
+users to do git pushes and pulls; see gitlink:git-shell[1].
 
-Emulating CVS behaviour
+Put all the committers in the same group, and make the repository
------------------------
+writable by that group:
 
+------------------------------------------------
+$ chgrp -R $group repo.git
+$ find repo.git -mindepth 1 -type d |xargs chmod ug+rwx,g+s
+$ GIT_DIR=repo.git git repo-config core.sharedrepository true
+------------------------------------------------
 
-So, by now you are convinced you absolutely want to work with git, but
+Make sure committers have a umask of at most 027, so that the directories
-at the same time you absolutely have to have a central repository.
+they create are writable and searchable by other group members.
-Step back and think again. Okay, you still need a single central
-repository? There are several ways to go about that:
 
-1. Designate a person responsible to pull all branches. Make the
+Suppose this repository is now set up in /pub/repo.git on the host
-repository of this person public, and make every team member
+foo.com.  Then as an individual committer you can clone the shared
-pull regularly from it.
+repository:
 
-2. Set up a public repository with read/write access for every team
+------------------------------------------------
-member. Use "git pull/push" as you used "cvs update/commit".  Be
+$ git clone foo.com:/pub/repo.git/ my-project
-sure that your repository is up to date before pushing, just
+$ cd my-project
-like you used to do with "cvs commit"; your push will fail if
+------------------------------------------------
-what you are pushing is not up to date.
 
-3. Make the repository of every team member public. It is the
+and hack away.  The equivalent of `cvs update` is
-responsibility of each single member to pull from every other
-team member.
 
+------------------------------------------------
+$ git pull origin
+------------------------------------------------
+
+which merges in any work that others might have done since the clone
+operation.
+
+[NOTE]
+================================
+The first `git clone` places the following in the
+`my-project/.git/remotes/origin` file, and that's why the previous step
+and the next step both work.
+------------
+URL: foo.com:/pub/project.git/ my-project
+Pull: master:origin
+------------
+================================
+
+You can update the shared repository with your changes using:
+
+------------------------------------------------
+$ git push origin master
+------------------------------------------------
+
+If someone else has updated the repository more recently, `git push`, like
+`cvs commit`, will complain, in which case you must pull any changes
+before attempting the push again.
+
+In the `git push` command above we specify the name of the remote branch
+to update (`master`).  If we leave that out, `git push` tries to update
+any branches in the remote repository that have the same name as a branch
+in the local repository.  So the last `push` can be done with either of:
+
+------------
+$ git push origin
+$ git push repo.shared.xz:/pub/scm/project.git/
+------------
+
+as long as the shared repository does not have any branches
+other than `master`.
+
+[NOTE]
+============
+Because of this behavior, if the shared repository and the developer's
+repository both have branches named `origin`, then a push like the above
+attempts to update the `origin` branch in the shared repository from the
+developer's `origin` branch.  The results may be unexpected, so it's
+usually best to remove any branch named `origin` from the shared
+repository.
+============
+
+Advanced Shared Repository Management
+-------------------------------------
+
+Git allows you to specify scripts called "hooks" to be run at certain
+points.  You can use these, for example, to send all commits to the shared
+repository to a mailing list.  See link:hooks.txt[Hooks used by git].
+
+You can enforce finer grained permissions using update hooks.  See
+link:howto/update-hook-example.txt[Controlling access to branches using
+update hooks].
 
 CVS annotate
 ------------

Documentation/diff-format.txt

@@ -146,3 +146,52 @@ the file that rename/copy produces, respectively.
 
 3.  TAB, LF, and backslash characters in pathnames are
     represented as `\t`, `\n`, and `\\`, respectively.
+
+
+combined diff format
+--------------------
+
+git-diff-tree and git-diff-files can take '-c' or '--cc' option
+to produce 'combined diff', which looks like this:
+
+------------
+diff --combined describe.c
+@@@ +98,7 @@@
+   return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
+  }
+
+- static void describe(char *arg)
+ -static void describe(struct commit *cmit, int last_one)
+++static void describe(char *arg, int last_one)
+  {
+ +     unsigned char sha1[20];
+ +     struct commit *cmit;
+------------
+
+Unlike the traditional 'unified' diff format, which shows two
+files A and B with a single column that has `-` (minus --
+appears in A but removed in B), `+` (plus -- missing in A but
+added to B), or ` ` (space -- unchanged) prefix, this format
+compares two or more files file1, file2,... with one file X, and
+shows how X differs from each of fileN.  One column for each of
+fileN is prepended to the output line to note how X's line is
+different from it.
+
+A `-` character in the column N means that the line appears in
+fileN but it does not appear in the last file.  A `+` character
+in the column N means that the line appears in the last file,
+and fileN does not have that line.
+
+In the above example output, the function signature was changed
+from both files (hence two `-` removals from both file1 and
+file2, plus `++` to mean one line that was added does not appear
+in either file1 nor file2).  Also two other lines are the same
+from file1 but do not appear in file2 (hence prefixed with ` +`).
+
+When shown by `git diff-tree -c`, it compares the parents of a
+merge commit with the merge result (i.e. file1..fileN are the
+parents).  When shown by `git diff-files -c`, it compares the
+two unresolved merge parents with the working tree file
+(i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka
+"their version").
+

Documentation/diff-options.txt

@@ -4,6 +4,22 @@
 -u::
 	Synonym for "-p".
 
+--raw::
+	Generate the raw format.
+
+--patch-with-raw::
+	Synonym for "-p --raw".
+
+--stat::
+	Generate a diffstat.
+
+--summary::
+	Output a condensed summary of extended header information
+	such as creations, renames and mode changes.
+
+--patch-with-stat::
+	Synonym for "-p --stat".
+
 -z::
 	\0 line termination on output
 
@@ -13,10 +29,25 @@
 --name-status::
 	Show only names and status of changed files.
 
+--color::
+	Show colored diff.
+
+--no-color::
+	Turn off colored diff, even when the configuration file
+	gives the default to color output.
+
+--no-renames::
+	Turn off rename detection, even when the configuration
+	file gives the default to do so.
+
 --full-index::
 	Instead of the first handful characters, show full
 	object name of pre- and post-image blob on the "index"
-	line when generating a patch format output.	
+	line when generating a patch format output.
+
+--binary::
+	In addition to --full-index, output "binary diff" that
+	can be applied with "git apply".
 
 --abbrev[=<n>]::
 	Instead of showing the full 40-byte hexadecimal object
@@ -35,6 +66,17 @@
 -C::
 	Detect copies as well as renames.
 
+--diff-filter=[ACDMRTUXB*]::
+	Select only files that are Added (`A`), Copied (`C`),
+	Deleted (`D`), Modified (`M`), Renamed (`R`), have their
+	type (mode) changed (`T`), are Unmerged (`U`), are
+	Unknown (`X`), or have had their pairing Broken (`B`).
+	Any combination of the filter characters may be used.
+	When `*` (All-or-none) is added to the combination, all
+	paths are selected if there is any file that matches
+	other criteria in the comparison; if there is no file
+	that matches other criteria, nothing is selected.
+
 --find-copies-harder::
 	For performance reasons, by default, -C option finds copies only 
 	if the original file of the copy was modified in the same 
@@ -58,6 +100,10 @@
 	changeset, not just the files that contain the change
 	in <string>.
 
+--pickaxe-regex::
+	Make the <string> not a plain string but an extended POSIX
+	regex to match.
+
 -O<orderfile>::
 	Output the patch in the order specified in the
 	<orderfile>, which has one shell glob pattern per line.
@@ -66,5 +112,11 @@
 	Swap two inputs; that is, show differences from index or
 	on-disk file to tree contents.
 
+--text::
+	Treat all files as text.
+
+-a::
+	Shorthand for "--text".
+
 For more detailed explanation on these common options, see also
 link:diffcore.html[diffcore documentation].

Documentation/everyday.txt

@@ -45,7 +45,7 @@ Everybody uses these commands to feed and care git repositories.
 
   * gitlink:git-fsck-objects[1] to validate the repository.
 
-  * gitlink:git-prune[1] to garbage collect crufts in the
+  * gitlink:git-prune[1] to garbage collect cruft in the
     repository.
 
   * gitlink:git-repack[1] to pack loose objects for efficiency.
@@ -61,32 +61,32 @@ $ git prune
 $ git count-objects <2>
 $ git repack <3>
 $ git prune <4>
-
+------------
++
 <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
-diskspace is wasted by not repacking.
+disk space is wasted by not repacking.
 <3> without "-a" repacks incrementally.  repacking every 4-5MB
 of loose objects accumulation may be a good rule of thumb.
 <4> after repack, prune removes the duplicate loose objects.
-------------
 
 Repack a small project into single pack.::
 +
 ------------
 $ git repack -a -d <1>
 $ git prune
-
+------------
++
 <1> pack all the objects reachable from the refs into one pack
 and remove unneeded other packs
-------------
 
 
 Individual Developer (Standalone)[[Individual Developer (Standalone)]]
 ----------------------------------------------------------------------
 
 A standalone individual developer does not exchange patches with
-other poeple, and works alone in a single repository, using the
+other people, and works alone in a single repository, using the
 following commands.
 
   * gitlink:git-show-branch[1] to see where you are.
@@ -129,10 +129,10 @@ $ git-init-db
 $ git add . <1>
 $ git commit -m 'import of frotz source tree.'
 $ git tag v2.43 <2>
-
+------------
++
 <1> add everything under the current directory.
 <2> make a lightweight, unannotated tag.
-------------
 
 Create a topic branch and develop.::
 +
@@ -153,7 +153,8 @@ $ git checkout master <9>
 $ git pull . alsa-audio <10>
 $ git log --since='3 days ago' <11>
 $ git log v2.43.. curses/ <12>
-
+------------
++
 <1> create a new topic branch.
 <2> revert your botched changes in "curses/ux_audio_oss.c".
 <3> you need to tell git if you added a new file; removal and
@@ -170,7 +171,6 @@ you originally wrote.
 combined and include --max-count=10 (show 10 commits), --until='2005-12-10'.
 <12> view only the changes that touch what's in curses/
 directory, since v2.43 tag.
-------------
 
 
 Individual Developer (Participant)[[Individual Developer (Participant)]]
@@ -208,7 +208,8 @@ $ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>
 $ git reset --hard ORIG_HEAD <6>
 $ git prune <7>
 $ git fetch --tags <8>
-
+------------
++
 <1> repeat as needed.
 <2> extract patches from your branch for e-mail submission.
 <3> "pull" fetches from "origin" by default and merges into the
@@ -221,7 +222,6 @@ area we are interested in.
 <7> garbage collect leftover objects from reverted pull.
 <8> from time to time, obtain official tags from the "origin"
 and store them under .git/refs/tags/.
-------------
 
 
 Push into another repository.::
@@ -239,7 +239,8 @@ satellite$ git push origin <4>
 mothership$ cd frotz
 mothership$ git checkout master
 mothership$ git pull . satellite <5>
-
+------------
++
 <1> mothership machine has a frotz repository under your home
 directory; clone from it to start a repository on the satellite
 machine.
@@ -252,7 +253,6 @@ to local "origin" branch.
 mothership machine.  You could use this as a back-up method.
 <5> on mothership machine, merge the work done on the satellite
 machine into the master branch.
-------------
 
 Branch off of a specific tag.::
 +
@@ -262,12 +262,12 @@ $ edit/compile/test; git commit -a
 $ git checkout master
 $ git format-patch -k -m --stdout v2.6.14..private2.6.14 |
   git am -3 -k <2>
-
+------------
++
 <1> create a private branch based on a well known (but somewhat behind)
 tag.
 <2> forward port all changes in private2.6.14 branch to master branch
 without a formal "merging".
-------------
 
 
 Integrator[[Integrator]]
@@ -317,7 +317,8 @@ $ git tag -s -m 'GIT 0.99.9x' v0.99.9x <10>
 $ git fetch ko && git show-branch master maint 'tags/ko-*' <11>
 $ git push ko <12>
 $ git push ko v0.99.9x <13>
-
+------------
++
 <1> see what I was in the middle of doing, if any.
 <2> see what topic branches I have and think about how ready
 they are.
@@ -335,18 +336,22 @@ master, nor exposed as a part of a stable branch.
 <11> make sure I did not accidentally rewind master beyond what I
 already pushed out.  "ko" shorthand points at the repository I have
 at kernel.org, and looks like this:
-    $ cat .git/remotes/ko
++
-    URL: kernel.org:/pub/scm/git/git.git
+------------
-    Pull: master:refs/tags/ko-master
+$ cat .git/remotes/ko
-    Pull: maint:refs/tags/ko-maint
+URL: kernel.org:/pub/scm/git/git.git
-    Push: master
+Pull: master:refs/tags/ko-master
-    Push: +pu
+Pull: maint:refs/tags/ko-maint
-    Push: maint
+Push: master
+Push: +pu
+Push: maint
+------------
++
 In the output from "git show-branch", "master" should have
 everything "ko-master" has.
+
 <12> push out the bleeding edge.
 <13> push the tag out, too.
-------------
 
 
 Repository Administration[[Repository Administration]]
@@ -367,17 +372,39 @@ example of managing a shared central repository.
 
 Examples
 ~~~~~~~~
-
 Run git-daemon to serve /pub/scm from inetd.::
 +
 ------------
-$ grep git /etc/inet.conf
+$ grep git /etc/inetd.conf
 git	stream	tcp	nowait	nobody \
   /usr/bin/git-daemon git-daemon --inetd --syslog --export-all /pub/scm
 ------------
 +
 The actual configuration line should be on one line.
 
+Run git-daemon to serve /pub/scm from xinetd.::
++
+------------
+$ cat /etc/xinetd.d/git-daemon
+# default: off
+# description: The git server offers access to git repositories
+service git
+{
+        disable = no
+        type            = UNLISTED
+        port            = 9418
+        socket_type     = stream
+        wait            = no
+        user            = nobody
+        server          = /usr/bin/git-daemon
+        server_args     = --inetd --syslog --export-all --base-path=/pub/scm
+        log_on_failure  += USERID
+}
+------------
++
+Check your xinetd(8) documentation and setup, this is from a Fedora system.
+Others might be different.
+
 Give push/pull only access to developers.::
 +
 ------------
@@ -388,13 +415,13 @@ cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
 david:x:1003:1003::/home/david:/usr/bin/git-shell
 $ grep git /etc/shells <2>
 /usr/bin/git-shell
-
+------------
++
 <1> log-in shell is set to /usr/bin/git-shell, which does not
 allow anything but "git push" and "git pull".  The users should
 get an ssh access to the machine.
 <2> in many distributions /etc/shells needs to list what is used
 as the login shell.
-------------
 
 CVS-style shared repository.::
 +
@@ -419,7 +446,8 @@ $ cat info/allowed-users <4>
 refs/heads/master	alice\|cindy
 refs/heads/doc-update	bob
 refs/tags/v[0-9]*	david
-
+------------
++
 <1> place the developers into the same git group.
 <2> and make the shared repository writable by the group.
 <3> use update-hook example by Carl from Documentation/howto/
@@ -427,7 +455,6 @@ for branch policy control.
 <4> alice and cindy can push into master, only bob can push into doc-update.
 david is the release manager and is the only person who can
 create and push version tags.
-------------
 
 HTTP server to support dumb protocol transfer.::
 +
@@ -435,7 +462,7 @@ HTTP server to support dumb protocol transfer.::
 dev$ git update-server-info <1>
 dev$ ftp user@isp.example.com <2>
 ftp> cp -r .git /home/user/myproject.git
-
+------------
++
 <1> make sure your info/refs and objects/info/packs are up-to-date
 <2> upload to public HTTP server hosted by your ISP.
-------------

Documentation/fetch-options.txt

@@ -3,6 +3,12 @@
 	existing contents of `.git/FETCH_HEAD`.  Without this
 	option old data in `.git/FETCH_HEAD` will be overwritten.
 
+\--upload-pack <upload-pack>::
+        When given, and the repository to fetch from is handled
+        by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
+        the command to specify non-default path for the command
+        run on the other end.
+
 -f, \--force::
 	When `git-fetch` is used with `<rbranch>:<lbranch>`
 	refspec, it refuses to update the local branch
@@ -10,15 +16,26 @@
 	fetches is a descendant of `<lbranch>`.  This option
 	overrides that check.
 
+\--no-tags::
+	By default, `git-fetch` fetches tags that point at
+	objects that are downloaded from the remote repository
+	and stores them locally.  This option disables this
+	automatic tag following.
+
 -t, \--tags::
-	By default, the git core utilities will not fetch and store
+	Most of the tags are fetched automatically as branch
-	tags under the same name as the remote repository;  ask it
+	heads are downloaded, but tags that do not point at
-	to do so using `--tags`.  Using this option will bound the
+	objects reachable from the branch heads that are being
-	list of objects pulled to the remote tags.  Commits in branches
+	tracked will not be fetched by this mechanism.  This
-	beyond the tags will be ignored.
+	flag lets all tags and their associated objects be
+	downloaded.
+
+-k, \--keep::
+	Keep downloaded pack.
 
 -u, \--update-head-ok::
 	By default `git-fetch` refuses to update the head which
 	corresponds to the current branch.  This flag disables the
 	check.  Note that fetching into the current branch will not
 	update the index and working directory, so use it with care.
+

Documentation/git-add.txt

@@ -3,22 +3,24 @@ git-add(1)
 
 NAME
 ----
-git-add - Add files to the index file.
+git-add - Add files to the index file
 
 SYNOPSIS
 --------
-'git-add' [-n] [-v] <file>...
+'git-add' [-n] [-v] [--] <file>...
 
 DESCRIPTION
 -----------
 A simple wrapper for git-update-index to add files to the index,
 for people used to do "cvs add".
 
+It only adds non-ignored files, to add ignored files use
+"git update-index --add".
 
 OPTIONS
 -------
 <file>...::
-	Files to add to the index.
+	Files to add to the index (see gitlink:git-ls-files[1]).
 
 -n::
         Don't actually add the file(s), just show if they exist.
@@ -26,6 +28,11 @@ OPTIONS
 -v::
         Be verbose.
 
+\--::
+	This option can be used to separate command-line options from
+	the list of files, (useful when filenames might be mistaken
+	for command-line options).
+
 
 DISCUSSION
 ----------
@@ -60,6 +67,10 @@ git-add git-*.sh::
 	(i.e. you are listing the files explicitly), it does not
 	add `subdir/git-foo.sh` to the index.
 
+See Also
+--------
+gitlink:git-rm[1]
+gitlink:git-ls-files[1]
 
 Author
 ------

Documentation/git-am.txt

@@ -9,7 +9,8 @@ git-am - Apply a series of patches in a mailbox
 SYNOPSIS
 --------
 [verse]
-'git-am' [--signoff] [--dotest=<dir>] [--utf8] [--binary] [--3way] <mbox>...
+'git-am' [--signoff] [--dotest=<dir>] [--utf8] [--binary] [--3way]
+         [--interactive] [--whitespace=<option>] <mbox>...
 'git-am' [--skip | --resolved]
 
 DESCRIPTION
@@ -46,6 +47,10 @@ OPTIONS
 	Skip the current patch.  This is only meaningful when
 	restarting an aborted patch.
 
+--whitespace=<option>::
+	This flag is passed to the `git-apply` program that applies
+	the patch.
+
 --interactive::
 	Run interactively, just like git-applymbox.
 
@@ -80,7 +85,7 @@ names.
 
 SEE ALSO
 --------
-gitlink:git-applymbox[1], gitlink:git-applypatch[1].
+gitlink:git-applymbox[1], gitlink:git-applypatch[1], gitlink:git-apply[1].
 
 
 Author

Documentation/git-annotate.txt

@@ -0,0 +1,44 @@
+git-annotate(1)
+===============
+
+NAME
+----
+git-annotate - Annotate file lines with commit info
+
+SYNOPSIS
+--------
+git-annotate [options] file [revision]
+
+DESCRIPTION
+-----------
+Annotates each line in the given file with information from the commit
+which introduced the line. Optionally annotate from a given revision.
+
+OPTIONS
+-------
+-l, --long::
+	Show long rev (Defaults off).
+
+-t, --time::
+	Show raw timestamp (Defaults off).
+
+-r, --rename::
+	Follow renames (Defaults on).
+
+-S, --rev-file <revs-file>::
+	Use revs from revs-file instead of calling git-rev-list.
+
+-h, --help::
+	Show help message.
+
+SEE ALSO
+--------
+gitlink:git-blame[1]
+
+AUTHOR
+------
+Written by Ryan Anderson <ryan@michonline.com>.
+
+GIT
+---
+Part of the gitlink:git[7] suite

Documentation/git-apply.txt

@@ -10,7 +10,8 @@ SYNOPSIS
 --------
 [verse]
 'git-apply' [--stat] [--numstat] [--summary] [--check] [--index] [--apply]
-	  [--no-add] [--index-info] [--allow-binary-replacement] [-z]
+	  [--no-add] [--index-info] [--allow-binary-replacement] [-z] [-pNUM]
+	  [-CNUM] [--whitespace=<nowarn|warn|error|error-all|strip>]
 	  [<patch>...]
 
 DESCRIPTION
@@ -68,6 +69,16 @@ OPTIONS
 	backslash characters replaced with `\t`, `\n`, and `\\`,
 	respectively.
 
+-p<n>::
+	Remove <n> leading slashes from traditional diff paths. The
+	default is 1.
+
+-C<n>::
+	Ensure at least <n> lines of surrounding context match before
+	and after each change.  When fewer lines of surrounding
+	context exist they all must match.  By default no context is
+	ever ignored.
+
 --apply::
 	If you use any of the options marked ``Turns off
 	"apply"'' above, git-apply reads and outputs the
@@ -93,6 +104,35 @@ OPTIONS
 	result.  This allows binary files to be patched in a
 	very limited way.
 
+--whitespace=<option>::
+	When applying a patch, detect a new or modified line
+	that ends with trailing whitespaces (this includes a
+	line that solely consists of whitespaces).  By default,
+	the command outputs warning messages and applies the
+	patch.
+	When `git-apply` is used for statistics and not applying a
+	patch, it defaults to `nowarn`.
+	You can use different `<option>` to control this
+	behavior:
++
+* `nowarn` turns off the trailing whitespace warning.
+* `warn` outputs warnings for a few such errors, but applies the
+  patch (default).
+* `error` outputs warnings for a few such errors, and refuses
+  to apply the patch.
+* `error-all` is similar to `error` but shows all errors.
+* `strip` outputs warnings for a few such errors, strips out the
+  trailing whitespaces and applies the patch.
+
+
+Configuration
+-------------
+
+apply.whitespace::
+	When no `--whitespace` flag is given from the command
+	line, this configuration item is used as the default.
+
+
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org>

Documentation/git-applypatch.txt

@@ -3,7 +3,7 @@ git-applypatch(1)
 
 NAME
 ----
-git-applypatch - Apply one patch extracted from an e-mail.
+git-applypatch - Apply one patch extracted from an e-mail
 
 
 SYNOPSIS

Documentation/git-archimport.txt

@@ -9,7 +9,7 @@ git-archimport - Import an Arch repository into git
 SYNOPSIS
 --------
 [verse]
-`git-archimport` [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
+'git-archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
                <archive/branch> [ <archive/branch> ]
 
 DESCRIPTION

Documentation/git-blame.txt

@@ -0,0 +1,45 @@
+git-blame(1)
+============
+
+NAME
+----
+git-blame - Blame file lines on commits
+
+SYNOPSIS
+--------
+git-blame file [options] file [revision]
+
+DESCRIPTION
+-----------
+Annotates each line in the given file with information from the commit
+which introduced the line. Start annotation from the given revision.
+
+OPTIONS
+-------
+-c, --compatibility::
+	Use the same output mode as git-annotate (Default: off).
+
+-l, --long::
+	Show long rev (Default: off).
+
+-t, --time::
+	Show raw timestamp (Default: off).
+
+-S, --rev-file <revs-file>::
+	Use revs from revs-file instead of calling git-rev-list.
+
+-h, --help::
+	Show help message.
+
+
+SEE ALSO
+--------
+gitlink:git-annotate[1]
+
+AUTHOR
+------
+Written by Fredrik Kuivinen <freku045@student.liu.se>.
+
+GIT
+---
+Part of the gitlink:git[7] suite

Documentation/git-branch.txt

@@ -3,19 +3,29 @@ git-branch(1)
 
 NAME
 ----
-git-branch - Create a new branch, or remove an old one.
+git-branch - List, create, or delete branches.
 
 SYNOPSIS
 --------
-'git-branch' [-d | -D] [<branchname> [start-point]]
+[verse]
+'git-branch' [-r]
+'git-branch' [-l] [-f] <branchname> [<start-point>]
+'git-branch' (-d | -D) <branchname>...
 
 DESCRIPTION
 -----------
-If no argument is provided, show available branches and mark current
+With no arguments given (or just `-r`) a list of available branches
-branch with star. Otherwise, create a new branch of name <branchname>.
+will be shown, the current branch will be highlighted with an asterisk.
+
+In its second form, a new branch named <branchname> will be created.
+It will start out with a head equal to the one given as <start-point>.
+If no <start-point> is given, the branch will be created with a head
+equal to that of the currently checked out branch.
+
+With a `-d` or `-D` option, `<branchname>` will be deleted.  You may
+specify more than one branch for deletion.  If the branch currently
+has a ref log then the ref log will also be deleted.
 
-If a starting point is also specified, that will be where the branch is
-created, otherwise it will be created at the current HEAD.
 
 OPTIONS
 -------
@@ -25,38 +35,65 @@ OPTIONS
 -D::
 	Delete a branch irrespective of its index status.
 
+-l::
+	Create the branch's ref log.  This activates recording of
+	all changes to made the branch ref, enabling use of date
+	based sha1 expressions such as "<branchname>@{yesterday}".
+
+-f::
+	Force the creation of a new branch even if it means deleting
+	a branch that already exists with the same name.
+
+-r::
+	List only the "remote" branches.
+
 <branchname>::
 	The name of the branch to create or delete.
+	The new branch name must pass all checks defined by
+	gitlink:git-check-ref-format[1].  Some of these checks
+	may restrict the characters allowed in a branch name.
+
+<start-point>::
+	The new branch will be created with a HEAD equal to this.  It may
+	be given as a branch name, a commit-id, or a tag.  If this option
+	is omitted, the current branch is assumed.
 
-start-point::
-	Where to create the branch; defaults to HEAD. This
-	option has no meaning with -d and -D.
 
 
 Examples
-~~~~~~~~
+--------
 
-Start development off of a know tag::
+Start development off of a known tag::
 +
 ------------
 $ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
 $ cd my2.6
-$ git branch my2.6.14 v2.6.14 <1>
+$ git branch my2.6.14 v2.6.14   <1>
 $ git checkout my2.6.14
-
-<1> These two steps are the same as "checkout -b my2.6.14 v2.6.14".
 ------------
++
+<1> This step and the next one could be combined into a single step with
+"checkout -b my2.6.14 v2.6.14".
 
 Delete unneeded branch::
 +
 ------------
 $ git clone git://git.kernel.org/.../git.git my.git
 $ cd my.git
-$ git branch -D todo <1>
+$ git branch -D todo    <1>
-
+------------
++
 <1> delete todo branch even if the "master" branch does not have all
 commits from todo branch.
-------------
+
+
+Notes
+-----
+
+If you are creating a branch that you want to immediately checkout, it's
+easier to use the git checkout command with its `-b` option to create
+a branch and check it out with a single command.
+
 
 Author
 ------

Documentation/git-cat-file.txt

@@ -8,12 +8,12 @@ git-cat-file - Provide content or type information for repository objects
 
 SYNOPSIS
 --------
-'git-cat-file' [-t | -s | -e | <type>] <object>
+'git-cat-file' [-t | -s | -e | -p | <type>] <object>
 
 DESCRIPTION
 -----------
 Provides content or type of objects in the repository. The type
-is required unless '-t' is used to find the object type,
+is required unless '-t' or '-p' is used to find the object type,
 or '-s' is used to find the object size.
 
 OPTIONS
@@ -33,6 +33,9 @@ OPTIONS
 	Suppress all output; instead exit with zero status if <object>
 	exists and is a valid object.
 
+-p::
+	Pretty-print the contents of <object> based on its type.
+
 <type>::
 	Typically this matches the real type of <object> but asking
 	for a type that can trivially be dereferenced from the given
@@ -49,6 +52,8 @@ If '-s' is specified, the size of the <object> in bytes.
 
 If '-e' is specified, no output.
 
+If '-p' is specified, the contents of <object> are pretty-printed.
+
 Otherwise the raw (though uncompressed) contents of the <object> will
 be returned.
 

Documentation/git-check-ref-format.txt

@@ -3,7 +3,7 @@ git-check-ref-format(1)
 
 NAME
 ----
-git-check-ref-format - Make sure ref name is well formed.
+git-check-ref-format - Make sure ref name is well formed
 
 SYNOPSIS
 --------
@@ -19,8 +19,9 @@ branch head is stored under `$GIT_DIR/refs/heads` directory, and
 a tag is stored under `$GIT_DIR/refs/tags` directory.  git
 imposes the following rules on how refs are named:
 
-. It could be named hierarchically (i.e. separated with slash
+. It can include slash `/` for hierarchical (directory)
-  `/`), but each of its component cannot begin with a dot `.`;
+  grouping, but no slash-separated component can begin with a
+  dot `.`;
 
 . It cannot have two consecutive dots `..` anywhere;
 
@@ -45,6 +46,8 @@ refname expressions (see gitlink:git-rev-parse[1]).  Namely:
 
 . colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
   value and store it in dstref" in fetch and push operations.
+  It may also be used to select a specific object such as with
+  gitlink:git-cat-file[1] "git-cat-file blob v1.3.3:refs.c".
 
 
 GIT

Documentation/git-checkout-index.txt

@@ -10,7 +10,10 @@ SYNOPSIS
 --------
 [verse]
 'git-checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
-		   [--stage=<number>] [--] <file>...
+		   [--stage=<number>|all]
+		   [--temp]
+		   [-z] [--stdin]
+		   [--] [<file>]\*
 
 DESCRIPTION
 -----------
@@ -41,11 +44,26 @@ OPTIONS
 	When creating files, prepend <string> (usually a directory
 	including a trailing /)
 
---stage=<number>::
+--stage=<number>|all::
 	Instead of checking out unmerged entries, copy out the
 	files from named stage.  <number> must be between 1 and 3.
+	Note: --stage=all automatically implies --temp.
 
---::
+--temp::
+	Instead of copying the files to the working directory
+	write the content to temporary files.  The temporary name
+	associations will be written to stdout.
+
+--stdin::
+	Instead of taking list of paths from the command line,
+	read list of paths from the standard input.  Paths are
+	separated by LF (i.e. one path per line) by default.
+
+-z::
+	Only meaningful with `--stdin`; paths are separated with
+	NUL character instead of LF.
+
+\--::
 	Do not interpret any more arguments as options.
 
 The order of the flags used to matter, but not anymore.
@@ -64,13 +82,58 @@ $ find . -name '*.h' -print0 | xargs -0 git-checkout-index -f --
 
 which will force all existing `*.h` files to be replaced with their
 cached copies. If an empty command line implied "all", then this would
-force-refresh everything in the index, which was not the point.
+force-refresh everything in the index, which was not the point.  But
+since git-checkout-index accepts --stdin it would be faster to use:
+
+----------------
+$ find . -name '*.h' -print0 | git-checkout-index -f -z --stdin
+----------------
 
 The `--` is just a good idea when you know the rest will be filenames;
 it will prevent problems with a filename of, for example,  `-a`.
 Using `--` is probably a good policy in scripts.
 
 
+Using --temp or --stage=all
+---------------------------
+When `--temp` is used (or implied by `--stage=all`)
+`git-checkout-index` will create a temporary file for each index
+entry being checked out.  The index will not be updated with stat
+information.  These options can be useful if the caller needs all
+stages of all unmerged entries so that the unmerged files can be
+processed by an external merge tool.
+
+A listing will be written to stdout providing the association of
+temporary file names to tracked path names.  The listing format
+has two variations:
+
+    . tempname TAB path RS
++
+The first format is what gets used when `--stage` is omitted or
+is not `--stage=all`. The field tempname is the temporary file
+name holding the file content and path is the tracked path name in
+the index.  Only the requested entries are output.
+
+    . stage1temp SP stage2temp SP stage3tmp TAB path RS
++
+The second format is what gets used when `--stage=all`.  The three
+stage temporary fields (stage1temp, stage2temp, stage3temp) list the
+name of the temporary file if there is a stage entry in the index
+or `.` if there is no stage entry.  Paths which only have a stage 0
+entry will always be omitted from the output.
+
+In both formats RS (the record separator) is newline by default
+but will be the null byte if -z was passed on the command line.
+The temporary file names are always safe strings; they will never
+contain directory separators or whitespace characters.  The path
+field is always relative to the current directory and the temporary
+file names are always relative to the top level directory.
+
+If the object being copied out to a temporary file is a symbolic
+link the content of the link will be written to a normal file.  It is
+up to the end-user or the Porcelain to make use of this information.
+
+
 EXAMPLES
 --------
 To update and refresh only the files already checked out::

Documentation/git-checkout.txt

@@ -3,19 +3,22 @@ git-checkout(1)
 
 NAME
 ----
-git-checkout - Checkout and switch to a branch.
+git-checkout - Checkout and switch to a branch
 
 SYNOPSIS
 --------
-'git-checkout' [-f] [-b <new_branch>] [<branch>] [<paths>...]
+[verse]
+'git-checkout' [-f] [-b <new_branch> [-l]] [-m] [<branch>]
+'git-checkout' [-m] [<branch>] <paths>...
 
 DESCRIPTION
 -----------
 
-When <paths> are not given, this command switches branches, by
+When <paths> are not given, this command switches branches by
 updating the index and working tree to reflect the specified
 branch, <branch>, and updating HEAD to be <branch> or, if
-specified, <new_branch>.
+specified, <new_branch>.  Using -b will cause <new_branch> to
+be created.
 
 When <paths> are given, this command does *not* switch
 branches.  It updates the named paths in the working tree from
@@ -29,10 +32,31 @@ given paths before updating the working tree.
 OPTIONS
 -------
 -f::
-	Force an re-read of everything.
+	Force a re-read of everything.
 
 -b::
-	Create a new branch and start it at <branch>.
+	Create a new branch named <new_branch> and start it at
+	<branch>.  The new branch name must pass all checks defined
+	by gitlink:git-check-ref-format[1].  Some of these checks
+	may restrict the characters allowed in a branch name.
+
+-l::
+	Create the new branch's ref log.  This activates recording of
+	all changes to made the branch ref, enabling use of date
+	based sha1 expressions such as "<branchname>@{yesterday}".
+
+-m::
+	If you have local modifications to one or more files that
+	are different between the current branch and the branch to
+	which you are switching, the command refuses to switch
+	branches in order to preserve your modifications in context.
+	However, with this option, a three-way merge between the current
+	branch, your working tree contents, and the new branch
+	is done, and you will be on the new branch.
++
+When a merge conflict happens, the index entries for conflicting
+paths are left unmerged, and you need to resolve the conflicts
+and mark the resolved paths with `git update-index`.
 
 <new_branch>::
 	Name for the new branch.
@@ -42,32 +66,81 @@ OPTIONS
 	commit. Defaults to HEAD.
 
 
-EXAMPLE
+EXAMPLES
--------
+--------
 
-The following sequence checks out the `master` branch, reverts
+. The following sequence checks out the `master` branch, reverts
 the `Makefile` to two revisions back, deletes hello.c by
 mistake, and gets it back from the index.
-
++
 ------------
-$ git checkout master <1>
+$ git checkout master             <1>
-$ git checkout master~2 Makefile <2>
+$ git checkout master~2 Makefile  <2>
 $ rm -f hello.c
-$ git checkout hello.c <3>
+$ git checkout hello.c            <3>
-
+------------
++
 <1> switch branch
 <2> take out a file out of other commit
-<3> or "git checkout -- hello.c", as in the next example.
+<3> restore hello.c from HEAD of current branch
-------------
++
-
+If you have an unfortunate branch that is named `hello.c`, this
-If you have an unfortunate branch that is named `hello.c`, the
+step would be confused as an instruction to switch to that branch.
-last step above would be confused as an instruction to switch to
+You should instead write:
-that branch.  You should instead write:
++
-
 ------------
 $ git checkout -- hello.c
 ------------
 
+. After working in a wrong branch, switching to the correct
+branch would be done using:
++
+------------
+$ git checkout mytopic
+------------
++
+However, your "wrong" branch and correct "mytopic" branch may
+differ in files that you have locally modified, in which case,
+the above checkout would fail like this:
++
+------------
+$ git checkout mytopic
+fatal: Entry 'frotz' not uptodate. Cannot merge.
+------------
++
+You can give the `-m` flag to the command, which would try a
+three-way merge:
++
+------------
+$ git checkout -m mytopic
+Auto-merging frotz
+------------
++
+After this three-way merge, the local modifications are _not_
+registered in your index file, so `git diff` would show you what
+changes you made since the tip of the new branch.
+
+. When a merge conflict happens during switching branches with
+the `-m` option, you would see something like this:
++
+------------
+$ git checkout -m mytopic
+Auto-merging frotz
+merge: warning: conflicts during merge
+ERROR: Merge conflict in frotz
+fatal: merge program failed
+------------
++
+At this point, `git diff` shows the changes cleanly merged as in
+the previous example, as well as the changes in the conflicted
+files.  Edit and resolve the conflict and mark it resolved with
+`git update-index` as usual:
++
+------------
+$ edit frotz
+$ git update-index frotz
+------------
+
 
 Author
 ------

Documentation/git-cherry-pick.txt

@@ -3,7 +3,7 @@ git-cherry-pick(1)
 
 NAME
 ----
-git-cherry-pick - Apply the change introduced by an existing commit.
+git-cherry-pick - Apply the change introduced by an existing commit
 
 SYNOPSIS
 --------

Documentation/git-cherry.txt

@@ -3,7 +3,7 @@ git-cherry(1)
 
 NAME
 ----
-git-cherry - Find commits not merged upstream.
+git-cherry - Find commits not merged upstream
 
 SYNOPSIS
 --------
@@ -11,11 +11,20 @@ SYNOPSIS
 
 DESCRIPTION
 -----------
-Each commit between the fork-point and <head> is examined, and compared against
+The changeset (or "diff") of each commit between the fork-point and <head>
-the change each commit between the fork-point and <upstream> introduces.
+is compared against each commit between the fork-point and <upstream>.
-Commits already included in upstream are prefixed with '-' (meaning "drop from
+
-my local pull"), while commits missing from upstream are prefixed with '+'
+Every commit with a changeset that doesn't exist in the other branch
-(meaning "add to the updated upstream").
+has its id (sha1) reported, prefixed by a symbol.  Those existing only
+in the <upstream> branch are prefixed with a minus (-) sign, and those
+that only exist in the <head> branch are prefixed with a plus (+) symbol.
+
+Because git-cherry compares the changeset rather than the commit id
+(sha1), you can use git-cherry to find out if a commit you made locally
+has been applied <upstream> under a different commit id.  For example,
+this will happen if you're feeding patches <upstream> via email rather
+than pushing or pulling commits directly.
+
 
 OPTIONS
 -------

Documentation/git-clean.txt

@@ -0,0 +1,53 @@
+git-clean(1)
+============
+
+NAME
+----
+git-clean - Remove untracked files from the working tree
+
+SYNOPSIS
+--------
+[verse]
+'git-clean' [-d] [-n] [-q] [-x | -X] [--] <paths>...
+
+DESCRIPTION
+-----------
+Removes files unknown to git.  This allows to clean the working tree
+from files that are not under version control.  If the '-x' option is
+specified, ignored files are also removed, allowing to remove all
+build products.
+When optional `<paths>...` arguments are given, the paths
+affected are further limited to those that match them.
+
+
+OPTIONS
+-------
+-d::
+	Remove untracked directories in addition to untracked files.
+
+-n::
+	Don't actually remove anything, just show what would be done.
+
+-q::
+	Be quiet, only report errors, but not the files that are
+	successfully removed.
+
+-x::
+	Don't use the ignore rules.  This allows removing all untracked
+	files, including build products.  This can be used (possibly in
+	conjunction with gitlink:git-reset[1]) to create a pristine
+	working directory to test a clean build.
+
+-X::
+	Remove only files ignored by git.  This may be useful to rebuild
+	everything from scratch, but keep manually created files.
+
+
+Author
+------
+Written by Pavel Roskin <proski@gnu.org>
+
+
+GIT
+---
+Part of the gitlink:git[7] suite

Documentation/git-clone-pack.txt

@@ -1,64 +0,0 @@
-git-clone-pack(1)
-=================
-
-NAME
-----
-git-clone-pack - Clones a repository by receiving packed objects.
-
-
-SYNOPSIS
---------
-'git-clone-pack' [--exec=<git-upload-pack>] [<host>:]<directory> [<head>...]
-
-DESCRIPTION
------------
-Clones a repository into the current repository by invoking
-'git-upload-pack', possibly on the remote host via ssh, in
-the named repository, and stores the sent pack in the local
-repository.
-
-OPTIONS
--------
---exec=<git-upload-pack>::
-	Use this to specify the path to 'git-upload-pack' on the
-	remote side, if it is not found on your $PATH.
-	Installations of sshd ignore the user's environment
-	setup scripts for login shells (e.g. .bash_profile) and
-	your privately installed git may not be found on the system
-	default $PATH.  Another workaround suggested is to set
-	up your $PATH in ".bashrc", but this flag is for people
-	who do not want to pay the overhead for non-interactive
-	shells by having a lean .bashrc file (they set most of
-	the things up in .bash_profile).
-
-<host>::
-	A remote host that houses the repository.  When this
-	part is specified, 'git-upload-pack' is invoked via
-	ssh.
-
-<directory>::
-	The repository to sync from.
-
-<head>...::
-	The heads to update.  This is relative to $GIT_DIR
-	(e.g. "HEAD", "refs/heads/master").  When unspecified,
-	all heads are updated to match the remote repository.
-+
-Usually all the refs from existing repository are stored
-under the same name in the new repository.  Giving explicit
-<head> arguments instead writes the object names and refs to
-the standard output, just like get-fetch-pack does.
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
---------------
-Documentation by Junio C Hamano.
-
-
-GIT
----
-Part of the gitlink:git[7] suite
-

Documentation/git-clone.txt

@@ -3,14 +3,15 @@ git-clone(1)
 
 NAME
 ----
-git-clone - Clones a repository.
+git-clone - Clones a repository
 
 
 SYNOPSIS
 --------
 [verse]
-'git-clone' [-l [-s]] [-q] [-n] [-u <upload-pack>]
+'git-clone' [--template=<template_directory>] [-l [-s]] [-q] [-n] [--bare]
-	  <repository> [<directory>]
+	  [-o <name>] [-u <upload-pack>] [--reference <repository>]
+	  [--use-separate-remote] <repository> [<directory>]
 
 DESCRIPTION
 -----------
@@ -46,38 +47,71 @@ OPTIONS
 -s::
 	When the repository to clone is on the local machine,
 	instead of using hard links, automatically setup
-	.git/objects/info/alternatives to share the objects
+	.git/objects/info/alternates to share the objects
 	with the source repository.  The resulting repository
 	starts out without any object of its own.
 
+--reference <repository>::
+	If the reference repository is on the local machine
+	automatically setup .git/objects/info/alternates to
+	obtain objects from the reference repository.  Using
+	an already existing repository as an alternate will
+	require less objects to be copied from the repository
+	being cloned, reducing network and local storage costs.
+
 --quiet::
 -q::
 	Operate quietly.  This flag is passed to "rsync" and
-	"git-clone-pack" commands when given.
+	"git-fetch-pack" commands when given.
 
 -n::
 	No checkout of HEAD is performed after the clone is complete.
 
+--bare::
+	Make a 'bare' GIT repository.  That is, instead of
+	creating `<directory>` and placing the administrative
+	files in `<directory>/.git`, make the `<directory>`
+	itself the `$GIT_DIR`. This implies `-n` option.  When
+	this option is used, neither the `origin` branch nor the
+	default `remotes/origin` file is created.
+
+-o <name>::
+	Instead of using the branch name 'origin' to keep track
+	of the upstream repository, use <name> instead.  Note
+	that the shorthand name stored in `remotes/origin` is
+	not affected, but the local branch name to pull the
+	remote `master` branch into is.
+
 --upload-pack <upload-pack>::
 -u <upload-pack>::
 	When given, and the repository to clone from is handled
-	by 'git-clone-pack', '--exec=<upload-pack>' is passed to
+	by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
 	the command to specify non-default path for the command
 	run on the other end.
 
+--template=<template_directory>::
+	Specify the directory from which templates will be used;
+	if unset the templates are taken from the installation
+	defined default, typically `/usr/share/git-core/templates`.
+
+--use-separate-remote::
+	Save remotes heads under `$GIT_DIR/remotes/origin/` instead
+	of `$GIT_DIR/refs/heads/`.  Only the master branch is saved
+	in the latter.
+
 <repository>::
 	The (possibly remote) repository to clone from.  It can
 	be any URL git-fetch supports.
 
 <directory>::
-	The name of a new directory to clone into.  The	"humanish"
+	The name of a new directory to clone into.  The "humanish"
 	part of the source repository is used if no directory is
 	explicitly given ("repo" for "/path/to/repo.git" and "foo"
 	for "host.xz:foo/.git").  Cloning into an existing directory
 	is not allowed.
 
 Examples
-~~~~~~~~
+--------
 
 Clone from upstream::
 +
@@ -96,6 +130,32 @@ $ cd copy
 $ git show-branch
 ------------
 
+
+Clone from upstream while borrowing from an existing local directory::
++
+------------
+$ git clone --reference my2.6 \
+	git://git.kernel.org/pub/scm/.../linux-2.7 \
+	my2.7
+$ cd my2.7
+------------
+
+
+Create a bare repository to publish your changes to the public::
++
+------------
+$ git clone --bare -l /home/proj/.git /pub/scm/proj.git
+------------
+
+
+Create a repository on the kernel.org machine that borrows from Linus::
++
+------------
+$ git clone --bare -l -s /pub/scm/.../torvalds/linux-2.6.git \
+    /pub/scm/.../me/subsys-2.6.git
+------------
+
+
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org>

Documentation/git-commit.txt

@@ -9,14 +9,19 @@ SYNOPSIS
 --------
 [verse]
 'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]
-	   [-e] [--] <file>...
+	   [--no-verify] [--amend] [-e] [--author <author>]
+	   [--] [[-i | -o ]<file>...]
 
 DESCRIPTION
 -----------
 Updates the index file for given paths, or all modified files if
-'-a' is specified, and makes a commit object.  The command
+'-a' is specified, and makes a commit object.  The command specified
-VISUAL and EDITOR environment variables to edit the commit log
+by either the VISUAL or EDITOR environment variables are used to edit
-message.
+the commit log message.
+
+Several environment variable are used during commits.  They are
+documented in gitlink:git-commit-tree[1].
+
 
 This command can run `commit-msg`, `pre-commit`, and
 `post-commit` hooks.  See link:hooks.html[hooks] for more
@@ -27,7 +32,7 @@ OPTIONS
 -a|--all::
 	Update all paths in the index file.  This flag notices
 	files that have been modified and deleted, but new files
-	you have not told about git are not affected.
+	you have not told git about are not affected.
 
 -c or -C <commit>::
 	Take existing commit object, and reuse the log message
@@ -40,6 +45,10 @@ OPTIONS
 	Take the commit message from the given file.  Use '-' to
 	read the message from the standard input.
 
+--author <author>::
+	Override the author name used in the commit.  Use
+	`A U Thor <author@example.com>` format.
+
 -m <msg>::
 	Use the given <msg> as the commit message.
 
@@ -63,17 +72,93 @@ OPTIONS
 	commit log message unmodified.  This option lets you
 	further edit the message taken from these sources.
 
---::
+--amend::
+
+	Used to amend the tip of the current branch. Prepare the tree
+	object you would want to replace the latest commit as usual
+	(this includes the usual -i/-o and explicit paths), and the
+	commit log editor is seeded with the commit message from the
+	tip of the current branch. The commit you create replaces the
+	current tip -- if it was a merge, it will have the parents of
+	the current tip as parents -- so the current top commit is
+	discarded.
++
+--
+It is a rough equivalent for:
+------
+	$ git reset --soft HEAD^
+	$ ... do something else to come up with the right tree ...
+	$ git commit -c ORIG_HEAD
+
+------
+but can be used to amend a merge commit.
+--
+
+-i|--include::
+	Instead of committing only the files specified on the
+	command line, update them in the index file and then
+	commit the whole index.  This is the traditional
+	behavior.
+
+-o|--only::
+	Commit only the files specified on the command line.
+	This format cannot be used during a merge, nor when the
+	index and the latest commit does not match on the
+	specified paths to avoid confusion.
+
+\--::
 	Do not interpret any more arguments as options.
 
 <file>...::
-	Update specified paths in the index file before committing.
+	Files to be committed.  The meaning of these is
-
+	different between `--include` and `--only`.  Without
+	either, it defaults `--only` semantics.
 
 If you make a commit and then found a mistake immediately after
 that, you can recover from it with gitlink:git-reset[1].
 
 
+Discussion
+----------
+
+`git commit` without _any_ parameter commits the tree structure
+recorded by the current index file.  This is a whole-tree commit
+even the command is invoked from a subdirectory.
+
+`git commit --include paths...` is equivalent to
+
+	git update-index --remove paths...
+	git commit
+
+That is, update the specified paths to the index and then commit
+the whole tree.
+
+`git commit paths...` largely bypasses the index file and
+commits only the changes made to the specified paths.  It has
+however several safety valves to prevent confusion.
+
+. It refuses to run during a merge (i.e. when
+  `$GIT_DIR/MERGE_HEAD` exists), and reminds trained git users
+  that the traditional semantics now needs -i flag.
+
+. It refuses to run if named `paths...` are different in HEAD
+  and the index (ditto about reminding).  Added paths are OK.
+  This is because an earlier `git diff` (not `git diff HEAD`)
+  would have shown the differences since the last `git
+  update-index paths...` to the user, and an inexperienced user
+  may mistakenly think that the changes between the index and
+  the HEAD (i.e. earlier changes made before the last `git
+  update-index paths...` was done) are not being committed.
+
+. It reads HEAD commit into a temporary index file, updates the
+  specified `paths...` and makes a commit.  At the same time,
+  the real index file is also updated with the same `paths...`.
+
+`git commit --all` updates the index file with _all_ changes to
+the working tree, and makes a whole-tree commit, regardless of
+which subdirectory the command is invoked in.
+
+
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org> and

Documentation/git-count-objects.txt

@@ -3,17 +3,27 @@ git-count-objects(1)
 
 NAME
 ----
-git-count-objects - Reports on unpacked objects.
+git-count-objects - Reports on unpacked objects
 
 SYNOPSIS
 --------
-'git-count-objects'
+'git-count-objects' [-v]
 
 DESCRIPTION
 -----------
 This counts the number of unpacked object files and disk space consumed by
 them, to help you decide when it is a good time to repack.
 
+
+OPTIONS
+-------
+-v::
+	In addition to the number of loose objects and disk
+	space consumed, it reports the number of in-pack
+	objects, and number of objects that can be removed by
+	running `git-prune-packed`.
+
+
 Author
 ------
 Written by Junio C Hamano <junkio@cox.net>

Documentation/git-cvsexportcommit.txt

@@ -8,7 +8,7 @@ git-cvsexportcommit - Export a commit to a CVS checkout
 
 SYNOPSIS
 --------
-'git-cvsexportcommmit' [-h] [-v] [-c] [-p] [PARENTCOMMIT] COMMITID
+'git-cvsexportcommit' [-h] [-v] [-c] [-p] [-a] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
 
 
 DESCRIPTION
@@ -17,6 +17,7 @@ Exports a commit from GIT to a CVS checkout, making it easier
 to merge patches from a git repository into a CVS repository. 
 
 Execute it from the root of the CVS working copy. GIT_DIR must be defined. 
+See examples below.
 
 It does its best to do the safe thing, it will check that the files are 
 unchanged and up to date in the CVS checkout, and it will not autocommit 
@@ -35,12 +36,43 @@ OPTIONS
 	commit if any hunks fail to apply or there were other problems.
 
 -p::
-	Be pedantic (paranoid) when applying patches. Invokes patch with 
+	Be pedantic (paranoid) when applying patches. Invokes patch with
 	--fuzz=0
 
+-a::
+	Add authorship information. Adds Author line, and Committer (if
+	different from Author) to the message.
+
+-f::
+	Force the merge even if the files are not up to date.
+
+-m::
+	Prepend the commit message with the provided prefix. 
+	Useful for patch series and the like.
+
 -v::
 	Verbose.
 
+EXAMPLES
+--------
+
+Merge one patch into CVS::
++
+------------
+$ export GIT_DIR=~/project/.git
+$ cd ~/project_cvs_checkout
+$ git-cvsexportcommit -v <commit-sha1>
+$ cvs commit -F .mgs <files> 
+------------
+
+Merge pending patches into CVS automatically -- only if you really know what you are doing ::
++
+------------
+$ export GIT_DIR=~/project/.git
+$ cd ~/project_cvs_checkout
+$ git-cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git-cvsexportcommit -c -p -v
+------------
+
 Author
 ------
 Written by Martin Langhoff <martin@catalyst.net.nz>

Documentation/git-cvsimport.txt

@@ -22,6 +22,12 @@ repository, or incrementally import into an existing one.
 Splitting the CVS log into patch sets is done by 'cvsps'.
 At least version 2.1 is required.
 
+You should *never* do any work of your own on the branches that are
+created by git-cvsimport. The initial import will create and populate a
+"master" branch from the CVS repository's main branch which you're free
+to work with; after that, you need to 'git merge' incremental imports, or
+any CVS branches, yourself.
+
 OPTIONS
 -------
 -d <CVSROOT>::
@@ -89,6 +95,29 @@ If you need to pass multiple options, separate them with a comma.
 -s <subst>::
 	Substitute the character "/" in branch names with <subst>
 
+-A <author-conv-file>::
+	CVS by default uses the unix username when writing its
+	commit logs. Using this option and an author-conv-file
+	in this format
++
+---------
+	exon=Andreas Ericsson <ae@op5.se>
+	spawn=Simon Pawn <spawn@frog-pond.org>
+
+---------
++
+git-cvsimport will make it appear as those authors had
+their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
+all along.
++
+For convenience, this data is saved to $GIT_DIR/cvs-authors
+each time the -A option is provided and read from that same
+file each time git-cvsimport is run.
++
+It is not recommended to use this feature if you intend to
+export changes back to CVS again later with
+git-link[1]::git-cvsexportcommit.
+
 OUTPUT
 ------
 If '-v' is specified, the script reports what it is doing.

Documentation/git-cvsserver.txt

@@ -0,0 +1,161 @@
+git-cvsserver(1)
+================
+
+NAME
+----
+git-cvsserver - A CVS server emulator for git
+
+SYNOPSIS
+--------
+[verse]
+export CVS_SERVER=git-cvsserver
+'cvs' -d :ext:user@server/path/repo.git co <HEAD_name>
+
+DESCRIPTION
+-----------
+
+This application is a CVS emulation layer for git.
+
+It is highly functional. However, not all methods are implemented,
+and for those methods that are implemented,
+not all switches are implemented.
+
+Testing has been done using both the CLI CVS client, and the Eclipse CVS
+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.
+
+INSTALLATION
+------------
+
+1. If you are going to offer anonymous CVS access via pserver, add a line in
+   /etc/inetd.conf like
++
+--
+------
+   cvspserver stream tcp nowait nobody git-cvsserver pserver
+
+------
+Note: In some cases, you need to pass the 'pserver' argument twice for
+git-cvsserver to see it. So the line would look like
+
+------
+   cvspserver stream tcp nowait nobody git-cvsserver pserver pserver
+
+------
+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
+env variable, you can rename git-cvsserver to cvs.
+--
+2. For each repo that you want accessible from CVS you need to edit config in
+   the repo and add the following section.
++
+--
+------
+   [gitcvs]
+        enabled=1
+        # optional for debugging
+        logfile=/path/to/logfile
+
+------
+Note: you need to ensure each user that is going to invoke git-cvsserver has
+write access to the log file and to the git repository. When offering anon
+access via pserver, this means that the nobody user should have write access
+to at least the sqlite database at the root of the repository.
+--
+3. On the client machine you need to set the following variables.
+   CVSROOT should be set as per normal, but the directory should point at the
+   appropriate git repo. For example:
++
+--
+For SSH access, CVS_SERVER should be set to git-cvsserver
+
+Example:
+
+------
+     export CVSROOT=:ext:user@server:/var/git/project.git
+     export CVS_SERVER=git-cvsserver
+------
+--
+4. For SSH clients that will make commits, make sure their .bashrc file
+   sets the GIT_AUTHOR and GIT_COMMITTER variables.
+
+5. Clients should now be able to check out the project. Use the CVS 'module'
+   name to indicate what GIT 'head' you want to check out. Example:
++
+------
+     cvs co -d project-master master
+------
+
+Eclipse CVS Client Notes
+------------------------
+
+To get a checkout with the Eclipse CVS client:
+
+1. Select "Create a new project -> From CVS checkout"
+2. Create a new location. See the notes below for details on how to choose the
+   right protocol.
+3. Browse the 'modules' available. It will give you a list of the heads in
+   the repository. You will not be able to browse the tree from there. Only
+   the heads.
+4. Pick 'HEAD' when it asks what branch/tag to check out. Untick the
+   "launch commit wizard" to avoid committing the .project file.
+
+Protocol notes: If you are using anonymous access via pserver, just select that.
+Those using SSH access should choose the 'ext' protocol, and configure 'ext'
+access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to
+'git-cvsserver'. Not that password support is not good when using 'ext',
+you will definitely want to have SSH keys setup.
+
+Alternatively, you can just use the non-standard extssh protocol that Eclipse
+offer. In that case CVS_SERVER is ignored, and you will have to replace
+the cvs utility on the server with git-cvsserver or manipulate your .bashrc
+so that calling 'cvs' effectively calls git-cvsserver.
+
+Clients known to work
+---------------------
+
+CVS 1.12.9 on Debian
+CVS 1.11.17 on MacOSX (from Fink package)
+Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes)
+TortoiseCVS
+
+Operations supported
+--------------------
+
+All the operations required for normal use are supported, including
+checkout, diff, status, update, log, add, remove, commit.
+Legacy monitoring operations are not supported (edit, watch and related).
+Exports and tagging (tags and branches) are not supported at this stage.
+
+The server will set the -k mode to binary when relevant. In proper GIT
+tradition, the contents of the files are always respected.
+No keyword expansion or newline munging is supported.
+
+Dependencies
+------------
+
+git-cvsserver depends on DBD::SQLite.
+
+Copyright and Authors
+---------------------
+
+This program is copyright The Open University UK - 2006.
+
+Authors: Martyn Smith    <martyn@catalyst.net.nz>
+         Martin Langhoff <martin@catalyst.net.nz>
+         with ideas and patches from participants of the git-list <git@vger.kernel.org>.
+
+Documentation
+--------------
+Documentation by Martyn Smith <martyn@catalyst.net.nz> and Martin Langhoff <martin@catalyst.net.nz> Matthias Urlichs <smurf@smurf.noris.de>.
+
+GIT
+---
+Part of the gitlink:git[7] suite

Documentation/git-daemon.txt

@@ -3,13 +3,15 @@ git-daemon(1)
 
 NAME
 ----
-git-daemon - A really simple server for git repositories.
+git-daemon - A really simple server for git repositories
 
 SYNOPSIS
 --------
 [verse]
 'git-daemon' [--verbose] [--syslog] [--inetd | --port=n] [--export-all]
-           [--timeout=n] [--init-timeout=n] [--strict-paths] [directory...]
+             [--timeout=n] [--init-timeout=n] [--strict-paths]
+             [--base-path=path] [--user-path | --user-path=path]
+	     [directory...]
 
 DESCRIPTION
 -----------
@@ -18,7 +20,7 @@ aka 9418. It waits for a connection, and will just execute "git-upload-pack"
 when it gets one.
 
 It's careful in that there's a magic request-line that gives the command and
-what directory to upload, and it verifies that the directory is ok.
+what directory to upload, and it verifies that the directory is OK.
 
 It verifies that the directory has the magic file "git-daemon-export-ok", and
 it will refuse to export any git directory that hasn't explicitly been marked
@@ -26,7 +28,7 @@ for export this way (unless the '--export-all' parameter is specified). If you
 pass some directory paths as 'git-daemon' arguments, you can further restrict
 the offers to a whitelist comprising of those.
 
-This is ideally suited for read-only updates, ie pulling from git repositories.
+This is ideally suited for read-only updates, i.e., pulling from git repositories.
 
 OPTIONS
 -------
@@ -36,6 +38,13 @@ OPTIONS
 	git-daemon will refuse to start when this option is enabled and no
 	whitelist is specified.
 
+--base-path::
+	Remap all the path requests as relative to the given path.
+	This is sort of "GIT root" - if you run git-daemon with
+	'--base-path=/srv/git' on example.com, then if you later try to pull
+	'git://example.com/hello.git', `git-daemon` will interpret the path
+	as '/srv/git/hello.git'.
+
 --export-all::
 	Allow pulling from all directories that look like GIT repositories
 	(have the 'objects' and 'refs' subdirectories), even if they
@@ -61,6 +70,15 @@ OPTIONS
 	Log to syslog instead of stderr. Note that this option does not imply
 	--verbose, thus by default only error conditions will be logged.
 
+--user-path, --user-path=path::
+	Allow ~user notation to be used in requests.  When
+	specified with no parameter, requests to
+	git://host/~alice/foo is taken as a request to access
+	'foo' repository in the home directory of user `alice`.
+	If `--user-path=path` is specified, the same request is
+	taken as a request to access `path/foo` repository in
+	the home directory of user `alice`.
+
 --verbose::
 	Log details about the incoming connections and requested files.
 

Documentation/git-describe.txt

@@ -0,0 +1,79 @@
+git-describe(1)
+===============
+
+NAME
+----
+git-describe - Show the most recent tag that is reachable from a commit
+
+
+SYNOPSIS
+--------
+'git-describe' [--all] [--tags] [--abbrev=<n>] <committish>...
+
+DESCRIPTION
+-----------
+The command finds the most recent tag that is reachable from a
+commit, and if the commit itself is pointed at by the tag, shows
+the tag.  Otherwise, it suffixes the tag name with abbreviated
+object name of the commit.
+
+
+OPTIONS
+-------
+<committish>::
+	The object name of the committish.
+
+--all::
+	Instead of using only the annotated tags, use any ref
+	found in `.git/refs/`.
+
+--tags::
+	Instead of using only the annotated tags, use any tag
+	found in `.git/refs/tags`.
+
+--abbrev=<n>::
+	Instead of using the default 8 hexadecimal digits as the
+	abbreviated object name, use <n> digits.
+
+
+EXAMPLES
+--------
+
+With something like git.git current tree, I get:
+
+	[torvalds@g5 git]$ git-describe parent
+	v1.0.4-g2414721b
+
+i.e. the current head of my "parent" branch is based on v1.0.4,
+but since it has a few commits on top of that, it has added the
+git hash of the thing to the end: "-g" + 8-char shorthand for
+the commit `2414721b194453f058079d897d13c4e377f92dc6`.
+
+Doing a "git-describe" on a tag-name will just show the tag name:
+
+	[torvalds@g5 git]$ git-describe v1.0.4
+	v1.0.4
+
+With --all, the command can use branch heads as references, so
+the output shows the reference path as well:
+
+	[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2
+	tags/v1.0.0-g975b
+
+	[torvalds@g5 git]$ git describe --all HEAD^
+	heads/lt/describe-g975b
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>, but somewhat
+butchered by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+

Documentation/git-diff-files.txt

@@ -8,7 +8,7 @@ git-diff-files - Compares files in the working tree and the index
 
 SYNOPSIS
 --------
-'git-diff-files' [-q] [<common diff options>] [<path>...]
+'git-diff-files' [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>...]
 
 DESCRIPTION
 -----------
@@ -30,8 +30,14 @@ The default is to diff against our branch (-2) and the
 cleanly resolved paths.  The option -0 can be given to
 omit diff output for unmerged entries and just show "Unmerged".
 
+-c,--cc::
+	This compares stage 2 (our branch), stage 3 (their
+	branch) and the working tree file and outputs a combined
+	diff, similar to the way 'diff-tree' shows a merge
+	commit with these flags.
+
 -q::
-	Remain silent even on nonexisting files
+	Remain silent even on nonexistent files
 
 Output format
 -------------

Documentation/git-diff-index.txt

@@ -101,7 +101,7 @@ have not actually done a "git-update-index" on it yet - there is no
   torvalds@ppc970:~/v2.6/linux> git-diff-index HEAD
   *100644->100664 blob    7476bb......->000000......      kernel/sched.c
 
-ie it shows that the tree has changed, and that `kernel/sched.c` has is
+i.e., it shows that the tree has changed, and that `kernel/sched.c` has is
 not up-to-date and may contain new stuff. The all-zero sha1 means that to
 get the real diff, you need to look at the object in the working directory
 directly rather than do an object-to-object diff.

Documentation/git-diff-stages.txt

@@ -3,7 +3,7 @@ git-diff-stages(1)
 
 NAME
 ----
-git-diff-stages - Compares content and mode of blobs between stages in an unmerged index file.
+git-diff-stages - Compares content and mode of blobs between stages in an unmerged index file
 
 
 SYNOPSIS

Documentation/git-diff-tree.txt

@@ -9,8 +9,9 @@ git-diff-tree - Compares the content and mode of blobs found via two tree object
 SYNOPSIS
 --------
 [verse]
-'git-diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty] [-t] [-r]
+'git-diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
-	      [--root] [<common diff options>] <tree-ish> [<tree-ish>] [<path>...]
+	      [-t] [-r] [-c | --cc] [--root] [<common diff options>]
+	      <tree-ish> [<tree-ish>] [<path>...]
 
 DESCRIPTION
 -----------
@@ -31,7 +32,7 @@ include::diff-options.txt[]
 <path>...::
 	If provided, the results are limited to a subset of files
 	matching one of these prefix strings.
-	ie file matches `/^<pattern1>|<pattern2>|.../`
+	i.e., file matches `/^<pattern1>|<pattern2>|.../`
 	Note that this parameter does not provide any wildcard or regexp
 	features.
 
@@ -53,13 +54,14 @@ include::diff-options.txt[]
 +
 When a single commit is given on one line of such input, it compares
 the commit with its parents.  The following flags further affects its
-behaviour.  This does not apply to the case where two <tree-ish>
+behavior.  This does not apply to the case where two <tree-ish>
 separated with a single space are given.
 
 -m::
 	By default, "git-diff-tree --stdin" does not show
 	differences for merge commits.  With this flag, it shows
-	differences to that commit from all of its parents.
+	differences to that commit from all of its parents. See
+	also '-c'.
 
 -s::
 	By default, "git-diff-tree --stdin" shows differences,
@@ -80,6 +82,30 @@ separated with a single space are given.
 	git-diff-tree outputs a line with the commit ID when
 	applicable.  This flag suppressed the commit ID output.
 
+-c::
+	This flag changes the way a merge commit is displayed
+	(which means it is useful only when the command is given
+	one <tree-ish>, or '--stdin').  It shows the differences
+	from each of the parents to the merge result simultaneously
+	instead of showing pairwise diff between a parent and the
+	result one at a time (which is what the '-m' option does).
+	Furthermore, it lists only files which were modified
+	from all parents.
+
+--cc::
+	This flag changes the way a merge commit patch is displayed,
+	in a similar way to the '-c' option. It implies the '-c'
+	and '-p' options and further compresses the patch output
+	by omitting hunks that show differences from only one
+	parent, or show the same change from all but one parent
+	for an Octopus merge.  When this optimization makes all
+	hunks disappear, the commit itself and the commit log
+	message is not shown, just like in any other "empty diff" case.
+
+--always::
+	Show the commit itself and the commit log message even
+	if the diff itself is empty.
+
 
 Limiting Output
 ---------------

Documentation/git-diff.txt

@@ -3,29 +3,29 @@ git-diff(1)
 
 NAME
 ----
-git-diff - Show changes between commits, commit and working tree, etc.
+git-diff - Show changes between commits, commit and working tree, etc
 
 
 SYNOPSIS
 --------
-'git-diff' [ --diff-options ] <ent>{0,2} [<path>...]
+'git-diff' [ --diff-options ] <tree-ish>{0,2} [<path>...]
 
 DESCRIPTION
 -----------
-Show changes between two ents, an ent and the working tree, an
+Show changes between two trees, a tree and the working tree, a
-ent and the index file, or the index file and the working tree.
+tree and the index file, or the index file and the working tree.
 The combination of what is compared with what is determined by
-the number of ents given to the command.
+the number of trees given to the command.
 
-* When no <ent> is given, the working tree and the index
+* When no <tree-ish> is given, the working tree and the index
-  file is compared, using `git-diff-files`.
+  file are compared, using `git-diff-files`.
 
-* When one <ent> is given, the working tree and the named
+* When one <tree-ish> is given, the working tree and the named
-  tree is compared, using `git-diff-index`.  The option
+  tree are compared, using `git-diff-index`.  The option
   `--cached` can be given to compare the index file and
   the named tree.
 
-* When two <ent>s are given, these two trees are compared
+* When two <tree-ish>s are given, these two trees are compared
   using `git-diff-tree`.
 
 OPTIONS
@@ -46,60 +46,60 @@ EXAMPLES
 Various ways to check your working tree::
 +
 ------------
-$ git diff <1>
+$ git diff            <1>
-$ git diff --cached <2>
+$ git diff --cached   <2>
-$ git diff HEAD <3>
+$ git diff HEAD       <3>
-
+------------
++
 <1> changes in the working tree since your last git-update-index.
 <2> changes between the index and your last commit; what you
 would be committing if you run "git commit" without "-a" option.
 <3> changes in the working tree since your last commit; what you
 would be committing if you run "git commit -a"
-------------
 
 Comparing with arbitrary commits::
 +
 ------------
-$ git diff test <1>
+$ git diff test            <1>
-$ git diff HEAD -- ./test <2>
+$ git diff HEAD -- ./test  <2>
-$ git diff HEAD^ HEAD <3>
+$ git diff HEAD^ HEAD      <3>
-
+------------
++
 <1> instead of using the tip of the current branch, compare with the
 tip of "test" branch.
 <2> instead of comparing with the tip of "test" branch, compare with
 the tip of the current branch, but limit the comparison to the
 file "test".
 <3> compare the version before the last commit and the last commit.
-------------
 
 
 Limiting the diff output::
 +
 ------------
-$ git diff --diff-filter=MRC <1>
+$ git diff --diff-filter=MRC            <1>
-$ git diff --name-status -r <2>
+$ git diff --name-status -r             <2>
-$ git diff arch/i386 include/asm-i386 <3>
+$ git diff arch/i386 include/asm-i386   <3>
-
+------------
++
 <1> show only modification, rename and copy, but not addition
 nor deletion.
 <2> show only names and the nature of change, but not actual
 diff output.  --name-status disables usual patch generation
-which in turn also disables recursive behaviour, so without -r
+which in turn also disables recursive behavior, so without -r
 you would only see the directory name if there is a change in a
 file in a subdirectory.
 <3> limit diff output to named subtrees.
-------------
 
 Munging the diff output::
 +
 ------------
-$ git diff --find-copies-harder -B -C <1>
+$ git diff --find-copies-harder -B -C  <1>
-$ git diff -R <2>
+$ git diff -R                          <2>
-
+------------
++
 <1> spend extra cycles to find renames, copies and complete
 rewrites (very expensive).
 <2> output diff in reverse.
-------------
 
 
 Author

Documentation/git-fetch-pack.txt

@@ -3,12 +3,12 @@ git-fetch-pack(1)
 
 NAME
 ----
-git-fetch-pack - Receive missing objects from another repository.
+git-fetch-pack - Receive missing objects from another repository
 
 
 SYNOPSIS
 --------
-git-fetch-pack [-q] [-k] [--exec=<git-upload-pack>] [<host>:]<directory> [<refs>...]
+'git-fetch-pack' [-q] [-k] [--exec=<git-upload-pack>] [<host>:]<directory> [<refs>...]
 
 DESCRIPTION
 -----------

Documentation/git-fetch.txt

@@ -3,7 +3,7 @@ git-fetch(1)
 
 NAME
 ----
-git-fetch - Download objects and a head from another repository.
+git-fetch - Download objects and a head from another repository
 
 
 SYNOPSIS
@@ -27,7 +27,7 @@ include::fetch-options.txt[]
 
 include::pull-fetch-param.txt[]
 
-
+include::urls.txt[]
 
 SEE ALSO
 --------

Documentation/git-format-patch.txt

@@ -3,34 +3,43 @@ git-format-patch(1)
 
 NAME
 ----
-git-format-patch - Prepare patches for e-mail submission.
+git-format-patch - Prepare patches for e-mail submission
 
 
 SYNOPSIS
 --------
 [verse]
-'git-format-patch' [-n | -k] [-o <dir> | --stdout] [-s] [-c] [--mbox]
+'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [--thread]
-		 [--diff-options] <his> [<mine>]
+	           [-s | --signoff] [--diff-options] [--start-number <n>]
+		   [--in-reply-to=Message-Id]
+		   <since>[..<until>]
 
 DESCRIPTION
 -----------
-Prepare each commit with its patch since <mine> head forked from
-<his> head, one file per patch, for e-mail submission.  Each
-output file is numbered sequentially from 1, and uses the first
-line of the commit message (massaged for pathname safety) as the
-filename.
 
-When -o is specified, output files are created in that
+Prepare each commit between <since> and <until> with its patch in
-directory; otherwise in the current working directory.
+one file per commit, formatted to resemble UNIX mailbox format.
+If ..<until> is not specified, the head of the current working
+tree is implied.
 
-When -n is specified, instead of "[PATCH] Subject", the first
+The output of this command is convenient for e-mail submission or
-line is formatted as "[PATCH N/M] Subject", unless you have only
+for use with gitlink:git-am[1].
-one patch.
 
-When --mbox is specified, the output is formatted to resemble
+Each output file is numbered sequentially from 1, and uses the
-UNIX mailbox format, and can be concatenated together for
+first line of the commit message (massaged for pathname safety) as
-processing with applymbox.
+the filename. The names of the output files are printed to standard
+output, unless the --stdout option is specified.
 
+If -o is specified, output files are created in <dir>.  Otherwise
+they are created in the current working directory.
+
+If -n is specified, instead of "[PATCH] Subject", the first line
+is formatted as "[PATCH n/m] Subject".
+
+If given --thread, git-format-patch will generate In-Reply-To and
+References headers to make the second and subsequent patch mails appear
+as replies to the first mail; this also generates a Message-Id header to
+reference.
 
 OPTIONS
 -------
@@ -41,36 +50,41 @@ OPTIONS
 -n|--numbered::
 	Name output in '[PATCH n/m]' format.
 
+--start-number <n>::
+	Start numbering the patches at <n> instead of 1.
+
 -k|--keep-subject::
 	Do not strip/add '[PATCH]' from the first line of the
 	commit log message.
 
--a|--author, -d|--date::
-	Output From: and Date: headers for commits made by
-	yourself as well.  Usually these are output only for
-	commits made by people other than yourself.
-
 -s|--signoff::
 	Add `Signed-off-by:` line to the commit message, using
 	the committer identity of yourself.
 
--c|--check::
-        Display suspicious lines in the patch.  The definition
-        of 'suspicious lines' is currently the lines that has
-        trailing whitespaces, and the lines whose indentation
-        has a SP character immediately followed by a TAB
-        character.
-
--m|--mbox::
-	Format the output files for closer to mbox format by
-	adding a phony Unix "From " line, so they can be
-	concatenated together and fed to `git-applymbox`.
-	Implies --author and --date.
-
 --stdout::
-	This flag generates the mbox formatted output to the
+	Print all commits to the standard output in mbox format,
-	standard output, instead of saving them into a file per
+	instead of creating a file for each one.
-	patch and implies --mbox.
+
+--attach::
+	Create attachments instead of inlining patches.
+
+--thread::
+	Add In-Reply-To and References headers to make the second and
+	subsequent mails appear as replies to the first.  Also generates
+	the Message-Id header to reference.
+
+--in-reply-to=Message-Id::
+	Make the first mail (or all the mails with --no-thread) appear as a
+	reply to the given Message-Id, which avoids breaking threads to
+	provide a new patch series.
+
+CONFIGURATION
+-------------
+You can specify extra mail header lines to be added to each
+message in the repository configuration as follows:
+
+[format]
+        headers = "Organization: git-foo\n"
 
 
 EXAMPLES
@@ -82,18 +96,18 @@ git-format-patch -k --stdout R1..R2 | git-am -3 -k::
 	cherry-pick them.
 
 git-format-patch origin::
-	Extract commits the current branch accumulated since it
+	Extract all commits which are in the current branch but
-	pulled from origin the last time in a patch form for
+	not in the origin branch.  For each commit a separate file
-	e-mail submission.
+	is created in the current directory.
 
 git-format-patch -M -B origin::
-	The same as the previous one, except detect and handle
+	The same as the previous one.  Additionally, it detects
-	renames and complete rewrites intelligently to produce
+	and handles renames and complete rewrites intelligently to
-	renaming patch.  A renaming patch reduces the amount of
+	produce a renaming patch.  A renaming patch reduces the
-	text output, and generally makes it easier to review
+	amount of text output, and generally makes it easier to
-	it.  Note that the "patch" program does not understand
+	review it.  Note that the "patch" program does not
-	renaming patch well, so use it only when you know the
+	understand renaming patches, so use it only when you know
-	recipient uses git to apply your patch.
+	the recipient uses git to apply your patch.
 
 
 See Also

Documentation/git-fsck-objects.txt

@@ -10,7 +10,7 @@ SYNOPSIS
 --------
 [verse]
 'git-fsck-objects' [--tags] [--root] [--unreachable] [--cache]
-		 [--standalone | --full] [--strict] [<object>*]
+		 [--full] [--strict] [<object>*]
 
 DESCRIPTION
 -----------
@@ -38,21 +38,14 @@ index file and all SHA1 references in .git/refs/* as heads.
 	Consider any object recorded in the index also as a head node for
 	an unreachability trace.
 
---standalone::
-	Limit checks to the contents of GIT_OBJECT_DIRECTORY
-	($GIT_DIR/objects), making sure that it is consistent and
-	complete without referring to objects found in alternate
-	object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES,
-	nor packed git archives found in $GIT_DIR/objects/pack;
-	cannot be used with --full.
-
 --full::
 	Check not just objects in GIT_OBJECT_DIRECTORY
 	($GIT_DIR/objects), but also the ones found in alternate
-	object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES,
+	object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES
+	or $GIT_DIR/objects/info/alternates,
 	and in packed git archives found in $GIT_DIR/objects/pack
 	and corresponding pack subdirectories in alternate
-	object pools; cannot be used with --standalone.
+	object pools.
 
 --strict::
 	Enable more strict checking, namely to catch a file mode
@@ -78,7 +71,7 @@ sorted properly etc), but on the whole if "git-fsck-objects" is happy, you
 do have a valid tree.
 
 Any corrupt objects you will have to find in backups or other archives
-(ie you can just remove them and do an "rsync" with some other site in
+(i.e., you can just remove them and do an "rsync" with some other site in
 the hopes that somebody else has the object you have corrupted).
 
 Of course, "valid tree" doesn't mean that it wasn't generated by some

Documentation/git-get-tar-commit-id.txt

@@ -3,7 +3,7 @@ git-get-tar-commit-id(1)
 
 NAME
 ----
-git-get-tar-commit-id - Extract commit ID from an archive created using git-tar-tree.
+git-get-tar-commit-id - Extract commit ID from an archive created using git-tar-tree
 
 
 SYNOPSIS

Documentation/git-grep.txt

@@ -3,37 +3,92 @@ git-grep(1)
 
 NAME
 ----
-git-grep - print lines matching a pattern
+git-grep - Print lines matching a pattern
 
 
 SYNOPSIS
 --------
-'git-grep' [<option>...] <pattern> [<path>...]
+[verse]
+'git-grep' [--cached]
+	   [-a | --text] [-I] [-i | --ignore-case] [-w | --word-regexp]
+	   [-v | --invert-match]
+	   [-E | --extended-regexp] [-G | --basic-regexp] [-F | --fixed-strings]
+	   [-n] [-l | --files-with-matches] [-L | --files-without-match]
+	   [-c | --count]
+	   [-A <post-context>] [-B <pre-context>] [-C <context>]
+	   [-f <file>] [-e] <pattern>
+	   [<tree>...]
+	   [--] [<path>...]
 
 DESCRIPTION
 -----------
-Searches list of files `git-ls-files` produces for lines
+Look for specified patterns in the working tree files, blobs
-containing a match to the given pattern.
+registered in the index file, or given tree objects.
 
 
 OPTIONS
 -------
-<option>...::
+--cached::
-	Either an option to pass to `grep` or `git-ls-files`.
+	Instead of searching in the working tree files, check
-	Some `grep` options, such as `-C` and `-m`, that take
+	the blobs registered in the index file.
-	parameters are known to `git-grep`.
 
-<pattern>::
+-a | --text::
-	The pattern to look for.
+	Process binary files as if they were text.
 
-<path>...::
+-i | --ignore-case::
-	Optional paths to limit the set of files to be searched;
+	Ignore case differences between the patterns and the
-	passed to `git-ls-files`.
+	files.
+
+-w | --word-regexp::
+	Match the pattern only at word boundary (either begin at the
+	beginning of a line, or preceded by a non-word character; end at
+	the end of a line or followed by a non-word character).
+
+-v | --invert-match::
+	Select non-matching lines.
+
+-E | --extended-regexp | -G | --basic-regexp::
+	Use POSIX extended/basic regexp for patterns.  Default
+	is to use basic regexp.
+
+-n::
+	Prefix the line number to matching lines.
+
+-l | --files-with-matches | -L | --files-without-match::
+	Instead of showing every matched line, show only the
+	names of files that contain (or do not contain) matches.
+
+-c | --count::
+	Instead of showing every matched line, show the number of
+	lines that match.
+
+-[ABC] <context>::
+	Show `context` trailing (`A` -- after), or leading (`B`
+	-- before), or both (`C` -- context) lines, and place a
+	line containing `--` between contiguous groups of
+	matches.
+
+-f <file>::
+	Read patterns from <file>, one per line.
+
+-e::
+	The next parameter is the pattern. This option has to be
+	used for patterns starting with - and should be used in
+	scripts passing user input to grep.
+
+`<tree>...`::
+	Search blobs in the trees for specified patterns.
+
+`--`::
+	Signals the end of options; the rest of the parameters
+	are <path> limiters.
 
 
 Author
 ------
-Written by Linus Torvalds <torvalds@osdl.org>
+Originally written by Linus Torvalds <torvalds@osdl.org>, later
+revamped by Junio C Hamano.
+
 
 Documentation
 --------------

Documentation/git-hash-object.txt

@@ -3,7 +3,7 @@ git-hash-object(1)
 
 NAME
 ----
-git-hash-object - Computes object ID and optionally creates a blob from a file.
+git-hash-object - Computes object ID and optionally creates a blob from a file
 
 
 SYNOPSIS

Documentation/git-http-push.txt

@@ -3,7 +3,7 @@ git-http-push(1)
 
 NAME
 ----
-git-http-push - Push missing objects using HTTP/DAV.
+git-http-push - Push missing objects using HTTP/DAV
 
 
 SYNOPSIS

Documentation/git-imap-send.txt

@@ -0,0 +1,62 @@
+git-imap-send(1)
+================
+
+NAME
+----
+git-imap-send - Dump a mailbox from stdin into an imap folder
+
+
+SYNOPSIS
+--------
+'git-imap-send'
+
+
+DESCRIPTION
+-----------
+This command uploads a mailbox generated with git-format-patch
+into an imap drafts folder.  This allows patches to be sent as
+other email is sent with mail clients that cannot read mailbox
+files directly.
+
+Typical usage is something like:
+
+git-format-patch --signoff --stdout --attach origin | git-imap-send
+
+
+CONFIGURATION
+-------------
+
+git-imap-send requires the following values in the repository
+configuration file (shown with examples):
+
+..........................
+[imap]
+    Folder = "INBOX.Drafts"
+
+[imap]
+    Tunnel = "ssh -q user@server.com /usr/bin/imapd ./Maildir 2> /dev/null"
+
+[imap]
+    Host = imap.server.com
+    User = bob
+    Pass = pwd
+    Port = 143
+..........................
+
+
+BUGS
+----
+Doesn't handle lines starting with "From " in the message body.
+
+
+Author
+------
+Derived from isync 1.0.1 by Mike McCormack.
+
+Documentation
+--------------
+Documentation by Mike McCormack
+
+GIT
+---
+Part of the gitlink:git[7] suite

Documentation/git-init-db.txt

@@ -14,7 +14,8 @@ SYNOPSIS
 OPTIONS
 -------
 --template=<template_directory>::
-	Provide the directory in from which templates will be used.
+	Provide the directory from which templates will be used.
+	The default template directory is `/usr/share/git-core/templates`.
 
 --shared::
 	Specify that the git repository is to be shared amongst several users.
@@ -22,9 +23,17 @@ OPTIONS
 
 DESCRIPTION
 -----------
-This simply creates an empty git repository - basically a `.git` directory
+This command creates an empty git repository - basically a `.git` directory
-and `.git/object/??/`, `.git/refs/heads` and `.git/refs/tags` directories,
+with subdirectories for `objects`, `refs/heads`, `refs/tags`, and
-and links `.git/HEAD` symbolically to `.git/refs/heads/master`.
+template files.
+An initial `HEAD` file that references the HEAD of the master branch
+is also created.
+
+If `--template=<template_directory>` is 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.
 
 If the `$GIT_DIR` environment variable is set then it specifies a path
 to use instead of `./.git` for the base of the repository.
@@ -38,7 +47,6 @@ repository. When specifying `--shared` the config variable "core.sharedRepositor
 is set to 'true' so that directories under `$GIT_DIR` are made group writable
 (and g+sx, since the git group may be not the primary group of all users).
 
-
 Running `git-init-db` in an existing repository is safe. It will not overwrite
 things that are already there. The primary reason for rerunning `git-init-db`
 is to pick up newly added templates.
@@ -52,12 +60,12 @@ Start a new git repository for an existing code base::
 +
 ----------------
 $ cd /path/to/my/codebase
-$ git-init-db <1>
+$ git-init-db   <1>
-$ git-add . <2>
+$ git-add .     <2>
-
+----------------
++
 <1> prepare /path/to/my/codebase/.git directory
 <2> add all existing file to the index
-----------------
 
 
 Author

Documentation/git-instaweb.txt

@@ -0,0 +1,84 @@
+git-instaweb(1)
+===============
+
+NAME
+----
+git-instaweb - instantly browse your working repository in gitweb
+
+SYNOPSIS
+--------
+'git-instaweb' [--local] [--httpd=<httpd>] [--port=<port>] [--browser=<browser>]
+
+'git-instaweb' [--start] [--stop] [--restart]
+
+DESCRIPTION
+-----------
+A simple script to setup gitweb and a web server for browsing the local
+repository.
+
+OPTIONS
+-------
+
+-l|--local::
+	Only bind the web server to the local IP (127.0.0.1).
+
+-d|--httpd::
+	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, lighttpd and apache2 are the only supported servers.
+	(Default: lighttpd)
+
+-m|--module-path::
+	The module path (only needed if httpd is Apache).
+	(Default: /usr/lib/apache2/modules)
+
+-p|--port::
+	The port number to bind the httpd to.  (Default: 1234)
+
+-b|--browser::
+
+	The web browser command-line to execute to view the gitweb page.
+	If blank, the URL of the gitweb instance will be printed to
+	stdout.  (Default: 'firefox')
+
+--start::
+	Start the httpd instance and exit.  This does not generate
+	any of the configuration files for spawning a new instance.
+
+--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 the httpd instance and exit.  This does not generate
+	any of the configuration files for spawning a new instance.
+
+CONFIGURATION
+-------------
+
+You may specify configuration in your .git/config
+
+-----------------------------------------------------------------------
+[instaweb]
+	local = true
+	httpd = apache2 -f
+	port = 4321
+	browser = konqueror
+	modulepath = /usr/lib/apache2/modules
+
+-----------------------------------------------------------------------
+
+Author
+------
+Written by Eric Wong <normalperson@yhbt.net>
+
+Documentation
+--------------
+Documentation by Eric Wong <normalperson@yhbt.net>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+

Documentation/git-log.txt

@@ -12,12 +12,16 @@ SYNOPSIS
 
 DESCRIPTION
 -----------
-Shows the commit logs.  This command internally invokes
+Shows the commit logs.
-'git-rev-list', and the command line options are passed to that
+
-command.
+The command takes options applicable to the gitlink:git-rev-list[1]
+command to control what is shown and how, and options applicable to
+the gitlink:git-diff-tree[1] commands to control how the change
+each commit introduces are shown.
 
 This manual page describes only the most frequently used options.
 
+
 OPTIONS
 -------
 --pretty=<format>::
@@ -29,6 +33,12 @@ OPTIONS
 <since>..<until>::
 	Show only commits between the named two commits.
 
+-p::
+	Show the change the commit introduces in a patch form.
+
+<paths>...::
+	Show only commits that affect the specified paths.
+
 
 Examples
 --------
@@ -41,12 +51,17 @@ git log v2.6.12.. include/scsi drivers/scsi::
 	Show all commits since version 'v2.6.12' that changed any file
 	in the include/scsi or drivers/scsi subdirectories
 
-git log --since="2 weeks ago" -- gitk::
+git log --since="2 weeks ago" \-- gitk::
 
 	Show the changes during the last two weeks to the file 'gitk'.
 	The "--" is necessary to avoid confusion with the *branch* named
 	'gitk'
 
+git log -r --name-status release..test::
+
+	Show the commits that are in the "test" branch but not yet
+	in the "release" branch, along with the list of paths
+	each commit modifies.
 
 Author
 ------

Documentation/git-lost-found.txt

@@ -3,7 +3,7 @@ git-lost-found(1)
 
 NAME
 ----
-git-lost-found - Recover lost refs that luckily have not yet been pruned.
+git-lost-found - Recover lost refs that luckily have not yet been pruned
 
 SYNOPSIS
 --------

Documentation/git-ls-files.txt

@@ -8,13 +8,15 @@ git-ls-files - Information about files in the index/working directory
 
 SYNOPSIS
 --------
-'git-ls-files' [-z] [-t]
+[verse]
+'git-ls-files' [-z] [-t] [-v]
 		(--[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-per-directory=<file>]
-		[--full-name] [--] [<file>]\*
+		[--error-unmatch]
+		[--full-name] [--abbrev] [--] [<file>]\*
 
 DESCRIPTION
 -----------
@@ -46,6 +48,13 @@ OPTIONS
 -s|--stage::
 	Show stage files in the output
 
+--directory::
+	If a whole directory is classified as "other", show just its
+	name (with a trailing slash) and not its whole contents.
+
+--no-empty-directory::
+	Do not list empty directories. Has no effect without --directory.
+
 -u|--unmerged::
 	Show unmerged files in the output (forces --stage)
 
@@ -68,6 +77,10 @@ OPTIONS
 	read additional exclude patterns that apply only to the
 	directory and its subdirectories in <file>.
 
+--error-unmatch::
+	If any <file> does not appear in the index, treat this as an
+	error (return 1).
+
 -t::
 	Identify the file status with the following tags (followed by
 	a space) at the start of each line:
@@ -76,7 +89,11 @@ OPTIONS
 	R::	removed/deleted
 	C::	modified/changed
 	K::	to be killed
-	?	other
+	?::	other
+
+-v::
+	Similar to `-t`, but use lowercase letters for files
+	that are marked as 'always matching index'.
 
 --full-name::
 	When run from a subdirectory, the command usually
@@ -84,7 +101,12 @@ OPTIONS
 	option forces paths to be output relative to the project
 	top directory.
 
---::
+--abbrev[=<n>]::
+	Instead of showing the full 40-byte hexadecimal object
+	lines, show only handful hexdigits prefix.
+	Non default number of digits can be specified with --abbrev=<n>.
+
+\--::
 	Do not interpret any more arguments as options.
 
 <file>::
@@ -173,8 +195,7 @@ An exclude pattern is of the following format:
 
  - if it does not contain a slash '/', it is a shell glob
    pattern and used to match against the filename without
-   leading directories (i.e. the same way as the current
+   leading directories.
-   implementation).
 
  - otherwise, it is a shell glob pattern, suitable for
    consumption by fnmatch(3) with FNM_PATHNAME flag.  I.e. a
@@ -186,7 +207,7 @@ An exclude pattern is of the following format:
 An example:
 
 --------------------------------------------------------------
-    $ cat .git/ignore
+    $ cat .git/info/exclude
     # ignore objects and archives, anywhere in the tree.
     *.[oa]
     $ cat Documentation/.gitignore
@@ -196,10 +217,23 @@ An example:
     !foo.html
     $ git-ls-files --ignored \
         --exclude='Documentation/*.[0-9]' \
-        --exclude-from=.git/ignore \
+        --exclude-from=.git/info/exclude \
         --exclude-per-directory=.gitignore
 --------------------------------------------------------------
 
+Another example:
+
+--------------------------------------------------------------
+    $ cat .gitignore
+    vmlinux*
+    $ ls arch/foo/kernel/vm*
+    arch/foo/kernel/vmlinux.lds.S
+    $ echo '!/vmlinux*' >arch/foo/kernel/.gitignore
+--------------------------------------------------------------
+
+The second .gitignore keeps `arch/foo/kernel/vmlinux.lds.S` file
+from getting ignored.
+
 
 See Also
 --------

Documentation/git-ls-remote.txt

@@ -3,7 +3,7 @@ git-ls-remote(1)
 
 NAME
 ----
-git-ls-remote - Look at references other repository has.
+git-ls-remote - Look at references other repository has
 
 
 SYNOPSIS

Documentation/git-ls-tree.txt

@@ -3,12 +3,15 @@ git-ls-tree(1)
 
 NAME
 ----
-git-ls-tree - Lists the contents of a tree object.
+git-ls-tree - Lists the contents of a tree object
 
 
 SYNOPSIS
 --------
-'git-ls-tree' [-d] [-r] [-t] [-z] [--name-only] [--name-status] <tree-ish> [paths...]
+[verse]
+'git-ls-tree' [-d] [-r] [-t] [-z]
+	    [--name-only] [--name-status] [--full-name] [--abbrev=[<n>]]
+	    <tree-ish> [paths...]
 
 DESCRIPTION
 -----------
@@ -40,6 +43,15 @@ OPTIONS
 --name-status::
 	List only filenames (instead of the "long" output), one per line.
 
+--abbrev[=<n>]::
+	Instead of showing the full 40-byte hexadecimal object
+	lines, show only handful hexdigits prefix.
+	Non default number of digits can be specified with --abbrev=<n>.
+
+--full-name::
+	Instead of showing the path names relative to the current working
+	directory, show the full path names.
+
 paths::
 	When paths are given, show them (note that this isn't really raw
 	pathnames, but rather a list of patterns to match).  Otherwise
@@ -65,8 +77,6 @@ Documentation
 Documentation by David Greaves, Junio C Hamano and the git-list
 <git@vger.kernel.org>.
 
-This manual page is a stub. You can help the git documentation by expanding it.
-
 GIT
 ---
 Part of the gitlink:git[7] suite

Documentation/git-mailinfo.txt

@@ -3,7 +3,7 @@ git-mailinfo(1)
 
 NAME
 ----
-git-mailinfo - Extracts patch from a single e-mail message.
+git-mailinfo - Extracts patch from a single e-mail message
 
 
 SYNOPSIS

Documentation/git-mailsplit.txt

@@ -3,7 +3,7 @@ git-mailsplit(1)
 
 NAME
 ----
-git-mailsplit - Totally braindamaged mbox splitter program.
+git-mailsplit - Totally braindamaged mbox splitter program
 
 SYNOPSIS
 --------
@@ -25,7 +25,7 @@ OPTIONS
 
 -b::
 	If any file doesn't begin with a From line, assume it is a
-	single mail message instead of signalling error.
+	single mail message instead of signaling error.
 
 -d<prec>::
 	Instead of the default 4 digits with leading zeros,

Documentation/git-merge-base.txt

@@ -8,16 +8,26 @@ git-merge-base - Finds as good a common ancestor as possible for a merge
 
 SYNOPSIS
 --------
-'git-merge-base' <commit> <commit>
+'git-merge-base' [--all] <commit> <commit>
 
 DESCRIPTION
 -----------
-"git-merge-base" finds as good a common ancestor as possible. Given a
+
-selection of equally good common ancestors it should not be relied on
+"git-merge-base" finds as good a common ancestor as possible between
-to decide in any particular way.
+the two commits. That is, given two commits A and B 'git-merge-base A
+B' will output a commit which is reachable from both A and B through
+the parent relationship.
+
+Given a selection of equally good common ancestors it should not be
+relied on to decide in any particular way.
 
 The "git-merge-base" algorithm is still in flux - use the source...
 
+OPTIONS
+-------
+--all::
+	Output all common ancestors for the two commits instead of
+	just one.
 
 Author
 ------

Documentation/git-merge-index.txt

@@ -8,7 +8,7 @@ git-merge-index - Runs 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
 -----------
@@ -19,7 +19,7 @@ files are passed as arguments 5, 6 and 7.
 
 OPTIONS
 -------
---::
+\--::
 	Do not interpret any more arguments as options.
 
 -a::
@@ -69,7 +69,7 @@ or
   fatal: merge program failed
 
 where the latter example shows how "git-merge-index" will stop trying to
-merge once anything has returned an error (ie "cat" returned an error
+merge once anything has returned an error (i.e., "cat" returned an error
 for the AA file, because it didn't exist in the original, and thus
 "git-merge-index" didn't even try to merge the MM thing).
 

Documentation/git-merge-tree.txt

@@ -0,0 +1,37 @@
+git-merge-tree(1)
+=================
+
+NAME
+----
+git-merge-tree - Show three-way merge without touching index
+
+
+SYNOPSIS
+--------
+'git-merge-tree' <base-tree> <branch1> <branch2>
+
+DESCRIPTION
+-----------
+Reads three treeish, and output trivial merge results and
+conflicting stages to the standard output.  This is similar to
+what three-way read-tree -m does, but instead of storing the
+results in the index, the command outputs the entries to the
+standard output.
+
+This is meant to be used by higher level scripts to compute
+merge results outside index, and stuff the results back into the
+index.  For this reason, the output from the command omits
+entries that match <branch1> tree.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+

Documentation/git-merge.txt

@@ -83,7 +83,7 @@ your local modifications interfere with the merge, again, it
 stops before touching anything.
 
 So in the above two "failed merge" case, you do not have to
-worry about lossage of data --- you simply were not ready to do
+worry about loss of data --- you simply were not ready to do
 a merge, so no merge happened at all.  You may want to finish
 whatever you were in the middle of doing, and retry the same
 pull after you are done and ready.

Documentation/git-mktree.txt

@@ -0,0 +1,35 @@
+git-mktree(1)
+=============
+
+NAME
+----
+git-mktree - Build a tree-object from ls-tree formatted text
+
+
+SYNOPSIS
+--------
+'git-mktree' [-z]
+
+DESCRIPTION
+-----------
+Reads standard input in non-recursive `ls-tree` output format,
+and creates a tree object.  The object name of the tree object
+built is written to the standard output.
+
+OPTIONS
+-------
+-z::
+	Read the NUL-terminated `ls-tree -z` output instead.
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+

Documentation/git-mv.txt

@@ -3,7 +3,7 @@ git-mv(1)
 
 NAME
 ----
-git-mv - Script used to move or rename a file, directory or symlink.
+git-mv - Move or rename a file, directory or symlink
 
 
 SYNOPSIS

Documentation/git-name-rev.txt

@@ -3,12 +3,12 @@ git-name-rev(1)
 
 NAME
 ----
-git-name-rev - Find symbolic names for given revs.
+git-name-rev - Find symbolic names for given revs
 
 
 SYNOPSIS
 --------
-'git-name-rev' [--tags] ( --all | --stdin | <commitish>... )
+'git-name-rev' [--tags] ( --all | --stdin | <committish>... )
 
 DESCRIPTION
 -----------
@@ -26,14 +26,14 @@ OPTIONS
 	List all commits reachable from all refs
 
 --stdin::
-	Read from stdin, append "(<rev_name>)" to all sha1's of name'able
+	Read from stdin, append "(<rev_name>)" to all sha1's of nameable
 	commits, and pass to stdout
 
 EXAMPLE
 -------
 
 Given a commit, find out where it is relative to the local refs. Say somebody
-wrote you about that phantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
+wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
 Of course, you look into the commit, but that only tells you what happened, but
 not the context.
 
@@ -41,6 +41,7 @@ Enter git-name-rev:
 
 ------------
 % git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
+33db5f4d9027a10e477ccf054b2c1ab94f74c85a tags/v0.99^0~940
 ------------
 
 Now you are wiser, because you know that it happened 940 revisions before v0.99.

Documentation/git-p4import.txt

@@ -0,0 +1,168 @@
+git-p4import(1)
+===============
+
+NAME
+----
+git-p4import - Import a Perforce repository into git
+
+
+SYNOPSIS
+--------
+`git-p4import` [-q|-v] [--notags] [--authors <file>] [-t <timezone>] <//p4repo/path> <branch>
+
+`git-p4import` --stitch <//p4repo/path>
+
+`git-p4import`
+
+
+DESCRIPTION
+-----------
+Import a Perforce repository into an existing git repository.  When
+a <//p4repo/path> and <branch> are specified a new branch with the
+given name will be created and the initial import will begin.
+
+Once the initial import is complete you can do an incremental import
+of new commits from the Perforce repository.  You do this by checking
+out the appropriate git branch and then running `git-p4import` without
+any options.
+
+The standard p4 client is used to communicate with the Perforce
+repository; it must be configured correctly in order for `git-p4import`
+to operate (see below).
+
+
+OPTIONS
+-------
+-q::
+	Do not display any progress information.
+
+-v::
+        Give extra progress information.
+
+\--authors::
+	Specify an authors file containing a mapping of Perforce user
+	ids to full names and email addresses (see Notes below).
+
+\--notags::
+	Do not create a tag for each imported commit.
+
+\--stitch::
+	Import the contents of the given perforce branch into the
+	currently checked out git branch.
+
+\--log::
+	Store debugging information in the specified file.
+
+-t::
+	Specify that the remote repository is in the specified timezone.
+	Timezone must be in the format "US/Pacific" or "Europe/London"
+	etc.  You only need to specify this once, it will be saved in
+	the git config file for the repository.
+
+<//p4repo/path>::
+	The Perforce path that will be imported into the specified branch.
+
+<branch>::
+	The new branch that will be created to hold the Perforce imports.
+
+
+P4 Client
+---------
+You must make the `p4` client command available in your $PATH and
+configure it to communicate with the target Perforce repository.
+Typically this means you must set the "$P4PORT" and "$P4CLIENT"
+environment variables.
+
+You must also configure a `p4` client "view" which maps the Perforce
+branch into the top level of your git repository, for example:
+
+------------
+Client: myhost
+
+Root:   /home/sean/import
+
+Options:   noallwrite clobber nocompress unlocked modtime rmdir
+
+View:
+        //public/jam/... //myhost/jam/...
+------------
+
+With the above `p4` client setup, you could import the "jam"
+perforce branch into a branch named "jammy", like so:
+
+------------
+$ mkdir -p /home/sean/import/jam
+$ cd /home/sean/import/jam
+$ git init-db
+$ git p4import //public/jam jammy
+------------
+
+
+Multiple Branches
+-----------------
+Note that by creating multiple "views" you can use `git-p4import`
+to import additional branches into the same git repository.
+However, the `p4` client has a limitation in that it silently
+ignores all but the last "view" that maps into the same local
+directory.  So the following will *not* work:
+
+------------
+View:
+        //public/jam/... //myhost/jam/...
+        //public/other/... //myhost/jam/...
+        //public/guest/... //myhost/jam/...
+------------
+
+If you want more than one Perforce branch to be imported into the
+same directory you must employ a workaround.  A simple option is
+to adjust your `p4` client before each import to only include a
+single view.
+
+Another option is to create multiple symlinks locally which all
+point to the same directory in your git repository and then use
+one per "view" instead of listing the actual directory.
+
+
+Tags
+----
+A git tag of the form p4/xx is created for every change imported from
+the Perforce repository where xx is the Perforce changeset number.
+Therefore after the import you can use git to access any commit by its
+Perforce number, e.g. git show p4/327.
+
+The tag associated with the HEAD commit is also how `git-p4import`
+determines if there are new changes to incrementally import from the
+Perforce repository.
+
+If you import from a repository with many thousands of changes
+you will have an equal number of p4/xxxx git tags.  Git tags can
+be expensive in terms of disk space and repository operations.
+If you don't need to perform further incremental imports, you
+may delete the tags.
+
+
+Notes
+-----
+You can interrupt the import (e.g. ctrl-c) at any time and restart it
+without worry.
+
+Author information is automatically determined by querying the
+Perforce "users" table using the id associated with each change.
+However, if you want to manually supply these mappings you can do
+so with the "--authors" option.  It accepts a file containing a list
+of mappings with each line containing one mapping in the format:
+
+------------
+    perforce_id = Full Name <email@address.com>
+------------
+
+
+Author
+------
+Written by Sean Estabrooks <seanlkml@sympatico.ca>
+
+
+GIT
+---
+Part of the gitlink:git[7] suite
+

Documentation/git-pack-objects.txt

@@ -3,12 +3,15 @@ git-pack-objects(1)
 
 NAME
 ----
-git-pack-objects - Create a packed archive of objects.
+git-pack-objects - Create a packed archive of objects
 
 
 SYNOPSIS
 --------
-'git-pack-objects' [--non-empty] [--local] [--incremental] [--window=N] [--depth=N] {--stdout | base-name} < object-list
+[verse]
+'git-pack-objects' [-q] [--no-reuse-delta] [--non-empty]
+	[--local] [--incremental] [--window=N] [--depth=N]
+	{--stdout | base-name} < object-list
 
 
 DESCRIPTION
@@ -32,6 +35,10 @@ Placing both in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
 any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)
 enables git to read from such an archive.
 
+In a packed archive, an object is either stored as a compressed
+whole, or as a difference from some other object.  The latter is
+often called a delta.
+
 
 OPTIONS
 -------
@@ -74,6 +81,18 @@ base-name::
         Only create a packed archive if it would contain at
         least one object.
 
+-q::
+	This flag makes the command not to report its progress
+	on the standard error stream.
+
+--no-reuse-delta::
+	When creating a packed archive in a repository that
+	has existing packs, the command reuses existing deltas.
+	This sometimes results in a slightly suboptimal pack.
+	This flag tells the command not to reuse existing deltas
+	but compute them from scratch.
+
+
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org>
@@ -82,7 +101,7 @@ Documentation
 -------------
 Documentation by Junio C Hamano
 
-See-Also
+See Also
 --------
 gitlink:git-repack[1]
 gitlink:git-prune-packed[1]

Documentation/git-pack-redundant.txt

@@ -3,12 +3,12 @@ git-pack-redundant(1)
 
 NAME
 ----
-git-pack-redundant - Program used to find redundant pack files.
+git-pack-redundant - Program used to find redundant pack files
 
 
 SYNOPSIS
 --------
-'git-pack-redundant [ --verbose ] [ --alt-odb ] < --all | .pack filename ... >'
+'git-pack-redundant' [ --verbose ] [ --alt-odb ] < --all | .pack filename ... >
 
 DESCRIPTION
 -----------
@@ -29,7 +29,7 @@ OPTIONS
 
 
 --all::
-	Processes all packs. Any filenames on the commandline are ignored.
+	Processes all packs. Any filenames on the command line are ignored.
 
 --alt-odb::
 	Don't require objects present in packs from alternate object
@@ -46,7 +46,7 @@ Documentation
 --------------
 Documentation by Lukas Sandström <lukass@etek.chalmers.se>
 
-See-Also
+See Also
 --------
 gitlink:git-pack-objects[1]
 gitlink:git-repack[1]

Documentation/git-patch-id.txt

@@ -3,7 +3,7 @@ git-patch-id(1)
 
 NAME
 ----
-git-patch-id - Generate a patch ID.
+git-patch-id - Generate a patch ID
 
 SYNOPSIS
 --------
@@ -13,7 +13,7 @@ DESCRIPTION
 -----------
 A "patch ID" is nothing but a SHA1 of the diff associated with a patch, with
 whitespace and line numbers ignored.  As such, it's "reasonably stable", but at
-the same time also reasonably unique, ie two patches that have the same "patch
+the same time also reasonably unique, i.e., two patches that have the same "patch
 ID" are almost guaranteed to be the same thing.
 
 IOW, you can use this thing to look for likely duplicate commits.

Documentation/git-peek-remote.txt

@@ -3,7 +3,7 @@ git-peek-remote(1)
 
 NAME
 ----
-git-peek-remote - Lists the references in a remote repository.
+git-peek-remote - Lists the references in a remote repository
 
 
 SYNOPSIS

Documentation/git-prune-packed.txt

@@ -40,7 +40,7 @@ Documentation
 --------------
 Documentation by Ryan Anderson <ryan@michonline.com>
 
-See-Also
+See Also
 --------
 gitlink:git-pack-objects[1]
 gitlink:git-repack[1]

Documentation/git-prune.txt

@@ -28,7 +28,7 @@ OPTIONS
 	Do not remove anything; just report what it would
 	remove.
 
---::
+\--::
 	Do not interpret any more arguments as options.
 
 <head>...::

Documentation/git-pull.txt

@@ -3,7 +3,7 @@ git-pull(1)
 
 NAME
 ----
-git-pull - Pull and merge from another repository.
+git-pull - Pull and merge from another repository
 
 
 SYNOPSIS
@@ -29,8 +29,9 @@ include::fetch-options.txt[]
 
 include::pull-fetch-param.txt[]
 
-include::merge-strategies.txt[]
+include::urls.txt[]
 
+include::merge-strategies.txt[]
 
 EXAMPLES
 --------

Documentation/git-push.txt

@@ -3,12 +3,12 @@ git-push(1)
 
 NAME
 ----
-git-push - Update remote refs along with associated objects.
+git-push - Update remote refs along with associated objects
 
 
 SYNOPSIS
 --------
-'git-push' [--all] [--force] <repository> <refspec>...
+'git-push' [--all] [--tags] [--force] <repository> <refspec>...
 
 DESCRIPTION
 -----------
@@ -16,25 +16,62 @@ DESCRIPTION
 Updates remote refs using local refs, while sending objects
 necessary to complete the given refs.
 
-You can make "interesting" things to happen on the repository
+You can make interesting things happen to a repository
 every time you push into it, by setting up 'hooks' there.  See
 documentation for gitlink:git-receive-pack[1].
 
 
 OPTIONS
 -------
-include::pull-fetch-param.txt[]
+<repository>::
+	The "remote" repository that is destination of a push
+	operation.  See the section <<URLS,GIT URLS>> below.
+
+<refspec>::
+	The canonical format of a <refspec> parameter is
+	`+?<src>:<dst>`; that is, an optional plus `+`, followed
+	by the source ref, followed by a colon `:`, followed by
+	the destination ref.
++
+The <src> side can be an
+arbitrary "SHA1 expression" that can be used as an
+argument to `git-cat-file -t`.  E.g. `master~4` (push
+four parents before the current master head).
++
+The local ref that matches <src> is used
+to fast forward the remote ref that matches <dst>.  If
+the optional plus `+` is used, the remote ref is updated
+even if it does not result in a fast forward update.
++
+Note: If no explicit refspec is found, (that is neither
+on the command line nor in any Push line of the
+corresponding remotes file---see below), then all the
+refs that exist both on the local side and on the remote
+side are updated.
++
+Some short-cut notations are also supported.
++
+* `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
+* A parameter <ref> without a colon is equivalent to
+  <ref>`:`<ref>, hence updates <ref> in the destination from <ref>
+  in the source.
 
 \--all::
-	Instead of naming each ref to push, specifies all refs
+	Instead of naming each ref to push, specifies that all
-	to be pushed.
+	refs be pushed.
+
+\--tags::
+	All refs under `$GIT_DIR/refs/tags` are pushed, in
+	addition to refspecs explicitly listed on the command
+	line.
 
 -f, \--force::
-	Usually, the command refuses to update a local ref that is
+	Usually, the command refuses to update a remote ref that is
-	not an ancestor of the remote ref used to overwrite it.
+	not a descendant of the local ref used to overwrite it.
-	This flag disables the check.  What this means is that the
+	This flag disables the check.  This can cause the
-	local repository can lose commits; use it with care.
+	remote repository to lose commits; use it with care.
 
+include::urls.txt[]
 
 Author
 ------

Documentation/git-quiltimport.txt

@@ -0,0 +1,61 @@
+git-quiltimport(1)
+================
+
+NAME
+----
+git-quiltimport - Applies a quilt patchset onto the current branch
+
+
+SYNOPSIS
+--------
+[verse]
+'git-quiltimport' [--dry-run] [--author <author>] [--patches <dir>]
+
+
+DESCRIPTION
+-----------
+Applies a quilt patchset onto the current git branch, preserving
+the patch boundaries, patch order, and patch descriptions present
+in the quilt patchset.
+
+For each patch the code attempts to extract the author from the
+patch description.  If that fails it falls back to the author
+specified with --author.  If the --author flag was not given
+the patch description is displayed and the user is asked to
+interactively enter the author of the patch.
+
+If a subject is not found in the patch description the patch name is
+preserved as the 1 line subject in the git description.
+
+OPTIONS
+-------
+--dry-run::
+	Walk through the patches in the series and warn
+	if we cannot find all of the necessary information to commit
+	a patch.  At the time of this writing only missing author
+	information is warned about.
+
+--author Author Name <Author Email>::
+	The author name and email address to use when no author
+	information can be found in the patch description.
+
+--patches <dir>::
+	The directory to find the quilt patches and the
+	quilt series file.
+
+        The default for the patch directory is patches
+	or the value of the $QUILT_PATCHES environment
+	variable.
+
+Author
+------
+Written by Eric Biederman <ebiederm@lnxi.com>
+
+Documentation
+--------------
+Documentation by Eric Biederman <ebiederm@lnxi.com>
+
+GIT
+---
+Part of the gitlink:git[7] suite
+

Documentation/git-read-tree.txt

@@ -8,7 +8,7 @@ git-read-tree - Reads tree information into the index
 
 SYNOPSIS
 --------
-'git-read-tree' (<tree-ish> | [[-m | --reset] [-u | -i]] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
+'git-read-tree' (<tree-ish> | [[-m [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
 
 
 DESCRIPTION
@@ -50,6 +50,28 @@ OPTIONS
 	trees that are not directly related to the current
 	working tree status into a temporary index file.
 
+--aggressive::
+	Usually a three-way merge by `git-read-tree` resolves
+	the merge for really trivial cases and leaves other
+	cases unresolved in the index, so that Porcelains can
+	implement different merge policies.  This flag makes the
+	command to resolve a few more cases internally:
++
+* when one side removes a path and the other side leaves the path
+  unmodified.  The resolution is to remove that path.
+* when both sides remove a path.  The resolution is to remove that path.
+* when both sides adds a path identically.  The resolution
+  is to add that path.
+
+--prefix=<prefix>/::
+	Keep the current index contents, and read the contents
+	of named tree-ish under directory at `<prefix>`.  The
+	original index file cannot have anything at the path
+	`<prefix>` itself, and have nothing in `<prefix>/`
+	directory.  Note that the `<prefix>/` value must end
+	with a slash.
+
+
 <tree-ish#>::
 	The id of the tree object(s) to be read/merged.
 
@@ -192,7 +214,7 @@ The `git-write-tree` command refuses to write a nonsensical tree, and it
 will complain about unmerged entries if it sees a single entry that is not
 stage 0.
 
-Ok, this all sounds like a collection of totally nonsensical rules,
+OK, this all sounds like a collection of totally nonsensical rules,
 but it's actually exactly what you want in order to do a fast
 merge. The different stages represent the "result tree" (stage 0, aka
 "merged"), the original tree (stage 1, aka "orig"), and the two trees
@@ -213,7 +235,7 @@ populated.  Here is an outline of how the algorithm works:
 
 - the index file saves and restores with all this information, so you
   can merge things incrementally, but as long as it has entries in
-  stages 1/2/3 (ie "unmerged entries") you can't write the result. So
+  stages 1/2/3 (i.e., "unmerged entries") you can't write the result. So
   now the merge algorithm ends up being really simple:
 
   * you walk the index in order, and ignore all entries of stage 0,
@@ -244,7 +266,7 @@ file that does not match stage 2.
 This is done to prevent you from losing your work-in-progress
 changes, and mixing your random changes in an unrelated merge
 commit.  To illustrate, suppose you start from what has been
-commited last to your repository:
+committed last to your repository:
 
 ----------------
 $ JC=`git-rev-parse --verify "HEAD^0"`

Documentation/git-rebase.txt

@@ -3,24 +3,142 @@ git-rebase(1)
 
 NAME
 ----
-git-rebase - Rebase local commits to new upstream head.
+git-rebase - Rebase local commits to a new head
 
 SYNOPSIS
 --------
-'git-rebase' <upstream> [<head>]
+'git-rebase' [--merge] [--onto <newbase>] <upstream> [<branch>]
+
+'git-rebase' --continue | --skip | --abort
 
 DESCRIPTION
 -----------
-Rebases local commits to the new head of the upstream tree.
+git-rebase replaces <branch> with a new branch of the same name.  When
+the --onto option is provided the new branch starts out with a HEAD equal
+to <newbase>, otherwise it is equal to <upstream>.  It then attempts to
+create a new commit for each commit from the original <branch> that does
+not exist in the <upstream> branch.
+
+It is possible that a merge failure will prevent this process from being
+completely automatic.  You will have to resolve any such merge failure
+and run `git rebase --continue`.  Another option is to bypass the commit
+that caused the merge failure with `git rebase --skip`.  To restore the
+original <branch> and remove the .dotest working files, use the command
+`git rebase --abort` instead.
+
+Note that if <branch> is not specified on the command line, the currently
+checked out branch is used.
+
+Assume the following history exists and the current branch is "topic":
+
+------------
+          A---B---C topic
+         /
+    D---E---F---G master
+------------
+
+From this point, the result of either of the following commands:
+
+
+    git-rebase master
+    git-rebase master topic
+
+would be:
+
+------------
+                  A'--B'--C' topic
+                 /
+    D---E---F---G master
+------------
+
+While, starting from the same point, the result of either of the following
+commands:
+
+    git-rebase --onto master~1 master
+    git-rebase --onto master~1 master topic
+
+would be:
+
+------------
+              A'--B'--C' topic
+             /
+    D---E---F---G master
+------------
+
+In case of conflict, git-rebase will stop at the first problematic commit
+and leave conflict markers in the tree.  You can use git diff to locate
+the markers (<<<<<<) and make edits to resolve the conflict.  For each
+file you edit, you need to tell git that the conflict has been resolved,
+typically this would be done with
+
+
+    git update-index <filename>
+
+
+After resolving the conflict manually and updating the index with the
+desired resolution, you can continue the rebasing process with
+
+
+    git rebase --continue
+
+
+Alternatively, you can undo the git-rebase with
+
+
+    git rebase --abort
 
 OPTIONS
 -------
+<newbase>::
+	Starting point at which to create the new commits. If the
+	--onto option is not specified, the starting point is
+	<upstream>.
+
 <upstream>::
 	Upstream branch to compare against.
 
-<head>::
+<branch>::
 	Working branch; defaults to HEAD.
 
+--continue::
+	Restart the rebasing process after having resolved a merge conflict.
+
+--abort::
+	Restore the original branch and abort the rebase operation.
+
+--skip::
+	Restart the rebasing process by skipping the current patch.
+
+--merge::
+	Use merging strategies to rebase.  When the recursive (default) merge
+	strategy is used, this allows rebase to be aware of renames on the
+	upstream side.
+
+-s <strategy>, \--strategy=<strategy>::
+	Use the given merge strategy; can be supplied more than
+	once to specify them in the order they should be tried.
+	If there is no `-s` option, a built-in list of strategies
+	is used instead (`git-merge-recursive` when merging a single
+	head, `git-merge-octopus` otherwise).  This implies --merge.
+
+include::merge-strategies.txt[]
+
+NOTES
+-----
+When you rebase a branch, you are changing its history in a way that
+will cause problems for anyone who already has a copy of the branch
+in their repository and tries to pull updates from you.  You should
+understand the implications of using 'git rebase' on a repository that
+you share.
+
+When the git rebase command is run, it will first execute a "pre-rebase"
+hook if one exists.  You can use this hook to do sanity checks and
+reject the rebase if it isn't appropriate.  Please see the template
+pre-rebase hook script for an example.
+
+You must be in the top directory of your project to start (or continue)
+a rebase.  Upon completion, <branch> will be the current branch.
+
 Author
 ------
 Written by Junio C Hamano <junkio@cox.net>

Documentation/git-receive-pack.txt

@@ -18,8 +18,7 @@ information fed from the remote end.
 This command is usually not invoked directly by the end user.
 The UI for the protocol is on the 'git-send-pack' side, and the
 program pair is meant to be used to push updates to remote
-repository.  For pull operations, see 'git-fetch-pack' and
+repository.  For pull operations, see 'git-fetch-pack'.
-'git-clone-pack'.
 
 The command allows for creation and fast forwarding of sha1 refs
 (heads/tags) on the remote end (strictly speaking, it is the

Documentation/git-relink.txt

@@ -3,7 +3,7 @@ git-relink(1)
 
 NAME
 ----
-git-relink - Hardlink common objects in local repositories.
+git-relink - Hardlink common objects in local repositories
 
 SYNOPSIS
 --------

Documentation/git-repack.txt

@@ -9,7 +9,7 @@ objects into pack files.
 
 SYNOPSIS
 --------
-'git-repack' [-a] [-d] [-l] [-n]
+'git-repack' [-a] [-d] [-f] [-l] [-n] [-q]
 
 DESCRIPTION
 -----------
@@ -38,11 +38,20 @@ OPTIONS
 -d::
 	After packing, if the newly created packs make some
 	existing packs redundant, remove the redundant packs.
+	Also runs gitlink:git-prune-packed[1].
 
 -l::
         Pass the `--local` option to `git pack-objects`, see
         gitlink:git-pack-objects[1].
 
+-f::
+        Pass the `--no-reuse-delta` option to `git pack-objects`, see
+        gitlink:git-pack-objects[1].
+
+-q::
+        Pass the `-q` option to `git pack-objects`, see
+        gitlink:git-pack-objects[1].
+
 -n::
         Do not update the server information with
         `git update-server-info`.
@@ -55,7 +64,7 @@ Documentation
 --------------
 Documentation by Ryan Anderson <ryan@michonline.com>
 
-See-Also
+See Also
 --------
 gitlink:git-pack-objects[1]
 gitlink:git-prune-packed[1]

Documentation/git-repo-config.txt

@@ -3,17 +3,19 @@ git-repo-config(1)
 
 NAME
 ----
-git-repo-config - Get and set options in .git/config.
+git-repo-config - Get and set options in .git/config
 
 
 SYNOPSIS
 --------
-'git-repo-config' name [value [value_regex]]
+[verse]
-'git-repo-config' --replace-all name [value [value_regex]]
+'git-repo-config' [type] name [value [value_regex]]
-'git-repo-config' --get name [value_regex]
+'git-repo-config' [type] --replace-all name [value [value_regex]]
-'git-repo-config' --get-all name [value_regex]
+'git-repo-config' [type] --get name [value_regex]
-'git-repo-config' --unset name [value_regex]
+'git-repo-config' [type] --get-all name [value_regex]
-'git-repo-config' --unset-all name [value_regex]
+'git-repo-config' [type] --unset name [value_regex]
+'git-repo-config' [type] --unset-all name [value_regex]
+'git-repo-config' -l | --list
 
 DESCRIPTION
 -----------
@@ -21,15 +23,22 @@ You can query/set/replace/unset options with this command. The name is
 actually the section and the key separated by a dot, and the value will be
 escaped.
 
-If you want to set/unset an option which can occur on multiple lines, you
+If you want to set/unset an option which can occur on multiple
-should provide a POSIX regex for the value. If you want to handle the lines
+lines, a POSIX regexp `value_regex` needs to be given.  Only the
-*not* matching the regex, just prepend a single exclamation mark in front
+existing values that match the regexp are updated or unset.  If
-(see EXAMPLES).
+you want to handle the lines that do *not* match the regex, just
+prepend a single exclamation mark in front (see EXAMPLES).
 
-This command will fail if
+The type specifier can be either '--int' or '--bool', which will make
+'git-repo-config' ensure that the variable(s) are of the given type and
+convert the value to the canonical form (simple decimal number for int,
+a "true" or "false" string for bool). If no type specifier is passed,
+no checks or transformations are performed on the value.
 
-. .git/config is invalid,
+This command will fail if:
-. .git/config can not be written to,
+
+. The .git/config file is invalid,
+. Can not write to .git/config,
 . no section was provided,
 . the section or key is invalid,
 . you try to unset an option which does not exist, or
@@ -40,8 +49,8 @@ OPTIONS
 -------
 
 --replace-all::
-	Default behaviour is to replace at most one line. This replaces
+	Default behavior is to replace at most one line. This replaces
-	all lines matching the key (and optionally the value_regex)
+	all lines matching the key (and optionally the value_regex).
 
 --get::
 	Get the value for a given key (optionally filtered by a regex
@@ -51,12 +60,30 @@ OPTIONS
 	Like get, but does not fail if the number of values for the key
 	is not exactly one.
 
+--get-regexp::
+	Like --get-all, but interprets the name as a regular expression.
+
 --unset::
 	Remove the line matching the key from .git/config.
 
 --unset-all::
 	Remove all matching lines from .git/config.
 
+-l, --list::
+	List all variables set in .git/config.
+
+
+ENVIRONMENT
+-----------
+
+GIT_CONFIG::
+	Take the configuration from the given file instead of .git/config.
+
+GIT_CONFIG_LOCAL::
+	Currently the same as $GIT_CONFIG; when Git will support global
+	configuration files, this will cause it to take the configuration
+	from the global configuration file in addition to the given file.
+
 
 EXAMPLE
 -------
@@ -80,11 +107,11 @@ Given a .git/config like this:
 		renames = true
 
 	; Proxy settings
-	[proxy]
+	[core]
-		command="ssh" for "ssh://kernel.org/"
+		gitproxy="ssh" for "ssh://kernel.org/"
-		command="proxy-command" for kernel.org
+		gitproxy="proxy-command" for kernel.org
-		command="myprotocol-command" for "my://"
+		gitproxy="myprotocol-command" for "my://"
-		command=default-proxy ; for all the rest
+		gitproxy=default-proxy ; for all the rest
 
 you can set the filemode to true with
 
@@ -92,12 +119,12 @@ you can set the filemode to true with
 % git repo-config core.filemode true
 ------------
 
-The hypothetic proxy command entries actually have a postfix to discern
+The hypothetical proxy command entries actually have a postfix to discern
-to what URL they apply. Here is how to change the entry for kernel.org
+what URL they apply to. Here is how to change the entry for kernel.org
 to "ssh".
 
 ------------
-% git repo-config proxy.command '"ssh" for kernel.org' 'for kernel.org$'
+% git repo-config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'
 ------------
 
 This makes sure that only the key/value pair for kernel.org is replaced.
@@ -108,7 +135,7 @@ To delete the entry for renames, do
 % git repo-config --unset diff.renames
 ------------
 
-If you want to delete an entry for a multivar (like proxy.command above),
+If you want to delete an entry for a multivar (like core.gitproxy above),
 you have to provide a regex matching the value of exactly one line.
 
 To query the value for a given key, do
@@ -126,27 +153,27 @@ or
 or, to query a multivar:
 
 ------------
-% git repo-config --get proxy.command "for kernel.org$"
+% git repo-config --get core.gitproxy "for kernel.org$"
 ------------
 
 If you want to know all the values for a multivar, do:
 
 ------------
-% git repo-config --get-all proxy.command
+% git repo-config --get-all core.gitproxy
 ------------
 
-If you like to live dangerous, you can replace *all* proxy.commands by a
+If you like to live dangerous, you can replace *all* core.gitproxy by a
 new one with
 
 ------------
-% git repo-config --replace-all proxy.command ssh
+% git repo-config --replace-all core.gitproxy ssh
 ------------
 
 However, if you really only want to replace the line for the default proxy,
 i.e. the one without a "for ..." postfix, do something like this:
 
 ------------
-% git repo-config proxy.command ssh '! for '
+% git repo-config core.gitproxy ssh '! for '
 ------------
 
 To actually match only values with an exclamation mark, you have to
@@ -156,13 +183,16 @@ To actually match only values with an exclamation mark, you have to
 ------------
 
 
+include::config.txt[]
+
+
 Author
 ------
 Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
 
 Documentation
 --------------
-Documentation by Johannes Schindelin.
+Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.kernel.org>.
 
 GIT
 ---

Documentation/git-request-pull.txt

@@ -3,7 +3,7 @@ git-request-pull(1)
 
 NAME
 ----
-git-request-pull - Generates a summary of pending changes.
+git-request-pull - Generates a summary of pending changes
 
 SYNOPSIS
 --------

Documentation/git-rerere.txt

@@ -0,0 +1,177 @@
+git-rerere(1)
+=============
+
+NAME
+----
+git-rerere - Reuse recorded resolve
+
+SYNOPSIS
+--------
+'git-rerere'
+
+
+DESCRIPTION
+-----------
+
+In a workflow that employs relatively long lived topic branches,
+the developer sometimes needs to resolve the same conflict over
+and over again until the topic branches are done (either merged
+to the "release" branch, or sent out and accepted upstream).
+
+This command helps this process by recording conflicted
+automerge results and corresponding hand-resolve results on the
+initial manual merge, and later by noticing the same automerge
+results and applying the previously recorded hand resolution.
+
+[NOTE]
+You need to create `$GIT_DIR/rr-cache` directory to enable this
+command.
+
+DISCUSSION
+----------
+
+When your topic branch modifies overlapping area that your
+master branch (or upstream) touched since your topic branch
+forked from it, you may want to test it with the latest master,
+even before your topic branch is ready to be pushed upstream:
+
+------------
+              o---*---o topic
+             /
+    o---o---o---*---o---o master
+------------
+
+For such a test, you need to merge master and topic somehow.
+One way to do it is to pull master into the topic branch:
+
+------------
+	$ git checkout topic
+	$ git pull . master
+
+              o---*---o---+ topic
+             /           /
+    o---o---o---*---o---o master
+------------
+
+The commits marked with `*` touch the same area in the same
+file; you need to resolve the conflicts when creating the commit
+marked with `+`.  Then you can test the result to make sure your
+work-in-progress still works with what is in the latest master.
+
+After this test merge, there are two ways to continue your work
+on the topic.  The easiest is to build on top of the test merge
+commit `+`, and when your work in the topic branch is finally
+ready, pull the topic branch into master, and/or ask the
+upstream to pull from you.  By that time, however, the master or
+the upstream might have been advanced since the test merge `+`,
+in which case the final commit graph would look like this:
+
+------------
+	$ git checkout topic
+	$ git pull . master
+	$ ... work on both topic and master branches
+	$ git checkout master
+	$ git pull . topic
+
+              o---*---o---+---o---o topic
+             /           /         \
+    o---o---o---*---o---o---o---o---+ master
+------------
+
+When your topic branch is long-lived, however, your topic branch
+would end up having many such "Merge from master" commits on it,
+which would unnecessarily clutter the development history.
+Readers of the Linux kernel mailing list may remember that Linus
+complained about such too frequent test merges when a subsystem
+maintainer asked to pull from a branch full of "useless merges".
+
+As an alternative, to keep the topic branch clean of test
+merges, you could blow away the test merge, and keep building on
+top of the tip before the test merge:
+
+------------
+	$ git checkout topic
+	$ git pull . master
+	$ git reset --hard HEAD^ ;# rewind the test merge
+	$ ... work on both topic and master branches
+	$ git checkout master
+	$ git pull . topic
+
+              o---*---o-------o---o topic
+             /                     \
+    o---o---o---*---o---o---o---o---+ master
+------------
+
+This would leave only one merge commit when your topic branch is
+finally ready and merged into the master branch.  This merge
+would require you to resolve the conflict, introduced by the
+commits marked with `*`.  However, often this conflict is the
+same conflict you resolved when you created the test merge you
+blew away.  `git-rerere` command helps you to resolve this final
+conflicted merge using the information from your earlier hand
+resolve.
+
+Running `git-rerere` command immediately after a conflicted
+automerge records the conflicted working tree files, with the
+usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in
+them.  Later, after you are done resolving the conflicts,
+running `git-rerere` again records the resolved state of these
+files.  Suppose you did this when you created the test merge of
+master into the topic branch.
+
+Next time, running `git-rerere` after seeing a conflicted
+automerge, if the conflict is the same as the earlier one
+recorded, it is noticed and a three-way merge between the
+earlier conflicted automerge, the earlier manual resolution, and
+the current conflicted automerge is performed by the command.
+If this three-way merge resolves cleanly, the result is written
+out to your working tree file, so you would not have to manually
+resolve it.  Note that `git-rerere` leaves the index file alone,
+so you still need to do the final sanity checks with `git diff`
+(or `git diff -c`) and `git update-index` when you are
+satisfied.
+
+As a convenience measure, `git-merge` automatically invokes
+`git-rerere` when it exits with a failed automerge, which
+records it if it is a new conflict, or reuses the earlier hand
+resolve when it is not.  `git-commit` also invokes `git-rerere`
+when recording a merge result.  What this means is that you do
+not have to do anything special yourself (Note: you still have
+to create `$GIT_DIR/rr-cache` directory to enable this command).
+
+In our example, when you did the test merge, the manual
+resolution is recorded, and it will be reused when you do the
+actual merge later with updated master and topic branch, as long
+as the earlier resolution is still applicable.
+
+The information `git-rerere` records is also used when running
+`git-rebase`.  After blowing away the test merge and continuing
+development on the topic branch:
+
+------------
+              o---*---o-------o---o topic
+             /
+    o---o---o---*---o---o---o---o   master
+
+	$ git rebase master topic
+
+				  o---*---o-------o---o topic
+				 /
+    o---o---o---*---o---o---o---o   master
+------------
+
+you could run `git rebase master topic`, to keep yourself
+up-to-date even before your topic is ready to be sent upstream.
+This would result in falling back to three-way merge, and it
+would conflict the same way the test merge you resolved earlier.
+`git-rerere` is run by `git rebase` to help you resolve this
+conflict.
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+GIT
+---
+Part of the gitlink:git[7] suite

Documentation/git-reset.txt

@@ -3,7 +3,7 @@ git-reset(1)
 
 NAME
 ----
-git-reset - Reset current HEAD to the specified state.
+git-reset - Reset current HEAD to the specified state
 
 SYNOPSIS
 --------
@@ -24,7 +24,7 @@ gitlink:git-revert[1] is your friend.
 OPTIONS
 -------
 --mixed::
-	Resets the index but not the working tree (ie, the changed files
+	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.
 
@@ -43,16 +43,17 @@ OPTIONS
 	Commit to make the current HEAD.
 
 Examples
-~~~~~~~~
+--------
 
 Undo a commit and redo::
 +
 ------------
 $ git commit ...
-$ git reset --soft HEAD^ <1>
+$ git reset --soft HEAD^      <1>
-$ edit <2>
+$ edit                        <2>
-$ git commit -a -c ORIG_HEAD <3>
+$ 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".
@@ -60,43 +61,43 @@ message, or both.  Leaves working tree as it was before "reset".
 <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.
-------------
 
 Undo commits permanently::
 +
 ------------
 $ git commit ...
-$ git reset --hard HEAD~3 <1>
+$ 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.
-------------
 
 Undo a commit, making it a topic branch::
 +
 ------------
-$ git branch topic/wip <1>
+$ git branch topic/wip     <1>
-$ git reset --hard HEAD~3 <2>
+$ git reset --hard HEAD~3  <2>
-$ git checkout topic/wip <3>
+$ 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 update-index::
 +
 ------------
-$ edit <1>
+$ edit                                     <1>
 $ git-update-index frotz.c filfre.c
-$ mailx <2>
+$ mailx                                    <2>
-$ git reset <3>
+$ git reset                                <3>
-$ git pull git://info.example.com/ nitfol <4>
+$ git pull git://info.example.com/ nitfol  <4>
-
+------------
++
 <1> you are happily working on something, and find the changes
 in these files are in good order.  You do not want to see them
 when you run "git diff", because you plan to work on other files
@@ -109,12 +110,11 @@ index changes for these two files.  Your changes in working tree
 remain there.
 <4> then you can pull and merge, leaving frotz.c and filfre.c
 changes still in the working tree.
-------------
 
 Undo a merge or pull::
 +
 ------------
-$ git pull <1>
+$ git pull                         <1>
 Trying really trivial in-index merge...
 fatal: Merge requires file-level merging
 Nope.
@@ -122,20 +122,19 @@ Nope.
 Auto-merging nitfol
 CONFLICT (content): Merge conflict in nitfol
 Automatic merge failed/prevented; fix up by hand
-$ git reset --hard <2>
+$ git reset --hard                 <2>
-
+$ git pull . topic/branch          <3>
+Updating from 41223... to 13134...
+Fast forward
+$ git reset --hard ORIG_HEAD       <4>
+------------
++
 <1> try to update from the upstream resulted in a lot of
 conflicts; you were not ready to spend a lot of time merging
 right now, so you decide to do that later.
 <2> "pull" has not made merge commit, so "git reset --hard"
 which is a synonym for "git reset --hard HEAD" clears the mess
 from the index file and the working tree.
-
-$ git pull . topic/branch <3>
-Updating from 41223... to 13134...
-Fast forward
-$ git reset --hard ORIG_HEAD <4>
-
 <3> merge a topic branch into the current branch, which resulted
 in a fast forward.
 <4> but you decided that the topic branch is not ready for public
@@ -143,33 +142,32 @@ consumption yet.  "pull" or "merge" always leaves the original
 tip of the current branch in ORIG_HEAD, so resetting hard to it
 brings your index file and the working tree back to that state,
 and resets the tip of the branch to that commit.
-------------
 
 Interrupted workflow::
 +
-You can get interrupted by an ungent fix request while you are
+Suppose you are interrupted by an urgent fix request while you
-still in the middle of a large change.  The files in your
+are in the middle of a large change.  The files in your
 working tree are not in any shape to be committed yet, but you
 need to get to the other branch for a quick bugfix.
 +
 ------------
 $ git checkout feature ;# you were working in "feature" branch and
 $ work work work       ;# got interrupted
-$ git commit -a -m 'snapshot WIP' <1>
+$ git commit -a -m 'snapshot WIP'                 <1>
 $ git checkout master
 $ fix fix fix
 $ git commit ;# commit with real log
 $ git checkout feature
-$ git reset --soft HEAD^ ;# go back to WIP state <2>
+$ git reset --soft HEAD^ ;# go back to WIP state  <2>
-$ git reset <3>
+$ git reset                                       <3>
-
-<1> This commit will get blown away so a throw-away log message is OK.
-<2> This removes the 'WIP' commit from the commit history, and makes
-    your working tree in the state just before you made that snapshot.
-<3> After <2>, the index file still has all the WIP changes you
-    committed in <1>.  This sets it to the last commit you were
-    basing the WIP changes on.
 ------------
++
+<1> This commit will get blown away so a throw-away log message is OK.
+<2> This removes the 'WIP' commit from the commit history, and sets
+    your working tree to the state just before you made that snapshot.
+<3> At this point the index file still has all the WIP changes you
+    committed as 'snapshot WIP'.  This updates the index to show your
+    WIP files as uncommitted.
 
 Author
 ------

Documentation/git-rev-list.txt

@@ -14,10 +14,12 @@ SYNOPSIS
 	     [ \--min-age=timestamp ]
 	     [ \--sparse ]
 	     [ \--no-merges ]
+	     [ \--remove-empty ]
+	     [ \--not ]
 	     [ \--all ]
-	     [ [ \--merge-order [ \--show-breaks ] ] | [ \--topo-order ] ]
+	     [ \--topo-order ]
 	     [ \--parents ]
-	     [ \--objects [ \--unpacked ] ]
+	     [ [\--objects | \--objects-edge] [ \--unpacked ] ]
 	     [ \--pretty | \--header ]
 	     [ \--bisect ]
 	     <commit>... [ \-- <paths>... ]
@@ -36,6 +38,14 @@ not in 'baz'".
 A special notation <commit1>..<commit2> can be used as a
 short-hand for {caret}<commit1> <commit2>.
 
+Another special notation is <commit1>...<commit2> which is useful for
+merges.  The resulting set of commits is the symmetric difference
+between the two operands.  The following two commands are equivalent:
+
+------------
+$ git-rev-list A B --not $(git-merge-base --all A B)
+$ git-rev-list A...B
+------------
 
 OPTIONS
 -------
@@ -46,12 +56,23 @@ OPTIONS
 	Print the contents of the commit in raw-format; each
 	record is separated with a NUL character.
 
+--parents::
+	Print the parents of the commit.
+
 --objects::
 	Print the object IDs of any object referenced by the listed commits.
 	'git-rev-list --objects foo ^bar' thus means "send me all object IDs
 	which I need to download if I have the commit object 'bar', but
 	not 'foo'".
 
+--objects-edge::
+	Similar to `--objects`, but also print the IDs of
+	excluded commits prefixed with a `-` character.  This is
+	used by `git-pack-objects` to build 'thin' pack, which
+	records objects in deltified form based on objects
+	contained in these excluded commits to reduce network
+	traffic.
+
 --unpacked::
 	Only useful with `--objects`; print the object IDs that
 	are not in packs.
@@ -59,9 +80,10 @@ OPTIONS
 --bisect::
 	Limit output to the one commit object which is roughly halfway
 	between the included and excluded commits. Thus, if 'git-rev-list
-	--bisect foo ^bar ^baz' outputs 'midpoint', the output
+	--bisect foo {caret}bar {caret}baz' outputs 'midpoint', the output
-	of 'git-rev-list foo ^midpoint' and 'git-rev-list midpoint
+	of 'git-rev-list foo {caret}midpoint' and 'git-rev-list midpoint
-	^bar ^baz' would be of roughly the same length. Finding the change
+	{caret}bar {caret}baz' would be of roughly the same length.
+	Finding the change
 	which introduces a regression is thus reduced to a binary search:
 	repeatedly generate and test new 'midpoint's until the commit chain
 	is of length one.
@@ -80,6 +102,17 @@ OPTIONS
 	(still subject to count and age limitation), but apply
 	merge simplification nevertheless.
 
+--remove-empty::
+	Stop when a given path disappears from the tree.
+
+--no-merges::
+	Do not print commits with more than one parent.
+
+--not::
+	Reverses the meaning of the '{caret}' prefix (or lack
+	thereof) for all following revision specifiers, up to
+	the next `--not`.
+
 --all::
 	Pretend as if all the refs in `$GIT_DIR/refs/` are
 	listed on the command line as <commit>.
@@ -90,57 +123,10 @@ OPTIONS
 	topological order (i.e. descendant commits are shown
 	before their parents).
 
---merge-order::
-	When specified the commit history is decomposed into a unique
-	sequence of minimal, non-linear epochs and maximal, linear epochs.
-	Non-linear epochs are then linearised by sorting them into merge
-	order, which is described below.
-+
-Maximal, linear epochs correspond to periods of sequential development.
-Minimal, non-linear epochs correspond to periods of divergent development
-followed by a converging merge. The theory of epochs is described in more
-detail at
-link:http://blackcubes.dyndns.org/epoch/[http://blackcubes.dyndns.org/epoch/].
-+
-The merge order for a non-linear epoch is defined as a linearisation for which
-the following invariants are true:
-+
-    1. if a commit P is reachable from commit N, commit P sorts after commit N
-       in the linearised list.
-    2. if Pi and Pj are any two parents of a merge M (with i < j), then any
-       commit N, such that N is reachable from Pj but not reachable from Pi,
-       sorts before all commits reachable from Pi.
-+
-Invariant 1 states that later commits appear before earlier commits they are
-derived from.
-+
-Invariant 2 states that commits unique to "later" parents in a merge, appear
-before all commits from "earlier" parents of a merge.
-
---show-breaks::
-	Each item of the list is output with a 2-character prefix consisting
-	of one of: (|), (^), (=) followed by a space.
-+
-Commits marked with (=) represent the boundaries of minimal, non-linear epochs
-and correspond either to the start of a period of divergent development or to
-the end of such a period.
-+
-Commits marked with (|) are direct parents of commits immediately preceding
-the marked commit in the list.
-+
-Commits marked with (^) are not parents of the immediately preceding commit.
-These "breaks" represent necessary discontinuities implied by trying to
-represent an arbitrary DAG in a linear form.
-+
-`--show-breaks` is only valid if `--merge-order` is also specified.
-
-
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org>
 
-Original *--merge-order* logic by Jon Seymour <jon.seymour@gmail.com>
-
 Documentation
 --------------
 Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.

Documentation/git-rev-parse.txt

@@ -3,7 +3,7 @@ git-rev-parse(1)
 
 NAME
 ----
-git-rev-parse - Pick out and massage parameters.
+git-rev-parse - Pick out and massage parameters
 
 
 SYNOPSIS
@@ -13,7 +13,7 @@ SYNOPSIS
 DESCRIPTION
 -----------
 
-Many git Porcelainish commands take mixture of flags
+Many git porcelainish commands take mixture of flags
 (i.e. parameters that begin with a dash '-') and parameters
 meant for underlying `git-rev-list` command they use internally
 and flags and parameters for other commands they use as the
@@ -67,11 +67,33 @@ OPTIONS
 --all::
 	Show all refs found in `$GIT_DIR/refs`.
 
+--branches::
+	Show branch refs found in `$GIT_DIR/refs/heads`.
+
+--tags::
+	Show tag refs found in `$GIT_DIR/refs/tags`.
+
+--remotes::
+	Show tag refs found in `$GIT_DIR/refs/remotes`.
+
 --show-prefix::
-	When the command is invoked from a directory show the
+	When the command is invoked from a subdirectory, show the
 	path of the current directory relative to the top-level
 	directory.
 
+--show-cdup::
+	When the command is invoked from a subdirectory, show the
+	path of the top-level directory relative to the current
+	directory (typically a sequence of "../", or an empty string).
+
+--git-dir::
+	Show `$GIT_DIR` if defined else show the path to the .git directory.
+
+--short, --short=number::
+	Instead of outputting the full SHA1 values of object names try to
+	abbreviate them to a shorter unique name. When no length is specified
+	7 is used. The minimum length is 4.
+
 --since=datestring, --after=datestring::
 	Parses the date string, and outputs corresponding
 	--max-age= parameter for git-rev-list command.
@@ -102,6 +124,13 @@ syntax.
   happen to have both heads/master and tags/master, you can
   explicitly say 'heads/master' to tell git which one you mean.
 
+* A suffix '@' followed by 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>).
+
 * 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}'
@@ -127,11 +156,6 @@ syntax.
   and dereference the tag recursively until a non-tag object is
   found.
 
-'git-rev-parse' also accepts a prefix '{caret}' to revision parameter,
-which is passed to 'git-rev-list'.  Two revision parameters
-concatenated with '..' is a short-hand for writing a range
-between them.  I.e. 'r1..r2' is equivalent to saying '{caret}r1 r2'
-
 Here is an illustration, by Jon Loeliger.  Both node B and C are
 a commit parents of commit node A.  Parent commits are ordered
 left-to-right.
@@ -139,9 +163,9 @@ left-to-right.
     G   H   I   J
      \ /     \ /
       D   E   F
-       \  |  /
+       \  |  / \
-        \ | /
+        \ | /   |
-         \|/
+         \|/    |
           B     C
            \   /
             \ /
@@ -159,6 +183,40 @@ left-to-right.
     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.  "`r1..r2`" is equivalent to "`{caret}r1 r2`".  It is
+the difference of two sets (subtract the set of commits
+reachable from `r1` from the set of commits reachable from
+`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 it the set of commits that are reachable from either one of
+`r1` or `r2` but not from both.
+
+Here are a few examples:
+
+   D                A B D
+   D F              A B C D F
+   ^A G		    B D
+   ^A F             B C F
+   G...I            C D F G I
+   ^B G I	    C D F G I
+
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org> and

Documentation/git-revert.txt

@@ -3,7 +3,7 @@ git-revert(1)
 
 NAME
 ----
-git-revert - Revert an existing commit.
+git-revert - Revert an existing commit
 
 SYNOPSIS
 --------

Documentation/git-rm.txt

@@ -0,0 +1,92 @@
+git-rm(1)
+=========
+
+NAME
+----
+git-rm - Remove files from the working tree and from the index
+
+SYNOPSIS
+--------
+'git-rm' [-f] [-n] [-v] [--] <file>...
+
+DESCRIPTION
+-----------
+A convenience wrapper for git-update-index --remove. For those coming
+from cvs, git-rm provides an operation similar to "cvs rm" or "cvs
+remove".
+
+
+OPTIONS
+-------
+<file>...::
+	Files to remove from the index and optionally, from the
+	working tree as well.
+
+-f::
+	Remove files from the working tree as well as from the index.
+
+-n::
+        Don't actually remove the file(s), just show if they exist in
+        the index.
+
+-v::
+        Be verbose.
+
+\--::
+	This option can be used to separate command-line options from
+	the list of files, (useful when filenames might be mistaken
+	for command-line options).
+
+
+DISCUSSION
+----------
+
+The list of <file> given to the command is fed to `git-ls-files`
+command to list files that are registered in the index and
+are not ignored/excluded by `$GIT_DIR/info/exclude` file or
+`.gitignore` file in each directory.  This means two things:
+
+. You can put the name of a directory on the command line, and the
+  command will remove all files in it and its subdirectories (the
+  directories themselves are never removed from the working tree);
+
+. Giving the name of a file that is not in the index does not
+  remove that file.
+
+
+EXAMPLES
+--------
+git-rm Documentation/\\*.txt::
+
+	Removes all `\*.txt` files from the index that are under the
+	`Documentation` directory and any of its subdirectories. The
+	files are not removed from the working tree.
++
+Note that the asterisk `\*` is quoted from the shell in this
+example; this lets the command include the files from
+subdirectories of `Documentation/` directory.
+
+git-rm -f git-*.sh::
+
+	Remove all git-*.sh scripts that are in the index. The files
+	are removed from the index, and (because of the -f option),
+	from the working tree as well. Because this example lets the
+	shell expand the asterisk (i.e. you are listing the files
+	explicitly), it does not remove `subdir/git-foo.sh`.
+
+See Also
+--------
+gitlink:git-add[1]
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+

Documentation/git-send-email.txt

@@ -24,31 +24,15 @@ OPTIONS
 -------
 The options available are:
 
---to::
+--bcc::
-	Specify the primary recipient of the emails generated.
+	Specify a "Bcc:" value for each email.
-	Generally, this will be the upstream maintainer of the
-	project involved.
 
---from::
+	The --bcc option must be repeated for each user you want on the bcc list.
-	Specify the sender of the emails.  This will default to
-	the value GIT_COMMITTER_IDENT, as returned by "git-var -l".
-	The user will still be prompted to confirm this entry.
 
---compose::
+--cc::
-	Use \$EDITOR to edit an introductory message for the
+	Specify a starting "Cc:" value for each email.
-	patch series.
 
---subject::
+	The --cc option must be repeated for each user you want on the cc list.
-   	Specify the initial subject of the email thread.
-	Only necessary if --compose is also set.  If --compose
-	is not set, this will be prompted for.
-
---in-reply-to::
-	Specify the contents of the first In-Reply-To header.
-	Subsequent emails will refer to the previous email 
-	instead of this if --chain-reply-to is set (the default)
-	Only necessary if --compose is also set.  If --compose
-	is not set, this will be prompted for.
 
 --chain-reply-to, --no-chain-reply-to::
 	If this is set, each email will be sent as a reply to the previous
@@ -58,10 +42,49 @@ The options available are:
 	entire patch series.
 	Default is --chain-reply-to
 
+--compose::
+	Use $EDITOR to edit an introductory message for the
+	patch series.
+
+--from::
+	Specify the sender of the emails.  This will default to
+	the value GIT_COMMITTER_IDENT, as returned by "git-var -l".
+	The user will still be prompted to confirm this entry.
+
+--in-reply-to::
+	Specify the contents of the first In-Reply-To header.
+	Subsequent emails will refer to the previous email 
+	instead of this if --chain-reply-to is set (the default)
+	Only necessary if --compose is also set.  If --compose
+	is not set, this will be prompted for.
+
+--no-signed-off-by-cc::
+	Do not add emails found in Signed-off-by: lines to the cc list.
+
+--quiet::
+	Make git-send-email less verbose.  One line per email should be
+	all that is output.
+
 --smtp-server::
 	If set, specifies the outgoing SMTP server to use.  Defaults to
 	localhost.
 
+--subject::
+   	Specify the initial subject of the email thread.
+	Only necessary if --compose is also set.  If --compose
+	is not set, this will be prompted for.
+
+--suppress-from::
+	Do not add the From: address to the cc: list, if it shows up in a From:
+	line.
+
+--to::
+	Specify the primary recipient of the emails generated.
+	Generally, this will be the upstream maintainer of the
+	project involved.
+
+	The --to option must be repeated for each user you want on the to list.
+
 
 Author
 ------

Documentation/git-send-pack.txt

@@ -3,7 +3,7 @@ git-send-pack(1)
 
 NAME
 ----
-git-send-pack - Push missing objects packed.
+git-send-pack - Push missing objects packed
 
 
 SYNOPSIS
@@ -53,7 +53,7 @@ Specifying the Refs
 There are three ways to specify which refs to update on the
 remote end.
 
-With '--all' flag, all refs that exist locally are transfered to
+With '--all' flag, all refs that exist locally are transferred to
 the remote side.  You cannot specify any '<ref>' if you use
 this flag.
 

Documentation/git-sh-setup.txt

@@ -3,7 +3,7 @@ git-sh-setup(1)
 
 NAME
 ----
-git-sh-setup - Common git shell script setup code.
+git-sh-setup - Common git shell script setup code
 
 SYNOPSIS
 --------
@@ -13,7 +13,7 @@ DESCRIPTION
 -----------
 
 Sets up the normal git environment variables and a few helper functions
-(currently just "die()"), and returns ok if it all looks like a git archive.
+(currently just "die()"), and returns OK if it all looks like a git archive.
 So, to make the rest of the git scripts more careful and readable,
 use it as follows:
 

Documentation/git-shell.txt

@@ -8,7 +8,7 @@ git-shell - Restricted login shell for GIT over SSH only
 
 SYNOPSIS
 --------
-'git-shell -c <command> <argument>'
+'git-shell' -c <command> <argument>
 
 DESCRIPTION
 -----------

Documentation/git-shortlog.txt

@@ -3,18 +3,31 @@ git-shortlog(1)
 
 NAME
 ----
-git-shortlog - Summarize 'git log' output.
+git-shortlog - Summarize 'git log' output
-
 
 SYNOPSIS
 --------
-'git-log --pretty=short | git shortlog'
+git-log --pretty=short | 'git-shortlog'
 
 DESCRIPTION
 -----------
 Summarizes 'git log' output in a format suitable for inclusion
-in release announcements.
+in release announcements. Each commit will be grouped by author
+the first line of the commit message will be shown.
 
+Additionally, "[PATCH]" will be stripped from the commit description.
+
+FILES
+-----
+'.mailmap'::
+	If this file exists, it will be used for mapping author email
+	addresses to a real author name. One mapping per line, first
+	the author name followed by the email address enclosed by
+	'<' and '>'. Use hash '#' for comments. Example:
+
+		# Keep alphabetized
+		Adam Morrow <adam@localhost.localdomain>
+		Eve Jones <eve@laptop.(none)>
 
 Author
 ------

Documentation/git-show-branch.txt

@@ -3,11 +3,14 @@ git-show-branch(1)
 
 NAME
 ----
-git-show-branch - Show branches and their commits.
+git-show-branch - Show branches and their commits
 
 SYNOPSIS
 --------
-'git-show-branch [--all] [--heads] [--tags] [--topo-order] [--more=<n> | --list | --independent | --merge-base] [--no-name | --sha1-name] [<rev> | <glob>]...'
+[verse]
+'git-show-branch' [--all] [--heads] [--tags] [--topo-order] [--current]
+		[--more=<n> | --list | --independent | --merge-base]
+		[--no-name | --sha1-name] [<rev> | <glob>]...
 
 DESCRIPTION
 -----------
@@ -18,6 +21,9 @@ and/or $GIT_DIR/refs/tags) semi-visually.
 
 It cannot show more than 29 branches and commits at a time.
 
+It uses `showbranch.default` multi-valued configuration items if
+no <rev> nor <glob> is given on the command line.
+
 
 OPTIONS
 -------
@@ -35,12 +41,22 @@ OPTIONS
 	Show all refs under $GIT_DIR/refs, $GIT_DIR/refs/heads,
 	and $GIT_DIR/refs/tags, respectively.
 
+--current::
+	With this option, the command includes the current
+	branch to the list of revs to be shown when it is not
+	given on the command line.
+
 --topo-order::
         By default, the branches and their commits are shown in
         reverse chronological order.  This option makes them
         appear in topological order (i.e., descendant commits
         are shown before their parents).
 
+--sparse::
+	By default, the output omits merges that are reachable
+	from only one tip being shown.  This option makes them
+	visible.
+
 --more=<n>::
 	Usually the command stops output upon showing the commit
 	that is the common ancestor of all the branches.  This
@@ -50,7 +66,7 @@ OPTIONS
 	tree.
 
 --list::
-	Synomym to `--more=-1`
+	Synonym to `--more=-1`
 
 --merge-base::
 	Instead of showing the commit list, just act like the
@@ -78,13 +94,14 @@ OUTPUT
 ------
 Given N <references>, the first N lines are the one-line
 description from their commit message.  The branch head that is
-pointed at by $GIT_DIR/HEAD is prefixed with an asterisk '*'
+pointed at by $GIT_DIR/HEAD is prefixed with an asterisk `*`
-character while other heads are prefixed with a '!' character.
+character while other heads are prefixed with a `!` character.
 
 Following these N lines, one-line log for each commit is
 displayed, indented N places.  If a commit is on the I-th
-branch, the I-th indentation character shows a '+' sign;
+branch, the I-th indentation character shows a `+` sign;
-otherwise it shows a space.  Each commit shows a short name that
+otherwise it shows a space.  Merge commits are denoted by
+a `-` sign.  Each commit shows a short name that
 can be used as an extended SHA1 to name that commit.
 
 The following example shows three branches, "master", "fixes"
@@ -92,7 +109,7 @@ and "mhf":
 
 ------------------------------------------------
 $ git show-branch master fixes mhf
-! [master] Add 'git show-branch'.
+* [master] Add 'git show-branch'.
  ! [fixes] Introduce "reset type" flag to "git reset"
   ! [mhf] Allow "+remote:local" refspec to cause --force when fetching.
 ---
@@ -106,13 +123,33 @@ $ git show-branch master fixes mhf
   + [mhf~6] Retire git-parse-remote.
   + [mhf~7] Multi-head fetch.
   + [mhf~8] Start adding the $GIT_DIR/remotes/ support.
-+++ [master] Add 'git show-branch'.
+*++ [master] Add 'git show-branch'.
 ------------------------------------------------
 
 These three branches all forked from a common commit, [master],
 whose commit message is "Add 'git show-branch'.  "fixes" branch
 adds one commit 'Introduce "reset type"'.  "mhf" branch has many
-other commits.
+other commits.  The current branch is "master".
+
+
+EXAMPLE
+-------
+
+If you keep your primary branches immediately under
+`$GIT_DIR/refs/heads`, and topic branches in subdirectories of
+it, having the following in the configuration file may help:
+
+------------
+[showbranch]
+	default = --topo-order
+	default = heads/*
+
+------------
+
+With this, `git show-branch` without extra parameters would show
+only the primary branches.  In addition, if you happen to be on
+your topic branch, it is shown as well.
+
 
 
 Author

Documentation/git-show.txt

@@ -0,0 +1,49 @@
+git-show(1)
+===========
+
+NAME
+----
+git-show - Show one commit with difference it introduces
+
+
+SYNOPSIS
+--------
+'git-show' <option>...
+
+DESCRIPTION
+-----------
+Shows commit log and textual diff for a single commit.  The
+command internally invokes 'git-rev-list' piped to
+'git-diff-tree', and takes command line options for both of
+these commands. It also presents the merge commit in a special
+format as produced by 'git-diff-tree --cc'.
+
+This manual page describes only the most frequently used options.
+
+
+OPTIONS
+-------
+<commitid>::
+	ID of the commit to show.
+
+--pretty=<format>::
+	Controls the output format for the commit logs.
+	<format> can be one of 'raw', 'medium', 'short', 'full',
+	and 'oneline'.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>
+
+
+Documentation
+-------------
+Documentation by David Greaves, Petr Baudis and the git-list <git@vger.kernel.org>.
+
+This manual page is a stub. You can help the git documentation by expanding it.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+

Documentation/git-status.txt

@@ -3,7 +3,7 @@ git-status(1)
 
 NAME
 ----
-git-status - Show working tree status.
+git-status - Show working tree status
 
 
 SYNOPSIS

Documentation/git-stripspace.txt

@@ -3,7 +3,7 @@ git-stripspace(1)
 
 NAME
 ----
-git-stripspace - Filter out empty lines.
+git-stripspace - Filter out empty lines
 
 
 SYNOPSIS

Documentation/git-svn.txt

@@ -0,0 +1,319 @@
+git-svn(1)
+==========
+
+NAME
+----
+git-svn - bidirectional operation between a single Subversion branch and git
+
+SYNOPSIS
+--------
+'git-svn' <command> [options] [arguments]
+
+DESCRIPTION
+-----------
+git-svn is a simple conduit for changesets between a single Subversion
+branch and git.
+
+git-svn is not to be confused with git-svnimport.  The were designed
+with very different goals in mind.
+
+git-svn is designed for an individual developer who wants a
+bidirectional flow of changesets between a single branch in Subversion
+and an arbitrary number of branches in git.  git-svnimport is designed
+for read-only operation on repositories that match a particular layout
+(albeit the recommended one by SVN developers).
+
+For importing svn, git-svnimport is potentially more powerful when
+operating on repositories organized under the recommended
+trunk/branch/tags structure, and should be faster, too.
+
+git-svn mostly ignores the very limited view of branching that
+Subversion has.  This allows git-svn to be much easier to use,
+especially on repositories that are not organized in a manner that
+git-svnimport is designed for.
+
+COMMANDS
+--------
+init::
+	Creates an empty git repository with additional metadata
+	directories for git-svn.  The Subversion URL must be specified
+	as a command-line argument.
+
+fetch::
+	Fetch unfetched revisions from the Subversion URL we are
+	tracking.  refs/remotes/git-svn will be updated to the
+	latest revision.
+
+	Note: You should never attempt to modify the remotes/git-svn
+	branch outside of git-svn.  Instead, create a branch from
+	remotes/git-svn and work on that branch.  Use the 'commit'
+	command (see below) to write git commits back to
+	remotes/git-svn.
+
+	See 'Additional Fetch Arguments' if you are interested in
+	manually joining branches on commit.
+
+commit::
+	Commit specified commit or tree objects to SVN.  This relies on
+	your imported fetch data being up-to-date.  This makes
+	absolutely no attempts to do patching when committing to SVN, it
+	simply overwrites files with those specified in the tree or
+	commit.  All merging is assumed to have taken place
+	independently of git-svn functions.
+
+rebuild::
+	Not a part of daily usage, but this is a useful command if
+	you've just cloned a repository (using git-clone) that was
+	tracked with git-svn.  Unfortunately, git-clone does not clone
+	git-svn metadata and the svn working tree that git-svn uses for
+	its operations.  This rebuilds the metadata so git-svn can
+	resume fetch operations.  A Subversion URL may be optionally
+	specified at the command-line if the directory/repository you're
+	tracking has moved or changed protocols.
+
+show-ignore::
+	Recursively finds and lists the svn:ignore property on
+	directories.  The output is suitable for appending to
+	the $GIT_DIR/info/exclude file.
+
+OPTIONS
+-------
+-r <ARG>::
+--revision <ARG>::
+	Only used with the 'fetch' command.
+
+	Takes any valid -r<argument> svn would accept and passes it
+	directly to svn. -r<ARG1>:<ARG2> ranges and "{" DATE "}" syntax
+	is also supported.  This is passed directly to svn, see svn
+	documentation for more details.
+
+	This can allow you to make partial mirrors when running fetch.
+
+-::
+--stdin::
+	Only used with the 'commit' command.
+
+	Read a list of commits from stdin and commit them in reverse
+	order.  Only the leading sha1 is read from each line, so
+	git-rev-list --pretty=oneline output can be used.
+
+--rmdir::
+	Only used with the 'commit' command.
+
+	Remove directories from the SVN tree if there are no files left
+	behind.  SVN can version empty directories, and they are not
+	removed by default if there are no files left in them.  git
+	cannot version empty directories.  Enabling this flag will make
+	the commit to SVN act like git.
+
+	repo-config key: svn.rmdir
+
+-e::
+--edit::
+	Only used with the 'commit' command.
+
+	Edit the commit message before committing to SVN.  This is off by
+	default for objects that are commits, and forced on when committing
+	tree objects.
+
+	repo-config key: svn.edit
+
+-l<num>::
+--find-copies-harder::
+	Both of these are only used with the 'commit' command.
+
+	They are both passed directly to git-diff-tree see
+	git-diff-tree(1) for more information.
+
+	repo-config key: svn.l
+	repo-config key: svn.findcopiesharder
+
+-A<filename>::
+--authors-file=<filename>::
+
+	Syntax is compatible with the files used by git-svnimport and
+	git-cvsimport:
+
+------------------------------------------------------------------------
+loginname = Joe User <user@example.com>
+------------------------------------------------------------------------
+
+	If this option is specified and git-svn encounters an SVN
+	committer name that does not exist in the authors-file, git-svn
+	will abort operation. The user will then have to add the
+	appropriate entry.  Re-running the previous git-svn command
+	after the authors-file is modified should continue operation.
+
+	repo-config key: svn.authors-file
+
+ADVANCED OPTIONS
+----------------
+-b<refname>::
+--branch <refname>::
+	Used with 'fetch' or 'commit'.
+
+	This can be used to join arbitrary git branches to remotes/git-svn
+	on new commits where the tree object is equivalent.
+
+	When used with different GIT_SVN_ID values, tags and branches in
+	SVN can be tracked this way, as can some merges where the heads
+	end up having completely equivalent content.  This can even be
+	used to track branches across multiple SVN _repositories_.
+
+	This option may be specified multiple times, once for each
+	branch.
+
+	repo-config key: svn.branch
+
+-i<GIT_SVN_ID>::
+--id <GIT_SVN_ID>::
+	This sets GIT_SVN_ID (instead of using the environment).  See
+	the section on "Tracking Multiple Repositories or Branches" for
+	more information on using GIT_SVN_ID.
+
+COMPATIBILITY OPTIONS
+---------------------
+--upgrade::
+	Only used with the 'rebuild' command.
+
+	Run this if you used an old version of git-svn that used
+	"git-svn-HEAD" instead of "remotes/git-svn" as the branch
+	for tracking the remote.
+
+--no-ignore-externals::
+	Only used with the 'fetch' and 'rebuild' command.
+
+	By default, git-svn passes --ignore-externals to svn to avoid
+	fetching svn:external trees into git.  Pass this flag to enable
+	externals tracking directly via git.
+
+	Versions of svn that do not support --ignore-externals are
+	automatically detected and this flag will be automatically
+	enabled for them.
+
+	Otherwise, do not enable this flag unless you know what you're
+	doing.
+
+	repo-config key: svn.noignoreexternals
+
+Basic Examples
+~~~~~~~~~~~~~~
+
+Tracking and contributing to an Subversion managed-project:
+
+------------------------------------------------------------------------
+# Initialize a tree (like git init-db):
+	git-svn init http://svn.foo.org/project/trunk
+# Fetch remote revisions:
+	git-svn fetch
+# Create your own branch to hack on:
+	git checkout -b my-branch remotes/git-svn
+# Commit only the git commits you want to SVN:
+	git-svn commit <tree-ish> [<tree-ish_2> ...]
+# Commit all the git commits from my-branch that don't exist in SVN:
+	git-svn commit remotes/git-svn..my-branch
+# Something is committed to SVN, pull the latest into your branch:
+	git-svn fetch && git pull . remotes/git-svn
+# Append svn:ignore settings to the default git exclude file:
+	git-svn show-ignore >> .git/info/exclude
+------------------------------------------------------------------------
+
+DESIGN PHILOSOPHY
+-----------------
+Merge tracking in Subversion is lacking and doing branched development
+with Subversion is cumbersome as a result.  git-svn completely forgoes
+any automated merge/branch tracking on the Subversion side and leaves it
+entirely up to the user on the git side.  It's simply not worth it to do
+a useful translation when the original signal is weak.
+
+TRACKING MULTIPLE REPOSITORIES OR BRANCHES
+------------------------------------------
+This is for advanced users, most users should ignore this section.
+
+Because git-svn does not care about relationships between different
+branches or directories in a Subversion repository, git-svn has a simple
+hack to allow it to track an arbitrary number of related _or_ unrelated
+SVN repositories via one git repository.  Simply set the GIT_SVN_ID
+environment variable to a name other other than "git-svn" (the default)
+and git-svn will ignore the contents of the $GIT_DIR/git-svn directory
+and instead do all of its work in $GIT_DIR/$GIT_SVN_ID for that
+invocation.  The interface branch will be remotes/$GIT_SVN_ID, instead of
+remotes/git-svn.  Any remotes/$GIT_SVN_ID branch should never be modified
+by the user outside of git-svn commands.
+
+ADDITIONAL FETCH ARGUMENTS
+--------------------------
+This is for advanced users, most users should ignore this section.
+
+Unfetched SVN revisions may be imported as children of existing commits
+by specifying additional arguments to 'fetch'.  Additional parents may
+optionally be specified in the form of sha1 hex sums at the
+command-line.  Unfetched SVN revisions may also be tied to particular
+git commits with the following syntax:
+
+	svn_revision_number=git_commit_sha1
+
+This allows you to tie unfetched SVN revision 375 to your current HEAD::
+
+	`git-svn fetch 375=$(git-rev-parse HEAD)`
+
+Advanced Example: Tracking a Reorganized Repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+If you're tracking a directory that has moved, or otherwise been
+branched or tagged off of another directory in the repository and you
+care about the full history of the project, then you can read this
+section.
+
+This is how Yann Dirson tracked the trunk of the ufoai directory when
+the /trunk directory of his repository was moved to /ufoai/trunk and
+he needed to continue tracking /ufoai/trunk where /trunk left off.
+
+------------------------------------------------------------------------
+	# This log message shows when the repository was reorganized:
+	r166 | ydirson | 2006-03-02 01:36:55 +0100 (Thu, 02 Mar 2006) | 1 line
+	Changed paths:
+	   D /trunk
+	   A /ufoai/trunk (from /trunk:165)
+
+	# First we start tracking the old revisions:
+	GIT_SVN_ID=git-oldsvn git-svn init \
+			https://svn.sourceforge.net/svnroot/ufoai/trunk
+	GIT_SVN_ID=git-oldsvn git-svn fetch -r1:165
+
+	# And now, we continue tracking the new revisions:
+	GIT_SVN_ID=git-newsvn git-svn init \
+	      https://svn.sourceforge.net/svnroot/ufoai/ufoai/trunk
+	GIT_SVN_ID=git-newsvn git-svn fetch \
+	      166=`git-rev-parse refs/remotes/git-oldsvn`
+------------------------------------------------------------------------
+
+BUGS
+----
+If somebody commits a conflicting changeset to SVN at a bad moment
+(right before you commit) causing a conflict and your commit to fail,
+your svn working tree ($GIT_DIR/git-svn/tree) may be dirtied.  The
+easiest thing to do is probably just to rm -rf $GIT_DIR/git-svn/tree and
+run 'rebuild'.
+
+We ignore all SVN properties except svn:executable.  Too difficult to
+map them since we rely heavily on git write-tree being _exactly_ the
+same on both the SVN and git working trees and I prefer not to clutter
+working trees with metadata files.
+
+svn:keywords can't be ignored in Subversion (at least I don't know of
+a way to ignore them).
+
+Renamed and copied directories are not detected by git and hence not
+tracked when committing to SVN.  I do not plan on adding support for
+this as it's quite difficult and time-consuming to get working for all
+the possible corner cases (git doesn't do it, either).  Renamed and
+copied files are fully supported if they're similar enough for git to
+detect them.
+
+Author
+------
+Written by Eric Wong <normalperson@yhbt.net>.
+
+Documentation
+-------------
+Written by Eric Wong <normalperson@yhbt.net>.