summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/CodingGuidelines11
-rw-r--r--Documentation/RelNotes/1.9.1.txt59
-rw-r--r--Documentation/RelNotes/1.9.2.txt38
-rw-r--r--Documentation/RelNotes/2.0.0.txt331
-rw-r--r--Documentation/config.txt95
-rw-r--r--Documentation/git-add.txt34
-rw-r--r--Documentation/git-am.txt17
-rw-r--r--Documentation/git-archive.txt5
-rw-r--r--Documentation/git-blame.txt3
-rw-r--r--Documentation/git-cherry-pick.txt7
-rw-r--r--Documentation/git-clone.txt11
-rw-r--r--Documentation/git-commit-tree.txt5
-rw-r--r--Documentation/git-commit.txt14
-rw-r--r--Documentation/git-cvsimport.txt4
-rw-r--r--Documentation/git-filter-branch.txt4
-rw-r--r--Documentation/git-gc.txt3
-rw-r--r--Documentation/git-merge.txt2
-rw-r--r--Documentation/git-notes.txt2
-rw-r--r--Documentation/git-pack-objects.txt2
-rw-r--r--Documentation/git-push.txt10
-rw-r--r--Documentation/git-rebase.txt4
-rw-r--r--Documentation/git-remote.txt2
-rw-r--r--Documentation/git-repack.txt17
-rw-r--r--Documentation/git-request-pull.txt55
-rw-r--r--Documentation/git-reset.txt5
-rw-r--r--Documentation/git-rev-list.txt1
-rw-r--r--Documentation/git-rev-parse.txt38
-rw-r--r--Documentation/git-revert.txt6
-rw-r--r--Documentation/git-stash.txt2
-rw-r--r--Documentation/git-status.txt2
-rw-r--r--Documentation/git-submodule.txt25
-rw-r--r--Documentation/git-tag.txt6
-rw-r--r--Documentation/git-update-index.txt8
-rw-r--r--Documentation/git-upload-archive.txt32
-rw-r--r--Documentation/git.txt8
-rw-r--r--Documentation/gitcore-tutorial.txt2
-rw-r--r--Documentation/gitcvs-migration.txt2
-rw-r--r--Documentation/gitignore.txt3
-rw-r--r--Documentation/gitk.txt10
-rw-r--r--Documentation/gitremote-helpers.txt4
-rw-r--r--Documentation/gitrepository-layout.txt4
-rw-r--r--Documentation/gitweb.txt2
-rw-r--r--Documentation/glossary-content.txt4
-rw-r--r--Documentation/merge-strategies.txt6
-rw-r--r--Documentation/rev-list-options.txt15
-rw-r--r--Documentation/technical/api-hash.txt52
-rw-r--r--Documentation/technical/api-hashmap.txt235
-rw-r--r--Documentation/technical/bitmap-format.txt164
-rw-r--r--Documentation/technical/http-protocol.txt4
-rw-r--r--Documentation/technical/pack-protocol.txt3
-rw-r--r--Documentation/technical/protocol-capabilities.txt18
51 files changed, 1260 insertions, 136 deletions
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index ef67b53..ed432a8 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -126,6 +126,17 @@ For C programs:
"char * string". This makes it easier to understand code
like "char *string, c;".
+ - Use whitespace around operators and keywords, but not inside
+ parentheses and not around functions. So:
+
+ while (condition)
+ func(bar + 1);
+
+ and not:
+
+ while( condition )
+ func (bar+1);
+
- We avoid using braces unnecessarily. I.e.
if (bla) {
diff --git a/Documentation/RelNotes/1.9.1.txt b/Documentation/RelNotes/1.9.1.txt
new file mode 100644
index 0000000..5b06020
--- /dev/null
+++ b/Documentation/RelNotes/1.9.1.txt
@@ -0,0 +1,59 @@
+Git v1.9.1 Release Notes
+========================
+
+Fixes since v1.9.0
+------------------
+
+ * "git clean -d pathspec" did not use the given pathspec correctly
+ and ended up cleaning too much.
+
+ * "git difftool" misbehaved when the repository is bound to the
+ working tree with the ".git file" mechanism, where a textual file
+ ".git" tells us where it is.
+
+ * "git push" did not pay attention to branch.*.pushremote if it is
+ defined earlier than remote.pushdefault; the order of these two
+ variables in the configuration file should not matter, but it did
+ by mistake.
+
+ * Codepaths that parse timestamps in commit objects have been
+ tightened.
+
+ * "git diff --external-diff" incorrectly fed the submodule directory
+ in the working tree to the external diff driver when it knew it is
+ the same as one of the versions being compared.
+
+ * "git reset" needs to refresh the index when working in a working
+ tree (it can also be used to match the index to the HEAD in an
+ otherwise bare repository), but it failed to set up the working
+ tree properly, causing GIT_WORK_TREE to be ignored.
+
+ * "git check-attr" when working on a repository with a working tree
+ did not work well when the working tree was specified via the
+ --work-tree (and obviously with --git-dir) option.
+
+ * "merge-recursive" was broken in 1.7.7 era and stopped working in
+ an empty (temporary) working tree, when there are renames
+ involved. This has been corrected.
+
+ * "git rev-parse" was loose in rejecting command line arguments
+ that do not make sense, e.g. "--default" without the required
+ value for that option.
+
+ * include.path variable (or any variable that expects a path that
+ can use ~username expansion) in the configuration file is not a
+ boolean, but the code failed to check it.
+
+ * "git diff --quiet -- pathspec1 pathspec2" sometimes did not return
+ correct status value.
+
+ * Attempting to deepen a shallow repository by fetching over smart
+ HTTP transport failed in the protocol exchange, when no-done
+ extension was used. The fetching side waited for the list of
+ shallow boundary commits after the sending end stopped talking to
+ it.
+
+ * Allow "git cmd path/", when the 'path' is where a submodule is
+ bound to the top-level working tree, to match 'path', despite the
+ extra and unnecessary trailing slash (such a slash is often
+ given by command line completion).
diff --git a/Documentation/RelNotes/1.9.2.txt b/Documentation/RelNotes/1.9.2.txt
new file mode 100644
index 0000000..c755e34
--- /dev/null
+++ b/Documentation/RelNotes/1.9.2.txt
@@ -0,0 +1,38 @@
+Git v1.9.2 Release Notes
+========================
+
+Fixes since v1.9.1
+------------------
+
+ * "git mv" that moves a submodule forgot to adjust the array that
+ uses to keep track of which submodules were to be moved to update
+ its configuration.
+
+ * Length limit for the pathname used when removing a path in a deep
+ subdirectory has been removed to avoid buffer overflows.
+
+ * The test helper lib-terminal always run an actual test_expect_*
+ when included, which screwed up with the use of skil-all that may
+ have to be done later.
+
+ * "git index-pack" used a wrong variable to name the keep-file in an
+ error message when the file cannot be written or closed.
+
+ * "rebase -i" produced a broken insn sheet when the title of a commit
+ happened to contain '\n' (or ended with '\c') due to a careless use
+ of 'echo'.
+
+ * There were a few instances of 'git-foo' remaining in the
+ documentation that should have been spelled 'git foo'.
+
+ * Serving objects from a shallow repository needs to write a
+ new file to hold the temporary shallow boundaries but it was not
+ cleaned when we exit due to die() or a signal.
+
+ * When "git stash pop" stops after failing to apply the stash
+ (e.g. due to conflicting changes), the stash is not dropped. State
+ that explicitly in the output to let the users know.
+
+ * The labels in "git status" output that describe the nature of
+ conflicts (e.g. "both deleted") were limited to 20 bytes, which was
+ too short for some l10n (e.g. fr).
diff --git a/Documentation/RelNotes/2.0.0.txt b/Documentation/RelNotes/2.0.0.txt
new file mode 100644
index 0000000..1058f7d
--- /dev/null
+++ b/Documentation/RelNotes/2.0.0.txt
@@ -0,0 +1,331 @@
+Git v2.0 Release Notes
+======================
+
+Backward compatibility notes
+----------------------------
+
+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 is now the "simple" semantics,
+which 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, if you are pushing to the same remote as you fetch from; or
+
+ - only the current branch to the branch with the same name, if you
+ are pushing to a remote that is not where you usually fetch from.
+
+You can use the configuration variable "push.default" to change
+this. If you are an old-timer who wants to keep using the
+"matching" semantics, you can set the variable to "matching", for
+example. Read the documentation for other possibilities.
+
+When "git add -u" and "git add -A" are run inside a subdirectory
+without specifying which paths to add on the command line, they
+operate on the entire tree for consistency with "git commit -a" and
+other commands (these commands used to operate only on the current
+subdirectory). Say "git add -u ." or "git add -A ." if you want to
+limit the operation to the current directory.
+
+"git add <path>" is the same as "git add -A <path>" now, so that
+"git add dir/" will notice paths you removed from the directory and
+record the removal. In older versions of Git, "git add <path>" used
+to ignore removals. You can say "git add --ignore-removal <path>" to
+add only added or modified paths in <path>, if you really want to.
+
+The "-q" option to "git diff-files", which does *NOT* mean "quiet",
+has been removed (it told Git to ignore deletion, which you can do
+with "git diff-files --diff-filter=d").
+
+"git request-pull" lost a few "heuristics" that often led to mistakes.
+
+
+Updates since v1.9 series
+-------------------------
+
+UI, Workflows & Features
+
+ * "git gc --aggressive" learned "--depth" option and
+ "gc.aggressiveDepth" configuration variable to allow use of a less
+ insane depth than the built-in default value of 250.
+
+ * "git log" learned the "--show-linear-break" option to show where a
+ single strand-of-pearls is broken in its output.
+
+ * The "rev-parse --parseopt" mechanism used by scripted Porcelains to
+ parse command line options and to give help text learned to take
+ the argv-help (the placeholder string for an option parameter,
+ e.g. "key-id" in "--gpg-sign=<key-id>").
+
+ * The pattern to find where the function begins in C/C++ used in
+ "diff" and "grep -p" have been updated to help C++ source better.
+
+ * "git rebase" learned to interpret a lone "-" as "@{-1}", the
+ branch that we were previously on.
+
+ * "git commit --cleanup=<mode>" learned a new mode, scissors.
+
+ * "git tag --list" output can be sorted using "version sort" with
+ "--sort=version:refname".
+
+ * Discard the accumulated "heuristics" to guess from which branch the
+ result wants to be pulled from and make sure what the end user
+ specified is not second-guessed by "git request-pull", to avoid
+ mistakes. When you pushed out your 'master' branch to your public
+ repository as 'for-linus', use the new "master:for-linus" syntax to
+ denote the branch to be pulled.
+
+ * "git grep" learned to behave in a way similar to native grep when
+ "-h" (no header) and "-c" (count) options are given.
+
+ * transport-helper, fast-import and fast-export have been updated to
+ allow the ref mapping and ref deletion in a way similar to the
+ natively supported transports.
+
+ * The "simple" mode is the default for "git push".
+
+ * "git add -u" and "git add -A", when run without any pathspec, is a
+ tree-wide operation even when run inside a subdirectory of a
+ working tree.
+
+ * "git add <path> is the same as "git add -A <path>" now.
+
+ * "core.statinfo" configuration variable, which is a
+ never-advertised synonym to "core.checkstat", has been removed.
+
+ * The "-q" option to "git diff-files", which does *NOT* mean
+ "quiet", has been removed (it told Git to ignore deletion, which
+ you can do with "git diff-files --diff-filter=d").
+
+ * Server operators can loosen the "tips of refs only" restriction for
+ the remote archive service with the uploadarchive.allowUnreachable
+ configuration option.
+
+ * The progress indicators from various time-consuming commands have
+ been marked for i18n/l10n.
+
+ * "git notes -C <blob>" diagnoses an attempt to use an object that
+ is not a blob as an error.
+
+ * "git config" learned to read from the standard input when "-" is
+ given as the value to its "--file" parameter (attempting an
+ operation to update the configuration in the standard input of
+ course is rejected).
+
+ * Trailing whitespaces in .gitignore files, unless they are quoted
+ for fnmatch(3), e.g. "path\ ", are warned and ignored. Strictly
+ speaking, this is a backward incompatible change, but very unlikely
+ to bite any sane user and adjusting should be obvious and easy.
+
+ * Many commands that create commits, e.g. "pull", "rebase",
+ learned to take the --gpg-sign option on the command line.
+
+ * "git commit" can be told to always GPG sign the resulting commit
+ by setting "commit.gpgsign" configuration variable to true (the
+ command line option --no-gpg-sign should override it).
+
+ * "git pull" can be told to only accept fast-forward by setting the
+ new "pull.ff" configuration.
+
+ * "git reset" learned "-N" option, which does not reset the index
+ fully for paths the index knows about but the tree-ish the command
+ resets to does not (these paths are kept as intend-to-add entries).
+
+
+Performance, Internal Implementation, etc.
+
+ * The compilation options to port to AIX has been updated.
+
+ * We started using wildmatch() in place of fnmatch(3) a few releases
+ ago; complete the process and stop using fnmatch(3).
+
+ * Uses of curl's "multi" interface and "easy" interface do not mix
+ well when we attempt to reuse outgoing connections. Teach the RPC
+ over http code, used in the smart HTTP transport, not to use the
+ "easy" interface.
+
+ * The bitmap-index feature from JGit has been ported, which should
+ significantly improve performance when serving objects form a
+ repository that uses it.
+
+ * The way "git log --cc" shows a combined diff against multiple
+ parents have been optimized.
+
+ * The prefixcmp() and suffixcmp() functions are gone. Use
+ starts_with() and ends_with(), and also consider if skip_prefix()
+ suits your needs better when using the former.
+
+
+Also contains various documentation updates and code clean-ups. Many
+of them came from flurry of activities as GSoC candidate microproject
+exercises.
+
+
+Fixes since v1.9 series
+-----------------------
+
+Unless otherwise noted, all the fixes since v1.9 in the maintenance
+track are contained in this release (see the maintenance releases'
+notes for details).
+
+ * "git diff --no-index -Mq a b" fell into an infinite loop.
+ (merge ad1c3fb jc/fix-diff-no-index-diff-opt-parse later to maint).
+
+ * "git fetch --prune", when the right-hand-side of multiple fetch
+ refspecs overlap (e.g. storing "refs/heads/*" to
+ "refs/remotes/origin/*", while storing "refs/frotz/*" to
+ "refs/remotes/origin/fr/*"), aggressively thought that lack of
+ "refs/heads/fr/otz" on the origin site meant we should remove
+ "refs/remotes/origin/fr/otz" from us, without checking their
+ "refs/frotz/otz" first.
+
+ Note that such a configuration is inherently unsafe (think what
+ should happen when "refs/heads/fr/otz" does appear on the origin
+ site), but that is not a reason not to be extra careful.
+ (merge e6f6371 cn/fetch-prune-overlapping-destination later to maint).
+
+ * "git status --porcelain --branch" showed its output with labels
+ "ahead/behind/gone" translated to the user's locale.
+ (merge 7a76c28 mm/status-porcelain-format-i18n-fix later to maint).
+
+
+ * "git repack" died when asked to (re)pack with the reachability
+ bitmap when a bitmap cannot be built; instead, just (re)pack
+ without producing a bitmap in such a case, with a warning.
+ (merge 373c67d jk/pack-bitmap later to maint).
+
+
+ * The progress output while repacking and transferring objects showed
+ an apparent large silence while writing the objects out of existing
+ packfiles, when the reachability bitmap was in use.
+ (merge 78d2214 jk/pack-bitmap-progress later to maint).
+
+
+ * A stray environment variable $prefix could have leaked into and
+ affected the behaviour of the "subtree" script (in contrib/).
+
+
+ * When it is not necessary to edit a commit log message (e.g. "git
+ commit -m" is given a message without specifying "-e"), we used to
+ disable the spawning of the editor by overriding GIT_EDITOR, but
+ this means all the uses of the editor, other than to edit the
+ commit log message, are also affected.
+ (merge b549be0 bp/commit-p-editor later to maint).
+
+
+ * "git mv" that moves a submodule forgot to adjust the array that
+ uses to keep track of which submodules were to be moved to update
+ its configuration.
+ (merge fb8a4e8 jk/mv-submodules-fix later to maint).
+
+ * Length limit for the pathname used when removing a path in a deep
+ subdirectory has been removed to avoid buffer overflows.
+ (merge 2f29e0c mh/remove-subtree-long-pathname-fix later to maint).
+
+ * The test helper lib-terminal always run an actual test_expect_*
+ when included, which screwed up with the use of skil-all that may
+ have to be done later.
+ (merge 7e27173 jk/lib-terminal-lazy later to maint).
+
+ * "git index-pack" used a wrong variable to name the keep-file in an
+ error message when the file cannot be written or closed.
+ (merge de983a0 nd/index-pack-error-message later to maint).
+
+ * "rebase -i" produced a broken insn sheet when the title of a commit
+ happened to contain '\n' (or ended with '\c') due to a careless use
+ of 'echo'.
+ (merge cb1aefd us/printf-not-echo later to maint).
+
+ * There were a few instances of 'git-foo' remaining in the
+ documentation that should have been spelled 'git foo'.
+ (merge 3c3e6f5 rr/doc-merge-strategies later to maint).
+
+ * Serving objects from a shallow repository needs to write a
+ new file to hold the temporary shallow boundaries but it was not
+ cleaned when we exit due to die() or a signal.
+ (merge 7839632 jk/shallow-update-fix later to maint).
+
+ * When "git stash pop" stops after failing to apply the stash
+ (e.g. due to conflicting changes), the stash is not dropped. State
+ that explicitly in the output to let the users know.
+ (merge 2d4c993 jc/stash-pop-not-popped later to maint).
+
+ * The labels in "git status" output that describe the nature of
+ conflicts (e.g. "both deleted") were limited to 20 bytes, which was
+ too short for some l10n (e.g. fr).
+ (merge c7cb333 jn/wt-status later to maint).
+
+ * "git clean -d pathspec" did not use the given pathspec correctly
+ and ended up cleaning too much.
+ (merge 1f2e108 jk/clean-d-pathspec later to maint).
+
+ * "git difftool" misbehaved when the repository is bound to the
+ working tree with the ".git file" mechanism, where a textual file
+ ".git" tells us where it is.
+ (merge fcfec8b da/difftool-git-files later to maint).
+
+ * "git push" did not pay attention to branch.*.pushremote if it is
+ defined earlier than remote.pushdefault; the order of these two
+ variables in the configuration file should not matter, but it did
+ by mistake.
+ (merge 98b406f jk/remote-pushremote-config-reading later to maint).
+
+ * Codepaths that parse timestamps in commit objects have been
+ tightened.
+ (merge 3f419d4 jk/commit-dates-parsing-fix later to maint).
+
+ * "git diff --external-diff" incorrectly fed the submodule directory
+ in the working tree to the external diff driver when it knew it is
+ the same as one of the versions being compared.
+ (merge aba4727 tr/diff-submodule-no-reuse-worktree later to maint).
+
+ * "git reset" needs to refresh the index when working in a working
+ tree (it can also be used to match the index to the HEAD in an
+ otherwise bare repository), but it failed to set up the working
+ tree properly, causing GIT_WORK_TREE to be ignored.
+ (merge b7756d4 nd/reset-setup-worktree later to maint).
+
+ * "git check-attr" when working on a repository with a working tree
+ did not work well when the working tree was specified via the
+ --work-tree (and obviously with --git-dir) option.
+ (merge cdbf623 jc/check-attr-honor-working-tree later to maint).
+
+ * "merge-recursive" was broken in 1.7.7 era and stopped working in
+ an empty (temporary) working tree, when there are renames
+ involved. This has been corrected.
+ (merge 6e2068a bk/refresh-missing-ok-in-merge-recursive later to maint.)
+
+ * "git rev-parse" was loose in rejecting command line arguments
+ that do not make sense, e.g. "--default" without the required
+ value for that option.
+ (merge a43219f ds/rev-parse-required-args later to maint.)
+
+ * include.path variable (or any variable that expects a path that
+ can use ~username expansion) in the configuration file is not a
+ boolean, but the code failed to check it.
+ (merge 67beb60 jk/config-path-include-fix later to maint.)
+
+ * Commands that take pathspecs on the command line misbehaved when
+ the pathspec is given as an absolute pathname (which is a
+ practice not particularly encouraged) that points at a symbolic
+ link in the working tree.
+ (merge later 655ee9e mw/symlinks to maint.)
+
+ * "git diff --quiet -- pathspec1 pathspec2" sometimes did not return
+ correct status value.
+ (merge f34b205 nd/diff-quiet-stat-dirty later to maint.)
+
+ * Attempting to deepen a shallow repository by fetching over smart
+ HTTP transport failed in the protocol exchange, when no-done
+ extension was used. The fetching side waited for the list of
+ shallow boundary commits after the sending end stopped talking to
+ it.
+ (merge 0232852 nd/http-fetch-shallow-fix later to maint.)
+
+ * Allow "git cmd path/", when the 'path' is where a submodule is
+ bound to the top-level working tree, to match 'path', despite the
+ extra and unnecessary trailing slash (such a slash is often
+ given by command line completion).
+ (merge 2e70c01 nd/submodule-pathspec-ending-with-slash later to maint.)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5f4d793..84c7e3f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -131,8 +131,13 @@ Variables
Note that this list is non-comprehensive and not necessarily complete.
For command-specific variables, you will find a more detailed description
-in the appropriate manual page. You will find a description of non-core
-porcelain configuration variables in the respective porcelain documentation.
+in the appropriate manual page.
+
+Other git-related tools may and do use their own variables. When
+inventing new variables for use in your own tool, make sure their
+names do not conflict with those that are used by Git itself and
+other popular tools, and describe them in your documentation.
+
advice.*::
These variables control various optional help messages designed to
@@ -142,19 +147,13 @@ advice.*::
--
pushUpdateRejected::
Set this variable to 'false' if you want to disable
- 'pushNonFFCurrent', 'pushNonFFDefault',
+ 'pushNonFFCurrent',
'pushNonFFMatching', 'pushAlreadyExists',
'pushFetchFirst', and 'pushNeedsForce'
simultaneously.
pushNonFFCurrent::
Advice shown when linkgit:git-push[1] fails due to a
non-fast-forward update to the current branch.
- pushNonFFDefault::
- Advice to set 'push.default' to 'upstream' or 'current'
- when you ran linkgit:git-push[1] and pushed 'matching
- refs' by default (i.e. you did not provide an explicit
- refspec, and no 'push.default' configuration was set)
- and it resulted in a non-fast-forward error.
pushNonFFMatching::
Advice shown when you ran linkgit:git-push[1] and pushed
'matching refs' explicitly (i.e. you used ':', or
@@ -992,6 +991,14 @@ commit.cleanup::
have to remove the help lines that begin with `#` in the commit log
template yourself, if you do this).
+commit.gpgsign::
+
+ A boolean to specify whether all commits should be GPG signed.
+ Use of this option when doing operations such as rebase can
+ result in a large number of commits being signed. It may be
+ convenient to use an agent to avoid typing your GPG passphrase
+ several times.
+
commit.status::
A boolean to enable/disable inclusion of status information in the
commit message template when using an editor to prepare the commit
@@ -1149,6 +1156,11 @@ filter.<driver>.smudge::
object to a worktree file upon checkout. See
linkgit:gitattributes[5] for details.
+gc.aggressiveDepth::
+ The depth parameter used in the delta compression
+ algorithm used by 'git gc --aggressive'. This defaults
+ to 250.
+
gc.aggressiveWindow::
The window size parameter used in the delta compression
algorithm used by 'git gc --aggressive'. This defaults
@@ -1167,6 +1179,10 @@ gc.autopacklimit::
--auto` consolidates them into one larger pack. The
default value is 50. Setting this to 0 disables it.
+gc.autodetach::
+ Make `git gc --auto` return immediately andrun in background
+ if the system supports it. Default is true.
+
gc.packrefs::
Running `git pack-refs` in a repository renders it
unclonable by Git versions prior to 1.5.1.2 over dumb
@@ -1601,6 +1617,10 @@ imap::
The configuration variables in the 'imap' section are described
in linkgit:git-imap-send[1].
+index.version::
+ Specify the version with which new index files should be
+ initialized. This does not affect existing repositories.
+
init.templatedir::
Specify the directory from which templates will be copied.
(See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
@@ -1633,7 +1653,7 @@ interactive.singlekey::
linkgit:git-add[1], linkgit:git-checkout[1], linkgit:git-commit[1],
linkgit:git-reset[1], and linkgit:git-stash[1]. Note that this
setting is silently ignored if portable keystroke input
- is not available.
+ is not available; requires the Perl module Term::ReadKey.
log.abbrevCommit::
If true, makes linkgit:git-log[1], linkgit:git-show[1], and
@@ -1862,6 +1882,31 @@ pack.packSizeLimit::
Common unit suffixes of 'k', 'm', or 'g' are
supported.
+pack.useBitmaps::
+ When true, git will use pack bitmaps (if available) when packing
+ to stdout (e.g., during the server side of a fetch). Defaults to
+ true. You should not generally need to turn this off unless
+ you are debugging pack bitmaps.
+
+pack.writebitmaps::
+ When true, git will write a bitmap index when packing all
+ objects to disk (e.g., when `git repack -a` is run). This
+ index can speed up the "counting objects" phase of subsequent
+ packs created for clones and fetches, at the cost of some disk
+ space and extra time spent on the initial repack. Defaults to
+ false.
+
+pack.writeBitmapHashCache::
+ When true, git will include a "hash cache" section in the bitmap
+ index (if one is written). This cache can be used to feed git's
+ delta heuristics, potentially leading to better deltas between
+ bitmapped and non-bitmapped objects (e.g., when serving a fetch
+ between an older, bitmapped pack and objects that have been
+ pushed since the last gc). The downside is that it consumes 4
+ bytes per object of disk space, and that JGit's bitmap
+ implementation does not understand it, causing it to complain if
+ Git and JGit are used on the same repository. Defaults to false.
+
pager.<cmd>::
If the value is boolean, turns on or off pagination of the
output of a particular Git subcommand when writing to a tty.
@@ -1881,6 +1926,16 @@ pretty.<name>::
Note that an alias with the same name as a built-in format
will be silently ignored.
+pull.ff::
+ By default, Git does not create an extra merge commit when merging
+ a commit that is a descendant of the current commit. Instead, the
+ tip of the current branch is fast-forwarded. When set to `false`,
+ this variable tells Git to create an extra merge commit in such
+ a case (equivalent to giving the `--no-ff` option from the command
+ line). When set to `only`, only such fast-forward merges are
+ allowed (equivalent to giving the `--ff-only` option from the
+ command line).
+
pull.rebase::
When true, rebase branches on top of the fetched branch, instead
of merging the default branch from the default remote when "git
@@ -1933,7 +1988,7 @@ When pushing to a remote that is different from the remote you normally
pull from, work as `current`. This is the safest option and is suited
for beginners.
+
-This mode will become the default in Git 2.0.
+This mode has become the default in Git 2.0.
* `matching` - push all branches having the same name on both ends.
This makes the repository you are pushing to remember the set of
@@ -1952,8 +2007,8 @@ suitable for pushing into a shared central repository, as other
people may add new branches there, or update the tip of existing
branches outside your control.
+
-This is currently the default, but Git 2.0 will change the default
-to `simple`.
+This used to be the default, but not since Git 2.0 (`simple` is the
+new default).
--
@@ -2111,6 +2166,13 @@ repack.usedeltabaseoffset::
"false" and repack. Access from old Git versions over the
native protocol are unaffected by this option.
+repack.packKeptObjects::
+ If set to true, makes `git repack` act as if
+ `--pack-kept-objects` was passed. See linkgit:git-repack[1] for
+ details. Defaults to `false` normally, but `true` if a bitmap
+ index is being written (either via `--write-bitmap-index` or
+ `pack.writeBitmaps`).
+
rerere.autoupdate::
When set to true, `git-rerere` updates the index with the
resulting contents after it cleanly resolves conflicts using
@@ -2291,6 +2353,13 @@ transfer.unpackLimit::
not set, the value of this variable is used instead.
The default value is 100.
+uploadarchive.allowUnreachable::
+ If true, allow clients to use `git archive --remote` to request
+ any tree, whether reachable from the ref tips or not. See the
+ discussion in the `SECURITY` section of
+ linkgit:git-upload-archive[1] for more details. Defaults to
+ `false`.
+
uploadpack.hiderefs::
String(s) `upload-pack` uses to decide which refs to omit
from its initial advertisement. Use more than one
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 48754cb..895922e 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -53,8 +53,14 @@ OPTIONS
Files to add content from. Fileglobs (e.g. `*.c`) can
be given to add all matching files. Also a
leading directory name (e.g. `dir` to add `dir/file1`
- and `dir/file2`) can be given to add all files in the
- directory, recursively.
+ and `dir/file2`) can be given to update the index to
+ match the current state of the directory as a whole (e.g.
+ specifying `dir` will record not just a file `dir/file1`
+ modified in the working tree, a file `dir/file2` added to
+ the working tree, but also a file `dir/file3` removed from
+ the working tree. Note that older versions of Git used
+ to ignore removed files; use `--no-all` option if you want
+ to add modified or new files but ignore removed ones.
-n::
--dry-run::
@@ -104,10 +110,10 @@ apply to the index. See EDITING PATCHES below.
<pathspec>. This removes as well as modifies index entries to
match the working tree, but adds no new files.
+
-If no <pathspec> is given, the current version of Git defaults to
-"."; in other words, update all tracked files in the current directory
-and its subdirectories. This default will change in a future version
-of Git, hence the form without <pathspec> should not be used.
+If no <pathspec> is given when `-u` option is used, all
+tracked files in the entire working tree are updated (old versions
+of Git used to limit the update to the current directory and its
+subdirectories).
-A::
--all::
@@ -117,10 +123,10 @@ of Git, hence the form without <pathspec> should not be used.
entry. This adds, modifies, and removes index entries to
match the working tree.
+
-If no <pathspec> is given, the current version of Git defaults to
-"."; in other words, update all files in the current directory
-and its subdirectories. This default will change in a future version
-of Git, hence the form without <pathspec> should not be used.
+If no <pathspec> is given when `-A` option is used, all
+files in the entire working tree are updated (old versions
+of Git used to limit the update to the current directory and its
+subdirectories).
--no-all::
--ignore-removal::
@@ -129,11 +135,9 @@ of Git, hence the form without <pathspec> should not be used.
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.
+This option is primarily to help users who are used to older
+versions of Git, whose "git add <pathspec>..." was a synonym
+for "git add --no-all <pathspec>...", i.e. ignored removed files.
-N::
--intent-to-add::
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 54d8461..9adce37 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -14,7 +14,7 @@ SYNOPSIS
[--ignore-date] [--ignore-space-change | --ignore-whitespace]
[--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
[--exclude=<path>] [--include=<path>] [--reject] [-q | --quiet]
- [--[no-]scissors]
+ [--[no-]scissors] [-S[<keyid>]] [--patch-format=<format>]
[(<mbox> | <Maildir>)...]
'git am' (--continue | --skip | --abort)
@@ -97,6 +97,12 @@ default. You can use `--no-utf8` to override this.
program that applies
the patch.
+--patch-format::
+ By default the command will try to detect the patch format
+ automatically. This option allows the user to bypass the automatic
+ detection and specify the patch format that the patch(es) should be
+ interpreted as. Valid formats are mbox, stgit, stgit-series and hg.
+
-i::
--interactive::
Run interactively.
@@ -119,6 +125,10 @@ default. You can use `--no-utf8` to override this.
Skip the current patch. This is only meaningful when
restarting an aborted patch.
+-S[<keyid>]::
+--gpg-sign[=<keyid>]::
+ GPG-sign commits.
+
--continue::
-r::
--resolved::
@@ -189,6 +199,11 @@ commits, like running 'git am' on the wrong branch or an error in the
commits that is more easily fixed by changing the mailbox (e.g.
errors in the "From:" lines).
+HOOKS
+-----
+This command can run `applypatch-msg`, `pre-applypatch`,
+and `post-applypatch` hooks. See linkgit:githooks[5] for more
+information.
SEE ALSO
--------
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index b97aaab..cfa1e4e 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -65,7 +65,10 @@ OPTIONS
--remote=<repo>::
Instead of making a tar archive from the local repository,
- retrieve a tar archive from a remote repository.
+ retrieve a tar archive from a remote repository. Note that the
+ remote repository may place restrictions on which sha1
+ expressions may be allowed in `<tree-ish>`. See
+ linkgit:git-upload-archive[1] for details.
--exec=<git-upload-archive>::
Used with --remote to specify the path to the
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index 8e70a61..9f23a86 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -35,7 +35,8 @@ Apart from supporting file annotation, Git also supports searching the
development history for when a code snippet occurred in a change. This makes it
possible to track when a code snippet was added to a file, moved or copied
between files, and eventually deleted or replaced. It works by searching for
-a text string in the diff. A small example:
+a text string in the diff. A small example of the pickaxe interface
+that searches for `blame_usage`:
-----------------------------------------------------------------------------
$ git log --pretty=oneline -S'blame_usage'
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index c205d23..1c03c79 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -8,7 +8,8 @@ git-cherry-pick - Apply the changes introduced by some existing commits
SYNOPSIS
--------
[verse]
-'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit>...
+'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff]
+ [-S[<key-id>]] <commit>...
'git cherry-pick' --continue
'git cherry-pick' --quit
'git cherry-pick' --abort
@@ -100,6 +101,10 @@ effect to your index in a row.
--signoff::
Add Signed-off-by line at the end of the commit message.
+-S[<key-id>]::
+--gpg-sign[=<key-id>]::
+ GPG-sign commits.
+
--ff::
If the current HEAD is the same as the parent of the
cherry-pick'ed commit, then a fast forward to this commit will
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index bf3dac0..0363d00 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -55,15 +55,12 @@ repository is specified as a URL, then this flag is ignored (and we
never use the local optimizations). Specifying `--no-local` will
override the default when `/path/to/repo` is given, using the regular
Git transport instead.
-+
-To force copying instead of hardlinking (which may be desirable if you
-are trying to make a back-up of your repository), but still avoid the
-usual "Git aware" transport mechanism, `--no-hardlinks` can be used.
--no-hardlinks::
- Optimize the cloning process from a repository on a
- local filesystem by copying files under `.git/objects`
- directory.
+ Force the cloning process from a repository on a local
+ filesystem to copy the files under the `.git/objects`
+ directory instead of using hardlinks. This may be desirable
+ if you are trying to make a back-up of your repository.
--shared::
-s::
diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
index cafdc96..a469eab 100644
--- a/Documentation/git-commit-tree.txt
+++ b/Documentation/git-commit-tree.txt
@@ -55,8 +55,13 @@ OPTIONS
from the standard input.
-S[<keyid>]::
+--gpg-sign[=<keyid>]::
GPG-sign commit.
+--no-gpg-sign::
+ Countermand `commit.gpgsign` configuration variable that is
+ set to force each and every commit to be signed.
+
Commit Information
------------------
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 1a7616c..0bbc8f5 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[-F <file> | -m <msg>] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author=<author>]
[--date=<date>] [--cleanup=<mode>] [--[no-]status]
- [-i | -o] [-S[<keyid>]] [--] [<file>...]
+ [-i | -o] [-S[<key-id>]] [--] [<file>...]
DESCRIPTION
-----------
@@ -176,7 +176,7 @@ OPTIONS
--cleanup=<mode>::
This option determines how the supplied commit message should be
cleaned up before committing. The '<mode>' can be `strip`,
- `whitespace`, `verbatim`, or `default`.
+ `whitespace`, `verbatim`, `scissors` or `default`.
+
--
strip::
@@ -186,6 +186,12 @@ whitespace::
Same as `strip` except #commentary is not removed.
verbatim::
Do not change the message at all.
+scissors::
+ Same as `whitespace`, except that everything from (and
+ including) the line
+ "`# ------------------------ >8 ------------------------`"
+ is truncated if the message is to be edited. "`#`" can be
+ customized with core.commentChar.
default::
Same as `strip` if the message is to be edited.
Otherwise `whitespace`.
@@ -302,6 +308,10 @@ configuration variable documented in linkgit:git-config[1].
--gpg-sign[=<keyid>]::
GPG-sign commit.
+--no-gpg-sign::
+ Countermand `commit.gpgsign` configuration variable that is
+ set to force each and every commit to be signed.
+
\--::
Do not interpret any more arguments as options.
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index 2df9953..260f39f 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -21,8 +21,8 @@ DESCRIPTION
*WARNING:* `git cvsimport` uses cvsps version 2, which is considered
deprecated; it does not work with cvsps version 3 and later. If you are
performing a one-shot import of a CVS repository consider using
-link:http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or
-link:https://github.com/BartMassey/parsecvs[parsecvs].
+http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or
+https://github.com/BartMassey/parsecvs[parsecvs].
Imports a CVS repository into Git. It will either create a new
repository, or incrementally import into an existing one.
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 2eba627..09535f2 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -436,7 +436,7 @@ git-filter-branch allows you to make complex shell-scripted rewrites
of your Git history, but you probably don't need this flexibility if
you're simply _removing unwanted data_ like large files or passwords.
For those operations you may want to consider
-link:http://rtyley.github.io/bfg-repo-cleaner/[The BFG Repo-Cleaner],
+http://rtyley.github.io/bfg-repo-cleaner/[The BFG Repo-Cleaner],
a JVM-based alternative to git-filter-branch, typically at least
10-50x faster for those use-cases, and with quite different
characteristics:
@@ -455,7 +455,7 @@ characteristics:
_is_ possible to write filters that include their own parallellism,
in the scripts executed against each commit.
-* The link:http://rtyley.github.io/bfg-repo-cleaner/#examples[command options]
+* The http://rtyley.github.io/bfg-repo-cleaner/#examples[command options]
are much more restrictive than git-filter branch, and dedicated just
to the tasks of removing unwanted data- e.g:
`--strip-blobs-bigger-than 1M`.
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index e158a3b..273c466 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -124,6 +124,9 @@ the value, the more time is spent optimizing the delta compression. See
the documentation for the --window' option in linkgit:git-repack[1] for
more details. This defaults to 250.
+Similarly, the optional configuration variable 'gc.aggressiveDepth'
+controls --depth option in linkgit:git-repack[1]. This defaults to 250.
+
The optional configuration variable 'gc.pruneExpire' controls how old
the unreferenced loose objects have to be before they are pruned. The
default is "2 weeks ago".
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 4395459..a3c1fa3 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git merge' [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
- [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
+ [-s <strategy>] [-X <strategy-option>] [-S[<key-id>]]
[--[no-]rerere-autoupdate] [-m <msg>] [<commit>...]
'git merge' <msg> HEAD <commit>...
'git merge' --abort
diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
index 84bb0fe..310f0a5 100644
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -14,7 +14,7 @@ SYNOPSIS
'git notes' append [-F <file> | -m <msg> | (-c | -C) <object>] [<object>]
'git notes' edit [<object>]
'git notes' show [<object>]
-'git notes' merge [-v | -q] [-s <strategy> ] <notes_ref>
+'git notes' merge [-v | -q] [-s <strategy> ] <notes-ref>
'git notes' merge --commit [-v | -q]
'git notes' merge --abort [-v | -q]
'git notes' remove [--ignore-missing] [--stdin] [<object>...]
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index cdab9ed..d2d8f47 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -64,6 +64,8 @@ base-name::
the same way as 'git rev-list' with the `--objects` flag
uses its `commit` arguments to build the list of objects it
outputs. The objects on the resulting list are packed.
+ Besides revisions, `--not` or `--shallow <SHA-1>` lines are
+ also accepted.
--unpacked::
This implies `--revs`. When processing the list of
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 2b7f4f9..14862fb 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -83,8 +83,8 @@ the local side, the remote side is updated if a branch of the same name
already exists on the remote side.
--all::
- Instead of naming each ref to push, specifies that all
- refs under `refs/heads/` be pushed.
+ Push all branches (i.e. refs under `refs/heads/`); cannot be
+ used with other <refspec>.
--prune::
Remove remote branches that don't have a local counterpart. For example
@@ -442,8 +442,10 @@ Examples
configured for the current branch).
`git push origin`::
- Without additional configuration, works like
- `git push origin :`.
+ Without additional configuration, pushes the current branch to
+ the configured upstream (`remote.origin.merge` configuration
+ variable) if it has the same name as the current branch, and
+ errors out without pushing otherwise.
+
The default behavior of this command when no <refspec> is given can be
configured by setting the `push` option of the remote, or the `push.default`
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 2889be6..2a93c64 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -281,6 +281,10 @@ which makes little sense.
specified, `-s recursive`. Note the reversal of 'ours' and
'theirs' as noted above for the `-m` option.
+-S[<keyid>]::
+--gpg-sign[=<keyid>]::
+ GPG-sign commits.
+
-q::
--quiet::
Be quiet. Implies --no-stat.
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 2507c8b..cb103c8 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -3,7 +3,7 @@ git-remote(1)
NAME
----
-git-remote - manage set of tracked repositories
+git-remote - Manage set of tracked repositories
SYNOPSIS
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 509cf73..4786a78 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -9,7 +9,7 @@ git-repack - Pack unpacked objects in a repository
SYNOPSIS
--------
[verse]
-'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [--window=<n>] [--depth=<n>]
+'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [-b] [--window=<n>] [--depth=<n>]
DESCRIPTION
-----------
@@ -110,6 +110,21 @@ other objects in that pack they already have locally.
The default is unlimited, unless the config variable
`pack.packSizeLimit` is set.
+-b::
+--write-bitmap-index::
+ Write a reachability bitmap index as part of the repack. This
+ only makes sense when used with `-a` or `-A`, as the bitmaps
+ must be able to refer to all reachable objects. This option
+ overrides the setting of `pack.writebitmaps`.
+
+--pack-kept-objects::
+ Include objects in `.keep` files when repacking. Note that we
+ still do not delete `.keep` packs after `pack-objects` finishes.
+ This means that we may duplicate objects, but this makes the
+ option safe to use when there are concurrent pushes or fetches.
+ This option is generally only useful if you are writing bitmaps
+ with `-b` or `pack.writebitmaps`, as it ensures that the
+ bitmapped packfile has the necessary objects.
Configuration
-------------
diff --git a/Documentation/git-request-pull.txt b/Documentation/git-request-pull.txt
index b99681c..283577b 100644
--- a/Documentation/git-request-pull.txt
+++ b/Documentation/git-request-pull.txt
@@ -13,22 +13,65 @@ SYNOPSIS
DESCRIPTION
-----------
-Summarizes the changes between two commits to the standard output, and includes
-the given URL in the generated summary.
+Generate a request asking your upstream project to pull changes into
+their tree. The request, printed to the standard output, summarizes
+the changes and indicates from where they can be pulled.
+
+The upstream project is expected to have the commit named by
+`<start>` and the output asks it to integrate the changes you made
+since that commit, up to the commit named by `<end>`, by visiting
+the repository named by `<url>`.
+
OPTIONS
-------
-p::
- Show patch text
+ Include patch text in the output.
<start>::
- Commit to start at.
+ Commit to start at. This names a commit that is already in
+ the upstream history.
<url>::
- URL to include in the summary.
+ The repository URL to be pulled from.
<end>::
- Commit to end at; defaults to HEAD.
+ Commit to end at (defaults to HEAD). This names the commit
+ at the tip of the history you are asking to be pulled.
++
+When the repository named by `<url>` has the commit at a tip of a
+ref that is different from the ref you have locally, you can use the
+`<local>:<remote>` syntax, to have its local name, a colon `:`, and
+its remote name.
+
+
+EXAMPLE
+-------
+
+Imagine that you built your work on your `master` branch on top of
+the `v1.0` release, and want it to be integrated to the project.
+First you push that change to your public repository for others to
+see:
+
+ git push https://git.ko.xz/project master
+
+Then, you run this command:
+
+ git request-pull v1.0 https://git.ko.xz/project master
+
+which will produce a request to the upstream, summarizing the
+changes between the `v1.0` release and your `master`, to pull it
+from your public repository.
+
+If you pushed your change to a branch whose name is different from
+the one you have locally, e.g.
+
+ git push https://git.ko.xz/project master:for-linus
+
+then you can ask that to be pulled with
+
+ git request-pull v1.0 https://git.ko.xz/project master:for-linus
+
GIT
---
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index f445cb3..a077ba0 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -10,7 +10,7 @@ SYNOPSIS
[verse]
'git reset' [-q] [<tree-ish>] [--] <paths>...
'git reset' (--patch | -p) [<tree-ish>] [--] [<paths>...]
-'git reset' [--soft | --mixed | --hard | --merge | --keep] [-q] [<commit>]
+'git reset' [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<commit>]
DESCRIPTION
-----------
@@ -60,6 +60,9 @@ section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
Resets the index but not the working tree (i.e., the changed files
are preserved but not marked for commit) and reports what has not
been updated. This is the default action.
++
+If `-N` is specified, removed paths are marked as intent-to-add (see
+linkgit:git-add[1]).
--hard::
Resets the index and working tree. Any changes to tracked files in the
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 045b37b..7a1585d 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -55,6 +55,7 @@ SYNOPSIS
[ \--reverse ]
[ \--walk-reflogs ]
[ \--no-walk ] [ \--do-walk ]
+ [ \--use-bitmap-index ]
<commit>... [ \-- <paths>... ]
DESCRIPTION
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 0d2cdcd..987395d 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -284,20 +284,20 @@ Input Format
'git rev-parse --parseopt' input format is fully text based. It has two parts,
separated by a line that contains only `--`. The lines before the separator
-(should be more than one) are used for the usage.
+(should be one or more) are used for the usage.
The lines after the separator describe the options.
Each line of options has this format:
------------
-<opt_spec><flags>* SP+ help LF
+<opt-spec><flags>*<arg-hint>? SP+ help LF
------------
-`<opt_spec>`::
+`<opt-spec>`::
its format is the short option character, then the long option name
separated by a comma. Both parts are not required, though at least one
is necessary. `h,help`, `dry-run` and `f` are all three correct
- `<opt_spec>`.
+ `<opt-spec>`.
`<flags>`::
`<flags>` are of `*`, `=`, `?` or `!`.
@@ -313,6 +313,12 @@ Each line of options has this format:
* Use `!` to not make the corresponding negated long option available.
+`<arg-hint>`::
+ `<arg-hint>`, if specified, is used as a name of the argument in the
+ help output, for options that take arguments. `<arg-hint>` is
+ terminated by the first whitespace. It is customary to use a
+ dash to separate words in a multi-word argument hint.
+
The remainder of the line, after stripping the spaces, is used
as the help associated to the option.
@@ -333,6 +339,8 @@ h,help show the help
foo some nifty option --foo
bar= some cool option --bar with an argument
+baz=arg another cool option --baz with a named argument
+qux?path qux may take a path argument but has meaning by itself
An option group Header
C? option C with an optional argument"
@@ -340,6 +348,28 @@ C? option C with an optional argument"
eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"
------------
+
+Usage text
+~~~~~~~~~~
+
+When `"$@"` is `-h` or `--help` in the above example, the following
+usage text would be shown:
+
+------------
+usage: some-command [options] <args>...
+
+ some-command does foo and bar!
+
+ -h, --help show the help
+ --foo some nifty option --foo
+ --bar ... some cool option --bar with an argument
+ --baz <arg> another cool option --baz with a named argument
+ --qux[=<path>] qux may take a path argument but has meaning by itself
+
+An option group Header
+ -C[...] option C with an optional argument
+------------
+
SQ-QUOTE
--------
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index 2de67a5..cceb5f2 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -8,7 +8,7 @@ git-revert - Revert some existing commits
SYNOPSIS
--------
[verse]
-'git revert' [--[no-]edit] [-n] [-m parent-number] [-s] <commit>...
+'git revert' [--[no-]edit] [-n] [-m parent-number] [-s] [-S[<key-id>]] <commit>...
'git revert' --continue
'git revert' --quit
'git revert' --abort
@@ -80,6 +80,10 @@ more details.
This is useful when reverting more than one commits'
effect to your index in a row.
+-S[<key-id>]::
+--gpg-sign[=<key-id>]::
+ GPG-sign commits.
+
-s::
--signoff::
Add Signed-off-by line at the end of the commit message.
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index db7e803..375213f 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -44,7 +44,7 @@ is also possible).
OPTIONS
-------
-save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]::
+save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]::
Save your local modifications to a new 'stash', and run `git reset
--hard` to revert them. The <message> part is optional and gives
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index a4acaa0..def635f 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -97,7 +97,7 @@ configuration variable documented in linkgit:git-config[1].
OUTPUT
------
The output from this command is designed to be used as a commit
-template comment, and all the output lines are prefixed with '#'.
+template comment.
The default, long format, is designed to be human readable,
verbose and descriptive. Its contents and format are subject to change
at any time.
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index bfef8a0..89c4d3e 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -15,8 +15,8 @@ SYNOPSIS
'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>] [--depth <depth>]
- [--merge] [--recursive] [--] [<path>...]
+ [-f|--force] [--rebase|--merge] [--reference <repository>]
+ [--depth <depth>] [--recursive] [--] [<path>...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
[commit] [--] [<path>...]
'git submodule' [--quiet] foreach [--recursive] <command>
@@ -229,7 +229,7 @@ OPTIONS
-b::
--branch::
Branch of repository to add as submodule.
- The name of the branch is recorded as `submodule.<path>.branch` in
+ The name of the branch is recorded as `submodule.<name>.branch` in
`.gitmodules` for `update --remote`.
-f::
@@ -281,12 +281,31 @@ In order to ensure a current tracking branch state, `update --remote`
fetches the submodule's remote repository before calculating the
SHA-1. If you don't want to fetch, you should use `submodule update
--remote --no-fetch`.
++
+Use this option to integrate changes from the upstream subproject with
+your submodule's current HEAD. Alternatively, you can run `git pull`
+from the submodule, which is equivalent except for the remote branch
+name: `update --remote` uses the default upstream repository and
+`submodule.<name>.branch`, while `git pull` uses the submodule's
+`branch.<name>.merge`. Prefer `submodule.<name>.branch` if you want
+to distribute the default upstream branch with the superproject and
+`branch.<name>.merge` if you want a more native feel while working in
+the submodule itself.
-N::
--no-fetch::
This option is only valid for the update command.
Don't fetch new objects from the remote site.
+--checkout::
+ This option is only valid for the update command.
+ Checkout the commit recorded in the superproject on a detached HEAD
+ in the submodule. This is the default behavior, the main use of
+ this option is to override `submodule.$name.update` when set to
+ `merge`, `rebase` or `none`.
+ If the key `submodule.$name.update` is either not explicitly set or
+ set to `checkout`, this option is implicit.
+
--merge::
This option is only valid for the update command.
Merge the commit recorded in the superproject into the current branch
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 404257d..b424a1b 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -95,6 +95,12 @@ OPTIONS
using fnmatch(3)). Multiple patterns may be given; if any of
them matches, the tag is shown.
+--sort=<type>::
+ Sort in a specific order. Supported type is "refname"
+ (lexicographic order), "version:refname" or "v:refname" (tag
+ names are treated as versions). Prepend "-" to reverse sort
+ order.
+
--column[=<options>]::
--no-column::
Display tag listing in columns. See configuration variable
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index e0a8702..d6de4a0 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -12,7 +12,7 @@ SYNOPSIS
'git update-index'
[--add] [--remove | --force-remove] [--replace]
[--refresh] [-q] [--unmerged] [--ignore-missing]
- [(--cacheinfo <mode> <object> <file>)...]
+ [(--cacheinfo <mode>,<object>,<file>)...]
[--chmod=(+|-)x]
[--[no-]assume-unchanged]
[--[no-]skip-worktree]
@@ -68,8 +68,12 @@ OPTIONS
--ignore-missing::
Ignores missing files during a --refresh
+--cacheinfo <mode>,<object>,<path>::
--cacheinfo <mode> <object> <path>::
- Directly insert the specified info into the index.
+ Directly insert the specified info into the index. For
+ backward compatibility, you can also give these three
+ arguments as three separate parameters, but new users are
+ encouraged to use a single-parameter form.
--index-info::
Read index information from stdin.
diff --git a/Documentation/git-upload-archive.txt b/Documentation/git-upload-archive.txt
index d09bbb5..cbef61b 100644
--- a/Documentation/git-upload-archive.txt
+++ b/Documentation/git-upload-archive.txt
@@ -20,6 +20,38 @@ This command is usually not invoked directly by the end user. The UI
for the protocol is on the 'git archive' side, and the program pair
is meant to be used to get an archive from a remote repository.
+SECURITY
+--------
+
+In order to protect the privacy of objects that have been removed from
+history but may not yet have been pruned, `git-upload-archive` avoids
+serving archives for commits and trees that are not reachable from the
+repository's refs. However, because calculating object reachability is
+computationally expensive, `git-upload-archive` implements a stricter
+but easier-to-check set of rules:
+
+ 1. Clients may request a commit or tree that is pointed to directly by
+ a ref. E.g., `git archive --remote=origin v1.0`.
+
+ 2. Clients may request a sub-tree within a commit or tree using the
+ `ref:path` syntax. E.g., `git archive --remote=origin v1.0:Documentation`.
+
+ 3. Clients may _not_ use other sha1 expressions, even if the end
+ result is reachable. E.g., neither a relative commit like `master^`
+ nor a literal sha1 like `abcd1234` is allowed, even if the result
+ is reachable from the refs.
+
+Note that rule 3 disallows many cases that do not have any privacy
+implications. These rules are subject to change in future versions of
+git, and the server accessed by `git archive --remote` may or may not
+follow these exact rules.
+
+If the config option `uploadArchive.allowUnreachable` is true, these
+rules are ignored, and clients may use arbitrary sha1 expressions.
+This is useful if you do not care about the privacy of unreachable
+objects, or if your object database is already publicly available for
+access via non-smart-http.
+
OPTIONS
-------
<directory>::
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 02bbc08..e5f8ed0 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -43,9 +43,10 @@ unreleased) version of Git, that is available from 'master'
branch of the `git.git` repository.
Documentation for older releases are available here:
-* link:v1.9.0/git.html[documentation for release 1.9.0]
+* link:v1.9.1/git.html[documentation for release 1.9.1]
* release notes for
+ link:RelNotes/1.9.1.txt[1.9.1],
link:RelNotes/1.9.0.txt[1.9.0].
* link:v1.8.5.5/git.html[documentation for release 1.8.5.5]
@@ -720,6 +721,11 @@ Git so take care if using Cogito etc.
index file. If not specified, the default of `$GIT_DIR/index`
is used.
+'GIT_INDEX_VERSION'::
+ This environment variable allows the specification of an index
+ version for new repositories. It won't affect existing index
+ files. By default index file version [23] is used.
+
'GIT_OBJECT_DIRECTORY'::
If the object storage directory is specified via this
environment variable then the sha1 directories are created
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 058a352..d2d7c21 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -1443,7 +1443,7 @@ Although Git is a truly distributed system, it is often
convenient to organize your project with an informal hierarchy
of developers. Linux kernel development is run this way. There
is a nice illustration (page 17, "Merges to Mainline") in
-link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation].
+http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation].
It should be stressed that this hierarchy is purely *informal*.
There is nothing fundamental in Git that enforces the "chain of
diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt
index 5ea94cb..5f4e890 100644
--- a/Documentation/gitcvs-migration.txt
+++ b/Documentation/gitcvs-migration.txt
@@ -117,7 +117,7 @@ Importing a CVS archive
-----------------------
First, install version 2.1 or higher of cvsps from
-link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make
+http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make
sure it is in your path. Then cd to a checked out CVS working directory
of the project you are interested in and run linkgit:git-cvsimport[1]:
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index b08d34d..8734c15 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -77,6 +77,9 @@ PATTERN FORMAT
Put a backslash ("`\`") in front of the first hash for patterns
that begin with a hash.
+ - Trailing spaces are ignored unless they are quoted with backlash
+ ("`\`").
+
- An optional prefix "`!`" which negates the pattern; any
matching file excluded by a previous pattern will become
included again. It is not possible to re-include a file if a parent
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index 1e9e38a..7e03fcc 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -166,8 +166,14 @@ gitk --max-count=100 --all \-- Makefile::
Files
-----
-Gitk creates the .gitk file in your $HOME directory to store preferences
-such as display options, font, and colors.
+User configuration and preferences are stored at:
+
+* '$XDG_CONFIG_HOME/git/gitk' if it exists, otherwise
+* '$HOME/.gitk' if it exists
+
+If neither of the above exist then '$XDG_CONFIG_HOME/git/gitk' is created and
+used by default. If '$XDG_CONFIG_HOME' is not set it defaults to
+'$HOME/.config' in all cases.
History
-------
diff --git a/Documentation/gitremote-helpers.txt b/Documentation/gitremote-helpers.txt
index c2908db..64f7ad2 100644
--- a/Documentation/gitremote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -437,6 +437,10 @@ set by Git if the remote helper has the 'option' capability.
'option check-connectivity' \{'true'|'false'\}::
Request the helper to check connectivity of a clone.
+'option force' \{'true'|'false'\}::
+ Request the helper to perform a force update. Defaults to
+ 'false'.
+
'option cloning \{'true'|'false'\}::
Notify the helper this is a clone request (i.e. the current
repository is guaranteed empty).
diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
index aa03882..17d2ea6 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -176,6 +176,10 @@ info/grafts::
per line describes a commit and its fake parents by
listing their 40-byte hexadecimal object names separated
by a space and terminated by a newline.
++
+Note that the grafts mechanism is outdated and can lead to problems
+transferring objects between repositories; see linkgit:git-replace[1]
+for a more flexible and robust system to do the same thing.
info/exclude::
This file, by convention among Porcelains, stores the
diff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt
index cca14b8..cd9c895 100644
--- a/Documentation/gitweb.txt
+++ b/Documentation/gitweb.txt
@@ -84,7 +84,7 @@ separator (rules for Perl's "`split(" ", $line)`").
* Fields use modified URI encoding, defined in RFC 3986, section 2.1
(Percent-Encoding), or rather "Query string encoding" (see
-link:http://en.wikipedia.org/wiki/Query_string#URL_encoding[]), the difference
+http://en.wikipedia.org/wiki/Query_string#URL_encoding[]), the difference
being that SP (" ") can be encoded as "{plus}" (and therefore "{plus}" has to be
also percent-encoded).
+
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index 378306f..be0858c 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -176,6 +176,10 @@ current branch integrates with) obviously do not work, as there is no
you can make Git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has
is different from what was recorded when the commit was
created. Configured via the `.git/info/grafts` file.
++
+Note that the grafts mechanism is outdated and can lead to problems
+transferring objects between repositories; see linkgit:git-replace[1]
+for a more flexible and robust system to do the same thing.
[[def_hash]]hash::
In Git's context, synonym for <<def_object_name,object name>>.
diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index fb6e593..7bbd19b 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -1,10 +1,10 @@
MERGE STRATEGIES
----------------
-The merge mechanism ('git-merge' and 'git-pull' commands) allows the
+The merge mechanism (`git merge` and `git pull` commands) allows the
backend 'merge strategies' to be chosen with `-s` option. Some strategies
can also take their own options, which can be passed by giving `-X<option>`
-arguments to 'git-merge' and/or 'git-pull'.
+arguments to `git merge` and/or `git pull`.
resolve::
This can only resolve two heads (i.e. the current branch
@@ -20,7 +20,7 @@ recursive::
merged tree of the common ancestors and uses that as
the reference tree for the 3-way merge. This has been
reported to result in fewer merge conflicts without
- causing mis-merges by tests done on actual merge commits
+ causing mismerges by tests done on actual merge commits
taken from Linux 2.6 kernel development history.
Additionally this can detect and handle merges involving
renames. This is the default merge strategy when
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 03533af..b813961 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -257,6 +257,14 @@ See also linkgit:git-reflog[1].
Output excluded boundary commits. Boundary commits are
prefixed with `-`.
+ifdef::git-rev-list[]
+--use-bitmap-index::
+
+ Try to speed up the traversal using the pack bitmap index (if
+ one is available). Note that when traversing with `--objects`,
+ trees and blobs will not have their associated path printed.
+endif::git-rev-list[]
+
--
History Simplification
@@ -750,6 +758,13 @@ This enables parent rewriting, see 'History Simplification' below.
This implies the `--topo-order` option by default, but the
`--date-order` option may also be specified.
+--show-linear-break[=<barrier>]::
+ When --graph is not used, all history branches are flattened
+ which can make it hard to see that the two consecutive commits
+ do not belong to a linear branch. This option puts a barrier
+ in between them in that case. If `<barrier>` is specified, it
+ is the string that will be shown instead of the default one.
+
ifdef::git-rev-list[]
--count::
Print a number stating how many commits would have been
diff --git a/Documentation/technical/api-hash.txt b/Documentation/technical/api-hash.txt
deleted file mode 100644
index e5061e0..0000000
--- a/Documentation/technical/api-hash.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-hash API
-========
-
-The hash API is a collection of simple hash table functions. Users are expected
-to implement their own hashing.
-
-Data Structures
----------------
-
-`struct hash_table`::
-
- The hash table structure. The `array` member points to the hash table
- entries. The `size` member counts the total number of valid and invalid
- entries in the table. The `nr` member keeps track of the number of
- valid entries.
-
-`struct hash_table_entry`::
-
- An opaque structure representing an entry in the hash table. The `hash`
- member is the entry's hash key and the `ptr` member is the entry's
- value.
-
-Functions
----------
-
-`init_hash`::
-
- Initialize the hash table.
-
-`free_hash`::
-
- Release memory associated with the hash table.
-
-`insert_hash`::
-
- Insert a pointer into the hash table. If an entry with that hash
- already exists, a pointer to the existing entry's value is returned.
- Otherwise NULL is returned. This allows callers to implement
- chaining, etc.
-
-`lookup_hash`::
-
- Lookup an entry in the hash table. If an entry with that hash exists
- the entry's value is returned. Otherwise NULL is returned.
-
-`for_each_hash`::
-
- Call a function for each entry in the hash table. The function is
- expected to take the entry's value as its only argument and return an
- int. If the function returns a negative int the loop is aborted
- immediately. Otherwise, the return value is accumulated and the sum
- returned upon completion of the loop.
diff --git a/Documentation/technical/api-hashmap.txt b/Documentation/technical/api-hashmap.txt
new file mode 100644
index 0000000..42ca234
--- /dev/null
+++ b/Documentation/technical/api-hashmap.txt
@@ -0,0 +1,235 @@
+hashmap API
+===========
+
+The hashmap API is a generic implementation of hash-based key-value mappings.
+
+Data Structures
+---------------
+
+`struct hashmap`::
+
+ The hash table structure.
++
+The `size` member keeps track of the total number of entries. The `cmpfn`
+member is a function used to compare two entries for equality. The `table` and
+`tablesize` members store the hash table and its size, respectively.
+
+`struct hashmap_entry`::
+
+ An opaque structure representing an entry in the hash table, which must
+ be used as first member of user data structures. Ideally it should be
+ followed by an int-sized member to prevent unused memory on 64-bit
+ systems due to alignment.
++
+The `hash` member is the entry's hash code and the `next` member points to the
+next entry in case of collisions (i.e. if multiple entries map to the same
+bucket).
+
+`struct hashmap_iter`::
+
+ An iterator structure, to be used with hashmap_iter_* functions.
+
+Types
+-----
+
+`int (*hashmap_cmp_fn)(const void *entry, const void *entry_or_key, const void *keydata)`::
+
+ User-supplied function to test two hashmap entries for equality. Shall
+ return 0 if the entries are equal.
++
+This function is always called with non-NULL `entry` / `entry_or_key`
+parameters that have the same hash code. When looking up an entry, the `key`
+and `keydata` parameters to hashmap_get and hashmap_remove are always passed
+as second and third argument, respectively. Otherwise, `keydata` is NULL.
+
+Functions
+---------
+
+`unsigned int strhash(const char *buf)`::
+`unsigned int strihash(const char *buf)`::
+`unsigned int memhash(const void *buf, size_t len)`::
+`unsigned int memihash(const void *buf, size_t len)`::
+
+ Ready-to-use hash functions for strings, using the FNV-1 algorithm (see
+ http://www.isthe.com/chongo/tech/comp/fnv).
++
+`strhash` and `strihash` take 0-terminated strings, while `memhash` and
+`memihash` operate on arbitrary-length memory.
++
+`strihash` and `memihash` are case insensitive versions.
+
+`void hashmap_init(struct hashmap *map, hashmap_cmp_fn equals_function, size_t initial_size)`::
+
+ Initializes a hashmap structure.
++
+`map` is the hashmap to initialize.
++
+The `equals_function` can be specified to compare two entries for equality.
+If NULL, entries are considered equal if their hash codes are equal.
++
+If the total number of entries is known in advance, the `initial_size`
+parameter may be used to preallocate a sufficiently large table and thus
+prevent expensive resizing. If 0, the table is dynamically resized.
+
+`void hashmap_free(struct hashmap *map, int free_entries)`::
+
+ Frees a hashmap structure and allocated memory.
++
+`map` is the hashmap to free.
++
+If `free_entries` is true, each hashmap_entry in the map is freed as well
+(using stdlib's free()).
+
+`void hashmap_entry_init(void *entry, unsigned int hash)`::
+
+ Initializes a hashmap_entry structure.
++
+`entry` points to the entry to initialize.
++
+`hash` is the hash code of the entry.
+
+`void *hashmap_get(const struct hashmap *map, const void *key, const void *keydata)`::
+
+ Returns the hashmap entry for the specified key, or NULL if not found.
++
+`map` is the hashmap structure.
++
+`key` is a hashmap_entry structure (or user data structure that starts with
+hashmap_entry) that has at least been initialized with the proper hash code
+(via `hashmap_entry_init`).
++
+If an entry with matching hash code is found, `key` and `keydata` are passed
+to `hashmap_cmp_fn` to decide whether the entry matches the key.
+
+`void *hashmap_get_next(const struct hashmap *map, const void *entry)`::
+
+ Returns the next equal hashmap entry, or NULL if not found. This can be
+ used to iterate over duplicate entries (see `hashmap_add`).
++
+`map` is the hashmap structure.
++
+`entry` is the hashmap_entry to start the search from, obtained via a previous
+call to `hashmap_get` or `hashmap_get_next`.
+
+`void hashmap_add(struct hashmap *map, void *entry)`::
+
+ Adds a hashmap entry. This allows to add duplicate entries (i.e.
+ separate values with the same key according to hashmap_cmp_fn).
++
+`map` is the hashmap structure.
++
+`entry` is the entry to add.
+
+`void *hashmap_put(struct hashmap *map, void *entry)`::
+
+ Adds or replaces a hashmap entry. If the hashmap contains duplicate
+ entries equal to the specified entry, only one of them will be replaced.
++
+`map` is the hashmap structure.
++
+`entry` is the entry to add or replace.
++
+Returns the replaced entry, or NULL if not found (i.e. the entry was added).
+
+`void *hashmap_remove(struct hashmap *map, const void *key, const void *keydata)`::
+
+ Removes a hashmap entry matching the specified key. If the hashmap
+ contains duplicate entries equal to the specified key, only one of
+ them will be removed.
++
+`map` is the hashmap structure.
++
+`key` is a hashmap_entry structure (or user data structure that starts with
+hashmap_entry) that has at least been initialized with the proper hash code
+(via `hashmap_entry_init`).
++
+If an entry with matching hash code is found, `key` and `keydata` are
+passed to `hashmap_cmp_fn` to decide whether the entry matches the key.
++
+Returns the removed entry, or NULL if not found.
+
+`void hashmap_iter_init(struct hashmap *map, struct hashmap_iter *iter)`::
+`void *hashmap_iter_next(struct hashmap_iter *iter)`::
+`void *hashmap_iter_first(struct hashmap *map, struct hashmap_iter *iter)`::
+
+ Used to iterate over all entries of a hashmap.
++
+`hashmap_iter_init` initializes a `hashmap_iter` structure.
++
+`hashmap_iter_next` returns the next hashmap_entry, or NULL if there are no
+more entries.
++
+`hashmap_iter_first` is a combination of both (i.e. initializes the iterator
+and returns the first entry, if any).
+
+Usage example
+-------------
+
+Here's a simple usage example that maps long keys to double values.
+[source,c]
+------------
+struct hashmap map;
+
+struct long2double {
+ struct hashmap_entry ent; /* must be the first member! */
+ long key;
+ double value;
+};
+
+static int long2double_cmp(const struct long2double *e1, const struct long2double *e2, const void *unused)
+{
+ return !(e1->key == e2->key);
+}
+
+void long2double_init(void)
+{
+ hashmap_init(&map, (hashmap_cmp_fn) long2double_cmp, 0);
+}
+
+void long2double_free(void)
+{
+ hashmap_free(&map, 1);
+}
+
+static struct long2double *find_entry(long key)
+{
+ struct long2double k;
+ hashmap_entry_init(&k, memhash(&key, sizeof(long)));
+ k.key = key;
+ return hashmap_get(&map, &k, NULL);
+}
+
+double get_value(long key)
+{
+ struct long2double *e = find_entry(key);
+ return e ? e->value : 0;
+}
+
+void set_value(long key, double value)
+{
+ struct long2double *e = find_entry(key);
+ if (!e) {
+ e = malloc(sizeof(struct long2double));
+ hashmap_entry_init(e, memhash(&key, sizeof(long)));
+ e->key = key;
+ hashmap_add(&map, e);
+ }
+ e->value = value;
+}
+------------
+
+Using variable-sized keys
+-------------------------
+
+The `hashmap_entry_get` and `hashmap_entry_remove` functions expect an ordinary
+`hashmap_entry` structure as key to find the correct entry. If the key data is
+variable-sized (e.g. a FLEX_ARRAY string) or quite large, it is undesirable
+to create a full-fledged entry structure on the heap and copy all the key data
+into the structure.
+
+In this case, the `keydata` parameter can be used to pass
+variable-sized key data directly to the comparison function, and the `key`
+parameter can be a stripped-down, fixed size entry structure allocated on the
+stack.
+
+See test-hashmap.c for an example using arbitrary-length strings as keys.
diff --git a/Documentation/technical/bitmap-format.txt b/Documentation/technical/bitmap-format.txt
new file mode 100644
index 0000000..f8c18a0
--- /dev/null
+++ b/Documentation/technical/bitmap-format.txt
@@ -0,0 +1,164 @@
+GIT bitmap v1 format
+====================
+
+ - A header appears at the beginning:
+
+ 4-byte signature: {'B', 'I', 'T', 'M'}
+
+ 2-byte version number (network byte order)
+ The current implementation only supports version 1
+ of the bitmap index (the same one as JGit).
+
+ 2-byte flags (network byte order)
+
+ The following flags are supported:
+
+ - BITMAP_OPT_FULL_DAG (0x1) REQUIRED
+ This flag must always be present. It implies that the bitmap
+ index has been generated for a packfile with full closure
+ (i.e. where every single object in the packfile can find
+ its parent links inside the same packfile). This is a
+ requirement for the bitmap index format, also present in JGit,
+ that greatly reduces the complexity of the implementation.
+
+ - BITMAP_OPT_HASH_CACHE (0x4)
+ If present, the end of the bitmap file contains
+ `N` 32-bit name-hash values, one per object in the
+ pack. The format and meaning of the name-hash is
+ described below.
+
+ 4-byte entry count (network byte order)
+
+ The total count of entries (bitmapped commits) in this bitmap index.
+
+ 20-byte checksum
+
+ The SHA1 checksum of the pack this bitmap index belongs to.
+
+ - 4 EWAH bitmaps that act as type indexes
+
+ Type indexes are serialized after the hash cache in the shape
+ of four EWAH bitmaps stored consecutively (see Appendix A for
+ the serialization format of an EWAH bitmap).
+
+ There is a bitmap for each Git object type, stored in the following
+ order:
+
+ - Commits
+ - Trees
+ - Blobs
+ - Tags
+
+ In each bitmap, the `n`th bit is set to true if the `n`th object
+ in the packfile is of that type.
+
+ The obvious consequence is that the OR of all 4 bitmaps will result
+ in a full set (all bits set), and the AND of all 4 bitmaps will
+ result in an empty bitmap (no bits set).
+
+ - N entries with compressed bitmaps, one for each indexed commit
+
+ Where `N` is the total amount of entries in this bitmap index.
+ Each entry contains the following:
+
+ - 4-byte object position (network byte order)
+ The position **in the index for the packfile** where the
+ bitmap for this commit is found.
+
+ - 1-byte XOR-offset
+ The xor offset used to compress this bitmap. For an entry
+ in position `x`, a XOR offset of `y` means that the actual
+ bitmap representing this commit is composed by XORing the
+ bitmap for this entry with the bitmap in entry `x-y` (i.e.
+ the bitmap `y` entries before this one).
+
+ Note that this compression can be recursive. In order to
+ XOR this entry with a previous one, the previous entry needs
+ to be decompressed first, and so on.
+
+ The hard-limit for this offset is 160 (an entry can only be
+ xor'ed against one of the 160 entries preceding it). This
+ number is always positive, and hence entries are always xor'ed
+ with **previous** bitmaps, not bitmaps that will come afterwards
+ in the index.
+
+ - 1-byte flags for this bitmap
+ At the moment the only available flag is `0x1`, which hints
+ that this bitmap can be re-used when rebuilding bitmap indexes
+ for the repository.
+
+ - The compressed bitmap itself, see Appendix A.
+
+== Appendix A: Serialization format for an EWAH bitmap
+
+Ewah bitmaps are serialized in the same protocol as the JAVAEWAH
+library, making them backwards compatible with the JGit
+implementation:
+
+ - 4-byte number of bits of the resulting UNCOMPRESSED bitmap
+
+ - 4-byte number of words of the COMPRESSED bitmap, when stored
+
+ - N x 8-byte words, as specified by the previous field
+
+ This is the actual content of the compressed bitmap.
+
+ - 4-byte position of the current RLW for the compressed
+ bitmap
+
+All words are stored in network byte order for their corresponding
+sizes.
+
+The compressed bitmap is stored in a form of run-length encoding, as
+follows. It consists of a concatenation of an arbitrary number of
+chunks. Each chunk consists of one or more 64-bit words
+
+ H L_1 L_2 L_3 .... L_M
+
+H is called RLW (run length word). It consists of (from lower to higher
+order bits):
+
+ - 1 bit: the repeated bit B
+
+ - 32 bits: repetition count K (unsigned)
+
+ - 31 bits: literal word count M (unsigned)
+
+The bitstream represented by the above chunk is then:
+
+ - K repetitions of B
+
+ - The bits stored in `L_1` through `L_M`. Within a word, bits at
+ lower order come earlier in the stream than those at higher
+ order.
+
+The next word after `L_M` (if any) must again be a RLW, for the next
+chunk. For efficient appending to the bitstream, the EWAH stores a
+pointer to the last RLW in the stream.
+
+
+== Appendix B: Optional Bitmap Sections
+
+These sections may or may not be present in the `.bitmap` file; their
+presence is indicated by the header flags section described above.
+
+Name-hash cache
+---------------
+
+If the BITMAP_OPT_HASH_CACHE flag is set, the end of the bitmap contains
+a cache of 32-bit values, one per object in the pack. The value at
+position `i` is the hash of the pathname at which the `i`th object
+(counting in index order) in the pack can be found. This can be fed
+into the delta heuristics to compare objects with similar pathnames.
+
+The hash algorithm used is:
+
+ hash = 0;
+ while ((c = *name++))
+ if (!isspace(c))
+ hash = (hash >> 2) + (c << 24);
+
+Note that this hashing scheme is tied to the BITMAP_OPT_HASH_CACHE flag.
+If implementations want to choose a different hashing scheme, they are
+free to do so, but MUST allocate a new header flag (because comparing
+hashes made under two different schemes would be pointless).
diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt
index 544373b..20525d9 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -500,7 +500,7 @@ TODO: Document this further.
References
----------
-link:http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)]
-link:http://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1]
+http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)]
+http://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1]
link:technical/pack-protocol.html
link:technical/protocol-capabilities.html
diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt
index c73b62f..39c6410 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -338,7 +338,8 @@ during a prior round. This helps to ensure that at least one common
ancestor is found before we give up entirely.
Once the 'done' line is read from the client, the server will either
-send a final 'ACK obj-id' or it will send a 'NAK'. The server only sends
+send a final 'ACK obj-id' or it will send a 'NAK'. 'obj-id' is the object
+name of the last commit determined to be common. The server only sends
ACK after 'done' if there is at least one common base and multi_ack or
multi_ack_detailed is enabled. The server always sends NAK after 'done'
if there is no common base found.
diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt
index e3e7924..e174343 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -69,6 +69,24 @@ ends.
Without multi_ack the client would have sent that c-b-a chain anyway,
interleaved with S-R-Q.
+multi_ack_detailed
+------------------
+This is an extension of multi_ack that permits client to better
+understand the server's in-memory state. See pack-protocol.txt,
+section "Packfile Negotiation" for more information.
+
+no-done
+-------
+This capability should only be used with the smart HTTP protocol. If
+multi_ack_detailed and no-done are both present, then the sender is
+free to immediately send a pack following its first "ACK obj-id ready"
+message.
+
+Without no-done in the smart HTTP protocol, the server session would
+end and the client has to make another trip to send "done" before
+the server can send the pack. no-done removes the last round and
+thus slightly reduces latency.
+
thin-pack
---------