Merge branch 'tr/unpack-entry-use-after-free-fix'
authorJunio C Hamano <gitster@pobox.com>
Fri, 3 May 2013 22:18:04 +0000 (15:18 -0700)
committerJunio C Hamano <gitster@pobox.com>
Fri, 3 May 2013 22:18:04 +0000 (15:18 -0700)
* tr/unpack-entry-use-after-free-fix:
  unpack_entry: avoid freeing objects in base cache

410 files changed:
.mailmap
Documentation/CodingGuidelines
Documentation/RelNotes/1.8.1.6.txt [new file with mode: 0644]
Documentation/RelNotes/1.8.2.1.txt [new file with mode: 0644]
Documentation/RelNotes/1.8.2.2.txt [new file with mode: 0644]
Documentation/RelNotes/1.8.3.txt [new file with mode: 0644]
Documentation/cat-texi.perl
Documentation/config.txt
Documentation/diff-options.txt
Documentation/git-add.txt
Documentation/git-archive.txt
Documentation/git-cat-file.txt
Documentation/git-checkout.txt
Documentation/git-commit-tree.txt
Documentation/git-commit.txt
Documentation/git-count-objects.txt
Documentation/git-credential.txt
Documentation/git-daemon.txt
Documentation/git-describe.txt
Documentation/git-difftool.txt
Documentation/git-fast-export.txt
Documentation/git-filter-branch.txt
Documentation/git-format-patch.txt
Documentation/git-fsck.txt
Documentation/git-help.txt
Documentation/git-http-backend.txt
Documentation/git-index-pack.txt
Documentation/git-log.txt
Documentation/git-ls-files.txt
Documentation/git-merge-index.txt
Documentation/git-merge.txt
Documentation/git-pack-objects.txt
Documentation/git-patch-id.txt
Documentation/git-pull.txt
Documentation/git-push.txt
Documentation/git-remote-ext.txt
Documentation/git-remote.txt
Documentation/git-replace.txt
Documentation/git-rev-parse.txt
Documentation/git-rm.txt
Documentation/git-send-email.txt
Documentation/git-sh-setup.txt
Documentation/git-shell.txt
Documentation/git-shortlog.txt
Documentation/git-show-branch.txt
Documentation/git-show-index.txt
Documentation/git-show-ref.txt
Documentation/git-status.txt
Documentation/git-submodule.txt
Documentation/git-svn.txt
Documentation/git-tag.txt
Documentation/git-tools.txt
Documentation/git-update-index.txt
Documentation/git-verify-pack.txt
Documentation/git-verify-tag.txt
Documentation/git.txt
Documentation/gitcli.txt
Documentation/gitcore-tutorial.txt
Documentation/gitdiffcore.txt
Documentation/githooks.txt
Documentation/gitremote-helpers.txt
Documentation/gitrepository-layout.txt
Documentation/gittutorial-2.txt
Documentation/gitweb.conf.txt
Documentation/glossary-content.txt
Documentation/howto/recover-corrupted-blob-object.txt
Documentation/merge-options.txt
Documentation/merge-strategies.txt
Documentation/pretty-formats.txt
Documentation/revisions.txt
Documentation/technical/api-argv-array.txt
Documentation/technical/api-credentials.txt
Documentation/technical/api-directory-listing.txt
Documentation/technical/api-ref-iteration.txt
Documentation/technical/api-sha1-array.txt
Documentation/technical/api-strbuf.txt
Documentation/technical/index-format.txt
Documentation/technical/pack-format.txt
Documentation/technical/pack-heuristics.txt
Documentation/technical/shallow.txt
Documentation/user-manual.txt
GIT-VERSION-GEN
INSTALL
Makefile
RelNotes
advice.c
advice.h
archive-zip.c
archive.c
attr.c
bisect.c
branch.c
builtin/add.c
builtin/apply.c
builtin/archive.c
builtin/blame.c
builtin/branch.c
builtin/cat-file.c
builtin/check-ignore.c
builtin/checkout.c
builtin/clone.c
builtin/commit-tree.c
builtin/commit.c
builtin/count-objects.c
builtin/describe.c
builtin/fast-export.c
builtin/fetch-pack.c
builtin/fmt-merge-msg.c
builtin/grep.c
builtin/help.c
builtin/index-pack.c
builtin/log.c
builtin/ls-files.c
builtin/mailsplit.c
builtin/merge-tree.c
builtin/merge.c
builtin/prune.c
builtin/push.c
builtin/receive-pack.c
builtin/reflog.c
builtin/remote.c
builtin/revert.c
builtin/rm.c
builtin/send-pack.c
builtin/shortlog.c
builtin/show-branch.c
builtin/tag.c
builtin/update-index.c
builtin/upload-archive.c
builtin/verify-tag.c
bundle.c
cache.h
combine-diff.c
commit.c
commit.h
compat/cygwin.c
compat/cygwin.h
compat/msvc.h
compat/nedmalloc/malloc.c.h
compat/obstack.h
compat/precompose_utf8.c
compat/regex/regcomp.c
compat/regex/regex.c
compat/regex/regex_internal.c
compat/vcbuild/include/sys/poll.h [deleted file]
compat/vcbuild/include/unistd.h
config.mak.in
config.mak.uname
connect.c
contrib/completion/git-completion.bash
contrib/completion/git-completion.zsh
contrib/completion/git-prompt.sh
contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
contrib/credential/netrc/Makefile [new file with mode: 0644]
contrib/credential/netrc/git-credential-netrc [new file with mode: 0755]
contrib/credential/netrc/test.netrc [new file with mode: 0644]
contrib/credential/netrc/test.pl [new file with mode: 0755]
contrib/credential/osxkeychain/git-credential-osxkeychain.c
contrib/credential/wincred/git-credential-wincred.c
contrib/examples/git-remote.perl
contrib/examples/git-svnimport.perl
contrib/fast-import/git-import.perl
contrib/fast-import/git-import.sh
contrib/fast-import/import-zips.py
contrib/hooks/setgitperms.perl
contrib/mw-to-git/git-remote-mediawiki.perl
contrib/mw-to-git/git-remote-mediawiki.txt
contrib/mw-to-git/t/README
contrib/mw-to-git/t/install-wiki.sh
contrib/mw-to-git/t/install-wiki/LocalSettings.php
contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh
contrib/remote-helpers/Makefile
contrib/remote-helpers/git-remote-bzr
contrib/remote-helpers/git-remote-hg
contrib/remote-helpers/test-bzr.sh
contrib/remote-helpers/test-hg-bidi.sh
contrib/remote-helpers/test-hg-hg-git.sh
contrib/remote-helpers/test-hg.sh
contrib/subtree/t/t7900-subtree.sh
convert.c
daemon.c
date.c
diff.c
diffcore-break.c
diffcore-pickaxe.c
diffcore-rename.c
dir.c
dir.h
entry.c
environment.c
fast-import.c
fetch-pack.c
fetch-pack.h
git-add--interactive.perl
git-am.sh
git-archimport.perl
git-bisect.sh
git-compat-util.h
git-cvsexportcommit.perl
git-cvsimport.perl
git-cvsserver.perl
git-difftool.perl
git-filter-branch.sh
git-merge-one-file.sh
git-p4.py
git-pull.sh
git-quiltimport.sh
git-rebase--am.sh
git-rebase--interactive.sh
git-rebase.sh
git-relink.perl
git-remote-testgit
git-send-email.perl
git-sh-setup.sh
git-submodule.sh
git-svn.perl
git-web--browse.sh
git.c
gitweb/INSTALL
gitweb/gitweb.perl
gpg-interface.c
gpg-interface.h
graph.c
graph.h
grep.c
grep.h
hash.h
help.c
http-backend.c
http-push.c
http.c
http.h
imap-send.c
kwset.c
log-tree.c
log-tree.h
match-trees.c
mergetools/p4merge
name-hash.c
object.c
object.h
pack-refs.c
path.c
perl/Git.pm
perl/Git/I18N.pm
perl/Git/SVN/Ra.pm
perl/private-Error.pm
pkt-line.c
pkt-line.h
po/README
po/de.po
po/git.pot
po/sv.po
po/vi.po
po/zh_CN.po
pretty.c
progress.c
reachable.c
read-cache.c
refs.c
refs.h
remote-curl.c
remote.c
remote.h
rerere.c
resolve-undo.c
resolve-undo.h
revision.c
revision.h
run-command.c
send-pack.c
sequencer.c
sequencer.h
setup.c
sha1_file.c
sha1_name.c
shell.c
sideband.c
sideband.h
strbuf.c
strbuf.h
streaming.c
submodule.c
submodule.h
t/Makefile
t/README
t/lib-git-svn.sh
t/lib-gpg/pubring.gpg
t/lib-gpg/random_seed
t/lib-gpg/secring.gpg
t/lib-gpg/trustdb.gpg
t/lib-httpd/apache.conf
t/t0024-crlf-archive.sh
t/t1006-cat-file.sh
t/t1011-read-tree-sparse-checkout.sh
t/t1060-object-corruption.sh [new file with mode: 0755]
t/t1300-repo-config.sh
t/t1507-rev-parse-upstream.sh
t/t1509/prepare-chroot.sh
t/t1510-repo-setup.sh
t/t2003-checkout-cache-mkdir.sh
t/t2022-checkout-paths.sh
t/t2030-unresolve-info.sh
t/t2200-add-update.sh
t/t3001-ls-files-others-exclude.sh
t/t3200-branch.sh
t/t3203-branch-output.sh
t/t3211-peel-ref.sh [new file with mode: 0755]
t/t3400-rebase.sh
t/t3404-rebase-interactive.sh
t/t3508-cherry-pick-many-commits.sh
t/t3511-cherry-pick-x.sh [new file with mode: 0755]
t/t3600-rm.sh
t/t3701-add-interactive.sh
t/t4001-diff-rename.sh
t/t4014-format-patch.sh
t/t4018-diff-funcname.sh
t/t4034-diff-words.sh
t/t4038-diff-combined.sh
t/t4124-apply-ws-rule.sh
t/t4150-am.sh
t/t4202-log.sh
t/t4205-log-pretty-formats.sh
t/t4207-log-decoration-colors.sh
t/t4209-log-pickaxe.sh
t/t4212-log-corrupt.sh [new file with mode: 0755]
t/t4300-merge-tree.sh
t/t5002-archive-attr-pattern.sh
t/t5003-archive-zip.sh
t/t5004-archive-corner-cases.sh [new file with mode: 0755]
t/t5004/empty.zip [new file with mode: 0644]
t/t5304-prune.sh
t/t5404-tracking-branches.sh
t/t5500-fetch-pack.sh
t/t5503-tagfollow.sh
t/t5505-remote.sh
t/t5516-fetch-push.sh
t/t5517-push-mirror.sh
t/t5519-push-alternates.sh
t/t5520-pull.sh
t/t5521-pull-options.sh
t/t5531-deep-submodule-push.sh
t/t5541-http-push.sh
t/t5550-http-fetch.sh
t/t5551-http-fetch.sh
t/t5570-git-daemon.sh
t/t5700-clone-reference.sh
t/t5704-bundle.sh
t/t5710-info-alternate.sh
t/t5801-remote-helpers.sh
t/t6006-rev-list-format.sh
t/t6009-rev-list-parent.sh
t/t6012-rev-list-simplify.sh
t/t6030-bisect-porcelain.sh
t/t6200-fmt-merge-msg.sh
t/t7003-filter-branch.sh
t/t7004-tag.sh
t/t7060-wtstatus.sh
t/t7061-wtstatus-ignore.sh
t/t7062-wtstatus-ignorecase.sh [new file with mode: 0755]
t/t7300-clean.sh
t/t7400-submodule-basic.sh
t/t7406-submodule-update.sh
t/t7409-submodule-detached-worktree.sh
t/t7500-commit.sh
t/t7502-commit.sh
t/t7508-status.sh
t/t7512-status-help.sh
t/t7600-merge.sh
t/t7601-merge-pull-config.sh
t/t7610-mergetool.sh
t/t7612-merge-verify-signatures.sh [new file with mode: 0755]
t/t7800-difftool.sh
t/t7811-grep-open.sh
t/t9001-send-email.sh
t/t9010-svn-fe.sh
t/t9020-remote-svn.sh
t/t9300-fast-import.sh
t/t9350-fast-export.sh
t/t9400-git-cvsserver-server.sh
t/t9401-git-cvsserver-crlf.sh
t/t9500-gitweb-standalone-no-errors.sh
t/t9501-gitweb-standalone-http-status.sh
t/t9700/test.pl
t/t9808-git-p4-chdir.sh
t/t9902-completion.sh
t/t9903-bash-prompt.sh
t/test-lib-functions.sh
t/test-lib.sh
t/valgrind/valgrind.sh
templates/hooks--update.sample
test-chmtime.c
test-delta.c
test-genrandom.c
test-svn-fe.c
transport-helper.c
transport.c
transport.h
unpack-trees.c
unpack-trees.h
upload-pack.c
usage.c
utf8.c
utf8.h
write_or_die.c
wt-status.c
wt-status.h
xdiff/xdiffi.c
xdiff/xhistogram.c
zlib.c

index c7e8618..48d7acf 100644 (file)
--- a/.mailmap
+++ b/.mailmap
@@ -73,6 +73,7 @@ Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
 <nico@fluxnic.net> <nico@cam.org>
 Peter Krefting <peter@softwolves.pp.se> <peter@svarten.intern.softwolves.pp.se>
 Peter Krefting <peter@softwolves.pp.se> <peter@softwolves.pp.se>
+Petr Baudis <pasky@ucw.cz> <pasky@suse.cz>
 Philippe Bruhat <book@cpan.org>
 Ralf Thielow <ralf.thielow@gmail.com> <ralf.thielow@googlemail.com>
 Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
index b1bfff6..7e4d571 100644 (file)
@@ -237,6 +237,9 @@ For Python scripts:
 
 Writing Documentation:
 
+ Most (if not all) of the documentation pages are written in AsciiDoc
+ and processed into HTML output and manpages.
+
  Every user-visible change should be reflected in the documentation.
  The same general rule as for code applies -- imitate the existing
  conventions.  A few commented examples follow to provide reference
