Merge branch 'master' into sp/gfi
authorShawn O. Pearce <spearce@spearce.org>
Tue, 30 Jan 2007 16:07:24 +0000 (11:07 -0500)
committerShawn O. Pearce <spearce@spearce.org>
Tue, 30 Jan 2007 16:07:24 +0000 (11:07 -0500)
git-fast-import requires use of inttypes.h, but the master branch has
added it to git-compat-util differently than git-fast-import originally
had used it.  This merge back of master to the fast-import topic is to
get (and use) inttypes.h the way master is using it.

This is a partially evil merge to remove the call to setup_ident(),
as the master branch now contains a change which makes this implicit
and therefore removed the function declaration. (commit 01754769).

Conflicts:

git-compat-util.h

252 files changed:
.gitignore
.mailmap
Documentation/.gitignore
Documentation/Makefile
Documentation/SubmittingPatches
Documentation/cmd-list.perl [new file with mode: 0755]
Documentation/config.txt
Documentation/core-intro.txt [new file with mode: 0644]
Documentation/core-tutorial.txt
Documentation/cvs-migration.txt
Documentation/diff-options.txt
Documentation/everyday.txt
Documentation/git-add.txt
Documentation/git-am.txt
Documentation/git-apply.txt
Documentation/git-applypatch.txt
Documentation/git-archive.txt
Documentation/git-bisect.txt
Documentation/git-blame.txt
Documentation/git-branch.txt
Documentation/git-cat-file.txt
Documentation/git-checkout-index.txt
Documentation/git-checkout.txt
Documentation/git-cherry-pick.txt
Documentation/git-clone.txt
Documentation/git-commit-tree.txt
Documentation/git-commit.txt
Documentation/git-config.txt [new file with mode: 0644]
Documentation/git-count-objects.txt
Documentation/git-cvsexportcommit.txt
Documentation/git-cvsimport.txt
Documentation/git-daemon.txt
Documentation/git-describe.txt
Documentation/git-diff-stages.txt
Documentation/git-diff.txt
Documentation/git-fetch-pack.txt
Documentation/git-fetch.txt
Documentation/git-for-each-ref.txt
Documentation/git-format-patch.txt
Documentation/git-fsck-objects.txt
Documentation/git-fsck.txt [new file with mode: 0644]
Documentation/git-gc.txt
Documentation/git-grep.txt
Documentation/git-hash-object.txt
Documentation/git-http-fetch.txt
Documentation/git-http-push.txt
Documentation/git-init.txt
Documentation/git-instaweb.txt
Documentation/git-local-fetch.txt
Documentation/git-log.txt
Documentation/git-ls-files.txt
Documentation/git-ls-remote.txt
Documentation/git-ls-tree.txt
Documentation/git-mailinfo.txt
Documentation/git-mailsplit.txt
Documentation/git-merge-base.txt
Documentation/git-merge-file.txt
Documentation/git-merge-index.txt
Documentation/git-merge-one-file.txt
Documentation/git-merge.txt
Documentation/git-mv.txt
Documentation/git-pack-redundant.txt
Documentation/git-pack-refs.txt
Documentation/git-parse-remote.txt
Documentation/git-patch-id.txt
Documentation/git-peek-remote.txt
Documentation/git-prune-packed.txt
Documentation/git-prune.txt
Documentation/git-pull.txt
Documentation/git-push.txt
Documentation/git-rebase.txt
Documentation/git-receive-pack.txt
Documentation/git-reflog.txt
Documentation/git-remote.txt
Documentation/git-repack.txt
Documentation/git-repo-config.txt
Documentation/git-rerere.txt
Documentation/git-reset.txt
Documentation/git-resolve.txt
Documentation/git-rev-list.txt
Documentation/git-rev-parse.txt
Documentation/git-revert.txt
Documentation/git-rm.txt
Documentation/git-send-pack.txt
Documentation/git-sh-setup.txt
Documentation/git-shell.txt
Documentation/git-shortlog.txt
Documentation/git-show-branch.txt
Documentation/git-show.txt
Documentation/git-ssh-fetch.txt
Documentation/git-ssh-upload.txt
Documentation/git-status.txt
Documentation/git-svn.txt
Documentation/git-symbolic-ref.txt
Documentation/git-tag.txt
Documentation/git-tar-tree.txt
Documentation/git-tools.txt
Documentation/git-update-index.txt
Documentation/git-update-ref.txt
Documentation/git-upload-archive.txt
Documentation/git-upload-pack.txt
Documentation/git-var.txt
Documentation/git-whatchanged.txt
Documentation/git-write-tree.txt
Documentation/git.txt
Documentation/gitk.txt
Documentation/glossary.txt
Documentation/howto/dangling-objects.txt [new file with mode: 0644]
Documentation/howto/rebase-from-internal-branch.txt
Documentation/howto/setup-git-server-over-http.txt
Documentation/repository-layout.txt
Documentation/tutorial-2.txt
Documentation/tutorial.txt
GIT-VERSION-GEN
Makefile
README
builtin-add.c
builtin-apply.c
builtin-archive.c
builtin-blame.c
builtin-branch.c
builtin-commit-tree.c
builtin-config.c [moved from builtin-repo-config.c with 94% similarity]
builtin-describe.c
builtin-for-each-ref.c
builtin-fsck.c [moved from fsck-objects.c with 83% similarity]
builtin-init-db.c
builtin-log.c
builtin-pack-objects.c
builtin-pack-refs.c
builtin-prune-packed.c
builtin-push.c
builtin-reflog.c
builtin-rm.c
builtin-show-branch.c
builtin-symbolic-ref.c
builtin-update-ref.c
builtin.h
cache.h
commit.c
commit.h
config.c
connect.c
contrib/blameview/README [new file with mode: 0644]
contrib/blameview/blameview.perl [new file with mode: 0755]
contrib/completion/git-completion.bash
contrib/emacs/git.el
contrib/emacs/vc-git.el
contrib/gitview/gitview
contrib/remotes2config.sh
contrib/vim/syntax/gitcommit.vim
daemon.c
date.c
diffcore-pickaxe.c
fast-import.c
fetch-pack.c
git-checkout.sh
git-clone.sh
git-commit.sh
git-compat-util.h
git-cvsimport.perl
git-cvsserver.perl
git-fetch.sh
git-gc.sh
git-instaweb.sh
git-lost-found.sh
git-ls-remote.sh
git-merge.sh
git-p4import.py
git-parse-remote.sh
git-pull.sh
git-quiltimport.sh
git-rebase.sh
git-remote.perl
git-repack.sh
git-reset.sh
git-revert.sh
git-send-email.perl
git-sh-setup.sh
git-svn.perl
git-tag.sh
git.c
gitk
gitweb/gitweb.perl
http-fetch.c
http-push.c
ident.c
local-fetch.c
log-tree.c
merge-recursive.c
pack.h
peek-remote.c
perl/Git.pm
perl/Makefile.PL
quote.c
quote.h
receive-pack.c
reflog-walk.c [new file with mode: 0644]
reflog-walk.h [new file with mode: 0644]
refs.c
refs.h
revision.c
revision.h
send-pack.c
setup.c
sha1_file.c
sha1_name.c
shallow.c
ssh-fetch.c
t/lib-git-svn.sh
t/t1020-subdirectory.sh
t/t1300-repo-config.sh
t/t1400-update-ref.sh
t/t1410-reflog.sh
t/t3200-branch.sh
t/t3210-pack-refs.sh
t/t3501-revert-cherry-pick.sh [new file with mode: 0755]
t/t3700-add.sh
t/t3800-mktag.sh
t/t3900-i18n-commit.sh
t/t3901-8859-1.txt [new file with mode: 0755]
t/t3901-i18n-patch.sh [new file with mode: 0755]
t/t3901-utf8.txt [new file with mode: 0755]
t/t4000-diff-format.sh
t/t4006-diff-mode.sh
t/t4013-diff-various.sh
t/t4013/diff.format-patch_--attach_--stdout_initial..master
t/t4013/diff.format-patch_--attach_--stdout_initial..master^
t/t4013/diff.format-patch_--attach_--stdout_initial..side
t/t4013/diff.format-patch_--stdout_initial..master
t/t4013/diff.format-patch_--stdout_initial..master^
t/t4013/diff.format-patch_--stdout_initial..side
t/t4102-apply-rename.sh
t/t4200-rerere.sh
t/t5301-sliding-window.sh
t/t5400-send-pack.sh
t/t5401-update-hooks.sh
t/t5500-fetch-pack.sh
t/t5510-fetch.sh
t/t5710-info-alternate.sh
t/t6023-merge-file.sh
t/t6120-describe.sh [new file with mode: 0755]
t/t6200-fmt-merge-msg.sh
t/t7201-co.sh
t/t9102-git-svn-deep-rmdir.sh
t/t9103-git-svn-graft-branches.sh
t/t9200-git-cvsexportcommit.sh
templates/hooks--update
upload-pack.c
var.c
write_or_die.c
wt-status.c

index a9dc462..d499949 100644 (file)
@@ -23,6 +23,7 @@ git-clean
 git-clone
 git-commit
 git-commit-tree
+git-config
 git-convert-objects
 git-count-objects
 git-cvsexportcommit
@@ -42,6 +43,7 @@ git-findtags
 git-fmt-merge-msg
 git-for-each-ref
 git-format-patch
+git-fsck
 git-fsck-objects
 git-gc
 git-get-tar-commit-id
index 2c658f4..c7a3a75 100644 (file)
--- a/.mailmap
+++ b/.mailmap
@@ -30,7 +30,9 @@ Robert Fitzsimons <robfitz@273k.net>
 Santi Béjar <sbejar@gmail.com>
 Sean Estabrooks <seanlkml@sympatico.ca>
 Shawn O. Pearce <spearce@spearce.org>
+Theodore Ts'o <tytso@mit.edu>
 Tony Luck <tony.luck@intel.com>
+Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
 Ville Skyttä <scop@xemacs.org>
 YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
 anonymous <linux@horizon.com>
index c87c61a..6a51331 100644 (file)
@@ -4,4 +4,4 @@
 *.7
 howto-index.txt
 doc.dep
-README
+cmds-*.txt
index 93c7024..5314068 100644 (file)
@@ -71,14 +71,24 @@ doc.dep : $(wildcard *.txt) build-docdep.perl
 
 -include doc.dep
 
-git.7: README
+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
 
-README: ../README
-       cp $< $@
+$(cmds_txt): cmd-list.perl $(MAN1_TXT)
+       perl ./cmd-list.perl
 
+git.7 git.html: git.txt core-intro.txt
 
 clean:
-       rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep README
+       rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep
+       rm -f $(cmds_txt)
 
 %.html : %.txt
        asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
@@ -89,8 +99,6 @@ clean:
 %.xml : %.txt
        asciidoc -b docbook -d manpage -f asciidoc.conf $<
 
-git.html: git.txt README
-
 glossary.html : glossary.txt sort_glossary.pl
        cat $< | \
        perl sort_glossary.pl | \
index 646b6e7..ce85d06 100644 (file)
@@ -23,7 +23,8 @@ 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.
+in templates/hooks--pre-commit.  To help ensure this does not happen,
+run git diff --check on your changes before you commit.
 
 
 (2) Generate your patch using git tools out of your commits.
@@ -72,7 +73,9 @@ other than the commit message itself.  Place such "cover letter"
 material between the three dash lines and the diffstat.
 
 Do not attach the patch as a MIME attachment, compressed or not.
-Do not let your e-mail client send quoted-printable.  Many
+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
@@ -312,3 +315,19 @@ settings but I haven't tried, yet.
        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.
+
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
new file mode 100755 (executable)
index 0000000..6dba8d8
--- /dev/null
@@ -0,0 +1,186 @@
+#
+
+sub format_one {
+       my ($out, $name) = @_;
+       my ($state, $description);
+       open I, '<', "$name.txt" or die "No such file $name.txt";
+       while (<I>) {
+               if (/^NAME$/) {
+                       $state = 1;
+                       next;
+               }
+               if ($state == 1 && /^----$/) {
+                       $state = 2;
+                       next;
+               }
+               next if ($state != 2);
+               chomp;
+               $description = $_;
+               last;
+       }
+       close I;
+       if (!defined $description) {
+               die "No description found in $name.txt";
+       }
+       if (my ($verify_name, $text) = ($description =~ /^($name) - (.*)/)) {
+               print $out "gitlink:$name\[1\]::\n";
+               print $out "\t$text.\n\n";
+       }
+       else {
+               die "Description does not match $name: $description";
+       }
+}
+
+my %cmds = ();
+while (<DATA>) {
+       next if /^#/;
+
+       chomp;
+       my ($name, $cat) = /^(\S+)\s+(.*)$/;
+       push @{$cmds{$cat}}, $name;
+}
+
+for my $cat (qw(ancillaryinterrogators
+               ancillarymanipulators
+               mainporcelain
+               plumbinginterrogators
+               plumbingmanipulators
+               synchingrepositories
+               foreignscminterface
+               purehelpers
+               synchelpers)) {
+       my $out = "cmds-$cat.txt";
+       open O, '>', "$out+" or die "Cannot open output file $out+";
+       for (@{$cmds{$cat}}) {
+               format_one(\*O, $_);
+       }
+       close O;
+       rename "$out+", "$out";
+}
+
+__DATA__
+git-add                                 mainporcelain
+git-am                                  mainporcelain
+git-annotate                            ancillaryinterrogators
+git-applymbox                           ancillaryinterrogators
+git-applypatch                          purehelpers
+git-apply                               plumbingmanipulators
+git-archimport                          foreignscminterface
+git-archive                             mainporcelain
+git-bisect                              mainporcelain
+git-blame                               ancillaryinterrogators
+git-branch                              mainporcelain
+git-cat-file                            plumbinginterrogators
+git-checkout-index                      plumbingmanipulators
+git-checkout                            mainporcelain
+git-check-ref-format                    purehelpers
+git-cherry                              ancillaryinterrogators
+git-cherry-pick                         mainporcelain
+git-clean                               mainporcelain
+git-clone                               mainporcelain
+git-commit                              mainporcelain
+git-commit-tree                         plumbingmanipulators
+git-convert-objects                     ancillarymanipulators
+git-count-objects                       ancillaryinterrogators
+git-cvsexportcommit                     foreignscminterface
+git-cvsimport                           foreignscminterface
+git-cvsserver                           foreignscminterface
+git-daemon                              synchingrepositories
+git-describe                            mainporcelain
+git-diff-files                          plumbinginterrogators
+git-diff-index                          plumbinginterrogators
+git-diff                                mainporcelain
+git-diff-stages                         plumbinginterrogators
+git-diff-tree                           plumbinginterrogators
+git-fetch                               mainporcelain
+git-fetch-pack                          synchingrepositories
+git-fmt-merge-msg                       purehelpers
+git-for-each-ref                        plumbinginterrogators
+git-format-patch                        mainporcelain
+git-fsck                               ancillaryinterrogators
+git-gc                                  mainporcelain
+git-get-tar-commit-id                   ancillaryinterrogators
+git-grep                                mainporcelain
+git-hash-object                         plumbingmanipulators
+git-http-fetch                          synchelpers
+git-http-push                           synchelpers
+git-imap-send                           foreignscminterface
+git-index-pack                          plumbingmanipulators
+git-init                                mainporcelain
+git-instaweb                            ancillaryinterrogators
+gitk                                    mainporcelain
+git-local-fetch                         synchingrepositories
+git-log                                 mainporcelain
+git-lost-found                          ancillarymanipulators
+git-ls-files                            plumbinginterrogators
+git-ls-remote                           plumbinginterrogators
+git-ls-tree                             plumbinginterrogators
+git-mailinfo                            purehelpers
+git-mailsplit                           purehelpers
+git-merge-base                          plumbinginterrogators
+git-merge-file                          plumbingmanipulators
+git-merge-index                         plumbingmanipulators
+git-merge                               mainporcelain
+git-merge-one-file                      purehelpers
+git-merge-tree                          ancillaryinterrogators
+git-mktag                               plumbingmanipulators
+git-mktree                              plumbingmanipulators
+git-mv                                  mainporcelain
+git-name-rev                            plumbinginterrogators
+git-pack-objects                        plumbingmanipulators
+git-pack-redundant                      plumbinginterrogators
+git-pack-refs                           ancillarymanipulators
+git-parse-remote                        synchelpers
+git-patch-id                            purehelpers
+git-peek-remote                         purehelpers
+git-prune                               ancillarymanipulators
+git-prune-packed                        plumbingmanipulators
+git-pull                                mainporcelain
+git-push                                mainporcelain
+git-quiltimport                         foreignscminterface
+git-read-tree                           plumbingmanipulators
+git-rebase                              mainporcelain
+git-receive-pack                        synchelpers
+git-reflog                              ancillarymanipulators
+git-relink                              ancillarymanipulators
+git-repack                              ancillarymanipulators
+git-config                              ancillarymanipulators
+git-request-pull                        foreignscminterface
+git-rerere                              ancillaryinterrogators
+git-reset                               mainporcelain
+git-resolve                             mainporcelain
+git-revert                              mainporcelain
+git-rev-list                            plumbinginterrogators
+git-rev-parse                           ancillaryinterrogators
+git-rm                                  mainporcelain
+git-runstatus                           ancillaryinterrogators
+git-send-email                          foreignscminterface
+git-send-pack                           synchingrepositories
+git-shell                               synchelpers
+git-shortlog                            mainporcelain
+git-show                                mainporcelain
+git-show-branch                         ancillaryinterrogators
+git-show-index                          plumbinginterrogators
+git-show-ref                            plumbinginterrogators
+git-sh-setup                            purehelpers
+git-ssh-fetch                           synchingrepositories
+git-ssh-upload                          synchingrepositories
+git-status                              mainporcelain
+git-stripspace                          purehelpers
+git-svn                                 foreignscminterface
+git-svnimport                           foreignscminterface
+git-symbolic-ref                        plumbingmanipulators
+git-tag                                 mainporcelain
+git-tar-tree                            plumbinginterrogators
+git-unpack-file                         plumbinginterrogators
+git-unpack-objects                      plumbingmanipulators
+git-update-index                        plumbingmanipulators
+git-update-ref                          plumbingmanipulators
+git-update-server-info                  synchingrepositories
+git-upload-archive                      synchelpers
+git-upload-pack                         synchelpers
+git-var                                 plumbinginterrogators
+git-verify-pack                         plumbinginterrogators
+git-verify-tag                          ancillaryinterrogators
+git-whatchanged                         ancillaryinterrogators
+git-write-tree                          plumbingmanipulators
index f7dba89..e5e019f 100644 (file)
@@ -2,21 +2,84 @@ CONFIGURATION FILE
 ------------------
 
 The git configuration file contains a number of variables that affect
-the git command's behavior. They can be used by both the git plumbing
+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.
+
+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, lines containing strings enclosed in square
-brackets start sections and all the other lines are recognized
-as setting variables, in the form 'name = value'. If there is no equal
-sign on the line, the entire line is taken as 'name' and the variable
-is recognized as boolean "true". String values may be entirely or partially
-enclosed in double quotes; some variables may require special value format.
+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 '`\\`',
+respecitvely) 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
 ~~~~~~~
@@ -35,6 +98,10 @@ Example
                remote = origin
                merge = refs/heads/devel
 
+       # Proxy settings
+       [core]
+               gitProxy="ssh" for "ssh://kernel.org/"
+               gitProxy=default-proxy ; for the rest
 
 Variables
 ~~~~~~~~~
@@ -183,10 +250,15 @@ 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), or `reset` (the normal terminal color).  The value for
-       these configuration variables can be one of: `normal`, `bold`,
-       `dim`, `ul`, `blink`, `reverse`, `reset`, `black`, `red`,
-       `green`, `yellow`, `blue`, `magenta`, `cyan`, or `white`.
+       refs).
++
+The value for these configuration variables is a list of colors (at most
+two) and attributes (at most one), separated by spaces.  The colors
+accepted are `normal`, `black`, `red`, `green`, `yellow`, `blue`,
+`magenta`, `cyan` and `white`; the attributes are `bold`, `dim`, `ul`,
+`blink` and `reverse`.  The first color given is the foreground; the
+second is the background.  The position of the attribute, if any,
+doesn't matter.
 
 color.diff::
        When true (or `always`), always use colors in patch.
@@ -194,12 +266,13 @@ color.diff::
        colors only when the output is to the terminal.
 
 color.diff.<slot>::
-       Use customized color for diff colorization.  `<slot>`
-       specifies which part of the patch to use the specified
-       color, and is one of `plain` (context text), `meta`
-       (metainformation), `frag` (hunk header), `old` (removed
-       lines), or `new` (added lines).  The values of these
-       variables may be specified as in color.branch.<slot>.
+       Use customized color for diff colorization.  `<slot>` specifies
+       which part of the patch to use the specified color, and is one
+       of `plain` (context text), `meta` (metainformation), `frag`
+       (hunk header), `old` (removed lines), `new` (added lines),
+       `commit` (commit headers), or `whitespace` (highlighting dubious
+       whitespace).  The values of these variables may be specified as
+       in color.branch.<slot>.
 
 color.pager::
        A boolean to enable/disable colored output when the pager is in
@@ -228,6 +301,16 @@ diff.renames::
        will enable basic rename detection.  If set to "copies" or
        "copy", it will detect copies, as well.
 
+fetch.unpackLimit::
+       If the number of objects fetched over the git native
+       transfer is below this
+       limit, then the objects will be unpacked into loose object
+       files. However if the number of received objects equals or
+       exceeds this limit then the received pack will be stored as
+       a pack, after adding any missing delta bases.  Storing the
+       pack from a push can make the push operation complete faster,
+       especially on slow filesystems.
+
 format.headers::
        Additional email headers to include in a patch to be submitted
        by mail.  See gitlink:git-format-patch[1].
@@ -321,6 +404,13 @@ merge.summary::
        Whether to include summaries of merged commits in newly created
        merge commit messages. False by default.
 
+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.
+
 pack.window::
        The size of the window used by gitlink:git-pack-objects[1] when no
        window size is given on the command line. Defaults to 10.
@@ -344,6 +434,14 @@ remote.<name>.push::
        The default set of "refspec" for gitlink:git-push[1]. See
        gitlink:git-push[1].
 
+remote.<name>.receivepack::
+       The default program to execute on the remote side when pushing.  See
+       option \--exec of gitlink:git-push[1].
+
+remote.<name>.uploadpack::
+       The default program to execute on the remote side when fetching.  See
+       option \--exec of gitlink:git-fetch-pack[1].
+
 repack.usedeltabaseoffset::
        Allow gitlink:git-repack[1] to create packs that uses
        delta-base offset.  Defaults to false.
@@ -377,6 +475,13 @@ user.name::
        Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME'
        environment variables.  See gitlink:git-commit-tree[1].
 
+user.signingkey::
+       If gitlink:git-tag[1] is not selecting the key you want it to
+       automatically when creating a signed tag, you can override the
+       default selection with this variable.  This option is passed
+       unchanged to gpg's --local-user parameter, so you may specify a key
+       using any method that gpg supports.
+
 whatchanged.difftree::
        The default gitlink:git-diff-tree[1] arguments to be used
        for gitlink:git-whatchanged[1].
@@ -400,3 +505,8 @@ receive.denyNonFastForwards::
        even if that push is forced. This configuration variable is
        set when initializing a shared repository.
 
