diff options
Diffstat (limited to 'Documentation')
79 files changed, 1739 insertions, 604 deletions
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index ef67b53f72..ed432a80ca 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/Makefile b/Documentation/Makefile index 91a12c7e51..fc6b2cf9ec 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -2,6 +2,9 @@ MAN1_TXT = MAN5_TXT = MAN7_TXT = +TECH_DOCS = +ARTICLES = +SP_ARTICLES = MAN1_TXT += $(filter-out \ $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ @@ -37,12 +40,12 @@ MAN_HTML = $(patsubst %.txt,%.html,$(MAN_TXT)) OBSOLETE_HTML = git-remote-helpers.html DOC_HTML = $(MAN_HTML) $(OBSOLETE_HTML) -ARTICLES = howto-index +ARTICLES += howto-index ARTICLES += everyday ARTICLES += git-tools ARTICLES += git-bisect-lk2009 # with their own formatting rules. -SP_ARTICLES = user-manual +SP_ARTICLES += user-manual SP_ARTICLES += howto/new-command SP_ARTICLES += howto/revert-branch-rebase SP_ARTICLES += howto/using-merge-subtree @@ -60,7 +63,8 @@ SP_ARTICLES += howto/maintain-git API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) SP_ARTICLES += $(API_DOCS) -TECH_DOCS = technical/index-format +TECH_DOCS += technical/http-protocol +TECH_DOCS += technical/index-format TECH_DOCS += technical/pack-format TECH_DOCS += technical/pack-heuristics TECH_DOCS += technical/pack-protocol @@ -324,7 +328,7 @@ manpage-base-url.xsl: manpage-base-url.xsl.in user-manual.xml: user-manual.txt user-manual.conf $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(ASCIIDOC) $(ASCIIDOC_EXTRA) -b docbook -d book -o $@+ $< && \ + $(ASCIIDOC) $(ASCIIDOC_EXTRA) -b docbook -d article -o $@+ $< && \ mv $@+ $@ technical/api-index.txt: technical/api-index-skel.txt \ diff --git a/Documentation/RelNotes/1.9.0.txt b/Documentation/RelNotes/1.9.0.txt new file mode 100644 index 0000000000..752d79127a --- /dev/null +++ b/Documentation/RelNotes/1.9.0.txt @@ -0,0 +1,345 @@ +Git v1.9.0 Release Notes +======================== + +Backward compatibility notes +---------------------------- + +"git submodule foreach $cmd $args" used to treat "$cmd $args" the same +way "ssh" did, concatenating them into a single string and letting the +shell unquote. Careless users who forget to sufficiently quote $args +get their argument split at $IFS whitespaces by the shell, and got +unexpected results due to this. Starting from this release, the +command line is passed directly to the shell, if it has an argument. + +Read-only support for experimental loose-object format, in which users +could optionally choose to write their loose objects for a short +while between v1.4.3 and v1.5.3 era, has been dropped. + +The meanings of the "--tags" option to "git fetch" has changed; the +command fetches tags _in addition to_ what is fetched by the same +command line without the option. + +The way "git push $there $what" interprets the $what part given on the +command line, when it does not have a colon that explicitly tells us +what ref at the $there repository is to be updated, has been enhanced. + +A handful of ancient commands that have long been deprecated are +finally gone (repo-config, tar-tree, lost-found, and peek-remote). + + +Backward compatibility notes (for Git 2.0.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, 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. + +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. + +The default prefix for "git svn" will change in Git 2.0. For a long +time, "git svn" created its remote-tracking branches directly under +refs/remotes, but it will place them under refs/remotes/origin/ unless +it is told otherwise with its --prefix option. + + +Updates since v1.8.5 +-------------------- + +Foreign interfaces, subsystems and ports. + + * The HTTP transport, when talking GSS-Negotiate, uses "100 + Continue" response to avoid having to rewind and resend a large + payload, which may not be always doable. + + * Various bugfixes to remote-bzr and remote-hg (in contrib/). + + * The build procedure is aware of MirBSD now. + + * Various "git p4", "git svn" and "gitk" updates. + + +UI, Workflows & Features + + * Fetching from a shallowly-cloned repository used to be forbidden, + primarily because the codepaths involved were not carefully vetted + and we did not bother supporting such usage. This release attempts + to allow object transfer out of a shallowly-cloned repository in a + more controlled way (i.e. the receiver becomes a shallow repository + with a truncated history). + + * Just like we give a reasonable default for "less" via the LESS + environment variable, we now specify a reasonable default for "lv" + via the "LV" environment variable when spawning the pager. + + * Two-level configuration variable names in "branch.*" and "remote.*" + hierarchies, whose variables are predominantly three-level, were + not completed by hitting a <TAB> in bash and zsh completions. + + * Fetching a 'frotz' branch with "git fetch", while a 'frotz/nitfol' + remote-tracking branch from an earlier fetch was still there, would + error out, primarily because the command was not told that it is + allowed to lose any information on our side. "git fetch --prune" + now can be used to remove 'frotz/nitfol' to make room for fetching and + storing the 'frotz' remote-tracking branch. + + * "diff.orderfile=<file>" configuration variable can be used to + pretend as if the "-O<file>" option were given from the command + line of "git diff", etc. + + * The negative pathspec syntax allows "git log -- . ':!dir'" to tell + us "I am interested in everything but 'dir' directory". + + * "git difftool" shows how many different paths there are in total, + and how many of them have been shown so far, to indicate progress. + + * "git push origin master" used to push our 'master' branch to update + the 'master' branch at the 'origin' repository. This has been + enhanced to use the same ref mapping "git push origin" would use to + determine what ref at the 'origin' to be updated with our 'master'. + For example, with this configuration + + [remote "origin"] + push = refs/heads/*:refs/review/* + + that would cause "git push origin" to push out our local branches + to corresponding refs under refs/review/ hierarchy at 'origin', + "git push origin master" would update 'refs/review/master' over + there. Alternatively, if push.default is set to 'upstream' and our + 'master' is set to integrate with 'topic' from the 'origin' branch, + running "git push origin" while on our 'master' would update their + 'topic' branch, and running "git push origin master" while on any + of our branches does the same. + + * "gitweb" learned to treat ref hierarchies other than refs/heads as + if they are additional branch namespaces (e.g. refs/changes/ in + Gerrit). + + * "git for-each-ref --format=..." learned a few formatting directives; + e.g. "%(color:red)%(HEAD)%(color:reset) %(refname:short) %(subject)". + + * The command string given to "git submodule foreach" is passed + directly to the shell, without being eval'ed. This is a backward + incompatible change that may break existing users. + + * "git log" and friends learned the "--exclude=<glob>" option, to + allow people to say "list history of all branches except those that + match this pattern" with "git log --exclude='*/*' --branches". + + * "git rev-parse --parseopt" learned a new "--stuck-long" option to + help scripts parse options with an optional parameter. + + * The "--tags" option to "git fetch" no longer tells the command to + fetch _only_ the tags. It instead fetches tags _in addition to_ + what are fetched by the same command line without the option. + + +Performance, Internal Implementation, etc. + + * When parsing a 40-hex string into the object name, the string is + checked to see if it can be interpreted as a ref so that a warning + can be given for ambiguity. The code kicked in even when the + core.warnambiguousrefs is set to false to squelch this warning, in + which case the cycles spent to look at the ref namespace were an + expensive no-op, as the result was discarded without being used. + + * The naming convention of the packfiles has been updated; it used to + be based on the enumeration of names of the objects that are + contained in the pack, but now it also depends on how the packed + result is represented---packing the same set of objects using + different settings (or delta order) would produce a pack with + different name. + + * "git diff --no-index" mode used to unnecessarily attempt to read + the index when there is one. + + * The deprecated parse-options macro OPT_BOOLEAN has been removed; + use OPT_BOOL or OPT_COUNTUP in new code. + + * A few duplicate implementations of prefix/suffix string comparison + functions have been unified to starts_with() and ends_with(). + + * The new PERLLIB_EXTRA makefile variable can be used to specify + additional directories Perl modules (e.g. the ones necessary to run + git-svn) are installed on the platform when building. + + * "git merge-base" learned the "--fork-point" mode, that implements + the same logic used in "git pull --rebase" to find a suitable fork + point out of the reflog entries for the remote-tracking branch the + work has been based on. "git rebase" has the same logic that can be + triggered with the "--fork-point" option. + + * A third-party "receive-pack" (the responder to "git push") can + advertise the "no-thin" capability to tell "git push" not to use + the thin-pack optimization. Our receive-pack has always been + capable of accepting and fattening a thin-pack, and will continue + not to ask "git push" to use a non-thin pack. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v1.8.5 +------------------ + +Unless otherwise noted, all the fixes since v1.8.5 in the maintenance +track are contained in this release (see the maintenance releases' notes +for details). + + * The pathspec matching code, while comparing two trees (e.g. "git + diff A B -- path1 path2") was too aggressive and failed to match + some paths when multiple pathspecs were involved. + + * "git repack --max-pack-size=8g" stopped being parsed correctly when + the command was reimplemented in C. + + * An earlier update in v1.8.4.x to "git rev-list --objects" with + negative ref had a performance regression. + (merge 200abe7 jk/mark-edges-uninteresting later to maint). + + * A recent update to "git send-email" broke platforms where + /etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path + (e.g. Fedora rawhide). + + * A handful of bugs around interpreting $branch@{upstream} notation + and its lookalike, when $branch part has interesting characters, + e.g. "@", and ":", have been fixed. + + * "git clone" would fail to clone from a repository that has a ref + directly under "refs/", e.g. "refs/stash", because different + validation paths do different things on such a refname. Loosen the + client side's validation to allow such a ref. + + * "git log --left-right A...B" lost the "leftness" of commits + reachable from A when A is a tag as a side effect of a recent + bugfix. This is a regression in 1.8.4.x series. + + * documentations to "git pull" hinted there is an "-m" option because + it incorrectly shared the documentation with "git merge". + + * "git diff A B submod" and "git diff A B submod/" ought to have done + the same for a submodule "submod", but didn't. + + * "git clone $origin foo\bar\baz" on Windows failed to create the + leading directories (i.e. a moral-equivalent of "mkdir -p"). + + * "submodule.*.update=checkout", when propagated from .gitmodules to + .git/config, turned into a "submodule.*.update=none", which did not + make much sense. + (merge efa8fd7 fp/submodule-checkout-mode later to maint). + + * The implementation of 'git stash $cmd "stash@{...}"' did not quote + the stash argument properly and left it split at IFS whitespace. + + * The "--[no-]informative-errors" options to "git daemon" were parsed + a bit too loosely, allowing any other string after these option + names. + + * There is no reason to have a hardcoded upper limit for the number of + parents of an octopus merge, created via the graft mechanism, but + there was. + + * The basic test used to leave unnecessary trash directories in the + t/ directory. + (merge 738a8be jk/test-framework-updates later to maint). + + * "git merge-base --octopus" used to leave cleaning up suboptimal + result to the caller, but now it does the clean-up itself. + + * A "gc" process running as a different user should be able to stop a + new "gc" process from starting, but it didn't. + + * An earlier "clean-up" introduced an unnecessary memory leak. + + * "git add -A" (no other arguments) in a totally empty working tree + used to emit an error. + + * "git log --decorate" did not handle a tag pointed by another tag + nicely. + + * When we figure out how many file descriptors to allocate for + keeping packfiles open, a system with non-working getrlimit() could + cause us to die(), but because we make this call only to get a + rough estimate of how many are available and we do not even attempt + to use up all available file descriptors ourselves, it is nicer to + fall back to a reasonable low value rather than dying. + + * read_sha1_file(), that is the workhorse to read the contents given + an object name, honoured object replacements, but there was no + corresponding mechanism to sha1_object_info() that was used to + obtain the metainfo (e.g. type & size) about the object. This led + callers to weird inconsistencies. + (merge 663a856 cc/replace-object-info later to maint). + + * "git cat-file --batch=", an admittedly useless command, did not + behave very well. + + * "git rev-parse <revs> -- <paths>" did not implement the usual + disambiguation rules the commands in the "git log" family used in + the same way. + + * "git mv A B/", when B does not exist as a directory, should error + out, but it didn't. + + * A workaround to an old bug in glibc prior to glibc 2.17 has been + retired; this would remove a side effect of the workaround that + corrupts system error messages in non-C locales. + + * SSL-related options were not passed correctly to underlying socket + layer in "git send-email". + + * "git commit -v" appends the patch to the log message before + editing, and then removes the patch when the editor returned + control. However, the patch was not stripped correctly when the + first modified path was a submodule. + + * "git fetch --depth=0" was a no-op, and was silently ignored. + Diagnose it as an error. + + * Remote repository URLs expressed in scp-style host:path notation are + parsed more carefully (e.g. "foo/bar:baz" is local, "[::1]:/~user" asks + to connect to user's home directory on host at address ::1. + + * "git diff -- ':(icase)makefile'" was unnecessarily rejected at the + command line parser. + + * "git cat-file --batch-check=ok" did not check the existence of + the named object. + + * "git am --abort" sometimes complained about not being able to write + a tree with an 0{40} object in it. + + * Two processes creating loose objects at the same time could have + failed unnecessarily when the name of their new objects started + with the same byte value, due to a race condition. diff --git a/Documentation/RelNotes/2.0.0.txt b/Documentation/RelNotes/2.0.0.txt new file mode 100644 index 0000000000..acc7415505 --- /dev/null +++ b/Documentation/RelNotes/2.0.0.txt @@ -0,0 +1,146 @@ +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"). + + +Updates since v1.9 series +------------------------- + +Foreign interfaces, subsystems and ports. + + +UI, Workflows & Features + + * 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"). + + * Many commands that creates 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). + + * Newly cloned submodule repositories by "git submodule update", + when the "checkout" update mode is used, will be on a local + branch instead of on a detached HEAD, just like submodules added + with "git submodule add". + + +Performance, Internal Implementation, etc. + + * 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. + + +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). + + * "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 7c3f67237c..79e576878a 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -142,19 +142,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 @@ -567,6 +561,10 @@ be passed to the shell by Git, which will translate the final command to `LESS=FRSX less -+S`. The environment tells the command to set the `S` option to chop long lines but the command line resets it to the default to fold long lines. ++ +Likewise, when the `LV` environment variable is unset, Git sets it +to `-c`. You can override this setting by exporting `LV` with +another value or setting `core.pager` to `lv +c`. core.whitespace:: A comma separated list of common whitespace problems to @@ -988,6 +986,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 @@ -1163,6 +1169,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 @@ -1597,6 +1607,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].) @@ -1858,6 +1872,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. @@ -1877,6 +1916,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 @@ -1929,7 +1978,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 @@ -1948,8 +1997,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). -- @@ -2026,6 +2075,10 @@ receive.updateserverinfo:: If set to true, git-receive-pack will run git-update-server-info after receiving data from git-push and updating refs. +receive.shallowupdate:: + If set to true, .git/shallow can be updated when new refs + require new shallow roots. Otherwise those refs are rejected. + remote.pushdefault:: The remote to push to by default. Overrides `branch.<name>.remote` for all branches, and is overridden by @@ -2087,8 +2140,8 @@ remote.<name>.vcs:: remote.<name>.prune:: When set to true, fetching from this remote by default will also - remove any remote-tracking branches which no longer exist on the - remote (as if the `--prune` option was give on the command line). + remove any remote-tracking references that no longer exist on the + remote (as if the `--prune` option was given on the command line). Overrides `fetch.prune` settings, if any. remotes.<group>:: @@ -2283,6 +2336,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/diff-config.txt b/Documentation/diff-config.txt index 223b9310df..f07b4513ed 100644 --- a/Documentation/diff-config.txt +++ b/Documentation/diff-config.txt @@ -98,6 +98,11 @@ diff.mnemonicprefix:: diff.noprefix:: If set, 'git diff' does not show any source or destination prefix. +diff.orderfile:: + File indicating how to order files within a diff, using + one shell glob pattern per line. + Can be overridden by the '-O' option to linkgit:git-diff[1]. + diff.renameLimit:: The number of files to consider when performing the copy/rename detection; equivalent to the 'git diff' option '-l'. diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index bbed2cd79c..9b37b2a10b 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -432,6 +432,9 @@ endif::git-format-patch[] -O<orderfile>:: Output the patch in the order specified in the <orderfile>, which has one shell glob pattern per line. + This overrides the `diff.orderfile` configuration variable + (see linkgit:git-config[1]). To cancel `diff.orderfile`, + use `-O/dev/null`. ifndef::git-format-patch[] -R:: diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index ba1fe49582..92c68c3fda 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -14,8 +14,18 @@ branch history. Tags for the deepened commits are not fetched. --unshallow:: - Convert a shallow repository to a complete one, removing all - the limitations imposed by shallow repositories. + If the source repository is complete, convert a shallow + repository to a complete one, removing all the limitations + imposed by shallow repositories. ++ +If the source repository is shallow, fetch as much as possible so that +the current repository has the same history as the source repository. + +--update-shallow:: + By default when fetching from a shallow repository, + `git fetch` refuses refs that require updating + .git/shallow. This option updates .git/shallow and accept such + refs. ifndef::git-pull[] --dry-run:: @@ -41,17 +51,20 @@ ifndef::git-pull[] -p:: --prune:: - After fetching, remove any remote-tracking branches which - no longer exist on the remote. + After fetching, remove any remote-tracking references that no + longer exist on the remote. Tags are not subject to pruning + if they are fetched only because of the default tag + auto-following or due to a --tags option. However, if tags + are fetched due to an explicit refspec (either on the command + line or in the remote configuration, for example if the remote + was cloned with the --mirror option), then they are also + subject to pruning. endif::git-pull[] -ifdef::git-pull[] ---no-tags:: -endif::git-pull[] ifndef::git-pull[] -n:: ---no-tags:: endif::git-pull[] +--no-tags:: By default, tags that point at objects that are downloaded from the remote repository are fetched and stored locally. This option disables this automatic tag following. The default @@ -61,11 +74,12 @@ endif::git-pull[] ifndef::git-pull[] -t:: --tags:: - This is a short-hand for giving `refs/tags/*:refs/tags/*` - refspec from the command line, to ask all tags to be fetched - and stored locally. Because this acts as an explicit - refspec, the default refspecs (configured with the - remote.$name.fetch variable) are overridden and not used. + Fetch all tags from the remote (i.e., fetch remote tags + `refs/tags/*` into local tags with the same name), in addition + to whatever else would otherwise be fetched. Using this + option alone does not subject tags to pruning, even if --prune + is used (though tags may be pruned anyway if they are also the + destination of an explicit refspec; see '--prune'). --recurse-submodules[=yes|on-demand|no]:: This option controls if and under what conditions new commits of diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 48754cbc67..895922e27c 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 54d8461d61..a2b97582fe 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>]] [(<mbox> | <Maildir>)...] 'git am' (--continue | --skip | --abort) @@ -119,6 +119,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 +193,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 b97aaab4ed..cfa1e4ebe4 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 8e70a61840..9f23a861ce 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-cat-file.txt b/Documentation/git-cat-file.txt index 322f5ed315..f6a16f4300 100644 --- a/Documentation/git-cat-file.txt +++ b/Documentation/git-cat-file.txt @@ -109,6 +109,11 @@ newline. The available atoms are: The size, in bytes, that the object takes up on disk. See the note about on-disk sizes in the `CAVEATS` section below. +`deltabase`:: + If the object is stored as a delta on-disk, this expands to the + 40-hex sha1 of the delta base object. Otherwise, expands to the + null sha1 (40 zeroes). See `CAVEATS` below. + `rest`:: If this atom is used in the output string, input lines are split at the first whitespace boundary. All characters before that @@ -152,10 +157,11 @@ should be taken in drawing conclusions about which refs or objects are responsible for disk usage. The size of a packed non-delta object may be much larger than the size of objects which delta against it, but the choice of which object is the base and which is the delta is arbitrary -and is subject to change during a repack. Note also that multiple copies -of an object may be present in the object database; in this case, it is -undefined which copy's size will be reported. +and is subject to change during a repack. +Note also that multiple copies of an object may be present in the object +database; in this case, it is undefined which copy's size or delta base +will be reported. GIT --- diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index 91294f89c8..33ad2adf5c 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -232,8 +232,8 @@ section of linkgit:git-add[1] to learn how to operate the `--patch` mode. commit, your HEAD becomes "detached" and you are no longer on any branch (see below for details). + -As a special case, the `"@{-N}"` syntax for the N-th last branch -checks out the branch (instead of detaching). You may also specify +As a special case, the `"@{-N}"` syntax for the N-th last branch/commit +checks out branches (instead of detaching). You may also specify `-` which is synonymous with `"@{-1}"`. + As a further special case, you may use `"A...B"` as a shortcut for the diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt index c205d2363e..f1e6b2fd6d 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[<keyid>]] <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[<keyid>]:: +--gpg-sign[=<keyid>]:: + 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 450f158779..0363d0039b 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:: @@ -181,12 +178,7 @@ objects from the source repository into a pack in the cloned repository. --depth <depth>:: Create a 'shallow' clone with a history truncated to the - specified number of revisions. A shallow repository has a - number of limitations (you cannot clone or fetch from - it, nor push from nor into it), but is adequate if you - are only interested in the recent history of a large project - with a long history, and would want to send in fixes - as patches. + specified number of revisions. --[no-]single-branch:: Clone only the history leading to the tip of a single branch, @@ -213,7 +205,7 @@ objects from the source repository into a pack in the cloned repository. --separate-git-dir=<git dir>:: Instead of placing the cloned repository where it is supposed to be, place the cloned repository at the specified directory, - then make a filesytem-agnostic Git symbolic link to there. + then make a filesystem-agnostic Git symbolic link to there. The result is Git repository can be separated from working tree. diff --git a/Documentation/git-column.txt b/Documentation/git-column.txt index 5d6f1cc464..03d18465d4 100644 --- a/Documentation/git-column.txt +++ b/Documentation/git-column.txt @@ -43,11 +43,6 @@ OPTIONS --padding=<N>:: The number of spaces between columns. One space by default. - -Author ------- -Written by Nguyen Thai Ngoc Duy <pclouds@gmail.com> - GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt index cafdc9642d..a469eab066 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 1a7616c73a..7c42e9cabc 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -302,6 +302,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 2df9953968..260f39fd40 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-diff.txt b/Documentation/git-diff.txt index 33fbd8c56f..56fb7e5322 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git-diff.txt @@ -44,7 +44,7 @@ two blob objects, or changes between two files on disk. commit relative to the named <commit>. Typically you would want comparison with the latest commit, so if you do not give <commit>, it defaults to HEAD. - If HEAD does not exist (e.g. unborned branches) and + If HEAD does not exist (e.g. unborn branches) and <commit> is not given, it shows all staged changes. --staged is a synonym of --cached. diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt index e08a028946..5809aa4eb9 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -24,19 +24,22 @@ The ref names and their object names of fetched refs are stored in `.git/FETCH_HEAD`. This information is left for a later merge operation done by 'git merge'. -When <refspec> stores the fetched result in remote-tracking branches, -the tags that point at these branches are automatically -followed. This is done by first fetching from the remote using -the given <refspec>s, and if the repository has objects that are -pointed by remote tags that it does not yet have, then fetch -those missing tags. If the other end has tags that point at -branches you are not interested in, you will not get them. +By default, tags are auto-followed. This means that when fetching +from a remote, any tags on the remote that point to objects that exist +in the local repository are fetched. The effect is to fetch tags that +point at branches that you are interested in. This default behavior +can be changed by using the --tags or --no-tags options, by +configuring remote.<name>.tagopt, or by using a refspec that fetches +tags explicitly. 'git fetch' can fetch from either a single named repository, or from several repositories at once if <group> is given and there is a remotes.<group> entry in the configuration file. (See linkgit:git-config[1]). +When no remote is specified, by default the `origin` remote will be used, +unless there's an upstream branch configured for the current branch. + OPTIONS ------- include::fetch-options.txt[] diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index e4c8e82660..09535f2a08 100644 --- a/Documentation/git-filter-branch.txt +++ b/Documentation/git-filter-branch.txt @@ -393,7 +393,7 @@ git filter-branch --index-filter \ Checklist for Shrinking a Repository ------------------------------------ -git-filter-branch is often used to get rid of a subset of files, +git-filter-branch can be used to get rid of a subset of files, usually with some combination of `--index-filter` and `--subdirectory-filter`. People expect the resulting repository to be smaller than the original, but you need a few more steps to @@ -429,6 +429,37 @@ warned. (or if your git-gc is not new enough to support arguments to `--prune`, use `git repack -ad; git prune` instead). +Notes +----- + +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 +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: + +* Any particular version of a file is cleaned exactly _once_. The BFG, + unlike git-filter-branch, does not give you the opportunity to + handle a file differently based on where or when it was committed + within your history. This constraint gives the core performance + benefit of The BFG, and is well-suited to the task of cleansing bad + data - you don't care _where_ the bad data is, you just want it + _gone_. + +* By default The BFG takes full advantage of multi-core machines, + cleansing commit file-trees in parallel. git-filter-branch cleans + commits sequentially (ie in a single-threaded manner), though it + _is_ possible to write filters that include their own parallellism, + in the scripts executed against each commit. + +* 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`. + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index f2e08d11c1..42408752d0 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -91,7 +91,19 @@ objectname:: upstream:: The name of a local ref which can be considered ``upstream'' from the displayed ref. Respects `:short` in the same way as - `refname` above. + `refname` above. Additionally respects `:track` to show + "[ahead N, behind M]" and `:trackshort` to show the terse + version: ">" (ahead), "<" (behind), "<>" (ahead and behind), + or "=" (in sync). Has no effect if the ref does not have + tracking information associated with it. + +HEAD:: + '*' if HEAD matches current ref (the checked out branch), ' ' + otherwise. + +color:: + Change output color. Followed by `:<colorname>`, where names + are described in `color.branch.*`. In addition to the above, for commit and tag objects, the header field names (`tree`, `parent`, `object`, `type`, and `tag`) can @@ -207,13 +219,9 @@ eval=`git for-each-ref --shell --format="$fmt" \ eval "$eval" ------------ -Author ------- -Written by Junio C Hamano <gitster@pobox.com>. - -Documentation -------------- -Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. +SEE ALSO +-------- +linkgit:git-show-ref[1] GIT --- diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt index e3bcdb50e3..e8c13f60ae 100644 --- a/Documentation/git-http-backend.txt +++ b/Documentation/git-http-backend.txt @@ -263,14 +263,6 @@ identifying information of the remote user who performed the push. All CGI environment variables are available to each of the hooks invoked by the 'git-receive-pack'. -Author ------- -Written by Shawn O. Pearce <spearce@spearce.org>. - -Documentation --------------- -Documentation by Shawn O. Pearce <spearce@spearce.org>. - GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-lost-found.txt b/Documentation/git-lost-found.txt deleted file mode 100644 index d54932889f..0000000000 --- a/Documentation/git-lost-found.txt +++ /dev/null @@ -1,74 +0,0 @@ -git-lost-found(1) -================= - -NAME ----- -git-lost-found - Recover lost refs that luckily have not yet been pruned - -SYNOPSIS --------- -[verse] -'git lost-found' - -DESCRIPTION ------------ - -*NOTE*: this command is deprecated. Use linkgit:git-fsck[1] with -the option '--lost-found' instead. - -Finds dangling commits and tags from the object database, and -creates refs to them in the .git/lost-found/ directory. Commits and -tags that dereference to commits are stored in .git/lost-found/commit, -and other objects are stored in .git/lost-found/other. - - -OUTPUT ------- -Prints to standard output the object names and one-line descriptions -of any commits or tags found. - -EXAMPLE -------- - -Suppose you run 'git tag -f' and mistype the tag to overwrite. -The ref to your tag is overwritten, but until you run 'git -prune', the tag itself is still there. - ------------- -$ git lost-found -[1ef2b196d909eed523d4f3c9bf54b78cdd6843c6] GIT 0.99.9c -... ------------- - -Also you can use gitk to browse how any tags found relate to each -other. - ------------- -$ gitk $(cd .git/lost-found/commit && echo ??*) ------------- - -After making sure you know which the object is the tag you are looking -for, you can reconnect it to your regular `refs` hierarchy by using -the `update-ref` command. - ------------- -$ git cat-file -t 1ef2b196 -tag -$ git cat-file tag 1ef2b196 -object fa41bbce8e38c67a218415de6cfa510c7e50032a -type commit -tag v0.99.9c -tagger Junio C Hamano <junkio@cox.net> 1131059594 -0800 - -GIT 0.99.9c - -This contains the following changes from the "master" branch, since -... -$ git update-ref refs/tags/not-lost-anymore 1ef2b196 -$ git rev-parse not-lost-anymore -1ef2b196d909eed523d4f3c9bf54b78cdd6843c6 ------------- - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt index 87842e33f8..808426faac 100644 --- a/Documentation/git-merge-base.txt +++ b/Documentation/git-merge-base.txt @@ -13,6 +13,7 @@ SYNOPSIS 'git merge-base' [-a|--all] --octopus <commit>... 'git merge-base' --is-ancestor <commit> <commit> 'git merge-base' --independent <commit>... +'git merge-base' --fork-point <ref> [<commit>] DESCRIPTION ----------- @@ -24,8 +25,8 @@ that does not have any better common ancestor is a 'best common ancestor', i.e. a 'merge base'. Note that there can be more than one merge base for a pair of commits. -OPERATION MODE --------------- +OPERATION MODES +--------------- As the most common special case, specifying only two commits on the command line means computing the merge base between the given two commits. @@ -56,6 +57,14 @@ from linkgit:git-show-branch[1] when used with the `--merge-base` option. and exit with status 0 if true, or with status 1 if not. Errors are signaled by a non-zero status that is not 1. +--fork-point:: + Find the point at which a branch (or any history that leads + to <commit>) forked from another branch (or any reference) + <ref>. This does not just look for the common ancestor of + the two commits, but also takes into account the reflog of + <ref> to see if the history leading to <commit> forked from + an earlier incarnation of the branch <ref> (see discussion + on this mode below). OPTIONS ------- @@ -137,6 +146,31 @@ In modern git, you can say this in a more direct way: instead. +Discussion on fork-point mode +----------------------------- + +After working on the `topic` branch created with `git checkout -b +topic origin/master`, the history of remote-tracking branch +`origin/master` may have been rewound and rebuilt, leading to a +history of this shape: + + o---B1 + / + ---o---o---B2--o---o---o---B (origin/master) + \ + B3 + \ + Derived (topic) + +where `origin/master` used to point at commits B3, B2, B1 and now it +points at B, and your `topic` branch was started on top of it back +when `origin/master` was at B3. This mode uses the reflog of +`origin/master` to find B3 as the fork point, so that the `topic` +can be rebased on top of the updated `origin/master` by: + + $ fork_point=$(git merge-base --fork-point origin/master topic) + $ git rebase --onto origin/master $fork_point topic + See also -------- diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt index b1f79881ef..e4531325cd 100644 --- a/Documentation/git-mv.txt +++ b/Documentation/git-mv.txt @@ -52,6 +52,18 @@ core.worktree setting to make the submodule work in the new location. It also will attempt to update the submodule.<name>.path setting in the linkgit:gitmodules[5] file and stage that file (unless -n is used). +BUGS +---- +Each time a superproject update moves a populated submodule (e.g. when +switching between commits before and after the move) a stale submodule +checkout will remain in the old location and an empty directory will +appear in the new location. To populate the submodule again in the new +location the user will have to run "git submodule update" +afterwards. Removing the old directory is only safe when it uses a +gitfile, as otherwise the history of the submodule will be deleted +too. Both steps will be obsolete when recursive submodule update has +been implemented. + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt index 46ef0466be..84bb0fecb0 100644 --- a/Documentation/git-notes.txt +++ b/Documentation/git-notes.txt @@ -375,16 +375,6 @@ does not match any refs is silently ignored. If not set in the environment, the list of notes to copy depends on the `notes.rewrite.<command>` and `notes.rewriteRef` settings. - -Author ------- -Written by Johannes Schindelin <johannes.schindelin@gmx.de> and -Johan Herland <johan@herland.net> - -Documentation -------------- -Documentation by Johannes Schindelin and Johan Herland - GIT --- Part of the linkgit:git[7] suite diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt index 8cba16d67f..6ab5f9497a 100644 --- a/Documentation/git-p4.txt +++ b/Documentation/git-p4.txt @@ -168,7 +168,8 @@ All commands except clone accept these options. --git-dir <dir>:: Set the 'GIT_DIR' environment variable. See linkgit:git[1]. ---verbose, -v:: +-v:: +--verbose:: Provide more progress information. Sync options @@ -279,7 +280,8 @@ These options can be used to modify 'git p4 submit' behavior. Export tags from Git as p4 labels. Tags found in Git are applied to the perforce working directory. ---dry-run, -n:: +-n:: +--dry-run:: Show just what commits would be submitted to p4; do not change state in Git or p4. diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt index d94edcd4b4..cdab9ed503 100644 --- a/Documentation/git-pack-objects.txt +++ b/Documentation/git-pack-objects.txt @@ -51,8 +51,7 @@ base-name:: <base-name> to determine the name of the created file. When this option is used, the two files are written in <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 + based on the pack content and is written to the standard output of the command. --stdout:: diff --git a/Documentation/git-peek-remote.txt b/Documentation/git-peek-remote.txt deleted file mode 100644 index 87ea3fb054..0000000000 --- a/Documentation/git-peek-remote.txt +++ /dev/null @@ -1,43 +0,0 @@ -git-peek-remote(1) -================== - -NAME ----- -git-peek-remote - List the references in a remote repository - - -SYNOPSIS --------- -[verse] -'git peek-remote' [--upload-pack=<git-upload-pack>] [<host>:]<directory> - -DESCRIPTION ------------ -This command is deprecated; use 'git ls-remote' instead. - -OPTIONS -------- ---upload-pack=<git-upload-pack>:: - Use this to specify the path to 'git-upload-pack' on the - remote side, if it is not found on your $PATH. Some - installations of sshd ignores the user's environment - setup scripts for login shells (e.g. .bash_profile) and - your privately installed git may not be found on the system - default $PATH. Another workaround suggested is to set - up your $PATH in ".bashrc", but this flag is for people - who do not want to pay the overhead for non-interactive - shells, but prefer having a lean .bashrc file (they set most of - the things up in .bash_profile). - -<host>:: - A remote host that houses the repository. When this - part is specified, 'git-upload-pack' is invoked via - ssh. - -<directory>:: - The repository to sync from. - - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt index bf824108c1..058ac0dc85 100644 --- a/Documentation/git-prune.txt +++ b/Documentation/git-prune.txt @@ -24,6 +24,8 @@ objects unreachable from any of these head objects from the object database. In addition, it prunes the unpacked objects that are also found in packs by running 'git prune-packed'. +It also removes entries from .git/shallow that are not reachable by +any ref. Note that unreachable, packed objects will remain. If this is not desired, see linkgit:git-repack[1]. diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 9eec740910..14862fb203 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -56,8 +56,13 @@ it can be any arbitrary "SHA-1 expression", such as `master~4` or + The <dst> tells which ref on the remote side is updated with this push. Arbitrary expressions cannot be used here, an actual ref must -be named. If `:`<dst> is omitted, the same ref as <src> will be -updated. +be named. +If `git push [<repository>]` without any `<refspec>` argument is set to +update some ref at the destination with `<src>` with +`remote.<repository>.push` configuration variable, `:<dst>` part can +be omitted---such a push will update a ref that `<src>` normally updates +without any `<refspec>` on the command line. Otherwise, missing +`:<dst>` means to update the same ref as the `<src>`. + The object referenced by <src> is used to update the <dst> reference on the remote side. By default this is only allowed if <dst> is not @@ -78,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 @@ -437,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 94e07fdab5..2a93c645bd 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. @@ -324,6 +328,16 @@ fresh commits so it can be remerged successfully without needing to "revert the reversion" (see the link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for details). +--fork-point:: +--no-fork-point:: + Use 'git merge-base --fork-point' to find a better common ancestor + between `upstream` and `branch` when calculating which commits have + have been introduced by `branch` (see linkgit:git-merge-base[1]). ++ +If no non-option arguments are given on the command line, then the default is +`--fork-point @{u}` otherwise the `upstream` argument is interpreted literally +unless the `--fork-point` option is specified. + --ignore-whitespace:: --whitespace=<option>:: These flag are passed to the 'git apply' program diff --git a/Documentation/git-remote-ext.txt b/Documentation/git-remote-ext.txt index 8cfc748ae2..cd0bb77e4a 100644 --- a/Documentation/git-remote-ext.txt +++ b/Documentation/git-remote-ext.txt @@ -116,11 +116,6 @@ begins with `ext::`. Examples: determined by the helper using environment variables (see above). -Documentation --------------- -Documentation by Ilari Liusvaara, Jonathan Nieder and the Git list -<git@vger.kernel.org> - GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-remote-fd.txt b/Documentation/git-remote-fd.txt index 933c2adaf6..bcd37668e3 100644 --- a/Documentation/git-remote-fd.txt +++ b/Documentation/git-remote-fd.txt @@ -50,10 +50,6 @@ EXAMPLES `git push fd::7,8/bar master`:: Same as above. -Documentation --------------- -Documentation by Ilari Liusvaara and the Git list <git@vger.kernel.org> - GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index 2507c8bd91..cb103c8b6f 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 509cf73e50..002cfd5eb9 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,13 @@ 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`. + Configuration ------------- diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index f373ab48d4..0a02f70657 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -10,7 +10,7 @@ SYNOPSIS [verse] 'git replace' [-f] <object> <replacement> 'git replace' -d <object>... -'git replace' -l [<pattern>] +'git replace' [--format=<format>] [-l [<pattern>]] DESCRIPTION ----------- @@ -70,6 +70,23 @@ OPTIONS Typing "git replace" without arguments, also lists all replace refs. +--format=<format>:: + When listing, use the specified <format>, which can be one of + 'short', 'medium' and 'long'. When omitted, the format + defaults to 'short'. + +FORMATS +------- + +The following format are available: + +* 'short': + <replaced sha1> +* 'medium': + <replaced sha1> -> <replacement sha1> +* 'long': + <replaced sha1> (<replaced type>) -> <replacement sha1> (<replacement type>) + CREATING REPLACEMENT OBJECTS ---------------------------- diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt deleted file mode 100644 index 9ec115b9e0..0000000000 --- a/Documentation/git-repo-config.txt +++ /dev/null @@ -1,23 +0,0 @@ -git-repo-config(1) -================== - -NAME ----- -git-repo-config - Get and set repository or global options - - -SYNOPSIS --------- -[verse] -'git repo-config' ... - - -DESCRIPTION ------------ - -This is a synonym for linkgit:git-config[1]. Please refer to the -documentation of that command. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt index f445cb38fa..a077ba0ddc 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 045b37b82e..7a1585def0 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 d068a65377..0d2cdcde55 100644 --- a/Documentation/git-rev-parse.txt +++ b/Documentation/git-rev-parse.txt @@ -50,6 +50,10 @@ Options for --parseopt the first non-option argument. This can be used to parse sub-commands that take options themselves. +--stuck-long:: + Only meaningful in `--parseopt` mode. Output the options in their + long form if available, and with their arguments stuck. + Options for Filtering ~~~~~~~~~~~~~~~~~~~~~ @@ -173,6 +177,20 @@ shown. If the pattern does not contain a globbing character (`?`, character (`?`, `*`, or `[`), it is turned into a prefix match by appending `/*`. +--exclude=<glob-pattern>:: + Do not include refs matching '<glob-pattern>' that the next `--all`, + `--branches`, `--tags`, `--remotes`, or `--glob` would otherwise + consider. Repetitions of this option accumulate exclusion patterns + up to the next `--all`, `--branches`, `--tags`, `--remotes`, or + `--glob` option (other options or arguments do not clear + accumlated patterns). ++ +The patterns given should not begin with `refs/heads`, `refs/tags`, or +`refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`, +respectively, and they must begin with `refs/` when applied to `--glob` +or `--all`. If a trailing '/{asterisk}' is intended, it must be given +explicitly. + --disambiguate=<prefix>:: Show every object whose name begins with the given prefix. The <prefix> must be at least 4 hexadecimal digits long to @@ -285,7 +303,9 @@ Each line of options has this format: `<flags>` are of `*`, `=`, `?` or `!`. * Use `=` if the option takes an argument. - * Use `?` to mean that the option is optional (though its use is discouraged). + * Use `?` to mean that the option takes an optional argument. You + probably want to use the `--stuck-long` mode to be able to + unambiguously parse the optional argument. * Use `*` to mean that this option should not be listed in the usage generated for the `-h` argument. It's shown for `--help-all` as diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt index 2de67a5496..9eb83f01a4 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[<keyid>]] <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[<keyid>]:: +--gpg-sign[=<keyid>]:: + GPG-sign commits. + -s:: --signoff:: Add Signed-off-by line at the end of the commit message. diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt index 9d731b453d..f1efc116eb 100644 --- a/Documentation/git-rm.txt +++ b/Documentation/git-rm.txt @@ -170,6 +170,15 @@ of files and subdirectories under the `Documentation/` directory. (i.e. you are listing the files explicitly), it does not remove `subdir/git-foo.sh`. +BUGS +---- +Each time a superproject update removes a populated submodule +(e.g. when switching between commits before and after the removal) a +stale submodule checkout will remain in the old location. Removing the +old directory is only safe when it uses a gitfile, as otherwise the +history of the submodule will be deleted too. This step will be +obsolete when recursive submodule update has been implemented. + SEE ALSO -------- linkgit:git-add[1] diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt index b0a309b117..ffd1b03a9c 100644 --- a/Documentation/git-show-ref.txt +++ b/Documentation/git-show-ref.txt @@ -175,6 +175,7 @@ FILES SEE ALSO -------- +linkgit:git-for-each-ref[1], linkgit:git-ls-remote[1], linkgit:git-update-ref[1], linkgit:gitrepository-layout[5] diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt index db7e803038..375213fe46 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-submodule.txt b/Documentation/git-submodule.txt index bfef8a0c62..46c1eebb93 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] [--checkout|--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> @@ -155,13 +155,31 @@ 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. - This will make the submodules HEAD be detached unless `--rebase` or - `--merge` is specified or the key `submodule.$name.update` is set to - `rebase`, `merge` or `none`. `none` can be overridden by specifying - `--checkout`. Setting the key `submodule.$name.update` to `!command` - will cause `command` to be run. `command` can be any arbitrary shell - command that takes a single argument, namely the sha1 to update to. + checkout the commit specified in the index of the containing + repository. The update mode defaults to `checkout`, but can be + configured with the `submodule.<name>.update` setting or the + `--rebase`, `--merge`, or `--checkout` options. ++ +For updates that clone missing submodules, checkout-mode updates will +create submodules with detached HEADs; all other modes will create +submodules with a local branch named after `submodule.<path>.branch`. ++ +For updates that do not clone missing submodules, the submodule's HEAD +is only touched when the remote reference does not match the +submodule's HEAD (for none-mode updates, the submodule is never +touched). The remote reference is usually the gitlinked commit from +the superproject's tree, but with `--remote` it is the upstream +subproject's `submodule.<name>.branch`. This remote reference is +integrated with the submodule's HEAD using the specified update mode. +For checkout-mode updates, that will result in a detached HEAD. For +rebase- and merge-mode updates, the commit referenced by the +submodule's HEAD may change, but the symbolic reference will remain +unchanged (i.e. checked-out branches will still be checked-out +branches, and detached HEADs will still be detached HEADs). If none +of the builtin modes fit your needs, set `submodule.<name>.update` to +`!command` to configure a custom integration command. `command` can +be any arbitrary shell command that takes a single argument, namely +the sha1 to update to. + If the submodule is not yet initialized, and you just want to use the setting as stored in .gitmodules, you can automatically initialize the @@ -281,12 +299,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 c418c44d40..404257df9f 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -103,8 +103,9 @@ OPTIONS + This option is only applicable when listing tags without annotation lines. ---contains <commit>:: - Only list tags which contain the specified commit. +--contains [<commit>]:: + Only list tags which contain the specified commit (HEAD if not + specified). --points-at <object>:: Only list tags of the given object. diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt deleted file mode 100644 index f7362dc2d1..0000000000 --- a/Documentation/git-tar-tree.txt +++ /dev/null @@ -1,82 +0,0 @@ -git-tar-tree(1) -=============== - -NAME ----- -git-tar-tree - Create a tar archive of the files in the named tree object - - -SYNOPSIS --------- -[verse] -'git tar-tree' [--remote=<repo>] <tree-ish> [ <base> ] - -DESCRIPTION ------------ -THIS COMMAND IS DEPRECATED. Use 'git archive' with `--format=tar` -option instead (and move the <base> argument to `--prefix=base/`). - -Creates a tar archive containing the tree structure for the named tree. -When <base> is specified it is added as a leading path to the files in the -generated tar archive. - -'git tar-tree' behaves differently when given a tree ID versus when given -a commit ID or tag ID. In the first case the current time is used as -modification time of each file in the archive. In the latter case the -commit time as recorded in the referenced commit object is used instead. -Additionally the commit ID is stored in a global extended pax header. -It can be extracted using 'git get-tar-commit-id'. - -OPTIONS -------- - -<tree-ish>:: - The tree or commit to produce tar archive for. If it is - the object name of a commit object. - -<base>:: - Leading path to the files in the resulting tar archive. - ---remote=<repo>:: - Instead of making a tar archive from local repository, - retrieve a tar archive from a remote repository. - -CONFIGURATION -------------- - -tar.umask:: - This variable can be used to restrict the permission bits of - tar archive entries. The default is 0002, which turns off the - world write bit. The special value "user" indicates that the - archiving user's umask will be used instead. See umask(2) for - details. - -EXAMPLES --------- -`git tar-tree HEAD junk | (cd /var/tmp/ && tar xf -)`:: - - Create a tar archive that contains the contents of the - latest commit on the current branch, and extracts it in - `/var/tmp/junk` directory. - -`git tar-tree v1.4.0 git-1.4.0 | gzip >git-1.4.0.tar.gz`:: - - Create a tarball for v1.4.0 release. - -`git tar-tree v1.4.0^{tree} git-1.4.0 | gzip >git-1.4.0.tar.gz`:: - - Create a tarball for v1.4.0 release, but without a - global extended pax header. - -`git tar-tree --remote=example.com:git.git v1.4.0 >git-1.4.0.tar`:: - - Get a tarball v1.4.0 from example.com. - -`git tar-tree HEAD:Documentation/ git-docs > git-1.4.0-docs.tar`:: - - Put everything in the current head's Documentation/ directory - into 'git-1.4.0-docs.tar', with the prefix 'git-docs/'. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/Documentation/git-upload-archive.txt b/Documentation/git-upload-archive.txt index d09bbb52b1..cbef61ba88 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 64da795aba..27a199ca1a 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -43,6 +43,11 @@ 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] + +* release notes for + link:RelNotes/1.9.0.txt[1.9.0]. + * link:v1.8.5.5/git.html[documentation for release 1.8.5.5] * release notes for @@ -715,6 +720,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 @@ -810,6 +820,15 @@ temporary file --- it is removed when 'GIT_EXTERNAL_DIFF' exits. + For a path that is unmerged, 'GIT_EXTERNAL_DIFF' is called with 1 parameter, <path>. ++ +For each path 'GIT_EXTERNAL_DIFF' is called, two environment variables, +'GIT_DIFF_PATH_COUNTER' and 'GIT_DIFF_PATH_TOTAL' are set. + +'GIT_DIFF_PATH_COUNTER':: + A 1-based counter incremented by one for every path. + +'GIT_DIFF_PATH_TOTAL':: + The total number of paths. other ~~~~~ diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index b322a2666c..643c1ba929 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -930,9 +930,12 @@ state. DEFINING MACRO ATTRIBUTES ------------------------- -Custom macro attributes can be defined only in the `.gitattributes` -file at the toplevel (i.e. not in any subdirectory). The built-in -macro attribute "binary" is equivalent to: +Custom macro attributes can be defined only in top-level gitattributes +files (`$GIT_DIR/info/attributes`, the `.gitattributes` file at the +top level of the working tree, or the global or system-wide +gitattributes files), not in `.gitattributes` files in working tree +subdirectories. The built-in macro attribute "binary" is equivalent +to: ------------ [attr]binary -diff -merge -text diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt index 41bed2983f..1c3e109cb3 100644 --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -28,7 +28,7 @@ arguments. Here are the rules: they can be disambiguated by placing `--` between them. E.g. `git diff -- HEAD` is, "I have a file called HEAD in my work tree. Please show changes between the version I staged in the index - and what I have in the work tree for that file". not "show difference + and what I have in the work tree for that file", not "show difference between the HEAD commit and the work tree as a whole". You can say `git diff HEAD --` to ask for the latter. @@ -72,11 +72,11 @@ scripting Git: * splitting short options to separate words (prefer `git foo -a -b` to `git foo -ab`, the latter may not even work). - * when a command line option takes an argument, use the 'sticked' form. In + * when a command line option takes an argument, use the 'stuck' form. In other words, write `git foo -oArg` instead of `git foo -o Arg` for short options, and `git foo --long-opt=Arg` instead of `git foo --long-opt Arg` for long options. An option that takes optional option-argument must be - written in the 'sticked' form. + written in the 'stuck' form. * when you give a revision parameter to a command, make sure the parameter is not ambiguous with a name of a file in the work tree. E.g. do not write @@ -165,7 +165,7 @@ $ git foo -o Arg ---------------------------- However, this is *NOT* allowed for switches with an optional value, where the -'sticked' form must be used: +'stuck' form must be used: ---------------------------- $ git describe --abbrev HEAD # correct $ git describe --abbrev=10 HEAD # correct diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index 058a352980..d2d7c213dd 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 5ea94cbceb..5f4e89005c 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/githooks.txt b/Documentation/githooks.txt index d48bf4d6fa..d954bf6ba8 100644 --- a/Documentation/githooks.txt +++ b/Documentation/githooks.txt @@ -251,7 +251,7 @@ three parameters: - the name of the ref being updated, - the old object name stored in the ref, - - and the new objectname to be stored in the ref. + - and the new object name to be stored in the ref. A zero exit from the update hook allows the ref to be updated. Exiting with a non-zero status prevents 'git-receive-pack' diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index f971960512..8734c1566c 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -7,7 +7,7 @@ gitignore - Specifies intentionally untracked files to ignore SYNOPSIS -------- -$GIT_DIR/info/exclude, .gitignore +$HOME/.config/git/ignore, $GIT_DIR/info/exclude, .gitignore DESCRIPTION ----------- @@ -77,10 +77,15 @@ 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. If a negated pattern matches, this will - override lower precedence patterns sources. + included again. It is not possible to re-include a file if a parent + directory of that file is excluded. Git doesn't list excluded + directories for performance reasons, so any patterns on contained + files have no effect, no matter where they are defined. Put a backslash ("`\`") in front of the first "`!`" for patterns that begin with a literal "`!`", for example, "`\!important!.txt`". @@ -182,6 +187,19 @@ Another example: The second .gitignore prevents Git from ignoring `arch/foo/kernel/vmlinux.lds.S`. +Example to exclude everything except a specific directory `foo/bar` +(note the `/*` - without the slash, the wildcard would also exclude +everything within `foo/bar`): + +-------------------------------------------------------------- + $ cat .gitignore + # exclude everything except directory foo/bar + /* + !/foo + /foo/* + !/foo/bar +-------------------------------------------------------------- + SEE ALSO -------- linkgit:git-rm[1], diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index d44e14c138..1e9e38ae40 100644 --- a/Documentation/gitk.txt +++ b/Documentation/gitk.txt @@ -98,6 +98,22 @@ linkgit:git-rev-list[1] for a complete list. (See "History simplification" in linkgit:git-log[1] for a more detailed explanation.) +-L<start>,<end>:<file>:: +-L:<regex>:<file>:: + + Trace the evolution of the line range given by "<start>,<end>" + (or the funcname regex <regex>) within the <file>. You may + not give any pathspec limiters. This is currently limited to + a walk starting from a single revision, i.e., you may only + give zero or one positive revision arguments. + You can specify this option more than once. ++ +*Note:* gitk (unlike linkgit:git-log[1]) currently only understands +this option if you specify it "glued together" with its argument. Do +*not* put a space after `-L`. ++ +include::line-range-format.txt[] + <revision range>:: Limit the revisions to show. This can be either a single revision diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt index 347a9f76ee..f539e3f66a 100644 --- a/Documentation/gitmodules.txt +++ b/Documentation/gitmodules.txt @@ -55,6 +55,10 @@ submodule.<name>.branch:: A remote branch name for tracking updates in the upstream submodule. If the option is not specified, it defaults to 'master'. See the `--remote` documentation in linkgit:git-submodule[1] for details. ++ +This branch name is also used for the local branch created by +non-checkout cloning updates. See the `update` documentation in +linkgit:git-submodule[1] for details. submodule.<name>.fetchRecurseSubmodules:: This option can be used to control recursive fetching of this diff --git a/Documentation/gitremote-helpers.txt b/Documentation/gitremote-helpers.txt index f1f4ca9727..c2908db763 100644 --- a/Documentation/gitremote-helpers.txt +++ b/Documentation/gitremote-helpers.txt @@ -437,6 +437,13 @@ 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 cloning \{'true'|'false'\}:: + Notify the helper this is a clone request (i.e. the current + repository is guaranteed empty). + +'option update-shallow \{'true'|'false'\}:: + Allow to extend .git/shallow if the new refs require it. + SEE ALSO -------- linkgit:git-remote[1] diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt index e2113d93c9..952f503afb 100644 --- a/Documentation/gitweb.conf.txt +++ b/Documentation/gitweb.conf.txt @@ -630,13 +630,13 @@ need to set this element to empty list i.e. `[]`. override:: If this field has a true value then the given feature is - overriddable, which means that it can be configured + overridable, which means that it can be configured (or enabled/disabled) on a per-repository basis. + Usually given "<feature>" is configurable via the `gitweb.<feature>` config variable in the per-repository Git configuration file. + -*Note* that no feature is overriddable by default. +*Note* that no feature is overridable by default. sub:: Internal detail of implementation. What is important is that @@ -849,6 +849,43 @@ time zones in the form of "+/-HHMM", such as "+0200". + Project specific override is not supported. +extra-branch-refs:: + List of additional directories under "refs" which are going to + be used as branch refs. For example if you have a gerrit setup + where all branches under refs/heads/ are official, + push-after-review ones and branches under refs/sandbox/, + refs/wip and refs/other are user ones where permissions are + much wider, then you might want to set this variable as + follows: ++ +-------------------------------------------------------------------------------- +$feature{'extra-branch-refs'}{'default'} = + ['sandbox', 'wip', 'other']; +-------------------------------------------------------------------------------- ++ +This feature can be configured on per-repository basis after setting +$feature{'extra-branch-refs'}{'override'} to true, via repository's +`gitweb.extraBranchRefs` configuration variable, which contains a +space separated list of refs. An example: ++ +-------------------------------------------------------------------------------- +[gitweb] + extraBranchRefs = sandbox wip other +-------------------------------------------------------------------------------- ++ +The gitweb.extraBranchRefs is actually a multi-valued configuration +variable, so following example is also correct and the result is the +same as of the snippet above: ++ +-------------------------------------------------------------------------------- +[gitweb] + extraBranchRefs = sandbox + extraBranchRefs = wip other +-------------------------------------------------------------------------------- ++ +It is an error to specify a ref that does not pass "git check-ref-format" +scrutiny. Duplicated values are filtered. + EXAMPLES -------- diff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt index cca14b8cc3..cd9c8951b2 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 aa1c8880dd..378306f581 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -323,24 +323,26 @@ 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 signature" letters (which optionally is terminated by another colon `:`), -and the remainder is the pattern to match against the path. The optional -colon that terminates the "magic signature" can be omitted if the pattern -begins with a character that cannot be a "magic signature" and is not a -colon. +and the remainder is the pattern to match against the path. +The "magic signature" consists of ASCII symbols that are neither +alphanumeric, glob, regex special charaters nor colon. +The optional colon that terminates the "magic signature" can be +omitted if the pattern begins with a character that does not belong to +"magic signature" symbol set and is not a colon. + In the long form, the leading colon `:` is followed by a open parenthesis `(`, a comma-separated list of zero or more "magic words", 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. +A pathspec with only a colon means "there is no pathspec". This form +should not be combined with other pathspec. + -- -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. +top;; + The magic word `top` (magic signature: `/`) makes the pattern + match from the root of the working tree, even when you are + running the command from inside a subdirectory. literal;; Wildcards in the pattern such as `*` or `?` are treated @@ -377,14 +379,12 @@ full pathname may have special meaning: - Other consecutive asterisks are considered invalid. + Glob magic is incompatible with literal magic. + +exclude;; + After a path matches any non-exclude pathspec, it will be run + through all exclude pathspec (magic signature: `!`). If it + matches, the path is ignored. -- -+ -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. -+ -A pathspec with only a colon means "there is no pathspec". This form -should not be combined with other pathspec. [[def_parent]]parent:: A <<def_commit_object,commit object>> contains a (possibly empty) list diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt index 33ae69c11f..ca4378740c 100644 --- a/Documentation/howto/maintain-git.txt +++ b/Documentation/howto/maintain-git.txt @@ -39,26 +39,26 @@ The policy on Integration is informally mentioned in "A Note from the maintainer" message, which is periodically posted to this mailing list after each feature release is made. - - Feature releases are numbered as vX.Y.Z and are meant to + - Feature releases are numbered as vX.Y.0 and are meant to contain bugfixes and enhancements in any area, including functionality, performance and usability, without regression. - One release cycle for a feature release is expected to last for eight to ten weeks. - - Maintenance releases are numbered as vX.Y.Z.W and are meant - to contain only bugfixes for the corresponding vX.Y.Z feature - release and earlier maintenance releases vX.Y.Z.V (V < W). + - Maintenance releases are numbered as vX.Y.Z and are meant + to contain only bugfixes for the corresponding vX.Y.0 feature + release and earlier maintenance releases vX.Y.W (W < Z). - 'master' branch is used to prepare for the next feature release. In other words, at some point, the tip of 'master' - branch is tagged with vX.Y.Z. + branch is tagged with vX.Y.0. - 'maint' branch is used to prepare for the next maintenance - release. After the feature release vX.Y.Z is made, the tip + release. After the feature release vX.Y.0 is made, the tip of 'maint' branch is set to that release, and bugfixes will accumulate on the branch, and at some point, the tip of the - branch is tagged with vX.Y.Z.1, vX.Y.Z.2, and so on. + branch is tagged with vX.Y.1, vX.Y.2, and so on. - 'next' branch is used to publish changes (both enhancements and fixes) that (1) have worthwhile goal, (2) are in a fairly @@ -86,6 +86,10 @@ this mailing list after each feature release is made. users are encouraged to test it so that regressions and bugs are found before new topics are merged to 'master'. +Note that before v1.9.0 release, the version numbers used to be +structured slightly differently. vX.Y.Z were feature releases while +vX.Y.Z.W were maintenance releases for vX.Y.Z. + A Typical Git Day ----------------- diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index 49a9a7d53f..350949810e 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -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 @@ -113,3 +113,11 @@ subtree:: match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree. + +With the strategies that use 3-way merge (including the default, 'recursive'), +if a change is made on both branches, but later reverted on one of the +branches, that change will be present in the merged result; some people find +this behavior confusing. It occurs because only the heads and the merge base +are considered when performing a merge, not the individual commits. The merge +algorithm therefore considers the reverted change as no change at all, and +substitutes the changed version instead. diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 2991d70a4a..9a3da3646e 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -153,6 +153,21 @@ parents) and `--max-parents=-1` (negative numbers denote no upper limit). is automatically prepended if missing. If pattern lacks '?', '{asterisk}', or '[', '/{asterisk}' at the end is implied. +--exclude=<glob-pattern>:: + + Do not include refs matching '<glob-pattern>' that the next `--all`, + `--branches`, `--tags`, `--remotes`, or `--glob` would otherwise + consider. Repetitions of this option accumulate exclusion patterns + up to the next `--all`, `--branches`, `--tags`, `--remotes`, or + `--glob` option (other options or arguments do not clear + accumlated patterns). ++ +The patterns given should not begin with `refs/heads`, `refs/tags`, or +`refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`, +respectively, and they must begin with `refs/` when applied to `--glob` +or `--all`. If a trailing '/{asterisk}' is intended, it must be given +explicitly. + --ignore-missing:: Upon seeing an invalid object name in the input, pretend as if the bad input was not given. @@ -242,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 diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt index 2c06ed34ad..5a286d0d61 100644 --- a/Documentation/revisions.txt +++ b/Documentation/revisions.txt @@ -88,7 +88,7 @@ some output processing may assume ref names in UTF-8. branch 'blabla' then '@\{1\}' means the same as 'blabla@\{1\}'. '@\{-<n>\}', e.g. '@\{-1\}':: - The construct '@\{-<n>\}' means the <n>th branch checked out + The construct '@\{-<n>\}' means the <n>th branch/commit checked out before the current one. '<branchname>@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}':: diff --git a/Documentation/technical/api-builtin.txt b/Documentation/technical/api-builtin.txt index f3c1357b7c..e3d6e7a79a 100644 --- a/Documentation/technical/api-builtin.txt +++ b/Documentation/technical/api-builtin.txt @@ -14,8 +14,8 @@ Git: . Add the external declaration for the function to `builtin.h`. -. Add the command to `commands[]` table in `handle_internal_command()`, - defined in `git.c`. The entry should look like: +. Add the command to the `commands[]` table defined in `git.c`. + The entry should look like: { "foo", cmd_foo, <options> }, + diff --git a/Documentation/technical/api-hash.txt b/Documentation/technical/api-hash.txt deleted file mode 100644 index e5061e0677..0000000000 --- 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 0000000000..42ca2347ed --- /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/api-parse-options.txt b/Documentation/technical/api-parse-options.txt index 0be2b5159f..be50cf4de3 100644 --- a/Documentation/technical/api-parse-options.txt +++ b/Documentation/technical/api-parse-options.txt @@ -29,9 +29,9 @@ that allow to change the behavior of a command. The parse-options API allows: -* 'sticked' and 'separate form' of options with arguments. - `-oArg` is sticked, `-o Arg` is separate form. - `--option=Arg` is sticked, `--option Arg` is separate form. +* 'stuck' and 'separate form' of options with arguments. + `-oArg` is stuck, `-o Arg` is separate form. + `--option=Arg` is stuck, `--option Arg` is separate form. * Long options may be 'abbreviated', as long as the abbreviation is unambiguous. diff --git a/Documentation/technical/api-remote.txt b/Documentation/technical/api-remote.txt index 4be87768f6..5d245aa9d1 100644 --- a/Documentation/technical/api-remote.txt +++ b/Documentation/technical/api-remote.txt @@ -58,16 +58,16 @@ default remote, given the current branch and configuration. struct refspec -------------- -A struct refspec holds the parsed interpretation of a refspec. If it -will force updates (starts with a '+'), force is true. If it is a -pattern (sides end with '*') pattern is true. src and dest are the two -sides (if a pattern, only the part outside of the wildcards); if there -is only one side, it is src, and dst is NULL; if sides exist but are -empty (i.e., the refspec either starts or ends with ':'), the -corresponding side is "". - -This parsing can be done to an array of strings to give an array of -struct refpsecs with parse_ref_spec(). +A struct refspec holds the parsed interpretation of a refspec. If it +will force updates (starts with a '+'), force is true. If it is a +pattern (sides end with '*') pattern is true. src and dest are the +two sides (including '*' characters if present); if there is only one +side, it is src, and dst is NULL; if sides exist but are empty (i.e., +the refspec either starts or ends with ':'), the corresponding side is +"". + +An array of strings can be parsed into an array of struct refspecs +using parse_fetch_refspec() or parse_push_refspec(). remote_find_tracking(), given a remote and a struct refspec with either src or dst filled out, will fill out the other such that the diff --git a/Documentation/technical/bitmap-format.txt b/Documentation/technical/bitmap-format.txt new file mode 100644 index 0000000000..f8c18a0f7a --- /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 d21d77d1de..20525d98bb 100644 --- a/Documentation/technical/http-protocol.txt +++ b/Documentation/technical/http-protocol.txt @@ -20,13 +20,13 @@ URL syntax documented by RFC 1738, so they are of the form: http://<host>:<port>/<path>?<searchpart> -Within this documentation the placeholder $GIT_URL will stand for +Within this documentation the placeholder `$GIT_URL` will stand for the http:// repository URL entered by the end-user. -Servers SHOULD handle all requests to locations matching $GIT_URL, as +Servers SHOULD handle all requests to locations matching `$GIT_URL`, as both the "smart" and "dumb" HTTP protocols used by Git operate by appending additional path components onto the end of the user -supplied $GIT_URL string. +supplied `$GIT_URL` string. An example of a dumb client requesting for a loose object: @@ -43,10 +43,10 @@ An example of a request to a submodule: $GIT_URL: http://example.com/git/repo.git/path/submodule.git URL request: http://example.com/git/repo.git/path/submodule.git/info/refs -Clients MUST strip a trailing '/', if present, from the user supplied -$GIT_URL string to prevent empty path tokens ('//') from appearing +Clients MUST strip a trailing `/`, if present, from the user supplied +`$GIT_URL` string to prevent empty path tokens (`//`) from appearing in any URL sent to a server. Compatible clients MUST expand -'$GIT_URL/info/refs' as 'foo/info/refs' and not 'foo//info/refs'. +`$GIT_URL/info/refs` as `foo/info/refs` and not `foo//info/refs`. Authentication @@ -103,14 +103,14 @@ Except where noted, all standard HTTP behavior SHOULD be assumed by both client and server. This includes (but is not necessarily limited to): -If there is no repository at $GIT_URL, or the resource pointed to by a -location matching $GIT_URL does not exist, the server MUST NOT respond -with '200 OK' response. A server SHOULD respond with -'404 Not Found', '410 Gone', or any other suitable HTTP status code +If there is no repository at `$GIT_URL`, or the resource pointed to by a +location matching `$GIT_URL` does not exist, the server MUST NOT respond +with `200 OK` response. A server SHOULD respond with +`404 Not Found`, `410 Gone`, or any other suitable HTTP status code which does not imply the resource exists as requested. -If there is a repository at $GIT_URL, but access is not currently -permitted, the server MUST respond with the '403 Forbidden' HTTP +If there is a repository at `$GIT_URL`, but access is not currently +permitted, the server MUST respond with the `403 Forbidden` HTTP status code. Servers SHOULD support both HTTP 1.0 and HTTP 1.1. @@ -126,9 +126,9 @@ Servers MAY return ETag and/or Last-Modified headers. Clients MAY revalidate cached entities by including If-Modified-Since and/or If-None-Match request headers. -Servers MAY return '304 Not Modified' if the relevant headers appear +Servers MAY return `304 Not Modified` if the relevant headers appear in the request and the entity has not changed. Clients MUST treat -'304 Not Modified' identical to '200 OK' by reusing the cached entity. +`304 Not Modified` identical to `200 OK` by reusing the cached entity. Clients MAY reuse a cached entity without revalidation if the Cache-Control and/or Expires header permits caching. Clients and @@ -148,7 +148,7 @@ HTTP clients that only support the "dumb" protocol MUST discover references by making a request for the special info/refs file of the repository. -Dumb HTTP clients MUST make a GET request to $GIT_URL/info/refs, +Dumb HTTP clients MUST make a `GET` request to `$GIT_URL/info/refs`, without any search/query parameters. C: GET $GIT_URL/info/refs HTTP/1.0 @@ -161,21 +161,21 @@ without any search/query parameters. S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{} The Content-Type of the returned info/refs entity SHOULD be -"text/plain; charset=utf-8", but MAY be any content type. +`text/plain; charset=utf-8`, but MAY be any content type. Clients MUST NOT attempt to validate the returned Content-Type. Dumb servers MUST NOT return a return type starting with -"application/x-git-". +`application/x-git-`. Cache-Control headers MAY be returned to disable caching of the returned entity. When examining the response clients SHOULD only examine the HTTP -status code. Valid responses are '200 OK', or '304 Not Modified'. +status code. Valid responses are `200 OK`, or `304 Not Modified`. The returned content is a UNIX formatted text file describing each ref and its known value. The file SHOULD be sorted by name according to the C locale ordering. The file SHOULD NOT include -the default ref named 'HEAD'. +the default ref named `HEAD`. info_refs = *( ref_record ) ref_record = any_ref / peeled_ref @@ -192,13 +192,14 @@ HTTP clients that support the "smart" protocol (or both the a parameterized request for the info/refs file of the repository. The request MUST contain exactly one query parameter, -'service=$servicename', where $servicename MUST be the service +`service=$servicename`, where `$servicename` MUST be the service name the client wishes to contact to complete the operation. The request MUST NOT contain additional query parameters. C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0 - dumb server reply: +dumb server reply: + S: 200 OK S: S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint @@ -206,7 +207,8 @@ The request MUST NOT contain additional query parameters. S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0 S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{} - smart server reply: +smart server reply: + S: 200 OK S: Content-Type: application/x-git-upload-pack-advertisement S: Cache-Control: no-cache @@ -228,7 +230,7 @@ Smart Server Response ^^^^^^^^^^^^^^^^^^^^^ If the server does not recognize the requested service name, or the requested service name has been disabled by the server administrator, -the server MUST respond with the '403 Forbidden' HTTP status code. +the server MUST respond with the `403 Forbidden` HTTP status code. Otherwise, smart servers MUST respond with the smart server reply format for the requested service name. @@ -236,35 +238,35 @@ format for the requested service name. Cache-Control headers SHOULD be used to disable caching of the returned entity. -The Content-Type MUST be 'application/x-$servicename-advertisement'. +The Content-Type MUST be `application/x-$servicename-advertisement`. Clients SHOULD fall back to the dumb protocol if another content type is returned. When falling back to the dumb protocol clients -SHOULD NOT make an additional request to $GIT_URL/info/refs, but +SHOULD NOT make an additional request to `$GIT_URL/info/refs`, but instead SHOULD use the response already in hand. Clients MUST NOT continue if they do not support the dumb protocol. -Clients MUST validate the status code is either '200 OK' or -'304 Not Modified'. +Clients MUST validate the status code is either `200 OK` or +`304 Not Modified`. Clients MUST validate the first five bytes of the response entity -matches the regex "^[0-9a-f]{4}#". If this test fails, clients +matches the regex `^[0-9a-f]{4}#`. If this test fails, clients MUST NOT continue. Clients MUST parse the entire response as a sequence of pkt-line records. -Clients MUST verify the first pkt-line is "# service=$servicename". +Clients MUST verify the first pkt-line is `# service=$servicename`. Servers MUST set $servicename to be the request parameter value. Servers SHOULD include an LF at the end of this line. Clients MUST ignore an LF at the end of the line. -Servers MUST terminate the response with the magic "0000" end +Servers MUST terminate the response with the magic `0000` end pkt-line marker. The returned response is a pkt-line stream describing each ref and its known value. The stream SHOULD be sorted by name according to the C locale ordering. The stream SHOULD include the default ref -named 'HEAD' as the first ref. The stream MUST include capability +named `HEAD` as the first ref. The stream MUST include capability declarations behind a NUL on the first ref. smart_reply = PKT-LINE("# service=$servicename" LF) @@ -286,12 +288,13 @@ declarations behind a NUL on the first ref. peeled_ref = PKT-LINE(obj-id SP name LF) PKT-LINE(obj-id SP name "^{}" LF + Smart Service git-upload-pack ------------------------------ -This service reads from the repository pointed to by $GIT_URL. +This service reads from the repository pointed to by `$GIT_URL`. Clients MUST first perform ref discovery with -'$GIT_URL/info/refs?service=git-upload-pack'. +`$GIT_URL/info/refs?service=git-upload-pack`. C: POST $GIT_URL/git-upload-pack HTTP/1.0 C: Content-Type: application/x-git-upload-pack-request @@ -313,10 +316,10 @@ to prevent caching of the response. Servers SHOULD support all capabilities defined here. -Clients MUST send at least one 'want' command in the request body. -Clients MUST NOT reference an id in a 'want' command which did not +Clients MUST send at least one "want" command in the request body. +Clients MUST NOT reference an id in a "want" command which did not appear in the response obtained through ref discovery unless the -server advertises capability "allow-tip-sha1-in-want". +server advertises capability `allow-tip-sha1-in-want`. compute_request = want_list have_list @@ -332,128 +335,128 @@ server advertises capability "allow-tip-sha1-in-want". have_list = *PKT-LINE("have" SP id LF) TODO: Document this further. -TODO: Don't use uppercase for variable names below. The Negotiation Algorithm ~~~~~~~~~~~~~~~~~~~~~~~~~ The computation to select the minimal pack proceeds as follows -(c = client, s = server): +(C = client, S = server): + +'init step:' + +C: Use ref discovery to obtain the advertised refs. + +C: Place any object seen into set `advertised`. - init step: - (c) Use ref discovery to obtain the advertised refs. - (c) Place any object seen into set ADVERTISED. +C: Build an empty set, `common`, to hold the objects that are later + determined to be on both ends. - (c) Build an empty set, COMMON, to hold the objects that are later - determined to be on both ends. - (c) Build a set, WANT, of the objects from ADVERTISED the client - wants to fetch, based on what it saw during ref discovery. +C: Build a set, `want`, of the objects from `advertised` the client + wants to fetch, based on what it saw during ref discovery. - (c) Start a queue, C_PENDING, ordered by commit time (popping newest - first). Add all client refs. When a commit is popped from - the queue its parents SHOULD be automatically inserted back. - Commits MUST only enter the queue once. +C: Start a queue, `c_pending`, ordered by commit time (popping newest + first). Add all client refs. When a commit is popped from + the queue its parents SHOULD be automatically inserted back. + Commits MUST only enter the queue once. - one compute step: - (c) Send one $GIT_URL/git-upload-pack request: +'one compute step:' - C: 0032want <WANT #1>............................... - C: 0032want <WANT #2>............................... +C: Send one `$GIT_URL/git-upload-pack` request: + + C: 0032want <want #1>............................... + C: 0032want <want #2>............................... .... - C: 0032have <COMMON #1>............................. - C: 0032have <COMMON #2>............................. + C: 0032have <common #1>............................. + C: 0032have <common #2>............................. .... - C: 0032have <HAVE #1>............................... - C: 0032have <HAVE #2>............................... + C: 0032have <have #1>............................... + C: 0032have <have #2>............................... .... C: 0000 - The stream is organized into "commands", with each command - appearing by itself in a pkt-line. Within a command line - the text leading up to the first space is the command name, - and the remainder of the line to the first LF is the value. - Command lines are terminated with an LF as the last byte of - the pkt-line value. +The stream is organized into "commands", with each command +appearing by itself in a pkt-line. Within a command line +the text leading up to the first space is the command name, +and the remainder of the line to the first LF is the value. +Command lines are terminated with an LF as the last byte of +the pkt-line value. - Commands MUST appear in the following order, if they appear - at all in the request stream: +Commands MUST appear in the following order, if they appear +at all in the request stream: - * want - * have +* "want" +* "have" - The stream is terminated by a pkt-line flush ("0000"). +The stream is terminated by a pkt-line flush (`0000`). - A single "want" or "have" command MUST have one hex formatted - SHA-1 as its value. Multiple SHA-1s MUST be sent by sending - multiple commands. +A single "want" or "have" command MUST have one hex formatted +SHA-1 as its value. Multiple SHA-1s MUST be sent by sending +multiple commands. - The HAVE list is created by popping the first 32 commits - from C_PENDING. Less can be supplied if C_PENDING empties. +The `have` list is created by popping the first 32 commits +from `c_pending`. Less can be supplied if `c_pending` empties. - If the client has sent 256 HAVE commits and has not yet - received one of those back from S_COMMON, or the client has - emptied C_PENDING it SHOULD include a "done" command to let - the server know it won't proceed: +If the client has sent 256 "have" commits and has not yet +received one of those back from `s_common`, or the client has +emptied `c_pending` it SHOULD include a "done" command to let +the server know it won't proceed: C: 0009done - (s) Parse the git-upload-pack request: - - Verify all objects in WANT are directly reachable from refs. - - The server MAY walk backwards through history or through - the reflog to permit slightly stale requests. +S: Parse the git-upload-pack request: - If no WANT objects are received, send an error: +Verify all objects in `want` are directly reachable from refs. -TODO: Define error if no want lines are requested. +The server MAY walk backwards through history or through +the reflog to permit slightly stale requests. - If any WANT object is not reachable, send an error: +If no "want" objects are received, send an error: +TODO: Define error if no "want" lines are requested. -TODO: Define error if an invalid want is requested. +If any "want" object is not reachable, send an error: +TODO: Define error if an invalid "want" is requested. - Create an empty list, S_COMMON. +Create an empty list, `s_common`. - If 'have' was sent: +If "have" was sent: - Loop through the objects in the order supplied by the client. - For each object, if the server has the object reachable from - a ref, add it to S_COMMON. If a commit is added to S_COMMON, - do not add any ancestors, even if they also appear in HAVE. +Loop through the objects in the order supplied by the client. - (s) Send the git-upload-pack response: +For each object, if the server has the object reachable from +a ref, add it to `s_common`. If a commit is added to `s_common`, +do not add any ancestors, even if they also appear in `have`. - If the server has found a closed set of objects to pack or the - request ends with "done", it replies with the pack. +S: Send the git-upload-pack response: +If the server has found a closed set of objects to pack or the +request ends with "done", it replies with the pack. TODO: Document the pack based response - S: PACK... - The returned stream is the side-band-64k protocol supported - by the git-upload-pack service, and the pack is embedded into - stream 1. Progress messages from the server side MAY appear - in stream 2. + S: PACK... - Here a "closed set of objects" is defined to have at least - one path from every WANT to at least one COMMON object. +The returned stream is the side-band-64k protocol supported +by the git-upload-pack service, and the pack is embedded into +stream 1. Progress messages from the server side MAY appear +in stream 2. - If the server needs more information, it replies with a - status continue response: +Here a "closed set of objects" is defined to have at least +one path from every "want" to at least one "common" object. +If the server needs more information, it replies with a +status continue response: TODO: Document the non-pack response - (c) Parse the upload-pack response: - -TODO: Document parsing response +C: Parse the upload-pack response: + TODO: Document parsing response - Do another compute step. +'Do another compute step.' Smart Service git-receive-pack ------------------------------ -This service reads from the repository pointed to by $GIT_URL. +This service reads from the repository pointed to by `$GIT_URL`. Clients MUST first perform ref discovery with -'$GIT_URL/info/refs?service=git-receive-pack'. +`$GIT_URL/info/refs?service=git-receive-pack`. C: POST $GIT_URL/git-receive-pack HTTP/1.0 C: Content-Type: application/x-git-receive-pack-request @@ -497,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 b898e97988..39c64105a6 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -161,6 +161,7 @@ MUST peel the ref if it's an annotated tag. ---- advertised-refs = (no-refs / list-of-refs) + *shallow flush-pkt no-refs = PKT-LINE(zero-id SP "capabilities^{}" @@ -174,6 +175,8 @@ MUST peel the ref if it's an annotated tag. other-tip = obj-id SP refname LF other-peeled = obj-id SP refname "^{}" LF + shallow = PKT-LINE("shallow" SP obj-id) + capability-list = capability *(SP capability) capability = 1*(LC_ALPHA / DIGIT / "-" / "_") LC_ALPHA = %x61-7A @@ -335,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. @@ -461,7 +465,9 @@ contain all the objects that the server will need to complete the new references. ---- - update-request = command-list [pack-file] + update-request = *shallow command-list [pack-file] + + shallow = PKT-LINE("shallow" SP obj-id) command-list = PKT-LINE(command NUL capability-list LF) *PKT-LINE(command LF) diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index fd8ffa5df3..e174343847 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -69,17 +69,50 @@ 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 --------- -This capability means that the server can send a 'thin' pack, a pack -which does not contain base objects; if those base objects are available -on client side. Client requests 'thin-pack' capability when it -understands how to "thicken" it by adding required delta bases making -it self-contained. - -Client MUST NOT request 'thin-pack' capability if it cannot turn a thin -pack into a self-contained pack. +A thin pack is one with deltas which reference base objects not +contained within the pack (but are known to exist at the receiving +end). This can reduce the network traffic significantly, but it +requires the receiving end to know how to "thicken" these packs by +adding the missing bases to the pack. + +The upload-pack server advertises 'thin-pack' when it can generate +and send a thin pack. A client requests the 'thin-pack' capability +when it understands how to "thicken" it, notifying the server that +it can receive such a pack. A client MUST NOT request the +'thin-pack' capability if it cannot turn a thin pack into a +self-contained pack. + +Receive-pack, on the other hand, is assumed by default to be able to +handle thin packs, but can ask the client not to use the feature by +advertising the 'no-thin' capability. A client MUST NOT send a thin +pack if the server advertises the 'no-thin' capability. + +The reasons for this asymmetry are historical. The receive-pack +program did not exist until after the invention of thin packs, so +historically the reference implementation of receive-pack always +understood thin packs. Adding 'no-thin' later allowed receive-pack +to disable the feature in a backwards-compatible manner. side-band, side-band-64k diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index cbb01a1ea2..d4f9804462 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -1,5 +1,5 @@ Git User Manual -_______________ +=============== Git is a fast distributed revision control system. @@ -3795,7 +3795,7 @@ like so: $ git update-index filename ------------------------------------------------- -but to avoid common mistakes with filename globbing etc, the command +but to avoid common mistakes with filename globbing etc., the command will not normally add totally new entries or remove old entries, i.e. it will normally just update existing cache entries. |