diff --git a/Documentation/RelNotes/1.8.1.6.txt b/Documentation/RelNotes/1.8.1.6.txt
new file mode 100644 (file)
index 0000000..c15cf2e
--- /dev/null
@@ -0,0 +1,39 @@
+Git 1.8.1.6 Release Notes
+=========================
+
+Fixes since v1.8.1.5
+--------------------
+
+ * An earlier change to the attribute system introduced at v1.8.1.2 by
+   mistake stopped a pattern "dir" (without trailing slash) from
+   matching a directory "dir" (it only wanted to allow pattern "dir/"
+   to also match).
+
+ * The code to keep track of what directory names are known to Git on
+   platforms with case insensitive filesystems can get confused upon a
+   hash collision between these pathnames and looped forever.
+
+ * When the "--prefix" option is used to "checkout-index", the code
+   did not pick the correct output filter based on the attribute
+   setting.
+
+ * Annotated tags outside refs/tags/ hierarchy were not advertised
+   correctly to the ls-remote and fetch with recent version of Git.
+
+ * The logic used by "git diff -M --stat" to shorten the names of
+   files before and after a rename did not work correctly when the
+   common prefix and suffix between the two filenames overlapped.
+
+ * "git update-index -h" did not do the usual "-h(elp)" thing.
+
+ * perl/Git.pm::cat_blob slurped everything in core only to write it
+   out to a file descriptor, which was not a very smart thing to do.
+
+ * The SSL peer verification done by "git imap-send" did not ask for
+   Server Name Indication (RFC 4366), failing to connect SSL/TLS
+   sites that serve multiple hostnames on a single IP.
+
+ * "git bundle verify" did not say "records a complete history" for a
+   bundle that does not have any prerequisites.
+
+Also contains various documentation fixes.
diff --git a/Documentation/RelNotes/1.8.2.1.txt b/Documentation/RelNotes/1.8.2.1.txt
new file mode 100644 (file)
index 0000000..1354ad0
--- /dev/null
@@ -0,0 +1,115 @@
+Git v1.8.2.1 Release Notes
+==========================
+
+Fixes since v1.8.2
+------------------
+
+ * An earlier change to the attribute system introduced at v1.8.1.2 by
+   mistake stopped a pattern "dir" (without trailing slash) from
+   matching a directory "dir" (it only wanted to allow pattern "dir/"
+   to also match).
+
+ * Verification of signed tags were not done correctly when not in C
+   or en/US locale.
+
+ * 'git commit -m "$msg"' used to add an extra newline even when
+   $msg already ended with one.
+
+ * The "--match=<pattern>" option of "git describe", when used with
+   "--all" to allow refs that are not annotated tags to be used as a
+   base of description, did not restrict the output from the command
+   to those that match the given pattern.
+
+ * An aliased command spawned from a bare repository that does not say
+   it is bare with "core.bare = yes" is treated as non-bare by mistake.
+
+ * When "format-patch" quoted a non-ascii strings on the header files,
+   it incorrectly applied rfc2047 and chopped a single character in
+   the middle of it.
+
+ * "git archive" reports a failure when asked to create an archive out
+   of an empty tree.  It would be more intuitive to give an empty
+   archive back in such a case.
+
+ * "git tag -f <tag>" always said "Updated tag '<tag>'" even when
+   creating a new tag (i.e. not overwriting nor updating).
+
+ * "git cmd -- ':(top'" was not diagnosed as an invalid syntax, and
+   instead the parser kept reading beyond the end of the string.
+
+ * Annotated tags outside refs/tags/ hierarchy were not advertised
+   correctly to the ls-remote and fetch with recent version of Git.
+
+ * The code to keep track of what directory names are known to Git on
+   platforms with case insensitive filesystems can get confused upon a
+   hash collision between these pathnames and looped forever.
+
+ * The logic used by "git diff -M --stat" to shorten the names of
+   files before and after a rename did not work correctly when the
+   common prefix and suffix between the two filenames overlapped.
+
+ * "git submodule update", when recursed into sub-submodules, did not
+   acccumulate the prefix paths.
+
+ * "git am $maildir/" applied messages in an unexpected order; sort
+   filenames read from the maildir/ in a way that is more likely to
+   sort messages in the order the writing MUA meant to, by sorting
+   numeric segment in numeric order and non-numeric segment in
+   alphabetical order.
+
+ * When export-subst is used, "zip" output recorded incorrect
+   size of the file.
+
+ * Some platforms and users spell UTF-8 differently; retry with the
+   most official "UTF-8" when the system does not understand the
+   user-supplied encoding name that are the common alternative
+   spellings of UTF-8.
+
+ * "git branch" did not bother to check nonsense command line
+   parameters and issue errors in many cases.
+
+ * "git update-index -h" did not do the usual "-h(elp)" thing.
+
+ * perl/Git.pm::cat_blob slurped everything in core only to write it
+   out to a file descriptor, which was not a very smart thing to do.
+
+ * The SSL peer verification done by "git imap-send" did not ask for
+   Server Name Indication (RFC 4366), failing to connect SSL/TLS
+   sites that serve multiple hostnames on a single IP.
+
+ * "git index-pack" had a buffer-overflow while preparing an
+   informational message when the translated version of it was too
+   long.
+
+ * Clarify in the documentation "what" gets pushed to "where" when the
+   command line to "git push" does not say these explicitly.
+
+ * In "git reflog expire", REACHABLE bit was not cleared from the
+   correct objects.
+
+ * The "--color=<when>" argument to the commands in the diff family
+   was described poorly.
+
+ * The arguments given to pre-rebase hook were not documented.
+
+ * The v4 index format was not documented.
+
+ * The "--match=<pattern>" argument "git describe" takes uses glob
+   pattern but it wasn't obvious from the documentation.
+
+ * Some sources failed to compile on systems that lack NI_MAXHOST in
+   their system header (e.g. z/OS).
+
+ * Add an example use of "--env-filter" in "filter-branch"
+   documentation.
+
+ * "git bundle verify" did not say "records a complete history" for a
+   bundle that does not have any prerequisites.
+
+ * In the v1.8.0 era, we changed symbols that do not have to be global
+   to file scope static, but a few functions in graph.c were used by
+   CGit from sideways bypassing the entry points of the API the
+   in-tree users use.
+
+ * "git merge-tree" had a typo in the logic to detect d/f conflicts,
+   which caused it to segfault in some cases.
diff --git a/Documentation/RelNotes/1.8.2.2.txt b/Documentation/RelNotes/1.8.2.2.txt
new file mode 100644 (file)
index 0000000..dab4831
--- /dev/null
@@ -0,0 +1,61 @@
+Git v1.8.2.2 Release Notes
+==========================
+
+Fixes since v1.8.2.1
+--------------------
+
+ * Zsh completion forgot that '%' character used to signal untracked
+   files needs to be escaped with another '%'.
+
+ * A commit object whose author or committer ident are malformed
+   crashed some code that trusted that a name, an email and an
+   timestamp can always be found in it.
+
+ * The new core.commentchar configuration was not applied to a few
+   places.
+
+ * "git pull --rebase" did not pass "-v/-q" options to underlying
+   "git rebase".
+
+ * When receive-pack detects error in the pack header it received in
+   order to decide which of unpack-objects or index-pack to run, it
+   returned without closing the error stream, which led to a hang
+   sideband thread.
+
+ * "git diff --diff-algorithm=algo" was understood by the command line
+   parser, but "git diff --diff-algorithm algo" was not.
+
+ * "git log -S/-G" started paying attention to textconv filter, but
+   there was no way to disable this.  Make it honor --no-textconv
+   option.
+
+ * "git merge $(git rev-parse v1.8.2)" behaved quite differently from
+   "git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did
+   not pay much attention to the annotated tag payload.  Make the code
+   notice the type of the tag object, in addition to the dwim_ref()
+   based classification the current code uses (i.e. the name appears
+   in refs/tags/) to decide when to special case merging of tags.
+
+ * "git cherry-pick" and "git revert" can take more than one commit
+   on the command line these days, but it was not mentioned on the usage
+   text.
+
+ * Perl scripts like "git-svn" closed (not redirecting to /dev/null)
+   the standard error stream, which is not a very smart thing to do.
+   Later open may return file descriptor #2 for unrelated purpose, and
+   error reporting code may write into them.
+
+ * "git apply --whitespace=fix" was not prepared to see a line getting
+   longer after fixing whitespaces (e.g. tab-in-indent aka Python).
+
+ * "git diff/log --cc" did not work well with options that ignore
+   whitespace changes.
+
+ * Documentation on setting up a http server that requires
+   authentication only on the push but not fetch has been clarified.
+
+ * A few bugfixes to "git rerere" working on corner case merge
+   conflicts have been applied.
+
+ * "git bundle" did not like a bundle created using a commit without
+   any message as its one of the prerequistes.
diff --git a/Documentation/RelNotes/1.8.3.txt b/Documentation/RelNotes/1.8.3.txt
new file mode 100644 (file)
index 0000000..b0cd887
--- /dev/null
@@ -0,0 +1,430 @@
+Git v1.8.3 Release Notes
+========================
+
+Backward compatibility notes (for Git 2.0)
+------------------------------------------
+
+When "git push [$there]" does not say what to push, we have used the
+traditional "matching" semantics so far (all your branches were sent
+to the remote as long as there already are branches of the same name
+over there).  In Git 2.0, the default will change to the "simple"
+semantics that pushes only the current branch to the branch with the same
+name, and only when the current branch is set to integrate with that
+remote branch.  Use the user preference configuration variable
+"push.default" to change this.  If you are an old-timer who is used
+to the "matching" semantics, you can set the variable to "matching"
+to keep the traditional behaviour.  If you want to live in the future
+early, you can set it to "simple" today without waiting for Git 2.0.
+
+When "git add -u" (and "git add -A") is run inside a subdirectory and
+does not specify which paths to add on the command line, it
+will operate on the entire tree in Git 2.0 for consistency
+with "git commit -a" and other commands.  There will be no
+mechanism to make plain "git add -u" behave like "git add -u .".
+Current users of "git add -u" (without a pathspec) should start
+training their fingers to explicitly say "git add -u ."
+before Git 2.0 comes.  A warning is issued when these commands are
+run without a pathspec and when you have local changes outside the
+current directory, because the behaviour in Git 2.0 will be different
+from today's version in such a situation.
+
+In Git 2.0, "git add <path>" will behave as "git add -A <path>", so
+that "git add dir/" will notice paths you removed from the directory
+and record the removal.  Versions before Git 2.0, including this
+release, will keep ignoring removals, but the users who rely on this
+behaviour are encouraged to start using "git add --ignore-removal <path>"
+now before 2.0 is released.
+
+
+Updates since v1.8.2
+--------------------
+
+Foreign interface
+
+ * remote-hg and remote-bzr helpers (in contrib/) have been updated.
+
+
+UI, Workflows & Features
+
+ * The prompt string generator (in contrib/completion/) learned to
+   show how many changes there are in total and how many have been
+   replayed during a "git rebase" session.
+
+ * "git branch --vv" learned to paint the name of the branch it
+   integrates with in a different color (color.branch.upstream,
+   which defaults to blue).
+
+ * In a sparsely populated working tree, "git checkout <pathspec>" no
+   longer unmarks paths that match the given pathspec that were
+   originally ignored with "--sparse" (use --ignore-skip-worktree-bits
+   option to resurrect these paths out of the index if you really want
+   to).
+
+ * "git log --format" specifier learned %C(auto) token that tells Git
+   to use color when interpolating %d (decoration), %h (short commit
+   object name), etc. for terminal output.
+
+ * "git bisect" leaves the final outcome as a comment in its bisect
+   log file.
+
+ * "git clone --reference" can now refer to a gitfile "textual symlink"
+   that points at the real location of the repository.
+
+ * "git count-objects" learned "--human-readable" aka "-H" option to
+   show various large numbers in Ki/Mi/GiB scaled as necessary.
+
+ * "git cherry-pick $blob" and "git cherry-pick $tree" are nonsense,
+   and a more readable error message e.g. "can't cherry-pick a tree"
+   is given (we used to say "expected exactly one commit").
+
+ * The "--annotate" option to "git send-email" can be turned on (or
+   off) by default with sendemail.annotate configuration variable (you
+   can use --no-annotate from the command line to override it).
+
+ * The "--cover-letter" option to "git format-patch" can be turned on
+   (or off) by default with format.coverLetter configuration
+   variable. By setting it to 'auto', you can turn it on only for a
+   series with two or more patches.
+
+ * The bash completion support (in contrib/) learned that cherry-pick
+   takes a few more options than it already knew about.
+
+ * "git help" learned "-g" option to show the list of guides just like
+   list of commands are given with "-a".
+
+ * A triangular "pull from one place, push to another place" workflow
+   is supported better by new remote.pushdefault (overrides the
+   "origin" thing) and branch.*.pushremote (overrides the
+   branch.*.remote) configuration variables.
+
+ * "git status" learned to report that you are in the middle of a
+   revert session, just like it does for a cherry-pick and a bisect
+   session.
+
+ * The handling by "git branch --set-upstream-to" against various forms
+   of erroneous inputs was suboptimal and has been improved.
+
+ * When the interactive access to git-shell is not enabled, it issues
+   a message meant to help the system administrator to enable it.
+   An explicit way to help the end users who connect to the service by
+   issuing custom messages to refuse such an access has been added.
+
+ * In addition to the case where the user edits the log message with
+   the "e)dit" option of "am -i", replace the "Applying: this patch"
+   message with the final log message contents after applymsg hook
+   munges it.
+
+ * "git status" suggests users to look into using --untracked=no option
+   when it takes too long.
+
+ * "git status" shows a bit more information during a
+   rebase/bisect session.
+
+ * "git fetch" learned to fetch a commit at the tip of an unadvertised
+   ref by specifying a raw object name from the command line when the
+   server side supports this feature.
+
+ * Output from "git log --graph" works better with submodule log
+   output now.
+
+ * "git count-objects -v" learned to report leftover temporary
+   packfiles and other garbage in the object store.
+
+ * A new read-only credential helper (in contrib/) to interact with
+   the .netrc/.authinfo files has been added.
+
+ * "git send-email" can be used with the credential helper system.
+
+ * There was no Porcelain way to say "I no longer am interested in
+   this submodule", once you express your interest in a submodule with
+   "submodule init".  "submodule deinit" is the way to do so.
+
+ * "git pull --rebase" learned to pass "-v/-q" options to underlying
+   "git rebase".
+
+ * The new "--follow-tags" option tells "git push" to push relevant
+   annotated tags when pushing branches out.
+
+ * "git merge" and "git pull" can optionally be told to inspect and
+   reject when merging a commit that does not carry a trusted GPG
+   signature.
+
+ * "git mergetool" now feeds files to the "p4merge" backend in the
+   order that matches the p4 convention, where "theirs" is usually
+   shown on the left side, which is the opposite from what other backends
+   expect.
+
+ * "show/log" now honors gpg.program configuration just like other
+   parts of the code that use GnuPG.
+
+ * "git log" that shows the difference between the parent and the
+   child has been optimized somewhat.
+
+ * "git difftool" allows the user to write into the temporary files
+   being shown; if the user makes changes to the working tree at the
+   same time, it now refrains from overwriting the copy in the working
+   tree and leaves the temporary file so that changes can be merged
+   manually.
+
+ * There was no good way to ask "I have a random string that came from
+   outside world. I want to turn it into a 40-hex object name while
+   making sure such an object exists".  A new peeling suffix ^{object}
+   can be used for that purpose, together with "rev-parse --verify".
+
+
+Performance, Internal Implementation, etc.
+
+ * Updates for building under msvc.
+
+ * A handful of issues in the code that traverses the working tree to find
+   untracked and/or ignored files have been fixed, and the general
+   codepath involved in "status -u" and "clean" have been cleaned up
+   and optimized.
+
+ * The stack footprint of some codepaths that access an object from a
+   pack has been shrunk.
+
+ * The logic to coalesce the same lines removed from the parents in
+   the output from "diff -c/--cc" has been updated, but with O(n^2)
+   complexity, so this might turn out to be undesirable.
+
+ * The code to enforce permission bits on files in $GIT_DIR/ for
+   shared repositories has been simplified.
+
+ * A few codepaths know how much data they need to put in the
+   hashtables they use when they start, but still began with small tables
+   and repeatedly grew and rehashed them.
+
+ * The API to walk reflog entries from the latest to older, which was
+   necessary for operations such as "git checkout -", was cumbersome
+   to use correctly and also inefficient.
+
+ * Codepaths that inspect log-message-to-be and decide when to add a
+   new Signed-off-by line in various commands have been consolidated.
+
+ * The pkt-line API, implementation and its callers have been cleaned
+   up to make them more robust.
+
+ * The Cygwin port has a faster-but-lying lstat(2) emulation whose
+   incorrectness does not matter in practice except for a few
+   codepaths, and setting permission bits on directories is a codepath
+   that needs to use a more correct one.
+
+ * "git checkout" had repeated pathspec matches on the same paths,
+   which have been consolidated.  Also a bug in "git checkout dir/"
+   that is started from an unmerged index has been fixed.
+
+ * A few bugfixes to "git rerere" working on corner case merge
+   conflicts have been applied.
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v1.8.2
+------------------
+
+Unless otherwise noted, all the fixes since v1.8.2 in the maintenance
+track are contained in this release (see release notes to them for
+details).
+
+ * Recent versions of File::Temp (used by "git svn") started blowing
+   up when its tempfile sub is called as a class method; updated the
+   callsite to call it as a plain vanilla function to fix it.
+   (merge eafc2dd hb/git-pm-tempfile later to maint).
+
+ * Various subcommands of "git remote" simply ignored extraneous
+   command line arguments instead of diagnosing them as errors.
+   (merge b17dd3f tr/remote-tighten-commandline-parsing later to maint).
+
+ * When receive-pack detects an error in the pack header it received in
+   order to decide which of unpack-objects or index-pack to run, it
+   returned without closing the error stream, which led to a hung
+   sideband thread.
+
+ * Zsh completion forgot that the '%' character used to signal untracked
+   files needs to be escaped with another '%'.
+
+ * A commit object whose author or committer ident are malformed
+   crashed some code that trusted that a name, an email and a
+   timestamp can always be found in it.
+
+ * When "upload-pack" fails while generating a pack in response to
+   "git fetch" (or "git clone"), the receiving side had
+   a programming error that triggered the die handler
+   recursively.
+
+ * "rev-list --stdin" and friends kept bogus pointers into the input
+   buffer around as human readable object names.  This was not a huge
+   problem but was exposed by a new change that uses these names in
+   error output.
+   (merge 70d26c6 tr/copy-revisions-from-stdin later to maint).
+
+ * Smart-capable HTTP servers were not restricted via the
+   GIT_NAMESPACE mechanism when talking with commit-walking clients,
+   like they are when talking with smart HTTP clients.
+   (merge 6130f86 jk/http-dumb-namespaces later to maint).
+
+ * "git merge-tree" did not omit a merge result that is identical to
+   the "our" side in certain cases.
+   (merge aacecc3 jk/merge-tree-added-identically later to maint).
+
+ * Perl scripts like "git-svn" closed (instead of redirecting to /dev/null)
+   the standard error stream, which is not a very smart thing to do.
+   A later open may return file descriptor #2 for an unrelated purpose, and
+   error reporting code may write into it.
+
+ * "git show-branch" was not prepared to show a very long run of
+   ancestor operators e.g. foobar^2~2^2^2^2...^2~4 correctly.
+
+ * "git diff --diff-algorithm algo" is also understood as "git diff
+   --diff-algorithm=algo".
+
+ * The new core.commentchar configuration was not applied in a few
+   places.
+
+ * "git bundle" erroneously bailed out when parsing a valid bundle
+   containing a prerequisite commit without a commit message.
+
+ * "git log -S/-G" started paying attention to textconv filter, but
+   there was no way to disable this.  Make it honor the --no-textconv
+   option.
+
+ * When used with the "-d temporary-directory" option, "git filter-branch"
+   failed to come back to the original working tree to perform the
+   final clean-up procedure.
+
+ * "git merge $(git rev-parse v1.8.2)" behaved quite differently from
+   "git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did
+   not pay much attention to the annotated tag payload.  Make the code
+   notice the type of the tag object, in addition to the dwim_ref()
+   based classification the current code uses (i.e. the name appears
+   in refs/tags/) to decide when to special-case tag merging.
+
+ * Fix a 1.8.1.x regression that stopped matching "dir" (without a
+   trailing slash) to a directory "dir".
+   (merge efa5f82 jc/directory-attrs-regression-fix later to maint-1.8.1).
+
+ * "git apply --whitespace=fix" was not prepared to see a line getting
+   longer after fixing whitespaces (e.g. tab-in-indent aka Python).
+   (merge 329b26e jc/apply-ws-fix-tab-in-indent later to maint-1.8.1).
+
+ * The prompt string generator (in contrib/completion/) did not notice
+   when we are in a middle of a "git revert" session.
+
+ * "submodule summary --summary-limit" option did not support the
+   "--option=value" form.
+
+ * "index-pack --fix-thin" used an uninitialized value to compute
+   the delta depths of objects it appends to the resulting pack.
+
+ * "index-pack --verify-stat" used a few counters outside the protection
+   of a mutex, possibly showing incorrect numbers.
+
+ * The code to keep track of what directory names are known to Git on
+   platforms with case insensitive filesystems could get confused upon a
+   hash collision between these pathnames and would loop forever.
+
+ * Annotated tags outside the refs/tags/ hierarchy were not advertised
+   correctly to ls-remote and fetch with recent versions of Git.
+
+ * Recent optimizations broke shallow clones.
+
+ * "git cmd -- ':(top'" was not diagnosed as an invalid syntax, and
+   instead the parser kept reading beyond the end of the string.
+
+ * "git tag -f <tag>" always said "Updated tag '<tag>'" even when
+   creating a new tag (i.e. neither overwriting nor updating).
+
+ * "git p4" did not behave well when the path to the root of the P4
+   client was not its real path.
+   (merge bbd8486 pw/p4-symlinked-root later to maint).
+
+ * "git archive" reported a failure when asked to create an archive out
+   of an empty tree.  It is more intuitive to give an empty
+   archive back in such a case.
+
+ * When "format-patch" quoted a non-ascii string in header files,
+   it incorrectly applied rfc2047 and chopped a single character in
+   the middle of the string.
+
+ * An aliased command spawned from a bare repository that does not say
+   it is bare with "core.bare = yes" was treated as non-bare by mistake.
+
+ * In "git reflog expire", the REACHABLE bit was not cleared from the
+   correct objects.
+
+ * The logic used by "git diff -M --stat" to shorten the names of
+   files before and after a rename did not work correctly when the
+   common prefix and suffix between the two filenames overlapped.
+
+ * The "--match=<pattern>" option of "git describe", when used with
+   "--all" to allow refs that are not annotated tags to be a
+   base of description, did not restrict the output from the command
+   to those refs that match the given pattern.
+
+ * Clarify in the documentation "what" gets pushed to "where" when the
+   command line to "git push" does not say these explicitly.
+
+ * The "--color=<when>" argument to the commands in the diff family
+   was described poorly.
+
+ * The arguments given to the pre-rebase hook were not documented.
+
+ * The v4 index format was not documented.
+
+ * The "--match=<pattern>" argument "git describe" takes uses glob
+   pattern but it wasn't obvious from the documentation.
+
+ * Some sources failed to compile on systems that lack NI_MAXHOST in
+   their system header (e.g. z/OS).
+
+ * Add an example use of "--env-filter" in "filter-branch"
+   documentation.
+
+ * "git bundle verify" did not say "records a complete history" for a
+   bundle that does not have any prerequisites.
+
+ * In the v1.8.0 era, we changed symbols that do not have to be global
+   to file scope static, but a few functions in graph.c were used by
+   CGit sideways, bypassing the entry points of the API the
+   in-tree users use.
+
+ * "git update-index -h" did not do the usual "-h(elp)" thing.
+
+ * "git index-pack" had a buffer-overflow while preparing an
+   informational message when the translated version of it was too
+   long.
+
+ * 'git commit -m "$msg"' used to add an extra newline even when
+   $msg already ended with one.
+
+ * The SSL peer verification done by "git imap-send" did not ask for
+   Server Name Indication (RFC 4366), failing to connect to SSL/TLS
+   sites that serve multiple hostnames on a single IP.
+
+ * perl/Git.pm::cat_blob slurped everything in core only to write it
+   out to a file descriptor, which was not a very smart thing to do.
+
+ * "git branch" did not bother to check nonsense command line
+   parameters.  It now issues errors in many cases.
+
+ * Verification of signed tags was not done correctly when not in C
+   or en/US locale.
+
+ * Some platforms and users spell UTF-8 differently; retry with the
+   most official "UTF-8" when the system does not understand the
+   user-supplied encoding name that is a common alternative
+   spelling of UTF-8.
+
+ * When export-subst is used, "zip" output recorded an incorrect
+   size of the file.
+
+ * "git am $maildir/" applied messages in an unexpected order; sort
+   filenames read from the maildir/ in a way that is more likely to
+   sort the messages in the order the writing MUA meant to, by sorting
+   numeric segments in numeric order and non-numeric segments in
+   alphabetical order.
+
+ * "git submodule update", when recursed into sub-submodules, did not
+   accumulate the prefix paths.
index 828ec62..87437f8 100755 (executable)
@@ -12,6 +12,7 @@ while (<STDIN>) {
                push @menu, $1;
        }
        s/\(\@pxref{\[(URLS|REMOTES)\]}\)//;
+       s/\@anchor\{[^{}]*\}//g;
        print TMP;
 }
 close TMP;
index bbba728..6e53fc5 100644 (file)
@@ -178,6 +178,10 @@ advice.*::
                the template shown when writing commit messages in
                linkgit:git-commit[1], and in the help message shown
                by linkgit:git-checkout[1] when switching branch.
+       statusUoption::
+               Advise to consider using the `-u` option to linkgit:git-status[1]
+               when the command takes more than 2 seconds to enumerate untracked
+               files.
        commitBeforeMerge::
                Advice shown when linkgit:git-merge[1] refuses to
                merge to avoid overwriting local changes.
@@ -408,7 +412,7 @@ repository's usual working tree).
 core.logAllRefUpdates::
        Enable the reflog. Updates to a ref <ref> is logged to the file
        "$GIT_DIR/logs/<ref>", by appending the new and old
-       SHA1, the date/time and the reason of the update, but
+       SHA-1, the date/time and the reason of the update, but
        only when the file exists.  If this configuration
        variable is set to true, missing "$GIT_DIR/logs/<ref>"
        file is automatically created for branch heads (i.e. under
@@ -443,7 +447,7 @@ core.sharedRepository::
 
 core.warnAmbiguousRefs::
        If true, Git will warn you if the ref name you passed it is ambiguous
-       and might match multiple refs in the .git/refs/ tree. True by default.
+       and might match multiple refs in the repository. True by default.
 
 core.compression::
        An integer -1..9, indicating a default compression level.
@@ -551,7 +555,7 @@ core.commentchar::
        (default '#').
 
 sequence.editor::
-       Text editor used by `git rebase -i` for editing the rebase insn file.
+       Text editor used by `git rebase -i` for editing the rebase instruction file.
        The value is meant to be interpreted by the shell when it is used.
        It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable.
        When not configured the default commit message editor is used instead.
@@ -723,9 +727,22 @@ branch.autosetuprebase::
        This option defaults to never.
 
 branch.<name>.remote::
-       When in branch <name>, it tells 'git fetch' and 'git push' which
-       remote to fetch from/push to.  It defaults to `origin` if no remote is
-       configured. `origin` is also used if you are not on any branch.
+       When on branch <name>, it tells 'git fetch' and 'git push'
+       which remote to fetch from/push to.  The remote to push to
+       may be overridden with `remote.pushdefault` (for all branches).
+       The remote to push to, for the current branch, may be further
+       overridden by `branch.<name>.pushremote`.  If no remote is
+       configured, or if you are not on any branch, it defaults to
+       `origin` for fetching and `remote.pushdefault` for pushing.
+
+branch.<name>.pushremote::
+       When on branch <name>, it overrides `branch.<name>.remote` for
+       pushing.  It also overrides `remote.pushdefault` for pushing
+       from branch <name>.  When you pull from one place (e.g. your
+       upstream) and push to another place (e.g. your own publishing
+       repository), you would want to set `remote.pushdefault` to
+       specify the remote to push to for all branches, and use this
+       option to override it for a specific branch.
 
 branch.<name>.merge::
        Defines, together with branch.<name>.remote, the upstream branch
@@ -790,7 +807,8 @@ color.branch::
 color.branch.<slot>::
        Use customized color for branch coloration. `<slot>` is one of
        `current` (the current branch), `local` (a local branch),
-       `remote` (a remote-tracking branch in refs/remotes/), `plain` (other
+       `remote` (a remote-tracking branch in refs/remotes/),
+       `upstream` (upstream tracking branch), `plain` (other
        refs).
 +
 The value for these configuration variables is a list of colors (at most
@@ -1086,11 +1104,16 @@ format.thread::
        value disables threading.
 
 format.signoff::
-    A boolean value which lets you enable the `-s/--signoff` option of
-    format-patch by default. *Note:* Adding the Signed-off-by: line to a
-    patch should be a conscious act and means that you certify you have
-    the rights to submit this work under the same open source license.
-    Please see the 'SubmittingPatches' document for further discussion.
+       A boolean value which lets you enable the `-s/--signoff` option of
+       format-patch by default. *Note:* Adding the Signed-off-by: line to a
+       patch should be a conscious act and means that you certify you have
+       the rights to submit this work under the same open source license.
+       Please see the 'SubmittingPatches' document for further discussion.
+
+format.coverLetter::
+       A boolean that controls whether to generate a cover-letter when
+       format-patch is invoked, but in addition can be set to "auto", to
+       generate a cover-letter only when there's more than one patch.
 
 filter.<driver>.clean::
        The command which is used to convert the content of a worktree
@@ -1202,7 +1225,7 @@ gitcvs.dbname::
 
 gitcvs.dbdriver::
        Used Perl DBI driver. You can specify any available driver
-        for this here, but it might not work. git-cvsserver is tested
+       for this here, but it might not work. git-cvsserver is tested
        with 'DBD::SQLite', reported to work with 'DBD::Pg', and
        reported *not* to work with 'DBD::mysql'. Experimental feature.
        May not contain double colons (`:`). Default: 'SQLite'.
@@ -1443,6 +1466,14 @@ http.sslCAPath::
        with when fetching or pushing over HTTPS. Can be overridden
        by the 'GIT_SSL_CAPATH' environment variable.
 
+http.sslTry::
+       Attempt to use AUTH SSL/TLS and encrypted data transfers
+       when connecting via regular FTP protocol. This might be needed
+       if the FTP server requires it for security reasons or you wish
+       to connect securely whenever remote FTP server supports it.
+       Default is false since it might trigger certificate verification
+       errors on misconfigured servers.
+
 http.maxRequests::
        How many HTTP requests to launch in parallel. Can be overridden
        by the 'GIT_HTTP_MAX_REQUESTS' environment variable. Default is 5.
@@ -1894,6 +1925,11 @@ receive.updateserverinfo::
        If set to true, git-receive-pack will run git-update-server-info
        after receiving data from git-push and updating refs.
 
+remote.pushdefault::
+       The remote to push to by default.  Overrides
+       `branch.<name>.remote` for all branches, and is overridden by
+       `branch.<name>.pushremote` for specific branches.
+
 remote.<name>.url::
        The URL of a remote repository.  See linkgit:git-fetch[1] or
        linkgit:git-push[1].
@@ -1994,6 +2030,7 @@ sendemail.<identity>.*::
 
 sendemail.aliasesfile::
 sendemail.aliasfiletype::
+sendemail.annotate::
 sendemail.bcc::
 sendemail.cc::
 sendemail.cccmd::
@@ -2119,7 +2156,13 @@ uploadpack.hiderefs::
        are under the hierarchies listed on the value of this
        variable is excluded, and is hidden from `git ls-remote`,
        `git fetch`, etc.  An attempt to fetch a hidden ref by `git
-       fetch` will fail.
+       fetch` will fail.  See also `uploadpack.allowtipsha1inwant`.
+
+uploadpack.allowtipsha1inwant::
+       When `uploadpack.hiderefs` is in effect, allow `upload-pack`
+       to accept a fetch request that asks for an object at the tip
+       of a hidden ref (by default, such a request is rejected).
+       see also `uploadpack.hiderefs`.
 
 url.<base>.insteadOf::
        Any URL that starts with this value will be rewritten to
index 869d965..104579d 100644 (file)
@@ -195,8 +195,8 @@ any of those replacements occurred.
 
 --color[=<when>]::
        Show colored diff.
-       The value must be `always` (the default for `<when>`), `never`, or `auto`.
-       The default value is `never`.
+       `--color` (i.e. without '=<when>') is the same as `--color=always`.
+       '<when>' can be one of `always`, `never`, or `auto`.
 ifdef::git-diff[]
        It can be changed by the `color.ui` and `color.diff`
        configuration settings.
index b0944e5..48754cb 100644 (file)
@@ -9,9 +9,9 @@ SYNOPSIS
 --------
 [verse]
 'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
-         [--edit | -e] [--all | [--update | -u]] [--intent-to-add | -N]
-         [--refresh] [--ignore-errors] [--ignore-missing] [--]
-         [<pathspec>...]
+         [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]]
+         [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing]
+         [--] [<pathspec>...]
 
 DESCRIPTION
 -----------
@@ -111,6 +111,7 @@ of Git, hence the form without <pathspec> should not be used.
 
 -A::
 --all::
+--no-ignore-removal::
        Update the index not only where the working tree has a file
        matching <pathspec> but also where the index already has an
        entry.  This adds, modifies, and removes index entries to
@@ -121,6 +122,19 @@ If no <pathspec> is given, the current version of Git defaults to
 and its subdirectories. This default will change in a future version
 of Git, hence the form without <pathspec> should not be used.
 
+--no-all::
+--ignore-removal::
+       Update the index by adding new files that are unknown to the
+       index and files modified in the working tree, but ignore
+       files that have been removed from the working tree.  This
+       option is a no-op when no <pathspec> is used.
++
+This option is primarily to help the current users of Git, whose
+"git add <pathspec>..." ignores removed files.  In future versions
+of Git, "git add <pathspec>..." will be a synonym to "git add -A
+<pathspec>..." and "git add --ignore-removal <pathspec>..." will behave like
+today's "git add <pathspec>...", ignoring removed files.
+
 -N::
 --intent-to-add::
        Record only the fact that the path will be added later. An entry
index b4c2e24..250e522 100644 (file)
@@ -56,7 +56,8 @@ OPTIONS
        Write the archive to <file> instead of stdout.
 
 --worktree-attributes::
-       Look for attributes in .gitattributes in working directory too.
+       Look for attributes in .gitattributes files in the working tree
+       as well (see <<ATTRIBUTES>>).
 
 <extra>::
        This can be any options that the archiver backend understands.
@@ -120,6 +121,7 @@ tar.<format>.remote::
        user-defined formats, but true for the "tar.gz" and "tgz"
        formats.
 
+[[ATTRIBUTES]]
 ATTRIBUTES
 ----------
 
index 2fb95bb..30d585a 100644 (file)
@@ -20,7 +20,7 @@ object type, or '-s' is used to find the object size, or '--textconv' is used
 (which implies type "blob").
 
 In the second form, a list of objects (separated by linefeeds) is provided on
-stdin, and the SHA1, type, and size of each object is printed on stdout.
+stdin, and the SHA-1, type, and size of each object is printed on stdout.
 
 OPTIONS
 -------
@@ -58,11 +58,11 @@ OPTIONS
        to apply the filter to the content recorded in the index at <path>.
 
 --batch::
-       Print the SHA1, type, size, and contents of each object provided on
+       Print the SHA-1, type, size, and contents of each object provided on
        stdin. May not be combined with any other options or arguments.
 
 --batch-check::
-       Print the SHA1, type, and size of each object provided on stdin. May not
+       Print the SHA-1, type, and size of each object provided on stdin. May not
        be combined with any other options or arguments.
 
 OUTPUT
index 8edcdca..23a9413 100644 (file)
@@ -180,6 +180,12 @@ branch by running "git rm -rf ." from the top level of the working tree.
 Afterwards you will be ready to prepare your new files, repopulating the
 working tree, by copying them from elsewhere, extracting a tarball, etc.
 
+--ignore-skip-worktree-bits::
+       In sparse checkout mode, `git checkout -- <paths>` would
+       update only entries matched by <paths> and sparse patterns
+       in $GIT_DIR/info/sparse-checkout. This option ignores
+       the sparse patterns and adds back any files in <paths>.
+
 -m::
 --merge::
        When switching branches,
index 86ef56e..cafdc96 100644 (file)
@@ -10,7 +10,9 @@ SYNOPSIS
 --------
 [verse]
 'git commit-tree' <tree> [(-p <parent>)...] < changelog
-'git commit-tree' [(-p <parent>)...] [(-m <message>)...] [(-F <file>)...] <tree>
+'git commit-tree' [(-p <parent>)...] [-S[<keyid>]] [(-m <message>)...]
+                 [(-F <file>)...] <tree>
+
 
 DESCRIPTION
 -----------
@@ -52,6 +54,9 @@ OPTIONS
        Read the commit log message from the given file. Use `-` to read
        from the standard input.
 
+-S[<keyid>]::
+       GPG-sign commit.
+
 
 Commit Information
 ------------------
index 0eb79cc..8172938 100644 (file)
@@ -137,6 +137,8 @@ OPTIONS
 -m <msg>::
 --message=<msg>::
        Use the given <msg> as the commit message.
+       If multiple `-m` options are given, their values are
+       concatenated as separate paragraphs.
 
 -t <file>::
 --template=<file>::
@@ -172,22 +174,31 @@ OPTIONS
        linkgit:git-commit-tree[1].
 
 --cleanup=<mode>::
-       This option sets how the commit message is cleaned up.
-       The  '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
-       and 'default'. The 'default' mode will strip leading and
-       trailing empty lines and #commentary from the commit message
-       only if the message is to be edited. Otherwise only whitespace
-       removed. The 'verbatim' mode does not change message at all,
-       'whitespace' removes just leading/trailing whitespace lines
-       and 'strip' removes both whitespace and commentary. The default
-       can be changed by the 'commit.cleanup' configuration variable
-       (see linkgit:git-config[1]).
+       This option determines how the supplied commit message should be
+       cleaned up before committing.  The '<mode>' can be `strip`,
+       `whitespace`, `verbatim`, or `default`.
++
+--
+strip::
+       Strip leading and trailing empty lines, trailing whitespace, and
+       #commentary and collapse consecutive empty lines.
+whitespace::
+       Same as `strip` except #commentary is not removed.
+verbatim::
+       Do not change the message at all.
+default::
+       Same as `strip` if the message is to be edited.
+       Otherwise `whitespace`.
+--
++
+The default can be changed by the 'commit.cleanup' configuration
+variable (see linkgit:git-config[1]).
 
 -e::
 --edit::
        The message taken from file with `-F`, command line with
-       `-m`, and from file with `-C` are usually used as the
-       commit log message unmodified.  This option lets you
+       `-m`, and from commit object with `-C` are usually used as
+       the commit log message unmodified. This option lets you
        further edit the message taken from these sources.
 
 --no-edit::
@@ -196,14 +207,15 @@ OPTIONS
        without changing its commit message.
 
 --amend::
-       Used to amend the tip of the current branch. Prepare the tree
-       object you would want to replace the latest commit as usual
-       (this includes the usual -i/-o and explicit paths), and the
-       commit log editor is seeded with the commit message from the
-       tip of the current branch. The commit you create replaces the
-       current tip -- if it was a merge, it will have the parents of
-       the current tip as parents -- so the current top commit is
-       discarded.
+       Replace the tip of the current branch by creating a new
+       commit. The recorded tree is prepared as usual (including
+       the effect of the `-i` and `-o` options and explicit
+       pathspec), and the message from the original commit is used
+       as the starting point, instead of an empty message, when no
+       other message is specified from the command line via options
+       such as `-m`, `-F`, `-c`, etc.  The new commit has the same
+       parents and author as the current one (the `--reset-author`
+       option can countermand this).
 +
 --
 It is a rough equivalent for:
index 23c80ce..b300e84 100644 (file)
@@ -8,7 +8,7 @@ git-count-objects - Count unpacked number of objects and their disk consumption
 SYNOPSIS
 --------
 [verse]
-'git count-objects' [-v]
+'git count-objects' [-v] [-H | --human-readable]
 
 DESCRIPTION
 -----------
@@ -20,11 +20,29 @@ OPTIONS
 -------
 -v::
 --verbose::
-       In addition to the number of loose objects and disk
-       space consumed, it reports the number of in-pack
-       objects, number of packs, disk space consumed by those packs,
-       and number of objects that can be removed by running
-       `git prune-packed`.
+       Report in more detail:
++
+count: the number of loose objects
++
+size: disk space consumed by loose objects, in KiB (unless -H is specified)
++
+in-pack: the number of in-pack objects
++
+size-pack: disk space consumed by the packs, in KiB (unless -H is specified)
++
+prune-packable: the number of loose objects that are also present in
+the packs. These objects could be pruned using `git prune-packed`.
++
+garbage: the number of files in object database that are not valid
+loose objects nor valid packs
++
+size-garbage: disk space consumed by garbage files, in KiB (unless -H is
+specified)
+
+-H::
+--human-readable::
+
+Print sizes in human readable format
 
 GIT
 ---
index 472f00f..7da0f13 100644 (file)
@@ -56,7 +56,7 @@ For example, if we want a password for
 `https://example.com/foo.git`, we might generate the following
 credential description (don't forget the blank line at the end; it
 tells `git credential` that the application finished feeding all the
-infomation it has):
+information it has):
 
         protocol=https
         host=example.com
index 77da564..bfb106c 100644 (file)
@@ -147,6 +147,13 @@ OPTIONS
 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.
++
+Like many programs that switch user id, the daemon does not reset
+environment variables such as `$HOME` when it runs git programs,
+e.g. `upload-pack` and `receive-pack`. When using this option, you
+may also want to set and export `HOME` to point at the home
+directory of `<user>` before starting the daemon, and make sure any
+Git configuration files in that directory are readable by `<user>`.
 
 --enable=<service>::
 --disable=<service>::
index 32da244..28e5ec0 100644 (file)
@@ -81,8 +81,9 @@ OPTIONS
        that points at object deadbee....).
 
 --match <pattern>::
-       Only consider tags matching the given pattern (can be used to avoid
-       leaking private tags made from the repository).
+       Only consider tags matching the given `glob(7)` pattern,
+       excluding the "refs/tags/" prefix.  This can be used to avoid
+       leaking private tags from the repository.
 
 --always::
        Show uniquely abbreviated commit object as fallback.
@@ -148,7 +149,7 @@ 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.
+abbreviation of the input committish's SHA-1.
 
 If multiple tags were found during the walk then the tag which
 has the fewest commits different from the input committish will be
index e0e12e9..8361e6e 100644 (file)
@@ -72,10 +72,12 @@ with custom merge tool commands and has the same value as `$MERGED`.
 --symlinks::
 --no-symlinks::
        'git difftool''s default behavior is create symlinks to the
-       working tree when run in `--dir-diff` mode.
+       working tree when run in `--dir-diff` mode and the right-hand
+       side of the comparison yields the same content as the file in
+       the working tree.
 +
-       Specifying `--no-symlinks` instructs 'git difftool' to create
-       copies instead.  `--no-symlinks` is the default on Windows.
+Specifying `--no-symlinks` instructs 'git difftool' to create copies
+instead.  `--no-symlinks` is the default on Windows.
 
 -x <command>::
 --extcmd=<command>::
index d6487e1..03fc8c3 100644 (file)
@@ -27,15 +27,17 @@ OPTIONS
        Insert 'progress' statements every <n> objects, to be shown by
        'git fast-import' during import.
 
---signed-tags=(verbatim|warn|strip|abort)::
+--signed-tags=(verbatim|warn|warn-strip|strip|abort)::
        Specify how to handle signed tags.  Since any transformation
        after the export can change the tag names (which can also happen
        when excluding revisions) the signatures will not match.
 +
 When asking to 'abort' (which is the default), this program will die
-when encountering a signed tag.  With 'strip', the tags will be made
-unsigned, with 'verbatim', they will be silently exported
-and with 'warn', they will be exported, but you will see a warning.
+when encountering a signed tag.  With 'strip', the tags will silently
+be made unsigned, with 'warn-strip' they will be made unsigned but a
+warning will be displayed, with 'verbatim', they will be silently
+exported and with 'warn', they will be exported, but you will see a
+warning.
 
 --tag-of-filtered-object=(abort|drop|rewrite)::
        Specify how to handle tags whose tagged object is filtered out.
@@ -66,6 +68,8 @@ produced incorrect results if you gave these options.
        incremental runs.  As <file> is only opened and truncated
        at completion, the same path can also be safely given to
        \--import-marks.
+       The file will not be written if no new object has been
+       marked/exported.
 
 --import-marks=<file>::
        Before processing any input, load the marks specified in
index dfd12c9..e4c8e82 100644 (file)
@@ -64,8 +64,11 @@ argument is always evaluated in the shell context using the 'eval' command
 Prior to that, the $GIT_COMMIT environment variable will be set to contain
 the id of the commit being rewritten.  Also, GIT_AUTHOR_NAME,
 GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL,
-and GIT_COMMITTER_DATE are set according to the current commit.  The values
-of these variables after the filters have run, are used for the new commit.
+and GIT_COMMITTER_DATE are taken from the current commit and exported to
+the environment, in order to affect the author and committer identities of
+the replacement commit created by linkgit:git-commit-tree[1] after the
+filters have run.
+
 If any evaluation of <command> returns a non-zero exit status, the whole
 operation will be aborted.
 
@@ -329,6 +332,26 @@ git filter-branch --msg-filter '
 ' HEAD~10..HEAD
 --------------------------------------------------------
 
+The `--env-filter` option can be used to modify committer and/or author
+identity.  For example, if you found out that your commits have the wrong
+identity due to a misconfigured user.email, you can make a correction,
+before publishing the project, like this:
+
+--------------------------------------------------------
+git filter-branch --env-filter '
+       if test "$GIT_AUTHOR_EMAIL" = "root@localhost"
+       then
+               GIT_AUTHOR_EMAIL=john@example.com
+               export GIT_AUTHOR_EMAIL
+       fi
+       if test "$GIT_COMMITTER_EMAIL" = "root@localhost"
+       then
+               GIT_COMMITTER_EMAIL=john@example.com
+               export GIT_COMMITTER_EMAIL
+       fi
+' -- --all
+--------------------------------------------------------
+
 To restrict rewriting to only part of the history, specify a revision
 range in addition to the new branch name.  The new branch name will
 point to the top-most revision that a 'git rev-list' of this range
index 3a62f50..3911877 100644 (file)
@@ -20,7 +20,7 @@ SYNOPSIS
                   [--ignore-if-in-upstream]
                   [--subject-prefix=Subject-Prefix] [(--reroll-count|-v) <n>]
                   [--to=<email>] [--cc=<email>]
-                  [--cover-letter] [--quiet] [--notes[=<ref>]]
+                  [--[no-]cover-letter] [--quiet] [--notes[=<ref>]]
                   [<common diff options>]
                   [ <since> | <revision range> ]
 
@@ -195,7 +195,7 @@ will want to ensure that threading is disabled for `git send-email`.
        `Cc:`, and custom) headers added so far from config or command
        line.
 