+transfer.unpackLimit::
+       When `fetch.unpackLimit` or `receive.unpackLimit` are
+       not set, the value of this variable is used instead.
+
+
diff --git a/Documentation/core-intro.txt b/Documentation/core-intro.txt
new file mode 100644 (file)
index 0000000..abafefc
--- /dev/null
@@ -0,0 +1,590 @@
+////////////////////////////////////////////////////////////////
+
+       GIT - the stupid content tracker
+
+////////////////////////////////////////////////////////////////
+
+"git" can mean anything, depending on your mood.
+
+ - random three-letter combination that is pronounceable, and not
+   actually used by any common UNIX command.  The fact that it is a
+   mispronunciation of "get" may or may not be relevant.
+ - stupid. contemptible and despicable. simple. Take your pick from the
+   dictionary of slang.
+ - "global information tracker": you're in a good mood, and it actually
+   works for you. Angels sing, and a light suddenly fills the room.
+ - "goddamn idiotic truckload of sh*t": when it breaks
+
+This is a (not so) stupid but extremely fast directory content manager.
+It doesn't do a whole lot at its core, but what it 'does' do is track
+directory contents efficiently.
+
+There are two object abstractions: the "object database", and the
+"current directory cache" aka "index".
+
+The Object Database
+~~~~~~~~~~~~~~~~~~~
+The object database is literally just a content-addressable collection
+of objects.  All objects are named by their content, which is
+approximated by the SHA1 hash of the object itself.  Objects may refer
+to other objects (by referencing their SHA1 hash), and so you can
+build up a hierarchy of objects.
+
+All objects have a statically determined "type" aka "tag", which is
+determined at object creation time, and which identifies the format of
+the object (i.e. how it is used, and how it can refer to other
+objects).  There are currently four different object types: "blob",
+"tree", "commit" and "tag".
+
+A "blob" object cannot refer to any other object, and is, like the type
+implies, a pure storage object containing some user data.  It is used to
+actually store the file data, i.e. a blob object is associated with some
+particular version of some file.
+
+A "tree" object is an object that ties one or more "blob" objects into a
+directory structure. In addition, a tree object can refer to other tree
+objects, thus creating a directory hierarchy.
+
+A "commit" object ties such directory hierarchies together into
+a DAG of revisions - each "commit" is associated with exactly one tree
+(the directory hierarchy at the time of the commit). In addition, a
+"commit" refers to one or more "parent" commit objects that describe the
+history of how we arrived at that directory hierarchy.
+
+As a special case, a commit object with no parents is called the "root"
+object, and is the point of an initial project commit.  Each project
+must have at least one root, and while you can tie several different
+root objects together into one project by creating a commit object which
+has two or more separate roots as its ultimate parents, that's probably
+just going to confuse people.  So aim for the notion of "one root object
+per project", even if git itself does not enforce that.
+
+A "tag" object symbolically identifies and can be used to sign other
+objects. It contains the identifier and type of another object, a
+symbolic name (of course!) and, optionally, a signature.
+
+Regardless of object type, all objects share the following
+characteristics: they are all deflated with zlib, and have a header
+that not only specifies their type, but also provides size information
+about the data in the object.  It's worth noting that the SHA1 hash
+that is used to name the object is the hash of the original data
+plus this header, so `sha1sum` 'file' does not match the object name
+for 'file'.
+(Historical note: in the dawn of the age of git the hash
+was the sha1 of the 'compressed' object.)
+
+As a result, the general consistency of an object can always be tested
+independently of the contents or the type of the object: all objects can
+be validated by verifying that (a) their hashes match the content of the
+file and (b) the object successfully inflates to a stream of bytes that
+forms a sequence of <ascii type without space> + <space> + <ascii decimal
+size> + <byte\0> + <binary object data>.
+
+The structured objects can further have their structure and
+connectivity to other objects verified. This is generally done with
+the `git-fsck` program, which generates a full dependency graph
+of all objects, and verifies their internal consistency (in addition
+to just verifying their superficial consistency through the hash).
+
+The object types in some more detail:
+
+Blob Object
+~~~~~~~~~~~
+A "blob" object is nothing but a binary blob of data, and doesn't
+refer to anything else.  There is no signature or any other
+verification of the data, so while the object is consistent (it 'is'
+indexed by its sha1 hash, so the data itself is certainly correct), it
+has absolutely no other attributes.  No name associations, no
+permissions.  It is purely a blob of data (i.e. normally "file
+contents").
+
+In particular, since the blob is entirely defined by its data, if two
+files in a directory tree (or in multiple different versions of the
+repository) have the same contents, they will share the same blob
+object. The object is totally independent of its location in the
+directory tree, and renaming a file does not change the object that
+file is associated with in any way.
+
+A blob is typically created when gitlink:git-update-index[1]
+is run, and its data can be accessed by gitlink:git-cat-file[1].
+
+Tree Object
+~~~~~~~~~~~
+The next hierarchical object type is the "tree" object.  A tree object
+is a list of mode/name/blob data, sorted by name.  Alternatively, the
+mode data may specify a directory mode, in which case instead of
+naming a blob, that name is associated with another TREE object.
+
+Like the "blob" object, a tree object is uniquely determined by the
+set contents, and so two separate but identical trees will always
+share the exact same object. This is true at all levels, i.e. it's
+true for a "leaf" tree (which does not refer to any other trees, only
+blobs) as well as for a whole subdirectory.
+
+For that reason a "tree" object is just a pure data abstraction: it
+has no history, no signatures, no verification of validity, except
+that since the contents are again protected by the hash itself, we can
+trust that the tree is immutable and its contents never change.
+
+So you can trust the contents of a tree to be valid, the same way you
+can trust the contents of a blob, but you don't know where those
+contents 'came' from.
+
+Side note on trees: since a "tree" object is a sorted list of
+"filename+content", you can create a diff between two trees without
+actually having to unpack two trees.  Just ignore all common parts,
+and your diff will look right.  In other words, you can effectively
+(and efficiently) tell the difference between any two random trees by
+O(n) where "n" is the size of the difference, rather than the size of
+the tree.
+
+Side note 2 on trees: since the name of a "blob" depends entirely and
+exclusively on its contents (i.e. there are no names or permissions
+involved), you can see trivial renames or permission changes by
+noticing that the blob stayed the same.  However, renames with data
+changes need a smarter "diff" implementation.
+
+A tree is created with gitlink:git-write-tree[1] and
+its data can be accessed by gitlink:git-ls-tree[1].
+Two trees can be compared with gitlink:git-diff-tree[1].
+
+Commit Object
+~~~~~~~~~~~~~
+The "commit" object is an object that introduces the notion of
+history into the picture.  In contrast to the other objects, it
+doesn't just describe the physical state of a tree, it describes how
+we got there, and why.
+
+A "commit" is defined by the tree-object that it results in, the
+parent commits (zero, one or more) that led up to that point, and a
+comment on what happened.  Again, a commit is not trusted per se:
+the contents are well-defined and "safe" due to the cryptographically
+strong signatures at all levels, but there is no reason to believe
+that the tree is "good" or that the merge information makes sense.
+The parents do not have to actually have any relationship with the
+result, for example.
+
+Note on commits: unlike real SCM's, commits do not contain
+rename information or file mode change information.  All of that is
+implicit in the trees involved (the result tree, and the result trees
+of the parents), and describing that makes no sense in this idiotic
+file manager.
+
+A commit is created with gitlink:git-commit-tree[1] and
+its data can be accessed by gitlink:git-cat-file[1].
+
+Trust
+~~~~~
+An aside on the notion of "trust". Trust is really outside the scope
+of "git", but it's worth noting a few things.  First off, since
+everything is hashed with SHA1, you 'can' trust that an object is
+intact and has not been messed with by external sources.  So the name
+of an object uniquely identifies a known state - just not a state that
+you may want to trust.
+
+Furthermore, since the SHA1 signature of a commit refers to the
+SHA1 signatures of the tree it is associated with and the signatures
+of the parent, a single named commit specifies uniquely a whole set
+of history, with full contents.  You can't later fake any step of the
+way once you have the name of a commit.
+
+So to introduce some real trust in the system, the only thing you need
+to do is to digitally sign just 'one' special note, which includes the
+name of a top-level commit.  Your digital signature shows others
+that you trust that commit, and the immutability of the history of
+commits tells others that they can trust the whole history.
+
+In other words, you can easily validate a whole archive by just
+sending out a single email that tells the people the name (SHA1 hash)
+of the top commit, and digitally sign that email using something
+like GPG/PGP.
+
+To assist in this, git also provides the tag object...
+
+Tag Object
+~~~~~~~~~~
+Git provides the "tag" object to simplify creating, managing and
+exchanging symbolic and signed tokens.  The "tag" object at its
+simplest simply symbolically identifies another object by containing
+the sha1, type and symbolic name.
+
+However it can optionally contain additional signature information
+(which git doesn't care about as long as there's less than 8k of
+it). This can then be verified externally to git.
+
+Note that despite the tag features, "git" itself only handles content
+integrity; the trust framework (and signature provision and
+verification) has to come from outside.
+
+A tag is created with gitlink:git-mktag[1],
+its data can be accessed by gitlink:git-cat-file[1],
+and the signature can be verified by
+gitlink:git-verify-tag[1].
+
+
+The "index" aka "Current Directory Cache"
+-----------------------------------------
+The index is a simple binary file, which contains an efficient
+representation of a virtual directory content at some random time.  It
+does so by a simple array that associates a set of names, dates,
+permissions and content (aka "blob") objects together.  The cache is
+always kept ordered by name, and names are unique (with a few very
+specific rules) at any point in time, but the cache has no long-term
+meaning, and can be partially updated at any time.
+
+In particular, the index certainly does not need to be consistent with
+the current directory contents (in fact, most operations will depend on
+different ways to make the index 'not' be consistent with the directory
+hierarchy), but it has three very important attributes:
+
+'(a) it can re-generate the full state it caches (not just the
+directory structure: it contains pointers to the "blob" objects so
+that it can regenerate the data too)'
+
+As a special case, there is a clear and unambiguous one-way mapping
+from a current directory cache to a "tree object", which can be
+efficiently created from just the current directory cache without
+actually looking at any other data.  So a directory cache at any one
+time uniquely specifies one and only one "tree" object (but has
+additional data to make it easy to match up that tree object with what
+has happened in the directory)
+
+'(b) it has efficient methods for finding inconsistencies between that
+cached state ("tree object waiting to be instantiated") and the
+current state.'
+
+'(c) it can additionally efficiently represent information about merge
+conflicts between different tree objects, allowing each pathname to be
+associated with sufficient information about the trees involved that
+you can create a three-way merge between them.'
+
+Those are the three ONLY things that the directory cache does.  It's a
+cache, and the normal operation is to re-generate it completely from a
+known tree object, or update/compare it with a live tree that is being
+developed.  If you blow the directory cache away entirely, you generally
+haven't lost any information as long as you have the name of the tree
+that it described.
+
+At the same time, the index is at the same time also the
+staging area for creating new trees, and creating a new tree always
+involves a controlled modification of the index file.  In particular,
+the index file can have the representation of an intermediate tree that
+has not yet been instantiated.  So the index can be thought of as a
+write-back cache, which can contain dirty information that has not yet
+been written back to the backing store.
+
+
+
+The Workflow
+------------
+Generally, all "git" operations work on the index file. Some operations
+work *purely* on the index file (showing the current state of the
+index), but most operations move data to and from the index file. Either
+from the database or from the working directory. Thus there are four
+main combinations:
+
+1) working directory -> index
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You update the index with information from the working directory with
+the gitlink:git-update-index[1] command.  You
+generally update the index information by just specifying the filename
+you want to update, like so:
+
+       git-update-index filename
+
+but to avoid common mistakes with filename globbing etc, the command
+will not normally add totally new entries or remove old entries,
+i.e. it will normally just update existing cache entries.
+
+To tell git that yes, you really do realize that certain files no
+longer exist, or that new files should be added, you
+should use the `--remove` and `--add` flags respectively.
+
+NOTE! A `--remove` flag does 'not' mean that subsequent filenames will
+necessarily be removed: if the files still exist in your directory
+structure, the index will be updated with their new status, not
+removed. The only thing `--remove` means is that update-cache will be
+considering a removed file to be a valid thing, and if the file really
+does not exist any more, it will update the index accordingly.
+
+As a special case, you can also do `git-update-index --refresh`, which
+will refresh the "stat" information of each index to match the current
+stat information. It will 'not' update the object status itself, and
+it will only update the fields that are used to quickly test whether
+an object still matches its old backing store object.
+
+2) index -> object database
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You write your current index file to a "tree" object with the program
+
+       git-write-tree
+
+that doesn't come with any options - it will just write out the
+current index into the set of tree objects that describe that state,
+and it will return the name of the resulting top-level tree. You can
+use that tree to re-generate the index at any time by going in the
+other direction:
+
+3) object database -> index
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You read a "tree" file from the object database, and use that to
+populate (and overwrite - don't do this if your index contains any
+unsaved state that you might want to restore later!) your current
+index.  Normal operation is just
+
+               git-read-tree <sha1 of tree>
+
+and your index file will now be equivalent to the tree that you saved
+earlier. However, that is only your 'index' file: your working
+directory contents have not been modified.
+
+4) index -> working directory
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You update your working directory from the index by "checking out"
+files. This is not a very common operation, since normally you'd just
+keep your files updated, and rather than write to your working
+directory, you'd tell the index files about the changes in your
+working directory (i.e. `git-update-index`).
+
+However, if you decide to jump to a new version, or check out somebody
+else's version, or just restore a previous tree, you'd populate your
+index file with read-tree, and then you need to check out the result
+with
+
+               git-checkout-index filename
+
+or, if you want to check out all of the index, use `-a`.
+
+NOTE! git-checkout-index normally refuses to overwrite old files, so
+if you have an old version of the tree already checked out, you will
+need to use the "-f" flag ('before' the "-a" flag or the filename) to
+'force' the checkout.
+
+
+Finally, there are a few odds and ends which are not purely moving
+from one representation to the other:
+
+5) Tying it all together
+~~~~~~~~~~~~~~~~~~~~~~~~
+To commit a tree you have instantiated with "git-write-tree", you'd
+create a "commit" object that refers to that tree and the history
+behind it - most notably the "parent" commits that preceded it in
+history.
+
+Normally a "commit" has one parent: the previous state of the tree
+before a certain change was made. However, sometimes it can have two
+or more parent commits, in which case we call it a "merge", due to the
+fact that such a commit brings together ("merges") two or more
+previous states represented by other commits.
+
+In other words, while a "tree" represents a particular directory state
+of a working directory, a "commit" represents that state in "time",
+and explains how we got there.
+
+You create a commit object by giving it the tree that describes the
+state at the time of the commit, and a list of parents:
+
+       git-commit-tree <tree> -p <parent> [-p <parent2> ..]
+
+and then giving the reason for the commit on stdin (either through
+redirection from a pipe or file, or by just typing it at the tty).
+
+git-commit-tree will return the name of the object that represents
+that commit, and you should save it away for later use. Normally,
+you'd commit a new `HEAD` state, and while git doesn't care where you
+save the note about that state, in practice we tend to just write the
+result to the file pointed at by `.git/HEAD`, so that we can always see
+what the last committed state was.
+
+Here is an ASCII art by Jon Loeliger that illustrates how
+various pieces fit together.
+
+------------
+
+                     commit-tree
+                      commit obj
+                       +----+
+                       |    |
+                       |    |
+                       V    V
+                    +-----------+
+                    | Object DB |
+                    |  Backing  |
+                    |   Store   |
+                    +-----------+
+                       ^
+           write-tree  |     |
+             tree obj  |     |
+                       |     |  read-tree
+                       |     |  tree obj
+                             V
+                    +-----------+
+                    |   Index   |
+                    |  "cache"  |
+                    +-----------+
+         update-index  ^
+             blob obj  |     |
+                       |     |
+    checkout-index -u  |     |  checkout-index
+             stat      |     |  blob obj
+                             V
+                    +-----------+
+                    |  Working  |
+                    | Directory |
+                    +-----------+
+
+------------
+
+
+6) Examining the data
+~~~~~~~~~~~~~~~~~~~~~
+
+You can examine the data represented in the object database and the
+index with various helper tools. For every object, you can use
+gitlink:git-cat-file[1] to examine details about the
+object:
+
+               git-cat-file -t <objectname>
+
+shows the type of the object, and once you have the type (which is
+usually implicit in where you find the object), you can use
+
+               git-cat-file blob|tree|commit|tag <objectname>
+
+to show its contents. NOTE! Trees have binary content, and as a result
+there is a special helper for showing that content, called
+`git-ls-tree`, which turns the binary content into a more easily
+readable form.
+
+It's especially instructive to look at "commit" objects, since those
+tend to be small and fairly self-explanatory. In particular, if you
+follow the convention of having the top commit name in `.git/HEAD`,
+you can do
+
+               git-cat-file commit HEAD
+
+to see what the top commit was.
+
+7) Merging multiple trees
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Git helps you do a three-way merge, which you can expand to n-way by
+repeating the merge procedure arbitrary times until you finally
+"commit" the state.  The normal situation is that you'd only do one
+three-way merge (two parents), and commit it, but if you like to, you
+can do multiple parents in one go.
+
+To do a three-way merge, you need the two sets of "commit" objects
+that you want to merge, use those to find the closest common parent (a
+third "commit" object), and then use those commit objects to find the
+state of the directory ("tree" object) at these points.
+
+To get the "base" for the merge, you first look up the common parent
+of two commits with
+
+               git-merge-base <commit1> <commit2>
+
+which will return you the commit they are both based on.  You should
+now look up the "tree" objects of those commits, which you can easily
+do with (for example)
+
+               git-cat-file commit <commitname> | head -1
+
+since the tree object information is always the first line in a commit
+object.
+
+Once you know the three trees you are going to merge (the one
+"original" tree, aka the common case, and the two "result" trees, aka
+the branches you want to merge), you do a "merge" read into the
+index. This will complain if it has to throw away your old index contents, so you should
+make sure that you've committed those - in fact you would normally
+always do a merge against your last commit (which should thus match
+what you have in your current index anyway).
+
+To do the merge, do
+
+               git-read-tree -m -u <origtree> <yourtree> <targettree>
+
+which will do all trivial merge operations for you directly in the
+index file, and you can just write the result out with
+`git-write-tree`.
+
+Historical note.  We did not have `-u` facility when this
+section was first written, so we used to warn that
+the merge is done in the index file, not in your
+working tree, and your working tree will not match your
+index after this step.
+This is no longer true.  The above command, thanks to `-u`
+option, updates your working tree with the merge results for
+paths that have been trivially merged.
+
+
+8) Merging multiple trees, continued
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sadly, many merges aren't trivial. If there are files that have
+been added.moved or removed, or if both branches have modified the
+same file, you will be left with an index tree that contains "merge
+entries" in it. Such an index tree can 'NOT' be written out to a tree
+object, and you will have to resolve any such merge clashes using
+other tools before you can write out the result.
+
+You can examine such index state with `git-ls-files --unmerged`
+command.  An example:
+
+------------------------------------------------
+$ git-read-tree -m $orig HEAD $target
+$ git-ls-files --unmerged
+100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1      hello.c
+100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2      hello.c
+100644 cc44c73eb783565da5831b4d820c962954019b69 3      hello.c
+------------------------------------------------
+
+Each line of the `git-ls-files --unmerged` output begins with
+the blob mode bits, blob SHA1, 'stage number', and the
+filename.  The 'stage number' is git's way to say which tree it
+came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD`
+tree, and stage3 `$target` tree.
+
+Earlier we said that trivial merges are done inside
+`git-read-tree -m`.  For example, if the file did not change
+from `$orig` to `HEAD` nor `$target`, or if the file changed
+from `$orig` to `HEAD` and `$orig` to `$target` the same way,
+obviously the final outcome is what is in `HEAD`.  What the
+above example shows is that file `hello.c` was changed from
+`$orig` to `HEAD` and `$orig` to `$target` in a different way.
+You could resolve this by running your favorite 3-way merge
+program, e.g.  `diff3` or `merge`, on the blob objects from
+these three stages yourself, like this:
+
+------------------------------------------------
+$ git-cat-file blob 263414f... >hello.c~1
+$ git-cat-file blob 06fa6a2... >hello.c~2
+$ git-cat-file blob cc44c73... >hello.c~3
+$ merge hello.c~2 hello.c~1 hello.c~3
+------------------------------------------------
+
+This would leave the merge result in `hello.c~2` file, along
+with conflict markers if there are conflicts.  After verifying
+the merge result makes sense, you can tell git what the final
+merge result for this file is by:
+
+       mv -f hello.c~2 hello.c
+       git-update-index hello.c
+
+When a path is in unmerged state, running `git-update-index` for
+that path tells git to mark the path resolved.
+
+The above is the description of a git merge at the lowest level,
+to help you understand what conceptually happens under the hood.
+In practice, nobody, not even git itself, uses three `git-cat-file`
+for this.  There is `git-merge-index` program that extracts the
+stages to temporary files and calls a "merge" script on it:
+
+       git-merge-index git-merge-one-file hello.c
+
+and that is what higher level `git resolve` is implemented with.
index 0cd33fb..86a9c75 100644 (file)
@@ -906,18 +906,13 @@ 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:
 
 ----------------
-       Trying really trivial in-index merge...
-       fatal: Merge requires file-level merging
-       Nope.
-       ...
        Auto-merging hello 
        CONFLICT (content): Merge conflict in hello 
        Automatic merge failed; fix up by hand
 ----------------
 
-which is way too verbose, but it basically tells you that it failed the
-really trivial merge ("Simple merge") and did an "Automatic merge"
-instead, but that too failed due to conflicts in `hello`.
+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
@@ -1129,46 +1124,26 @@ 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.
 
-[NOTE]
-You could even pull from your own repository by
-giving '.' as <remote-repository> parameter to `git pull`.  This
-is useful when you want to merge a local branch (or more, if you
-are making an Octopus) into the current branch.
-
 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 a file under .git/remotes/
-directory, like this:
-
-------------------------------------------------
-$ mkdir -p .git/remotes/
-$ cat >.git/remotes/linus <<\EOF
-URL: http://www.kernel.org/pub/scm/git/git.git/
-EOF
-------------------------------------------------
-
-and use the filename to `git pull` instead of the full URL.
-The URL specified in such file can even be a prefix
-of a full URL, like this:
+the remote repository URL in the local repository's config file
+like this:
 
 ------------------------------------------------
-$ cat >.git/remotes/jgarzik <<\EOF
-URL: http://www.kernel.org/pub/scm/linux/git/jgarzik/
-EOF
+$ 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`
-. `git pull jgarzik/netdev-2.6.git/ e100`
 
 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`
-. `git pull http://www.kernel.org/pub/.../jgarzik/netdev-2.6.git e100`
 
 
 How does the merge work?
@@ -1546,7 +1521,8 @@ 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 `.git/remotes/origin`.
+   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.
@@ -1586,14 +1562,15 @@ 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 `.git/remotes/origin`.
+   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/heads/origin`.
+   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
@@ -1681,11 +1658,11 @@ $ 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 pull these two
+two 'git merge' commands in a row, you would merge these two
 branch heads (this is known as 'making an Octopus'):
 
 ------------
-$ git pull . commit-fix diff-fix
+$ git merge commit-fix diff-fix
 $ git show-branch
 ! [commit-fix] Fix commit message normalization.
  ! [diff-fix] Fix rename detection.
@@ -1701,7 +1678,7 @@ $ git show-branch
 
 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 pulling more than two independent
+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
index 775bf42..764cc56 100644 (file)
@@ -36,7 +36,7 @@ them first before running git pull.
 ================================
 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 repo-config -l` and the gitlink:git-repo-config[1] man
+command; see `git config -l` and the gitlink:git-config[1] man
 page for details.
 ================================
 
index da1cc60..019a39f 100644 (file)
        Turn off rename detection, even when the configuration
        file gives the default to do so.
 
+--check::
+       Warn if changes introduce trailing whitespace
+       or an indent that uses a space before a tab.
+
 --full-index::
        Instead of the first handful characters, show full
        object name of pre- and post-image blob on the "index"
index 4e83994..08c61b1 100644 (file)
@@ -28,7 +28,7 @@ Everybody uses these commands to maintain git repositories.
   * gitlink:git-init[1] or gitlink:git-clone[1] to create a
     new repository.
 
-  * gitlink:git-fsck-objects[1] to check the repository for errors.
+  * gitlink:git-fsck[1] to check the repository for errors.
 
   * gitlink:git-prune[1] to remove unused objects in the repository.
 
@@ -43,7 +43,7 @@ Examples
 Check health and remove cruft.::
 +
 ------------
-$ git fsck-objects <1>
+$ git fsck <1>
 $ git count-objects <2>
 $ git repack <3>
 $ git gc <4>
@@ -148,8 +148,7 @@ modification will be caught if you do `git commit -a` later.
 <8> redo the commit undone in the previous step, using the message
 you originally wrote.
 <9> switch to the master branch.
-<10> merge a topic branch into your master branch.  You can also use
-`git pull . alsa-audio`, i.e. pull from the local repository.
+<10> merge a topic branch into your master branch.
 <11> review commit logs; other forms to limit output can be
 combined and include `\--max-count=10` (show 10 commits),
 `\--until=2005-12-10`, etc.
@@ -213,12 +212,12 @@ Push into another repository.::
 ------------
 satellite$ git clone mothership:frotz frotz <1>
 satellite$ cd frotz
