Merge branch 'master' of git://repo.or.cz/git-gui
authorJunio C Hamano <junkio@cox.net>
Mon, 7 May 2007 21:47:14 +0000 (14:47 -0700)
committerJunio C Hamano <junkio@cox.net>
Mon, 7 May 2007 21:47:14 +0000 (14:47 -0700)
* 'master' of git://repo.or.cz/git-gui:
  git-gui: Correctly handle UTF-8 encoded commit messages

952 files changed:
.gitignore
.mailmap [new file with mode: 0644]
COPYING [new file with mode: 0644]
Documentation/.gitignore [new file with mode: 0644]
Documentation/Makefile [new file with mode: 0644]
Documentation/RelNotes-1.5.0.1.txt [new file with mode: 0644]
Documentation/RelNotes-1.5.0.2.txt [new file with mode: 0644]
Documentation/RelNotes-1.5.0.3.txt [new file with mode: 0644]
Documentation/RelNotes-1.5.0.4.txt [new file with mode: 0644]
Documentation/RelNotes-1.5.0.5.txt [new file with mode: 0644]
Documentation/RelNotes-1.5.0.6.txt [new file with mode: 0644]
Documentation/RelNotes-1.5.0.7.txt [new file with mode: 0644]
Documentation/RelNotes-1.5.0.txt [new file with mode: 0644]
Documentation/RelNotes-1.5.1.1.txt [new file with mode: 0644]
Documentation/RelNotes-1.5.1.2.txt [new file with mode: 0644]
Documentation/RelNotes-1.5.1.3.txt [new file with mode: 0644]
Documentation/RelNotes-1.5.1.txt [new file with mode: 0644]
Documentation/RelNotes-1.5.2.txt [new file with mode: 0644]
Documentation/SubmittingPatches [new file with mode: 0644]
Documentation/asciidoc.conf [new file with mode: 0644]
Documentation/blame-options.txt [new file with mode: 0644]
Documentation/build-docdep.perl [new file with mode: 0755]
Documentation/callouts.xsl [new file with mode: 0644]
Documentation/cmd-list.perl [new file with mode: 0755]
Documentation/config.txt [new file with mode: 0644]
Documentation/core-intro.txt [new file with mode: 0644]
Documentation/core-tutorial.txt [new file with mode: 0644]
Documentation/cvs-migration.txt [new file with mode: 0644]
Documentation/diff-format.txt [new file with mode: 0644]
Documentation/diff-options.txt [new file with mode: 0644]
Documentation/diffcore.txt [new file with mode: 0644]
Documentation/docbook-xsl.css [new file with mode: 0644]
Documentation/everyday.txt [new file with mode: 0644]
Documentation/fetch-options.txt [new file with mode: 0644]
Documentation/git-add.txt [new file with mode: 0644]
Documentation/git-am.txt [new file with mode: 0644]
Documentation/git-annotate.txt [new file with mode: 0644]
Documentation/git-apply.txt [new file with mode: 0644]
Documentation/git-applymbox.txt [new file with mode: 0644]
Documentation/git-applypatch.txt [new file with mode: 0644]
Documentation/git-archimport.txt [new file with mode: 0644]
Documentation/git-archive.txt [new file with mode: 0644]
Documentation/git-bisect.txt [new file with mode: 0644]
Documentation/git-blame.txt [new file with mode: 0644]
Documentation/git-branch.txt [new file with mode: 0644]
Documentation/git-bundle.txt [new file with mode: 0644]
Documentation/git-cat-file.txt [new file with mode: 0644]
Documentation/git-check-attr.txt [new file with mode: 0644]
Documentation/git-check-ref-format.txt [new file with mode: 0644]
Documentation/git-checkout-index.txt [new file with mode: 0644]
Documentation/git-checkout.txt [new file with mode: 0644]
Documentation/git-cherry-pick.txt [new file with mode: 0644]
Documentation/git-cherry.txt [new file with mode: 0644]
Documentation/git-clean.txt [new file with mode: 0644]
Documentation/git-clone.txt [new file with mode: 0644]
Documentation/git-commit-tree.txt [new file with mode: 0644]
Documentation/git-commit.txt [new file with mode: 0644]
Documentation/git-config.txt [new file with mode: 0644]
Documentation/git-convert-objects.txt [new file with mode: 0644]
Documentation/git-count-objects.txt [new file with mode: 0644]
Documentation/git-cvsexportcommit.txt [new file with mode: 0644]
Documentation/git-cvsimport.txt [new file with mode: 0644]
Documentation/git-cvsserver.txt [new file with mode: 0644]
Documentation/git-daemon.txt [new file with mode: 0644]
Documentation/git-describe.txt [new file with mode: 0644]
Documentation/git-diff-files.txt [new file with mode: 0644]
Documentation/git-diff-index.txt [new file with mode: 0644]
Documentation/git-diff-tree.txt [new file with mode: 0644]
Documentation/git-diff.txt [new file with mode: 0644]
Documentation/git-fast-import.txt [new file with mode: 0644]
Documentation/git-fetch-pack.txt [new file with mode: 0644]
Documentation/git-fetch.txt [new file with mode: 0644]
Documentation/git-fmt-merge-msg.txt [new file with mode: 0644]
Documentation/git-for-each-ref.txt [new file with mode: 0644]
Documentation/git-format-patch.txt [new file with mode: 0644]
Documentation/git-fsck-objects.txt [new file with mode: 0644]
Documentation/git-fsck.txt [new file with mode: 0644]
Documentation/git-gc.txt [new file with mode: 0644]
Documentation/git-get-tar-commit-id.txt [new file with mode: 0644]
Documentation/git-grep.txt [new file with mode: 0644]
Documentation/git-hash-object.txt [new file with mode: 0644]
Documentation/git-http-fetch.txt [new file with mode: 0644]
Documentation/git-http-push.txt [new file with mode: 0644]
Documentation/git-imap-send.txt [new file with mode: 0644]
Documentation/git-index-pack.txt [new file with mode: 0644]
Documentation/git-init-db.txt [new file with mode: 0644]
Documentation/git-init.txt [new file with mode: 0644]
Documentation/git-instaweb.txt [new file with mode: 0644]
Documentation/git-local-fetch.txt [new file with mode: 0644]
Documentation/git-log.txt [new file with mode: 0644]
Documentation/git-lost-found.txt [new file with mode: 0644]
Documentation/git-ls-files.txt [new file with mode: 0644]
Documentation/git-ls-remote.txt [new file with mode: 0644]
Documentation/git-ls-tree.txt [new file with mode: 0644]
Documentation/git-mailinfo.txt [new file with mode: 0644]
Documentation/git-mailsplit.txt [new file with mode: 0644]
Documentation/git-merge-base.txt [new file with mode: 0644]
Documentation/git-merge-file.txt [new file with mode: 0644]
Documentation/git-merge-index.txt [new file with mode: 0644]
Documentation/git-merge-one-file.txt [new file with mode: 0644]
Documentation/git-merge-tree.txt [new file with mode: 0644]
Documentation/git-merge.txt [new file with mode: 0644]
Documentation/git-mergetool.txt [new file with mode: 0644]
Documentation/git-mktag.txt [new file with mode: 0644]
Documentation/git-mktree.txt [new file with mode: 0644]
Documentation/git-mv.txt [new file with mode: 0644]
Documentation/git-name-rev.txt [new file with mode: 0644]
Documentation/git-p4import.txt [new file with mode: 0644]
Documentation/git-pack-objects.txt [new file with mode: 0644]
Documentation/git-pack-redundant.txt [new file with mode: 0644]
Documentation/git-pack-refs.txt [new file with mode: 0644]
Documentation/git-parse-remote.txt [new file with mode: 0644]
Documentation/git-patch-id.txt [new file with mode: 0644]
Documentation/git-peek-remote.txt [new file with mode: 0644]
Documentation/git-prune-packed.txt [new file with mode: 0644]
Documentation/git-prune.txt [new file with mode: 0644]
Documentation/git-pull.txt [new file with mode: 0644]
Documentation/git-push.txt [new file with mode: 0644]
Documentation/git-quiltimport.txt [new file with mode: 0644]
Documentation/git-read-tree.txt [new file with mode: 0644]
Documentation/git-rebase.txt [new file with mode: 0644]
Documentation/git-receive-pack.txt [new file with mode: 0644]
Documentation/git-reflog.txt [new file with mode: 0644]
Documentation/git-relink.txt [new file with mode: 0644]
Documentation/git-remote.txt [new file with mode: 0644]
Documentation/git-repack.txt [new file with mode: 0644]
Documentation/git-repo-config.txt [new file with mode: 0644]
Documentation/git-request-pull.txt [new file with mode: 0644]
Documentation/git-rerere.txt [new file with mode: 0644]
Documentation/git-reset.txt [new file with mode: 0644]
Documentation/git-rev-list.txt [new file with mode: 0644]
Documentation/git-rev-parse.txt [new file with mode: 0644]
Documentation/git-revert.txt [new file with mode: 0644]
Documentation/git-rm.txt [new file with mode: 0644]
Documentation/git-runstatus.txt [new file with mode: 0644]
Documentation/git-send-email.txt [new file with mode: 0644]
Documentation/git-send-pack.txt [new file with mode: 0644]
Documentation/git-sh-setup.txt [new file with mode: 0644]
Documentation/git-shell.txt [new file with mode: 0644]
Documentation/git-shortlog.txt [new file with mode: 0644]
Documentation/git-show-branch.txt [new file with mode: 0644]
Documentation/git-show-index.txt [new file with mode: 0644]
Documentation/git-show-ref.txt [new file with mode: 0644]
Documentation/git-show.txt [new file with mode: 0644]
Documentation/git-ssh-fetch.txt [new file with mode: 0644]
Documentation/git-ssh-upload.txt [new file with mode: 0644]
Documentation/git-status.txt [new file with mode: 0644]
Documentation/git-stripspace.txt [new file with mode: 0644]
Documentation/git-svn.txt [new file with mode: 0644]
Documentation/git-svnimport.txt [new file with mode: 0644]
Documentation/git-symbolic-ref.txt [new file with mode: 0644]
Documentation/git-tag.txt [new file with mode: 0644]
Documentation/git-tar-tree.txt [new file with mode: 0644]
Documentation/git-tools.txt [new file with mode: 0644]
Documentation/git-unpack-file.txt [new file with mode: 0644]
Documentation/git-unpack-objects.txt [new file with mode: 0644]
Documentation/git-update-index.txt [new file with mode: 0644]
Documentation/git-update-ref.txt [new file with mode: 0644]
Documentation/git-update-server-info.txt [new file with mode: 0644]
Documentation/git-upload-archive.txt [new file with mode: 0644]
Documentation/git-upload-pack.txt [new file with mode: 0644]
Documentation/git-var.txt [new file with mode: 0644]
Documentation/git-verify-pack.txt [new file with mode: 0644]
Documentation/git-verify-tag.txt [new file with mode: 0644]
Documentation/git-whatchanged.txt [new file with mode: 0644]
Documentation/git-write-tree.txt [new file with mode: 0644]
Documentation/git.txt [new file with mode: 0644]
Documentation/gitattributes.txt [new file with mode: 0644]
Documentation/gitk.txt [new file with mode: 0644]
Documentation/glossary.txt [new file with mode: 0644]
Documentation/hooks.txt [new file with mode: 0644]
Documentation/howto-index.sh [new file with mode: 0755]
Documentation/howto/dangling-objects.txt [new file with mode: 0644]
Documentation/howto/isolate-bugs-with-bisect.txt [new file with mode: 0644]
Documentation/howto/make-dist.txt [new file with mode: 0644]
Documentation/howto/rebase-and-edit.txt [new file with mode: 0644]
Documentation/howto/rebase-from-internal-branch.txt [new file with mode: 0644]
Documentation/howto/rebuild-from-update-hook.txt [new file with mode: 0644]
Documentation/howto/revert-branch-rebase.txt [new file with mode: 0644]
Documentation/howto/separating-topic-branches.txt [new file with mode: 0644]
Documentation/howto/setup-git-server-over-http.txt [new file with mode: 0644]
Documentation/howto/update-hook-example.txt [new file with mode: 0644]
Documentation/howto/use-git-daemon.txt [new file with mode: 0644]
Documentation/howto/using-topic-branches.txt [new file with mode: 0644]
Documentation/i18n.txt [new file with mode: 0644]
Documentation/install-doc-quick.sh [new file with mode: 0755]
Documentation/install-webdoc.sh [new file with mode: 0755]
Documentation/merge-options.txt [new file with mode: 0644]
Documentation/merge-strategies.txt [new file with mode: 0644]
Documentation/pretty-formats.txt [new file with mode: 0644]
Documentation/pull-fetch-param.txt [new file with mode: 0644]
Documentation/repository-layout.txt [new file with mode: 0644]
Documentation/technical/pack-format.txt [new file with mode: 0644]
Documentation/technical/pack-heuristics.txt [new file with mode: 0644]
Documentation/technical/pack-protocol.txt [new file with mode: 0644]
Documentation/technical/racy-git.txt [new file with mode: 0644]
Documentation/technical/send-pack-pipeline.txt [new file with mode: 0644]
Documentation/technical/shallow.txt [new file with mode: 0644]
Documentation/technical/trivial-merge.txt [new file with mode: 0644]
Documentation/tutorial-2.txt [new file with mode: 0644]
Documentation/tutorial.txt [new file with mode: 0644]
Documentation/urls.txt [new file with mode: 0644]
Documentation/user-manual.conf [new file with mode: 0644]
Documentation/user-manual.txt [new file with mode: 0644]
GIT-VERSION-GEN
INSTALL [new file with mode: 0644]
Makefile
README [new file with mode: 0644]
RelNotes [new symlink]
alloc.c [new file with mode: 0644]
archive-tar.c [new file with mode: 0644]
archive-zip.c [new file with mode: 0644]
archive.h [new file with mode: 0644]
arm/sha1.c [new file with mode: 0644]
arm/sha1.h [new file with mode: 0644]
arm/sha1_arm.S [new file with mode: 0644]
attr.c [new file with mode: 0644]
attr.h [new file with mode: 0644]
base85.c [new file with mode: 0644]
blob.c [new file with mode: 0644]
blob.h [new file with mode: 0644]
builtin-add.c [new file with mode: 0644]
builtin-annotate.c [new file with mode: 0644]
builtin-apply.c [new file with mode: 0644]
builtin-archive.c [new file with mode: 0644]
builtin-blame.c [new file with mode: 0644]
builtin-branch.c [new file with mode: 0644]
builtin-bundle.c [new file with mode: 0644]
builtin-cat-file.c [new file with mode: 0644]
builtin-check-attr.c [new file with mode: 0644]
builtin-check-ref-format.c [new file with mode: 0644]
builtin-checkout-index.c [new file with mode: 0644]
builtin-commit-tree.c [new file with mode: 0644]
builtin-config.c [new file with mode: 0644]
builtin-count-objects.c [new file with mode: 0644]
builtin-describe.c [new file with mode: 0644]
builtin-diff-files.c [new file with mode: 0644]
builtin-diff-index.c [new file with mode: 0644]
builtin-diff-tree.c [new file with mode: 0644]
builtin-diff.c [new file with mode: 0644]
builtin-fetch--tool.c [new file with mode: 0644]
builtin-fmt-merge-msg.c [new file with mode: 0644]
builtin-for-each-ref.c [new file with mode: 0644]
builtin-fsck.c [new file with mode: 0644]
builtin-gc.c [new file with mode: 0644]
builtin-grep.c [new file with mode: 0644]
builtin-init-db.c [new file with mode: 0644]
builtin-log.c [new file with mode: 0644]
builtin-ls-files.c [new file with mode: 0644]
builtin-ls-tree.c [new file with mode: 0644]
builtin-mailinfo.c [new file with mode: 0644]
builtin-mailsplit.c [new file with mode: 0644]
builtin-merge-base.c [new file with mode: 0644]
builtin-merge-file.c [new file with mode: 0644]
builtin-mv.c [new file with mode: 0644]
builtin-name-rev.c [new file with mode: 0644]
builtin-pack-objects.c [new file with mode: 0644]
builtin-pack-refs.c [new file with mode: 0644]
builtin-prune-packed.c [new file with mode: 0644]
builtin-prune.c [new file with mode: 0644]
builtin-push.c [new file with mode: 0644]
builtin-read-tree.c [new file with mode: 0644]
builtin-reflog.c [new file with mode: 0644]
builtin-rerere.c [new file with mode: 0644]
builtin-rev-list.c [new file with mode: 0644]
builtin-rev-parse.c [new file with mode: 0644]
builtin-revert.c [new file with mode: 0644]
builtin-rm.c [new file with mode: 0644]
builtin-runstatus.c [new file with mode: 0644]
builtin-shortlog.c [new file with mode: 0644]
builtin-show-branch.c [new file with mode: 0644]
builtin-show-ref.c [new file with mode: 0644]
builtin-stripspace.c [new file with mode: 0644]
builtin-symbolic-ref.c [new file with mode: 0644]
builtin-tar-tree.c [new file with mode: 0644]
builtin-unpack-objects.c [new file with mode: 0644]
builtin-update-index.c [new file with mode: 0644]
builtin-update-ref.c [new file with mode: 0644]
builtin-upload-archive.c [new file with mode: 0644]
builtin-verify-pack.c [new file with mode: 0644]
builtin-write-tree.c [new file with mode: 0644]
builtin.h [new file with mode: 0644]
cache-tree.c [new file with mode: 0644]
cache-tree.h [new file with mode: 0644]
cache.h [new file with mode: 0644]
check-builtins.sh [new file with mode: 0755]
check-racy.c [new file with mode: 0644]
color.c [new file with mode: 0644]
color.h [new file with mode: 0644]
combine-diff.c [new file with mode: 0644]
commit.c [new file with mode: 0644]
commit.h [new file with mode: 0644]
compat/inet_ntop.c [new file with mode: 0644]
compat/inet_pton.c [new file with mode: 0644]
compat/mmap.c [new file with mode: 0644]
compat/pread.c [new file with mode: 0644]
compat/setenv.c [new file with mode: 0644]
compat/strcasestr.c [new file with mode: 0644]
compat/strlcpy.c [new file with mode: 0644]
compat/strtoumax.c [new file with mode: 0644]
compat/unsetenv.c [new file with mode: 0644]
config.c [new file with mode: 0644]
config.mak.in [new file with mode: 0644]
configure.ac [new file with mode: 0644]
connect.c [new file with mode: 0644]
contrib/README [new file with mode: 0644]
contrib/blameview/README [new file with mode: 0644]
contrib/blameview/blameview.perl [new file with mode: 0755]
contrib/completion/git-completion.bash [new file with mode: 0755]
contrib/continuous/cidaemon [new file with mode: 0644]
contrib/continuous/post-receive-cinotify [new file with mode: 0644]
contrib/emacs/.gitignore [new file with mode: 0644]
contrib/emacs/Makefile [new file with mode: 0644]
contrib/emacs/git-blame.el [new file with mode: 0644]
contrib/emacs/git.el [new file with mode: 0644]
contrib/emacs/vc-git.el [new file with mode: 0644]
contrib/examples/git-gc.sh [new file with mode: 0755]
contrib/examples/git-resolve.sh [new file with mode: 0755]
contrib/fast-import/import-tars.perl [new file with mode: 0755]
contrib/gitview/gitview [new file with mode: 0755]
contrib/gitview/gitview.txt [new file with mode: 0644]
contrib/hg-to-git/hg-to-git.py [new file with mode: 0755]
contrib/hg-to-git/hg-to-git.txt [new file with mode: 0644]
contrib/hooks/post-receive-email [new file with mode: 0644]
contrib/hooks/update-paranoid [new file with mode: 0644]
contrib/remotes2config.sh [new file with mode: 0644]
contrib/vim/README [new file with mode: 0644]
contrib/vim/syntax/gitcommit.vim [new file with mode: 0644]
contrib/workdir/git-new-workdir [new file with mode: 0755]
convert-objects.c [new file with mode: 0644]
convert.c [new file with mode: 0644]
copy.c [new file with mode: 0644]
csum-file.c [new file with mode: 0644]
csum-file.h [new file with mode: 0644]
ctype.c [new file with mode: 0644]
daemon.c [new file with mode: 0644]
date.c [new file with mode: 0644]
decorate.c [new file with mode: 0644]
decorate.h [new file with mode: 0644]
delta.h [new file with mode: 0644]
diff-delta.c [new file with mode: 0644]
diff-lib.c [new file with mode: 0644]
diff.c [new file with mode: 0644]
diff.h [new file with mode: 0644]
diffcore-break.c [new file with mode: 0644]
diffcore-delta.c [new file with mode: 0644]
diffcore-order.c [new file with mode: 0644]
diffcore-pickaxe.c [new file with mode: 0644]
diffcore-rename.c [new file with mode: 0644]
diffcore.h [new file with mode: 0644]
dir.c [new file with mode: 0644]
dir.h [new file with mode: 0644]
dump-cache-tree.c [new file with mode: 0644]
entry.c [new file with mode: 0644]
environment.c [new file with mode: 0644]
exec_cmd.c [new file with mode: 0644]
exec_cmd.h [new file with mode: 0644]
fast-import.c [new file with mode: 0644]
fetch-pack.c [new file with mode: 0644]
fetch.c [new file with mode: 0644]
fetch.h [new file with mode: 0644]
generate-cmdlist.sh [new file with mode: 0755]
git-add--interactive.perl [new file with mode: 0755]
git-am.sh [new file with mode: 0755]
git-applymbox.sh [new file with mode: 0755]
git-applypatch.sh [new file with mode: 0755]
git-archimport.perl [new file with mode: 0755]
git-bisect.sh [new file with mode: 0755]
git-checkout.sh [new file with mode: 0755]
git-clean.sh [new file with mode: 0755]
git-clone.sh [new file with mode: 0755]
git-commit.sh [new file with mode: 0755]
git-compat-util.h [new file with mode: 0644]
git-cvsexportcommit.perl [new file with mode: 0755]
git-cvsimport.perl [new file with mode: 0755]
git-cvsserver.perl [new file with mode: 0755]
git-fetch.sh [new file with mode: 0755]
git-gui/.gitignore [new file with mode: 0644]
git-gui/GIT-VERSION-GEN [new file with mode: 0755]
git-gui/Makefile [new file with mode: 0644]
git-gui/git-gui.sh [moved from git-gui.sh with 100% similarity]
git-instaweb.sh [new file with mode: 0755]
git-lost-found.sh [new file with mode: 0755]
git-ls-remote.sh [new file with mode: 0755]
git-merge-octopus.sh [new file with mode: 0755]
git-merge-one-file.sh [new file with mode: 0755]
git-merge-ours.sh [new file with mode: 0755]
git-merge-resolve.sh [new file with mode: 0755]
git-merge-stupid.sh [new file with mode: 0755]
git-merge.sh [new file with mode: 0755]
git-mergetool.sh [new file with mode: 0755]
git-p4import.py [new file with mode: 0644]
git-parse-remote.sh [new file with mode: 0755]
git-pull.sh [new file with mode: 0755]
git-quiltimport.sh [new file with mode: 0755]
git-rebase.sh [new file with mode: 0755]
git-relink.perl [new file with mode: 0755]
git-remote.perl [new file with mode: 0755]
git-repack.sh [new file with mode: 0755]
git-request-pull.sh [new file with mode: 0755]
git-reset.sh [new file with mode: 0755]
git-send-email.perl [new file with mode: 0755]
git-sh-setup.sh [new file with mode: 0755]
git-svn.perl [new file with mode: 0755]
git-svnimport.perl [new file with mode: 0755]
git-tag.sh [new file with mode: 0755]
git-verify-tag.sh [new file with mode: 0755]
git.c [new file with mode: 0644]
git.spec.in [new file with mode: 0644]
gitk [new file with mode: 0755]
gitweb/INSTALL [new file with mode: 0644]
gitweb/README [new file with mode: 0644]
gitweb/git-favicon.png [new file with mode: 0644]
gitweb/git-logo.png [new file with mode: 0644]
gitweb/gitweb.css [new file with mode: 0644]
gitweb/gitweb.perl [new file with mode: 0755]
gitweb/test/Märchen [new file with mode: 0644]
gitweb/test/file with spaces [new file with mode: 0644]
gitweb/test/file+plus+sign [new file with mode: 0644]
grep.c [new file with mode: 0644]
grep.h [new file with mode: 0644]
hash-object.c [new file with mode: 0644]
help.c [new file with mode: 0644]
http-fetch.c [new file with mode: 0644]
http-push.c [new file with mode: 0644]
http.c [new file with mode: 0644]
http.h [new file with mode: 0644]
ident.c [new file with mode: 0644]
imap-send.c [new file with mode: 0644]
index-pack.c [new file with mode: 0644]
interpolate.c [new file with mode: 0644]
interpolate.h [new file with mode: 0644]
list-objects.c [new file with mode: 0644]
list-objects.h [new file with mode: 0644]
local-fetch.c [new file with mode: 0644]
lockfile.c [new file with mode: 0644]
log-tree.c [new file with mode: 0644]
log-tree.h [new file with mode: 0644]
mailmap.c [new file with mode: 0644]
mailmap.h [new file with mode: 0644]
match-trees.c [new file with mode: 0644]
merge-file.c [new file with mode: 0644]
merge-index.c [new file with mode: 0644]
merge-recursive.c [new file with mode: 0644]
merge-tree.c [new file with mode: 0644]
mktag.c [new file with mode: 0644]
mktree.c [new file with mode: 0644]
mozilla-sha1/sha1.c [new file with mode: 0644]
mozilla-sha1/sha1.h [new file with mode: 0644]
object-refs.c [new file with mode: 0644]
object.c [new file with mode: 0644]
object.h [new file with mode: 0644]
pack-check.c [new file with mode: 0644]
pack-redundant.c [new file with mode: 0644]
pack-write.c [new file with mode: 0644]
pack.h [new file with mode: 0644]
pager.c [new file with mode: 0644]
patch-delta.c [new file with mode: 0644]
patch-id.c [new file with mode: 0644]
patch-ids.c [new file with mode: 0644]
patch-ids.h [new file with mode: 0644]
path-list.c [new file with mode: 0644]
path-list.h [new file with mode: 0644]
path.c [new file with mode: 0644]
peek-remote.c [new file with mode: 0644]
perl/.gitignore [new file with mode: 0644]
perl/Git.pm [new file with mode: 0644]
perl/Makefile [new file with mode: 0644]
perl/Makefile.PL [new file with mode: 0644]
perl/private-Error.pm [new file with mode: 0644]
pkt-line.c [new file with mode: 0644]
pkt-line.h [new file with mode: 0644]
ppc/sha1.c [new file with mode: 0644]
ppc/sha1.h [new file with mode: 0644]
ppc/sha1ppc.S [new file with mode: 0644]
progress.c [new file with mode: 0644]
progress.h [new file with mode: 0644]
quote.c [new file with mode: 0644]
quote.h [new file with mode: 0644]
reachable.c [new file with mode: 0644]
reachable.h [new file with mode: 0644]
read-cache.c [new file with mode: 0644]
receive-pack.c [new file with mode: 0644]
reflog-walk.c [new file with mode: 0644]
reflog-walk.h [new file with mode: 0644]
refs.c [new file with mode: 0644]
refs.h [new file with mode: 0644]
revision.c [new file with mode: 0644]
revision.h [new file with mode: 0644]
rsh.c [new file with mode: 0644]
rsh.h [new file with mode: 0644]
run-command.c [new file with mode: 0644]
run-command.h [new file with mode: 0644]
send-pack.c [new file with mode: 0644]
server-info.c [new file with mode: 0644]
setup.c [new file with mode: 0644]
sha1_file.c [new file with mode: 0644]
sha1_name.c [new file with mode: 0644]
shallow.c [new file with mode: 0644]
shell.c [new file with mode: 0644]
show-index.c [new file with mode: 0644]
sideband.c [new file with mode: 0644]
sideband.h [new file with mode: 0644]
ssh-fetch.c [new file with mode: 0644]
ssh-pull.c [new file with mode: 0644]
ssh-push.c [new file with mode: 0644]
ssh-upload.c [new file with mode: 0644]
strbuf.c [new file with mode: 0644]
strbuf.h [new file with mode: 0644]
t/.gitignore [new file with mode: 0644]
t/Makefile [new file with mode: 0644]
t/README [new file with mode: 0644]
t/annotate-tests.sh [new file with mode: 0644]
t/diff-lib.sh [new file with mode: 0644]
t/lib-git-svn.sh [new file with mode: 0644]
t/lib-read-tree-m-3way.sh [new file with mode: 0644]
t/t0000-basic.sh [new file with mode: 0755]
t/t0010-racy-git.sh [new file with mode: 0755]
t/t0020-crlf.sh [new file with mode: 0755]
t/t0021-conversion.sh [new file with mode: 0755]
t/t1000-read-tree-m-3way.sh [new file with mode: 0755]
t/t1001-read-tree-m-2way.sh [new file with mode: 0755]
t/t1002-read-tree-m-u-2way.sh [new file with mode: 0755]
t/t1003-read-tree-prefix.sh [new file with mode: 0755]
t/t1004-read-tree-m-u-wf.sh [new file with mode: 0755]
t/t1020-subdirectory.sh [new file with mode: 0755]
t/t1100-commit-tree-options.sh [new file with mode: 0755]
t/t1200-tutorial.sh [new file with mode: 0755]
t/t1300-repo-config.sh [new file with mode: 0755]
t/t1400-update-ref.sh [new file with mode: 0755]
t/t1410-reflog.sh [new file with mode: 0755]
t/t2000-checkout-cache-clash.sh [new file with mode: 0755]
t/t2001-checkout-cache-clash.sh [new file with mode: 0755]
t/t2002-checkout-cache-u.sh [new file with mode: 0755]
t/t2003-checkout-cache-mkdir.sh [new file with mode: 0755]
t/t2004-checkout-cache-temp.sh [new file with mode: 0755]
t/t2005-checkout-index-symlinks.sh [new file with mode: 0755]
t/t2100-update-cache-badpath.sh [new file with mode: 0755]
t/t2101-update-index-reupdate.sh [new file with mode: 0755]
t/t2102-update-index-symlinks.sh [new file with mode: 0755]
t/t3000-ls-files-others.sh [new file with mode: 0755]
t/t3001-ls-files-others-exclude.sh [new file with mode: 0755]
t/t3002-ls-files-dashpath.sh [new file with mode: 0755]
t/t3010-ls-files-killed-modified.sh [new file with mode: 0755]
t/t3020-ls-files-error-unmatch.sh [new file with mode: 0755]
t/t3030-merge-recursive.sh [new file with mode: 0755]
t/t3040-subprojects-basic.sh [new file with mode: 0755]
t/t3100-ls-tree-restrict.sh [new file with mode: 0755]
t/t3101-ls-tree-dirname.sh [new file with mode: 0755]
t/t3200-branch.sh [new file with mode: 0755]
t/t3210-pack-refs.sh [new file with mode: 0755]
t/t3300-funny-names.sh [new file with mode: 0755]
t/t3400-rebase.sh [new file with mode: 0755]
t/t3401-rebase-partial.sh [new file with mode: 0755]
t/t3402-rebase-merge.sh [new file with mode: 0755]
t/t3403-rebase-skip.sh [new file with mode: 0755]
t/t3500-cherry.sh [new file with mode: 0755]
t/t3501-revert-cherry-pick.sh [new file with mode: 0755]
t/t3600-rm.sh [new file with mode: 0755]
t/t3700-add.sh [new file with mode: 0755]
t/t3800-mktag.sh [new file with mode: 0755]
t/t3900-i18n-commit.sh [new file with mode: 0755]
t/t3900/1-UTF-8.txt [new file with mode: 0644]
t/t3900/2-UTF-8.txt [new file with mode: 0644]
t/t3900/EUCJP.txt [new file with mode: 0644]
t/t3900/ISO-2022-JP.txt [new file with mode: 0644]
t/t3900/ISO-8859-1.txt [new file with mode: 0644]
t/t3901-8859-1.txt [new file with mode: 0755]
t/t3901-i18n-patch.sh [new file with mode: 0755]
t/t3901-utf8.txt [new file with mode: 0755]
t/t4000-diff-format.sh [new file with mode: 0755]
t/t4001-diff-rename.sh [new file with mode: 0755]
t/t4002-diff-basic.sh [new file with mode: 0755]
t/t4003-diff-rename-1.sh [new file with mode: 0755]
t/t4004-diff-rename-symlink.sh [new file with mode: 0755]
t/t4005-diff-rename-2.sh [new file with mode: 0755]
t/t4006-diff-mode.sh [new file with mode: 0755]
t/t4007-rename-3.sh [new file with mode: 0755]
t/t4008-diff-break-rewrite.sh [new file with mode: 0755]
t/t4009-diff-rename-4.sh [new file with mode: 0755]
t/t4010-diff-pathspec.sh [new file with mode: 0755]
t/t4011-diff-symlink.sh [new file with mode: 0755]
t/t4012-diff-binary.sh [new file with mode: 0755]
t/t4013-diff-various.sh [new file with mode: 0755]
t/t4013/diff.diff-tree_--cc_--patch-with-stat_--summary_master [new file with mode: 0644]
t/t4013/diff.diff-tree_--cc_--patch-with-stat_--summary_side [new file with mode: 0644]
t/t4013/diff.diff-tree_--cc_--patch-with-stat_master [new file with mode: 0644]
t/t4013/diff.diff-tree_--cc_--stat_--summary_master [new file with mode: 0644]
t/t4013/diff.diff-tree_--cc_--stat_--summary_side [new file with mode: 0644]
t/t4013/diff.diff-tree_--cc_--stat_master [new file with mode: 0644]
t/t4013/diff.diff-tree_--cc_master [new file with mode: 0644]
t/t4013/diff.diff-tree_--patch-with-raw_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--patch-with-stat_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty=oneline_--patch-with-raw_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty=oneline_--patch-with-stat_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty=oneline_--root_--patch-with-raw_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty=oneline_--root_--patch-with-stat_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty=oneline_--root_-p_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty=oneline_--root_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty=oneline_-p_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty=oneline_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_--patch-with-raw_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_--patch-with-stat_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_--patch-with-stat_side [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_--root_--patch-with-raw_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_--root_--patch-with-stat_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_--root_--stat_--summary_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_--root_--stat_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_--root_--summary_-r_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_--root_--summary_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_--root_-p_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_--root_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_--stat_--summary_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_--stat_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_--summary_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_-p_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_-p_side [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--pretty_side [new file with mode: 0644]
t/t4013/diff.diff-tree_--root_--abbrev_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--root_--patch-with-raw_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--root_--patch-with-stat_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--root_-p_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--root_-r_--abbrev=4_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--root_-r_--abbrev_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--root_-r_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_--root_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_-c_--abbrev_master [new file with mode: 0644]
t/t4013/diff.diff-tree_-c_--stat_--summary_master [new file with mode: 0644]
t/t4013/diff.diff-tree_-c_--stat_--summary_side [new file with mode: 0644]
t/t4013/diff.diff-tree_-c_--stat_master [new file with mode: 0644]
t/t4013/diff.diff-tree_-c_master [new file with mode: 0644]
t/t4013/diff.diff-tree_-p_-m_master [new file with mode: 0644]
t/t4013/diff.diff-tree_-p_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_-p_master [new file with mode: 0644]
t/t4013/diff.diff-tree_-r_--abbrev=4_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_-r_--abbrev_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_-r_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_initial [new file with mode: 0644]
t/t4013/diff.diff-tree_master [new file with mode: 0644]
t/t4013/diff.diff_--abbrev_initial..side [new file with mode: 0644]
t/t4013/diff.diff_--patch-with-raw_-r_initial..side [new file with mode: 0644]
t/t4013/diff.diff_--patch-with-raw_initial..side [new file with mode: 0644]
t/t4013/diff.diff_--patch-with-stat_-r_initial..side [new file with mode: 0644]
t/t4013/diff.diff_--patch-with-stat_initial..side [new file with mode: 0644]
t/t4013/diff.diff_--stat_initial..side [new file with mode: 0644]
t/t4013/diff.diff_-r_--stat_initial..side [new file with mode: 0644]
t/t4013/diff.diff_-r_initial..side [new file with mode: 0644]
t/t4013/diff.diff_initial..side [new file with mode: 0644]
t/t4013/diff.format-patch_--attach_--stdout_initial..master [new file with mode: 0644]
t/t4013/diff.format-patch_--attach_--stdout_initial..master^ [new file with mode: 0644]
t/t4013/diff.format-patch_--attach_--stdout_initial..side [new file with mode: 0644]
t/t4013/diff.format-patch_--inline_--stdout_--subject-prefix=TESTCASE_initial..master [new file with mode: 0644]
t/t4013/diff.format-patch_--inline_--stdout_initial..master [new file with mode: 0644]
t/t4013/diff.format-patch_--inline_--stdout_initial..master^ [new file with mode: 0644]
t/t4013/diff.format-patch_--inline_--stdout_initial..side [new file with mode: 0644]
t/t4013/diff.format-patch_--stdout_initial..master [new file with mode: 0644]
t/t4013/diff.format-patch_--stdout_initial..master^ [new file with mode: 0644]
t/t4013/diff.format-patch_--stdout_initial..side [new file with mode: 0644]
t/t4013/diff.log_--patch-with-stat_--summary_master_--_dir_ [new file with mode: 0644]
t/t4013/diff.log_--patch-with-stat_master [new file with mode: 0644]
t/t4013/diff.log_--patch-with-stat_master_--_dir_ [new file with mode: 0644]
t/t4013/diff.log_--root_--cc_--patch-with-stat_--summary_master [new file with mode: 0644]
t/t4013/diff.log_--root_--patch-with-stat_--summary_master [new file with mode: 0644]
t/t4013/diff.log_--root_--patch-with-stat_master [new file with mode: 0644]
t/t4013/diff.log_--root_-c_--patch-with-stat_--summary_master [new file with mode: 0644]
t/t4013/diff.log_--root_-p_master [new file with mode: 0644]
t/t4013/diff.log_--root_master [new file with mode: 0644]
t/t4013/diff.log_-SF_-p_master [new file with mode: 0644]
t/t4013/diff.log_-SF_master [new file with mode: 0644]
t/t4013/diff.log_-p_master [new file with mode: 0644]
t/t4013/diff.log_master [new file with mode: 0644]
t/t4013/diff.show_--patch-with-raw_side [new file with mode: 0644]
t/t4013/diff.show_--patch-with-stat_--summary_side [new file with mode: 0644]
t/t4013/diff.show_--patch-with-stat_side [new file with mode: 0644]
t/t4013/diff.show_--root_initial [new file with mode: 0644]
t/t4013/diff.show_--stat_--summary_side [new file with mode: 0644]
t/t4013/diff.show_--stat_side [new file with mode: 0644]
t/t4013/diff.show_initial [new file with mode: 0644]
t/t4013/diff.show_master [new file with mode: 0644]
t/t4013/diff.show_side [new file with mode: 0644]
t/t4013/diff.whatchanged_--patch-with-stat_--summary_master_--_dir_ [new file with mode: 0644]
t/t4013/diff.whatchanged_--patch-with-stat_master [new file with mode: 0644]
t/t4013/diff.whatchanged_--patch-with-stat_master_--_dir_ [new file with mode: 0644]
t/t4013/diff.whatchanged_--root_--cc_--patch-with-stat_--summary_master [new file with mode: 0644]
t/t4013/diff.whatchanged_--root_--patch-with-stat_--summary_master [new file with mode: 0644]
t/t4013/diff.whatchanged_--root_--patch-with-stat_master [new file with mode: 0644]
t/t4013/diff.whatchanged_--root_-c_--patch-with-stat_--summary_master [new file with mode: 0644]
t/t4013/diff.whatchanged_--root_-p_master [new file with mode: 0644]
t/t4013/diff.whatchanged_--root_master [new file with mode: 0644]
t/t4013/diff.whatchanged_-SF_-p_master [new file with mode: 0644]
t/t4013/diff.whatchanged_-SF_master [new file with mode: 0644]
t/t4013/diff.whatchanged_-p_master [new file with mode: 0644]
t/t4013/diff.whatchanged_master [new file with mode: 0644]
t/t4014-format-patch.sh [new file with mode: 0755]
t/t4015-diff-whitespace.sh [new file with mode: 0755]
t/t4016-diff-quote.sh [new file with mode: 0755]
t/t4017-diff-retval.sh [new file with mode: 0755]
t/t4017-quiet.sh [new file with mode: 0755]
t/t4020-diff-external.sh [new file with mode: 0755]
t/t4100-apply-stat.sh [new file with mode: 0755]
t/t4100/t-apply-1.expect [new file with mode: 0644]
t/t4100/t-apply-1.patch [new file with mode: 0644]
t/t4100/t-apply-2.expect [new file with mode: 0644]
t/t4100/t-apply-2.patch [new file with mode: 0644]
t/t4100/t-apply-3.expect [new file with mode: 0644]
t/t4100/t-apply-3.patch [new file with mode: 0644]
t/t4100/t-apply-4.expect [new file with mode: 0644]
t/t4100/t-apply-4.patch [new file with mode: 0644]
t/t4100/t-apply-5.expect [new file with mode: 0644]
t/t4100/t-apply-5.patch [new file with mode: 0644]
t/t4100/t-apply-6.expect [new file with mode: 0644]
t/t4100/t-apply-6.patch [new file with mode: 0644]
t/t4100/t-apply-7.expect [new file with mode: 0644]
t/t4100/t-apply-7.patch [new file with mode: 0644]
t/t4101-apply-nonl.sh [new file with mode: 0755]
t/t4101/diff.0-1 [new file with mode: 0644]
t/t4101/diff.0-2 [new file with mode: 0644]
t/t4101/diff.0-3 [new file with mode: 0644]
t/t4101/diff.1-0 [new file with mode: 0644]
t/t4101/diff.1-2 [new file with mode: 0644]
t/t4101/diff.1-3 [new file with mode: 0644]
t/t4101/diff.2-0 [new file with mode: 0644]
t/t4101/diff.2-1 [new file with mode: 0644]
t/t4101/diff.2-3 [new file with mode: 0644]
t/t4101/diff.3-0 [new file with mode: 0644]
t/t4101/diff.3-1 [new file with mode: 0644]
t/t4101/diff.3-2 [new file with mode: 0644]
t/t4102-apply-rename.sh [new file with mode: 0755]
t/t4103-apply-binary.sh [new file with mode: 0755]
t/t4104-apply-boundary.sh [new file with mode: 0755]
t/t4109-apply-multifrag.sh [new file with mode: 0755]
t/t4110-apply-scan.sh [new file with mode: 0755]
t/t4112-apply-renames.sh [new file with mode: 0755]
t/t4113-apply-ending.sh [new file with mode: 0755]
t/t4114-apply-typechange.sh [new file with mode: 0755]
t/t4115-apply-symlink.sh [new file with mode: 0755]
t/t4116-apply-reverse.sh [new file with mode: 0755]
t/t4117-apply-reject.sh [new file with mode: 0755]
t/t4118-apply-empty-context.sh [new file with mode: 0755]
t/t4119-apply-config.sh [new file with mode: 0755]
t/t4120-apply-popt.sh [new file with mode: 0755]
t/t4121-apply-diffs.sh [new file with mode: 0755]
t/t4200-rerere.sh [new file with mode: 0755]
t/t4201-shortlog.sh [new file with mode: 0755]
t/t5000-tar-tree.sh [new file with mode: 0755]
t/t5100-mailinfo.sh [new file with mode: 0755]
t/t5100/info0001 [new file with mode: 0644]
t/t5100/info0002 [new file with mode: 0644]
t/t5100/info0003 [new file with mode: 0644]
t/t5100/info0004 [new file with mode: 0644]
t/t5100/info0005 [new file with mode: 0644]
t/t5100/info0006 [new file with mode: 0644]
t/t5100/info0007 [new file with mode: 0644]
t/t5100/info0008 [new file with mode: 0644]
t/t5100/msg0001 [new file with mode: 0644]
t/t5100/msg0002 [new file with mode: 0644]
t/t5100/msg0003 [new file with mode: 0644]
t/t5100/msg0004 [new file with mode: 0644]
t/t5100/msg0005 [new file with mode: 0644]
t/t5100/msg0006 [new file with mode: 0644]
t/t5100/msg0007 [new file with mode: 0644]
t/t5100/msg0008 [new file with mode: 0644]
t/t5100/patch0001 [new file with mode: 0644]
t/t5100/patch0002 [new file with mode: 0644]
t/t5100/patch0003 [new file with mode: 0644]
t/t5100/patch0004 [new file with mode: 0644]
t/t5100/patch0005 [new file with mode: 0644]
t/t5100/patch0006 [new file with mode: 0644]
t/t5100/patch0007 [new file with mode: 0644]
t/t5100/patch0008 [new file with mode: 0644]
t/t5100/sample.mbox [new file with mode: 0644]
t/t5300-pack-object.sh [new file with mode: 0755]
t/t5301-sliding-window.sh [new file with mode: 0755]
t/t5302-pack-index.sh [new file with mode: 0755]
t/t5400-send-pack.sh [new file with mode: 0755]
t/t5401-update-hooks.sh [new file with mode: 0755]
t/t5500-fetch-pack.sh [new file with mode: 0755]
t/t5502-quickfetch.sh [new file with mode: 0755]
t/t5510-fetch.sh [new file with mode: 0755]
t/t5515-fetch-merge-logic.sh [new file with mode: 0755]
t/t5515/fetch.br-branches-default [new file with mode: 0644]
t/t5515/fetch.br-branches-default-merge [new file with mode: 0644]
t/t5515/fetch.br-branches-default-merge_branches-default [new file with mode: 0644]
t/t5515/fetch.br-branches-default-octopus [new file with mode: 0644]
t/t5515/fetch.br-branches-default-octopus_branches-default [new file with mode: 0644]
t/t5515/fetch.br-branches-default_branches-default [new file with mode: 0644]
t/t5515/fetch.br-branches-one [new file with mode: 0644]
t/t5515/fetch.br-branches-one-merge [new file with mode: 0644]
t/t5515/fetch.br-branches-one-merge_branches-one [new file with mode: 0644]
t/t5515/fetch.br-branches-one-octopus [new file with mode: 0644]
t/t5515/fetch.br-branches-one-octopus_branches-one [new file with mode: 0644]
t/t5515/fetch.br-branches-one_branches-one [new file with mode: 0644]
t/t5515/fetch.br-config-explicit [new file with mode: 0644]
t/t5515/fetch.br-config-explicit-merge [new file with mode: 0644]
t/t5515/fetch.br-config-explicit-merge_config-explicit [new file with mode: 0644]
t/t5515/fetch.br-config-explicit-octopus [new file with mode: 0644]
t/t5515/fetch.br-config-explicit-octopus_config-explicit [new file with mode: 0644]
t/t5515/fetch.br-config-explicit_config-explicit [new file with mode: 0644]
t/t5515/fetch.br-config-glob [new file with mode: 0644]
t/t5515/fetch.br-config-glob-merge [new file with mode: 0644]
t/t5515/fetch.br-config-glob-merge_config-glob [new file with mode: 0644]
t/t5515/fetch.br-config-glob-octopus [new file with mode: 0644]
t/t5515/fetch.br-config-glob-octopus_config-glob [new file with mode: 0644]
t/t5515/fetch.br-config-glob_config-glob [new file with mode: 0644]
t/t5515/fetch.br-remote-explicit [new file with mode: 0644]
t/t5515/fetch.br-remote-explicit-merge [new file with mode: 0644]
t/t5515/fetch.br-remote-explicit-merge_remote-explicit [new file with mode: 0644]
t/t5515/fetch.br-remote-explicit-octopus [new file with mode: 0644]
t/t5515/fetch.br-remote-explicit-octopus_remote-explicit [new file with mode: 0644]
t/t5515/fetch.br-remote-explicit_remote-explicit [new file with mode: 0644]
t/t5515/fetch.br-remote-glob [new file with mode: 0644]
t/t5515/fetch.br-remote-glob-merge [new file with mode: 0644]
t/t5515/fetch.br-remote-glob-merge_remote-glob [new file with mode: 0644]
t/t5515/fetch.br-remote-glob-octopus [new file with mode: 0644]
t/t5515/fetch.br-remote-glob-octopus_remote-glob [new file with mode: 0644]
t/t5515/fetch.br-remote-glob_remote-glob [new file with mode: 0644]
t/t5515/fetch.br-unconfig [new file with mode: 0644]
t/t5515/fetch.br-unconfig_--tags_.._.git [new file with mode: 0644]
t/t5515/fetch.br-unconfig_.._.git [new file with mode: 0644]
t/t5515/fetch.br-unconfig_.._.git_one [new file with mode: 0644]
t/t5515/fetch.br-unconfig_.._.git_one_tag_tag-one_tag_tag-three-file [new file with mode: 0644]
t/t5515/fetch.br-unconfig_.._.git_one_two [new file with mode: 0644]
t/t5515/fetch.br-unconfig_.._.git_tag_tag-one-tree_tag_tag-three-file [new file with mode: 0644]
t/t5515/fetch.br-unconfig_.._.git_tag_tag-one_tag_tag-three [new file with mode: 0644]
t/t5515/fetch.br-unconfig_branches-default [new file with mode: 0644]
t/t5515/fetch.br-unconfig_branches-one [new file with mode: 0644]
t/t5515/fetch.br-unconfig_config-explicit [new file with mode: 0644]
t/t5515/fetch.br-unconfig_config-glob [new file with mode: 0644]
t/t5515/fetch.br-unconfig_remote-explicit [new file with mode: 0644]
t/t5515/fetch.br-unconfig_remote-glob [new file with mode: 0644]
t/t5515/fetch.master [new file with mode: 0644]
t/t5515/fetch.master_--tags_.._.git [new file with mode: 0644]
t/t5515/fetch.master_.._.git [new file with mode: 0644]
t/t5515/fetch.master_.._.git_one [new file with mode: 0644]
t/t5515/fetch.master_.._.git_one_tag_tag-one_tag_tag-three-file [new file with mode: 0644]
t/t5515/fetch.master_.._.git_one_two [new file with mode: 0644]
t/t5515/fetch.master_.._.git_tag_tag-one-tree_tag_tag-three-file [new file with mode: 0644]
t/t5515/fetch.master_.._.git_tag_tag-one_tag_tag-three [new file with mode: 0644]
t/t5515/fetch.master_branches-default [new file with mode: 0644]
t/t5515/fetch.master_branches-one [new file with mode: 0644]
t/t5515/fetch.master_config-explicit [new file with mode: 0644]
t/t5515/fetch.master_config-glob [new file with mode: 0644]
t/t5515/fetch.master_remote-explicit [new file with mode: 0644]
t/t5515/fetch.master_remote-glob [new file with mode: 0644]
t/t5520-pull.sh [new file with mode: 0755]
t/t5600-clone-fail-cleanup.sh [new file with mode: 0755]
t/t5700-clone-reference.sh [new file with mode: 0755]
t/t5710-info-alternate.sh [new file with mode: 0755]
t/t6000lib.sh [new file with mode: 0755]
t/t6001-rev-list-graft.sh [new file with mode: 0755]
t/t6002-rev-list-bisect.sh [new file with mode: 0755]
t/t6003-rev-list-topo-order.sh [new file with mode: 0755]
t/t6004-rev-list-path-optim.sh [new file with mode: 0755]
t/t6005-rev-list-count.sh [new file with mode: 0755]
t/t6006-rev-list-format.sh [new file with mode: 0755]
t/t6010-merge-base.sh [new file with mode: 0755]
t/t6020-merge-df.sh [new file with mode: 0755]
t/t6021-merge-criss-cross.sh [new file with mode: 0755]
t/t6022-merge-rename.sh [new file with mode: 0755]
t/t6023-merge-file.sh [new file with mode: 0755]
t/t6023-merge-rename-nocruft.sh [new file with mode: 0755]
t/t6024-recursive-merge.sh [new file with mode: 0755]
t/t6025-merge-symlinks.sh [new file with mode: 0755]
t/t6026-merge-attr.sh [new file with mode: 0755]
t/t6030-bisect-porcelain.sh [new file with mode: 0755]
t/t6101-rev-parse-parents.sh [new file with mode: 0755]
t/t6120-describe.sh [new file with mode: 0755]
t/t6200-fmt-merge-msg.sh [new file with mode: 0755]
t/t7001-mv.sh [new file with mode: 0755]
t/t7002-grep.sh [new file with mode: 0755]
t/t7101-reset.sh [new file with mode: 0755]
t/t7201-co.sh [new file with mode: 0755]
t/t8001-annotate.sh [new file with mode: 0755]
t/t8002-blame.sh [new file with mode: 0755]
t/t8003-blame.sh [new file with mode: 0755]
t/t9001-send-email.sh [new file with mode: 0755]
t/t9100-git-svn-basic.sh [new file with mode: 0755]
t/t9101-git-svn-props.sh [new file with mode: 0755]
t/t9102-git-svn-deep-rmdir.sh [new file with mode: 0755]
t/t9104-git-svn-follow-parent.sh [new file with mode: 0755]
t/t9105-git-svn-commit-diff.sh [new file with mode: 0755]
t/t9106-git-svn-commit-diff-clobber.sh [new file with mode: 0755]
t/t9107-git-svn-migrate.sh [new file with mode: 0755]
t/t9108-git-svn-glob.sh [new file with mode: 0755]
t/t9110-git-svn-use-svm-props.sh [new file with mode: 0755]
t/t9110/svm.dump [new file with mode: 0644]
t/t9111-git-svn-use-svnsync-props.sh [new file with mode: 0755]
t/t9111/svnsync.dump [new file with mode: 0644]
t/t9200-git-cvsexportcommit.sh [new file with mode: 0755]
t/t9300-fast-import.sh [new file with mode: 0755]
t/test-lib.sh [new file with mode: 0644]
t/test4012.png [new file with mode: 0644]
t/test9200a.png [new file with mode: 0644]
t/test9200b.png [new file with mode: 0644]
tag.c [new file with mode: 0644]
tag.h [new file with mode: 0644]
tar.h [new file with mode: 0644]
templates/.gitignore [new file with mode: 0644]
templates/Makefile [new file with mode: 0644]
templates/branches-- [new file with mode: 0644]
templates/hooks--applypatch-msg [new file with mode: 0644]
templates/hooks--commit-msg [new file with mode: 0644]
templates/hooks--post-commit [new file with mode: 0644]
templates/hooks--post-receive [new file with mode: 0644]
templates/hooks--post-update [new file with mode: 0644]
templates/hooks--pre-applypatch [new file with mode: 0644]
templates/hooks--pre-commit [new file with mode: 0644]
templates/hooks--pre-rebase [new file with mode: 0644]
templates/hooks--update [new file with mode: 0644]
templates/info--exclude [new file with mode: 0644]
templates/this--description [new file with mode: 0644]
test-chmtime.c [new file with mode: 0644]
test-date.c [new file with mode: 0644]
test-delta.c [new file with mode: 0644]
test-genrandom.c [new file with mode: 0644]
test-match-trees.c [new file with mode: 0644]
test-sha1.c [new file with mode: 0644]
test-sha1.sh [new file with mode: 0755]
trace.c [new file with mode: 0644]
tree-diff.c [new file with mode: 0644]
tree-walk.c [new file with mode: 0644]
tree-walk.h [new file with mode: 0644]
tree.c [new file with mode: 0644]
tree.h [new file with mode: 0644]
unpack-file.c [new file with mode: 0644]
unpack-trees.c [new file with mode: 0644]
unpack-trees.h [new file with mode: 0644]
update-server-info.c [new file with mode: 0644]
upload-pack.c [new file with mode: 0644]
usage.c [new file with mode: 0644]
utf8.c [new file with mode: 0644]
utf8.h [new file with mode: 0644]
var.c [new file with mode: 0644]
write_or_die.c [new file with mode: 0644]
wt-status.c [new file with mode: 0644]
wt-status.h [new file with mode: 0644]
xdiff-interface.c [new file with mode: 0644]
xdiff-interface.h [new file with mode: 0644]
xdiff/xdiff.h [new file with mode: 0644]
xdiff/xdiffi.c [new file with mode: 0644]
xdiff/xdiffi.h [new file with mode: 0644]
xdiff/xemit.c [new file with mode: 0644]
xdiff/xemit.h [new file with mode: 0644]
xdiff/xinclude.h [new file with mode: 0644]
xdiff/xmacros.h [new file with mode: 0644]
xdiff/xmerge.c [new file with mode: 0644]
xdiff/xprepare.c [new file with mode: 0644]
xdiff/xprepare.h [new file with mode: 0644]
xdiff/xtypes.h [new file with mode: 0644]
xdiff/xutils.c [new file with mode: 0644]
xdiff/xutils.h [new file with mode: 0644]

index c714d38..4dc0c39 100644 (file)
@@ -1,3 +1,170 @@
+GIT-CFLAGS
+GIT-GUI-VARS
 GIT-VERSION-FILE
-git-citool
-git-gui
+git
+git-add
+git-add--interactive
+git-am
+git-annotate
+git-apply
+git-applymbox
+git-applypatch
+git-archimport
+git-archive
+git-bisect
+git-blame
+git-branch
+git-bundle
+git-cat-file
+git-check-attr
+git-check-ref-format
+git-checkout
+git-checkout-index
+git-cherry
+git-cherry-pick
+git-clean
+git-clone
+git-commit
+git-commit-tree
+git-config
+git-convert-objects
+git-count-objects
+git-cvsexportcommit
+git-cvsimport
+git-cvsserver
+git-daemon
+git-diff
+git-diff-files
+git-diff-index
+git-diff-tree
+git-describe
+git-fast-import
+git-fetch
+git-fetch--tool
+git-fetch-pack
+git-findtags
+git-fmt-merge-msg
+git-for-each-ref
+git-format-patch
+git-fsck
+git-fsck-objects
+git-gc
+git-get-tar-commit-id
+git-grep
+git-hash-object
+git-http-fetch
+git-http-push
+git-imap-send
+git-index-pack
+git-init
+git-init-db
+git-instaweb
+git-local-fetch
+git-log
+git-lost-found
+git-ls-files
+git-ls-remote
+git-ls-tree
+git-mailinfo
+git-mailsplit
+git-merge
+git-merge-base
+git-merge-index
+git-merge-file
+git-merge-tree
+git-merge-octopus
+git-merge-one-file
+git-merge-ours
+git-merge-recursive
+git-merge-resolve
+git-merge-stupid
+git-merge-subtree
+git-mergetool
+git-mktag
+git-mktree
+git-name-rev
+git-mv
+git-pack-redundant
+git-pack-objects
+git-pack-refs
+git-parse-remote
+git-patch-id
+git-peek-remote
+git-prune
+git-prune-packed
+git-pull
+git-push
+git-quiltimport
+git-read-tree
+git-rebase
+git-receive-pack
+git-reflog
+git-relink
+git-remote
+git-repack
+git-repo-config
+git-request-pull
+git-rerere
+git-reset
+git-rev-list
+git-rev-parse
+git-revert
+git-rm
+git-runstatus
+git-send-email
+git-send-pack
+git-sh-setup
+git-shell
+git-shortlog
+git-show
+git-show-branch
+git-show-index
+git-show-ref
+git-ssh-fetch
+git-ssh-pull
+git-ssh-push
+git-ssh-upload
+git-status
+git-stripspace
+git-svn
+git-svnimport
+git-symbolic-ref
+git-tag
+git-tar-tree
+git-unpack-file
+git-unpack-objects
+git-update-index
+git-update-ref
+git-update-server-info
+git-upload-archive
+git-upload-pack
+git-var
+git-verify-pack
+git-verify-tag
+git-whatchanged
+git-write-tree
+git-core-*/?*
+gitk-wish
+gitweb/gitweb.cgi
+test-chmtime
+test-date
+test-delta
+test-dump-cache-tree
+test-genrandom
+test-match-trees
+common-cmds.h
+*.tar.gz
+*.dsc
+*.deb
+git-core.spec
+*.exe
+*.[ao]
+*.py[co]
+config.mak
+autom4te.cache
+config.cache
+config.log
+config.status
+config.mak.autogen
+config.mak.append
+configure
diff --git a/.mailmap b/.mailmap
new file mode 100644 (file)
index 0000000..17e89af
--- /dev/null
+++ b/.mailmap
@@ -0,0 +1,41 @@
+#
+# This list is used by git-shortlog to fix a few botched name translations
+# in the git archive, either because the author's full name was messed up
+# and/or not always written the same way, making contributions from the
+# same person appearing not to be so.
+#
+
+Aneesh Kumar K.V <aneesh.kumar@gmail.com>
+Chris Shoemaker <c.shoemaker@cox.net>
+Daniel Barkalow <barkalow@iabervon.org>
+David Kågedal <davidk@lysator.liu.se>
+Fredrik Kuivinen <freku045@student.liu.se>
+H. Peter Anvin <hpa@bonde.sc.orionmulti.com>
+H. Peter Anvin <hpa@tazenda.sc.orionmulti.com>
+H. Peter Anvin <hpa@trantor.hos.anvin.org>
+Horst H. von Brand <vonbrand@inf.utfsm.cl>
+Joachim Berdal Haga <cjhaga@fys.uio.no>
+Jon Loeliger <jdl@freescale.com>
+Jon Seymour <jon@blackcubes.dyndns.org>
+Karl Hasselström <kha@treskal.com>
+Kent Engstrom <kent@lysator.liu.se>
+Lars Doelle <lars.doelle@on-line.de>
+Lars Doelle <lars.doelle@on-line ! de>
+Lukas Sandström <lukass@etek.chalmers.se>
+Martin Langhoff <martin@catalyst.net.nz>
+Michele Ballabio <barra_cuda@katamail.com>
+Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
+Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
+René Scharfe <rene.scharfe@lsrfire.ath.cx>
+Robert Fitzsimons <robfitz@273k.net>
+Sam Vilain <sam@vilain.net>
+Santi Béjar <sbejar@gmail.com>
+Sean Estabrooks <seanlkml@sympatico.ca>
+Shawn O. Pearce <spearce@spearce.org>
+Theodore Ts'o <tytso@mit.edu>
+Tony Luck <tony.luck@intel.com>
+Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
+Ville Skyttä <scop@xemacs.org>
+YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
+anonymous <linux@horizon.com>
+anonymous <linux@horizon.net>
diff --git a/COPYING b/COPYING
new file mode 100644 (file)
index 0000000..6ff87c4
--- /dev/null
+++ b/COPYING
@@ -0,0 +1,361 @@
+
+ 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.
+
+ HOWEVER, in order to allow a migration to GPLv3 if that seems like
+ a good idea, I also ask that people involved with the project make
+ their preferences known. In particular, if you trust me to make that
+ decision, you might note so in your copyright message, ie something
+ like
+
+       This file is licensed under the GPL v2, or a later version
+       at the discretion of Linus.
+
+  might avoid issues. But we can also just decide to synchronize and
+  contact all copyright holders on record if/when the occasion arises.
+
+                       Linus Torvalds
+
+----------------------------------------
+
+                   GNU GENERAL PUBLIC LICENSE
+                      Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+                       59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+                           Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.)  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+\f
+                   GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+  1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+
+  2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+    a) You must cause the modified files to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+    b) You must cause any work that you distribute or publish, that in
+    whole or in part contains or is derived from the Program or any
+    part thereof, to be licensed as a whole at no charge to all third
+    parties under the terms of this License.
+
+    c) If the modified program normally reads commands interactively
+    when run, you must cause it, when started running for such
+    interactive use in the most ordinary way, to print or display an
+    announcement including an appropriate copyright notice and a
+    notice that there is no warranty (or else, saying that you provide
+    a warranty) and that users may redistribute the program under
+    these conditions, and telling the user how to view a copy of this
+    License.  (Exception: if the Program itself is interactive but
+    does not normally print such an announcement, your work based on
+    the Program is not required to print an announcement.)
+\f
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works.  But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+  3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+
+    a) Accompany it with the complete corresponding machine-readable
+    source code, which must be distributed under the terms of Sections
+    1 and 2 above on a medium customarily used for software interchange; or,
+
+    b) Accompany it with a written offer, valid for at least three
+    years, to give any third party, for a charge no more than your
+    cost of physically performing source distribution, a complete
+    machine-readable copy of the corresponding source code, to be
+    distributed under the terms of Sections 1 and 2 above on a medium
+    customarily used for software interchange; or,
+
+    c) Accompany it with the information you received as to the offer
+    to distribute corresponding source code.  (This alternative is
+    allowed only for noncommercial distribution and only if you
+    received the program in object code or executable form with such
+    an offer, in accord with Subsection b above.)
+
+The source code for a work means the preferred form of the work for
+making modifications to it.  For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable.  However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+\f
+  4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License.  Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+  5. You are not required to accept this License, since you have not
+signed it.  However, nothing else grants you permission to modify or
+distribute the Program or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+
+  6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions.  You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+  7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices.  Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+\f
+  8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded.  In such case, this License incorporates
+the limitation as if written in the body of this License.
+
+  9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation.  If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+
+  10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission.  For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this.  Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+                           NO WARRANTY
+
+  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+                    END OF TERMS AND CONDITIONS
+\f
+           How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+
+    Gnomovision version 69, Copyright (C) year name of author
+    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary.  Here is a sample; alter the names:
+
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+  `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+  <signature of Ty Coon>, 1 April 1989
+  Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into
+proprietary programs.  If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library.  If this is what you want to do, use the GNU Library General
+Public License instead of this License.
diff --git a/Documentation/.gitignore b/Documentation/.gitignore
new file mode 100644 (file)
index 0000000..a37b215
--- /dev/null
@@ -0,0 +1,7 @@
+*.xml
+*.html
+*.[1-8]
+*.made
+howto-index.txt
+doc.dep
+cmds-*.txt
diff --git a/Documentation/Makefile b/Documentation/Makefile
new file mode 100644 (file)
index 0000000..3f92783
--- /dev/null
@@ -0,0 +1,159 @@
+MAN1_TXT= \
+       $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
+               $(wildcard git-*.txt)) \
+       gitk.txt
+MAN5_TXT=gitattributes.txt
+MAN7_TXT=git.txt
+
+DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT))
+
+ARTICLES = tutorial
+ARTICLES += tutorial-2
+ARTICLES += core-tutorial
+ARTICLES += cvs-migration
+ARTICLES += diffcore
+ARTICLES += howto-index
+ARTICLES += repository-layout
+ARTICLES += hooks
+ARTICLES += everyday
+ARTICLES += git-tools
+ARTICLES += glossary
+# with their own formatting rules.
+SP_ARTICLES = howto/revert-branch-rebase user-manual
+
+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
+mandir?=$(prefix)/man
+man1dir=$(mandir)/man1
+man5dir=$(mandir)/man5
+man7dir=$(mandir)/man7
+# DESTDIR=
+
+ASCIIDOC=asciidoc
+ASCIIDOC_EXTRA =
+INSTALL?=install
+DOC_REF = origin/man
+
+-include ../config.mak.autogen
+-include ../config.mak
+
+#
+# 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)
+
+install: man
+       $(INSTALL) -d -m755 $(DESTDIR)$(man1dir)
+       $(INSTALL) -d -m755 $(DESTDIR)$(man5dir)
+       $(INSTALL) -d -m755 $(DESTDIR)$(man7dir)
+       $(INSTALL) -m644 $(DOC_MAN1) $(DESTDIR)$(man1dir)
+       $(INSTALL) -m644 $(DOC_MAN5) $(DESTDIR)$(man5dir)
+       $(INSTALL) -m644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
+
+
+../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 -f $@+ $@
+       perl ./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 $(MAN1_TXT)
+       perl ./cmd-list.perl
+       date >$@
+
+git.7 git.html: git.txt core-intro.txt
+
+clean:
+       rm -f *.xml *.xml+ *.html *.html+ *.1 *.5 *.7 howto-index.txt howto/*.html doc.dep
+       rm -f $(cmds_txt) *.made
+
+%.html : %.txt
+       rm -f $@+ $@
+       $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
+               $(ASCIIDOC_EXTRA) -o - $< | \
+               sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' >$@+
+       mv $@+ $@
+
+%.1 %.5 %.7 : %.xml
+       xmlto -m callouts.xsl man $<
+
+%.xml : %.txt
+       rm -f $@+ $@
+       $(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \
+               $(ASCIIDOC_EXTRA) -o - $< | \
+               sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' >$@+
+       mv $@+ $@
+
+user-manual.xml: user-manual.txt user-manual.conf
+       $(ASCIIDOC) -b docbook -d book $<
+
+XSLT = http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl
+XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css
+
+user-manual.html: user-manual.xml
+       xsltproc $(XSLTOPTS) -o $@ $(XSLT) $<
+
+howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
+       rm -f $@+ $@
+       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 -f $@+ $@
+       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) $(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 (file)
index 0000000..fea3f99
--- /dev/null
@@ -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 (file)
index 0000000..b061e50
--- /dev/null
@@ -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 (file)
index 0000000..cd500f9
--- /dev/null
@@ -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 (file)
index 0000000..b727a8d
--- /dev/null
@@ -0,0 +1,24 @@
+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 (file)
index 0000000..aa86149
--- /dev/null
@@ -0,0 +1,28 @@
+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 (file)
index 0000000..e15447f
--- /dev/null
@@ -0,0 +1,22 @@
+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 (file)
index 0000000..670ad32
--- /dev/null
@@ -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 (file)
index 0000000..daf4bdb
--- /dev/null
@@ -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 (file)
index 0000000..9147121
--- /dev/null
@@ -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 (file)
index 0000000..d884563
--- /dev/null
@@ -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 (file)
index 0000000..2ddeabd
--- /dev/null
@@ -0,0 +1,46 @@
+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.txt b/Documentation/RelNotes-1.5.1.txt
new file mode 100644 (file)
index 0000000..daed367
--- /dev/null
@@ -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.txt b/Documentation/RelNotes-1.5.2.txt
new file mode 100644 (file)
index 0000000..02b8ea0
--- /dev/null
@@ -0,0 +1,176 @@
+GIT v1.5.2 Release Notes (draft)
+========================
+
+Updates since v1.5.1
+--------------------
+
+* Plumbing level subproject support.
+
+  You can include a subdirectory that has an independent git
+  repository in your index and tree objects as a
+  "subproject".  This plumbing (i.e. "core") level subproject
+  support explicitly excludes recursive behaviour.
+
+  The "subproject" entries in the index and trees 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 '$ident$' 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 keyward
+  expansion).
+
+* 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
+
+* 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 unnecessary.
+
+  - "git blame" uses .mailmap to canonicalize the author name
+    just like "git shortlog" does.
+
+* 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.
+
+  - 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.
+
+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.
+
+* Documentation updates
+
+* Performance Tweaks
+
+--
+exec >/var/tmp/1
+O=v1.5.2-rc1-32-g125a5f1
+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 (file)
index 0000000..6a4da2d
--- /dev/null
@@ -0,0 +1,387 @@
+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 <your@email.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
+
+       Patch:
+
+       - use "git format-patch -M" to create the patch
+       - send your patch to <git@vger.kernel.org>. If you use
+         git-send-email(1), please test it first by sending
+         email to yourself.
+       - 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
+       - send the patch to the list _and_ the maintainer
+       - 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.
+
+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.
+
+
+(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.
+
+"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.
+
+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.
+
+Some people also put extra tags at the end.  They'll just be ignored for
+now, but you can do this to mark internal company procedures or just
+point out some special detail about the sign-off.
+
+
+------------------------------------------------
+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 applymbox 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; applymbox 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 (file)
index 0000000..fa7dc94
--- /dev/null
@@ -0,0 +1,58 @@
+## gitlink: macro
+#
+# Usage: gitlink: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]
+caret=^
+startsb=&#91;
+endsb=&#93;
+tilde=&#126;
+
+ifdef::backend-docbook[]
+[gitlink-inlinemacro]
+{0%{target}}
+{0#<citerefentry>}
+{0#<refentrytitle>{target}</refentrytitle><manvolnum>{0}</manvolnum>}
+{0#</citerefentry>}
+endif::backend-docbook[]
+
+ifdef::backend-docbook[]
+# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this.
+[listingblock]
+<example><title>{title}</title>
+<literallayout>
+|
+</literallayout>
+{title#}</example>
+endif::backend-docbook[]
+
+ifdef::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[]
+[gitlink-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 (file)
index 0000000..a46bf6c
--- /dev/null
@@ -0,0 +1,87 @@
+-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 gitlink: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 he 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 (executable)
index 0000000..ba4205e
--- /dev/null
@@ -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 (file)
index 0000000..6a361a2
--- /dev/null
@@ -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/cmd-list.perl b/Documentation/cmd-list.perl
new file mode 100755 (executable)
index 0000000..443802a
--- /dev/null
@@ -0,0 +1,199 @@
+#!/usr/bin/perl -w
+
+use File::Compare qw(compare);
+
+sub format_one {
+       my ($out, $name) = @_;
+       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 "gitlink:$name\[1\]::\n";
+               print $out "\t$text.\n\n";
+       }
+       else {
+               die "Description does not match $name: $description";
+       }
+}
+
+my %cmds = ();
+while (<DATA>) {
+       next if /^#/;
+
+       chomp;
+       my ($name, $cat) = /^(\S+)\s+(.*)$/;
+       push @{$cmds{$cat}}, $name;
+}
+
+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";
+       }
+}
+
+__DATA__
+git-add                                 mainporcelain
+git-am                                  mainporcelain
+git-annotate                            ancillaryinterrogators
+git-applymbox                           ancillaryinterrogators
+git-applypatch                          purehelpers
+git-apply                               plumbingmanipulators
+git-archimport                          foreignscminterface
+git-archive                             mainporcelain
+git-bisect                              mainporcelain
+git-blame                               ancillaryinterrogators
+git-branch                              mainporcelain
+git-bundle                              mainporcelain
+git-cat-file                            plumbinginterrogators
+git-checkout-index                      plumbingmanipulators
+git-checkout                            mainporcelain
+git-check-attr                          purehelpers
+git-check-ref-format                    purehelpers
+git-cherry                              ancillaryinterrogators
+git-cherry-pick                         mainporcelain
+git-clean                               mainporcelain
+git-clone                               mainporcelain
+git-commit                              mainporcelain
+git-commit-tree                         plumbingmanipulators
+git-convert-objects                     ancillarymanipulators
+git-count-objects                       ancillaryinterrogators
+git-cvsexportcommit                     foreignscminterface
+git-cvsimport                           foreignscminterface
+git-cvsserver                           foreignscminterface
+git-daemon                              synchingrepositories
+git-describe                            mainporcelain
+git-diff-files                          plumbinginterrogators
+git-diff-index                          plumbinginterrogators
+git-diff                                mainporcelain
+git-diff-tree                           plumbinginterrogators
+git-fast-import                                ancillarymanipulators
+git-fetch                               mainporcelain
+git-fetch-pack                          synchingrepositories
+git-fmt-merge-msg                       purehelpers
+git-for-each-ref                        plumbinginterrogators
+git-format-patch                        mainporcelain
+git-fsck                               ancillaryinterrogators
+git-gc                                  mainporcelain
+git-get-tar-commit-id                   ancillaryinterrogators
+git-grep                                mainporcelain
+git-hash-object                         plumbingmanipulators
+git-http-fetch                          synchelpers
+git-http-push                           synchelpers
+git-imap-send                           foreignscminterface
+git-index-pack                          plumbingmanipulators
+git-init                                mainporcelain
+git-instaweb                            ancillaryinterrogators
+gitk                                    mainporcelain
+git-local-fetch                         synchingrepositories
+git-log                                 mainporcelain
+git-lost-found                          ancillarymanipulators
+git-ls-files                            plumbinginterrogators
+git-ls-remote                           plumbinginterrogators
+git-ls-tree                             plumbinginterrogators
+git-mailinfo                            purehelpers
+git-mailsplit                           purehelpers
+git-merge-base                          plumbinginterrogators
+git-merge-file                          plumbingmanipulators
+git-merge-index                         plumbingmanipulators
+git-merge                               mainporcelain
+git-merge-one-file                      purehelpers
+git-merge-tree                          ancillaryinterrogators
+git-mergetool                           ancillarymanipulators
+git-mktag                               plumbingmanipulators
+git-mktree                              plumbingmanipulators
+git-mv                                  mainporcelain
+git-name-rev                            plumbinginterrogators
+git-pack-objects                        plumbingmanipulators
+git-pack-redundant                      plumbinginterrogators
+git-pack-refs                           ancillarymanipulators
+git-parse-remote                        synchelpers
+git-patch-id                            purehelpers
+git-peek-remote                         purehelpers
+git-prune                               ancillarymanipulators
+git-prune-packed                        plumbingmanipulators
+git-pull                                mainporcelain
+git-push                                mainporcelain
+git-quiltimport                         foreignscminterface
+git-read-tree                           plumbingmanipulators
+git-rebase                              mainporcelain
+git-receive-pack                        synchelpers
+git-reflog                              ancillarymanipulators
+git-relink                              ancillarymanipulators
+git-repack                              ancillarymanipulators
+git-config                              ancillarymanipulators
+git-remote                              ancillarymanipulators
+git-request-pull                        foreignscminterface
+git-rerere                              ancillaryinterrogators
+git-reset                               mainporcelain
+git-revert                              mainporcelain
+git-rev-list                            plumbinginterrogators
+git-rev-parse                           ancillaryinterrogators
+git-rm                                  mainporcelain
+git-runstatus                           ancillaryinterrogators
+git-send-email                          foreignscminterface
+git-send-pack                           synchingrepositories
+git-shell                               synchelpers
+git-shortlog                            mainporcelain
+git-show                                mainporcelain
+git-show-branch                         ancillaryinterrogators
+git-show-index                          plumbinginterrogators
+git-show-ref                            plumbinginterrogators
+git-sh-setup                            purehelpers
+git-ssh-fetch                           synchingrepositories
+git-ssh-upload                          synchingrepositories
+git-status                              mainporcelain
+git-stripspace                          purehelpers
+git-svn                                 foreignscminterface
+git-svnimport                           foreignscminterface
+git-symbolic-ref                        plumbingmanipulators
+git-tag                                 mainporcelain
+git-tar-tree                            plumbinginterrogators
+git-unpack-file                         plumbinginterrogators
+git-unpack-objects                      plumbingmanipulators
+git-update-index                        plumbingmanipulators
+git-update-ref                          plumbingmanipulators
+git-update-server-info                  synchingrepositories
+git-upload-archive                      synchelpers
+git-upload-pack                         synchelpers
+git-var                                 plumbinginterrogators
+git-verify-pack                         plumbinginterrogators
+git-verify-tag                          ancillaryinterrogators
+git-whatchanged                         ancillaryinterrogators
+git-write-tree                          plumbingmanipulators
diff --git a/Documentation/config.txt b/Documentation/config.txt
new file mode 100644 (file)
index 0000000..24f9655
--- /dev/null
@@ -0,0 +1,655 @@
+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 "ssh://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 gitlink:git-update-index[1]. True by default.
+
+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.symlinks::
+       If false, symbolic links are checked out as small plain files that
+       contain the link text. gitlink:git-update-index[1] and
+       gitlink: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::
+       The working copy files are assumed to stay unchanged until you
+       mark them otherwise manually - Git will not detect the file changes
+       by lstat() calls. This is useful on systems where those are very
+       slow, such as Microsoft Windows.  See gitlink:git-update-index[1].
+       False by default.
+
+core.preferSymlinkRefs::
+       Instead of the default "symref" format for HEAD
+       and other symbolic reference files, use symbolic links.
+       This is sometimes needed to work with old scripts that
+       expect HEAD to be a symbolic link.
+
+core.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 gitlink:git-add[1] or gitlink:git-merge[1].
++
+This setting is automatically guessed by gitlink:git-clone[1] or
+gitlink: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.logAllRefUpdates::
+       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). See gitlink: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 the compression level for objects that
+       are not in a pack file. -1 is the zlib and git default. 0 means no
+       compression, and 1..9 are various speed/size tradeoffs, 9 being
+       slowest.
+
+core.legacyheaders::
+       A boolean which
+       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 versions of git over dumb transports (e.g. http)
+       will also be affected.
++
+To let git use the new loose object format, you have to
+set core.legacyheaders to false.
+
+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.
+
+alias.*::
+       Command aliases for the gitlink:git[1] command wrapper - e.g.
+       after defining "alias.last = cat-file commit HEAD", the invocation
+       "git last" is equivalent to "git cat-file commit HEAD". To avoid
+       confusion and troubles with script usage, aliases that
+       hide existing git commands are ignored. Arguments are split by
+       spaces, the usual shell quoting and escaping is supported.
+       quote pair and a backslash can be used to quote them.
+
+       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 gitlink:git-apply[1].
+
+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 has exactly to match
+       a remote part of one of the refspecs which are 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.
+
+clean.requireForce::
+       A boolean to make git-clean do nothing unless given -f or -n.  Defaults
+       to false.
+
+color.branch::
+       A boolean to enable/disable color in the output of
+       gitlink:git-branch[1]. May be set to `true` (or `always`),
+       `false` (or `never`) or `auto`, 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 true (or `always`), always use colors in patch.
+       When false (or `never`), never.  When set to `auto`, use
+       colors only when the output is to the terminal.
+
+color.diff.<slot>::
+       Use customized color for diff colorization.  `<slot>` specifies
+       which part of the patch to use the specified color, and is one
+       of `plain` (context text), `meta` (metainformation), `frag`
+       (hunk header), `old` (removed lines), `new` (added lines),
+       `commit` (commit headers), or `whitespace` (highlighting dubious
+       whitespace).  The values of these variables may be specified as
+       in color.branch.<slot>.
+
+color.pager::
+       A boolean to enable/disable colored output when the pager is in
+       use (default is true).
+
+color.status::
+       A boolean to enable/disable color in the output of
+       gitlink:git-status[1]. May be set to `true` (or `always`),
+       `false` (or `never`) or `auto`, 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),
+       or `untracked` (files which are not tracked by git). The values of
+       these variables may be specified as in color.branch.<slot>.
+
+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.
+
+format.headers::
+       Additional email headers to include in a patch to be submitted
+       by mail.  See gitlink: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).
+
+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.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 gitlink: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 gitlink:git-rerere[1].
+
+gitcvs.enabled::
+       Whether the cvs server interface is enabled for this repository.
+       See gitlink:git-cvsserver[1].
+
+gitcvs.logfile::
+       Path to a log file where the cvs server interface well... logs
+       various stuff. See gitlink:git-cvsserver[1].
+
+gitcvs.allbinary::
+       If true, all files are sent to the client in mode '-kb'. This
+       causes the client to treat all files as binary files which suppresses
+       any newline munging it otherwise might do. A work-around for the
+       fact that there is no way yet to set single files to mode '-kb'.
+
+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
+       gitlink: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 gitlink: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
+       gitlink:git-cvsserver[1] for details).
+
+All gitcvs variables except for 'gitcvs.allbinary' can also specifed
+as 'gitcvs.<access_method>.<varname>' (where 'access_method' is one
+of "ext" and "pserver") to make them apply only for the given access
+method.
+
+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. gitlink:git-mailinfo[1]. Defaults to 'utf-8'.
+
+i18n.logOutputEncoding::
+       Character encoding the commit messages are converted to when
+       running `git-log` and friends.
+
+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 gitlink:git-log[1] or gitlink:git-whatchanged[1], which
+       normally hide the root commit will now show it. True by default.
+
+merge.summary::
+       Whether to include summaries of merged commits in newly created
+       merge commit messages. False by default.
+
+merge.tool::
+       Controls which merge resolution program is used by
+       gitlink:git-mergetool[l].  Valid values are: "kdiff3", "tkdiff",
+       "meld", "xxdiff", "emerge", "vimdiff", and "opendiff"
+
+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.
+
+merge.<driver>.name::
+       Defines a human readable name for a custom low-level
+       merge driver.  See gitlink:gitattributes[5] for details.
+
+merge.<driver>.driver::
+       Defines the command that implements a custom low-level
+       merge driver.  See gitlink: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 gitlink:gitattributes[5] for details.
+
+pack.window::
+       The size of the window used by gitlink:git-pack-objects[1] when no
+       window size is given on the command line. Defaults to 10.
+
+pull.octopus::
+       The default merge strategy to use when pulling multiple branches
+       at once.
+
+pull.twohead::
+       The default merge strategy to use when pulling a single branch.
+
+remote.<name>.url::
+       The URL of a remote repository.  See gitlink:git-fetch[1] or
+       gitlink:git-push[1].
+
+remote.<name>.fetch::
+       The default set of "refspec" for gitlink:git-fetch[1]. See
+       gitlink:git-fetch[1].
+
+remote.<name>.push::
+       The default set of "refspec" for gitlink:git-push[1]. See
+       gitlink:git-push[1].
+
+remote.<name>.skipDefaultUpdate::
+       If true, this remote will be skipped by default when updating
+       using the remote subcommand of gitlink:git-remote[1].
+
+remote.<name>.receivepack::
+       The default program to execute on the remote side when pushing.  See
+       option \--exec of gitlink:git-push[1].
+
+remote.<name>.uploadpack::
+       The default program to execute on the remote side when fetching.  See
+       option \--exec of gitlink: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 gitlink:git-remote[1].
+
+repack.usedeltabaseoffset::
+       Allow gitlink:git-repack[1] to create packs that uses
+       delta-base offset.  Defaults to false.
+
+show.difftree::
+       The default gitlink:git-diff-tree[1] arguments to be used
+       for gitlink:git-show[1].
+
+showbranch.default::
+       The default set of branches for gitlink:git-show-branch[1].
+       See gitlink:git-show-branch[1].
+
+tar.umask::
+       By default, gitlink:git-tar-tree[1] sets file and directories modes
+       to 0666 or 0777. While this is both useful and acceptable for projects
+       such as the Linux Kernel, it might be excessive for other projects.
+       With this variable, it becomes possible to tell
+       gitlink:git-tar-tree[1] to apply a specific umask to the modes above.
+       The special value "user" indicates that the user's current umask will
+       be used. This should be enough for most projects, as it will lead to
+       the same permissions as gitlink:git-checkout[1] would use. The default
+       value remains 0, which means world read-write.
+
+user.email::
+       Your email address to be recorded in any newly created commits.
+       Can be overridden by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and
+       'EMAIL' environment variables.  See gitlink:git-commit-tree[1].
+
+user.name::
+       Your full name to be recorded in any newly created commits.
+       Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME'
+       environment variables.  See gitlink:git-commit-tree[1].
+
+user.signingkey::
+       If gitlink: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 gitlink:git-diff-tree[1] arguments to be used
+       for gitlink:git-whatchanged[1].
+
+imap::
+       The configuration variables in the 'imap' section are described
+       in gitlink:git-imap-send[1].
+
+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.
+
+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.
+
+
diff --git a/Documentation/core-intro.txt b/Documentation/core-intro.txt
new file mode 100644 (file)
index 0000000..eea44d9
--- /dev/null
@@ -0,0 +1,592 @@
+////////////////////////////////////////////////////////////////
+
+       GIT - the stupid content tracker
+
+////////////////////////////////////////////////////////////////
+
+"git" can mean anything, depending on your mood.
+
+ - random three-letter combination that is pronounceable, and not
+   actually used by any common UNIX command.  The fact that it is a
+   mispronunciation of "get" may or may not be relevant.
+ - stupid. contemptible and despicable. simple. Take your pick from the
+   dictionary of slang.
+ - "global information tracker": you're in a good mood, and it actually
+   works for you. Angels sing, and a light suddenly fills the room.
+ - "goddamn idiotic truckload of sh*t": when it breaks
+
+This is a (not so) stupid but extremely fast directory content manager.
+It doesn't do a whole lot at its core, but what it 'does' do is track
+directory contents efficiently.
+
+There are two object abstractions: the "object database", and the
+"current directory cache" aka "index".
+
+The Object Database
+~~~~~~~~~~~~~~~~~~~
+The object database is literally just a content-addressable collection
+of objects.  All objects are named by their content, which is
+approximated by the SHA1 hash of the object itself.  Objects may refer
+to other objects (by referencing their SHA1 hash), and so you can
+build up a hierarchy of objects.
+
+All objects have a statically determined "type" aka "tag", which is
+determined at object creation time, and 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".
+
+A "blob" object cannot refer to any other object, and is, like the type
+implies, a pure storage object containing some user data.  It is used to
+actually store the file data, i.e. a blob object is associated with some
+particular version of some file.
+
+A "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 "commit" object ties such directory hierarchies together into
+a DAG of revisions - each "commit" is associated with exactly one tree
+(the directory hierarchy at the time of the commit). In addition, a
+"commit" refers to one or more "parent" commit objects that describe the
+history of how we arrived at that directory hierarchy.
+
+As a special case, a commit object with no parents is called the "root"
+object, and is the point of an initial project commit.  Each project
+must have at least one root, and while you can tie several different
+root objects together into one project by creating a commit object which
+has two or more separate roots as its ultimate parents, that's probably
+just going to confuse people.  So aim for the notion of "one root object
+per project", even if git itself does not enforce that.
+
+A "tag" object symbolically identifies and can be used to sign other
+objects. It contains the identifier and type of another object, a
+symbolic name (of course!) and, optionally, a signature.
+
+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> + <space> + <ascii decimal
+size> + <byte\0> + <binary object data>.
+
+The structured objects can further have their structure and
+connectivity to other objects verified. This is generally done with
+the `git-fsck` 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).
+
+The object types in some more detail:
+
+Blob Object
+~~~~~~~~~~~
+A "blob" object is nothing but a binary blob of data, and doesn't
+refer to anything else.  There is no signature or any other
+verification of the data, so while the object is consistent (it 'is'
+indexed by its sha1 hash, so the data itself is certainly correct), it
+has absolutely no other attributes.  No name associations, no
+permissions.  It is purely a blob of data (i.e. normally "file
+contents").
+
+In particular, 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 in any way.
+
+A blob is typically created when gitlink:git-update-index[1]
+(or gitlink:git-add[1]) is run, and its data can be accessed by
+gitlink:git-cat-file[1].
+
+Tree Object
+~~~~~~~~~~~
+The next hierarchical object type is the "tree" object.  A tree object
+is a list of mode/name/blob data, sorted by name.  Alternatively, the
+mode data may specify a directory mode, in which case instead of
+naming a blob, that name is associated with another TREE object.
+
+Like the "blob" object, a tree object is uniquely determined by the
+set contents, and so two separate but identical trees will always
+share the exact same object. This is true at all levels, i.e. it's
+true for a "leaf" tree (which does not refer to any other trees, only
+blobs) as well as for a whole subdirectory.
+
+For that reason a "tree" object is just a pure data abstraction: it
+has no history, no signatures, no verification of validity, except
+that since the contents are again protected by the hash itself, we can
+trust that the tree is immutable and its contents never change.
+
+So you can trust the contents of a tree to be valid, the same way you
+can trust the contents of a blob, but you don't know where those
+contents 'came' from.
+
+Side note on trees: since a "tree" object is a sorted list of
+"filename+content", you can create a diff between two trees without
+actually having to unpack two trees.  Just ignore all common parts,
+and your diff will look right.  In other words, you can effectively
+(and efficiently) tell the difference between any two random trees by
+O(n) where "n" is the size of the difference, rather than the size of
+the tree.
+
+Side note 2 on trees: since the name of a "blob" depends entirely and
+exclusively on its contents (i.e. there are no names or permissions
+involved), you can see trivial renames or permission changes by
+noticing that the blob stayed the same.  However, renames with data
+changes need a smarter "diff" implementation.
+
+A tree is created with gitlink:git-write-tree[1] and
+its data can be accessed by gitlink:git-ls-tree[1].
+Two trees can be compared with gitlink:git-diff-tree[1].
+
+Commit Object
+~~~~~~~~~~~~~
+The "commit" object is an object that introduces the notion of
+history into the picture.  In contrast to the other objects, it
+doesn't just describe the physical state of a tree, it describes how
+we got there, and why.
+
+A "commit" is defined by the tree-object that it results in, the
+parent commits (zero, one or more) that led up to that point, and a
+comment on what happened.  Again, a commit is not trusted per se:
+the contents are well-defined and "safe" due to the cryptographically
+strong signatures at all levels, but there is no reason to believe
+that the tree is "good" or that the merge information makes sense.
+The parents do not have to actually have any relationship with the
+result, for example.
+
+Note on commits: unlike real SCM's, commits do not contain
+rename information or file mode change information.  All of that is
+implicit in the trees involved (the result tree, and the result trees
+of the parents), and describing that makes no sense in this idiotic
+file manager.
+
+A commit is created with gitlink:git-commit-tree[1] and
+its data can be accessed by gitlink:git-cat-file[1].
+
+Trust
+~~~~~
+An aside on the notion of "trust". Trust is really outside the scope
+of "git", but it's worth noting a few things.  First off, since
+everything is hashed with SHA1, you 'can' trust that an object is
+intact and has not been messed with by external sources.  So the name
+of an object uniquely identifies a known state - just not a state that
+you may want to trust.
+
+Furthermore, since the SHA1 signature of a commit refers to the
+SHA1 signatures of the tree it is associated with and the signatures
+of the parent, a single named commit specifies uniquely a whole set
+of history, with full contents.  You can't later fake any step of the
+way once you have the name of a commit.
+
+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
+~~~~~~~~~~
+Git provides the "tag" object to simplify creating, managing and
+exchanging symbolic and signed tokens.  The "tag" object at its
+simplest simply symbolically identifies another object by containing
+the sha1, type and symbolic name.
+
+However it can optionally contain additional signature information
+(which git doesn't care about as long as there's less than 8k of
+it). This can then be verified externally to git.
+
+Note that despite the tag features, "git" itself only handles content
+integrity; the trust framework (and signature provision and
+verification) has to come from outside.
+
+A tag is created with gitlink:git-mktag[1],
+its data can be accessed by gitlink:git-cat-file[1],
+and the signature can be verified by
+gitlink:git-verify-tag[1].
+
+
+The "index" aka "Current Directory Cache"
+-----------------------------------------
+The index is a simple binary file, which contains an efficient
+representation of a virtual directory content at some random time.  It
+does so by a simple array that associates a set of names, dates,
+permissions and content (aka "blob") objects together.  The cache is
+always kept ordered by name, and names are unique (with a few very
+specific rules) at any point in time, but the cache has no long-term
+meaning, and can be partially updated at any time.
+
+In particular, the index certainly does not need to be consistent with
+the current directory contents (in fact, most operations will depend on
+different ways to make the index 'not' be consistent with the directory
+hierarchy), but it has three very important attributes:
+
+'(a) it can re-generate the full state it caches (not just the
+directory structure: it contains pointers to the "blob" objects so
+that it can regenerate the data too)'
+
+As a special case, there is a clear and unambiguous one-way mapping
+from a current directory cache to a "tree object", which can be
+efficiently created from just the current directory cache without
+actually looking at any other data.  So a directory cache at any one
+time uniquely specifies one and only one "tree" object (but has
+additional data to make it easy to match up that tree object with what
+has happened in the directory)
+
+'(b) it has efficient methods for finding inconsistencies between that
+cached state ("tree object waiting to be instantiated") and the
+current state.'
+
+'(c) it can additionally 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.'
+
+Those are the three ONLY things that the directory cache does.  It's a
+cache, and the normal operation is to re-generate it completely from a
+known tree object, or update/compare it with a live tree that is being
+developed.  If you blow the directory cache away entirely, you generally
+haven't lost any information as long as you have the name of the tree
+that it described.
+
+At the same time, the index is at the same time also the
+staging area for creating new trees, and creating a new tree always
+involves a controlled modification of the index file.  In particular,
+the index file can have the representation of an intermediate tree that
+has not yet been instantiated.  So the index can be thought of as a
+write-back cache, which can contain dirty information that has not yet
+been written back to the backing store.
+
+
+
+The Workflow
+------------
+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 to and from the index file. Either
+from the database or from the working directory. Thus there are four
+main combinations:
+
+1) working directory -> index
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You update the index with information from the working directory with
+the gitlink:git-update-index[1] command.  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-cache 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.
+
+2) 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:
+
+3) 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.
+
+4) 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:
+
+5) 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 |
+                    +-----------+
+
+------------
+
+
+6) 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
+gitlink: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.
+
+7) 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 case, 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`.
+
+Historical note.  We did not have `-u` facility when this
+section was first written, so we used to warn that
+the merge is done in the index file, not in your
+working tree, and your working tree will not match your
+index after this step.
+This is no longer true.  The above command, thanks to `-u`
+option, updates your working tree with the merge results for
+paths that have been trivially merged.
+
+
+8) 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` or `merge`, 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
+$ merge 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.
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
new file mode 100644 (file)
index 0000000..6b9b9ad
--- /dev/null
@@ -0,0 +1,1690 @@
+A git core tutorial for developers
+==================================
+
+Introduction
+------------
+
+This is trying to be a short tutorial on setting up and using a git
+repository, mainly because being hands-on and using explicit examples is
+often the best way of explaining what is going on.
+
+In normal life, most people wouldn't use the "core" git programs
+directly, but rather script around them to make them more palatable. 
+Understanding the core git stuff may help some people get those scripts
+done, though, and it may also be instructive in helping people
+understand what it is that the higher-level helper scripts are actually
+doing. 
+
+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.
+
+The material presented here often goes deep describing how things
+work internally.  If you are mostly interested in using git as a
+SCM, you can skip them during your first pass.
+
+[NOTE]
+And those "too deep" descriptions are often marked as Note.
+
+[NOTE]
+If you are already familiar with another version control system,
+like CVS, you may want to take a look at
+link:everyday.html[Everyday GIT in 20 commands or so] first
+before reading this.
+
+
+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
+link:repository-layout.html[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