---cover-letter::
+--[no-]cover-letter::
        In addition to the patches, generate a cover letter file
        containing the shortlog and the overall diffstat.  You can
        fill in a description in the file before sending it out.
@@ -260,6 +260,7 @@ attachments, and sign off patches with configuration variables.
        cc = <email>
        attach [ = mime-boundary-string ]
        signoff = true
+       coverletter = auto
 ------------
 
 
index eff9188..e5878bd 100644 (file)
@@ -23,7 +23,7 @@ OPTIONS
        An object to treat as the head of an unreachability trace.
 +
 If no objects are given, 'git fsck' defaults to using the
-index file, all SHA1 references in `refs` namespace, and all reflogs
+index file, all SHA-1 references in `refs` namespace, and all reflogs
 (unless --no-reflogs is given) as heads.
 
 --unreachable::
@@ -89,7 +89,7 @@ index file, all SHA1 references in `refs` namespace, and all reflogs
 DISCUSSION
 ----------
 
-git-fsck tests SHA1 and general object sanity, and it does full tracking
+git-fsck tests SHA-1 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
index e07b6dc..b21e9d7 100644 (file)
@@ -8,31 +8,45 @@ git-help - Display help information about Git
 SYNOPSIS
 --------
 [verse]
-'git help' [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND]
+'git help' [-a|--all] [-g|--guide]
+          [-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE]
 
 DESCRIPTION
 -----------
 
-With no options and no COMMAND given, the synopsis of the 'git'
+With no options and no COMMAND or GUIDE given, the synopsis of the 'git'
 command and a list of the most commonly used Git commands are printed
 on the standard output.
 
-If the option '--all' or '-a' is given, then all available commands are
+If the option '--all' or '-a' is given, all available commands are
 printed on the standard output.
 
-If a Git subcommand is named, a manual page for that subcommand is brought
-up. The 'man' program is used by default for this purpose, but this
-can be overridden by other options or configuration variables.
+If the option '--guide' or '-g' is given, a list of the useful
+Git guides is also printed on the standard output.
+
+If a command, or a guide, is given, a manual page for that command or
+guide is brought up. The 'man' program is used by default for this
+purpose, but this can be overridden by other options or configuration
+variables.
 
 Note that `git --help ...` is identical to `git help ...` because the
 former is internally converted into the latter.
 
+To display the linkgit:git[1] man page, use `git help git`.
+
+This page can be displayed with 'git help help' or `git help --help`
+
 OPTIONS
 -------
 -a::
 --all::
        Prints all the available commands on the standard output. This
-       option supersedes any other option.
+       option overrides any given command or guide name.
+
+-g::
+--guides::
+       Prints a list of useful guides on the standard output. This
+       option overrides any given command or guide name.
 
 -i::
 --info::
index 7b1e85c..e3bcdb5 100644 (file)
@@ -80,7 +80,30 @@ ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
 ----------------------------------------------------------------
 +
 To enable anonymous read access but authenticated write access,
-require authorization with a LocationMatch directive:
+require authorization for both the initial ref advertisement (which we
+detect as a push via the service parameter in the query string), and the
+receive-pack invocation itself:
++
+----------------------------------------------------------------
+RewriteCond %{QUERY_STRING} service=git-receive-pack [OR]
+RewriteCond %{REQUEST_URI} /git-receive-pack$
+RewriteRule ^/git/ - [E=AUTHREQUIRED:yes]
+
+<LocationMatch "^/git/">
+       Order Deny,Allow
+       Deny from env=AUTHREQUIRED
+
+       AuthType Basic
+       AuthName "Git Access"
+       Require group committers
+       Satisfy Any
+       ...
+</LocationMatch>
+----------------------------------------------------------------
++
+If you do not have `mod_rewrite` available to match against the query
+string, it is sufficient to just protect `git-receive-pack` itself,
+like:
 +
 ----------------------------------------------------------------
 <LocationMatch "^/git/.*/git-receive-pack$">
@@ -91,6 +114,15 @@ require authorization with a LocationMatch directive:
 </LocationMatch>
 ----------------------------------------------------------------
 +
+In this mode, the server will not request authentication until the
+client actually starts the object negotiation phase of the push, rather
+than during the initial contact.  For this reason, you must also enable
+the `http.receivepack` config option in any repositories that should
+accept a push. The default behavior, if `http.receivepack` is not set,
+is to reject any pushes by unauthenticated users; the initial request
+will therefore report `403 Forbidden` to the client, without even giving
+an opportunity for authentication.
++
 To require authentication for both reads and writes, use a Location
 directive around the repository, or one of its parent directories:
 +
@@ -158,6 +190,54 @@ ScriptAliasMatch \
 ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
 ----------------------------------------------------------------
 