-satellite$ git repo-config --get-regexp '^(remote|branch)\.' <2>
+satellite$ git config --get-regexp '^(remote|branch)\.' <2>
 remote.origin.url mothership:frotz
 remote.origin.fetch refs/heads/*:refs/remotes/origin/*
 branch.master.remote origin
 branch.master.merge refs/heads/master
-satellite$ git repo-config remote.origin.push \
+satellite$ git config remote.origin.push \
            master:refs/remotes/satellite/master <3>
 satellite$ edit/compile/test/commit
 satellite$ git push origin <4>
index 95bea66..b73a99d 100644 (file)
@@ -7,7 +7,7 @@ git-add - Add file contents to the changeset to be committed next
 
 SYNOPSIS
 --------
-'git-add' [-n] [-v] [-f] [--interactive] [--] <file>...
+'git-add' [-n] [-v] [-f] [--interactive | -i] [--] <file>...
 
 DESCRIPTION
 -----------
@@ -52,7 +52,7 @@ OPTIONS
 -f::
        Allow adding otherwise ignored files.
 
-\--interactive::
+\i, \--interactive::
        Add modified contents in the working tree interactively to
        the index.
 
@@ -83,7 +83,7 @@ git-add git-*.sh::
 Interactive mode
 ----------------
 When the command enters the interactive mode, it shows the
-output of the 'status' subcommand, and then goes into ints
+output of the 'status' subcommand, and then goes into its
 interactive command loop.
 
 The command loop shows the list of subcommands available, and
index 53e81cb..aa4ce1d 100644 (file)
@@ -3,7 +3,7 @@ git-am(1)
 
 NAME
 ----
-git-am - Apply a series of patches in a mailbox
+git-am - Apply a series of patches from a mailbox
 
 
 SYNOPSIS
index 33b93db..065ba1b 100644 (file)
@@ -3,7 +3,7 @@ git-apply(1)
 
 NAME
 ----
-git-apply - Apply patch on a git index file and a work tree
+git-apply - Apply a patch on a git index file and a working tree
 
 
 SYNOPSIS
index 2b1ff14..451434a 100644 (file)
@@ -12,6 +12,9 @@ SYNOPSIS
 
 DESCRIPTION
 -----------
+This is usually not what an end user wants to run directly.  See
+gitlink:git-am[1] instead.
+
 Takes three files <msg>, <patch>, and <info> prepared from an
 e-mail message by 'git-mailinfo', and creates a commit.  It is
 usually not necessary to use this command directly.
index 031fcd5..493474b 100644 (file)
@@ -3,7 +3,7 @@ git-archive(1)
 
 NAME
 ----
-git-archive - Creates a archive of the files in the named tree
+git-archive - Creates an archive of files from a named tree
 
 
 SYNOPSIS
index ac4b496..16ec726 100644 (file)
@@ -3,7 +3,7 @@ git-bisect(1)
 
 NAME
 ----
-git-bisect - Find the change that introduced a bug
+git-bisect - Find the change that introduced a bug by binary search
 
 
 SYNOPSIS
index bdfc666..0ee887d 100644 (file)
@@ -8,7 +8,7 @@ git-blame - Show what revision and author last modified each line of a file
 SYNOPSIS
 --------
 [verse]
-'git-blame' [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S <revs-file>]
+'git-blame' [-c] [-l] [-t] [-f] [-n] [-p] [--incremental] [-L n,m] [-S <revs-file>]
             [-M] [-C] [-C] [--since=<date>] [<rev>] [--] <file>
 
 DESCRIPTION
@@ -24,7 +24,7 @@ replaced; you need to use a tool such as gitlink:git-diff[1] or the "pickaxe"
 interface briefly mentioned in the following paragraph.
 
 Apart from supporting file annotation, git also supports searching the
-development history for when a code snippet occured in a change. This makes it
+development history for when a code snippet occurred in a change. This makes it
 possible to track when a code snippet was added to a file, moved or copied
 between files, and eventually deleted or replaced. It works by searching for
 a text string in the diff. A small example:
@@ -63,6 +63,10 @@ OPTIONS
 -p, --porcelain::
        Show in a format designed for machine consumption.
 
+--incremental::
+       Show the result incrementally in a format designed for
+       machine consumption.
+
 -M::
        Detect moving lines in the file as well.  When a commit
        moves a block of lines in a file (e.g. the original file
@@ -89,7 +93,7 @@ THE PORCELAIN FORMAT
 --------------------
 
 In this format, each line is output after a header; the
-header at the minumum has the first line which has:
+header at the minimum has the first line which has:
 
 - 40-byte SHA-1 of the commit the line is attributed to;
 - the line number of the line in the original file;
@@ -112,15 +116,18 @@ header, prefixed by a TAB. This is to allow adding more
 header elements later.
 
 
-SPECIFIYING RANGES
-------------------
+SPECIFYING RANGES
+-----------------
 
 Unlike `git-blame` and `git-annotate` in older git, the extent
 of annotation can be limited to both line ranges and revision
 ranges.  When you are interested in finding the origin for
-ll. 40-60 for file `foo`, you can use `-L` option like this:
+ll. 40-60 for file `foo`, you can use `-L` option like these
+(they mean the same thing -- both ask for 21 lines starting at
+line 40):
 
        git blame -L 40,60 foo
+       git blame -L 40,+21 foo
 
 Also you can use regular expression to specify the line range.
 
@@ -155,6 +162,47 @@ parents, using `commit{caret}!` notation:
        git blame -C -C -f $commit^! -- foo
 
 
+INCREMENTAL OUTPUT
+------------------
+
+When called with `--incremental` option, the command outputs the
+result as it is built.  The output generally will talk about
+lines touched by more recent commits first (i.e. the lines will
+be annotated out of order) and is meant to be used by
+interactive viewers.
+
+The output format is similar to the Porcelain format, but it
+does not contain the actual lines from the file that is being
+annotated.
+
+. Each blame entry always starts with a line of:
+
+       <40-byte hex sha1> <sourceline> <resultline> <num_lines>
++
+Line numbers count from 1.
+
+. The first time that commit shows up in the stream, it has various
+  other information about it printed out with a one-word tag at the
+  beginning of each line about that "extended commit info" (author,
+  email, committer, dates, summary etc).
+
+. Unlike Porcelain format, the filename information is always
+  given and terminates the entry:
+
+       "filename" <whitespace-quoted-filename-goes-here>
++
+and thus it's really quite easy to parse for some line- and word-oriented
+parser (which should be quite natural for most scripting languages).
++
+[NOTE]
+For people who do parsing: to make it more robust, just ignore any
+lines in between the first and last one ("<sha1>" and "filename" lines)
+where you don't recognize the tag-words (or care about that particular
+one) at the beginning of the "extended information" lines. That way, if
+there is ever added information (like the commit encoding or extended
+commit commentary), a blame viewer won't ever care.
+
+
 SEE ALSO
 --------
 gitlink:git-annotate[1]
index e872fc8..aa1fdd4 100644 (file)
@@ -3,7 +3,7 @@ git-branch(1)
 
 NAME
 ----
-git-branch - List, create, or delete branches.
+git-branch - List, create, or delete branches
 
 SYNOPSIS
 --------
@@ -74,7 +74,7 @@ OPTIONS
        List both remote-tracking branches and local branches.
 
 -v::
-       Show sha1 and commit subjectline for each head.
+       Show sha1 and commit subject line for each head.
 
 --abbrev=<length>::
        Alter minimum display length for sha1 in output listing,
index 5e9cbf8..7e90ce9 100644 (file)
@@ -3,7 +3,7 @@ git-cat-file(1)
 
 NAME
 ----
-git-cat-file - Provide content or type information for repository objects
+git-cat-file - Provide content or type/size information for repository objects
 
 
 SYNOPSIS
index 765c173..6dd6db0 100644 (file)
@@ -3,7 +3,7 @@ git-checkout-index(1)
 
 NAME
 ----
-git-checkout-index - Copy files from the index to the working directory
+git-checkout-index - Copy files from the index to the working tree
 
 
 SYNOPSIS
index fbdbadc..c44a4a8 100644 (file)
@@ -9,7 +9,7 @@ SYNOPSIS
 --------
 [verse]
 'git-checkout' [-f] [-b <new_branch> [-l]] [-m] [<branch>]
-'git-checkout' [-m] [<branch>] <paths>...
+'git-checkout' [<branch>] <paths>...
 
 DESCRIPTION
 -----------
@@ -63,7 +63,57 @@ and mark the resolved paths with `git update-index`.
 
 <branch>::
        Branch to checkout; may be any object ID that resolves to a
-       commit. Defaults to HEAD.
+       commit.  Defaults to HEAD.
++
+When this parameter names a non-branch (but still a valid commit object),
+your HEAD becomes 'detached'.
+
+
+Detached HEAD
+-------------
+
+It is sometimes useful to be able to 'checkout' a commit that is
+not at the tip of one of your branches.  The most obvious
+example is to check out the commit at a tagged official release
+point, like this:
+
+------------
+$ git checkout v2.6.18
+------------
+
+Earlier versions of git did not allow this and asked you to
+create a temporary branch using `-b` option, but starting from
+version 1.5.0, the above command 'detaches' your HEAD from the
+current branch and directly point at the commit named by the tag
+(`v2.6.18` in the above example).
+
+You can use usual git commands while in this state.  You can use
+`git-reset --hard $othercommit` to further move around, for
+example.  You can make changes and create a new commit on top of
+a detached HEAD.  You can even create a merge by using `git
+merge $othercommit`.
+
+The state you are in while your HEAD is detached is not recorded
+by any branch (which is natural --- you are not on any branch).
+What this means is that you can discard your temporary commits
+and merges by switching back to an existing branch (e.g. `git
+checkout master`), and a later `git prune` or `git gc` would
+garbage-collect them.
+
+The command would refuse to switch back to make sure that you do
+not discard your temporary state by mistake when your detached
+HEAD is not pointed at by any existing ref.  If you did want to
+save your state (e.g. "I was interested in the fifth commit from
+the top of 'master' branch", or "I made two commits to fix minor
+bugs while on a detached HEAD" -- and if you do not want to lose
+these facts), you can create a new branch and switch to it with
+`git checkout -b newbranch` so that you can keep building on
+that state, or tag it first so that you can come back to it
+later and switch to the branch you wanted to switch to with `git
+tag that_state; git checkout master`.  On the other hand, if you
+did want to discard the temporary state, you can give `-f`
+option (e.g. `git checkout -f master`) to override this
+behaviour.
 
 
 EXAMPLES
index 875edb6..3149d08 100644 (file)
@@ -19,6 +19,8 @@ OPTIONS
 -------
 <commit>::
        Commit to cherry-pick.
+       For a more complete list of ways to spell commits, see
+       "SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
 
 -e|--edit::
        With this option, `git-cherry-pick` will let you edit the commit
index a782074..707376f 100644 (file)
@@ -3,7 +3,7 @@ git-clone(1)
 
 NAME
 ----
-git-clone - Clones a repository
+git-clone - Clones a repository into a new directory
 
 
 SYNOPSIS
index 77ba96e..cf25507 100644 (file)
@@ -3,7 +3,7 @@ git-commit-tree(1)
 
 NAME
 ----
-git-commit-tree - Creates a new commit object
+git-commit-tree - Create a new commit object
 
 
 SYNOPSIS
@@ -12,6 +12,9 @@ SYNOPSIS
 
 DESCRIPTION
 -----------
+This is usually not what an end user wants to run directly.  See
+gitlink:git-commit[1] instead.
+
 Creates a new commit object based on the provided tree object and
 emits the new commit object id on stdout. If no parent is given then
 it is considered to be an initial tree.
index b4528d7..2187eee 100644 (file)
@@ -3,13 +3,13 @@ git-commit(1)
 
 NAME
 ----
-git-commit - Record your changes
+git-commit - Record changes to the repository
 
 SYNOPSIS
 --------
 [verse]
-'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]
-          [--no-verify] [--amend] [-e] [--author <author>]
+'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg> |
+           --amend] [--no-verify] [-e] [--author <author>]
           [--] [[-i | -o ]<file>...]
 
 DESCRIPTION
@@ -111,7 +111,7 @@ but can be used to amend a merge commit.
        are concluding a conflicted merge.
 
 -q|--quiet::
-       Supress commit summary message.
+       Suppress commit summary message.
 
 \--::
        Do not interpret any more arguments as options.
@@ -142,11 +142,6 @@ $ git add hello.c
 $ git commit
 ------------
 
-////////////
-We should fix 'git rm' to remove goodbye.c from both index and
-working tree for the above example.
-////////////
-
 Instead of staging files after each individual change, you can
 tell `git commit` to notice the changes to the files whose
 contents are tracked in
@@ -223,6 +218,12 @@ refuses to run when given pathnames (but see `-i` option).
 DISCUSSION
 ----------
 
+Though not required, it's a good idea to begin the commit message
+with a single short (less than 50 character) line summarizing the
+change, followed by a blank line and then a more thorough description.
+Tools that turn commits into email, for example, use the first line
+on the Subject: line and the rest of the commit in the body.
+
 include::i18n.txt[]
 
 ENVIRONMENT VARIABLES
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
new file mode 100644 (file)
index 0000000..6624484
--- /dev/null
@@ -0,0 +1,227 @@
+git-config(1)
+=============
+
+NAME
+----
+git-config - Get and set repository or global options
+
+
+SYNOPSIS
+--------
+[verse]
+'git-config' [--global] [type] name [value [value_regex]]
+'git-config' [--global] [type] --add name value
+'git-config' [--global] [type] --replace-all name [value [value_regex]]
+'git-config' [--global] [type] --get name [value_regex]
+'git-config' [--global] [type] --get-all name [value_regex]
+'git-config' [--global] [type] --unset name [value_regex]
+'git-config' [--global] [type] --unset-all name [value_regex]
+'git-config' [--global] -l | --list
+
+DESCRIPTION
+-----------
+You can query/set/replace/unset options with this command. The name is
+actually the section and the key separated by a dot, and the value will be
+escaped.
+
+Multiple lines can be added to an option by using the '--add' option.
+If you want to update or unset an option which can occur on multiple
+lines, a POSIX regexp `value_regex` needs to be given.  Only the
+existing values that match the regexp are updated or unset.  If
+you want to handle the lines that do *not* match the regex, just
+prepend a single exclamation mark in front (see EXAMPLES).
+
+The type specifier can be either '--int' or '--bool', which will make
+'git-config' ensure that the variable(s) are of the given type and
+convert the value to the canonical form (simple decimal number for int,
+a "true" or "false" string for bool). If no type specifier is passed,
+no checks or transformations are performed on the value.
+
+This command will fail if:
+
+. The .git/config file is invalid,
+. Can not write to .git/config,
+. no section was provided,
+. the section or key is invalid,
+. you try to unset an option which does not exist,
+. you try to unset/set an option for which multiple lines match, or
+. you use --global option without $HOME being properly set.
+
+
+OPTIONS
+-------
+
+--replace-all::
+       Default behavior is to replace at most one line. This replaces
+       all lines matching the key (and optionally the value_regex).
+
+--add::
+       Adds a new line to the option without altering any existing
+       values.  This is the same as providing '^$' as the value_regex.
+
+--get::
+       Get the value for a given key (optionally filtered by a regex
+       matching the value). Returns error code 1 if the key was not
+       found and error code 2 if multiple key values were found.
+
+--get-all::
+       Like get, but does not fail if the number of values for the key
+       is not exactly one.
+
+--get-regexp::
+       Like --get-all, but interprets the name as a regular expression.
+
+--global::
+       Use global ~/.gitconfig file rather than the repository .git/config.
+
+--unset::
+       Remove the line matching the key from config file.
+
+--unset-all::
+       Remove all matching lines from config file.
+
+-l, --list::
+       List all variables set in config file.
+
+--bool::
+       git-config will ensure that the output is "true" or "false"
+
+--int::
+       git-config will ensure that the output is a simple
+       decimal number.  An optional value suffix of 'k', 'm', or 'g'
+       in the config file will cause the value to be multiplied
+       by 1024, 1048576, or 1073741824 prior to output.
+
+
+ENVIRONMENT
+-----------
+
+GIT_CONFIG::
+       Take the configuration from the given file instead of .git/config.
+       Using the "--global" option forces this to ~/.gitconfig.
+
+GIT_CONFIG_LOCAL::
+       Currently the same as $GIT_CONFIG; when Git will support global
+       configuration files, this will cause it to take the configuration
+       from the global configuration file in addition to the given file.
+
+
+EXAMPLE
+-------
+
+Given a .git/config like this:
+
+       #
+       # This is the config file, and
+       # a '#' or ';' character indicates
+       # a comment
+       #
+
+       ; core variables
+       [core]
+               ; Don't trust file modes
+               filemode = false
+
+       ; Our diff algorithm
+       [diff]
+               external = "/usr/local/bin/gnu-diff -u"
+               renames = true
+
+       ; Proxy settings
+       [core]
+               gitproxy="ssh" for "ssh://kernel.org/"
+               gitproxy="proxy-command" for kernel.org
+               gitproxy="myprotocol-command" for "my://"
+               gitproxy=default-proxy ; for all the rest
+
+you can set the filemode to true with
+
+------------
+% git config core.filemode true
+------------
+
+The hypothetical proxy command entries actually have a postfix to discern
+what URL they apply to. Here is how to change the entry for kernel.org
+to "ssh".
+
+------------
+% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'
+------------
+
+This makes sure that only the key/value pair for kernel.org is replaced.
+
+To delete the entry for renames, do
+
+------------
+% git config --unset diff.renames
+------------
+
+If you want to delete an entry for a multivar (like core.gitproxy above),
+you have to provide a regex matching the value of exactly one line.
+
+To query the value for a given key, do
+
+------------
+% git config --get core.filemode
+------------
+
+or
+
+------------
+% git config core.filemode
+------------
+
+or, to query a multivar:
+
+------------
+% git config --get core.gitproxy "for kernel.org$"
+------------
+
+If you want to know all the values for a multivar, do:
+
+------------
+% git config --get-all core.gitproxy
+------------
+
+If you like to live dangerous, you can replace *all* core.gitproxy by a
+new one with
+
+------------
+% git config --replace-all core.gitproxy ssh
+------------
+
+However, if you really only want to replace the line for the default proxy,
+i.e. the one without a "for ..." postfix, do something like this:
+
+------------
+% git config core.gitproxy ssh '! for '
+------------
+
+To actually match only values with an exclamation mark, you have to
+
+------------
+% git config section.key value '[!]'
+------------
+
+To add a new proxy, without altering any of the existing ones, use
+
+------------
+% git config core.gitproxy '"proxy" for example.com'
+------------
+
+
+include::config.txt[]
+
+
+Author
+------
+Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
+
+Documentation
+--------------
+Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
index c59df64..91c8c92 100644 (file)
@@ -3,7 +3,7 @@ git-count-objects(1)
 
 NAME
 ----
-git-count-objects - Reports on unpacked objects
+git-count-objects - Count unpacked number of objects and their disk consumption
 
 SYNOPSIS
 --------
index 092d0d6..347cbce 100644 (file)
@@ -3,7 +3,7 @@ git-cvsexportcommit(1)
 
 NAME
 ----
-git-cvsexportcommit - Export a commit to a CVS checkout
+git-cvsexportcommit - Export a single commit to a CVS checkout
 
 
 SYNOPSIS
index 5c402de..f5450de 100644 (file)
@@ -3,7 +3,7 @@ git-cvsimport(1)
 
 NAME
 ----
-git-cvsimport - Import a CVS repository into git
+git-cvsimport - Salvage your data out of another SCM people love to hate
 
 
 SYNOPSIS
@@ -97,7 +97,7 @@ If you need to pass multiple options, separate them with a comma.
        Substitute the character "/" in branch names with <subst>
 
 -A <author-conv-file>::
-       CVS by default uses the unix username when writing its
+       CVS by default uses the Unix username when writing its
        commit logs. Using this option and an author-conv-file
        in this format
 
index 993adc7..9ddab71 100644 (file)
@@ -131,14 +131,14 @@ Giving these options is an error when used with `--inetd`; use
 the facility of inet daemon to achieve the same before spawning
 `git-daemon` if needed.
 
---enable-service, --disable-service::
+--enable=service, --disable=service::
        Enable/disable the service site-wide per default.  Note
        that a service disabled site-wide can still be enabled
        per repository if it is marked overridable and the
        repository enables the service with an configuration
        item.
 
---allow-override, --forbid-override::
+--allow-override=service, --forbid-override=service::
        Allow/forbid overriding the site-wide default with per
        repository configuration.  By default, all the services
        are overridable.
index 2700f35..47a583d 100644 (file)
@@ -14,8 +14,8 @@ DESCRIPTION
 -----------
 The command finds the most recent tag that is reachable from a
 commit, and if the commit itself is pointed at by the tag, shows
-the tag.  Otherwise, it suffixes the tag name with abbreviated
-object name of the commit.
+the tag.  Otherwise, it suffixes the tag name with the number of
+additional commits and the abbreviated object name of the commit.
 
 
 OPTIONS
@@ -35,6 +35,16 @@ OPTIONS
        Instead of using the default 8 hexadecimal digits as the
        abbreviated object name, use <n> digits.
 
+--candidates=<n>::
+       Instead of considering only the 10 most recent tags as
+       candidates to describe the input committish consider
+       up to <n> candidates.  Increasing <n> above 10 will take
+       slightly longer but may produce a more accurate result.
+
+--debug::
+       Verbosely display information about the searching strategy
+       being employed to standard error.  The tag name will still
+       be printed to standard out.
 
 EXAMPLES
 --------
@@ -42,12 +52,18 @@ EXAMPLES
 With something like git.git current tree, I get:
 
        [torvalds@g5 git]$ git-describe parent
-       v1.0.4-g2414721b
+       v1.0.4-14-g2414721
 
 i.e. the current head of my "parent" branch is based on v1.0.4,
-but since it has a few commits on top of that, it has added the
-git hash of the thing to the end: "-g" + 8-char shorthand for
-the commit `2414721b194453f058079d897d13c4e377f92dc6`.
+but since it has a handful commits on top of that,
+describe has added the number of additional commits ("14") and
+an abbreviated object name for the commit itself ("2414721")
+at the end.
+
+The number of additional commits is the number
+of commits which would be displayed by "git log v1.0.4..parent".
+The hash suffix is "-g" + 7-char abbreviation for the tip commit
+of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).
 
 Doing a "git-describe" on a tag-name will just show the tag name:
 
@@ -58,16 +74,43 @@ With --all, the command can use branch heads as references, so
 the output shows the reference path as well:
 
        [torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2
-       tags/v1.0.0-g975b
+       tags/v1.0.0-21-g975b
 
        [torvalds@g5 git]$ git describe --all HEAD^
-       heads/lt/describe-g975b
+       heads/lt/describe-7-g975b
+
+With --abbrev set to 0, the command can be used to find the
+closest tagname without any suffix:
+
+       [torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2
+       tags/v1.0.0
+
+SEARCH STRATEGY
+---------------
+
+For each committish supplied "git describe" will first look for
+a tag which tags exactly that commit.  Annotated tags will always
+be preferred over lightweight tags, and tags with newer dates will
+always be preferred over tags with older dates.  If an exact match
+is found, its name will be output and searching will stop.
+
+If an exact match was not found "git describe" will walk back
+through the commit history to locate an ancestor commit which
+has been tagged.  The ancestor's tag will be output along with an
+abbreviation of the input committish's SHA1.
+
+If multiple tags were found during the walk then the tag which
+has the fewest commits different from the input committish will be
+selected and output.  Here fewest commits different is defined as
+the number of commits which would be shown by "git log tag..input"
+will be the smallest number of commits possible.
 
 
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org>, but somewhat
-butchered by Junio C Hamano <junkio@cox.net>
+butchered by Junio C Hamano <junkio@cox.net>.  Later significantly
+updated by Shawn Pearce <spearce@spearce.org>.
 
 Documentation
 --------------
index 3273918..120d14e 100644 (file)
@@ -3,7 +3,7 @@ git-diff-stages(1)
 
 NAME
 ----
-git-diff-stages - Compares content and mode of blobs between stages in an unmerged index file
+git-diff-stages - Compares two merge stages in the index
 
 
 SYNOPSIS
index 8977877..6a098df 100644 (file)
@@ -47,6 +47,9 @@ Just in case if you are doing something exotic, it should be
 noted that all of the <commit> in the above description can be
 any <tree-ish>.
 
+For a more complete list of ways to spell <commit>, see
+"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
+
 
 OPTIONS
 -------
index 3e6cd88..105d76b 100644 (file)
@@ -8,10 +8,13 @@ git-fetch-pack - Receive missing objects from another repository
 
 SYNOPSIS
 --------
-'git-fetch-pack' [-q] [-k] [--exec=<git-upload-pack>] [<host>:]<directory> [<refs>...]
+'git-fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--upload-pack=<git-upload-pack>] [--depth=<n>] [-v] [<host>:]<directory> [<refs>...]
 
 DESCRIPTION
 -----------
+Usually you would want to use gitlink:git-fetch[1] which is a
+higher level wrapper of this command instead.
+
 Invokes 'git-upload-pack' on a potentially remote repository,
 and asks it to send objects missing from this repository, to
 update the named heads.  The list of commits available locally
@@ -25,17 +28,24 @@ have a common ancestor commit.
 
 OPTIONS
 -------
--q::
+\--all::
+       Fetch all remote refs.
+
+\--quiet, \-q::
        Pass '-q' flag to 'git-unpack-objects'; this makes the
        cloning process less verbose.
 
--k::
+\--keep, \-k::
        Do not invoke 'git-unpack-objects' on received data, but
        create a single packfile out of it instead, and store it
        in the object database. If provided twice then the pack is
        locked against repacking.
 
---exec=<git-upload-pack>::
+\--thin::
+       Spend extra cycles to minimize the number of objects to be sent.
+       Use it on slower connection.
+
+\--upload-pack=<git-upload-pack>::
        Use this to specify the path to 'git-upload-pack' on the
        remote side, if is not found on your $PATH.
        Installations of sshd ignores the user's environment
@@ -47,6 +57,15 @@ OPTIONS
        shells by having a lean .bashrc file (they set most of
        the things up in .bash_profile).
 
+\--exec=<git-upload-pack>::
+       Same as \--upload-pack=<git-upload-pack>.
+
+\--depth=<n>::
+       Limit fetching to ancestor-chains not longer than n.
+
+\-v::
+       Run verbosely.
+
 <host>::
        A remote host that houses the repository.  When this
        part is specified, 'git-upload-pack' is invoked via
index a9e86fd..7ecf240 100644 (file)
@@ -3,7 +3,7 @@ git-fetch(1)
 
 NAME
 ----
-git-fetch - Download objects and a head from another repository
+git-fetch - Download objects and refs from another repository
 
 
 SYNOPSIS
index 2bf6aef..da52eba 100644 (file)
@@ -7,7 +7,7 @@ git-for-each-ref - Output information on each ref
 
 SYNOPSIS
 --------
-'git-for-each-ref' [--count=<count>]\* [--shell|--perl|--python] [--sort=<key>]\* [--format=<format>] [<pattern>]
+'git-for-each-ref' [--count=<count>]\* [--shell|--perl|--python|--tcl] [--sort=<key>]\* [--format=<format>] [<pattern>]
 
 DESCRIPTION
 -----------
@@ -15,7 +15,7 @@ DESCRIPTION
 Iterate over all refs that match `<pattern>` and show them
 according to the given `<format>`, after sorting them according
 to the given set of `<key>`.  If `<max>` is given, stop after
-showing that many refs.  The interporated values in `<format>`
+showing that many refs.  The interpolated values in `<format>`
 can optionally be quoted as string literals in the specified
 host language allowing their direct evaluation in that language.
 
@@ -49,7 +49,7 @@ OPTIONS
        using fnmatch(3).  Refs that do not match the pattern
        are not shown.
 
---shell, --perl, --python::
+--shell, --perl, --python, --tcl::
        If given, strings that substitute `%(fieldname)`
        placeholders are quoted as string literals suitable for
        the specified host language.  This is meant to produce
index 67425dc..59f34b9 100644 (file)
@@ -11,7 +11,8 @@ SYNOPSIS
 [verse]
 'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [--thread]
                   [-s | --signoff] [--diff-options] [--start-number <n>]
-                  [--in-reply-to=Message-Id]
+                  [--in-reply-to=Message-Id] [--suffix=.<sfx>]
+                  [--ignore-if-in-upstream]
                   <since>[..<until>]
 
 DESCRIPTION
@@ -20,7 +21,9 @@ DESCRIPTION
 Prepare each commit between <since> and <until> with its patch in
 one file per commit, formatted to resemble UNIX mailbox format.
 If ..<until> is not specified, the head of the current working
-tree is implied.
+tree is implied.  For a more complete list of ways to spell
+<since> and <until>, see "SPECIFYING REVISIONS" section in
+gitlink:git-rev-parse[1].
 
 The output of this command is convenient for e-mail submission or
 for use with gitlink:git-am[1].
@@ -78,13 +81,34 @@ OPTIONS
        reply to the given Message-Id, which avoids breaking threads to
        provide a new patch series.
 
+--ignore-if-in-upstream::
+       Do not include a patch that matches a commit in
+       <until>..<since>.  This will examine all patches reachable
+       from <since> but not from <until> and compare them with the
+       patches being generated, and any patch that matches is
+       ignored.
+
+--suffix=.<sfx>::
+       Instead of using `.patch` as the suffix for generated
+       filenames, use specifed suffix.  A common alternative is
+       `--suffix=.txt`.
++
+Note that you would need to include the leading dot `.` if you
+want a filename like `0001-description-of-my-change.patch`, and
+the first letter does not have to be a dot.  Leaving it empty would
+not add any suffix.
+
 CONFIGURATION
 -------------
 You can specify extra mail header lines to be added to each
-message in the repository configuration as follows:
+message in the repository configuration.  Also you can specify
+the default suffix different from the built-in one:
 
+------------
 [format]
         headers = "Organization: git-foo\n"
+        suffix = .txt
+------------
 
 
 EXAMPLES
@@ -109,6 +133,9 @@ git-format-patch -M -B origin::
        understand renaming patches, so use it only when you know
        the recipient uses git to apply your patch.
 
+git-format-patch -3::
+       Extract three topmost commits from the current branch
+       and format them as e-mailable patches.
 
 See Also
 --------
index d0af99d..f21061e 100644 (file)
@@ -8,132 +8,10 @@ git-fsck-objects - Verifies the connectivity and validity of the objects in the
 
 SYNOPSIS
 --------
-[verse]
-'git-fsck-objects' [--tags] [--root] [--unreachable] [--cache]
-                [--full] [--strict] [<object>*]
+'git-fsck-objects' ...
 
 DESCRIPTION
 -----------
-Verifies the connectivity and validity of the objects in the database.
-
-OPTIONS
--------
-<object>::
-       An object to treat as the head of an unreachability trace.
-+
-If no objects are given, git-fsck-objects defaults to using the
-index file and all SHA1 references in .git/refs/* as heads.
-
---unreachable::
-       Print out objects that exist but that aren't readable from any
-       of the reference nodes.
-
---root::
-       Report root nodes.
-
---tags::
-       Report tags.
-
---cache::
-       Consider any object recorded in the index also as a head node for
-       an unreachability trace.
-
---full::
-       Check not just objects in GIT_OBJECT_DIRECTORY
-       ($GIT_DIR/objects), but also the ones found in alternate
-       object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES
-       or $GIT_DIR/objects/info/alternates,
-       and in packed git archives found in $GIT_DIR/objects/pack
-       and corresponding pack subdirectories in alternate
-       object pools.
-
---strict::
-       Enable more strict checking, namely to catch a file mode
-       recorded with g+w bit set, which was created by older
-       versions of git.  Existing repositories, including the
-       Linux kernel, git itself, and sparse repository have old
-       objects that triggers this check, but it is recommended
-       to check new projects with this flag.
-
-It tests SHA1 and general object sanity, and it does full tracking of
-the resulting reachability and everything else. It prints out any
-corruption it finds (missing or bad objects), and if you use the
-'--unreachable' flag it will also print out objects that exist but
-that aren't readable from any of the specified head nodes.
-
-So for example
-
-       git-fsck-objects --unreachable HEAD $(cat .git/refs/heads/*)
-
-will do quite a _lot_ of verification on the tree. There are a few
-extra validity tests to be added (make sure that tree objects are
-sorted properly etc), but on the whole if "git-fsck-objects" is happy, you
-do have a valid tree.
-
-Any corrupt objects you will have to find in backups or other archives
-(i.e., you can just remove them and do an "rsync" with some other site in
-the hopes that somebody else has the object you have corrupted).
-
-Of course, "valid tree" doesn't mean that it wasn't generated by some
-evil person, and the end result might be crap. git is a revision
-tracking system, not a quality assurance system ;)
-
-Extracted Diagnostics
----------------------
-
-expect dangling commits - potential heads - due to lack of head information::
-       You haven't specified any nodes as heads so it won't be
-       possible to differentiate between un-parented commits and
-       root nodes.
-
-missing sha1 directory '<dir>'::
-       The directory holding the sha1 objects is missing.
-
-unreachable <type> <object>::
-       The <type> object <object>, isn't actually referred to directly
-       or indirectly in any of the trees or commits seen. This can
-       mean that there's another root node that you're not specifying
-       or that the tree is corrupt. If you haven't missed a root node
-       then you might as well delete unreachable nodes since they
-       can't be used.
-
-missing <type> <object>::
-       The <type> object <object>, is referred to but isn't present in
-       the database.
-
-dangling <type> <object>::
-       The <type> object <object>, is present in the database but never
-       'directly' used. A dangling commit could be a root node.
-
-warning: git-fsck-objects: tree <tree> has full pathnames in it::
-       And it shouldn't...
-
-sha1 mismatch <object>::
-       The database has an object who's sha1 doesn't match the
-       database value.
-       This indicates a serious data integrity problem.
-
-Environment Variables
----------------------
-
-GIT_OBJECT_DIRECTORY::
-       used to specify the object database root (usually $GIT_DIR/objects)
-
-GIT_INDEX_FILE::
-       used to specify the index file of the index
-
-GIT_ALTERNATE_OBJECT_DIRECTORIES::
-       used to specify additional object database roots (usually unset)
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
---------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the gitlink:git[7] suite
 
+This is a synonym for gitlink:git-fsck[1].  Please refer to the
+documentation of that command.
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
new file mode 100644 (file)
index 0000000..058009d
--- /dev/null
@@ -0,0 +1,139 @@
+git-fsck(1)
+===========
+
+NAME
+----
+git-fsck - Verifies the connectivity and validity of the objects in the database
+
+
+SYNOPSIS
+--------
+[verse]
+'git-fsck' [--tags] [--root] [--unreachable] [--cache]
+                [--full] [--strict] [<object>*]
+
+DESCRIPTION
+-----------
+Verifies the connectivity and validity of the objects in the database.
+
+OPTIONS
+-------
+<object>::
+       An object to treat as the head of an unreachability trace.
++
+If no objects are given, git-fsck defaults to using the
+index file and all SHA1 references in .git/refs/* as heads.
+
+--unreachable::
+       Print out objects that exist but that aren't readable from any
+       of the reference nodes.
+
+--root::
+       Report root nodes.
+
+--tags::
+       Report tags.
+
+--cache::
+       Consider any object recorded in the index also as a head node for
+       an unreachability trace.
+
+--full::
+       Check not just objects in GIT_OBJECT_DIRECTORY
+       ($GIT_DIR/objects), but also the ones found in alternate
+       object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES
+       or $GIT_DIR/objects/info/alternates,
+       and in packed git archives found in $GIT_DIR/objects/pack
+       and corresponding pack subdirectories in alternate
+       object pools.
+
+--strict::
+       Enable more strict checking, namely to catch a file mode
+       recorded with g+w bit set, which was created by older
+       versions of git.  Existing repositories, including the
+       Linux kernel, git itself, and sparse repository have old
+       objects that triggers this check, but it is recommended
+       to check new projects with this flag.
+
+It tests SHA1 and general object sanity, and it does full tracking of
+the resulting reachability and everything else. It prints out any
+corruption it finds (missing or bad objects), and if you use the
+'--unreachable' flag it will also print out objects that exist but
+that aren't readable from any of the specified head nodes.
+
+So for example
+
+       git-fsck --unreachable HEAD $(cat .git/refs/heads/*)
+
+will do quite a _lot_ of verification on the tree. There are a few
+extra validity tests to be added (make sure that tree objects are
+sorted properly etc), but on the whole if "git-fsck" is happy, you
+do have a valid tree.
+
+Any corrupt objects you will have to find in backups or other archives
+(i.e., you can just remove them and do an "rsync" with some other site in
+the hopes that somebody else has the object you have corrupted).
+
+Of course, "valid tree" doesn't mean that it wasn't generated by some
+evil person, and the end result might be crap. git is a revision
+tracking system, not a quality assurance system ;)
+
+Extracted Diagnostics
+---------------------
+
+expect dangling commits - potential heads - due to lack of head information::
+       You haven't specified any nodes as heads so it won't be
+       possible to differentiate between un-parented commits and
+       root nodes.
+
+missing sha1 directory '<dir>'::
+       The directory holding the sha1 objects is missing.
+
+unreachable <type> <object>::
+       The <type> object <object>, isn't actually referred to directly
+       or indirectly in any of the trees or commits seen. This can
+       mean that there's another root node that you're not specifying
+       or that the tree is corrupt. If you haven't missed a root node
+       then you might as well delete unreachable nodes since they
+       can't be used.
+
+missing <type> <object>::
+       The <type> object <object>, is referred to but isn't present in
+       the database.
+
+dangling <type> <object>::
+       The <type> object <object>, is present in the database but never
+       'directly' used. A dangling commit could be a root node.
+
+warning: git-fsck: tree <tree> has full pathnames in it::
+       And it shouldn't...
+
+sha1 mismatch <object>::
+       The database has an object who's sha1 doesn't match the
+       database value.
+       This indicates a serious data integrity problem.
+
+Environment Variables
+---------------------
+
+GIT_OBJECT_DIRECTORY::
+       used to specify the object database root (usually $GIT_DIR/objects)
+
+GIT_INDEX_FILE::
+       used to specify the index file of the index
+
+GIT_ALTERNATE_OBJECT_DIRECTORIES::
+       used to specify additional object database roots (usually unset)
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
index 73d78c1..e37758a 100644 (file)
@@ -8,7 +8,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository
 
 SYNOPSIS
 --------
-'git-gc'
+'git-gc' [--prune]
 
 DESCRIPTION
 -----------
@@ -21,6 +21,21 @@ Users are encouraged to run this task on a regular basis within
 each repository to maintain good disk space utilization and good
 operating performance.
 
+OPTIONS
+-------
+
+--prune::
+       Usually `git-gc` packs refs, expires old reflog entries,
+       packs loose objects,
+       and removes old 'rerere' records.  Removal
+       of unreferenced loose objects is an unsafe operation
+       while other git operations are in progress, so it is not
+       done by default.  Pass this option if you want it, and only
+       when you know nobody else is creating new objects in the
+       repository at the same time (e.g. never use this option
+       in a cron script).
+
+
 Configuration
 -------------
 
@@ -35,7 +50,7 @@ can be set to indicate how long historical reflog entries which
 are not part of the current branch should remain available in
 this repository.  These types of entries are generally created as
 a result of using `git commit \--amend` or `git rebase` and are the
-commits prior to the amend or rebase occuring.  Since these changes
+commits prior to the amend or rebase occurring.  Since these changes
 are not part of the current project most users will want to expire
 them sooner.  This option defaults to '30 days'.
 
index bfbece9..0140c8e 100644 (file)
@@ -91,7 +91,7 @@ OPTIONS
        combined by 'or'.
 
 --and | --or | --not | ( | )::
-       Specify how multiple patterns are combined using boolean
+       Specify how multiple patterns are combined using Boolean
        expressions.  `--or` is the default operator.  `--and` has
        higher precedence than `--or`.  `-e` has to be used for all
        patterns.
index 04e8d00..5edc36f 100644 (file)
@@ -3,7 +3,7 @@ git-hash-object(1)
 
 NAME
 ----
-git-hash-object - Computes object ID and optionally creates a blob from a file
+git-hash-object - Compute object ID and optionally creates a blob from a file
 
 
 SYNOPSIS
index 3d50809..7dc2df3 100644 (file)
@@ -3,7 +3,7 @@ git-http-fetch(1)
 
 NAME
 ----
-git-http-fetch - downloads a remote git repository via HTTP
+git-http-fetch - Download from a remote git repository via HTTP
 
 
 SYNOPSIS
index c2485c6..4b4a461 100644 (file)
@@ -3,7 +3,7 @@ git-http-push(1)
 
 NAME
 ----
-git-http-push - Push missing objects using HTTP/DAV
+git-http-push - Push objects over HTTP/DAV to another repository
 
 
 SYNOPSIS
index 596b567..1b64d3a 100644 (file)
@@ -3,7 +3,7 @@ git-init(1)
 
 NAME
 ----
-git-init - Creates an empty git repository
+git-init - Create an empty git repository or reinitialize an existing one
 
 
 SYNOPSIS
index 7dd393b..52a6aa6 100644 (file)
@@ -3,7 +3,7 @@ git-instaweb(1)
 
 NAME
 ----
-git-instaweb - instantly browse your working repository in gitweb
+git-instaweb - Instantly browse your working repository in gitweb
 
 SYNOPSIS
 --------
index 2fbdfe0..22048d8 100644 (file)
@@ -3,7 +3,7 @@ git-local-fetch(1)
 
 NAME
 ----
-git-local-fetch - Duplicates another git repository on a local system
+git-local-fetch - Duplicate another git repository on a local system
 
 
 SYNOPSIS
index e9f746b..b802946 100644 (file)
@@ -27,13 +27,16 @@ OPTIONS
 
 include::pretty-formats.txt[]
 
---max-count=<n>::
+-<n>::
        Limits the number of commits to show.
 
 <since>..<until>::
        Show only commits between the named two commits.  When
        either <since> or <until> is omitted, it defaults to
        `HEAD`, i.e. the tip of the current branch.
+       For a more complete list of ways to spell <since>
+       and <until>, see "SPECIFYING REVISIONS" section in
+       gitlink:git-rev-parse[1].
 
 -p::
        Show the change the commit introduces in a patch form.
index 8520b97..79e0b7b 100644 (file)
@@ -3,7 +3,7 @@ git-ls-files(1)
 
 NAME
 ----
-git-ls-files - Information about files in the index/working directory
+git-ls-files - Show information about files in the index and the working tree
 
 
 SYNOPSIS
index c8a4c5a..c254005 100644 (file)
@@ -29,7 +29,7 @@ OPTIONS
 -u <exec>, --upload-pack=<exec>::
        Specify the full path of gitlink:git-upload-pack[1] on the remote
        host. This allows listing references from repositories accessed via
-       SSH and where the SSH deamon does not use the PATH configured by the
+       SSH and where the SSH daemon does not use the PATH configured by the
        user. Also see the '--exec' option for gitlink:git-peek-remote[1].
 
 <repository>::
index f283bac..7899394 100644 (file)
@@ -3,7 +3,7 @@ git-ls-tree(1)
 
 NAME
 ----
-git-ls-tree - Lists the contents of a tree object
+git-ls-tree - List the contents of a tree object
 
 
 SYNOPSIS
index 5088bbe..ba18133 100644 (file)
@@ -3,7 +3,7 @@ git-mailinfo(1)
 
 NAME
 ----
-git-mailinfo - Extracts patch from a single e-mail message
+git-mailinfo - Extracts patch and authorship from a single e-mail message
 
 
 SYNOPSIS
@@ -18,7 +18,7 @@ writes the commit log message in <msg> file, and the patches in
 <patch> file.  The author name, e-mail and e-mail subject are
 written out to the standard output to be used by git-applypatch
 to create a commit.  It is usually not necessary to use this
-command directly.
+command directly.  See gitlink:git-am[1] instead.
 
 
 OPTIONS
index 5a17801..c11d6a5 100644 (file)
@@ -3,7 +3,7 @@ git-mailsplit(1)
 
 NAME
 ----
-git-mailsplit - Totally braindamaged mbox splitter program
+git-mailsplit - Simple UNIX mbox splitter program
 
 SYNOPSIS
 --------
index 6099be2..3190aed 100644 (file)
@@ -3,7 +3,7 @@ git-merge-base(1)
 
 NAME
 ----
-git-merge-base - Finds as good a common ancestor as possible for a merge
+git-merge-base - Find as good common ancestors as possible for a merge
 
 
 SYNOPSIS
index 29d3faa..31882ab 100644 (file)
@@ -3,7 +3,7 @@ git-merge-file(1)
 
 NAME
 ----
-git-merge-file - three-way file merge
+git-merge-file - Run a three-way file merge
 
 
 SYNOPSIS
index 0cf505e..b8ee1ff 100644 (file)
@@ -3,7 +3,7 @@ git-merge-index(1)
 
 NAME
 ----
-git-merge-index - Runs a merge for files needing merging
+git-merge-index - Run a merge for files needing merging
 
 
 SYNOPSIS
index 86aad37..f80ab3b 100644 (file)
@@ -3,7 +3,7 @@ git-merge-one-file(1)
 
 NAME
 ----
-git-merge-one-file - The standard helper program to use with "git-merge-index"
+git-merge-one-file - The standard helper program to use with git-merge-index
 
 
 SYNOPSIS
index 0f79665..3c08a6f 100644 (file)
@@ -3,7 +3,7 @@ git-merge(1)
 
 NAME
 ----
-git-merge - Grand Unified Merge Driver
+git-merge - Join two or more development histories together
 
 
 SYNOPSIS
index 207c43a..6756b76 100644 (file)
@@ -3,7 +3,7 @@ git-mv(1)
 
 NAME
 ----
-git-mv - Move or rename a file, directory or symlink
+git-mv - Move or rename a file, a directory, or a symlink
 
 
 SYNOPSIS
index 7d54b17..94bbea0 100644 (file)
@@ -3,7 +3,7 @@ git-pack-redundant(1)
 
 NAME
 ----
-git-pack-redundant - Program used to find redundant pack files
+git-pack-redundant - Find redundant pack files
 
 
 SYNOPSIS
@@ -21,7 +21,7 @@ given will be ignored when checking which packs are required. This makes the
 following command useful when wanting to remove packs which contain unreachable
 objects.
 
-git-fsck-objects --full --unreachable | cut -d ' ' -f3 | \
+git-fsck --full --unreachable | cut -d ' ' -f3 | \
 git-pack-redundant --all | xargs rm
 
 OPTIONS
index 464269f..a20fc7d 100644 (file)
@@ -29,12 +29,23 @@ file and used if found.
 Subsequent updates to branches always creates new file under
 `$GIT_DIR/refs` hierarchy.
 
+A recommended practice to deal with a repository with too many
+refs is to pack its refs with `--all --prune` once, and
+occasionally run `git-pack-refs \--prune`.  Tags are by
+definition stationary and are not expected to change.  Branch
+heads will be packed with the initial `pack-refs --all`, but
+only the currently active branch heads will become unpacked,
+and next `pack-refs` (without `--all`) will leave them
+unpacked.
+
+
 OPTIONS
 -------
 
 \--all::
 
-The command by default packs all tags and leaves branch tips
+The command by default packs all tags and refs that are already
+packed, and leaves other refs
 alone.  This is because branches are expected to be actively
 developed and packing their tips does not help performance.
 This option causes branch tips to be packed as well.  Useful for
index fc27afe..11b1f4d 100644 (file)
@@ -3,7 +3,7 @@ git-parse-remote(1)
 
 NAME
 ----
-git-parse-remote - Routines to help parsing $GIT_DIR/remotes/
+git-parse-remote - Routines to help parsing remote repository access parameters
 
 
 SYNOPSIS
@@ -14,7 +14,8 @@ DESCRIPTION
 -----------
 This script is included in various scripts to supply
 routines to parse files under $GIT_DIR/remotes/ and
-$GIT_DIR/branches/.
+$GIT_DIR/branches/ and configuration variables that are related
+to fetching, pulling and pushing.
 
 The primary entry points are:
 
@@ -25,7 +26,8 @@ get_remote_refs_for_fetch::
        (e.g. `refs/heads/foo`).  When `<refspec>...` is empty
        the returned list of refs consists of the defaults
        for the given `<repo>`, if specified in
-       `$GIT_DIR/remotes/` or `$GIT_DIR/branches/`.
+       `$GIT_DIR/remotes/`, `$GIT_DIR/branches/`, or `remote.*.fetch`
+       configuration.
 
 get_remote_refs_for_push::
        Given the list of user-supplied `<repo> <refspec>...`,
index 5389097..a7e9fd0 100644 (file)
@@ -3,7 +3,7 @@ git-patch-id(1)
 
 NAME
 ----
-git-patch-id - Generate a patch ID
+git-patch-id - Compute unique ID for a patch
 
 SYNOPSIS
 --------
index a00060c..74f37bd 100644 (file)
@@ -3,12 +3,12 @@ git-peek-remote(1)
 
 NAME
 ----
-git-peek-remote - Lists the references in a remote repository
+git-peek-remote - List the references in a remote repository
 
 
 SYNOPSIS
 --------
-'git-peek-remote' [--exec=<git-upload-pack>] [<host>:]<directory>
+'git-peek-remote' [--upload-pack=<git-upload-pack>] [<host>:]<directory>
 
 DESCRIPTION
 -----------
@@ -17,7 +17,7 @@ stores them in the local repository under the same name.
 
 OPTIONS
 -------
---exec=<git-upload-pack>::
+\--upload-pack=<git-upload-pack>::
        Use this to specify the path to 'git-upload-pack' on the
        remote side, if it is not found on your $PATH. Some
        installations of sshd ignores the user's environment
@@ -29,6 +29,9 @@ OPTIONS
        shells, but prefer having a lean .bashrc file (they set most of
        the things up in .bash_profile).
 
+\--exec=<git-upload-pack>::
+       Same \--upload-pack=<git-upload-pack>.
+
 <host>::
        A remote host that houses the repository.  When this
        part is specified, 'git-upload-pack' is invoked via
index a79193f..310033e 100644 (file)
@@ -3,8 +3,7 @@ git-prune-packed(1)
 
 NAME
 ----
-git-prune-packed - Program used to remove the extra object files that are now
-residing in a pack file.
+git-prune-packed - Remove extra objects that are already in pack files
 
 
 SYNOPSIS
index a11e303..0b44f30 100644 (file)
@@ -13,7 +13,7 @@ SYNOPSIS
 DESCRIPTION
 -----------
 
-This runs `git-fsck-objects --unreachable` using all the refs
+This runs `git-fsck --unreachable` using all the refs
 available in `$GIT_DIR/refs`, optionally with additional set of
 objects specified on the command line, and prunes all
 objects unreachable from any of these head objects from the object database.
index 13be992..a81d68c 100644 (file)
@@ -3,7 +3,7 @@ git-pull(1)
 
 NAME
 ----
-git-pull - Pull and merge from another repository or a local branch
+git-pull - Fetch from and merge with another repository or a local branch
 
 
 SYNOPSIS
@@ -42,7 +42,7 @@ git pull, git pull origin::
        current branch.  Normally the branch merged in is
        the HEAD of the remote repository, but the choice is
        determined by the branch.<name>.remote and
-       branch.<name>.merge options; see gitlink:git-repo-config[1]
+       branch.<name>.merge options; see gitlink:git-config[1]
        for details.
 
 git pull origin next::
@@ -52,7 +52,8 @@ git pull origin next::
 
 git pull . fixes enhancements::
        Bundle local branch `fixes` and `enhancements` on top of
-       the current branch, making an Octopus merge.
+       the current branch, making an Octopus merge.  This `git pull .`
+       syntax is equivalent to `git merge`.
 
 git pull -s ours . obsolete::
        Merge local branch `obsolete` into the current branch,
@@ -93,7 +94,7 @@ gitlink:git-reset[1].
 
 SEE ALSO
 --------
-gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-repo-config[1]
+gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-config[1]
 
 
 Author
index 197f4b5..f8cc2b5 100644 (file)
@@ -8,7 +8,7 @@ git-push - Update remote refs along with associated objects
 
 SYNOPSIS
 --------
-'git-push' [--all] [--tags] [-f | --force] <repository> <refspec>...
+'git-push' [--all] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]
 
 DESCRIPTION
 -----------
@@ -67,12 +67,33 @@ the remote repository.
        addition to refspecs explicitly listed on the command
        line.
 
+\--receive-pack=<git-receive-pack>::
+       Path to the 'git-receive-pack' program on the remote
+       end.  Sometimes useful when pushing to a remote
+       repository over ssh, and you do not have the program in
+       a directory on the default $PATH.
+
+\--exec=<git-receive-pack>::
+       Same as \--receive-pack=<git-receive-pack>.
+
 -f, \--force::
        Usually, the command refuses to update a remote ref that is
        not a descendant of the local ref used to overwrite it.
        This flag disables the check.  This can cause the
        remote repository to lose commits; use it with care.
 
+\--repo=<repo>::
+       When no repository is specified the command defaults to
+       "origin"; this overrides it.
+
+\--thin, \--no-thin::
+       These options are passed to `git-send-pack`.  Thin
+       transfer spends extra cycles to minimize the number of
+       objects to be sent and meant to be used on slower connection.
+
+-v::
+       Run verbosely.
+
 include::urls.txt[]
 
 Author
index 03e867a..0cb9e1f 100644 (file)
@@ -3,7 +3,7 @@ git-rebase(1)
 
 NAME
 ----
-git-rebase - Rebase local commits to a new head
+git-rebase - Forward-port local commits to the updated upstream head
 
 SYNOPSIS
 --------
index 0dfadc2..10e8c46 100644 (file)
@@ -3,7 +3,7 @@ git-receive-pack(1)
 
 NAME
 ----
-git-receive-pack - Receive what is pushed into it
+git-receive-pack - Receive what is pushed into the repository
 
 
 SYNOPSIS
index 55a24d3..1138865 100644 (file)
@@ -9,7 +9,7 @@ git-reflog - Manage reflog information
 SYNOPSIS
 --------
 [verse]
-'git-reflog' expire [--dry-run]
+'git-reflog' expire [--dry-run] [--stale-fix]
        [--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...
 
 
index 5b93a8c..358c1ac 100644 (file)
@@ -28,7 +28,7 @@ In the third form, gives some information about the remote <name>.
 
 The remote configuration is achieved using the `remote.origin.url` and
 `remote.origin.fetch` configuration variables.  (See
-gitlink:git-repo-config[1]).
+gitlink:git-config[1]).
 
 Examples
 --------
@@ -58,7 +58,7 @@ See Also
 --------
 gitlink:git-fetch[1]
 gitlink:git-branch[1]
-gitlink:git-repo-config[1]
+gitlink:git-config[1]
 
 Author
 ------
index 0fa47e3..4a57ce8 100644 (file)
@@ -3,8 +3,7 @@ git-repack(1)
 
 NAME
 ----
-git-repack - Script used to pack a repository from a collection of
-objects into pack files.
+git-repack - Pack unpacked objects in a repository
 
 
 SYNOPSIS
index c55a8ba..2deba31 100644 (file)
@@ -3,225 +3,16 @@ git-repo-config(1)
 
 NAME
 ----
-git-repo-config - Get and set repository or global options.
+git-repo-config - Get and set repository or global options
 
 
 SYNOPSIS
 --------
-[verse]
-'git-repo-config' [--global] [type] name [value [value_regex]]
-'git-repo-config' [--global] [type] --add name value
-'git-repo-config' [--global] [type] --replace-all name [value [value_regex]]
-'git-repo-config' [--global] [type] --get name [value_regex]
-'git-repo-config' [--global] [type] --get-all name [value_regex]
-'git-repo-config' [--global] [type] --unset name [value_regex]
-'git-repo-config' [--global] [type] --unset-all name [value_regex]
-'git-repo-config' [--global] -l | --list
+'git-repo-config' ...
 
-DESCRIPTION
------------
-You can query/set/replace/unset options with this command. The name is
-actually the section and the key separated by a dot, and the value will be
-escaped.
-
-Multiple lines can be added to an option by using the '--add' option.
-If you want to update or unset an option which can occur on multiple
-lines, a POSIX regexp `value_regex` needs to be given.  Only the
-existing values that match the regexp are updated or unset.  If
-you want to handle the lines that do *not* match the regex, just
-prepend a single exclamation mark in front (see EXAMPLES).
-
-The type specifier can be either '--int' or '--bool', which will make
-'git-repo-config' ensure that the variable(s) are of the given type and
-convert the value to the canonical form (simple decimal number for int,
-a "true" or "false" string for bool). If no type specifier is passed,
-no checks or transformations are performed on the value.
-
-This command will fail if:
-
-. The .git/config file is invalid,
-. Can not write to .git/config,
-. no section was provided,
-. the section or key is invalid,
-. you try to unset an option which does not exist,
-. you try to unset/set an option for which multiple lines match, or
-. you use --global option without $HOME being properly set.
-
-
-OPTIONS
--------
-
---replace-all::
-       Default behavior is to replace at most one line. This replaces
-       all lines matching the key (and optionally the value_regex).
-
---add::
-       Adds a new line to the option without altering any existing
-       values.  This is the same as providing '^$' as the value_regex.
-
---get::
-       Get the value for a given key (optionally filtered by a regex
-       matching the value). Returns error code 1 if the key was not
-       found and error code 2 if multiple key values were found.
-
---get-all::
-       Like get, but does not fail if the number of values for the key
-       is not exactly one.
-
---get-regexp::
-       Like --get-all, but interprets the name as a regular expression.
-
---global::
-       Use global ~/.gitconfig file rather than the repository .git/config.
-
---unset::
-       Remove the line matching the key from config file.
 
---unset-all::
-       Remove all matching lines from config file.
-
--l, --list::
-       List all variables set in config file.
-
---bool::
-       git-repo-config will ensure that the output is "true" or "false"
-
---int::
-       git-repo-config will ensure that the output is a simple
-       decimal number.  An optional value suffix of 'k', 'm', or 'g'
-       in the config file will cause the value to be multiplied
-       by 1024, 1048576, or 1073741824 prior to output.
-
-
-ENVIRONMENT
+DESCRIPTION
 -----------
 
-GIT_CONFIG::
-       Take the configuration from the given file instead of .git/config.
-       Using the "--global" option forces this to ~/.gitconfig.
-
-GIT_CONFIG_LOCAL::
-       Currently the same as $GIT_CONFIG; when Git will support global
-       configuration files, this will cause it to take the configuration
-       from the global configuration file in addition to the given file.
-
-
-EXAMPLE
--------
-
-Given a .git/config like this:
-
-       #
-       # This is the config file, and
-       # a '#' or ';' character indicates
-       # a comment
-       #
-
-       ; core variables
-       [core]
-               ; Don't trust file modes
-               filemode = false
-
-       ; Our diff algorithm
-       [diff]
-               external = "/usr/local/bin/gnu-diff -u"
-               renames = true
-
-       ; Proxy settings
-       [core]
-               gitproxy="ssh" for "ssh://kernel.org/"
-               gitproxy="proxy-command" for kernel.org
-               gitproxy="myprotocol-command" for "my://"
-               gitproxy=default-proxy ; for all the rest
-
-you can set the filemode to true with
-
-------------
-% git repo-config core.filemode true
-------------
-
-The hypothetical proxy command entries actually have a postfix to discern
-what URL they apply to. Here is how to change the entry for kernel.org
-to "ssh".
-
-------------
-% git repo-config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'
-------------
-
-This makes sure that only the key/value pair for kernel.org is replaced.
-
-To delete the entry for renames, do
-
-------------
-% git repo-config --unset diff.renames
-------------
-
-If you want to delete an entry for a multivar (like core.gitproxy above),
-you have to provide a regex matching the value of exactly one line.
-
-To query the value for a given key, do
-
-------------
-% git repo-config --get core.filemode
-------------
-
-or
-
-------------
-% git repo-config core.filemode
-------------
-
-or, to query a multivar:
-
-------------
-% git repo-config --get core.gitproxy "for kernel.org$"
-------------
-
-If you want to know all the values for a multivar, do:
-
-------------
-% git repo-config --get-all core.gitproxy
-------------
-
-If you like to live dangerous, you can replace *all* core.gitproxy by a
-new one with
-
-------------
-% git repo-config --replace-all core.gitproxy ssh
-------------
-
-However, if you really only want to replace the line for the default proxy,
-i.e. the one without a "for ..." postfix, do something like this:
-
-------------
-% git repo-config core.gitproxy ssh '! for '
-------------
-
-To actually match only values with an exclamation mark, you have to
-
-------------
-% git repo-config section.key value '[!]'
-------------
-
-To add a new proxy, without altering any of the existing ones, use
-
-------------
-% git repo-config core.gitproxy '"proxy" for example.com'
-------------
-
-
-include::config.txt[]
-
-
-Author
-------
-Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
-
-Documentation
---------------
-Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the gitlink:git[7] suite
-
+This is a synonym for gitlink:git-config[1].  Please refer to the
+documentation of that command.
index b57a72b..139b6eb 100644 (file)
@@ -3,7 +3,7 @@ git-rerere(1)
 
 NAME
 ----
-git-rerere - Reuse recorded resolve
+git-rerere - Reuse recorded resolution of conflicted merges
 
 SYNOPSIS
 --------
@@ -38,7 +38,7 @@ its working state.
 
 This resets the metadata used by rerere if a merge resolution is to be
 is aborted.  Calling gitlink:git-am[1] --skip or gitlink:git-rebase[1]
-[--skip|--abort] will automatcally invoke this command.
+[--skip|--abort] will automatically invoke this command.
 
 'diff'::
 
@@ -81,7 +81,7 @@ One way to do it is to pull master into the topic branch:
 
 ------------
        $ git checkout topic
-       $ git pull . master
+       $ git merge master
 
               o---*---o---+ topic
              /           /
@@ -103,10 +103,10 @@ in which case the final commit graph would look like this:
 
 ------------
        $ git checkout topic
-       $ git pull . master
+       $ git merge master
        $ ... work on both topic and master branches
        $ git checkout master
-       $ git pull . topic
+       $ git merge topic
 
               o---*---o---+---o---o topic
              /           /         \
@@ -126,11 +126,11 @@ top of the tip before the test merge:
 
 ------------
        $ git checkout topic
-       $ git pull . master
+       $ git merge master
        $ git reset --hard HEAD^ ;# rewind the test merge
        $ ... work on both topic and master branches
        $ git checkout master
-       $ git pull . topic
+       $ git merge topic
 
               o---*---o-------o---o topic
              /                     \
index 4f42478..04475a9 100644 (file)
@@ -121,10 +121,6 @@ Undo a merge or pull::
 +
 ------------
 $ git pull                         <1>
-Trying really trivial in-index merge...
-fatal: Merge requires file-level merging
-Nope.
-...
 Auto-merging nitfol
 CONFLICT (content): Merge conflict in nitfol
 Automatic merge failed/prevented; fix up by hand
index 4e57c2b..0925973 100644 (file)
@@ -12,6 +12,8 @@ SYNOPSIS
 
 DESCRIPTION
 -----------
+DEPRECATED.  Use `git-merge` instead.
+
 Given two commits and a merge message, merge the <merged> commit
 into <current> commit, with the commit log message <message>.
 
index 86c94e7..c742117 100644 (file)
@@ -27,6 +27,7 @@ SYNOPSIS
             [ \--pretty | \--header ]
             [ \--bisect ]
             [ \--merge ]
+            [ \--walk-reflogs ]
             <commit>... [ \-- <paths>... ]
 
 DESCRIPTION
@@ -190,6 +191,22 @@ limiting may be applied.
        In addition to the '<commit>' listed on the command
        line, read them from the standard input.
 
+-g, --walk-reflogs::
+
+       Instead of walking the commit ancestry chain, walk
+       reflog entries from the most recent one to older ones.
+       When this option is used you cannot specify commits to
+       exclude (that is, '{caret}commit', 'commit1..commit2',
+       nor 'commit1...commit2' notations cannot be used).
++
+With '\--pretty' format other than oneline (for obvious reasons),
+this causes the output to have two extra lines of information
+taken from the reflog.  By default, 'commit@{Nth}' notation is
+used in the output.  When the starting commit is specified as
+'commit@{now}', output also uses 'commit@{timestamp}' notation
+instead.  Under '\--pretty=oneline', the commit message is
+prefixed with this information on the same line.
+
 --merge::
 
        After a failed merge, show refs that touch files having a
index 4eaf5a0..aeb37b6 100644 (file)
@@ -152,6 +152,14 @@ blobs contained in a commit.
   used immediately following a ref name and the ref must have an
   existing log ($GIT_DIR/logs/<ref>).
 
+* A ref followed by the suffix '@' with an ordinal specification
+  enclosed in a brace pair (e.g. '\{1\}', '\{15\}') to specify
+  the n-th prior value of that ref.  For example 'master@\{1\}'
+  is the immediate prior value of 'master' while 'master@\{5\}'
+  is the 5th prior value of 'master'. This suffix may only be used
+  immediately following a ref name and the ref must have an existing
+  log ($GIT_DIR/logs/<ref>).
+
 * A suffix '{caret}' to a revision parameter means the first parent of
   that commit object.  '{caret}<n>' means the <n>th parent (i.e.
   'rev{caret}'
index 71f7815..8081bba 100644 (file)
@@ -19,6 +19,8 @@ OPTIONS
 -------
 <commit>::
        Commit to revert.
+       For a more complete list of ways to spell commit names, see
+       "SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
 
 -e|--edit::
        With this option, `git-revert` will let you edit the commit
index 3a8f279..6feebc0 100644 (file)
@@ -60,21 +60,17 @@ a file that you have not told git about does not remove that file.
 EXAMPLES
 --------
 git-rm Documentation/\\*.txt::
-
        Removes all `\*.txt` files from the index that are under the
-       `Documentation` directory and any of its subdirectories. The
-       files are not removed from the working tree.
+       `Documentation` directory and any of its subdirectories.
 +
 Note that the asterisk `\*` is quoted from the shell in this
 example; this lets the command include the files from
 subdirectories of `Documentation/` directory.
 
 git-rm -f git-*.sh::
-
-       Remove all git-*.sh scripts that are in the index. The files
-       are removed from the index, and from the working
-       tree. Because this example lets the shell expand the
-       asterisk (i.e. you are listing the files explicitly), it
+       Remove all git-*.sh scripts that are in the index.
+       Because this example lets the shell expand the asterisk
+       (i.e. you are listing the files explicitly), it
        does not remove `subdir/git-foo.sh`.
 
 See Also
index 5376f68..2f6267c 100644 (file)
@@ -3,38 +3,51 @@ git-send-pack(1)
 
 NAME
 ----
-git-send-pack - Push missing objects packed
+git-send-pack - Push objects over git protocol to another reposiotory
 
 
 SYNOPSIS
 --------
-'git-send-pack' [--all] [--force] [--exec=<git-receive-pack>] [<host>:]<directory> [<ref>...]
+'git-send-pack' [--all] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]
 
 DESCRIPTION
 -----------
+Usually you would want to use gitlink:git-push[1] which is a
+higher level wrapper of this command instead.
+
 Invokes 'git-receive-pack' on a possibly remote repository, and
 updates it from the current repository, sending named refs.
 
 
 OPTIONS
 -------
---exec=<git-receive-pack>::
+\--receive-pack=<git-receive-pack>::
        Path to the 'git-receive-pack' program on the remote
        end.  Sometimes useful when pushing to a remote
        repository over ssh, and you do not have the program in
        a directory on the default $PATH.
 
---all::
+\--exec=<git-receive-pack>::
+       Same as \--receive-pack=<git-receive-pack>.
+
+\--all::
        Instead of explicitly specifying which refs to update,
        update all refs that locally exist.
 
---force::
+\--force::
        Usually, the command refuses to update a remote ref that
        is not an ancestor of the local ref used to overwrite it.
        This flag disables the check.  What this means is that
        the remote repository can lose commits; use it with
        care.
 
+\--verbose::
+       Run verbosely.
+
+\--thin::
+       Spend extra cycles to minimize the number of objects to be sent.
+       Use it on slower connection.
+
 <host>::
        A remote host to house the repository.  When this
        part is specified, 'git-receive-pack' is invoked via
index 79217d8..2b2abeb 100644 (file)
@@ -12,14 +12,51 @@ SYNOPSIS
 DESCRIPTION
 -----------
 
-Sets up the normal git environment variables and a few helper functions
-(currently just "die()"), and returns OK if it all looks like a git archive.
-So, to make the rest of the git scripts more careful and readable,
-use it as follows:
-
--------------------------------------------------
-. git-sh-setup || die "Not a git archive"
--------------------------------------------------
+This is not a command the end user would want to run.  Ever.
+This documentation is meant for people who are studying the
+Porcelain-ish scripts and/or are writing new ones.
+
+The `git-sh-setup` scriptlet is designed to be sourced (using
+`.`) by other shell scripts to set up some variables pointing at
+the normal git directories and a few helper shell functions.
+
+Before sourcing it, your script should set up a few variables;
+`USAGE` (and `LONG_USAGE`, if any) is used to define message
+given by `usage()` shell function.  `SUBDIRECTORY_OK` can be set
+if the script can run from a subdirectory of the working tree
+(some commands do not).
+
+The scriptlet sets `GIT_DIR` and `GIT_OBJECT_DIRECTORY` shell
+variables, but does *not* export them to the environment.
+
+FUNCTIONS
+---------
+
+die::
+       exit after emitting the supplied error message to the
+       standard error stream.
+
+usage::
+       die with the usage message.
+
+set_reflog_action::
+       set the message that will be recorded to describe the
+       end-user action in the reflog, when the script updates a
+       ref.
+
+is_bare_repository::
+       outputs `true` or `false` to the standard output stream
+       to indicate if the repository is a bare repository
+       (i.e. without an associated working tree).
+
+cd_to_toplevel::
+       runs chdir to the toplevel of the working tree.
+
+require_work_tree::
+       checks if the repository is a bare repository, and dies
+       if so.  Used by scripts that require working tree
+       (e.g. `checkout`).
+
 
 Author
 ------
index cc4266d..228b9f1 100644 (file)
@@ -3,7 +3,7 @@ git-shell(1)
 
 NAME
 ----
-git-shell - Restricted login shell for GIT over SSH only
+git-shell - Restricted login shell for GIT-only SSH access
 
 
 SYNOPSIS
index 95fa901..b0df92e 100644 (file)
@@ -29,7 +29,7 @@ OPTIONS
        of author alphabetic order.
 
 -s::
-       Supress commit description and provide a commit count summary only.
+       Suppress commit description and provide a commit count summary only.
 
 FILES
 -----
index 912e15b..b38633c 100644 (file)
@@ -11,7 +11,7 @@ SYNOPSIS
 'git-show-branch' [--all] [--remotes] [--topo-order] [--current]
                [--more=<n> | --list | --independent | --merge-base]
                [--no-name | --sha1-name] [--topics] [<rev> | <glob>]...
-'git-show-branch' --reflog[=<n>] <ref>
+'git-show-branch' (-g|--reflog)[=<n>[,<base>]] [--list] <ref>
 
 DESCRIPTION
 -----------
@@ -97,9 +97,11 @@ OPTIONS
        will show the revisions given by "git rev-list {caret}master
        topic1 topic2"
 
---reflog[=<n>] <ref>::
-       Shows <n> most recent ref-log entries for the given ref.
-
+--reflog[=<n>[,<base>]] <ref>::
+       Shows <n> most recent ref-log entries for the given
+       ref.  If <base> is given, <n> entries going back from
+       that entry.  <base> can be specified as count or date.
+       `-g` can be used as a short-hand for this option.
 
 Note that --more, --list, --independent and --merge-base options
 are mutually exclusive.
@@ -165,6 +167,13 @@ With this, `git show-branch` without extra parameters would show
 only the primary branches.  In addition, if you happen to be on
 your topic branch, it is shown as well.
 
+------------
+$ git show-branch --reflog='10,1 hour ago' --list master
+------------
+
+shows 10 reflog entries going back from the tip as of 1 hour ago.
+Without `--list`, the output also shows how these tips are
+topologically related with each other.
 
 
 Author
index c210b9a..9051951 100644 (file)
@@ -32,6 +32,8 @@ OPTIONS
 -------
 <object>::
        The name of the object to show.
+       For a more complete list of ways to spell object names, see
+       "SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
 
 include::pretty-formats.txt[]
 
index b7116b3..192b1f1 100644 (file)
@@ -3,7 +3,7 @@ git-ssh-fetch(1)
 
 NAME
 ----
-git-ssh-fetch - Pulls from a remote repository over ssh connection
+git-ssh-fetch - Fetch from a remote repository over ssh connection
 
 
 
index 702674e..a9b7e9f 100644 (file)
@@ -3,7 +3,7 @@ git-ssh-upload(1)
 
 NAME
 ----
-git-ssh-upload - Pushes to a remote repository over ssh connection
+git-ssh-upload - Push to a remote repository over ssh connection
 
 
 SYNOPSIS
index ce7857e..03871e5 100644 (file)
@@ -3,7 +3,7 @@ git-status(1)
 
 NAME
 ----
-git-status - Show working tree status
+git-status - Show the working tree status
 
 
 SYNOPSIS
@@ -34,6 +34,15 @@ The output from this command is designed to be used as a commit
 template comments, and all the output lines are prefixed with '#'.
 
 
+CONFIGURATION
+-------------
+
+The command honors `color.status` (or `status.color` -- they
+mean the same thing and the latter is kept for backward
+compatibility) and `color.status.<slot>` configuration variables
+to colorize its output.
+
+
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org> and
index 9ed7211..aea4a6b 100644 (file)
@@ -3,7 +3,7 @@ git-svn(1)
 
 NAME
 ----
-git-svn - bidirectional operation between Subversion and git
+git-svn - Bidirectional operation between a single Subversion branch and git
 
 SYNOPSIS
 --------
@@ -113,7 +113,7 @@ manually joining branches on commit.
 
 'commit-diff'::
        Commits the diff of two tree-ish arguments from the
-       command-line.  This command is intended for interopability with
+       command-line.  This command is intended for interoperability with
        git-svnimport and does not rely on being inside an git-svn
        init-ed repository.  This command takes three arguments, (a) the
        original tree to diff against, (b) the new tree result, (c) the
@@ -204,7 +204,7 @@ removed by default if there are no files left in them.  git
 cannot version empty directories.  Enabling this flag will make
 the commit to SVN act like git.
 
-repo-config key: svn.rmdir
+config key: svn.rmdir
 
 -e::
 --edit::
@@ -215,7 +215,7 @@ Edit the commit message before committing to SVN.  This is off by
 default for objects that are commits, and forced on when committing
 tree objects.
 
-repo-config key: svn.edit
+config key: svn.edit
 
 -l<num>::
 --find-copies-harder::
@@ -226,8 +226,8 @@ They are both passed directly to git-diff-tree see
 gitlink:git-diff-tree[1] for more information.
 
 [verse]
-repo-config key: svn.l
-repo-config key: svn.findcopiesharder
+config key: svn.l
+config key: svn.findcopiesharder
 
 -A<filename>::
 --authors-file=<filename>::
@@ -245,7 +245,7 @@ will abort operation. The user will then have to add the
 appropriate entry.  Re-running the previous git-svn command
 after the authors-file is modified should continue operation.
 
-repo-config key: svn.authorsfile
+config key: svn.authorsfile
 
 -q::
 --quiet::
@@ -262,8 +262,8 @@ repo-config key: svn.authorsfile
 
        --repack-flags are passed directly to gitlink:git-repack[1].
 
-repo-config key: svn.repack
-repo-config key: svn.repackflags
+config key: svn.repack
+config key: svn.repackflags
 
 -m::
 --merge::
@@ -304,7 +304,7 @@ used to track branches across multiple SVN _repositories_.
 This option may be specified multiple times, once for each
 branch.
 
-repo-config key: svn.branch
+config key: svn.branch
 
 -i<GIT_SVN_ID>::
 --id <GIT_SVN_ID>::
@@ -320,7 +320,7 @@ for more information on using GIT_SVN_ID.
        started tracking a branch and never tracked the trunk it was
        descended from.
 
-repo-config key: svn.followparent
+config key: svn.followparent
 
 --no-metadata::
        This gets rid of the git-svn-id: lines at the end of every commit.
@@ -332,7 +332,7 @@ repo-config key: svn.followparent
        The 'git-svn log' command will not work on repositories using this,
        either.
 
-repo-config key: svn.nometadata
+config key: svn.nometadata
 
 --
 
index 4bc35a1..f93b79a 100644 (file)
@@ -3,11 +3,11 @@ git-symbolic-ref(1)
 
 NAME
 ----
-git-symbolic-ref - read and modify symbolic refs
+git-symbolic-ref - Read and modify symbolic refs
 
 SYNOPSIS
 --------
-'git-symbolic-ref' <name> [<ref>]
+'git-symbolic-ref' [-q] <name> [<ref>]
 
 DESCRIPTION
 -----------
@@ -23,6 +23,14 @@ A symbolic ref is a regular file that stores a string that
 begins with `ref: refs/`.  For example, your `.git/HEAD` is
 a regular file whose contents is `ref: refs/heads/master`.
 
+OPTIONS
+-------
+
+-q::
+       Do not issue an error message if the <name> is not a
+       symbolic ref but a detached HEAD; instead exit with
+       non-zero status silently.
+
 NOTES
 -----
 In the past, `.git/HEAD` was a symbolic link pointing at
@@ -36,6 +44,10 @@ cumbersome.  On some platforms, `ln -sf` does not even work as
 advertised (horrors).  Therefore symbolic links are now deprecated
 and symbolic refs are used by default.
 
+git-symbolic-ref will exit with status 0 if the contents of the
+symbolic ref were printed correctly, with status 1 if the requested
+name is not a symbolic ref, or 128 if another error occurs.
+
 Author
 ------
 Written by Junio C Hamano <junkio@cox.net>
index 80bece0..3f01e0b 100644 (file)
@@ -3,14 +3,14 @@ git-tag(1)
 
 NAME
 ----
-git-tag - Create a tag object signed with GPG
+git-tag - Create, list, delete or verify a tag object signed with GPG
 
 
 SYNOPSIS
 --------
 [verse]
-'git-tag' [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg> | -F <file>]
-        <name> [<head>]
+'git-tag' [-a | -s | -u <key-id>] [-f | -v] [-m <msg> | -F <file>]  <name> [<head>]
+'git-tag' -d <name>...
 'git-tag' -l [<pattern>]
 
 DESCRIPTION
@@ -55,7 +55,7 @@ OPTIONS
        Replace an existing tag with the given name (instead of failing)
 
 -d::
-       Delete an existing tag with the given name
+       Delete existing tags with the given names.
 
 -v::
        Verify the gpg signature of given the tag
@@ -70,6 +70,16 @@ OPTIONS
        Take the tag message from the given file.  Use '-' to
        read the message from the standard input.
 
+CONFIGURATION
+-------------
+By default, git-tag in sign-with-default mode (-s) will use your
+committer identity (of the form "Your Name <your@email.address>") to
+find a key.  If you want to use a different default key, you can specify
+it in the repository configuration as follows:
+
+[user]
+    signingkey = <gpg-key-id>
+
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org>,
index 74a6fdd..5959405 100644 (file)
@@ -3,7 +3,7 @@ git-tar-tree(1)
 
 NAME
 ----
-git-tar-tree - Creates a tar archive of the files in the named tree
+git-tar-tree - Create a tar archive of the files in the named tree object
 
 
 SYNOPSIS
@@ -50,7 +50,7 @@ repository configuration as follows :
         umask = 002    ;# group friendly
 
 The special umask value "user" indicates that the user's current umask
-will be used instead. The default value remains 0, which means world
+will be used instead.  The default value is 002, which means group
 readable/writable files and directories.
 
 EXAMPLES
index 0914cbb..6b407f9 100644 (file)
@@ -50,7 +50,7 @@ History Viewers
    gitview is a GTK based repository browser for git
 
 
-   - *gitweb* (ftp://ftp.kernel.org/pub/software/scm/gitweb/)
+   - *gitweb* (shipped with git-core)
 
    GITweb provides full-fledged web interface for GIT repositories.
 
@@ -63,12 +63,18 @@ History Viewers
    Currently it is the fastest and most feature rich among the git
    viewers and commit tools.
 
+   - *tig* (http://jonas.nitro.dk/tig/)
+
+   tig by Jonas Fonseca is a simple git repository browser
+   written using ncurses. Basically, it just acts as a front-end
+   for git-log and git-show/git-diff. Additionally, you can also
+   use it as a pager for git commands.
 
 
 Foreign SCM interface
 ---------------------
 
-   - *git-svn* (contrib/)
+   - *git-svn* (shipped with git-core)
 
    git-svn is a simple conduit for changesets between a single Subversion
    branch and git.
@@ -95,3 +101,7 @@ Others
    This is an Emacs interface for git. The user interface is modeled on
    pcl-cvs. It has been developed on Emacs 21 and will probably need some
    tweaking to work on XEmacs.
+
+
+http://git.or.cz/gitwiki/InterfacesFrontendsAndTools has more
+comprehensive list.
index 0e0a3af..b161c8b 100644 (file)
@@ -3,7 +3,7 @@ git-update-index(1)
 
 NAME
 ----
-git-update-index - Modifies the index or directory cache
+git-update-index - Register file contents in the working tree to the index
 
 
 SYNOPSIS
@@ -289,7 +289,7 @@ Configuration
 
 The command honors `core.filemode` configuration variable.  If
 your repository is on an filesystem whose executable bits are
-unreliable, this should be set to 'false' (see gitlink:git-repo-config[1]).
+unreliable, this should be set to 'false' (see gitlink:git-config[1]).
 This causes the command to ignore differences in file modes recorded
 in the index and the file mode on the filesystem if they differ only on
 executable bit.   On such an unfortunate filesystem, you may
@@ -301,7 +301,7 @@ The command looks at `core.ignorestat` configuration variable.  See
 
 See Also
 --------
-gitlink:git-repo-config[1]
+gitlink:git-config[1]
 
 
 Author
index 71bcb79..9424fea 100644 (file)
@@ -3,7 +3,7 @@ git-update-ref(1)
 
 NAME
 ----
-git-update-ref - update the object name stored in a ref safely
+git-update-ref - Update the object name stored in a ref safely
 
 SYNOPSIS
 --------
index 388bb53..403871d 100644 (file)
@@ -3,7 +3,7 @@ git-upload-archive(1)
 
 NAME
 ----
-git-upload-archive - Send archive
+git-upload-archive - Send archive back to git-archive
 
 
 SYNOPSIS
index b2c9307..9da062d 100644 (file)
@@ -3,7 +3,7 @@ git-upload-pack(1)
 
 NAME
 ----
-git-upload-pack - Send missing objects packed
+git-upload-pack - Send objects packed back to git-fetch-pack
 
 
 SYNOPSIS
index a5b1a0d..9b0de1c 100644 (file)
@@ -3,7 +3,7 @@ git-var(1)
 
 NAME
 ----
-git-var - Print the git users identity
+git-var - Show a git logical variable
 
 
 SYNOPSIS
@@ -20,7 +20,7 @@ OPTIONS
        Cause the logical variables to be listed. In addition, all the
        variables of the git configuration file .git/config are listed
        as well. (However, the configuration variables listing functionality
-       is deprecated in favor of `git-repo-config -l`.)
+       is deprecated in favor of `git-config -l`.)
 
 EXAMPLE
 --------
@@ -49,7 +49,7 @@ See Also
 --------
 gitlink:git-commit-tree[1]
 gitlink:git-tag[1]
-gitlink:git-repo-config[1]
+gitlink:git-config[1]
 
 Author
 ------
index e8f21d0..399bff3 100644 (file)
@@ -27,7 +27,7 @@ OPTIONS
        output format that is useful only to tell the changed
        paths and their nature of changes.
 
---max-count=<n>::
+-<n>::
        Limit output to <n> commits.
 
 <since>..<until>::
index c85fa89..96d5e07 100644 (file)
@@ -3,7 +3,7 @@ git-write-tree(1)
 
 NAME
 ----
-git-write-tree - Creates a tree object from the current index
+git-write-tree - Create a tree object from the current index
 
 
 SYNOPSIS
index f89d745..7cd3467 100644 (file)
@@ -24,7 +24,7 @@ link:everyday.html[Everyday Git] for a useful minimum set of commands, and
 also want to read link:cvs-migration.html[CVS migration].
 
 The COMMAND is either a name of a Git command (see below) or an alias
-as defined in the configuration file (see gitlink:git-repo-config[1]).
+as defined in the configuration file (see gitlink:git-config[1]).
 
 OPTIONS
 -------
@@ -81,244 +81,26 @@ ancillary user utilities.
 Main porcelain commands
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-gitlink:git-add[1]::
-       Add paths to the index.
-
-gitlink:git-am[1]::
-       Apply patches from a mailbox, but cooler.
-
-gitlink:git-applymbox[1]::
-       Apply patches from a mailbox, original version by Linus.
-
-gitlink:git-archive[1]::
-       Creates an archive of files from a named tree.
-
-gitlink:git-bisect[1]::
-       Find the change that introduced a bug by binary search.
-
-gitlink:git-branch[1]::
-       Create and Show branches.
-
-gitlink:git-checkout[1]::
-       Checkout and switch to a branch.
-
-gitlink:git-cherry-pick[1]::
-       Cherry-pick the effect of an existing commit.
-
-gitlink:git-clean[1]::
-       Remove untracked files from the working tree.
-
-gitlink:git-clone[1]::
-       Clones a repository into a new directory.
-
-gitlink:git-commit[1]::
-       Record changes to the repository.
-
-gitlink:git-diff[1]::
-       Show changes between commits, commit and working tree, etc.
-
-gitlink:git-fetch[1]::
-       Download from a remote repository via various protocols.
-
-gitlink:git-format-patch[1]::
-       Prepare patches for e-mail submission.
-
-gitlink:git-grep[1]::
-       Print lines matching a pattern.
-
-gitlink:gitk[1]::
-       The git repository browser.
-
-gitlink:git-log[1]::
-       Shows commit logs.
-
-gitlink:git-ls-remote[1]::
-       Shows references in a remote or local repository.
-
-gitlink:git-merge[1]::
-       Grand unified merge driver.
-
-gitlink:git-mv[1]::
-       Move or rename a file, a directory, or a symlink.
-
-gitlink:git-pack-refs[1]::
-       Pack heads and tags for efficient repository access.
-
-gitlink:git-pull[1]::
-       Fetch from and merge with a remote repository or a local branch.
-
-gitlink:git-push[1]::
-       Update remote refs along with associated objects.
-
-gitlink:git-rebase[1]::
-       Rebase local commits to the updated upstream head.
-
-gitlink:git-repack[1]::
-       Pack unpacked objects in a repository.
-
-gitlink:git-rerere[1]::
-       Reuse recorded resolution of conflicted merges.
-
-gitlink:git-reset[1]::
-       Reset current HEAD to the specified state.
-
-gitlink:git-resolve[1]::
-       Merge two commits.
-
-gitlink:git-revert[1]::
-       Revert an existing commit.
-
-gitlink:git-rm[1]::
-       Remove files from the working tree and from the index.
-
-gitlink:git-shortlog[1]::
-       Summarizes 'git log' output.
-
-gitlink:git-show[1]::
-       Show one commit log and its diff.
-
-gitlink:git-show-branch[1]::
-       Show branches and their commits.
-
-gitlink:git-status[1]::
-       Shows the working tree status.
-
-gitlink:git-verify-tag[1]::
-       Check the GPG signature of tag.
-
-gitlink:git-whatchanged[1]::
-       Shows commit logs and differences they introduce.
-
+include::cmds-mainporcelain.txt[]
 
 Ancillary Commands
 ~~~~~~~~~~~~~~~~~~
 Manipulators:
 
-gitlink:git-applypatch[1]::
-       Apply one patch extracted from an e-mail.
-
-gitlink:git-archimport[1]::
-       Import an arch repository into git.
-
-gitlink:git-convert-objects[1]::
-       Converts old-style git repository.
-
-gitlink:git-cvsimport[1]::
-       Salvage your data out of another SCM people love to hate.
-
-gitlink:git-cvsexportcommit[1]::
-       Export a single commit to a CVS checkout.
-
-gitlink:git-cvsserver[1]::
-       A CVS server emulator for git.
-
-gitlink:git-gc[1]::
-       Cleanup unnecessary files and optimize the local repository.
-
-gitlink:git-lost-found[1]::
-       Recover lost refs that luckily have not yet been pruned.
-
-gitlink:git-merge-one-file[1]::
-       The standard helper program to use with `git-merge-index`.
-
-gitlink:git-prune[1]::
-       Prunes all unreachable objects from the object database.
-
-gitlink:git-quiltimport[1]::
-       Applies a quilt patchset onto the current branch.
-
-gitlink:git-reflog[1]::
-       Manage reflog information.
-
-gitlink:git-relink[1]::
-       Hardlink common objects in local repositories.
-
-gitlink:git-svn[1]::
-       Bidirectional operation between a single Subversion branch and git.
-
-gitlink:git-svnimport[1]::
-       Import a SVN repository into git.
-
-gitlink:git-sh-setup[1]::
-       Common git shell script setup code.
-
-gitlink:git-symbolic-ref[1]::
-       Read and modify symbolic refs.
-
-gitlink:git-tag[1]::
-       An example script to create a tag object signed with GPG.
-
-gitlink:git-update-ref[1]::
-       Update the object name stored in a ref safely.
-
+include::cmds-ancillarymanipulators.txt[]
 
 Interrogators:
 
-gitlink:git-annotate[1]::
-       Annotate file lines with commit info.
-
-gitlink:git-blame[1]::
-       Find out where each line in a file came from.
-
-gitlink:git-check-ref-format[1]::
-       Make sure ref name is well formed.
+include::cmds-ancillaryinterrogators.txt[]
 
-gitlink:git-cherry[1]::
-       Find commits not merged upstream.
 
-gitlink:git-count-objects[1]::
-       Count unpacked number of objects and their disk consumption.
-
-gitlink:git-daemon[1]::
-       A really simple server for git repositories.
-
-gitlink:git-fmt-merge-msg[1]::
-       Produce a merge commit message.
-
-gitlink:git-get-tar-commit-id[1]::
-       Extract commit ID from an archive created using git-tar-tree.
-
-gitlink:git-imap-send[1]::
-       Dump a mailbox from stdin into an imap folder.
-
-gitlink:git-instaweb[1]::
-       Instantly browse your working repository in gitweb.
-
-gitlink:git-mailinfo[1]::
-       Extracts patch and authorship information from a single
-       e-mail message, optionally transliterating the commit
-       message into utf-8.
-
-gitlink:git-mailsplit[1]::
-       A stupid program to split UNIX mbox format mailbox into
-       individual pieces of e-mail.
-
-gitlink:git-merge-tree[1]::
-       Show three-way merge without touching index.
-
-gitlink:git-patch-id[1]::
-       Compute unique ID for a patch.
-
-gitlink:git-parse-remote[1]::
-       Routines to help parsing `$GIT_DIR/remotes/` files.
-
-gitlink:git-request-pull[1]::
-       git-request-pull.
-
-gitlink:git-rev-parse[1]::
-       Pick out and massage parameters.
-
-gitlink:git-runstatus[1]::
-       A helper for git-status and git-commit.
-
-gitlink:git-send-email[1]::
-       Send patch e-mails out of "format-patch --mbox" output.
+Interacting with Others
+~~~~~~~~~~~~~~~~~~~~~~~
 
-gitlink:git-symbolic-ref[1]::
-       Read and modify symbolic refs.
+These commands are to interact with foreign SCM and with other
+people via patch over e-mail.
 
-gitlink:git-stripspace[1]::
-       Filter out empty lines.
+include::cmds-foreignscminterface.txt[]
 
 
 Low-level commands (plumbing)
@@ -330,129 +112,30 @@ development of alternative porcelains.  Developers of such porcelains
 might start by reading about gitlink:git-update-index[1] and
 gitlink:git-read-tree[1].
 
-We divide the low-level commands into commands that manipulate objects (in
+The interface (input, output, set of options and the semantics)
+to these low-level commands are meant to be a lot more stable
+than Porcelain level commands, because these commands are
+primarily for scripted use.  The interface to Porcelain commands
+on the other hand are subject to change in order to improve the
+end user experience.
+
+The following description divides
+the low-level commands into commands that manipulate objects (in
 the repository, index, and working tree), commands that interrogate and
 compare objects, and commands that move objects and references between
 repositories.
 
+
 Manipulation commands
 ~~~~~~~~~~~~~~~~~~~~~
-gitlink:git-apply[1]::
-       Reads a "diff -up1" or git generated patch file and
-       applies it to the working tree.
-
-gitlink:git-checkout-index[1]::
-       Copy files from the index to the working tree.
-
-gitlink:git-commit-tree[1]::
-       Creates a new commit object.
-
-gitlink:git-hash-object[1]::
-       Computes the object ID from a file.
-
-gitlink:git-index-pack[1]::
-       Build pack idx file for an existing packed archive.
-
-gitlink:git-init[1]::
-       Creates an empty git repository, or reinitialize an
-       existing one.
-
-gitlink:git-merge-file[1]::
-       Runs a threeway merge.
-
-gitlink:git-merge-index[1]::
-       Runs a merge for files needing merging.
-
-gitlink:git-mktag[1]::
-       Creates a tag object.
-
-gitlink:git-mktree[1]::
-       Build a tree-object from ls-tree formatted text.
-
-gitlink:git-pack-objects[1]::
-       Creates a packed archive of objects.
-
-gitlink:git-prune-packed[1]::
-       Remove extra objects that are already in pack files.
-
-gitlink:git-read-tree[1]::
-       Reads tree information into the index.
 
-gitlink:git-repo-config[1]::
-       Get and set options in .git/config.
-
-gitlink:git-unpack-objects[1]::
-       Unpacks objects out of a packed archive.
-
-gitlink:git-update-index[1]::
-       Registers files in the working tree to the index.
-
-gitlink:git-write-tree[1]::
-       Creates a tree from the index.
+include::cmds-plumbingmanipulators.txt[]
 
 
 Interrogation commands
 ~~~~~~~~~~~~~~~~~~~~~~
 
-gitlink:git-cat-file[1]::
-       Provide content or type/size information for repository objects.
-
-gitlink:git-describe[1]::
-       Show the most recent tag that is reachable from a commit.
-
-gitlink:git-diff-index[1]::
-       Compares content and mode of blobs between the index and repository.
-
-gitlink:git-diff-files[1]::
-       Compares files in the working tree and the index.
-
-gitlink:git-diff-stages[1]::
-       Compares two "merge stages" in the index.
-
-gitlink:git-diff-tree[1]::
-       Compares the content and mode of blobs found via two tree objects.
-
-gitlink:git-for-each-ref[1]::
-       Output information on each ref.
-
-gitlink:git-fsck-objects[1]::
-       Verifies the connectivity and validity of the objects in the database.
-
-gitlink:git-ls-files[1]::
-       Information about files in the index and the working tree.
-
-gitlink:git-ls-tree[1]::
-       Displays a tree object in human readable form.
-
-gitlink:git-merge-base[1]::
-       Finds as good common ancestors as possible for a merge.
-
-gitlink:git-name-rev[1]::
-       Find symbolic names for given revs.
-
-gitlink:git-pack-redundant[1]::
-       Find redundant pack files.
-
-gitlink:git-rev-list[1]::
-       Lists commit objects in reverse chronological order.
-
-gitlink:git-show-index[1]::
-       Displays contents of a pack idx file.
-
-gitlink:git-show-ref[1]::
-       List references in a local repository.
-
-gitlink:git-tar-tree[1]::
-       Creates a tar archive of the files in the named tree object.
-
-gitlink:git-unpack-file[1]::
-       Creates a temporary file with a blob's contents.
-
-gitlink:git-var[1]::
-       Displays a git logical variable.
-
-gitlink:git-verify-pack[1]::
-       Validates packed git archive files.
+include::cmds-plumbinginterrogators.txt[]
 
 In general, the interrogate commands do not touch the files in
 the working tree.
@@ -461,52 +144,21 @@ the working tree.
 Synching repositories
 ~~~~~~~~~~~~~~~~~~~~~
 
-gitlink:git-fetch-pack[1]::
-       Updates from a remote repository (engine for ssh and
-       local transport).
-
-gitlink:git-http-fetch[1]::
-       Downloads a remote git repository via HTTP by walking
-       commit chain.
-
-gitlink:git-local-fetch[1]::
-       Duplicates another git repository on a local system by
-       walking commit chain.
-
-gitlink:git-peek-remote[1]::
-       Lists references on a remote repository using
-       upload-pack protocol (engine for ssh and local
-       transport).
-
-gitlink:git-receive-pack[1]::
-       Invoked by 'git-send-pack' to receive what is pushed to it.
-
-gitlink:git-send-pack[1]::
-       Pushes to a remote repository, intelligently.
-
-gitlink:git-http-push[1]::
-       Push missing objects using HTTP/DAV.
+include::cmds-synchingrepositories.txt[]
 
-gitlink:git-shell[1]::
-       Restricted shell for GIT-only SSH access.
+The following are helper programs used by the above; end users
+typically do not use them directly.
 
-gitlink:git-ssh-fetch[1]::
-       Pulls from a remote repository over ssh connection by
-       walking commit chain.
+include::cmds-synchelpers.txt[]
 
-gitlink:git-ssh-upload[1]::
-       Helper "server-side" program used by git-ssh-fetch.
 
-gitlink:git-update-server-info[1]::
-       Updates auxiliary information on a dumb server to help
-       clients discover references and packs on it.
+Internal helper commands
+~~~~~~~~~~~~~~~~~~~~~~~~
 
-gitlink:git-upload-archive[1]::
-       Invoked by 'git-archive' to send a generated archive.
+These are internal helper commands used by other commands; end
+users typically do not use them directly.
 
-gitlink:git-upload-pack[1]::
-       Invoked by 'git-fetch-pack' to push
-       what are asked for.
+include::cmds-purehelpers.txt[]
 
 
 Configuration Mechanism
@@ -699,7 +351,7 @@ other
 
 Discussion[[Discussion]]
 ------------------------
-include::README[]
+include::core-intro.txt[]
 
 Authors
 -------
index f1aeb07..5bdaa60 100644 (file)
@@ -3,7 +3,7 @@ gitk(1)
 
 NAME
 ----
-gitk - git repository browser
+gitk - The git repository browser
 
 SYNOPSIS
 --------
@@ -47,6 +47,8 @@ frequently used options.
        meaning show from the given revision and back, or it can be a range in
        the form "'<from>'..'<to>'" to show all revisions between '<from>' and
        back to '<to>'. Note, more advanced revision selection can be applied.
+       For a more complete list of ways to spell object names, see
+       "SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
 
 <path>::
 
index bc917bb..d20eb62 100644 (file)
@@ -286,6 +286,18 @@ SCM::
 SHA1::
        Synonym for object name.
 
+shallow repository::
+       A shallow repository has an incomplete history some of
+       whose commits have parents cauterized away (in other
+       words, git is told to pretend that these commits do not
+       have the parents, even though they are recorded in the
+       commit object).  This is sometimes useful when you are
+       interested only in the recent history of a project even
+       though the real history recorded in the upstream is
+       much larger.  A shallow repository is created by giving
+       `--depth` option to gitlink:git-clone[1], and its
+       history can be later deepened with gitlink:git-fetch[1].
+
 symref::
        Symbolic reference: instead of containing the SHA1 id itself, it
        is of the format 'ref: refs/some/thing' and when referenced, it
diff --git a/Documentation/howto/dangling-objects.txt b/Documentation/howto/dangling-objects.txt
new file mode 100644 (file)
index 0000000..e82ddae
--- /dev/null
@@ -0,0 +1,109 @@
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Subject: Re: Question about fsck-objects output
+Date: Thu, 25 Jan 2007 12:01:06 -0800 (PST)
+Message-ID: <Pine.LNX.4.64.0701251144290.25027@woody.linux-foundation.org>
+Archived-At: <http://permalink.gmane.org/gmane.comp.version-control.git/37754>
+Abstract: Linus describes what dangling objects are, when they
+ are left behind, and how to view their relationship with branch
+ heads in gitk
+
+On Thu, 25 Jan 2007, Larry Streepy wrote:
+
+> Sorry to ask such a basic question, but I can't quite decipher the output of
+> fsck-objects.  When I run it, I get this:
+>
+>  git fsck-objects
+> dangling commit 2213f6d4dd39ca8baebd0427723723e63208521b
+> dangling commit f0d4e00196bd5ee54463e9ea7a0f0e8303da767f
+> dangling blob 6a6d0b01b3e96d49a8f2c7addd4ef8c3bd1f5761
+>
+>
+> Even after a "repack -a -d" they still exist.  The man page has a short
+> explanation, but, at least for me, it wasn't fully enlightening. :-)
+>
+> The man page says that dangling commits could be "root" commits, but since my
+> repo started as a clone of another repo, I don't see how I could have any root
+> commits.  Also, the page doesn't really describe what a dangling blob is.
+>
+> So, can someone explain what these artifacts are and if they are a problem
+> that I should be worried about?
+
+The most common situation is that you've rebased a branch (or you have
+pulled from somebody else who rebased a branch, like the "pu" branch in
+the git.git archive itself).
+
+What happens is that the old head of the original branch still exists, as
+does obviously everything it pointed to. The branch pointer itself just
+doesn't, since you replaced it with another one.
+
+However, there are certainly other situations too that cause dangling
+objects. For example, the "dangling blob" situation you have tends to be
+because you did a "git add" of a file, but then, before you actually
+committed it and made it part of the bigger picture, you changed something
+else in that file and committed that *updated* thing - the old state that
+you added originally ends up not being pointed to by any commit/tree, so
+it's now a dangling blob object.
+
+Similarly, when the "recursive" merge strategy runs, and finds that there
+are criss-cross merges and thus more than one merge base (which is fairly
+unusual, but it does happen), it will generate one temporary midway tree
+(or possibly even more, if you had lots of criss-crossing merges and
+more than two merge bases) as a temporary internal merge base, and again,
+those are real objects, but the end result will not end up pointing to
+them, so they end up "dangling" in your repository.
+
+Generally, dangling objects aren't anything to worry about. They can even
+be very useful: if you screw something up, the dangling objects can be how
+you recover your old tree (say, you did a rebase, and realized that you
+really didn't want to - you can look at what dangling objects you have,
+and decide to reset your head to some old dangling state).
+
+For commits, the most useful thing to do with dangling objects tends to be
+to do a simple
+
+       gitk <dangling-commit-sha-goes-here> --not --all
+
+which means exactly what it sounds like: it says that you want to see the
+commit history that is described by the dangling commit(s), but you do NOT
+want to see the history that is described by all your branches and tags
+(which are the things you normally reach). That basically shows you in a
+nice way what the danglign commit was (and notice that it might not be
+just one commit: we only report the "tip of the line" as being dangling,
+but there might be a whole deep and complex commit history that has gotten
+dropped - rebasing will do that).
+
+For blobs and trees, you can't do the same, but you can examine them. You
+can just do
+
+       git show <dangling-blob/tree-sha-goes-here>
+
+to show what the contents of the blob were (or, for a tree, basically what
+the "ls" for that directory was), and that may give you some idea of what
+the operation was that left that dangling object.
+
+Usually, dangling blobs and trees aren't very interesting. They're almost
+always the result of either being a half-way mergebase (the blob will
+often even have the conflict markers from a merge in it, if you have had
+conflicting merges that you fixed up by hand), or simply because you
+interrupted a "git fetch" with ^C or something like that, leaving _some_
+of the new objects in the object database, but just dangling and useless.
+
+Anyway, once you are sure that you're not interested in any dangling
+state, you can just prune all unreachable objects:
+
+       git prune
+
+and they'll be gone. But you should only run "git prune" on a quiescent
+repository - it's kind of like doing a filesystem fsck recovery: you don't
+want to do that while the filesystem is mounted.
+
+(The same is true of "git-fsck-objects" itself, btw - but since
+git-fsck-objects never actually *changes* the repository, it just reports
+on what it found, git-fsck-objects itself is never "dangerous" to run.
+Running it while somebody is actually changing the repository can cause
+confusing and scary messages, but it won't actually do anything bad. In
+contrast, running "git prune" while somebody is actively changing the
+repository is a *BAD* idea).
+
+                       Linus
+
index fcd64e9..3b3a5c2 100644 (file)
@@ -106,7 +106,7 @@ prepare #2 and #3 for e-mail submission.
 
     $ git format-patch master^^ master
 
-This creates two files, 0001-XXXX.txt and 0002-XXXX.txt.  Send
+This creates two files, 0001-XXXX.patch and 0002-XXXX.patch.  Send
 them out "To: " your project maintainer and "Cc: " your mailing
 list.  You could use contributed script git-send-email if
 your host has necessary perl modules for this, but your usual
index a202f3a..8eadc20 100644 (file)
@@ -205,7 +205,7 @@ To check whether all is OK, do:
 Now, add the remote in your existing repository which contains the project
 you want to export:
 
-   $ git-repo-config remote.upload.url \
+   $ git-config remote.upload.url \
        http://<username>@<servername>/my-new-repo.git/
 
 It is important to put the last '/'; Without it, the server will send
@@ -222,7 +222,7 @@ From your client repository, do
 
 This pushes branch 'master' (which is assumed to be the branch you
 want to export) to repository called 'upload', which we previously
-defined with git-repo-config.
+defined with git-config.
 
 
 Troubleshooting:
index 0fdd366..863cb67 100644 (file)
@@ -18,6 +18,8 @@ could have only commit objects without associated blobs and
 trees this way, for example.  A repository with this kind of
 incomplete object store is not suitable to be published to the
 outside world but sometimes useful for private repository.
+. You also could have an incomplete but locally usable repository
+by cloning shallowly.  See gitlink:git-clone[1].
 . You can be using `objects/info/alternates` mechanism, or
 `$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanism to 'borrow'
 objects from other object stores.  A repository with this kind
@@ -32,7 +34,7 @@ objects/[0-9a-f][0-9a-f]::
        two letters from its object name to keep the number of
        directory entries `objects` directory itself needs to
        hold.  Objects found here are often called 'unpacked'
-       objects.
+       (or 'loose') objects.
 
 objects/pack::
        Packs (files that store many object in compressed form,
@@ -80,6 +82,15 @@ refs/tags/`name`::
        records any object name (not necessarily a commit
        object, or a tag object that points at a commit object).
 
+refs/remotes/`name`::
+       records tip-of-the-tree commit objects of branches copied
+       from a remote repository.
+
+packed-refs::
+       records the same information as refs/heads/, refs/tags/,
+       and friends record in a more efficient way.  See
+       gitlink:git-pack-refs[1].
+
 HEAD::
        A symref (see glossary) to the `refs/heads/` namespace
        describing the currently active branch.  It does not mean
@@ -91,6 +102,12 @@ HEAD::
        'name' does not (yet) exist.  In some legacy setups, it is
        a symbolic link instead of a symref that points at the current
        branch.
++
+HEAD can also record a specific commit directly, instead of
+being a symref to point at the current branch.  Such a state
+is often called 'detached HEAD', and almost all commands work
+identically as normal.  See gitlink:git-checkout[1] for
+details.
 
 branches::
        A slightly deprecated way to store shorthands to be used
@@ -156,3 +173,9 @@ logs/refs/heads/`name`::
 
 logs/refs/tags/`name`::
        Records all changes made to the tag named `name`.
+
+shallow::
+       This is similar to `info/grafts` but is internally used
+       and maintained by shallow clone mechanism.  See `--depth`
+       option to gitlink:git-clone[1] and gitlink:git-fetch[1].
+
index f48894c..f363d17 100644 (file)
@@ -343,8 +343,8 @@ And, as you can see with cat-file, this new entry refers to the
 current contents of the file:
 
 ------------------------------------------------
-$ git cat-file blob a6b11f7a
-goodbye, word
+$ git cat-file blob 8b9743b2
+goodbye, world
 ------------------------------------------------
 
 The "status" command is a useful way to get a quick summary of the
index d2bf0b9..adb1e32 100644 (file)
@@ -11,15 +11,13 @@ diff" with:
 $ man git-diff
 ------------------------------------------------
 
-It is a good idea to introduce yourself to git before doing any
-operation.  The easiest way to do so is:
+It is a good idea to introduce yourself to git with your name and
+public email address before doing any operation.  The easiest
+way to do so is:
 
 ------------------------------------------------
-$ cat >~/.gitconfig <<\EOF
-[user]
-       name = Your Name Comes Here
-       email = you@yourdomain.example.com
-EOF
+$ git config --global user.name "Your Name Comes Here"
+$ git config --global user.email you@yourdomain.example.com
 ------------------------------------------------
 
 
@@ -211,7 +209,7 @@ at this point the two branches have diverged, with different changes
 made in each.  To merge the changes made in experimental into master, run
 
 ------------------------------------------------
-$ git pull . experimental
+$ git merge experimental
 ------------------------------------------------
 
 If the changes don't conflict, you're done.  If there are conflicts,
@@ -297,46 +295,51 @@ is the default.)
 The "pull" command thus performs two operations: it fetches changes
 from a remote branch, then merges them into the current branch.
 
-You can perform the first operation alone using the "git fetch"
-command.  For example, Alice could create a temporary branch just to
-track Bob's changes, without merging them with her own, using:
+When you are working in a small closely knit group, it is not
+unusual to interact with the same repository over and over
+again.  By defining 'remote' repository shorthand, you can make
+it easier:
+
+------------------------------------------------
+$ git remote add bob /home/bob/myrepo
+------------------------------------------------
+
+With this, you can perform the first operation alone using the
+"git fetch" command without merging them with her own branch,
+using:
 
 -------------------------------------
-$ git fetch /home/bob/myrepo master:bob-incoming
+$ git fetch bob
 -------------------------------------
 
-which fetches the changes from Bob's master branch into a new branch
-named bob-incoming.  Then
+Unlike the longhand form, when Alice fetches from Bob using a
+remote repository shorthand set up with `git remote`, what was
+fetched is stored in a remote tracking branch, in this case
+`bob/master`.  So after this:
 
 -------------------------------------
-$ git log -p master..bob-incoming
+$ git log -p master..bob/master
 -------------------------------------
 
 shows a list of all the changes that Bob made since he branched from
 Alice's master branch.
 
-After examining those changes, and possibly fixing things, Alice
-could pull the changes into her master branch:
+After examining those changes, Alice
+could merge the changes into her master branch:
 
 -------------------------------------
-$ git checkout master
-$ git pull . bob-incoming
+$ git merge bob/master
 -------------------------------------
 
-The last command is a pull from the "bob-incoming" branch in Alice's
-own repository.
-
-Alice could also perform both steps at once with:
+This `merge` can also be done by 'pulling from her own remote
+tracking branch', like this:
 
 -------------------------------------
-$ git pull /home/bob/myrepo master:bob-incoming
+$ git pull . remotes/bob/master
 -------------------------------------
 
-This is just like the "git pull /home/bob/myrepo master" that we saw
-before, except that it also stores the unmerged changes from bob's
-master branch in bob-incoming before merging them into Alice's
-current branch.  Note that git pull always merges into the current
-branch, regardless of what else is given on the commandline.
+Note that git pull always merges into the current branch,
+regardless of what else is given on the commandline.
 
 Later, Bob can update his repo with Alice's latest changes using
 
@@ -350,12 +353,12 @@ repository in the repository configuration, and that location is
 used for pulls:
 
 -------------------------------------
-$ git repo-config --get remote.origin.url
+$ git config --get remote.origin.url
 /home/bob/myrepo
 -------------------------------------
 
 (The complete configuration created by git-clone is visible using
-"git repo-config -l", and the gitlink:git-repo-config[1] man page
+"git config -l", and the gitlink:git-config[1] man page
 explains the meaning of each option.)
 
 Git also keeps a pristine copy of Alice's master branch under the
index 8502e4c..e0adc34 100755 (executable)
@@ -1,7 +1,7 @@
 #!/bin/sh
 
 GVF=GIT-VERSION-FILE
-DEF_VER=v1.5.0-rc1.GIT
+DEF_VER=v1.5.0-rc2.GIT
 
 LF='
 '
index db9d8ee..a00c5ab 100644 (file)
--- a/Makefile
+++ b/Makefile
@@ -192,7 +192,7 @@ SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
 
 # ... and all the rest that could be moved out of bindir to gitexecdir
 PROGRAMS = \
-       git-convert-objects$X git-fetch-pack$X git-fsck-objects$X \
+       git-convert-objects$X git-fetch-pack$X git-fsck$X \
        git-hash-object$X git-index-pack$X git-local-fetch$X \
        git-fast-import$X \
        git-merge-base$X \
@@ -214,7 +214,8 @@ EXTRA_PROGRAMS =
 
 BUILT_INS = \
        git-format-patch$X git-show$X git-whatchanged$X git-cherry$X \
-       git-get-tar-commit-id$X git-init$X \
+       git-get-tar-commit-id$X git-init$X git-repo-config$X \
+       git-fsck-objects$X \
        $(patsubst builtin-%.o,git-%$X,$(BUILTIN_OBJS))
 
 # what 'all' will build and 'install' will install, in gitexecdir
@@ -242,7 +243,7 @@ LIB_H = \
        diff.h object.h pack.h pkt-line.h quote.h refs.h list-objects.h sideband.h \
        run-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \
        tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h \
-       utf8.h
+       utf8.h reflog-walk.h
 
 DIFF_OBJS = \
        diff.o diff-lib.o diffcore-break.o diffcore-order.o \
@@ -255,7 +256,7 @@ LIB_OBJS = \
        interpolate.o \
        lockfile.o \
        object.o pack-check.o patch-delta.o path.o pkt-line.o sideband.o \
-       reachable.o \
+       reachable.o reflog-walk.o \
        quote.o read-cache.o refs.o run-command.o dir.o object-refs.o \
        server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
        tag.o tree.o usage.o config.o environment.o ctype.o copy.o \
@@ -284,6 +285,7 @@ BUILTIN_OBJS = \
        builtin-diff-tree.o \
        builtin-fmt-merge-msg.o \
        builtin-for-each-ref.o \
+       builtin-fsck.o \
        builtin-grep.o \
        builtin-init-db.o \
        builtin-log.o \
@@ -300,7 +302,7 @@ BUILTIN_OBJS = \
        builtin-push.o \
        builtin-read-tree.o \
        builtin-reflog.o \
-       builtin-repo-config.o \
+       builtin-config.o \
        builtin-rerere.o \
        builtin-rev-list.o \
        builtin-rev-parse.o \
diff --git a/README b/README
index cee7e43..441167c 100644 (file)
--- a/README
+++ b/README
@@ -3,6 +3,7 @@
        GIT - the stupid content tracker
 
 ////////////////////////////////////////////////////////////////
+
 "git" can mean anything, depending on your mood.
 
  - random three-letter combination that is pronounceable, and not
  - stupid. contemptible and despicable. simple. Take your pick from the
    dictionary of slang.
  - "global information tracker": you're in a good mood, and it actually
-   works for you. Angels sing, and a light suddenly fills the room. 
+   works for you. Angels sing, and a light suddenly fills the room.
  - "goddamn idiotic truckload of sh*t": when it breaks
 
-This is a stupid (but extremely fast) directory content manager.  It
-doesn't do a whole lot, but what it 'does' do is track directory
-contents efficiently. 
-
-There are two object abstractions: the "object database", and the
-"current directory cache" aka "index".
-
-The Object Database
-~~~~~~~~~~~~~~~~~~~
-The object database is literally just a content-addressable collection
-of objects.  All objects are named by their content, which is
-approximated by the SHA1 hash of the object itself.  Objects may refer
-to other objects (by referencing their SHA1 hash), and so you can
-build up a hierarchy of objects.
-
-All objects have a statically determined "type" aka "tag", which is
-determined at object creation time, and which identifies the format of
-the object (i.e. how it is used, and how it can refer to other
-objects).  There are currently four different object types: "blob",
-"tree", "commit" and "tag".
-
-A "blob" object cannot refer to any other object, and is, like the type
-implies, a pure storage object containing some user data.  It is used to
-actually store the file data, i.e. a blob object is associated with some
-particular version of some file. 
-
-A "tree" object is an object that ties one or more "blob" objects into a
-directory structure. In addition, a tree object can refer to other tree
-objects, thus creating a directory hierarchy. 
-
-A "commit" object ties such directory hierarchies together into
-a DAG of revisions - each "commit" is associated with exactly one tree
-(the directory hierarchy at the time of the commit). In addition, a
-"commit" refers to one or more "parent" commit objects that describe the
-history of how we arrived at that directory hierarchy.
-
-As a special case, a commit object with no parents is called the "root"
-object, and is the point of an initial project commit.  Each project
-must have at least one root, and while you can tie several different
-root objects together into one project by creating a commit object which
-has two or more separate roots as its ultimate parents, that's probably
-just going to confuse people.  So aim for the notion of "one root object
-per project", even if git itself does not enforce that. 
-
-A "tag" object symbolically identifies and can be used to sign other
-objects. It contains the identifier and type of another object, a
-symbolic name (of course!) and, optionally, a signature.
-
-Regardless of object type, all objects share the following
-characteristics: they are all deflated with zlib, and have a header
-that not only specifies their type, but also provides size information
-about the data in the object.  It's worth noting that the SHA1 hash
-that is used to name the object is the hash of the original data
-plus this header, so `sha1sum` 'file' does not match the object name
-for 'file'.
-(Historical note: in the dawn of the age of git the hash
-was the sha1 of the 'compressed' object.)
-
-As a result, the general consistency of an object can always be tested
-independently of the contents or the type of the object: all objects can
-be validated by verifying that (a) their hashes match the content of the
-file and (b) the object successfully inflates to a stream of bytes that
-forms a sequence of <ascii type without space> + <space> + <ascii decimal
-size> + <byte\0> + <binary object data>. 
-
-The structured objects can further have their structure and
-connectivity to other objects verified. This is generally done with
-the `git-fsck-objects` program, which generates a full dependency graph
-of all objects, and verifies their internal consistency (in addition
-to just verifying their superficial consistency through the hash).
-
-The object types in some more detail:
-
-Blob Object
-~~~~~~~~~~~
-A "blob" object is nothing but a binary blob of data, and doesn't
-refer to anything else.  There is no signature or any other
-verification of the data, so while the object is consistent (it 'is'
-indexed by its sha1 hash, so the data itself is certainly correct), it
-has absolutely no other attributes.  No name associations, no
-permissions.  It is purely a blob of data (i.e. normally "file
-contents").
-
-In particular, since the blob is entirely defined by its data, if two
-files in a directory tree (or in multiple different versions of the
-repository) have the same contents, they will share the same blob
-object. The object is totally independent of its location in the
-directory tree, and renaming a file does not change the object that
-file is associated with in any way.
-
-A blob is typically created when gitlink:git-update-index[1]
-is run, and its data can be accessed by gitlink:git-cat-file[1].
-
-Tree Object
-~~~~~~~~~~~
-The next hierarchical object type is the "tree" object.  A tree object
-is a list of mode/name/blob data, sorted by name.  Alternatively, the
-mode data may specify a directory mode, in which case instead of
-naming a blob, that name is associated with another TREE object.
-
-Like the "blob" object, a tree object is uniquely determined by the
-set contents, and so two separate but identical trees will always
-share the exact same object. This is true at all levels, i.e. it's
-true for a "leaf" tree (which does not refer to any other trees, only
-blobs) as well as for a whole subdirectory.
-
-For that reason a "tree" object is just a pure data abstraction: it
-has no history, no signatures, no verification of validity, except
-that since the contents are again protected by the hash itself, we can
-trust that the tree is immutable and its contents never change.
-
-So you can trust the contents of a tree to be valid, the same way you
-can trust the contents of a blob, but you don't know where those
-contents 'came' from.
-
-Side note on trees: since a "tree" object is a sorted list of
-"filename+content", you can create a diff between two trees without
-actually having to unpack two trees.  Just ignore all common parts,
-and your diff will look right.  In other words, you can effectively
-(and efficiently) tell the difference between any two random trees by
-O(n) where "n" is the size of the difference, rather than the size of
-the tree.
-
-Side note 2 on trees: since the name of a "blob" depends entirely and
-exclusively on its contents (i.e. there are no names or permissions
-involved), you can see trivial renames or permission changes by
-noticing that the blob stayed the same.  However, renames with data
-changes need a smarter "diff" implementation.
-
-A tree is created with gitlink:git-write-tree[1] and
-its data can be accessed by gitlink:git-ls-tree[1].
-Two trees can be compared with gitlink:git-diff-tree[1].
-
-Commit Object
-~~~~~~~~~~~~~
-The "commit" object is an object that introduces the notion of
-history into the picture.  In contrast to the other objects, it
-doesn't just describe the physical state of a tree, it describes how
-we got there, and why.
-
-A "commit" is defined by the tree-object that it results in, the
-parent commits (zero, one or more) that led up to that point, and a
-comment on what happened.  Again, a commit is not trusted per se:
-the contents are well-defined and "safe" due to the cryptographically
-strong signatures at all levels, but there is no reason to believe
-that the tree is "good" or that the merge information makes sense.
-The parents do not have to actually have any relationship with the
-result, for example.
-
-Note on commits: unlike real SCM's, commits do not contain
-rename information or file mode change information.  All of that is
-implicit in the trees involved (the result tree, and the result trees
-of the parents), and describing that makes no sense in this idiotic
-file manager.
-
-A commit is created with gitlink:git-commit-tree[1] and
-its data can be accessed by gitlink:git-cat-file[1].
-
-Trust
-~~~~~
-An aside on the notion of "trust". Trust is really outside the scope
-of "git", but it's worth noting a few things.  First off, since
-everything is hashed with SHA1, you 'can' trust that an object is
-intact and has not been messed with by external sources.  So the name
-of an object uniquely identifies a known state - just not a state that
-you may want to trust.
-
-Furthermore, since the SHA1 signature of a commit refers to the
-SHA1 signatures of the tree it is associated with and the signatures
-of the parent, a single named commit specifies uniquely a whole set
-of history, with full contents.  You can't later fake any step of the
-way once you have the name of a commit.
-
-So to introduce some real trust in the system, the only thing you need
-to do is to digitally sign just 'one' special note, which includes the
-name of a top-level commit.  Your digital signature shows others
-that you trust that commit, and the immutability of the history of
-commits tells others that they can trust the whole history.
-
-In other words, you can easily validate a whole archive by just
-sending out a single email that tells the people the name (SHA1 hash)
-of the top commit, and digitally sign that email using something
-like GPG/PGP.
-
-To assist in this, git also provides the tag object...
-
-Tag Object
-~~~~~~~~~~
-Git provides the "tag" object to simplify creating, managing and
-exchanging symbolic and signed tokens.  The "tag" object at its
-simplest simply symbolically identifies another object by containing
-the sha1, type and symbolic name.
-
-However it can optionally contain additional signature information
-(which git doesn't care about as long as there's less than 8k of
-it). This can then be verified externally to git.
-
-Note that despite the tag features, "git" itself only handles content
-integrity; the trust framework (and signature provision and
-verification) has to come from outside.
-
-A tag is created with gitlink:git-mktag[1],
-its data can be accessed by gitlink:git-cat-file[1],
-and the signature can be verified by
-gitlink:git-verify-tag[1].
-
-
-The "index" aka "Current Directory Cache"
------------------------------------------
-The index is a simple binary file, which contains an efficient
-representation of a virtual directory content at some random time.  It
-does so by a simple array that associates a set of names, dates,
-permissions and content (aka "blob") objects together.  The cache is
-always kept ordered by name, and names are unique (with a few very
-specific rules) at any point in time, but the cache has no long-term
-meaning, and can be partially updated at any time.
-
-In particular, the index certainly does not need to be consistent with
-the current directory contents (in fact, most operations will depend on
-different ways to make the index 'not' be consistent with the directory
-hierarchy), but it has three very important attributes:
-
-'(a) it can re-generate the full state it caches (not just the
-directory structure: it contains pointers to the "blob" objects so
-that it can regenerate the data too)'
-
-As a special case, there is a clear and unambiguous one-way mapping
-from a current directory cache to a "tree object", which can be
-efficiently created from just the current directory cache without
-actually looking at any other data.  So a directory cache at any one
-time uniquely specifies one and only one "tree" object (but has
-additional data to make it easy to match up that tree object with what
-has happened in the directory)
-
-'(b) it has efficient methods for finding inconsistencies between that
-cached state ("tree object waiting to be instantiated") and the
-current state.'
-
-'(c) it can additionally efficiently represent information about merge
-conflicts between different tree objects, allowing each pathname to be
-associated with sufficient information about the trees involved that
-you can create a three-way merge between them.'
-
-Those are the three ONLY things that the directory cache does.  It's a
-cache, and the normal operation is to re-generate it completely from a
-known tree object, or update/compare it with a live tree that is being
-developed.  If you blow the directory cache away entirely, you generally
-haven't lost any information as long as you have the name of the tree
-that it described. 
-
-At the same time, the index is at the same time also the
-staging area for creating new trees, and creating a new tree always
-involves a controlled modification of the index file.  In particular,
-the index file can have the representation of an intermediate tree that
-has not yet been instantiated.  So the index can be thought of as a
-write-back cache, which can contain dirty information that has not yet
-been written back to the backing store.
-
-
-
-The Workflow
-------------
-Generally, all "git" operations work on the index file. Some operations
-work *purely* on the index file (showing the current state of the
-index), but most operations move data to and from the index file. Either
-from the database or from the working directory. Thus there are four
-main combinations: 
-
-1) working directory -> index
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-You update the index with information from the working directory with
-the gitlink:git-update-index[1] command.  You
-generally update the index information by just specifying the filename
-you want to update, like so:
-
-       git-update-index filename
-
-but to avoid common mistakes with filename globbing etc, the command
-will not normally add totally new entries or remove old entries,
-i.e. it will normally just update existing cache entries.
-
-To tell git that yes, you really do realize that certain files no
-longer exist, or that new files should be added, you
-should use the `--remove` and `--add` flags respectively.
-
-NOTE! A `--remove` flag does 'not' mean that subsequent filenames will
-necessarily be removed: if the files still exist in your directory
-structure, the index will be updated with their new status, not
-removed. The only thing `--remove` means is that update-cache will be
-considering a removed file to be a valid thing, and if the file really
-does not exist any more, it will update the index accordingly.
-
-As a special case, you can also do `git-update-index --refresh`, which
-will refresh the "stat" information of each index to match the current
-stat information. It will 'not' update the object status itself, and
-it will only update the fields that are used to quickly test whether
-an object still matches its old backing store object.
-
-2) index -> object database
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-You write your current index file to a "tree" object with the program
-
-       git-write-tree
-
-that doesn't come with any options - it will just write out the
-current index into the set of tree objects that describe that state,
-and it will return the name of the resulting top-level tree. You can
-use that tree to re-generate the index at any time by going in the
-other direction:
-
-3) object database -> index
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-You read a "tree" file from the object database, and use that to
-populate (and overwrite - don't do this if your index contains any
-unsaved state that you might want to restore later!) your current
-index.  Normal operation is just
-
-               git-read-tree <sha1 of tree>
-
-and your index file will now be equivalent to the tree that you saved
-earlier. However, that is only your 'index' file: your working
-directory contents have not been modified.
-
-4) index -> working directory
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-You update your working directory from the index by "checking out"
-files. This is not a very common operation, since normally you'd just
-keep your files updated, and rather than write to your working
-directory, you'd tell the index files about the changes in your
-working directory (i.e. `git-update-index`).
-
-However, if you decide to jump to a new version, or check out somebody
-else's version, or just restore a previous tree, you'd populate your
-index file with read-tree, and then you need to check out the result
-with
-
-               git-checkout-index filename
-
-or, if you want to check out all of the index, use `-a`.
-
-NOTE! git-checkout-index normally refuses to overwrite old files, so
-if you have an old version of the tree already checked out, you will
-need to use the "-f" flag ('before' the "-a" flag or the filename) to
-'force' the checkout.
-
-
-Finally, there are a few odds and ends which are not purely moving
-from one representation to the other:
-
-5) Tying it all together
-~~~~~~~~~~~~~~~~~~~~~~~~
-To commit a tree you have instantiated with "git-write-tree", you'd
-create a "commit" object that refers to that tree and the history
-behind it - most notably the "parent" commits that preceded it in
-history.
-
-Normally a "commit" has one parent: the previous state of the tree
-before a certain change was made. However, sometimes it can have two
-or more parent commits, in which case we call it a "merge", due to the
-fact that such a commit brings together ("merges") two or more
-previous states represented by other commits.
-
-In other words, while a "tree" represents a particular directory state
-of a working directory, a "commit" represents that state in "time",
-and explains how we got there.
-
-You create a commit object by giving it the tree that describes the
-state at the time of the commit, and a list of parents:
-
-       git-commit-tree <tree> -p <parent> [-p <parent2> ..]
-
-and then giving the reason for the commit on stdin (either through
-redirection from a pipe or file, or by just typing it at the tty).
-
-git-commit-tree will return the name of the object that represents
-that commit, and you should save it away for later use. Normally,
-you'd commit a new `HEAD` state, and while git doesn't care where you
-save the note about that state, in practice we tend to just write the
-result to the file pointed at by `.git/HEAD`, so that we can always see
-what the last committed state was.
-
-Here is an ASCII art by Jon Loeliger that illustrates how
-various pieces fit together.
-
-------------
-
-                     commit-tree
-                      commit obj
-                       +----+
-                       |    |
-                       |    |
-                       V    V
-                    +-----------+
-                    | Object DB |
-                    |  Backing  |
-                    |   Store   |
-                    +-----------+
-                       ^
-           write-tree  |     |
-             tree obj  |     |
-                       |     |  read-tree
-                       |     |  tree obj
-                             V
-                    +-----------+
-                    |   Index   |
-                    |  "cache"  |
-                    +-----------+
-         update-index  ^
-             blob obj  |     |
-                       |     |
-    checkout-index -u  |     |  checkout-index
-             stat      |     |  blob obj
-                             V
-                    +-----------+
-                    |  Working  |
-                    | Directory |
-                    +-----------+
-
-------------
-
-
-6) Examining the data
-~~~~~~~~~~~~~~~~~~~~~
-
-You can examine the data represented in the object database and the
-index with various helper tools. For every object, you can use
-gitlink:git-cat-file[1] to examine details about the
-object:
-
-               git-cat-file -t <objectname>
-
-shows the type of the object, and once you have the type (which is
-usually implicit in where you find the object), you can use
-
-               git-cat-file blob|tree|commit|tag <objectname>
-
-to show its contents. NOTE! Trees have binary content, and as a result
-there is a special helper for showing that content, called
-`git-ls-tree`, which turns the binary content into a more easily
-readable form.
-
-It's especially instructive to look at "commit" objects, since those
-tend to be small and fairly self-explanatory. In particular, if you
-follow the convention of having the top commit name in `.git/HEAD`,
-you can do
-
-               git-cat-file commit HEAD
-
-to see what the top commit was.
-
-7) Merging multiple trees
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Git helps you do a three-way merge, which you can expand to n-way by
-repeating the merge procedure arbitrary times until you finally
-"commit" the state.  The normal situation is that you'd only do one
-three-way merge (two parents), and commit it, but if you like to, you
-can do multiple parents in one go.
-
-To do a three-way merge, you need the two sets of "commit" objects
-that you want to merge, use those to find the closest common parent (a
-third "commit" object), and then use those commit objects to find the
-state of the directory ("tree" object) at these points.
-
-To get the "base" for the merge, you first look up the common parent
-of two commits with
-
-               git-merge-base <commit1> <commit2>
-
-which will return you the commit they are both based on.  You should
-now look up the "tree" objects of those commits, which you can easily
-do with (for example)
-
-               git-cat-file commit <commitname> | head -1
-
-since the tree object information is always the first line in a commit
-object.
-
-Once you know the three trees you are going to merge (the one
-"original" tree, aka the common case, and the two "result" trees, aka
-the branches you want to merge), you do a "merge" read into the
-index. This will complain if it has to throw away your old index contents, so you should
-make sure that you've committed those - in fact you would normally
-always do a merge against your last commit (which should thus match
-what you have in your current index anyway).
-
-To do the merge, do
-
-               git-read-tree -m -u <origtree> <yourtree> <targettree>
-
-which will do all trivial merge operations for you directly in the
-index file, and you can just write the result out with
-`git-write-tree`.
-
-Historical note.  We did not have `-u` facility when this
-section was first written, so we used to warn that
-the merge is done in the index file, not in your
-working tree, and your working tree will not match your
-index after this step.
-This is no longer true.  The above command, thanks to `-u`
-option, updates your working tree with the merge results for
-paths that have been trivially merged.
-
-
-8) Merging multiple trees, continued
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Sadly, many merges aren't trivial. If there are files that have
-been added.moved or removed, or if both branches have modified the
-same file, you will be left with an index tree that contains "merge
-entries" in it. Such an index tree can 'NOT' be written out to a tree
-object, and you will have to resolve any such merge clashes using
-other tools before you can write out the result.
-
-You can examine such index state with `git-ls-files --unmerged`
-command.  An example:
-
-------------------------------------------------
-$ git-read-tree -m $orig HEAD $target
-$ git-ls-files --unmerged
-100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1      hello.c
-100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2      hello.c
-100644 cc44c73eb783565da5831b4d820c962954019b69 3      hello.c
-------------------------------------------------
-
-Each line of the `git-ls-files --unmerged` output begins with
-the blob mode bits, blob SHA1, 'stage number', and the
-filename.  The 'stage number' is git's way to say which tree it
-came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD`
-tree, and stage3 `$target` tree.
-
-Earlier we said that trivial merges are done inside
-`git-read-tree -m`.  For example, if the file did not change
-from `$orig` to `HEAD` nor `$target`, or if the file changed
-from `$orig` to `HEAD` and `$orig` to `$target` the same way,
-obviously the final outcome is what is in `HEAD`.  What the
-above example shows is that file `hello.c` was changed from
-`$orig` to `HEAD` and `$orig` to `$target` in a different way.
-You could resolve this by running your favorite 3-way merge
-program, e.g.  `diff3` or `merge`, on the blob objects from
-these three stages yourself, like this:
-
-------------------------------------------------
-$ git-cat-file blob 263414f... >hello.c~1
-$ git-cat-file blob 06fa6a2... >hello.c~2
-$ git-cat-file blob cc44c73... >hello.c~3
-$ merge hello.c~2 hello.c~1 hello.c~3
-------------------------------------------------
-
-This would leave the merge result in `hello.c~2` file, along
-with conflict markers if there are conflicts.  After verifying
-the merge result makes sense, you can tell git what the final
-merge result for this file is by:
-
-       mv -f hello.c~2 hello.c
-       git-update-index hello.c
-
-When a path is in unmerged state, running `git-update-index` for
-that path tells git to mark the path resolved.
-
-The above is the description of a git merge at the lowest level,
-to help you understand what conceptually happens under the hood.
-In practice, nobody, not even git itself, uses three `git-cat-file`
-for this.  There is `git-merge-index` program that extracts the
-stages to temporary files and calls a "merge" script on it:
-
-       git-merge-index git-merge-one-file hello.c
-
-and that is what higher level `git resolve` is implemented with.
+Git is a fast, scalable, distributed revision control system with an
+unusually rich command set that provides both high-level operations
+and full access to internals.
+
+Git is an Open Source project covered by the GNU General Public License.
+It was originally written by Linus Torvalds with help of a group of
+hackers around the net. It is currently maintained by Junio C Hamano.
+
+Please read the file INSTALL for installation instructions.
+See Documentation/tutorial.txt to get started, then see
+Documentation/everyday.txt for a useful minimum set of commands,
+and "man git-commandname" for documentation of each command.
+CVS users may also want to read Documentation/cvs-migration.txt.
+
+Many Git online resources are accessible from http://git.or.cz/
+including full documentation and Git related tools.
+
+The user discussion and development of Git take place on the Git
+mailing list -- everyone is welcome to post bug reports, feature
+requests, comments and patches to git@vger.kernel.org. To subscribe
+to the list, send an email with just "subscribe git" in the body to
+majordomo@vger.kernel.org. The mailing list archives are available at
+http://marc.theaimsgroup.com/?l=git and other archival sites.
index e7a1b4d..87e16aa 100644 (file)
@@ -10,7 +10,7 @@
 #include "cache-tree.h"
 
 static const char builtin_add_usage[] =
-"git-add [-n] [-v] [-f] [--interactive] [--] <filepattern>...";
+"git-add [-n] [-v] [-f] [--interactive | -i] [--] <filepattern>...";
 
 static void prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)
 {
@@ -102,7 +102,8 @@ int cmd_add(int argc, const char **argv, const char *prefix)
        int add_interactive = 0;
 
        for (i = 1; i < argc; i++) {
-               if (!strcmp("--interactive", argv[i]))
+               if (!strcmp("--interactive", argv[i]) ||
+                   !strcmp("-i", argv[i]))
                        add_interactive++;
        }
        if (add_interactive) {
index 54fd2cb..3fefdac 100644 (file)
@@ -2589,7 +2589,7 @@ static int git_apply_config(const char *var, const char *value)
 }
 
 
-int cmd_apply(int argc, const char **argv, const char *prefix)
+int cmd_apply(int argc, const char **argv, const char *unused_prefix)
 {
        int i;
        int read_stdin = 1;
index 32737d3..f613ac2 100644 (file)
@@ -74,6 +74,7 @@ static int run_remote_archiver(const char *remote, int argc,
        /* Now, start reading from fd[0] and spit it out to stdout */
        rv = recv_sideband("archive", fd[0], 1, 2);
        close(fd[0]);
