summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/.gitattributes1
-rw-r--r--Documentation/.gitignore8
-rw-r--r--Documentation/CodingGuidelines126
-rw-r--r--Documentation/Makefile225
-rw-r--r--Documentation/RelNotes-1.5.0.1.txt42
-rw-r--r--Documentation/RelNotes-1.5.0.2.txt65
-rw-r--r--Documentation/RelNotes-1.5.0.3.txt58
-rw-r--r--Documentation/RelNotes-1.5.0.4.txt22
-rw-r--r--Documentation/RelNotes-1.5.0.5.txt26
-rw-r--r--Documentation/RelNotes-1.5.0.6.txt21
-rw-r--r--Documentation/RelNotes-1.5.0.7.txt18
-rw-r--r--Documentation/RelNotes-1.5.0.txt469
-rw-r--r--Documentation/RelNotes-1.5.1.1.txt65
-rw-r--r--Documentation/RelNotes-1.5.1.2.txt50
-rw-r--r--Documentation/RelNotes-1.5.1.3.txt45
-rw-r--r--Documentation/RelNotes-1.5.1.4.txt30
-rw-r--r--Documentation/RelNotes-1.5.1.5.txt42
-rw-r--r--Documentation/RelNotes-1.5.1.6.txt45
-rw-r--r--Documentation/RelNotes-1.5.1.txt371
-rw-r--r--Documentation/RelNotes-1.5.2.1.txt53
-rw-r--r--Documentation/RelNotes-1.5.2.2.txt61
-rw-r--r--Documentation/RelNotes-1.5.2.3.txt27
-rw-r--r--Documentation/RelNotes-1.5.2.4.txt28
-rw-r--r--Documentation/RelNotes-1.5.2.5.txt30
-rw-r--r--Documentation/RelNotes-1.5.2.txt197
-rw-r--r--Documentation/RelNotes-1.5.3.1.txt10
-rw-r--r--Documentation/RelNotes-1.5.3.2.txt58
-rw-r--r--Documentation/RelNotes-1.5.3.3.txt31
-rw-r--r--Documentation/RelNotes-1.5.3.4.txt35
-rw-r--r--Documentation/RelNotes-1.5.3.5.txt94
-rw-r--r--Documentation/RelNotes-1.5.3.6.txt48
-rw-r--r--Documentation/RelNotes-1.5.3.7.txt45
-rw-r--r--Documentation/RelNotes-1.5.3.8.txt25
-rw-r--r--Documentation/RelNotes-1.5.3.txt366
-rw-r--r--Documentation/RelNotes-1.5.4.1.txt17
-rw-r--r--Documentation/RelNotes-1.5.4.2.txt43
-rw-r--r--Documentation/RelNotes-1.5.4.3.txt27
-rw-r--r--Documentation/RelNotes-1.5.4.4.txt66
-rw-r--r--Documentation/RelNotes-1.5.4.5.txt56
-rw-r--r--Documentation/RelNotes-1.5.4.txt377
-rw-r--r--Documentation/RelNotes-1.5.5.1.txt44
-rw-r--r--Documentation/RelNotes-1.5.5.2.txt27
-rw-r--r--Documentation/RelNotes-1.5.5.3.txt12
-rw-r--r--Documentation/RelNotes-1.5.5.4.txt7
-rw-r--r--Documentation/RelNotes-1.5.5.txt207
-rw-r--r--Documentation/RelNotes-1.5.6.txt116
-rw-r--r--Documentation/SubmittingPatches453
-rw-r--r--Documentation/asciidoc.conf66
-rw-r--r--Documentation/blame-options.txt89
-rwxr-xr-xDocumentation/build-docdep.perl46
-rw-r--r--Documentation/callouts.xsl30
-rwxr-xr-xDocumentation/cat-texi.perl38
-rwxr-xr-xDocumentation/cmd-list.perl74
-rw-r--r--Documentation/config.txt1089
-rw-r--r--Documentation/diff-format.txt147
-rw-r--r--Documentation/diff-generate-patch.txt161
-rw-r--r--Documentation/diff-options.txt244
-rw-r--r--Documentation/docbook-xsl.css286
-rw-r--r--Documentation/docbook.xsl5
-rw-r--r--Documentation/everyday.txt456
-rw-r--r--Documentation/fetch-options.txt66
-rwxr-xr-xDocumentation/fix-texi.perl15
-rw-r--r--Documentation/git-add.txt272
-rw-r--r--Documentation/git-am.txt164
-rw-r--r--Documentation/git-annotate.txt31
-rw-r--r--Documentation/git-apply.txt212
-rw-r--r--Documentation/git-archimport.txt120
-rw-r--r--Documentation/git-archive.txt123
-rw-r--r--Documentation/git-bisect.txt286
-rw-r--r--Documentation/git-blame.txt197
-rw-r--r--Documentation/git-branch.txt213
-rw-r--r--Documentation/git-bundle.txt174
-rw-r--r--Documentation/git-cat-file.txt107
-rw-r--r--Documentation/git-check-attr.txt41
-rw-r--r--Documentation/git-check-ref-format.txt55
-rw-r--r--Documentation/git-checkout-index.txt189
-rw-r--r--Documentation/git-checkout.txt219
-rw-r--r--Documentation/git-cherry-pick.txt85
-rw-r--r--Documentation/git-cherry.txt75
-rw-r--r--Documentation/git-citool.txt32
-rw-r--r--Documentation/git-clean.txt59
-rw-r--r--Documentation/git-clone.txt208
-rw-r--r--Documentation/git-commit-tree.txt106
-rw-r--r--Documentation/git-commit.txt330
-rw-r--r--Documentation/git-config.txt340
-rw-r--r--Documentation/git-count-objects.txt38
-rw-r--r--Documentation/git-cvsexportcommit.txt120
-rw-r--r--Documentation/git-cvsimport.txt173
-rw-r--r--Documentation/git-cvsserver.txt358
-rw-r--r--Documentation/git-daemon.txt279
-rw-r--r--Documentation/git-describe.txt148
-rw-r--r--Documentation/git-diff-files.txt58
-rw-r--r--Documentation/git-diff-index.txt132
-rw-r--r--Documentation/git-diff-tree.txt168
-rw-r--r--Documentation/git-diff.txt171
-rw-r--r--Documentation/git-fast-export.txt83
-rw-r--r--Documentation/git-fast-import.txt1122
-rw-r--r--Documentation/git-fetch-pack.txt104
-rw-r--r--Documentation/git-fetch.txt56
-rw-r--r--Documentation/git-filter-branch.txt321
-rw-r--r--Documentation/git-fmt-merge-msg.txt72
-rw-r--r--Documentation/git-for-each-ref.txt197
-rw-r--r--Documentation/git-format-patch.txt246
-rw-r--r--Documentation/git-fsck-objects.txt17
-rw-r--r--Documentation/git-fsck.txt154
-rw-r--r--Documentation/git-gc.txt135
-rw-r--r--Documentation/git-get-tar-commit-id.txt36
-rw-r--r--Documentation/git-grep.txt165
-rw-r--r--Documentation/git-gui.txt115
-rw-r--r--Documentation/git-hash-object.txt48
-rw-r--r--Documentation/git-help.txt185
-rw-r--r--Documentation/git-http-fetch.txt56
-rw-r--r--Documentation/git-http-push.txt105
-rw-r--r--Documentation/git-imap-send.txt62
-rw-r--r--Documentation/git-index-pack.txt103
-rw-r--r--Documentation/git-init-db.txt18
-rw-r--r--Documentation/git-init.txt126
-rw-r--r--Documentation/git-instaweb.txt94
-rw-r--r--Documentation/git-log.txt115
-rw-r--r--Documentation/git-lost-found.txt81
-rw-r--r--Documentation/git-ls-files.txt205
-rw-r--r--Documentation/git-ls-remote.txt76
-rw-r--r--Documentation/git-ls-tree.txt94
-rw-r--r--Documentation/git-mailinfo.txt69
-rw-r--r--Documentation/git-mailsplit.txt58
-rw-r--r--Documentation/git-merge-base.txt42
-rw-r--r--Documentation/git-merge-file.txt92
-rw-r--r--Documentation/git-merge-index.txt87
-rw-r--r--Documentation/git-merge-one-file.txt29
-rw-r--r--Documentation/git-merge-tree.txt36
-rw-r--r--Documentation/git-merge.txt171
-rw-r--r--Documentation/git-mergetool.txt73
-rw-r--r--Documentation/git-mktag.txt46
-rw-r--r--Documentation/git-mktree.txt34
-rw-r--r--Documentation/git-mv.txt54
-rw-r--r--Documentation/git-name-rev.txt85
-rw-r--r--Documentation/git-pack-objects.txt212
-rw-r--r--Documentation/git-pack-redundant.txt57
-rw-r--r--Documentation/git-pack-refs.txt66
-rw-r--r--Documentation/git-parse-remote.txt50
-rw-r--r--Documentation/git-patch-id.txt42
-rw-r--r--Documentation/git-peek-remote.txt50
-rw-r--r--Documentation/git-prune-packed.txt52
-rw-r--r--Documentation/git-prune.txt86
-rw-r--r--Documentation/git-pull.txt206
-rw-r--r--Documentation/git-push.txt206
-rw-r--r--Documentation/git-quiltimport.txt62
-rw-r--r--Documentation/git-read-tree.txt367
-rw-r--r--Documentation/git-rebase.txt409
-rw-r--r--Documentation/git-receive-pack.txt165
-rw-r--r--Documentation/git-reflog.txt105
-rw-r--r--Documentation/git-relink.txt37
-rw-r--r--Documentation/git-remote.txt157
-rw-r--r--Documentation/git-repack.txt133
-rw-r--r--Documentation/git-repo-config.txt18
-rw-r--r--Documentation/git-request-pull.txt39
-rw-r--r--Documentation/git-rerere.txt211
-rw-r--r--Documentation/git-reset.txt206
-rw-r--r--Documentation/git-rev-list.txt112
-rw-r--r--Documentation/git-rev-parse.txt424
-rw-r--r--Documentation/git-revert.txt72
-rw-r--r--Documentation/git-rm.txt112
-rw-r--r--Documentation/git-send-email.txt248
-rw-r--r--Documentation/git-send-pack.txt128
-rw-r--r--Documentation/git-sh-setup.txt80
-rw-r--r--Documentation/git-shell.txt34
-rw-r--r--Documentation/git-shortlog.txt72
-rw-r--r--Documentation/git-show-branch.txt195
-rw-r--r--Documentation/git-show-index.txt34
-rw-r--r--Documentation/git-show-ref.txt179
-rw-r--r--Documentation/git-show.txt84
-rw-r--r--Documentation/git-stash.txt185
-rw-r--r--Documentation/git-status.txt75
-rw-r--r--Documentation/git-stripspace.txt36
-rw-r--r--Documentation/git-submodule.txt104
-rw-r--r--Documentation/git-svn.txt630
-rw-r--r--Documentation/git-symbolic-ref.txt62
-rw-r--r--Documentation/git-tag.txt258
-rw-r--r--Documentation/git-tar-tree.txt89
-rw-r--r--Documentation/git-tools.txt118
-rw-r--r--Documentation/git-unpack-file.txt35
-rw-r--r--Documentation/git-unpack-objects.txt57
-rw-r--r--Documentation/git-update-index.txt333
-rw-r--r--Documentation/git-update-ref.txt93
-rw-r--r--Documentation/git-update-server-info.txt58
-rw-r--r--Documentation/git-upload-archive.txt37
-rw-r--r--Documentation/git-upload-pack.txt46
-rw-r--r--Documentation/git-var.txt64
-rw-r--r--Documentation/git-verify-pack.txt53
-rw-r--r--Documentation/git-verify-tag.txt31
-rw-r--r--Documentation/git-web--browse.txt124
-rw-r--r--Documentation/git-whatchanged.txt79
-rw-r--r--Documentation/git-write-tree.txt49
-rw-r--r--Documentation/git.txt594
-rw-r--r--Documentation/gitattributes.txt521
-rw-r--r--Documentation/gitcli.txt113
-rw-r--r--Documentation/gitcore-tutorial.txt1699
-rw-r--r--Documentation/gitcvs-migration.txt196
-rw-r--r--Documentation/gitdiffcore.txt292
-rw-r--r--Documentation/gitglossary.txt25
-rw-r--r--Documentation/githooks.txt303
-rw-r--r--Documentation/gitignore.txt141
-rw-r--r--Documentation/gitk.txt113
-rw-r--r--Documentation/gitmodules.txt62
-rw-r--r--Documentation/gitrepository-layout.txt208
-rw-r--r--Documentation/gittutorial-2.txt430
-rw-r--r--Documentation/gittutorial.txt608
-rw-r--r--Documentation/glossary-content.txt454
-rwxr-xr-xDocumentation/howto-index.sh56
-rw-r--r--Documentation/howto/maintain-git.txt277
-rw-r--r--Documentation/howto/rebase-and-edit.txt79
-rw-r--r--Documentation/howto/rebase-from-internal-branch.txt163
-rw-r--r--Documentation/howto/rebuild-from-update-hook.txt86
-rw-r--r--Documentation/howto/recover-corrupted-blob-object.txt134
-rw-r--r--Documentation/howto/revert-branch-rebase.txt193
-rw-r--r--Documentation/howto/separating-topic-branches.txt90
-rw-r--r--Documentation/howto/setup-git-server-over-http.txt277
-rw-r--r--Documentation/howto/update-hook-example.txt172
-rw-r--r--Documentation/howto/use-git-daemon.txt51
-rw-r--r--Documentation/howto/using-merge-subtree.txt75
-rw-r--r--Documentation/i18n.txt57
-rwxr-xr-xDocumentation/install-doc-quick.sh31
-rwxr-xr-xDocumentation/install-webdoc.sh39
-rw-r--r--Documentation/manpage-1.72.xsl21
-rw-r--r--Documentation/merge-config.txt40
-rw-r--r--Documentation/merge-options.txt60
-rw-r--r--Documentation/merge-strategies.txt42
-rw-r--r--Documentation/pretty-formats.txt126
-rw-r--r--Documentation/pretty-options.txt25
-rw-r--r--Documentation/pull-fetch-param.txt67
-rw-r--r--Documentation/rev-list-options.txt395
-rw-r--r--Documentation/technical/.gitignore1
-rw-r--r--Documentation/technical/api-allocation-growing.txt34
-rw-r--r--Documentation/technical/api-builtin.txt63
-rw-r--r--Documentation/technical/api-decorate.txt6
-rw-r--r--Documentation/technical/api-diff.txt166
-rw-r--r--Documentation/technical/api-directory-listing.txt76
-rw-r--r--Documentation/technical/api-gitattributes.txt111
-rw-r--r--Documentation/technical/api-grep.txt8
-rw-r--r--Documentation/technical/api-hash.txt6
-rw-r--r--Documentation/technical/api-history-graph.txt179
-rw-r--r--Documentation/technical/api-in-core-index.txt21
-rw-r--r--Documentation/technical/api-index-skel.txt15
-rwxr-xr-xDocumentation/technical/api-index.sh28
-rw-r--r--Documentation/technical/api-lockfile.txt74
-rw-r--r--Documentation/technical/api-object-access.txt15
-rw-r--r--Documentation/technical/api-parse-options.txt6
-rw-r--r--Documentation/technical/api-path-list.txt9
-rw-r--r--Documentation/technical/api-quote.txt10
-rw-r--r--Documentation/technical/api-remote.txt123
-rw-r--r--Documentation/technical/api-revision-walking.txt67
-rw-r--r--Documentation/technical/api-run-command.txt172
-rw-r--r--Documentation/technical/api-setup.txt13
-rw-r--r--Documentation/technical/api-strbuf.txt241
-rw-r--r--Documentation/technical/api-tree-walking.txt12
-rw-r--r--Documentation/technical/api-xdiff-interface.txt7
-rw-r--r--Documentation/technical/pack-format.txt160
-rw-r--r--Documentation/technical/pack-heuristics.txt466
-rw-r--r--Documentation/technical/pack-protocol.txt41
-rw-r--r--Documentation/technical/racy-git.txt195
-rw-r--r--Documentation/technical/send-pack-pipeline.txt63
-rw-r--r--Documentation/technical/shallow.txt49
-rw-r--r--Documentation/technical/trivial-merge.txt121
-rw-r--r--Documentation/urls-remotes.txt82
-rw-r--r--Documentation/urls.txt69
-rw-r--r--Documentation/user-manual.conf21
-rw-r--r--Documentation/user-manual.txt4550
267 files changed, 40372 insertions, 0 deletions
diff --git a/Documentation/.gitattributes b/Documentation/.gitattributes
new file mode 100644
index 0000000000..ddb030137d
--- /dev/null
+++ b/Documentation/.gitattributes
@@ -0,0 +1 @@
+*.txt whitespace
diff --git a/Documentation/.gitignore b/Documentation/.gitignore
new file mode 100644
index 0000000000..2f938f471a
--- /dev/null
+++ b/Documentation/.gitignore
@@ -0,0 +1,8 @@
+*.xml
+*.html
+*.[1-8]
+*.made
+git.info
+howto-index.txt
+doc.dep
+cmds-*.txt
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
new file mode 100644
index 0000000000..d2a0a76e6c
--- /dev/null
+++ b/Documentation/CodingGuidelines
@@ -0,0 +1,126 @@
+Like other projects, we also have some guidelines to keep to the
+code. For git in general, three rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+ ignore your needs should your system not conform to it."
+ We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+ it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+ this is not in POSIX, it (is so convenient | makes the code
+ much more readable | has other good characteristics) and
+ practically all the platforms we care about support it, so
+ let's use it".
+
+ Again, we live in the real world, and it is sometimes a
+ judgement call, the decision based more on real world
+ constraints people face than what the paper standard says.
+
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). But if you must have a list of rules,
+here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+ properly nests. It should have been the way Bourne spelled
+ it from day one, but unfortunately isn't.
+
+ - We use ${parameter-word} and its [-=?+] siblings, and their
+ colon'ed "unset or null" form.
+
+ - We use ${parameter#word} and its [#%] siblings, and their
+ doubled "longest matching" form.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - No "Substring Expansion" ${parameter:offset:length}.
+
+ - No shell arrays.
+
+ - No strlen ${#parameter}.
+
+ - No regexp ${parameter/pattern/string}.
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+ functions.
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+ [::], [==], nor [..]) for portability.
+
+ - We do not use \{m,n\};
+
+ - We do not use -E;
+
+ - We do not use ? nor + (which are \{0,1\} and \{1,\}
+ respectively in BRE) but that goes without saying as these
+ are ERE elements not BRE (note that \? and \+ are not even part
+ of BRE -- making them accessible from BRE is a GNU extension).
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+ 8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - When declaring pointers, the star sides with the variable
+ name, i.e. "char *string", not "char* string" or
+ "char * string". This makes it easier to understand code
+ like "char *string, c;".
+
+ - We avoid using braces unnecessarily. I.e.
+
+ if (bla) {
+ x = 1;
+ }
+
+ is frowned upon. A gray area is when the statement extends
+ over a few lines, and/or you have a lengthy comment atop of
+ it. Also, like in the Linux kernel, if there is a long list
+ of "else if" statements, it can make sense to add braces to
+ single line blocks.
+
+ - We try to avoid assignments inside if().
+
+ - Try to make your code understandable. You may put comments
+ in, but comments invariably tend to stale out when the code
+ they were describing changes. Often splitting a function
+ into two makes the intention of the code much clearer.
+
+ - Double negation is often harder to understand than no negation
+ at all.
+
+ - Some clever tricks, like using the !! operator with arithmetic
+ constructs, can be extremely confusing to others. Avoid them,
+ unless there is a compelling reason to use them.
+
+ - Use the API. No, really. We have a strbuf (variable length
+ string), several arrays with the ALLOC_GROW() macro, a
+ path_list for sorted string lists, a hash map (mapping struct
+ objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document it.
+
+ - The first #include in C files, except in platform specific
+ compat/ implementations, should be git-compat-util.h or another
+ header file that includes it, such as cache.h or builtin.h.
+
+ - If you are planning a new command, consider writing it in shell
+ or perl first, so that changes in semantics can be easily
+ changed and discussed. Many git commands started out like
+ that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into git. This means you
+ usually should stay away from scripting languages not already
+ used in the git core command set (unless your command is clearly
+ separate from it, such as an importer to convert random-scm-X
+ repositories to git).
diff --git a/Documentation/Makefile b/Documentation/Makefile
new file mode 100644
index 0000000000..62269e39c4
--- /dev/null
+++ b/Documentation/Makefile
@@ -0,0 +1,225 @@
+MAN1_TXT= \
+ $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
+ $(wildcard git-*.txt)) \
+ gitk.txt git.txt
+MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \
+ gitrepository-layout.txt
+MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \
+ gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \
+ gitdiffcore.txt
+
+MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
+MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
+MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT))
+
+DOC_HTML=$(MAN_HTML)
+
+ARTICLES = howto-index
+ARTICLES += everyday
+ARTICLES += git-tools
+# with their own formatting rules.
+SP_ARTICLES = howto/revert-branch-rebase howto/using-merge-subtree user-manual
+API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
+SP_ARTICLES += $(API_DOCS)
+SP_ARTICLES += technical/api-index
+
+DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES))
+
+DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT))
+DOC_MAN5=$(patsubst %.txt,%.5,$(MAN5_TXT))
+DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
+
+prefix?=$(HOME)
+bindir?=$(prefix)/bin
+htmldir?=$(prefix)/share/doc/git-doc
+mandir?=$(prefix)/share/man
+man1dir=$(mandir)/man1
+man5dir=$(mandir)/man5
+man7dir=$(mandir)/man7
+# DESTDIR=
+
+ASCIIDOC=asciidoc
+ASCIIDOC_EXTRA =
+MANPAGE_XSL = callouts.xsl
+INSTALL?=install
+RM ?= rm -f
+DOC_REF = origin/man
+
+infodir?=$(prefix)/share/info
+MAKEINFO=makeinfo
+INSTALL_INFO=install-info
+DOCBOOK2X_TEXI=docbook2x-texi
+ifndef PERL_PATH
+ PERL_PATH = /usr/bin/perl
+endif
+
+-include ../config.mak.autogen
+-include ../config.mak
+
+ifdef ASCIIDOC8
+ASCIIDOC_EXTRA += -a asciidoc7compatible
+endif
+ifdef DOCBOOK_XSL_172
+ASCIIDOC_EXTRA += -a docbook-xsl-172
+MANPAGE_XSL = manpage-1.72.xsl
+endif
+
+#
+# Please note that there is a minor bug in asciidoc.
+# The version after 6.0.3 _will_ include the patch found here:
+# http://marc.theaimsgroup.com/?l=git&m=111558757202243&w=2
+#
+# Until that version is released you may have to apply the patch
+# yourself - yes, all 6 characters of it!
+#
+
+all: html man
+
+html: $(DOC_HTML)
+
+$(DOC_HTML) $(DOC_MAN1) $(DOC_MAN5) $(DOC_MAN7): asciidoc.conf
+
+man: man1 man5 man7
+man1: $(DOC_MAN1)
+man5: $(DOC_MAN5)
+man7: $(DOC_MAN7)
+
+info: git.info gitman.info
+
+install: man
+ $(INSTALL) -d -m 755 $(DESTDIR)$(man1dir)
+ $(INSTALL) -d -m 755 $(DESTDIR)$(man5dir)
+ $(INSTALL) -d -m 755 $(DESTDIR)$(man7dir)
+ $(INSTALL) -m 644 $(DOC_MAN1) $(DESTDIR)$(man1dir)
+ $(INSTALL) -m 644 $(DOC_MAN5) $(DESTDIR)$(man5dir)
+ $(INSTALL) -m 644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
+
+install-info: info
+ $(INSTALL) -d -m 755 $(DESTDIR)$(infodir)
+ $(INSTALL) -m 644 git.info gitman.info $(DESTDIR)$(infodir)
+ if test -r $(DESTDIR)$(infodir)/dir; then \
+ $(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) git.info ;\
+ $(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) gitman.info ;\
+ else \
+ echo "No directory found in $(DESTDIR)$(infodir)" >&2 ; \
+ fi
+
+install-html: html
+ sh ./install-webdoc.sh $(DESTDIR)$(htmldir)
+
+../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
+ $(MAKE) -C ../ GIT-VERSION-FILE
+
+-include ../GIT-VERSION-FILE
+
+#
+# Determine "include::" file references in asciidoc files.
+#
+doc.dep : $(wildcard *.txt) build-docdep.perl
+ $(RM) $@+ $@
+ $(PERL_PATH) ./build-docdep.perl >$@+
+ mv $@+ $@
+
+-include doc.dep
+
+cmds_txt = cmds-ancillaryinterrogators.txt \
+ cmds-ancillarymanipulators.txt \
+ cmds-mainporcelain.txt \
+ cmds-plumbinginterrogators.txt \
+ cmds-plumbingmanipulators.txt \
+ cmds-synchingrepositories.txt \
+ cmds-synchelpers.txt \
+ cmds-purehelpers.txt \
+ cmds-foreignscminterface.txt
+
+$(cmds_txt): cmd-list.made
+
+cmd-list.made: cmd-list.perl ../command-list.txt $(MAN1_TXT)
+ $(RM) $@
+ $(PERL_PATH) ./cmd-list.perl ../command-list.txt
+ date >$@
+
+clean:
+ $(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7
+ $(RM) *.texi *.texi+ git.info gitman.info
+ $(RM) howto-index.txt howto/*.html doc.dep
+ $(RM) technical/api-*.html technical/api-index.txt
+ $(RM) $(cmds_txt) *.made
+
+$(MAN_HTML): %.html : %.txt
+ $(RM) $@+ $@
+ $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
+ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
+ mv $@+ $@
+
+%.1 %.5 %.7 : %.xml
+ $(RM) $@
+ xmlto -m $(MANPAGE_XSL) man $<
+
+%.xml : %.txt
+ $(RM) $@+ $@
+ $(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \
+ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
+ mv $@+ $@
+
+user-manual.xml: user-manual.txt user-manual.conf
+ $(ASCIIDOC) -b docbook -d book $<
+
+technical/api-index.txt: technical/api-index-skel.txt \
+ technical/api-index.sh $(patsubst %,%.txt,$(API_DOCS))
+ cd technical && sh ./api-index.sh
+
+$(patsubst %,%.html,$(API_DOCS) technical/api-index): %.html : %.txt
+ $(ASCIIDOC) -b xhtml11 -f asciidoc.conf \
+ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt
+
+XSLT = docbook.xsl
+XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css
+
+user-manual.html: user-manual.xml
+ xsltproc $(XSLTOPTS) -o $@ $(XSLT) $<
+
+git.info: user-manual.texi
+ $(MAKEINFO) --no-split -o $@ user-manual.texi
+
+user-manual.texi: user-manual.xml
+ $(RM) $@+ $@
+ $(DOCBOOK2X_TEXI) user-manual.xml --to-stdout | $(PERL_PATH) fix-texi.perl >$@+
+ mv $@+ $@
+
+gitman.texi: $(MAN_XML) cat-texi.perl
+ $(RM) $@+ $@
+ ($(foreach xml,$(MAN_XML),$(DOCBOOK2X_TEXI) --to-stdout $(xml);)) | \
+ $(PERL_PATH) cat-texi.perl $@ >$@+
+ mv $@+ $@
+
+gitman.info: gitman.texi
+ $(MAKEINFO) --no-split $*.texi
+
+$(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml
+ $(RM) $@+ $@
+ $(DOCBOOK2X_TEXI) --to-stdout $*.xml >$@+
+ mv $@+ $@
+
+howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
+ $(RM) $@+ $@
+ sh ./howto-index.sh $(wildcard howto/*.txt) >$@+
+ mv $@+ $@
+
+$(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
+ $(ASCIIDOC) -b xhtml11 $*.txt
+
+WEBDOC_DEST = /pub/software/scm/git/docs
+
+$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
+ $(RM) $@+ $@
+ sed -e '1,/^$$/d' $< | $(ASCIIDOC) -b xhtml11 - >$@+
+ mv $@+ $@
+
+install-webdoc : html
+ sh ./install-webdoc.sh $(WEBDOC_DEST)
+
+quick-install:
+ sh ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir)
+
+.PHONY: .FORCE-GIT-VERSION-FILE
diff --git a/Documentation/RelNotes-1.5.0.1.txt b/Documentation/RelNotes-1.5.0.1.txt
new file mode 100644
index 0000000000..fea3f9935b
--- /dev/null
+++ b/Documentation/RelNotes-1.5.0.1.txt
@@ -0,0 +1,42 @@
+GIT v1.5.0.1 Release Notes
+==========================
+
+Fixes since v1.5.0
+------------------
+
+* Documentation updates
+
+ - Clarifications and corrections to 1.5.0 release notes.
+
+ - The main documentation did not link to git-remote documentation.
+
+ - Clarified introductory text of git-rebase documentation.
+
+ - Converted remaining mentions of update-index on Porcelain
+ documents to git-add/git-rm.
+
+ - Some i18n.* configuration variables were incorrectly
+ described as core.*; fixed.
+
+* Bugfixes
+
+ - git-add and git-update-index on a filesystem on which
+ executable bits are unreliable incorrectly reused st_mode
+ bits even when the path changed between symlink and regular
+ file.
+
+ - git-daemon marks the listening sockets with FD_CLOEXEC so
+ that it won't be leaked into the children.
+
+ - segfault from git-blame when the mandatory pathname
+ parameter was missing was fixed; usage() message is given
+ instead.
+
+ - git-rev-list did not read $GIT_DIR/config file, which means
+ that did not honor i18n.logoutputencoding correctly.
+
+* Tweaks
+
+ - sliding mmap() inefficiently mmaped the same region of a
+ packfile with an access pattern that used objects in the
+ reverse order. This has been made more efficient.
diff --git a/Documentation/RelNotes-1.5.0.2.txt b/Documentation/RelNotes-1.5.0.2.txt
new file mode 100644
index 0000000000..b061e50ff0
--- /dev/null
+++ b/Documentation/RelNotes-1.5.0.2.txt
@@ -0,0 +1,65 @@
+GIT v1.5.0.2 Release Notes
+==========================
+
+Fixes since v1.5.0.1
+--------------------
+
+* Bugfixes
+
+ - Automated merge conflict handling when changes to symbolic
+ links conflicted were completely broken. The merge-resolve
+ strategy created a regular file with conflict markers in it
+ in place of the symbolic link. The default strategy,
+ merge-recursive was even more broken. It removed the path
+ that was pointed at by the symbolic link. Both of these
+ problems have been fixed.
+
+ - 'git diff maint master next' did not correctly give combined
+ diff across three trees.
+
+ - 'git fast-import' portability fix for Solaris.
+
+ - 'git show-ref --verify' without arguments did not error out
+ but segfaulted.
+
+ - 'git diff :tracked-file `pwd`/an-untracked-file' gave an extra
+ slashes after a/ and b/.
+
+ - 'git format-patch' produced too long filenames if the commit
+ message had too long line at the beginning.
+
+ - Running 'make all' and then without changing anything
+ running 'make install' still rebuilt some files. This
+ was inconvenient when building as yourself and then
+ installing as root (especially problematic when the source
+ directory is on NFS and root is mapped to nobody).
+
+ - 'git-rerere' failed to deal with two unconflicted paths that
+ sorted next to each other.
+
+ - 'git-rerere' attempted to open(2) a symlink and failed if
+ there was a conflict. Since a conflicting change to a
+ symlink would not benefit from rerere anyway, the command
+ now ignores conflicting changes to symlinks.
+
+ - 'git-repack' did not like to pass more than 64 arguments
+ internally to underlying 'rev-list' logic, which made it
+ impossible to repack after accumulating many (small) packs
+ in the repository.
+
+ - 'git-diff' to review the combined diff during a conflicted
+ merge were not reading the working tree version correctly
+ when changes to a symbolic link conflicted. It should have
+ read the data using readlink(2) but read from the regular
+ file the symbolic link pointed at.
+
+ - 'git-remote' did not like period in a remote's name.
+
+* Documentation updates
+
+ - added and clarified core.bare, core.legacyheaders configurations.
+
+ - updated "git-clone --depth" documentation.
+
+
+* Assorted git-gui fixes.
diff --git a/Documentation/RelNotes-1.5.0.3.txt b/Documentation/RelNotes-1.5.0.3.txt
new file mode 100644
index 0000000000..cd500f96bf
--- /dev/null
+++ b/Documentation/RelNotes-1.5.0.3.txt
@@ -0,0 +1,58 @@
+GIT v1.5.0.3 Release Notes
+==========================
+
+Fixes since v1.5.0.2
+--------------------
+
+* Bugfixes
+
+ - 'git.el' honors the commit coding system from the configuration.
+
+ - 'blameview' in contrib/ correctly digs deeper when a line is
+ clicked.
+
+ - 'http-push' correctly makes sure the remote side has leading
+ path. Earlier it started in the middle of the path, and
+ incorrectly.
+
+ - 'git-merge' did not exit with non-zero status when the
+ working tree was dirty and cannot fast forward. It does
+ now.
+
+ - 'cvsexportcommit' does not lose yet-to-be-used message file.
+
+ - int-vs-size_t typefix when running combined diff on files
+ over 2GB long.
+
+ - 'git apply --whitespace=strip' should not touch unmodified
+ lines.
+
+ - 'git-mailinfo' choke when a logical header line was too long.
+
+ - 'git show A..B' did not error out. Negative ref ("not A" in
+ this example) does not make sense for the purpose of the
+ command, so now it errors out.
+
+ - 'git fmt-merge-msg --file' without file parameter did not
+ correctly error out.
+
+ - 'git archimport' barfed upon encountering a commit without
+ summary.
+
+ - 'git index-pack' did not protect itself from getting a short
+ read out of pread(2).
+
+ - 'git http-push' had a few buffer overruns.
+
+ - Build dependency fixes to rebuild fetch.o when other headers
+ change.
+
+* Documentation updates
+
+ - user-manual updates.
+
+ - Options to 'git remote add' were described insufficiently.
+
+ - Configuration format.suffix was not documented.
+
+ - Other formatting and spelling fixes.
diff --git a/Documentation/RelNotes-1.5.0.4.txt b/Documentation/RelNotes-1.5.0.4.txt
new file mode 100644
index 0000000000..feefa5dfd4
--- /dev/null
+++ b/Documentation/RelNotes-1.5.0.4.txt
@@ -0,0 +1,22 @@
+GIT v1.5.0.4 Release Notes
+==========================
+
+Fixes since v1.5.0.3
+--------------------
+
+* Bugfixes
+
+ - git.el does not add duplicate sign-off lines.
+
+ - git-commit shows the full stat of the resulting commit, not
+ just about the files in the current directory, when run from
+ a subdirectory.
+
+ - "git-checkout -m '@{8 hours ago}'" had a funny failure from
+ eval; fixed.
+
+ - git-gui updates.
+
+* Documentation updates
+
+* User manual updates
diff --git a/Documentation/RelNotes-1.5.0.5.txt b/Documentation/RelNotes-1.5.0.5.txt
new file mode 100644
index 0000000000..eeec3d73d0
--- /dev/null
+++ b/Documentation/RelNotes-1.5.0.5.txt
@@ -0,0 +1,26 @@
+GIT v1.5.0.5 Release Notes
+==========================
+
+Fixes since v1.5.0.3
+--------------------
+
+* Bugfixes
+
+ - git-merge (hence git-pull) did not refuse fast-forwarding
+ when the working tree had local changes that would have
+ conflicted with it.
+
+ - git.el does not add duplicate sign-off lines.
+
+ - git-commit shows the full stat of the resulting commit, not
+ just about the files in the current directory, when run from
+ a subdirectory.
+
+ - "git-checkout -m '@{8 hours ago}'" had a funny failure from
+ eval; fixed.
+
+ - git-gui updates.
+
+* Documentation updates
+
+* User manual updates
diff --git a/Documentation/RelNotes-1.5.0.6.txt b/Documentation/RelNotes-1.5.0.6.txt
new file mode 100644
index 0000000000..c02015ad5f
--- /dev/null
+++ b/Documentation/RelNotes-1.5.0.6.txt
@@ -0,0 +1,21 @@
+GIT v1.5.0.6 Release Notes
+==========================
+
+Fixes since v1.5.0.5
+--------------------
+
+* Bugfixes
+
+ - a handful small fixes to gitweb.
+
+ - build procedure for user-manual is fixed not to require locally
+ installed stylesheets.
+
+ - "git commit $paths" on paths whose earlier contents were
+ already updated in the index were failing out.
+
+* Documentation
+
+ - user-manual has better cross references.
+
+ - gitweb installation/deployment procedure is now documented.
diff --git a/Documentation/RelNotes-1.5.0.7.txt b/Documentation/RelNotes-1.5.0.7.txt
new file mode 100644
index 0000000000..670ad32b85
--- /dev/null
+++ b/Documentation/RelNotes-1.5.0.7.txt
@@ -0,0 +1,18 @@
+GIT v1.5.0.7 Release Notes
+==========================
+
+Fixes since v1.5.0.6
+--------------------
+
+* Bugfixes
+
+ - git-upload-pack failed to close unused pipe ends, resulting
+ in many zombies to hang around.
+
+ - git-rerere was recording the contents of earlier hunks
+ duplicated in later hunks. This prevented resolving the same
+ conflict when performing the same merge the other way around.
+
+* Documentation
+
+ - a few documentation fixes from Debian package maintainer.
diff --git a/Documentation/RelNotes-1.5.0.txt b/Documentation/RelNotes-1.5.0.txt
new file mode 100644
index 0000000000..daf4bdb0d7
--- /dev/null
+++ b/Documentation/RelNotes-1.5.0.txt
@@ -0,0 +1,469 @@
+GIT v1.5.0 Release Notes
+========================
+
+Old news
+--------
+
+This section is for people who are upgrading from ancient
+versions of git. Although all of the changes in this section
+happened before the current v1.4.4 release, they are summarized
+here in the v1.5.0 release notes for people who skipped earlier
+versions.
+
+As of git v1.5.0 there are some optional features that changes
+the repository to allow data to be stored and transferred more
+efficiently. These features are not enabled by default, as they
+will make the repository unusable with older versions of git.
+Specifically, the available options are:
+
+ - There is a configuration variable core.legacyheaders that
+ changes the format of loose objects so that they are more
+ efficient to pack and to send out of the repository over git
+ native protocol, since v1.4.2. However, loose objects
+ written in the new format cannot be read by git older than
+ that version; people fetching from your repository using
+ older clients over dumb transports (e.g. http) using older
+ versions of git will also be affected.
+
+ To let git use the new loose object format, you have to
+ set core.legacyheaders to false.
+
+ - Since v1.4.3, configuration repack.usedeltabaseoffset allows
+ packfile to be created in more space efficient format, which
+ cannot be read by git older than that version.
+
+ To let git use the new format for packfiles, you have to
+ set repack.usedeltabaseoffset to true.
+
+The above two new features are not enabled by default and you
+have to explicitly ask for them, because they make repositories
+unreadable by older versions of git, and in v1.5.0 we still do
+not enable them by default for the same reason. We will change
+this default probably 1 year after 1.4.2's release, when it is
+reasonable to expect everybody to have new enough version of
+git.
+
+ - 'git pack-refs' appeared in v1.4.4; this command allows tags
+ to be accessed much more efficiently than the traditional
+ 'one-file-per-tag' format. Older git-native clients can
+ still fetch from a repository that packed and pruned refs
+ (the server side needs to run the up-to-date version of git),
+ but older dumb transports cannot. Packing of refs is done by
+ an explicit user action, either by use of "git pack-refs
+ --prune" command or by use of "git gc" command.
+
+ - 'git -p' to paginate anything -- many commands do pagination
+ by default on a tty. Introduced between v1.4.1 and v1.4.2;
+ this may surprise old timers.
+
+ - 'git archive' superseded 'git tar-tree' in v1.4.3;
+
+ - 'git cvsserver' was new invention in v1.3.0;
+
+ - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
+ seriously enhanced during v1.4.0 timeperiod.
+
+ - 'gitweb' became part of git.git during v1.4.0 timeperiod and
+ seriously modified since then.
+
+ - reflog is an v1.4.0 invention. This allows you to name a
+ revision that a branch used to be at (e.g. "git diff
+ master@{yesterday} master" allows you to see changes since
+ yesterday's tip of the branch).
+
+
+Updates in v1.5.0 since v1.4.4 series
+-------------------------------------
+
+* Index manipulation
+
+ - git-add is to add contents to the index (aka "staging area"
+ for the next commit), whether the file the contents happen to
+ be is an existing one or a newly created one.
+
+ - git-add without any argument does not add everything
+ anymore. Use 'git-add .' instead. Also you can add
+ otherwise ignored files with an -f option.
+
+ - git-add tries to be more friendly to users by offering an
+ interactive mode ("git-add -i").
+
+ - git-commit <path> used to refuse to commit if <path> was
+ different between HEAD and the index (i.e. update-index was
+ used on it earlier). This check was removed.
+
+ - git-rm is much saner and safer. It is used to remove paths
+ from both the index file and the working tree, and makes sure
+ you are not losing any local modification before doing so.
+
+ - git-reset <tree> <paths>... can be used to revert index
+ entries for selected paths.
+
+ - git-update-index is much less visible. Many suggestions to
+ use the command in git output and documentation have now been
+ replaced by simpler commands such as "git add" or "git rm".
+
+
+* Repository layout and objects transfer
+
+ - The data for origin repository is stored in the configuration
+ file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
+ created clones. The latter is still supported and there is
+ no need to convert your existing repository if you are
+ already comfortable with your workflow with the layout.
+
+ - git-clone always uses what is known as "separate remote"
+ layout for a newly created repository with a working tree.
+
+ A repository with the separate remote layout starts with only
+ one default branch, 'master', to be used for your own
+ development. Unlike the traditional layout that copied all
+ the upstream branches into your branch namespace (while
+ renaming their 'master' to your 'origin'), the new layout
+ puts upstream branches into local "remote-tracking branches"
+ with their own namespace. These can be referenced with names
+ such as "origin/$upstream_branch_name" and are stored in
+ .git/refs/remotes rather than .git/refs/heads where normal
+ branches are stored.
+
+ This layout keeps your own branch namespace less cluttered,
+ avoids name collision with your upstream, makes it possible
+ to automatically track new branches created at the remote
+ after you clone from it, and makes it easier to interact with
+ more than one remote repository (you can use "git remote" to
+ add other repositories to track). There might be some
+ surprises:
+
+ * 'git branch' does not show the remote tracking branches.
+ It only lists your own branches. Use '-r' option to view
+ the tracking branches.
+
+ * If you are forking off of a branch obtained from the
+ upstream, you would have done something like 'git branch
+ my-next next', because traditional layout dropped the
+ tracking branch 'next' into your own branch namespace.
+ With the separate remote layout, you say 'git branch next
+ origin/next', which allows you to use the matching name
+ 'next' for your own branch. It also allows you to track a
+ remote other than 'origin' (i.e. where you initially cloned
+ from) and fork off of a branch from there the same way
+ (e.g. "git branch mingw j6t/master").
+
+ Repositories initialized with the traditional layout continue
+ to work.
+
+ - New branches that appear on the origin side after a clone is
+ made are also tracked automatically. This is done with an
+ wildcard refspec "refs/heads/*:refs/remotes/origin/*", which
+ older git does not understand, so if you clone with 1.5.0,
+ you would need to downgrade remote.*.fetch in the
+ configuration file to specify each branch you are interested
+ in individually if you plan to fetch into the repository with
+ older versions of git (but why would you?).
+
+ - Similarly, wildcard refspec "refs/heads/*:refs/remotes/me/*"
+ can be given to "git-push" command to update the tracking
+ branches that is used to track the repository you are pushing
+ from on the remote side.
+
+ - git-branch and git-show-branch know remote tracking branches
+ (use the command line switch "-r" to list only tracked branches).
+
+ - git-push can now be used to delete a remote branch or a tag.
+ This requires the updated git on the remote side (use "git
+ push <remote> :refs/heads/<branch>" to delete "branch").
+
+ - git-push more aggressively keeps the transferred objects
+ packed. Earlier we recommended to monitor amount of loose
+ objects and repack regularly, but you should repack when you
+ accumulated too many small packs this way as well. Updated
+ git-count-objects helps you with this.
+
+ - git-fetch also more aggressively keeps the transferred objects
+ packed. This behavior of git-push and git-fetch can be
+ tweaked with a single configuration transfer.unpacklimit (but
+ usually there should not be any need for a user to tweak it).
+
+ - A new command, git-remote, can help you manage your remote
+ tracking branch definitions.
+
+ - You may need to specify explicit paths for upload-pack and/or
+ receive-pack due to your ssh daemon configuration on the
+ other end. This can now be done via remote.*.uploadpack and
+ remote.*.receivepack configuration.
+
+
+* Bare repositories
+
+ - Certain commands change their behavior in a bare repository
+ (i.e. a repository without associated working tree). We use
+ a fairly conservative heuristic (if $GIT_DIR is ".git", or
+ ends with "/.git", the repository is not bare) to decide if a
+ repository is bare, but "core.bare" configuration variable
+ can be used to override the heuristic when it misidentifies
+ your repository.
+
+ - git-fetch used to complain updating the current branch but
+ this is now allowed for a bare repository. So is the use of
+ 'git-branch -f' to update the current branch.
+
+ - Porcelain-ish commands that require a working tree refuses to
+ work in a bare repository.
+
+
+* Reflog
+
+ - Reflog records the history from the view point of the local
+ repository. In other words, regardless of the real history,
+ the reflog shows the history as seen by one particular
+ repository (this enables you to ask "what was the current
+ revision in _this_ repository, yesterday at 1pm?"). This
+ facility is enabled by default for repositories with working
+ trees, and can be accessed with the "branch@{time}" and
+ "branch@{Nth}" notation.
+
+ - "git show-branch" learned showing the reflog data with the
+ new -g option. "git log" has -g option to view reflog
+ entries in a more verbose manner.
+
+ - git-branch knows how to rename branches and moves existing
+ reflog data from the old branch to the new one.
+
+ - In addition to the reflog support in v1.4.4 series, HEAD
+ reference maintains its own log. "HEAD@{5.minutes.ago}"
+ means the commit you were at 5 minutes ago, which takes
+ branch switching into account. If you want to know where the
+ tip of your current branch was at 5 minutes ago, you need to
+ explicitly say its name (e.g. "master@{5.minutes.ago}") or
+ omit the refname altogether i.e. "@{5.minutes.ago}".
+
+ - The commits referred to by reflog entries are now protected
+ against pruning. The new command "git reflog expire" can be
+ used to truncate older reflog entries and entries that refer
+ to commits that have been pruned away previously with older
+ versions of git.
+
+ Existing repositories that have been using reflog may get
+ complaints from fsck-objects and may not be able to run
+ git-repack, if you had run git-prune from older git; please
+ run "git reflog expire --stale-fix --all" first to remove
+ reflog entries that refer to commits that are no longer in
+ the repository when that happens.
+
+
+* Crufts removal
+
+ - We used to say "old commits are retrievable using reflog and
+ 'master@{yesterday}' syntax as long as you haven't run
+ git-prune". We no longer have to say the latter half of the
+ above sentence, as git-prune does not remove things reachable
+ from reflog entries.
+
+ - There is a toplevel garbage collector script, 'git-gc', that
+ runs periodic cleanup functions, including 'git-repack -a -d',
+ 'git-reflog expire', 'git-pack-refs --prune', and 'git-rerere
+ gc'.
+
+ - The output from fsck ("fsck-objects" is called just "fsck"
+ now, but the old name continues to work) was needlessly
+ alarming in that it warned missing objects that are reachable
+ only from dangling objects. This has been corrected and the
+ output is much more useful.
+
+
+* Detached HEAD
+
+ - You can use 'git-checkout' to check out an arbitrary revision
+ or a tag as well, instead of named branches. This will
+ dissociate your HEAD from the branch you are currently on.
+
+ A typical use of this feature is to "look around". E.g.
+
+ $ git checkout v2.6.16
+ ... compile, test, etc.
+ $ git checkout v2.6.17
+ ... compile, test, etc.
+
+ - After detaching your HEAD, you can go back to an existing
+ branch with usual "git checkout $branch". Also you can
+ start a new branch using "git checkout -b $newbranch" to
+ start a new branch at that commit.
+
+ - You can even pull from other repositories, make merges and
+ commits while your HEAD is detached. Also you can use "git
+ reset" to jump to arbitrary commit, while still keeping your
+ HEAD detached.
+
+ Remember that a detached state is volatile, i.e. it will be forgotten
+ as soon as you move away from it with the checkout or reset command,
+ unless a branch is created from it as mentioned above. It is also
+ possible to rescue a lost detached state from the HEAD reflog.
+
+
+* Packed refs
+
+ - Repositories with hundreds of tags have been paying large
+ overhead, both in storage and in runtime, due to the
+ traditional one-ref-per-file format. A new command,
+ git-pack-refs, can be used to "pack" them in more efficient
+ representation (you can let git-gc do this for you).
+
+ - Clones and fetches over dumb transports are now aware of
+ packed refs and can download from repositories that use
+ them.
+
+
+* Configuration
+
+ - configuration related to color setting are consolidated under
+ color.* namespace (older diff.color.*, status.color.* are
+ still supported).
+
+ - 'git-repo-config' command is accessible as 'git-config' now.
+
+
+* Updated features
+
+ - git-describe uses better criteria to pick a base ref. It
+ used to pick the one with the newest timestamp, but now it
+ picks the one that is topologically the closest (that is,
+ among ancestors of commit C, the ref T that has the shortest
+ output from "git-rev-list T..C" is chosen).
+
+ - git-describe gives the number of commits since the base ref
+ between the refname and the hash suffix. E.g. the commit one
+ before v2.6.20-rc6 in the kernel repository is:
+
+ v2.6.20-rc5-306-ga21b069
+
+ which tells you that its object name begins with a21b069,
+ v2.6.20-rc5 is an ancestor of it (meaning, the commit
+ contains everything -rc5 has), and there are 306 commits
+ since v2.6.20-rc5.
+
+ - git-describe with --abbrev=0 can be used to show only the
+ name of the base ref.
+
+ - git-blame learned a new option, --incremental, that tells it
+ to output the blames as they are assigned. A sample script
+ to use it is also included as contrib/blameview.
+
+ - git-blame starts annotating from the working tree by default.
+
+
+* Less external dependency
+
+ - We no longer require the "merge" program from the RCS suite.
+ All 3-way file-level merges are now done internally.
+
+ - The original implementation of git-merge-recursive which was
+ in Python has been removed; we have a C implementation of it
+ now.
+
+ - git-shortlog is no longer a Perl script. It no longer
+ requires output piped from git-log; it can accept revision
+ parameters directly on the command line.
+
+
+* I18n
+
+ - We have always encouraged the commit message to be encoded in
+ UTF-8, but the users are allowed to use legacy encoding as
+ appropriate for their projects. This will continue to be the
+ case. However, a non UTF-8 commit encoding _must_ be
+ explicitly set with i18n.commitencoding in the repository
+ where a commit is made; otherwise git-commit-tree will
+ complain if the log message does not look like a valid UTF-8
+ string.
+
+ - The value of i18n.commitencoding in the originating
+ repository is recorded in the commit object on the "encoding"
+ header, if it is not UTF-8. git-log and friends notice this,
+ and reencodes the message to the log output encoding when
+ displaying, if they are different. The log output encoding
+ is determined by "git log --encoding=<encoding>",
+ i18n.logoutputencoding configuration, or i18n.commitencoding
+ configuration, in the decreasing order of preference, and
+ defaults to UTF-8.
+
+ - Tools for e-mailed patch application now default to -u
+ behavior; i.e. it always re-codes from the e-mailed encoding
+ to the encoding specified with i18n.commitencoding. This
+ unfortunately forces projects that have happily been using a
+ legacy encoding without setting i18n.commitencoding to set
+ the configuration, but taken with other improvement, please
+ excuse us for this very minor one-time inconvenience.
+
+
+* e-mailed patches
+
+ - See the above I18n section.
+
+ - git-format-patch now enables --binary without being asked.
+ git-am does _not_ default to it, as sending binary patch via
+ e-mail is unusual and is harder to review than textual
+ patches and it is prudent to require the person who is
+ applying the patch to explicitly ask for it.
+
+ - The default suffix for git-format-patch output is now ".patch",
+ not ".txt". This can be changed with --suffix=.txt option,
+ or setting the config variable "format.suffix" to ".txt".
+
+
+* Foreign SCM interfaces
+
+ - git-svn now requires the Perl SVN:: libraries, the
+ command-line backend was too slow and limited.
+
+ - the 'commit' subcommand of git-svn has been renamed to
+ 'set-tree', and 'dcommit' is the recommended replacement for
+ day-to-day work.
+
+ - git fast-import backend.
+
+
+* User support
+
+ - Quite a lot of documentation updates.
+
+ - Bash completion scripts have been updated heavily.
+
+ - Better error messages for often used Porcelainish commands.
+
+ - Git GUI. This is a simple Tk based graphical interface for
+ common Git operations.
+
+
+* Sliding mmap
+
+ - We used to assume that we can mmap the whole packfile while
+ in use, but with a large project this consumes huge virtual
+ memory space and truly huge ones would not fit in the
+ userland address space on 32-bit platforms. We now mmap huge
+ packfile in pieces to avoid this problem.
+
+
+* Shallow clones
+
+ - There is a partial support for 'shallow' repositories that
+ keeps only recent history. A 'shallow clone' is created by
+ specifying how deep that truncated history should be
+ (e.g. "git clone --depth 5 git://some.where/repo.git").
+
+ Currently a shallow repository has number of limitations:
+
+ - Cloning and fetching _from_ a shallow clone are not
+ supported (nor tested -- so they might work by accident but
+ they are not expected to).
+
+ - Pushing from nor into a shallow clone are not expected to
+ work.
+
+ - Merging inside a shallow repository would work as long as a
+ merge base is found in the recent history, but otherwise it
+ will be like merging unrelated histories and may result in
+ huge conflicts.
+
+ but this would be more than adequate for people who want to
+ look at near the tip of a big project with a deep history and
+ send patches in e-mail format.
diff --git a/Documentation/RelNotes-1.5.1.1.txt b/Documentation/RelNotes-1.5.1.1.txt
new file mode 100644
index 0000000000..91471213bd
--- /dev/null
+++ b/Documentation/RelNotes-1.5.1.1.txt
@@ -0,0 +1,65 @@
+GIT v1.5.1.1 Release Notes
+==========================
+
+Fixes since v1.5.1
+------------------
+
+* Documentation updates
+
+ - The --left-right option of rev-list and friends is documented.
+
+ - The documentation for cvsimport has been majorly improved.
+
+ - "git-show-ref --exclude-existing" was documented.
+
+* Bugfixes
+
+ - The implementation of -p option in "git cvsexportcommit" had
+ the meaning of -C (context reduction) option wrong, and
+ loosened the context requirements when it was told to be
+ strict.
+
+ - "git cvsserver" did not behave like the real cvsserver when
+ client side removed a file from the working tree without
+ doing anything else on the path. In such a case, it should
+ restore it from the checked out revision.
+
+ - "git fsck" issued an alarming error message on detached
+ HEAD. It is not an error since at least 1.5.0.
+
+ - "git send-email" produced of References header of unbounded length;
+ fixed this with line-folding.
+
+ - "git archive" to download from remote site should not
+ require you to be in a git repository, but it incorrectly
+ did.
+
+ - "git apply" ignored -p<n> for "diff --git" formatted
+ patches.
+
+ - "git rerere" recorded a conflict that had one side empty
+ (the other side adds) incorrectly; this made merging in the
+ other direction fail to use previously recorded resolution.
+
+ - t4200 test was broken where "wc -l" pads its output with
+ spaces.
+
+ - "git branch -m old new" to rename branch did not work
+ without a configuration file in ".git/config".
+
+ - The sample hook for notification e-mail was misnamed.
+
+ - gitweb did not show type-changing patch correctly in the
+ blobdiff view.
+
+ - git-svn did not error out with incorrect command line options.
+
+ - git-svn fell into an infinite loop when insanely long commit
+ message was found.
+
+ - git-svn dcommit and rebase was confused by patches that were
+ merged from another branch that is managed by git-svn.
+
+ - git-svn used to get confused when globbing remote branch/tag
+ spec (e.g. "branches = proj/branches/*:refs/remotes/origin/*")
+ is used and there was a plain file that matched the glob.
diff --git a/Documentation/RelNotes-1.5.1.2.txt b/Documentation/RelNotes-1.5.1.2.txt
new file mode 100644
index 0000000000..d88456306c
--- /dev/null
+++ b/Documentation/RelNotes-1.5.1.2.txt
@@ -0,0 +1,50 @@
+GIT v1.5.1.2 Release Notes
+==========================
+
+Fixes since v1.5.1.1
+--------------------
+
+* Bugfixes
+
+ - "git clone" over http from a repository that has lost the
+ loose refs by running "git pack-refs" were broken (a code to
+ deal with this was added to "git fetch" in v1.5.0, but it
+ was missing from "git clone").
+
+ - "git diff a/ b/" incorrectly fell in "diff between two
+ filesystem objects" codepath, when the user most likely
+ wanted to limit the extent of output to two tracked
+ directories.
+
+ - git-quiltimport had the same bug as we fixed for
+ git-applymbox in v1.5.1.1 -- it gave an alarming "did not
+ have any patch" message (but did not actually fail and was
+ harmless).
+
+ - various git-svn fixes.
+
+ - Sample update hook incorrectly always refused requests to
+ delete branches through push.
+
+ - git-blame on a very long working tree path had buffer
+ overrun problem.
+
+ - git-apply did not like to be fed two patches in a row that created
+ and then modified the same file.
+
+ - git-svn was confused when a non-project was stored directly under
+ trunk/, branches/ and tags/.
+
+ - git-svn wants the Error.pm module that was at least as new
+ as what we ship as part of git; install ours in our private
+ installation location if the one on the system is older.
+
+ - An earlier update to command line integer parameter parser was
+ botched and made 'update-index --cacheinfo' completely useless.
+
+
+* Documentation updates
+
+ - Various documentation updates from J. Bruce Fields, Frank
+ Lichtenheld, Alex Riesen and others. Andrew Ruder started a
+ war on undocumented options.
diff --git a/Documentation/RelNotes-1.5.1.3.txt b/Documentation/RelNotes-1.5.1.3.txt
new file mode 100644
index 0000000000..876408b65a
--- /dev/null
+++ b/Documentation/RelNotes-1.5.1.3.txt
@@ -0,0 +1,45 @@
+GIT v1.5.1.3 Release Notes
+==========================
+
+Fixes since v1.5.1.2
+--------------------
+
+* Bugfixes
+
+ - git-add tried to optimize by finding common leading
+ directories across its arguments but botched, causing very
+ confused behaviour.
+
+ - unofficial rpm.spec file shipped with git was letting
+ ETC_GITCONFIG set to /usr/etc/gitconfig. Tweak the official
+ Makefile to make it harder for distro people to make the
+ same mistake, by setting the variable to /etc/gitconfig if
+ prefix is set to /usr.
+
+ - git-svn inconsistently stripped away username from the URL
+ only when svnsync_props was in use.
+
+ - git-svn got confused when handling symlinks on Mac OS.
+
+ - git-send-email was not quoting recipient names that have
+ period '.' in them. Also it did not allow overriding
+ envelope sender, which made it impossible to send patches to
+ certain subscriber-only lists.
+
+ - built-in write_tree() routine had a sequence that renamed a
+ file that is still open, which some systems did not like.
+
+ - when memory is very tight, sliding mmap code to read
+ packfiles incorrectly closed the fd that was still being
+ used to read the pack.
+
+ - import-tars contributed front-end for fastimport was passing
+ wrong directory modes without checking.
+
+ - git-fastimport trusted its input too much and allowed to
+ create corrupt tree objects with entries without a name.
+
+ - git-fetch needlessly barfed when too long reflog action
+ description was given by the caller.
+
+Also contains various documentation updates.
diff --git a/Documentation/RelNotes-1.5.1.4.txt b/Documentation/RelNotes-1.5.1.4.txt
new file mode 100644
index 0000000000..df2f66ccb5
--- /dev/null
+++ b/Documentation/RelNotes-1.5.1.4.txt
@@ -0,0 +1,30 @@
+GIT v1.5.1.4 Release Notes
+==========================
+
+Fixes since v1.5.1.3
+--------------------
+
+* Bugfixes
+
+ - "git-http-fetch" did not work around a bug in libcurl
+ earlier than 7.16 (curl_multi_remove_handle() was broken).
+
+ - "git cvsserver" handles a file that was once removed and
+ then added again correctly.
+
+ - import-tars script (in contrib/) handles GNU tar archives
+ that contain pathnames longer than 100 bytes (long-link
+ extension) correctly.
+
+ - xdelta test program did not build correctly.
+
+ - gitweb sometimes tried incorrectly to apply function to
+ decode utf8 twice, resulting in corrupt output.
+
+ - "git blame -C" mishandled text at the end of a group of
+ lines.
+
+ - "git log/rev-list --boundary" did not produce output
+ correctly without --left-right option.
+
+ - Many documentation updates.
diff --git a/Documentation/RelNotes-1.5.1.5.txt b/Documentation/RelNotes-1.5.1.5.txt
new file mode 100644
index 0000000000..b0ab8eb371
--- /dev/null
+++ b/Documentation/RelNotes-1.5.1.5.txt
@@ -0,0 +1,42 @@
+GIT v1.5.1.5 Release Notes
+==========================
+
+Fixes since v1.5.1.4
+--------------------
+
+* Bugfixes
+
+ - git-send-email did not understand aliases file for mutt, which
+ allows leading whitespaces.
+
+ - git-format-patch emitted Content-Type and Content-Transfer-Encoding
+ headers for non ASCII contents, but failed to add MIME-Version.
+
+ - git-name-rev had a buffer overrun with a deep history.
+
+ - contributed script import-tars did not get the directory in
+ tar archives interpreted correctly.
+
+ - git-svn was reported to segfault for many people on list and
+ #git; hopefully this has been fixed.
+
+ - "git-svn clone" does not try to minimize the URL
+ (i.e. connect to higher level hierarchy) by default, as this
+ can prevent clone to fail if only part of the repository
+ (e.g. 'trunk') is open to public.
+
+ - "git checkout branch^0" did not detach the head when you are
+ already on 'branch'; backported the fix from the 'master'.
+
+ - "git-config section.var" did not correctly work when
+ existing configuration file had both [section] and [section "name"]
+ next to each other.
+
+ - "git clone ../other-directory" was fooled if the current
+ directory $PWD points at is a symbolic link.
+
+ - (build) tree_entry_extract() function was both static inline
+ and extern, which caused trouble compiling with Forte12
+ compilers on Sun.
+
+ - Many many documentation fixes and updates.
diff --git a/Documentation/RelNotes-1.5.1.6.txt b/Documentation/RelNotes-1.5.1.6.txt
new file mode 100644
index 0000000000..55f3ac13e3
--- /dev/null
+++ b/Documentation/RelNotes-1.5.1.6.txt
@@ -0,0 +1,45 @@
+GIT v1.5.1.6 Release Notes
+==========================
+
+Fixes since v1.5.1.4
+--------------------
+
+* Bugfixes
+
+ - git-send-email did not understand aliases file for mutt, which
+ allows leading whitespaces.
+
+ - git-format-patch emitted Content-Type and Content-Transfer-Encoding
+ headers for non ASCII contents, but failed to add MIME-Version.
+
+ - git-name-rev had a buffer overrun with a deep history.
+
+ - contributed script import-tars did not get the directory in
+ tar archives interpreted correctly.
+
+ - git-svn was reported to segfault for many people on list and
+ #git; hopefully this has been fixed.
+
+ - git-svn also had a bug to crash svnserve by sending a bad
+ sequence of requests.
+
+ - "git-svn clone" does not try to minimize the URL
+ (i.e. connect to higher level hierarchy) by default, as this
+ can prevent clone to fail if only part of the repository
+ (e.g. 'trunk') is open to public.
+
+ - "git checkout branch^0" did not detach the head when you are
+ already on 'branch'; backported the fix from the 'master'.
+
+ - "git-config section.var" did not correctly work when
+ existing configuration file had both [section] and [section "name"]
+ next to each other.
+
+ - "git clone ../other-directory" was fooled if the current
+ directory $PWD points at is a symbolic link.
+
+ - (build) tree_entry_extract() function was both static inline
+ and extern, which caused trouble compiling with Forte12
+ compilers on Sun.
+
+ - Many many documentation fixes and updates.
diff --git a/Documentation/RelNotes-1.5.1.txt b/Documentation/RelNotes-1.5.1.txt
new file mode 100644
index 0000000000..daed367270
--- /dev/null
+++ b/Documentation/RelNotes-1.5.1.txt
@@ -0,0 +1,371 @@
+GIT v1.5.1 Release Notes
+========================
+
+Updates since v1.5.0
+--------------------
+
+* Deprecated commands and options.
+
+ - git-diff-stages and git-resolve have been removed.
+
+* New commands and options.
+
+ - "git log" and friends take --reverse, which instructs them
+ to give their output in the order opposite from their usual.
+ They typically output from new to old, but with this option
+ their output would read from old to new. "git shortlog"
+ usually lists older commits first, but with this option,
+ they are shown from new to old.
+
+ - "git log --pretty=format:<string>" to allow more flexible
+ custom log output.
+
+ - "git diff" learned --ignore-space-at-eol. This is a weaker
+ form of --ignore-space-change.
+
+ - "git diff --no-index pathA pathB" can be used as diff
+ replacement with git specific enhancements.
+
+ - "git diff --no-index" can read from '-' (standard input).
+
+ - "git diff" also learned --exit-code to exit with non-zero
+ status when it found differences. In the future we might
+ want to make this the default but that would be a rather big
+ backward incompatible change; it will stay as an option for
+ now.
+
+ - "git diff --quiet" is --exit-code with output turned off,
+ meant for scripted use to quickly determine if there is any
+ tree-level difference.
+
+ - Textual patch generation with "git diff" without -w/-b
+ option has been significantly optimized. "git blame" got
+ faster because of the same change.
+
+ - "git log" and "git rev-list" has been optimized
+ significantly when they are used with pathspecs.
+
+ - "git branch --track" can be used to set up configuration
+ variables to help it easier to base your work on branches
+ you track from a remote site.
+
+ - "git format-patch --attach" now emits attachments. Use
+ --inline to get an inlined multipart/mixed.
+
+ - "git name-rev" learned --refs=<pattern>, to limit the tags
+ used for naming the given revisions only to the ones
+ matching the given pattern.
+
+ - "git remote update" is to run "git fetch" for defined remotes
+ to update tracking branches.
+
+ - "git cvsimport" can now take '-d' to talk with a CVS
+ repository different from what are recorded in CVS/Root
+ (overriding it with environment CVSROOT does not work).
+
+ - "git bundle" can help sneaker-netting your changes between
+ repositories.
+
+ - "git mergetool" can help 3-way file-level conflict
+ resolution with your favorite graphical merge tools.
+
+ - A new configuration "core.symlinks" can be used to disable
+ symlinks on filesystems that do not support them; they are
+ checked out as regular files instead.
+
+ - You can name a commit object with its first line of the
+ message. The syntax to use is ':/message text'. E.g.
+
+ $ git show ":/object name: introduce ':/<oneline prefix>' notation"
+
+ means the same thing as:
+
+ $ git show 28a4d940443806412effa246ecc7768a21553ec7
+
+ - "git bisect" learned a new command "run" that takes a script
+ to run after each revision is checked out to determine if it
+ is good or bad, to automate the bisection process.
+
+ - "git log" family learned a new traversal option --first-parent,
+ which does what the name suggests.
+
+
+* Updated behavior of existing commands.
+
+ - "git-merge-recursive" used to barf when there are more than
+ one common ancestors for the merge, and merging them had a
+ rename/rename conflict. This has been fixed.
+
+ - "git fsck" does not barf on corrupt loose objects.
+
+ - "git rm" does not remove newly added files without -f.
+
+ - "git archimport" allows remapping when coming up with git
+ branch names from arch names.
+
+ - git-svn got almost a rewrite.
+
+ - core.autocrlf configuration, when set to 'true', makes git
+ to convert CRLF at the end of lines in text files to LF when
+ reading from the filesystem, and convert in reverse when
+ writing to the filesystem. The variable can be set to
+ 'input', in which case the conversion happens only while
+ reading from the filesystem but files are written out with
+ LF at the end of lines. Currently, which paths to consider
+ 'text' (i.e. be subjected to the autocrlf mechanism) is
+ decided purely based on the contents, but the plan is to
+ allow users to explicitly override this heuristic based on
+ paths.
+
+ - The behavior of 'git-apply', when run in a subdirectory,
+ without --index nor --cached were inconsistent with that of
+ the command with these options. This was fixed to match the
+ behavior with --index. A patch that is meant to be applied
+ with -p1 from the toplevel of the project tree can be
+ applied with any custom -p<n> option. A patch that is not
+ relative to the toplevel needs to be applied with -p<n>
+ option with or without --index (or --cached).
+
+ - "git diff" outputs a trailing HT when pathnames have embedded
+ SP on +++/--- header lines, in order to help "GNU patch" to
+ parse its output. "git apply" was already updated to accept
+ this modified output format since ce74618d (Sep 22, 2006).
+
+ - "git cvsserver" runs hooks/update and honors its exit status.
+
+ - "git cvsserver" can be told to send everything with -kb.
+
+ - "git diff --check" also honors the --color output option.
+
+ - "git name-rev" used to stress the fact that a ref is a tag too
+ much, by saying something like "v1.2.3^0~22". It now says
+ "v1.2.3~22" in such a case (it still says "v1.2.3^0" if it does
+ not talk about an ancestor of the commit that is tagged, which
+ makes sense).
+
+ - "git rev-list --boundary" now shows boundary markers for the
+ commits omitted by --max-age and --max-count condition.
+
+ - The configuration mechanism now reads $(prefix)/etc/gitconfig.
+
+ - "git apply --verbose" shows what preimage lines were wanted
+ when it couldn't find them.
+
+ - "git status" in a read-only repository got a bit saner.
+
+ - "git fetch" (hence "git clone" and "git pull") are less
+ noisy when the output does not go to tty.
+
+ - "git fetch" between repositories with many refs were slow
+ even when there are not many changes that needed
+ transferring. This has been sped up by partially rewriting
+ the heaviest parts in C.
+
+ - "git mailinfo" which splits an e-mail into a patch and the
+ meta-information was rewritten, thanks to Don Zickus. It
+ handles nested multipart better. The command was broken for
+ a brief period on 'master' branch since 1.5.0 but the
+ breakage is fixed now.
+
+ - send-email learned configurable bcc and chain-reply-to.
+
+ - "git remote show $remote" also talks about branches that
+ would be pushed if you run "git push remote".
+
+ - Using objects from packs is now seriously optimized by clever
+ use of a cache. This should be most noticeable in git-log
+ family of commands that involve reading many tree objects.
+ In addition, traversing revisions while filtering changes
+ with pathspecs is made faster by terminating the comparison
+ between the trees as early as possible.
+
+
+* Hooks
+
+ - The part to send out notification e-mails was removed from
+ the sample update hook, as it was not an appropriate place
+ to do so. The proper place to do this is the new post-receive
+ hook. An example hook has been added to contrib/hooks/.
+
+
+* Others
+
+ - git-revert, git-gc and git-cherry-pick are now built-ins.
+
+Fixes since v1.5.0
+------------------
+
+These are all in v1.5.0.x series.
+
+* Documentation updates
+
+ - Clarifications and corrections to 1.5.0 release notes.
+
+ - The main documentation did not link to git-remote documentation.
+
+ - Clarified introductory text of git-rebase documentation.
+
+ - Converted remaining mentions of update-index on Porcelain
+ documents to git-add/git-rm.
+
+ - Some i18n.* configuration variables were incorrectly
+ described as core.*; fixed.
+
+ - added and clarified core.bare, core.legacyheaders configurations.
+
+ - updated "git-clone --depth" documentation.
+
+ - user-manual updates.
+
+ - Options to 'git remote add' were described insufficiently.
+
+ - Configuration format.suffix was not documented.
+
+ - Other formatting and spelling fixes.
+
+ - user-manual has better cross references.
+
+ - gitweb installation/deployment procedure is now documented.
+
+
+* Bugfixes
+
+ - git-upload-pack closes unused pipe ends; earlier this caused
+ many zombies to hang around.
+
+ - git-rerere was recording the contents of earlier hunks
+ duplicated in later hunks. This prevented resolving the same
+ conflict when performing the same merge the other way around.
+
+ - git-add and git-update-index on a filesystem on which
+ executable bits are unreliable incorrectly reused st_mode
+ bits even when the path changed between symlink and regular
+ file.
+
+ - git-daemon marks the listening sockets with FD_CLOEXEC so
+ that it won't be leaked into the children.
+
+ - segfault from git-blame when the mandatory pathname
+ parameter was missing was fixed; usage() message is given
+ instead.
+
+ - git-rev-list did not read $GIT_DIR/config file, which means
+ that did not honor i18n.logoutputencoding correctly.
+
+ - Automated merge conflict handling when changes to symbolic
+ links conflicted were completely broken. The merge-resolve
+ strategy created a regular file with conflict markers in it
+ in place of the symbolic link. The default strategy,
+ merge-recursive was even more broken. It removed the path
+ that was pointed at by the symbolic link. Both of these
+ problems have been fixed.
+
+ - 'git diff maint master next' did not correctly give combined
+ diff across three trees.
+
+ - 'git fast-import' portability fix for Solaris.
+
+ - 'git show-ref --verify' without arguments did not error out
+ but segfaulted.
+
+ - 'git diff :tracked-file `pwd`/an-untracked-file' gave an extra
+ slashes after a/ and b/.
+
+ - 'git format-patch' produced too long filenames if the commit
+ message had too long line at the beginning.
+
+ - Running 'make all' and then without changing anything
+ running 'make install' still rebuilt some files. This
+ was inconvenient when building as yourself and then
+ installing as root (especially problematic when the source
+ directory is on NFS and root is mapped to nobody).
+
+ - 'git-rerere' failed to deal with two unconflicted paths that
+ sorted next to each other.
+
+ - 'git-rerere' attempted to open(2) a symlink and failed if
+ there was a conflict. Since a conflicting change to a
+ symlink would not benefit from rerere anyway, the command
+ now ignores conflicting changes to symlinks.
+
+ - 'git-repack' did not like to pass more than 64 arguments
+ internally to underlying 'rev-list' logic, which made it
+ impossible to repack after accumulating many (small) packs
+ in the repository.
+
+ - 'git-diff' to review the combined diff during a conflicted
+ merge were not reading the working tree version correctly
+ when changes to a symbolic link conflicted. It should have
+ read the data using readlink(2) but read from the regular
+ file the symbolic link pointed at.
+
+ - 'git-remote' did not like period in a remote's name.
+
+ - 'git.el' honors the commit coding system from the configuration.
+
+ - 'blameview' in contrib/ correctly digs deeper when a line is
+ clicked.
+
+ - 'http-push' correctly makes sure the remote side has leading
+ path. Earlier it started in the middle of the path, and
+ incorrectly.
+
+ - 'git-merge' did not exit with non-zero status when the
+ working tree was dirty and cannot fast forward. It does
+ now.
+
+ - 'cvsexportcommit' does not lose yet-to-be-used message file.
+
+ - int-vs-size_t typefix when running combined diff on files
+ over 2GB long.
+
+ - 'git apply --whitespace=strip' should not touch unmodified
+ lines.
+
+ - 'git-mailinfo' choke when a logical header line was too long.
+
+ - 'git show A..B' did not error out. Negative ref ("not A" in
+ this example) does not make sense for the purpose of the
+ command, so now it errors out.
+
+ - 'git fmt-merge-msg --file' without file parameter did not
+ correctly error out.
+
+ - 'git archimport' barfed upon encountering a commit without
+ summary.
+
+ - 'git index-pack' did not protect itself from getting a short
+ read out of pread(2).
+
+ - 'git http-push' had a few buffer overruns.
+
+ - Build dependency fixes to rebuild fetch.o when other headers
+ change.
+
+ - git.el does not add duplicate sign-off lines.
+
+ - git-commit shows the full stat of the resulting commit, not
+ just about the files in the current directory, when run from
+ a subdirectory.
+
+ - "git-checkout -m '@{8 hours ago}'" had a funny failure from
+ eval; fixed.
+
+ - git-merge (hence git-pull) did not refuse fast-forwarding
+ when the working tree had local changes that would have
+ conflicted with it.
+
+ - a handful small fixes to gitweb.
+
+ - build procedure for user-manual is fixed not to require locally
+ installed stylesheets.
+
+ - "git commit $paths" on paths whose earlier contents were
+ already updated in the index were failing out.
+
+
+* Tweaks
+
+ - sliding mmap() inefficiently mmaped the same region of a
+ packfile with an access pattern that used objects in the
+ reverse order. This has been made more efficient.
diff --git a/Documentation/RelNotes-1.5.2.1.txt b/Documentation/RelNotes-1.5.2.1.txt
new file mode 100644
index 0000000000..ebf20e22a7
--- /dev/null
+++ b/Documentation/RelNotes-1.5.2.1.txt
@@ -0,0 +1,53 @@
+GIT v1.5.2.1 Release Notes
+==========================
+
+Fixes since v1.5.2
+------------------
+
+* Bugfixes
+
+ - Temporary files that are used when invoking external diff
+ programs did not tolerate a long TMPDIR.
+
+ - git-daemon did not notice when it could not write into its
+ pid file.
+
+ - git-status did not honor core.excludesFile configuration like
+ git-add did.
+
+ - git-annotate did not work from a subdirectory while
+ git-blame did.
+
+ - git-cvsserver should have disabled access to a repository
+ with "gitcvs.pserver.enabled = false" set even when
+ "gitcvs.enabled = true" was set at the same time. It
+ didn't.
+
+ - git-cvsimport did not work correctly in a repository with
+ its branch heads were packed with pack-refs.
+
+ - ident unexpansion to squash "$Id: xxx $" that is in the
+ repository copy removed incorrect number of bytes.
+
+ - git-svn misbehaved when the subversion repository did not
+ provide MD5 checksums for files.
+
+ - git rebase (and git am) misbehaved on commits that have '\n'
+ (literally backslash and en, not a linefeed) in the title.
+
+ - code to decode base85 used in binary patches had one error
+ return codepath wrong.
+
+ - RFC2047 Q encoding output by git-format-patch used '_' for a
+ space, which is not understood by some programs. It uses =20
+ which is safer.
+
+ - git-fastimport --import-marks was broken; fixed.
+
+ - A lot of documentation updates, clarifications and fixes.
+
+--
+exec >/var/tmp/1
+O=v1.5.2-65-g996e2d6
+echo O=`git describe refs/heads/maint`
+git shortlog --no-merges $O..refs/heads/maint
diff --git a/Documentation/RelNotes-1.5.2.2.txt b/Documentation/RelNotes-1.5.2.2.txt
new file mode 100644
index 0000000000..f6393f8a94
--- /dev/null
+++ b/Documentation/RelNotes-1.5.2.2.txt
@@ -0,0 +1,61 @@
+GIT v1.5.2.2 Release Notes
+==========================
+
+Fixes since v1.5.2.1
+--------------------
+
+* Usability fix
+
+ - git-gui is shipped with its updated blame interface. It is
+ rumored that the older one was not just unusable but was
+ active health hazard, but this one is actually pretty.
+ Please see for yourself.
+
+* Bugfixes
+
+ - "git checkout fubar" was utterly confused when there is a
+ branch fubar and a tag fubar at the same time. It correctly
+ checks out the branch fubar now.
+
+ - "git clone /path/foo" to clone a local /path/foo.git
+ repository left an incorrect configuration.
+
+ - "git send-email" correctly unquotes RFC 2047 quoted names in
+ the patch-email before using their values.
+
+ - We did not accept number of seconds since epoch older than
+ year 2000 as a valid timestamp. We now interpret positive
+ integers more than 8 digits as such, which allows us to
+ express timestamps more recent than March 1973.
+
+ - git-cvsimport did not work when you have GIT_DIR to point
+ your repository at a nonstandard location.
+
+ - Some systems (notably, Solaris) lack hstrerror() to make
+ h_errno human readable; prepare a replacement
+ implementation.
+
+ - .gitignore file listed git-core.spec but what we generate is
+ git.spec, and nobody noticed for a long time.
+
+ - "git-merge-recursive" does not try to run file level merge
+ on binary files.
+
+ - "git-branch --track" did not create tracking configuration
+ correctly when the branch name had slash in it.
+
+ - The email address of the user specified with user.email
+ configuration was overriden by EMAIL environment variable.
+
+ - The tree parser did not warn about tree entries with
+ nonsense file modes, and assumed they must be blobs.
+
+ - "git log -z" without any other request to generate diff still
+ invoked the diff machinery, wasting cycles.
+
+* Documentation
+
+ - Many updates to fix stale or missing documentation.
+
+ - Although our documentation was primarily meant to be formatted
+ with AsciiDoc7, formatting with AsciiDoc8 is supported better.
diff --git a/Documentation/RelNotes-1.5.2.3.txt b/Documentation/RelNotes-1.5.2.3.txt
new file mode 100644
index 0000000000..addb22955b
--- /dev/null
+++ b/Documentation/RelNotes-1.5.2.3.txt
@@ -0,0 +1,27 @@
+GIT v1.5.2.3 Release Notes
+==========================
+
+Fixes since v1.5.2.2
+--------------------
+
+ * Bugfixes
+
+ - Version 2 pack index format was introduced in version 1.5.2
+ to support pack files that has offset that cannot be
+ represented in 32-bit. The runtime code to validate such
+ an index mishandled such an index for an empty pack.
+
+ - Commit walkers (most notably, fetch over http protocol)
+ tried to traverse commit objects contained in trees (aka
+ subproject); they shouldn't.
+
+ - A build option NO_R_TO_GCC_LINKER was not explained in Makefile
+ comment correctly.
+
+ * Documentation Fixes and Updates
+
+ - git-config --regexp was not documented properly.
+
+ - git-repack -a was not documented properly.
+
+ - git-remote -n was not documented properly.
diff --git a/Documentation/RelNotes-1.5.2.4.txt b/Documentation/RelNotes-1.5.2.4.txt
new file mode 100644
index 0000000000..75cff475f6
--- /dev/null
+++ b/Documentation/RelNotes-1.5.2.4.txt
@@ -0,0 +1,28 @@
+GIT v1.5.2.4 Release Notes
+==========================
+
+Fixes since v1.5.2.3
+--------------------
+
+ * Bugfixes
+
+ - "git-gui" bugfixes, including a handful fixes to run it
+ better on Cygwin/MSYS.
+
+ - "git checkout" failed to switch back and forth between
+ branches, one of which has "frotz -> xyzzy" symlink and
+ file "xyzzy/filfre", while the other one has a file
+ "frotz/filfre".
+
+ - "git prune" used to segfault upon seeing a commit that is
+ referred to by a tree object (aka "subproject").
+
+ - "git diff --name-status --no-index" mishandled an added file.
+
+ - "git apply --reverse --whitespace=warn" still complained
+ about whitespaces that a forward application would have
+ introduced.
+
+ * Documentation Fixes and Updates
+
+ - A handful documentation updates.
diff --git a/Documentation/RelNotes-1.5.2.5.txt b/Documentation/RelNotes-1.5.2.5.txt
new file mode 100644
index 0000000000..e8281c72a0
--- /dev/null
+++ b/Documentation/RelNotes-1.5.2.5.txt
@@ -0,0 +1,30 @@
+GIT v1.5.2.5 Release Notes
+==========================
+
+Fixes since v1.5.2.4
+--------------------
+
+ * Bugfixes
+
+ - "git add -u" had a serious data corruption problem in one
+ special case (when the changes to a subdirectory's files
+ consist only deletion of files).
+
+ - "git add -u <path>" did not work from a subdirectory.
+
+ - "git apply" left an empty directory after all its files are
+ renamed away.
+
+ - "git $anycmd foo/bar", when there is a file 'foo' in the
+ working tree, complained that "git $anycmd foo/bar --" form
+ should be used to disambiguate between revs and files,
+ which was completely bogus.
+
+ - "git checkout-index" and other commands that checks out
+ files to the work tree tried unlink(2) on directories,
+ which is a sane thing to do on sane systems, but not on
+ Solaris when you are root.
+
+ * Documentation Fixes and Updates
+
+ - A handful documentation fixes.
diff --git a/Documentation/RelNotes-1.5.2.txt b/Documentation/RelNotes-1.5.2.txt
new file mode 100644
index 0000000000..6195715dc7
--- /dev/null
+++ b/Documentation/RelNotes-1.5.2.txt
@@ -0,0 +1,197 @@
+GIT v1.5.2 Release Notes
+========================
+
+Updates since v1.5.1
+--------------------
+
+* Plumbing level superproject support.
+
+ You can include a subdirectory that has an independent git
+ repository in your index and tree objects of your project
+ ("superproject"). This plumbing (i.e. "core") level
+ superproject support explicitly excludes recursive behaviour.
+
+ The "subproject" entries in the index and trees of a superproject
+ are incompatible with older versions of git. Experimenting with
+ the plumbing level support is encouraged, but be warned that
+ unless everybody in your project updates to this release or
+ later, using this feature would make your project
+ inaccessible by people with older versions of git.
+
+* Plumbing level gitattributes support.
+
+ The gitattributes mechanism allows you to add 'attributes' to
+ paths in your project, and affect the way certain git
+ operations work. Currently you can influence if a path is
+ considered a binary or text (the former would be treated by
+ 'git diff' not to produce textual output; the latter can go
+ through the line endings conversion process in repositories
+ with core.autocrlf set), expand and unexpand '$Id$' keyword
+ with blob object name, specify a custom 3-way merge driver,
+ and specify a custom diff driver. You can also apply
+ arbitrary filter to contents on check-in/check-out codepath
+ but this feature is an extremely sharp-edged razor and needs
+ to be handled with caution (do not use it unless you
+ understand the earlier mailing list discussion on keyword
+ expansion). These conversions apply when checking files in
+ or out, and exporting via git-archive.
+
+* The packfile format now optionally suports 64-bit index.
+
+ This release supports the "version 2" format of the .idx
+ file. This is automatically enabled when a huge packfile
+ needs more than 32-bit to express offsets of objects in the
+ pack.
+
+* Comes with an updated git-gui 0.7.1
+
+* Updated gitweb:
+
+ - can show combined diff for merges;
+ - uses font size of user's preference, not hardcoded in pixels;
+ - can now 'grep';
+
+* New commands and options.
+
+ - "git bisect start" can optionally take a single bad commit and
+ zero or more good commits on the command line.
+
+ - "git shortlog" can optionally be told to wrap its output.
+
+ - "subtree" merge strategy allows another project to be merged in as
+ your subdirectory.
+
+ - "git format-patch" learned a new --subject-prefix=<string>
+ option, to override the built-in "[PATCH]".
+
+ - "git add -u" is a quick way to do the first stage of "git
+ commit -a" (i.e. update the index to match the working
+ tree); it obviously does not make a commit.
+
+ - "git clean" honors a new configuration, "clean.requireforce". When
+ set to true, this makes "git clean" a no-op, preventing you
+ from losing files by typing "git clean" when you meant to
+ say "make clean". You can still say "git clean -f" to
+ override this.
+
+ - "git log" family of commands learned --date={local,relative,default}
+ option. --date=relative is synonym to the --relative-date.
+ --date=local gives the timestamp in local timezone.
+
+* Updated behavior of existing commands.
+
+ - When $GIT_COMMITTER_EMAIL or $GIT_AUTHOR_EMAIL is not set
+ but $EMAIL is set, the latter is used as a substitute.
+
+ - "git diff --stat" shows size of preimage and postimage blobs
+ for binary contents. Earlier it only said "Bin".
+
+ - "git lost-found" shows stuff that are unreachable except
+ from reflogs.
+
+ - "git checkout branch^0" now detaches HEAD at the tip commit
+ on the named branch, instead of just switching to the
+ branch (use "git checkout branch" to switch to the branch,
+ as before).
+
+ - "git bisect next" can be used after giving only a bad commit
+ without giving a good one (this starts bisection half-way to
+ the root commit). We used to refuse to operate without a
+ good and a bad commit.
+
+ - "git push", when pushing into more than one repository, does
+ not stop at the first error.
+
+ - "git archive" does not insist you to give --format parameter
+ anymore; it defaults to "tar".
+
+ - "git cvsserver" can use backends other than sqlite.
+
+ - "gitview" (in contrib/ section) learned to better support
+ "git-annotate".
+
+ - "git diff $commit1:$path2 $commit2:$path2" can now report
+ mode changes between the two blobs.
+
+ - Local "git fetch" from a repository whose object store is
+ one of the alternates (e.g. fetching from the origin in a
+ repository created with "git clone -l -s") avoids
+ downloading objects unnecessarily.
+
+ - "git blame" uses .mailmap to canonicalize the author name
+ just like "git shortlog" does.
+
+ - "git pack-objects" pays attention to pack.depth
+ configuration variable.
+
+ - "git cherry-pick" and "git revert" does not use .msg file in
+ the working tree to prepare commit message; instead it uses
+ $GIT_DIR/MERGE_MSG as other commands do.
+
+* Builds
+
+ - git-p4import has never been installed; now there is an
+ installation option to do so.
+
+ - gitk and git-gui can be configured out.
+
+ - Generated documentation pages automatically get version
+ information from GIT_VERSION.
+
+ - Parallel build with "make -j" descending into subdirectory
+ was fixed.
+
+* Performance Tweaks
+
+ - Optimized "git-rev-list --bisect" (hence "git-bisect").
+
+ - Optimized "git-add $path" in a large directory, most of
+ whose contents are ignored.
+
+ - Optimized "git-diff-tree" for reduced memory footprint.
+
+ - The recursive merge strategy updated a worktree file that
+ was changed identically in two branches, when one of them
+ renamed it. We do not do that when there is no rename, so
+ match that behaviour. This avoids excessive rebuilds.
+
+ - The default pack depth has been increased to 50, as the
+ recent addition of delta_base_cache makes deeper delta chains
+ much less expensive to access. Depending on the project, it was
+ reported that this reduces the resulting pack file by 10%
+ or so.
+
+
+Fixes since v1.5.1
+------------------
+
+All of the fixes in v1.5.1 maintenance series are included in
+this release, unless otherwise noted.
+
+* Bugfixes
+
+ - Switching branches with "git checkout" refused to work when
+ a path changes from a file to a directory between the
+ current branch and the new branch, in order not to lose
+ possible local changes in the directory that is being turned
+ into a file with the switch. We now allow such a branch
+ switch after making sure that there is no locally modified
+ file nor un-ignored file in the directory. This has not
+ been backported to 1.5.1.x series, as it is rather an
+ intrusive change.
+
+ - Merging branches that have a file in one and a directory in
+ another at the same path used to get quite confused. We
+ handle such a case a bit more carefully, even though that is
+ still left as a conflict for the user to sort out. This
+ will not be backported to 1.5.1.x series, as it is rather an
+ intrusive change.
+
+ - git-fetch had trouble with a remote with insanely large number
+ of refs.
+
+ - "git clean -d -X" now does not remove non-excluded directories.
+
+ - rebasing (without -m) a series that changes a symlink to a directory
+ in the middle of a path confused git-apply greatly and refused to
+ operate.
diff --git a/Documentation/RelNotes-1.5.3.1.txt b/Documentation/RelNotes-1.5.3.1.txt
new file mode 100644
index 0000000000..7ff546c743
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.1.txt
@@ -0,0 +1,10 @@
+GIT v1.5.3.1 Release Notes
+==========================
+
+Fixes since v1.5.3
+------------------
+
+This is solely to fix the generated RPM's dependencies. We used
+to have git-p4 package but we do not anymore. As suggested on
+the mailing list, this release makes git-core "Obsolete" git-p4,
+so that yum update would not complain.
diff --git a/Documentation/RelNotes-1.5.3.2.txt b/Documentation/RelNotes-1.5.3.2.txt
new file mode 100644
index 0000000000..4bbde3cab4
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.2.txt
@@ -0,0 +1,58 @@
+GIT v1.5.3.2 Release Notes
+==========================
+
+Fixes since v1.5.3.1
+--------------------
+
+ * git-push sent thin packs by default, which was not good for
+ the public distribution server (no point in saving transfer
+ while pushing; no point in making the resulting pack less
+ optimum).
+
+ * git-svn sometimes terminated with "Malformed network data" when
+ talking over svn:// protocol.
+
+ * git-send-email re-issued the same message-id about 10% of the
+ time if you fired off 30 messages within a single second.
+
+ * git-stash was not terminating the log message of commits it
+ internally creates with LF.
+
+ * git-apply failed to check the size of the patch hunk when its
+ beginning part matched the remainder of the preimage exactly,
+ even though the preimage recorded in the hunk was much larger
+ (therefore the patch should not have applied), leading to a
+ segfault.
+
+ * "git rm foo && git commit foo" complained that 'foo' needs to
+ be added first, instead of committing the removal, which was a
+ nonsense.
+
+ * git grep -c said "/dev/null: 0".
+
+ * git-add -u failed to recognize a blob whose type changed
+ between the index and the work tree.
+
+ * The limit to rename detection has been tightened a lot to
+ reduce performance problems with a huge change.
+
+ * cvsimport and svnimport barfed when the input tried to move
+ a tag.
+
+ * "git apply -pN" did not chop the right number of directories.
+
+ * "git svnimport" did not like SVN tags with funny characters in them.
+
+ * git-gui 0.8.3, with assorted fixes, including:
+
+ - font-chooser on X11 was unusable with large number of fonts;
+ - a diff that contained a deleted symlink made it barf;
+ - an untracked symbolic link to a directory made it fart;
+ - a file with % in its name made it vomit;
+
+
+Documentation updates
+---------------------
+
+User manual has been somewhat restructured. I think the new
+organization is much easier to read.
diff --git a/Documentation/RelNotes-1.5.3.3.txt b/Documentation/RelNotes-1.5.3.3.txt
new file mode 100644
index 0000000000..d213846951
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.3.txt
@@ -0,0 +1,31 @@
+GIT v1.5.3.3 Release Notes
+==========================
+
+Fixes since v1.5.3.2
+--------------------
+
+ * git-quiltimport did not like it when a patch described in the
+ series file does not exist.
+
+ * p4 importer missed executable bit in some cases.
+
+ * The default shell on some FreeBSD did not execute the
+ argument parsing code correctly and made git unusable.
+
+ * git-svn incorrectly spawned pager even when the user
+ explicitly asked not to.
+
+ * sample post-receive hook overquoted the envelope sender
+ value.
+
+ * git-am got confused when the patch contained a change that is
+ only about type and not contents.
+
+ * git-mergetool did not show our and their version of the
+ conflicted file when started from a subdirectory of the
+ project.
+
+ * git-mergetool did not pass correct options when invoking diff3.
+
+ * git-log sometimes invoked underlying "diff" machinery
+ unnecessarily.
diff --git a/Documentation/RelNotes-1.5.3.4.txt b/Documentation/RelNotes-1.5.3.4.txt
new file mode 100644
index 0000000000..b04b3a45a5
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.4.txt
@@ -0,0 +1,35 @@
+GIT v1.5.3.4 Release Notes
+==========================
+
+Fixes since v1.5.3.3
+--------------------
+
+ * Change to "git-ls-files" in v1.5.3.3 that was introduced to support
+ partial commit of removal better had a segfaulting bug, which was
+ diagnosed and fixed by Keith and Carl.
+
+ * Performance improvements for rename detection has been backported
+ from the 'master' branch.
+
+ * "git-for-each-ref --format='%(numparent)'" was not working
+ correctly at all, and --format='%(parent)' was not working for
+ merge commits.
+
+ * Sample "post-receive-hook" incorrectly sent out push
+ notification e-mails marked as "From: " the committer of the
+ commit that happened to be at the tip of the branch that was
+ pushed, not from the person who pushed.
+
+ * "git-remote" did not exit non-zero status upon error.
+
+ * "git-add -i" did not respond very well to EOF from tty nor
+ bogus input.
+
+ * "git-rebase -i" squash subcommand incorrectly made the
+ author of later commit the author of resulting commit,
+ instead of taking from the first one in the squashed series.
+
+ * "git-stash apply --index" was not documented.
+
+ * autoconfiguration learned that "ar" command is found as "gas" on
+ some systems.
diff --git a/Documentation/RelNotes-1.5.3.5.txt b/Documentation/RelNotes-1.5.3.5.txt
new file mode 100644
index 0000000000..7ff1d5d0d1
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.5.txt
@@ -0,0 +1,94 @@
+GIT v1.5.3.5 Release Notes
+==========================
+
+Fixes since v1.5.3.4
+--------------------
+
+ * Comes with git-gui 0.8.4.
+
+ * "git-config" silently ignored options after --list; now it will
+ error out with a usage message.
+
+ * "git-config --file" failed if the argument used a relative path
+ as it changed directories before opening the file.
+
+ * "git-config --file" now displays a proper error message if it
+ cannot read the file specified on the command line.
+
+ * "git-config", "git-diff", "git-apply" failed if run from a
+ subdirectory with relative GIT_DIR and GIT_WORK_TREE set.
+
+ * "git-blame" crashed if run during a merge conflict.
+
+ * "git-add -i" did not handle single line hunks correctly.
+
+ * "git-rebase -i" and "git-stash apply" failed if external diff
+ drivers were used for one or more files in a commit. They now
+ avoid calling the external diff drivers.
+
+ * "git-log --follow" did not work unless diff generation (e.g. -p)
+ was also requested.
+
+ * "git-log --follow -B" did not work at all. Fixed.
+
+ * "git-log -M -B" did not correctly handle cases of very large files
+ being renamed and replaced by very small files in the same commit.
+
+ * "git-log" printed extra newlines between commits when a diff
+ was generated internally (e.g. -S or --follow) but not displayed.
+
+ * "git-push" error message is more helpful when pushing to a
+ repository with no matching refs and none specified.
+
+ * "git-push" now respects + (force push) on wildcard refspecs,
+ matching the behavior of git-fetch.
+
+ * "git-filter-branch" now updates the working directory when it
+ has finished filtering the current branch.
+
+ * "git-instaweb" no longer fails on Mac OS X.
+
+ * "git-cvsexportcommit" didn't always create new parent directories
+ before trying to create new child directories. Fixed.
+
+ * "git-fetch" printed a scary (but bogus) error message while
+ fetching a tag that pointed to a tree or blob. The error did
+ not impact correctness, only user perception. The bogus error
+ is no longer printed.
+
+ * "git-ls-files --ignored" did not properly descend into non-ignored
+ directories that themselves contained ignored files if d_type
+ was not supported by the filesystem. This bug impacted systems
+ such as AFS. Fixed.
+
+ * Git segfaulted when reading an invalid .gitattributes file. Fixed.
+
+ * post-receive-email example hook was fixed for non-fast-forward
+ updates.
+
+ * Documentation updates for supported (but previously undocumented)
+ options of "git-archive" and "git-reflog".
+
+ * "make clean" no longer deletes the configure script that ships
+ with the git tarball, making multiple architecture builds easier.
+
+ * "git-remote show origin" spewed a warning message from Perl
+ when no remote is defined for the current branch via
+ branch.<name>.remote configuration settings.
+
+ * Building with NO_PERL_MAKEMAKER excessively rebuilt contents
+ of perl/ subdirectory by rewriting perl.mak.
+
+ * http.sslVerify configuration settings were not used in scripted
+ Porcelains.
+
+ * "git-add" leaked a bit of memory while scanning for files to add.
+
+ * A few workarounds to squelch false warnings from recent gcc have
+ been added.
+
+ * "git-send-pack $remote frotz" segfaulted when there is nothing
+ named 'frotz' on the local end.
+
+ * "git-rebase --interactive" did not handle its "--strategy" option
+ properly.
diff --git a/Documentation/RelNotes-1.5.3.6.txt b/Documentation/RelNotes-1.5.3.6.txt
new file mode 100644
index 0000000000..069a2b2cf9
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.6.txt
@@ -0,0 +1,48 @@
+GIT v1.5.3.6 Release Notes
+==========================
+
+Fixes since v1.5.3.5
+--------------------
+
+ * git-cvsexportcommit handles root commits better.
+
+ * git-svn dcommit used to clobber when sending a series of
+ patches.
+
+ * git-svn dcommit failed after attempting to rebase when
+ started with a dirty index; now it stops upfront.
+
+ * git-grep sometimes refused to work when your index was
+ unmerged.
+
+ * "git-grep -A1 -B2" acted as if it was told to run "git -A1 -B21".
+
+ * git-hash-object did not honor configuration variables, such as
+ core.compression.
+
+ * git-index-pack choked on a huge pack on 32-bit machines, even when
+ large file offsets are supported.
+
+ * atom feeds from git-web said "10" for the month of November.
+
+ * a memory leak in commit walker was plugged.
+
+ * When git-send-email inserted the original author's From:
+ address in body, it did not mark the message with
+ Content-type: as needed.
+
+ * git-revert and git-cherry-pick incorrectly refused to start
+ when the work tree was dirty.
+
+ * git-clean did not honor core.excludesfile configuration.
+
+ * git-add mishandled ".gitignore" files when applying them to
+ subdirectories.
+
+ * While importing a too branchy history, git-fastimport did not
+ honor delta depth limit properly.
+
+ * Support for zlib implementations that lack ZLIB_VERNUM and definition
+ of deflateBound() has been added.
+
+ * Quite a lot of documentation clarifications.
diff --git a/Documentation/RelNotes-1.5.3.7.txt b/Documentation/RelNotes-1.5.3.7.txt
new file mode 100644
index 0000000000..2f690616c8
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.7.txt
@@ -0,0 +1,45 @@
+GIT v1.5.3.7 Release Notes
+==========================
+
+Fixes since v1.5.3.6
+--------------------
+
+ * git-send-email added 8-bit contents to the payload without
+ marking it as 8-bit in a CTE header.
+
+ * "git-bundle create a.bndl HEAD" dereferenced the symref and
+ did not record the ref as 'HEAD'; this prevented a bundle
+ from being used as a normal source of git-clone.
+
+ * The code to reject nonsense command line of the form
+ "git-commit -a paths..." and "git-commit --interactive
+ paths..." were broken.
+
+ * Adding a signature that is not ASCII-only to an original
+ commit that is ASCII-only would make the result non-ASCII.
+ "git-format-patch -s" did not mark such a message correctly
+ with MIME encoding header.
+
+ * git-add sometimes did not mark the resulting index entry
+ stat-clean. This affected only cases when adding the
+ contents with the same length as the previously staged
+ contents, and the previous staging made the index entry
+ "racily clean".
+
+ * git-commit did not honor GIT_INDEX_FILE the user had in the
+ environment.
+
+ * When checking out a revision, git-checkout did not report where the
+ updated HEAD is if you happened to have a file called HEAD in the
+ work tree.
+
+ * "git-rev-list --objects" mishandled a tree that points at a
+ submodule.
+
+ * "git cvsimport" was not ready for packed refs that "git gc" can
+ produce and gave incorrect results.
+
+ * Many scripted Porcelains were confused when you happened to have a
+ file called "HEAD" in your work tree.
+
+Also it contains updates to the user manual and documentation.
diff --git a/Documentation/RelNotes-1.5.3.8.txt b/Documentation/RelNotes-1.5.3.8.txt
new file mode 100644
index 0000000000..0e3ff58a46
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.8.txt
@@ -0,0 +1,25 @@
+GIT v1.5.3.8 Release Notes
+==========================
+
+Fixes since v1.5.3.7
+--------------------
+
+ * Some documentation used "email.com" as an example domain.
+
+ * git-svn fix to handle funky branch and project names going over
+ http/https correctly.
+
+ * git-svn fix to tone down a needlessly alarming warning message.
+
+ * git-clone did not correctly report errors while fetching over http.
+
+ * git-send-email added redundant Message-Id: header to the outgoing
+ e-mail when the patch text already had one.
+
+ * a read-beyond-end-of-buffer bug in configuration file updater was fixed.
+
+ * git-grep used to show the same hit repeatedly for unmerged paths.
+
+ * After amending the patch title in "git-am -i", the command did not
+ report the patch it applied with the updated title.
+
diff --git a/Documentation/RelNotes-1.5.3.txt b/Documentation/RelNotes-1.5.3.txt
new file mode 100644
index 0000000000..d03894b926
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.txt
@@ -0,0 +1,366 @@
+GIT v1.5.3 Release Notes
+========================
+
+Updates since v1.5.2
+--------------------
+
+* The commit walkers other than http are officially deprecated,
+ but still supported for now.
+
+* The submodule support has Porcelain layer.
+
+ Note that the current submodule support is minimal and this is
+ deliberately so. A design decision we made is that operations
+ at the supermodule level do not recurse into submodules by
+ default. The expectation is that later we would add a
+ mechanism to tell git which submodules the user is interested
+ in, and this information might be used to determine the
+ recursive behaviour of certain commands (e.g. "git checkout"
+ and "git diff"), but currently we haven't agreed on what that
+ mechanism should look like. Therefore, if you use submodules,
+ you would probably need "git submodule update" on the
+ submodules you care about after running a "git checkout" at
+ the supermodule level.
+
+* There are a handful pack-objects changes to help you cope better
+ with repositories with pathologically large blobs in them.
+
+* For people who need to import from Perforce, a front-end for
+ fast-import is in contrib/fast-import/.
+
+* Comes with git-gui 0.8.2.
+
+* Comes with updated gitk.
+
+* New commands and options.
+
+ - "git log --date=<format>" can use more formats: iso8601, rfc2822.
+
+ - The hunk header output from "git diff" family can be customized
+ with the attributes mechanism. See gitattributes(5) for details.
+
+ - "git stash" allows you to quickly save away your work in
+ progress and replay it later on an updated state.
+
+ - "git rebase" learned an "interactive" mode that let you
+ pick and reorder which commits to rebuild.
+
+ - "git fsck" can save its findings in $GIT_DIR/lost-found, without a
+ separate invocation of "git lost-found" command. The blobs stored by
+ lost-found are stored in plain format to allow you to grep in them.
+
+ - $GIT_WORK_TREE environment variable can be used together with
+ $GIT_DIR to work in a subdirectory of a working tree that is
+ not located at "$GIT_DIR/..".
+
+ - Giving "--file=<file>" option to "git config" is the same as
+ running the command with GIT_CONFIG=<file> environment.
+
+ - "git log" learned a new option "--follow", to follow
+ renaming history of a single file.
+
+ - "git filter-branch" lets you rewrite the revision history of
+ specified branches. You can specify a number of filters to
+ modify the commits, files and trees.
+
+ - "git cvsserver" learned new options (--base-path, --export-all,
+ --strict-paths) inspired by "git daemon".
+
+ - "git daemon --base-path-relaxed" can help migrating a repository URL
+ that did not use to use --base-path to use --base-path.
+
+ - "git commit" can use "-t templatefile" option and commit.template
+ configuration variable to prime the commit message given to you in the
+ editor.
+
+ - "git submodule" command helps you manage the projects from
+ the superproject that contain them.
+
+ - In addition to core.compression configuration option,
+ core.loosecompression and pack.compression options can
+ independently tweak zlib compression levels used for loose
+ and packed objects.
+
+ - "git ls-tree -l" shows size of blobs pointed at by the
+ tree entries, similar to "/bin/ls -l".
+
+ - "git rev-list" learned --regexp-ignore-case and
+ --extended-regexp options to tweak its matching logic used
+ for --grep fitering.
+
+ - "git describe --contains" is a handier way to call more
+ obscure command "git name-rev --tags".
+
+ - "git gc --aggressive" tells the command to spend more cycles
+ to optimize the repository harder.
+
+ - "git repack" learned a "window-memory" limit which
+ dynamically reduces the window size to stay within the
+ specified memory usage.
+
+ - "git repack" can be told to split resulting packs to avoid
+ exceeding limit specified with "--max-pack-size".
+
+ - "git fsck" gained --verbose option. This is really really
+ verbose but it might help you identify exact commit that is
+ corrupt in your repository.
+
+ - "git format-patch" learned --numbered-files option. This
+ may be useful for MH users.
+
+ - "git format-patch" learned format.subjectprefix configuration
+ variable, which serves the same purpose as "--subject-prefix"
+ option.
+
+ - "git tag -n -l" shows tag annotations while listing tags.
+
+ - "git cvsimport" can optionally use the separate-remote layout.
+
+ - "git blame" can be told to see through commits that change
+ whitespaces and indentation levels with "-w" option.
+
+ - "git send-email" can be told not to thread the messages when
+ sending out more than one patches.
+
+ - "git send-email" can also be told how to find whom to cc the
+ message to for each message via --cc-cmd.
+
+ - "git config" learned NUL terminated output format via -z to
+ help scripts.
+
+ - "git add" learned "--refresh <paths>..." option to selectively refresh
+ the cached stat information.
+
+ - "git init -q" makes the command quieter.
+
+ - "git -p command" now has a cousin of opposite sex, "git --no-pager
+ command".
+
+* Updated behavior of existing commands.
+
+ - "gitweb" can offer multiple snapshot formats.
+
+ ***NOTE*** Unfortunately, this changes the format of the
+ $feature{snapshot}{default} entry in the per-site
+ configuration file 'gitweb_config.perl'. It used to be a
+ three-element tuple that describe a single format; with the
+ new configuration item format, you only have to say the name
+ of the format ('tgz', 'tbz2' or 'zip'). Please update the
+ your configuration file accordingly.
+
+ - "git clone" uses -l (hardlink files under .git) by default when
+ cloning locally.
+
+ - URL used for "git clone" and friends can specify nonstandard SSH port
+ by using ssh://host:port/path/to/repo syntax.
+
+ - "git bundle create" can now create a bundle without negative refs,
+ i.e. "everything since the beginning up to certain points".
+
+ - "git diff" (but not the plumbing level "git diff-tree") now
+ recursively descends into trees by default.
+
+ - "git diff" does not show differences that come only from
+ stat-dirtiness in the form of "diff --git" header anymore.
+ It runs "update-index --refresh" silently as needed.
+
+ - "git tag -l" used to match tags by globbing its parameter as if it
+ has wildcard '*' on both ends, which made "git tag -l gui" to match
+ tag 'gitgui-0.7.0'; this was very annoying. You now have to add
+ asterisk on the sides you want to wildcard yourself.
+
+ - The editor to use with many interactive commands can be
+ overridden with GIT_EDITOR environment variable, or if it
+ does not exist, with core.editor configuration variable. As
+ before, if you have neither, environment variables VISUAL
+ and EDITOR are consulted in this order, and then finally we
+ fall back on "vi".
+
+ - "git rm --cached" does not complain when removing a newly
+ added file from the index anymore.
+
+ - Options to "git log" to affect how --grep/--author options look for
+ given strings now have shorter abbreviations. -i is for ignore case,
+ and -E is for extended regexp.
+
+ - "git log" learned --log-size to show the number of bytes in
+ the log message part of the output to help qgit.
+
+ - "git log --name-status" does not require you to give "-r" anymore.
+ As a general rule, Porcelain commands should recurse when showing
+ diff.
+
+ - "git format-patch --root A" can be used to format everything
+ since the beginning up to A. This was supported with
+ "git format-patch --root A A" for a long time, but was not
+ properly documented.
+
+ - "git svn dcommit" retains local merge information.
+
+ - "git svnimport" allows an empty string to be specified as the
+ trunk/ directory. This is necessary to suck data from a SVN
+ repository that doe not have trunk/ branches/ and tags/ organization
+ at all.
+
+ - "git config" to set values also honors type flags like --bool
+ and --int.
+
+ - core.quotepath configuration can be used to make textual git
+ output to emit most of the characters in the path literally.
+
+ - "git mergetool" chooses its backend more wisely, taking
+ notice of its environment such as use of X, Gnome/KDE, etc.
+
+ - "gitweb" shows merge commits a lot nicer than before. The
+ default view uses more compact --cc format, while the UI
+ allows to choose normal diff with any parent.
+
+ - snapshot files "gitweb" creates from a repository at
+ $path/$project/.git are more useful. We use $project part
+ in the filename, which we used to discard.
+
+ - "git cvsimport" creates lightweight tags; there is no
+ interesting information we can record in an annotated tag,
+ and the handcrafted ones the old code created was not
+ properly formed anyway.
+
+ - "git push" pretends that you immediately fetched back from
+ the remote by updating corresponding remote tracking
+ branches if you have any.
+
+ - The diffstat given after a merge (or a pull) honors the
+ color.diff configuration.
+
+ - "git commit --amend" is now compatible with various message source
+ options such as -m/-C/-c/-F.
+
+ - "git apply --whitespace=strip" removes blank lines added at
+ the end of the file.
+
+ - "git fetch" over git native protocols with "-v" option shows
+ connection status, and the IP address of the other end, to
+ help diagnosing problems.
+
+ - We used to have core.legacyheaders configuration, when
+ set to false, allowed git to write loose objects in a format
+ that mimicks the format used by objects stored in packs. It
+ turns out that this was not so useful. Although we will
+ continue to read objects written in that format, we do not
+ honor that configuration anymore and create loose objects in
+ the legacy/traditional format.
+
+ - "--find-copies-harder" option to diff family can now be
+ spelled as "-C -C" for brevity.
+
+ - "git mailsplit" (hence "git am") can read from Maildir
+ formatted mailboxes.
+
+ - "git cvsserver" does not barf upon seeing "cvs login"
+ request.
+
+ - "pack-objects" honors "delta" attribute set in
+ .gitattributes. It does not attempt to deltify blobs that
+ come from paths with delta attribute set to false.
+
+ - "new-workdir" script (in contrib) can now be used with a
+ bare repository.
+
+ - "git mergetool" learned to use gvimdiff.
+
+ - "gitview" (in contrib) has a better blame interface.
+
+ - "git log" and friends did not handle a commit log message
+ that is larger than 16kB; they do now.
+
+ - "--pretty=oneline" output format for "git log" and friends
+ deals with "malformed" commit log messages that have more
+ than one lines in the first paragraph better. We used to
+ show the first line, cutting the title at mid-sentence; we
+ concatenate them into a single line and treat the result as
+ "oneline".
+
+ - "git p4import" has been demoted to contrib status. For
+ a superior option, checkout the "git p4" front end to
+ "git fast-import" (also in contrib). The man page and p4
+ rpm have been removed as well.
+
+ - "git mailinfo" (hence "am") now tries to see if the message
+ is in utf-8 first, instead of assuming iso-8859-1, if
+ incoming e-mail does not say what encoding it is in.
+
+* Builds
+
+ - old-style function definitions (most notably, a function
+ without parameter defined with "func()", not "func(void)")
+ have been eradicated.
+
+ - "git tag" and "git verify-tag" have been rewritten in C.
+
+* Performance Tweaks
+
+ - "git pack-objects" avoids re-deltification cost by caching
+ small enough delta results it creates while looking for the
+ best delta candidates.
+
+ - "git pack-objects" learned a new heuristcs to prefer delta
+ that is shallower in depth over the smallest delta
+ possible. This improves both overall packfile access
+ performance and packfile density.
+
+ - diff-delta code that is used for packing has been improved
+ to work better on big files.
+
+ - when there are more than one pack files in the repository,
+ the runtime used to try finding an object always from the
+ newest packfile; it now tries the same packfile as we found
+ the object requested the last time, which exploits the
+ locality of references.
+
+ - verifying pack contents done by "git fsck --full" got boost
+ by carefully choosing the order to verify objects in them.
+
+ - "git read-tree -m" to read into an already populated index
+ has been optimized vastly. The effect of this can be seen
+ when switching branches that have differences in only a
+ handful paths.
+
+ - "git add paths..." and "git commit paths..." has also been
+ heavily optimized.
+
+Fixes since v1.5.2
+------------------
+
+All of the fixes in v1.5.2 maintenance series are included in
+this release, unless otherwise noted.
+
+* Bugfixes
+
+ - "gitweb" had trouble handling non UTF-8 text with older
+ Encode.pm Perl module.
+
+ - "git svn" misparsed the data from the commits in the repository when
+ the user had "color.diff = true" in the configuration. This has been
+ fixed.
+
+ - There was a case where "git svn dcommit" clobbered changes made on the
+ SVN side while committing multiple changes.
+
+ - "git-write-tree" had a bad interaction with racy-git avoidance and
+ gitattributes mechanisms.
+
+ - "git --bare command" overrode existing GIT_DIR setting and always
+ made it treat the current working directory as GIT_DIR.
+
+ - "git ls-files --error-unmatch" does not complain if you give the
+ same path pattern twice by mistake.
+
+ - "git init" autodetected core.filemode but not core.symlinks, which
+ made a new directory created automatically by "git clone" cumbersome
+ to use on filesystems that require these configurations to be set.
+
+ - "git log" family of commands behaved differently when run as "git
+ log" (no pathspec) and as "git log --" (again, no pathspec). This
+ inconsistency was introduced somewhere in v1.3.0 series but now has
+ been corrected.
+
+ - "git rebase -m" incorrectly displayed commits that were skipped.
diff --git a/Documentation/RelNotes-1.5.4.1.txt b/Documentation/RelNotes-1.5.4.1.txt
new file mode 100644
index 0000000000..d4e44b8b09
--- /dev/null
+++ b/Documentation/RelNotes-1.5.4.1.txt
@@ -0,0 +1,17 @@
+GIT v1.5.4.1 Release Notes
+==========================
+
+Fixes since v1.5.4
+------------------
+
+ * "git-commit -C $tag" used to work but rewrite in C done in
+ 1.5.4 broke it.
+
+ * An entry in the .gitattributes file that names a pattern in a
+ subdirectory of the directory it is in did not match
+ correctly (e.g. pattern "b/*.c" in "a/.gitattributes" should
+ match "a/b/foo.c" but it didn't).
+
+ * Customized color specification was parsed incorrectly when
+ numeric color values are used. This was fixed in 1.5.4.1.
+
diff --git a/Documentation/RelNotes-1.5.4.2.txt b/Documentation/RelNotes-1.5.4.2.txt
new file mode 100644
index 0000000000..21d0df59fb
--- /dev/null
+++ b/Documentation/RelNotes-1.5.4.2.txt
@@ -0,0 +1,43 @@
+GIT v1.5.4.2 Release Notes
+==========================
+
+Fixes since v1.5.4
+------------------
+
+ * The configuration parser was not prepared to see string
+ valued variables misspelled as boolean and segfaulted.
+
+ * Temporary files left behind due to interrupted object
+ transfers were not cleaned up with "git prune".
+
+ * "git config --unset" was confused when the unset variables
+ were spelled with continuation lines in the config file.
+
+ * The merge message detection in "git cvsimport" did not catch
+ a message that began with "Merge...".
+
+ * "git status" suggests "git rm --cached" for unstaging the
+ earlier "git add" before the initial commit.
+
+ * "git status" output was incorrect during a partial commit.
+
+ * "git bisect" refused to start when the HEAD was detached.
+
+ * "git bisect" allowed a wildcard character in the commit
+ message expanded while writing its log file.
+
+ * Manual pages were not formatted correctly with docbook xsl
+ 1.72; added a workaround.
+
+ * "git-commit -C $tag" used to work but rewrite in C done in
+ 1.5.4 broke it. This was fixed in 1.5.4.1.
+
+ * An entry in the .gitattributes file that names a pattern in a
+ subdirectory of the directory it is in did not match
+ correctly (e.g. pattern "b/*.c" in "a/.gitattributes" should
+ match "a/b/foo.c" but it didn't). This was fixed in 1.5.4.1.
+
+ * Customized color specification was parsed incorrectly when
+ numeric color values are used. This was fixed in 1.5.4.1.
+
+ * http transport misbehaved when linked with curl-gnutls.
diff --git a/Documentation/RelNotes-1.5.4.3.txt b/Documentation/RelNotes-1.5.4.3.txt
new file mode 100644
index 0000000000..b0fc67fb2a
--- /dev/null
+++ b/Documentation/RelNotes-1.5.4.3.txt
@@ -0,0 +1,27 @@
+GIT v1.5.4.3 Release Notes
+==========================
+
+Fixes since v1.5.4.2
+--------------------
+
+ * RPM spec used to pull in everything with 'git'. This has been
+ changed so that 'git' package contains just the core parts,
+ and we now supply 'git-all' metapackage to slurp in everything.
+ This should match end user's expectation better.
+
+ * When some refs failed to update, git-push reported "failure"
+ which was unclear if some other refs were updated or all of
+ them failed atomically (the answer is the former). Reworded
+ the message to clarify this.
+
+ * "git clone" from a repository whose HEAD was misconfigured
+ did not set up the remote properly. Now it tries to do
+ better.
+
+ * Updated git-push documentation to clarify what "matching"
+ means, in order to reduce user confusion.
+
+ * Updated git-add documentation to clarify "add -u" operates in
+ the current subdirectory you are in, just like other commands.
+
+ * git-gui updates to work on OSX and Windows better.
diff --git a/Documentation/RelNotes-1.5.4.4.txt b/Documentation/RelNotes-1.5.4.4.txt
new file mode 100644
index 0000000000..89fa6d03bc
--- /dev/null
+++ b/Documentation/RelNotes-1.5.4.4.txt
@@ -0,0 +1,66 @@
+GIT v1.5.4.4 Release Notes
+==========================
+
+Fixes since v1.5.4.3
+--------------------
+
+ * Building and installing with an overtight umask such as 077 made
+ installed templates unreadable by others, while the rest of the install
+ are done in a way that is friendly to umask 022.
+
+ * "git cvsexportcommit -w $cvsdir" misbehaved when GIT_DIR is set to a
+ relative directory.
+
+ * "git http-push" had an invalid memory access that could lead it to
+ segfault.
+
+ * When "git rebase -i" gave control back to the user for a commit that is
+ marked to be edited, it just said "modify it with commit --amend",
+ without saying what to do to continue after modifying it. Give an
+ explicit instruction to run "rebase --continue" to be more helpful.
+
+ * "git send-email" in 1.5.4.3 issued a bogus empty In-Reply-To: header.
+
+ * "git bisect" showed mysterious "won't bisect on seeked tree" error message.
+ This was leftover from Cogito days to prevent "bisect" starting from a
+ cg-seeked state. We still keep the Cogito safety, but running "git bisect
+ start" when another bisect was in effect will clean up and start over.
+
+ * "git push" with an explicit PATH to receive-pack did not quite work if
+ receive-pack was not on usual PATH. We earlier fixed the same issue
+ with "git fetch" and upload-pack, but somehow forgot to do so in the
+ other direction.
+
+ * git-gui's info dialog was not displayed correctly when the user tries
+ to commit nothing (i.e. without staging anything).
+
+ * "git revert" did not properly fail when attempting to run with a
+ dirty index.
+
+ * "git merge --no-commit --no-ff <other>" incorrectly made commits.
+
+ * "git merge --squash --no-ff <other>", which is a nonsense combination
+ of options, was not rejected.
+
+ * "git ls-remote" and "git remote show" against an empty repository
+ failed, instead of just giving an empty result (regression).
+
+ * "git fast-import" did not handle a renamed path whose name needs to be
+ quoted, due to a bug in unquote_c_style() function.
+
+ * "git cvsexportcommit" was confused when multiple files with the same
+ basename needed to be pushed out in the same commit.
+
+ * "git daemon" did not send early errors to syslog.
+
+ * "git log --merge" did not work well with --left-right option.
+
+ * "git svn" promprted for client cert password every time it accessed the
+ server.
+
+ * The reset command in "git fast-import" data stream was documented to
+ end with an optional LF, but it actually required one.
+
+ * "git svn dcommit/rebase" did not honor --rewrite-root option.
+
+Also included are a handful documentation updates.
diff --git a/Documentation/RelNotes-1.5.4.5.txt b/Documentation/RelNotes-1.5.4.5.txt
new file mode 100644
index 0000000000..0282341398
--- /dev/null
+++ b/Documentation/RelNotes-1.5.4.5.txt
@@ -0,0 +1,56 @@
+GIT v1.5.4.5 Release Notes
+==========================
+
+Fixes since v1.5.4.4
+--------------------
+
+ * "git fetch there" when the URL information came from the Cogito style
+ branches/there file did not update refs/heads/there (regression in
+ 1.5.4).
+
+ * Bogus refspec configuration such as "remote.there.fetch = =" were not
+ detected as errors (regressionin 1.5.4).
+
+ * You couldn't specify a custom editor whose path contains a whitespace
+ via GIT_EDITOR (and core.editor).
+
+ * The subdirectory filter to "git filter-branch" mishandled a history
+ where the subdirectory becomes empty and then later becomes non-empty.
+
+ * "git shortlog" gave an empty line if the original commit message was
+ malformed (e.g. a botched import from foreign SCM). Now it finds the
+ first non-empty line and uses it for better information.
+
+ * When the user fails to give a revision parameter to "git svn", an error
+ from the Perl interpreter was issued because the script lacked proper
+ error checking.
+
+ * After "git rebase" stopped due to conflicts, if the user played with
+ "git reset" and friends, "git rebase --abort" failed to go back to the
+ correct commit.
+
+ * Additional work trees prepared with git-new-workdir (in contrib/) did
+ not share git-svn metadata directory .git/svn with the original.
+
+ * "git-merge-recursive" did not mark addition of the same path with
+ different filemodes correctly as a conflict.
+
+ * "gitweb" gave malformed URL when pathinfo stype paths are in use.
+
+ * "-n" stands for "--no-tags" again for "git fetch".
+
+ * "git format-patch" did not detect the need to add 8-bit MIME header
+ when the user used format.header configuration.
+
+ * "rev~" revision specifier used to mean "rev", which was inconsistent
+ with how "rev^" worked. Now "rev~" is the same as "rev~1" (hence it
+ also is the same as "rev^1"), and "rev~0" is the same as "rev^0"
+ (i.e. it has to be a commit).
+
+ * "git quiltimport" did not grok empty lines, lines in "file -pNNN"
+ format to specify the prefix levels and lines with trailing comments.
+
+ * "git rebase -m" triggered pre-commit verification, which made
+ "rebase --continue" impossible.
+
+As usual, it also comes with many documentation fixes and clarifications.
diff --git a/Documentation/RelNotes-1.5.4.txt b/Documentation/RelNotes-1.5.4.txt
new file mode 100644
index 0000000000..f1323b6174
--- /dev/null
+++ b/Documentation/RelNotes-1.5.4.txt
@@ -0,0 +1,377 @@
+GIT v1.5.4 Release Notes
+========================
+
+Removal
+-------
+
+ * "git svnimport" was removed in favor of "git svn". It is still there
+ in the source tree (contrib/examples) but unsupported.
+
+ * As git-commit and git-status have been rewritten, "git runstatus"
+ helper script lost all its users and has been removed.
+
+
+Temporarily disabled
+--------------------
+
+ * "git http-push" is known not to work well with cURL library older
+ than 7.16, and we had reports of repository corruption. It is
+ disabled on such platforms for now. Unfortunately, 1.5.3.8 shares
+ the same issue. In other words, this does not mean you will be
+ fine if you stick to an older git release. For now, please do not
+ use http-push from older git with cURL older than 7.16 if you
+ value your data. A proper fix will hopefully materialize in
+ later versions.
+
+
+Deprecation notices
+-------------------
+
+ * From v1.6.0, git will by default install dashed form of commands
+ (e.g. "git-commit") outside of users' normal $PATH, and will install
+ only selected commands ("git" itself, and "gitk") in $PATH. This
+ implies:
+
+ - Using dashed forms of git commands (e.g. "git-commit") from the
+ command line has been informally deprecated since early 2006, but
+ now it officially is, and will be removed in the future. Use
+ dash-less forms (e.g. "git commit") instead.
+
+ - Using dashed forms from your scripts, without first prepending the
+ return value from "git --exec-path" to the scripts' PATH, has been
+ informally deprecated since early 2006, but now it officially is.
+
+ - Use of dashed forms with "PATH=$(git --exec-path):$PATH; export
+ PATH" early in your script is not deprecated with this change.
+
+ Users are strongly encouraged to adjust their habits and scripts now
+ to prepare for this change.
+
+ * The post-receive hook was introduced in March 2007 to supersede
+ the post-update hook, primarily to overcome the command line length
+ limitation of the latter. Use of post-update hook will be deprecated
+ in future versions of git, starting from v1.6.0.
+
+ * "git lost-found" was deprecated in favor of "git fsck"'s --lost-found
+ option, and will be removed in the future.
+
+ * "git peek-remote" is deprecated, as "git ls-remote" was written in C
+ and works for all transports; "git peek-remote" will be removed in
+ the future.
+
+ * "git repo-config" which was an old name for "git config" command
+ has been supported without being advertised for a long time. The
+ next feature release will remove it.
+
+ * From v1.6.0, the repack.usedeltabaseoffset config option will default
+ to true, which will give denser packfiles (i.e. more efficient storage).
+ The downside is that git older than version 1.4.4 will not be able
+ to directly use a repository packed using this setting.
+
+ * From v1.6.0, the pack.indexversion config option will default to 2,
+ which is slightly more efficient, and makes repacking more immune to
+ data corruptions. Git older than version 1.5.2 may revert to version 1
+ of the pack index with a manual "git index-pack" to be able to directly
+ access corresponding pack files.
+
+
+Updates since v1.5.3
+--------------------
+
+ * Comes with much improved gitk, with i18n.
+
+ * Comes with git-gui 0.9.2 with i18n.
+
+ * gitk is now merged as a subdirectory of git.git project, in
+ preparation for its i18n.
+
+ * progress displays from many commands are a lot nicer to the eye.
+ Transfer commands show throughput data.
+
+ * many commands that pay attention to per-directory .gitignore now do
+ so lazily, which makes the usual case go much faster.
+
+ * Output processing for '--pretty=format:<user format>' has been
+ optimized.
+
+ * Rename detection of diff family while detecting exact matches has
+ been greatly optimized.
+
+ * Rename detection of diff family tries to make more natural looking
+ pairing. Earlier, if multiple identical rename sources were
+ found in the preimage, the source used was picked pretty much at random.
+
+ * Value "true" for color.diff and color.status configuration used to
+ mean "always" (even when the output is not going to a terminal).
+ This has been corrected to mean the same thing as "auto".
+
+ * "git diff" Porcelain now respects diff.external configuration, which
+ is another way to specify GIT_EXTERNAL_DIFF.
+
+ * "git diff" can be told to use different prefixes other than
+ "a/" and "b/" e.g. "git diff --src-prefix=l/ --dst-prefix=k/".
+
+ * "git diff" sometimes did not quote paths with funny
+ characters properly.
+
+ * "git log" (and any revision traversal commands) misbehaved
+ when --diff-filter is given but was not asked to actually
+ produce diff.
+
+ * HTTP proxy can be specified per remote repository using
+ remote.*.httpproxy configuration, or global http.proxy configuration
+ variable.
+
+ * Various Perforce importer updates.
+
+ * Example update and post-receive hooks have been improved.
+
+ * Any command that wants to take a commit object name can now use
+ ":/string" syntax to name a commit.
+
+ * "git reset" is now built-in and its output can be squelched with -q.
+
+ * "git reset --hard" does not make any sense in a bare
+ repository, but did not error out; fixed.
+
+ * "git send-email" can optionally talk over ssmtp and use SMTP-AUTH.
+
+ * "git rebase" learned --whitespace option.
+
+ * In "git rebase", when you decide not to replay a particular change
+ after the command stopped with a conflict, you can say "git rebase
+ --skip" without first running "git reset --hard", as the command now
+ runs it for you.
+
+ * "git rebase --interactive" mode can now work on detached HEAD.
+
+ * Other minor to serious bugs in "git rebase -i" have been fixed.
+
+ * "git rebase" now detaches head during its operation, so after a
+ successful "git rebase" operation, the reflog entry branch@{1} for
+ the current branch points at the commit before the rebase was
+ started.
+
+ * "git rebase -i" also triggers rerere to help your repeated merges.
+
+ * "git merge" can call the "post-merge" hook.
+
+ * "git pack-objects" can optionally run deltification with multiple
+ threads.
+
+ * "git archive" can optionally substitute keywords in files marked with
+ export-subst attribute.
+
+ * "git cherry-pick" made a misguided attempt to repeat the original
+ command line in the generated log message, when told to cherry-pick a
+ commit by naming a tag that points at it. It does not anymore.
+
+ * "git for-each-ref" learned %(xxxdate:<date-format>) syntax to show the
+ various date fields in different formats.
+
+ * "git gc --auto" is a low-impact way to automatically run a variant of
+ "git repack" that does not lose unreferenced objects (read: safer
+ than the usual one) after the user accumulates too many loose
+ objects.
+
+ * "git clean" has been rewritten in C.
+
+ * You need to explicitly set clean.requireForce to "false" to allow
+ "git clean" without -f to do any damage (lack of the configuration
+ variable used to mean "do not require -f option to lose untracked
+ files", but we now use the safer default).
+
+ * The kinds of whitespace errors "git diff" and "git apply" notice (and
+ fix) can be controlled via 'core.whitespace' configuration variable
+ and 'whitespace' attribute in .gitattributes file.
+
+ * "git push" learned --dry-run option to show what would happen if a
+ push is run.
+
+ * "git push" does not update a tracking ref on the local side when the
+ remote refused to update the corresponding ref.
+
+ * "git push" learned --mirror option. This is to push the local refs
+ one-to-one to the remote, and deletes refs from the remote that do
+ not exist anymore in the repository on the pushing side.
+
+ * "git push" can remove a corrupt ref at the remote site with the usual
+ ":ref" refspec.
+
+ * "git remote" knows --mirror mode. This is to set up configuration to
+ push into a remote repository to store local branch heads to the same
+ branch on the remote side, and remove branch heads locally removed
+ from local repository at the same time. Suitable for pushing into a
+ back-up repository.
+
+ * "git remote" learned "rm" subcommand.
+
+ * "git cvsserver" can be run via "git shell". Also, "cvs" is
+ recognized as a synonym for "git cvsserver", so that CVS users
+ can be switched to git just by changing their login shell.
+
+ * "git cvsserver" acts more like receive-pack by running post-receive
+ and post-update hooks.
+
+ * "git am" and "git rebase" are far less verbose.
+
+ * "git pull" learned to pass --[no-]ff option to underlying "git
+ merge".
+
+ * "git pull --rebase" is a different way to integrate what you fetched
+ into your current branch.
+
+ * "git fast-export" produces data-stream that can be fed to fast-import
+ to reproduce the history recorded in a git repository.
+
+ * "git add -i" takes pathspecs to limit the set of files to work on.
+
+ * "git add -p" is a short-hand to go directly to the selective patch
+ subcommand in the interactive command loop and to exit when done.
+
+ * "git add -i" UI has been colorized. The interactive prompt
+ and menu can be colored by setting color.interactive
+ configuration. The diff output (including the hunk picker)
+ are colored with color.diff configuration.
+
+ * "git commit --allow-empty" allows you to create a single-parent
+ commit that records the same tree as its parent, overriding the usual
+ safety valve.
+
+ * "git commit --amend" can amend a merge that does not change the tree
+ from its first parent.
+
+ * "git commit" used to unconditionally strip comment lines that
+ began with '#' and removed excess blank lines. This behavior has
+ been made configurable.
+
+ * "git commit" has been rewritten in C.
+
+ * "git stash random-text" does not create a new stash anymore. It was
+ a UI mistake. Use "git stash save random-text", or "git stash"
+ (without extra args) for that.
+
+ * "git stash clear extra-text" does not clear the whole stash
+ anymore. It is tempting to expect "git stash clear stash@{2}"
+ to drop only a single named stash entry, and it is rude to
+ discard everything when that is asked (but not provided).
+
+ * "git prune --expire <time>" can exempt young loose objects from
+ getting pruned.
+
+ * "git branch --contains <commit>" can list branches that are
+ descendants of a given commit.
+
+ * "git log" learned --early-output option to help interactive GUI
+ implementations.
+
+ * "git bisect" learned "skip" action to mark untestable commits.
+
+ * "git bisect visualize" learned a shorter synonym "git bisect view".
+
+ * "git bisect visualize" runs "git log" in a non-windowed
+ environments. It also can be told what command to run (e.g. "git
+ bisect visualize tig").
+
+ * "git format-patch" learned "format.numbered" configuration variable
+ to automatically turn --numbered option on when more than one commits
+ are formatted.
+
+ * "git ls-files" learned "--exclude-standard" to use the canned set of
+ exclude files.
+
+ * "git tag -a -f existing" begins the editor session using the existing
+ annotation message.
+
+ * "git tag -m one -m bar" (multiple -m options) behaves similarly to
+ "git commit"; the parameters to -m options are formatted as separate
+ paragraphs.
+
+ * The format "git show" outputs an annotated tag has been updated to
+ include "Tagger: " and "Date: " lines from the tag itself. Strictly
+ speaking this is a backward incompatible change, but this is a
+ reasonable usability fix and people's scripts shouldn't have been
+ relying on the exact output from "git show" Porcelain anyway.
+
+ * "git cvsimport" did not notice errors from underlying "cvsps"
+ and produced a corrupt import silently.
+
+ * "git cvsexportcommit" learned -w option to specify and switch to the
+ CVS working directory.
+
+ * "git checkout" from a subdirectory learned to use "../path" to allow
+ checking out a path outside the current directory without cd'ing up.
+
+ * "git checkout" from and to detached HEAD leaves a bit more
+ information in the reflog.
+
+ * "git send-email --dry-run" shows full headers for easier diagnosis.
+
+ * "git merge-ours" is now built-in.
+
+ * "git svn" learned "info" and "show-externals" subcommands.
+
+ * "git svn" run from a subdirectory failed to read settings from the
+ .git/config.
+
+ * "git svn" learned --use-log-author option, which picks up more
+ descriptive name from From: and Signed-off-by: lines in the commit
+ message.
+
+ * "git svn" wasted way too much disk to record revision mappings
+ between svn and git; a new representation that is much more compact
+ for this information has been introduced to correct this.
+
+ * "git svn" left temporary index files it used without cleaning them
+ up; this was corrected.
+
+ * "git status" from a subdirectory now shows relative paths, which
+ makes copy-and-pasting for git-checkout/git-add/git-rm easier. The
+ traditional behavior to show the full path relative to the top of
+ the work tree can be had by setting status.relativepaths
+ configuration variable to false.
+
+ * "git blame" kept text for each annotated revision in core needlessly;
+ this has been corrected.
+
+ * "git shortlog" learned to default to HEAD when the standard input is
+ a terminal and the user did not give any revision parameter.
+
+ * "git shortlog" learned "-e" option to show e-mail addresses as well as
+ authors' names.
+
+ * "git help" learned "-w" option to show documentation in browsers.
+
+ * In addition there are quite a few internal clean-ups. Notably:
+
+ - many fork/exec have been replaced with run-command API,
+ brought from the msysgit effort.
+
+ - introduction and more use of the option parser API.
+
+ - enhancement and more use of the strbuf API.
+
+ * Makefile tweaks to support HP-UX is in.
+
+Fixes since v1.5.3
+------------------
+
+All of the fixes in v1.5.3 maintenance series are included in
+this release, unless otherwise noted.
+
+These fixes are only in v1.5.4 and not backported to v1.5.3 maintenance
+series.
+
+ * The way "git diff --check" behaves is much more consistent with the way
+ "git apply --whitespace=warn" works.
+
+ * "git svn" talking with the SVN over HTTP will correctly quote branch
+ and project names.
+
+ * "git config" did not work correctly on platforms that define
+ REG_NOMATCH to an even number.
+
+ * Recent versions of AsciiDoc 8 has a change to break our
+ documentation; a workaround has been implemented.
+
+ * "git diff --color-words" colored context lines in a wrong color.
diff --git a/Documentation/RelNotes-1.5.5.1.txt b/Documentation/RelNotes-1.5.5.1.txt
new file mode 100644
index 0000000000..7de419708f
--- /dev/null
+++ b/Documentation/RelNotes-1.5.5.1.txt
@@ -0,0 +1,44 @@
+GIT v1.5.5.1 Release Notes
+==========================
+
+Fixes since v1.5.5
+------------------
+
+ * "git archive --prefix=$path/" mishandled gitattributes.
+
+ * "git fetch -v" that fetches into FETCH_HEAD did not report the summary
+ the same way as done for updating the tracking refs.
+
+ * "git svn" misbehaved when the configuration file customized the "git
+ log" output format using format.pretty.
+
+ * "git submodule status" leaked an unnecessary error message.
+
+ * "git log --date-order --topo-order" did not override the earlier
+ date-order with topo-order as expected.
+
+ * "git bisect good $this" did not check the validity of the revision
+ given properly.
+
+ * "url.<there>.insteadOf" did not work correctly.
+
+ * "git clean" ran inside subdirectory behaved as if the directory was
+ explicitly specified for removal by the end user from the top level.
+
+ * "git bisect" from a detached head leaked an unnecessary error message.
+
+ * "git bisect good $a $b" when $a is Ok but $b is bogus should have
+ atomically failed before marking $a as good.
+
+ * "git fmt-merge-msg" did not clean up leading empty lines from commit
+ log messages like "git log" family does.
+
+ * "git am" recorded a commit with empty Subject: line without
+ complaining.
+
+ * when given a commit log message whose first paragraph consists of
+ multiple lines, "git rebase" squashed it into a single line.
+
+ * "git remote add $bogus_name $url" did not complain properly.
+
+Also comes with various documentation updates.
diff --git a/Documentation/RelNotes-1.5.5.2.txt b/Documentation/RelNotes-1.5.5.2.txt
new file mode 100644
index 0000000000..391a7b02ea
--- /dev/null
+++ b/Documentation/RelNotes-1.5.5.2.txt
@@ -0,0 +1,27 @@
+GIT v1.5.5.2 Release Notes
+==========================
+
+Fixes since v1.5.5.1
+--------------------
+
+ * "git repack -n" was mistakenly made no-op earlier.
+
+ * "git imap-send" wanted to always have imap.host even when use of
+ imap.tunnel made it unnecessary.
+
+ * reflog syntax that uses time e.g. "HEAD@{10 seconds ago}:path" did not
+ stop parsing at the closing "}".
+
+ * "git rev-parse --symbolic-full-name ^master^2" printed solitary "^",
+ but it should print nothing.
+
+ * "git commit" did not detect when it failed to write tree objects.
+
+ * "git fetch" sometimes transferred too many objects unnecessarily.
+
+ * a path specification "a/b" in .gitattributes file should not match
+ "sub/a/b".
+
+ * various gitweb fixes.
+
+Also comes with various documentation updates.
diff --git a/Documentation/RelNotes-1.5.5.3.txt b/Documentation/RelNotes-1.5.5.3.txt
new file mode 100644
index 0000000000..f22f98b734
--- /dev/null
+++ b/Documentation/RelNotes-1.5.5.3.txt
@@ -0,0 +1,12 @@
+GIT v1.5.5.3 Release Notes
+==========================
+
+Fixes since v1.5.5.2
+--------------------
+
+ * "git send-email --compose" did not notice that non-ascii contents
+ needed some MIME magic.
+
+ * "git fast-export" did not export octopus merges correctly.
+
+Also comes with various documentation updates.
diff --git a/Documentation/RelNotes-1.5.5.4.txt b/Documentation/RelNotes-1.5.5.4.txt
new file mode 100644
index 0000000000..2d0279ecce
--- /dev/null
+++ b/Documentation/RelNotes-1.5.5.4.txt
@@ -0,0 +1,7 @@
+GIT v1.5.5.4 Release Notes
+==========================
+
+Fixes since v1.5.5.4
+--------------------
+
+ * "git name-rev --all" used to segfault.
diff --git a/Documentation/RelNotes-1.5.5.txt b/Documentation/RelNotes-1.5.5.txt
new file mode 100644
index 0000000000..2932212488
--- /dev/null
+++ b/Documentation/RelNotes-1.5.5.txt
@@ -0,0 +1,207 @@
+GIT v1.5.5 Release Notes
+========================
+
+Updates since v1.5.4
+--------------------
+
+(subsystems)
+
+ * Comes with git-gui 0.10.1
+
+(portability)
+
+ * We shouldn't ask for BSD group ownership semantics by setting g+s bit
+ on directories on older BSD systems that refuses chmod() by non root
+ users. BSD semantics is the default there anyway.
+
+ * Bunch of portability improvement patches coming from an effort to port
+ to Solaris has been applied.
+
+(performance)
+
+ * On platforms with suboptimal qsort(3) implementation, there
+ is an option to use more reasonable substitute we ship with
+ our software.
+
+ * New configuration variable "pack.packsizelimit" can be used
+ in place of command line option --max-pack-size.
+
+ * "git fetch" over the native git protocol used to make a
+ connection to find out the set of current remote refs and
+ another to actually download the pack data. We now use only
+ one connection for these tasks.
+
+ * "git commit" does not run lstat(2) more than necessary
+ anymore.
+
+(usability, bells and whistles)
+
+ * Bash completion script (in contrib) are aware of more commands and
+ options.
+
+ * You can be warned when core.autocrlf conversion is applied in
+ such a way that results in an irreversible conversion.
+
+ * A catch-all "color.ui" configuration variable can be used to
+ enable coloring of all color-capable commands, instead of
+ individual ones such as "color.status" and "color.branch".
+
+ * The commands refused to take absolute pathnames where they
+ require pathnames relative to the work tree or the current
+ subdirectory. They now can take absolute pathnames in such a
+ case as long as the pathnames do not refer outside of the
+ work tree. E.g. "git add $(pwd)/foo" now works.
+
+ * Error messages used to be sent to stderr, only to get hidden,
+ when $PAGER was in use. They now are sent to stdout along
+ with the command output to be shown in the $PAGER.
+
+ * A pattern "foo/" in .gitignore file now matches a directory
+ "foo". Pattern "foo" also matches as before.
+
+ * bash completion's prompt helper function can talk about
+ operation in-progress (e.g. merge, rebase, etc.).
+
+ * Configuration variables "url.<usethis>.insteadof = <otherurl>" can be
+ used to tell "git-fetch" and "git-push" to use different URL than what
+ is given from the command line.
+
+ * "git add -i" behaves better even before you make an initial commit.
+
+ * "git am" refused to run from a subdirectory without a good reason.
+
+ * After "git apply --whitespace=fix" fixes whitespace errors in a patch,
+ a line before the fix can appear as a context or preimage line in a
+ later patch, causing the patch not to apply. The command now knows to
+ see through whitespace fixes done to context lines to successfully
+ apply such a patch series.
+
+ * "git branch" (and "git checkout -b") to branch from a local branch can
+ optionally set "branch.<name>.merge" to mark the new branch to build on
+ the other local branch, when "branch.autosetupmerge" is set to
+ "always", or when passing the command line option "--track" (this option
+ was ignored when branching from local branches). By default, this does
+ not happen when branching from a local branch.
+
+ * "git checkout" to switch to a branch that has "branch.<name>.merge" set
+ (i.e. marked to build on another branch) reports how much the branch
+ and the other branch diverged.
+
+ * When "git checkout" has to update a lot of paths, it used to be silent
+ for 4 seconds before it showed any progress report. It is now a bit
+ more impatient and starts showing progress report early.
+
+ * "git commit" learned a new hook "prepare-commit-msg" that can
+ inspect what is going to be committed and prepare the commit
+ log message template to be edited.
+
+ * "git cvsimport" can now take more than one -M options.
+
+ * "git describe" learned to limit the tags to be used for
+ naming with --match option.
+
+ * "git describe --contains" now barfs when the named commit
+ cannot be described.
+
+ * "git describe --exact-match" describes only commits that are tagged.
+
+ * "git describe --long" describes a tagged commit as $tag-0-$sha1,
+ instead of just showing the exact tagname.
+
+ * "git describe" warns when using a tag whose name and path contradict
+ with each other.
+
+ * "git diff" learned "--relative" option to limit and output paths
+ relative to the current directory when working in a subdirectory.
+
+ * "git diff" learned "--dirstat" option to show birds-eye-summary of
+ changes more concisely than "--diffstat".
+
+ * "git format-patch" learned --cover-letter option to generate a cover
+ letter template.
+
+ * "git gc" learned --quiet option.
+
+ * "git gc" now automatically prunes unreachable objects that are two
+ weeks old or older.
+
+ * "git gc --auto" can be disabled more easily by just setting gc.auto
+ to zero. It also tolerates more packfiles by default.
+
+ * "git grep" now knows "--name-only" is a synonym for the "-l" option.
+
+ * "git help <alias>" now reports "'git <alias>' is alias to <what>",
+ instead of saying "No manual entry for git-<alias>".
+
+ * "git help" can use different backends to show manual pages and this can
+ be configured using "man.viewer" configuration.
+
+ * "gitk" does not restore window position from $HOME/.gitk anymore (it
+ still restores the size).
+
+ * "git log --grep=<what>" learned "--fixed-strings" option to look for
+ <what> without treating it as a regular expression.
+
+ * "git gui" learned an auto-spell checking.
+
+ * "git push <somewhere> HEAD" and "git push <somewhere> +HEAD" works as
+ expected; they push the current branch (and only the current branch).
+ In addition, HEAD can be written as the value of "remote.<there>.push"
+ configuration variable.
+
+ * When the configuration variable "pack.threads" is set to 0, "git
+ repack" auto detects the number of CPUs and uses that many threads.
+
+ * "git send-email" learned to prompt for passwords
+ interactively.
+
+ * "git send-email" learned an easier way to suppress CC
+ recipients.
+
+ * "git stash" learned "pop" command, that applies the latest stash and
+ removes it from the stash, and "drop" command to discard the named
+ stash entry.
+
+ * "git submodule" learned a new subcommand "summary" to show the
+ symmetric difference between the HEAD version and the work tree version
+ of the submodule commits.
+
+ * Various "git cvsimport", "git cvsexportcommit", "git cvsserver",
+ "git svn" and "git p4" improvements.
+
+(internal)
+
+ * Duplicated code between git-help and git-instaweb that
+ launches user's preferred browser has been refactored.
+
+ * It is now easier to write test scripts that records known
+ breakages.
+
+ * "git checkout" is rewritten in C.
+
+ * "git remote" is rewritten in C.
+
+ * Two conflict hunks that are separated by a very short span of common
+ lines are now coalesced into one larger hunk, to make the result easier
+ to read.
+
+ * Run-command API's use of file descriptors is documented clearer and
+ is more consistent now.
+
+ * diff output can be sent to FILE * that is different from stdout. This
+ will help reimplementing more things in C.
+
+Fixes since v1.5.4
+------------------
+
+All of the fixes in v1.5.4 maintenance series are included in
+this release, unless otherwise noted.
+
+ * "git-http-push" did not allow deletion of remote ref with the usual
+ "push <remote> :<branch>" syntax.
+
+ * "git-rebase --abort" did not go back to the right location if
+ "git-reset" was run during the "git-rebase" session.
+
+ * "git imap-send" without setting imap.host did not error out but
+ segfaulted.
diff --git a/Documentation/RelNotes-1.5.6.txt b/Documentation/RelNotes-1.5.6.txt
new file mode 100644
index 0000000000..a79e4b9393
--- /dev/null
+++ b/Documentation/RelNotes-1.5.6.txt
@@ -0,0 +1,116 @@
+GIT v1.5.6 Release Notes
+========================
+
+Updates since v1.5.5
+--------------------
+
+(subsystems)
+
+* Comes with updated gitk and git-gui.
+
+(portability)
+
+* git will build on AIX better than before now.
+
+* core.ignorecase configuration variable can be used to work better on
+ filesystems that are not case sensitive.
+
+* "git init" now autodetects the case sensitivity of the filesystem and
+ sets core.ignorecase accordingly.
+
+(documentation)
+
+* Many freestanding documentation pages have been converted and made
+ available to "git help" (aka "man git-<command>") as section 7 of the
+ manual pages.
+
+(performance)
+
+* "git clone" was rewritten in C. This will hopefully help cloning a
+ repository with insane number of refs.
+
+* "git rebase --onto $there $from $branch" used to switch to the tip of
+ $branch only to immediately reset back to $from, smudging work tree
+ files unnecessarily. This has been optimized.
+
+* Object creation codepath in "git-svn" has been optimized by enhancing
+ plumbing commands git-cat-file and git-hash-object.
+
+(usability, bells and whistles)
+
+* "git add -p" (and the "patch" subcommand of "git add -i") can choose to
+ apply (or not apply) mode changes independently from contents changes.
+
+* "git bisect help" gives longer and more helpful usage information.
+
+* "git bisect" does not use a special branch "bisect" anymore; instead, it
+ does its work on a detached HEAD.
+
+* "git branch" (and "git checkout -b") can be told to set up
+ branch.<name>.rebase automatically, so that later you can say "git pull"
+ and magically cause "git pull --rebase" to happen.
+
+* "git branch --merged" and "git branch --no-merged" can be used to list
+ branches that have already been merged (or not yet merged) to the
+ current branch.
+
+* "git cherry-pick" and "git revert" can add a sign-off.
+
+* "git commit" mentions the author identity when you are committing
+ somebody else's changes.
+
+* "git diff/log --dirstat" output is consistent between binary and textual
+ changes.
+
+* "git filter-branch" rewrites signed tags by demoting them to annotated.
+
+* "git format-patch --no-binary" can produce a patch that lack binary
+ changes (i.e. cannot be used to propagate the whole changes) meant only
+ for reviewing.
+
+* "git init --bare" is a synonym for "git --bare init" now.
+
+* "git gc --auto" honors a new pre-aut-gc hook to temporarily disable it.
+
+* "git log --pretty=tformat:<custom format>" gives a LF after each entry,
+ instead of giving a LF between each pair of entries which is how
+ "git log --pretty=format:<custom format>" works.
+
+* "git log" and friends learned the "--graph" option to show the ancestry
+ graph at the left margin of the output.
+
+* "git log" and friends can be told to use date format that is different
+ from the default via 'log.date' configuration variable.
+
+* "git send-email" now can send out messages outside a git repository.
+
+* "git send-email --compose" was made aware of rfc2047 quoting.
+
+* "git status" can optionally include output from "git submodule
+ summary".
+
+* "git svn" learned --add-author-from option to propagate the authorship
+ by munging the commit log message.
+
+* new object creation and looking up in "git svn" has been optimized.
+
+* "gitweb" can read from a system-wide configuration file.
+
+(internal)
+
+* "git unpack-objects" and "git receive-pack" is now more strict about
+ detecting breakage in the objects they receive over the wire.
+
+
+Fixes since v1.5.5
+------------------
+
+All of the fixes in v1.5.5 maintenance series are included in
+this release, unless otherwise noted.
+
+
+--
+exec >/var/tmp/1
+O=v1.5.6-rc1
+echo O=`git describe refs/heads/master`
+git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
new file mode 100644
index 0000000000..0e155c936c
--- /dev/null
+++ b/Documentation/SubmittingPatches
@@ -0,0 +1,453 @@
+Checklist (and a short version for the impatient):
+
+ Commits:
+
+ - make commits of logical units
+ - check for unnecessary whitespace with "git diff --check"
+ before committing
+ - do not check in commented out code or unneeded files
+ - provide a meaningful commit message
+ - the first line of the commit message should be a short
+ description and should skip the full stop
+ - if you want your work included in git.git, add a
+ "Signed-off-by: Your Name <you@example.com>" line to the
+ commit message (or just use the option "-s" when
+ committing) to confirm that you agree to the Developer's
+ Certificate of Origin
+ - make sure that you have tests for the bug you are fixing
+ - make sure that the test suite passes after your commit
+
+ Patch:
+
+ - use "git format-patch -M" to create the patch
+ - do not PGP sign your patch
+ - do not attach your patch, but read in the mail
+ body, unless you cannot teach your mailer to
+ leave the formatting of the patch alone.
+ - be careful doing cut & paste into your mailer, not to
+ corrupt whitespaces.
+ - provide additional information (which is unsuitable for
+ the commit message) between the "---" and the diffstat
+ - if you change, add, or remove a command line option or
+ make some other user interface change, the associated
+ documentation should be updated as well.
+ - if your name is not writable in ASCII, make sure that
+ you send off a message in the correct encoding.
+ - send the patch to the list (git@vger.kernel.org) and the
+ maintainer (gitster@pobox.com) if (and only if) the patch
+ is ready for inclusion. If you use git-send-email(1),
+ please test it first by sending email to yourself.
+
+Long version:
+
+I started reading over the SubmittingPatches document for Linux
+kernel, primarily because I wanted to have a document similar to
+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 on the technical/contents front, because the core GIT is
+thousand times smaller ;-). So here is only the relevant bits.
+
+
+(1) Make separate commits for logically separate changes.
+
+Unless your patch is really trivial, you should not be sending
+out a patch that was generated between your working tree and
+your commit head. Instead, always make a commit with complete
+commit message and generate a series of patches from your
+repository. It is a good discipline.
+
+Describe the technical detail of the change(s).
+
+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. To help ensure this does not happen,
+run git diff --check on your changes before you commit.
+
+
+(1a) Try to be nice to older C compilers
+
+We try to support wide range of C compilers to compile
+git with. That means that you should not use C99 initializers, even
+if a lot of compilers grok it.
+
+Also, variables have to be declared at the beginning of the block
+(you can check this with gcc, using the -Wdeclaration-after-statement
+option).
+
+Another thing: NULL pointers shall be written as NULL, not as 0.
+
+
+(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.
+
+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. 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 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 submitted
+"inline". WARNING: Be wary of your MUAs word-wrap
+corrupting your patch. Do not cut-n-paste your patch; you can
+lose tabs that way if you are not careful.
+
+It is a common convention to prefix your subject line with
+[PATCH]. This lets people easily distinguish patches from other
+e-mail discussions. Use of additional markers after PATCH and
+the closing bracket to mark the nature of the patch is also
+encouraged. E.g. [PATCH/RFC] is often used when the patch is
+not ready to be applied but it is for discussion, [PATCH v2],
+[PATCH v3] etc. are often seen when you are sending an update to
+what you have previously sent.
+
+"git format-patch" command follows the best current practice to
+format the body of an e-mail message. At the beginning of the
+patch should come your commit message, ending with the
+Signed-off-by: lines, and a line that consists of three dashes,
+followed by the diffstat information and the patch itself. If
+you are forwarding a patch from somebody else, optionally, at
+the beginning of the e-mail message just before the commit
+message starts, you can put a "From: " line to name that person.
+
+You often want to add additional explanation about the patch,
+other than the commit message itself. Place such "cover letter"
+material between the three dash lines and the diffstat.
+
+Do not attach the patch as a MIME attachment, compressed or not.
+Do not let your e-mail client send quoted-printable. Do not let
+your e-mail client send format=flowed which would destroy
+whitespaces in your patches. Many
+popular e-mail applications will not always transmit a MIME
+attachment as plain text, making it impossible to comment on
+your code. A MIME attachment also takes a bit more time to
+process. This does not decrease the likelihood of your
+MIME-attached change being accepted, but it makes it more likely
+that it will be postponed.
+
+Exception: If your mailer is mangling patches then someone may ask
+you to re-send them using MIME, that is OK.
+
+Do not PGP sign your patch, at least for now. Most likely, your
+maintainer or other people on the list would not have your PGP
+key and would not bother obtaining it anyway. Your patch is not
+judged by who you are; a good patch from an unknown origin has a
+far better chance of being accepted than a patch from a known,
+respected origin that is done poorly or does incorrect things.
+
+If you really really really really want to do a PGP signed
+patch, format it as "multipart/signed", not a text/plain message
+that starts with '-----BEGIN PGP SIGNED MESSAGE-----'. That is
+not a text/plain, it's something else.
+
+Note that your maintainer does not necessarily read everything
+on the git mailing list. If your patch is for discussion first,
+send it "To:" the mailing list, and optionally "cc:" him. If it
+is trivially correct or after the list reached a consensus, send
+it "To:" the maintainer and optionally "cc:" the list for
+inclusion.
+
+Also note that your maintainer does not actively involve himself in
+maintaining what are in contrib/ hierarchy. When you send fixes and
+enhancements to them, do not forget to "cc: " the person who primarily
+worked on that hierarchy in contrib/.
+
+
+(4) Sign your work
+
+To improve tracking of who did what, we've borrowed the
+"sign-off" procedure from the Linux kernel project on patches
+that are being emailed around. Although core GIT is a lot
+smaller project it is a good discipline to follow it.
+
+The sign-off is a simple line at the end of the explanation for
+the patch, which certifies that you wrote it or otherwise have
+the right to pass it on as a open-source patch. The rules are
+pretty simple: if you can certify the below:
+
+ Developer's Certificate of Origin 1.1
+
+ By making a contribution to this project, I certify that:
+
+ (a) The contribution was created in whole or in part by me and I
+ have the right to submit it under the open source license
+ indicated in the file; or
+
+ (b) The contribution is based upon previous work that, to the best
+ of my knowledge, is covered under an appropriate open source
+ license and I have the right under that license to submit that
+ work with modifications, whether created in whole or in part
+ by me, under the same open source license (unless I am
+ permitted to submit under a different license), as indicated
+ in the file; or
+
+ (c) The contribution was provided directly to me by some other
+ person who certified (a), (b) or (c) and I have not modified
+ it.
+
+ (d) I understand and agree that this project and the contribution
+ are public and that a record of the contribution (including all
+ personal information I submit with it, including my sign-off) is
+ maintained indefinitely and may be redistributed consistent with
+ this project or the open source license(s) involved.
+
+then you just add a line saying
+
+ Signed-off-by: Random J Developer <random@developer.example.org>
+
+This line can be automatically added by git if you run the git-commit
+command with the -s option.
+
+Notice that you can place your own Signed-off-by: line when
+forwarding somebody else's patch with the above rules for
+D-C-O. Indeed you are encouraged to do so. Do not forget to
+place an in-body "From: " line at the beginning to properly attribute
+the change to its true author (see (2) above).
+
+Some people also put extra tags at the end.
+
+"Acked-by:" says that the patch was reviewed by the person who
+is more familiar with the issues and the area the patch attempts
+to modify. "Tested-by:" says the patch was tested by the person
+and found to have the desired effect.
+
+------------------------------------------------
+An ideal patch flow
+
+Here is an ideal patch flow for this project the current maintainer
+suggests to the contributors:
+
+ (0) You come up with an itch. You code it up.
+
+ (1) Send it to the list and cc people who may need to know about
+ the change.
+
+ The people who may need to know are the ones whose code you
+ are butchering. These people happen to be the ones who are
+ most likely to be knowledgeable enough to help you, but
+ they have no obligation to help you (i.e. you ask for help,
+ don't demand). "git log -p -- $area_you_are_modifying" would
+ help you find out who they are.
+
+ (2) You get comments and suggestions for improvements. You may
+ even get them in a "on top of your change" patch form.
+
+ (3) Polish, refine, and re-send to the list and the people who
+ spend their time to improve your patch. Go back to step (2).
+
+ (4) The list forms consensus that the last round of your patch is
+ good. Send it to the list and cc the maintainer.
+
+ (5) A topic branch is created with the patch and is merged to 'next',
+ and cooked further and eventually graduates to 'master'.
+
+In any time between the (2)-(3) cycle, the maintainer may pick it up
+from the list and queue it to 'pu', in order to make it easier for
+people play with it without having to pick up and apply the patch to
+their trees themselves.
+
+------------------------------------------------
+MUA specific hints
+
+Some of patches I receive or pick up from the list share common
+patterns of breakage. Please make sure your MUA is set up
+properly not to corrupt whitespaces. Here are two common ones
+I have seen:
+
+* Empty context lines that do not have _any_ whitespace.
+
+* Non empty context lines that have one extra whitespace at the
+ beginning.
+
+One test you could do yourself if your MUA is set up correctly is:
+
+* Send the patch to yourself, exactly the way you would, except
+ To: and Cc: lines, which would not contain the list and
+ maintainer address.
+
+* Save that patch to a file in UNIX mailbox format. Call it say
+ a.patch.
+
+* Try to apply to the tip of the "master" branch from the
+ git.git public repository:
+
+ $ git fetch http://kernel.org/pub/scm/git/git.git master:test-apply
+ $ git checkout test-apply
+ $ git reset --hard
+ $ git am a.patch
+
+If it does not apply correctly, there can be various reasons.
+
+* Your patch itself does not apply cleanly. That is _bad_ but
+ does not have much to do with your MUA. Please rebase the
+ patch appropriately.
+
+* Your MUA corrupted your patch; "am" would complain that
+ the patch does not apply. Look at .dotest/ subdirectory and
+ see what 'patch' file contains and check for the common
+ corruption patterns mentioned above.
+
+* While you are at it, check what are in 'info' and
+ 'final-commit' files as well. If what is in 'final-commit' is
+ not exactly what you would want to see in the commit log
+ message, it is very likely that your maintainer would end up
+ hand editing the log message when he applies your patch.
+ Things like "Hi, this is my first patch.\n", if you really
+ want to put in the patch e-mail, should come after the
+ three-dash line that signals the end of the commit message.
+
+
+Pine
+----
+
+(Johannes Schindelin)
+
+I don't know how many people still use pine, but for those poor
+souls it may be good to mention that the quell-flowed-text is
+needed for recent versions.
+
+... the "no-strip-whitespace-before-send" option, too. AFAIK it
+was introduced in 4.60.
+
+(Linus Torvalds)
+
+And 4.58 needs at least this.
+
+---
+diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from e886a61f76edf5410573e92e38ce22974f9c40f1)
+Author: Linus Torvalds <torvalds@g5.osdl.org>
+Date: Mon Aug 15 17:23:51 2005 -0700
+
+ Fix pine whitespace-corruption bug
+
+ There's no excuse for unconditionally removing whitespace from
+ the pico buffers on close.
+
+diff --git a/pico/pico.c b/pico/pico.c
+--- a/pico/pico.c
++++ b/pico/pico.c
+@@ -219,7 +219,9 @@ PICO *pm;
+ switch(pico_all_done){ /* prepare for/handle final events */
+ case COMP_EXIT : /* already confirmed */
+ packheader();
++#if 0
+ stripwhitespace();
++#endif
+ c |= COMP_EXIT;
+ break;
+
+
+(Daniel Barkalow)
+
+> A patch to SubmittingPatches, MUA specific help section for
+> users of Pine 4.63 would be very much appreciated.
+
+Ah, it looks like a recent version changed the default behavior to do the
+right thing, and inverted the sense of the configuration option. (Either
+that or Gentoo did it.) So you need to set the
+"no-strip-whitespace-before-send" option, unless the option you have is
+"strip-whitespace-before-send", in which case you should avoid checking
+it.
+
+
+Thunderbird
+-----------
+
+(A Large Angry SCM)
+
+Here are some hints on how to successfully submit patches inline using
+Thunderbird.
+
+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.7.2
+ http://globs.org/articles.php?lng=en&pg=8
+
+1) Prepare the patch as a text file using your method of choice.
+
+2) Before opening a compose window, use Edit->Account Settings to
+uncheck the "Compose messages in HTML format" setting in the
+"Composition & Addressing" panel of the account to be used to send the
+patch. [*2*]
+
+3) In the main Thunderbird window, _before_ you open the compose window
+for the patch, use Tools->about:config to set the following to the
+indicated values:
+ mailnews.send_plaintext_flowed => false
+ mailnews.wraplength => 0
+
+4) Open a compose window and click the external editor icon.
+
+5) In the external editor window, read in the patch file and exit the
+editor normally.
+
+6) Back in the compose window: Add whatever other text you wish to the
+message, complete the addressing and subject fields, and press send.
+
+7) Optionally, undo the about:config/account settings changes made in
+steps 2 & 3.
+
+
+[Footnotes]
+*1* Version 1.0 (20041207) from the MozillaThunderbird-1.0-5 rpm of Suse
+9.3 professional updates.
+
+*2* It may be possible to do this with about:config and the following
+settings but I haven't tried, yet.
+ mail.html_compose => false
+ mail.identity.default.compose_html => false
+ mail.identity.id?.compose_html => false
+
+
+Gnus
+----
+
+'|' in the *Summary* buffer can be used to pipe the current
+message to an external program, and this is a handy way to drive
+"git am". However, if the message is MIME encoded, what is
+piped into the program is the representation you see in your
+*Article* buffer after unwrapping MIME. This is often not what
+you would want for two reasons. It tends to screw up non ASCII
+characters (most notably in people's names), and also
+whitespaces (fatal in patches). Running 'C-u g' to display the
+message in raw form before using '|' to run the pipe can work
+this problem around.
+
+
+KMail
+-----
+
+This should help you to submit patches inline using KMail.
+
+1) Prepare the patch as a text file.
+
+2) Click on New Mail.
+
+3) Go under "Options" in the Composer window and be sure that
+"Word wrap" is not set.
+
+4) Use Message -> Insert file... and insert the patch.
+
+5) Back in the compose window: add whatever other text you wish to the
+message, complete the addressing and subject fields, and press send.
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
new file mode 100644
index 0000000000..10c1a151a4
--- /dev/null
+++ b/Documentation/asciidoc.conf
@@ -0,0 +1,66 @@
+## linkgit: macro
+#
+# Usage: linkgit:command[manpage-section]
+#
+# Note, {0} is the manpage section, while {target} is the command.
+#
+# Show GIT link as: <command>(<section>); if section is defined, else just show
+# the command.
+
+[attributes]
+plus=&#43;
+caret=&#94;
+startsb=&#91;
+endsb=&#93;
+tilde=&#126;
+
+ifdef::backend-docbook[]
+[linkgit-inlinemacro]
+{0%{target}}
+{0#<citerefentry>}
+{0#<refentrytitle>{target}</refentrytitle><manvolnum>{0}</manvolnum>}
+{0#</citerefentry>}
+endif::backend-docbook[]
+
+ifdef::backend-docbook[]
+ifndef::docbook-xsl-172[]
+# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this.
+# v1.72 breaks with this because it replaces dots not in roff requests.
+[listingblock]
+<example><title>{title}</title>
+<literallayout>
+ifdef::doctype-manpage[]
+&#10;.ft C&#10;
+endif::doctype-manpage[]
+|
+ifdef::doctype-manpage[]
+&#10;.ft&#10;
+endif::doctype-manpage[]
+</literallayout>
+{title#}</example>
+endif::docbook-xsl-172[]
+endif::backend-docbook[]
+
+ifdef::doctype-manpage[]
+ifdef::backend-docbook[]
+[header]
+template::[header-declarations]
+<refentry>
+<refmeta>
+<refentrytitle>{mantitle}</refentrytitle>
+<manvolnum>{manvolnum}</manvolnum>
+<refmiscinfo class="source">Git</refmiscinfo>
+<refmiscinfo class="version">{git_version}</refmiscinfo>
+<refmiscinfo class="manual">Git Manual</refmiscinfo>
+</refmeta>
+<refnamediv>
+ <refname>{manname}</refname>
+ <refpurpose>{manpurpose}</refpurpose>
+</refnamediv>
+endif::backend-docbook[]
+endif::doctype-manpage[]
+
+ifdef::backend-xhtml11[]
+[linkgit-inlinemacro]
+<a href="{target}.html">{target}{0?({0})}</a>
+endif::backend-xhtml11[]
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
new file mode 100644
index 0000000000..5428111d73
--- /dev/null
+++ b/Documentation/blame-options.txt
@@ -0,0 +1,89 @@
+-b::
+ Show blank SHA-1 for boundary commits. This can also
+ be controlled via the `blame.blankboundary` config option.
+
+--root::
+ Do not treat root commits as boundaries. This can also be
+ controlled via the `blame.showroot` config option.
+
+--show-stats::
+ Include additional statistics at the end of blame output.
+
+-L <start>,<end>::
+ Annotate only the given line range. <start> and <end> can take
+ one of these forms:
+
+ - number
++
+If <start> or <end> is a number, it specifies an
+absolute line number (lines count from 1).
++
+
+- /regex/
++
+This form will use the first line matching the given
+POSIX regex. If <end> is a regex, it will search
+starting at the line given by <start>.
++
+
+- +offset or -offset
++
+This is only valid for <end> and will specify a number
+of lines before or after the line given by <start>.
++
+
+-l::
+ Show long rev (Default: off).
+
+-t::
+ Show raw timestamp (Default: off).
+
+-S <revs-file>::
+ Use revs from revs-file instead of calling linkgit:git-rev-list[1].
+
+-p::
+--porcelain::
+ Show in a format designed for machine consumption.
+
+--incremental::
+ Show the result incrementally in a format designed for
+ machine consumption.
+
+--contents <file>::
+ When <rev> is not specified, the command annotates the
+ changes starting backwards from the working tree copy.
+ This flag makes the command pretend as if the working
+ tree copy has the contents of the named file (specify
+ `-` to make the command read from the standard input).
+
+-M|<num>|::
+ Detect moving lines in the file as well. When a commit
+ moves a block of lines in a file (e.g. the original file
+ has A and then B, and the commit changes it to B and
+ then A), traditional 'blame' algorithm typically blames
+ the lines that were moved up (i.e. B) to the parent and
+ assigns blame to the lines that were moved down (i.e. A)
+ to the child commit. With this option, both groups of lines
+ are blamed on the parent.
++
+<num> is optional but it is the lower bound on the number of
+alphanumeric characters that git must detect as moving
+within a file for it to associate those lines with the parent
+commit.
+
+-C|<num>|::
+ In addition to `-M`, detect lines copied from other
+ files that were modified in the same commit. This is
+ useful when you reorganize your program and move code
+ around across files. When this option is given twice,
+ the command looks for copies from all other files in the
+ parent for the commit that creates the file in addition.
++
+<num> is optional but it is the lower bound on the number of
+alphanumeric characters that git must detect as moving
+between files for it to associate those lines with the parent
+commit.
+
+-h::
+--help::
+ Show help message.
diff --git a/Documentation/build-docdep.perl b/Documentation/build-docdep.perl
new file mode 100755
index 0000000000..ba4205e030
--- /dev/null
+++ b/Documentation/build-docdep.perl
@@ -0,0 +1,46 @@
+#!/usr/bin/perl
+
+my %include = ();
+my %included = ();
+
+for my $text (<*.txt>) {
+ open I, '<', $text || die "cannot read: $text";
+ while (<I>) {
+ if (/^include::/) {
+ chomp;
+ s/^include::\s*//;
+ s/\[\]//;
+ $include{$text}{$_} = 1;
+ $included{$_} = 1;
+ }
+ }
+ close I;
+}
+
+# Do we care about chained includes???
+my $changed = 1;
+while ($changed) {
+ $changed = 0;
+ while (my ($text, $included) = each %include) {
+ for my $i (keys %$included) {
+ # $text has include::$i; if $i includes $j
+ # $text indirectly includes $j.
+ if (exists $include{$i}) {
+ for my $j (keys %{$include{$i}}) {
+ if (!exists $include{$text}{$j}) {
+ $include{$text}{$j} = 1;
+ $included{$j} = 1;
+ $changed = 1;
+ }
+ }
+ }
+ }
+ }
+}
+
+while (my ($text, $included) = each %include) {
+ if (! exists $included{$text} &&
+ (my $base = $text) =~ s/\.txt$//) {
+ print "$base.html $base.xml : ", join(" ", keys %$included), "\n";
+ }
+}
diff --git a/Documentation/callouts.xsl b/Documentation/callouts.xsl
new file mode 100644
index 0000000000..6a361a2136
--- /dev/null
+++ b/Documentation/callouts.xsl
@@ -0,0 +1,30 @@
+<!-- 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>
+
+<!-- sorry, this is not about callouts, but attempts to work around
+ spurious .sp at the tail of the line docbook stylesheets seem to add -->
+<xsl:template match="simpara">
+ <xsl:variable name="content">
+ <xsl:apply-templates/>
+ </xsl:variable>
+ <xsl:value-of select="normalize-space($content)"/>
+ <xsl:if test="not(ancestor::authorblurb) and
+ not(ancestor::personblurb)">
+ <xsl:text>&#10;&#10;</xsl:text>
+ </xsl:if>
+</xsl:template>
+
+</xsl:stylesheet>
diff --git a/Documentation/cat-texi.perl b/Documentation/cat-texi.perl
new file mode 100755
index 0000000000..e3d8e9faa8
--- /dev/null
+++ b/Documentation/cat-texi.perl
@@ -0,0 +1,38 @@
+#!/usr/bin/perl -w
+
+my @menu = ();
+my $output = $ARGV[0];
+
+open TMP, '>', "$output.tmp";
+
+while (<STDIN>) {
+ next if (/^\\input texinfo/../\@node Top/);
+ next if (/^\@bye/ || /^\.ft/);
+ if (s/^\@top (.*)/\@node $1,,,Top/) {
+ push @menu, $1;
+ }
+ s/\(\@pxref{\[URLS\]}\)//;
+ print TMP;
+}
+close TMP;
+
+printf '\input texinfo
+@setfilename gitman.info
+@documentencoding us-ascii
+@node Top,,%s
+@top Git Manual Pages
+@documentlanguage en
+@menu
+', $menu[0];
+
+for (@menu) {
+ print "* ${_}::\n";
+}
+print "\@end menu\n";
+open TMP, '<', "$output.tmp";
+while (<TMP>) {
+ print;
+}
+close TMP;
+print "\@bye\n";
+unlink "$output.tmp";
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
new file mode 100755
index 0000000000..04f99778d8
--- /dev/null
+++ b/Documentation/cmd-list.perl
@@ -0,0 +1,74 @@
+#!/usr/bin/perl -w
+
+use File::Compare qw(compare);
+
+sub format_one {
+ my ($out, $nameattr) = @_;
+ my ($name, $attr) = @$nameattr;
+ my ($state, $description);
+ $state = 0;
+ open I, '<', "$name.txt" or die "No such file $name.txt";
+ while (<I>) {
+ if (/^NAME$/) {
+ $state = 1;
+ next;
+ }
+ if ($state == 1 && /^----$/) {
+ $state = 2;
+ next;
+ }
+ next if ($state != 2);
+ chomp;
+ $description = $_;
+ last;
+ }
+ close I;
+ if (!defined $description) {
+ die "No description found in $name.txt";
+ }
+ if (my ($verify_name, $text) = ($description =~ /^($name) - (.*)/)) {
+ print $out "linkgit:$name\[1\]::\n\t";
+ if ($attr =~ / deprecated /) {
+ print $out "(deprecated) ";
+ }
+ print $out "$text.\n\n";
+ }
+ else {
+ die "Description does not match $name: $description";
+ }
+}
+
+my %cmds = ();
+for (sort <>) {
+ next if /^#/;
+
+ chomp;
+ my ($name, $cat, $attr) = /^(\S+)\s+(.*?)(?:\s+(.*))?$/;
+ $attr = '' unless defined $attr;
+ push @{$cmds{$cat}}, [$name, " $attr "];
+}
+
+for my $cat (qw(ancillaryinterrogators
+ ancillarymanipulators
+ mainporcelain
+ plumbinginterrogators
+ plumbingmanipulators
+ synchingrepositories
+ foreignscminterface
+ purehelpers
+ synchelpers)) {
+ my $out = "cmds-$cat.txt";
+ open O, '>', "$out+" or die "Cannot open output file $out+";
+ for (@{$cmds{$cat}}) {
+ format_one(\*O, $_);
+ }
+ close O;
+
+ if (-f "$out" && compare("$out", "$out+") == 0) {
+ unlink "$out+";
+ }
+ else {
+ print STDERR "$out\n";
+ rename "$out+", "$out";
+ }
+}
diff --git a/Documentation/config.txt b/Documentation/config.txt
new file mode 100644
index 0000000000..5331b450ea
--- /dev/null
+++ b/Documentation/config.txt
@@ -0,0 +1,1089 @@
+CONFIGURATION FILE
+------------------
+
+The git configuration file contains a number of variables that affect
+the git command's behavior. `.git/config` file for each repository
+is used to store the information for that repository, and
+`$HOME/.gitconfig` is used to store per user information to give
+fallback values for `.git/config` file. The file `/etc/gitconfig`
+can be used to store system-wide defaults.
+
+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.
+
+Syntax
+~~~~~~
+
+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.
+
+The file consists of sections and variables. A section begins with
+the name of the section in square brackets and continues until the next
+section begins. Section names are not case sensitive. Only alphanumeric
+characters, '`-`' and '`.`' are allowed in section names. Each variable
+must belong to some section, which means that there must be section
+header before first setting of a variable.
+
+Sections can be further divided into subsections. To begin a subsection
+put its name in double quotes, separated by space from the section name,
+in the section header, like in example below:
+
+--------
+ [section "subsection"]
+
+--------
+
+Subsection names can contain any characters except newline (doublequote
+'`"`' and backslash have to be escaped as '`\"`' and '`\\`',
+respectively) and are case sensitive. Section header cannot span multiple
+lines. Variables may belong directly to a section or to a given subsection.
+You can have `[section]` if you have `[section "subsection"]`, but you
+don't need to.
+
+There is also (case insensitive) alternative `[section.subsection]` syntax.
+In this syntax subsection names follow the same restrictions as for section
+name.
+
+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".
+The variable names are case-insensitive and only alphanumeric
+characters and '`-`' are allowed. There can be more than one value
+for a given variable; we say then that variable is multivalued.
+
+Leading and trailing whitespace in a variable value is discarded.
+Internal whitespace within a variable value is retained verbatim.
+
+The values following the equals sign in variable assign are all either
+a string, an integer, or a boolean. Boolean values may be given as yes/no,
+0/1 or true/false. Case is not significant in boolean values, when
+converting value to the canonical form using '--bool' type specifier;
+`git-config` will ensure that the output is "true" or "false".
+
+String values may be entirely or partially enclosed in double quotes.
+You need to enclose variable value in double quotes if you want to
+preserve leading or trailing whitespace, or if variable value contains
+beginning of comment characters (if it contains '#' or ';').
+Double quote '`"`' and backslash '`\`' characters in variable value must
+be escaped: use '`\"`' for '`"`' and '`\\`' for '`\`'.
+
+The following escape sequences (beside '`\"`' and '`\\`') are recognized:
+'`\n`' for newline character (NL), '`\t`' for horizontal tabulation (HT, TAB)
+and '`\b`' for backspace (BS). No other char escape sequence, nor octal
+char sequences are valid.
+
+Variable value ending in a '`\`' is continued on the next line in the
+customary UNIX fashion.
+
+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
+
+ [branch "devel"]
+ remote = origin
+ merge = refs/heads/devel
+
+ # Proxy settings
+ [core]
+ gitProxy="ssh" for "kernel.org"
+ gitProxy=default-proxy ; for the rest
+
+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 linkgit:git-update-index[1]. True by default.
+
+core.quotepath::
+ The commands that output paths (e.g. `ls-files`,
+ `diff`), when not given the `-z` option, will quote
+ "unusual" characters in the pathname by enclosing the
+ pathname in a double-quote pair and with backslashes the
+ same way strings in C source code are quoted. If this
+ variable is set to false, the bytes higher than 0x80 are
+ not quoted but output as verbatim. Note that double
+ quote, backslash and control characters are always
+ quoted without `-z` regardless of the setting of this
+ variable.
+
+core.autocrlf::
+ If true, makes git convert `CRLF` at the end of lines in text files to
+ `LF` when reading from the filesystem, and convert in reverse when
+ writing to the filesystem. The variable can be set to
+ 'input', in which case the conversion happens only while
+ reading from the filesystem but files are written out with
+ `LF` at the end of lines. Currently, which paths to consider
+ "text" (i.e. be subjected to the autocrlf mechanism) is
+ decided purely based on the contents.
+
+core.safecrlf::
+ If true, makes git check if converting `CRLF` as controlled by
+ `core.autocrlf` is reversible. Git will verify if a command
+ modifies a file in the work tree either directly or indirectly.
+ For example, committing a file followed by checking out the
+ same file should yield the original file in the work tree. If
+ this is not the case for the current setting of
+ `core.autocrlf`, git will reject the file. The variable can
+ be set to "warn", in which case git will only warn about an
+ irreversible conversion but continue the operation.
++
+CRLF conversion bears a slight chance of corrupting data.
+autocrlf=true will convert CRLF to LF during commit and LF to
+CRLF during checkout. A file that contains a mixture of LF and
+CRLF before the commit cannot be recreated by git. For text
+files this is the right thing to do: it corrects line endings
+such that we have only LF line endings in the repository.
+But for binary files that are accidentally classified as text the
+conversion can corrupt data.
++
+If you recognize such corruption early you can easily fix it by
+setting the conversion type explicitly in .gitattributes. Right
+after committing you still have the original file in your work
+tree and this file is not yet corrupted. You can explicitly tell
+git that this file is binary and git will handle the file
+appropriately.
++
+Unfortunately, the desired effect of cleaning up text files with
+mixed line endings and the undesired effect of corrupting binary
+files cannot be distinguished. In both cases CRLFs are removed
+in an irreversible way. For text files this is the right thing
+to do because CRLFs are line endings, while for binary files
+converting CRLFs corrupts data.
++
+Note, this safety check does not mean that a checkout will generate a
+file identical to the original file for a different setting of
+`core.autocrlf`, but only for the current one. For example, a text
+file with `LF` would be accepted with `core.autocrlf=input` and could
+later be checked out with `core.autocrlf=true`, in which case the
+resulting file would contain `CRLF`, although the original file
+contained `LF`. However, in both work trees the line endings would be
+consistent, that is either all `LF` or all `CRLF`, but never mixed. A
+file with mixed line endings would be reported by the `core.safecrlf`
+mechanism.
+
+core.symlinks::
+ If false, symbolic links are checked out as small plain files that
+ contain the link text. linkgit:git-update-index[1] and
+ linkgit:git-add[1] will not change the recorded type to regular
+ file. Useful on filesystems like FAT that do not support
+ symbolic links. 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::
+ If true, commands which modify both the working tree and the index
+ will mark the updated paths with the "assume unchanged" bit in the
+ index. These marked files are then assumed to stay unchanged in the
+ working copy, 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 linkgit: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.bare::
+ If true this repository is assumed to be 'bare' and has no
+ working directory associated with it. If this is the case a
+ number of commands that require a working directory will be
+ disabled, such as linkgit:git-add[1] or linkgit:git-merge[1].
++
+This setting is automatically guessed by linkgit:git-clone[1] or
+linkgit:git-init[1] when the repository was created. By default a
+repository that ends in "/.git" is assumed to be not bare (bare =
+false), while all other repositories are assumed to be bare (bare
+= true).
+
+core.worktree::
+ Set the path to the working tree. The value will not be
+ used in combination with repositories found automatically in
+ a .git directory (i.e. $GIT_DIR is not set).
+ This can be overridden by the GIT_WORK_TREE environment
+ variable and the '--work-tree' command line option. It can be
+ a absolute path or relative path to the directory specified by
+ --git-dir or GIT_DIR.
+ Note: If --git-dir or GIT_DIR are specified but none of
+ --work-tree, GIT_WORK_TREE and core.worktree is specified,
+ the current working directory is regarded as the top directory
+ of your working tree.
+
+core.logAllRefUpdates::
+ Enable the reflog. Updates to a ref <ref> is logged to the file
+ "$GIT_DIR/logs/<ref>", by appending the new and old
+ SHA1, the date/time and the reason of the update, but
+ only when the file exists. If this configuration
+ variable is set to true, missing "$GIT_DIR/logs/<ref>"
+ file is automatically created for branch heads.
++
+This information can be used to determine what commit
+was the tip of a branch "2 days ago".
++
+This value is true by default in a repository that has
+a working directory associated with it, and false by
+default in a bare repository.
+
+core.repositoryFormatVersion::
+ Internal variable identifying the repository format and layout
+ version.
+
+core.sharedRepository::
+ When 'group' (or 'true'), the repository is made shareable between
+ several users in a group (making sure all the files and objects are
+ group-writable). When 'all' (or 'world' or 'everybody'), the
+ repository will be readable by all users, additionally to being
+ group-shareable. When 'umask' (or 'false'), git will use permissions
+ reported by umask(2). When '0xxx', where '0xxx' is an octal number,
+ files in the repository will have this mode value. '0xxx' will override
+ user's umask value, and thus, users with a safe umask (0077) can use
+ this option. Examples: '0660' is equivalent to 'group'. '0640' is a
+ repository that is group-readable but not group-writable.
+ See linkgit:git-init[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 a default compression level.
+ -1 is the zlib default. 0 means no compression,
+ and 1..9 are various speed/size tradeoffs, 9 being slowest.
+ If set, this provides a default to other compression variables,
+ such as 'core.loosecompression' and 'pack.compression'.
+
+core.loosecompression::
+ An integer -1..9, indicating the compression level for objects that
+ are not in a pack file. -1 is the zlib default. 0 means no
+ compression, and 1..9 are various speed/size tradeoffs, 9 being
+ slowest. If not set, defaults to core.compression. If that is
+ not set, defaults to 1 (best speed).
+
+core.packedGitWindowSize::
+ Number of bytes of a pack file to map into memory in a
+ single mapping operation. Larger window sizes may allow
+ your system to process a smaller number of large pack files
+ more quickly. Smaller window sizes will negatively affect
+ performance due to increased calls to the operating system's
+ memory manager, but may improve performance when accessing
+ a large number of large pack files.
++
+Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32
+MiB on 32 bit platforms and 1 GiB on 64 bit platforms. This should
+be reasonable for all users/operating systems. You probably do
+not need to adjust this value.
++
+Common unit suffixes of 'k', 'm', or 'g' are supported.
+
+core.packedGitLimit::
+ Maximum number of bytes to map simultaneously into memory
+ from pack files. If Git needs to access more than this many
+ bytes at once to complete an operation it will unmap existing
+ regions to reclaim virtual address space within the process.
++
+Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms.
+This should be reasonable for all users/operating systems, except on
+the largest projects. You probably do not need to adjust this value.
++
+Common unit suffixes of 'k', 'm', or 'g' are supported.
+
+core.deltaBaseCacheLimit::
+ Maximum number of bytes to reserve for caching base objects
+ that multiple deltafied objects reference. By storing the
+ entire decompressed base objects in a cache Git is able
+ to avoid unpacking and decompressing frequently used base
+ objects multiple times.
++
+Default is 16 MiB on all platforms. This should be reasonable
+for all users/operating systems, except on the largest projects.
+You probably do not need to adjust this value.
++
+Common unit suffixes of 'k', 'm', or 'g' are supported.
+
+core.excludesfile::
+ In addition to '.gitignore' (per-directory) and
+ '.git/info/exclude', git looks into this file for patterns
+ of files which are not meant to be tracked. See
+ linkgit:gitignore[5].
+
+core.editor::
+ Commands such as `commit` and `tag` that lets you edit
+ messages by launching an editor uses the value of this
+ variable when it is set, and the environment variable
+ `GIT_EDITOR` is not set. The order of preference is
+ `GIT_EDITOR` environment, `core.editor`, `VISUAL` and
+ `EDITOR` environment variables and then finally `vi`.
+
+core.pager::
+ The command that git will use to paginate output. Can be overridden
+ with the `GIT_PAGER` environment variable.
+
+core.whitespace::
+ A comma separated list of common whitespace problems to
+ notice. `git diff` will use `color.diff.whitespace` to
+ highlight them, and `git apply --whitespace=error` will
+ consider them as errors:
++
+* `trailing-space` treats trailing whitespaces at the end of the line
+ as an error (enabled by default).
+* `space-before-tab` treats a space character that appears immediately
+ before a tab character in the initial indent part of the line as an
+ error (enabled by default).
+* `indent-with-non-tab` treats a line that is indented with 8 or more
+ space characters as an error (not enabled by default).
+* `cr-at-eol` treats a carriage-return at the end of line as
+ part of the line terminator, i.e. with it, `trailing-space`
+ does not trigger if the character before such a carriage-return
+ is not a whitespace (not enabled by default).
+
+alias.*::
+ Command aliases for the linkgit: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.
++
+If the alias expansion is prefixed with an exclamation point,
+it will be treated as a shell command. For example, defining
+"alias.new = !gitk --all --not ORIG_HEAD", the invocation
+"git new" is equivalent to running the shell command
+"gitk --all --not ORIG_HEAD".
+
+apply.whitespace::
+ Tells `git-apply` how to handle whitespaces, in the same way
+ as the '--whitespace' option. See linkgit:git-apply[1].
+
+branch.autosetupmerge::
+ Tells `git-branch` and `git-checkout` to setup new branches
+ so that linkgit:git-pull[1] will appropriately merge from the
+ starting point branch. Note that even if this option is not set,
+ this behavior can be chosen per-branch using the `--track`
+ and `--no-track` options. The valid settings are: `false` -- no
+ automatic setup is done; `true` -- automatic setup is done when the
+ starting point is a remote branch; `always` -- automatic setup is
+ done when the starting point is either a local branch or remote
+ branch. This option defaults to true.
+
+branch.autosetuprebase::
+ When a new branch is created with `git-branch` or `git-checkout`
+ that tracks another branch, this variable tells git to set
+ up pull to rebase instead of merge (see "branch.<name>.rebase").
+ When `never`, rebase is never automatically set to true.
+ When `local`, rebase is set to true for tracked branches of
+ other local branches.
+ When `remote`, rebase is set to true for tracked branches of
+ remote branches.
+ When `always`, rebase will be set to true for all tracking
+ branches.
+ See "branch.autosetupmerge" for details on how to set up a
+ branch to track another branch.
+ This option defaults to never.
+
+branch.<name>.remote::
+ When in branch <name>, it tells `git fetch` which remote to fetch.
+ If this option is not given, `git fetch` defaults to remote "origin".
+
+branch.<name>.merge::
+ When in branch <name>, it tells `git fetch` the default
+ refspec to be marked for merging in FETCH_HEAD. The value is
+ handled like the remote part of a refspec, and must match a
+ ref which is fetched from the remote given by
+ "branch.<name>.remote".
+ The merge information is used by `git pull` (which at first calls
+ `git fetch`) to lookup the default branch for merging. Without
+ this option, `git pull` defaults to merge the first refspec fetched.
+ Specify multiple values to get an octopus merge.
+ If you wish to setup `git pull` so that it merges into <name> from
+ another branch in the local repository, you can point
+ branch.<name>.merge to the desired branch, and use the special setting
+ `.` (a period) for branch.<name>.remote.
+
+branch.<name>.mergeoptions::
+ Sets default options for merging into branch <name>. The syntax and
+ supported options are equal to that of linkgit:git-merge[1], but
+ option values containing whitespace characters are currently not
+ supported.
+
+branch.<name>.rebase::
+ When true, rebase the branch <name> on top of the fetched branch,
+ instead of merging the default branch from the default remote when
+ "git pull" is run.
+ *NOTE*: this is a possibly dangerous operation; do *not* use
+ it unless you understand the implications (see linkgit:git-rebase[1]
+ for details).
+
+browser.<tool>.cmd::
+ Specify the command to invoke the specified browser. The
+ specified command is evaluated in shell with the URLs passed
+ as arguments. (See linkgit:git-web--browse[1].)
+
+browser.<tool>.path::
+ Override the path for the given tool that may be used to
+ browse HTML help (see '-w' option in linkgit:git-help[1]) or a
+ working repository in gitweb (see linkgit:git-instaweb[1]).
+
+clean.requireForce::
+ A boolean to make git-clean do nothing unless given -f
+ or -n. Defaults to true.
+
+color.branch::
+ A boolean to enable/disable color in the output of
+ linkgit:git-branch[1]. May be set to `always`,
+ `false` (or `never`) or `auto` (or `true`), in which case colors are used
+ only when the output is to a terminal. Defaults to false.
+
+color.branch.<slot>::
+ Use customized color for branch coloration. `<slot>` is one of
+ `current` (the current branch), `local` (a local branch),
+ `remote` (a tracking branch in refs/remotes/), `plain` (other
+ refs).
++
+The value for these configuration variables is a list of colors (at most
+two) and attributes (at most one), separated by spaces. The colors
+accepted are `normal`, `black`, `red`, `green`, `yellow`, `blue`,
+`magenta`, `cyan` and `white`; the attributes are `bold`, `dim`, `ul`,
+`blink` and `reverse`. The first color given is the foreground; the
+second is the background. The position of the attribute, if any,
+doesn't matter.
+
+color.diff::
+ When set to `always`, always use colors in patch.
+ When false (or `never`), never. When set to `true` or `auto`, use
+ colors only when the output is to the terminal. Defaults to false.
+
+color.diff.<slot>::
+ Use customized color for diff colorization. `<slot>` specifies
+ which part of the patch to use the specified color, and is one
+ of `plain` (context text), `meta` (metainformation), `frag`
+ (hunk header), `old` (removed lines), `new` (added lines),
+ `commit` (commit headers), or `whitespace` (highlighting
+ whitespace errors). The values of these variables may be specified as
+ in color.branch.<slot>.
+
+color.interactive::
+ When set to `always`, always use colors for interactive prompts
+ and displays (such as those used by "git add --interactive").
+ When false (or `never`), never. When set to `true` or `auto`, use
+ colors only when the output is to the terminal. Defaults to false.
+
+color.interactive.<slot>::
+ Use customized color for `git add --interactive`
+ output. `<slot>` may be `prompt`, `header`, or `help`, for
+ three distinct types of normal output from interactive
+ programs. The values of these variables may be specified as
+ in color.branch.<slot>.
+
+color.pager::
+ A boolean to enable/disable colored output when the pager is in
+ use (default is true).
+
+color.status::
+ A boolean to enable/disable color in the output of
+ linkgit:git-status[1]. May be set to `always`,
+ `false` (or `never`) or `auto` (or `true`), in which case colors are used
+ only when the output is to a terminal. Defaults to false.
+
+color.status.<slot>::
+ Use customized color for status colorization. `<slot>` is
+ one of `header` (the header text of the status message),
+ `added` or `updated` (files which are added but not committed),
+ `changed` (files which are changed but not added in the index),
+ `untracked` (files which are not tracked by git), or
+ `nobranch` (the color the 'no branch' warning is shown in, defaulting
+ to red). The values of these variables may be specified as in
+ color.branch.<slot>.
+
+commit.template::
+ Specify a file to use as the template for new commit messages.
+
+color.ui::
+ When set to `always`, always use colors in all git commands which
+ are capable of colored output. When false (or `never`), never. When
+ set to `true` or `auto`, use colors only when the output is to the
+ terminal. When more specific variables of color.* are set, they always
+ take precedence over this setting. Defaults to false.
+
+diff.autorefreshindex::
+ When using `git diff` to compare with work tree
+ files, do not consider stat-only change as changed.
+ Instead, silently run `git update-index --refresh` to
+ update the cached stat information for paths whose
+ contents in the work tree match the contents in the
+ index. This option defaults to true. Note that this
+ affects only `git diff` Porcelain, and not lower level
+ `diff` commands, such as `git diff-files`.
+
+diff.external::
+ If this config variable is set, diff generation is not
+ performed using the internal diff machinery, but using the
+ given command. Note: if you want to use an external diff
+ program only on a subset of your files, you might want to
+ use linkgit:gitattributes[5] instead.
+
+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.
+
+fetch.unpackLimit::
+ If the number of objects fetched over the git native
+ transfer is below this
+ limit, then the objects will be unpacked into loose object
+ files. However if the number of received objects equals or
+ exceeds this limit then the received pack will be stored as
+ a pack, after adding any missing delta bases. Storing the
+ pack from a push can make the push operation complete faster,
+ especially on slow filesystems. If not set, the value of
+ `transfer.unpackLimit` is used instead.
+
+format.numbered::
+ A boolean which can enable sequence numbers in patch subjects.
+ Setting this option to "auto" will enable it only if there is
+ more than one patch. See --numbered option in
+ linkgit:git-format-patch[1].
+
+format.headers::
+ Additional email headers to include in a patch to be submitted
+ by mail. See linkgit:git-format-patch[1].
+
+format.suffix::
+ The default for format-patch is to output files with the suffix
+ `.patch`. Use this variable to change that suffix (make sure to
+ include the dot if you want it).
+
+format.pretty::
+ The default pretty format for log/show/whatchanged command,
+ See linkgit:git-log[1], linkgit:git-show[1],
+ linkgit:git-whatchanged[1].
+
+gc.aggressiveWindow::
+ The window size parameter used in the delta compression
+ algorithm used by 'git gc --aggressive'. This defaults
+ to 10.
+
+gc.auto::
+ When there are approximately more than this many loose
+ objects in the repository, `git gc --auto` will pack them.
+ Some Porcelain commands use this command to perform a
+ light-weight garbage collection from time to time. The
+ default value is 6700. Setting this to 0 disables it.
+
+gc.autopacklimit::
+ When there are more than this many packs that are not
+ marked with `*.keep` file in the repository, `git gc
+ --auto` consolidates them into one larger pack. The
+ default value is 50. Setting this to 0 disables it.
+
+gc.packrefs::
+ `git gc` does not run `git pack-refs` in a bare repository by
+ default so that older dumb-transport clients can still fetch
+ from the repository. Setting this to `true` lets `git
+ gc` to run `git pack-refs`. Setting this to `false` tells
+ `git gc` never to run `git pack-refs`. The default setting is
+ `notbare`. Enable it only when you know you do not have to
+ support such clients. The default setting will change to `true`
+ at some stage, and setting this to `false` will continue to
+ prevent `git pack-refs` from being run from `git gc`.
+
+gc.pruneexpire::
+ When `git gc` is run, it will call `prune --expire 2.weeks.ago`.
+ Override the grace period with this config variable.
+
+gc.reflogexpire::
+ `git reflog expire` removes reflog entries older than
+ this time; defaults to 90 days.
+
+gc.reflogexpireunreachable::
+ `git reflog expire` removes reflog entries older than
+ this time and are not reachable from the current tip;
+ defaults to 30 days.
+
+gc.rerereresolved::
+ Records of conflicted merge you resolved earlier are
+ kept for this many days when `git rerere gc` is run.
+ The default is 60 days. See linkgit:git-rerere[1].
+
+gc.rerereunresolved::
+ Records of conflicted merge you have not resolved are
+ kept for this many days when `git rerere gc` is run.
+ The default is 15 days. See linkgit:git-rerere[1].
+
+rerere.enabled::
+ Activate recording of resolved conflicts, so that identical
+ conflict hunks can be resolved automatically, should they
+ be encountered again. linkgit:git-rerere[1] command is by
+ default enabled if you create `rr-cache` directory under
+ `$GIT_DIR`, but can be disabled by setting this option to false.
+
+gitcvs.enabled::
+ Whether the CVS server interface is enabled for this repository.
+ See linkgit:git-cvsserver[1].
+
+gitcvs.logfile::
+ Path to a log file where the CVS server interface well... logs
+ various stuff. See linkgit:git-cvsserver[1].
+
+gitcvs.usecrlfattr
+ If true, the server will look up the `crlf` attribute for
+ files to determine the '-k' modes to use. If `crlf` is set,
+ the '-k' mode will be left blank, so cvs clients will
+ treat it as text. If `crlf` is explicitly unset, the file
+ will be set with '-kb' mode, which supresses any newline munging
+ the client might otherwise do. If `crlf` is not specified,
+ then 'gitcvs.allbinary' is used. See linkgit:gitattribute[5].
+
+gitcvs.allbinary::
+ This is used if 'gitcvs.usecrlfattr' does not resolve
+ the correct '-kb' mode to use. If true, all
+ unresolved files are sent to the client in
+ mode '-kb'. This causes the client to treat them
+ as binary files, which suppresses any newline munging it
+ otherwise might do. Alternatively, if it is set to "guess",
+ then the contents of the file are examined to decide if
+ it is binary, similar to 'core.autocrlf'.
+
+gitcvs.dbname::
+ Database used by git-cvsserver to cache revision information
+ derived from the git repository. The exact meaning depends on the
+ used database driver, for SQLite (which is the default driver) this
+ is a filename. Supports variable substitution (see
+ linkgit:git-cvsserver[1] for details). May not contain semicolons (`;`).
+ Default: '%Ggitcvs.%m.sqlite'
+
+gitcvs.dbdriver::
+ Used Perl DBI driver. You can specify any available driver
+ for this here, but it might not work. git-cvsserver is tested
+ with 'DBD::SQLite', reported to work with 'DBD::Pg', and
+ reported *not* to work with 'DBD::mysql'. Experimental feature.
+ May not contain double colons (`:`). Default: 'SQLite'.
+ See linkgit:git-cvsserver[1].
+
+gitcvs.dbuser, gitcvs.dbpass::
+ Database user and password. Only useful if setting 'gitcvs.dbdriver',
+ since SQLite has no concept of database users and/or passwords.
+ 'gitcvs.dbuser' supports variable substitution (see
+ linkgit:git-cvsserver[1] for details).
+
+gitcvs.dbTableNamePrefix::
+ Database table name prefix. Prepended to the names of any
+ database tables used, allowing a single database to be used
+ for several repositories. Supports variable substitution (see
+ linkgit:git-cvsserver[1] for details). Any non-alphabetic
+ characters will be replaced with underscores.
+
+All gitcvs variables except for 'gitcvs.usecrlfattr' and
+'gitcvs.allbinary' can also be specified as
+'gitcvs.<access_method>.<varname>' (where 'access_method'
+is one of "ext" and "pserver") to make them apply only for the given
+access method.
+
+gui.commitmsgwidth::
+ Defines how wide the commit message window is in the
+ linkgit:git-gui[1]. "75" is the default.
+
+gui.diffcontext::
+ Specifies how many context lines should be used in calls to diff
+ made by the linkgit:git-gui[1]. The default is "5".
+
+gui.matchtrackingbranch::
+ Determines if new branches created with linkgit:git-gui[1] should
+ default to tracking remote branches with matching names or
+ not. Default: "false".
+
+gui.newbranchtemplate::
+ Is used as suggested name when creating new branches using the
+ linkgit:git-gui[1].
+
+gui.pruneduringfetch::
+ "true" if linkgit:git-gui[1] should prune tracking branches when
+ performing a fetch. The default value is "false".
+
+gui.trustmtime::
+ Determines if linkgit:git-gui[1] should trust the file modification
+ timestamp or not. By default the timestamps are not trusted.
+
+gui.spellingdictionary::
+ Specifies the dictionary used for spell checking commit messages in
+ the linkgit:git-gui[1]. When set to "none" spell checking is turned
+ off.
+
+help.browser::
+ Specify the browser that will be used to display help in the
+ 'web' format. See linkgit:git-help[1].
+
+help.format::
+ Override the default help format used by linkgit:git-help[1].
+ Values 'man', 'info', 'web' and 'html' are supported. 'man' is
+ the default. 'web' and 'html' are the same.
+
+http.proxy::
+ Override the HTTP proxy, normally configured using the 'http_proxy'
+ environment variable (see linkgit:curl[1]). This can be overridden
+ on a per-remote basis; see remote.<name>.proxy
+
+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.
+
+http.noEPSV::
+ A boolean which disables using of EPSV ftp command by curl.
+ This can helpful with some "poor" ftp servers which don't
+ support EPSV mode. Can be overridden by the 'GIT_CURL_FTP_NO_EPSV'
+ environment variable. Default is false (curl will use EPSV).
+
+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. linkgit:git-mailinfo[1]. Defaults to 'utf-8'.
+
+i18n.logOutputEncoding::
+ Character encoding the commit messages are converted to when
+ running `git-log` and friends.
+
+instaweb.browser::
+ Specify the program that will be used to browse your working
+ repository in gitweb. See linkgit:git-instaweb[1].
+
+instaweb.httpd::
+ The HTTP daemon command-line to start gitweb on your working
+ repository. See linkgit:git-instaweb[1].
+
+instaweb.local::
+ If true the web server started by linkgit:git-instaweb[1] will
+ be bound to the local IP (127.0.0.1).
+
+instaweb.modulepath::
+ The module path for an apache httpd used by linkgit:git-instaweb[1].
+
+instaweb.port::
+ The port number to bind the gitweb httpd to. See
+ linkgit:git-instaweb[1].
+
+log.date::
+ Set default date-time mode for the log command. Setting log.date
+ value is similar to using git log's --date option. The value is one of
+ following alternatives: {relative,local,default,iso,rfc,short}.
+ See linkgit:git-log[1].
+
+log.showroot::
+ If true, the initial commit will be shown as a big creation event.
+ This is equivalent to a diff against an empty tree.
+ Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
+ normally hide the root commit will now show it. True by default.
+
+man.viewer::
+ Specify the programs that may be used to display help in the
+ 'man' format. See linkgit:git-help[1].
+
+include::merge-config.txt[]
+
+man.<tool>.cmd::
+ Specify the command to invoke the specified man viewer. The
+ specified command is evaluated in shell with the man page
+ passed as argument. (See linkgit:git-help[1].)
+
+man.<tool>.path::
+ Override the path for the given tool that may be used to
+ display help in the 'man' format. See linkgit:git-help[1].
+
+mergetool.<tool>.path::
+ Override the path for the given tool. This is useful in case
+ your tool is not in the PATH.
+
+mergetool.<tool>.cmd::
+ Specify the command to invoke the specified merge tool. The
+ specified command is evaluated in shell with the following
+ variables available: 'BASE' is the name of a temporary file
+ containing the common base of the files to be merged, if available;
+ 'LOCAL' is the name of a temporary file containing the contents of
+ the file on the current branch; 'REMOTE' is the name of a temporary
+ file containing the contents of the file from the branch being
+ merged; 'MERGED' contains the name of the file to which the merge
+ tool should write the results of a successful merge.
+
+mergetool.<tool>.trustExitCode::
+ For a custom merge command, specify whether the exit code of
+ the merge command can be used to determine whether the merge was
+ successful. If this is not set to true then the merge target file
+ timestamp is checked and the merge assumed to have been successful
+ if the file has been updated, otherwise the user is prompted to
+ indicate the success of the merge.
+
+mergetool.keepBackup::
+ After performing a merge, the original file with conflict markers
+ can be saved as a file with a `.orig` extension. If this variable
+ is set to `false` then this file is not preserved. Defaults to
+ `true` (i.e. keep the backup files).
+
+pack.window::
+ The size of the window used by linkgit:git-pack-objects[1] when no
+ window size is given on the command line. Defaults to 10.
+
+pack.depth::
+ The maximum delta depth used by linkgit:git-pack-objects[1] when no
+ maximum depth is given on the command line. Defaults to 50.
+
+pack.windowMemory::
+ The window memory size limit used by linkgit:git-pack-objects[1]
+ when no limit is given on the command line. The value can be
+ suffixed with "k", "m", or "g". Defaults to 0, meaning no
+ limit.
+
+pack.compression::
+ An integer -1..9, indicating the compression level for objects
+ in a pack file. -1 is the zlib default. 0 means no
+ compression, and 1..9 are various speed/size tradeoffs, 9 being
+ slowest. If not set, defaults to core.compression. If that is
+ not set, defaults to -1, the zlib default, which is "a default
+ compromise between speed and compression (currently equivalent
+ to level 6)."
+
+pack.deltaCacheSize::
+ The maximum memory in bytes used for caching deltas in
+ linkgit:git-pack-objects[1].
+ A value of 0 means no limit. Defaults to 0.
+
+pack.deltaCacheLimit::
+ The maximum size of a delta, that is cached in
+ linkgit:git-pack-objects[1]. Defaults to 1000.
+
+pack.threads::
+ Specifies the number of threads to spawn when searching for best
+ delta matches. This requires that linkgit:git-pack-objects[1]
+ be compiled with pthreads otherwise this option is ignored with a
+ warning. This is meant to reduce packing time on multiprocessor
+ machines. The required amount of memory for the delta search window
+ is however multiplied by the number of threads.
+ Specifying 0 will cause git to auto-detect the number of CPU's
+ and set the number of threads accordingly.
+
+pack.indexVersion::
+ Specify the default pack index version. Valid values are 1 for
+ legacy pack index used by Git versions prior to 1.5.2, and 2 for
+ the new pack index with capabilities for packs larger than 4 GB
+ as well as proper protection against the repacking of corrupted
+ packs. Version 2 is selected and this config option ignored
+ whenever the corresponding pack is larger than 2 GB. Otherwise
+ the default is 1.
+
+pack.packSizeLimit::
+ The default maximum size of a pack. This setting only affects
+ packing to a file, i.e. the git:// protocol is unaffected. It
+ can be overridden by the `\--max-pack-size` option of
+ linkgit:git-repack[1].
+
+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.
+
+remote.<name>.url::
+ The URL of a remote repository. See linkgit:git-fetch[1] or
+ linkgit:git-push[1].
+
+remote.<name>.proxy::
+ For remotes that require curl (http, https and ftp), the URL to
+ the proxy to use for that remote. Set to the empty string to
+ disable proxying for that remote.
+
+remote.<name>.fetch::
+ The default set of "refspec" for linkgit:git-fetch[1]. See
+ linkgit:git-fetch[1].
+
+remote.<name>.push::
+ The default set of "refspec" for linkgit:git-push[1]. See
+ linkgit:git-push[1].
+
+remote.<name>.mirror::
+ If true, pushing to this remote will automatically behave
+ as if the `\--mirror` option was given on the command line.
+
+remote.<name>.skipDefaultUpdate::
+ If true, this remote will be skipped by default when updating
+ using the update subcommand of linkgit:git-remote[1].
+
+remote.<name>.receivepack::
+ The default program to execute on the remote side when pushing. See
+ option \--receive-pack of linkgit:git-push[1].
+
+remote.<name>.uploadpack::
+ The default program to execute on the remote side when fetching. See
+ option \--upload-pack of linkgit:git-fetch-pack[1].
+
+remote.<name>.tagopt::
+ Setting this value to \--no-tags disables automatic tag following when
+ fetching from remote <name>
+
+remotes.<group>::
+ The list of remotes which are fetched by "git remote update
+ <group>". See linkgit:git-remote[1].
+
+repack.usedeltabaseoffset::
+ Allow linkgit:git-repack[1] to create packs that uses
+ delta-base offset. Defaults to false.
+
+show.difftree::
+ The default linkgit:git-diff-tree[1] arguments to be used
+ for linkgit:git-show[1].
+
+showbranch.default::
+ The default set of branches for linkgit:git-show-branch[1].
+ See linkgit:git-show-branch[1].
+
+status.relativePaths::
+ By default, linkgit:git-status[1] shows paths relative to the
+ current directory. Setting this variable to `false` shows paths
+ relative to the repository root (this was the default for git
+ prior to v1.5.4).
+
+tar.umask::
+ This variable can be used to restrict the permission bits of
+ tar archive entries. The default is 0002, which turns off the
+ world write bit. The special value "user" indicates that the
+ archiving user's umask will be used instead. See umask(2) and
+ linkgit:git-archive[1].
+
+url.<base>.insteadOf::
+ Any URL that starts with this value will be rewritten to
+ start, instead, with <base>. In cases where some site serves a
+ large number of repositories, and serves them with multiple
+ access methods, and some users need to use different access
+ methods, this feature allows people to specify any of the
+ equivalent URLs and have git automatically rewrite the URL to
+ the best alternative for the particular user, even for a
+ never-before-seen repository on the site. When more than one
+ insteadOf strings match a given URL, the longest match is used.
+
+user.email::
+ Your email address to be recorded in any newly created commits.
+ Can be overridden by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and
+ 'EMAIL' environment variables. See linkgit: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 linkgit:git-commit-tree[1].
+
+user.signingkey::
+ If linkgit:git-tag[1] is not selecting the key you want it to
+ automatically when creating a signed tag, you can override the
+ default selection with this variable. This option is passed
+ unchanged to gpg's --local-user parameter, so you may specify a key
+ using any method that gpg supports.
+
+whatchanged.difftree::
+ The default linkgit:git-diff-tree[1] arguments to be used
+ for linkgit:git-whatchanged[1].
+
+imap::
+ The configuration variables in the 'imap' section are described
+ in linkgit:git-imap-send[1].
+
+receive.fsckObjects::
+ If it is set to true, git-receive-pack will check all received
+ objects. It will abort in the case of a malformed object or a
+ broken link. The result of an abort are only dangling objects.
+ Defaults to false.
+
+receive.unpackLimit::
+ If the number of objects received in a push is below this
+ limit then the objects will be unpacked into loose object
+ files. However if the number of received objects equals or
+ exceeds this limit then the received pack will be stored as
+ a pack, after adding any missing delta bases. Storing the
+ pack from a push can make the push operation complete faster,
+ especially on slow filesystems. If not set, the value of
+ `transfer.unpackLimit` is used instead.
+
+receive.denyNonFastForwards::
+ If set to true, git-receive-pack will deny a ref update which is
+ not a fast forward. Use this to prevent such an update via a push,
+ even if that push is forced. This configuration variable is
+ set when initializing a shared repository.
+
+transfer.unpackLimit::
+ When `fetch.unpackLimit` or `receive.unpackLimit` are
+ not set, the value of this variable is used instead.
+ The default value is 100.
+
+web.browser::
+ Specify a web browser that may be used by some commands.
+ Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
+ may use it.
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
new file mode 100644
index 0000000000..400cbb3b1c
--- /dev/null
+++ b/Documentation/diff-format.txt
@@ -0,0 +1,147 @@
+The output format from "git-diff-index", "git-diff-tree",
+"git-diff-files" and "git diff --raw" are very similar.
+
+These commands all compare two sets of things; what is
+compared differs:
+
+git-diff-index <tree-ish>::
+ compares the <tree-ish> and the files on the filesystem.
+
+git-diff-index --cached <tree-ish>::
+ compares the <tree-ish> and the index.
+
+git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>...]::
+ compares the trees named by the two arguments.
+
+git-diff-files [<pattern>...]::
+ compares the index and the files on the filesystem.
+
+
+An output line is formatted this way:
+
+------------------------------------------------
+in-place edit :100644 100644 bcd1234... 0123456... M file0
+copy-edit :100644 100644 abcd123... 1234567... C68 file1 file2
+rename-edit :100644 100644 abcd123... 1234567... R86 file1 file3
+create :000000 100644 0000000... 1234567... A file4
+delete :100644 000000 1234567... 0000000... D file5
+unmerged :000000 000000 0000000... 0000000... U file6
+------------------------------------------------
+
+That is, from the left to the right:
+
+. a colon.
+. mode for "src"; 000000 if creation or unmerged.
+. a space.
+. mode for "dst"; 000000 if deletion or unmerged.
+. a space.
+. sha1 for "src"; 0\{40\} if creation or unmerged.
+. a space.
+. sha1 for "dst"; 0\{40\} if creation, unmerged or "look at work tree".
+. a space.
+. status, followed by optional "score" number.
+. a tab or a NUL when '-z' option is used.
+. path for "src"
+. a tab or a NUL when '-z' option is used; only exists for C or R.
+. path for "dst"; only exists for C or R.
+. an LF or a NUL when '-z' option is used, to terminate the record.
+
+<sha1> is shown as all 0's if a file is new on the filesystem
+and it is out of sync with the index.
+
+Example:
+
+------------------------------------------------
+:100644 100644 5be4a4...... 000000...... M file.c
+------------------------------------------------
+
+When `-z` option is not used, TAB, LF, and backslash characters
+in pathnames are represented as `\t`, `\n`, and `\\`,
+respectively.
+
+diff format for merges
+----------------------
+
+"git-diff-tree", "git-diff-files" and "git-diff --raw"
+can take '-c' or '--cc' option
+to generate diff output also for merge commits. The output differs
+from the format described above in the following way:
+
+. there is a colon for each parent
+. there are more "src" modes and "src" sha1
+. status is concatenated status characters for each parent
+. no optional "score" number
+. single path, only for "dst"
+
+Example:
+
+------------------------------------------------
+::100644 100644 100644 fabadb8... cc95eb0... 4866510... MM describe.c
+------------------------------------------------
+
+Note that 'combined diff' lists only files which were modified from
+all parents.
+
+
+include::diff-generate-patch.txt[]
+
+
+other diff formats
+------------------
+
+The `--summary` option describes newly added, deleted, renamed and
+copied files. The `--stat` option adds diffstat(1) graph to the
+output. These options can be combined with other options, such as
+`-p`, and are meant for human consumption.
+
+When showing a change that involves a rename or a copy, `--stat` output
+formats the pathnames compactly by combining common prefix and suffix of
+the pathnames. For example, a change that moves `arch/i386/Makefile` to
+`arch/x86/Makefile` while modifying 4 lines will be shown like this:
+
+------------------------------------
+arch/{i386 => x86}/Makefile | 4 +--
+------------------------------------
+
+The `--numstat` option gives the diffstat(1) information but is designed
+for easier machine consumption. An entry in `--numstat` output looks
+like this:
+
+----------------------------------------
+1 2 README
+3 1 arch/{i386 => x86}/Makefile
+----------------------------------------
+
+That is, from left to right:
+
+. the number of added lines;
+. a tab;
+. the number of deleted lines;
+. a tab;
+. pathname (possibly with rename/copy information);
+. a newline.
+
+When `-z` output option is in effect, the output is formatted this way:
+
+----------------------------------------
+1 2 README NUL
+3 1 NUL arch/i386/Makefile NUL arch/x86/Makefile NUL
+----------------------------------------
+
+That is:
+
+. the number of added lines;
+. a tab;
+. the number of deleted lines;
+. a tab;
+. a NUL (only exists if renamed/copied);
+. pathname in preimage;
+. a NUL (only exists if renamed/copied);
+. pathname in postimage (only exists if renamed/copied);
+. a NUL.
+
+The extra `NUL` before the preimage path in renamed case is to allow
+scripts that read the output to tell if the current record being read is
+a single-path record or a rename/copy record without reading ahead.
+After reading added and deleted lines, reading up to `NUL` would yield
+the pathname, but if that is `NUL`, the record will show two paths.
diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt
new file mode 100644
index 0000000000..029c5f2b82
--- /dev/null
+++ b/Documentation/diff-generate-patch.txt
@@ -0,0 +1,161 @@
+Generating patches with -p
+--------------------------
+
+When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
+with a '-p' option, "git diff" without the '--raw' option, or
+"git log" with the "-p" option, they
+do not produce the output described above; instead they produce a
+patch file. You can customize the creation of such patches via the
+GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
+
+What the -p option produces is slightly different from the traditional
+diff format.
+
+1. It is preceded with a "git diff" header, that looks like
+ this:
+
+ diff --git a/file1 b/file2
++
+The `a/` and `b/` filenames are the same unless rename/copy is
+involved. Especially, even for a creation or a deletion,
+`/dev/null` is _not_ used in place of `a/` or `b/` filenames.
++
+When rename/copy is involved, `file1` and `file2` show the
+name of the source file of the rename/copy and the name of
+the file that rename/copy produces, respectively.
+
+2. It is followed by one or more extended header lines:
+
+ old mode <mode>
+ new mode <mode>
+ deleted file mode <mode>
+ new file mode <mode>
+ copy from <path>
+ copy to <path>
+ rename from <path>
+ rename to <path>
+ similarity index <number>
+ dissimilarity index <number>
+ index <hash>..<hash> <mode>
+
+3. TAB, LF, double quote and backslash characters in pathnames
+ are represented as `\t`, `\n`, `\"` and `\\`, respectively.
+ If there is need for such substitution then the whole
+ pathname is put in double quotes.
+
+The similarity index is the percentage of unchanged lines, and
+the dissimilarity index is the percentage of changed lines. It
+is a rounded down integer, followed by a percent sign. The
+similarity index value of 100% is thus reserved for two equal
+files, while 100% dissimilarity means that no line from the old
+file made it into the new one.
+
+
+combined diff format
+--------------------
+
+"git-diff-tree", "git-diff-files" and "git-diff" can take '-c' or
+'--cc' option to produce 'combined diff'. For showing a merge commit
+with "git log -p", this is the default format.
+A 'combined diff' format looks like this:
+
+------------
+diff --combined describe.c
+index fabadb8,cc95eb0..4866510
+--- a/describe.c
++++ b/describe.c
+@@@ -98,20 -98,12 +98,20 @@@
+ 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;
+ struct commit_list *list;
+ static int initialized = 0;
+ struct commit_name *n;
+
+ + if (get_sha1(arg, sha1) < 0)
+ + usage(describe_usage);
+ + cmit = lookup_commit_reference(sha1);
+ + if (!cmit)
+ + usage(describe_usage);
+ +
+ if (!initialized) {
+ initialized = 1;
+ for_each_ref(get_name);
+------------
+
+1. It is preceded with a "git diff" header, that looks like
+ this (when '-c' option is used):
+
+ diff --combined file
++
+or like this (when '--cc' option is used):
+
+ diff --c file
+
+2. It is followed by one or more extended header lines
+ (this example shows a merge with two parents):
+
+ index <hash>,<hash>..<hash>
+ mode <mode>,<mode>..<mode>
+ new file mode <mode>
+ deleted file mode <mode>,<mode>
++
+The `mode <mode>,<mode>..<mode>` line appears only if at least one of
+the <mode> is different from the rest. Extended headers with
+information about detected contents movement (renames and
+copying detection) are designed to work with diff of two
+<tree-ish> and are not used by combined diff format.
+
+3. It is followed by two-line from-file/to-file header
+
+ --- a/file
+ +++ b/file
++
+Similar to two-line header for traditional 'unified' diff
+format, `/dev/null` is used to signal created or deleted
+files.
+
+4. Chunk header format is modified to prevent people from
+ accidentally feeding it to `patch -p1`. Combined diff format
+ was created for review of merge commit changes, and was not
+ meant for apply. The change is similar to the change in the
+ extended 'index' header:
+
+ @@@ <from-file-range> <from-file-range> <to-file-range> @@@
++
+There are (number of parents + 1) `@` characters in the chunk
+header for combined diff format.
+
+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 result. A `+` character
+in the column N means that the line appears in the last file,
+and fileN does not have that line (in other words, the line was
+added, from the point of view of that parent).
+
+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").
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
new file mode 100644
index 0000000000..572154834b
--- /dev/null
+++ b/Documentation/diff-options.txt
@@ -0,0 +1,244 @@
+// Please don't remove this comment as asciidoc behaves badly when
+// the first non-empty line is ifdef/ifndef. The symptom is that
+// without this comment the <git-diff-core> attribute conditionally
+// defined below ends up being defined unconditionally.
+// Last checked with asciidoc 7.0.2.
+
+ifndef::git-format-patch[]
+ifndef::git-diff[]
+ifndef::git-log[]
+:git-diff-core: 1
+endif::git-log[]
+endif::git-diff[]
+endif::git-format-patch[]
+
+ifdef::git-format-patch[]
+-p::
+ Generate patches without diffstat.
+endif::git-format-patch[]
+
+ifndef::git-format-patch[]
+-p::
+ Generate patch (see section on generating patches).
+ {git-diff? This is the default.}
+endif::git-format-patch[]
+
+-u::
+ Synonym for "-p".
+
+-U<n>::
+ Shorthand for "--unified=<n>".
+
+--unified=<n>::
+ Generate diffs with <n> lines of context instead of
+ the usual three. Implies "-p".
+
+--raw::
+ Generate the raw format.
+ {git-diff-core? This is the default.}
+
+--patch-with-raw::
+ Synonym for "-p --raw".
+
+--stat[=width[,name-width]]::
+ Generate a diffstat. You can override the default
+ output width for 80-column terminal by "--stat=width".
+ The width of the filename part can be controlled by
+ giving another width to it separated by a comma.
+
+--numstat::
+ Similar to \--stat, but shows number of added and
+ deleted lines in decimal notation and pathname without
+ abbreviation, to make it more machine friendly. For
+ binary files, outputs two `-` instead of saying
+ `0 0`.
+
+--shortstat::
+ Output only the last line of the --stat format containing total
+ number of modified files, as well as number of added and deleted
+ lines.
+
+--dirstat[=limit]::
+ Output only the sub-directories that are impacted by a diff,
+ and to what degree they are impacted. You can override the
+ default cut-off in percent (3) by "--dirstat=limit". If you
+ want to enable "cumulative" directory statistics, you can use
+ the "--cumulative" flag, which adds up percentages recursively
+ even when they have been already reported for a sub-directory.
+
+--summary::
+ Output a condensed summary of extended header information
+ such as creations, renames and mode changes.
+
+--patch-with-stat::
+ Synonym for "-p --stat".
+ {git-format-patch? This is the default.}
+
+-z::
+ NUL-line termination on output. This affects the --raw
+ output field terminator. Also output from commands such
+ as "git-log" will be delimited with NUL between commits.
+
+--name-only::
+ Show only names of changed files.
+
+--name-status::
+ Show only names and status of changed files. See the description
+ of the `--diff-filter` option on what the status letters mean.
+
+--color::
+ Show colored diff.
+
+--no-color::
+ Turn off colored diff, even when the configuration file
+ gives the default to color output.
+
+--color-words::
+ Show colored word diff, i.e. color words which have changed.
+
+--no-renames::
+ Turn off rename detection, even when the configuration
+ file gives the default to do so.
+
+--check::
+ Warn if changes introduce trailing whitespace
+ or an indent that uses a space before a tab. Exits with
+ non-zero status if problems are found. Not compatible with
+ --exit-code.
+
+--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.
+
+--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
+ name in diff-raw format output and diff-tree header
+ lines, show only handful hexdigits prefix. This is
+ independent of --full-index option above, which controls
+ the diff-patch output format. Non default number of
+ digits can be specified with --abbrev=<n>.
+
+-B::
+ Break complete rewrite changes into pairs of delete and create.
+
+-M::
+ Detect renames.
+
+-C::
+ Detect copies as well as renames. See also `--find-copies-harder`.
+
+--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
+ changeset. This flag makes the command
+ inspect unmodified files as candidates for the source of
+ copy. This is a very expensive operation for large
+ projects, so use it with caution. Giving more than one
+ `-C` option has the same effect.
+
+-l<num>::
+ -M and -C options require O(n^2) processing time where n
+ is the number of potential rename/copy targets. This
+ option prevents rename/copy detection from running if
+ the number of rename/copy targets exceeds the specified
+ number.
+
+-S<string>::
+ Look for differences that contain the change in <string>.
+
+--pickaxe-all::
+ When -S finds a change, show all the changes in that
+ 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.
+
+-R::
+ Swap two inputs; that is, show differences from index or
+ on-disk file to tree contents.
+
+--relative[=<path>]::
+ When run from a subdirectory of the project, it can be
+ told to exclude changes outside the directory and show
+ pathnames relative to it with this option. When you are
+ not in a subdirectory (e.g. in a bare repository), you
+ can name which subdirectory to make the output relative
+ to by giving a <path> as an argument.
+
+--text::
+ Treat all files as text.
+
+-a::
+ Shorthand for "--text".
+
+--ignore-space-at-eol::
+ Ignore changes in whitespace at EOL.
+
+--ignore-space-change::
+ Ignore changes in amount of whitespace. This ignores whitespace
+ at line end, and considers all other sequences of one or
+ more whitespace characters to be equivalent.
+
+-b::
+ Shorthand for "--ignore-space-change".
+
+--ignore-all-space::
+ Ignore whitespace when comparing lines. This ignores
+ differences even if one line has whitespace where the other
+ line has none.
+
+-w::
+ Shorthand for "--ignore-all-space".
+
+--exit-code::
+ Make the program exit with codes similar to diff(1).
+ That is, it exits with 1 if there were differences and
+ 0 means no differences.
+
+--quiet::
+ Disable all output of the program. Implies --exit-code.
+
+--ext-diff::
+ Allow an external diff helper to be executed. If you set an
+ external diff driver with linkgit:gitattributes[5], you need
+ to use this option with linkgit:git-log[1] and friends.
+
+--no-ext-diff::
+ Disallow external diff drivers.
+
+--ignore-submodules::
+ Ignore changes to submodules in the diff generation.
+
+--src-prefix=<prefix>::
+ Show the given source prefix instead of "a/".
+
+--dst-prefix=<prefix>::
+ Show the given destination prefix instead of "b/".
+
+--no-prefix::
+ Do not show any source or destination prefix.
+
+For more detailed explanation on these common options, see also
+linkgit:gitdiffcore[7][diffcore documentation].
diff --git a/Documentation/docbook-xsl.css b/Documentation/docbook-xsl.css
new file mode 100644
index 0000000000..b878b385c6
--- /dev/null
+++ b/Documentation/docbook-xsl.css
@@ -0,0 +1,286 @@
+/*
+ CSS stylesheet for XHTML produced by DocBook XSL stylesheets.
+ Tested with XSL stylesheets 1.61.2, 1.67.2
+*/
+
+span.strong {
+ font-weight: bold;
+}
+
+body blockquote {
+ margin-top: .75em;
+ line-height: 1.5;
+ margin-bottom: .75em;
+}
+
+html body {
+ margin: 1em 5% 1em 5%;
+ line-height: 1.2;
+}
+
+body div {
+ margin: 0;
+}
+
+h1, h2, h3, h4, h5, h6,
+div.toc p b,
+div.list-of-figures p b,
+div.list-of-tables p b,
+div.abstract p.title
+{
+ color: #527bbd;
+ font-family: tahoma, verdana, sans-serif;
+}
+
+div.toc p:first-child,
+div.list-of-figures p:first-child,
+div.list-of-tables p:first-child,
+div.example p.title
+{
+ margin-bottom: 0.2em;
+}
+
+body h1 {
+ margin: .0em 0 0 -4%;
+ line-height: 1.3;
+ border-bottom: 2px solid silver;
+}
+
+body h2 {
+ margin: 0.5em 0 0 -4%;
+ line-height: 1.3;
+ border-bottom: 2px solid silver;
+}
+
+body h3 {
+ margin: .8em 0 0 -3%;
+ line-height: 1.3;
+}
+
+body h4 {
+ margin: .8em 0 0 -3%;
+ line-height: 1.3;
+}
+
+body h5 {
+ margin: .8em 0 0 -2%;
+ line-height: 1.3;
+}
+
+body h6 {
+ margin: .8em 0 0 -1%;
+ line-height: 1.3;
+}
+
+body hr {
+ border: none; /* Broken on IE6 */
+}
+div.footnotes hr {
+ border: 1px solid silver;
+}
+
+div.navheader th, div.navheader td, div.navfooter td {
+ font-family: sans-serif;
+ font-size: 0.9em;
+ font-weight: bold;
+ color: #527bbd;
+}
+div.navheader img, div.navfooter img {
+ border-style: none;
+}
+div.navheader a, div.navfooter a {
+ font-weight: normal;
+}
+div.navfooter hr {
+ border: 1px solid silver;
+}
+
+body td {
+ line-height: 1.2
+}
+
+body th {
+ line-height: 1.2;
+}
+
+ol {
+ line-height: 1.2;
+}
+
+ul, body dir, body menu {
+ line-height: 1.2;
+}
+
+html {
+ margin: 0;
+ padding: 0;
+}
+
+body h1, body h2, body h3, body h4, body h5, body h6 {
+ margin-left: 0
+}
+
+body pre {
+ margin: 0.5em 10% 0.5em 1em;
+ line-height: 1.0;
+ color: navy;
+}
+
+tt.literal, code.literal {
+ color: navy;
+}
+
+div.literallayout p {
+ padding: 0em;
+ margin: 0em;
+}
+
+div.literallayout {
+ font-family: monospace;
+# margin: 0.5em 10% 0.5em 1em;
+ margin: 0em;
+ color: navy;
+ border: 1px solid silver;
+ background: #f4f4f4;
+ padding: 0.5em;
+}
+
+.programlisting, .screen {
+ border: 1px solid silver;
+ background: #f4f4f4;
+ margin: 0.5em 10% 0.5em 0;
+ padding: 0.5em 1em;
+}
+
+div.sidebar {
+ background: #ffffee;
+ margin: 1.0em 10% 0.5em 0;
+ padding: 0.5em 1em;
+ border: 1px solid silver;
+}
+div.sidebar * { padding: 0; }
+div.sidebar div { margin: 0; }
+div.sidebar p.title {
+ font-family: sans-serif;
+ margin-top: 0.5em;
+ margin-bottom: 0.2em;
+}
+
+div.bibliomixed {
+ margin: 0.5em 5% 0.5em 1em;
+}
+
+div.glossary dt {
+ font-weight: bold;
+}
+div.glossary dd p {
+ margin-top: 0.2em;
+}
+
+dl {
+ margin: .8em 0;
+ line-height: 1.2;
+}
+
+dt {
+ margin-top: 0.5em;
+}
+
+dt span.term {
+ font-style: italic;
+}
+
+div.variablelist dd p {
+ margin-top: 0;
+}
+
+div.itemizedlist li, div.orderedlist li {
+ margin-left: -0.8em;
+ margin-top: 0.5em;
+}
+
+ul, ol {
+ list-style-position: outside;
+}
+
+div.sidebar ul, div.sidebar ol {
+ margin-left: 2.8em;
+}
+
+div.itemizedlist p.title,
+div.orderedlist p.title,
+div.variablelist p.title
+{
+ margin-bottom: -0.8em;
+}
+
+div.revhistory table {
+ border-collapse: collapse;
+ border: none;
+}
+div.revhistory th {
+ border: none;
+ color: #527bbd;
+ font-family: tahoma, verdana, sans-serif;
+}
+div.revhistory td {
+ border: 1px solid silver;
+}
+
+/* Keep TOC and index lines close together. */
+div.toc dl, div.toc dt,
+div.list-of-figures dl, div.list-of-figures dt,
+div.list-of-tables dl, div.list-of-tables dt,
+div.indexdiv dl, div.indexdiv dt
+{
+ line-height: normal;
+ margin-top: 0;
+ margin-bottom: 0;
+}
+
+/*
+ Table styling does not work because of overriding attributes in
+ generated HTML.
+*/
+div.table table,
+div.informaltable table
+{
+ margin-left: 0;
+ margin-right: 5%;
+ margin-bottom: 0.8em;
+}
+div.informaltable table
+{
+ margin-top: 0.4em
+}
+div.table thead,
+div.table tfoot,
+div.table tbody,
+div.informaltable thead,
+div.informaltable tfoot,
+div.informaltable tbody
+{
+ /* No effect in IE6. */
+ border-top: 2px solid #527bbd;
+ border-bottom: 2px solid #527bbd;
+}
+div.table thead, div.table tfoot,
+div.informaltable thead, div.informaltable tfoot
+{
+ font-weight: bold;
+}
+
+div.mediaobject img {
+ border: 1px solid silver;
+ margin-bottom: 0.8em;
+}
+div.figure p.title,
+div.table p.title
+{
+ margin-top: 1em;
+ margin-bottom: 0.4em;
+}
+
+@media print {
+ div.navheader, div.navfooter { display: none; }
+}
diff --git a/Documentation/docbook.xsl b/Documentation/docbook.xsl
new file mode 100644
index 0000000000..9a6912c641
--- /dev/null
+++ b/Documentation/docbook.xsl
@@ -0,0 +1,5 @@
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+ version='1.0'>
+ <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl"/>
+ <xsl:output method="html" encoding="UTF-8" indent="no" />
+</xsl:stylesheet>
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
new file mode 100644
index 0000000000..e598cdda45
--- /dev/null
+++ b/Documentation/everyday.txt
@@ -0,0 +1,456 @@
+Everyday GIT With 20 Commands Or So
+===================================
+
+<<Basic Repository>> commands are needed by people who have a
+repository --- that is everybody, because every working tree of
+git is a repository.
+
+In addition, <<Individual Developer (Standalone)>> commands are
+essential for anybody who makes a commit, even for somebody who
+works alone.
+
+If you work with other people, you will need commands listed in
+the <<Individual Developer (Participant)>> section as well.
+
+People who play the <<Integrator>> role need to learn some more
+commands in addition to the above.
+
+<<Repository Administration>> commands are for system
+administrators who are responsible for the care and feeding
+of git repositories.
+
+
+Basic Repository[[Basic Repository]]
+------------------------------------
+
+Everybody uses these commands to maintain git repositories.
+
+ * linkgit:git-init[1] or linkgit:git-clone[1] to create a
+ new repository.
+
+ * linkgit:git-fsck[1] to check the repository for errors.
+
+ * linkgit:git-gc[1] to do common housekeeping tasks such as
+ repack and prune.
+
+Examples
+~~~~~~~~
+
+Check health and remove cruft.::
++
+------------
+$ git fsck <1>
+$ git count-objects <2>
+$ git gc <3>
+------------
++
+<1> running without `\--full` is usually cheap and assures the
+repository health reasonably well.
+<2> check how many loose objects there are and how much
+disk space is wasted by not repacking.
+<3> repacks the local repository and performs other housekeeping tasks.
+
+Repack a small project into single pack.::
++
+------------
+$ git gc <1>
+------------
++
+<1> pack all the objects reachable from the refs into one pack,
+then remove the other packs.
+
+
+Individual Developer (Standalone)[[Individual Developer (Standalone)]]
+----------------------------------------------------------------------
+
+A standalone individual developer does not exchange patches with
+other people, and works alone in a single repository, using the
+following commands.
+
+ * linkgit:git-show-branch[1] to see where you are.
+
+ * linkgit:git-log[1] to see what happened.
+
+ * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch
+ branches.
+
+ * linkgit:git-add[1] to manage the index file.
+
+ * linkgit:git-diff[1] and linkgit:git-status[1] to see what
+ you are in the middle of doing.
+
+ * linkgit:git-commit[1] to advance the current branch.
+
+ * linkgit:git-reset[1] and linkgit:git-checkout[1] (with
+ pathname parameters) to undo changes.
+
+ * linkgit:git-merge[1] to merge between local branches.
+
+ * linkgit:git-rebase[1] to maintain topic branches.
+
+ * linkgit:git-tag[1] to mark known point.
+
+Examples
+~~~~~~~~
+
+Use a tarball as a starting point for a new repository.::
++
+------------
+$ tar zxf frotz.tar.gz
+$ cd frotz
+$ git-init
+$ 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.::
++
+------------
+$ git checkout -b alsa-audio <1>
+$ edit/compile/test
+$ git checkout -- curses/ux_audio_oss.c <2>
+$ git add curses/ux_audio_alsa.c <3>
+$ edit/compile/test
+$ git diff HEAD <4>
+$ git commit -a -s <5>
+$ edit/compile/test
+$ git reset --soft HEAD^ <6>
+$ edit/compile/test
+$ git diff ORIG_HEAD <7>
+$ git commit -a -c ORIG_HEAD <8>
+$ git checkout master <9>
+$ git merge 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
+modification will be caught if you do `git commit -a` later.
+<4> to see what changes you are committing.
+<5> commit everything as you have tested, with your sign-off.
+<6> take the last commit back, keeping what is in the working tree.
+<7> look at the changes since the premature commit we took back.
+<8> redo the commit undone in the previous step, using the message
+you originally wrote.
+<9> switch to the master branch.
+<10> merge a topic branch into your master branch.
+<11> review commit logs; other forms to limit output can be
+combined and include `\--max-count=10` (show 10 commits),
+`\--until=2005-12-10`, etc.
+<12> view only the changes that touch what's in `curses/`
+directory, since `v2.43` tag.
+
+
+Individual Developer (Participant)[[Individual Developer (Participant)]]
+------------------------------------------------------------------------
+
+A developer working as a participant in a group project needs to
+learn how to communicate with others, and uses these commands in
+addition to the ones needed by a standalone developer.
+
+ * linkgit:git-clone[1] from the upstream to prime your local
+ repository.
+
+ * linkgit:git-pull[1] and linkgit:git-fetch[1] from "origin"
+ to keep up-to-date with the upstream.
+
+ * linkgit:git-push[1] to shared repository, if you adopt CVS
+ style shared repository workflow.
+
+ * linkgit:git-format-patch[1] to prepare e-mail submission, if
+ you adopt Linux kernel-style public forum workflow.
+
+Examples
+~~~~~~~~
+
+Clone the upstream and work on it. Feed changes to upstream.::
++
+------------
+$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
+$ cd my2.6
+$ edit/compile/test; git commit -a -s <1>
+$ git format-patch origin <2>
+$ git pull <3>
+$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>
+$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>
+$ git reset --hard ORIG_HEAD <6>
+$ git gc <7>
+$ git fetch --tags <8>
+------------
++
+<1> repeat as needed.
+<2> extract patches from your branch for e-mail submission.
+<3> `git pull` fetches from `origin` by default and merges into the
+current branch.
+<4> immediately after pulling, look at the changes done upstream
+since last time we checked, only in the
+area we are interested in.
+<5> fetch from a specific branch from a specific repository and merge.
+<6> revert the pull.
+<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.::
++
+------------
+satellite$ git clone mothership:frotz frotz <1>
+satellite$ cd frotz
+satellite$ git config --get-regexp '^(remote|branch)\.' <2>
+remote.origin.url mothership:frotz
+remote.origin.fetch refs/heads/*:refs/remotes/origin/*
+branch.master.remote origin
+branch.master.merge refs/heads/master
+satellite$ git config remote.origin.push \
+ master:refs/remotes/satellite/master <3>
+satellite$ edit/compile/test/commit
+satellite$ git push origin <4>
+
+mothership$ cd frotz
+mothership$ git checkout master
+mothership$ git merge satellite/master <5>
+------------
++
+<1> mothership machine has a frotz repository under your home
+directory; clone from it to start a repository on the satellite
+machine.
+<2> clone sets these configuration variables by default.
+It arranges `git pull` to fetch and store the branches of mothership
+machine to local `remotes/origin/*` tracking branches.
+<3> arrange `git push` to push local `master` branch to
+`remotes/satellite/master` branch of the mothership machine.
+<4> push will stash our work away on `remotes/satellite/master`
+tracking branch on the 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.::
++
+------------
+$ git checkout -b private2.6.14 v2.6.14 <1>
+$ 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]]
+------------------------
+
+A fairly central person acting as the integrator in a group
+project receives changes made by others, reviews and integrates
+them and publishes the result for others to use, using these
+commands in addition to the ones needed by participants.
+
+ * linkgit:git-am[1] to apply patches e-mailed in from your
+ contributors.
+
+ * linkgit:git-pull[1] to merge from your trusted lieutenants.
+
+ * linkgit:git-format-patch[1] to prepare and send suggested
+ alternative to contributors.
+
+ * linkgit:git-revert[1] to undo botched commits.
+
+ * linkgit:git-push[1] to publish the bleeding edge.
+
+
+Examples
+~~~~~~~~
+
+My typical GIT day.::
++
+------------
+$ git status <1>
+$ git show-branch <2>
+$ mailx <3>
+& s 2 3 4 5 ./+to-apply
+& s 7 8 ./+hold-linus
+& q
+$ git checkout -b topic/one master
+$ git am -3 -i -s -u ./+to-apply <4>
+$ compile/test
+$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5>
+$ git checkout topic/one && git rebase master <6>
+$ git checkout pu && git reset --hard next <7>
+$ git merge topic/one topic/two && git merge hold/linus <8>
+$ git checkout maint
+$ git cherry-pick master~4 <9>
+$ compile/test
+$ 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.
+<3> read mails, save ones that are applicable, and save others
+that are not quite ready.
+<4> apply them, interactively, with my sign-offs.
+<5> create topic branch as needed and apply, again with my
+sign-offs.
+<6> rebase internal topic branch that has not been merged to the
+master, nor exposed as a part of a stable branch.
+<7> restart `pu` every time from the next.
+<8> and bundle topic branches still cooking.
+<9> backport a critical fix.
+<10> create a signed tag.
+<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
+Pull: next:refs/tags/ko-next
+Pull: maint:refs/tags/ko-maint
+Push: master
+Push: next
+Push: +pu
+Push: maint
+------------
++
+In the output from `git show-branch`, `master` should have
+everything `ko-master` has, and `next` should have
+everything `ko-next` has.
+
+<12> push out the bleeding edge.
+<13> push the tag out, too.
+
+
+Repository Administration[[Repository Administration]]
+------------------------------------------------------
+
+A repository administrator uses the following tools to set up
+and maintain access to the repository by developers.
+
+ * linkgit:git-daemon[1] to allow anonymous download from
+ repository.
+
+ * linkgit:git-shell[1] can be used as a 'restricted login shell'
+ for shared central repository users.
+
+link:howto/update-hook-example.txt[update hook howto] has a good
+example of managing a shared central repository.
+
+
+Examples
+~~~~~~~~
+We assume the following in /etc/services::
++
+------------
+$ grep 9418 /etc/services
+git 9418/tcp # Git Version Control System
+------------
+
+Run git-daemon to serve /pub/scm from inetd.::
++
+------------
+$ grep git /etc/inetd.conf
+git stream tcp nowait nobody \
+ /usr/bin/git-daemon git-daemon --inetd --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 --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.::
++
+------------
+$ grep git /etc/passwd <1>
+alice:x:1000:1000::/home/alice:/usr/bin/git-shell
+bob:x:1001:1001::/home/bob:/usr/bin/git-shell
+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.::
++
+------------
+$ grep git /etc/group <1>
+git:x:9418:alice,bob,cindy,david
+$ cd /home/devo.git
+$ ls -l <2>
+ lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD -> refs/heads/master
+ drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches
+ -rw-rw-r-- 1 david git 84 Dec 4 22:40 config
+ -rw-rw-r-- 1 david git 58 Dec 4 22:40 description
+ drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks
+ -rw-rw-r-- 1 david git 37504 Dec 4 22:40 index
+ drwxrwsr-x 2 david git 4096 Dec 4 22:40 info
+ drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects
+ drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs
+ drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes
+$ ls -l hooks/update <3>
+ -r-xr-xr-x 1 david git 3536 Dec 4 22:40 update
+$ 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/
+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.::
++
+------------
+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.
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
new file mode 100644
index 0000000000..85c87180db
--- /dev/null
+++ b/Documentation/fetch-options.txt
@@ -0,0 +1,66 @@
+-q::
+--quiet::
+ Pass --quiet to git-fetch-pack and silence any other internally
+ used programs.
+
+-v::
+--verbose::
+ Be verbose.
+
+-a::
+--append::
+ Append ref names and object names of fetched refs to the
+ 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
+ `<lbranch>` unless the remote branch `<rbranch>` it
+ fetches is a descendant of `<lbranch>`. This option
+ overrides that check.
+
+ifdef::git-pull[]
+--no-tags::
+endif::git-pull[]
+ifndef::git-pull[]
+-n::
+--no-tags::
+endif::git-pull[]
+ By default, tags that point at objects that are downloaded
+ from the remote repository are fetched and stored locally.
+ This option disables this automatic tag following.
+
+-t::
+--tags::
+ Most of the tags are fetched automatically as branch
+ heads are downloaded, but tags that do not point at
+ objects reachable from the branch heads that are being
+ tracked will not be fetched by this mechanism. This
+ flag lets all tags and their associated objects be
+ downloaded.
+
+-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. This is purely for the internal use for `git-pull`
+ to communicate with `git-fetch`, and unless you are
+ implementing your own Porcelain you are not supposed to
+ use it.
+
+--depth=<depth>::
+ Deepen the history of a 'shallow' repository created by
+ `git clone` with `--depth=<depth>` option (see linkgit:git-clone[1])
+ by the specified number of commits.
diff --git a/Documentation/fix-texi.perl b/Documentation/fix-texi.perl
new file mode 100755
index 0000000000..ff7d78f620
--- /dev/null
+++ b/Documentation/fix-texi.perl
@@ -0,0 +1,15 @@
+#!/usr/bin/perl -w
+
+while (<>) {
+ if (/^\@setfilename/) {
+ $_ = "\@setfilename git.info\n";
+ } elsif (/^\@direntry/) {
+ print '@dircategory Development
+@direntry
+* Git: (git). A fast distributed revision control system
+@end direntry
+'; }
+ unless (/^\@direntry/../^\@end direntry/) {
+ print;
+ }
+}
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
new file mode 100644
index 0000000000..9c6b081e6c
--- /dev/null
+++ b/Documentation/git-add.txt
@@ -0,0 +1,272 @@
+git-add(1)
+==========
+
+NAME
+----
+git-add - Add file contents to the index
+
+SYNOPSIS
+--------
+[verse]
+'git-add' [-n] [-v] [-f] [--interactive | -i] [--patch | -p] [-u] [--refresh]
+ [--ignore-errors] [--] <filepattern>...
+
+DESCRIPTION
+-----------
+This command adds the current content of new or modified files to the
+index, thus staging that content for inclusion in the next commit.
+
+The "index" holds a snapshot of the content of the working tree, and it
+is this snapshot that is taken as the contents of the next commit. Thus
+after making any changes to the working directory, and before running
+the commit command, you must use the 'add' command to add any new or
+modified files to the index.
+
+This command can be performed multiple times before a commit. It only
+adds the content of the specified file(s) at the time the add command is
+run; if you want subsequent changes included in the next commit, then
+you must run 'git add' again to add the new content to the index.
+
+The 'git status' command can be used to obtain a summary of which
+files have changes that are staged for the next commit.
+
+The 'git add' command will not add ignored files by default. If any
+ignored files were explicitly specified on the command line, 'git add'
+will fail with a list of ignored files. Ignored files reached by
+directory recursion or filename globbing performed by Git (quote your
+globs before the shell) will be silently ignored. The 'add' command can
+be used to add ignored files with the `-f` (force) option.
+
+Please see linkgit:git-commit[1] for alternative ways to add content to a
+commit.
+
+
+OPTIONS
+-------
+<filepattern>...::
+ Files to add content from. Fileglobs (e.g. `*.c`) can
+ be given to add all matching files. Also a
+ leading directory name (e.g. `dir` to add `dir/file1`
+ and `dir/file2`) can be given to add all files in the
+ directory, recursively.
+
+-n::
+--dry-run::
+ Don't actually add the file(s), just show if they exist.
+
+-v::
+--verbose::
+ Be verbose.
+
+-f::
+ Allow adding otherwise ignored files.
+
+-i::
+--interactive::
+ Add modified contents in the working tree interactively to
+ the index. Optional path arguments may be supplied to limit
+ operation to a subset of the working tree. See ``Interactive
+ mode'' for details.
+
+-p::
+--patch::
+ Similar to Interactive mode but the initial command loop is
+ bypassed and the 'patch' subcommand is invoked using each of
+ the specified filepatterns before exiting.
+
+-u::
+ Update only files that git already knows about, staging modified
+ content for commit and marking deleted files for removal. This
+ is similar
+ to what "git commit -a" does in preparation for making a commit,
+ except that the update is limited to paths specified on the
+ command line. If no paths are specified, all tracked files in the
+ current directory and its subdirectories are updated.
+
+--refresh::
+ Don't add the file(s), but only refresh their stat()
+ information in the index.
+
+--ignore-errors::
+ If some files could not be added because of errors indexing
+ them, do not abort the operation, but continue adding the
+ others. The command shall still exit with non-zero status.
+
+\--::
+ 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).
+
+
+Configuration
+-------------
+
+The optional configuration variable 'core.excludesfile' indicates a path to a
+file containing patterns of file names to exclude from git-add, similar to
+$GIT_DIR/info/exclude. Patterns in the exclude file are used in addition to
+those in info/exclude. See linkgit:gitrepository-layout[5][repository layout].
+
+
+EXAMPLES
+--------
+
+* Adds content from all `\*.txt` files under `Documentation` directory
+and its subdirectories:
++
+------------
+$ git add Documentation/\\*.txt
+------------
++
+Note that the asterisk `\*` is quoted from the shell in this
+example; this lets the command to include the files from
+subdirectories of `Documentation/` directory.
+
+* Considers adding content from all git-*.sh scripts:
++
+------------
+$ git add git-*.sh
+------------
++
+Because this example lets shell expand the asterisk (i.e. you are
+listing the files explicitly), it does not consider
+`subdir/git-foo.sh`.
+
+Interactive mode
+----------------
+When the command enters the interactive mode, it shows the
+output of the 'status' subcommand, and then goes into its
+interactive command loop.
+
+The command loop shows the list of subcommands available, and
+gives a prompt "What now> ". In general, when the prompt ends
+with a single '>', you can pick only one of the choices given
+and type return, like this:
+
+------------
+ *** Commands ***
+ 1: status 2: update 3: revert 4: add untracked
+ 5: patch 6: diff 7: quit 8: help
+ What now> 1
+------------
+
+You also could say "s" or "sta" or "status" above as long as the
+choice is unique.
+
+The main command loop has 6 subcommands (plus help and quit).
+
+status::
+
+ This shows the change between HEAD and index (i.e. what will be
+ committed if you say "git commit"), and between index and
+ working tree files (i.e. what you could stage further before
+ "git commit" using "git-add") for each path. A sample output
+ looks like this:
++
+------------
+ staged unstaged path
+ 1: binary nothing foo.png
+ 2: +403/-35 +1/-1 git-add--interactive.perl
+------------
++
+It shows that foo.png has differences from HEAD (but that is
+binary so line count cannot be shown) and there is no
+difference between indexed copy and the working tree
+version (if the working tree version were also different,
+'binary' would have been shown in place of 'nothing'). The
+other file, git-add--interactive.perl, has 403 lines added
+and 35 lines deleted if you commit what is in the index, but
+working tree file has further modifications (one addition and
+one deletion).
+
+update::
+
+ This shows the status information and gives prompt
+ "Update>>". When the prompt ends with double '>>', you can
+ make more than one selection, concatenated with whitespace or
+ comma. Also you can say ranges. E.g. "2-5 7,9" to choose
+ 2,3,4,5,7,9 from the list. You can say '*' to choose
+ everything.
++
+What you chose are then highlighted with '*',
+like this:
++
+------------
+ staged unstaged path
+ 1: binary nothing foo.png
+* 2: +403/-35 +1/-1 git-add--interactive.perl
+------------
++
+To remove selection, prefix the input with `-`
+like this:
++
+------------
+Update>> -2
+------------
++
+After making the selection, answer with an empty line to stage the
+contents of working tree files for selected paths in the index.
+
+revert::
+
+ This has a very similar UI to 'update', and the staged
+ information for selected paths are reverted to that of the
+ HEAD version. Reverting new paths makes them untracked.
+
+add untracked::
+
+ This has a very similar UI to 'update' and
+ 'revert', and lets you add untracked paths to the index.
+
+patch::
+
+ This lets you choose one path out of 'status' like selection.
+ After choosing the path, it presents diff between the index
+ and the working tree file and asks you if you want to stage
+ the change of each hunk. You can say:
+
+ y - stage this hunk
+ n - do not stage this hunk
+ a - stage this and all the remaining hunks in the file
+ d - do not stage this hunk nor any of the remaining hunks in the file
+ j - leave this hunk undecided, see next undecided hunk
+ J - leave this hunk undecided, see next hunk
+ k - leave this hunk undecided, see previous undecided hunk
+ K - leave this hunk undecided, see previous hunk
+ s - split the current hunk into smaller hunks
+ ? - print help
++
+After deciding the fate for all hunks, if there is any hunk
+that was chosen, the index is updated with the selected hunks.
+
+diff::
+
+ This lets you review what will be committed (i.e. between
+ HEAD and index).
+
+Bugs
+----
+The interactive mode does not work with files whose names contain
+characters that need C-quoting. `core.quotepath` configuration can be
+used to work this limitation around to some degree, but backslash,
+double-quote and control characters will still have problems.
+
+SEE ALSO
+--------
+linkgit:git-status[1]
+linkgit:git-rm[1]
+linkgit:git-reset[1]
+linkgit:git-mv[1]
+linkgit:git-commit[1]
+linkgit:git-update-index[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 linkgit:git[1] suite
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
new file mode 100644
index 0000000000..46544a0769
--- /dev/null
+++ b/Documentation/git-am.txt
@@ -0,0 +1,164 @@
+git-am(1)
+=========
+
+NAME
+----
+git-am - Apply a series of patches from a mailbox
+
+
+SYNOPSIS
+--------
+[verse]
+'git-am' [--signoff] [--keep] [--utf8 | --no-utf8]
+ [--3way] [--interactive] [--binary]
+ [--whitespace=<option>] [-C<n>] [-p<n>]
+ <mbox>|<Maildir>...
+'git-am' [--skip | --resolved]
+
+DESCRIPTION
+-----------
+Splits mail messages in a mailbox into commit log message,
+authorship information and patches, and applies them to the
+current branch.
+
+OPTIONS
+-------
+<mbox>|<Maildir>...::
+ The list of mailbox files to read patches from. If you do not
+ supply this argument, reads from the standard input. If you supply
+ directories, they'll be treated as Maildirs.
+
+-s::
+--signoff::
+ Add `Signed-off-by:` line to the commit message, using
+ the committer identity of yourself.
+
+-k::
+--keep::
+ Pass `-k` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).
+
+-u::
+--utf8::
+ Pass `-u` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).
+ The proposed commit log message taken from the e-mail
+ is re-coded into UTF-8 encoding (configuration variable
+ `i18n.commitencoding` can be used to specify project's
+ preferred encoding if it is not UTF-8).
++
+This was optional in prior versions of git, but now it is the
+default. You could use `--no-utf8` to override this.
+
+--no-utf8::
+ Pass `-n` flag to `git-mailinfo` (see
+ linkgit:git-mailinfo[1]).
+
+-3::
+--3way::
+ When the patch does not apply cleanly, fall back on
+ 3-way merge, if the patch records the identity of blobs
+ it is supposed to apply to, and we have those blobs
+ available locally.
+
+-b::
+--binary::
+ Pass `--allow-binary-replacement` flag to `git-apply`
+ (see linkgit:git-apply[1]).
+
+--whitespace=<option>::
+ This flag is passed to the `git-apply` (see linkgit:git-apply[1])
+ program that applies
+ the patch.
+
+-C<n>::
+-p<n>::
+ These flags are passed to the `git-apply` (see linkgit:git-apply[1])
+ program that applies
+ the patch.
+
+-i::
+--interactive::
+ Run interactively.
+
+--skip::
+ Skip the current patch. This is only meaningful when
+ restarting an aborted patch.
+
+-r::
+--resolved::
+ After a patch failure (e.g. attempting to apply
+ conflicting patch), the user has applied it by hand and
+ the index file stores the result of the application.
+ Make a commit using the authorship and commit log
+ extracted from the e-mail message and the current index
+ file, and continue.
+
+--resolvemsg=<msg>::
+ When a patch failure occurs, <msg> will be printed
+ to the screen before exiting. This overrides the
+ standard message informing you to use `--resolved`
+ or `--skip` to handle the failure. This is solely
+ for internal use between `git-rebase` and `git-am`.
+
+DISCUSSION
+----------
+
+The commit author name is taken from the "From: " line of the
+message, and commit author time is taken from the "Date: " line
+of the message. The "Subject: " line is used as the title of
+the commit, after stripping common prefix "[PATCH <anything>]".
+It is supposed to describe what the commit is about concisely as
+a one line text.
+
+The body of the message (iow, after a blank line that terminates
+RFC2822 headers) can begin with "Subject: " and "From: " lines
+that are different from those of the mail header, to override
+the values of these fields.
+
+The commit message is formed by the title taken from the
+"Subject: ", a blank line and the body of the message up to
+where the patch begins. Excess whitespaces at the end of the
+lines are automatically stripped.
+
+The patch is expected to be inline, directly following the
+message. Any line that is of form:
+
+* three-dashes and end-of-line, or
+* a line that begins with "diff -", or
+* a line that begins with "Index: "
+
+is taken as the beginning of a patch, and the commit log message
+is terminated before the first occurrence of such a line.
+
+When initially invoking it, you give it names of the mailboxes
+to crunch. Upon seeing the first patch that does not apply, it
+aborts in the middle,. You can recover from this in one of two ways:
+
+. skip the current patch by re-running the command with '--skip'
+ option.
+
+. hand resolve the conflict in the working directory, and update
+ the index file to bring it in a state that the patch should
+ have produced. Then run the command with '--resolved' option.
+
+The command refuses to process new mailboxes while `.dotest`
+directory exists, so if you decide to start over from scratch,
+run `rm -f -r .dotest` before running the command with mailbox
+names.
+
+
+SEE ALSO
+--------
+linkgit:git-apply[1].
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-annotate.txt b/Documentation/git-annotate.txt
new file mode 100644
index 0000000000..da15379ae5
--- /dev/null
+++ b/Documentation/git-annotate.txt
@@ -0,0 +1,31 @@
+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
+-------
+include::blame-options.txt[]
+
+SEE ALSO
+--------
+linkgit:git-blame[1]
+
+AUTHOR
+------
+Written by Ryan Anderson <ryan@michonline.com>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
new file mode 100644
index 0000000000..c8347637da
--- /dev/null
+++ b/Documentation/git-apply.txt
@@ -0,0 +1,212 @@
+git-apply(1)
+============
+
+NAME
+----
+git-apply - Apply a patch on a git index file and a working tree
+
+
+SYNOPSIS
+--------
+[verse]
+'git-apply' [--stat] [--numstat] [--summary] [--check] [--index]
+ [--apply] [--no-add] [--build-fake-ancestor <file>] [-R | --reverse]
+ [--allow-binary-replacement | --binary] [--reject] [-z]
+ [-pNUM] [-CNUM] [--inaccurate-eof] [--cached]
+ [--whitespace=<nowarn|warn|fix|error|error-all>]
+ [--exclude=PATH] [--verbose] [<patch>...]
+
+DESCRIPTION
+-----------
+Reads supplied diff output and applies it on a git index file
+and a work tree.
+
+OPTIONS
+-------
+<patch>...::
+ The files to read patch from. '-' can be used to read
+ from the standard input.
+
+--stat::
+ Instead of applying the patch, output diffstat for the
+ input. Turns off "apply".
+
+--numstat::
+ Similar to \--stat, but shows number of added and
+ deleted lines in decimal notation and pathname without
+ abbreviation, to make it more machine friendly. For
+ binary files, outputs two `-` instead of saying
+ `0 0`. Turns off "apply".
+
+--summary::
+ Instead of applying the patch, output a condensed
+ summary of information obtained from git diff extended
+ headers, such as creations, renames and mode changes.
+ Turns off "apply".
+
+--check::
+ Instead of applying the patch, see if the patch is
+ applicable to the current work tree and/or the index
+ file and detects errors. Turns off "apply".
+
+--index::
+ When --check is in effect, or when applying the patch
+ (which is the default when none of the options that
+ disables it is in effect), make sure the patch is
+ applicable to what the current index file records. If
+ the file to be patched in the work tree is not
+ up-to-date, it is flagged as an error. This flag also
+ causes the index file to be updated.
+
+--cached::
+ Apply a patch without touching the working tree. Instead, take the
+ cached data, apply the patch, and store the result in the index,
+ without using the working tree. This implies '--index'.
+
+--build-fake-ancestor <file>::
+ Newer git-diff output has embedded 'index information'
+ for each blob to help identify the original version that
+ the patch applies to. When this flag is given, and if
+ the original versions of the blobs is available locally,
+ builds a temporary index containing those blobs.
++
+When a pure mode change is encountered (which has no index information),
+the information is read from the current index instead.
+
+-R::
+--reverse::
+ Apply the patch in reverse.
+
+--reject::
+ For atomicity, linkgit:git-apply[1] by default fails the whole patch and
+ does not touch the working tree when some of the hunks
+ do not apply. This option makes it apply
+ the parts of the patch that are applicable, and leave the
+ rejected hunks in corresponding *.rej files.
+
+-z::
+ When showing the index information, do not munge paths,
+ but use NUL terminated machine readable format. Without
+ this flag, the pathnames output will have TAB, LF, and
+ 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.
+
+--unidiff-zero::
+ By default, linkgit:git-apply[1] expects that the patch being
+ applied is a unified diff with at least one line of context.
+ This provides good safety measures, but breaks down when
+ applying a diff generated with --unified=0. To bypass these
+ checks use '--unidiff-zero'.
++
+Note, for the reasons stated above usage of context-free patches are
+discouraged.
+
+--apply::
+ If you use any of the options marked "Turns off
+ 'apply'" above, linkgit:git-apply[1] reads and outputs the
+ information you asked without actually applying the
+ patch. Give this flag after those flags to also apply
+ the patch.
+
+--no-add::
+ When applying a patch, ignore additions made by the
+ patch. This can be used to extract the common part between
+ two files by first running `diff` on them and applying
+ the result with this option, which would apply the
+ deletion part but not addition part.
+
+--allow-binary-replacement::
+--binary::
+ Historically we did not allow binary patch applied
+ without an explicit permission from the user, and this
+ flag was the way to do so. Currently we always allow binary
+ patch application, so this is a no-op.
+
+--exclude=<path-pattern>::
+ Don't apply changes to files matching the given path pattern. This can
+ be useful when importing patchsets, where you want to exclude certain
+ files or directories.
+
+--whitespace=<action>::
+ When applying a patch, detect a new or modified line that has
+ whitespace errors. What are considered whitespace errors is
+ controlled by `core.whitespace` configuration. By default,
+ trailing whitespaces (including lines that solely consist of
+ whitespaces) and a space character that is immediately followed
+ by a tab character inside the initial indent of the line are
+ considered whitespace errors.
++
+By default, the command outputs warning messages but applies the patch.
+When linkgit:git-apply[1] is used for statistics and not applying a
+patch, it defaults to `nowarn`.
++
+You can use different `<action>` to control this
+behavior:
++
+* `nowarn` turns off the trailing whitespace warning.
+* `warn` outputs warnings for a few such errors, but applies the
+ patch as-is (default).
+* `fix` outputs warnings for a few such errors, and applies the
+ patch after fixing them (`strip` is a synonym --- the tool
+ used to consider only trailing whitespaces as errors, and the
+ fix involved 'stripping' them, but modern gits do more).
+* `error` outputs warnings for a few such errors, and refuses
+ to apply the patch.
+* `error-all` is similar to `error` but shows all errors.
+
+--inaccurate-eof::
+ Under certain circumstances, some versions of diff do not correctly
+ detect a missing new-line at the end of the file. As a result, patches
+ created by such diff programs do not record incomplete lines
+ correctly. This option adds support for applying such patches by
+ working around this bug.
+
+-v::
+--verbose::
+ Report progress to stderr. By default, only a message about the
+ current patch being applied will be printed. This option will cause
+ additional information to be reported.
+
+Configuration
+-------------
+
+apply.whitespace::
+ When no `--whitespace` flag is given from the command
+ line, this configuration item is used as the default.
+
+Submodules
+----------
+If the patch contains any changes to submodules then linkgit:git-apply[1]
+treats these changes as follows.
+
+If --index is specified (explicitly or implicitly), then the submodule
+commits must match the index exactly for the patch to apply. If any
+of the submodules are checked-out, then these check-outs are completely
+ignored, i.e., they are not required to be up-to-date or clean and they
+are not updated.
+
+If --index is not specified, then the submodule commits in the patch
+are ignored and only the absence of presence of the corresponding
+subdirectory is checked and (if possible) updated.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-archimport.txt b/Documentation/git-archimport.txt
new file mode 100644
index 0000000000..603117c796
--- /dev/null
+++ b/Documentation/git-archimport.txt
@@ -0,0 +1,120 @@
+git-archimport(1)
+=================
+
+NAME
+----
+git-archimport - Import an Arch repository into git
+
+
+SYNOPSIS
+--------
+[verse]
+'git-archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
+ <archive/branch>[:<git-branch>] ...
+
+DESCRIPTION
+-----------
+Imports a project from one or more Arch repositories. It will follow branches
+and repositories within the namespaces defined by the <archive/branch>
+parameters supplied. If it cannot find the remote branch a merge comes from
+it will just import it as a regular commit. If it can find it, it will mark it
+as a merge whenever possible (see discussion below).
+
+The script expects you to provide the key roots where it can start the import
+from an 'initial import' or 'tag' type of Arch commit. It will follow and
+import new branches within the provided roots.
+
+It expects to be dealing with one project only. If it sees
+branches that have different roots, it will refuse to run. In that case,
+edit your <archive/branch> parameters to define clearly the scope of the
+import.
+
+`git-archimport` uses `tla` extensively in the background to access the
+Arch repository.
+Make sure you have a recent version of `tla` available in the path. `tla` must
+know about the repositories you pass to `git-archimport`.
+
+For the initial import `git-archimport` expects to find itself in an empty
+directory. To follow the development of a project that uses Arch, rerun
+`git-archimport` with the same parameters as the initial import to perform
+incremental imports.
+
+While git-archimport will try to create sensible branch names for the
+archives that it imports, it is also possible to specify git branch names
+manually. To do so, write a git branch name after each <archive/branch>
+parameter, separated by a colon. This way, you can shorten the Arch
+branch names and convert Arch jargon to git jargon, for example mapping a
+"PROJECT--devo--VERSION" branch to "master".
+
+Associating multiple Arch branches to one git branch is possible; the
+result will make the most sense only if no commits are made to the first
+branch, after the second branch is created. Still, this is useful to
+convert Arch repositories that had been rotated periodically.
+
+
+MERGES
+------
+Patch merge data from Arch is used to mark merges in git as well. git
+does not care much about tracking patches, and only considers a merge when a
+branch incorporates all the commits since the point they forked. The end result
+is that git will have a good idea of how far branches have diverged. So the
+import process does lose some patch-trading metadata.
+
+Fortunately, when you try and merge branches imported from Arch,
+git will find a good merge base, and it has a good chance of identifying
+patches that have been traded out-of-sequence between the branches.
+
+OPTIONS
+-------
+
+-h::
+ Display usage.
+
+-v::
+ Verbose output.
+
+-T::
+ Many tags. Will create a tag for every commit, reflecting the commit
+ name in the Arch repository.
+
+-f::
+ Use the fast patchset import strategy. This can be significantly
+ faster for large trees, but cannot handle directory renames or
+ permissions changes. The default strategy is slow and safe.
+
+-o::
+ Use this for compatibility with old-style branch names used by
+ earlier versions of git-archimport. Old-style branch names
+ were category--branch, whereas new-style branch names are
+ archive,category--branch--version. In both cases, names given
+ on the command-line will override the automatically-generated
+ ones.
+
+-D <depth>::
+ Follow merge ancestry and attempt to import trees that have been
+ merged from. Specify a depth greater than 1 if patch logs have been
+ pruned.
+
+-a::
+ Attempt to auto-register archives at http://mirrors.sourcecontrol.net
+ This is particularly useful with the -D option.
+
+-t <tmpdir>::
+ Override the default tempdir.
+
+
+<archive/branch>::
+ Archive/branch identifier in a format that `tla log` understands.
+
+
+Author
+------
+Written by Martin Langhoff <martin@catalyst.net.nz>.
+
+Documentation
+--------------
+Documentation by Junio C Hamano, Martin Langhoff and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
new file mode 100644
index 0000000000..9b5f3ae5ed
--- /dev/null
+++ b/Documentation/git-archive.txt
@@ -0,0 +1,123 @@
+git-archive(1)
+==============
+
+NAME
+----
+git-archive - Create an archive of files from a named tree
+
+
+SYNOPSIS
+--------
+[verse]
+'git-archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
+ [--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
+ [path...]
+
+DESCRIPTION
+-----------
+Creates an archive of the specified format containing the tree
+structure for the named tree, and writes it out to the standard
+output. If <prefix> is specified it is
+prepended to the filenames in the archive.
+
+'git-archive' behaves differently when given a tree ID versus when
+given a commit ID or tag ID. In the first case the current time is
+used as modification time of each file in the archive. In the latter
+case the commit time as recorded in the referenced commit object is
+used instead. Additionally the commit ID is stored in a global
+extended pax header if the tar format is used; it can be extracted
+using 'git-get-tar-commit-id'. In ZIP files it is stored as a file
+comment.
+
+OPTIONS
+-------
+
+--format=<fmt>::
+ Format of the resulting archive: 'tar' or 'zip'. The default
+ is 'tar'.
+
+-l::
+--list::
+ Show all available formats.
+
+-v::
+--verbose::
+ Report progress to stderr.
+
+--prefix=<prefix>/::
+ Prepend <prefix>/ to each filename in the archive.
+
+<extra>::
+ This can be any options that the archiver backend understand.
+ See next section.
+
+--remote=<repo>::
+ Instead of making a tar archive from local repository,
+ retrieve a tar archive from a remote repository.
+
+--exec=<git-upload-archive>::
+ Used with --remote to specify the path to the
+ git-upload-archive executable on the remote side.
+
+<tree-ish>::
+ The tree or commit to produce an archive for.
+
+path::
+ If one or more paths are specified, include only these in the
+ archive, otherwise include all files and subdirectories.
+
+BACKEND EXTRA OPTIONS
+---------------------
+
+zip
+~~~
+-0::
+ Store the files instead of deflating them.
+-9::
+ Highest and slowest compression level. You can specify any
+ number from 1 to 9 to adjust compression speed and ratio.
+
+
+CONFIGURATION
+-------------
+
+tar.umask::
+ This variable can be used to restrict the permission bits of
+ tar archive entries. The default is 0002, which turns off the
+ world write bit. The special value "user" indicates that the
+ archiving user's umask will be used instead. See umask(2) for
+ details.
+
+EXAMPLES
+--------
+git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)::
+
+ Create a tar archive that contains the contents of the
+ latest commit on the current branch, and extracts it in
+ `/var/tmp/junk` directory.
+
+git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz::
+
+ Create a compressed tarball for v1.4.0 release.
+
+git archive --format=tar --prefix=git-1.4.0/ v1.4.0{caret}\{tree\} | gzip >git-1.4.0.tar.gz::
+
+ Create a compressed tarball for v1.4.0 release, but without a
+ global extended pax header.
+
+git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs.zip::
+
+ Put everything in the current head's Documentation/ directory
+ into 'git-1.4.0-docs.zip', with the prefix 'git-docs/'.
+
+Author
+------
+Written by Franck Bui-Huu and Rene Scharfe.
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
new file mode 100644
index 0000000000..37c7acbe9f
--- /dev/null
+++ b/Documentation/git-bisect.txt
@@ -0,0 +1,286 @@
+git-bisect(1)
+=============
+
+NAME
+----
+git-bisect - Find the change that introduced a bug by binary search
+
+
+SYNOPSIS
+--------
+'git bisect' <subcommand> <options>
+
+DESCRIPTION
+-----------
+The command takes various subcommands, and different options depending
+on the subcommand:
+
+ git bisect help
+ git bisect start [<bad> [<good>...]] [--] [<paths>...]
+ git bisect bad [<rev>]
+ git bisect good [<rev>...]
+ git bisect skip [<rev>...]
+ git bisect reset [<branch>]
+ git bisect visualize
+ git bisect replay <logfile>
+ git bisect log
+ git bisect run <cmd>...
+
+This command uses 'git-rev-list --bisect' option to help drive the
+binary search process to find which change introduced a bug, given an
+old "good" commit object name and a later "bad" commit object name.
+
+Getting help
+~~~~~~~~~~~~
+
+Use "git bisect" to get a short usage description, and "git bisect
+help" or "git bisect -h" to get a long usage description.
+
+Basic bisect commands: start, bad, good
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The way you use it is:
+
+------------------------------------------------
+$ git bisect start
+$ git bisect bad # Current version is bad
+$ git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version
+ # tested that was good
+------------------------------------------------
+
+When you give at least one bad and one good versions, it will bisect
+the revision tree and say something like:
+
+------------------------------------------------
+Bisecting: 675 revisions left to test after this
+------------------------------------------------
+
+and check out the state in the middle. Now, compile that kernel, and
+boot it. Now, let's say that this booted kernel works fine, then just
+do
+
+------------------------------------------------
+$ git bisect good # this one is good
+------------------------------------------------
+
+which will now say
+
+------------------------------------------------
+Bisecting: 337 revisions left to test after this
+------------------------------------------------
+
+and you continue along, compiling that one, testing it, and depending
+on whether it is good or bad, you say "git bisect good" or "git bisect
+bad", and ask for the next bisection.
+
+Until you have no more left, and you'll have been left with the first
+bad kernel rev in "refs/bisect/bad".
+
+Bisect reset
+~~~~~~~~~~~~
+
+Oh, and then after you want to reset to the original head, do a
+
+------------------------------------------------
+$ git bisect reset
+------------------------------------------------
+
+to get back to the original branch, instead of being in one of the
+bisection branches ("git bisect start" will do that for you too,
+actually: it will reset the bisection state, and before it does that
+it checks that you're not using some old bisection branch).
+
+Bisect visualize
+~~~~~~~~~~~~~~~~
+
+During the bisection process, you can say
+
+------------
+$ git bisect visualize
+------------
+
+to see the currently remaining suspects in `gitk`. `visualize` is a bit
+too long to type and `view` is provided as a synonym.
+
+If `DISPLAY` environment variable is not set, `git log` is used
+instead. You can even give command line options such as `-p` and
+`--stat`.
+
+------------
+$ git bisect view --stat
+------------
+
+Bisect log and bisect replay
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The good/bad input is logged, and
+
+------------
+$ git bisect log
+------------
+
+shows what you have done so far. You can truncate its output somewhere
+and save it in a file, and run
+
+------------
+$ git bisect replay that-file
+------------
+
+if you find later you made a mistake telling good/bad about a
+revision.
+
+Avoiding to test a commit
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If in a middle of bisect session, you know what the bisect suggested
+to try next is not a good one to test (e.g. the change the commit
+introduces is known not to work in your environment and you know it
+does not have anything to do with the bug you are chasing), you may
+want to find a near-by commit and try that instead.
+
+It goes something like this:
+
+------------
+$ git bisect good/bad # previous round was good/bad.
+Bisecting: 337 revisions left to test after this
+$ git bisect visualize # oops, that is uninteresting.
+$ git reset --hard HEAD~3 # try 3 revs before what
+ # was suggested
+------------
+
+Then compile and test the one you chose to try. After that, tell
+bisect what the result was as usual.
+
+Bisect skip
+~~~~~~~~~~~~
+
+Instead of choosing by yourself a nearby commit, you may just want git
+to do it for you using:
+
+------------
+$ git bisect skip # Current version cannot be tested
+------------
+
+But computing the commit to test may be slower afterwards and git may
+eventually not be able to tell the first bad among a bad and one or
+more "skip"ped commits.
+
+Cutting down bisection by giving more parameters to bisect start
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can further cut down the number of trials if you know what part of
+the tree is involved in the problem you are tracking down, by giving
+paths parameters when you say `bisect start`, like this:
+
+------------
+$ git bisect start -- arch/i386 include/asm-i386
+------------
+
+If you know beforehand more than one good commits, you can narrow the
+bisect space down without doing the whole tree checkout every time you
+give good commits. You give the bad revision immediately after `start`
+and then you give all the good revisions you have:
+
+------------
+$ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 --
+ # v2.6.20-rc6 is bad
+ # v2.6.20-rc4 and v2.6.20-rc1 are good
+------------
+
+Bisect run
+~~~~~~~~~~
+
+If you have a script that can tell if the current source code is good
+or bad, you can automatically bisect using:
+
+------------
+$ git bisect run my_script
+------------
+
+Note that the "run" script (`my_script` in the above example) should
+exit with code 0 in case the current source code is good. Exit with a
+code between 1 and 127 (inclusive), except 125, if the current
+source code is bad.
+
+Any other exit code will abort the automatic bisect process. (A
+program that does "exit(-1)" leaves $? = 255, see exit(3) manual page,
+the value is chopped with "& 0377".)
+
+The special exit code 125 should be used when the current source code
+cannot be tested. If the "run" script exits with this code, the current
+revision will be skipped, see `git bisect skip` above.
+
+You may often find that during bisect you want to have near-constant
+tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
+"revision that does not have this commit needs this patch applied to
+work around other problem this bisection is not interested in")
+applied to the revision being tested.
+
+To cope with such a situation, after the inner git-bisect finds the
+next revision to test, with the "run" script, you can apply that tweak
+before compiling, run the real test, and after the test decides if the
+revision (possibly with the needed tweaks) passed the test, rewind the
+tree to the pristine state. Finally the "run" script can exit with
+the status of the real test to let "git bisect run" command loop to
+know the outcome.
+
+EXAMPLES
+--------
+
+* Automatically bisect a broken build between v1.2 and HEAD:
++
+------------
+$ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good
+$ git bisect run make # "make" builds the app
+------------
+
+* Automatically bisect a broken test suite:
++
+------------
+$ cat ~/test.sh
+#!/bin/sh
+make || exit 125 # this "skip"s broken builds
+make test # "make test" runs the test suite
+$ git bisect start v1.3 v1.1 -- # v1.3 is bad, v1.1 is good
+$ git bisect run ~/test.sh
+------------
++
+Here we use a "test.sh" custom script. In this script, if "make"
+fails, we "skip" the current commit.
++
+It's safer to use a custom script outside the repo to prevent
+interactions between the bisect, make and test processes and the
+script.
++
+And "make test" should "exit 0", if the test suite passes, and
+"exit 1" (for example) otherwise.
+
+* Automatically bisect a broken test case:
++
+------------
+$ cat ~/test.sh
+#!/bin/sh
+make || exit 125 # this "skip"s broken builds
+~/check_test_case.sh # does the test case passes ?
+$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10
+$ git bisect run ~/test.sh
+------------
++
+Here "check_test_case.sh" should "exit 0", if the test case passes,
+and "exit 1" (for example) otherwise.
++
+It's safer if both "test.sh" and "check_test_case.sh" scripts are
+outside the repo to prevent interactions between the bisect, make and
+test processes and the scripts.
+
+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 linkgit:git[1] suite
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
new file mode 100644
index 0000000000..8f4fb46685
--- /dev/null
+++ b/Documentation/git-blame.txt
@@ -0,0 +1,197 @@
+git-blame(1)
+============
+
+NAME
+----
+git-blame - Show what revision and author last modified each line of a file
+
+SYNOPSIS
+--------
+[verse]
+'git-blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
+ [-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
+ [<rev> | --contents <file>] [--] <file>
+
+DESCRIPTION
+-----------
+
+Annotates each line in the given file with information from the revision which
+last modified the line. Optionally, start annotating from the given revision.
+
+Also it can limit the range of lines annotated.
+
+This report doesn't tell you anything about lines which have been deleted or
+replaced; you need to use a tool such as linkgit:git-diff[1] or the "pickaxe"
+interface briefly mentioned in the following paragraph.
+
+Apart from supporting file annotation, git also supports searching the
+development history for when a code snippet occurred in a change. This makes it
+possible to track when a code snippet was added to a file, moved or copied
+between files, and eventually deleted or replaced. It works by searching for
+a text string in the diff. A small example:
+
+-----------------------------------------------------------------------------
+$ git log --pretty=oneline -S'blame_usage'
+5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
+ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output
+-----------------------------------------------------------------------------
+
+OPTIONS
+-------
+include::blame-options.txt[]
+
+-c::
+ Use the same output mode as linkgit:git-annotate[1] (Default: off).
+
+--score-debug::
+ Include debugging information related to the movement of
+ lines between files (see `-C`) and lines moved within a
+ file (see `-M`). The first number listed is the score.
+ This is the number of alphanumeric characters detected
+ to be moved between or within files. This must be above
+ a certain threshold for git-blame to consider those lines
+ of code to have been moved.
+
+-f::
+--show-name::
+ Show filename in the original commit. By default
+ filename is shown if there is any line that came from a
+ file with different name, due to rename detection.
+
+-n::
+--show-number::
+ Show line number in the original commit (Default: off).
+
+-s::
+ Suppress author name and timestamp from the output.
+
+-w::
+ Ignore whitespace when comparing parent's version and
+ child's to find where the lines came from.
+
+
+THE PORCELAIN FORMAT
+--------------------
+
+In this format, each line is output after a header; the
+header at the minimum has the first line which has:
+
+- 40-byte SHA-1 of the commit the line is attributed to;
+- the line number of the line in the original file;
+- the line number of the line in the final file;
+- on a line that starts a group of line from a different
+ commit than the previous one, the number of lines in this
+ group. On subsequent lines this field is absent.
+
+This header line is followed by the following information
+at least once for each commit:
+
+- author name ("author"), email ("author-mail"), time
+ ("author-time"), and timezone ("author-tz"); similarly
+ for committer.
+- filename in the commit the line is attributed to.
+- the first line of the commit log message ("summary").
+
+The contents of the actual line is output after the above
+header, prefixed by a TAB. This is to allow adding more
+header elements later.
+
+
+SPECIFYING RANGES
+-----------------
+
+Unlike `git-blame` and `git-annotate` in older git, the extent
+of annotation can be limited to both line ranges and revision
+ranges. When you are interested in finding the origin for
+ll. 40-60 for file `foo`, you can use `-L` option like these
+(they mean the same thing -- both ask for 21 lines starting at
+line 40):
+
+ git blame -L 40,60 foo
+ git blame -L 40,+21 foo
+
+Also you can use regular expression to specify the line range.
+
+ git blame -L '/^sub hello {/,/^}$/' foo
+
+would limit the annotation to the body of `hello` subroutine.
+
+When you are not interested in changes older than the version
+v2.6.18, or changes older than 3 weeks, you can use revision
+range specifiers similar to `git-rev-list`:
+
+ git blame v2.6.18.. -- foo
+ git blame --since=3.weeks -- foo
+
+When revision range specifiers are used to limit the annotation,
+lines that have not changed since the range boundary (either the
+commit v2.6.18 or the most recent commit that is more than 3
+weeks old in the above example) are blamed for that range
+boundary commit.
+
+A particularly useful way is to see if an added file have lines
+created by copy-and-paste from existing files. Sometimes this
+indicates that the developer was being sloppy and did not
+refactor the code properly. You can first find the commit that
+introduced the file with:
+
+ git log --diff-filter=A --pretty=short -- foo
+
+and then annotate the change between the commit and its
+parents, using `commit{caret}!` notation:
+
+ git blame -C -C -f $commit^! -- foo
+
+
+INCREMENTAL OUTPUT
+------------------
+
+When called with `--incremental` option, the command outputs the
+result as it is built. The output generally will talk about
+lines touched by more recent commits first (i.e. the lines will
+be annotated out of order) and is meant to be used by
+interactive viewers.
+
+The output format is similar to the Porcelain format, but it
+does not contain the actual lines from the file that is being
+annotated.
+
+. Each blame entry always starts with a line of:
+
+ <40-byte hex sha1> <sourceline> <resultline> <num_lines>
++
+Line numbers count from 1.
+
+. The first time that commit shows up in the stream, it has various
+ other information about it printed out with a one-word tag at the
+ beginning of each line about that "extended commit info" (author,
+ email, committer, dates, summary etc).
+
+. Unlike Porcelain format, the filename information is always
+ given and terminates the entry:
+
+ "filename" <whitespace-quoted-filename-goes-here>
++
+and thus it's really quite easy to parse for some line- and word-oriented
+parser (which should be quite natural for most scripting languages).
++
+[NOTE]
+For people who do parsing: to make it more robust, just ignore any
+lines in between the first and last one ("<sha1>" and "filename" lines)
+where you don't recognize the tag-words (or care about that particular
+one) at the beginning of the "extended information" lines. That way, if
+there is ever added information (like the commit encoding or extended
+commit commentary), a blame viewer won't ever care.
+
+
+SEE ALSO
+--------
+linkgit:git-annotate[1]
+
+AUTHOR
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
new file mode 100644
index 0000000000..0fd58083eb
--- /dev/null
+++ b/Documentation/git-branch.txt
@@ -0,0 +1,213 @@
+git-branch(1)
+=============
+
+NAME
+----
+git-branch - List, create, or delete branches
+
+SYNOPSIS
+--------
+[verse]
+'git-branch' [--color | --no-color] [-r | -a] [--merged | --no-merged]
+ [-v [--abbrev=<length> | --no-abbrev]]
+ [--contains <commit>]
+'git-branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
+'git-branch' (-m | -M) [<oldbranch>] <newbranch>
+'git-branch' (-d | -D) [-r] <branchname>...
+
+DESCRIPTION
+-----------
+With no arguments given a list of existing branches
+will be shown, the current branch will be highlighted with an asterisk.
+Option `-r` causes the remote-tracking branches to be listed,
+and option `-a` shows both.
+With `--contains <commit>`, shows only the branches that
+contains the named commit (in other words, the branches whose
+tip commits are descendant of the named commit).
+With `--merged`, only branches merged into HEAD will be listed, and
+with `--no-merged` only branches not merged into HEAD will be listed.
+
+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.
+
+Note that this will create the new branch, but it will not switch the
+working tree to it; use "git checkout <newbranch>" to switch to the
+new branch.
+
+When a local branch is started off a remote branch, git sets up the
+branch so that linkgit:git-pull[1] will appropriately merge from
+the remote branch. This behavior may be changed via the global
+`branch.autosetupmerge` configuration flag. That setting can be
+overridden by using the `--track` and `--no-track` options.
+
+With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>.
+If <oldbranch> had a corresponding reflog, it is renamed to match
+<newbranch>, and a reflog entry is created to remember the branch
+renaming. If <newbranch> exists, -M must be used to force the rename
+to happen.
+
+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 reflog then the reflog will also be deleted.
+
+Use -r together with -d to delete remote-tracking branches. Note, that it
+only makes sense to delete remote-tracking branches if they no longer exist
+in remote repository or if linkgit:git-fetch[1] was configured not to fetch
+them again. See also 'prune' subcommand of linkgit:git-remote[1] for way to
+clean up all obsolete remote-tracking branches.
+
+
+OPTIONS
+-------
+-d::
+ Delete a branch. The branch must be fully merged in HEAD.
+
+-D::
+ Delete a branch irrespective of its merged status.
+
+-l::
+ Create the branch's reflog. This activates recording of
+ all changes made to 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.
+
+-m::
+ Move/rename a branch and the corresponding reflog.
+
+-M::
+ Move/rename a branch even if the new branchname already exists.
+
+--color::
+ Color branches to highlight current, local, and remote branches.
+
+--no-color::
+ Turn off branch colors, even when the configuration file gives the
+ default to color output.
+
+-r::
+ List or delete (if used with -d) the remote-tracking branches.
+
+-a::
+ List both remote-tracking branches and local branches.
+
+-v::
+--verbose::
+ Show sha1 and commit subject line for each head.
+
+--abbrev=<length>::
+ Alter minimum display length for sha1 in output listing,
+ default value is 7.
+
+--no-abbrev::
+ Display the full sha1s in output listing rather than abbreviating them.
+
+--track::
+ When creating a new branch, set up configuration so that git-pull
+ will automatically retrieve data from the start point, which must be
+ a branch. Use this if you always pull from the same upstream branch
+ into the new branch, and if you don't want to use "git pull
+ <repository> <refspec>" explicitly. This behavior is the default
+ when the start point is a remote branch. Set the
+ branch.autosetupmerge configuration variable to `false` if you want
+ git-checkout and git-branch to always behave as if '--no-track' were
+ given. Set it to `always` if you want this behavior when the
+ start-point is either a local or remote branch.
+
+--no-track::
+ Ignore the branch.autosetupmerge configuration variable.
+
+--contains <commit>::
+ Only list branches which contain the specified commit.
+
+--merged::
+ Only list branches which are fully contained by HEAD.
+
+--no-merged::
+ Do not list branches which are fully contained by HEAD.
+
+<branchname>::
+ The name of the branch to create or delete.
+ The new branch name must pass all checks defined by
+ linkgit: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.
+
+<oldbranch>::
+ The name of an existing branch to rename.
+
+<newbranch>::
+ The new name for an existing branch. The same restrictions as for
+ <branchname> applies.
+
+
+Examples
+--------
+
+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 checkout my2.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 -r origin/todo origin/html origin/man <1>
+$ git branch -D test <2>
+------------
++
+<1> Delete remote-tracking branches "todo", "html", "man". Next 'fetch' or
+'pull' will create them again unless you configure them not to. See
+linkgit:git-fetch[1].
+<2> Delete "test" branch even if the "master" branch (or whichever branch is
+currently checked out) does not have all commits from test 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.
+
+The options `--contains`, `--merged` and `--no-merged` serves three related
+but different purposes:
+
+- `--contains <commit>` is used to find all branches which will need
+ special attention if <commit> were to be rebased or amended, since those
+ branches contain the specified <commit>.
+
+- `--merged` is used to find all branches which can be safely deleted,
+ since those branches are fully contained by HEAD.
+
+- `--no-merged` is used to find branches which are candidates for merging
+ into HEAD, since those branches are not fully contained by HEAD.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
new file mode 100644
index 0000000000..f6a06129ab
--- /dev/null
+++ b/Documentation/git-bundle.txt
@@ -0,0 +1,174 @@
+git-bundle(1)
+=============
+
+NAME
+----
+git-bundle - Move objects and refs by archive
+
+
+SYNOPSIS
+--------
+[verse]
+'git-bundle' create <file> <git-rev-list args>
+'git-bundle' verify <file>
+'git-bundle' list-heads <file> [refname...]
+'git-bundle' unbundle <file> [refname...]
+
+DESCRIPTION
+-----------
+
+Some workflows require that one or more branches of development on one
+machine be replicated on another machine, but the two machines cannot
+be directly connected so the interactive git protocols (git, ssh,
+rsync, http) cannot be used. This command provides support for
+git-fetch and git-pull to operate by packaging objects and references
+in an archive at the originating machine, then importing those into
+another repository using linkgit:git-fetch[1] and linkgit:git-pull[1]
+after moving the archive by some means (i.e., by sneakernet). As no
+direct connection between repositories exists, the user must specify a
+basis for the bundle that is held by the destination repository: the
+bundle assumes that all objects in the basis are already in the
+destination repository.
+
+OPTIONS
+-------
+
+create <file>::
+ Used to create a bundle named 'file'. This requires the
+ git-rev-list arguments to define the bundle contents.
+
+verify <file>::
+ Used to check that a bundle file is valid and will apply
+ cleanly to the current repository. This includes checks on the
+ bundle format itself as well as checking that the prerequisite
+ commits exist and are fully linked in the current repository.
+ git-bundle prints a list of missing commits, if any, and exits
+ with non-zero status.
+
+list-heads <file>::
+ Lists the references defined in the bundle. If followed by a
+ list of references, only references matching those given are
+ printed out.
+
+unbundle <file>::
+ Passes the objects in the bundle to linkgit:git-index-pack[1]
+ for storage in the repository, then prints the names of all
+ defined references. If a reflist is given, only references
+ matching those in the given list are printed. This command is
+ really plumbing, intended to be called only by
+ linkgit:git-fetch[1].
+
+[git-rev-list-args...]::
+ A list of arguments, acceptable to git-rev-parse and
+ git-rev-list, that specify the specific objects and references
+ to transport. For example, "master~10..master" causes the
+ current master reference to be packaged along with all objects
+ added since its 10th ancestor commit. There is no explicit
+ limit to the number of references and objects that may be
+ packaged.
+
+
+[refname...]::
+ A list of references used to limit the references reported as
+ available. This is principally of use to git-fetch, which
+ expects to receive only those references asked for and not
+ necessarily everything in the pack (in this case, git-bundle is
+ acting like linkgit:git-fetch-pack[1]).
+
+SPECIFYING REFERENCES
+---------------------
+
+git-bundle will only package references that are shown by
+git-show-ref: this includes heads, tags, and remote heads. References
+such as master~1 cannot be packaged, but are perfectly suitable for
+defining the basis. More than one reference may be packaged, and more
+than one basis can be specified. The objects packaged are those not
+contained in the union of the given bases. Each basis can be
+specified explicitly (e.g., ^master~10), or implicitly (e.g.,
+master~10..master, master --since=10.days.ago).
+
+It is very important that the basis used be held by the destination.
+It is okay to err on the side of conservatism, causing the bundle file
+to contain objects already in the destination as these are ignored
+when unpacking at the destination.
+
+EXAMPLE
+-------
+
+Assume two repositories exist as R1 on machine A, and R2 on machine B.
+For whatever reason, direct connection between A and B is not allowed,
+but we can move data from A to B via some mechanism (CD, email, etc).
+We want to update R2 with developments made on branch master in R1.
+
+To create the bundle you have to specify the basis. You have some options:
+
+- Without basis.
++
+This is useful when sending the whole history.
+
+------------
+$ git bundle create mybundle master
+------------
+
+- Using temporally tags.
++
+We set a tag in R1 (lastR2bundle) after the previous such transport,
+and move it afterwards to help build the bundle.
+
+------------
+$ git-bundle create mybundle master ^lastR2bundle
+$ git tag -f lastR2bundle master
+------------
+
+- Using a tag present in both repositories
+
+------------
+$ git bundle create mybundle master ^v1.0.0
+------------
+
+- A basis based on time.
+
+------------
+$ git bundle create mybundle master --since=10.days.ago
+------------
+
+- With a limit on the number of commits
+
+------------
+$ git bundle create mybundle master -n 10
+------------
+
+Then you move mybundle from A to B, and in R2 on B:
+
+------------
+$ git-bundle verify mybundle
+$ git-fetch mybundle master:localRef
+------------
+
+With something like this in the config in R2:
+
+------------------------
+[remote "bundle"]
+ url = /home/me/tmp/file.bdl
+ fetch = refs/heads/*:refs/remotes/origin/*
+------------------------
+
+You can first sneakernet the bundle file to ~/tmp/file.bdl and
+then these commands on machine B:
+
+------------
+$ git ls-remote bundle
+$ git fetch bundle
+$ git pull bundle
+------------
+
+would treat it as if it is talking with a remote side over the
+network.
+
+Author
+------
+Written by Mark Levedahl <mdl123@verizon.net>
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
new file mode 100644
index 0000000000..f58013ca60
--- /dev/null
+++ b/Documentation/git-cat-file.txt
@@ -0,0 +1,107 @@
+git-cat-file(1)
+===============
+
+NAME
+----
+git-cat-file - Provide content or type/size information for repository objects
+
+
+SYNOPSIS
+--------
+[verse]
+'git-cat-file' [-t | -s | -e | -p | <type>] <object>
+'git-cat-file' [--batch | --batch-check] < <list-of-objects>
+
+DESCRIPTION
+-----------
+In the first form, provides content or type of objects in the repository. The
+type is required unless '-t' or '-p' is used to find the object type, or '-s'
+is used to find the object size.
+
+In the second form, a list of object (separated by LFs) is provided on stdin,
+and the SHA1, type, and size of each object is printed on stdout.
+
+OPTIONS
+-------
+<object>::
+ The name of the object to show.
+ For a more complete list of ways to spell object names, see
+ "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
+
+-t::
+ Instead of the content, show the object type identified by
+ <object>.
+
+-s::
+ Instead of the content, show the object size identified by
+ <object>.
+
+-e::
+ 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
+ <object> is also permitted. An example is to ask for a
+ "tree" with <object> being a commit object that contains it,
+ or to ask for a "blob" with <object> being a tag object that
+ points at it.
+
+--batch::
+ Print the SHA1, type, size, and contents of each object provided on
+ stdin. May not be combined with any other options or arguments.
+
+--batch-check::
+ Print the SHA1, type, and size of each object provided on stdin. May not be
+ combined with any other options or arguments.
+
+OUTPUT
+------
+If '-t' is specified, one of the <type>.
+
+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.
+
+If <type> is specified, the raw (though uncompressed) contents of the <object>
+will be returned.
+
+If '--batch' is specified, output of the following form is printed for each
+object specified on stdin:
+
+------------
+<sha1> SP <type> SP <size> LF
+<contents> LF
+------------
+
+If '--batch-check' is specified, output of the following form is printed for
+each object specified fon stdin:
+
+------------
+<sha1> SP <type> SP <size> LF
+------------
+
+For both '--batch' and '--batch-check', output of the following form is printed
+for each object specified on stdin that does not exist in the repository:
+
+------------
+<object> SP missing LF
+------------
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt
new file mode 100644
index 0000000000..ef16b93982
--- /dev/null
+++ b/Documentation/git-check-attr.txt
@@ -0,0 +1,41 @@
+git-check-attr(1)
+=================
+
+NAME
+----
+git-check-attr - Display gitattributes information.
+
+
+SYNOPSIS
+--------
+'git-check-attr' attr... [--] pathname...
+
+DESCRIPTION
+-----------
+For every pathname, this command will list if each attr is 'unspecified',
+'set', or 'unset' as a gitattribute on that pathname.
+
+OPTIONS
+-------
+\--::
+ Interpret all preceding arguments as attributes, and all following
+ arguments as path names. If not supplied, only the first argument will
+ be treated as an attribute.
+
+
+SEE ALSO
+--------
+linkgit:gitattributes[5].
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by James Bowes.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
new file mode 100644
index 0000000000..c560c0aa6d
--- /dev/null
+++ b/Documentation/git-check-ref-format.txt
@@ -0,0 +1,55 @@
+git-check-ref-format(1)
+=======================
+
+NAME
+----
+git-check-ref-format - Make sure ref name is well formed
+
+SYNOPSIS
+--------
+'git-check-ref-format' <refname>
+
+DESCRIPTION
+-----------
+Checks if a given 'refname' is acceptable, and exits non-zero if
+it is not.
+
+A reference is used in git to specify branches and tags. A
+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 can include slash `/` for hierarchical (directory)
+ grouping, but no slash-separated component can begin with a
+ dot `.`;
+
+. It cannot have two consecutive dots `..` anywhere;
+
+. It cannot have ASCII control character (i.e. bytes whose
+ values are lower than \040, or \177 `DEL`), space, tilde `~`,
+ caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`,
+ or open bracket `[` anywhere;
+
+. It cannot end with a slash `/`.
+
+These rules makes it easy for shell script based tools to parse
+refnames, pathname expansion by the shell when a refname is used
+unquoted (by mistake), and also avoids ambiguities in certain
+refname expressions (see linkgit:git-rev-parse[1]). Namely:
+
+. double-dot `..` are often used as in `ref1..ref2`, and in some
+ context this notation means `{caret}ref1 ref2` (i.e. not in
+ ref1 and in ref2).
+
+. tilde `~` and caret `{caret}` are used to introduce postfix
+ 'nth parent' and 'peel onion' operation.
+
+. 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
+ linkgit:git-cat-file[1] "git-cat-file blob v1.3.3:refs.c".
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-checkout-index.txt b/Documentation/git-checkout-index.txt
new file mode 100644
index 0000000000..676203b2eb
--- /dev/null
+++ b/Documentation/git-checkout-index.txt
@@ -0,0 +1,189 @@
+git-checkout-index(1)
+=====================
+
+NAME
+----
+git-checkout-index - Copy files from the index to the working tree
+
+
+SYNOPSIS
+--------
+[verse]
+'git-checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
+ [--stage=<number>|all]
+ [--temp]
+ [-z] [--stdin]
+ [--] [<file>]\*
+
+DESCRIPTION
+-----------
+Will copy all files listed from the index to the working directory
+(not overwriting existing files).
+
+OPTIONS
+-------
+-u::
+--index::
+ update stat information for the checked out entries in
+ the index file.
+
+-q::
+--quiet::
+ be quiet if files exist or are not in the index
+
+-f::
+--force::
+ forces overwrite of existing files
+
+-a::
+--all::
+ checks out all files in the index. Cannot be used
+ together with explicit filenames.
+
+-n::
+--no-create::
+ Don't checkout new files, only refresh files already checked
+ out.
+
+--prefix=<string>::
+ When creating files, prepend <string> (usually a directory
+ including a trailing /)
+
+--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.
+
+Just doing `git-checkout-index` does nothing. You probably meant
+`git-checkout-index -a`. And if you want to force it, you want
+`git-checkout-index -f -a`.
+
+Intuitiveness is not the goal here. Repeatability is. The reason for
+the "no arguments means no work" behavior is that from scripts you are
+supposed to be able to do:
+
+----------------
+$ 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. 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::
++
+----------------
+$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
+----------------
+
+Using `git-checkout-index` to "export an entire tree"::
+ The prefix ability basically makes it trivial to use
+ `git-checkout-index` as an "export as tree" function.
+ Just read the desired tree into the index, and do:
++
+----------------
+$ git-checkout-index --prefix=git-export-dir/ -a
+----------------
++
+`git-checkout-index` will "export" the index into the specified
+directory.
++
+The final "/" is important. The exported name is literally just
+prefixed with the specified string. Contrast this with the
+following example.
+
+Export files with a prefix::
++
+----------------
+$ git-checkout-index --prefix=.merged- Makefile
+----------------
++
+This will check out the currently cached copy of `Makefile`
+into the file `.merged-Makefile`.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+
+Documentation
+--------------
+Documentation by David Greaves,
+Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
new file mode 100644
index 0000000000..3ad9760a4d
--- /dev/null
+++ b/Documentation/git-checkout.txt
@@ -0,0 +1,219 @@
+git-checkout(1)
+===============
+
+NAME
+----
+git-checkout - Checkout a branch or paths to the working tree
+
+SYNOPSIS
+--------
+[verse]
+'git-checkout' [-q] [-f] [[--track | --no-track] -b <new_branch> [-l]] [-m] [<branch>]
+'git-checkout' [<tree-ish>] <paths>...
+
+DESCRIPTION
+-----------
+
+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>. Using -b will cause <new_branch> to
+be created; in this case you can use the --track or --no-track
+options, which will be passed to `git branch`.
+
+When <paths> are given, this command does *not* switch
+branches. It updates the named paths in the working tree from
+the index file (i.e. it runs `git-checkout-index -f -u`), or
+from a named commit. In
+this case, the `-f` and `-b` options are meaningless and giving
+either of them results in an error. <tree-ish> argument can be
+used to specify a specific tree-ish (i.e. commit, tag or tree)
+to update the index for the given paths before updating the
+working tree.
+
+
+OPTIONS
+-------
+-q::
+ Quiet, suppress feedback messages.
+
+-f::
+ Proceed even if the index or the working tree differs
+ from HEAD. This is used to throw away local changes.
+
+-b::
+ Create a new branch named <new_branch> and start it at
+ <branch>. The new branch name must pass all checks defined
+ by linkgit:git-check-ref-format[1]. Some of these checks
+ may restrict the characters allowed in a branch name.
+
+-t::
+--track::
+ When creating a new branch, set up configuration so that git-pull
+ will automatically retrieve data from the start point, which must be
+ a branch. Use this if you always pull from the same upstream branch
+ into the new branch, and if you don't want to use "git pull
+ <repository> <refspec>" explicitly. This behavior is the default
+ when the start point is a remote branch. Set the
+ branch.autosetupmerge configuration variable to `false` if you want
+ git-checkout and git-branch to always behave as if '--no-track' were
+ given. Set it to `always` if you want this behavior when the
+ start-point is either a local or remote branch.
+
+--no-track::
+ Ignore the branch.autosetupmerge configuration variable.
+
+-l::
+ Create the new branch's reflog. This activates recording of
+ all changes made to 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 add` (or `git rm` if the merge
+should result in deletion of the path).
+
+<new_branch>::
+ Name for the new branch.
+
+<branch>::
+ Branch to checkout; may be any object ID that resolves to a
+ commit. Defaults to HEAD.
++
+When this parameter names a non-branch (but still a valid commit object),
+your HEAD becomes 'detached'.
+
+
+Detached HEAD
+-------------
+
+It is sometimes useful to be able to 'checkout' a commit that is
+not at the tip of one of your branches. The most obvious
+example is to check out the commit at a tagged official release
+point, like this:
+
+------------
+$ git checkout v2.6.18
+------------
+
+Earlier versions of git did not allow this and asked you to
+create a temporary branch using `-b` option, but starting from
+version 1.5.0, the above command 'detaches' your HEAD from the
+current branch and directly point at the commit named by the tag
+(`v2.6.18` in the above example).
+
+You can use usual git commands while in this state. You can use
+`git-reset --hard $othercommit` to further move around, for
+example. You can make changes and create a new commit on top of
+a detached HEAD. You can even create a merge by using `git
+merge $othercommit`.
+
+The state you are in while your HEAD is detached is not recorded
+by any branch (which is natural --- you are not on any branch).
+What this means is that you can discard your temporary commits
+and merges by switching back to an existing branch (e.g. `git
+checkout master`), and a later `git prune` or `git gc` would
+garbage-collect them. If you did this by mistake, you can ask
+the reflog for HEAD where you were, e.g.
+
+------------
+$ git log -g -2 HEAD
+------------
+
+
+EXAMPLES
+--------
+
+. 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~2 Makefile <2>
+$ rm -f hello.c
+$ git checkout hello.c <3>
+------------
++
+<1> switch branch
+<2> take out a file out of other commit
+<3> restore hello.c from HEAD of current branch
++
+If you have an unfortunate branch that is named `hello.c`, this
+step would be confused as an instruction to switch to 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 add` as usual:
++
+------------
+$ edit frotz
+$ git add frotz
+------------
+
+
+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 linkgit:git[1] suite
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
new file mode 100644
index 0000000000..5ac9cfb0ef
--- /dev/null
+++ b/Documentation/git-cherry-pick.txt
@@ -0,0 +1,85 @@
+git-cherry-pick(1)
+==================
+
+NAME
+----
+git-cherry-pick - Apply the change introduced by an existing commit
+
+SYNOPSIS
+--------
+'git-cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] <commit>
+
+DESCRIPTION
+-----------
+Given one existing commit, apply the change the patch introduces, and record a
+new commit that records it. This requires your working tree to be clean (no
+modifications from the HEAD commit).
+
+OPTIONS
+-------
+<commit>::
+ Commit to cherry-pick.
+ For a more complete list of ways to spell commits, see
+ "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
+
+-e::
+--edit::
+ With this option, `git-cherry-pick` will let you edit the commit
+ message prior to committing.
+
+-x::
+ When recording the commit, append to the original commit
+ message a note that indicates which commit this change
+ was cherry-picked from. Append the note only for cherry
+ picks without conflicts. Do not use this option if
+ you are cherry-picking from your private branch because
+ the information is useless to the recipient. If on the
+ other hand you are cherry-picking between two publicly
+ visible branches (e.g. backporting a fix to a
+ maintenance branch for an older release from a
+ development branch), adding this information can be
+ useful.
+
+-r::
+ It used to be that the command defaulted to do `-x`
+ described above, and `-r` was to disable it. Now the
+ default is not to do `-x` so this option is a no-op.
+
+-m parent-number::
+--mainline parent-number::
+ Usually you cannot cherry-pick a merge because you do not know which
+ side of the merge should be considered the mainline. This
+ option specifies the parent number (starting from 1) of
+ the mainline and allows cherry-pick to replay the change
+ relative to the specified parent.
+
+-n::
+--no-commit::
+ Usually the command automatically creates a commit with
+ a commit log message stating which commit was
+ cherry-picked. This flag applies the change necessary
+ to cherry-pick the named commit to your working tree,
+ but does not make the commit. In addition, when this
+ option is used, your working tree does not have to match
+ the HEAD commit. The cherry-pick is done against the
+ beginning state of your working tree.
++
+This is useful when cherry-picking more than one commits'
+effect to your working tree in a row.
+
+-s::
+--signoff::
+ Add Signed-off-by line at the end of the commit message.
+
+
+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 linkgit:git[1] suite
diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt
new file mode 100644
index 0000000000..ef7caf61e1
--- /dev/null
+++ b/Documentation/git-cherry.txt
@@ -0,0 +1,75 @@
+git-cherry(1)
+=============
+
+NAME
+----
+git-cherry - Find commits not merged upstream
+
+SYNOPSIS
+--------
+'git-cherry' [-v] <upstream> [<head>] [<limit>]
+
+DESCRIPTION
+-----------
+The changeset (or "diff") of each commit between the fork-point and <head>
+is compared against each commit between the fork-point and <upstream>.
+The commits are compared with their 'patch id', obtained from linkgit:git-patch-id[1]
+program.
+
+Every commit that doesn't exist in the <upstream> branch
+has its id (sha1) reported, prefixed by a symbol. The ones that have
+equivalent change already
+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:
+
+ __*__*__*__*__> <upstream>
+ /
+ fork-point
+ \__+__+__-__+__+__-__+__> <head>
+
+
+If a <limit> has been given then the commits along the <head> branch up
+to and including <limit> are not reported:
+
+ __*__*__*__*__> <upstream>
+ /
+ fork-point
+ \__*__*__<limit>__-__+__> <head>
+
+
+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
+-------
+-v::
+ Verbose.
+
+<upstream>::
+ Upstream branch to compare against.
+
+<head>::
+ Working branch; defaults to HEAD.
+
+<limit>::
+ Do not report commits up to (and including) limit.
+
+SEE ALSO
+--------
+linkgit:git-patch-id[1]
+
+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 linkgit:git[1] suite
diff --git a/Documentation/git-citool.txt b/Documentation/git-citool.txt
new file mode 100644
index 0000000000..09108d0e66
--- /dev/null
+++ b/Documentation/git-citool.txt
@@ -0,0 +1,32 @@
+git-citool(1)
+=============
+
+NAME
+----
+git-citool - Graphical alternative to git-commit
+
+SYNOPSIS
+--------
+'git citool'
+
+DESCRIPTION
+-----------
+A Tcl/Tk based graphical interface to review modified files, stage
+them into the index, enter a commit message and record the new
+commit onto the current branch. This interface is an alternative
+to the less interactive linkgit:git-commit[1] program.
+
+git-citool is actually a standard alias for 'git gui citool'.
+See linkgit:git-gui[1] for more details.
+
+Author
+------
+Written by Shawn O. Pearce <spearce@spearce.org>.
+
+Documentation
+--------------
+Documentation by Shawn O. Pearce <spearce@spearce.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
new file mode 100644
index 0000000000..37a82ee4b8
--- /dev/null
+++ b/Documentation/git-clean.txt
@@ -0,0 +1,59 @@
+git-clean(1)
+============
+
+NAME
+----
+git-clean - Remove untracked files from the working tree
+
+SYNOPSIS
+--------
+[verse]
+'git-clean' [-d] [-f] [-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.
+
+-f::
+ If the git configuration specifies clean.requireForce as true,
+ git-clean will refuse to run unless given -f or -n.
+
+-n::
+--dry-run::
+ Don't actually remove anything, just show what would be done.
+
+-q::
+--quiet::
+ 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 linkgit: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 linkgit:git[1] suite
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
new file mode 100644
index 0000000000..7973e6af4c
--- /dev/null
+++ b/Documentation/git-clone.txt
@@ -0,0 +1,208 @@
+git-clone(1)
+============
+
+NAME
+----
+git-clone - Clone a repository into a new directory
+
+
+SYNOPSIS
+--------
+[verse]
+'git-clone' [--template=<template_directory>]
+ [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare]
+ [-o <name>] [-u <upload-pack>] [--reference <repository>]
+ [--depth <depth>] [--] <repository> [<directory>]
+
+DESCRIPTION
+-----------
+
+Clones a repository into a newly created directory, creates
+remote-tracking branches for each branch in the cloned repository
+(visible using `git branch -r`), and creates and checks out an initial
+branch equal to the cloned repository's currently active branch.
+
+After the clone, a plain `git fetch` without arguments will update
+all the remote-tracking branches, and a `git pull` without
+arguments will in addition merge the remote master branch into the
+current master branch, if any.
+
+This default configuration is achieved by creating references to
+the remote branch heads under `$GIT_DIR/refs/remotes/origin` and
+by initializing `remote.origin.url` and `remote.origin.fetch`
+configuration variables.
+
+
+OPTIONS
+-------
+--local::
+-l::
+ When the repository to clone from is on a local machine,
+ this flag bypasses normal "git aware" transport
+ mechanism and clones the repository by making a copy of
+ HEAD and everything under objects and refs directories.
+ The files under `.git/objects/` directory are hardlinked
+ to save space when possible. This is now the default when
+ the source repository is specified with `/path/to/repo`
+ syntax, so it essentially is a no-op option. To force
+ copying instead of hardlinking (which may be desirable
+ if you are trying to make a back-up of your repository),
+ but still avoid the usual "git aware" transport
+ mechanism, `--no-hardlinks` can be used.
+
+--no-hardlinks::
+ Optimize the cloning process from a repository on a
+ local filesystem by copying files under `.git/objects`
+ directory.
+
+--shared::
+-s::
+ When the repository to clone is on the local machine,
+ instead of using hard links, automatically setup
+ .git/objects/info/alternates to share the objects
+ with the source repository. The resulting repository
+ starts out without any object of its own.
++
+*NOTE*: this is a possibly dangerous operation; do *not* use
+it unless you understand what it does. If you clone your
+repository using this option and then delete branches (or use any
+other git command that makes any existing commit unreferenced) in the
+source repository, some objects may become unreferenced (or dangling).
+These objects may be removed by normal git operations (such as git-commit[1])
+which automatically call git-gc[1]. If these objects are removed and
+were referenced by the cloned repository, then the cloned repository
+will become corrupt.
+
+
+
+--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 fewer objects to be copied from the repository
+ being cloned, reducing network and local storage costs.
++
+*NOTE*: see NOTE to --shared option.
+
+--quiet::
+-q::
+ Operate quietly. This flag is passed to "rsync" and
+ "git-fetch-pack" commands when given.
+
+--no-checkout::
+-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 obviously implies the `-n`
+ because there is nowhere to check out the working tree.
+ Also the branch heads at the remote are copied directly
+ to corresponding local branch heads, without mapping
+ them to `refs/remotes/origin/`. When this option is
+ used, neither remote-tracking branches nor the related
+ configuration variables are created.
+
+--origin <name>::
+-o <name>::
+ Instead of using the remote name 'origin' to keep track
+ of the upstream repository, use <name> instead.
+
+--upload-pack <upload-pack>::
+-u <upload-pack>::
+ When given, and the repository to clone 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.
+
+--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`.
+
+--depth <depth>::
+ Create a 'shallow' clone with a history truncated to the
+ specified number of revisions. A shallow repository has a
+ number of limitations (you cannot clone or fetch from
+ it, nor push from nor into it), but is adequate if you
+ are only interested in the recent history of a large project
+ with a long history, and would want to send in fixes
+ as patches.
+
+<repository>::
+ The (possibly remote) repository to clone from. See the
+ <<URLS,URLS>> section below for more information on specifying
+ repositories.
+
+<directory>::
+ 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.
+
+:git-clone: 1
+include::urls.txt[]
+
+Examples
+--------
+
+Clone from upstream::
++
+------------
+$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
+$ cd my2.6
+$ make
+------------
+
+
+Make a local clone that borrows from the current directory, without checking things out::
++
+------------
+$ git clone -l -s -n . ../copy
+$ 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
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
new file mode 100644
index 0000000000..728c2fae89
--- /dev/null
+++ b/Documentation/git-commit-tree.txt
@@ -0,0 +1,106 @@
+git-commit-tree(1)
+==================
+
+NAME
+----
+git-commit-tree - Create a new commit object
+
+
+SYNOPSIS
+--------
+'git-commit-tree' <tree> [-p <parent commit>]\* < changelog
+
+DESCRIPTION
+-----------
+This is usually not what an end user wants to run directly. See
+linkgit:git-commit[1] instead.
+
+Creates a new commit object based on the provided tree object and
+emits the new commit object id on stdout. If no parent is given then
+it is considered to be an initial tree.
+
+A commit object usually has 1 parent (a commit after a change) or up
+to 16 parents. More than one parent represents a merge of branches
+that led to them.
+
+While a tree represents a particular directory state of a working
+directory, a commit represents that state in "time", and explains how
+to get there.
+
+Normally a commit would identify a new "HEAD" state, and while git
+doesn't care where you save the note about that state, in practice we
+tend to just write the result to the file that is pointed at by
+`.git/HEAD`, so that we can always see what the last committed
+state was.
+
+OPTIONS
+-------
+<tree>::
+ An existing tree object
+
+-p <parent commit>::
+ Each '-p' indicates the id of a parent commit object.
+
+
+Commit Information
+------------------
+
+A commit encapsulates:
+
+- all parent object ids
+- author name, email and date
+- committer name and email and the commit time.
+
+While parent object ids are provided on the command line, author and
+committer information is taken from the following environment variables,
+if set:
+
+ GIT_AUTHOR_NAME
+ GIT_AUTHOR_EMAIL
+ GIT_AUTHOR_DATE
+ GIT_COMMITTER_NAME
+ GIT_COMMITTER_EMAIL
+ GIT_COMMITTER_DATE
+ EMAIL
+
+(nb "<", ">" and "\n"s are stripped)
+
+In case (some of) these environment variables are not set, the information
+is taken from the configuration items user.name and user.email, or, if not
+present, system user name and fully qualified hostname.
+
+A commit comment is read from stdin. If a changelog
+entry is not provided via "<" redirection, "git-commit-tree" will just wait
+for one to be entered and terminated with ^D.
+
+
+Diagnostics
+-----------
+You don't exist. Go away!::
+ The passwd(5) gecos field couldn't be read
+Your parents must have hated you!::
+ The password(5) gecos field is longer than a giant static buffer.
+Your sysadmin must hate you!::
+ The password(5) name field is longer than a giant static buffer.
+
+Discussion
+----------
+
+include::i18n.txt[]
+
+SEE ALSO
+--------
+linkgit:git-write-tree[1]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
new file mode 100644
index 0000000000..7e8b4ff72c
--- /dev/null
+++ b/Documentation/git-commit.txt
@@ -0,0 +1,330 @@
+git-commit(1)
+=============
+
+NAME
+----
+git-commit - Record changes to the repository
+
+SYNOPSIS
+--------
+[verse]
+'git-commit' [-a | --interactive] [-s] [-v] [-u] [--amend]
+ [(-c | -C) <commit>] [-F <file> | -m <msg>]
+ [--allow-empty] [--no-verify] [-e] [--author=<author>]
+ [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
+
+DESCRIPTION
+-----------
+Use 'git commit' to store the current contents of the index in a new
+commit along with a log message describing the changes you have made.
+
+The content to be added can be specified in several ways:
+
+1. by using linkgit:git-add[1] to incrementally "add" changes to the
+ index before using the 'commit' command (Note: even modified
+ files must be "added");
+
+2. by using linkgit:git-rm[1] to remove files from the working tree
+ and the index, again before using the 'commit' command;
+
+3. by listing files as arguments to the 'commit' command, in which
+ case the commit will ignore changes staged in the index, and instead
+ record the current content of the listed files;
+
+4. by using the -a switch with the 'commit' command to automatically
+ "add" changes from all known files (i.e. all files that are already
+ listed in the index) and to automatically "rm" files in the index
+ that have been removed from the working tree, and then perform the
+ actual commit;
+
+5. by using the --interactive switch with the 'commit' command to decide one
+ by one which files should be part of the commit, before finalizing the
+ operation. Currently, this is done by invoking `git-add --interactive`.
+
+The linkgit:git-status[1] command can be used to obtain a
+summary of what is included by any of the above for the next
+commit by giving the same set of parameters you would give to
+this command.
+
+If you make a commit and then found a mistake immediately after
+that, you can recover from it with linkgit:git-reset[1].
+
+
+OPTIONS
+-------
+-a::
+--all::
+ Tell the command to automatically stage files that have
+ been modified and deleted, but new files you have not
+ told git about are not affected.
+
+-C <commit>::
+--reuse-message=<commit>::
+ Take an existing commit object, and reuse the log message
+ and the authorship information (including the timestamp)
+ when creating the commit.
+
+-c <commit>::
+--reedit-message=<commit>::
+ Like '-C', but with '-c' the editor is invoked, so that
+ the user can further edit the commit message.
+
+-F <file>::
+--file=<file>::
+ 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>::
+--message=<msg>::
+ Use the given <msg> as the commit message.
+
+-t <file>::
+--template=<file>::
+ Use the contents of the given file as the initial version
+ of the commit message. The editor is invoked and you can
+ make subsequent changes. If a message is specified using
+ the `-m` or `-F` options, this option has no effect. This
+ overrides the `commit.template` configuration variable.
+
+-s::
+--signoff::
+ Add Signed-off-by line at the end of the commit message.
+
+-n::
+--no-verify::
+ This option bypasses the pre-commit and commit-msg hooks.
+ See also linkgit:githooks[5][hooks].
+
+--allow-empty::
+ Usually recording a commit that has the exact same tree as its
+ sole parent commit is a mistake, and the command prevents you
+ from making such a commit. This option bypasses the safety, and
+ is primarily for use by foreign scm interface scripts.
+
+--cleanup=<mode>::
+ This option sets how the commit message is cleaned up.
+ The '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
+ and 'default'. The 'default' mode will strip leading and
+ trailing empty lines and #commentary from the commit message
+ only if the message is to be edited. Otherwise only whitespace
+ removed. The 'verbatim' mode does not change message at all,
+ 'whitespace' removes just leading/trailing whitespace lines
+ and 'strip' removes both whitespace and commentary.
+
+-e::
+--edit::
+ The message taken from file with `-F`, command line with
+ `-m`, and from file with `-C` are usually used as the
+ 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::
+ Before making a commit out of staged contents so far,
+ stage the contents of paths given on the command line
+ as well. This is usually not what you want unless you
+ are concluding a conflicted merge.
+
+-o::
+--only::
+ Make a commit only from the paths specified on the
+ command line, disregarding any contents that have been
+ staged so far. This is the default mode of operation of
+ 'git commit' if any paths are given on the command line,
+ in which case this option can be omitted.
+ If this option is specified together with '--amend', then
+ no paths need be specified, which can be used to amend
+ the last commit without committing changes that have
+ already been staged.
+
+-u::
+--untracked-files::
+ Show all untracked files, also those in uninteresting
+ directories, in the "Untracked files:" section of commit
+ message template. Without this option only its name and
+ a trailing slash are displayed for each untracked
+ directory.
+
+-v::
+--verbose::
+ Show unified diff between the HEAD commit and what
+ would be committed at the bottom of the commit message
+ template. Note that this diff output doesn't have its
+ lines prefixed with '#'.
+
+-q::
+--quiet::
+ Suppress commit summary message.
+
+\--::
+ Do not interpret any more arguments as options.
+
+<file>...::
+ When files are given on the command line, the command
+ commits the contents of the named files, without
+ recording the changes already staged. The contents of
+ these files are also staged for the next commit on top
+ of what have been staged before.
+
+
+EXAMPLES
+--------
+When recording your own work, the contents of modified files in
+your working tree are temporarily stored to a staging area
+called the "index" with linkgit:git-add[1]. A file can be
+reverted back, only in the index but not in the working tree,
+to that of the last commit with `git-reset HEAD -- <file>`,
+which effectively reverts `git-add` and prevents the changes to
+this file from participating in the next commit. After building
+the state to be committed incrementally with these commands,
+`git commit` (without any pathname parameter) is used to record what
+has been staged so far. This is the most basic form of the
+command. An example:
+
+------------
+$ edit hello.c
+$ git rm goodbye.c
+$ git add hello.c
+$ git commit
+------------
+
+Instead of staging files after each individual change, you can
+tell `git commit` to notice the changes to the files whose
+contents are tracked in
+your working tree and do corresponding `git add` and `git rm`
+for you. That is, this example does the same as the earlier
+example if there is no other change in your working tree:
+
+------------
+$ edit hello.c
+$ rm goodbye.c
+$ git commit -a
+------------
+
+The command `git commit -a` first looks at your working tree,
+notices that you have modified hello.c and removed goodbye.c,
+and performs necessary `git add` and `git rm` for you.
+
+After staging changes to many files, you can alter the order the
+changes are recorded in, by giving pathnames to `git commit`.
+When pathnames are given, the command makes a commit that
+only records the changes made to the named paths:
+
+------------
+$ edit hello.c hello.h
+$ git add hello.c hello.h
+$ edit Makefile
+$ git commit Makefile
+------------
+
+This makes a commit that records the modification to `Makefile`.
+The changes staged for `hello.c` and `hello.h` are not included
+in the resulting commit. However, their changes are not lost --
+they are still staged and merely held back. After the above
+sequence, if you do:
+
+------------
+$ git commit
+------------
+
+this second commit would record the changes to `hello.c` and
+`hello.h` as expected.
+
+After a merge (initiated by either linkgit:git-merge[1] or
+linkgit:git-pull[1]) stops because of conflicts, cleanly merged
+paths are already staged to be committed for you, and paths that
+conflicted are left in unmerged state. You would have to first
+check which paths are conflicting with linkgit:git-status[1]
+and after fixing them manually in your working tree, you would
+stage the result as usual with linkgit:git-add[1]:
+
+------------
+$ git status | grep unmerged
+unmerged: hello.c
+$ edit hello.c
+$ git add hello.c
+------------
+
+After resolving conflicts and staging the result, `git ls-files -u`
+would stop mentioning the conflicted path. When you are done,
+run `git commit` to finally record the merge:
+
+------------
+$ git commit
+------------
+
+As with the case to record your own changes, you can use `-a`
+option to save typing. One difference is that during a merge
+resolution, you cannot use `git commit` with pathnames to
+alter the order the changes are committed, because the merge
+should be recorded as a single commit. In fact, the command
+refuses to run when given pathnames (but see `-i` option).
+
+
+DISCUSSION
+----------
+
+Though not required, it's a good idea to begin the commit message
+with a single short (less than 50 character) line summarizing the
+change, followed by a blank line and then a more thorough description.
+Tools that turn commits into email, for example, use the first line
+on the Subject: line and the rest of the commit in the body.
+
+include::i18n.txt[]
+
+ENVIRONMENT AND CONFIGURATION VARIABLES
+---------------------------------------
+The editor used to edit the commit log message will be chosen from the
+GIT_EDITOR environment variable, the core.editor configuration variable, the
+VISUAL environment variable, or the EDITOR environment variable (in that
+order).
+
+HOOKS
+-----
+This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`,
+and `post-commit` hooks. See linkgit:githooks[5][hooks] for more
+information.
+
+
+SEE ALSO
+--------
+linkgit:git-add[1],
+linkgit:git-rm[1],
+linkgit:git-mv[1],
+linkgit:git-merge[1],
+linkgit:git-commit-tree[1]
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
new file mode 100644
index 0000000000..c90421ee7f
--- /dev/null
+++ b/Documentation/git-config.txt
@@ -0,0 +1,340 @@
+git-config(1)
+=============
+
+NAME
+----
+git-config - Get and set repository or global options
+
+
+SYNOPSIS
+--------
+[verse]
+'git-config' [<file-option>] [type] [-z|--null] name [value [value_regex]]
+'git-config' [<file-option>] [type] --add name value
+'git-config' [<file-option>] [type] --replace-all name [value [value_regex]]
+'git-config' [<file-option>] [type] [-z|--null] --get name [value_regex]
+'git-config' [<file-option>] [type] [-z|--null] --get-all name [value_regex]
+'git-config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex]
+'git-config' [<file-option>] --unset name [value_regex]
+'git-config' [<file-option>] --unset-all name [value_regex]
+'git-config' [<file-option>] --rename-section old_name new_name
+'git-config' [<file-option>] --remove-section name
+'git-config' [<file-option>] [-z|--null] -l | --list
+'git-config' [<file-option>] --get-color name [default]
+'git-config' [<file-option>] --get-colorbool name [stdout-is-tty]
+
+DESCRIPTION
+-----------
+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.
+
+Multiple lines can be added to an option by using the '--add' option.
+If you want to update or unset an option which can occur on multiple
+lines, a POSIX regexp `value_regex` needs to be given. Only the
+existing values that match the regexp are updated or unset. If
+you want to handle the lines that do *not* match the regex, just
+prepend a single exclamation mark in front (see also <<EXAMPLES>>).
+
+The type specifier can be either '--int' or '--bool', which will make
+'git-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.
+
+The file-option can be one of '--system', '--global' or '--file'
+which specify where the values will be read from or written to.
+The default is to assume the config file of the current repository,
+.git/config unless defined otherwise with GIT_DIR and GIT_CONFIG
+(see <<FILES>>).
+
+This command will fail if:
+
+. The config file is invalid,
+. Can not write to the config file,
+. no section was provided,
+. the section or key is invalid,
+. you try to unset an option which does not exist,
+. you try to unset/set an option for which multiple lines match, or
+. you use '--global' option without $HOME being properly set.
+
+
+OPTIONS
+-------
+
+--replace-all::
+ Default behavior is to replace at most one line. This replaces
+ all lines matching the key (and optionally the value_regex).
+
+--add::
+ Adds a new line to the option without altering any existing
+ values. This is the same as providing '^$' as the value_regex.
+
+--get::
+ Get the value for a given key (optionally filtered by a regex
+ matching the value). Returns error code 1 if the key was not
+ found and error code 2 if multiple key values were found.
+
+--get-all::
+ 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.
+ Also outputs the key names.
+
+--global::
+ For writing options: write to global ~/.gitconfig file rather than
+ the repository .git/config.
++
+For reading options: read only from global ~/.gitconfig rather than
+from all available files.
++
+See also <<FILES>>.
+
+--system::
+ For writing options: write to system-wide $(prefix)/etc/gitconfig
+ rather than the repository .git/config.
++
+For reading options: read only from system-wide $(prefix)/etc/gitconfig
+rather than from all available files.
++
+See also <<FILES>>.
+
+-f config-file::
+--file config-file::
+ Use the given config file instead of the one specified by GIT_CONFIG.
+
+--remove-section::
+ Remove the given section from the configuration file.
+
+--rename-section::
+ Rename the given section to a new name.
+
+--unset::
+ Remove the line matching the key from config file.
+
+--unset-all::
+ Remove all lines matching the key from config file.
+
+-l::
+--list::
+ List all variables set in config file.
+
+--bool::
+ git-config will ensure that the output is "true" or "false"
+
+--int::
+ git-config will ensure that the output is a simple
+ decimal number. An optional value suffix of 'k', 'm', or 'g'
+ in the config file will cause the value to be multiplied
+ by 1024, 1048576, or 1073741824 prior to output.
+
+-z::
+--null::
+ For all options that output values and/or keys, always
+ end values with the null character (instead of a
+ newline). Use newline instead as a delimiter between
+ key and value. This allows for secure parsing of the
+ output without getting confused e.g. by values that
+ contain line breaks.
+
+--get-colorbool name [stdout-is-tty]::
+
+ Find the color setting for `name` (e.g. `color.diff`) and output
+ "true" or "false". `stdout-is-tty` should be either "true" or
+ "false", and is taken into account when configuration says
+ "auto". If `stdout-is-tty` is missing, then checks the standard
+ output of the command itself, and exits with status 0 if color
+ is to be used, or exits with status 1 otherwise.
+ When the color setting for `name` is undefined, the command uses
+ `color.ui` as fallback.
+
+--get-color name default::
+
+ Find the color configured for `name` (e.g. `color.diff.new`) and
+ output it as the ANSI color escape sequence to the standard
+ output. The optional `default` parameter is used instead, if
+ there is no color configured for `name`.
+
+[[FILES]]
+FILES
+-----
+
+If not set explicitly with '--file', there are three files where
+git-config will search for configuration options:
+
+$GIT_DIR/config::
+ Repository specific configuration file. (The filename is
+ of course relative to the repository root, not the working
+ directory.)
+
+~/.gitconfig::
+ User-specific configuration file. Also called "global"
+ configuration file.
+
+$(prefix)/etc/gitconfig::
+ System-wide configuration file.
+
+If no further options are given, all reading options will read all of these
+files that are available. If the global or the system-wide configuration
+file are not available they will be ignored. If the repository configuration
+file is not available or readable, git-config will exit with a non-zero
+error code. However, in neither case will an error message be issued.
+
+All writing options will per default write to the repository specific
+configuration file. Note that this also affects options like '--replace-all'
+and '--unset'. *git-config will only ever change one file at a time*.
+
+You can override these rules either by command line options or by environment
+variables. The '--global' and the '--system' options will limit the file used
+to the global or system-wide file respectively. The GIT_CONFIG environment
+variable has a similar effect, but you can specify any filename you want.
+
+The GIT_CONFIG_LOCAL environment variable on the other hand only changes
+the name used instead of the repository configuration file. The global and
+the system-wide configuration files will still be read. (For writing options
+this will obviously result in the same behavior as using GIT_CONFIG.)
+
+
+ENVIRONMENT
+-----------
+
+GIT_CONFIG::
+ Take the configuration from the given file instead of .git/config.
+ Using the "--global" option forces this to ~/.gitconfig. Using the
+ "--system" option forces this to $(prefix)/etc/gitconfig.
+
+GIT_CONFIG_LOCAL::
+ Take the configuration from the given file instead if .git/config.
+ Still read the global and the system-wide configuration files, though.
+
+See also <<FILES>>.
+
+
+[[EXAMPLES]]
+EXAMPLES
+--------
+
+Given a .git/config like this:
+
+ #
+ # This is the config file, and
+ # a '#' or ';' character indicates
+ # a comment
+ #
+
+ ; core variables
+ [core]
+ ; Don't trust file modes
+ filemode = false
+
+ ; Our diff algorithm
+ [diff]
+ external = "/usr/local/bin/gnu-diff -u"
+ renames = true
+
+ ; Proxy settings
+ [core]
+ gitproxy="proxy-command" for kernel.org
+ gitproxy=default-proxy ; for all the rest
+
+you can set the filemode to true with
+
+------------
+% git config core.filemode true
+------------
+
+The hypothetical proxy command entries actually have a postfix to discern
+what URL they apply to. Here is how to change the entry for kernel.org
+to "ssh".
+
+------------
+% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'
+------------
+
+This makes sure that only the key/value pair for kernel.org is replaced.
+
+To delete the entry for renames, do
+
+------------
+% git config --unset diff.renames
+------------
+
+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
+
+------------
+% git config --get core.filemode
+------------
+
+or
+
+------------
+% git config core.filemode
+------------
+
+or, to query a multivar:
+
+------------
+% git config --get core.gitproxy "for kernel.org$"
+------------
+
+If you want to know all the values for a multivar, do:
+
+------------
+% git config --get-all core.gitproxy
+------------
+
+If you like to live dangerous, you can replace *all* core.gitproxy by a
+new one with
+
+------------
+% git 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 config core.gitproxy ssh '! for '
+------------
+
+To actually match only values with an exclamation mark, you have to
+
+------------
+% git config section.key value '[!]'
+------------
+
+To add a new proxy, without altering any of the existing ones, use
+
+------------
+% git config core.gitproxy '"proxy-command" for example.com'
+------------
+
+An example to use customized color from the configuration in your
+script:
+
+------------
+#!/bin/sh
+WS=$(git config --get-color color.diff.whitespace "blue reverse")
+RESET=$(git config --get-color "" "reset")
+echo "${WS}your whitespace color or blue reverse${RESET}"
+------------
+
+include::config.txt[]
+
+
+Author
+------
+Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
+
+Documentation
+--------------
+Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
new file mode 100644
index 0000000000..1ba85a259a
--- /dev/null
+++ b/Documentation/git-count-objects.txt
@@ -0,0 +1,38 @@
+git-count-objects(1)
+====================
+
+NAME
+----
+git-count-objects - Count unpacked number of objects and their disk consumption
+
+SYNOPSIS
+--------
+'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::
+--verbose::
+ In addition to the number of loose objects and disk
+ space consumed, it reports the number of in-pack
+ objects, number of packs, and number of objects that can be
+ removed by running `git-prune-packed`.
+
+
+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 linkgit:git[1] suite
diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt
new file mode 100644
index 0000000000..5fa91e51ad
--- /dev/null
+++ b/Documentation/git-cvsexportcommit.txt
@@ -0,0 +1,120 @@
+git-cvsexportcommit(1)
+======================
+
+NAME
+----
+git-cvsexportcommit - Export a single commit to a CVS checkout
+
+
+SYNOPSIS
+--------
+'git-cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
+
+
+DESCRIPTION
+-----------
+Exports a commit from GIT to a CVS checkout, making it easier
+to merge patches from a git repository into a CVS repository.
+
+Specify the name of a CVS checkout using the -w switch or execute it
+from the root of the CVS working copy. In the latter case 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
+by default.
+
+Supports file additions, removals, and commits that affect binary files.
+
+If the commit is a merge commit, you must tell git-cvsexportcommit what parent
+should the changeset be done against.
+
+OPTIONS
+-------
+
+-c::
+ Commit automatically if the patch applied cleanly. It will not
+ commit if any hunks fail to apply or there were other problems.
+
+-p::
+ 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.
+
+-d::
+ Set an alternative CVSROOT to use. This corresponds to the CVS
+ -d parameter. Usually users will not want to set this, except
+ if using CVS in an asymmetric fashion.
+
+-f::
+ Force the merge even if the files are not up to date.
+
+-P::
+ Force the parent commit, even if it is not a direct parent.
+
+-m::
+ Prepend the commit message with the provided prefix.
+ Useful for patch series and the like.
+
+-u::
+ Update affected files from CVS repository before attempting export.
+
+-w::
+ Specify the location of the CVS checkout to use for the export. This
+ option does not require GIT_DIR to be set before execution if the
+ current directory is within a git repository. The default is the
+ value of 'cvsexportcommit.cvsdir'.
+
+-W::
+ Tell cvsexportcommit that the current working directory is not only
+ a Git checkout, but also the CVS checkout. Therefore, Git will
+ reset the working directory to the parent commit before proceeding.
+
+-v::
+ Verbose.
+
+CONFIGURATION
+-------------
+cvsexportcommit.cvsdir::
+ The default location of the CVS checkout to use for the export.
+
+EXAMPLES
+--------
+
+Merge one patch into CVS::
++
+------------
+$ export GIT_DIR=~/project/.git
+$ cd ~/project_cvs_checkout
+$ git-cvsexportcommit -v <commit-sha1>
+$ cvs commit -F .msg <files>
+------------
+
+Merge one patch into CVS (-c and -w options). The working directory is within the Git Repo::
++
+------------
+ $ git-cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>
+------------
+
+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> and others.
+
+Documentation
+--------------
+Documentation by Martin Langhoff <martin@catalyst.net.nz> and others.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
new file mode 100644
index 0000000000..2f9b35f622
--- /dev/null
+++ b/Documentation/git-cvsimport.txt
@@ -0,0 +1,173 @@
+git-cvsimport(1)
+================
+
+NAME
+----
+git-cvsimport - Salvage your data out of another SCM people love to hate
+
+
+SYNOPSIS
+--------
+[verse]
+'git-cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
+ [-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>]
+ [-C <git_repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
+ [-a] [-m] [-M <regex>] [-S <regex>] [-L <commitlimit>]
+ [-r <remote>] [<CVS_module>]
+
+
+DESCRIPTION
+-----------
+Imports a CVS repository into git. It will either create a new
+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. By default 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. It is advisable to specify a named remote via
+-r to separate and protect the incoming branches.
+
+
+OPTIONS
+-------
+-v::
+ Verbosity: let 'cvsimport' report what it is doing.
+
+-d <CVSROOT>::
+ The root of the CVS archive. May be local (a simple path) or remote;
+ currently, only the :local:, :ext: and :pserver: access methods
+ are supported. If not given, git-cvsimport will try to read it
+ from `CVS/Root`. If no such file exists, it checks for the
+ `CVSROOT` environment variable.
+
+<CVS_module>::
+ The CVS module you want to import. Relative to <CVSROOT>.
+ If not given, git-cvsimport tries to read it from
+ `CVS/Repository`.
+
+-C <target-dir>::
+ The git repository to import to. If the directory doesn't
+ exist, it will be created. Default is the current directory.
+
+-r <remote>::
+ The git remote to import this CVS repository into.
+ Moves all CVS branches into remotes/<remote>/<branch>
+ akin to the git-clone --use-separate-remote option.
+
+-o <branch-for-HEAD>::
+ When no remote is specified (via -r) the 'HEAD' branch
+ from CVS is imported to the 'origin' branch within the git
+ repository, as 'HEAD' already has a special meaning for git.
+ When a remote is specified the 'HEAD' branch is named
+ remotes/<remote>/master mirroring git-clone behaviour.
+ Use this option if you want to import into a different
+ branch.
++
+Use '-o master' for continuing an import that was initially done by
+the old cvs2git tool.
+
+-i::
+ Import-only: don't perform a checkout after importing. This option
+ ensures the working directory and index remain untouched and will
+ not create them if they do not exist.
+
+-k::
+ Kill keywords: will extract files with '-kk' from the CVS archive
+ to avoid noisy changesets. Highly recommended, but off by default
+ to preserve compatibility with early imported trees.
+
+-u::
+ Convert underscores in tag and branch names to dots.
+
+-s <subst>::
+ Substitute the character "/" in branch names with <subst>
+
+-p <options-for-cvsps>::
+ Additional options for cvsps.
+ The options '-u' and '-A' are implicit and should not be used here.
++
+If you need to pass multiple options, separate them with a comma.
+
+-z <fuzz>::
+ Pass the timestamp fuzz factor to cvsps, in seconds. If unset,
+ cvsps defaults to 300s.
+
+-P <cvsps-output-file>::
+ Instead of calling cvsps, read the provided cvsps output file. Useful
+ for debugging or when cvsps is being handled outside cvsimport.
+
+-m::
+ Attempt to detect merges based on the commit message. This option
+ will enable default regexes that try to capture the source
+ branch name from the commit message.
+
+-M <regex>::
+ Attempt to detect merges based on the commit message with a custom
+ regex. It can be used with '-m' to enable the default regexes
+ as well. You must escape forward slashes.
++
+The regex must capture the source branch name in $1.
++
+This option can be used several times to provide several detection regexes.
+
+-S <regex>::
+ Skip paths matching the regex.
+
+-a::
+ Import all commits, including recent ones. cvsimport by default
+ skips commits that have a timestamp less than 10 minutes ago.
+
+-L <limit>::
+ Limit the number of commits imported. Workaround for cases where
+ cvsimport leaks memory.
+
+-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
+linkgit:git-cvsexportcommit[1].
+
+-h::
+ Print a short usage message and exit.
+
+OUTPUT
+------
+If '-v' is specified, the script reports what it is doing.
+
+Otherwise, success is indicated the Unix way, i.e. by simply exiting with
+a zero exit status.
+
+
+Author
+------
+Written by Matthias Urlichs <smurf@smurf.noris.de>, with help from
+various participants of the git-list <git@vger.kernel.org>.
+
+Documentation
+--------------
+Documentation by Matthias Urlichs <smurf@smurf.noris.de>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
new file mode 100644
index 0000000000..3310ae25ff
--- /dev/null
+++ b/Documentation/git-cvsserver.txt
@@ -0,0 +1,358 @@
+git-cvsserver(1)
+================
+
+NAME
+----
+git-cvsserver - A CVS server emulator for git
+
+SYNOPSIS
+--------
+
+SSH:
+
+[verse]
+export CVS_SERVER=git-cvsserver
+'cvs' -d :ext:user@server/path/repo.git co <HEAD_name>
+
+pserver (/etc/inetd.conf):
+
+[verse]
+cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
+
+Usage:
+
+[verse]
+'git-cvsserver' [options] [pserver|server] [<directory> ...]
+
+OPTIONS
+-------
+
+All these options obviously only make sense if enforced by the server side.
+They have been implemented to resemble the linkgit:git-daemon[1] options as
+closely as possible.
+
+--base-path <path>::
+Prepend 'path' to requested CVSROOT
+
+--strict-paths::
+Don't allow recursing into subdirectories
+
+--export-all::
+Don't check for `gitcvs.enabled` in config. You also have to specify a list
+of allowed directories (see below) if you want to use this option.
+
+-V::
+--version::
+Print version information and exit
+
+-h::
+-H::
+--help::
+Print usage information and exit
+
+<directory>::
+You can specify a list of allowed directories. If no directories
+are given, all are allowed. This is an additional restriction, gitcvs
+access still needs to be enabled by the `gitcvs.enabled` config option
+unless '--export-all' was given, too.
+
+
+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.
+
+git-cvsserver maps GIT branches to CVS modules. This is very different
+from what most CVS users would expect since in CVS modules usually represent
+one or more directories.
+
+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: Some inetd servers let you specify the name of the executable
+independently of the value of argv[0] (i.e. the name the program assumes
+it was executed with). In this case the correct line in /etc/inetd.conf
+looks like
+
+------
+ cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver 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
+environment variable, you can rename git-cvsserver to cvs.
+
+Note: Newer CVS versions (>= 1.12.11) also support specifying
+CVS_SERVER directly in CVSROOT like
+
+------
+cvs -d ":ext;CVS_SERVER=git-cvsserver:user@server/path/repo.git" co <HEAD_name>
+------
+This has the advantage that it will be saved in your 'CVS/Root' files and
+you don't need to worry about always setting the correct environment
+variable. SSH users restricted to git-shell don't need to override the default
+with CVS_SERVER (and shouldn't) as git-shell understands `cvs` to mean
+git-cvsserver and pretends that the other end runs the real cvs better.
+--
+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 database (see
+<<dbbackend,Database Backend>>. If you want to offer write access over
+SSH, the users of course also need write access to the git repository itself.
+
+[[configaccessmethod]]
+All configuration variables can also be overridden for a specific method of
+access. Valid method names are "ext" (for SSH access) and "pserver". The
+following example configuration would disable pserver access while still
+allowing access over SSH.
+------
+ [gitcvs]
+ enabled=0
+
+ [gitcvs "ext"]
+ enabled=1
+------
+--
+3. If you didn't specify the CVSROOT/CVS_SERVER directly in the checkout command,
+ automatically saving it in your 'CVS/Root' files, then you need to set them
+ explicitly in your environment. CVSROOT should be set as per normal, but the
+ directory should point at the appropriate git repo. As above, for SSH clients
+ _not_ restricted to git-shell, CVS_SERVER should be set to git-cvsserver.
++
+--
+------
+ 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 server-side
+ .ssh/environment files (or .bashrc, etc., according to their specific shell)
+ export appropriate values for GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL,
+ GIT_COMMITTER_NAME, and GIT_COMMITTER_EMAIL. For SSH clients whose login
+ shell is bash, .bashrc may be a reasonable alternative.
+
+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. This also sets the
+ name of your newly checked-out directory, unless you tell it otherwise with
+ `-d <dir_name>`. For example, this checks out 'master' branch to the
+ `project-master` directory:
++
+------
+ cvs co -d project-master master
+------
+
+[[dbbackend]]
+Database Backend
+----------------
+
+git-cvsserver uses one database per git head (i.e. CVS module) to
+store information about the repository for faster access. The
+database doesn't contain any persistent data and can be completely
+regenerated from the git repository at any time. The database
+needs to be updated (i.e. written to) after every commit.
+
+If the commit is done directly by using git (as opposed to
+using git-cvsserver) the update will need to happen on the
+next repository access by git-cvsserver, independent of
+access method and requested operation.
+
+That means that even if you offer only read access (e.g. by using
+the pserver method), git-cvsserver should have write access to
+the database to work reliably (otherwise you need to make sure
+that the database is up-to-date any time git-cvsserver is executed).
+
+By default it uses SQLite databases in the git directory, named
+`gitcvs.<module_name>.sqlite`. Note that the SQLite backend creates
+temporary files in the same directory as the database file on
+write so it might not be enough to grant the users using
+git-cvsserver write access to the database file without granting
+them write access to the directory, too.
+
+You can configure the database backend with the following
+configuration variables:
+
+Configuring database backend
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+git-cvsserver uses the Perl DBI module. Please also read
+its documentation if changing these variables, especially
+about `DBI->connect()`.
+
+gitcvs.dbname::
+ Database name. The exact meaning depends on the
+ selected database driver, for SQLite this is a filename.
+ Supports variable substitution (see below). May
+ not contain semicolons (`;`).
+ Default: '%Ggitcvs.%m.sqlite'
+
+gitcvs.dbdriver::
+ Used DBI driver. You can specify any available driver
+ for this here, but it might not work. cvsserver is tested
+ with 'DBD::SQLite', reported to work with
+ 'DBD::Pg', and reported *not* to work with 'DBD::mysql'.
+ Please regard this as an experimental feature. May not
+ contain colons (`:`).
+ Default: 'SQLite'
+
+gitcvs.dbuser::
+ Database user. Only useful if setting `dbdriver`, since
+ SQLite has no concept of database users. Supports variable
+ substitution (see below).
+
+gitcvs.dbpass::
+ Database password. Only useful if setting `dbdriver`, since
+ SQLite has no concept of database passwords.
+
+gitcvs.dbTableNamePrefix::
+ Database table name prefix. Supports variable substitution
+ (see below). Any non-alphabetic characters will be replaced
+ with underscores.
+
+All variables can also be set per access method, see <<configaccessmethod,above>>.
+
+Variable substitution
+^^^^^^^^^^^^^^^^^^^^^
+In `dbdriver` and `dbuser` you can use the following variables:
+
+%G::
+ git directory name
+%g::
+ git directory name, where all characters except for
+ alpha-numeric ones, `.`, and `-` are replaced with
+ `_` (this should make it easier to use the directory
+ name in a filename if wanted)
+%m::
+ CVS module/git head name
+%a::
+ access method (one of "ext" or "pserver")
+%u::
+ Name of the user running git-cvsserver.
+ If no name can be determined, the
+ numeric uid is used.
+
+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'. Note 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.
+
+CRLF Line Ending Conversions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+By default the server leaves the '-k' mode blank for all files,
+which causes the cvs client to treat them as a text files, subject
+to crlf conversion on some platforms.
+
+You can make the server use `crlf` attributes to set the '-k' modes
+for files by setting the `gitcvs.usecrlfattr` config variable.
+In this case, if `crlf` is explicitly unset ('-crlf'), then the
+server will set '-kb' mode for binary files. If `crlf` is set,
+then the '-k' mode will explicitly be left blank. See
+also linkgit:gitattributes[5] for more information about the `crlf`
+attribute.
+
+Alternatively, if `gitcvs.usecrlfattr` config is not enabled
+or if the `crlf` attribute is unspecified for a filename, then
+the server uses the `gitcvs.allbinary` config for the default setting.
+If `gitcvs.allbinary` is set, then file not otherwise
+specified will default to '-kb' mode. Otherwise the '-k' mode
+is left blank. But if `gitcvs.allbinary` is set to "guess", then
+the correct '-k' mode will be guessed based on the contents of
+the file.
+
+For best consistency with cvs, it is probably best to override the
+defaults by setting `gitcvs.usecrlfattr` to true,
+and `gitcvs.allbinary` to "guess".
+
+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>, Martin Langhoff <martin@catalyst.net.nz>, and Matthias Urlichs <smurf@smurf.noris.de>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
new file mode 100644
index 0000000000..344f24ea59
--- /dev/null
+++ b/Documentation/git-daemon.txt
@@ -0,0 +1,279 @@
+git-daemon(1)
+=============
+
+NAME
+----
+git-daemon - A really simple server for git repositories
+
+SYNOPSIS
+--------
+[verse]
+'git-daemon' [--verbose] [--syslog] [--export-all]
+ [--timeout=n] [--init-timeout=n] [--strict-paths]
+ [--base-path=path] [--user-path | --user-path=path]
+ [--interpolated-path=pathtemplate]
+ [--reuseaddr] [--detach] [--pid-file=file]
+ [--enable=service] [--disable=service]
+ [--allow-override=service] [--forbid-override=service]
+ [--inetd | [--listen=host_or_ipaddr] [--port=n] [--user=user [--group=group]]
+ [directory...]
+
+DESCRIPTION
+-----------
+A really simple TCP git daemon that normally listens on port "DEFAULT_GIT_PORT"
+aka 9418. It waits for a connection asking for a service, and will serve
+that service if it is enabled.
+
+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
+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.
+
+By default, only `upload-pack` service is enabled, which serves
+`git-fetch-pack` and `git-ls-remote` clients, which are invoked
+from `git-fetch`, `git-pull`, and `git-clone`.
+
+This is ideally suited for read-only updates, i.e., pulling from
+git repositories.
+
+An `upload-archive` also exists to serve `git-archive`.
+
+OPTIONS
+-------
+--strict-paths::
+ Match paths exactly (i.e. don't allow "/foo/repo" when the real path is
+ "/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths.
+ 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'.
+
+--base-path-relaxed::
+ If --base-path is enabled and repo lookup fails, with this option
+ `git-daemon` will attempt to lookup without prefixing the base path.
+ This is useful for switching to --base-path usage, while still
+ allowing the old paths.
+
+--interpolated-path=pathtemplate::
+ To support virtual hosting, an interpolated path template can be
+ used to dynamically construct alternate paths. The template
+ supports %H for the target hostname as supplied by the client but
+ converted to all lowercase, %CH for the canonical hostname,
+ %IP for the server's IP address, %P for the port number,
+ and %D for the absolute path of the named repository.
+ After interpolation, the path is validated against the directory
+ whitelist.
+
+--export-all::
+ Allow pulling from all directories that look like GIT repositories
+ (have the 'objects' and 'refs' subdirectories), even if they
+ do not have the 'git-daemon-export-ok' file.
+
+--inetd::
+ Have the server run as an inetd service. Implies --syslog.
+ Incompatible with --port, --listen, --user and --group options.
+
+--listen=host_or_ipaddr::
+ Listen on an a specific IP address or hostname. IP addresses can
+ be either an IPv4 address or an IPV6 address if supported. If IPv6
+ is not supported, then --listen=hostname is also not supported and
+ --listen must be given an IPv4 address.
+ Incompatible with '--inetd' option.
+
+--port=n::
+ Listen on an alternative port. Incompatible with '--inetd' option.
+
+--init-timeout::
+ Timeout between the moment the connection is established and the
+ client request is received (typically a rather low value, since
+ that should be basically immediate).
+
+--timeout::
+ Timeout for specific client sub-requests. This includes the time
+ it takes for the server to process the sub-request and time spent
+ waiting for next client's request.
+
+--syslog::
+ 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.
+
+--reuseaddr::
+ Use SO_REUSEADDR when binding the listening socket.
+ This allows the server to restart without waiting for
+ old connections to time out.
+
+--detach::
+ Detach from the shell. Implies --syslog.
+
+--pid-file=file::
+ Save the process id in 'file'. Ignored when the daemon
+ is run under `--inetd`.
+
+--user=user::
+--group=group::
+ Change daemon's uid and gid before entering the service loop.
+ When only `--user` is given without `--group`, the
+ primary group ID for the user is used. The values of
+ the option are given to `getpwnam(3)` and `getgrnam(3)`
+ and numeric IDs are not supported.
++
+Giving these options is an error when used with `--inetd`; use
+the facility of inet daemon to achieve the same before spawning
+`git-daemon` if needed.
+
+--enable=service::
+--disable=service::
+ Enable/disable the service site-wide per default. Note
+ that a service disabled site-wide can still be enabled
+ per repository if it is marked overridable and the
+ repository enables the service with an configuration
+ item.
+
+--allow-override=service::
+--forbid-override=service::
+ Allow/forbid overriding the site-wide default with per
+ repository configuration. By default, all the services
+ are overridable.
+
+<directory>::
+ A directory to add to the whitelist of allowed directories. Unless
+ --strict-paths is specified this will also include subdirectories
+ of each named directory.
+
+SERVICES
+--------
+
+These services can be globally enabled/disabled using the
+command line options of this command. If a finer-grained
+control is desired (e.g. to allow `git-archive` to be run
+against only in a few selected repositories the daemon serves),
+the per-repository configuration file can be used to enable or
+disable them.
+
+upload-pack::
+ This serves `git-fetch-pack` and `git-ls-remote`
+ clients. It is enabled by default, but a repository can
+ disable it by setting `daemon.uploadpack` configuration
+ item to `false`.
+
+upload-archive::
+ This serves `git-archive --remote`. It is disabled by
+ default, but a repository can enable it by setting
+ `daemon.uploadarch` configuration item to `true`.
+
+receive-pack::
+ This serves `git-send-pack` clients, allowing anonymous
+ push. It is disabled by default, as there is _no_
+ authentication in the protocol (in other words, anybody
+ can push anything into the repository, including removal
+ of refs). This is solely meant for a closed LAN setting
+ where everybody is friendly. This service can be
+ enabled by `daemon.receivepack` configuration item to
+ `true`.
+
+EXAMPLES
+--------
+We assume the following in /etc/services::
++
+------------
+$ grep 9418 /etc/services
+git 9418/tcp # Git Version Control System
+------------
+
+git-daemon as inetd server::
+ To set up `git-daemon` as an inetd service that handles any
+ repository under the whitelisted set of directories, /pub/foo
+ and /pub/bar, place an entry like the following into
+ /etc/inetd all on one line:
++
+------------------------------------------------
+ git stream tcp nowait nobody /usr/bin/git-daemon
+ git-daemon --inetd --verbose --export-all
+ /pub/foo /pub/bar
+------------------------------------------------
+
+
+git-daemon as inetd server for virtual hosts::
+ To set up `git-daemon` as an inetd service that handles
+ repositories for different virtual hosts, `www.example.com`
+ and `www.example.org`, place an entry like the following into
+ `/etc/inetd` all on one line:
++
+------------------------------------------------
+ git stream tcp nowait nobody /usr/bin/git-daemon
+ git-daemon --inetd --verbose --export-all
+ --interpolated-path=/pub/%H%D
+ /pub/www.example.org/software
+ /pub/www.example.com/software
+ /software
+------------------------------------------------
++
+In this example, the root-level directory `/pub` will contain
+a subdirectory for each virtual host name supported.
+Further, both hosts advertise repositories simply as
+`git://www.example.com/software/repo.git`. For pre-1.4.0
+clients, a symlink from `/software` into the appropriate
+default repository could be made as well.
+
+
+git-daemon as regular daemon for virtual hosts::
+ To set up `git-daemon` as a regular, non-inetd service that
+ handles repositories for multiple virtual hosts based on
+ their IP addresses, start the daemon like this:
++
+------------------------------------------------
+ git-daemon --verbose --export-all
+ --interpolated-path=/pub/%IP/%D
+ /pub/192.168.1.200/software
+ /pub/10.10.220.23/software
+------------------------------------------------
++
+In this example, the root-level directory `/pub` will contain
+a subdirectory for each virtual host IP address supported.
+Repositories can still be accessed by hostname though, assuming
+they correspond to these IP addresses.
+
+selectively enable/disable services per repository::
+ To enable `git-archive --remote` and disable `git-fetch` against
+ a repository, have the following in the configuration file in the
+ repository (that is the file 'config' next to 'HEAD', 'refs' and
+ 'objects').
++
+----------------------------------------------------------------
+ [daemon]
+ uploadpack = false
+ uploadarch = true
+----------------------------------------------------------------
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>, YOSHIFUJI Hideaki
+<yoshfuji@linux-ipv6.org> and the git-list <git@vger.kernel.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
new file mode 100644
index 0000000000..9f6f483186
--- /dev/null
+++ b/Documentation/git-describe.txt
@@ -0,0 +1,148 @@
+git-describe(1)
+===============
+
+NAME
+----
+git-describe - Show the most recent tag that is reachable from a commit
+
+
+SYNOPSIS
+--------
+'git-describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
+
+DESCRIPTION
+-----------
+The command finds the most recent tag that is reachable from a
+commit. If the tag points to the commit, then only the tag is
+shown. Otherwise, it suffixes the tag name with the number of
+additional commits on top of the tagged object and the
+abbreviated object name of the most recent 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`.
+
+--contains::
+ Instead of finding the tag that predates the commit, find
+ the tag that comes after the commit, and thus contains it.
+ Automatically implies --tags.
+
+--abbrev=<n>::
+ Instead of using the default 8 hexadecimal digits as the
+ abbreviated object name, use <n> digits.
+
+--candidates=<n>::
+ Instead of considering only the 10 most recent tags as
+ candidates to describe the input committish consider
+ up to <n> candidates. Increasing <n> above 10 will take
+ slightly longer but may produce a more accurate result.
+ An <n> of 0 will cause only exact matches to be output.
+
+--exact-match::
+ Only output exact matches (a tag directly references the
+ supplied commit). This is a synonym for --candidates=0.
+
+--debug::
+ Verbosely display information about the searching strategy
+ being employed to standard error. The tag name will still
+ be printed to standard out.
+
+--long::
+ Always output the long format (the tag, the number of commits
+ and the abbreviated commit name) even when it matches a tag.
+ This is useful when you want to see parts of the commit object name
+ in "describe" output, even when the commit in question happens to be
+ a tagged version. Instead of just emitting the tag name, it will
+ describe such a commit as v1.2-0-deadbeef (0th commit since tag v1.2
+ that points at object deadbeef....).
+
+--match <pattern>::
+ Only consider tags matching the given pattern (can be used to avoid
+ leaking private tags made from the repository).
+
+--always::
+ Show uniquely abbreviated commit object as fallback.
+
+EXAMPLES
+--------
+
+With something like git.git current tree, I get:
+
+ [torvalds@g5 git]$ git-describe parent
+ v1.0.4-14-g2414721
+
+i.e. the current head of my "parent" branch is based on v1.0.4,
+but since it has a handful commits on top of that,
+describe has added the number of additional commits ("14") and
+an abbreviated object name for the commit itself ("2414721")
+at the end.
+
+The number of additional commits is the number
+of commits which would be displayed by "git log v1.0.4..parent".
+The hash suffix is "-g" + 7-char abbreviation for the tip commit
+of parent (which was `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-21-g975b
+
+ [torvalds@g5 git]$ git describe --all HEAD^
+ heads/lt/describe-7-g975b
+
+With --abbrev set to 0, the command can be used to find the
+closest tagname without any suffix:
+
+ [torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2
+ tags/v1.0.0
+
+SEARCH STRATEGY
+---------------
+
+For each committish supplied "git describe" will first look for
+a tag which tags exactly that commit. Annotated tags will always
+be preferred over lightweight tags, and tags with newer dates will
+always be preferred over tags with older dates. If an exact match
+is found, its name will be output and searching will stop.
+
+If an exact match was not found "git describe" will walk back
+through the commit history to locate an ancestor commit which
+has been tagged. The ancestor's tag will be output along with an
+abbreviation of the input committish's SHA1.
+
+If multiple tags were found during the walk then the tag which
+has the fewest commits different from the input committish will be
+selected and output. Here fewest commits different is defined as
+the number of commits which would be shown by "git log tag..input"
+will be the smallest number of commits possible.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>, but somewhat
+butchered by Junio C Hamano <junkio@cox.net>. Later significantly
+updated by Shawn Pearce <spearce@spearce.org>.
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-diff-files.txt b/Documentation/git-diff-files.txt
new file mode 100644
index 0000000000..8a64869d27
--- /dev/null
+++ b/Documentation/git-diff-files.txt
@@ -0,0 +1,58 @@
+git-diff-files(1)
+=================
+
+NAME
+----
+git-diff-files - Compares files in the working tree and the index
+
+
+SYNOPSIS
+--------
+'git-diff-files' [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>...]
+
+DESCRIPTION
+-----------
+Compares the files in the working tree and the index. When paths
+are specified, compares only those named paths. Otherwise all
+entries in the index are compared. The output format is the
+same as "git-diff-index" and "git-diff-tree".
+
+OPTIONS
+-------
+include::diff-options.txt[]
+
+-1 -2 -3 or --base --ours --theirs, and -0::
+ Diff against the "base" version, "our branch" or "their
+ branch" respectively. With these options, diffs for
+ merged entries are not shown.
++
+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 nonexistent files
+
+Output format
+-------------
+include::diff-format.txt[]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt
new file mode 100644
index 0000000000..f6e844fe61
--- /dev/null
+++ b/Documentation/git-diff-index.txt
@@ -0,0 +1,132 @@
+git-diff-index(1)
+=================
+
+NAME
+----
+git-diff-index - Compares content and mode of blobs between the index and repository
+
+
+SYNOPSIS
+--------
+'git-diff-index' [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
+
+DESCRIPTION
+-----------
+Compares the content and mode of the blobs found via a tree
+object with the content of the current index and, optionally
+ignoring the stat state of the file on disk. When paths are
+specified, compares only those named paths. Otherwise all
+entries in the index are compared.
+
+OPTIONS
+-------
+include::diff-options.txt[]
+
+<tree-ish>::
+ The id of a tree object to diff against.
+
+--cached::
+ do not consider the on-disk file at all
+
+-m::
+ By default, files recorded in the index but not checked
+ out are reported as deleted. This flag makes
+ "git-diff-index" say that all non-checked-out files are up
+ to date.
+
+Output format
+-------------
+include::diff-format.txt[]
+
+Operating Modes
+---------------
+You can choose whether you want to trust the index file entirely
+(using the '--cached' flag) or ask the diff logic to show any files
+that don't match the stat state as being "tentatively changed". Both
+of these operations are very useful indeed.
+
+Cached Mode
+-----------
+If '--cached' is specified, it allows you to ask:
+
+ show me the differences between HEAD and the current index
+ contents (the ones I'd write with a "git-write-tree")
+
+For example, let's say that you have worked on your working directory, updated
+some files in the index and are ready to commit. You want to see exactly
+*what* you are going to commit, without having to write a new tree
+object and compare it that way, and to do that, you just do
+
+ git-diff-index --cached HEAD
+
+Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
+done an "git-update-index" to make that effective in the index file.
+"git-diff-files" wouldn't show anything at all, since the index file
+matches my working directory. But doing a "git-diff-index" does:
+
+ torvalds@ppc970:~/git> git-diff-index --cached HEAD
+ -100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+ +100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c
+
+You can see easily that the above is a rename.
+
+In fact, "git-diff-index --cached" *should* always be entirely equivalent to
+actually doing a "git-write-tree" and comparing that. Except this one is much
+nicer for the case where you just want to check where you are.
+
+So doing a "git-diff-index --cached" is basically very useful when you are
+asking yourself "what have I already marked for being committed, and
+what's the difference to a previous tree".
+
+Non-cached Mode
+---------------
+The "non-cached" mode takes a different approach, and is potentially
+the more useful of the two in that what it does can't be emulated with
+a "git-write-tree" + "git-diff-tree". Thus that's the default mode.
+The non-cached version asks the question:
+
+ show me the differences between HEAD and the currently checked out
+ tree - index contents _and_ files that aren't up-to-date
+
+which is obviously a very useful question too, since that tells you what
+you *could* commit. Again, the output matches the "git-diff-tree -r"
+output to a tee, but with a twist.
+
+The twist is that if some file doesn't match the index, we don't have
+a backing store thing for it, and we use the magic "all-zero" sha1 to
+show that. So let's say that you have edited `kernel/sched.c`, but
+have not actually done a "git-update-index" on it yet - there is no
+"object" associated with the new state, and you get:
+
+ torvalds@ppc970:~/v2.6/linux> git-diff-index HEAD
+ *100644->100664 blob 7476bb......->000000...... kernel/sched.c
+
+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.
+
+NOTE: As with other commands of this type, "git-diff-index" does not
+actually look at the contents of the file at all. So maybe
+`kernel/sched.c` hasn't actually changed, and it's just that you
+touched it. In either case, it's a note that you need to
+"git-update-index" it to make the index be in sync.
+
+NOTE: You can have a mixture of files show up as "has been updated"
+and "is still dirty in the working directory" together. You can always
+tell which file is in which state, since the "has been updated" ones
+show a valid sha1, and the "not in sync with the index" ones will
+always have the special all-zero sha1.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
new file mode 100644
index 0000000000..56caeb2d26
--- /dev/null
+++ b/Documentation/git-diff-tree.txt
@@ -0,0 +1,168 @@
+git-diff-tree(1)
+================
+
+NAME
+----
+git-diff-tree - Compares the content and mode of blobs found via two tree objects
+
+
+SYNOPSIS
+--------
+[verse]
+'git-diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
+ [-t] [-r] [-c | --cc] [--root] [<common diff options>]
+ <tree-ish> [<tree-ish>] [<path>...]
+
+DESCRIPTION
+-----------
+Compares the content and mode of the blobs found via two tree objects.
+
+If there is only one <tree-ish> given, the commit is compared with its parents
+(see --stdin below).
+
+Note that "git-diff-tree" can use the tree encapsulated in a commit object.
+
+OPTIONS
+-------
+include::diff-options.txt[]
+
+<tree-ish>::
+ The id of a tree object.
+
+<path>...::
+ If provided, the results are limited to a subset of files
+ matching one of these prefix strings.
+ i.e., file matches `/^<pattern1>|<pattern2>|.../`
+ Note that this parameter does not provide any wildcard or regexp
+ features.
+
+-r::
+ recurse into sub-trees
+
+-t::
+ show tree entry itself as well as subtrees. Implies -r.
+
+--root::
+ When '--root' is specified the initial commit will be showed as a big
+ creation event. This is equivalent to a diff against the NULL tree.
+
+--stdin::
+ When '--stdin' is specified, the command does not take
+ <tree-ish> arguments from the command line. Instead, it
+ reads either one <commit> or a pair of <tree-ish>
+ separated with a single space from its standard input.
++
+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
+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. See
+ also '-c'.
+
+-s::
+ By default, "git-diff-tree --stdin" shows differences,
+ either in machine-readable form (without '-p') or in patch
+ form (with '-p'). This output can be suppressed. It is
+ only useful with '-v' flag.
+
+-v::
+ This flag causes "git-diff-tree --stdin" to also show
+ the commit message before the differences.
+
+include::pretty-options.txt[]
+
+--no-commit-id::
+ 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.
+
+
+include::pretty-formats.txt[]
+
+
+Limiting Output
+---------------
+If you're only interested in differences in a subset of files, for
+example some architecture-specific files, you might do:
+
+ git-diff-tree -r <tree-ish> <tree-ish> arch/ia64 include/asm-ia64
+
+and it will only show you what changed in those two directories.
+
+Or if you are searching for what changed in just `kernel/sched.c`, just do
+
+ git-diff-tree -r <tree-ish> <tree-ish> kernel/sched.c
+
+and it will ignore all differences to other files.
+
+The pattern is always the prefix, and is matched exactly. There are no
+wildcards. Even stricter, it has to match a complete path component.
+I.e. "foo" does not pick up `foobar.h`. "foo" does match `foo/bar.h`
+so it can be used to name subdirectories.
+
+An example of normal usage is:
+
+ torvalds@ppc970:~/git> git-diff-tree 5319e4......
+ *100664->100664 blob ac348b.......->a01513....... git-fsck-objects.c
+
+which tells you that the last commit changed just one file (it's from
+this one:
+
+-----------------------------------------------------------------------------
+commit 3c6f7ca19ad4043e9e72fa94106f352897e651a8
+tree 5319e4d609cdd282069cc4dce33c1db559539b03
+parent b4e628ea30d5ab3606119d2ea5caeab141d38df7
+author Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
+committer Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
+
+Make "git-fsck-objects" print out all the root commits it finds.
+
+Once I do the reference tracking, I'll also make it print out all the
+HEAD commits it finds, which is even more interesting.
+-----------------------------------------------------------------------------
+
+in case you care).
+
+Output format
+-------------
+include::diff-format.txt[]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
new file mode 100644
index 0000000000..7acd428964
--- /dev/null
+++ b/Documentation/git-diff.txt
@@ -0,0 +1,171 @@
+git-diff(1)
+===========
+
+NAME
+----
+git-diff - Show changes between commits, commit and working tree, etc
+
+
+SYNOPSIS
+--------
+'git-diff' [<common diff options>] <commit>{0,2} [--] [<path>...]
+
+DESCRIPTION
+-----------
+Show changes between two trees, a tree and the working tree, a
+tree and the index file, or the index file and the working tree.
+
+'git-diff' [--options] [--] [<path>...]::
+
+ This form is to view the changes you made relative to
+ the index (staging area for the next commit). In other
+ words, the differences are what you _could_ tell git to
+ further add to the index but you still haven't. You can
+ stage these changes by using linkgit:git-add[1].
++
+If exactly two paths are given, and at least one is untracked,
+compare the two files / directories. This behavior can be
+forced by --no-index.
+
+'git-diff' [--options] --cached [<commit>] [--] [<path>...]::
+
+ This form is to view the changes you staged for the next
+ commit relative to the named <commit>. Typically you
+ would want comparison with the latest commit, so if you
+ do not give <commit>, it defaults to HEAD.
+
+'git-diff' [--options] <commit> [--] [<path>...]::
+
+ This form is to view the changes you have in your
+ working tree relative to the named <commit>. You can
+ use HEAD to compare it with the latest commit, or a
+ branch name to compare with the tip of a different
+ branch.
+
+'git-diff' [--options] <commit> <commit> [--] [<path>...]::
+
+ This is to view the changes between two arbitrary
+ <commit>.
+
+'git-diff' [--options] <commit>..<commit> [--] [<path>...]::
+
+ This is synonymous to the previous form. If <commit> on
+ one side is omitted, it will have the same effect as
+ using HEAD instead.
+
+'git-diff' [--options] <commit>\...<commit> [--] [<path>...]::
+
+ This form is to view the changes on the branch containing
+ and up to the second <commit>, starting at a common ancestor
+ of both <commit>. "git-diff A\...B" is equivalent to
+ "git-diff $(git-merge-base A B) B". You can omit any one
+ of <commit>, which has the same effect as using HEAD instead.
+
+Just in case if you are doing something exotic, it should be
+noted that all of the <commit> in the above description, except
+for the last two forms that use ".." notations, can be any
+<tree-ish>.
+
+For a more complete list of ways to spell <commit>, see
+"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
+However, "diff" is about comparing two _endpoints_, not ranges,
+and the range notations ("<commit>..<commit>" and
+"<commit>\...<commit>") do not mean a range as defined in the
+"SPECIFYING RANGES" section in linkgit:git-rev-parse[1].
+
+OPTIONS
+-------
+:git-diff: 1
+include::diff-options.txt[]
+
+<path>...::
+ The <paths> parameters, when given, are used to limit
+ the diff to the named paths (you can give directory
+ names and get diff for all files under them).
+
+Output format
+-------------
+include::diff-format.txt[]
+
+EXAMPLES
+--------
+
+Various ways to check your working tree::
++
+------------
+$ git diff <1>
+$ git diff --cached <2>
+$ git diff HEAD <3>
+------------
++
+<1> Changes in the working tree not yet staged for the next commit.
+<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 HEAD -- ./test <2>
+$ 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.
+
+Comparing branches::
++
+------------
+$ git diff topic master <1>
+$ git diff topic..master <2>
+$ git diff topic...master <3>
+------------
++
+<1> Changes between the tips of the topic and the master branches.
+<2> Same as above.
+<3> Changes that occurred on the master branch since when the topic
+branch was started off it.
+
+Limiting the diff output::
++
+------------
+$ git diff --diff-filter=MRC <1>
+$ git diff --name-status <2>
+$ 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.
+<3> Limit diff output to named subtrees.
+
+Munging the diff output::
++
+------------
+$ git diff --find-copies-harder -B -C <1>
+$ git diff -R <2>
+------------
++
+<1> Spend extra cycles to find renames, copies and complete
+rewrites (very expensive).
+<2> Output diff in reverse.
+
+
+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 linkgit:git[1] suite
diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt
new file mode 100644
index 0000000000..332346cc5d
--- /dev/null
+++ b/Documentation/git-fast-export.txt
@@ -0,0 +1,83 @@
+git-fast-export(1)
+==================
+
+NAME
+----
+git-fast-export - Git data exporter
+
+
+SYNOPSIS
+--------
+'git-fast-export [options]' | 'git-fast-import'
+
+DESCRIPTION
+-----------
+This program dumps the given revisions in a form suitable to be piped
+into linkgit:git-fast-import[1].
+
+You can use it as a human readable bundle replacement (see
+linkgit:git-bundle[1]), or as a kind of an interactive
+linkgit:git-filter-branch[1].
+
+
+OPTIONS
+-------
+--progress=<n>::
+ Insert 'progress' statements every <n> objects, to be shown by
+ linkgit:git-fast-import[1] during import.
+
+--signed-tags=(verbatim|warn|strip|abort)::
+ Specify how to handle signed tags. Since any transformation
+ after the export can change the tag names (which can also happen
+ when excluding revisions) the signatures will not match.
++
+When asking to 'abort' (which is the default), this program will die
+when encountering a signed tag. With 'strip', the tags will be made
+unsigned, with 'verbatim', they will be silently exported
+and with 'warn', they will be exported, but you will see a warning.
+
+
+EXAMPLES
+--------
+
+-------------------------------------------------------------------
+$ git fast-export --all | (cd /empty/repository && git fast-import)
+-------------------------------------------------------------------
+
+This will export the whole repository and import it into the existing
+empty repository. Except for reencoding commits that are not in
+UTF-8, it would be a one-to-one mirror.
+
+-----------------------------------------------------
+$ git fast-export master~5..master |
+ sed "s|refs/heads/master|refs/heads/other|" |
+ git fast-import
+-----------------------------------------------------
+
+This makes a new branch called 'other' from 'master~5..master'
+(i.e. if 'master' has linear history, it will take the last 5 commits).
+
+Note that this assumes that none of the blobs and commit messages
+referenced by that revision range contains the string
+'refs/heads/master'.
+
+
+Limitations
+-----------
+
+Since linkgit:git-fast-import[1] cannot tag trees, you will not be
+able to export the linux-2.6.git repository completely, as it contains
+a tag referencing a tree instead of a commit.
+
+
+Author
+------
+Written by Johannes E. Schindelin <johannes.schindelin@gmx.de>.
+
+Documentation
+--------------
+Documentation by Johannes E. Schindelin <johannes.schindelin@gmx.de>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
new file mode 100644
index 0000000000..395c055f95
--- /dev/null
+++ b/Documentation/git-fast-import.txt
@@ -0,0 +1,1122 @@
+git-fast-import(1)
+==================
+
+NAME
+----
+git-fast-import - Backend for fast Git data importers
+
+
+SYNOPSIS
+--------
+frontend | 'git-fast-import' [options]
+
+DESCRIPTION
+-----------
+This program is usually not what the end user wants to run directly.
+Most end users want to use one of the existing frontend programs,
+which parses a specific type of foreign source and feeds the contents
+stored there to git-fast-import.
+
+fast-import reads a mixed command/data stream from standard input and
+writes one or more packfiles directly into the current repository.
+When EOF is received on standard input, fast import writes out
+updated branch and tag refs, fully updating the current repository
+with the newly imported data.
+
+The fast-import backend itself can import into an empty repository (one that
+has already been initialized by linkgit:git-init[1]) or incrementally
+update an existing populated repository. Whether or not incremental
+imports are supported from a particular foreign source depends on
+the frontend program in use.
+
+
+OPTIONS
+-------
+--date-format=<fmt>::
+ Specify the type of dates the frontend will supply to
+ fast-import within `author`, `committer` and `tagger` commands.
+ See ``Date Formats'' below for details about which formats
+ are supported, and their syntax.
+
+--force::
+ Force updating modified existing branches, even if doing
+ so would cause commits to be lost (as the new commit does
+ not contain the old commit).
+
+--max-pack-size=<n>::
+ Maximum size of each output packfile, expressed in MiB.
+ The default is 4096 (4 GiB) as that is the maximum allowed
+ packfile size (due to file format limitations). Some
+ importers may wish to lower this, such as to ensure the
+ resulting packfiles fit on CDs.
+
+--depth=<n>::
+ Maximum delta depth, for blob and tree deltification.
+ Default is 10.
+
+--active-branches=<n>::
+ Maximum number of branches to maintain active at once.
+ See ``Memory Utilization'' below for details. Default is 5.
+
+--export-marks=<file>::
+ Dumps the internal marks table to <file> when complete.
+ Marks are written one per line as `:markid SHA-1`.
+ Frontends can use this file to validate imports after they
+ have been completed, or to save the marks table across
+ incremental runs. As <file> is only opened and truncated
+ at checkpoint (or completion) the same path can also be
+ safely given to \--import-marks.
+
+--import-marks=<file>::
+ Before processing any input, load the marks specified in
+ <file>. The input file must exist, must be readable, and
+ must use the same format as produced by \--export-marks.
+ Multiple options may be supplied to import more than one
+ set of marks. If a mark is defined to different values,
+ the last file wins.
+
+--export-pack-edges=<file>::
+ After creating a packfile, print a line of data to
+ <file> listing the filename of the packfile and the last
+ commit on each branch that was written to that packfile.
+ This information may be useful after importing projects
+ whose total object set exceeds the 4 GiB packfile limit,
+ as these commits can be used as edge points during calls
+ to linkgit:git-pack-objects[1].
+
+--quiet::
+ Disable all non-fatal output, making fast-import silent when it
+ is successful. This option disables the output shown by
+ \--stats.
+
+--stats::
+ Display some basic statistics about the objects fast-import has
+ created, the packfiles they were stored into, and the
+ memory used by fast-import during this run. Showing this output
+ is currently the default, but can be disabled with \--quiet.
+
+
+Performance
+-----------
+The design of fast-import allows it to import large projects in a minimum
+amount of memory usage and processing time. Assuming the frontend
+is able to keep up with fast-import and feed it a constant stream of data,
+import times for projects holding 10+ years of history and containing
+100,000+ individual commits are generally completed in just 1-2
+hours on quite modest (~$2,000 USD) hardware.
+
+Most bottlenecks appear to be in foreign source data access (the
+source just cannot extract revisions fast enough) or disk IO (fast-import
+writes as fast as the disk will take the data). Imports will run
+faster if the source data is stored on a different drive than the
+destination Git repository (due to less IO contention).
+
+
+Development Cost
+----------------
+A typical frontend for fast-import tends to weigh in at approximately 200
+lines of Perl/Python/Ruby code. Most developers have been able to
+create working importers in just a couple of hours, even though it
+is their first exposure to fast-import, and sometimes even to Git. This is
+an ideal situation, given that most conversion tools are throw-away
+(use once, and never look back).
+
+
+Parallel Operation
+------------------
+Like `git-push` or `git-fetch`, imports handled by fast-import are safe to
+run alongside parallel `git repack -a -d` or `git gc` invocations,
+or any other Git operation (including `git prune`, as loose objects
+are never used by fast-import).
+
+fast-import does not lock the branch or tag refs it is actively importing.
+After the import, during its ref update phase, fast-import tests each
+existing branch ref to verify the update will be a fast-forward
+update (the commit stored in the ref is contained in the new
+history of the commit to be written). If the update is not a
+fast-forward update, fast-import will skip updating that ref and instead
+prints a warning message. fast-import will always attempt to update all
+branch refs, and does not stop on the first failure.
+
+Branch updates can be forced with \--force, but its recommended that
+this only be used on an otherwise quiet repository. Using \--force
+is not necessary for an initial import into an empty repository.
+
+
+Technical Discussion
+--------------------
+fast-import tracks a set of branches in memory. Any branch can be created
+or modified at any point during the import process by sending a
+`commit` command on the input stream. This design allows a frontend
+program to process an unlimited number of branches simultaneously,
+generating commits in the order they are available from the source
+data. It also simplifies the frontend programs considerably.
+
+fast-import does not use or alter the current working directory, or any
+file within it. (It does however update the current Git repository,
+as referenced by `GIT_DIR`.) Therefore an import frontend may use
+the working directory for its own purposes, such as extracting file
+revisions from the foreign source. This ignorance of the working
+directory also allows fast-import to run very quickly, as it does not
+need to perform any costly file update operations when switching
+between branches.
+
+Input Format
+------------
+With the exception of raw file data (which Git does not interpret)
+the fast-import input format is text (ASCII) based. This text based
+format simplifies development and debugging of frontend programs,
+especially when a higher level language such as Perl, Python or
+Ruby is being used.
+
+fast-import is very strict about its input. Where we say SP below we mean
+*exactly* one space. Likewise LF means one (and only one) linefeed.
+Supplying additional whitespace characters will cause unexpected
+results, such as branch names or file names with leading or trailing
+spaces in their name, or early termination of fast-import when it encounters
+unexpected input.
+
+Stream Comments
+~~~~~~~~~~~~~~~
+To aid in debugging frontends fast-import ignores any line that
+begins with `#` (ASCII pound/hash) up to and including the line
+ending `LF`. A comment line may contain any sequence of bytes
+that does not contain an LF and therefore may be used to include
+any detailed debugging information that might be specific to the
+frontend and useful when inspecting a fast-import data stream.
+
+Date Formats
+~~~~~~~~~~~~
+The following date formats are supported. A frontend should select
+the format it will use for this import by passing the format name
+in the \--date-format=<fmt> command line option.
+
+`raw`::
+ This is the Git native format and is `<time> SP <offutc>`.
+ It is also fast-import's default format, if \--date-format was
+ not specified.
++
+The time of the event is specified by `<time>` as the number of
+seconds since the UNIX epoch (midnight, Jan 1, 1970, UTC) and is
+written as an ASCII decimal integer.
++
+The local offset is specified by `<offutc>` as a positive or negative
+offset from UTC. For example EST (which is 5 hours behind UTC)
+would be expressed in `<tz>` by ``-0500'' while UTC is ``+0000''.
+The local offset does not affect `<time>`; it is used only as an
+advisement to help formatting routines display the timestamp.
++
+If the local offset is not available in the source material, use
+``+0000'', or the most common local offset. For example many
+organizations have a CVS repository which has only ever been accessed
+by users who are located in the same location and timezone. In this
+case a reasonable offset from UTC could be assumed.
++
+Unlike the `rfc2822` format, this format is very strict. Any
+variation in formatting will cause fast-import to reject the value.
+
+`rfc2822`::
+ This is the standard email format as described by RFC 2822.
++
+An example value is ``Tue Feb 6 11:22:18 2007 -0500''. The Git
+parser is accurate, but a little on the lenient side. It is the
+same parser used by linkgit:git-am[1] when applying patches
+received from email.
++
+Some malformed strings may be accepted as valid dates. In some of
+these cases Git will still be able to obtain the correct date from
+the malformed string. There are also some types of malformed
+strings which Git will parse wrong, and yet consider valid.
+Seriously malformed strings will be rejected.
++
+Unlike the `raw` format above, the timezone/UTC offset information
+contained in an RFC 2822 date string is used to adjust the date
+value to UTC prior to storage. Therefore it is important that
+this information be as accurate as possible.
++
+If the source material uses RFC 2822 style dates,
+the frontend should let fast-import handle the parsing and conversion
+(rather than attempting to do it itself) as the Git parser has
+been well tested in the wild.
++
+Frontends should prefer the `raw` format if the source material
+already uses UNIX-epoch format, can be coaxed to give dates in that
+format, or its format is easily convertible to it, as there is no
+ambiguity in parsing.
+
+`now`::
+ Always use the current time and timezone. The literal
+ `now` must always be supplied for `<when>`.
++
+This is a toy format. The current time and timezone of this system
+is always copied into the identity string at the time it is being
+created by fast-import. There is no way to specify a different time or
+timezone.
++
+This particular format is supplied as its short to implement and
+may be useful to a process that wants to create a new commit
+right now, without needing to use a working directory or
+linkgit:git-update-index[1].
++
+If separate `author` and `committer` commands are used in a `commit`
+the timestamps may not match, as the system clock will be polled
+twice (once for each command). The only way to ensure that both
+author and committer identity information has the same timestamp
+is to omit `author` (thus copying from `committer`) or to use a
+date format other than `now`.
+
+Commands
+~~~~~~~~
+fast-import accepts several commands to update the current repository
+and control the current import process. More detailed discussion
+(with examples) of each command follows later.
+
+`commit`::
+ Creates a new branch or updates an existing branch by
+ creating a new commit and updating the branch to point at
+ the newly created commit.
+
+`tag`::
+ Creates an annotated tag object from an existing commit or
+ branch. Lightweight tags are not supported by this command,
+ as they are not recommended for recording meaningful points
+ in time.
+
+`reset`::
+ Reset an existing branch (or a new branch) to a specific
+ revision. This command must be used to change a branch to
+ a specific revision without making a commit on it.
+
+`blob`::
+ Convert raw file data into a blob, for future use in a
+ `commit` command. This command is optional and is not
+ needed to perform an import.
+
+`checkpoint`::
+ Forces fast-import to close the current packfile, generate its
+ unique SHA-1 checksum and index, and start a new packfile.
+ This command is optional and is not needed to perform
+ an import.
+
+`progress`::
+ Causes fast-import to echo the entire line to its own
+ standard output. This command is optional and is not needed
+ to perform an import.
+
+`commit`
+~~~~~~~~
+Create or update a branch with a new commit, recording one logical
+change to the project.
+
+....
+ 'commit' SP <ref> LF
+ mark?
+ ('author' SP <name> SP LT <email> GT SP <when> LF)?
+ 'committer' SP <name> SP LT <email> GT SP <when> LF
+ data
+ ('from' SP <committish> LF)?
+ ('merge' SP <committish> LF)?
+ (filemodify | filedelete | filecopy | filerename | filedeleteall)*
+ LF?
+....
+
+where `<ref>` is the name of the branch to make the commit on.
+Typically branch names are prefixed with `refs/heads/` in
+Git, so importing the CVS branch symbol `RELENG-1_0` would use
+`refs/heads/RELENG-1_0` for the value of `<ref>`. The value of
+`<ref>` must be a valid refname in Git. As `LF` is not valid in
+a Git refname, no quoting or escaping syntax is supported here.
+
+A `mark` command may optionally appear, requesting fast-import to save a
+reference to the newly created commit for future use by the frontend
+(see below for format). It is very common for frontends to mark
+every commit they create, thereby allowing future branch creation
+from any imported commit.
+
+The `data` command following `committer` must supply the commit
+message (see below for `data` command syntax). To import an empty
+commit message use a 0 length data. Commit messages are free-form
+and are not interpreted by Git. Currently they must be encoded in
+UTF-8, as fast-import does not permit other encodings to be specified.
+
+Zero or more `filemodify`, `filedelete`, `filecopy`, `filerename`
+and `filedeleteall` commands
+may be included to update the contents of the branch prior to
+creating the commit. These commands may be supplied in any order.
+However it is recommended that a `filedeleteall` command precede
+all `filemodify`, `filecopy` and `filerename` commands in the same
+commit, as `filedeleteall`
+wipes the branch clean (see below).
+
+The `LF` after the command is optional (it used to be required).
+
+`author`
+^^^^^^^^
+An `author` command may optionally appear, if the author information
+might differ from the committer information. If `author` is omitted
+then fast-import will automatically use the committer's information for
+the author portion of the commit. See below for a description of
+the fields in `author`, as they are identical to `committer`.
+
+`committer`
+^^^^^^^^^^^
+The `committer` command indicates who made this commit, and when
+they made it.
+
+Here `<name>` is the person's display name (for example
+``Com M Itter'') and `<email>` is the person's email address
+(``cm@example.com''). `LT` and `GT` are the literal less-than (\x3c)
+and greater-than (\x3e) symbols. These are required to delimit
+the email address from the other fields in the line. Note that
+`<name>` is free-form and may contain any sequence of bytes, except
+`LT` and `LF`. It is typically UTF-8 encoded.
+
+The time of the change is specified by `<when>` using the date format
+that was selected by the \--date-format=<fmt> command line option.
+See ``Date Formats'' above for the set of supported formats, and
+their syntax.
+
+`from`
+^^^^^^
+The `from` command is used to specify the commit to initialize
+this branch from. This revision will be the first ancestor of the
+new commit.
+
+Omitting the `from` command in the first commit of a new branch
+will cause fast-import to create that commit with no ancestor. This
+tends to be desired only for the initial commit of a project.
+If the frontend creates all files from scratch when making a new
+branch, a `merge` command may be used instead of `from` to start
+the commit with an empty tree.
+Omitting the `from` command on existing branches is usually desired,
+as the current commit on that branch is automatically assumed to
+be the first ancestor of the new commit.
+
+As `LF` is not valid in a Git refname or SHA-1 expression, no
+quoting or escaping syntax is supported within `<committish>`.
+
+Here `<committish>` is any of the following:
+
+* The name of an existing branch already in fast-import's internal branch
+ table. If fast-import doesn't know the name, its treated as a SHA-1
+ expression.
+
+* A mark reference, `:<idnum>`, where `<idnum>` is the mark number.
++
+The reason fast-import uses `:` to denote a mark reference is this character
+is not legal in a Git branch name. The leading `:` makes it easy
+to distinguish between the mark 42 (`:42`) and the branch 42 (`42`
+or `refs/heads/42`), or an abbreviated SHA-1 which happened to
+consist only of base-10 digits.
++
+Marks must be declared (via `mark`) before they can be used.
+
+* A complete 40 byte or abbreviated commit SHA-1 in hex.
+
+* Any valid Git SHA-1 expression that resolves to a commit. See
+ ``SPECIFYING REVISIONS'' in linkgit:git-rev-parse[1] for details.
+
+The special case of restarting an incremental import from the
+current branch value should be written as:
+----
+ from refs/heads/branch^0
+----
+The `{caret}0` suffix is necessary as fast-import does not permit a branch to
+start from itself, and the branch is created in memory before the
+`from` command is even read from the input. Adding `{caret}0` will force
+fast-import to resolve the commit through Git's revision parsing library,
+rather than its internal branch table, thereby loading in the
+existing value of the branch.
+
+`merge`
+^^^^^^^
+Includes one additional ancestor commit. If the `from` command is
+omitted when creating a new branch, the first `merge` commit will be
+the first ancestor of the current commit, and the branch will start
+out with no files. An unlimited number of `merge` commands per
+commit are permitted by fast-import, thereby establishing an n-way merge.
+However Git's other tools never create commits with more than 15
+additional ancestors (forming a 16-way merge). For this reason
+it is suggested that frontends do not use more than 15 `merge`
+commands per commit; 16, if starting a new, empty branch.
+
+Here `<committish>` is any of the commit specification expressions
+also accepted by `from` (see above).
+
+`filemodify`
+^^^^^^^^^^^^
+Included in a `commit` command to add a new file or change the
+content of an existing file. This command has two different means
+of specifying the content of the file.
+
+External data format::
+ The data content for the file was already supplied by a prior
+ `blob` command. The frontend just needs to connect it.
++
+....
+ 'M' SP <mode> SP <dataref> SP <path> LF
+....
++
+Here `<dataref>` can be either a mark reference (`:<idnum>`)
+set by a prior `blob` command, or a full 40-byte SHA-1 of an
+existing Git blob object.
+
+Inline data format::
+ The data content for the file has not been supplied yet.
+ The frontend wants to supply it as part of this modify
+ command.
++
+....
+ 'M' SP <mode> SP 'inline' SP <path> LF
+ data
+....
++
+See below for a detailed description of the `data` command.
+
+In both formats `<mode>` is the type of file entry, specified
+in octal. Git only supports the following modes:
+
+* `100644` or `644`: A normal (not-executable) file. The majority
+ of files in most projects use this mode. If in doubt, this is
+ what you want.
+* `100755` or `755`: A normal, but executable, file.
+* `120000`: A symlink, the content of the file will be the link target.
+
+In both formats `<path>` is the complete path of the file to be added
+(if not already existing) or modified (if already existing).
+
+A `<path>` string must use UNIX-style directory separators (forward
+slash `/`), may contain any byte other than `LF`, and must not
+start with double quote (`"`).
+
+If an `LF` or double quote must be encoded into `<path>` shell-style
+quoting should be used, e.g. `"path/with\n and \" in it"`.
+
+The value of `<path>` must be in canonical form. That is it must not:
+
+* contain an empty directory component (e.g. `foo//bar` is invalid),
+* end with a directory separator (e.g. `foo/` is invalid),
+* start with a directory separator (e.g. `/foo` is invalid),
+* contain the special component `.` or `..` (e.g. `foo/./bar` and
+ `foo/../bar` are invalid).
+
+It is recommended that `<path>` always be encoded using UTF-8.
+
+`filedelete`
+^^^^^^^^^^^^
+Included in a `commit` command to remove a file or recursively
+delete an entire directory from the branch. If the file or directory
+removal makes its parent directory empty, the parent directory will
+be automatically removed too. This cascades up the tree until the
+first non-empty directory or the root is reached.
+
+....
+ 'D' SP <path> LF
+....
+
+here `<path>` is the complete path of the file or subdirectory to
+be removed from the branch.
+See `filemodify` above for a detailed description of `<path>`.
+
+`filecopy`
+^^^^^^^^^^^^
+Recursively copies an existing file or subdirectory to a different
+location within the branch. The existing file or directory must
+exist. If the destination exists it will be completely replaced
+by the content copied from the source.
+
+....
+ 'C' SP <path> SP <path> LF
+....
+
+here the first `<path>` is the source location and the second
+`<path>` is the destination. See `filemodify` above for a detailed
+description of what `<path>` may look like. To use a source path
+that contains SP the path must be quoted.
+
+A `filecopy` command takes effect immediately. Once the source
+location has been copied to the destination any future commands
+applied to the source location will not impact the destination of
+the copy.
+
+`filerename`
+^^^^^^^^^^^^
+Renames an existing file or subdirectory to a different location
+within the branch. The existing file or directory must exist. If
+the destination exists it will be replaced by the source directory.
+
+....
+ 'R' SP <path> SP <path> LF
+....
+
+here the first `<path>` is the source location and the second
+`<path>` is the destination. See `filemodify` above for a detailed
+description of what `<path>` may look like. To use a source path
+that contains SP the path must be quoted.
+
+A `filerename` command takes effect immediately. Once the source
+location has been renamed to the destination any future commands
+applied to the source location will create new files there and not
+impact the destination of the rename.
+
+Note that a `filerename` is the same as a `filecopy` followed by a
+`filedelete` of the source location. There is a slight performance
+advantage to using `filerename`, but the advantage is so small
+that it is never worth trying to convert a delete/add pair in
+source material into a rename for fast-import. This `filerename`
+command is provided just to simplify frontends that already have
+rename information and don't want bother with decomposing it into a
+`filecopy` followed by a `filedelete`.
+
+`filedeleteall`
+^^^^^^^^^^^^^^^
+Included in a `commit` command to remove all files (and also all
+directories) from the branch. This command resets the internal
+branch structure to have no files in it, allowing the frontend
+to subsequently add all interesting files from scratch.
+
+....
+ 'deleteall' LF
+....
+
+This command is extremely useful if the frontend does not know
+(or does not care to know) what files are currently on the branch,
+and therefore cannot generate the proper `filedelete` commands to
+update the content.
+
+Issuing a `filedeleteall` followed by the needed `filemodify`
+commands to set the correct content will produce the same results
+as sending only the needed `filemodify` and `filedelete` commands.
+The `filedeleteall` approach may however require fast-import to use slightly
+more memory per active branch (less than 1 MiB for even most large
+projects); so frontends that can easily obtain only the affected
+paths for a commit are encouraged to do so.
+
+`mark`
+~~~~~~
+Arranges for fast-import to save a reference to the current object, allowing
+the frontend to recall this object at a future point in time, without
+knowing its SHA-1. Here the current object is the object creation
+command the `mark` command appears within. This can be `commit`,
+`tag`, and `blob`, but `commit` is the most common usage.
+
+....
+ 'mark' SP ':' <idnum> LF
+....
+
+where `<idnum>` is the number assigned by the frontend to this mark.
+The value of `<idnum>` is expressed as an ASCII decimal integer.
+The value 0 is reserved and cannot be used as
+a mark. Only values greater than or equal to 1 may be used as marks.
+
+New marks are created automatically. Existing marks can be moved
+to another object simply by reusing the same `<idnum>` in another
+`mark` command.
+
+`tag`
+~~~~~
+Creates an annotated tag referring to a specific commit. To create
+lightweight (non-annotated) tags see the `reset` command below.
+
+....
+ 'tag' SP <name> LF
+ 'from' SP <committish> LF
+ 'tagger' SP <name> SP LT <email> GT SP <when> LF
+ data
+....
+
+where `<name>` is the name of the tag to create.
+
+Tag names are automatically prefixed with `refs/tags/` when stored
+in Git, so importing the CVS branch symbol `RELENG-1_0-FINAL` would
+use just `RELENG-1_0-FINAL` for `<name>`, and fast-import will write the
+corresponding ref as `refs/tags/RELENG-1_0-FINAL`.
+
+The value of `<name>` must be a valid refname in Git and therefore
+may contain forward slashes. As `LF` is not valid in a Git refname,
+no quoting or escaping syntax is supported here.
+
+The `from` command is the same as in the `commit` command; see
+above for details.
+
+The `tagger` command uses the same format as `committer` within
+`commit`; again see above for details.
+
+The `data` command following `tagger` must supply the annotated tag
+message (see below for `data` command syntax). To import an empty
+tag message use a 0 length data. Tag messages are free-form and are
+not interpreted by Git. Currently they must be encoded in UTF-8,
+as fast-import does not permit other encodings to be specified.
+
+Signing annotated tags during import from within fast-import is not
+supported. Trying to include your own PGP/GPG signature is not
+recommended, as the frontend does not (easily) have access to the
+complete set of bytes which normally goes into such a signature.
+If signing is required, create lightweight tags from within fast-import with
+`reset`, then create the annotated versions of those tags offline
+with the standard linkgit:git-tag[1] process.
+
+`reset`
+~~~~~~~
+Creates (or recreates) the named branch, optionally starting from
+a specific revision. The reset command allows a frontend to issue
+a new `from` command for an existing branch, or to create a new
+branch from an existing commit without creating a new commit.
+
+....
+ 'reset' SP <ref> LF
+ ('from' SP <committish> LF)?
+ LF?
+....
+
+For a detailed description of `<ref>` and `<committish>` see above
+under `commit` and `from`.
+
+The `LF` after the command is optional (it used to be required).
+
+The `reset` command can also be used to create lightweight
+(non-annotated) tags. For example:
+
+====
+ reset refs/tags/938
+ from :938
+====
+
+would create the lightweight tag `refs/tags/938` referring to
+whatever commit mark `:938` references.
+
+`blob`
+~~~~~~
+Requests writing one file revision to the packfile. The revision
+is not connected to any commit; this connection must be formed in
+a subsequent `commit` command by referencing the blob through an
+assigned mark.
+
+....
+ 'blob' LF
+ mark?
+ data
+....
+
+The mark command is optional here as some frontends have chosen
+to generate the Git SHA-1 for the blob on their own, and feed that
+directly to `commit`. This is typically more work than its worth
+however, as marks are inexpensive to store and easy to use.
+
+`data`
+~~~~~~
+Supplies raw data (for use as blob/file content, commit messages, or
+annotated tag messages) to fast-import. Data can be supplied using an exact
+byte count or delimited with a terminating line. Real frontends
+intended for production-quality conversions should always use the
+exact byte count format, as it is more robust and performs better.
+The delimited format is intended primarily for testing fast-import.
+
+Comment lines appearing within the `<raw>` part of `data` commands
+are always taken to be part of the body of the data and are therefore
+never ignored by fast-import. This makes it safe to import any
+file/message content whose lines might start with `#`.
+
+Exact byte count format::
+ The frontend must specify the number of bytes of data.
++
+....
+ 'data' SP <count> LF
+ <raw> LF?
+....
++
+where `<count>` is the exact number of bytes appearing within
+`<raw>`. The value of `<count>` is expressed as an ASCII decimal
+integer. The `LF` on either side of `<raw>` is not
+included in `<count>` and will not be included in the imported data.
++
+The `LF` after `<raw>` is optional (it used to be required) but
+recommended. Always including it makes debugging a fast-import
+stream easier as the next command always starts in column 0
+of the next line, even if `<raw>` did not end with an `LF`.
+
+Delimited format::
+ A delimiter string is used to mark the end of the data.
+ fast-import will compute the length by searching for the delimiter.
+ This format is primarily useful for testing and is not
+ recommended for real data.
++
+....
+ 'data' SP '<<' <delim> LF
+ <raw> LF
+ <delim> LF
+ LF?
+....
++
+where `<delim>` is the chosen delimiter string. The string `<delim>`
+must not appear on a line by itself within `<raw>`, as otherwise
+fast-import will think the data ends earlier than it really does. The `LF`
+immediately trailing `<raw>` is part of `<raw>`. This is one of
+the limitations of the delimited format, it is impossible to supply
+a data chunk which does not have an LF as its last byte.
++
+The `LF` after `<delim> LF` is optional (it used to be required).
+
+`checkpoint`
+~~~~~~~~~~~~
+Forces fast-import to close the current packfile, start a new one, and to
+save out all current branch refs, tags and marks.
+
+....
+ 'checkpoint' LF
+ LF?
+....
+
+Note that fast-import automatically switches packfiles when the current
+packfile reaches \--max-pack-size, or 4 GiB, whichever limit is
+smaller. During an automatic packfile switch fast-import does not update
+the branch refs, tags or marks.
+
+As a `checkpoint` can require a significant amount of CPU time and
+disk IO (to compute the overall pack SHA-1 checksum, generate the
+corresponding index file, and update the refs) it can easily take
+several minutes for a single `checkpoint` command to complete.
+
+Frontends may choose to issue checkpoints during extremely large
+and long running imports, or when they need to allow another Git
+process access to a branch. However given that a 30 GiB Subversion
+repository can be loaded into Git through fast-import in about 3 hours,
+explicit checkpointing may not be necessary.
+
+The `LF` after the command is optional (it used to be required).
+
+`progress`
+~~~~~~~~~~
+Causes fast-import to print the entire `progress` line unmodified to
+its standard output channel (file descriptor 1) when the command is
+processed from the input stream. The command otherwise has no impact
+on the current import, or on any of fast-import's internal state.
+
+....
+ 'progress' SP <any> LF
+ LF?
+....
+
+The `<any>` part of the command may contain any sequence of bytes
+that does not contain `LF`. The `LF` after the command is optional.
+Callers may wish to process the output through a tool such as sed to
+remove the leading part of the line, for example:
+
+====
+ frontend | git-fast-import | sed 's/^progress //'
+====
+
+Placing a `progress` command immediately after a `checkpoint` will
+inform the reader when the `checkpoint` has been completed and it
+can safely access the refs that fast-import updated.
+
+Crash Reports
+-------------
+If fast-import is supplied invalid input it will terminate with a
+non-zero exit status and create a crash report in the top level of
+the Git repository it was importing into. Crash reports contain
+a snapshot of the internal fast-import state as well as the most
+recent commands that lead up to the crash.
+
+All recent commands (including stream comments, file changes and
+progress commands) are shown in the command history within the crash
+report, but raw file data and commit messages are excluded from the
+crash report. This exclusion saves space within the report file
+and reduces the amount of buffering that fast-import must perform
+during execution.
+
+After writing a crash report fast-import will close the current
+packfile and export the marks table. This allows the frontend
+developer to inspect the repository state and resume the import from
+the point where it crashed. The modified branches and tags are not
+updated during a crash, as the import did not complete successfully.
+Branch and tag information can be found in the crash report and
+must be applied manually if the update is needed.
+
+An example crash:
+
+====
+ $ cat >in <<END_OF_INPUT
+ # my very first test commit
+ commit refs/heads/master
+ committer Shawn O. Pearce <spearce> 19283 -0400
+ # who is that guy anyway?
+ data <<EOF
+ this is my commit
+ EOF
+ M 644 inline .gitignore
+ data <<EOF
+ .gitignore
+ EOF
+ M 777 inline bob
+ END_OF_INPUT
+
+ $ git-fast-import <in
+ fatal: Corrupt mode: M 777 inline bob
+ fast-import: dumping crash report to .git/fast_import_crash_8434
+
+ $ cat .git/fast_import_crash_8434
+ fast-import crash report:
+ fast-import process: 8434
+ parent process : 1391
+ at Sat Sep 1 00:58:12 2007
+
+ fatal: Corrupt mode: M 777 inline bob
+
+ Most Recent Commands Before Crash
+ ---------------------------------
+ # my very first test commit
+ commit refs/heads/master
+ committer Shawn O. Pearce <spearce> 19283 -0400
+ # who is that guy anyway?
+ data <<EOF
+ M 644 inline .gitignore
+ data <<EOF
+ * M 777 inline bob
+
+ Active Branch LRU
+ -----------------
+ active_branches = 1 cur, 5 max
+
+ pos clock name
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 1) 0 refs/heads/master
+
+ Inactive Branches
+ -----------------
+ refs/heads/master:
+ status : active loaded dirty
+ tip commit : 0000000000000000000000000000000000000000
+ old tree : 0000000000000000000000000000000000000000
+ cur tree : 0000000000000000000000000000000000000000
+ commit clock: 0
+ last pack :
+
+
+ -------------------
+ END OF CRASH REPORT
+====
+
+Tips and Tricks
+---------------
+The following tips and tricks have been collected from various
+users of fast-import, and are offered here as suggestions.
+
+Use One Mark Per Commit
+~~~~~~~~~~~~~~~~~~~~~~~
+When doing a repository conversion, use a unique mark per commit
+(`mark :<n>`) and supply the \--export-marks option on the command
+line. fast-import will dump a file which lists every mark and the Git
+object SHA-1 that corresponds to it. If the frontend can tie
+the marks back to the source repository, it is easy to verify the
+accuracy and completeness of the import by comparing each Git
+commit to the corresponding source revision.
+
+Coming from a system such as Perforce or Subversion this should be
+quite simple, as the fast-import mark can also be the Perforce changeset
+number or the Subversion revision number.
+
+Freely Skip Around Branches
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Don't bother trying to optimize the frontend to stick to one branch
+at a time during an import. Although doing so might be slightly
+faster for fast-import, it tends to increase the complexity of the frontend
+code considerably.
+
+The branch LRU builtin to fast-import tends to behave very well, and the
+cost of activating an inactive branch is so low that bouncing around
+between branches has virtually no impact on import performance.
+
+Handling Renames
+~~~~~~~~~~~~~~~~
+When importing a renamed file or directory, simply delete the old
+name(s) and modify the new name(s) during the corresponding commit.
+Git performs rename detection after-the-fact, rather than explicitly
+during a commit.
+
+Use Tag Fixup Branches
+~~~~~~~~~~~~~~~~~~~~~~
+Some other SCM systems let the user create a tag from multiple
+files which are not from the same commit/changeset. Or to create
+tags which are a subset of the files available in the repository.
+
+Importing these tags as-is in Git is impossible without making at
+least one commit which ``fixes up'' the files to match the content
+of the tag. Use fast-import's `reset` command to reset a dummy branch
+outside of your normal branch space to the base commit for the tag,
+then commit one or more file fixup commits, and finally tag the
+dummy branch.
+
+For example since all normal branches are stored under `refs/heads/`
+name the tag fixup branch `TAG_FIXUP`. This way it is impossible for
+the fixup branch used by the importer to have namespace conflicts
+with real branches imported from the source (the name `TAG_FIXUP`
+is not `refs/heads/TAG_FIXUP`).
+
+When committing fixups, consider using `merge` to connect the
+commit(s) which are supplying file revisions to the fixup branch.
+Doing so will allow tools such as linkgit:git-blame[1] to track
+through the real commit history and properly annotate the source
+files.
+
+After fast-import terminates the frontend will need to do `rm .git/TAG_FIXUP`
+to remove the dummy branch.
+
+Import Now, Repack Later
+~~~~~~~~~~~~~~~~~~~~~~~~
+As soon as fast-import completes the Git repository is completely valid
+and ready for use. Typically this takes only a very short time,
+even for considerably large projects (100,000+ commits).
+
+However repacking the repository is necessary to improve data
+locality and access performance. It can also take hours on extremely
+large projects (especially if -f and a large \--window parameter is
+used). Since repacking is safe to run alongside readers and writers,
+run the repack in the background and let it finish when it finishes.
+There is no reason to wait to explore your new Git project!
+
+If you choose to wait for the repack, don't try to run benchmarks
+or performance tests until repacking is completed. fast-import outputs
+suboptimal packfiles that are simply never seen in real use
+situations.
+
+Repacking Historical Data
+~~~~~~~~~~~~~~~~~~~~~~~~~
+If you are repacking very old imported data (e.g. older than the
+last year), consider expending some extra CPU time and supplying
+\--window=50 (or higher) when you run linkgit:git-repack[1].
+This will take longer, but will also produce a smaller packfile.
+You only need to expend the effort once, and everyone using your
+project will benefit from the smaller repository.
+
+Include Some Progress Messages
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Every once in a while have your frontend emit a `progress` message
+to fast-import. The contents of the messages are entirely free-form,
+so one suggestion would be to output the current month and year
+each time the current commit date moves into the next month.
+Your users will feel better knowing how much of the data stream
+has been processed.
+
+
+Packfile Optimization
+---------------------
+When packing a blob fast-import always attempts to deltify against the last
+blob written. Unless specifically arranged for by the frontend,
+this will probably not be a prior version of the same file, so the
+generated delta will not be the smallest possible. The resulting
+packfile will be compressed, but will not be optimal.
+
+Frontends which have efficient access to all revisions of a
+single file (for example reading an RCS/CVS ,v file) can choose
+to supply all revisions of that file as a sequence of consecutive
+`blob` commands. This allows fast-import to deltify the different file
+revisions against each other, saving space in the final packfile.
+Marks can be used to later identify individual file revisions during
+a sequence of `commit` commands.
+
+The packfile(s) created by fast-import do not encourage good disk access
+patterns. This is caused by fast-import writing the data in the order
+it is received on standard input, while Git typically organizes
+data within packfiles to make the most recent (current tip) data
+appear before historical data. Git also clusters commits together,
+speeding up revision traversal through better cache locality.
+
+For this reason it is strongly recommended that users repack the
+repository with `git repack -a -d` after fast-import completes, allowing
+Git to reorganize the packfiles for faster data access. If blob
+deltas are suboptimal (see above) then also adding the `-f` option
+to force recomputation of all deltas can significantly reduce the
+final packfile size (30-50% smaller can be quite typical).
+
+
+Memory Utilization
+------------------
+There are a number of factors which affect how much memory fast-import
+requires to perform an import. Like critical sections of core
+Git, fast-import uses its own memory allocators to amortize any overheads
+associated with malloc. In practice fast-import tends to amortize any
+malloc overheads to 0, due to its use of large block allocations.
+
+per object
+~~~~~~~~~~
+fast-import maintains an in-memory structure for every object written in
+this execution. On a 32 bit system the structure is 32 bytes,
+on a 64 bit system the structure is 40 bytes (due to the larger
+pointer sizes). Objects in the table are not deallocated until
+fast-import terminates. Importing 2 million objects on a 32 bit system
+will require approximately 64 MiB of memory.
+
+The object table is actually a hashtable keyed on the object name
+(the unique SHA-1). This storage configuration allows fast-import to reuse
+an existing or already written object and avoid writing duplicates
+to the output packfile. Duplicate blobs are surprisingly common
+in an import, typically due to branch merges in the source.
+
+per mark
+~~~~~~~~
+Marks are stored in a sparse array, using 1 pointer (4 bytes or 8
+bytes, depending on pointer size) per mark. Although the array
+is sparse, frontends are still strongly encouraged to use marks
+between 1 and n, where n is the total number of marks required for
+this import.
+
+per branch
+~~~~~~~~~~
+Branches are classified as active and inactive. The memory usage
+of the two classes is significantly different.
+
+Inactive branches are stored in a structure which uses 96 or 120
+bytes (32 bit or 64 bit systems, respectively), plus the length of
+the branch name (typically under 200 bytes), per branch. fast-import will
+easily handle as many as 10,000 inactive branches in under 2 MiB
+of memory.
+
+Active branches have the same overhead as inactive branches, but
+also contain copies of every tree that has been recently modified on
+that branch. If subtree `include` has not been modified since the
+branch became active, its contents will not be loaded into memory,
+but if subtree `src` has been modified by a commit since the branch
+became active, then its contents will be loaded in memory.
+
+As active branches store metadata about the files contained on that
+branch, their in-memory storage size can grow to a considerable size
+(see below).
+
+fast-import automatically moves active branches to inactive status based on
+a simple least-recently-used algorithm. The LRU chain is updated on
+each `commit` command. The maximum number of active branches can be
+increased or decreased on the command line with \--active-branches=.
+
+per active tree
+~~~~~~~~~~~~~~~
+Trees (aka directories) use just 12 bytes of memory on top of the
+memory required for their entries (see ``per active file'' below).
+The cost of a tree is virtually 0, as its overhead amortizes out
+over the individual file entries.
+
+per active file entry
+~~~~~~~~~~~~~~~~~~~~~
+Files (and pointers to subtrees) within active trees require 52 or 64
+bytes (32/64 bit platforms) per entry. To conserve space, file and
+tree names are pooled in a common string table, allowing the filename
+``Makefile'' to use just 16 bytes (after including the string header
+overhead) no matter how many times it occurs within the project.
+
+The active branch LRU, when coupled with the filename string pool
+and lazy loading of subtrees, allows fast-import to efficiently import
+projects with 2,000+ branches and 45,114+ files in a very limited
+memory footprint (less than 2.7 MiB per active branch).
+
+
+Author
+------
+Written by Shawn O. Pearce <spearce@spearce.org>.
+
+Documentation
+--------------
+Documentation by Shawn O. Pearce <spearce@spearce.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
new file mode 100644
index 0000000000..282fcaf17f
--- /dev/null
+++ b/Documentation/git-fetch-pack.txt
@@ -0,0 +1,104 @@
+git-fetch-pack(1)
+=================
+
+NAME
+----
+git-fetch-pack - Receive missing objects from another repository
+
+
+SYNOPSIS
+--------
+'git-fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] [-v] [<host>:]<directory> [<refs>...]
+
+DESCRIPTION
+-----------
+Usually you would want to use linkgit:git-fetch[1] which is a
+higher level wrapper of this command instead.
+
+Invokes 'git-upload-pack' on a potentially remote repository,
+and asks it to send objects missing from this repository, to
+update the named heads. The list of commits available locally
+is found out by scanning local $GIT_DIR/refs/ and sent to
+'git-upload-pack' running on the other end.
+
+This command degenerates to download everything to complete the
+asked refs from the remote side when the local side does not
+have a common ancestor commit.
+
+
+OPTIONS
+-------
+--all::
+ Fetch all remote refs.
+
+-q::
+--quiet::
+ Pass '-q' flag to 'git-unpack-objects'; this makes the
+ cloning process less verbose.
+
+-k::
+--keep::
+ Do not invoke 'git-unpack-objects' on received data, but
+ create a single packfile out of it instead, and store it
+ in the object database. If provided twice then the pack is
+ locked against repacking.
+
+--thin::
+ Spend extra cycles to minimize the number of objects to be sent.
+ Use it on slower connection.
+
+--include-tag::
+ If the remote side supports it, annotated tags objects will
+ be downloaded on the same connection as the other objects if
+ the object the tag references is downloaded. The caller must
+ otherwise determine the tags this option made available.
+
+--upload-pack=<git-upload-pack>::
+ Use this to specify the path to 'git-upload-pack' on the
+ remote side, if is not found on your $PATH.
+ Installations of sshd ignores 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).
+
+--exec=<git-upload-pack>::
+ Same as \--upload-pack=<git-upload-pack>.
+
+--depth=<n>::
+ Limit fetching to ancestor-chains not longer than n.
+
+--no-progress::
+ Do not show the progress.
+
+-v::
+ Run verbosely.
+
+<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.
+
+<refs>...::
+ The remote heads to update from. This is relative to
+ $GIT_DIR (e.g. "HEAD", "refs/heads/master"). When
+ unspecified, update from all heads the remote side has.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
new file mode 100644
index 0000000000..489b2b17e6
--- /dev/null
+++ b/Documentation/git-fetch.txt
@@ -0,0 +1,56 @@
+git-fetch(1)
+============
+
+NAME
+----
+git-fetch - Download objects and refs from another repository
+
+
+SYNOPSIS
+--------
+'git-fetch' <options> <repository> <refspec>...
+
+
+DESCRIPTION
+-----------
+Fetches named heads or tags from another repository, along with
+the objects necessary to complete them.
+
+The ref names and their object names of fetched refs are stored
+in `.git/FETCH_HEAD`. This information is left for a later merge
+operation done by "git merge".
+
+When <refspec> stores the fetched result in tracking branches,
+the tags that point at these branches are automatically
+followed. This is done by first fetching from the remote using
+the given <refspec>s, and if the repository has objects that are
+pointed by remote tags that it does not yet have, then fetch
+those missing tags. If the other end has tags that point at
+branches you are not interested in, you will not get them.
+
+
+OPTIONS
+-------
+include::fetch-options.txt[]
+
+include::pull-fetch-param.txt[]
+
+include::urls-remotes.txt[]
+
+SEE ALSO
+--------
+linkgit:git-pull[1]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and
+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 linkgit:git[1] suite
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
new file mode 100644
index 0000000000..ea77f1fce5
--- /dev/null
+++ b/Documentation/git-filter-branch.txt
@@ -0,0 +1,321 @@
+git-filter-branch(1)
+====================
+
+NAME
+----
+git-filter-branch - Rewrite branches
+
+SYNOPSIS
+--------
+[verse]
+'git-filter-branch' [--env-filter <command>] [--tree-filter <command>]
+ [--index-filter <command>] [--parent-filter <command>]
+ [--msg-filter <command>] [--commit-filter <command>]
+ [--tag-name-filter <command>] [--subdirectory-filter <directory>]
+ [--original <namespace>] [-d <directory>] [-f | --force]
+ [<rev-list options>...]
+
+DESCRIPTION
+-----------
+Lets you rewrite git revision history by rewriting the branches mentioned
+in the <rev-list options>, applying custom filters on each revision.
+Those filters can modify each tree (e.g. removing a file or running
+a perl rewrite on all files) or information about each commit.
+Otherwise, all information (including original commit times or merge
+information) will be preserved.
+
+The command will only rewrite the _positive_ refs mentioned in the
+command line (e.g. if you pass 'a..b', only 'b' will be rewritten).
+If you specify no filters, the commits will be recommitted without any
+changes, which would normally have no effect. Nevertheless, this may be
+useful in the future for compensating for some git bugs or such,
+therefore such a usage is permitted.
+
+*WARNING*! The rewritten history will have different object names for all
+the objects and will not converge with the original branch. You will not
+be able to easily push and distribute the rewritten branch on top of the
+original branch. Please do not use this command if you do not know the
+full implications, and avoid using it anyway, if a simple single commit
+would suffice to fix your problem.
+
+Always verify that the rewritten version is correct: The original refs,
+if different from the rewritten ones, will be stored in the namespace
+'refs/original/'.
+
+Note that since this operation is very I/O expensive, it might
+be a good idea to redirect the temporary directory off-disk with the
+'-d' option, e.g. on tmpfs. Reportedly the speedup is very noticeable.
+
+
+Filters
+~~~~~~~
+
+The filters are applied in the order as listed below. The <command>
+argument is always evaluated in the shell context using the 'eval' command
+(with the notable exception of the commit filter, for technical reasons).
+Prior to that, the $GIT_COMMIT environment variable will be set to contain
+the id of the commit being rewritten. Also, GIT_AUTHOR_NAME,
+GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL,
+and GIT_COMMITTER_DATE are set according to the current commit. The values
+of these variables after the filters have run, are used for the new commit.
+If any evaluation of <command> returns a non-zero exit status, the whole
+operation will be aborted.
+
+A 'map' function is available that takes an "original sha1 id" argument
+and outputs a "rewritten sha1 id" if the commit has been already
+rewritten, and "original sha1 id" otherwise; the 'map' function can
+return several ids on separate lines if your commit filter emitted
+multiple commits.
+
+
+OPTIONS
+-------
+
+--env-filter <command>::
+ This filter may be used if you only need to modify the environment
+ in which the commit will be performed. Specifically, you might
+ want to rewrite the author/committer name/email/time environment
+ variables (see linkgit:git-commit[1] for details). Do not forget
+ to re-export the variables.
+
+--tree-filter <command>::
+ This is the filter for rewriting the tree and its contents.
+ The argument is evaluated in shell with the working
+ directory set to the root of the checked out tree. The new tree
+ is then used as-is (new files are auto-added, disappeared files
+ are auto-removed - neither .gitignore files nor any other ignore
+ rules *HAVE ANY EFFECT*!).
+
+--index-filter <command>::
+ This is the filter for rewriting the index. It is similar to the
+ tree filter but does not check out the tree, which makes it much
+ faster. For hairy cases, see linkgit:git-update-index[1].
+
+--parent-filter <command>::
+ This is the filter for rewriting the commit's parent list.
+ It will receive the parent string on stdin and shall output
+ the new parent string on stdout. The parent string is in
+ a format accepted by linkgit:git-commit-tree[1]: empty for
+ the initial commit, "-p parent" for a normal commit and
+ "-p parent1 -p parent2 -p parent3 ..." for a merge commit.
+
+--msg-filter <command>::
+ This is the filter for rewriting the commit messages.
+ The argument is evaluated in the shell with the original
+ commit message on standard input; its standard output is
+ used as the new commit message.
+
+--commit-filter <command>::
+ This is the filter for performing the commit.
+ If this filter is specified, it will be called instead of the
+ linkgit:git-commit-tree[1] command, with arguments of the form
+ "<TREE_ID> [-p <PARENT_COMMIT_ID>]..." and the log message on
+ stdin. The commit id is expected on stdout.
++
+As a special extension, the commit filter may emit multiple
+commit ids; in that case, the rewritten children of the original commit will
+have all of them as parents.
++
+You can use the 'map' convenience function in this filter, and other
+convenience functions, too. For example, calling 'skip_commit "$@"'
+will leave out the current commit (but not its changes! If you want
+that, use linkgit:git-rebase[1] instead).
+
+--tag-name-filter <command>::
+ This is the filter for rewriting tag names. When passed,
+ it will be called for every tag ref that points to a rewritten
+ object (or to a tag object which points to a rewritten object).
+ The original tag name is passed via standard input, and the new
+ tag name is expected on standard output.
++
+The original tags are not deleted, but can be overwritten;
+use "--tag-name-filter cat" to simply update the tags. In this
+case, be very careful and make sure you have the old tags
+backed up in case the conversion has run afoul.
++
+Nearly proper rewriting of tag objects is supported. If the tag has
+a message attached, a new tag object will be created with the same message,
+author, and timestamp. If the tag has a signature attached, the
+signature will be stripped. It is by definition impossible to preserve
+signatures. The reason this is "nearly" proper, is because ideally if
+the tag did not change (points to the same object, has the same name, etc.)
+it should retain any signature. That is not the case, signatures will always
+be removed, buyer beware. There is also no support for changing the
+author or timestamp (or the tag message for that matter). Tags which point
+to other tags will be rewritten to point to the underlying commit.
+
+--subdirectory-filter <directory>::
+ Only look at the history which touches the given subdirectory.
+ The result will contain that directory (and only that) as its
+ project root.
+
+--original <namespace>::
+ Use this option to set the namespace where the original commits
+ will be stored. The default value is 'refs/original'.
+
+-d <directory>::
+ Use this option to set the path to the temporary directory used for
+ rewriting. When applying a tree filter, the command needs to
+ temporarily check out the tree to some directory, which may consume
+ considerable space in case of large projects. By default it
+ does this in the '.git-rewrite/' directory but you can override
+ that choice by this parameter.
+
+-f::
+--force::
+ `git filter-branch` refuses to start with an existing temporary
+ directory or when there are already refs starting with
+ 'refs/original/', unless forced.
+
+<rev-list-options>::
+ When options are given after the new branch name, they will
+ be passed to linkgit:git-rev-list[1]. Only commits in the resulting
+ output will be filtered, although the filtered commits can still
+ reference parents which are outside of that set.
+
+
+Examples
+--------
+
+Suppose you want to remove a file (containing confidential information
+or copyright violation) from all commits:
+
+-------------------------------------------------------
+git filter-branch --tree-filter 'rm filename' HEAD
+-------------------------------------------------------
+
+However, if the file is absent from the tree of some commit,
+a simple `rm filename` will fail for that tree and commit.
+Thus you may instead want to use `rm -f filename` as the script.
+
+A significantly faster version:
+
+--------------------------------------------------------------------------
+git filter-branch --index-filter 'git update-index --remove filename' HEAD
+--------------------------------------------------------------------------
+
+Now, you will get the rewritten history saved in HEAD.
+
+To set a commit (which typically is at the tip of another
+history) to be the parent of the current initial commit, in
+order to paste the other history behind the current history:
+
+-------------------------------------------------------------------
+git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' HEAD
+-------------------------------------------------------------------
+
+(if the parent string is empty - which happens when we are dealing with
+the initial commit - add graftcommit as a parent). Note that this assumes
+history with a single root (that is, no merge without common ancestors
+happened). If this is not the case, use:
+
+--------------------------------------------------------------------------
+git filter-branch --parent-filter \
+ 'test $GIT_COMMIT = <commit-id> && echo "-p <graft-id>" || cat' HEAD
+--------------------------------------------------------------------------
+
+or even simpler:
+
+-----------------------------------------------
+echo "$commit-id $graft-id" >> .git/info/grafts
+git filter-branch $graft-id..HEAD
+-----------------------------------------------
+
+To remove commits authored by "Darl McBribe" from the history:
+
+------------------------------------------------------------------------------
+git filter-branch --commit-filter '
+ if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ];
+ then
+ skip_commit "$@";
+ else
+ git commit-tree "$@";
+ fi' HEAD
+------------------------------------------------------------------------------
+
+The function 'skip_commit' is defined as follows:
+
+--------------------------
+skip_commit()
+{
+ shift;
+ while [ -n "$1" ];
+ do
+ shift;
+ map "$1";
+ shift;
+ done;
+}
+--------------------------
+
+The shift magic first throws away the tree id and then the -p
+parameters. Note that this handles merges properly! In case Darl
+committed a merge between P1 and P2, it will be propagated properly
+and all children of the merge will become merge commits with P1,P2
+as their parents instead of the merge commit.
+
+You can rewrite the commit log messages using `--msg-filter`. For
+example, `git-svn-id` strings in a repository created by `git-svn` can
+be removed this way:
+
+-------------------------------------------------------
+git filter-branch --msg-filter '
+ sed -e "/^git-svn-id:/d"
+'
+-------------------------------------------------------
+
+To restrict rewriting to only part of the history, specify a revision
+range in addition to the new branch name. The new branch name will
+point to the top-most revision that a 'git rev-list' of this range
+will print.
+
+*NOTE* the changes introduced by the commits, and which are not reverted
+by subsequent commits, will still be in the rewritten branch. If you want
+to throw out _changes_ together with the commits, you should use the
+interactive mode of linkgit:git-rebase[1].
+
+
+Consider this history:
+
+------------------
+ D--E--F--G--H
+ / /
+A--B-----C
+------------------
+
+To rewrite only commits D,E,F,G,H, but leave A, B and C alone, use:
+
+--------------------------------
+git filter-branch ... C..H
+--------------------------------
+
+To rewrite commits E,F,G,H, use one of these:
+
+----------------------------------------
+git filter-branch ... C..H --not D
+git filter-branch ... D..H --not C
+----------------------------------------
+
+To move the whole tree into a subdirectory, or remove it from there:
+
+---------------------------------------------------------------
+git filter-branch --index-filter \
+ 'git ls-files -s | sed "s-\t-&newsubdir/-" |
+ GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
+ git update-index --index-info &&
+ mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD
+---------------------------------------------------------------
+
+
+Author
+------
+Written by Petr "Pasky" Baudis <pasky@suse.cz>,
+and the git list <git@vger.kernel.org>
+
+Documentation
+--------------
+Documentation by Petr Baudis and the git list.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-fmt-merge-msg.txt b/Documentation/git-fmt-merge-msg.txt
new file mode 100644
index 0000000000..2a7cfb980b
--- /dev/null
+++ b/Documentation/git-fmt-merge-msg.txt
@@ -0,0 +1,72 @@
+git-fmt-merge-msg(1)
+====================
+
+NAME
+----
+git-fmt-merge-msg - Produce a merge commit message
+
+
+SYNOPSIS
+--------
+[verse]
+git-fmt-merge-msg [--log | --no-log] <$GIT_DIR/FETCH_HEAD
+git-fmt-merge-msg [--log | --no-log] -F <file>
+
+DESCRIPTION
+-----------
+Takes the list of merged objects on stdin and produces a suitable
+commit message to be used for the merge commit, usually to be
+passed as the '<merge-message>' argument of `git-merge`.
+
+This script is intended mostly for internal use by scripts
+automatically invoking `git-merge`.
+
+OPTIONS
+-------
+
+--log::
+ In addition to branch names, populate the log message with
+ one-line descriptions from the actual commits that are being
+ merged.
+
+--no-log::
+ Do not list one-line descriptions from the actual commits being
+ merged.
+
+--summary::
+--no-summary::
+ Synonyms to --log and --no-log; these are deprecated and will be
+ removed in the future.
+
+-F <file>::
+--file <file>::
+ Take the list of merged objects from <file> instead of
+ stdin.
+
+CONFIGURATION
+-------------
+
+merge.log::
+ Whether to include summaries of merged commits in newly
+ merge commit messages. False by default.
+
+merge.summary::
+ Synonym to `merge.log`; this is deprecated and will be removed in
+ the future.
+
+SEE ALSO
+--------
+linkgit:git-merge[1]
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
new file mode 100644
index 0000000000..b347bfbb14
--- /dev/null
+++ b/Documentation/git-for-each-ref.txt
@@ -0,0 +1,197 @@
+git-for-each-ref(1)
+===================
+
+NAME
+----
+git-for-each-ref - Output information on each ref
+
+SYNOPSIS
+--------
+[verse]
+'git-for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl]
+ [--sort=<key>]\* [--format=<format>] [<pattern>...]
+
+DESCRIPTION
+-----------
+
+Iterate over all refs that match `<pattern>` and show them
+according to the given `<format>`, after sorting them according
+to the given set of `<key>`. If `<max>` is given, stop after
+showing that many refs. The interpolated values in `<format>`
+can optionally be quoted as string literals in the specified
+host language allowing their direct evaluation in that language.
+
+OPTIONS
+-------
+<count>::
+ By default the command shows all refs that match
+ `<pattern>`. This option makes it stop after showing
+ that many refs.
+
+<key>::
+ A field name to sort on. Prefix `-` to sort in
+ descending order of the value. When unspecified,
+ `refname` is used. You may use the --sort=<key> option
+ multiple times, in which case the last key becomes the primary
+ key.
+
+<format>::
+ A string that interpolates `%(fieldname)` from the
+ object pointed at by a ref being shown. If `fieldname`
+ is prefixed with an asterisk (`*`) and the ref points
+ at a tag object, the value for the field in the object
+ tag refers is used. When unspecified, defaults to
+ `%(objectname) SPC %(objecttype) TAB %(refname)`.
+ It also interpolates `%%` to `%`, and `%xx` where `xx`
+ are hex digits interpolates to character with hex code
+ `xx`; for example `%00` interpolates to `\0` (NUL),
+ `%09` to `\t` (TAB) and `%0a` to `\n` (LF).
+
+<pattern>::
+ If one or more patterns are given, only refs are shown that
+ match againt at least one pattern, either using fnmatch(3) or
+ literally, in the latter case matching completely or from the
+ beginning up to a slash.
+
+--shell::
+--perl::
+--python::
+--tcl::
+ If given, strings that substitute `%(fieldname)`
+ placeholders are quoted as string literals suitable for
+ the specified host language. This is meant to produce
+ a scriptlet that can directly be `eval`ed.
+
+
+FIELD NAMES
+-----------
+
+Various values from structured fields in referenced objects can
+be used to interpolate into the resulting output, or as sort
+keys.
+
+For all objects, the following names can be used:
+
+refname::
+ The name of the ref (the part after $GIT_DIR/).
+
+objecttype::
+ The type of the object (`blob`, `tree`, `commit`, `tag`).
+
+objectsize::
+ The size of the object (the same as `git-cat-file -s` reports).
+
+objectname::
+ The object name (aka SHA-1).
+
+In addition to the above, for commit and tag objects, the header
+field names (`tree`, `parent`, `object`, `type`, and `tag`) can
+be used to specify the value in the header field.
+
+Fields that have name-email-date tuple as its value (`author`,
+`committer`, and `tagger`) can be suffixed with `name`, `email`,
+and `date` to extract the named component.
+
+The first line of the message in a commit and tag object is
+`subject`, the remaining lines are `body`. The whole message
+is `contents`.
+
+For sorting purposes, fields with numeric values sort in numeric
+order (`objectsize`, `authordate`, `committerdate`, `taggerdate`).
+All other fields are used to sort in their byte-value order.
+
+In any case, a field name that refers to a field inapplicable to
+the object referred by the ref does not cause an error. It
+returns an empty string instead.
+
+As a special case for the date-type fields, you may specify a format for
+the date by adding one of `:default`, `:relative`, `:short`, `:local`,
+`:iso8601` or `:rfc2822` to the end of the fieldname; e.g.
+`%(taggerdate:relative)`.
+
+
+EXAMPLES
+--------
+
+An example directly producing formatted text. Show the most recent
+3 tagged commits::
+
+------------
+#!/bin/sh
+
+git-for-each-ref --count=3 --sort='-*authordate' \
+--format='From: %(*authorname) %(*authoremail)
+Subject: %(*subject)
+Date: %(*authordate)
+Ref: %(*refname)
+
+%(*body)
+' 'refs/tags'
+------------
+
+
+A simple example showing the use of shell eval on the output,
+demonstrating the use of --shell. List the prefixes of all heads::
+------------
+#!/bin/sh
+
+git-for-each-ref --shell --format="ref=%(refname)" refs/heads | \
+while read entry
+do
+ eval "$entry"
+ echo `dirname $ref`
+done
+------------
+
+
+A bit more elaborate report on tags, demonstrating that the format
+may be an entire script::
+------------
+#!/bin/sh
+
+fmt='
+ r=%(refname)
+ t=%(*objecttype)
+ T=${r#refs/tags/}
+
+ o=%(*objectname)
+ n=%(*authorname)
+ e=%(*authoremail)
+ s=%(*subject)
+ d=%(*authordate)
+ b=%(*body)
+
+ kind=Tag
+ if test "z$t" = z
+ then
+ # could be a lightweight tag
+ t=%(objecttype)
+ kind="Lightweight tag"
+ o=%(objectname)
+ n=%(authorname)
+ e=%(authoremail)
+ s=%(subject)
+ d=%(authordate)
+ b=%(body)
+ fi
+ echo "$kind $T points at a $t object $o"
+ if test "z$t" = zcommit
+ then
+ echo "The commit was authored by $n $e
+at $d, and titled
+
+ $s
+
+Its message reads as:
+"
+ echo "$b" | sed -e "s/^/ /"
+ echo
+ fi
+'
+
+eval=`git-for-each-ref --shell --format="$fmt" \
+ --sort='*objecttype' \
+ --sort=-taggerdate \
+ refs/tags`
+eval "$eval"
+------------
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
new file mode 100644
index 0000000000..4dafa39a92
--- /dev/null
+++ b/Documentation/git-format-patch.txt
@@ -0,0 +1,246 @@
+git-format-patch(1)
+===================
+
+NAME
+----
+git-format-patch - Prepare patches for e-mail submission
+
+
+SYNOPSIS
+--------
+[verse]
+'git-format-patch' [-k] [-o <dir> | --stdout] [--thread]
+ [--attach[=<boundary>] | --inline[=<boundary>]]
+ [-s | --signoff] [<common diff options>]
+ [-n | --numbered | -N | --no-numbered]
+ [--start-number <n>] [--numbered-files]
+ [--in-reply-to=Message-Id] [--suffix=.<sfx>]
+ [--ignore-if-in-upstream]
+ [--subject-prefix=Subject-Prefix]
+ [--cc=<email>]
+ [--cover-letter]
+ [ <since> | <revision range> ]
+
+DESCRIPTION
+-----------
+
+Prepare each commit with its patch in
+one file per commit, formatted to resemble UNIX mailbox format.
+The output of this command is convenient for e-mail submission or
+for use with linkgit:git-am[1].
+
+There are two ways to specify which commits to operate on.
+
+1. A single commit, <since>, specifies that the commits leading
+ to the tip of the current branch that are not in the history
+ that leads to the <since> to be output.
+
+2. Generic <revision range> expression (see "SPECIFYING
+ REVISIONS" section in linkgit:git-rev-parse[1]) means the
+ commits in the specified range.
+
+A single commit, when interpreted as a <revision range>
+expression, means "everything that leads to that commit", but
+if you write 'git format-patch <commit>', the previous rule
+applies to that command line and you do not get "everything
+since the beginning of the time". If you want to format
+everything since project inception to one commit, say "git
+format-patch \--root <commit>" to make it clear that it is the
+latter case.
+
+By default, each output file is numbered sequentially from 1, and uses the
+first line of the commit message (massaged for pathname safety) as
+the filename. With the --numbered-files option, the output file names
+will only be numbers, without the first line of the commit appended.
+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
+-------
+:git-format-patch: 1
+include::diff-options.txt[]
+
+-<n>::
+ Limits the number of patches to prepare.
+
+-o <dir>::
+--output-directory <dir>::
+ Use <dir> to store the resulting files, instead of the
+ current working directory.
+
+-n::
+--numbered::
+ Name output in '[PATCH n/m]' format.
+
+-N::
+--no-numbered::
+ Name output in '[PATCH]' format.
+
+--start-number <n>::
+ Start numbering the patches at <n> instead of 1.
+
+--numbered-files::
+ Output file names will be a simple number sequence
+ without the default first line of the commit appended.
+ Mutually exclusive with the --stdout option.
+
+-k::
+--keep-subject::
+ Do not strip/add '[PATCH]' from the first line of the
+ commit log message.
+
+-s::
+--signoff::
+ Add `Signed-off-by:` line to the commit message, using
+ the committer identity of yourself.
+
+--stdout::
+ Print all commits to the standard output in mbox format,
+ instead of creating a file for each one.
+
+--attach[=<boundary>]::
+ Create multipart/mixed attachment, the first part of
+ which is the commit message and the patch itself in the
+ second part, with "Content-Disposition: attachment".
+
+--inline[=<boundary>]::
+ Create multipart/mixed attachment, the first part of
+ which is the commit message and the patch itself in the
+ second part, with "Content-Disposition: inline".
+
+--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.
+
+--ignore-if-in-upstream::
+ Do not include a patch that matches a commit in
+ <until>..<since>. This will examine all patches reachable
+ from <since> but not from <until> and compare them with the
+ patches being generated, and any patch that matches is
+ ignored.
+
+--subject-prefix=<Subject-Prefix>::
+ Instead of the standard '[PATCH]' prefix in the subject
+ line, instead use '[<Subject-Prefix>]'. This
+ allows for useful naming of a patch series, and can be
+ combined with the --numbered option.
+
+--cc=<email>::
+ Add a "Cc:" header to the email headers. This is in addition
+ to any configured headers, and may be used multiple times.
+
+--cover-letter::
+ Generate a cover letter template. You still have to fill in
+ a description, but the shortlog and the diffstat will be
+ generated for you.
+
+--suffix=.<sfx>::
+ Instead of using `.patch` as the suffix for generated
+ filenames, use specified suffix. A common alternative is
+ `--suffix=.txt`.
++
+Note that you would need to include the leading dot `.` if you
+want a filename like `0001-description-of-my-change.patch`, and
+the first letter does not have to be a dot. Leaving it empty would
+not add any suffix.
+
+--no-binary::
+ Don't output contents of changes in binary files, just take note
+ that they differ. Note that this disable the patch to be properly
+ applied. By default the contents of changes in those files are
+ encoded in the patch.
+
+CONFIGURATION
+-------------
+You can specify extra mail header lines to be added to each message
+in the repository configuration, new defaults for the subject prefix
+and file suffix, and number patches when outputting more than one.
+
+------------
+[format]
+ headers = "Organization: git-foo\n"
+ subjectprefix = CHANGE
+ suffix = .txt
+ numbered = auto
+ cc = <email>
+------------
+
+
+EXAMPLES
+--------
+
+* Extract commits between revisions R1 and R2, and apply them on top of
+the current branch using `git-am` to cherry-pick them:
++
+------------
+$ git format-patch -k --stdout R1..R2 | git-am -3 -k
+------------
+
+* Extract all commits which are in the current branch but not in the
+origin branch:
++
+------------
+$ git format-patch origin
+------------
++
+For each commit a separate file is created in the current directory.
+
+* Extract all commits that lead to 'origin' since the inception of the
+project:
++
+------------
+$ git format-patch \--root origin
+------------
+
+* The same as the previous one:
++
+------------
+$ git format-patch -M -B origin
+------------
++
+Additionally, it detects and handles renames and complete rewrites
+intelligently to produce a renaming patch. A renaming patch reduces
+the amount of text output, and generally makes it easier to review it.
+Note that the "patch" program does not understand renaming patches, so
+use it only when you know the recipient uses git to apply your patch.
+
+* Extract three topmost commits from the current branch and format them
+as e-mailable patches:
++
+------------
+$ git format-patch -3
+------------
+
+SEE ALSO
+--------
+linkgit:git-am[1], linkgit:git-send-email[1]
+
+
+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 linkgit:git[1] suite
diff --git a/Documentation/git-fsck-objects.txt b/Documentation/git-fsck-objects.txt
new file mode 100644
index 0000000000..6e9f717642
--- /dev/null
+++ b/Documentation/git-fsck-objects.txt
@@ -0,0 +1,17 @@
+git-fsck-objects(1)
+===================
+
+NAME
+----
+git-fsck-objects - Verifies the connectivity and validity of the objects in the database
+
+
+SYNOPSIS
+--------
+'git-fsck-objects' ...
+
+DESCRIPTION
+-----------
+
+This is a synonym for linkgit:git-fsck[1]. Please refer to the
+documentation of that command.
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
new file mode 100644
index 0000000000..9846c859cf
--- /dev/null
+++ b/Documentation/git-fsck.txt
@@ -0,0 +1,154 @@
+git-fsck(1)
+===========
+
+NAME
+----
+git-fsck - Verifies the connectivity and validity of the objects in the database
+
+
+SYNOPSIS
+--------
+[verse]
+'git-fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
+ [--full] [--strict] [--verbose] [--lost-found] [<object>*]
+
+DESCRIPTION
+-----------
+Verifies the connectivity and validity of the objects in the database.
+
+OPTIONS
+-------
+<object>::
+ An object to treat as the head of an unreachability trace.
++
+If no objects are given, git-fsck defaults to using the
+index file, all SHA1 references in .git/refs/*, and all reflogs (unless
+--no-reflogs is given) as heads.
+
+--unreachable::
+ Print out objects that exist but that aren't readable from any
+ of the reference nodes.
+
+--root::
+ Report root nodes.
+
+--tags::
+ Report tags.
+
+--cache::
+ Consider any object recorded in the index also as a head node for
+ an unreachability trace.
+
+--no-reflogs::
+ Do not consider commits that are referenced only by an
+ entry in a reflog to be reachable. This option is meant
+ only to search for commits that used to be in a ref, but
+ now aren't, but are still in that corresponding reflog.
+
+--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
+ 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.
+
+--strict::
+ Enable more strict checking, namely to catch a file mode
+ recorded with g+w bit set, which was created by older
+ versions of git. Existing repositories, including the
+ Linux kernel, git itself, and sparse repository have old
+ objects that triggers this check, but it is recommended
+ to check new projects with this flag.
+
+--verbose::
+ Be chatty.
+
+--lost-found::
+ Write dangling objects into .git/lost-found/commit/ or
+ .git/lost-found/other/, depending on type. If the object is
+ a blob, the contents are written into the file, rather than
+ its object name.
+
+It tests SHA1 and general object sanity, and it does full tracking of
+the resulting reachability and everything else. It prints out any
+corruption it finds (missing or bad objects), and if you use the
+'--unreachable' flag it will also print out objects that exist but
+that aren't readable from any of the specified head nodes.
+
+So for example
+
+ git-fsck --unreachable HEAD $(cat .git/refs/heads/*)
+
+will do quite a _lot_ of verification on the tree. There are a few
+extra validity tests to be added (make sure that tree objects are
+sorted properly etc), but on the whole if "git-fsck" is happy, you
+do have a valid tree.
+
+Any corrupt objects you will have to find in backups or other archives
+(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
+evil person, and the end result might be crap. git is a revision
+tracking system, not a quality assurance system ;)
+
+Extracted Diagnostics
+---------------------
+
+expect dangling commits - potential heads - due to lack of head information::
+ You haven't specified any nodes as heads so it won't be
+ possible to differentiate between un-parented commits and
+ root nodes.
+
+missing sha1 directory '<dir>'::
+ The directory holding the sha1 objects is missing.
+
+unreachable <type> <object>::
+ The <type> object <object>, isn't actually referred to directly
+ or indirectly in any of the trees or commits seen. This can
+ mean that there's another root node that you're not specifying
+ or that the tree is corrupt. If you haven't missed a root node
+ then you might as well delete unreachable nodes since they
+ can't be used.
+
+missing <type> <object>::
+ The <type> object <object>, is referred to but isn't present in
+ the database.
+
+dangling <type> <object>::
+ The <type> object <object>, is present in the database but never
+ 'directly' used. A dangling commit could be a root node.
+
+warning: git-fsck: tree <tree> has full pathnames in it::
+ And it shouldn't...
+
+sha1 mismatch <object>::
+ The database has an object who's sha1 doesn't match the
+ database value.
+ This indicates a serious data integrity problem.
+
+Environment Variables
+---------------------
+
+GIT_OBJECT_DIRECTORY::
+ used to specify the object database root (usually $GIT_DIR/objects)
+
+GIT_INDEX_FILE::
+ used to specify the index file of the index
+
+GIT_ALTERNATE_OBJECT_DIRECTORIES::
+ used to specify additional object database roots (usually unset)
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
new file mode 100644
index 0000000000..6ace615d80
--- /dev/null
+++ b/Documentation/git-gc.txt
@@ -0,0 +1,135 @@
+git-gc(1)
+=========
+
+NAME
+----
+git-gc - Cleanup unnecessary files and optimize the local repository
+
+
+SYNOPSIS
+--------
+'git-gc' [--aggressive] [--auto] [--quiet]
+
+DESCRIPTION
+-----------
+Runs a number of housekeeping tasks within the current repository,
+such as compressing file revisions (to reduce disk space and increase
+performance) and removing unreachable objects which may have been
+created from prior invocations of linkgit:git-add[1].
+
+Users are encouraged to run this task on a regular basis within
+each repository to maintain good disk space utilization and good
+operating performance.
+
+Some git commands may automatically run `git-gc`; see the `--auto` flag
+below for details. If you know what you're doing and all you want is to
+disable this behavior permanently without further considerations, just do:
+
+----------------------
+$ git config --global gc.auto 0
+----------------------
+
+OPTIONS
+-------
+
+--aggressive::
+ Usually 'git-gc' runs very quickly while providing good disk
+ space utilization and performance. This option will cause
+ git-gc to more aggressively optimize the repository at the expense
+ of taking much more time. The effects of this optimization are
+ persistent, so this option only needs to be used occasionally; every
+ few hundred changesets or so.
+
+--auto::
+ With this option, `git gc` checks whether any housekeeping is
+ required; if not, it exits without performing any work.
+ Some git commands run `git gc --auto` after performing
+ operations that could create many loose objects.
++
+Housekeeping is required if there are too many loose objects or
+too many packs in the repository. If the number of loose objects
+exceeds the value of the `gc.auto` configuration variable, then
+all loose objects are combined into a single pack using
+`git-repack -d -l`. Setting the value of `gc.auto` to 0
+disables automatic packing of loose objects.
++
+If the number of packs exceeds the value of `gc.autopacklimit`,
+then existing packs (except those marked with a `.keep` file)
+are consolidated into a single pack by using the `-A` option of
+`git-repack`. Setting `gc.autopacklimit` to 0 disables
+automatic consolidation of packs.
+
+--quiet::
+ Suppress all progress reports.
+
+Configuration
+-------------
+
+The optional configuration variable 'gc.reflogExpire' can be
+set to indicate how long historical entries within each branch's
+reflog should remain available in this repository. The setting is
+expressed as a length of time, for example '90 days' or '3 months'.
+It defaults to '90 days'.
+
+The optional configuration variable 'gc.reflogExpireUnreachable'
+can be set to indicate how long historical reflog entries which
+are not part of the current branch should remain available in
+this repository. These types of entries are generally created as
+a result of using `git commit \--amend` or `git rebase` and are the
+commits prior to the amend or rebase occurring. Since these changes
+are not part of the current project most users will want to expire
+them sooner. This option defaults to '30 days'.
+
+The optional configuration variable 'gc.rerereresolved' indicates
+how long records of conflicted merge you resolved earlier are
+kept. This defaults to 60 days.
+
+The optional configuration variable 'gc.rerereunresolved' indicates
+how long records of conflicted merge you have not resolved are
+kept. This defaults to 15 days.
+
+The optional configuration variable 'gc.packrefs' determines if
+`git gc` runs `git-pack-refs`. This can be set to "nobare" to enable
+it within all non-bare repos or it can be set to a boolean value.
+This defaults to true.
+
+The optional configuration variable 'gc.aggressiveWindow' controls how
+much time is spent optimizing the delta compression of the objects in
+the repository when the --aggressive option is specified. The larger
+the value, the more time is spent optimizing the delta compression. See
+the documentation for the --window' option in linkgit:git-repack[1] for
+more details. This defaults to 10.
+
+The optional configuration variable 'gc.pruneExpire' controls how old
+the unreferenced loose objects have to be before they are pruned. The
+default is "2 weeks ago".
+
+
+Notes
+-----
+
+git-gc tries very hard to be safe about the garbage it collects. In
+particular, it will keep not only objects referenced by your current set
+of branches and tags, but also objects referenced by the index, remote
+tracking branches, refs saved by linkgit:git-filter-branch[1] in
+refs/original/, or reflogs (which may references commits in branches
+that were later amended or rewound).
+
+If you are expecting some objects to be collected and they aren't, check
+all of those locations and decide whether it makes sense in your case to
+remove those references.
+
+SEE ALSO
+--------
+linkgit:git-prune[1]
+linkgit:git-reflog[1]
+linkgit:git-repack[1]
+linkgit:git-rerere[1]
+
+Author
+------
+Written by Shawn O. Pearce <spearce@spearce.org>
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-get-tar-commit-id.txt b/Documentation/git-get-tar-commit-id.txt
new file mode 100644
index 0000000000..c13bf98697
--- /dev/null
+++ b/Documentation/git-get-tar-commit-id.txt
@@ -0,0 +1,36 @@
+git-get-tar-commit-id(1)
+========================
+
+NAME
+----
+git-get-tar-commit-id - Extract commit ID from an archive created using git-archive
+
+
+SYNOPSIS
+--------
+'git-get-tar-commit-id' < <tarfile>
+
+
+DESCRIPTION
+-----------
+Acts as a filter, extracting the commit ID stored in archives created by
+linkgit:git-archive[1]. It reads only the first 1024 bytes of input, thus its
+runtime is not influenced by the size of <tarfile> very much.
+
+If no commit ID is found, git-get-tar-commit-id quietly exists with a
+return code of 1. This can happen if <tarfile> had not been created
+using git-archive or if the first parameter of git-archive had been
+a tree ID instead of a commit ID or tag.
+
+
+Author
+------
+Written by Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
new file mode 100644
index 0000000000..1b646b73f0
--- /dev/null
+++ b/Documentation/git-grep.txt
@@ -0,0 +1,165 @@
+git-grep(1)
+===========
+
+NAME
+----
+git-grep - Print lines matching a pattern
+
+
+SYNOPSIS
+--------
+[verse]
+'git-grep' [--cached]
+ [-a | --text] [-I] [-i | --ignore-case] [-w | --word-regexp]
+ [-v | --invert-match] [-h|-H] [--full-name]
+ [-E | --extended-regexp] [-G | --basic-regexp]
+ [-F | --fixed-strings] [-n]
+ [-l | --files-with-matches] [-L | --files-without-match]
+ [-c | --count] [--all-match]
+ [-A <post-context>] [-B <pre-context>] [-C <context>]
+ [-f <file>] [-e] <pattern>
+ [--and|--or|--not|(|)|-e <pattern>...] [<tree>...]
+ [--] [<path>...]
+
+DESCRIPTION
+-----------
+Look for specified patterns in the working tree files, blobs
+registered in the index file, or given tree objects.
+
+
+OPTIONS
+-------
+--cached::
+ Instead of searching in the working tree files, check
+ the blobs registered in the index file.
+
+-a::
+--text::
+ Process binary files as if they were text.
+
+-i::
+--ignore-case::
+ Ignore case differences between the patterns and the
+ files.
+
+-I::
+ Don't match the pattern in binary 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.
+
+-h::
+-H::
+ By default, the command shows the filename for each
+ match. `-h` option is used to suppress this output.
+ `-H` is there for completeness and does not do anything
+ except it overrides `-h` given earlier on the command
+ line.
+
+--full-name::
+ When run from a subdirectory, the command usually
+ outputs paths relative to the current directory. This
+ option forces paths to be output relative to the project
+ top directory.
+
+-E::
+--extended-regexp::
+-G::
+--basic-regexp::
+ Use POSIX extended/basic regexp for patterns. Default
+ is to use basic regexp.
+
+-F::
+--fixed-strings::
+ Use fixed strings for patterns (don't interpret pattern
+ as a regex).
+
+-n::
+ Prefix the line number to matching lines.
+
+-l::
+--files-with-matches::
+--name-only::
+-L::
+--files-without-match::
+ Instead of showing every matched line, show only the
+ names of files that contain (or do not contain) matches.
+ For better compatibility with git-diff, --name-only is a
+ synonym for --files-with-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.
+
+-<num>::
+ A shortcut for specifying -C<num>.
+
+-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. Multiple patterns are
+ combined by 'or'.
+
+--and::
+--or::
+--not::
+( ... )::
+ Specify how multiple patterns are combined using Boolean
+ expressions. `--or` is the default operator. `--and` has
+ higher precedence than `--or`. `-e` has to be used for all
+ patterns.
+
+--all-match::
+ When giving multiple pattern expressions combined with `--or`,
+ this flag is specified to limit the match to files that
+ have lines to match all of them.
+
+`<tree>...`::
+ Search blobs in the trees for specified patterns.
+
+\--::
+ Signals the end of options; the rest of the parameters
+ are <path> limiters.
+
+
+Example
+-------
+
+git grep -e \'#define\' --and \( -e MAX_PATH -e PATH_MAX \)::
+ Looks for a line that has `#define` and either `MAX_PATH` or
+ `PATH_MAX`.
+
+git grep --all-match -e NODE -e Unexpected::
+ Looks for a line that has `NODE` or `Unexpected` in
+ files that have lines that match both.
+
+Author
+------
+Originally written by Linus Torvalds <torvalds@osdl.org>, later
+revamped by Junio C Hamano.
+
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt
new file mode 100644
index 0000000000..105397f2bd
--- /dev/null
+++ b/Documentation/git-gui.txt
@@ -0,0 +1,115 @@
+git-gui(1)
+==========
+
+NAME
+----
+git-gui - A portable graphical interface to Git
+
+SYNOPSIS
+--------
+'git gui' [<command>] [arguments]
+
+DESCRIPTION
+-----------
+A Tcl/Tk based graphical user interface to Git. git-gui focuses
+on allowing users to make changes to their repository by making
+new commits, amending existing ones, creating branches, performing
+local merges, and fetching/pushing to remote repositories.
+
+Unlike linkgit:gitk[1], git-gui focuses on commit generation
+and single file annotation, and does not show project history.
+It does however supply menu actions to start a gitk session from
+within git-gui.
+
+git-gui is known to work on all popular UNIX systems, Mac OS X,
+and Windows (under both Cygwin and MSYS). To the extent possible
+OS specific user interface guidelines are followed, making git-gui
+a fairly native interface for users.
+
+COMMANDS
+--------
+blame::
+ Start a blame viewer on the specified file on the given
+ version (or working directory if not specified).
+
+browser::
+ Start a tree browser showing all files in the specified
+ commit (or 'HEAD' by default). Files selected through the
+ browser are opened in the blame viewer.
+
+citool::
+ Start git-gui and arrange to make exactly one commit before
+ exiting and returning to the shell. The interface is limited
+ to only commit actions, slightly reducing the application's
+ startup time and simplifying the menubar.
+
+version::
+ Display the currently running version of git-gui.
+
+
+Examples
+--------
+git gui blame Makefile::
+
+ Show the contents of the file 'Makefile' in the current
+ working directory, and provide annotations for both the
+ original author of each line, and who moved the line to its
+ current location. The uncommitted file is annotated, and
+ uncommitted changes (if any) are explicitly attributed to
+ 'Not Yet Committed'.
+
+git gui blame v0.99.8 Makefile::
+
+ Show the contents of 'Makefile' in revision 'v0.99.8'
+ and provide annotations for each line. Unlike the above
+ example the file is read from the object database and not
+ the working directory.
+
+git gui citool::
+
+ Make one commit and return to the shell when it is complete.
+
+git citool::
+
+ Same as 'git gui citool' (above).
+
+git gui browser maint::
+
+ Show a browser for the tree of the 'maint' branch. Files
+ selected in the browser can be viewed with the internal
+ blame viewer.
+
+SEE ALSO
+--------
+linkgit:gitk[1]::
+ The git repository browser. Shows branches, commit history
+ and file differences. gitk is the utility started by
+ git-gui's Repository Visualize actions.
+
+Other
+-----
+git-gui is actually maintained as an independent project, but stable
+versions are distributed as part of the Git suite for the convenience
+of end users.
+
+A git-gui development repository can be obtained from:
+
+ git clone git://repo.or.cz/git-gui.git
+
+or
+
+ git clone http://repo.or.cz/r/git-gui.git
+
+or browsed online at http://repo.or.cz/w/git-gui.git/[].
+
+Author
+------
+Written by Shawn O. Pearce <spearce@spearce.org>.
+
+Documentation
+--------------
+Documentation by Shawn O. Pearce <spearce@spearce.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt
new file mode 100644
index 0000000000..cf3dce8a4a
--- /dev/null
+++ b/Documentation/git-hash-object.txt
@@ -0,0 +1,48 @@
+git-hash-object(1)
+==================
+
+NAME
+----
+git-hash-object - Compute object ID and optionally creates a blob from a file
+
+
+SYNOPSIS
+--------
+'git-hash-object' [-t <type>] [-w] [--stdin | --stdin-paths] [--] <file>...
+
+DESCRIPTION
+-----------
+Computes the object ID value for an object with specified type
+with the contents of the named file (which can be outside of the
+work tree), and optionally writes the resulting object into the
+object database. Reports its object ID to its standard output.
+This is used by "git-cvsimport" to update the index
+without modifying files in the work tree. When <type> is not
+specified, it defaults to "blob".
+
+OPTIONS
+-------
+
+-t <type>::
+ Specify the type (default: "blob").
+
+-w::
+ Actually write the object into the object database.
+
+--stdin::
+ Read the object from standard input instead of from a file.
+
+--stdin-paths::
+ Read file names from stdin instead of from the command-line.
+
+Author
+------
+Written 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 linkgit:git[1] suite
diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
new file mode 100644
index 0000000000..faecd6bb90
--- /dev/null
+++ b/Documentation/git-help.txt
@@ -0,0 +1,185 @@
+git-help(1)
+===========
+
+NAME
+----
+git-help - display help information about git
+
+SYNOPSIS
+--------
+'git help' [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND]
+
+DESCRIPTION
+-----------
+
+With no options and no COMMAND given, the synopsis of the 'git'
+command and a list of the most commonly used git commands are printed
+on the standard output.
+
+If the option '--all' or '-a' is given, then all available commands are
+printed on the standard output.
+
+If a git command is named, a manual page for that command is brought
+up. The 'man' program is used by default for this purpose, but this
+can be overridden by other options or configuration variables.
+
+Note that 'git --help ...' is identical as 'git help ...' because the
+former is internally converted into the latter.
+
+OPTIONS
+-------
+-a::
+--all::
+ Prints all the available commands on the standard output. This
+ option supersedes any other option.
+
+-i::
+--info::
+ Display manual page for the command in the 'info' format. The
+ 'info' program will be used for that purpose.
+
+-m::
+--man::
+ Display manual page for the command in the 'man' format. This
+ option may be used to override a value set in the
+ 'help.format' configuration variable.
++
+By default the 'man' program will be used to display the manual page,
+but the 'man.viewer' configuration variable may be used to choose
+other display programs (see below).
+
+-w::
+--web::
+ Display manual page for the command in the 'web' (HTML)
+ format. A web browser will be used for that purpose.
++
+The web browser can be specified using the configuration variable
+'help.browser', or 'web.browser' if the former is not set. If none of
+these config variables is set, the 'git-web--browse' helper script
+(called by 'git-help') will pick a suitable default. See
+linkgit:git-web--browse[1] for more information about this.
+
+CONFIGURATION VARIABLES
+-----------------------
+
+help.format
+~~~~~~~~~~~
+
+If no command line option is passed, the 'help.format' configuration
+variable will be checked. The following values are supported for this
+variable; they make 'git-help' behave as their corresponding command
+line option:
+
+* "man" corresponds to '-m|--man',
+* "info" corresponds to '-i|--info',
+* "web" or "html" correspond to '-w|--web'.
+
+help.browser, web.browser and browser.<tool>.path
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The 'help.browser', 'web.browser' and 'browser.<tool>.path' will also
+be checked if the 'web' format is chosen (either by command line
+option or configuration variable). See '-w|--web' in the OPTIONS
+section above and linkgit:git-web--browse[1].
+
+man.viewer
+~~~~~~~~~~
+
+The 'man.viewer' config variable will be checked if the 'man' format
+is chosen. The following values are currently supported:
+
+* "man": use the 'man' program as usual,
+* "woman": use 'emacsclient' to launch the "woman" mode in emacs
+(this only works starting with emacsclient versions 22),
+* "konqueror": use 'kfmclient' to open the man page in a new konqueror
+tab (see 'Note about konqueror' below).
+
+Values for other tools can be used if there is a corresponding
+'man.<tool>.cmd' configuration entry (see below).
+
+Multiple values may be given to the 'man.viewer' configuration
+variable. Their corresponding programs will be tried in the order
+listed in the configuration file.
+
+For example, this configuration:
+
+------------------------------------------------
+ [man]
+ viewer = konqueror
+ viewer = woman
+------------------------------------------------
+
+will try to use konqueror first. But this may fail (for example if
+DISPLAY is not set) and in that case emacs' woman mode will be tried.
+
+If everything fails the 'man' program will be tried anyway.
+
+man.<tool>.path
+~~~~~~~~~~~~~~~
+
+You can explicitly provide a full path to your preferred man viewer by
+setting the configuration variable 'man.<tool>.path'. For example, you
+can configure the absolute path to konqueror by setting
+'man.konqueror.path'. Otherwise, 'git help' assumes the tool is
+available in PATH.
+
+man.<tool>.cmd
+~~~~~~~~~~~~~~
+
+When the man viewer, specified by the 'man.viewer' configuration
+variables, is not among the supported ones, then the corresponding
+'man.<tool>.cmd' configuration variable will be looked up. If this
+variable exists then the specified tool will be treated as a custom
+command and a shell eval will be used to run the command with the man
+page passed as arguments.
+
+Note about konqueror
+~~~~~~~~~~~~~~~~~~~~
+
+When 'konqueror' is specified in the 'man.viewer' configuration
+variable, we launch 'kfmclient' to try to open the man page on an
+already opened konqueror in a new tab if possible.
+
+For consistency, we also try such a trick if 'man.konqueror.path' is
+set to something like 'A_PATH_TO/konqueror'. That means we will try to
+launch 'A_PATH_TO/kfmclient' instead.
+
+If you really want to use 'konqueror', then you can use something like
+the following:
+
+------------------------------------------------
+ [man]
+ viewer = konq
+
+ [man "konq"]
+ cmd = A_PATH_TO/konqueror
+------------------------------------------------
+
+Note about git config --global
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Note that all these configuration variables should probably be set
+using the '--global' flag, for example like this:
+
+------------------------------------------------
+$ git config --global help.format web
+$ git config --global web.browser firefox
+------------------------------------------------
+
+as they are probably more user specific than repository specific.
+See linkgit:git-config[1] for more information about this.
+
+Author
+------
+Written by Junio C Hamano <gitster@pobox.com> and the git-list
+<git@vger.kernel.org>.
+
+Documentation
+-------------
+Initial documentation was part of the linkgit:git[1] man page.
+Christian Couder <chriscool@tuxfamily.org> extracted and rewrote it a
+little. Maintenance is done by the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-http-fetch.txt b/Documentation/git-http-fetch.txt
new file mode 100644
index 0000000000..70fb635291
--- /dev/null
+++ b/Documentation/git-http-fetch.txt
@@ -0,0 +1,56 @@
+git-http-fetch(1)
+=================
+
+NAME
+----
+git-http-fetch - Download from a remote git repository via HTTP
+
+
+SYNOPSIS
+--------
+'git-http-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin] <commit> <url>
+
+DESCRIPTION
+-----------
+Downloads a remote git repository via HTTP.
+
+OPTIONS
+-------
+commit-id::
+ Either the hash or the filename under [URL]/refs/ to
+ pull.
+
+-c::
+ Get the commit objects.
+-t::
+ Get trees associated with the commit objects.
+-a::
+ Get all the objects.
+-v::
+ Report what is downloaded.
+
+-w <filename>::
+ Writes the commit-id into the filename under $GIT_DIR/refs/<filename> on
+ the local end after the transfer is complete.
+
+--stdin::
+ Instead of a commit id on the command line (which is not expected in this
+ case), 'git-http-fetch' expects lines on stdin in the format
+
+ <commit-id>['\t'<filename-as-in--w>]
+
+--recover::
+ Verify that everything reachable from target is fetched. Used after
+ an earlier fetch is interrupted.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt
new file mode 100644
index 0000000000..8d32a92049
--- /dev/null
+++ b/Documentation/git-http-push.txt
@@ -0,0 +1,105 @@
+git-http-push(1)
+================
+
+NAME
+----
+git-http-push - Push objects over HTTP/DAV to another repository
+
+
+SYNOPSIS
+--------
+'git-http-push' [--all] [--dry-run] [--force] [--verbose] <url> <ref> [<ref>...]
+
+DESCRIPTION
+-----------
+Sends missing objects to remote repository, and updates the
+remote branch.
+
+*NOTE*: This command is temporarily disabled if your cURL
+library is older than 7.16, as the combination has been reported
+not to work and sometimes corrupts repository.
+
+OPTIONS
+-------
+--all::
+ Do not assume that the remote repository is complete in its
+ current state, and verify all objects in the entire local
+ ref's history exist in the remote repository.
+
+--force::
+ Usually, the command refuses to update a remote ref that
+ is not an ancestor of the local ref used to overwrite it.
+ This flag disables the check. What this means is that
+ the remote repository can lose commits; use it with
+ care.
+
+--dry-run::
+ Do everything except actually send the updates.
+
+--verbose::
+ Report the list of objects being walked locally and the
+ list of objects successfully sent to the remote repository.
+
+-d::
+-D::
+ Remove <ref> from remote repository. The specified branch
+ cannot be the remote HEAD. If -d is specified the following
+ other conditions must also be met:
+
+ - Remote HEAD must resolve to an object that exists locally
+ - Specified branch resolves to an object that exists locally
+ - Specified branch is an ancestor of the remote HEAD
+
+<ref>...::
+ The remote refs to update.
+
+
+Specifying the Refs
+-------------------
+
+A '<ref>' specification can be either a single pattern, or a pair
+of such patterns separated by a colon ":" (this means that a ref name
+cannot have a colon in it). A single pattern '<name>' is just a
+shorthand for '<name>:<name>'.
+
+Each pattern pair consists of the source side (before the colon)
+and the destination side (after the colon). The ref to be
+pushed is determined by finding a match that matches the source
+side, and where it is pushed is determined by using the
+destination side.
+
+ - It is an error if <src> does not match exactly one of the
+ local refs.
+
+ - If <dst> does not match any remote ref, either
+
+ * it has to start with "refs/"; <dst> is used as the
+ destination literally in this case.
+
+ * <src> == <dst> and the ref that matched the <src> must not
+ exist in the set of remote refs; the ref matched <src>
+ locally is used as the name of the destination.
+
+Without '--force', the <src> ref is stored at the remote only if
+<dst> does not exist, or <dst> is a proper subset (i.e. an
+ancestor) of <src>. This check, known as "fast forward check",
+is performed in order to avoid accidentally overwriting the
+remote ref and lose other peoples' commits from there.
+
+With '--force', the fast forward check is disabled for all refs.
+
+Optionally, a <ref> parameter can be prefixed with a plus '+' sign
+to disable the fast-forward check only on that ref.
+
+
+Author
+------
+Written by Nick Hengeveld <nickh@reactrix.com>
+
+Documentation
+--------------
+Documentation by Nick Hengeveld
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
new file mode 100644
index 0000000000..f4fdc24283
--- /dev/null
+++ b/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 linkgit:git[1] suite
diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt
new file mode 100644
index 0000000000..6409363ae5
--- /dev/null
+++ b/Documentation/git-index-pack.txt
@@ -0,0 +1,103 @@
+git-index-pack(1)
+=================
+
+NAME
+----
+git-index-pack - Build pack index file for an existing packed archive
+
+
+SYNOPSIS
+--------
+[verse]
+'git-index-pack' [-v] [-o <index-file>] <pack-file>
+'git-index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>]
+ [<pack-file>]
+
+
+DESCRIPTION
+-----------
+Reads a packed archive (.pack) from the specified file, and
+builds a pack index file (.idx) for it. The packed archive
+together with the pack index can then be placed in the
+objects/pack/ directory of a git repository.
+
+
+OPTIONS
+-------
+-v::
+ Be verbose about what is going on, including progress status.
+
+-o <index-file>::
+ Write the generated pack index into the specified
+ file. Without this option the name of pack index
+ file is constructed from the name of packed archive
+ file by replacing .pack with .idx (and the program
+ fails if the name of packed archive does not end
+ with .pack).
+
+--stdin::
+ When this flag is provided, the pack is read from stdin
+ instead and a copy is then written to <pack-file>. If
+ <pack-file> is not specified, the pack is written to
+ objects/pack/ directory of the current git repository with
+ a default name determined from the pack content. If
+ <pack-file> is not specified consider using --keep to
+ prevent a race condition between this process and
+ linkgit:git-repack[1].
+
+--fix-thin::
+ It is possible for linkgit:git-pack-objects[1] to build
+ "thin" pack, which records objects in deltified form based on
+ objects not included in the pack to reduce network traffic.
+ Those objects are expected to be present on the receiving end
+ and they must be included in the pack for that pack to be self
+ contained and indexable. Without this option any attempt to
+ index a thin pack will fail. This option only makes sense in
+ conjunction with --stdin.
+
+--keep::
+ Before moving the index into its final destination
+ create an empty .keep file for the associated pack file.
+ This option is usually necessary with --stdin to prevent a
+ simultaneous linkgit:git-repack[1] process from deleting
+ the newly constructed pack and index before refs can be
+ updated to use objects contained in the pack.
+
+--keep='why'::
+ Like --keep create a .keep file before moving the index into
+ its final destination, but rather than creating an empty file
+ place 'why' followed by an LF into the .keep file. The 'why'
+ message can later be searched for within all .keep files to
+ locate any which have outlived their usefulness.
+
+--index-version=<version>[,<offset>]::
+ This is intended to be used by the test suite only. It allows
+ to force the version for the generated pack index, and to force
+ 64-bit index entries on objects located above the given offset.
+
+--strict::
+ Die, if the pack contains broken objects or links.
+
+
+Note
+----
+
+Once the index has been created, the list of object names is sorted
+and the SHA1 hash of that list is printed to stdout. If --stdin was
+also used then this is prefixed by either "pack\t", or "keep\t" if a
+new .keep file was successfully created. This is useful to remove a
+.keep file used as a lock to prevent the race with linkgit:git-repack[1]
+mentioned above.
+
+
+Author
+------
+Written by Sergey Vlasov <vsu@altlinux.ru>
+
+Documentation
+-------------
+Documentation by Sergey Vlasov
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
new file mode 100644
index 0000000000..439cabb737
--- /dev/null
+++ b/Documentation/git-init-db.txt
@@ -0,0 +1,18 @@
+git-init-db(1)
+==============
+
+NAME
+----
+git-init-db - Creates an empty git repository
+
+
+SYNOPSIS
+--------
+'git-init-db' [-q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]]
+
+
+DESCRIPTION
+-----------
+
+This is a synonym for linkgit:git-init[1]. Please refer to the
+documentation of that command.
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
new file mode 100644
index 0000000000..792643c809
--- /dev/null
+++ b/Documentation/git-init.txt
@@ -0,0 +1,126 @@
+git-init(1)
+===========
+
+NAME
+----
+git-init - Create an empty git repository or reinitialize an existing one
+
+
+SYNOPSIS
+--------
+'git-init' [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]]
+
+
+OPTIONS
+-------
+
+--
+
+-q::
+--quiet::
+
+Only print error and warning messages, all other output will be suppressed.
+
+--bare::
+
+Create a bare repository. If GIT_DIR environment is not set, it is set to the
+current working directory.
+
+--template=<template_directory>::
+
+Provide the directory from which templates will be used. The default template
+directory is `/usr/share/git-core/templates`.
+
+When specified, `<template_directory>` is used as the source of the template
+files rather than the default. The template files include some directory
+structure, some suggested "exclude patterns", and copies of non-executing
+"hook" files. The suggested patterns and hook files are all modifiable and
+extensible.
+
+--shared[={false|true|umask|group|all|world|everybody|0xxx}]::
+
+Specify that the git repository is to be shared amongst several users. This
+allows users belonging to the same group to push into that
+repository. When specified, the config variable "core.sharedRepository" is
+set so that files and directories under `$GIT_DIR` are created with the
+requested permissions. When not specified, git will use permissions reported
+by umask(2).
+
+The option can have the following values, defaulting to 'group' if no value
+is given:
+
+ - 'umask' (or 'false'): Use permissions reported by umask(2). The default,
+ when `--shared` is not specified.
+
+ - 'group' (or 'true'): Make the repository group-writable, (and g+sx, since
+ the git group may be not the primary group of all users).
+
+ - 'all' (or 'world' or 'everybody'): Same as 'group', but make the repository
+ readable by all users.
+
+ - '0xxx': '0xxx' is an octal number and each file will have mode '0xxx'
+ Any option except 'umask' can be set using this option. '0xxx' will
+ override users umask(2) value, and thus, users with a safe umask (0077)
+ can use this option. '0640' will create a repository which is group-readable
+ but not writable. '0660' is equivalent to 'group'.
+
+By default, the configuration flag receive.denyNonFastForwards is enabled
+in shared repositories, so that you cannot force a non fast-forwarding push
+into it.
+
+--
+
+
+DESCRIPTION
+-----------
+This command creates an empty git repository - basically a `.git` directory
+with subdirectories for `objects`, `refs/heads`, `refs/tags`, and
+template files.
+An initial `HEAD` file that references the HEAD of the master branch
+is also created.
+
+If the `$GIT_DIR` environment variable is set then it specifies a path
+to use instead of `./.git` for the base of the repository.
+
+If the object storage directory is specified via the `$GIT_OBJECT_DIRECTORY`
+environment variable then the sha1 directories are created underneath -
+otherwise the default `$GIT_DIR/objects` directory is used.
+
+Running `git-init` in an existing repository is safe. It will not overwrite
+things that are already there. The primary reason for rerunning `git-init`
+is to pick up newly added templates.
+
+Note that `git-init` is the same as `git-init-db`. The command
+was primarily meant to initialize the object database, but over
+time it has become responsible for setting up the other aspects
+of the repository, such as installing the default hooks and
+setting the configuration variables. The old name is retained
+for backward compatibility reasons.
+
+
+EXAMPLES
+--------
+
+Start a new git repository for an existing code base::
++
+----------------
+$ cd /path/to/my/codebase
+$ git-init <1>
+$ git-add . <2>
+----------------
++
+<1> prepare /path/to/my/codebase/.git directory
+<2> add all existing file to the index
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt
new file mode 100644
index 0000000000..7da5b8d9a9
--- /dev/null
+++ b/Documentation/git-instaweb.txt
@@ -0,0 +1,94 @@
+git-instaweb(1)
+===============
+
+NAME
+----
+git-instaweb - Instantly browse your working repository in gitweb
+
+SYNOPSIS
+--------
+[verse]
+'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, apache2 and webrick are supported.
+ (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 that should be used to view the gitweb
+ page. This will be passed to the 'git-web--browse' helper
+ script along with the URL of the gitweb instance. See
+ linkgit:git-web--browse[1] for more information about this. If
+ the script fails, the URL will be printed to stdout.
+
+--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
+
+-----------------------------------------------------------------------
+
+If the configuration variable 'instaweb.browser' is not set,
+'web.browser' will be used instead if it is defined. See
+linkgit:git-web--browse[1] for more information about this.
+
+Author
+------
+Written by Eric Wong <normalperson@yhbt.net>
+
+Documentation
+--------------
+Documentation by Eric Wong <normalperson@yhbt.net>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
new file mode 100644
index 0000000000..db61bc96c7
--- /dev/null
+++ b/Documentation/git-log.txt
@@ -0,0 +1,115 @@
+git-log(1)
+==========
+
+NAME
+----
+git-log - Show commit logs
+
+
+SYNOPSIS
+--------
+'git-log' <option>...
+
+DESCRIPTION
+-----------
+Shows the commit logs.
+
+The command takes options applicable to the linkgit:git-rev-list[1]
+command to control what is shown and how, and options applicable to
+the linkgit:git-diff-tree[1] commands to control how the changes
+each commit introduces are shown.
+
+
+OPTIONS
+-------
+
+:git-log: 1
+include::diff-options.txt[]
+
+-<n>::
+ Limits the number of commits to show.
+
+<since>..<until>::
+ Show only commits between the named two commits. When
+ either <since> or <until> is omitted, it defaults to
+ `HEAD`, i.e. the tip of the current branch.
+ For a more complete list of ways to spell <since>
+ and <until>, see "SPECIFYING REVISIONS" section in
+ linkgit:git-rev-parse[1].
+
+--decorate::
+ Print out the ref names of any commits that are shown.
+
+--full-diff::
+ Without this flag, "git log -p <paths>..." shows commits that
+ touch the specified paths, and diffs about the same specified
+ paths. With this, the full diff is shown for commits that touch
+ the specified paths; this means that "<paths>..." limits only
+ commits, and doesn't limit diff for those commits.
+
+--follow::
+ Continue listing the history of a file beyond renames.
+
+--log-size::
+ Before the log message print out its size in bytes. Intended
+ mainly for porcelain tools consumption. If git is unable to
+ produce a valid value size is set to zero.
+ Note that only message is considered, if also a diff is shown
+ its size is not included.
+
+<paths>...::
+ Show only commits that affect the specified paths.
+
+
+include::rev-list-options.txt[]
+
+include::pretty-formats.txt[]
+
+include::diff-generate-patch.txt[]
+
+Examples
+--------
+git log --no-merges::
+
+ Show the whole commit history, but skip any merges
+
+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::
+
+ 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 --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.
+
+git log --follow builtin-rev-list.c::
+
+ Shows the commits that changed builtin-rev-list.c, including
+ those commits that occurred before the file was given its
+ present name.
+
+Discussion
+----------
+
+include::i18n.txt[]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-lost-found.txt b/Documentation/git-lost-found.txt
new file mode 100644
index 0000000000..4dc475e0de
--- /dev/null
+++ b/Documentation/git-lost-found.txt
@@ -0,0 +1,81 @@
+git-lost-found(1)
+=================
+
+NAME
+----
+git-lost-found - Recover lost refs that luckily have not yet been pruned
+
+SYNOPSIS
+--------
+'git-lost-found'
+
+DESCRIPTION
+-----------
+
+*NOTE*: this command is deprecated. Use linkgit:git-fsck[1] with
+the option '--lost-found' instead.
+
+Finds dangling commits and tags from the object database, and
+creates refs to them in the .git/lost-found/ directory. Commits and
+tags that dereference to commits are stored in .git/lost-found/commit,
+and other objects are stored in .git/lost-found/other.
+
+
+OUTPUT
+------
+Prints to standard output the object names and one-line descriptions
+of any commits or tags found.
+
+EXAMPLE
+-------
+
+Suppose you run 'git tag -f' and mistype the tag to overwrite.
+The ref to your tag is overwritten, but until you run 'git
+prune', the tag itself is still there.
+
+------------
+$ git lost-found
+[1ef2b196d909eed523d4f3c9bf54b78cdd6843c6] GIT 0.99.9c
+...
+------------
+
+Also you can use gitk to browse how any tags found relate to each
+other.
+
+------------
+$ gitk $(cd .git/lost-found/commit && echo ??*)
+------------
+
+After making sure you know which the object is the tag you are looking
+for, you can reconnect it to your regular .git/refs hierarchy.
+
+------------
+$ git cat-file -t 1ef2b196
+tag
+$ git cat-file tag 1ef2b196
+object fa41bbce8e38c67a218415de6cfa510c7e50032a
+type commit
+tag v0.99.9c
+tagger Junio C Hamano <junkio@cox.net> 1131059594 -0800
+
+GIT 0.99.9c
+
+This contains the following changes from the "master" branch, since
+...
+$ git update-ref refs/tags/not-lost-anymore 1ef2b196
+$ git rev-parse not-lost-anymore
+1ef2b196d909eed523d4f3c9bf54b78cdd6843c6
+------------
+
+Author
+------
+Written by Junio C Hamano <gitster@pobox.com>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
new file mode 100644
index 0000000000..560594e25f
--- /dev/null
+++ b/Documentation/git-ls-files.txt
@@ -0,0 +1,205 @@
+git-ls-files(1)
+===============
+
+NAME
+----
+git-ls-files - Show information about files in the index and the working tree
+
+
+SYNOPSIS
+--------
+[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-standard]
+ [--error-unmatch] [--with-tree=<tree-ish>]
+ [--full-name] [--abbrev] [--] [<file>]\*
+
+DESCRIPTION
+-----------
+This merges the file listing in the directory cache index with the
+actual working directory list, and shows different combinations of the
+two.
+
+One or more of the options below may be used to determine the files
+shown:
+
+OPTIONS
+-------
+-c::
+--cached::
+ Show cached files in the output (default)
+
+-d::
+--deleted::
+ Show deleted files in the output
+
+-m::
+--modified::
+ Show modified files in the output
+
+-o::
+--others::
+ Show other files in the output
+
+-i::
+--ignored::
+ Show ignored files in the output.
+ Note that this also reverses any exclude list present.
+
+-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)
+
+-k::
+--killed::
+ Show files on the filesystem that need to be removed due
+ to file/directory conflicts for checkout-index to
+ succeed.
+
+-z::
+ \0 line termination on output.
+
+-x <pattern>::
+--exclude=<pattern>::
+ Skips files matching pattern.
+ Note that pattern is a shell wildcard pattern.
+
+-X <file>::
+--exclude-from=<file>::
+ exclude patterns are read from <file>; 1 per line.
+
+--exclude-per-directory=<file>::
+ read additional exclude patterns that apply only to the
+ directory and its subdirectories in <file>.
+
+--exclude-standard::
+ Add the standard git exclusions: .git/info/exclude, .gitignore
+ in each directory, and the user's global exclusion file.
+
+--error-unmatch::
+ If any <file> does not appear in the index, treat this as an
+ error (return 1).
+
+--with-tree=<tree-ish>::
+ When using --error-unmatch to expand the user supplied
+ <file> (i.e. path pattern) arguments to paths, pretend
+ that paths which were removed in the index since the
+ named <tree-ish> are still present. Using this option
+ with `-s` or `-u` options does not make any sense.
+
+-t::
+ Identify the file status with the following tags (followed by
+ a space) at the start of each line:
+ H:: cached
+ M:: unmerged
+ R:: removed/deleted
+ C:: modified/changed
+ K:: to be killed
+ ?:: other
+
+-v::
+ Similar to `-t`, but use lowercase letters for files
+ that are marked as 'assume unchanged' (see
+ linkgit:git-update-index[1]).
+
+--full-name::
+ When run from a subdirectory, the command usually
+ outputs paths relative to the current directory. This
+ 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>::
+ Files to show. If no files are given all files which match the other
+ specified criteria are shown.
+
+Output
+------
+show files just outputs the filename unless '--stage' is specified in
+which case it outputs:
+
+ [<tag> ]<mode> <object> <stage> <file>
+
+"git-ls-files --unmerged" and "git-ls-files --stage" can be used to examine
+detailed information on unmerged paths.
+
+For an unmerged path, instead of recording a single mode/SHA1 pair,
+the index records up to three such pairs; one from tree O in stage
+1, A in stage 2, and B in stage 3. This information can be used by
+the user (or the porcelain) to see what should eventually be recorded at the
+path. (see git-read-tree for more information on state)
+
+When `-z` option is not used, TAB, LF, and backslash characters
+in pathnames are represented as `\t`, `\n`, and `\\`,
+respectively.
+
+
+Exclude Patterns
+----------------
+
+'git-ls-files' can use a list of "exclude patterns" when
+traversing the directory tree and finding files to show when the
+flags --others or --ignored are specified. linkgit:gitignore[5]
+specifies the format of exclude patterns.
+
+These exclude patterns come from these places, in order:
+
+ 1. The command line flag --exclude=<pattern> specifies a
+ single pattern. Patterns are ordered in the same order
+ they appear in the command line.
+
+ 2. The command line flag --exclude-from=<file> specifies a
+ file containing a list of patterns. Patterns are ordered
+ in the same order they appear in the file.
+
+ 3. command line flag --exclude-per-directory=<name> specifies
+ a name of the file in each directory 'git-ls-files'
+ examines, normally `.gitignore`. Files in deeper
+ directories take precedence. Patterns are ordered in the
+ same order they appear in the files.
+
+A pattern specified on the command line with --exclude or read
+from the file specified with --exclude-from is relative to the
+top of the directory tree. A pattern read from a file specified
+by --exclude-per-directory is relative to the directory that the
+pattern file appears in.
+
+SEE ALSO
+--------
+linkgit:git-read-tree[1], linkgit:gitignore[5]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano, Josh Triplett, and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt
new file mode 100644
index 0000000000..f92f3ca186
--- /dev/null
+++ b/Documentation/git-ls-remote.txt
@@ -0,0 +1,76 @@
+git-ls-remote(1)
+================
+
+NAME
+----
+git-ls-remote - List references in a remote repository
+
+
+SYNOPSIS
+--------
+[verse]
+'git-ls-remote' [--heads] [--tags] [-u <exec> | --upload-pack <exec>]
+ <repository> <refs>...
+
+DESCRIPTION
+-----------
+Displays references available in a remote repository along with the associated
+commit IDs.
+
+
+OPTIONS
+-------
+-h::
+--heads::
+-t::
+--tags::
+ Limit to only refs/heads and refs/tags, respectively.
+ These options are _not_ mutually exclusive; when given
+ both, references stored in refs/heads and refs/tags are
+ displayed.
+
+-u <exec>::
+--upload-pack=<exec>::
+ Specify the full path of linkgit:git-upload-pack[1] on the remote
+ host. This allows listing references from repositories accessed via
+ SSH and where the SSH daemon does not use the PATH configured by the
+ user.
+
+<repository>::
+ Location of the repository. The shorthand defined in
+ $GIT_DIR/branches/ can be used. Use "." (dot) to list references in
+ the local repository.
+
+<refs>...::
+ When unspecified, all references, after filtering done
+ with --heads and --tags, are shown. When <refs>... are
+ specified, only references matching the given patterns
+ are displayed.
+
+EXAMPLES
+--------
+
+ $ git ls-remote --tags ./.
+ d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99
+ f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1
+ 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3
+ c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2
+ 0918385dbd9656cab0d1d81ba7453d49bbc16250 refs/tags/junio-gpg-pub
+ $ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc
+ 5fe978a5381f1fbad26a80e682ddd2a401966740 refs/heads/master
+ c781a84b5204fb294c9ccc79f8b3baceeb32c061 refs/heads/pu
+ b1d096f2926c4e37c9c0b6a7bf2119bedaa277cb refs/heads/rc
+ $ echo http://www.kernel.org/pub/scm/git/git.git >.git/branches/public
+ $ git ls-remote --tags public v\*
+ d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99
+ f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1
+ c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2
+ 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
new file mode 100644
index 0000000000..d9881fbbbe
--- /dev/null
+++ b/Documentation/git-ls-tree.txt
@@ -0,0 +1,94 @@
+git-ls-tree(1)
+==============
+
+NAME
+----
+git-ls-tree - List the contents of a tree object
+
+
+SYNOPSIS
+--------
+[verse]
+'git-ls-tree' [-d] [-r] [-t] [-l] [-z]
+ [--name-only] [--name-status] [--full-name] [--abbrev=[<n>]]
+ <tree-ish> [paths...]
+
+DESCRIPTION
+-----------
+Lists the contents of a given tree object, like what "/bin/ls -a" does
+in the current working directory. Note that the usage is subtly different,
+though - 'paths' denote just a list of patterns to match, e.g. so specifying
+directory name (without '-r') will behave differently, and order of the
+arguments does not matter.
+
+OPTIONS
+-------
+<tree-ish>::
+ Id of a tree-ish.
+
+-d::
+ Show only the named tree entry itself, not its children.
+
+-r::
+ Recurse into sub-trees.
+
+-t::
+ Show tree entries even when going to recurse them. Has no effect
+ if '-r' was not passed. '-d' implies '-t'.
+
+-l::
+--long::
+ Show object size of blob (file) entries.
+
+-z::
+ \0 line termination on output.
+
+--name-only::
+--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
+ implicitly uses the root level of the tree as the sole path argument.
+
+
+Output Format
+-------------
+ <mode> SP <type> SP <object> TAB <file>
+
+When the `-z` option is not used, TAB, LF, and backslash characters
+in pathnames are represented as `\t`, `\n`, and `\\`, respectively.
+
+When the `-l` option is used, format changes to
+
+ <mode> SP <type> SP <object> SP <object size> TAB <file>
+
+Object size identified by <object> is given in bytes, and right-justified
+with minimum width of 7 characters. Object size is given only for blobs
+(file) entries; for other entries `-` character is used in place of size.
+
+
+Author
+------
+Written by Petr Baudis <pasky@suse.cz>
+Completely rewritten from scratch by Junio C Hamano <junkio@cox.net>,
+another major rewrite by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list
+<git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
new file mode 100644
index 0000000000..183dc1dd75
--- /dev/null
+++ b/Documentation/git-mailinfo.txt
@@ -0,0 +1,69 @@
+git-mailinfo(1)
+===============
+
+NAME
+----
+git-mailinfo - Extracts patch and authorship from a single e-mail message
+
+
+SYNOPSIS
+--------
+'git-mailinfo' [-k] [-u | --encoding=<encoding>] <msg> <patch>
+
+
+DESCRIPTION
+-----------
+Reading a single e-mail message from the standard input, and
+writes the commit log message in <msg> file, and the patches in
+<patch> file. The author name, e-mail and e-mail subject are
+written out to the standard output to be used by git-am
+to create a commit. It is usually not necessary to use this
+command directly. See linkgit:git-am[1] instead.
+
+
+OPTIONS
+-------
+-k::
+ Usually the program 'cleans up' the Subject: header line
+ to extract the title line for the commit log message,
+ among which (1) remove 'Re:' or 're:', (2) leading
+ whitespaces, (3) '[' up to ']', typically '[PATCH]', and
+ then prepends "[PATCH] ". This flag forbids this
+ munging, and is most useful when used to read back 'git
+ format-patch -k' output.
+
+-u::
+ The commit log message, author name and author email are
+ taken from the e-mail, and after minimally decoding MIME
+ transfer encoding, re-coded in UTF-8 by transliterating
+ them. This used to be optional but now it is the default.
++
+Note that the patch is always used as-is without charset
+conversion, even with this flag.
+
+--encoding=<encoding>::
+ Similar to -u but if the local convention is different
+ from what is specified by i18n.commitencoding, this flag
+ can be used to override it.
+
+<msg>::
+ The commit log message extracted from e-mail, usually
+ except the title line which comes from e-mail Subject.
+
+<patch>::
+ The patch extracted from e-mail.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>
+
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-mailsplit.txt b/Documentation/git-mailsplit.txt
new file mode 100644
index 0000000000..9a2aedd480
--- /dev/null
+++ b/Documentation/git-mailsplit.txt
@@ -0,0 +1,58 @@
+git-mailsplit(1)
+================
+
+NAME
+----
+git-mailsplit - Simple UNIX mbox splitter program
+
+SYNOPSIS
+--------
+'git-mailsplit' [-b] [-f<nn>] [-d<prec>] -o<directory> [--] [<mbox>|<Maildir>...]
+
+DESCRIPTION
+-----------
+Splits a mbox file or a Maildir into a list of files: "0001" "0002" .. in the
+specified directory so you can process them further from there.
+
+IMPORTANT: Maildir splitting relies upon filenames being sorted to output
+patches in the correct order.
+
+OPTIONS
+-------
+<mbox>::
+ Mbox file to split. If not given, the mbox is read from
+ the standard input.
+
+<Maildir>::
+ Root of the Maildir to split. This directory should contain the cur, tmp
+ and new subdirectories.
+
+-o<directory>::
+ Directory in which to place the individual messages.
+
+-b::
+ If any file doesn't begin with a From line, assume it is a
+ single mail message instead of signaling error.
+
+-d<prec>::
+ Instead of the default 4 digits with leading zeros,
+ different precision can be specified for the generated
+ filenames.
+
+-f<nn>::
+ Skip the first <nn> numbers, for example if -f3 is specified,
+ start the numbering with 0004.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+and Junio C Hamano <junkio@cox.net>
+
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt
new file mode 100644
index 0000000000..bbe8512397
--- /dev/null
+++ b/Documentation/git-merge-base.txt
@@ -0,0 +1,42 @@
+git-merge-base(1)
+=================
+
+NAME
+----
+git-merge-base - Find as good common ancestors as possible for a merge
+
+
+SYNOPSIS
+--------
+'git-merge-base' [--all] <commit> <commit>
+
+DESCRIPTION
+-----------
+
+"git-merge-base" finds as good a common ancestor as possible between
+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
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt
new file mode 100644
index 0000000000..149f131051
--- /dev/null
+++ b/Documentation/git-merge-file.txt
@@ -0,0 +1,92 @@
+git-merge-file(1)
+=================
+
+NAME
+----
+git-merge-file - Run a three-way file merge
+
+
+SYNOPSIS
+--------
+[verse]
+'git-merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
+ [-p|--stdout] [-q|--quiet] <current-file> <base-file> <other-file>
+
+
+DESCRIPTION
+-----------
+git-file-merge incorporates all changes that lead from the `<base-file>`
+to `<other-file>` into `<current-file>`. The result ordinarily goes into
+`<current-file>`. git-merge-file is useful for combining separate changes
+to an original. Suppose `<base-file>` is the original, and both
+`<current-file>` and `<other-file>` are modifications of `<base-file>`.
+Then git-merge-file combines both changes.
+
+A conflict occurs if both `<current-file>` and `<other-file>` have changes
+in a common segment of lines. If a conflict is found, git-merge-file
+normally outputs a warning and brackets the conflict with <<<<<<< and
+>>>>>>> lines. A typical conflict will look like this:
+
+ <<<<<<< A
+ lines in file A
+ =======
+ lines in file B
+ >>>>>>> B
+
+If there are conflicts, the user should edit the result and delete one of
+the alternatives.
+
+The exit value of this program is negative on error, and the number of
+conflicts otherwise. If the merge was clean, the exit value is 0.
+
+git-merge-file is designed to be a minimal clone of RCS merge, that is, it
+implements all of RCS merge's functionality which is needed by
+linkgit:git[1].
+
+
+OPTIONS
+-------
+
+-L <label>::
+ This option may be given up to three times, and
+ specifies labels to be used in place of the
+ corresponding file names in conflict reports. That is,
+ `git-merge-file -L x -L y -L z a b c` generates output that
+ looks like it came from files x, y and z instead of
+ from files a, b and c.
+
+-p::
+ Send results to standard output instead of overwriting
+ `<current-file>`.
+
+-q::
+ Quiet; do not warn about conflicts.
+
+
+EXAMPLES
+--------
+
+git merge-file README.my README README.upstream::
+
+ combines the changes of README.my and README.upstream since README,
+ tries to merge them and writes the result into README.my.
+
+git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345::
+
+ merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels
+ `a` and `c` instead of `tmp/a123` and `tmp/c345`.
+
+
+Author
+------
+Written by Johannes Schindelin <johannes.schindelin@gmx.de>
+
+
+Documentation
+--------------
+Documentation by Johannes Schindelin and the git-list <git@vger.kernel.org>,
+with parts copied from the original documentation of RCS merge.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt
new file mode 100644
index 0000000000..a0ead2bbf3
--- /dev/null
+++ b/Documentation/git-merge-index.txt
@@ -0,0 +1,87 @@
+git-merge-index(1)
+==================
+
+NAME
+----
+git-merge-index - Run a merge for files needing merging
+
+
+SYNOPSIS
+--------
+'git-merge-index' [-o] [-q] <merge-program> (-a | [--] <file>\*)
+
+DESCRIPTION
+-----------
+This looks up the <file>(s) in the index and, if there are any merge
+entries, passes the SHA1 hash for those files as arguments 1, 2, 3 (empty
+argument if no file), and <file> as argument 4. File modes for the three
+files are passed as arguments 5, 6 and 7.
+
+OPTIONS
+-------
+\--::
+ Do not interpret any more arguments as options.
+
+-a::
+ Run merge against all files in the index that need merging.
+
+-o::
+ Instead of stopping at the first failed merge, do all of them
+ in one shot - continue with merging even when previous merges
+ returned errors, and only return the error code after all the
+ merges are over.
+
+-q::
+ Do not complain about failed merge program (the merge program
+ failure usually indicates conflicts during merge). This is for
+ porcelains which might want to emit custom messages.
+
+If "git-merge-index" is called with multiple <file>s (or -a) then it
+processes them in turn only stopping if merge returns a non-zero exit
+code.
+
+Typically this is run with a script calling git's imitation of
+the merge command from the RCS package.
+
+A sample script called "git-merge-one-file" is included in the
+distribution.
+
+ALERT ALERT ALERT! The git "merge object order" is different from the
+RCS "merge" program merge object order. In the above ordering, the
+original is first. But the argument order to the 3-way merge program
+"merge" is to have the original in the middle. Don't ask me why.
+
+Examples:
+
+ torvalds@ppc970:~/merge-test> git-merge-index cat MM
+ This is MM from the original tree. # original
+ This is modified MM in the branch A. # merge1
+ This is modified MM in the branch B. # merge2
+ This is modified MM in the branch B. # current contents
+
+or
+
+ torvalds@ppc970:~/merge-test> git-merge-index cat AA MM
+ cat: : No such file or directory
+ This is added AA in the branch A.
+ This is added AA in the branch B.
+ This is added AA in the branch B.
+ fatal: merge program failed
+
+where the latter example shows how "git-merge-index" will stop trying to
+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).
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+One-shot merge by Petr Baudis <pasky@ucw.cz>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-merge-one-file.txt b/Documentation/git-merge-one-file.txt
new file mode 100644
index 0000000000..5c9ce641ec
--- /dev/null
+++ b/Documentation/git-merge-one-file.txt
@@ -0,0 +1,29 @@
+git-merge-one-file(1)
+=====================
+
+NAME
+----
+git-merge-one-file - The standard helper program to use with git-merge-index
+
+
+SYNOPSIS
+--------
+'git-merge-one-file'
+
+DESCRIPTION
+-----------
+This is the standard helper program to use with "git-merge-index"
+to resolve a merge after the trivial merge done with "git-read-tree -m".
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>,
+Junio C Hamano <junkio@cox.net> and Petr Baudis <pasky@suse.cz>.
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-merge-tree.txt b/Documentation/git-merge-tree.txt
new file mode 100644
index 0000000000..b785e0f6e0
--- /dev/null
+++ b/Documentation/git-merge-tree.txt
@@ -0,0 +1,36 @@
+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 linkgit:git[1] suite
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
new file mode 100644
index 0000000000..55bc367479
--- /dev/null
+++ b/Documentation/git-merge.txt
@@ -0,0 +1,171 @@
+git-merge(1)
+============
+
+NAME
+----
+git-merge - Join two or more development histories together
+
+
+SYNOPSIS
+--------
+[verse]
+'git-merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
+ [-m <msg>] <remote> <remote>...
+'git-merge' <msg> HEAD <remote>...
+
+DESCRIPTION
+-----------
+This is the top-level interface to the merge machinery
+which drives multiple merge strategy scripts.
+
+The second syntax (<msg> `HEAD` <remote>) is supported for
+historical reasons. Do not use it from the command line or in
+new scripts. It is the same as `git merge -m <msg> <remote>`.
+
+
+OPTIONS
+-------
+include::merge-options.txt[]
+
+-m <msg>::
+ The commit message to be used for the merge commit (in case
+ it is created). The `git-fmt-merge-msg` script can be used
+ to give a good default for automated `git-merge` invocations.
+
+<remote>::
+ Other branch head merged into our branch. You need at
+ least one <remote>. Specifying more than one <remote>
+ obviously means you are trying an Octopus.
+
+include::merge-strategies.txt[]
+
+
+If you tried a merge which resulted in a complex conflicts and
+would want to start over, you can recover with
+linkgit:git-reset[1].
+
+CONFIGURATION
+-------------
+include::merge-config.txt[]
+
+branch.<name>.mergeoptions::
+ Sets default options for merging into branch <name>. The syntax and
+ supported options are equal to that of git-merge, but option values
+ containing whitespace characters are currently not supported.
+
+HOW MERGE WORKS
+---------------
+
+A merge is always between the current `HEAD` and one or more
+commits (usually, branch head or tag), and the index file must
+exactly match the
+tree of `HEAD` commit (i.e. the contents of the last commit) when
+it happens. In other words, `git-diff --cached HEAD` must
+report no changes.
+
+[NOTE]
+This is a bit of a lie. In certain special cases, your index is
+allowed to be different from the tree of the `HEAD` commit. The most
+notable case is when your `HEAD` commit is already ahead of what
+is being merged, in which case your index can have arbitrary
+differences from your `HEAD` commit. Also, your index entries
+may have differences from your `HEAD` commit that match
+the result of a trivial merge (e.g. you received the same patch
+from an external source to produce the same result as what you are
+merging). For example, if a path did not exist in the common
+ancestor and your head commit but exists in the tree you are
+merging into your repository, and if you already happen to have
+that path exactly in your index, the merge does not have to
+fail.
+
+Otherwise, merge will refuse to do any harm to your repository
+(that is, it may fetch the objects from remote, and it may even
+update the local branch used to keep track of the remote branch
+with `git pull remote rbranch:lbranch`, but your working tree,
+`.git/HEAD` pointer and index file are left intact).
+
+You may have local modifications in the working tree files. In
+other words, `git-diff` is allowed to report changes.
+However, the merge uses your working tree as the working area,
+and in order to prevent the merge operation from losing such
+changes, it makes sure that they do not interfere with the
+merge. Those complex tables in read-tree documentation define
+what it means for a path to "interfere with the merge". And if
+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 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.
+
+When things cleanly merge, these things happen:
+
+1. The results are updated both in the index file and in your
+ working tree;
+2. Index file is written out as a tree;
+3. The tree gets committed; and
+4. The `HEAD` pointer gets advanced.
+
+Because of 2., we require that the original state of the index
+file to match exactly the current `HEAD` commit; otherwise we
+will write out your local changes already registered in your
+index file along with the merge result, which is not good.
+Because 1. involves only the paths different between your
+branch and the remote branch you are pulling from during the
+merge (which is typically a fraction of the whole tree), you can
+have local modifications in your working tree as long as they do
+not overlap with what the merge updates.
+
+When there are conflicts, these things happen:
+
+1. `HEAD` stays the same.
+
+2. Cleanly merged paths are updated both in the index file and
+ in your working tree.
+
+3. For conflicting paths, the index file records up to three
+ versions; stage1 stores the version from the common ancestor,
+ stage2 from `HEAD`, and stage3 from the remote branch (you
+ can inspect the stages with `git-ls-files -u`). The working
+ tree files have the result of "merge" program; i.e. 3-way
+ merge result with familiar conflict markers `<<< === >>>`.
+
+4. No other changes are done. In particular, the local
+ modifications you had before you started merge will stay the
+ same and the index entries for them stay as they were,
+ i.e. matching `HEAD`.
+
+After seeing a conflict, you can do two things:
+
+ * Decide not to merge. The only clean-up you need are to reset
+ the index file to the `HEAD` commit to reverse 2. and to clean
+ up working tree changes made by 2. and 3.; `git-reset` can
+ be used for this.
+
+ * Resolve the conflicts. `git-diff` would report only the
+ conflicting paths because of the above 2. and 3.. Edit the
+ working tree files into a desirable shape, `git-add` or `git-rm`
+ them, to make the index file contain what the merge result
+ should be, and run `git-commit` to commit the result.
+
+
+SEE ALSO
+--------
+linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1],
+linkgit:gitattributes[5]
+
+
+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 linkgit:git[1] suite
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
new file mode 100644
index 0000000000..83525609c6
--- /dev/null
+++ b/Documentation/git-mergetool.txt
@@ -0,0 +1,73 @@
+git-mergetool(1)
+================
+
+NAME
+----
+git-mergetool - Run merge conflict resolution tools to resolve merge conflicts
+
+SYNOPSIS
+--------
+'git-mergetool' [--tool=<tool>] [<file>]...
+
+DESCRIPTION
+-----------
+
+Use `git mergetool` to run one of several merge utilities to resolve
+merge conflicts. It is typically run after linkgit:git-merge[1].
+
+If one or more <file> parameters are given, the merge tool program will
+be run to resolve differences on each file. If no <file> names are
+specified, `git mergetool` will run the merge tool program on every file
+with merge conflicts.
+
+OPTIONS
+-------
+-t or --tool=<tool>::
+ Use the merge resolution program specified by <tool>.
+ Valid merge tools are:
+ kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
++
+If a merge resolution program is not specified, `git mergetool`
+will use the configuration variable `merge.tool`. If the
+configuration variable `merge.tool` is not set, `git mergetool`
+will pick a suitable default.
++
+You can explicitly provide a full path to the tool by setting the
+configuration variable `mergetool.<tool>.path`. For example, you
+can configure the absolute path to kdiff3 by setting
+`mergetool.kdiff3.path`. Otherwise, `git mergetool` assumes the
+tool is available in PATH.
++
+Instead of running one of the known merge tool programs
+`git mergetool` can be customized to run an alternative program
+by specifying the command line to invoke in a configration
+variable `mergetool.<tool>.cmd`.
++
+When `git mergetool` is invoked with this tool (either through the
+`-t` or `--tool` option or the `merge.tool` configuration
+variable) the configured command line will be invoked with `$BASE`
+set to the name of a temporary file containing the common base for
+the merge, if available; `$LOCAL` set to the name of a temporary
+file containing the contents of the file on the current branch;
+`$REMOTE` set to the name of a temporary file containing the
+contents of the file to be merged, and `$MERGED` set to the name
+of the file to which the merge tool should write the result of the
+merge resolution.
++
+If the custom merge tool correctly indicates the success of a
+merge resolution with its exit code then the configuration
+variable `mergetool.<tool>.trustExitCode` can be set to `true`.
+Otherwise, `git mergetool` will prompt the user to indicate the
+success of the resolution after the custom tool has exited.
+
+Author
+------
+Written by Theodore Y Ts'o <tytso@mit.edu>
+
+Documentation
+--------------
+Documentation by Theodore Y Ts'o.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-mktag.txt b/Documentation/git-mktag.txt
new file mode 100644
index 0000000000..232bc1a338
--- /dev/null
+++ b/Documentation/git-mktag.txt
@@ -0,0 +1,46 @@
+git-mktag(1)
+============
+
+NAME
+----
+git-mktag - Creates a tag object
+
+
+SYNOPSIS
+--------
+'git-mktag' < signature_file
+
+DESCRIPTION
+-----------
+Reads a tag contents on standard input and creates a tag object
+that can also be used to sign other objects.
+
+The output is the new tag's <object> identifier.
+
+Tag Format
+----------
+A tag signature file has a very simple fixed format: four lines of
+
+ object <sha1>
+ type <typename>
+ tag <tagname>
+ tagger <tagger>
+
+followed by some 'optional' free-form message (some tags created
+by older git may not have `tagger` line). The message, when
+exists, is separated by a blank line from the header. The
+message part may contain a signature that git itself doesn't
+care about, but that can be verified with gpg.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-mktree.txt b/Documentation/git-mktree.txt
new file mode 100644
index 0000000000..1ddbf00afc
--- /dev/null
+++ b/Documentation/git-mktree.txt
@@ -0,0 +1,34 @@
+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 linkgit:git[1] suite
diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt
new file mode 100644
index 0000000000..339190600a
--- /dev/null
+++ b/Documentation/git-mv.txt
@@ -0,0 +1,54 @@
+git-mv(1)
+=========
+
+NAME
+----
+git-mv - Move or rename a file, a directory, or a symlink
+
+
+SYNOPSIS
+--------
+'git-mv' <options>... <args>...
+
+DESCRIPTION
+-----------
+This script is used to move or rename a file, directory or symlink.
+
+ git-mv [-f] [-n] <source> <destination>
+ git-mv [-f] [-n] [-k] <source> ... <destination directory>
+
+In the first form, it renames <source>, which must exist and be either
+a file, symlink or directory, to <destination>.
+In the second form, the last argument has to be an existing
+directory; the given sources will be moved into this directory.
+
+The index is updated after successful completion, but the change must still be
+committed.
+
+OPTIONS
+-------
+-f::
+ Force renaming or moving of a file even if the target exists
+-k::
+ Skip move or rename actions which would lead to an error
+ condition. An error happens when a source is neither existing nor
+ controlled by GIT, or when it would overwrite an existing
+ file unless '-f' is given.
+-n::
+--dry-run::
+ Do nothing; only show what would happen
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+Rewritten by Ryan Anderson <ryan@michonline.com>
+Move functionality added by Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
new file mode 100644
index 0000000000..ffac3f8f56
--- /dev/null
+++ b/Documentation/git-name-rev.txt
@@ -0,0 +1,85 @@
+git-name-rev(1)
+===============
+
+NAME
+----
+git-name-rev - Find symbolic names for given revs
+
+
+SYNOPSIS
+--------
+[verse]
+'git-name-rev' [--tags] [--refs=<pattern>]
+ ( --all | --stdin | <committish>... )
+
+DESCRIPTION
+-----------
+Finds symbolic names suitable for human digestion for revisions given in any
+format parsable by git-rev-parse.
+
+
+OPTIONS
+-------
+
+--tags::
+ Do not use branch names, but only tags to name the commits
+
+--refs=<pattern>::
+ Only use refs whose names match a given shell pattern.
+
+--all::
+ List all commits reachable from all refs
+
+--stdin::
+ Read from stdin, append "(<rev_name>)" to all sha1's of nameable
+ commits, and pass to stdout
+
+--name-only::
+ Instead of printing both the SHA-1 and the name, print only
+ the name. If given with --tags the usual tag prefix of
+ "tags/" is also omitted from the name, matching the output
+ of linkgit:git-describe[1] more closely. This option
+ cannot be combined with --stdin.
+
+--no-undefined::
+ Die with error code != 0 when a reference is undefined,
+ instead of printing `undefined`.
+
+--always::
+ Show uniquely abbreviated commit object as fallback.
+
+EXAMPLE
+-------
+
+Given a commit, find out where it is relative to the local refs. Say somebody
+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.
+
+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.
+
+Another nice thing you can do is:
+
+------------
+% git log | git name-rev --stdin
+------------
+
+
+Author
+------
+Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
+
+Documentation
+--------------
+Documentation by Johannes Schindelin.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
new file mode 100644
index 0000000000..f4d8d68e34
--- /dev/null
+++ b/Documentation/git-pack-objects.txt
@@ -0,0 +1,212 @@
+git-pack-objects(1)
+===================
+
+NAME
+----
+git-pack-objects - Create a packed archive of objects
+
+
+SYNOPSIS
+--------
+[verse]
+'git-pack-objects' [-q] [--no-reuse-delta] [--delta-base-offset] [--non-empty]
+ [--local] [--incremental] [--window=N] [--depth=N] [--all-progress]
+ [--revs [--unpacked | --all]*] [--stdout | base-name] < object-list
+
+
+DESCRIPTION
+-----------
+Reads list of objects from the standard input, and writes a packed
+archive with specified base-name, or to the standard output.
+
+A packed archive is an efficient way to transfer set of objects
+between two repositories, and also is an archival format which
+is efficient to access. The packed archive format (.pack) is
+designed to be self contained so that it can be unpacked without
+any further information, but for fast, random access to the objects
+in the pack, a pack index file (.idx) will be generated.
+
+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.
+
+'git-unpack-objects' command can read the packed archive and
+expand the objects contained in the pack into "one-file
+one-object" format; this is typically done by the smart-pull
+commands when a pack is created on-the-fly for efficient network
+transport by their peers.
+
+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
+-------
+base-name::
+ Write into a pair of files (.pack and .idx), using
+ <base-name> to determine the name of the created file.
+ When this option is used, the two files are written in
+ <base-name>-<SHA1>.{pack,idx} files. <SHA1> is a hash
+ of the sorted object names to make the resulting filename
+ based on the pack content, and written to the standard
+ output of the command.
+
+--stdout::
+ Write the pack contents (what would have been written to
+ .pack file) out to the standard output.
+
+--revs::
+ Read the revision arguments from the standard input, instead of
+ individual object names. The revision arguments are processed
+ the same way as linkgit:git-rev-list[1] with `--objects` flag
+ uses its `commit` arguments to build the list of objects it
+ outputs. The objects on the resulting list are packed.
+
+--unpacked::
+ This implies `--revs`. When processing the list of
+ revision arguments read from the standard input, limit
+ the objects packed to those that are not already packed.
+
+--all::
+ This implies `--revs`. In addition to the list of
+ revision arguments read from the standard input, pretend
+ as if all refs under `$GIT_DIR/refs` are specified to be
+ included.
+
+--include-tag::
+ Include unasked-for annotated tags if the object they
+ reference was included in the resulting packfile. This
+ can be useful to send new tags to native git clients.
+
+--window=[N]::
+--depth=[N]::
+ These two options affect how the objects contained in
+ the pack are stored using delta compression. The
+ objects are first internally sorted by type, size and
+ optionally names and compared against the other objects
+ within --window to see if using delta compression saves
+ space. --depth limits the maximum delta depth; making
+ it too deep affects the performance on the unpacker
+ side, because delta data needs to be applied that many
+ times to get to the necessary object.
+ The default value for --window is 10 and --depth is 50.
+
+--window-memory=[N]::
+ This option provides an additional limit on top of `--window`;
+ the window size will dynamically scale down so as to not take
+ up more than N bytes in memory. This is useful in
+ repositories with a mix of large and small objects to not run
+ out of memory with a large window, but still be able to take
+ advantage of the large window for the smaller objects. The
+ size can be suffixed with "k", "m", or "g".
+ `--window-memory=0` makes memory usage unlimited, which is the
+ default.
+
+--max-pack-size=<n>::
+ Maximum size of each output packfile, expressed in MiB.
+ If specified, multiple packfiles may be created.
+ The default is unlimited, unless the config variable
+ `pack.packSizeLimit` is set.
+
+--incremental::
+ This flag causes an object already in a pack ignored
+ even if it appears in the standard input.
+
+--local::
+ This flag is similar to `--incremental`; instead of
+ ignoring all packed objects, it only ignores objects
+ that are packed and not in the local object store
+ (i.e. borrowed from an alternate).
+
+--non-empty::
+ Only create a packed archive if it would contain at
+ least one object.
+
+--progress::
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless -q
+ is specified. This flag forces progress status even if
+ the standard error stream is not directed to a terminal.
+
+--all-progress::
+ When --stdout is specified then progress report is
+ displayed during the object count and deltification phases
+ but inhibited during the write-out phase. The reason is
+ that in some cases the output stream is directly linked
+ to another command which may wish to display progress
+ status of its own as it processes incoming pack data.
+ This flag is like --progress except that it forces progress
+ report for the write-out phase as well even if --stdout is
+ used.
+
+-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.
+
+--no-reuse-object::
+ This flag tells the command not to reuse existing object data at all,
+ including non deltified object, forcing recompression of everything.
+ This implies --no-reuse-delta. Useful only in the obscure case where
+ wholesale enforcement of a different compression level on the
+ packed data is desired.
+
+--compression=[N]::
+ Specifies compression level for newly-compressed data in the
+ generated pack. If not specified, pack compression level is
+ determined first by pack.compression, then by core.compression,
+ and defaults to -1, the zlib default, if neither is set.
+ Add \--no-reuse-object if you want to force a uniform compression
+ level on all data no matter the source.
+
+--delta-base-offset::
+ A packed archive can express base object of a delta as
+ either 20-byte object name or as an offset in the
+ stream, but older version of git does not understand the
+ latter. By default, git-pack-objects only uses the
+ former format for better compatibility. This option
+ allows the command to use the latter format for
+ compactness. Depending on the average delta chain
+ length, this option typically shrinks the resulting
+ packfile by 3-5 per-cent.
+
+--threads=<n>::
+ Specifies the number of threads to spawn when searching for best
+ delta matches. This requires that pack-objects be compiled with
+ pthreads otherwise this option is ignored with a warning.
+ This is meant to reduce packing time on multiprocessor machines.
+ The required amount of memory for the delta search window is
+ however multiplied by the number of threads.
+ Specifying 0 will cause git to auto-detect the number of CPU's
+ and set the number of threads accordingly.
+
+--index-version=<version>[,<offset>]::
+ This is intended to be used by the test suite only. It allows
+ to force the version for the generated pack index, and to force
+ 64-bit index entries on objects located above the given offset.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+-------------
+Documentation by Junio C Hamano
+
+SEE ALSO
+--------
+linkgit:git-rev-list[1]
+linkgit:git-repack[1]
+linkgit:git-prune-packed[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-pack-redundant.txt b/Documentation/git-pack-redundant.txt
new file mode 100644
index 0000000000..6737326f0b
--- /dev/null
+++ b/Documentation/git-pack-redundant.txt
@@ -0,0 +1,57 @@
+git-pack-redundant(1)
+=====================
+
+NAME
+----
+git-pack-redundant - Find redundant pack files
+
+
+SYNOPSIS
+--------
+'git-pack-redundant' [ --verbose ] [ --alt-odb ] < --all | .pack filename ... >
+
+DESCRIPTION
+-----------
+This program computes which packs in your repository
+are redundant. The output is suitable for piping to
+'xargs rm' if you are in the root of the repository.
+
+git-pack-redundant accepts a list of objects on standard input. Any objects
+given will be ignored when checking which packs are required. This makes the
+following command useful when wanting to remove packs which contain unreachable
+objects.
+
+git-fsck --full --unreachable | cut -d ' ' -f3 | \
+git-pack-redundant --all | xargs rm
+
+OPTIONS
+-------
+
+
+--all::
+ Processes all packs. Any filenames on the command line are ignored.
+
+--alt-odb::
+ Don't require objects present in packs from alternate object
+ directories to be present in local packs.
+
+--verbose::
+ Outputs some statistics to stderr. Has a small performance penalty.
+
+Author
+------
+Written by Lukas Sandström <lukass@etek.chalmers.se>
+
+Documentation
+--------------
+Documentation by Lukas Sandström <lukass@etek.chalmers.se>
+
+SEE ALSO
+--------
+linkgit:git-pack-objects[1]
+linkgit:git-repack[1]
+linkgit:git-prune-packed[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-pack-refs.txt b/Documentation/git-pack-refs.txt
new file mode 100644
index 0000000000..c0718468d5
--- /dev/null
+++ b/Documentation/git-pack-refs.txt
@@ -0,0 +1,66 @@
+git-pack-refs(1)
+================
+
+NAME
+----
+git-pack-refs - Pack heads and tags for efficient repository access
+
+SYNOPSIS
+--------
+'git-pack-refs' [--all] [--no-prune]
+
+DESCRIPTION
+-----------
+
+Traditionally, tips of branches and tags (collectively known as
+'refs') were stored one file per ref under `$GIT_DIR/refs`
+directory. While many branch tips tend to be updated often,
+most tags and some branch tips are never updated. When a
+repository has hundreds or thousands of tags, this
+one-file-per-ref format both wastes storage and hurts
+performance.
+
+This command is used to solve the storage and performance
+problem by stashing the refs in a single file,
+`$GIT_DIR/packed-refs`. When a ref is missing from the
+traditional `$GIT_DIR/refs` hierarchy, it is looked up in this
+file and used if found.
+
+Subsequent updates to branches always creates new file under
+`$GIT_DIR/refs` hierarchy.
+
+A recommended practice to deal with a repository with too many
+refs is to pack its refs with `--all --prune` once, and
+occasionally run `git-pack-refs \--prune`. Tags are by
+definition stationary and are not expected to change. Branch
+heads will be packed with the initial `pack-refs --all`, but
+only the currently active branch heads will become unpacked,
+and next `pack-refs` (without `--all`) will leave them
+unpacked.
+
+
+OPTIONS
+-------
+
+--all::
+
+The command by default packs all tags and refs that are already
+packed, and leaves other refs
+alone. This is because branches are expected to be actively
+developed and packing their tips does not help performance.
+This option causes branch tips to be packed as well. Useful for
+a repository with many branches of historical interests.
+
+--no-prune::
+
+The command usually removes loose refs under `$GIT_DIR/refs`
+hierarchy after packing them. This option tells it not to.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-parse-remote.txt b/Documentation/git-parse-remote.txt
new file mode 100644
index 0000000000..951dbd6c83
--- /dev/null
+++ b/Documentation/git-parse-remote.txt
@@ -0,0 +1,50 @@
+git-parse-remote(1)
+===================
+
+NAME
+----
+git-parse-remote - Routines to help parsing remote repository access parameters
+
+
+SYNOPSIS
+--------
+'. git-parse-remote'
+
+DESCRIPTION
+-----------
+This script is included in various scripts to supply
+routines to parse files under $GIT_DIR/remotes/ and
+$GIT_DIR/branches/ and configuration variables that are related
+to fetching, pulling and pushing.
+
+The primary entry points are:
+
+get_remote_refs_for_fetch::
+ Given the list of user-supplied `<repo> <refspec>...`,
+ return the list of refs to fetch after canonicalizing
+ them into `$GIT_DIR` relative paths
+ (e.g. `refs/heads/foo`). When `<refspec>...` is empty
+ the returned list of refs consists of the defaults
+ for the given `<repo>`, if specified in
+ `$GIT_DIR/remotes/`, `$GIT_DIR/branches/`, or `remote.*.fetch`
+ configuration.
+
+get_remote_refs_for_push::
+ Given the list of user-supplied `<repo> <refspec>...`,
+ return the list of refs to push in a form suitable to be
+ fed to the `git-send-pack` command. When `<refspec>...`
+ is empty the returned list of refs consists of the
+ defaults for the given `<repo>`, if specified in
+ `$GIT_DIR/remotes/`.
+
+Author
+------
+Written by Junio C Hamano.
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-patch-id.txt b/Documentation/git-patch-id.txt
new file mode 100644
index 0000000000..bb8a079254
--- /dev/null
+++ b/Documentation/git-patch-id.txt
@@ -0,0 +1,42 @@
+git-patch-id(1)
+===============
+
+NAME
+----
+git-patch-id - Compute unique ID for a patch
+
+SYNOPSIS
+--------
+'git-patch-id' < <patch>
+
+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, 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.
+
+When dealing with git-diff-tree output, it takes advantage of
+the fact that the patch is prefixed with the object name of the
+commit, and outputs two 40-byte hexadecimal string. The first
+string is the patch ID, and the second string is the commit ID.
+This can be used to make a mapping from patch ID to commit ID.
+
+OPTIONS
+-------
+<patch>::
+ The diff to create the ID of.
+
+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 linkgit:git[1] suite
diff --git a/Documentation/git-peek-remote.txt b/Documentation/git-peek-remote.txt
new file mode 100644
index 0000000000..ffbf93a799
--- /dev/null
+++ b/Documentation/git-peek-remote.txt
@@ -0,0 +1,50 @@
+git-peek-remote(1)
+==================
+
+NAME
+----
+git-peek-remote - List the references in a remote repository
+
+
+SYNOPSIS
+--------
+'git-peek-remote' [--upload-pack=<git-upload-pack>] [<host>:]<directory>
+
+DESCRIPTION
+-----------
+This command is deprecated; use `git-ls-remote` instead.
+
+OPTIONS
+-------
+--upload-pack=<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. Some
+ installations of sshd ignores 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, but prefer 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.
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-prune-packed.txt b/Documentation/git-prune-packed.txt
new file mode 100644
index 0000000000..f330b8a5b9
--- /dev/null
+++ b/Documentation/git-prune-packed.txt
@@ -0,0 +1,52 @@
+git-prune-packed(1)
+=====================
+
+NAME
+----
+git-prune-packed - Remove extra objects that are already in pack files
+
+
+SYNOPSIS
+--------
+'git-prune-packed' [-n] [-q]
+
+
+DESCRIPTION
+-----------
+This program searches the `$GIT_OBJECT_DIR` for all objects that currently
+exist in a pack file as well as the independent object directories.
+
+All such extra objects are removed.
+
+A pack is a collection of objects, individually compressed, with delta
+compression applied, stored in a single file, with an associated index file.
+
+Packs are used to reduce the load on mirror systems, backup engines,
+disk storage, etc.
+
+
+OPTIONS
+-------
+-n::
+ Don't actually remove any objects, only show those that would have been
+ removed.
+
+-q::
+ Squelch the progress indicator.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Ryan Anderson <ryan@michonline.com>
+
+SEE ALSO
+--------
+linkgit:git-pack-objects[1]
+linkgit:git-repack[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt
new file mode 100644
index 0000000000..ec335d6fab
--- /dev/null
+++ b/Documentation/git-prune.txt
@@ -0,0 +1,86 @@
+git-prune(1)
+============
+
+NAME
+----
+git-prune - Prune all unreachable objects from the object database
+
+
+SYNOPSIS
+--------
+'git-prune' [-n] [--expire <expire>] [--] [<head>...]
+
+DESCRIPTION
+-----------
+
+NOTE: In most cases, users should run linkgit:git-gc[1], which calls
+git-prune. See the section "NOTES", below.
+
+This runs `git-fsck --unreachable` using all the refs
+available in `$GIT_DIR/refs`, optionally with additional set of
+objects specified on the command line, and prunes all unpacked
+objects unreachable from any of these head objects from the object database.
+In addition, it
+prunes the unpacked objects that are also found in packs by
+running `git prune-packed`.
+
+Note that unreachable, packed objects will remain. If this is
+not desired, see linkgit:git-repack[1].
+
+OPTIONS
+-------
+
+-n::
+ Do not remove anything; just report what it would
+ remove.
+
+\--::
+ Do not interpret any more arguments as options.
+
+--expire <time>::
+ Only expire loose objects older than <time>.
+
+<head>...::
+ In addition to objects
+ reachable from any of our references, keep objects
+ reachable from listed <head>s.
+
+EXAMPLE
+-------
+
+To prune objects not used by your repository nor another that
+borrows from your repository via its
+`.git/objects/info/alternates`:
+
+------------
+$ git prune $(cd ../another && $(git-rev-parse --all))
+------------
+
+Notes
+-----
+
+In most cases, users will not need to call git-prune directly, but
+should instead call linkgit:git-gc[1], which handles pruning along with
+many other housekeeping tasks.
+
+For a description of which objects are considered for pruning, see
+git-fsck's --unreachable option.
+
+SEE ALSO
+--------
+
+linkgit:git-fsck[1],
+linkgit:git-gc[1],
+linkgit:git-reflog[1]
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
new file mode 100644
index 0000000000..5f55f6494a
--- /dev/null
+++ b/Documentation/git-pull.txt
@@ -0,0 +1,206 @@
+git-pull(1)
+===========
+
+NAME
+----
+git-pull - Fetch from and merge with another repository or a local branch
+
+
+SYNOPSIS
+--------
+'git-pull' <options> <repository> <refspec>...
+
+
+DESCRIPTION
+-----------
+Runs `git-fetch` with the given parameters, and calls `git-merge`
+to merge the retrieved head(s) into the current branch.
+With `--rebase`, calls `git-rebase` instead of `git-merge`.
+
+Note that you can use `.` (current directory) as the
+<repository> to pull from the local repository -- this is useful
+when merging local branches into the current branch.
+
+Also note that options meant for `git-pull` itself and underlying
+`git-merge` must be given before the options meant for `git-fetch`.
+
+OPTIONS
+-------
+include::merge-options.txt[]
+
+:git-pull: 1
+
+--rebase::
+ Instead of a merge, perform a rebase after fetching. If
+ there is a remote ref for the upstream branch, and this branch
+ was rebased since last fetched, the rebase uses that information
+ to avoid rebasing non-local changes. To make this the default
+ for branch `<name>`, set configuration `branch.<name>.rebase`
+ to `true`.
++
+*NOTE:* This is a potentially _dangerous_ mode of operation.
+It rewrites history, which does not bode well when you
+published that history already. Do *not* use this option
+unless you have read linkgit:git-rebase[1] carefully.
+
+--no-rebase::
+ Override earlier --rebase.
+
+include::fetch-options.txt[]
+
+include::pull-fetch-param.txt[]
+
+include::urls-remotes.txt[]
+
+include::merge-strategies.txt[]
+
+DEFAULT BEHAVIOUR
+-----------------
+
+Often people use `git pull` without giving any parameter.
+Traditionally, this has been equivalent to saying `git pull
+origin`. However, when configuration `branch.<name>.remote` is
+present while on branch `<name>`, that value is used instead of
+`origin`.
+
+In order to determine what URL to use to fetch from, the value
+of the configuration `remote.<origin>.url` is consulted
+and if there is not any such variable, the value on `URL: ` line
+in `$GIT_DIR/remotes/<origin>` file is used.
+
+In order to determine what remote branches to fetch (and
+optionally store in the tracking branches) when the command is
+run without any refspec parameters on the command line, values
+of the configuration variable `remote.<origin>.fetch` are
+consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>`
+file is consulted and its `Pull: ` lines are used.
+In addition to the refspec formats described in the OPTIONS
+section, you can have a globbing refspec that looks like this:
+
+------------
+refs/heads/*:refs/remotes/origin/*
+------------
+
+A globbing refspec must have a non-empty RHS (i.e. must store
+what were fetched in tracking branches), and its LHS and RHS
+must end with `/*`. The above specifies that all remote
+branches are tracked using tracking branches in
+`refs/remotes/origin/` hierarchy under the same name.
+
+The rule to determine which remote branch to merge after
+fetching is a bit involved, in order not to break backward
+compatibility.
+
+If explicit refspecs were given on the command
+line of `git pull`, they are all merged.
+
+When no refspec was given on the command line, then `git pull`
+uses the refspec from the configuration or
+`$GIT_DIR/remotes/<origin>`. In such cases, the following
+rules apply:
+
+. If `branch.<name>.merge` configuration for the current
+ branch `<name>` exists, that is the name of the branch at the
+ remote site that is merged.
+
+. If the refspec is a globbing one, nothing is merged.
+
+. Otherwise the remote branch of the first refspec is merged.
+
+
+EXAMPLES
+--------
+
+* Update the remote-tracking branches for the repository
+ you cloned from, then merge one of them into your
+ current branch:
++
+------------------------------------------------
+$ git pull, git pull origin
+------------------------------------------------
++
+Normally the branch merged in is the HEAD of the remote repository,
+but the choice is determined by the branch.<name>.remote and
+branch.<name>.merge options; see linkgit:git-config[1] for details.
+
+* Merge into the current branch the remote branch `next`:
++
+------------------------------------------------
+$ git pull origin next
+------------------------------------------------
++
+This leaves a copy of `next` temporarily in FETCH_HEAD, but
+does not update any remote-tracking branches.
+
+* Bundle local branch `fixes` and `enhancements` on top of
+ the current branch, making an Octopus merge:
++
+------------------------------------------------
+$ git pull . fixes enhancements
+------------------------------------------------
++
+This `git pull .` syntax is equivalent to `git merge`.
+
+* Merge local branch `obsolete` into the current branch, using `ours`
+ merge strategy:
++
+------------------------------------------------
+$ git pull -s ours . obsolete
+------------------------------------------------
+
+* Merge local branch `maint` into the current branch, but do not make
+ a commit automatically:
++
+------------------------------------------------
+$ git pull --no-commit . maint
+------------------------------------------------
++
+This can be used when you want to include further changes to the
+merge, or want to write your own merge commit message.
++
+You should refrain from abusing this option to sneak substantial
+changes into a merge commit. Small fixups like bumping
+release/version name would be acceptable.
+
+* Command line pull of multiple branches from one repository:
++
+------------------------------------------------
+$ git checkout master
+$ git fetch origin +pu:pu maint:tmp
+$ git pull . tmp
+------------------------------------------------
++
+This updates (or creates, as necessary) branches `pu` and `tmp` in
+the local repository by fetching from the branches (respectively)
+`pu` and `maint` from the remote repository.
++
+The `pu` branch will be updated even if it is does not fast-forward;
+the others will not be.
++
+The final command then merges the newly fetched `tmp` into master.
+
+
+If you tried a pull which resulted in a complex conflicts and
+would want to start over, you can recover with
+linkgit:git-reset[1].
+
+
+SEE ALSO
+--------
+linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-config[1]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+and Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Jon Loeliger,
+David Greaves,
+Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
new file mode 100644
index 0000000000..89e0049bce
--- /dev/null
+++ b/Documentation/git-push.txt
@@ -0,0 +1,206 @@
+git-push(1)
+===========
+
+NAME
+----
+git-push - Update remote refs along with associated objects
+
+
+SYNOPSIS
+--------
+[verse]
+'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
+ [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
+
+DESCRIPTION
+-----------
+
+Updates remote refs using local refs, while sending objects
+necessary to complete the given refs.
+
+You can make interesting things happen to a repository
+every time you push into it, by setting up 'hooks' there. See
+documentation for linkgit:git-receive-pack[1].
+
+
+OPTIONS
+-------
+<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 represents the source branch (or arbitrary
+"SHA1 expression", such as `master~4` (four parents before the
+tip of `master` branch); see linkgit:git-rev-parse[1]) that you
+want to push. The <dst> side represents the destination location.
++
+The local ref that matches <src> is used
+to fast forward the remote ref that matches <dst> (or, if no <dst> was
+specified, the same ref that <src> referred to locally). If
+the optional leading plus `+` is used, the remote ref is updated
+even if it does not result in a fast forward update.
++
+`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
++
+A parameter <ref> without a colon pushes the <ref> from the source
+repository to the destination repository under the same name.
++
+Pushing an empty <src> allows you to delete the <dst> ref from
+the remote repository.
++
+The special refspec `:` (or `+:` to allow non-fast forward updates)
+directs git to push "matching" heads: for every head that exists on
+the local side, the remote side is updated if a head of the same name
+already exists on the remote side. This is the default operation mode
+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).
+
+--all::
+ Instead of naming each ref to push, specifies that all
+ refs under `$GIT_DIR/refs/heads/` be pushed.
+
+--mirror::
+ Instead of naming each ref to push, specifies that all
+ refs under `$GIT_DIR/refs/heads/` and `$GIT_DIR/refs/tags/`
+ be mirrored to the remote repository. Newly created local
+ refs will be pushed to the remote end, locally updated refs
+ will be force updated on the remote end, and deleted refs
+ will be removed from the remote end. This is the default
+ if the configuration option `remote.<remote>.mirror` is
+ set.
+
+--dry-run::
+ Do everything except actually send the updates.
+
+--tags::
+ All refs under `$GIT_DIR/refs/tags` are pushed, in
+ addition to refspecs explicitly listed on the command
+ line.
+
+--receive-pack=<git-receive-pack>::
+ Path to the 'git-receive-pack' program on the remote
+ end. Sometimes useful when pushing to a remote
+ repository over ssh, and you do not have the program in
+ a directory on the default $PATH.
+
+--exec=<git-receive-pack>::
+ Same as \--receive-pack=<git-receive-pack>.
+
+-f::
+--force::
+ Usually, the command refuses to update a remote ref that is
+ not an ancestor of the local ref used to overwrite it.
+ This flag disables the check. This can cause the
+ remote repository to lose commits; use it with care.
+
+--repo=<repo>::
+ When no repository is specified the command defaults to
+ "origin"; this overrides it.
+
+--thin::
+--no-thin::
+ These options are passed to `git-send-pack`. Thin
+ transfer spends extra cycles to minimize the number of
+ objects to be sent and meant to be used on slower connection.
+
+-v::
+--verbose::
+ Run verbosely.
+
+include::urls-remotes.txt[]
+
+OUTPUT
+------
+
+The output of "git push" depends on the transport method used; this
+section describes the output when pushing over the git protocol (either
+locally or via ssh).
+
+The status of the push is output in tabular form, with each line
+representing the status of a single ref. Each line is of the form:
+
+-------------------------------
+ <flag> <summary> <from> -> <to> (<reason>)
+-------------------------------
+
+flag::
+ A single character indicating the status of the ref. This is
+ blank for a successfully pushed ref, `!` for a ref that was
+ rejected or failed to push, and '=' for a ref that was up to
+ date and did not need pushing (note that the status of up to
+ date refs is shown only when `git push` is running verbosely).
+
+summary::
+ For a successfully pushed ref, the summary shows the old and new
+ values of the ref in a form suitable for using as an argument to
+ `git log` (this is `<old>..<new>` in most cases, and
+ `<old>...<new>` for forced non-fast forward updates). For a
+ failed update, more details are given for the failure.
+ The string `rejected` indicates that git did not try to send the
+ ref at all (typically because it is not a fast forward). The
+ string `remote rejected` indicates that the remote end refused
+ the update; this rejection is typically caused by a hook on the
+ remote side. The string `remote failure` indicates that the
+ remote end did not report the successful update of the ref
+ (perhaps because of a temporary error on the remote side, a
+ break in the network connection, or other transient error).
+
+from::
+ The name of the local ref being pushed, minus its
+ `refs/<type>/` prefix. In the case of deletion, the
+ name of the local ref is omitted.
+
+to::
+ The name of the remote ref being updated, minus its
+ `refs/<type>/` prefix.
+
+reason::
+ A human-readable explanation. In the case of successfully pushed
+ refs, no explanation is needed. For a failed ref, the reason for
+ failure is described.
+
+Examples
+--------
+
+git push origin master::
+ Find a ref that matches `master` in the source repository
+ (most likely, it would find `refs/heads/master`), and update
+ the same ref (e.g. `refs/heads/master`) in `origin` repository
+ with it. If `master` did not exist remotely, it would be
+ created.
+
+git push origin :experimental::
+ Find a ref that matches `experimental` in the `origin` repository
+ (e.g. `refs/heads/experimental`), and delete it.
+
+git push origin master:satellite/master::
+ Find a ref that matches `master` in the source repository
+ (most likely, it would find `refs/heads/master`), and update
+ the ref that matches `satellite/master` (most likely, it would
+ be `refs/remotes/satellite/master`) in `origin` repository with it.
+
+git push origin master:refs/heads/experimental::
+ Create the branch `experimental` in the `origin` repository
+ by copying the current `master` branch. This form is only
+ needed to create a new branch or tag in the remote repository when
+ the local name and the remote name are different; otherwise,
+ the ref name on its own will work.
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>, later rewritten in C
+by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-quiltimport.txt b/Documentation/git-quiltimport.txt
new file mode 100644
index 0000000000..0600379394
--- /dev/null
+++ b/Documentation/git-quiltimport.txt
@@ -0,0 +1,62 @@
+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
+-------
+
+-n::
+--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 linkgit:git[1] suite
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
new file mode 100644
index 0000000000..58fb906ef6
--- /dev/null
+++ b/Documentation/git-read-tree.txt
@@ -0,0 +1,367 @@
+git-read-tree(1)
+================
+
+NAME
+----
+git-read-tree - Reads tree information into the index
+
+
+SYNOPSIS
+--------
+'git-read-tree' (<tree-ish> | [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] [--exclude-per-directory=<gitignore>] [--index-output=<file>] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
+
+
+DESCRIPTION
+-----------
+Reads the tree information given by <tree-ish> into the index,
+but does not actually *update* any of the files it "caches". (see:
+linkgit:git-checkout-index[1])
+
+Optionally, it can merge a tree into the index, perform a
+fast-forward (i.e. 2-way) merge, or a 3-way merge, with the `-m`
+flag. When used with `-m`, the `-u` flag causes it to also update
+the files in the work tree with the result of the merge.
+
+Trivial merges are done by `git-read-tree` itself. Only conflicting paths
+will be in unmerged state when `git-read-tree` returns.
+
+OPTIONS
+-------
+-m::
+ Perform a merge, not just a read. The command will
+ refuse to run if your index file has unmerged entries,
+ indicating that you have not finished previous merge you
+ started.
+
+--reset::
+ Same as -m, except that unmerged entries are discarded
+ instead of failing.
+
+-u::
+ After a successful merge, update the files in the work
+ tree with the result of the merge.
+
+-i::
+ Usually a merge requires the index file as well as the
+ files in the working tree are up to date with the
+ current head commit, in order not to lose local
+ changes. This flag disables the check with the working
+ tree and is meant to be used when creating a merge of
+ trees that are not directly related to the current
+ working tree status into a temporary index file.
+
+-v::
+ Show the progress of checking files out.
+
+--trivial::
+ Restrict three-way merge by `git-read-tree` to happen
+ only if there is no file-level merging required, instead
+ of resolving merge for trivial cases and leaving
+ conflicting files unresolved in the index.
+
+--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.
+
+--exclude-per-directory=<gitignore>::
+ When running the command with `-u` and `-m` options, the
+ merge result may need to overwrite paths that are not
+ tracked in the current branch. The command usually
+ refuses to proceed with the merge to avoid losing such a
+ path. However this safety valve sometimes gets in the
+ way. For example, it often happens that the other
+ branch added a file that used to be a generated file in
+ your branch, and the safety valve triggers when you try
+ to switch to that branch after you ran `make` but before
+ running `make clean` to remove the generated file. This
+ option tells the command to read per-directory exclude
+ file (usually '.gitignore') and allows such an untracked
+ but explicitly ignored file to be overwritten.
+
+--index-output=<file>::
+ Instead of writing the results out to `$GIT_INDEX_FILE`,
+ write the resulting index in the named file. While the
+ command is operating, the original index file is locked
+ with the same mechanism as usual. The file must allow
+ to be rename(2)ed into from a temporary file that is
+ created next to the usual index file; typically this
+ means it needs to be on the same filesystem as the index
+ file itself, and you need write permission to the
+ directories the index file and index output file are
+ located in.
+
+<tree-ish#>::
+ The id of the tree object(s) to be read/merged.
+
+
+Merging
+-------
+If `-m` is specified, `git-read-tree` can perform 3 kinds of
+merge, a single tree merge if only 1 tree is given, a
+fast-forward merge with 2 trees, or a 3-way merge if 3 trees are
+provided.
+
+
+Single Tree Merge
+~~~~~~~~~~~~~~~~~
+If only 1 tree is specified, git-read-tree operates as if the user did not
+specify `-m`, except that if the original index has an entry for a
+given pathname, and the contents of the path matches with the tree
+being read, the stat info from the index is used. (In other words, the
+index's stat()s take precedence over the merged tree's).
+
+That means that if you do a `git-read-tree -m <newtree>` followed by a
+`git-checkout-index -f -u -a`, the `git-checkout-index` only checks out
+the stuff that really changed.
+
+This is used to avoid unnecessary false hits when `git-diff-files` is
+run after `git-read-tree`.
+
+
+Two Tree Merge
+~~~~~~~~~~~~~~
+
+Typically, this is invoked as `git-read-tree -m $H $M`, where $H
+is the head commit of the current repository, and $M is the head
+of a foreign tree, which is simply ahead of $H (i.e. we are in a
+fast forward situation).
+
+When two trees are specified, the user is telling git-read-tree
+the following:
+
+ 1. The current index and work tree is derived from $H, but
+ the user may have local changes in them since $H;
+
+ 2. The user wants to fast-forward to $M.
+
+In this case, the `git-read-tree -m $H $M` command makes sure
+that no local change is lost as the result of this "merge".
+Here are the "carry forward" rules:
+
+ I (index) H M Result
+ -------------------------------------------------------
+ 0 nothing nothing nothing (does not happen)
+ 1 nothing nothing exists use M
+ 2 nothing exists nothing remove path from index
+ 3 nothing exists exists use M
+
+ clean I==H I==M
+ ------------------
+ 4 yes N/A N/A nothing nothing keep index
+ 5 no N/A N/A nothing nothing keep index
+
+ 6 yes N/A yes nothing exists keep index
+ 7 no N/A yes nothing exists keep index
+ 8 yes N/A no nothing exists fail
+ 9 no N/A no nothing exists fail
+
+ 10 yes yes N/A exists nothing remove path from index
+ 11 no yes N/A exists nothing fail
+ 12 yes no N/A exists nothing fail
+ 13 no no N/A exists nothing fail
+
+ clean (H=M)
+ ------
+ 14 yes exists exists keep index
+ 15 no exists exists keep index
+
+ clean I==H I==M (H!=M)
+ ------------------
+ 16 yes no no exists exists fail
+ 17 no no no exists exists fail
+ 18 yes no yes exists exists keep index
+ 19 no no yes exists exists keep index
+ 20 yes yes no exists exists use M
+ 21 no yes no exists exists fail
+
+In all "keep index" cases, the index entry stays as in the
+original index file. If the entry were not up to date,
+git-read-tree keeps the copy in the work tree intact when
+operating under the -u flag.
+
+When this form of git-read-tree returns successfully, you can
+see what "local changes" you made are carried forward by running
+`git-diff-index --cached $M`. Note that this does not
+necessarily match `git-diff-index --cached $H` would have
+produced before such a two tree merge. This is because of cases
+18 and 19 --- if you already had the changes in $M (e.g. maybe
+you picked it up via e-mail in a patch form), `git-diff-index
+--cached $H` would have told you about the change before this
+merge, but it would not show in `git-diff-index --cached $M`
+output after two-tree merge.
+
+
+3-Way Merge
+~~~~~~~~~~~
+Each "index" entry has two bits worth of "stage" state. stage 0 is the
+normal one, and is the only one you'd see in any kind of normal use.
+
+However, when you do `git-read-tree` with three trees, the "stage"
+starts out at 1.
+
+This means that you can do
+
+----------------
+$ git-read-tree -m <tree1> <tree2> <tree3>
+----------------
+
+and you will end up with an index with all of the <tree1> entries in
+"stage1", all of the <tree2> entries in "stage2" and all of the
+<tree3> entries in "stage3". When performing a merge of another
+branch into the current branch, we use the common ancestor tree
+as <tree1>, the current branch head as <tree2>, and the other
+branch head as <tree3>.
+
+Furthermore, `git-read-tree` has special-case logic that says: if you see
+a file that matches in all respects in the following states, it
+"collapses" back to "stage0":
+
+ - stage 2 and 3 are the same; take one or the other (it makes no
+ difference - the same work has been done on our branch in
+ stage 2 and their branch in stage 3)
+
+ - stage 1 and stage 2 are the same and stage 3 is different; take
+ stage 3 (our branch in stage 2 did not do anything since the
+ ancestor in stage 1 while their branch in stage 3 worked on
+ it)
+
+ - stage 1 and stage 3 are the same and stage 2 is different take
+ stage 2 (we did something while they did nothing)
+
+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,
+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
+you are trying to merge (stage 2 and 3 respectively).
+
+The order of stages 1, 2 and 3 (hence the order of three
+<tree-ish> command line arguments) are significant when you
+start a 3-way merge with an index file that is already
+populated. Here is an outline of how the algorithm works:
+
+- if a file exists in identical format in all three trees, it will
+ automatically collapse to "merged" state by git-read-tree.
+
+- a file that has _any_ difference what-so-ever in the three trees
+ will stay as separate entries in the index. It's up to "porcelain
+ policy" to determine how to remove the non-0 stages, and insert a
+ merged version.
+
+- 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 (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,
+ since they've already been done.
+
+ * if you find a "stage1", but no matching "stage2" or "stage3", you
+ know it's been removed from both trees (it only existed in the
+ original tree), and you remove that entry.
+
+ * if you find a matching "stage2" and "stage3" tree, you remove one
+ of them, and turn the other into a "stage0" entry. Remove any
+ matching "stage1" entry if it exists too. .. all the normal
+ trivial rules ..
+
+You would normally use `git-merge-index` with supplied
+`git-merge-one-file` to do this last step. The script updates
+the files in the working tree as it merges each path and at the
+end of a successful merge.
+
+When you start a 3-way merge with an index file that is already
+populated, it is assumed that it represents the state of the
+files in your work tree, and you can even have files with
+changes unrecorded in the index file. It is further assumed
+that this state is "derived" from the stage 2 tree. The 3-way
+merge refuses to run if it finds an entry in the original index
+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
+committed last to your repository:
+
+----------------
+$ JC=`git-rev-parse --verify "HEAD^0"`
+$ git-checkout-index -f -u -a $JC
+----------------
+
+You do random edits, without running git-update-index. And then
+you notice that the tip of your "upstream" tree has advanced
+since you pulled from him:
+
+----------------
+$ git-fetch git://.... linus
+$ LT=`cat .git/FETCH_HEAD`
+----------------
+
+Your work tree is still based on your HEAD ($JC), but you have
+some edits since. Three-way merge makes sure that you have not
+added or modified index entries since $JC, and if you haven't,
+then does the right thing. So with the following sequence:
+
+----------------
+$ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT
+$ git-merge-index git-merge-one-file -a
+$ echo "Merge with Linus" | \
+ git-commit-tree `git-write-tree` -p $JC -p $LT
+----------------
+
+what you would commit is a pure merge between $JC and $LT without
+your work-in-progress changes, and your work tree would be
+updated to the result of the merge.
+
+However, if you have local changes in the working tree that
+would be overwritten by this merge,`git-read-tree` will refuse
+to run to prevent your changes from being lost.
+
+In other words, there is no need to worry about what exists only
+in the working tree. When you have local changes in a part of
+the project that is not involved in the merge, your changes do
+not interfere with the merge, and are kept intact. When they
+*do* interfere, the merge does not even start (`git-read-tree`
+complains loudly and fails without modifying anything). In such
+a case, you can simply continue doing what you were in the
+middle of doing, and when your working tree is ready (i.e. you
+have finished your work-in-progress), attempt the merge again.
+
+
+SEE ALSO
+--------
+linkgit:git-write-tree[1]; linkgit:git-ls-files[1];
+linkgit:gitignore[5]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
new file mode 100644
index 0000000000..7166414355
--- /dev/null
+++ b/Documentation/git-rebase.txt
@@ -0,0 +1,409 @@
+git-rebase(1)
+=============
+
+NAME
+----
+git-rebase - Forward-port local commits to the updated upstream head
+
+SYNOPSIS
+--------
+[verse]
+'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
+ [-s <strategy> | --strategy=<strategy>]
+ [-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]
+ [--onto <newbase>] <upstream> [<branch>]
+'git-rebase' --continue | --skip | --abort
+
+DESCRIPTION
+-----------
+If <branch> is specified, git-rebase will perform an automatic
+`git checkout <branch>` before doing anything else. Otherwise
+it remains on the current branch.
+
+All changes made by commits in the current branch but that are not
+in <upstream> are saved to a temporary area. This is the same set
+of commits that would be shown by `git log <upstream>..HEAD`.
+
+The current branch is reset to <upstream>, or <newbase> if the
+--onto option was supplied. This has the exact same effect as
+`git reset --hard <upstream>` (or <newbase>).
+
+The commits that were previously saved into the temporary area are
+then reapplied to the current branch, one by one, in order. Note that
+any commits in HEAD which introduce the same textual changes as a commit
+in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream
+with a different commit message or timestamp will be skipped).
+
+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.
+
+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
+------------
+
+The latter form is just a short-hand of `git checkout topic`
+followed by `git rebase master`.
+
+If the upstream branch already contains a change you have made (e.g.,
+because you mailed a patch which was applied upstream), then that commit
+will be skipped. For example, running `git-rebase master` on the
+following history (in which A' and A introduce the same set of changes,
+but have different committer information):
+
+------------
+ A---B---C topic
+ /
+ D---E---A'---F master
+------------
+
+will result in:
+
+------------
+ B'---C' topic
+ /
+ D---E---A'---F master
+------------
+
+Here is how you would transplant a topic branch based on one
+branch to another, to pretend that you forked the topic branch
+from the latter branch, using `rebase --onto`.
+
+First let's assume your 'topic' is based on branch 'next'.
+For example feature developed in 'topic' depends on some
+functionality which is found in 'next'.
+
+------------
+ o---o---o---o---o master
+ \
+ o---o---o---o---o next
+ \
+ o---o---o topic
+------------
+
+We would want to make 'topic' forked from branch 'master',
+for example because the functionality 'topic' branch depend on
+got merged into more stable 'master' branch, like this:
+
+------------
+ o---o---o---o---o master
+ | \
+ | o'--o'--o' topic
+ \
+ o---o---o---o---o next
+------------
+
+We can get this using the following command:
+
+ git-rebase --onto master next topic
+
+
+Another example of --onto option is to rebase part of a
+branch. If we have the following situation:
+
+------------
+ H---I---J topicB
+ /
+ E---F---G topicA
+ /
+ A---B---C---D master
+------------
+
+then the command
+
+ git-rebase --onto master topicA topicB
+
+would result in:
+
+------------
+ H'--I'--J' topicB
+ /
+ | E---F---G topicA
+ |/
+ A---B---C---D master
+------------
+
+This is useful when topicB does not depend on topicA.
+
+A range of commits could also be removed with rebase. If we have
+the following situation:
+
+------------
+ E---F---G---H---I---J topicA
+------------
+
+then the command
+
+ git-rebase --onto topicA~5 topicA~3 topicA
+
+would result in the removal of commits F and G:
+
+------------
+ E---H'---I'---J' topicA
+------------
+
+This is useful if F and G were flawed in some way, or should not be
+part of topicA. Note that the argument to --onto and the <upstream>
+parameter can be any valid commit-ish.
+
+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 add <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>. May be any valid commit, and not just an
+ existing branch name.
+
+<upstream>::
+ Upstream branch to compare against. May be any valid commit,
+ not just an existing branch name.
+
+<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.
+
+-m::
+--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.
+
+-v::
+--verbose::
+ Display a diffstat of what changed upstream since the last rebase.
+
+-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.
+
+--whitespace=<nowarn|warn|error|error-all|strip>::
+ This flag is passed to the `git-apply` program
+ (see linkgit:git-apply[1]) that applies the patch.
+
+-i::
+--interactive::
+ Make a list of the commits which are about to be rebased. Let the
+ user edit that list before rebasing. This mode can also be used to
+ split commits (see SPLITTING COMMITS below).
+
+-p::
+--preserve-merges::
+ Instead of ignoring merges, try to recreate them. This option
+ only works in interactive mode.
+
+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.
+
+Upon completion, <branch> will be the current branch.
+
+INTERACTIVE MODE
+----------------
+
+Rebasing interactively means that you have a chance to edit the commits
+which are rebased. You can reorder the commits, and you can
+remove them (weeding out bad or otherwise unwanted patches).
+
+The interactive mode is meant for this type of workflow:
+
+1. have a wonderful idea
+2. hack on the code
+3. prepare a series for submission
+4. submit
+
+where point 2. consists of several instances of
+
+a. regular use
+ 1. finish something worthy of a commit
+ 2. commit
+b. independent fixup
+ 1. realize that something does not work
+ 2. fix that
+ 3. commit it
+
+Sometimes the thing fixed in b.2. cannot be amended to the not-quite
+perfect commit it fixes, because that commit is buried deeply in a
+patch series. That is exactly what interactive rebase is for: use it
+after plenty of "a"s and "b"s, by rearranging and editing
+commits, and squashing multiple commits into one.
+
+Start it with the last commit you want to retain as-is:
+
+ git rebase -i <after-this-commit>
+
+An editor will be fired up with all the commits in your current branch
+(ignoring merge commits), which come after the given commit. You can
+reorder the commits in this list to your heart's content, and you can
+remove them. The list looks more or less like this:
+
+-------------------------------------------
+pick deadbee The oneline of this commit
+pick fa1afe1 The oneline of the next commit
+...
+-------------------------------------------
+
+The oneline descriptions are purely for your pleasure; `git-rebase` will
+not look at them but at the commit names ("deadbee" and "fa1afe1" in this
+example), so do not delete or edit the names.
+
+By replacing the command "pick" with the command "edit", you can tell
+`git-rebase` to stop after applying that commit, so that you can edit
+the files and/or the commit message, amend the commit, and continue
+rebasing.
+
+If you want to fold two or more commits into one, replace the command
+"pick" with "squash" for the second and subsequent commit. If the
+commits had different authors, it will attribute the squashed commit to
+the author of the first commit.
+
+In both cases, or when a "pick" does not succeed (because of merge
+errors), the loop will stop to let you fix things, and you can continue
+the loop with `git rebase --continue`.
+
+For example, if you want to reorder the last 5 commits, such that what
+was HEAD~4 becomes the new HEAD. To achieve that, you would call
+`git-rebase` like this:
+
+----------------------
+$ git rebase -i HEAD~5
+----------------------
+
+And move the first patch to the end of the list.
+
+You might want to preserve merges, if you have a history like this:
+
+------------------
+ X
+ \
+ A---M---B
+ /
+---o---O---P---Q
+------------------
+
+Suppose you want to rebase the side branch starting at "A" to "Q". Make
+sure that the current HEAD is "B", and call
+
+-----------------------------
+$ git rebase -i -p --onto Q O
+-----------------------------
+
+
+SPLITTING COMMITS
+-----------------
+
+In interactive mode, you can mark commits with the action "edit". However,
+this does not necessarily mean that 'git rebase' expects the result of this
+edit to be exactly one commit. Indeed, you can undo the commit, or you can
+add other commits. This can be used to split a commit into two:
+
+- Start an interactive rebase with 'git rebase -i <commit>^', where
+ <commit> is the commit you want to split. In fact, any commit range
+ will do, as long as it contains that commit.
+
+- Mark the commit you want to split with the action "edit".
+
+- When it comes to editing that commit, execute 'git reset HEAD^'. The
+ effect is that the HEAD is rewound by one, and the index follows suit.
+ However, the working tree stays the same.
+
+- Now add the changes to the index that you want to have in the first
+ commit. You can use linkgit:git-add[1] (possibly interactively) and/or
+ linkgit:git-gui[1] to do that.
+
+- Commit the now-current index with whatever commit message is appropriate
+ now.
+
+- Repeat the last two steps until your working tree is clean.
+
+- Continue the rebase with 'git rebase --continue'.
+
+If you are not absolutely sure that the intermediate revisions are
+consistent (they compile, pass the testsuite, etc.) you should use
+linkgit:git-stash[1] to stash away the not-yet-committed changes
+after each commit, test, and amend the commit if fixes are necessary.
+
+
+Authors
+------
+Written by Junio C Hamano <junkio@cox.net> and
+Johannes E. Schindelin <johannes.schindelin@gmx.de>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
new file mode 100644
index 0000000000..a70c7168f6
--- /dev/null
+++ b/Documentation/git-receive-pack.txt
@@ -0,0 +1,165 @@
+git-receive-pack(1)
+===================
+
+NAME
+----
+git-receive-pack - Receive what is pushed into the repository
+
+
+SYNOPSIS
+--------
+'git-receive-pack' <directory>
+
+DESCRIPTION
+-----------
+Invoked by 'git-send-pack' and updates the repository with the
+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'.
+
+The command allows for creation and fast forwarding of sha1 refs
+(heads/tags) on the remote end (strictly speaking, it is the
+local end receive-pack runs, but to the user who is sitting at
+the send-pack end, it is updating the remote. Confused?)
+
+There are other real-world examples of using update and
+post-update hooks found in the Documentation/howto directory.
+
+git-receive-pack honours the receive.denyNonFastForwards config
+option, which tells it if updates to a ref should be denied if they
+are not fast-forwards.
+
+OPTIONS
+-------
+<directory>::
+ The repository to sync into.
+
+pre-receive Hook
+----------------
+Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists
+and is executable, it will be invoked once with no parameters. The
+standard input of the hook will be one line per ref to be updated:
+
+ sha1-old SP sha1-new SP refname LF
+
+The refname value is relative to $GIT_DIR; e.g. for the master
+head this is "refs/heads/master". The two sha1 values before
+each refname are the object names for the refname before and after
+the update. Refs to be created will have sha1-old equal to 0\{40},
+while refs to be deleted will have sha1-new equal to 0\{40}, otherwise
+sha1-old and sha1-new should be valid objects in the repository.
+
+This hook is called before any refname is updated and before any
+fast-forward checks are performed.
+
+If the pre-receive hook exits with a non-zero exit status no updates
+will be performed, and the update, post-receive and post-update
+hooks will not be invoked either. This can be useful to quickly
+bail out if the update is not to be supported.
+
+update Hook
+-----------
+Before each ref is updated, if $GIT_DIR/hooks/update file exists
+and is executable, it is invoked once per ref, with three parameters:
+
+ $GIT_DIR/hooks/update refname sha1-old sha1-new
+
+The refname parameter is relative to $GIT_DIR; e.g. for the master
+head this is "refs/heads/master". The two sha1 arguments are
+the object names for the refname before and after the update.
+Note that the hook is called before the refname is updated,
+so either sha1-old is 0\{40} (meaning there is no such ref yet),
+or it should match what is recorded in refname.
+
+The hook should exit with non-zero status if it wants to disallow
+updating the named ref. Otherwise it should exit with zero.
+
+Successful execution (a zero exit status) of this hook does not
+ensure the ref will actually be updated, it is only a prerequisite.
+As such it is not a good idea to send notices (e.g. email) from
+this hook. Consider using the post-receive hook instead.
+
+post-receive Hook
+-----------------
+After all refs were updated (or attempted to be updated), if any
+ref update was successful, and if $GIT_DIR/hooks/post-receive
+file exists and is executable, it will be invoke once with no
+parameters. The standard input of the hook will be one line
+for each successfully updated ref:
+
+ sha1-old SP sha1-new SP refname LF
+
+The refname value is relative to $GIT_DIR; e.g. for the master
+head this is "refs/heads/master". The two sha1 values before
+each refname are the object names for the refname before and after
+the update. Refs that were created will have sha1-old equal to
+0\{40}, while refs that were deleted will have sha1-new equal to
+0\{40}, otherwise sha1-old and sha1-new should be valid objects in
+the repository.
+
+Using this hook, it is easy to generate mails describing the updates
+to the repository. This example script sends one mail message per
+ref listing the commits pushed to the repository:
+
+ #!/bin/sh
+ # mail out commit update information.
+ while read oval nval ref
+ do
+ if expr "$oval" : '0*$' >/dev/null
+ then
+ echo "Created a new ref, with the following commits:"
+ git-rev-list --pretty "$nval"
+ else
+ echo "New commits:"
+ git-rev-list --pretty "$nval" "^$oval"
+ fi |
+ mail -s "Changes to ref $ref" commit-list@mydomain
+ done
+ exit 0
+
+The exit code from this hook invocation is ignored, however a
+non-zero exit code will generate an error message.
+
+Note that it is possible for refname to not have sha1-new when this
+hook runs. This can easily occur if another user modifies the ref
+after it was updated by receive-pack, but before the hook was able
+to evaluate it. It is recommended that hooks rely on sha1-new
+rather than the current value of refname.
+
+post-update Hook
+----------------
+After all other processing, if at least one ref was updated, and
+if $GIT_DIR/hooks/post-update file exists and is executable, then
+post-update will called with the list of refs that have been updated.
+This can be used to implement any repository wide cleanup tasks.
+
+The exit code from this hook invocation is ignored; the only thing
+left for git-receive-pack to do at that point is to exit itself
+anyway.
+
+This hook can be used, for example, to run "git-update-server-info"
+if the repository is packed and is served via a dumb transport.
+
+ #!/bin/sh
+ exec git-update-server-info
+
+
+SEE ALSO
+--------
+linkgit:git-send-pack[1]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
new file mode 100644
index 0000000000..8492aeacf1
--- /dev/null
+++ b/Documentation/git-reflog.txt
@@ -0,0 +1,105 @@
+git-reflog(1)
+=============
+
+NAME
+----
+git-reflog - Manage reflog information
+
+
+SYNOPSIS
+--------
+'git reflog' <subcommand> <options>
+
+DESCRIPTION
+-----------
+The command takes various subcommands, and different options
+depending on the subcommand:
+
+[verse]
+git reflog expire [--dry-run] [--stale-fix] [--verbose]
+ [--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...
+
+git reflog delete ref@\{specifier\}...
+
+git reflog [show] [log-options] [<ref>]
+
+Reflog is a mechanism to record when the tip of branches are
+updated. This command is to manage the information recorded in it.
+
+The subcommand "expire" is used to prune older reflog entries.
+Entries older than `expire` time, or entries older than
+`expire-unreachable` time and are not reachable from the current
+tip, are removed from the reflog. This is typically not used
+directly by the end users -- instead, see linkgit:git-gc[1].
+
+The subcommand "show" (which is also the default, in the absence of any
+subcommands) will take all the normal log options, and show the log of
+the reference provided in the command-line (or `HEAD`, by default).
+The reflog will cover all recent actions (HEAD reflog records branch switching
+as well). It is an alias for 'git log -g --abbrev-commit --pretty=oneline';
+see linkgit:git-log[1].
+
+The reflog is useful in various git commands, to specify the old value
+of a reference. For example, `HEAD@\{2\}` means "where HEAD used to be
+two moves ago", `master@\{one.week.ago\}` means "where master used to
+point to one week ago", and so on. See linkgit:git-rev-parse[1] for
+more details.
+
+To delete single entries from the reflog, use the subcommand "delete"
+and specify the _exact_ entry (e.g. ``git reflog delete master@\{2\}'').
+
+
+OPTIONS
+-------
+
+--stale-fix::
+ This revamps the logic -- the definition of "broken commit"
+ becomes: a commit that is not reachable from any of the refs and
+ there is a missing object among the commit, tree, or blob
+ objects reachable from it that is not reachable from any of the
+ refs.
++
+This computation involves traversing all the reachable objects, i.e. it
+has the same cost as 'git prune'. Fortunately, once this is run, we
+should not have to ever worry about missing objects, because the current
+prune and pack-objects know about reflogs and protect objects referred by
+them.
+
+--expire=<time>::
+ Entries older than this time are pruned. Without the
+ option it is taken from configuration `gc.reflogExpire`,
+ which in turn defaults to 90 days.
+
+--expire-unreachable=<time>::
+ Entries older than this time and are not reachable from
+ the current tip of the branch are pruned. Without the
+ option it is taken from configuration
+ `gc.reflogExpireUnreachable`, which in turn defaults to
+ 30 days.
+
+--all::
+ Instead of listing <refs> explicitly, prune all refs.
+
+--updateref::
+ Update the ref with the sha1 of the top reflog entry (i.e.
+ <ref>@\{0\}) after expiring or deleting.
+
+--rewrite::
+ While expiring or deleting, adjust each reflog entry to ensure
+ that the `old` sha1 field points to the `new` sha1 field of the
+ previous entry.
+
+--verbose::
+ Print extra information on screen.
+
+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 linkgit:git[1] suite
diff --git a/Documentation/git-relink.txt b/Documentation/git-relink.txt
new file mode 100644
index 0000000000..f6dafd4495
--- /dev/null
+++ b/Documentation/git-relink.txt
@@ -0,0 +1,37 @@
+git-relink(1)
+=============
+
+NAME
+----
+git-relink - Hardlink common objects in local repositories
+
+SYNOPSIS
+--------
+'git-relink' [--safe] <dir> [<dir>]\* <master_dir>
+
+DESCRIPTION
+-----------
+This will scan 1 or more object repositories and look for objects in common
+with a master repository. Objects not already hardlinked to the master
+repository will be replaced with a hardlink to the master repository.
+
+OPTIONS
+-------
+--safe::
+ Stops if two objects with the same hash exist but have different sizes.
+ Default is to warn and continue.
+
+<dir>::
+ Directories containing a .git/objects/ subdirectory.
+
+Author
+------
+Written by Ryan Anderson <ryan@michonline.com>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
new file mode 100644
index 0000000000..782b0554cf
--- /dev/null
+++ b/Documentation/git-remote.txt
@@ -0,0 +1,157 @@
+git-remote(1)
+============
+
+NAME
+----
+git-remote - manage set of tracked repositories
+
+
+SYNOPSIS
+--------
+[verse]
+'git-remote' [-v | --verbose]
+'git-remote' add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
+'git-remote' rm <name>
+'git-remote' show <name>
+'git-remote' prune <name>
+'git-remote' update [group]
+
+DESCRIPTION
+-----------
+
+Manage the set of repositories ("remotes") whose branches you track.
+
+
+OPTIONS
+-------
+
+-v::
+--verbose::
+ Be a little more verbose and show remote url after name.
+
+
+COMMANDS
+--------
+
+With no arguments, shows a list of existing remotes. Several
+subcommands are available to perform operations on the remotes.
+
+'add'::
+
+Adds a remote named <name> for the repository at
+<url>. The command `git fetch <name>` can then be used to create and
+update remote-tracking branches <name>/<branch>.
++
+With `-f` option, `git fetch <name>` is run immediately after
+the remote information is set up.
++
+With `-t <branch>` option, instead of the default glob
+refspec for the remote to track all branches under
+`$GIT_DIR/remotes/<name>/`, a refspec to track only `<branch>`
+is created. You can give more than one `-t <branch>` to track
+multiple branches without grabbing all branches.
++
+With `-m <master>` option, `$GIT_DIR/remotes/<name>/HEAD` is set
+up to point at remote's `<master>` branch instead of whatever
+branch the `HEAD` at the remote repository actually points at.
++
+In mirror mode, enabled with `\--mirror`, the refs will not be stored
+in the 'refs/remotes/' namespace, but in 'refs/heads/'. This option
+only makes sense in bare repositories. If a remote uses mirror
+mode, furthermore, `git push` will always behave as if `\--mirror`
+was passed.
+
+'rm'::
+
+Remove the remote named <name>. All remote tracking branches and
+configuration settings for the remote are removed.
+
+'show'::
+
+Gives some information about the remote <name>.
++
+With `-n` option, the remote heads are not queried first with
+`git ls-remote <name>`; cached information is used instead.
+
+'prune'::
+
+Deletes all stale tracking branches under <name>.
+These stale branches have already been removed from the remote repository
+referenced by <name>, but are still locally available in
+"remotes/<name>".
++
+With `-n` option, the remote heads are not confirmed first with `git
+ls-remote <name>`; cached information is used instead. Use with
+caution.
+
+'update'::
+
+Fetch updates for a named set of remotes in the repository as defined by
+remotes.<group>. If a named group is not specified on the command line,
+the configuration parameter remotes.default will get used; if
+remotes.default is not defined, all remotes which do not have the
+configuration parameter remote.<name>.skipDefaultUpdate set to true will
+be updated. (See linkgit:git-config[1]).
+
+
+DISCUSSION
+----------
+
+The remote configuration is achieved using the `remote.origin.url` and
+`remote.origin.fetch` configuration variables. (See
+linkgit:git-config[1]).
+
+Examples
+--------
+
+* Add a new remote, fetch, and check out a branch from it
++
+------------
+$ git remote
+origin
+$ git branch -r
+origin/master
+$ git remote add linux-nfs git://linux-nfs.org/pub/linux/nfs-2.6.git
+$ git remote
+linux-nfs
+origin
+$ git fetch
+* refs/remotes/linux-nfs/master: storing branch 'master' ...
+ commit: bf81b46
+$ git branch -r
+origin/master
+linux-nfs/master
+$ git checkout -b nfs linux-nfs/master
+...
+------------
+
+* Imitate 'git clone' but track only selected branches
++
+------------
+$ mkdir project.git
+$ cd project.git
+$ git init
+$ git remote add -f -t master -m master origin git://example.com/git.git/
+$ git merge origin
+------------
+
+
+SEE ALSO
+--------
+linkgit:git-fetch[1]
+linkgit:git-branch[1]
+linkgit:git-config[1]
+
+Author
+------
+Written by Junio Hamano
+
+
+Documentation
+--------------
+Documentation by J. Bruce Fields and the git-list <git@vger.kernel.org>.
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
new file mode 100644
index 0000000000..04d6f1fbc4
--- /dev/null
+++ b/Documentation/git-repack.txt
@@ -0,0 +1,133 @@
+git-repack(1)
+=============
+
+NAME
+----
+git-repack - Pack unpacked objects in a repository
+
+
+SYNOPSIS
+--------
+'git-repack' [-a] [-A] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N]
+
+DESCRIPTION
+-----------
+
+This script is used to combine all objects that do not currently
+reside in a "pack", into a pack. It can also be used to re-organize
+existing packs into a single, more efficient pack.
+
+A pack is a collection of objects, individually compressed, with
+delta compression applied, stored in a single file, with an
+associated index file.
+
+Packs are used to reduce the load on mirror systems, backup
+engines, disk storage, etc.
+
+OPTIONS
+-------
+
+-a::
+ Instead of incrementally packing the unpacked objects,
+ pack everything referenced into a single pack.
+ Especially useful when packing a repository that is used
+ for private development and there is no need to worry
+ about people fetching via dumb protocols from it. Use
+ with '-d'. This will clean up the objects that `git prune`
+ leaves behind, but `git fsck --full` shows as
+ dangling.
+
+-A::
+ Same as `-a`, but any unreachable objects in a previous
+ pack become loose, unpacked objects, instead of being
+ left in the old pack. Unreachable objects are never
+ intentionally added to a pack, even when repacking.
+ When used with '-d', this option
+ prevents unreachable objects from being immediately
+ deleted by way of being left in the old pack and then
+ removed. Instead, the loose unreachable objects
+ will be pruned according to normal expiry rules
+ with the next linkgit:git-gc[1].
+
+-d::
+ After packing, if the newly created packs make some
+ existing packs redundant, remove the redundant packs.
+ Also runs linkgit:git-prune-packed[1].
+
+-l::
+ Pass the `--local` option to `git pack-objects`, see
+ linkgit:git-pack-objects[1].
+
+-f::
+ Pass the `--no-reuse-delta` option to `git pack-objects`, see
+ linkgit:git-pack-objects[1].
+
+-q::
+ Pass the `-q` option to `git pack-objects`, see
+ linkgit:git-pack-objects[1].
+
+-n::
+ Do not update the server information with
+ `git update-server-info`. This option skips
+ updating local catalog files needed to publish
+ this repository (or a direct copy of it)
+ over HTTP or FTP. See gitlink:git-update-server-info[1].
+
+--window=[N]::
+--depth=[N]::
+ These two options affect how the objects contained in the pack are
+ stored using delta compression. The objects are first internally
+ sorted by type, size and optionally names and compared against the
+ other objects within `--window` to see if using delta compression saves
+ space. `--depth` limits the maximum delta depth; making it too deep
+ affects the performance on the unpacker side, because delta data needs
+ to be applied that many times to get to the necessary object.
+ The default value for --window is 10 and --depth is 50.
+
+--window-memory=[N]::
+ This option provides an additional limit on top of `--window`;
+ the window size will dynamically scale down so as to not take
+ up more than N bytes in memory. This is useful in
+ repositories with a mix of large and small objects to not run
+ out of memory with a large window, but still be able to take
+ advantage of the large window for the smaller objects. The
+ size can be suffixed with "k", "m", or "g".
+ `--window-memory=0` makes memory usage unlimited, which is the
+ default.
+
+--max-pack-size=<n>::
+ Maximum size of each output packfile, expressed in MiB.
+ If specified, multiple packfiles may be created.
+ The default is unlimited.
+
+
+Configuration
+-------------
+
+When configuration variable `repack.UseDeltaBaseOffset` is set
+for the repository, the command passes `--delta-base-offset`
+option to `git-pack-objects`; this typically results in slightly
+smaller packs, but the generated packs are incompatible with
+versions of git older than (and including) v1.4.3; do not set
+the variable in a repository that older version of git needs to
+be able to read (this includes repositories from which packs can
+be copied out over http or rsync, and people who obtained packs
+that way can try to use older git with it).
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Ryan Anderson <ryan@michonline.com>
+
+SEE ALSO
+--------
+linkgit:git-pack-objects[1]
+linkgit:git-prune-packed[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt
new file mode 100644
index 0000000000..2ca39946b7
--- /dev/null
+++ b/Documentation/git-repo-config.txt
@@ -0,0 +1,18 @@
+git-repo-config(1)
+==================
+
+NAME
+----
+git-repo-config - Get and set repository or global options
+
+
+SYNOPSIS
+--------
+'git-repo-config' ...
+
+
+DESCRIPTION
+-----------
+
+This is a synonym for linkgit:git-config[1]. Please refer to the
+documentation of that command.
diff --git a/Documentation/git-request-pull.txt b/Documentation/git-request-pull.txt
new file mode 100644
index 0000000000..c71d86985e
--- /dev/null
+++ b/Documentation/git-request-pull.txt
@@ -0,0 +1,39 @@
+git-request-pull(1)
+===================
+
+NAME
+----
+git-request-pull - Generates a summary of pending changes
+
+SYNOPSIS
+--------
+'git-request-pull' <start> <url> [<end>]
+
+DESCRIPTION
+-----------
+
+Summarizes the changes between two commits to the standard output, and includes
+the given URL in the generated summary.
+
+OPTIONS
+-------
+<start>::
+ Commit to start at.
+
+<url>::
+ URL to include in the summary.
+
+<end>::
+ Commit to end at; defaults to HEAD.
+
+Author
+------
+Written by Ryan Anderson <ryan@michonline.com> and Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
new file mode 100644
index 0000000000..8030ec4d01
--- /dev/null
+++ b/Documentation/git-rerere.txt
@@ -0,0 +1,211 @@
+git-rerere(1)
+=============
+
+NAME
+----
+git-rerere - Reuse recorded resolution of conflicted merges
+
+SYNOPSIS
+--------
+'git-rerere' [clear|diff|status|gc]
+
+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 set the configuration variable rerere.enabled to
+enable this command.
+
+
+COMMANDS
+--------
+
+Normally, git-rerere is run without arguments or user-intervention.
+However, it has several commands that allow it to interact with
+its working state.
+
+'clear'::
+
+This resets the metadata used by rerere if a merge resolution is to be
+is aborted. Calling linkgit:git-am[1] --skip or linkgit:git-rebase[1]
+[--skip|--abort] will automatically invoke this command.
+
+'diff'::
+
+This displays diffs for the current state of the resolution. It is
+useful for tracking what has changed while the user is resolving
+conflicts. Additional arguments are passed directly to the system
+diff(1) command installed in PATH.
+
+'status'::
+
+Like diff, but this only prints the filenames that will be tracked
+for resolutions.
+
+'gc'::
+
+This command is used to prune records of conflicted merge that
+occurred long time ago. By default, conflicts older than 15
+days that you have not recorded their resolution, and conflicts
+older than 60 days, are pruned. These are controlled with
+`gc.rerereunresolved` and `gc.rerereresolved` configuration
+variables.
+
+
+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 merge 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 merge master
+ $ ... work on both topic and master branches
+ $ git checkout master
+ $ git merge 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 merge master
+ $ git reset --hard HEAD^ ;# rewind the test merge
+ $ ... work on both topic and master branches
+ $ git checkout master
+ $ git merge 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 add` 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 set the config variable rerere.enabled 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 linkgit:git[1] suite
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
new file mode 100644
index 0000000000..12ea9b23c5
--- /dev/null
+++ b/Documentation/git-reset.txt
@@ -0,0 +1,206 @@
+git-reset(1)
+============
+
+NAME
+----
+git-reset - Reset current HEAD to the specified state
+
+SYNOPSIS
+--------
+[verse]
+'git reset' [--mixed | --soft | --hard] [-q] [<commit>]
+'git reset' [-q] [<commit>] [--] <paths>...
+
+DESCRIPTION
+-----------
+Sets the current head to the specified commit and optionally resets the
+index and working tree to match.
+
+This command is useful if you notice some small error in a recent
+commit (or set of commits) and want to redo that part without showing
+the undo in the history.
+
+If you want to undo a commit other than the latest on a branch,
+linkgit:git-revert[1] is your friend.
+
+The second form with 'paths' is used to revert selected paths in
+the index from a given commit, without moving HEAD.
+
+
+OPTIONS
+-------
+--mixed::
+ Resets the index but not the working tree (i.e., the changed files
+ are preserved but not marked for commit) and reports what has not
+ been updated. This is the default action.
+
+--soft::
+ Does not touch the index file nor the working tree at all, but
+ requires them to be in a good order. This leaves all your changed
+ files "Changes to be committed", as linkgit:git-status[1] would
+ put it.
+
+--hard::
+ Matches the working tree and index to that of the tree being
+ switched to. Any changes to tracked files in the working tree
+ since <commit> are lost.
+
+-q::
+ Be quiet, only report errors.
+
+<commit>::
+ Commit to make the current HEAD. If not given defaults to HEAD.
+
+Examples
+--------
+
+Undo a commit and redo::
++
+------------
+$ git commit ...
+$ git reset --soft HEAD^ <1>
+$ edit <2>
+$ git commit -a -c ORIG_HEAD <3>
+------------
++
+<1> This is most often done when you remembered what you
+just committed is incomplete, or you misspelled your commit
+message, or both. Leaves working tree as it was before "reset".
+<2> Make corrections to working tree files.
+<3> "reset" copies the old head to .git/ORIG_HEAD; redo the
+commit by starting with its log message. If you do not need to
+edit the message further, you can give -C option instead.
++
+See also the --amend option to linkgit:git-commit[1].
+
+Undo commits permanently::
++
+------------
+$ git commit ...
+$ git reset --hard HEAD~3 <1>
+------------
++
+<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad
+and you do not want to ever see them again. Do *not* do this if
+you have already given these commits to somebody else.
+
+Undo a commit, making it a topic branch::
++
+------------
+$ git branch topic/wip <1>
+$ git reset --hard HEAD~3 <2>
+$ git checkout topic/wip <3>
+------------
++
+<1> You have made some commits, but realize they were premature
+to be in the "master" branch. You want to continue polishing
+them in a topic branch, so create "topic/wip" branch off of the
+current HEAD.
+<2> Rewind the master branch to get rid of those three commits.
+<3> Switch to "topic/wip" branch and keep working.
+
+Undo add::
++
+------------
+$ edit <1>
+$ git add frotz.c filfre.c
+$ mailx <2>
+$ git reset <3>
+$ 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
+and changes with these files are distracting.
+<2> Somebody asks you to pull, and the changes sounds worthy of merging.
+<3> However, you already dirtied the index (i.e. your index does
+not match the HEAD commit). But you know the pull you are going
+to make does not affect frotz.c nor filfre.c, so you revert the
+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>
+Auto-merging nitfol
+CONFLICT (content): Merge conflict in nitfol
+Automatic merge failed/prevented; fix up by hand
+$ 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.
+<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
+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::
++
+Suppose you are interrupted by an urgent fix request while you
+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 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 <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 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.
+
+Reset a single file in the index::
++
+Suppose you have added a file to your index, but later decide you do not
+want to add it to your commit. You can remove the file from the index
+while keeping your changes with git reset.
++
+------------
+$ git reset -- frotz.c <1>
+$ git commit -m "Commit files in index" <2>
+$ git add frotz.c <3>
+------------
++
+<1> This removes the file from the index while keeping it in the working
+ directory.
+<2> This commits all other changes in the index.
+<3> Adds the file to the index again.
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net> and Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
new file mode 100644
index 0000000000..c9b0950321
--- /dev/null
+++ b/Documentation/git-rev-list.txt
@@ -0,0 +1,112 @@
+git-rev-list(1)
+===============
+
+NAME
+----
+git-rev-list - Lists commit objects in reverse chronological order
+
+
+SYNOPSIS
+--------
+[verse]
+'git-rev-list' [ \--max-count=number ]
+ [ \--skip=number ]
+ [ \--max-age=timestamp ]
+ [ \--min-age=timestamp ]
+ [ \--sparse ]
+ [ \--no-merges ]
+ [ \--first-parent ]
+ [ \--remove-empty ]
+ [ \--full-history ]
+ [ \--not ]
+ [ \--all ]
+ [ \--branches ]
+ [ \--tags ]
+ [ \--remotes ]
+ [ \--stdin ]
+ [ \--quiet ]
+ [ \--topo-order ]
+ [ \--parents ]
+ [ \--timestamp ]
+ [ \--left-right ]
+ [ \--cherry-pick ]
+ [ \--encoding[=<encoding>] ]
+ [ \--(author|committer|grep)=<pattern> ]
+ [ \--regexp-ignore-case | \-i ]
+ [ \--extended-regexp | \-E ]
+ [ \--fixed-strings | \-F ]
+ [ \--date={local|relative|default|iso|rfc|short} ]
+ [ [\--objects | \--objects-edge] [ \--unpacked ] ]
+ [ \--pretty | \--header ]
+ [ \--bisect ]
+ [ \--bisect-vars ]
+ [ \--bisect-all ]
+ [ \--merge ]
+ [ \--reverse ]
+ [ \--walk-reflogs ]
+ [ \--no-walk ] [ \--do-walk ]
+ <commit>... [ \-- <paths>... ]
+
+DESCRIPTION
+-----------
+
+Lists commit objects in reverse chronological order starting at the
+given commit(s), taking ancestry relationship into account. This is
+useful to produce human-readable log output.
+
+Commits which are stated with a preceding '{caret}' cause listing to
+stop at that point. Their parents are implied. Thus the following
+command:
+
+-----------------------------------------------------------------------
+ $ git-rev-list foo bar ^baz
+-----------------------------------------------------------------------
+
+means "list all the commits which are included in 'foo' and 'bar', but
+not in 'baz'".
+
+A special notation "'<commit1>'..'<commit2>'" can be used as a
+short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of
+the following may be used interchangeably:
+
+-----------------------------------------------------------------------
+ $ git-rev-list origin..HEAD
+ $ git-rev-list HEAD ^origin
+-----------------------------------------------------------------------
+
+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
+-----------------------------------------------------------------------
+
+linkgit:git-rev-list[1] is a very essential git program, since it
+provides the ability to build and traverse commit ancestry graphs. For
+this reason, it has a lot of different options that enables it to be
+used by commands as different as linkgit:git-bisect[1] and
+linkgit:git-repack[1].
+
+OPTIONS
+-------
+
+:git-rev-list: 1
+include::rev-list-options.txt[]
+
+include::pretty-formats.txt[]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano, Jonas Fonseca
+and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
new file mode 100644
index 0000000000..9e273bc5a6
--- /dev/null
+++ b/Documentation/git-rev-parse.txt
@@ -0,0 +1,424 @@
+git-rev-parse(1)
+================
+
+NAME
+----
+git-rev-parse - Pick out and massage parameters
+
+
+SYNOPSIS
+--------
+'git-rev-parse' [ --option ] <args>...
+
+DESCRIPTION
+-----------
+
+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
+downstream of `git-rev-list`. This command is used to
+distinguish between them.
+
+
+OPTIONS
+-------
+--parseopt::
+ Use `git-rev-parse` in option parsing mode (see PARSEOPT section below).
+
+--keep-dash-dash::
+ Only meaningful in `--parseopt` mode. Tells the option parser to echo
+ out the first `--` met instead of skipping it.
+
+--revs-only::
+ Do not output flags and parameters not meant for
+ `git-rev-list` command.
+
+--no-revs::
+ Do not output flags and parameters meant for
+ `git-rev-list` command.
+
+--flags::
+ Do not output non-flag parameters.
+
+--no-flags::
+ Do not output flag parameters.
+
+--default <arg>::
+ If there is no parameter given by the user, use `<arg>`
+ instead.
+
+--verify::
+ The parameter given must be usable as a single, valid
+ object name. Otherwise barf and abort.
+
+-q::
+--quiet::
+ Only meaningful in `--verify` mode. Do not output an error
+ message if the first argument is not a valid object name;
+ instead exit with non-zero status silently.
+
+--sq::
+ Usually the output is made one line per flag and
+ parameter. This option makes output a single line,
+ properly quoted for consumption by shell. Useful when
+ you expect your parameter to contain whitespaces and
+ newlines (e.g. when using pickaxe `-S` with
+ `git-diff-\*`).
+
+--not::
+ When showing object names, prefix them with '{caret}' and
+ strip '{caret}' prefix from the object names that already have
+ one.
+
+--symbolic::
+ Usually the object names are output in SHA1 form (with
+ possible '{caret}' prefix); this option makes them output in a
+ form as close to the original input as possible.
+
+--symbolic-full-name::
+ This is similar to \--symbolic, but it omits input that
+ are not refs (i.e. branch or tag names; or more
+ explicitly disambiguating "heads/master" form, when you
+ want to name the "master" branch when there is an
+ unfortunately named tag "master"), and show them as full
+ refnames (e.g. "refs/heads/master").
+
+--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 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.
+
+--is-inside-git-dir::
+ When the current working directory is below the repository
+ directory print "true", otherwise "false".
+
+--is-inside-work-tree::
+ When the current working directory is inside the work tree of the
+ repository print "true", otherwise "false".
+
+--is-bare-repository::
+ When the repository is bare print "true", otherwise "false".
+
+--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.
+
+--until=datestring::
+--before=datestring::
+ Parses the date string, and outputs corresponding
+ --min-age= parameter for git-rev-list command.
+
+<args>...::
+ Flags and parameters to be parsed.
+
+
+SPECIFYING REVISIONS
+--------------------
+
+A revision parameter typically, but not necessarily, names a
+commit object. They use what is called an 'extended SHA1'
+syntax. Here are various ways to spell object names. The
+ones listed near the end of this list are to name trees and
+blobs contained in a commit.
+
+* The full SHA1 object name (40-byte hexadecimal string), or
+ a substring of such that is unique within the repository.
+ E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both
+ name the same commit object if there are no other object in
+ your repository whose object name starts with dae86e.
+
+* An output from `git-describe`; i.e. a closest tag, followed by a
+ dash, a `g`, and an abbreviated object name.
+
+* A symbolic ref name. E.g. 'master' typically means the commit
+ object referenced by $GIT_DIR/refs/heads/master. If you
+ happen to have both heads/master and tags/master, you can
+ explicitly say 'heads/master' to tell git which one you mean.
+ When ambiguous, a `<name>` is disambiguated by taking the
+ first match in the following rules:
+
+ . if `$GIT_DIR/<name>` exists, that is what you mean (this is usually
+ useful only for `HEAD`, `FETCH_HEAD` and `MERGE_HEAD`);
+
+ . otherwise, `$GIT_DIR/refs/<name>` if exists;
+
+ . otherwise, `$GIT_DIR/refs/tags/<name>` if exists;
+
+ . otherwise, `$GIT_DIR/refs/heads/<name>` if exists;
+
+ . otherwise, `$GIT_DIR/refs/remotes/<name>` if exists;
+
+ . otherwise, `$GIT_DIR/refs/remotes/<name>/HEAD` if exists.
+
+* A ref followed by the suffix '@' with a date specification
+ enclosed in a brace
+ pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1
+ second ago\}' or '\{1979-02-26 18:30:00\}') to specify the value
+ of the ref at a prior point in time. This suffix may only be
+ used immediately following a ref name and the ref must have an
+ existing log ($GIT_DIR/logs/<ref>).
+
+* A ref followed by the suffix '@' with an ordinal specification
+ enclosed in a brace pair (e.g. '\{1\}', '\{15\}') to specify
+ the n-th prior value of that ref. For example 'master@\{1\}'
+ is the immediate prior value of 'master' while 'master@\{5\}'
+ is the 5th prior value of 'master'. This suffix may only be used
+ immediately following a ref name and the ref must have an existing
+ log ($GIT_DIR/logs/<ref>).
+
+* You can use the '@' construct with an empty ref part to get at a
+ reflog of the current branch. For example, if you are on the
+ branch 'blabla', then '@\{1\}' means the same as 'blabla@\{1\}'.
+
+* A suffix '{caret}' to a revision parameter means the first parent of
+ that commit object. '{caret}<n>' means the <n>th parent (i.e.
+ 'rev{caret}'
+ is equivalent to 'rev{caret}1'). As a special rule,
+ 'rev{caret}0' means the commit itself and is used when 'rev' is the
+ object name of a tag object that refers to a commit object.
+
+* A suffix '{tilde}<n>' to a revision parameter means the commit
+ object that is the <n>th generation grand-parent of the named
+ commit object, following only the first parent. I.e. rev~3 is
+ equivalent to rev{caret}{caret}{caret} which is equivalent to
+ rev{caret}1{caret}1{caret}1. See below for a illustration of
+ the usage of this form.
+
+* A suffix '{caret}' followed by an object type name enclosed in
+ brace pair (e.g. `v0.99.8{caret}\{commit\}`) means the object
+ could be a tag, and dereference the tag recursively until an
+ object of that type is found or the object cannot be
+ dereferenced anymore (in which case, barf). `rev{caret}0`
+ introduced earlier is a short-hand for `rev{caret}\{commit\}`.
+
+* A suffix '{caret}' followed by an empty brace pair
+ (e.g. `v0.99.8{caret}\{\}`) means the object could be a tag,
+ and dereference the tag recursively until a non-tag object is
+ found.
+
+* A colon, followed by a slash, followed by a text: this names
+ a commit whose commit message starts with the specified text.
+ This name returns the youngest matching commit which is
+ reachable from any ref. If the commit message starts with a
+ '!', you have to repeat that; the special sequence ':/!',
+ followed by something else than '!' is reserved for now.
+
+* A suffix ':' followed by a path; this names the blob or tree
+ at the given path in the tree-ish object named by the part
+ before the colon.
+
+* A colon, optionally followed by a stage number (0 to 3) and a
+ colon, followed by a path; this names a blob object in the
+ index at the given path. Missing stage number (and the colon
+ that follows it) names a stage 0 entry. During a merge, stage
+ 1 is the common ancestor, stage 2 is the target branch's version
+ (typically the current branch), and stage 3 is the version from
+ the branch being merged.
+
+Here is an illustration, by Jon Loeliger. Both commit nodes B
+and C are parents of commit node A. Parent commits are ordered
+left-to-right.
+
+........................................
+G H I J
+ \ / \ /
+ D E F
+ \ | / \
+ \ | / |
+ \|/ |
+ B C
+ \ /
+ \ /
+ A
+........................................
+
+ A = = A^0
+ B = A^ = A^1 = A~1
+ C = A^2 = A^2
+ D = A^^ = A^1^1 = A~2
+ E = B^2 = A^^2
+ F = B^3 = A^^3
+ G = A^^^ = A^1^1^1 = A~3
+ H = D^2 = B^^2 = A^^^2 = A~2^2
+ I = F^ = B^3^ = A^^3^
+ J = F^2 = B^3^2 = A^^3^2
+
+
+SPECIFYING RANGES
+-----------------
+
+History traversing commands such as `git-log` operate on a set
+of commits, not just a single commit. To these commands,
+specifying a single revision with the notation described in the
+previous section means the set of commits reachable from that
+commit, following the commit ancestry chain.
+
+To exclude commits reachable from a commit, a prefix `{caret}`
+notation is used. E.g. "`{caret}r1 r2`" means commits reachable
+from `r2` but exclude the ones reachable from `r1`.
+
+This set operation appears so often that there is a shorthand
+for it. "`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 is the set of commits that are reachable from either one of
+`r1` or `r2` but not from both.
+
+Two other shorthands for naming a set that is formed by a commit
+and its parent commits exists. `r1{caret}@` notation means all
+parents of `r1`. `r1{caret}!` includes commit `r1` but excludes
+its all parents.
+
+Here are a handful of examples:
+
+ D G H D
+ D F G H I J D F
+ ^G D H D
+ ^D B E I J F B
+ B...C G H D E B C
+ ^D B C E I J F B C
+ C^@ I J F
+ F^! D G H D F
+
+PARSEOPT
+--------
+
+In `--parseopt` mode, `git-rev-parse` helps massaging options to bring to shell
+scripts the same facilities C builtins have. It works as an option normalizer
+(e.g. splits single switches aggregate values), a bit like `getopt(1)` does.
+
+It takes on the standard input the specification of the options to parse and
+understand, and echoes on the standard output a line suitable for `sh(1)` `eval`
+to replace the arguments with normalized ones. In case of error, it outputs
+usage on the standard error stream, and exits with code 129.
+
+Input Format
+~~~~~~~~~~~~
+
+`git-rev-parse --parseopt` input format is fully text based. It has two parts,
+separated by a line that contains only `--`. The lines before the separator
+(should be more than one) are used for the usage.
+The lines after the separator describe the options.
+
+Each line of options has this format:
+
+------------
+<opt_spec><flags>* SP+ help LF
+------------
+
+`<opt_spec>`::
+ its format is the short option character, then the long option name
+ separated by a comma. Both parts are not required, though at least one
+ is necessary. `h,help`, `dry-run` and `f` are all three correct
+ `<opt_spec>`.
+
+`<flags>`::
+ `<flags>` are of `*`, `=`, `?` or `!`.
+ * Use `=` if the option takes an argument.
+
+ * Use `?` to mean that the option is optional (though its use is discouraged).
+
+ * Use `*` to mean that this option should not be listed in the usage
+ generated for the `-h` argument. It's shown for `--help-all` as
+ documented in linkgit:gitcli[7].
+
+ * Use `!` to not make the corresponding negated long option available.
+
+The remainder of the line, after stripping the spaces, is used
+as the help associated to the option.
+
+Blank lines are ignored, and lines that don't match this specification are used
+as option group headers (start the line with a space to create such
+lines on purpose).
+
+Example
+~~~~~~~
+
+------------
+OPTS_SPEC="\
+some-command [options] <args>...
+
+some-command does foo and bar!
+--
+h,help show the help
+
+foo some nifty option --foo
+bar= some cool option --bar with an argument
+
+ An option group Header
+C? option C with an optional argument"
+
+eval `echo "$OPTS_SPEC" | git-rev-parse --parseopt -- "$@" || echo exit $?`
+------------
+
+EXAMPLES
+--------
+
+* Print the object name of the current commit:
++
+------------
+$ git rev-parse --verify HEAD
+------------
+
+* Print the commit object name from the revision in the $REV shell variable:
++
+------------
+$ git rev-parse --verify $REV
+------------
++
+This will error out if $REV is empty or not a valid revision.
+
+* Same as above:
++
+------------
+$ git rev-parse --default master --verify $REV
+------------
++
+but if $REV is empty, the commit object name from master will be printed.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> .
+Junio C Hamano <junkio@cox.net> and Pierre Habouzit <madcoder@debian.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
new file mode 100644
index 0000000000..5b49b81386
--- /dev/null
+++ b/Documentation/git-revert.txt
@@ -0,0 +1,72 @@
+git-revert(1)
+=============
+
+NAME
+----
+git-revert - Revert an existing commit
+
+SYNOPSIS
+--------
+'git-revert' [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>
+
+DESCRIPTION
+-----------
+Given one existing commit, revert the change the patch introduces, and record a
+new commit that records it. This requires your working tree to be clean (no
+modifications from the HEAD commit).
+
+OPTIONS
+-------
+<commit>::
+ Commit to revert.
+ For a more complete list of ways to spell commit names, see
+ "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
+
+-e::
+--edit::
+ With this option, `git-revert` will let you edit the commit
+ message prior to committing the revert. This is the default if
+ you run the command from a terminal.
+
+-m parent-number::
+--mainline parent-number::
+ Usually you cannot revert a merge because you do not know which
+ side of the merge should be considered the mainline. This
+ option specifies the parent number (starting from 1) of
+ the mainline and allows revert to reverse the change
+ relative to the specified parent.
+
+--no-edit::
+ With this option, `git-revert` will not start the commit
+ message editor.
+
+-n::
+--no-commit::
+ Usually the command automatically creates a commit with
+ a commit log message stating which commit was reverted.
+ This flag applies the change necessary to revert the
+ named commit to your working tree, but does not make the
+ commit. In addition, when this option is used, your
+ working tree does not have to match the HEAD commit.
+ The revert is done against the beginning state of your
+ working tree.
++
+This is useful when reverting more than one commits'
+effect to your working tree in a row.
+
+-s::
+--signoff::
+ Add Signed-off-by line at the end of the commit message.
+
+
+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 linkgit:git[1] suite
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
new file mode 100644
index 0000000000..d88554bedc
--- /dev/null
+++ b/Documentation/git-rm.txt
@@ -0,0 +1,112 @@
+git-rm(1)
+=========
+
+NAME
+----
+git-rm - Remove files from the working tree and from the index
+
+SYNOPSIS
+--------
+'git-rm' [-f] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>...
+
+DESCRIPTION
+-----------
+Remove files from the index, or from the working tree and the index.
+`git rm` will not remove a file from just your working directory.
+(There is no option to remove a file only from the work tree
+and yet keep it in the index; use `/bin/rm` if you want to do that.)
+The files being removed have to be identical to the tip of the branch,
+and no updates to their contents can be staged in the index,
+though that default behavior can be overridden with the `-f` option.
+When '--cached' is given, the staged content has to
+match either the tip of the branch or the file on disk,
+allowing the file to be removed from just the index.
+
+
+OPTIONS
+-------
+<file>...::
+ Files to remove. Fileglobs (e.g. `*.c`) can be given to
+ remove all matching files. If you want git to expand
+ file glob characters, you may need to shell-escape them.
+ A leading directory name
+ (e.g. `dir` to remove `dir/file1` and `dir/file2`) can be
+ given to remove all files in the directory, and recursively
+ all sub-directories,
+ but this requires the `-r` option to be explicitly given.
+
+-f::
+ Override the up-to-date check.
+
+-n::
+--dry-run::
+ Don't actually remove any file(s). Instead, just show
+ if they exist in the index and would otherwise be removed
+ by the command.
+
+-r::
+ Allow recursive removal when a leading directory name is
+ given.
+
+\--::
+ 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).
+
+--cached::
+ Use this option to unstage and remove paths only from the index.
+ Working tree files, whether modified or not, will be
+ left alone.
+
+--ignore-unmatch::
+ Exit with a zero status even if no files matched.
+
+-q::
+--quiet::
+ git-rm normally outputs one line (in the form of an "rm" command)
+ for each file removed. This option suppresses that output.
+
+
+DISCUSSION
+----------
+
+The <file> list given to the command can be exact pathnames,
+file glob patterns, or leading directory names. The command
+removes only the paths that are known to git. Giving the name of
+a file that you have not told git about does not remove that file.
+
+File globbing matches across directory boundaries. Thus, given
+two directories `d` and `d2`, there is a difference between
+using `git rm \'d\*\'` and `git rm \'d/\*\'`, as the former will
+also remove all of directory `d2`.
+
+EXAMPLES
+--------
+git-rm Documentation/\\*.txt::
+ Removes all `\*.txt` files from the index that are under the
+ `Documentation` directory and any of its subdirectories.
++
+Note that the asterisk `\*` is quoted from the shell in this
+example; this lets git, and not the shell, expand the pathnames
+of files and subdirectories under the `Documentation/` directory.
+
+git-rm -f git-*.sh::
+ 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
+--------
+linkgit: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 linkgit:git[1] suite
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
new file mode 100644
index 0000000000..251d661afd
--- /dev/null
+++ b/Documentation/git-send-email.txt
@@ -0,0 +1,248 @@
+git-send-email(1)
+=================
+
+NAME
+----
+git-send-email - Send a collection of patches as emails
+
+
+SYNOPSIS
+--------
+'git-send-email' [options] <file|directory> [... file|directory]
+
+
+
+DESCRIPTION
+-----------
+Takes the patches given on the command line and emails them out.
+
+The header of the email is configurable by command line options. If not
+specified on the command line, the user will be prompted with a ReadLine
+enabled interface to provide the necessary information.
+
+OPTIONS
+-------
+The options available are:
+
+--bcc::
+ Specify a "Bcc:" value for each email.
++
+The --bcc option must be repeated for each user you want on the bcc list.
+
+--cc::
+ Specify a starting "Cc:" value for each email.
++
+The --cc option must be repeated for each user you want on the cc list.
+
+--cc-cmd::
+ Specify a command to execute once per patch file which
+ should generate patch file specific "Cc:" entries.
+ Output of this command must be single email address per line.
+ Default is the value of 'sendemail.cccmd' configuration value.
+
+--chain-reply-to::
+--no-chain-reply-to::
+ If this is set, each email will be sent as a reply to the previous
+ email sent. If disabled with "--no-chain-reply-to", all emails after
+ the first will be sent as replies to the first email sent. When using
+ this, it is recommended that the first file given be an overview of the
+ entire patch series.
+ Default is the value of the 'sendemail.chainreplyto' configuration
+ value; if that is unspecified, default to --chain-reply-to.
+
+--compose::
+ Use $GIT_EDITOR, core.editor, $VISUAL, or $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.
+
+--signed-off-by-cc::
+--no-signed-off-by-cc::
+ If this is set, add emails found in Signed-off-by: or Cc: lines to the
+ cc list.
+ Default is the value of 'sendemail.signedoffcc' configuration value;
+ if that is unspecified, default to --signed-off-by-cc.
+
+--quiet::
+ Make git-send-email less verbose. One line per email should be
+ all that is output.
+
+--identity::
+ A configuration identity. When given, causes values in the
+ 'sendemail.<identity>' subsection to take precedence over
+ values in the 'sendemail' section. The default identity is
+ the value of 'sendemail.identity'.
+
+--smtp-server::
+ If set, specifies the outgoing SMTP server to use (e.g.
+ `smtp.example.com` or a raw IP address). Alternatively it can
+ specify a full pathname of a sendmail-like program instead;
+ the program must support the `-i` option. Default value can
+ be specified by the 'sendemail.smtpserver' configuration
+ option; the built-in default is `/usr/sbin/sendmail` or
+ `/usr/lib/sendmail` if such program is available, or
+ `localhost` otherwise.
+
+--smtp-server-port::
+ Specifies a port different from the default port (SMTP
+ servers typically listen to smtp port 25 and ssmtp port
+ 465).
+
+--smtp-user::
+ Username for SMTP-AUTH. In place of this option, the following
+ configuration variables can be specified:
++
+--
+ * sendemail.smtpuser
+ * sendemail.<identity>.smtpuser (see sendemail.identity).
+--
++
+However, --smtp-user always overrides these variables.
++
+If a username is not specified (with --smtp-user or a
+configuration variable), then authentication is not attempted.
+
+--smtp-pass::
+ Password for SMTP-AUTH. The argument is optional: If no
+ argument is specified, then the empty string is used as
+ the password.
++
+In place of this option, the following configuration variables
+can be specified:
++
+--
+ * sendemail.smtppass
+ * sendemail.<identity>.smtppass (see sendemail.identity).
+--
++
+However, --smtp-pass always overrides these variables.
++
+Furthermore, passwords need not be specified in configuration files
+or on the command line. If a username has been specified (with
+--smtp-user or a configuration variable), but no password has been
+specified (with --smtp-pass or a configuration variable), then the
+user is prompted for a password while the input is masked for privacy.
+
+--smtp-ssl::
+ If set, connects to the SMTP server using SSL.
+ Default is the value of the 'sendemail.smtpssl' configuration value;
+ if that is unspecified, does not use SSL.
+
+--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::
+--no-suppress-from::
+ If this is set, do not add the From: address to the cc: list.
+ Default is the value of 'sendemail.suppressfrom' configuration value;
+ if that is unspecified, default to --no-suppress-from.
+
+--suppress-cc::
+ Specify an additional category of recipients to suppress the
+ auto-cc of. 'self' will avoid including the sender, 'author' will
+ avoid including the patch author, 'cc' will avoid including anyone
+ mentioned in Cc lines in the patch, 'sob' will avoid including
+ anyone mentioned in Signed-off-by lines, and 'cccmd' will avoid
+ running the --cc-cmd. 'all' will suppress all auto cc values.
+ Default is the value of 'sendemail.suppresscc' configuration value;
+ if that is unspecified, default to 'self' if --suppress-from is
+ specified, as well as 'sob' if --no-signed-off-cc is specified.
+
+--thread::
+--no-thread::
+ If this is set, the In-Reply-To header will be set on each email sent.
+ If disabled with "--no-thread", no emails will have the In-Reply-To
+ header set.
+ Default is the value of the 'sendemail.thread' configuration value;
+ if that is unspecified, default to --thread.
+
+--dry-run::
+ Do everything except actually send the emails.
+
+--envelope-sender::
+ Specify the envelope sender used to send the emails.
+ This is useful if your default address is not the address that is
+ subscribed to a list. If you use the sendmail binary, you must have
+ suitable privileges for the -f parameter.
+
+--to::
+ Specify the primary recipient of the emails generated.
+ Generally, this will be the upstream maintainer of the
+ project involved.
+ Default is the value of the 'sendemail.to' configuration value;
+ if that is unspecified, this will be prompted for.
++
+The --to option must be repeated for each user you want on the to list.
+
+
+CONFIGURATION
+-------------
+sendemail.identity::
+ The default configuration identity. When specified,
+ 'sendemail.<identity>.<item>' will have higher precedence than
+ 'sendemail.<item>'. This is useful to declare multiple SMTP
+ identities and to hoist sensitive authentication information
+ out of the repository and into the global configuration file.
+
+sendemail.aliasesfile::
+ To avoid typing long email addresses, point this to one or more
+ email aliases files. You must also supply 'sendemail.aliasfiletype'.
+
+sendemail.aliasfiletype::
+ Format of the file(s) specified in sendemail.aliasesfile. Must be
+ one of 'mutt', 'mailrc', 'pine', or 'gnus'.
+
+sendemail.to::
+ Email address (or alias) to always send to.
+
+sendemail.cccmd::
+ Command to execute to generate per patch file specific "Cc:"s.
+
+sendemail.bcc::
+ Email address (or alias) to always bcc.
+
+sendemail.chainreplyto::
+ Boolean value specifying the default to the '--chain_reply_to'
+ parameter.
+
+sendemail.smtpserver::
+ Default SMTP server to use.
+
+sendemail.smtpserverport::
+ Default SMTP server port to use.
+
+sendemail.smtpuser::
+ Default SMTP-AUTH username.
+
+sendemail.smtppass::
+ Default SMTP-AUTH password.
+
+sendemail.smtpssl::
+ Boolean value specifying the default to the '--smtp-ssl' parameter.
+
+Author
+------
+Written by Ryan Anderson <ryan@michonline.com>
+
+git-send-email is originally based upon
+send_lots_of_email.pl by Greg Kroah-Hartman.
+
+Documentation
+--------------
+Documentation by Ryan Anderson
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
new file mode 100644
index 0000000000..ba2fdaec08
--- /dev/null
+++ b/Documentation/git-send-pack.txt
@@ -0,0 +1,128 @@
+git-send-pack(1)
+================
+
+NAME
+----
+git-send-pack - Push objects over git protocol to another repository
+
+
+SYNOPSIS
+--------
+'git-send-pack' [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]
+
+DESCRIPTION
+-----------
+Usually you would want to use linkgit:git-push[1] which is a
+higher level wrapper of this command instead.
+
+Invokes 'git-receive-pack' on a possibly remote repository, and
+updates it from the current repository, sending named refs.
+
+
+OPTIONS
+-------
+--receive-pack=<git-receive-pack>::
+ Path to the 'git-receive-pack' program on the remote
+ end. Sometimes useful when pushing to a remote
+ repository over ssh, and you do not have the program in
+ a directory on the default $PATH.
+
+--exec=<git-receive-pack>::
+ Same as \--receive-pack=<git-receive-pack>.
+
+--all::
+ Instead of explicitly specifying which refs to update,
+ update all heads that locally exist.
+
+--dry-run::
+ Do everything except actually send the updates.
+
+--force::
+ Usually, the command refuses to update a remote ref that
+ is not an ancestor of the local ref used to overwrite it.
+ This flag disables the check. What this means is that
+ the remote repository can lose commits; use it with
+ care.
+
+--verbose::
+ Run verbosely.
+
+--thin::
+ Spend extra cycles to minimize the number of objects to be sent.
+ Use it on slower connection.
+
+<host>::
+ A remote host to house the repository. When this
+ part is specified, 'git-receive-pack' is invoked via
+ ssh.
+
+<directory>::
+ The repository to update.
+
+<ref>...::
+ The remote refs to update.
+
+
+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 transferred to
+the remote side. You cannot specify any '<ref>' if you use
+this flag.
+
+Without '--all' and without any '<ref>', the heads that exist
+both on the local side and on the remote side are updated.
+
+When one or more '<ref>' are specified explicitly, it can be either a
+single pattern, or a pair of such pattern separated by a colon
+":" (this means that a ref name cannot have a colon in it). A
+single pattern '<name>' is just a shorthand for '<name>:<name>'.
+
+Each pattern pair consists of the source side (before the colon)
+and the destination side (after the colon). The ref to be
+pushed is determined by finding a match that matches the source
+side, and where it is pushed is determined by using the
+destination side. The rules used to match a ref are the same
+rules used by linkgit:git-rev-parse[1] to resolve a symbolic ref
+name.
+
+ - It is an error if <src> does not match exactly one of the
+ local refs.
+
+ - It is an error if <dst> matches more than one remote refs.
+
+ - If <dst> does not match any remote ref, either
+
+ * it has to start with "refs/"; <dst> is used as the
+ destination literally in this case.
+
+ * <src> == <dst> and the ref that matched the <src> must not
+ exist in the set of remote refs; the ref matched <src>
+ locally is used as the name of the destination.
+
+Without '--force', the <src> ref is stored at the remote only if
+<dst> does not exist, or <dst> is a proper subset (i.e. an
+ancestor) of <src>. This check, known as "fast forward check",
+is performed in order to avoid accidentally overwriting the
+remote ref and lose other peoples' commits from there.
+
+With '--force', the fast forward check is disabled for all refs.
+
+Optionally, a <ref> parameter can be prefixed with a plus '+' sign
+to disable the fast-forward check only on that ref.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt
new file mode 100644
index 0000000000..c543170342
--- /dev/null
+++ b/Documentation/git-sh-setup.txt
@@ -0,0 +1,80 @@
+git-sh-setup(1)
+===============
+
+NAME
+----
+git-sh-setup - Common git shell script setup code
+
+SYNOPSIS
+--------
+'git-sh-setup'
+
+DESCRIPTION
+-----------
+
+This is not a command the end user would want to run. Ever.
+This documentation is meant for people who are studying the
+Porcelain-ish scripts and/or are writing new ones.
+
+The `git-sh-setup` scriptlet is designed to be sourced (using
+`.`) by other shell scripts to set up some variables pointing at
+the normal git directories and a few helper shell functions.
+
+Before sourcing it, your script should set up a few variables;
+`USAGE` (and `LONG_USAGE`, if any) is used to define message
+given by `usage()` shell function. `SUBDIRECTORY_OK` can be set
+if the script can run from a subdirectory of the working tree
+(some commands do not).
+
+The scriptlet sets `GIT_DIR` and `GIT_OBJECT_DIRECTORY` shell
+variables, but does *not* export them to the environment.
+
+FUNCTIONS
+---------
+
+die::
+ exit after emitting the supplied error message to the
+ standard error stream.
+
+usage::
+ die with the usage message.
+
+set_reflog_action::
+ set the message that will be recorded to describe the
+ end-user action in the reflog, when the script updates a
+ ref.
+
+git_editor::
+ runs an editor of user's choice (GIT_EDITOR, core.editor, VISUAL or
+ EDITOR) on a given file, but error out if no editor is specified
+ and the terminal is dumb.
+
+is_bare_repository::
+ outputs `true` or `false` to the standard output stream
+ to indicate if the repository is a bare repository
+ (i.e. without an associated working tree).
+
+cd_to_toplevel::
+ runs chdir to the toplevel of the working tree.
+
+require_work_tree::
+ checks if the repository is a bare repository, and dies
+ if so. Used by scripts that require working tree
+ (e.g. `checkout`).
+
+get_author_ident_from_commit::
+ outputs code for use with eval to set the GIT_AUTHOR_NAME,
+ GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE variables for a given commit.
+
+
+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 linkgit:git[1] suite
diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt
new file mode 100644
index 0000000000..bd09196acc
--- /dev/null
+++ b/Documentation/git-shell.txt
@@ -0,0 +1,34 @@
+git-shell(1)
+============
+
+NAME
+----
+git-shell - Restricted login shell for GIT-only SSH access
+
+
+SYNOPSIS
+--------
+'git-shell' -c <command> <argument>
+
+DESCRIPTION
+-----------
+This is meant to be used as a login shell for SSH accounts you want
+to restrict to GIT pull/push access only. It permits execution only
+of server-side GIT commands implementing the pull/push functionality.
+The commands can be executed only by the '-c' option; the shell is not
+interactive.
+
+Currently, only the `git-receive-pack` and `git-upload-pack` commands
+are permitted to be called, with a single required argument.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Petr Baudis and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt
new file mode 100644
index 0000000000..daa64d4d81
--- /dev/null
+++ b/Documentation/git-shortlog.txt
@@ -0,0 +1,72 @@
+git-shortlog(1)
+===============
+
+NAME
+----
+git-shortlog - Summarize 'git log' output
+
+SYNOPSIS
+--------
+[verse]
+git-log --pretty=short | 'git-shortlog' [-h] [-n] [-s] [-e] [-w]
+git-shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] [<committish>...]
+
+DESCRIPTION
+-----------
+Summarizes 'git log' output in a format suitable for inclusion
+in release announcements. Each commit will be grouped by author and
+the first line of the commit message will be shown.
+
+Additionally, "[PATCH]" will be stripped from the commit description.
+
+OPTIONS
+-------
+
+-h::
+--help::
+ Print a short usage message and exit.
+
+-n::
+--numbered::
+ Sort output according to the number of commits per author instead
+ of author alphabetic order.
+
+-s::
+--summary::
+ Suppress commit description and provide a commit count summary only.
+
+-e::
+--email::
+ Show the email address of each author.
+
+-w[<width>[,<indent1>[,<indent2>]]]::
+ Linewrap the output by wrapping each line at `width`. The first
+ line of each entry is indented by `indent1` spaces, and the second
+ and subsequent lines are indented by `indent2` spaces. `width`,
+ `indent1`, and `indent2` default to 76, 6 and 9 respectively.
+
+FILES
+-----
+
+If the file `.mailmap` 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
+------
+Written by Jeff Garzik <jgarzik@pobox.com>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
new file mode 100644
index 0000000000..de9e8f885f
--- /dev/null
+++ b/Documentation/git-show-branch.txt
@@ -0,0 +1,195 @@
+git-show-branch(1)
+==================
+
+NAME
+----
+git-show-branch - Show branches and their commits
+
+SYNOPSIS
+--------
+[verse]
+'git-show-branch' [--all] [--remotes] [--topo-order] [--current]
+ [--more=<n> | --list | --independent | --merge-base]
+ [--no-name | --sha1-name] [--topics] [<rev> | <glob>]...
+'git-show-branch' (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>]
+
+DESCRIPTION
+-----------
+
+Shows the commit ancestry graph starting from the commits named
+with <rev>s or <globs>s (or all refs under $GIT_DIR/refs/heads
+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
+-------
+<rev>::
+ Arbitrary extended SHA1 expression (see `git-rev-parse`)
+ that typically names a branch HEAD or a tag.
+
+<glob>::
+ A glob pattern that matches branch or tag names under
+ $GIT_DIR/refs. For example, if you have many topic
+ branches under $GIT_DIR/refs/heads/topic, giving
+ `topic/*` would show all of them.
+
+-r::
+--remotes::
+ Show the remote-tracking branches.
+
+-a::
+--all::
+ Show both remote-tracking branches and local branches.
+
+--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
+ flag tells the command to go <n> more common commits
+ beyond that. When <n> is negative, display only the
+ <reference>s given, without showing the commit ancestry
+ tree.
+
+--list::
+ Synonym to `--more=-1`
+
+--merge-base::
+ Instead of showing the commit list, just act like the
+ 'git-merge-base -a' command, except that it can accept
+ more than two heads.
+
+--independent::
+ Among the <reference>s given, display only the ones that
+ cannot be reached from any other <reference>.
+
+--no-name::
+ Do not show naming strings for each commit.
+
+--sha1-name::
+ Instead of naming the commits using the path to reach
+ them from heads (e.g. "master~2" to mean the grandparent
+ of "master"), name them with the unique prefix of their
+ object names.
+
+--topics::
+ Shows only commits that are NOT on the first branch given.
+ This helps track topic branches by hiding any commit that
+ is already in the main line of development. When given
+ "git show-branch --topics master topic1 topic2", this
+ will show the revisions given by "git rev-list {caret}master
+ topic1 topic2"
+
+--reflog[=<n>[,<base>]] [<ref>]::
+ Shows <n> most recent ref-log entries for the given
+ ref. If <base> is given, <n> entries going back from
+ that entry. <base> can be specified as count or date.
+ `-g` can be used as a short-hand for this option. When
+ no explicit <ref> parameter is given, it defaults to the
+ current branch (or `HEAD` if it is detached).
+
+Note that --more, --list, --independent and --merge-base options
+are mutually exclusive.
+
+
+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 `*`
+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;
+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"
+and "mhf":
+
+------------------------------------------------
+$ git show-branch master fixes mhf
+* [master] Add 'git show-branch'.
+ ! [fixes] Introduce "reset type" flag to "git reset"
+ ! [mhf] Allow "+remote:local" refspec to cause --force when fetching.
+---
+ + [mhf] Allow "+remote:local" refspec to cause --force when fetching.
+ + [mhf~1] Use git-octopus when pulling more than one heads.
+ + [fixes] Introduce "reset type" flag to "git reset"
+ + [mhf~2] "git fetch --force".
+ + [mhf~3] Use .git/remote/origin, not .git/branches/origin.
+ + [mhf~4] Make "git pull" and "git fetch" default to origin
+ + [mhf~5] Infamous 'octopus merge'
+ + [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'.
+------------------------------------------------
+
+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. 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.
+
+------------
+$ git show-branch --reflog='10,1 hour ago' --list master
+------------
+
+shows 10 reflog entries going back from the tip as of 1 hour ago.
+Without `--list`, the output also shows how these tips are
+topologically related with each other.
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-show-index.txt b/Documentation/git-show-index.txt
new file mode 100644
index 0000000000..891f0eff27
--- /dev/null
+++ b/Documentation/git-show-index.txt
@@ -0,0 +1,34 @@
+git-show-index(1)
+=================
+
+NAME
+----
+git-show-index - Show packed archive index
+
+
+SYNOPSIS
+--------
+'git-show-index' < idx-file
+
+
+DESCRIPTION
+-----------
+Reads given idx file for packed git archive created with
+git-pack-objects command, and dumps its contents.
+
+The information it outputs is subset of what you can get from
+'git-verify-pack -v'; this command only shows the packfile
+offset and SHA1 of each object.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
new file mode 100644
index 0000000000..6b99529b6b
--- /dev/null
+++ b/Documentation/git-show-ref.txt
@@ -0,0 +1,179 @@
+git-show-ref(1)
+===============
+
+NAME
+----
+git-show-ref - List references in a local repository
+
+SYNOPSIS
+--------
+[verse]
+'git-show-ref' [-q|--quiet] [--verify] [-h|--head] [-d|--dereference]
+ [-s|--hash] [--abbrev] [--tags] [--heads] [--] <pattern>...
+'git-show-ref' --exclude-existing[=pattern]
+
+DESCRIPTION
+-----------
+
+Displays references available in a local repository along with the associated
+commit IDs. Results can be filtered using a pattern and tags can be
+dereferenced into object IDs. Additionally, it can be used to test whether a
+particular ref exists.
+
+The --exclude-existing form is a filter that does the inverse, it shows the
+refs from stdin that don't exist in the local repository.
+
+Use of this utility is encouraged in favor of directly accessing files under
+in the `.git` directory.
+
+OPTIONS
+-------
+
+-h::
+--head::
+
+ Show the HEAD reference.
+
+--tags::
+--heads::
+
+ Limit to only "refs/heads" and "refs/tags", respectively. These
+ options are not mutually exclusive; when given both, references stored
+ in "refs/heads" and "refs/tags" are displayed.
+
+-d::
+--dereference::
+
+ Dereference tags into object IDs as well. They will be shown with "^{}"
+ appended.
+
+-s::
+--hash::
+
+ Only show the SHA1 hash, not the reference name. When also using
+ --dereference the dereferenced tag will still be shown after the SHA1.
+
+--verify::
+
+ Enable stricter reference checking by requiring an exact ref path.
+ Aside from returning an error code of 1, it will also print an error
+ message if '--quiet' was not specified.
+
+--abbrev::
+--abbrev=len::
+
+ Abbreviate the object name. When using `--hash`, you do
+ not have to say `--hash --abbrev`; `--hash=len` would do.
+
+-q::
+--quiet::
+
+ Do not print any results to stdout. When combined with '--verify' this
+ can be used to silently check if a reference exists.
+
+--exclude-existing::
+--exclude-existing=pattern::
+
+ Make git-show-ref act as a filter that reads refs from stdin of the
+ form "^(?:<anything>\s)?<refname>(?:\^\{\})?$" and performs the
+ following actions on each:
+ (1) strip "^{}" at the end of line if any;
+ (2) ignore if pattern is provided and does not head-match refname;
+ (3) warn if refname is not a well-formed refname and skip;
+ (4) ignore if refname is a ref that exists in the local repository;
+ (5) otherwise output the line.
+
+
+<pattern>::
+
+ Show references matching one or more patterns.
+
+OUTPUT
+------
+
+The output is in the format: '<SHA-1 ID>' '<space>' '<reference name>'.
+
+-----------------------------------------------------------------------------
+$ git show-ref --head --dereference
+832e76a9899f560a90ffd62ae2ce83bbeff58f54 HEAD
+832e76a9899f560a90ffd62ae2ce83bbeff58f54 refs/heads/master
+832e76a9899f560a90ffd62ae2ce83bbeff58f54 refs/heads/origin
+3521017556c5de4159da4615a39fa4d5d2c279b5 refs/tags/v0.99.9c
+6ddc0964034342519a87fe013781abf31c6db6ad refs/tags/v0.99.9c^{}
+055e4ae3ae6eb344cbabf2a5256a49ea66040131 refs/tags/v1.0rc4
+423325a2d24638ddcc82ce47be5e40be550f4507 refs/tags/v1.0rc4^{}
+...
+-----------------------------------------------------------------------------
+
+When using --hash (and not --dereference) the output format is: '<SHA-1 ID>'
+
+-----------------------------------------------------------------------------
+$ git show-ref --heads --hash
+2e3ba0114a1f52b47df29743d6915d056be13278
+185008ae97960c8d551adcd9e23565194651b5d1
+03adf42c988195b50e1a1935ba5fcbc39b2b029b
+...
+-----------------------------------------------------------------------------
+
+EXAMPLE
+-------
+
+To show all references called "master", whether tags or heads or anything
+else, and regardless of how deep in the reference naming hierarchy they are,
+use:
+
+-----------------------------------------------------------------------------
+ git show-ref master
+-----------------------------------------------------------------------------
+
+This will show "refs/heads/master" but also "refs/remote/other-repo/master",
+if such references exists.
+
+When using the '--verify' flag, the command requires an exact path:
+
+-----------------------------------------------------------------------------
+ git show-ref --verify refs/heads/master
+-----------------------------------------------------------------------------
+
+will only match the exact branch called "master".
+
+If nothing matches, linkgit:git-show-ref[1] will return an error code of 1,
+and in the case of verification, it will show an error message.
+
+For scripting, you can ask it to be quiet with the "--quiet" flag, which
+allows you to do things like
+
+-----------------------------------------------------------------------------
+ git-show-ref --quiet --verify -- "refs/heads/$headname" ||
+ echo "$headname is not a valid branch"
+-----------------------------------------------------------------------------
+
+to check whether a particular branch exists or not (notice how we don't
+actually want to show any results, and we want to use the full refname for it
+in order to not trigger the problem with ambiguous partial matches).
+
+To show only tags, or only proper branch heads, use "--tags" and/or "--heads"
+respectively (using both means that it shows tags and heads, but not other
+random references under the refs/ subdirectory).
+
+To do automatic tag object dereferencing, use the "-d" or "--dereference"
+flag, so you can do
+
+-----------------------------------------------------------------------------
+ git show-ref --tags --dereference
+-----------------------------------------------------------------------------
+
+to get a listing of all tags together with what they dereference.
+
+SEE ALSO
+--------
+linkgit:git-ls-remote[1]
+
+AUTHORS
+-------
+Written by Linus Torvalds <torvalds@osdl.org>.
+Man page by Jonas Fonseca <fonseca@diku.dk>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
new file mode 100644
index 0000000000..baaf2bc8fe
--- /dev/null
+++ b/Documentation/git-show.txt
@@ -0,0 +1,84 @@
+git-show(1)
+===========
+
+NAME
+----
+git-show - Show various types of objects
+
+
+SYNOPSIS
+--------
+'git-show' [options] <object>...
+
+DESCRIPTION
+-----------
+Shows one or more objects (blobs, trees, tags and commits).
+
+For commits it shows the log message and textual diff. It also
+presents the merge commit in a special format as produced by
+'git-diff-tree --cc'.
+
+For tags, it shows the tag message and the referenced objects.
+
+For trees, it shows the names (equivalent to linkgit:git-ls-tree[1]
+with \--name-only).
+
+For plain blobs, it shows the plain contents.
+
+The command takes options applicable to the linkgit:git-diff-tree[1] command to
+control how the changes the commit introduces are shown.
+
+This manual page describes only the most frequently used options.
+
+
+OPTIONS
+-------
+<object>::
+ The name of the object to show.
+ For a more complete list of ways to spell object names, see
+ "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
+
+include::pretty-options.txt[]
+
+
+include::pretty-formats.txt[]
+
+
+EXAMPLES
+--------
+
+git show v1.0.0::
+ Shows the tag `v1.0.0`, along with the object the tags
+ points at.
+
+git show v1.0.0^\{tree\}::
+ Shows the tree pointed to by the tag `v1.0.0`.
+
+git show next~10:Documentation/README::
+ Shows the contents of the file `Documentation/README` as
+ they were current in the 10th last commit of the branch
+ `next`.
+
+git show master:Makefile master:t/Makefile::
+ Concatenates the contents of said Makefiles in the head
+ of the branch `master`.
+
+Discussion
+----------
+
+include::i18n.txt[]
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>. Significantly enhanced by
+Johannes Schindelin <Johannes.Schindelin@gmx.de>.
+
+
+Documentation
+-------------
+Documentation by David Greaves, Petr Baudis and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
new file mode 100644
index 0000000000..baa4f55b48
--- /dev/null
+++ b/Documentation/git-stash.txt
@@ -0,0 +1,185 @@
+git-stash(1)
+============
+
+NAME
+----
+git-stash - Stash the changes in a dirty working directory away
+
+SYNOPSIS
+--------
+[verse]
+'git-stash' (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>] | pop [<stash>])
+'git-stash' [save [<message>]]
+
+DESCRIPTION
+-----------
+
+Use 'git-stash' when you want to record the current state of the
+working directory and the index, but want to go back to a clean
+working directory. The command saves your local modifications away
+and reverts the working directory to match the `HEAD` commit.
+
+The modifications stashed away by this command can be listed with
+`git-stash list`, inspected with `git-stash show`, and restored
+(potentially on top of a different commit) with `git-stash apply`.
+Calling git-stash without any arguments is equivalent to `git-stash
+save`. A stash is by default listed as "WIP on 'branchname' ...", but
+you can give a more descriptive message on the command line when
+you create one.
+
+The latest stash you created is stored in `$GIT_DIR/refs/stash`; older
+stashes are found in the reflog of this reference and can be named using
+the usual reflog syntax (e.g. `stash@\{0}` is the most recently
+created stash, `stash@\{1}` is the one before it, `stash@\{2.hours.ago}`
+is also possible).
+
+OPTIONS
+-------
+
+save [<message>]::
+
+ Save your local modifications to a new 'stash', and run `git-reset
+ --hard` to revert them. This is the default action when no
+ subcommand is given. The <message> part is optional and gives
+ the description along with the stashed state.
+
+list [<options>]::
+
+ List the stashes that you currently have. Each 'stash' is listed
+ with its name (e.g. `stash@\{0}` is the latest stash, `stash@\{1}` is
+ the one before, etc.), the name of the branch that was current when the
+ stash was made, and a short description of the commit the stash was
+ based on.
++
+----------------------------------------------------------------
+stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation
+stash@{1}: On master: 9cc0589... Add git-stash
+----------------------------------------------------------------
++
+The command takes options applicable to the linkgit:git-log[1]
+command to control what is shown and how.
+
+show [<stash>]::
+
+ Show the changes recorded in the stash as a diff between the
+ stashed state and its original parent. When no `<stash>` is given,
+ shows the latest one. By default, the command shows the diffstat, but
+ it will accept any format known to `git-diff` (e.g., `git-stash show
+ -p stash@\{1}` to view the second most recent stash in patch form).
+
+apply [--index] [<stash>]::
+
+ Restore the changes recorded in the stash on top of the current
+ working tree state. When no `<stash>` is given, applies the latest
+ one. The working directory must match the index.
++
+This operation can fail with conflicts; you need to resolve them
+by hand in the working tree.
++
+If the `--index` option is used, then tries to reinstate not only the working
+tree's changes, but also the index's ones. However, this can fail, when you
+have conflicts (which are stored in the index, where you therefore can no
+longer apply the changes as they were originally).
+
+clear::
+ Remove all the stashed states. Note that those states will then
+ be subject to pruning, and may be difficult or impossible to recover.
+
+drop [<stash>]::
+
+ Remove a single stashed state from the stash list. When no `<stash>`
+ is given, it removes the latest one. i.e. `stash@\{0}`
+
+pop [<stash>]::
+
+ Remove a single stashed state from the stash list and apply on top
+ of the current working tree state. When no `<stash>` is given,
+ `stash@\{0}` is assumed. See also `apply`.
+
+
+DISCUSSION
+----------
+
+A stash is represented as a commit whose tree records the state of the
+working directory, and its first parent is the commit at `HEAD` when
+the stash was created. The tree of the second parent records the
+state of the index when the stash is made, and it is made a child of
+the `HEAD` commit. The ancestry graph looks like this:
+
+ .----W
+ / /
+ -----H----I
+
+where `H` is the `HEAD` commit, `I` is a commit that records the state
+of the index, and `W` is a commit that records the state of the working
+tree.
+
+
+EXAMPLES
+--------
+
+Pulling into a dirty tree::
+
+When you are in the middle of something, you learn that there are
+upstream changes that are possibly relevant to what you are
+doing. When your local changes do not conflict with the changes in
+the upstream, a simple `git pull` will let you move forward.
++
+However, there are cases in which your local changes do conflict with
+the upstream changes, and `git pull` refuses to overwrite your
+changes. In such a case, you can stash your changes away,
+perform a pull, and then unstash, like this:
++
+----------------------------------------------------------------
+$ git pull
+...
+file foobar not up to date, cannot merge.
+$ git stash
+$ git pull
+$ git stash apply
+----------------------------------------------------------------
+
+Interrupted workflow::
+
+When you are in the middle of something, your boss comes in and
+demands that you fix something immediately. Traditionally, you would
+make a commit to a temporary branch to store your changes away, and
+return to your original branch to make the emergency fix, like this:
++
+----------------------------------------------------------------
+... hack hack hack ...
+$ git checkout -b my_wip
+$ git commit -a -m "WIP"
+$ git checkout master
+$ edit emergency fix
+$ git commit -a -m "Fix in a hurry"
+$ git checkout my_wip
+$ git reset --soft HEAD^
+... continue hacking ...
+----------------------------------------------------------------
++
+You can use `git-stash` to simplify the above, like this:
++
+----------------------------------------------------------------
+... hack hack hack ...
+$ git stash
+$ edit emergency fix
+$ git commit -a -m "Fix in a hurry"
+$ git stash apply
+... continue hacking ...
+----------------------------------------------------------------
+
+SEE ALSO
+--------
+linkgit:git-checkout[1],
+linkgit:git-commit[1],
+linkgit:git-reflog[1],
+linkgit:git-reset[1]
+
+AUTHOR
+------
+Written by Nanako Shiraishi <nanako3@bluebottle.com>
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
new file mode 100644
index 0000000000..fef62b16df
--- /dev/null
+++ b/Documentation/git-status.txt
@@ -0,0 +1,75 @@
+git-status(1)
+=============
+
+NAME
+----
+git-status - Show the working tree status
+
+
+SYNOPSIS
+--------
+'git-status' <options>...
+
+DESCRIPTION
+-----------
+Displays paths that have differences between the index file and the
+current HEAD commit, paths that have differences between the working
+tree and the index file, and paths in the working tree that are not
+tracked by git (and are not ignored by linkgit:gitignore[5]). The first
+are what you _would_ commit by running `git commit`; the second and
+third are what you _could_ commit by running `git add` before running
+`git commit`.
+
+The command takes the same set of options as `git-commit`; it
+shows what would be committed if the same options are given to
+`git-commit`.
+
+If there is no path that is different between the index file and
+the current HEAD commit (i.e., there is nothing to commit by running
+`git-commit`), the command exits with non-zero status.
+
+
+OUTPUT
+------
+The output from this command is designed to be used as a commit
+template comment, and all the output lines are prefixed with '#'.
+
+The paths mentioned in the output, unlike many other git commands, are
+made relative to the current directory if you are working in a
+subdirectory (this is on purpose, to help cutting and pasting). See
+the status.relativePaths config option below.
+
+
+CONFIGURATION
+-------------
+
+The command honors `color.status` (or `status.color` -- they
+mean the same thing and the latter is kept for backward
+compatibility) and `color.status.<slot>` configuration variables
+to colorize its output.
+
+If the config variable `status.relativePaths` is set to false, then all
+paths shown are relative to the repository root, not to the current
+directory.
+
+If `status.submodulesummary` is set to a non zero number or true (identical
+to -1 or an unlimited number), the submodule summary will be enabled and a
+summary of commits for modified submodules will be shown (see --summary-limit
+option of linkgit:git-submodule[1]).
+
+SEE ALSO
+--------
+linkgit:gitignore[5]
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and
+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 linkgit:git[1] suite
diff --git a/Documentation/git-stripspace.txt b/Documentation/git-stripspace.txt
new file mode 100644
index 0000000000..8421a39f26
--- /dev/null
+++ b/Documentation/git-stripspace.txt
@@ -0,0 +1,36 @@
+git-stripspace(1)
+=================
+
+NAME
+----
+git-stripspace - Filter out empty lines
+
+
+SYNOPSIS
+--------
+'git-stripspace' [-s | --strip-comments] < <stream>
+
+DESCRIPTION
+-----------
+Remove multiple empty lines, and empty lines at beginning and end.
+
+OPTIONS
+-------
+-s::
+--strip-comments::
+ In addition to empty lines, also strip lines starting with '#'.
+
+<stream>::
+ Byte stream to act on.
+
+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 linkgit:git[1] suite
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
new file mode 100644
index 0000000000..441ae1483b
--- /dev/null
+++ b/Documentation/git-submodule.txt
@@ -0,0 +1,104 @@
+git-submodule(1)
+================
+
+NAME
+----
+git-submodule - Initialize, update or inspect submodules
+
+
+SYNOPSIS
+--------
+[verse]
+'git-submodule' [--quiet] add [-b branch] [--] <repository> [<path>]
+'git-submodule' [--quiet] status [--cached] [--] [<path>...]
+'git-submodule' [--quiet] init [--] [<path>...]
+'git-submodule' [--quiet] update [--init] [--] [<path>...]
+'git-submodule' [--quiet] summary [--summary-limit <n>] [commit] [--] [<path>...]
+
+
+COMMANDS
+--------
+add::
+ Add the given repository as a submodule at the given path
+ to the changeset to be committed next. If path is a valid
+ repository within the project, it is added as is. Otherwise,
+ repository is cloned at the specified path. path is added to the
+ changeset and registered in .gitmodules. If no path is
+ specified, the path is deduced from the repository specification.
+ If the repository url begins with ./ or ../, it is stored as
+ given but resolved as a relative path from the main project's
+ url when cloning.
+
+status::
+ Show the status of the submodules. This will print the SHA-1 of the
+ currently checked out commit for each submodule, along with the
+ submodule path and the output of linkgit:git-describe[1] for the
+ SHA-1. Each SHA-1 will be prefixed with `-` if the submodule is not
+ initialized and `+` if the currently checked out submodule commit
+ does not match the SHA-1 found in the index of the containing
+ repository. This command is the default command for git-submodule.
+
+init::
+ Initialize the submodules, i.e. register in .git/config each submodule
+ name and url found in .gitmodules. The key used in .git/config is
+ `submodule.$name.url`. This command does not alter existing information
+ in .git/config.
+
+update::
+ Update the registered submodules, i.e. clone missing submodules and
+ checkout the commit specified in the index of the containing repository.
+ This will make the submodules HEAD be detached.
++
+If the submodule is not yet initialized, and you just want to use the
+setting as stored in .gitmodules, you can automatically initialize the
+submodule with the --init option.
+
+summary::
+ Show commit summary between the given commit (defaults to HEAD) and
+ working tree/index. For a submodule in question, a series of commits
+ in the submodule between the given super project commit and the
+ index or working tree (switched by --cached) are shown.
+
+OPTIONS
+-------
+-q::
+--quiet::
+ Only print error messages.
+
+-b::
+--branch::
+ Branch of repository to add as submodule.
+
+--cached::
+ This option is only valid for status and summary commands. These
+ commands typically use the commit found in the submodule HEAD, but
+ with this option, the commit stored in the index is used instead.
+
+-n::
+--summary-limit::
+ This option is only valid for the summary command.
+ Limit the summary size (number of commits shown in total).
+ Giving 0 will disable the summary; a negative number means unlimited
+ (the default). This limit only applies to modified submodules. The
+ size is always limited to 1 for added/deleted/typechanged submodules.
+
+<path>::
+ Path to submodule(s). When specified this will restrict the command
+ to only operate on the submodules found at the specified paths.
+
+FILES
+-----
+When initializing submodules, a .gitmodules file in the top-level directory
+of the containing repository is used to find the url of each submodule.
+This file should be formatted in the same way as `$GIT_DIR/config`. The key
+to each submodule url is "submodule.$name.url". See linkgit:gitmodules[5]
+for details.
+
+
+AUTHOR
+------
+Written by Lars Hjemli <hjemli@gmail.com>
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
new file mode 100644
index 0000000000..f4cbd2f212
--- /dev/null
+++ b/Documentation/git-svn.txt
@@ -0,0 +1,630 @@
+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 Subversion and git.
+It is not to be confused with linkgit:git-svnimport[1], which is
+read-only.
+
+git-svn was originally 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. Since its inception,
+git-svn has gained the ability to track multiple branches in a manner
+similar to git-svnimport.
+
+git-svn is especially useful when it comes to tracking repositories
+not organized in the way Subversion developers recommend (trunk,
+branches, tags directories).
+
+COMMANDS
+--------
+--
+
+'init'::
+ Initializes an empty git repository with additional
+ metadata directories for git-svn. The Subversion URL
+ may be specified as a command-line argument, or as full
+ URL arguments to -T/-t/-b. Optionally, the target
+ directory to operate on can be specified as a second
+ argument. Normally this command initializes the current
+ directory.
+
+-T<trunk_subdir>;;
+--trunk=<trunk_subdir>;;
+-t<tags_subdir>;;
+--tags=<tags_subdir>;;
+-b<branches_subdir>;;
+--branches=<branches_subdir>;;
+-s;;
+--stdlayout;;
+ These are optional command-line options for init. Each of
+ these flags can point to a relative repository path
+ (--tags=project/tags') or a full url
+ (--tags=https://foo.org/project/tags). The option --stdlayout is
+ a shorthand way of setting trunk,tags,branches as the relative paths,
+ which is the Subversion default. If any of the other options are given
+ as well, they take precedence.
+--no-metadata;;
+ Set the 'noMetadata' option in the [svn-remote] config.
+--use-svm-props;;
+ Set the 'useSvmProps' option in the [svn-remote] config.
+--use-svnsync-props;;
+ Set the 'useSvnsyncProps' option in the [svn-remote] config.
+--rewrite-root=<URL>;;
+ Set the 'rewriteRoot' option in the [svn-remote] config.
+--use-log-author;;
+ When retrieving svn commits into git (as part of fetch, rebase, or
+ dcommit operations), look for the first From: or Signed-off-by: line
+ in the log message and use that as the author string.
+--add-author-from;;
+ When committing to svn from git (as part of commit or dcommit
+ operations), if the existing log message doesn't already have a
+ From: or Signed-off-by: line, append a From: line based on the
+ git commit's author string. If you use this, then --use-log-author
+ will retrieve a valid author string for all commits.
+--username=<USER>;;
+ For transports that SVN handles authentication for (http,
+ https, and plain svn), specify the username. For other
+ transports (eg svn+ssh://), you must include the username in
+ the URL, eg svn+ssh://foo@svn.bar.com/project
+--prefix=<prefix>;;
+ This allows one to specify a prefix which is prepended
+ to the names of remotes if trunk/branches/tags are
+ specified. The prefix does not automatically include a
+ trailing slash, so be sure you include one in the
+ argument if that is what you want. If --branches/-b is
+ specified, the prefix must include a trailing slash.
+ Setting a prefix is useful if you wish to track multiple
+ projects that share a common repository.
+
+'fetch'::
+ Fetch unfetched revisions from the Subversion remote we are
+ tracking. The name of the [svn-remote "..."] section in the
+ .git/config file may be specified as an optional command-line
+ argument.
+
+'clone'::
+ Runs 'init' and 'fetch'. It will automatically create a
+ directory based on the basename of the URL passed to it;
+ or if a second argument is passed; it will create a directory
+ and work within that. It accepts all arguments that the
+ 'init' and 'fetch' commands accept; with the exception of
+ '--fetch-all'. After a repository is cloned, the 'fetch'
+ command will be able to update revisions without affecting
+ the working tree; and the 'rebase' command will be able
+ to update the working tree with the latest changes.
+
+'rebase'::
+ This fetches revisions from the SVN parent of the current HEAD
+ and rebases the current (uncommitted to SVN) work against it.
+
+This works similarly to 'svn update' or 'git-pull' except that
+it preserves linear history with 'git-rebase' instead of
+'git-merge' for ease of dcommiting with git-svn.
+
+This accepts all options that 'git-svn fetch' and 'git-rebase'
+accepts. However '--fetch-all' only fetches from the current
+[svn-remote], and not all [svn-remote] definitions.
+
+Like 'git-rebase'; this requires that the working tree be clean
+and have no uncommitted changes.
+
+-l;;
+--local;;
+ Do not fetch remotely; only run 'git-rebase' against the
+ last fetched commit from the upstream SVN.
+
+'dcommit'::
+ Commit each diff from a specified head directly to the SVN
+ repository, and then rebase or reset (depending on whether or
+ not there is a diff between SVN and head). This will create
+ a revision in SVN for each commit in git.
+ It is recommended that you run git-svn fetch and rebase (not
+ pull or merge) your commits against the latest changes in the
+ SVN repository.
+ An optional command-line argument may be specified as an
+ alternative to HEAD.
+ This is advantageous over 'set-tree' (below) because it produces
+ cleaner, more linear history.
++
+--no-rebase;;
+ After committing, do not rebase or reset.
+--
+
+'log'::
+ This should make it easy to look up svn log messages when svn
+ users refer to -r/--revision numbers.
++
+The following features from `svn log' are supported:
++
+--
+--revision=<n>[:<n>];;
+ is supported, non-numeric args are not:
+ HEAD, NEXT, BASE, PREV, etc ...
+-v/--verbose;;
+ it's not completely compatible with the --verbose
+ output in svn log, but reasonably close.
+--limit=<n>;;
+ is NOT the same as --max-count, doesn't count
+ merged/excluded commits
+--incremental;;
+ supported
+--
++
+New features:
++
+--
+--show-commit;;
+ shows the git commit sha1, as well
+--oneline;;
+ our version of --pretty=oneline
+--
++
+NOTE: SVN itself only stores times in UTC and nothing else. The regular svn
+client converts the UTC time to the local time (or based on the TZ=
+environment). This command has the same behaviour.
++
+Any other arguments are passed directly to `git log'
+
+'blame'::
+ Show what revision and author last modified each line of a file. The
+ output of this mode is format-compatible with the output of
+ `svn blame' by default. Like the SVN blame command,
+ local uncommitted changes in the working copy are ignored;
+ the version of the file in the HEAD revision is annotated. Unknown
+ arguments are passed directly to git-blame.
++
+--git-format;;
+ Produce output in the same format as `git blame', but with
+ SVN revision numbers instead of git commit hashes. In this mode,
+ changes that haven't been committed to SVN (including local
+ working-copy edits) are shown as revision 0.
+
+--
+'find-rev'::
+ When given an SVN revision number of the form 'rN', returns the
+ corresponding git commit hash (this can optionally be followed by a
+ tree-ish to specify which branch should be searched). When given a
+ tree-ish, returns the corresponding SVN revision number.
+
+'set-tree'::
+ You should consider using 'dcommit' instead of this command.
+ 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.
+
+'create-ignore'::
+ Recursively finds the svn:ignore property on directories and
+ creates matching .gitignore files. The resulting files are staged to
+ be committed, but are not committed. Use -r/--revision to refer to a
+ specfic revision.
+
+'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.
+
+'commit-diff'::
+ Commits the diff of two tree-ish arguments from the
+ command-line. This command is intended for interoperability with
+ git-svnimport and does not rely on being inside an git-svn
+ init-ed repository. This command takes three arguments, (a) the
+ original tree to diff against, (b) the new tree result, (c) the
+ URL of the target Subversion repository. The final argument
+ (URL) may be omitted if you are working from a git-svn-aware
+ repository (that has been init-ed with git-svn).
+ The -r<revision> option is required for this.
+
+'info'::
+ Shows information about a file or directory similar to what
+ `svn info' provides. Does not currently support a -r/--revision
+ argument. Use the --url option to output only the value of the
+ 'URL:' field.
+
+'proplist'::
+ Lists the properties stored in the Subversion repository about a
+ given file or directory. Use -r/--revision to refer to a specific
+ Subversion revision.
+
+'propget'::
+ Gets the Subversion property given as the first argument, for a
+ file. A specific revision can be specified with -r/--revision.
+
+'show-externals'::
+ Shows the Subversion externals. Use -r/--revision to specify a
+ specific revision.
+
+--
+
+OPTIONS
+-------
+--
+
+--shared[={false|true|umask|group|all|world|everybody}]::
+--template=<template_directory>::
+ Only used with the 'init' command.
+ These are passed directly to linkgit:git-init[1].
+
+-r <ARG>::
+--revision <ARG>::
+
+Used with the 'fetch' command.
+
+This allows revision ranges for partial/cauterized history
+to be supported. $NUMBER, $NUMBER1:$NUMBER2 (numeric ranges),
+$NUMBER:HEAD, and BASE:$NUMBER are all supported.
+
+This can allow you to make partial mirrors when running fetch;
+but is generally not recommended because history will be skipped
+and lost.
+
+-::
+--stdin::
+
+Only used with the 'set-tree' 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 'dcommit', 'set-tree' and 'commit-diff' commands.
+
+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.
+
+config key: svn.rmdir
+
+-e::
+--edit::
+
+Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands.
+
+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.
+
+config key: svn.edit
+
+-l<num>::
+--find-copies-harder::
+
+Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands.
+
+They are both passed directly to git-diff-tree see
+linkgit:git-diff-tree[1] for more information.
+
+[verse]
+config key: svn.l
+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.
+
+config key: svn.authorsfile
+
+-q::
+--quiet::
+ Make git-svn less verbose.
+
+--repack[=<n>]::
+--repack-flags=<flags>::
+
+These should help keep disk usage sane for large fetches
+with many revisions.
+
+--repack takes an optional argument for the number of revisions
+to fetch before repacking. This defaults to repacking every
+1000 commits fetched if no argument is specified.
+
+--repack-flags are passed directly to linkgit:git-repack[1].
+
+[verse]
+config key: svn.repack
+config key: svn.repackflags
+
+-m::
+--merge::
+-s<strategy>::
+--strategy=<strategy>::
+
+These are only used with the 'dcommit' and 'rebase' commands.
+
+Passed directly to git-rebase when using 'dcommit' if a
+'git-reset' cannot be used (see dcommit).
+
+-n::
+--dry-run::
+
+This can be used with the 'dcommit' and 'rebase' commands.
+
+For 'dcommit', print out the series of git arguments that would show
+which diffs would be committed to SVN.
+
+For 'rebase', display the local branch associated with the upstream svn
+repository associated with the current branch and the URL of svn
+repository that will be fetched from.
+
+--
+
+ADVANCED OPTIONS
+----------------
+--
+
+-i<GIT_SVN_ID>::
+--id <GIT_SVN_ID>::
+
+This sets GIT_SVN_ID (instead of using the environment). This
+allows the user to override the default refname to fetch from
+when tracking a single URL. The 'log' and 'dcommit' commands
+no longer require this switch as an argument.
+
+-R<remote name>::
+--svn-remote <remote name>::
+ Specify the [svn-remote "<remote name>"] section to use,
+ this allows SVN multiple repositories to be tracked.
+ Default: "svn"
+
+--follow-parent::
+ This is especially helpful when we're tracking a directory
+ that has been moved around within the repository, or if we
+ started tracking a branch and never tracked the trunk it was
+ descended from. This feature is enabled by default, use
+ --no-follow-parent to disable it.
+
+config key: svn.followparent
+
+--
+CONFIG FILE-ONLY OPTIONS
+------------------------
+--
+
+svn.noMetadata::
+svn-remote.<name>.noMetadata::
+
+This gets rid of the git-svn-id: lines at the end of every commit.
+
+If you lose your .git/svn/git-svn/.rev_db file, git-svn will not
+be able to rebuild it and you won't be able to fetch again,
+either. This is fine for one-shot imports.
+
+The 'git-svn log' command will not work on repositories using
+this, either. Using this conflicts with the 'useSvmProps'
+option for (hopefully) obvious reasons.
+
+svn.useSvmProps::
+svn-remote.<name>.useSvmProps::
+
+This allows git-svn to re-map repository URLs and UUIDs from
+mirrors created using SVN::Mirror (or svk) for metadata.
+
+If an SVN revision has a property, "svm:headrev", it is likely
+that the revision was created by SVN::Mirror (also used by SVK).
+The property contains a repository UUID and a revision. We want
+to make it look like we are mirroring the original URL, so
+introduce a helper function that returns the original identity
+URL and UUID, and use it when generating metadata in commit
+messages.
+
+svn.useSvnsyncProps::
+svn-remote.<name>.useSvnsyncprops::
+ Similar to the useSvmProps option; this is for users
+ of the svnsync(1) command distributed with SVN 1.4.x and
+ later.
+
+svn-remote.<name>.rewriteRoot::
+ This allows users to create repositories from alternate
+ URLs. For example, an administrator could run git-svn on the
+ server locally (accessing via file://) but wish to distribute
+ the repository with a public http:// or svn:// URL in the
+ metadata so users of it will see the public URL.
+
+Since the noMetadata, rewriteRoot, useSvnsyncProps and useSvmProps
+options all affect the metadata generated and used by git-svn; they
+*must* be set in the configuration file before any history is imported
+and these settings should never be changed once they are set.
+
+Additionally, only one of these four options can be used per-svn-remote
+section because they affect the 'git-svn-id:' metadata line.
+
+--
+
+BASIC EXAMPLES
+--------------
+
+Tracking and contributing to the trunk of a Subversion-managed project:
+
+------------------------------------------------------------------------
+# Clone a repo (like git clone):
+ git-svn clone http://svn.foo.org/project/trunk
+# Enter the newly cloned directory:
+ cd trunk
+# You should be on master branch, double-check with git-branch
+ git branch
+# Do some work and commit locally to git:
+ git commit ...
+# Something is committed to SVN, rebase your local changes against the
+# latest changes in SVN:
+ git-svn rebase
+# Now commit your changes (that were committed previously using git) to SVN,
+# as well as automatically updating your working HEAD:
+ git-svn dcommit
+# Append svn:ignore settings to the default git exclude file:
+ git-svn show-ignore >> .git/info/exclude
+------------------------------------------------------------------------
+
+Tracking and contributing to an entire Subversion-managed project
+(complete with a trunk, tags and branches):
+
+------------------------------------------------------------------------
+# Clone a repo (like git clone):
+ git-svn clone http://svn.foo.org/project -T trunk -b branches -t tags
+# View all branches and tags you have cloned:
+ git branch -r
+# Reset your master to trunk (or any other branch, replacing 'trunk'
+# with the appropriate name):
+ git reset --hard remotes/trunk
+# You may only dcommit to one branch/tag/trunk at a time. The usage
+# of dcommit/rebase/show-ignore should be the same as above.
+------------------------------------------------------------------------
+
+The initial 'git-svn clone' can be quite time-consuming
+(especially for large Subversion repositories). If multiple
+people (or one person with multiple machines) want to use
+git-svn to interact with the same Subversion repository, you can
+do the initial 'git-svn clone' to a repository on a server and
+have each person clone that repository with 'git clone':
+
+------------------------------------------------------------------------
+# Do the initial import on a server
+ ssh server "cd /pub && git-svn clone http://svn.foo.org/project
+# Clone locally - make sure the refs/remotes/ space matches the server
+ mkdir project
+ cd project
+ git-init
+ git remote add origin server:/pub/project
+ git config --add remote.origin.fetch=+refs/remotes/*:refs/remotes/*
+ git fetch
+# Initialize git-svn locally (be sure to use the same URL and -T/-b/-t options as were used on server)
+ git-svn init http://svn.foo.org/project
+# Pull the latest changes from Subversion
+ git-svn rebase
+------------------------------------------------------------------------
+
+REBASE VS. PULL/MERGE
+---------------------
+
+Originally, git-svn recommended that the remotes/git-svn branch be
+pulled or merged from. This is because the author favored
+'git-svn set-tree B' to commit a single head rather than the
+'git-svn set-tree A..B' notation to commit multiple commits.
+
+If you use 'git-svn set-tree A..B' to commit several diffs and you do
+not have the latest remotes/git-svn merged into my-branch, you should
+use 'git-svn rebase' to update your work branch instead of 'git pull' or
+'git merge'. 'pull/merge' can cause non-linear history to be flattened
+when committing into SVN, which can lead to merge commits reversing
+previous commits in SVN.
+
+DESIGN PHILOSOPHY
+-----------------
+Merge tracking in Subversion is lacking and doing branched development
+with Subversion can be cumbersome as a result. While git-svn can track
+copy history (including branches and tags) for repositories adopting a
+standard layout, it cannot yet represent merge history that happened
+inside git back upstream to SVN users. Therefore it is advised that
+users keep history as linear as possible inside git to ease
+compatibility with SVN (see the CAVEATS section below).
+
+CAVEATS
+-------
+
+For the sake of simplicity and interoperating with a less-capable system
+(SVN), it is recommended that all git-svn users clone, fetch and dcommit
+directly from the SVN server, and avoid all git-clone/pull/merge/push
+operations between git repositories and branches. The recommended
+method of exchanging code between git branches and users is
+git-format-patch and git-am, or just dcommiting to the SVN repository.
+
+Running 'git-merge' or 'git-pull' is NOT recommended on a branch you
+plan to dcommit from. Subversion does not represent merges in any
+reasonable or useful fashion; so users using Subversion cannot see any
+merges you've made. Furthermore, if you merge or pull from a git branch
+that is a mirror of an SVN branch, dcommit may commit to the wrong
+branch.
+
+'git-clone' does not clone branches under the refs/remotes/ hierarchy or
+any git-svn metadata, or config. So repositories created and managed with
+using git-svn should use rsync(1) for cloning, if cloning is to be done
+at all.
+
+Since 'dcommit' uses rebase internally, any git branches you git-push to
+before dcommit on will require forcing an overwrite of the existing ref
+on the remote repository. This is generally considered bad practice,
+see the git-push(1) documentation for details.
+
+Do not use the --amend option of git-commit(1) on a change you've
+already dcommitted. It is considered bad practice to --amend commits
+you've already pushed to a remote repository for other users, and
+dcommit with SVN is analogous to that.
+
+BUGS
+----
+
+We ignore all SVN properties except svn:executable. Any unhandled
+properties are logged to $GIT_DIR/svn/<refname>/unhandled.log
+
+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). Committing
+renamed and copied files are fully supported if they're similar enough
+for git to detect them.
+
+CONFIGURATION
+-------------
+
+git-svn stores [svn-remote] configuration information in the
+repository .git/config file. It is similar the core git
+[remote] sections except 'fetch' keys do not accept glob
+arguments; but they are instead handled by the 'branches'
+and 'tags' keys. Since some SVN repositories are oddly
+configured with multiple projects glob expansions such those
+listed below are allowed:
+
+------------------------------------------------------------------------
+[svn-remote "project-a"]
+ url = http://server.org/svn
+ branches = branches/*/project-a:refs/remotes/project-a/branches/*
+ tags = tags/*/project-a:refs/remotes/project-a/tags/*
+ trunk = trunk/project-a:refs/remotes/project-a/trunk
+------------------------------------------------------------------------
+
+Keep in mind that the '*' (asterisk) wildcard of the local ref
+(right of the ':') *must* be the farthest right path component;
+however the remote wildcard may be anywhere as long as it's own
+independent path component (surrounded by '/' or EOL). This
+type of configuration is not automatically created by 'init' and
+should be manually entered with a text-editor or using
+linkgit:git-config[1]
+
+SEE ALSO
+--------
+linkgit:git-rebase[1]
+
+Author
+------
+Written by Eric Wong <normalperson@yhbt.net>.
+
+Documentation
+-------------
+Written by Eric Wong <normalperson@yhbt.net>.
diff --git a/Documentation/git-symbolic-ref.txt b/Documentation/git-symbolic-ref.txt
new file mode 100644
index 0000000000..3d3a059c5e
--- /dev/null
+++ b/Documentation/git-symbolic-ref.txt
@@ -0,0 +1,62 @@
+git-symbolic-ref(1)
+===================
+
+NAME
+----
+git-symbolic-ref - Read and modify symbolic refs
+
+SYNOPSIS
+--------
+'git-symbolic-ref' [-q] [-m <reason>] <name> [<ref>]
+
+DESCRIPTION
+-----------
+Given one argument, reads which branch head the given symbolic
+ref refers to and outputs its path, relative to the `.git/`
+directory. Typically you would give `HEAD` as the <name>
+argument to see on which branch your working tree is on.
+
+Give two arguments, create or update a symbolic ref <name> to
+point at the given branch <ref>.
+
+A symbolic ref is a regular file that stores a string that
+begins with `ref: refs/`. For example, your `.git/HEAD` is
+a regular file whose contents is `ref: refs/heads/master`.
+
+OPTIONS
+-------
+
+-q::
+--quiet::
+ Do not issue an error message if the <name> is not a
+ symbolic ref but a detached HEAD; instead exit with
+ non-zero status silently.
+
+-m::
+ Update the reflog for <name> with <reason>. This is valid only
+ when creating or updating a symbolic ref.
+
+NOTES
+-----
+In the past, `.git/HEAD` was a symbolic link pointing at
+`refs/heads/master`. When we wanted to switch to another branch,
+we did `ln -sf refs/heads/newbranch .git/HEAD`, and when we wanted
+to find out which branch we are on, we did `readlink .git/HEAD`.
+This was fine, and internally that is what still happens by
+default, but on platforms that do not have working symlinks,
+or that do not have the `readlink(1)` command, this was a bit
+cumbersome. On some platforms, `ln -sf` does not even work as
+advertised (horrors). Therefore symbolic links are now deprecated
+and symbolic refs are used by default.
+
+git-symbolic-ref will exit with status 0 if the contents of the
+symbolic ref were printed correctly, with status 1 if the requested
+name is not a symbolic ref, or 128 if another error occurs.
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
new file mode 100644
index 0000000000..8f40f4bf0d
--- /dev/null
+++ b/Documentation/git-tag.txt
@@ -0,0 +1,258 @@
+git-tag(1)
+==========
+
+NAME
+----
+git-tag - Create, list, delete or verify a tag object signed with GPG
+
+
+SYNOPSIS
+--------
+[verse]
+'git-tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <name> [<head>]
+'git-tag' -d <name>...
+'git-tag' [-n[<num>]] -l [<pattern>]
+'git-tag' -v <name>...
+
+DESCRIPTION
+-----------
+Adds a 'tag' reference in `.git/refs/tags/`
+
+Unless `-f` is given, the tag must not yet exist in
+`.git/refs/tags/` directory.
+
+If one of `-a`, `-s`, or `-u <key-id>` is passed, the command
+creates a 'tag' object, and requires the tag message. Unless
+`-m <msg>` or `-F <file>` is given, an editor is started for the user to type
+in the tag message.
+
+If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>`
+are absent, `-a` is implied.
+
+Otherwise just the SHA1 object name of the commit object is
+written (i.e. a lightweight tag).
+
+A GnuPG signed tag object will be created when `-s` or `-u
+<key-id>` is used. When `-u <key-id>` is not used, the
+committer identity for the current user is used to find the
+GnuPG key for signing.
+
+OPTIONS
+-------
+-a::
+ Make an unsigned, annotated tag object
+
+-s::
+ Make a GPG-signed tag, using the default e-mail address's key
+
+-u <key-id>::
+ Make a GPG-signed tag, using the given key
+
+-f::
+ Replace an existing tag with the given name (instead of failing)
+
+-d::
+ Delete existing tags with the given names.
+
+-v::
+ Verify the gpg signature of the given tag names.
+
+-n<num>::
+ <num> specifies how many lines from the annotation, if any,
+ are printed when using -l.
+ The default is not to print any annotation lines.
+ If no number is given to `-n`, only the first line is printed.
+
+-l <pattern>::
+ List tags with names that match the given pattern (or all if no pattern is given).
+ Typing "git tag" without arguments, also lists all tags.
+
+-m <msg>::
+ Use the given tag message (instead of prompting).
+ If multiple `-m` options are given, there values are
+ concatenated as separate paragraphs.
+ Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
+ is given.
+
+-F <file>::
+ Take the tag message from the given file. Use '-' to
+ read the message from the standard input.
+ Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
+ is given.
+
+CONFIGURATION
+-------------
+By default, git-tag in sign-with-default mode (-s) will use your
+committer identity (of the form "Your Name <your@email.address>") to
+find a key. If you want to use a different default key, you can specify
+it in the repository configuration as follows:
+
+-------------------------------------
+[user]
+ signingkey = <gpg-key-id>
+-------------------------------------
+
+
+DISCUSSION
+----------
+
+On Re-tagging
+~~~~~~~~~~~~~
+
+What should you do when you tag a wrong commit and you would
+want to re-tag?
+
+If you never pushed anything out, just re-tag it. Use "-f" to
+replace the old one. And you're done.
+
+But if you have pushed things out (or others could just read
+your repository directly), then others will have already seen
+the old tag. In that case you can do one of two things:
+
+. The sane thing.
+Just admit you screwed up, and use a different name. Others have
+already seen one tag-name, and if you keep the same name, you
+may be in the situation that two people both have "version X",
+but they actually have 'different' "X"'s. So just call it "X.1"
+and be done with it.
+
+. The insane thing.
+You really want to call the new version "X" too, 'even though'
+others have already seen the old one. So just use "git tag -f"
+again, as if you hadn't already published the old one.
+
+However, Git does *not* (and it should not) change tags behind
+users back. So if somebody already got the old tag, doing a "git
+pull" on your tree shouldn't just make them overwrite the old
+one.
+
+If somebody got a release tag from you, you cannot just change
+the tag for them by updating your own one. This is a big
+security issue, in that people MUST be able to trust their
+tag-names. If you really want to do the insane thing, you need
+to just fess up to it, and tell people that you messed up. You
+can do that by making a very public announcement saying:
+
+------------
+Ok, I messed up, and I pushed out an earlier version tagged as X. I
+then fixed something, and retagged the *fixed* tree as X again.
+
+If you got the wrong tag, and want the new one, please delete
+the old one and fetch the new one by doing:
+
+ git tag -d X
+ git fetch origin tag X
+
+to get my updated tag.
+
+You can test which tag you have by doing
+
+ git rev-parse X
+
+which should return 0123456789abcdef.. if you have the new version.
+
+Sorry for inconvenience.
+------------
+
+Does this seem a bit complicated? It *should* be. There is no
+way that it would be correct to just "fix" it behind peoples
+backs. People need to know that their tags might have been
+changed.
+
+
+On Automatic following
+~~~~~~~~~~~~~~~~~~~~~~
+
+If you are following somebody else's tree, you are most likely
+using tracking branches (`refs/heads/origin` in traditional
+layout, or `refs/remotes/origin/master` in the separate-remote
+layout). You usually want the tags from the other end.
+
+On the other hand, if you are fetching because you would want a
+one-shot merge from somebody else, you typically do not want to
+get tags from there. This happens more often for people near
+the toplevel but not limited to them. Mere mortals when pulling
+from each other do not necessarily want to automatically get
+private anchor point tags from the other person.
+
+You would notice "please pull" messages on the mailing list says
+repo URL and branch name alone. This is designed to be easily
+cut&pasted to "git fetch" command line:
+
+------------
+Linus, please pull from
+
+ git://git..../proj.git master
+
+to get the following updates...
+------------
+
+becomes:
+
+------------
+$ git pull git://git..../proj.git master
+------------
+
+In such a case, you do not want to automatically follow other's
+tags.
+
+One important aspect of git is it is distributed, and being
+distributed largely means there is no inherent "upstream" or
+"downstream" in the system. On the face of it, the above
+example might seem to indicate that the tag namespace is owned
+by upper echelon of people and tags only flow downwards, but
+that is not the case. It only shows that the usage pattern
+determines who are interested in whose tags.
+
+A one-shot pull is a sign that a commit history is now crossing
+the boundary between one circle of people (e.g. "people who are
+primarily interested in networking part of the kernel") who may
+have their own set of tags (e.g. "this is the third release
+candidate from the networking group to be proposed for general
+consumption with 2.6.21 release") to another circle of people
+(e.g. "people who integrate various subsystem improvements").
+The latter are usually not interested in the detailed tags used
+internally in the former group (that is what "internal" means).
+That is why it is desirable not to follow tags automatically in
+this case.
+
+It may well be that among networking people, they may want to
+exchange the tags internal to their group, but in that workflow
+they are most likely tracking with each other's progress by
+having tracking branches. Again, the heuristic to automatically
+follow such tags is a good thing.
+
+
+On Backdating Tags
+~~~~~~~~~~~~~~~~~~
+
+If you have imported some changes from another VCS and would like
+to add tags for major releases of your work, it is useful to be able
+to specify the date to embed inside of the tag object. The data in
+the tag object affects, for example, the ordering of tags in the
+gitweb interface.
+
+To set the date used in future tag objects, set the environment
+variable GIT_COMMITTER_DATE to one or more of the date and time. The
+date and time can be specified in a number of ways; the most common
+is "YYYY-MM-DD HH:MM".
+
+An example follows.
+
+------------
+$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1
+------------
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>,
+Junio C Hamano <junkio@cox.net> and Chris Wright <chrisw@osdl.org>.
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt
new file mode 100644
index 0000000000..74ed06525e
--- /dev/null
+++ b/Documentation/git-tar-tree.txt
@@ -0,0 +1,89 @@
+git-tar-tree(1)
+===============
+
+NAME
+----
+git-tar-tree - Create a tar archive of the files in the named tree object
+
+
+SYNOPSIS
+--------
+'git-tar-tree' [--remote=<repo>] <tree-ish> [ <base> ]
+
+DESCRIPTION
+-----------
+THIS COMMAND IS DEPRECATED. Use `git-archive` with `--format=tar`
+option instead (and move the <base> argument to `--prefix=base/`).
+
+Creates a tar archive containing the tree structure for the named tree.
+When <base> is specified it is added as a leading path to the files in the
+generated tar archive.
+
+git-tar-tree behaves differently when given a tree ID versus when given
+a commit ID or tag ID. In the first case the current time is used as
+modification time of each file in the archive. In the latter case the
+commit time as recorded in the referenced commit object is used instead.
+Additionally the commit ID is stored in a global extended pax header.
+It can be extracted using git-get-tar-commit-id.
+
+OPTIONS
+-------
+
+<tree-ish>::
+ The tree or commit to produce tar archive for. If it is
+ the object name of a commit object.
+
+<base>::
+ Leading path to the files in the resulting tar archive.
+
+--remote=<repo>::
+ Instead of making a tar archive from local repository,
+ retrieve a tar archive from a remote repository.
+
+CONFIGURATION
+-------------
+
+tar.umask::
+ This variable can be used to restrict the permission bits of
+ tar archive entries. The default is 0002, which turns off the
+ world write bit. The special value "user" indicates that the
+ archiving user's umask will be used instead. See umask(2) for
+ details.
+
+EXAMPLES
+--------
+git tar-tree HEAD junk | (cd /var/tmp/ && tar xf -)::
+
+ Create a tar archive that contains the contents of the
+ latest commit on the current branch, and extracts it in
+ `/var/tmp/junk` directory.
+
+git tar-tree v1.4.0 git-1.4.0 | gzip >git-1.4.0.tar.gz::
+
+ Create a tarball for v1.4.0 release.
+
+git tar-tree v1.4.0{caret}\{tree\} git-1.4.0 | gzip >git-1.4.0.tar.gz::
+
+ Create a tarball for v1.4.0 release, but without a
+ global extended pax header.
+
+git tar-tree --remote=example.com:git.git v1.4.0 >git-1.4.0.tar::
+
+ Get a tarball v1.4.0 from example.com.
+
+git tar-tree HEAD:Documentation/ git-docs > git-1.4.0-docs.tar::
+
+ Put everything in the current head's Documentation/ directory
+ into 'git-1.4.0-docs.tar', with the prefix 'git-docs/'.
+
+Author
+------
+Written by Rene Scharfe.
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt
new file mode 100644
index 0000000000..a96403cb8c
--- /dev/null
+++ b/Documentation/git-tools.txt
@@ -0,0 +1,118 @@
+A short git tools survey
+========================
+
+
+Introduction
+------------
+
+Apart from git contrib/ area there are some others third-party tools
+you may want to look.
+
+This document presents a brief summary of each tool and the corresponding
+link.
+
+
+Alternative/Augmentative Porcelains
+-----------------------------------
+
+ - *Cogito* (http://www.kernel.org/pub/software/scm/cogito/)
+
+ Cogito is a version control system layered on top of the git tree history
+ storage system. It aims at seamless user interface and ease of use,
+ providing generally smoother user experience than the "raw" Core GIT
+ itself and indeed many other version control systems.
+
+ Cogito is no longer maintained as most of its functionality
+ is now in core GIT.
+
+
+ - *pg* (http://www.spearce.org/category/projects/scm/pg/)
+
+ pg is a shell script wrapper around GIT to help the user manage a set of
+ patches to files. pg is somewhat like quilt or StGIT, but it does have a
+ slightly different feature set.
+
+
+ - *StGit* (http://www.procode.org/stgit/)
+
+ Stacked GIT provides a quilt-like patch management functionality in the
+ GIT environment. You can easily manage your patches in the scope of GIT
+ until they get merged upstream.
+
+
+History Viewers
+---------------
+
+ - *gitk* (shipped with git-core)
+
+ gitk is a simple Tk GUI for browsing history of GIT repositories easily.
+
+
+ - *gitview* (contrib/)
+
+ gitview is a GTK based repository browser for git
+
+
+ - *gitweb* (shipped with git-core)
+
+ GITweb provides full-fledged web interface for GIT repositories.
+
+
+ - *qgit* (http://digilander.libero.it/mcostalba/)
+
+ QGit is a git/StGIT GUI viewer built on Qt/C++. QGit could be used
+ to browse history and directory tree, view annotated files, commit
+ changes cherry picking single files or applying patches.
+ Currently it is the fastest and most feature rich among the git
+ viewers and commit tools.
+
+ - *tig* (http://jonas.nitro.dk/tig/)
+
+ tig by Jonas Fonseca is a simple git repository browser
+ written using ncurses. Basically, it just acts as a front-end
+ for git-log and git-show/git-diff. Additionally, you can also
+ use it as a pager for git commands.
+
+
+Foreign SCM interface
+---------------------
+
+ - *git-svn* (shipped with git-core)
+
+ git-svn is a simple conduit for changesets between a single Subversion
+ branch and git.
+
+
+ - *quilt2git / git2quilt* (http://home-tj.org/wiki/index.php/Misc)
+
+ These utilities convert patch series in a quilt repository and commit
+ series in git back and forth.
+
+
+ - *hg-to-git* (contrib/)
+
+ hg-to-git converts a Mercurial repository into a git one, and
+ preserves the full branch history in the process. hg-to-git can
+ also be used in an incremental way to keep the git repository
+ in sync with the master Mercurial repository.
+
+
+Others
+------
+
+ - *(h)gct* (http://www.cyd.liu.se/users/~freku045/gct/)
+
+ Commit Tool or (h)gct is a GUI enabled commit tool for git and
+ Mercurial (hg). It allows the user to view diffs, select which files
+ to committed (or ignored / reverted) write commit messages and
+ perform the commit itself.
+
+ - *git.el* (contrib/)
+
+ This is an Emacs interface for git. The user interface is modeled on
+ pcl-cvs. It has been developed on Emacs 21 and will probably need some
+ tweaking to work on XEmacs.
+
+
+http://git.or.cz/gitwiki/InterfacesFrontendsAndTools has more
+comprehensive list.
diff --git a/Documentation/git-unpack-file.txt b/Documentation/git-unpack-file.txt
new file mode 100644
index 0000000000..d0552b2c74
--- /dev/null
+++ b/Documentation/git-unpack-file.txt
@@ -0,0 +1,35 @@
+git-unpack-file(1)
+==================
+
+NAME
+----
+git-unpack-file - Creates a temporary file with a blob's contents
+
+
+
+SYNOPSIS
+--------
+'git-unpack-file' <blob>
+
+DESCRIPTION
+-----------
+Creates a file holding the contents of the blob specified by sha1. It
+returns the name of the temporary file in the following format:
+ .merge_file_XXXXX
+
+OPTIONS
+-------
+<blob>::
+ Must be a blob id
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt
new file mode 100644
index 0000000000..b9c4279a88
--- /dev/null
+++ b/Documentation/git-unpack-objects.txt
@@ -0,0 +1,57 @@
+git-unpack-objects(1)
+=====================
+
+NAME
+----
+git-unpack-objects - Unpack objects from a packed archive
+
+
+SYNOPSIS
+--------
+'git-unpack-objects' [-n] [-q] [-r] [--strict] <pack-file
+
+
+DESCRIPTION
+-----------
+Read a packed archive (.pack) from the standard input, expanding
+the objects contained within and writing them into the repository in
+"loose" (one object per file) format.
+
+Objects that already exist in the repository will *not* be unpacked
+from the pack-file. Therefore, nothing will be unpacked if you use
+this command on a pack-file that exists within the target repository.
+
+Please see the `git-repack` documentation for options to generate
+new packs and replace existing ones.
+
+OPTIONS
+-------
+-n::
+ Dry run. Check the pack file without actually unpacking
+ the objects.
+
+-q::
+ The command usually shows percentage progress. This
+ flag suppresses it.
+
+-r::
+ When unpacking a corrupt packfile, the command dies at
+ the first corruption. This flag tells it to keep going
+ and make the best effort to recover as many objects as
+ possible.
+
+--strict::
+ Don't write objects with broken content or links.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+-------------
+Documentation by Junio C Hamano
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
new file mode 100644
index 0000000000..bbb0a6ad57
--- /dev/null
+++ b/Documentation/git-update-index.txt
@@ -0,0 +1,333 @@
+git-update-index(1)
+===================
+
+NAME
+----
+git-update-index - Register file contents in the working tree to the index
+
+
+SYNOPSIS
+--------
+[verse]
+'git-update-index'
+ [--add] [--remove | --force-remove] [--replace]
+ [--refresh] [-q] [--unmerged] [--ignore-missing]
+ [--cacheinfo <mode> <object> <file>]\*
+ [--chmod=(+|-)x]
+ [--assume-unchanged | --no-assume-unchanged]
+ [--ignore-submodules]
+ [--really-refresh] [--unresolve] [--again | -g]
+ [--info-only] [--index-info]
+ [-z] [--stdin]
+ [--verbose]
+ [--] [<file>]\*
+
+DESCRIPTION
+-----------
+Modifies the index or directory cache. Each file mentioned is updated
+into the index and any 'unmerged' or 'needs updating' state is
+cleared.
+
+See also linkgit:git-add[1] for a more user-friendly way to do some of
+the most common operations on the index.
+
+The way "git-update-index" handles files it is told about can be modified
+using the various options:
+
+OPTIONS
+-------
+--add::
+ If a specified file isn't in the index already then it's
+ added.
+ Default behaviour is to ignore new files.
+
+--remove::
+ If a specified file is in the index but is missing then it's
+ removed.
+ Default behavior is to ignore removed file.
+
+--refresh::
+ Looks at the current index and checks to see if merges or
+ updates are needed by checking stat() information.
+
+-q::
+ Quiet. If --refresh finds that the index needs an update, the
+ default behavior is to error out. This option makes
+ git-update-index continue anyway.
+
+--ignore-submodules:
+ Do not try to update submodules. This option is only respected
+ when passed before --refresh.
+
+--unmerged::
+ If --refresh finds unmerged changes in the index, the default
+ behavior is to error out. This option makes git-update-index
+ continue anyway.
+
+--ignore-missing::
+ Ignores missing files during a --refresh
+
+--cacheinfo <mode> <object> <path>::
+ Directly insert the specified info into the index.
+
+--index-info::
+ Read index information from stdin.
+
+--chmod=(+|-)x::
+ Set the execute permissions on the updated files.
+
+--assume-unchanged::
+--no-assume-unchanged::
+ When these flags are specified, the object name recorded
+ for the paths are not updated. Instead, these options
+ sets and unsets the "assume unchanged" bit for the
+ paths. When the "assume unchanged" bit is on, git stops
+ checking the working tree files for possible
+ modifications, so you need to manually unset the bit to
+ tell git when you change the working tree file. This is
+ sometimes helpful when working with a big project on a
+ filesystem that has very slow lstat(2) system call
+ (e.g. cifs).
+
+-g::
+--again::
+ Runs `git-update-index` itself on the paths whose index
+ entries are different from those from the `HEAD` commit.
+
+--unresolve::
+ Restores the 'unmerged' or 'needs updating' state of a
+ file during a merge if it was cleared by accident.
+
+--info-only::
+ Do not create objects in the object database for all
+ <file> arguments that follow this flag; just insert
+ their object IDs into the index.
+
+--force-remove::
+ Remove the file from the index even when the working directory
+ still has such a file. (Implies --remove.)
+
+--replace::
+ By default, when a file `path` exists in the index,
+ git-update-index refuses an attempt to add `path/file`.
+ Similarly if a file `path/file` exists, a file `path`
+ cannot be added. With --replace flag, existing entries
+ that conflicts with the entry being added are
+ automatically removed with warning messages.
+
+--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.
+
+--verbose::
+ Report what is being added and removed from index.
+
+-z::
+ Only meaningful with `--stdin`; paths are separated with
+ NUL character instead of LF.
+
+\--::
+ Do not interpret any more arguments as options.
+
+<file>::
+ Files to act on.
+ Note that files beginning with '.' are discarded. This includes
+ `./file` and `dir/./file`. If you don't want this, then use
+ cleaner names.
+ The same applies to directories ending '/' and paths with '//'
+
+Using --refresh
+---------------
+'--refresh' does not calculate a new sha1 file or bring the index
+up-to-date for mode/content changes. But what it *does* do is to
+"re-match" the stat information of a file with the index, so that you
+can refresh the index for a file that hasn't been changed but where
+the stat entry is out of date.
+
+For example, you'd want to do this after doing a "git-read-tree", to link
+up the stat index details with the proper files.
+
+Using --cacheinfo or --info-only
+--------------------------------
+'--cacheinfo' is used to register a file that is not in the
+current working directory. This is useful for minimum-checkout
+merging.
+
+To pretend you have a file with mode and sha1 at path, say:
+
+----------------
+$ git-update-index --cacheinfo mode sha1 path
+----------------
+
+'--info-only' is used to register files without placing them in the object
+database. This is useful for status-only repositories.
+
+Both '--cacheinfo' and '--info-only' behave similarly: the index is updated
+but the object database isn't. '--cacheinfo' is useful when the object is
+in the database but the file isn't available locally. '--info-only' is
+useful when the file is available, but you do not wish to update the
+object database.
+
+
+Using --index-info
+------------------
+
+`--index-info` is a more powerful mechanism that lets you feed
+multiple entry definitions from the standard input, and designed
+specifically for scripts. It can take inputs of three formats:
+
+ . mode SP sha1 TAB path
++
+The first format is what "git-apply --index-info"
+reports, and used to reconstruct a partial tree
+that is used for phony merge base tree when falling
+back on 3-way merge.
+
+ . mode SP type SP sha1 TAB path
++
+The second format is to stuff git-ls-tree output
+into the index file.
+
+ . mode SP sha1 SP stage TAB path
++
+This format is to put higher order stages into the
+index file and matches git-ls-files --stage output.
+
+To place a higher stage entry to the index, the path should
+first be removed by feeding a mode=0 entry for the path, and
+then feeding necessary input lines in the third format.
+
+For example, starting with this index:
+
+------------
+$ git ls-files -s
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0 frotz
+------------
+
+you can feed the following input to `--index-info`:
+
+------------
+$ git update-index --index-info
+0 0000000000000000000000000000000000000000 frotz
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz
+100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz
+------------
+
+The first line of the input feeds 0 as the mode to remove the
+path; the SHA1 does not matter as long as it is well formatted.
+Then the second and third line feeds stage 1 and stage 2 entries
+for that path. After the above, we would end up with this:
+
+------------
+$ git ls-files -s
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz
+100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz
+------------
+
+
+Using ``assume unchanged'' bit
+------------------------------
+
+Many operations in git depend on your filesystem to have an
+efficient `lstat(2)` implementation, so that `st_mtime`
+information for working tree files can be cheaply checked to see
+if the file contents have changed from the version recorded in
+the index file. Unfortunately, some filesystems have
+inefficient `lstat(2)`. If your filesystem is one of them, you
+can set "assume unchanged" bit to paths you have not changed to
+cause git not to do this check. Note that setting this bit on a
+path does not mean git will check the contents of the file to
+see if it has changed -- it makes git to omit any checking and
+assume it has *not* changed. When you make changes to working
+tree files, you have to explicitly tell git about it by dropping
+"assume unchanged" bit, either before or after you modify them.
+
+In order to set "assume unchanged" bit, use `--assume-unchanged`
+option. To unset, use `--no-assume-unchanged`.
+
+The command looks at `core.ignorestat` configuration variable. When
+this is true, paths updated with `git-update-index paths...` and
+paths updated with other git commands that update both index and
+working tree (e.g. `git-apply --index`, `git-checkout-index -u`,
+and `git-read-tree -u`) are automatically marked as "assume
+unchanged". Note that "assume unchanged" bit is *not* set if
+`git-update-index --refresh` finds the working tree file matches
+the index (use `git-update-index --really-refresh` if you want
+to mark them as "assume unchanged").
+
+
+Examples
+--------
+To update and refresh only the files already checked out:
+
+----------------
+$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
+----------------
+
+On an inefficient filesystem with `core.ignorestat` set::
++
+------------
+$ git update-index --really-refresh <1>
+$ git update-index --no-assume-unchanged foo.c <2>
+$ git diff --name-only <3>
+$ edit foo.c
+$ git diff --name-only <4>
+M foo.c
+$ git update-index foo.c <5>
+$ git diff --name-only <6>
+$ edit foo.c
+$ git diff --name-only <7>
+$ git update-index --no-assume-unchanged foo.c <8>
+$ git diff --name-only <9>
+M foo.c
+------------
++
+<1> forces lstat(2) to set "assume unchanged" bits for paths that match index.
+<2> mark the path to be edited.
+<3> this does lstat(2) and finds index matches the path.
+<4> this does lstat(2) and finds index does *not* match the path.
+<5> registering the new version to index sets "assume unchanged" bit.
+<6> and it is assumed unchanged.
+<7> even after you edit it.
+<8> you can tell about the change after the fact.
+<9> now it checks with lstat(2) and finds it has been changed.
+
+
+Configuration
+-------------
+
+The command honors `core.filemode` configuration variable. If
+your repository is on an filesystem whose executable bits are
+unreliable, this should be set to 'false' (see linkgit:git-config[1]).
+This causes the command to ignore differences in file modes recorded
+in the index and the file mode on the filesystem if they differ only on
+executable bit. On such an unfortunate filesystem, you may
+need to use `git-update-index --chmod=`.
+
+Quite similarly, if `core.symlinks` configuration variable is set
+to 'false' (see linkgit:git-config[1]), symbolic links are checked out
+as plain files, and this command does not modify a recorded file mode
+from symbolic link to regular file.
+
+The command looks at `core.ignorestat` configuration variable. See
+'Using "assume unchanged" bit' section above.
+
+
+SEE ALSO
+--------
+linkgit:git-config[1],
+linkgit:git-add[1]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
new file mode 100644
index 0000000000..7f7e3d197b
--- /dev/null
+++ b/Documentation/git-update-ref.txt
@@ -0,0 +1,93 @@
+git-update-ref(1)
+=================
+
+NAME
+----
+git-update-ref - Update the object name stored in a ref safely
+
+SYNOPSIS
+--------
+'git-update-ref' [-m <reason>] (-d <ref> <oldvalue> | [--no-deref] <ref> <newvalue> [<oldvalue>])
+
+DESCRIPTION
+-----------
+Given two arguments, stores the <newvalue> in the <ref>, possibly
+dereferencing the symbolic refs. E.g. `git-update-ref HEAD
+<newvalue>` updates the current branch head to the new object.
+
+Given three arguments, stores the <newvalue> in the <ref>,
+possibly dereferencing the symbolic refs, after verifying that
+the current value of the <ref> matches <oldvalue>.
+E.g. `git-update-ref refs/heads/master <newvalue> <oldvalue>`
+updates the master branch head to <newvalue> only if its current
+value is <oldvalue>. You can specify 40 "0" or an empty string
+as <oldvalue> to make sure that the ref you are creating does
+not exist.
+
+It also allows a "ref" file to be a symbolic pointer to another
+ref file by starting with the four-byte header sequence of
+"ref:".
+
+More importantly, it allows the update of a ref file to follow
+these symbolic pointers, whether they are symlinks or these
+"regular file symbolic refs". It follows *real* symlinks only
+if they start with "refs/": otherwise it will just try to read
+them and update them as a regular file (i.e. it will allow the
+filesystem to follow them, but will overwrite such a symlink to
+somewhere else with a regular filename).
+
+If --no-deref is given, <ref> itself is overwritten, rather than
+the result of following the symbolic pointers.
+
+In general, using
+
+ git-update-ref HEAD "$head"
+
+should be a _lot_ safer than doing
+
+ echo "$head" > "$GIT_DIR/HEAD"
+
+both from a symlink following standpoint *and* an error checking
+standpoint. The "refs/" rule for symlinks means that symlinks
+that point to "outside" the tree are safe: they'll be followed
+for reading but not for writing (so we'll never write through a
+ref symlink to some other tree, if you have copied a whole
+archive by creating a symlink tree).
+
+With `-d` flag, it deletes the named <ref> after verifying it
+still contains <oldvalue>.
+
+
+Logging Updates
+---------------
+If config parameter "core.logAllRefUpdates" is true or the file
+"$GIT_DIR/logs/<ref>" exists then `git-update-ref` will append
+a line to the log file "$GIT_DIR/logs/<ref>" (dereferencing all
+symbolic refs before creating the log name) describing the change
+in ref value. Log lines are formatted as:
+
+ . oldsha1 SP newsha1 SP committer LF
++
+Where "oldsha1" is the 40 character hexadecimal value previously
+stored in <ref>, "newsha1" is the 40 character hexadecimal value of
+<newvalue> and "committer" is the committer's name, email address
+and date in the standard GIT committer ident format.
+
+Optionally with -m:
+
+ . oldsha1 SP newsha1 SP committer TAB message LF
++
+Where all fields are as described above and "message" is the
+value supplied to the -m option.
+
+An update will fail (without changing <ref>) if the current user is
+unable to create a new log file, append to the existing log file
+or does not have committer information available.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-update-server-info.txt b/Documentation/git-update-server-info.txt
new file mode 100644
index 0000000000..d21be41d06
--- /dev/null
+++ b/Documentation/git-update-server-info.txt
@@ -0,0 +1,58 @@
+git-update-server-info(1)
+=========================
+
+NAME
+----
+git-update-server-info - Update auxiliary info file to help dumb servers
+
+
+SYNOPSIS
+--------
+'git-update-server-info' [--force]
+
+DESCRIPTION
+-----------
+A dumb server that does not do on-the-fly pack generations must
+have some auxiliary information files in $GIT_DIR/info and
+$GIT_OBJECT_DIRECTORY/info directories to help clients discover
+what references and packs the server has. This command
+generates such auxiliary files.
+
+
+OPTIONS
+-------
+
+-f::
+--force::
+ Update the info files from scratch.
+
+
+OUTPUT
+------
+
+Currently the command updates the following files. Please see
+linkgit:gitrepository-layout[5][repository-layout] for description of
+what they are for:
+
+* objects/info/packs
+
+* info/refs
+
+
+BUGS
+----
+When you remove an existing ref, the command fails to update
+info/refs file unless `--force` flag is given.
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-upload-archive.txt b/Documentation/git-upload-archive.txt
new file mode 100644
index 0000000000..e49f68f68e
--- /dev/null
+++ b/Documentation/git-upload-archive.txt
@@ -0,0 +1,37 @@
+git-upload-archive(1)
+====================
+
+NAME
+----
+git-upload-archive - Send archive back to git-archive
+
+
+SYNOPSIS
+--------
+'git-upload-archive' <directory>
+
+DESCRIPTION
+-----------
+Invoked by 'git-archive --remote' and sends a generated archive to the
+other end over the git protocol.
+
+This command is usually not invoked directly by the end user. The UI
+for the protocol is on the 'git-archive' side, and the program pair
+is meant to be used to get an archive from a remote repository.
+
+OPTIONS
+-------
+<directory>::
+ The repository to get a tar archive from.
+
+Author
+------
+Written by Franck Bui-Huu.
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt
new file mode 100644
index 0000000000..bac465e13f
--- /dev/null
+++ b/Documentation/git-upload-pack.txt
@@ -0,0 +1,46 @@
+git-upload-pack(1)
+==================
+
+NAME
+----
+git-upload-pack - Send objects packed back to git-fetch-pack
+
+
+SYNOPSIS
+--------
+'git-upload-pack' [--strict] [--timeout=<n>] <directory>
+
+DESCRIPTION
+-----------
+Invoked by 'git-fetch-pack', learns what
+objects the other side is missing, and sends them after packing.
+
+This command is usually not invoked directly by the end user.
+The UI for the protocol is on the 'git-fetch-pack' side, and the
+program pair is meant to be used to pull updates from a remote
+repository. For push operations, see 'git-send-pack'.
+
+
+OPTIONS
+-------
+
+--strict::
+ Do not try <directory>/.git/ if <directory> is no git directory.
+
+--timeout=<n>::
+ Interrupt transfer after <n> seconds of inactivity.
+
+<directory>::
+ The repository to sync from.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt
new file mode 100644
index 0000000000..67e8e1f93a
--- /dev/null
+++ b/Documentation/git-var.txt
@@ -0,0 +1,64 @@
+git-var(1)
+==========
+
+NAME
+----
+git-var - Show a git logical variable
+
+
+SYNOPSIS
+--------
+'git-var' [ -l | <variable> ]
+
+DESCRIPTION
+-----------
+Prints a git logical variable.
+
+OPTIONS
+-------
+-l::
+ Cause the logical variables to be listed. In addition, all the
+ variables of the git configuration file .git/config are listed
+ as well. (However, the configuration variables listing functionality
+ is deprecated in favor of `git-config -l`.)
+
+EXAMPLE
+--------
+ $ git-var GIT_AUTHOR_IDENT
+ Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600
+
+
+VARIABLES
+----------
+GIT_AUTHOR_IDENT::
+ The author of a piece of code.
+
+GIT_COMMITTER_IDENT::
+ The person who put a piece of code into git.
+
+Diagnostics
+-----------
+You don't exist. Go away!::
+ The passwd(5) gecos field couldn't be read
+Your parents must have hated you!::
+ The password(5) gecos field is longer than a giant static buffer.
+Your sysadmin must hate you!::
+ The password(5) name field is longer than a giant static buffer.
+
+SEE ALSO
+--------
+linkgit:git-commit-tree[1]
+linkgit:git-tag[1]
+linkgit:git-config[1]
+
+Author
+------
+Written by Eric Biederman <ebiederm@xmission.com>
+
+Documentation
+--------------
+Documentation by Eric Biederman and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt
new file mode 100644
index 0000000000..478f236996
--- /dev/null
+++ b/Documentation/git-verify-pack.txt
@@ -0,0 +1,53 @@
+git-verify-pack(1)
+==================
+
+NAME
+----
+git-verify-pack - Validate packed git archive files
+
+
+SYNOPSIS
+--------
+'git-verify-pack' [-v] [--] <pack>.idx ...
+
+
+DESCRIPTION
+-----------
+Reads given idx file for packed git archive created with
+git-pack-objects command and verifies idx file and the
+corresponding pack file.
+
+OPTIONS
+-------
+<pack>.idx ...::
+ The idx files to verify.
+
+-v::
+ After verifying the pack, show list of objects contained
+ in the pack.
+\--::
+ Do not interpret any more arguments as options.
+
+OUTPUT FORMAT
+-------------
+When specifying the -v option the format used is:
+
+ SHA1 type size size-in-pack-file offset-in-packfile
+
+for objects that are not deltified in the pack, and
+
+ SHA1 type size size-in-packfile offset-in-packfile depth base-SHA1
+
+for objects that are deltified.
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-verify-tag.txt b/Documentation/git-verify-tag.txt
new file mode 100644
index 0000000000..dffba8906a
--- /dev/null
+++ b/Documentation/git-verify-tag.txt
@@ -0,0 +1,31 @@
+git-verify-tag(1)
+=================
+
+NAME
+----
+git-verify-tag - Check the GPG signature of tags
+
+SYNOPSIS
+--------
+'git-verify-tag' <tag>...
+
+DESCRIPTION
+-----------
+Validates the gpg signature created by git-tag.
+
+OPTIONS
+-------
+<tag>::
+ SHA1 identifier of a git tag object.
+
+Author
+------
+Written by Jan Harkes <jaharkes@cs.cmu.edu> and Eric W. Biederman <ebiederm@xmission.com>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-web--browse.txt b/Documentation/git-web--browse.txt
new file mode 100644
index 0000000000..e80a7c1cc4
--- /dev/null
+++ b/Documentation/git-web--browse.txt
@@ -0,0 +1,124 @@
+git-web--browse(1)
+==================
+
+NAME
+----
+git-web--browse - git helper script to launch a web browser
+
+SYNOPSIS
+--------
+'git-web--browse' [OPTIONS] URL/FILE ...
+
+DESCRIPTION
+-----------
+
+This script tries, as much as possible, to display the URLs and FILEs
+that are passed as arguments, as HTML pages in new tabs on an already
+opened web browser.
+
+The following browsers (or commands) are currently supported:
+
+* firefox (this is the default under X Window when not using KDE)
+* iceweasel
+* konqueror (this is the default under KDE, see 'Note about konqueror' below)
+* w3m (this is the default outside graphical environments)
+* links
+* lynx
+* dillo
+* open (this is the default under Mac OS X GUI)
+
+Custom commands may also be specified.
+
+OPTIONS
+-------
+-b BROWSER::
+--browser=BROWSER::
+ Use the specified BROWSER. It must be in the list of supported
+ browsers.
+
+-t BROWSER::
+--tool=BROWSER::
+ Same as above.
+
+-c CONF.VAR::
+--config=CONF.VAR::
+ CONF.VAR is looked up in the git config files. If it's set,
+ then its value specify the browser that should be used.
+
+CONFIGURATION VARIABLES
+-----------------------
+
+CONF.VAR (from -c option) and web.browser
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The web browser can be specified using a configuration variable passed
+with the -c (or --config) command line option, or the 'web.browser'
+configuration variable if the former is not used.
+
+browser.<tool>.path
+~~~~~~~~~~~~~~~~~~~
+
+You can explicitly provide a full path to your preferred browser by
+setting the configuration variable 'browser.<tool>.path'. For example,
+you can configure the absolute path to firefox by setting
+'browser.firefox.path'. Otherwise, 'git-web--browse' assumes the tool
+is available in PATH.
+
+browser.<tool>.cmd
+~~~~~~~~~~~~~~~~~~
+
+When the browser, specified by options or configuration variables, is
+not among the supported ones, then the corresponding
+'browser.<tool>.cmd' configuration variable will be looked up. If this
+variable exists then "git web--browse" will treat the specified tool
+as a custom command and will use a shell eval to run the command with
+the URLs passed as arguments.
+
+Note about konqueror
+--------------------
+
+When 'konqueror' is specified by the a command line option or a
+configuration variable, we launch 'kfmclient' to try to open the HTML
+man page on an already opened konqueror in a new tab if possible.
+
+For consistency, we also try such a trick if 'browser.konqueror.path' is
+set to something like 'A_PATH_TO/konqueror'. That means we will try to
+launch 'A_PATH_TO/kfmclient' instead.
+
+If you really want to use 'konqueror', then you can use something like
+the following:
+
+------------------------------------------------
+ [web]
+ browser = konq
+
+ [browser "konq"]
+ cmd = A_PATH_TO/konqueror
+------------------------------------------------
+
+Note about git config --global
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Note that these configuration variables should probably be set using
+the '--global' flag, for example like this:
+
+------------------------------------------------
+$ git config --global web.browser firefox
+------------------------------------------------
+
+as they are probably more user specific than repository specific.
+See linkgit:git-config[1] for more information about this.
+
+Author
+------
+Written by Christian Couder <chriscool@tuxfamily.org> and the git-list
+<git@vger.kernel.org>, based on git-mergetool by Theodore Y. Ts'o.
+
+Documentation
+-------------
+Documentation by Christian Couder <chriscool@tuxfamily.org> and the
+git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt
new file mode 100644
index 0000000000..f5d39c7870
--- /dev/null
+++ b/Documentation/git-whatchanged.txt
@@ -0,0 +1,79 @@
+git-whatchanged(1)
+==================
+
+NAME
+----
+git-whatchanged - Show logs with difference each commit introduces
+
+
+SYNOPSIS
+--------
+'git-whatchanged' <option>...
+
+DESCRIPTION
+-----------
+Shows commit logs and diff output each commit introduces. The
+command internally invokes 'git-rev-list' piped to
+'git-diff-tree', and takes command line options for both of
+these commands.
+
+This manual page describes only the most frequently used options.
+
+
+OPTIONS
+-------
+-p::
+ Show textual diffs, instead of the git internal diff
+ output format that is useful only to tell the changed
+ paths and their nature of changes.
+
+-<n>::
+ Limit output to <n> commits.
+
+<since>..<until>::
+ Limit output to between the two named commits (bottom
+ exclusive, top inclusive).
+
+-r::
+ Show git internal diff output, but for the whole tree,
+ not just the top level.
+
+-m::
+ By default, differences for merge commits are not shown.
+ With this flag, show differences to that commit from all
+ of its parents.
++
+However, it is not very useful in general, although it
+*is* useful on a file-by-file basis.
+
+include::pretty-options.txt[]
+
+include::pretty-formats.txt[]
+
+Examples
+--------
+git-whatchanged -p v2.6.12.. include/scsi drivers/scsi::
+
+ Show as patches the commits since version 'v2.6.12' that changed
+ any file in the include/scsi or drivers/scsi subdirectories
+
+git-whatchanged --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'
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and
+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 linkgit:git[1] suite
diff --git a/Documentation/git-write-tree.txt b/Documentation/git-write-tree.txt
new file mode 100644
index 0000000000..8744f6535d
--- /dev/null
+++ b/Documentation/git-write-tree.txt
@@ -0,0 +1,49 @@
+git-write-tree(1)
+=================
+
+NAME
+----
+git-write-tree - Create a tree object from the current index
+
+
+SYNOPSIS
+--------
+'git-write-tree' [--missing-ok] [--prefix=<prefix>/]
+
+DESCRIPTION
+-----------
+Creates a tree object using the current index.
+
+The index must be in a fully merged state.
+
+Conceptually, `git-write-tree` sync()s the current index contents
+into a set of tree files.
+In order to have that match what is actually in your directory right
+now, you need to have done a `git-update-index` phase before you did the
+`git-write-tree`.
+
+
+OPTIONS
+-------
+--missing-ok::
+ Normally `git-write-tree` ensures that the objects referenced by the
+ directory exist in the object database. This option disables this
+ check.
+
+--prefix=<prefix>/::
+ Writes a tree object that represents a subdirectory
+ `<prefix>`. This can be used to write the tree object
+ for a subproject that is in the named subdirectory.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/git.txt b/Documentation/git.txt
new file mode 100644
index 0000000000..ee96774009
--- /dev/null
+++ b/Documentation/git.txt
@@ -0,0 +1,594 @@
+git(1)
+======
+
+NAME
+----
+git - the stupid content tracker
+
+
+SYNOPSIS
+--------
+[verse]
+'git' [--version] [--exec-path[=GIT_EXEC_PATH]]
+ [-p|--paginate|--no-pager]
+ [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]
+ [--help] COMMAND [ARGS]
+
+DESCRIPTION
+-----------
+Git is a fast, scalable, distributed revision control system with an
+unusually rich command set that provides both high-level operations
+and full access to internals.
+
+See this linkgit:gittutorial[7][tutorial] to get started, then see
+link:everyday.html[Everyday Git] for a useful minimum set of commands, and
+"man git-commandname" for documentation of each command. CVS users may
+also want to read linkgit:gitcvs-migration[7][CVS migration]. See
+link:user-manual.html[Git User's Manual] for a more in-depth
+introduction.
+
+The COMMAND is either a name of a Git command (see below) or an alias
+as defined in the configuration file (see linkgit:git-config[1]).
+
+Formatted and hyperlinked version of the latest git
+documentation can be viewed at
+`http://www.kernel.org/pub/software/scm/git/docs/`.
+
+ifdef::stalenotes[]
+[NOTE]
+============
+
+You are reading the documentation for the latest (possibly
+unreleased) version of git, that is available from 'master'
+branch of the `git.git` repository.
+Documentation for older releases are available here:
+
+* link:v1.5.5/git.html[documentation for release 1.5.5]
+
+* release notes for
+ link:RelNotes-1.5.5.4.txt[1.5.5.4],
+ link:RelNotes-1.5.5.3.txt[1.5.5.3],
+ link:RelNotes-1.5.5.2.txt[1.5.5.2],
+ link:RelNotes-1.5.5.1.txt[1.5.5.1],
+ link:RelNotes-1.5.5.txt[1.5.5].
+
+* link:v1.5.5.4/git.html[documentation for release 1.5.5.4]
+
+* link:v1.5.4.5/git.html[documentation for release 1.5.4.5]
+
+* release notes for
+ link:RelNotes-1.5.4.5.txt[1.5.4.5],
+ link:RelNotes-1.5.4.4.txt[1.5.4.4],
+ link:RelNotes-1.5.4.3.txt[1.5.4.3],
+ link:RelNotes-1.5.4.2.txt[1.5.4.2],
+ link:RelNotes-1.5.4.1.txt[1.5.4.1],
+ link:RelNotes-1.5.4.txt[1.5.4].
+
+* link:v1.5.3.8/git.html[documentation for release 1.5.3.8]
+
+* release notes for
+ link:RelNotes-1.5.3.8.txt[1.5.3.8],
+ link:RelNotes-1.5.3.7.txt[1.5.3.7],
+ link:RelNotes-1.5.3.6.txt[1.5.3.6],
+ link:RelNotes-1.5.3.5.txt[1.5.3.5],
+ link:RelNotes-1.5.3.4.txt[1.5.3.4],
+ link:RelNotes-1.5.3.3.txt[1.5.3.3],
+ link:RelNotes-1.5.3.2.txt[1.5.3.2],
+ link:RelNotes-1.5.3.1.txt[1.5.3.1],
+ link:RelNotes-1.5.3.txt[1.5.3].
+
+* release notes for
+ link:RelNotes-1.5.2.5.txt[1.5.2.5],
+ link:RelNotes-1.5.2.4.txt[1.5.2.4],
+ link:RelNotes-1.5.2.3.txt[1.5.2.3],
+ link:RelNotes-1.5.2.2.txt[1.5.2.2],
+ link:RelNotes-1.5.2.1.txt[1.5.2.1],
+ link:RelNotes-1.5.2.txt[1.5.2].
+
+* link:v1.5.1.6/git.html[documentation for release 1.5.1.6]
+
+* release notes for
+ link:RelNotes-1.5.1.6.txt[1.5.1.6],
+ link:RelNotes-1.5.1.5.txt[1.5.1.5],
+ link:RelNotes-1.5.1.4.txt[1.5.1.4],
+ link:RelNotes-1.5.1.3.txt[1.5.1.3],
+ link:RelNotes-1.5.1.2.txt[1.5.1.2],
+ link:RelNotes-1.5.1.1.txt[1.5.1.1],
+ link:RelNotes-1.5.1.txt[1.5.1].
+
+* link:v1.5.0.7/git.html[documentation for release 1.5.0.7]
+
+* release notes for
+ link:RelNotes-1.5.0.7.txt[1.5.0.7],
+ link:RelNotes-1.5.0.6.txt[1.5.0.6],
+ link:RelNotes-1.5.0.5.txt[1.5.0.5],
+ link:RelNotes-1.5.0.3.txt[1.5.0.3],
+ link:RelNotes-1.5.0.2.txt[1.5.0.2],
+ link:RelNotes-1.5.0.1.txt[1.5.0.1],
+ link:RelNotes-1.5.0.txt[1.5.0].
+
+* documentation for release link:v1.4.4.4/git.html[1.4.4.4],
+ link:v1.3.3/git.html[1.3.3],
+ link:v1.2.6/git.html[1.2.6],
+ link:v1.0.13/git.html[1.0.13].
+
+============
+
+endif::stalenotes[]
+
+OPTIONS
+-------
+--version::
+ Prints the git suite version that the 'git' program came from.
+
+--help::
+ Prints the synopsis and a list of the most commonly used
+ commands. If the option '--all' or '-a' is given then all
+ available commands are printed. If a git command is named this
+ option will bring up the manual page for that command.
++
+Other options are available to control how the manual page is
+displayed. See linkgit:git-help[1] for more information,
+because 'git --help ...' is converted internally into 'git
+help ...'.
+
+--exec-path::
+ Path to wherever your core git programs are installed.
+ This can also be controlled by setting the GIT_EXEC_PATH
+ environment variable. If no path is given 'git' will print
+ the current setting and then exit.
+
+-p::
+--paginate::
+ Pipe all output into 'less' (or if set, $PAGER).
+
+--no-pager::
+ Do not pipe git output into a pager.
+
+--git-dir=<path>::
+ Set the path to the repository. This can also be controlled by
+ setting the GIT_DIR environment variable. It can be an absolute
+ path or relative path to current working directory.
+
+--work-tree=<path>::
+ Set the path to the working tree. The value will not be
+ used in combination with repositories found automatically in
+ a .git directory (i.e. $GIT_DIR is not set).
+ This can also be controlled by setting the GIT_WORK_TREE
+ environment variable and the core.worktree configuration
+ variable. It can be an absolute path or relative path to
+ the directory specified by --git-dir or GIT_DIR.
+ Note: If --git-dir or GIT_DIR are specified but none of
+ --work-tree, GIT_WORK_TREE and core.worktree is specified,
+ the current working directory is regarded as the top directory
+ of your working tree.
+
+--bare::
+ Treat the repository as a bare repository. If GIT_DIR
+ environment is not set, it is set to the current working
+ directory.
+
+
+FURTHER DOCUMENTATION
+---------------------
+
+See the references above to get started using git. The following is
+probably more detail than necessary for a first-time user.
+
+The link:user-manual.html#git-concepts[git concepts chapter of the
+user-manual] and the linkgit:gitcore-tutorial[7][Core tutorial] both provide
+introductions to the underlying git architecture.
+
+See also the link:howto-index.html[howto] documents for some useful
+examples.
+
+The internals are documented link:technical/api-index.html[here].
+
+GIT COMMANDS
+------------
+
+We divide git into high level ("porcelain") commands and low level
+("plumbing") commands.
+
+High-level commands (porcelain)
+-------------------------------
+
+We separate the porcelain commands into the main commands and some
+ancillary user utilities.
+
+Main porcelain commands
+~~~~~~~~~~~~~~~~~~~~~~~
+
+include::cmds-mainporcelain.txt[]
+
+Ancillary Commands
+~~~~~~~~~~~~~~~~~~
+Manipulators:
+
+include::cmds-ancillarymanipulators.txt[]
+
+Interrogators:
+
+include::cmds-ancillaryinterrogators.txt[]
+
+
+Interacting with Others
+~~~~~~~~~~~~~~~~~~~~~~~
+
+These commands are to interact with foreign SCM and with other
+people via patch over e-mail.
+
+include::cmds-foreignscminterface.txt[]
+
+
+Low-level commands (plumbing)
+-----------------------------
+
+Although git includes its
+own porcelain layer, its low-level commands are sufficient to support
+development of alternative porcelains. Developers of such porcelains
+might start by reading about linkgit:git-update-index[1] and
+linkgit:git-read-tree[1].
+
+The interface (input, output, set of options and the semantics)
+to these low-level commands are meant to be a lot more stable
+than Porcelain level commands, because these commands are
+primarily for scripted use. The interface to Porcelain commands
+on the other hand are subject to change in order to improve the
+end user experience.
+
+The following description divides
+the low-level commands into commands that manipulate objects (in
+the repository, index, and working tree), commands that interrogate and
+compare objects, and commands that move objects and references between
+repositories.
+
+
+Manipulation commands
+~~~~~~~~~~~~~~~~~~~~~
+
+include::cmds-plumbingmanipulators.txt[]
+
+
+Interrogation commands
+~~~~~~~~~~~~~~~~~~~~~~
+
+include::cmds-plumbinginterrogators.txt[]
+
+In general, the interrogate commands do not touch the files in
+the working tree.
+
+
+Synching repositories
+~~~~~~~~~~~~~~~~~~~~~
+
+include::cmds-synchingrepositories.txt[]
+
+The following are helper programs used by the above; end users
+typically do not use them directly.
+
+include::cmds-synchelpers.txt[]
+
+
+Internal helper commands
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+These are internal helper commands used by other commands; end
+users typically do not use them directly.
+
+include::cmds-purehelpers.txt[]
+
+
+Configuration Mechanism
+-----------------------
+
+Starting from 0.99.9 (actually mid 0.99.8.GIT), `.git/config` file
+is used to hold per-repository configuration options. It is a
+simple text file modeled after `.ini` format familiar to some
+people. Here is an example:
+
+------------
+#
+# A '#' or ';' character indicates a comment.
+#
+
+; core variables
+[core]
+ ; Don't trust file modes
+ filemode = false
+
+; user identity
+[user]
+ name = "Junio C Hamano"
+ email = "junkio@twinsun.com"
+
+------------
+
+Various commands read from the configuration file and adjust
+their operation accordingly.
+
+
+Identifier Terminology
+----------------------
+<object>::
+ Indicates the object name for any type of object.
+
+<blob>::
+ Indicates a blob object name.
+
+<tree>::
+ Indicates a tree object name.
+
+<commit>::
+ Indicates a commit object name.
+
+<tree-ish>::
+ Indicates a tree, commit or tag object name. A
+ command that takes a <tree-ish> argument ultimately wants to
+ operate on a <tree> object but automatically dereferences
+ <commit> and <tag> objects that point at a <tree>.
+
+<commit-ish>::
+ Indicates a commit or tag object name. A
+ command that takes a <commit-ish> argument ultimately wants to
+ operate on a <commit> object but automatically dereferences
+ <tag> objects that point at a <commit>.
+
+<type>::
+ Indicates that an object type is required.
+ Currently one of: `blob`, `tree`, `commit`, or `tag`.
+
+<file>::
+ Indicates a filename - almost always relative to the
+ root of the tree structure `GIT_INDEX_FILE` describes.
+
+Symbolic Identifiers
+--------------------
+Any git command accepting any <object> can also use the following
+symbolic notation:
+
+HEAD::
+ indicates the head of the current branch (i.e. the
+ contents of `$GIT_DIR/HEAD`).
+
+<tag>::
+ a valid tag 'name'
+ (i.e. the contents of `$GIT_DIR/refs/tags/<tag>`).
+
+<head>::
+ a valid head 'name'
+ (i.e. the contents of `$GIT_DIR/refs/heads/<head>`).
+
+For a more complete list of ways to spell object names, see
+"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
+
+
+File/Directory Structure
+------------------------
+
+Please see the linkgit:gitrepository-layout[5][repository layout]
+document.
+
+Read linkgit:githooks[5][hooks] for more details about each hook.
+
+Higher level SCMs may provide and manage additional information in the
+`$GIT_DIR`.
+
+
+Terminology
+-----------
+Please see the linkgit:gitglossary[7][glossary] document.
+
+
+Environment Variables
+---------------------
+Various git commands use the following environment variables:
+
+The git Repository
+~~~~~~~~~~~~~~~~~~
+These environment variables apply to 'all' core git commands. Nb: it
+is worth noting that they may be used/overridden by SCMS sitting above
+git so take care if using Cogito etc.
+
+'GIT_INDEX_FILE'::
+ This environment allows the specification of an alternate
+ index file. If not specified, the default of `$GIT_DIR/index`
+ is used.
+
+'GIT_OBJECT_DIRECTORY'::
+ If the object storage directory is specified via this
+ environment variable then the sha1 directories are created
+ underneath - otherwise the default `$GIT_DIR/objects`
+ directory is used.
+
+'GIT_ALTERNATE_OBJECT_DIRECTORIES'::
+ Due to the immutable nature of git objects, old objects can be
+ archived into shared, read-only directories. This variable
+ specifies a ":" separated list of git object directories which
+ can be used to search for git objects. New objects will not be
+ written to these directories.
+
+'GIT_DIR'::
+ If the 'GIT_DIR' environment variable is set then it
+ specifies a path to use instead of the default `.git`
+ for the base of the repository.
+
+'GIT_WORK_TREE'::
+ Set the path to the working tree. The value will not be
+ used in combination with repositories found automatically in
+ a .git directory (i.e. $GIT_DIR is not set).
+ This can also be controlled by the '--work-tree' command line
+ option and the core.worktree configuration variable.
+
+git Commits
+~~~~~~~~~~~
+'GIT_AUTHOR_NAME'::
+'GIT_AUTHOR_EMAIL'::
+'GIT_AUTHOR_DATE'::
+'GIT_COMMITTER_NAME'::
+'GIT_COMMITTER_EMAIL'::
+'GIT_COMMITTER_DATE'::
+'EMAIL'::
+ see linkgit:git-commit-tree[1]
+
+git Diffs
+~~~~~~~~~
+'GIT_DIFF_OPTS'::
+ Only valid setting is "--unified=??" or "-u??" to set the
+ number of context lines shown when a unified diff is created.
+ This takes precedence over any "-U" or "--unified" option
+ value passed on the git diff command line.
+
+'GIT_EXTERNAL_DIFF'::
+ When the environment variable 'GIT_EXTERNAL_DIFF' is set, the
+ program named by it is called, instead of the diff invocation
+ described above. For a path that is added, removed, or modified,
+ 'GIT_EXTERNAL_DIFF' is called with 7 parameters:
+
+ path old-file old-hex old-mode new-file new-hex new-mode
++
+where:
+
+ <old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the
+ contents of <old|new>,
+ <old|new>-hex:: are the 40-hexdigit SHA1 hashes,
+ <old|new>-mode:: are the octal representation of the file modes.
+
++
+The file parameters can point at the user's working file
+(e.g. `new-file` in "git-diff-files"), `/dev/null` (e.g. `old-file`
+when a new file is added), or a temporary file (e.g. `old-file` in the
+index). 'GIT_EXTERNAL_DIFF' should not worry about unlinking the
+temporary file --- it is removed when 'GIT_EXTERNAL_DIFF' exits.
++
+For a path that is unmerged, 'GIT_EXTERNAL_DIFF' is called with 1
+parameter, <path>.
+
+other
+~~~~~
+'GIT_MERGE_VERBOSITY'::
+ A number controlling the amount of output shown by
+ the recursive merge strategy. Overrides merge.verbosity.
+ See linkgit:git-merge[1]
+
+'GIT_PAGER'::
+ This environment variable overrides `$PAGER`. If it is set
+ to an empty string or to the value "cat", git will not launch
+ a pager.
+
+'GIT_SSH'::
+ If this environment variable is set then linkgit:git-fetch[1]
+ and linkgit:git-push[1] will use this command instead
+ of `ssh` when they need to connect to a remote system.
+ The 'GIT_SSH' command will be given exactly two arguments:
+ the 'username@host' (or just 'host') from the URL and the
+ shell command to execute on that remote system.
++
+To pass options to the program that you want to list in GIT_SSH
+you will need to wrap the program and options into a shell script,
+then set GIT_SSH to refer to the shell script.
++
+Usually it is easier to configure any desired options through your
+personal `.ssh/config` file. Please consult your ssh documentation
+for further details.
+
+'GIT_FLUSH'::
+ If this environment variable is set to "1", then commands such
+ as git-blame (in incremental mode), git-rev-list, git-log,
+ git-whatchanged, etc., will force a flush of the output stream
+ after each commit-oriented record have been flushed. If this
+ variable is set to "0", the output of these commands will be done
+ using completely buffered I/O. If this environment variable is
+ not set, git will choose buffered or record-oriented flushing
+ based on whether stdout appears to be redirected to a file or not.
+
+'GIT_TRACE'::
+ If this variable is set to "1", "2" or "true" (comparison
+ is case insensitive), git will print `trace:` messages on
+ stderr telling about alias expansion, built-in command
+ execution and external command execution.
+ If this variable is set to an integer value greater than 1
+ and lower than 10 (strictly) then git will interpret this
+ value as an open file descriptor and will try to write the
+ trace messages into this file descriptor.
+ Alternatively, if this variable is set to an absolute path
+ (starting with a '/' character), git will interpret this
+ as a file path and will try to write the trace messages
+ into it.
+
+Discussion[[Discussion]]
+------------------------
+
+More detail on the following is available from the
+link:user-manual.html#git-concepts[git concepts chapter of the
+user-manual] and the linkgit:gitcore-tutorial[7][Core tutorial].
+
+A git project normally consists of a working directory with a ".git"
+subdirectory at the top level. The .git directory contains, among other
+things, a compressed object database representing the complete history
+of the project, an "index" file which links that history to the current
+contents of the working tree, and named pointers into that history such
+as tags and branch heads.
+
+The object database contains objects of three main types: blobs, which
+hold file data; trees, which point to blobs and other trees to build up
+directory hierarchies; and commits, which each reference a single tree
+and some number of parent commits.
+
+The commit, equivalent to what other systems call a "changeset" or
+"version", represents a step in the project's history, and each parent
+represents an immediately preceding step. Commits with more than one
+parent represent merges of independent lines of development.
+
+All objects are named by the SHA1 hash of their contents, normally
+written as a string of 40 hex digits. Such names are globally unique.
+The entire history leading up to a commit can be vouched for by signing
+just that commit. A fourth object type, the tag, is provided for this
+purpose.
+
+When first created, objects are stored in individual files, but for
+efficiency may later be compressed together into "pack files".
+
+Named pointers called refs mark interesting points in history. A ref
+may contain the SHA1 name of an object or the name of another ref. Refs
+with names beginning `ref/head/` contain the SHA1 name of the most
+recent commit (or "head") of a branch under development. SHA1 names of
+tags of interest are stored under `ref/tags/`. A special ref named
+`HEAD` contains the name of the currently checked-out branch.
+
+The index file is initialized with a list of all paths and, for each
+path, a blob object and a set of attributes. The blob object represents
+the contents of the file as of the head of the current branch. The
+attributes (last modified time, size, etc.) are taken from the
+corresponding file in the working tree. Subsequent changes to the
+working tree can be found by comparing these attributes. The index may
+be updated with new content, and new commits may be created from the
+content stored in the index.
+
+The index is also capable of storing multiple entries (called "stages")
+for a given pathname. These stages are used to hold the various
+unmerged version of a file when a merge is in progress.
+
+Authors
+-------
+* git's founding father is Linus Torvalds <torvalds@osdl.org>.
+* The current git nurse is Junio C Hamano <gitster@pobox.com>.
+* The git potty was written by Andreas Ericsson <ae@op5.se>.
+* General upbringing is handled by the git-list <git@vger.kernel.org>.
+
+Documentation
+--------------
+The documentation for git suite was started by David Greaves
+<david@dgreaves.com>, and later enhanced greatly by the
+contributors on the git-list <git@vger.kernel.org>.
+
+SEE ALSO
+--------
+linkgit:gittutorial[7], linkgit:gittutorial-2[7],
+linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
+linkgit:gitglossary[7], linkgit:gitcore-tutorial[7],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
new file mode 100644
index 0000000000..471754eb12
--- /dev/null
+++ b/Documentation/gitattributes.txt
@@ -0,0 +1,521 @@
+gitattributes(5)
+================
+
+NAME
+----
+gitattributes - defining attributes per path
+
+SYNOPSIS
+--------
+$GIT_DIR/info/attributes, gitattributes
+
+
+DESCRIPTION
+-----------
+
+A `gitattributes` file is a simple text file that gives
+`attributes` to pathnames.
+
+Each line in `gitattributes` file is of form:
+
+ glob attr1 attr2 ...
+
+That is, a glob pattern followed by an attributes list,
+separated by whitespaces. When the glob pattern matches the
+path in question, the attributes listed on the line are given to
+the path.
+
+Each attribute can be in one of these states for a given path:
+
+Set::
+
+ The path has the attribute with special value "true";
+ this is specified by listing only the name of the
+ attribute in the attribute list.
+
+Unset::
+
+ The path has the attribute with special value "false";
+ this is specified by listing the name of the attribute
+ prefixed with a dash `-` in the attribute list.
+
+Set to a value::
+
+ The path has the attribute with specified string value;
+ this is specified by listing the name of the attribute
+ followed by an equal sign `=` and its value in the
+ attribute list.
+
+Unspecified::
+
+ No glob pattern matches the path, and nothing says if
+ the path has or does not have the attribute, the
+ attribute for the path is said to be Unspecified.
+
+When more than one glob pattern matches the path, a later line
+overrides an earlier line. This overriding is done per
+attribute.
+
+When deciding what attributes are assigned to a path, git
+consults `$GIT_DIR/info/attributes` file (which has the highest
+precedence), `.gitattributes` file in the same directory as the
+path in question, and its parent directories (the further the
+directory that contains `.gitattributes` is from the path in
+question, the lower its precedence).
+
+If you wish to affect only a single repository (i.e., to assign
+attributes to files that are particular to one user's workflow), then
+attributes should be placed in the `$GIT_DIR/info/attributes` file.
+Attributes which should be version-controlled and distributed to other
+repositories (i.e., attributes of interest to all users) should go into
+`.gitattributes` files.
+
+Sometimes you would need to override an setting of an attribute
+for a path to `unspecified` state. This can be done by listing
+the name of the attribute prefixed with an exclamation point `!`.
+
+
+EFFECTS
+-------
+
+Certain operations by git can be influenced by assigning
+particular attributes to a path. Currently, the following
+operations are attributes-aware.
+
+Checking-out and checking-in
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+These attributes affect how the contents stored in the
+repository are copied to the working tree files when commands
+such as `git checkout` and `git merge` run. They also affect how
+git stores the contents you prepare in the working tree in the
+repository upon `git add` and `git commit`.
+
+`crlf`
+^^^^^^
+
+This attribute controls the line-ending convention.
+
+Set::
+
+ Setting the `crlf` attribute on a path is meant to mark
+ the path as a "text" file. 'core.autocrlf' conversion
+ takes place without guessing the content type by
+ inspection.
+
+Unset::
+
+ Unsetting the `crlf` attribute on a path is meant to
+ mark the path as a "binary" file. The path never goes
+ through line endings conversion upon checkin/checkout.
+
+Unspecified::
+
+ Unspecified `crlf` attribute tells git to apply the
+ `core.autocrlf` conversion when the file content looks
+ like text.
+
+Set to string value "input"::
+
+ This is similar to setting the attribute to `true`, but
+ also forces git to act as if `core.autocrlf` is set to
+ `input` for the path.
+
+Any other value set to `crlf` attribute is ignored and git acts
+as if the attribute is left unspecified.
+
+
+The `core.autocrlf` conversion
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If the configuration variable `core.autocrlf` is false, no
+conversion is done.
+
+When `core.autocrlf` is true, it means that the platform wants
+CRLF line endings for files in the working tree, and you want to
+convert them back to the normal LF line endings when checking
+in to the repository.
+
+When `core.autocrlf` is set to "input", line endings are
+converted to LF upon checkin, but there is no conversion done
+upon checkout.
+
+If `core.safecrlf` is set to "true" or "warn", git verifies if
+the conversion is reversible for the current setting of
+`core.autocrlf`. For "true", git rejects irreversible
+conversions; for "warn", git only prints a warning but accepts
+an irreversible conversion. The safety triggers to prevent such
+a conversion done to the files in the work tree, but there are a
+few exceptions. Even though...
+
+- "git add" itself does not touch the files in the work tree, the
+ next checkout would, so the safety triggers;
+
+- "git apply" to update a text file with a patch does touch the files
+ in the work tree, but the operation is about text files and CRLF
+ conversion is about fixing the line ending inconsistencies, so the
+ safety does not trigger;
+
+- "git diff" itself does not touch the files in the work tree, it is
+ often run to inspect the changes you intend to next "git add". To
+ catch potential problems early, safety triggers.
+
+
+`ident`
+^^^^^^^
+
+When the attribute `ident` is set to a path, git replaces
+`$Id$` in the blob object with `$Id:`, followed by
+40-character hexadecimal blob object name, followed by a dollar
+sign `$` upon checkout. Any byte sequence that begins with
+`$Id:` and ends with `$` in the worktree file is replaced
+with `$Id$` upon check-in.
+
+
+`filter`
+^^^^^^^^
+
+A `filter` attribute can be set to a string value that names a
+filter driver specified in the configuration.
+
+A filter driver consists of a `clean` command and a `smudge`
+command, either of which can be left unspecified. Upon
+checkout, when the `smudge` command is specified, the command is
+fed the blob object from its standard input, and its standard
+output is used to update the worktree file. Similarly, the
+`clean` command is used to convert the contents of worktree file
+upon checkin.
+
+A missing filter driver definition in the config is not an error
+but makes the filter a no-op passthru.
+
+The content filtering is done to massage the content into a
+shape that is more convenient for the platform, filesystem, and
+the user to use. The key phrase here is "more convenient" and not
+"turning something unusable into usable". In other words, the
+intent is that if someone unsets the filter driver definition,
+or does not have the appropriate filter program, the project
+should still be usable.
+
+
+Interaction between checkin/checkout attributes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In the check-in codepath, the worktree file is first converted
+with `filter` driver (if specified and corresponding driver
+defined), then the result is processed with `ident` (if
+specified), and then finally with `crlf` (again, if specified
+and applicable).
+
+In the check-out codepath, the blob content is first converted
+with `crlf`, and then `ident` and fed to `filter`.
+
+
+Generating diff text
+~~~~~~~~~~~~~~~~~~~~
+
+The attribute `diff` affects if `git diff` generates textual
+patch for the path or just says `Binary files differ`. It also
+can affect what line is shown on the hunk header `@@ -k,l +n,m @@`
+line.
+
+Set::
+
+ A path to which the `diff` attribute is set is treated
+ as text, even when they contain byte values that
+ normally never appear in text files, such as NUL.
+
+Unset::
+
+ A path to which the `diff` attribute is unset will
+ generate `Binary files differ`.
+
+Unspecified::
+
+ A path to which the `diff` attribute is unspecified
+ first gets its contents inspected, and if it looks like
+ text, it is treated as text. Otherwise it would
+ generate `Binary files differ`.
+
+String::
+
+ Diff is shown using the specified custom diff driver.
+ The driver program is given its input using the same
+ calling convention as used for GIT_EXTERNAL_DIFF
+ program. This name is also used for custom hunk header
+ selection.
+
+
+Defining a custom diff driver
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The definition of a diff driver is done in `gitconfig`, not
+`gitattributes` file, so strictly speaking this manual page is a
+wrong place to talk about it. However...
+
+To define a custom diff driver `jcdiff`, add a section to your
+`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this:
+
+----------------------------------------------------------------
+[diff "jcdiff"]
+ command = j-c-diff
+----------------------------------------------------------------
+
+When git needs to show you a diff for the path with `diff`
+attribute set to `jcdiff`, it calls the command you specified
+with the above configuration, i.e. `j-c-diff`, with 7
+parameters, just like `GIT_EXTERNAL_DIFF` program is called.
+See linkgit:git[1] for details.
+
+
+Defining a custom hunk-header
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Each group of changes (called "hunk") in the textual diff output
+is prefixed with a line of the form:
+
+ @@ -k,l +n,m @@ TEXT
+
+The text is called 'hunk header', and by default a line that
+begins with an alphabet, an underscore or a dollar sign is used,
+which matches what GNU `diff -p` output uses. This default
+selection however is not suited for some contents, and you can
+use customized pattern to make a selection.
+
+First in .gitattributes, you would assign the `diff` attribute
+for paths.
+
+------------------------
+*.tex diff=tex
+------------------------
+
+Then, you would define "diff.tex.funcname" configuration to
+specify a regular expression that matches a line that you would
+want to appear as the hunk header, like this:
+
+------------------------
+[diff "tex"]
+ funcname = "^\\(\\\\\\(sub\\)*section{.*\\)$"
+------------------------
+
+Note. A single level of backslashes are eaten by the
+configuration file parser, so you would need to double the
+backslashes; the pattern above picks a line that begins with a
+backslash, and zero or more occurrences of `sub` followed by
+`section` followed by open brace, to the end of line.
+
+There are a few built-in patterns to make this easier, and `tex`
+is one of them, so you do not have to write the above in your
+configuration file (you still need to enable this with the
+attribute mechanism, via `.gitattributes`). Another built-in
+pattern is defined for `java` that defines a pattern suitable
+for program text in Java language.
+
+
+Performing a three-way merge
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The attribute `merge` affects how three versions of a file is
+merged when a file-level merge is necessary during `git merge`,
+and other programs such as `git revert` and `git cherry-pick`.
+
+Set::
+
+ Built-in 3-way merge driver is used to merge the
+ contents in a way similar to `merge` command of `RCS`
+ suite. This is suitable for ordinary text files.
+
+Unset::
+
+ Take the version from the current branch as the
+ tentative merge result, and declare that the merge has
+ conflicts. This is suitable for binary files that does
+ not have a well-defined merge semantics.
+
+Unspecified::
+
+ By default, this uses the same built-in 3-way merge
+ driver as is the case the `merge` attribute is set.
+ However, `merge.default` configuration variable can name
+ different merge driver to be used for paths to which the
+ `merge` attribute is unspecified.
+
+String::
+
+ 3-way merge is performed using the specified custom
+ merge driver. The built-in 3-way merge driver can be
+ explicitly specified by asking for "text" driver; the
+ built-in "take the current branch" driver can be
+ requested with "binary".
+
+
+Built-in merge drivers
+^^^^^^^^^^^^^^^^^^^^^^
+
+There are a few built-in low-level merge drivers defined that
+can be asked for via the `merge` attribute.
+
+text::
+
+ Usual 3-way file level merge for text files. Conflicted
+ regions are marked with conflict markers `<<<<<<<`,
+ `=======` and `>>>>>>>`. The version from your branch
+ appears before the `=======` marker, and the version
+ from the merged branch appears after the `=======`
+ marker.
+
+binary::
+
+ Keep the version from your branch in the work tree, but
+ leave the path in the conflicted state for the user to
+ sort out.
+
+union::
+
+ Run 3-way file level merge for text files, but take
+ lines from both versions, instead of leaving conflict
+ markers. This tends to leave the added lines in the
+ resulting file in random order and the user should
+ verify the result. Do not use this if you do not
+ understand the implications.
+
+
+Defining a custom merge driver
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The definition of a merge driver is done in the `.git/config`
+file, not in the `gitattributes` file, so strictly speaking this
+manual page is a wrong place to talk about it. However...
+
+To define a custom merge driver `filfre`, add a section to your
+`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this:
+
+----------------------------------------------------------------
+[merge "filfre"]
+ name = feel-free merge driver
+ driver = filfre %O %A %B
+ recursive = binary
+----------------------------------------------------------------
+
+The `merge.*.name` variable gives the driver a human-readable
+name.
+
+The `merge.*.driver` variable's value is used to construct a
+command to run to merge ancestor's version (`%O`), current
+version (`%A`) and the other branches' version (`%B`). These
+three tokens are replaced with the names of temporary files that
+hold the contents of these versions when the command line is
+built.
+
+The merge driver is expected to leave the result of the merge in
+the file named with `%A` by overwriting it, and exit with zero
+status if it managed to merge them cleanly, or non-zero if there
+were conflicts.
+
+The `merge.*.recursive` variable specifies what other merge
+driver to use when the merge driver is called for an internal
+merge between common ancestors, when there are more than one.
+When left unspecified, the driver itself is used for both
+internal merge and the final merge.
+
+
+Checking whitespace errors
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`whitespace`
+^^^^^^^^^^^^
+
+The `core.whitespace` configuration variable allows you to define what
+`diff` and `apply` should consider whitespace errors for all paths in
+the project (See linkgit:git-config[1]). This attribute gives you finer
+control per path.
+
+Set::
+
+ Notice all types of potential whitespace errors known to git.
+
+Unset::
+
+ Do not notice anything as error.
+
+Unspecified::
+
+ Use the value of `core.whitespace` configuration variable to
+ decide what to notice as error.
+
+String::
+
+ Specify a comma separate list of common whitespace problems to
+ notice in the same format as `core.whitespace` configuration
+ variable.
+
+
+EXAMPLE
+-------
+
+If you have these three `gitattributes` file:
+
+----------------------------------------------------------------
+(in $GIT_DIR/info/attributes)
+
+a* foo !bar -baz
+
+(in .gitattributes)
+abc foo bar baz
+
+(in t/.gitattributes)
+ab* merge=filfre
+abc -foo -bar
+*.c frotz
+----------------------------------------------------------------
+
+the attributes given to path `t/abc` are computed as follows:
+
+1. By examining `t/.gitattributes` (which is in the same
+ directory as the path in question), git finds that the first
+ line matches. `merge` attribute is set. It also finds that
+ the second line matches, and attributes `foo` and `bar`
+ are unset.
+
+2. Then it examines `.gitattributes` (which is in the parent
+ directory), and finds that the first line matches, but
+ `t/.gitattributes` file already decided how `merge`, `foo`
+ and `bar` attributes should be given to this path, so it
+ leaves `foo` and `bar` unset. Attribute `baz` is set.
+
+3. Finally it examines `$GIT_DIR/info/attributes`. This file
+ is used to override the in-tree settings. The first line is
+ a match, and `foo` is set, `bar` is reverted to unspecified
+ state, and `baz` is unset.
+
+As the result, the attributes assignment to `t/abc` becomes:
+
+----------------------------------------------------------------
+foo set to true
+bar unspecified
+baz set to false
+merge set to string value "filfre"
+frotz unspecified
+----------------------------------------------------------------
+
+
+Creating an archive
+~~~~~~~~~~~~~~~~~~~
+
+`export-subst`
+^^^^^^^^^^^^^^
+
+If the attribute `export-subst` is set for a file then git will expand
+several placeholders when adding this file to an archive. The
+expansion depends on the availability of a commit ID, i.e. if
+linkgit:git-archive[1] has been given a tree instead of a commit or a
+tag then no replacement will be done. The placeholders are the same
+as those for the option `--pretty=format:` of linkgit:git-log[1],
+except that they need to be wrapped like this: `$Format:PLACEHOLDERS$`
+in the file. E.g. the string `$Format:%H$` will be replaced by the
+commit hash.
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
new file mode 100644
index 0000000000..8fb5d889e5
--- /dev/null
+++ b/Documentation/gitcli.txt
@@ -0,0 +1,113 @@
+gitcli(7)
+=========
+
+NAME
+----
+gitcli - git command line interface and conventions
+
+SYNOPSIS
+--------
+gitcli
+
+
+DESCRIPTION
+-----------
+
+This manual describes best practice in how to use git CLI. Here are
+the rules that you should follow when you are scripting git:
+
+ * it's preferred to use the non dashed form of git commands, which means that
+ you should prefer `"git foo"` to `"git-foo"`.
+
+ * splitting short options to separate words (prefer `"git foo -a -b"`
+ to `"git foo -ab"`, the latter may not even work).
+
+ * when a command line option takes an argument, use the 'sticked' form. In
+ other words, write `"git foo -oArg"` instead of `"git foo -o Arg"` for short
+ options, and `"git foo --long-opt=Arg"` instead of `"git foo --long-opt Arg"`
+ for long options. An option that takes optional option-argument must be
+ written in the 'sticked' form.
+
+ * when you give a revision parameter to a command, make sure the parameter is
+ not ambiguous with a name of a file in the work tree. E.g. do not write
+ `"git log -1 HEAD"` but write `"git log -1 HEAD --"`; the former will not work
+ if you happen to have a file called `HEAD` in the work tree.
+
+
+ENHANCED CLI
+------------
+From the git 1.5.4 series and further, many git commands (not all of them at the
+time of the writing though) come with an enhanced option parser.
+
+Here is an exhaustive list of the facilities provided by this option parser.
+
+
+Magic Options
+~~~~~~~~~~~~~
+Commands which have the enhanced option parser activated all understand a
+couple of magic command line options:
+
+-h::
+ gives a pretty printed usage of the command.
++
+---------------------------------------------
+$ git describe -h
+usage: git-describe [options] <committish>*
+
+ --contains find the tag that comes after the commit
+ --debug debug search strategy on stderr
+ --all use any ref in .git/refs
+ --tags use any tag in .git/refs/tags
+ --abbrev [<n>] use <n> digits to display SHA-1s
+ --candidates <n> consider <n> most recent tags (default: 10)
+---------------------------------------------
+
+--help-all::
+ Some git commands take options that are only used for plumbing or that
+ are deprecated, and such options are hidden from the default usage. This
+ option gives the full list of options.
+
+
+Negating options
+~~~~~~~~~~~~~~~~
+Options with long option names can be negated by prefixing `"--no-"`. For
+example, `"git branch"` has the option `"--track"` which is 'on' by default. You
+can use `"--no-track"` to override that behaviour. The same goes for `"--color"`
+and `"--no-color"`.
+
+
+Aggregating short options
+~~~~~~~~~~~~~~~~~~~~~~~~~
+Commands that support the enhanced option parser allow you to aggregate short
+options. This means that you can for example use `"git rm -rf"` or
+`"git clean -fdx"`.
+
+
+Separating argument from the option
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+You can write the mandatory option parameter to an option as a separate
+word on the command line. That means that all the following uses work:
+
+----------------------------
+$ git foo --long-opt=Arg
+$ git foo --long-opt Arg
+$ git foo -oArg
+$ git foo -o Arg
+----------------------------
+
+However, this is *NOT* allowed for switches with an optional value, where the
+'sticked' form must be used:
+----------------------------
+$ git describe --abbrev HEAD # correct
+$ git describe --abbrev=10 HEAD # correct
+$ git describe --abbrev 10 HEAD # NOT WHAT YOU MEANT
+----------------------------
+
+
+Documentation
+-------------
+Documentation by Pierre Habouzit.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
new file mode 100644
index 0000000000..cb4ec40440
--- /dev/null
+++ b/Documentation/gitcore-tutorial.txt
@@ -0,0 +1,1699 @@
+gitcore-tutorial(7)
+===================
+
+NAME
+----
+gitcore-tutorial - A git core tutorial for developers
+
+SYNOPSIS
+--------
+git *
+
+DESCRIPTION
+-----------
+
+This tutorial explains how to use the "core" git programs to set up and
+work with a git repository.
+
+If you just need to use git as a revision control system you may prefer
+to start with linkgit:gittutorial[7][a tutorial introduction to git] or
+link:user-manual.html[the git user manual].
+
+However, an understanding of these low-level tools can be helpful if
+you want to understand git's internals.
+
+The core git is often called "plumbing", with the prettier user
+interfaces on top of it called "porcelain". You may not want to use the
+plumbing directly very often, but it can be good to know what the
+plumbing does for when the porcelain isn't flushing.
+
+[NOTE]
+Deeper technical details are often marked as Notes, which you can
+skip on your first reading.
+
+
+Creating a git repository
+-------------------------
+
+Creating a new git repository couldn't be easier: all git repositories start
+out empty, and the only thing you need to do is find yourself a
+subdirectory that you want to use as a working tree - either an empty
+one for a totally new project, or an existing working tree that you want
+to import into git.
+
+For our first example, we're going to start a totally new repository from
+scratch, with no pre-existing files, and we'll call it `git-tutorial`.
+To start up, create a subdirectory for it, change into that
+subdirectory, and initialize the git infrastructure with `git-init`:
+
+------------------------------------------------
+$ mkdir git-tutorial
+$ cd git-tutorial
+$ git-init
+------------------------------------------------
+
+to which git will reply
+
+----------------
+Initialized empty Git repository in .git/
+----------------
+
+which is just git's way of saying that you haven't been doing anything
+strange, and that it will have created a local `.git` directory setup for
+your new project. You will now have a `.git` directory, and you can
+inspect that with `ls`. For your new empty project, it should show you
+three entries, among other things:
+
+ - a file called `HEAD`, that has `ref: refs/heads/master` in it.
+ This is similar to a symbolic link and points at
+ `refs/heads/master` relative to the `HEAD` file.
++
+Don't worry about the fact that the file that the `HEAD` link points to
+doesn't even exist yet -- you haven't created the commit that will
+start your `HEAD` development branch yet.
+
+ - a subdirectory called `objects`, which will contain all the
+ objects of your project. You should never have any real reason to
+ look at the objects directly, but you might want to know that these
+ objects are what contains all the real 'data' in your repository.
+
+ - a subdirectory called `refs`, which contains references to objects.
+
+In particular, the `refs` subdirectory will contain two other
+subdirectories, named `heads` and `tags` respectively. They do
+exactly what their names imply: they contain references to any number
+of different 'heads' of development (aka 'branches'), and to any
+'tags' that you have created to name specific versions in your
+repository.
+
+One note: the special `master` head is the default branch, which is
+why the `.git/HEAD` file was created points to it even if it
+doesn't yet exist. Basically, the `HEAD` link is supposed to always
+point to the branch you are working on right now, and you always
+start out expecting to work on the `master` branch.
+
+However, this is only a convention, and you can name your branches
+anything you want, and don't have to ever even 'have' a `master`
+branch. A number of the git tools will assume that `.git/HEAD` is
+valid, though.
+
+[NOTE]
+An 'object' is identified by its 160-bit SHA1 hash, aka 'object name',
+and a reference to an object is always the 40-byte hex
+representation of that SHA1 name. The files in the `refs`
+subdirectory are expected to contain these hex references
+(usually with a final `\'\n\'` at the end), and you should thus
+expect to see a number of 41-byte files containing these
+references in these `refs` subdirectories when you actually start
+populating your tree.
+
+[NOTE]
+An advanced user may want to take a look at the
+linkgit:gitrepository-layout[5][repository layout] document
+after finishing this tutorial.
+
+You have now created your first git repository. Of course, since it's
+empty, that's not very useful, so let's start populating it with data.
+
+
+Populating a git repository
+---------------------------
+
+We'll keep this simple and stupid, so we'll start off with populating a
+few trivial files just to get a feel for it.
+
+Start off with just creating any random files that you want to maintain
+in your git repository. We'll start off with a few bad examples, just to
+get a feel for how this works:
+
+------------------------------------------------
+$ echo "Hello World" >hello
+$ echo "Silly example" >example
+------------------------------------------------
+
+you have now created two files in your working tree (aka 'working directory'),
+but to actually check in your hard work, you will have to go through two steps:
+
+ - fill in the 'index' file (aka 'cache') with the information about your
+ working tree state.
+
+ - commit that index file as an object.
+
+The first step is trivial: when you want to tell git about any changes
+to your working tree, you use the `git-update-index` program. That
+program normally just takes a list of filenames you want to update, but
+to avoid trivial mistakes, it refuses to add new entries to the index
+(or remove existing ones) unless you explicitly tell it that you're
+adding a new entry with the `\--add` flag (or removing an entry with the
+`\--remove`) flag.
+
+So to populate the index with the two files you just created, you can do
+
+------------------------------------------------
+$ git-update-index --add hello example
+------------------------------------------------
+
+and you have now told git to track those two files.
+
+In fact, as you did that, if you now look into your object directory,
+you'll notice that git will have added two new objects to the object
+database. If you did exactly the steps above, you should now be able to do
+
+
+----------------
+$ ls .git/objects/??/*
+----------------
+
+and see two files:
+
+----------------
+.git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238
+.git/objects/f2/4c74a2e500f5ee1332c86b94199f52b1d1d962
+----------------
+
+which correspond with the objects with names of `557db...` and
+`f24c7...` respectively.
+
+If you want to, you can use `git-cat-file` to look at those objects, but
+you'll have to use the object name, not the filename of the object:
+
+----------------
+$ git-cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
+----------------
+
+where the `-t` tells `git-cat-file` to tell you what the "type" of the
+object is. git will tell you that you have a "blob" object (i.e., just a
+regular file), and you can see the contents with
+
+----------------
+$ git-cat-file "blob" 557db03
+----------------
+
+which will print out "Hello World". The object `557db03` is nothing
+more than the contents of your file `hello`.
+
+[NOTE]
+Don't confuse that object with the file `hello` itself. The
+object is literally just those specific *contents* of the file, and
+however much you later change the contents in file `hello`, the object
+we just looked at will never change. Objects are immutable.
+
+[NOTE]
+The second example demonstrates that you can
+abbreviate the object name to only the first several
+hexadecimal digits in most places.
+
+Anyway, as we mentioned previously, you normally never actually take a
+look at the objects themselves, and typing long 40-character hex
+names is not something you'd normally want to do. The above digression
+was just to show that `git-update-index` did something magical, and
+actually saved away the contents of your files into the git object
+database.
+
+Updating the index did something else too: it created a `.git/index`
+file. This is the index that describes your current working tree, and
+something you should be very aware of. Again, you normally never worry
+about the index file itself, but you should be aware of the fact that
+you have not actually really "checked in" your files into git so far,
+you've only *told* git about them.
+
+However, since git knows about them, you can now start using some of the
+most basic git commands to manipulate the files or look at their status.
+
+In particular, let's not even check in the two files into git yet, we'll
+start off by adding another line to `hello` first:
+
+------------------------------------------------
+$ echo "It's a new day for git" >>hello
+------------------------------------------------
+
+and you can now, since you told git about the previous state of `hello`, ask
+git what has changed in the tree compared to your old index, using the
+`git-diff-files` command:
+
+------------
+$ git-diff-files
+------------
+
+Oops. That wasn't very readable. It just spit out its own internal
+version of a `diff`, but that internal version really just tells you
+that it has noticed that "hello" has been modified, and that the old object
+contents it had have been replaced with something else.
+
+To make it readable, we can tell git-diff-files to output the
+differences as a patch, using the `-p` flag:
+
+------------
+$ git-diff-files -p
+diff --git a/hello b/hello
+index 557db03..263414f 100644
+--- a/hello
++++ b/hello
+@@ -1 +1,2 @@
+ Hello World
++It's a new day for git
+----
+
+i.e. the diff of the change we caused by adding another line to `hello`.
+
+In other words, `git-diff-files` always shows us the difference between
+what is recorded in the index, and what is currently in the working
+tree. That's very useful.
+
+A common shorthand for `git-diff-files -p` is to just write `git
+diff`, which will do the same thing.
+
+------------
+$ git diff
+diff --git a/hello b/hello
+index 557db03..263414f 100644
+--- a/hello
++++ b/hello
+@@ -1 +1,2 @@
+ Hello World
++It's a new day for git
+------------
+
+
+Committing git state
+--------------------
+
+Now, we want to go to the next stage in git, which is to take the files
+that git knows about in the index, and commit them as a real tree. We do
+that in two phases: creating a 'tree' object, and committing that 'tree'
+object as a 'commit' object together with an explanation of what the
+tree was all about, along with information of how we came to that state.
+
+Creating a tree object is trivial, and is done with `git-write-tree`.
+There are no options or other input: git-write-tree will take the
+current index state, and write an object that describes that whole
+index. In other words, we're now tying together all the different
+filenames with their contents (and their permissions), and we're
+creating the equivalent of a git "directory" object:
+
+------------------------------------------------
+$ git-write-tree
+------------------------------------------------
+
+and this will just output the name of the resulting tree, in this case
+(if you have done exactly as I've described) it should be
+
+----------------
+8988da15d077d4829fc51d8544c097def6644dbb
+----------------
+
+which is another incomprehensible object name. Again, if you want to,
+you can use `git-cat-file -t 8988d\...` to see that this time the object
+is not a "blob" object, but a "tree" object (you can also use
+`git-cat-file` to actually output the raw object contents, but you'll see
+mainly a binary mess, so that's less interesting).
+
+However -- normally you'd never use `git-write-tree` on its own, because
+normally you always commit a tree into a commit object using the
+`git-commit-tree` command. In fact, it's easier to not actually use
+`git-write-tree` on its own at all, but to just pass its result in as an
+argument to `git-commit-tree`.
+
+`git-commit-tree` normally takes several arguments -- it wants to know
+what the 'parent' of a commit was, but since this is the first commit
+ever in this new repository, and it has no parents, we only need to pass in
+the object name of the tree. However, `git-commit-tree` also wants to get a
+commit message on its standard input, and it will write out the resulting
+object name for the commit to its standard output.
+
+And this is where we create the `.git/refs/heads/master` file
+which is pointed at by `HEAD`. This file is supposed to contain
+the reference to the top-of-tree of the master branch, and since
+that's exactly what `git-commit-tree` spits out, we can do this
+all with a sequence of simple shell commands:
+
+------------------------------------------------
+$ tree=$(git-write-tree)
+$ commit=$(echo 'Initial commit' | git-commit-tree $tree)
+$ git-update-ref HEAD $commit
+------------------------------------------------
+
+In this case this creates a totally new commit that is not related to
+anything else. Normally you do this only *once* for a project ever, and
+all later commits will be parented on top of an earlier commit.
+
+Again, normally you'd never actually do this by hand. There is a
+helpful script called `git commit` that will do all of this for you. So
+you could have just written `git commit`
+instead, and it would have done the above magic scripting for you.
+
+
+Making a change
+---------------
+
+Remember how we did the `git-update-index` on file `hello` and then we
+changed `hello` afterward, and could compare the new state of `hello` with the
+state we saved in the index file?
+
+Further, remember how I said that `git-write-tree` writes the contents
+of the *index* file to the tree, and thus what we just committed was in
+fact the *original* contents of the file `hello`, not the new ones. We did
+that on purpose, to show the difference between the index state, and the
+state in the working tree, and how they don't have to match, even
+when we commit things.
+
+As before, if we do `git-diff-files -p` in our git-tutorial project,
+we'll still see the same difference we saw last time: the index file
+hasn't changed by the act of committing anything. However, now that we
+have committed something, we can also learn to use a new command:
+`git-diff-index`.
+
+Unlike `git-diff-files`, which showed the difference between the index
+file and the working tree, `git-diff-index` shows the differences
+between a committed *tree* and either the index file or the working
+tree. In other words, `git-diff-index` wants a tree to be diffed
+against, and before we did the commit, we couldn't do that, because we
+didn't have anything to diff against.
+
+But now we can do
+
+----------------
+$ git-diff-index -p HEAD
+----------------
+
+(where `-p` has the same meaning as it did in `git-diff-files`), and it
+will show us the same difference, but for a totally different reason.
+Now we're comparing the working tree not against the index file,
+but against the tree we just wrote. It just so happens that those two
+are obviously the same, so we get the same result.
+
+Again, because this is a common operation, you can also just shorthand
+it with
+
+----------------
+$ git diff HEAD
+----------------
+
+which ends up doing the above for you.
+
+In other words, `git-diff-index` normally compares a tree against the
+working tree, but when given the `\--cached` flag, it is told to
+instead compare against just the index cache contents, and ignore the
+current working tree state entirely. Since we just wrote the index
+file to HEAD, doing `git-diff-index \--cached -p HEAD` should thus return
+an empty set of differences, and that's exactly what it does.
+
+[NOTE]
+================
+`git-diff-index` really always uses the index for its
+comparisons, and saying that it compares a tree against the working
+tree is thus not strictly accurate. In particular, the list of
+files to compare (the "meta-data") *always* comes from the index file,
+regardless of whether the `\--cached` flag is used or not. The `\--cached`
+flag really only determines whether the file *contents* to be compared
+come from the working tree or not.
+
+This is not hard to understand, as soon as you realize that git simply
+never knows (or cares) about files that it is not told about
+explicitly. git will never go *looking* for files to compare, it
+expects you to tell it what the files are, and that's what the index
+is there for.
+================
+
+However, our next step is to commit the *change* we did, and again, to
+understand what's going on, keep in mind the difference between "working
+tree contents", "index file" and "committed tree". We have changes
+in the working tree that we want to commit, and we always have to
+work through the index file, so the first thing we need to do is to
+update the index cache:
+
+------------------------------------------------
+$ git-update-index hello
+------------------------------------------------
+
+(note how we didn't need the `\--add` flag this time, since git knew
+about the file already).
+
+Note what happens to the different `git-diff-\*` versions here. After
+we've updated `hello` in the index, `git-diff-files -p` now shows no
+differences, but `git-diff-index -p HEAD` still *does* show that the
+current state is different from the state we committed. In fact, now
+`git-diff-index` shows the same difference whether we use the `--cached`
+flag or not, since now the index is coherent with the working tree.
+
+Now, since we've updated `hello` in the index, we can commit the new
+version. We could do it by writing the tree by hand again, and
+committing the tree (this time we'd have to use the `-p HEAD` flag to
+tell commit that the HEAD was the *parent* of the new commit, and that
+this wasn't an initial commit any more), but you've done that once
+already, so let's just use the helpful script this time:
+
+------------------------------------------------
+$ git commit
+------------------------------------------------
+
+which starts an editor for you to write the commit message and tells you
+a bit about what you have done.
+
+Write whatever message you want, and all the lines that start with '#'
+will be pruned out, and the rest will be used as the commit message for
+the change. If you decide you don't want to commit anything after all at
+this point (you can continue to edit things and update the index), you
+can just leave an empty message. Otherwise `git commit` will commit
+the change for you.
+
+You've now made your first real git commit. And if you're interested in
+looking at what `git commit` really does, feel free to investigate:
+it's a few very simple shell scripts to generate the helpful (?) commit
+message headers, and a few one-liners that actually do the
+commit itself (`git-commit`).
+
+
+Inspecting Changes
+------------------
+
+While creating changes is useful, it's even more useful if you can tell
+later what changed. The most useful command for this is another of the
+`diff` family, namely `git-diff-tree`.
+
+`git-diff-tree` can be given two arbitrary trees, and it will tell you the
+differences between them. Perhaps even more commonly, though, you can
+give it just a single commit object, and it will figure out the parent
+of that commit itself, and show the difference directly. Thus, to get
+the same diff that we've already seen several times, we can now do
+
+----------------
+$ git-diff-tree -p HEAD
+----------------
+
+(again, `-p` means to show the difference as a human-readable patch),
+and it will show what the last commit (in `HEAD`) actually changed.
+
+[NOTE]
+============
+Here is an ASCII art by Jon Loeliger that illustrates how
+various diff-\* commands compare things.
+
+ diff-tree
+ +----+
+ | |
+ | |
+ V V
+ +-----------+
+ | Object DB |
+ | Backing |
+ | Store |
+ +-----------+
+ ^ ^
+ | |
+ | | diff-index --cached
+ | |
+ diff-index | V
+ | +-----------+
+ | | Index |
+ | | "cache" |
+ | +-----------+
+ | ^
+ | |
+ | | diff-files
+ | |
+ V V
+ +-----------+
+ | Working |
+ | Directory |
+ +-----------+
+============
+
+More interestingly, you can also give `git-diff-tree` the `--pretty` flag,
+which tells it to also show the commit message and author and date of the
+commit, and you can tell it to show a whole series of diffs.
+Alternatively, you can tell it to be "silent", and not show the diffs at
+all, but just show the actual commit message.
+
+In fact, together with the `git-rev-list` program (which generates a
+list of revisions), `git-diff-tree` ends up being a veritable fount of
+changes. A trivial (but very useful) script called `git-whatchanged` is
+included with git which does exactly this, and shows a log of recent
+activities.
+
+To see the whole history of our pitiful little git-tutorial project, you
+can do
+
+----------------
+$ git log
+----------------
+
+which shows just the log messages, or if we want to see the log together
+with the associated patches use the more complex (and much more
+powerful)
+
+----------------
+$ git-whatchanged -p
+----------------
+
+and you will see exactly what has changed in the repository over its
+short history.
+
+[NOTE]
+When using the above two commands, the initial commit will be shown.
+If this is a problem because it is huge, you can hide it by setting
+the log.showroot configuration variable to false. Having this, you
+can still show it for each command just adding the `\--root` option,
+which is a flag for `git-diff-tree` accepted by both commands.
+
+With that, you should now be having some inkling of what git does, and
+can explore on your own.
+
+[NOTE]
+Most likely, you are not directly using the core
+git Plumbing commands, but using Porcelain such as `git-add`, `git-rm'
+and `git-commit'.
+
+
+Tagging a version
+-----------------
+
+In git, there are two kinds of tags, a "light" one, and an "annotated tag".
+
+A "light" tag is technically nothing more than a branch, except we put
+it in the `.git/refs/tags/` subdirectory instead of calling it a `head`.
+So the simplest form of tag involves nothing more than
+
+------------------------------------------------
+$ git tag my-first-tag
+------------------------------------------------
+
+which just writes the current `HEAD` into the `.git/refs/tags/my-first-tag`
+file, after which point you can then use this symbolic name for that
+particular state. You can, for example, do
+
+----------------
+$ git diff my-first-tag
+----------------
+
+to diff your current state against that tag which at this point will
+obviously be an empty diff, but if you continue to develop and commit
+stuff, you can use your tag as an "anchor-point" to see what has changed
+since you tagged it.
+
+An "annotated tag" is actually a real git object, and contains not only a
+pointer to the state you want to tag, but also a small tag name and
+message, along with optionally a PGP signature that says that yes,
+you really did
+that tag. You create these annotated tags with either the `-a` or
+`-s` flag to `git tag`:
+
+----------------
+$ git tag -s <tagname>
+----------------
+
+which will sign the current `HEAD` (but you can also give it another
+argument that specifies the thing to tag, i.e., you could have tagged the
+current `mybranch` point by using `git tag <tagname> mybranch`).
+
+You normally only do signed tags for major releases or things
+like that, while the light-weight tags are useful for any marking you
+want to do -- any time you decide that you want to remember a certain
+point, just create a private tag for it, and you have a nice symbolic
+name for the state at that point.
+
+
+Copying repositories
+--------------------
+
+git repositories are normally totally self-sufficient and relocatable.
+Unlike CVS, for example, there is no separate notion of
+"repository" and "working tree". A git repository normally *is* the
+working tree, with the local git information hidden in the `.git`
+subdirectory. There is nothing else. What you see is what you got.
+
+[NOTE]
+You can tell git to split the git internal information from
+the directory that it tracks, but we'll ignore that for now: it's not
+how normal projects work, and it's really only meant for special uses.
+So the mental model of "the git information is always tied directly to
+the working tree that it describes" may not be technically 100%
+accurate, but it's a good model for all normal use.
+
+This has two implications:
+
+ - if you grow bored with the tutorial repository you created (or you've
+ made a mistake and want to start all over), you can just do simple
++
+----------------
+$ rm -rf git-tutorial
+----------------
++
+and it will be gone. There's no external repository, and there's no
+history outside the project you created.
+
+ - if you want to move or duplicate a git repository, you can do so. There
+ is `git clone` command, but if all you want to do is just to
+ create a copy of your repository (with all the full history that
+ went along with it), you can do so with a regular
+ `cp -a git-tutorial new-git-tutorial`.
++
+Note that when you've moved or copied a git repository, your git index
+file (which caches various information, notably some of the "stat"
+information for the files involved) will likely need to be refreshed.
+So after you do a `cp -a` to create a new copy, you'll want to do
++
+----------------
+$ git-update-index --refresh
+----------------
++
+in the new repository to make sure that the index file is up-to-date.
+
+Note that the second point is true even across machines. You can
+duplicate a remote git repository with *any* regular copy mechanism, be it
+`scp`, `rsync` or `wget`.
+
+When copying a remote repository, you'll want to at a minimum update the
+index cache when you do this, and especially with other peoples'
+repositories you often want to make sure that the index cache is in some
+known state (you don't know *what* they've done and not yet checked in),
+so usually you'll precede the `git-update-index` with a
+
+----------------
+$ git-read-tree --reset HEAD
+$ git-update-index --refresh
+----------------
+
+which will force a total index re-build from the tree pointed to by `HEAD`.
+It resets the index contents to `HEAD`, and then the `git-update-index`
+makes sure to match up all index entries with the checked-out files.
+If the original repository had uncommitted changes in its
+working tree, `git-update-index --refresh` notices them and
+tells you they need to be updated.
+
+The above can also be written as simply
+
+----------------
+$ git reset
+----------------
+
+and in fact a lot of the common git command combinations can be scripted
+with the `git xyz` interfaces. You can learn things by just looking
+at what the various git scripts do. For example, `git reset` used to be
+the above two lines implemented in `git-reset`, but some things like
+`git status` and `git commit` are slightly more complex scripts around
+the basic git commands.
+
+Many (most?) public remote repositories will not contain any of
+the checked out files or even an index file, and will *only* contain the
+actual core git files. Such a repository usually doesn't even have the
+`.git` subdirectory, but has all the git files directly in the
+repository.
+
+To create your own local live copy of such a "raw" git repository, you'd
+first create your own subdirectory for the project, and then copy the
+raw repository contents into the `.git` directory. For example, to
+create your own copy of the git repository, you'd do the following
+
+----------------
+$ mkdir my-git
+$ cd my-git
+$ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git
+----------------
+
+followed by
+
+----------------
+$ git-read-tree HEAD
+----------------
+
+to populate the index. However, now you have populated the index, and
+you have all the git internal files, but you will notice that you don't
+actually have any of the working tree files to work on. To get
+those, you'd check them out with
+
+----------------
+$ git-checkout-index -u -a
+----------------
+
+where the `-u` flag means that you want the checkout to keep the index
+up-to-date (so that you don't have to refresh it afterward), and the
+`-a` flag means "check out all files" (if you have a stale copy or an
+older version of a checked out tree you may also need to add the `-f`
+flag first, to tell git-checkout-index to *force* overwriting of any old
+files).
+
+Again, this can all be simplified with
+
+----------------
+$ git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ my-git
+$ cd my-git
+$ git checkout
+----------------
+
+which will end up doing all of the above for you.
+
+You have now successfully copied somebody else's (mine) remote
+repository, and checked it out.
+
+
+Creating a new branch
+---------------------
+
+Branches in git are really nothing more than pointers into the git
+object database from within the `.git/refs/` subdirectory, and as we
+already discussed, the `HEAD` branch is nothing but a symlink to one of
+these object pointers.
+
+You can at any time create a new branch by just picking an arbitrary
+point in the project history, and just writing the SHA1 name of that
+object into a file under `.git/refs/heads/`. You can use any filename you
+want (and indeed, subdirectories), but the convention is that the
+"normal" branch is called `master`. That's just a convention, though,
+and nothing enforces it.
+
+To show that as an example, let's go back to the git-tutorial repository we
+used earlier, and create a branch in it. You do that by simply just
+saying that you want to check out a new branch:
+
+------------
+$ git checkout -b mybranch
+------------
+
+will create a new branch based at the current `HEAD` position, and switch
+to it.
+
+[NOTE]
+================================================
+If you make the decision to start your new branch at some
+other point in the history than the current `HEAD`, you can do so by
+just telling `git checkout` what the base of the checkout would be.
+In other words, if you have an earlier tag or branch, you'd just do
+
+------------
+$ git checkout -b mybranch earlier-commit
+------------
+
+and it would create the new branch `mybranch` at the earlier commit,
+and check out the state at that time.
+================================================
+
+You can always just jump back to your original `master` branch by doing
+
+------------
+$ git checkout master
+------------
+
+(or any other branch-name, for that matter) and if you forget which
+branch you happen to be on, a simple
+
+------------
+$ cat .git/HEAD
+------------
+
+will tell you where it's pointing. To get the list of branches
+you have, you can say
+
+------------
+$ git branch
+------------
+
+which used to be nothing more than a simple script around `ls .git/refs/heads`.
+There will be an asterisk in front of the branch you are currently on.
+
+Sometimes you may wish to create a new branch _without_ actually
+checking it out and switching to it. If so, just use the command
+
+------------
+$ git branch <branchname> [startingpoint]
+------------
+
+which will simply _create_ the branch, but will not do anything further.
+You can then later -- once you decide that you want to actually develop
+on that branch -- switch to that branch with a regular `git checkout`
+with the branchname as the argument.
+
+
+Merging two branches
+--------------------
+
+One of the ideas of having a branch is that you do some (possibly
+experimental) work in it, and eventually merge it back to the main
+branch. So assuming you created the above `mybranch` that started out
+being the same as the original `master` branch, let's make sure we're in
+that branch, and do some work there.
+
+------------------------------------------------
+$ git checkout mybranch
+$ echo "Work, work, work" >>hello
+$ git commit -m "Some work." -i hello
+------------------------------------------------
+
+Here, we just added another line to `hello`, and we used a shorthand for
+doing both `git-update-index hello` and `git commit` by just giving the
+filename directly to `git commit`, with an `-i` flag (it tells
+git to 'include' that file in addition to what you have done to
+the index file so far when making the commit). The `-m` flag is to give the
+commit log message from the command line.
+
+Now, to make it a bit more interesting, let's assume that somebody else
+does some work in the original branch, and simulate that by going back
+to the master branch, and editing the same file differently there:
+
+------------
+$ git checkout master
+------------
+
+Here, take a moment to look at the contents of `hello`, and notice how they
+don't contain the work we just did in `mybranch` -- because that work
+hasn't happened in the `master` branch at all. Then do
+
+------------
+$ echo "Play, play, play" >>hello
+$ echo "Lots of fun" >>example
+$ git commit -m "Some fun." -i hello example
+------------
+
+since the master branch is obviously in a much better mood.
+
+Now, you've got two branches, and you decide that you want to merge the
+work done. Before we do that, let's introduce a cool graphical tool that
+helps you view what's going on:
+
+----------------
+$ gitk --all
+----------------
+
+will show you graphically both of your branches (that's what the `\--all`
+means: normally it will just show you your current `HEAD`) and their
+histories. You can also see exactly how they came to be from a common
+source.
+
+Anyway, let's exit `gitk` (`^Q` or the File menu), and decide that we want
+to merge the work we did on the `mybranch` branch into the `master`
+branch (which is currently our `HEAD` too). To do that, there's a nice
+script called `git merge`, which wants to know which branches you want
+to resolve and what the merge is all about:
+
+------------
+$ git merge -m "Merge work in mybranch" mybranch
+------------
+
+where the first argument is going to be used as the commit message if
+the merge can be resolved automatically.
+
+Now, in this case we've intentionally created a situation where the
+merge will need to be fixed up by hand, though, so git will do as much
+of it as it can automatically (which in this case is just merge the `example`
+file, which had no differences in the `mybranch` branch), and say:
+
+----------------
+ Auto-merging hello
+ CONFLICT (content): Merge conflict in hello
+ Automatic merge failed; fix up by hand
+----------------
+
+It tells you that it did an "Automatic merge", which
+failed due to conflicts in `hello`.
+
+Not to worry. It left the (trivial) conflict in `hello` in the same form you
+should already be well used to if you've ever used CVS, so let's just
+open `hello` in our editor (whatever that may be), and fix it up somehow.
+I'd suggest just making it so that `hello` contains all four lines:
+
+------------
+Hello World
+It's a new day for git
+Play, play, play
+Work, work, work
+------------
+
+and once you're happy with your manual merge, just do a
+
+------------
+$ git commit -i hello
+------------
+
+which will very loudly warn you that you're now committing a merge
+(which is correct, so never mind), and you can write a small merge
+message about your adventures in git-merge-land.
+
+After you're done, start up `gitk \--all` to see graphically what the
+history looks like. Notice that `mybranch` still exists, and you can
+switch to it, and continue to work with it if you want to. The
+`mybranch` branch will not contain the merge, but next time you merge it
+from the `master` branch, git will know how you merged it, so you'll not
+have to do _that_ merge again.
+
+Another useful tool, especially if you do not always work in X-Window
+environment, is `git show-branch`.
+
+------------------------------------------------
+$ git-show-branch --topo-order --more=1 master mybranch
+* [master] Merge work in mybranch
+ ! [mybranch] Some work.
+--
+- [master] Merge work in mybranch
+*+ [mybranch] Some work.
+* [master^] Some fun.
+------------------------------------------------
+
+The first two lines indicate that it is showing the two branches
+and the first line of the commit log message from their
+top-of-the-tree commits, you are currently on `master` branch
+(notice the asterisk `\*` character), and the first column for
+the later output lines is used to show commits contained in the
+`master` branch, and the second column for the `mybranch`
+branch. Three commits are shown along with their log messages.
+All of them have non blank characters in the first column (`*`
+shows an ordinary commit on the current branch, `-` is a merge commit), which
+means they are now part of the `master` branch. Only the "Some
+work" commit has the plus `+` character in the second column,
+because `mybranch` has not been merged to incorporate these
+commits from the master branch. The string inside brackets
+before the commit log message is a short name you can use to
+name the commit. In the above example, 'master' and 'mybranch'
+are branch heads. 'master^' is the first parent of 'master'
+branch head. Please see 'git-rev-parse' documentation if you
+see more complex cases.
+
+[NOTE]
+Without the '--more=1' option, 'git-show-branch' would not output the
+'[master^]' commit, as '[mybranch]' commit is a common ancestor of
+both 'master' and 'mybranch' tips. Please see 'git-show-branch'
+documentation for details.
+
+[NOTE]
+If there were more commits on the 'master' branch after the merge, the
+merge commit itself would not be shown by 'git-show-branch' by
+default. You would need to provide '--sparse' option to make the
+merge commit visible in this case.
+
+Now, let's pretend you are the one who did all the work in
+`mybranch`, and the fruit of your hard work has finally been merged
+to the `master` branch. Let's go back to `mybranch`, and run
+`git merge` to get the "upstream changes" back to your branch.
+
+------------
+$ git checkout mybranch
+$ git merge -m "Merge upstream changes." master
+------------
+
+This outputs something like this (the actual commit object names
+would be different)
+
+----------------
+Updating from ae3a2da... to a80b4aa....
+Fast forward
+ example | 1 +
+ hello | 1 +
+ 2 files changed, 2 insertions(+), 0 deletions(-)
+----------------
+
+Because your branch did not contain anything more than what are
+already merged into the `master` branch, the merge operation did
+not actually do a merge. Instead, it just updated the top of
+the tree of your branch to that of the `master` branch. This is
+often called 'fast forward' merge.
+
+You can run `gitk \--all` again to see how the commit ancestry
+looks like, or run `show-branch`, which tells you this.
+
+------------------------------------------------
+$ git show-branch master mybranch
+! [master] Merge work in mybranch
+ * [mybranch] Merge work in mybranch
+--
+-- [master] Merge work in mybranch
+------------------------------------------------
+
+
+Merging external work
+---------------------
+
+It's usually much more common that you merge with somebody else than
+merging with your own branches, so it's worth pointing out that git
+makes that very easy too, and in fact, it's not that different from
+doing a `git merge`. In fact, a remote merge ends up being nothing
+more than "fetch the work from a remote repository into a temporary tag"
+followed by a `git merge`.
+
+Fetching from a remote repository is done by, unsurprisingly,
+`git fetch`:
+
+----------------
+$ git fetch <remote-repository>
+----------------
+
+One of the following transports can be used to name the
+repository to download from:
+
+Rsync::
+ `rsync://remote.machine/path/to/repo.git/`
++
+Rsync transport is usable for both uploading and downloading,
+but is completely unaware of what git does, and can produce
+unexpected results when you download from the public repository
+while the repository owner is uploading into it via `rsync`
+transport. Most notably, it could update the files under
+`refs/` which holds the object name of the topmost commits
+before uploading the files in `objects/` -- the downloader would
+obtain head commit object name while that object itself is still
+not available in the repository. For this reason, it is
+considered deprecated.
+
+SSH::
+ `remote.machine:/path/to/repo.git/` or
++
+`ssh://remote.machine/path/to/repo.git/`
++
+This transport can be used for both uploading and downloading,
+and requires you to have a log-in privilege over `ssh` to the
+remote machine. It finds out the set of objects the other side
+lacks by exchanging the head commits both ends have and
+transfers (close to) minimum set of objects. It is by far the
+most efficient way to exchange git objects between repositories.
+
+Local directory::
+ `/path/to/repo.git/`
++
+This transport is the same as SSH transport but uses `sh` to run
+both ends on the local machine instead of running other end on
+the remote machine via `ssh`.
+
+git Native::
+ `git://remote.machine/path/to/repo.git/`
++
+This transport was designed for anonymous downloading. Like SSH
+transport, it finds out the set of objects the downstream side
+lacks and transfers (close to) minimum set of objects.
+
+HTTP(S)::
+ `http://remote.machine/path/to/repo.git/`
++
+Downloader from http and https URL
+first obtains the topmost commit object name from the remote site
+by looking at the specified refname under `repo.git/refs/` directory,
+and then tries to obtain the
+commit object by downloading from `repo.git/objects/xx/xxx\...`
+using the object name of that commit object. Then it reads the
+commit object to find out its parent commits and the associate
+tree object; it repeats this process until it gets all the
+necessary objects. Because of this behavior, they are
+sometimes also called 'commit walkers'.
++
+The 'commit walkers' are sometimes also called 'dumb
+transports', because they do not require any git aware smart
+server like git Native transport does. Any stock HTTP server
+that does not even support directory index would suffice. But
+you must prepare your repository with `git-update-server-info`
+to help dumb transport downloaders.
+
+Once you fetch from the remote repository, you `merge` that
+with your current branch.
+
+However -- it's such a common thing to `fetch` and then
+immediately `merge`, that it's called `git pull`, and you can
+simply do
+
+----------------
+$ git pull <remote-repository>
+----------------
+
+and optionally give a branch-name for the remote end as a second
+argument.
+
+[NOTE]
+You could do without using any branches at all, by
+keeping as many local repositories as you would like to have
+branches, and merging between them with `git pull`, just like
+you merge between branches. The advantage of this approach is
+that it lets you keep a set of files for each `branch` checked
+out and you may find it easier to switch back and forth if you
+juggle multiple lines of development simultaneously. Of
+course, you will pay the price of more disk usage to hold
+multiple working trees, but disk space is cheap these days.
+
+It is likely that you will be pulling from the same remote
+repository from time to time. As a short hand, you can store
+the remote repository URL in the local repository's config file
+like this:
+
+------------------------------------------------
+$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
+------------------------------------------------
+
+and use the "linus" keyword with `git pull` instead of the full URL.
+
+Examples.
+
+. `git pull linus`
+. `git pull linus tag v0.99.1`
+
+the above are equivalent to:
+
+. `git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD`
+. `git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1`
+
+
+How does the merge work?
+------------------------
+
+We said this tutorial shows what plumbing does to help you cope
+with the porcelain that isn't flushing, but we so far did not
+talk about how the merge really works. If you are following
+this tutorial the first time, I'd suggest to skip to "Publishing
+your work" section and come back here later.
+
+OK, still with me? To give us an example to look at, let's go
+back to the earlier repository with "hello" and "example" file,
+and bring ourselves back to the pre-merge state:
+
+------------
+$ git show-branch --more=2 master mybranch
+! [master] Merge work in mybranch
+ * [mybranch] Merge work in mybranch
+--
+-- [master] Merge work in mybranch
++* [master^2] Some work.
++* [master^] Some fun.
+------------
+
+Remember, before running `git merge`, our `master` head was at
+"Some fun." commit, while our `mybranch` head was at "Some
+work." commit.
+
+------------
+$ git checkout mybranch
+$ git reset --hard master^2
+$ git checkout master
+$ git reset --hard master^
+------------
+
+After rewinding, the commit structure should look like this:
+
+------------
+$ git show-branch
+* [master] Some fun.
+ ! [mybranch] Some work.
+--
+ + [mybranch] Some work.
+* [master] Some fun.
+*+ [mybranch^] New day.
+------------
+
+Now we are ready to experiment with the merge by hand.
+
+`git merge` command, when merging two branches, uses 3-way merge
+algorithm. First, it finds the common ancestor between them.
+The command it uses is `git-merge-base`:
+
+------------
+$ mb=$(git-merge-base HEAD mybranch)
+------------
+
+The command writes the commit object name of the common ancestor
+to the standard output, so we captured its output to a variable,
+because we will be using it in the next step. By the way, the common
+ancestor commit is the "New day." commit in this case. You can
+tell it by:
+
+------------
+$ git-name-rev $mb
+my-first-tag
+------------
+
+After finding out a common ancestor commit, the second step is
+this:
+
+------------
+$ git-read-tree -m -u $mb HEAD mybranch
+------------
+
+This is the same `git-read-tree` command we have already seen,
+but it takes three trees, unlike previous examples. This reads
+the contents of each tree into different 'stage' in the index
+file (the first tree goes to stage 1, the second to stage 2,
+etc.). After reading three trees into three stages, the paths
+that are the same in all three stages are 'collapsed' into stage
+0. Also paths that are the same in two of three stages are
+collapsed into stage 0, taking the SHA1 from either stage 2 or
+stage 3, whichever is different from stage 1 (i.e. only one side
+changed from the common ancestor).
+
+After 'collapsing' operation, paths that are different in three
+trees are left in non-zero stages. At this point, you can
+inspect the index file with this command:
+
+------------
+$ git-ls-files --stage
+100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example
+100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello
+100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
+100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
+------------
+
+In our example of only two files, we did not have unchanged
+files so only 'example' resulted in collapsing, but in real-life
+large projects, only small number of files change in one commit,
+and this 'collapsing' tends to trivially merge most of the paths
+fairly quickly, leaving only a handful the real changes in non-zero
+stages.
+
+To look at only non-zero stages, use `\--unmerged` flag:
+
+------------
+$ git-ls-files --unmerged
+100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello
+100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
+100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
+------------
+
+The next step of merging is to merge these three versions of the
+file, using 3-way merge. This is done by giving
+`git-merge-one-file` command as one of the arguments to
+`git-merge-index` command:
+
+------------
+$ git-merge-index git-merge-one-file hello
+Auto-merging hello.
+merge: warning: conflicts during merge
+ERROR: Merge conflict in hello.
+fatal: merge program failed
+------------
+
+`git-merge-one-file` script is called with parameters to
+describe those three versions, and is responsible to leave the
+merge results in the working tree.
+It is a fairly straightforward shell script, and
+eventually calls `merge` program from RCS suite to perform a
+file-level 3-way merge. In this case, `merge` detects
+conflicts, and the merge result with conflict marks is left in
+the working tree.. This can be seen if you run `ls-files
+--stage` again at this point:
+
+------------
+$ git-ls-files --stage
+100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example
+100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello
+100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
+100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
+------------
+
+This is the state of the index file and the working file after
+`git merge` returns control back to you, leaving the conflicting
+merge for you to resolve. Notice that the path `hello` is still
+unmerged, and what you see with `git diff` at this point is
+differences since stage 2 (i.e. your version).
+
+
+Publishing your work
+--------------------
+
+So, we can use somebody else's work from a remote repository, but
+how can *you* prepare a repository to let other people pull from
+it?
+
+You do your real work in your working tree that has your
+primary repository hanging under it as its `.git` subdirectory.
+You *could* make that repository accessible remotely and ask
+people to pull from it, but in practice that is not the way
+things are usually done. A recommended way is to have a public
+repository, make it reachable by other people, and when the
+changes you made in your primary working tree are in good shape,
+update the public repository from it. This is often called
+'pushing'.
+
+[NOTE]
+This public repository could further be mirrored, and that is
+how git repositories at `kernel.org` are managed.
+
+Publishing the changes from your local (private) repository to
+your remote (public) repository requires a write privilege on
+the remote machine. You need to have an SSH account there to
+run a single command, `git-receive-pack`.
+
+First, you need to create an empty repository on the remote
+machine that will house your public repository. This empty
+repository will be populated and be kept up-to-date by pushing
+into it later. Obviously, this repository creation needs to be
+done only once.
+
+[NOTE]
+`git push` uses a pair of programs,
+`git-send-pack` on your local machine, and `git-receive-pack`
+on the remote machine. The communication between the two over
+the network internally uses an SSH connection.
+
+Your private repository's git directory is usually `.git`, but
+your public repository is often named after the project name,
+i.e. `<project>.git`. Let's create such a public repository for
+project `my-git`. After logging into the remote machine, create
+an empty directory:
+
+------------
+$ mkdir my-git.git
+------------
+
+Then, make that directory into a git repository by running
+`git init`, but this time, since its name is not the usual
+`.git`, we do things slightly differently:
+
+------------
+$ GIT_DIR=my-git.git git-init
+------------
+
+Make sure this directory is available for others you want your
+changes to be pulled by via the transport of your choice. Also
+you need to make sure that you have the `git-receive-pack`
+program on the `$PATH`.
+
+[NOTE]
+Many installations of sshd do not invoke your shell as the login
+shell when you directly run programs; what this means is that if
+your login shell is `bash`, only `.bashrc` is read and not
+`.bash_profile`. As a workaround, make sure `.bashrc` sets up
+`$PATH` so that you can run `git-receive-pack` program.
+
+[NOTE]
+If you plan to publish this repository to be accessed over http,
+you should do `chmod +x my-git.git/hooks/post-update` at this
+point. This makes sure that every time you push into this
+repository, `git-update-server-info` is run.
+
+Your "public repository" is now ready to accept your changes.
+Come back to the machine you have your private repository. From
+there, run this command:
+
+------------
+$ git push <public-host>:/path/to/my-git.git master
+------------
+
+This synchronizes your public repository to match the named
+branch head (i.e. `master` in this case) and objects reachable
+from them in your current repository.
+
+As a real example, this is how I update my public git
+repository. Kernel.org mirror network takes care of the
+propagation to other publicly visible machines:
+
+------------
+$ git push master.kernel.org:/pub/scm/git/git.git/
+------------
+
+
+Packing your repository
+-----------------------
+
+Earlier, we saw that one file under `.git/objects/??/` directory
+is stored for each git object you create. This representation
+is efficient to create atomically and safely, but
+not so convenient to transport over the network. Since git objects are
+immutable once they are created, there is a way to optimize the
+storage by "packing them together". The command
+
+------------
+$ git repack
+------------
+
+will do it for you. If you followed the tutorial examples, you
+would have accumulated about 17 objects in `.git/objects/??/`
+directories by now. `git repack` tells you how many objects it
+packed, and stores the packed file in `.git/objects/pack`
+directory.
+
+[NOTE]
+You will see two files, `pack-\*.pack` and `pack-\*.idx`,
+in `.git/objects/pack` directory. They are closely related to
+each other, and if you ever copy them by hand to a different
+repository for whatever reason, you should make sure you copy
+them together. The former holds all the data from the objects
+in the pack, and the latter holds the index for random
+access.
+
+If you are paranoid, running `git-verify-pack` command would
+detect if you have a corrupt pack, but do not worry too much.
+Our programs are always perfect ;-).
+
+Once you have packed objects, you do not need to leave the
+unpacked objects that are contained in the pack file anymore.
+
+------------
+$ git prune-packed
+------------
+
+would remove them for you.
+
+You can try running `find .git/objects -type f` before and after
+you run `git prune-packed` if you are curious. Also `git
+count-objects` would tell you how many unpacked objects are in
+your repository and how much space they are consuming.
+
+[NOTE]
+`git pull` is slightly cumbersome for HTTP transport, as a
+packed repository may contain relatively few objects in a
+relatively large pack. If you expect many HTTP pulls from your
+public repository you might want to repack & prune often, or
+never.
+
+If you run `git repack` again at this point, it will say
+"Nothing to pack". Once you continue your development and
+accumulate the changes, running `git repack` again will create a
+new pack, that contains objects created since you packed your
+repository the last time. We recommend that you pack your project
+soon after the initial import (unless you are starting your
+project from scratch), and then run `git repack` every once in a
+while, depending on how active your project is.
+
+When a repository is synchronized via `git push` and `git pull`
+objects packed in the source repository are usually stored
+unpacked in the destination, unless rsync transport is used.
+While this allows you to use different packing strategies on
+both ends, it also means you may need to repack both
+repositories every once in a while.
+
+
+Working with Others
+-------------------
+
+Although git is a truly distributed system, it is often
+convenient to organize your project with an informal hierarchy
+of developers. Linux kernel development is run this way. There
+is a nice illustration (page 17, "Merges to Mainline") in
+link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation].
+
+It should be stressed that this hierarchy is purely *informal*.
+There is nothing fundamental in git that enforces the "chain of
+patch flow" this hierarchy implies. You do not have to pull
+from only one remote repository.
+
+A recommended workflow for a "project lead" goes like this:
+
+1. Prepare your primary repository on your local machine. Your
+ work is done there.
+
+2. Prepare a public repository accessible to others.
++
+If other people are pulling from your repository over dumb
+transport protocols (HTTP), you need to keep this repository
+'dumb transport friendly'. After `git init`,
+`$GIT_DIR/hooks/post-update` copied from the standard templates
+would contain a call to `git-update-server-info` but the
+`post-update` hook itself is disabled by default -- enable it
+with `chmod +x post-update`. This makes sure `git-update-server-info`
+keeps the necessary files up-to-date.
+
+3. Push into the public repository from your primary
+ repository.
+
+4. `git repack` the public repository. This establishes a big
+ pack that contains the initial set of objects as the
+ baseline, and possibly `git prune` if the transport
+ used for pulling from your repository supports packed
+ repositories.
+
+5. Keep working in your primary repository. Your changes
+ include modifications of your own, patches you receive via
+ e-mails, and merges resulting from pulling the "public"
+ repositories of your "subsystem maintainers".
++
+You can repack this private repository whenever you feel like.
+
+6. Push your changes to the public repository, and announce it
+ to the public.
+
+7. Every once in a while, "git repack" the public repository.
+ Go back to step 5. and continue working.
+
+
+A recommended work cycle for a "subsystem maintainer" who works
+on that project and has an own "public repository" goes like this:
+
+1. Prepare your work repository, by `git clone` the public
+ repository of the "project lead". The URL used for the
+ initial cloning is stored in the remote.origin.url
+ configuration variable.
+
+2. Prepare a public repository accessible to others, just like
+ the "project lead" person does.
+
+3. Copy over the packed files from "project lead" public
+ repository to your public repository, unless the "project
+ lead" repository lives on the same machine as yours. In the
+ latter case, you can use `objects/info/alternates` file to
+ point at the repository you are borrowing from.
+
+4. Push into the public repository from your primary
+ repository. Run `git repack`, and possibly `git prune` if the
+ transport used for pulling from your repository supports
+ packed repositories.
+
+5. Keep working in your primary repository. Your changes
+ include modifications of your own, patches you receive via
+ e-mails, and merges resulting from pulling the "public"
+ repositories of your "project lead" and possibly your
+ "sub-subsystem maintainers".
++
+You can repack this private repository whenever you feel
+like.
+
+6. Push your changes to your public repository, and ask your
+ "project lead" and possibly your "sub-subsystem
+ maintainers" to pull from it.
+
+7. Every once in a while, `git repack` the public repository.
+ Go back to step 5. and continue working.
+
+
+A recommended work cycle for an "individual developer" who does
+not have a "public" repository is somewhat different. It goes
+like this:
+
+1. Prepare your work repository, by `git clone` the public
+ repository of the "project lead" (or a "subsystem
+ maintainer", if you work on a subsystem). The URL used for
+ the initial cloning is stored in the remote.origin.url
+ configuration variable.
+
+2. Do your work in your repository on 'master' branch.
+
+3. Run `git fetch origin` from the public repository of your
+ upstream every once in a while. This does only the first
+ half of `git pull` but does not merge. The head of the
+ public repository is stored in `.git/refs/remotes/origin/master`.
+
+4. Use `git cherry origin` to see which ones of your patches
+ were accepted, and/or use `git rebase origin` to port your
+ unmerged changes forward to the updated upstream.
+
+5. Use `git format-patch origin` to prepare patches for e-mail
+ submission to your upstream and send it out. Go back to
+ step 2. and continue.
+
+
+Working with Others, Shared Repository Style
+--------------------------------------------
+
+If you are coming from CVS background, the style of cooperation
+suggested in the previous section may be new to you. You do not
+have to worry. git supports "shared public repository" style of
+cooperation you are probably more familiar with as well.
+
+See linkgit:gitcvs-migration[7][git for CVS users] for the details.
+
+Bundling your work together
+---------------------------
+
+It is likely that you will be working on more than one thing at
+a time. It is easy to manage those more-or-less independent tasks
+using branches with git.
+
+We have already seen how branches work previously,
+with "fun and work" example using two branches. The idea is the
+same if there are more than two branches. Let's say you started
+out from "master" head, and have some new code in the "master"
+branch, and two independent fixes in the "commit-fix" and
+"diff-fix" branches:
+
+------------
+$ git show-branch
+! [commit-fix] Fix commit message normalization.
+ ! [diff-fix] Fix rename detection.
+ * [master] Release candidate #1
+---
+ + [diff-fix] Fix rename detection.
+ + [diff-fix~1] Better common substring algorithm.
++ [commit-fix] Fix commit message normalization.
+ * [master] Release candidate #1
+++* [diff-fix~2] Pretty-print messages.
+------------
+
+Both fixes are tested well, and at this point, you want to merge
+in both of them. You could merge in 'diff-fix' first and then
+'commit-fix' next, like this:
+
+------------
+$ git merge -m "Merge fix in diff-fix" diff-fix
+$ git merge -m "Merge fix in commit-fix" commit-fix
+------------
+
+Which would result in:
+
+------------
+$ git show-branch
+! [commit-fix] Fix commit message normalization.
+ ! [diff-fix] Fix rename detection.
+ * [master] Merge fix in commit-fix
+---
+ - [master] Merge fix in commit-fix
++ * [commit-fix] Fix commit message normalization.
+ - [master~1] Merge fix in diff-fix
+ +* [diff-fix] Fix rename detection.
+ +* [diff-fix~1] Better common substring algorithm.
+ * [master~2] Release candidate #1
+++* [master~3] Pretty-print messages.
+------------
+
+However, there is no particular reason to merge in one branch
+first and the other next, when what you have are a set of truly
+independent changes (if the order mattered, then they are not
+independent by definition). You could instead merge those two
+branches into the current branch at once. First let's undo what
+we just did and start over. We would want to get the master
+branch before these two merges by resetting it to 'master~2':
+
+------------
+$ git reset --hard master~2
+------------
+
+You can make sure 'git show-branch' matches the state before
+those two 'git merge' you just did. Then, instead of running
+two 'git merge' commands in a row, you would merge these two
+branch heads (this is known as 'making an Octopus'):
+
+------------
+$ git merge commit-fix diff-fix
+$ git show-branch
+! [commit-fix] Fix commit message normalization.
+ ! [diff-fix] Fix rename detection.
+ * [master] Octopus merge of branches 'diff-fix' and 'commit-fix'
+---
+ - [master] Octopus merge of branches 'diff-fix' and 'commit-fix'
++ * [commit-fix] Fix commit message normalization.
+ +* [diff-fix] Fix rename detection.
+ +* [diff-fix~1] Better common substring algorithm.
+ * [master~1] Release candidate #1
+++* [master~2] Pretty-print messages.
+------------
+
+Note that you should not do Octopus because you can. An octopus
+is a valid thing to do and often makes it easier to view the
+commit history if you are merging more than two independent
+changes at the same time. However, if you have merge conflicts
+with any of the branches you are merging in and need to hand
+resolve, that is an indication that the development happened in
+those branches were not independent after all, and you should
+merge two at a time, documenting how you resolved the conflicts,
+and the reason why you preferred changes made in one side over
+the other. Otherwise it would make the project history harder
+to follow, not easier.
+
+SEE ALSO
+--------
+linkgit:gittutorial[7], linkgit:gittutorial-2[7],
+linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[1] suite.
diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt
new file mode 100644
index 0000000000..1db3f52945
--- /dev/null
+++ b/Documentation/gitcvs-migration.txt
@@ -0,0 +1,196 @@
+gitcvs-migration(7)
+===================
+
+NAME
+----
+gitcvs-migration - git for CVS users
+
+SYNOPSIS
+--------
+git cvsimport *
+
+DESCRIPTION
+-----------
+
+Git differs from CVS in that 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;
+this document explains how to do that.
+
+Some basic familiarity with git is required. This
+linkgit:gittutorial[7][tutorial introduction to git] and the
+linkgit:gitglossary[7][git glossary] should be sufficient.
+
+Developing against a shared repository
+--------------------------------------
+
+Suppose a shared repository is set up in /pub/repo.git on the host
+foo.com. Then as an individual committer you can clone the shared
+repository over ssh with:
+
+------------------------------------------------
+$ git clone foo.com:/pub/repo.git/ my-project
+$ cd my-project
+------------------------------------------------
+
+and hack away. The equivalent of `cvs update` is
+
+------------------------------------------------
+$ git pull origin
+------------------------------------------------
+
+which merges in any work that others might have done since the clone
+operation. If there are uncommitted changes in your working tree, commit
+them first before running git pull.
+
+[NOTE]
+================================
+The `pull` command knows where to get updates from because of certain
+configuration variables that were set by the first `git clone`
+command; see `git config -l` and the linkgit:git-config[1] man
+page for details.
+================================
+
+You can update the shared repository with your changes by first committing
+your changes, and then using the linkgit:git-push[1] command:
+
+------------------------------------------------
+$ git push origin master
+------------------------------------------------
+
+to "push" those commits to the shared repository. 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 foo.com:/pub/project.git/
+------------
+
+as long as the shared repository does not have any branches
+other than `master`.
+
+Setting Up a Shared Repository
+------------------------------
+
+We assume you have already created a git repository for your project,
+possibly created from scratch or from a tarball (see the
+linkgit:gittutorial[7][tutorial]), or imported from an already existing CVS
+repository (see the next section).
+
+Assume your existing repo is at /home/alice/myproject. Create a new "bare"
+repository (a repository without a working tree) and fetch your project into
+it:
+
+------------------------------------------------
+$ mkdir /pub/my-repo.git
+$ cd /pub/my-repo.git
+$ git --bare init --shared
+$ git --bare fetch /home/alice/myproject master:master
+------------------------------------------------
+
+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 linkgit:git-shell[1].
+
+Put all the committers in the same group, and make the repository
+writable by that group:
+
+------------------------------------------------
+$ chgrp -R $group /pub/my-repo.git
+------------------------------------------------
+
+Make sure committers have a umask of at most 027, so that the directories
+they create are writable and searchable by other group members.
+
+Importing a CVS archive
+-----------------------
+
+First, install version 2.1 or higher of cvsps from
+link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make
+sure it is in your path. Then cd to a checked out CVS working directory
+of the project you are interested in and run linkgit:git-cvsimport[1]:
+
+-------------------------------------------
+$ git cvsimport -C <destination> <module>
+-------------------------------------------
+
+This puts a git archive of the named CVS module in the directory
+<destination>, which will be created if necessary.
+
+The import checks out from CVS every revision of every file. Reportedly
+cvsimport can average some twenty revisions per second, so for a
+medium-sized project this should not take more than a couple of minutes.
+Larger projects or remote repositories may take longer.
+
+The main trunk is stored in the git branch named `origin`, and additional
+CVS branches are stored in git branches with the same names. The most
+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.
+
+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.
+
+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 linkgit:githooks[5][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].
+
+Providing CVS Access to a git Repository
+----------------------------------------
+
+It is also possible to provide true CVS access to a git repository, so
+that developers can still use CVS; see linkgit:git-cvsserver[1] for
+details.
+
+Alternative Development Models
+------------------------------
+
+CVS users are accustomed to giving a group of developers commit access to
+a common repository. As we've seen, this is also possible with git.
+However, the distributed nature of git allows other development models,
+and you may want to first consider whether one of them might be a better
+fit for your project.
+
+For example, you can choose a single person to maintain the project's
+primary public repository. Other developers then clone this repository
+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.
+
+With a small group, developers may just pull changes from each other's
+repositories without the need for a central maintainer.
+
+SEE ALSO
+--------
+linkgit:gittutorial[7],
+linkgit:gittutorial-2[7],
+linkgit:gitcore-tutorial[7],
+linkgit:gitglossary[7],
+link:everyday.html[Everyday Git],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[1] suite.
diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt
new file mode 100644
index 0000000000..4d56c85260
--- /dev/null
+++ b/Documentation/gitdiffcore.txt
@@ -0,0 +1,292 @@
+gitdiffcore(7)
+==============
+
+NAME
+----
+gitdiffcore - Tweaking diff output (June 2005)
+
+SYNOPSIS
+--------
+git diff *
+
+DESCRIPTION
+-----------
+
+The diff commands git-diff-index, git-diff-files, and git-diff-tree
+can be told to manipulate differences they find in
+unconventional ways before showing diff(1) output. The manipulation
+is collectively called "diffcore transformation". This short note
+describes what they are and how to use them to produce diff outputs
+that are easier to understand than the conventional kind.
+
+
+The chain of operation
+----------------------
+
+The git-diff-* family works by first comparing two sets of
+files:
+
+ - git-diff-index compares contents of a "tree" object and the
+ working directory (when '\--cached' flag is not used) or a
+ "tree" object and the index file (when '\--cached' flag is
+ used);
+
+ - git-diff-files compares contents of the index file and the
+ working directory;
+
+ - git-diff-tree compares contents of two "tree" objects;
+
+In all of these cases, the commands themselves compare
+corresponding paths in the two sets of files. The result of
+comparison is passed from these commands to what is internally
+called "diffcore", in a format similar to what is output when
+the -p option is not used. E.g.
+
+------------------------------------------------
+in-place edit :100644 100644 bcd1234... 0123456... M file0
+create :000000 100644 0000000... 1234567... A file4
+delete :100644 000000 1234567... 0000000... D file5
+unmerged :000000 000000 0000000... 0000000... U file6
+------------------------------------------------
+
+The diffcore mechanism is fed a list of such comparison results
+(each of which is called "filepair", although at this point each
+of them talks about a single file), and transforms such a list
+into another list. There are currently 6 such transformations:
+
+- diffcore-pathspec
+- diffcore-break
+- diffcore-rename
+- diffcore-merge-broken
+- diffcore-pickaxe
+- diffcore-order
+
+These are applied in sequence. The set of filepairs git-diff-\*
+commands find are used as the input to diffcore-pathspec, and
+the output from diffcore-pathspec is used as the input to the
+next transformation. The final result is then passed to the
+output routine and generates either diff-raw format (see Output
+format sections of the manual for git-diff-\* commands) or
+diff-patch format.
+
+
+diffcore-pathspec: For Ignoring Files Outside Our Consideration
+---------------------------------------------------------------
+
+The first transformation in the chain is diffcore-pathspec, and
+is controlled by giving the pathname parameters to the
+git-diff-* commands on the command line. The pathspec is used
+to limit the world diff operates in. It removes the filepairs
+outside the specified set of pathnames. E.g. If the input set
+of filepairs included:
+
+------------------------------------------------
+:100644 100644 bcd1234... 0123456... M junkfile
+------------------------------------------------
+
+but the command invocation was "git-diff-files myfile", then the
+junkfile entry would be removed from the list because only "myfile"
+is under consideration.
+
+Implementation note. For performance reasons, git-diff-tree
+uses the pathname parameters on the command line to cull set of
+filepairs it feeds the diffcore mechanism itself, and does not
+use diffcore-pathspec, but the end result is the same.
+
+
+diffcore-break: For Splitting Up "Complete Rewrites"
+----------------------------------------------------
+
+The second transformation in the chain is diffcore-break, and is
+controlled by the -B option to the git-diff-* commands. This is
+used to detect a filepair that represents "complete rewrite" and
+break such filepair into two filepairs that represent delete and
+create. E.g. If the input contained this filepair:
+
+------------------------------------------------
+:100644 100644 bcd1234... 0123456... M file0
+------------------------------------------------
+
+and if it detects that the file "file0" is completely rewritten,
+it changes it to:
+
+------------------------------------------------
+:100644 000000 bcd1234... 0000000... D file0
+:000000 100644 0000000... 0123456... A file0
+------------------------------------------------
+
+For the purpose of breaking a filepair, diffcore-break examines
+the extent of changes between the contents of the files before
+and after modification (i.e. the contents that have "bcd1234..."
+and "0123456..." as their SHA1 content ID, in the above
+example). The amount of deletion of original contents and
+insertion of new material are added together, and if it exceeds
+the "break score", the filepair is broken into two. The break
+score defaults to 50% of the size of the smaller of the original
+and the result (i.e. if the edit shrinks the file, the size of
+the result is used; if the edit lengthens the file, the size of
+the original is used), and can be customized by giving a number
+after "-B" option (e.g. "-B75" to tell it to use 75%).
+
+
+diffcore-rename: For Detection Renames and Copies
+-------------------------------------------------
+
+This transformation is used to detect renames and copies, and is
+controlled by the -M option (to detect renames) and the -C option
+(to detect copies as well) to the git-diff-* commands. If the
+input contained these filepairs:
+
+------------------------------------------------
+:100644 000000 0123456... 0000000... D fileX
+:000000 100644 0000000... 0123456... A file0
+------------------------------------------------
+
+and the contents of the deleted file fileX is similar enough to
+the contents of the created file file0, then rename detection
+merges these filepairs and creates:
+
+------------------------------------------------
+:100644 100644 0123456... 0123456... R100 fileX file0
+------------------------------------------------
+
+When the "-C" option is used, the original contents of modified files,
+and deleted files (and also unmodified files, if the
+"\--find-copies-harder" option is used) are considered as candidates
+of the source files in rename/copy operation. If the input were like
+these filepairs, that talk about a modified file fileY and a newly
+created file file0:
+
+------------------------------------------------
+:100644 100644 0123456... 1234567... M fileY
+:000000 100644 0000000... bcd3456... A file0
+------------------------------------------------
+
+the original contents of fileY and the resulting contents of
+file0 are compared, and if they are similar enough, they are
+changed to:
+
+------------------------------------------------
+:100644 100644 0123456... 1234567... M fileY
+:100644 100644 0123456... bcd3456... C100 fileY file0
+------------------------------------------------
+
+In both rename and copy detection, the same "extent of changes"
+algorithm used in diffcore-break is used to determine if two
+files are "similar enough", and can be customized to use
+a similarity score different from the default of 50% by giving a
+number after the "-M" or "-C" option (e.g. "-M8" to tell it to use
+8/10 = 80%).
+
+Note. When the "-C" option is used with `\--find-copies-harder`
+option, git-diff-\* commands feed unmodified filepairs to
+diffcore mechanism as well as modified ones. This lets the copy
+detector consider unmodified files as copy source candidates at
+the expense of making it slower. Without `\--find-copies-harder`,
+git-diff-\* commands can detect copies only if the file that was
+copied happened to have been modified in the same changeset.
+
+
+diffcore-merge-broken: For Putting "Complete Rewrites" Back Together
+--------------------------------------------------------------------
+
+This transformation is used to merge filepairs broken by
+diffcore-break, and not transformed into rename/copy by
+diffcore-rename, back into a single modification. This always
+runs when diffcore-break is used.
+
+For the purpose of merging broken filepairs back, it uses a
+different "extent of changes" computation from the ones used by
+diffcore-break and diffcore-rename. It counts only the deletion
+from the original, and does not count insertion. If you removed
+only 10 lines from a 100-line document, even if you added 910
+new lines to make a new 1000-line document, you did not do a
+complete rewrite. diffcore-break breaks such a case in order to
+help diffcore-rename to consider such filepairs as candidate of
+rename/copy detection, but if filepairs broken that way were not
+matched with other filepairs to create rename/copy, then this
+transformation merges them back into the original
+"modification".
+
+The "extent of changes" parameter can be tweaked from the
+default 80% (that is, unless more than 80% of the original
+material is deleted, the broken pairs are merged back into a
+single modification) by giving a second number to -B option,
+like these:
+
+* -B50/60 (give 50% "break score" to diffcore-break, use 60%
+ for diffcore-merge-broken).
+
+* -B/60 (the same as above, since diffcore-break defaults to 50%).
+
+Note that earlier implementation left a broken pair as a separate
+creation and deletion patches. This was an unnecessary hack and
+the latest implementation always merges all the broken pairs
+back into modifications, but the resulting patch output is
+formatted differently for easier review in case of such
+a complete rewrite by showing the entire contents of old version
+prefixed with '-', followed by the entire contents of new
+version prefixed with '+'.
+
+
+diffcore-pickaxe: For Detecting Addition/Deletion of Specified String
+---------------------------------------------------------------------
+
+This transformation is used to find filepairs that represent
+changes that touch a specified string, and is controlled by the
+-S option and the `\--pickaxe-all` option to the git-diff-*
+commands.
+
+When diffcore-pickaxe is in use, it checks if there are
+filepairs whose "original" side has the specified string and
+whose "result" side does not. Such a filepair represents "the
+string appeared in this changeset". It also checks for the
+opposite case that loses the specified string.
+
+When `\--pickaxe-all` is not in effect, diffcore-pickaxe leaves
+only such filepairs that touch the specified string in its
+output. When `\--pickaxe-all` is used, diffcore-pickaxe leaves all
+filepairs intact if there is such a filepair, or makes the
+output empty otherwise. The latter behaviour is designed to
+make reviewing of the changes in the context of the whole
+changeset easier.
+
+
+diffcore-order: For Sorting the Output Based on Filenames
+---------------------------------------------------------
+
+This is used to reorder the filepairs according to the user's
+(or project's) taste, and is controlled by the -O option to the
+git-diff-* commands.
+
+This takes a text file each of whose lines is a shell glob
+pattern. Filepairs that match a glob pattern on an earlier line
+in the file are output before ones that match a later line, and
+filepairs that do not match any glob pattern are output last.
+
+As an example, a typical orderfile for the core git probably
+would look like this:
+
+------------------------------------------------
+README
+Makefile
+Documentation
+*.h
+*.c
+t
+------------------------------------------------
+
+SEE ALSO
+--------
+linkgit:git-diff[1],
+linkgit:git-diff-files[1],
+linkgit:git-diff-index[1],
+linkgit:git-diff-tree[1],
+linkgit:git-format-patch[1],
+linkgit:git-log[1],
+linkgit:gitglossary[7],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[1] suite.
diff --git a/Documentation/gitglossary.txt b/Documentation/gitglossary.txt
new file mode 100644
index 0000000000..5c5c31d31c
--- /dev/null
+++ b/Documentation/gitglossary.txt
@@ -0,0 +1,25 @@
+gitglossary(7)
+==============
+
+NAME
+----
+gitglossary - A GIT Glossary
+
+SYNOPSIS
+--------
+*
+
+DESCRIPTION
+-----------
+
+include::glossary-content.txt[]
+
+SEE ALSO
+--------
+linkgit:gittutorial[7], linkgit:gittutorial-2[7],
+linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[1] suite.
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
new file mode 100644
index 0000000000..4f06ae0ed4
--- /dev/null
+++ b/Documentation/githooks.txt
@@ -0,0 +1,303 @@
+githooks(5)
+===========
+
+NAME
+----
+githooks - Hooks used by git
+
+SYNOPSIS
+--------
+$GIT_DIR/hooks/*
+
+
+DESCRIPTION
+-----------
+
+Hooks are little scripts you can place in `$GIT_DIR/hooks`
+directory to trigger action at certain points. When
+`git-init` is run, a handful example hooks are copied in the
+`hooks` directory of the new repository, but by default they are
+all disabled. To enable a hook, make it executable with `chmod +x`.
+
+This document describes the currently defined hooks.
+
+applypatch-msg
+--------------
+
+This hook is invoked by `git-am` script. It takes a single
+parameter, the name of the file that holds the proposed commit
+log message. Exiting with non-zero status causes
+`git-am` to abort before applying the patch.
+
+The hook is allowed to edit the message file in place, and can
+be used to normalize the message into some project standard
+format (if the project has one). It can also be used to refuse
+the commit after inspecting the message file.
+
+The default 'applypatch-msg' hook, when enabled, runs the
+'commit-msg' hook, if the latter is enabled.
+
+pre-applypatch
+--------------
+
+This hook is invoked by `git-am`. It takes no parameter, and is
+invoked after the patch is applied, but before a commit is made.
+
+If it exits with non-zero status, then the working tree will not be
+committed after applying the patch.
+
+It can be used to inspect the current working tree and refuse to
+make a commit if it does not pass certain test.
+
+The default 'pre-applypatch' hook, when enabled, runs the
+'pre-commit' hook, if the latter is enabled.
+
+post-applypatch
+---------------
+
+This hook is invoked by `git-am`. It takes no parameter,
+and is invoked after the patch is applied and a commit is made.
+
+This hook is meant primarily for notification, and cannot affect
+the outcome of `git-am`.
+
+pre-commit
+----------
+
+This hook is invoked by `git-commit`, and can be bypassed
+with `\--no-verify` option. It takes no parameter, and is
+invoked before obtaining the proposed commit log message and
+making a commit. Exiting with non-zero status from this script
+causes the `git-commit` to abort.
+
+The default 'pre-commit' hook, when enabled, catches introduction
+of lines with trailing whitespaces and aborts the commit when
+such a line is found.
+
+All the `git-commit` hooks are invoked with the environment
+variable `GIT_EDITOR=:` if the command will not bring up an editor
+to modify the commit message.
+
+prepare-commit-msg
+------------------
+
+This hook is invoked by `git-commit` right after preparing the
+default log message, and before the editor is started.
+
+It takes one to three parameters. The first is the name of the file
+that the commit log message. The second is the source of the commit
+message, and can be: `message` (if a `\-m` or `\-F` option was
+given); `template` (if a `\-t` option was given or the
+configuration option `commit.template` is set); `merge` (if the
+commit is a merge or a `.git/MERGE_MSG` file exists); `squash`
+(if a `.git/SQUASH_MSG` file exists); or `commit`, followed by
+a commit SHA1 (if a `\-c`, `\-C` or `\--amend` option was given).
+
+If the exit status is non-zero, `git-commit` will abort.
+
+The purpose of the hook is to edit the message file in place, and
+it is not suppressed by the `\--no-verify` option. A non-zero exit
+means a failure of the hook and aborts the commit. It should not
+be used as replacement for pre-commit hook.
+
+The sample `prepare-commit-msg` hook that comes with git comments
+out the `Conflicts:` part of a merge's commit message.
+
+commit-msg
+----------
+
+This hook is invoked by `git-commit`, and can be bypassed
+with `\--no-verify` option. It takes a single parameter, the
+name of the file that holds the proposed commit log message.
+Exiting with non-zero status causes the `git-commit` to
+abort.
+
+The hook is allowed to edit the message file in place, and can
+be used to normalize the message into some project standard
+format (if the project has one). It can also be used to refuse
+the commit after inspecting the message file.
+
+The default 'commit-msg' hook, when enabled, detects duplicate
+"Signed-off-by" lines, and aborts the commit if one is found.
+
+post-commit
+-----------
+
+This hook is invoked by `git-commit`. It takes no
+parameter, and is invoked after a commit is made.
+
+This hook is meant primarily for notification, and cannot affect
+the outcome of `git-commit`.
+
+post-checkout
+-----------
+
+This hook is invoked when a `git-checkout` is run after having updated the
+worktree. The hook is given three parameters: the ref of the previous HEAD,
+the ref of the new HEAD (which may or may not have changed), and a flag
+indicating whether the checkout was a branch checkout (changing branches,
+flag=1) or a file checkout (retrieving a file from the index, flag=0).
+This hook cannot affect the outcome of `git-checkout`.
+
+This hook can be used to perform repository validity checks, auto-display
+differences from the previous HEAD if different, or set working dir metadata
+properties.
+
+post-merge
+-----------
+
+This hook is invoked by `git-merge`, which happens when a `git pull`
+is done on a local repository. The hook takes a single parameter, a status
+flag specifying whether or not the merge being done was a squash merge.
+This hook cannot affect the outcome of `git-merge` and is not executed,
+if the merge failed due to conflicts.
+
+This hook can be used in conjunction with a corresponding pre-commit hook to
+save and restore any form of metadata associated with the working tree
+(eg: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl
+for an example of how to do this.
+
+[[pre-receive]]
+pre-receive
+-----------
+
+This hook is invoked by `git-receive-pack` on the remote repository,
+which happens when a `git push` is done on a local repository.
+Just before starting to update refs on the remote repository, the
+pre-receive hook is invoked. Its exit status determines the success
+or failure of the update.
+
+This hook executes once for the receive operation. It takes no
+arguments, but for each ref to be updated it receives on standard
+input a line of the format:
+
+ <old-value> SP <new-value> SP <ref-name> LF
+
+where `<old-value>` is the old object name stored in the ref,
+`<new-value>` is the new object name to be stored in the ref and
+`<ref-name>` is the full name of the ref.
+When creating a new ref, `<old-value>` is 40 `0`.
+
+If the hook exits with non-zero status, none of the refs will be
+updated. If the hook exits with zero, updating of individual refs can
+still be prevented by the <<update,'update'>> hook.
+
+Both standard output and standard error output are forwarded to
+`git-send-pack` on the other end, so you can simply `echo` messages
+for the user.
+
+[[update]]
+update
+------
+
+This hook is invoked by `git-receive-pack` on the remote repository,
+which happens when a `git push` is done on a local repository.
+Just before updating the ref on the remote repository, the update hook
+is invoked. Its exit status determines the success or failure of
+the ref update.
+
+The hook executes once for each ref to be updated, and takes
+three parameters:
+
+ - the name of the ref being updated,
+ - the old object name stored in the ref,
+ - and the new objectname to be stored in the ref.
+
+A zero exit from the update hook allows the ref to be updated.
+Exiting with a non-zero status prevents `git-receive-pack`
+from updating that ref.
+
+This hook can be used to prevent 'forced' update on certain refs by
+making sure that the object name is a commit object that is a
+descendant of the commit object named by the old object name.
+That is, to enforce a "fast forward only" policy.
+
+It could also be used to log the old..new status. However, it
+does not know the entire set of branches, so it would end up
+firing one e-mail per ref when used naively, though. The
+<<post-receive,'post-receive'>> hook is more suited to that.
+
+Another use suggested on the mailing list is to use this hook to
+implement access control which is finer grained than the one
+based on filesystem group.
+
+Both standard output and standard error output are forwarded to
+`git-send-pack` on the other end, so you can simply `echo` messages
+for the user.
+
+The default 'update' hook, when enabled--and with
+`hooks.allowunannotated` config option turned on--prevents
+unannotated tags to be pushed.
+
+[[post-receive]]
+post-receive
+------------
+
+This hook is invoked by `git-receive-pack` on the remote repository,
+which happens when a `git push` is done on a local repository.
+It executes on the remote repository once after all the refs have
+been updated.
+
+This hook executes once for the receive operation. It takes no
+arguments, but gets the same information as the
+<<pre-receive,'pre-receive'>>
+hook does on its standard input.
+
+This hook does not affect the outcome of `git-receive-pack`, as it
+is called after the real work is done.
+
+This supersedes the <<post-update,'post-update'>> hook in that it gets
+both old and new values of all the refs in addition to their
+names.
+
+Both standard output and standard error output are forwarded to
+`git-send-pack` on the other end, so you can simply `echo` messages
+for the user.
+
+The default 'post-receive' hook is empty, but there is
+a sample script `post-receive-email` provided in the `contrib/hooks`
+directory in git distribution, which implements sending commit
+emails.
+
+[[post-update]]
+post-update
+-----------
+
+This hook is invoked by `git-receive-pack` on the remote repository,
+which happens when a `git push` is done on a local repository.
+It executes on the remote repository once after all the refs have
+been updated.
+
+It takes a variable number of parameters, each of which is the
+name of ref that was actually updated.
+
+This hook is meant primarily for notification, and cannot affect
+the outcome of `git-receive-pack`.
+
+The 'post-update' hook can tell what are the heads that were pushed,
+but it does not know what their original and updated values are,
+so it is a poor place to do log old..new. The
+<<post-receive,'post-receive'>> hook does get both original and
+updated values of the refs. You might consider it instead if you need
+them.
+
+When enabled, the default 'post-update' hook runs
+`git-update-server-info` to keep the information used by dumb
+transports (e.g., HTTP) up-to-date. If you are publishing
+a git repository that is accessible via HTTP, you should
+probably enable this hook.
+
+Both standard output and standard error output are forwarded to
+`git-send-pack` on the other end, so you can simply `echo` messages
+for the user.
+
+pre-auto-gc
+-----------
+
+This hook is invoked by `git-gc --auto`. It takes no parameter, and
+exiting with non-zero status from this script causes the `git-gc --auto`
+to abort.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
new file mode 100644
index 0000000000..2881c9cb92
--- /dev/null
+++ b/Documentation/gitignore.txt
@@ -0,0 +1,141 @@
+gitignore(5)
+============
+
+NAME
+----
+gitignore - Specifies intentionally untracked files to ignore
+
+SYNOPSIS
+--------
+$GIT_DIR/info/exclude, .gitignore
+
+DESCRIPTION
+-----------
+
+A `gitignore` file specifies intentionally untracked files that
+git should ignore. Each line in a `gitignore` file specifies a
+pattern.
+
+When deciding whether to ignore a path, git normally checks
+`gitignore` patterns from multiple sources, with the following
+order of precedence, from highest to lowest (within one level of
+precedence, the last matching pattern decides the outcome):
+
+ * Patterns read from the command line for those commands that support
+ them.
+
+ * Patterns read from a `.gitignore` file in the same directory
+ as the path, or in any parent directory, with patterns in the
+ higher level files (up to the root) being overridden by those in
+ lower level files down to the directory containing the file.
+ These patterns match relative to the location of the
+ `.gitignore` file. A project normally includes such
+ `.gitignore` files in its repository, containing patterns for
+ files generated as part of the project build.
+
+ * Patterns read from `$GIT_DIR/info/exclude`.
+
+ * Patterns read from the file specified by the configuration
+ variable 'core.excludesfile'.
+
+Which file to place a pattern in depends on how the pattern is meant to
+be used. Patterns which should be version-controlled and distributed to
+other repositories via clone (i.e., files that all developers will want
+to ignore) should go into a `.gitignore` file. Patterns which are
+specific to a particular repository but which do not need to be shared
+with other related repositories (e.g., auxiliary files that live inside
+the repository but are specific to one user's workflow) should go into
+the `$GIT_DIR/info/exclude` file. Patterns which a user wants git to
+ignore in all situations (e.g., backup or temporary files generated by
+the user's editor of choice) generally go into a file specified by
+`core.excludesfile` in the user's `~/.gitconfig`.
+
+The underlying git plumbing tools, such as
+linkgit:git-ls-files[1] and linkgit:git-read-tree[1], read
+`gitignore` patterns specified by command-line options, or from
+files specified by command-line options. Higher-level git
+tools, such as linkgit:git-status[1] and linkgit:git-add[1],
+use patterns from the sources specified above.
+
+Patterns have the following format:
+
+ - A blank line matches no files, so it can serve as a separator
+ for readability.
+
+ - A line starting with # serves as a comment.
+
+ - An optional prefix '!' which negates the pattern; any
+ matching file excluded by a previous pattern will become
+ included again. If a negated pattern matches, this will
+ override lower precedence patterns sources.
+
+ - If the pattern ends with a slash, it is removed for the
+ purpose of the following description, but it would only find
+ a match with a directory. In other words, `foo/` will match a
+ directory `foo` and paths underneath it, but will not match a
+ regular file or a symbolic link `foo` (this is consistent
+ with the way how pathspec works in general in git).
+
+ - If the pattern does not contain a slash '/', git treats it as
+ a shell glob pattern and checks for a match against the
+ pathname without leading directories.
+
+ - Otherwise, git treats the pattern as a shell glob suitable
+ for consumption by fnmatch(3) with the FNM_PATHNAME flag:
+ wildcards in the pattern will not match a / in the pathname.
+ For example, "Documentation/\*.html" matches
+ "Documentation/git.html" but not
+ "Documentation/ppc/ppc.html". A leading slash matches the
+ beginning of the pathname; for example, "/*.c" matches
+ "cat-file.c" but not "mozilla-sha1/sha1.c".
+
+An example:
+
+--------------------------------------------------------------
+ $ git-status
+ [...]
+ # Untracked files:
+ [...]
+ # Documentation/foo.html
+ # Documentation/gitignore.html
+ # file.o
+ # lib.a
+ # src/internal.o
+ [...]
+ $ cat .git/info/exclude
+ # ignore objects and archives, anywhere in the tree.
+ *.[oa]
+ $ cat Documentation/.gitignore
+ # ignore generated html files,
+ *.html
+ # except foo.html which is maintained by hand
+ !foo.html
+ $ git-status
+ [...]
+ # Untracked files:
+ [...]
+ # Documentation/foo.html
+ [...]
+--------------------------------------------------------------
+
+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 prevents git from ignoring
+`arch/foo/kernel/vmlinux.lds.S`.
+
+Documentation
+-------------
+Documentation by David Greaves, Junio C Hamano, Josh Triplett,
+Frank Lichtenheld, and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
new file mode 100644
index 0000000000..f843f39bf2
--- /dev/null
+++ b/Documentation/gitk.txt
@@ -0,0 +1,113 @@
+gitk(1)
+=======
+
+NAME
+----
+gitk - The git repository browser
+
+SYNOPSIS
+--------
+'gitk' [<option>...] [<revs>] [--] [<path>...]
+
+DESCRIPTION
+-----------
+Displays changes in a repository or a selected set of commits. This includes
+visualizing the commit graph, showing information related to each commit, and
+the files in the trees of each revision.
+
+Historically, gitk was the first repository browser. It's written in tcl/tk
+and started off in a separate repository but was later merged into the main
+git repository.
+
+OPTIONS
+-------
+To control which revisions to shown, the command takes options applicable to
+the linkgit:git-rev-list[1] command. This manual page describes only the most
+frequently used options.
+
+-n <number>::
+--max-count=<number>::
+
+ Limits the number of commits to show.
+
+--since=<date>::
+
+ Show commits more recent than a specific date.
+
+--until=<date>::
+
+ Show commits older than a specific date.
+
+--all::
+
+ Show all branches.
+
+--merge::
+
+ After an attempt to merge stops with conflicts, show the commits on
+ the history between two branches (i.e. the HEAD and the MERGE_HEAD)
+ that modify the conflicted files.
+
+<revs>::
+
+ Limit the revisions to show. This can be either a single revision
+ meaning show from the given revision and back, or it can be a range in
+ the form "'<from>'..'<to>'" to show all revisions between '<from>' and
+ back to '<to>'. Note, more advanced revision selection can be applied.
+ For a more complete list of ways to spell object names, see
+ "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
+
+<path>::
+
+ Limit commits to the ones touching files in the given paths. Note, to
+ avoid ambiguity wrt. revision names use "--" to separate the paths
+ from any preceding options.
+
+Examples
+--------
+gitk v2.6.12.. include/scsi drivers/scsi::
+
+ Show as the changes since version 'v2.6.12' that changed any
+ file in the include/scsi or drivers/scsi subdirectories
+
+gitk --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'
+
+gitk --max-count=100 --all \-- Makefile::
+
+ Show at most 100 changes made to the file 'Makefile'. Instead of only
+ looking for changes in the current branch look in all branches.
+
+Files
+-----
+Gitk creates the .gitk file in your $HOME directory to store preferences
+such as display options, font, and colors.
+
+SEE ALSO
+--------
+'qgit(1)'::
+ A repository browser written in C++ using Qt.
+
+'gitview(1)'::
+ A repository browser written in Python using Gtk. It's based on
+ 'bzrk(1)' and distributed in the contrib area of the git repository.
+
+'tig(1)'::
+ A minimal repository browser and git tool output highlighter written
+ in C using Ncurses.
+
+Author
+------
+Written by Paul Mackerras <paulus@samba.org>.
+
+Documentation
+--------------
+Documentation by Junio C Hamano, Jonas Fonseca, and the git-list
+<git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
new file mode 100644
index 0000000000..f8d122a8b9
--- /dev/null
+++ b/Documentation/gitmodules.txt
@@ -0,0 +1,62 @@
+gitmodules(5)
+=============
+
+NAME
+----
+gitmodules - defining submodule properties
+
+SYNOPSIS
+--------
+gitmodules
+
+
+DESCRIPTION
+-----------
+
+The `.gitmodules` file, located in the top-level directory of a git
+working tree, is a text file with a syntax matching the requirements
+of linkgit:git-config[1].
+
+The file contains one subsection per submodule, and the subsection value
+is the name of the submodule. Each submodule section also contains the
+following required keys:
+
+submodule.<name>.path::
+ Defines the path, relative to the top-level directory of the git
+ working tree, where the submodule is expected to be checked out.
+ The path name must not end with a `/`. All submodule paths must
+ be unique within the .gitmodules file.
+
+submodule.<name>.url::
+ Defines an url from where the submodule repository can be cloned.
+
+
+EXAMPLES
+--------
+
+Consider the following .gitmodules file:
+
+ [submodule "libfoo"]
+ path = include/foo
+ url = git://foo.com/git/lib.git
+
+ [submodule "libbar"]
+ path = include/bar
+ url = git://bar.com/git/lib.git
+
+
+This defines two submodules, `libfoo` and `libbar`. These are expected to
+be checked out in the paths 'include/foo' and 'include/bar', and for both
+submodules an url is specified which can be used for cloning the submodules.
+
+SEE ALSO
+--------
+linkgit:git-submodule[1] linkgit:git-config[1]
+
+DOCUMENTATION
+-------------
+Documentation by Lars Hjemli <hjemli@gmail.com>
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
new file mode 100644
index 0000000000..03c52ff526
--- /dev/null
+++ b/Documentation/gitrepository-layout.txt
@@ -0,0 +1,208 @@
+gitrepository-layout(5)
+=======================
+
+NAME
+----
+gitrepository-layout - Git Repository Layout
+
+SYNOPSIS
+--------
+$GIT_DIR/*
+
+DESCRIPTION
+-----------
+
+You may find these things in your git repository (`.git`
+directory for a repository associated with your working tree, or
+`<project>.git` directory for a public 'bare' repository. It is
+also possible to have a working tree where `.git` is a plain
+ascii file containing `gitdir: <path>`, i.e. the path to the
+real git repository).
+
+objects::
+ Object store associated with this repository. Usually
+ an object store is self sufficient (i.e. all the objects
+ that are referred to by an object found in it are also
+ found in it), but there are couple of ways to violate
+ it.
++
+. You could populate the repository by running a commit walker
+without `-a` option. Depending on which options are given, you
+could have only commit objects without associated blobs and
+trees this way, for example. A repository with this kind of
+incomplete object store is not suitable to be published to the
+outside world but sometimes useful for private repository.
+. You also could have an incomplete but locally usable repository
+by cloning shallowly. See linkgit:git-clone[1].
+. You can be using `objects/info/alternates` mechanism, or
+`$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanism to 'borrow'
+objects from other object stores. A repository with this kind
+of incomplete object store is not suitable to be published for
+use with dumb transports but otherwise is OK as long as
+`objects/info/alternates` points at the right object stores
+it borrows from.
+
+objects/[0-9a-f][0-9a-f]::
+ Traditionally, each object is stored in its own file.
+ They are split into 256 subdirectories using the first
+ two letters from its object name to keep the number of
+ directory entries `objects` directory itself needs to
+ hold. Objects found here are often called 'unpacked'
+ (or 'loose') objects.
+
+objects/pack::
+ Packs (files that store many object in compressed form,
+ along with index files to allow them to be randomly
+ accessed) are found in this directory.
+
+objects/info::
+ Additional information about the object store is
+ recorded in this directory.
+
+objects/info/packs::
+ This file is to help dumb transports discover what packs
+ are available in this object store. Whenever a pack is
+ added or removed, `git update-server-info` should be run
+ to keep this file up-to-date if the repository is
+ published for dumb transports. `git repack` does this
+ by default.
+
+objects/info/alternates::
+ This file records paths to alternate object stores that
+ this object store borrows objects from, one pathname per
+ line. Note that not only native Git tools use it locally,
+ but the HTTP fetcher also tries to use it remotely; this
+ will usually work if you have relative paths (relative
+ to the object database, not to the repository!) in your
+ alternates file, but it will not work if you use absolute
+ paths unless the absolute path in filesystem and web URL
+ is the same. See also 'objects/info/http-alternates'.
+
+objects/info/http-alternates::
+ This file records URLs to alternate object stores that
+ this object store borrows objects from, to be used when
+ the repository is fetched over HTTP.
+
+refs::
+ References are stored in subdirectories of this
+ directory. The `git prune` command knows to keep
+ objects reachable from refs found in this directory and
+ its subdirectories.
+
+refs/heads/`name`::
+ records tip-of-the-tree commit objects of branch `name`
+
+refs/tags/`name`::
+ records any object name (not necessarily a commit
+ object, or a tag object that points at a commit object).
+
+refs/remotes/`name`::
+ records tip-of-the-tree commit objects of branches copied
+ from a remote repository.
+
+packed-refs::
+ records the same information as refs/heads/, refs/tags/,
+ and friends record in a more efficient way. See
+ linkgit:git-pack-refs[1].
+
+HEAD::
+ A symref (see glossary) to the `refs/heads/` namespace
+ describing the currently active branch. It does not mean
+ much if the repository is not associated with any working tree
+ (i.e. a 'bare' repository), but a valid git repository
+ *must* have the HEAD file; some porcelains may use it to
+ guess the designated "default" branch of the repository
+ (usually 'master'). It is legal if the named branch
+ 'name' does not (yet) exist. In some legacy setups, it is
+ a symbolic link instead of a symref that points at the current
+ branch.
++
+HEAD can also record a specific commit directly, instead of
+being a symref to point at the current branch. Such a state
+is often called 'detached HEAD', and almost all commands work
+identically as normal. See linkgit:git-checkout[1] for
+details.
+
+branches::
+ A slightly deprecated way to store shorthands to be used
+ to specify URL to `git fetch`, `git pull` and `git push`
+ commands is to store a file in `branches/<name>` and
+ give 'name' to these commands in place of 'repository'
+ argument.
+
+hooks::
+ Hooks are customization scripts used by various git
+ commands. A handful of sample hooks are installed when
+ `git init` is run, but all of them are disabled by
+ default. To enable, they need to be made executable.
+ Read linkgit:githooks[5][hooks] for more details about
+ each hook.
+
+index::
+ The current index file for the repository. It is
+ usually not found in a bare repository.
+
+info::
+ Additional information about the repository is recorded
+ in this directory.
+
+info/refs::
+ This file helps dumb transports discover what refs are
+ available in this repository. If the repository is
+ published for dumb transports, this file should be
+ regenerated by `git update-server-info` every time a tag
+ or branch is created or modified. This is normally done
+ from the `hooks/update` hook, which is run by the
+ `git-receive-pack` command when you `git push` into the
+ repository.
+
+info/grafts::
+ This file records fake commit ancestry information, to
+ pretend the set of parents a commit has is different
+ from how the commit was actually created. One record
+ per line describes a commit and its fake parents by
+ listing their 40-byte hexadecimal object names separated
+ by a space and terminated by a newline.
+
+info/exclude::
+ This file, by convention among Porcelains, stores the
+ exclude pattern list. `.gitignore` is the per-directory
+ ignore file. `git status`, `git add`, `git rm` and `git
+ clean` look at it but the core git commands do not look
+ at it. See also: linkgit:gitignore[5].
+
+remotes::
+ Stores shorthands to be used to give URL and default
+ refnames to interact with remote repository to `git
+ fetch`, `git pull` and `git push` commands.
+
+logs::
+ Records of changes made to refs are stored in this
+ directory. See the documentation on git-update-ref
+ for more information.
+
+logs/refs/heads/`name`::
+ Records all changes made to the branch tip named `name`.
+
+logs/refs/tags/`name`::
+ Records all changes made to the tag named `name`.
+
+shallow::
+ This is similar to `info/grafts` but is internally used
+ and maintained by shallow clone mechanism. See `--depth`
+ option to linkgit:git-clone[1] and linkgit:git-fetch[1].
+
+SEE ALSO
+--------
+linkgit:git-init[1],
+linkgit:git-clone[1],
+linkgit:git-fetch[1],
+linkgit:git-pack-refs[1],
+linkgit:git-gc[1],
+linkgit:git-checkout[1],
+linkgit:gitglossary[7],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[1] suite.
diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt
new file mode 100644
index 0000000000..e3d5c1fbf0
--- /dev/null
+++ b/Documentation/gittutorial-2.txt
@@ -0,0 +1,430 @@
+gittutorial-2(7)
+================
+
+NAME
+----
+gittutorial-2 - A tutorial introduction to git: part two
+
+SYNOPSIS
+--------
+git *
+
+DESCRIPTION
+-----------
+
+You should work through linkgit:gittutorial[7][A tutorial introduction to
+git] before reading this tutorial.
+
+The goal of this tutorial is to introduce two fundamental pieces of
+git's architecture--the object database and the index file--and to
+provide the reader with everything necessary to understand the rest
+of the git documentation.
+
+The git object database
+-----------------------
+
+Let's start a new project and create a small amount of history:
+
+------------------------------------------------
+$ mkdir test-project
+$ cd test-project
+$ git init
+Initialized empty Git repository in .git/
+$ echo 'hello world' > file.txt
+$ git add .
+$ git commit -a -m "initial commit"
+Created initial commit 54196cc2703dc165cbd373a65a4dcf22d50ae7f7
+ create mode 100644 file.txt
+$ echo 'hello world!' >file.txt
+$ git commit -a -m "add emphasis"
+Created commit c4d59f390b9cfd4318117afde11d601c1085f241
+------------------------------------------------
+
+What are the 40 digits of hex that git responded to the commit with?
+
+We saw in part one of the tutorial that commits have names like this.
+It turns out that every object in the git history is stored under
+such a 40-digit hex name. That name is the SHA1 hash of the object's
+contents; among other things, this ensures that git will never store
+the same data twice (since identical data is given an identical SHA1
+name), and that the contents of a git object will never change (since
+that would change the object's name as well).
+
+It is expected that the content of the commit object you created while
+following the example above generates a different SHA1 hash than
+the one shown above because the commit object records the time when
+it was created and the name of the person performing the commit.
+
+We can ask git about this particular object with the cat-file
+command. Don't copy the 40 hex digits from this example but use those
+from your own version. Note that you can shorten it to only a few
+characters to save yourself typing all 40 hex digits:
+
+------------------------------------------------
+$ git-cat-file -t 54196cc2
+commit
+$ git-cat-file commit 54196cc2
+tree 92b8b694ffb1675e5975148e1121810081dbdffe
+author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+
+initial commit
+------------------------------------------------
+
+A tree can refer to one or more "blob" objects, each corresponding to
+a file. In addition, a tree can also refer to other tree objects,
+thus creating a directory hierarchy. You can examine the contents of
+any tree using ls-tree (remember that a long enough initial portion
+of the SHA1 will also work):
+
+------------------------------------------------
+$ git ls-tree 92b8b694
+100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad file.txt
+------------------------------------------------
+
+Thus we see that this tree has one file in it. The SHA1 hash is a
+reference to that file's data:
+
+------------------------------------------------
+$ git cat-file -t 3b18e512
+blob
+------------------------------------------------
+
+A "blob" is just file data, which we can also examine with cat-file:
+
+------------------------------------------------
+$ git cat-file blob 3b18e512
+hello world
+------------------------------------------------
+
+Note that this is the old file data; so the object that git named in
+its response to the initial tree was a tree with a snapshot of the
+directory state that was recorded by the first commit.
+
+All of these objects are stored under their SHA1 names inside the git
+directory:
+
+------------------------------------------------
+$ find .git/objects/
+.git/objects/
+.git/objects/pack
+.git/objects/info
+.git/objects/3b
+.git/objects/3b/18e512dba79e4c8300dd08aeb37f8e728b8dad
+.git/objects/92
+.git/objects/92/b8b694ffb1675e5975148e1121810081dbdffe
+.git/objects/54
+.git/objects/54/196cc2703dc165cbd373a65a4dcf22d50ae7f7
+.git/objects/a0
+.git/objects/a0/423896973644771497bdc03eb99d5281615b51
+.git/objects/d0
+.git/objects/d0/492b368b66bdabf2ac1fd8c92b39d3db916e59
+.git/objects/c4
+.git/objects/c4/d59f390b9cfd4318117afde11d601c1085f241
+------------------------------------------------
+
+and the contents of these files is just the compressed data plus a
+header identifying their length and their type. The type is either a
+blob, a tree, a commit, or a tag.
+
+The simplest commit to find is the HEAD commit, which we can find
+from .git/HEAD:
+
+------------------------------------------------
+$ cat .git/HEAD
+ref: refs/heads/master
+------------------------------------------------
+
+As you can see, this tells us which branch we're currently on, and it
+tells us this by naming a file under the .git directory, which itself
+contains a SHA1 name referring to a commit object, which we can
+examine with cat-file:
+
+------------------------------------------------
+$ cat .git/refs/heads/master
+c4d59f390b9cfd4318117afde11d601c1085f241
+$ git cat-file -t c4d59f39
+commit
+$ git cat-file commit c4d59f39
+tree d0492b368b66bdabf2ac1fd8c92b39d3db916e59
+parent 54196cc2703dc165cbd373a65a4dcf22d50ae7f7
+author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500
+committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500
+
+add emphasis
+------------------------------------------------
+
+The "tree" object here refers to the new state of the tree:
+
+------------------------------------------------
+$ git ls-tree d0492b36
+100644 blob a0423896973644771497bdc03eb99d5281615b51 file.txt
+$ git cat-file blob a0423896
+hello world!
+------------------------------------------------
+
+and the "parent" object refers to the previous commit:
+
+------------------------------------------------
+$ git-cat-file commit 54196cc2
+tree 92b8b694ffb1675e5975148e1121810081dbdffe
+author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+
+initial commit
+------------------------------------------------
+
+The tree object is the tree we examined first, and this commit is
+unusual in that it lacks any parent.
+
+Most commits have only one parent, but it is also common for a commit
+to have multiple parents. In that case the commit represents a
+merge, with the parent references pointing to the heads of the merged
+branches.
+
+Besides blobs, trees, and commits, the only remaining type of object
+is a "tag", which we won't discuss here; refer to linkgit:git-tag[1]
+for details.
+
+So now we know how git uses the object database to represent a
+project's history:
+
+ * "commit" objects refer to "tree" objects representing the
+ snapshot of a directory tree at a particular point in the
+ history, and refer to "parent" commits to show how they're
+ connected into the project history.
+ * "tree" objects represent the state of a single directory,
+ associating directory names to "blob" objects containing file
+ data and "tree" objects containing subdirectory information.
+ * "blob" objects contain file data without any other structure.
+ * References to commit objects at the head of each branch are
+ stored in files under .git/refs/heads/.
+ * The name of the current branch is stored in .git/HEAD.
+
+Note, by the way, that lots of commands take a tree as an argument.
+But as we can see above, a tree can be referred to in many different
+ways--by the SHA1 name for that tree, by the name of a commit that
+refers to the tree, by the name of a branch whose head refers to that
+tree, etc.--and most such commands can accept any of these names.
+
+In command synopses, the word "tree-ish" is sometimes used to
+designate such an argument.
+
+The index file
+--------------
+
+The primary tool we've been using to create commits is "git commit
+-a", which creates a commit including every change you've made to
+your working tree. But what if you want to commit changes only to
+certain files? Or only certain changes to certain files?
+
+If we look at the way commits are created under the cover, we'll see
+that there are more flexible ways creating commits.
+
+Continuing with our test-project, let's modify file.txt again:
+
+------------------------------------------------
+$ echo "hello world, again" >>file.txt
+------------------------------------------------
+
+but this time instead of immediately making the commit, let's take an
+intermediate step, and ask for diffs along the way to keep track of
+what's happening:
+
+------------------------------------------------
+$ git diff
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,2 @@
+ hello world!
++hello world, again
+$ git add file.txt
+$ git diff
+------------------------------------------------
+
+The last diff is empty, but no new commits have been made, and the
+head still doesn't contain the new line:
+
+------------------------------------------------
+$ git-diff HEAD
+diff --git a/file.txt b/file.txt
+index a042389..513feba 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,2 @@
+ hello world!
++hello world, again
+------------------------------------------------
+
+So "git diff" is comparing against something other than the head.
+The thing that it's comparing against is actually the index file,
+which is stored in .git/index in a binary format, but whose contents
+we can examine with ls-files:
+
+------------------------------------------------
+$ git ls-files --stage
+100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt
+$ git cat-file -t 513feba2
+blob
+$ git cat-file blob 513feba2
+hello world!
+hello world, again
+------------------------------------------------
+
+So what our "git add" did was store a new blob and then put
+a reference to it in the index file. If we modify the file again,
+we'll see that the new modifications are reflected in the "git-diff"
+output:
+
+------------------------------------------------
+$ echo 'again?' >>file.txt
+$ git diff
+index 513feba..ba3da7b 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1,2 +1,3 @@
+ hello world!
+ hello world, again
++again?
+------------------------------------------------
+
+With the right arguments, git diff can also show us the difference
+between the working directory and the last commit, or between the
+index and the last commit:
+
+------------------------------------------------
+$ git diff HEAD
+diff --git a/file.txt b/file.txt
+index a042389..ba3da7b 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,3 @@
+ hello world!
++hello world, again
++again?
+$ git diff --cached
+diff --git a/file.txt b/file.txt
+index a042389..513feba 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,2 @@
+ hello world!
++hello world, again
+------------------------------------------------
+
+At any time, we can create a new commit using "git commit" (without
+the -a option), and verify that the state committed only includes the
+changes stored in the index file, not the additional change that is
+still only in our working tree:
+
+------------------------------------------------
+$ git commit -m "repeat"
+$ git diff HEAD
+diff --git a/file.txt b/file.txt
+index 513feba..ba3da7b 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1,2 +1,3 @@
+ hello world!
+ hello world, again
++again?
+------------------------------------------------
+
+So by default "git commit" uses the index to create the commit, not
+the working tree; the -a option to commit tells it to first update
+the index with all changes in the working tree.
+
+Finally, it's worth looking at the effect of "git add" on the index
+file:
+
+------------------------------------------------
+$ echo "goodbye, world" >closing.txt
+$ git add closing.txt
+------------------------------------------------
+
+The effect of the "git add" was to add one entry to the index file:
+
+------------------------------------------------
+$ git ls-files --stage
+100644 8b9743b20d4b15be3955fc8d5cd2b09cd2336138 0 closing.txt
+100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt
+------------------------------------------------
+
+And, as you can see with cat-file, this new entry refers to the
+current contents of the file:
+
+------------------------------------------------
+$ git cat-file blob 8b9743b2
+goodbye, world
+------------------------------------------------
+
+The "status" command is a useful way to get a quick summary of the
+situation:
+
+------------------------------------------------
+$ git status
+# On branch master
+# Changes to be committed:
+# (use "git reset HEAD <file>..." to unstage)
+#
+# new file: closing.txt
+#
+# Changed but not updated:
+# (use "git add <file>..." to update what will be committed)
+#
+# modified: file.txt
+#
+------------------------------------------------
+
+Since the current state of closing.txt is cached in the index file,
+it is listed as "Changes to be committed". Since file.txt has
+changes in the working directory that aren't reflected in the index,
+it is marked "changed but not updated". At this point, running "git
+commit" would create a commit that added closing.txt (with its new
+contents), but that didn't modify file.txt.
+
+Also, note that a bare "git diff" shows the changes to file.txt, but
+not the addition of closing.txt, because the version of closing.txt
+in the index file is identical to the one in the working directory.
+
+In addition to being the staging area for new commits, the index file
+is also populated from the object database when checking out a
+branch, and is used to hold the trees involved in a merge operation.
+See the linkgit:gitcore-tutorial[7][core tutorial] and the relevant man
+pages for details.
+
+What next?
+----------
+
+At this point you should know everything necessary to read the man
+pages for any of the git commands; one good place to start would be
+with the commands mentioned in link:everyday.html[Everyday git]. You
+should be able to find any unknown jargon in the
+linkgit:gitglossary[7][Glossary].
+
+The link:user-manual.html[Git User's Manual] provides a more
+comprehensive introduction to git.
+
+The linkgit:gitcvs-migration[7][CVS migration] document explains how to
+import a CVS repository into git, and shows how to use git in a
+CVS-like way.
+
+For some interesting examples of git use, see the
+link:howto-index.html[howtos].
+
+For git developers, the linkgit:gitcore-tutorial[7][Core tutorial] goes
+into detail on the lower-level git mechanisms involved in, for
+example, creating a new commit.
+
+SEE ALSO
+--------
+linkgit:gittutorial[7],
+linkgit:gitcvs-migration[7],
+linkgit:gitcore-tutorial[7],
+linkgit:gitglossary[7],
+link:everyday.html[Everyday git],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[1] suite.
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
new file mode 100644
index 0000000000..d465aab64e
--- /dev/null
+++ b/Documentation/gittutorial.txt
@@ -0,0 +1,608 @@
+gittutorial(7)
+==============
+
+NAME
+----
+gittutorial - A tutorial introduction to git (for version 1.5.1 or newer)
+
+SYNOPSIS
+--------
+git *
+
+DESCRIPTION
+-----------
+
+This tutorial explains how to import a new project into git, make
+changes to it, and share changes with other developers.
+
+If you are instead primarily interested in using git to fetch a project,
+for example, to test the latest version, you may prefer to start with
+the first two chapters of link:user-manual.html[The Git User's Manual].
+
+First, note that you can get documentation for a command such as "git
+diff" with:
+
+------------------------------------------------
+$ man git-diff
+------------------------------------------------
+
+It is a good idea to introduce yourself to git with your name and
+public email address before doing any operation. The easiest
+way to do so is:
+
+------------------------------------------------
+$ git config --global user.name "Your Name Comes Here"
+$ git config --global user.email you@yourdomain.example.com
+------------------------------------------------
+
+
+Importing a new project
+-----------------------
+
+Assume you have a tarball project.tar.gz with your initial work. You
+can place it under git revision control as follows.
+
+------------------------------------------------
+$ tar xzf project.tar.gz
+$ cd project
+$ git init
+------------------------------------------------
+
+Git will reply
+
+------------------------------------------------
+Initialized empty Git repository in .git/
+------------------------------------------------
+
+You've now initialized the working directory--you may notice a new
+directory created, named ".git".
+
+Next, tell git to take a snapshot of the contents of all files under the
+current directory (note the '.'), with linkgit:git-add[1]:
+
+------------------------------------------------
+$ git add .
+------------------------------------------------
+
+This snapshot is now stored in a temporary staging area which git calls
+the "index". You can permanently store the contents of the index in the
+repository with linkgit:git-commit[1]:
+
+------------------------------------------------
+$ git commit
+------------------------------------------------
+
+This will prompt you for a commit message. You've now stored the first
+version of your project in git.
+
+Making changes
+--------------
+
+Modify some files, then add their updated contents to the index:
+
+------------------------------------------------
+$ git add file1 file2 file3
+------------------------------------------------
+
+You are now ready to commit. You can see what is about to be committed
+using linkgit:git-diff[1] with the --cached option:
+
+------------------------------------------------
+$ git diff --cached
+------------------------------------------------
+
+(Without --cached, linkgit:git-diff[1] will show you any changes that
+you've made but not yet added to the index.) You can also get a brief
+summary of the situation with linkgit:git-status[1]:
+
+------------------------------------------------
+$ git status
+# On branch master
+# Changes to be committed:
+# (use "git reset HEAD <file>..." to unstage)
+#
+# modified: file1
+# modified: file2
+# modified: file3
+#
+------------------------------------------------
+
+If you need to make any further adjustments, do so now, and then add any
+newly modified content to the index. Finally, commit your changes with:
+
+------------------------------------------------
+$ git commit
+------------------------------------------------
+
+This will again prompt you for a message describing the change, and then
+record a new version of the project.
+
+Alternatively, instead of running `git add` beforehand, you can use
+
+------------------------------------------------
+$ git commit -a
+------------------------------------------------
+
+which will automatically notice any modified (but not new) files, add
+them to the index, and commit, all in one step.
+
+A note on commit messages: Though not required, it's a good idea to
+begin the commit message with a single short (less than 50 character)
+line summarizing the change, followed by a blank line and then a more
+thorough description. Tools that turn commits into email, for
+example, use the first line on the Subject: line and the rest of the
+commit in the body.
+
+Git tracks content not files
+----------------------------
+
+Many revision control systems provide an "add" command that tells the
+system to start tracking changes to a new file. Git's "add" command
+does something simpler and more powerful: `git add` is used both for new
+and newly modified files, and in both cases it takes a snapshot of the
+given files and stages that content in the index, ready for inclusion in
+the next commit.
+
+Viewing project history
+-----------------------
+
+At any point you can view the history of your changes using
+
+------------------------------------------------
+$ git log
+------------------------------------------------
+
+If you also want to see complete diffs at each step, use
+
+------------------------------------------------
+$ git log -p
+------------------------------------------------
+
+Often the overview of the change is useful to get a feel of
+each step
+
+------------------------------------------------
+$ git log --stat --summary
+------------------------------------------------
+
+Managing branches
+-----------------
+
+A single git repository can maintain multiple branches of
+development. To create a new branch named "experimental", use
+
+------------------------------------------------
+$ git branch experimental
+------------------------------------------------
+
+If you now run
+
+------------------------------------------------
+$ git branch
+------------------------------------------------
+
+you'll get a list of all existing branches:
+
+------------------------------------------------
+ experimental
+* master
+------------------------------------------------
+
+The "experimental" branch is the one you just created, and the
+"master" branch is a default branch that was created for you
+automatically. The asterisk marks the branch you are currently on;
+type
+
+------------------------------------------------
+$ git checkout experimental
+------------------------------------------------
+
+to switch to the experimental branch. Now edit a file, commit the
+change, and switch back to the master branch:
+
+------------------------------------------------
+(edit file)
+$ git commit -a
+$ git checkout master
+------------------------------------------------
+
+Check that the change you made is no longer visible, since it was
+made on the experimental branch and you're back on the master branch.
+
+You can make a different change on the master branch:
+
+------------------------------------------------
+(edit file)
+$ git commit -a
+------------------------------------------------
+
+at this point the two branches have diverged, with different changes
+made in each. To merge the changes made in experimental into master, run
+
+------------------------------------------------
+$ git merge experimental
+------------------------------------------------
+
+If the changes don't conflict, you're done. If there are conflicts,
+markers will be left in the problematic files showing the conflict;
+
+------------------------------------------------
+$ git diff
+------------------------------------------------
+
+will show this. Once you've edited the files to resolve the
+conflicts,
+
+------------------------------------------------
+$ git commit -a
+------------------------------------------------
+
+will commit the result of the merge. Finally,
+
+------------------------------------------------
+$ gitk
+------------------------------------------------
+
+will show a nice graphical representation of the resulting history.
+
+At this point you could delete the experimental branch with
+
+------------------------------------------------
+$ git branch -d experimental
+------------------------------------------------
+
+This command ensures that the changes in the experimental branch are
+already in the current branch.
+
+If you develop on a branch crazy-idea, then regret it, you can always
+delete the branch with
+
+-------------------------------------
+$ git branch -D crazy-idea
+-------------------------------------
+
+Branches are cheap and easy, so this is a good way to try something
+out.
+
+Using git for collaboration
+---------------------------
+
+Suppose that Alice has started a new project with a git repository in
+/home/alice/project, and that Bob, who has a home directory on the
+same machine, wants to contribute.
+
+Bob begins with:
+
+------------------------------------------------
+$ git clone /home/alice/project myrepo
+------------------------------------------------
+
+This creates a new directory "myrepo" containing a clone of Alice's
+repository. The clone is on an equal footing with the original
+project, possessing its own copy of the original project's history.
+
+Bob then makes some changes and commits them:
+
+------------------------------------------------
+(edit files)
+$ git commit -a
+(repeat as necessary)
+------------------------------------------------
+
+When he's ready, he tells Alice to pull changes from the repository
+at /home/bob/myrepo. She does this with:
+
+------------------------------------------------
+$ cd /home/alice/project
+$ git pull /home/bob/myrepo master
+------------------------------------------------
+
+This merges the changes from Bob's "master" branch into Alice's
+current branch. If Alice has made her own changes in the meantime,
+then she may need to manually fix any conflicts. (Note that the
+"master" argument in the above command is actually unnecessary, as it
+is the default.)
+
+The "pull" command thus performs two operations: it fetches changes
+from a remote branch, then merges them into the current branch.
+
+When you are working in a small closely knit group, it is not
+unusual to interact with the same repository over and over
+again. By defining 'remote' repository shorthand, you can make
+it easier:
+
+------------------------------------------------
+$ git remote add bob /home/bob/myrepo
+------------------------------------------------
+
+With this, Alice can perform the first operation alone using the
+"git fetch" command without merging them with her own branch,
+using:
+
+-------------------------------------
+$ git fetch bob
+-------------------------------------
+
+Unlike the longhand form, when Alice fetches from Bob using a
+remote repository shorthand set up with `git remote`, what was
+fetched is stored in a remote tracking branch, in this case
+`bob/master`. So after this:
+
+-------------------------------------
+$ git log -p master..bob/master
+-------------------------------------
+
+shows a list of all the changes that Bob made since he branched from
+Alice's master branch.
+
+After examining those changes, Alice
+could merge the changes into her master branch:
+
+-------------------------------------
+$ git merge bob/master
+-------------------------------------
+
+This `merge` can also be done by 'pulling from her own remote
+tracking branch', like this:
+
+-------------------------------------
+$ git pull . remotes/bob/master
+-------------------------------------
+
+Note that git pull always merges into the current branch,
+regardless of what else is given on the command line.
+
+Later, Bob can update his repo with Alice's latest changes using
+
+-------------------------------------
+$ git pull
+-------------------------------------
+
+Note that he doesn't need to give the path to Alice's repository;
+when Bob cloned Alice's repository, git stored the location of her
+repository in the repository configuration, and that location is
+used for pulls:
+
+-------------------------------------
+$ git config --get remote.origin.url
+/home/alice/project
+-------------------------------------
+
+(The complete configuration created by git-clone is visible using
+"git config -l", and the linkgit:git-config[1] man page
+explains the meaning of each option.)
+
+Git also keeps a pristine copy of Alice's master branch under the
+name "origin/master":
+
+-------------------------------------
+$ git branch -r
+ origin/master
+-------------------------------------
+
+If Bob later decides to work from a different host, he can still
+perform clones and pulls using the ssh protocol:
+
+-------------------------------------
+$ git clone alice.org:/home/alice/project myrepo
+-------------------------------------
+
+Alternatively, git has a native protocol, or can use rsync or http;
+see linkgit:git-pull[1] for details.
+
+Git can also be used in a CVS-like mode, with a central repository
+that various users push changes to; see linkgit:git-push[1] and
+linkgit:gitcvs-migration[7][git for CVS users].
+
+Exploring history
+-----------------
+
+Git history is represented as a series of interrelated commits. We
+have already seen that the git log command can list those commits.
+Note that first line of each git log entry also gives a name for the
+commit:
+
+-------------------------------------
+$ git log
+commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
+Author: Junio C Hamano <junkio@cox.net>
+Date: Tue May 16 17:18:22 2006 -0700
+
+ merge-base: Clarify the comments on post processing.
+-------------------------------------
+
+We can give this name to git show to see the details about this
+commit.
+
+-------------------------------------
+$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
+-------------------------------------
+
+But there are other ways to refer to commits. You can use any initial
+part of the name that is long enough to uniquely identify the commit:
+
+-------------------------------------
+$ git show c82a22c39c # the first few characters of the name are
+ # usually enough
+$ git show HEAD # the tip of the current branch
+$ git show experimental # the tip of the "experimental" branch
+-------------------------------------
+
+Every commit usually has one "parent" commit
+which points to the previous state of the project:
+
+-------------------------------------
+$ git show HEAD^ # to see the parent of HEAD
+$ git show HEAD^^ # to see the grandparent of HEAD
+$ git show HEAD~4 # to see the great-great grandparent of HEAD
+-------------------------------------
+
+Note that merge commits may have more than one parent:
+
+-------------------------------------
+$ git show HEAD^1 # show the first parent of HEAD (same as HEAD^)
+$ git show HEAD^2 # show the second parent of HEAD
+-------------------------------------
+
+You can also give commits names of your own; after running
+
+-------------------------------------
+$ git-tag v2.5 1b2e1d63ff
+-------------------------------------
+
+you can refer to 1b2e1d63ff by the name "v2.5". If you intend to
+share this name with other people (for example, to identify a release
+version), you should create a "tag" object, and perhaps sign it; see
+linkgit:git-tag[1] for details.
+
+Any git command that needs to know a commit can take any of these
+names. For example:
+
+-------------------------------------
+$ git diff v2.5 HEAD # compare the current HEAD to v2.5
+$ git branch stable v2.5 # start a new branch named "stable" based
+ # at v2.5
+$ git reset --hard HEAD^ # reset your current branch and working
+ # directory to its state at HEAD^
+-------------------------------------
+
+Be careful with that last command: in addition to losing any changes
+in the working directory, it will also remove all later commits from
+this branch. If this branch is the only branch containing those
+commits, they will be lost. Also, don't use "git reset" on a
+publicly-visible branch that other developers pull from, as it will
+force needless merges on other developers to clean up the history.
+If you need to undo changes that you have pushed, use linkgit:git-revert[1]
+instead.
+
+The git grep command can search for strings in any version of your
+project, so
+
+-------------------------------------
+$ git grep "hello" v2.5
+-------------------------------------
+
+searches for all occurrences of "hello" in v2.5.
+
+If you leave out the commit name, git grep will search any of the
+files it manages in your current directory. So
+
+-------------------------------------
+$ git grep "hello"
+-------------------------------------
+
+is a quick way to search just the files that are tracked by git.
+
+Many git commands also take sets of commits, which can be specified
+in a number of ways. Here are some examples with git log:
+
+-------------------------------------
+$ git log v2.5..v2.6 # commits between v2.5 and v2.6
+$ git log v2.5.. # commits since v2.5
+$ git log --since="2 weeks ago" # commits from the last 2 weeks
+$ git log v2.5.. Makefile # commits since v2.5 which modify
+ # Makefile
+-------------------------------------
+
+You can also give git log a "range" of commits where the first is not
+necessarily an ancestor of the second; for example, if the tips of
+the branches "stable-release" and "master" diverged from a common
+commit some time ago, then
+
+-------------------------------------
+$ git log stable..experimental
+-------------------------------------
+
+will list commits made in the experimental branch but not in the
+stable branch, while
+
+-------------------------------------
+$ git log experimental..stable
+-------------------------------------
+
+will show the list of commits made on the stable branch but not
+the experimental branch.
+
+The "git log" command has a weakness: it must present commits in a
+list. When the history has lines of development that diverged and
+then merged back together, the order in which "git log" presents
+those commits is meaningless.
+
+Most projects with multiple contributors (such as the linux kernel,
+or git itself) have frequent merges, and gitk does a better job of
+visualizing their history. For example,
+
+-------------------------------------
+$ gitk --since="2 weeks ago" drivers/
+-------------------------------------
+
+allows you to browse any commits from the last 2 weeks of commits
+that modified files under the "drivers" directory. (Note: you can
+adjust gitk's fonts by holding down the control key while pressing
+"-" or "+".)
+
+Finally, most commands that take filenames will optionally allow you
+to precede any filename by a commit, to specify a particular version
+of the file:
+
+-------------------------------------
+$ git diff v2.5:Makefile HEAD:Makefile.in
+-------------------------------------
+
+You can also use "git show" to see any such file:
+
+-------------------------------------
+$ git show v2.5:Makefile
+-------------------------------------
+
+Next Steps
+----------
+
+This tutorial should be enough to perform basic distributed revision
+control for your projects. However, to fully understand the depth
+and power of git you need to understand two simple ideas on which it
+is based:
+
+ * The object database is the rather elegant system used to
+ store the history of your project--files, directories, and
+ commits.
+
+ * The index file is a cache of the state of a directory tree,
+ used to create commits, check out working directories, and
+ hold the various trees involved in a merge.
+
+linkgit:gittutorial-2[7][Part two of this tutorial] explains the object
+database, the index file, and a few other odds and ends that you'll
+need to make the most of git.
+
+If you don't want to continue with that right away, a few other
+digressions that may be interesting at this point are:
+
+ * linkgit:git-format-patch[1], linkgit:git-am[1]: These convert
+ series of git commits into emailed patches, and vice versa,
+ useful for projects such as the linux kernel which rely heavily
+ on emailed patches.
+
+ * linkgit:git-bisect[1]: When there is a regression in your
+ project, one way to track down the bug is by searching through
+ the history to find the exact commit that's to blame. Git bisect
+ can help you perform a binary search for that commit. It is
+ smart enough to perform a close-to-optimal search even in the
+ case of complex non-linear history with lots of merged branches.
+
+ * link:everyday.html[Everyday GIT with 20 Commands Or So]
+
+ * linkgit:gitcvs-migration[7][git for CVS users].
+
+SEE ALSO
+--------
+linkgit:gittutorial-2[7],
+linkgit:gitcvs-migration[7],
+linkgit:gitcore-tutorial[7],
+linkgit:gitglossary[7],
+link:everyday.html[Everyday git],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[1] suite.
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
new file mode 100644
index 0000000000..9b4a4f45e9
--- /dev/null
+++ b/Documentation/glossary-content.txt
@@ -0,0 +1,454 @@
+[[def_alternate_object_database]]alternate object database::
+ Via the alternates mechanism, a <<def_repository,repository>>
+ can inherit part of its <<def_object_database,object database>>
+ from another object database, which is called "alternate".
+
+[[def_bare_repository]]bare repository::
+ A bare repository is normally an appropriately
+ named <<def_directory,directory>> with a `.git` suffix that does not
+ have a locally checked-out copy of any of the files under
+ revision control. That is, all of the `git`
+ administrative and control files that would normally be present in the
+ hidden `.git` sub-directory are directly present in the
+ `repository.git` directory instead,
+ and no other files are present and checked out. Usually publishers of
+ public repositories make bare repositories available.
+
+[[def_blob_object]]blob object::
+ Untyped <<def_object,object>>, e.g. the contents of a file.
+
+[[def_branch]]branch::
+ A "branch" is an active line of development. The most recent
+ <<def_commit,commit>> on a branch is referred to as the tip of
+ that branch. The tip of the branch is referenced by a branch
+ <<def_head,head>>, which moves forward as additional development
+ is done on the branch. A single git
+ <<def_repository,repository>> can track an arbitrary number of
+ branches, but your <<def_working_tree,working tree>> is
+ associated with just one of them (the "current" or "checked out"
+ branch), and <<def_HEAD,HEAD>> points to that branch.
+
+[[def_cache]]cache::
+ Obsolete for: <<def_index,index>>.
+
+[[def_chain]]chain::
+ A list of objects, where each <<def_object,object>> in the list contains
+ a reference to its successor (for example, the successor of a
+ <<def_commit,commit>> could be one of its <<def_parent,parents>>).
+
+[[def_changeset]]changeset::
+ BitKeeper/cvsps speak for "<<def_commit,commit>>". Since git does not
+ store changes, but states, it really does not make sense to use the term
+ "changesets" with git.
+
+[[def_checkout]]checkout::
+ The action of updating all or part of the
+ <<def_working_tree,working tree>> with a <<def_tree_object,tree object>>
+ or <<def_blob_object,blob>> from the
+ <<def_object_database,object database>>, and updating the
+ <<def_index,index>> and <<def_HEAD,HEAD>> if the whole working tree has
+ been pointed at a new <<def_branch,branch>>.
+
+[[def_cherry-picking]]cherry-picking::
+ In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of
+ changes out of a series of changes (typically commits) and record them
+ as a new series of changes on top of a different codebase. In GIT, this is
+ performed by the "git cherry-pick" command to extract the change introduced
+ by an existing <<def_commit,commit>> and to record it based on the tip
+ of the current <<def_branch,branch>> as a new commit.
+
+[[def_clean]]clean::
+ A <<def_working_tree,working tree>> is clean, if it
+ corresponds to the <<def_revision,revision>> referenced by the current
+ <<def_head,head>>. Also see "<<def_dirty,dirty>>".
+
+[[def_commit]]commit::
+ As a noun: A single point in the
+ git history; the entire history of a project is represented as a
+ set of interrelated commits. The word "commit" is often
+ used by git in the same places other revision control systems
+ use the words "revision" or "version". Also used as a short
+ hand for <<def_commit_object,commit object>>.
++
+As a verb: The action of storing a new snapshot of the project's
+state in the git history, by creating a new commit representing the current
+state of the <<def_index,index>> and advancing <<def_HEAD,HEAD>>
+to point at the new commit.
+
+[[def_commit_object]]commit object::
+ An <<def_object,object>> which contains the information about a
+ particular <<def_revision,revision>>, such as <<def_parent,parents>>, committer,
+ author, date and the <<def_tree_object,tree object>> which corresponds
+ to the top <<def_directory,directory>> of the stored
+ revision.
+
+[[def_core_git]]core git::
+ Fundamental data structures and utilities of git. Exposes only limited
+ source code management tools.
+
+[[def_DAG]]DAG::
+ Directed acyclic graph. The <<def_commit_object,commit objects>> form a
+ directed acyclic graph, because they have parents (directed), and the
+ graph of commit objects is acyclic (there is no <<def_chain,chain>>
+ which begins and ends with the same <<def_object,object>>).
+
+[[def_dangling_object]]dangling object::
+ An <<def_unreachable_object,unreachable object>> which is not
+ <<def_reachable,reachable>> even from other unreachable objects; a
+ dangling object has no references to it from any
+ reference or <<def_object,object>> in the <<def_repository,repository>>.
+
+[[def_detached_HEAD]]detached HEAD::
+ Normally the <<def_HEAD,HEAD>> stores the name of a
+ <<def_branch,branch>>. However, git also allows you to <<def_checkout,check out>>
+ an arbitrary <<def_commit,commit>> that isn't necessarily the tip of any
+ particular branch. In this case HEAD is said to be "detached".
+
+[[def_dircache]]dircache::
+ You are *waaaaay* behind. See <<def_index,index>>.
+
+[[def_directory]]directory::
+ The list you get with "ls" :-)
+
+[[def_dirty]]dirty::
+ A <<def_working_tree,working tree>> is said to be "dirty" if
+ it contains modifications which have not been <<def_commit,committed>> to the current
+ <<def_branch,branch>>.
+
+[[def_ent]]ent::
+ Favorite synonym to "<<def_tree-ish,tree-ish>>" by some total geeks. See
+ `http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth
+ explanation. Avoid this term, not to confuse people.
+
+[[def_evil_merge]]evil merge::
+ An evil merge is a <<def_merge,merge>> that introduces changes that
+ do not appear in any <<def_parent,parent>>.
+
+[[def_fast_forward]]fast forward::
+ A fast-forward is a special type of <<def_merge,merge>> where you have a
+ <<def_revision,revision>> and you are "merging" another
+ <<def_branch,branch>>'s changes that happen to be a descendant of what
+ you have. In such these cases, you do not make a new <<def_merge,merge>>
+ <<def_commit,commit>> but instead just update to his
+ revision. This will happen frequently on a
+ <<def_tracking_branch,tracking branch>> of a remote
+ <<def_repository,repository>>.
+
+[[def_fetch]]fetch::
+ Fetching a <<def_branch,branch>> means to get the
+ branch's <<def_head_ref,head ref>> from a remote
+ <<def_repository,repository>>, to find out which objects are
+ missing from the local <<def_object_database,object database>>,
+ and to get them, too. See also linkgit:git-fetch[1].
+
+[[def_file_system]]file system::
+ Linus Torvalds originally designed git to be a user space file system,
+ i.e. the infrastructure to hold files and directories. That ensured the
+ efficiency and speed of git.
+
+[[def_git_archive]]git archive::
+ Synonym for <<def_repository,repository>> (for arch people).
+
+[[def_grafts]]grafts::
+ Grafts enables two otherwise different lines of development to be joined
+ together by recording fake ancestry information for commits. This way
+ you can make git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has
+ is different from what was recorded when the commit was
+ created. Configured via the `.git/info/grafts` file.
+
+[[def_hash]]hash::
+ In git's context, synonym to <<def_object_name,object name>>.
+
+[[def_head]]head::
+ A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a
+ <<def_branch,branch>>. Heads are stored in
+ `$GIT_DIR/refs/heads/`, except when using packed refs. (See
+ linkgit:git-pack-refs[1].)
+
+[[def_HEAD]]HEAD::
+ The current <<def_branch,branch>>. In more detail: Your <<def_working_tree,
+ working tree>> is normally derived from the state of the tree
+ referred to by HEAD. HEAD is a reference to one of the
+ <<def_head,heads>> in your repository, except when using a
+ <<def_detached_HEAD,detached HEAD>>, in which case it may
+ reference an arbitrary commit.
+
+[[def_head_ref]]head ref::
+ A synonym for <<def_head,head>>.
+
+[[def_hook]]hook::
+ During the normal execution of several git commands, call-outs are made
+ to optional scripts that allow a developer to add functionality or
+ checking. Typically, the hooks allow for a command to be pre-verified
+ and potentially aborted, and allow for a post-notification after the
+ operation is done. The hook scripts are found in the
+ `$GIT_DIR/hooks/` directory, and are enabled by simply
+ making them executable.
+
+[[def_index]]index::
+ A collection of files with stat information, whose contents are stored
+ as objects. The index is a stored version of your
+ <<def_working_tree,working tree>>. Truth be told, it can also contain a second, and even
+ a third version of a working tree, which are used
+ when <<def_merge,merging>>.
+
+[[def_index_entry]]index entry::
+ The information regarding a particular file, stored in the
+ <<def_index,index>>. An index entry can be unmerged, if a
+ <<def_merge,merge>> was started, but not yet finished (i.e. if
+ the index contains multiple versions of that file).
+
+[[def_master]]master::
+ The default development <<def_branch,branch>>. Whenever you
+ create a git <<def_repository,repository>>, a branch named
+ "master" is created, and becomes the active branch. In most
+ cases, this contains the local development, though that is
+ purely by convention and is not required.
+
+[[def_merge]]merge::
+ As a verb: To bring the contents of another
+ <<def_branch,branch>> (possibly from an external
+ <<def_repository,repository>>) into the current branch. In the
+ case where the merged-in branch is from a different repository,
+ this is done by first <<def_fetch,fetching>> the remote branch
+ and then merging the result into the current branch. This
+ combination of fetch and merge operations is called a
+ <<def_pull,pull>>. Merging is performed by an automatic process
+ that identifies changes made since the branches diverged, and
+ then applies all those changes together. In cases where changes
+ conflict, manual intervention may be required to complete the
+ merge.
++
+As a noun: unless it is a <<def_fast_forward,fast forward>>, a
+successful merge results in the creation of a new <<def_commit,commit>>
+representing the result of the merge, and having as
+<<def_parent,parents>> the tips of the merged <<def_branch,branches>>.
+This commit is referred to as a "merge commit", or sometimes just a
+"merge".
+
+[[def_object]]object::
+ The unit of storage in git. It is uniquely identified by the
+ <<def_SHA1,SHA1>> of its contents. Consequently, an
+ object can not be changed.
+
+[[def_object_database]]object database::
+ Stores a set of "objects", and an individual <<def_object,object>> is
+ identified by its <<def_object_name,object name>>. The objects usually
+ live in `$GIT_DIR/objects/`.
+
+[[def_object_identifier]]object identifier::
+ Synonym for <<def_object_name,object name>>.
+
+[[def_object_name]]object name::
+ The unique identifier of an <<def_object,object>>. The <<def_hash,hash>>
+ of the object's contents using the Secure Hash Algorithm
+ 1 and usually represented by the 40 character hexadecimal encoding of
+ the <<def_hash,hash>> of the object.
+
+[[def_object_type]]object type::
+ One of the identifiers "<<def_commit_object,commit>>",
+ "<<def_tree_object,tree>>", "<<def_tag_object,tag>>" or
+ "<<def_blob_object,blob>>" describing the type of an
+ <<def_object,object>>.
+
+[[def_octopus]]octopus::
+ To <<def_merge,merge>> more than two <<def_branch,branches>>. Also denotes an
+ intelligent predator.
+
+[[def_origin]]origin::
+ The default upstream <<def_repository,repository>>. Most projects have
+ at least one upstream project which they track. By default
+ 'origin' is used for that purpose. New upstream updates
+ will be fetched into remote <<def_tracking_branch,tracking branches>> named
+ origin/name-of-upstream-branch, which you can see using
+ "`git branch -r`".
+
+[[def_pack]]pack::
+ A set of objects which have been compressed into one file (to save space
+ or to transmit them efficiently).
+
+[[def_pack_index]]pack index::
+ The list of identifiers, and other information, of the objects in a
+ <<def_pack,pack>>, to assist in efficiently accessing the contents of a
+ pack.
+
+[[def_parent]]parent::
+ A <<def_commit_object,commit object>> contains a (possibly empty) list
+ of the logical predecessor(s) in the line of development, i.e. its
+ parents.
+
+[[def_pickaxe]]pickaxe::
+ The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore
+ routines that help select changes that add or delete a given text
+ string. With the `--pickaxe-all` option, it can be used to view the full
+ <<def_changeset,changeset>> that introduced or removed, say, a
+ particular line of text. See linkgit:git-diff[1].
+
+[[def_plumbing]]plumbing::
+ Cute name for <<def_core_git,core git>>.
+
+[[def_porcelain]]porcelain::
+ Cute name for programs and program suites depending on
+ <<def_core_git,core git>>, presenting a high level access to
+ core git. Porcelains expose more of a <<def_SCM,SCM>>
+ interface than the <<def_plumbing,plumbing>>.
+
+[[def_pull]]pull::
+ Pulling a <<def_branch,branch>> means to <<def_fetch,fetch>> it and
+ <<def_merge,merge>> it. See also linkgit:git-pull[1].
+
+[[def_push]]push::
+ Pushing a <<def_branch,branch>> means to get the branch's
+ <<def_head_ref,head ref>> from a remote <<def_repository,repository>>,
+ find out if it is a direct ancestor to the branch's local
+ head ref, and in that case, putting all
+ objects, which are <<def_reachable,reachable>> from the local
+ head ref, and which are missing from the remote
+ repository, into the remote
+ <<def_object_database,object database>>, and updating the remote
+ head ref. If the remote <<def_head,head>> is not an
+ ancestor to the local head, the push fails.
+
+[[def_reachable]]reachable::
+ All of the ancestors of a given <<def_commit,commit>> are said to be
+ "reachable" from that commit. More
+ generally, one <<def_object,object>> is reachable from
+ another if we can reach the one from the other by a <<def_chain,chain>>
+ that follows <<def_tag,tags>> to whatever they tag,
+ <<def_commit_object,commits>> to their parents or trees, and
+ <<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>>
+ that they contain.
+
+[[def_rebase]]rebase::
+ To reapply a series of changes from a <<def_branch,branch>> to a
+ different base, and reset the <<def_head,head>> of that branch
+ to the result.
+
+[[def_ref]]ref::
+ A 40-byte hex representation of a <<def_SHA1,SHA1>> or a name that
+ denotes a particular <<def_object,object>>. These may be stored in
+ `$GIT_DIR/refs/`.
+
+[[def_reflog]]reflog::
+ A reflog shows the local "history" of a ref. In other words,
+ it can tell you what the 3rd last revision in _this_ repository
+ was, and what was the current state in _this_ repository,
+ yesterday 9:14pm. See linkgit:git-reflog[1] for details.
+
+[[def_refspec]]refspec::
+ A "refspec" is used by <<def_fetch,fetch>> and
+ <<def_push,push>> to describe the mapping between remote
+ <<def_ref,ref>> and local ref. They are combined with a colon in
+ the format <src>:<dst>, preceded by an optional plus sign, +.
+ For example: `git fetch $URL
+ refs/heads/master:refs/heads/origin` means "grab the master
+ <<def_branch,branch>> <<def_head,head>> from the $URL and store
+ it as my origin branch head". And `git push
+ $URL refs/heads/master:refs/heads/to-upstream` means "publish my
+ master branch head as to-upstream branch at $URL". See also
+ linkgit:git-push[1].
+
+[[def_repository]]repository::
+ A collection of <<def_ref,refs>> together with an
+ <<def_object_database,object database>> containing all objects
+ which are <<def_reachable,reachable>> from the refs, possibly
+ accompanied by meta data from one or more <<def_porcelain,porcelains>>. A
+ repository can share an object database with other repositories
+ via <<def_alternate_object_database,alternates mechanism>>.
+
+[[def_resolve]]resolve::
+ The action of fixing up manually what a failed automatic
+ <<def_merge,merge>> left behind.
+
+[[def_revision]]revision::
+ A particular state of files and directories which was stored in the
+ <<def_object_database,object database>>. It is referenced by a
+ <<def_commit_object,commit object>>.
+
+[[def_rewind]]rewind::
+ To throw away part of the development, i.e. to assign the
+ <<def_head,head>> to an earlier <<def_revision,revision>>.
+
+[[def_SCM]]SCM::
+ Source code management (tool).
+
+[[def_SHA1]]SHA1::
+ Synonym for <<def_object_name,object name>>.
+
+[[def_shallow_repository]]shallow repository::
+ A shallow <<def_repository,repository>> has an incomplete
+ history some of whose <<def_commit,commits>> have <<def_parent,parents>> cauterized away (in other
+ words, git is told to pretend that these commits do not have the
+ parents, even though they are recorded in the <<def_commit_object,commit
+ object>>). This is sometimes useful when you are interested only in the
+ recent history of a project even though the real history recorded in the
+ upstream is much larger. A shallow repository
+ is created by giving the `--depth` option to linkgit:git-clone[1], and
+ its history can be later deepened with linkgit:git-fetch[1].
+
+[[def_symref]]symref::
+ Symbolic reference: instead of containing the <<def_SHA1,SHA1>>
+ id itself, it is of the format 'ref: refs/some/thing' and when
+ referenced, it recursively dereferences to this reference.
+ '<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic
+ references are manipulated with the linkgit:git-symbolic-ref[1]
+ command.
+
+[[def_tag]]tag::
+ A <<def_ref,ref>> pointing to a <<def_tag_object,tag>> or
+ <<def_commit_object,commit object>>. In contrast to a <<def_head,head>>,
+ a tag is not changed by a <<def_commit,commit>>. Tags (not
+ <<def_tag_object,tag objects>>) are stored in `$GIT_DIR/refs/tags/`. A
+ git tag has nothing to do with a Lisp tag (which would be
+ called an <<def_object_type,object type>> in git's context). A
+ tag is most typically used to mark a particular point in the
+ commit ancestry <<def_chain,chain>>.
+
+[[def_tag_object]]tag object::
+ An <<def_object,object>> containing a <<def_ref,ref>> pointing to
+ another object, which can contain a message just like a
+ <<def_commit_object,commit object>>. It can also contain a (PGP)
+ signature, in which case it is called a "signed tag object".
+
+[[def_topic_branch]]topic branch::
+ A regular git <<def_branch,branch>> that is used by a developer to
+ identify a conceptual line of development. Since branches are very easy
+ and inexpensive, it is often desirable to have several small branches
+ that each contain very well defined concepts or small incremental yet
+ related changes.
+
+[[def_tracking_branch]]tracking branch::
+ A regular git <<def_branch,branch>> that is used to follow changes from
+ another <<def_repository,repository>>. A tracking
+ branch should not contain direct modifications or have local commits
+ made to it. A tracking branch can usually be
+ identified as the right-hand-side <<def_ref,ref>> in a Pull:
+ <<def_refspec,refspec>>.
+
+[[def_tree]]tree::
+ Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree
+ object>> together with the dependent <<def_blob_object,blob>> and tree objects
+ (i.e. a stored representation of a working tree).
+
+[[def_tree_object]]tree object::
+ An <<def_object,object>> containing a list of file names and modes along
+ with refs to the associated blob and/or tree objects. A
+ <<def_tree,tree>> is equivalent to a <<def_directory,directory>>.
+
+[[def_tree-ish]]tree-ish::
+ A <<def_ref,ref>> pointing to either a <<def_commit_object,commit
+ object>>, a <<def_tree_object,tree object>>, or a <<def_tag_object,tag
+ object>> pointing to a tag or commit or tree object.
+
+[[def_unmerged_index]]unmerged index::
+ An <<def_index,index>> which contains unmerged
+ <<def_index_entry,index entries>>.
+
+[[def_unreachable_object]]unreachable object::
+ An <<def_object,object>> which is not <<def_reachable,reachable>> from a
+ <<def_branch,branch>>, <<def_tag,tag>>, or any other reference.
+
+[[def_working_tree]]working tree::
+ The tree of actual checked out files. The working tree is
+ normally equal to the <<def_HEAD,HEAD>> plus any local changes
+ that you have made but not yet committed.
diff --git a/Documentation/howto-index.sh b/Documentation/howto-index.sh
new file mode 100755
index 0000000000..34aa30c5b9
--- /dev/null
+++ b/Documentation/howto-index.sh
@@ -0,0 +1,56 @@
+#!/bin/sh
+
+cat <<\EOF
+GIT Howto Index
+===============
+
+Here is a collection of mailing list postings made by various
+people describing how they use git in their workflow.
+
+EOF
+
+for txt
+do
+ title=`expr "$txt" : '.*/\(.*\)\.txt$'`
+ from=`sed -ne '
+ /^$/q
+ /^From:[ ]/{
+ s///
+ s/^[ ]*//
+ s/[ ]*$//
+ s/^/by /
+ p
+ }
+ ' "$txt"`
+
+ abstract=`sed -ne '
+ /^Abstract:[ ]/{
+ s/^[^ ]*//
+ x
+ s/.*//
+ x
+ : again
+ /^[ ]/{
+ s/^[ ]*//
+ H
+ n
+ b again
+ }
+ x
+ p
+ q
+ }' "$txt"`
+
+ if grep 'Content-type: text/asciidoc' >/dev/null $txt
+ then
+ file=`expr "$txt" : '\(.*\)\.txt$'`.html
+ else
+ file="$txt"
+ fi
+
+ echo "* link:$file[$title] $from
+$abstract
+
+"
+
+done
diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt
new file mode 100644
index 0000000000..4357e26913
--- /dev/null
+++ b/Documentation/howto/maintain-git.txt
@@ -0,0 +1,277 @@
+From: Junio C Hamano <gitster@pobox.com>
+Date: Wed, 21 Nov 2007 16:32:55 -0800
+Subject: Addendum to "MaintNotes"
+Abstract: Imagine that git development is racing along as usual, when our friendly
+ neighborhood maintainer is struck down by a wayward bus. Out of the
+ hordes of suckers (loyal developers), you have been tricked (chosen) to
+ step up as the new maintainer. This howto will show you "how to" do it.
+
+The maintainer's git time is spent on three activities.
+
+ - Communication (60%)
+
+ Mailing list discussions on general design, fielding user
+ questions, diagnosing bug reports; reviewing, commenting on,
+ suggesting alternatives to, and rejecting patches.
+
+ - Integration (30%)
+
+ Applying new patches from the contributors while spotting and
+ correcting minor mistakes, shuffling the integration and
+ testing branches, pushing the results out, cutting the
+ releases, and making announcements.
+
+ - Own development (10%)
+
+ Scratching my own itch and sending proposed patch series out.
+
+The policy on Integration is informally mentioned in "A Note
+from the maintainer" message, which is periodically posted to
+this mailing list after each feature release is made.
+
+The policy.
+
+ - Feature releases are numbered as vX.Y.Z and are meant to
+ contain bugfixes and enhancements in any area, including
+ functionality, performance and usability, without regression.
+
+ - Maintenance releases are numbered as vX.Y.Z.W and are meant
+ to contain only bugfixes for the corresponding vX.Y.Z feature
+ release and earlier maintenance releases vX.Y.Z.V (V < W).
+
+ - 'master' branch is used to prepare for the next feature
+ release. In other words, at some point, the tip of 'master'
+ branch is tagged with vX.Y.Z.
+
+ - 'maint' branch is used to prepare for the next maintenance
+ release. After the feature release vX.Y.Z is made, the tip
+ of 'maint' branch is set to that release, and bugfixes will
+ accumulate on the branch, and at some point, the tip of the
+ branch is tagged with vX.Y.Z.1, vX.Y.Z.2, and so on.
+
+ - 'next' branch is used to publish changes (both enhancements
+ and fixes) that (1) have worthwhile goal, (2) are in a fairly
+ good shape suitable for everyday use, (3) but have not yet
+ demonstrated to be regression free. New changes are tested
+ in 'next' before merged to 'master'.
+
+ - 'pu' branch is used to publish other proposed changes that do
+ not yet pass the criteria set for 'next'.
+
+ - The tips of 'master', 'maint' and 'next' branches will always
+ fast forward, to allow people to build their own
+ customization on top of them.
+
+ - Usually 'master' contains all of 'maint', 'next' contains all
+ of 'master' and 'pu' contains all of 'next'.
+
+ - The tip of 'master' is meant to be more stable than any
+ tagged releases, and the users are encouraged to follow it.
+
+ - The 'next' branch is where new action takes place, and the
+ users are encouraged to test it so that regressions and bugs
+ are found before new topics are merged to 'master'.
+
+
+A typical git day for the maintainer implements the above policy
+by doing the following:
+
+ - Scan mailing list and #git channel log. Respond with review
+ comments, suggestions etc. Kibitz. Collect potentially
+ usable patches from the mailing list. Patches about a single
+ topic go to one mailbox (I read my mail in Gnus, and type
+ \C-o to save/append messages in files in mbox format).
+
+ - Review the patches in the saved mailboxes. Edit proposed log
+ message for typofixes and clarifications, and add Acks
+ collected from the list. Edit patch to incorporate "Oops,
+ that should have been like this" fixes from the discussion.
+
+ - Classify the collected patches and handle 'master' and
+ 'maint' updates:
+
+ - Obviously correct fixes that pertain to the tip of 'maint'
+ are directly applied to 'maint'.
+
+ - Obviously correct fixes that pertain to the tip of 'master'
+ are directly applied to 'master'.
+
+ This step is done with "git am".
+
+ $ git checkout master ;# or "git checkout maint"
+ $ git am -3 -s mailbox
+ $ make test
+
+ - Merge downwards (maint->master):
+
+ $ git checkout master
+ $ git merge maint
+ $ make test
+
+ - Review the last issue of "What's cooking" message, review the
+ topics scheduled for merging upwards (topic->master and
+ topic->maint), and merge.
+
+ $ git checkout master ;# or "git checkout maint"
+ $ git merge ai/topic ;# or "git merge ai/maint-topic"
+ $ git log -p ORIG_HEAD.. ;# final review
+ $ git diff ORIG_HEAD.. ;# final review
+ $ make test ;# final review
+ $ git branch -d ai/topic ;# or "git branch -d ai/maint-topic"
+
+ - Merge downwards (maint->master) if needed:
+
+ $ git checkout master
+ $ git merge maint
+ $ make test
+
+ - Merge downwards (master->next) if needed:
+
+ $ git checkout next
+ $ git merge master
+ $ make test
+
+ - Handle the remaining patches:
+
+ - Anything unobvious that is applicable to 'master' (in other
+ words, does not depend on anything that is still in 'next'
+ and not in 'master') is applied to a new topic branch that
+ is forked from the tip of 'master'. This includes both
+ enhancements and unobvious fixes to 'master'. A topic
+ branch is named as ai/topic where "ai" is typically
+ author's initial and "topic" is a descriptive name of the
+ topic (in other words, "what's the series is about").
+
+ - An unobvious fix meant for 'maint' is applied to a new
+ topic branch that is forked from the tip of 'maint'. The
+ topic is named as ai/maint-topic.
+
+ - Changes that pertain to an existing topic are applied to
+ the branch, but:
+
+ - obviously correct ones are applied first;
+
+ - questionable ones are discarded or applied to near the tip;
+
+ - Replacement patches to an existing topic are accepted only
+ for commits not in 'next'.
+
+ The above except the "replacement" are all done with:
+
+ $ git am -3 -s mailbox
+
+ while patch replacement is often done by:
+
+ $ git format-patch ai/topic~$n..ai/topic ;# export existing
+
+ then replace some parts with the new patch, and reapplying:
+
+ $ git reset --hard ai/topic~$n
+ $ git am -3 -s 000*.txt
+
+ The full test suite is always run for 'maint' and 'master'
+ after patch application; for topic branches the tests are run
+ as time permits.
+
+ - Update "What's cooking" message to review the updates to
+ existing topics, newly added topics and graduated topics.
+
+ This step is helped with Meta/UWC script (where Meta/ contains
+ a checkout of the 'todo' branch).
+
+ - Merge topics to 'next'. For each branch whose tip is not
+ merged to 'next', one of three things can happen:
+
+ - The commits are all next-worthy; merge the topic to next:
+
+ $ git checkout next
+ $ git merge ai/topic ;# or "git merge ai/maint-topic"
+ $ make test
+
+ - The new parts are of mixed quality, but earlier ones are
+ next-worthy; merge the early parts to next:
+
+ $ git checkout next
+ $ git merge ai/topic~2 ;# the tip two are dubious
+ $ make test
+
+ - Nothing is next-worthy; do not do anything.
+
+ - Rebase topics that do not have any commit in next yet. This
+ step is optional but sometimes is worth doing when an old
+ series that is not in next can take advantage of low-level
+ framework change that is merged to 'master' already.
+
+ $ git rebase master ai/topic
+
+ This step is helped with Meta/git-topic.perl script to
+ identify which topic is rebaseable. There also is a
+ pre-rebase hook to make sure that topics that are already in
+ 'next' are not rebased beyond the merged commit.
+
+ - Rebuild "pu" to merge the tips of topics not in 'next'.
+
+ $ git checkout pu
+ $ git reset --hard next
+ $ git merge ai/topic ;# repeat for all remaining topics
+ $ make test
+
+ This step is helped with Meta/PU script
+
+ - Push four integration branches to a private repository at
+ k.org and run "make test" on all of them.
+
+ - Push four integration branches to /pub/scm/git/git.git at
+ k.org. This triggers its post-update hook which:
+
+ (1) runs "git pull" in $HOME/git-doc/ repository to pull
+ 'master' just pushed out;
+
+ (2) runs "make doc" in $HOME/git-doc/, install the generated
+ documentation in staging areas, which are separate
+ repositories that have html and man branches checked
+ out.
+
+ (3) runs "git commit" in the staging areas, and run "git
+ push" back to /pub/scm/git/git.git/ to update the html
+ and man branches.
+
+ (4) installs generated documentation to /pub/software/scm/git/docs/
+ to be viewed from http://www.kernel.org/
+
+ - Fetch html and man branches back from k.org, and push four
+ integration branches and the two documentation branches to
+ repo.or.cz
+
+
+Some observations to be made.
+
+ * Each topic is tested individually, and also together with
+ other topics cooking in 'next'. Until it matures, none part
+ of it is merged to 'master'.
+
+ * A topic already in 'next' can get fixes while still in
+ 'next'. Such a topic will have many merges to 'next' (in
+ other words, "git log --first-parent next" will show many
+ "Merge ai/topic to next" for the same topic.
+
+ * An unobvious fix for 'maint' is cooked in 'next' and then
+ merged to 'master' to make extra sure it is Ok and then
+ merged to 'maint'.
+
+ * Even when 'next' becomes empty (in other words, all topics
+ prove stable and are merged to 'master' and "git diff master
+ next" shows empty), it has tons of merge commits that will
+ never be in 'master'.
+
+ * In principle, "git log --first-parent master..next" should
+ show nothing but merges (in practice, there are fixup commits
+ and reverts that are not merges).
+
+ * Commits near the tip of a topic branch that are not in 'next'
+ are fair game to be discarded, replaced or rewritten.
+ Commits already merged to 'next' will not be.
+
+ * Being in the 'next' branch is not a guarantee for a topic to
+ be included in the next feature release. Being in the
+ 'master' branch typically is.
diff --git a/Documentation/howto/rebase-and-edit.txt b/Documentation/howto/rebase-and-edit.txt
new file mode 100644
index 0000000000..554909fe08
--- /dev/null
+++ b/Documentation/howto/rebase-and-edit.txt
@@ -0,0 +1,79 @@
+Date: Sat, 13 Aug 2005 22:16:02 -0700 (PDT)
+From: Linus Torvalds <torvalds@osdl.org>
+To: Steve French <smfrench@austin.rr.com>
+cc: git@vger.kernel.org
+Subject: Re: sending changesets from the middle of a git tree
+Abstract: In this article, Linus demonstrates how a broken commit
+ in a sequence of commits can be removed by rewinding the head and
+ reapplying selected changes.
+
+On Sat, 13 Aug 2005, Linus Torvalds wrote:
+
+> That's correct. Same things apply: you can move a patch over, and create a
+> new one with a modified comment, but basically the _old_ commit will be
+> immutable.
+
+Let me clarify.
+
+You can entirely _drop_ old branches, so commits may be immutable, but
+nothing forces you to keep them. Of course, when you drop a commit, you'll
+always end up dropping all the commits that depended on it, and if you
+actually got somebody else to pull that commit you can't drop it from
+_their_ repository, but undoing things is not impossible.
+
+For example, let's say that you've made a mess of things: you've committed
+three commits "old->a->b->c", and you notice that "a" was broken, but you
+want to save "b" and "c". What you can do is
+
+ # Create a branch "broken" that is the current code
+ # for reference
+ git branch broken
+
+ # Reset the main branch to three parents back: this
+ # effectively undoes the three top commits
+ git reset HEAD^^^
+ git checkout -f
+
+ # Check the result visually to make sure you know what's
+ # going on
+ gitk --all
+
+ # Re-apply the two top ones from "broken"
+ #
+ # First "parent of broken" (aka b):
+ git-diff-tree -p broken^ | git-apply --index
+ git commit --reedit=broken^
+
+ # Then "top of broken" (aka c):
+ git-diff-tree -p broken | git-apply --index
+ git commit --reedit=broken
+
+and you've now re-applied (and possibly edited the comments) the two
+commits b/c, and commit "a" is basically gone (it still exists in the
+"broken" branch, of course).
+
+Finally, check out the end result again:
+
+ # Look at the new commit history
+ gitk --all
+
+to see that everything looks sensible.
+
+And then, you can just remove the broken branch if you decide you really
+don't want it:
+
+ # remove 'broken' branch
+ git branch -d broken
+
+ # Prune old objects if you're really really sure
+ git prune
+
+And yeah, I'm sure there are other ways of doing this. And as usual, the
+above is totally untested, and I just wrote it down in this email, so if
+I've done something wrong, you'll have to figure it out on your own ;)
+
+ Linus
+-
+To unsubscribe from this list: send the line "unsubscribe git" in
+the body of a message to majordomo@vger.kernel.org
+More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt
new file mode 100644
index 0000000000..7a76045eb7
--- /dev/null
+++ b/Documentation/howto/rebase-from-internal-branch.txt
@@ -0,0 +1,163 @@
+From: Junio C Hamano <junkio@cox.net>
+To: git@vger.kernel.org
+Cc: Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org>
+Subject: Re: sending changesets from the middle of a git tree
+Date: Sun, 14 Aug 2005 18:37:39 -0700
+Abstract: In this article, JC talks about how he rebases the
+ public "pu" branch using the core GIT tools when he updates
+ the "master" branch, and how "rebase" works. Also discussed
+ is how this applies to individual developers who sends patches
+ upstream.
+
+Petr Baudis <pasky@suse.cz> writes:
+
+> Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter
+> where Junio C Hamano <junkio@cox.net> told me that...
+>> Linus Torvalds <torvalds@osdl.org> writes:
+>>
+>> > Junio, maybe you want to talk about how you move patches from your "pu"
+>> > branch to the real branches.
+>>
+> Actually, wouldn't this be also precisely for what StGIT is intended to?
+
+Exactly my feeling. I was sort of waiting for Catalin to speak
+up. With its basing philosophical ancestry on quilt, this is
+the kind of task StGIT is designed to do.
+
+I just have done a simpler one, this time using only the core
+GIT tools.
+
+I had a handful commits that were ahead of master in pu, and I
+wanted to add some documentation bypassing my usual habit of
+placing new things in pu first. At the beginning, the commit
+ancestry graph looked like this:
+
+ *"pu" head
+ master --> #1 --> #2 --> #3
+
+So I started from master, made a bunch of edits, and committed:
+
+ $ git checkout master
+ $ cd Documentation; ed git.txt ...
+ $ cd ..; git add Documentation/*.txt
+ $ git commit -s
+
+After the commit, the ancestry graph would look like this:
+
+ *"pu" head
+ master^ --> #1 --> #2 --> #3
+ \
+ \---> master
+
+The old master is now master^ (the first parent of the master).
+The new master commit holds my documentation updates.
+
+Now I have to deal with "pu" branch.
+
+This is the kind of situation I used to have all the time when
+Linus was the maintainer and I was a contributor, when you look
+at "master" branch being the "maintainer" branch, and "pu"
+branch being the "contributor" branch. Your work started at the
+tip of the "maintainer" branch some time ago, you made a lot of
+progress in the meantime, and now the maintainer branch has some
+other commits you do not have yet. And "git rebase" was written
+with the explicit purpose of helping to maintain branches like
+"pu". You _could_ merge master to pu and keep going, but if you
+eventually want to cherrypick and merge some but not necessarily
+all changes back to the master branch, it often makes later
+operations for _you_ easier if you rebase (i.e. carry forward
+your changes) "pu" rather than merge. So I ran "git rebase":
+
+ $ git checkout pu
+ $ git rebase master pu
+
+What this does is to pick all the commits since the current
+branch (note that I now am on "pu" branch) forked from the
+master branch, and forward port these changes.
+
+ master^ --> #1 --> #2 --> #3
+ \ *"pu" head
+ \---> master --> #1' --> #2' --> #3'
+
+The diff between master^ and #1 is applied to master and
+committed to create #1' commit with the commit information (log,
+author and date) taken from commit #1. On top of that #2' and #3'
+commits are made similarly out of #2 and #3 commits.
+
+Old #3 is not recorded in any of the .git/refs/heads/ file
+anymore, so after doing this you will have dangling commit if
+you ran fsck-cache, which is normal. After testing "pu", you
+can run "git prune" to get rid of those original three commits.
+
+While I am talking about "git rebase", I should talk about how
+to do cherrypicking using only the core GIT tools.
+
+Let's go back to the earlier picture, with different labels.
+
+You, as an individual developer, cloned upstream repository and
+made a couple of commits on top of it.
+
+ *your "master" head
+ upstream --> #1 --> #2 --> #3
+
+You would want changes #2 and #3 incorporated in the upstream,
+while you feel that #1 may need further improvements. So you
+prepare #2 and #3 for e-mail submission.
+
+ $ git format-patch master^^ master
+
+This creates two files, 0001-XXXX.patch and 0002-XXXX.patch. Send
+them out "To: " your project maintainer and "Cc: " your mailing
+list. You could use contributed script git-send-email if
+your host has necessary perl modules for this, but your usual
+MUA would do as long as it does not corrupt whitespaces in the
+patch.
+
+Then you would wait, and you find out that the upstream picked
+up your changes, along with other changes.
+
+ where *your "master" head
+ upstream --> #1 --> #2 --> #3
+ used \
+ to be \--> #A --> #2' --> #3' --> #B --> #C
+ *upstream head
+
+The two commits #2' and #3' in the above picture record the same
+changes your e-mail submission for #2 and #3 contained, but
+probably with the new sign-off line added by the upstream
+maintainer and definitely with different committer and ancestry
+information, they are different objects from #2 and #3 commits.
+
+You fetch from upstream, but not merge.
+
+ $ git fetch upstream
+
+This leaves the updated upstream head in .git/FETCH_HEAD but
+does not touch your .git/HEAD nor .git/refs/heads/master.
+You run "git rebase" now.
+
+ $ git rebase FETCH_HEAD master
+
+Earlier, I said that rebase applies all the commits from your
+branch on top of the upstream head. Well, I lied. "git rebase"
+is a bit smarter than that and notices that #2 and #3 need not
+be applied, so it only applies #1. The commit ancestry graph
+becomes something like this:
+
+ where *your old "master" head
+ upstream --> #1 --> #2 --> #3
+ used \ your new "master" head*
+ to be \--> #A --> #2' --> #3' --> #B --> #C --> #1'
+ *upstream
+ head
+
+Again, "git prune" would discard the disused commits #1-#3 and
+you continue on starting from the new "master" head, which is
+the #1' commit.
+
+-jc
+
+-
+To unsubscribe from this list: send the line "unsubscribe git" in
+the body of a message to majordomo@vger.kernel.org
+More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/howto/rebuild-from-update-hook.txt b/Documentation/howto/rebuild-from-update-hook.txt
new file mode 100644
index 0000000000..8d55dfbfae
--- /dev/null
+++ b/Documentation/howto/rebuild-from-update-hook.txt
@@ -0,0 +1,86 @@
+Subject: [HOWTO] Using post-update hook
+Message-ID: <7vy86o6usx.fsf@assigned-by-dhcp.cox.net>
+From: Junio C Hamano <junkio@cox.net>
+Date: Fri, 26 Aug 2005 18:19:10 -0700
+Abstract: In this how-to article, JC talks about how he
+ uses the post-update hook to automate git documentation page
+ shown at http://www.kernel.org/pub/software/scm/git/docs/.
+
+The pages under http://www.kernel.org/pub/software/scm/git/docs/
+are built from Documentation/ directory of the git.git project
+and needed to be kept up-to-date. The www.kernel.org/ servers
+are mirrored and I was told that the origin of the mirror is on
+the machine $some.kernel.org, on which I was given an account
+when I took over git maintainership from Linus.
+
+The directories relevant to this how-to are these two:
+
+ /pub/scm/git/git.git/ The public git repository.
+ /pub/software/scm/git/docs/ The HTML documentation page.
+
+So I made a repository to generate the documentation under my
+home directory over there.
+
+ $ cd
+ $ mkdir doc-git && cd doc-git
+ $ git clone /pub/scm/git/git.git/ docgen
+
+What needs to happen is to update the $HOME/doc-git/docgen/
+working tree, build HTML docs there and install the result in
+/pub/software/scm/git/docs/ directory. So I wrote a little
+script:
+
+ $ cat >dododoc.sh <<\EOF
+ #!/bin/sh
+ cd $HOME/doc-git/docgen || exit
+
+ unset GIT_DIR
+
+ git pull /pub/scm/git/git.git/ master &&
+ cd Documentation &&
+ make install-webdoc
+ EOF
+
+Initially I used to run this by hand whenever I push into the
+public git repository. Then I did a cron job that ran twice a
+day. The current round uses the post-update hook mechanism,
+like this:
+
+ $ cat >/pub/scm/git/git.git/hooks/post-update <<\EOF
+ #!/bin/sh
+ #
+ # An example hook script to prepare a packed repository for use over
+ # dumb transports.
+ #
+ # To enable this hook, make this file executable by "chmod +x post-update".
+
+ case " $* " in
+ *' refs/heads/master '*)
+ echo $HOME/doc-git/dododoc.sh | at now
+ ;;
+ esac
+ exec git-update-server-info
+ EOF
+ $ chmod +x /pub/scm/git/git.git/hooks/post-update
+
+There are four things worth mentioning:
+
+ - The update-hook is run after the repository accepts a "git
+ push", under my user privilege. It is given the full names
+ of refs that have been updated as arguments. My post-update
+ runs the dododoc.sh script only when the master head is
+ updated.
+
+ - When update-hook is run, GIT_DIR is set to '.' by the calling
+ receive-pack. This is inherited by the dododoc.sh run via
+ the "at" command, and needs to be unset; otherwise, "git
+ pull" it does into $HOME/doc-git/docgen/ repository would not
+ work correctly.
+
+ - The stdout of update hook script is not connected to git
+ push; I run the heavy part of the command inside "at", to
+ receive the execution report via e-mail.
+
+ - This is still crude and does not protect against simultaneous
+ make invocations stomping on each other. I would need to add
+ some locking mechanism for this.
diff --git a/Documentation/howto/recover-corrupted-blob-object.txt b/Documentation/howto/recover-corrupted-blob-object.txt
new file mode 100644
index 0000000000..323b513ed0
--- /dev/null
+++ b/Documentation/howto/recover-corrupted-blob-object.txt
@@ -0,0 +1,134 @@
+Date: Fri, 9 Nov 2007 08:28:38 -0800 (PST)
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Subject: corrupt object on git-gc
+Abstract: Some tricks to reconstruct blob objects in order to fix
+ a corrupted repository.
+
+On Fri, 9 Nov 2007, Yossi Leybovich wrote:
+>
+> Did not help still the repository look for this object?
+> Any one know how can I track this object and understand which file is it
+
+So exactly *because* the SHA1 hash is cryptographically secure, the hash
+itself doesn't actually tell you anything, in order to fix a corrupt
+object you basically have to find the "original source" for it.
+
+The easiest way to do that is almost always to have backups, and find the
+same object somewhere else. Backups really are a good idea, and git makes
+it pretty easy (if nothing else, just clone the repository somewhere else,
+and make sure that you do *not* use a hard-linked clone, and preferably
+not the same disk/machine).
+
+But since you don't seem to have backups right now, the good news is that
+especially with a single blob being corrupt, these things *are* somewhat
+debuggable.
+
+First off, move the corrupt object away, and *save* it. The most common
+cause of corruption so far has been memory corruption, but even so, there
+are people who would be interested in seeing the corruption - but it's
+basically impossible to judge the corruption until we can also see the
+original object, so right now the corrupt object is useless, but it's very
+interesting for the future, in the hope that you can re-create a
+non-corrupt version.
+
+So:
+
+> ib]$ mv .git/objects/4b/9458b3786228369c63936db65827de3cc06200 ../
+
+This is the right thing to do, although it's usually best to save it under
+it's full SHA1 name (you just dropped the "4b" from the result ;).
+
+Let's see what that tells us:
+
+> ib]$ git-fsck --full
+> broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
+> to blob 4b9458b3786228369c63936db65827de3cc06200
+> missing blob 4b9458b3786228369c63936db65827de3cc06200
+
+Ok, I removed the "dangling commit" messages, because they are just
+messages about the fact that you probably have rebased etc, so they're not
+at all interesting. But what remains is still very useful. In particular,
+we now know which tree points to it!
+
+Now you can do
+
+ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
+
+which will show something like
+
+ 100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8 .gitignore
+ 100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883 .mailmap
+ 100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c COPYING
+ 100644 blob ee909f2cc49e54f0799a4739d24c4cb9151ae453 CREDITS
+ 040000 tree 0f5f709c17ad89e72bdbbef6ea221c69807009f6 Documentation
+ 100644 blob 1570d248ad9237e4fa6e4d079336b9da62d9ba32 Kbuild
+ 100644 blob 1c7c229a092665b11cd46a25dbd40feeb31661d9 MAINTAINERS
+ ...
+
+and you should now have a line that looks like
+
+ 10064 blob 4b9458b3786228369c63936db65827de3cc06200 my-magic-file
+
+in the output. This already tells you a *lot* it tells you what file the
+corrupt blob came from!
+
+Now, it doesn't tell you quite enough, though: it doesn't tell what
+*version* of the file didn't get correctly written! You might be really
+lucky, and it may be the version that you already have checked out in your
+working tree, in which case fixing this problem is really simple, just do
+
+ git hash-object -w my-magic-file
+
+again, and if it outputs the missing SHA1 (4b945..) you're now all done!
+
+But that's the really lucky case, so let's assume that it was some older
+version that was broken. How do you tell which version it was?
+
+The easiest way to do it is to do
+
+ git log --raw --all --full-history -- subdirectory/my-magic-file
+
+and that will show you the whole log for that file (please realize that
+the tree you had may not be the top-level tree, so you need to figure out
+which subdirectory it was in on your own), and because you're asking for
+raw output, you'll now get something like
+
+ commit abc
+ Author:
+ Date:
+ ..
+ :100644 100644 4b9458b... newsha... M somedirectory/my-magic-file
+
+
+ commit xyz
+ Author:
+ Date:
+
+ ..
+ :100644 100644 oldsha... 4b9458b... M somedirectory/my-magic-file
+
+and this actually tells you what the *previous* and *subsequent* versions
+of that file were! So now you can look at those ("oldsha" and "newsha"
+respectively), and hopefully you have done commits often, and can
+re-create the missing my-magic-file version by looking at those older and
+newer versions!
+
+If you can do that, you can now recreate the missing object with
+
+ git hash-object -w <recreated-file>
+
+and your repository is good again!
+
+(Btw, you could have ignored the fsck, and started with doing a
+
+ git log --raw --all
+
+and just looked for the sha of the missing object (4b9458b..) in that
+whole thing. It's up to you - git does *have* a lot of information, it is
+just missing one particular blob version.
+
+Trying to recreate trees and especially commits is *much* harder. So you
+were lucky that it's a blob. It's quite possible that you can recreate the
+thing.
+
+ Linus
diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt
new file mode 100644
index 0000000000..865a666324
--- /dev/null
+++ b/Documentation/howto/revert-branch-rebase.txt
@@ -0,0 +1,193 @@
+From: Junio C Hamano <junkio@cox.net>
+To: git@vger.kernel.org
+Subject: [HOWTO] Reverting an existing commit
+Abstract: In this article, JC gives a small real-life example of using
+ 'git revert' command, and using a temporary branch and tag for safety
+ and easier sanity checking.
+Date: Mon, 29 Aug 2005 21:39:02 -0700
+Content-type: text/asciidoc
+Message-ID: <7voe7g3uop.fsf@assigned-by-dhcp.cox.net>
+
+Reverting an existing commit
+============================
+
+One of the changes I pulled into the 'master' branch turns out to
+break building GIT with GCC 2.95. While they were well intentioned
+portability fixes, keeping things working with gcc-2.95 was also
+important. Here is what I did to revert the change in the 'master'
+branch and to adjust the 'pu' branch, using core GIT tools and
+barebone Porcelain.
+
+First, prepare a throw-away branch in case I screw things up.
+
+------------------------------------------------
+$ git checkout -b revert-c99 master
+------------------------------------------------
+
+Now I am on the 'revert-c99' branch. Let's figure out which commit to
+revert. I happen to know that the top of the 'master' branch is a
+merge, and its second parent (i.e. foreign commit I merged from) has
+the change I would want to undo. Further I happen to know that that
+merge introduced 5 commits or so:
+
+------------------------------------------------
+$ git show-branch --more=4 master master^2 | head
+* [master] Merge refs/heads/portable from http://www.cs.berkeley....
+ ! [master^2] Replace C99 array initializers with code.
+--
+- [master] Merge refs/heads/portable from http://www.cs.berkeley....
+*+ [master^2] Replace C99 array initializers with code.
+*+ [master^2~1] Replace unsetenv() and setenv() with older putenv().
+*+ [master^2~2] Include sys/time.h in daemon.c.
+*+ [master^2~3] Fix ?: statements.
+*+ [master^2~4] Replace zero-length array decls with [].
+* [master~1] tutorial note about git branch
+------------------------------------------------
+
+The '--more=4' above means "after we reach the merge base of refs,
+show until we display four more common commits". That last commit
+would have been where the "portable" branch was forked from the main
+git.git repository, so this would show everything on both branches
+since then. I just limited the output to the first handful using
+'head'.
+
+Now I know 'master^2~4' (pronounce it as "find the second parent of
+the 'master', and then go four generations back following the first
+parent") is the one I would want to revert. Since I also want to say
+why I am reverting it, the '-n' flag is given to 'git revert'. This
+prevents it from actually making a commit, and instead 'git revert'
+leaves the commit log message it wanted to use in '.msg' file:
+
+------------------------------------------------
+$ git revert -n master^2~4
+$ cat .msg
+Revert "Replace zero-length array decls with []."
+
+This reverts 6c5f9baa3bc0d63e141e0afc23110205379905a4 commit.
+$ git diff HEAD ;# to make sure what we are reverting makes sense.
+$ make CC=gcc-2.95 clean test ;# make sure it fixed the breakage.
+$ make clean test ;# make sure it did not cause other breakage.
+------------------------------------------------
+
+The reverted change makes sense (from reading the 'diff' output), does
+fix the problem (from 'make CC=gcc-2.95' test), and does not cause new
+breakage (from the last 'make test'). I'm ready to commit:
+
+------------------------------------------------
+$ git commit -a -s ;# read .msg into the log,
+ # and explain why I am reverting.
+------------------------------------------------
+
+I could have screwed up in any of the above steps, but in the worst
+case I could just have done 'git checkout master' to start over.
+Fortunately I did not have to; what I have in the current branch
+'revert-c99' is what I want. So merge that back into 'master':
+
+------------------------------------------------
+$ git checkout master
+$ git merge revert-c99 ;# this should be a fast forward
+Updating from 10d781b9caa4f71495c7b34963bef137216f86a8 to e3a693c...
+ cache.h | 8 ++++----
+ commit.c | 2 +-
+ ls-files.c | 2 +-
+ receive-pack.c | 2 +-
+ server-info.c | 2 +-
+ 5 files changed, 8 insertions(+), 8 deletions(-)
+------------------------------------------------
+
+There is no need to redo the test at this point. We fast forwarded
+and we know 'master' matches 'revert-c99' exactly. In fact:
+
+------------------------------------------------
+$ git diff master..revert-c99
+------------------------------------------------
+
+says nothing.
+
+Then we rebase the 'pu' branch as usual.
+
+------------------------------------------------
+$ git checkout pu
+$ git tag pu-anchor pu
+$ git rebase master
+* Applying: Redo "revert" using three-way merge machinery.
+First trying simple merge strategy to cherry-pick.
+Finished one cherry-pick.
+* Applying: Remove git-apply-patch-script.
+First trying simple merge strategy to cherry-pick.
+Simple cherry-pick fails; trying Automatic cherry-pick.
+Removing Documentation/git-apply-patch-script.txt
+Removing git-apply-patch-script
+Finished one cherry-pick.
+* Applying: Document "git cherry-pick" and "git revert"
+First trying simple merge strategy to cherry-pick.
+Finished one cherry-pick.
+* Applying: mailinfo and applymbox updates
+First trying simple merge strategy to cherry-pick.
+Finished one cherry-pick.
+* Applying: Show commits in topo order and name all commits.
+First trying simple merge strategy to cherry-pick.
+Finished one cherry-pick.
+* Applying: More documentation updates.
+First trying simple merge strategy to cherry-pick.
+Finished one cherry-pick.
+------------------------------------------------
+
+The temporary tag 'pu-anchor' is me just being careful, in case 'git
+rebase' screws up. After this, I can do these for sanity check:
+
+------------------------------------------------
+$ git diff pu-anchor..pu ;# make sure we got the master fix.
+$ make CC=gcc-2.95 clean test ;# make sure it fixed the breakage.
+$ make clean test ;# make sure it did not cause other breakage.
+------------------------------------------------
+
+Everything is in the good order. I do not need the temporary branch
+nor tag anymore, so remove them:
+
+------------------------------------------------
+$ rm -f .git/refs/tags/pu-anchor
+$ git branch -d revert-c99
+------------------------------------------------
+
+It was an emergency fix, so we might as well merge it into the
+'release candidate' branch, although I expect the next release would
+be some days off:
+
+------------------------------------------------
+$ git checkout rc
+$ git pull . master
+Packing 0 objects
+Unpacking 0 objects
+
+* committish: e3a693c... refs/heads/master from .
+Trying to merge e3a693c... into 8c1f5f0... using 10d781b...
+Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f
+ cache.h | 8 ++++----
+ commit.c | 2 +-
+ ls-files.c | 2 +-
+ receive-pack.c | 2 +-
+ server-info.c | 2 +-
+ 5 files changed, 8 insertions(+), 8 deletions(-)
+------------------------------------------------
+
+And the final repository status looks like this:
+
+------------------------------------------------
+$ git show-branch --more=1 master pu rc
+! [master] Revert "Replace zero-length array decls with []."
+ ! [pu] git-repack: Add option to repack all objects.
+ * [rc] Merge refs/heads/master from .
+---
+ + [pu] git-repack: Add option to repack all objects.
+ + [pu~1] More documentation updates.
+ + [pu~2] Show commits in topo order and name all commits.
+ + [pu~3] mailinfo and applymbox updates
+ + [pu~4] Document "git cherry-pick" and "git revert"
+ + [pu~5] Remove git-apply-patch-script.
+ + [pu~6] Redo "revert" using three-way merge machinery.
+ - [rc] Merge refs/heads/master from .
+++* [master] Revert "Replace zero-length array decls with []."
+ - [rc~1] Merge refs/heads/master from .
+... [master~1] Merge refs/heads/portable from http://www.cs.berkeley....
+------------------------------------------------
diff --git a/Documentation/howto/separating-topic-branches.txt b/Documentation/howto/separating-topic-branches.txt
new file mode 100644
index 0000000000..0d73b31224
--- /dev/null
+++ b/Documentation/howto/separating-topic-branches.txt
@@ -0,0 +1,90 @@
+From: Junio C Hamano <junkio@cox.net>
+Subject: Separating topic branches
+Abstract: In this article, JC describes how to separate topic branches.
+
+This text was originally a footnote to a discussion about the
+behaviour of the git diff commands.
+
+Often I find myself doing that [running diff against something other
+than HEAD] while rewriting messy development history. For example, I
+start doing some work without knowing exactly where it leads, and end
+up with a history like this:
+
+ "master"
+ o---o
+ \ "topic"
+ o---o---o---o---o---o
+
+At this point, "topic" contains something I know I want, but it
+contains two concepts that turned out to be completely independent.
+And often, one topic component is larger than the other. It may
+contain more than two topics.
+
+In order to rewrite this mess to be more manageable, I would first do
+"diff master..topic", to extract the changes into a single patch, start
+picking pieces from it to get logically self-contained units, and
+start building on top of "master":
+
+ $ git diff master..topic >P.diff
+ $ git checkout -b topicA master
+ ... pick and apply pieces from P.diff to build
+ ... commits on topicA branch.
+
+ o---o---o
+ / "topicA"
+ o---o"master"
+ \ "topic"
+ o---o---o---o---o---o
+
+Before doing each commit on "topicA" HEAD, I run "diff HEAD"
+before update-index the affected paths, or "diff --cached HEAD"
+after. Also I would run "diff --cached master" to make sure
+that the changes are only the ones related to "topicA". Usually
+I do this for smaller topics first.
+
+After that, I'd do the remainder of the original "topic", but
+for that, I do not start from the patchfile I extracted by
+comparing "master" and "topic" I used initially. Still on
+"topicA", I extract "diff topic", and use it to rebuild the
+other topic:
+
+ $ git diff -R topic >P.diff ;# --cached also would work fine
+ $ git checkout -b topicB master
+ ... pick and apply pieces from P.diff to build
+ ... commits on topicB branch.
+
+ "topicB"
+ o---o---o---o---o
+ /
+ /o---o---o
+ |/ "topicA"
+ o---o"master"
+ \ "topic"
+ o---o---o---o---o---o
+
+After I am done, I'd try a pretend-merge between "topicA" and
+"topicB" in order to make sure I have not missed anything:
+
+ $ git pull . topicA ;# merge it into current "topicB"
+ $ git diff topic
+ "topicB"
+ o---o---o---o---o---* (pretend merge)
+ / /
+ /o---o---o----------'
+ |/ "topicA"
+ o---o"master"
+ \ "topic"
+ o---o---o---o---o---o
+
+The last diff better not to show anything other than cleanups
+for crufts. Then I can finally clean things up:
+
+ $ git branch -D topic
+ $ git reset --hard HEAD^ ;# nuke pretend merge
+
+ "topicB"
+ o---o---o---o---o
+ /
+ /o---o---o
+ |/ "topicA"
+ o---o"master"
diff --git a/Documentation/howto/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt
new file mode 100644
index 0000000000..b7d09c1ec6
--- /dev/null
+++ b/Documentation/howto/setup-git-server-over-http.txt
@@ -0,0 +1,277 @@
+From: Rutger Nijlunsing <rutger@nospam.com>
+Subject: Setting up a git repository which can be pushed into and pulled from over HTTP(S).
+Date: Thu, 10 Aug 2006 22:00:26 +0200
+
+Since Apache is one of those packages people like to compile
+themselves while others prefer the bureaucrat's dream Debian, it is
+impossible to give guidelines which will work for everyone. Just send
+some feedback to the mailing list at git@vger.kernel.org to get this
+document tailored to your favorite distro.
+
+
+What's needed:
+
+- Have an Apache web-server
+
+ On Debian:
+ $ apt-get install apache2
+ To get apache2 by default started,
+ edit /etc/default/apache2 and set NO_START=0
+
+- can edit the configuration of it.
+
+ This could be found under /etc/httpd, or refer to your Apache documentation.
+
+ On Debian: this means being able to edit files under /etc/apache2
+
+- can restart it.
+
+ 'apachectl --graceful' might do. If it doesn't, just stop and
+ restart apache. Be warning that active connections to your server
+ might be aborted by this.
+
+ On Debian:
+ $ /etc/init.d/apache2 restart
+ or
+ $ /etc/init.d/apache2 force-reload
+ (which seems to do the same)
+ This adds symlinks from the /etc/apache2/mods-enabled to
+ /etc/apache2/mods-available.
+
+- have permissions to chown a directory
+
+- have git installed on the client, and
+
+- either have git installed on the server or have a webdav client on
+ the client.
+
+In effect, this means you're going to be root, or that you're using a
+preconfigured WebDAV server.
+
+
+Step 1: setup a bare GIT repository
+-----------------------------------
+
+At the time of writing, git-http-push cannot remotely create a GIT
+repository. So we have to do that at the server side with git. Another
+option is to generate an empty bare repository at the client and copy
+it to the server with a WebDAV client (which is the only option if Git
+is not installed on the server).
+
+Create the directory under the DocumentRoot of the directories served
+by Apache. As an example we take /usr/local/apache2, but try "grep
+DocumentRoot /where/ever/httpd.conf" to find your root:
+
+ $ cd /usr/local/apache/htdocs
+ $ mkdir my-new-repo.git
+
+ On Debian:
+
+ $ cd /var/www
+ $ mkdir my-new-repo.git
+
+
+Initialize a bare repository
+
+ $ cd my-new-repo.git
+ $ git --bare init
+
+
+Change the ownership to your web-server's credentials. Use "grep ^User
+httpd.conf" and "grep ^Group httpd.conf" to find out:
+
+ $ chown -R www.www .
+
+ On Debian:
+
+ $ chown -R www-data.www-data .
+
+
+If you do not know which user Apache runs as, you can alternatively do
+a "chmod -R a+w .", inspect the files which are created later on, and
+set the permissions appropriately.
+
+Restart apache2, and check whether http://server/my-new-repo.git gives
+a directory listing. If not, check whether apache started up
+successfully.
+
+
+Step 2: enable DAV on this repository
+-------------------------------------
+
+First make sure the dav_module is loaded. For this, insert in httpd.conf:
+
+ LoadModule dav_module libexec/httpd/libdav.so
+ AddModule mod_dav.c
+
+Also make sure that this line exists which is the file used for
+locking DAV operations:
+
+ DAVLockDB "/usr/local/apache2/temp/DAV.lock"
+
+ On Debian these steps can be performed with:
+
+ Enable the dav and dav_fs modules of apache:
+ $ a2enmod dav_fs
+ (just to be sure. dav_fs might be unneeded, I don't know)
+ $ a2enmod dav
+ The DAV lock is located in /etc/apache2/mods-available/dav_fs.conf:
+ DAVLockDB /var/lock/apache2/DAVLock
+
+Of course, it can point somewhere else, but the string is actually just a
+prefix in some Apache configurations, and therefore the _directory_ has to
+be writable by the user Apache runs as.
+
+Then, add something like this to your httpd.conf
+
+ <Location /my-new-repo.git>
+ DAV on
+ AuthType Basic
+ AuthName "Git"
+ AuthUserFile /usr/local/apache2/conf/passwd.git
+ Require valid-user
+ </Location>
+
+ On Debian:
+ Create (or add to) /etc/apache2/conf.d/git.conf :
+
+ <Location /my-new-repo.git>
+ DAV on
+ AuthType Basic
+ AuthName "Git"
+ AuthUserFile /etc/apache2/passwd.git
+ Require valid-user
+ </Location>
+
+ Debian automatically reads all files under /etc/apach2/conf.d.
+
+The password file can be somewhere else, but it has to be readable by
+Apache and preferably not readable by the world.
+
+Create this file by
+ $ htpasswd -c /usr/local/apache2/conf/passwd.git <user>
+
+ On Debian:
+ $ htpasswd -c /etc/apache2/passwd.git <user>
+
+You will be asked a password, and the file is created. Subsequent calls
+to htpasswd should omit the '-c' option, since you want to append to the
+existing file.
+
+You need to restart Apache.
+
+Now go to http://<username>@<servername>/my-new-repo.git in your
+browser to check whether it asks for a password and accepts the right
+password.
+
+On Debian:
+
+ To test the WebDAV part, do:
+
+ $ apt-get install litmus
+ $ litmus http://<servername>/my-new-repo.git <username> <password>
+
+ Most tests should pass.
+
+A command line tool to test WebDAV is cadaver. If you prefer GUIs, for
+example, konqueror can open WebDAV URLs as "webdav://..." or
+"webdavs://...".
+
+If you're into Windows, from XP onwards Internet Explorer supports
+WebDAV. For this, do Internet Explorer -> Open Location ->
+http://<servername>/my-new-repo.git [x] Open as webfolder -> login .
+
+
+Step 3: setup the client
+------------------------
+
+Make sure that you have HTTP support, i.e. your git was built with
+curl (version more recent than 7.10). The command 'git http-push' with
+no argument should display a usage message.
+
+Then, add the following to your $HOME/.netrc (you can do without, but will be
+asked to input your password a _lot_ of times):
+
+ machine <servername>
+ login <username>
+ password <password>
+
+...and set permissions:
+ chmod 600 ~/.netrc
+
+If you want to access the web-server by its IP, you have to type that in,
+instead of the server name.
+
+To check whether all is OK, do:
+
+ curl --netrc --location -v http://<username>@<servername>/my-new-repo.git/HEAD
+
+...this should give something like 'ref: refs/heads/master', which is
+the content of the file HEAD on the server.
+
+Now, add the remote in your existing repository which contains the project
+you want to export:
+
+ $ git-config remote.upload.url \
+ http://<username>@<servername>/my-new-repo.git/
+
+It is important to put the last '/'; Without it, the server will send
+a redirect which git-http-push does not (yet) understand, and git-http-push
+will repeat the request infinitely.
+
+
+Step 4: make the initial push
+-----------------------------
+
+From your client repository, do
+
+ $ git push upload master
+
+This pushes branch 'master' (which is assumed to be the branch you
+want to export) to repository called 'upload', which we previously
+defined with git-config.
+
+
+Using a proxy:
+--------------
+
+If you have to access the WebDAV server from behind an HTTP(S) proxy,
+set the variable 'all_proxy' to 'http://proxy-host.com:port', or
+'http://login-on-proxy:passwd-on-proxy@proxy-host.com:port'. See 'man
+curl' for details.
+
+
+Troubleshooting:
+----------------
+
+If git-http-push says
+
+ Error: no DAV locking support on remote repo http://...
+
+then it means the web-server did not accept your authentication. Make sure
+that the user name and password matches in httpd.conf, .netrc and the URL
+you are uploading to.
+
+If git-http-push shows you an error (22/502) when trying to MOVE a blob,
+it means that your web-server somehow does not recognize its name in the
+request; This can happen when you start Apache, but then disable the
+network interface. A simple restart of Apache helps.
+
+Errors like (22/502) are of format (curl error code/http error
+code). So (22/404) means something like 'not found' at the server.
+
+Reading /usr/local/apache2/logs/error_log is often helpful.
+
+ On Debian: Read /var/log/apache2/error.log instead.
+
+If you access HTTPS locations, git may fail verifying the SSL
+certificate (this is return code 60). Setting http.sslVerify=false can
+help diagnosing the problem, but removes security checks.
+
+
+Debian References: http://www.debian-administration.org/articles/285
+
+Authors
+ Johannes Schindelin <Johannes.Schindelin@gmx.de>
+ Rutger Nijlunsing <git@wingding.demon.nl>
+ Matthieu Moy <Matthieu.Moy@imag.fr>
diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt
new file mode 100644
index 0000000000..88765b5575
--- /dev/null
+++ b/Documentation/howto/update-hook-example.txt
@@ -0,0 +1,172 @@
+From: Junio C Hamano <junkio@cox.net> and Carl Baldwin <cnb@fc.hp.com>
+Subject: control access to branches.
+Date: Thu, 17 Nov 2005 23:55:32 -0800
+Message-ID: <7vfypumlu3.fsf@assigned-by-dhcp.cox.net>
+Abstract: An example hooks/update script is presented to
+ implement repository maintenance policies, such as who can push
+ into which branch and who can make a tag.
+
+When your developer runs git-push into the repository,
+git-receive-pack is run (either locally or over ssh) as that
+developer, so is hooks/update script. Quoting from the relevant
+section of the documentation:
+
+ Before each ref is updated, if $GIT_DIR/hooks/update file exists
+ and executable, it is called with three parameters:
+
+ $GIT_DIR/hooks/update refname sha1-old sha1-new
+
+ The refname parameter is relative to $GIT_DIR; e.g. for the
+ master head this is "refs/heads/master". Two sha1 are the
+ object names for the refname before and after the update. Note
+ that the hook is called before the refname is updated, so either
+ sha1-old is 0{40} (meaning there is no such ref yet), or it
+ should match what is recorded in refname.
+
+So if your policy is (1) always require fast-forward push
+(i.e. never allow "git-push repo +branch:branch"), (2) you
+have a list of users allowed to update each branch, and (3) you
+do not let tags to be overwritten, then you can use something
+like this as your hooks/update script.
+
+[jc: editorial note. This is a much improved version by Carl
+since I posted the original outline]
+
+-- >8 -- beginning of script -- >8 --
+
+#!/bin/bash
+
+umask 002
+
+# If you are having trouble with this access control hook script
+# you can try setting this to true. It will tell you exactly
+# why a user is being allowed/denied access.
+
+verbose=false
+
+# Default shell globbing messes things up downstream
+GLOBIGNORE=*
+
+function grant {
+ $verbose && echo >&2 "-Grant- $1"
+ echo grant
+ exit 0
+}
+
+function deny {
+ $verbose && echo >&2 "-Deny- $1"
+ echo deny
+ exit 1
+}
+
+function info {
+ $verbose && echo >&2 "-Info- $1"
+}
+
+# Implement generic branch and tag policies.
+# - Tags should not be updated once created.
+# - Branches should only be fast-forwarded.
+case "$1" in
+ refs/tags/*)
+ [ -f "$GIT_DIR/$1" ] &&
+ deny >/dev/null "You can't overwrite an existing tag"
+ ;;
+ refs/heads/*)
+ # No rebasing or rewinding
+ if expr "$2" : '0*$' >/dev/null; then
+ info "The branch '$1' is new..."
+ else
+ # updating -- make sure it is a fast forward
+ mb=$(git-merge-base "$2" "$3")
+ case "$mb,$2" in
+ "$2,$mb") info "Update is fast-forward" ;;
+ *) deny >/dev/null "This is not a fast-forward update." ;;
+ esac
+ fi
+ ;;
+ *)
+ deny >/dev/null \
+ "Branch is not under refs/heads or refs/tags. What are you trying to do?"
+ ;;
+esac
+
+# Implement per-branch controls based on username
+allowed_users_file=$GIT_DIR/info/allowed-users
+username=$(id -u -n)
+info "The user is: '$username'"
+
+if [ -f "$allowed_users_file" ]; then
+ rc=$(cat $allowed_users_file | grep -v '^#' | grep -v '^$' |
+ while read head_pattern user_patterns; do
+ matchlen=$(expr "$1" : "$head_pattern")
+ if [ "$matchlen" == "${#1}" ]; then
+ info "Found matching head pattern: '$head_pattern'"
+ for user_pattern in $user_patterns; do
+ info "Checking user: '$username' against pattern: '$user_pattern'"
+ matchlen=$(expr "$username" : "$user_pattern")
+ if [ "$matchlen" == "${#username}" ]; then
+ grant "Allowing user: '$username' with pattern: '$user_pattern'"
+ fi
+ done
+ deny "The user is not in the access list for this branch"
+ fi
+ done
+ )
+ case "$rc" in
+ grant) grant >/dev/null "Granting access based on $allowed_users_file" ;;
+ deny) deny >/dev/null "Denying access based on $allowed_users_file" ;;
+ *) ;;
+ esac
+fi
+
+allowed_groups_file=$GIT_DIR/info/allowed-groups
+groups=$(id -G -n)
+info "The user belongs to the following groups:"
+info "'$groups'"
+
+if [ -f "$allowed_groups_file" ]; then
+ rc=$(cat $allowed_groups_file | grep -v '^#' | grep -v '^$' |
+ while read head_pattern group_patterns; do
+ matchlen=$(expr "$1" : "$head_pattern")
+ if [ "$matchlen" == "${#1}" ]; then
+ info "Found matching head pattern: '$head_pattern'"
+ for group_pattern in $group_patterns; do
+ for groupname in $groups; do
+ info "Checking group: '$groupname' against pattern: '$group_pattern'"
+ matchlen=$(expr "$groupname" : "$group_pattern")
+ if [ "$matchlen" == "${#groupname}" ]; then
+ grant "Allowing group: '$groupname' with pattern: '$group_pattern'"
+ fi
+ done
+ done
+ deny "None of the user's groups are in the access list for this branch"
+ fi
+ done
+ )
+ case "$rc" in
+ grant) grant >/dev/null "Granting access based on $allowed_groups_file" ;;
+ deny) deny >/dev/null "Denying access based on $allowed_groups_file" ;;
+ *) ;;
+ esac
+fi
+
+deny >/dev/null "There are no more rules to check. Denying access"
+
+-- >8 -- end of script -- >8 --
+
+This uses two files, $GIT_DIR/info/allowed-users and
+allowed-groups, to describe which heads can be pushed into by
+whom. The format of each file would look like this:
+
+ refs/heads/master junio
+ refs/heads/cogito$ pasky
+ refs/heads/bw/.* linus
+ refs/heads/tmp/.* .*
+ refs/tags/v[0-9].* junio
+
+With this, Linus can push or create "bw/penguin" or "bw/zebra"
+or "bw/panda" branches, Pasky can do only "cogito", and JC can
+do master branch and make versioned tags. And anybody can do
+tmp/blah branches.
+
+------------
diff --git a/Documentation/howto/use-git-daemon.txt b/Documentation/howto/use-git-daemon.txt
new file mode 100644
index 0000000000..4e2f75cb61
--- /dev/null
+++ b/Documentation/howto/use-git-daemon.txt
@@ -0,0 +1,51 @@
+How to use git-daemon
+
+Git can be run in inetd mode and in stand alone mode. But all you want is
+let a coworker pull from you, and therefore need to set up a git server
+real quick, right?
+
+Note that git-daemon is not really chatty at the moment, especially when
+things do not go according to plan (e.g. a socket could not be bound).
+
+Another word of warning: if you run
+
+ $ git ls-remote git://127.0.0.1/rule-the-world.git
+
+and you see a message like
+
+ fatal: The remote end hung up unexpectedly
+
+it only means that _something_ went wrong. To find out _what_ went wrong,
+you have to ask the server. (Git refuses to be more precise for your
+security only. Take off your shoes now. You have any coins in your pockets?
+Sorry, not allowed -- who knows what you planned to do with them?)
+
+With these two caveats, let's see an example:
+
+ $ git daemon --reuseaddr --verbose --base-path=/home/gitte/git \
+ --export-all -- /home/gitte/git/rule-the-world.git
+
+(Of course, unless your user name is `gitte` _and_ your repository is in
+~/rule-the-world.git, you have to adjust the paths. If your repository is
+not bare, be aware that you have to type the path to the .git directory!)
+
+This invocation tries to reuse the address if it is already taken
+(this can save you some debugging, because otherwise killing and restarting
+git-daemon could just silently fail to bind to a socket).
+
+Also, it is (relatively) verbose when somebody actually connects to it.
+It also sets the base path, which means that all the projects which can be
+accessed using this daemon have to reside in or under that path.
+
+The option `--export-all` just means that you _don't_ have to create a
+file named `git-daemon-export-ok` in each exported repository. (Otherwise,
+git-daemon would complain loudly, and refuse to cooperate.)
+
+Last of all, the repository which should be exported is specified. It is
+a good practice to put the paths after a "--" separator.
+
+Now, test your daemon with
+
+ $ git ls-remote git://127.0.0.1/rule-the-world.git
+
+If this does not work, find out why, and submit a patch to this document.
diff --git a/Documentation/howto/using-merge-subtree.txt b/Documentation/howto/using-merge-subtree.txt
new file mode 100644
index 0000000000..0953a50b69
--- /dev/null
+++ b/Documentation/howto/using-merge-subtree.txt
@@ -0,0 +1,75 @@
+Date: Sat, 5 Jan 2008 20:17:40 -0500
+From: Sean <seanlkml@sympatico.ca>
+To: Miklos Vajna <vmiklos@frugalware.org>
+Cc: git@vger.kernel.org
+Subject: how to use git merge -s subtree?
+Abstract: In this article, Sean demonstrates how one can use the subtree merge
+ strategy.
+Content-type: text/asciidoc
+Message-ID: <BAYC1-PASMTP12374B54BA370A1E1C6E78AE4E0@CEZ.ICE>
+
+How to use the subtree merge strategy
+=====================================
+
+There are situations where you want to include contents in your project
+from an independently developed project. You can just pull from the
+other project as long as there are no conflicting paths.
+
+The problematic case is when there are conflicting files. Potential
+candidates are Makefiles and other standard filenames. You could merge
+these files but probably you do not want to. A better solution for this
+problem can be to merge the project as its own subdirectory. This is not
+supported by the 'recursive' merge strategy, so just pulling won't work.
+
+What you want is the 'subtree' merge strategy, which helps you in such a
+situation.
+
+In this example, let's say you have the repository at `/path/to/B` (but
+it can be an URL as well, if you want). You want to merge the 'master'
+branch of that repository to the `dir-B` subdirectory in your current
+branch.
+
+Here is the command sequence you need:
+
+----------------
+$ git remote add -f Bproject /path/to/B <1>
+$ git merge -s ours --no-commit Bproject/master <2>
+$ git read-tree --prefix=dir-B/ -u Bproject/master <3>
+$ git commit -m "Merge B project as our subdirectory" <4>
+
+$ git pull -s subtree Bproject master <5>
+----------------
+<1> name the other project "Bproject", and fetch.
+<2> prepare for the later step to record the result as a merge.
+<3> read "master" branch of Bproject to the subdirectory "dir-B".
+<4> record the merge result.
+<5> maintain the result with subsequent merges using "subtree"
+
+The first four commands are used for the initial merge, while the last
+one is to merge updates from 'B project'.
+
+Comparing 'subtree' merge with submodules
+-----------------------------------------
+
+- The benefit of using subtree merge is that it requires less
+ administrative burden from the users of your repository. It works with
+ older (before Git v1.5.2) clients and you have the code right after
+ clone.
+
+- However if you use submodules then you can choose not to transfer the
+ submodule objects. This may be a problem with the subtree merge.
+
+- Also, in case you make changes to the other project, it is easier to
+ submit changes if you just use submodules.
+
+Additional tips
+---------------
+
+- If you made changes to the other project in your repository, they may
+ want to merge from your project. This is possible using subtree -- it
+ can shift up the paths in your tree and then they can merge only the
+ relevant parts of your tree.
+
+- Please note that if the other project merges from you, then it will
+ connects its history to yours, which can be something they don't want
+ to.
diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt
new file mode 100644
index 0000000000..1e188e6e74
--- /dev/null
+++ b/Documentation/i18n.txt
@@ -0,0 +1,57 @@
+At the core level, git is character encoding agnostic.
+
+ - The pathnames recorded in the index and in the tree objects
+ are treated as uninterpreted sequences of non-NUL bytes.
+ What readdir(2) returns are what are recorded and compared
+ with the data git keeps track of, which in turn are expected
+ to be what lstat(2) and creat(2) accepts. There is no such
+ thing as pathname encoding translation.
+
+ - The contents of the blob objects are uninterpreted sequence
+ of bytes. There is no encoding translation at the core
+ level.
+
+ - The commit log messages are uninterpreted sequence of non-NUL
+ bytes.
+
+Although we encourage that the commit log messages are encoded
+in UTF-8, both the core and git Porcelain are designed not to
+force UTF-8 on projects. If all participants of a particular
+project find it more convenient to use legacy encodings, git
+does not forbid it. However, there are a few things to keep in
+mind.
+
+. `git-commit-tree` (hence, `git-commit` which uses it) issues
+ a warning if the commit log message given to it does not look
+ like a valid UTF-8 string, unless you explicitly say your
+ project uses a legacy encoding. The way to say this is to
+ have i18n.commitencoding in `.git/config` file, like this:
++
+------------
+[i18n]
+ commitencoding = ISO-8859-1
+------------
++
+Commit objects created with the above setting record the value
+of `i18n.commitencoding` in its `encoding` header. This is to
+help other people who look at them later. Lack of this header
+implies that the commit log message is encoded in UTF-8.
+
+. `git-log`, `git-show` and friends looks at the `encoding`
+ header of a commit object, and tries to re-code the log
+ message into UTF-8 unless otherwise specified. You can
+ specify the desired output encoding with
+ `i18n.logoutputencoding` in `.git/config` file, like this:
++
+------------
+[i18n]
+ logoutputencoding = ISO-8859-1
+------------
++
+If you do not have this configuration variable, the value of
+`i18n.commitencoding` is used instead.
+
+Note that we deliberately chose not to re-code the commit log
+message when a commit is made to force UTF-8 at the commit
+object level, because re-coding to UTF-8 is not necessarily a
+reversible operation.
diff --git a/Documentation/install-doc-quick.sh b/Documentation/install-doc-quick.sh
new file mode 100755
index 0000000000..5433cf8ced
--- /dev/null
+++ b/Documentation/install-doc-quick.sh
@@ -0,0 +1,31 @@
+#!/bin/sh
+# This requires a branch named in $head
+# (usually 'man' or 'html', provided by the git.git repository)
+set -e
+head="$1"
+mandir="$2"
+SUBDIRECTORY_OK=t
+USAGE='<refname> <target directory>'
+. git-sh-setup
+cd_to_toplevel
+
+test -z "$mandir" && usage
+if ! git rev-parse --verify "$head^0" >/dev/null; then
+ echo >&2 "head: $head does not exist in the current repository"
+ usage
+fi
+
+GIT_INDEX_FILE=`pwd`/.quick-doc.index
+export GIT_INDEX_FILE
+rm -f "$GIT_INDEX_FILE"
+trap 'rm -f "$GIT_INDEX_FILE"' 0
+
+git read-tree $head
+git checkout-index -a -f --prefix="$mandir"/
+
+if test -n "$GZ"; then
+ git ls-tree -r --name-only $head |
+ xargs printf "$mandir/%s\n" |
+ xargs gzip -f
+fi
+rm -f "$GIT_INDEX_FILE"
diff --git a/Documentation/install-webdoc.sh b/Documentation/install-webdoc.sh
new file mode 100755
index 0000000000..2135a8ee1f
--- /dev/null
+++ b/Documentation/install-webdoc.sh
@@ -0,0 +1,39 @@
+#!/bin/sh
+
+T="$1"
+
+for h in \
+ *.txt *.html \
+ howto/*.txt howto/*.html \
+ technical/*.txt technical/*.html \
+ RelNotes-*.txt *.css
+do
+ if test ! -f "$h"
+ then
+ : did not match
+ elif test -f "$T/$h" &&
+ diff -u -I'Last updated [0-9][0-9]-[A-Z][a-z][a-z]-' "$T/$h" "$h"
+ then
+ :; # up to date
+ else
+ echo >&2 "# install $h $T/$h"
+ rm -f "$T/$h"
+ mkdir -p `dirname "$T/$h"`
+ cp "$h" "$T/$h"
+ fi
+done
+strip_leading=`echo "$T/" | sed -e 's|.|.|g'`
+for th in \
+ "$T"/*.html "$T"/*.txt \
+ "$T"/howto/*.txt "$T"/howto/*.html \
+ "$T"/technical/*.txt "$T"/technical/*.html
+do
+ h=`expr "$th" : "$strip_leading"'\(.*\)'`
+ case "$h" in
+ index.html) continue ;;
+ esac
+ test -f "$h" && continue
+ echo >&2 "# rm -f $th"
+ rm -f "$th"
+done
+ln -sf git.html "$T/index.html"
diff --git a/Documentation/manpage-1.72.xsl b/Documentation/manpage-1.72.xsl
new file mode 100644
index 0000000000..4065a3a27a
--- /dev/null
+++ b/Documentation/manpage-1.72.xsl
@@ -0,0 +1,21 @@
+<!-- Based on callouts.xsl. Fixes man page callouts for DocBook 1.72 XSL -->
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
+
+<xsl:param name="man.output.quietly" select="1"/>
+<xsl:param name="refentry.meta.get.quietly" select="1"/>
+
+<xsl:template match="co">
+ <xsl:value-of select="concat('&#x2593;fB(',substring-after(@id,'-'),')&#x2593;fR')"/>
+</xsl:template>
+<xsl:template match="calloutlist">
+ <xsl:text>&#x2302;sp&#10;</xsl:text>
+ <xsl:apply-templates/>
+ <xsl:text>&#10;</xsl:text>
+</xsl:template>
+<xsl:template match="callout">
+ <xsl:value-of select="concat('&#x2593;fB',substring-after(@arearefs,'-'),'. &#x2593;fR')"/>
+ <xsl:apply-templates/>
+ <xsl:text>&#x2302;br&#10;</xsl:text>
+</xsl:template>
+
+</xsl:stylesheet>
diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
new file mode 100644
index 0000000000..48ce747cf4
--- /dev/null
+++ b/Documentation/merge-config.txt
@@ -0,0 +1,40 @@
+merge.stat::
+ Whether to print the diffstat berween ORIG_HEAD and merge result
+ at the end of the merge. True by default.
+
+merge.log::
+ Whether to include summaries of merged commits in newly created
+ merge commit messages. False by default.
+
+merge.renameLimit::
+ The number of files to consider when performing rename detection
+ during a merge; if not specified, defaults to the value of
+ diff.renameLimit.
+
+merge.tool::
+ Controls which merge resolution program is used by
+ linkgit:git-mergetool[1]. Valid built-in values are: "kdiff3",
+ "tkdiff", "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", and
+ "opendiff". Any other value is treated is custom merge tool
+ and there must be a corresponing mergetool.<tool>.cmd option.
+
+merge.verbosity::
+ Controls the amount of output shown by the recursive merge
+ strategy. Level 0 outputs nothing except a final error
+ message if conflicts were detected. Level 1 outputs only
+ conflicts, 2 outputs conflicts and file changes. Level 5 and
+ above outputs debugging information. The default is level 2.
+ Can be overridden by 'GIT_MERGE_VERBOSITY' environment variable.
+
+merge.<driver>.name::
+ Defines a human readable name for a custom low-level
+ merge driver. See linkgit:gitattributes[5] for details.
+
+merge.<driver>.driver::
+ Defines the command that implements a custom low-level
+ merge driver. See linkgit:gitattributes[5] for details.
+
+merge.<driver>.recursive::
+ Names a low-level merge driver to be used when
+ performing an internal merge between common ancestors.
+ See linkgit:gitattributes[5] for details.
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
new file mode 100644
index 0000000000..ffbc6e9861
--- /dev/null
+++ b/Documentation/merge-options.txt
@@ -0,0 +1,60 @@
+--stat::
+ Show a diffstat at the end of the merge. The diffstat is also
+ controlled by the configuration option merge.stat.
+
+-n::
+--no-stat::
+ Do not show diffstat at the end of the merge.
+
+--summary::
+--no-summary::
+ Synonyms to --stat and --no-stat; these are deprecated and will be
+ removed in the future.
+
+--log::
+ In addition to branch names, populate the log message with
+ one-line descriptions from the actual commits that are being
+ merged.
+
+--no-log::
+ Do not list one-line descriptions from the actual commits being
+ merged.
+
+--no-commit::
+ Perform the merge but pretend the merge failed and do
+ not autocommit, to give the user a chance to inspect and
+ further tweak the merge result before committing.
+
+--commit::
+ Perform the merge and commit the result. This option can
+ be used to override --no-commit.
+
+--squash::
+ Produce the working tree and index state as if a real
+ merge happened, but do not actually make a commit or
+ move the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to
+ cause the next `git commit` command to create a merge
+ commit. This allows you to create a single commit on
+ top of the current branch whose effect is the same as
+ merging another branch (or more in case of an octopus).
+
+--no-squash::
+ Perform the merge and commit the result. This option can
+ be used to override --squash.
+
+--no-ff::
+ Generate a merge commit even if the merge resolved as a
+ fast-forward.
+
+--ff::
+ Do not generate a merge commit if the merge resolved as
+ a fast-forward, only update the branch pointer. This is
+ the default behavior of git-merge.
+
+-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).
diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
new file mode 100644
index 0000000000..1276f858ad
--- /dev/null
+++ b/Documentation/merge-strategies.txt
@@ -0,0 +1,42 @@
+MERGE STRATEGIES
+----------------
+
+resolve::
+ This can only resolve two heads (i.e. the current branch
+ and another branch you pulled from) using 3-way merge
+ algorithm. It tries to carefully detect criss-cross
+ merge ambiguities and is considered generally safe and
+ fast.
+
+recursive::
+ This can only resolve two heads using 3-way merge
+ algorithm. When there are more than one common
+ ancestors that can be used for 3-way merge, it creates a
+ merged tree of the common ancestors and uses that as
+ the reference tree for the 3-way merge. This has been
+ reported to result in fewer merge conflicts without
+ causing mis-merges by tests done on actual merge commits
+ taken from Linux 2.6 kernel development history.
+ Additionally this can detect and handle merges involving
+ renames. This is the default merge strategy when
+ pulling or merging one branch.
+
+octopus::
+ This resolves more than two-head case, but refuses to do
+ complex merge that needs manual resolution. It is
+ primarily meant to be used for bundling topic branch
+ heads together. This is the default merge strategy when
+ pulling or merging more than one branches.
+
+ours::
+ This resolves any number of heads, but the result of the
+ merge is always the current branch head. It is meant to
+ be used to supersede old development history of side
+ branches.
+
+subtree::
+ This is a modified recursive strategy. When merging trees A and
+ B, if B corresponds to a subtree of A, B is first adjusted to
+ match the tree structure of A, instead of reading the trees at
+ the same level. This adjustment is also done to the common
+ ancestor tree.
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
new file mode 100644
index 0000000000..e8bea3e18e
--- /dev/null
+++ b/Documentation/pretty-formats.txt
@@ -0,0 +1,126 @@
+PRETTY FORMATS
+--------------
+
+If the commit is a merge, and if the pretty-format
+is not 'oneline', 'email' or 'raw', an additional line is
+inserted before the 'Author:' line. This line begins with
+"Merge: " and the sha1s of ancestral commits are printed,
+separated by spaces. Note that the listed commits may not
+necessarily be the list of the *direct* parent commits if you
+have limited your view of history: for example, if you are
+only interested in changes related to a certain directory or
+file.
+
+Here are some additional details for each format:
+
+* 'oneline'
+
+ <sha1> <title line>
++
+This is designed to be as compact as possible.
+
+* 'short'
+
+ commit <sha1>
+ Author: <author>
+
+ <title line>
+
+* 'medium'
+
+ commit <sha1>
+ Author: <author>
+ Date: <date>
+
+ <title line>
+
+ <full commit message>
+
+* 'full'
+
+ commit <sha1>
+ Author: <author>
+ Commit: <committer>
+
+ <title line>
+
+ <full commit message>
+
+* 'fuller'
+
+ commit <sha1>
+ Author: <author>
+ AuthorDate: <date & time>
+ Commit: <committer>
+ CommitDate: <date & time>
+
+ <title line>
+
+ <full commit message>
+
+* 'email'
+
+ From <sha1> <date>
+ From: <author>
+ Date: <date & time>
+ Subject: [PATCH] <title line>
+
+ <full commit message>
+
+* 'raw'
++
+The 'raw' format shows the entire commit exactly as
+stored in the commit object. Notably, the SHA1s are
+displayed in full, regardless of whether --abbrev or
+--no-abbrev are used, and 'parents' information show the
+true parent commits, without taking grafts nor history
+simplification into account.
+
+* 'format:'
++
+The 'format:' format allows you to specify which information
+you want to show. It works a little bit like printf format,
+with the notable exception that you get a newline with '%n'
+instead of '\n'.
++
+E.g, 'format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"'
+would show something like this:
++
+-------
+The author of fe6e0ee was Junio C Hamano, 23 hours ago
+The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
+
+--------
++
+The placeholders are:
+
+- '%H': commit hash
+- '%h': abbreviated commit hash
+- '%T': tree hash
+- '%t': abbreviated tree hash
+- '%P': parent hashes
+- '%p': abbreviated parent hashes
+- '%an': author name
+- '%ae': author email
+- '%ad': author date
+- '%aD': author date, RFC2822 style
+- '%ar': author date, relative
+- '%at': author date, UNIX timestamp
+- '%ai': author date, ISO 8601 format
+- '%cn': committer name
+- '%ce': committer email
+- '%cd': committer date
+- '%cD': committer date, RFC2822 style
+- '%cr': committer date, relative
+- '%ct': committer date, UNIX timestamp
+- '%ci': committer date, ISO 8601 format
+- '%e': encoding
+- '%s': subject
+- '%b': body
+- '%Cred': switch color to red
+- '%Cgreen': switch color to green
+- '%Cblue': switch color to blue
+- '%Creset': reset color
+- '%m': left, right or boundary mark
+- '%n': newline
+- '%x00': print a byte from a hex code
diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt
new file mode 100644
index 0000000000..6d66c74cc1
--- /dev/null
+++ b/Documentation/pretty-options.txt
@@ -0,0 +1,25 @@
+--pretty[='<format>']::
+
+ Pretty-print the contents of the commit logs in a given format,
+ where '<format>' can be one of 'oneline', 'short', 'medium',
+ 'full', 'fuller', 'email', 'raw' and 'format:<string>'.
+ When omitted, the format defaults to 'medium'.
++
+Note: you can specify the default pretty format in the repository
+configuration (see linkgit:git-config[1]).
+
+--abbrev-commit::
+ Instead of showing the full 40-byte hexadecimal commit object
+ name, show only handful hexdigits prefix. Non default number of
+ digits can be specified with "--abbrev=<n>" (which also modifies
+ diff output, if it is displayed).
++
+This should make "--pretty=oneline" a whole lot more readable for
+people using 80-column terminals.
+
+--encoding[=<encoding>]::
+ The commit objects record the encoding used for the log message
+ in their encoding header; this option can be used to tell the
+ command to re-code the commit log message in the encoding
+ preferred by the user. For non plumbing commands this
+ defaults to UTF-8.
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
new file mode 100644
index 0000000000..cbee369947
--- /dev/null
+++ b/Documentation/pull-fetch-param.txt
@@ -0,0 +1,67 @@
+<repository>::
+ The "remote" repository that is the source of a fetch
+ or pull operation. This parameter can be either a URL
+ (see the section <<URLS,GIT URLS>> below) or the name
+ of a remote (see the section <<REMOTES,REMOTES>> 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 remote ref that matches <src>
+is fetched, and if <dst> is not empty string, the local
+ref that matches it is fast forwarded using <src>.
+Again, if the optional plus `+` is used, the local ref
+is updated even if it does not result in a fast forward
+update.
++
+[NOTE]
+If the remote branch from which you want to pull is
+modified in non-linear ways such as being rewound and
+rebased frequently, then a pull will attempt a merge with
+an older version of itself, likely conflict, and fail.
+It is under these conditions that you would want to use
+the `+` sign to indicate non-fast-forward updates will
+be needed. There is currently no easy way to determine
+or declare that a branch will be made available in a
+repository with this behavior; the pulling user simply
+must know this is the expected usage pattern for a branch.
++
+[NOTE]
+You never do your own development on branches that appear
+on the right hand side of a <refspec> colon on `Pull:` lines;
+they are to be updated by `git-fetch`. If you intend to do
+development derived from a remote branch `B`, have a `Pull:`
+line to track it (i.e. `Pull: B:remote-B`), and have a separate
+branch `my-B` to do your development on top of it. The latter
+is created by `git branch my-B remote-B` (or its equivalent `git
+checkout -b my-B remote-B`). Run `git fetch` to keep track of
+the progress of the remote side, and when you see something new
+on the remote branch, merge it into your development branch with
+`git pull . remote-B`, while you are on `my-B` branch.
++
+[NOTE]
+There is a difference between listing multiple <refspec>
+directly on `git-pull` command line and having multiple
+`Pull:` <refspec> lines for a <repository> and running
+`git-pull` command without any explicit <refspec> parameters.
+<refspec> listed explicitly on the command line are always
+merged into the current branch after fetching. In other words,
+if you list more than one remote refs, you would be making
+an Octopus. While `git-pull` run without any explicit <refspec>
+parameter takes default <refspec>s from `Pull:` lines, it
+merges only the first <refspec> found into the current branch,
+after fetching all the remote refs. This is because making an
+Octopus from remote refs is rarely done, while keeping track
+of multiple remote heads in one-go by fetching more than one
+is often useful.
++
+Some short-cut notations are also supported.
++
+* `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`;
+ it requests fetching everything up to the given tag.
+* A parameter <ref> without a colon is equivalent to
+ <ref>: when pulling/fetching, so it merges <ref> into the current
+ branch without storing the remote branch anywhere locally
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
new file mode 100644
index 0000000000..37dd1d61ea
--- /dev/null
+++ b/Documentation/rev-list-options.txt
@@ -0,0 +1,395 @@
+Commit Formatting
+~~~~~~~~~~~~~~~~~
+
+ifdef::git-rev-list[]
+Using these options, linkgit:git-rev-list[1] will act similar to the
+more specialized family of commit log tools: linkgit:git-log[1],
+linkgit:git-show[1], and linkgit:git-whatchanged[1]
+endif::git-rev-list[]
+
+include::pretty-options.txt[]
+
+--relative-date::
+
+ Synonym for `--date=relative`.
+
+--date={relative,local,default,iso,rfc,short}::
+
+ Only takes effect for dates shown in human-readable format, such
+ as when using "--pretty". `log.date` config variable sets a default
+ value for log command's --date option.
++
+`--date=relative` shows dates relative to the current time,
+e.g. "2 hours ago".
++
+`--date=local` shows timestamps in user's local timezone.
++
+`--date=iso` (or `--date=iso8601`) shows timestamps in ISO 8601 format.
++
+`--date=rfc` (or `--date=rfc2822`) shows timestamps in RFC 2822
+format, often found in E-mail messages.
++
+`--date=short` shows only date but not time, in `YYYY-MM-DD` format.
++
+`--date=default` shows timestamps in the original timezone
+(either committer's or author's).
+
+ifdef::git-rev-list[]
+--header::
+
+ Print the contents of the commit in raw-format; each record is
+ separated with a NUL character.
+endif::git-rev-list[]
+
+--parents::
+
+ Print the parents of the commit.
+
+ifdef::git-rev-list[]
+--timestamp::
+ Print the raw commit timestamp.
+endif::git-rev-list[]
+
+--left-right::
+
+ Mark which side of a symmetric diff a commit is reachable from.
+ Commits from the left side are prefixed with `<` and those from
+ the right with `>`. If combined with `--boundary`, those
+ commits are prefixed with `-`.
++
+For example, if you have this topology:
++
+-----------------------------------------------------------------------
+ y---b---b branch B
+ / \ /
+ / .
+ / / \
+ o---x---a---a branch A
+-----------------------------------------------------------------------
++
+you would get an output line this:
++
+-----------------------------------------------------------------------
+ $ git rev-list --left-right --boundary --pretty=oneline A...B
+
+ >bbbbbbb... 3rd on b
+ >bbbbbbb... 2nd on b
+ <aaaaaaa... 3rd on a
+ <aaaaaaa... 2nd on a
+ -yyyyyyy... 1st on b
+ -xxxxxxx... 1st on a
+-----------------------------------------------------------------------
+
+--graph::
+
+ Draw a text-based graphical representation of the commit history
+ on the left hand side of the output. This may cause extra lines
+ to be printed in between commits, in order for the graph history
+ to be drawn properly.
++
+This implies the '--topo-order' option by default, but the
+'--date-order' option may also be specified.
+
+Diff Formatting
+~~~~~~~~~~~~~~~
+
+Below are listed options that control the formatting of diff output.
+Some of them are specific to linkgit:git-rev-list[1], however other diff
+options may be given. See linkgit:git-diff-files[1] for more options.
+
+-c::
+
+ This flag changes the way a merge commit is displayed. 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. Furthermore, it lists only files
+ which were modified from all parents.
+
+--cc::
+
+ This flag implies the '-c' 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.
+
+-r::
+
+ Show recursive diffs.
+
+-t::
+
+ Show the tree objects in the diff output. This implies '-r'.
+
+Commit Limiting
+~~~~~~~~~~~~~~~
+
+Besides specifying a range of commits that should be listed using the
+special notations explained in the description, additional commit
+limiting may be applied.
+
+--
+
+-n 'number'::
+--max-count='number'::
+
+ Limit the number of commits output.
+
+--skip='number'::
+
+ Skip 'number' commits before starting to show the commit output.
+
+--since='date'::
+--after='date'::
+
+ Show commits more recent than a specific date.
+
+--until='date'::
+--before='date'::
+
+ Show commits older than a specific date.
+
+ifdef::git-rev-list[]
+--max-age='timestamp'::
+--min-age='timestamp'::
+
+ Limit the commits output to specified time range.
+endif::git-rev-list[]
+
+--author='pattern'::
+--committer='pattern'::
+
+ Limit the commits output to ones with author/committer
+ header lines that match the specified pattern (regular expression).
+
+--grep='pattern'::
+
+ Limit the commits output to ones with log message that
+ matches the specified pattern (regular expression).
+
+-i::
+--regexp-ignore-case::
+
+ Match the regexp limiting patterns without regard to letters case.
+
+-E::
+--extended-regexp::
+
+ Consider the limiting patterns to be extended regular expressions
+ instead of the default basic regular expressions.
+
+-F::
+--fixed-strings::
+
+ Consider the limiting patterns to be fixed strings (don't interpret
+ pattern as a regular expression).
+
+--remove-empty::
+
+ Stop when a given path disappears from the tree.
+
+--full-history::
+
+ Show also parts of history irrelevant to current state of a given
+ path. This turns off history simplification, which removed merges
+ which didn't change anything at all at some child. It will still actually
+ simplify away merges that didn't change anything at all into either
+ child.
+
+--no-merges::
+
+ Do not print commits with more than one parent.
+
+--first-parent::
+ Follow only the first parent commit upon seeing a merge
+ commit. This option can give a better overview when
+ viewing the evolution of a particular topic branch,
+ because merges into a topic branch tend to be only about
+ adjusting to updated upstream from time to time, and
+ this option allows you to ignore the individual commits
+ brought in to your history by such a merge.
+
+--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>'.
+
+ifdef::git-rev-list[]
+--stdin::
+
+ In addition to the '<commit>' listed on the command
+ line, read them from the standard input.
+
+--quiet::
+
+ Don't print anything to standard output. This form
+ is primarily meant to allow the caller to
+ test the exit status to see if a range of objects is fully
+ connected (or not). It is faster than redirecting stdout
+ to /dev/null as the output does not have to be formatted.
+endif::git-rev-list[]
+
+--cherry-pick::
+
+ Omit any commit that introduces the same change as
+ another commit on the "other side" when the set of
+ commits are limited with symmetric difference.
++
+For example, if you have two branches, `A` and `B`, a usual way
+to list all commits on only one side of them is with
+`--left-right`, like the example above in the description of
+that option. It however shows the commits that were cherry-picked
+from the other branch (for example, "3rd on b" may be cherry-picked
+from branch A). With this option, such pairs of commits are
+excluded from the output.
+
+-g::
+--walk-reflogs::
+
+ Instead of walking the commit ancestry chain, walk
+ reflog entries from the most recent one to older ones.
+ When this option is used you cannot specify commits to
+ exclude (that is, '{caret}commit', 'commit1..commit2',
+ nor 'commit1...commit2' notations cannot be used).
++
+With '\--pretty' format other than oneline (for obvious reasons),
+this causes the output to have two extra lines of information
+taken from the reflog. By default, 'commit@\{Nth}' notation is
+used in the output. When the starting commit is specified as
+'commit@{now}', output also uses 'commit@\{timestamp}' notation
+instead. Under '\--pretty=oneline', the commit message is
+prefixed with this information on the same line.
+
+Cannot be combined with '\--reverse'.
+See also linkgit:git-reflog[1].
+
+--merge::
+
+ After a failed merge, show refs that touch files having a
+ conflict and don't exist on all heads to merge.
+
+--boundary::
+
+ Output uninteresting commits at the boundary, which are usually
+ not shown.
+
+--dense::
+--sparse::
+
+When optional paths are given, the default behaviour ('--dense') is to
+only output commits that changes at least one of them, and also ignore
+merges that do not touch the given paths.
+
+Use the '--sparse' flag to makes the command output all eligible commits
+(still subject to count and age limitation), but apply merge
+simplification nevertheless.
+
+ifdef::git-rev-list[]
+--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 of the two commands
+
+-----------------------------------------------------------------------
+ $ git-rev-list foo ^midpoint
+ $ git-rev-list midpoint ^bar ^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.
+
+--bisect-vars::
+
+This calculates the same as `--bisect`, but outputs text ready
+to be eval'ed by the shell. These lines will assign the name of
+the midpoint revision to the variable `bisect_rev`, and the
+expected number of commits to be tested after `bisect_rev` is
+tested to `bisect_nr`, the expected number of commits to be
+tested if `bisect_rev` turns out to be good to `bisect_good`,
+the expected number of commits to be tested if `bisect_rev`
+turns out to be bad to `bisect_bad`, and the number of commits
+we are bisecting right now to `bisect_all`.
+
+--bisect-all::
+
+This outputs all the commit objects between the included and excluded
+commits, ordered by their distance to the included and excluded
+commits. The farthest from them is displayed first. (This is the only
+one displayed by `--bisect`.)
+
+This is useful because it makes it easy to choose a good commit to
+test when you want to avoid to test some of them for some reason (they
+may not compile for example).
+
+This option can be used along with `--bisect-vars`, in this case,
+after all the sorted commit objects, there will be the same text as if
+`--bisect-vars` had been used alone.
+endif::git-rev-list[]
+
+--
+
+Commit Ordering
+~~~~~~~~~~~~~~~
+
+By default, the commits are shown in reverse chronological order.
+
+--topo-order::
+
+ This option makes them appear in topological order (i.e.
+ descendant commits are shown before their parents).
+
+--date-order::
+
+ This option is similar to '--topo-order' in the sense that no
+ parent comes before all of its children, but otherwise things
+ are still ordered in the commit timestamp order.
+
+--reverse::
+
+ Output the commits in reverse order.
+ Cannot be combined with '\--walk-reflogs'.
+
+Object Traversal
+~~~~~~~~~~~~~~~~
+
+These options are mostly targeted for packing of git repositories.
+
+--objects::
+
+ Print the object IDs of any object referenced by the listed
+ commits. '--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
+ linkgit:git-pack-objects[1] 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.
+
+--no-walk::
+
+ Only show the given revs, but do not traverse their ancestors.
+
+--do-walk::
+
+ Overrides a previous --no-walk.
diff --git a/Documentation/technical/.gitignore b/Documentation/technical/.gitignore
new file mode 100644
index 0000000000..8aa891daee
--- /dev/null
+++ b/Documentation/technical/.gitignore
@@ -0,0 +1 @@
+api-index.txt
diff --git a/Documentation/technical/api-allocation-growing.txt b/Documentation/technical/api-allocation-growing.txt
new file mode 100644
index 0000000000..43dbe09f73
--- /dev/null
+++ b/Documentation/technical/api-allocation-growing.txt
@@ -0,0 +1,34 @@
+allocation growing API
+======================
+
+Dynamically growing an array using realloc() is error prone and boring.
+
+Define your array with:
+
+* a pointer (`ary`) that points at the array, initialized to `NULL`;
+
+* an integer variable (`alloc`) that keeps track of how big the current
+ allocation is, initialized to `0`;
+
+* another integer variable (`nr`) to keep track of how many elements the
+ array currently has, initialized to `0`.
+
+Then before adding `n`th element to the array, call `ALLOC_GROW(ary, n,
+alloc)`. This ensures that the array can hold at least `n` elements by
+calling `realloc(3)` and adjusting `alloc` variable.
+
+------------
+sometype *ary;
+size_t nr;
+size_t alloc
+
+for (i = 0; i < nr; i++)
+ if (we like ary[i] already)
+ return;
+
+/* we did not like any existing one, so add one */
+ALLOC_GROW(ary, nr + 1, alloc);
+ary[nr++] = value you like;
+------------
+
+You are responsible for updating the `nr` variable.
diff --git a/Documentation/technical/api-builtin.txt b/Documentation/technical/api-builtin.txt
new file mode 100644
index 0000000000..52cdb4c520
--- /dev/null
+++ b/Documentation/technical/api-builtin.txt
@@ -0,0 +1,63 @@
+builtin API
+===========
+
+Adding a new built-in
+---------------------
+
+There are 4 things to do to add a bulit-in command implementation to
+git:
+
+. Define the implementation of the built-in command `foo` with
+ signature:
+
+ int cmd_foo(int argc, const char **argv, const char *prefix);
+
+. Add the external declaration for the function to `builtin.h`.
+
+. Add the command to `commands[]` table in `handle_internal_command()`,
+ defined in `git.c`. The entry should look like:
+
+ { "foo", cmd_foo, <options> },
+
+ where options is the bitwise-or of:
+
+`RUN_SETUP`::
+
+ Make sure there is a git directory to work on, and if there is a
+ work tree, chdir to the top of it if the command was invoked
+ in a subdirectory. If there is no work tree, no chdir() is
+ done.
+
+`USE_PAGER`::
+
+ If the standard output is connected to a tty, spawn a pager and
+ feed our output to it.
+
+. Add `builtin-foo.o` to `BUILTIN_OBJS` in `Makefile`.
+
+Additionally, if `foo` is a new command, there are 3 more things to do:
+
+. Add tests to `t/` directory.
+
+. Write documentation in `Documentation/git-foo.txt`.
+
+. Add an entry for `git-foo` to the list at the end of
+ `Documentation/cmd-list.perl`.
+
+
+How a built-in is called
+------------------------
+
+The implementation `cmd_foo()` takes three parameters, `argc`, `argv,
+and `prefix`. The first two are similar to what `main()` of a
+standalone command would be called with.
+
+When `RUN_SETUP` is specified in the `commands[]` table, and when you
+were started from a subdirectory of the work tree, `cmd_foo()` is called
+after chdir(2) to the top of the work tree, and `prefix` gets the path
+to the subdirectory the command started from. This allows you to
+convert a user-supplied pathname (typically relative to that directory)
+to a pathname relative to the top of the work tree.
+
+The return value from `cmd_foo()` becomes the exit status of the
+command.
diff --git a/Documentation/technical/api-decorate.txt b/Documentation/technical/api-decorate.txt
new file mode 100644
index 0000000000..1d52a6ce14
--- /dev/null
+++ b/Documentation/technical/api-decorate.txt
@@ -0,0 +1,6 @@
+decorate API
+============
+
+Talk about <decorate.h>
+
+(Linus)
diff --git a/Documentation/technical/api-diff.txt b/Documentation/technical/api-diff.txt
new file mode 100644
index 0000000000..20b0241d30
--- /dev/null
+++ b/Documentation/technical/api-diff.txt
@@ -0,0 +1,166 @@
+diff API
+========
+
+The diff API is for programs that compare two sets of files (e.g. two
+trees, one tree and the index) and present the found difference in
+various ways. The calling program is responsible for feeding the API
+pairs of files, one from the "old" set and the corresponding one from
+"new" set, that are different. The library called through this API is
+called diffcore, and is responsible for two things.
+
+* finding total rewrites (`-B`), renames (`-M`) and copies (`-C`), and
+ changes that touch a string (`-S`), as specified by the caller.
+
+* outputting the differences in various formats, as specified by the
+ caller.
+
+Calling sequence
+----------------
+
+* Prepare `struct diff_options` to record the set of diff options, and
+ then call `diff_setup()` to initialize this structure. This sets up
+ the vanilla default.
+
+* Fill in the options structure to specify desired output format, rename
+ detection, etc. `diff_opt_parse()` can be used to parse options given
+ from the command line in a way consistent with existing git-diff
+ family of programs.
+
+* Call `diff_setup_done()`; this inspects the options set up so far for
+ internal consistency and make necessary tweaking to it (e.g. if
+ textual patch output was asked, recursive behaviour is turned on).
+
+* As you find different pairs of files, call `diff_change()` to feed
+ modified files, `diff_addremove()` to feed created or deleted files,
+ or `diff_unmerged()` to feed a file whose state is 'unmerged' to the
+ API. These are thin wrappers to a lower-level `diff_queue()` function
+ that is flexible enough to record any of these kinds of changes.
+
+* Once you finish feeding the pairs of files, call `diffcore_std()`.
+ This will tell the diffcore library to go ahead and do its work.
+
+* Calling `diff_flush()` will produce the output.
+
+
+Data structures
+---------------
+
+* `struct diff_filespec`
+
+This is the internal representation for a single file (blob). It
+records the blob object name (if known -- for a work tree file it
+typically is a NUL SHA-1), filemode and pathname. This is what the
+`diff_addremove()`, `diff_change()` and `diff_unmerged()` synthesize and
+feed `diff_queue()` function with.
+
+* `struct diff_filepair`
+
+This records a pair of `struct diff_filespec`; the filespec for a file
+in the "old" set (i.e. preimage) is called `one`, and the filespec for a
+file in the "new" set (i.e. postimage) is called `two`. A change that
+represents file creation has NULL in `one`, and file deletion has NULL
+in `two`.
+
+A `filepair` starts pointing at `one` and `two` that are from the same
+filename, but `diffcore_std()` can break pairs and match component
+filespecs with other filespecs from a different filepair to form new
+filepair. This is called 'rename detection'.
+
+* `struct diff_queue`
+
+This is a collection of filepairs. Notable members are:
+
+`queue`::
+
+ An array of pointers to `struct diff_filepair`. This
+ dynamically grows as you add filepairs;
+
+`alloc`::
+
+ The allocated size of the `queue` array;
+
+`nr`::
+
+ The number of elements in the `queue` array.
+
+
+* `struct diff_options`
+
+This describes the set of options the calling program wants to affect
+the operation of diffcore library with.
+
+Notable members are:
+
+`output_format`::
+ The output format used when `diff_flush()` is run.
+
+`context`::
+ Number of context lines to generate in patch output.
+
+`break_opt`, `detect_rename`, `rename-score`, `rename_limit`::
+ Affects the way detection logic for complete rewrites, renames
+ and copies.
+
+`abbrev`::
+ Number of hexdigits to abbreviate raw format output to.
+
+`pickaxe`::
+ A constant string (can and typically does contain newlines to
+ look for a block of text, not just a single line) to filter out
+ the filepairs that do not change the number of strings contained
+ in its preimage and postimage of the diff_queue.
+
+`flags`::
+ This is mostly a collection of boolean options that affects the
+ operation, but some do not have anything to do with the diffcore
+ library.
+
+BINARY, TEXT;;
+ Affects the way how a file that is seemingly binary is treated.
+
+FULL_INDEX;;
+ Tells the patch output format not to use abbreviated object
+ names on the "index" lines.
+
+FIND_COPIES_HARDER;;
+ Tells the diffcore library that the caller is feeding unchanged
+ filepairs to allow copies from unmodified files be detected.
+
+COLOR_DIFF;;
+ Output should be colored.
+
+COLOR_DIFF_WORDS;;
+ Output is a colored word-diff.
+
+NO_INDEX;;
+ Tells diff-files that the input is not tracked files but files
+ in random locations on the filesystem.
+
+ALLOW_EXTERNAL;;
+ Tells output routine that it is Ok to call user specified patch
+ output routine. Plumbing disables this to ensure stable output.
+
+QUIET;;
+ Do not show any output.
+
+REVERSE_DIFF;;
+ Tells the library that the calling program is feeding the
+ filepairs reversed; `one` is two, and `two` is one.
+
+EXIT_WITH_STATUS;;
+ For communication between the calling program and the options
+ parser; tell the calling program to signal the presence of
+ difference using program exit code.
+
+HAS_CHANGES;;
+ Internal; used for optimization to see if there is any change.
+
+SILENT_ON_REMOVE;;
+ Affects if diff-files shows removed files.
+
+RECURSIVE, TREE_IN_RECURSIVE;;
+ Tells if tree traversal done by tree-diff should recursively
+ descend into a tree object pair that are different in preimage
+ and postimage set.
+
+(JC)
diff --git a/Documentation/technical/api-directory-listing.txt b/Documentation/technical/api-directory-listing.txt
new file mode 100644
index 0000000000..5bbd18f020
--- /dev/null
+++ b/Documentation/technical/api-directory-listing.txt
@@ -0,0 +1,76 @@
+directory listing API
+=====================
+
+The directory listing API is used to enumerate paths in the work tree,
+optionally taking `.git/info/exclude` and `.gitignore` files per
+directory into account.
+
+Data structure
+--------------
+
+`struct dir_struct` structure is used to pass directory traversal
+options to the library and to record the paths discovered. The notable
+options are:
+
+`exclude_per_dir`::
+
+ The name of the file to be read in each directory for excluded
+ files (typically `.gitignore`).
+
+`collect_ignored`::
+
+ Include paths that are to be excluded in the result.
+
+`show_ignored`::
+
+ The traversal is for finding just ignored files, not unignored
+ files.
+
+`show_other_directories`::
+
+ Include a directory that is not tracked.
+
+`hide_empty_directories`::
+
+ Do not include a directory that is not tracked and is empty.
+
+`no_gitlinks`::
+
+ If set, recurse into a directory that looks like a git
+ directory. Otherwise it is shown as a directory.
+
+The result of the enumeration is left in these fields::
+
+`entries[]`::
+
+ An array of `struct dir_entry`, each element of which describes
+ a path.
+
+`nr`::
+
+ The number of members in `entries[]` array.
+
+`alloc`::
+
+ Internal use; keeps track of allocation of `entries[]` array.
+
+
+Calling sequence
+----------------
+
+* Prepare `struct dir_struct dir` and clear it with `memset(&dir, 0,
+ sizeof(dir))`.
+
+* Call `add_exclude()` to add single exclude pattern,
+ `add_excludes_from_file()` to add patterns from a file
+ (e.g. `.git/info/exclude`), and/or set `dir.exclude_per_dir`. A
+ short-hand function `setup_standard_excludes()` can be used to set up
+ the standard set of exclude settings.
+
+* Set options described in the Data Structure section above.
+
+* Call `read_directory()`.
+
+* Use `dir.entries[]`.
+
+(JC)
diff --git a/Documentation/technical/api-gitattributes.txt b/Documentation/technical/api-gitattributes.txt
new file mode 100644
index 0000000000..9d97eaa9de
--- /dev/null
+++ b/Documentation/technical/api-gitattributes.txt
@@ -0,0 +1,111 @@
+gitattributes API
+=================
+
+gitattributes mechanism gives a uniform way to associate various
+attributes to set of paths.
+
+
+Data Structure
+--------------
+
+`struct git_attr`::
+
+ An attribute is an opaque object that is identified by its name.
+ Pass the name and its length to `git_attr()` function to obtain
+ the object of this type. The internal representation of this
+ structure is of no interest to the calling programs.
+
+`struct git_attr_check`::
+
+ This structure represents a set of attributes to check in a call
+ to `git_checkattr()` function, and receives the results.
+
+
+Calling Sequence
+----------------
+
+* Prepare an array of `struct git_attr_check` to define the list of
+ attributes you would want to check. To populate this array, you would
+ need to define necessary attributes by calling `git_attr()` function.
+
+* Call git_checkattr() to check the attributes for the path.
+
+* Inspect `git_attr_check` structure to see how each of the attribute in
+ the array is defined for the path.
+
+
+Attribute Values
+----------------
+
+An attribute for a path can be in one of four states: Set, Unset,
+Unspecified or set to a string, and `.value` member of `struct
+git_attr_check` records it. There are three macros to check these:
+
+`ATTR_TRUE()`::
+
+ Returns true if the attribute is Set for the path.
+
+`ATTR_FALSE()`::
+
+ Returns true if the attribute is Unset for the path.
+
+`ATTR_UNSET()`::
+
+ Returns true if the attribute is Unspecified for the path.
+
+If none of the above returns true, `.value` member points at a string
+value of the attribute for the path.
+
+
+Example
+-------
+
+To see how attributes "crlf" and "indent" are set for different paths.
+
+. Prepare an array of `struct git_attr_check` with two elements (because
+ we are checking two attributes). Initialize their `attr` member with
+ pointers to `struct git_attr` obtained by calling `git_attr()`:
+
+------------
+static struct git_attr_check check[2];
+static void setup_check(void)
+{
+ if (check[0].attr)
+ return; /* already done */
+ check[0].attr = git_attr("crlf", 4);
+ check[1].attr = git_attr("ident", 5);
+}
+------------
+
+. Call `git_checkattr()` with the prepared array of `struct git_attr_check`:
+
+------------
+ const char *path;
+
+ setup_check();
+ git_checkattr(path, ARRAY_SIZE(check), check);
+------------
+
+. Act on `.value` member of the result, left in `check[]`:
+
+------------
+ const char *value = check[0].value;
+
+ if (ATTR_TRUE(value)) {
+ The attribute is Set, by listing only the name of the
+ attribute in the gitattributes file for the path.
+ } else if (ATTR_FALSE(value)) {
+ The attribute is Unset, by listing the name of the
+ attribute prefixed with a dash - for the path.
+ } else if (ATTR_UNSET(value)) {
+ The attribute is not set nor unset for the path.
+ } else if (!strcmp(value, "input")) {
+ If none of ATTR_TRUE(), ATTR_FALSE(), or ATTR_UNSET() is
+ true, the value is a string set in the gitattributes
+ file for the path by saying "attr=value".
+ } else if (... other check using value as string ...) {
+ ...
+ }
+------------
+
+(JC)
diff --git a/Documentation/technical/api-grep.txt b/Documentation/technical/api-grep.txt
new file mode 100644
index 0000000000..a69cc8964d
--- /dev/null
+++ b/Documentation/technical/api-grep.txt
@@ -0,0 +1,8 @@
+grep API
+========
+
+Talk about <grep.h>, things like:
+
+* grep_buffer()
+
+(JC)
diff --git a/Documentation/technical/api-hash.txt b/Documentation/technical/api-hash.txt
new file mode 100644
index 0000000000..c784d3edcb
--- /dev/null
+++ b/Documentation/technical/api-hash.txt
@@ -0,0 +1,6 @@
+hash API
+========
+
+Talk about <hash.h>
+
+(Linus)
diff --git a/Documentation/technical/api-history-graph.txt b/Documentation/technical/api-history-graph.txt
new file mode 100644
index 0000000000..e9559790a3
--- /dev/null
+++ b/Documentation/technical/api-history-graph.txt
@@ -0,0 +1,179 @@
+history graph API
+=================
+
+The graph API is used to draw a text-based representation of the commit
+history. The API generates the graph in a line-by-line fashion.
+
+Functions
+---------
+
+Core functions:
+
+* `graph_init()` creates a new `struct git_graph`
+
+* `graph_release()` destroys a `struct git_graph`, and frees the memory
+ associated with it.
+
+* `graph_update()` moves the graph to a new commit.
+
+* `graph_next_line()` outputs the next line of the graph into a strbuf. It
+ does not add a terminating newline.
+
+* `graph_padding_line()` outputs a line of vertical padding in the graph. It
+ is similar to `graph_next_line()`, but is guaranteed to never print the line
+ containing the current commit. Where `graph_next_line()` would print the
+ commit line next, `graph_padding_line()` prints a line that simply extends
+ all branch lines downwards one row, leaving their positions unchanged.
+
+* `graph_is_commit_finished()` determines if the graph has output all lines
+ necessary for the current commit. If `graph_update()` is called before all
+ lines for the current commit have been printed, the next call to
+ `graph_next_line()` will output an ellipsis, to indicate that a portion of
+ the graph was omitted.
+
+The following utility functions are wrappers around `graph_next_line()` and
+`graph_is_commit_finished()`. They always print the output to stdout.
+They can all be called with a NULL graph argument, in which case no graph
+output will be printed.
+
+* `graph_show_commit()` calls `graph_next_line()` until it returns non-zero.
+ This prints all graph lines up to, and including, the line containing this
+ commit. Output is printed to stdout. The last line printed does not contain
+ a terminating newline. This should not be called if the commit line has
+ already been printed, or it will loop forever.
+
+* `graph_show_oneline()` calls `graph_next_line()` and prints the result to
+ stdout. The line printed does not contain a terminating newline.
+
+* `graph_show_padding()` calls `graph_padding_line()` and prints the result to
+ stdout. The line printed does not contain a terminating newline.
+
+* `graph_show_remainder()` calls `graph_next_line()` until
+ `graph_is_commit_finished()` returns non-zero. Output is printed to stdout.
+ The last line printed does not contain a terminating newline. Returns 1 if
+ output was printed, and 0 if no output was necessary.
+
+* `graph_show_strbuf()` prints the specified strbuf to stdout, prefixing all
+ lines but the first with a graph line. The caller is responsible for
+ ensuring graph output for the first line has already been printed to stdout.
+ (This can be done with `graph_show_commit()` or `graph_show_oneline()`.) If
+ a NULL graph is supplied, the strbuf is printed as-is.
+
+* `graph_show_commit_msg()` is similar to `graph_show_strbuf()`, but it also
+ prints the remainder of the graph, if more lines are needed after the strbuf
+ ends. It is better than directly calling `graph_show_strbuf()` followed by
+ `graph_show_remainder()` since it properly handles buffers that do not end in
+ a terminating newline. The output printed by `graph_show_commit_msg()` will
+ end in a newline if and only if the strbuf ends in a newline.
+
+Data structure
+--------------
+`struct git_graph` is an opaque data type used to store the current graph
+state.
+
+Calling sequence
+----------------
+
+* Create a `struct git_graph` by calling `graph_init()`. When using the
+ revision walking API, this is done automatically by `setup_revisions()` if
+ the '--graph' option is supplied.
+
+* Use the revision walking API to walk through a group of contiguous commits.
+ The `get_revision()` function automatically calls `graph_update()` each time
+ it is invoked.
+
+* For each commit, call `graph_next_line()` repeatedly, until
+ `graph_is_commit_finished()` returns non-zero. Each call go
+ `graph_next_line()` will output a single line of the graph. The resulting
+ lines will not contain any newlines. `graph_next_line()` returns 1 if the
+ resulting line contains the current commit, or 0 if this is merely a line
+ needed to adjust the graph before or after the current commit. This return
+ value can be used to determine where to print the commit summary information
+ alongside the graph output.
+
+Limitations
+-----------
+
+* `graph_update()` must be called with commits in topological order. It should
+ not be called on a commit if it has already been invoked with an ancestor of
+ that commit, or the graph output will be incorrect.
+
+* `graph_update()` must be called on a contiguous group of commits. If
+ `graph_update()` is called on a particular commit, it should later be called
+ on all parents of that commit. Parents must not be skipped, or the graph
+ output will appear incorrect.
++
+`graph_update()` may be used on a pruned set of commits only if the parent list
+has been rewritten so as to include only ancestors from the pruned set.
+
+* The graph API does not currently support reverse commit ordering. In
+ order to implement reverse ordering, the graphing API needs an
+ (efficient) mechanism to find the children of a commit.
+
+Sample usage
+------------
+
+------------
+struct commit *commit;
+struct git_graph *graph = graph_init(opts);
+
+while ((commit = get_revision(opts)) != NULL) {
+ graph_update(graph, commit);
+ while (!graph_is_commit_finished(graph))
+ {
+ struct strbuf sb;
+ int is_commit_line;
+
+ strbuf_init(&sb, 0);
+ is_commit_line = graph_next_line(graph, &sb);
+ fputs(sb.buf, stdout);
+
+ if (is_commit_line)
+ log_tree_commit(opts, commit);
+ else
+ putchar(opts->diffopt.line_termination);
+ }
+}
+
+graph_release(graph);
+------------
+
+Sample output
+-------------
+
+The following is an example of the output from the graph API. This output does
+not include any commit summary information--callers are responsible for
+outputting that information, if desired.
+
+------------
+*
+*
+M
+|\
+* |
+| | *
+| \ \
+| \ \
+M-. \ \
+|\ \ \ \
+| | * | |
+| | | | | *
+| | | | | *
+| | | | | M
+| | | | | |\
+| | | | | | *
+| * | | | | |
+| | | | | M \
+| | | | | |\ |
+| | | | * | | |
+| | | | * | | |
+* | | | | | | |
+| |/ / / / / /
+|/| / / / / /
+* | | | | | |
+|/ / / / / /
+* | | | | |
+| | | | | *
+| | | | |/
+| | | | *
+------------
diff --git a/Documentation/technical/api-in-core-index.txt b/Documentation/technical/api-in-core-index.txt
new file mode 100644
index 0000000000..adbdbf5d75
--- /dev/null
+++ b/Documentation/technical/api-in-core-index.txt
@@ -0,0 +1,21 @@
+in-core index API
+=================
+
+Talk about <read-cache.c> and <cache-tree.c>, things like:
+
+* cache -> the_index macros
+* read_index()
+* write_index()
+* ie_match_stat() and ie_modified(); how they are different and when to
+ use which.
+* index_name_pos()
+* remove_index_entry_at()
+* remove_file_from_index()
+* add_file_to_index()
+* add_index_entry()
+* refresh_index()
+* discard_index()
+* cache_tree_invalidate_path()
+* cache_tree_update()
+
+(JC, Linus)
diff --git a/Documentation/technical/api-index-skel.txt b/Documentation/technical/api-index-skel.txt
new file mode 100644
index 0000000000..af7cc2e395
--- /dev/null
+++ b/Documentation/technical/api-index-skel.txt
@@ -0,0 +1,15 @@
+GIT API Documents
+=================
+
+GIT has grown a set of internal API over time. This collection
+documents them.
+
+////////////////////////////////////////////////////////////////
+// table of contents begin
+////////////////////////////////////////////////////////////////
+
+////////////////////////////////////////////////////////////////
+// table of contents end
+////////////////////////////////////////////////////////////////
+
+2007-11-24
diff --git a/Documentation/technical/api-index.sh b/Documentation/technical/api-index.sh
new file mode 100755
index 0000000000..9c3f4131b8
--- /dev/null
+++ b/Documentation/technical/api-index.sh
@@ -0,0 +1,28 @@
+#!/bin/sh
+
+(
+ c=////////////////////////////////////////////////////////////////
+ skel=api-index-skel.txt
+ sed -e '/^\/\/ table of contents begin/q' "$skel"
+ echo "$c"
+
+ ls api-*.txt |
+ while read filename
+ do
+ case "$filename" in
+ api-index-skel.txt | api-index.txt) continue ;;
+ esac
+ title=$(sed -e 1q "$filename")
+ html=${filename%.txt}.html
+ echo "* link:$html[$title]"
+ done
+ echo "$c"
+ sed -n -e '/^\/\/ table of contents end/,$p' "$skel"
+) >api-index.txt+
+
+if test -f api-index.txt && cmp api-index.txt api-index.txt+ >/dev/null
+then
+ rm -f api-index.txt+
+else
+ mv api-index.txt+ api-index.txt
+fi
diff --git a/Documentation/technical/api-lockfile.txt b/Documentation/technical/api-lockfile.txt
new file mode 100644
index 0000000000..dd894043ae
--- /dev/null
+++ b/Documentation/technical/api-lockfile.txt
@@ -0,0 +1,74 @@
+lockfile API
+============
+
+The lockfile API serves two purposes:
+
+* Mutual exclusion. When we write out a new index file, first
+ we create a new file `$GIT_DIR/index.lock`, write the new
+ contents into it, and rename it to the final destination
+ `$GIT_DIR/index`. We try to create the `$GIT_DIR/index.lock`
+ file with O_EXCL so that we can notice and fail when somebody
+ else is already trying to update the index file.
+
+* Automatic cruft removal. After we create the "lock" file, we
+ may decide to `die()`, and we would want to make sure that we
+ remove the file that has not been committed to its final
+ destination. This is done by remembering the lockfiles we
+ created in a linked list and cleaning them up from an
+ `atexit(3)` handler. Outstanding lockfiles are also removed
+ when the program dies on a signal.
+
+
+The functions
+-------------
+
+hold_lock_file_for_update::
+
+ Take a pointer to `struct lock_file`, the filename of
+ the final destination (e.g. `$GIT_DIR/index`) and a flag
+ `die_on_error`. Attempt to create a lockfile for the
+ destination and return the file descriptor for writing
+ to the file. If `die_on_error` flag is true, it dies if
+ a lock is already taken for the file; otherwise it
+ returns a negative integer to the caller on failure.
+
+commit_lock_file::
+
+ Take a pointer to the `struct lock_file` initialized
+ with an earlier call to `hold_lock_file_for_update()`,
+ close the file descriptor and rename the lockfile to its
+ final destination. Returns 0 upon success, a negative
+ value on failure to close(2) or rename(2).
+
+rollback_lock_file::
+
+ Take a pointer to the `struct lock_file` initialized
+ with an earlier call to `hold_lock_file_for_update()`,
+ close the file descriptor and remove the lockfile.
+
+close_lock_file::
+ Take a pointer to the `struct lock_file` initialized
+ with an earlier call to `hold_lock_file_for_update()`,
+ and close the file descriptor. Returns 0 upon success,
+ a negative value on failure to close(2).
+
+Because the structure is used in an `atexit(3)` handler, its
+storage has to stay throughout the life of the program. It
+cannot be an auto variable allocated on the stack.
+
+Call `commit_lock_file()` or `rollback_lock_file()` when you are
+done writing to the file descriptor. If you do not call either
+and simply `exit(3)` from the program, an `atexit(3)` handler
+will close and remove the lockfile.
+
+If you need to close the file descriptor you obtained from
+`hold_lock_file_for_update` function yourself, do so by calling
+`close_lock_file()`. You should never call `close(2)` yourself!
+Otherwise the `struct
+lock_file` structure still remembers that the file descriptor
+needs to be closed, and a later call to `commit_lock_file()` or
+`rollback_lock_file()` will result in duplicate calls to
+`close(2)`. Worse yet, if you `close(2)`, open another file
+descriptor for completely different purpose, and then call
+`commit_lock_file()` or `rollback_lock_file()`, they may close
+that unrelated file descriptor.
diff --git a/Documentation/technical/api-object-access.txt b/Documentation/technical/api-object-access.txt
new file mode 100644
index 0000000000..03bb0e950d
--- /dev/null
+++ b/Documentation/technical/api-object-access.txt
@@ -0,0 +1,15 @@
+object access API
+=================
+
+Talk about <sha1_file.c> and <object.h> family, things like
+
+* read_sha1_file()
+* read_object_with_reference()
+* has_sha1_file()
+* write_sha1_file()
+* pretend_sha1_file()
+* lookup_{object,commit,tag,blob,tree}
+* parse_{object,commit,tag,blob,tree}
+* Use of object flags
+
+(JC, Shawn, Daniel, Dscho, Linus)
diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
new file mode 100644
index 0000000000..b7cda94f54
--- /dev/null
+++ b/Documentation/technical/api-parse-options.txt
@@ -0,0 +1,6 @@
+parse-options API
+=================
+
+Talk about <parse-options.h>
+
+(Pierre)
diff --git a/Documentation/technical/api-path-list.txt b/Documentation/technical/api-path-list.txt
new file mode 100644
index 0000000000..d077683171
--- /dev/null
+++ b/Documentation/technical/api-path-list.txt
@@ -0,0 +1,9 @@
+path-list API
+=============
+
+Talk about <path-list.h>, things like
+
+* it is not just paths but strings in general;
+* the calling sequence.
+
+(Dscho)
diff --git a/Documentation/technical/api-quote.txt b/Documentation/technical/api-quote.txt
new file mode 100644
index 0000000000..e8a1bce94e
--- /dev/null
+++ b/Documentation/technical/api-quote.txt
@@ -0,0 +1,10 @@
+quote API
+=========
+
+Talk about <quote.h>, things like
+
+* sq_quote and unquote
+* c_style quote and unquote
+* quoting for foreign languages
+
+(JC)
diff --git a/Documentation/technical/api-remote.txt b/Documentation/technical/api-remote.txt
new file mode 100644
index 0000000000..073b22bd83
--- /dev/null
+++ b/Documentation/technical/api-remote.txt
@@ -0,0 +1,123 @@
+Remotes configuration API
+=========================
+
+The API in remote.h gives access to the configuration related to
+remotes. It handles all three configuration mechanisms historically
+and currently used by git, and presents the information in a uniform
+fashion. Note that the code also handles plain URLs without any
+configuration, giving them just the default information.
+
+struct remote
+-------------
+
+`name`::
+
+ The user's nickname for the remote
+
+`url`::
+
+ An array of all of the url_nr URLs configured for the remote
+
+`push`::
+
+ An array of refspecs configured for pushing, with
+ push_refspec being the literal strings, and push_refspec_nr
+ being the quantity.
+
+`fetch`::
+
+ An array of refspecs configured for fetching, with
+ fetch_refspec being the literal strings, and fetch_refspec_nr
+ being the quantity.
+
+`fetch_tags`::
+
+ The setting for whether to fetch tags (as a separate rule from
+ the configured refspecs); -1 means never to fetch tags, 0
+ means to auto-follow tags based on the default heuristic, 1
+ means to always auto-follow tags, and 2 means to fetch all
+ tags.
+
+`receivepack`, `uploadpack`::
+
+ The configured helper programs to run on the remote side, for
+ git-native protocols.
+
+`http_proxy`::
+
+ The proxy to use for curl (http, https, ftp, etc.) URLs.
+
+struct remotes can be found by name with remote_get(), and iterated
+through with for_each_remote(). remote_get(NULL) will return the
+default remote, given the current branch and configuration.
+
+struct refspec
+--------------
+
+A struct refspec holds the parsed interpretation of a refspec. If it
+will force updates (starts with a '+'), force is true. If it is a
+pattern (sides end with '*') pattern is true. src and dest are the two
+sides (if a pattern, only the part outside of the wildcards); if there
+is only one side, it is src, and dst is NULL; if sides exist but are
+empty (i.e., the refspec either starts or ends with ':'), the
+corresponding side is "".
+
+This parsing can be done to an array of strings to give an array of
+struct refpsecs with parse_ref_spec().
+
+remote_find_tracking(), given a remote and a struct refspec with
+either src or dst filled out, will fill out the other such that the
+result is in the "fetch" specification for the remote (note that this
+evaluates patterns and returns a single result).
+
+struct branch
+-------------
+
+Note that this may end up moving to branch.h
+
+struct branch holds the configuration for a branch. It can be looked
+up with branch_get(name) for "refs/heads/{name}", or with
+branch_get(NULL) for HEAD.
+
+It contains:
+
+`name`::
+
+ The short name of the branch.
+
+`refname`::
+
+ The full path for the branch ref.
+
+`remote_name`::
+
+ The name of the remote listed in the configuration.
+
+`remote`::
+
+ The struct remote for that remote.
+
+`merge_name`::
+
+ An array of the "merge" lines in the configuration.
+
+`merge`::
+
+ An array of the struct refspecs used for the merge lines. That
+ is, merge[i]->dst is a local tracking ref which should be
+ merged into this branch by default.
+
+`merge_nr`::
+
+ The number of merge configurations
+
+branch_has_merge_config() returns true if the given branch has merge
+configuration given.
+
+Other stuff
+-----------
+
+There is other stuff in remote.h that is related, in general, to the
+process of interacting with remotes.
+
+(Daniel Barkalow)
diff --git a/Documentation/technical/api-revision-walking.txt b/Documentation/technical/api-revision-walking.txt
new file mode 100644
index 0000000000..996da0503a
--- /dev/null
+++ b/Documentation/technical/api-revision-walking.txt
@@ -0,0 +1,67 @@
+revision walking API
+====================
+
+The revision walking API offers functions to build a list of revisions
+and then iterate over that list.
+
+Calling sequence
+----------------
+
+The walking API has a given calling sequence: first you need to
+initialize a rev_info structure, then add revisions to control what kind
+of revision list do you want to get, finally you can iterate over the
+revision list.
+
+Functions
+---------
+
+`init_revisions`::
+
+ Initialize a rev_info structure with default values. The second
+ parameter may be NULL or can be prefix path, and then the `.prefix`
+ variable will be set to it. This is typically the first function you
+ want to call when you want to deal with a revision list. After calling
+ this function, you are free to customize options, like set
+ `.ignore_merges` to 0 if you don't want to ignore merges, and so on. See
+ `revision.h` for a complete list of available options.
+
+`add_pending_object`::
+
+ This function can be used if you want to add commit objects as revision
+ information. You can use the `UNINTERESTING` object flag to indicate if
+ you want to include or exclude the given commit (and commits reachable
+ from the given commit) from the revision list.
++
+NOTE: If you have the commits as a string list then you probably want to
+use setup_revisions(), instead of parsing each string and using this
+function.
+
+`setup_revisions`::
+
+ Parse revision information, filling in the `rev_info` structure, and
+ removing the used arguments from the argument list. Returns the number
+ of arguments left that weren't recognized, which are also moved to the
+ head of the argument list. The last parameter is used in case no
+ parameter given by the first two arguments.
+
+`prepare_revision_walk`::
+
+ Prepares the rev_info structure for a walk. You should check if it
+ returns any error (non-zero return code) and if it does not, you can
+ start using get_revision() to do the iteration.
+
+`get_revision`::
+
+ Takes a pointer to a `rev_info` structure and iterates over it,
+ returning a `struct commit *` each time you call it. The end of the
+ revision list is indicated by returning a NULL pointer.
+
+Data structures
+---------------
+
+Talk about <revision.h>, things like:
+
+* two diff_options, one for path limiting, another for output;
+* remaining functions;
+
+(Linus, JC, Dscho)
diff --git a/Documentation/technical/api-run-command.txt b/Documentation/technical/api-run-command.txt
new file mode 100644
index 0000000000..c364a22c8f
--- /dev/null
+++ b/Documentation/technical/api-run-command.txt
@@ -0,0 +1,172 @@
+run-command API
+===============
+
+The run-command API offers a versatile tool to run sub-processes with
+redirected input and output as well as with a modified environment
+and an alternate current directory.
+
+A similar API offers the capability to run a function asynchronously,
+which is primarily used to capture the output that the function
+produces in the caller in order to process it.
+
+
+Functions
+---------
+
+`start_command`::
+
+ Start a sub-process. Takes a pointer to a `struct child_process`
+ that specifies the details and returns pipe FDs (if requested).
+ See below for details.
+
+`finish_command`::
+
+ Wait for the completion of a sub-process that was started with
+ start_command().
+
+`run_command`::
+
+ A convenience function that encapsulates a sequence of
+ start_command() followed by finish_command(). Takes a pointer
+ to a `struct child_process` that specifies the details.
+
+`run_command_v_opt`, `run_command_v_opt_dir`, `run_command_v_opt_cd_env`::
+
+ Convenience functions that encapsulate a sequence of
+ start_command() followed by finish_command(). The argument argv
+ specifies the program and its arguments. The argument opt is zero
+ or more of the flags `RUN_COMMAND_NO_STDIN`, `RUN_GIT_CMD`, or
+ `RUN_COMMAND_STDOUT_TO_STDERR` that correspond to the members
+ .no_stdin, .git_cmd, .stdout_to_stderr of `struct child_process`.
+ The argument dir corresponds the member .dir. The argument env
+ corresponds to the member .env.
+
+`start_async`::
+
+ Run a function asynchronously. Takes a pointer to a `struct
+ async` that specifies the details and returns a pipe FD
+ from which the caller reads. See below for details.
+
+`finish_async`::
+
+ Wait for the completion of an asynchronous function that was
+ started with start_async().
+
+
+Data structures
+---------------
+
+* `struct child_process`
+
+This describes the arguments, redirections, and environment of a
+command to run in a sub-process.
+
+The caller:
+
+1. allocates and clears (memset(&chld, '0', sizeof(chld));) a
+ struct child_process variable;
+2. initializes the members;
+3. calls start_command();
+4. processes the data;
+5. closes file descriptors (if necessary; see below);
+6. calls finish_command().
+
+The .argv member is set up as an array of string pointers (NULL
+terminated), of which .argv[0] is the program name to run (usually
+without a path). If the command to run is a git command, set argv[0] to
+the command name without the 'git-' prefix and set .git_cmd = 1.
+
+The members .in, .out, .err are used to redirect stdin, stdout,
+stderr as follows:
+
+. Specify 0 to request no special redirection. No new file descriptor
+ is allocated. The child process simply inherits the channel from the
+ parent.
+
+. Specify -1 to have a pipe allocated; start_command() replaces -1
+ by the pipe FD in the following way:
+
+ .in: Returns the writable pipe end into which the caller writes;
+ the readable end of the pipe becomes the child's stdin.
+
+ .out, .err: Returns the readable pipe end from which the caller
+ reads; the writable end of the pipe end becomes child's
+ stdout/stderr.
+
+ The caller of start_command() must close the so returned FDs
+ after it has completed reading from/writing to it!
+
+. Specify a file descriptor > 0 to be used by the child:
+
+ .in: The FD must be readable; it becomes child's stdin.
+ .out: The FD must be writable; it becomes child's stdout.
+ .err > 0 is not supported.
+
+ The specified FD is closed by start_command(), even if it fails to
+ run the sub-process!
+
+. Special forms of redirection are available by setting these members
+ to 1:
+
+ .no_stdin, .no_stdout, .no_stderr: The respective channel is
+ redirected to /dev/null.
+
+ .stdout_to_stderr: stdout of the child is redirected to its
+ stderr. This happens after stderr is itself redirected.
+ So stdout will follow stderr to wherever it is
+ redirected.
+
+To modify the environment of the sub-process, specify an array of
+string pointers (NULL terminated) in .env:
+
+. If the string is of the form "VAR=value", i.e. it contains '='
+ the variable is added to the child process's environment.
+
+. If the string does not contain '=', it names an environment
+ variable that will be removed from the child process's environment.
+
+To specify a new initial working directory for the sub-process,
+specify it in the .dir member.
+
+
+* `struct async`
+
+This describes a function to run asynchronously, whose purpose is
+to produce output that the caller reads.
+
+The caller:
+
+1. allocates and clears (memset(&asy, '0', sizeof(asy));) a
+ struct async variable;
+2. initializes .proc and .data;
+3. calls start_async();
+4. processes the data by reading from the fd in .out;
+5. closes .out;
+6. calls finish_async().
+
+The function pointer in .proc has the following signature:
+
+ int proc(int fd, void *data);
+
+. fd specifies a writable file descriptor to which the function must
+ write the data that it produces. The function *must* close this
+ descriptor before it returns.
+
+. data is the value that the caller has specified in the .data member
+ of struct async.
+
+. The return value of the function is 0 on success and non-zero
+ on failure. If the function indicates failure, finish_async() will
+ report failure as well.
+
+
+There are serious restrictions on what the asynchronous function can do
+because this facility is implemented by a pipe to a forked process on
+UNIX, but by a thread in the same address space on Windows:
+
+. It cannot change the program's state (global variables, environment,
+ etc.) in a way that the caller notices; in other words, .out is the
+ only communication channel to the caller.
+
+. It must not change the program's state that the caller of the
+ facility also uses.
diff --git a/Documentation/technical/api-setup.txt b/Documentation/technical/api-setup.txt
new file mode 100644
index 0000000000..4f63a04d7d
--- /dev/null
+++ b/Documentation/technical/api-setup.txt
@@ -0,0 +1,13 @@
+setup API
+=========
+
+Talk about
+
+* setup_git_directory()
+* setup_git_directory_gently()
+* is_inside_git_dir()
+* is_inside_work_tree()
+* setup_work_tree()
+* get_pathspec()
+
+(Dscho)
diff --git a/Documentation/technical/api-strbuf.txt b/Documentation/technical/api-strbuf.txt
new file mode 100644
index 0000000000..a9668e5f2d
--- /dev/null
+++ b/Documentation/technical/api-strbuf.txt
@@ -0,0 +1,241 @@
+strbuf API
+==========
+
+strbuf's are meant to be used with all the usual C string and memory
+APIs. Given that the length of the buffer is known, it's often better to
+use the mem* functions than a str* one (memchr vs. strchr e.g.).
+Though, one has to be careful about the fact that str* functions often
+stop on NULs and that strbufs may have embedded NULs.
+
+An strbuf is NUL terminated for convenience, but no function in the
+strbuf API actually relies on the string being free of NULs.
+
+strbufs has some invariants that are very important to keep in mind:
+
+. The `buf` member is never NULL, so you it can be used in any usual C
+string operations safely. strbuf's _have_ to be initialized either by
+`strbuf_init()` or by `= STRBUF_INIT` before the invariants, though.
++
+Do *not* assume anything on what `buf` really is (e.g. if it is
+allocated memory or not), use `strbuf_detach()` to unwrap a memory
+buffer from its strbuf shell in a safe way. That is the sole supported
+way. This will give you a malloced buffer that you can later `free()`.
++
+However, it it totally safe to modify anything in the string pointed by
+the `buf` member, between the indices `0` and `len-1` (inclusive).
+
+. The `buf` member is a byte array that has at least `len + 1` bytes
+ allocated. The extra byte is used to store a `'\0'`, allowing the
+ `buf` member to be a valid C-string. Every strbuf function ensure this
+ invariant is preserved.
++
+NOTE: It is OK to "play" with the buffer directly if you work it this
+ way:
++
+----
+strbuf_grow(sb, SOME_SIZE); <1>
+strbuf_setlen(sb, sb->len + SOME_OTHER_SIZE);
+----
+<1> Here, the memory array starting at `sb->buf`, and of length
+`strbuf_avail(sb)` is all yours, and you can be sure that
+`strbuf_avail(sb)` is at least `SOME_SIZE`.
++
+NOTE: `SOME_OTHER_SIZE` must be smaller or equal to `strbuf_avail(sb)`.
++
+Doing so is safe, though if it has to be done in many places, adding the
+missing API to the strbuf module is the way to go.
++
+WARNING: Do _not_ assume that the area that is yours is of size `alloc
+- 1` even if it's true in the current implementation. Alloc is somehow a
+"private" member that should not be messed with. Use `strbuf_avail()`
+instead.
+
+Data structures
+---------------
+
+* `struct strbuf`
+
+This is string buffer structure. The `len` member can be used to
+determine the current length of the string, and `buf` member provides access to
+the string itself.
+
+Functions
+---------
+
+* Life cycle
+
+`strbuf_init`::
+
+ Initialize the structure. The second parameter can be zero or a bigger
+ number to allocate memory, in case you want to prevent further reallocs.
+
+`strbuf_release`::
+
+ Release a string buffer and the memory it used. You should not use the
+ string buffer after using this function, unless you initialize it again.
+
+`strbuf_detach`::
+
+ Detach the string from the strbuf and returns it; you now own the
+ storage the string occupies and it is your responsibility from then on
+ to release it with `free(3)` when you are done with it.
+
+`strbuf_attach`::
+
+ Attach a string to a buffer. You should specify the string to attach,
+ the current length of the string and the amount of allocated memory.
+ The amount must be larger than the string length, because the string you
+ pass is supposed to be a NUL-terminated string. This string _must_ be
+ malloc()ed, and after attaching, the pointer cannot be relied upon
+ anymore, and neither be free()d directly.
+
+`strbuf_swap`::
+
+ Swap the contents of two string buffers.
+
+* Related to the size of the buffer
+
+`strbuf_avail`::
+
+ Determine the amount of allocated but unused memory.
+
+`strbuf_grow`::
+
+ Ensure that at least this amount of unused memory is available after
+ `len`. This is used when you know a typical size for what you will add
+ and want to avoid repetitive automatic resizing of the underlying buffer.
+ This is never a needed operation, but can be critical for performance in
+ some cases.
+
+`strbuf_setlen`::
+
+ Set the length of the buffer to a given value. This function does *not*
+ allocate new memory, so you should not perform a `strbuf_setlen()` to a
+ length that is larger than `len + strbuf_avail()`. `strbuf_setlen()` is
+ just meant as a 'please fix invariants from this strbuf I just messed
+ with'.
+
+`strbuf_reset`::
+
+ Empty the buffer by setting the size of it to zero.
+
+* Related to the contents of the buffer
+
+`strbuf_rtrim`::
+
+ Strip whitespace from the end of a string.
+
+`strbuf_cmp`::
+
+ Compare two buffers. Returns an integer less than, equal to, or greater
+ than zero if the first buffer is found, respectively, to be less than,
+ to match, or be greater than the second buffer.
+
+* Adding data to the buffer
+
+NOTE: All of these functions in this section will grow the buffer as
+ necessary.
+
+`strbuf_addch`::
+
+ Add a single character to the buffer.
+
+`strbuf_insert`::
+
+ Insert data to the given position of the buffer. The remaining contents
+ will be shifted, not overwritten.
+
+`strbuf_remove`::
+
+ Remove given amount of data from a given position of the buffer.
+
+`strbuf_splice`::
+
+ Remove the bytes between `pos..pos+len` and replace it with the given
+ data.
+
+`strbuf_add`::
+
+ Add data of given length to the buffer.
+
+`strbuf_addstr`::
+
+Add a NUL-terminated string to the buffer.
++
+NOTE: This function will *always* be implemented as an inline or a macro
+that expands to:
++
+----
+strbuf_add(..., s, strlen(s));
+----
++
+Meaning that this is efficient to write things like:
++
+----
+strbuf_addstr(sb, "immediate string");
+----
+
+`strbuf_addbuf`::
+
+ Copy the contents of an other buffer at the end of the current one.
+
+`strbuf_adddup`::
+
+ Copy part of the buffer from a given position till a given length to the
+ end of the buffer.
+
+`strbuf_expand`::
+
+ This function can be used to expand a format string containing
+ placeholders. To that end, it parses the string and calls the specified
+ function for every percent sign found.
++
+The callback function is given a pointer to the character after the `%`
+and a pointer to the struct strbuf. It is expected to add the expanded
+version of the placeholder to the strbuf, e.g. to add a newline
+character if the letter `n` appears after a `%`. The function returns
+the length of the placeholder recognized and `strbuf_expand()` skips
+over it.
++
+All other characters (non-percent and not skipped ones) are copied
+verbatim to the strbuf. If the callback returned zero, meaning that the
+placeholder is unknown, then the percent sign is copied, too.
++
+In order to facilitate caching and to make it possible to give
+parameters to the callback, `strbuf_expand()` passes a context pointer,
+which can be used by the programmer of the callback as she sees fit.
+
+`strbuf_addf`::
+
+ Add a formatted string to the buffer.
+
+`strbuf_fread`::
+
+ Read a given size of data from a FILE* pointer to the buffer.
++
+NOTE: The buffer is rewinded if the read fails. If -1 is returned,
+`errno` must be consulted, like you would do for `read(3)`.
+`strbuf_read()`, `strbuf_read_file()` and `strbuf_getline()` has the
+same behaviour as well.
+
+`strbuf_read`::
+
+ Read the contents of a given file descriptor. The third argument can be
+ used to give a hint about the file size, to avoid reallocs.
+
+`strbuf_read_file`::
+
+ Read the contents of a file, specified by its path. The third argument
+ can be used to give a hint about the file size, to avoid reallocs.
+
+`strbuf_getline`::
+
+ Read a line from a FILE* pointer. The second argument specifies the line
+ terminator character, typically `'\n'`.
+
+`stripspace`::
+
+ Strip whitespace from a buffer. The second parameter controls if
+ comments are considered contents to be removed or not.
+
+`launch_editor`::
diff --git a/Documentation/technical/api-tree-walking.txt b/Documentation/technical/api-tree-walking.txt
new file mode 100644
index 0000000000..e3ddf91284
--- /dev/null
+++ b/Documentation/technical/api-tree-walking.txt
@@ -0,0 +1,12 @@
+tree walking API
+================
+
+Talk about <tree-walk.h>, things like
+
+* struct tree_desc
+* init_tree_desc
+* tree_entry_extract
+* update_tree_entry
+* get_tree_entry
+
+(JC, Linus)
diff --git a/Documentation/technical/api-xdiff-interface.txt b/Documentation/technical/api-xdiff-interface.txt
new file mode 100644
index 0000000000..6296ecad1d
--- /dev/null
+++ b/Documentation/technical/api-xdiff-interface.txt
@@ -0,0 +1,7 @@
+xdiff interface API
+===================
+
+Talk about our calling convention to xdiff library, including
+xdiff_emit_consume_fn.
+
+(Dscho, JC)
diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt
new file mode 100644
index 0000000000..1803e64e46
--- /dev/null
+++ b/Documentation/technical/pack-format.txt
@@ -0,0 +1,160 @@
+GIT pack format
+===============
+
+= pack-*.pack files have the following format:
+
+ - A header appears at the beginning and consists of the following:
+
+ 4-byte signature:
+ The signature is: {'P', 'A', 'C', 'K'}
+
+ 4-byte version number (network byte order):
+ GIT currently accepts version number 2 or 3 but
+ generates version 2 only.
+
+ 4-byte number of objects contained in the pack (network byte order)
+
+ Observation: we cannot have more than 4G versions ;-) and
+ more than 4G objects in a pack.
+
+ - The header is followed by number of object entries, each of
+ which looks like this:
+
+ (undeltified representation)
+ n-byte type and length (3-bit type, (n-1)*7+4-bit length)
+ compressed data
+
+ (deltified representation)
+ n-byte type and length (3-bit type, (n-1)*7+4-bit length)
+ 20-byte base object name
+ compressed delta data
+
+ Observation: length of each object is encoded in a variable
+ length format and is not constrained to 32-bit or anything.
+
+ - The trailer records 20-byte SHA1 checksum of all of the above.
+
+= Original (version 1) pack-*.idx files have the following format:
+
+ - The header consists of 256 4-byte network byte order
+ integers. N-th entry of this table records the number of
+ objects in the corresponding pack, the first byte of whose
+ object name is less than or equal to N. This is called the
+ 'first-level fan-out' table.
+
+ - The header is followed by sorted 24-byte entries, one entry
+ per object in the pack. Each entry is:
+
+ 4-byte network byte order integer, recording where the
+ object is stored in the packfile as the offset from the
+ beginning.
+
+ 20-byte object name.
+
+ - The file is concluded with a trailer:
+
+ A copy of the 20-byte SHA1 checksum at the end of
+ corresponding packfile.
+
+ 20-byte SHA1-checksum of all of the above.
+
+Pack Idx file:
+
+ -- +--------------------------------+
+fanout | fanout[0] = 2 (for example) |-.
+table +--------------------------------+ |
+ | fanout[1] | |
+ +--------------------------------+ |
+ | fanout[2] | |
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
+ | fanout[255] = total objects |---.
+ -- +--------------------------------+ | |
+main | offset | | |
+index | object name 00XXXXXXXXXXXXXXXX | | |
+table +--------------------------------+ | |
+ | offset | | |
+ | object name 00XXXXXXXXXXXXXXXX | | |
+ +--------------------------------+<+ |
+ .-| offset | |
+ | | object name 01XXXXXXXXXXXXXXXX | |
+ | +--------------------------------+ |
+ | | offset | |
+ | | object name 01XXXXXXXXXXXXXXXX | |
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
+ | | offset | |
+ | | object name FFXXXXXXXXXXXXXXXX | |
+ --| +--------------------------------+<--+
+trailer | | packfile checksum |
+ | +--------------------------------+
+ | | idxfile checksum |
+ | +--------------------------------+
+ .-------.
+ |
+Pack file entry: <+
+
+ packed object header:
+ 1-byte size extension bit (MSB)
+ type (next 3 bit)
+ size0 (lower 4-bit)
+ n-byte sizeN (as long as MSB is set, each 7-bit)
+ size0..sizeN form 4+7+7+..+7 bit integer, size0
+ is the least significant part, and sizeN is the
+ most significant part.
+ packed object data:
+ If it is not DELTA, then deflated bytes (the size above
+ is the size before compression).
+ If it is REF_DELTA, then
+ 20-byte base object name SHA1 (the size above is the
+ size of the delta data that follows).
+ delta data, deflated.
+ If it is OFS_DELTA, then
+ n-byte offset (see below) interpreted as a negative
+ offset from the type-byte of the header of the
+ ofs-delta entry (the size above is the size of
+ the delta data that follows).
+ delta data, deflated.
+
+ offset encoding:
+ n bytes with MSB set in all but the last one.
+ The offset is then the number constructed by
+ concatenating the lower 7 bit of each byte, and
+ for n >= 2 adding 2^7 + 2^14 + ... + 2^(7*(n-1))
+ to the result.
+
+
+
+= Version 2 pack-*.idx files support packs larger than 4 GiB, and
+ have some other reorganizations. They have the format:
+
+ - A 4-byte magic number '\377tOc' which is an unreasonable
+ fanout[0] value.
+
+ - A 4-byte version number (= 2)
+
+ - A 256-entry fan-out table just like v1.
+
+ - A table of sorted 20-byte SHA1 object names. These are
+ packed together without offset values to reduce the cache
+ footprint of the binary search for a specific object name.
+
+ - A table of 4-byte CRC32 values of the packed object data.
+ This is new in v2 so compressed data can be copied directly
+ from pack to pack during repacking without undetected
+ data corruption.
+
+ - A table of 4-byte offset values (in network byte order).
+ These are usually 31-bit pack file offsets, but large
+ offsets are encoded as an index into the next table with
+ the msbit set.
+
+ - A table of 8-byte offset entries (empty for pack files less
+ than 2 GiB). Pack files are organized with heavily used
+ objects toward the front, so most object references should
+ not need to refer to this table.
+
+ - The same trailer as a v1 pack file:
+
+ A copy of the 20-byte SHA1 checksum at the end of
+ corresponding packfile.
+
+ 20-byte SHA1-checksum of all of the above.
diff --git a/Documentation/technical/pack-heuristics.txt b/Documentation/technical/pack-heuristics.txt
new file mode 100644
index 0000000000..103eb5d989
--- /dev/null
+++ b/Documentation/technical/pack-heuristics.txt
@@ -0,0 +1,466 @@
+ Concerning Git's Packing Heuristics
+ ===================================
+
+ Oh, here's a really stupid question:
+
+ Where do I go
+ to learn the details
+ of git's packing heuristics?
+
+Be careful what you ask!
+
+Followers of the git, please open the git IRC Log and turn to
+February 10, 2006.
+
+It's a rare occasion, and we are joined by the King Git Himself,
+Linus Torvalds (linus). Nathaniel Smith, (njs`), has the floor
+and seeks enlightenment. Others are present, but silent.
+
+Let's listen in!
+
+ <njs`> Oh, here's a really stupid question -- where do I go to
+ learn the details of git's packing heuristics? google avails
+ me not, reading the source didn't help a lot, and wading
+ through the whole mailing list seems less efficient than any
+ of that.
+
+It is a bold start! A plea for help combined with a simultaneous
+tri-part attack on some of the tried and true mainstays in the quest
+for enlightenment. Brash accusations of google being useless. Hubris!
+Maligning the source. Heresy! Disdain for the mailing list archives.
+Woe.
+
+ <pasky> yes, the packing-related delta stuff is somewhat
+ mysterious even for me ;)
+
+Ah! Modesty after all.
+
+ <linus> njs, I don't think the docs exist. That's something where
+ I don't think anybody else than me even really got involved.
+ Most of the rest of git others have been busy with (especially
+ Junio), but packing nobody touched after I did it.
+
+It's cryptic, yet vague. Linus in style for sure. Wise men
+interpret this as an apology. A few argue it is merely a
+statement of fact.
+
+ <njs`> I guess the next step is "read the source again", but I
+ have to build up a certain level of gumption first :-)
+
+Indeed! On both points.
+
+ <linus> The packing heuristic is actually really really simple.
+
+Bait...
+
+ <linus> But strange.
+
+And switch. That ought to do it!
+
+ <linus> Remember: git really doesn't follow files. So what it does is
+ - generate a list of all objects
+ - sort the list according to magic heuristics
+ - walk the list, using a sliding window, seeing if an object
+ can be diffed against another object in the window
+ - write out the list in recency order
+
+The traditional understatement:
+
+ <njs`> I suspect that what I'm missing is the precise definition of
+ the word "magic"
+
+The traditional insight:
+
+ <pasky> yes
+
+And Babel-like confusion flowed.
+
+ <njs`> oh, hmm, and I'm not sure what this sliding window means either
+
+ <pasky> iirc, it appeared to me to be just the sha1 of the object
+ when reading the code casually ...
+
+ ... which simply doesn't sound as a very good heuristics, though ;)
+
+ <njs`> .....and recency order. okay, I think it's clear I didn't
+ even realize how much I wasn't realizing :-)
+
+Ah, grasshopper! And thus the enlightenment begins anew.
+
+ <linus> The "magic" is actually in theory totally arbitrary.
+ ANY order will give you a working pack, but no, it's not
+ ordered by SHA1.
+
+ Before talking about the ordering for the sliding delta
+ window, let's talk about the recency order. That's more
+ important in one way.
+
+ <njs`> Right, but if all you want is a working way to pack things
+ together, you could just use cat and save yourself some
+ trouble...
+
+Waaait for it....
+
+ <linus> The recency ordering (which is basically: put objects
+ _physically_ into the pack in the order that they are
+ "reachable" from the head) is important.
+
+ <njs`> okay
+
+ <linus> It's important because that's the thing that gives packs
+ good locality. It keeps the objects close to the head (whether
+ they are old or new, but they are _reachable_ from the head)
+ at the head of the pack. So packs actually have absolutely
+ _wonderful_ IO patterns.
+
+Read that again, because it is important.
+
+ <linus> But recency ordering is totally useless for deciding how
+ to actually generate the deltas, so the delta ordering is
+ something else.
+
+ The delta ordering is (wait for it):
+ - first sort by the "basename" of the object, as defined by
+ the name the object was _first_ reached through when
+ generating the object list
+ - within the same basename, sort by size of the object
+ - but always sort different types separately (commits first).
+
+ That's not exactly it, but it's very close.
+
+ <njs`> The "_first_ reached" thing is not too important, just you
+ need some way to break ties since the same objects may be
+ reachable many ways, yes?
+
+And as if to clarify:
+
+ <linus> The point is that it's all really just any random
+ heuristic, and the ordering is totally unimportant for
+ correctness, but it helps a lot if the heuristic gives
+ "clumping" for things that are likely to delta well against
+ each other.
+
+It is an important point, so secretly, I did my own research and have
+included my results below. To be fair, it has changed some over time.
+And through the magic of Revisionistic History, I draw upon this entry
+from The Git IRC Logs on my father's birthday, March 1:
+
+ <gitster> The quote from the above linus should be rewritten a
+ bit (wait for it):
+ - first sort by type. Different objects never delta with
+ each other.
+ - then sort by filename/dirname. hash of the basename
+ occupies the top BITS_PER_INT-DIR_BITS bits, and bottom
+ DIR_BITS are for the hash of leading path elements.
+ - then if we are doing "thin" pack, the objects we are _not_
+ going to pack but we know about are sorted earlier than
+ other objects.
+ - and finally sort by size, larger to smaller.
+
+In one swell-foop, clarification and obscurification! Nonetheless,
+authoritative. Cryptic, yet concise. It even solicits notions of
+quotes from The Source Code. Clearly, more study is needed.
+
+ <gitster> That's the sort order. What this means is:
+ - we do not delta different object types.
+ - we prefer to delta the objects with the same full path, but
+ allow files with the same name from different directories.
+ - we always prefer to delta against objects we are not going
+ to send, if there are some.
+ - we prefer to delta against larger objects, so that we have
+ lots of removals.
+
+ The penultimate rule is for "thin" packs. It is used when
+ the other side is known to have such objects.
+
+There it is again. "Thin" packs. I'm thinking to myself, "What
+is a 'thin' pack?" So I ask:
+
+ <jdl> What is a "thin" pack?
+
+ <gitster> Use of --objects-edge to rev-list as the upstream of
+ pack-objects. The pack transfer protocol negotiates that.
+
+Woo hoo! Cleared that _right_ up!
+
+ <gitster> There are two directions - push and fetch.
+
+There! Did you see it? It is not '"push" and "pull"'! How often the
+confusion has started here. So casually mentioned, too!
+
+ <gitster> For push, git-send-pack invokes git-receive-pack on the
+ other end. The receive-pack says "I have up to these commits".
+ send-pack looks at them, and computes what are missing from
+ the other end. So "thin" could be the default there.
+
+ In the other direction, fetch, git-fetch-pack and
+ git-clone-pack invokes git-upload-pack on the other end
+ (via ssh or by talking to the daemon).
+
+ There are two cases: fetch-pack with -k and clone-pack is one,
+ fetch-pack without -k is the other. clone-pack and fetch-pack
+ with -k will keep the downloaded packfile without expanded, so
+ we do not use thin pack transfer. Otherwise, the generated
+ pack will have delta without base object in the same pack.
+
+ But fetch-pack without -k will explode the received pack into
+ individual objects, so we automatically ask upload-pack to
+ give us a thin pack if upload-pack supports it.
+
+OK then.
+
+Uh.
+
+Let's return to the previous conversation still in progress.
+
+ <njs`> and "basename" means something like "the tail of end of
+ path of file objects and dir objects, as per basename(3), and
+ we just declare all commit and tag objects to have the same
+ basename" or something?
+
+Luckily, that too is a point that gitster clarified for us!
+
+If I might add, the trick is to make files that _might_ be similar be
+located close to each other in the hash buckets based on their file
+names. It used to be that "foo/Makefile", "bar/baz/quux/Makefile" and
+"Makefile" all landed in the same bucket due to their common basename,
+"Makefile". However, now they land in "close" buckets.
+
+The algorithm allows not just for the _same_ bucket, but for _close_
+buckets to be considered delta candidates. The rationale is
+essentially that files, like Makefiles, often have very similar
+content no matter what directory they live in.
+
+ <linus> I played around with different delta algorithms, and with
+ making the "delta window" bigger, but having too big of a
+ sliding window makes it very expensive to generate the pack:
+ you need to compare every object with a _ton_ of other objects.
+
+ There are a number of other trivial heuristics too, which
+ basically boil down to "don't bother even trying to delta this
+ pair" if we can tell before-hand that the delta isn't worth it
+ (due to size differences, where we can take a previous delta
+ result into account to decide that "ok, no point in trying
+ that one, it will be worse").
+
+ End result: packing is actually very size efficient. It's
+ somewhat CPU-wasteful, but on the other hand, since you're
+ really only supposed to do it maybe once a month (and you can
+ do it during the night), nobody really seems to care.
+
+Nice Engineering Touch, there. Find when it doesn't matter, and
+proclaim it a non-issue. Good style too!
+
+ <njs`> So, just to repeat to see if I'm following, we start by
+ getting a list of the objects we want to pack, we sort it by
+ this heuristic (basically lexicographically on the tuple
+ (type, basename, size)).
+
+ Then we walk through this list, and calculate a delta of
+ each object against the last n (tunable parameter) objects,
+ and pick the smallest of these deltas.
+
+Vastly simplified, but the essence is there!
+
+ <linus> Correct.
+
+ <njs`> And then once we have picked a delta or fulltext to
+ represent each object, we re-sort by recency, and write them
+ out in that order.
+
+ <linus> Yup. Some other small details:
+
+And of course there is the "Other Shoe" Factor too.
+
+ <linus> - We limit the delta depth to another magic value (right
+ now both the window and delta depth magic values are just "10")
+
+ <njs`> Hrm, my intuition is that you'd end up with really _bad_ IO
+ patterns, because the things you want are near by, but to
+ actually reconstruct them you may have to jump all over in
+ random ways.
+
+ <linus> - When we write out a delta, and we haven't yet written
+ out the object it is a delta against, we write out the base
+ object first. And no, when we reconstruct them, we actually
+ get nice IO patterns, because:
+ - larger objects tend to be "more recent" (Linus' law: files grow)
+ - we actively try to generate deltas from a larger object to a
+ smaller one
+ - this means that the top-of-tree very seldom has deltas
+ (i.e. deltas in _practice_ are "backwards deltas")
+
+Again, we should reread that whole paragraph. Not just because
+Linus has slipped Linus's Law in there on us, but because it is
+important. Let's make sure we clarify some of the points here:
+
+ <njs`> So the point is just that in practice, delta order and
+ recency order match each other quite well.
+
+ <linus> Yes. There's another nice side to this (and yes, it was
+ designed that way ;):
+ - the reason we generate deltas against the larger object is
+ actually a big space saver too!
+
+ <njs`> Hmm, but your last comment (if "we haven't yet written out
+ the object it is a delta against, we write out the base object
+ first"), seems like it would make these facts mostly
+ irrelevant because even if in practice you would not have to
+ wander around much, in fact you just brute-force say that in
+ the cases where you might have to wander, don't do that :-)
+
+ <linus> Yes and no. Notice the rule: we only write out the base
+ object first if the delta against it was more recent. That
+ means that you can actually have deltas that refer to a base
+ object that is _not_ close to the delta object, but that only
+ happens when the delta is needed to generate an _old_ object.
+
+ <linus> See?
+
+Yeah, no. I missed that on the first two or three readings myself.
+
+ <linus> This keeps the front of the pack dense. The front of the
+ pack never contains data that isn't relevant to a "recent"
+ object. The size optimization comes from our use of xdelta
+ (but is true for many other delta algorithms): removing data
+ is cheaper (in size) than adding data.
+
+ When you remove data, you only need to say "copy bytes n--m".
+ In contrast, in a delta that _adds_ data, you have to say "add
+ these bytes: 'actual data goes here'"
+
+ *** njs` has quit: Read error: 104 (Connection reset by peer)
+
+ <linus> Uhhuh. I hope I didn't blow njs` mind.
+
+ *** njs` has joined channel #git
+
+ <pasky> :)
+
+The silent observers are amused. Of course.
+
+And as if njs` was expected to be omniscient:
+
+ <linus> njs - did you miss anything?
+
+OK, I'll spell it out. That's Geek Humor. If njs` was not actually
+connected for a little bit there, how would he know if missed anything
+while he was disconnected? He's a benevolent dictator with a sense of
+humor! Well noted!
+
+ <njs`> Stupid router. Or gremlins, or whatever.
+
+It's a cheap shot at Cisco. Take 'em when you can.
+
+ <njs`> Yes and no. Notice the rule: we only write out the base
+ object first if the delta against it was more recent.
+
+ I'm getting lost in all these orders, let me re-read :-)
+ So the write-out order is from most recent to least recent?
+ (Conceivably it could be the opposite way too, I'm not sure if
+ we've said) though my connection back at home is logging, so I
+ can just read what you said there :-)
+
+And for those of you paying attention, the Omniscient Trick has just
+been detailed!
+
+ <linus> Yes, we always write out most recent first
+
+For the other record:
+
+ <pasky> njs`: http://pastebin.com/547965
+
+The 'net never forgets, so that should be good until the end of time.
+
+ <njs`> And, yeah, I got the part about deeper-in-history stuff
+ having worse IO characteristics, one sort of doesn't care.
+
+ <linus> With the caveat that if the "most recent" needs an older
+ object to delta against (hey, shrinking sometimes does
+ happen), we write out the old object with the delta.
+
+ <njs`> (if only it happened more...)
+
+ <linus> Anyway, the pack-file could easily be denser still, but
+ because it's used both for streaming (the git protocol) and
+ for on-disk, it has a few pessimizations.
+
+Actually, it is a made-up word. But it is a made-up word being
+used as setup for a later optimization, which is a real word:
+
+ <linus> In particular, while the pack-file is then compressed,
+ it's compressed just one object at a time, so the actual
+ compression factor is less than it could be in theory. But it
+ means that it's all nice random-access with a simple index to
+ do "object name->location in packfile" translation.
+
+ <njs`> I'm assuming the real win for delta-ing large->small is
+ more homogeneous statistics for gzip to run over?
+
+ (You have to put the bytes in one place or another, but
+ putting them in a larger blob wins on compression)
+
+ Actually, what is the compression strategy -- each delta
+ individually gzipped, the whole file gzipped, somewhere in
+ between, no compression at all, ....?
+
+ Right.
+
+Reality IRC sets in. For example:
+
+ <pasky> I'll read the rest in the morning, I really have to go
+ sleep or there's no hope whatsoever for me at the today's
+ exam... g'nite all.
+
+Heh.
+
+ <linus> pasky: g'nite
+
+ <njs`> pasky: 'luck
+
+ <linus> Right: large->small matters exactly because of compression
+ behaviour. If it was non-compressed, it probably wouldn't make
+ any difference.
+
+ <njs`> yeah
+
+ <linus> Anyway: I'm not even trying to claim that the pack-files
+ are perfect, but they do tend to have a nice balance of
+ density vs ease-of use.
+
+Gasp! OK, saved. That's a fair Engineering trade off. Close call!
+In fact, Linus reflects on some Basic Engineering Fundamentals,
+design options, etc.
+
+ <linus> More importantly, they allow git to still _conceptually_
+ never deal with deltas at all, and be a "whole object" store.
+
+ Which has some problems (we discussed bad huge-file
+ behaviour on the git lists the other day), but it does mean
+ that the basic git concepts are really really simple and
+ straightforward.
+
+ It's all been quite stable.
+
+ Which I think is very much a result of having very simple
+ basic ideas, so that there's never any confusion about what's
+ going on.
+
+ Bugs happen, but they are "simple" bugs. And bugs that
+ actually get some object store detail wrong are almost always
+ so obvious that they never go anywhere.
+
+ <njs`> Yeah.
+
+Nuff said.
+
+ <linus> Anyway. I'm off for bed. It's not 6AM here, but I've got
+ three kids, and have to get up early in the morning to send
+ them off. I need my beauty sleep.
+
+ <njs`> :-)
+
+ <njs`> appreciate the infodump, I really was failing to find the
+ details on git packs :-)
+
+And now you know the rest of the story.
diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt
new file mode 100644
index 0000000000..9cd48b4859
--- /dev/null
+++ b/Documentation/technical/pack-protocol.txt
@@ -0,0 +1,41 @@
+Pack transfer protocols
+=======================
+
+There are two Pack push-pull protocols.
+
+upload-pack (S) | fetch/clone-pack (C) protocol:
+
+ # Tell the puller what commits we have and what their names are
+ S: SHA1 name
+ S: ...
+ S: SHA1 name
+ S: # flush -- it's your turn
+ # Tell the pusher what commits we want, and what we have
+ C: want name
+ C: ..
+ C: want name
+ C: have SHA1
+ C: have SHA1
+ C: ...
+ C: # flush -- occasionally ask "had enough?"
+ S: NAK
+ C: have SHA1
+ C: ...
+ C: have SHA1
+ S: ACK
+ C: done
+ S: XXXXXXX -- packfile contents.
+
+send-pack | receive-pack protocol.
+
+ # Tell the pusher what commits we have and what their names are
+ C: SHA1 name
+ C: ...
+ C: SHA1 name
+ C: # flush -- it's your turn
+ # Tell the puller what the pusher has
+ S: old-SHA1 new-SHA1 name
+ S: old-SHA1 new-SHA1 name
+ S: ...
+ S: # flush -- done with the list
+ S: XXXXXXX --- packfile contents.
diff --git a/Documentation/technical/racy-git.txt b/Documentation/technical/racy-git.txt
new file mode 100644
index 0000000000..6bdf034b3a
--- /dev/null
+++ b/Documentation/technical/racy-git.txt
@@ -0,0 +1,195 @@
+Use of index and Racy git problem
+=================================
+
+Background
+----------
+
+The index is one of the most important data structures in git.
+It represents a virtual working tree state by recording list of
+paths and their object names and serves as a staging area to
+write out the next tree object to be committed. The state is
+"virtual" in the sense that it does not necessarily have to, and
+often does not, match the files in the working tree.
+
+There are cases git needs to examine the differences between the
+virtual working tree state in the index and the files in the
+working tree. The most obvious case is when the user asks `git
+diff` (or its low level implementation, `git diff-files`) or
+`git-ls-files --modified`. In addition, git internally checks
+if the files in the working tree are different from what are
+recorded in the index to avoid stomping on local changes in them
+during patch application, switching branches, and merging.
+
+In order to speed up this comparison between the files in the
+working tree and the index entries, the index entries record the
+information obtained from the filesystem via `lstat(2)` system
+call when they were last updated. When checking if they differ,
+git first runs `lstat(2)` on the files and compares the result
+with this information (this is what was originally done by the
+`ce_match_stat()` function, but the current code does it in
+`ce_match_stat_basic()` function). If some of these "cached
+stat information" fields do not match, git can tell that the
+files are modified without even looking at their contents.
+
+Note: not all members in `struct stat` obtained via `lstat(2)`
+are used for this comparison. For example, `st_atime` obviously
+is not useful. Currently, git compares the file type (regular
+files vs symbolic links) and executable bits (only for regular
+files) from `st_mode` member, `st_mtime` and `st_ctime`
+timestamps, `st_uid`, `st_gid`, `st_ino`, and `st_size` members.
+With a `USE_STDEV` compile-time option, `st_dev` is also
+compared, but this is not enabled by default because this member
+is not stable on network filesystems. With `USE_NSEC`
+compile-time option, `st_mtim.tv_nsec` and `st_ctim.tv_nsec`
+members are also compared, but this is not enabled by default
+because the value of this member becomes meaningless once the
+inode is evicted from the inode cache on filesystems that do not
+store it on disk.
+
+
+Racy git
+--------
+
+There is one slight problem with the optimization based on the
+cached stat information. Consider this sequence:
+
+ : modify 'foo'
+ $ git update-index 'foo'
+ : modify 'foo' again, in-place, without changing its size
+
+The first `update-index` computes the object name of the
+contents of file `foo` and updates the index entry for `foo`
+along with the `struct stat` information. If the modification
+that follows it happens very fast so that the file's `st_mtime`
+timestamp does not change, after this sequence, the cached stat
+information the index entry records still exactly match what you
+would see in the filesystem, even though the file `foo` is now
+different.
+This way, git can incorrectly think files in the working tree
+are unmodified even though they actually are. This is called
+the "racy git" problem (discovered by Pasky), and the entries
+that appear clean when they may not be because of this problem
+are called "racily clean".
+
+To avoid this problem, git does two things:
+
+. When the cached stat information says the file has not been
+ modified, and the `st_mtime` is the same as (or newer than)
+ the timestamp of the index file itself (which is the time `git
+ update-index foo` finished running in the above example), it
+ also compares the contents with the object registered in the
+ index entry to make sure they match.
+
+. When the index file is updated that contains racily clean
+ entries, cached `st_size` information is truncated to zero
+ before writing a new version of the index file.
+
+Because the index file itself is written after collecting all
+the stat information from updated paths, `st_mtime` timestamp of
+it is usually the same as or newer than any of the paths the
+index contains. And no matter how quick the modification that
+follows `git update-index foo` finishes, the resulting
+`st_mtime` timestamp on `foo` cannot get a value earlier
+than the index file. Therefore, index entries that can be
+racily clean are limited to the ones that have the same
+timestamp as the index file itself.
+
+The callers that want to check if an index entry matches the
+corresponding file in the working tree continue to call
+`ce_match_stat()`, but with this change, `ce_match_stat()` uses
+`ce_modified_check_fs()` to see if racily clean ones are
+actually clean after comparing the cached stat information using
+`ce_match_stat_basic()`.
+
+The problem the latter solves is this sequence:
+
+ $ git update-index 'foo'
+ : modify 'foo' in-place without changing its size
+ : wait for enough time
+ $ git update-index 'bar'
+
+Without the latter, the timestamp of the index file gets a newer
+value, and falsely clean entry `foo` would not be caught by the
+timestamp comparison check done with the former logic anymore.
+The latter makes sure that the cached stat information for `foo`
+would never match with the file in the working tree, so later
+checks by `ce_match_stat_basic()` would report that the index entry
+does not match the file and git does not have to fall back on more
+expensive `ce_modified_check_fs()`.
+
+
+Runtime penalty
+---------------
+
+The runtime penalty of falling back to `ce_modified_check_fs()`
+from `ce_match_stat()` can be very expensive when there are many
+racily clean entries. An obvious way to artificially create
+this situation is to give the same timestamp to all the files in
+the working tree in a large project, run `git update-index` on
+them, and give the same timestamp to the index file:
+
+ $ date >.datestamp
+ $ git ls-files | xargs touch -r .datestamp
+ $ git ls-files | git update-index --stdin
+ $ touch -r .datestamp .git/index
+
+This will make all index entries racily clean. The linux-2.6
+project, for example, there are over 20,000 files in the working
+tree. On my Athron 64X2 3800+, after the above:
+
+ $ /usr/bin/time git diff-files
+ 1.68user 0.54system 0:02.22elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
+ 0inputs+0outputs (0major+67111minor)pagefaults 0swaps
+ $ git update-index MAINTAINERS
+ $ /usr/bin/time git diff-files
+ 0.02user 0.12system 0:00.14elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
+ 0inputs+0outputs (0major+935minor)pagefaults 0swaps
+
+Running `git update-index` in the middle checked the racily
+clean entries, and left the cached `st_mtime` for all the paths
+intact because they were actually clean (so this step took about
+the same amount of time as the first `git diff-files`). After
+that, they are not racily clean anymore but are truly clean, so
+the second invocation of `git diff-files` fully took advantage
+of the cached stat information.
+
+
+Avoiding runtime penalty
+------------------------
+
+In order to avoid the above runtime penalty, post 1.4.2 git used
+to have a code that made sure the index file
+got timestamp newer than the youngest files in the index when
+there are many young files with the same timestamp as the
+resulting index file would otherwise would have by waiting
+before finishing writing the index file out.
+
+I suspected that in practice the situation where many paths in the
+index are all racily clean was quite rare. The only code paths
+that can record recent timestamp for large number of paths are:
+
+. Initial `git add .` of a large project.
+
+. `git checkout` of a large project from an empty index into an
+ unpopulated working tree.
+
+Note: switching branches with `git checkout` keeps the cached
+stat information of existing working tree files that are the
+same between the current branch and the new branch, which are
+all older than the resulting index file, and they will not
+become racily clean. Only the files that are actually checked
+out can become racily clean.
+
+In a large project where raciness avoidance cost really matters,
+however, the initial computation of all object names in the
+index takes more than one second, and the index file is written
+out after all that happens. Therefore the timestamp of the
+index file will be more than one seconds later than the
+youngest file in the working tree. This means that in these
+cases there actually will not be any racily clean entry in
+the resulting index.
+
+Based on this discussion, the current code does not use the
+"workaround" to avoid the runtime penalty that does not exist in
+practice anymore. This was done with commit 0fc82cff on Aug 15,
+2006.
diff --git a/Documentation/technical/send-pack-pipeline.txt b/Documentation/technical/send-pack-pipeline.txt
new file mode 100644
index 0000000000..681efe4219
--- /dev/null
+++ b/Documentation/technical/send-pack-pipeline.txt
@@ -0,0 +1,63 @@
+git-send-pack
+=============
+
+Overall operation
+-----------------
+
+. Connects to the remote side and invokes git-receive-pack.
+
+. Learns what refs the remote has and what commit they point at.
+ Matches them to the refspecs we are pushing.
+
+. Checks if there are non-fast-forwards. Unlike fetch-pack,
+ the repository send-pack runs in is supposed to be a superset
+ of the recipient in fast-forward cases, so there is no need
+ for want/have exchanges, and fast-forward check can be done
+ locally. Tell the result to the other end.
+
+. Calls pack_objects() which generates a packfile and sends it
+ over to the other end.
+
+. If the remote side is new enough (v1.1.0 or later), wait for
+ the unpack and hook status from the other end.
+
+. Exit with appropriate error codes.
+
+
+Pack_objects pipeline
+---------------------
+
+This function gets one file descriptor (`fd`) which is either a
+socket (over the network) or a pipe (local). What's written to
+this fd goes to git-receive-pack to be unpacked.
+
+ send-pack ---> fd ---> receive-pack
+
+The function pack_objects creates a pipe and then forks. The
+forked child execs pack-objects with --revs to receive revision
+parameters from its standard input. This process will write the
+packfile to the other end.
+
+ send-pack
+ |
+ pack_objects() ---> fd ---> receive-pack
+ | ^ (pipe)
+ v |
+ (child)
+
+The child dup2's to arrange its standard output to go back to
+the other end, and read its standard input to come from the
+pipe. After that it exec's pack-objects. On the other hand,
+the parent process, before starting to feed the child pipeline,
+closes the reading side of the pipe and fd to receive-pack.
+
+ send-pack
+ |
+ pack_objects(parent)
+ |
+ v [0]
+ pack-objects [0] ---> receive-pack
+
+
+[jc: the pipeline was much more complex and needed documentation before
+ I understood an earlier bug, but now it is trivial and straightforward.]
diff --git a/Documentation/technical/shallow.txt b/Documentation/technical/shallow.txt
new file mode 100644
index 0000000000..559263af48
--- /dev/null
+++ b/Documentation/technical/shallow.txt
@@ -0,0 +1,49 @@
+Def.: Shallow commits do have parents, but not in the shallow
+repo, and therefore grafts are introduced pretending that
+these commits have no parents.
+
+The basic idea is to write the SHA1s of shallow commits into
+$GIT_DIR/shallow, and handle its contents like the contents
+of $GIT_DIR/info/grafts (with the difference that shallow
+cannot contain parent information).
+
+This information is stored in a new file instead of grafts, or
+even the config, since the user should not touch that file
+at all (even throughout development of the shallow clone, it
+was never manually edited!).
+
+Each line contains exactly one SHA1. When read, a commit_graft
+will be constructed, which has nr_parent < 0 to make it easier
+to discern from user provided grafts.
+
+Since fsck-objects relies on the library to read the objects,
+it honours shallow commits automatically.
+
+There are some unfinished ends of the whole shallow business:
+
+- maybe we have to force non-thin packs when fetching into a
+ shallow repo (ATM they are forced non-thin).
+
+- A special handling of a shallow upstream is needed. At some
+ stage, upload-pack has to check if it sends a shallow commit,
+ and it should send that information early (or fail, if the
+ client does not support shallow repositories). There is no
+ support at all for this in this patch series.
+
+- Instead of locking $GIT_DIR/shallow at the start, just
+ the timestamp of it is noted, and when it comes to writing it,
+ a check is performed if the mtime is still the same, dying if
+ it is not.
+
+- It is unclear how "push into/from a shallow repo" should behave.
+
+- If you deepen a history, you'd want to get the tags of the
+ newly stored (but older!) commits. This does not work right now.
+
+To make a shallow clone, you can call "git-clone --depth 20 repo".
+The result contains only commit chains with a length of at most 20.
+It also writes an appropriate $GIT_DIR/shallow.
+
+You can deepen a shallow repository with "git-fetch --depth 20
+repo branch", which will fetch branch from repo, but stop at depth
+20, updating $GIT_DIR/shallow.
diff --git a/Documentation/technical/trivial-merge.txt b/Documentation/technical/trivial-merge.txt
new file mode 100644
index 0000000000..24c84100b0
--- /dev/null
+++ b/Documentation/technical/trivial-merge.txt
@@ -0,0 +1,121 @@
+Trivial merge rules
+===================
+
+This document describes the outcomes of the trivial merge logic in read-tree.
+
+One-way merge
+-------------
+
+This replaces the index with a different tree, keeping the stat info
+for entries that don't change, and allowing -u to make the minimum
+required changes to the working tree to have it match.
+
+Entries marked '+' have stat information. Spaces marked '*' don't
+affect the result.
+
+ index tree result
+ -----------------------
+ * (empty) (empty)
+ (empty) tree tree
+ index+ tree tree
+ index+ index index+
+
+Two-way merge
+-------------
+
+It is permitted for the index to lack an entry; this does not prevent
+any case from applying.
+
+If the index exists, it is an error for it not to match either the old
+or the result.
+
+If multiple cases apply, the one used is listed first.
+
+A result which changes the index is an error if the index is not empty
+and not up-to-date.
+
+Entries marked '+' have stat information. Spaces marked '*' don't
+affect the result.
+
+ case index old new result
+ -------------------------------------
+ 0/2 (empty) * (empty) (empty)
+ 1/3 (empty) * new new
+ 4/5 index+ (empty) (empty) index+
+ 6/7 index+ (empty) index index+
+ 10 index+ index (empty) (empty)
+ 14/15 index+ old old index+
+ 18/19 index+ old index index+
+ 20 index+ index new new
+
+Three-way merge
+---------------
+
+It is permitted for the index to lack an entry; this does not prevent
+any case from applying.
+
+If the index exists, it is an error for it not to match either the
+head or (if the merge is trivial) the result.
+
+If multiple cases apply, the one used is listed first.
+
+A result of "no merge" means that index is left in stage 0, ancest in
+stage 1, head in stage 2, and remote in stage 3 (if any of these are
+empty, no entry is left for that stage). Otherwise, the given entry is
+left in stage 0, and there are no other entries.
+
+A result of "no merge" is an error if the index is not empty and not
+up-to-date.
+
+*empty* means that the tree must not have a directory-file conflict
+ with the entry.
+
+For multiple ancestors, a '+' means that this case applies even if
+only one ancestor or remote fits; a '^' means all of the ancestors
+must be the same.
+
+case ancest head remote result
+----------------------------------------
+1 (empty)+ (empty) (empty) (empty)
+2ALT (empty)+ *empty* remote remote
+2 (empty)^ (empty) remote no merge
+3ALT (empty)+ head *empty* head
+3 (empty)^ head (empty) no merge
+4 (empty)^ head remote no merge
+5ALT * head head head
+6 ancest+ (empty) (empty) no merge
+8 ancest^ (empty) ancest no merge
+7 ancest+ (empty) remote no merge
+10 ancest^ ancest (empty) no merge
+9 ancest+ head (empty) no merge
+16 anc1/anc2 anc1 anc2 no merge
+13 ancest+ head ancest head
+14 ancest+ ancest remote remote
+11 ancest+ head remote no merge
+
+Only #2ALT and #3ALT use *empty*, because these are the only cases
+where there can be conflicts that didn't exist before. Note that we
+allow directory-file conflicts between things in different stages
+after the trivial merge.
+
+A possible alternative for #6 is (empty), which would make it like
+#1. This is not used, due to the likelihood that it arises due to
+moving the file to multiple different locations or moving and deleting
+it in different branches.
+
+Case #1 is included for completeness, and also in case we decide to
+put on '+' markings; any path that is never mentioned at all isn't
+handled.
+
+Note that #16 is when both #13 and #14 apply; in this case, we refuse
+the trivial merge, because we can't tell from this data which is
+right. This is a case of a reverted patch (in some direction, maybe
+multiple times), and the right answer depends on looking at crossings
+of history or common ancestors of the ancestors.
+
+Note that, between #6, #7, #9, and #11, all cases not otherwise
+covered are handled in this table.
+
+For #8 and #10, there is alternative behavior, not currently
+implemented, where the result is (empty). As currently implemented,
+the automatic merge will generally give this effect.
diff --git a/Documentation/urls-remotes.txt b/Documentation/urls-remotes.txt
new file mode 100644
index 0000000000..99753006e2
--- /dev/null
+++ b/Documentation/urls-remotes.txt
@@ -0,0 +1,82 @@
+include::urls.txt[]
+
+REMOTES[[REMOTES]]
+------------------
+
+The name of one of the following can be used instead
+of a URL as `<repository>` argument:
+
+* a remote in the git configuration file: `$GIT_DIR/config`,
+* a file in the `$GIT_DIR/remotes` directory, or
+* a file in the `$GIT_DIR/branches` directory.
+
+All of these also allow you to omit the refspec from the command line
+because they each contain a refspec which git will use by default.
+
+Named remote in configuration file
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can choose to provide the name of a remote which you had previously
+configured using linkgit:git-remote[1], linkgit:git-config[1]
+or even by a manual edit to the `$GIT_DIR/config` file. The URL of
+this remote will be used to access the repository. The refspec
+of this remote will be used by default when you do
+not provide a refspec on the command line. The entry in the
+config file would appear like this:
+
+------------
+ [remote "<name>"]
+ url = <url>
+ push = <refspec>
+ fetch = <refspec>
+------------
+
+
+Named file in `$GIT_DIR/remotes`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can choose to provide the name of a
+file in `$GIT_DIR/remotes`. The URL
+in this file will be used to access the repository. The refspec
+in this file will be used as default when you do not
+provide a refspec on the command line. This file should have the
+following format:
+
+------------
+ URL: one of the above URL format
+ Push: <refspec>
+ Pull: <refspec>
+
+------------
+
+`Push:` lines are used by `git-push` and
+`Pull:` lines are used by `git-pull` and `git-fetch`.
+Multiple `Push:` and `Pull:` lines may
+be specified for additional branch mappings.
+
+Named file in `$GIT_DIR/branches`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can choose to provide the name of a
+file in `$GIT_DIR/branches`.
+The URL in this file will be used to access the repository.
+This file should have the following format:
+
+
+------------
+ <url>#<head>
+------------
+
+`<url>` is required; `#<head>` is optional.
+When you do not provide a refspec on the command line,
+git will use the following refspec, where `<head>` defaults to `master`,
+and `<repository>` is the name of this file
+you provided in the command line.
+
+------------
+ refs/heads/<head>:<repository>
+------------
+
+
+
+
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
new file mode 100644
index 0000000000..fa34c67471
--- /dev/null
+++ b/Documentation/urls.txt
@@ -0,0 +1,69 @@
+GIT URLS[[URLS]]
+----------------
+
+One of the following notations can be used
+to name the remote repository:
+
+===============================================================
+- rsync://host.xz/path/to/repo.git/
+- http://host.xz/path/to/repo.git/
+- https://host.xz/path/to/repo.git/
+- git://host.xz/path/to/repo.git/
+- git://host.xz/~user/path/to/repo.git/
+- ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/path/to/repo.git/
+- ssh://{startsb}user@{endsb}host.xz/path/to/repo.git/
+- ssh://{startsb}user@{endsb}host.xz/~user/path/to/repo.git/
+- ssh://{startsb}user@{endsb}host.xz/~/path/to/repo.git
+===============================================================
+
+SSH is the default transport protocol over the network. You can
+optionally specify which user to log-in as, and an alternate,
+scp-like syntax is also supported. Both syntaxes support
+username expansion, as does the native git protocol, but
+only the former supports port specification. The following
+three are identical to the last three above, respectively:
+
+===============================================================
+- {startsb}user@{endsb}host.xz:/path/to/repo.git/
+- {startsb}user@{endsb}host.xz:~user/path/to/repo.git/
+- {startsb}user@{endsb}host.xz:path/to/repo.git
+===============================================================
+
+To sync with a local directory, you can use:
+
+===============================================================
+- /path/to/repo.git/
+- file:///path/to/repo.git/
+===============================================================
+
+ifndef::git-clone[]
+They are mostly equivalent, except when cloning. See
+linkgit:git-clone[1] for details.
+endif::git-clone[]
+
+ifdef::git-clone[]
+They are equivalent, except the former implies --local option.
+endif::git-clone[]
+
+
+If there are a large number of similarly-named remote repositories and
+you want to use a different format for them (such that the URLs you
+use will be rewritten into URLs that work), you can create a
+configuration section of the form:
+
+------------
+ [url "<actual url base>"]
+ insteadOf = <other url base>
+------------
+
+For example, with this:
+
+------------
+ [url "git://git.host.xz/"]
+ insteadOf = host.xz:/path/to/
+ insteadOf = work:
+------------
+
+a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
+rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".
+
diff --git a/Documentation/user-manual.conf b/Documentation/user-manual.conf
new file mode 100644
index 0000000000..339b30919e
--- /dev/null
+++ b/Documentation/user-manual.conf
@@ -0,0 +1,21 @@
+[titles]
+ underlines="__","==","--","~~","^^"
+
+[attributes]
+caret=^
+startsb=&#91;
+endsb=&#93;
+tilde=&#126;
+
+[linkgit-inlinemacro]
+<ulink url="{target}.html">{target}{0?({0})}</ulink>
+
+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[]
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
new file mode 100644
index 0000000000..bfde507e0e
--- /dev/null
+++ b/Documentation/user-manual.txt
@@ -0,0 +1,4550 @@
+Git User's Manual (for version 1.5.3 or newer)
+______________________________________________
+
+
+Git is a fast distributed revision control system.
+
+This manual is designed to be readable by someone with basic UNIX
+command-line skills, but no previous knowledge of git.
+
+<<repositories-and-branches>> and <<exploring-git-history>> explain how
+to fetch and study a project using git--read these chapters to learn how
+to build and test a particular version of a software project, search for
+regressions, and so on.
+
+People needing to do actual development will also want to read
+<<Developing-with-git>> and <<sharing-development>>.
+
+Further chapters cover more specialized topics.
+
+Comprehensive reference documentation is available through the man
+pages. For a command such as "git clone", just use
+
+------------------------------------------------
+$ man git-clone
+------------------------------------------------
+
+See also <<git-quick-start>> for a brief overview of git commands,
+without any explanation.
+
+Finally, see <<todo>> for ways that you can help make this manual more
+complete.
+
+
+[[repositories-and-branches]]
+Repositories and Branches
+=========================
+
+[[how-to-get-a-git-repository]]
+How to get a git repository
+---------------------------
+
+It will be useful to have a git repository to experiment with as you
+read this manual.
+
+The best way to get one is by using the linkgit:git-clone[1] command to
+download a copy of an existing repository. If you don't already have a
+project in mind, here are some interesting examples:
+
+------------------------------------------------
+ # git itself (approx. 10MB download):
+$ git clone git://git.kernel.org/pub/scm/git/git.git
+ # the linux kernel (approx. 150MB download):
+$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+------------------------------------------------
+
+The initial clone may be time-consuming for a large project, but you
+will only need to clone once.
+
+The clone command creates a new directory named after the project ("git"
+or "linux-2.6" in the examples above). After you cd into this
+directory, you will see that it contains a copy of the project files,
+called the <<def_working_tree,working tree>>, together with a special
+top-level directory named ".git", which contains all the information
+about the history of the project.
+
+[[how-to-check-out]]
+How to check out a different version of a project
+-------------------------------------------------
+
+Git is best thought of as a tool for storing the history of a collection
+of files. It stores the history as a compressed collection of
+interrelated snapshots of the project's contents. In git each such
+version is called a <<def_commit,commit>>.
+
+Those snapshots aren't necessarily all arranged in a single line from
+oldest to newest; instead, work may simultaneously proceed along
+parallel lines of development, called <<def_branch,branches>>, which may
+merge and diverge.
+
+A single git repository can track development on multiple branches. It
+does this by keeping a list of <<def_head,heads>> which reference the
+latest commit on each branch; the linkgit:git-branch[1] command shows
+you the list of branch heads:
+
+------------------------------------------------
+$ git branch
+* master
+------------------------------------------------
+
+A freshly cloned repository contains a single branch head, by default
+named "master", with the working directory initialized to the state of
+the project referred to by that branch head.
+
+Most projects also use <<def_tag,tags>>. Tags, like heads, are
+references into the project's history, and can be listed using the
+linkgit:git-tag[1] command:
+
+------------------------------------------------
+$ git tag -l
+v2.6.11
+v2.6.11-tree
+v2.6.12
+v2.6.12-rc2
+v2.6.12-rc3
+v2.6.12-rc4
+v2.6.12-rc5
+v2.6.12-rc6
+v2.6.13
+...
+------------------------------------------------
+
+Tags are expected to always point at the same version of a project,
+while heads are expected to advance as development progresses.
+
+Create a new branch head pointing to one of these versions and check it
+out using linkgit:git-checkout[1]:
+
+------------------------------------------------
+$ git checkout -b new v2.6.13
+------------------------------------------------
+
+The working directory then reflects the contents that the project had
+when it was tagged v2.6.13, and linkgit:git-branch[1] shows two
+branches, with an asterisk marking the currently checked-out branch:
+
+------------------------------------------------
+$ git branch
+ master
+* new
+------------------------------------------------
+
+If you decide that you'd rather see version 2.6.17, you can modify
+the current branch to point at v2.6.17 instead, with
+
+------------------------------------------------
+$ git reset --hard v2.6.17
+------------------------------------------------
+
+Note that if the current branch head was your only reference to a
+particular point in history, then resetting that branch may leave you
+with no way to find the history it used to point to; so use this command
+carefully.
+
+[[understanding-commits]]
+Understanding History: Commits
+------------------------------
+
+Every change in the history of a project is represented by a commit.
+The linkgit:git-show[1] command shows the most recent commit on the
+current branch:
+
+------------------------------------------------
+$ git show
+commit 17cf781661e6d38f737f15f53ab552f1e95960d7
+Author: Linus Torvalds <torvalds@ppc970.osdl.org.(none)>
+Date: Tue Apr 19 14:11:06 2005 -0700
+
+ Remove duplicate getenv(DB_ENVIRONMENT) call
+
+ Noted by Tony Luck.
+
+diff --git a/init-db.c b/init-db.c
+index 65898fa..b002dc6 100644
+--- a/init-db.c
++++ b/init-db.c
+@@ -7,7 +7,7 @@
+
+ int main(int argc, char **argv)
+ {
+- char *sha1_dir = getenv(DB_ENVIRONMENT), *path;
++ char *sha1_dir, *path;
+ int len, i;
+
+ if (mkdir(".git", 0755) < 0) {
+------------------------------------------------
+
+As you can see, a commit shows who made the latest change, what they
+did, and why.
+
+Every commit has a 40-hexdigit id, sometimes called the "object name" or the
+"SHA1 id", shown on the first line of the "git show" output. You can usually
+refer to a commit by a shorter name, such as a tag or a branch name, but this
+longer name can also be useful. Most importantly, it is a globally unique
+name for this commit: so if you tell somebody else the object name (for
+example in email), then you are guaranteed that name will refer to the same
+commit in their repository that it does in yours (assuming their repository
+has that commit at all). Since the object name is computed as a hash over the
+contents of the commit, you are guaranteed that the commit can never change
+without its name also changing.
+
+In fact, in <<git-concepts>> we shall see that everything stored in git
+history, including file data and directory contents, is stored in an object
+with a name that is a hash of its contents.
+
+[[understanding-reachability]]
+Understanding history: commits, parents, and reachability
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Every commit (except the very first commit in a project) also has a
+parent commit which shows what happened before this commit.
+Following the chain of parents will eventually take you back to the
+beginning of the project.
+
+However, the commits do not form a simple list; git allows lines of
+development to diverge and then reconverge, and the point where two
+lines of development reconverge is called a "merge". The commit
+representing a merge can therefore have more than one parent, with
+each parent representing the most recent commit on one of the lines
+of development leading to that point.
+
+The best way to see how this works is using the linkgit:gitk[1]
+command; running gitk now on a git repository and looking for merge
+commits will help understand how the git organizes history.
+
+In the following, we say that commit X is "reachable" from commit Y
+if commit X is an ancestor of commit Y. Equivalently, you could say
+that Y is a descendant of X, or that there is a chain of parents
+leading from commit Y to commit X.
+
+[[history-diagrams]]
+Understanding history: History diagrams
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We will sometimes represent git history using diagrams like the one
+below. Commits are shown as "o", and the links between them with
+lines drawn with - / and \. Time goes left to right:
+
+
+................................................
+ o--o--o <-- Branch A
+ /
+ o--o--o <-- master
+ \
+ o--o--o <-- Branch B
+................................................
+
+If we need to talk about a particular commit, the character "o" may
+be replaced with another letter or number.
+
+[[what-is-a-branch]]
+Understanding history: What is a branch?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When we need to be precise, we will use the word "branch" to mean a line
+of development, and "branch head" (or just "head") to mean a reference
+to the most recent commit on a branch. In the example above, the branch
+head named "A" is a pointer to one particular commit, but we refer to
+the line of three commits leading up to that point as all being part of
+"branch A".
+
+However, when no confusion will result, we often just use the term
+"branch" both for branches and for branch heads.
+
+[[manipulating-branches]]
+Manipulating branches
+---------------------
+
+Creating, deleting, and modifying branches is quick and easy; here's
+a summary of the commands:
+
+git branch::
+ list all branches
+git branch <branch>::
+ create a new branch named <branch>, referencing the same
+ point in history as the current branch
+git branch <branch> <start-point>::
+ create a new branch named <branch>, referencing
+ <start-point>, which may be specified any way you like,
+ including using a branch name or a tag name
+git branch -d <branch>::
+ delete the branch <branch>; if the branch you are deleting
+ points to a commit which is not reachable from the current
+ branch, this command will fail with a warning.
+git branch -D <branch>::
+ even if the branch points to a commit not reachable
+ from the current branch, you may know that that commit
+ is still reachable from some other branch or tag. In that
+ case it is safe to use this command to force git to delete
+ the branch.
+git checkout <branch>::
+ make the current branch <branch>, updating the working
+ directory to reflect the version referenced by <branch>
+git checkout -b <new> <start-point>::
+ create a new branch <new> referencing <start-point>, and
+ check it out.
+
+The special symbol "HEAD" can always be used to refer to the current
+branch. In fact, git uses a file named "HEAD" in the .git directory to
+remember which branch is current:
+
+------------------------------------------------
+$ cat .git/HEAD
+ref: refs/heads/master
+------------------------------------------------
+
+[[detached-head]]
+Examining an old version without creating a new branch
+------------------------------------------------------
+
+The git-checkout command normally expects a branch head, but will also
+accept an arbitrary commit; for example, you can check out the commit
+referenced by a tag:
+
+------------------------------------------------
+$ git checkout v2.6.17
+Note: moving to "v2.6.17" which isn't a local branch
+If you want to create a new branch from this checkout, you may do so
+(now or later) by using -b with the checkout command again. Example:
+ git checkout -b <new_branch_name>
+HEAD is now at 427abfa... Linux v2.6.17
+------------------------------------------------
+
+The HEAD then refers to the SHA1 of the commit instead of to a branch,
+and git branch shows that you are no longer on a branch:
+
+------------------------------------------------
+$ cat .git/HEAD
+427abfa28afedffadfca9dd8b067eb6d36bac53f
+$ git branch
+* (no branch)
+ master
+------------------------------------------------
+
+In this case we say that the HEAD is "detached".
+
+This is an easy way to check out a particular version without having to
+make up a name for the new branch. You can still create a new branch
+(or tag) for this version later if you decide to.
+
+[[examining-remote-branches]]
+Examining branches from a remote repository
+-------------------------------------------
+
+The "master" branch that was created at the time you cloned is a copy
+of the HEAD in the repository that you cloned from. That repository
+may also have had other branches, though, and your local repository
+keeps branches which track each of those remote branches, which you
+can view using the "-r" option to linkgit:git-branch[1]:
+
+------------------------------------------------
+$ git branch -r
+ origin/HEAD
+ origin/html
+ origin/maint
+ origin/man
+ origin/master
+ origin/next
+ origin/pu
+ origin/todo
+------------------------------------------------
+
+You cannot check out these remote-tracking branches, but you can
+examine them on a branch of your own, just as you would a tag:
+
+------------------------------------------------
+$ git checkout -b my-todo-copy origin/todo
+------------------------------------------------
+
+Note that the name "origin" is just the name that git uses by default
+to refer to the repository that you cloned from.
+
+[[how-git-stores-references]]
+Naming branches, tags, and other references
+-------------------------------------------
+
+Branches, remote-tracking branches, and tags are all references to
+commits. All references are named with a slash-separated path name
+starting with "refs"; the names we've been using so far are actually
+shorthand:
+
+ - The branch "test" is short for "refs/heads/test".
+ - The tag "v2.6.18" is short for "refs/tags/v2.6.18".
+ - "origin/master" is short for "refs/remotes/origin/master".
+
+The full name is occasionally useful if, for example, there ever
+exists a tag and a branch with the same name.
+
+(Newly created refs are actually stored in the .git/refs directory,
+under the path given by their name. However, for efficiency reasons
+they may also be packed together in a single file; see
+linkgit:git-pack-refs[1]).
+
+As another useful shortcut, the "HEAD" of a repository can be referred
+to just using the name of that repository. So, for example, "origin"
+is usually a shortcut for the HEAD branch in the repository "origin".
+
+For the complete list of paths which git checks for references, and
+the order it uses to decide which to choose when there are multiple
+references with the same shorthand name, see the "SPECIFYING
+REVISIONS" section of linkgit:git-rev-parse[1].
+
+[[Updating-a-repository-with-git-fetch]]
+Updating a repository with git fetch
+------------------------------------
+
+Eventually the developer cloned from will do additional work in her
+repository, creating new commits and advancing the branches to point
+at the new commits.
+
+The command "git fetch", with no arguments, will update all of the
+remote-tracking branches to the latest version found in her
+repository. It will not touch any of your own branches--not even the
+"master" branch that was created for you on clone.
+
+[[fetching-branches]]
+Fetching branches from other repositories
+-----------------------------------------
+
+You can also track branches from repositories other than the one you
+cloned from, using linkgit:git-remote[1]:
+
+-------------------------------------------------
+$ git remote add linux-nfs git://linux-nfs.org/pub/nfs-2.6.git
+$ git fetch linux-nfs
+* refs/remotes/linux-nfs/master: storing branch 'master' ...
+ commit: bf81b46
+-------------------------------------------------
+
+New remote-tracking branches will be stored under the shorthand name
+that you gave "git remote add", in this case linux-nfs:
+
+-------------------------------------------------
+$ git branch -r
+linux-nfs/master
+origin/master
+-------------------------------------------------
+
+If you run "git fetch <remote>" later, the tracking branches for the
+named <remote> will be updated.
+
+If you examine the file .git/config, you will see that git has added
+a new stanza:
+
+-------------------------------------------------
+$ cat .git/config
+...
+[remote "linux-nfs"]
+ url = git://linux-nfs.org/pub/nfs-2.6.git
+ fetch = +refs/heads/*:refs/remotes/linux-nfs/*
+...
+-------------------------------------------------
+
+This is what causes git to track the remote's branches; you may modify
+or delete these configuration options by editing .git/config with a
+text editor. (See the "CONFIGURATION FILE" section of
+linkgit:git-config[1] for details.)
+
+[[exploring-git-history]]
+Exploring git history
+=====================
+
+Git is best thought of as a tool for storing the history of a
+collection of files. It does this by storing compressed snapshots of
+the contents of a file hierarchy, together with "commits" which show
+the relationships between these snapshots.
+
+Git provides extremely flexible and fast tools for exploring the
+history of a project.
+
+We start with one specialized tool that is useful for finding the
+commit that introduced a bug into a project.
+
+[[using-bisect]]
+How to use bisect to find a regression
+--------------------------------------
+
+Suppose version 2.6.18 of your project worked, but the version at
+"master" crashes. Sometimes the best way to find the cause of such a
+regression is to perform a brute-force search through the project's
+history to find the particular commit that caused the problem. The
+linkgit:git-bisect[1] command can help you do this:
+
+-------------------------------------------------
+$ git bisect start
+$ git bisect good v2.6.18
+$ git bisect bad master
+Bisecting: 3537 revisions left to test after this
+[65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6]
+-------------------------------------------------
+
+If you run "git branch" at this point, you'll see that git has
+temporarily moved you to a new branch named "bisect". This branch
+points to a commit (with commit id 65934...) that is reachable from
+"master" but not from v2.6.18. Compile and test it, and see whether
+it crashes. Assume it does crash. Then:
+
+-------------------------------------------------
+$ git bisect bad
+Bisecting: 1769 revisions left to test after this
+[7eff82c8b1511017ae605f0c99ac275a7e21b867] i2c-core: Drop useless bitmaskings
+-------------------------------------------------
+
+checks out an older version. Continue like this, telling git at each
+stage whether the version it gives you is good or bad, and notice
+that the number of revisions left to test is cut approximately in
+half each time.
+
+After about 13 tests (in this case), it will output the commit id of
+the guilty commit. You can then examine the commit with
+linkgit:git-show[1], find out who wrote it, and mail them your bug
+report with the commit id. Finally, run
+
+-------------------------------------------------
+$ git bisect reset
+-------------------------------------------------
+
+to return you to the branch you were on before and delete the
+temporary "bisect" branch.
+
+Note that the version which git-bisect checks out for you at each
+point is just a suggestion, and you're free to try a different
+version if you think it would be a good idea. For example,
+occasionally you may land on a commit that broke something unrelated;
+run
+
+-------------------------------------------------
+$ git bisect visualize
+-------------------------------------------------
+
+which will run gitk and label the commit it chose with a marker that
+says "bisect". Chose a safe-looking commit nearby, note its commit
+id, and check it out with:
+
+-------------------------------------------------
+$ git reset --hard fb47ddb2db...
+-------------------------------------------------
+
+then test, run "bisect good" or "bisect bad" as appropriate, and
+continue.
+
+[[naming-commits]]
+Naming commits
+--------------
+
+We have seen several ways of naming commits already:
+
+ - 40-hexdigit object name
+ - branch name: refers to the commit at the head of the given
+ branch
+ - tag name: refers to the commit pointed to by the given tag
+ (we've seen branches and tags are special cases of
+ <<how-git-stores-references,references>>).
+ - HEAD: refers to the head of the current branch
+
+There are many more; see the "SPECIFYING REVISIONS" section of the
+linkgit:git-rev-parse[1] man page for the complete list of ways to
+name revisions. Some examples:
+
+-------------------------------------------------
+$ git show fb47ddb2 # the first few characters of the object name
+ # are usually enough to specify it uniquely
+$ git show HEAD^ # the parent of the HEAD commit
+$ git show HEAD^^ # the grandparent
+$ git show HEAD~4 # the great-great-grandparent
+-------------------------------------------------
+
+Recall that merge commits may have more than one parent; by default,
+^ and ~ follow the first parent listed in the commit, but you can
+also choose:
+
+-------------------------------------------------
+$ git show HEAD^1 # show the first parent of HEAD
+$ git show HEAD^2 # show the second parent of HEAD
+-------------------------------------------------
+
+In addition to HEAD, there are several other special names for
+commits:
+
+Merges (to be discussed later), as well as operations such as
+git-reset, which change the currently checked-out commit, generally
+set ORIG_HEAD to the value HEAD had before the current operation.
+
+The git-fetch operation always stores the head of the last fetched
+branch in FETCH_HEAD. For example, if you run git fetch without
+specifying a local branch as the target of the operation
+
+-------------------------------------------------
+$ git fetch git://example.com/proj.git theirbranch
+-------------------------------------------------
+
+the fetched commits will still be available from FETCH_HEAD.
+
+When we discuss merges we'll also see the special name MERGE_HEAD,
+which refers to the other branch that we're merging in to the current
+branch.
+
+The linkgit:git-rev-parse[1] command is a low-level command that is
+occasionally useful for translating some name for a commit to the object
+name for that commit:
+
+-------------------------------------------------
+$ git rev-parse origin
+e05db0fd4f31dde7005f075a84f96b360d05984b
+-------------------------------------------------
+
+[[creating-tags]]
+Creating tags
+-------------
+
+We can also create a tag to refer to a particular commit; after
+running
+
+-------------------------------------------------
+$ git tag stable-1 1b2e1d63ff
+-------------------------------------------------
+
+You can use stable-1 to refer to the commit 1b2e1d63ff.
+
+This creates a "lightweight" tag. If you would also like to include a
+comment with the tag, and possibly sign it cryptographically, then you
+should create a tag object instead; see the linkgit:git-tag[1] man page
+for details.
+
+[[browsing-revisions]]
+Browsing revisions
+------------------
+
+The linkgit:git-log[1] command can show lists of commits. On its
+own, it shows all commits reachable from the parent commit; but you
+can also make more specific requests:
+
+-------------------------------------------------
+$ git log v2.5.. # commits since (not reachable from) v2.5
+$ git log test..master # commits reachable from master but not test
+$ git log master..test # ...reachable from test but not master
+$ git log master...test # ...reachable from either test or master,
+ # but not both
+$ git log --since="2 weeks ago" # commits from the last 2 weeks
+$ git log Makefile # commits which modify Makefile
+$ git log fs/ # ... which modify any file under fs/
+$ git log -S'foo()' # commits which add or remove any file data
+ # matching the string 'foo()'
+-------------------------------------------------
+
+And of course you can combine all of these; the following finds
+commits since v2.5 which touch the Makefile or any file under fs:
+
+-------------------------------------------------
+$ git log v2.5.. Makefile fs/
+-------------------------------------------------
+
+You can also ask git log to show patches:
+
+-------------------------------------------------
+$ git log -p
+-------------------------------------------------
+
+See the "--pretty" option in the linkgit:git-log[1] man page for more
+display options.
+
+Note that git log starts with the most recent commit and works
+backwards through the parents; however, since git history can contain
+multiple independent lines of development, the particular order that
+commits are listed in may be somewhat arbitrary.
+
+[[generating-diffs]]
+Generating diffs
+----------------
+
+You can generate diffs between any two versions using
+linkgit:git-diff[1]:
+
+-------------------------------------------------
+$ git diff master..test
+-------------------------------------------------
+
+That will produce the diff between the tips of the two branches. If
+you'd prefer to find the diff from their common ancestor to test, you
+can use three dots instead of two:
+
+-------------------------------------------------
+$ git diff master...test
+-------------------------------------------------
+
+Sometimes what you want instead is a set of patches; for this you can
+use linkgit:git-format-patch[1]:
+
+-------------------------------------------------
+$ git format-patch master..test
+-------------------------------------------------
+
+will generate a file with a patch for each commit reachable from test
+but not from master.
+
+[[viewing-old-file-versions]]
+Viewing old file versions
+-------------------------
+
+You can always view an old version of a file by just checking out the
+correct revision first. But sometimes it is more convenient to be
+able to view an old version of a single file without checking
+anything out; this command does that:
+
+-------------------------------------------------
+$ git show v2.5:fs/locks.c
+-------------------------------------------------
+
+Before the colon may be anything that names a commit, and after it
+may be any path to a file tracked by git.
+
+[[history-examples]]
+Examples
+--------
+
+[[counting-commits-on-a-branch]]
+Counting the number of commits on a branch
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Suppose you want to know how many commits you've made on "mybranch"
+since it diverged from "origin":
+
+-------------------------------------------------
+$ git log --pretty=oneline origin..mybranch | wc -l
+-------------------------------------------------
+
+Alternatively, you may often see this sort of thing done with the
+lower-level command linkgit:git-rev-list[1], which just lists the SHA1's
+of all the given commits:
+
+-------------------------------------------------
+$ git rev-list origin..mybranch | wc -l
+-------------------------------------------------
+
+[[checking-for-equal-branches]]
+Check whether two branches point at the same history
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Suppose you want to check whether two branches point at the same point
+in history.
+
+-------------------------------------------------
+$ git diff origin..master
+-------------------------------------------------
+
+will tell you whether the contents of the project are the same at the
+two branches; in theory, however, it's possible that the same project
+contents could have been arrived at by two different historical
+routes. You could compare the object names:
+
+-------------------------------------------------
+$ git rev-list origin
+e05db0fd4f31dde7005f075a84f96b360d05984b
+$ git rev-list master
+e05db0fd4f31dde7005f075a84f96b360d05984b
+-------------------------------------------------
+
+Or you could recall that the ... operator selects all commits
+contained reachable from either one reference or the other but not
+both: so
+
+-------------------------------------------------
+$ git log origin...master
+-------------------------------------------------
+
+will return no commits when the two branches are equal.
+
+[[finding-tagged-descendants]]
+Find first tagged version including a given fix
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Suppose you know that the commit e05db0fd fixed a certain problem.
+You'd like to find the earliest tagged release that contains that
+fix.
+
+Of course, there may be more than one answer--if the history branched
+after commit e05db0fd, then there could be multiple "earliest" tagged
+releases.
+
+You could just visually inspect the commits since e05db0fd:
+
+-------------------------------------------------
+$ gitk e05db0fd..
+-------------------------------------------------
+
+Or you can use linkgit:git-name-rev[1], which will give the commit a
+name based on any tag it finds pointing to one of the commit's
+descendants:
+
+-------------------------------------------------
+$ git name-rev --tags e05db0fd
+e05db0fd tags/v1.5.0-rc1^0~23
+-------------------------------------------------
+
+The linkgit:git-describe[1] command does the opposite, naming the
+revision using a tag on which the given commit is based:
+
+-------------------------------------------------
+$ git describe e05db0fd
+v1.5.0-rc0-260-ge05db0f
+-------------------------------------------------
+
+but that may sometimes help you guess which tags might come after the
+given commit.
+
+If you just want to verify whether a given tagged version contains a
+given commit, you could use linkgit:git-merge-base[1]:
+
+-------------------------------------------------
+$ git merge-base e05db0fd v1.5.0-rc1
+e05db0fd4f31dde7005f075a84f96b360d05984b
+-------------------------------------------------
+
+The merge-base command finds a common ancestor of the given commits,
+and always returns one or the other in the case where one is a
+descendant of the other; so the above output shows that e05db0fd
+actually is an ancestor of v1.5.0-rc1.
+
+Alternatively, note that
+
+-------------------------------------------------
+$ git log v1.5.0-rc1..e05db0fd
+-------------------------------------------------
+
+will produce empty output if and only if v1.5.0-rc1 includes e05db0fd,
+because it outputs only commits that are not reachable from v1.5.0-rc1.
+
+As yet another alternative, the linkgit:git-show-branch[1] command lists
+the commits reachable from its arguments with a display on the left-hand
+side that indicates which arguments that commit is reachable from. So,
+you can run something like
+
+-------------------------------------------------
+$ git show-branch e05db0fd v1.5.0-rc0 v1.5.0-rc1 v1.5.0-rc2
+! [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if
+available
+ ! [v1.5.0-rc0] GIT v1.5.0 preview
+ ! [v1.5.0-rc1] GIT v1.5.0-rc1
+ ! [v1.5.0-rc2] GIT v1.5.0-rc2
+...
+-------------------------------------------------
+
+then search for a line that looks like
+
+-------------------------------------------------
++ ++ [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if
+available
+-------------------------------------------------
+
+Which shows that e05db0fd is reachable from itself, from v1.5.0-rc1, and
+from v1.5.0-rc2, but not from v1.5.0-rc0.
+
+[[showing-commits-unique-to-a-branch]]
+Showing commits unique to a given branch
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Suppose you would like to see all the commits reachable from the branch
+head named "master" but not from any other head in your repository.
+
+We can list all the heads in this repository with
+linkgit:git-show-ref[1]:
+
+-------------------------------------------------
+$ git show-ref --heads
+bf62196b5e363d73353a9dcf094c59595f3153b7 refs/heads/core-tutorial
+db768d5504c1bb46f63ee9d6e1772bd047e05bf9 refs/heads/maint
+a07157ac624b2524a059a3414e99f6f44bebc1e7 refs/heads/master
+24dbc180ea14dc1aebe09f14c8ecf32010690627 refs/heads/tutorial-2
+1e87486ae06626c2f31eaa63d26fc0fd646c8af2 refs/heads/tutorial-fixes
+-------------------------------------------------
+
+We can get just the branch-head names, and remove "master", with
+the help of the standard utilities cut and grep:
+
+-------------------------------------------------
+$ git show-ref --heads | cut -d' ' -f2 | grep -v '^refs/heads/master'
+refs/heads/core-tutorial
+refs/heads/maint
+refs/heads/tutorial-2
+refs/heads/tutorial-fixes
+-------------------------------------------------
+
+And then we can ask to see all the commits reachable from master
+but not from these other heads:
+
+-------------------------------------------------
+$ gitk master --not $( git show-ref --heads | cut -d' ' -f2 |
+ grep -v '^refs/heads/master' )
+-------------------------------------------------
+
+Obviously, endless variations are possible; for example, to see all
+commits reachable from some head but not from any tag in the repository:
+
+-------------------------------------------------
+$ gitk $( git show-ref --heads ) --not $( git show-ref --tags )
+-------------------------------------------------
+
+(See linkgit:git-rev-parse[1] for explanations of commit-selecting
+syntax such as `--not`.)
+
+[[making-a-release]]
+Creating a changelog and tarball for a software release
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The linkgit:git-archive[1] command can create a tar or zip archive from
+any version of a project; for example:
+
+-------------------------------------------------
+$ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz
+-------------------------------------------------
+
+will use HEAD to produce a tar archive in which each filename is
+preceded by "project/".
+
+If you're releasing a new version of a software project, you may want
+to simultaneously make a changelog to include in the release
+announcement.
+
+Linus Torvalds, for example, makes new kernel releases by tagging them,
+then running:
+
+-------------------------------------------------
+$ release-script 2.6.12 2.6.13-rc6 2.6.13-rc7
+-------------------------------------------------
+
+where release-script is a shell script that looks like:
+
+-------------------------------------------------
+#!/bin/sh
+stable="$1"
+last="$2"
+new="$3"
+echo "# git tag v$new"
+echo "git archive --prefix=linux-$new/ v$new | gzip -9 > ../linux-$new.tar.gz"
+echo "git diff v$stable v$new | gzip -9 > ../patch-$new.gz"
+echo "git log --no-merges v$new ^v$last > ../ChangeLog-$new"
+echo "git shortlog --no-merges v$new ^v$last > ../ShortLog"
+echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new"
+-------------------------------------------------
+
+and then he just cut-and-pastes the output commands after verifying that
+they look OK.
+
+[[Finding-comments-with-given-content]]
+Finding commits referencing a file with given content
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Somebody hands you a copy of a file, and asks which commits modified a
+file such that it contained the given content either before or after the
+commit. You can find out with this:
+
+-------------------------------------------------
+$ git log --raw --abbrev=40 --pretty=oneline |
+ grep -B 1 `git hash-object filename`
+-------------------------------------------------
+
+Figuring out why this works is left as an exercise to the (advanced)
+student. The linkgit:git-log[1], linkgit:git-diff-tree[1], and
+linkgit:git-hash-object[1] man pages may prove helpful.
+
+[[Developing-with-git]]
+Developing with git
+===================
+
+[[telling-git-your-name]]
+Telling git your name
+---------------------
+
+Before creating any commits, you should introduce yourself to git. The
+easiest way to do so is to make sure the following lines appear in a
+file named .gitconfig in your home directory:
+
+------------------------------------------------
+[user]
+ name = Your Name Comes Here
+ email = you@yourdomain.example.com
+------------------------------------------------
+
+(See the "CONFIGURATION FILE" section of linkgit:git-config[1] for
+details on the configuration file.)
+
+
+[[creating-a-new-repository]]
+Creating a new repository
+-------------------------
+
+Creating a new repository from scratch is very easy:
+
+-------------------------------------------------
+$ mkdir project
+$ cd project
+$ git init
+-------------------------------------------------
+
+If you have some initial content (say, a tarball):
+
+-------------------------------------------------
+$ tar -xzvf project.tar.gz
+$ cd project
+$ git init
+$ git add . # include everything below ./ in the first commit:
+$ git commit
+-------------------------------------------------
+
+[[how-to-make-a-commit]]
+How to make a commit
+--------------------
+
+Creating a new commit takes three steps:
+
+ 1. Making some changes to the working directory using your
+ favorite editor.
+ 2. Telling git about your changes.
+ 3. Creating the commit using the content you told git about
+ in step 2.
+
+In practice, you can interleave and repeat steps 1 and 2 as many
+times as you want: in order to keep track of what you want committed
+at step 3, git maintains a snapshot of the tree's contents in a
+special staging area called "the index."
+
+At the beginning, the content of the index will be identical to
+that of the HEAD. The command "git diff --cached", which shows
+the difference between the HEAD and the index, should therefore
+produce no output at that point.
+
+Modifying the index is easy:
+
+To update the index with the new contents of a modified file, use
+
+-------------------------------------------------
+$ git add path/to/file
+-------------------------------------------------
+
+To add the contents of a new file to the index, use
+
+-------------------------------------------------
+$ git add path/to/file
+-------------------------------------------------
+
+To remove a file from the index and from the working tree,
+
+-------------------------------------------------
+$ git rm path/to/file
+-------------------------------------------------
+
+After each step you can verify that
+
+-------------------------------------------------
+$ git diff --cached
+-------------------------------------------------
+
+always shows the difference between the HEAD and the index file--this
+is what you'd commit if you created the commit now--and that
+
+-------------------------------------------------
+$ git diff
+-------------------------------------------------
+
+shows the difference between the working tree and the index file.
+
+Note that "git add" always adds just the current contents of a file
+to the index; further changes to the same file will be ignored unless
+you run git-add on the file again.
+
+When you're ready, just run
+
+-------------------------------------------------
+$ git commit
+-------------------------------------------------
+
+and git will prompt you for a commit message and then create the new
+commit. Check to make sure it looks like what you expected with
+
+-------------------------------------------------
+$ git show
+-------------------------------------------------
+
+As a special shortcut,
+
+-------------------------------------------------
+$ git commit -a
+-------------------------------------------------
+
+will update the index with any files that you've modified or removed
+and create a commit, all in one step.
+
+A number of commands are useful for keeping track of what you're
+about to commit:
+
+-------------------------------------------------
+$ git diff --cached # difference between HEAD and the index; what
+ # would be committed if you ran "commit" now.
+$ git diff # difference between the index file and your
+ # working directory; changes that would not
+ # be included if you ran "commit" now.
+$ git diff HEAD # difference between HEAD and working tree; what
+ # would be committed if you ran "commit -a" now.
+$ git status # a brief per-file summary of the above.
+-------------------------------------------------
+
+You can also use linkgit:git-gui[1] to create commits, view changes in
+the index and the working tree files, and individually select diff hunks
+for inclusion in the index (by right-clicking on the diff hunk and
+choosing "Stage Hunk For Commit").
+
+[[creating-good-commit-messages]]
+Creating good commit messages
+-----------------------------
+
+Though not required, it's a good idea to begin the commit message
+with a single short (less than 50 character) line summarizing the
+change, followed by a blank line and then a more thorough
+description. Tools that turn commits into email, for example, use
+the first line on the Subject line and the rest of the commit in the
+body.
+
+[[ignoring-files]]
+Ignoring files
+--------------
+
+A project will often generate files that you do 'not' want to track with git.
+This typically includes files generated by a build process or temporary
+backup files made by your editor. Of course, 'not' tracking files with git
+is just a matter of 'not' calling "`git add`" on them. But it quickly becomes
+annoying to have these untracked files lying around; e.g. they make
+"`git add .`" and "`git commit -a`" practically useless, and they keep
+showing up in the output of "`git status`".
+
+You can tell git to ignore certain files by creating a file called .gitignore
+in the top level of your working directory, with contents such as:
+
+-------------------------------------------------
+# Lines starting with '#' are considered comments.
+# Ignore any file named foo.txt.
+foo.txt
+# Ignore (generated) html files,
+*.html
+# except foo.html which is maintained by hand.
+!foo.html
+# Ignore objects and archives.
+*.[oa]
+-------------------------------------------------
+
+See linkgit:gitignore[5] for a detailed explanation of the syntax. You can
+also place .gitignore files in other directories in your working tree, and they
+will apply to those directories and their subdirectories. The `.gitignore`
+files can be added to your repository like any other files (just run `git add
+.gitignore` and `git commit`, as usual), which is convenient when the exclude
+patterns (such as patterns matching build output files) would also make sense
+for other users who clone your repository.
+
+If you wish the exclude patterns to affect only certain repositories
+(instead of every repository for a given project), you may instead put
+them in a file in your repository named .git/info/exclude, or in any file
+specified by the `core.excludesfile` configuration variable. Some git
+commands can also take exclude patterns directly on the command line.
+See linkgit:gitignore[5] for the details.
+
+[[how-to-merge]]
+How to merge
+------------
+
+You can rejoin two diverging branches of development using
+linkgit:git-merge[1]:
+
+-------------------------------------------------
+$ git merge branchname
+-------------------------------------------------
+
+merges the development in the branch "branchname" into the current
+branch. If there are conflicts--for example, if the same file is
+modified in two different ways in the remote branch and the local
+branch--then you are warned; the output may look something like this:
+
+-------------------------------------------------
+$ git merge next
+ 100% (4/4) done
+Auto-merged file.txt
+CONFLICT (content): Merge conflict in file.txt
+Automatic merge failed; fix conflicts and then commit the result.
+-------------------------------------------------
+
+Conflict markers are left in the problematic files, and after
+you resolve the conflicts manually, you can update the index
+with the contents and run git commit, as you normally would when
+creating a new file.
+
+If you examine the resulting commit using gitk, you will see that it
+has two parents, one pointing to the top of the current branch, and
+one to the top of the other branch.
+
+[[resolving-a-merge]]
+Resolving a merge
+-----------------
+
+When a merge isn't resolved automatically, git leaves the index and
+the working tree in a special state that gives you all the
+information you need to help resolve the merge.
+
+Files with conflicts are marked specially in the index, so until you
+resolve the problem and update the index, linkgit:git-commit[1] will
+fail:
+
+-------------------------------------------------
+$ git commit
+file.txt: needs merge
+-------------------------------------------------
+
+Also, linkgit:git-status[1] will list those files as "unmerged", and the
+files with conflicts will have conflict markers added, like this:
+
+-------------------------------------------------
+<<<<<<< HEAD:file.txt
+Hello world
+=======
+Goodbye
+>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt
+-------------------------------------------------
+
+All you need to do is edit the files to resolve the conflicts, and then
+
+-------------------------------------------------
+$ git add file.txt
+$ git commit
+-------------------------------------------------
+
+Note that the commit message will already be filled in for you with
+some information about the merge. Normally you can just use this
+default message unchanged, but you may add additional commentary of
+your own if desired.
+
+The above is all you need to know to resolve a simple merge. But git
+also provides more information to help resolve conflicts:
+
+[[conflict-resolution]]
+Getting conflict-resolution help during a merge
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+All of the changes that git was able to merge automatically are
+already added to the index file, so linkgit:git-diff[1] shows only
+the conflicts. It uses an unusual syntax:
+
+-------------------------------------------------
+$ git diff
+diff --cc file.txt
+index 802992c,2b60207..0000000
+--- a/file.txt
++++ b/file.txt
+@@@ -1,1 -1,1 +1,5 @@@
+++<<<<<<< HEAD:file.txt
+ +Hello world
+++=======
++ Goodbye
+++>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt
+-------------------------------------------------
+
+Recall that the commit which will be committed after we resolve this
+conflict will have two parents instead of the usual one: one parent
+will be HEAD, the tip of the current branch; the other will be the
+tip of the other branch, which is stored temporarily in MERGE_HEAD.
+
+During the merge, the index holds three versions of each file. Each of
+these three "file stages" represents a different version of the file:
+
+-------------------------------------------------
+$ git show :1:file.txt # the file in a common ancestor of both branches
+$ git show :2:file.txt # the version from HEAD, but including any
+ # nonconflicting changes from MERGE_HEAD
+$ git show :3:file.txt # the version from MERGE_HEAD, but including any
+ # nonconflicting changes from HEAD.
+-------------------------------------------------
+
+Since the stage 2 and stage 3 versions have already been updated with
+nonconflicting changes, the only remaining differences between them are
+the important ones; thus linkgit:git-diff[1] can use the information in
+the index to show only those conflicts.
+
+The diff above shows the differences between the working-tree version of
+file.txt and the stage 2 and stage 3 versions. So instead of preceding
+each line by a single "+" or "-", it now uses two columns: the first
+column is used for differences between the first parent and the working
+directory copy, and the second for differences between the second parent
+and the working directory copy. (See the "COMBINED DIFF FORMAT" section
+of linkgit:git-diff-files[1] for a details of the format.)
+
+After resolving the conflict in the obvious way (but before updating the
+index), the diff will look like:
+
+-------------------------------------------------
+$ git diff
+diff --cc file.txt
+index 802992c,2b60207..0000000
+--- a/file.txt
++++ b/file.txt
+@@@ -1,1 -1,1 +1,1 @@@
+- Hello world
+ -Goodbye
+++Goodbye world
+-------------------------------------------------
+
+This shows that our resolved version deleted "Hello world" from the
+first parent, deleted "Goodbye" from the second parent, and added
+"Goodbye world", which was previously absent from both.
+
+Some special diff options allow diffing the working directory against
+any of these stages:
+
+-------------------------------------------------
+$ git diff -1 file.txt # diff against stage 1
+$ git diff --base file.txt # same as the above
+$ git diff -2 file.txt # diff against stage 2
+$ git diff --ours file.txt # same as the above
+$ git diff -3 file.txt # diff against stage 3
+$ git diff --theirs file.txt # same as the above.
+-------------------------------------------------
+
+The linkgit:git-log[1] and gitk[1] commands also provide special help
+for merges:
+
+-------------------------------------------------
+$ git log --merge
+$ gitk --merge
+-------------------------------------------------
+
+These will display all commits which exist only on HEAD or on
+MERGE_HEAD, and which touch an unmerged file.
+
+You may also use linkgit:git-mergetool[1], which lets you merge the
+unmerged files using external tools such as emacs or kdiff3.
+
+Each time you resolve the conflicts in a file and update the index:
+
+-------------------------------------------------
+$ git add file.txt
+-------------------------------------------------
+
+the different stages of that file will be "collapsed", after which
+git-diff will (by default) no longer show diffs for that file.
+
+[[undoing-a-merge]]
+Undoing a merge
+---------------
+
+If you get stuck and decide to just give up and throw the whole mess
+away, you can always return to the pre-merge state with
+
+-------------------------------------------------
+$ git reset --hard HEAD
+-------------------------------------------------
+
+Or, if you've already committed the merge that you want to throw away,
+
+-------------------------------------------------
+$ git reset --hard ORIG_HEAD
+-------------------------------------------------
+
+However, this last command can be dangerous in some cases--never
+throw away a commit you have already committed if that commit may
+itself have been merged into another branch, as doing so may confuse
+further merges.
+
+[[fast-forwards]]
+Fast-forward merges
+-------------------
+
+There is one special case not mentioned above, which is treated
+differently. Normally, a merge results in a merge commit, with two
+parents, one pointing at each of the two lines of development that
+were merged.
+
+However, if the current branch is a descendant of the other--so every
+commit present in the one is already contained in the other--then git
+just performs a "fast forward"; the head of the current branch is moved
+forward to point at the head of the merged-in branch, without any new
+commits being created.
+
+[[fixing-mistakes]]
+Fixing mistakes
+---------------
+
+If you've messed up the working tree, but haven't yet committed your
+mistake, you can return the entire working tree to the last committed
+state with
+
+-------------------------------------------------
+$ git reset --hard HEAD
+-------------------------------------------------
+
+If you make a commit that you later wish you hadn't, there are two
+fundamentally different ways to fix the problem:
+
+ 1. You can create a new commit that undoes whatever was done
+ by the old commit. This is the correct thing if your
+ mistake has already been made public.
+
+ 2. You can go back and modify the old commit. You should
+ never do this if you have already made the history public;
+ git does not normally expect the "history" of a project to
+ change, and cannot correctly perform repeated merges from
+ a branch that has had its history changed.
+
+[[reverting-a-commit]]
+Fixing a mistake with a new commit
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Creating a new commit that reverts an earlier change is very easy;
+just pass the linkgit:git-revert[1] command a reference to the bad
+commit; for example, to revert the most recent commit:
+
+-------------------------------------------------
+$ git revert HEAD
+-------------------------------------------------
+
+This will create a new commit which undoes the change in HEAD. You
+will be given a chance to edit the commit message for the new commit.
+
+You can also revert an earlier change, for example, the next-to-last:
+
+-------------------------------------------------
+$ git revert HEAD^
+-------------------------------------------------
+
+In this case git will attempt to undo the old change while leaving
+intact any changes made since then. If more recent changes overlap
+with the changes to be reverted, then you will be asked to fix
+conflicts manually, just as in the case of <<resolving-a-merge,
+resolving a merge>>.
+
+[[fixing-a-mistake-by-rewriting-history]]
+Fixing a mistake by rewriting history
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If the problematic commit is the most recent commit, and you have not
+yet made that commit public, then you may just
+<<undoing-a-merge,destroy it using git-reset>>.
+
+Alternatively, you
+can edit the working directory and update the index to fix your
+mistake, just as if you were going to <<how-to-make-a-commit,create a
+new commit>>, then run
+
+-------------------------------------------------
+$ git commit --amend
+-------------------------------------------------
+
+which will replace the old commit by a new commit incorporating your
+changes, giving you a chance to edit the old commit message first.
+
+Again, you should never do this to a commit that may already have
+been merged into another branch; use linkgit:git-revert[1] instead in
+that case.
+
+It is also possible to replace commits further back in the history, but
+this is an advanced topic to be left for
+<<cleaning-up-history,another chapter>>.
+
+[[checkout-of-path]]
+Checking out an old version of a file
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In the process of undoing a previous bad change, you may find it
+useful to check out an older version of a particular file using
+linkgit:git-checkout[1]. We've used git checkout before to switch
+branches, but it has quite different behavior if it is given a path
+name: the command
+
+-------------------------------------------------
+$ git checkout HEAD^ path/to/file
+-------------------------------------------------
+
+replaces path/to/file by the contents it had in the commit HEAD^, and
+also updates the index to match. It does not change branches.
+
+If you just want to look at an old version of the file, without
+modifying the working directory, you can do that with
+linkgit:git-show[1]:
+
+-------------------------------------------------
+$ git show HEAD^:path/to/file
+-------------------------------------------------
+
+which will display the given version of the file.
+
+[[interrupted-work]]
+Temporarily setting aside work in progress
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+While you are in the middle of working on something complicated, you
+find an unrelated but obvious and trivial bug. You would like to fix it
+before continuing. You can use linkgit:git-stash[1] to save the current
+state of your work, and after fixing the bug (or, optionally after doing
+so on a different branch and then coming back), unstash the
+work-in-progress changes.
+
+------------------------------------------------
+$ git stash "work in progress for foo feature"
+------------------------------------------------
+
+This command will save your changes away to the `stash`, and
+reset your working tree and the index to match the tip of your
+current branch. Then you can make your fix as usual.
+
+------------------------------------------------
+... edit and test ...
+$ git commit -a -m "blorpl: typofix"
+------------------------------------------------
+
+After that, you can go back to what you were working on with
+`git stash apply`:
+
+------------------------------------------------
+$ git stash apply
+------------------------------------------------
+
+
+[[ensuring-good-performance]]
+Ensuring good performance
+-------------------------
+
+On large repositories, git depends on compression to keep the history
+information from taking up too much space on disk or in memory.
+
+This compression is not performed automatically. Therefore you
+should occasionally run linkgit:git-gc[1]:
+
+-------------------------------------------------
+$ git gc
+-------------------------------------------------
+
+to recompress the archive. This can be very time-consuming, so
+you may prefer to run git-gc when you are not doing other work.
+
+
+[[ensuring-reliability]]
+Ensuring reliability
+--------------------
+
+[[checking-for-corruption]]
+Checking the repository for corruption
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The linkgit:git-fsck[1] command runs a number of self-consistency checks
+on the repository, and reports on any problems. This may take some
+time. The most common warning by far is about "dangling" objects:
+
+-------------------------------------------------
+$ git fsck
+dangling commit 7281251ddd2a61e38657c827739c57015671a6b3
+dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63
+dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5
+dangling blob 218761f9d90712d37a9c5e36f406f92202db07eb
+dangling commit bf093535a34a4d35731aa2bd90fe6b176302f14f
+dangling commit 8e4bec7f2ddaa268bef999853c25755452100f8e
+dangling tree d50bb86186bf27b681d25af89d3b5b68382e4085
+dangling tree b24c2473f1fd3d91352a624795be026d64c8841f
+...
+-------------------------------------------------
+
+Dangling objects are not a problem. At worst they may take up a little
+extra disk space. They can sometimes provide a last-resort method for
+recovering lost work--see <<dangling-objects>> for details.
+
+[[recovering-lost-changes]]
+Recovering lost changes
+~~~~~~~~~~~~~~~~~~~~~~~
+
+[[reflogs]]
+Reflogs
+^^^^^^^
+
+Say you modify a branch with `linkgit:git-reset[1] --hard`, and then
+realize that the branch was the only reference you had to that point in
+history.
+
+Fortunately, git also keeps a log, called a "reflog", of all the
+previous values of each branch. So in this case you can still find the
+old history using, for example,
+
+-------------------------------------------------
+$ git log master@{1}
+-------------------------------------------------
+
+This lists the commits reachable from the previous version of the
+"master" branch head. This syntax can be used with any git command
+that accepts a commit, not just with git log. Some other examples:
+
+-------------------------------------------------
+$ git show master@{2} # See where the branch pointed 2,
+$ git show master@{3} # 3, ... changes ago.
+$ gitk master@{yesterday} # See where it pointed yesterday,
+$ gitk master@{"1 week ago"} # ... or last week
+$ git log --walk-reflogs master # show reflog entries for master
+-------------------------------------------------
+
+A separate reflog is kept for the HEAD, so
+
+-------------------------------------------------
+$ git show HEAD@{"1 week ago"}
+-------------------------------------------------
+
+will show what HEAD pointed to one week ago, not what the current branch
+pointed to one week ago. This allows you to see the history of what
+you've checked out.
+
+The reflogs are kept by default for 30 days, after which they may be
+pruned. See linkgit:git-reflog[1] and linkgit:git-gc[1] to learn
+how to control this pruning, and see the "SPECIFYING REVISIONS"
+section of linkgit:git-rev-parse[1] for details.
+
+Note that the reflog history is very different from normal git history.
+While normal history is shared by every repository that works on the
+same project, the reflog history is not shared: it tells you only about
+how the branches in your local repository have changed over time.
+
+[[dangling-object-recovery]]
+Examining dangling objects
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In some situations the reflog may not be able to save you. For example,
+suppose you delete a branch, then realize you need the history it
+contained. The reflog is also deleted; however, if you have not yet
+pruned the repository, then you may still be able to find the lost
+commits in the dangling objects that git-fsck reports. See
+<<dangling-objects>> for the details.
+
+-------------------------------------------------
+$ git fsck
+dangling commit 7281251ddd2a61e38657c827739c57015671a6b3
+dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63
+dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5
+...
+-------------------------------------------------
+
+You can examine
+one of those dangling commits with, for example,
+
+------------------------------------------------
+$ gitk 7281251ddd --not --all
+------------------------------------------------
+
+which does what it sounds like: it says that you want to see the commit
+history that is described by the dangling commit(s), but not the
+history that is described by all your existing branches and tags. Thus
+you get exactly the history reachable from that commit that is lost.
+(And notice that it might not be just one commit: we only report the
+"tip of the line" as being dangling, but there might be a whole deep
+and complex commit history that was dropped.)
+
+If you decide you want the history back, you can always create a new
+reference pointing to it, for example, a new branch:
+
+------------------------------------------------
+$ git branch recovered-branch 7281251ddd
+------------------------------------------------
+
+Other types of dangling objects (blobs and trees) are also possible, and
+dangling objects can arise in other situations.
+
+
+[[sharing-development]]
+Sharing development with others
+===============================
+
+[[getting-updates-with-git-pull]]
+Getting updates with git pull
+-----------------------------
+
+After you clone a repository and make a few changes of your own, you
+may wish to check the original repository for updates and merge them
+into your own work.
+
+We have already seen <<Updating-a-repository-with-git-fetch,how to
+keep remote tracking branches up to date>> with linkgit:git-fetch[1],
+and how to merge two branches. So you can merge in changes from the
+original repository's master branch with:
+
+-------------------------------------------------
+$ git fetch
+$ git merge origin/master
+-------------------------------------------------
+
+However, the linkgit:git-pull[1] command provides a way to do this in
+one step:
+
+-------------------------------------------------
+$ git pull origin master
+-------------------------------------------------
+
+In fact, if you have "master" checked out, then by default "git pull"
+merges from the HEAD branch of the origin repository. So often you can
+accomplish the above with just a simple
+
+-------------------------------------------------
+$ git pull
+-------------------------------------------------
+
+More generally, a branch that is created from a remote branch will pull
+by default from that branch. See the descriptions of the
+branch.<name>.remote and branch.<name>.merge options in
+linkgit:git-config[1], and the discussion of the `--track` option in
+linkgit:git-checkout[1], to learn how to control these defaults.
+
+In addition to saving you keystrokes, "git pull" also helps you by
+producing a default commit message documenting the branch and
+repository that you pulled from.
+
+(But note that no such commit will be created in the case of a
+<<fast-forwards,fast forward>>; instead, your branch will just be
+updated to point to the latest commit from the upstream branch.)
+
+The git-pull command can also be given "." as the "remote" repository,
+in which case it just merges in a branch from the current repository; so
+the commands
+
+-------------------------------------------------
+$ git pull . branch
+$ git merge branch
+-------------------------------------------------
+
+are roughly equivalent. The former is actually very commonly used.
+
+[[submitting-patches]]
+Submitting patches to a project
+-------------------------------
+
+If you just have a few changes, the simplest way to submit them may
+just be to send them as patches in email:
+
+First, use linkgit:git-format-patch[1]; for example:
+
+-------------------------------------------------
+$ git format-patch origin
+-------------------------------------------------
+
+will produce a numbered series of files in the current directory, one
+for each patch in the current branch but not in origin/HEAD.
+
+You can then import these into your mail client and send them by
+hand. However, if you have a lot to send at once, you may prefer to
+use the linkgit:git-send-email[1] script to automate the process.
+Consult the mailing list for your project first to determine how they
+prefer such patches be handled.
+
+[[importing-patches]]
+Importing patches to a project
+------------------------------
+
+Git also provides a tool called linkgit:git-am[1] (am stands for
+"apply mailbox"), for importing such an emailed series of patches.
+Just save all of the patch-containing messages, in order, into a
+single mailbox file, say "patches.mbox", then run
+
+-------------------------------------------------
+$ git am -3 patches.mbox
+-------------------------------------------------
+
+Git will apply each patch in order; if any conflicts are found, it
+will stop, and you can fix the conflicts as described in
+"<<resolving-a-merge,Resolving a merge>>". (The "-3" option tells
+git to perform a merge; if you would prefer it just to abort and
+leave your tree and index untouched, you may omit that option.)
+
+Once the index is updated with the results of the conflict
+resolution, instead of creating a new commit, just run
+
+-------------------------------------------------
+$ git am --resolved
+-------------------------------------------------
+
+and git will create the commit for you and continue applying the
+remaining patches from the mailbox.
+
+The final result will be a series of commits, one for each patch in
+the original mailbox, with authorship and commit log message each
+taken from the message containing each patch.
+
+[[public-repositories]]
+Public git repositories
+-----------------------
+
+Another way to submit changes to a project is to tell the maintainer
+of that project to pull the changes from your repository using
+linkgit:git-pull[1]. In the section "<<getting-updates-with-git-pull,
+Getting updates with git pull>>" we described this as a way to get
+updates from the "main" repository, but it works just as well in the
+other direction.
+
+If you and the maintainer both have accounts on the same machine, then
+you can just pull changes from each other's repositories directly;
+commands that accept repository URLs as arguments will also accept a
+local directory name:
+
+-------------------------------------------------
+$ git clone /path/to/repository
+$ git pull /path/to/other/repository
+-------------------------------------------------
+
+or an ssh URL:
+
+-------------------------------------------------
+$ git clone ssh://yourhost/~you/repository
+-------------------------------------------------
+
+For projects with few developers, or for synchronizing a few private
+repositories, this may be all you need.
+
+However, the more common way to do this is to maintain a separate public
+repository (usually on a different host) for others to pull changes
+from. This is usually more convenient, and allows you to cleanly
+separate private work in progress from publicly visible work.
+
+You will continue to do your day-to-day work in your personal
+repository, but periodically "push" changes from your personal
+repository into your public repository, allowing other developers to
+pull from that repository. So the flow of changes, in a situation
+where there is one other developer with a public repository, looks
+like this:
+
+ you push
+ your personal repo ------------------> your public repo
+ ^ |
+ | |
+ | you pull | they pull
+ | |
+ | |
+ | they push V
+ their public repo <------------------- their repo
+
+We explain how to do this in the following sections.
+
+[[setting-up-a-public-repository]]
+Setting up a public repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Assume your personal repository is in the directory ~/proj. We
+first create a new clone of the repository and tell git-daemon that it
+is meant to be public:
+
+-------------------------------------------------
+$ git clone --bare ~/proj proj.git
+$ touch proj.git/git-daemon-export-ok
+-------------------------------------------------
+
+The resulting directory proj.git contains a "bare" git repository--it is
+just the contents of the ".git" directory, without any files checked out
+around it.
+
+Next, copy proj.git to the server where you plan to host the
+public repository. You can use scp, rsync, or whatever is most
+convenient.
+
+[[exporting-via-git]]
+Exporting a git repository via the git protocol
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This is the preferred method.
+
+If someone else administers the server, they should tell you what
+directory to put the repository in, and what git:// URL it will appear
+at. You can then skip to the section
+"<<pushing-changes-to-a-public-repository,Pushing changes to a public
+repository>>", below.
+
+Otherwise, all you need to do is start linkgit:git-daemon[1]; it will
+listen on port 9418. By default, it will allow access to any directory
+that looks like a git directory and contains the magic file
+git-daemon-export-ok. Passing some directory paths as git-daemon
+arguments will further restrict the exports to those paths.
+
+You can also run git-daemon as an inetd service; see the
+linkgit:git-daemon[1] man page for details. (See especially the
+examples section.)
+
+[[exporting-via-http]]
+Exporting a git repository via http
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The git protocol gives better performance and reliability, but on a
+host with a web server set up, http exports may be simpler to set up.
+
+All you need to do is place the newly created bare git repository in
+a directory that is exported by the web server, and make some
+adjustments to give web clients some extra information they need:
+
+-------------------------------------------------
+$ mv proj.git /home/you/public_html/proj.git
+$ cd proj.git
+$ git --bare update-server-info
+$ chmod a+x hooks/post-update
+-------------------------------------------------
+
+(For an explanation of the last two lines, see
+linkgit:git-update-server-info[1], and the documentation
+linkgit:githooks[5][Hooks used by git].)
+
+Advertise the URL of proj.git. Anybody else should then be able to
+clone or pull from that URL, for example with a command line like:
+
+-------------------------------------------------
+$ git clone http://yourserver.com/~you/proj.git
+-------------------------------------------------
+
+(See also
+link:howto/setup-git-server-over-http.txt[setup-git-server-over-http]
+for a slightly more sophisticated setup using WebDAV which also
+allows pushing over http.)
+
+[[pushing-changes-to-a-public-repository]]
+Pushing changes to a public repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Note that the two techniques outlined above (exporting via
+<<exporting-via-http,http>> or <<exporting-via-git,git>>) allow other
+maintainers to fetch your latest changes, but they do not allow write
+access, which you will need to update the public repository with the
+latest changes created in your private repository.
+
+The simplest way to do this is using linkgit:git-push[1] and ssh; to
+update the remote branch named "master" with the latest state of your
+branch named "master", run
+
+-------------------------------------------------
+$ git push ssh://yourserver.com/~you/proj.git master:master
+-------------------------------------------------
+
+or just
+
+-------------------------------------------------
+$ git push ssh://yourserver.com/~you/proj.git master
+-------------------------------------------------
+
+As with git-fetch, git-push will complain if this does not result in a
+<<fast-forwards,fast forward>>; see the following section for details on
+handling this case.
+
+Note that the target of a "push" is normally a
+<<def_bare_repository,bare>> repository. You can also push to a
+repository that has a checked-out working tree, but the working tree
+will not be updated by the push. This may lead to unexpected results if
+the branch you push to is the currently checked-out branch!
+
+As with git-fetch, you may also set up configuration options to
+save typing; so, for example, after
+
+-------------------------------------------------
+$ cat >>.git/config <<EOF
+[remote "public-repo"]
+ url = ssh://yourserver.com/~you/proj.git
+EOF
+-------------------------------------------------
+
+you should be able to perform the above push with just
+
+-------------------------------------------------
+$ git push public-repo master
+-------------------------------------------------
+
+See the explanations of the remote.<name>.url, branch.<name>.remote,
+and remote.<name>.push options in linkgit:git-config[1] for
+details.
+
+[[forcing-push]]
+What to do when a push fails
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If a push would not result in a <<fast-forwards,fast forward>> of the
+remote branch, then it will fail with an error like:
+
+-------------------------------------------------
+error: remote 'refs/heads/master' is not an ancestor of
+ local 'refs/heads/master'.
+ Maybe you are not up-to-date and need to pull first?
+error: failed to push to 'ssh://yourserver.com/~you/proj.git'
+-------------------------------------------------
+
+This can happen, for example, if you:
+
+ - use `git reset --hard` to remove already-published commits, or
+ - use `git commit --amend` to replace already-published commits
+ (as in <<fixing-a-mistake-by-rewriting-history>>), or
+ - use `git rebase` to rebase any already-published commits (as
+ in <<using-git-rebase>>).
+
+You may force git-push to perform the update anyway by preceding the
+branch name with a plus sign:
+
+-------------------------------------------------
+$ git push ssh://yourserver.com/~you/proj.git +master
+-------------------------------------------------
+
+Normally whenever a branch head in a public repository is modified, it
+is modified to point to a descendant of the commit that it pointed to
+before. By forcing a push in this situation, you break that convention.
+(See <<problems-with-rewriting-history>>.)
+
+Nevertheless, this is a common practice for people that need a simple
+way to publish a work-in-progress patch series, and it is an acceptable
+compromise as long as you warn other developers that this is how you
+intend to manage the branch.
+
+It's also possible for a push to fail in this way when other people have
+the right to push to the same repository. In that case, the correct
+solution is to retry the push after first updating your work by either a
+pull or a fetch followed by a rebase; see the
+<<setting-up-a-shared-repository,next section>> and
+linkgit:gitcvs-migration[7][git for CVS users] for more.
+
+[[setting-up-a-shared-repository]]
+Setting up a shared repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Another way to collaborate is by using a model similar to that
+commonly used in CVS, where several developers with special rights
+all push to and pull from a single shared repository. See
+linkgit:gitcvs-migration[7][git for CVS users] for instructions on how to
+set this up.
+
+However, while there is nothing wrong with git's support for shared
+repositories, this mode of operation is not generally recommended,
+simply because the mode of collaboration that git supports--by
+exchanging patches and pulling from public repositories--has so many
+advantages over the central shared repository:
+
+ - Git's ability to quickly import and merge patches allows a
+ single maintainer to process incoming changes even at very
+ high rates. And when that becomes too much, git-pull provides
+ an easy way for that maintainer to delegate this job to other
+ maintainers while still allowing optional review of incoming
+ changes.
+ - Since every developer's repository has the same complete copy
+ of the project history, no repository is special, and it is
+ trivial for another developer to take over maintenance of a
+ project, either by mutual agreement, or because a maintainer
+ becomes unresponsive or difficult to work with.
+ - The lack of a central group of "committers" means there is
+ less need for formal decisions about who is "in" and who is
+ "out".
+
+[[setting-up-gitweb]]
+Allowing web browsing of a repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The gitweb cgi script provides users an easy way to browse your
+project's files and history without having to install git; see the file
+gitweb/INSTALL in the git source tree for instructions on setting it up.
+
+[[sharing-development-examples]]
+Examples
+--------
+
+[[maintaining-topic-branches]]
+Maintaining topic branches for a Linux subsystem maintainer
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This describes how Tony Luck uses git in his role as maintainer of the
+IA64 architecture for the Linux kernel.
+
+He uses two public branches:
+
+ - A "test" tree into which patches are initially placed so that they
+ can get some exposure when integrated with other ongoing development.
+ This tree is available to Andrew for pulling into -mm whenever he
+ wants.
+
+ - A "release" tree into which tested patches are moved for final sanity
+ checking, and as a vehicle to send them upstream to Linus (by sending
+ him a "please pull" request.)
+
+He also uses a set of temporary branches ("topic branches"), each
+containing a logical grouping of patches.
+
+To set this up, first create your work tree by cloning Linus's public
+tree:
+
+-------------------------------------------------
+$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
+$ cd work
+-------------------------------------------------
+
+Linus's tree will be stored in the remote branch named origin/master,
+and can be updated using linkgit:git-fetch[1]; you can track other
+public trees using linkgit:git-remote[1] to set up a "remote" and
+linkgit:git-fetch[1] to keep them up-to-date; see
+<<repositories-and-branches>>.
+
+Now create the branches in which you are going to work; these start out
+at the current tip of origin/master branch, and should be set up (using
+the --track option to linkgit:git-branch[1]) to merge changes in from
+Linus by default.
+
+-------------------------------------------------
+$ git branch --track test origin/master
+$ git branch --track release origin/master
+-------------------------------------------------
+
+These can be easily kept up to date using linkgit:git-pull[1].
+
+-------------------------------------------------
+$ git checkout test && git pull
+$ git checkout release && git pull
+-------------------------------------------------
+
+Important note! If you have any local changes in these branches, then
+this merge will create a commit object in the history (with no local
+changes git will simply do a "Fast forward" merge). Many people dislike
+the "noise" that this creates in the Linux history, so you should avoid
+doing this capriciously in the "release" branch, as these noisy commits
+will become part of the permanent history when you ask Linus to pull
+from the release branch.
+
+A few configuration variables (see linkgit:git-config[1]) can
+make it easy to push both branches to your public tree. (See
+<<setting-up-a-public-repository>>.)
+
+-------------------------------------------------
+$ cat >> .git/config <<EOF
+[remote "mytree"]
+ url = master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
+ push = release
+ push = test
+EOF
+-------------------------------------------------
+
+Then you can push both the test and release trees using
+linkgit:git-push[1]:
+
+-------------------------------------------------
+$ git push mytree
+-------------------------------------------------
+
+or push just one of the test and release branches using:
+
+-------------------------------------------------
+$ git push mytree test
+-------------------------------------------------
+
+or
+
+-------------------------------------------------
+$ git push mytree release
+-------------------------------------------------
+
+Now to apply some patches from the community. Think of a short
+snappy name for a branch to hold this patch (or related group of
+patches), and create a new branch from the current tip of Linus's
+branch:
+
+-------------------------------------------------
+$ git checkout -b speed-up-spinlocks origin
+-------------------------------------------------
+
+Now you apply the patch(es), run some tests, and commit the change(s). If
+the patch is a multi-part series, then you should apply each as a separate
+commit to this branch.
+
+-------------------------------------------------
+$ ... patch ... test ... commit [ ... patch ... test ... commit ]*
+-------------------------------------------------
+
+When you are happy with the state of this change, you can pull it into the
+"test" branch in preparation to make it public:
+
+-------------------------------------------------
+$ git checkout test && git pull . speed-up-spinlocks
+-------------------------------------------------
+
+It is unlikely that you would have any conflicts here ... but you might if you
+spent a while on this step and had also pulled new versions from upstream.
+
+Some time later when enough time has passed and testing done, you can pull the
+same branch into the "release" tree ready to go upstream. This is where you
+see the value of keeping each patch (or patch series) in its own branch. It
+means that the patches can be moved into the "release" tree in any order.
+
+-------------------------------------------------
+$ git checkout release && git pull . speed-up-spinlocks
+-------------------------------------------------
+
+After a while, you will have a number of branches, and despite the
+well chosen names you picked for each of them, you may forget what
+they are for, or what status they are in. To get a reminder of what
+changes are in a specific branch, use:
+
+-------------------------------------------------
+$ git log linux..branchname | git-shortlog
+-------------------------------------------------
+
+To see whether it has already been merged into the test or release branches,
+use:
+
+-------------------------------------------------
+$ git log test..branchname
+-------------------------------------------------
+
+or
+
+-------------------------------------------------
+$ git log release..branchname
+-------------------------------------------------
+
+(If this branch has not yet been merged, you will see some log entries.
+If it has been merged, then there will be no output.)
+
+Once a patch completes the great cycle (moving from test to release,
+then pulled by Linus, and finally coming back into your local
+"origin/master" branch), the branch for this change is no longer needed.
+You detect this when the output from:
+
+-------------------------------------------------
+$ git log origin..branchname
+-------------------------------------------------
+
+is empty. At this point the branch can be deleted:
+
+-------------------------------------------------
+$ git branch -d branchname
+-------------------------------------------------
+
+Some changes are so trivial that it is not necessary to create a separate
+branch and then merge into each of the test and release branches. For
+these changes, just apply directly to the "release" branch, and then
+merge that into the "test" branch.
+
+To create diffstat and shortlog summaries of changes to include in a "please
+pull" request to Linus you can use:
+
+-------------------------------------------------
+$ git diff --stat origin..release
+-------------------------------------------------
+
+and
+
+-------------------------------------------------
+$ git log -p origin..release | git shortlog
+-------------------------------------------------
+
+Here are some of the scripts that simplify all this even further.
+
+-------------------------------------------------
+==== update script ====
+# Update a branch in my GIT tree. If the branch to be updated
+# is origin, then pull from kernel.org. Otherwise merge
+# origin/master branch into test|release branch
+
+case "$1" in
+test|release)
+ git checkout $1 && git pull . origin
+ ;;
+origin)
+ before=$(git rev-parse refs/remotes/origin/master)
+ git fetch origin
+ after=$(git rev-parse refs/remotes/origin/master)
+ if [ $before != $after ]
+ then
+ git log $before..$after | git shortlog
+ fi
+ ;;
+*)
+ echo "Usage: $0 origin|test|release" 1>&2
+ exit 1
+ ;;
+esac
+-------------------------------------------------
+
+-------------------------------------------------
+==== merge script ====
+# Merge a branch into either the test or release branch
+
+pname=$0
+
+usage()
+{
+ echo "Usage: $pname branch test|release" 1>&2
+ exit 1
+}
+
+git show-ref -q --verify -- refs/heads/"$1" || {
+ echo "Can't see branch <$1>" 1>&2
+ usage
+}
+
+case "$2" in
+test|release)
+ if [ $(git log $2..$1 | wc -c) -eq 0 ]
+ then
+ echo $1 already merged into $2 1>&2
+ exit 1
+ fi
+ git checkout $2 && git pull . $1
+ ;;
+*)
+ usage
+ ;;
+esac
+-------------------------------------------------
+
+-------------------------------------------------
+==== status script ====
+# report on status of my ia64 GIT tree
+
+gb=$(tput setab 2)
+rb=$(tput setab 1)
+restore=$(tput setab 9)
+
+if [ `git rev-list test..release | wc -c` -gt 0 ]
+then
+ echo $rb Warning: commits in release that are not in test $restore
+ git log test..release
+fi
+
+for branch in `git show-ref --heads | sed 's|^.*/||'`
+do
+ if [ $branch = test -o $branch = release ]
+ then
+ continue
+ fi
+
+ echo -n $gb ======= $branch ====== $restore " "
+ status=
+ for ref in test release origin/master
+ do
+ if [ `git rev-list $ref..$branch | wc -c` -gt 0 ]
+ then
+ status=$status${ref:0:1}
+ fi
+ done
+ case $status in
+ trl)
+ echo $rb Need to pull into test $restore
+ ;;
+ rl)
+ echo "In test"
+ ;;
+ l)
+ echo "Waiting for linus"
+ ;;
+ "")
+ echo $rb All done $restore
+ ;;
+ *)
+ echo $rb "<$status>" $restore
+ ;;
+ esac
+ git log origin/master..$branch | git shortlog
+done
+-------------------------------------------------
+
+
+[[cleaning-up-history]]
+Rewriting history and maintaining patch series
+==============================================
+
+Normally commits are only added to a project, never taken away or
+replaced. Git is designed with this assumption, and violating it will
+cause git's merge machinery (for example) to do the wrong thing.
+
+However, there is a situation in which it can be useful to violate this
+assumption.
+
+[[patch-series]]
+Creating the perfect patch series
+---------------------------------
+
+Suppose you are a contributor to a large project, and you want to add a
+complicated feature, and to present it to the other developers in a way
+that makes it easy for them to read your changes, verify that they are
+correct, and understand why you made each change.
+
+If you present all of your changes as a single patch (or commit), they
+may find that it is too much to digest all at once.
+
+If you present them with the entire history of your work, complete with
+mistakes, corrections, and dead ends, they may be overwhelmed.
+
+So the ideal is usually to produce a series of patches such that:
+
+ 1. Each patch can be applied in order.
+
+ 2. Each patch includes a single logical change, together with a
+ message explaining the change.
+
+ 3. No patch introduces a regression: after applying any initial
+ part of the series, the resulting project still compiles and
+ works, and has no bugs that it didn't have before.
+
+ 4. The complete series produces the same end result as your own
+ (probably much messier!) development process did.
+
+We will introduce some tools that can help you do this, explain how to
+use them, and then explain some of the problems that can arise because
+you are rewriting history.
+
+[[using-git-rebase]]
+Keeping a patch series up to date using git-rebase
+--------------------------------------------------
+
+Suppose that you create a branch "mywork" on a remote-tracking branch
+"origin", and create some commits on top of it:
+
+-------------------------------------------------
+$ git checkout -b mywork origin
+$ vi file.txt
+$ git commit
+$ vi otherfile.txt
+$ git commit
+...
+-------------------------------------------------
+
+You have performed no merges into mywork, so it is just a simple linear
+sequence of patches on top of "origin":
+
+................................................
+ o--o--o <-- origin
+ \
+ o--o--o <-- mywork
+................................................
+
+Some more interesting work has been done in the upstream project, and
+"origin" has advanced:
+
+................................................
+ o--o--O--o--o--o <-- origin
+ \
+ a--b--c <-- mywork
+................................................
+
+At this point, you could use "pull" to merge your changes back in;
+the result would create a new merge commit, like this:
+
+................................................
+ o--o--O--o--o--o <-- origin
+ \ \
+ a--b--c--m <-- mywork
+................................................
+
+However, if you prefer to keep the history in mywork a simple series of
+commits without any merges, you may instead choose to use
+linkgit:git-rebase[1]:
+
+-------------------------------------------------
+$ git checkout mywork
+$ git rebase origin
+-------------------------------------------------
+
+This will remove each of your commits from mywork, temporarily saving
+them as patches (in a directory named ".dotest"), update mywork to
+point at the latest version of origin, then apply each of the saved
+patches to the new mywork. The result will look like:
+
+
+................................................
+ o--o--O--o--o--o <-- origin
+ \
+ a'--b'--c' <-- mywork
+................................................
+
+In the process, it may discover conflicts. In that case it will stop
+and allow you to fix the conflicts; after fixing conflicts, use "git
+add" to update the index with those contents, and then, instead of
+running git-commit, just run
+
+-------------------------------------------------
+$ git rebase --continue
+-------------------------------------------------
+
+and git will continue applying the rest of the patches.
+
+At any point you may use the `--abort` option to abort this process and
+return mywork to the state it had before you started the rebase:
+
+-------------------------------------------------
+$ git rebase --abort
+-------------------------------------------------
+
+[[rewriting-one-commit]]
+Rewriting a single commit
+-------------------------
+
+We saw in <<fixing-a-mistake-by-rewriting-history>> that you can replace the
+most recent commit using
+
+-------------------------------------------------
+$ git commit --amend
+-------------------------------------------------
+
+which will replace the old commit by a new commit incorporating your
+changes, giving you a chance to edit the old commit message first.
+
+You can also use a combination of this and linkgit:git-rebase[1] to
+replace a commit further back in your history and recreate the
+intervening changes on top of it. First, tag the problematic commit
+with
+
+-------------------------------------------------
+$ git tag bad mywork~5
+-------------------------------------------------
+
+(Either gitk or git-log may be useful for finding the commit.)
+
+Then check out that commit, edit it, and rebase the rest of the series
+on top of it (note that we could check out the commit on a temporary
+branch, but instead we're using a <<detached-head,detached head>>):
+
+-------------------------------------------------
+$ git checkout bad
+$ # make changes here and update the index
+$ git commit --amend
+$ git rebase --onto HEAD bad mywork
+-------------------------------------------------
+
+When you're done, you'll be left with mywork checked out, with the top
+patches on mywork reapplied on top of your modified commit. You can
+then clean up with
+
+-------------------------------------------------
+$ git tag -d bad
+-------------------------------------------------
+
+Note that the immutable nature of git history means that you haven't really
+"modified" existing commits; instead, you have replaced the old commits with
+new commits having new object names.
+
+[[reordering-patch-series]]
+Reordering or selecting from a patch series
+-------------------------------------------
+
+Given one existing commit, the linkgit:git-cherry-pick[1] command
+allows you to apply the change introduced by that commit and create a
+new commit that records it. So, for example, if "mywork" points to a
+series of patches on top of "origin", you might do something like:
+
+-------------------------------------------------
+$ git checkout -b mywork-new origin
+$ gitk origin..mywork &
+-------------------------------------------------
+
+and browse through the list of patches in the mywork branch using gitk,
+applying them (possibly in a different order) to mywork-new using
+cherry-pick, and possibly modifying them as you go using `commit --amend`.
+The linkgit:git-gui[1] command may also help as it allows you to
+individually select diff hunks for inclusion in the index (by
+right-clicking on the diff hunk and choosing "Stage Hunk for Commit").
+
+Another technique is to use git-format-patch to create a series of
+patches, then reset the state to before the patches:
+
+-------------------------------------------------
+$ git format-patch origin
+$ git reset --hard origin
+-------------------------------------------------
+
+Then modify, reorder, or eliminate patches as preferred before applying
+them again with linkgit:git-am[1].
+
+[[patch-series-tools]]
+Other tools
+-----------
+
+There are numerous other tools, such as StGIT, which exist for the
+purpose of maintaining a patch series. These are outside of the scope of
+this manual.
+
+[[problems-with-rewriting-history]]
+Problems with rewriting history
+-------------------------------
+
+The primary problem with rewriting the history of a branch has to do
+with merging. Suppose somebody fetches your branch and merges it into
+their branch, with a result something like this:
+
+................................................
+ o--o--O--o--o--o <-- origin
+ \ \
+ t--t--t--m <-- their branch:
+................................................
+
+Then suppose you modify the last three commits:
+
+................................................
+ o--o--o <-- new head of origin
+ /
+ o--o--O--o--o--o <-- old head of origin
+................................................
+
+If we examined all this history together in one repository, it will
+look like:
+
+................................................
+ o--o--o <-- new head of origin
+ /
+ o--o--O--o--o--o <-- old head of origin
+ \ \
+ t--t--t--m <-- their branch:
+................................................
+
+Git has no way of knowing that the new head is an updated version of
+the old head; it treats this situation exactly the same as it would if
+two developers had independently done the work on the old and new heads
+in parallel. At this point, if someone attempts to merge the new head
+in to their branch, git will attempt to merge together the two (old and
+new) lines of development, instead of trying to replace the old by the
+new. The results are likely to be unexpected.
+
+You may still choose to publish branches whose history is rewritten,
+and it may be useful for others to be able to fetch those branches in
+order to examine or test them, but they should not attempt to pull such
+branches into their own work.
+
+For true distributed development that supports proper merging,
+published branches should never be rewritten.
+
+[[bisect-merges]]
+Why bisecting merge commits can be harder than bisecting linear history
+-----------------------------------------------------------------------
+
+The linkgit:git-bisect[1] command correctly handles history that
+includes merge commits. However, when the commit that it finds is a
+merge commit, the user may need to work harder than usual to figure out
+why that commit introduced a problem.
+
+Imagine this history:
+
+................................................
+ ---Z---o---X---...---o---A---C---D
+ \ /
+ o---o---Y---...---o---B
+................................................
+
+Suppose that on the upper line of development, the meaning of one
+of the functions that exists at Z is changed at commit X. The
+commits from Z leading to A change both the function's
+implementation and all calling sites that exist at Z, as well
+as new calling sites they add, to be consistent. There is no
+bug at A.
+
+Suppose that in the meantime on the lower line of development somebody
+adds a new calling site for that function at commit Y. The
+commits from Z leading to B all assume the old semantics of that
+function and the callers and the callee are consistent with each
+other. There is no bug at B, either.
+
+Suppose further that the two development lines merge cleanly at C,
+so no conflict resolution is required.
+
+Nevertheless, the code at C is broken, because the callers added
+on the lower line of development have not been converted to the new
+semantics introduced on the upper line of development. So if all
+you know is that D is bad, that Z is good, and that
+linkgit:git-bisect[1] identifies C as the culprit, how will you
+figure out that the problem is due to this change in semantics?
+
+When the result of a git-bisect is a non-merge commit, you should
+normally be able to discover the problem by examining just that commit.
+Developers can make this easy by breaking their changes into small
+self-contained commits. That won't help in the case above, however,
+because the problem isn't obvious from examination of any single
+commit; instead, a global view of the development is required. To
+make matters worse, the change in semantics in the problematic
+function may be just one small part of the changes in the upper
+line of development.
+
+On the other hand, if instead of merging at C you had rebased the
+history between Z to B on top of A, you would have gotten this
+linear history:
+
+................................................................
+ ---Z---o---X--...---o---A---o---o---Y*--...---o---B*--D*
+................................................................
+
+Bisecting between Z and D* would hit a single culprit commit Y*,
+and understanding why Y* was broken would probably be easier.
+
+Partly for this reason, many experienced git users, even when
+working on an otherwise merge-heavy project, keep the history
+linear by rebasing against the latest upstream version before
+publishing.
+
+[[advanced-branch-management]]
+Advanced branch management
+==========================
+
+[[fetching-individual-branches]]
+Fetching individual branches
+----------------------------
+
+Instead of using linkgit:git-remote[1], you can also choose just
+to update one branch at a time, and to store it locally under an
+arbitrary name:
+
+-------------------------------------------------
+$ git fetch origin todo:my-todo-work
+-------------------------------------------------
+
+The first argument, "origin", just tells git to fetch from the
+repository you originally cloned from. The second argument tells git
+to fetch the branch named "todo" from the remote repository, and to
+store it locally under the name refs/heads/my-todo-work.
+
+You can also fetch branches from other repositories; so
+
+-------------------------------------------------
+$ git fetch git://example.com/proj.git master:example-master
+-------------------------------------------------
+
+will create a new branch named "example-master" and store in it the
+branch named "master" from the repository at the given URL. If you
+already have a branch named example-master, it will attempt to
+<<fast-forwards,fast-forward>> to the commit given by example.com's
+master branch. In more detail:
+
+[[fetch-fast-forwards]]
+git fetch and fast-forwards
+---------------------------
+
+In the previous example, when updating an existing branch, "git
+fetch" checks to make sure that the most recent commit on the remote
+branch is a descendant of the most recent commit on your copy of the
+branch before updating your copy of the branch to point at the new
+commit. Git calls this process a <<fast-forwards,fast forward>>.
+
+A fast forward looks something like this:
+
+................................................
+ o--o--o--o <-- old head of the branch
+ \
+ o--o--o <-- new head of the branch
+................................................
+
+
+In some cases it is possible that the new head will *not* actually be
+a descendant of the old head. For example, the developer may have
+realized she made a serious mistake, and decided to backtrack,
+resulting in a situation like:
+
+................................................
+ o--o--o--o--a--b <-- old head of the branch
+ \
+ o--o--o <-- new head of the branch
+................................................
+
+In this case, "git fetch" will fail, and print out a warning.
+
+In that case, you can still force git to update to the new head, as
+described in the following section. However, note that in the
+situation above this may mean losing the commits labeled "a" and "b",
+unless you've already created a reference of your own pointing to
+them.
+
+[[forcing-fetch]]
+Forcing git fetch to do non-fast-forward updates
+------------------------------------------------
+
+If git fetch fails because the new head of a branch is not a
+descendant of the old head, you may force the update with:
+
+-------------------------------------------------
+$ git fetch git://example.com/proj.git +master:refs/remotes/example/master
+-------------------------------------------------
+
+Note the addition of the "+" sign. Alternatively, you can use the "-f"
+flag to force updates of all the fetched branches, as in:
+
+-------------------------------------------------
+$ git fetch -f origin
+-------------------------------------------------
+
+Be aware that commits that the old version of example/master pointed at
+may be lost, as we saw in the previous section.
+
+[[remote-branch-configuration]]
+Configuring remote branches
+---------------------------
+
+We saw above that "origin" is just a shortcut to refer to the
+repository that you originally cloned from. This information is
+stored in git configuration variables, which you can see using
+linkgit:git-config[1]:
+
+-------------------------------------------------
+$ git config -l
+core.repositoryformatversion=0
+core.filemode=true
+core.logallrefupdates=true
+remote.origin.url=git://git.kernel.org/pub/scm/git/git.git
+remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
+branch.master.remote=origin
+branch.master.merge=refs/heads/master
+-------------------------------------------------
+
+If there are other repositories that you also use frequently, you can
+create similar configuration options to save typing; for example,
+after
+
+-------------------------------------------------
+$ git config remote.example.url git://example.com/proj.git
+-------------------------------------------------
+
+then the following two commands will do the same thing:
+
+-------------------------------------------------
+$ git fetch git://example.com/proj.git master:refs/remotes/example/master
+$ git fetch example master:refs/remotes/example/master
+-------------------------------------------------
+
+Even better, if you add one more option:
+
+-------------------------------------------------
+$ git config remote.example.fetch master:refs/remotes/example/master
+-------------------------------------------------
+
+then the following commands will all do the same thing:
+
+-------------------------------------------------
+$ git fetch git://example.com/proj.git master:refs/remotes/example/master
+$ git fetch example master:refs/remotes/example/master
+$ git fetch example
+-------------------------------------------------
+
+You can also add a "+" to force the update each time:
+
+-------------------------------------------------
+$ git config remote.example.fetch +master:ref/remotes/example/master
+-------------------------------------------------
+
+Don't do this unless you're sure you won't mind "git fetch" possibly
+throwing away commits on mybranch.
+
+Also note that all of the above configuration can be performed by
+directly editing the file .git/config instead of using
+linkgit:git-config[1].
+
+See linkgit:git-config[1] for more details on the configuration
+options mentioned above.
+
+
+[[git-concepts]]
+Git concepts
+============
+
+Git is built on a small number of simple but powerful ideas. While it
+is possible to get things done without understanding them, you will find
+git much more intuitive if you do.
+
+We start with the most important, the <<def_object_database,object
+database>> and the <<def_index,index>>.
+
+[[the-object-database]]
+The Object Database
+-------------------
+
+
+We already saw in <<understanding-commits>> that all commits are stored
+under a 40-digit "object name". In fact, all the information needed to
+represent the history of a project is stored in objects with such names.
+In each case the name is calculated by taking the SHA1 hash of the
+contents of the object. The SHA1 hash is a cryptographic hash function.
+What that means to us is that it is impossible to find two different
+objects with the same name. This has a number of advantages; among
+others:
+
+- Git can quickly determine whether two objects are identical or not,
+ just by comparing names.
+- Since object names are computed the same way in every repository, the
+ same content stored in two repositories will always be stored under
+ the same name.
+- Git can detect errors when it reads an object, by checking that the
+ object's name is still the SHA1 hash of its contents.
+
+(See <<object-details>> for the details of the object formatting and
+SHA1 calculation.)
+
+There are four different types of objects: "blob", "tree", "commit", and
+"tag".
+
+- A <<def_blob_object,"blob" object>> is used to store file data.
+- A <<def_tree_object,"tree" object>> is an object that ties one or more
+ "blob" objects into a directory structure. In addition, a tree object
+ can refer to other tree objects, thus creating a directory hierarchy.
+- A <<def_commit_object,"commit" object>> ties such directory hierarchies
+ together into a <<def_DAG,directed acyclic graph>> of revisions--each
+ commit contains the object name of exactly one tree designating the
+ directory hierarchy at the time of the commit. In addition, a commit
+ refers to "parent" commit objects that describe the history of how we
+ arrived at that directory hierarchy.
+- A <<def_tag_object,"tag" object>> symbolically identifies and can be
+ used to sign other objects. It contains the object name and type of
+ another object, a symbolic name (of course!) and, optionally, a
+ signature.
+
+The object types in some more detail:
+
+[[commit-object]]
+Commit Object
+~~~~~~~~~~~~~
+
+The "commit" object links a physical state of a tree with a description
+of how we got there and why. Use the --pretty=raw option to
+linkgit:git-show[1] or linkgit:git-log[1] to examine your favorite
+commit:
+
+------------------------------------------------
+$ git show -s --pretty=raw 2be7fcb476
+commit 2be7fcb4764f2dbcee52635b91fedb1b3dcf7ab4
+tree fb3a8bdd0ceddd019615af4d57a53f43d8cee2bf
+parent 257a84d9d02e90447b149af58b271c19405edb6a
+author Dave Watson <dwatson@mimvista.com> 1187576872 -0400
+committer Junio C Hamano <gitster@pobox.com> 1187591163 -0700
+
+ Fix misspelling of 'suppress' in docs
+
+ Signed-off-by: Junio C Hamano <gitster@pobox.com>
+------------------------------------------------
+
+As you can see, a commit is defined by:
+
+- a tree: The SHA1 name of a tree object (as defined below), representing
+ the contents of a directory at a certain point in time.
+- parent(s): The SHA1 name of some number of commits which represent the
+ immediately previous step(s) in the history of the project. The
+ example above has one parent; merge commits may have more than
+ one. A commit with no parents is called a "root" commit, and
+ represents the initial revision of a project. Each project must have
+ at least one root. A project can also have multiple roots, though
+ that isn't common (or necessarily a good idea).
+- an author: The name of the person responsible for this change, together
+ with its date.
+- a committer: The name of the person who actually created the commit,
+ with the date it was done. This may be different from the author, for
+ example, if the author was someone who wrote a patch and emailed it
+ to the person who used it to create the commit.
+- a comment describing this commit.
+
+Note that a commit does not itself contain any information about what
+actually changed; all changes are calculated by comparing the contents
+of the tree referred to by this commit with the trees associated with
+its parents. In particular, git does not attempt to record file renames
+explicitly, though it can identify cases where the existence of the same
+file data at changing paths suggests a rename. (See, for example, the
+-M option to linkgit:git-diff[1]).
+
+A commit is usually created by linkgit:git-commit[1], which creates a
+commit whose parent is normally the current HEAD, and whose tree is
+taken from the content currently stored in the index.
+
+[[tree-object]]
+Tree Object
+~~~~~~~~~~~
+
+The ever-versatile linkgit:git-show[1] command can also be used to
+examine tree objects, but linkgit:git-ls-tree[1] will give you more
+details:
+
+------------------------------------------------
+$ git ls-tree fb3a8bdd0ce
+100644 blob 63c918c667fa005ff12ad89437f2fdc80926e21c .gitignore
+100644 blob 5529b198e8d14decbe4ad99db3f7fb632de0439d .mailmap
+100644 blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3 COPYING
+040000 tree 2fb783e477100ce076f6bf57e4a6f026013dc745 Documentation
+100755 blob 3c0032cec592a765692234f1cba47dfdcc3a9200 GIT-VERSION-GEN
+100644 blob 289b046a443c0647624607d471289b2c7dcd470b INSTALL
+100644 blob 4eb463797adc693dc168b926b6932ff53f17d0b1 Makefile
+100644 blob 548142c327a6790ff8821d67c2ee1eff7a656b52 README
+...
+------------------------------------------------
+
+As you can see, a tree object contains a list of entries, each with a
+mode, object type, SHA1 name, and name, sorted by name. It represents
+the contents of a single directory tree.
+
+The object type may be a blob, representing the contents of a file, or
+another tree, representing the contents of a subdirectory. Since trees
+and blobs, like all other objects, are named by the SHA1 hash of their
+contents, two trees have the same SHA1 name if and only if their
+contents (including, recursively, the contents of all subdirectories)
+are identical. This allows git to quickly determine the differences
+between two related tree objects, since it can ignore any entries with
+identical object names.
+
+(Note: in the presence of submodules, trees may also have commits as
+entries. See <<submodules>> for documentation.)
+
+Note that the files all have mode 644 or 755: git actually only pays
+attention to the executable bit.
+
+[[blob-object]]
+Blob Object
+~~~~~~~~~~~
+
+You can use linkgit:git-show[1] to examine the contents of a blob; take,
+for example, the blob in the entry for "COPYING" from the tree above:
+
+------------------------------------------------
+$ git show 6ff87c4664
+
+ Note that the only valid version of the GPL as far as this project
+ is concerned is _this_ particular version of the license (ie v2, not
+ v2.2 or v3.x or whatever), unless explicitly otherwise stated.
+...
+------------------------------------------------
+
+A "blob" object is nothing but a binary blob of data. It doesn't refer
+to anything else or have attributes of any kind.
+
+Since the blob is entirely defined by its data, if two files in a
+directory tree (or in multiple different versions of the repository)
+have the same contents, they will share the same blob object. The object
+is totally independent of its location in the directory tree, and
+renaming a file does not change the object that file is associated with.
+
+Note that any tree or blob object can be examined using
+linkgit:git-show[1] with the <revision>:<path> syntax. This can
+sometimes be useful for browsing the contents of a tree that is not
+currently checked out.
+
+[[trust]]
+Trust
+~~~~~
+
+If you receive the SHA1 name of a blob from one source, and its contents
+from another (possibly untrusted) source, you can still trust that those
+contents are correct as long as the SHA1 name agrees. This is because
+the SHA1 is designed so that it is infeasible to find different contents
+that produce the same hash.
+
+Similarly, you need only trust the SHA1 name of a top-level tree object
+to trust the contents of the entire directory that it refers to, and if
+you receive the SHA1 name of a commit from a trusted source, then you
+can easily verify the entire history of commits reachable through
+parents of that commit, and all of those contents of the trees referred
+to by those commits.
+
+So to introduce some real trust in the system, the only thing you need
+to do is to digitally sign just 'one' special note, which includes the
+name of a top-level commit. Your digital signature shows others
+that you trust that commit, and the immutability of the history of
+commits tells others that they can trust the whole history.
+
+In other words, you can easily validate a whole archive by just
+sending out a single email that tells the people the name (SHA1 hash)
+of the top commit, and digitally sign that email using something
+like GPG/PGP.
+
+To assist in this, git also provides the tag object...
+
+[[tag-object]]
+Tag Object
+~~~~~~~~~~
+
+A tag object contains an object, object type, tag name, the name of the
+person ("tagger") who created the tag, and a message, which may contain
+a signature, as can be seen using the linkgit:git-cat-file[1]:
+
+------------------------------------------------
+$ git cat-file tag v1.5.0
+object 437b1b20df4b356c9342dac8d38849f24ef44f27
+type commit
+tag v1.5.0
+tagger Junio C Hamano <junkio@cox.net> 1171411200 +0000
+
+GIT 1.5.0
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.6 (GNU/Linux)
+
+iD8DBQBF0lGqwMbZpPMRm5oRAuRiAJ9ohBLd7s2kqjkKlq1qqC57SbnmzQCdG4ui
+nLE/L9aUXdWeTFPron96DLA=
+=2E+0
+-----END PGP SIGNATURE-----
+------------------------------------------------
+
+See the linkgit:git-tag[1] command to learn how to create and verify tag
+objects. (Note that linkgit:git-tag[1] can also be used to create
+"lightweight tags", which are not tag objects at all, but just simple
+references whose names begin with "refs/tags/").
+
+[[pack-files]]
+How git stores objects efficiently: pack files
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Newly created objects are initially created in a file named after the
+object's SHA1 hash (stored in .git/objects).
+
+Unfortunately this system becomes inefficient once a project has a
+lot of objects. Try this on an old project:
+
+------------------------------------------------
+$ git count-objects
+6930 objects, 47620 kilobytes
+------------------------------------------------
+
+The first number is the number of objects which are kept in
+individual files. The second is the amount of space taken up by
+those "loose" objects.
+
+You can save space and make git faster by moving these loose objects in
+to a "pack file", which stores a group of objects in an efficient
+compressed format; the details of how pack files are formatted can be
+found in link:technical/pack-format.txt[technical/pack-format.txt].
+
+To put the loose objects into a pack, just run git repack:
+
+------------------------------------------------
+$ git repack
+Generating pack...
+Done counting 6020 objects.
+Deltifying 6020 objects.
+ 100% (6020/6020) done
+Writing 6020 objects.
+ 100% (6020/6020) done
+Total 6020, written 6020 (delta 4070), reused 0 (delta 0)
+Pack pack-3e54ad29d5b2e05838c75df582c65257b8d08e1c created.
+------------------------------------------------
+
+You can then run
+
+------------------------------------------------
+$ git prune
+------------------------------------------------
+
+to remove any of the "loose" objects that are now contained in the
+pack. This will also remove any unreferenced objects (which may be
+created when, for example, you use "git reset" to remove a commit).
+You can verify that the loose objects are gone by looking at the
+.git/objects directory or by running
+
+------------------------------------------------
+$ git count-objects
+0 objects, 0 kilobytes
+------------------------------------------------
+
+Although the object files are gone, any commands that refer to those
+objects will work exactly as they did before.
+
+The linkgit:git-gc[1] command performs packing, pruning, and more for
+you, so is normally the only high-level command you need.
+
+[[dangling-objects]]
+Dangling objects
+~~~~~~~~~~~~~~~~
+
+The linkgit:git-fsck[1] command will sometimes complain about dangling
+objects. They are not a problem.
+
+The most common cause of dangling objects is that you've rebased a
+branch, or you have pulled from somebody else who rebased a branch--see
+<<cleaning-up-history>>. In that case, the old head of the original
+branch still exists, as does everything it pointed to. The branch
+pointer itself just doesn't, since you replaced it with another one.
+
+There are also other situations that cause dangling objects. For
+example, a "dangling blob" may arise because you did a "git add" of a
+file, but then, before you actually committed it and made it part of the
+bigger picture, you changed something else in that file and committed
+that *updated* thing--the old state that you added originally ends up
+not being pointed to by any commit or tree, so it's now a dangling blob
+object.
+
+Similarly, when the "recursive" merge strategy runs, and finds that
+there are criss-cross merges and thus more than one merge base (which is
+fairly unusual, but it does happen), it will generate one temporary
+midway tree (or possibly even more, if you had lots of criss-crossing
+merges and more than two merge bases) as a temporary internal merge
+base, and again, those are real objects, but the end result will not end
+up pointing to them, so they end up "dangling" in your repository.
+
+Generally, dangling objects aren't anything to worry about. They can
+even be very useful: if you screw something up, the dangling objects can
+be how you recover your old tree (say, you did a rebase, and realized
+that you really didn't want to--you can look at what dangling objects
+you have, and decide to reset your head to some old dangling state).
+
+For commits, you can just use:
+
+------------------------------------------------
+$ gitk <dangling-commit-sha-goes-here> --not --all
+------------------------------------------------
+
+This asks for all the history reachable from the given commit but not
+from any branch, tag, or other reference. If you decide it's something
+you want, you can always create a new reference to it, e.g.,
+
+------------------------------------------------
+$ git branch recovered-branch <dangling-commit-sha-goes-here>
+------------------------------------------------
+
+For blobs and trees, you can't do the same, but you can still examine
+them. You can just do
+
+------------------------------------------------
+$ git show <dangling-blob/tree-sha-goes-here>
+------------------------------------------------
+
+to show what the contents of the blob were (or, for a tree, basically
+what the "ls" for that directory was), and that may give you some idea
+of what the operation was that left that dangling object.
+
+Usually, dangling blobs and trees aren't very interesting. They're
+almost always the result of either being a half-way mergebase (the blob
+will often even have the conflict markers from a merge in it, if you
+have had conflicting merges that you fixed up by hand), or simply
+because you interrupted a "git fetch" with ^C or something like that,
+leaving _some_ of the new objects in the object database, but just
+dangling and useless.
+
+Anyway, once you are sure that you're not interested in any dangling
+state, you can just prune all unreachable objects:
+
+------------------------------------------------
+$ git prune
+------------------------------------------------
+
+and they'll be gone. But you should only run "git prune" on a quiescent
+repository--it's kind of like doing a filesystem fsck recovery: you
+don't want to do that while the filesystem is mounted.
+
+(The same is true of "git-fsck" itself, btw, but since
+git-fsck never actually *changes* the repository, it just reports
+on what it found, git-fsck itself is never "dangerous" to run.
+Running it while somebody is actually changing the repository can cause
+confusing and scary messages, but it won't actually do anything bad. In
+contrast, running "git prune" while somebody is actively changing the
+repository is a *BAD* idea).
+
+[[recovering-from-repository-corruption]]
+Recovering from repository corruption
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+By design, git treats data trusted to it with caution. However, even in
+the absence of bugs in git itself, it is still possible that hardware or
+operating system errors could corrupt data.
+
+The first defense against such problems is backups. You can back up a
+git directory using clone, or just using cp, tar, or any other backup
+mechanism.
+
+As a last resort, you can search for the corrupted objects and attempt
+to replace them by hand. Back up your repository before attempting this
+in case you corrupt things even more in the process.
+
+We'll assume that the problem is a single missing or corrupted blob,
+which is sometimes a solvable problem. (Recovering missing trees and
+especially commits is *much* harder).
+
+Before starting, verify that there is corruption, and figure out where
+it is with linkgit:git-fsck[1]; this may be time-consuming.
+
+Assume the output looks like this:
+
+------------------------------------------------
+$ git-fsck --full
+broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
+ to blob 4b9458b3786228369c63936db65827de3cc06200
+missing blob 4b9458b3786228369c63936db65827de3cc06200
+------------------------------------------------
+
+(Typically there will be some "dangling object" messages too, but they
+aren't interesting.)
+
+Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6
+points to it. If you could find just one copy of that missing blob
+object, possibly in some other repository, you could move it into
+.git/objects/4b/9458b3... and be done. Suppose you can't. You can
+still examine the tree that pointed to it with linkgit:git-ls-tree[1],
+which might output something like:
+
+------------------------------------------------
+$ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
+100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8 .gitignore
+100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883 .mailmap
+100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c COPYING
+...
+100644 blob 4b9458b3786228369c63936db65827de3cc06200 myfile
+...
+------------------------------------------------
+
+So now you know that the missing blob was the data for a file named
+"myfile". And chances are you can also identify the directory--let's
+say it's in "somedirectory". If you're lucky the missing copy might be
+the same as the copy you have checked out in your working tree at
+"somedirectory/myfile"; you can test whether that's right with
+linkgit:git-hash-object[1]:
+
+------------------------------------------------
+$ git hash-object -w somedirectory/myfile
+------------------------------------------------
+
+which will create and store a blob object with the contents of
+somedirectory/myfile, and output the sha1 of that object. if you're
+extremely lucky it might be 4b9458b3786228369c63936db65827de3cc06200, in
+which case you've guessed right, and the corruption is fixed!
+
+Otherwise, you need more information. How do you tell which version of
+the file has been lost?
+
+The easiest way to do this is with:
+
+------------------------------------------------
+$ git log --raw --all --full-history -- somedirectory/myfile
+------------------------------------------------
+
+Because you're asking for raw output, you'll now get something like
+
+------------------------------------------------
+commit abc
+Author:
+Date:
+...
+:100644 100644 4b9458b... newsha... M somedirectory/myfile
+
+
+commit xyz
+Author:
+Date:
+
+...
+:100644 100644 oldsha... 4b9458b... M somedirectory/myfile
+------------------------------------------------
+
+This tells you that the immediately preceding version of the file was
+"newsha", and that the immediately following version was "oldsha".
+You also know the commit messages that went with the change from oldsha
+to 4b9458b and with the change from 4b9458b to newsha.
+
+If you've been committing small enough changes, you may now have a good
+shot at reconstructing the contents of the in-between state 4b9458b.
+
+If you can do that, you can now recreate the missing object with
+
+------------------------------------------------
+$ git hash-object -w <recreated-file>
+------------------------------------------------
+
+and your repository is good again!
+
+(Btw, you could have ignored the fsck, and started with doing a
+
+------------------------------------------------
+$ git log --raw --all
+------------------------------------------------
+
+and just looked for the sha of the missing object (4b9458b..) in that
+whole thing. It's up to you - git does *have* a lot of information, it is
+just missing one particular blob version.
+
+[[the-index]]
+The index
+-----------
+
+The index is a binary file (generally kept in .git/index) containing a
+sorted list of path names, each with permissions and the SHA1 of a blob
+object; linkgit:git-ls-files[1] can show you the contents of the index:
+
+-------------------------------------------------
+$ git ls-files --stage
+100644 63c918c667fa005ff12ad89437f2fdc80926e21c 0 .gitignore
+100644 5529b198e8d14decbe4ad99db3f7fb632de0439d 0 .mailmap
+100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0 COPYING
+100644 a37b2152bd26be2c2289e1f57a292534a51a93c7 0 Documentation/.gitignore
+100644 fbefe9a45b00a54b58d94d06eca48b03d40a50e0 0 Documentation/Makefile
+...
+100644 2511aef8d89ab52be5ec6a5e46236b4b6bcd07ea 0 xdiff/xtypes.h
+100644 2ade97b2574a9f77e7ae4002a4e07a6a38e46d07 0 xdiff/xutils.c
+100644 d5de8292e05e7c36c4b68857c1cf9855e3d2f70a 0 xdiff/xutils.h
+-------------------------------------------------
+
+Note that in older documentation you may see the index called the
+"current directory cache" or just the "cache". It has three important
+properties:
+
+1. The index contains all the information necessary to generate a single
+(uniquely determined) tree object.
++
+For example, running linkgit:git-commit[1] generates this tree object
+from the index, stores it in the object database, and uses it as the
+tree object associated with the new commit.
+
+2. The index enables fast comparisons between the tree object it defines
+and the working tree.
++
+It does this by storing some additional data for each entry (such as
+the last modified time). This data is not displayed above, and is not
+stored in the created tree object, but it can be used to determine
+quickly which files in the working directory differ from what was
+stored in the index, and thus save git from having to read all of the
+data from such files to look for changes.
+
+3. It can efficiently represent information about merge conflicts
+between different tree objects, allowing each pathname to be
+associated with sufficient information about the trees involved that
+you can create a three-way merge between them.
++
+We saw in <<conflict-resolution>> that during a merge the index can
+store multiple versions of a single file (called "stages"). The third
+column in the linkgit:git-ls-files[1] output above is the stage
+number, and will take on values other than 0 for files with merge
+conflicts.
+
+The index is thus a sort of temporary staging area, which is filled with
+a tree which you are in the process of working on.
+
+If you blow the index away entirely, you generally haven't lost any
+information as long as you have the name of the tree that it described.
+
+[[submodules]]
+Submodules
+==========
+
+Large projects are often composed of smaller, self-contained modules. For
+example, an embedded Linux distribution's source tree would include every
+piece of software in the distribution with some local modifications; a movie
+player might need to build against a specific, known-working version of a
+decompression library; several independent programs might all share the same
+build scripts.
+
+With centralized revision control systems this is often accomplished by
+including every module in one single repository. Developers can check out
+all modules or only the modules they need to work with. They can even modify
+files across several modules in a single commit while moving things around
+or updating APIs and translations.
+
+Git does not allow partial checkouts, so duplicating this approach in Git
+would force developers to keep a local copy of modules they are not
+interested in touching. Commits in an enormous checkout would be slower
+than you'd expect as Git would have to scan every directory for changes.
+If modules have a lot of local history, clones would take forever.
+
+On the plus side, distributed revision control systems can much better
+integrate with external sources. In a centralized model, a single arbitrary
+snapshot of the external project is exported from its own revision control
+and then imported into the local revision control on a vendor branch. All
+the history is hidden. With distributed revision control you can clone the
+entire external history and much more easily follow development and re-merge
+local changes.
+
+Git's submodule support allows a repository to contain, as a subdirectory, a
+checkout of an external project. Submodules maintain their own identity;
+the submodule support just stores the submodule repository location and
+commit ID, so other developers who clone the containing project
+("superproject") can easily clone all the submodules at the same revision.
+Partial checkouts of the superproject are possible: you can tell Git to
+clone none, some or all of the submodules.
+
+The linkgit:git-submodule[1] command is available since Git 1.5.3. Users
+with Git 1.5.2 can look up the submodule commits in the repository and
+manually check them out; earlier versions won't recognize the submodules at
+all.
+
+To see how submodule support works, create (for example) four example
+repositories that can be used later as a submodule:
+
+-------------------------------------------------
+$ mkdir ~/git
+$ cd ~/git
+$ for i in a b c d
+do
+ mkdir $i
+ cd $i
+ git init
+ echo "module $i" > $i.txt
+ git add $i.txt
+ git commit -m "Initial commit, submodule $i"
+ cd ..
+done
+-------------------------------------------------
+
+Now create the superproject and add all the submodules:
+
+-------------------------------------------------
+$ mkdir super
+$ cd super
+$ git init
+$ for i in a b c d
+do
+ git submodule add ~/git/$i
+done
+-------------------------------------------------
+
+NOTE: Do not use local URLs here if you plan to publish your superproject!
+
+See what files `git submodule` created:
+
+-------------------------------------------------
+$ ls -a
+. .. .git .gitmodules a b c d
+-------------------------------------------------
+
+The `git submodule add` command does a couple of things:
+
+- It clones the submodule under the current directory and by default checks out
+ the master branch.
+- It adds the submodule's clone path to the linkgit:gitmodules[5] file and
+ adds this file to the index, ready to be committed.
+- It adds the submodule's current commit ID to the index, ready to be
+ committed.
+
+Commit the superproject:
+
+-------------------------------------------------
+$ git commit -m "Add submodules a, b, c and d."
+-------------------------------------------------
+
+Now clone the superproject:
+
+-------------------------------------------------
+$ cd ..
+$ git clone super cloned
+$ cd cloned
+-------------------------------------------------
+
+The submodule directories are there, but they're empty:
+
+-------------------------------------------------
+$ ls -a a
+. ..
+$ git submodule status
+-d266b9873ad50488163457f025db7cdd9683d88b a
+-e81d457da15309b4fef4249aba9b50187999670d b
+-c1536a972b9affea0f16e0680ba87332dc059146 c
+-d96249ff5d57de5de093e6baff9e0aafa5276a74 d
+-------------------------------------------------
+
+NOTE: The commit object names shown above would be different for you, but they
+should match the HEAD commit object names of your repositories. You can check
+it by running `git ls-remote ../a`.
+
+Pulling down the submodules is a two-step process. First run `git submodule
+init` to add the submodule repository URLs to `.git/config`:
+
+-------------------------------------------------
+$ git submodule init
+-------------------------------------------------
+
+Now use `git submodule update` to clone the repositories and check out the
+commits specified in the superproject:
+
+-------------------------------------------------
+$ git submodule update
+$ cd a
+$ ls -a
+. .. .git a.txt
+-------------------------------------------------
+
+One major difference between `git submodule update` and `git submodule add` is
+that `git submodule update` checks out a specific commit, rather than the tip
+of a branch. It's like checking out a tag: the head is detached, so you're not
+working on a branch.
+
+-------------------------------------------------
+$ git branch
+* (no branch)
+ master
+-------------------------------------------------
+
+If you want to make a change within a submodule and you have a detached head,
+then you should create or checkout a branch, make your changes, publish the
+change within the submodule, and then update the superproject to reference the
+new commit:
+
+-------------------------------------------------
+$ git checkout master
+-------------------------------------------------
+
+or
+
+-------------------------------------------------
+$ git checkout -b fix-up
+-------------------------------------------------
+
+then
+
+-------------------------------------------------
+$ echo "adding a line again" >> a.txt
+$ git commit -a -m "Updated the submodule from within the superproject."
+$ git push
+$ cd ..
+$ git diff
+diff --git a/a b/a
+index d266b98..261dfac 160000
+--- a/a
++++ b/a
+@@ -1 +1 @@
+-Subproject commit d266b9873ad50488163457f025db7cdd9683d88b
++Subproject commit 261dfac35cb99d380eb966e102c1197139f7fa24
+$ git add a
+$ git commit -m "Updated submodule a."
+$ git push
+-------------------------------------------------
+
+You have to run `git submodule update` after `git pull` if you want to update
+submodules, too.
+
+Pitfalls with submodules
+------------------------
+
+Always publish the submodule change before publishing the change to the
+superproject that references it. If you forget to publish the submodule change,
+others won't be able to clone the repository:
+
+-------------------------------------------------
+$ cd ~/git/super/a
+$ echo i added another line to this file >> a.txt
+$ git commit -a -m "doing it wrong this time"
+$ cd ..
+$ git add a
+$ git commit -m "Updated submodule a again."
+$ git push
+$ cd ~/git/cloned
+$ git pull
+$ git submodule update
+error: pathspec '261dfac35cb99d380eb966e102c1197139f7fa24' did not match any file(s) known to git.
+Did you forget to 'git add'?
+Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path 'a'
+-------------------------------------------------
+
+You also should not rewind branches in a submodule beyond commits that were
+ever recorded in any superproject.
+
+It's not safe to run `git submodule update` if you've made and committed
+changes within a submodule without checking out a branch first. They will be
+silently overwritten:
+
+-------------------------------------------------
+$ cat a.txt
+module a
+$ echo line added from private2 >> a.txt
+$ git commit -a -m "line added inside private2"
+$ cd ..
+$ git submodule update
+Submodule path 'a': checked out 'd266b9873ad50488163457f025db7cdd9683d88b'
+$ cd a
+$ cat a.txt
+module a
+-------------------------------------------------
+
+NOTE: The changes are still visible in the submodule's reflog.
+
+This is not the case if you did not commit your changes.
+
+[[low-level-operations]]
+Low-level git operations
+========================
+
+Many of the higher-level commands were originally implemented as shell
+scripts using a smaller core of low-level git commands. These can still
+be useful when doing unusual things with git, or just as a way to
+understand its inner workings.
+
+[[object-manipulation]]
+Object access and manipulation
+------------------------------
+
+The linkgit:git-cat-file[1] command can show the contents of any object,
+though the higher-level linkgit:git-show[1] is usually more useful.
+
+The linkgit:git-commit-tree[1] command allows constructing commits with
+arbitrary parents and trees.
+
+A tree can be created with linkgit:git-write-tree[1] and its data can be
+accessed by linkgit:git-ls-tree[1]. Two trees can be compared with
+linkgit:git-diff-tree[1].
+
+A tag is created with linkgit:git-mktag[1], and the signature can be
+verified by linkgit:git-verify-tag[1], though it is normally simpler to
+use linkgit:git-tag[1] for both.
+
+[[the-workflow]]
+The Workflow
+------------
+
+High-level operations such as linkgit:git-commit[1],
+linkgit:git-checkout[1] and linkgit:git-reset[1] work by moving data
+between the working tree, the index, and the object database. Git
+provides low-level operations which perform each of these steps
+individually.
+
+Generally, all "git" operations work on the index file. Some operations
+work *purely* on the index file (showing the current state of the
+index), but most operations move data between the index file and either
+the database or the working directory. Thus there are four main
+combinations:
+
+[[working-directory-to-index]]
+working directory -> index
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The linkgit:git-update-index[1] command updates the index with
+information from the working directory. You generally update the
+index information by just specifying the filename you want to update,
+like so:
+
+-------------------------------------------------
+$ git update-index filename
+-------------------------------------------------
+
+but to avoid common mistakes with filename globbing etc, the command
+will not normally add totally new entries or remove old entries,
+i.e. it will normally just update existing cache entries.
+
+To tell git that yes, you really do realize that certain files no
+longer exist, or that new files should be added, you
+should use the `--remove` and `--add` flags respectively.
+
+NOTE! A `--remove` flag does 'not' mean that subsequent filenames will
+necessarily be removed: if the files still exist in your directory
+structure, the index will be updated with their new status, not
+removed. The only thing `--remove` means is that update-index will be
+considering a removed file to be a valid thing, and if the file really
+does not exist any more, it will update the index accordingly.
+
+As a special case, you can also do `git-update-index --refresh`, which
+will refresh the "stat" information of each index to match the current
+stat information. It will 'not' update the object status itself, and
+it will only update the fields that are used to quickly test whether
+an object still matches its old backing store object.
+
+The previously introduced linkgit:git-add[1] is just a wrapper for
+linkgit:git-update-index[1].
+
+[[index-to-object-database]]
+index -> object database
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+You write your current index file to a "tree" object with the program
+
+-------------------------------------------------
+$ git write-tree
+-------------------------------------------------
+
+that doesn't come with any options--it will just write out the
+current index into the set of tree objects that describe that state,
+and it will return the name of the resulting top-level tree. You can
+use that tree to re-generate the index at any time by going in the
+other direction:
+
+[[object-database-to-index]]
+object database -> index
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+You read a "tree" file from the object database, and use that to
+populate (and overwrite--don't do this if your index contains any
+unsaved state that you might want to restore later!) your current
+index. Normal operation is just
+
+-------------------------------------------------
+$ git-read-tree <sha1 of tree>
+-------------------------------------------------
+
+and your index file will now be equivalent to the tree that you saved
+earlier. However, that is only your 'index' file: your working
+directory contents have not been modified.
+
+[[index-to-working-directory]]
+index -> working directory
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You update your working directory from the index by "checking out"
+files. This is not a very common operation, since normally you'd just
+keep your files updated, and rather than write to your working
+directory, you'd tell the index files about the changes in your
+working directory (i.e. `git-update-index`).
+
+However, if you decide to jump to a new version, or check out somebody
+else's version, or just restore a previous tree, you'd populate your
+index file with read-tree, and then you need to check out the result
+with
+
+-------------------------------------------------
+$ git-checkout-index filename
+-------------------------------------------------
+
+or, if you want to check out all of the index, use `-a`.
+
+NOTE! git-checkout-index normally refuses to overwrite old files, so
+if you have an old version of the tree already checked out, you will
+need to use the "-f" flag ('before' the "-a" flag or the filename) to
+'force' the checkout.
+
+
+Finally, there are a few odds and ends which are not purely moving
+from one representation to the other:
+
+[[tying-it-all-together]]
+Tying it all together
+~~~~~~~~~~~~~~~~~~~~~
+
+To commit a tree you have instantiated with "git-write-tree", you'd
+create a "commit" object that refers to that tree and the history
+behind it--most notably the "parent" commits that preceded it in
+history.
+
+Normally a "commit" has one parent: the previous state of the tree
+before a certain change was made. However, sometimes it can have two
+or more parent commits, in which case we call it a "merge", due to the
+fact that such a commit brings together ("merges") two or more
+previous states represented by other commits.
+
+In other words, while a "tree" represents a particular directory state
+of a working directory, a "commit" represents that state in "time",
+and explains how we got there.
+
+You create a commit object by giving it the tree that describes the
+state at the time of the commit, and a list of parents:
+
+-------------------------------------------------
+$ git-commit-tree <tree> -p <parent> [-p <parent2> ..]
+-------------------------------------------------
+
+and then giving the reason for the commit on stdin (either through
+redirection from a pipe or file, or by just typing it at the tty).
+
+git-commit-tree will return the name of the object that represents
+that commit, and you should save it away for later use. Normally,
+you'd commit a new `HEAD` state, and while git doesn't care where you
+save the note about that state, in practice we tend to just write the
+result to the file pointed at by `.git/HEAD`, so that we can always see
+what the last committed state was.
+
+Here is an ASCII art by Jon Loeliger that illustrates how
+various pieces fit together.
+
+------------
+
+ commit-tree
+ commit obj
+ +----+
+ | |
+ | |
+ V V
+ +-----------+
+ | Object DB |
+ | Backing |
+ | Store |
+ +-----------+
+ ^
+ write-tree | |
+ tree obj | |
+ | | read-tree
+ | | tree obj
+ V
+ +-----------+
+ | Index |
+ | "cache" |
+ +-----------+
+ update-index ^
+ blob obj | |
+ | |
+ checkout-index -u | | checkout-index
+ stat | | blob obj
+ V
+ +-----------+
+ | Working |
+ | Directory |
+ +-----------+
+
+------------
+
+
+[[examining-the-data]]
+Examining the data
+------------------
+
+You can examine the data represented in the object database and the
+index with various helper tools. For every object, you can use
+linkgit:git-cat-file[1] to examine details about the
+object:
+
+-------------------------------------------------
+$ git-cat-file -t <objectname>
+-------------------------------------------------
+
+shows the type of the object, and once you have the type (which is
+usually implicit in where you find the object), you can use
+
+-------------------------------------------------
+$ git-cat-file blob|tree|commit|tag <objectname>
+-------------------------------------------------
+
+to show its contents. NOTE! Trees have binary content, and as a result
+there is a special helper for showing that content, called
+`git-ls-tree`, which turns the binary content into a more easily
+readable form.
+
+It's especially instructive to look at "commit" objects, since those
+tend to be small and fairly self-explanatory. In particular, if you
+follow the convention of having the top commit name in `.git/HEAD`,
+you can do
+
+-------------------------------------------------
+$ git-cat-file commit HEAD
+-------------------------------------------------
+
+to see what the top commit was.
+
+[[merging-multiple-trees]]
+Merging multiple trees
+----------------------
+
+Git helps you do a three-way merge, which you can expand to n-way by
+repeating the merge procedure arbitrary times until you finally
+"commit" the state. The normal situation is that you'd only do one
+three-way merge (two parents), and commit it, but if you like to, you
+can do multiple parents in one go.
+
+To do a three-way merge, you need the two sets of "commit" objects
+that you want to merge, use those to find the closest common parent (a
+third "commit" object), and then use those commit objects to find the
+state of the directory ("tree" object) at these points.
+
+To get the "base" for the merge, you first look up the common parent
+of two commits with
+
+-------------------------------------------------
+$ git-merge-base <commit1> <commit2>
+-------------------------------------------------
+
+which will return you the commit they are both based on. You should
+now look up the "tree" objects of those commits, which you can easily
+do with (for example)
+
+-------------------------------------------------
+$ git-cat-file commit <commitname> | head -1
+-------------------------------------------------
+
+since the tree object information is always the first line in a commit
+object.
+
+Once you know the three trees you are going to merge (the one "original"
+tree, aka the common tree, and the two "result" trees, aka the branches
+you want to merge), you do a "merge" read into the index. This will
+complain if it has to throw away your old index contents, so you should
+make sure that you've committed those--in fact you would normally
+always do a merge against your last commit (which should thus match what
+you have in your current index anyway).
+
+To do the merge, do
+
+-------------------------------------------------
+$ git-read-tree -m -u <origtree> <yourtree> <targettree>
+-------------------------------------------------
+
+which will do all trivial merge operations for you directly in the
+index file, and you can just write the result out with
+`git-write-tree`.
+
+
+[[merging-multiple-trees-2]]
+Merging multiple trees, continued
+---------------------------------
+
+Sadly, many merges aren't trivial. If there are files that have
+been added, moved or removed, or if both branches have modified the
+same file, you will be left with an index tree that contains "merge
+entries" in it. Such an index tree can 'NOT' be written out to a tree
+object, and you will have to resolve any such merge clashes using
+other tools before you can write out the result.
+
+You can examine such index state with `git-ls-files --unmerged`
+command. An example:
+
+------------------------------------------------
+$ git-read-tree -m $orig HEAD $target
+$ git-ls-files --unmerged
+100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello.c
+100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello.c
+100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c
+------------------------------------------------
+
+Each line of the `git-ls-files --unmerged` output begins with
+the blob mode bits, blob SHA1, 'stage number', and the
+filename. The 'stage number' is git's way to say which tree it
+came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD`
+tree, and stage3 `$target` tree.
+
+Earlier we said that trivial merges are done inside
+`git-read-tree -m`. For example, if the file did not change
+from `$orig` to `HEAD` nor `$target`, or if the file changed
+from `$orig` to `HEAD` and `$orig` to `$target` the same way,
+obviously the final outcome is what is in `HEAD`. What the
+above example shows is that file `hello.c` was changed from
+`$orig` to `HEAD` and `$orig` to `$target` in a different way.
+You could resolve this by running your favorite 3-way merge
+program, e.g. `diff3`, `merge`, or git's own merge-file, on
+the blob objects from these three stages yourself, like this:
+
+------------------------------------------------
+$ git-cat-file blob 263414f... >hello.c~1
+$ git-cat-file blob 06fa6a2... >hello.c~2
+$ git-cat-file blob cc44c73... >hello.c~3
+$ git merge-file hello.c~2 hello.c~1 hello.c~3
+------------------------------------------------
+
+This would leave the merge result in `hello.c~2` file, along
+with conflict markers if there are conflicts. After verifying
+the merge result makes sense, you can tell git what the final
+merge result for this file is by:
+
+-------------------------------------------------
+$ mv -f hello.c~2 hello.c
+$ git-update-index hello.c
+-------------------------------------------------
+
+When a path is in unmerged state, running `git-update-index` for
+that path tells git to mark the path resolved.
+
+The above is the description of a git merge at the lowest level,
+to help you understand what conceptually happens under the hood.
+In practice, nobody, not even git itself, uses three `git-cat-file`
+for this. There is `git-merge-index` program that extracts the
+stages to temporary files and calls a "merge" script on it:
+
+-------------------------------------------------
+$ git-merge-index git-merge-one-file hello.c
+-------------------------------------------------
+
+and that is what higher level `git merge -s resolve` is implemented with.
+
+[[hacking-git]]
+Hacking git
+===========
+
+This chapter covers internal details of the git implementation which
+probably only git developers need to understand.
+
+[[object-details]]
+Object storage format
+---------------------
+
+All objects have a statically determined "type" which identifies the
+format of the object (i.e. how it is used, and how it can refer to other
+objects). There are currently four different object types: "blob",
+"tree", "commit", and "tag".
+
+Regardless of object type, all objects share the following
+characteristics: they are all deflated with zlib, and have a header
+that not only specifies their type, but also provides size information
+about the data in the object. It's worth noting that the SHA1 hash
+that is used to name the object is the hash of the original data
+plus this header, so `sha1sum` 'file' does not match the object name
+for 'file'.
+(Historical note: in the dawn of the age of git the hash
+was the sha1 of the 'compressed' object.)
+
+As a result, the general consistency of an object can always be tested
+independently of the contents or the type of the object: all objects can
+be validated by verifying that (a) their hashes match the content of the
+file and (b) the object successfully inflates to a stream of bytes that
+forms a sequence of <ascii type without space> {plus} <space> {plus} <ascii decimal
+size> {plus} <byte\0> {plus} <binary object data>.
+
+The structured objects can further have their structure and
+connectivity to other objects verified. This is generally done with
+the `git-fsck` program, which generates a full dependency graph
+of all objects, and verifies their internal consistency (in addition
+to just verifying their superficial consistency through the hash).
+
+[[birdview-on-the-source-code]]
+A birds-eye view of Git's source code
+-------------------------------------
+
+It is not always easy for new developers to find their way through Git's
+source code. This section gives you a little guidance to show where to
+start.
+
+A good place to start is with the contents of the initial commit, with:
+
+----------------------------------------------------
+$ git checkout e83c5163
+----------------------------------------------------
+
+The initial revision lays the foundation for almost everything git has
+today, but is small enough to read in one sitting.
+
+Note that terminology has changed since that revision. For example, the
+README in that revision uses the word "changeset" to describe what we
+now call a <<def_commit_object,commit>>.
+
+Also, we do not call it "cache" any more, but "index", however, the
+file is still called `cache.h`. Remark: Not much reason to change it now,
+especially since there is no good single name for it anyway, because it is
+basically _the_ header file which is included by _all_ of Git's C sources.
+
+If you grasp the ideas in that initial commit, you should check out a
+more recent version and skim `cache.h`, `object.h` and `commit.h`.
+
+In the early days, Git (in the tradition of UNIX) was a bunch of programs
+which were extremely simple, and which you used in scripts, piping the
+output of one into another. This turned out to be good for initial
+development, since it was easier to test new things. However, recently
+many of these parts have become builtins, and some of the core has been
+"libified", i.e. put into libgit.a for performance, portability reasons,
+and to avoid code duplication.
+
+By now, you know what the index is (and find the corresponding data
+structures in `cache.h`), and that there are just a couple of object types
+(blobs, trees, commits and tags) which inherit their common structure from
+`struct object`, which is their first member (and thus, you can cast e.g.
+`(struct object *)commit` to achieve the _same_ as `&commit->object`, i.e.
+get at the object name and flags).
+
+Now is a good point to take a break to let this information sink in.
+
+Next step: get familiar with the object naming. Read <<naming-commits>>.
+There are quite a few ways to name an object (and not only revisions!).
+All of these are handled in `sha1_name.c`. Just have a quick look at
+the function `get_sha1()`. A lot of the special handling is done by
+functions like `get_sha1_basic()` or the likes.
+
+This is just to get you into the groove for the most libified part of Git:
+the revision walker.
+
+Basically, the initial version of `git log` was a shell script:
+
+----------------------------------------------------------------
+$ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \
+ LESS=-S ${PAGER:-less}
+----------------------------------------------------------------
+
+What does this mean?
+
+`git-rev-list` is the original version of the revision walker, which
+_always_ printed a list of revisions to stdout. It is still functional,
+and needs to, since most new Git programs start out as scripts using
+`git-rev-list`.
+
+`git-rev-parse` is not as important any more; it was only used to filter out
+options that were relevant for the different plumbing commands that were
+called by the script.
+
+Most of what `git-rev-list` did is contained in `revision.c` and
+`revision.h`. It wraps the options in a struct named `rev_info`, which
+controls how and what revisions are walked, and more.
+
+The original job of `git-rev-parse` is now taken by the function
+`setup_revisions()`, which parses the revisions and the common command line
+options for the revision walker. This information is stored in the struct
+`rev_info` for later consumption. You can do your own command line option
+parsing after calling `setup_revisions()`. After that, you have to call
+`prepare_revision_walk()` for initialization, and then you can get the
+commits one by one with the function `get_revision()`.
+
+If you are interested in more details of the revision walking process,
+just have a look at the first implementation of `cmd_log()`; call
+`git-show v1.3.0{tilde}155^2{tilde}4` and scroll down to that function (note that you
+no longer need to call `setup_pager()` directly).
+
+Nowadays, `git log` is a builtin, which means that it is _contained_ in the
+command `git`. The source side of a builtin is
+
+- a function called `cmd_<bla>`, typically defined in `builtin-<bla>.c`,
+ and declared in `builtin.h`,
+
+- an entry in the `commands[]` array in `git.c`, and
+
+- an entry in `BUILTIN_OBJECTS` in the `Makefile`.
+
+Sometimes, more than one builtin is contained in one source file. For
+example, `cmd_whatchanged()` and `cmd_log()` both reside in `builtin-log.c`,
+since they share quite a bit of code. In that case, the commands which are
+_not_ named like the `.c` file in which they live have to be listed in
+`BUILT_INS` in the `Makefile`.
+
+`git log` looks more complicated in C than it does in the original script,
+but that allows for a much greater flexibility and performance.
+
+Here again it is a good point to take a pause.
+
+Lesson three is: study the code. Really, it is the best way to learn about
+the organization of Git (after you know the basic concepts).
+
+So, think about something which you are interested in, say, "how can I
+access a blob just knowing the object name of it?". The first step is to
+find a Git command with which you can do it. In this example, it is either
+`git show` or `git cat-file`.
+
+For the sake of clarity, let's stay with `git cat-file`, because it
+
+- is plumbing, and
+
+- was around even in the initial commit (it literally went only through
+ some 20 revisions as `cat-file.c`, was renamed to `builtin-cat-file.c`
+ when made a builtin, and then saw less than 10 versions).
+
+So, look into `builtin-cat-file.c`, search for `cmd_cat_file()` and look what
+it does.
+
+------------------------------------------------------------------
+ git_config(git_default_config);
+ if (argc != 3)
+ usage("git-cat-file [-t|-s|-e|-p|<type>] <sha1>");
+ if (get_sha1(argv[2], sha1))
+ die("Not a valid object name %s", argv[2]);
+------------------------------------------------------------------
+
+Let's skip over the obvious details; the only really interesting part
+here is the call to `get_sha1()`. It tries to interpret `argv[2]` as an
+object name, and if it refers to an object which is present in the current
+repository, it writes the resulting SHA-1 into the variable `sha1`.
+
+Two things are interesting here:
+
+- `get_sha1()` returns 0 on _success_. This might surprise some new
+ Git hackers, but there is a long tradition in UNIX to return different
+ negative numbers in case of different errors--and 0 on success.
+
+- the variable `sha1` in the function signature of `get_sha1()` is `unsigned
+ char \*`, but is actually expected to be a pointer to `unsigned
+ char[20]`. This variable will contain the 160-bit SHA-1 of the given
+ commit. Note that whenever a SHA-1 is passed as `unsigned char \*`, it
+ is the binary representation, as opposed to the ASCII representation in
+ hex characters, which is passed as `char *`.
+
+You will see both of these things throughout the code.
+
+Now, for the meat:
+
+-----------------------------------------------------------------------------
+ case 0:
+ buf = read_object_with_reference(sha1, argv[1], &size, NULL);
+-----------------------------------------------------------------------------
+
+This is how you read a blob (actually, not only a blob, but any type of
+object). To know how the function `read_object_with_reference()` actually
+works, find the source code for it (something like `git grep
+read_object_with | grep ":[a-z]"` in the git repository), and read
+the source.
+
+To find out how the result can be used, just read on in `cmd_cat_file()`:
+
+-----------------------------------
+ write_or_die(1, buf, size);
+-----------------------------------
+
+Sometimes, you do not know where to look for a feature. In many such cases,
+it helps to search through the output of `git log`, and then `git show` the
+corresponding commit.
+
+Example: If you know that there was some test case for `git bundle`, but
+do not remember where it was (yes, you _could_ `git grep bundle t/`, but that
+does not illustrate the point!):
+
+------------------------
+$ git log --no-merges t/
+------------------------
+
+In the pager (`less`), just search for "bundle", go a few lines back,
+and see that it is in commit 18449ab0... Now just copy this object name,
+and paste it into the command line
+
+-------------------
+$ git show 18449ab0
+-------------------
+
+Voila.
+
+Another example: Find out what to do in order to make some script a
+builtin:
+
+-------------------------------------------------
+$ git log --no-merges --diff-filter=A builtin-*.c
+-------------------------------------------------
+
+You see, Git is actually the best tool to find out about the source of Git
+itself!
+
+[[glossary]]
+GIT Glossary
+============
+
+include::glossary-content.txt[]
+
+[[git-quick-start]]
+Appendix A: Git Quick Reference
+===============================
+
+This is a quick summary of the major commands; the previous chapters
+explain how these work in more detail.
+
+[[quick-creating-a-new-repository]]
+Creating a new repository
+-------------------------
+
+From a tarball:
+
+-----------------------------------------------
+$ tar xzf project.tar.gz
+$ cd project
+$ git init
+Initialized empty Git repository in .git/
+$ git add .
+$ git commit
+-----------------------------------------------
+
+From a remote repository:
+
+-----------------------------------------------
+$ git clone git://example.com/pub/project.git
+$ cd project
+-----------------------------------------------
+
+[[managing-branches]]
+Managing branches
+-----------------
+
+-----------------------------------------------
+$ git branch # list all local branches in this repo
+$ git checkout test # switch working directory to branch "test"
+$ git branch new # create branch "new" starting at current HEAD
+$ git branch -d new # delete branch "new"
+-----------------------------------------------
+
+Instead of basing a new branch on current HEAD (the default), use:
+
+-----------------------------------------------
+$ git branch new test # branch named "test"
+$ git branch new v2.6.15 # tag named v2.6.15
+$ git branch new HEAD^ # commit before the most recent
+$ git branch new HEAD^^ # commit before that
+$ git branch new test~10 # ten commits before tip of branch "test"
+-----------------------------------------------
+
+Create and switch to a new branch at the same time:
+
+-----------------------------------------------
+$ git checkout -b new v2.6.15
+-----------------------------------------------
+
+Update and examine branches from the repository you cloned from:
+
+-----------------------------------------------
+$ git fetch # update
+$ git branch -r # list
+ origin/master
+ origin/next
+ ...
+$ git checkout -b masterwork origin/master
+-----------------------------------------------
+
+Fetch a branch from a different repository, and give it a new
+name in your repository:
+
+-----------------------------------------------
+$ git fetch git://example.com/project.git theirbranch:mybranch
+$ git fetch git://example.com/project.git v2.6.15:mybranch
+-----------------------------------------------
+
+Keep a list of repositories you work with regularly:
+
+-----------------------------------------------
+$ git remote add example git://example.com/project.git
+$ git remote # list remote repositories
+example
+origin
+$ git remote show example # get details
+* remote example
+ URL: git://example.com/project.git
+ Tracked remote branches
+ master next ...
+$ git fetch example # update branches from example
+$ git branch -r # list all remote branches
+-----------------------------------------------
+
+
+[[exploring-history]]
+Exploring history
+-----------------
+
+-----------------------------------------------
+$ gitk # visualize and browse history
+$ git log # list all commits
+$ git log src/ # ...modifying src/
+$ git log v2.6.15..v2.6.16 # ...in v2.6.16, not in v2.6.15
+$ git log master..test # ...in branch test, not in branch master
+$ git log test..master # ...in branch master, but not in test
+$ git log test...master # ...in one branch, not in both
+$ git log -S'foo()' # ...where difference contain "foo()"
+$ git log --since="2 weeks ago"
+$ git log -p # show patches as well
+$ git show # most recent commit
+$ git diff v2.6.15..v2.6.16 # diff between two tagged versions
+$ git diff v2.6.15..HEAD # diff with current head
+$ git grep "foo()" # search working directory for "foo()"
+$ git grep v2.6.15 "foo()" # search old tree for "foo()"
+$ git show v2.6.15:a.txt # look at old version of a.txt
+-----------------------------------------------
+
+Search for regressions:
+
+-----------------------------------------------
+$ git bisect start
+$ git bisect bad # current version is bad
+$ git bisect good v2.6.13-rc2 # last known good revision
+Bisecting: 675 revisions left to test after this
+ # test here, then:
+$ git bisect good # if this revision is good, or
+$ git bisect bad # if this revision is bad.
+ # repeat until done.
+-----------------------------------------------
+
+[[making-changes]]
+Making changes
+--------------
+
+Make sure git knows who to blame:
+
+------------------------------------------------
+$ cat >>~/.gitconfig <<\EOF
+[user]
+ name = Your Name Comes Here
+ email = you@yourdomain.example.com
+EOF
+------------------------------------------------
+
+Select file contents to include in the next commit, then make the
+commit:
+
+-----------------------------------------------
+$ git add a.txt # updated file
+$ git add b.txt # new file
+$ git rm c.txt # old file
+$ git commit
+-----------------------------------------------
+
+Or, prepare and create the commit in one step:
+
+-----------------------------------------------
+$ git commit d.txt # use latest content only of d.txt
+$ git commit -a # use latest content of all tracked files
+-----------------------------------------------
+
+[[merging]]
+Merging
+-------
+
+-----------------------------------------------
+$ git merge test # merge branch "test" into the current branch
+$ git pull git://example.com/project.git master
+ # fetch and merge in remote branch
+$ git pull . test # equivalent to git merge test
+-----------------------------------------------
+
+[[sharing-your-changes]]
+Sharing your changes
+--------------------
+
+Importing or exporting patches:
+
+-----------------------------------------------
+$ git format-patch origin..HEAD # format a patch for each commit
+ # in HEAD but not in origin
+$ git am mbox # import patches from the mailbox "mbox"
+-----------------------------------------------
+
+Fetch a branch in a different git repository, then merge into the
+current branch:
+
+-----------------------------------------------
+$ git pull git://example.com/project.git theirbranch
+-----------------------------------------------
+
+Store the fetched branch into a local branch before merging into the
+current branch:
+
+-----------------------------------------------
+$ git pull git://example.com/project.git theirbranch:mybranch
+-----------------------------------------------
+
+After creating commits on a local branch, update the remote
+branch with your commits:
+
+-----------------------------------------------
+$ git push ssh://example.com/project.git mybranch:theirbranch
+-----------------------------------------------
+
+When remote and local branch are both named "test":
+
+-----------------------------------------------
+$ git push ssh://example.com/project.git test
+-----------------------------------------------
+
+Shortcut version for a frequently used remote repository:
+
+-----------------------------------------------
+$ git remote add example ssh://example.com/project.git
+$ git push example test
+-----------------------------------------------
+
+[[repository-maintenance]]
+Repository maintenance
+----------------------
+
+Check for corruption:
+
+-----------------------------------------------
+$ git fsck
+-----------------------------------------------
+
+Recompress, remove unused cruft:
+
+-----------------------------------------------
+$ git gc
+-----------------------------------------------
+
+
+[[todo]]
+Appendix B: Notes and todo list for this manual
+===============================================
+
+This is a work in progress.
+
+The basic requirements:
+
+- It must be readable in order, from beginning to end, by someone
+ intelligent with a basic grasp of the UNIX command line, but without
+ any special knowledge of git. If necessary, any other prerequisites
+ should be specifically mentioned as they arise.
+- Whenever possible, section headings should clearly describe the task
+ they explain how to do, in language that requires no more knowledge
+ than necessary: for example, "importing patches into a project" rather
+ than "the git-am command"
+
+Think about how to create a clear chapter dependency graph that will
+allow people to get to important topics without necessarily reading
+everything in between.
+
+Scan Documentation/ for other stuff left out; in particular:
+
+- howto's
+- some of technical/?
+- hooks
+- list of commands in linkgit:git[1]
+
+Scan email archives for other stuff left out
+
+Scan man pages to see if any assume more background than this manual
+provides.
+
+Simplify beginning by suggesting disconnected head instead of
+temporary branch creation?
+
+Add more good examples. Entire sections of just cookbook examples
+might be a good idea; maybe make an "advanced examples" section a
+standard end-of-chapter section?
+
+Include cross-references to the glossary, where appropriate.
+
+Document shallow clones? See draft 1.5.0 release notes for some
+documentation.
+
+Add a section on working with other version control systems, including
+CVS, Subversion, and just imports of series of release tarballs.
+
+More details on gitweb?
+
+Write a chapter on using plumbing and writing scripts.
+
+Alternates, clone -reference, etc.
+
+More on recovery from repository corruption. See:
+ http://marc.theaimsgroup.com/?l=git&m=117263864820799&w=2
+ http://marc.theaimsgroup.com/?l=git&m=117147855503798&w=2
+ http://marc.theaimsgroup.com/?l=git&m=117147855503798&w=2