+Lighttpd::
+       Ensure that `mod_cgi`, `mod_alias, `mod_auth`, `mod_setenv` are
+       loaded, then set `GIT_PROJECT_ROOT` appropriately and redirect
+       all requests to the CGI:
++
+----------------------------------------------------------------
+alias.url += ( "/git" => "/usr/lib/git-core/git-http-backend" )
+$HTTP["url"] =~ "^/git" {
+       cgi.assign = ("" => "")
+       setenv.add-environment = (
+               "GIT_PROJECT_ROOT" => "/var/www/git",
+               "GIT_HTTP_EXPORT_ALL" => ""
+       )
+}
+----------------------------------------------------------------
++
+To enable anonymous read access but authenticated write access:
++
+----------------------------------------------------------------
+$HTTP["querystring"] =~ "service=git-receive-pack" {
+       include "git-auth.conf"
+}
+$HTTP["url"] =~ "^/git/.*/git-receive-pack$" {
+       include "git-auth.conf"
+}
+----------------------------------------------------------------
++
+where `git-auth.conf` looks something like:
++
+----------------------------------------------------------------
+auth.require = (
+       "/" => (
+               "method" => "basic",
+               "realm" => "Git Access",
+               "require" => "valid-user"
+              )
+)
+# ...and set up auth.backend here
+----------------------------------------------------------------
++
+To require authentication for both reads and writes:
++
+----------------------------------------------------------------
+$HTTP["url"] =~ "^/git/private" {
+       include "git-auth.conf"
+}
+----------------------------------------------------------------
+
 
 ENVIRONMENT
 -----------
index 36adc5f..bde8eec 100644 (file)
@@ -89,7 +89,7 @@ Note
 ----
 
 Once the index has been created, the list of object names is sorted
-and the SHA1 hash of that list is printed to stdout. If --stdin was
+and the SHA-1 hash of that list is printed to stdout. If --stdin was
 also used then this is prefixed by either "pack\t", or "keep\t" if a
 new .keep file was successfully created. This is useful to remove a
 .keep file used as a lock to prevent the race with 'git repack'
index 69db578..a976534 100644 (file)
@@ -9,7 +9,7 @@ git-log - Show commit logs
 SYNOPSIS
 --------
 [verse]
-'git log' [<options>] [<since>..<until>] [[\--] <path>...]
+'git log' [<options>] [<revision range>] [[\--] <path>...]
 
 DESCRIPTION
 -----------
@@ -24,13 +24,6 @@ each commit introduces are shown.
 OPTIONS
 -------
 
-<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 linkgit:gitrevisions[7].
-
 --follow::
        Continue listing the history of a file beyond renames
        (works only for a single file).
@@ -69,14 +62,23 @@ produced by --stat etc.
        Note that only message is considered, if also a diff is shown
        its size is not included.
 
+<revision range>::
+       Show only commits in the specified revision range.  When no
+       <revision range> is specified, it defaults to `HEAD` (i.e. the
+       whole history leading to the current commit).  `origin..HEAD`
+       specifies all the commits reachable from the current commit
+       (i.e. `HEAD`), but not from `origin`. For a complete list of
+       ways to spell <revision range>, see the "Specifying Ranges"
+       section of linkgit:gitrevisions[7].
+
 [\--] <path>...::
        Show only commits that are enough to explain how the files
        that match the specified paths came to be.  See "History
        Simplification" below for details and other simplification
        modes.
 +
-To prevent confusion with options and branch names, paths may need to
-be prefixed with "\-- " to separate them from options or refnames.
+Paths may need to be prefixed with "\-- " to separate them from
+options or the revision range, when confusion arises.
 
 include::rev-list-options.txt[]
 
index 0bdebff..c0856a6 100644 (file)
@@ -164,7 +164,7 @@ which case it outputs:
 'git ls-files --unmerged' and 'git ls-files --stage' can be used to examine
 detailed information on unmerged paths.
 
-For an unmerged path, instead of recording a single mode/SHA1 pair,
+For an unmerged path, instead of recording a single mode/SHA-1 pair,
 the index records up to three such pairs; one from tree O in stage
 1, A in stage 2, and B in stage 3.  This information can be used by
 the user (or the porcelain) to see what should eventually be recorded at the
index 0c80cec..02676fb 100644 (file)
@@ -14,7 +14,7 @@ SYNOPSIS
 DESCRIPTION
 -----------
 This looks up the <file>(s) in the index and, if there are any merge
-entries, passes the SHA1 hash for those files as arguments 1, 2, 3 (empty
+entries, passes the SHA-1 hash for those files as arguments 1, 2, 3 (empty
 argument if no file), and <file> as argument 4.  File modes for the three
 files are passed as arguments 5, 6 and 7.
 
index c852a26..42391f2 100644 (file)
@@ -170,6 +170,30 @@ happens:
 If you tried a merge which resulted in complex conflicts and
 want to start over, you can recover with `git merge --abort`.
 
+MERGING TAG
+-----------
+
+When merging an annotated (and possibly signed) tag, Git always
+creates a merge commit even if a fast-forward merge is possible, and
+the commit message template is prepared with the tag message.
+Additionally, if the tag is signed, the signature check is reported
+as a comment in the message template. See also linkgit:git-tag[1].
+
+When you want to just integrate with the work leading to the commit
+that happens to be tagged, e.g. synchronizing with an upstream
+release point, you may not want to make an unnecessary merge commit.
+
+In such a case, you can "unwrap" the tag yourself before feeding it
+to `git merge`, or pass `--ff-only` when you do not have any work on
+your own. e.g.
+
+---
+git fetch origin
+git merge v1.2.3^0
+git merge --ff-only v1.2.3
+---
+
+
 HOW CONFLICTS ARE PRESENTED
 ---------------------------
 
index 69c9313..d94edcd 100644 (file)
@@ -50,7 +50,7 @@ base-name::
        Write into a pair of files (.pack and .idx), using
        <base-name> to determine the name of the created file.
        When this option is used, the two files are written in
-       <base-name>-<SHA1>.{pack,idx} files.  <SHA1> is a hash
+       <base-name>-<SHA-1>.{pack,idx} files.  <SHA-1> is a hash
        of the sorted object names to make the resulting filename
        based on the pack content, and written to the standard
        output of the command.
index 90268f0..312c3b1 100644 (file)
@@ -12,7 +12,7 @@ SYNOPSIS
 
 DESCRIPTION
 -----------
-A "patch ID" is nothing but a SHA1 of the diff associated with a patch, with
+A "patch ID" is nothing but a SHA-1 of the diff associated with a patch, with
 whitespace and line numbers ignored.  As such, it's "reasonably stable", but at
 the same time also reasonably unique, i.e., two patches that have the same "patch
 ID" are almost guaranteed to be the same thing.
index c975743..24ab07a 100644 (file)
@@ -218,7 +218,7 @@ $ git merge origin/next
 ------------------------------------------------
 
 
-If you tried a pull which resulted in complex conflicts and
+If you tried a pull which resulted in complex conflicts and
 would want to start over, you can recover with 'git reset'.
 
 
index 1398025..eb2883c 100644 (file)
@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects
 SYNOPSIS
 --------
 [verse]
-'git push' [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
+'git push' [--all | --mirror | --tags] [--follow-tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
           [--repo=<repository>] [-f | --force] [--prune] [-v | --verbose] [-u | --set-upstream]
           [<repository> [<refspec>...]]
 
@@ -23,6 +23,17 @@ You can make interesting things happen to a repository
 every time you push into it, by setting up 'hooks' there.  See
 documentation for linkgit:git-receive-pack[1].
 
+When the command line does not specify where to push with the
+`<repository>` argument, `branch.*.remote` configuration for the
+current branch is consulted to determine where to push.  If the
+configuration is missing, it defaults to 'origin'.
+
+When the command line does not specify what to push with `<refspec>...`
+arguments or `--all`, `--mirror`, `--tags` options, the command finds
+the default `<refspec>` by consulting `remote.*.push` configuration,
+and if it is not found, honors `push.default` configuration to decide
+what to push (See gitlink:git-config[1] for the meaning of `push.default`).
+
 
 OPTIONS[[OPTIONS]]
 ------------------
@@ -33,13 +44,10 @@ OPTIONS[[OPTIONS]]
        of a remote (see the section <<REMOTES,REMOTES>> below).
 
 <refspec>...::
+       Specify what destination ref to update with what source object.
        The format of a <refspec> parameter is an optional plus
-       `+`, followed by the source ref <src>, followed
+       `+`, followed by the source object <src>, followed
        by a colon `:`, followed by the destination ref <dst>.
-       It is used to specify with what <src> object the <dst> ref
-       in the remote repository is to be updated.  If not specified,
-       the behavior of the command is controlled by the `push.default`
-       configuration variable.
 +
 The <src> is often the name of the branch you would want to push, but
 it can be any arbitrary "SHA-1 expression", such as `master~4` or
@@ -66,10 +74,7 @@ the remote repository.
 The special refspec `:` (or `+:` to allow non-fast-forward updates)
 directs Git to push "matching" branches: for every branch that exists on
 the local side, the remote side is updated if a branch of the same name
-already exists on the remote side.  This is the default operation mode
-if no explicit refspec is found (that is neither on the command line
-nor in any Push line of the corresponding remotes file---see below) and
-no `push.default` configuration variable is set.
+already exists on the remote side.
 
 --all::
        Instead of naming each ref to push, specifies that all
@@ -112,6 +117,12 @@ no `push.default` configuration variable is set.
        addition to refspecs explicitly listed on the command
        line.
 
+--follow-tags::
+       Push all the refs that would be pushed without this option,
+       and also push annotated tags in `refs/tags` that are missing
+       from the remote but are pointing at committish that are
+       reachable from the refs being pushed.
+
 --receive-pack=<git-receive-pack>::
 --exec=<git-receive-pack>::
        Path to the 'git-receive-pack' program on the remote
index 58b7fac..8cfc748 100644 (file)
@@ -86,7 +86,7 @@ begins with `ext::`.  Examples:
        edit .ssh/config.
 
 "ext::socat -t3600 - ABSTRACT-CONNECT:/git-server %G/somerepo"::
-       Represents repository with path /somerepo accessable over
+       Represents repository with path /somerepo accessible over
        git protocol at abstract namespace address /git-server.
 
 "ext::git-server-alias foo %G/repo"::
index e8c396b..7a6f354 100644 (file)
@@ -18,8 +18,8 @@ SYNOPSIS
 'git remote set-url' [--push] <name> <newurl> [<oldurl>]
 'git remote set-url --add' [--push] <name> <newurl>
 'git remote set-url --delete' [--push] <name> <url>
-'git remote' [-v | --verbose] 'show' [-n] <name>
-'git remote prune' [-n | --dry-run] <name>
+'git remote' [-v | --verbose] 'show' [-n] <name>...
+'git remote prune' [-n | --dry-run] <name>...
 'git remote' [-v | --verbose] 'update' [-p | --prune] [(<group> | <remote>)...]
 
 DESCRIPTION
index 0142cd1..e0b4057 100644 (file)
@@ -16,8 +16,8 @@ DESCRIPTION
 -----------
 Adds a 'replace' reference in `refs/replace/` namespace.
 
-The name of the 'replace' reference is the SHA1 of the object that is
-replaced. The content of the 'replace' reference is the SHA1 of the
+The name of the 'replace' reference is the SHA-1 of the object that is
+replaced. The content of the 'replace' reference is the SHA-1 of the
 replacement object.
 
 Unless `-f` is given, the 'replace' reference must not yet exist.
index 10a116f..947d62f 100644 (file)
@@ -60,8 +60,19 @@ OPTIONS
        instead.
 
 --verify::
-       The parameter given must be usable as a single, valid
-       object name.  Otherwise barf and abort.
+       Verify that exactly one parameter is provided, and that it
+       can be turned into a raw 20-byte SHA-1 that can be used to
+       access the object database. If so, emit it to the standard
+       output; otherwise, error out.
++
+If you want to make sure that the output actually names an object in
+your object database and/or can be used as a specific type of object
+you require, you can add "^{type}" peeling operator to the parmeter.
+For example, `git rev-parse "$VAR^{commit}"` will make sure `$VAR`
+names an existing object that is a commit-ish (i.e. a commit, or an
+annotated tag that points at a commit).  To make sure that `$VAR`
+names an existing object of any type, `git rev-parse "$VAR^{object}"`
+can be used.
 
 -q::
 --quiet::
@@ -84,7 +95,7 @@ OPTIONS
        one.
 
 --symbolic::
-       Usually the object names are output in SHA1 form (with
+       Usually the object names are output in SHA-1 form (with
        possible '{caret}' prefix); this option makes them output in a
        form as close to the original input as possible.
 
@@ -169,7 +180,7 @@ print a message to stderr and exit with nonzero status.
 
 --short::
 --short=number::
-       Instead of outputting the full SHA1 values of object names try to
+       Instead of outputting the full SHA-1 values of object names try to
        abbreviate them to a shorter unique name. When no length is specified
        7 is used. The minimum length is 4.
 
@@ -308,12 +319,12 @@ $ git rev-parse --verify HEAD
 * Print the commit object name from the revision in the $REV shell variable:
 +
 ------------
-$ git rev-parse --verify $REV
+$ git rev-parse --verify $REV^{commit}
 ------------
 +
 This will error out if $REV is empty or not a valid revision.
 
-* Same as above:
+* Similar to above:
 +
 ------------
 $ git rev-parse --default master --verify $REV
index 92bac27..1d876c2 100644 (file)
@@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules work tree.
 Ignored files are deemed expendable and won't stop a submodule's work
 tree from being removed.
 
+If you only want to remove the local checkout of a submodule from your
+work tree without committing the removal,
+use linkgit:git-submodule[1] `deinit` instead.
+
 EXAMPLES
 --------
 `git rm Documentation/\*.txt`::
index 44a1f7c..40a9a9a 100644 (file)
@@ -45,8 +45,9 @@ Composing
 ~~~~~~~~~
 
 --annotate::
-       Review and edit each patch you're about to send. See the
-       CONFIGURATION section for 'sendemail.multiedit'.
+       Review and edit each patch you're about to send. Default is the value
+       of 'sendemail.annotate'. See the CONFIGURATION section for
+       'sendemail.multiedit'.
 
 --bcc=<address>::
        Specify a "Bcc:" value for each email. Default is the value of
@@ -164,8 +165,8 @@ Sending
 Furthermore, passwords need not be specified in configuration files
 or on the command line. If a username has been specified (with
 '--smtp-user' or a 'sendemail.smtpuser'), but no password has been
-specified (with '--smtp-pass' or 'sendemail.smtppass'), then the
-user is prompted for a password while the input is masked for privacy.
+specified (with '--smtp-pass' or 'sendemail.smtppass'), then
+a password is obtained using 'git-credential'.
 
 --smtp-server=<host>::
        If set, specifies the outgoing SMTP server to use (e.g.
index 6a9f66d..5d709d0 100644 (file)
@@ -82,6 +82,12 @@ get_author_ident_from_commit::
        outputs code for use with eval to set the GIT_AUTHOR_NAME,
        GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE variables for a given commit.
 
+create_virtual_base::
+       modifies the first file so only lines in common with the
+       second file remain. If there is insufficient common material,
+       then the first file is left empty. The result is suitable
+       as a virtual base input for a 3-way merge.
+
 GIT
 ---
 Part of the linkgit:git[1] suite
index 9b92506..c35051b 100644 (file)
@@ -9,25 +9,81 @@ git-shell - Restricted login shell for Git-only SSH access
 SYNOPSIS
 --------
 [verse]
-'git shell' [-c <command> <argument>]
+'chsh' -s $(command -v git-shell) <user>
+'git clone' <user>`@localhost:/path/to/repo.git`
+'ssh' <user>`@localhost`
 
 DESCRIPTION
 -----------
 
-A login shell for SSH accounts to provide restricted Git access. When
-'-c' is given, the program executes <command> non-interactively;
-<command> can be one of 'git receive-pack', 'git upload-pack', 'git
-upload-archive', 'cvs server', or a command in COMMAND_DIR. The shell
-is started in interactive mode when no arguments are given; in this
-case, COMMAND_DIR must exist, and any of the executables in it can be
-invoked.
+This is a login shell for SSH accounts to provide restricted Git access.
+It permits execution only of server-side Git commands implementing the
+pull/push functionality, plus custom commands present in a subdirectory
+named `git-shell-commands` in the user's home directory.
 
-'cvs server' is a special command which executes git-cvsserver.
+COMMANDS
+--------
+
+'git shell' accepts the following commands after the '-c' option:
+
+'git receive-pack <argument>'::
+'git upload-pack <argument>'::
+'git upload-archive <argument>'::
+       Call the corresponding server-side command to support
+       the client's 'git push', 'git fetch', or 'git archive --remote'
+       request.
+'cvs server'::
+       Imitate a CVS server.  See linkgit:git-cvsserver[1].
+
+If a `~/git-shell-commands` directory is present, 'git shell' will
+also handle other, custom commands by running
+"`git-shell-commands/<command> <arguments>`" from the user's home
+directory.
+
+INTERACTIVE USE
+---------------
+
+By default, the commands above can be executed only with the '-c'
+option; the shell is not interactive.
 
-COMMAND_DIR is the path "$HOME/git-shell-commands". The user must have
-read and execute permissions to the directory in order to execute the
-programs in it. The programs are executed with a cwd of $HOME, and
-<argument> is parsed as a command-line string.
+If a `~/git-shell-commands` directory is present, 'git shell'
+can also be run interactively (with no arguments).  If a `help`
+command is present in the `git-shell-commands` directory, it is
+run to provide the user with an overview of allowed actions.  Then a
+"git> " prompt is presented at which one can enter any of the
+commands from the `git-shell-commands` directory, or `exit` to close
+the connection.
+
+Generally this mode is used as an administrative interface to allow
+users to list repositories they have access to, create, delete, or
+rename repositories, or change repository descriptions and
+permissions.
+
+If a `no-interactive-login` command exists, then it is run and the
+interactive shell is aborted.
+
+EXAMPLE
+-------
+
+To disable interactive logins, displaying a greeting instead:
++
+----------------
+$ chsh -s /usr/bin/git-shell
+$ mkdir $HOME/git-shell-commands
+$ cat >$HOME/git-shell-commands/no-interactive-login <<\EOF
+#!/bin/sh
+printf '%s\n' "Hi $USER! You've successfully authenticated, but I do not"
+printf '%s\n' "provide interactive shell access."
+exit 128
+EOF
+$ chmod +x $HOME/git-shell-commands/no-interactive-login
+----------------
+
+SEE ALSO
+--------
+ssh(1),
+linkgit:git-daemon[1],
+contrib/git-shell-commands/README
 
 GIT
 ---
index c308e91..31af7f2 100644 (file)
@@ -8,8 +8,8 @@ git-shortlog - Summarize 'git log' output
 SYNOPSIS
 --------
 [verse]
-git log --pretty=short | 'git shortlog' [-h] [-n] [-s] [-e] [-w]
-'git shortlog' [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] <commit>...
+git log --pretty=short | 'git shortlog' [<options>]
+'git shortlog' [<options>] [<revision range>] [[\--] <path>...]
 
 DESCRIPTION
 -----------
@@ -26,10 +26,6 @@ reference to the current repository.
 OPTIONS
 -------
 
--h::
---help::
-       Print a short usage message and exit.
-
 -n::
 --numbered::
        Sort output according to the number of commits per author instead
@@ -60,6 +56,21 @@ OPTIONS
 If width is `0` (zero) then indent the lines of the output without wrapping
 them.
 
+<revision range>::
+       Show only commits in the specified revision range.  When no
+       <revision range> is specified, it defaults to `HEAD` (i.e. the
+       whole history leading to the current commit).  `origin..HEAD`
+       specifies all the commits reachable from the current commit
+       (i.e. `HEAD`), but not from `origin`. For a complete list of
+       ways to spell <revision range>, see the "Specifying Ranges"
+       section of linkgit:gitrevisions[7].
+
+[\--] <path>...::
+       Consider only commits that are enough to explain how the files
+       that match the specified paths came to be.
++
+Paths may need to be prefixed with "\-- " to separate them from
+options or the revision range, when confusion arises.
 
 MAPPING AUTHORS
 ---------------
index a8e77b5..a515648 100644 (file)
@@ -31,7 +31,7 @@ no <rev> nor <glob> is given on the command line.
 OPTIONS
 -------
 <rev>::
-       Arbitrary extended SHA1 expression (see linkgit:gitrevisions[7])
+       Arbitrary extended SHA-1 expression (see linkgit:gitrevisions[7])
        that typically names a branch head or a tag.
 
 <glob>::
@@ -142,7 +142,7 @@ displayed, indented N places.  If a commit is on the I-th
 branch, the I-th indentation character shows a `+` sign;
 otherwise it shows a space.  Merge commits are denoted by
 a `-` sign.  Each commit shows a short name that
-can be used as an extended SHA1 to name that commit.
+can be used as an extended SHA-1 to name that commit.
 
 The following example shows three branches, "master", "fixes"
 and "mhf":
index 9cbbed9..fbdc8ad 100644 (file)
@@ -19,7 +19,7 @@ Reads given idx file for packed Git archive created with
 
 The information it outputs is subset of what you can get from
 'git verify-pack -v'; this command only shows the packfile
-offset and SHA1 of each object.
+offset and SHA-1 of each object.
 
 GIT
 ---
index 5dbcd47..de4d352 100644 (file)
@@ -50,8 +50,8 @@ OPTIONS
 -s::
 --hash[=<n>]::
 
-       Only show the SHA1 hash, not the reference name. When combined with
-       --dereference the dereferenced tag will still be shown after the SHA1.
+       Only show the SHA-1 hash, not the reference name. When combined with
+       --dereference the dereferenced tag will still be shown after the SHA-1.
 
 --verify::
 
index 0412c40..9046df9 100644 (file)
@@ -46,15 +46,21 @@ OPTIONS
        Show untracked files.
 +
 The mode parameter is optional (defaults to 'all'), and is used to
-specify the handling of untracked files; when -u is not used, the
-default is 'normal', i.e. show untracked files and directories.
+specify the handling of untracked files.
 +
 The possible options are:
 +
-       - 'no'     - Show no untracked files
-       - 'normal' - Shows untracked files and directories
+       - 'no'     - Show no untracked files.
+       - 'normal' - Shows untracked files and directories.
        - 'all'    - Also shows individual files in untracked directories.
 +
+When `-u` option is not used, untracked files and directories are
+shown (i.e. the same as specifying `normal`), to help you avoid
+forgetting to add newly created files.  Because it takes extra work
+to find untracked files in the filesystem, this mode may take some
+time in a large working tree.  You can use `no` to have `git status`
+return more quickly without showing untracked files.
++
 The default can be changed using the status.showUntrackedFiles
 configuration variable documented in linkgit:git-config[1].
 
index c99d795..74d5bdc 100644 (file)
@@ -13,6 +13,7 @@ SYNOPSIS
              [--reference <repository>] [--] <repository> [<path>]
 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
 'git submodule' [--quiet] init [--] [<path>...]
+'git submodule' [--quiet] deinit [-f|--force] [--] <path>...
 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
              [-f|--force] [--rebase] [--reference <repository>]
              [--merge] [--recursive] [--] [<path>...]
@@ -135,6 +136,19 @@ init::
        the explicit 'init' step if you do not intend to customize
        any submodule locations.
 
+deinit::
+       Unregister the given submodules, i.e. remove the whole
+       `submodule.$name` section from .git/config together with their work
+       tree. Further calls to `git submodule update`, `git submodule foreach`
+       and `git submodule sync` will skip any unregistered submodules until
+       they are initialized again, so use this command if you don't want to
+       have a local checkout of the submodule in your work tree anymore. If
+       you really want to remove a submodule from the repository and commit
+       that use linkgit:git-rm[1] instead.
++
+If `--force` is specified, the submodule's work tree will be removed even if
+it contains local modifications.
+
 update::
        Update the registered submodules, i.e. clone missing submodules and
        checkout the commit specified in the index of the containing repository.
@@ -214,8 +228,10 @@ OPTIONS
 
 -f::
 --force::
-       This option is only valid for add and update commands.
+       This option is only valid for add, deinit and update commands.
        When running add, allow adding an otherwise ignored submodule path.
+       When running deinit the submodule work trees will be removed even if
+       they contain local changes.
        When running update, throw away local changes in submodules when
        switching to a different commit; and always run a checkout operation
        in the submodule, even if the commit listed in the index of the
index 1b8b649..7706d41 100644 (file)
@@ -245,7 +245,7 @@ first have already been pushed into SVN.
        patch), "all" (accept all patches), or "quit".
        +
        'git svn dcommit' returns immediately if answer if "no" or "quit", without
-       commiting anything to SVN.
+       committing anything to SVN.
 
 'branch'::
        Create a branch in the SVN repository.
@@ -856,7 +856,7 @@ HANDLING OF SVN BRANCHES
 ------------------------
 If 'git svn' is configured to fetch branches (and --follow-branches
 is in effect), it sometimes creates multiple Git branches for one
-SVN branch, where the addtional branches have names of the form
+SVN branch, where the additional branches have names of the form
 'branchname@nnn' (with nnn an SVN revision number).  These additional
 branches are created if 'git svn' cannot find a parent commit for the
 first commit in an SVN branch, to connect the branch to the history of
index e3032c4..22894cb 100644 (file)
@@ -33,7 +33,7 @@ in the tag message.
 If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>`
 are absent, `-a` is implied.
 
-Otherwise just a tag reference for the SHA1 object name of the commit object is
+Otherwise just a tag reference for the SHA-1 object name of the commit object is
 created (i.e. a lightweight tag).
 
 A GnuPG signed tag object will be created when `-s` or `-u
@@ -126,6 +126,12 @@ This option is only applicable when listing tags without annotation lines.
        linkgit:git-check-ref-format[1].  Some of these checks
        may restrict the characters allowed in a tag name.
 
+<commit>::
+<object>::
+       The object that the new tag will refer to, usually a commit.
+       Defaults to HEAD.
+
+
 CONFIGURATION
 -------------
 By default, 'git tag' in sign-with-default mode (-s) will use your
index ad8b823..78a0d95 100644 (file)
@@ -109,7 +109,7 @@ Others
 
    - *git.el* (contrib/)
 
-   This is an Emacs interface for Git. The user interface is modeled on
+   This is an Emacs interface for Git. The user interface is modelled on
    pcl-cvs. It has been developed on Emacs 21 and will probably need some
    tweaking to work on XEmacs.
 
index 77a912d..670e9fb 100644 (file)
@@ -145,7 +145,15 @@ you will need to handle the situation manually.
 
 --index-version <n>::
        Write the resulting index out in the named on-disk format version.
-       The current default version is 2.
+       Supported versions are 2, 3 and 4. The current default version is 2
+       or 3, depending on whether extra features are used, such as
+       `git add -N`.
++
+Version 4 performs a simple pathname compression that reduces index
+size by 30%-50% on large repositories, which results in faster load
+time. Version 4 is relatively young (first released in in 1.8.0 in
+October 2012). Other Git implementations such as JGit and libgit2
+may not support it yet.
 
 -z::
        Only meaningful with `--stdin` or `--index-info`; paths are
@@ -239,7 +247,7 @@ $ git update-index --index-info
 ------------
 
 The first line of the input feeds 0 as the mode to remove the
-path; the SHA1 does not matter as long as it is well formatted.
+path; the SHA-1 does not matter as long as it is well formatted.
 Then the second and third line feeds stage 1 and stage 2 entries
 for that path.  After the above, we would end up with this:
 
index 0eb9ffb..526ba7b 100644 (file)
@@ -40,11 +40,11 @@ OUTPUT FORMAT
 -------------
 When specifying the -v option the format used is:
 
-       SHA1 type size size-in-pack-file offset-in-packfile
+       SHA-1 type size size-in-pack-file offset-in-packfile
 
 for objects that are not deltified in the pack, and
 
-       SHA1 type size size-in-packfile offset-in-packfile depth base-SHA1
+       SHA-1 type size size-in-packfile offset-in-packfile depth base-SHA-1
 
 for objects that are deltified.
 
index e996135..f88ba96 100644 (file)
@@ -21,7 +21,7 @@ OPTIONS
        Print the contents of the tag object before validating it.
 
 <tag>...::
-       SHA1 identifiers of Git tag objects.
+       SHA-1 identifiers of Git tag objects.
 
 GIT
 ---
index 7efaa59..8438c07 100644 (file)
@@ -43,14 +43,17 @@ unreleased) version of Git, that is available from 'master'
 branch of the `git.git` repository.
 Documentation for older releases are available here:
 
-* link:v1.8.2/git.html[documentation for release 1.8.2]
+* link:v1.8.2.2/git.html[documentation for release 1.8.2.2]
 
 * release notes for
+  link:RelNotes/1.8.2.2.txt[1.8.2.2].
+  link:RelNotes/1.8.2.1.txt[1.8.2.1].
   link:RelNotes/1.8.2.txt[1.8.2].
 
-* link:v1.8.1.5/git.html[documentation for release 1.8.1.5]
+* link:v1.8.1.6/git.html[documentation for release 1.8.1.6]
 
 * release notes for
+  link:RelNotes/1.8.1.6.txt[1.8.1.6],
   link:RelNotes/1.8.1.5.txt[1.8.1.5],
   link:RelNotes/1.8.1.4.txt[1.8.1.4],
   link:RelNotes/1.8.1.3.txt[1.8.1.3],
@@ -739,7 +742,7 @@ where:
 
        <old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the
                          contents of <old|new>,
-       <old|new>-hex:: are the 40-hexdigit SHA1 hashes,
+       <old|new>-hex:: are the 40-hexdigit SHA-1 hashes,
        <old|new>-mode:: are the octal representation of the file modes.
 +
 The file parameters can point at the user's working file
@@ -774,9 +777,12 @@ other
        If this environment variable is set then 'git fetch'
        and 'git push' will use this command instead
        of 'ssh' when they need to connect to a remote system.
-       The '$GIT_SSH' command will be given exactly two arguments:
-       the 'username@host' (or just 'host') from the URL and the
-       shell command to execute on that remote system.
+       The '$GIT_SSH' command will be given exactly two or
+       four arguments: the 'username@host' (or just 'host')
+       from the URL and the shell command to execute on that
+       remote system, optionally preceded by '-p' (literally) and
+       the 'port' from the URL when it specifies something other
+       than the default SSH port.
 +
 To pass options to the program that you want to list in GIT_SSH
 you will need to wrap the program and options into a shell script,
@@ -859,7 +865,7 @@ The commit, equivalent to what other systems call a "changeset" or
 represents an immediately preceding step.  Commits with more than one
 parent represent merges of independent lines of development.
 
-All objects are named by the SHA1 hash of their contents, normally
+All objects are named by the SHA-1 hash of their contents, normally
 written as a string of 40 hex digits.  Such names are globally unique.
 The entire history leading up to a commit can be vouched for by signing
 just that commit.  A fourth object type, the tag, is provided for this
@@ -869,9 +875,9 @@ When first created, objects are stored in individual files, but for
 efficiency may later be compressed together into "pack files".
 
 Named pointers called refs mark interesting points in history.  A ref
-may contain the SHA1 name of an object or the name of another ref.  Refs
-with names beginning `ref/head/` contain the SHA1 name of the most
-recent commit (or "head") of a branch under development.  SHA1 names of
+may contain the SHA-1 name of an object or the name of another ref.  Refs
+with names beginning `ref/head/` contain the SHA-1 name of the most
+recent commit (or "head") of a branch under development.  SHA-1 names of
 tags of interest are stored under `ref/tags/`.  A special ref named
 `HEAD` contains the name of the currently checked-out branch.
 
index dc9e617..9ac5088 100644 (file)
@@ -107,13 +107,14 @@ couple of magic command line options:
 ---------------------------------------------
 $ git describe -h
 usage: git describe [options] <committish>*
+   or: git describe [options] --dirty
 
     --contains            find the tag that comes after the commit
     --debug               debug search strategy on stderr
-    --all                 use any ref in .git/refs
-    --tags                use any tag in .git/refs/tags
-    --abbrev [<n>]        use <n> digits to display SHA-1s
-    --candidates <n>      consider <n> most recent tags (default: 10)
+    --all                 use any ref
+    --tags                use any tag, even unannotated
+    --long                always use long format
+    --abbrev[=<n>]        use <n> digits to display SHA-1s
 ---------------------------------------------
 
 --help-all::
index 59c1c17..f538a87 100644 (file)
@@ -106,9 +106,9 @@ branch. A number of the Git tools will assume that `.git/HEAD` is
 valid, though.
 
 [NOTE]
-An 'object' is identified by its 160-bit SHA1 hash, aka 'object name',
+An 'object' is identified by its 160-bit SHA-1 hash, aka 'object name',
 and a reference to an object is always the 40-byte hex
-representation of that SHA1 name. The files in the `refs`
+representation of that SHA-1 name. The files in the `refs`
 subdirectory are expected to contain these hex references
 (usually with a final `\n` at the end), and you should thus
 expect to see a number of 41-byte files containing these
@@ -763,7 +763,7 @@ already discussed, the `HEAD` branch is nothing but a symlink to one of
 these object pointers.
 
 You can at any time create a new branch by just picking an arbitrary
-point in the project history, and just writing the SHA1 name of that
+point in the project history, and just writing the SHA-1 name of that
 object into a file under `.git/refs/heads/`. You can use any filename you
 want (and indeed, subdirectories), but the convention is that the
 "normal" branch is called `master`. That's just a convention, though,
@@ -1233,7 +1233,7 @@ file (the first tree goes to stage 1, the second to stage 2,
 etc.).  After reading three trees into three stages, the paths
 that are the same in all three stages are 'collapsed' into stage
 0.  Also paths that are the same in two of three stages are
-collapsed into stage 0, taking the SHA1 from either stage 2 or
+collapsed into stage 0, taking the SHA-1 from either stage 2 or
 stage 3, whichever is different from stage 1 (i.e. only one side
 changed from the common ancestor).
 
index 4ed71c7..568d757 100644 (file)
@@ -108,7 +108,7 @@ it changes it to:
 For the purpose of breaking a filepair, diffcore-break examines
 the extent of changes between the contents of the files before
 and after modification (i.e. the contents that have "bcd1234..."
-and "0123456..." as their SHA1 content ID, in the above
+and "0123456..." as their SHA-1 content ID, in the above
 example).  The amount of deletion of original contents and
 insertion of new material are added together, and if it exceeds
 the "break score", the filepair is broken into two.  The break
index eab9b35..d48bf4d 100644 (file)
@@ -99,7 +99,7 @@ given); `template` (if a `-t` option was given or the
 configuration option `commit.template` is set); `merge` (if the
 commit is a merge or a `.git/MERGE_MSG` file exists); `squash`
 (if a `.git/SQUASH_MSG` file exists); or `commit`, followed by
-a commit SHA1 (if a `-c`, `-C` or `--amend` option was given).
+a commit SHA-1 (if a `-c`, `-C` or `--amend` option was given).
 
 If the exit status is non-zero, 'git commit' will abort.
 
@@ -140,9 +140,11 @@ the outcome of 'git commit'.
 pre-rebase
 ~~~~~~~~~~
 
-This hook is called by 'git rebase' and can be used to prevent a branch
-from getting rebased.
-
+This hook is called by 'git rebase' and can be used to prevent a
+branch from getting rebased.  The hook may be called with one or
+two parameters.  The first parameter is the upstream from which
+the series was forked.  The second parameter is the branch being
+rebased, and is not set when rebasing the current branch.
 
 post-checkout
 ~~~~~~~~~~~~~
@@ -194,11 +196,11 @@ hook would receive a line like the following:
 
   refs/heads/master 67890 refs/heads/foreign 12345
 
-although the full, 40-character SHA1s would be supplied.  If the foreign ref
-does not yet exist the `<remote SHA1>` will be 40 `0`.  If a ref is to be
+although the full, 40-character SHA-1s would be supplied.  If the foreign ref
+does not yet exist the `<remote SHA-1>` will be 40 `0`.  If a ref is to be
 deleted, the `<local ref>` will be supplied as `(delete)` and the `<local
-SHA1>` will be 40 `0`.  If the local commit was specified by something other
-than a name which could be expanded (such as `HEAD~`, or a SHA1) it will be
+SHA-1>` will be 40 `0`.  If the local commit was specified by something other
+than a name which could be expanded (such as `HEAD~`, or a SHA-1) it will be
 supplied as it was originally given.
 
 If this hook exits with a non-zero status, 'git push' will abort without
index 0c91aba..da74641 100644 (file)
@@ -174,8 +174,8 @@ ref.
 This capability can be advertised multiple times.  The first
 applicable refspec takes precedence.  The left-hand of refspecs
 advertised with this capability must cover all refs reported by
-the list command.  If no 'refspec' capability is advertised,
-there is an implied `refspec *:*`.
+the list command.  If a helper does not need a specific 'refspec'
+capability then it should advertise `refspec *:*`.
 
 'bidi-import'::
        This modifies the 'import' capability.
@@ -202,6 +202,10 @@ there is an implied `refspec *:*`.
        marks specified in <file> before processing any input. For details,
        read up on '--import-marks=<file>' in linkgit:git-fast-export[1].
 
+'signed-tags'::
+       This modifies the 'export' capability, instructing Git to pass
+       '--signed-tags=verbatim' to linkgit:git-fast-export[1].  In the
+       absence of this capability, Git will use '--signed-tags=warn-strip'.
 
 
 
index f0eef76..d6f3393 100644 (file)
@@ -106,7 +106,7 @@ refs/remotes/`name`::
        from a remote repository.
 
 refs/replace/`<obj-sha1>`::