+       close(fd[1]);
        rv |= finish_connect(pid);
 
        return !!rv;
index 4a1accf..3033e9b 100644 (file)
@@ -13,6 +13,7 @@
 #include "diff.h"
 #include "diffcore.h"
 #include "revision.h"
+#include "quote.h"
 #include "xdiff-interface.h"
 
 static char blame_usage[] =
@@ -27,6 +28,7 @@ static char blame_usage[] =
 "  -p, --porcelain     Show in a format designed for machine consumption\n"
 "  -L n,m              Process only line range n,m, counting from 1\n"
 "  -M, -C              Find line movements within and across files\n"
+"  --incremental       Show blame entries as we find them, incrementally\n"
 "  -S revs-file        Use revisions from revs-file instead of calling git-rev-list\n";
 
 static int longest_file;
@@ -36,6 +38,7 @@ static int max_digits;
 static int max_score_digits;
 static int show_root;
 static int blank_boundary;
+static int incremental;
 
 #ifndef DEBUG
 #define DEBUG 0
@@ -74,6 +77,10 @@ struct origin {
        char path[FLEX_ARRAY];
 };
 
+/*
+ * Given an origin, prepare mmfile_t structure to be used by the
+ * diff machinery
+ */
 static char *fill_origin_blob(struct origin *o, mmfile_t *file)
 {
        if (!o->file.ptr) {
@@ -88,6 +95,10 @@ static char *fill_origin_blob(struct origin *o, mmfile_t *file)
        return file->ptr;
 }
 
+/*
+ * Origin is refcounted and usually we keep the blob contents to be
+ * reused.
+ */
 static inline struct origin *origin_incref(struct origin *o)
 {
        if (o)
@@ -105,6 +116,11 @@ static void origin_decref(struct origin *o)
        }
 }
 
