summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--.gitignore177
-rw-r--r--.mailmap54
-rw-r--r--COPYING361
-rw-r--r--Documentation/.gitignore8
-rw-r--r--Documentation/CodingGuidelines112
-rw-r--r--Documentation/Makefile232
-rw-r--r--Documentation/RelNotes-1.5.0.1.txt42
-rw-r--r--Documentation/RelNotes-1.5.0.2.txt65
-rw-r--r--Documentation/RelNotes-1.5.0.3.txt58
-rw-r--r--Documentation/RelNotes-1.5.0.4.txt22
-rw-r--r--Documentation/RelNotes-1.5.0.5.txt26
-rw-r--r--Documentation/RelNotes-1.5.0.6.txt21
-rw-r--r--Documentation/RelNotes-1.5.0.7.txt18
-rw-r--r--Documentation/RelNotes-1.5.0.txt469
-rw-r--r--Documentation/RelNotes-1.5.1.1.txt65
-rw-r--r--Documentation/RelNotes-1.5.1.2.txt50
-rw-r--r--Documentation/RelNotes-1.5.1.3.txt45
-rw-r--r--Documentation/RelNotes-1.5.1.4.txt30
-rw-r--r--Documentation/RelNotes-1.5.1.5.txt42
-rw-r--r--Documentation/RelNotes-1.5.1.6.txt45
-rw-r--r--Documentation/RelNotes-1.5.1.txt371
-rw-r--r--Documentation/RelNotes-1.5.2.1.txt53
-rw-r--r--Documentation/RelNotes-1.5.2.2.txt61
-rw-r--r--Documentation/RelNotes-1.5.2.3.txt27
-rw-r--r--Documentation/RelNotes-1.5.2.4.txt28
-rw-r--r--Documentation/RelNotes-1.5.2.5.txt30
-rw-r--r--Documentation/RelNotes-1.5.2.txt197
-rw-r--r--Documentation/RelNotes-1.5.3.1.txt10
-rw-r--r--Documentation/RelNotes-1.5.3.2.txt58
-rw-r--r--Documentation/RelNotes-1.5.3.3.txt31
-rw-r--r--Documentation/RelNotes-1.5.3.4.txt35
-rw-r--r--Documentation/RelNotes-1.5.3.5.txt94
-rw-r--r--Documentation/RelNotes-1.5.3.6.txt48
-rw-r--r--Documentation/RelNotes-1.5.3.7.txt45
-rw-r--r--Documentation/RelNotes-1.5.3.8.txt25
-rw-r--r--Documentation/RelNotes-1.5.3.txt366
-rw-r--r--Documentation/RelNotes-1.5.4.1.txt17
-rw-r--r--Documentation/RelNotes-1.5.4.2.txt43
-rw-r--r--Documentation/RelNotes-1.5.4.3.txt27
-rw-r--r--Documentation/RelNotes-1.5.4.4.txt46
-rw-r--r--Documentation/RelNotes-1.5.4.txt377
-rw-r--r--Documentation/SubmittingPatches404
-rw-r--r--Documentation/asciidoc.conf66
-rw-r--r--Documentation/blame-options.txt87
-rwxr-xr-xDocumentation/build-docdep.perl46
-rw-r--r--Documentation/callouts.xsl30
-rwxr-xr-xDocumentation/cat-texi.perl38
-rwxr-xr-xDocumentation/cmd-list.perl74
-rw-r--r--Documentation/config.txt887
-rw-r--r--Documentation/core-tutorial.txt1681
-rw-r--r--Documentation/cvs-migration.txt171
-rw-r--r--Documentation/diff-format.txt147
-rw-r--r--Documentation/diff-generate-patch.txt161
-rw-r--r--Documentation/diff-options.txt224
-rw-r--r--Documentation/diffcore.txt271
-rw-r--r--Documentation/docbook-xsl.css286
-rw-r--r--Documentation/docbook.xsl5
-rw-r--r--Documentation/everyday.txt458
-rw-r--r--Documentation/fetch-options.txt58
-rwxr-xr-xDocumentation/fix-texi.perl15
-rw-r--r--Documentation/git-add.txt251
-rw-r--r--Documentation/git-am.txt160
-rw-r--r--Documentation/git-annotate.txt31
-rw-r--r--Documentation/git-apply.txt209
-rw-r--r--Documentation/git-archimport.txt120
-rw-r--r--Documentation/git-archive.txt121
-rw-r--r--Documentation/git-bisect.txt230
-rw-r--r--Documentation/git-blame.txt195
-rw-r--r--Documentation/git-branch.txt191
-rw-r--r--Documentation/git-bundle.txt148
-rw-r--r--Documentation/git-cat-file.txt73
-rw-r--r--Documentation/git-check-attr.txt41
-rw-r--r--Documentation/git-check-ref-format.txt55
-rw-r--r--Documentation/git-checkout-index.txt184
-rw-r--r--Documentation/git-checkout.txt220
-rw-r--r--Documentation/git-cherry-pick.txt78
-rw-r--r--Documentation/git-cherry.txt69
-rw-r--r--Documentation/git-citool.txt32
-rw-r--r--Documentation/git-clean.txt57
-rw-r--r--Documentation/git-clone.txt203
-rw-r--r--Documentation/git-commit-tree.txt106
-rw-r--r--Documentation/git-commit.txt304
-rw-r--r--Documentation/git-config.txt335
-rw-r--r--Documentation/git-count-objects.txt37
-rw-r--r--Documentation/git-cvsexportcommit.txt109
-rw-r--r--Documentation/git-cvsimport.txt169
-rw-r--r--Documentation/git-cvsserver.txt322
-rw-r--r--Documentation/git-daemon.txt275
-rw-r--r--Documentation/git-describe.txt126
-rw-r--r--Documentation/git-diff-files.txt60
-rw-r--r--Documentation/git-diff-index.txt132
-rw-r--r--Documentation/git-diff-tree.txt168
-rw-r--r--Documentation/git-diff.txt171
-rw-r--r--Documentation/git-fast-export.txt83
-rw-r--r--Documentation/git-fast-import.txt1030
-rw-r--r--Documentation/git-fetch-pack.txt96
-rw-r--r--Documentation/git-fetch.txt56
-rw-r--r--Documentation/git-filter-branch.txt309
-rw-r--r--Documentation/git-fmt-merge-msg.txt62
-rw-r--r--Documentation/git-for-each-ref.txt193
-rw-r--r--Documentation/git-format-patch.txt208
-rw-r--r--Documentation/git-fsck-objects.txt17
-rw-r--r--Documentation/git-fsck.txt153
-rw-r--r--Documentation/git-gc.txt117
-rw-r--r--Documentation/git-get-tar-commit-id.txt36
-rw-r--r--Documentation/git-grep.txt146
-rw-r--r--Documentation/git-gui.txt115
-rw-r--r--Documentation/git-hash-object.txt45
-rw-r--r--Documentation/git-help.txt113
-rw-r--r--Documentation/git-http-fetch.txt56
-rw-r--r--Documentation/git-http-push.txt104
-rw-r--r--Documentation/git-imap-send.txt62
-rw-r--r--Documentation/git-index-pack.txt100
-rw-r--r--Documentation/git-init-db.txt18
-rw-r--r--Documentation/git-init.txt114
-rw-r--r--Documentation/git-instaweb.txt87
-rw-r--r--Documentation/git-log.txt115
-rw-r--r--Documentation/git-lost-found.txt81
-rw-r--r--Documentation/git-ls-files.txt195
-rw-r--r--Documentation/git-ls-remote.txt72
-rw-r--r--Documentation/git-ls-tree.txt94
-rw-r--r--Documentation/git-mailinfo.txt69
-rw-r--r--Documentation/git-mailsplit.txt58
-rw-r--r--Documentation/git-merge-base.txt42
-rw-r--r--Documentation/git-merge-file.txt92
-rw-r--r--Documentation/git-merge-index.txt87
-rw-r--r--Documentation/git-merge-one-file.txt29
-rw-r--r--Documentation/git-merge-tree.txt36
-rw-r--r--Documentation/git-merge.txt182
-rw-r--r--Documentation/git-mergetool.txt51
-rw-r--r--Documentation/git-mktag.txt46
-rw-r--r--Documentation/git-mktree.txt34
-rw-r--r--Documentation/git-mv.txt53
-rw-r--r--Documentation/git-name-rev.txt78
-rw-r--r--Documentation/git-pack-objects.txt202
-rw-r--r--Documentation/git-pack-redundant.txt57
-rw-r--r--Documentation/git-pack-refs.txt66
-rw-r--r--Documentation/git-parse-remote.txt50
-rw-r--r--Documentation/git-patch-id.txt42
-rw-r--r--Documentation/git-peek-remote.txt50
-rw-r--r--Documentation/git-prune-packed.txt52
-rw-r--r--Documentation/git-prune.txt63
-rw-r--r--Documentation/git-pull.txt182
-rw-r--r--Documentation/git-push.txt197
-rw-r--r--Documentation/git-quiltimport.txt60
-rw-r--r--Documentation/git-read-tree.txt364
-rw-r--r--Documentation/git-rebase.txt404
-rw-r--r--Documentation/git-receive-pack.txt165
-rw-r--r--Documentation/git-reflog.txt91
-rw-r--r--Documentation/git-relink.txt37
-rw-r--r--Documentation/git-remote.txt147
-rw-r--r--Documentation/git-repack.txt117
-rw-r--r--Documentation/git-repo-config.txt18
-rw-r--r--Documentation/git-request-pull.txt39
-rw-r--r--Documentation/git-rerere.txt211
-rw-r--r--Documentation/git-reset.txt206
-rw-r--r--Documentation/git-rev-list.txt108
-rw-r--r--Documentation/git-rev-parse.txt381
-rw-r--r--Documentation/git-revert.txt65
-rw-r--r--Documentation/git-rm.txt98
-rw-r--r--Documentation/git-send-email.txt201
-rw-r--r--Documentation/git-send-pack.txt128
-rw-r--r--Documentation/git-sh-setup.txt80
-rw-r--r--Documentation/git-shell.txt34
-rw-r--r--Documentation/git-shortlog.txt62
-rw-r--r--Documentation/git-show-branch.txt193
-rw-r--r--Documentation/git-show-index.txt34
-rw-r--r--Documentation/git-show-ref.txt172
-rw-r--r--Documentation/git-show.txt86
-rw-r--r--Documentation/git-stash.txt174
-rw-r--r--Documentation/git-status.txt70
-rw-r--r--Documentation/git-stripspace.txt35
-rw-r--r--Documentation/git-submodule.txt82
-rw-r--r--Documentation/git-svn.txt583
-rw-r--r--Documentation/git-symbolic-ref.txt61
-rw-r--r--Documentation/git-tag.txt251
-rw-r--r--Documentation/git-tar-tree.txt89
-rw-r--r--Documentation/git-tools.txt118
-rw-r--r--Documentation/git-unpack-file.txt35
-rw-r--r--Documentation/git-unpack-objects.txt54
-rw-r--r--Documentation/git-update-index.txt326
-rw-r--r--Documentation/git-update-ref.txt93
-rw-r--r--Documentation/git-update-server-info.txt57
-rw-r--r--Documentation/git-upload-archive.txt37
-rw-r--r--Documentation/git-upload-pack.txt46
-rw-r--r--Documentation/git-var.txt64
-rw-r--r--Documentation/git-verify-pack.txt53
-rw-r--r--Documentation/git-verify-tag.txt31
-rw-r--r--Documentation/git-whatchanged.txt80
-rw-r--r--Documentation/git-write-tree.txt49
-rw-r--r--Documentation/git.txt563
-rw-r--r--Documentation/gitattributes.txt494
-rw-r--r--Documentation/gitcli.txt113
-rw-r--r--Documentation/gitignore.txt122
-rw-r--r--Documentation/gitk.txt101
-rw-r--r--Documentation/gitmodules.txt62
-rw-r--r--Documentation/glossary.txt454
-rw-r--r--Documentation/hooks.txt249
-rwxr-xr-xDocumentation/howto-index.sh56
-rw-r--r--Documentation/howto/maintain-git.txt277
-rw-r--r--Documentation/howto/rebase-and-edit.txt79
-rw-r--r--Documentation/howto/rebase-from-internal-branch.txt163
-rw-r--r--Documentation/howto/rebuild-from-update-hook.txt86
-rw-r--r--Documentation/howto/recover-corrupted-blob-object.txt134
-rw-r--r--Documentation/howto/revert-branch-rebase.txt193
-rw-r--r--Documentation/howto/separating-topic-branches.txt90
-rw-r--r--Documentation/howto/setup-git-server-over-http.txt256
-rw-r--r--Documentation/howto/update-hook-example.txt172
-rw-r--r--Documentation/howto/use-git-daemon.txt51
-rw-r--r--Documentation/howto/using-merge-subtree.txt75
-rw-r--r--Documentation/i18n.txt57
-rwxr-xr-xDocumentation/install-doc-quick.sh31
-rwxr-xr-xDocumentation/install-webdoc.sh39
-rw-r--r--Documentation/manpage-1.72.xsl17
-rw-r--r--Documentation/merge-options.txt44
-rw-r--r--Documentation/merge-strategies.txt35
-rw-r--r--Documentation/pretty-formats.txt125
-rw-r--r--Documentation/pretty-options.txt22
-rw-r--r--Documentation/pull-fetch-param.txt65
-rw-r--r--Documentation/repository-layout.txt179
-rw-r--r--Documentation/rev-list-options.txt361
-rw-r--r--Documentation/technical/.gitignore1
-rw-r--r--Documentation/technical/api-allocation-growing.txt34
-rw-r--r--Documentation/technical/api-builtin.txt63
-rw-r--r--Documentation/technical/api-decorate.txt6
-rw-r--r--Documentation/technical/api-diff.txt166
-rw-r--r--Documentation/technical/api-directory-listing.txt76
-rw-r--r--Documentation/technical/api-gitattributes.txt111
-rw-r--r--Documentation/technical/api-grep.txt8
-rw-r--r--Documentation/technical/api-hash.txt6
-rw-r--r--Documentation/technical/api-in-core-index.txt21
-rw-r--r--Documentation/technical/api-index-skel.txt15
-rwxr-xr-xDocumentation/technical/api-index.sh28
-rw-r--r--Documentation/technical/api-lockfile.txt74
-rw-r--r--Documentation/technical/api-object-access.txt15
-rw-r--r--Documentation/technical/api-parse-options.txt6
-rw-r--r--Documentation/technical/api-path-list.txt9
-rw-r--r--Documentation/technical/api-quote.txt10
-rw-r--r--Documentation/technical/api-revision-walking.txt9
-rw-r--r--Documentation/technical/api-run-command.txt10
-rw-r--r--Documentation/technical/api-setup.txt13
-rw-r--r--Documentation/technical/api-strbuf.txt6
-rw-r--r--Documentation/technical/api-tree-walking.txt12
-rw-r--r--Documentation/technical/api-xdiff-interface.txt7
-rw-r--r--Documentation/technical/pack-format.txt146
-rw-r--r--Documentation/technical/pack-heuristics.txt466
-rw-r--r--Documentation/technical/pack-protocol.txt41
-rw-r--r--Documentation/technical/racy-git.txt195
-rw-r--r--Documentation/technical/send-pack-pipeline.txt63
-rw-r--r--Documentation/technical/shallow.txt49
-rw-r--r--Documentation/technical/trivial-merge.txt121
-rw-r--r--Documentation/tutorial-2.txt406
-rw-r--r--Documentation/tutorial.txt584
-rw-r--r--Documentation/urls-remotes.txt55
-rw-r--r--Documentation/urls.txt46
-rw-r--r--Documentation/user-manual.conf21
-rw-r--r--Documentation/user-manual.txt4562
-rwxr-xr-xGIT-VERSION-GEN79
-rw-r--r--INSTALL129
-rw-r--r--Makefile1423
-rw-r--r--README46
l---------RelNotes1
-rw-r--r--alloc.c76
-rw-r--r--archive-tar.c293
-rw-r--r--archive-zip.c354
-rw-r--r--archive.c84
-rw-r--r--archive.h48
-rw-r--r--arm/sha1.c82
-rw-r--r--arm/sha1.h18
-rw-r--r--arm/sha1_arm.S183
-rw-r--r--attr.c635
-rw-r--r--attr.h34
-rw-r--r--base85.c140
-rw-r--r--blob.c46
-rw-r--r--blob.h18
-rw-r--r--builtin-add.c267
-rw-r--r--builtin-annotate.c24
-rw-r--r--builtin-apply.c2931
-rw-r--r--builtin-archive.c261
-rw-r--r--builtin-blame.c2454
-rw-r--r--builtin-branch.c623
-rw-r--r--builtin-bundle.c63
-rw-r--r--builtin-cat-file.c159
-rw-r--r--builtin-check-attr.c64
-rw-r--r--builtin-check-ref-format.c14
-rw-r--r--builtin-checkout-index.c303
-rw-r--r--builtin-clean.c172
-rw-r--r--builtin-commit-tree.c121
-rw-r--r--builtin-commit.c951
-rw-r--r--builtin-config.c404
-rw-r--r--builtin-count-objects.c128
-rw-r--r--builtin-describe.c288
-rw-r--r--builtin-diff-files.c35
-rw-r--r--builtin-diff-index.c48
-rw-r--r--builtin-diff-tree.c137
-rw-r--r--builtin-diff.c359
-rwxr-xr-xbuiltin-fast-export.c406
-rw-r--r--builtin-fetch--tool.c574
-rw-r--r--builtin-fetch-pack.c794
-rw-r--r--builtin-fetch.c632
-rw-r--r--builtin-fmt-merge-msg.c354
-rw-r--r--builtin-for-each-ref.c894
-rw-r--r--builtin-fsck.c784
-rw-r--r--builtin-gc.c244
-rw-r--r--builtin-grep.c788
-rw-r--r--builtin-http-fetch.c87
-rw-r--r--builtin-init-db.c416
-rw-r--r--builtin-log.c961
-rw-r--r--builtin-ls-files.c621
-rw-r--r--builtin-ls-remote.c105
-rw-r--r--builtin-ls-tree.c195
-rw-r--r--builtin-mailinfo.c988
-rw-r--r--builtin-mailsplit.c302
-rw-r--r--builtin-merge-base.c52
-rw-r--r--builtin-merge-file.c68
-rw-r--r--builtin-merge-ours.c28
-rw-r--r--builtin-mv.c273
-rw-r--r--builtin-name-rev.c279
-rw-r--r--builtin-pack-objects.c2250
-rw-r--r--builtin-pack-refs.c140
-rw-r--r--builtin-prune-packed.c91
-rw-r--r--builtin-prune.c158
-rw-r--r--builtin-push.c152
-rw-r--r--builtin-read-tree.c289
-rw-r--r--builtin-reflog.c430
-rw-r--r--builtin-rerere.c437
-rw-r--r--builtin-reset.c293
-rw-r--r--builtin-rev-list.c664
-rw-r--r--builtin-rev-parse.c572
-rw-r--r--builtin-revert.c431
-rw-r--r--builtin-rm.c258
-rw-r--r--builtin-send-pack.c654
-rw-r--r--builtin-shortlog.c298
-rw-r--r--builtin-show-branch.c918
-rw-r--r--builtin-show-ref.c253
-rw-r--r--builtin-stripspace.c89
-rw-r--r--builtin-symbolic-ref.c53
-rw-r--r--builtin-tag.c482
-rw-r--r--builtin-tar-tree.c90
-rw-r--r--builtin-unpack-objects.c402
-rw-r--r--builtin-update-index.c748
-rw-r--r--builtin-update-ref.c51
-rw-r--r--builtin-upload-archive.c172
-rw-r--r--builtin-verify-pack.c80
-rw-r--r--builtin-verify-tag.c110
-rw-r--r--builtin-write-tree.c91
-rw-r--r--builtin.h98
-rw-r--r--bundle.c357
-rw-r--r--bundle.h25
-rw-r--r--cache-tree.c531
-rw-r--r--cache-tree.h33
-rw-r--r--cache.h672
-rwxr-xr-xcheck-builtins.sh34
-rw-r--r--check-racy.c28
-rw-r--r--color.c181
-rw-r--r--color.h12
-rw-r--r--combine-diff.c1030
-rw-r--r--command-list.txt130
-rw-r--r--commit.c685
-rw-r--r--commit.h124
-rw-r--r--compat/hstrerror.c21
-rw-r--r--compat/inet_ntop.c199
-rw-r--r--compat/inet_pton.c219
-rw-r--r--compat/memmem.c29
-rw-r--r--compat/mkdtemp.c8
-rw-r--r--compat/mmap.c42
-rw-r--r--compat/pread.c18
-rw-r--r--compat/setenv.c34
-rw-r--r--compat/strcasestr.c22
-rw-r--r--compat/strlcpy.c13
-rw-r--r--compat/strtoumax.c10
-rw-r--r--compat/unsetenv.c25
-rw-r--r--config.c1091
-rw-r--r--config.mak.in48
-rw-r--r--configure.ac482
-rw-r--r--connect.c647
-rw-r--r--contrib/README43
-rw-r--r--contrib/blameview/README9
-rwxr-xr-xcontrib/blameview/blameview.perl155
-rwxr-xr-xcontrib/completion/git-completion.bash1265
-rw-r--r--contrib/continuous/cidaemon503
-rw-r--r--contrib/continuous/post-receive-cinotify104
-rw-r--r--contrib/convert-objects/convert-objects.c329
-rw-r--r--contrib/convert-objects/git-convert-objects.txt28
-rw-r--r--contrib/emacs/.gitignore1
-rw-r--r--contrib/emacs/Makefile21
-rw-r--r--contrib/emacs/git-blame.el426
-rw-r--r--contrib/emacs/git.el1475
-rw-r--r--contrib/emacs/vc-git.el216
-rwxr-xr-xcontrib/examples/git-clean.sh118
-rwxr-xr-xcontrib/examples/git-commit.sh639
-rwxr-xr-xcontrib/examples/git-fetch.sh377
-rwxr-xr-xcontrib/examples/git-gc.sh37
-rwxr-xr-xcontrib/examples/git-ls-remote.sh142
-rwxr-xr-xcontrib/examples/git-merge-ours.sh14
-rwxr-xr-xcontrib/examples/git-reset.sh106
-rwxr-xr-xcontrib/examples/git-resolve.sh112
-rwxr-xr-xcontrib/examples/git-revert.sh197
-rwxr-xr-xcontrib/examples/git-svnimport.perl976
-rw-r--r--contrib/examples/git-svnimport.txt179
-rwxr-xr-xcontrib/examples/git-tag.sh205
-rwxr-xr-xcontrib/examples/git-verify-tag.sh45
-rwxr-xr-xcontrib/fast-import/git-import.perl64
-rwxr-xr-xcontrib/fast-import/git-import.sh38
-rwxr-xr-xcontrib/fast-import/git-p41828
-rw-r--r--contrib/fast-import/git-p4.bat1
-rw-r--r--contrib/fast-import/git-p4.txt159
-rwxr-xr-xcontrib/fast-import/import-tars.perl131
-rwxr-xr-xcontrib/gitview/gitview1305
-rw-r--r--contrib/gitview/gitview.txt56
-rwxr-xr-xcontrib/hg-to-git/hg-to-git.py239
-rw-r--r--contrib/hg-to-git/hg-to-git.txt21
-rw-r--r--contrib/hooks/post-receive-email643
-rw-r--r--contrib/hooks/setgitperms.perl214
-rw-r--r--contrib/hooks/update-paranoid421
-rw-r--r--contrib/p4import/README1
-rw-r--r--contrib/p4import/git-p4import.py360
-rw-r--r--contrib/p4import/git-p4import.txt167
-rw-r--r--contrib/patches/docbook-xsl-manpages-charmap.patch21
-rwxr-xr-xcontrib/remotes2config.sh33
-rwxr-xr-xcontrib/stats/git-common-hash26
-rwxr-xr-xcontrib/stats/mailmap.pl38
-rwxr-xr-xcontrib/stats/packinfo.pl212
-rw-r--r--contrib/vim/README8
-rw-r--r--contrib/vim/syntax/gitcommit.vim18
-rwxr-xr-xcontrib/workdir/git-new-workdir82
-rw-r--r--convert.c597
-rw-r--r--copy.c57
-rw-r--r--csum-file.c112
-rw-r--r--csum-file.h26
-rw-r--r--ctype.c22
-rw-r--r--daemon.c1209
-rw-r--r--date.c859
-rw-r--r--decorate.c88
-rw-r--r--decorate.h18
-rw-r--r--delta.h105
-rw-r--r--diff-delta.c482
-rw-r--r--diff-lib.c741
-rw-r--r--diff.c3216
-rw-r--r--diff.h254
-rw-r--r--diffcore-break.c293
-rw-r--r--diffcore-delta.c224
-rw-r--r--diffcore-order.c124
-rw-r--r--diffcore-pickaxe.c139
-rw-r--r--diffcore-rename.c613
-rw-r--r--diffcore.h121
-rw-r--r--dir.c795
-rw-r--r--dir.h83
-rw-r--r--dump-cache-tree.c64
-rw-r--r--entry.c234
-rw-r--r--environment.c136
-rw-r--r--exec_cmd.c119
-rw-r--r--exec_cmd.h11
-rw-r--r--fast-import.c2470
-rw-r--r--fetch-pack.h24
-rwxr-xr-xfixup-builtins16
-rwxr-xr-xgenerate-cmdlist.sh24
-rwxr-xr-xgit-add--interactive.perl1028
-rwxr-xr-xgit-am.sh477
-rwxr-xr-xgit-archimport.perl1133
-rwxr-xr-xgit-bisect.sh488
-rwxr-xr-xgit-checkout.sh299
-rwxr-xr-xgit-clone.sh495
-rw-r--r--git-compat-util.h429
-rwxr-xr-xgit-cvsexportcommit.perl357
-rwxr-xr-xgit-cvsimport.perl1009
-rwxr-xr-xgit-cvsserver.perl3064
-rwxr-xr-xgit-filter-branch.sh422
-rw-r--r--git-gui/.gitignore8
-rwxr-xr-xgit-gui/GIT-VERSION-GEN80
-rw-r--r--git-gui/Makefile339
-rwxr-xr-xgit-gui/git-gui.sh (renamed from git-gui.sh)0
-rw-r--r--git-gui/lib/about.tcl (renamed from lib/about.tcl)0
-rw-r--r--git-gui/lib/blame.tcl (renamed from lib/blame.tcl)0
-rw-r--r--git-gui/lib/branch.tcl (renamed from lib/branch.tcl)0
-rw-r--r--git-gui/lib/branch_checkout.tcl (renamed from lib/branch_checkout.tcl)0
-rw-r--r--git-gui/lib/branch_create.tcl (renamed from lib/branch_create.tcl)0
-rw-r--r--git-gui/lib/branch_delete.tcl (renamed from lib/branch_delete.tcl)0
-rw-r--r--git-gui/lib/branch_rename.tcl (renamed from lib/branch_rename.tcl)0
-rw-r--r--git-gui/lib/browser.tcl (renamed from lib/browser.tcl)0
-rw-r--r--git-gui/lib/checkout_op.tcl (renamed from lib/checkout_op.tcl)0
-rw-r--r--git-gui/lib/choose_font.tcl (renamed from lib/choose_font.tcl)0
-rw-r--r--git-gui/lib/choose_repository.tcl (renamed from lib/choose_repository.tcl)0
-rw-r--r--git-gui/lib/choose_rev.tcl (renamed from lib/choose_rev.tcl)0
-rw-r--r--git-gui/lib/class.tcl (renamed from lib/class.tcl)0
-rw-r--r--git-gui/lib/commit.tcl (renamed from lib/commit.tcl)0
-rw-r--r--git-gui/lib/console.tcl (renamed from lib/console.tcl)0
-rw-r--r--git-gui/lib/database.tcl (renamed from lib/database.tcl)0
-rw-r--r--git-gui/lib/date.tcl (renamed from lib/date.tcl)0
-rw-r--r--git-gui/lib/diff.tcl (renamed from lib/diff.tcl)0
-rw-r--r--git-gui/lib/encoding.tcl (renamed from lib/encoding.tcl)0
-rw-r--r--git-gui/lib/error.tcl (renamed from lib/error.tcl)0
-rw-r--r--git-gui/lib/git-gui.ico (renamed from lib/git-gui.ico)bin3638 -> 3638 bytes
-rw-r--r--git-gui/lib/index.tcl (renamed from lib/index.tcl)0
-rw-r--r--git-gui/lib/logo.tcl (renamed from lib/logo.tcl)0
-rw-r--r--git-gui/lib/merge.tcl (renamed from lib/merge.tcl)0
-rw-r--r--git-gui/lib/option.tcl (renamed from lib/option.tcl)0
-rw-r--r--git-gui/lib/remote.tcl (renamed from lib/remote.tcl)0
-rw-r--r--git-gui/lib/remote_branch_delete.tcl (renamed from lib/remote_branch_delete.tcl)0
-rw-r--r--git-gui/lib/shortcut.tcl (renamed from lib/shortcut.tcl)0
-rw-r--r--git-gui/lib/status_bar.tcl (renamed from lib/status_bar.tcl)0
-rw-r--r--git-gui/lib/transport.tcl (renamed from lib/transport.tcl)0
-rw-r--r--git-gui/lib/win32.tcl (renamed from lib/win32.tcl)0
-rw-r--r--git-gui/lib/win32_shortcut.js (renamed from lib/win32_shortcut.js)0
-rw-r--r--git-gui/macosx/AppMain.tcl (renamed from macosx/AppMain.tcl)0
-rw-r--r--git-gui/macosx/Info.plist (renamed from macosx/Info.plist)0
-rw-r--r--git-gui/macosx/git-gui.icns (renamed from macosx/git-gui.icns)bin28866 -> 28866 bytes
-rw-r--r--git-gui/po/.gitignore (renamed from po/.gitignore)0
-rw-r--r--git-gui/po/README (renamed from po/README)0
-rw-r--r--git-gui/po/de.po (renamed from po/de.po)0
-rw-r--r--git-gui/po/fr.po (renamed from po/fr.po)0
-rw-r--r--git-gui/po/git-gui.pot (renamed from po/git-gui.pot)0
-rw-r--r--git-gui/po/glossary/Makefile (renamed from po/glossary/Makefile)0
-rw-r--r--git-gui/po/glossary/de.po (renamed from po/glossary/de.po)0
-rw-r--r--git-gui/po/glossary/fr.po (renamed from po/glossary/fr.po)0
-rw-r--r--git-gui/po/glossary/git-gui-glossary.pot (renamed from po/glossary/git-gui-glossary.pot)0
-rw-r--r--git-gui/po/glossary/git-gui-glossary.txt (renamed from po/glossary/git-gui-glossary.txt)0
-rw-r--r--git-gui/po/glossary/it.po (renamed from po/glossary/it.po)0
-rwxr-xr-xgit-gui/po/glossary/txt-to-pot.sh (renamed from po/glossary/txt-to-pot.sh)0
-rw-r--r--git-gui/po/glossary/zh_cn.po (renamed from po/glossary/zh_cn.po)0
-rw-r--r--git-gui/po/hu.po (renamed from po/hu.po)0
-rw-r--r--git-gui/po/it.po (renamed from po/it.po)0
-rw-r--r--git-gui/po/ja.po (renamed from po/ja.po)0
-rw-r--r--git-gui/po/po2msg.sh (renamed from po/po2msg.sh)0
-rw-r--r--git-gui/po/ru.po (renamed from po/ru.po)0
-rw-r--r--git-gui/po/sv.po (renamed from po/sv.po)0
-rw-r--r--git-gui/po/zh_cn.po (renamed from po/zh_cn.po)0
-rw-r--r--git-gui/windows/git-gui.sh (renamed from windows/git-gui.sh)0
-rwxr-xr-xgit-help--browse.sh149
-rwxr-xr-xgit-instaweb.sh287
-rwxr-xr-xgit-lost-found.sh33
-rwxr-xr-xgit-merge-octopus.sh114
-rwxr-xr-xgit-merge-one-file.sh140
-rwxr-xr-xgit-merge-resolve.sh54
-rwxr-xr-xgit-merge-stupid.sh80
-rwxr-xr-xgit-merge.sh549
-rwxr-xr-xgit-mergetool.sh412
-rwxr-xr-xgit-parse-remote.sh264
-rwxr-xr-xgit-pull.sh179
-rwxr-xr-xgit-quiltimport.sh122
-rwxr-xr-xgit-rebase--interactive.sh556
-rwxr-xr-xgit-rebase.sh420
-rwxr-xr-xgit-relink.perl173
-rwxr-xr-xgit-remote.perl475
-rwxr-xr-xgit-repack.sh144
-rwxr-xr-xgit-request-pull.sh57
-rwxr-xr-xgit-send-email.perl865
-rwxr-xr-xgit-sh-setup.sh150
-rwxr-xr-xgit-stash.sh243
-rwxr-xr-xgit-submodule.sh439
-rwxr-xr-xgit-svn.perl4825
-rw-r--r--git.c477
-rw-r--r--git.spec.in279
-rw-r--r--gitk-git/Makefile63
-rw-r--r--gitk-git/gitk8667
-rw-r--r--gitk-git/po/.gitignore1
-rw-r--r--gitk-git/po/de.po725
-rw-r--r--gitk-git/po/po2msg.sh133
-rw-r--r--gitweb/INSTALL225
-rw-r--r--gitweb/README273
-rw-r--r--gitweb/git-favicon.pngbin0 -> 164 bytes
-rw-r--r--gitweb/git-logo.pngbin0 -> 208 bytes
-rw-r--r--gitweb/gitweb.css501
-rwxr-xr-xgitweb/gitweb.perl5700
-rw-r--r--gitweb/test/Märchen2
-rw-r--r--gitweb/test/file with spaces4
-rw-r--r--gitweb/test/file+plus+sign6
-rw-r--r--grep.c565
-rw-r--r--grep.h81
-rw-r--r--hash-object.c83
-rw-r--r--hash.c110
-rw-r--r--hash.h43
-rw-r--r--help.c400
-rw-r--r--http-push.c2455
-rw-r--r--http-walker.c938
-rw-r--r--http.c633
-rw-r--r--http.h109
-rw-r--r--ident.c257
-rw-r--r--imap-send.c1342
-rw-r--r--index-pack.c835
-rw-r--r--interpolate.c104
-rw-r--r--interpolate.h26
-rw-r--r--list-objects.c180
-rw-r--r--list-objects.h12
-rw-r--r--lockfile.c217
-rw-r--r--log-tree.c411
-rw-r--r--log-tree.h17
-rw-r--r--mailmap.c92
-rw-r--r--mailmap.h7
-rw-r--r--match-trees.c303
-rw-r--r--merge-file.c118
-rw-r--r--merge-index.c127
-rw-r--r--merge-recursive.c1761
-rw-r--r--merge-tree.c356
-rw-r--r--mktag.c138
-rw-r--r--mktree.c130
-rw-r--r--mozilla-sha1/sha1.c151
-rw-r--r--mozilla-sha1/sha1.h45
-rw-r--r--object-refs.c87
-rw-r--r--object.c266
-rw-r--r--object.h83
-rw-r--r--pack-check.c191
-rw-r--r--pack-redundant.c695
-rw-r--r--pack-write.c208
-rw-r--r--pack.h68
-rw-r--r--pager.c85
-rw-r--r--parse-options.c397
-rw-r--r--parse-options.h119
-rw-r--r--patch-delta.c87
-rw-r--r--patch-id.c84
-rw-r--r--patch-ids.c192
-rw-r--r--patch-ids.h21
-rw-r--r--path-list.c104
-rw-r--r--path-list.h22
-rw-r--r--path.c355
-rw-r--r--perl/.gitignore5
-rw-r--r--perl/Git.pm950
-rw-r--r--perl/Makefile42
-rw-r--r--perl/Makefile.PL30
-rw-r--r--perl/private-Error.pm827
-rw-r--r--pkt-line.c114
-rw-r--r--pkt-line.h15
-rw-r--r--ppc/sha1.c72
-rw-r--r--ppc/sha1.h20
-rw-r--r--ppc/sha1ppc.S224
-rw-r--r--pretty.c835
-rw-r--r--progress.c258
-rw-r--r--progress.h14
-rw-r--r--quote.c403
-rw-r--r--quote.h55
-rw-r--r--reachable.c220
-rw-r--r--reachable.h6
-rw-r--r--read-cache.c1195
-rw-r--r--receive-pack.c507
-rw-r--r--reflog-walk.c274
-rw-r--r--reflog-walk.h11
-rw-r--r--refs.c1513
-rw-r--r--refs.h73
-rw-r--r--remote.c924
-rw-r--r--remote.h117
-rw-r--r--revision.c1632
-rw-r--r--revision.h143
-rw-r--r--run-command.c239
-rw-r--r--run-command.h69
-rw-r--r--send-pack.h18
-rw-r--r--server-info.c252
-rw-r--r--setup.c405
-rw-r--r--sha1_file.c2440
-rw-r--r--sha1_name.c720
-rw-r--r--shallow.c103
-rw-r--r--shell.c80
-rw-r--r--show-index.c78
-rw-r--r--sideband.c129
-rw-r--r--sideband.h13
-rw-r--r--strbuf.c243
-rw-r--r--strbuf.h122
-rw-r--r--symlinks.c48
-rw-r--r--t/.gitignore1
-rw-r--r--t/Makefile31
-rw-r--r--t/README211
-rw-r--r--t/annotate-tests.sh123
-rw-r--r--t/diff-lib.sh41
-rw-r--r--t/lib-git-svn.sh110
-rw-r--r--t/lib-read-tree-m-3way.sh158
-rwxr-xr-xt/t0000-basic.sh300
-rwxr-xr-xt/t0001-init.sh116
-rwxr-xr-xt/t0003-attributes.sh49
-rwxr-xr-xt/t0010-racy-git.sh33
-rwxr-xr-xt/t0020-crlf.sh381
-rwxr-xr-xt/t0021-conversion.sh89
-rwxr-xr-xt/t0022-crlf-rename.sh33
-rwxr-xr-xt/t0023-crlf-am.sh44
-rwxr-xr-xt/t0030-stripspace.sh400
-rwxr-xr-xt/t0040-parse-options.sh117
-rwxr-xr-xt/t1000-read-tree-m-3way.sh514
-rwxr-xr-xt/t1001-read-tree-m-2way.sh344
-rwxr-xr-xt/t1002-read-tree-m-u-2way.sh344
-rwxr-xr-xt/t1003-read-tree-prefix.sh27
-rwxr-xr-xt/t1004-read-tree-m-u-wf.sh119
-rwxr-xr-xt/t1020-subdirectory.sh138
-rwxr-xr-xt/t1100-commit-tree-options.sh45
-rwxr-xr-xt/t1200-tutorial.sh161
-rwxr-xr-xt/t1300-repo-config.sh678
-rwxr-xr-xt/t1301-shared-repo.sh36
-rwxr-xr-xt/t1302-repo-version.sh46
-rwxr-xr-xt/t1303-wacky-config.sh37
-rwxr-xr-xt/t1400-update-ref.sh239
-rwxr-xr-xt/t1410-reflog.sh196
-rwxr-xr-xt/t1420-lost-found.sh35
-rwxr-xr-xt/t1500-rev-parse.sh79
-rwxr-xr-xt/t1501-worktree.sh115
-rwxr-xr-xt/t1502-rev-parse-parseopt.sh43
-rwxr-xr-xt/t2000-checkout-cache-clash.sh51
-rwxr-xr-xt/t2001-checkout-cache-clash.sh86
-rwxr-xr-xt/t2002-checkout-cache-u.sh33
-rwxr-xr-xt/t2003-checkout-cache-mkdir.sh96
-rwxr-xr-xt/t2004-checkout-cache-temp.sh212
-rwxr-xr-xt/t2005-checkout-index-symlinks.sh28
-rwxr-xr-xt/t2007-checkout-symlink.sh50
-rwxr-xr-xt/t2008-checkout-subdir.sh82
-rwxr-xr-xt/t2050-git-dir-relative.sh55
-rwxr-xr-xt/t2100-update-cache-badpath.sh51
-rwxr-xr-xt/t2101-update-index-reupdate.sh84
-rwxr-xr-xt/t2102-update-index-symlinks.sh31
-rwxr-xr-xt/t2200-add-update.sh114
-rwxr-xr-xt/t3000-ls-files-others.sh56
-rwxr-xr-xt/t3001-ls-files-others-exclude.sh102
-rwxr-xr-xt/t3002-ls-files-dashpath.sh69
-rwxr-xr-xt/t3010-ls-files-killed-modified.sh96
-rwxr-xr-xt/t3020-ls-files-error-unmatch.sh27
-rwxr-xr-xt/t3030-merge-recursive.sh527
-rwxr-xr-xt/t3040-subprojects-basic.sh85
-rwxr-xr-xt/t3050-subprojects-fetch.sh52
-rwxr-xr-xt/t3060-ls-files-with-tree.sh71
-rwxr-xr-xt/t3100-ls-tree-restrict.sh158
-rwxr-xr-xt/t3101-ls-tree-dirname.sh138
-rwxr-xr-xt/t3200-branch.sh205
-rwxr-xr-xt/t3201-branch-contains.sh58
-rwxr-xr-xt/t3210-pack-refs.sh108
-rwxr-xr-xt/t3300-funny-names.sh160
-rwxr-xr-xt/t3400-rebase.sh86
-rwxr-xr-xt/t3401-rebase-partial.sh61
-rwxr-xr-xt/t3402-rebase-merge.sh111
-rwxr-xr-xt/t3403-rebase-skip.sh71
-rwxr-xr-xt/t3404-rebase-interactive.sh365
-rwxr-xr-xt/t3405-rebase-malformed.sh48
-rwxr-xr-xt/t3406-rebase-message.sh44
-rwxr-xr-xt/t3500-cherry.sh54
-rwxr-xr-xt/t3501-revert-cherry-pick.sh71
-rwxr-xr-xt/t3502-cherry-pick-merge.sh123
-rwxr-xr-xt/t3600-rm.sh219
-rwxr-xr-xt/t3700-add.sh182
-rwxr-xr-xt/t3800-mktag.sh188
-rwxr-xr-xt/t3900-i18n-commit.sh122
-rw-r--r--t/t3900/1-UTF-8.txt3
-rw-r--r--t/t3900/2-UTF-8.txt4
-rw-r--r--t/t3900/EUCJP.txt4
-rw-r--r--t/t3900/ISO-2022-JP.txt4
-rw-r--r--t/t3900/ISO-8859-1.txt3
-rwxr-xr-xt/t3901-8859-1.txt4
-rwxr-xr-xt/t3901-i18n-patch.sh255
-rwxr-xr-xt/t3901-utf8.txt4
-rwxr-xr-xt/t3902-quoted.sh139
-rwxr-xr-xt/t3903-stash.sh76
-rwxr-xr-xt/t4000-diff-format.sh62
-rwxr-xr-xt/t4001-diff-rename.sh80
-rwxr-xr-xt/t4002-diff-basic.sh247
-rwxr-xr-xt/t4003-diff-rename-1.sh128
-rwxr-xr-xt/t4004-diff-rename-symlink.sh67
-rwxr-xr-xt/t4005-diff-rename-2.sh86
-rwxr-xr-xt/t4006-diff-mode.sh43
-rwxr-xr-xt/t4007-rename-3.sh90
-rwxr-xr-xt/t4008-diff-break-rewrite.sh188
-rwxr-xr-xt/t4009-diff-rename-4.sh95
-rwxr-xr-xt/t4010-diff-pathspec.sh65
-rwxr-xr-xt/t4011-diff-symlink.sh85
-rwxr-xr-xt/t4012-diff-binary.sh80
-rwxr-xr-xt/t4013-diff-various.sh261
-rw-r--r--t/t4013/diff.config_format.subjectprefix_DIFFERENT_PREFIX2
-rw-r--r--t/t4013/diff.diff-tree_--cc_--patch-with-stat_--summary_master34
-rw-r--r--t/t4013/diff.diff-tree_--cc_--patch-with-stat_--summary_side39
-rw-r--r--t/t4013/diff.diff-tree_--cc_--patch-with-stat_master34
-rw-r--r--t/t4013/diff.diff-tree_--cc_--stat_--summary_master6
-rw-r--r--t/t4013/diff.diff-tree_--cc_--stat_--summary_side8
-rw-r--r--t/t4013/diff.diff-tree_--cc_--stat_master6
-rw-r--r--t/t4013/diff.diff-tree_--cc_master30
-rw-r--r--t/t4013/diff.diff-tree_--patch-with-raw_initial2
-rw-r--r--t/t4013/diff.diff-tree_--patch-with-stat_initial2
-rw-r--r--t/t4013/diff.diff-tree_--pretty=oneline_--patch-with-raw_initial2
-rw-r--r--t/t4013/diff.diff-tree_--pretty=oneline_--patch-with-stat_initial2
-rw-r--r--t/t4013/diff.diff-tree_--pretty=oneline_--root_--patch-with-raw_initial33
-rw-r--r--t/t4013/diff.diff-tree_--pretty=oneline_--root_--patch-with-stat_initial34
-rw-r--r--t/t4013/diff.diff-tree_--pretty=oneline_--root_-p_initial29
-rw-r--r--t/t4013/diff.diff-tree_--pretty=oneline_--root_initial6
-rw-r--r--t/t4013/diff.diff-tree_--pretty=oneline_-p_initial2
-rw-r--r--t/t4013/diff.diff-tree_--pretty=oneline_initial2
-rw-r--r--t/t4013/diff.diff-tree_--pretty_--patch-with-raw_initial2
-rw-r--r--t/t4013/diff.diff-tree_--pretty_--patch-with-stat_initial2
-rw-r--r--t/t4013/diff.diff-tree_--pretty_--patch-with-stat_side43
-rw-r--r--t/t4013/diff.diff-tree_--pretty_--root_--patch-with-raw_initial38
-rw-r--r--t/t4013/diff.diff-tree_--pretty_--root_--patch-with-stat_initial39
-rw-r--r--t/t4013/diff.diff-tree_--pretty_--root_--stat_--summary_initial15
-rw-r--r--t/t4013/diff.diff-tree_--pretty_--root_--stat_initial12
-rw-r--r--t/t4013/diff.diff-tree_--pretty_--root_--summary_-r_initial11
-rw-r--r--t/t4013/diff.diff-tree_--pretty_--root_--summary_initial11
-rw-r--r--t/t4013/diff.diff-tree_--pretty_--root_-p_initial34
-rw-r--r--t/t4013/diff.diff-tree_--pretty_--root_initial11
-rw-r--r--t/t4013/diff.diff-tree_--pretty_--stat_--summary_initial2
-rw-r--r--t/t4013/diff.diff-tree_--pretty_--stat_initial2
-rw-r--r--t/t4013/diff.diff-tree_--pretty_--summary_initial2
-rw-r--r--t/t4013/diff.diff-tree_--pretty_-p_initial2
-rw-r--r--t/t4013/diff.diff-tree_--pretty_-p_side38
-rw-r--r--t/t4013/diff.diff-tree_--pretty_initial2
-rw-r--r--t/t4013/diff.diff-tree_--pretty_side11
-rw-r--r--t/t4013/diff.diff-tree_--root_--abbrev_initial6
-rw-r--r--t/t4013/diff.diff-tree_--root_--patch-with-raw_initial33
-rw-r--r--t/t4013/diff.diff-tree_--root_--patch-with-stat_initial34
-rw-r--r--t/t4013/diff.diff-tree_--root_-p_initial29
-rw-r--r--t/t4013/diff.diff-tree_--root_-r_--abbrev=4_initial6
-rw-r--r--t/t4013/diff.diff-tree_--root_-r_--abbrev_initial6
-rw-r--r--t/t4013/diff.diff-tree_--root_-r_initial6
-rw-r--r--t/t4013/diff.diff-tree_--root_initial6
-rw-r--r--t/t4013/diff.diff-tree_-c_--abbrev_master5
-rw-r--r--t/t4013/diff.diff-tree_-c_--stat_--summary_master6
-rw-r--r--t/t4013/diff.diff-tree_-c_--stat_--summary_side8
-rw-r--r--t/t4013/diff.diff-tree_-c_--stat_master6
-rw-r--r--t/t4013/diff.diff-tree_-c_master5
-rw-r--r--t/t4013/diff.diff-tree_-p_-m_master80
-rw-r--r--t/t4013/diff.diff-tree_-p_initial2
-rw-r--r--t/t4013/diff.diff-tree_-p_master2
-rw-r--r--t/t4013/diff.diff-tree_-r_--abbrev=4_initial2
-rw-r--r--t/t4013/diff.diff-tree_-r_--abbrev_initial2
-rw-r--r--t/t4013/diff.diff-tree_-r_initial2
-rw-r--r--t/t4013/diff.diff-tree_initial2
-rw-r--r--t/t4013/diff.diff-tree_master2
-rw-r--r--t/t4013/diff.diff_--abbrev_initial..side32
-rw-r--r--t/t4013/diff.diff_--name-status_dir2_dir3
-rw-r--r--t/t4013/diff.diff_--patch-with-raw_-r_initial..side36
-rw-r--r--t/t4013/diff.diff_--patch-with-raw_initial..side36
-rw-r--r--t/t4013/diff.diff_--patch-with-stat_-r_initial..side37
-rw-r--r--t/t4013/diff.diff_--patch-with-stat_initial..side37
-rw-r--r--t/t4013/diff.diff_--stat_initial..side6
-rw-r--r--t/t4013/diff.diff_-r_--stat_initial..side6
-rw-r--r--t/t4013/diff.diff_-r_initial..side32
-rw-r--r--t/t4013/diff.diff_initial..side32
-rw-r--r--t/t4013/diff.format-patch_--attach_--stdout_initial..master164
-rw-r--r--t/t4013/diff.format-patch_--attach_--stdout_initial..master^106
-rw-r--r--t/t4013/diff.format-patch_--attach_--stdout_initial..side59
-rw-r--r--t/t4013/diff.format-patch_--inline_--stdout_--subject-prefix=TESTCASE_initial..master164
-rw-r--r--t/t4013/diff.format-patch_--inline_--stdout_initial..master164
-rw-r--r--t/t4013/diff.format-patch_--inline_--stdout_initial..master^106
-rw-r--r--t/t4013/diff.format-patch_--inline_--stdout_initial..master^^60
-rw-r--r--t/t4013/diff.format-patch_--inline_--stdout_initial..side59
-rw-r--r--t/t4013/diff.format-patch_--stdout_initial..master127
-rw-r--r--t/t4013/diff.format-patch_--stdout_initial..master^81
-rw-r--r--t/t4013/diff.format-patch_--stdout_initial..side47
-rw-r--r--t/t4013/diff.log_--patch-with-stat_--summary_master_--_dir_74
-rw-r--r--t/t4013/diff.log_--patch-with-stat_master129
-rw-r--r--t/t4013/diff.log_--patch-with-stat_master_--_dir_74
-rw-r--r--t/t4013/diff.log_--root_--cc_--patch-with-stat_--summary_master199
-rw-r--r--t/t4013/diff.log_--root_--patch-with-stat_--summary_master167
-rw-r--r--t/t4013/diff.log_--root_--patch-with-stat_master161
-rw-r--r--t/t4013/diff.log_--root_-c_--patch-with-stat_--summary_master199
-rw-r--r--t/t4013/diff.log_--root_-p_master142
-rw-r--r--t/t4013/diff.log_--root_master34
-rw-r--r--t/t4013/diff.log_-SF_-p_master18
-rw-r--r--t/t4013/diff.log_-SF_master7
-rw-r--r--t/t4013/diff.log_-p_master115
-rw-r--r--t/t4013/diff.log_master34
-rw-r--r--t/t4013/diff.show_--patch-with-raw_side42
-rw-r--r--t/t4013/diff.show_--patch-with-stat_--summary_side44
-rw-r--r--t/t4013/diff.show_--patch-with-stat_side43
-rw-r--r--t/t4013/diff.show_--root_initial34
-rw-r--r--t/t4013/diff.show_--stat_--summary_side13
-rw-r--r--t/t4013/diff.show_--stat_side12
-rw-r--r--t/t4013/diff.show_initial7
-rw-r--r--t/t4013/diff.show_master36
-rw-r--r--t/t4013/diff.show_side38
-rw-r--r--t/t4013/diff.whatchanged_--patch-with-stat_--summary_master_--_dir_61
-rw-r--r--t/t4013/diff.whatchanged_--patch-with-stat_master116
-rw-r--r--t/t4013/diff.whatchanged_--patch-with-stat_master_--_dir_61
-rw-r--r--t/t4013/diff.whatchanged_--root_--cc_--patch-with-stat_--summary_master199
-rw-r--r--t/t4013/diff.whatchanged_--root_--patch-with-stat_--summary_master160
-rw-r--r--t/t4013/diff.whatchanged_--root_--patch-with-stat_master154
-rw-r--r--t/t4013/diff.whatchanged_--root_-c_--patch-with-stat_--summary_master199
-rw-r--r--t/t4013/diff.whatchanged_--root_-p_master135
-rw-r--r--t/t4013/diff.whatchanged_--root_master42
-rw-r--r--t/t4013/diff.whatchanged_-SF_-p_master18
-rw-r--r--t/t4013/diff.whatchanged_-SF_master9
-rw-r--r--t/t4013/diff.whatchanged_-p_master102
-rw-r--r--t/t4013/diff.whatchanged_master32
-rwxr-xr-xt/t4014-format-patch.sh91
-rwxr-xr-xt/t4015-diff-whitespace.sh338
-rwxr-xr-xt/t4016-diff-quote.sh70
-rwxr-xr-xt/t4017-diff-retval.sh108
-rwxr-xr-xt/t4017-quiet.sh80
-rwxr-xr-xt/t4018-diff-funcname.sh60
-rwxr-xr-xt/t4019-diff-wserror.sh123
-rwxr-xr-xt/t4020-diff-external.sh109
-rwxr-xr-xt/t4021-format-patch-numbered.sh106
-rwxr-xr-xt/t4021-format-patch-signer-mime.sh42
-rwxr-xr-xt/t4022-diff-rewrite.sh26
-rwxr-xr-xt/t4023-diff-rename-typechange.sh86
-rwxr-xr-xt/t4024-diff-optimize-common.sh157
-rwxr-xr-xt/t4025-hunk-header.sh44
-rwxr-xr-xt/t4026-color.sh69
-rwxr-xr-xt/t4100-apply-stat.sh46
-rw-r--r--t/t4100/t-apply-1.expect11
-rw-r--r--t/t4100/t-apply-1.patch194
-rw-r--r--t/t4100/t-apply-2.expect5
-rw-r--r--t/t4100/t-apply-2.patch72
-rw-r--r--t/t4100/t-apply-3.expect7
-rw-r--r--t/t4100/t-apply-3.patch567
-rw-r--r--t/t4100/t-apply-4.expect5
-rw-r--r--t/t4100/t-apply-4.patch7
-rw-r--r--t/t4100/t-apply-5.expect19
-rw-r--r--t/t4100/t-apply-5.patch612
-rw-r--r--t/t4100/t-apply-6.expect5
-rw-r--r--t/t4100/t-apply-6.patch101
-rw-r--r--t/t4100/t-apply-7.expect6
-rw-r--r--t/t4100/t-apply-7.patch494
-rwxr-xr-xt/t4101-apply-nonl.sh30
-rw-r--r--t/t4101/diff.0-16
-rw-r--r--t/t4101/diff.0-27
-rw-r--r--t/t4101/diff.0-38
-rw-r--r--t/t4101/diff.1-06
-rw-r--r--t/t4101/diff.1-28
-rw-r--r--t/t4101/diff.1-38
-rw-r--r--t/t4101/diff.2-07
-rw-r--r--t/t4101/diff.2-18
-rw-r--r--t/t4101/diff.2-37
-rw-r--r--t/t4101/diff.3-08
-rw-r--r--t/t4101/diff.3-18
-rw-r--r--t/t4101/diff.3-27
-rwxr-xr-xt/t4102-apply-rename.sh62
-rwxr-xr-xt/t4103-apply-binary.sh115
-rwxr-xr-xt/t4104-apply-boundary.sh115
-rwxr-xr-xt/t4109-apply-multifrag.sh176
-rwxr-xr-xt/t4110-apply-scan.sh100
-rwxr-xr-xt/t4112-apply-renames.sh124
-rwxr-xr-xt/t4113-apply-ending.sh53
-rwxr-xr-xt/t4114-apply-typechange.sh105
-rwxr-xr-xt/t4115-apply-symlink.sh49
-rwxr-xr-xt/t4116-apply-reverse.sh91
-rwxr-xr-xt/t4117-apply-reject.sh157
-rwxr-xr-xt/t4118-apply-empty-context.sh55
-rwxr-xr-xt/t4119-apply-config.sh162
-rwxr-xr-xt/t4120-apply-popt.sh25
-rwxr-xr-xt/t4121-apply-diffs.sh32
-rwxr-xr-xt/t4122-apply-symlink-inside.sh55
-rwxr-xr-xt/t4123-apply-shrink.sh58
-rwxr-xr-xt/t4124-apply-ws-rule.sh151
-rwxr-xr-xt/t4200-rerere.sh201
-rwxr-xr-xt/t4201-shortlog.sh50
-rwxr-xr-xt/t4202-log.sh74
-rwxr-xr-xt/t5000-tar-tree.sh174
-rwxr-xr-xt/t5100-mailinfo.sh28
-rw-r--r--t/t5100/info00015
-rw-r--r--t/t5100/info00025
-rw-r--r--t/t5100/info00035
-rw-r--r--t/t5100/info00045
-rw-r--r--t/t5100/info00055
-rw-r--r--t/t5100/info00065
-rw-r--r--t/t5100/info00075
-rw-r--r--t/t5100/info00085
-rw-r--r--t/t5100/info00095
-rw-r--r--t/t5100/msg00012
-rw-r--r--t/t5100/msg000221
-rw-r--r--t/t5100/msg00039
-rw-r--r--t/t5100/msg00047
-rw-r--r--t/t5100/msg000513
-rw-r--r--t/t5100/msg00062
-rw-r--r--t/t5100/msg00072
-rw-r--r--t/t5100/msg00084
-rw-r--r--t/t5100/msg00092
-rw-r--r--t/t5100/patch000114
-rw-r--r--t/t5100/patch000214
-rw-r--r--t/t5100/patch000314
-rw-r--r--t/t5100/patch000493
-rw-r--r--t/t5100/patch000569
-rw-r--r--t/t5100/patch000614
-rw-r--r--t/t5100/patch00070
-rw-r--r--t/t5100/patch00080
-rw-r--r--t/t5100/patch000913
-rw-r--r--t/t5100/sample.mbox432
-rwxr-xr-xt/t5300-pack-object.sh271
-rwxr-xr-xt/t5301-sliding-window.sh60
-rwxr-xr-xt/t5302-pack-index.sh165
-rw-r--r--t/t5304-prune.sh32
-rwxr-xr-xt/t5400-send-pack.sh174
-rwxr-xr-xt/t5401-update-hooks.sh136
-rwxr-xr-xt/t5402-post-merge-hook.sh56
-rwxr-xr-xt/t5403-post-checkout-hook.sh74
-rwxr-xr-xt/t5404-tracking-branches.sh53
-rwxr-xr-xt/t5405-send-pack-rewind.sh42
-rwxr-xr-xt/t5406-remote-rejects.sh24
-rwxr-xr-xt/t5500-fetch-pack.sh182
-rwxr-xr-xt/t5502-quickfetch.sh122
-rwxr-xr-xt/t5505-remote.sh97
-rwxr-xr-xt/t5510-fetch.sh298
-rwxr-xr-xt/t5512-ls-remote.sh52
-rwxr-xr-xt/t5515-fetch-merge-logic.sh161
-rw-r--r--t/t5515/fetch.br-branches-default8
-rw-r--r--t/t5515/fetch.br-branches-default-merge9
-rw-r--r--t/t5515/fetch.br-branches-default-merge_branches-default9
-rw-r--r--t/t5515/fetch.br-branches-default-octopus10
-rw-r--r--t/t5515/fetch.br-branches-default-octopus_branches-default10
-rw-r--r--t/t5515/fetch.br-branches-default_branches-default8
-rw-r--r--t/t5515/fetch.br-branches-one8
-rw-r--r--t/t5515/fetch.br-branches-one-merge9
-rw-r--r--t/t5515/fetch.br-branches-one-merge_branches-one9
-rw-r--r--t/t5515/fetch.br-branches-one-octopus9
-rw-r--r--t/t5515/fetch.br-branches-one-octopus_branches-one9
-rw-r--r--t/t5515/fetch.br-branches-one_branches-one8
-rw-r--r--t/t5515/fetch.br-config-explicit11
-rw-r--r--t/t5515/fetch.br-config-explicit-merge11
-rw-r--r--t/t5515/fetch.br-config-explicit-merge_config-explicit11
-rw-r--r--t/t5515/fetch.br-config-explicit-octopus11
-rw-r--r--t/t5515/fetch.br-config-explicit-octopus_config-explicit11
-rw-r--r--t/t5515/fetch.br-config-explicit_config-explicit11
-rw-r--r--t/t5515/fetch.br-config-glob11
-rw-r--r--t/t5515/fetch.br-config-glob-merge11
-rw-r--r--t/t5515/fetch.br-config-glob-merge_config-glob11
-rw-r--r--t/t5515/fetch.br-config-glob-octopus11
-rw-r--r--t/t5515/fetch.br-config-glob-octopus_config-glob11
-rw-r--r--t/t5515/fetch.br-config-glob_config-glob11
-rw-r--r--t/t5515/fetch.br-remote-explicit11
-rw-r--r--t/t5515/fetch.br-remote-explicit-merge11
-rw-r--r--t/t5515/fetch.br-remote-explicit-merge_remote-explicit11
-rw-r--r--t/t5515/fetch.br-remote-explicit-octopus11
-rw-r--r--t/t5515/fetch.br-remote-explicit-octopus_remote-explicit11
-rw-r--r--t/t5515/fetch.br-remote-explicit_remote-explicit11
-rw-r--r--t/t5515/fetch.br-remote-glob11
-rw-r--r--t/t5515/fetch.br-remote-glob-merge11
-rw-r--r--t/t5515/fetch.br-remote-glob-merge_remote-glob11
-rw-r--r--t/t5515/fetch.br-remote-glob-octopus11
-rw-r--r--t/t5515/fetch.br-remote-glob-octopus_remote-glob11
-rw-r--r--t/t5515/fetch.br-remote-glob_remote-glob11
-rw-r--r--t/t5515/fetch.br-unconfig11
-rw-r--r--t/t5515/fetch.br-unconfig_--tags_.._.git7
-rw-r--r--t/t5515/fetch.br-unconfig_.._.git2
-rw-r--r--t/t5515/fetch.br-unconfig_.._.git_one2
-rw-r--r--t/t5515/fetch.br-unconfig_.._.git_one_tag_tag-one_tag_tag-three-file8
-rw-r--r--t/t5515/fetch.br-unconfig_.._.git_one_two3
-rw-r--r--t/t5515/fetch.br-unconfig_.._.git_tag_tag-one-tree_tag_tag-three-file7
-rw-r--r--t/t5515/fetch.br-unconfig_.._.git_tag_tag-one_tag_tag-three7
-rw-r--r--t/t5515/fetch.br-unconfig_branches-default8
-rw-r--r--t/t5515/fetch.br-unconfig_branches-one8
-rw-r--r--t/t5515/fetch.br-unconfig_config-explicit11
-rw-r--r--t/t5515/fetch.br-unconfig_config-glob11
-rw-r--r--t/t5515/fetch.br-unconfig_remote-explicit11
-rw-r--r--t/t5515/fetch.br-unconfig_remote-glob11
-rw-r--r--t/t5515/fetch.master11
-rw-r--r--t/t5515/fetch.master_--tags_.._.git7
-rw-r--r--t/t5515/fetch.master_.._.git2
-rw-r--r--t/t5515/fetch.master_.._.git_one2
-rw-r--r--t/t5515/fetch.master_.._.git_one_tag_tag-one_tag_tag-three-file8
-rw-r--r--t/t5515/fetch.master_.._.git_one_two3
-rw-r--r--t/t5515/fetch.master_.._.git_tag_tag-one-tree_tag_tag-three-file7
-rw-r--r--t/t5515/fetch.master_.._.git_tag_tag-one_tag_tag-three7
-rw-r--r--t/t5515/fetch.master_branches-default8
-rw-r--r--t/t5515/fetch.master_branches-one8
-rw-r--r--t/t5515/fetch.master_config-explicit11
-rw-r--r--t/t5515/fetch.master_config-glob11
-rw-r--r--t/t5515/fetch.master_remote-explicit11
-rw-r--r--t/t5515/fetch.master_remote-glob11
-rwxr-xr-xt/t5516-fetch-push.sh323
-rwxr-xr-xt/t5517-push-mirror.sh228
-rwxr-xr-xt/t5520-pull.sh95
-rwxr-xr-xt/t5530-upload-pack-error.sh75
-rwxr-xr-xt/t5600-clone-fail-cleanup.sh42
-rwxr-xr-xt/t5700-clone-reference.sh116
-rwxr-xr-xt/t5701-clone-local.sh74
-rwxr-xr-xt/t5702-clone-options.sh22
-rwxr-xr-xt/t5710-info-alternate.sh110
-rwxr-xr-xt/t6000lib.sh116
-rwxr-xr-xt/t6001-rev-list-graft.sh113
-rwxr-xr-xt/t6002-rev-list-bisect.sh238
-rwxr-xr-xt/t6003-rev-list-topo-order.sh408
-rwxr-xr-xt/t6004-rev-list-path-optim.sh51
-rwxr-xr-xt/t6005-rev-list-count.sh51
-rwxr-xr-xt/t6006-rev-list-format.sh152
-rwxr-xr-xt/t6007-rev-list-cherry-pick-file.sh57
-rwxr-xr-xt/t6008-rev-list-submodule.sh42
-rwxr-xr-xt/t6010-merge-base.sh110
-rwxr-xr-xt/t6020-merge-df.sh25
-rwxr-xr-xt/t6021-merge-criss-cross.sh92
-rwxr-xr-xt/t6022-merge-rename.sh344
-rwxr-xr-xt/t6023-merge-file.sh142
-rwxr-xr-xt/t6023-merge-rename-nocruft.sh139
-rwxr-xr-xt/t6024-recursive-merge.sh98
-rwxr-xr-xt/t6025-merge-symlinks.sh62
-rwxr-xr-xt/t6026-merge-attr.sh145
-rwxr-xr-xt/t6027-merge-binary.sh67
-rwxr-xr-xt/t6028-merge-up-to-date.sh77
-rwxr-xr-xt/t6030-bisect-porcelain.sh271
-rwxr-xr-xt/t6101-rev-parse-parents.sh42
-rwxr-xr-xt/t6120-describe.sh97
-rwxr-xr-xt/t6200-fmt-merge-msg.sh163
-rwxr-xr-xt/t6300-for-each-ref.sh212
-rwxr-xr-xt/t7001-mv.sh121
-rwxr-xr-xt/t7002-grep.sh116
-rwxr-xr-xt/t7003-filter-branch.sh182
-rwxr-xr-xt/t7004-tag.sh1068
-rw-r--r--t/t7004/pubring.gpgbin0 -> 1164 bytes
-rw-r--r--t/t7004/random_seedbin0 -> 600 bytes
-rw-r--r--t/t7004/secring.gpgbin0 -> 1237 bytes
-rw-r--r--t/t7004/trustdb.gpgbin0 -> 1280 bytes
-rwxr-xr-xt/t7005-editor.sh94
-rwxr-xr-xt/t7101-reset.sh63
-rwxr-xr-xt/t7102-reset.sh431
-rwxr-xr-xt/t7103-reset-bare.sh28
-rwxr-xr-xt/t7201-co.sh273
-rwxr-xr-xt/t7300-clean.sh319
-rwxr-xr-xt/t7400-submodule-basic.sh199
-rwxr-xr-xt/t7500-commit.sh141
-rwxr-xr-xt/t7500/add-comments4
-rwxr-xr-xt/t7500/add-content3
-rwxr-xr-xt/t7500/add-signed-off3
-rwxr-xr-xt/t7501-commit.sh348
-rwxr-xr-xt/t7502-commit.sh157
-rwxr-xr-xt/t7502-status.sh152
-rwxr-xr-xt/t7503-pre-commit-hook.sh88
-rwxr-xr-xt/t7504-commit-msg-hook.sh220
-rwxr-xr-xt/t7600-merge.sh446
-rwxr-xr-xt/t8001-annotate.sh15
-rwxr-xr-xt/t8002-blame.sh9
-rwxr-xr-xt/t8003-blame.sh132
-rwxr-xr-xt/t8004-blame.sh73
-rwxr-xr-xt/t9001-send-email.sh132
-rwxr-xr-xt/t9100-git-svn-basic.sh268
-rwxr-xr-xt/t9101-git-svn-props.sh217
-rwxr-xr-xt/t9102-git-svn-deep-rmdir.sh30
-rwxr-xr-xt/t9103-git-svn-tracked-directory-removed.sh39
-rwxr-xr-xt/t9104-git-svn-follow-parent.sh171
-rwxr-xr-xt/t9105-git-svn-commit-diff.sh43
-rwxr-xr-xt/t9106-git-svn-commit-diff-clobber.sh99
-rwxr-xr-xt/t9106-git-svn-dcommit-clobber-series.sh63
-rwxr-xr-xt/t9107-git-svn-migrate.sh115
-rwxr-xr-xt/t9108-git-svn-glob.sh86
-rwxr-xr-xt/t9110-git-svn-use-svm-props.sh52
-rw-r--r--t/t9110/svm.dump511
-rwxr-xr-xt/t9111-git-svn-use-svnsync-props.sh51
-rw-r--r--t/t9111/svnsync.dump560
-rwxr-xr-xt/t9112-git-svn-md5less-file.sh45
-rwxr-xr-xt/t9113-git-svn-dcommit-new-file.sh40
-rwxr-xr-xt/t9114-git-svn-dcommit-merge.sh94
-rwxr-xr-xt/t9115-git-svn-dcommit-funky-renames.sh54
-rw-r--r--t/t9115/funky-names.dump103
-rwxr-xr-xt/t9116-git-svn-log.sh128
-rwxr-xr-xt/t9117-git-svn-init-clone.sh55
-rwxr-xr-xt/t9118-git-svn-funky-branch-names.sh40
-rwxr-xr-xt/t9119-git-svn-info.sh370
-rwxr-xr-xt/t9200-git-cvsexportcommit.sh265
-rwxr-xr-xt/t9300-fast-import.sh919
-rwxr-xr-xt/t9301-fast-export.sh123
-rwxr-xr-xt/t9400-git-cvsserver-server.sh417
-rwxr-xr-xt/t9500-gitweb-standalone-no-errors.sh608
-rwxr-xr-xt/t9600-cvsimport.sh150
-rw-r--r--t/test-lib.sh357
-rw-r--r--t/test4012.pngbin0 -> 5660 bytes
-rw-r--r--t/test9200a.pngbin0 -> 5660 bytes
-rw-r--r--t/test9200b.pngbin0 -> 275 bytes
-rw-r--r--tag.c117
-rw-r--r--tag.h20
-rw-r--r--tar.h25
-rw-r--r--templates/.gitignore2
-rw-r--r--templates/Makefile51
-rw-r--r--templates/branches--1
-rw-r--r--templates/hooks--applypatch-msg15
-rw-r--r--templates/hooks--commit-msg21
-rw-r--r--templates/hooks--post-commit8
-rw-r--r--templates/hooks--post-receive16
-rw-r--r--templates/hooks--post-update8
-rw-r--r--templates/hooks--pre-applypatch14
-rw-r--r--templates/hooks--pre-commit70
-rw-r--r--templates/hooks--pre-rebase150
-rw-r--r--templates/hooks--update107
-rw-r--r--templates/info--exclude6
-rw-r--r--templates/this--description1
-rw-r--r--test-absolute-path.c11
-rw-r--r--test-chmtime.c61
-rw-r--r--test-date.c20
-rw-r--r--test-delta.c78
-rw-r--r--test-genrandom.c34
-rw-r--r--test-match-trees.c24
-rw-r--r--test-parse-options.c37
-rw-r--r--test-sha1.c47
-rwxr-xr-xtest-sha1.sh83
-rw-r--r--trace.c127
-rw-r--r--transport.c793
-rw-r--r--transport.h72
-rw-r--r--tree-diff.c445
-rw-r--r--tree-walk.c214
-rw-r--r--tree-walk.h42
-rw-r--r--tree.c301
-rw-r--r--tree.h33
-rw-r--r--unpack-file.c38
-rw-r--r--unpack-trees.c928
-rw-r--r--unpack-trees.h38
-rw-r--r--update-server-info.c25
-rw-r--r--upload-pack.c634
-rw-r--r--usage.c96
-rw-r--r--utf8.c391
-rw-r--r--utf8.h19
-rw-r--r--var.c74
-rw-r--r--walker.c317
-rw-r--r--walker.h37
-rw-r--r--write_or_die.c112
-rw-r--r--ws.c203
-rw-r--r--wt-status.c415
-rw-r--r--wt-status.h36
-rw-r--r--xdiff-interface.c240
-rw-r--r--xdiff-interface.h26
-rw-r--r--xdiff/xdiff.h109
-rw-r--r--xdiff/xdiffi.c565
-rw-r--r--xdiff/xdiffi.h59
-rw-r--r--xdiff/xemit.c205
-rw-r--r--xdiff/xemit.h33
-rw-r--r--xdiff/xinclude.h42
-rw-r--r--xdiff/xmacros.h53
-rw-r--r--xdiff/xmerge.c426
-rw-r--r--xdiff/xprepare.c468
-rw-r--r--xdiff/xprepare.h34
-rw-r--r--xdiff/xtypes.h67
-rw-r--r--xdiff/xutils.c380
-rw-r--r--xdiff/xutils.h47
1207 files changed, 224422 insertions, 343 deletions
diff --git a/.gitignore b/.gitignore
index 6483b21..7f8421d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,8 +1,171 @@
-.DS_Store
-config.mak
-Git Gui.app*
-git-gui.tcl
-GIT-VERSION-FILE
+GIT-CFLAGS
GIT-GUI-VARS
-git-gui
-lib/tclIndex
+GIT-VERSION-FILE
+git
+git-add
+git-add--interactive
+git-am
+git-annotate
+git-apply
+git-archimport
+git-archive
+git-bisect
+git-blame
+git-branch
+git-bundle
+git-cat-file
+git-check-attr
+git-check-ref-format
+git-checkout
+git-checkout-index
+git-cherry
+git-cherry-pick
+git-clean
+git-clone
+git-commit
+git-commit-tree
+git-config
+git-count-objects
+git-cvsexportcommit
+git-cvsimport
+git-cvsserver
+git-daemon
+git-diff
+git-diff-files
+git-diff-index
+git-diff-tree
+git-describe
+git-fast-export
+git-fast-import
+git-fetch
+git-fetch--tool
+git-fetch-pack
+git-filter-branch
+git-fmt-merge-msg
+git-for-each-ref
+git-format-patch
+git-fsck
+git-fsck-objects
+git-gc
+git-get-tar-commit-id
+git-grep
+git-hash-object
+git-help--browse
+git-http-fetch
+git-http-push
+git-imap-send
+git-index-pack
+git-init
+git-init-db
+git-instaweb
+git-log
+git-lost-found
+git-ls-files
+git-ls-remote
+git-ls-tree
+git-mailinfo
+git-mailsplit
+git-merge
+git-merge-base
+git-merge-index
+git-merge-file
+git-merge-tree
+git-merge-octopus
+git-merge-one-file
+git-merge-ours
+git-merge-recursive
+git-merge-resolve
+git-merge-stupid
+git-merge-subtree
+git-mergetool
+git-mktag
+git-mktree
+git-name-rev
+git-mv
+git-pack-redundant
+git-pack-objects
+git-pack-refs
+git-parse-remote
+git-patch-id
+git-peek-remote
+git-prune
+git-prune-packed
+git-pull
+git-push
+git-quiltimport
+git-read-tree
+git-rebase
+git-rebase--interactive
+git-receive-pack
+git-reflog
+git-relink
+git-remote
+git-repack
+git-repo-config
+git-request-pull
+git-rerere
+git-reset
+git-rev-list
+git-rev-parse
+git-revert
+git-rm
+git-send-email
+git-send-pack
+git-sh-setup
+git-shell
+git-shortlog
+git-show
+git-show-branch
+git-show-index
+git-show-ref
+git-stash
+git-status
+git-stripspace
+git-submodule
+git-svn
+git-symbolic-ref
+git-tag
+git-tar-tree
+git-unpack-file
+git-unpack-objects
+git-update-index
+git-update-ref
+git-update-server-info
+git-upload-archive
+git-upload-pack
+git-var
+git-verify-pack
+git-verify-tag
+git-whatchanged
+git-write-tree
+git-core-*/?*
+gitk-wish
+gitweb/gitweb.cgi
+test-absolute-path
+test-chmtime
+test-date
+test-delta
+test-dump-cache-tree
+test-genrandom
+test-match-trees
+test-parse-options
+test-sha1
+common-cmds.h
+*.tar.gz
+*.dsc
+*.deb
+git.spec
+*.exe
+*.[aos]
+*.py[co]
+config.mak
+autom4te.cache
+config.cache
+config.log
+config.status
+config.mak.autogen
+config.mak.append
+configure
+tags
+TAGS
+cscope*
diff --git a/.mailmap b/.mailmap
new file mode 100644
index 0000000..a32d9e2
--- /dev/null
+++ b/.mailmap
@@ -0,0 +1,54 @@
+#
+# This list is used by git-shortlog to fix a few botched name translations
+# in the git archive, either because the author's full name was messed up
+# and/or not always written the same way, making contributions from the
+# same person appearing not to be so.
+#
+
+Aneesh Kumar K.V <aneesh.kumar@gmail.com>
+Brian M. Carlson <sandals@crustytoothpaste.ath.cx>
+Chris Shoemaker <c.shoemaker@cox.net>
+Dana L. How <danahow@gmail.com>
+Dana L. How <how@deathvalley.cswitch.com>
+Daniel Barkalow <barkalow@iabervon.org>
+David Kågedal <davidk@lysator.liu.se>
+Fredrik Kuivinen <freku045@student.liu.se>
+H. Peter Anvin <hpa@bonde.sc.orionmulti.com>
+H. Peter Anvin <hpa@tazenda.sc.orionmulti.com>
+H. Peter Anvin <hpa@trantor.hos.anvin.org>
+Horst H. von Brand <vonbrand@inf.utfsm.cl>
+Joachim Berdal Haga <cjhaga@fys.uio.no>
+Jon Loeliger <jdl@freescale.com>
+Jon Seymour <jon@blackcubes.dyndns.org>
+Junio C Hamano <junio@twinsun.com>
+Karl Hasselström <kha@treskal.com>
+Kent Engstrom <kent@lysator.liu.se>
+Lars Doelle <lars.doelle@on-line ! de>
+Lars Doelle <lars.doelle@on-line.de>
+Li Hong <leehong@pku.edu.cn>
+Lukas Sandström <lukass@etek.chalmers.se>
+Martin Langhoff <martin@catalyst.net.nz>
+Michael Coleman <tutufan@gmail.com>
+Michele Ballabio <barra_cuda@katamail.com>
+Nanako Shiraishi <nanako3@bluebottle.com>
+Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
+Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
+René Scharfe <rene.scharfe@lsrfire.ath.cx>
+Robert Fitzsimons <robfitz@273k.net>
+Sam Vilain <sam@vilain.net>
+Santi Béjar <sbejar@gmail.com>
+Sean Estabrooks <seanlkml@sympatico.ca>
+Shawn O. Pearce <spearce@spearce.org>
+Steven Grimm <koreth@midwinter.com>
+Theodore Ts'o <tytso@mit.edu>
+Tony Luck <tony.luck@intel.com>
+Uwe Kleine-König <Uwe_Zeisberger@digi.com>
+Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
+Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
+Uwe Kleine-König <uzeisberger@io.fsforth.de>
+Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
+Ville Skyttä <scop@xemacs.org>
+William Pursell <bill.pursell@gmail.com>
+YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
+anonymous <linux@horizon.com>
+anonymous <linux@horizon.net>
diff --git a/COPYING b/COPYING
new file mode 100644
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.
+
+ 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.)
+
+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.
+
+ 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.
+
+ 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
+
+ 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
index 0000000..2f938f4
--- /dev/null
+++ b/Documentation/.gitignore
@@ -0,0 +1,8 @@
+*.xml
+*.html
+*.[1-8]
+*.made
+git.info
+howto-index.txt
+doc.dep
+cmds-*.txt
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
new file mode 100644
index 0000000..3b042db
--- /dev/null
+++ b/Documentation/CodingGuidelines
@@ -0,0 +1,112 @@
+Like other projects, we also have some guidelines to keep to the
+code. For git in general, three rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+ ignore your needs should your system not conform to it."
+ We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+ it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+ this is not in POSIX, it (is so convenient | makes the code
+ much more readable | has other good characteristics) and
+ practically all the platforms we care about support it, so
+ let's use it".
+
+ Again, we live in the real world, and it is sometimes a
+ judgement call, the decision based more on real world
+ constraints people face than what the paper standard says.
+
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). But if you must have a list of rules,
+here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+ properly nests. It should have been the way Bourne spelled
+ it from day one, but unfortunately isn't.
+
+ - We use ${parameter-word} and its [-=?+] siblings, and their
+ colon'ed "unset or null" form.
+
+ - We use ${parameter#word} and its [#%] siblings, and their
+ doubled "longest matching" form.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - No "Substring Expansion" ${parameter:offset:length}.
+
+ - No shell arrays.
+
+ - No strlen ${#parameter}.
+
+ - No regexp ${parameter/pattern/string}.
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+ functions.
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+ 8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - When declaring pointers, the star sides with the variable
+ name, i.e. "char *string", not "char* string" or
+ "char * string". This makes it easier to understand code
+ like "char *string, c;".
+
+ - We avoid using braces unnecessarily. I.e.
+
+ if (bla) {
+ x = 1;
+ }
+
+ is frowned upon. A gray area is when the statement extends
+ over a few lines, and/or you have a lengthy comment atop of
+ it. Also, like in the Linux kernel, if there is a long list
+ of "else if" statements, it can make sense to add braces to
+ single line blocks.
+
+ - Try to make your code understandable. You may put comments
+ in, but comments invariably tend to stale out when the code
+ they were describing changes. Often splitting a function
+ into two makes the intention of the code much clearer.
+
+ - Double negation is often harder to understand than no negation
+ at all.
+
+ - Some clever tricks, like using the !! operator with arithmetic
+ constructs, can be extremely confusing to others. Avoid them,
+ unless there is a compelling reason to use them.
+
+ - Use the API. No, really. We have a strbuf (variable length
+ string), several arrays with the ALLOC_GROW() macro, a
+ path_list for sorted string lists, a hash map (mapping struct
+ objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document it.
+
+ - The first #include in C files, except in platform specific
+ compat/ implementations, should be git-compat-util.h or another
+ header file that includes it, such as cache.h or builtin.h.
+
+ - If you are planning a new command, consider writing it in shell
+ or perl first, so that changes in semantics can be easily
+ changed and discussed. Many git commands started out like
+ that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into git. This means you
+ usually should stay away from scripting languages not already
+ used in the git core command set (unless your command is clearly
+ separate from it, such as an importer to convert random-scm-X
+ repositories to git).
diff --git a/Documentation/Makefile b/Documentation/Makefile
new file mode 100644
index 0000000..43781fb
--- /dev/null
+++ b/Documentation/Makefile
@@ -0,0 +1,232 @@
+MAN1_TXT= \
+ $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
+ $(wildcard git-*.txt)) \
+ gitk.txt
+MAN5_TXT=gitattributes.txt gitignore.txt gitcli.txt gitmodules.txt
+MAN7_TXT=git.txt
+
+MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
+MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
+MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT))
+
+DOC_HTML=$(MAN_HTML)
+
+ARTICLES = tutorial
+ARTICLES += tutorial-2
+ARTICLES += core-tutorial
+ARTICLES += cvs-migration
+ARTICLES += diffcore
+ARTICLES += howto-index
+ARTICLES += repository-layout
+ARTICLES += hooks
+ARTICLES += everyday
+ARTICLES += git-tools
+ARTICLES += glossary
+# with their own formatting rules.
+SP_ARTICLES = howto/revert-branch-rebase howto/using-merge-subtree user-manual
+API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
+SP_ARTICLES += $(API_DOCS)
+SP_ARTICLES += technical/api-index
+
+DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES))
+
+DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT))
+DOC_MAN5=$(patsubst %.txt,%.5,$(MAN5_TXT))
+DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
+
+prefix?=$(HOME)
+bindir?=$(prefix)/bin
+htmldir?=$(prefix)/share/doc/git-doc
+mandir?=$(prefix)/share/man
+man1dir=$(mandir)/man1
+man5dir=$(mandir)/man5
+man7dir=$(mandir)/man7
+# DESTDIR=
+
+ASCIIDOC=asciidoc
+ASCIIDOC_EXTRA =
+MANPAGE_XSL = callouts.xsl
+INSTALL?=install
+RM ?= rm -f
+DOC_REF = origin/man
+
+infodir?=$(prefix)/share/info
+MAKEINFO=makeinfo
+INSTALL_INFO=install-info
+DOCBOOK2X_TEXI=docbook2x-texi
+ifndef PERL_PATH
+ PERL_PATH = /usr/bin/perl
+endif
+
+-include ../config.mak.autogen
+-include ../config.mak
+
+ifdef ASCIIDOC8
+ASCIIDOC_EXTRA += -a asciidoc7compatible
+endif
+ifdef DOCBOOK_XSL_172
+ASCIIDOC_EXTRA += -a docbook-xsl-172
+MANPAGE_XSL = manpage-1.72.xsl
+endif
+
+#
+# Please note that there is a minor bug in asciidoc.
+# The version after 6.0.3 _will_ include the patch found here:
+# http://marc.theaimsgroup.com/?l=git&m=111558757202243&w=2
+#
+# Until that version is released you may have to apply the patch
+# yourself - yes, all 6 characters of it!
+#
+
+all: html man
+
+html: $(DOC_HTML)
+
+$(DOC_HTML) $(DOC_MAN1) $(DOC_MAN5) $(DOC_MAN7): asciidoc.conf
+
+man: man1 man5 man7
+man1: $(DOC_MAN1)
+man5: $(DOC_MAN5)
+man7: $(DOC_MAN7)
+
+info: git.info gitman.info
+
+install: man
+ $(INSTALL) -d -m 755 $(DESTDIR)$(man1dir)
+ $(INSTALL) -d -m 755 $(DESTDIR)$(man5dir)
+ $(INSTALL) -d -m 755 $(DESTDIR)$(man7dir)
+ $(INSTALL) -m 644 $(DOC_MAN1) $(DESTDIR)$(man1dir)
+ $(INSTALL) -m 644 $(DOC_MAN5) $(DESTDIR)$(man5dir)
+ $(INSTALL) -m 644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
+
+install-info: info
+ $(INSTALL) -d -m 755 $(DESTDIR)$(infodir)
+ $(INSTALL) -m 644 git.info gitman.info $(DESTDIR)$(infodir)
+ if test -r $(DESTDIR)$(infodir)/dir; then \
+ $(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) git.info ;\
+ $(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) gitman.info ;\
+ else \
+ echo "No directory found in $(DESTDIR)$(infodir)" >&2 ; \
+ fi
+
+install-html: html
+ sh ./install-webdoc.sh $(DESTDIR)$(htmldir)
+
+../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
+ $(MAKE) -C ../ GIT-VERSION-FILE
+
+-include ../GIT-VERSION-FILE
+
+#
+# Determine "include::" file references in asciidoc files.
+#
+doc.dep : $(wildcard *.txt) build-docdep.perl
+ $(RM) $@+ $@
+ $(PERL_PATH) ./build-docdep.perl >$@+
+ mv $@+ $@
+
+-include doc.dep
+
+cmds_txt = cmds-ancillaryinterrogators.txt \
+ cmds-ancillarymanipulators.txt \
+ cmds-mainporcelain.txt \
+ cmds-plumbinginterrogators.txt \
+ cmds-plumbingmanipulators.txt \
+ cmds-synchingrepositories.txt \
+ cmds-synchelpers.txt \
+ cmds-purehelpers.txt \
+ cmds-foreignscminterface.txt
+
+$(cmds_txt): cmd-list.made
+
+cmd-list.made: cmd-list.perl ../command-list.txt $(MAN1_TXT)
+ $(RM) $@
+ $(PERL_PATH) ./cmd-list.perl ../command-list.txt
+ date >$@
+
+git.7 git.html: git.txt
+
+clean:
+ $(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7
+ $(RM) *.texi *.texi+ git.info gitman.info
+ $(RM) howto-index.txt howto/*.html doc.dep
+ $(RM) technical/api-*.html technical/api-index.txt
+ $(RM) $(cmds_txt) *.made
+
+$(MAN_HTML): %.html : %.txt
+ $(RM) $@+ $@
+ $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
+ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
+ mv $@+ $@
+
+%.1 %.5 %.7 : %.xml
+ $(RM) $@
+ xmlto -m $(MANPAGE_XSL) man $<
+
+%.xml : %.txt
+ $(RM) $@+ $@
+ $(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \
+ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
+ mv $@+ $@
+
+user-manual.xml: user-manual.txt user-manual.conf
+ $(ASCIIDOC) -b docbook -d book $<
+
+technical/api-index.txt: technical/api-index-skel.txt \
+ technical/api-index.sh $(patsubst %,%.txt,$(API_DOCS))
+ cd technical && sh ./api-index.sh
+
+$(patsubst %,%.html,$(API_DOCS) technical/api-index): %.html : %.txt
+ $(ASCIIDOC) -b xhtml11 -f asciidoc.conf \
+ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt
+
+XSLT = docbook.xsl
+XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css
+
+user-manual.html: user-manual.xml
+ xsltproc $(XSLTOPTS) -o $@ $(XSLT) $<
+
+git.info: user-manual.texi
+ $(MAKEINFO) --no-split -o $@ user-manual.texi
+
+user-manual.texi: user-manual.xml
+ $(RM) $@+ $@
+ $(DOCBOOK2X_TEXI) user-manual.xml --to-stdout | $(PERL_PATH) fix-texi.perl >$@+
+ mv $@+ $@
+
+gitman.texi: $(MAN_XML) cat-texi.perl
+ $(RM) $@+ $@
+ ($(foreach xml,$(MAN_XML),$(DOCBOOK2X_TEXI) --to-stdout $(xml);)) | \
+ $(PERL_PATH) cat-texi.perl $@ >$@+
+ mv $@+ $@
+
+gitman.info: gitman.texi
+ $(MAKEINFO) --no-split $*.texi
+
+$(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml
+ $(RM) $@+ $@
+ $(DOCBOOK2X_TEXI) --to-stdout $*.xml >$@+
+ mv $@+ $@
+
+howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
+ $(RM) $@+ $@
+ sh ./howto-index.sh $(wildcard howto/*.txt) >$@+
+ mv $@+ $@
+
+$(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
+ $(ASCIIDOC) -b xhtml11 $*.txt
+
+WEBDOC_DEST = /pub/software/scm/git/docs
+
+$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
+ $(RM) $@+ $@
+ sed -e '1,/^$$/d' $< | $(ASCIIDOC) -b xhtml11 - >$@+
+ mv $@+ $@
+
+install-webdoc : html
+ sh ./install-webdoc.sh $(WEBDOC_DEST)
+
+quick-install:
+ sh ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir)
+
+.PHONY: .FORCE-GIT-VERSION-FILE
diff --git a/Documentation/RelNotes-1.5.0.1.txt b/Documentation/RelNotes-1.5.0.1.txt
new file mode 100644
index 0000000..fea3f99
--- /dev/null
+++ b/Documentation/RelNotes-1.5.0.1.txt
@@ -0,0 +1,42 @@
+GIT v1.5.0.1 Release Notes
+==========================
+
+Fixes since v1.5.0
+------------------
+
+* Documentation updates
+
+ - Clarifications and corrections to 1.5.0 release notes.
+
+ - The main documentation did not link to git-remote documentation.
+
+ - Clarified introductory text of git-rebase documentation.
+
+ - Converted remaining mentions of update-index on Porcelain
+ documents to git-add/git-rm.
+
+ - Some i18n.* configuration variables were incorrectly
+ described as core.*; fixed.
+
+* Bugfixes
+
+ - git-add and git-update-index on a filesystem on which
+ executable bits are unreliable incorrectly reused st_mode
+ bits even when the path changed between symlink and regular
+ file.
+
+ - git-daemon marks the listening sockets with FD_CLOEXEC so
+ that it won't be leaked into the children.
+
+ - segfault from git-blame when the mandatory pathname
+ parameter was missing was fixed; usage() message is given
+ instead.
+
+ - git-rev-list did not read $GIT_DIR/config file, which means
+ that did not honor i18n.logoutputencoding correctly.
+
+* Tweaks
+
+ - sliding mmap() inefficiently mmaped the same region of a
+ packfile with an access pattern that used objects in the
+ reverse order. This has been made more efficient.
diff --git a/Documentation/RelNotes-1.5.0.2.txt b/Documentation/RelNotes-1.5.0.2.txt
new file mode 100644
index 0000000..b061e50
--- /dev/null
+++ b/Documentation/RelNotes-1.5.0.2.txt
@@ -0,0 +1,65 @@
+GIT v1.5.0.2 Release Notes
+==========================
+
+Fixes since v1.5.0.1
+--------------------
+
+* Bugfixes
+
+ - Automated merge conflict handling when changes to symbolic
+ links conflicted were completely broken. The merge-resolve
+ strategy created a regular file with conflict markers in it
+ in place of the symbolic link. The default strategy,
+ merge-recursive was even more broken. It removed the path
+ that was pointed at by the symbolic link. Both of these
+ problems have been fixed.
+
+ - 'git diff maint master next' did not correctly give combined
+ diff across three trees.
+
+ - 'git fast-import' portability fix for Solaris.
+
+ - 'git show-ref --verify' without arguments did not error out
+ but segfaulted.
+
+ - 'git diff :tracked-file `pwd`/an-untracked-file' gave an extra
+ slashes after a/ and b/.
+
+ - 'git format-patch' produced too long filenames if the commit
+ message had too long line at the beginning.
+
+ - Running 'make all' and then without changing anything
+ running 'make install' still rebuilt some files. This
+ was inconvenient when building as yourself and then
+ installing as root (especially problematic when the source
+ directory is on NFS and root is mapped to nobody).
+
+ - 'git-rerere' failed to deal with two unconflicted paths that
+ sorted next to each other.
+
+ - 'git-rerere' attempted to open(2) a symlink and failed if
+ there was a conflict. Since a conflicting change to a
+ symlink would not benefit from rerere anyway, the command
+ now ignores conflicting changes to symlinks.
+
+ - 'git-repack' did not like to pass more than 64 arguments
+ internally to underlying 'rev-list' logic, which made it
+ impossible to repack after accumulating many (small) packs
+ in the repository.
+
+ - 'git-diff' to review the combined diff during a conflicted
+ merge were not reading the working tree version correctly
+ when changes to a symbolic link conflicted. It should have
+ read the data using readlink(2) but read from the regular
+ file the symbolic link pointed at.
+
+ - 'git-remote' did not like period in a remote's name.
+
+* Documentation updates
+
+ - added and clarified core.bare, core.legacyheaders configurations.
+
+ - updated "git-clone --depth" documentation.
+
+
+* Assorted git-gui fixes.
diff --git a/Documentation/RelNotes-1.5.0.3.txt b/Documentation/RelNotes-1.5.0.3.txt
new file mode 100644
index 0000000..cd500f9
--- /dev/null
+++ b/Documentation/RelNotes-1.5.0.3.txt
@@ -0,0 +1,58 @@
+GIT v1.5.0.3 Release Notes
+==========================
+
+Fixes since v1.5.0.2
+--------------------
+
+* Bugfixes
+
+ - 'git.el' honors the commit coding system from the configuration.
+
+ - 'blameview' in contrib/ correctly digs deeper when a line is
+ clicked.
+
+ - 'http-push' correctly makes sure the remote side has leading
+ path. Earlier it started in the middle of the path, and
+ incorrectly.
+
+ - 'git-merge' did not exit with non-zero status when the
+ working tree was dirty and cannot fast forward. It does
+ now.
+
+ - 'cvsexportcommit' does not lose yet-to-be-used message file.
+
+ - int-vs-size_t typefix when running combined diff on files
+ over 2GB long.
+
+ - 'git apply --whitespace=strip' should not touch unmodified
+ lines.
+
+ - 'git-mailinfo' choke when a logical header line was too long.
+
+ - 'git show A..B' did not error out. Negative ref ("not A" in
+ this example) does not make sense for the purpose of the
+ command, so now it errors out.
+
+ - 'git fmt-merge-msg --file' without file parameter did not
+ correctly error out.
+
+ - 'git archimport' barfed upon encountering a commit without
+ summary.
+
+ - 'git index-pack' did not protect itself from getting a short
+ read out of pread(2).
+
+ - 'git http-push' had a few buffer overruns.
+
+ - Build dependency fixes to rebuild fetch.o when other headers
+ change.
+
+* Documentation updates
+
+ - user-manual updates.
+
+ - Options to 'git remote add' were described insufficiently.
+
+ - Configuration format.suffix was not documented.
+
+ - Other formatting and spelling fixes.
diff --git a/Documentation/RelNotes-1.5.0.4.txt b/Documentation/RelNotes-1.5.0.4.txt
new file mode 100644
index 0000000..feefa5d
--- /dev/null
+++ b/Documentation/RelNotes-1.5.0.4.txt
@@ -0,0 +1,22 @@
+GIT v1.5.0.4 Release Notes
+==========================
+
+Fixes since v1.5.0.3
+--------------------
+
+* Bugfixes
+
+ - git.el does not add duplicate sign-off lines.
+
+ - git-commit shows the full stat of the resulting commit, not
+ just about the files in the current directory, when run from
+ a subdirectory.
+
+ - "git-checkout -m '@{8 hours ago}'" had a funny failure from
+ eval; fixed.
+
+ - git-gui updates.
+
+* Documentation updates
+
+* User manual updates
diff --git a/Documentation/RelNotes-1.5.0.5.txt b/Documentation/RelNotes-1.5.0.5.txt
new file mode 100644
index 0000000..eeec3d7
--- /dev/null
+++ b/Documentation/RelNotes-1.5.0.5.txt
@@ -0,0 +1,26 @@
+GIT v1.5.0.5 Release Notes
+==========================
+
+Fixes since v1.5.0.3
+--------------------
+
+* Bugfixes
+
+ - git-merge (hence git-pull) did not refuse fast-forwarding
+ when the working tree had local changes that would have
+ conflicted with it.
+
+ - git.el does not add duplicate sign-off lines.
+
+ - git-commit shows the full stat of the resulting commit, not
+ just about the files in the current directory, when run from
+ a subdirectory.
+
+ - "git-checkout -m '@{8 hours ago}'" had a funny failure from
+ eval; fixed.
+
+ - git-gui updates.
+
+* Documentation updates
+
+* User manual updates
diff --git a/Documentation/RelNotes-1.5.0.6.txt b/Documentation/RelNotes-1.5.0.6.txt
new file mode 100644
index 0000000..c02015a
--- /dev/null
+++ b/Documentation/RelNotes-1.5.0.6.txt
@@ -0,0 +1,21 @@
+GIT v1.5.0.6 Release Notes
+==========================
+
+Fixes since v1.5.0.5
+--------------------
+
+* Bugfixes
+
+ - a handful small fixes to gitweb.
+
+ - build procedure for user-manual is fixed not to require locally
+ installed stylesheets.
+
+ - "git commit $paths" on paths whose earlier contents were
+ already updated in the index were failing out.
+
+* Documentation
+
+ - user-manual has better cross references.
+
+ - gitweb installation/deployment procedure is now documented.
diff --git a/Documentation/RelNotes-1.5.0.7.txt b/Documentation/RelNotes-1.5.0.7.txt
new file mode 100644
index 0000000..670ad32
--- /dev/null
+++ b/Documentation/RelNotes-1.5.0.7.txt
@@ -0,0 +1,18 @@
+GIT v1.5.0.7 Release Notes
+==========================
+
+Fixes since v1.5.0.6
+--------------------
+
+* Bugfixes
+
+ - git-upload-pack failed to close unused pipe ends, resulting
+ in many zombies to hang around.
+
+ - git-rerere was recording the contents of earlier hunks
+ duplicated in later hunks. This prevented resolving the same
+ conflict when performing the same merge the other way around.
+
+* Documentation
+
+ - a few documentation fixes from Debian package maintainer.
diff --git a/Documentation/RelNotes-1.5.0.txt b/Documentation/RelNotes-1.5.0.txt
new file mode 100644
index 0000000..daf4bdb
--- /dev/null
+++ b/Documentation/RelNotes-1.5.0.txt
@@ -0,0 +1,469 @@
+GIT v1.5.0 Release Notes
+========================
+
+Old news
+--------
+
+This section is for people who are upgrading from ancient
+versions of git. Although all of the changes in this section
+happened before the current v1.4.4 release, they are summarized
+here in the v1.5.0 release notes for people who skipped earlier
+versions.
+
+As of git v1.5.0 there are some optional features that changes
+the repository to allow data to be stored and transferred more
+efficiently. These features are not enabled by default, as they
+will make the repository unusable with older versions of git.
+Specifically, the available options are:
+
+ - There is a configuration variable core.legacyheaders that
+ changes the format of loose objects so that they are more
+ efficient to pack and to send out of the repository over git
+ native protocol, since v1.4.2. However, loose objects
+ written in the new format cannot be read by git older than
+ that version; people fetching from your repository using
+ older clients over dumb transports (e.g. http) using older
+ versions of git will also be affected.
+
+ To let git use the new loose object format, you have to
+ set core.legacyheaders to false.
+
+ - Since v1.4.3, configuration repack.usedeltabaseoffset allows
+ packfile to be created in more space efficient format, which
+ cannot be read by git older than that version.
+
+ To let git use the new format for packfiles, you have to
+ set repack.usedeltabaseoffset to true.
+
+The above two new features are not enabled by default and you
+have to explicitly ask for them, because they make repositories
+unreadable by older versions of git, and in v1.5.0 we still do
+not enable them by default for the same reason. We will change
+this default probably 1 year after 1.4.2's release, when it is
+reasonable to expect everybody to have new enough version of
+git.
+
+ - 'git pack-refs' appeared in v1.4.4; this command allows tags
+ to be accessed much more efficiently than the traditional
+ 'one-file-per-tag' format. Older git-native clients can
+ still fetch from a repository that packed and pruned refs
+ (the server side needs to run the up-to-date version of git),
+ but older dumb transports cannot. Packing of refs is done by
+ an explicit user action, either by use of "git pack-refs
+ --prune" command or by use of "git gc" command.
+
+ - 'git -p' to paginate anything -- many commands do pagination
+ by default on a tty. Introduced between v1.4.1 and v1.4.2;
+ this may surprise old timers.
+
+ - 'git archive' superseded 'git tar-tree' in v1.4.3;
+
+ - 'git cvsserver' was new invention in v1.3.0;
+
+ - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
+ seriously enhanced during v1.4.0 timeperiod.
+
+ - 'gitweb' became part of git.git during v1.4.0 timeperiod and
+ seriously modified since then.
+
+ - reflog is an v1.4.0 invention. This allows you to name a
+ revision that a branch used to be at (e.g. "git diff
+ master@{yesterday} master" allows you to see changes since
+ yesterday's tip of the branch).
+
+
+Updates in v1.5.0 since v1.4.4 series
+-------------------------------------
+
+* Index manipulation
+
+ - git-add is to add contents to the index (aka "staging area"
+ for the next commit), whether the file the contents happen to
+ be is an existing one or a newly created one.
+
+ - git-add without any argument does not add everything
+ anymore. Use 'git-add .' instead. Also you can add
+ otherwise ignored files with an -f option.
+
+ - git-add tries to be more friendly to users by offering an
+ interactive mode ("git-add -i").
+
+ - git-commit <path> used to refuse to commit if <path> was
+ different between HEAD and the index (i.e. update-index was
+ used on it earlier). This check was removed.
+
+ - git-rm is much saner and safer. It is used to remove paths
+ from both the index file and the working tree, and makes sure
+ you are not losing any local modification before doing so.
+
+ - git-reset <tree> <paths>... can be used to revert index
+ entries for selected paths.
+
+ - git-update-index is much less visible. Many suggestions to
+ use the command in git output and documentation have now been
+ replaced by simpler commands such as "git add" or "git rm".
+
+
+* Repository layout and objects transfer
+
+ - The data for origin repository is stored in the configuration
+ file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
+ created clones. The latter is still supported and there is
+ no need to convert your existing repository if you are
+ already comfortable with your workflow with the layout.
+
+ - git-clone always uses what is known as "separate remote"
+ layout for a newly created repository with a working tree.
+
+ A repository with the separate remote layout starts with only
+ one default branch, 'master', to be used for your own
+ development. Unlike the traditional layout that copied all
+ the upstream branches into your branch namespace (while
+ renaming their 'master' to your 'origin'), the new layout
+ puts upstream branches into local "remote-tracking branches"
+ with their own namespace. These can be referenced with names
+ such as "origin/$upstream_branch_name" and are stored in
+ .git/refs/remotes rather than .git/refs/heads where normal
+ branches are stored.
+
+ This layout keeps your own branch namespace less cluttered,
+ avoids name collision with your upstream, makes it possible
+ to automatically track new branches created at the remote
+ after you clone from it, and makes it easier to interact with
+ more than one remote repository (you can use "git remote" to
+ add other repositories to track). There might be some
+ surprises:
+
+ * 'git branch' does not show the remote tracking branches.
+ It only lists your own branches. Use '-r' option to view
+ the tracking branches.
+
+ * If you are forking off of a branch obtained from the
+ upstream, you would have done something like 'git branch
+ my-next next', because traditional layout dropped the
+ tracking branch 'next' into your own branch namespace.
+ With the separate remote layout, you say 'git branch next
+ origin/next', which allows you to use the matching name
+ 'next' for your own branch. It also allows you to track a
+ remote other than 'origin' (i.e. where you initially cloned
+ from) and fork off of a branch from there the same way
+ (e.g. "git branch mingw j6t/master").
+
+ Repositories initialized with the traditional layout continue
+ to work.
+
+ - New branches that appear on the origin side after a clone is
+ made are also tracked automatically. This is done with an
+ wildcard refspec "refs/heads/*:refs/remotes/origin/*", which
+ older git does not understand, so if you clone with 1.5.0,
+ you would need to downgrade remote.*.fetch in the
+ configuration file to specify each branch you are interested
+ in individually if you plan to fetch into the repository with
+ older versions of git (but why would you?).
+
+ - Similarly, wildcard refspec "refs/heads/*:refs/remotes/me/*"
+ can be given to "git-push" command to update the tracking
+ branches that is used to track the repository you are pushing
+ from on the remote side.
+
+ - git-branch and git-show-branch know remote tracking branches
+ (use the command line switch "-r" to list only tracked branches).
+
+ - git-push can now be used to delete a remote branch or a tag.
+ This requires the updated git on the remote side (use "git
+ push <remote> :refs/heads/<branch>" to delete "branch").
+
+ - git-push more aggressively keeps the transferred objects
+ packed. Earlier we recommended to monitor amount of loose
+ objects and repack regularly, but you should repack when you
+ accumulated too many small packs this way as well. Updated
+ git-count-objects helps you with this.
+
+ - git-fetch also more aggressively keeps the transferred objects
+ packed. This behavior of git-push and git-fetch can be
+ tweaked with a single configuration transfer.unpacklimit (but
+ usually there should not be any need for a user to tweak it).
+
+ - A new command, git-remote, can help you manage your remote
+ tracking branch definitions.
+
+ - You may need to specify explicit paths for upload-pack and/or
+ receive-pack due to your ssh daemon configuration on the
+ other end. This can now be done via remote.*.uploadpack and
+ remote.*.receivepack configuration.
+
+
+* Bare repositories
+
+ - Certain commands change their behavior in a bare repository
+ (i.e. a repository without associated working tree). We use
+ a fairly conservative heuristic (if $GIT_DIR is ".git", or
+ ends with "/.git", the repository is not bare) to decide if a
+ repository is bare, but "core.bare" configuration variable
+ can be used to override the heuristic when it misidentifies
+ your repository.
+
+ - git-fetch used to complain updating the current branch but
+ this is now allowed for a bare repository. So is the use of
+ 'git-branch -f' to update the current branch.
+
+ - Porcelain-ish commands that require a working tree refuses to
+ work in a bare repository.
+
+
+* Reflog
+
+ - Reflog records the history from the view point of the local
+ repository. In other words, regardless of the real history,
+ the reflog shows the history as seen by one particular
+ repository (this enables you to ask "what was the current
+ revision in _this_ repository, yesterday at 1pm?"). This
+ facility is enabled by default for repositories with working
+ trees, and can be accessed with the "branch@{time}" and
+ "branch@{Nth}" notation.
+
+ - "git show-branch" learned showing the reflog data with the
+ new -g option. "git log" has -g option to view reflog
+ entries in a more verbose manner.
+
+ - git-branch knows how to rename branches and moves existing
+ reflog data from the old branch to the new one.
+
+ - In addition to the reflog support in v1.4.4 series, HEAD
+ reference maintains its own log. "HEAD@{5.minutes.ago}"
+ means the commit you were at 5 minutes ago, which takes
+ branch switching into account. If you want to know where the
+ tip of your current branch was at 5 minutes ago, you need to
+ explicitly say its name (e.g. "master@{5.minutes.ago}") or
+ omit the refname altogether i.e. "@{5.minutes.ago}".
+
+ - The commits referred to by reflog entries are now protected
+ against pruning. The new command "git reflog expire" can be
+ used to truncate older reflog entries and entries that refer
+ to commits that have been pruned away previously with older
+ versions of git.
+
+ Existing repositories that have been using reflog may get
+ complaints from fsck-objects and may not be able to run
+ git-repack, if you had run git-prune from older git; please
+ run "git reflog expire --stale-fix --all" first to remove
+ reflog entries that refer to commits that are no longer in
+ the repository when that happens.
+
+
+* Crufts removal
+
+ - We used to say "old commits are retrievable using reflog and
+ 'master@{yesterday}' syntax as long as you haven't run
+ git-prune". We no longer have to say the latter half of the
+ above sentence, as git-prune does not remove things reachable
+ from reflog entries.
+
+ - There is a toplevel garbage collector script, 'git-gc', that
+ runs periodic cleanup functions, including 'git-repack -a -d',
+ 'git-reflog expire', 'git-pack-refs --prune', and 'git-rerere
+ gc'.
+
+ - The output from fsck ("fsck-objects" is called just "fsck"
+ now, but the old name continues to work) was needlessly
+ alarming in that it warned missing objects that are reachable
+ only from dangling objects. This has been corrected and the
+ output is much more useful.
+
+
+* Detached HEAD
+
+ - You can use 'git-checkout' to check out an arbitrary revision
+ or a tag as well, instead of named branches. This will
+ dissociate your HEAD from the branch you are currently on.
+
+ A typical use of this feature is to "look around". E.g.
+
+ $ git checkout v2.6.16
+ ... compile, test, etc.
+ $ git checkout v2.6.17
+ ... compile, test, etc.
+
+ - After detaching your HEAD, you can go back to an existing
+ branch with usual "git checkout $branch". Also you can
+ start a new branch using "git checkout -b $newbranch" to
+ start a new branch at that commit.
+
+ - You can even pull from other repositories, make merges and
+ commits while your HEAD is detached. Also you can use "git
+ reset" to jump to arbitrary commit, while still keeping your
+ HEAD detached.
+
+ Remember that a detached state is volatile, i.e. it will be forgotten
+ as soon as you move away from it with the checkout or reset command,
+ unless a branch is created from it as mentioned above. It is also
+ possible to rescue a lost detached state from the HEAD reflog.
+
+
+* Packed refs
+
+ - Repositories with hundreds of tags have been paying large
+ overhead, both in storage and in runtime, due to the
+ traditional one-ref-per-file format. A new command,
+ git-pack-refs, can be used to "pack" them in more efficient
+ representation (you can let git-gc do this for you).
+
+ - Clones and fetches over dumb transports are now aware of
+ packed refs and can download from repositories that use
+ them.
+
+
+* Configuration
+
+ - configuration related to color setting are consolidated under
+ color.* namespace (older diff.color.*, status.color.* are
+ still supported).
+
+ - 'git-repo-config' command is accessible as 'git-config' now.
+
+
+* Updated features
+
+ - git-describe uses better criteria to pick a base ref. It
+ used to pick the one with the newest timestamp, but now it
+ picks the one that is topologically the closest (that is,
+ among ancestors of commit C, the ref T that has the shortest
+ output from "git-rev-list T..C" is chosen).
+
+ - git-describe gives the number of commits since the base ref
+ between the refname and the hash suffix. E.g. the commit one
+ before v2.6.20-rc6 in the kernel repository is:
+
+ v2.6.20-rc5-306-ga21b069
+
+ which tells you that its object name begins with a21b069,
+ v2.6.20-rc5 is an ancestor of it (meaning, the commit
+ contains everything -rc5 has), and there are 306 commits
+ since v2.6.20-rc5.
+
+ - git-describe with --abbrev=0 can be used to show only the
+ name of the base ref.
+
+ - git-blame learned a new option, --incremental, that tells it
+ to output the blames as they are assigned. A sample script
+ to use it is also included as contrib/blameview.
+
+ - git-blame starts annotating from the working tree by default.
+
+
+* Less external dependency
+
+ - We no longer require the "merge" program from the RCS suite.
+ All 3-way file-level merges are now done internally.
+
+ - The original implementation of git-merge-recursive which was
+ in Python has been removed; we have a C implementation of it
+ now.
+
+ - git-shortlog is no longer a Perl script. It no longer
+ requires output piped from git-log; it can accept revision
+ parameters directly on the command line.
+
+
+* I18n
+
+ - We have always encouraged the commit message to be encoded in
+ UTF-8, but the users are allowed to use legacy encoding as
+ appropriate for their projects. This will continue to be the
+ case. However, a non UTF-8 commit encoding _must_ be
+ explicitly set with i18n.commitencoding in the repository
+ where a commit is made; otherwise git-commit-tree will
+ complain if the log message does not look like a valid UTF-8
+ string.
+
+ - The value of i18n.commitencoding in the originating
+ repository is recorded in the commit object on the "encoding"
+ header, if it is not UTF-8. git-log and friends notice this,
+ and reencodes the message to the log output encoding when
+ displaying, if they are different. The log output encoding
+ is determined by "git log --encoding=<encoding>",
+ i18n.logoutputencoding configuration, or i18n.commitencoding
+ configuration, in the decreasing order of preference, and
+ defaults to UTF-8.
+
+ - Tools for e-mailed patch application now default to -u
+ behavior; i.e. it always re-codes from the e-mailed encoding
+ to the encoding specified with i18n.commitencoding. This
+ unfortunately forces projects that have happily been using a
+ legacy encoding without setting i18n.commitencoding to set
+ the configuration, but taken with other improvement, please
+ excuse us for this very minor one-time inconvenience.
+
+
+* e-mailed patches
+
+ - See the above I18n section.
+
+ - git-format-patch now enables --binary without being asked.
+ git-am does _not_ default to it, as sending binary patch via
+ e-mail is unusual and is harder to review than textual
+ patches and it is prudent to require the person who is
+ applying the patch to explicitly ask for it.
+
+ - The default suffix for git-format-patch output is now ".patch",
+ not ".txt". This can be changed with --suffix=.txt option,
+ or setting the config variable "format.suffix" to ".txt".
+
+
+* Foreign SCM interfaces
+
+ - git-svn now requires the Perl SVN:: libraries, the
+ command-line backend was too slow and limited.
+
+ - the 'commit' subcommand of git-svn has been renamed to
+ 'set-tree', and 'dcommit' is the recommended replacement for
+ day-to-day work.
+
+ - git fast-import backend.
+
+
+* User support
+
+ - Quite a lot of documentation updates.
+
+ - Bash completion scripts have been updated heavily.
+
+ - Better error messages for often used Porcelainish commands.
+
+ - Git GUI. This is a simple Tk based graphical interface for
+ common Git operations.
+
+
+* Sliding mmap
+
+ - We used to assume that we can mmap the whole packfile while
+ in use, but with a large project this consumes huge virtual
+ memory space and truly huge ones would not fit in the
+ userland address space on 32-bit platforms. We now mmap huge
+ packfile in pieces to avoid this problem.
+
+
+* Shallow clones
+
+ - There is a partial support for 'shallow' repositories that
+ keeps only recent history. A 'shallow clone' is created by
+ specifying how deep that truncated history should be
+ (e.g. "git clone --depth 5 git://some.where/repo.git").
+
+ Currently a shallow repository has number of limitations:
+
+ - Cloning and fetching _from_ a shallow clone are not
+ supported (nor tested -- so they might work by accident but
+ they are not expected to).
+
+ - Pushing from nor into a shallow clone are not expected to
+ work.
+
+ - Merging inside a shallow repository would work as long as a
+ merge base is found in the recent history, but otherwise it
+ will be like merging unrelated histories and may result in
+ huge conflicts.
+
+ but this would be more than adequate for people who want to
+ look at near the tip of a big project with a deep history and
+ send patches in e-mail format.
diff --git a/Documentation/RelNotes-1.5.1.1.txt b/Documentation/RelNotes-1.5.1.1.txt
new file mode 100644
index 0000000..9147121
--- /dev/null
+++ b/Documentation/RelNotes-1.5.1.1.txt
@@ -0,0 +1,65 @@
+GIT v1.5.1.1 Release Notes
+==========================
+
+Fixes since v1.5.1
+------------------
+
+* Documentation updates
+
+ - The --left-right option of rev-list and friends is documented.
+
+ - The documentation for cvsimport has been majorly improved.
+
+ - "git-show-ref --exclude-existing" was documented.
+
+* Bugfixes
+
+ - The implementation of -p option in "git cvsexportcommit" had
+ the meaning of -C (context reduction) option wrong, and
+ loosened the context requirements when it was told to be
+ strict.
+
+ - "git cvsserver" did not behave like the real cvsserver when
+ client side removed a file from the working tree without
+ doing anything else on the path. In such a case, it should
+ restore it from the checked out revision.
+
+ - "git fsck" issued an alarming error message on detached
+ HEAD. It is not an error since at least 1.5.0.
+
+ - "git send-email" produced of References header of unbounded length;
+ fixed this with line-folding.
+
+ - "git archive" to download from remote site should not
+ require you to be in a git repository, but it incorrectly
+ did.
+
+ - "git apply" ignored -p<n> for "diff --git" formatted
+ patches.
+
+ - "git rerere" recorded a conflict that had one side empty
+ (the other side adds) incorrectly; this made merging in the
+ other direction fail to use previously recorded resolution.
+
+ - t4200 test was broken where "wc -l" pads its output with
+ spaces.
+
+ - "git branch -m old new" to rename branch did not work
+ without a configuration file in ".git/config".
+
+ - The sample hook for notification e-mail was misnamed.
+
+ - gitweb did not show type-changing patch correctly in the
+ blobdiff view.
+
+ - git-svn did not error out with incorrect command line options.
+
+ - git-svn fell into an infinite loop when insanely long commit
+ message was found.
+
+ - git-svn dcommit and rebase was confused by patches that were
+ merged from another branch that is managed by git-svn.
+
+ - git-svn used to get confused when globbing remote branch/tag
+ spec (e.g. "branches = proj/branches/*:refs/remotes/origin/*")
+ is used and there was a plain file that matched the glob.
diff --git a/Documentation/RelNotes-1.5.1.2.txt b/Documentation/RelNotes-1.5.1.2.txt
new file mode 100644
index 0000000..d884563
--- /dev/null
+++ b/Documentation/RelNotes-1.5.1.2.txt
@@ -0,0 +1,50 @@
+GIT v1.5.1.2 Release Notes
+==========================
+
+Fixes since v1.5.1.1
+--------------------
+
+* Bugfixes
+
+ - "git clone" over http from a repository that has lost the
+ loose refs by running "git pack-refs" were broken (a code to
+ deal with this was added to "git fetch" in v1.5.0, but it
+ was missing from "git clone").
+
+ - "git diff a/ b/" incorrectly fell in "diff between two
+ filesystem objects" codepath, when the user most likely
+ wanted to limit the extent of output to two tracked
+ directories.
+
+ - git-quiltimport had the same bug as we fixed for
+ git-applymbox in v1.5.1.1 -- it gave an alarming "did not
+ have any patch" message (but did not actually fail and was
+ harmless).
+
+ - various git-svn fixes.
+
+ - Sample update hook incorrectly always refused requests to
+ delete branches through push.
+
+ - git-blame on a very long working tree path had buffer
+ overrun problem.
+
+ - git-apply did not like to be fed two patches in a row that created
+ and then modified the same file.
+
+ - git-svn was confused when a non-project was stored directly under
+ trunk/, branches/ and tags/.
+
+ - git-svn wants the Error.pm module that was at least as new
+ as what we ship as part of git; install ours in our private
+ installation location if the one on the system is older.
+
+ - An earlier update to command line integer parameter parser was
+ botched and made 'update-index --cacheinfo' completely useless.
+
+
+* Documentation updates
+
+ - Various documentation updates from J. Bruce Fields, Frank
+ Lichtenheld, Alex Riesen and others. Andrew Ruder started a
+ war on undocumented options.
diff --git a/Documentation/RelNotes-1.5.1.3.txt b/Documentation/RelNotes-1.5.1.3.txt
new file mode 100644
index 0000000..876408b
--- /dev/null
+++ b/Documentation/RelNotes-1.5.1.3.txt
@@ -0,0 +1,45 @@
+GIT v1.5.1.3 Release Notes
+==========================
+
+Fixes since v1.5.1.2
+--------------------
+
+* Bugfixes
+
+ - git-add tried to optimize by finding common leading
+ directories across its arguments but botched, causing very
+ confused behaviour.
+
+ - unofficial rpm.spec file shipped with git was letting
+ ETC_GITCONFIG set to /usr/etc/gitconfig. Tweak the official
+ Makefile to make it harder for distro people to make the
+ same mistake, by setting the variable to /etc/gitconfig if
+ prefix is set to /usr.
+
+ - git-svn inconsistently stripped away username from the URL
+ only when svnsync_props was in use.
+
+ - git-svn got confused when handling symlinks on Mac OS.
+
+ - git-send-email was not quoting recipient names that have
+ period '.' in them. Also it did not allow overriding
+ envelope sender, which made it impossible to send patches to
+ certain subscriber-only lists.
+
+ - built-in write_tree() routine had a sequence that renamed a
+ file that is still open, which some systems did not like.
+
+ - when memory is very tight, sliding mmap code to read
+ packfiles incorrectly closed the fd that was still being
+ used to read the pack.
+
+ - import-tars contributed front-end for fastimport was passing
+ wrong directory modes without checking.
+
+ - git-fastimport trusted its input too much and allowed to
+ create corrupt tree objects with entries without a name.
+
+ - git-fetch needlessly barfed when too long reflog action
+ description was given by the caller.
+
+Also contains various documentation updates.
diff --git a/Documentation/RelNotes-1.5.1.4.txt b/Documentation/RelNotes-1.5.1.4.txt
new file mode 100644
index 0000000..df2f66c
--- /dev/null
+++ b/Documentation/RelNotes-1.5.1.4.txt
@@ -0,0 +1,30 @@
+GIT v1.5.1.4 Release Notes
+==========================
+
+Fixes since v1.5.1.3
+--------------------
+
+* Bugfixes
+
+ - "git-http-fetch" did not work around a bug in libcurl
+ earlier than 7.16 (curl_multi_remove_handle() was broken).
+
+ - "git cvsserver" handles a file that was once removed and
+ then added again correctly.
+
+ - import-tars script (in contrib/) handles GNU tar archives
+ that contain pathnames longer than 100 bytes (long-link
+ extension) correctly.
+
+ - xdelta test program did not build correctly.
+
+ - gitweb sometimes tried incorrectly to apply function to
+ decode utf8 twice, resulting in corrupt output.
+
+ - "git blame -C" mishandled text at the end of a group of
+ lines.
+
+ - "git log/rev-list --boundary" did not produce output
+ correctly without --left-right option.
+
+ - Many documentation updates.
diff --git a/Documentation/RelNotes-1.5.1.5.txt b/Documentation/RelNotes-1.5.1.5.txt
new file mode 100644
index 0000000..b0ab8eb
--- /dev/null
+++ b/Documentation/RelNotes-1.5.1.5.txt
@@ -0,0 +1,42 @@
+GIT v1.5.1.5 Release Notes
+==========================
+
+Fixes since v1.5.1.4
+--------------------
+
+* Bugfixes
+
+ - git-send-email did not understand aliases file for mutt, which
+ allows leading whitespaces.
+
+ - git-format-patch emitted Content-Type and Content-Transfer-Encoding
+ headers for non ASCII contents, but failed to add MIME-Version.
+
+ - git-name-rev had a buffer overrun with a deep history.
+
+ - contributed script import-tars did not get the directory in
+ tar archives interpreted correctly.
+
+ - git-svn was reported to segfault for many people on list and
+ #git; hopefully this has been fixed.
+
+ - "git-svn clone" does not try to minimize the URL
+ (i.e. connect to higher level hierarchy) by default, as this
+ can prevent clone to fail if only part of the repository
+ (e.g. 'trunk') is open to public.
+
+ - "git checkout branch^0" did not detach the head when you are
+ already on 'branch'; backported the fix from the 'master'.
+
+ - "git-config section.var" did not correctly work when
+ existing configuration file had both [section] and [section "name"]
+ next to each other.
+
+ - "git clone ../other-directory" was fooled if the current
+ directory $PWD points at is a symbolic link.
+
+ - (build) tree_entry_extract() function was both static inline
+ and extern, which caused trouble compiling with Forte12
+ compilers on Sun.
+
+ - Many many documentation fixes and updates.
diff --git a/Documentation/RelNotes-1.5.1.6.txt b/Documentation/RelNotes-1.5.1.6.txt
new file mode 100644
index 0000000..55f3ac1
--- /dev/null
+++ b/Documentation/RelNotes-1.5.1.6.txt
@@ -0,0 +1,45 @@
+GIT v1.5.1.6 Release Notes
+==========================
+
+Fixes since v1.5.1.4
+--------------------
+
+* Bugfixes
+
+ - git-send-email did not understand aliases file for mutt, which
+ allows leading whitespaces.
+
+ - git-format-patch emitted Content-Type and Content-Transfer-Encoding
+ headers for non ASCII contents, but failed to add MIME-Version.
+
+ - git-name-rev had a buffer overrun with a deep history.
+
+ - contributed script import-tars did not get the directory in
+ tar archives interpreted correctly.
+
+ - git-svn was reported to segfault for many people on list and
+ #git; hopefully this has been fixed.
+
+ - git-svn also had a bug to crash svnserve by sending a bad
+ sequence of requests.
+
+ - "git-svn clone" does not try to minimize the URL
+ (i.e. connect to higher level hierarchy) by default, as this
+ can prevent clone to fail if only part of the repository
+ (e.g. 'trunk') is open to public.
+
+ - "git checkout branch^0" did not detach the head when you are
+ already on 'branch'; backported the fix from the 'master'.
+
+ - "git-config section.var" did not correctly work when
+ existing configuration file had both [section] and [section "name"]
+ next to each other.
+
+ - "git clone ../other-directory" was fooled if the current
+ directory $PWD points at is a symbolic link.
+
+ - (build) tree_entry_extract() function was both static inline
+ and extern, which caused trouble compiling with Forte12
+ compilers on Sun.
+
+ - Many many documentation fixes and updates.
diff --git a/Documentation/RelNotes-1.5.1.txt b/Documentation/RelNotes-1.5.1.txt
new file mode 100644
index 0000000..daed367
--- /dev/null
+++ b/Documentation/RelNotes-1.5.1.txt
@@ -0,0 +1,371 @@
+GIT v1.5.1 Release Notes
+========================
+
+Updates since v1.5.0
+--------------------
+
+* Deprecated commands and options.
+
+ - git-diff-stages and git-resolve have been removed.
+
+* New commands and options.
+
+ - "git log" and friends take --reverse, which instructs them
+ to give their output in the order opposite from their usual.
+ They typically output from new to old, but with this option
+ their output would read from old to new. "git shortlog"
+ usually lists older commits first, but with this option,
+ they are shown from new to old.
+
+ - "git log --pretty=format:<string>" to allow more flexible
+ custom log output.
+
+ - "git diff" learned --ignore-space-at-eol. This is a weaker
+ form of --ignore-space-change.
+
+ - "git diff --no-index pathA pathB" can be used as diff
+ replacement with git specific enhancements.
+
+ - "git diff --no-index" can read from '-' (standard input).
+
+ - "git diff" also learned --exit-code to exit with non-zero
+ status when it found differences. In the future we might
+ want to make this the default but that would be a rather big
+ backward incompatible change; it will stay as an option for
+ now.
+
+ - "git diff --quiet" is --exit-code with output turned off,
+ meant for scripted use to quickly determine if there is any
+ tree-level difference.
+
+ - Textual patch generation with "git diff" without -w/-b
+ option has been significantly optimized. "git blame" got
+ faster because of the same change.
+
+ - "git log" and "git rev-list" has been optimized
+ significantly when they are used with pathspecs.
+
+ - "git branch --track" can be used to set up configuration
+ variables to help it easier to base your work on branches
+ you track from a remote site.
+
+ - "git format-patch --attach" now emits attachments. Use
+ --inline to get an inlined multipart/mixed.
+
+ - "git name-rev" learned --refs=<pattern>, to limit the tags
+ used for naming the given revisions only to the ones
+ matching the given pattern.
+
+ - "git remote update" is to run "git fetch" for defined remotes
+ to update tracking branches.
+
+ - "git cvsimport" can now take '-d' to talk with a CVS
+ repository different from what are recorded in CVS/Root
+ (overriding it with environment CVSROOT does not work).
+
+ - "git bundle" can help sneaker-netting your changes between
+ repositories.
+
+ - "git mergetool" can help 3-way file-level conflict
+ resolution with your favorite graphical merge tools.
+
+ - A new configuration "core.symlinks" can be used to disable
+ symlinks on filesystems that do not support them; they are
+ checked out as regular files instead.
+
+ - You can name a commit object with its first line of the
+ message. The syntax to use is ':/message text'. E.g.
+
+ $ git show ":/object name: introduce ':/<oneline prefix>' notation"
+
+ means the same thing as:
+
+ $ git show 28a4d940443806412effa246ecc7768a21553ec7
+
+ - "git bisect" learned a new command "run" that takes a script
+ to run after each revision is checked out to determine if it
+ is good or bad, to automate the bisection process.
+
+ - "git log" family learned a new traversal option --first-parent,
+ which does what the name suggests.
+
+
+* Updated behavior of existing commands.
+
+ - "git-merge-recursive" used to barf when there are more than
+ one common ancestors for the merge, and merging them had a
+ rename/rename conflict. This has been fixed.
+
+ - "git fsck" does not barf on corrupt loose objects.
+
+ - "git rm" does not remove newly added files without -f.
+
+ - "git archimport" allows remapping when coming up with git
+ branch names from arch names.
+
+ - git-svn got almost a rewrite.
+
+ - core.autocrlf configuration, when set to 'true', makes git
+ to convert CRLF at the end of lines in text files to LF when
+ reading from the filesystem, and convert in reverse when
+ writing to the filesystem. The variable can be set to
+ 'input', in which case the conversion happens only while
+ reading from the filesystem but files are written out with
+ LF at the end of lines. Currently, which paths to consider
+ 'text' (i.e. be subjected to the autocrlf mechanism) is
+ decided purely based on the contents, but the plan is to
+ allow users to explicitly override this heuristic based on
+ paths.
+
+ - The behavior of 'git-apply', when run in a subdirectory,
+ without --index nor --cached were inconsistent with that of
+ the command with these options. This was fixed to match the
+ behavior with --index. A patch that is meant to be applied
+ with -p1 from the toplevel of the project tree can be
+ applied with any custom -p<n> option. A patch that is not
+ relative to the toplevel needs to be applied with -p<n>
+ option with or without --index (or --cached).
+
+ - "git diff" outputs a trailing HT when pathnames have embedded
+ SP on +++/--- header lines, in order to help "GNU patch" to
+ parse its output. "git apply" was already updated to accept
+ this modified output format since ce74618d (Sep 22, 2006).
+
+ - "git cvsserver" runs hooks/update and honors its exit status.
+
+ - "git cvsserver" can be told to send everything with -kb.
+
+ - "git diff --check" also honors the --color output option.
+
+ - "git name-rev" used to stress the fact that a ref is a tag too
+ much, by saying something like "v1.2.3^0~22". It now says
+ "v1.2.3~22" in such a case (it still says "v1.2.3^0" if it does
+ not talk about an ancestor of the commit that is tagged, which
+ makes sense).
+
+ - "git rev-list --boundary" now shows boundary markers for the
+ commits omitted by --max-age and --max-count condition.
+
+ - The configuration mechanism now reads $(prefix)/etc/gitconfig.
+
+ - "git apply --verbose" shows what preimage lines were wanted
+ when it couldn't find them.
+
+ - "git status" in a read-only repository got a bit saner.
+
+ - "git fetch" (hence "git clone" and "git pull") are less
+ noisy when the output does not go to tty.
+
+ - "git fetch" between repositories with many refs were slow
+ even when there are not many changes that needed
+ transferring. This has been sped up by partially rewriting
+ the heaviest parts in C.
+
+ - "git mailinfo" which splits an e-mail into a patch and the
+ meta-information was rewritten, thanks to Don Zickus. It
+ handles nested multipart better. The command was broken for
+ a brief period on 'master' branch since 1.5.0 but the
+ breakage is fixed now.
+
+ - send-email learned configurable bcc and chain-reply-to.
+
+ - "git remote show $remote" also talks about branches that
+ would be pushed if you run "git push remote".
+
+ - Using objects from packs is now seriously optimized by clever
+ use of a cache. This should be most noticeable in git-log
+ family of commands that involve reading many tree objects.
+ In addition, traversing revisions while filtering changes
+ with pathspecs is made faster by terminating the comparison
+ between the trees as early as possible.
+
+
+* Hooks
+
+ - The part to send out notification e-mails was removed from
+ the sample update hook, as it was not an appropriate place
+ to do so. The proper place to do this is the new post-receive
+ hook. An example hook has been added to contrib/hooks/.
+
+
+* Others
+
+ - git-revert, git-gc and git-cherry-pick are now built-ins.
+
+Fixes since v1.5.0
+------------------
+
+These are all in v1.5.0.x series.
+
+* Documentation updates
+
+ - Clarifications and corrections to 1.5.0 release notes.
+
+ - The main documentation did not link to git-remote documentation.
+
+ - Clarified introductory text of git-rebase documentation.
+
+ - Converted remaining mentions of update-index on Porcelain
+ documents to git-add/git-rm.
+
+ - Some i18n.* configuration variables were incorrectly
+ described as core.*; fixed.
+
+ - added and clarified core.bare, core.legacyheaders configurations.
+
+ - updated "git-clone --depth" documentation.
+
+ - user-manual updates.
+
+ - Options to 'git remote add' were described insufficiently.
+
+ - Configuration format.suffix was not documented.
+
+ - Other formatting and spelling fixes.
+
+ - user-manual has better cross references.
+
+ - gitweb installation/deployment procedure is now documented.
+
+
+* Bugfixes
+
+ - git-upload-pack closes unused pipe ends; earlier this caused
+ many zombies to hang around.
+
+ - git-rerere was recording the contents of earlier hunks
+ duplicated in later hunks. This prevented resolving the same
+ conflict when performing the same merge the other way around.
+
+ - git-add and git-update-index on a filesystem on which
+ executable bits are unreliable incorrectly reused st_mode
+ bits even when the path changed between symlink and regular
+ file.
+
+ - git-daemon marks the listening sockets with FD_CLOEXEC so
+ that it won't be leaked into the children.
+
+ - segfault from git-blame when the mandatory pathname
+ parameter was missing was fixed; usage() message is given
+ instead.
+
+ - git-rev-list did not read $GIT_DIR/config file, which means
+ that did not honor i18n.logoutputencoding correctly.
+
+ - Automated merge conflict handling when changes to symbolic
+ links conflicted were completely broken. The merge-resolve
+ strategy created a regular file with conflict markers in it
+ in place of the symbolic link. The default strategy,
+ merge-recursive was even more broken. It removed the path
+ that was pointed at by the symbolic link. Both of these
+ problems have been fixed.
+
+ - 'git diff maint master next' did not correctly give combined
+ diff across three trees.
+
+ - 'git fast-import' portability fix for Solaris.
+
+ - 'git show-ref --verify' without arguments did not error out
+ but segfaulted.
+
+ - 'git diff :tracked-file `pwd`/an-untracked-file' gave an extra
+ slashes after a/ and b/.
+
+ - 'git format-patch' produced too long filenames if the commit
+ message had too long line at the beginning.
+
+ - Running 'make all' and then without changing anything
+ running 'make install' still rebuilt some files. This
+ was inconvenient when building as yourself and then
+ installing as root (especially problematic when the source
+ directory is on NFS and root is mapped to nobody).
+
+ - 'git-rerere' failed to deal with two unconflicted paths that
+ sorted next to each other.
+
+ - 'git-rerere' attempted to open(2) a symlink and failed if
+ there was a conflict. Since a conflicting change to a
+ symlink would not benefit from rerere anyway, the command
+ now ignores conflicting changes to symlinks.
+
+ - 'git-repack' did not like to pass more than 64 arguments
+ internally to underlying 'rev-list' logic, which made it
+ impossible to repack after accumulating many (small) packs
+ in the repository.
+
+ - 'git-diff' to review the combined diff during a conflicted
+ merge were not reading the working tree version correctly
+ when changes to a symbolic link conflicted. It should have
+ read the data using readlink(2) but read from the regular
+ file the symbolic link pointed at.
+
+ - 'git-remote' did not like period in a remote's name.
+
+ - 'git.el' honors the commit coding system from the configuration.
+
+ - 'blameview' in contrib/ correctly digs deeper when a line is
+ clicked.
+
+ - 'http-push' correctly makes sure the remote side has leading
+ path. Earlier it started in the middle of the path, and
+ incorrectly.
+
+ - 'git-merge' did not exit with non-zero status when the
+ working tree was dirty and cannot fast forward. It does
+ now.
+
+ - 'cvsexportcommit' does not lose yet-to-be-used message file.
+
+ - int-vs-size_t typefix when running combined diff on files
+ over 2GB long.
+
+ - 'git apply --whitespace=strip' should not touch unmodified
+ lines.
+
+ - 'git-mailinfo' choke when a logical header line was too long.
+
+ - 'git show A..B' did not error out. Negative ref ("not A" in
+ this example) does not make sense for the purpose of the
+ command, so now it errors out.
+
+ - 'git fmt-merge-msg --file' without file parameter did not
+ correctly error out.
+
+ - 'git archimport' barfed upon encountering a commit without
+ summary.
+
+ - 'git index-pack' did not protect itself from getting a short
+ read out of pread(2).
+
+ - 'git http-push' had a few buffer overruns.
+
+ - Build dependency fixes to rebuild fetch.o when other headers
+ change.
+
+ - git.el does not add duplicate sign-off lines.
+
+ - git-commit shows the full stat of the resulting commit, not
+ just about the files in the current directory, when run from
+ a subdirectory.
+
+ - "git-checkout -m '@{8 hours ago}'" had a funny failure from
+ eval; fixed.
+
+ - git-merge (hence git-pull) did not refuse fast-forwarding
+ when the working tree had local changes that would have
+ conflicted with it.
+
+ - a handful small fixes to gitweb.
+
+ - build procedure for user-manual is fixed not to require locally
+ installed stylesheets.
+
+ - "git commit $paths" on paths whose earlier contents were
+ already updated in the index were failing out.
+
+
+* Tweaks
+
+ - sliding mmap() inefficiently mmaped the same region of a
+ packfile with an access pattern that used objects in the
+ reverse order. This has been made more efficient.
diff --git a/Documentation/RelNotes-1.5.2.1.txt b/Documentation/RelNotes-1.5.2.1.txt
new file mode 100644
index 0000000..ebf20e2
--- /dev/null
+++ b/Documentation/RelNotes-1.5.2.1.txt
@@ -0,0 +1,53 @@
+GIT v1.5.2.1 Release Notes
+==========================
+
+Fixes since v1.5.2
+------------------
+
+* Bugfixes
+
+ - Temporary files that are used when invoking external diff
+ programs did not tolerate a long TMPDIR.
+
+ - git-daemon did not notice when it could not write into its
+ pid file.
+
+ - git-status did not honor core.excludesFile configuration like
+ git-add did.
+
+ - git-annotate did not work from a subdirectory while
+ git-blame did.
+
+ - git-cvsserver should have disabled access to a repository
+ with "gitcvs.pserver.enabled = false" set even when
+ "gitcvs.enabled = true" was set at the same time. It
+ didn't.
+
+ - git-cvsimport did not work correctly in a repository with
+ its branch heads were packed with pack-refs.
+
+ - ident unexpansion to squash "$Id: xxx $" that is in the
+ repository copy removed incorrect number of bytes.
+
+ - git-svn misbehaved when the subversion repository did not
+ provide MD5 checksums for files.
+
+ - git rebase (and git am) misbehaved on commits that have '\n'
+ (literally backslash and en, not a linefeed) in the title.
+
+ - code to decode base85 used in binary patches had one error
+ return codepath wrong.
+
+ - RFC2047 Q encoding output by git-format-patch used '_' for a
+ space, which is not understood by some programs. It uses =20
+ which is safer.
+
+ - git-fastimport --import-marks was broken; fixed.
+
+ - A lot of documentation updates, clarifications and fixes.
+
+--
+exec >/var/tmp/1
+O=v1.5.2-65-g996e2d6
+echo O=`git describe refs/heads/maint`
+git shortlog --no-merges $O..refs/heads/maint
diff --git a/Documentation/RelNotes-1.5.2.2.txt b/Documentation/RelNotes-1.5.2.2.txt
new file mode 100644
index 0000000..f6393f8
--- /dev/null
+++ b/Documentation/RelNotes-1.5.2.2.txt
@@ -0,0 +1,61 @@
+GIT v1.5.2.2 Release Notes
+==========================
+
+Fixes since v1.5.2.1
+--------------------
+
+* Usability fix
+
+ - git-gui is shipped with its updated blame interface. It is
+ rumored that the older one was not just unusable but was
+ active health hazard, but this one is actually pretty.
+ Please see for yourself.
+
+* Bugfixes
+
+ - "git checkout fubar" was utterly confused when there is a
+ branch fubar and a tag fubar at the same time. It correctly
+ checks out the branch fubar now.
+
+ - "git clone /path/foo" to clone a local /path/foo.git
+ repository left an incorrect configuration.
+
+ - "git send-email" correctly unquotes RFC 2047 quoted names in
+ the patch-email before using their values.
+
+ - We did not accept number of seconds since epoch older than
+ year 2000 as a valid timestamp. We now interpret positive
+ integers more than 8 digits as such, which allows us to
+ express timestamps more recent than March 1973.
+
+ - git-cvsimport did not work when you have GIT_DIR to point
+ your repository at a nonstandard location.
+
+ - Some systems (notably, Solaris) lack hstrerror() to make
+ h_errno human readable; prepare a replacement
+ implementation.
+
+ - .gitignore file listed git-core.spec but what we generate is
+ git.spec, and nobody noticed for a long time.
+
+ - "git-merge-recursive" does not try to run file level merge
+ on binary files.
+
+ - "git-branch --track" did not create tracking configuration
+ correctly when the branch name had slash in it.
+
+ - The email address of the user specified with user.email
+ configuration was overriden by EMAIL environment variable.
+
+ - The tree parser did not warn about tree entries with
+ nonsense file modes, and assumed they must be blobs.
+
+ - "git log -z" without any other request to generate diff still
+ invoked the diff machinery, wasting cycles.
+
+* Documentation
+
+ - Many updates to fix stale or missing documentation.
+
+ - Although our documentation was primarily meant to be formatted
+ with AsciiDoc7, formatting with AsciiDoc8 is supported better.
diff --git a/Documentation/RelNotes-1.5.2.3.txt b/Documentation/RelNotes-1.5.2.3.txt
new file mode 100644
index 0000000..addb229
--- /dev/null
+++ b/Documentation/RelNotes-1.5.2.3.txt
@@ -0,0 +1,27 @@
+GIT v1.5.2.3 Release Notes
+==========================
+
+Fixes since v1.5.2.2
+--------------------
+
+ * Bugfixes
+
+ - Version 2 pack index format was introduced in version 1.5.2
+ to support pack files that has offset that cannot be
+ represented in 32-bit. The runtime code to validate such
+ an index mishandled such an index for an empty pack.
+
+ - Commit walkers (most notably, fetch over http protocol)
+ tried to traverse commit objects contained in trees (aka
+ subproject); they shouldn't.
+
+ - A build option NO_R_TO_GCC_LINKER was not explained in Makefile
+ comment correctly.
+
+ * Documentation Fixes and Updates
+
+ - git-config --regexp was not documented properly.
+
+ - git-repack -a was not documented properly.
+
+ - git-remote -n was not documented properly.
diff --git a/Documentation/RelNotes-1.5.2.4.txt b/Documentation/RelNotes-1.5.2.4.txt
new file mode 100644
index 0000000..75cff47
--- /dev/null
+++ b/Documentation/RelNotes-1.5.2.4.txt
@@ -0,0 +1,28 @@
+GIT v1.5.2.4 Release Notes
+==========================
+
+Fixes since v1.5.2.3
+--------------------
+
+ * Bugfixes
+
+ - "git-gui" bugfixes, including a handful fixes to run it
+ better on Cygwin/MSYS.
+
+ - "git checkout" failed to switch back and forth between
+ branches, one of which has "frotz -> xyzzy" symlink and
+ file "xyzzy/filfre", while the other one has a file
+ "frotz/filfre".
+
+ - "git prune" used to segfault upon seeing a commit that is
+ referred to by a tree object (aka "subproject").
+
+ - "git diff --name-status --no-index" mishandled an added file.
+
+ - "git apply --reverse --whitespace=warn" still complained
+ about whitespaces that a forward application would have
+ introduced.
+
+ * Documentation Fixes and Updates
+
+ - A handful documentation updates.
diff --git a/Documentation/RelNotes-1.5.2.5.txt b/Documentation/RelNotes-1.5.2.5.txt
new file mode 100644
index 0000000..e8281c7
--- /dev/null
+++ b/Documentation/RelNotes-1.5.2.5.txt
@@ -0,0 +1,30 @@
+GIT v1.5.2.5 Release Notes
+==========================
+
+Fixes since v1.5.2.4
+--------------------
+
+ * Bugfixes
+
+ - "git add -u" had a serious data corruption problem in one
+ special case (when the changes to a subdirectory's files
+ consist only deletion of files).
+
+ - "git add -u <path>" did not work from a subdirectory.
+
+ - "git apply" left an empty directory after all its files are
+ renamed away.
+
+ - "git $anycmd foo/bar", when there is a file 'foo' in the
+ working tree, complained that "git $anycmd foo/bar --" form
+ should be used to disambiguate between revs and files,
+ which was completely bogus.
+
+ - "git checkout-index" and other commands that checks out
+ files to the work tree tried unlink(2) on directories,
+ which is a sane thing to do on sane systems, but not on
+ Solaris when you are root.
+
+ * Documentation Fixes and Updates
+
+ - A handful documentation fixes.
diff --git a/Documentation/RelNotes-1.5.2.txt b/Documentation/RelNotes-1.5.2.txt
new file mode 100644
index 0000000..6195715
--- /dev/null
+++ b/Documentation/RelNotes-1.5.2.txt
@@ -0,0 +1,197 @@
+GIT v1.5.2 Release Notes
+========================
+
+Updates since v1.5.1
+--------------------
+
+* Plumbing level superproject support.
+
+ You can include a subdirectory that has an independent git
+ repository in your index and tree objects of your project
+ ("superproject"). This plumbing (i.e. "core") level
+ superproject support explicitly excludes recursive behaviour.
+
+ The "subproject" entries in the index and trees of a superproject
+ are incompatible with older versions of git. Experimenting with
+ the plumbing level support is encouraged, but be warned that
+ unless everybody in your project updates to this release or
+ later, using this feature would make your project
+ inaccessible by people with older versions of git.
+
+* Plumbing level gitattributes support.
+
+ The gitattributes mechanism allows you to add 'attributes' to
+ paths in your project, and affect the way certain git
+ operations work. Currently you can influence if a path is
+ considered a binary or text (the former would be treated by
+ 'git diff' not to produce textual output; the latter can go
+ through the line endings conversion process in repositories
+ with core.autocrlf set), expand and unexpand '$Id$' keyword
+ with blob object name, specify a custom 3-way merge driver,
+ and specify a custom diff driver. You can also apply
+ arbitrary filter to contents on check-in/check-out codepath
+ but this feature is an extremely sharp-edged razor and needs
+ to be handled with caution (do not use it unless you
+ understand the earlier mailing list discussion on keyword
+ expansion). These conversions apply when checking files in
+ or out, and exporting via git-archive.
+
+* The packfile format now optionally suports 64-bit index.
+
+ This release supports the "version 2" format of the .idx
+ file. This is automatically enabled when a huge packfile
+ needs more than 32-bit to express offsets of objects in the
+ pack.
+
+* Comes with an updated git-gui 0.7.1
+
+* Updated gitweb:
+
+ - can show combined diff for merges;
+ - uses font size of user's preference, not hardcoded in pixels;
+ - can now 'grep';
+
+* New commands and options.
+
+ - "git bisect start" can optionally take a single bad commit and
+ zero or more good commits on the command line.
+
+ - "git shortlog" can optionally be told to wrap its output.
+
+ - "subtree" merge strategy allows another project to be merged in as
+ your subdirectory.
+
+ - "git format-patch" learned a new --subject-prefix=<string>
+ option, to override the built-in "[PATCH]".
+
+ - "git add -u" is a quick way to do the first stage of "git
+ commit -a" (i.e. update the index to match the working
+ tree); it obviously does not make a commit.
+
+ - "git clean" honors a new configuration, "clean.requireforce". When
+ set to true, this makes "git clean" a no-op, preventing you
+ from losing files by typing "git clean" when you meant to
+ say "make clean". You can still say "git clean -f" to
+ override this.
+
+ - "git log" family of commands learned --date={local,relative,default}
+ option. --date=relative is synonym to the --relative-date.
+ --date=local gives the timestamp in local timezone.
+
+* Updated behavior of existing commands.
+
+ - When $GIT_COMMITTER_EMAIL or $GIT_AUTHOR_EMAIL is not set
+ but $EMAIL is set, the latter is used as a substitute.
+
+ - "git diff --stat" shows size of preimage and postimage blobs
+ for binary contents. Earlier it only said "Bin".
+
+ - "git lost-found" shows stuff that are unreachable except
+ from reflogs.
+
+ - "git checkout branch^0" now detaches HEAD at the tip commit
+ on the named branch, instead of just switching to the
+ branch (use "git checkout branch" to switch to the branch,
+ as before).
+
+ - "git bisect next" can be used after giving only a bad commit
+ without giving a good one (this starts bisection half-way to
+ the root commit). We used to refuse to operate without a
+ good and a bad commit.
+
+ - "git push", when pushing into more than one repository, does
+ not stop at the first error.
+
+ - "git archive" does not insist you to give --format parameter
+ anymore; it defaults to "tar".
+
+ - "git cvsserver" can use backends other than sqlite.
+
+ - "gitview" (in contrib/ section) learned to better support
+ "git-annotate".
+
+ - "git diff $commit1:$path2 $commit2:$path2" can now report
+ mode changes between the two blobs.
+
+ - Local "git fetch" from a repository whose object store is
+ one of the alternates (e.g. fetching from the origin in a
+ repository created with "git clone -l -s") avoids
+ downloading objects unnecessarily.
+
+ - "git blame" uses .mailmap to canonicalize the author name
+ just like "git shortlog" does.
+
+ - "git pack-objects" pays attention to pack.depth
+ configuration variable.
+
+ - "git cherry-pick" and "git revert" does not use .msg file in
+ the working tree to prepare commit message; instead it uses
+ $GIT_DIR/MERGE_MSG as other commands do.
+
+* Builds
+
+ - git-p4import has never been installed; now there is an
+ installation option to do so.
+
+ - gitk and git-gui can be configured out.
+
+ - Generated documentation pages automatically get version
+ information from GIT_VERSION.
+
+ - Parallel build with "make -j" descending into subdirectory
+ was fixed.
+
+* Performance Tweaks
+
+ - Optimized "git-rev-list --bisect" (hence "git-bisect").
+
+ - Optimized "git-add $path" in a large directory, most of
+ whose contents are ignored.
+
+ - Optimized "git-diff-tree" for reduced memory footprint.
+
+ - The recursive merge strategy updated a worktree file that
+ was changed identically in two branches, when one of them
+ renamed it. We do not do that when there is no rename, so
+ match that behaviour. This avoids excessive rebuilds.
+
+ - The default pack depth has been increased to 50, as the
+ recent addition of delta_base_cache makes deeper delta chains
+ much less expensive to access. Depending on the project, it was
+ reported that this reduces the resulting pack file by 10%
+ or so.
+
+
+Fixes since v1.5.1
+------------------
+
+All of the fixes in v1.5.1 maintenance series are included in
+this release, unless otherwise noted.
+
+* Bugfixes
+
+ - Switching branches with "git checkout" refused to work when
+ a path changes from a file to a directory between the
+ current branch and the new branch, in order not to lose
+ possible local changes in the directory that is being turned
+ into a file with the switch. We now allow such a branch
+ switch after making sure that there is no locally modified
+ file nor un-ignored file in the directory. This has not
+ been backported to 1.5.1.x series, as it is rather an
+ intrusive change.
+
+ - Merging branches that have a file in one and a directory in
+ another at the same path used to get quite confused. We
+ handle such a case a bit more carefully, even though that is
+ still left as a conflict for the user to sort out. This
+ will not be backported to 1.5.1.x series, as it is rather an
+ intrusive change.
+
+ - git-fetch had trouble with a remote with insanely large number
+ of refs.
+
+ - "git clean -d -X" now does not remove non-excluded directories.
+
+ - rebasing (without -m) a series that changes a symlink to a directory
+ in the middle of a path confused git-apply greatly and refused to
+ operate.
diff --git a/Documentation/RelNotes-1.5.3.1.txt b/Documentation/RelNotes-1.5.3.1.txt
new file mode 100644
index 0000000..7ff546c
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.1.txt
@@ -0,0 +1,10 @@
+GIT v1.5.3.1 Release Notes
+==========================
+
+Fixes since v1.5.3
+------------------
+
+This is solely to fix the generated RPM's dependencies. We used
+to have git-p4 package but we do not anymore. As suggested on
+the mailing list, this release makes git-core "Obsolete" git-p4,
+so that yum update would not complain.
diff --git a/Documentation/RelNotes-1.5.3.2.txt b/Documentation/RelNotes-1.5.3.2.txt
new file mode 100644
index 0000000..4bbde3c
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.2.txt
@@ -0,0 +1,58 @@
+GIT v1.5.3.2 Release Notes
+==========================
+
+Fixes since v1.5.3.1
+--------------------
+
+ * git-push sent thin packs by default, which was not good for
+ the public distribution server (no point in saving transfer
+ while pushing; no point in making the resulting pack less
+ optimum).
+
+ * git-svn sometimes terminated with "Malformed network data" when
+ talking over svn:// protocol.
+
+ * git-send-email re-issued the same message-id about 10% of the
+ time if you fired off 30 messages within a single second.
+
+ * git-stash was not terminating the log message of commits it
+ internally creates with LF.
+
+ * git-apply failed to check the size of the patch hunk when its
+ beginning part matched the remainder of the preimage exactly,
+ even though the preimage recorded in the hunk was much larger
+ (therefore the patch should not have applied), leading to a
+ segfault.
+
+ * "git rm foo && git commit foo" complained that 'foo' needs to
+ be added first, instead of committing the removal, which was a
+ nonsense.
+
+ * git grep -c said "/dev/null: 0".
+
+ * git-add -u failed to recognize a blob whose type changed
+ between the index and the work tree.
+
+ * The limit to rename detection has been tightened a lot to
+ reduce performance problems with a huge change.
+
+ * cvsimport and svnimport barfed when the input tried to move
+ a tag.
+
+ * "git apply -pN" did not chop the right number of directories.
+
+ * "git svnimport" did not like SVN tags with funny characters in them.
+
+ * git-gui 0.8.3, with assorted fixes, including:
+
+ - font-chooser on X11 was unusable with large number of fonts;
+ - a diff that contained a deleted symlink made it barf;
+ - an untracked symbolic link to a directory made it fart;
+ - a file with % in its name made it vomit;
+
+
+Documentation updates
+---------------------
+
+User manual has been somewhat restructured. I think the new
+organization is much easier to read.
diff --git a/Documentation/RelNotes-1.5.3.3.txt b/Documentation/RelNotes-1.5.3.3.txt
new file mode 100644
index 0000000..d213846
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.3.txt
@@ -0,0 +1,31 @@
+GIT v1.5.3.3 Release Notes
+==========================
+
+Fixes since v1.5.3.2
+--------------------
+
+ * git-quiltimport did not like it when a patch described in the
+ series file does not exist.
+
+ * p4 importer missed executable bit in some cases.
+
+ * The default shell on some FreeBSD did not execute the
+ argument parsing code correctly and made git unusable.
+
+ * git-svn incorrectly spawned pager even when the user
+ explicitly asked not to.
+
+ * sample post-receive hook overquoted the envelope sender
+ value.
+
+ * git-am got confused when the patch contained a change that is
+ only about type and not contents.
+
+ * git-mergetool did not show our and their version of the
+ conflicted file when started from a subdirectory of the
+ project.
+
+ * git-mergetool did not pass correct options when invoking diff3.
+
+ * git-log sometimes invoked underlying "diff" machinery
+ unnecessarily.
diff --git a/Documentation/RelNotes-1.5.3.4.txt b/Documentation/RelNotes-1.5.3.4.txt
new file mode 100644
index 0000000..b04b3a4
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.4.txt
@@ -0,0 +1,35 @@
+GIT v1.5.3.4 Release Notes
+==========================
+
+Fixes since v1.5.3.3
+--------------------
+
+ * Change to "git-ls-files" in v1.5.3.3 that was introduced to support
+ partial commit of removal better had a segfaulting bug, which was
+ diagnosed and fixed by Keith and Carl.
+
+ * Performance improvements for rename detection has been backported
+ from the 'master' branch.
+
+ * "git-for-each-ref --format='%(numparent)'" was not working
+ correctly at all, and --format='%(parent)' was not working for
+ merge commits.
+
+ * Sample "post-receive-hook" incorrectly sent out push
+ notification e-mails marked as "From: " the committer of the
+ commit that happened to be at the tip of the branch that was
+ pushed, not from the person who pushed.
+
+ * "git-remote" did not exit non-zero status upon error.
+
+ * "git-add -i" did not respond very well to EOF from tty nor
+ bogus input.
+
+ * "git-rebase -i" squash subcommand incorrectly made the
+ author of later commit the author of resulting commit,
+ instead of taking from the first one in the squashed series.
+
+ * "git-stash apply --index" was not documented.
+
+ * autoconfiguration learned that "ar" command is found as "gas" on
+ some systems.
diff --git a/Documentation/RelNotes-1.5.3.5.txt b/Documentation/RelNotes-1.5.3.5.txt
new file mode 100644
index 0000000..7ff1d5d
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.5.txt
@@ -0,0 +1,94 @@
+GIT v1.5.3.5 Release Notes
+==========================
+
+Fixes since v1.5.3.4
+--------------------
+
+ * Comes with git-gui 0.8.4.
+
+ * "git-config" silently ignored options after --list; now it will
+ error out with a usage message.
+
+ * "git-config --file" failed if the argument used a relative path
+ as it changed directories before opening the file.
+
+ * "git-config --file" now displays a proper error message if it
+ cannot read the file specified on the command line.
+
+ * "git-config", "git-diff", "git-apply" failed if run from a
+ subdirectory with relative GIT_DIR and GIT_WORK_TREE set.
+
+ * "git-blame" crashed if run during a merge conflict.
+
+ * "git-add -i" did not handle single line hunks correctly.
+
+ * "git-rebase -i" and "git-stash apply" failed if external diff
+ drivers were used for one or more files in a commit. They now
+ avoid calling the external diff drivers.
+
+ * "git-log --follow" did not work unless diff generation (e.g. -p)
+ was also requested.
+
+ * "git-log --follow -B" did not work at all. Fixed.
+
+ * "git-log -M -B" did not correctly handle cases of very large files
+ being renamed and replaced by very small files in the same commit.
+
+ * "git-log" printed extra newlines between commits when a diff
+ was generated internally (e.g. -S or --follow) but not displayed.
+
+ * "git-push" error message is more helpful when pushing to a
+ repository with no matching refs and none specified.
+
+ * "git-push" now respects + (force push) on wildcard refspecs,
+ matching the behavior of git-fetch.
+
+ * "git-filter-branch" now updates the working directory when it
+ has finished filtering the current branch.
+
+ * "git-instaweb" no longer fails on Mac OS X.
+
+ * "git-cvsexportcommit" didn't always create new parent directories
+ before trying to create new child directories. Fixed.
+
+ * "git-fetch" printed a scary (but bogus) error message while
+ fetching a tag that pointed to a tree or blob. The error did
+ not impact correctness, only user perception. The bogus error
+ is no longer printed.
+
+ * "git-ls-files --ignored" did not properly descend into non-ignored
+ directories that themselves contained ignored files if d_type
+ was not supported by the filesystem. This bug impacted systems
+ such as AFS. Fixed.
+
+ * Git segfaulted when reading an invalid .gitattributes file. Fixed.
+
+ * post-receive-email example hook was fixed for non-fast-forward
+ updates.
+
+ * Documentation updates for supported (but previously undocumented)
+ options of "git-archive" and "git-reflog".
+
+ * "make clean" no longer deletes the configure script that ships
+ with the git tarball, making multiple architecture builds easier.
+
+ * "git-remote show origin" spewed a warning message from Perl
+ when no remote is defined for the current branch via
+ branch.<name>.remote configuration settings.
+
+ * Building with NO_PERL_MAKEMAKER excessively rebuilt contents
+ of perl/ subdirectory by rewriting perl.mak.
+
+ * http.sslVerify configuration settings were not used in scripted
+ Porcelains.
+
+ * "git-add" leaked a bit of memory while scanning for files to add.
+
+ * A few workarounds to squelch false warnings from recent gcc have
+ been added.
+
+ * "git-send-pack $remote frotz" segfaulted when there is nothing
+ named 'frotz' on the local end.
+
+ * "git-rebase --interactive" did not handle its "--strategy" option
+ properly.
diff --git a/Documentation/RelNotes-1.5.3.6.txt b/Documentation/RelNotes-1.5.3.6.txt
new file mode 100644
index 0000000..069a2b2
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.6.txt
@@ -0,0 +1,48 @@
+GIT v1.5.3.6 Release Notes
+==========================
+
+Fixes since v1.5.3.5
+--------------------
+
+ * git-cvsexportcommit handles root commits better.
+
+ * git-svn dcommit used to clobber when sending a series of
+ patches.
+
+ * git-svn dcommit failed after attempting to rebase when
+ started with a dirty index; now it stops upfront.
+
+ * git-grep sometimes refused to work when your index was
+ unmerged.
+
+ * "git-grep -A1 -B2" acted as if it was told to run "git -A1 -B21".
+
+ * git-hash-object did not honor configuration variables, such as
+ core.compression.
+
+ * git-index-pack choked on a huge pack on 32-bit machines, even when
+ large file offsets are supported.
+
+ * atom feeds from git-web said "10" for the month of November.
+
+ * a memory leak in commit walker was plugged.
+
+ * When git-send-email inserted the original author's From:
+ address in body, it did not mark the message with
+ Content-type: as needed.
+
+ * git-revert and git-cherry-pick incorrectly refused to start
+ when the work tree was dirty.
+
+ * git-clean did not honor core.excludesfile configuration.
+
+ * git-add mishandled ".gitignore" files when applying them to
+ subdirectories.
+
+ * While importing a too branchy history, git-fastimport did not
+ honor delta depth limit properly.
+
+ * Support for zlib implementations that lack ZLIB_VERNUM and definition
+ of deflateBound() has been added.
+
+ * Quite a lot of documentation clarifications.
diff --git a/Documentation/RelNotes-1.5.3.7.txt b/Documentation/RelNotes-1.5.3.7.txt
new file mode 100644
index 0000000..2f69061
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.7.txt
@@ -0,0 +1,45 @@
+GIT v1.5.3.7 Release Notes
+==========================
+
+Fixes since v1.5.3.6
+--------------------
+
+ * git-send-email added 8-bit contents to the payload without
+ marking it as 8-bit in a CTE header.
+
+ * "git-bundle create a.bndl HEAD" dereferenced the symref and
+ did not record the ref as 'HEAD'; this prevented a bundle
+ from being used as a normal source of git-clone.
+
+ * The code to reject nonsense command line of the form
+ "git-commit -a paths..." and "git-commit --interactive
+ paths..." were broken.
+
+ * Adding a signature that is not ASCII-only to an original
+ commit that is ASCII-only would make the result non-ASCII.
+ "git-format-patch -s" did not mark such a message correctly
+ with MIME encoding header.
+
+ * git-add sometimes did not mark the resulting index entry
+ stat-clean. This affected only cases when adding the
+ contents with the same length as the previously staged
+ contents, and the previous staging made the index entry
+ "racily clean".
+
+ * git-commit did not honor GIT_INDEX_FILE the user had in the
+ environment.
+
+ * When checking out a revision, git-checkout did not report where the
+ updated HEAD is if you happened to have a file called HEAD in the
+ work tree.
+
+ * "git-rev-list --objects" mishandled a tree that points at a
+ submodule.
+
+ * "git cvsimport" was not ready for packed refs that "git gc" can
+ produce and gave incorrect results.
+
+ * Many scripted Porcelains were confused when you happened to have a
+ file called "HEAD" in your work tree.
+
+Also it contains updates to the user manual and documentation.
diff --git a/Documentation/RelNotes-1.5.3.8.txt b/Documentation/RelNotes-1.5.3.8.txt
new file mode 100644
index 0000000..0e3ff58
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.8.txt
@@ -0,0 +1,25 @@
+GIT v1.5.3.8 Release Notes
+==========================
+
+Fixes since v1.5.3.7
+--------------------
+
+ * Some documentation used "email.com" as an example domain.
+
+ * git-svn fix to handle funky branch and project names going over
+ http/https correctly.
+
+ * git-svn fix to tone down a needlessly alarming warning message.
+
+ * git-clone did not correctly report errors while fetching over http.
+
+ * git-send-email added redundant Message-Id: header to the outgoing
+ e-mail when the patch text already had one.
+
+ * a read-beyond-end-of-buffer bug in configuration file updater was fixed.
+
+ * git-grep used to show the same hit repeatedly for unmerged paths.
+
+ * After amending the patch title in "git-am -i", the command did not
+ report the patch it applied with the updated title.
+
diff --git a/Documentation/RelNotes-1.5.3.txt b/Documentation/RelNotes-1.5.3.txt
new file mode 100644
index 0000000..d03894b
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.txt
@@ -0,0 +1,366 @@
+GIT v1.5.3 Release Notes
+========================
+
+Updates since v1.5.2
+--------------------
+
+* The commit walkers other than http are officially deprecated,
+ but still supported for now.
+
+* The submodule support has Porcelain layer.
+
+ Note that the current submodule support is minimal and this is
+ deliberately so. A design decision we made is that operations
+ at the supermodule level do not recurse into submodules by
+ default. The expectation is that later we would add a
+ mechanism to tell git which submodules the user is interested
+ in, and this information might be used to determine the
+ recursive behaviour of certain commands (e.g. "git checkout"
+ and "git diff"), but currently we haven't agreed on what that
+ mechanism should look like. Therefore, if you use submodules,
+ you would probably need "git submodule update" on the
+ submodules you care about after running a "git checkout" at
+ the supermodule level.
+
+* There are a handful pack-objects changes to help you cope better
+ with repositories with pathologically large blobs in them.
+
+* For people who need to import from Perforce, a front-end for
+ fast-import is in contrib/fast-import/.
+
+* Comes with git-gui 0.8.2.
+
+* Comes with updated gitk.
+
+* New commands and options.
+
+ - "git log --date=<format>" can use more formats: iso8601, rfc2822.
+
+ - The hunk header output from "git diff" family can be customized
+ with the attributes mechanism. See gitattributes(5) for details.
+
+ - "git stash" allows you to quickly save away your work in
+ progress and replay it later on an updated state.
+
+ - "git rebase" learned an "interactive" mode that let you
+ pick and reorder which commits to rebuild.
+
+ - "git fsck" can save its findings in $GIT_DIR/lost-found, without a
+ separate invocation of "git lost-found" command. The blobs stored by
+ lost-found are stored in plain format to allow you to grep in them.
+
+ - $GIT_WORK_TREE environment variable can be used together with
+ $GIT_DIR to work in a subdirectory of a working tree that is
+ not located at "$GIT_DIR/..".
+
+ - Giving "--file=<file>" option to "git config" is the same as
+ running the command with GIT_CONFIG=<file> environment.
+
+ - "git log" learned a new option "--follow", to follow
+ renaming history of a single file.
+
+ - "git filter-branch" lets you rewrite the revision history of
+ specified branches. You can specify a number of filters to
+ modify the commits, files and trees.
+
+ - "git cvsserver" learned new options (--base-path, --export-all,
+ --strict-paths) inspired by "git daemon".
+
+ - "git daemon --base-path-relaxed" can help migrating a repository URL
+ that did not use to use --base-path to use --base-path.
+
+ - "git commit" can use "-t templatefile" option and commit.template
+ configuration variable to prime the commit message given to you in the
+ editor.
+
+ - "git submodule" command helps you manage the projects from
+ the superproject that contain them.
+
+ - In addition to core.compression configuration option,
+ core.loosecompression and pack.compression options can
+ independently tweak zlib compression levels used for loose
+ and packed objects.
+
+ - "git ls-tree -l" shows size of blobs pointed at by the
+ tree entries, similar to "/bin/ls -l".
+
+ - "git rev-list" learned --regexp-ignore-case and
+ --extended-regexp options to tweak its matching logic used
+ for --grep fitering.
+
+ - "git describe --contains" is a handier way to call more
+ obscure command "git name-rev --tags".
+
+ - "git gc --aggressive" tells the command to spend more cycles
+ to optimize the repository harder.
+
+ - "git repack" learned a "window-memory" limit which
+ dynamically reduces the window size to stay within the
+ specified memory usage.
+
+ - "git repack" can be told to split resulting packs to avoid
+ exceeding limit specified with "--max-pack-size".
+
+ - "git fsck" gained --verbose option. This is really really
+ verbose but it might help you identify exact commit that is
+ corrupt in your repository.
+
+ - "git format-patch" learned --numbered-files option. This
+ may be useful for MH users.
+
+ - "git format-patch" learned format.subjectprefix configuration
+ variable, which serves the same purpose as "--subject-prefix"
+ option.
+
+ - "git tag -n -l" shows tag annotations while listing tags.
+
+ - "git cvsimport" can optionally use the separate-remote layout.
+
+ - "git blame" can be told to see through commits that change
+ whitespaces and indentation levels with "-w" option.
+
+ - "git send-email" can be told not to thread the messages when
+ sending out more than one patches.
+
+ - "git send-email" can also be told how to find whom to cc the
+ message to for each message via --cc-cmd.
+
+ - "git config" learned NUL terminated output format via -z to
+ help scripts.
+
+ - "git add" learned "--refresh <paths>..." option to selectively refresh
+ the cached stat information.
+
+ - "git init -q" makes the command quieter.
+
+ - "git -p command" now has a cousin of opposite sex, "git --no-pager
+ command".
+
+* Updated behavior of existing commands.
+
+ - "gitweb" can offer multiple snapshot formats.
+
+ ***NOTE*** Unfortunately, this changes the format of the
+ $feature{snapshot}{default} entry in the per-site
+ configuration file 'gitweb_config.perl'. It used to be a
+ three-element tuple that describe a single format; with the
+ new configuration item format, you only have to say the name
+ of the format ('tgz', 'tbz2' or 'zip'). Please update the
+ your configuration file accordingly.
+
+ - "git clone" uses -l (hardlink files under .git) by default when
+ cloning locally.
+
+ - URL used for "git clone" and friends can specify nonstandard SSH port
+ by using ssh://host:port/path/to/repo syntax.
+
+ - "git bundle create" can now create a bundle without negative refs,
+ i.e. "everything since the beginning up to certain points".
+
+ - "git diff" (but not the plumbing level "git diff-tree") now
+ recursively descends into trees by default.
+
+ - "git diff" does not show differences that come only from
+ stat-dirtiness in the form of "diff --git" header anymore.
+ It runs "update-index --refresh" silently as needed.
+
+ - "git tag -l" used to match tags by globbing its parameter as if it
+ has wildcard '*' on both ends, which made "git tag -l gui" to match
+ tag 'gitgui-0.7.0'; this was very annoying. You now have to add
+ asterisk on the sides you want to wildcard yourself.
+
+ - The editor to use with many interactive commands can be
+ overridden with GIT_EDITOR environment variable, or if it
+ does not exist, with core.editor configuration variable. As
+ before, if you have neither, environment variables VISUAL
+ and EDITOR are consulted in this order, and then finally we
+ fall back on "vi".
+
+ - "git rm --cached" does not complain when removing a newly
+ added file from the index anymore.
+
+ - Options to "git log" to affect how --grep/--author options look for
+ given strings now have shorter abbreviations. -i is for ignore case,
+ and -E is for extended regexp.
+
+ - "git log" learned --log-size to show the number of bytes in
+ the log message part of the output to help qgit.
+
+ - "git log --name-status" does not require you to give "-r" anymore.
+ As a general rule, Porcelain commands should recurse when showing
+ diff.
+
+ - "git format-patch --root A" can be used to format everything
+ since the beginning up to A. This was supported with
+ "git format-patch --root A A" for a long time, but was not
+ properly documented.
+
+ - "git svn dcommit" retains local merge information.
+
+ - "git svnimport" allows an empty string to be specified as the
+ trunk/ directory. This is necessary to suck data from a SVN
+ repository that doe not have trunk/ branches/ and tags/ organization
+ at all.
+
+ - "git config" to set values also honors type flags like --bool
+ and --int.
+
+ - core.quotepath configuration can be used to make textual git
+ output to emit most of the characters in the path literally.
+
+ - "git mergetool" chooses its backend more wisely, taking
+ notice of its environment such as use of X, Gnome/KDE, etc.
+
+ - "gitweb" shows merge commits a lot nicer than before. The
+ default view uses more compact --cc format, while the UI
+ allows to choose normal diff with any parent.
+
+ - snapshot files "gitweb" creates from a repository at
+ $path/$project/.git are more useful. We use $project part
+ in the filename, which we used to discard.
+
+ - "git cvsimport" creates lightweight tags; there is no
+ interesting information we can record in an annotated tag,
+ and the handcrafted ones the old code created was not
+ properly formed anyway.
+
+ - "git push" pretends that you immediately fetched back from
+ the remote by updating corresponding remote tracking
+ branches if you have any.
+
+ - The diffstat given after a merge (or a pull) honors the
+ color.diff configuration.
+
+ - "git commit --amend" is now compatible with various message source
+ options such as -m/-C/-c/-F.
+
+ - "git apply --whitespace=strip" removes blank lines added at
+ the end of the file.
+
+ - "git fetch" over git native protocols with "-v" option shows
+ connection status, and the IP address of the other end, to
+ help diagnosing problems.
+
+ - We used to have core.legacyheaders configuration, when
+ set to false, allowed git to write loose objects in a format
+ that mimicks the format used by objects stored in packs. It
+ turns out that this was not so useful. Although we will
+ continue to read objects written in that format, we do not
+ honor that configuration anymore and create loose objects in
+ the legacy/traditional format.
+
+ - "--find-copies-harder" option to diff family can now be
+ spelled as "-C -C" for brevity.
+
+ - "git mailsplit" (hence "git am") can read from Maildir
+ formatted mailboxes.
+
+ - "git cvsserver" does not barf upon seeing "cvs login"
+ request.
+
+ - "pack-objects" honors "delta" attribute set in
+ .gitattributes. It does not attempt to deltify blobs that
+ come from paths with delta attribute set to false.
+
+ - "new-workdir" script (in contrib) can now be used with a
+ bare repository.
+
+ - "git mergetool" learned to use gvimdiff.
+
+ - "gitview" (in contrib) has a better blame interface.
+
+ - "git log" and friends did not handle a commit log message
+ that is larger than 16kB; they do now.
+
+ - "--pretty=oneline" output format for "git log" and friends
+ deals with "malformed" commit log messages that have more
+ than one lines in the first paragraph better. We used to
+ show the first line, cutting the title at mid-sentence; we
+ concatenate them into a single line and treat the result as
+ "oneline".
+
+ - "git p4import" has been demoted to contrib status. For
+ a superior option, checkout the "git p4" front end to
+ "git fast-import" (also in contrib). The man page and p4
+ rpm have been removed as well.
+
+ - "git mailinfo" (hence "am") now tries to see if the message
+ is in utf-8 first, instead of assuming iso-8859-1, if
+ incoming e-mail does not say what encoding it is in.
+
+* Builds
+
+ - old-style function definitions (most notably, a function
+ without parameter defined with "func()", not "func(void)")
+ have been eradicated.
+
+ - "git tag" and "git verify-tag" have been rewritten in C.
+
+* Performance Tweaks
+
+ - "git pack-objects" avoids re-deltification cost by caching
+ small enough delta results it creates while looking for the
+ best delta candidates.
+
+ - "git pack-objects" learned a new heuristcs to prefer delta
+ that is shallower in depth over the smallest delta
+ possible. This improves both overall packfile access
+ performance and packfile density.
+
+ - diff-delta code that is used for packing has been improved
+ to work better on big files.
+
+ - when there are more than one pack files in the repository,
+ the runtime used to try finding an object always from the
+ newest packfile; it now tries the same packfile as we found
+ the object requested the last time, which exploits the
+ locality of references.
+
+ - verifying pack contents done by "git fsck --full" got boost
+ by carefully choosing the order to verify objects in them.
+
+ - "git read-tree -m" to read into an already populated index
+ has been optimized vastly. The effect of this can be seen
+ when switching branches that have differences in only a
+ handful paths.
+
+ - "git add paths..." and "git commit paths..." has also been
+ heavily optimized.
+
+Fixes since v1.5.2
+------------------
+
+All of the fixes in v1.5.2 maintenance series are included in
+this release, unless otherwise noted.
+
+* Bugfixes
+
+ - "gitweb" had trouble handling non UTF-8 text with older
+ Encode.pm Perl module.
+
+ - "git svn" misparsed the data from the commits in the repository when
+ the user had "color.diff = true" in the configuration. This has been
+ fixed.
+
+ - There was a case where "git svn dcommit" clobbered changes made on the
+ SVN side while committing multiple changes.
+
+ - "git-write-tree" had a bad interaction with racy-git avoidance and
+ gitattributes mechanisms.
+
+ - "git --bare command" overrode existing GIT_DIR setting and always
+ made it treat the current working directory as GIT_DIR.
+
+ - "git ls-files --error-unmatch" does not complain if you give the
+ same path pattern twice by mistake.
+
+ - "git init" autodetected core.filemode but not core.symlinks, which
+ made a new directory created automatically by "git clone" cumbersome
+ to use on filesystems that require these configurations to be set.
+
+ - "git log" family of commands behaved differently when run as "git
+ log" (no pathspec) and as "git log --" (again, no pathspec). This
+ inconsistency was introduced somewhere in v1.3.0 series but now has
+ been corrected.
+
+ - "git rebase -m" incorrectly displayed commits that were skipped.
diff --git a/Documentation/RelNotes-1.5.4.1.txt b/Documentation/RelNotes-1.5.4.1.txt
new file mode 100644
index 0000000..d4e44b8
--- /dev/null
+++ b/Documentation/RelNotes-1.5.4.1.txt
@@ -0,0 +1,17 @@
+GIT v1.5.4.1 Release Notes
+==========================
+
+Fixes since v1.5.4
+------------------
+
+ * "git-commit -C $tag" used to work but rewrite in C done in
+ 1.5.4 broke it.
+
+ * An entry in the .gitattributes file that names a pattern in a
+ subdirectory of the directory it is in did not match
+ correctly (e.g. pattern "b/*.c" in "a/.gitattributes" should
+ match "a/b/foo.c" but it didn't).
+
+ * Customized color specification was parsed incorrectly when
+ numeric color values are used. This was fixed in 1.5.4.1.
+
diff --git a/Documentation/RelNotes-1.5.4.2.txt b/Documentation/RelNotes-1.5.4.2.txt
new file mode 100644
index 0000000..21d0df5
--- /dev/null
+++ b/Documentation/RelNotes-1.5.4.2.txt
@@ -0,0 +1,43 @@
+GIT v1.5.4.2 Release Notes
+==========================
+
+Fixes since v1.5.4
+------------------
+
+ * The configuration parser was not prepared to see string
+ valued variables misspelled as boolean and segfaulted.
+
+ * Temporary files left behind due to interrupted object
+ transfers were not cleaned up with "git prune".
+
+ * "git config --unset" was confused when the unset variables
+ were spelled with continuation lines in the config file.
+
+ * The merge message detection in "git cvsimport" did not catch
+ a message that began with "Merge...".
+
+ * "git status" suggests "git rm --cached" for unstaging the
+ earlier "git add" before the initial commit.
+
+ * "git status" output was incorrect during a partial commit.
+
+ * "git bisect" refused to start when the HEAD was detached.
+
+ * "git bisect" allowed a wildcard character in the commit
+ message expanded while writing its log file.
+
+ * Manual pages were not formatted correctly with docbook xsl
+ 1.72; added a workaround.
+
+ * "git-commit -C $tag" used to work but rewrite in C done in
+ 1.5.4 broke it. This was fixed in 1.5.4.1.
+
+ * An entry in the .gitattributes file that names a pattern in a
+ subdirectory of the directory it is in did not match
+ correctly (e.g. pattern "b/*.c" in "a/.gitattributes" should
+ match "a/b/foo.c" but it didn't). This was fixed in 1.5.4.1.
+
+ * Customized color specification was parsed incorrectly when
+ numeric color values are used. This was fixed in 1.5.4.1.
+
+ * http transport misbehaved when linked with curl-gnutls.
diff --git a/Documentation/RelNotes-1.5.4.3.txt b/Documentation/RelNotes-1.5.4.3.txt
new file mode 100644
index 0000000..b0fc67f
--- /dev/null
+++ b/Documentation/RelNotes-1.5.4.3.txt
@@ -0,0 +1,27 @@
+GIT v1.5.4.3 Release Notes
+==========================
+
+Fixes since v1.5.4.2
+--------------------
+
+ * RPM spec used to pull in everything with 'git'. This has been
+ changed so that 'git' package contains just the core parts,
+ and we now supply 'git-all' metapackage to slurp in everything.
+ This should match end user's expectation better.
+
+ * When some refs failed to update, git-push reported "failure"
+ which was unclear if some other refs were updated or all of
+ them failed atomically (the answer is the former). Reworded
+ the message to clarify this.
+
+ * "git clone" from a repository whose HEAD was misconfigured
+ did not set up the remote properly. Now it tries to do
+ better.
+
+ * Updated git-push documentation to clarify what "matching"
+ means, in order to reduce user confusion.
+
+ * Updated git-add documentation to clarify "add -u" operates in
+ the current subdirectory you are in, just like other commands.
+
+ * git-gui updates to work on OSX and Windows better.
diff --git a/Documentation/RelNotes-1.5.4.4.txt b/Documentation/RelNotes-1.5.4.4.txt
new file mode 100644
index 0000000..5635977
--- /dev/null
+++ b/Documentation/RelNotes-1.5.4.4.txt
@@ -0,0 +1,46 @@
+GIT v1.5.4.4 Release Notes
+==========================
+
+Fixes since v1.5.4.3
+--------------------
+
+ * Building and installing with an overtight umask such as 077 made
+ installed templates unreadable by others, while the rest of the install
+ are done in a way that is friendly to umask 022.
+
+ * "git cvsexportcommit -w $cvsdir" misbehaved when GIT_DIR is set to a
+ relative directory.
+
+ * "git http-push" had an invalid memory access that could lead it to
+ segfault.
+
+ * When "git rebase -i" gave control back to the user for a commit that is
+ marked to be edited, it just said "modify it with commit --amend",
+ without saying what to do to continue after modifying it. Give an
+ explicit instruction to run "rebase --continue" to be more helpful.
+
+ * "git send-email" in 1.5.4.3 issued a bogus empty In-Reply-To: header.
+
+ * "git bisect" showed mysterious "won't bisect on seeked tree" error message.
+ This was leftover from Cogito days to prevent "bisect" starting from a
+ cg-seeked state. We still keep the Cogito safety, but running "git bisect
+ start" when another bisect was in effect will clean up and start over.
+
+ * "git push" with an explicit PATH to receive-pack did not quite work if
+ receive-pack was not on usual PATH. We earlier fixed the same issue
+ with "git fetch" and upload-pack, but somehow forgot to do so in the
+ other direction.
+
+ * git-gui's info dialog was not displayed correctly when the user tries
+ to commit nothing (i.e. without staging anything).
+
+ * "git revert" did not properly fail when attempting to run with a
+ dirty index.
+
+Also included are a handful documentation updates.
+
+---
+exec >/var/tmp/1
+echo O=$(git describe maint)
+O=v1.5.4.3-32-g0f2d447
+git shortlog --no-merges $O..maint
diff --git a/Documentation/RelNotes-1.5.4.txt b/Documentation/RelNotes-1.5.4.txt
new file mode 100644
index 0000000..f1323b6
--- /dev/null
+++ b/Documentation/RelNotes-1.5.4.txt
@@ -0,0 +1,377 @@
+GIT v1.5.4 Release Notes
+========================
+
+Removal
+-------
+
+ * "git svnimport" was removed in favor of "git svn". It is still there
+ in the source tree (contrib/examples) but unsupported.
+
+ * As git-commit and git-status have been rewritten, "git runstatus"
+ helper script lost all its users and has been removed.
+
+
+Temporarily disabled
+--------------------
+
+ * "git http-push" is known not to work well with cURL library older
+ than 7.16, and we had reports of repository corruption. It is
+ disabled on such platforms for now. Unfortunately, 1.5.3.8 shares
+ the same issue. In other words, this does not mean you will be
+ fine if you stick to an older git release. For now, please do not
+ use http-push from older git with cURL older than 7.16 if you
+ value your data. A proper fix will hopefully materialize in
+ later versions.
+
+
+Deprecation notices
+-------------------
+
+ * From v1.6.0, git will by default install dashed form of commands
+ (e.g. "git-commit") outside of users' normal $PATH, and will install
+ only selected commands ("git" itself, and "gitk") in $PATH. This
+ implies:
+
+ - Using dashed forms of git commands (e.g. "git-commit") from the
+ command line has been informally deprecated since early 2006, but
+ now it officially is, and will be removed in the future. Use
+ dash-less forms (e.g. "git commit") instead.
+
+ - Using dashed forms from your scripts, without first prepending the
+ return value from "git --exec-path" to the scripts' PATH, has been
+ informally deprecated since early 2006, but now it officially is.
+
+ - Use of dashed forms with "PATH=$(git --exec-path):$PATH; export
+ PATH" early in your script is not deprecated with this change.
+
+ Users are strongly encouraged to adjust their habits and scripts now
+ to prepare for this change.
+
+ * The post-receive hook was introduced in March 2007 to supersede
+ the post-update hook, primarily to overcome the command line length
+ limitation of the latter. Use of post-update hook will be deprecated
+ in future versions of git, starting from v1.6.0.
+
+ * "git lost-found" was deprecated in favor of "git fsck"'s --lost-found
+ option, and will be removed in the future.
+
+ * "git peek-remote" is deprecated, as "git ls-remote" was written in C
+ and works for all transports; "git peek-remote" will be removed in
+ the future.
+
+ * "git repo-config" which was an old name for "git config" command
+ has been supported without being advertised for a long time. The
+ next feature release will remove it.
+
+ * From v1.6.0, the repack.usedeltabaseoffset config option will default
+ to true, which will give denser packfiles (i.e. more efficient storage).
+ The downside is that git older than version 1.4.4 will not be able
+ to directly use a repository packed using this setting.
+
+ * From v1.6.0, the pack.indexversion config option will default to 2,
+ which is slightly more efficient, and makes repacking more immune to
+ data corruptions. Git older than version 1.5.2 may revert to version 1
+ of the pack index with a manual "git index-pack" to be able to directly
+ access corresponding pack files.
+
+
+Updates since v1.5.3
+--------------------
+
+ * Comes with much improved gitk, with i18n.
+
+ * Comes with git-gui 0.9.2 with i18n.
+
+ * gitk is now merged as a subdirectory of git.git project, in
+ preparation for its i18n.
+
+ * progress displays from many commands are a lot nicer to the eye.
+ Transfer commands show throughput data.
+
+ * many commands that pay attention to per-directory .gitignore now do
+ so lazily, which makes the usual case go much faster.
+
+ * Output processing for '--pretty=format:<user format>' has been
+ optimized.
+
+ * Rename detection of diff family while detecting exact matches has
+ been greatly optimized.
+
+ * Rename detection of diff family tries to make more natural looking
+ pairing. Earlier, if multiple identical rename sources were
+ found in the preimage, the source used was picked pretty much at random.
+
+ * Value "true" for color.diff and color.status configuration used to
+ mean "always" (even when the output is not going to a terminal).
+ This has been corrected to mean the same thing as "auto".
+
+ * "git diff" Porcelain now respects diff.external configuration, which
+ is another way to specify GIT_EXTERNAL_DIFF.
+
+ * "git diff" can be told to use different prefixes other than
+ "a/" and "b/" e.g. "git diff --src-prefix=l/ --dst-prefix=k/".
+
+ * "git diff" sometimes did not quote paths with funny
+ characters properly.
+
+ * "git log" (and any revision traversal commands) misbehaved
+ when --diff-filter is given but was not asked to actually
+ produce diff.
+
+ * HTTP proxy can be specified per remote repository using
+ remote.*.httpproxy configuration, or global http.proxy configuration
+ variable.
+
+ * Various Perforce importer updates.
+
+ * Example update and post-receive hooks have been improved.
+
+ * Any command that wants to take a commit object name can now use
+ ":/string" syntax to name a commit.
+
+ * "git reset" is now built-in and its output can be squelched with -q.
+
+ * "git reset --hard" does not make any sense in a bare
+ repository, but did not error out; fixed.
+
+ * "git send-email" can optionally talk over ssmtp and use SMTP-AUTH.
+
+ * "git rebase" learned --whitespace option.
+
+ * In "git rebase", when you decide not to replay a particular change
+ after the command stopped with a conflict, you can say "git rebase
+ --skip" without first running "git reset --hard", as the command now
+ runs it for you.
+
+ * "git rebase --interactive" mode can now work on detached HEAD.
+
+ * Other minor to serious bugs in "git rebase -i" have been fixed.
+
+ * "git rebase" now detaches head during its operation, so after a
+ successful "git rebase" operation, the reflog entry branch@{1} for
+ the current branch points at the commit before the rebase was
+ started.
+
+ * "git rebase -i" also triggers rerere to help your repeated merges.
+
+ * "git merge" can call the "post-merge" hook.
+
+ * "git pack-objects" can optionally run deltification with multiple
+ threads.
+
+ * "git archive" can optionally substitute keywords in files marked with
+ export-subst attribute.
+
+ * "git cherry-pick" made a misguided attempt to repeat the original
+ command line in the generated log message, when told to cherry-pick a
+ commit by naming a tag that points at it. It does not anymore.
+
+ * "git for-each-ref" learned %(xxxdate:<date-format>) syntax to show the
+ various date fields in different formats.
+
+ * "git gc --auto" is a low-impact way to automatically run a variant of
+ "git repack" that does not lose unreferenced objects (read: safer
+ than the usual one) after the user accumulates too many loose
+ objects.
+
+ * "git clean" has been rewritten in C.
+
+ * You need to explicitly set clean.requireForce to "false" to allow
+ "git clean" without -f to do any damage (lack of the configuration
+ variable used to mean "do not require -f option to lose untracked
+ files", but we now use the safer default).
+
+ * The kinds of whitespace errors "git diff" and "git apply" notice (and
+ fix) can be controlled via 'core.whitespace' configuration variable
+ and 'whitespace' attribute in .gitattributes file.
+
+ * "git push" learned --dry-run option to show what would happen if a
+ push is run.
+
+ * "git push" does not update a tracking ref on the local side when the
+ remote refused to update the corresponding ref.
+
+ * "git push" learned --mirror option. This is to push the local refs
+ one-to-one to the remote, and deletes refs from the remote that do
+ not exist anymore in the repository on the pushing side.
+
+ * "git push" can remove a corrupt ref at the remote site with the usual
+ ":ref" refspec.
+
+ * "git remote" knows --mirror mode. This is to set up configuration to
+ push into a remote repository to store local branch heads to the same
+ branch on the remote side, and remove branch heads locally removed
+ from local repository at the same time. Suitable for pushing into a
+ back-up repository.
+
+ * "git remote" learned "rm" subcommand.
+
+ * "git cvsserver" can be run via "git shell". Also, "cvs" is
+ recognized as a synonym for "git cvsserver", so that CVS users
+ can be switched to git just by changing their login shell.
+
+ * "git cvsserver" acts more like receive-pack by running post-receive
+ and post-update hooks.
+
+ * "git am" and "git rebase" are far less verbose.
+
+ * "git pull" learned to pass --[no-]ff option to underlying "git
+ merge".
+
+ * "git pull --rebase" is a different way to integrate what you fetched
+ into your current branch.
+
+ * "git fast-export" produces data-stream that can be fed to fast-import
+ to reproduce the history recorded in a git repository.
+
+ * "git add -i" takes pathspecs to limit the set of files to work on.
+
+ * "git add -p" is a short-hand to go directly to the selective patch
+ subcommand in the interactive command loop and to exit when done.
+
+ * "git add -i" UI has been colorized. The interactive prompt
+ and menu can be colored by setting color.interactive
+ configuration. The diff output (including the hunk picker)
+ are colored with color.diff configuration.
+
+ * "git commit --allow-empty" allows you to create a single-parent
+ commit that records the same tree as its parent, overriding the usual
+ safety valve.
+
+ * "git commit --amend" can amend a merge that does not change the tree
+ from its first parent.
+
+ * "git commit" used to unconditionally strip comment lines that
+ began with '#' and removed excess blank lines. This behavior has
+ been made configurable.
+
+ * "git commit" has been rewritten in C.
+
+ * "git stash random-text" does not create a new stash anymore. It was
+ a UI mistake. Use "git stash save random-text", or "git stash"
+ (without extra args) for that.
+
+ * "git stash clear extra-text" does not clear the whole stash
+ anymore. It is tempting to expect "git stash clear stash@{2}"
+ to drop only a single named stash entry, and it is rude to
+ discard everything when that is asked (but not provided).
+
+ * "git prune --expire <time>" can exempt young loose objects from
+ getting pruned.
+
+ * "git branch --contains <commit>" can list branches that are
+ descendants of a given commit.
+
+ * "git log" learned --early-output option to help interactive GUI
+ implementations.
+
+ * "git bisect" learned "skip" action to mark untestable commits.
+
+ * "git bisect visualize" learned a shorter synonym "git bisect view".
+
+ * "git bisect visualize" runs "git log" in a non-windowed
+ environments. It also can be told what command to run (e.g. "git
+ bisect visualize tig").
+
+ * "git format-patch" learned "format.numbered" configuration variable
+ to automatically turn --numbered option on when more than one commits
+ are formatted.
+
+ * "git ls-files" learned "--exclude-standard" to use the canned set of
+ exclude files.
+
+ * "git tag -a -f existing" begins the editor session using the existing
+ annotation message.
+
+ * "git tag -m one -m bar" (multiple -m options) behaves similarly to
+ "git commit"; the parameters to -m options are formatted as separate
+ paragraphs.
+
+ * The format "git show" outputs an annotated tag has been updated to
+ include "Tagger: " and "Date: " lines from the tag itself. Strictly
+ speaking this is a backward incompatible change, but this is a
+ reasonable usability fix and people's scripts shouldn't have been
+ relying on the exact output from "git show" Porcelain anyway.
+
+ * "git cvsimport" did not notice errors from underlying "cvsps"
+ and produced a corrupt import silently.
+
+ * "git cvsexportcommit" learned -w option to specify and switch to the
+ CVS working directory.
+
+ * "git checkout" from a subdirectory learned to use "../path" to allow
+ checking out a path outside the current directory without cd'ing up.
+
+ * "git checkout" from and to detached HEAD leaves a bit more
+ information in the reflog.
+
+ * "git send-email --dry-run" shows full headers for easier diagnosis.
+
+ * "git merge-ours" is now built-in.
+
+ * "git svn" learned "info" and "show-externals" subcommands.
+
+ * "git svn" run from a subdirectory failed to read settings from the
+ .git/config.
+
+ * "git svn" learned --use-log-author option, which picks up more
+ descriptive name from From: and Signed-off-by: lines in the commit
+ message.
+
+ * "git svn" wasted way too much disk to record revision mappings
+ between svn and git; a new representation that is much more compact
+ for this information has been introduced to correct this.
+
+ * "git svn" left temporary index files it used without cleaning them
+ up; this was corrected.
+
+ * "git status" from a subdirectory now shows relative paths, which
+ makes copy-and-pasting for git-checkout/git-add/git-rm easier. The
+ traditional behavior to show the full path relative to the top of
+ the work tree can be had by setting status.relativepaths
+ configuration variable to false.
+
+ * "git blame" kept text for each annotated revision in core needlessly;
+ this has been corrected.
+
+ * "git shortlog" learned to default to HEAD when the standard input is
+ a terminal and the user did not give any revision parameter.
+
+ * "git shortlog" learned "-e" option to show e-mail addresses as well as
+ authors' names.
+
+ * "git help" learned "-w" option to show documentation in browsers.
+
+ * In addition there are quite a few internal clean-ups. Notably:
+
+ - many fork/exec have been replaced with run-command API,
+ brought from the msysgit effort.
+
+ - introduction and more use of the option parser API.
+
+ - enhancement and more use of the strbuf API.
+
+ * Makefile tweaks to support HP-UX is in.
+
+Fixes since v1.5.3
+------------------
+
+All of the fixes in v1.5.3 maintenance series are included in
+this release, unless otherwise noted.
+
+These fixes are only in v1.5.4 and not backported to v1.5.3 maintenance
+series.
+
+ * The way "git diff --check" behaves is much more consistent with the way
+ "git apply --whitespace=warn" works.
+
+ * "git svn" talking with the SVN over HTTP will correctly quote branch
+ and project names.
+
+ * "git config" did not work correctly on platforms that define
+ REG_NOMATCH to an even number.
+
+ * Recent versions of AsciiDoc 8 has a change to break our
+ documentation; a workaround has been implemented.
+
+ * "git diff --color-words" colored context lines in a wrong color.
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
new file mode 100644
index 0000000..de08d09
--- /dev/null
+++ b/Documentation/SubmittingPatches
@@ -0,0 +1,404 @@
+Checklist (and a short version for the impatient):
+
+ Commits:
+
+ - make commits of logical units
+ - check for unnecessary whitespace with "git diff --check"
+ before committing
+ - do not check in commented out code or unneeded files
+ - provide a meaningful commit message
+ - the first line of the commit message should be a short
+ description and should skip the full stop
+ - if you want your work included in git.git, add a
+ "Signed-off-by: Your Name <you@example.com>" line to the
+ commit message (or just use the option "-s" when
+ committing) to confirm that you agree to the Developer's
+ Certificate of Origin
+ - make sure that you have tests for the bug you are fixing
+ - make sure that the test suite passes after your commit
+
+ Patch:
+
+ - use "git format-patch -M" to create the patch
+ - do not PGP sign your patch
+ - do not attach your patch, but read in the mail
+ body, unless you cannot teach your mailer to
+ leave the formatting of the patch alone.
+ - be careful doing cut & paste into your mailer, not to
+ corrupt whitespaces.
+ - provide additional information (which is unsuitable for
+ the commit message) between the "---" and the diffstat
+ - if you change, add, or remove a command line option or
+ make some other user interface change, the associated
+ documentation should be updated as well.
+ - if your name is not writable in ASCII, make sure that
+ you send off a message in the correct encoding.
+ - send the patch to the list (git@vger.kernel.org) and the
+ maintainer (gitster@pobox.com). If you use
+ git-send-email(1), please test it first by sending
+ email to yourself.
+
+Long version:
+
+I started reading over the SubmittingPatches document for Linux
+kernel, primarily because I wanted to have a document similar to
+it for the core GIT to make sure people understand what they are
+doing when they write "Signed-off-by" line.
+
+But the patch submission requirements are a lot more relaxed
+here on the technical/contents front, because the core GIT is
+thousand times smaller ;-). So here is only the relevant bits.
+
+
+(1) Make separate commits for logically separate changes.
+
+Unless your patch is really trivial, you should not be sending
+out a patch that was generated between your working tree and
+your commit head. Instead, always make a commit with complete
+commit message and generate a series of patches from your
+repository. It is a good discipline.
+
+Describe the technical detail of the change(s).
+
+If your description starts to get too long, that's a sign that you
+probably need to split up your commit to finer grained pieces.
+
+Oh, another thing. I am picky about whitespaces. Make sure your
+changes do not trigger errors with the sample pre-commit hook shipped
+in templates/hooks--pre-commit. To help ensure this does not happen,
+run git diff --check on your changes before you commit.
+
+
+(1a) Try to be nice to older C compilers
+
+We try to support wide range of C compilers to compile
+git with. That means that you should not use C99 initializers, even
+if a lot of compilers grok it.
+
+Also, variables have to be declared at the beginning of the block
+(you can check this with gcc, using the -Wdeclaration-after-statement
+option).
+
+Another thing: NULL pointers shall be written as NULL, not as 0.
+
+
+(2) Generate your patch using git tools out of your commits.
+
+git based diff tools (git, Cogito, and StGIT included) generate
+unidiff which is the preferred format.
+
+You do not have to be afraid to use -M option to "git diff" or
+"git format-patch", if your patch involves file renames. The
+receiving end can handle them just fine.
+
+Please make sure your patch does not include any extra files
+which do not belong in a patch submission. Make sure to review
+your patch after generating it, to ensure accuracy. Before
+sending out, please make sure it cleanly applies to the "master"
+branch head. If you are preparing a work based on "next" branch,
+that is fine, but please mark it as such.
+
+
+(3) Sending your patches.
+
+People on the git mailing list need to be able to read and
+comment on the changes you are submitting. It is important for
+a developer to be able to "quote" your changes, using standard
+e-mail tools, so that they may comment on specific portions of
+your code. For this reason, all patches should be submitted
+"inline". WARNING: Be wary of your MUAs word-wrap
+corrupting your patch. Do not cut-n-paste your patch; you can
+lose tabs that way if you are not careful.
+
+It is a common convention to prefix your subject line with
+[PATCH]. This lets people easily distinguish patches from other
+e-mail discussions.
+
+"git format-patch" command follows the best current practice to
+format the body of an e-mail message. At the beginning of the
+patch should come your commit message, ending with the
+Signed-off-by: lines, and a line that consists of three dashes,
+followed by the diffstat information and the patch itself. If
+you are forwarding a patch from somebody else, optionally, at
+the beginning of the e-mail message just before the commit
+message starts, you can put a "From: " line to name that person.
+
+You often want to add additional explanation about the patch,
+other than the commit message itself. Place such "cover letter"
+material between the three dash lines and the diffstat.
+
+Do not attach the patch as a MIME attachment, compressed or not.
+Do not let your e-mail client send quoted-printable. Do not let
+your e-mail client send format=flowed which would destroy
+whitespaces in your patches. Many
+popular e-mail applications will not always transmit a MIME
+attachment as plain text, making it impossible to comment on
+your code. A MIME attachment also takes a bit more time to
+process. This does not decrease the likelihood of your
+MIME-attached change being accepted, but it makes it more likely
+that it will be postponed.
+
+Exception: If your mailer is mangling patches then someone may ask
+you to re-send them using MIME, that is OK.
+
+Do not PGP sign your patch, at least for now. Most likely, your
+maintainer or other people on the list would not have your PGP
+key and would not bother obtaining it anyway. Your patch is not
+judged by who you are; a good patch from an unknown origin has a
+far better chance of being accepted than a patch from a known,
+respected origin that is done poorly or does incorrect things.
+
+If you really really really really want to do a PGP signed
+patch, format it as "multipart/signed", not a text/plain message
+that starts with '-----BEGIN PGP SIGNED MESSAGE-----'. That is
+not a text/plain, it's something else.
+
+Note that your maintainer does not necessarily read everything
+on the git mailing list. If your patch is for discussion first,
+send it "To:" the mailing list, and optionally "cc:" him. If it
+is trivially correct or after the list reached a consensus, send
+it "To:" the maintainer and optionally "cc:" the list.
+
+Also note that your maintainer does not actively involve himself in
+maintaining what are in contrib/ hierarchy. When you send fixes and
+enhancements to them, do not forget to "cc: " the person who primarily
+worked on that hierarchy in contrib/.
+
+
+(4) Sign your work
+
+To improve tracking of who did what, we've borrowed the
+"sign-off" procedure from the Linux kernel project on patches
+that are being emailed around. Although core GIT is a lot
+smaller project it is a good discipline to follow it.
+
+The sign-off is a simple line at the end of the explanation for
+the patch, which certifies that you wrote it or otherwise have
+the right to pass it on as a open-source patch. The rules are
+pretty simple: if you can certify the below:
+
+ Developer's Certificate of Origin 1.1
+
+ By making a contribution to this project, I certify that:
+
+ (a) The contribution was created in whole or in part by me and I
+ have the right to submit it under the open source license
+ indicated in the file; or
+
+ (b) The contribution is based upon previous work that, to the best
+ of my knowledge, is covered under an appropriate open source
+ license and I have the right under that license to submit that
+ work with modifications, whether created in whole or in part
+ by me, under the same open source license (unless I am
+ permitted to submit under a different license), as indicated
+ in the file; or
+
+ (c) The contribution was provided directly to me by some other
+ person who certified (a), (b) or (c) and I have not modified
+ it.
+
+ (d) I understand and agree that this project and the contribution
+ are public and that a record of the contribution (including all
+ personal information I submit with it, including my sign-off) is
+ maintained indefinitely and may be redistributed consistent with
+ this project or the open source license(s) involved.
+
+then you just add a line saying
+
+ Signed-off-by: Random J Developer <random@developer.example.org>
+
+This line can be automatically added by git if you run the git-commit
+command with the -s option.
+
+Some people also put extra tags at the end. They'll just be ignored for
+now, but you can do this to mark internal company procedures or just
+point out some special detail about the sign-off.
+
+
+------------------------------------------------
+MUA specific hints
+
+Some of patches I receive or pick up from the list share common
+patterns of breakage. Please make sure your MUA is set up
+properly not to corrupt whitespaces. Here are two common ones
+I have seen:
+
+* Empty context lines that do not have _any_ whitespace.
+
+* Non empty context lines that have one extra whitespace at the
+ beginning.
+
+One test you could do yourself if your MUA is set up correctly is:
+
+* Send the patch to yourself, exactly the way you would, except
+ To: and Cc: lines, which would not contain the list and
+ maintainer address.
+
+* Save that patch to a file in UNIX mailbox format. Call it say
+ a.patch.
+
+* Try to apply to the tip of the "master" branch from the
+ git.git public repository:
+
+ $ git fetch http://kernel.org/pub/scm/git/git.git master:test-apply
+ $ git checkout test-apply
+ $ git reset --hard
+ $ git am a.patch
+
+If it does not apply correctly, there can be various reasons.
+
+* Your patch itself does not apply cleanly. That is _bad_ but
+ does not have much to do with your MUA. Please rebase the
+ patch appropriately.
+
+* Your MUA corrupted your patch; "am" would complain that
+ the patch does not apply. Look at .dotest/ subdirectory and
+ see what 'patch' file contains and check for the common
+ corruption patterns mentioned above.
+
+* While you are at it, check what are in 'info' and
+ 'final-commit' files as well. If what is in 'final-commit' is
+ not exactly what you would want to see in the commit log
+ message, it is very likely that your maintainer would end up
+ hand editing the log message when he applies your patch.
+ Things like "Hi, this is my first patch.\n", if you really
+ want to put in the patch e-mail, should come after the
+ three-dash line that signals the end of the commit message.
+
+
+Pine
+----
+
+(Johannes Schindelin)
+
+I don't know how many people still use pine, but for those poor
+souls it may be good to mention that the quell-flowed-text is
+needed for recent versions.
+
+... the "no-strip-whitespace-before-send" option, too. AFAIK it
+was introduced in 4.60.
+
+(Linus Torvalds)
+
+And 4.58 needs at least this.
+
+---
+diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from e886a61f76edf5410573e92e38ce22974f9c40f1)
+Author: Linus Torvalds <torvalds@g5.osdl.org>
+Date: Mon Aug 15 17:23:51 2005 -0700
+
+ Fix pine whitespace-corruption bug
+
+ There's no excuse for unconditionally removing whitespace from
+ the pico buffers on close.
+
+diff --git a/pico/pico.c b/pico/pico.c
+--- a/pico/pico.c
++++ b/pico/pico.c
+@@ -219,7 +219,9 @@ PICO *pm;
+ switch(pico_all_done){ /* prepare for/handle final events */
+ case COMP_EXIT : /* already confirmed */
+ packheader();
++#if 0
+ stripwhitespace();
++#endif
+ c |= COMP_EXIT;
+ break;
+
+
+(Daniel Barkalow)
+
+> A patch to SubmittingPatches, MUA specific help section for
+> users of Pine 4.63 would be very much appreciated.
+
+Ah, it looks like a recent version changed the default behavior to do the
+right thing, and inverted the sense of the configuration option. (Either
+that or Gentoo did it.) So you need to set the
+"no-strip-whitespace-before-send" option, unless the option you have is
+"strip-whitespace-before-send", in which case you should avoid checking
+it.
+
+
+Thunderbird
+-----------
+
+(A Large Angry SCM)
+
+Here are some hints on how to successfully submit patches inline using
+Thunderbird.
+
+This recipe appears to work with the current [*1*] Thunderbird from Suse.
+
+The following Thunderbird extensions are needed:
+ AboutConfig 0.5
+ http://aboutconfig.mozdev.org/
+ External Editor 0.7.2
+ http://globs.org/articles.php?lng=en&pg=8
+
+1) Prepare the patch as a text file using your method of choice.
+
+2) Before opening a compose window, use Edit->Account Settings to
+uncheck the "Compose messages in HTML format" setting in the
+"Composition & Addressing" panel of the account to be used to send the
+patch. [*2*]
+
+3) In the main Thunderbird window, _before_ you open the compose window
+for the patch, use Tools->about:config to set the following to the
+indicated values:
+ mailnews.send_plaintext_flowed => false
+ mailnews.wraplength => 0
+
+4) Open a compose window and click the external editor icon.
+
+5) In the external editor window, read in the patch file and exit the
+editor normally.
+
+6) Back in the compose window: Add whatever other text you wish to the
+message, complete the addressing and subject fields, and press send.
+
+7) Optionally, undo the about:config/account settings changes made in
+steps 2 & 3.
+
+
+[Footnotes]
+*1* Version 1.0 (20041207) from the MozillaThunderbird-1.0-5 rpm of Suse
+9.3 professional updates.
+
+*2* It may be possible to do this with about:config and the following
+settings but I haven't tried, yet.
+ mail.html_compose => false
+ mail.identity.default.compose_html => false
+ mail.identity.id?.compose_html => false
+
+
+Gnus
+----
+
+'|' in the *Summary* buffer can be used to pipe the current
+message to an external program, and this is a handy way to drive
+"git am". However, if the message is MIME encoded, what is
+piped into the program is the representation you see in your
+*Article* buffer after unwrapping MIME. This is often not what
+you would want for two reasons. It tends to screw up non ASCII
+characters (most notably in people's names), and also
+whitespaces (fatal in patches). Running 'C-u g' to display the
+message in raw form before using '|' to run the pipe can work
+this problem around.
+
+
+KMail
+-----
+
+This should help you to submit patches inline using KMail.
+
+1) Prepare the patch as a text file.
+
+2) Click on New Mail.
+
+3) Go under "Options" in the Composer window and be sure that
+"Word wrap" is not set.
+
+4) Use Message -> Insert file... and insert the patch.
+
+5) Back in the compose window: add whatever other text you wish to the
+message, complete the addressing and subject fields, and press send.
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
new file mode 100644
index 0000000..10c1a15
--- /dev/null
+++ b/Documentation/asciidoc.conf
@@ -0,0 +1,66 @@
+## linkgit: macro
+#
+# Usage: linkgit:command[manpage-section]
+#
+# Note, {0} is the manpage section, while {target} is the command.
+#
+# Show GIT link as: <command>(<section>); if section is defined, else just show
+# the command.
+
+[attributes]
+plus=&#43;
+caret=&#94;
+startsb=&#91;
+endsb=&#93;
+tilde=&#126;
+
+ifdef::backend-docbook[]
+[linkgit-inlinemacro]
+{0%{target}}
+{0#<citerefentry>}
+{0#<refentrytitle>{target}</refentrytitle><manvolnum>{0}</manvolnum>}
+{0#</citerefentry>}
+endif::backend-docbook[]
+
+ifdef::backend-docbook[]
+ifndef::docbook-xsl-172[]
+# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this.
+# v1.72 breaks with this because it replaces dots not in roff requests.
+[listingblock]
+<example><title>{title}</title>
+<literallayout>
+ifdef::doctype-manpage[]
+&#10;.ft C&#10;
+endif::doctype-manpage[]
+|
+ifdef::doctype-manpage[]
+&#10;.ft&#10;
+endif::doctype-manpage[]
+</literallayout>
+{title#}</example>
+endif::docbook-xsl-172[]
+endif::backend-docbook[]
+
+ifdef::doctype-manpage[]
+ifdef::backend-docbook[]
+[header]
+template::[header-declarations]
+<refentry>
+<refmeta>
+<refentrytitle>{mantitle}</refentrytitle>
+<manvolnum>{manvolnum}</manvolnum>
+<refmiscinfo class="source">Git</refmiscinfo>
+<refmiscinfo class="version">{git_version}</refmiscinfo>
+<refmiscinfo class="manual">Git Manual</refmiscinfo>
+</refmeta>
+<refnamediv>
+ <refname>{manname}</refname>
+ <refpurpose>{manpurpose}</refpurpose>
+</refnamediv>
+endif::backend-docbook[]
+endif::doctype-manpage[]
+
+ifdef::backend-xhtml11[]
+[linkgit-inlinemacro]
+<a href="{target}.html">{target}{0?({0})}</a>
+endif::backend-xhtml11[]
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
new file mode 100644
index 0000000..c11bb7d
--- /dev/null
+++ b/Documentation/blame-options.txt
@@ -0,0 +1,87 @@
+-b::
+ Show blank SHA-1 for boundary commits. This can also
+ be controlled via the `blame.blankboundary` config option.
+
+--root::
+ Do not treat root commits as boundaries. This can also be
+ controlled via the `blame.showroot` config option.
+
+--show-stats::
+ Include additional statistics at the end of blame output.
+
+-L <start>,<end>::
+ Annotate only the given line range. <start> and <end> can take
+ one of these forms:
+
+ - number
++
+If <start> or <end> is a number, it specifies an
+absolute line number (lines count from 1).
++
+
+- /regex/
++
+This form will use the first line matching the given
+POSIX regex. If <end> is a regex, it will search
+starting at the line given by <start>.
++
+
+- +offset or -offset
++
+This is only valid for <end> and will specify a number
+of lines before or after the line given by <start>.
++
+
+-l::
+ Show long rev (Default: off).
+
+-t::
+ Show raw timestamp (Default: off).
+
+-S <revs-file>::
+ Use revs from revs-file instead of calling linkgit:git-rev-list[1].
+
+-p, --porcelain::
+ Show in a format designed for machine consumption.
+
+--incremental::
+ Show the result incrementally in a format designed for
+ machine consumption.
+
+--contents <file>::
+ When <rev> is not specified, the command annotates the
+ changes starting backwards from the working tree copy.
+ This flag makes the command pretend as if the working
+ tree copy has the contents of the named file (specify
+ `-` to make the command read from the standard input).
+
+-M|<num>|::
+ Detect moving lines in the file as well. When a commit
+ moves a block of lines in a file (e.g. the original file
+ has A and then B, and the commit changes it to B and
+ then A), traditional 'blame' algorithm typically blames
+ the lines that were moved up (i.e. B) to the parent and
+ assigns blame to the lines that were moved down (i.e. A)
+ to the child commit. With this option, both groups of lines
+ are blamed on the parent.
++
+<num> is optional but it is the lower bound on the number of
+alphanumeric characters that git must detect as moving
+within a file for it to associate those lines with the parent
+commit.
+
+-C|<num>|::
+ In addition to `-M`, detect lines copied from other
+ files that were modified in the same commit. This is
+ useful when you reorganize your program and move code
+ around across files. When this option is given twice,
+ the command looks for copies from all other files in the
+ parent for the commit that creates the file in addition.
++
+<num> is optional but it is the lower bound on the number of
+alphanumeric characters that git must detect as moving
+between files for it to associate those lines with the parent
+commit.
+
+-h, --help::
+ Show help message.
diff --git a/Documentation/build-docdep.perl b/Documentation/build-docdep.perl
new file mode 100755
index 0000000..ba4205e
--- /dev/null
+++ b/Documentation/build-docdep.perl
@@ -0,0 +1,46 @@
+#!/usr/bin/perl
+
+my %include = ();
+my %included = ();
+
+for my $text (<*.txt>) {
+ open I, '<', $text || die "cannot read: $text";
+ while (<I>) {
+ if (/^include::/) {
+ chomp;
+ s/^include::\s*//;
+ s/\[\]//;
+ $include{$text}{$_} = 1;
+ $included{$_} = 1;
+ }
+ }
+ close I;
+}
+
+# Do we care about chained includes???
+my $changed = 1;
+while ($changed) {
+ $changed = 0;
+ while (my ($text, $included) = each %include) {
+ for my $i (keys %$included) {
+ # $text has include::$i; if $i includes $j
+ # $text indirectly includes $j.
+ if (exists $include{$i}) {
+ for my $j (keys %{$include{$i}}) {
+ if (!exists $include{$text}{$j}) {
+ $include{$text}{$j} = 1;
+ $included{$j} = 1;
+ $changed = 1;
+ }
+ }
+ }
+ }
+ }
+}
+
+while (my ($text, $included) = each %include) {
+ if (! exists $included{$text} &&
+ (my $base = $text) =~ s/\.txt$//) {
+ print "$base.html $base.xml : ", join(" ", keys %$included), "\n";
+ }
+}
diff --git a/Documentation/callouts.xsl b/Documentation/callouts.xsl
new file mode 100644
index 0000000..6a361a2
--- /dev/null
+++ b/Documentation/callouts.xsl
@@ -0,0 +1,30 @@
+<!-- callout.xsl: converts asciidoc callouts to man page format -->
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
+<xsl:template match="co">
+ <xsl:value-of select="concat('\fB(',substring-after(@id,'-'),')\fR')"/>
+</xsl:template>
+<xsl:template match="calloutlist">
+ <xsl:text>.sp&#10;</xsl:text>
+ <xsl:apply-templates/>
+ <xsl:text>&#10;</xsl:text>
+</xsl:template>
+<xsl:template match="callout">
+ <xsl:value-of select="concat('\fB',substring-after(@arearefs,'-'),'. \fR')"/>
+ <xsl:apply-templates/>
+ <xsl:text>.br&#10;</xsl:text>
+</xsl:template>
+
+<!-- sorry, this is not about callouts, but attempts to work around
+ spurious .sp at the tail of the line docbook stylesheets seem to add -->
+<xsl:template match="simpara">
+ <xsl:variable name="content">
+ <xsl:apply-templates/>
+ </xsl:variable>
+ <xsl:value-of select="normalize-space($content)"/>
+ <xsl:if test="not(ancestor::authorblurb) and
+ not(ancestor::personblurb)">
+ <xsl:text>&#10;&#10;</xsl:text>
+ </xsl:if>
+</xsl:template>
+
+</xsl:stylesheet>
diff --git a/Documentation/cat-texi.perl b/Documentation/cat-texi.perl
new file mode 100755
index 0000000..e3d8e9f
--- /dev/null
+++ b/Documentation/cat-texi.perl
@@ -0,0 +1,38 @@
+#!/usr/bin/perl -w
+
+my @menu = ();
+my $output = $ARGV[0];
+
+open TMP, '>', "$output.tmp";
+
+while (<STDIN>) {
+ next if (/^\\input texinfo/../\@node Top/);
+ next if (/^\@bye/ || /^\.ft/);
+ if (s/^\@top (.*)/\@node $1,,,Top/) {
+ push @menu, $1;
+ }
+ s/\(\@pxref{\[URLS\]}\)//;
+ print TMP;
+}
+close TMP;
+
+printf '\input texinfo
+@setfilename gitman.info
+@documentencoding us-ascii
+@node Top,,%s
+@top Git Manual Pages
+@documentlanguage en
+@menu
+', $menu[0];
+
+for (@menu) {
+ print "* ${_}::\n";
+}
+print "\@end menu\n";
+open TMP, '<', "$output.tmp";
+while (<TMP>) {
+ print;
+}
+close TMP;
+print "\@bye\n";
+unlink "$output.tmp";
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
new file mode 100755
index 0000000..04f9977
--- /dev/null
+++ b/Documentation/cmd-list.perl
@@ -0,0 +1,74 @@
+#!/usr/bin/perl -w
+
+use File::Compare qw(compare);
+
+sub format_one {
+ my ($out, $nameattr) = @_;
+ my ($name, $attr) = @$nameattr;
+ my ($state, $description);
+ $state = 0;
+ open I, '<', "$name.txt" or die "No such file $name.txt";
+ while (<I>) {
+ if (/^NAME$/) {
+ $state = 1;
+ next;
+ }
+ if ($state == 1 && /^----$/) {
+ $state = 2;
+ next;
+ }
+ next if ($state != 2);
+ chomp;
+ $description = $_;
+ last;
+ }
+ close I;
+ if (!defined $description) {
+ die "No description found in $name.txt";
+ }
+ if (my ($verify_name, $text) = ($description =~ /^($name) - (.*)/)) {
+ print $out "linkgit:$name\[1\]::\n\t";
+ if ($attr =~ / deprecated /) {
+ print $out "(deprecated) ";
+ }
+ print $out "$text.\n\n";
+ }
+ else {
+ die "Description does not match $name: $description";
+ }
+}
+
+my %cmds = ();
+for (sort <>) {
+ next if /^#/;
+
+ chomp;
+ my ($name, $cat, $attr) = /^(\S+)\s+(.*?)(?:\s+(.*))?$/;
+ $attr = '' unless defined $attr;
+ push @{$cmds{$cat}}, [$name, " $attr "];
+}
+
+for my $cat (qw(ancillaryinterrogators
+ ancillarymanipulators
+ mainporcelain
+ plumbinginterrogators
+ plumbingmanipulators
+ synchingrepositories
+ foreignscminterface
+ purehelpers
+ synchelpers)) {
+ my $out = "cmds-$cat.txt";
+ open O, '>', "$out+" or die "Cannot open output file $out+";
+ for (@{$cmds{$cat}}) {
+ format_one(\*O, $_);
+ }
+ close O;
+
+ if (-f "$out" && compare("$out", "$out+") == 0) {
+ unlink "$out+";
+ }
+ else {
+ print STDERR "$out\n";
+ rename "$out+", "$out";
+ }
+}
diff --git a/Documentation/config.txt b/Documentation/config.txt
new file mode 100644
index 0000000..6d8cca4
--- /dev/null
+++ b/Documentation/config.txt
@@ -0,0 +1,887 @@
+CONFIGURATION FILE
+------------------
+
+The git configuration file contains a number of variables that affect
+the git command's behavior. `.git/config` file for each repository
+is used to store the information for that repository, and
+`$HOME/.gitconfig` is used to store per user information to give
+fallback values for `.git/config` file. The file `/etc/gitconfig`
+can be used to store system-wide defaults.
+
+They can be used by both the git plumbing
+and the porcelains. The variables are divided into sections, where
+in the fully qualified variable name the variable itself is the last
+dot-separated segment and the section name is everything before the last
+dot. The variable names are case-insensitive and only alphanumeric
+characters are allowed. Some variables may appear multiple times.
+
+Syntax
+~~~~~~
+
+The syntax is fairly flexible and permissive; whitespaces are mostly
+ignored. The '#' and ';' characters begin comments to the end of line,
+blank lines are ignored.
+
+The file consists of sections and variables. A section begins with
+the name of the section in square brackets and continues until the next
+section begins. Section names are not case sensitive. Only alphanumeric
+characters, '`-`' and '`.`' are allowed in section names. Each variable
+must belong to some section, which means that there must be section
+header before first setting of a variable.
+
+Sections can be further divided into subsections. To begin a subsection
+put its name in double quotes, separated by space from the section name,
+in the section header, like in example below:
+
+--------
+ [section "subsection"]
+
+--------
+
+Subsection names can contain any characters except newline (doublequote
+'`"`' and backslash have to be escaped as '`\"`' and '`\\`',
+respectively) and are case sensitive. Section header cannot span multiple
+lines. Variables may belong directly to a section or to a given subsection.
+You can have `[section]` if you have `[section "subsection"]`, but you
+don't need to.
+
+There is also (case insensitive) alternative `[section.subsection]` syntax.
+In this syntax subsection names follow the same restrictions as for section
+name.
+
+All the other lines are recognized as setting variables, in the form
+'name = value'. If there is no equal sign on the line, the entire line
+is taken as 'name' and the variable is recognized as boolean "true".
+The variable names are case-insensitive and only alphanumeric
+characters and '`-`' are allowed. There can be more than one value
+for a given variable; we say then that variable is multivalued.
+
+Leading and trailing whitespace in a variable value is discarded.
+Internal whitespace within a variable value is retained verbatim.
+
+The values following the equals sign in variable assign are all either
+a string, an integer, or a boolean. Boolean values may be given as yes/no,
+0/1 or true/false. Case is not significant in boolean values, when
+converting value to the canonical form using '--bool' type specifier;
+`git-config` will ensure that the output is "true" or "false".
+
+String values may be entirely or partially enclosed in double quotes.
+You need to enclose variable value in double quotes if you want to
+preserve leading or trailing whitespace, or if variable value contains
+beginning of comment characters (if it contains '#' or ';').
+Double quote '`"`' and backslash '`\`' characters in variable value must
+be escaped: use '`\"`' for '`"`' and '`\\`' for '`\`'.
+
+The following escape sequences (beside '`\"`' and '`\\`') are recognized:
+'`\n`' for newline character (NL), '`\t`' for horizontal tabulation (HT, TAB)
+and '`\b`' for backspace (BS). No other char escape sequence, nor octal
+char sequences are valid.
+
+Variable value ending in a '`\`' is continued on the next line in the
+customary UNIX fashion.
+
+Some variables may require special value format.
+
+Example
+~~~~~~~
+
+ # Core variables
+ [core]
+ ; Don't trust file modes
+ filemode = false
+
+ # Our diff algorithm
+ [diff]
+ external = "/usr/local/bin/gnu-diff -u"
+ renames = true
+
+ [branch "devel"]
+ remote = origin
+ merge = refs/heads/devel
+
+ # Proxy settings
+ [core]
+ gitProxy="ssh" for "kernel.org"
+ gitProxy=default-proxy ; for the rest
+
+Variables
+~~~~~~~~~
+
+Note that this list is non-comprehensive and not necessarily complete.
+For command-specific variables, you will find a more detailed description
+in the appropriate manual page. You will find a description of non-core
+porcelain configuration variables in the respective porcelain documentation.
+
+core.fileMode::
+ If false, the executable bit differences between the index and
+ the working copy are ignored; useful on broken filesystems like FAT.
+ See linkgit:git-update-index[1]. True by default.
+
+core.quotepath::
+ The commands that output paths (e.g. `ls-files`,
+ `diff`), when not given the `-z` option, will quote
+ "unusual" characters in the pathname by enclosing the
+ pathname in a double-quote pair and with backslashes the
+ same way strings in C source code are quoted. If this
+ variable is set to false, the bytes higher than 0x80 are
+ not quoted but output as verbatim. Note that double
+ quote, backslash and control characters are always
+ quoted without `-z` regardless of the setting of this
+ variable.
+
+core.autocrlf::
+ If true, makes git convert `CRLF` at the end of lines in text files to
+ `LF` when reading from the filesystem, and convert in reverse when
+ writing to the filesystem. The variable can be set to
+ 'input', in which case the conversion happens only while
+ reading from the filesystem but files are written out with
+ `LF` at the end of lines. Currently, which paths to consider
+ "text" (i.e. be subjected to the autocrlf mechanism) is
+ decided purely based on the contents.
+
+core.symlinks::
+ If false, symbolic links are checked out as small plain files that
+ contain the link text. linkgit:git-update-index[1] and
+ linkgit:git-add[1] will not change the recorded type to regular
+ file. Useful on filesystems like FAT that do not support
+ symbolic links. True by default.
+
+core.gitProxy::
+ A "proxy command" to execute (as 'command host port') instead
+ of establishing direct connection to the remote server when
+ using the git protocol for fetching. If the variable value is
+ in the "COMMAND for DOMAIN" format, the command is applied only
+ on hostnames ending with the specified domain string. This variable
+ may be set multiple times and is matched in the given order;
+ the first match wins.
++
+Can be overridden by the 'GIT_PROXY_COMMAND' environment variable
+(which always applies universally, without the special "for"
+handling).
+
+core.ignoreStat::
+ The working copy files are assumed to stay unchanged until you
+ mark them otherwise manually - Git will not detect the file changes
+ by lstat() calls. This is useful on systems where those are very
+ slow, such as Microsoft Windows. See linkgit:git-update-index[1].
+ False by default.
+
+core.preferSymlinkRefs::
+ Instead of the default "symref" format for HEAD
+ and other symbolic reference files, use symbolic links.
+ This is sometimes needed to work with old scripts that
+ expect HEAD to be a symbolic link.
+
+core.bare::
+ If true this repository is assumed to be 'bare' and has no
+ working directory associated with it. If this is the case a
+ number of commands that require a working directory will be
+ disabled, such as linkgit:git-add[1] or linkgit:git-merge[1].
++
+This setting is automatically guessed by linkgit:git-clone[1] or
+linkgit:git-init[1] when the repository was created. By default a
+repository that ends in "/.git" is assumed to be not bare (bare =
+false), while all other repositories are assumed to be bare (bare
+= true).
+
+core.worktree::
+ Set the path to the working tree. The value will not be
+ used in combination with repositories found automatically in
+ a .git directory (i.e. $GIT_DIR is not set).
+ This can be overridden by the GIT_WORK_TREE environment
+ variable and the '--work-tree' command line option.
+
+core.logAllRefUpdates::
+ Enable the reflog. Updates to a ref <ref> is logged to the file
+ "$GIT_DIR/logs/<ref>", by appending the new and old
+ SHA1, the date/time and the reason of the update, but
+ only when the file exists. If this configuration
+ variable is set to true, missing "$GIT_DIR/logs/<ref>"
+ file is automatically created for branch heads.
++
+This information can be used to determine what commit
+was the tip of a branch "2 days ago".
++
+This value is true by default in a repository that has
+a working directory associated with it, and false by
+default in a bare repository.
+
+core.repositoryFormatVersion::
+ Internal variable identifying the repository format and layout
+ version.
+
+core.sharedRepository::
+ When 'group' (or 'true'), the repository is made shareable between
+ several users in a group (making sure all the files and objects are
+ group-writable). When 'all' (or 'world' or 'everybody'), the
+ repository will be readable by all users, additionally to being
+ group-shareable. When 'umask' (or 'false'), git will use permissions
+ reported by umask(2). See linkgit:git-init[1]. False by default.
+
+core.warnAmbiguousRefs::
+ If true, git will warn you if the ref name you passed it is ambiguous
+ and might match multiple refs in the .git/refs/ tree. True by default.
+
+core.compression::
+ An integer -1..9, indicating a default compression level.
+ -1 is the zlib default. 0 means no compression,
+ and 1..9 are various speed/size tradeoffs, 9 being slowest.
+ If set, this provides a default to other compression variables,
+ such as 'core.loosecompression' and 'pack.compression'.
+
+core.loosecompression::
+ An integer -1..9, indicating the compression level for objects that
+ are not in a pack file. -1 is the zlib default. 0 means no
+ compression, and 1..9 are various speed/size tradeoffs, 9 being
+ slowest. If not set, defaults to core.compression. If that is
+ not set, defaults to 1 (best speed).
+
+core.packedGitWindowSize::
+ Number of bytes of a pack file to map into memory in a
+ single mapping operation. Larger window sizes may allow
+ your system to process a smaller number of large pack files
+ more quickly. Smaller window sizes will negatively affect
+ performance due to increased calls to the operating system's
+ memory manager, but may improve performance when accessing
+ a large number of large pack files.
++
+Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32
+MiB on 32 bit platforms and 1 GiB on 64 bit platforms. This should
+be reasonable for all users/operating systems. You probably do
+not need to adjust this value.
++
+Common unit suffixes of 'k', 'm', or 'g' are supported.
+
+core.packedGitLimit::
+ Maximum number of bytes to map simultaneously into memory
+ from pack files. If Git needs to access more than this many
+ bytes at once to complete an operation it will unmap existing
+ regions to reclaim virtual address space within the process.
++
+Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms.
+This should be reasonable for all users/operating systems, except on
+the largest projects. You probably do not need to adjust this value.
++
+Common unit suffixes of 'k', 'm', or 'g' are supported.
+
+core.deltaBaseCacheLimit::
+ Maximum number of bytes to reserve for caching base objects
+ that multiple deltafied objects reference. By storing the
+ entire decompressed base objects in a cache Git is able
+ to avoid unpacking and decompressing frequently used base
+ objects multiple times.
++
+Default is 16 MiB on all platforms. This should be reasonable
+for all users/operating systems, except on the largest projects.
+You probably do not need to adjust this value.
++
+Common unit suffixes of 'k', 'm', or 'g' are supported.
+
+core.excludesfile::
+ In addition to '.gitignore' (per-directory) and
+ '.git/info/exclude', git looks into this file for patterns
+ of files which are not meant to be tracked. See
+ linkgit:gitignore[5].
+
+core.editor::
+ Commands such as `commit` and `tag` that lets you edit
+ messages by launching an editor uses the value of this
+ variable when it is set, and the environment variable
+ `GIT_EDITOR` is not set. The order of preference is
+ `GIT_EDITOR` environment, `core.editor`, `VISUAL` and
+ `EDITOR` environment variables and then finally `vi`.
+
+core.pager::
+ The command that git will use to paginate output. Can be overridden
+ with the `GIT_PAGER` environment variable.
+
+core.whitespace::
+ A comma separated list of common whitespace problems to
+ notice. `git diff` will use `color.diff.whitespace` to
+ highlight them, and `git apply --whitespace=error` will
+ consider them as errors:
++
+* `trailing-space` treats trailing whitespaces at the end of the line
+ as an error (enabled by default).
+* `space-before-tab` treats a space character that appears immediately
+ before a tab character in the initial indent part of the line as an
+ error (enabled by default).
+* `indent-with-non-tab` treats a line that is indented with 8 or more
+ space characters as an error (not enabled by default).
+
+alias.*::
+ Command aliases for the linkgit:git[1] command wrapper - e.g.
+ after defining "alias.last = cat-file commit HEAD", the invocation
+ "git last" is equivalent to "git cat-file commit HEAD". To avoid
+ confusion and troubles with script usage, aliases that
+ hide existing git commands are ignored. Arguments are split by
+ spaces, the usual shell quoting and escaping is supported.
+ quote pair and a backslash can be used to quote them.
++
+If the alias expansion is prefixed with an exclamation point,
+it will be treated as a shell command. For example, defining
+"alias.new = !gitk --all --not ORIG_HEAD", the invocation
+"git new" is equivalent to running the shell command
+"gitk --all --not ORIG_HEAD".
+
+apply.whitespace::
+ Tells `git-apply` how to handle whitespaces, in the same way
+ as the '--whitespace' option. See linkgit:git-apply[1].
+
+branch.autosetupmerge::
+ Tells `git-branch` and `git-checkout` to setup new branches
+ so that linkgit:git-pull[1] will appropriately merge from that
+ remote branch. Note that even if this option is not set,
+ this behavior can be chosen per-branch using the `--track`
+ and `--no-track` options. This option defaults to true.
+
+branch.<name>.remote::
+ When in branch <name>, it tells `git fetch` which remote to fetch.
+ If this option is not given, `git fetch` defaults to remote "origin".
+
+branch.<name>.merge::
+ When in branch <name>, it tells `git fetch` the default
+ refspec to be marked for merging in FETCH_HEAD. The value is
+ handled like the remote part of a refspec, and must match a
+ ref which is fetched from the remote given by
+ "branch.<name>.remote".
+ The merge information is used by `git pull` (which at first calls
+ `git fetch`) to lookup the default branch for merging. Without
+ this option, `git pull` defaults to merge the first refspec fetched.
+ Specify multiple values to get an octopus merge.
+ If you wish to setup `git pull` so that it merges into <name> from
+ another branch in the local repository, you can point
+ branch.<name>.merge to the desired branch, and use the special setting
+ `.` (a period) for branch.<name>.remote.
+
+branch.<name>.mergeoptions::
+ Sets default options for merging into branch <name>. The syntax and
+ supported options are equal to that of linkgit:git-merge[1], but
+ option values containing whitespace characters are currently not
+ supported.
+
+branch.<name>.rebase::
+ When true, rebase the branch <name> on top of the fetched branch,
+ instead of merging the default branch from the default remote.
+ *NOTE*: this is a possibly dangerous operation; do *not* use
+ it unless you understand the implications (see linkgit:git-rebase[1]
+ for details).
+
+browser.<tool>.path::
+ Override the path for the given tool that may be used to
+ browse HTML help (see '-w' option in linkgit:git-help[1]) or a
+ working repository in gitweb (see linkgit:git-instaweb[1]).
+
+clean.requireForce::
+ A boolean to make git-clean do nothing unless given -f
+ or -n. Defaults to true.
+
+color.branch::
+ A boolean to enable/disable color in the output of
+ linkgit:git-branch[1]. May be set to `always`,
+ `false` (or `never`) or `auto` (or `true`), in which case colors are used
+ only when the output is to a terminal. Defaults to false.
+
+color.branch.<slot>::
+ Use customized color for branch coloration. `<slot>` is one of
+ `current` (the current branch), `local` (a local branch),
+ `remote` (a tracking branch in refs/remotes/), `plain` (other
+ refs).
++
+The value for these configuration variables is a list of colors (at most
+two) and attributes (at most one), separated by spaces. The colors
+accepted are `normal`, `black`, `red`, `green`, `yellow`, `blue`,
+`magenta`, `cyan` and `white`; the attributes are `bold`, `dim`, `ul`,
+`blink` and `reverse`. The first color given is the foreground; the
+second is the background. The position of the attribute, if any,
+doesn't matter.
+
+color.diff::
+ When set to `always`, always use colors in patch.
+ When false (or `never`), never. When set to `true` or `auto`, use
+ colors only when the output is to the terminal. Defaults to false.
+
+color.diff.<slot>::
+ Use customized color for diff colorization. `<slot>` specifies
+ which part of the patch to use the specified color, and is one
+ of `plain` (context text), `meta` (metainformation), `frag`
+ (hunk header), `old` (removed lines), `new` (added lines),
+ `commit` (commit headers), or `whitespace` (highlighting
+ whitespace errors). The values of these variables may be specified as
+ in color.branch.<slot>.
+
+color.interactive::
+ When set to `always`, always use colors for interactive prompts
+ and displays (such as those used by "git add --interactive").
+ When false (or `never`), never. When set to `true` or `auto`, use
+ colors only when the output is to the terminal. Defaults to false.
+
+color.interactive.<slot>::
+ Use customized color for `git add --interactive`
+ output. `<slot>` may be `prompt`, `header`, or `help`, for
+ three distinct types of normal output from interactive
+ programs. The values of these variables may be specified as
+ in color.branch.<slot>.
+
+color.pager::
+ A boolean to enable/disable colored output when the pager is in
+ use (default is true).
+
+color.status::
+ A boolean to enable/disable color in the output of
+ linkgit:git-status[1]. May be set to `always`,
+ `false` (or `never`) or `auto` (or `true`), in which case colors are used
+ only when the output is to a terminal. Defaults to false.
+
+color.status.<slot>::
+ Use customized color for status colorization. `<slot>` is
+ one of `header` (the header text of the status message),
+ `added` or `updated` (files which are added but not committed),
+ `changed` (files which are changed but not added in the index),
+ or `untracked` (files which are not tracked by git). The values of
+ these variables may be specified as in color.branch.<slot>.
+
+commit.template::
+ Specify a file to use as the template for new commit messages.
+
+diff.autorefreshindex::
+ When using `git diff` to compare with work tree
+ files, do not consider stat-only change as changed.
+ Instead, silently run `git update-index --refresh` to
+ update the cached stat information for paths whose
+ contents in the work tree match the contents in the
+ index. This option defaults to true. Note that this
+ affects only `git diff` Porcelain, and not lower level
+ `diff` commands, such as `git diff-files`.
+
+diff.external::
+ If this config variable is set, diff generation is not
+ performed using the internal diff machinery, but using the
+ given command. Note: if you want to use an external diff
+ program only on a subset of your files, you might want to
+ use linkgit:gitattributes[5] instead.
+
+diff.renameLimit::
+ The number of files to consider when performing the copy/rename
+ detection; equivalent to the git diff option '-l'.
+
+diff.renames::
+ Tells git to detect renames. If set to any boolean value, it
+ will enable basic rename detection. If set to "copies" or
+ "copy", it will detect copies, as well.
+
+fetch.unpackLimit::
+ If the number of objects fetched over the git native
+ transfer is below this
+ limit, then the objects will be unpacked into loose object
+ files. However if the number of received objects equals or
+ exceeds this limit then the received pack will be stored as
+ a pack, after adding any missing delta bases. Storing the
+ pack from a push can make the push operation complete faster,
+ especially on slow filesystems. If not set, the value of
+ `transfer.unpackLimit` is used instead.
+
+format.numbered::
+ A boolean which can enable sequence numbers in patch subjects.
+ Setting this option to "auto" will enable it only if there is
+ more than one patch. See --numbered option in
+ linkgit:git-format-patch[1].
+
+format.headers::
+ Additional email headers to include in a patch to be submitted
+ by mail. See linkgit:git-format-patch[1].
+
+format.suffix::
+ The default for format-patch is to output files with the suffix
+ `.patch`. Use this variable to change that suffix (make sure to
+ include the dot if you want it).
+
+gc.aggressiveWindow::
+ The window size parameter used in the delta compression
+ algorithm used by 'git gc --aggressive'. This defaults
+ to 10.
+
+gc.auto::
+ When there are approximately more than this many loose
+ objects in the repository, `git gc --auto` will pack them.
+ Some Porcelain commands use this command to perform a
+ light-weight garbage collection from time to time. The
+ default value is 6700. Setting this to 0 disables it.
+
+gc.autopacklimit::
+ When there are more than this many packs that are not
+ marked with `*.keep` file in the repository, `git gc
+ --auto` consolidates them into one larger pack. The
+ default value is 20. Setting this to 0 disables it.
+
+gc.packrefs::
+ `git gc` does not run `git pack-refs` in a bare repository by
+ default so that older dumb-transport clients can still fetch
+ from the repository. Setting this to `true` lets `git
+ gc` to run `git pack-refs`. Setting this to `false` tells
+ `git gc` never to run `git pack-refs`. The default setting is
+ `notbare`. Enable it only when you know you do not have to
+ support such clients. The default setting will change to `true`
+ at some stage, and setting this to `false` will continue to
+ prevent `git pack-refs` from being run from `git gc`.
+
+gc.reflogexpire::
+ `git reflog expire` removes reflog entries older than
+ this time; defaults to 90 days.
+
+gc.reflogexpireunreachable::
+ `git reflog expire` removes reflog entries older than
+ this time and are not reachable from the current tip;
+ defaults to 30 days.
+
+gc.rerereresolved::
+ Records of conflicted merge you resolved earlier are
+ kept for this many days when `git rerere gc` is run.
+ The default is 60 days. See linkgit:git-rerere[1].
+
+gc.rerereunresolved::
+ Records of conflicted merge you have not resolved are
+ kept for this many days when `git rerere gc` is run.
+ The default is 15 days. See linkgit:git-rerere[1].
+
+rerere.enabled::
+ Activate recording of resolved conflicts, so that identical
+ conflict hunks can be resolved automatically, should they
+ be encountered again. linkgit:git-rerere[1] command is by
+ default enabled if you create `rr-cache` directory under
+ `$GIT_DIR`, but can be disabled by setting this option to false.
+
+gitcvs.enabled::
+ Whether the CVS server interface is enabled for this repository.
+ See linkgit:git-cvsserver[1].
+
+gitcvs.logfile::
+ Path to a log file where the CVS server interface well... logs
+ various stuff. See linkgit:git-cvsserver[1].
+
+gitcvs.allbinary::
+ If true, all files are sent to the client in mode '-kb'. This
+ causes the client to treat all files as binary files which suppresses
+ any newline munging it otherwise might do. A work-around for the
+ fact that there is no way yet to set single files to mode '-kb'.
+
+gitcvs.dbname::
+ Database used by git-cvsserver to cache revision information
+ derived from the git repository. The exact meaning depends on the
+ used database driver, for SQLite (which is the default driver) this
+ is a filename. Supports variable substitution (see
+ linkgit:git-cvsserver[1] for details). May not contain semicolons (`;`).
+ Default: '%Ggitcvs.%m.sqlite'
+
+gitcvs.dbdriver::
+ Used Perl DBI driver. You can specify any available driver
+ for this here, but it might not work. git-cvsserver is tested
+ with 'DBD::SQLite', reported to work with 'DBD::Pg', and
+ reported *not* to work with 'DBD::mysql'. Experimental feature.
+ May not contain double colons (`:`). Default: 'SQLite'.
+ See linkgit:git-cvsserver[1].
+
+gitcvs.dbuser, gitcvs.dbpass::
+ Database user and password. Only useful if setting 'gitcvs.dbdriver',
+ since SQLite has no concept of database users and/or passwords.
+ 'gitcvs.dbuser' supports variable substitution (see
+ linkgit:git-cvsserver[1] for details).
+
+All gitcvs variables except for 'gitcvs.allbinary' can also be
+specified as 'gitcvs.<access_method>.<varname>' (where 'access_method'
+is one of "ext" and "pserver") to make them apply only for the given
+access method.
+
+help.browser::
+ Specify the browser that will be used to display help in the
+ 'web' format. See linkgit:git-help[1].
+
+help.format::
+ Override the default help format used by linkgit:git-help[1].
+ Values 'man', 'info', 'web' and 'html' are supported. 'man' is
+ the default. 'web' and 'html' are the same.
+
+http.proxy::
+ Override the HTTP proxy, normally configured using the 'http_proxy'
+ environment variable (see linkgit:curl[1]). This can be overridden
+ on a per-remote basis; see remote.<name>.proxy
+
+http.sslVerify::
+ Whether to verify the SSL certificate when fetching or pushing
+ over HTTPS. Can be overridden by the 'GIT_SSL_NO_VERIFY' environment
+ variable.
+
+http.sslCert::
+ File containing the SSL certificate when fetching or pushing
+ over HTTPS. Can be overridden by the 'GIT_SSL_CERT' environment
+ variable.
+
+http.sslKey::
+ File containing the SSL private key when fetching or pushing
+ over HTTPS. Can be overridden by the 'GIT_SSL_KEY' environment
+ variable.
+
+http.sslCAInfo::
+ File containing the certificates to verify the peer with when
+ fetching or pushing over HTTPS. Can be overridden by the
+ 'GIT_SSL_CAINFO' environment variable.
+
+http.sslCAPath::
+ Path containing files with the CA certificates to verify the peer
+ with when fetching or pushing over HTTPS. Can be overridden
+ by the 'GIT_SSL_CAPATH' environment variable.
+
+http.maxRequests::
+ How many HTTP requests to launch in parallel. Can be overridden
+ by the 'GIT_HTTP_MAX_REQUESTS' environment variable. Default is 5.
+
+http.lowSpeedLimit, http.lowSpeedTime::
+ If the HTTP transfer speed is less than 'http.lowSpeedLimit'
+ for longer than 'http.lowSpeedTime' seconds, the transfer is aborted.
+ Can be overridden by the 'GIT_HTTP_LOW_SPEED_LIMIT' and
+ 'GIT_HTTP_LOW_SPEED_TIME' environment variables.
+
+http.noEPSV::
+ A boolean which disables using of EPSV ftp command by curl.
+ This can helpful with some "poor" ftp servers which don't
+ support EPSV mode. Can be overridden by the 'GIT_CURL_FTP_NO_EPSV'
+ environment variable. Default is false (curl will use EPSV).
+
+i18n.commitEncoding::
+ Character encoding the commit messages are stored in; git itself
+ does not care per se, but this information is necessary e.g. when
+ importing commits from emails or in the gitk graphical history
+ browser (and possibly at other places in the future or in other
+ porcelains). See e.g. linkgit:git-mailinfo[1]. Defaults to 'utf-8'.
+
+i18n.logOutputEncoding::
+ Character encoding the commit messages are converted to when
+ running `git-log` and friends.
+
+instaweb.browser::
+ Specify the program that will be used to browse your working
+ repository in gitweb. See linkgit:git-instaweb[1].
+
+instaweb.httpd::
+ The HTTP daemon command-line to start gitweb on your working
+ repository. See linkgit:git-instaweb[1].
+
+instaweb.local::
+ If true the web server started by linkgit:git-instaweb[1] will
+ be bound to the local IP (127.0.0.1).
+
+instaweb.modulepath::
+ The module path for an apache httpd used by linkgit:git-instaweb[1].
+
+instaweb.port::
+ The port number to bind the gitweb httpd to. See
+ linkgit:git-instaweb[1].
+
+log.showroot::
+ If true, the initial commit will be shown as a big creation event.
+ This is equivalent to a diff against an empty tree.
+ Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
+ normally hide the root commit will now show it. True by default.
+
+merge.summary::
+ Whether to include summaries of merged commits in newly created
+ merge commit messages. False by default.
+
+merge.tool::
+ Controls which merge resolution program is used by
+ linkgit:git-mergetool[1]. Valid values are: "kdiff3", "tkdiff",
+ "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", and "opendiff".
+
+merge.verbosity::
+ Controls the amount of output shown by the recursive merge
+ strategy. Level 0 outputs nothing except a final error
+ message if conflicts were detected. Level 1 outputs only
+ conflicts, 2 outputs conflicts and file changes. Level 5 and
+ above outputs debugging information. The default is level 2.
+ Can be overridden by 'GIT_MERGE_VERBOSITY' environment variable.
+
+merge.<driver>.name::
+ Defines a human readable name for a custom low-level
+ merge driver. See linkgit:gitattributes[5] for details.
+
+merge.<driver>.driver::
+ Defines the command that implements a custom low-level
+ merge driver. See linkgit:gitattributes[5] for details.
+
+merge.<driver>.recursive::
+ Names a low-level merge driver to be used when
+ performing an internal merge between common ancestors.
+ See linkgit:gitattributes[5] for details.
+
+mergetool.<tool>.path::
+ Override the path for the given tool. This is useful in case
+ your tool is not in the PATH.
+
+pack.window::
+ The size of the window used by linkgit:git-pack-objects[1] when no
+ window size is given on the command line. Defaults to 10.
+
+pack.depth::
+ The maximum delta depth used by linkgit:git-pack-objects[1] when no
+ maximum depth is given on the command line. Defaults to 50.
+
+pack.windowMemory::
+ The window memory size limit used by linkgit:git-pack-objects[1]
+ when no limit is given on the command line. The value can be
+ suffixed with "k", "m", or "g". Defaults to 0, meaning no
+ limit.
+
+pack.compression::
+ An integer -1..9, indicating the compression level for objects
+ in a pack file. -1 is the zlib default. 0 means no
+ compression, and 1..9 are various speed/size tradeoffs, 9 being
+ slowest. If not set, defaults to core.compression. If that is
+ not set, defaults to -1, the zlib default, which is "a default
+ compromise between speed and compression (currently equivalent
+ to level 6)."
+
+pack.deltaCacheSize::
+ The maximum memory in bytes used for caching deltas in
+ linkgit:git-pack-objects[1].
+ A value of 0 means no limit. Defaults to 0.
+
+pack.deltaCacheLimit::
+ The maximum size of a delta, that is cached in
+ linkgit:git-pack-objects[1]. Defaults to 1000.
+
+pack.threads::
+ Specifies the number of threads to spawn when searching for best
+ delta matches. This requires that linkgit:git-pack-objects[1]
+ be compiled with pthreads otherwise this option is ignored with a
+ warning. This is meant to reduce packing time on multiprocessor
+ machines. The required amount of memory for the delta search window
+ is however multiplied by the number of threads.
+
+pack.indexVersion::
+ Specify the default pack index version. Valid values are 1 for
+ legacy pack index used by Git versions prior to 1.5.2, and 2 for
+ the new pack index with capabilities for packs larger than 4 GB
+ as well as proper protection against the repacking of corrupted
+ packs. Version 2 is selected and this config option ignored
+ whenever the corresponding pack is larger than 2 GB. Otherwise
+ the default is 1.
+
+pull.octopus::
+ The default merge strategy to use when pulling multiple branches
+ at once.
+
+pull.twohead::
+ The default merge strategy to use when pulling a single branch.
+
+remote.<name>.url::
+ The URL of a remote repository. See linkgit:git-fetch[1] or
+ linkgit:git-push[1].
+
+remote.<name>.proxy::
+ For remotes that require curl (http, https and ftp), the URL to
+ the proxy to use for that remote. Set to the empty string to
+ disable proxying for that remote.
+
+remote.<name>.fetch::
+ The default set of "refspec" for linkgit:git-fetch[1]. See
+ linkgit:git-fetch[1].
+
+remote.<name>.push::
+ The default set of "refspec" for linkgit:git-push[1]. See
+ linkgit:git-push[1].
+
+remote.<name>.skipDefaultUpdate::
+ If true, this remote will be skipped by default when updating
+ using the update subcommand of linkgit:git-remote[1].
+
+remote.<name>.receivepack::
+ The default program to execute on the remote side when pushing. See
+ option \--exec of linkgit:git-push[1].
+
+remote.<name>.uploadpack::
+ The default program to execute on the remote side when fetching. See
+ option \--exec of linkgit:git-fetch-pack[1].
+
+remote.<name>.tagopt::
+ Setting this value to --no-tags disables automatic tag following when fetching
+ from remote <name>
+
+remotes.<group>::
+ The list of remotes which are fetched by "git remote update
+ <group>". See linkgit:git-remote[1].
+
+repack.usedeltabaseoffset::
+ Allow linkgit:git-repack[1] to create packs that uses
+ delta-base offset. Defaults to false.
+
+show.difftree::
+ The default linkgit:git-diff-tree[1] arguments to be used
+ for linkgit:git-show[1].
+
+showbranch.default::
+ The default set of branches for linkgit:git-show-branch[1].
+ See linkgit:git-show-branch[1].
+
+status.relativePaths::
+ By default, linkgit:git-status[1] shows paths relative to the
+ current directory. Setting this variable to `false` shows paths
+ relative to the repository root (this was the default for git
+ prior to v1.5.4).
+
+tar.umask::
+ This variable can be used to restrict the permission bits of
+ tar archive entries. The default is 0002, which turns off the
+ world write bit. The special value "user" indicates that the
+ archiving user's umask will be used instead. See umask(2) and
+ linkgit:git-archive[1].
+
+user.email::
+ Your email address to be recorded in any newly created commits.
+ Can be overridden by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and
+ 'EMAIL' environment variables. See linkgit:git-commit-tree[1].
+
+user.name::
+ Your full name to be recorded in any newly created commits.
+ Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME'
+ environment variables. See linkgit:git-commit-tree[1].
+
+user.signingkey::
+ If linkgit:git-tag[1] is not selecting the key you want it to
+ automatically when creating a signed tag, you can override the
+ default selection with this variable. This option is passed
+ unchanged to gpg's --local-user parameter, so you may specify a key
+ using any method that gpg supports.
+
+whatchanged.difftree::
+ The default linkgit:git-diff-tree[1] arguments to be used
+ for linkgit:git-whatchanged[1].
+
+imap::
+ The configuration variables in the 'imap' section are described
+ in linkgit:git-imap-send[1].
+
+receive.unpackLimit::
+ If the number of objects received in a push is below this
+ limit then the objects will be unpacked into loose object
+ files. However if the number of received objects equals or
+ exceeds this limit then the received pack will be stored as
+ a pack, after adding any missing delta bases. Storing the
+ pack from a push can make the push operation complete faster,
+ especially on slow filesystems. If not set, the value of
+ `transfer.unpackLimit` is used instead.
+
+receive.denyNonFastForwards::
+ If set to true, git-receive-pack will deny a ref update which is
+ not a fast forward. Use this to prevent such an update via a push,
+ even if that push is forced. This configuration variable is
+ set when initializing a shared repository.
+
+transfer.unpackLimit::
+ When `fetch.unpackLimit` or `receive.unpackLimit` are
+ not set, the value of this variable is used instead.
+ The default value is 100.
+
+web.browser::
+ Specify a web browser that may be used by some commands.
+ Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
+ may use it.
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
new file mode 100644
index 0000000..aa40dfd
--- /dev/null
+++ b/Documentation/core-tutorial.txt
@@ -0,0 +1,1681 @@
+A git core tutorial for developers
+==================================
+
+Introduction
+------------
+
+This tutorial explains how to use the "core" git programs to set up and
+work with a git repository.
+
+If you just need to use git as a revision control system you may prefer
+to start with link:tutorial.html[a tutorial introduction to git] or
+link:user-manual.html[the git user manual].
+
+However, an understanding of these low-level tools can be helpful if
+you want to understand git's internals.
+
+The core git is often called "plumbing", with the prettier user
+interfaces on top of it called "porcelain". You may not want to use the
+plumbing directly very often, but it can be good to know what the
+plumbing does for when the porcelain isn't flushing.
+
+[NOTE]
+Deeper technical details are often marked as Notes, which you can
+skip on your first reading.
+
+
+Creating a git repository
+-------------------------
+
+Creating a new git repository couldn't be easier: all git repositories start
+out empty, and the only thing you need to do is find yourself a
+subdirectory that you want to use as a working tree - either an empty
+one for a totally new project, or an existing working tree that you want
+to import into git.
+
+For our first example, we're going to start a totally new repository from
+scratch, with no pre-existing files, and we'll call it `git-tutorial`.
+To start up, create a subdirectory for it, change into that
+subdirectory, and initialize the git infrastructure with `git-init`:
+
+------------------------------------------------
+$ mkdir git-tutorial
+$ cd git-tutorial
+$ git-init
+------------------------------------------------
+
+to which git will reply
+
+----------------
+Initialized empty Git repository in .git/
+----------------
+
+which is just git's way of saying that you haven't been doing anything
+strange, and that it will have created a local `.git` directory setup for
+your new project. You will now have a `.git` directory, and you can
+inspect that with `ls`. For your new empty project, it should show you
+three entries, among other things:
+
+ - a file called `HEAD`, that has `ref: refs/heads/master` in it.
+ This is similar to a symbolic link and points at
+ `refs/heads/master` relative to the `HEAD` file.
++
+Don't worry about the fact that the file that the `HEAD` link points to
+doesn't even exist yet -- you haven't created the commit that will
+start your `HEAD` development branch yet.
+
+ - a subdirectory called `objects`, which will contain all the
+ objects of your project. You should never have any real reason to
+ look at the objects directly, but you might want to know that these
+ objects are what contains all the real 'data' in your repository.
+
+ - a subdirectory called `refs`, which contains references to objects.
+
+In particular, the `refs` subdirectory will contain two other
+subdirectories, named `heads` and `tags` respectively. They do
+exactly what their names imply: they contain references to any number
+of different 'heads' of development (aka 'branches'), and to any
+'tags' that you have created to name specific versions in your
+repository.
+
+One note: the special `master` head is the default branch, which is
+why the `.git/HEAD` file was created points to it even if it
+doesn't yet exist. Basically, the `HEAD` link is supposed to always
+point to the branch you are working on right now, and you always
+start out expecting to work on the `master` branch.
+
+However, this is only a convention, and you can name your branches
+anything you want, and don't have to ever even 'have' a `master`
+branch. A number of the git tools will assume that `.git/HEAD` is
+valid, though.
+
+[NOTE]
+An 'object' is identified by its 160-bit SHA1 hash, aka 'object name',
+and a reference to an object is always the 40-byte hex
+representation of that SHA1 name. The files in the `refs`
+subdirectory are expected to contain these hex references
+(usually with a final `\'\n\'` at the end), and you should thus
+expect to see a number of 41-byte files containing these
+references in these `refs` subdirectories when you actually start
+populating your tree.
+
+[NOTE]
+An advanced user may want to take a look at the
+link:repository-layout.html[repository layout] document
+after finishing this tutorial.
+
+You have now created your first git repository. Of course, since it's
+empty, that's not very useful, so let's start populating it with data.
+
+
+Populating a git repository
+---------------------------
+
+We'll keep this simple and stupid, so we'll start off with populating a
+few trivial files just to get a feel for it.
+
+Start off with just creating any random files that you want to maintain
+in your git repository. We'll start off with a few bad examples, just to
+get a feel for how this works:
+
+------------------------------------------------
+$ echo "Hello World" >hello
+$ echo "Silly example" >example
+------------------------------------------------
+
+you have now created two files in your working tree (aka 'working directory'),
+but to actually check in your hard work, you will have to go through two steps:
+
+ - fill in the 'index' file (aka 'cache') with the information about your
+ working tree state.
+
+ - commit that index file as an object.
+
+The first step is trivial: when you want to tell git about any changes
+to your working tree, you use the `git-update-index` program. That
+program normally just takes a list of filenames you want to update, but
+to avoid trivial mistakes, it refuses to add new entries to the index
+(or remove existing ones) unless you explicitly tell it that you're
+adding a new entry with the `\--add` flag (or removing an entry with the
+`\--remove`) flag.
+
+So to populate the index with the two files you just created, you can do
+
+------------------------------------------------
+$ git-update-index --add hello example
+------------------------------------------------
+
+and you have now told git to track those two files.
+
+In fact, as you did that, if you now look into your object directory,
+you'll notice that git will have added two new objects to the object
+database. If you did exactly the steps above, you should now be able to do
+
+
+----------------
+$ ls .git/objects/??/*
+----------------
+
+and see two files:
+
+----------------
+.git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238
+.git/objects/f2/4c74a2e500f5ee1332c86b94199f52b1d1d962
+----------------
+
+which correspond with the objects with names of `557db...` and
+`f24c7...` respectively.
+
+If you want to, you can use `git-cat-file` to look at those objects, but
+you'll have to use the object name, not the filename of the object:
+
+----------------
+$ git-cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
+----------------
+
+where the `-t` tells `git-cat-file` to tell you what the "type" of the
+object is. git will tell you that you have a "blob" object (i.e., just a
+regular file), and you can see the contents with
+
+----------------
+$ git-cat-file "blob" 557db03
+----------------
+
+which will print out "Hello World". The object `557db03` is nothing
+more than the contents of your file `hello`.
+
+[NOTE]
+Don't confuse that object with the file `hello` itself. The
+object is literally just those specific *contents* of the file, and
+however much you later change the contents in file `hello`, the object
+we just looked at will never change. Objects are immutable.
+
+[NOTE]
+The second example demonstrates that you can
+abbreviate the object name to only the first several
+hexadecimal digits in most places.
+
+Anyway, as we mentioned previously, you normally never actually take a
+look at the objects themselves, and typing long 40-character hex
+names is not something you'd normally want to do. The above digression
+was just to show that `git-update-index` did something magical, and
+actually saved away the contents of your files into the git object
+database.
+
+Updating the index did something else too: it created a `.git/index`
+file. This is the index that describes your current working tree, and
+something you should be very aware of. Again, you normally never worry
+about the index file itself, but you should be aware of the fact that
+you have not actually really "checked in" your files into git so far,
+you've only *told* git about them.
+
+However, since git knows about them, you can now start using some of the
+most basic git commands to manipulate the files or look at their status.
+
+In particular, let's not even check in the two files into git yet, we'll
+start off by adding another line to `hello` first:
+
+------------------------------------------------
+$ echo "It's a new day for git" >>hello
+------------------------------------------------
+
+and you can now, since you told git about the previous state of `hello`, ask
+git what has changed in the tree compared to your old index, using the
+`git-diff-files` command:
+
+------------
+$ git-diff-files
+------------
+
+Oops. That wasn't very readable. It just spit out its own internal
+version of a `diff`, but that internal version really just tells you
+that it has noticed that "hello" has been modified, and that the old object
+contents it had have been replaced with something else.
+
+To make it readable, we can tell git-diff-files to output the
+differences as a patch, using the `-p` flag:
+
+------------
+$ git-diff-files -p
+diff --git a/hello b/hello
+index 557db03..263414f 100644
+--- a/hello
++++ b/hello
+@@ -1 +1,2 @@
+ Hello World
++It's a new day for git
+----
+
+i.e. the diff of the change we caused by adding another line to `hello`.
+
+In other words, `git-diff-files` always shows us the difference between
+what is recorded in the index, and what is currently in the working
+tree. That's very useful.
+
+A common shorthand for `git-diff-files -p` is to just write `git
+diff`, which will do the same thing.
+
+------------
+$ git diff
+diff --git a/hello b/hello
+index 557db03..263414f 100644
+--- a/hello
++++ b/hello
+@@ -1 +1,2 @@
+ Hello World
++It's a new day for git
+------------
+
+
+Committing git state
+--------------------
+
+Now, we want to go to the next stage in git, which is to take the files
+that git knows about in the index, and commit them as a real tree. We do
+that in two phases: creating a 'tree' object, and committing that 'tree'
+object as a 'commit' object together with an explanation of what the
+tree was all about, along with information of how we came to that state.
+
+Creating a tree object is trivial, and is done with `git-write-tree`.
+There are no options or other input: git-write-tree will take the
+current index state, and write an object that describes that whole
+index. In other words, we're now tying together all the different
+filenames with their contents (and their permissions), and we're
+creating the equivalent of a git "directory" object:
+
+------------------------------------------------
+$ git-write-tree
+------------------------------------------------
+
+and this will just output the name of the resulting tree, in this case
+(if you have done exactly as I've described) it should be
+
+----------------
+8988da15d077d4829fc51d8544c097def6644dbb
+----------------
+
+which is another incomprehensible object name. Again, if you want to,
+you can use `git-cat-file -t 8988d\...` to see that this time the object
+is not a "blob" object, but a "tree" object (you can also use
+`git-cat-file` to actually output the raw object contents, but you'll see
+mainly a binary mess, so that's less interesting).
+
+However -- normally you'd never use `git-write-tree` on its own, because
+normally you always commit a tree into a commit object using the
+`git-commit-tree` command. In fact, it's easier to not actually use
+`git-write-tree` on its own at all, but to just pass its result in as an
+argument to `git-commit-tree`.
+
+`git-commit-tree` normally takes several arguments -- it wants to know
+what the 'parent' of a commit was, but since this is the first commit
+ever in this new repository, and it has no parents, we only need to pass in
+the object name of the tree. However, `git-commit-tree` also wants to get a
+commit message on its standard input, and it will write out the resulting
+object name for the commit to its standard output.
+
+And this is where we create the `.git/refs/heads/master` file
+which is pointed at by `HEAD`. This file is supposed to contain
+the reference to the top-of-tree of the master branch, and since
+that's exactly what `git-commit-tree` spits out, we can do this
+all with a sequence of simple shell commands:
+
+------------------------------------------------
+$ tree=$(git-write-tree)
+$ commit=$(echo 'Initial commit' | git-commit-tree $tree)
+$ git-update-ref HEAD $commit
+------------------------------------------------
+
+In this case this creates a totally new commit that is not related to
+anything else. Normally you do this only *once* for a project ever, and
+all later commits will be parented on top of an earlier commit.
+
+Again, normally you'd never actually do this by hand. There is a
+helpful script called `git commit` that will do all of this for you. So
+you could have just written `git commit`
+instead, and it would have done the above magic scripting for you.
+
+
+Making a change
+---------------
+
+Remember how we did the `git-update-index` on file `hello` and then we
+changed `hello` afterward, and could compare the new state of `hello` with the
+state we saved in the index file?
+
+Further, remember how I said that `git-write-tree` writes the contents
+of the *index* file to the tree, and thus what we just committed was in
+fact the *original* contents of the file `hello`, not the new ones. We did
+that on purpose, to show the difference between the index state, and the
+state in the working tree, and how they don't have to match, even
+when we commit things.
+
+As before, if we do `git-diff-files -p` in our git-tutorial project,
+we'll still see the same difference we saw last time: the index file
+hasn't changed by the act of committing anything. However, now that we
+have committed something, we can also learn to use a new command:
+`git-diff-index`.
+
+Unlike `git-diff-files`, which showed the difference between the index
+file and the working tree, `git-diff-index` shows the differences
+between a committed *tree* and either the index file or the working
+tree. In other words, `git-diff-index` wants a tree to be diffed
+against, and before we did the commit, we couldn't do that, because we
+didn't have anything to diff against.
+
+But now we can do
+
+----------------
+$ git-diff-index -p HEAD
+----------------
+
+(where `-p` has the same meaning as it did in `git-diff-files`), and it
+will show us the same difference, but for a totally different reason.
+Now we're comparing the working tree not against the index file,
+but against the tree we just wrote. It just so happens that those two
+are obviously the same, so we get the same result.
+
+Again, because this is a common operation, you can also just shorthand
+it with
+
+----------------
+$ git diff HEAD
+----------------
+
+which ends up doing the above for you.
+
+In other words, `git-diff-index` normally compares a tree against the
+working tree, but when given the `\--cached` flag, it is told to
+instead compare against just the index cache contents, and ignore the
+current working tree state entirely. Since we just wrote the index
+file to HEAD, doing `git-diff-index \--cached -p HEAD` should thus return
+an empty set of differences, and that's exactly what it does.
+
+[NOTE]
+================
+`git-diff-index` really always uses the index for its
+comparisons, and saying that it compares a tree against the working
+tree is thus not strictly accurate. In particular, the list of
+files to compare (the "meta-data") *always* comes from the index file,
+regardless of whether the `\--cached` flag is used or not. The `\--cached`
+flag really only determines whether the file *contents* to be compared
+come from the working tree or not.
+
+This is not hard to understand, as soon as you realize that git simply
+never knows (or cares) about files that it is not told about
+explicitly. git will never go *looking* for files to compare, it
+expects you to tell it what the files are, and that's what the index
+is there for.
+================
+
+However, our next step is to commit the *change* we did, and again, to
+understand what's going on, keep in mind the difference between "working
+tree contents", "index file" and "committed tree". We have changes
+in the working tree that we want to commit, and we always have to
+work through the index file, so the first thing we need to do is to
+update the index cache:
+
+------------------------------------------------
+$ git-update-index hello
+------------------------------------------------
+
+(note how we didn't need the `\--add` flag this time, since git knew
+about the file already).
+
+Note what happens to the different `git-diff-\*` versions here. After
+we've updated `hello` in the index, `git-diff-files -p` now shows no
+differences, but `git-diff-index -p HEAD` still *does* show that the
+current state is different from the state we committed. In fact, now
+`git-diff-index` shows the same difference whether we use the `--cached`
+flag or not, since now the index is coherent with the working tree.
+
+Now, since we've updated `hello` in the index, we can commit the new
+version. We could do it by writing the tree by hand again, and
+committing the tree (this time we'd have to use the `-p HEAD` flag to
+tell commit that the HEAD was the *parent* of the new commit, and that
+this wasn't an initial commit any more), but you've done that once
+already, so let's just use the helpful script this time:
+
+------------------------------------------------
+$ git commit
+------------------------------------------------
+
+which starts an editor for you to write the commit message and tells you
+a bit about what you have done.
+
+Write whatever message you want, and all the lines that start with '#'
+will be pruned out, and the rest will be used as the commit message for
+the change. If you decide you don't want to commit anything after all at
+this point (you can continue to edit things and update the index), you
+can just leave an empty message. Otherwise `git commit` will commit
+the change for you.
+
+You've now made your first real git commit. And if you're interested in
+looking at what `git commit` really does, feel free to investigate:
+it's a few very simple shell scripts to generate the helpful (?) commit
+message headers, and a few one-liners that actually do the
+commit itself (`git-commit`).
+
+
+Inspecting Changes
+------------------
+
+While creating changes is useful, it's even more useful if you can tell
+later what changed. The most useful command for this is another of the
+`diff` family, namely `git-diff-tree`.
+
+`git-diff-tree` can be given two arbitrary trees, and it will tell you the
+differences between them. Perhaps even more commonly, though, you can
+give it just a single commit object, and it will figure out the parent
+of that commit itself, and show the difference directly. Thus, to get
+the same diff that we've already seen several times, we can now do
+
+----------------
+$ git-diff-tree -p HEAD
+----------------
+
+(again, `-p` means to show the difference as a human-readable patch),
+and it will show what the last commit (in `HEAD`) actually changed.
+
+[NOTE]
+============
+Here is an ASCII art by Jon Loeliger that illustrates how
+various diff-\* commands compare things.
+
+ diff-tree
+ +----+
+ | |
+ | |
+ V V
+ +-----------+
+ | Object DB |
+ | Backing |
+ | Store |
+ +-----------+
+ ^ ^
+ | |
+ | | diff-index --cached
+ | |
+ diff-index | V
+ | +-----------+
+ | | Index |
+ | | "cache" |
+ | +-----------+
+ | ^
+ | |
+ | | diff-files
+ | |
+ V V
+ +-----------+
+ | Working |
+ | Directory |
+ +-----------+
+============
+
+More interestingly, you can also give `git-diff-tree` the `--pretty` flag,
+which tells it to also show the commit message and author and date of the
+commit, and you can tell it to show a whole series of diffs.
+Alternatively, you can tell it to be "silent", and not show the diffs at
+all, but just show the actual commit message.
+
+In fact, together with the `git-rev-list` program (which generates a
+list of revisions), `git-diff-tree` ends up being a veritable fount of
+changes. A trivial (but very useful) script called `git-whatchanged` is
+included with git which does exactly this, and shows a log of recent
+activities.
+
+To see the whole history of our pitiful little git-tutorial project, you
+can do
+
+----------------
+$ git log
+----------------
+
+which shows just the log messages, or if we want to see the log together
+with the associated patches use the more complex (and much more
+powerful)
+
+----------------
+$ git-whatchanged -p --root
+----------------
+
+and you will see exactly what has changed in the repository over its
+short history.
+
+[NOTE]
+The `\--root` flag is a flag to `git-diff-tree` to tell it to
+show the initial aka 'root' commit too. Normally you'd probably not
+want to see the initial import diff, but since the tutorial project
+was started from scratch and is so small, we use it to make the result
+a bit more interesting.
+
+With that, you should now be having some inkling of what git does, and
+can explore on your own.
+
+[NOTE]
+Most likely, you are not directly using the core
+git Plumbing commands, but using Porcelain such as `git-add`, `git-rm'
+and `git-commit'.
+
+
+Tagging a version
+-----------------
+
+In git, there are two kinds of tags, a "light" one, and an "annotated tag".
+
+A "light" tag is technically nothing more than a branch, except we put
+it in the `.git/refs/tags/` subdirectory instead of calling it a `head`.
+So the simplest form of tag involves nothing more than
+
+------------------------------------------------
+$ git tag my-first-tag
+------------------------------------------------
+
+which just writes the current `HEAD` into the `.git/refs/tags/my-first-tag`
+file, after which point you can then use this symbolic name for that
+particular state. You can, for example, do
+
+----------------
+$ git diff my-first-tag
+----------------
+
+to diff your current state against that tag which at this point will
+obviously be an empty diff, but if you continue to develop and commit
+stuff, you can use your tag as an "anchor-point" to see what has changed
+since you tagged it.
+
+An "annotated tag" is actually a real git object, and contains not only a
+pointer to the state you want to tag, but also a small tag name and
+message, along with optionally a PGP signature that says that yes,
+you really did
+that tag. You create these annotated tags with either the `-a` or
+`-s` flag to `git tag`:
+
+----------------
+$ git tag -s <tagname>
+----------------
+
+which will sign the current `HEAD` (but you can also give it another
+argument that specifies the thing to tag, i.e., you could have tagged the
+current `mybranch` point by using `git tag <tagname> mybranch`).
+
+You normally only do signed tags for major releases or things
+like that, while the light-weight tags are useful for any marking you
+want to do -- any time you decide that you want to remember a certain
+point, just create a private tag for it, and you have a nice symbolic
+name for the state at that point.
+
+
+Copying repositories
+--------------------
+
+git repositories are normally totally self-sufficient and relocatable.
+Unlike CVS, for example, there is no separate notion of
+"repository" and "working tree". A git repository normally *is* the
+working tree, with the local git information hidden in the `.git`
+subdirectory. There is nothing else. What you see is what you got.
+
+[NOTE]
+You can tell git to split the git internal information from
+the directory that it tracks, but we'll ignore that for now: it's not
+how normal projects work, and it's really only meant for special uses.
+So the mental model of "the git information is always tied directly to
+the working tree that it describes" may not be technically 100%
+accurate, but it's a good model for all normal use.
+
+This has two implications:
+
+ - if you grow bored with the tutorial repository you created (or you've
+ made a mistake and want to start all over), you can just do simple
++
+----------------
+$ rm -rf git-tutorial
+----------------
++
+and it will be gone. There's no external repository, and there's no
+history outside the project you created.
+
+ - if you want to move or duplicate a git repository, you can do so. There
+ is `git clone` command, but if all you want to do is just to
+ create a copy of your repository (with all the full history that
+ went along with it), you can do so with a regular
+ `cp -a git-tutorial new-git-tutorial`.
++
+Note that when you've moved or copied a git repository, your git index
+file (which caches various information, notably some of the "stat"
+information for the files involved) will likely need to be refreshed.
+So after you do a `cp -a` to create a new copy, you'll want to do
++
+----------------
+$ git-update-index --refresh
+----------------
++
+in the new repository to make sure that the index file is up-to-date.
+
+Note that the second point is true even across machines. You can
+duplicate a remote git repository with *any* regular copy mechanism, be it
+`scp`, `rsync` or `wget`.
+
+When copying a remote repository, you'll want to at a minimum update the
+index cache when you do this, and especially with other peoples'
+repositories you often want to make sure that the index cache is in some
+known state (you don't know *what* they've done and not yet checked in),
+so usually you'll precede the `git-update-index` with a
+
+----------------
+$ git-read-tree --reset HEAD
+$ git-update-index --refresh
+----------------
+
+which will force a total index re-build from the tree pointed to by `HEAD`.
+It resets the index contents to `HEAD`, and then the `git-update-index`
+makes sure to match up all index entries with the checked-out files.
+If the original repository had uncommitted changes in its
+working tree, `git-update-index --refresh` notices them and
+tells you they need to be updated.
+
+The above can also be written as simply
+
+----------------
+$ git reset
+----------------
+
+and in fact a lot of the common git command combinations can be scripted
+with the `git xyz` interfaces. You can learn things by just looking
+at what the various git scripts do. For example, `git reset` used to be
+the above two lines implemented in `git-reset`, but some things like
+`git status` and `git commit` are slightly more complex scripts around
+the basic git commands.
+
+Many (most?) public remote repositories will not contain any of
+the checked out files or even an index file, and will *only* contain the
+actual core git files. Such a repository usually doesn't even have the
+`.git` subdirectory, but has all the git files directly in the
+repository.
+
+To create your own local live copy of such a "raw" git repository, you'd
+first create your own subdirectory for the project, and then copy the
+raw repository contents into the `.git` directory. For example, to
+create your own copy of the git repository, you'd do the following
+
+----------------
+$ mkdir my-git
+$ cd my-git
+$ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git
+----------------
+
+followed by
+
+----------------
+$ git-read-tree HEAD
+----------------
+
+to populate the index. However, now you have populated the index, and
+you have all the git internal files, but you will notice that you don't
+actually have any of the working tree files to work on. To get
+those, you'd check them out with
+
+----------------
+$ git-checkout-index -u -a
+----------------
+
+where the `-u` flag means that you want the checkout to keep the index
+up-to-date (so that you don't have to refresh it afterward), and the
+`-a` flag means "check out all files" (if you have a stale copy or an
+older version of a checked out tree you may also need to add the `-f`
+flag first, to tell git-checkout-index to *force* overwriting of any old
+files).
+
+Again, this can all be simplified with
+
+----------------
+$ git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ my-git
+$ cd my-git
+$ git checkout
+----------------
+
+which will end up doing all of the above for you.
+
+You have now successfully copied somebody else's (mine) remote
+repository, and checked it out.
+
+
+Creating a new branch
+---------------------
+
+Branches in git are really nothing more than pointers into the git
+object database from within the `.git/refs/` subdirectory, and as we
+already discussed, the `HEAD` branch is nothing but a symlink to one of
+these object pointers.
+
+You can at any time create a new branch by just picking an arbitrary
+point in the project history, and just writing the SHA1 name of that
+object into a file under `.git/refs/heads/`. You can use any filename you
+want (and indeed, subdirectories), but the convention is that the
+"normal" branch is called `master`. That's just a convention, though,
+and nothing enforces it.
+
+To show that as an example, let's go back to the git-tutorial repository we
+used earlier, and create a branch in it. You do that by simply just
+saying that you want to check out a new branch:
+
+------------
+$ git checkout -b mybranch
+------------
+
+will create a new branch based at the current `HEAD` position, and switch
+to it.
+
+[NOTE]
+================================================
+If you make the decision to start your new branch at some
+other point in the history than the current `HEAD`, you can do so by
+just telling `git checkout` what the base of the checkout would be.
+In other words, if you have an earlier tag or branch, you'd just do
+
+------------
+$ git checkout -b mybranch earlier-commit
+------------
+
+and it would create the new branch `mybranch` at the earlier commit,
+and check out the state at that time.
+================================================
+
+You can always just jump back to your original `master` branch by doing
+
+------------
+$ git checkout master
+------------
+
+(or any other branch-name, for that matter) and if you forget which
+branch you happen to be on, a simple
+
+------------
+$ cat .git/HEAD
+------------
+
+will tell you where it's pointing. To get the list of branches
+you have, you can say
+
+------------
+$ git branch
+------------
+
+which used to be nothing more than a simple script around `ls .git/refs/heads`.
+There will be an asterisk in front of the branch you are currently on.
+
+Sometimes you may wish to create a new branch _without_ actually
+checking it out and switching to it. If so, just use the command
+
+------------
+$ git branch <branchname> [startingpoint]
+------------
+
+which will simply _create_ the branch, but will not do anything further.
+You can then later -- once you decide that you want to actually develop
+on that branch -- switch to that branch with a regular `git checkout`
+with the branchname as the argument.
+
+
+Merging two branches
+--------------------
+
+One of the ideas of having a branch is that you do some (possibly
+experimental) work in it, and eventually merge it back to the main
+branch. So assuming you created the above `mybranch` that started out
+being the same as the original `master` branch, let's make sure we're in
+that branch, and do some work there.
+
+------------------------------------------------
+$ git checkout mybranch
+$ echo "Work, work, work" >>hello
+$ git commit -m "Some work." -i hello
+------------------------------------------------
+
+Here, we just added another line to `hello`, and we used a shorthand for
+doing both `git-update-index hello` and `git commit` by just giving the
+filename directly to `git commit`, with an `-i` flag (it tells
+git to 'include' that file in addition to what you have done to
+the index file so far when making the commit). The `-m` flag is to give the
+commit log message from the command line.
+
+Now, to make it a bit more interesting, let's assume that somebody else
+does some work in the original branch, and simulate that by going back
+to the master branch, and editing the same file differently there:
+
+------------
+$ git checkout master
+------------
+
+Here, take a moment to look at the contents of `hello`, and notice how they
+don't contain the work we just did in `mybranch` -- because that work
+hasn't happened in the `master` branch at all. Then do
+
+------------
+$ echo "Play, play, play" >>hello
+$ echo "Lots of fun" >>example
+$ git commit -m "Some fun." -i hello example
+------------
+
+since the master branch is obviously in a much better mood.
+
+Now, you've got two branches, and you decide that you want to merge the
+work done. Before we do that, let's introduce a cool graphical tool that
+helps you view what's going on:
+
+----------------
+$ gitk --all
+----------------
+
+will show you graphically both of your branches (that's what the `\--all`
+means: normally it will just show you your current `HEAD`) and their
+histories. You can also see exactly how they came to be from a common
+source.
+
+Anyway, let's exit `gitk` (`^Q` or the File menu), and decide that we want
+to merge the work we did on the `mybranch` branch into the `master`
+branch (which is currently our `HEAD` too). To do that, there's a nice
+script called `git merge`, which wants to know which branches you want
+to resolve and what the merge is all about:
+
+------------
+$ git merge -m "Merge work in mybranch" mybranch
+------------
+
+where the first argument is going to be used as the commit message if
+the merge can be resolved automatically.
+
+Now, in this case we've intentionally created a situation where the
+merge will need to be fixed up by hand, though, so git will do as much
+of it as it can automatically (which in this case is just merge the `example`
+file, which had no differences in the `mybranch` branch), and say:
+
+----------------
+ Auto-merging hello
+ CONFLICT (content): Merge conflict in hello
+ Automatic merge failed; fix up by hand
+----------------
+
+It tells you that it did an "Automatic merge", which
+failed due to conflicts in `hello`.
+
+Not to worry. It left the (trivial) conflict in `hello` in the same form you
+should already be well used to if you've ever used CVS, so let's just
+open `hello` in our editor (whatever that may be), and fix it up somehow.
+I'd suggest just making it so that `hello` contains all four lines:
+
+------------
+Hello World
+It's a new day for git
+Play, play, play
+Work, work, work
+------------
+
+and once you're happy with your manual merge, just do a
+
+------------
+$ git commit -i hello
+------------
+
+which will very loudly warn you that you're now committing a merge
+(which is correct, so never mind), and you can write a small merge
+message about your adventures in git-merge-land.
+
+After you're done, start up `gitk \--all` to see graphically what the
+history looks like. Notice that `mybranch` still exists, and you can
+switch to it, and continue to work with it if you want to. The
+`mybranch` branch will not contain the merge, but next time you merge it
+from the `master` branch, git will know how you merged it, so you'll not
+have to do _that_ merge again.
+
+Another useful tool, especially if you do not always work in X-Window
+environment, is `git show-branch`.
+
+------------------------------------------------
+$ git-show-branch --topo-order --more=1 master mybranch
+* [master] Merge work in mybranch
+ ! [mybranch] Some work.
+--
+- [master] Merge work in mybranch
+*+ [mybranch] Some work.
+* [master^] Some fun.
+------------------------------------------------
+
+The first two lines indicate that it is showing the two branches
+and the first line of the commit log message from their
+top-of-the-tree commits, you are currently on `master` branch
+(notice the asterisk `\*` character), and the first column for
+the later output lines is used to show commits contained in the
+`master` branch, and the second column for the `mybranch`
+branch. Three commits are shown along with their log messages.
+All of them have non blank characters in the first column (`*`
+shows an ordinary commit on the current branch, `-` is a merge commit), which
+means they are now part of the `master` branch. Only the "Some
+work" commit has the plus `+` character in the second column,
+because `mybranch` has not been merged to incorporate these
+commits from the master branch. The string inside brackets
+before the commit log message is a short name you can use to
+name the commit. In the above example, 'master' and 'mybranch'
+are branch heads. 'master^' is the first parent of 'master'
+branch head. Please see 'git-rev-parse' documentation if you
+see more complex cases.
+
+[NOTE]
+Without the '--more=1' option, 'git-show-branch' would not output the
+'[master^]' commit, as '[mybranch]' commit is a common ancestor of
+both 'master' and 'mybranch' tips. Please see 'git-show-branch'
+documentation for details.
+
+[NOTE]
+If there were more commits on the 'master' branch after the merge, the
+merge commit itself would not be shown by 'git-show-branch' by
+default. You would need to provide '--sparse' option to make the
+merge commit visible in this case.
+
+Now, let's pretend you are the one who did all the work in
+`mybranch`, and the fruit of your hard work has finally been merged
+to the `master` branch. Let's go back to `mybranch`, and run
+`git merge` to get the "upstream changes" back to your branch.
+
+------------
+$ git checkout mybranch
+$ git merge -m "Merge upstream changes." master
+------------
+
+This outputs something like this (the actual commit object names
+would be different)
+
+----------------
+Updating from ae3a2da... to a80b4aa....
+Fast forward
+ example | 1 +
+ hello | 1 +
+ 2 files changed, 2 insertions(+), 0 deletions(-)
+----------------
+
+Because your branch did not contain anything more than what are
+already merged into the `master` branch, the merge operation did
+not actually do a merge. Instead, it just updated the top of
+the tree of your branch to that of the `master` branch. This is
+often called 'fast forward' merge.
+
+You can run `gitk \--all` again to see how the commit ancestry
+looks like, or run `show-branch`, which tells you this.
+
+------------------------------------------------
+$ git show-branch master mybranch
+! [master] Merge work in mybranch
+ * [mybranch] Merge work in mybranch
+--
+-- [master] Merge work in mybranch
+------------------------------------------------
+
+
+Merging external work
+---------------------
+
+It's usually much more common that you merge with somebody else than
+merging with your own branches, so it's worth pointing out that git
+makes that very easy too, and in fact, it's not that different from
+doing a `git merge`. In fact, a remote merge ends up being nothing
+more than "fetch the work from a remote repository into a temporary tag"
+followed by a `git merge`.
+
+Fetching from a remote repository is done by, unsurprisingly,
+`git fetch`:
+
+----------------
+$ git fetch <remote-repository>
+----------------
+
+One of the following transports can be used to name the
+repository to download from:
+
+Rsync::
+ `rsync://remote.machine/path/to/repo.git/`
++
+Rsync transport is usable for both uploading and downloading,
+but is completely unaware of what git does, and can produce
+unexpected results when you download from the public repository
+while the repository owner is uploading into it via `rsync`
+transport. Most notably, it could update the files under
+`refs/` which holds the object name of the topmost commits
+before uploading the files in `objects/` -- the downloader would
+obtain head commit object name while that object itself is still
+not available in the repository. For this reason, it is
+considered deprecated.
+
+SSH::
+ `remote.machine:/path/to/repo.git/` or
++
+`ssh://remote.machine/path/to/repo.git/`
++
+This transport can be used for both uploading and downloading,
+and requires you to have a log-in privilege over `ssh` to the
+remote machine. It finds out the set of objects the other side
+lacks by exchanging the head commits both ends have and
+transfers (close to) minimum set of objects. It is by far the
+most efficient way to exchange git objects between repositories.
+
+Local directory::
+ `/path/to/repo.git/`
++
+This transport is the same as SSH transport but uses `sh` to run
+both ends on the local machine instead of running other end on
+the remote machine via `ssh`.
+
+git Native::
+ `git://remote.machine/path/to/repo.git/`
++
+This transport was designed for anonymous downloading. Like SSH
+transport, it finds out the set of objects the downstream side
+lacks and transfers (close to) minimum set of objects.
+
+HTTP(S)::
+ `http://remote.machine/path/to/repo.git/`
++
+Downloader from http and https URL
+first obtains the topmost commit object name from the remote site
+by looking at the specified refname under `repo.git/refs/` directory,
+and then tries to obtain the
+commit object by downloading from `repo.git/objects/xx/xxx\...`
+using the object name of that commit object. Then it reads the
+commit object to find out its parent commits and the associate
+tree object; it repeats this process until it gets all the
+necessary objects. Because of this behavior, they are
+sometimes also called 'commit walkers'.
++
+The 'commit walkers' are sometimes also called 'dumb
+transports', because they do not require any git aware smart
+server like git Native transport does. Any stock HTTP server
+that does not even support directory index would suffice. But
+you must prepare your repository with `git-update-server-info`
+to help dumb transport downloaders.
+
+Once you fetch from the remote repository, you `merge` that
+with your current branch.
+
+However -- it's such a common thing to `fetch` and then
+immediately `merge`, that it's called `git pull`, and you can
+simply do
+
+----------------
+$ git pull <remote-repository>
+----------------
+
+and optionally give a branch-name for the remote end as a second
+argument.
+
+[NOTE]
+You could do without using any branches at all, by
+keeping as many local repositories as you would like to have
+branches, and merging between them with `git pull`, just like
+you merge between branches. The advantage of this approach is
+that it lets you keep a set of files for each `branch` checked
+out and you may find it easier to switch back and forth if you
+juggle multiple lines of development simultaneously. Of
+course, you will pay the price of more disk usage to hold
+multiple working trees, but disk space is cheap these days.
+
+It is likely that you will be pulling from the same remote
+repository from time to time. As a short hand, you can store
+the remote repository URL in the local repository's config file
+like this:
+
+------------------------------------------------
+$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
+------------------------------------------------
+
+and use the "linus" keyword with `git pull` instead of the full URL.
+
+Examples.
+
+. `git pull linus`
+. `git pull linus tag v0.99.1`
+
+the above are equivalent to:
+
+. `git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD`
+. `git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1`
+
+
+How does the merge work?
+------------------------
+
+We said this tutorial shows what plumbing does to help you cope
+with the porcelain that isn't flushing, but we so far did not
+talk about how the merge really works. If you are following
+this tutorial the first time, I'd suggest to skip to "Publishing
+your work" section and come back here later.
+
+OK, still with me? To give us an example to look at, let's go
+back to the earlier repository with "hello" and "example" file,
+and bring ourselves back to the pre-merge state:
+
+------------
+$ git show-branch --more=2 master mybranch
+! [master] Merge work in mybranch
+ * [mybranch] Merge work in mybranch
+--
+-- [master] Merge work in mybranch
++* [master^2] Some work.
++* [master^] Some fun.
+------------
+
+Remember, before running `git merge`, our `master` head was at
+"Some fun." commit, while our `mybranch` head was at "Some
+work." commit.
+
+------------
+$ git checkout mybranch
+$ git reset --hard master^2
+$ git checkout master
+$ git reset --hard master^
+------------
+
+After rewinding, the commit structure should look like this:
+
+------------
+$ git show-branch
+* [master] Some fun.
+ ! [mybranch] Some work.
+--
+ + [mybranch] Some work.
+* [master] Some fun.
+*+ [mybranch^] New day.
+------------
+
+Now we are ready to experiment with the merge by hand.
+
+`git merge` command, when merging two branches, uses 3-way merge
+algorithm. First, it finds the common ancestor between them.
+The command it uses is `git-merge-base`:
+
+------------
+$ mb=$(git-merge-base HEAD mybranch)
+------------
+
+The command writes the commit object name of the common ancestor
+to the standard output, so we captured its output to a variable,
+because we will be using it in the next step. By the way, the common
+ancestor commit is the "New day." commit in this case. You can
+tell it by:
+
+------------
+$ git-name-rev $mb
+my-first-tag
+------------
+
+After finding out a common ancestor commit, the second step is
+this:
+
+------------
+$ git-read-tree -m -u $mb HEAD mybranch
+------------
+
+This is the same `git-read-tree` command we have already seen,
+but it takes three trees, unlike previous examples. This reads
+the contents of each tree into different 'stage' in the index
+file (the first tree goes to stage 1, the second to stage 2,
+etc.). After reading three trees into three stages, the paths
+that are the same in all three stages are 'collapsed' into stage
+0. Also paths that are the same in two of three stages are
+collapsed into stage 0, taking the SHA1 from either stage 2 or
+stage 3, whichever is different from stage 1 (i.e. only one side
+changed from the common ancestor).
+
+After 'collapsing' operation, paths that are different in three
+trees are left in non-zero stages. At this point, you can
+inspect the index file with this command:
+
+------------
+$ git-ls-files --stage
+100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example
+100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello
+100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
+100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
+------------
+
+In our example of only two files, we did not have unchanged
+files so only 'example' resulted in collapsing, but in real-life
+large projects, only small number of files change in one commit,
+and this 'collapsing' tends to trivially merge most of the paths
+fairly quickly, leaving only a handful the real changes in non-zero
+stages.
+
+To look at only non-zero stages, use `\--unmerged` flag:
+
+------------
+$ git-ls-files --unmerged
+100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello
+100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
+100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
+------------
+
+The next step of merging is to merge these three versions of the
+file, using 3-way merge. This is done by giving
+`git-merge-one-file` command as one of the arguments to
+`git-merge-index` command:
+
+------------
+$ git-merge-index git-merge-one-file hello
+Auto-merging hello.
+merge: warning: conflicts during merge
+ERROR: Merge conflict in hello.
+fatal: merge program failed
+------------
+
+`git-merge-one-file` script is called with parameters to
+describe those three versions, and is responsible to leave the
+merge results in the working tree.
+It is a fairly straightforward shell script, and
+eventually calls `merge` program from RCS suite to perform a
+file-level 3-way merge. In this case, `merge` detects
+conflicts, and the merge result with conflict marks is left in
+the working tree.. This can be seen if you run `ls-files
+--stage` again at this point:
+
+------------
+$ git-ls-files --stage
+100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example
+100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello
+100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
+100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
+------------
+
+This is the state of the index file and the working file after
+`git merge` returns control back to you, leaving the conflicting
+merge for you to resolve. Notice that the path `hello` is still
+unmerged, and what you see with `git diff` at this point is
+differences since stage 2 (i.e. your version).
+
+
+Publishing your work
+--------------------
+
+So, we can use somebody else's work from a remote repository, but
+how can *you* prepare a repository to let other people pull from
+it?
+
+You do your real work in your working tree that has your
+primary repository hanging under it as its `.git` subdirectory.
+You *could* make that repository accessible remotely and ask
+people to pull from it, but in practice that is not the way
+things are usually done. A recommended way is to have a public
+repository, make it reachable by other people, and when the
+changes you made in your primary working tree are in good shape,
+update the public repository from it. This is often called
+'pushing'.
+
+[NOTE]
+This public repository could further be mirrored, and that is
+how git repositories at `kernel.org` are managed.
+
+Publishing the changes from your local (private) repository to
+your remote (public) repository requires a write privilege on
+the remote machine. You need to have an SSH account there to
+run a single command, `git-receive-pack`.
+
+First, you need to create an empty repository on the remote
+machine that will house your public repository. This empty
+repository will be populated and be kept up-to-date by pushing
+into it later. Obviously, this repository creation needs to be
+done only once.
+
+[NOTE]
+`git push` uses a pair of programs,
+`git-send-pack` on your local machine, and `git-receive-pack`
+on the remote machine. The communication between the two over
+the network internally uses an SSH connection.
+
+Your private repository's git directory is usually `.git`, but
+your public repository is often named after the project name,
+i.e. `<project>.git`. Let's create such a public repository for
+project `my-git`. After logging into the remote machine, create
+an empty directory:
+
+------------
+$ mkdir my-git.git
+------------
+
+Then, make that directory into a git repository by running
+`git init`, but this time, since its name is not the usual
+`.git`, we do things slightly differently:
+
+------------
+$ GIT_DIR=my-git.git git-init
+------------
+
+Make sure this directory is available for others you want your
+changes to be pulled by via the transport of your choice. Also
+you need to make sure that you have the `git-receive-pack`
+program on the `$PATH`.
+
+[NOTE]
+Many installations of sshd do not invoke your shell as the login
+shell when you directly run programs; what this means is that if
+your login shell is `bash`, only `.bashrc` is read and not
+`.bash_profile`. As a workaround, make sure `.bashrc` sets up
+`$PATH` so that you can run `git-receive-pack` program.
+
+[NOTE]
+If you plan to publish this repository to be accessed over http,
+you should do `chmod +x my-git.git/hooks/post-update` at this
+point. This makes sure that every time you push into this
+repository, `git-update-server-info` is run.
+
+Your "public repository" is now ready to accept your changes.
+Come back to the machine you have your private repository. From
+there, run this command:
+
+------------
+$ git push <public-host>:/path/to/my-git.git master
+------------
+
+This synchronizes your public repository to match the named
+branch head (i.e. `master` in this case) and objects reachable
+from them in your current repository.
+
+As a real example, this is how I update my public git
+repository. Kernel.org mirror network takes care of the
+propagation to other publicly visible machines:
+
+------------
+$ git push master.kernel.org:/pub/scm/git/git.git/
+------------
+
+
+Packing your repository
+-----------------------
+
+Earlier, we saw that one file under `.git/objects/??/` directory
+is stored for each git object you create. This representation
+is efficient to create atomically and safely, but
+not so convenient to transport over the network. Since git objects are
+immutable once they are created, there is a way to optimize the
+storage by "packing them together". The command
+
+------------
+$ git repack
+------------
+
+will do it for you. If you followed the tutorial examples, you
+would have accumulated about 17 objects in `.git/objects/??/`
+directories by now. `git repack` tells you how many objects it
+packed, and stores the packed file in `.git/objects/pack`
+directory.
+
+[NOTE]
+You will see two files, `pack-\*.pack` and `pack-\*.idx`,
+in `.git/objects/pack` directory. They are closely related to
+each other, and if you ever copy them by hand to a different
+repository for whatever reason, you should make sure you copy
+them together. The former holds all the data from the objects
+in the pack, and the latter holds the index for random
+access.
+
+If you are paranoid, running `git-verify-pack` command would
+detect if you have a corrupt pack, but do not worry too much.
+Our programs are always perfect ;-).
+
+Once you have packed objects, you do not need to leave the
+unpacked objects that are contained in the pack file anymore.
+
+------------
+$ git prune-packed
+------------
+
+would remove them for you.
+
+You can try running `find .git/objects -type f` before and after
+you run `git prune-packed` if you are curious. Also `git
+count-objects` would tell you how many unpacked objects are in
+your repository and how much space they are consuming.
+
+[NOTE]
+`git pull` is slightly cumbersome for HTTP transport, as a
+packed repository may contain relatively few objects in a
+relatively large pack. If you expect many HTTP pulls from your
+public repository you might want to repack & prune often, or
+never.
+
+If you run `git repack` again at this point, it will say
+"Nothing to pack". Once you continue your development and
+accumulate the changes, running `git repack` again will create a
+new pack, that contains objects created since you packed your
+repository the last time. We recommend that you pack your project
+soon after the initial import (unless you are starting your
+project from scratch), and then run `git repack` every once in a
+while, depending on how active your project is.
+
+When a repository is synchronized via `git push` and `git pull`
+objects packed in the source repository are usually stored
+unpacked in the destination, unless rsync transport is used.
+While this allows you to use different packing strategies on
+both ends, it also means you may need to repack both
+repositories every once in a while.
+
+
+Working with Others
+-------------------
+
+Although git is a truly distributed system, it is often
+convenient to organize your project with an informal hierarchy
+of developers. Linux kernel development is run this way. There
+is a nice illustration (page 17, "Merges to Mainline") in
+link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation].
+
+It should be stressed that this hierarchy is purely *informal*.
+There is nothing fundamental in git that enforces the "chain of
+patch flow" this hierarchy implies. You do not have to pull
+from only one remote repository.
+
+A recommended workflow for a "project lead" goes like this:
+
+1. Prepare your primary repository on your local machine. Your
+ work is done there.
+
+2. Prepare a public repository accessible to others.
++
+If other people are pulling from your repository over dumb
+transport protocols (HTTP), you need to keep this repository
+'dumb transport friendly'. After `git init`,
+`$GIT_DIR/hooks/post-update` copied from the standard templates
+would contain a call to `git-update-server-info` but the
+`post-update` hook itself is disabled by default -- enable it
+with `chmod +x post-update`. This makes sure `git-update-server-info`
+keeps the necessary files up-to-date.
+
+3. Push into the public repository from your primary
+ repository.
+
+4. `git repack` the public repository. This establishes a big
+ pack that contains the initial set of objects as the
+ baseline, and possibly `git prune` if the transport
+ used for pulling from your repository supports packed
+ repositories.
+
+5. Keep working in your primary repository. Your changes
+ include modifications of your own, patches you receive via
+ e-mails, and merges resulting from pulling the "public"
+ repositories of your "subsystem maintainers".
++
+You can repack this private repository whenever you feel like.
+
+6. Push your changes to the public repository, and announce it
+ to the public.
+
+7. Every once in a while, "git repack" the public repository.
+ Go back to step 5. and continue working.
+
+
+A recommended work cycle for a "subsystem maintainer" who works
+on that project and has an own "public repository" goes like this:
+
+1. Prepare your work repository, by `git clone` the public
+ repository of the "project lead". The URL used for the
+ initial cloning is stored in the remote.origin.url
+ configuration variable.
+
+2. Prepare a public repository accessible to others, just like
+ the "project lead" person does.
+
+3. Copy over the packed files from "project lead" public
+ repository to your public repository, unless the "project
+ lead" repository lives on the same machine as yours. In the
+ latter case, you can use `objects/info/alternates` file to
+ point at the repository you are borrowing from.
+
+4. Push into the public repository from your primary
+ repository. Run `git repack`, and possibly `git prune` if the
+ transport used for pulling from your repository supports
+ packed repositories.
+
+5. Keep working in your primary repository. Your changes
+ include modifications of your own, patches you receive via
+ e-mails, and merges resulting from pulling the "public"
+ repositories of your "project lead" and possibly your
+ "sub-subsystem maintainers".
++
+You can repack this private repository whenever you feel
+like.
+
+6. Push your changes to your public repository, and ask your
+ "project lead" and possibly your "sub-subsystem
+ maintainers" to pull from it.
+
+7. Every once in a while, `git repack` the public repository.
+ Go back to step 5. and continue working.
+
+
+A recommended work cycle for an "individual developer" who does
+not have a "public" repository is somewhat different. It goes
+like this:
+
+1. Prepare your work repository, by `git clone` the public
+ repository of the "project lead" (or a "subsystem
+ maintainer", if you work on a subsystem). The URL used for
+ the initial cloning is stored in the remote.origin.url
+ configuration variable.
+
+2. Do your work in your repository on 'master' branch.
+
+3. Run `git fetch origin` from the public repository of your
+ upstream every once in a while. This does only the first
+ half of `git pull` but does not merge. The head of the
+ public repository is stored in `.git/refs/remotes/origin/master`.
+
+4. Use `git cherry origin` to see which ones of your patches
+ were accepted, and/or use `git rebase origin` to port your
+ unmerged changes forward to the updated upstream.
+
+5. Use `git format-patch origin` to prepare patches for e-mail
+ submission to your upstream and send it out. Go back to
+ step 2. and continue.
+
+
+Working with Others, Shared Repository Style
+--------------------------------------------
+
+If you are coming from CVS background, the style of cooperation
+suggested in the previous section may be new to you. You do not
+have to worry. git supports "shared public repository" style of
+cooperation you are probably more familiar with as well.
+
+See link:cvs-migration.html[git for CVS users] for the details.
+
+Bundling your work together
+---------------------------
+
+It is likely that you will be working on more than one thing at
+a time. It is easy to manage those more-or-less independent tasks
+using branches with git.
+
+We have already seen how branches work previously,
+with "fun and work" example using two branches. The idea is the
+same if there are more than two branches. Let's say you started
+out from "master" head, and have some new code in the "master"
+branch, and two independent fixes in the "commit-fix" and
+"diff-fix" branches:
+
+------------
+$ git show-branch
+! [commit-fix] Fix commit message normalization.
+ ! [diff-fix] Fix rename detection.
+ * [master] Release candidate #1
+---
+ + [diff-fix] Fix rename detection.
+ + [diff-fix~1] Better common substring algorithm.
++ [commit-fix] Fix commit message normalization.
+ * [master] Release candidate #1
+++* [diff-fix~2] Pretty-print messages.
+------------
+
+Both fixes are tested well, and at this point, you want to merge
+in both of them. You could merge in 'diff-fix' first and then
+'commit-fix' next, like this:
+
+------------
+$ git merge -m "Merge fix in diff-fix" diff-fix
+$ git merge -m "Merge fix in commit-fix" commit-fix
+------------
+
+Which would result in:
+
+------------
+$ git show-branch
+! [commit-fix] Fix commit message normalization.
+ ! [diff-fix] Fix rename detection.
+ * [master] Merge fix in commit-fix
+---
+ - [master] Merge fix in commit-fix
++ * [commit-fix] Fix commit message normalization.
+ - [master~1] Merge fix in diff-fix
+ +* [diff-fix] Fix rename detection.
+ +* [diff-fix~1] Better common substring algorithm.
+ * [master~2] Release candidate #1
+++* [master~3] Pretty-print messages.
+------------
+
+However, there is no particular reason to merge in one branch
+first and the other next, when what you have are a set of truly
+independent changes (if the order mattered, then they are not
+independent by definition). You could instead merge those two
+branches into the current branch at once. First let's undo what
+we just did and start over. We would want to get the master
+branch before these two merges by resetting it to 'master~2':
+
+------------
+$ git reset --hard master~2
+------------
+
+You can make sure 'git show-branch' matches the state before
+those two 'git merge' you just did. Then, instead of running
+two 'git merge' commands in a row, you would merge these two
+branch heads (this is known as 'making an Octopus'):
+
+------------
+$ git merge commit-fix diff-fix
+$ git show-branch
+! [commit-fix] Fix commit message normalization.
+ ! [diff-fix] Fix rename detection.
+ * [master] Octopus merge of branches 'diff-fix' and 'commit-fix'
+---
+ - [master] Octopus merge of branches 'diff-fix' and 'commit-fix'
++ * [commit-fix] Fix commit message normalization.
+ +* [diff-fix] Fix rename detection.
+ +* [diff-fix~1] Better common substring algorithm.
+ * [master~1] Release candidate #1
+++* [master~2] Pretty-print messages.
+------------
+
+Note that you should not do Octopus because you can. An octopus
+is a valid thing to do and often makes it easier to view the
+commit history if you are merging more than two independent
+changes at the same time. However, if you have merge conflicts
+with any of the branches you are merging in and need to hand
+resolve, that is an indication that the development happened in
+those branches were not independent after all, and you should
+merge two at a time, documenting how you resolved the conflicts,
+and the reason why you preferred changes made in one side over
+the other. Otherwise it would make the project history harder
+to follow, not easier.
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
new file mode 100644
index 0000000..ea98900
--- /dev/null
+++ b/Documentation/cvs-migration.txt
@@ -0,0 +1,171 @@
+git for CVS users
+=================
+
+Git differs from CVS in that every working tree contains a repository with
+a full copy of the project history, and no repository is inherently more
+important than any other. However, you can emulate the CVS model by
+designating a single shared repository which people can synchronize with;
+this document explains how to do that.
+
+Some basic familiarity with git is required. This
+link:tutorial.html[tutorial introduction to git] should be sufficient.
+
+Developing against a shared repository
+--------------------------------------
+
+Suppose a shared repository is set up in /pub/repo.git on the host
+foo.com. Then as an individual committer you can clone the shared
+repository over ssh with:
+
+------------------------------------------------
+$ git clone foo.com:/pub/repo.git/ my-project
+$ cd my-project
+------------------------------------------------
+
+and hack away. The equivalent of `cvs update` is
+
+------------------------------------------------
+$ git pull origin
+------------------------------------------------
+
+which merges in any work that others might have done since the clone
+operation. If there are uncommitted changes in your working tree, commit
+them first before running git pull.
+
+[NOTE]
+================================
+The `pull` command knows where to get updates from because of certain
+configuration variables that were set by the first `git clone`
+command; see `git config -l` and the linkgit:git-config[1] man
+page for details.
+================================
+
+You can update the shared repository with your changes by first committing
+your changes, and then using the linkgit:git-push[1] command:
+
+------------------------------------------------
+$ git push origin master
+------------------------------------------------
+
+to "push" those commits to the shared repository. If someone else has
+updated the repository more recently, `git push`, like `cvs commit`, will
+complain, in which case you must pull any changes before attempting the
+push again.
+
+In the `git push` command above we specify the name of the remote branch
+to update (`master`). If we leave that out, `git push` tries to update
+any branches in the remote repository that have the same name as a branch
+in the local repository. So the last `push` can be done with either of:
+
+------------
+$ git push origin
+$ git push foo.com:/pub/project.git/
+------------
+
+as long as the shared repository does not have any branches
+other than `master`.
+
+Setting Up a Shared Repository
+------------------------------
+
+We assume you have already created a git repository for your project,
+possibly created from scratch or from a tarball (see the
+link:tutorial.html[tutorial]), or imported from an already existing CVS
+repository (see the next section).
+
+Assume your existing repo is at /home/alice/myproject. Create a new "bare"
+repository (a repository without a working tree) and fetch your project into
+it:
+
+------------------------------------------------
+$ mkdir /pub/my-repo.git
+$ cd /pub/my-repo.git
+$ git --bare init --shared
+$ git --bare fetch /home/alice/myproject master:master
+------------------------------------------------
+
+Next, give every team member read/write access to this repository. One
+easy way to do this is to give all the team members ssh access to the
+machine where the repository is hosted. If you don't want to give them a
+full shell on the machine, there is a restricted shell which only allows
+users to do git pushes and pulls; see linkgit:git-shell[1].
+
+Put all the committers in the same group, and make the repository
+writable by that group:
+
+------------------------------------------------
+$ chgrp -R $group /pub/my-repo.git
+------------------------------------------------
+
+Make sure committers have a umask of at most 027, so that the directories
+they create are writable and searchable by other group members.
+
+Importing a CVS archive
+-----------------------
+
+First, install version 2.1 or higher of cvsps from
+link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make
+sure it is in your path. Then cd to a checked out CVS working directory
+of the project you are interested in and run linkgit:git-cvsimport[1]:
+
+-------------------------------------------
+$ git cvsimport -C <destination> <module>
+-------------------------------------------
+
+This puts a git archive of the named CVS module in the directory
+<destination>, which will be created if necessary.
+
+The import checks out from CVS every revision of every file. Reportedly
+cvsimport can average some twenty revisions per second, so for a
+medium-sized project this should not take more than a couple of minutes.
+Larger projects or remote repositories may take longer.
+
+The main trunk is stored in the git branch named `origin`, and additional
+CVS branches are stored in git branches with the same names. The most
+recent version of the main trunk is also left checked out on the `master`
+branch, so you can start adding your own changes right away.
+
+The import is incremental, so if you call it again next month it will
+fetch any CVS updates that have been made in the meantime. For this to
+work, you must not modify the imported branches; instead, create new
+branches for your own changes, and merge in the imported branches as
+necessary.
+
+Advanced Shared Repository Management
+-------------------------------------
+
+Git allows you to specify scripts called "hooks" to be run at certain
+points. You can use these, for example, to send all commits to the shared
+repository to a mailing list. See link:hooks.html[Hooks used by git].
+
+You can enforce finer grained permissions using update hooks. See
+link:howto/update-hook-example.txt[Controlling access to branches using
+update hooks].
+
+Providing CVS Access to a git Repository
+----------------------------------------
+
+It is also possible to provide true CVS access to a git repository, so
+that developers can still use CVS; see linkgit:git-cvsserver[1] for
+details.
+
+Alternative Development Models
+------------------------------
+
+CVS users are accustomed to giving a group of developers commit access to
+a common repository. As we've seen, this is also possible with git.
+However, the distributed nature of git allows other development models,
+and you may want to first consider whether one of them might be a better
+fit for your project.
+
+For example, you can choose a single person to maintain the project's
+primary public repository. Other developers then clone this repository
+and each work in their own clone. When they have a series of changes that
+they're happy with, they ask the maintainer to pull from the branch
+containing the changes. The maintainer reviews their changes and pulls
+them into the primary repository, which other developers pull from as
+necessary to stay coordinated. The Linux kernel and other projects use
+variants of this model.
+
+With a small group, developers may just pull changes from each other's
+repositories without the need for a central maintainer.
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
new file mode 100644
index 0000000..400cbb3
--- /dev/null
+++ b/Documentation/diff-format.txt
@@ -0,0 +1,147 @@
+The output format from "git-diff-index", "git-diff-tree",
+"git-diff-files" and "git diff --raw" are very similar.
+
+These commands all compare two sets of things; what is
+compared differs:
+
+git-diff-index <tree-ish>::
+ compares the <tree-ish> and the files on the filesystem.
+
+git-diff-index --cached <tree-ish>::
+ compares the <tree-ish> and the index.
+
+git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>...]::
+ compares the trees named by the two arguments.
+
+git-diff-files [<pattern>...]::
+ compares the index and the files on the filesystem.
+
+
+An output line is formatted this way:
+
+------------------------------------------------
+in-place edit :100644 100644 bcd1234... 0123456... M file0
+copy-edit :100644 100644 abcd123... 1234567... C68 file1 file2
+rename-edit :100644 100644 abcd123... 1234567... R86 file1 file3
+create :000000 100644 0000000... 1234567... A file4
+delete :100644 000000 1234567... 0000000... D file5
+unmerged :000000 000000 0000000... 0000000... U file6
+------------------------------------------------
+
+That is, from the left to the right:
+
+. a colon.
+. mode for "src"; 000000 if creation or unmerged.
+. a space.
+. mode for "dst"; 000000 if deletion or unmerged.
+. a space.
+. sha1 for "src"; 0\{40\} if creation or unmerged.
+. a space.
+. sha1 for "dst"; 0\{40\} if creation, unmerged or "look at work tree".
+. a space.
+. status, followed by optional "score" number.
+. a tab or a NUL when '-z' option is used.
+. path for "src"
+. a tab or a NUL when '-z' option is used; only exists for C or R.
+. path for "dst"; only exists for C or R.
+. an LF or a NUL when '-z' option is used, to terminate the record.
+
+<sha1> is shown as all 0's if a file is new on the filesystem
+and it is out of sync with the index.
+
+Example:
+
+------------------------------------------------
+:100644 100644 5be4a4...... 000000...... M file.c
+------------------------------------------------
+
+When `-z` option is not used, TAB, LF, and backslash characters
+in pathnames are represented as `\t`, `\n`, and `\\`,
+respectively.
+
+diff format for merges
+----------------------
+
+"git-diff-tree", "git-diff-files" and "git-diff --raw"
+can take '-c' or '--cc' option
+to generate diff output also for merge commits. The output differs
+from the format described above in the following way:
+
+. there is a colon for each parent
+. there are more "src" modes and "src" sha1
+. status is concatenated status characters for each parent
+. no optional "score" number
+. single path, only for "dst"
+
+Example:
+
+------------------------------------------------
+::100644 100644 100644 fabadb8... cc95eb0... 4866510... MM describe.c
+------------------------------------------------
+
+Note that 'combined diff' lists only files which were modified from
+all parents.
+
+
+include::diff-generate-patch.txt[]
+
+
+other diff formats
+------------------
+
+The `--summary` option describes newly added, deleted, renamed and
+copied files. The `--stat` option adds diffstat(1) graph to the
+output. These options can be combined with other options, such as
+`-p`, and are meant for human consumption.
+
+When showing a change that involves a rename or a copy, `--stat` output
+formats the pathnames compactly by combining common prefix and suffix of
+the pathnames. For example, a change that moves `arch/i386/Makefile` to
+`arch/x86/Makefile` while modifying 4 lines will be shown like this:
+
+------------------------------------
+arch/{i386 => x86}/Makefile | 4 +--
+------------------------------------
+
+The `--numstat` option gives the diffstat(1) information but is designed
+for easier machine consumption. An entry in `--numstat` output looks
+like this:
+
+----------------------------------------
+1 2 README
+3 1 arch/{i386 => x86}/Makefile
+----------------------------------------
+
+That is, from left to right:
+
+. the number of added lines;
+. a tab;
+. the number of deleted lines;
+. a tab;
+. pathname (possibly with rename/copy information);
+. a newline.
+
+When `-z` output option is in effect, the output is formatted this way:
+
+----------------------------------------
+1 2 README NUL
+3 1 NUL arch/i386/Makefile NUL arch/x86/Makefile NUL
+----------------------------------------
+
+That is:
+
+. the number of added lines;
+. a tab;
+. the number of deleted lines;
+. a tab;
+. a NUL (only exists if renamed/copied);
+. pathname in preimage;
+. a NUL (only exists if renamed/copied);
+. pathname in postimage (only exists if renamed/copied);
+. a NUL.
+
+The extra `NUL` before the preimage path in renamed case is to allow
+scripts that read the output to tell if the current record being read is
+a single-path record or a rename/copy record without reading ahead.
+After reading added and deleted lines, reading up to `NUL` would yield
+the pathname, but if that is `NUL`, the record will show two paths.
diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt
new file mode 100644
index 0000000..029c5f2
--- /dev/null
+++ b/Documentation/diff-generate-patch.txt
@@ -0,0 +1,161 @@
+Generating patches with -p
+--------------------------
+
+When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
+with a '-p' option, "git diff" without the '--raw' option, or
+"git log" with the "-p" option, they
+do not produce the output described above; instead they produce a
+patch file. You can customize the creation of such patches via the
+GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
+
+What the -p option produces is slightly different from the traditional
+diff format.
+
+1. It is preceded with a "git diff" header, that looks like
+ this:
+
+ diff --git a/file1 b/file2
++
+The `a/` and `b/` filenames are the same unless rename/copy is
+involved. Especially, even for a creation or a deletion,
+`/dev/null` is _not_ used in place of `a/` or `b/` filenames.
++
+When rename/copy is involved, `file1` and `file2` show the
+name of the source file of the rename/copy and the name of
+the file that rename/copy produces, respectively.
+
+2. It is followed by one or more extended header lines:
+
+ old mode <mode>
+ new mode <mode>
+ deleted file mode <mode>
+ new file mode <mode>
+ copy from <path>
+ copy to <path>
+ rename from <path>
+ rename to <path>
+ similarity index <number>
+ dissimilarity index <number>
+ index <hash>..<hash> <mode>
+
+3. TAB, LF, double quote and backslash characters in pathnames
+ are represented as `\t`, `\n`, `\"` and `\\`, respectively.
+ If there is need for such substitution then the whole
+ pathname is put in double quotes.
+
+The similarity index is the percentage of unchanged lines, and
+the dissimilarity index is the percentage of changed lines. It
+is a rounded down integer, followed by a percent sign. The
+similarity index value of 100% is thus reserved for two equal
+files, while 100% dissimilarity means that no line from the old
+file made it into the new one.
+
+
+combined diff format
+--------------------
+
+"git-diff-tree", "git-diff-files" and "git-diff" can take '-c' or
+'--cc' option to produce 'combined diff'. For showing a merge commit
+with "git log -p", this is the default format.
+A 'combined diff' format looks like this:
+
+------------
+diff --combined describe.c
+index fabadb8,cc95eb0..4866510
+--- a/describe.c
++++ b/describe.c
+@@@ -98,20 -98,12 +98,20 @@@
+ return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
+ }
+
+- static void describe(char *arg)
+ -static void describe(struct commit *cmit, int last_one)
+++static void describe(char *arg, int last_one)
+ {
+ + unsigned char sha1[20];
+ + struct commit *cmit;
+ struct commit_list *list;
+ static int initialized = 0;
+ struct commit_name *n;
+
+ + if (get_sha1(arg, sha1) < 0)
+ + usage(describe_usage);
+ + cmit = lookup_commit_reference(sha1);
+ + if (!cmit)
+ + usage(describe_usage);
+ +
+ if (!initialized) {
+ initialized = 1;
+ for_each_ref(get_name);
+------------
+
+1. It is preceded with a "git diff" header, that looks like
+ this (when '-c' option is used):
+
+ diff --combined file
++
+or like this (when '--cc' option is used):
+
+ diff --c file
+
+2. It is followed by one or more extended header lines
+ (this example shows a merge with two parents):
+
+ index <hash>,<hash>..<hash>
+ mode <mode>,<mode>..<mode>
+ new file mode <mode>
+ deleted file mode <mode>,<mode>
++
+The `mode <mode>,<mode>..<mode>` line appears only if at least one of
+the <mode> is different from the rest. Extended headers with
+information about detected contents movement (renames and
+copying detection) are designed to work with diff of two
+<tree-ish> and are not used by combined diff format.
+
+3. It is followed by two-line from-file/to-file header
+
+ --- a/file
+ +++ b/file
++
+Similar to two-line header for traditional 'unified' diff
+format,