-       records the SHA1 of the object that replaces `<obj-sha1>`.
+       records the SHA-1 of the object that replaces `<obj-sha1>`.
        This is similar to info/grafts and is internally used and
        maintained by linkgit:git-replace[1]. Such refs can be exchanged
        between repositories while grafts are not.
@@ -184,6 +184,10 @@ info/exclude::
        'git clean' look at it but the core Git commands do not look
        at it.  See also: linkgit:gitignore[5].
 
+info/sparse-checkout::
+       This file stores sparse checkout patterns.
+       See also: linkgit:git-read-tree[1].
+
 remotes::
        Stores shorthands for URL and default refnames for use
        when interacting with remote repositories via 'git fetch',
index 94c906e..3109ea8 100644 (file)
@@ -46,9 +46,9 @@ What are the 7 digits of hex that Git responded to the commit with?
 
 We saw in part one of the tutorial that commits have names like this.
 It turns out that every object in the Git history is stored under
-a 40-digit hex name.  That name is the SHA1 hash of the object's
+a 40-digit hex name.  That name is the SHA-1 hash of the object's
 contents; among other things, this ensures that Git will never store
-the same data twice (since identical data is given an identical SHA1
+the same data twice (since identical data is given an identical SHA-1
 name), and that the contents of a Git object will never change (since
 that would change the object's name as well). The 7 char hex strings
 here are simply the abbreviation of such 40 character long strings.
@@ -56,7 +56,7 @@ Abbreviations can be used everywhere where the 40 character strings
 can be used, so long as they are unambiguous.
 
 It is expected that the content of the commit object you created while
-following the example above generates a different SHA1 hash than
+following the example above generates a different SHA-1 hash than
 the one shown above because the commit object records the time when
 it was created and the name of the person performing the commit.
 
@@ -80,14 +80,14 @@ A tree can refer to one or more "blob" objects, each corresponding to
 a file.  In addition, a tree can also refer to other tree objects,
 thus creating a directory hierarchy.  You can examine the contents of
 any tree using ls-tree (remember that a long enough initial portion
-of the SHA1 will also work):
+of the SHA-1 will also work):
 
 ------------------------------------------------
 $ git ls-tree 92b8b694
 100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad    file.txt
 ------------------------------------------------
 
-Thus we see that this tree has one file in it.  The SHA1 hash is a
+Thus we see that this tree has one file in it.  The SHA-1 hash is a
 reference to that file's data:
 
 ------------------------------------------------
@@ -106,7 +106,7 @@ Note that this is the old file data; so the object that Git named in
 its response to the initial tree was a tree with a snapshot of the
 directory state that was recorded by the first commit.
 
-All of these objects are stored under their SHA1 names inside the Git
+All of these objects are stored under their SHA-1 names inside the Git
 directory:
 
 ------------------------------------------------
@@ -142,7 +142,7 @@ ref: refs/heads/master
 
 As you can see, this tells us which branch we're currently on, and it
 tells us this by naming a file under the .git directory, which itself
-contains a SHA1 name referring to a commit object, which we can
+contains a SHA-1 name referring to a commit object, which we can
 examine with cat-file:
 
 ------------------------------------------------
@@ -208,7 +208,7 @@ project's history:
 
 Note, by the way, that lots of commands take a tree as an argument.
 But as we can see above, a tree can be referred to in many different
-ways--by the SHA1 name for that tree, by the name of a commit that
+ways--by the SHA-1 name for that tree, by the name of a commit that
 refers to the tree, by the name of a branch whose head refers to that
 tree, etc.--and most such commands can accept any of these names.
 
index eb63631..ea0526e 100644 (file)
@@ -857,6 +857,13 @@ adding the following lines to your gitweb configuration file:
        $known_snapshot_formats{'zip'}{'disabled'} = 1;
        $known_snapshot_formats{'tgz'}{'compressor'} = ['gzip','-6'];
 
+BUGS
+----
+Debugging would be easier if the fallback configuration file
+(`/etc/gitweb.conf`) and environment variable to override its location
+('GITWEB_CONFIG_SYSTEM') had names reflecting their "fallback" role.
+The current names are kept to avoid breaking working setups.
+
 ENVIRONMENT
 -----------
 The location of per-instance and system-wide configuration files can be
index eb7ba84..68a18e1 100644 (file)
@@ -100,12 +100,22 @@ to point at the new commit.
 
 [[def_detached_HEAD]]detached HEAD::
        Normally the <<def_HEAD,HEAD>> stores the name of a
-       <<def_branch,branch>>.  However, Git also allows you to <<def_checkout,check out>>
-       an arbitrary <<def_commit,commit>> that isn't necessarily the tip of any
-       particular branch.  In this case HEAD is said to be "detached".
-
-[[def_dircache]]dircache::
-       You are *waaaaay* behind. See <<def_index,index>>.
+       <<def_branch,branch>>, and commands that operate on the
+       history HEAD represents operate on the history leading to the
+       tip of the branch the HEAD points at.  However, Git also
+       allows you to <<def_checkout,check out>> an arbitrary
+       <<def_commit,commit>> that isn't necessarily the tip of any
+       particular branch.  The HEAD in such a state is called
+       "detached".
++
+Note that commands that operate on the history of the current branch
+(e.g. `git commit` to build a new history on top of it) still work
+while the HEAD is detached. They update the HEAD to point at the tip
+of the updated history without affecting any branch.  Commands that
+update or inquire information _about_ the current branch (e.g. `git
+branch --set-upstream-to` that sets what remote tracking branch the
+current branch integrates with) obviously do not work, as there is no
+(real) current branch to ask about in this state.
 
 [[def_directory]]directory::
        The list you get with "ls" :-)
@@ -115,11 +125,6 @@ to point at the new commit.
        it contains modifications which have not been <<def_commit,committed>> to the current
        <<def_branch,branch>>.
 
-[[def_ent]]ent::
-       Favorite synonym to "<<def_tree-ish,tree-ish>>" by some total geeks. See
-       http://en.wikipedia.org/wiki/Ent_(Middle-earth) for an in-depth
-       explanation. Avoid this term, not to confuse people.
-
 [[def_evil_merge]]evil merge::
        An evil merge is a <<def_merge,merge>> that introduces changes that
        do not appear in any <<def_parent,parent>>.
@@ -161,7 +166,7 @@ to point at the new commit.
        created. Configured via the `.git/info/grafts` file.
 
 [[def_hash]]hash::
-       In Git's context, synonym to <<def_object_name,object name>>.
+       In Git's context, synonym for <<def_object_name,object name>>.
 
 [[def_head]]head::
        A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a
@@ -233,7 +238,7 @@ This commit is referred to as a "merge commit", or sometimes just a
 
 [[def_object]]object::
        The unit of storage in Git. It is uniquely identified by the
-       <<def_SHA1,SHA1>> of its contents. Consequently, an
+       <<def_SHA1,SHA-1>> of its contents. Consequently, an
        object can not be changed.
 
 [[def_object_database]]object database::
@@ -245,10 +250,9 @@ This commit is referred to as a "merge commit", or sometimes just a
        Synonym for <<def_object_name,object name>>.
 
 [[def_object_name]]object name::
-       The unique identifier of an <<def_object,object>>. The <<def_hash,hash>>
-       of the object's contents using the Secure Hash Algorithm
-       1 and usually represented by the 40 character hexadecimal encoding of
-       the <<def_hash,hash>> of the object.
+       The unique identifier of an <<def_object,object>>.  The
+       object name is usually represented by a 40 character
+       hexadecimal string.  Also colloquially called <<def_SHA1,SHA-1>>.
 
 [[def_object_type]]object type::
        One of the identifiers "<<def_commit_object,commit>>",
@@ -257,8 +261,7 @@ This commit is referred to as a "merge commit", or sometimes just a
        <<def_object,object>>.
 
 [[def_octopus]]octopus::
-       To <<def_merge,merge>> more than two <<def_branch,branches>>. Also denotes an
-       intelligent predator.
+       To <<def_merge,merge>> more than two <<def_branch,branches>>.
 
 [[def_origin]]origin::
        The default upstream <<def_repository,repository>>. Most projects have
@@ -278,7 +281,7 @@ This commit is referred to as a "merge commit", or sometimes just a
        pack.
 
 [[def_pathspec]]pathspec::
-       Pattern used to specify paths.
+       Pattern used to limit paths in Git commands.
 +
 Pathspecs are used on the command line of "git ls-files", "git
 ls-tree", "git add", "git grep", "git diff", "git checkout",
@@ -287,6 +290,8 @@ limit the scope of operations to some subset of the tree or
 worktree.  See the documentation of each command for whether
 paths are relative to the current directory or toplevel.  The
 pathspec syntax is as follows:
++
+--
 
 * any path matches itself
 * the pathspec up to the last slash represents a
@@ -296,11 +301,12 @@ pathspec syntax is as follows:
   of the pathname.  Paths relative to the directory
   prefix will be matched against that pattern using fnmatch(3);
   in particular, '*' and '?' _can_ match directory separators.
+
+--
 +
 For example, Documentation/*.jpg will match all .jpg files
 in the Documentation subtree,
 including Documentation/chapter_1/figure_1.jpg.
-
 +
 A pathspec that begins with a colon `:` has special meaning.  In the
 short form, the leading colon `:` is followed by zero or more "magic
@@ -316,18 +322,10 @@ and a close parentheses `)`, and the remainder is the pattern to match
 against the path.
 +
 The "magic signature" consists of an ASCII symbol that is not
-alphanumeric.
-+
---
-top `/`;;
-       The magic word `top` (mnemonic: `/`) makes the pattern match
-       from the root of the working tree, even when you are running
-       the command from inside a subdirectory.
---
-+
-Currently only the slash `/` is recognized as the "magic signature",
-but it is envisioned that we will support more types of magic in later
-versions of Git.
+alphanumeric. Currently only the slash `/` is recognized as a
+"magic signature": it makes the pattern match from the root of
+the working tree, even when you are running the command from
+inside a subdirectory.
 +
 A pathspec with only a colon means "there is no pathspec". This form
 should not be combined with other pathspec.
@@ -385,7 +383,7 @@ should not be combined with other pathspec.
        to the result.
 
 [[def_ref]]ref::
-       A 40-byte hex representation of a <<def_SHA1,SHA1>> or a name that
+       A 40-byte hex representation of a <<def_SHA1,SHA-1>> or a name that
        denotes a particular <<def_object,object>>. They may be stored in
        a file under `$GIT_DIR/refs/` directory, or
        in the `$GIT_DIR/packed-refs` file.
@@ -399,15 +397,7 @@ should not be combined with other pathspec.
 [[def_refspec]]refspec::
        A "refspec" is used by <<def_fetch,fetch>> and
        <<def_push,push>> to describe the mapping between remote
-       <<def_ref,ref>> and local ref. They are combined with a colon in
-       the format <src>:<dst>, preceded by an optional plus sign, +.
-       For example: `git fetch $URL
-       refs/heads/master:refs/heads/origin` means "grab the master
-       <<def_branch,branch>> <<def_head,head>> from the $URL and store
-       it as my origin branch head". And `git push
-       $URL refs/heads/master:refs/heads/to-upstream` means "publish my
-       master branch head as to-upstream branch at $URL". See also
-       linkgit:git-push[1].
+       <<def_ref,ref>> and local ref.
 
 [[def_remote_tracking_branch]]remote-tracking branch::
        A regular Git <<def_branch,branch>> that is used to follow changes from
@@ -430,9 +420,7 @@ should not be combined with other pathspec.
        <<def_merge,merge>> left behind.
 
 [[def_revision]]revision::
-       A particular state of files and directories which was stored in the
-       <<def_object_database,object database>>. It is referenced by a
-       <<def_commit_object,commit object>>.
+       Synonym for <<def_commit,commit>> (the noun).
 
 [[def_rewind]]rewind::
        To throw away part of the development, i.e. to assign the
@@ -441,8 +429,9 @@ should not be combined with other pathspec.
 [[def_SCM]]SCM::
        Source code management (tool).
 
-[[def_SHA1]]SHA1::
-       Synonym for <<def_object_name,object name>>.
+[[def_SHA1]]SHA-1::
+       "Secure Hash Algorithm 1"; a cryptographic hash function.
+       In the context of Git used as a synonym for <<def_object_name,object name>>.
 
 [[def_shallow_repository]]shallow repository::
        A shallow <<def_repository,repository>> has an incomplete
@@ -456,7 +445,7 @@ should not be combined with other pathspec.
        its history can be later deepened with linkgit:git-fetch[1].
 
 [[def_symref]]symref::
-       Symbolic reference: instead of containing the <<def_SHA1,SHA1>>
+       Symbolic reference: instead of containing the <<def_SHA1,SHA-1>>
        id itself, it is of the format 'ref: refs/some/thing' and when
        referenced, it recursively dereferences to this reference.
        '<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic
index 6d362ce..1b3b188 100644 (file)
@@ -15,7 +15,7 @@ On Fri, 9 Nov 2007, Yossi Leybovich wrote:
 > Any one know how can I track this object and understand which file is it
 -----------------------------------------------------------
 
-So exactly *because* the SHA1 hash is cryptographically secure, the hash
+So exactly *because* the SHA-1 hash is cryptographically secure, the hash
 itself doesn't actually tell you anything, in order to fix a corrupt
 object you basically have to find the "original source" for it.
 
@@ -44,7 +44,7 @@ So:
 -----------------------------------------------------------
 
 This is the right thing to do, although it's usually best to save it under
-it's full SHA1 name (you just dropped the "4b" from the result ;).
+it's full SHA-1 name (you just dropped the "4b" from the result ;).
 
 Let's see what that tells us:
 
@@ -89,7 +89,7 @@ working tree, in which case fixing this problem is really simple, just do
 
        git hash-object -w my-magic-file
 
-again, and if it outputs the missing SHA1 (4b945..) you're now all done!
+again, and if it outputs the missing SHA-1 (4b945..) you're now all done!
 
 But that's the really lucky case, so let's assume that it was some older
 version that was broken. How do you tell which version it was?
index 0bcbe0a..2adccf8 100644 (file)
@@ -30,7 +30,8 @@ set to `no` at the beginning of them.
 
 --no-ff::
        Create a merge commit even when the merge resolves as a
-       fast-forward.
+       fast-forward.  This is the default behaviour when merging an
+       annotated (and possibly signed) tag.
 
 --ff-only::
        Refuse to merge and exit with a non-zero status unless the
@@ -83,6 +84,11 @@ option can be used to override --squash.
        Pass merge strategy specific option through to the merge
        strategy.
 
+--verify-signatures::
+--no-verify-signatures::
+       Verify that the commits being merged have good and trusted GPG signatures
+       and abort the merge in case they do not.
+
 --summary::
 --no-summary::
        Synonyms to --stat and --no-stat; these are deprecated and will be
index 66db802..49a9a7d 100644 (file)
@@ -48,6 +48,12 @@ patience;;
        this when the branches to be merged have diverged wildly.
        See also linkgit:git-diff[1] `--patience`.
 
+diff-algorithm=[patience|minimal|histogram|myers];;
+       Tells 'merge-recursive' to use a different diff algorithm, which
+       can help avoid mismerges that occur due to unimportant matching
+       lines (such as braces from distinct functions).  See also
+       linkgit:git-diff[1] `--diff-algorithm`.
+
 ignore-space-change;;
 ignore-all-space;;
 ignore-space-at-eol;;
index 105f18a..1d174fd 100644 (file)
@@ -75,7 +75,7 @@ This is designed to be as compact as possible.
 * 'raw'
 +
 The 'raw' format shows the entire commit exactly as
-stored in the commit object.  Notably, the SHA1s are
+stored in the commit object.  Notably, the SHA-1s are
 displayed in full, regardless of whether --abbrev or
 --no-abbrev are used, and 'parents' information show the
 true parent commits, without taking grafts nor history
@@ -106,18 +106,22 @@ The placeholders are:
 - '%P': parent hashes
 - '%p': abbreviated parent hashes
 - '%an': author name
-- '%aN': author name (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1])
+- '%aN': author name (respecting .mailmap, see linkgit:git-shortlog[1]
+  or linkgit:git-blame[1])
 - '%ae': author email
-- '%aE': author email (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1])
+- '%aE': author email (respecting .mailmap, see
+  linkgit:git-shortlog[1] or linkgit:git-blame[1])
 - '%ad': author date (format respects --date= option)
 - '%aD': author date, RFC2822 style
 - '%ar': author date, relative
 - '%at': author date, UNIX timestamp
 - '%ai': author date, ISO 8601 format
 - '%cn': committer name
-- '%cN': committer name (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1])
+- '%cN': committer name (respecting .mailmap, see
+  linkgit:git-shortlog[1] or linkgit:git-blame[1])
 - '%ce': committer email
-- '%cE': committer email (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1])
+- '%cE': committer email (respecting .mailmap, see
+  linkgit:git-shortlog[1] or linkgit:git-blame[1])
 - '%cd': committer date
 - '%cD': committer date, RFC2822 style
 - '%cr': committer date, relative
@@ -131,14 +135,18 @@ The placeholders are:
 - '%B': raw body (unwrapped subject and body)
 - '%N': commit notes
 - '%GG': raw verification message from GPG for a signed commit
-- '%G?': show either "G" for Good or "B" for Bad for a signed commit
+- '%G?': show "G" for a Good signature, "B" for a Bad signature, "U" for a good,
+  untrusted signature and "N" for no signature
 - '%GS': show the name of the signer for a signed commit
+- '%GK': show the key used to sign a signed commit
 - '%gD': reflog selector, e.g., `refs/stash@{1}`
 - '%gd': shortened reflog selector, e.g., `stash@{1}`
 - '%gn': reflog identity name
-- '%gN': reflog identity name (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1])
+- '%gN': reflog identity name (respecting .mailmap, see
+  linkgit:git-shortlog[1] or linkgit:git-blame[1])
 - '%ge': reflog identity email
-- '%gE': reflog identity email (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1])
+- '%gE': reflog identity email (respecting .mailmap, see
+  linkgit:git-shortlog[1] or linkgit:git-blame[1])
 - '%gs': reflog subject
 - '%Cred': switch color to red
 - '%Cgreen': switch color to green
@@ -148,13 +156,28 @@ The placeholders are:
   adding `auto,` at the beginning will emit color only when colors are
   enabled for log output (by `color.diff`, `color.ui`, or `--color`, and
   respecting the `auto` settings of the former if we are going to a
-  terminal)
+  terminal). `auto` alone (i.e. `%C(auto)`) will turn on auto coloring
+  on the next placeholders until the color is switched again.
 - '%m': left, right or boundary mark
 - '%n': newline
 - '%%': a raw '%'
 - '%x00': print a byte from a hex code
 - '%w([<w>[,<i1>[,<i2>]]])': switch line wrapping, like the -w option of
   linkgit:git-shortlog[1].
+- '%<(<N>[,trunc|ltrunc|mtrunc])': make the next placeholder take at
+  least N columns, padding spaces on the right if necessary.
+  Optionally truncate at the beginning (ltrunc), the middle (mtrunc)
+  or the end (trunc) if the output is longer than N columns.
+  Note that truncating only works correctly with N >= 2.
+- '%<|(<N>)': make the next placeholder take at least until Nth
+  columns, padding spaces on the right if necessary
+- '%>(<N>)', '%>|(<N>)': similar to '%<(<N>)', '%<|(<N>)'
+  respectively, but padding spaces on the left
+- '%>>(<N>)', '%>>|(<N>)': similar to '%>(<N>)', '%>|(<N>)'
+  respectively, except that if the next placeholder takes more spaces
+  than given and there are spaces on its left, use those spaces
+- '%><(<N>)', '%><|(<N>)': similar to '% <(<N>)', '%<|(<N>)'
+  respectively, but padding both sides (i.e. the text is centered)
 
 NOTE: Some placeholders may depend on other options given to the
 revision traversal engine. For example, the `%g*` reflog options will
index 678d175..d477b3f 100644 (file)
@@ -2,13 +2,13 @@ SPECIFYING REVISIONS
 --------------------
 
 A revision parameter '<rev>' typically, but not necessarily, names a
-commit object.  It uses what is called an 'extended SHA1'
+commit object.  It uses what is called an 'extended SHA-1'
 syntax.  Here are various ways to spell object names.  The
 ones listed near the end of this list name trees and
 blobs contained in a commit.
 
 '<sha1>', e.g. 'dae86e1950b1277e545cee180551750029cfe735', 'dae86e'::
-  The full SHA1 object name (40-byte hexadecimal string), or
+  The full SHA-1 object name (40-byte hexadecimal string), or
   a leading substring that is unique within the repository.
   E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both
   name the same commit object if there is no other object in
@@ -55,7 +55,7 @@ when you run `git cherry-pick`.
 +
 Note that any of the 'refs/*' cases above may come either from
 the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.
-While the ref name encoding is unspecified, UTF-8 is prefered as
+While the ref name encoding is unspecified, UTF-8 is preferred as
 some output processing may assume ref names in UTF-8.
 
 '<refname>@\{<date>\}', e.g. 'master@\{yesterday\}', 'HEAD@\{5 minutes ago\}'::
@@ -88,10 +88,10 @@ some output processing may assume ref names in UTF-8.
   The construct '@\{-<n>\}' means the <n>th branch checked out
   before the current one.
 
-'<refname>@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'::
-  The suffix '@\{upstream\}' to a ref (short form '<refname>@\{u\}') refers to
-  the branch the ref is set to build on top of.  A missing ref defaults
-  to the current branch.
+'<branchname>@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'::
+  The suffix '@\{upstream\}' to a branchname (short form '<branchname>@\{u\}')
+  refers to the branch that the branch specified by branchname is set to build on
+  top of.  A missing branchname defaults to the current one.
 
 '<rev>{caret}', e.g. 'HEAD{caret}, v1.5.1{caret}0'::
   A suffix '{caret}' to a revision parameter means the first parent of
@@ -116,6 +116,11 @@ some output processing may assume ref names in UTF-8.
   object of that type is found or the object cannot be
   dereferenced anymore (in which case, barf).  '<rev>{caret}0'
   is a short-hand for '<rev>{caret}\{commit\}'.
++
+'rev{caret}\{object\}' can be used to make sure 'rev' names an
+object that exists, without requiring 'rev' to be a tag, and
+without dereferencing 'rev'; because a tag is already an object,
+it does not have to be dereferenced even once to get to an object.
 
 '<rev>{caret}\{\}', e.g. 'v0.99.8{caret}\{\}'::
   A suffix '{caret}' followed by an empty brace pair
@@ -239,11 +244,13 @@ To summarize:
 
 '<rev1>..<rev2>'::
        Include commits that are reachable from <rev2> but exclude
-       those that are reachable from <rev1>.
+       those that are reachable from <rev1>.  When either <rev1> or
+       <rev2> is omitted, it defaults to 'HEAD'.
 
 '<rev1>\...<rev2>'::
        Include commits that are reachable from either <rev1> or
-       <rev2> but exclude those that are reachable from both.
+       <rev2> but exclude those that are reachable from both.  When
+       either <rev1> or <rev2> is omitted, it defaults to 'HEAD'.
 
 '<rev>{caret}@', e.g. 'HEAD{caret}@'::
   A suffix '{caret}' followed by an at sign is the same as listing
index a959517..a6b7d83 100644 (file)
@@ -55,7 +55,7 @@ Functions
        initial, empty state.
 
 `argv_array_detach`::
-       Detach the argv array from the `struct argv_array`, transfering
+       Detach the argv array from the `struct argv_array`, transferring
        ownership of the allocated array and strings.
 
 `argv_array_free_detached`::
index 516fda7..c1b42a4 100644 (file)
@@ -160,7 +160,7 @@ int foo_login(struct foo_connection *f)
                break;
        default:
                /*
-                * Some other error occured. We don't know if the
+                * Some other error occurred. We don't know if the
                 * credential is good or bad, so report nothing to the
                 * credential subsystem.
                 */
index 1f349b2..7f8e78d 100644 (file)
@@ -22,12 +22,23 @@ The notable options are:
 
 `flags`::
 
-       A bit-field of options:
+       A bit-field of options (the `*IGNORED*` flags are mutually exclusive):
 
 `DIR_SHOW_IGNORED`:::
 
-       The traversal is for finding just ignored files, not unignored
-       files.
+       Return just ignored files in `entries[]`, not untracked files.
+
+`DIR_SHOW_IGNORED_TOO`:::
+
+       Similar to `DIR_SHOW_IGNORED`, but return ignored files in `ignored[]`
+       in addition to untracked files in `entries[]`.
+
+`DIR_COLLECT_IGNORED`:::
+
+       Special mode for git-add. Return ignored files in `ignored[]` and
+       untracked files in `entries[]`. Only returns ignored files that match
+       pathspec exactly (no wildcards). Does not recurse into ignored
+       directories.
 
 `DIR_SHOW_OTHER_DIRECTORIES`:::
 
@@ -57,6 +68,14 @@ The result of the enumeration is left in these fields:
 
        Internal use; keeps track of allocation of `entries[]` array.
 
+`ignored[]`::
+
+       An array of `struct dir_entry`, used for ignored paths with the
+       `DIR_SHOW_IGNORED_TOO` and `DIR_COLLECT_IGNORED` flags.
+
+`ignored_nr`::
+
+       The number of members in `ignored[]` array.
 
 Calling sequence
 ----------------
index dbbea95..aa1c50f 100644 (file)
@@ -35,7 +35,7 @@ Iteration functions
 * `head_ref_submodule()`, `for_each_ref_submodule()`,
   `for_each_ref_in_submodule()`, `for_each_tag_ref_submodule()`,
   `for_each_branch_ref_submodule()`, `for_each_remote_ref_submodule()`
-  do the same as the functions descibed above but for a specified
+  do the same as the functions described above but for a specified
   submodule.
 
 * `for_each_rawref()` can be used to learn about broken ref and symref.
index 45d1c51..3e75497 100644 (file)
@@ -1,7 +1,7 @@
 sha1-array API
 ==============
 