+/*
+ * Each group of lines is described by a blame_entry; it can be split
+ * as we pass blame to the parents.  They form a linked list in the
+ * scoreboard structure, sorted by the target line number.
+ */
 struct blame_entry {
        struct blame_entry *prev;
        struct blame_entry *next;
@@ -131,19 +147,24 @@ struct blame_entry {
        int s_lno;
 
        /* how significant this entry is -- cached to avoid
-        * scanning the lines over and over
+        * scanning the lines over and over.
         */
        unsigned score;
 };
 
+/*
+ * The current state of the blame assignment.
+ */
 struct scoreboard {
        /* the final commit (i.e. where we started digging from) */
        struct commit *final;
 
        const char *path;
 
-       /* the contents in the final; pointed into by buf pointers of
-        * blame_entries
+       /*
+        * The contents in the final image.
+        * Used by many functions to obtain contents of the nth line,
+        * indexed with scoreboard.lineno[blame_entry.lno].
         */
        const char *final_buf;
        unsigned long final_buf_size;
@@ -168,6 +189,11 @@ static int cmp_suspect(struct origin *a, struct origin *b)
 
 static void sanity_check_refcnt(struct scoreboard *);
 
+/*
+ * If two blame entries that are next to each other came from
+ * contiguous lines in the same origin (i.e. <commit, path> pair),
+ * merge them together.
+ */
 static void coalesce(struct scoreboard *sb)
 {
        struct blame_entry *ent, *next;
@@ -191,6 +217,12 @@ static void coalesce(struct scoreboard *sb)
                sanity_check_refcnt(sb);
 }
 
+/*
+ * Given a commit and a path in it, create a new origin structure.
+ * The callers that add blame to the scoreboard should use
+ * get_origin() to obtain shared, refcounted copy instead of calling
+ * this function directly.
+ */
 static struct origin *make_origin(struct commit *commit, const char *path)
 {
        struct origin *o;
@@ -201,6 +233,9 @@ static struct origin *make_origin(struct commit *commit, const char *path)
        return o;
 }
 
+/*
+ * Locate an existing origin or create a new one.
+ */
 static struct origin *get_origin(struct scoreboard *sb,
                                 struct commit *commit,
                                 const char *path)
@@ -215,6 +250,13 @@ static struct origin *get_origin(struct scoreboard *sb,
        return make_origin(commit, path);
 }
 
+/*
+ * Fill the blob_sha1 field of an origin if it hasn't, so that later
+ * call to fill_origin_blob() can use it to locate the data.  blob_sha1
+ * for an origin is also used to pass the blame for the entire file to
+ * the parent to detect the case where a child's blob is identical to
+ * that of its parent's.
+ */
 static int fill_blob_sha1(struct origin *origin)
 {
        unsigned mode;
@@ -235,6 +277,10 @@ static int fill_blob_sha1(struct origin *origin)
        return -1;
 }
 
+/*
+ * We have an origin -- check if the same path exists in the
+ * parent and return an origin structure to represent it.
+ */
 static struct origin *find_origin(struct scoreboard *sb,
                                  struct commit *parent,
                                  struct origin *origin)
@@ -244,12 +290,26 @@ static struct origin *find_origin(struct scoreboard *sb,
        const char *paths[2];
 
        if (parent->util) {
-               /* This is a freestanding copy of origin and not
-                * refcounted.
+               /*
+                * Each commit object can cache one origin in that
+                * commit.  This is a freestanding copy of origin and
+                * not refcounted.
                 */
                struct origin *cached = parent->util;
                if (!strcmp(cached->path, origin->path)) {
+                       /*
+                        * The same path between origin and its parent
+                        * without renaming -- the most common case.
+                        */
                        porigin = get_origin(sb, parent, cached->path);
+
+                       /*
+                        * If the origin was newly created (i.e. get_origin
+                        * would call make_origin if none is found in the
+                        * scoreboard), it does not know the blob_sha1,
+                        * so copy it.  Otherwise porigin was in the
+                        * scoreboard and already knows blob_sha1.
+                        */
                        if (porigin->refcnt == 1)
                                hashcpy(porigin->blob_sha1, cached->blob_sha1);
                        return porigin;
@@ -306,7 +366,13 @@ static struct origin *find_origin(struct scoreboard *sb,
        }
        diff_flush(&diff_opts);
        if (porigin) {
+               /*
+                * Create a freestanding copy that is not part of
+                * the refcounted origin found in the scoreboard, and
+                * cache it in the commit.
+                */
                struct origin *cached;
+
                cached = make_origin(porigin->commit, porigin->path);
                hashcpy(cached->blob_sha1, porigin->blob_sha1);
                parent->util = cached;
@@ -314,6 +380,10 @@ static struct origin *find_origin(struct scoreboard *sb,
        return porigin;
 }
 
+/*
+ * We have an origin -- find the path that corresponds to it in its
+ * parent and return an origin structure to represent it.
+ */
 static struct origin *find_rename(struct scoreboard *sb,
                                  struct commit *parent,
                                  struct origin *origin)
@@ -350,6 +420,9 @@ static struct origin *find_rename(struct scoreboard *sb,
        return porigin;
 }
 
+/*
+ * Parsing of patch chunks...
+ */
 struct chunk {
        /* line number in postimage; up to but not including this
         * line is the same as preimage
@@ -451,6 +524,11 @@ static struct patch *compare_buffer(mmfile_t *file_p, mmfile_t *file_o,
        return state.ret;
 }
 
+/*
+ * Run diff between two origins and grab the patch output, so that
+ * we can pass blame for lines origin is currently suspected for
+ * to its parent.
+ */
 static struct patch *get_patch(struct origin *parent, struct origin *origin)
 {
        mmfile_t file_p, file_o;
@@ -471,6 +549,10 @@ static void free_patch(struct patch *p)
        free(p);
 }
 
+/*
+ * Link in a new blame entry to the scorebord.  Entries that cover the
+ * same line range have been removed from the scoreboard previously.
+ */
 static void add_blame_entry(struct scoreboard *sb, struct blame_entry *e)
 {
        struct blame_entry *ent, *prev = NULL;
@@ -494,6 +576,12 @@ static void add_blame_entry(struct scoreboard *sb, struct blame_entry *e)
                e->next->prev = e;
 }
 
+/*
+ * src typically is on-stack; we want to copy the information in it to
+ * an malloced blame_entry that is already on the linked list of the
+ * scoreboard.  The origin of dst loses a refcnt while the origin of src
+ * gains one.
+ */
 static void dup_entry(struct blame_entry *dst, struct blame_entry *src)
 {
        struct blame_entry *p, *n;
@@ -513,25 +601,25 @@ static const char *nth_line(struct scoreboard *sb, int lno)
        return sb->final_buf + sb->lineno[lno];
 }
 
+/*
+ * It is known that lines between tlno to same came from parent, and e
+ * has an overlap with that range.  it also is known that parent's
+ * line plno corresponds to e's line tlno.
+ *
+ *                <---- e ----->
+ *                   <------>
+ *                   <------------>
+ *             <------------>
+ *             <------------------>
+ *
+ * Split e into potentially three parts; before this chunk, the chunk
+ * to be blamed for the parent, and after that portion.
+ */
 static void split_overlap(struct blame_entry *split,
                          struct blame_entry *e,
                          int tlno, int plno, int same,
                          struct origin *parent)
 {
-       /* it is known that lines between tlno to same came from
-        * parent, and e has an overlap with that range.  it also is
-        * known that parent's line plno corresponds to e's line tlno.
-        *
-        *                <---- e ----->
-        *                   <------>
-        *                   <------------>
-        *             <------------>
-        *             <------------------>
-        *
-        * Potentially we need to split e into three parts; before
-        * this chunk, the chunk to be blamed for parent, and after
-        * that portion.
-        */
        int chunk_end_lno;
        memset(split, 0, sizeof(struct blame_entry [3]));
 
@@ -561,11 +649,20 @@ static void split_overlap(struct blame_entry *split,
                chunk_end_lno = e->lno + e->num_lines;
        split[1].num_lines = chunk_end_lno - split[1].lno;
 
+       /*
+        * if it turns out there is nothing to blame the parent for,
+        * forget about the splitting.  !split[1].suspect signals this.
+        */
        if (split[1].num_lines < 1)
                return;
        split[1].suspect = origin_incref(parent);
 }
 
+/*
+ * split_overlap() divided an existing blame e into up to three parts
+ * in split.  Adjust the linked list of blames in the scoreboard to
+ * reflect the split.
+ */
 static void split_blame(struct scoreboard *sb,
                        struct blame_entry *split,
                        struct blame_entry *e)
@@ -573,21 +670,27 @@ static void split_blame(struct scoreboard *sb,
        struct blame_entry *new_entry;
 
        if (split[0].suspect && split[2].suspect) {
-               /* we need to split e into two and add another for parent */
+               /* The first part (reuse storage for the existing entry e) */
                dup_entry(e, &split[0]);
 
+               /* The last part -- me */
                new_entry = xmalloc(sizeof(*new_entry));
                memcpy(new_entry, &(split[2]), sizeof(struct blame_entry));
                add_blame_entry(sb, new_entry);
 
+               /* ... and the middle part -- parent */
                new_entry = xmalloc(sizeof(*new_entry));
                memcpy(new_entry, &(split[1]), sizeof(struct blame_entry));
                add_blame_entry(sb, new_entry);
        }
        else if (!split[0].suspect && !split[2].suspect)
-               /* parent covers the entire area */
+               /*
+                * The parent covers the entire area; reuse storage for
+                * e and replace it with the parent.
+                */
                dup_entry(e, &split[1]);
        else if (split[0].suspect) {
+               /* me and then parent */
                dup_entry(e, &split[0]);
 
                new_entry = xmalloc(sizeof(*new_entry));
@@ -595,6 +698,7 @@ static void split_blame(struct scoreboard *sb,
                add_blame_entry(sb, new_entry);
        }
        else {
+               /* parent and then me */
                dup_entry(e, &split[1]);
 
                new_entry = xmalloc(sizeof(*new_entry));
@@ -625,6 +729,10 @@ static void split_blame(struct scoreboard *sb,
        }
 }
 
+/*
+ * After splitting the blame, the origins used by the
+ * on-stack blame_entry should lose one refcnt each.
+ */
 static void decref_split(struct blame_entry *split)
 {
        int i;
@@ -633,6 +741,10 @@ static void decref_split(struct blame_entry *split)
                origin_decref(split[i].suspect);
 }
 
+/*
+ * Helper for blame_chunk().  blame_entry e is known to overlap with
+ * the patch hunk; split it and pass blame to the parent.
+ */
 static void blame_overlap(struct scoreboard *sb, struct blame_entry *e,
                          int tlno, int plno, int same,
                          struct origin *parent)
@@ -645,6 +757,9 @@ static void blame_overlap(struct scoreboard *sb, struct blame_entry *e,
        decref_split(split);
 }
 
+/*
+ * Find the line number of the last line the target is suspected for.
+ */
 static int find_last_in_target(struct scoreboard *sb, struct origin *target)
 {
        struct blame_entry *e;
@@ -659,6 +774,11 @@ static int find_last_in_target(struct scoreboard *sb, struct origin *target)
        return last_in_target;
 }
 
+/*
+ * Process one hunk from the patch between the current suspect for
+ * blame_entry e and its parent.  Find and split the overlap, and
+ * pass blame to the overlapping part to the parent.
+ */
 static void blame_chunk(struct scoreboard *sb,
                        int tlno, int plno, int same,
                        struct origin *target, struct origin *parent)
@@ -675,6 +795,11 @@ static void blame_chunk(struct scoreboard *sb,
        }
 }
 
+/*
+ * We are looking at the origin 'target' and aiming to pass blame
+ * for the lines it is suspected to its parent.  Run diff to find
+ * which lines came from parent and pass blame for them.
+ */
 static int pass_blame_to_parent(struct scoreboard *sb,
                                struct origin *target,
                                struct origin *parent)
@@ -695,13 +820,22 @@ static int pass_blame_to_parent(struct scoreboard *sb,
                plno = chunk->p_next;
                tlno = chunk->t_next;
        }
-       /* rest (i.e. anything above tlno) are the same as parent */
+       /* The rest (i.e. anything after tlno) are the same as the parent */
        blame_chunk(sb, tlno, plno, last_in_target, target, parent);
 
        free_patch(patch);
        return 0;
 }
 
+/*
+ * The lines in blame_entry after splitting blames many times can become
+ * very small and trivial, and at some point it becomes pointless to
+ * blame the parents.  E.g. "\t\t}\n\t}\n\n" appears everywhere in any
+ * ordinary C program, and it is not worth to say it was copied from
+ * totally unrelated file in the parent.
+ *
+ * Compute how trivial the lines in the blame_entry are.
+ */
 static unsigned ent_score(struct scoreboard *sb, struct blame_entry *e)
 {
        unsigned score;
@@ -723,6 +857,12 @@ static unsigned ent_score(struct scoreboard *sb, struct blame_entry *e)
        return score;
 }
 
+/*
+ * best_so_far[] and this[] are both a split of an existing blame_entry
+ * that passes blame to the parent.  Maintain best_so_far the best split
+ * so far, by comparing this and best_so_far and copying this into
+ * bst_so_far as needed.
+ */
 static void copy_split_if_better(struct scoreboard *sb,
                                 struct blame_entry *best_so_far,
                                 struct blame_entry *this)
@@ -742,6 +882,11 @@ static void copy_split_if_better(struct scoreboard *sb,
        memcpy(best_so_far, this, sizeof(struct blame_entry [3]));
 }
 
+/*
+ * Find the lines from parent that are the same as ent so that
+ * we can pass blames to it.  file_p has the blob contents for
+ * the parent.
+ */
 static void find_copy_in_blob(struct scoreboard *sb,
                              struct blame_entry *ent,
                              struct origin *parent,
@@ -754,6 +899,9 @@ static void find_copy_in_blob(struct scoreboard *sb,
        struct patch *patch;
        int i, plno, tlno;
 
+       /*
+        * Prepare mmfile that contains only the lines in ent.
+        */
        cp = nth_line(sb, ent->lno);
        file_o.ptr = (char*) cp;
        cnt = ent->num_lines;
@@ -789,6 +937,10 @@ static void find_copy_in_blob(struct scoreboard *sb,
        free_patch(patch);
 }
 
+/*
+ * See if lines currently target is suspected for can be attributed to
+ * parent.
+ */
 static int find_move_in_parent(struct scoreboard *sb,
                               struct origin *target,
                               struct origin *parent)
@@ -823,12 +975,15 @@ static int find_move_in_parent(struct scoreboard *sb,
        return 0;
 }
 
-
 struct blame_list {
        struct blame_entry *ent;
        struct blame_entry split[3];
 };
 
+/*
+ * Count the number of entries the target is suspected for,
+ * and prepare a list of entry and the best split.
+ */
 static struct blame_list *setup_blame_list(struct scoreboard *sb,
                                           struct origin *target,
                                           int *num_ents_p)
@@ -837,9 +992,6 @@ static struct blame_list *setup_blame_list(struct scoreboard *sb,
        int num_ents, i;
        struct blame_list *blame_list = NULL;
 
-       /* Count the number of entries the target is suspected for,
-        * and prepare a list of entry and the best split.
-        */
        for (e = sb->ent, num_ents = 0; e; e = e->next)
                if (!e->guilty && !cmp_suspect(e->suspect, target))
                        num_ents++;
@@ -853,6 +1005,11 @@ static struct blame_list *setup_blame_list(struct scoreboard *sb,
        return blame_list;
 }
 
+/*
+ * For lines target is suspected for, see if we can find code movement
+ * across file boundary from the parent commit.  porigin is the path
+ * in the parent we already tried.
+ */
 static int find_copy_in_parent(struct scoreboard *sb,
                               struct origin *target,
                               struct commit *parent,
@@ -953,7 +1110,8 @@ static int find_copy_in_parent(struct scoreboard *sb,
        return retval;
 }
 
-/* The blobs of origin and porigin exactly match, so everything
+/*
+ * The blobs of origin and porigin exactly match, so everything
  * origin is suspected for can be blamed on the parent.
  */
 static void pass_whole_blame(struct scoreboard *sb,
@@ -1038,7 +1196,7 @@ static void pass_blame(struct scoreboard *sb, struct origin *origin, int opt)
        }
 
        /*
-        * Optionally run "miff" to find moves in parents' files here.
+        * Optionally find moves in parents' files.
         */
        if (opt & PICKAXE_BLAME_MOVE)
                for (i = 0, parent = commit->parents;
@@ -1052,7 +1210,7 @@ static void pass_blame(struct scoreboard *sb, struct origin *origin, int opt)
                }
 
        /*
-        * Optionally run "ciff" to find copies from parents' files here.
+        * Optionally find copies from parents' files.
         */
        if (opt & PICKAXE_BLAME_COPY)
                for (i = 0, parent = commit->parents;
@@ -1069,72 +1227,9 @@ static void pass_blame(struct scoreboard *sb, struct origin *origin, int opt)
                origin_decref(parent_origin[i]);
 }
 
-static void assign_blame(struct scoreboard *sb, struct rev_info *revs, int opt)
-{
-       while (1) {
-               struct blame_entry *ent;
-               struct commit *commit;
-               struct origin *suspect = NULL;
-
-               /* find one suspect to break down */
-               for (ent = sb->ent; !suspect && ent; ent = ent->next)
-                       if (!ent->guilty)
-                               suspect = ent->suspect;
-               if (!suspect)
-                       return; /* all done */
-
-               origin_incref(suspect);
-               commit = suspect->commit;
-               if (!commit->object.parsed)
-                       parse_commit(commit);
-               if (!(commit->object.flags & UNINTERESTING) &&
-                   !(revs->max_age != -1 && commit->date  < revs->max_age))
-                       pass_blame(sb, suspect, opt);
-               else {
-                       commit->object.flags |= UNINTERESTING;
-                       if (commit->object.parsed)
-                               mark_parents_uninteresting(commit);
-               }
-               /* treat root commit as boundary */
-               if (!commit->parents && !show_root)
-                       commit->object.flags |= UNINTERESTING;
-
-               /* Take responsibility for the remaining entries */
-               for (ent = sb->ent; ent; ent = ent->next)
-                       if (!cmp_suspect(ent->suspect, suspect))
-                               ent->guilty = 1;
-               origin_decref(suspect);
-
-               if (DEBUG) /* sanity */
-                       sanity_check_refcnt(sb);
-       }
-}
-
-static const char *format_time(unsigned long time, const char *tz_str,
-                              int show_raw_time)
-{
-       static char time_buf[128];
-       time_t t = time;
-       int minutes, tz;
-       struct tm *tm;
-
-       if (show_raw_time) {
-               sprintf(time_buf, "%lu %s", time, tz_str);
-               return time_buf;
-       }
-
-       tz = atoi(tz_str);
-       minutes = tz < 0 ? -tz : tz;
-       minutes = (minutes / 100)*60 + (minutes % 100);
-       minutes = tz < 0 ? -minutes : minutes;
-       t = time + minutes * 60;
-       tm = gmtime(&t);
-
-       strftime(time_buf, sizeof(time_buf), "%Y-%m-%d %H:%M:%S ", tm);
-       strcat(time_buf, tz_str);
-       return time_buf;
-}
-
+/*
+ * Information on commits, used for output.
+ */
 struct commit_info
 {
        char *author;
@@ -1151,6 +1246,9 @@ struct commit_info
        char *summary;
 };
 
+/*
+ * Parse author/committer line in the commit object buffer
+ */
 static void get_ac_line(const char *inbuf, const char *what,
                        int bufsz, char *person, char **mail,
                        unsigned long *time, char **tz)
@@ -1205,7 +1303,8 @@ static void get_commit_info(struct commit *commit,
        static char committer_buf[1024];
        static char summary_buf[1024];
 
-       /* We've operated without save_commit_buffer, so
+       /*
+        * We've operated without save_commit_buffer, so
         * we now need to populate them for output.
         */
        if (!commit->buffer) {
@@ -1245,6 +1344,127 @@ static void get_commit_info(struct commit *commit,
        summary_buf[len] = 0;
 }
 
+/*
+ * To allow LF and other nonportable characters in pathnames,
+ * they are c-style quoted as needed.
+ */
+static void write_filename_info(const char *path)
+{
+       printf("filename ");
+       write_name_quoted(NULL, 0, path, 1, stdout);
+       putchar('\n');
+}
+
+/*
+ * The blame_entry is found to be guilty for the range.  Mark it
+ * as such, and show it in incremental output.
+ */
+static void found_guilty_entry(struct blame_entry *ent)
+{
+       if (ent->guilty)
+               return;
+       ent->guilty = 1;
+       if (incremental) {
+               struct origin *suspect = ent->suspect;
+
+               printf("%s %d %d %d\n",
+                      sha1_to_hex(suspect->commit->object.sha1),
+                      ent->s_lno + 1, ent->lno + 1, ent->num_lines);
+               if (!(suspect->commit->object.flags & METAINFO_SHOWN)) {
+                       struct commit_info ci;
+                       suspect->commit->object.flags |= METAINFO_SHOWN;
+                       get_commit_info(suspect->commit, &ci, 1);
+                       printf("author %s\n", ci.author);
+                       printf("author-mail %s\n", ci.author_mail);
+                       printf("author-time %lu\n", ci.author_time);
+                       printf("author-tz %s\n", ci.author_tz);
+                       printf("committer %s\n", ci.committer);
+                       printf("committer-mail %s\n", ci.committer_mail);
+                       printf("committer-time %lu\n", ci.committer_time);
+                       printf("committer-tz %s\n", ci.committer_tz);
+                       printf("summary %s\n", ci.summary);
+                       if (suspect->commit->object.flags & UNINTERESTING)
+                               printf("boundary\n");
+               }
+               write_filename_info(suspect->path);
+       }
+}
+
+/*
+ * The main loop -- while the scoreboard has lines whose true origin
+ * is still unknown, pick one brame_entry, and allow its current
+ * suspect to pass blames to its parents.
+ */
+static void assign_blame(struct scoreboard *sb, struct rev_info *revs, int opt)
+{
+       while (1) {
+               struct blame_entry *ent;
+               struct commit *commit;
+               struct origin *suspect = NULL;
+
+               /* find one suspect to break down */
+               for (ent = sb->ent; !suspect && ent; ent = ent->next)
+                       if (!ent->guilty)
+                               suspect = ent->suspect;
+               if (!suspect)
+                       return; /* all done */
+
+               /*
+                * We will use this suspect later in the loop,
+                * so hold onto it in the meantime.
+                */
+               origin_incref(suspect);
+               commit = suspect->commit;
+               if (!commit->object.parsed)
+                       parse_commit(commit);
+               if (!(commit->object.flags & UNINTERESTING) &&
+                   !(revs->max_age != -1 && commit->date < revs->max_age))
+                       pass_blame(sb, suspect, opt);
+               else {
+                       commit->object.flags |= UNINTERESTING;
+                       if (commit->object.parsed)
+                               mark_parents_uninteresting(commit);
+               }
+               /* treat root commit as boundary */
+               if (!commit->parents && !show_root)
+                       commit->object.flags |= UNINTERESTING;
+
+               /* Take responsibility for the remaining entries */
+               for (ent = sb->ent; ent; ent = ent->next)
+                       if (!cmp_suspect(ent->suspect, suspect))
+                               found_guilty_entry(ent);
+               origin_decref(suspect);
+
+               if (DEBUG) /* sanity */
+                       sanity_check_refcnt(sb);
+       }
+}
+
+static const char *format_time(unsigned long time, const char *tz_str,
+                              int show_raw_time)
+{
+       static char time_buf[128];
+       time_t t = time;
+       int minutes, tz;
+       struct tm *tm;
+
+       if (show_raw_time) {
+               sprintf(time_buf, "%lu %s", time, tz_str);
+               return time_buf;
+       }
+
+       tz = atoi(tz_str);
+       minutes = tz < 0 ? -tz : tz;
+       minutes = (minutes / 100)*60 + (minutes % 100);
+       minutes = tz < 0 ? -minutes : minutes;
+       t = time + minutes * 60;
+       tm = gmtime(&t);
+
+       strftime(time_buf, sizeof(time_buf), "%Y-%m-%d %H:%M:%S ", tm);
+       strcat(time_buf, tz_str);
+       return time_buf;
+}
+
 #define OUTPUT_ANNOTATE_COMPAT 001
 #define OUTPUT_LONG_OBJECT_NAME        002
 #define OUTPUT_RAW_TIMESTAMP   004
@@ -1279,13 +1499,13 @@ static void emit_porcelain(struct scoreboard *sb, struct blame_entry *ent)
                printf("committer-mail %s\n", ci.committer_mail);
                printf("committer-time %lu\n", ci.committer_time);
                printf("committer-tz %s\n", ci.committer_tz);
-               printf("filename %s\n", suspect->path);
+               write_filename_info(suspect->path);
                printf("summary %s\n", ci.summary);
                if (suspect->commit->object.flags & UNINTERESTING)
                        printf("boundary\n");
        }
        else if (suspect->commit->object.flags & MORE_THAN_ONE_PATH)
-               printf("filename %s\n", suspect->path);
+               write_filename_info(suspect->path);
 
        cp = nth_line(sb, ent->lno);
        for (cnt = 0; cnt < ent->num_lines; cnt++) {
@@ -1390,6 +1610,10 @@ static void output(struct scoreboard *sb, int option)
        }
 }
 
+/*
+ * To allow quick access to the contents of nth line in the
+ * final image, prepare an index in the scoreboard.
+ */
 static int prepare_lines(struct scoreboard *sb)
 {
        const char *buf = sb->final_buf;
@@ -1417,6 +1641,11 @@ static int prepare_lines(struct scoreboard *sb)
        return sb->num_lines;
 }
 
+/*
+ * Add phony grafts for use with -S; this is primarily to
+ * support git-cvsserver that wants to give a linear history
+ * to its clients.
+ */
 static int read_ancestry(const char *graft_file)
 {
        FILE *fp = fopen(graft_file, "r");
@@ -1434,6 +1663,9 @@ static int read_ancestry(const char *graft_file)
        return 0;
 }
 
+/*
+ * How many columns do we need to show line numbers in decimal?
+ */
 static int lineno_width(int lines)
 {
         int i, width;
@@ -1443,6 +1675,10 @@ static int lineno_width(int lines)
         return width;
 }
 
+/*
+ * How many columns do we need to show line numbers, authors,
+ * and filenames?
+ */
 static void find_alignment(struct scoreboard *sb, int *option)
 {
        int longest_src_lines = 0;
@@ -1481,6 +1717,10 @@ static void find_alignment(struct scoreboard *sb, int *option)
        max_score_digits = lineno_width(largest_score);
 }
 
+/*
+ * For debugging -- origin is refcounted, and this asserts that
+ * we do not underflow.
+ */
 static void sanity_check_refcnt(struct scoreboard *sb)
 {
        int baa = 0;
@@ -1502,8 +1742,9 @@ static void sanity_check_refcnt(struct scoreboard *sb)
                        ent->suspect->refcnt = -ent->suspect->refcnt;
        }
        for (ent = sb->ent; ent; ent = ent->next) {
-               /* then pick each and see if they have the the correct
-                * refcnt.
+               /*
+                * ... then pick each and see if they have the the
+                * correct refcnt.
                 */
                int found;
                struct blame_entry *e;
@@ -1533,6 +1774,10 @@ static void sanity_check_refcnt(struct scoreboard *sb)
        }
 }
 
+/*
+ * Used for the command line parsing; check if the path exists
+ * in the working tree.
+ */
 static int has_path_in_work_tree(const char *path)
 {
        struct stat st;
@@ -1555,6 +1800,9 @@ static const char *add_prefix(const char *prefix, const char *path)
        return prefix_path(prefix, strlen(prefix), path);
 }
 
+/*
+ * Parsing of (comma separated) one item in the -L option
+ */
 static const char *parse_loc(const char *spec,
                             struct scoreboard *sb, long lno,
                             long begin, long *ret)
@@ -1629,6 +1877,9 @@ static const char *parse_loc(const char *spec,
        }
 }
 
+/*
+ * Parsing of -L option
+ */
 static void prepare_blame_range(struct scoreboard *sb,
                                const char *bottomtop,
                                long lno,