Merge http://www.kernel.org/pub/scm/gitk/gitk
authorJunio C Hamano <junkio@cox.net>
Thu, 27 Oct 2005 07:14:46 +0000 (00:14 -0700)
committerJunio C Hamano <junkio@cox.net>
Thu, 27 Oct 2005 07:14:46 +0000 (00:14 -0700)
398 files changed:
.gitignore [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/SubmittingPatches [new file with mode: 0644]
Documentation/asciidoc.conf [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/git-add.txt [new file with mode: 0644]
Documentation/git-am.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-bisect.txt [new file with mode: 0644]
Documentation/git-branch.txt [new file with mode: 0644]
Documentation/git-cat-file.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-clone-pack.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-convert-objects.txt [new file with mode: 0644]
Documentation/git-count-objects.txt [new file with mode: 0644]
Documentation/git-cvsimport.txt [new file with mode: 0644]
Documentation/git-daemon.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-stages.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-fetch-pack.txt [new file with mode: 0644]
Documentation/git-fetch.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-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-index-pack.txt [new file with mode: 0644]
Documentation/git-init-db.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-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-index.txt [new file with mode: 0644]
Documentation/git-merge-one-file.txt [new file with mode: 0644]
Documentation/git-merge.txt [new file with mode: 0644]
Documentation/git-mktag.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-octopus.txt [new file with mode: 0644]
Documentation/git-pack-objects.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-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-relink.txt [new file with mode: 0644]
Documentation/git-rename.txt [new file with mode: 0644]
Documentation/git-repack.txt [new file with mode: 0644]
Documentation/git-request-pull.txt [new file with mode: 0644]
Documentation/git-reset.txt [new file with mode: 0644]
Documentation/git-resolve.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-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-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-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-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-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/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/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/using-topic-branches.txt [new file with mode: 0644]
Documentation/install-webdoc.sh [new file with mode: 0755]
Documentation/pack-protocol.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/sort_glossary.pl [new file with mode: 0644]
Documentation/technical/trivial-merge.txt [new file with mode: 0644]
Documentation/tutorial.txt [new file with mode: 0644]
INSTALL [new file with mode: 0644]
Makefile [new file with mode: 0644]
README [new file with mode: 0644]
apply.c [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]
blob.c [new file with mode: 0644]
blob.h [new file with mode: 0644]
cache.h [new file with mode: 0644]
cat-file.c [new file with mode: 0644]
check-ref-format.c [new file with mode: 0644]
checkout-index.c [new file with mode: 0644]
clone-pack.c [new file with mode: 0644]
cmd-rename.sh [new file with mode: 0755]
commit-tree.c [new file with mode: 0644]
commit.c [new file with mode: 0644]
commit.h [new file with mode: 0644]
compat/mmap.c [new file with mode: 0644]
compat/strcasestr.c [new file with mode: 0644]
compat/subprocess.py [new file with mode: 0644]
config.c [new file with mode: 0644]
connect.c [new file with mode: 0644]
convert-objects.c [new file with mode: 0644]
copy.c [new file with mode: 0644]
count-delta.c [new file with mode: 0644]
count-delta.h [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]
debian/.gitignore [new file with mode: 0644]
debian/changelog [new file with mode: 0644]
debian/compat [new file with mode: 0644]
debian/control [new file with mode: 0644]
debian/copyright [new file with mode: 0644]
debian/docs [new file with mode: 0644]
debian/git-core.doc-base [new file with mode: 0644]
debian/git-core.files [new file with mode: 0644]
debian/git-tk.files [new file with mode: 0644]
debian/rules [new file with mode: 0755]
delta.h [new file with mode: 0644]
diff-delta.c [new file with mode: 0644]
diff-files.c [new file with mode: 0644]
diff-index.c [new file with mode: 0644]
diff-stages.c [new file with mode: 0644]
diff-tree.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-order.c [new file with mode: 0644]
diffcore-pathspec.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]
entry.c [new file with mode: 0644]
environment.c [new file with mode: 0644]
epoch.c [new file with mode: 0644]
epoch.h [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]
fsck-objects.c [new file with mode: 0644]
get-tar-commit-id.c [new file with mode: 0644]
git-add.sh [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-branch.sh [new file with mode: 0755]
git-checkout.sh [new file with mode: 0755]
git-cherry.sh [new file with mode: 0755]
git-clone.sh [new file with mode: 0755]
git-commit.sh [new file with mode: 0755]
git-core.spec.in [new file with mode: 0644]
git-count-objects.sh [new file with mode: 0755]
git-cvsimport.perl [new file with mode: 0755]
git-diff.sh [new file with mode: 0755]
git-fetch.sh [new file with mode: 0755]
git-findtags.perl [new file with mode: 0755]
git-fmt-merge-msg.perl [new file with mode: 0755]
git-format-patch.sh [new file with mode: 0755]
git-grep.sh [new file with mode: 0755]
git-log.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-recursive.py [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-mv.perl [new file with mode: 0755]
git-octopus.sh [new file with mode: 0755]
git-parse-remote.sh [new file with mode: 0755]
git-prune.sh [new file with mode: 0755]
git-pull.sh [new file with mode: 0755]
git-push.sh [new file with mode: 0755]
git-rebase.sh [new file with mode: 0755]
git-relink.perl [new file with mode: 0755]
git-rename.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-resolve.sh [new file with mode: 0755]
git-revert.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-shortlog.perl [new file with mode: 0755]
git-status.sh [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-whatchanged.sh [new file with mode: 0755]
git.sh [new file with mode: 0755]
gitMergeCommon.py [new file with mode: 0644]
hash-object.c [new file with mode: 0644]
http-fetch.c [new file with mode: 0644]
ident.c [new file with mode: 0644]
index-pack.c [new file with mode: 0644]
index.c [new file with mode: 0644]
init-db.c [new file with mode: 0644]
local-fetch.c [new file with mode: 0644]
ls-files.c [new file with mode: 0644]
ls-tree.c [new file with mode: 0644]
mailinfo.c [new file with mode: 0644]
mailsplit.c [new file with mode: 0644]
merge-base.c [new file with mode: 0644]
merge-index.c [new file with mode: 0644]
mktag.c [new file with mode: 0644]
mozilla-sha1/sha1.c [new file with mode: 0644]
mozilla-sha1/sha1.h [new file with mode: 0644]
name-rev.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-objects.c [new file with mode: 0644]
pack.h [new file with mode: 0644]
patch-delta.c [new file with mode: 0644]
patch-id.c [new file with mode: 0644]
path.c [new file with mode: 0644]
peek-remote.c [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]
prune-packed.c [new file with mode: 0644]
quote.c [new file with mode: 0644]
quote.h [new file with mode: 0644]
read-cache.c [new file with mode: 0644]
read-tree.c [new file with mode: 0644]
receive-pack.c [new file with mode: 0644]
refs.c [new file with mode: 0644]
refs.h [new file with mode: 0644]
rev-list.c [new file with mode: 0644]
rev-parse.c [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]
shell.c [new file with mode: 0644]
show-branch.c [new file with mode: 0644]
show-index.c [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]
stripspace.c [new file with mode: 0644]
symbolic-ref.c [new file with mode: 0644]
t/Makefile [new file with mode: 0644]
t/README [new file with mode: 0644]
t/diff-lib.sh [new file with mode: 0755]
t/lib-read-tree-m-3way.sh [new file with mode: 0755]
t/t0000-basic.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/t1100-commit-tree-options.sh [new file with mode: 0755]
t/t1200-tutorial.sh [new file with mode: 0644]
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/t2100-update-cache-badpath.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/t3100-ls-tree-restrict.sh [new file with mode: 0755]
t/t3101-ls-tree-dirname.sh [new file with mode: 0644]
t/t3200-branch.sh [new file with mode: 0755]
t/t3300-funny-names.sh [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/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/t4102-apply-rename.sh [new file with mode: 0755]
t/t4109-apply-multifrag.sh [new file with mode: 0644]
t/t4110-apply-scan.sh [new file with mode: 0644]
t/t4112-apply-renames.sh [new file with mode: 0755]
t/t5000-tar-tree.sh [new file with mode: 0755]
t/t5300-pack-object.sh [new file with mode: 0755]
t/t5400-send-pack.sh [new file with mode: 0755]
t/t6000lib.sh [new file with mode: 0755]
t/t6001-rev-list-merge-order.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/t6101-rev-parse-parents.sh [new file with mode: 0644]
t/test-lib.sh [new file with mode: 0755]
tag.c [new file with mode: 0644]
tag.h [new file with mode: 0644]
tar-tree.c [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-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--update [new file with mode: 0644]
templates/info--exclude [new file with mode: 0644]
templates/remotes-- [new file with mode: 0644]
templates/this--description [new file with mode: 0644]
test-date.c [new file with mode: 0644]
test-delta.c [new file with mode: 0644]
tree-diff.c [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-objects.c [new file with mode: 0644]
update-index.c [new file with mode: 0644]
update-ref.c [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]
var.c [new file with mode: 0644]
verify-pack.c [new file with mode: 0644]
write-tree.c [new file with mode: 0644]

diff --git a/.gitignore b/.gitignore
new file mode 100644 (file)
index 0000000..52cb9e2
--- /dev/null
@@ -0,0 +1,112 @@
+git
+git-add
+git-am
+git-apply
+git-applymbox
+git-applypatch
+git-archimport
+git-bisect
+git-branch
+git-cat-file
+git-check-ref-format
+git-checkout
+git-checkout-index
+git-cherry
+git-cherry-pick
+git-clone
+git-clone-pack
+git-commit
+git-commit-tree
+git-convert-objects
+git-count-objects
+git-cvsimport
+git-daemon
+git-diff
+git-diff-files
+git-diff-index
+git-diff-stages
+git-diff-tree
+git-fetch
+git-fetch-pack
+git-findtags
+git-fmt-merge-msg
+git-format-patch
+git-fsck-objects
+git-get-tar-commit-id
+git-grep
+git-hash-object
+git-http-fetch
+git-index-pack
+git-init-db
+git-local-fetch
+git-log
+git-ls-files
+git-ls-remote
+git-ls-tree
+git-mailinfo
+git-mailsplit
+git-merge
+git-merge-base
+git-merge-index
+git-merge-octopus
+git-merge-one-file
+git-merge-recursive
+git-merge-resolve
+git-merge-stupid
+git-mktag
+git-octopus
+git-pack-objects
+git-parse-remote
+git-patch-id
+git-peek-remote
+git-prune
+git-prune-packed
+git-pull
+git-push
+git-read-tree
+git-rebase
+git-receive-pack
+git-relink
+git-rename
+git-repack
+git-request-pull
+git-reset
+git-resolve
+git-rev-list
+git-rev-parse
+git-revert
+git-send-email
+git-send-pack
+git-sh-setup
+git-shortlog
+git-show-branch
+git-show-index
+git-ssh-fetch
+git-ssh-pull
+git-ssh-push
+git-ssh-upload
+git-status
+git-stripspace
+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-pack
+git-var
+git-verify-pack
+git-verify-tag
+git-whatchanged
+git-write-tree
+git-core-*/?*
+*.tar.gz
+*.dsc
+*.deb
+git-core.spec
+*.exe
+libgit.a
+*.o
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..dad52b8
--- /dev/null
@@ -0,0 +1,5 @@
+*.xml
+*.html
+*.1
+*.7
+howto-index.txt
diff --git a/Documentation/Makefile b/Documentation/Makefile
new file mode 100644 (file)
index 0000000..3cfa360
--- /dev/null
@@ -0,0 +1,96 @@
+MAN1_TXT=$(wildcard git-*.txt) gitk.txt
+MAN7_TXT=git.txt
+
+DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT))
+
+ARTICLES = tutorial
+ARTICLES += cvs-migration
+ARTICLES += diffcore
+ARTICLES += howto-index
+ARTICLES += repository-layout
+ARTICLES += hooks
+# with their own formatting rules.
+SP_ARTICLES = glossary howto/revert-branch-rebase
+
+DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES))
+
+DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT))
+DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
+
+prefix?=$(HOME)
+bin=$(prefix)/bin
+mandir=$(prefix)/man
+man1=$(mandir)/man1
+man7=$(mandir)/man7
+# DESTDIR=
+
+INSTALL?=install
+
+#
+# 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)
+
+
+man: man1 man7
+man1: $(DOC_MAN1)
+man7: $(DOC_MAN7)
+
+install: man
+       $(INSTALL) -d -m755 $(DESTDIR)/$(man1) $(DESTDIR)/$(man7)
+       $(INSTALL) $(DOC_MAN1) $(DESTDIR)/$(man1)
+       $(INSTALL) $(DOC_MAN7) $(DESTDIR)/$(man7)
+
+# 'include' dependencies
+$(patsubst %.txt,%.1,$(wildcard git-diff-*.txt)): \
+       diff-format.txt diff-options.txt
+$(patsubst %,%.1,git-fetch git-pull git-push): pull-fetch-param.txt
+$(patsubst %.txt,%.html,$(wildcard git-diff-*.txt)): \
+       diff-format.txt diff-options.txt
+$(patsubst %,%.html,git-fetch git-pull git-push): pull-fetch-param.txt
+git.7: ../README
+
+clean:
+       rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html
+
+%.html : %.txt
+       asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
+
+%.1 %.7 : %.xml
+       xmlto man $<
+
+%.xml : %.txt
+       asciidoc -b docbook -d manpage -f asciidoc.conf $<
+
+git.html: git.txt ../README
+
+glossary.html : glossary.txt sort_glossary.pl
+       cat $< | \
+       perl sort_glossary.pl | \
+       asciidoc -b xhtml11 - > glossary.html
+
+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)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
new file mode 100644 (file)
index 0000000..9ccb8f7
--- /dev/null
@@ -0,0 +1,298 @@
+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, 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 long, that's a sign that you
+probably need to split up your commit to finer grained pieces.
+
+
+(2) Generate your patch using git/cogito out of your commits.
+
+git diff tools 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.
+
+
+(3) Sending your patches.
+
+People on the git mailing list needs to be able to read and
+comment on the changes you are submitting.  It is important for
+a developer to be able to "quote" your changes, using standard
+e-mail tools, so that they may comment on specific portions of
+your code.  For this reason, all patches should be submitting
+e-mail "inline".  WARNING: Be wary of your MUAs word-wrap
+corrupting your patch.  Do not cut-n-paste your patch.
+
+It is 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.  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.
+
+
+(6) 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>
+
+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.5.4
+               http://extensionroom.mozdev.org/more-info/exteditor
+
+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
+
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
new file mode 100644 (file)
index 0000000..fa0877d
--- /dev/null
@@ -0,0 +1,26 @@
+## 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=^
+
+ifdef::backend-docbook[]
+[gitlink-inlinemacro]
+{0%{target}}
+{0#<citerefentry>}
+{0#<refentrytitle>{target}</refentrytitle><manvolnum>{0}</manvolnum>}
+{0#</citerefentry>}
+endif::backend-docbook[]
+
+ifdef::backend-xhtml11[]
+[gitlink-inlinemacro]
+<a href="{target}.html">{target}{0?({0})}</a>
+endif::backend-xhtml11[]
+
+
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
new file mode 100644 (file)
index 0000000..57436f0
--- /dev/null
@@ -0,0 +1,247 @@
+git for CVS users
+=================
+
+Ok, so you're a CVS user. That's ok, it's a treatable condition, and the
+first step to recovery is admitting you have a problem. The fact that
+you are reading this file means that you may be well on that path
+already.
+
+The thing about CVS is that it absolutely sucks as a source control
+manager, and you'll thus be happy with almost anything else. git,
+however, may be a bit 'too' different (read: "good") for your taste, and
+does a lot of things differently. 
+
+One particular suckage of CVS is very hard to work around: CVS is
+basically a tool for tracking 'file' history, while git is a tool for
+tracking 'project' history.  This sometimes causes problems if you are
+used to doing very strange things in CVS, in particular if you're doing
+things like making branches of just a subset of the project.  git can't
+track that, since git never tracks things on the level of an individual
+file, only on the whole project level. 
+
+The good news is that most people don't do that, and in fact most sane
+people think it's a bug in CVS that makes it tag (and check in changes)
+one file at a time.  So most projects you'll ever see will use CVS
+'as if' it was sane.  In which case you'll find it very easy indeed to
+move over to git. 
+
+First off: this is not a git tutorial. See
+link:tutorial.html[Documentation/tutorial.txt] for how git
+actually works. This is more of a random collection of gotcha's
+and notes on converting from CVS to git.
+
+Second: CVS has the notion of a "repository" as opposed to the thing
+that you're actually working in (your working directory, or your
+"checked out tree").  git does not have that notion at all, and all git
+working directories 'are' the repositories.  However, you can easily
+emulate the CVS model by having one special "global repository", which
+people can synchronize with.  See details later, but in the meantime
+just keep in mind that with git, every checked out working tree will
+have a full revision control history of its own.
+
+
+Importing a CVS archive
+-----------------------
+
+Ok, you have an old project, and you want to at least give git a chance
+to see how it performs. The first thing you want to do (after you've
+gone through the git tutorial, and generally familiarized yourself with
+how to commit stuff etc in git) is to create a git'ified version of your
+CVS archive.
+
+Happily, that's very easy indeed. git will do it for you, although git
+will need the help of a program called "cvsps":
+
+       http://www.cobite.com/cvsps/
+
+which is not actually related to git at all, but which makes CVS usage
+look almost sane (ie you almost certainly want to have it even if you
+decide to stay with CVS). However, git will want 'at least' version 2.1
+of cvsps (available at the address above), and in fact will currently
+refuse to work with anything else.
+
+Once you've gotten (and installed) cvsps, you may or may not want to get
+any more familiar with it, but make sure it is in your path. After that,
+the magic command line is
+
+       git cvsimport -v -d <cvsroot> -C <destination> <module>
+
+which will do exactly what you'd think it does: it will create a git
+archive of the named CVS module. The new archive will be created in the
+subdirectory named <destination>; it'll be created if it doesn't exist.
+Default is the local directory.
+
+It can take some time to actually do the conversion for a large archive
+since it involves checking out from CVS every revision of every file,
+and the conversion script is reasonably chatty unless you omit the '-v'
+option, but on some not very scientific tests it averaged about twenty
+revisions per second, so a medium-sized project should not take more
+than a couple of minutes.  For larger projects or remote repositories,
+the process may take longer.
+
+After the (initial) import is done, the CVS archive's current head
+revision will be checked out -- thus, you can start adding your own
+changes right away.
+
+The import is incremental, i.e. if you call it again next month it'll
+fetch any CVS updates that have been happening in the meantime. The
+cut-off is date-based, so don't change the branches that were imported
+from CVS.
+
+You can merge those updates (or, in fact, a different CVS branch) into
+your main branch:
+
+       git resolve HEAD origin "merge with current CVS HEAD"
+
+The HEAD revision from CVS is named "origin", not "HEAD", because git
+already uses "HEAD". (If you don't like 'origin', use cvsimport's
+'-o' option to change it.)
+
+
+Emulating CVS behaviour
+-----------------------
+
+
+So, by now you are convinced you absolutely want to work with git, but
+at the same time you absolutely have to have a central repository.
+Step back and think again. Okay, you still need a single central
+repository? There are several ways to go about that:
+
+1. Designate a person responsible to pull all branches. Make the
+repository of this person public, and make every team member
+pull regularly from it.
+
+2. Set up a public repository with read/write access for every team
+member. Use "git pull/push" as you used "cvs update/commit".  Be
+sure that your repository is up to date before pushing, just
+like you used to do with "cvs commit"; your push will fail if
+what you are pushing is not up to date.
+
+3. Make the repository of every team member public. It is the
+responsibility of each single member to pull from every other
+team member.
+
+
+CVS annotate
+------------
+
+So, something has gone wrong, and you don't know whom to blame, and
+you're an ex-CVS user and used to do "cvs annotate" to see who caused
+the breakage. You're looking for the "git annotate", and it's just
+claiming not to find such a script. You're annoyed.
+
+Yes, that's right.  Core git doesn't do "annotate", although it's
+technically possible, and there are at least two specialized scripts out
+there that can be used to get equivalent information (see the git
+mailing list archives for details). 
+
+git has a couple of alternatives, though, that you may find sufficient
+or even superior depending on your use.  One is called "git-whatchanged"
+(for obvious reasons) and the other one is called "pickaxe" ("a tool for
+the software archeologist"). 
+
+The "git-whatchanged" script is a truly trivial script that can give you
+a good overview of what has changed in a file or a directory (or an
+arbitrary list of files or directories).  The "pickaxe" support is an
+additional layer that can be used to further specify exactly what you're
+looking for, if you already know the specific area that changed.
+
+Let's step back a bit and think about the reason why you would
+want to do "cvs annotate a-file.c" to begin with.
+
+You would use "cvs annotate" on a file when you have trouble
+with a function (or even a single "if" statement in a function)
+that happens to be defined in the file, which does not do what
+you want it to do.  And you would want to find out why it was
+written that way, because you are about to modify it to suit
+your needs, and at the same time you do not want to break its
+current callers.  For that, you are trying to find out why the
+original author did things that way in the original context.
+
+Many times, it may be enough to see the commit log messages of
+commits that touch the file in question, possibly along with the
+patches themselves, like this:
+
+       $ git-whatchanged -p a-file.c
+
+This will show log messages and patches for each commit that
+touches a-file.
+
+This, however, may not be very useful when this file has many
+modifications that are not related to the piece of code you are
+interested in.  You would see many log messages and patches that
+do not have anything to do with the piece of code you are
+interested in.  As an example, assuming that you have this piece
+of code that you are interested in in the HEAD version:
+
+       if (frotz) {
+               nitfol();
+       }
+
+you would use git-rev-list and git-diff-tree like this:
+
+       $ git-rev-list HEAD |
+         git-diff-tree --stdin -v -p -S'if (frotz) {
+               nitfol();
+       }'
+
+We have already talked about the "\--stdin" form of git-diff-tree
+command that reads the list of commits and compares each commit
+with its parents.  The git-whatchanged command internally runs
+the equivalent of the above command, and can be used like this:
+
+       $ git-whatchanged -p -S'if (frotz) {
+               nitfol();
+       }'
+
+When the -S option is used, git-diff-tree command outputs
+differences between two commits only if one tree has the
+specified string in a file and the corresponding file in the
+other tree does not.  The above example looks for a commit that
+has the "if" statement in it in a file, but its parent commit
+does not have it in the same shape in the corresponding file (or
+the other way around, where the parent has it and the commit
+does not), and the differences between them are shown, along
+with the commit message (thanks to the -v flag).  It does not
+show anything for commits that do not touch this "if" statement.
+
+Also, in the original context, the same statement might have
+appeared at first in a different file and later the file was
+renamed to "a-file.c".  CVS annotate would not help you to go
+back across such a rename, but git would still help you in such
+a situation.  For that, you can give the -C flag to
+git-diff-tree, like this:
+
+       $ git-whatchanged -p -C -S'if (frotz) {
+               nitfol();
+       }'
+
+When the -C flag is used, file renames and copies are followed.
+So if the "if" statement in question happens to be in "a-file.c"
+in the current HEAD commit, even if the file was originally
+called "o-file.c" and then renamed in an earlier commit, or if
+the file was created by copying an existing "o-file.c" in an
+earlier commit, you will not lose track.  If the "if" statement
+did not change across such a rename or copy, then the commit that
+does rename or copy would not show in the output, and if the
+"if" statement was modified while the file was still called
+"o-file.c", it would find the commit that changed the statement
+when it was in "o-file.c".
+
+NOTE: The current version of "git-diff-tree -C" is not eager
+  enough to find copies, and it will miss the fact that a-file.c
+  was created by copying o-file.c unless o-file.c was somehow
+  changed in the same commit.
+
+You can use the --pickaxe-all flag in addition to the -S flag.
+This causes the differences from all the files contained in
+those two commits, not just the differences between the files
+that contain this changed "if" statement:
+
+       $ git-whatchanged -p -C -S'if (frotz) {
+               nitfol();
+       }' --pickaxe-all
+
+NOTE: This option is called "--pickaxe-all" because -S
+  option is internally called "pickaxe", a tool for software
+  archaeologists.
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
new file mode 100644 (file)
index 0000000..d1d0d2d
--- /dev/null
@@ -0,0 +1,148 @@
+The output format from "git-diff-index", "git-diff-tree" and
+"git-diff-files" are very similar.
+
+These commands all compare two sets of things; what is 
+compared differs:
+
+git-diff-index <tree-ish>::
+        compares the <tree-ish> and the files on the filesystem.
+
+git-diff-index --cached <tree-ish>::
+        compares the <tree-ish> and the cache.
+
+git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>...]::
+        compares the trees named by the two arguments.
+
+git-diff-files [<pattern>...]::
+        compares the cache and the files on the filesystem.
+
+
+An output line is formatted this way:
+
+------------------------------------------------
+in-place edit  :100644 100644 bcd1234... 0123456... M file0
+copy-edit      :100644 100644 abcd123... 1234567... C68 file1 file2
+rename-edit    :100644 100644 abcd123... 1234567... R86 file1 file3
+create         :000000 100644 0000000... 1234567... A file4
+delete         :100644 000000 1234567... 0000000... D file5
+unmerged       :000000 000000 0000000... 0000000... U file6
+------------------------------------------------
+
+That is, from the left to the right:
+
+. a colon.
+. mode for "src"; 000000 if creation or unmerged.
+. a space.
+. mode for "dst"; 000000 if deletion or unmerged.
+. a space.
+. sha1 for "src"; 0\{40\} if creation or unmerged.
+. a space.
+. sha1 for "dst"; 0\{40\} if creation, unmerged or "look at work tree".
+. a space.
+. status, followed by optional "score" number.
+. a tab or a NUL when '-z' option is used.
+. path for "src"
+. a tab or a NUL when '-z' option is used; only exists for C or R.
+. path for "dst"; only exists for C or R.
+. an LF or a NUL when '-z' option is used, to terminate the record.
+
+<sha1> is shown as all 0's if a file is new on the filesystem
+and it is out of sync with the cache.
+
+Example:
+
+------------------------------------------------
+:100644 100644 5be4a4...... 000000...... M file.c
+------------------------------------------------
+
+When `-z` option is not used, TAB, LF, and backslash characters
+in pathnames are represented as `\t`, `\n`, and `\\`,
+respectively.
+
+
+Generating patches with -p
+--------------------------
+
+When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
+with a '-p' option, they do not produce the output described above;
+instead they produce a patch file.
+
+The patch generation can be customized at two levels.
+
+1. When the environment variable 'GIT_EXTERNAL_DIFF' is not set,
+   these commands internally invoke "diff" like this:
+
+      diff -L a/<path> -L b/<path> -pu <old> <new>
++
+For added files, `/dev/null` is used for <old>.  For removed
+files, `/dev/null` is used for <new>
++
+The "diff" formatting options can be customized via the
+environment variable 'GIT_DIFF_OPTS'.  For example, if you
+prefer context diff:
+
+      GIT_DIFF_OPTS=-c git-diff-index -p $(cat .git/HEAD)
+
+
+2. When the environment variable 'GIT_EXTERNAL_DIFF' is set, the
+   program named by it is called, instead of the diff invocation
+   described above.
++
+For a path that is added, removed, or modified,
+'GIT_EXTERNAL_DIFF' is called with 7 parameters:
+
+     path old-file old-hex old-mode new-file new-hex new-mode
++
+where:
+
+     <old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the
+                     contents of <old|new>,
+     <old|new>-hex:: are the 40-hexdigit SHA1 hashes,
+     <old|new>-mode:: are the octal representation of the file modes.
+
++ 
+The file parameters can point at the user's working file
+(e.g. `new-file` in "git-diff-files"), `/dev/null` (e.g. `old-file`
+when a new file is added), or a temporary file (e.g. `old-file` in the
+cache).  'GIT_EXTERNAL_DIFF' should not worry about unlinking the
+temporary file --- it is removed when 'GIT_EXTERNAL_DIFF' exits.
+
+For a path that is unmerged, 'GIT_EXTERNAL_DIFF' is called with 1
+parameter, <path>.
+
+
+git specific extension to diff format
+-------------------------------------
+
+What -p option produces is slightly different from the
+traditional diff format.
+
+1.   It is preceeded with a "git diff" header, that looks like
+     this:
+
+     diff --git a/file1 b/file2
++
+The `a/` and `b/` filenames are the same unless rename/copy is
+involved.  Especially, even for a creation or a deletion,
+`/dev/null` is _not_ used in place of `a/` or `b/` filenames.
++
+When rename/copy is involved, `file1` and `file2` show the
+name of the source file of the rename/copy and the name of
+the file that rename/copy produces, respectively.
+
+2.   It is followed by one or more extended header lines:
+
+       old mode <mode>
+       new mode <mode>
+       deleted file mode <mode>
+       new file mode <mode>
+       copy from <path>
+       copy to <path>
+       rename from <path>
+       rename to <path>
+       similarity index <number>
+       dissimilarity index <number>
+       index <hash>..<hash> <mode>
+
+3.  TAB, LF, and backslash characters in pathnames are
+    represented as `\t`, `\n`, and `\\`, respectively.
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
new file mode 100644 (file)
index 0000000..06500d0
--- /dev/null
@@ -0,0 +1,61 @@
+-p::
+       Generate patch (see section on generating patches)
+
+-u::
+       Synonym for "-p".
+
+-r::
+       Look recursively in subdirectories; only used by "git-diff-tree";
+       other diff commands always work recursively.
+
+-z::
+       \0 line termination on output
+
+--name-only::
+       Show only names of changed files.
+
+--name-status::
+       Show only names and status of changed files.
+
+-B::
+       Break complete rewrite changes into pairs of delete and create.
+
+-M::
+       Detect renames.
+
+-C::
+       Detect copies as well as renames.
+
+--find-copies-harder::
+       For performance reasons, by default, -C option finds copies only 
+       if the original file of the copy was modified in the same 
+       changeset.  This flag makes the command
+       inspect unmodified files as candidates for the source of
+       copy.  This is a very expensive operation for large
+       projects, so use it with caution.
+
+-l<num>::
+       -M and -C options require O(n^2) processing time where n
+       is the number of potential rename/copy targets.  This
+       option prevents rename/copy detection from running if
+       the number of rename/copy targets exceeds the specified
+       number.
+
+-S<string>::
+       Look for differences that contain the change in <string>.
+
+--pickaxe-all::
+       When -S finds a change, show all the changes in that
+       changeset, not just the files that contain the change
+       in <string>.
+
+-O<orderfile>::
+       Output the patch in the order specified in the
+       <orderfile>, which has one shell glob pattern per line.
+
+-R::
+       Swap two inputs; that is, show differences from cache or
+       on-disk file to tree contents.
+
+For more detailed explanation on these common options, see also
+link:diffcore.html[diffcore documentation].
diff --git a/Documentation/diffcore.txt b/Documentation/diffcore.txt
new file mode 100644 (file)
index 0000000..7c2168a
--- /dev/null
@@ -0,0 +1,264 @@
+Tweaking diff output
+====================
+June 2005
+
+
+Introduction
+------------
+
+The diff commands git-diff-index, git-diff-files, and
+git-diff-tree can be told to manipulate differences they find
+in unconventional ways before showing diff(1) output.  The
+manipulation is collectively called "diffcore transformation".
+This short note describes what they are and how to use them to
+produce diff outputs that are easier to understand than the
+conventional kind.
+
+
+The chain of operation
+----------------------
+
+The git-diff-* family works by first comparing two sets of
+files:
+
+ - git-diff-index compares contents of a "tree" object and the
+   working directory (when '\--cached' flag is not used) or a
+   "tree" object and the index file (when '\--cached' flag is
+   used);
+
+ - git-diff-files compares contents of the index file and the
+   working directory;
+
+ - git-diff-tree compares contents of two "tree" objects.
+
+In all of these cases, the commands themselves compare
+corresponding paths in the two sets of files.  The result of
+comparison is passed from these commands to what is internally
+called "diffcore", in a format similar to what is output when
+the -p option is not used.  E.g.
+
+------------------------------------------------
+in-place edit  :100644 100644 bcd1234... 0123456... M file0
+create         :000000 100644 0000000... 1234567... A file4
+delete         :100644 000000 1234567... 0000000... D file5
+unmerged       :000000 000000 0000000... 0000000... U file6
+------------------------------------------------
+
+The diffcore mechanism is fed a list of such comparison results
+(each of which is called "filepair", although at this point each
+of them talks about a single file), and transforms such a list
+into another list.  There are currently 6 such transformations:
+
+- diffcore-pathspec
+- diffcore-break
+- diffcore-rename
+- diffcore-merge-broken
+- diffcore-pickaxe
+- diffcore-order
+
+These are applied in sequence.  The set of filepairs git-diff-\*
+commands find are used as the input to diffcore-pathspec, and
+the output from diffcore-pathspec is used as the input to the
+next transformation.  The final result is then passed to the
+output routine and generates either diff-raw format (see Output
+format sections of the manual for git-diff-\* commands) or
+diff-patch format.
+
+
+diffcore-pathspec
+-----------------
+
+The first transformation in the chain is diffcore-pathspec, and
+is controlled by giving the pathname parameters to the
+git-diff-* commands on the command line.  The pathspec is used
+to limit the world diff operates in.  It removes the filepairs
+outside the specified set of pathnames.
+
+Implementation note.  For performance reasons, git-diff-tree
+uses the pathname parameters on the command line to cull set of
+filepairs it feeds the diffcore mechanism itself, and does not
+use diffcore-pathspec, but the end result is the same.
+
+
+diffcore-break
+--------------
+
+The second transformation in the chain is diffcore-break, and is
+controlled by the -B option to the git-diff-* commands.  This is
+used to detect a filepair that represents "complete rewrite" and
+break such filepair into two filepairs that represent delete and
+create.  E.g.  If the input contained this filepair:
+
+------------------------------------------------
+:100644 100644 bcd1234... 0123456... M file0
+------------------------------------------------
+
+and if it detects that the file "file0" is completely rewritten,
+it changes it to:
+
+------------------------------------------------
+:100644 000000 bcd1234... 0000000... D file0
+:000000 100644 0000000... 0123456... A file0
+------------------------------------------------
+
+For the purpose of breaking a filepair, diffcore-break examines
+the extent of changes between the contents of the files before
+and after modification (i.e. the contents that have "bcd1234..."
+and "0123456..." as their SHA1 content ID, in the above
+example).  The amount of deletion of original contents and
+insertion of new material are added together, and if it exceeds
+the "break score", the filepair is broken into two.  The break
+score defaults to 50% of the size of the smaller of the original
+and the result (i.e. if the edit shrinks the file, the size of
+the result is used; if the edit lengthens the file, the size of
+the original is used), and can be customized by giving a number
+after "-B" option (e.g. "-B75" to tell it to use 75%).
+
+
+diffcore-rename
+---------------
+
+This transformation is used to detect renames and copies, and is
+controlled by the -M option (to detect renames) and the -C option
+(to detect copies as well) to the git-diff-* commands.  If the
+input contained these filepairs:
+
+------------------------------------------------
+:100644 000000 0123456... 0000000... D fileX
+:000000 100644 0000000... 0123456... A file0
+------------------------------------------------
+
+and the contents of the deleted file fileX is similar enough to
+the contents of the created file file0, then rename detection
+merges these filepairs and creates:
+
+------------------------------------------------
+:100644 100644 0123456... 0123456... R100 fileX file0
+------------------------------------------------
+
+When the "-C" option is used, the original contents of modified
+files and contents of unchanged files are considered as
+candidates of the source files in rename/copy operation, in
+addition to the deleted files.  If the input were like these
+filepairs, that talk about a modified file fileY and a newly
+created file file0:
+
+------------------------------------------------
+:100644 100644 0123456... 1234567... M fileY
+:000000 100644 0000000... 0123456... A file0
+------------------------------------------------
+
+the original contents of fileY and the resulting contents of
+file0 are compared, and if they are similar enough, they are
+changed to:
+
+------------------------------------------------
+:100644 100644 0123456... 1234567... M fileY
+:100644 100644 0123456... 0123456... C100 fileY file0
+------------------------------------------------
+
+In both rename and copy detection, the same "extent of changes"
+algorithm used in diffcore-break is used to determine if two
+files are "similar enough", and can be customized to use
+similarity score different from the default 50% by giving a
+number after "-M" or "-C" option (e.g. "-M8" to tell it to use
+8/10 = 80%).
+
+Note.  When the "-C" option is used with `\--find-copies-harder`
+option, git-diff-\* commands feed unmodified filepairs to
+diffcore mechanism as well as modified ones.  This lets the copy
+detector consider unmodified files as copy source candidates at
+the expense of making it slower.  Without `\--find-copies-harder`,
+git-diff-\* commands can detect copies only if the file that was
+copied happened to have been modified in the same changeset.
+
+
+diffcore-merge-broken
+---------------------
+
+This transformation is used to merge filepairs broken by
+diffcore-break, and not transformed into rename/copy by
+diffcore-rename, back into a single modification.  This always
+runs when diffcore-break is used.
+
+For the purpose of merging broken filepairs back, it uses a
+different "extent of changes" computation from the ones used by
+diffcore-break and diffcore-rename.  It counts only the deletion
+from the original, and does not count insertion.  If you removed
+only 10 lines from a 100-line document, even if you added 910
+new lines to make a new 1000-line document, you did not do a
+complete rewrite.  diffcore-break breaks such a case in order to
+help diffcore-rename to consider such filepairs as candidate of
+rename/copy detection, but if filepairs broken that way were not
+matched with other filepairs to create rename/copy, then this
+transformation merges them back into the original
+"modification".
+
+The "extent of changes" parameter can be tweaked from the
+default 80% (that is, unless more than 80% of the original
+material is deleted, the broken pairs are merged back into a
+single modification) by giving a second number to -B option,
+like these:
+
+* -B50/60 (give 50% "break score" to diffcore-break, use 60%
+  for diffcore-merge-broken).
+
+* -B/60 (the same as above, since diffcore-break defaults to 50%).
+
+Note that earlier implementation left a broken pair as a separate
+creation and deletion patches.  This was an unnecessary hack and
+the latest implementation always merges all the broken pairs
+back into modifications, but the resulting patch output is
+formatted differently for easier review in case of such
+a complete rewrite by showing the entire contents of old version
+prefixed with '-', followed by the entire contents of new
+version prefixed with '+'.
+
+
+diffcore-pickaxe
+----------------
+
+This transformation is used to find filepairs that represent
+changes that touch a specified string, and is controlled by the
+-S option and the `\--pickaxe-all` option to the git-diff-*
+commands.
+
+When diffcore-pickaxe is in use, it checks if there are
+filepairs whose "original" side has the specified string and
+whose "result" side does not.  Such a filepair represents "the
+string appeared in this changeset".  It also checks for the
+opposite case that loses the specified string.
+
+When `\--pickaxe-all` is not in effect, diffcore-pickaxe leaves
+only such filepairs that touches the specified string in its
+output.  When `\--pickaxe-all` is used, diffcore-pickaxe leaves all
+filepairs intact if there is such a filepair, or makes the
+output empty otherwise.  The latter behaviour is designed to
+make reviewing of the changes in the context of the whole
+changeset easier.
+
+
+diffcore-order
+--------------
+
+This is used to reorder the filepairs according to the user's
+(or project's) taste, and is controlled by the -O option to the
+git-diff-* commands.
+
+This takes a text file each of whose line is a shell glob
+pattern.  Filepairs that match a glob pattern on an earlier line
+in the file are output before ones that match a later line, and
+filepairs that do not match any glob pattern are output last.
+
+As an example, typical orderfile for the core git probably
+would look like this:
+
+------------------------------------------------
+README
+Makefile
+Documentation
+*.h
+*.c
+t
+------------------------------------------------
+
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
new file mode 100644 (file)
index 0000000..4a03b4c
--- /dev/null
@@ -0,0 +1,33 @@
+git-add(1)
+==========
+
+NAME
+----
+git-add - Add files to the cache.
+
+SYNOPSIS
+--------
+'git-add' <file>...
+
+DESCRIPTION
+-----------
+A simple wrapper for git-update-index to add files to the cache for people used
+to do "cvs add".
+
+OPTIONS
+-------
+<file>...::
+       Files to add to the cache.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
new file mode 100644 (file)
index 0000000..704dc51
--- /dev/null
@@ -0,0 +1,90 @@
+git-am(1)
+=========
+
+NAME
+----
+git-am - Apply a series of patches in a mailbox
+
+
+SYNOPSIS
+--------
+'git-am' [--signoff] [--dotest=<dir>] [--utf8] [--3way] <mbox>...
+'git-am' [--skip]
+
+DESCRIPTION
+-----------
+Splits mail messages in a mailbox into commit log message,
+authorship information and patches, and applies them to the
+current branch.
+
+OPTIONS
+-------
+--signoff::
+       Add `Signed-off-by:` line to the commit message, using
+       the committer identity of yourself.
+
+--dotest=<dir>::
+       Instead of `.dotest` directory, use <dir> as a working
+       area to store extracted patches.
+
+--utf8, --keep::
+       Pass `--utf8` and `--keep` flags to `git-mailinfo` (see
+       gitlink:git-mailinfo[1]).
+
+--3way::
+       When the patch does not apply cleanly, fall back on
+       3-way merge, if the patch records the identity of blobs
+       it is supposed to apply to, and we have those blobs
+       locally.
+
+--skip::
+       Skip the current patch.  This is only meaningful when
+       restarting an aborted patch.
+
+--interactive::
+       Run interactively, just like git-applymbox.
+
+
+DISCUSSION
+----------
+
+When initially invoking it, you give it names of the mailboxes
+to crunch.  Upon seeing the first patch that does not apply, it
+aborts in the middle, just like 'git-applymbox' does.  You can
+recover from this in one of two ways:
+
+. skip the current one by re-running the command with '--skip'
+  option.
+
+. hand resolve the conflict in the working directory, run 'git
+  diff HEAD' to extract the merge result into a patch form and
+  replacing the patch in .dotest/patch file.  After doing this,
+  run `git-reset --hard HEAD` to bring the working tree to the
+  state before half-applying the patch, then re-run the command
+  without any options.
+
+The command refuses to process new mailboxes while `.dotest`
+directory exists, so if you decide to start over from scratch,
+run `rm -f .dotest` before running the command with mailbox
+names.
+
+
+SEE ALSO
+--------
+gitlink:git-applymbox[1], gitlink:git-applypatch[1].
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+This manual page is a stub. You can help the git documentation by expanding it.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
new file mode 100644 (file)
index 0000000..fd38ee5
--- /dev/null
@@ -0,0 +1,81 @@
+git-apply(1)
+============
+
+NAME
+----
+git-apply - Apply patch on a git index file and a work tree
+
+
+SYNOPSIS
+--------
+'git-apply' [--stat] [--summary] [--check] [--index] [--apply] [--index-info] [-z] [<patch>...]
+
+DESCRIPTION
+-----------
+Reads supplied diff output and applies it on a git index file
+and a work tree.
+
+OPTIONS
+-------
+<patch>...::
+       The files to read patch from.  '-' can be used to read
+       from the standard input.
+
+--stat::
+       Instead of applying the patch, output diffstat for the
+       input.  Turns off "apply".
+
+--summary::
+       Instead of applying the patch, output a condensed
+       summary of information obtained from git diff extended
+       headers, such as creations, renames and mode changes.
+       Turns off "apply".
+
+--check::
+       Instead of applying the patch, see if the patch is
+       applicable to the current work tree and/or the index
+       file and detects errors.  Turns off "apply".
+
+--index::
+       When --check is in effect, or when applying the patch
+       (which is the default when none of the options that
+       disables it is in effect), make sure the patch is
+       applicable to what the current index file records.  If
+       the file to be patched in the work tree is not
+       up-to-date, it is flagged as an error.  This flag also
+       causes the index file to be updated.
+
+--index-info::
+       Newer git-diff output has embedded 'index information'
+       for each blob to help identify the original version that
+       the patch applies to.  When this flag is given, and if
+       the original version of the blob is available locally,
+       outputs information about them to the standard output.
+
+-z::
+       When showing the index information, do not munge paths,
+       but use NUL terminated machine readable format.  Without
+       this flag, the pathnames output will have TAB, LF, and
+       backslash characters replaced with `\t`, `\n`, and `\\`,
+       respectively.
+
+--apply::
+       If you use any of the options marked ``Turns off
+       "apply"'' above, git-apply reads and outputs the
+       information you asked without actually applying the
+       patch.  Give this flag after those flags to also apply
+       the patch.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-applymbox.txt b/Documentation/git-applymbox.txt
new file mode 100644 (file)
index 0000000..f74c6a4
--- /dev/null
@@ -0,0 +1,92 @@
+git-applymbox(1)
+================
+
+NAME
+----
+git-applymbox - Apply a series of patches in a mailbox
+
+
+SYNOPSIS
+--------
+'git-applymbox' [-u] [-k] [-q] [-m] ( -c .dotest/<num> | <mbox> ) [ <signoff> ]
+
+DESCRIPTION
+-----------
+Splits mail messages in a mailbox into commit log message,
+authorship information and patches, and applies them to the
+current branch.
+
+
+OPTIONS
+-------
+-q::
+       Apply patches interactively.  The user will be given
+       opportunity to edit the log message and the patch before
+       attempting to apply it.
+
+-k::
+       Usually the program 'cleans up' the Subject: header line
+       to extract the title line for the commit log message,
+       among which (1) remove 'Re:' or 're:', (2) leading
+       whitespaces, (3) '[' up to ']', typically '[PATCH]', and
+       then prepends "[PATCH] ".  This flag forbids this
+       munging, and is most useful when used to read back 'git
+       format-patch --mbox' output.
+
+-m::
+       Patches are applied with `git-apply` command, and unless
+       it cleanly applies without fuzz, the processing fails.
+       With this flag, if a tree that the patch applies cleanly
+       is found in a repository, the patch is applied to the
+       tree and then a 3-way merge between the resulting tree
+       and the current tree.
+
+-u::
+       By default, the commit log message, author name and
+       author email are taken from the e-mail without any
+       charset conversion, after minimally decoding MIME
+       transfer encoding.  This flag causes the resulting
+       commit to be encoded in utf-8 by transliterating them.
+       Note that the patch is always used as is without charset
+       conversion, even with this flag.
+
+-c .dotest/<num>::
+       When the patch contained in an e-mail does not cleanly
+       apply, the command exits with an error message. The
+       patch and extracted message are found in .dotest/, and
+       you could re-run 'git applymbox' with '-c .dotest/<num>'
+       flag to restart the process after inspecting and fixing
+       them.
+
+<mbox>::
+       The name of the file that contains the e-mail messages
+       with patches.  This file should be in the UNIX mailbox
+       format.  See 'SubmittingPatches' document to learn about
+       the formatting convention for e-mail submission.
+
+<signoff>::
+       The name of the file that contains your "Signed-off-by"
+       line.  See 'SubmittingPatches' document to learn what
+       "Signed-off-by" line means.  You can also just say
+       'yes', 'true', 'me', or 'please' to use an automatically
+       generated "Signed-off-by" line based on your committer
+       identity.
+
+
+SEE ALSO
+--------
+gitlink:git-am[1], gitlink:git-applypatch[1].
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-applypatch.txt b/Documentation/git-applypatch.txt
new file mode 100644 (file)
index 0000000..5b9037d
--- /dev/null
@@ -0,0 +1,50 @@
+git-applypatch(1)
+=================
+
+NAME
+----
+git-applypatch - Apply one patch extracted from an e-mail.
+
+
+SYNOPSIS
+--------
+'git-applypatch' <msg> <patch> <info> [<signoff>]
+
+DESCRIPTION
+-----------
+Takes three files <msg>, <patch>, and <info> prepared from an
+e-mail message by 'git-mailinfo', and creates a commit.  It is
+usually not necessary to use this command directly.
+
+This command can run `applypatch-msg`, `pre-applypatch`, and
+`post-applypatch` hooks.  See link:hooks.html[hooks] for more
+information.
+
+
+OPTIONS
+-------
+<msg>::
+       Commit log message (sans the first line, which comes
+       from e-mail Subject stored in <info>).
+
+<patch>::
+       The patch to apply.
+
+<info>::
+       Author and subject information extracted from e-mail,
+       used on "author" line and as the first line of the
+       commit log message.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-archimport.txt b/Documentation/git-archimport.txt
new file mode 100644 (file)
index 0000000..fcda012
--- /dev/null
@@ -0,0 +1,85 @@
+git-archimport(1)
+=================
+
+NAME
+----
+git-archimport - Import an Arch repository into git
+
+
+SYNOPSIS
+--------
+`git-archimport` [ -h ] [ -v ] [ -T ] [ -t tempdir ] 
+                 <archive/branch> [ <archive/branch> ]
+
+DESCRIPTION
+-----------
+Imports a project from one or more Arch repositories. It will follow branches
+and repositories within the namespaces defined by the <archive/branch>
+parameters suppplied. If it cannot find the remote branch a merge comes from
+it will just import it as a regular commit. If it can find it, it will mark it 
+as a merge whenever possible (see discussion below). 
+
+The script expects you to provide the key roots where it can start the import 
+from an 'initial import' or 'tag' type of Arch commit. It will follow and 
+import new branches within the provided roots. 
+
+It expects to be dealing with one project only. If it sees 
+branches that have different roots, it will refuse to run. In that case, 
+edit your <archive/branch> parameters to define clearly the scope of the 
+import. 
+
+`git-archimport` uses `tla` extensively in the background to access the 
+Arch repository.
+Make sure you have a recent version of `tla` available in the path. `tla` must
+know about the repositories you pass to `git-archimport`. 
+
+For the initial import `git-archimport` expects to find itself in an empty 
+directory. To follow the development of a project that uses Arch, rerun 
+`git-archimport` with the same parameters as the initial import to perform 
+incremental imports.
+
+MERGES
+------
+Patch merge data from Arch is used to mark merges in git as well. git 
+does not care much about tracking patches, and only considers a merge when a
+branch incorporates all the commits since the point they forked. The end result
+is that git will have a good idea of how far branches have diverged. So the 
+import process does lose some patch-trading metadata.
+
+Fortunately, when you try and merge branches imported from Arch, 
+git will find a good merge base, and it has a good chance of identifying 
+patches that have been traded out-of-sequence between the branches. 
+
+OPTIONS
+-------
+
+-h::
+       Display usage.
+
+-v::
+       Verbose output. 
+
+-T::
+       Many tags. Will create a tag for every commit, reflecting the commit 
+       name in the Arch repository.
+
+-t <tmpdir>::
+       Override the default tempdir.
+
+
+<archive/branch>::
+       Archive/branch identifier in a format that `tla log` understands. 
+
+
+Author
+------
+Written by Martin Langhoff <martin@catalyst.net.nz>.
+
+Documentation
+--------------
+Documentation by Junio C Hamano, Martin Langhoff and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
new file mode 100644 (file)
index 0000000..39fa665
--- /dev/null
@@ -0,0 +1,100 @@
+git-bisect(1)
+=============
+
+NAME
+----
+git-bisect - Find the change that introduced a bug
+
+
+SYNOPSIS
+--------
+'git bisect' start
+'git bisect' bad <rev>
+'git bisect' good <rev>
+'git bisect' reset [<branch>]
+'git bisect' visualize
+'git bisect' replay <logfile>
+'git bisect' log
+
+DESCRIPTION
+-----------
+This command uses 'git-rev-list --bisect' option to help drive
+the binary search process to find which change introduced a bug,
+given an old "good" commit object name and a later "bad" commit
+object name.
+
+The way you use it is:
+
+------------------------------------------------
+git bisect start
+git bisect bad                 # Current version is bad
+git bisect good v2.6.13-rc2    # v2.6.13-rc2 was the last version
+                               # tested that was good
+------------------------------------------------
+
+When you give at least one bad and one good versions, it will
+bisect the revision tree and say something like:
+
+------------------------------------------------
+Bisecting: 675 revisions left to test after this
+------------------------------------------------
+
+and check out the state in the middle. Now, compile that kernel, and boot
+it. Now, let's say that this booted kernel works fine, then just do
+
+------------------------------------------------
+git bisect good                        # this one is good
+------------------------------------------------
+
+which will now say
+
+------------------------------------------------
+Bisecting: 337 revisions left to test after this
+------------------------------------------------
+
+and you continue along, compiling that one, testing it, and depending on
+whether it is good or bad, you say "git bisect good" or "git bisect bad",
+and ask for the next bisection.
+
+Until you have no more left, and you'll have been left with the first bad
+kernel rev in "refs/bisect/bad".
+
+Oh, and then after you want to reset to the original head, do a
+
+------------------------------------------------
+git bisect reset
+------------------------------------------------
+
+to get back to the master branch, instead of being in one of the bisection
+branches ("git bisect start" will do that for you too, actually: it will
+reset the bisection state, and before it does that it checks that you're
+not using some old bisection branch).
+
+During the bisection process, you can say
+
+       git bisect visualize
+
+to see the currently remaining suspects in `gitk`.
+
+The good/bad input is logged, and `git bisect
+log` shows what you have done so far.  You can truncate its
+output somewhere and save it in a file, and run
+
+       git bisect replay that-file
+
+if you find later you made a mistake telling good/bad about a
+revision.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+-------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
new file mode 100644 (file)
index 0000000..a7121a4
--- /dev/null
@@ -0,0 +1,39 @@
+git-branch(1)
+=============
+
+NAME
+----
+git-branch - Create a new branch.
+
+SYNOPSIS
+--------
+'git-branch' [<branchname> [start-point]]
+
+DESCRIPTION
+-----------
+If no argument is provided, show available branches and mark current
+branch with star. Otherwise, create a new branch of name <branchname>.
+
+If a starting point is also specified, that will be where the branch is
+created, otherwise it will be created at the current HEAD.
+
+OPTIONS
+-------
+<branchname>::
+       The name of the branch to create.
+
+start-point::
+       Where to create the branch; defaults to HEAD.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
new file mode 100644 (file)
index 0000000..ab4dcae
--- /dev/null
@@ -0,0 +1,60 @@
+git-cat-file(1)
+===============
+
+NAME
+----
+git-cat-file - Provide content or type information for repository objects
+
+
+SYNOPSIS
+--------
+'git-cat-file' (-t | -s | <type>) <object>
+
+DESCRIPTION
+-----------
+Provides content or type of objects in the repository. The type
+is required unless '-t' is used to find the object type,
+or '-s' is used to find the object size.
+
+OPTIONS
+-------
+<object>::
+       The sha1 identifier of the object.
+
+-t::
+       Instead of the content, show the object type identified by
+       <object>.
+
+-s::
+       Instead of the content, show the object size identified by
+       <object>.
+
+<type>::
+       Typically this matches the real type of <object> but asking
+       for a type that can trivially be dereferenced from the given
+       <object> is also permitted.  An example is to ask for a
+       "tree" with <object> being a commit object that contains it,
+       or to ask for a "blob" with <object> being a tag object that
+       points at it.
+
+OUTPUT
+------
+If '-t' is specified, one of the <type>.  If '-s' is specified,
+the size of the <object> in bytes.
+
+Otherwise the raw (though uncompressed) contents of the <object> will
+be returned.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
new file mode 100644 (file)
index 0000000..636e951
--- /dev/null
@@ -0,0 +1,50 @@
+git-check-ref-format(1)
+=======================
+
+NAME
+----
+git-check-ref-format - Make sure ref name is well formed.
+
+SYNOPSIS
+--------
+'git-check-ref-format' <refname>
+
+DESCRIPTION
+-----------
+Checks if a given 'refname' is acceptable, and exits non-zero if
+it is not.
+
+A reference is used in git to specify branches and tags.  A
+branch head is stored under `$GIT_DIR/refs/heads` directory, and
+a tag is stored under `$GIT_DIR/refs/tags` directory.  git
+imposes the following rules on how refs are named:
+
+. It could be named hierarchically (i.e. separated with slash
+  `/`), but each of its component cannot begin with a dot `.`;
+
+. It cannot have two consecutive dots `..` anywhere;
+
+. It cannot have ASCII control character (i.e. bytes whose
+  values are lower than \040, or \177 `DEL`), space, tilde `~`,
+  caret `{caret}`, or colon `:` anywhere;
+
+. It cannot end with a slash `/`.
+
+These rules makes it easy for shell script based tools to parse
+refnames, and also avoids ambiguities in certain refname
+expressions (see gitlink:git-rev-parse[1]).  Namely:
+
+. double-dot `..` are often used as in `ref1..ref2`, and in some
+  context this notation means `{caret}ref1 ref2` (i.e. not in
+  ref1 and in ref2).
+
+. tilde `~` and caret `{caret}` are used to introduce postfix
+  'nth parent' and 'peel onion' operation.
+
+. colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
+  value and store it in dstref" in fetch and push operations.
+
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-checkout-index.txt b/Documentation/git-checkout-index.txt
new file mode 100644 (file)
index 0000000..589dc9a
--- /dev/null
@@ -0,0 +1,99 @@
+git-checkout-index(1)
+=====================
+
+NAME
+----
+git-checkout-index - Copy files from the cache to the working directory
+
+
+SYNOPSIS
+--------
+'git-checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
+                  [--] <file>...
+
+DESCRIPTION
+-----------
+Will copy all files listed from the cache to the working directory
+(not overwriting existing files).
+
+OPTIONS
+-------
+-u::
+       update stat information for the checked out entries in
+       the cache file.
+
+-q::
+       be quiet if files exist or are not in the cache
+
+-f::
+       forces overwrite of existing files
+
+-a::
+       checks out all files in the cache.  Cannot be used
+       together with explicit filenames.
+
+-n::
+       Don't checkout new files, only refresh files already checked
+       out.
+
+--prefix=<string>::
+       When creating files, prepend <string> (usually a directory
+       including a trailing /)
+
+--::
+       Do not interpret any more arguments as options.
+
+The order of the flags used to matter, but not anymore.
+
+Just doing "git-checkout-index" does nothing. You probably meant
+"git-checkout-index -a". And if you want to force it, you want
+"git-checkout-index -f -a".
+
+Intuitiveness is not the goal here. Repeatability is. The reason for
+the "no arguments means no work" thing is that from scripts you are
+supposed to be able to do things like:
+
+       find . -name '*.h' -print0 | xargs -0 git-checkout-index -f --
+
+which will force all existing `*.h` files to be replaced with their
+cached copies. If an empty command line implied "all", then this would
+force-refresh everything in the cache, which was not the point.
+
+To update and refresh only the files already checked out:
+
+        git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
+
+Oh, and the "--" is just a good idea when you know the rest will be
+filenames. Just so that you wouldn't have a filename of "-a" causing
+problems (not possible in the above example, but get used to it in
+scripting!).
+
+The prefix ability basically makes it trivial to use
+git-checkout-index as an "export as tree" function. Just read the
+desired tree into the index, and do a
+
+        git-checkout-index --prefix=git-export-dir/ -a
+
+and git-checkout-index will "export" the cache into the specified
+directory.
+
+NOTE The final "/" is important. The exported name is literally just
+prefixed with the specified string, so you can also do something like
+
+    git-checkout-index --prefix=.merged- Makefile
+
+to check out the currently cached copy of `Makefile` into the file
+`.merged-Makefile`
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
new file mode 100644 (file)
index 0000000..b7bb1b4
--- /dev/null
@@ -0,0 +1,79 @@
+git-checkout(1)
+===============
+
+NAME
+----
+git-checkout - Checkout and switch to a branch.
+
+SYNOPSIS
+--------
+'git-checkout' [-f] [-b <new_branch>] [<branch>] [<paths>...]
+
+DESCRIPTION
+-----------
+
+When <paths> are not given, this command switches branches, by
+updating the index and working tree to reflect the specified
+branch, <branch>, and updating HEAD to be <branch> or, if
+specified, <new_branch>.
+
+When <paths> are given, this command does *not* switch
+branches.  It updates the named paths in the working tree from
+the index file (i.e. it runs `git-checkout-index -f -u`).  In
+this case, `-f` and `-b` options are meaningless and giving
+either of them results in an error.  <branch> argument can be
+used to specify a specific tree-ish to update the index for the
+given paths before updating the working tree.
+
+
+OPTIONS
+-------
+-f::
+       Force an re-read of everything.
+
+-b::
+       Create a new branch and start it at <branch>.
+
+<new_branch>::
+       Name for the new branch.
+
+<branch>::
+       Branch to checkout; may be any object ID that resolves to a
+       commit. Defaults to HEAD.
+
+
+EXAMPLE
+-------
+
+The following sequence checks out the `master` branch, reverts
+the `Makefile` to two revisions back, deletes hello.c by
+mistake, and gets it back from the index.
+
+------------
+$ git checkout master
+$ git checkout master~2 Makefile
+$ rm -f hello.c
+$ git checkout hello.c
+------------
+
+If you have an unfortunate branch that is named `hello.c`, the
+last step above would be confused as an instruction to switch to
+that branch.  You should instead write:
+
+------------
+$ git checkout -- hello.c
+------------
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
new file mode 100644 (file)
index 0000000..26e0467
--- /dev/null
@@ -0,0 +1,56 @@
+git-cherry-pick(1)
+==================
+
+NAME
+----
+git-cherry-pick - Apply the change introduced by an existing commit.
+
+SYNOPSIS
+--------
+'git-cherry-pick' [-n] [-r] <commit>
+
+DESCRIPTION
+-----------
+Given one existing commit, apply the change the patch introduces, and record a
+new commit that records it.  This requires your working tree to be clean (no
+modifications from the HEAD commit).
+
+OPTIONS
+-------
+<commit>::
+       Commit to cherry-pick.
+
+-r::
+       Usually the command appends which commit was
+       cherry-picked after the original commit message when
+       making a commit.  This option, '--replay', causes it to
+       use the original commit message intact.  This is useful
+       when you are reordering the patches in your private tree
+       before publishing, and is used by 'git rebase'.
+
+-n::
+       Usually the command automatically creates a commit with
+       a commit log message stating which commit was
+       cherry-picked.  This flag applies the change necessary
+       to cherry-pick the named commit to your working tree,
+       but does not make the commit.  In addition, when this
+       option is used, your working tree does not have to match
+       the HEAD commit.  The cherry-pick is done against the
+       beginning state of your working tree.
++
+This is useful when cherry-picking more than one commits'
+effect to your working tree in a row.
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt
new file mode 100644 (file)
index 0000000..af87966
--- /dev/null
@@ -0,0 +1,42 @@
+git-cherry(1)
+=============
+
+NAME
+----
+git-cherry - Find commits not merged upstream.
+
+SYNOPSIS
+--------
+'git-cherry' [-v] <upstream> [<head>]
+
+DESCRIPTION
+-----------
+Each commit between the fork-point and <head> is examined, and compared against
+the change each commit between the fork-point and <upstream> introduces.
+Commits already included in upstream are prefixed with '-' (meaning "drop from
+my local pull"), while commits missing from upstream are prefixed with '+'
+(meaning "add to the updated upstream").
+
+OPTIONS
+-------
+-v::
+       Verbose.
+
+<upstream>::
+       Upstream branch to compare against.
+
+<head>::
+       Working branch; defaults to HEAD.
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-clone-pack.txt b/Documentation/git-clone-pack.txt
new file mode 100644 (file)
index 0000000..cfc7b62
--- /dev/null
@@ -0,0 +1,60 @@
+git-clone-pack(1)
+=================
+
+NAME
+----
+git-clone-pack - Clones a repository by receiving packed objects.
+
+
+SYNOPSIS
+--------
+'git-clone-pack' [--exec=<git-upload-pack>] [<host>:]<directory> [<head>...]
+
+DESCRIPTION
+-----------
+Clones a repository into the current repository by invoking
+'git-upload-pack', possibly on the remote host via ssh, in
+the named repository, and stores the sent pack in the local
+repository.
+
+OPTIONS
+-------
+--exec=<git-upload-pack>::
+       Use this to specify the path to 'git-upload-pack' on the
+       remote side, if it is not found on your $PATH.
+       Installations of sshd ignore the user's environment
+       setup scripts for login shells (e.g. .bash_profile) and
+       your privately installed git may not be found on the system
+       default $PATH.  Another workaround suggested is to set
+       up your $PATH in ".bashrc", but this flag is for people
+       who do not want to pay the overhead for non-interactive
+       shells by having a lean .bashrc file (they set most of
+       the things up in .bash_profile).
+
+<host>::
+       A remote host that houses the repository.  When this
+       part is specified, 'git-upload-pack' is invoked via
+       ssh.
+
+<directory>::
+       The repository to sync from.
+
+<head>...::
+       The heads to update.  This is relative to $GIT_DIR
+       (e.g. "HEAD", "refs/heads/master").  When unspecified,
+       all heads are updated to match the remote repository.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
new file mode 100644 (file)
index 0000000..dd92cde
--- /dev/null
@@ -0,0 +1,72 @@
+git-clone(1)
+============
+
+NAME
+----
+git-clone - Clones a repository.
+
+
+SYNOPSIS
+--------
+'git-clone' [-l [-s]] [-q] [-n] [-u <upload-pack>] <repository> <directory>
+
+DESCRIPTION
+-----------
+Clones a repository into a newly created directory.
+
+OPTIONS
+-------
+--local::
+-l::
+       When the repository to clone from is on a local machine,
+       this flag bypasses normal "git aware" transport
+       mechanism and clones the repository by making a copy of
+       HEAD and everything under objects and refs directories.
+       The files under .git/objects/ directory are hardlinked
+       to save space when possible.
+
+--shared::
+-s::
+       When the repository to clone is on the local machine,
+       instead of using hard links automatically setup
+       .git/objects/info/alternatives to share the objects
+       with the source repository
+
+--quiet::
+-q::
+       Operate quietly.  This flag is passed to "rsync" and
+       "git-clone-pack" commands when given.
+
+-n::
+       No checkout of HEAD is performed after the clone is complete.
+
+--upload-pack <upload-pack>::
+-u <upload-pack>::
+       When given, and the repository to clone from is handled
+       by 'git-clone-pack', '--exec=<upload-pack>' is passed to
+       the command to specify non-default path for the command
+       run on the other end.
+
+<repository>::
+       The (possibly remote) repository to clone from.  It can
+       be an "rsync://host/dir" URL, an "http://host/dir" URL,
+       or [<host>:]/dir notation that is used by 'git-clone-pack'.
+       Currently http transport is not supported.
+
+<directory>::
+       The name of a new directory to be cloned into.  It is an
+       error to specify an existing directory.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
new file mode 100644 (file)
index 0000000..d9b0ab0
--- /dev/null
@@ -0,0 +1,91 @@
+git-commit-tree(1)
+==================
+
+NAME
+----
+git-commit-tree - Creates a new commit object
+
+
+SYNOPSIS
+--------
+'git-commit-tree' <tree> [-p <parent commit>]\   < changelog
+
+DESCRIPTION
+-----------
+Creates a new commit object based on the provided tree object and
+emits the new commit object id on stdout. If no parent is given then
+it is considered to be an initial tree.
+
+A commit object usually has 1 parent (a commit after a change) or up
+to 16 parents.  More than one parent represents a merge of branches
+that led to them.
+
+While a tree represents a particular directory state of a working
+directory, a commit represents that state in "time", and explains how
+to get there.
+
+Normally a commit would identify a new "HEAD" state, and while git
+doesn't care where you save the note about that state, in practice we
+tend to just write the result to the file `.git/HEAD`, so that we can
+always see what the last committed state was.
+
+OPTIONS
+-------
+<tree>::
+       An existing tree object
+
+-p <parent commit>::
+       Each '-p' indicates the id of a parent commit object.
+       
+
+Commit Information
+------------------
+
+A commit encapsulates:
+
+- all parent object ids
+- author name, email and date
+- committer name and email and the commit time.
+
+If not provided, "git-commit-tree" uses your name, hostname and domain to
+provide author and committer info. This can be overridden using the
+following environment variables.
+
+       GIT_AUTHOR_NAME
+       GIT_AUTHOR_EMAIL
+       GIT_AUTHOR_DATE
+       GIT_COMMITTER_NAME
+       GIT_COMMITTER_EMAIL
+
+(nb "<", ">" and "\n"s are stripped)
+
+A commit comment is read from stdin (max 999 chars). If a changelog
+entry is not provided via "<" redirection, "git-commit-tree" will just wait
+for one to be entered and terminated with ^D.
+
+Diagnostics
+-----------
+You don't exist. Go away!::
+    The passwd(5) gecos field couldn't be read
+Your parents must have hated you!::
+    The password(5) gecos field is longer than a giant static buffer.
+Your sysadmin must hate you!::
+    The password(5) name field is longer than a giant static buffer.
+
+See Also
+--------
+gitlink:git-write-tree[1]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
new file mode 100644 (file)
index 0000000..1edc278
--- /dev/null
@@ -0,0 +1,71 @@
+git-commit(1)
+=============
+
+NAME
+----
+git-commit - Record your changes
+
+SYNOPSIS
+--------
+'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>] [-e] <file>...
+
+DESCRIPTION
+-----------
+Updates the index file for given paths, or all modified files if
+'-a' is specified, and makes a commit object.  The command
+VISUAL and EDITOR environment variables to edit the commit log
+message.
+
+This command can run `commit-msg`, `pre-commit`, and
+`post-commit` hooks.  See link:hooks.html[hooks] for more
+information.
+
+OPTIONS
+-------
+-a::
+       Update all paths in the index file.
+
+-c or -C <commit>::
+       Take existing commit object, and reuse the log message
+       and the authorship information (including the timestamp)
+       when creating the commit.  With '-C', the editor is not
+       invoked; with '-c' the user can further edit the commit
+       message.
+
+-F <file>::
+       Take the commit message from the given file.  Use '-' to
+       read the message from the standard input.
+
+-m <msg>::
+       Use the given <msg> as the commit message.
+
+-s::
+       Add Signed-off-by line at the end of the commit message.
+
+-v::
+       Look for suspicious lines the commit introduces, and
+       abort committing if there is one.  The definition of
+       'suspicious lines' is currently the lines that has
+       trailing whitespaces, and the lines whose indentation
+       has a SP character immediately followed by a TAB
+       character.
+
+-e::
+       The message taken from file with `-F`, command line with
+       `-m`, and from file with `-C` are usually used as the
+       commit log message unmodified.  This option lets you
+       further edit the message taken from these sources.
+
+<file>...::
+       Update specified paths in the index file before committing.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>
+
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-convert-objects.txt b/Documentation/git-convert-objects.txt
new file mode 100644 (file)
index 0000000..b1220c0
--- /dev/null
@@ -0,0 +1,29 @@
+git-convert-objects(1)
+======================
+
+NAME
+----
+git-convert-objects - Converts old-style git repository
+
+
+SYNOPSIS
+--------
+'git-convert-objects'
+
+DESCRIPTION
+-----------
+Converts old-style git repository to the latest format
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
new file mode 100644 (file)
index 0000000..36888d9
--- /dev/null
@@ -0,0 +1,28 @@
+git-count-objects(1)
+====================
+
+NAME
+----
+git-count-objects - Reports on unpacked objects.
+
+SYNOPSIS
+--------
+'git-count-objects'
+
+DESCRIPTION
+-----------
+This counts the number of unpacked object files and disk space consumed by
+them, to help you decide when it is a good time to repack.
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
new file mode 100644 (file)
index 0000000..f5248c9
--- /dev/null
@@ -0,0 +1,108 @@
+git-cvsimport(1)
+================
+
+NAME
+----
+git-cvsimport - Import a CVS repository into git
+
+
+SYNOPSIS
+--------
+'git-cvsimport' [ -o <branch-for-HEAD> ] [ -h ] [ -v ]
+                       [ -d <CVSROOT> ] [ -p <options-for-cvsps> ]
+                       [ -C <git_repository> ] [ -i ] [ -k ]
+                       [ -s <subst> ] [ -m ] [ -M regex ] [ <CVS_module> ]
+
+
+DESCRIPTION
+-----------
+Imports a CVS repository into git. It will either create a new
+repository, or incrementally import into an existing one.
+
+Splitting the CVS log into patch sets is done by 'cvsps'.
+At least version 2.1 is required.
+
+OPTIONS
+-------
+-d <CVSROOT>::
+       The root of the CVS archive. May be local (a simple path) or remote;
+       currently, only the :local:, :ext: and :pserver: access methods 
+       are supported.
+
+-C <target-dir>::
+        The git repository to import to.  If the directory doesn't
+        exist, it will be created.  Default is the current directory.
+
+-i::
+       Import-only: don't perform a checkout after importing.  This option
+       ensures the working directory and cache remain untouched and will
+       not create them if they do not exist.
+
+-k::
+       Kill keywords: will extract files with -kk from the CVS archive
+       to avoid noisy changesets. Highly recommended, but off by default
+       to preserve compatibility with early imported trees. 
+
+-u::
+       Convert underscores in tag and branch names to dots.
+
+-o <branch-for-HEAD>::
+       The 'HEAD' branch from CVS is imported to the 'origin' branch within
+       the git repository, as 'HEAD' already has a special meaning for git.
+       Use this option if you want to import into a different branch.
++
+Use '-o master' for continuing an import that was initially done by
+the old cvs2git tool.
+
+-p <options-for-cvsps>::
+       Additional options for cvsps.
+       The options '-u' and '-A' are implicit and should not be used here.
++
+If you need to pass multiple options, separate them with a comma.
+
+-m::    
+       Attempt to detect merges based on the commit message. This option
+       will enable default regexes that try to capture the name source 
+       branch name from the commit message. 
+
+-M <regex>::
+       Attempt to detect merges based on the commit message with a custom
+       regex. It can be used with -m to also see the default regexes. 
+       You must escape forward slashes. 
+
+-v::
+       Verbosity: let 'cvsimport' report what it is doing.
+
+<CVS_module>::
+       The CVS module you want to import. Relative to <CVSROOT>.
+
+-h::
+       Print a short usage message and exit.
+
+-z <fuzz>::
+        Pass the timestamp fuzz factor to cvsps.
+
+-s <subst>::
+       Substitute the character "/" in branch names with <subst>
+
+OUTPUT
+------
+If '-v' is specified, the script reports what it is doing.
+
+Otherwise, success is indicated the Unix way, i.e. by simply exiting with
+a zero exit status.
+
+
+Author
+------
+Written by Matthias Urlichs <smurf@smurf.noris.de>, with help from
+various participants of the git-list <git@vger.kernel.org>.
+
+Documentation
+--------------
+Documentation by Matthias Urlichs <smurf@smurf.noris.de>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
new file mode 100644 (file)
index 0000000..67c5f22
--- /dev/null
@@ -0,0 +1,71 @@
+git-daemon(1)
+=============
+
+NAME
+----
+git-daemon - A really simple server for git repositories.
+
+SYNOPSIS
+--------
+'git-daemon' [--verbose] [--syslog] [--inetd | --port=n] [--export-all]
+             [--timeout=n] [--init-timeout=n] [directory...]
+
+DESCRIPTION
+-----------
+A really simple TCP git daemon that normally listens on port "DEFAULT_GIT_PORT"
+aka 9418. It waits for a connection, and will just execute "git-upload-pack"
+when it gets one.
+
+It's careful in that there's a magic request-line that gives the command and
+what directory to upload, and it verifies that the directory is ok.
+
+It verifies that the directory has the magic file "git-daemon-export-ok", and
+it will refuse to export any git directory that hasn't explicitly been marked
+for export this way (unless the '--export-all' parameter is specified). If you
+pass some directory paths as 'git-daemon' arguments, you can further restrict
+the offers to a whitelist comprising of those.
+
+This is ideally suited for read-only updates, ie pulling from git repositories.
+
+OPTIONS
+-------
+--export-all::
+       Allow pulling from all directories that look like GIT repositories
+       (have the 'objects' subdirectory and a 'HEAD' file), even if they
+       do not have the 'git-daemon-export-ok' file.
+
+--inetd::
+       Have the server run as an inetd service.
+
+--port::
+       Listen on an alternative port.
+
+--init-timeout::
+       Timeout between the moment the connection is established and the
+       client request is received (typically a rather low value, since
+       that should be basically immediate).
+
+--timeout::
+       Timeout for specific client sub-requests. This includes the time
+       it takes for the server to process the sub-request and time spent
+       waiting for next client's request.
+
+--syslog::
+       Log to syslog instead of stderr. Note that this option does not imply
+       --verbose, thus by default only error conditions will be logged.
+
+--verbose::
+       Log details about the incoming connections and requested files.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-diff-files.txt b/Documentation/git-diff-files.txt
new file mode 100644 (file)
index 0000000..e387388
--- /dev/null
@@ -0,0 +1,43 @@
+git-diff-files(1)
+=================
+
+NAME
+----
+git-diff-files - Compares files in the working tree and the cache
+
+
+SYNOPSIS
+--------
+'git-diff-files' [-q] [<common diff options>] [<path>...]
+
+DESCRIPTION
+-----------
+Compares the files in the working tree and the cache.  When paths
+are specified, compares only those named paths.  Otherwise all
+entries in the cache are compared.  The output format is the
+same as "git-diff-index" and "git-diff-tree".
+
+OPTIONS
+-------
+include::diff-options.txt[]
+
+-q::
+       Remain silent even on nonexisting files
+
+Output format
+-------------
+include::diff-format.txt[]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt
new file mode 100644 (file)
index 0000000..2fc3eed
--- /dev/null
@@ -0,0 +1,133 @@
+git-diff-index(1)
+=================
+
+NAME
+----
+git-diff-index - Compares content and mode of blobs between the cache and repository
+
+
+SYNOPSIS
+--------
+'git-diff-index' [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
+
+DESCRIPTION
+-----------
+Compares the content and mode of the blobs found via a tree
+object with the content of the current cache and, optionally
+ignoring the stat state of the file on disk.  When paths are
+specified, compares only those named paths.  Otherwise all
+entries in the cache are compared.
+
+OPTIONS
+-------
+include::diff-options.txt[]
+
+<tree-ish>::
+       The id of a tree object to diff against.
+
+--cached::
+       do not consider the on-disk file at all
+
+-m::
+       By default, files recorded in the index but not checked
+       out are reported as deleted.  This flag makes
+       "git-diff-index" say that all non-checked-out files are up
+       to date.
+
+Output format
+-------------
+include::diff-format.txt[]
+
+Operating Modes
+---------------
+You can choose whether you want to trust the index file entirely
+(using the '--cached' flag) or ask the diff logic to show any files
+that don't match the stat state as being "tentatively changed".  Both
+of these operations are very useful indeed.
+
+Cached Mode
+-----------
+If '--cached' is specified, it allows you to ask:
+
+       show me the differences between HEAD and the current cache
+       contents (the ones I'd write with a "git-write-tree")
+
+For example, let's say that you have worked on your working directory, updated
+some files in the cache and are ready to commit. You want to see eactly
+*what* you are going to commit is without having to write a new tree
+object and compare it that way, and to do that, you just do
+
+       git-diff-index --cached $(cat .git/HEAD)
+
+Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
+done an "git-update-index" to make that effective in the index file.
+"git-diff-files" wouldn't show anything at all, since the index file
+matches my working directory. But doing a "git-diff-index" does:
+
+  torvalds@ppc970:~/git> git-diff-index --cached $(cat .git/HEAD)
+  -100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        commit.c
+  +100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        git-commit.c
+
+You can trivially see that the above is a rename.
+
+In fact, "git-diff-index --cached" *should* always be entirely equivalent to
+actually doing a "git-write-tree" and comparing that. Except this one is much
+nicer for the case where you just want to check where you are.
+
+So doing a "git-diff-index --cached" is basically very useful when you are
+asking yourself "what have I already marked for being committed, and 
+what's the difference to a previous tree".
+
+Non-cached Mode
+---------------
+The "non-cached" mode takes a different approach, and is potentially
+the more useful of the two in that what it does can't be emulated with
+a "git-write-tree" + "git-diff-tree". Thus that's the default mode.
+The non-cached version asks the question:
+
+  show me the differences between HEAD and the currently checked out
+  tree - index contents _and_ files that aren't up-to-date
+
+which is obviously a very useful question too, since that tells you what
+you *could* commit. Again, the output matches the "git-diff-tree -r"
+output to a tee, but with a twist.
+
+The twist is that if some file doesn't match the cache, we don't have
+a backing store thing for it, and we use the magic "all-zero" sha1 to
+show that. So let's say that you have edited `kernel/sched.c`, but
+have not actually done a "git-update-index" on it yet - there is no
+"object" associated with the new state, and you get:
+
+  torvalds@ppc970:~/v2.6/linux> git-diff-index $(cat .git/HEAD )
+  *100644->100664 blob    7476bb......->000000......      kernel/sched.c
+
+ie it shows that the tree has changed, and that `kernel/sched.c` has is
+not up-to-date and may contain new stuff. The all-zero sha1 means that to
+get the real diff, you need to look at the object in the working directory
+directly rather than do an object-to-object diff.
+
+NOTE: As with other commands of this type, "git-diff-index" does not
+actually look at the contents of the file at all. So maybe
+`kernel/sched.c` hasn't actually changed, and it's just that you
+touched it. In either case, it's a note that you need to
+"git-upate-cache" it to make the cache be in sync.
+
+NOTE: You can have a mixture of files show up as "has been updated"
+and "is still dirty in the working directory" together. You can always
+tell which file is in which state, since the "has been updated" ones
+show a valid sha1, and the "not in sync with the index" ones will
+always have the special all-zero sha1.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-diff-stages.txt b/Documentation/git-diff-stages.txt
new file mode 100644 (file)
index 0000000..28c60fc
--- /dev/null
@@ -0,0 +1,40 @@
+git-diff-stages(1)
+==================
+
+NAME
+----
+git-diff-stages - Compares content and mode of blobs between stages in an unmerged index file.
+
+
+SYNOPSIS
+--------
+'git-diff-stages' [<common diff options>] <stage1> <stage2> [<path>...]
+
+DESCRIPTION
+-----------
+Compares the content and mode of the blobs in two stages in an
+unmerged index file.
+
+OPTIONS
+-------
+include::diff-options.txt[]
+
+<stage1>,<stage2>::
+       The stage number to be compared.
+
+Output format
+-------------
+include::diff-format.txt[]
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
new file mode 100644 (file)
index 0000000..dcfb9e1
--- /dev/null
@@ -0,0 +1,134 @@
+git-diff-tree(1)
+================
+
+NAME
+----
+git-diff-tree - Compares the content and mode of blobs found via two tree objects
+
+
+SYNOPSIS
+--------
+'git-diff-tree' [--stdin] [-m] [-s] [-v] [--pretty] [-t] [<common diff options>] <tree-ish> [<tree-ish>] [<path>...]
+
+DESCRIPTION
+-----------
+Compares the content and mode of the blobs found via two tree objects.
+
+If there is only one <tree-ish> given, the commit is compared with its parents
+(see --stdin below).
+
+Note that "git-diff-tree" can use the tree encapsulated in a commit object.
+
+OPTIONS
+-------
+include::diff-options.txt[]
+
+<tree-ish>::
+       The id of a tree object.
+
+<path>...::
+       If provided, the results are limited to a subset of files
+       matching one of these prefix strings.
+       ie file matches `/^<pattern1>|<pattern2>|.../`
+       Note that this parameter does not provide any wildcard or regexp
+       features.
+
+-t::
+       show tree entry itself as well as subtrees.  Implies -r.
+
+--root::
+       When '--root' is specified the initial commit will be showed as a big
+       creation event. This is equivalent to a diff against the NULL tree.
+
+--stdin::
+       When '--stdin' is specified, the command does not take
+       <tree-ish> arguments from the command line.  Instead, it
+       reads either one <commit> or a pair of <tree-ish>
+       separated with a single space from its standard input.
++
+When a single commit is given on one line of such input, it compares
+the commit with its parents.  The following flags further affects its
+behaviour.  This does not apply to the case where two <tree-ish>
+separated with a single space are given.
+
+-m::
+       By default, "git-diff-tree --stdin" does not show
+       differences for merge commits.  With this flag, it shows
+       differences to that commit from all of its parents.
+
+-s::
+       By default, "git-diff-tree --stdin" shows differences,
+       either in machine-readable form (without '-p') or in patch
+       form (with '-p').  This output can be supressed.  It is
+       only useful with '-v' flag.
+
+-v::
+       This flag causes "git-diff-tree --stdin" to also show
+       the commit message before the differences.
+
+--pretty[=(raw|medium|short)]::
+       This is used to control "pretty printing" format of the
+       commit message.  Without "=<style>", it defaults to
+       medium.
+
+
+Limiting Output
+---------------
+If you're only interested in differences in a subset of files, for
+example some architecture-specific files, you might do:
+
+       git-diff-tree -r <tree-ish> <tree-ish> arch/ia64 include/asm-ia64
+
+and it will only show you what changed in those two directories.
+
+Or if you are searching for what changed in just `kernel/sched.c`, just do
+
+       git-diff-tree -r <tree-ish> <tree-ish> kernel/sched.c
+
+and it will ignore all differences to other files.
+
+The pattern is always the prefix, and is matched exactly.  There are no
+wildcards.  Even stricter, it has to match a complete path component.
+I.e. "foo" does not pick up `foobar.h`.  "foo" does match `foo/bar.h`
+so it can be used to name subdirectories.
+
+An example of normal usage is:
+
+  torvalds@ppc970:~/git> git-diff-tree 5319e4......
+  *100664->100664 blob    ac348b.......->a01513.......      git-fsck-objects.c
+
+which tells you that the last commit changed just one file (it's from
+this one:
+
+-----------------------------------------------------------------------------
+commit 3c6f7ca19ad4043e9e72fa94106f352897e651a8
+tree 5319e4d609cdd282069cc4dce33c1db559539b03
+parent b4e628ea30d5ab3606119d2ea5caeab141d38df7
+author Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
+committer Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
+
+Make "git-fsck-objects" print out all the root commits it finds.
+
+Once I do the reference tracking, I'll also make it print out all the
+HEAD commits it finds, which is even more interesting.
+-----------------------------------------------------------------------------
+
+in case you care).
+
+Output format
+-------------
+include::diff-format.txt[]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
new file mode 100644 (file)
index 0000000..cadaf59
--- /dev/null
@@ -0,0 +1,52 @@
+git-diff(1)
+===========
+
+NAME
+----
+git-diff - Show changes between commits, commit and working tree, etc.
+
+
+SYNOPSIS
+--------
+'git-diff' [ --diff-options ] <ent>{0,2} [<path>...]
+
+DESCRIPTION
+-----------
+Show changes between two ents, an ent and the working tree, an
+ent and the index file, or the index file and the working tree.
+The combination of what is compared with what is determined by
+the number of ents given to the command.
+
+`----------------`--------`-----------------------------`------------------
+Number of ents    Options  What's Compared               Underlying command
+---------------------------------------------------------------------------
+0                 -        index file and working tree   git-diff-files
+1                 --cached ent and index file            git-diff-index
+1                 -        ent and working tree          git-diff-index
+2                 -        two ents                      git-diff-tree
+---------------------------------------------------------------------------
+
+OPTIONS
+-------
+--diff-options::
+       '--diff-options' are passed to the `git-diff-files`,
+       `git-diff-index`, and `git-diff-tree` commands.  See the
+       documentation for these commands for description.
+
+<path>...::
+       The <path> arguments are also passed to `git-diff-\*`
+       commands.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
new file mode 100644 (file)
index 0000000..ea6faab
--- /dev/null
@@ -0,0 +1,68 @@
+git-fetch-pack(1)
+=================
+
+NAME
+----
+git-fetch-pack - Receive missing objects from another repository.
+
+
+SYNOPSIS
+--------
+git-fetch-pack [-q] [--exec=<git-upload-pack>] [<host>:]<directory> [<refs>...]
+
+DESCRIPTION
+-----------
+Invokes 'git-upload-pack' on a potentially remote repository,
+and asks it to send objects missing from this repository, to
+update the named heads.  The list of commits available locally
+is found out by scanning local $GIT_DIR/refs/ and sent to
+'git-upload-pack' running on the other end.
+
+This command degenerates to download everything to complete the
+asked refs from the remote side when the local side does not
+have a common ancestor commit.
+
+
+OPTIONS
+-------
+-q::
+       Pass '-q' flag to 'git-unpack-objects'; this makes the
+       cloning process less verbose.
+
+--exec=<git-upload-pack>::
+       Use this to specify the path to 'git-upload-pack' on the
+       remote side, if is not found on your $PATH.
+       Installations of sshd ignores the user's environment
+       setup scripts for login shells (e.g. .bash_profile) and
+       your privately installed git may not be found on the system
+       default $PATH.  Another workaround suggested is to set
+       up your $PATH in ".bashrc", but this flag is for people
+       who do not want to pay the overhead for non-interactive
+       shells by having a lean .bashrc file (they set most of
+       the things up in .bash_profile).
+
+<host>::
+       A remote host that houses the repository.  When this
+       part is specified, 'git-upload-pack' is invoked via
+       ssh.
+
+<directory>::
+       The repository to sync from.
+
+<refs>...::
+       The remote heads to update from. This is relative to
+       $GIT_DIR (e.g. "HEAD", "refs/heads/master").  When
+       unspecified, update from all heads the remote side has.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
new file mode 100644 (file)
index 0000000..7169365
--- /dev/null
@@ -0,0 +1,51 @@
+git-fetch(1)
+============
+
+NAME
+----
+git-fetch - Download objects and a head from another repository.
+
+
+SYNOPSIS
+--------
+'git-fetch' <repository> <refspec>...
+
+
+DESCRIPTION
+-----------
+Fetches named heads or tags from another repository, along with
+the objects necessary to complete them.
+
+The ref names and their object names of fetched refs are stored
+in $GIT_DIR/FETCH_HEAD.  This information is left for a later merge
+operation done by "git resolve" or "git octopus".
+
+
+OPTIONS
+-------
+include::pull-fetch-param.txt[]
+
+-a, \--append::
+       Append ref names and object names of fetched refs to the
+       existing contents of $GIT_DIR/FETCH_HEAD.  Without this
+       option old data in $GIT_DIR/FETCH_HEAD will be overwritten.
+
+-u, \--update-head-ok::
+       By default 'git-fetch' refuses to update the head which
+       corresponds to the current branch.  This flag disables the
+       check.  Note that fetching into the current branch will not
+       update the index and working directory, so use it with care.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>
+
+Documentation
+-------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
new file mode 100644 (file)
index 0000000..f3ef4c1
--- /dev/null
@@ -0,0 +1,73 @@
+git-format-patch(1)
+===================
+
+NAME
+----
+git-format-patch - Prepare patches for e-mail submission.
+
+
+SYNOPSIS
+--------
+'git-format-patch' [-n][-o <dir>|--stdout][-k][--mbox][--diff-options] <his> [<mine>]
+
+DESCRIPTION
+-----------
+Prepare each commit with its patch since <mine> head forked from
+<his> head, one file per patch, for e-mail submission.  Each
+output file is numbered sequentially from 1, and uses the first
+line of the commit message (massaged for pathname safety) as the
+filename.
+
+When -o is specified, output files are created in that
+directory; otherwise in the current working directory.
+
+When -n is specified, instead of "[PATCH] Subject", the first
+line is formatted as "[PATCH N/M] Subject", unless you have only
+one patch.
+
+When --mbox is specified, the output is formatted to resemble
+UNIX mailbox format, and can be concatenated together for
+processing with applymbox.
+
+
+OPTIONS
+-------
+-o <dir>::
+       Use <dir> to store the resulting files, instead of the
+       current working directory.
+
+-n::
+       Name output in '[PATCH n/m]' format.
+
+-k::
+       Do not strip/add '[PATCH]' from the first line of the
+       commit log message.
+
+--author, --date::
+       Output From: and Date: headers for commits made by
+       yourself as well.  Usually these are output only for
+       commits made by people other than yourself.
+
+--mbox::
+       Format the output files for closer to mbox format by
+       adding a phony Unix "From " line, so they can be
+       concatenated together and fed to `git-applymbox`.
+       Implies --author and --date.
+
+--stdout::
+       This flag generates the mbox formatted output to the
+       standard output, instead of saving them into a file per
+       patch and implies --mbox.
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-fsck-objects.txt b/Documentation/git-fsck-objects.txt
new file mode 100644 (file)
index 0000000..5dc9dbd
--- /dev/null
@@ -0,0 +1,144 @@
+git-fsck-objects(1)
+===================
+
+NAME
+----
+git-fsck-objects - Verifies the connectivity and validity of the objects in the database
+
+
+SYNOPSIS
+--------
+'git-fsck-objects' [--tags] [--root] [--unreachable] [--cache] [--standalone | --full] [--strict] [<object>*]
+
+DESCRIPTION
+-----------
+Verifies the connectivity and validity of the objects in the database.
+
+OPTIONS
+-------
+<object>::
+       An object to treat as the head of an unreachability trace.
++
+If no objects are given, git-fsck-objects defaults to using the
+index file and all SHA1 references in .git/refs/* as heads.
+
+--unreachable::
+       Print out objects that exist but that aren't readable from any
+       of the reference nodes.
+
+--root::
+       Report root nodes.
+
+--tags::
+       Report tags.
+
+--cache::
+       Consider any object recorded in the cache also as a head node for
+       an unreachability trace.
+
+--standalone::
+       Limit checks to the contents of GIT_OBJECT_DIRECTORY
+       ($GIT_DIR/objects), making sure that it is consistent and
+       complete without referring to objects found in alternate
+       object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES,
+       nor packed git archives found in $GIT_DIR/objects/pack;
+       cannot be used with --full.
+
+--full::
+       Check not just objects in GIT_OBJECT_DIRECTORY
+       ($GIT_DIR/objects), but also the ones found in alternate
+       object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES,
+       and in packed git archives found in $GIT_DIR/objects/pack
+       and corresponding pack subdirectories in alternate
+       object pools; cannot be used with --standalone.
+
+--strict::
+       Enable more strict checking, namely to catch a file mode
+       recorded with g+w bit set, which was created by older
+       versions of git.  Existing repositories, including the
+       Linux kernel, git itself, and sparse repository have old
+       objects that triggers this check, but it is recommended
+       to check new projects with this flag.
+
+It tests SHA1 and general object sanity, and it does full tracking of
+the resulting reachability and everything else. It prints out any
+corruption it finds (missing or bad objects), and if you use the
+'--unreachable' flag it will also print out objects that exist but
+that aren't readable from any of the specified head nodes.
+
+So for example
+
+       git-fsck-objects --unreachable $(cat .git/HEAD .git/refs/heads/*)
+
+will do quite a _lot_ of verification on the tree. There are a few
+extra validity tests to be added (make sure that tree objects are
+sorted properly etc), but on the whole if "git-fsck-objects" is happy, you
+do have a valid tree.
+
+Any corrupt objects you will have to find in backups or other archives
+(ie you can just remove them and do an "rsync" with some other site in
+the hopes that somebody else has the object you have corrupted).
+
+Of course, "valid tree" doesn't mean that it wasn't generated by some
+evil person, and the end result might be crap. git is a revision
+tracking system, not a quality assurance system ;)
+
+Extracted Diagnostics
+---------------------
+
+expect dangling commits - potential heads - due to lack of head information::
+       You haven't specified any nodes as heads so it won't be
+       possible to differentiate between un-parented commits and
+       root nodes.
+
+missing sha1 directory '<dir>'::
+       The directory holding the sha1 objects is missing.
+
+unreachable <type> <object>::
+       The <type> object <object>, isn't actually referred to directly
+       or indirectly in any of the trees or commits seen. This can
+       mean that there's another root node that you're not specifying
+       or that the tree is corrupt. If you haven't missed a root node
+       then you might as well delete unreachable nodes since they
+       can't be used.
+
+missing <type> <object>::
+       The <type> object <object>, is referred to but isn't present in
+       the database.
+
+dangling <type> <object>::
+       The <type> object <object>, is present in the database but never
+       'directly' used. A dangling commit could be a root node.
+
+warning: git-fsck-objects: tree <tree> has full pathnames in it::
+       And it shouldn't...
+
+sha1 mismatch <object>::
+       The database has an object who's sha1 doesn't match the
+       database value.
+       This indicates a serious data integrity problem.
+
+Environment Variables
+---------------------
+
+GIT_OBJECT_DIRECTORY::
+       used to specify the object database root (usually $GIT_DIR/objects)
+
+GIT_INDEX_FILE::
+       used to specify the index file of the cache
+
+GIT_ALTERNATE_OBJECT_DIRECTORIES::
+       used to specify additional object database roots (usually unset)
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-get-tar-commit-id.txt b/Documentation/git-get-tar-commit-id.txt
new file mode 100644 (file)
index 0000000..30b1fbf
--- /dev/null
@@ -0,0 +1,37 @@
+git-get-tar-commit-id(1)
+========================
+
+NAME
+----
+git-get-tar-commit-id - Extract commit ID from an archive created using git-tar-tree.
+
+
+SYNOPSIS
+--------
+'git-get-tar-commit-id' < <tarfile>
+
+
+DESCRIPTION
+-----------
+Acts as a filter, extracting the commit ID stored in archives created by
+git-tar-tree.  It reads only the first 1024 bytes of input, thus its
+runtime is not influenced by the size of <tarfile> very much.
+
+If no commit ID is found, git-get-tar-commit-id quietly exists with a
+return code of 1.  This can happen if <tarfile> had not been created
+using git-tar-tree or if the first parameter of git-tar-tree had been
+a tree ID instead of a commit ID or tag.
+
+
+Author
+------
+Written by Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
new file mode 100644 (file)
index 0000000..0175793
--- /dev/null
@@ -0,0 +1,46 @@
+git-grep(1)
+===========
+
+NAME
+----
+git-grep - print lines matching a pattern
+
+
+SYNOPSIS
+--------
+'git-grep' <option>... <pattern> <path>...
+
+DESCRIPTION
+-----------
+Searches list of files `git-ls-files` produces for lines
+containing a match to the given pattern.
+
+
+OPTIONS
+-------
+<option>...::
+       Either an option to pass to `grep` or `git-ls-files`.
+       Some `grep` options, such as `-C` and `-m`, that take
+       parameters are known to `git-grep`.
+
+<pattern>::
+       The pattern to look for.
+
+<path>...::
+
+       Optional paths to limit the set of files to be searched;
+       passed to `git-ls-files`.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt
new file mode 100644 (file)
index 0000000..9239f11
--- /dev/null
@@ -0,0 +1,43 @@
+git-hash-object(1)
+==================
+
+NAME
+----
+git-hash-object - Computes object ID and optionally creates a blob from a file.
+
+
+SYNOPSIS
+--------
+'git-hash-object' [-t <type>] [-w] <any-file-on-the-filesystem>
+
+DESCRIPTION
+-----------
+Computes the object ID value for an object with specified type
+with the contents of the named file (which can be outside of the
+work tree), and optionally writes the resulting object into the
+object database.  Reports its object ID to its standard output.
+This is used by "git-cvsimport" to update the cache
+without modifying files in the work tree.  When <type> is not
+specified, it defaults to "blob". 
+
+OPTIONS
+-------
+
+-t <type>::
+       Specify the type (default: "blob").
+
+-w::
+       Actually write the object into the object database.
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-http-fetch.txt b/Documentation/git-http-fetch.txt
new file mode 100644 (file)
index 0000000..088624f
--- /dev/null
@@ -0,0 +1,41 @@
+git-http-fetch(1)
+=================
+
+NAME
+----
+git-http-fetch - Downloads a remote git repository via HTTP
+
+
+SYNOPSIS
+--------
+'git-http-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] commit-id url
+
+DESCRIPTION
+-----------
+Downloads a remote git repository via HTTP.
+
+-c::
+       Get the commit objects.
+-t::
+       Get trees associated with the commit objects.
+-a::
+       Get all the objects.
+-v::
+       Report what is downloaded.
+
+-w <filename>::
+        Writes the commit-id into the filename under $GIT_DIR/refs/<filename> on
+        the local end after the transfer is complete.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt
new file mode 100644 (file)
index 0000000..71ce557
--- /dev/null
@@ -0,0 +1,44 @@
+git-index-pack(1)
+=================
+
+NAME
+----
+git-index-pack - Build pack index file for an existing packed archive
+
+
+SYNOPSIS
+--------
+'git-index-pack' [-o <index-file>] <pack-file>
+
+
+DESCRIPTION
+-----------
+Reads a packed archive (.pack) from the specified file, and
+builds a pack index file (.idx) for it.  The packed archive
+together with the pack index can then be placed in the
+objects/pack/ directory of a git repository.
+
+
+OPTIONS
+-------
+-o <index-file>::
+       Write the generated pack index into the specified
+       file.  Without this option the name of pack index
+       file is constructed from the name of packed archive
+       file by replacing .pack with .idx (and the program
+       fails if the name of packed archive does not end
+       with .pack).
+
+
+Author
+------
+Written by Sergey Vlasov <vsu@altlinux.ru>
+
+Documentation
+-------------
+Documentation by Sergey Vlasov
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
new file mode 100644 (file)
index 0000000..ef1826a
--- /dev/null
@@ -0,0 +1,40 @@
+git-init-db(1)
+==============
+
+NAME
+----
+git-init-db - Creates an empty git repository
+
+
+SYNOPSIS
+--------
+'git-init-db'
+
+DESCRIPTION
+-----------
+This simply creates an empty git repository - basically a `.git` directory
+and `.git/object/??/`, `.git/refs/heads` and `.git/refs/tags` directories,
+and links `.git/HEAD` symbolically to `.git/refs/heads/master`.
+
+If the 'GIT_DIR' environment variable is set then it specifies a path
+to use instead of `./.git` for the base of the repository.
+
+If the object storage directory is specified via the 'GIT_OBJECT_DIRECTORY'
+environment variable then the sha1 directories are created underneath -
+otherwise the default `$GIT_DIR/objects` directory is used.
+
+"git-init-db" won't hurt an existing repository.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-local-fetch.txt b/Documentation/git-local-fetch.txt
new file mode 100644 (file)
index 0000000..87abec1
--- /dev/null
@@ -0,0 +1,43 @@
+git-local-fetch(1)
+==================
+
+NAME
+----
+git-local-fetch - Duplicates another git repository on a local system
+
+
+SYNOPSIS
+--------
+'git-local-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [-l] [-s] [-n] commit-id path
+
+DESCRIPTION
+-----------
+Duplicates another git repository on a local system.
+
+OPTIONS
+-------
+-c::
+       Get the commit objects.
+-t::
+       Get trees associated with the commit objects.
+-a::
+       Get all the objects.
+-v::
+       Report what is downloaded.
+
+-w <filename>::
+        Writes the commit-id into the filename under $GIT_DIR/refs/<filename> on
+        the local end after the transfer is complete.
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
new file mode 100644 (file)
index 0000000..13a3998
--- /dev/null
@@ -0,0 +1,44 @@
+git-log(1)
+==========
+
+NAME
+----
+git-log - Show commit logs
+
+
+SYNOPSIS
+--------
+'git-log' <option>...
+
+DESCRIPTION
+-----------
+Shows the commit logs.  This command internally invokes
+'git-rev-list', and the command line options are passed to that
+command.
+
+This manual page describes only the most frequently used options.
+
+OPTIONS
+-------
+--pretty=<format>:
+       Controls the way the commit log is formatted.
+
+--max-count=<n>::
+       Limits the number of commits to show.
+
+<since>..<until>::
+       Show only commits between the named two commits.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
new file mode 100644 (file)
index 0000000..8c1784d
--- /dev/null
@@ -0,0 +1,213 @@
+git-ls-files(1)
+===============
+
+NAME
+----
+git-ls-files - Information about files in the cache/working directory
+
+
+SYNOPSIS
+--------
+'git-ls-files' [-z] [-t]
+               (--[cached|deleted|others|ignored|stage|unmerged|killed|modified])\*
+               (-[c|d|o|i|s|u|k|m])\*
+               [-x <pattern>|--exclude=<pattern>]
+               [-X <file>|--exclude-from=<file>]
+               [--exclude-per-directory=<file>] [--] [<file>]\*
+
+DESCRIPTION
+-----------
+This merges the file listing in the directory cache index with the
+actual working directory list, and shows different combinations of the
+two.
+
+One or more of the options below may be used to determine the files
+shown:
+
+OPTIONS
+-------
+-c|--cached::
+       Show cached files in the output (default)
+
+-d|--deleted::
+       Show deleted files in the output
+
+-m|--modified::
+       Show modified files in the output
+
+-o|--others::
+       Show other files in the output
+
+-i|--ignored::
+       Show ignored files in the output
+       Note the this also reverses any exclude list present.
+
+-s|--stage::
+       Show stage files in the output
+
+-u|--unmerged::
+       Show unmerged files in the output (forces --stage)
+
+-k|--killed::
+       Show files on the filesystem that need to be removed due
+       to file/directory conflicts for checkout-index to
+       succeed.
+
+-z::
+       \0 line termination on output.
+
+-x|--exclude=<pattern>::
+       Skips files matching pattern.
+       Note that pattern is a shell wildcard pattern.
+
+-X|--exclude-from=<file>::
+       exclude patterns are read from <file>; 1 per line.
+
+--exclude-per-directory=<file>::
+       read additional exclude patterns that apply only to the
+       directory and its subdirectories in <file>.
+
+-t::
+       Identify the file status with the following tags (followed by
+       a space) at the start of each line:
+       H::     cached
+       M::     unmerged
+       R::     removed/deleted
+       C::     modifed/changed
+       K::     to be killed
+       ?       other
+
+--::
+       Do not interpret any more arguments as options.
+
+<file>::
+       Files to show. If no files are given all files which match the other
+       specified criteria are shown.
+
+Output
+------
+show files just outputs the filename unless '--stage' is specified in
+which case it outputs:
+
+        [<tag> ]<mode> <object> <stage> <file>
+
+"git-ls-files --unmerged" and "git-ls-files --stage" can be used to examine
+detailed information on unmerged paths.
+
+For an unmerged path, instead of recording a single mode/SHA1 pair,
+the dircache records up to three such pairs; one from tree O in stage
+1, A in stage 2, and B in stage 3.  This information can be used by
+the user (or the porcelain) to see what should eventually be recorded at the
+path. (see git-read-tree for more information on state)
+
+When `-z` option is not used, TAB, LF, and backslash characters
+in pathnames are represented as `\t`, `\n`, and `\\`,
+respectively.
+
+
+Exclude Patterns
+----------------
+
+'git-ls-files' can use a list of "exclude patterns" when
+traversing the directory tree and finding files to show when the
+flags --others or --ignored are specified.
+
+These exclude patterns come from these places:
+
+  1. command line flag --exclude=<pattern> specifies a single
+     pattern.
+
+  2. command line flag --exclude-from=<file> specifies a list of
+     patterns stored in a file.
+
+  3. command line flag --exclude-per-directory=<name> specifies
+     a name of the file in each directory 'git-ls-files'
+     examines, and if exists, its contents are used as an
+     additional list of patterns.
+
+An exclude pattern file used by (2) and (3) contains one pattern
+per line.  A line that starts with a '#' can be used as comment
+for readability.
+
+There are three lists of patterns that are in effect at a given
+time.  They are built and ordered in the following way:
+
+ * --exclude=<pattern> from the command line; patterns are
+   ordered in the same order as they appear on the command line.
+
+ * lines read from --exclude-from=<file>; patterns are ordered
+   in the same order as they appear in the file.
+
+ * When --exclude-per-directory=<name> is specified, upon
+   entering a directory that has such a file, its contents are
+   appended at the end of the current "list of patterns".  They
+   are popped off when leaving the directory.
+
+Each pattern in the pattern list specifies "a match pattern" and
+optionally the fate; either a file that matches the pattern is
+considered excluded or included.  A filename is matched against
+the patterns in the three lists; the --exclude-from list is
+checked first, then the --exclude-per-directory list, and then
+finally the --exclude list. The last match determines its fate.
+If there is no match in the three lists, the fate is "included".
+
+A pattern specified on the command line with --exclude or read
+from the file specified with --exclude-from is relative to the
+top of the directory tree.  A pattern read from a file specified
+by --exclude-per-directory is relative to the directory that the
+pattern file appears in.
+
+An exclude pattern is of the following format:
+
+ - an optional prefix '!' which means that the fate this pattern
+   specifies is "include", not the usual "exclude"; the
+   remainder of the pattern string is interpreted according to
+   the following rules.
+
+ - if it does not contain a slash '/', it is a shell glob
+   pattern and used to match against the filename without
+   leading directories (i.e. the same way as the current
+   implementation).
+
+ - otherwise, it is a shell glob pattern, suitable for
+   consumption by fnmatch(3) with FNM_PATHNAME flag.  I.e. a
+   slash in the pattern must match a slash in the pathname.
+   "Documentation/\*.html" matches "Documentation/git.html" but
+   not "ppc/ppc.html".  As a natural exception, "/*.c" matches
+   "cat-file.c" but not "mozilla-sha1/sha1.c".
+
+An example:
+
+--------------------------------------------------------------
+    $ cat .git/ignore
+    # ignore objects and archives, anywhere in the tree.
+    *.[oa]
+    $ cat Documentation/.gitignore
+    # ignore generated html files,
+    *.html
+    # except foo.html which is maintained by hand
+    !foo.html
+    $ git-ls-files --ignored \
+        --exclude='Documentation/*.[0-9]' \
+        --exclude-from=.git/ignore \
+        --exclude-per-directory=.gitignore
+--------------------------------------------------------------
+
+
+See Also
+--------
+gitlink:git-read-tree[1]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt
new file mode 100644 (file)
index 0000000..c0a80d4
--- /dev/null
@@ -0,0 +1,63 @@
+git-ls-remote(1)
+================
+
+NAME
+----
+git-ls-remote - Look at references other repository has.
+
+
+SYNOPSIS
+--------
+'git-ls-remote' [--heads] [--tags] <repository> <refs>...
+
+DESCRIPTION
+-----------
+Displays the references other repository has.
+
+
+OPTIONS
+-------
+--heads --tags::
+       Limit to only refs/heads and refs/tags, respectively.
+       These options are _not_ mutually exclusive; when given
+       both, references stored in refs/heads and refs/tags are
+       displayed.
+
+<repository>::
+       Location of the repository.  The shorthand defined in
+       $GIT_DIR/branches/ can be used.
+
+<refs>...::
+       When unspecified, all references, after filtering done
+       with --heads and --tags, are shown.  When <refs>... are
+       specified, only references matching the given patterns
+       are displayed.
+
+EXAMPLES
+--------
+
+       $ git ls-remote --tags ./.
+       d6602ec5194c87b0fc87103ca4d67251c76f233a        refs/tags/v0.99
+       f25a265a342aed6041ab0cc484224d9ca54b6f41        refs/tags/v0.99.1
+       7ceca275d047c90c0c7d5afb13ab97efdf51bd6e        refs/tags/v0.99.3
+       c5db5456ae3b0873fc659c19fafdde22313cc441        refs/tags/v0.99.2
+       0918385dbd9656cab0d1d81ba7453d49bbc16250        refs/tags/junio-gpg-pub
+       $ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc
+       5fe978a5381f1fbad26a80e682ddd2a401966740        refs/heads/master
+       c781a84b5204fb294c9ccc79f8b3baceeb32c061        refs/heads/pu
+       b1d096f2926c4e37c9c0b6a7bf2119bedaa277cb        refs/heads/rc
+       $ echo http://www.kernel.org/pub/scm/git/git.git >.git/branches/public
+       $ git ls-remote --tags public v\*
+       d6602ec5194c87b0fc87103ca4d67251c76f233a        refs/tags/v0.99
+       f25a265a342aed6041ab0cc484224d9ca54b6f41        refs/tags/v0.99.1
+       c5db5456ae3b0873fc659c19fafdde22313cc441        refs/tags/v0.99.2
+       7ceca275d047c90c0c7d5afb13ab97efdf51bd6e        refs/tags/v0.99.3
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
new file mode 100644 (file)
index 0000000..ba0438e
--- /dev/null
@@ -0,0 +1,58 @@
+git-ls-tree(1)
+==============
+
+NAME
+----
+git-ls-tree - Lists the contents of a tree object.
+
+
+SYNOPSIS
+--------
+'git-ls-tree' [-d] [-r] [-z] <tree-ish> [paths...]
+
+DESCRIPTION
+-----------
+Lists the contents of a tree object, like what "/bin/ls -a" does
+in the current working directory.
+
+OPTIONS
+-------
+<tree-ish>::
+       Id of a tree-ish.
+
+-d::
+       show only the named tree entry itself, not its children
+
+-r::
+       recurse into sub-trees
+
+-z::
+       \0 line termination on output
+
+paths::
+       When paths are given, show them.  Otherwise implicitly
+       uses the root level of the tree as the sole path argument.
+
+
+Output Format
+-------------
+        <mode> SP <type> SP <object> TAB <file>
+
+When `-z` option is not used, TAB, LF, and backslash characters
+in pathnames are represented as `\t`, `\n`, and `\\`,
+respectively.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+Completely rewritten from scratch by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
new file mode 100644 (file)
index 0000000..dc7d725
--- /dev/null
@@ -0,0 +1,65 @@
+git-mailinfo(1)
+===============
+
+NAME
+----
+git-mailinfo - Extracts patch from a single e-mail message.
+
+
+SYNOPSIS
+--------
+'git-mailinfo' [-k] [-u] <msg> <patch>
+
+
+DESCRIPTION
+-----------
+Reading a single e-mail message from the standard input, and
+writes the commit log message in <msg> file, and the patches in
+<patch> file.  The author name, e-mail and e-mail subject are
+written out to the standard output to be used by git-applypatch
+to create a commit.  It is usually not necessary to use this
+command directly.
+
+
+OPTIONS
+-------
+-k::
+       Usually the program 'cleans up' the Subject: header line
+       to extract the title line for the commit log message,
+       among which (1) remove 'Re:' or 're:', (2) leading
+       whitespaces, (3) '[' up to ']', typically '[PATCH]', and
+       then prepends "[PATCH] ".  This flag forbids this
+       munging, and is most useful when used to read back 'git
+       format-patch --mbox' output.
+
+-u::
+       By default, the commit log message, author name and
+       author email are taken from the e-mail without any
+       charset conversion, after minimally decoding MIME
+       transfer encoding.  This flag causes the resulting
+       commit to be encoded in utf-8 by transliterating them.
+       Note that the patch is always used as is without charset
+       conversion, even with this flag.
+
+<msg>::
+       The commit log message extracted from e-mail, usually
+       except the title line which comes from e-mail Subject.
+
+<patch>::
+       The patch extracted from e-mail.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>
+
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-mailsplit.txt b/Documentation/git-mailsplit.txt
new file mode 100644 (file)
index 0000000..03a9477
--- /dev/null
@@ -0,0 +1,45 @@
+git-mailsplit(1)
+================
+
+NAME
+----
+git-mailsplit - Totally braindamaged mbox splitter program.
+
+SYNOPSIS
+--------
+'git-mailsplit' [-d<prec>] [<mbox>] <directory>
+
+DESCRIPTION
+-----------
+Splits a mbox file into a list of files: "0001" "0002" ..  in the specified
+directory so you can process them further from there.
+
+OPTIONS
+-------
+<mbox>::
+       Mbox file to split.  If not given, the mbox is read from
+       the standard input.
+
+<directory>::
+       Directory in which to place the individual messages.
+
+-d<prec>::
+       Instead of the default 4 digits with leading zeros,
+       different precision can be specified for the generated
+       filenames.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+and Junio C Hamano <junkio@cox.net>
+
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt
new file mode 100644 (file)
index 0000000..d1d56f1
--- /dev/null
@@ -0,0 +1,33 @@
+git-merge-base(1)
+=================
+
+NAME
+----
+git-merge-base - Finds as good a common ancestor as possible for a merge
+
+
+SYNOPSIS
+--------
+'git-merge-base' <commit> <commit>
+
+DESCRIPTION
+-----------
+"git-merge-base" finds as good a common ancestor as possible. Given a
+selection of equally good common ancestors it should not be relied on
+to decide in any particular way.
+
+The "git-merge-base" algorithm is still in flux - use the source...
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt
new file mode 100644 (file)
index 0000000..d072fda
--- /dev/null
@@ -0,0 +1,88 @@
+git-merge-index(1)
+==================
+
+NAME
+----
+git-merge-index - Runs a merge for files needing merging
+
+
+SYNOPSIS
+--------
+'git-merge-index' [-o] [-q] <merge-program> (-a | -- | <file>\*)
+
+DESCRIPTION
+-----------
+This looks up the <file>(s) in the cache and, if there are any merge
+entries, passes the SHA1 hash for those files as arguments 1, 2, 3 (empty
+argument if no file), and <file> as argument 4.  File modes for the three
+files are passed as arguments 5, 6 and 7.
+
+OPTIONS
+-------
+--::
+       Interpret all following arguments as filenames.
+
+-a::
+       Run merge against all files in the cache that need merging.
+
+-o::
+       Instead of stopping at the first failed merge, do all of them
+       in one shot - continue with merging even when previous merges
+       returned errors, and only return the error code after all the
+       merges are over.
+
+-q::
+       Do not complain about failed merge program (the merge program
+       failure usually indicates conflicts during merge). This is for
+       porcelains which might want to emit custom messages.
+
+If "git-merge-index" is called with multiple <file>s (or -a) then it
+processes them in turn only stopping if merge returns a non-zero exit
+code.
+
+Typically this is run with the a script calling the merge command from
+the RCS package.
+
+A sample script called "git-merge-one-file" is included in the
+distribution.
+
+ALERT ALERT ALERT! The git "merge object order" is different from the
+RCS "merge" program merge object order. In the above ordering, the
+original is first. But the argument order to the 3-way merge program
+"merge" is to have the original in the middle. Don't ask me why.
+
+Examples:
+
+  torvalds@ppc970:~/merge-test> git-merge-index cat MM
+  This is MM from the original tree.                   # original
+  This is modified MM in the branch A.                 # merge1
+  This is modified MM in the branch B.                 # merge2
+  This is modified MM in the branch B.                 # current contents
+
+or 
+
+  torvalds@ppc970:~/merge-test> git-merge-index cat AA MM
+  cat: : No such file or directory
+  This is added AA in the branch A.
+  This is added AA in the branch B.
+  This is added AA in the branch B.
+  fatal: merge program failed
+
+where the latter example shows how "git-merge-index" will stop trying to
+merge once anything has returned an error (ie "cat" returned an error
+for the AA file, because it didn't exist in the original, and thus
+"git-merge-index" didn't even try to merge the MM thing).
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+One-shot merge by Petr Baudis <pasky@ucw.cz>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-merge-one-file.txt b/Documentation/git-merge-one-file.txt
new file mode 100644 (file)
index 0000000..86aad37
--- /dev/null
@@ -0,0 +1,30 @@
+git-merge-one-file(1)
+=====================
+
+NAME
+----
+git-merge-one-file - The standard helper program to use with "git-merge-index"
+
+
+SYNOPSIS
+--------
+'git-merge-one-file'
+
+DESCRIPTION
+-----------
+This is the standard helper program to use with "git-merge-index"
+to resolve a merge after the trivial merge done with "git-read-tree -m".
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>,
+Junio C Hamano <junkio@cox.net> and Petr Baudis <pasky@suse.cz>.
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
new file mode 100644 (file)
index 0000000..a007a8b
--- /dev/null
@@ -0,0 +1,51 @@
+git-merge(1)
+============
+
+NAME
+----
+git-merge - Grand Unified Merge Driver
+
+
+SYNOPSIS
+--------
+'git-merge' [-n] [-s <strategy>]... <msg> <head> <remote> <remote>...
+
+
+DESCRIPTION
+-----------
+This is the top-level user interface to the merge machinery
+which drives multiple merge strategy scripts.
+
+
+OPTIONS
+-------
+-n::
+       Do not show diffstat at the end of the merge.
+
+-s <strategy>::
+       use that merge strategy; can be given more than once to
+       specify them in the order they should be tried.  If
+       there is no `-s` option, built-in list of strategies is
+       used instead.
+
+<head>::
+       our branch head commit.
+
+<remote>::
+       other branch head merged into our branch.  You need at
+       least one <remote>.  Specifying more than one <remote>
+       obviously means you are trying an Octopus.
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-mktag.txt b/Documentation/git-mktag.txt
new file mode 100644 (file)
index 0000000..2860a3d
--- /dev/null
@@ -0,0 +1,47 @@
+git-mktag(1)
+============
+
+NAME
+----
+git-mktag - Creates a tag object
+
+
+SYNOPSIS
+--------
+'git-mktag' < signature_file
+
+DESCRIPTION
+-----------
+Reads a tag contents on standard input and creates a tag object
+that can also be used to sign other objects.
+
+The output is the new tag's <object> identifier.
+
+Tag Format
+----------
+A tag signature file has a very simple fixed format: three lines of
+
+  object <sha1>
+  type <typename>
+  tag <tagname>
+
+followed by some 'optional' free-form signature that git itself
+doesn't care about, but that can be verified with gpg or similar.
+
+The size of the full object is artificially limited to 8kB.  (Just
+because I'm a lazy bastard, and if you can't fit a signature in that
+size, you're doing something wrong)
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt
new file mode 100644 (file)
index 0000000..f2d5882
--- /dev/null
@@ -0,0 +1,51 @@
+git-mv(1)
+=========
+
+NAME
+----
+git-mv - Script used to move or rename a file, directory or symlink.
+
+
+SYNOPSIS
+--------
+'git-mv' [-f] [-n] <source> <destination>
+'git-mv' [-f] [-k] [-n] <source> ... <destination directory>
+
+DESCRIPTION
+-----------
+This script is used to move or rename a file, directory or symlink.
+In the first form, it renames <source>, which must exist and be either
+a file, symlink or directory, to <destination>, which must not exist.
+In the second form, the last argument has to be an existing
+directory; the given sources will be moved into this directory.
+
+The index is updated after successful completion, but the change must still be
+committed.
+
+OPTIONS
+-------
+-f::
+       Force renaming or moving even targets exist
+-k::
+        Skip move or rename actions which would lead to an error
+       condition. An error happens when a source is neither existing nor
+        controlled by GIT, or when it would overwrite an existing
+        file unless '-f' is given.
+-n::
+       Do nothing; only show what would happen
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+Rewritten by Ryan Anderson <ryan@michonline.com>
+Move functionality added by Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
new file mode 100644 (file)
index 0000000..e37b0b8
--- /dev/null
@@ -0,0 +1,66 @@
+git-name-rev(1)
+===============
+
+NAME
+----
+git-name-rev - Find symbolic names for given revs.
+
+
+SYNOPSIS
+--------
+'git-name-rev' [--tags] ( --all | --stdin | <commitish>... )
+
+DESCRIPTION
+-----------
+Finds symbolic names suitable for human digestion for revisions given in any
+format parsable by git-rev-parse.
+
+
+OPTIONS
+-------
+
+--tags::
+       Do not use branch names, but only tags to name the commits
+
+--all::
+       List all commits reachable from all refs
+
+--stdin::
+       Read from stdin, append "(<rev_name>)" to all sha1's of name'able
+       commits, and pass to stdout
+
+EXAMPLE
+-------
+
+Given a commit, find out where it is relative to the local refs. Say somebody
+wrote you about that phantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
+Of course, you look into the commit, but that only tells you what happened, but
+not the context.
+
+Enter git-name-rev:
+
+------------
+% git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
+------------
+
+Now you are wiser, because you know that it happened 940 revisions before v0.99.
+
+Another nice thing you can do is:
+
+------------
+% git log | git name-rev --stdin
+------------
+
+
+Author
+------
+Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
+
+Documentation
+--------------
+Documentation by Johannes Schindelin.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-octopus.txt b/Documentation/git-octopus.txt
new file mode 100644 (file)
index 0000000..6e32ea3
--- /dev/null
@@ -0,0 +1,38 @@
+git-octopus(1)
+==============
+
+NAME
+----
+git-octopus - Merge more than two commits.
+
+
+SYNOPSIS
+--------
+'git-octopus'
+
+DESCRIPTION
+-----------
+After running 'git fetch', $GIT_DIR/FETCH_HEAD contains the
+following information, one line per remote ref:
+
+------------------------------------------------
+<object name>  <ref name> from <repository>
+------------------------------------------------
+
+Using this information, create and commit an Octopus merge on
+top of the current HEAD.
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
new file mode 100644 (file)
index 0000000..caf5d0d
--- /dev/null
@@ -0,0 +1,84 @@
+git-pack-objects(1)
+===================
+
+NAME
+----
+git-pack-objects - Create a packed archive of objects.
+
+
+SYNOPSIS
+--------
+'git-pack-objects' [--incremental] [--window=N] [--depth=N] {--stdout | base-name} < object-list
+
+
+DESCRIPTION
+-----------
+Reads list of objects from the standard input, and writes a packed
+archive with specified base-name, or to the standard output.
+
+A packed archive is an efficient way to transfer set of objects
+between two repositories, and also is an archival format which
+is efficient to access.  The packed archive format (.pack) is
+designed to be unpackable without having anything else, but for
+random access, accompanied with the pack index file (.idx).
+
+'git-unpack-objects' command can read the packed archive and
+expand the objects contained in the pack into "one-file
+one-object" format; this is typically done by the smart-pull
+commands when a pack is created on-the-fly for efficient network
+transport by their peers.
+
+Placing both in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
+any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)
+enables git to read from such an archive.
+
+
+OPTIONS
+-------
+base-name::
+       Write into a pair of files (.pack and .idx), using
+       <base-name> to determine the name of the created file.
+       When this option is used, the two files are written in
+       <base-name>-<SHA1>.{pack,idx} files.  <SHA1> is a hash
+       of object names (currently in random order so it does
+       not have any useful meaning) to make the resulting
+       filename reasonably unique, and written to the standard
+       output of the command.
+
+--stdout::
+       Write the pack contents (what would have been writtin to
+       .pack file) out to the standard output.
+
+--window and --depth::
+       These two options affects how the objects contained in
+       the pack are stored using delta compression.  The
+       objects are first internally sorted by type, size and
+       optionally names and compared against the other objects
+       within --window to see if using delta compression saves
+       space.  --depth limits the maximum delta depth; making
+       it too deep affects the performance on the unpacker
+       side, because delta data needs to be applied that many
+       times to get to the necessary object.
+
+--incremental::
+       This flag causes an object already in a pack ignored
+       even if it appears in the standard input.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+-------------
+Documentation by Junio C Hamano
+
+See-Also
+--------
+gitlink:git-repack[1]
+gitlink:git-prune-packed[1]
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-parse-remote.txt b/Documentation/git-parse-remote.txt
new file mode 100644 (file)
index 0000000..fc27afe
--- /dev/null
@@ -0,0 +1,48 @@
+git-parse-remote(1)
+===================
+
+NAME
+----
+git-parse-remote - Routines to help parsing $GIT_DIR/remotes/
+
+
+SYNOPSIS
+--------
+'. git-parse-remote'
+
+DESCRIPTION
+-----------
+This script is included in various scripts to supply
+routines to parse files under $GIT_DIR/remotes/ and
+$GIT_DIR/branches/.
+
+The primary entry points are:
+
+get_remote_refs_for_fetch::
+       Given the list of user-supplied `<repo> <refspec>...`,
+       return the list of refs to fetch after canonicalizing
+       them into `$GIT_DIR` relative paths
+       (e.g. `refs/heads/foo`).  When `<refspec>...` is empty
+       the returned list of refs consists of the defaults
+       for the given `<repo>`, if specified in
+       `$GIT_DIR/remotes/` or `$GIT_DIR/branches/`.
+
+get_remote_refs_for_push::
+       Given the list of user-supplied `<repo> <refspec>...`,
+       return the list of refs to push in a form suitable to be
+       fed to the `git-send-pack` command.  When `<refspec>...`
+       is empty the returned list of refs consists of the
+       defaults for the given `<repo>`, if specified in
+       `$GIT_DIR/remotes/`.
+
+Author
+------
+Written by Junio C Hamano.
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-patch-id.txt b/Documentation/git-patch-id.txt
new file mode 100644 (file)
index 0000000..3e560a3
--- /dev/null
@@ -0,0 +1,37 @@
+git-patch-id(1)
+===============
+
+NAME
+----
+git-patch-id - Generate a patch ID.
+
+SYNOPSIS
+--------
+'git-patch-id' < <patch>
+
+DESCRIPTION
+-----------
+A "patch ID" is nothing but a SHA1 of the diff associated with a patch, with
+whitespace and line numbers ignored.  As such, it's "reasonably stable", but at
+the same time also reasonably unique, ie two patches that have the same "patch
+ID" are almost guaranteed to be the same thing.
+
+IOW, you can use this thing to look for likely duplicate commits.
+
+OPTIONS
+-------
+<patch>::
+       The diff to create the ID of.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-peek-remote.txt b/Documentation/git-peek-remote.txt
new file mode 100644 (file)
index 0000000..915d3f8
--- /dev/null
@@ -0,0 +1,52 @@
+git-peek-remote(1)
+==================
+
+NAME
+----
+git-peek-remote - Lists the references in a remote repository.
+
+
+SYNOPSIS
+--------
+'git-peek-remote' [--exec=<git-upload-pack>] [<host>:]<directory>
+
+DESCRIPTION
+-----------
+Lists the references the remote repository has, and optionally
+stores them in the local repository under the same name.
+
+OPTIONS
+-------
+--exec=<git-upload-pack>::
+       Use this to specify the path to 'git-upload-pack' on the
+       remote side, if it is not found on your $PATH. Some
+       installations of sshd ignores the user's environment
+       setup scripts for login shells (e.g. .bash_profile) and
+       your privately installed git may not be found on the system
+       default $PATH.  Another workaround suggested is to set
+       up your $PATH in ".bashrc", but this flag is for people
+       who do not want to pay the overhead for non-interactive
+       shells, but prefer having a lean .bashrc file (they set most of
+       the things up in .bash_profile).
+
+<host>::
+       A remote host that houses the repository.  When this
+       part is specified, 'git-upload-pack' is invoked via
+       ssh.
+
+<directory>::
+       The repository to sync from.
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-prune-packed.txt b/Documentation/git-prune-packed.txt
new file mode 100644 (file)
index 0000000..28a1500
--- /dev/null
@@ -0,0 +1,42 @@
+git-prune-packed(1)
+=====================
+
+NAME
+----
+git-prune-packed - Program used to remove the extra object files that are now
+residing in a pack file.
+
+
+SYNOPSIS
+--------
+'git-prune-packed'
+
+DESCRIPTION
+-----------
+This program search the GIT_OBJECT_DIR for all objects that currently exist in
+a pack file as well as the independent object directories.
+
+All such extra objects are removed.
+
+A pack is a collection of objects, individually compressed, with delta
+compression applied, stored in a single file, with an associated index file.
+
+Packs are used to reduce the load on mirror systems, backup engines, disk storage, etc.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Ryan Anderson <ryan@michonline.com>
+
+See-Also
+--------
+gitlink:git-pack-objects[1]
+gitlink:git-repack[1]
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt
new file mode 100644 (file)
index 0000000..3367c9b
--- /dev/null
@@ -0,0 +1,42 @@
+git-prune(1)
+============
+
+NAME
+----
+git-prune - Prunes all unreachable objects from the object database
+
+
+SYNOPSIS
+--------
+'git-prune' [-n]
+
+DESCRIPTION
+-----------
+
+This runs `git-fsck-objects --unreachable` using the heads
+specified on the command line (or `$GIT_DIR/refs/heads/\*` and
+`$GIT_DIR/refs/tags/\*` if none is specified), and prunes all
+unreachable objects from the object database.  In addition, it
+prunes the unpacked objects that are also found in packs by
+running `git prune-packed`.
+
+OPTIONS
+-------
+
+-n::
+       Do not remove anything; just report what it would
+       remove.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
new file mode 100644 (file)
index 0000000..bae05de
--- /dev/null
@@ -0,0 +1,44 @@
+git-pull(1)
+===========
+
+NAME
+----
+git-pull - Pull and merge from another repository.
+
+
+SYNOPSIS
+--------
+'git-pull' <repository> <refspec>...
+
+
+DESCRIPTION
+-----------
+Runs 'git-fetch' with the given parameters.
+
+When only one ref is downloaded, runs 'git resolve' to merge it
+into the local HEAD.  Otherwise uses 'git octopus' to merge them
+into the local HEAD.
+
+
+OPTIONS
+-------
+include::pull-fetch-param.txt[]
+
+-a, \--append::
+       Append ref names and object names of fetched refs to the
+       existing contents of $GIT_DIR/FETCH_HEAD.  Without this
+       option old data in $GIT_DIR/FETCH_HEAD will be overwritten.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+and Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
new file mode 100644 (file)
index 0000000..f45ac5e
--- /dev/null
@@ -0,0 +1,45 @@
+git-push(1)
+===========
+
+NAME
+----
+git-push - Update remote refs along with associated objects.
+
+
+SYNOPSIS
+--------
+'git-push' [--all] [--force] <repository> <refspec>...
+
+DESCRIPTION
+-----------
+
+Updates remote refs using local refs, while sending objects
+necessary to complete the given refs.
+
+
+OPTIONS
+-------
+include::pull-fetch-param.txt[]
+
+\--all::
+       Instead of naming each ref to push, specifies all refs
+       to be pushed.
+
+-f, \--force::
+       Usually, the command refuses to update a local ref that is
+       not an ancestor of the remote ref used to overwrite it.
+       This flag disables the check.  What this means is that the
+       local repository can lose commits; use it with care.
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
new file mode 100644 (file)
index 0000000..7db5fb5
--- /dev/null
@@ -0,0 +1,277 @@
+git-read-tree(1)
+================
+
+NAME
+----
+git-read-tree - Reads tree information into the directory cache
+
+
+SYNOPSIS
+--------
+'git-read-tree' (<tree-ish> | [-m [-u|-i]] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
+
+
+DESCRIPTION
+-----------
+Reads the tree information given by <tree-ish> into the directory cache,
+but does not actually *update* any of the files it "caches". (see:
+git-checkout-index)
+
+Optionally, it can merge a tree into the cache, perform a
+fast-forward (i.e. 2-way) merge, or a 3-way merge, with the -m
+flag.  When used with -m, the -u flag causes it to also update
+the files in the work tree with the result of the merge.
+
+Trivial merges are done by "git-read-tree" itself.  Only conflicting paths
+will be in unmerged state when "git-read-tree" returns.
+
+OPTIONS
+-------
+-m::
+       Perform a merge, not just a read.
+
+-u::
+       After a successful merge, update the files in the work
+       tree with the result of the merge.
+
+-i::
+       Usually a merge requires the index file as well as the
+       files in the working tree are up to date with the
+       current head commit, in order not to lose local
+       changes.  This flag disables the check with the working
+       tree and is meant to be used when creating a merge of
+       trees that are not directly related to the current
+       working tree status into a temporary index file.
+
+
+<tree-ish#>::
+       The id of the tree object(s) to be read/merged.
+
+
+Merging
+-------
+If '-m' is specified, "git-read-tree" can perform 3 kinds of
+merge, a single tree merge if only 1 tree is given, a
+fast-forward merge with 2 trees, or a 3-way merge if 3 trees are
+provided.
+
+
+Single Tree Merge
+~~~~~~~~~~~~~~~~~
+If only 1 tree is specified, git-read-tree operates as if the user did not
+specify '-m', except that if the original cache has an entry for a
+given pathname, and the contents of the path matches with the tree
+being read, the stat info from the cache is used. (In other words, the
+cache's stat()s take precedence over the merged tree's).
+
+That means that if you do a "git-read-tree -m <newtree>" followed by a
+"git-checkout-index -f -u -a", the "git-checkout-index" only checks out
+the stuff that really changed.
+
+This is used to avoid unnecessary false hits when "git-diff-files" is
+run after git-read-tree.
+
+
+Two Tree Merge
+~~~~~~~~~~~~~~
+
+Typically, this is invoked as "git-read-tree -m $H $M", where $H
+is the head commit of the current repository, and $M is the head
+of a foreign tree, which is simply ahead of $H (i.e. we are in a
+fast forward situation).
+
+When two trees are specified, the user is telling git-read-tree
+the following:
+
+     1. The current index and work tree is derived from $H, but
+        the user may have local changes in them since $H;
+
+     2. The user wants to fast-forward to $M.
+
+In this case, the "git-read-tree -m $H $M" command makes sure
+that no local change is lost as the result of this "merge".
+Here are the "carry forward" rules:
+
+        I (index)           H        M        Result
+       -------------------------------------------------------
+      0 nothing             nothing  nothing  (does not happen)
+      1 nothing             nothing  exists   use M
+      2 nothing             exists   nothing  remove path from cache
+      3 nothing             exists   exists   use M
+
+        clean I==H  I==M
+       ------------------
+      4 yes   N/A   N/A     nothing  nothing  keep index
+      5 no    N/A   N/A     nothing  nothing  keep index
+
+      6 yes   N/A   yes     nothing  exists   keep index
+      7 no    N/A   yes     nothing  exists   keep index
+      8 yes   N/A   no      nothing  exists   fail
+      9 no    N/A   no      nothing  exists   fail
+
+     10 yes   yes   N/A     exists   nothing  remove path from cache
+     11 no    yes   N/A     exists   nothing  fail
+     12 yes   no    N/A     exists   nothing  fail
+     13 no    no    N/A     exists   nothing  fail
+
+        clean (H=M)
+       ------
+     14 yes                 exists   exists   keep index
+     15 no                  exists   exists   keep index
+
+        clean I==H  I==M (H!=M)
+       ------------------
+     16 yes   no    no      exists   exists   fail
+     17 no    no    no      exists   exists   fail
+     18 yes   no    yes     exists   exists   keep index
+     19 no    no    yes     exists   exists   keep index
+     20 yes   yes   no      exists   exists   use M
+     21 no    yes   no      exists   exists   fail
+
+In all "keep index" cases, the cache entry stays as in the
+original index file.  If the entry were not up to date,
+git-read-tree keeps the copy in the work tree intact when
+operating under the -u flag.
+
+When this form of git-read-tree returns successfully, you can
+see what "local changes" you made are carried forward by running
+"git-diff-index --cached $M".  Note that this does not
+necessarily match "git-diff-index --cached $H" would have
+produced before such a two tree merge.  This is because of cases
+18 and 19 --- if you already had the changes in $M (e.g. maybe
+you picked it up via e-mail in a patch form), "git-diff-index
+--cached $H" would have told you about the change before this
+merge, but it would not show in "git-diff-index --cached $M"
+output after two-tree merge.
+
+
+3-Way Merge
+~~~~~~~~~~~
+Each "index" entry has two bits worth of "stage" state. stage 0 is the
+normal one, and is the only one you'd see in any kind of normal use.
+
+However, when you do "git-read-tree" with three trees, the "stage"
+starts out at 1.
+
+This means that you can do
+
+       git-read-tree -m <tree1> <tree2> <tree3>
+
+and you will end up with an index with all of the <tree1> entries in
+"stage1", all of the <tree2> entries in "stage2" and all of the
+<tree3> entries in "stage3".
+
+Furthermore, "git-read-tree" has special-case logic that says: if you see
+a file that matches in all respects in the following states, it
+"collapses" back to "stage0":
+
+   - stage 2 and 3 are the same; take one or the other (it makes no
+     difference - the same work has been done on stage 2 and 3)
+
+   - stage 1 and stage 2 are the same and stage 3 is different; take
+     stage 3 (some work has been done on stage 3)
+
+   - stage 1 and stage 3 are the same and stage 2 is different take
+     stage 2 (some work has been done on stage 2)
+
+The "git-write-tree" command refuses to write a nonsensical tree, and it
+will complain about unmerged entries if it sees a single entry that is not
+stage 0.
+
+Ok, this all sounds like a collection of totally nonsensical rules,
+but it's actually exactly what you want in order to do a fast
+merge. The different stages represent the "result tree" (stage 0, aka
+"merged"), the original tree (stage 1, aka "orig"), and the two trees
+you are trying to merge (stage 2 and 3 respectively).
+
+The order of stages 1, 2 and 3 (hence the order of three
+<tree-ish> command line arguments) are significant when you
+start a 3-way merge with an index file that is already
+populated.  Here is an outline of how the algorithm works:
+
+- if a file exists in identical format in all three trees, it will
+  automatically collapse to "merged" state by git-read-tree.
+
+- a file that has _any_ difference what-so-ever in the three trees
+  will stay as separate entries in the index. It's up to "porcelain
+  policy" to determine how to remove the non-0 stages, and insert a
+  merged version.
+
+- the index file saves and restores with all this information, so you
+  can merge things incrementally, but as long as it has entries in
+  stages 1/2/3 (ie "unmerged entries") you can't write the result. So
+  now the merge algorithm ends up being really simple:
+
+  * you walk the index in order, and ignore all entries of stage 0,
+    since they've already been done.
+
+  * if you find a "stage1", but no matching "stage2" or "stage3", you
+    know it's been removed from both trees (it only existed in the
+    original tree), and you remove that entry.
+
+  * if you find a matching "stage2" and "stage3" tree, you remove one
+    of them, and turn the other into a "stage0" entry. Remove any
+    matching "stage1" entry if it exists too.  .. all the normal
+    trivial rules ..
+
+You would normally use "git-merge-index" with supplied
+"git-merge-one-file" to do this last step.  The script
+does not touch the files in the work tree, and the entire merge
+happens in the index file.  In other words, there is no need to
+worry about what is in the working directory, since it is never
+shown and never used.
+
+When you start a 3-way merge with an index file that is already
+populated, it is assumed that it represents the state of the
+files in your work tree, and you can even have files with
+changes unrecorded in the index file.  It is further assumed
+that this state is "derived" from the stage 2 tree.  The 3-way
+merge refuses to run if it finds an entry in the original index
+file that does not match stage 2.
+
+This is done to prevent you from losing your work-in-progress
+changes.  To illustrate, suppose you start from what has been
+commited last to your repository:
+
+    $ JC=`cat .git/HEAD`
+    $ git-checkout-index -f -u -a $JC
+
+You do random edits, without running git-update-index.  And then
+you notice that the tip of your "upstream" tree has advanced
+since you pulled from him:
+
+    $ git-fetch rsync://.... linus
+    $ LT=`cat .git/MERGE_HEAD`
+
+Your work tree is still based on your HEAD ($JC), but you have
+some edits since.  Three-way merge makes sure that you have not
+added or modified cache entries since $JC, and if you haven't,
+then does the right thing.  So with the following sequence:
+
+    $ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT
+    $ git-merge-index git-merge-one-file -a
+    $ echo "Merge with Linus" | \
+      git-commit-tree `git-write-tree` -p $JC -p $LT
+
+what you would commit is a pure merge between $JC and LT without
+your work-in-progress changes, and your work tree would be
+updated to the result of the merge.
+
+
+See Also
+--------
+gitlink:git-write-tree[1]; gitlink:git-ls-files[1]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
new file mode 100644 (file)
index 0000000..16c158f
--- /dev/null
@@ -0,0 +1,35 @@
+git-rebase(1)
+=============
+
+NAME
+----
+git-rebase - Rebase local commits to new upstream head.
+
+SYNOPSIS
+--------
+'git-rebase' <upstream> [<head>]
+
+DESCRIPTION
+-----------
+Rebases local commits to the new head of the upstream tree.
+
+OPTIONS
+-------
+<upstream>::
+       Upstream branch to compare against.
+
+<head>::
+       Working branch; defaults to HEAD.
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
new file mode 100644 (file)
index 0000000..8afde14
--- /dev/null
@@ -0,0 +1,95 @@
+git-receive-pack(1)
+===================
+
+NAME
+----
+git-receive-pack - Receive what is pushed into it
+
+
+SYNOPSIS
+--------
+'git-receive-pack' <directory>
+
+DESCRIPTION
+-----------
+Invoked by 'git-send-pack' and updates the repository with the
+information fed from the remote end.
+
+This command is usually not invoked directly by the end user.
+The UI for the protocol is on the 'git-send-pack' side, and the
+program pair is meant to be used to push updates to remote
+repository.  For pull operations, see 'git-fetch-pack' and
+'git-clone-pack'.
+
+The command allows for creation and fast forwarding of sha1 refs
+(heads/tags) on the remote end (strictly speaking, it is the
+local end receive-pack runs, but to the user who is sitting at
+the send-pack end, it is updating the remote.  Confused?)
+
+Before each ref is updated, if $GIT_DIR/hooks/update file exists
+and executable, it is called with three parameters:
+
+       $GIT_DIR/hooks/update refname sha1-old sha1-new
+
+The refname parameter is relative to $GIT_DIR; e.g. for the
+master head this is "refs/heads/master".  Two sha1 are the
+object names for the refname before and after the update.  Note
+that the hook is called before the refname is updated, so either
+sha1-old is 0{40} (meaning there is no such ref yet), or it
+should match what is recorded in refname.
+
+The hook should exit with non-zero status if it wants to
+disallow updating the named ref.  Otherwise it should exit with
+zero.
+
+Using this hook, it is easy to generate mails on updates to
+the local repository. This example script sends a mail with
+the commits pushed to the repository:
+
+       #!/bin/sh
+       # mail out commit update information.
+       if expr "$2" : '0*$' >/dev/null
+       then
+               echo "Created a new ref, with the following commits:"
+               git-rev-list --pretty "$2"
+       else
+               echo "New commits:"
+               git-rev-list --pretty "$3" "^$2"
+       fi |
+       mail -s "Changes to ref $1" commit-list@mydomain
+       exit 0
+
+Another hook $GIT_DIR/hooks/post-update, if exists and
+executable, is called with the list of refs that have been
+updated.  This can be used to implement repository wide cleanup
+task if needed.  The exit code from this hook invocation is
+ignored; the only thing left for git-receive-pack to do at that
+point is to exit itself anyway.  This hook can be used, for
+example, to run "git-update-server-info" if the repository is
+packed and is served via a dumb transport.
+
+       #!/bin/sh
+       exec git-update-server-info
+
+OPTIONS
+-------
+<directory>::
+       The repository to sync into.
+
+
+SEE ALSO
+--------
+gitlink:git-send-pack[1]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-relink.txt b/Documentation/git-relink.txt
new file mode 100644 (file)
index 0000000..6240535
--- /dev/null
@@ -0,0 +1,37 @@
+git-relink(1)
+=============
+
+NAME
+----
+git-relink - Hardlink common objects in local repositories.
+
+SYNOPSIS
+--------
+'git-relink' [--safe] <dir> <dir> [<dir>]\*
+
+DESCRIPTION
+-----------
+This will scan 2 or more object repositories and look for common objects, check
+if they are hardlinked, and replace one with a hardlink to the other if not.
+
+OPTIONS
+-------
+--safe::
+       Stops if two objects with the same hash exist but have different sizes.
+       Default is to warn and continue.
+
+<dir>::
+       Directories containing a .git/objects/ subdirectory.
+
+Author
+------
+Written by Ryan Anderson <ryan@michonline.com>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-rename.txt b/Documentation/git-rename.txt
new file mode 100644 (file)
index 0000000..583cb03
--- /dev/null
@@ -0,0 +1,32 @@
+git-rename(1)
+=============
+
+NAME
+----
+git-rename - Script used to rename a file, directory or symlink.
+
+
+SYNOPSIS
+--------
+'git-rename' <source> <destination>
+
+DESCRIPTION
+-----------
+This script is used to rename a file, directory or symlink.
+
+The index is updated after successful completion, but the change must still be
+committed.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+Rewritten by Ryan Anderson <ryan@michonline.com>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
new file mode 100644 (file)
index 0000000..0c1ae49
--- /dev/null
@@ -0,0 +1,59 @@
+git-repack(1)
+=============
+
+NAME
+----
+git-repack - Script used to pack a repository from a collection of
+objects into pack files.
+
+
+SYNOPSIS
+--------
+'git-repack' [-a] [-d]
+
+DESCRIPTION
+-----------
+
+This script is used to combine all objects that do not currently
+reside in a "pack", into a pack.
+
+A pack is a collection of objects, individually compressed, with
+delta compression applied, stored in a single file, with an
+associated index file.
+
+Packs are used to reduce the load on mirror systems, backup
+engines, disk storage, etc.
+
+OPTIONS
+-------
+
+-a::
+       Instead of incrementally packing the unpacked objects,
+       pack everything available into a single pack.
+       Especially useful when packing a repository that is used
+       for a private development and there no need to worry
+       about people fetching via dumb protocols from it.  Use
+       with '-d'.
+
+-d::
+       After packing, if the newly created packs make some
+       existing packs redundant, remove the redundant packs.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Ryan Anderson <ryan@michonline.com>
+
+See-Also
+--------
+gitlink:git-pack-objects[1]
+gitlink:git-prune-packed[1]
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-request-pull.txt b/Documentation/git-request-pull.txt
new file mode 100644 (file)
index 0000000..2463ec9
--- /dev/null
@@ -0,0 +1,40 @@
+git-request-pull(1)
+===================
+
+NAME
+----
+git-request-pull - Generates a summary of pending changes.
+
+SYNOPSIS
+--------
+'git-request-pull' <start> <url> [<end>]
+
+DESCRIPTION
+-----------
+
+Summarizes the changes between two commits to the standard output, and includes
+the given URL in the generated summary.
+
+OPTIONS
+-------
+<start>::
+       Commit to start at.
+
+<url>::
+       URL to include in the summary.
+
+<end>::
+       Commit to send at; defaults to HEAD.
+
+Author
+------
+Written by Ryan Anderson <ryan@michonline.com> and Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
new file mode 100644 (file)
index 0000000..31ec207
--- /dev/null
@@ -0,0 +1,45 @@
+git-reset(1)
+============
+
+NAME
+----
+git-reset - Reset current HEAD to the specified state.
+
+SYNOPSIS
+--------
+'git-reset' [--mixed | --soft | --hard] [<commit-ish>]
+
+DESCRIPTION
+-----------
+Sets the current head to the specified commit and optionally resets the
+index and working tree to match.
+
+OPTIONS
+-------
+--mixed::
+       Like --soft but reports what has not been updated. This is the
+       default action.
+
+--soft::
+       Does not touch the index file nor the working tree at all, but
+       requires them in a good order.
+
+--hard::
+       Matches the working tree and index to that of the tree being
+       switched to.
+
+<commit-ish>::
+       Commit to make the current HEAD.
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net> and Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-resolve.txt b/Documentation/git-resolve.txt
new file mode 100644 (file)
index 0000000..4e57c2b
--- /dev/null
@@ -0,0 +1,36 @@
+git-resolve(1)
+==============
+
+NAME
+----
+git-resolve - Merge two commits
+
+
+SYNOPSIS
+--------
+'git-resolve' <current> <merged> <message>
+
+DESCRIPTION
+-----------
+Given two commits and a merge message, merge the <merged> commit
+into <current> commit, with the commit log message <message>.
+
+When <current> is a descendant of <merged>, or <current> is an
+ancestor of <merged>, no new commit is created and the <message>
+is ignored.  The former is informally called "already up to
+date", and the latter is often called "fast forward".
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and
+Dan Holmsand <holmsand@gmail.com>.
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
new file mode 100644 (file)
index 0000000..7dbb7c6
--- /dev/null
@@ -0,0 +1,102 @@
+git-rev-list(1)
+===============
+
+NAME
+----
+git-rev-list - Lists commit objects in reverse chronological order
+
+
+SYNOPSIS
+--------
+'git-rev-list' [ *--max-count*=number ] [ *--max-age*=timestamp ] [ *--min-age*=timestamp ] [ *--bisect* ] [ *--pretty* ] [ *--objects* ] [ *--merge-order* [ *--show-breaks* ] ] <commit> [ <commit> ...] [ ^<commit> ...]
+
+DESCRIPTION
+-----------
+Lists commit objects in reverse chronological order starting at the
+given commit(s), taking ancestry relationship into account.  This is
+useful to produce human-readable log output.
+
+Commits which are stated with a preceding '^' cause listing to stop at
+that point. Their parents are implied. "git-rev-list foo bar ^baz" thus
+means "list all the commits which are included in 'foo' and 'bar', but
+not in 'baz'".
+
+OPTIONS
+-------
+--pretty::
+       Print the contents of the commit changesets in human-readable form.
+
+--objects::
+       Print the object IDs of any object referenced by the listed commits.
+       'git-rev-list --objects foo ^bar' thus means "send me all object IDs
+       which I need to download if I have the commit object 'bar', but
+       not 'foo'".
+
+--bisect::
+       Limit output to the one commit object which is roughly halfway
+       between the included and excluded commits. Thus, if 'git-rev-list
+       --bisect foo ^bar ^baz' outputs 'midpoint', the output
+       of 'git-rev-list foo ^midpoint' and 'git-rev-list midpoint
+       ^bar ^baz' would be of roughly the same length. Finding the change
+       which introduces a regression is thus reduced to a binary search:
+       repeatedly generate and test new 'midpoint's until the commit chain
+       is of length one.
+
+--merge-order::
+       When specified the commit history is decomposed into a unique
+       sequence of minimal, non-linear epochs and maximal, linear epochs.
+       Non-linear epochs are then linearised by sorting them into merge
+       order, which is described below.
++
+Maximal, linear epochs correspond to periods of sequential development.
+Minimal, non-linear epochs correspond to periods of divergent development
+followed by a converging merge. The theory of epochs is described in more
+detail at
+link:http://blackcubes.dyndns.org/epoch/[http://blackcubes.dyndns.org/epoch/].
++
+The merge order for a non-linear epoch is defined as a linearisation for which
+the following invariants are true:
++
+    1. if a commit P is reachable from commit N, commit P sorts after commit N
+       in the linearised list.
+    2. if Pi and Pj are any two parents of a merge M (with i < j), then any
+       commit N, such that N is reachable from Pj but not reachable from Pi,
+       sorts before all commits reachable from Pi.
++
+Invariant 1 states that later commits appear before earlier commits they are
+derived from.
++
+Invariant 2 states that commits unique to "later" parents in a merge, appear
+before all commits from "earlier" parents of a merge.
+
+--show-breaks::
+       Each item of the list is output with a 2-character prefix consisting
+       of one of: (|), (^), (=) followed by a space.
++
+Commits marked with (=) represent the boundaries of minimal, non-linear epochs
+and correspond either to the start of a period of divergent development or to
+the end of such a period.
++
+Commits marked with (|) are direct parents of commits immediately preceding
+the marked commit in the list.
++
+Commits marked with (^) are not parents of the immediately preceding commit.
+These "breaks" represent necessary discontinuities implied by trying to
+represent an arbtirary DAG in a linear form.
++
+*--show-breaks* is only valid if *--merge-order* is also specified.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Original *--merge-order* logic by Jon Seymour <jon.seymour@gmail.com>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
new file mode 100644 (file)
index 0000000..099db29
--- /dev/null
@@ -0,0 +1,140 @@
+git-rev-parse(1)
+================
+
+NAME
+----
+git-rev-parse - Pick out and massage parameters.
+
+
+SYNOPSIS
+--------
+'git-rev-parse' [ --option ] <args>...
+
+DESCRIPTION
+-----------
+
+Many git Porcelainish commands take mixture of flags
+(i.e. parameters that begin with a dash '-') and parameters
+meant for underlying `git-rev-list` command they use internally
+and flags and parameters for other commands they use as the
+downstream of `git-rev-list`.  This command is used to
+distinguish between them.
+
+
+OPTIONS
+-------
+--revs-only::
+       Do not output flags and parameters not meant for
+       `git-rev-list` command.
+
+--no-revs::
+       Do not output flags and parameters meant for
+       `git-rev-list` command.
+
+--flags::
+       Do not output non-flag parameters.
+
+--no-flags::
+       Do not output flag parameters.
+
+--default <arg>::
+       If there is no parameter given by the user, use `<arg>`
+       instead.
+
+--verify::
+       The parameter given must be usable as a single, valid
+       object name.  Otherwise barf and abort.
+
+--sq::
+       Usually the output is made one line per flag and
+       parameter.  This option makes output a single line,
+       properly quoted for consumption by shell.  Useful when
+       you expect your parameter to contain whitespaces and
+       newlines (e.g. when using pickaxe `-S` with
+       `git-diff-\*`).
+
+--not::
+       When showing object names, prefix them with '{caret}' and
+       strip '{caret}' prefix from the object names that already have
+       one.
+
+--symbolic::
+       Usually the object names are output in SHA1 form (with
+       possible '{caret}' prefix); this option makes them output in a
+       form as close to the original input as possible.
+
+
+--all::
+       Show all refs found in `$GIT_DIR/refs`.
+
+--show-prefix::
+       When the command is invoked from a directory show the
+       path of the current directory relative to the top-level
+       directory.
+
+<args>...::
+       Flags and parameters to be parsed.
+
+
+SPECIFYING REVISIONS
+--------------------
+
+A revision parameter typically, but not necessarily, names a
+commit object.  They use what is called an 'extended SHA1'
+syntax.
+
+* The full SHA1 object name (40-byte hexadecimal string), or
+  a substring of such that is unique within the repository.
+  E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both
+  name the same commit object if there are no other object in
+  your repository whose object name starts with dae86e.
+
+* A symbolic ref name.  E.g. 'master' typically means the commit
+  object referenced by $GIT_DIR/refs/heads/master.  If you
+  happen to have both heads/master and tags/master, you can
+  explicitly say 'heads/master' to tell git which one you mean.
+
+* A suffix '{caret}' to a revision parameter means the first parent of
+  that commit object.  '{caret}<n>' means the <n>th parent (i.e.
+  'rev{caret}'
+  is equivalent to 'rev{caret}1').  As a special rule,
+  'rev{caret}0' means the commit itself and is used when 'rev' is the
+  object name of a tag object that refers to a commit object.
+
+* A suffix '~<n>' to a revision parameter means the commit
+  object that is the <n>th generation grand-parent of the named
+  commit object, following only the first parent.  I.e. rev~3 is
+  equivalent to rev{caret}{caret}{caret} which is equivalent to\
+  rev{caret}1{caret}1{caret}1.
+
+* A suffix '{caret}' followed by an object type name enclosed in
+  brace pair (e.g. `v0.99.8{caret}\{commit\}`) means the object
+  could be a tag, and dereference the tag recursively until an
+  object of that type is found or the object cannot be
+  dereferenced anymore (in which case, barf).  `rev{caret}0`
+  introduced earlier is a short-hand for `rev{caret}\{commit\}`.
+
+* A suffix '{caret}' followed by an empty brace pair
+  (e.g. `v0.99.8{caret}\{\}`) means the object could be a tag,
+  and dereference the tag recursively until a non-tag object is
+  found.
+
+'git-rev-parse' also accepts a prefix '{caret}' to revision parameter,
+which is passed to 'git-rev-list'.  Two revision parameters
+concatenated with '..' is a short-hand for writing a range
+between them.  I.e. 'r1..r2' is equivalent to saying '{caret}r1 r2'
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
new file mode 100644 (file)
index 0000000..feebd81
--- /dev/null
@@ -0,0 +1,48 @@
+git-revert(1)
+=============
+
+NAME
+----
+git-revert - Revert an existing commit.
+
+SYNOPSIS
+--------
+'git-revert' [-n] <commit>
+
+DESCRIPTION
+-----------
+Given one existing commit, revert the change the patch introduces, and record a
+new commit that records it.  This requires your working tree to be clean (no
+modifications from the HEAD commit).
+
+OPTIONS
+-------
+<commit>::
+       Commit to revert.
+
+-n::
+       Usually the command automatically creates a commit with
+       a commit log message stating which commit was reverted.
+       This flag applies the change necessary to revert the
+       named commit to your working tree, but does not make the
+       commit.  In addition, when this option is used, your
+       working tree does not have to match the HEAD commit.
+       The revert is done against the beginning state of your
+       working tree.
++
+This is useful when reverting more than one commits'
+effect to your working tree in a row.
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
new file mode 100644 (file)
index 0000000..b9bec55
--- /dev/null
@@ -0,0 +1,80 @@
+git-send-email(1)
+=================
+
+NAME
+----
+git-send-email - Send a collection of patches as emails
+
+
+SYNOPSIS
+--------
+'git-send-email' [options] <file|directory> [... file|directory]
+
+
+
+DESCRIPTION
+-----------
+Takes the patches given on the command line and emails them out.
+
+The header of the email is configurable by command line options.  If not
+specified on the command line, the user will be prompted with a ReadLine
+enabled interface to provide the necessary information.
+
+OPTIONS
+-------
+The options available are:
+
+--to::
+       Specify the primary recipient of the emails generated.
+       Generally, this will be the upstream maintainer of the
+       project involved.
+
+--from::
+       Specify the sender of the emails.  This will default to
+       the value GIT_COMMITTER_IDENT, as returned by "git-var -l".
+       The user will still be prompted to confirm this entry.
+
+--compose::
+       Use \$EDITOR to edit an introductory message for the
+       patch series.
+
+--subject::
+       Specify the initial subject of the email thread.
+       Only necessary if --compose is also set.  If --compose
+       is not set, this will be prompted for.
+
+--in-reply-to::
+       Specify the contents of the first In-Reply-To header.
+       Subsequent emails will refer to the previous email 
+       instead of this if --chain-reply-to is set (the default)
+       Only necessary if --compose is also set.  If --compose
+       is not set, this will be prompted for.
+
+--chain-reply-to, --no-chain-reply-to::
+       If this is set, each email will be sent as a reply to the previous
+       email sent.  If disabled with "--no-chain-reply-to", all emails after
+       the first will be sent as replies to the first email sent.  When using
+       this, it is recommended that the first file given be an overview of the
+       entire patch series.
+       Default is --chain-reply-to
+
+--smtp-server::
+       If set, specifies the outgoing SMTP server to use.  Defaults to
+       localhost.
+
+
+Author
+------
+Written by Ryan Anderson <ryan@michonline.com>
+
+git-send-email is originally based upon
+send_lots_of_email.pl by Greg Kroah-Hartman.
+
+Documentation
+--------------
+Documentation by Ryan Anderson
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
new file mode 100644 (file)
index 0000000..577f06a
--- /dev/null
@@ -0,0 +1,110 @@
+git-send-pack(1)
+================
+
+NAME
+----
+git-send-pack - Push missing objects packed.
+
+
+SYNOPSIS
+--------
+'git-send-pack' [--all] [--force] [--exec=<git-receive-pack>] [<host>:]<directory> [<ref>...]
+
+DESCRIPTION
+-----------
+Invokes 'git-receive-pack' on a possibly remote repository, and
+updates it from the current repository, sending named refs.
+
+
+OPTIONS
+-------
+--exec=<git-receive-pack>::
+       Path to the 'git-receive-pack' program on the remote
+       end.  Sometimes useful when pushing to a remote
+       repository over ssh, and you do not have the program in
+       a directory on the default $PATH.
+
+--all::
+       Instead of explicitly specifying which refs to update,
+       update all refs that locally exist.
+
+--force::
+       Usually, the command refuses to update a remote ref that
+       is not an ancestor of the local ref used to overwrite it.
+       This flag disables the check.  What this means is that
+       the remote repository can lose commits; use it with
+       care.
+
+<host>::
+       A remote host to house the repository.  When this
+       part is specified, 'git-receive-pack' is invoked via
+       ssh.
+
+<directory>::
+       The repository to update.
+
+<ref>...:
+       The remote refs to update.
+
+
+Specifying the Refs
+-------------------
+
+There are three ways to specify which refs to update on the
+remote end.
+
+With '--all' flag, all refs that exist locally are transfered to
+the remote side.  You cannot specify any '<ref>' if you use
+this flag.
+
+Without '--all' and without any '<ref>', the refs that exist
+both on the local side and on the remote side are updated.
+
+When one or more '<ref>' are specified explicitly, it can be either a
+single pattern, or a pair of such pattern separated by a colon
+":" (this means that a ref name cannot have a colon in it).  A
+single pattern '<name>' is just a shorthand for '<name>:<name>'.
+
+Each pattern pair consists of the source side (before the colon)
+and the destination side (after the colon).  The ref to be
+pushed is determined by finding a match that matches the source
+side, and where it is pushed is determined by using the
+destination side.
+
+ - It is an error if <src> does not match exactly one of the
+   local refs.
+
+ - It is an error if <dst> matches more than one remote refs.
+
+ - If <dst> does not match any remote ref, either
+
+   * it has to start with "refs/"; <dst> is used as the
+     destination literally in this case.
+
+   * <src> == <dst> and the ref that matched the <src> must not
+     exist in the set of remote refs; the ref matched <src>
+     locally is used as the name of the destination.
+
+Without '--force', the <src> ref is stored at the remote only if
+<dst> does not exist, or <dst> is a proper subset (i.e. an
+ancestor) of <src>.  This check, known as "fast forward check",
+is performed in order to avoid accidentally overwriting the
+remote ref and lose other peoples' commits from there.
+
+With '--force', the fast forward check is disabled for all refs.
+
+Optionally, a <ref> parameter can be prefixed with a plus '+' sign
+to disable the fast-forward check only on that ref.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt
new file mode 100644 (file)
index 0000000..6ef59ac
--- /dev/null
@@ -0,0 +1,35 @@
+git-sh-setup(1)
+===============
+
+NAME
+----
+git-sh-setup - Common git shell script setup code.
+
+SYNOPSIS
+--------
+'git-sh-setup'
+
+DESCRIPTION
+-----------
+
+Sets up the normal git environment variables and a few helper functions
+(currently just "die()"), and returns ok if it all looks like a git archive.
+So, to make the rest of the git scripts more careful and readable,
+use it as follows:
+
+-------------------------------------------------
+. git-sh-setup || die "Not a git archive"
+-------------------------------------------------
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt
new file mode 100644 (file)
index 0000000..3f4d804
--- /dev/null
@@ -0,0 +1,35 @@
+git-shell(1)
+============
+
+NAME
+----
+git-shell - Restricted login shell for GIT over SSH only
+
+
+SYNOPSIS
+--------
+'git-shell -c <command> <argument>'
+
+DESCRIPTION
+-----------
+This is meant to be used as a login shell for SSH accounts you want
+to restrict to GIT pull/push access only. It permits execution only
+of server-side GIT commands implementing the pull/push functionality.
+The commands can be executed only by the '-c' option; the shell is not
+interactive.
+
+Currently, only the `git-receive-pack` and `git-upload-pack` commands
+are permitted to be called, with a single required argument.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Petr Baudis and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt
new file mode 100644 (file)
index 0000000..65ca77f
--- /dev/null
@@ -0,0 +1,30 @@
+git-shortlog(1)
+===============
+
+NAME
+----
+git-shortlog - Summarize 'git log' output.
+
+
+SYNOPSIS
+--------
+'git-log --pretty=short | git shortlog'
+
+DESCRIPTION
+-----------
+Summarizes 'git log' output in a format suitable for inclusion
+in release announcements.
+
+
+Author
+------
+Written by Jeff Garzik <jgarzik@pobox.com>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
new file mode 100644 (file)
index 0000000..c6c97b2
--- /dev/null
@@ -0,0 +1,113 @@
+git-show-branch(1)
+==================
+
+NAME
+----
+git-show-branch - Show branches and their commits.
+
+SYNOPSIS
+--------
+'git-show-branch [--all] [--heads] [--tags] [--more=<n> | --list | --independent | --merge-base] [--no-name | --sha1-name] <reference>...'
+
+DESCRIPTION
+-----------
+Shows the head commits from the named <reference> (or all refs under
+$GIT_DIR/refs/heads), and displays concise list of commit logs
+to show their relationship semi-visually.
+
+OPTIONS
+-------
+<reference>::
+       Name of the reference under $GIT_DIR/refs/.
+
+--all --heads --tags::
+       Show all refs under $GIT_DIR/refs, $GIT_DIR/refs/heads,
+       and $GIT_DIR/refs/tags, respectively.
+
+--more=<n>::
+       Usually the command stops output upon showing the commit
+       that is the common ancestor of all the branches.  This
+       flag tells the command to go <n> more common commits
+       beyond that.  When <n> is negative, display only the
+       <reference>s given, without showing the commit ancestry
+       tree.
+
+--list::
+       Synomym to `--more=-1`
+
+--merge-base::
+       Instead of showing the commit list, just act like the
+       'git-merge-base -a' command, except that it can accept
+       more than two heads.
+
+--independent::
+       Among the <reference>s given, display only the ones that
+       cannot be reached from any other <reference>.
+
+--no-name::
+       Do not show naming strings for each commit.
+
+--sha1-name::
+       Instead of naming the commits using the path to reach
+       them from heads (e.g. "master~2" to mean the grandparent
+       of "master"), name them with the unique prefix of their
+       object names.
+
+Note that --more, --list, --independent and --merge-base options
+are mutually exclusive.
+
+
+OUTPUT
+------
+Given N <references>, the first N lines are the one-line
+description from their commit message.  The branch head that is
+pointed at by $GIT_DIR/HEAD is prefixed with an asterisk '*'
+character while other heads are prefixed with a '!' character.
+
+Following these N lines, one-line log for each commit is
+displayed, indented N places.  If a commit is on the I-th
+branch, the I-th indentation character shows a '+' sign;
+otherwise it shows a space.  Each commit shows a short name that
+can be used as an exended SHA1 to name that commit.
+
+The following example shows three branches, "master", "fixes"
+and "mhf":
+
+------------------------------------------------
+$ git show-branch master fixes mhf
+! [master] Add 'git show-branch'.
+ ! [fixes] Introduce "reset type" flag to "git reset"
+  ! [mhf] Allow "+remote:local" refspec to cause --force when fetching.
+---
+  + [mhf] Allow "+remote:local" refspec to cause --force when fetching.
+  + [mhf~1] Use git-octopus when pulling more than one heads.
+ +  [fixes] Introduce "reset type" flag to "git reset"
+  + [mhf~2] "git fetch --force".
+  + [mhf~3] Use .git/remote/origin, not .git/branches/origin.
+  + [mhf~4] Make "git pull" and "git fetch" default to origin
+  + [mhf~5] Infamous 'octopus merge'
+  + [mhf~6] Retire git-parse-remote.
+  + [mhf~7] Multi-head fetch.
+  + [mhf~8] Start adding the $GIT_DIR/remotes/ support.
++++ [master] Add 'git show-branch'.
+------------------------------------------------
+
+These three branches all forked from a common commit, [master],
+whose commit message is "Add 'git show-branch'.  "fixes" branch
+adds one commit 'Introduce "reset type"'.  "mhf" branch has many
+other commits.
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-show-index.txt b/Documentation/git-show-index.txt
new file mode 100644 (file)
index 0000000..be09b62
--- /dev/null
@@ -0,0 +1,35 @@
+git-show-index(1)
+=================
+
+NAME
+----
+git-show-index - Show packed archive index
+
+
+SYNOPSIS
+--------
+'git-show-index' < idx-file
+
+
+DESCRIPTION
+-----------
+Reads given idx file for packed git archive created with
+git-pack-objects command, and dumps its contents.
+
+The information it outputs is subset of what you can get from
+'git-verify-pack -v'; this command only shows the packfile
+offset and SHA1 of each object.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-ssh-fetch.txt b/Documentation/git-ssh-fetch.txt
new file mode 100644 (file)
index 0000000..b7116b3
--- /dev/null
@@ -0,0 +1,51 @@
+git-ssh-fetch(1)
+================
+
+NAME
+----
+git-ssh-fetch - Pulls from a remote repository over ssh connection
+
+
+
+SYNOPSIS
+--------
+'git-ssh-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] commit-id url
+
+DESCRIPTION
+-----------
+Pulls from a remote repository over ssh connection, invoking
+git-ssh-upload on the other end. It functions identically to
+git-ssh-upload, aside from which end you run it on.
+
+
+OPTIONS
+-------
+commit-id::
+        Either the hash or the filename under [URL]/refs/ to
+        pull.
+
+-c::
+       Get the commit objects.
+-t::
+       Get trees associated with the commit objects.
+-a::
+       Get all the objects.
+-v::
+       Report what is downloaded.
+-w::
+        Writes the commit-id into the filename under $GIT_DIR/refs/ on
+        the local end after the transfer is complete.
+
+
+Author
+------
+Written by Daniel Barkalow <barkalow@iabervon.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-ssh-upload.txt b/Documentation/git-ssh-upload.txt
new file mode 100644 (file)
index 0000000..702674e
--- /dev/null
@@ -0,0 +1,47 @@
+git-ssh-upload(1)
+=================
+
+NAME
+----
+git-ssh-upload - Pushes to a remote repository over ssh connection
+
+
+SYNOPSIS
+--------
+'git-ssh-upload' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] commit-id url
+
+DESCRIPTION
+-----------
+Pushes from a remote repository over ssh connection, invoking
+git-ssh-fetch on the other end. It functions identically to
+git-ssh-fetch, aside from which end you run it on.
+
+OPTIONS
+-------
+commit-id::
+        Id of commit to push.
+
+-c::
+        Get the commit objects.
+-t::
+        Get tree associated with the requested commit object.
+-a::
+        Get all the objects.
+-v::
+        Report what is uploaded.
+-w::
+        Writes the commit-id into the filename under [URL]/refs/ on
+        the remote end after the transfer is complete.
+
+Author
+------
+Written by Daniel Barkalow <barkalow@iabervon.org>
+
+Documentation
+--------------
+Documentation by Daniel Barkalow
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
new file mode 100644 (file)
index 0000000..753fc08
--- /dev/null
@@ -0,0 +1,45 @@
+git-status(1)
+=============
+
+NAME
+----
+git-status - Show working tree status.
+
+
+SYNOPSIS
+--------
+'git-status'
+
+DESCRIPTION
+-----------
+Examines paths in the working tree that has changes unrecorded
+to the index file, and changes between the index file and the
+current HEAD commit.  The former paths are what you _could_
+commit by running 'git-update-index' before running 'git
+commit', and the latter paths are what you _would_ commit by
+running 'git commit'.
+
+If there is no path that is different between the index file and
+the current HEAD commit, the command exits with non-zero
+status.
+
+
+OUTPUT
+------
+The output from this command is designed to be used as a commit
+template comments, and all the output lines are prefixed with '#'.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>.
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-stripspace.txt b/Documentation/git-stripspace.txt
new file mode 100644 (file)
index 0000000..528a1b6
--- /dev/null
@@ -0,0 +1,33 @@
+git-stripspace(1)
+=================
+
+NAME
+----
+git-stripspace - Filter out empty lines.
+
+
+SYNOPSIS
+--------
+'git-stripspace' < <stream>
+
+DESCRIPTION
+-----------
+Remove multiple empty lines, and empty lines at beginning and end.
+
+OPTIONS
+-------
+<stream>::
+       Byte stream to act on.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
new file mode 100644 (file)
index 0000000..88bdc08
--- /dev/null
@@ -0,0 +1,137 @@
+git-svnimport(1)
+================
+v0.1, July 2005
+
+NAME
+----
+git-svnimport - Import a SVN repository into git
+
+
+SYNOPSIS
+--------
+'git-svnimport' [ -o <branch-for-HEAD> ] [ -h ] [ -v ] [ -d | -D ]
+                       [ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_nr_changes]
+                       [ -b branch_subdir ] [ -t trunk_subdir ] [ -T tag_subdir ]
+                       [ -s start_chg ] [ -m ] [ -M regex ]
+                       <SVN_repository_URL> [ <path> ]
+
+
+DESCRIPTION
+-----------
+Imports a SVN repository into git. It will either create a new
+repository, or incrementally import into an existing one.
+
+SVN access is done by the SVN:: Perl module.
+
+git-svnimport assumes that SVN repositories are organized into one
+"trunk" directory where the main development happens, "branch/FOO"
+directories for branches, and "/tags/FOO" directories for tags.
+Other subdirectories are ignored.
+
+git-svnimport creates a file ".git/svn2git", which is required for
+incremental SVN imports.
+
+OPTIONS
+-------
+-C <target-dir>::
+        The GIT repository to import to.  If the directory doesn't
+        exist, it will be created.  Default is the current directory.
+
+-s <start_rev>::
+        Start importing at this SVN change number. The  default is 1.
++
+When importing incementally, you might need to edit the .git/svn2git file.
+
+-i::
+       Import-only: don't perform a checkout after importing.  This option
+       ensures the working directory and cache remain untouched and will
+       not create them if they do not exist.
+
+-t <trunk_subdir>::
+       Name the SVN trunk. Default "trunk".
+
+-T <tag_subdir>::
+       Name the SVN subdirectory for tags. Default "tags".
+
+-b <branch_subdir>::
+       Name the SVN subdirectory for branches. Default "branches".
+
+-o <branch-for-HEAD>::
+       The 'trunk' branch from SVN is imported to the 'origin' branch within
+       the git repository. Use this option if you want to import into a
+       different branch.
+
+-m::
+       Attempt to detect merges based on the commit message. This option
+       will enable default regexes that try to capture the name source
+       branch name from the commit message.
+
+-M <regex>::
+       Attempt to detect merges based on the commit message with a custom
+       regex. It can be used with -m to also see the default regexes.
+       You must escape forward slashes.
+
+-l <max_num_changes>::
+       Limit the number of SVN changesets we pull before quitting.
+       This option is necessary because the SVN library has serious memory
+       leaks; the recommended value for nontrivial imports is 100.
+
+       git-svnimport will still exit with a zero exit code. You can check
+       the size of the file ".git/svn2git" to determine whether to call
+       the importer again.
+
+-v::
+       Verbosity: let 'svnimport' report what it is doing.
+
+-d::
+       Use direct HTTP requests if possible. The "<path>" argument is used
+       only for retrieving the SVN logs; the path to the contents is
+       included in the SVN log.
+
+-D::
+       Use direct HTTP requests if possible. The "<path>" argument is used
+       for retrieving the logs, as well as for the contents.
++
+There's no safe way to automatically find out which of these options to
+use, so you need to try both. Usually, the one that's wrong will die
+with a 40x error pretty quickly.
+
+<SVN_repository_URL>::
+       The URL of the SVN module you want to import. For local
+       repositories, use "file:///absolute/path".
++
+If you're using the "-d" or "-D" option, this is the URL of the SVN
+repository itself; it usually ends in "/svn".
+
+<SVN_repository_URL>::
+       The URL of the SVN module you want to import. For local
+       repositories, use "file:///absolute/path".
+
+<path>
+       The path to the module you want to check out.
+
+-h::
+       Print a short usage message and exit.
+
+OUTPUT
+------
+If '-v' is specified, the script reports what it is doing.
+
+Otherwise, success is indicated the Unix way, i.e. by simply exiting with
+a zero exit status.
+
+Author
+------
+Written by Matthias Urlichs <smurf@smurf.noris.de>, with help from
+various participants of the git-list <git@vger.kernel.org>.
+
+Based on a cvs2git script by the same author.
+
+Documentation
+--------------
+Documentation by Matthias Urlichs <smurf@smurf.noris.de>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-symbolic-ref.txt b/Documentation/git-symbolic-ref.txt
new file mode 100644 (file)
index 0000000..a851ae2
--- /dev/null
@@ -0,0 +1,52 @@
+git-symbolic-ref(1)
+===================
+
+NAME
+----
+git-symbolic-ref - read and modify symbolic refs
+
+SYNOPSIS
+--------
+'git-symbolic-ref' <name> [<ref>]
+
+DESCRIPTION
+-----------
+Given one argument, reads which branch head the given symbolic
+ref refers to and outputs its path, relative to the `.git/`
+directory.  Typically you would give `HEAD` as the <name>
+argument to see on which branch your working tree is on.
+
+Give two arguments, create or update a symbolic ref <name> to
+point at the given branch <ref>.
+
+Traditionally, `.git/HEAD` is a symlink pointing at
+`refs/heads/master`.  When we want to switch to another branch,
+we did `ln -sf refs/heads/newbranch .git/HEAD`, and when we want
+to find out which branch we are on, we did `readlink .git/HEAD`.
+This was fine, and internally that is what still happens by
+default, but on platforms that does not have working symlinks,
+or that does not have the `readlink(1)` command, this was a bit
+cumbersome.  On some platforms, `ln -sf` does not even work as
+advertised (horrors).
+
+A symbolic ref can be a regular file that stores a string that
+begins with `ref: refs/`.  For example, your `.git/HEAD` *can*
+be a regular file whose contents is `ref: refs/heads/master`.
+This can be used on a filesystem that does not support symbolic
+links.  Instead of doing `readlink .git/HEAD`, `git-symbolic-ref
+HEAD` can be used to find out which branch we are on.  To point
+the HEAD to `newbranch`, instead of `ln -sf refs/heads/newbranch
+.git/HEAD`, `git-symbolic-ref HEAD refs/heads/newbranch` can be
+used.
+
+Currently, .git/HEAD uses a regular file symbolic ref on Cygwin,
+and everywhere else it is implemented as a symlink.  This can be
+changed at compilation time.
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
new file mode 100644 (file)
index 0000000..3984812
--- /dev/null
@@ -0,0 +1,45 @@
+git-tag(1)
+==========
+
+NAME
+----
+git-tag -  Create a tag object signed with GPG
+
+
+SYNOPSIS
+--------
+'git-tag' [-a | -s | -u <key-id>] [-f] [-m <msg>] <name> [<head>]
+
+DESCRIPTION
+-----------
+Adds a 'tag' reference in .git/refs/tags/
+
+Unless `-f` is given, the tag must not yet exist in
+`.git/refs/tags/` directory.
+
+If one of `-a`, `-s`, or `-u <key-id>` is passed, the command
+creates a 'tag' object, and requires the tag message.  Unless
+`-m <msg>` is given, an editor is started for the user to type
+in the tag message.
+
+Otherwise just the SHA1 object name of the commit object is
+written (i.e. an lightweight tag).
+
+A GnuPG signed tag object will be created when `-s` or `-u
+<key-id>` is used.  When `-u <key-id>` is not used, the
+committer identity for the current user is used to find the
+GnuPG key for signing.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>,
+Junio C Hamano <junkio@cox.net> and Chris Wright <chrisw@osdl.org>.
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt
new file mode 100644 (file)
index 0000000..2139b6f
--- /dev/null
@@ -0,0 +1,38 @@
+git-tar-tree(1)
+===============
+
+NAME
+----
+git-tar-tree - Creates a tar archive of the files in the named tree
+
+
+SYNOPSIS
+--------
+'git-tar-tree' <tree-ish> [ <base> ]
+
+DESCRIPTION
+-----------
+Creates a tar archive containing the tree structure for the named tree.
+When <base> is specified it is added as a leading path to the files in the
+generated tar archive.
+
+git-tar-tree behaves differently when given a tree ID versus when given
+a commit ID or tag ID.  In the first case the current time is used as
+modification time of each file in the archive.  In the latter case the
+commit time as recorded in the referenced commit object is used instead.
+Additionally the commit ID is stored in a global extended pax header.
+It can be extracted using git-get-tar-commit-id.
+
+
+Author
+------
+Written by Rene Scharfe.
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-unpack-file.txt b/Documentation/git-unpack-file.txt
new file mode 100644 (file)
index 0000000..213dc81
--- /dev/null
@@ -0,0 +1,36 @@
+git-unpack-file(1)
+==================
+
+NAME
+----
+git-unpack-file - Creates a temporary file with a blob's contents
+
+
+
+SYNOPSIS
+--------
+'git-unpack-file' <blob>
+
+DESCRIPTION
+-----------
+Creates a file holding the contents of the blob specified by sha1. It
+returns the name of the temporary file in the following format:
+       .merge_file_XXXXX
+
+OPTIONS
+-------
+<blob>::
+       Must be a blob id
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt
new file mode 100644 (file)
index 0000000..b716ba1
--- /dev/null
@@ -0,0 +1,38 @@
+git-unpack-objects(1)
+=====================
+
+NAME
+----
+git-unpack-objects - Unpack objects from a packed archive.
+
+
+SYNOPSIS
+--------
+'git-unpack-objects' [-q] <pack-file
+
+
+DESCRIPTION
+-----------
+Reads a packed archive (.pack) from the standard input, and
+expands the objects contained in the pack into "one-file
+one-object" format in $GIT_OBJECT_DIRECTORY.
+
+OPTIONS
+-------
+-q::
+       The command usually shows percentage progress.  This
+       flag suppresses it.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+-------------
+Documentation by Junio C Hamano
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
new file mode 100644 (file)
index 0000000..6fa1d98
--- /dev/null
@@ -0,0 +1,135 @@
+git-update-index(1)
+===================
+
+NAME
+----
+git-update-index - Modifies the index or directory cache
+
+
+SYNOPSIS
+--------
+'git-update-index'
+            [--add] [--remove] [--refresh] [--replace]
+            [--ignore-missing]
+            [--force-remove]
+            [--cacheinfo <mode> <object> <file>]\*
+            [--info-only]
+            [-z] [--stdin]
+            [--] [<file>]\*
+
+DESCRIPTION
+-----------
+Modifies the index or directory cache. Each file mentioned is updated
+into the cache and any 'unmerged' or 'needs updating' state is
+cleared.
+
+The way "git-update-index" handles files it is told about can be modified
+using the various options:
+
+OPTIONS
+-------
+--add::
+       If a specified file isn't in the cache already then it's
+       added.
+       Default behaviour is to ignore new files.
+
+--remove::
+       If a specified file is in the cache but is missing then it's
+       removed.
+       Default behaviour is to ignore removed file.
+
+--refresh::
+       Looks at the current cache and checks to see if merges or
+       updates are needed by checking stat() information.
+
+--ignore-missing::
+       Ignores missing files during a --refresh
+
+--cacheinfo <mode> <object> <path>::
+       Directly insert the specified info into the cache.
+       
+--info-only::
+       Do not create objects in the object database for all
+       <file> arguments that follow this flag; just insert
+       their object IDs into the cache.
+
+--force-remove::
+       Remove the file from the index even when the working directory
+       still has such a file. (Implies --remove.)
+
+--replace::
+       By default, when a file `path` exists in the index,
+       git-update-index refuses an attempt to add `path/file`.
+       Similarly if a file `path/file` exists, a file `path`
+       cannot be added.  With --replace flag, existing entries
+       that conflicts with the entry being added are
+       automatically removed with warning messages.
+
+--stdin::
+       Instead of taking list of paths from the command line,
+       read list of paths from the standard input.  Paths are
+       separated by LF (i.e. one path per line) by default.
+
+-z::
+       Only meaningful with `--stdin`; paths are separated with
+       NUL character instead of LF.
+
+--::
+       Do not interpret any more arguments as options.
+
+<file>::
+       Files to act on.
+       Note that files begining with '.' are discarded. This includes
+       `./file` and `dir/./file`. If you don't want this, then use     
+       cleaner names.
+       The same applies to directories ending '/' and paths with '//'
+
+Using --refresh
+---------------
+'--refresh' does not calculate a new sha1 file or bring the cache
+up-to-date for mode/content changes. But what it *does* do is to
+"re-match" the stat information of a file with the cache, so that you
+can refresh the cache for a file that hasn't been changed but where
+the stat entry is out of date.
+
+For example, you'd want to do this after doing a "git-read-tree", to link
+up the stat cache details with the proper files.
+
+Using --cacheinfo or --info-only
+--------------------------------
+'--cacheinfo' is used to register a file that is not in the
+current working directory.  This is useful for minimum-checkout
+merging.
+
+To pretend you have a file with mode and sha1 at path, say:
+
+   $ git-update-index --cacheinfo mode sha1 path
+
+'--info-only' is used to register files without placing them in the object
+database.  This is useful for status-only repositories.
+
+Both '--cacheinfo' and '--info-only' behave similarly: the index is updated
+but the object database isn't.  '--cacheinfo' is useful when the object is
+in the database but the file isn't available locally.  '--info-only' is
+useful when the file is available, but you do not wish to update the
+object database.
+
+Examples
+--------
+To update and refresh only the files already checked out:
+
+   git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
new file mode 100644 (file)
index 0000000..69715aa
--- /dev/null
@@ -0,0 +1,58 @@
+git-update-ref(1)
+=================
+
+NAME
+----
+git-update-ref - update the object name stored in a ref safely
+
+SYNOPSIS
+--------
+`git-update-ref` <ref> <newvalue> [<oldvalue>]
+
+DESCRIPTION
+-----------
+Given two arguments, stores the <newvalue> in the <ref>, possibly
+dereferencing the symbolic refs.  E.g. `git-update-ref HEAD
+<newvalue>` updates the current branch head to the new object.
+
+Given three arguments, stores the <newvalue> in the <ref>,
+possibly dereferencing the symbolic refs, after verifying that
+the current value of the <ref> matches <oldvalue>.
+E.g. `git-update-ref refs/heads/master <newvalue> <oldvalue>`
+updates the master branch head to <newvalue> only if its current
+value is <oldvalue>.
+
+It also allows a "ref" file to be a symbolic pointer to another
+ref file by starting with the four-byte header sequence of
+"ref:".
+
+More importantly, it allows the update of a ref file to follow
+these symbolic pointers, whether they are symlinks or these
+"regular file symbolic refs".  It follows *real* symlinks only
+if they start with "refs/": otherwise it will just try to read
+them and update them as a regular file (i.e. it will allow the
+filesystem to follow them, but will overwrite such a symlink to
+somewhere else with a regular filename).
+
+In general, using
+
+       git-update-ref HEAD "$head"
+
+should be a _lot_ safer than doing
+
+       echo "$head" > "$GIT_DIR/HEAD"
+
+both from a symlink following standpoint *and* an error checking
+standpoint.  The "refs/" rule for symlinks means that symlinks
+that point to "outside" the tree are safe: they'll be followed
+for reading but not for writing (so we'll never write through a
+ref symlink to some other tree, if you have copied a whole
+archive by creating a symlink tree).
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-update-server-info.txt b/Documentation/git-update-server-info.txt
new file mode 100644 (file)
index 0000000..3d0dea0
--- /dev/null
@@ -0,0 +1,58 @@
+git-update-server-info(1)
+=========================
+
+NAME
+----
+git-update-server-info - Update auxiliary info file to help dumb servers
+
+
+SYNOPSIS
+--------
+'git-update-server-info' [--force]
+
+DESCRIPTION
+-----------
+A dumb server that does not do on-the-fly pack generations can
+have some auxiliary information files in $GIT_DIR/info and
+$GIT_OBJECT_DIRECTORY/info directories to help clients discover
+what references and packs the server has and make optimized
+pull decisions.  This command generates such auxiliary files.
+
+
+OPTIONS
+-------
+
+--force::
+       Update the info files from scratch.
+
+
+OUTPUT
+------
+
+Currently the command updates the following files.  Please see
+link:repository-layout.html[repository-layout] for description
+of what they are for:
+
+* objects/info/packs
+
+* info/refs
+
+
+BUGS
+----
+When you remove an existing ref, the command fails to update
+info/refs file unless `--force` flag is given.
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt
new file mode 100644 (file)
index 0000000..3d8f8ef
--- /dev/null
@@ -0,0 +1,39 @@
+git-upload-pack(1)
+==================
+
+NAME
+----
+git-upload-pack - Send missing objects packed.
+
+
+SYNOPSIS
+--------
+'git-upload-pack' <directory>
+
+DESCRIPTION
+-----------
+Invoked by 'git-clone-pack' and/or 'git-fetch-pack', learns what
+objects the other side is missing, and sends them after packing.
+
+This command is usually not invoked directly by the end user.
+The UI for the protocol is on the 'git-fetch-pack' side, and the
+program pair is meant to be used to pull updates from a remote
+repository.  For push operations, see 'git-send-pack'.
+
+
+OPTIONS
+-------
+<directory>::
+       The repository to sync from.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt
new file mode 100644 (file)
index 0000000..c22d34f
--- /dev/null
@@ -0,0 +1,61 @@
+git-var(1)
+==========
+
+NAME
+----
+git-var - Print the git users identity
+
+
+SYNOPSIS
+--------
+git-var [ -l | <variable> ]
+
+DESCRIPTION
+-----------
+Prints a git logical variable.
+
+OPTIONS
+-------
+-l::
+       Cause the logical variables to be listed.
+
+EXAMPLE
+--------
+       $ git-var GIT_AUTHOR_IDENT
+       Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600
+
+
+VARIABLES
+----------
+GIT_AUTHOR_IDENT::
+    The author of a piece of code.
+
+GIT_COMMITTER_IDENT::
+    The person who put a piece of code into git.
+
+Diagnostics
+-----------
+You don't exist. Go away!::
+    The passwd(5) gecos field couldn't be read
+Your parents must have hated you!::
+    The password(5) gecos field is longer than a giant static buffer.
+Your sysadmin must hate you!::
+    The password(5) name field is longer than a giant static buffer.
+
+See Also
+--------
+gitlink:git-commit-tree[1]
+gitlink:git-tag[1]
+
+Author
+------
+Written by Eric Biederman <ebiederm@xmission.com>
+
+Documentation
+--------------
+Documentation by Eric Biederman and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt
new file mode 100644 (file)
index 0000000..cd74ffd
--- /dev/null
@@ -0,0 +1,52 @@
+git-verify-pack(1)
+==================
+
+NAME
+----
+git-verify-pack - Validate packed git archive files.
+
+
+SYNOPSIS
+--------
+'git-verify-pack' [-v] <pack>.idx ...
+
+
+DESCRIPTION
+-----------
+Reads given idx file for packed git archive created with
+git-pack-objects command and verifies idx file and the
+corresponding pack file.
+
+OPTIONS
+-------
+<pack>.idx ...::
+       The idx files to verify.
+
+-v::
+       After verifying the pack, show list of objects contained
+       in the pack.
+
+OUTPUT FORMAT
+-------------
+When specifying the -v option the format used is:
+
+       SHA1 type size offset-in-packfile
+
+for objects that are not deltified in the pack, and
+
+       SHA1 type size offset-in-packfile depth base-SHA1
+
+for objects that are deltified.
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by Junio C Hamano
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-verify-tag.txt b/Documentation/git-verify-tag.txt
new file mode 100644 (file)
index 0000000..b8a73c4
--- /dev/null
@@ -0,0 +1,32 @@
+git-verify-tag(1)
+=================
+
+NAME
+----
+git-verify-tag - Check the GPG signature of tag.
+
+SYNOPSIS
+--------
+'git-verify-tag' <tag>
+
+DESCRIPTION
+-----------
+Validates the gpg signature created by git-tag.
+
+OPTIONS
+-------
+<tag>::
+       SHA1 identifier of a git tag object.
+
+Author
+------
+Written by Jan Harkes <jaharkes@cs.cmu.edu> and Eric W. Biederman <ebiederm@xmission.com>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt
new file mode 100644 (file)
index 0000000..e6f57d9
--- /dev/null
@@ -0,0 +1,67 @@
+git-whatchanged(1)
+==================
+
+NAME
+----
+git-whatchanged - Show logs with difference each commit introduces.
+
+
+SYNOPSIS
+--------
+'git-whatchanged' <option>...
+
+DESCRIPTION
+-----------
+Shows commit logs and diff output each commit introduces.  The
+command internally invokes 'git-rev-list' piped to
+'git-diff-tree', and takes command line options for both of
+these commands.
+
+This manual page describes only the most frequently used options.
+
+
+OPTIONS
+-------
+-p::
+       Show textual diffs, instead of the git internal diff
+       output format that is useful only to tell the changed
+       paths and their nature of changes.
+
+--max-count=<n>::
+       Limit output to <n> commits.
+
+<since>..<until>::
+       Limit output to between the two named commits (bottom
+       exclusive, top inclusive).
+
+-r::
+       Show git internal diff output, but for the whole tree,
+       not just the top level.
+
+--pretty=<format>::
+       Controls the output format for the commit logs.
+       <format> can be one of 'raw', 'medium', 'short', 'full',
+       and 'oneline'.
+
+-m::
+       By default, differences for merge commits are not shown.
+       With this flag, show differences to that commit from all
+       of its parents.
+
+       However, it is not very useful in general, although it
+       *is* useful on a file-by-file basis.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>
+
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git-write-tree.txt b/Documentation/git-write-tree.txt
new file mode 100644 (file)
index 0000000..51be44d
--- /dev/null
@@ -0,0 +1,42 @@
+git-write-tree(1)
+=================
+
+NAME
+----
+git-write-tree - Creates a tree object from the current cache
+
+
+SYNOPSIS
+--------
+'git-write-tree' [--missing-ok]
+
+DESCRIPTION
+-----------
+Creates a tree object using the current cache.
+
+The cache must be merged.
+
+Conceptually, "git-write-tree" sync()s the current directory cache contents
+into a set of tree files.
+In order to have that match what is actually in your directory right
+now, you need to have done a "git-update-index" phase before you did the
+"git-write-tree".
+
+OPTIONS
+-------
+--missing-ok::
+       Normally "git-write-tree" ensures that the objects referenced by the
+       directory exist in the object database.  This option disables this check.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git.txt b/Documentation/git.txt
new file mode 100644 (file)
index 0000000..054f091
--- /dev/null
@@ -0,0 +1,554 @@
+git(7)
+======
+
+NAME
+----
+git - the stupid content tracker
+
+
+SYNOPSIS
+--------
+'git-<command>' <args>
+
+DESCRIPTION
+-----------
+
+This is reference information for the core git commands.
+
+Before reading this cover to cover, you may want to take a look
+at the link:tutorial.html[tutorial] document.
+
+The <<Discussion>> section below contains much useful definition and
+clarification info - read that first.  And of the commands, I suggest
+reading gitlink:git-update-index[1] and
+gitlink:git-read-tree[1] first - I wish I had!
+
+If you are migrating from CVS, link:cvs-migration.html[cvs migration]
+document may be helpful after you finish the tutorial.
+
+After you get the general feel from the tutorial and this
+overview page, you may want to take a look at the
+link:howto-index.html[howto] documents.
+
+
+David Greaves <david@dgreaves.com>
+08/05/05
+
+Updated by Junio C Hamano <junkio@cox.net> on 2005-05-05 to
+reflect recent changes.
+
+Commands Overview
+-----------------
+The git commands can helpfully be split into those that manipulate
+the repository, the cache and the working fileset, those that
+interrogate and compare them, and those that moves objects and
+references between repositories.
+
+In addition, git itself comes with a spartan set of porcelain
+commands.  They are usable but are not meant to compete with real
+Porcelains.
+
+There are also some ancillary programs that can be viewed as useful
+aids for using the core commands but which are unlikely to be used by
+SCMs layered over git.
+
+Manipulation commands
+~~~~~~~~~~~~~~~~~~~~~
+gitlink:git-apply[1]::
+       Reads a "diff -up1" or git generated patch file and
+       applies it to the working tree.
+
+gitlink:git-checkout-index[1]::
+       Copy files from the cache to the working directory
+       Previously this command was known as git-checkout-cache.
+
+gitlink:git-commit-tree[1]::
+       Creates a new commit object
+
+gitlink:git-hash-object[1]::
+       Computes the object ID from a file.
+
+gitlink:git-index-pack.html[1]::
+       Build pack index file for an existing packed archive.
+
+gitlink:git-init-db[1]::
+       Creates an empty git object database
+
+gitlink:git-merge-index[1]::
+       Runs a merge for files needing merging
+       Previously this command was known as git-merge-cache.
+
+gitlink:git-mktag[1]::
+       Creates a tag object
+
+gitlink:git-pack-objects[1]::
+       Creates a packed archive of objects.
+
+gitlink:git-prune-packed[1]::
+       Remove extra objects that are already in pack files.
+
+gitlink:git-read-tree[1]::
+       Reads tree information into the directory cache
+
+gitlink:git-unpack-objects[1]::
+       Unpacks objects out of a packed archive.
+
+gitlink:git-update-index[1]::
+       Modifies the index or directory cache
+       Previously this command was known as git-update-cache.
+
+gitlink:git-write-tree[1]::
+       Creates a tree from the current cache
+
+
+Interrogation commands
+~~~~~~~~~~~~~~~~~~~~~~
+
+gitlink:git-cat-file[1]::
+       Provide content or type information for repository objects
+
+gitlink:git-diff-index[1]::
+       Compares content and mode of blobs between the cache and repository
+       Previously this command was known as git-diff-cache.
+
+gitlink:git-diff-files[1]::
+       Compares files in the working tree and the cache
+
+gitlink:git-diff-stages[1]::
+       Compares two "merge stages" in the index file.
+
+gitlink:git-diff-tree[1]::
+       Compares the content and mode of blobs found via two tree objects
+
+gitlink:git-fsck-objects[1]::
+       Verifies the connectivity and validity of the objects in the database
+       Previously this command was known as git-fsck-cache.
+
+gitlink:git-ls-files[1]::
+       Information about files in the cache/working directory
+
+gitlink:git-ls-tree[1]::
+       Displays a tree object in human readable form
+
+gitlink:git-merge-base[1]::
+       Finds as good a common ancestor as possible for a merge
+
+gitlink:git-rev-list[1]::
+       Lists commit objects in reverse chronological order
+
+gitlink:git-show-index[1]::
+       Displays contents of a pack idx file.
+
+gitlink:git-tar-tree[1]::
+       Creates a tar archive of the files in the named tree
+
+gitlink:git-unpack-file[1]::
+       Creates a temporary file with a blob's contents
+
+gitlink:git-var[1]::
+       Displays a git logical variable
+
+gitlink:git-verify-pack[1]::
+       Validates packed git archive files
+
+The interrogate commands may create files - and you can force them to
+touch the working file set - but in general they don't
+
+
+Synching repositories
+~~~~~~~~~~~~~~~~~~~~~
+
+gitlink:git-clone-pack[1]::
+       Clones a repository into the current repository (engine
+       for ssh and local transport)
+
+gitlink:git-fetch-pack[1]::
+       Updates from a remote repository.
+
+gitlink:git-http-fetch[1]::
+       Downloads a remote git repository via HTTP
+       Previously this command was known as git-http-pull.
+
+gitlink:git-local-fetch[1]::
+       Duplicates another git repository on a local system
+       Previously this command was known as git-local-pull.
+
+gitlink:git-peek-remote[1]::
+       Lists references on a remote repository using upload-pack protocol.
+
+gitlink:git-receive-pack[1]::
+       Invoked by 'git-send-pack' to receive what is pushed to it.
+
+gitlink:git-send-pack[1]::
+       Pushes to a remote repository, intelligently.
+
+gitlink:git-shell[1]::
+       Restricted shell for GIT-only SSH access.
+
+gitlink:git-ssh-fetch[1]::
+       Pulls from a remote repository over ssh connection
+       Previously this command was known as git-ssh-pull.
+
+gitlink:git-ssh-upload[1]::
+       Helper "server-side" program used by git-ssh-fetch
+       Previously this command was known as git-ssh-push.
+
+gitlink:git-update-server-info[1]::
+       Updates auxiliary information on a dumb server to help
+       clients discover references and packs on it.
+
+gitlink:git-upload-pack[1]::
+       Invoked by 'git-clone-pack' and 'git-fetch-pack' to push
+       what are asked for.
+
+
+Porcelain-ish Commands
+----------------------
+
+gitlink:git-add[1]::
+       Add paths to the index file.
+       Previously this command was known as git-add-script.
+
+gitlink:git-am[1]::
+       Apply patches from a mailbox, but cooler.
+
+gitlink:git-applymbox[1]::
+       Apply patches from a mailbox.
+
+gitlink:git-bisect[1]::
+       Find the change that introduced a bug.
+       Previously this command was known as git-bisect-script.
+
+gitlink:git-branch[1]::
+       Create and Show branches.
+       Previously this command was known as git-branch-script.
+
+gitlink:git-checkout[1]::
+       Checkout and switch to a branch.
+       Previously this command was known as git-checkout-script.
+
+gitlink:git-cherry-pick[1]::
+       Cherry-pick the effect of an existing commit.
+       Previously this command was known as git-cherry-pick-script.
+
+gitlink:git-clone[1]::
+       Clones a repository into a new directory.
+       Previously this command was known as git-clone-script.
+
+gitlink:git-commit[1]::
+       Record changes to the repository.
+       Previously this command was known as git-commit-script.
+
+gitlink:git-diff[1]::
+       Show changes between commits, commit and working tree, etc.
+       Previously this command was known as git-diff-script.
+
+gitlink:git-fetch[1]::
+       Download from a remote repository via various protocols.
+       Previously this command was known as git-fetch-script.
+
+gitlink:git-format-patch[1]::
+       Prepare patches for e-mail submission.
+       Previously this command was known as git-format-patch-script.
+
+gitlink:git-grep[1]::
+       Print lines matching a pattern
+
+gitlink:git-log[1]::
+       Shows commit logs.
+       Previously this command was known as git-log-script.
+
+gitlink:git-ls-remote[1]::
+       Shows references in a remote or local repository.
+       Previously this command was known as git-ls-remote-script.
+
+gitlink:git-merge[1]::
+       Grand unified merge driver.
+
+gitlink:git-mv[1]::
+       Move or rename a file, a directory, or a symlink.
+
+gitlink:git-octopus[1]::
+       Merge more than two commits.
+       Previously this command was known as git-octopus-script.
+
+gitlink:git-pull[1]::
+       Fetch from and merge with a remote repository.
+       Previously this command was known as git-pull-script.
+
+gitlink:git-push[1]::
+       Update remote refs along with associated objects.
+       Previously this command was known as git-push-script.
+
+gitlink:git-rebase[1]::
+       Rebase local commits to new upstream head.
+       Previously this command was known as git-rebase-script.
+
+gitlink:git-rename[1]::
+       Rename files and directories.
+       Previously this command was known as git-rename-script.
+
+gitlink:git-repack[1]::
+       Pack unpacked objects in a repository.
+       Previously this command was known as git-repack-script.
+
+gitlink:git-reset[1]::
+       Reset current HEAD to the specified state.
+       Previously this command was known as git-reset-script.
+
+gitlink:git-resolve[1]::
+       Merge two commits.
+       Previously this command was known as git-resolve-script.
+
+gitlink:git-revert[1]::
+       Revert an existing commit.
+       Previously this command was known as git-revert-script.
+
+gitlink:git-shortlog[1]::
+       Summarizes 'git log' output.
+
+gitlink:git-show-branch[1]::
+       Show branches and their commits.
+
+gitlink:git-status[1]::
+       Shows the working tree status.
+       Previously this command was known as git-status-script.
+
+gitlink:git-verify-tag[1]::
+       Check the GPG signature of tag.
+       Previously this command was known as git-verify-tag-script.
+
+gitlink:git-whatchanged[1]::
+       Shows commit logs and differences they introduce.
+
+
+Ancillary Commands
+------------------
+Manipulators:
+
+gitlink:git-applypatch[1]::
+       Apply one patch extracted from an e-mail.
+
+gitlink:git-archimport[1]::
+       Import an arch repository into git.
+       Previously this command was known as git-archimport-script.
+
+gitlink:git-convert-objects[1]::
+       Converts old-style git repository
+       Previously this command was known as git-convert-cache.
+
+gitlink:git-cvsimport[1]::
+       Salvage your data out of another SCM people love to hate.
+       Previously this command was known as git-cvsimport-script.
+
+gitlink:git-merge-one-file[1]::
+       The standard helper program to use with "git-merge-index"
+       Previously this command was known as git-merge-one-file-script.
+
+gitlink:git-prune[1]::
+       Prunes all unreachable objects from the object database
+       Previously this command was known as git-prune-script.
+
+gitlink:git-relink[1]::
+       Hardlink common objects in local repositories.
+       Previously this command was known as git-relink-script.
+
+gitlink:git-svnimport[1]::
+       Import a SVN repository into git.
+
+gitlink:git-sh-setup[1]::
+       Common git shell script setup code.
+       Previously this command was known as git-sh-setup-script.
+
+gitlink:git-tag[1]::
+       An example script to create a tag object signed with GPG
+       Previously this command was known as git-tag-script.
+
+gitlink:git-update-ref[1]::
+       Update the object name stored in a ref safely.
+
+
+Interrogators:
+
+gitlink:git-check-ref-format[1]::
+       Make sure ref name is well formed.
+
+gitlink:git-cherry[1]::
+       Find commits not merged upstream.
+
+gitlink:git-count-objects[1]::
+       Count unpacked number of objects and their disk consumption.
+       Previously this command was known as git-count-objects-script.
+
+gitlink:git-daemon[1]::
+       A really simple server for git repositories.
+
+gitlink:git-get-tar-commit-id[1]::
+       Extract commit ID from an archive created using git-tar-tree.
+
+gitlink:git-mailinfo[1]::
+       Extracts patch from a single e-mail message.
+
+gitlink:git-mailsplit[1]::
+       git-mailsplit.
+
+gitlink:git-patch-id[1]::
+       Compute unique ID for a patch.
+
+gitlink:git-parse-remote[1]::
+       Routines to help parsing $GIT_DIR/remotes/
+       Previously this command was known as git-parse-remote-script.
+
+gitlink:git-request-pull[1]::
+       git-request-pull.
+       Previously this command was known as git-request-pull-script.
+
+gitlink:git-rev-parse[1]::
+       Pick out and massage parameters.
+
+gitlink:git-send-email[1]::
+       Send patch e-mails out of "format-patch --mbox" output.
+       Previously this command was known as git-send-email-script.
+
+gitlink:git-symbolic-refs[1]::
+       Read and modify symbolic refs.
+
+gitlink:git-stripspace[1]::
+       Filter out empty lines.
+
+
+Commands not yet documented
+---------------------------
+
+gitlink:gitk[1]::
+       gitk.
+
+
+Identifier Terminology
+----------------------
+<object>::
+       Indicates the sha1 identifier for any type of object
+
+<blob>::
+       Indicates a blob object sha1 identifier
+
+<tree>::
+       Indicates a tree object sha1 identifier
+
+<commit>::
+       Indicates a commit object sha1 identifier
+
+<tree-ish>::
+       Indicates a tree, commit or tag object sha1 identifier.  A
+       command that takes a <tree-ish> argument ultimately wants to
+       operate on a <tree> object but automatically dereferences
+       <commit> and <tag> objects that point at a <tree>.
+
+<type>::
+       Indicates that an object type is required.
+       Currently one of: blob/tree/commit/tag
+
+<file>::
+       Indicates a filename - always relative to the root of
+       the tree structure GIT_INDEX_FILE describes.
+
+Symbolic Identifiers
+--------------------
+Any git command accepting any <object> can also use the following
+symbolic notation:
+
+HEAD::
+       indicates the head of the repository (ie the contents of
+       `$GIT_DIR/HEAD`)
+<tag>::
+       a valid tag 'name'+
+       (ie the contents of `$GIT_DIR/refs/tags/<tag>`)
+<head>::
+       a valid head 'name'+
+       (ie the contents of `$GIT_DIR/refs/heads/<head>`)
+<snap>::
+       a valid snapshot 'name'+
+       (ie the contents of `$GIT_DIR/refs/snap/<snap>`)
+
+
+File/Directory Structure
+------------------------
+
+Please see link:repository-layout.html[repository layout] document.
+
+Higher level SCMs may provide and manage additional information in the
+GIT_DIR.
+
+
+Terminology
+-----------
+Please see link:glossary.html[glossary] document.
+
+
+Environment Variables
+---------------------
+Various git commands use the following environment variables:
+
+The git Repository
+~~~~~~~~~~~~~~~~~~
+These environment variables apply to 'all' core git commands. Nb: it
+is worth noting that they may be used/overridden by SCMS sitting above
+git so take care if using Cogito etc
+
+'GIT_INDEX_FILE'::
+       This environment allows the specification of an alternate
+       cache/index file. If not specified, the default of
+       `$GIT_DIR/index` is used.
+
+'GIT_OBJECT_DIRECTORY'::
+       If the object storage directory is specified via this
+       environment variable then the sha1 directories are created
+       underneath - otherwise the default `$GIT_DIR/objects`
+       directory is used.
+
+'GIT_ALTERNATE_OBJECT_DIRECTORIES'::
+       Due to the immutable nature of git objects, old objects can be
+       archived into shared, read-only directories. This variable
+       specifies a ":" separated list of git object directories which
+       can be used to search for git objects. New objects will not be
+       written to these directories.
+
+'GIT_DIR'::
+       If the 'GIT_DIR' environment variable is set then it specifies
+       a path to use instead of `./.git` for the base of the
+       repository.
+
+git Commits
+~~~~~~~~~~~
+'GIT_AUTHOR_NAME'::
+'GIT_AUTHOR_EMAIL'::
+'GIT_AUTHOR_DATE'::
+'GIT_COMMITTER_NAME'::
+'GIT_COMMITTER_EMAIL'::
+       see gitlink:git-commit-tree[1]
+
+git Diffs
+~~~~~~~~~
+'GIT_DIFF_OPTS'::
+'GIT_EXTERNAL_DIFF'::
+       see the "generating patches" section in :
+       gitlink:git-diff-index[1];
+       gitlink:git-diff-files[1];
+       gitlink:git-diff-tree[1]
+
+Discussion[[Discussion]]
+------------------------
+include::../README[]
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and the git-list <git@vger.kernel.org>.
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
new file mode 100644 (file)
index 0000000..e5ef6d6
--- /dev/null
@@ -0,0 +1,38 @@
+gitk(1)
+=======
+
+NAME
+----
+gitk - Some git command not yet documented.
+
+
+SYNOPSIS
+--------
+'gitk' [ --option ] <args>...
+
+DESCRIPTION
+-----------
+Does something not yet documented.
+
+
+OPTIONS
+-------
+--option::
+       Some option not yet documented.
+
+<args>...::
+       Some argument not yet documented.
+
+
+Author
+------
+Written by Paul Mackerras <paulus@samba.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
new file mode 100644 (file)
index 0000000..eb7b471
--- /dev/null
@@ -0,0 +1,242 @@
+object::
+       The unit of storage in git. It is uniquely identified by
+       the SHA1 of its contents. Consequently, an object can not
+       be changed.
+
+object name::
+       The unique identifier of an object. The hash of the object's contents
+       using the Secure Hash Algorithm 1 and usually represented by the 40
+       character hexadecimal encoding of the hash of the object (possibly
+       followed by a white space).
+
+SHA1::
+       Synonym for object name.
+
+object identifier::
+       Synonym for object name.
+
+hash::
+       In git's context, synonym to object name.
+
+object database::
+       Stores a set of "objects", and an individial object is identified
+       by its object name. The object usually live in $GIT_DIR/objects/.
+
+blob object::
+       Untyped object, e.g. the contents of a file.
+
+tree object::
+       An object containing a list of file names and modes along with refs
+       to the associated blob and/or tree objects. A tree is equivalent
+       to a directory.
+
+tree::
+       Either a working tree, or a tree object together with the
+       dependent blob and tree objects (i.e. a stored representation
+       of a working tree).
+
+DAG::
+       Directed acyclic graph. The commit objects form a directed acyclic
+       graph, because they have parents (directed), and the graph of commit
+       objects is acyclic (there is no chain which begins and ends with the
+       same object).
+
+index::
+       A collection of files with stat information, whose contents are
+       stored as objects. The cache is a stored version of your working
+       tree. Truth be told, it can also contain a second, and even a third
+       version of a working tree, which are used when merging.
+
+index entry::
+       The information regarding a particular file, stored in the index.
+       An index entry can be unmerged, if a merge was started, but not
+       yet finished (i.e. if the cache contains multiple versions of
+       that file).
+
+unmerged index:
+       An index which contains unmerged index entries.
+
+cache::
+       Obsolete for: index.
+
+working tree::
+       The set of files and directories currently being worked on,
+       i.e. you can work in your working tree without using git at all.
+
+directory::
+       The list you get with "ls" :-)
+
+revision::
+       A particular state of files and directories which was stored in
+       the object database. It is referenced by a commit object.
+
+checkout::
+       The action of updating the working tree to a revision which was
+       stored in the object database.
+
+commit::
+       As a verb: The action of storing the current state of the cache in the
+       object database. The result is a revision.
+       As a noun: Short hand for commit object.
+
+commit object::
+       An object which contains the information about a particular
+       revision, such as parents, committer, author, date and the
+       tree object which corresponds to the top directory of the
+       stored revision.
+
+parent::
+       A commit object contains a (possibly empty) list of the logical
+       predecessor(s) in the line of development, i.e. its parents.
+
+changeset::
+       BitKeeper/cvsps speak for "commit". Since git does not store
+       changes, but states, it really does not make sense to use
+       the term "changesets" with git.
+
+clean::
+       A working tree is clean, if it corresponds to the revision
+       referenced by the current head.
+
+dirty::
+       A working tree is said to be dirty if it contains modifications
+       which have not been committed to the current branch.
+
+head::
+       The top of a branch. It contains a ref to the corresponding
+       commit object.
+
+branch::
+       A non-cyclical graph of revisions, i.e. the complete history of
+       a particular revision, which is called the branch head. The
+       branch heads are stored in $GIT_DIR/refs/heads/.
+
+ref::
+       A 40-byte hex representation of a SHA1 pointing to a particular
+       object. These may be stored in $GIT_DIR/refs/.
+
+head ref::
+       A ref pointing to a head. Often, this is abbreviated to "head".
+       Head refs are stored in $GIT_DIR/refs/heads/.
+
+tree-ish::
+       A ref pointing to either a commit object, a tree object, or a
+       tag object pointing to a tag or commit or tree object.
+
+ent::
+       Favorite synonym to "tree-ish" by some total geeks. See
+       http://en.wikipedia.org/wiki/Ent_(Middle-earth) for an in-depth
+       explanation.
+
+tag object::
+       An object containing a ref pointing to another object, which can
+       contain a message just like a commit object. It can also
+       contain a (PGP) signature, in which case it is called a "signed
+       tag object".
+
+tag::
+       A ref pointing to a tag or commit object. In contrast to a head,
+       a tag is not changed by a commit. Tags (not tag objects) are
+       stored in $GIT_DIR/refs/tags/. A git tag has nothing to do with
+       a Lisp tag (which is called object type in git's context).
+       A tag is most typically used to mark a particular point in the
+       commit ancestry chain.
+
+merge::
+       To merge branches means to try to accumulate the changes since a
+       common ancestor and apply them to the first branch. An automatic
+       merge uses heuristics to accomplish that. Evidently, an automatic
+       merge can fail.
+
+octopus::
+       To merge more than two branches. Also denotes an intelligent
+       predator.
+
+resolve::
+       The action of fixing up manually what a failed automatic merge
+       left behind.
+
+rewind::
+       To throw away part of the development, i.e. to assign the head to
+       an earlier revision.
+
+rebase::
+       To clean a branch by starting from the head of the main line of
+       development ("master"), and reapply the (possibly cherry-picked)
+       changes from that branch.
+
+repository::
+       A collection of refs together with an object database containing
+       all objects, which are reachable from the refs, possibly accompanied
+       by meta data from one or more porcelains. A repository can
+       share an object database with other repositories.
+
+git archive::
+       Synonym for repository (for arch people).
+
+file system::
+       Linus Torvalds originally designed git to be a user space file
+       system, i.e. the infrastructure to hold files and directories.
+       That ensured the efficiency and speed of git.
+
+alternate object database::
+       Via the alternates mechanism, a repository can inherit part of its
+       object database from another object database, which is called
+       "alternate".
+
+reachable::
+       An object is reachable from a ref/commit/tree/tag, if there is a
+       chain leading from the latter to the former.
+
+chain::
+       A list of objects, where each object in the list contains a
+       reference to its successor (for example, the successor of a commit
+       could be one of its parents).
+
+fetch::
+       Fetching a branch means to get the branch's head ref from a
+       remote repository, to find out which objects are missing from
+       the local object database, and to get them, too.
+
+pull::
+       Pulling a branch means to fetch it and merge it.
+
+push::
+       Pushing a branch means to get the branch's head ref from a remote
+       repository, find out if it is an ancestor to the branch's local
+       head ref is a direct, and in that case, putting all objects, which
+       are reachable from the local head ref, and which are missing from
+       the remote repository, into the remote object database, and updating
+       the remote head ref. If the remote head is not an ancestor to the
+       local head, the push fails.
+
+pack::
+       A set of objects which have been compressed into one file (to save
+       space or to transmit them efficiently).
+
+pack index::
+       The list of identifiers, and other information, of the objects in a
+       pack, to assist in efficiently accessing the contents of a pack. 
+
+core git::
+       Fundamental data structures and utilities of git. Exposes only
+       limited source code management tools.
+
+plumbing::
+       Cute name for core git.
+
+porcelain::
+ &nb