-The sha1-array API provides storage and manipulation of sets of SHA1
+The sha1-array API provides storage and manipulation of sets of SHA-1
 identifiers. The emphasis is on storage and processing efficiency,
 making them suitable for large lists. Note that the ordering of items is
 not preserved over some operations.
@@ -11,7 +11,7 @@ Data Structures
 
 `struct sha1_array`::
 
-       A single array of SHA1 hashes. This should be initialized by
+       A single array of SHA-1 hashes. This should be initialized by
        assignment from `SHA1_ARRAY_INIT`.  The `sha1` member contains
        the actual data. The `nr` member contains the number of items in
        the set.  The `alloc` and `sorted` members are used internally,
index 2c59cb2..3350d97 100644 (file)
@@ -230,6 +230,11 @@ which can be used by the programmer of the callback as she sees fit.
        destination. This is useful for literal data to be fed to either
        strbuf_expand or to the *printf family of functions.
 
+`strbuf_humanise_bytes`::
+
+       Append the given byte size as a human-readable string (i.e. 12.23 KiB,
+       3.50 MiB).
+
 `strbuf_addf`::
 
        Add a formatted string to the buffer.
index 27c716b..0810251 100644 (file)
@@ -12,7 +12,7 @@ Git index format
        The signature is { 'D', 'I', 'R', 'C' } (stands for "dircache")
 
      4-byte version number:
-       The current supported versions are 2 and 3.
+       The current supported versions are 2, 3 and 4.
 
      32-bit number of index entries.
 
@@ -93,8 +93,8 @@ Git index format
     12-bit name length if the length is less than 0xFFF; otherwise 0xFFF
     is stored in this field.
 
-  (Version 3) A 16-bit field, only applicable if the "extended flag"
-  above is 1, split into (high to low bits).
+  (Version 3 or later) A 16-bit field, only applicable if the
+  "extended flag" above is 1, split into (high to low bits).
 
     1-bit reserved for future
 
index 0e37ec9..8e5bf60 100644 (file)
@@ -26,13 +26,15 @@ Git pack format
 
      (deltified representation)
      n-byte type and length (3-bit type, (n-1)*7+4-bit length)
-     20-byte base object name
+     20-byte base object name if OBJ_REF_DELTA or a negative relative
+        offset from the delta object's position in the pack if this
+        is an OBJ_OFS_DELTA object
      compressed delta data
 
      Observation: length of each object is encoded in a variable
      length format and is not constrained to 32-bit or anything.
 
-  - The trailer records 20-byte SHA1 checksum of all of the above.
+  - The trailer records 20-byte SHA-1 checksum of all of the above.
 
 == Original (version 1) pack-*.idx files have the following format:
 
@@ -53,10 +55,10 @@ Git pack format
 
   - The file is concluded with a trailer:
 
-    A copy of the 20-byte SHA1 checksum at the end of
+    A copy of the 20-byte SHA-1 checksum at the end of
     corresponding packfile.
 
-    20-byte SHA1-checksum of all of the above.
+    20-byte SHA-1-checksum of all of the above.
 
 Pack Idx file:
 
@@ -104,7 +106,7 @@ Pack file entry: <+
         If it is not DELTA, then deflated bytes (the size above
                is the size before compression).
        If it is REF_DELTA, then
-         20-byte base object name SHA1 (the size above is the
+         20-byte base object name SHA-1 (the size above is the
                size of the delta data that follows).
           delta data, deflated.
        If it is OFS_DELTA, then
@@ -133,7 +135,7 @@ Pack file entry: <+
 
   - A 256-entry fan-out table just like v1.
 
-  - A table of sorted 20-byte SHA1 object names.  These are
+  - A table of sorted 20-byte SHA-1 object names.  These are
     packed together without offset values to reduce the cache
     footprint of the binary search for a specific object name.
 
@@ -154,7 +156,7 @@ Pack file entry: <+
 
   - The same trailer as a v1 pack file:
 
-    A copy of the 20-byte SHA1 checksum at the end of
+    A copy of the 20-byte SHA-1 checksum at the end of
     corresponding packfile.
 
-    20-byte SHA1-checksum of all of the above.
+    20-byte SHA-1-checksum of all of the above.
index dbdf7ba..8b7ae1c 100644 (file)
@@ -89,7 +89,7 @@ Ah, grasshopper!  And thus the enlightenment begins anew.
 
     <linus> The "magic" is actually in theory totally arbitrary.
         ANY order will give you a working pack, but no, it's not
-        ordered by SHA1.
+       ordered by SHA-1.
 
         Before talking about the ordering for the sliding delta
         window, let's talk about the recency order. That's more
index ea2f69f..5183b15 100644 (file)
@@ -8,7 +8,7 @@ repo, and therefore grafts are introduced pretending that
 these commits have no parents.
 *********************************************************
 
-The basic idea is to write the SHA1s of shallow commits into
+The basic idea is to write the SHA-1s of shallow commits into
 $GIT_DIR/shallow, and handle its contents like the contents
 of $GIT_DIR/info/grafts (with the difference that shallow
 cannot contain parent information).
@@ -18,7 +18,7 @@ even the config, since the user should not touch that file
 at all (even throughout development of the shallow clone, it
 was never manually edited!).
 
-Each line contains exactly one SHA1. When read, a commit_graft
+Each line contains exactly one SHA-1. When read, a commit_graft
 will be constructed, which has nr_parent < 0 to make it easier
 to discern from user provided grafts.
 
index 5f36f81..e831cc2 100644 (file)
@@ -19,7 +19,7 @@ Further chapters cover more specialized topics.
 
 Comprehensive reference documentation is available through the man
 pages, or linkgit:git-help[1] command.  For example, for the command
-"git clone <repo>", you can either use:
+`git clone <repo>`, you can either use:
 
 ------------------------------------------------
 $ man git-clone
@@ -66,11 +66,11 @@ $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
 The initial clone may be time-consuming for a large project, but you
 will only need to clone once.
 
-The clone command creates a new directory named after the project ("git"
-or "linux-2.6" in the examples above).  After you cd into this
+The clone command creates a new directory named after the project (`git`
+or `linux-2.6` in the examples above).  After you cd into this
 directory, you will see that it contains a copy of the project files,
 called the <<def_working_tree,working tree>>, together with a special
-top-level directory named ".git", which contains all the information
+top-level directory named `.git`, which contains all the information
 about the history of the project.
 
 [[how-to-check-out]]
@@ -188,7 +188,7 @@ As you can see, a commit shows who made the latest change, what they
 did, and why.
 
 Every commit has a 40-hexdigit id, sometimes called the "object name" or the
-"SHA-1 id", shown on the first line of the "git show" output.  You can usually
+"SHA-1 id", shown on the first line of the `git show` output.  You can usually
 refer to a commit by a shorter name, such as a tag or a branch name, but this
 longer name can also be useful.  Most importantly, it is a globally unique
 name for this commit: so if you tell somebody else the object name (for
@@ -268,35 +268,35 @@ Manipulating branches
 Creating, deleting, and modifying branches is quick and easy; here's
 a summary of the commands:
 
-git branch::
+`git branch`::
        list all branches
-git branch <branch>::
-       create a new branch named <branch>, referencing the same
+`git branch <branch>`::
+       create a new branch named `<branch>`, referencing the same
        point in history as the current branch
-git branch <branch> <start-point>::
-       create a new branch named <branch>, referencing
-       <start-point>, which may be specified any way you like,
+`git branch <branch> <start-point>`::
+       create a new branch named `<branch>`, referencing
+       `<start-point>`, which may be specified any way you like,
        including using a branch name or a tag name
-git branch -d <branch>::
-       delete the branch <branch>; if the branch you are deleting
+`git branch -d <branch>`::
+       delete the branch `<branch>`; if the branch you are deleting
        points to a commit which is not reachable from the current
        branch, this command will fail with a warning.
-git branch -D <branch>::
+`git branch -D <branch>`::
        even if the branch points to a commit not reachable
        from the current branch, you may know that that commit
        is still reachable from some other branch or tag.  In that
        case it is safe to use this command to force Git to delete
        the branch.
-git checkout <branch>::
-       make the current branch <branch>, updating the working
-       directory to reflect the version referenced by <branch>
-git checkout -b <new> <start-point>::
-       create a new branch <new> referencing <start-point>, and
+`git checkout <branch>`::
+       make the current branch `<branch>`, updating the working
+       directory to reflect the version referenced by `<branch>`
+`git checkout -b <new> <start-point>`::
+       create a new branch `<new>` referencing `<start-point>`, and
        check it out.
 
 The special symbol "HEAD" can always be used to refer to the current
-branch.  In fact, Git uses a file named "HEAD" in the .git directory to
-remember which branch is current:
+branch.  In fact, Git uses a file named `HEAD` in the `.git` directory
+to remember which branch is current:
 
 ------------------------------------------------
 $ cat .git/HEAD
@@ -346,7 +346,7 @@ of the HEAD in the repository that you cloned from.  That repository
 may also have had other branches, though, and your local repository
 keeps branches which track each of those remote branches, called
 remote-tracking branches, which you
-can view using the "-r" option to linkgit:git-branch[1]:
+can view using the `-r` option to linkgit:git-branch[1]:
 
 ------------------------------------------------
 $ git branch -r
@@ -364,7 +364,7 @@ In this example, "origin" is called a remote repository, or "remote"
 for short. The branches of this repository are called "remote
 branches" from our point of view. The remote-tracking branches listed
 above were created based on the remote branches at clone time and will
-be updated by "git fetch" (hence "git pull") and "git push". See
+be updated by `git fetch` (hence `git pull`) and `git push`. See
 <<Updating-a-repository-With-git-fetch>> for details.
 
 You might want to build on one of these remote-tracking branches
@@ -374,7 +374,7 @@ on a branch of your own, just as you would for a tag:
 $ git checkout -b my-todo-copy origin/todo
 ------------------------------------------------
 
-You can also check out "origin/todo" directly to examine it or
+You can also check out `origin/todo` directly to examine it or
 write a one-off patch.  See <<detached-head,detached head>>.
 
 Note that the name "origin" is just the name that Git uses by default
@@ -386,17 +386,17 @@ Naming branches, tags, and other references
 
 Branches, remote-tracking branches, and tags are all references to
 commits.  All references are named with a slash-separated path name
-starting with "refs"; the names we've been using so far are actually
+starting with `refs`; the names we've been using so far are actually
 shorthand:
 
-       - The branch "test" is short for "refs/heads/test".
-       - The tag "v2.6.18" is short for "refs/tags/v2.6.18".
-       - "origin/master" is short for "refs/remotes/origin/master".
+       - The branch `test` is short for `refs/heads/test`.
+       - The tag `v2.6.18` is short for `refs/tags/v2.6.18`.
+       - `origin/master` is short for `refs/remotes/origin/master`.
 
 The full name is occasionally useful if, for example, there ever
 exists a tag and a branch with the same name.
 
-(Newly created refs are actually stored in the .git/refs directory,
+(Newly created refs are actually stored in the `.git/refs` directory,
 under the path given by their name.  However, for efficiency reasons
 they may also be packed together in a single file; see
 linkgit:git-pack-refs[1]).
@@ -418,7 +418,7 @@ Eventually the developer cloned from will do additional work in her
 repository, creating new commits and advancing the branches to point
 at the new commits.
 
-The command "git fetch", with no arguments, will update all of the
+The command `git fetch`, with no arguments, will update all of the
 remote-tracking branches to the latest version found in her
 repository.  It will not touch any of your own branches--not even the
 "master" branch that was created for you on clone.
@@ -438,7 +438,7 @@ $ git fetch linux-nfs
 -------------------------------------------------
 
 New remote-tracking branches will be stored under the shorthand name
-that you gave "git remote add", in this case linux-nfs:
+that you gave `git remote add`, in this case `linux-nfs`:
 
 -------------------------------------------------
 $ git branch -r
@@ -446,10 +446,10 @@ linux-nfs/master
 origin/master
 -------------------------------------------------
 
-If you run "git fetch <remote>" later, the remote-tracking branches for the
-named <remote> will be updated.
+If you run `git fetch <remote>` later, the remote-tracking branches
+for the named `<remote>` will be updated.
 
-If you examine the file .git/config, you will see that Git has added
+If you examine the file `.git/config`, you will see that Git has added
 a new stanza:
 
 -------------------------------------------------
@@ -462,7 +462,7 @@ $ cat .git/config
 -------------------------------------------------
 
 This is what causes Git to track the remote's branches; you may modify
-or delete these configuration options by editing .git/config with a
+or delete these configuration options by editing `.git/config` with a
 text editor.  (See the "CONFIGURATION FILE" section of
 linkgit:git-config[1] for details.)
 
@@ -499,7 +499,7 @@ Bisecting: 3537 revisions left to test after this
 [65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6]
 -------------------------------------------------
 
-If you run "git branch" at this point, you'll see that Git has
+If you run `git branch` at this point, you'll see that Git has
 temporarily moved you in "(no branch)". HEAD is now detached from any
 branch and points directly to a commit (with commit id 65934...) that
 is reachable from "master" but not from v2.6.18. Compile and test it,
@@ -545,11 +545,11 @@ id, and check it out with:
 $ git reset --hard fb47ddb2db...
 -------------------------------------------------
 
-then test, run "bisect good" or "bisect bad" as appropriate, and
+then test, run `bisect good` or `bisect bad` as appropriate, and
 continue.
 
-Instead of "git bisect visualize" and then "git reset --hard
-fb47ddb2db...", you might just want to tell Git that you want to skip
+Instead of `git bisect visualize` and then `git reset --hard
+fb47ddb2db...`, you might just want to tell Git that you want to skip
 the current commit:
 
 -------------------------------------------------
@@ -561,8 +561,8 @@ bad one between some first skipped commits and a later bad commit.
 
 There are also ways to automate the bisecting process if you have a
 test script that can tell a good from a bad commit. See
-linkgit:git-bisect[1] for more information about this and other "git
-bisect" features.
+linkgit:git-bisect[1] for more information about this and other `git
+bisect` features.
 
 [[naming-commits]]
 Naming commits
@@ -591,7 +591,7 @@ $ git show HEAD~4   # the great-great-grandparent
 -------------------------------------------------
 
 Recall that merge commits may have more than one parent; by default,
-^ and ~ follow the first parent listed in the commit, but you can
+`^` and `~` follow the first parent listed in the commit, but you can
 also choose:
 
 -------------------------------------------------
@@ -640,7 +640,7 @@ running
 $ git tag stable-1 1b2e1d63ff
 -------------------------------------------------
 
-You can use stable-1 to refer to the commit 1b2e1d63ff.
+You can use `stable-1` to refer to the commit 1b2e1d63ff.
 
 This creates a "lightweight" tag.  If you would also like to include a
 comment with the tag, and possibly sign it cryptographically, then you
@@ -669,7 +669,7 @@ $ git log -S'foo()' # commits which add or remove any file data
 -------------------------------------------------
 
 And of course you can combine all of these; the following finds
-commits since v2.5 which touch the Makefile or any file under fs:
+commits since v2.5 which touch the `Makefile` or any file under `fs`:
 
 -------------------------------------------------
 $ git log v2.5.. Makefile fs/
@@ -681,7 +681,7 @@ You can also ask git log to show patches:
 $ git log -p
 -------------------------------------------------
 
-See the "--pretty" option in the linkgit:git-log[1] man page for more
+See the `--pretty` option in the linkgit:git-log[1] man page for more
 display options.
 
 Note that git log starts with the most recent commit and works
@@ -742,8 +742,8 @@ Examples
 Counting the number of commits on a branch
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Suppose you want to know how many commits you've made on "mybranch"
-since it diverged from "origin":
+Suppose you want to know how many commits you've made on `mybranch`
+since it diverged from `origin`:
 
 -------------------------------------------------
 $ git log --pretty=oneline origin..mybranch | wc -l
@@ -780,7 +780,7 @@ $ git rev-list master
 e05db0fd4f31dde7005f075a84f96b360d05984b
 -------------------------------------------------
 
-Or you could recall that the ... operator selects all commits
+Or you could recall that the `...` operator selects all commits
 contained reachable from either one reference or the other but not
 both; so
 
@@ -880,7 +880,7 @@ Showing commits unique to a given branch
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Suppose you would like to see all the commits reachable from the branch
-head named "master" but not from any other head in your repository.
+head named `master` but not from any other head in your repository.
 
 We can list all the heads in this repository with
 linkgit:git-show-ref[1]:
@@ -894,7 +894,7 @@ a07157ac624b2524a059a3414e99f6f44bebc1e7 refs/heads/master
 1e87486ae06626c2f31eaa63d26fc0fd646c8af2 refs/heads/tutorial-fixes
 -------------------------------------------------
 
-We can get just the branch-head names, and remove "master", with
+We can get just the branch-head names, and remove `master`, with
 the help of the standard utilities cut and grep:
 
 -------------------------------------------------
@@ -939,7 +939,7 @@ is preceded by `project/`.  The output file format is inferred from
 the output file extension if possible, see linkgit:git-archive[1] for
 details.
 
-Versions of Git older than 1.7.7 don't know about the 'tar.gz' format,
+Versions of Git older than 1.7.7 don't know about the `tar.gz` format,
 you'll need to use gzip explicitly:
 
 -------------------------------------------------
@@ -1062,7 +1062,7 @@ at step 3, Git maintains a snapshot of the tree's contents in a
 special staging area called "the index."
 
 At the beginning, the content of the index will be identical to
-that of the HEAD.  The command "git diff --cached", which shows
+that of the HEAD.  The command `git diff --cached`, which shows
 the difference between the HEAD and the index, should therefore
 produce no output at that point.
 
@@ -1101,7 +1101,7 @@ $ git diff
 
 shows the difference between the working tree and the index file.
 
-Note that "git add" always adds just the current contents of a file
+Note that `git add` always adds just the current contents of a file
 to the index; further changes to the same file will be ignored unless
 you run `git add` on the file again.
 
@@ -1172,8 +1172,9 @@ annoying to have these untracked files lying around; e.g. they make
 `git add .` practically useless, and they keep showing up in the output of
 `git status`.
 
-You can tell Git to ignore certain files by creating a file called .gitignore
-in the top level of your working directory, with contents such as:
+You can tell Git to ignore certain files by creating a file called
+`.gitignore` in the top level of your working directory, with contents
+such as:
 
 -------------------------------------------------
 # Lines starting with '#' are considered comments.
@@ -1197,10 +1198,10 @@ for other users who clone your repository.
 
 If you wish the exclude patterns to affect only certain repositories
 (instead of every repository for a given project), you may instead put
-them in a file in your repository named .git/info/exclude, or in any file
-specified by the `core.excludesfile` configuration variable.  Some Git
-commands can also take exclude patterns directly on the command line.
-See linkgit:gitignore[5] for the details.
+them in a file in your repository named `.git/info/exclude`, or in any
+file specified by the `core.excludesfile` configuration variable.
+Some Git commands can also take exclude patterns directly on the
+command line.  See linkgit:gitignore[5] for the details.
 
 [[how-to-merge]]
 How to merge
@@ -1213,10 +1214,10 @@ linkgit:git-merge[1]:
 $ git merge branchname
 -------------------------------------------------
 
-merges the development in the branch "branchname" into the current
+merges the development in the branch `branchname` into the current
 branch.
 
-A merge is made by combining the changes made in "branchname" and the
+A merge is made by combining the changes made in `branchname` and the
 changes made up to the latest commit in your current branch since
 their histories forked. The work tree is overwritten by the result of
 the merge when this combining is done cleanly, or overwritten by a
@@ -1338,7 +1339,7 @@ that part is not conflicting and is not shown.  Same for stage 3).
 
 The diff above shows the differences between the working-tree version of
 file.txt and the stage 2 and stage 3 versions.  So instead of preceding
-each line by a single "+" or "-", it now uses two columns: the first
+each line by a single `+` or `-`, it now uses two columns: the first
 column is used for differences between the first parent and the working
 directory copy, and the second for differences between the second parent
 and the working directory copy.  (See the "COMBINED DIFF FORMAT" section
@@ -1613,7 +1614,7 @@ dangling tree b24c2473f1fd3d91352a624795be026d64c8841f
 
 You will see informational messages on dangling objects. They are objects
 that still exist in the repository but are no longer referenced by any of
-your branches, and can (and will) be removed after a while with "gc".
+your branches, and can (and will) be removed after a while with `gc`.
 You can run `git fsck --no-dangling` to suppress these messages, and still
 view real errors.
 
@@ -1625,9 +1626,9 @@ Recovering lost changes
 Reflogs
 ^^^^^^^
 
-Say you modify a branch with +linkgit:git-reset[1] \--hard+, and then
-realize that the branch was the only reference you had to that point in
-history.
+Say you modify a branch with <<fixing-mistakes,`git reset --hard`>>,
+and then realize that the branch was the only reference you had to
+that point in history.
 
 Fortunately, Git also keeps a log, called a "reflog", of all the
 previous values of each branch.  So in this case you can still find the
@@ -1638,8 +1639,8 @@ $ git log master@{1}
 -------------------------------------------------
 
 This lists the commits reachable from the previous version of the
-"master" branch head.  This syntax can be used with any Git command
-that accepts a commit, not just with git log.  Some other examples:
+`master` branch head.  This syntax can be used with any Git command
+that accepts a commit, not just with `git log`.  Some other examples:
 
 -------------------------------------------------
 $ git show master@{2}          # See where the branch pointed 2,
@@ -1743,8 +1744,8 @@ one step:
 $ git pull origin master
 -------------------------------------------------
 
-In fact, if you have "master" checked out, then this branch has been
-configured by "git clone" to get changes from the HEAD branch of the
+In fact, if you have `master` checked out, then this branch has been
+configured by `git clone` to get changes from the HEAD branch of the
 origin repository.  So often you can
 accomplish the above with just a simple
 
@@ -1759,11 +1760,11 @@ the current branch.
 More generally, a branch that is created from a remote-tracking branch
 will pull
 by default from that branch.  See the descriptions of the
-branch.<name>.remote and branch.<name>.merge options in
+`branch.<name>.remote` and `branch.<name>.merge` options in
 linkgit:git-config[1], and the discussion of the `--track` option in
 linkgit:git-checkout[1], to learn how to control these defaults.
 
-In addition to saving you keystrokes, "git pull" also helps you by
+In addition to saving you keystrokes, `git pull` also helps you by
 producing a default commit message documenting the branch and
 repository that you pulled from.
 
@@ -1771,7 +1772,7 @@ repository that you pulled from.
 <<fast-forwards,fast-forward>>; instead, your branch will just be
 updated to point to the latest commit from the upstream branch.)
 
-The `git pull` command can also be given "." as the "remote" repository,
+The `git pull` command can also be given `.` as the "remote" repository,
 in which case it just merges in a branch from the current repository; so
 the commands
 
@@ -1796,7 +1797,7 @@ $ git format-patch origin
 -------------------------------------------------
 
 will produce a numbered series of files in the current directory, one
-for each patch in the current branch but not in origin/HEAD.
+for each patch in the current branch but not in `origin/HEAD`.
 
 `git format-patch` can include an initial "cover letter". You can insert
 commentary on individual patches after the three dash line which
@@ -1818,7 +1819,7 @@ Importing patches to a project
 Git also provides a tool called linkgit:git-am[1] (am stands for
 "apply mailbox"), for importing such an emailed series of patches.
 Just save all of the patch-containing messages, in order, into a
-single mailbox file, say "patches.mbox", then run
+single mailbox file, say `patches.mbox`, then run
 
 -------------------------------------------------
 $ git am -3 patches.mbox
@@ -1826,7 +1827,7 @@ $ git am -3 patches.mbox
 
 Git will apply each patch in order; if any conflicts are found, it
 will stop, and you can fix the conflicts as described in
-"<<resolving-a-merge,Resolving a merge>>".  (The "-3" option tells
+"<<resolving-a-merge,Resolving a merge>>".  (The `-3` option tells
 Git to perform a merge; if you would prefer it just to abort and
 leave your tree and index untouched, you may omit that option.)
 
@@ -1902,7 +1903,7 @@ We explain how to do this in the following sections.
 Setting up a public repository
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Assume your personal repository is in the directory ~/proj.  We
+Assume your personal repository is in the directory `~/proj`.  We
 first create a new clone of the repository and tell `git daemon` that it
 is meant to be public:
 
@@ -1912,10 +1913,10 @@ $ touch proj.git/git-daemon-export-ok
 -------------------------------------------------
 
 The resulting directory proj.git contains a "bare" git repository--it is
-just the contents of the ".git" directory, without any files checked out
+just the contents of the `.git` directory, without any files checked out
 around it.
 
-Next, copy proj.git to the server where you plan to host the
+Next, copy `proj.git` to the server where you plan to host the
 public repository.  You can use scp, rsync, or whatever is most
 convenient.
 
@@ -1926,8 +1927,8 @@ Exporting a Git repository via the Git protocol
 This is the preferred method.
 
 If someone else administers the server, they should tell you what
-directory to put the repository in, and what git:// URL it will appear
-at.  You can then skip to the section
+directory to put the repository in, and what `git://` URL it will
+appear at.  You can then skip to the section
 "<<pushing-changes-to-a-public-repository,Pushing changes to a public
 repository>>", below.
 
@@ -1962,7 +1963,7 @@ $ mv hooks/post-update.sample hooks/post-update
 (For an explanation of the last two lines, see
 linkgit:git-update-server-info[1] and linkgit:githooks[5].)
 
-Advertise the URL of proj.git.  Anybody else should then be able to
+Advertise the URL of `proj.git`.  Anybody else should then be able to
 clone or pull from that URL, for example with a command line like:
 
 -------------------------------------------------
@@ -1985,8 +1986,8 @@ access, which you will need to update the public repository with the
 latest changes created in your private repository.
 
 The simplest way to do this is using linkgit:git-push[1] and ssh; to
-update the remote branch named "master" with the latest state of your
-branch named "master", run
+update the remote branch named `master` with the latest state of your
+branch named `master`, run
 
 -------------------------------------------------
 $ git push ssh://yourserver.com/~you/proj.git master:master
@@ -2002,7 +2003,7 @@ As with `git fetch`, `git push` will complain if this does not result in a
 <<fast-forwards,fast-forward>>; see the following section for details on
 handling this case.
 
-Note that the target of a "push" is normally a
+Note that the target of a `push` is normally a
 <<def_bare_repository,bare>> repository.  You can also push to a
 repository that has a checked-out working tree, but a push to update the
 currently checked-out branch is denied by default to prevent confusion.
@@ -2030,9 +2031,9 @@ which lets you do the same push with just
 $ git push public-repo master
 -------------------------------------------------
 
-See the explanations of the remote.<name>.url, branch.<name>.remote,
-and remote.<name>.push options in linkgit:git-config[1] for
-details.
+See the explanations of the `remote.<name>.url`,
+`branch.<name>.remote`, and `remote.<name>.push` options in
+linkgit:git-config[1] for details.
 
 [[forcing-push]]
 What to do when a push fails
@@ -2167,7 +2168,7 @@ linkgit:git-fetch[1] to keep them up-to-date; see
 
 Now create the branches in which you are going to work; these start out
 at the current tip of origin/master branch, and should be set up (using
-the --track option to linkgit:git-branch[1]) to merge changes in from
+the `--track` option to linkgit:git-branch[1]) to merge changes in from
 Linus by default.
 
 -------------------------------------------------
@@ -2186,7 +2187,7 @@ Important note!  If you have any local changes in these branches, then
 this merge will create a commit object in the history (with no local
 changes Git will simply do a "fast-forward" merge).  Many people dislike
 the "noise" that this creates in the Linux history, so you should avoid
-doing this capriciously in the "release" branch, as these noisy commits
+doing this capriciously in the `release` branch, as these noisy commits
 will become part of the permanent history when you ask Linus to pull
 from the release branch.
 
@@ -2228,7 +2229,7 @@ patches), and create a new branch from a recent stable tag of
 Linus's branch. Picking a stable base for your branch will:
 1) help you: by avoiding inclusion of unrelated and perhaps lightly
 tested changes
-2) help future bug hunters that use "git bisect" to find problems
+2) help future bug hunters that use `git bisect` to find problems
 
 -------------------------------------------------
 $ git checkout -b speed-up-spinlocks v2.6.35
@@ -2253,9 +2254,9 @@ It is unlikely that you would have any conflicts here ... but you might if you
 spent a while on this step and had also pulled new versions from upstream.
 
 Some time later when enough time has passed and testing done, you can pull the
-same branch into the "release" tree ready to go upstream.  This is where you
+same branch into the `release` tree ready to go upstream.  This is where you
 see the value of keeping each patch (or patch series) in its own branch.  It
-means that the patches can be moved into the "release" tree in any order.
+means that the patches can be moved into the `release` tree in any order.
 
 -------------------------------------------------
 $ git checkout release && git pull . speed-up-spinlocks
@@ -2288,7 +2289,7 @@ If it has been merged, then there will be no output.)
 
 Once a patch completes the great cycle (moving from test to release,
 then pulled by Linus, and finally coming back into your local
-"origin/master" branch), the branch for this change is no longer needed.
+`origin/master` branch), the branch for this change is no longer needed.
 You detect this when the output from:
 
 -------------------------------------------------
@@ -2303,8 +2304,8 @@ $ git branch -d branchname
 
 Some changes are so trivial that it is not necessary to create a separate
 branch and then merge into each of the test and release branches.  For
-these changes, just apply directly to the "release" branch, and then
-merge that into the "test" branch.
+these changes, just apply directly to the `release` branch, and then
+merge that into the `test` branch.
 
 After pushing your work to `mytree`, you can use
 linkgit:git-request-pull[1] to prepare a "please pull" request message
@@ -2337,7 +2338,7 @@ origin)
        fi
        ;;
 *)
-       echo "Usage: $0 origin|test|release" 1>&2
+       echo "usage: $0 origin|test|release" 1>&2
        exit 1
        ;;
 esac
@@ -2351,7 +2352,7 @@ pname=$0
 
 usage()
 {
-       echo "Usage: $pname branch test|release" 1>&2
+       echo "usage: $pname branch test|release" 1>&2
        exit 1
 }
 
@@ -2475,8 +2476,8 @@ you are rewriting history.
 Keeping a patch series up to date using git rebase
 --------------------------------------------------
 
-Suppose that you create a branch "mywork" on a remote-tracking branch
-"origin", and create some commits on top of it:
+Suppose that you create a branch `mywork` on a remote-tracking branch
+`origin`, and create some commits on top of it:
 
 -------------------------------------------------
 $ git checkout -b mywork origin
@@ -2488,7 +2489,7 @@ $ git commit
 -------------------------------------------------
 
 You have performed no merges into mywork, so it is just a simple linear
-sequence of patches on top of "origin":
+sequence of patches on top of `origin`:
 
 ................................................
  o--o--O <-- origin
@@ -2497,7 +2498,7 @@ sequence of patches on top of "origin":
 ................................................
 
 Some more interesting work has been done in the upstream project, and
-"origin" has advanced:
+`origin` has advanced:
 
 ................................................
  o--o--O--o--o--o <-- origin
@@ -2505,7 +2506,7 @@ Some more interesting work has been done in the upstream project, and
          a--b--c <-- mywork
 ................................................
 
-At this point, you could use "pull" to merge your changes back in;
+At this point, you could use `pull` to merge your changes back in;
 the result would create a new merge commit, like this:
 
 ................................................
@@ -2524,7 +2525,7 @@ $ git rebase origin
 -------------------------------------------------
 
 This will remove each of your commits from mywork, temporarily saving
-them as patches (in a directory named ".git/rebase-apply"), update mywork to
+them as patches (in a directory named `.git/rebase-apply`), update mywork to
 point at the latest version of origin, then apply each of the saved
 patches to the new mywork.  The result will look like:
 
@@ -2795,10 +2796,10 @@ arbitrary name:
 $ git fetch origin todo:my-todo-work
 -------------------------------------------------
 
-The first argument, "origin", just tells Git to fetch from the
+The first argument, `origin`, just tells Git to fetch from the
 repository you originally cloned from.  The second argument tells Git
-to fetch the branch named "todo" from the remote repository, and to
-store it locally under the name refs/heads/my-todo-work.
+to fetch the branch named `todo` from the remote repository, and to
+store it locally under the name `refs/heads/my-todo-work`.
 
 You can also fetch branches from other repositories; so
 
@@ -2806,8 +2807,8 @@ You can also fetch branches from other repositories; so
 $ git fetch git://example.com/proj.git master:example-master
 -------------------------------------------------
 
-will create a new branch named "example-master" and store in it the
-branch named "master" from the repository at the given URL.  If you
+will create a new branch named `example-master` and store in it the
+branch named `master` from the repository at the given URL.  If you
 already have a branch named example-master, it will attempt to
 <<fast-forwards,fast-forward>> to the commit given by example.com's
 master branch.  In more detail:
@@ -2816,7 +2817,7 @@ master branch.  In more detail:
 git fetch and fast-forwards
 ---------------------------
 
-In the previous example, when updating an existing branch, "git fetch"
+In the previous example, when updating an existing branch, `git fetch`
 checks to make sure that the most recent commit on the remote
 branch is a descendant of the most recent commit on your copy of the
 branch before updating your copy of the branch to point at the new
@@ -2842,11 +2843,11 @@ resulting in a situation like:
             o--o--o <-- new head of the branch
 ................................................
 
-In this case, "git fetch" will fail, and print out a warning.
+In this case, `git fetch` will fail, and print out a warning.
 
 In that case, you can still force Git to update to the new head, as
 described in the following section.  However, note that in the
-situation above this may mean losing the commits labeled "a" and "b",
+situation above this may mean losing the commits labeled `a` and `b`,
 unless you've already created a reference of your own pointing to
 them.
 
@@ -2861,7 +2862,7 @@ descendant of the old head, you may force the update with:
 $ git fetch git://example.com/proj.git +master:refs/remotes/example/master
 -------------------------------------------------
 
-Note the addition of the "+" sign.  Alternatively, you can use the "-f"
+Note the addition of the `+` sign.  Alternatively, you can use the `-f`
 flag to force updates of all the fetched branches, as in:
 
 -------------------------------------------------
@@ -2875,7 +2876,7 @@ may be lost, as we saw in the previous section.
 Configuring remote-tracking branches
 ------------------------------------
 
-We saw above that "origin" is just a shortcut to refer to the
+We saw above that `origin` is just a shortcut to refer to the
 repository that you originally cloned from.  This information is
 stored in Git configuration variables, which you can see using
 linkgit:git-config[1]:
@@ -2984,7 +2985,7 @@ Commit Object
 ~~~~~~~~~~~~~
 
 The "commit" object links a physical state of a tree with a description
-of how we got there and why.  Use the --pretty=raw option to
+of how we got there and why.  Use the `--pretty=raw` option to
 linkgit:git-show[1] or linkgit:git-log[1] to examine your favorite
 commit:
 
@@ -3026,7 +3027,7 @@ of the tree referred to by this commit with the trees associated with
 its parents.  In particular, Git does not attempt to record file renames
 explicitly, though it can identify cases where the existence of the same
 file data at changing paths suggests a rename.  (See, for example, the
--M option to linkgit:git-diff[1]).
+`-M` option to linkgit:git-diff[1]).
 
 A commit is usually created by linkgit:git-commit[1], which creates a
 commit whose parent is normally the current HEAD, and whose tree is
@@ -3077,7 +3078,7 @@ Blob Object
 ~~~~~~~~~~~
 
 You can use linkgit:git-show[1] to examine the contents of a blob; take,
-for example, the blob in the entry for "COPYING" from the tree above:
+for example, the blob in the entry for `COPYING` from the tree above:
 
 ------------------------------------------------
 $ git show 6ff87c4664
@@ -3160,14 +3161,14 @@ nLE/L9aUXdWeTFPron96DLA=
 See the linkgit:git-tag[1] command to learn how to create and verify tag
 objects.  (Note that linkgit:git-tag[1] can also be used to create
 "lightweight tags", which are not tag objects at all, but just simple
-references whose names begin with "refs/tags/").
+references whose names begin with `refs/tags/`).
 
 [[pack-files]]
 How Git stores objects efficiently: pack files
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Newly created objects are initially created in a file named after the
-object's SHA-1 hash (stored in .git/objects).
+object's SHA-1 hash (stored in `.git/objects`).
 
 Unfortunately this system becomes inefficient once a project has a
 lot of objects.  Try this on an old project:
@@ -3208,9 +3209,9 @@ $ git prune
 
 to remove any of the "loose" objects that are now contained in the
 pack.  This will also remove any unreferenced objects (which may be
-created when, for example, you use "git reset" to remove a commit).
+created when, for example, you use `git reset` to remove a commit).
 You can verify that the loose objects are gone by looking at the
-.git/objects directory or by running
+`.git/objects` directory or by running
 
 ------------------------------------------------
 $ git count-objects
@@ -3237,7 +3238,7 @@ branch still exists, as does everything it pointed to. The branch
 pointer itself just doesn't, since you replaced it with another one.
 
 There are also other situations that cause dangling objects. For
-example, a "dangling blob" may arise because you did a "git add" of a
+example, a "dangling blob" may arise because you did a `git add` of a
 file, but then, before you actually committed it and made it part of the
 bigger picture, you changed something else in that file and committed
 that *updated* thing--the old state that you added originally ends up
@@ -3280,14 +3281,14 @@ $ 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
+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,
+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.
 
@@ -3298,16 +3299,16 @@ 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
+and they'll be gone. But you should only run `git prune` on a quiescent
 repository--it's kind of like doing a filesystem fsck recovery: you
 don't want to do that while the filesystem is mounted.
 
-(The same is true of "git fsck" itself, btw, but since
+(The same is true of `git fsck` itself, btw, but since
 `git fsck` never actually *changes* the repository, it just reports
 on what it found, `git fsck` itself is never 'dangerous' to run.
 Running it while somebody is actually changing the repository can cause
 confusing and scary messages, but it won't actually do anything bad. In
-contrast, running "git prune" while somebody is actively changing the
+contrast, running `git prune` while somebody is actively changing the
 repository is a *BAD* idea).
 
 [[recovering-from-repository-corruption]]
@@ -3345,7 +3346,7 @@ missing blob 4b9458b3786228369c63936db65827de3cc06200
 Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6
 points to it.  If you could find just one copy of that missing blob
 object, possibly in some other repository, you could move it into
-.git/objects/4b/9458b3... and be done.  Suppose you can't.  You can
+`.git/objects/4b/9458b3...` and be done.  Suppose you can't.  You can
 still examine the tree that pointed to it with linkgit:git-ls-tree[1],
 which might output something like:
 
@@ -3360,10 +3361,10 @@ $ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
 ------------------------------------------------
 
 So now you know that the missing blob was the data for a file named
-"myfile".  And chances are you can also identify the directory--let's
-say it's in "somedirectory".  If you're lucky the missing copy might be
+`myfile`.  And chances are you can also identify the directory--let's
+say it's in `somedirectory`.  If you're lucky the missing copy might be
 the same as the copy you have checked out in your working tree at
-"somedirectory/myfile"; you can test whether that's right with
+`somedirectory/myfile`; you can test whether that's right with
 linkgit:git-hash-object[1]:
 
 ------------------------------------------------
@@ -3418,7 +3419,7 @@ $ git hash-object -w <recreated-file>
 
 and your repository is good again!
 
-(Btw, you could have ignored the fsck, and started with doing a
+(Btw, you could have ignored the `fsck`, and started with doing a
 
 ------------------------------------------------
 $ git log --raw --all
@@ -3432,7 +3433,7 @@ just missing one particular blob version.
 The index
 -----------
 
-The index is a binary file (generally kept in .git/index) containing a
+The index is a binary file (generally kept in `.git/index`) containing a
 sorted list of path names, each with permissions and the SHA-1 of a blob
 object; linkgit:git-ls-files[1] can show you the contents of the index:
 
@@ -3572,7 +3573,7 @@ $ ls -a
 
 The `git submodule add <repo> <path>` command does a couple of things:
 
-- It clones the submodule from <repo> to the given <path> under the
+- It clones the submodule from `<repo>` to the given `<path>` under the
   current directory and by default checks out the master branch.
 - It adds the submodule's clone path to the linkgit:gitmodules[5] file and
   adds this file to the index, ready to be committed.
@@ -3700,11 +3701,11 @@ Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path
 
 In older Git versions it could be easily forgotten to commit new or modified
 files in a submodule, which silently leads to similar problems as not pushing
-the submodule changes. Starting with Git 1.7.0 both "git status" and "git diff"
+the submodule changes. Starting with Git 1.7.0 both `git status` and `git diff`
 in the superproject show submodules as modified when they contain new or
-modified files to protect against accidentally committing such a state. "git
-diff" will also add a "-dirty" to the work tree side when generating patch
-output or used with the --submodule option:
+modified files to protect against accidentally committing such a state. `git
+diff` will also add a `-dirty` to the work tree side when generating patch
+output or used with the `--submodule` option:
 
 -------------------------------------------------
 $ git diff
@@ -3880,7 +3881,7 @@ 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
+need to use the `-f` flag ('before' the `-a` flag or the filename) to
 'force' the checkout.
 
 
@@ -3891,7 +3892,7 @@ from one representation to the other:
 Tying it all together
 ~~~~~~~~~~~~~~~~~~~~~
 
-To commit a tree you have instantiated with "git write-tree", you'd
+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.
@@ -4152,8 +4153,9 @@ As a result, the general consistency of an object can always be tested
 independently of the contents or the type of the object: all objects can
 be validated by verifying that (a) their hashes match the content of the
 file and (b) the object successfully inflates to a stream of bytes that
-forms a sequence of <ascii type without space> {plus} <space> {plus} <ascii decimal
-size> {plus} <byte\0> {plus} <binary object data>.
+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
@@ -4632,10 +4634,10 @@ Think about how to create a clear chapter dependency graph that will
 allow people to get to important topics without necessarily reading
 everything in between.
 
-Scan Documentation/ for other stuff left out; in particular:
+Scan `Documentation/` for other stuff left out; in particular:
 
 - howto's
-- some of technical/?
+- some of `technical/`?
 - hooks
 - list of commands in linkgit:git[1]
 
index f189b78..293d0b9 100755 (executable)
@@ -1,7 +1,7 @@
 #!/bin/sh
 
 GVF=GIT-VERSION-FILE
-DEF_VER=v1.8.2
+DEF_VER=v1.8.3-rc0
 
 LF='
 '
diff --git a/INSTALL b/INSTALL
index 2dc3b61..ba01e74 100644 (file)
--- a/INSTALL
+++ b/INSTALL
@@ -101,7 +101,7 @@ Issues of note:
        - "openssl" library is used by git-imap-send to use IMAP over SSL.
          If you don't need it, use NO_OPENSSL.
 
-         By default, git uses OpenSSL for SHA1 but it will use it's own
+         By default, git uses OpenSSL for SHA1 but it will use its own
          library (inspired by Mozilla's) with either NO_OPENSSL or
          BLK_SHA1.  Also included is a version optimized for PowerPC
          (PPC_SHA1).
index 26d3332..0f931a2 100644 (file)
--- a/Makefile
+++ b/Makefile
@@ -358,33 +358,39 @@ STRIP ?= strip
 # Among the variables below, these:
 #   gitexecdir
 #   template_dir
-#   mandir
-#   infodir
-#   htmldir
 #   sysconfdir
 # can be specified as a relative path some/where/else;
 # this is interpreted as relative to $(prefix) and "git" at
 # runtime figures out where they are based on the path to the executable.
+# Additionally, the following will be treated as relative by "git" if they
+# begin with "$(prefix)/":
+#   mandir
+#   infodir
+#   htmldir
 # This can help installing the suite in a relocatable way.
 
 prefix = $(HOME)
 bindir_relative = bin
 bindir = $(prefix)/$(bindir_relative)
-mandir = share/man
-infodir = share/info
+mandir = $(prefix)/share/man
+infodir = $(prefix)/share/info
 gitexecdir = libexec/git-core
 mergetoolsdir = $(gitexecdir)/mergetools
 sharedir = $(prefix)/share
 gitwebdir = $(sharedir)/gitweb
 localedir = $(sharedir)/locale
 template_dir = share/git-core/templates
-htmldir = share/doc/git-doc
+htmldir = $(prefix)/share/doc/git-doc
 ETC_GITCONFIG = $(sysconfdir)/gitconfig
 ETC_GITATTRIBUTES = $(sysconfdir)/gitattributes
 lib = lib
 # DESTDIR =
 pathsep = :
 
+mandir_relative = $(patsubst $(prefix)/%,%,$(mandir))
+infodir_relative = $(patsubst $(prefix)/%,%,$(infodir))
+htmldir_relative = $(patsubst $(prefix)/%,%,$(htmldir))
+
 export prefix bindir sharedir sysconfdir gitwebdir localedir
 
 CC = cc
@@ -617,22 +623,6 @@ LIB_FILE = libgit.a
 XDIFF_LIB = xdiff/lib.a
 VCSSVN_LIB = vcs-svn/lib.a
 
-LIB_H += xdiff/xinclude.h
-LIB_H += xdiff/xmacros.h
-LIB_H += xdiff/xdiff.h
-LIB_H += xdiff/xtypes.h
-LIB_H += xdiff/xutils.h
-LIB_H += xdiff/xprepare.h
-LIB_H += xdiff/xdiffi.h
-LIB_H += xdiff/xemit.h
-
-LIB_H += vcs-svn/line_buffer.h
-LIB_H += vcs-svn/sliding_window.h
-LIB_H += vcs-svn/repo_tree.h
-LIB_H += vcs-svn/fast_export.h
-LIB_H += vcs-svn/svndiff.h
-LIB_H += vcs-svn/svndump.h
-
 GENERATED_H += common-cmds.h
 
 LIB_H += advice.h
@@ -734,11 +724,24 @@ LIB_H += url.h
 LIB_H += userdiff.h
 LIB_H += utf8.h
 LIB_H += varint.h
+LIB_H += vcs-svn/fast_export.h
+LIB_H += vcs-svn/line_buffer.h
+LIB_H += vcs-svn/repo_tree.h
+LIB_H += vcs-svn/sliding_window.h
+LIB_H += vcs-svn/svndiff.h
+LIB_H += vcs-svn/svndump.h
 LIB_H += walker.h
 LIB_H += wildmatch.h
 LIB_H += wt-status.h
 LIB_H += xdiff-interface.h
 LIB_H += xdiff/xdiff.h
+LIB_H += xdiff/xdiffi.h
+LIB_H += xdiff/xemit.h
+LIB_H += xdiff/xinclude.h
+LIB_H += xdiff/xmacros.h
+LIB_H += xdiff/xprepare.h
+LIB_H += xdiff/xtypes.h
+LIB_H += xdiff/xutils.h
 
 LIB_OBJS += abspath.o
 LIB_OBJS += advice.o
@@ -1542,12 +1545,12 @@ ETC_GITATTRIBUTES_SQ = $(subst ','\'',$(ETC_GITATTRIBUTES))
 DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
 bindir_SQ = $(subst ','\'',$(bindir))
 bindir_relative_SQ = $(subst ','\'',$(bindir_relative))
-mandir_SQ = $(subst ','\'',$(mandir))
-infodir_SQ = $(subst ','\'',$(infodir))
+mandir_relative_SQ = $(subst ','\'',$(mandir_relative))
+infodir_relative_SQ = $(subst ','\'',$(infodir_relative))
 localedir_SQ = $(subst ','\'',$(localedir))
 gitexecdir_SQ = $(subst ','\'',$(gitexecdir))
 template_dir_SQ = $(subst ','\'',$(template_dir))
-htmldir_SQ = $(subst ','\'',$(htmldir))
+htmldir_relative_SQ = $(subst ','\'',$(htmldir_relative))
 prefix_SQ = $(subst ','\'',$(prefix))
 gitwebdir_SQ = $(subst ','\'',$(gitwebdir))
 
@@ -1679,9 +1682,9 @@ strip: $(PROGRAMS) git$X
 
 git.sp git.s git.o: GIT-PREFIX
 git.sp git.s git.o: EXTRA_CPPFLAGS = \
-       '-DGIT_HTML_PATH="$(htmldir_SQ)"' \
-       '-DGIT_MAN_PATH="$(mandir_SQ)"' \
-       '-DGIT_INFO_PATH="$(infodir_SQ)"'
+       '-DGIT_HTML_PATH="$(htmldir_relative_SQ)"' \
+       '-DGIT_MAN_PATH="$(mandir_relative_SQ)"' \
+       '-DGIT_INFO_PATH="$(infodir_relative_SQ)"'
 
 git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS)
        $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
@@ -1691,9 +1694,9 @@ help.sp help.s help.o: common-cmds.h
 
 builtin/help.sp builtin/help.s builtin/help.o: common-cmds.h GIT-PREFIX
 builtin/help.sp builtin/help.s builtin/help.o: EXTRA_CPPFLAGS = \
-       '-DGIT_HTML_PATH="$(htmldir_SQ)"' \
-       '-DGIT_MAN_PATH="$(mandir_SQ)"' \
-       '-DGIT_INFO_PATH="$(infodir_SQ)"'
+       '-DGIT_HTML_PATH="$(htmldir_relative_SQ)"' \
+       '-DGIT_MAN_PATH="$(mandir_relative_SQ)"' \
+       '-DGIT_INFO_PATH="$(infodir_relative_SQ)"'
 
 version.sp version.s version.o: GIT-VERSION-FILE GIT-USER-AGENT
 version.sp version.s version.o: EXTRA_CPPFLAGS = \
index bdce313..80b7e38 120000 (symlink)
--- a/RelNotes
+++ b/RelNotes
@@ -1 +1 @@
-Documentation/RelNotes/1.8.2.txt
\ No newline at end of file
+Documentation/RelNotes/1.8.3.txt
\ No newline at end of file
index 780f58d..a8deee6 100644 (file)
--- a/advice.c
+++ b/advice.c
@@ -8,10 +8,12 @@ int advice_push_already_exists = 1;
 int advice_push_fetch_first = 1;
 int advice_push_needs_force = 1;
 int advice_status_hints = 1;
+int advice_status_u_option = 1;
 int advice_commit_before_merge = 1;
 int advice_resolve_conflict = 1;
 int advice_implicit_identity = 1;
 int advice_detached_head = 1;
+int advice_set_upstream_failure = 1;
 
 static struct {
        const char *name;
@@ -25,10 +27,12 @@ static struct {
        { "pushfetchfirst", &advice_push_fetch_first },
        { "pushneedsforce", &advice_push_needs_force },
        { "statushints", &advice_status_hints },
+       { "statusuoption", &advice_status_u_option },
        { "commitbeforemerge", &advice_commit_before_merge },
        { "resolveconflict", &advice_resolve_conflict },
        { "implicitidentity", &advice_implicit_identity },
        { "detachedhead", &advice_detached_head },
+       { "setupstreamfailure", &advice_set_upstream_failure },
 
        /* make this an alias for backward compatibility */
        { "pushnonfastforward", &advice_push_update_rejected }
index fad36df..94caa32 100644 (file)
--- a/advice.h
+++ b/advice.h
@@ -11,10 +11,12 @@ extern int advice_push_already_exists;
 extern int advice_push_fetch_first;
 extern int advice_push_needs_force;
 extern int advice_status_hints;
+extern int advice_status_u_option;
 extern int advice_commit_before_merge;
 extern int advice_resolve_conflict;
 extern int advice_implicit_identity;
 extern int advice_detached_head;
+extern int advice_set_upstream_failure;
 
 int git_default_advice_config(const char *var, const char *value);
 void advise(const char *advice, ...);
index d3aef53..b2c4fe0 100644 (file)
@@ -111,8 +111,9 @@ static void copy_le32(unsigned char *dest, unsigned int n)
        dest[3] = 0xff & (n >> 030);
 }
 
-static void *zlib_deflate(void *data, unsigned long size,
-               int compression_level, unsigned long *compressed_size)
+static void *zlib_deflate_raw(void *data, unsigned long size,
+                             int compression_level,
+                             unsigned long *compressed_size)
 {
        git_zstream stream;
        unsigned long maxsize;
@@ -120,7 +121,7 @@ static void *zlib_deflate(void *data, unsigned long size,
        int result;
 
        memset(&stream, 0, sizeof(stream));
-       git_deflate_init(&stream, compression_level);
+       git_deflate_init_raw(&stream, compression_level);
        maxsize = git_deflate_bound(&stream, size);
        buffer = xmalloc(maxsize);
 
@@ -240,7 +241,6 @@ static int write_zip_entry(struct archiver_args *args,
                        (mode & 0111) ? ((mode) << 16) : 0;
                if (S_ISREG(mode) && args->compression_level != 0 && size > 0)
                        method = 8;
-               compressed_size = (method == 0) ? size : 0;
 
                if (S_ISREG(mode) && type == OBJ_BLOB && !args->convert &&
                    size > big_file_threshold) {
@@ -259,20 +259,18 @@ static int write_zip_entry(struct archiver_args *args,
                        crc = crc32(crc, buffer, size);
                        out = buffer;
                }
+               compressed_size = (method == 0) ? size : 0;
        } else {
                return error("unsupported file mode: 0%o (SHA1: %s)", mode,
                                sha1_to_hex(sha1));
        }
 
        if (buffer && method == 8) {
-               deflated = zlib_deflate(buffer, size, args->compression_level,
-                               &compressed_size);
-               if (deflated && compressed_size - 6 < size) {
-                       /* ZLIB --> raw compressed data (see RFC 1950) */
-                       /* CMF and FLG ... */
-                       out = (unsigned char *)deflated + 2;
-                       compressed_size -= 6;   /* ... and ADLER32 */
-               } else {
+               out = deflated = zlib_deflate_raw(buffer, size,
+                                                 args->compression_level,
+                                                 &compressed_size);
+               if (!out || compressed_size >= size) {
+                       out = buffer;
                        method = 0;
                        compressed_size = size;
                }
@@ -353,7 +351,7 @@ static int write_zip_entry(struct archiver_args *args,
                unsigned char compressed[STREAM_BUFFER_SIZE * 2];
 
                memset(&zstream, 0, sizeof(zstream));
-               git_deflate_init(&zstream, args->compression_level);
+               git_deflate_init_raw(&zstream, args->compression_level);
 
                compressed_size = 0;
                zstream.next_out = compressed;
@@ -370,13 +368,10 @@ static int write_zip_entry(struct archiver_args *args,
                        result = git_deflate(&zstream, 0);
                        if (result != Z_OK)
                                die("deflate error (%d)", result);
-                       out = compressed;
-                       if (!compressed_size)
-                               out += 2;
-                       out_len = zstream.next_out - out;
+                       out_len = zstream.next_out - compressed;
 
                        if (out_len > 0) {
-                               write_or_die(1, out, out_len);
+                               write_or_die(1, compressed, out_len);
                                compressed_size += out_len;
                                zstream.next_out = compressed;
                                zstream.avail_out = sizeof(compressed);
@@ -394,11 +389,8 @@ static int write_zip_entry(struct archiver_args *args,
                        die("deflate error (%d)", result);
 
                git_deflate_end(&zstream);
-               out = compressed;
-               if (!compressed_size)
-                       out += 2;
-               out_len = zstream.next_out - out - 4;
-               write_or_die(1, out, out_len);
+               out_len = zstream.next_out - compressed;
+               write_or_die(1, compressed, out_len);
                compressed_size += out_len;
                zip_offset += compressed_size;
 
index 93e00bb..d254fa5 100644 (file)
--- a/archive.c
+++ b/archive.c
@@ -234,7 +234,7 @@ static void parse_pathspec_arg(const char **pathspec,
        ar_args->pathspec = pathspec = get_pathspec("", pathspec);
        if (pathspec) {
                while (*pathspec) {
-                       if (!path_exists(ar_args->tree, *pathspec))
+                       if (**pathspec && !path_exists(ar_args->tree, *pathspec))
                                die("path not found: %s", *pathspec);
                        pathspec++;
                }
diff --git a/attr.c b/attr.c
index e2f9377..0e774c6 100644 (file)
--- a/attr.c
+++ b/attr.c
@@ -381,46 +381,13 @@ static struct attr_stack *read_attr_from_file(const char *path, int macro_ok)
        return res;
 }
 
-static void *read_index_data(const char *path)
-{
-       int pos, len;
-       unsigned long sz;
-       enum object_type type;
-       void *data;
-       struct index_state *istate = use_index ? use_index : &the_index;
-
-       len = strlen(path);
-       pos = index_name_pos(istate, path, len);
-       if (pos < 0) {
-               /*
-                * We might be in the middle of a merge, in which
-                * case we would read stage #2 (ours).
-                */
-               int i;
-               for (i = -pos - 1;
-                    (pos < 0 && i < istate->cache_nr &&
-                     !strcmp(istate->cache[i]->name, path));
-                    i++)
-                       if (ce_stage(istate->cache[i]) == 2)
-                               pos = i;
-       }
-       if (pos < 0)
-               return NULL;
-       data = read_sha1_file(istate->cache[pos]->sha1, &type, &sz);
-       if (!data || type != OBJ_BLOB) {
-               free(data);
-               return NULL;
-       }
-       return data;
-}
-
 static struct attr_stack *read_attr_from_index(const char *path, int macro_ok)
 {
        struct attr_stack *res;
        char *buf, *sp;
        int lineno = 0;
 
-       buf = read_index_data(path);
+       buf = read_blob_data_from_index(use_index ? use_index : &the_index, path, NULL);
        if (!buf)
                return NULL;
 
@@ -657,24 +624,24 @@ static void prepare_attr_stack(const char *path, int dirlen)
 }
 
 static int path_matches(const char *pathname, int pathlen,
-                       const char *basename,
+                       int basename_offset,
                        const struct pattern *pat,
                        const char *base, int baselen)
 {
        const char *pattern = pat->pattern;
        int prefix = pat->nowildcardlen;
+       int isdir = (pathlen && pathname[pathlen - 1] == '/');
 
-       if ((pat->flags & EXC_FLAG_MUSTBEDIR) &&
-           ((!pathlen) || (pathname[pathlen-1] != '/')))
+       if ((pat->flags & EXC_FLAG_MUSTBEDIR) && !isdir)
                return 0;
 
        if (pat->flags & EXC_FLAG_NODIR) {
-               return match_basename(basename,
-                                     pathlen - (basename - pathname),
+               return match_basename(pathname + basename_offset,
+                                     pathlen - basename_offset - isdir,
                                      pattern, prefix,
                                      pat->patternlen, pat->flags);
        }
-       return match_pathname(pathname, pathlen,
+       return match_pathname(pathname, pathlen - isdir,
                              base, baselen,
                              pattern, prefix, pat->patternlen, pat->flags);
 }
@@ -703,7 +670,7 @@ static int fill_one(const char *what, struct match_attr *a, int rem)
        return rem;
 }
 
-static int fill(const char *path, int pathlen, const char *basename,
+static int fill(const char *path, int pathlen, int basename_offset,
                struct attr_stack *stk, int rem)
 {
        int i;
@@ -713,7 +680,7 @@ static int fill(const char *path, int pathlen, const char *basename,
                struct match_attr *a = stk->attrs[i];
                if (a->is_macro)
                        continue;
-               if (path_matches(path, pathlen, basename,
+               if (path_matches(path, pathlen, basename_offset,
                                 &a->u.pat, base, stk->originlen))
                        rem = fill_one("fill", a, rem);
        }
@@ -752,7 +719,8 @@ static void collect_all_attrs(const char *path)
 {
        struct attr_stack *stk;
        int i, pathlen, rem, dirlen;
-       const char *basename, *cp, *last_slash = NULL;
+       const char *cp, *last_slash = NULL;
+       int basename_offset;
 
        for (cp = path; *cp; cp++) {
                if (*cp == '/' && cp[1])
@@ -760,10 +728,10 @@ static void collect_all_attrs(const char *path)
        }
        pathlen = cp - path;
        if (last_slash) {
-               basename = last_slash + 1;
+               basename_offset = last_slash + 1 - path;
                dirlen = last_slash - path;
        } else {
-               basename = path;
+               basename_offset = 0;
                dirlen = 0;
        }
 
@@ -773,7 +741,7 @@ static void collect_all_attrs(const char *path)
 
        rem = attr_nr;
        for (stk = attr_stack; 0 < rem && stk; stk = stk->prev)
-               rem = fill(path, pathlen, basename, stk, rem);
+               rem = fill(path, pathlen, basename_offset, stk, rem);
 }
 
 int git_check_attr(const char *path, int num, struct git_attr_check *check)
index bd1b7b5..374d9e2 100644 (file)
--- a/bisect.c
+++ b/bisect.c
@@ -525,9 +525,9 @@ struct commit_list *filter_skipped(struct commit_list *list,
  * is increased by one between each call, but that should not matter
  * for this application.
  */
-static int get_prn(int count) {
+static unsigned get_prn(unsigned count) {
        count = count * 1103515245 + 12345;
-       return ((unsigned)(count/65536) % PRN_MODULO);
+       return (count/65536) % PRN_MODULO;
 }
 
 /*
index 2bef1e7..97c72bf 100644 (file)
--- a/branch.c
+++ b/branch.c
@@ -57,7 +57,7 @@ void install_branch_config(int flag, const char *local, const char *origin, cons
        if (remote_is_branch
            && !strcmp(local, shortname)
            && !origin) {
-               warning("Not setting branch %s as its own upstream.",
+               warning(_("Not setting branch %s as its own upstream."),
                        local);
                return;
        }
@@ -78,25 +78,25 @@ void install_branch_config(int flag, const char *local, const char *origin, cons
 
        if (flag & BRANCH_CONFIG_VERBOSE) {
                if (remote_is_branch && origin)
-                       printf(rebasing ?
-                              "Branch %s set up to track remote branch %s from %s by rebasing.\n" :
-                              "Branch %s set up to track remote branch %s from %s.\n",
-                              local, shortname, origin);
+                       printf_ln(rebasing ?
+                                 _("Branch %s set up to track remote branch %s from %s by rebasing.") :
+                                 _("Branch %s set up to track remote branch %s from %s."),
+                                 local, shortname, origin);
                else if (remote_is_branch && !origin)
-                       printf(rebasing ?
-                              "Branch %s set up to track local branch %s by rebasing.\n" :
-                              "Branch %s set up to track local branch %s.\n",
-                              local, shortname);
+                       printf_ln(rebasing ?
+                                 _("Branch %s set up to track local branch %s by rebasing.") :
+                                 _("Branch %s set up to track local branch %s."),
+                                 local, shortname);
                else if (!remote_is_branch && origin)
-                       printf(rebasing ?
-                              "Branch %s set up to track remote ref %s by rebasing.\n" :
-                              "Branch %s set up to track remote ref %s.\n",
-                              local, remote);
+                       printf_ln(rebasing ?
+                                 _("Branch %s set up to track remote ref %s by rebasing.") :
+                                 _("Branch %s set up to track remote ref %s."),
+                                 local, remote);
                else if (!remote_is_branch && !origin)
-                       printf(rebasing ?
-                              "Branch %s set up to track local ref %s by rebasing.\n" :
-                              "Branch %s set up to track local ref %s.\n",
-                              local, remote);
+                       printf_ln(rebasing ?
+                                 _("Branch %s set up to track local ref %s by rebasing.") :
+                                 _("Branch %s set up to track local ref %s."),
+                                 local, remote);
                else
                        die("BUG: impossible combination of %d and %p",
                            remote_is_branch, origin);
@@ -115,7 +115,7 @@ static int setup_tracking(const char *new_ref, const char *orig_ref,
        int config_flags = quiet ? 0 : BRANCH_CONFIG_VERBOSE;
 
        if (strlen(new_ref) > 1024 - 7 - 7 - 1)
-               return error("Tracking not set up: name too long: %s",
+               return error(_("Tracking not set up: name too long: %s"),
                                new_ref);
 
        memset(&tracking, 0, sizeof(tracking));
@@ -134,7 +134,7 @@ static int setup_tracking(const char *new_ref, const char *orig_ref,
                }
 
        if (tracking.matches > 1)
-               return error("Not tracking: ambiguous information for ref %s",
+               return error(_("Not tracking: ambiguous information for ref %s"),
                                orig_ref);
 
        install_branch_config(config_flags, new_ref, tracking.remote,
@@ -179,12 +179,12 @@ int validate_new_branchname(const char *name, struct strbuf *ref,
                            int force, int attr_only)
 {
        if (strbuf_check_branch_ref(ref, name))
-               die("'%s' is not a valid branch name.", name);
+               die(_("'%s' is not a valid branch name."), name);
 
        if (!ref_exists(ref->buf))
                return 0;
        else if (!force && !attr_only)
-               die("A branch named '%s' already exists.", ref->buf + strlen("refs/heads/"));
+               die(_("A branch named '%s' already exists."), ref->buf + strlen("refs/heads/"));
 
        if (!attr_only) {
                const char *head;
@@ -192,11 +192,25 @@ int validate_new_branchname(const char *name, struct strbuf *ref,
 
                head = resolve_ref_unsafe("HEAD", sha1, 0, NULL);
                if (!is_bare_repository() && head && !strcmp(head, ref->buf))
-                       die("Cannot force update the current branch.");
+                       die(_("Cannot force update the current branch."));
        }
        return 1;
 }
 
+static const char upstream_not_branch[] =
+N_("Cannot setup tracking information; starting point '%s' is not a branch.");
+static const char upstream_missing[] =
+N_("the requested upstream branch '%s' does not exist");
+static const char upstream_advice[] =
+N_("\n"
+"If you are planning on basing your work on an upstream\n"
+"branch that already exists at the remote, you may need to\n"
+"run \"git fetch\" to retrieve it.\n"
+"\n"
+"If you are planning to push out a new local branch that\n"
+"will track its remote counterpart, you may want to use\n"
+"\"git push -u\" to set the upstream config as you push.");
+
 void create_branch(const char *head,
                   const char *name, const char *start_name,
                   int force, int reflog, int clobber_head,
@@ -224,38 +238,47 @@ void create_branch(const char *head,
        }
 
        real_ref = NULL;
-       if (get_sha1(start_name, sha1))
-               die("Not a valid object name: '%s'.", start_name);
+       if (get_sha1(start_name, sha1)) {
+               if (explicit_tracking) {
+                       if (advice_set_upstream_failure) {
+                               error(_(upstream_missing), start_name);
+                               advise(_(upstream_advice));
+                               exit(1);
+                       }
+                       die(_(upstream_missing), start_name);
+               }
+               die(_("Not a valid object name: '%s'."), start_name);
+       }
 
        switch (dwim_ref(start_name, strlen(start_name), sha1, &real_ref)) {
        case 0:
                /* Not branching from any existing branch */
                if (explicit_tracking)
-                       die("Cannot setup tracking information; starting point is not a branch.");
+                       die(_(upstream_not_branch), start_name);
                break;
        case 1:
                /* Unique completion -- good, only if it is a real branch */
                if (prefixcmp(real_ref, "refs/heads/") &&
                    prefixcmp(real_ref, "refs/remotes/")) {
                        if (explicit_tracking)
-                               die("Cannot setup tracking information; starting point is not a branch.");
+                               die(_(upstream_not_branch), start_name);
                        else
                                real_ref = NULL;
                }
                break;
        default:
-               die("Ambiguous object name: '%s'.", start_name);
+               die(_("Ambiguous object name: '%s'."), start_name);
                break;
        }
 
        if ((commit = lookup_commit_reference(sha1)) == NULL)
-               die("Not a valid branch point: '%s'.", start_name);
+               die(_("Not a valid branch point: '%s'."), start_name);
        hashcpy(sha1, commit->object.sha1);
 
        if (!dont_change_ref) {
                lock = lock_any_ref_for_update(ref.buf, NULL, 0);
                if (!lock)
-                       die_errno("Failed to lock ref for update");
+                       die_errno(_("Failed to lock ref for update"));
        }
 
        if (reflog)
@@ -273,7 +296,7 @@ void create_branch(const char *head,
 
        if (!dont_change_ref)
                if (write_ref_sha1(lock, sha1, msg) < 0)
-                       die_errno("Failed to write ref");
+                       die_errno(_("Failed to write ref"));
 
        strbuf_release(&ref);
        free(real_ref);
index ab1c9e8..f45d9d4 100644 (file)
@@ -26,8 +26,55 @@ static int take_worktree_changes;
 struct update_callback_data {
        int flags;
        int add_errors;
+       const char *implicit_dot;
+       size_t implicit_dot_len;
+
+       /* only needed for 2.0 transition preparation */
+       int warn_add_would_remove;
 };
 
+static const char *option_with_implicit_dot;
+static const char *short_option_with_implicit_dot;
+
+static void warn_pathless_add(void)
+{
+       static int shown;
+       assert(option_with_implicit_dot && short_option_with_implicit_dot);
+
+       if (shown)
+               return;
+       shown = 1;
+
+       /*
+        * To be consistent with "git add -p" and most Git
+        * commands, we should default to being tree-wide, but
+        * this is not the original behavior and can't be
+        * changed until users trained themselves not to type
+        * "git add -u" or "git add -A". For now, we warn and
+        * keep the old behavior. Later, the behavior can be changed
+        * to tree-wide, keeping the warning for a while, and
+        * eventually we can drop the warning.
+        */
+       warning(_("The behavior of 'git add %s (or %s)' with no path argument from a\n"
+                 "subdirectory of the tree will change in Git 2.0 and should not be used anymore.\n"
+                 "To add content for the whole tree, run:\n"
+                 "\n"
+                 "  git add %s :/\n"
+                 "  (or git add %s :/)\n"
+                 "\n"
+                 "To restrict the command to the current directory, run:\n"
+                 "\n"
+                 "  git add %s .\n"
+                 "  (or git add %s .)\n"
+                 "\n"
+                 "With the current Git version, the command is restricted to "
+                 "the current directory.\n"
+                 ""),
+               option_with_implicit_dot, short_option_with_implicit_dot,
+               option_with_implicit_dot, short_option_with_implicit_dot,
+               option_with_implicit_dot, short_option_with_implicit_dot);
+}
+
 static int fix_unmerged_status(struct diff_filepair *p,
                               struct update_callback_data *data)
 {
@@ -49,15 +96,49 @@ static int fix_unmerged_status(struct diff_filepair *p,
                return DIFF_STATUS_MODIFIED;
 }
 
+static const char *add_would_remove_warning = N_(
+       "You ran 'git add' with neither '-A (--all)' or '--ignore-removal',\n"
+"whose behaviour will change in Git 2.0 with respect to paths you removed.\n"
+"Paths like '%s' that are\n"
+"removed from your working tree are ignored with this version of Git.\n"
+"\n"
+"* 'git add --ignore-removal <pathspec>', which is the current default,\n"
+"  ignores paths you removed from your working tree.\n"
+"\n"
+"* 'git add --all <pathspec>' will let you also record the removals.\n"
+"\n"
+"Run 'git status' to check the paths you removed from your working tree.\n");
+
+static void warn_add_would_remove(const char *path)
+{
+       warning(_(add_would_remove_warning), path);
+}
+
 static void update_callback(struct diff_queue_struct *q,
                            struct diff_options *opt, void *cbdata)
 {
        int i;
        struct update_callback_data *data = cbdata;
+       const char *implicit_dot = data->implicit_dot;
+       size_t implicit_dot_len = data->implicit_dot_len;
 
        for (i = 0; i < q->nr; i++) {
                struct diff_filepair *p = q->queue[i];
                const char *path = p->one->path;
+               /*
+                * Check if "git add -A" or "git add -u" was run from a
+                * subdirectory with a modified file outside that directory,
+                * and warn if so.
+                *
+                * "git add -u" will behave like "git add -u :/" instead of
+                * "git add -u ." in the future.  This warning prepares for
+                * that change.
+                */
+               if (implicit_dot &&
+                   strncmp_icase(path, implicit_dot, implicit_dot_len)) {
+                       warn_pathless_add();
+                       continue;
+               }
                switch (fix_unmerged_status(p, data)) {
                default:
                        die(_("unexpected diff status %c"), p->status);
@@ -70,6 +151,10 @@ static void update_callback(struct diff_queue_struct *q,
                        }
                        break;
                case DIFF_STATUS_DELETED:
+                       if (data->warn_add_would_remove) {
+                               warn_add_would_remove(path);
+                               data->warn_add_would_remove = 0;
+                       }
                        if (data->flags & ADD_CACHE_IGNORE_REMOVAL)
                                break;
                        if (!(data->flags & ADD_CACHE_PRETEND))
@@ -81,24 +166,34 @@ static void update_callback(struct diff_queue_struct *q,
        }
 }
 
-int add_files_to_cache(const char *prefix, const char **pathspec, int flags)
+static void update_files_in_cache(const char *prefix, const char **pathspec,
+                                 struct update_callback_data *data)
 {
-       struct update_callback_data data;
        struct rev_info rev;
+
        init_revisions(&rev, prefix);
        setup_revisions(0, NULL, &rev, NULL);
        init_pathspec(&rev.prune_data, pathspec);
        rev.diffopt.output_format = DIFF_FORMAT_CALLBACK;
        rev.diffopt.format_callback = update_callback;
-       data.flags = flags;
-       data.add_errors = 0;
-       rev.diffopt.format_callback_data = &data;
+       rev.diffopt.format_callback_data = data;
        rev.max_count = 0; /* do not compare unmerged paths with stage #2 */
        run_diff_files(&rev, DIFF_RACY_IS_MODIFIED);
+}
+
+int add_files_to_cache(const char *prefix, const char **pathspec, int flags)
+{
+       struct update_callback_data data;
+
+       memset(&data, 0, sizeof(data));
+       data.flags = flags;
+       update_files_in_cache(prefix, pathspec, &data);
        return !!data.add_errors;
 }
 
-static char *prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)
+#define WARN_IMPLICIT_DOT (1u << 0)
+static char *prune_directory(struct dir_struct *dir, const char **pathspec,
+                            int prefix, unsigned flag)
 {
        char *seen;
        int i, specs;
@@ -115,6 +210,16 @@ static char *prune_directory(struct dir_struct *dir, const char **pathspec, int
                if (match_pathspec(pathspec, entry->name, entry->len,
                                   prefix, seen))
                        *dst++ = entry;
+               else if (flag & WARN_IMPLICIT_DOT)
+                       /*
+                        * "git add -A" was run from a subdirectory with a
+                        * new file outside that directory.
+                        *
+                        * "git add -A" will behave like "git add -A :/"
+                        * instead of "git add -A ." in the future.
+                        * Warn about the coming behavior change.
+                        */
+                       warn_pathless_add();
        }
        dir->nr = dst - dir->entries;
        add_pathspec_matches_against_index(pathspec, seen, specs);
@@ -270,23 +375,38 @@ static struct lock_file lock_file;
 static const char ignore_error[] =
 N_("The following paths are ignored by one of your .gitignore files:\n");
 
-static int verbose = 0, show_only = 0, ignored_too = 0, refresh_only = 0;
-static int ignore_add_errors, addremove, intent_to_add, ignore_missing = 0;
+static int verbose, show_only, ignored_too, refresh_only;
+static int ignore_add_errors, intent_to_add, ignore_missing;
+
+#define ADDREMOVE_DEFAULT 0 /* Change to 1 in Git 2.0 */
+static int addremove = ADDREMOVE_DEFAULT;
+static int addremove_explicit = -1; /* unspecified */
+
+static int ignore_removal_cb(const struct option *opt, const char *arg, int unset)
+{
+       /* if we are told to ignore, we are not adding removals */
+       *(int *)opt->value = !unset ? 0 : 1;
+       return 0;
+}
 
 static struct option builtin_add_options[] = {
        OPT__DRY_RUN(&show_only, N_("dry run")),
        OPT__VERBOSE(&verbose, N_("be verbose")),
        OPT_GROUP(""),
-       OPT_BOOLEAN('i', "interactive", &add_interactive, N_("interactive picking")),
-       OPT_BOOLEAN('p', "patch", &patch_interactive, N_("select hunks interactively")),
-       OPT_BOOLEAN('e', "edit", &edit_interactive, N_("edit current diff and apply")),
+       OPT_BOOL('i', "interactive", &add_interactive, N_("interactive picking")),
+       OPT_BOOL('p', "patch", &patch_interactive, N_("select hunks interactively")),
+       OPT_BOOL('e', "edit", &edit_interactive, N_("edit current diff and apply")),
        OPT__FORCE(&ignored_too, N_("allow adding otherwise ignored files")),
-       OPT_BOOLEAN('u', "update", &take_worktree_changes, N_("update tracked files")),
-       OPT_BOOLEAN('N', "intent-to-add", &intent_to_add, N_("record only the fact that the path will be added later")),
-       OPT_BOOLEAN('A', "all", &addremove, N_("add changes from all tracked and untracked files")),
-       OPT_BOOLEAN( 0 , "refresh", &refresh_only, N_("don't add, only refresh the index")),
-       OPT_BOOLEAN( 0 , "ignore-errors", &ignore_add_errors, N_("just skip files which cannot be added because of errors")),
-       OPT_BOOLEAN( 0 , "ignore-missing", &ignore_missing, N_("check if - even missing - files are ignored in dry run")),
+       OPT_BOOL('u', "update", &take_worktree_changes, N_("update tracked files")),
+       OPT_BOOL('N', "intent-to-add", &intent_to_add, N_("record only the fact that the path will be added later")),
+       OPT_BOOL('A', "all", &addremove_explicit, N_("add changes from all tracked and untracked files")),
+       { OPTION_CALLBACK, 0, "ignore-removal", &addremove_explicit,
+         NULL /* takes no arguments */,
+         N_("ignore paths removed in the working tree (same as --no-all)"),
+         PARSE_OPT_NOARG, ignore_removal_cb },
+       OPT_BOOL( 0 , "refresh", &refresh_only, N_("don't add, only refresh the index")),
+       OPT_BOOL( 0 , "ignore-errors", &ignore_add_e