diff options
Diffstat (limited to 'Documentation')
120 files changed, 3498 insertions, 484 deletions
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index c4cb5ff0d4..48aa4edfbd 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -386,6 +386,11 @@ For C programs: - Use Git's gettext wrappers to make the user interface translatable. See "Marking strings for translation" in po/README. + - Variables and functions local to a given source file should be marked + with "static". Variables that are visible to other source files + must be declared with "extern" in header files. However, function + declarations should not use "extern", as that is already the default. + For Perl programs: - Most of the C guidelines above apply. diff --git a/Documentation/Makefile b/Documentation/Makefile index 4ae9ba5c86..d079d7c73a 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -72,11 +72,13 @@ TECH_DOCS += SubmittingPatches TECH_DOCS += technical/hash-function-transition TECH_DOCS += technical/http-protocol TECH_DOCS += technical/index-format +TECH_DOCS += technical/long-running-process-protocol TECH_DOCS += technical/pack-format TECH_DOCS += technical/pack-heuristics TECH_DOCS += technical/pack-protocol TECH_DOCS += technical/protocol-capabilities TECH_DOCS += technical/protocol-common +TECH_DOCS += technical/protocol-v2 TECH_DOCS += technical/racy-git TECH_DOCS += technical/send-pack-pipeline TECH_DOCS += technical/shallow @@ -183,7 +185,7 @@ ASCIIDOC = asciidoctor ASCIIDOC_CONF = ASCIIDOC_HTML = xhtml5 ASCIIDOC_DOCBOOK = docbook45 -ASCIIDOC_EXTRA += -acompat-mode +ASCIIDOC_EXTRA += -acompat-mode -atabsize=8 ASCIIDOC_EXTRA += -I. -rasciidoctor-extensions ASCIIDOC_EXTRA += -alitdd='&\#x2d;&\#x2d;' DBLATEX_COMMON = diff --git a/Documentation/RelNotes/1.7.11.7.txt b/Documentation/RelNotes/1.7.11.7.txt index e7e79d999b..e743a2a8e4 100644 --- a/Documentation/RelNotes/1.7.11.7.txt +++ b/Documentation/RelNotes/1.7.11.7.txt @@ -25,7 +25,7 @@ Fixes since v1.7.11.6 references" nor "Reload" did not update what is shown as the contents of it, when the user overwrote the tag with "git tag -f". - * "git for-each-ref" did not currectly support more than one --sort + * "git for-each-ref" did not correctly support more than one --sort option. * "git log .." errored out saying it is both rev range and a path diff --git a/Documentation/RelNotes/2.17.0.txt b/Documentation/RelNotes/2.17.0.txt new file mode 100644 index 0000000000..c2cf891f71 --- /dev/null +++ b/Documentation/RelNotes/2.17.0.txt @@ -0,0 +1,398 @@ +Git 2.17 Release Notes +====================== + +Updates since v2.16 +------------------- + +UI, Workflows & Features + + * "diff" family of commands learned "--find-object=<object-id>" option + to limit the findings to changes that involve the named object. + + * "git format-patch" learned to give 72-cols to diffstat, which is + consistent with other line length limits the subcommand uses for + its output meant for e-mails. + + * The log from "git daemon" can be redirected with a new option; one + relevant use case is to send the log to standard error (instead of + syslog) when running it from inetd. + + * "git rebase" learned to take "--allow-empty-message" option. + + * "git am" has learned the "--quit" option, in addition to the + existing "--abort" option; having the pair mirrors a few other + commands like "rebase" and "cherry-pick". + + * "git worktree add" learned to run the post-checkout hook, just like + "git clone" runs it upon the initial checkout. + + * "git tag" learned an explicit "--edit" option that allows the + message given via "-m" and "-F" to be further edited. + + * "git fetch --prune-tags" may be used as a handy short-hand for + getting rid of stale tags that are locally held. + + * The new "--show-current-patch" option gives an end-user facing way + to get the diff being applied when "git rebase" (and "git am") + stops with a conflict. + + * "git add -p" used to offer "/" (look for a matching hunk) as a + choice, even there was only one hunk, which has been corrected. + Also the single-key help is now given only for keys that are + enabled (e.g. help for '/' won't be shown when there is only one + hunk). + + * Since Git 1.7.9, "git merge" defaulted to --no-ff (i.e. even when + the side branch being merged is a descendant of the current commit, + create a merge commit instead of fast-forwarding) when merging a + tag object. This was appropriate default for integrators who pull + signed tags from their downstream contributors, but caused an + unnecessary merges when used by downstream contributors who + habitually "catch up" their topic branches with tagged releases + from the upstream. Update "git merge" to default to --no-ff only + when merging a tag object that does *not* sit at its usual place in + refs/tags/ hierarchy, and allow fast-forwarding otherwise, to + mitigate the problem. + + * "git status" can spend a lot of cycles to compute the relation + between the current branch and its upstream, which can now be + disabled with "--no-ahead-behind" option. + + * "git diff" and friends learned funcname patterns for Go language + source files. + + * "git send-email" learned "--reply-to=<address>" option. + + * Funcname pattern used for C# now recognizes "async" keyword. + + * In a way similar to how "git tag" learned to honor the pager + setting only in the list mode, "git config" learned to ignore the + pager setting when it is used for setting values (i.e. when the + purpose of the operation is not to "show"). + + +Performance, Internal Implementation, Development Support etc. + + * More perf tests for threaded grep + + * "perf" test output can be sent to codespeed server. + + * The build procedure for perl/ part has been greatly simplified by + weaning ourselves off of MakeMaker. + + * Perl 5.8 or greater has been required since Git 1.7.4 released in + 2010, but we continued to assume some core modules may not exist and + used a conditional "eval { require <<module>> }"; we no longer do + this. Some platforms (Fedora/RedHat/CentOS, for example) ship Perl + without all core modules by default (e.g. Digest::MD5, File::Temp, + File::Spec, Net::Domain, Net::SMTP). Users on such platforms may + need to install these additional modules. + + * As a convenience, we install copies of Perl modules we require which + are not part of the core Perl distribution (e.g. Error and + Mail::Address). Users and packagers whose operating system provides + these modules can set NO_PERL_CPAN_FALLBACKS to avoid installing the + bundled modules. + + * In preparation for implementing narrow/partial clone, the machinery + for checking object connectivity used by gc and fsck has been + taught that a missing object is OK when it is referenced by a + packfile specially marked as coming from trusted repository that + promises to make them available on-demand and lazily. + + * The machinery to clone & fetch, which in turn involves packing and + unpacking objects, has been told how to omit certain objects using + the filtering mechanism introduced by another topic. It now knows + to mark the resulting pack as a promisor pack to tolerate missing + objects, laying foundation for "narrow" clones. + + * The first step to getting rid of mru API and using the + doubly-linked list API directly instead. + + * Retire mru API as it does not give enough abstraction over + underlying list API to be worth it. + + * Rewrite two more "git submodule" subcommands in C. + + * The tracing machinery learned to report tweaking of environment + variables as well. + + * Update Coccinelle rules to catch and optimize strbuf_addf(&buf, "%s", str) + + * Prevent "clang-format" from breaking line after function return type. + + * The sequencer infrastructure is shared across "git cherry-pick", + "git rebase -i", etc., and has always spawned "git commit" when it + needs to create a commit. It has been taught to do so internally, + when able, by reusing the codepath "git commit" itself uses, which + gives performance boost for a few tens of percents in some sample + scenarios. + + * Push the submodule version of collision-detecting SHA-1 hash + implementation a bit harder on builders. + + * Avoid mmapping small files while using packed refs (especially ones + with zero size, which would cause later munmap() to fail). + + * Conversion from uchar[20] to struct object_id continues. + + * More tests for wildmatch functions. + + * The code to binary search starting from a fan-out table (which is + how the packfile is indexed with object names) has been refactored + into a reusable helper. + + * We now avoid using identifiers that clash with C++ keywords. Even + though it is not a goal to compile Git with C++ compilers, changes + like this help use of code analysis tools that targets C++ on our + codebase. + + * The executable is now built in 'script' phase in Travis CI integration, + to follow the established practice, rather than during 'before_script' + phase. This allows the CI categorize the failures better ('failed' + is project's fault, 'errored' is build environment's). + (merge 3c93b82920 sg/travis-build-during-script-phase later to maint). + + * Writing out the index file when the only thing that changed in it + is the untracked cache information is often wasteful, and this has + been optimized out. + + * Various pieces of Perl code we have have been cleaned up. + + * Internal API clean-up to allow write_locked_index() optionally skip + writing the in-core index when it is not modified. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v2.16 +----------------- + + * An old regression in "git describe --all $annotated_tag^0" has been + fixed. + + * "git status" after moving a path in the working tree (hence making + it appear "removed") and then adding with the -N option (hence + making that appear "added") detected it as a rename, but did not + report the old and new pathnames correctly. + + * "git svn dcommit" did not take into account the fact that a + svn+ssh:// URL with a username@ (typically used for pushing) refers + to the same SVN repository without the username@ and failed when + svn.pushmergeinfo option is set. + + * API clean-up around revision traversal. + + * "git merge -Xours/-Xtheirs" learned to use our/their version when + resolving a conflicting updates to a symbolic link. + + * "git clone $there $here" is allowed even when here directory exists + as long as it is an empty directory, but the command incorrectly + removed it upon a failure of the operation. + + * "git commit --fixup" did not allow "-m<message>" option to be used + at the same time; allow it to annotate resulting commit with more + text. + + * When resetting the working tree files recursively, the working tree + of submodules are now also reset to match. + + * "git stash -- <pathspec>" incorrectly blew away untracked files in + the directory that matched the pathspec, which has been corrected. + + * Instead of maintaining home-grown email address parsing code, ship + a copy of reasonably recent Mail::Address to be used as a fallback + in 'git send-email' when the platform lacks it. + (merge d60be8acab mm/send-email-fallback-to-local-mail-address later to maint). + + * "git add -p" was taught to ignore local changes to submodules as + they do not interfere with the partial addition of regular changes + anyway. + + * Avoid showing a warning message in the middle of a line of "git + diff" output. + (merge 4e056c989f nd/diff-flush-before-warning later to maint). + + * The http tracing code, often used to debug connection issues, + learned to redact potentially sensitive information from its output + so that it can be more safely sharable. + (merge 8ba18e6fa4 jt/http-redact-cookies later to maint). + + * Crash fix for a corner case where an error codepath tried to unlock + what it did not acquire lock on. + (merge 81fcb698e0 mr/packed-ref-store-fix later to maint). + + * The split-index mode had a few corner case bugs fixed. + (merge ae59a4e44f tg/split-index-fixes later to maint). + + * Assorted fixes to "git daemon". + (merge ed15e58efe jk/daemon-fixes later to maint). + + * Completion of "git merge -s<strategy>" (in contrib/) did not work + well in non-C locale. + (merge 7cc763aaa3 nd/list-merge-strategy later to maint). + + * Workaround for segfault with more recent versions of SVN. + (merge 7f6f75e97a ew/svn-branch-segfault-fix later to maint). + + * Plug recently introduced leaks in fsck. + (merge ba3a08ca0e jt/fsck-code-cleanup later to maint). + + * "git pull --rebase" did not pass verbosity setting down when + recursing into a submodule. + (merge a56771a668 sb/pull-rebase-submodule later to maint). + + * The way "git reset --hard" reports the commit the updated HEAD + points at is made consistent with the way how the commit title is + generated by the other parts of the system. This matters when the + title is spread across physically multiple lines. + (merge 1cf823fb68 tg/reset-hard-show-head-with-pretty later to maint). + + * Test fixes. + (merge 63b1a175ee sg/test-i18ngrep later to maint). + + * Some bugs around "untracked cache" feature have been fixed. This + will notice corrupt data in the untracked cache left by old and + buggy code and issue a warning---the index can be fixed by clearing + the untracked cache from it. + (merge 0cacebf099 nd/fix-untracked-cache-invalidation later to maint). + (merge 7bf0be7501 ab/untracked-cache-invalidation-docs later to maint). + + * "git blame HEAD COPYING" in a bare repository failed to run, while + "git blame HEAD -- COPYING" run just fine. This has been corrected. + + * "git add" files in the same directory, but spelling the directory + path in different cases on case insensitive filesystem, corrupted + the name hash data structure and led to unexpected results. This + has been corrected. + (merge c95525e90d bp/name-hash-dirname-fix later to maint). + + * "git rebase -p" mangled log messages of a merge commit, which is + now fixed. + (merge ed5144d7eb js/fix-merge-arg-quoting-in-rebase-p later to maint). + + * Some low level protocol codepath could crash when they get an + unexpected flush packet, which is now fixed. + (merge bb1356dc64 js/packet-read-line-check-null later to maint). + + * "git check-ignore" with multiple paths got confused when one is a + file and the other is a directory, which has been fixed. + (merge d60771e930 rs/check-ignore-multi later to maint). + + * "git describe $garbage" stopped giving any errors when the garbage + happens to be a string with 40 hexadecimal letters. + (merge a8e7a2bf0f sb/describe-blob later to maint). + + * Code to unquote single-quoted string (used in the parser for + configuration files, etc.) did not diagnose bogus input correctly + and produced bogus results instead. + (merge ddbbf8eb25 jk/sq-dequote-on-bogus-input later to maint). + + * Many places in "git apply" knew that "/dev/null" that signals + "there is no such file on this side of the diff" can be followed by + whitespace and garbage when parsing a patch, except for one, which + made an otherwise valid patch (e.g. ones from subversion) rejected. + (merge e454ad4bec tk/apply-dev-null-verify-name-fix later to maint). + + * We no longer create any *.spec file, so "make clean" should not + remove it. + (merge 4321bdcabb tz/do-not-clean-spec-file later to maint). + + * "git push" over http transport did not unquote the push-options + correctly. + (merge 90dce21eb0 jk/push-options-via-transport-fix later to maint). + + * "git send-email" learned to complain when the batch-size option is + not defined when the relogin-delay option is, since these two are + mutually required. + (merge 9caa70697b xz/send-email-batch-size later to maint). + + * Y2k20 fix ;-) for our perl scripts. + (merge a40e06ee33 bw/perl-timegm-timelocal-fix later to maint). + + * Threaded "git grep" has been optimized to avoid allocation in code + section that is covered under a mutex. + (merge 38ef24dccf rv/grep-cleanup later to maint). + + * "git subtree" script (in contrib/) scripted around "git log", whose + output got affected by end-user configuration like log.showsignature + (merge 8841b5222c sg/subtree-signed-commits later to maint). + + * While finding unique object name abbreviation, the code may + accidentally have read beyond the end of the array of object names + in a pack. + (merge 21abed500c ds/find-unique-abbrev-optim later to maint). + + * Micro optimization in revision traversal code. + (merge ebbed3ba04 ds/mark-parents-uninteresting-optim later to maint). + + * "git commit" used to run "gc --auto" near the end, which was lost + when the command was reimplemented in C by mistake. + (merge 095c741edd ab/gc-auto-in-commit later to maint). + + * Allow running a couple of tests with "sh -x". + (merge c20bf94abc sg/cvs-tests-with-x later to maint). + + * The codepath to replace an existing entry in the index had a bug in + updating the name hash structure, which has been fixed. + (merge 0e267b7a24 bp/refresh-cache-ent-rehash-fix later to maint). + + * The transfer.fsckobjects configuration tells "git fetch" to + validate the data and connected-ness of objects in the received + pack; the code to perform this check has been taught about the + narrow clone's convention that missing objects that are reachable + from objects in a pack that came from a promisor remote is OK. + + * There was an unused file-scope static variable left in http.c when + building for versions of libCURL that is older than 7.19.4, which + has been fixed. + (merge b8fd6008ec rj/http-code-cleanup later to maint). + + * Shell script portability fix. + (merge 206a6ae013 ml/filter-branch-portability-fix later to maint). + + * Other minor doc, test and build updates and code cleanups. + (merge e2a5a028c7 bw/oidmap-autoinit later to maint). + (merge ec3b4b06f8 cl/t9001-cleanup later to maint). + (merge e1b3f3dd38 ks/submodule-doc-updates later to maint). + (merge fbac558a9b rs/describe-unique-abbrev later to maint). + (merge 8462ff43e4 tb/crlf-conv-flags later to maint). + (merge 7d68bb0766 rb/hashmap-h-compilation-fix later to maint). + (merge 3449847168 cc/sha1-file-name later to maint). + (merge ad622a256f ds/use-get-be64 later to maint). + (merge f919ffebed sg/cocci-move-array later to maint). + (merge 4e801463c7 jc/mailinfo-cleanup-fix later to maint). + (merge ef5b3a6c5e nd/shared-index-fix later to maint). + (merge 9f5258cbb8 tz/doc-show-defaults-to-head later to maint). + (merge b780e4407d jc/worktree-add-short-help later to maint). + (merge ae239fc8e5 rs/cocci-strbuf-addf-to-addstr later to maint). + (merge 2e22a85e5c nd/ignore-glob-doc-update later to maint). + (merge 3738031581 jk/gettext-poison later to maint). + (merge 54360a1956 rj/sparse-updates later to maint). + (merge 12e31a6b12 sg/doc-test-must-fail-args later to maint). + (merge 760f1ad101 bc/doc-interpret-trailers-grammofix later to maint). + (merge 4ccf461f56 bp/fsmonitor later to maint). + (merge a6119f82b1 jk/test-hashmap-updates later to maint). + (merge 5aea9fe6cc rd/typofix later to maint). + (merge e4e5da2796 sb/status-doc-fix later to maint). + (merge 7976e901c8 gs/test-unset-xdg-cache-home later to maint). + (merge d023df1ee6 tg/worktree-create-tracking later to maint). + (merge 4cbe92fd41 sm/mv-dry-run-update later to maint). + (merge 75e5e9c3f7 sb/color-h-cleanup later to maint). + (merge 2708ef4af6 sg/t6300-modernize later to maint). + (merge d88e92d4e0 bw/doc-submodule-recurse-config-with-clone later to maint). + (merge f74bbc8dd2 jk/cached-commit-buffer later to maint). + (merge 1316416903 ms/non-ascii-ticks later to maint). + (merge 878056005e rs/strbuf-read-file-or-whine later to maint). + (merge 79f0ba1547 jk/strbuf-read-file-close-error later to maint). + (merge edfb8ba068 ot/ref-filter-cleanup later to maint). + (merge 11395a3b4b jc/test-must-be-empty later to maint). + (merge 768b9d6db7 mk/doc-pretty-fill later to maint). + (merge 2caa7b8d27 ab/man-sec-list later to maint). + (merge 40c17eb184 ks/t3200-typofix later to maint). + (merge bd9958c358 dp/merge-strategy-doc-fix later to maint). + (merge 9ee0540a40 js/ming-strftime later to maint). + (merge 1775e990f7 tz/complete-tag-delete-tagname later to maint). + (merge 00a4b03501 rj/warning-uninitialized-fix later to maint). + (merge b635ed97a0 jk/attributes-path-doc later to maint). diff --git a/Documentation/RelNotes/2.17.1.txt b/Documentation/RelNotes/2.17.1.txt new file mode 100644 index 0000000000..e01384fe8e --- /dev/null +++ b/Documentation/RelNotes/2.17.1.txt @@ -0,0 +1,16 @@ +Git v2.17.1 Release Notes +========================= + +Fixes since v2.17 +----------------- + + * This release contains the same fixes made in the v2.13.7 version of + Git, covering CVE-2018-11233 and 11235, and forward-ported to + v2.14.4, v2.15.2 and v2.16.4 releases. See release notes to + v2.13.7 for details. + + * In addition to the above fixes, this release has support on the + server side to reject pushes to repositories that attempt to create + such problematic .gitmodules file etc. as tracked contents, to help + hosting sites protect their customers by preventing malicious + contents from spreading. diff --git a/Documentation/RelNotes/2.18.0.txt b/Documentation/RelNotes/2.18.0.txt new file mode 100644 index 0000000000..3ea280cf68 --- /dev/null +++ b/Documentation/RelNotes/2.18.0.txt @@ -0,0 +1,583 @@ +Git 2.18 Release Notes +====================== + +Updates since v2.17 +------------------- + +UI, Workflows & Features + + * Rename detection logic that is used in "merge" and "cherry-pick" has + learned to guess when all of x/a, x/b and x/c have moved to z/a, + z/b and z/c, it is likely that x/d added in the meantime would also + want to move to z/d by taking the hint that the entire directory + 'x' moved to 'z'. A bug causing dirty files involved in a rename + to be overwritten during merge has also been fixed as part of this + work. Incidentally, this also avoids updating a file in the + working tree after a (non-trivial) merge whose result matches what + our side originally had. + + * "git filter-branch" learned to use a different exit code to allow + the callers to tell the case where there was no new commits to + rewrite from other error cases. + + * When built with more recent cURL, GIT_SSL_VERSION can now specify + "tlsv1.3" as its value. + + * "git gui" learned that "~/.ssh/id_ecdsa.pub" and + "~/.ssh/id_ed25519.pub" are also possible SSH key files. + (merge 2e2f0288ef bb/git-gui-ssh-key-files later to maint). + + * "git gui" performs commit upon CTRL/CMD+ENTER but the + CTRL/CMD+KP_ENTER (i.e. enter key on the numpad) did not have the + same key binding. It now does. + (merge 28a1d94a06 bp/git-gui-bind-kp-enter later to maint). + + * "git gui" has been taught to work with old versions of tk (like + 8.5.7) that do not support "ttk::style theme use" as a way to query + the current theme. + (merge 4891961105 cb/git-gui-ttk-style later to maint). + + * "git rebase" has learned to honor "--signoff" option when using + backends other than "am" (but not "--preserve-merges"). + + * "git branch --list" during an interrupted "rebase -i" now lets + users distinguish the case where a detached HEAD is being rebased + and a normal branch is being rebased. + + * "git mergetools" learned talking to guiffy. + + * The scripts in contrib/emacs/ have outlived their usefulness and + have been replaced with a stub that errors out and tells the user + there are replacements. + + * The new "working-tree-encoding" attribute can ask Git to convert the + contents to the specified encoding when checking out to the working + tree (and the other way around when checking in). + + * The "git config" command uses separate options e.g. "--int", + "--bool", etc. to specify what type the caller wants the value to + be interpreted as. A new "--type=<typename>" option has been + introduced, which would make it cleaner to define new types. + + * "git config --get" learned the "--default" option, to help the + calling script. Building on top of the above changes, the + "git config" learns "--type=color" type. Taken together, you can + do things like "git config --get foo.color --default blue" and get + the ANSI color sequence for the color given to foo.color variable, + or "blue" if the variable does not exist. + + * "git ls-remote" learned an option to allow sorting its output based + on the refnames being shown. + + * The command line completion (in contrib/) has been taught that "git + stash save" has been deprecated ("git stash push" is the preferred + spelling in the new world) and does not offer it as a possible + completion candidate when "git stash push" can be. + + * "git gc --prune=nonsense" spent long time repacking and then + silently failed when underlying "git prune --expire=nonsense" + failed to parse its command line. This has been corrected. + + * Error messages from "git push" can be painted for more visibility. + + * "git http-fetch" (deprecated) had an optional and experimental + "feature" to fetch only commits and/or trees, which nobody used. + This has been removed. + + * The functionality of "$GIT_DIR/info/grafts" has been superseded by + the "refs/replace/" mechanism for some time now, but the internal + code had support for it in many places, which has been cleaned up + in order to drop support of the "grafts" mechanism. + + * "git worktree add" learned to check out an existing branch. + + * "git --no-pager cmd" did not have short-and-sweet single letter + option. Now it does as "-P". + (merge 7213c28818 js/no-pager-shorthand later to maint). + + * "git rebase" learned "--rebase-merges" to transplant the whole + topology of commit graph elsewhere. + + * "git status" learned to pay attention to UI related diff + configuration variables such as diff.renames. + + * The command line completion mechanism (in contrib/) learned to load + custom completion file for "git $command" where $command is a + custom "git-$command" that the end user has on the $PATH when using + newer version of bash-completion. + + * "git send-email" can sometimes offer confirmation dialog "Send this + email?" with choices 'Yes', 'No', 'Quit', and 'All'. A new action + 'Edit' has been added to this dialog's choice. + + * With merge.renames configuration set to false, the recursive merge + strategy can be told not to spend cycles trying to find renamed + paths and merge them accordingly. + + * "git status" learned to honor a new status.renames configuration to + skip rename detection, which could be useful for those who want to + do so without disabling the default rename detection done by the + "git diff" command. + + * Command line completion (in contrib/) learned to complete pathnames + for various commands better. + + * "git blame" learns to unhighlight uninteresting metadata from the + originating commit on lines that are the same as the previous one, + and also paint lines in different colors depending on the age of + the commit. + + * Transfer protocol v2 learned to support the partial clone. + + * When a short hexadecimal string is used to name an object but there + are multiple objects that share the string as the prefix of their + names, the code lists these ambiguous candidates in a help message. + These object names are now sorted according to their types for + easier eyeballing. + + * "git fetch $there $refspec" that talks over protocol v2 can take + advantage of server-side ref filtering; the code has been extended + so that this mechanism triggers also when fetching with configured + refspec. + + * Our HTTP client code used to advertise that we accept gzip encoding + from the other side; instead, just let cURL library to advertise + and negotiate the best one. + + * "git p4" learned to "unshelve" shelved commit from P4. + (merge 123f631761 ld/p4-unshelve later to maint). + + +Performance, Internal Implementation, Development Support etc. + + * A "git fetch" from a repository with insane number of refs into a + repository that is already up-to-date still wasted too many cycles + making many lstat(2) calls to see if these objects at the tips + exist as loose objects locally. These lstat(2) calls are optimized + away by enumerating all loose objects beforehand. + It is unknown if the new strategy negatively affects existing use + cases, fetching into a repository with many loose objects from a + repository with small number of refs. + + * Git can be built to use either v1 or v2 of the PCRE library, and so + far, the build-time configuration USE_LIBPCRE=YesPlease instructed + the build procedure to use v1, but now it means v2. USE_LIBPCRE1 + and USE_LIBPCRE2 can be used to explicitly choose which version to + use, as before. + + * The build procedure learned to optionally use symbolic links + (instead of hardlinks and copies) to install "git-foo" for built-in + commands, whose binaries are all identical. + + * Conversion from uchar[20] to struct object_id continues. + + * The way "git worktree prune" worked internally has been simplified, + by assuming how "git worktree move" moves an existing worktree to a + different place. + + * Code clean-up for the "repository" abstraction. + (merge 00a3da2a13 nd/remove-ignore-env-field later to maint). + + * Code to find the length to uniquely abbreviate object names based + on packfile content, which is a relatively recent addtion, has been + optimized to use the same fan-out table. + + * The mechanism to use parse-options API to automate the command line + completion continues to get extended and polished. + + * Copies of old scripted Porcelain commands in contrib/examples/ have + been removed. + + * Some tests that rely on the exact hardcoded values of object names + have been updated in preparation for hash function migration. + + * Perf-test update. + + * Test helper update. + + * The effort continues to refactor the internal global data structure + to make it possible to open multiple repositories, work with and + then close them, + + * Small test-helper programs have been consolidated into a single + binary. + + * API clean-up around ref-filter code. + + * Shell completion (in contrib) that gives list of paths have been + optimized somewhat. + + * The index file is updated to record the fsmonitor section after a + full scan was made, to avoid wasting the effort that has already + spent. + + * Performance measuring framework in t/perf learned to help bisecting + performance regressions. + + * Some multi-word source filenames are being renamed to separate + words with dashes instead of underscores. + + * An reusable "memory pool" implementation has been extracted from + fast-import.c, which in turn has become the first user of the + mem-pool API. + + * A build-time option has been added to allow Git to be told to refer + to its associated files relative to the main binary, in the same + way that has been possible on Windows for quite some time, for + Linux, BSDs and Darwin. + + * Precompute and store information necessary for ancestry traversal + in a separate file to optimize graph walking. + + * The effort to pass the repository in-core structure throughout the + API continues. This round deals with the code that implements the + refs/replace/ mechanism. + + * The build procedure "make DEVELOPER=YesPlease" learned to enable a + bit more warning options depending on the compiler used to help + developers more. There also is "make DEVOPTS=tokens" knob + available now, for those who want to help fixing warnings we + usually ignore, for example. + + * A new version of the transport protocol is being worked on. + + * The code to interface to GPG has been restructured somewhat to make + it cleaner to integrate with other types of signature systems later. + + * The code has been taught to use the duplicated information stored + in the commit-graph file to learn the tree object name for a commit + to avoid opening and parsing the commit object when it makes sense + to do so. + + * "git gc" in a large repository takes a lot of time as it considers + to repack all objects into one pack by default. The command has + been taught to pretend as if the largest existing packfile is + marked with ".keep" so that it is left untouched while objects in + other packs and loose ones are repacked. + + * The transport protocol v2 is getting updated further. + + * The codepath around object-info API has been taught to take the + repository object (which in turn tells the API which object store + the objects are to be located). + + * "git pack-objects" needs to allocate tons of "struct object_entry" + while doing its work, and shrinking its size helps the performance + quite a bit. + + * The implementation of "git rebase -i --root" has been updated to use + the sequencer machinery more. + + * Developer support update, by using BUG() macro instead of die() to + mark codepaths that should not happen more clearly. + + * Developer support. Use newer GCC on one of the builds done at + TravisCI.org to get more warnings and errors diagnosed. + + * Conversion from uchar[20] to struct object_id continues. + + * By code restructuring of submodule merge in merge-recursive, + informational messages from the codepath are now given using the + same mechanism as other output, and honor the merge.verbosity + configuration. The code also learned to give a few new messages + when a submodule three-way merge resolves cleanly when one side + records a descendant of the commit chosen by the other side. + + * Avoid unchecked snprintf() to make future code auditing easier. + (merge ac4896f007 jk/snprintf-truncation later to maint). + + * Many tests hardcode the raw object names, which would change once + we migrate away from SHA-1. While some of them must test against + exact object names, most of them do not have to use hardcoded + constants in the test. The latter kind of tests have been updated + to test the moral equivalent of the original without hardcoding the + actual object names. + + * The list of commands with their various attributes were spread + across a few places in the build procedure, but it now is getting a + bit more consolidated to allow more automation. + + * Quite a many tests assumed that newly created refs are made as + loose refs using the files backend, which have been updated to use + proper plumbing like rev-parse and update-ref, to avoid breakage + once we start using different ref backends. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v2.17 +----------------- + + * "git shortlog cruft" aborted with a BUG message when run outside a + Git repository. The command has been taught to complain about + extra and unwanted arguments on its command line instead in such a + case. + (merge 4aa0161e83 ma/shortlog-revparse later to maint). + + * "git stash push -u -- <pathspec>" gave an unnecessary and confusing + error message when there was no tracked files that match the + <pathspec>, which has been fixed. + (merge 353278687e tg/stash-untracked-with-pathspec-fix later to maint). + + * "git tag --contains no-such-commit" gave a full list of options + after giving an error message. + (merge 3bb0923f06 ps/contains-id-error-message later to maint). + + * "diff-highlight" filter (in contrib/) learned to understand "git log + --graph" output better. + (merge 4551fbba14 jk/diff-highlight-graph-fix later to maint). + + * when refs that do not point at committish are given, "git + filter-branch" gave a misleading error messages. This has been + corrected. + (merge f78ab355e7 yk/filter-branch-non-committish-refs later to maint). + + * "git submodule status" misbehaved on a submodule that has been + removed from the working tree. + (merge 74b6bda32f rs/status-with-removed-submodule later to maint). + + * When credential helper exits very quickly without reading its + input, it used to cause Git to die with SIGPIPE, which has been + fixed. + (merge a0d51e8d0e eb/cred-helper-ignore-sigpipe later to maint). + + * "git rebase --keep-empty" still removed an empty commit if the + other side contained an empty commit (due to the "does an + equivalent patch exist already?" check), which has been corrected. + (merge 3d946165e1 pw/rebase-keep-empty-fixes later to maint). + + * Some codepaths, including the refs API, get and keep relative + paths, that go out of sync when the process does chdir(2). The + chdir-notify API is introduced to let these codepaths adjust these + cached paths to the new current directory. + (merge fb9c2d2703 jk/relative-directory-fix later to maint). + + * "cd sub/dir && git commit ../path" ought to record the changes to + the file "sub/path", but this regressed long time ago. + (merge 86238e07ef bw/commit-partial-from-subdirectory-fix later to maint). + + * Recent introduction of "--log-destination" option to "git daemon" + did not work well when the daemon was run under "--inetd" mode. + (merge e67d906d73 lw/daemon-log-destination later to maint). + + * Small fix to the autoconf build procedure. + (merge 249482daf0 es/fread-reads-dir-autoconf-fix later to maint). + + * Fix an unexploitable (because the oversized contents are not under + attacker's control) buffer overflow. + (merge d8579accfa bp/fsmonitor-bufsize-fix later to maint). + + * Recent simplification of build procedure forgot a bit of tweak to + the build procedure of contrib/mw-to-git/ + (merge d8698987f3 ab/simplify-perl-makefile later to maint). + + * Moving a submodule that itself has submodule in it with "git mv" + forgot to make necessary adjustment to the nested sub-submodules; + now the codepath learned to recurse into the submodules. + + * "git config --unset a.b", when "a.b" is the last variable in an + otherwise empty section "a", left an empty section "a" behind, and + worse yet, a subsequent "git config a.c value" did not reuse that + empty shell and instead created a new one. These have been + (partially) corrected. + (merge c71d8bb38a js/empty-config-section-fix later to maint). + + * "git worktree remove" learned that "-f" is a shorthand for + "--force" option, just like for "git worktree add". + (merge d228eea514 sb/worktree-remove-opt-force later to maint). + + * The completion script (in contrib/) learned to clear cached list of + command line options upon dot-sourcing it again in a more efficient + way. + (merge 94408dc71c sg/completion-clear-cached later to maint). + + * "git svn" had a minor thinko/typo which has been fixed. + (merge 51db271587 ab/git-svn-get-record-typofix later to maint). + + * During a "rebase -i" session, the code could give older timestamp + to commits created by later "pick" than an earlier "reword", which + has been corrected. + (merge 12f7babd6b js/ident-date-fix later to maint). + + * "git submodule status" did not check the symbolic revision name it + computed for the submodule HEAD is not the NULL, and threw it at + printf routines, which has been corrected. + (merge 0b5e2ea7cf nd/submodule-status-fix later to maint). + + * When fed input that already has In-Reply-To: and/or References: + headers and told to add the same information, "git send-email" + added these headers separately, instead of appending to an existing + one, which is a violation of the RFC. This has been corrected. + (merge 256be1d3f0 sa/send-email-dedup-some-headers later to maint). + + * "git fast-export" had a regression in v2.15.0 era where it skipped + some merge commits in certain cases, which has been corrected. + (merge be011bbe00 ma/fast-export-skip-merge-fix later to maint). + + * The code did not propagate the terminal width to subprocesses via + COLUMNS environment variable, which it now does. This caused + trouble to "git column" helper subprocess when "git tag --column=row" + tried to list the existing tags on a display with non-default width. + (merge b5d5a567fb nd/term-columns later to maint). + + * We learned that our source files with ".pl" and ".py" extensions + are Perl and Python files respectively and changes to them are + better viewed as such with appropriate diff drivers. + (merge 7818b619e2 ab/perl-python-attrs later to maint). + + * "git rebase -i" sometimes left intermediate "# This is a + combination of N commits" message meant for the human consumption + inside an editor in the final result in certain corner cases, which + has been fixed. + (merge 15ef69314d js/rebase-i-clean-msg-after-fixup-continue later to maint). + + * A test to see if the filesystem normalizes UTF-8 filename has been + updated to check what we need to know in a more direct way, i.e. a + path created in NFC form can be accessed with NFD form (or vice + versa) to cope with APFS as well as HFS. + (merge 742ae10e35 tb/test-apfs-utf8-normalization later to maint). + + * "git format-patch --cover --attach" created a broken MIME multipart + message for the cover letter, which has been fixed by keeping the + cover letter as plain text file. + (merge 50cd54ef4e bc/format-patch-cover-no-attach later to maint). + + * The split-index feature had a long-standing and dormant bug in + certain use of the in-core merge machinery, which has been fixed. + (merge 7db118303a en/unpack-trees-split-index-fix later to maint). + + * Asciidoctor gives a reasonable imitation for AsciiDoc, but does not + render illustration in a literal block correctly when indented with + HT by default. The problem is fixed by forcing 8-space tabs. + (merge 379805051d bc/asciidoctor-tab-width later to maint). + + * Code clean-up to adjust to a more recent lockfile API convention that + allows lockfile instances kept on the stack. + (merge 0fa5a2ed8d ma/lockfile-cleanup later to maint). + + * the_repository->index is not a allocated piece of memory but + repo_clear() indiscriminately attempted to free(3) it, which has + been corrected. + (merge 74373b5f10 nd/repo-clear-keep-the-index later to maint). + + * Code clean-up to avoid non-standard-conformant pointer arithmetic. + (merge c112084af9 rs/no-null-ptr-arith-in-fast-export later to maint). + + * Code clean-up to turn history traversal more robust in a + semi-corrupt repository. + (merge 8702b30fd7 jk/unavailable-can-be-missing later to maint). + + * "git update-ref A B" is supposed to ensure that ref A does not yet + exist when B is a NULL OID, but this check was not done correctly + for pseudo-refs outside refs/ hierarchy, e.g. MERGE_HEAD. + + * "git submodule update" and "git submodule add" supported the + "--reference" option to borrow objects from a neighbouring local + repository like "git clone" does, but lacked the more recent + invention "--dissociate". Also "git submodule add" has been taught + to take the "--progress" option. + (merge a0ef29341a cf/submodule-progress-dissociate later to maint). + + * Update credential-netrc helper (in contrib/) to allow customizing + the GPG used to decrypt the encrypted .netrc file. + (merge 786ef50a23 lm/credential-netrc later to maint). + + * "git submodule update" attempts two different kinds of "git fetch" + against the upstream repository to grab a commit bound at the + submodule's path, but it incorrectly gave up if the first kind + (i.e. a normal fetch) failed, making the second "last resort" one + (i.e. fetching an exact commit object by object name) ineffective. + This has been corrected. + (merge e30d833671 sb/submodule-update-try-harder later to maint). + + * Error behaviour of "git grep" when it cannot read the index was + inconsistent with other commands that uses the index, which has + been corrected to error out early. + (merge b2aa84c789 sb/grep-die-on-unreadable-index later to maint). + + * We used to call regfree() after regcomp() failed in some codepaths, + which have been corrected. + (merge 17154b1576 ma/regex-no-regfree-after-comp-fail later to maint). + + * The import-tars script (in contrib/) has been taught to handle + tarballs with overly long paths that use PAX extended headers. + (merge 12ecea46e3 pa/import-tars-long-names later to maint). + + * "git rev-parse Y..." etc. misbehaved when given endpoints were + not committishes. + (merge 0ed556d38f en/rev-parse-invalid-range later to maint). + + * "git pull --recurse-submodules --rebase", when the submodule + repository's history did not have anything common between ours and + the upstream's, failed to execute. We need to fetch from them to + continue even in such a case. + (merge 4d36f88be7 jt/submodule-pull-recurse-rebase later to maint). + + * "git remote update" can take both a single remote nickname and a + nickname for remote groups, but only one of them was documented. + (merge a97447a42a nd/remote-update-doc later to maint). + + * "index-pack --strict" has been taught to make sure that it runs the + final object integrity checks after making the freshly indexed + packfile available to itself. + (merge 3737746120 jk/index-pack-maint later to maint). + + * Make zlib inflate codepath more robust against versions of zlib + that clobber unused portion of outbuf. + (merge b611396e97 jl/zlib-restore-nul-termination later to maint). + + * Fix old merge glitch in Documentation during v2.13-rc0 era. + (merge 28cb06020b mw/doc-merge-enumfix later to maint). + + * The code to read compressed bitmap was not careful to avoid reading + past the end of the file, which has been corrected. + (merge 1140bf01ec jk/ewah-bounds-check later to maint). + + * "make NO_ICONV=NoThanks" did not override NEEDS_LIBICONV + (i.e. linkage of -lintl, -liconv, etc. that are platform-specific + tweaks), which has been corrected. + (merge fdb1fbbc7d es/make-no-iconv later to maint). + + * Other minor doc, test and build updates and code cleanups. + (merge 248f66ed8e nd/trace-with-env later to maint). + (merge 14ced5562c ys/bisect-object-id-missing-conversion-fix later to maint). + (merge 5988eb631a ab/doc-hash-brokenness later to maint). + (merge a4d4e32a70 pk/test-avoid-pipe-hiding-exit-status later to maint). + (merge 05e293c1ac jk/flockfile-stdio later to maint). + (merge e9184b0789 jk/t5561-missing-curl later to maint). + (merge b1801b85a3 nd/worktree-move later to maint). + (merge bbd374dd20 ak/bisect-doc-typofix later to maint). + (merge 4855f06fb3 mn/send-email-credential-doc later to maint). + (merge 8523b1e355 en/doc-typoes later to maint). + (merge 43b44ccfe7 js/t5404-path-fix later to maint). + (merge decf711fc1 ps/test-chmtime-get later to maint). + (merge 22d11a6e8e es/worktree-docs later to maint). + (merge 92a5dbbc22 tg/use-git-contacts later to maint). + (merge adc887221f tq/t1510 later to maint). + (merge bed21a8ad6 sg/doc-gc-quote-mismatch-fix later to maint). + (merge 73364e4f10 tz/doc-git-urls-reference later to maint). + (merge cd1e606bad bc/mailmap-self later to maint). + (merge f7997e3682 ao/config-api-doc later to maint). + (merge ee930754d8 jk/apply-p-doc later to maint). + (merge 011b648646 nd/pack-format-doc later to maint). + (merge 87a6bb701a sg/t5310-jgit-bitmap-test later to maint). + (merge f6b82970aa sg/t5516-fixes later to maint). + (merge 4362da078e sg/t7005-spaces-in-filenames-cleanup later to maint). + (merge 7d0ee47c11 js/test-unset-prereq later to maint). + (merge 5356a3c354 ah/misc-doc-updates later to maint). + (merge 92c4a7a129 nd/completion-aliasfiletype-typofix later to maint). + (merge 58bd77b66a nd/pack-unreachable-objects-doc later to maint). + (merge 4ed79d5203 sg/t6500-no-redirect-of-stdin later to maint). + (merge 17b8a2d6cd jk/config-blob-sans-repo later to maint). + (merge 590551ca2c rd/tag-doc-lightweight later to maint). + (merge 44f560fc16 rd/init-typo later to maint). + (merge f156a0934a rd/p4-doc-markup-env later to maint). + (merge 2a00502b14 tg/doc-sec-list later to maint). + (merge 47cc91310a jk/submodule-fsck-loose-fixup later to maint). + (merge efde7b725c rd/comment-typofix-in-sha1-file later to maint). + (merge 7eedad15df rd/diff-options-typofix later to maint). + (merge 58ebd936cc km/doc-workflows-typofix later to maint). + (merge 30aa96cdf8 rd/doc-remote-tracking-with-hyphen later to maint). + (merge cf317877e3 ks/branch-set-upstream later to maint). + (merge 8de19d6be8 sg/t7406-chain-fix later to maint). diff --git a/Documentation/RelNotes/2.19.0.txt b/Documentation/RelNotes/2.19.0.txt new file mode 100644 index 0000000000..2b45b6ff5c --- /dev/null +++ b/Documentation/RelNotes/2.19.0.txt @@ -0,0 +1,101 @@ +Git 2.19 Release Notes +====================== + +Updates since v2.18 +------------------- + +UI, Workflows & Features + + * "git diff" compares the index and the working tree. For paths + added with intent-to-add bit, the command shows the full contents + of them as added, but the paths themselves were not marked as new + files. They are now shown as new by default. + + "git apply" learned the "--intent-to-add" option so that an + otherwise working-tree-only application of a patch will add new + paths to the index marked with the "intent-to-add" bit. + + +Performance, Internal Implementation, Development Support etc. + + * The bulk of "git submodule foreach" has been rewritten in C. + + * The in-core "commit" object had an all-purpose "void *util" field, + which was tricky to use especially in library-ish part of the + code. All of the existing uses of the field has been migrated to a + more dedicated "commit-slab" mechanism and the field is eliminated. + + * A less often used command "git show-index" has been modernized. + (merge fb3010c31f jk/show-index later to maint). + + * The conversion to pass "the_repository" and then "a_repository" + throughout the object access API continues. + + * Continuing with the idea to programatically enumerate various + pieces of data required for command line completion, teach the + codebase to report the list of configuration variables + subcommands care about to help complete them. + + * Separate "rebase -p" codepath out of "rebase -i" implementation to + slim down the latter and make it easier to manage. + + * Make refspec parsing codepath more robust. + + * Some flaky tests have been fixed. + + * Continuing with the idea to programmatically enumerate various + pieces of data required for command line completion, the codebase + has been taught to enumerate options prefixed with "--no-" to + negate them. + + * Build and test procedure for netrc credential helper (in contrib/) + has been updated. + + +Fixes since v2.18 +----------------- + + * "git remote update" can take both a single remote nickname and a + nickname for remote groups, and the completion script (in contrib/) + has been taught about it. + (merge 9cd4382ad5 ls/complete-remote-update-names later to maint). + + * "git fetch --shallow-since=<cutoff>" that specifies the cut-off + point that is newer than the existing history used to end up + grabbing the entire history. Such a request now errors out. + (merge e34de73c56 nd/reject-empty-shallow-request later to maint). + + * Fix for 2.17-era regression around `core.safecrlf`. + (merge 6cb09125be as/safecrlf-quiet-fix later to maint). + + * The recent addition of "partial clone" experimental feature kicked + in when it shouldn't, namely, when there is no partial-clone filter + defined even if extensions.partialclone is set. + (merge cac1137dc4 jh/partial-clone later to maint). + + * "git send-pack --signed" (hence "git push --signed" over the http + transport) did not read user ident from the config mechanism to + determine whom to sign the push certificate as, which has been + corrected. + (merge d067d98887 ms/send-pack-honor-config later to maint). + + * "git fetch-pack --all" used to unnecessarily fail upon seeing an + annotated tag that points at an object other than a commit. + (merge c12c9df527 jk/fetch-all-peeled-fix later to maint). + + * When user edits the patch in "git add -p" and the user's editor is + set to strip trailing whitespaces indiscriminately, an empty line + that is unchanged in the patch would become completely empty + (instead of a line with a sole SP on it). The code introduced in + Git 2.17 timeframe failed to parse such a patch, but now it learned + to notice the situation and cope with it. + (merge f4d35a6b49 pw/add-p-recount later to maint). + + * The code to try seeing if a fetch is necessary in a submodule + during a fetch with --recurse-submodules got confused when the path + to the submodule was changed in the range of commits in the + superproject, sometimes showing "(null)". This has been corrected. + + * Code cleanup. + (merge aee9be2ebe sg/update-ref-stdin-cleanup later to maint). + (merge 037714252f jc/clean-after-sanity-tests later to maint). diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index a1d0feca36..2488544407 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -176,6 +176,12 @@ that is fine, but please mark it as such. [[send-patches]] === Sending your patches. +:security-ml: footnoteref:[security-ml,The Git Security mailing list: git-security@googlegroups.com] + +Before sending any patches, please note that patches that may be +security relevant should be submitted privately to the Git Security +mailing list{security-ml}, instead of the public mailing list. + Learn to use format-patch and send-email if possible. These commands are optimized for the workflow of sending patches, avoiding many ways your existing e-mail client that is optimized for "multipart/*" mime @@ -259,17 +265,24 @@ patch, format it as "multipart/signed", not a text/plain message that starts with `-----BEGIN PGP SIGNED MESSAGE-----`. That is not a text/plain, it's something else. +:security-ml-ref: footnoteref:[security-ml] + +As mentioned at the beginning of the section, patches that may be +security relevant should not be submitted to the public mailing list +mentioned below, but should instead be sent privately to the Git +Security mailing list{security-ml-ref}. + Send your patch with "To:" set to the mailing list, with "cc:" listing -people who are involved in the area you are touching (the output from -`git blame $path` and `git shortlog --no-merges $path` would help to +people who are involved in the area you are touching (the `git +contacts` command in `contrib/contacts/` can help to identify them), to solicit comments and reviews. -:1: footnote:[The current maintainer: gitster@pobox.com] -:2: footnote:[The mailing list: git@vger.kernel.org] +:current-maintainer: footnote:[The current maintainer: gitster@pobox.com] +:git-ml: footnote:[The mailing list: git@vger.kernel.org] After the list reached a consensus that it is a good idea to apply the -patch, re-send it with "To:" set to the maintainer{1} and "cc:" the -list{2} for inclusion. +patch, re-send it with "To:" set to the maintainer{current-maintainer} and "cc:" the +list{git-ml} for inclusion. Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and `Tested-by:` lines as necessary to credit people who helped your diff --git a/Documentation/config.txt b/Documentation/config.txt index 0e25b2c92b..1cc18a828c 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -530,6 +530,12 @@ core.autocrlf:: This variable can be set to 'input', in which case no output conversion is performed. +core.checkRoundtripEncoding:: + A comma and/or whitespace separated list of encodings that Git + performs UTF-8 round trip checks on if they are used in an + `working-tree-encoding` attribute (see linkgit:gitattributes[5]). + The default value is `SHIFT-JIS`. + core.symlinks:: If false, symbolic links are checked out as small plain files that contain the link text. linkgit:git-update-index[1] and @@ -898,6 +904,10 @@ core.notesRef:: This setting defaults to "refs/notes/commits", and it can be overridden by the `GIT_NOTES_REF` environment variable. See linkgit:git-notes[1]. +core.commitGraph:: + Enable git commit graph feature. Allows reading from the + commit-graph file. + core.sparseCheckout:: Enable "sparse checkout" feature. See section "Sparse checkout" in linkgit:git-read-tree[1] for more information. @@ -1058,6 +1068,10 @@ branch.<name>.rebase:: "git pull" is run. See "pull.rebase" for doing this in a non branch-specific manner. + +When `merges`, pass the `--rebase-merges` option to 'git rebase' +so that the local merge commits are included in the rebase (see +linkgit:git-rebase[1] for details). ++ When preserve, also pass `--preserve-merges` along to 'git rebase' so that locally committed merge commits will not be flattened by running 'git pull'. @@ -1088,6 +1102,16 @@ clean.requireForce:: A boolean to make git-clean do nothing unless given -f, -i or -n. Defaults to true. +color.advice:: + A boolean to enable/disable color in hints (e.g. when a push + failed, see `advice.*` for a list). May be set to `always`, + `false` (or `never`) or `auto` (or `true`), in which case colors + are used only when the error output goes to a terminal. If + unset, then the value of `color.ui` is used (`auto` by default). + +color.advice.hint:: + Use customized color for hints. + color.branch:: A boolean to enable/disable color in the output of linkgit:git-branch[1]. May be set to `always`, @@ -1138,7 +1162,8 @@ color.diff.<slot>:: color.decorate.<slot>:: Use customized color for 'git log --decorate' output. `<slot>` is one of `branch`, `remoteBranch`, `tag`, `stash` or `HEAD` for local - branches, remote-tracking branches, tags, stash and HEAD, respectively. + branches, remote-tracking branches, tags, stash and HEAD, respectively + and `grafted` for grafted commits. color.grep:: When set to `always`, always highlight matches. When `false` (or @@ -1190,6 +1215,15 @@ color.pager:: A boolean to enable/disable colored output when the pager is in use (default is true). +color.push:: + A boolean to enable/disable color in push errors. May be set to + `always`, `false` (or `never`) or `auto` (or `true`), in which + case colors are used only when the error output goes to a terminal. + If unset, then the value of `color.ui` is used (`auto` by default). + +color.push.error:: + Use customized color for push errors. + color.showBranch:: A boolean to enable/disable color in the output of linkgit:git-show-branch[1]. May be set to `always`, @@ -1218,6 +1252,42 @@ color.status.<slot>:: status short-format), or `unmerged` (files which have unmerged changes). +color.blame.repeatedLines:: + Use the customized color for the part of git-blame output that + is repeated meta information per line (such as commit id, + author name, date and timezone). Defaults to cyan. + +color.blame.highlightRecent:: + This can be used to color the metadata of a blame line depending + on age of the line. ++ +This setting should be set to a comma-separated list of color and date settings, +starting and ending with a color, the dates should be set from oldest to newest. +The metadata will be colored given the colors if the the line was introduced +before the given timestamp, overwriting older timestamped colors. ++ +Instead of an absolute timestamp relative timestamps work as well, e.g. +2.weeks.ago is valid to address anything older than 2 weeks. ++ +It defaults to 'blue,12 month ago,white,1 month ago,red', which colors +everything older than one year blue, recent changes between one month and +one year old are kept white, and lines introduced within the last month are +colored red. + +blame.coloring:: + This determines the coloring scheme to be applied to blame + output. It can be 'repeatedLines', 'highlightRecent', + or 'none' which is the default. + +color.transport:: + A boolean to enable/disable color when pushes are rejected. May be + set to `always`, `false` (or `never`) or `auto` (or `true`), in which + case colors are used only when the error output goes to a terminal. + If unset, then the value of `color.ui` is used (`auto` by default). + +color.transport.rejected:: + Use customized color when a push was rejected. + color.ui:: This variable determines the default value for variables such as `color.diff` and `color.grep` that control the use of color @@ -1343,6 +1413,14 @@ credential.<url>.*:: credentialCache.ignoreSIGHUP:: Tell git-credential-cache--daemon to ignore SIGHUP, instead of quitting. +completion.commands:: + This is only used by git-completion.bash to add or remove + commands from the list of completed commands. Normally only + porcelain commands and a few select others are completed. You + can add more commands, separated by space, in this + variable. Prefixing the command with '-' will remove it from + the existing list. + include::diff-config.txt[] difftool.<tool>.path:: @@ -1398,7 +1476,16 @@ fetch.unpackLimit:: fetch.prune:: If true, fetch will automatically behave as if the `--prune` - option was given on the command line. See also `remote.<name>.prune`. + option was given on the command line. See also `remote.<name>.prune` + and the PRUNING section of linkgit:git-fetch[1]. + +fetch.pruneTags:: + If true, fetch will automatically behave as if the + `refs/tags/*:refs/tags/*` refspec was provided when pruning, + if not set already. This allows for setting both this option + and `fetch.prune` to maintain a 1=1 mapping to upstream + refs. See also `remote.<name>.pruneTags` and the PRUNING + section of linkgit:git-fetch[1]. fetch.output:: Control how ref update status is printed. Valid values are @@ -1549,6 +1636,18 @@ gc.autoDetach:: Make `git gc --auto` return immediately and run in background if the system supports it. Default is true. +gc.bigPackThreshold:: + If non-zero, all packs larger than this limit are kept when + `git gc` is run. This is very similar to `--keep-base-pack` + except that all packs that meet the threshold are kept, not + just the base pack. Defaults to zero. Common unit suffixes of + 'k', 'm', or 'g' are supported. ++ +Note that if the number of kept packs is more than gc.autoPackLimit, +this configuration variable is ignored, all packs except the base pack +will be repacked. After this the number of packs should go below +gc.autoPackLimit and gc.bigPackThreshold should be respected again. + gc.logExpiry:: If the file gc.log exists, then `git gc --auto` won't run unless that file is more than 'gc.logExpiry' old. Default is @@ -1948,6 +2047,7 @@ http.sslVersion:: - tlsv1.0 - tlsv1.1 - tlsv1.2 + - tlsv1.3 + Can be overridden by the `GIT_SSL_VERSION` environment variable. @@ -2412,6 +2512,7 @@ pack.window:: pack.depth:: The maximum delta depth used by linkgit:git-pack-objects[1] when no maximum depth is given on the command line. Defaults to 50. + Maximum value is 4095. pack.windowMemory:: The maximum size of memory that is consumed by each thread @@ -2448,7 +2549,8 @@ pack.deltaCacheLimit:: The maximum size of a delta, that is cached in linkgit:git-pack-objects[1]. This cache is used to speed up the writing object phase by not having to recompute the final delta - result once the best match for all objects is found. Defaults to 1000. + result once the best match for all objects is found. + Defaults to 1000. Maximum value is 65535. pack.threads:: Specifies the number of threads to spawn when searching for best @@ -2607,6 +2709,10 @@ pull.rebase:: pull" is run. See "branch.<name>.rebase" for setting this on a per-branch basis. + +When `merges`, pass the `--rebase-merges` option to 'git rebase' +so that the local merge commits are included in the rebase (see +linkgit:git-rebase[1] for details). ++ When preserve, also pass `--preserve-merges` along to 'git rebase' so that locally committed merge commits will not be flattened by running 'git pull'. @@ -2945,6 +3051,15 @@ remote.<name>.prune:: remote (as if the `--prune` option was given on the command line). Overrides `fetch.prune` settings, if any. +remote.<name>.pruneTags:: + When set to true, fetching from this remote by default will also + remove any local tags that no longer exist on the remote if pruning + is activated in general via `remote.<name>.prune`, `fetch.prune` or + `--prune`. Overrides `fetch.pruneTags` settings, if any. ++ +See also `remote.<name>.prune` and the PRUNING section of +linkgit:git-fetch[1]. + remotes.<group>:: The list of remotes which are fetched by "git remote update <group>". See linkgit:git-remote[1]. @@ -3100,6 +3215,18 @@ status.displayCommentPrefix:: behavior of linkgit:git-status[1] in Git 1.8.4 and previous. Defaults to false. +status.renameLimit:: + The number of files to consider when performing rename detection + in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to + the value of diff.renameLimit. + +status.renames:: + Whether and how Git detects renames in linkgit:git-status[1] and + linkgit:git-commit[1] . If set to "false", rename detection is + disabled. If set to "true", basic rename detection is enabled. + If set to "copies" or "copy", Git will detect copies, as well. + Defaults to the value of diff.renames. + status.showStash:: If set to true, linkgit:git-status[1] will display the number of entries currently stashed away. @@ -3210,7 +3337,8 @@ submodule.active:: submodule.recurse:: Specifies if commands recurse into submodules by default. This - applies to all commands that have a `--recurse-submodules` option. + applies to all commands that have a `--recurse-submodules` option, + except `clone`. Defaults to false. submodule.fetchJobs:: @@ -3343,6 +3471,10 @@ uploadpack.packObjectsHook:: was run. I.e., `upload-pack` will feed input intended for `pack-objects` to the hook, and expects a completed packfile on stdout. + +uploadpack.allowFilter:: + If this option is set, `upload-pack` will support partial + clone and partial fetch object filtering. + Note that this configuration variable is ignored if it is seen in the repository-level config (this is a safety measure against fetching from diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt index 5ca942ab5e..77caa66c2f 100644 --- a/Documentation/diff-config.txt +++ b/Documentation/diff-config.txt @@ -112,7 +112,8 @@ diff.orderFile:: diff.renameLimit:: The number of files to consider when performing the copy/rename - detection; equivalent to the 'git diff' option `-l`. + detection; equivalent to the 'git diff' option `-l`. This setting + has no effect if rename detection is turned off. diff.renames:: Whether and how Git detects renames. If set to "false", diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index 743af97b06..41064909ee 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -64,7 +64,7 @@ ifndef::git-format-patch[] endif::git-format-patch[] --indent-heuristic:: - Enable the heuristic that shift diff hunk boundaries to make patches + Enable the heuristic that shifts diff hunk boundaries to make patches easier to read. This is the default. --no-indent-heuristic:: @@ -106,7 +106,7 @@ diff" algorithm internally. low-occurrence common elements". -- + -For instance, if you configured diff.algorithm variable to a +For instance, if you configured the `diff.algorithm` variable to a non-default value and want to use the default one, then you have to use `--diff-algorithm=default` option. @@ -128,6 +128,14 @@ have to use `--diff-algorithm=default` option. These parameters can also be set individually with `--stat-width=<width>`, `--stat-name-width=<name-width>` and `--stat-count=<count>`. +--compact-summary:: + Output a condensed summary of extended header information such + as file creations or deletions ("new" or "gone", optionally "+l" + if it's a symlink) and mode changes ("+x" or "-x" for adding + or removing executable bit respectively) in diffstat. The + information is put between the filename part and the graph + part. Implies `--stat`. + --numstat:: Similar to `--stat`, but shows number of added and deleted lines in decimal notation and pathname without @@ -342,7 +350,7 @@ ifndef::git-format-patch[] Warn if changes introduce conflict markers or whitespace errors. What are considered whitespace errors is controlled by `core.whitespace` configuration. By default, trailing whitespaces (including - lines that solely consist of whitespaces) and a space character + lines that consist solely of whitespaces) and a space character that is immediately followed by a tab character inside the initial indent of the line are considered whitespace errors. Exits with non-zero status if problems are found. Not compatible @@ -356,7 +364,7 @@ ifndef::git-format-patch[] this option is not given, and the configuration variable `diff.wsErrorHighlight` is not set, only whitespace errors in `new` lines are highlighted. The whitespace errors are colored - whith `color.diff.whitespace`. + with `color.diff.whitespace`. endif::git-format-patch[] @@ -508,6 +516,15 @@ occurrences of that string did not change). See the 'pickaxe' entry in linkgit:gitdiffcore[7] for more information. +--find-object=<object-id>:: + Look for differences that change the number of occurrences of + the specified object. Similar to `-S`, just the argument is different + in that it doesn't search for a specific string but for a specific + object id. ++ +The object can be a blob or a submodule commit. It implies the `-t` option in +`git-log` to also find trees. + --pickaxe-all:: When `-S` or `-G` finds a change, show all the changes in that changeset, not just the files that contain the change @@ -516,6 +533,7 @@ information. --pickaxe-regex:: Treat the <string> given to `-S` as an extended POSIX regular expression to match. + endif::git-format-patch[] -O<orderfile>:: @@ -550,7 +568,7 @@ the normal order. -- + Patterns have the same syntax and semantics as patterns used for -fnmantch(3) without the FNM_PATHNAME flag, except a pathname also +fnmatch(3) without the FNM_PATHNAME flag, except a pathname also matches a pattern if removing any number of the final pathname components matches the pattern. For example, the pattern "`foo*bar`" matches "`fooasdfbar`" and "`foo/bar/baz/asdf`" but not "`foobarx`". @@ -574,7 +592,7 @@ endif::git-format-patch[] Treat all files as text. --ignore-cr-at-eol:: - Ignore carrige-return at the end of line when doing a comparison. + Ignore carriage-return at the end of line when doing a comparison. --ignore-space-at-eol:: Ignore changes in whitespace at EOL. diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index fb6bebbc61..97d3217df9 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -73,7 +73,22 @@ ifndef::git-pull[] 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. + subject to pruning. Supplying `--prune-tags` is a shorthand for + providing the tag refspec. ++ +See the PRUNING section below for more details. + +-P:: +--prune-tags:: + Before fetching, remove any local tags that no longer exist on + the remote if `--prune` is enabled. This option should be used + more carefully, unlike `--prune` it will remove any local + references (local tags) that have been created. This option is + a shorthand for providing the explicit tag refspec along with + `--prune`, see the discussion about that in its documentation. ++ +See the PRUNING section below for more details. + endif::git-pull[] ifndef::git-pull[] @@ -173,6 +188,14 @@ endif::git-pull[] is specified. This flag forces progress status even if the standard error stream is not directed to a terminal. +-o <option>:: +--server-option=<option>:: + Transmit the given string to the server when communicating using + protocol version 2. The given string must not contain a NUL or LF + character. + When multiple `--server-option=<option>` are given, they are all + sent to the other side in the order listed on the command line. + -4:: --ipv4:: Use IPv4 addresses only, ignoring IPv6 addresses. diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index d50fa339dc..45652fe4a6 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -193,7 +193,7 @@ for "git add --no-all <pathspec>...", i.e. ignored removed files. for command-line options). -Configuration +CONFIGURATION ------------- The optional configuration variable `core.excludesFile` indicates a path to a @@ -226,7 +226,7 @@ Because this example lets the shell expand the asterisk (i.e. you are listing the files explicitly), it does not consider `subdir/git-foo.sh`. -Interactive mode +INTERACTIVE MODE ---------------- When the command enters the interactive mode, it shows the output of the 'status' subcommand, and then goes into its diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt index 12879e4029..6f6c34b0f4 100644 --- a/Documentation/git-am.txt +++ b/Documentation/git-am.txt @@ -16,7 +16,7 @@ SYNOPSIS [--exclude=<path>] [--include=<path>] [--reject] [-q | --quiet] [--[no-]scissors] [-S[<keyid>]] [--patch-format=<format>] [(<mbox> | <Maildir>)...] -'git am' (--continue | --skip | --abort) +'git am' (--continue | --skip | --abort | --quit | --show-current-patch) DESCRIPTION ----------- @@ -167,6 +167,14 @@ default. You can use `--no-utf8` to override this. --abort:: Restore the original branch and abort the patching operation. +--quit:: + Abort the patching operation but keep HEAD and the index + untouched. + +--show-current-patch:: + Show the patch being applied when "git am" is stopped because + of conflicts. + DISCUSSION ---------- diff --git a/Documentation/git-annotate.txt b/Documentation/git-annotate.txt index 05fd482b74..e44a831339 100644 --- a/Documentation/git-annotate.txt +++ b/Documentation/git-annotate.txt @@ -8,7 +8,7 @@ git-annotate - Annotate file lines with commit information SYNOPSIS -------- [verse] -'git annotate' [options] file [revision] +'git annotate' [<options>] <file> [<revision>] DESCRIPTION ----------- diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt index 4ebc3d3271..b9aa39000f 100644 --- a/Documentation/git-apply.txt +++ b/Documentation/git-apply.txt @@ -9,7 +9,7 @@ git-apply - Apply a patch to files and/or to the index SYNOPSIS -------- [verse] -'git apply' [--stat] [--numstat] [--summary] [--check] [--index] [--3way] +'git apply' [--stat] [--numstat] [--summary] [--check] [--index | --intent-to-add] [--3way] [--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse] [--allow-binary-replacement | --binary] [--reject] [-z] [-p<n>] [-C<n>] [--inaccurate-eof] [--recount] [--cached] @@ -74,6 +74,14 @@ OPTIONS cached data, apply the patch, and store the result in the index without using the working tree. This implies `--index`. +--intent-to-add:: + When applying the patch only to the working tree, mark new + files to be added to the index later (see `--intent-to-add` + option in linkgit:git-add[1]). This option is ignored unless + running in a Git repository and `--index` is not specified. + Note that `--index` could be implied by other options such + as `--cached` or `--3way`. + -3:: --3way:: When the patch does not apply cleanly, fall back on 3-way merge if @@ -113,8 +121,10 @@ explained for the configuration variable `core.quotePath` (see linkgit:git-config[1]). -p<n>:: - Remove <n> leading slashes from traditional diff paths. The - default is 1. + Remove <n> leading path components (separated by slashes) from + traditional diff paths. E.g., with `-p2`, a patch against + `a/dir/file` will be applied directly to `file`. The default is + 1. -C<n>:: Ensure at least <n> lines of surrounding context match before @@ -240,7 +250,7 @@ When `git apply` is used as a "better GNU patch", the user can pass the `--unsafe-paths` option to override this safety check. This option has no effect when `--index` or `--cached` is in use. -Configuration +CONFIGURATION ------------- apply.ignoreWhitespace:: @@ -251,7 +261,7 @@ apply.whitespace:: When no `--whitespace` flag is given from the command line, this configuration item is used as the default. -Submodules +SUBMODULES ---------- If the patch contains any changes to submodules then 'git apply' treats these changes as follows. diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index 4a1417bdcd..4b45d837a7 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -165,8 +165,8 @@ To get a reminder of the currently used terms, use git bisect terms ------------------------------------------------ -You can get just the old (respectively new) term with `git bisect term ---term-old` or `git bisect term --term-good`. +You can get just the old (respectively new) term with `git bisect terms +--term-old` or `git bisect terms --term-good`. If you would like to use your own terms instead of "bad"/"good" or "new"/"old", you can choose any names you like (except existing bisect diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index b3084c99c1..02eccbb931 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -287,7 +287,7 @@ CONFIGURATION `--list` is used or implied. The default is to use a pager. See linkgit:git-config[1]. -Examples +EXAMPLES -------- Start development from a known tag:: @@ -318,7 +318,7 @@ See linkgit:git-fetch[1]. is currently checked out) does not have all commits from the test branch. -Notes +NOTES ----- If you are creating a branch that you want to checkout immediately, it is diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt index 3a8120c3b3..7d6c9dcd17 100644 --- a/Documentation/git-bundle.txt +++ b/Documentation/git-bundle.txt @@ -92,8 +92,8 @@ It is okay to err on the side of caution, causing the bundle file to contain objects already in the destination, as these are ignored when unpacking at the destination. -EXAMPLE -------- +EXAMPLES +-------- Assume you want to transfer the history from a repository R1 on machine A to another repository R2 on machine B. diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt index aa3b2bf2fc..3c0578217b 100644 --- a/Documentation/git-check-attr.txt +++ b/Documentation/git-check-attr.txt @@ -9,8 +9,8 @@ git-check-attr - Display gitattributes information SYNOPSIS -------- [verse] -'git check-attr' [-a | --all | attr...] [--] pathname... -'git check-attr' --stdin [-z] [-a | --all | attr...] +'git check-attr' [-a | --all | <attr>...] [--] <pathname>... +'git check-attr' --stdin [-z] [-a | --all | <attr>...] DESCRIPTION ----------- diff --git a/Documentation/git-check-ignore.txt b/Documentation/git-check-ignore.txt index 611754f10b..8b42cb3fb2 100644 --- a/Documentation/git-check-ignore.txt +++ b/Documentation/git-check-ignore.txt @@ -9,8 +9,8 @@ git-check-ignore - Debug gitignore / exclude files SYNOPSIS -------- [verse] -'git check-ignore' [options] pathname... -'git check-ignore' [options] --stdin +'git check-ignore' [<options>] <pathname>... +'git check-ignore' [<options>] --stdin DESCRIPTION ----------- diff --git a/Documentation/git-check-mailmap.txt b/Documentation/git-check-mailmap.txt index 39028ee1a3..aa2055dbeb 100644 --- a/Documentation/git-check-mailmap.txt +++ b/Documentation/git-check-mailmap.txt @@ -9,7 +9,7 @@ git-check-mailmap - Show canonical names and email addresses of contacts SYNOPSIS -------- [verse] -'git check-mailmap' [options] <contact>... +'git check-mailmap' [<options>] <contact>... DESCRIPTION diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index 42ca7b5095..a55536f0bf 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -260,7 +260,7 @@ or `--mirror` is given) <repository>:: The (possibly remote) repository to clone from. See the - <<URLS,URLS>> section below for more information on specifying + <<URLS,GIT URLS>> section below for more information on specifying repositories. <directory>:: @@ -273,7 +273,7 @@ or `--mirror` is given) :git-clone: 1 include::urls.txt[] -Examples +EXAMPLES -------- * Clone from upstream: diff --git a/Documentation/git-commit-graph.txt b/Documentation/git-commit-graph.txt new file mode 100644 index 0000000000..4c97b555cc --- /dev/null +++ b/Documentation/git-commit-graph.txt @@ -0,0 +1,94 @@ +git-commit-graph(1) +=================== + +NAME +---- +git-commit-graph - Write and verify Git commit graph files + + +SYNOPSIS +-------- +[verse] +'git commit-graph read' [--object-dir <dir>] +'git commit-graph write' <options> [--object-dir <dir>] + + +DESCRIPTION +----------- + +Manage the serialized commit graph file. + + +OPTIONS +------- +--object-dir:: + Use given directory for the location of packfiles and commit graph + file. This parameter exists to specify the location of an alternate + that only has the objects directory, not a full .git directory. The + commit graph file is expected to be at <dir>/info/commit-graph and + the packfiles are expected to be in <dir>/pack. + + +COMMANDS +-------- +'write':: + +Write a commit graph file based on the commits found in packfiles. ++ +With the `--stdin-packs` option, generate the new commit graph by +walking objects only in the specified pack-indexes. (Cannot be combined +with --stdin-commits.) ++ +With the `--stdin-commits` option, generate the new commit graph by +walking commits starting at the commits specified in stdin as a list +of OIDs in hex, one OID per line. (Cannot be combined with +--stdin-packs.) ++ +With the `--append` option, include all commits that are present in the +existing commit-graph file. + +'read':: + +Read a graph file given by the commit-graph file and output basic +details about the graph file. Used for debugging purposes. + + +EXAMPLES +-------- + +* Write a commit graph file for the packed commits in your local .git folder. ++ +------------------------------------------------ +$ git commit-graph write +------------------------------------------------ + +* Write a graph file, extending the current graph file using commits +* in <pack-index>. ++ +------------------------------------------------ +$ echo <pack-index> | git commit-graph write --stdin-packs +------------------------------------------------ + +* Write a graph file containing all reachable commits. ++ +------------------------------------------------ +$ git show-ref -s | git commit-graph write --stdin-commits +------------------------------------------------ + +* Write a graph file containing all commits in the current +* commit-graph file along with those reachable from HEAD. ++ +------------------------------------------------ +$ git rev-parse HEAD | git commit-graph write --stdin-commits --append +------------------------------------------------ + +* Read basic information from the commit-graph file. ++ +------------------------------------------------ +$ git commit-graph read +------------------------------------------------ + + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index 14da5fc157..18ddc78f42 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -9,13 +9,13 @@ git-config - Get and set repository or global options SYNOPSIS -------- [verse] -'git config' [<file-option>] [type] [--show-origin] [-z|--null] name [value [value_regex]] -'git config' [<file-option>] [type] --add name value -'git config' [<file-option>] [type] --replace-all name value [value_regex] -'git config' [<file-option>] [type] [--show-origin] [-z|--null] --get name [value_regex] -'git config' [<file-option>] [type] [--show-origin] [-z|--null] --get-all name [value_regex] -'git config' [<file-option>] [type] [--show-origin] [-z|--null] [--name-only] --get-regexp name_regex [value_regex] -'git config' [<file-option>] [type] [-z|--null] --get-urlmatch name URL +'git config' [<file-option>] [--type=<type>] [--show-origin] [-z|--null] name [value [value_regex]] +'git config' [<file-option>] [--type=<type>] --add name value +'git config' [<file-option>] [--type=<type>] --replace-all name value [value_regex] +'git config' [<file-option>] [--type=<type>] [--show-origin] [-z|--null] --get name [value_regex] +'git config' [<file-option>] [--type=<type>] [--show-origin] [-z|--null] --get-all name [value_regex] +'git config' [<file-option>] [--type=<type>] [--show-origin] [-z|--null] [--name-only] --get-regexp name_regex [value_regex] +'git config' [<file-option>] [--type=<type>] [-z|--null] --get-urlmatch name URL 'git config' [<file-option>] --unset name [value_regex] 'git config' [<file-option>] --unset-all name [value_regex] 'git config' [<file-option>] --rename-section old_name new_name @@ -38,12 +38,10 @@ existing values that match the regexp are updated or unset. If you want to handle the lines that do *not* match the regex, just prepend a single exclamation mark in front (see also <<EXAMPLES>>). -The type specifier can be either `--int` or `--bool`, to make -'git config' ensure that the variable(s) are of the given type and -convert the value to the canonical form (simple decimal number for int, -a "true" or "false" string for bool), or `--path`, which does some -path expansion (see `--path` below). If no type specifier is passed, no -checks or transformations are performed on the value. +The `--type=<type>` option instructs 'git config' to ensure that incoming and +outgoing values are canonicalize-able under the given <type>. If no +`--type=<type>` is given, no canonicalization will be performed. Callers may +unset an existing `--type` specifier with `--no-type`. When reading, the values are read from the system, global and repository local configuration files by default, and options @@ -160,30 +158,43 @@ See also <<FILES>>. --list:: List all variables set in config file, along with their values. ---bool:: - 'git config' will ensure that the output is "true" or "false" +--type <type>:: + 'git config' will ensure that any input or output is valid under the given + type constraint(s), and will canonicalize outgoing values in `<type>`'s + canonical form. ++ +Valid `<type>`'s include: ++ +- 'bool': canonicalize values as either "true" or "false". +- 'int': canonicalize values as simple decimal numbers. An optional suffix of + 'k', 'm', or 'g' will cause the value to be multiplied by 1024, 1048576, or + 1073741824 upon input. +- 'bool-or-int': canonicalize according to either 'bool' or 'int', as described + above. +- 'path': canonicalize by adding a leading `~` to the value of `$HOME` and + `~user` to the home directory for the specified user. This specifier has no + effect when setting the value (but you can use `git config section.variable + ~/` from the command line to let your shell do the expansion.) +- 'expiry-date': canonicalize by converting from a fixed or relative date-string + to a timestamp. This specifier has no effect when setting the value. +- 'color': When getting a value, canonicalize by converting to an ANSI color + escape sequence. When setting a value, a sanity-check is performed to ensure + that the given value is canonicalize-able as an ANSI color, but it is written + as-is. ++ +--bool:: --int:: - 'git config' will ensure that the output is a simple - decimal number. An optional value suffix of 'k', 'm', or 'g' - in the config file will cause the value to be multiplied - by 1024, 1048576, or 1073741824 prior to output. - --bool-or-int:: - 'git config' will ensure that the output matches the format of - either --bool or --int, as described above. - --path:: - `git config` will expand a leading `~` to the value of - `$HOME`, and `~user` to the home directory for the - specified user. This option has no effect when setting the - value (but you can use `git config section.variable ~/` - from the command line to let your shell do the expansion). - --expiry-date:: - `git config` will ensure that the output is converted from - a fixed or relative date-string to a timestamp. This option - has no effect when setting the value. + Historical options for selecting a type specifier. Prefer instead `--type`, + (see: above). + +--no-type:: + Un-sets the previously set type specifier (if one was previously set). This + option requests that 'git config' not canonicalize the retrieved variable. + `--no-type` has no effect without `--type=<type>` or `--<type>`. -z:: --null:: @@ -221,6 +232,8 @@ See also <<FILES>>. output it as the ANSI color escape sequence to the standard output. The optional `default` parameter is used instead, if there is no color configured for `name`. ++ +`--type=color [--default=<default>]` is preferred over `--get-color`. -e:: --edit:: @@ -233,6 +246,16 @@ See also <<FILES>>. using `--file`, `--global`, etc) and `on` when searching all config files. +--default <value>:: + When using `--get`, and the requested variable is not found, behave as if + <value> were the value assigned to the that variable. + +CONFIGURATION +------------- +`pager.config` is only respected when listing configuration, i.e., when +using `--list` or any of the `--get-*` which may return multiple results. +The default is to use a pager. + [[FILES]] FILES ----- diff --git a/Documentation/git-credential-cache.txt b/Documentation/git-credential-cache.txt index 2b85826393..0216c18ef8 100644 --- a/Documentation/git-credential-cache.txt +++ b/Documentation/git-credential-cache.txt @@ -8,7 +8,7 @@ git-credential-cache - Helper to temporarily store passwords in memory SYNOPSIS -------- ----------------------------- -git config credential.helper 'cache [options]' +git config credential.helper 'cache [<options>]' ----------------------------- DESCRIPTION diff --git a/Documentation/git-credential-store.txt b/Documentation/git-credential-store.txt index 25fb963f4b..693dd9d9d7 100644 --- a/Documentation/git-credential-store.txt +++ b/Documentation/git-credential-store.txt @@ -8,7 +8,7 @@ git-credential-store - Helper to store credentials on disk SYNOPSIS -------- ------------------- -git config credential.helper 'store [options]' +git config credential.helper 'store [<options>]' ------------------- DESCRIPTION diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt index ba90066f10..f98b7c6ed7 100644 --- a/Documentation/git-cvsserver.txt +++ b/Documentation/git-cvsserver.txt @@ -22,7 +22,7 @@ cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver Usage: [verse] -'git-cvsserver' [options] [pserver|server] [<directory> ...] +'git-cvsserver' [<options>] [pserver|server] [<directory> ...] OPTIONS ------- @@ -207,7 +207,7 @@ allowing access over SSH. ------ [[dbbackend]] -Database Backend +DATABASE BACKEND ---------------- 'git-cvsserver' uses one database per Git head (i.e. CVS module) to @@ -321,7 +321,7 @@ git-cvsserver, as described above. When these environment variables are set, the corresponding command-line arguments may not be used. -Eclipse CVS Client Notes +ECLIPSE CVS CLIENT NOTES ------------------------ To get a checkout with the Eclipse CVS client: @@ -346,7 +346,7 @@ offer. In that case CVS_SERVER is ignored, and you will have to replace the cvs utility on the server with 'git-cvsserver' or manipulate your `.bashrc` so that calling 'cvs' effectively calls 'git-cvsserver'. -Clients known to work +CLIENTS KNOWN TO WORK --------------------- - CVS 1.12.9 on Debian @@ -354,7 +354,7 @@ Clients known to work - Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes) - TortoiseCVS -Operations supported +OPERATIONS SUPPORTED -------------------- All the operations required for normal use are supported, including @@ -424,7 +424,7 @@ For best consistency with 'cvs', it is probably best to override the defaults by setting `gitcvs.usecrlfattr` to true, and `gitcvs.allBinary` to "guess". -Dependencies +DEPENDENCIES ------------ 'git-cvsserver' depends on DBD::SQLite. diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt index 3c91db7bed..56d54a4898 100644 --- a/Documentation/git-daemon.txt +++ b/Documentation/git-daemon.txt @@ -20,6 +20,7 @@ SYNOPSIS [--inetd | [--listen=<host_or_ipaddr>] [--port=<n>] [--user=<user> [--group=<group>]]] + [--log-destination=(stderr|syslog|none)] [<directory>...] DESCRIPTION @@ -80,7 +81,8 @@ OPTIONS do not have the 'git-daemon-export-ok' file. --inetd:: - Have the server run as an inetd service. Implies --syslog. + Have the server run as an inetd service. Implies --syslog (may be + overridden with `--log-destination=`). Incompatible with --detach, --port, --listen, --user and --group options. @@ -110,8 +112,28 @@ OPTIONS zero for no limit. --syslog:: - Log to syslog instead of stderr. Note that this option does not imply - --verbose, thus by default only error conditions will be logged. + Short for `--log-destination=syslog`. + +--log-destination=<destination>:: + Send log messages to the specified destination. + Note that this option does not imply --verbose, + thus by default only error conditions will be logged. + The <destination> must be one of: ++ +-- +stderr:: + Write to standard error. + Note that if `--detach` is specified, + the process disconnects from the real standard error, + making this destination effectively equivalent to `none`. +syslog:: + Write to syslog, using the `git-daemon` identifier. +none:: + Disable all logging. +-- ++ +The default destination is `syslog` if `--inetd` or `--detach` is specified, +otherwise `stderr`. --user-path:: --user-path=<path>:: diff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt index b380677718..f4bd8155c0 100644 --- a/Documentation/git-diff-index.txt +++ b/Documentation/git-diff-index.txt @@ -37,14 +37,14 @@ include::diff-options.txt[] include::diff-format.txt[] -Operating Modes +OPERATING MODES --------------- You can choose whether you want to trust the index file entirely (using the `--cached` flag) or ask the diff logic to show any files that don't match the stat state as being "tentatively changed". Both of these operations are very useful indeed. -Cached Mode +CACHED MODE ----------- If `--cached` is specified, it allows you to ask: @@ -77,7 +77,7 @@ So doing a `git diff-index --cached` is basically very useful when you are asking yourself "what have I already marked for being committed, and what's the difference to a previous tree". -Non-cached Mode +NON-CACHED MODE --------------- The "non-cached" mode takes a different approach, and is potentially the more useful of the two in that what it does can't be emulated with diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt index 7870e175b7..2319b2b192 100644 --- a/Documentation/git-diff-tree.txt +++ b/Documentation/git-diff-tree.txt @@ -116,7 +116,7 @@ include::pretty-options.txt[] include::pretty-formats.txt[] -Limiting Output +LIMITING OUTPUT --------------- If you're only interested in differences in a subset of files, for example some architecture-specific files, you might do: diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index b0c1bb95c8..b180f1fa5b 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git-diff.txt @@ -9,11 +9,11 @@ git-diff - Show changes between commits, commit and working tree, etc SYNOPSIS -------- [verse] -'git diff' [options] [<commit>] [--] [<path>...] -'git diff' [options] --cached [<commit>] [--] [<path>...] -'git diff' [options] <commit> <commit> [--] [<path>...] -'git diff' [options] <blob> <blob> -'git diff' [options] [--no-index] [--] <path> <path> +'git diff' [<options>] [<commit>] [--] [<path>...] +'git diff' [<options>] --cached [<commit>] [--] [<path>...] +'git diff' [<options>] <commit> <commit> [--] [<path>...] +'git diff' [<options>] <blob> <blob> +'git diff' [<options>] --no-index [--] <path> <path> DESCRIPTION ----------- @@ -21,7 +21,7 @@ Show changes between the working tree and the index or a tree, changes between the index and a tree, changes between two trees, changes between two blob objects, or changes between two files on disk. -'git diff' [--options] [--] [<path>...]:: +'git diff' [<options>] [--] [<path>...]:: This form is to view the changes you made relative to the index (staging area for the next commit). In other @@ -29,7 +29,7 @@ two blob objects, or changes between two files on disk. further add to the index but you still haven't. You can stage these changes by using linkgit:git-add[1]. -'git diff' --no-index [--options] [--] [<path>...]:: +'git diff' [<options>] --no-index [--] <path> <path>:: This form is to compare the given two paths on the filesystem. You can omit the `--no-index` option when @@ -38,7 +38,7 @@ two blob objects, or changes between two files on disk. or when running the command outside a working tree controlled by Git. -'git diff' [--options] --cached [<commit>] [--] [<path>...]:: +'git diff' [<options>] --cached [<commit>] [--] [<path>...]:: This form is to view the changes you staged for the next commit relative to the named <commit>. Typically you @@ -48,7 +48,7 @@ two blob objects, or changes between two files on disk. <commit> is not given, it shows all staged changes. --staged is a synonym of --cached. -'git diff' [--options] <commit> [--] [<path>...]:: +'git diff' [<options>] <commit> [--] [<path>...]:: This form is to view the changes you have in your working tree relative to the named <commit>. You can @@ -56,18 +56,18 @@ two blob objects, or changes between two files on disk. branch name to compare with the tip of a different branch. -'git diff' [--options] <commit> <commit> [--] [<path>...]:: +'git diff' [<options>] <commit> <commit> [--] [<path>...]:: This is to view the changes between two arbitrary <commit>. -'git diff' [--options] <commit>..<commit> [--] [<path>...]:: +'git diff' [<options>] <commit>..<commit> [--] [<path>...]:: This is synonymous to the previous form. If <commit> on one side is omitted, it will have the same effect as using HEAD instead. -'git diff' [--options] <commit>\...<commit> [--] [<path>...]:: +'git diff' [<options>] <commit>\...<commit> [--] [<path>...]:: This form is to view the changes on the branch containing and up to the second <commit>, starting at a common ancestor @@ -87,7 +87,7 @@ and the range notations ("<commit>..<commit>" and "<commit>\...<commit>") do not mean a range as defined in the "SPECIFYING RANGES" section in linkgit:gitrevisions[7]. -'git diff' [options] <blob> <blob>:: +'git diff' [<options>] <blob> <blob>:: This form is to view the differences between the raw contents of two blob objects. diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt index ed57c684db..ce954be532 100644 --- a/Documentation/git-fast-export.txt +++ b/Documentation/git-fast-export.txt @@ -9,7 +9,7 @@ git-fast-export - Git data exporter SYNOPSIS -------- [verse] -'git fast-export [options]' | 'git fast-import' +'git fast-export [<options>]' | 'git fast-import' DESCRIPTION ----------- @@ -202,7 +202,7 @@ smaller output, and it is usually easy to quickly confirm that there is no private data in the stream. -Limitations +LIMITATIONS ----------- Since 'git fast-import' cannot tag trees, you will not be diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 3d3d219e58..e81117d27f 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -9,7 +9,7 @@ git-fast-import - Backend for fast Git data importers SYNOPSIS -------- [verse] -frontend | 'git fast-import' [options] +frontend | 'git fast-import' [<options>] DESCRIPTION ----------- @@ -139,7 +139,7 @@ Performance and Compression Tuning fastimport.unpackLimit:: See linkgit:git-config[1] -Performance +PERFORMANCE ----------- The design of fast-import allows it to import large projects in a minimum amount of memory usage and processing time. Assuming the frontend @@ -155,7 +155,7 @@ faster if the source data is stored on a different drive than the destination Git repository (due to less IO contention). -Development Cost +DEVELOPMENT COST ---------------- A typical frontend for fast-import tends to weigh in at approximately 200 lines of Perl/Python/Ruby code. Most developers have been able to @@ -165,7 +165,7 @@ an ideal situation, given that most conversion tools are throw-away (use once, and never look back). -Parallel Operation +PARALLEL OPERATION ------------------ Like 'git push' or 'git fetch', imports handled by fast-import are safe to run alongside parallel `git repack -a -d` or `git gc` invocations, @@ -186,7 +186,7 @@ this only be used on an otherwise quiet repository. Using --force is not necessary for an initial import into an empty repository. -Technical Discussion +TECHNICAL DISCUSSION -------------------- fast-import tracks a set of branches in memory. Any branch can be created or modified at any point during the import process by sending a @@ -204,7 +204,7 @@ directory also allows fast-import to run very quickly, as it does not need to perform any costly file update operations when switching between branches. -Input Format +INPUT FORMAT ------------ With the exception of raw file data (which Git does not interpret) the fast-import input format is text (ASCII) based. This text based @@ -1131,7 +1131,7 @@ If the `--done` command-line option or `feature done` command is in use, the `done` command is mandatory and marks the end of the stream. -Responses To Commands +RESPONSES TO COMMANDS --------------------- New objects written by fast-import are not available immediately. Most fast-import commands have no visible effect until the next @@ -1160,7 +1160,7 @@ To avoid deadlock, such frontends must completely consume any pending output from `progress`, `ls`, `get-mark`, and `cat-blob` before performing writes to fast-import that might block. -Crash Reports +CRASH REPORTS ------------- If fast-import is supplied invalid input it will terminate with a non-zero exit status and create a crash report in the top level of @@ -1247,7 +1247,7 @@ An example crash: END OF CRASH REPORT ==== -Tips and Tricks +TIPS AND TRICKS --------------- The following tips and tricks have been collected from various users of fast-import, and are offered here as suggestions. @@ -1349,7 +1349,7 @@ Your users will feel better knowing how much of the data stream has been processed. -Packfile Optimization +PACKFILE OPTIMIZATION --------------------- When packing a blob fast-import always attempts to deltify against the last blob written. Unless specifically arranged for by the frontend, @@ -1380,7 +1380,7 @@ to force recomputation of all deltas can significantly reduce the final packfile size (30-50% smaller can be quite typical). -Memory Utilization +MEMORY UTILIZATION ------------------ There are a number of factors which affect how much memory fast-import requires to perform an import. Like critical sections of core @@ -1458,7 +1458,7 @@ and lazy loading of subtrees, allows fast-import to efficiently import projects with 2,000+ branches and 45,114+ files in a very limited memory footprint (less than 2.7 MiB per active branch). -Signals +SIGNALS ------- Sending *SIGUSR1* to the 'git fast-import' process ends the current packfile early, simulating a `checkpoint` command. The impatient diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt index f7ebe36a7b..c975884793 100644 --- a/Documentation/git-fetch-pack.txt +++ b/Documentation/git-fetch-pack.txt @@ -88,7 +88,7 @@ be in a separate packet, and the list must end with a flush packet. infinite even if there is an ancestor-chain that long. --shallow-since=<date>:: - Deepen or shorten the history of a shallow'repository to + Deepen or shorten the history of a shallow repository to include all reachable commits after <date>. --shallow-exclude=<revision>:: diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt index b153aefa68..e319935597 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -99,6 +99,93 @@ The latter use of the `remote.<repository>.fetch` values can be overridden by giving the `--refmap=<refspec>` parameter(s) on the command line. +PRUNING +------- + +Git has a default disposition of keeping data unless it's explicitly +thrown away; this extends to holding onto local references to branches +on remotes that have themselves deleted those branches. + +If left to accumulate, these stale references might make performance +worse on big and busy repos that have a lot of branch churn, and +e.g. make the output of commands like `git branch -a --contains +<commit>` needlessly verbose, as well as impacting anything else +that'll work with the complete set of known references. + +These remote-tracking references can be deleted as a one-off with +either of: + +------------------------------------------------ +# While fetching +$ git fetch --prune <name> + +# Only prune, don't fetch +$ git remote prune <name> +------------------------------------------------ + +To prune references as part of your normal workflow without needing to +remember to run that, set `fetch.prune` globally, or +`remote.<name>.prune` per-remote in the config. See +linkgit:git-config[1]. + +Here's where things get tricky and more specific. The pruning feature +doesn't actually care about branches, instead it'll prune local <-> +remote-references as a function of the refspec of the remote (see +`<refspec>` and <<CRTB,CONFIGURED REMOTE-TRACKING BRANCHES>> above). + +Therefore if the refspec for the remote includes +e.g. `refs/tags/*:refs/tags/*`, or you manually run e.g. `git fetch +--prune <name> "refs/tags/*:refs/tags/*"` it won't be stale remote +tracking branches that are deleted, but any local tag that doesn't +exist on the remote. + +This might not be what you expect, i.e. you want to prune remote +`<name>`, but also explicitly fetch tags from it, so when you fetch +from it you delete all your local tags, most of which may not have +come from the `<name>` remote in the first place. + +So be careful when using this with a refspec like +`refs/tags/*:refs/tags/*`, or any other refspec which might map +references from multiple remotes to the same local namespace. + +Since keeping up-to-date with both branches and tags on the remote is +a common use-case the `--prune-tags` option can be supplied along with +`--prune` to prune local tags that don't exist on the remote, and +force-update those tags that differ. Tag pruning can also be enabled +with `fetch.pruneTags` or `remote.<name>.pruneTags` in the config. See +linkgit:git-config[1]. + +The `--prune-tags` option is equivalent to having +`refs/tags/*:refs/tags/*` declared in the refspecs of the remote. This +can lead to some seemingly strange interactions: + +------------------------------------------------ +# These both fetch tags +$ git fetch --no-tags origin 'refs/tags/*:refs/tags/*' +$ git fetch --no-tags --prune-tags origin +------------------------------------------------ + +The reason it doesn't error out when provided without `--prune` or its +config versions is for flexibility of the configured versions, and to +maintain a 1=1 mapping between what the command line flags do, and +what the configuration versions do. + +It's reasonable to e.g. configure `fetch.pruneTags=true` in +`~/.gitconfig` to have tags pruned whenever `git fetch --prune` is +run, without making every invocation of `git fetch` without `--prune` +an error. + +Pruning tags with `--prune-tags` also works when fetching a URL +instead of a named remote. These will all prune tags not found on +origin: + +------------------------------------------------ +$ git fetch origin --prune --prune-tags +$ git fetch origin --prune 'refs/tags/*:refs/tags/*' +$ git fetch <url of origin> --prune --prune-tags +$ git fetch <url of origin> --prune 'refs/tags/*:refs/tags/*' +------------------------------------------------ + OUTPUT ------ diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index 3a52e4dce3..e6f08ab189 100644 --- a/Documentation/git-filter-branch.txt +++ b/Documentation/git-filter-branch.txt @@ -222,7 +222,15 @@ this purpose, they are instead rewritten to point at the nearest ancestor that was not excluded. -Examples +EXIT STATUS +----------- + +On success, the exit status is `0`. If the filter can't find any commits to +rewrite, the exit status is `2`. On any other error, the exit status may be +any other non-zero value. + + +EXAMPLES -------- Suppose you want to remove a file (containing confidential information @@ -280,7 +288,7 @@ git filter-branch --parent-filter \ or even simpler: ----------------------------------------------- -echo "$commit-id $graft-id" >> .git/info/grafts +git replace --graft $commit-id $graft-id git filter-branch $graft-id..HEAD ----------------------------------------------- @@ -398,7 +406,7 @@ git filter-branch --index-filter \ -Checklist for Shrinking a Repository +CHECKLIST FOR SHRINKING A REPOSITORY ------------------------------------ git-filter-branch can be used to get rid of a subset of files, @@ -437,7 +445,7 @@ warned. (or if your git-gc is not new enough to support arguments to `--prune`, use `git repack -ad; git prune` instead). -Notes +NOTES ----- git-filter-branch allows you to make complex shell-scripted rewrites diff --git a/Documentation/git-fmt-merge-msg.txt b/Documentation/git-fmt-merge-msg.txt index 44892c447e..423b6e033b 100644 --- a/Documentation/git-fmt-merge-msg.txt +++ b/Documentation/git-fmt-merge-msg.txt @@ -57,8 +57,8 @@ merge.summary:: Synonym to `merge.log`; this is deprecated and will be removed in the future. -EXAMPLE -------- +EXAMPLES +-------- --------- $ git fetch origin master diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index dffa14a795..085d177d97 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -121,7 +121,7 @@ refname:: stripping with positive <N>, or it becomes the full refname if stripping with negative <N>. Neither is an error. + -`strip` can be used as a synomym to `lstrip`. +`strip` can be used as a synonym to `lstrip`. objecttype:: The type of the object (`blob`, `tree`, `commit`, `tag`). diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 6cbe462a77..b41e1329a7 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -47,7 +47,7 @@ There are two ways to specify which commits to operate on. The first rule takes precedence in the case of a single <commit>. To apply the second rule, i.e., format everything since the beginning of -history up until <commit>, use the '\--root' option: `git format-patch +history up until <commit>, use the `--root` option: `git format-patch --root <commit>`. If you want to format only <commit> itself, you can do this with `git format-patch -1 <commit>`. diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt index 571b5a7e3c..24b2dd44fe 100644 --- a/Documentation/git-gc.txt +++ b/Documentation/git-gc.txt @@ -9,14 +9,15 @@ git-gc - Cleanup unnecessary files and optimize the local repository SYNOPSIS -------- [verse] -'git gc' [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune] [--force] +'git gc' [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack] DESCRIPTION ----------- Runs a number of housekeeping tasks within the current repository, such as compressing file revisions (to reduce disk space and increase -performance) and removing unreachable objects which may have been -created from prior invocations of 'git add'. +performance), removing unreachable objects which may have been +created from prior invocations of 'git add', packing refs, pruning +reflog, rerere metadata or stale working trees. Users are encouraged to run this task on a regular basis within each repository to maintain good disk space utilization and good @@ -45,20 +46,31 @@ OPTIONS With this option, 'git gc' checks whether any housekeeping is required; if not, it exits without performing any work. Some git commands run `git gc --auto` after performing - operations that could create many loose objects. + operations that could create many loose objects. Housekeeping + is required if there are too many loose objects or too many + packs in the repository. + -Housekeeping is required if there are too many loose objects or -too many packs in the repository. If the number of loose objects -exceeds the value of the `gc.auto` configuration variable, then -all loose objects are combined into a single pack using -`git repack -d -l`. Setting the value of `gc.auto` to 0 -disables automatic packing of loose objects. +If the number of loose objects exceeds the value of the `gc.auto` +configuration variable, then all loose objects are combined into a +single pack using `git repack -d -l`. Setting the value of `gc.auto` +to 0 disables automatic packing of loose objects. + If the number of packs exceeds the value of `gc.autoPackLimit`, -then existing packs (except those marked with a `.keep` file) +then existing packs (except those marked with a `.keep` file +or over `gc.bigPackThreshold` limit) are consolidated into a single pack by using the `-A` option of -'git repack'. Setting `gc.autoPackLimit` to 0 disables -automatic consolidation of packs. +'git repack'. +If the amount of memory is estimated not enough for `git repack` to +run smoothly and `gc.bigPackThreshold` is not set, the largest +pack will also be excluded (this is the equivalent of running `git gc` +with `--keep-base-pack`). +Setting `gc.autoPackLimit` to 0 disables automatic consolidation of +packs. ++ +If houskeeping is required due to many loose objects or packs, all +other housekeeping tasks (e.g. rerere, working trees, reflog...) will +be performed as well. + --prune=<date>:: Prune loose objects older than date (default is 2 weeks ago, @@ -78,7 +90,12 @@ automatic consolidation of packs. Force `git gc` to run even if there may be another `git gc` instance running on this repository. -Configuration +--keep-largest-pack:: + All packs except the largest pack and those marked with a + `.keep` files are consolidated into a single pack. When this + option is used, `gc.bigPackThreshold` is ignored. + +CONFIGURATION ------------- The optional configuration variable `gc.reflogExpire` can be @@ -123,7 +140,7 @@ The optional configuration variable `gc.aggressiveWindow` controls how much time is spent optimizing the delta compression of the objects in the repository when the --aggressive option is specified. The larger the value, the more time is spent optimizing the delta compression. See -the documentation for the --window' option in linkgit:git-repack[1] for +the documentation for the --window option in linkgit:git-repack[1] for more details. This defaults to 250. Similarly, the optional configuration variable `gc.aggressiveDepth` @@ -133,8 +150,12 @@ The optional configuration variable `gc.pruneExpire` controls how old the unreferenced loose objects have to be before they are pruned. The default is "2 weeks ago". +Optional configuration variable `gc.worktreePruneExpire` controls how +old a stale working tree should be before `git worktree prune` deletes +it. Default is "3 months ago". + -Notes +NOTES ----- 'git gc' tries very hard not to delete objects that are referenced diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt index 18b494731f..312409a607 100644 --- a/Documentation/git-grep.txt +++ b/Documentation/git-grep.txt @@ -293,7 +293,7 @@ providing this option will cause it to die. For more details about the <pathspec> syntax, see the 'pathspec' entry in linkgit:gitglossary[7]. -Examples +EXAMPLES -------- `git grep 'time_t' -- '*.[ch]'`:: diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt index 40d328a4b3..83d25d825a 100644 --- a/Documentation/git-help.txt +++ b/Documentation/git-help.txt @@ -8,7 +8,7 @@ git-help - Display help information about Git SYNOPSIS -------- [verse] -'git help' [-a|--all] [-g|--guide] +'git help' [-a|--all [--verbose]] [-g|--guide] [-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE] DESCRIPTION @@ -42,6 +42,13 @@ OPTIONS --all:: Prints all the available commands on the standard output. This option overrides any given command or guide name. + When used with `--verbose` print description for all recognized + commands. + +-c:: +--config:: + List all available configuration variables. This is a short + summary of the list in linkgit:git-config[1]. -g:: --guides:: diff --git a/Documentation/git-http-fetch.txt b/Documentation/git-http-fetch.txt index 21a33d2c41..666b042679 100644 --- a/Documentation/git-http-fetch.txt +++ b/Documentation/git-http-fetch.txt @@ -15,8 +15,9 @@ DESCRIPTION ----------- Downloads a remote Git repository via HTTP. -*NOTE*: use of this command without -a is deprecated. The -a -behaviour will become the default in a future release. +This command always gets all objects. Historically, there were three options +`-a`, `-c` and `-t` for choosing which objects to download. They are now +silently ignored. OPTIONS ------- @@ -24,12 +25,8 @@ commit-id:: Either the hash or the filename under [URL]/refs/ to pull. --c:: - Get the commit objects. --t:: - Get trees associated with the commit objects. --a:: - Get all the objects. +-a, -c, -t:: + These options are ignored for historical reasons. -v:: Report what is downloaded. diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt index 2aceb6f26d..ea03a4eeb0 100644 --- a/Documentation/git-http-push.txt +++ b/Documentation/git-http-push.txt @@ -55,7 +55,7 @@ OPTIONS The remote refs to update. -Specifying the Refs +SPECIFYING THE REFS ------------------- A '<ref>' specification can be either a single pattern, or a pair diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt index 5d1e4c80cd..032613c420 100644 --- a/Documentation/git-imap-send.txt +++ b/Documentation/git-imap-send.txt @@ -136,8 +136,8 @@ Using direct mode with SSL: ......................... -EXAMPLE -------- +EXAMPLES +-------- To submit patches using GMail's IMAP interface, first, edit your ~/.gitconfig to specify your account settings: diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt index 1b4b65d665..d5b7560bfe 100644 --- a/Documentation/git-index-pack.txt +++ b/Documentation/git-index-pack.txt @@ -77,6 +77,9 @@ OPTIONS --check-self-contained-and-connected:: Die if the pack contains broken links. For internal use only. +--fsck-objects:: + Die if the pack contains broken objects. For internal use only. + --threads=<n>:: Specifies the number of threads to spawn when resolving deltas. This requires that index-pack be compiled with @@ -90,8 +93,8 @@ OPTIONS --max-input-size=<size>:: Die, if the pack is larger than <size>. -Note ----- +NOTES +----- Once the index has been created, the list of object names is sorted and the SHA-1 hash of that list is printed to stdout. If --stdin was diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt index ff446f15f7..9111c47a1b 100644 --- a/Documentation/git-interpret-trailers.txt +++ b/Documentation/git-interpret-trailers.txt @@ -8,8 +8,8 @@ git-interpret-trailers - add or parse structured information in commit messages SYNOPSIS -------- [verse] -'git interpret-trailers' [options] [(--trailer <token>[(=|:)<value>])...] [<file>...] -'git interpret-trailers' [options] [--parse] [<file>...] +'git interpret-trailers' [<options>] [(--trailer <token>[(=|:)<value>])...] [<file>...] +'git interpret-trailers' [<options>] [--parse] [<file>...] DESCRIPTION ----------- diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 5437f8b0f0..90761f1694 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -9,7 +9,7 @@ git-log - Show commit logs SYNOPSIS -------- [verse] -'git log' [<options>] [<revision range>] [[\--] <path>...] +'git log' [<options>] [<revision range>] [[--] <path>...] DESCRIPTION ----------- @@ -90,13 +90,13 @@ include::line-range-format.txt[] ways to spell <revision range>, see the 'Specifying Ranges' section of linkgit:gitrevisions[7]. -[\--] <path>...:: +[--] <path>...:: Show only commits that are enough to explain how the files that match the specified paths came to be. See 'History Simplification' below for details and other simplification modes. + -Paths may need to be prefixed with ``\-- '' to separate them from +Paths may need to be prefixed with `--` to separate them from options or the revision range, when confusion arises. include::rev-list-options.txt[] @@ -125,7 +125,7 @@ EXAMPLES `git log --since="2 weeks ago" -- gitk`:: Show the changes during the last two weeks to the file 'gitk'. - The ``--'' is necessary to avoid confusion with the *branch* named + The `--` is necessary to avoid confusion with the *branch* named 'gitk' `git log --name-status release..test`:: diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt index 3ac3e3a77d..5298f1bc30 100644 --- a/Documentation/git-ls-files.txt +++ b/Documentation/git-ls-files.txt @@ -53,7 +53,8 @@ OPTIONS Show only ignored files in the output. When showing files in the index, print only those matched by an exclude pattern. When showing "other" files, show only those matched by an exclude - pattern. + pattern. Standard ignore rules are not automatically activated, + therefore at least one of the `--exclude*` options is required. -s:: --stage:: @@ -183,7 +184,7 @@ followed by the ("attr/<eolattr>"). Files to show. If no files are given all files which match the other specified criteria are shown. -Output +OUTPUT ------ 'git ls-files' just outputs the filenames unless `--stage` is specified in which case it outputs: @@ -208,7 +209,7 @@ quoted as explained for the configuration variable `core.quotePath` verbatim and the line is terminated by a NUL byte. -Exclude Patterns +EXCLUDE PATTERNS ---------------- 'git ls-files' can use a list of "exclude patterns" when diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index 5f2628c8f8..b9fd3770a6 100644 --- a/Documentation/git-ls-remote.txt +++ b/Documentation/git-ls-remote.txt @@ -10,7 +10,7 @@ SYNOPSIS -------- [verse] 'git ls-remote' [--heads] [--tags] [--refs] [--upload-pack=<exec>] - [-q | --quiet] [--exit-code] [--get-url] + [-q | --quiet] [--exit-code] [--get-url] [--sort=<key>] [--symref] [<repository> [<refs>...]] DESCRIPTION @@ -60,6 +60,24 @@ OPTIONS upload-pack only shows the symref HEAD, so it will be the only one shown by ls-remote. +--sort=<key>:: + Sort based on the key given. Prefix `-` to sort in descending order + of the value. Supports "version:refname" or "v:refname" (tag names + are treated as versions). The "version:refname" sort order can also + be affected by the "versionsort.suffix" configuration variable. + See linkgit:git-for-each-ref[1] for more sort options, but be aware + keys like `committerdate` that require access to the objects + themselves will not work for refs whose objects have not yet been + fetched from the remote, and will give a `missing object` error. + +-o <option>:: +--server-option=<option>:: + Transmit the given string to the server when communicating using + protocol version 2. The given string must not contain a NUL or LF + character. + When multiple `--server-option=<option>` are given, they are all + sent to the other side in the order listed on the command line. + <repository>:: The "remote" repository to query. This parameter can be either a URL or the name of a remote (see the GIT URLS and @@ -90,6 +108,10 @@ EXAMPLES c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3 +SEE ALSO +-------- +linkgit:git-check-ref-format[1]. + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index d5dfd8430f..6a5c00e2c2 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -57,7 +57,7 @@ reconstruct the original (pre-merge) changes. Therefore: discouraged: while possible, it may leave you in a state that is hard to back out of in the case of a conflict. -The fourth syntax ("`git merge --continue`") can only be run after the +The third syntax ("`git merge --continue`") can only be run after the merge has resulted in conflicts. OPTIONS diff --git a/Documentation/git-mktree.txt b/Documentation/git-mktree.txt index c3616e7711..27fe2b32e1 100644 --- a/Documentation/git-mktree.txt +++ b/Documentation/git-mktree.txt @@ -14,7 +14,7 @@ SYNOPSIS DESCRIPTION ----------- Reads standard input in non-recursive `ls-tree` output format, and creates -a tree object. The order of the tree entries is normalised by mktree so +a tree object. The order of the tree entries is normalized by mktree so pre-sorting the input is not required. The object name of the tree object built is written to the standard output. diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt index e8e68f528c..5cb0eb0855 100644 --- a/Documentation/git-name-rev.txt +++ b/Documentation/git-name-rev.txt @@ -61,8 +61,8 @@ OPTIONS --always:: Show uniquely abbreviated commit object as fallback. -EXAMPLE -------- +EXAMPLES +-------- Given a commit, find out where it is relative to the local refs. Say somebody wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a. diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt index d8c8f11c9f..f0de3b891b 100644 --- a/Documentation/git-p4.txt +++ b/Documentation/git-p4.txt @@ -29,8 +29,8 @@ Submit Git changes back to p4 using 'git p4 submit'. The command the updated p4 remote branch. -EXAMPLE -------- +EXAMPLES +-------- * Clone a repository: + ------------ @@ -149,6 +149,12 @@ To specify a branch other than the current one, use: $ git p4 submit topicbranch ------------ +To specify a single commit or a range of commits, use: +------------ +$ git p4 submit --commit <sha1> +$ git p4 submit --commit <sha1..sha1> +------------ + The upstream reference is generally 'refs/remotes/p4/master', but can be overridden using the `--origin=` command-line option. @@ -164,6 +170,31 @@ $ git p4 submit --shelve $ git p4 submit --update-shelve 1234 --update-shelve 2345 ---- + +Unshelve +~~~~~~~~ +Unshelving will take a shelved P4 changelist, and produce the equivalent git commit +in the branch refs/remotes/p4/unshelved/<changelist>. + +The git commit is created relative to the current origin revision (HEAD by default). +If the shelved changelist's parent revisions differ, git-p4 will refuse to unshelve; +you need to be unshelving onto an equivalent tree. + +The origin revision can be changed with the "--origin" option. + +If the target branch in refs/remotes/p4/unshelved already exists, the old one will +be renamed. + +---- +$ git p4 sync +$ git p4 unshelve 12345 +$ git show refs/remotes/p4/unshelved/12345 +<submit more changes via p4 to the same files> +$ git p4 unshelve 12345 +<refuses to unshelve until git is in sync with p4 again> + +---- + OPTIONS ------- @@ -330,6 +361,19 @@ These options can be used to modify 'git p4 submit' behavior. p4/master. See the "Sync options" section above for more information. +--commit <sha1>|<sha1..sha1>:: + Submit only the specified commit or range of commits, instead of the full + list of changes that are in the current Git branch. + +--disable-rebase:: + Disable the automatic rebase after all commits have been successfully + submitted. Can also be set with git-p4.disableRebase. + +--disable-p4sync:: + Disable the automatic sync of p4/master from Perforce after commits have + been submitted. Implies --disable-rebase. Can also be set with + git-p4.disableP4Sync. Sync with origin/master still goes ahead if possible. + Rebase options ~~~~~~~~~~~~~~ These options can be used to modify 'git p4 rebase' behavior. @@ -337,6 +381,13 @@ These options can be used to modify 'git p4 rebase' behavior. --import-labels:: Import p4 labels. +Unshelve options +~~~~~~~~~~~~~~~~ + +--origin:: + Sets the git refspec against which the shelved P4 changelist is compared. + Defaults to p4/master. + DEPOT PATH SYNTAX ----------------- The p4 depot path argument to 'git p4 sync' and 'git p4 clone' can @@ -392,7 +443,7 @@ dedicating a client spec just for 'git p4'. The name of the client can be given to 'git p4' in multiple ways. The variable 'git-p4.client' takes precedence if it exists. Otherwise, normal p4 mechanisms of determining the client are used: environment -variable P4CLIENT, a file referenced by P4CONFIG, or the local host name. +variable `P4CLIENT`, a file referenced by `P4CONFIG`, or the local host name. BRANCH DETECTION @@ -461,22 +512,22 @@ General variables ~~~~~~~~~~~~~~~~~ git-p4.user:: User specified as an option to all p4 commands, with '-u <user>'. - The environment variable 'P4USER' can be used instead. + The environment variable `P4USER` can be used instead. git-p4.password:: Password specified as an option to all p4 commands, with '-P <password>'. - The environment variable 'P4PASS' can be used instead. + The environment variable `P4PASS` can be used instead. git-p4.port:: Port specified as an option to all p4 commands, with '-p <port>'. - The environment variable 'P4PORT' can be used instead. + The environment variable `P4PORT` can be used instead. git-p4.host:: Host specified as an option to all p4 commands, with '-h <host>'. - The environment variable 'P4HOST' can be used instead. + The environment variable `P4HOST` can be used instead. git-p4.client:: Client specified as an option to all p4 commands, with @@ -644,6 +695,12 @@ git-p4.conflict:: Specify submit behavior when a conflict with p4 is found, as per --conflict. The default behavior is 'ask'. +git-p4.disableRebase:: + Do not rebase the tree against p4/master following a submit. + +git-p4.disableP4Sync:: + Do not sync p4/master with Perforce following a submit. Implies git-p4.disableRebase. + IMPLEMENTATION DETAILS ---------------------- * Changesets from p4 are imported using Git fast-import. diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt index aa403d02f3..d95b472d16 100644 --- a/Documentation/git-pack-objects.txt +++ b/Documentation/git-pack-objects.txt @@ -12,7 +12,7 @@ SYNOPSIS 'git pack-objects' [-q | --progress | --all-progress] [--all-progress-implied] [--no-reuse-delta] [--delta-base-offset] [--non-empty] [--local] [--incremental] [--window=<n>] [--depth=<n>] - [--revs [--unpacked | --all]] + [--revs [--unpacked | --all]] [--keep-pack=<pack-name>] [--stdout [--filter=<filter-spec>] | base-name] [--shallow] [--keep-true-parents] < object-list @@ -96,7 +96,9 @@ base-name:: it too deep affects the performance on the unpacker side, because delta data needs to be applied that many times to get to the necessary object. - The default value for --window is 10 and --depth is 50. ++ +The default value for --window is 10 and --depth is 50. The maximum +depth is 4095. --window-memory=<n>:: This option provides an additional limit on top of `--window`; @@ -126,6 +128,13 @@ base-name:: has a .keep file to be ignored, even if it would have otherwise been packed. +--keep-pack=<pack-name>:: + This flag causes an object already in the given pack to be + ignored, even if it would have otherwise been + packed. `<pack-name>` is the the pack file name without + leading directory (e.g. `pack-123.pack`). The option could be + specified multiple times to keep multiple packs. + --incremental:: This flag causes an object already in a pack to be ignored even if it would have otherwise been packed. @@ -255,6 +264,30 @@ a missing object is encountered. This is the default action. The form '--missing=allow-any' will allow object traversal to continue if a missing object is encountered. Missing objects will silently be omitted from the results. ++ +The form '--missing=allow-promisor' is like 'allow-any', but will only +allow object traversal to continue for EXPECTED promisor missing objects. +Unexpected missing object will raise an error. + +--exclude-promisor-objects:: + Omit objects that are known to be in the promisor remote. (This + option has the purpose of operating only on locally created objects, + so that when we repack, we still maintain a distinction between + locally created objects [without .promisor] and objects from the + promisor remote [with .promisor].) This is used with partial clone. + +--keep-unreachable:: + Objects unreachable from the refs in packs named with + --unpacked= option are added to the resulting pack, in + addition to the reachable objects that are not in packs marked + with *.keep files. This implies `--revs`. + +--pack-loose-unreachable:: + Pack unreachable loose objects (and their loose counterparts + removed). This implies `--revs`. + +--unpack-unreachable:: + Keep unreachable objects in loose form. This implies `--revs`. SEE ALSO -------- diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt index a37c0af931..03552dd86f 100644 --- a/Documentation/git-prune.txt +++ b/Documentation/git-prune.txt @@ -56,8 +56,8 @@ OPTIONS reachable from any of our references, keep objects reachable from listed <head>s. -EXAMPLE -------- +EXAMPLES +-------- To prune objects not used by your repository or another that borrows from your repository via its @@ -67,7 +67,7 @@ borrows from your repository via its $ git prune $(cd ../another && git rev-parse --all) ------------ -Notes +NOTES ----- In most cases, users will not need to call 'git prune' directly, but diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index ce05b7a5b1..118d9d86f7 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -9,7 +9,7 @@ git-pull - Fetch from and integrate with another repository or a local branch SYNOPSIS -------- [verse] -'git pull' [options] [<repository> [<refspec>...]] +'git pull' [<options>] [<repository> [<refspec>...]] DESCRIPTION @@ -101,13 +101,17 @@ Options related to merging include::merge-options.txt[] -r:: ---rebase[=false|true|preserve|interactive]:: +--rebase[=false|true|merges|preserve|interactive]:: When true, rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to the upstream branch and the upstream branch was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes. + +When set to `merges`, rebase using `git rebase --rebase-merges` so that +the local merge commits are included in the rebase (see +linkgit:git-rebase[1] for details). ++ When set to preserve, rebase with the `--preserve-merges` option passed to `git rebase` so that locally created merge commits will not be flattened. + diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 5b08302fc2..55277a9781 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -11,7 +11,7 @@ SYNOPSIS [verse] 'git push' [--all | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-v | --verbose] - [-u | --set-upstream] [--push-option=<string>] + [-u | --set-upstream] [-o <string> | --push-option=<string>] [--[no-]signed|--signed=(true|false|if-asked)] [--force-with-lease[=<refname>[:<expect>]]] [--no-verify] [<repository> [<refspec>...]] @@ -123,6 +123,7 @@ already exists on the remote side. will be tab-separated and sent to stdout instead of stderr. The full symbolic names of the refs will be given. +-d:: --delete:: All listed refs are deleted from the remote repository. This is the same as prefixing all refs with a colon. @@ -300,7 +301,7 @@ origin +master` to force a push to the `master` branch). See the These options are passed to linkgit:git-send-pack[1]. A thin transfer significantly reduces the amount of sent data when the sender and receiver share many of the same objects in common. The default is - \--thin. + `--thin`. -q:: --quiet:: @@ -423,7 +424,7 @@ reason:: refs, no explanation is needed. For a failed ref, the reason for failure is described. -Note about fast-forwards +NOTE ABOUT FAST-FORWARDS ------------------------ When an update changes a branch (or more in general, a ref) that used to @@ -510,7 +511,7 @@ overwrite it. In other words, "git push --force" is a method reserved for a case where you do mean to lose history. -Examples +EXAMPLES -------- `git push`:: diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt index f2a07d54d6..5c70bc2878 100644 --- a/Documentation/git-read-tree.txt +++ b/Documentation/git-read-tree.txt @@ -132,7 +132,7 @@ OPTIONS The id of the tree object(s) to be read/merged. -Merging +MERGING ------- If `-m` is specified, 'git read-tree' can perform 3 kinds of merge, a single tree merge if only 1 tree is given, a @@ -382,7 +382,7 @@ middle of doing, and when your working tree is ready (i.e. you have finished your work-in-progress), attempt the merge again. -Sparse checkout +SPARSE CHECKOUT --------------- "Sparse checkout" allows populating the working directory sparsely. diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 8a861c1e0d..0e20a66e73 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -8,11 +8,11 @@ git-rebase - Reapply commits on top of another base tip SYNOPSIS -------- [verse] -'git rebase' [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] +'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>] [<upstream> [<branch>]] -'git rebase' [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] +'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>] --root [<branch>] -'git rebase' --continue | --skip | --abort | --quit | --edit-todo +'git rebase' --continue | --skip | --abort | --quit | --edit-todo | --show-current-patch DESCRIPTION ----------- @@ -244,12 +244,22 @@ leave out at most one of A and B, in which case it defaults to HEAD. Keep the commits that do not change anything from its parents in the result. +--allow-empty-message:: + By default, rebasing commits with an empty message will fail. + This option overrides that behavior, allowing commits with empty + messages to be rebased. + --skip:: Restart the rebasing process by skipping the current patch. --edit-todo:: Edit the todo list during an interactive rebase. +--show-current-patch:: + Show the current patch in an interactive rebase or when rebase + is stopped because of conflicts. This is the equivalent of + `git show REBASE_HEAD`. + -m:: --merge:: Use merging strategies to rebase. When the recursive (default) merge @@ -354,9 +364,10 @@ default is `--no-fork-point`, otherwise the default is `--fork-point`. Incompatible with the --interactive option. --signoff:: - This flag is passed to 'git am' to sign off all the rebased - commits (see linkgit:git-am[1]). Incompatible with the - --interactive option. + Add a Signed-off-by: trailer to all the rebased commits. Note + that if `--interactive` is given then only commits marked to be + picked, edited or reworded will have the trailer added. Incompatible + with the `--preserve-merges` option. -i:: --interactive:: @@ -368,6 +379,33 @@ The commit list format can be changed by setting the configuration option rebase.instructionFormat. A customized instruction format will automatically have the long commit hash prepended to the format. +-r:: +--rebase-merges[=(rebase-cousins|no-rebase-cousins)]:: + By default, a rebase will simply drop merge commits from the todo + list, and put the rebased commits into a single, linear branch. + With `--rebase-merges`, the rebase will instead try to preserve + the branching structure within the commits that are to be rebased, + by recreating the merge commits. Any resolved merge conflicts or + manual amendments in these merge commits will have to be + resolved/re-applied manually. ++ +By default, or when `no-rebase-cousins` was specified, commits which do not +have `<upstream>` as direct ancestor will keep their original branch point, +i.e. commits that would be excluded by gitlink:git-log[1]'s +`--ancestry-path` option will keep their original ancestry by default. If +the `rebase-cousins` mode is turned on, such commits are instead rebased +onto `<upstream>` (or `<onto>`, if specified). ++ +The `--rebase-merges` mode is similar in spirit to `--preserve-merges`, but +in contrast to that option works well in interactive rebases: commits can be +reordered, inserted and dropped at will. ++ +It is currently only possible to recreate the merge commits using the +`recursive` merge strategy; Different merge strategies can be used only via +explicit `exec git merge -s <strategy> [...]` commands. ++ +See also REBASING MERGES below. + -p:: --preserve-merges:: Recreate merge commits instead of flattening the history by replaying @@ -765,12 +803,146 @@ The ripple effect of a "hard case" recovery is especially bad: 'everyone' downstream from 'topic' will now have to perform a "hard case" recovery too! +REBASING MERGES +----------------- + +The interactive rebase command was originally designed to handle +individual patch series. As such, it makes sense to exclude merge +commits from the todo list, as the developer may have merged the +then-current `master` while working on the branch, only to rebase +all the commits onto `master` eventually (skipping the merge +commits). + +However, there are legitimate reasons why a developer may want to +recreate merge commits: to keep the branch structure (or "commit +topology") when working on multiple, inter-related branches. + +In the following example, the developer works on a topic branch that +refactors the way buttons are defined, and on another topic branch +that uses that refactoring to implement a "Report a bug" button. The +output of `git log --graph --format=%s -5` may look like this: + +------------ +* Merge branch 'report-a-bug' +|\ +| * Add the feedback button +* | Merge branch 'refactor-button' +|\ \ +| |/ +| * Use the Button class for all buttons +| * Extract a generic Button class from the DownloadButton one +------------ + +The developer might want to rebase those commits to a newer `master` +while keeping the branch topology, for example when the first topic +branch is expected to be integrated into `master` much earlier than the +second one, say, to resolve merge conflicts with changes to the +DownloadButton class that made it into `master`. + +This rebase can be performed using the `--rebase-merges` option. +It will generate a todo list looking like this: + +------------ +label onto + +# Branch: refactor-button +reset onto +pick 123456 Extract a generic Button class from the DownloadButton one +pick 654321 Use the Button class for all buttons +label refactor-button + +# Branch: report-a-bug +reset refactor-button # Use the Button class for all buttons +pick abcdef Add the feedback button +label report-a-bug + +reset onto +merge -C a1b2c3 refactor-button # Merge 'refactor-button' +merge -C 6f5e4d report-a-bug # Merge 'report-a-bug' +------------ + +In contrast to a regular interactive rebase, there are `label`, `reset` +and `merge` commands in addition to `pick` ones. + +The `label` command associates a label with the current HEAD when that +command is executed. These labels are created as worktree-local refs +(`refs/rewritten/<label>`) that will be deleted when the rebase +finishes. That way, rebase operations in multiple worktrees linked to +the same repository do not interfere with one another. If the `label` +command fails, it is rescheduled immediately, with a helpful message how +to proceed. + +The `reset` command resets the HEAD, index and worktree to the specified +revision. It is isimilar to an `exec git reset --hard <label>`, but +refuses to overwrite untracked files. If the `reset` command fails, it is +rescheduled immediately, with a helpful message how to edit the todo list +(this typically happens when a `reset` command was inserted into the todo +list manually and contains a typo). + +The `merge` command will merge the specified revision into whatever is +HEAD at that time. With `-C <original-commit>`, the commit message of +the specified merge commit will be used. When the `-C` is changed to +a lower-case `-c`, the message will be opened in an editor after a +successful merge so that the user can edit the message. + +If a `merge` command fails for any reason other than merge conflicts (i.e. +when the merge operation did not even start), it is rescheduled immediately. + +At this time, the `merge` command will *always* use the `recursive` +merge strategy, with no way to choose a different one. To work around +this, an `exec` command can be used to call `git merge` explicitly, +using the fact that the labels are worktree-local refs (the ref +`refs/rewritten/onto` would correspond to the label `onto`, for example). + +Note: the first command (`label onto`) labels the revision onto which +the commits are rebased; The name `onto` is just a convention, as a nod +to the `--onto` option. + +It is also possible to introduce completely new merge commits from scratch +by adding a command of the form `merge <merge-head>`. This form will +generate a tentative commit message and always open an editor to let the +user edit it. This can be useful e.g. when a topic branch turns out to +address more than a single concern and wants to be split into two or +even more topic branches. Consider this todo list: + +------------ +pick 192837 Switch from GNU Makefiles to CMake +pick 5a6c7e Document the switch to CMake +pick 918273 Fix detection of OpenSSL in CMake +pick afbecd http: add support for TLS v1.3 +pick fdbaec Fix detection of cURL in CMake on Windows +------------ + +The one commit in this list that is not related to CMake may very well +have been motivated by working on fixing all those bugs introduced by +switching to CMake, but it addresses a different concern. To split this +branch into two topic branches, the todo list could be edited like this: + +------------ +label onto + +pick afbecd http: add support for TLS v1.3 +label tlsv1.3 + +reset onto +pick 192837 Switch from GNU Makefiles to CMake +pick 918273 Fix detection of OpenSSL in CMake +pick fdbaec Fix detection of cURL in CMake on Windows +pick 5a6c7e Document the switch to CMake +label cmake + +reset onto +merge tlsv1.3 +merge cmake +------------ + BUGS ---- The todo list presented by `--preserve-merges --interactive` does not represent the topology of the revision graph. Editing commits and rewording their commit messages should work fine, but attempts to -reorder commits tend to produce counterintuitive results. +reorder commits tend to produce counterintuitive results. Use +`--rebase-merges` in such scenarios instead. For example, an attempt to rearrange ------------ diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt index 86a4b32f0f..dedf97efbb 100644 --- a/Documentation/git-receive-pack.txt +++ b/Documentation/git-receive-pack.txt @@ -41,7 +41,7 @@ OPTIONS <directory>:: The repository to sync into. -pre-receive Hook +PRE-RECEIVE HOOK ---------------- Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists and is executable, it will be invoked once with no parameters. The @@ -116,7 +116,7 @@ bail out if the update is not to be supported. See the notes on the quarantine environment below. -update Hook +UPDATE HOOK ----------- Before each ref is updated, if $GIT_DIR/hooks/update file exists and is executable, it is invoked once per ref, with three parameters: @@ -138,7 +138,7 @@ ensure the ref will actually be updated, it is only a prerequisite. As such it is not a good idea to send notices (e.g. email) from this hook. Consider using the post-receive hook instead. -post-receive Hook +POST-RECEIVE HOOK ----------------- After all refs were updated (or attempted to be updated), if any ref update was successful, and if $GIT_DIR/hooks/post-receive @@ -198,7 +198,7 @@ after it was updated by 'git-receive-pack', but before the hook was able to evaluate it. It is recommended that hooks rely on sha1-new rather than the current value of refname. -post-update Hook +POST-UPDATE HOOK ---------------- After all other processing, if at least one ref was updated, and if $GIT_DIR/hooks/post-update file exists and is executable, then @@ -216,7 +216,7 @@ if the repository is packed and is served via a dumb transport. exec git update-server-info -Quarantine Environment +QUARANTINE ENVIRONMENT ---------------------- When `receive-pack` takes in objects, they are placed into a temporary diff --git a/Documentation/git-remote-ext.txt b/Documentation/git-remote-ext.txt index b25d0b5996..3fc5d94336 100644 --- a/Documentation/git-remote-ext.txt +++ b/Documentation/git-remote-ext.txt @@ -55,14 +55,14 @@ some tunnel. the vhost field in the git:// service request (to rest of the argument). Default is not to send vhost in such request (if sent). -ENVIRONMENT VARIABLES: ----------------------- +ENVIRONMENT VARIABLES +--------------------- GIT_TRANSLOOP_DEBUG:: If set, prints debugging information about various reads/writes. -ENVIRONMENT VARIABLES PASSED TO COMMAND: ----------------------------------------- +ENVIRONMENT VARIABLES PASSED TO COMMAND +--------------------------------------- GIT_EXT_SERVICE:: Set to long name (git-upload-pack, etc...) of service helper needs @@ -73,8 +73,8 @@ GIT_EXT_SERVICE_NOPREFIX:: to invoke. -EXAMPLES: ---------- +EXAMPLES +-------- This remote helper is transparently used by Git when you use commands such as "git fetch <URL>", "git clone <URL>", , "git push <URL>" or "git remote add <nick> <URL>", where <URL> diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index 577b969c1b..0cad37fb81 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -172,24 +172,28 @@ With `-n` option, the remote heads are not queried first with 'prune':: -Deletes all stale remote-tracking branches under <name>. -These stale branches have already been removed from the remote repository -referenced by <name>, but are still locally available in -"remotes/<name>". +Deletes stale references associated with <name>. By default, stale +remote-tracking branches under <name> are deleted, but depending on +global configuration and the configuration of the remote we might even +prune local tags that haven't been pushed there. Equivalent to `git +fetch --prune <name>`, except that no new references will be fetched. ++ +See the PRUNING section of linkgit:git-fetch[1] for what it'll prune +depending on various configuration. + With `--dry-run` option, report what branches will be pruned, but do not actually prune them. 'update':: -Fetch updates for a named set of remotes in the repository as defined by -remotes.<group>. If a named group is not specified on the command line, +Fetch updates for remotes or remote groups in the repository as defined by +remotes.<group>. If neither group nor remote is specified on the command line, the configuration parameter remotes.default will be used; if remotes.default is not defined, all remotes which do not have the configuration parameter remote.<name>.skipDefaultUpdate set to true will be updated. (See linkgit:git-config[1]). + -With `--prune` option, prune all the remotes that are updated. +With `--prune` option, run pruning against all the remotes that are updated. DISCUSSION @@ -199,7 +203,7 @@ The remote configuration is achieved using the `remote.origin.url` and `remote.origin.fetch` configuration variables. (See linkgit:git-config[1]). -Examples +EXAMPLES -------- * Add a new remote, fetch, and check out a branch from it diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt index ae750e9e11..d90e7907f4 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] [-b] [--window=<n>] [--depth=<n>] [--threads=<n>] +'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [-b] [--window=<n>] [--depth=<n>] [--threads=<n>] [--keep-pack=<pack-name>] DESCRIPTION ----------- @@ -90,7 +90,9 @@ other objects in that pack they already have locally. space. `--depth` limits the maximum delta depth; making it too deep affects the performance on the unpacker side, because delta data needs to be applied that many times to get to the necessary object. - The default value for --window is 10 and --depth is 50. ++ +The default value for --window is 10 and --depth is 50. The maximum +depth is 4095. --threads=<n>:: This option is passed through to `git pack-objects`. @@ -133,6 +135,13 @@ other objects in that pack they already have locally. with `-b` or `repack.writeBitmaps`, as it ensures that the bitmapped packfile has the necessary objects. +--keep-pack=<pack-name>:: + Exclude the given pack from repacking. This is the equivalent + of having `.keep` file on the pack. `<pack-name>` is the the + pack file name without leading directory (e.g. `pack-123.pack`). + The option could be specified multiple times to keep multiple + packs. + --unpack-unreachable=<when>:: When loosening unreachable objects, do not bother loosening any objects older than `<when>`. This can be used to optimize out diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index e5c57ae6ef..246dc9943c 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -11,6 +11,7 @@ SYNOPSIS 'git replace' [-f] <object> <replacement> 'git replace' [-f] --edit <object> 'git replace' [-f] --graft <commit> [<parent>...] +'git replace' [-f] --convert-graft-file 'git replace' -d <object>... 'git replace' [--format=<format>] [-l [<pattern>]] @@ -87,9 +88,13 @@ OPTIONS content as <commit> except that its parents will be [<parent>...] instead of <commit>'s parents. A replacement ref is then created to replace <commit> with the newly created - commit. See contrib/convert-grafts-to-replace-refs.sh for an - example script based on this option that can convert grafts to - replace refs. + commit. Use `--convert-graft-file` to convert a + `$GIT_DIR/info/grafts` file and use replace refs instead. + +--convert-graft-file:: + Creates graft commits for all entries in `$GIT_DIR/info/grafts` + and deletes that file upon success. The purpose is to help users + with transitioning off of the now-deprecated graft file. -l <pattern>:: --list <pattern>:: diff --git a/Documentation/git-request-pull.txt b/Documentation/git-request-pull.txt index c32cb0bea1..4d4392d0f8 100644 --- a/Documentation/git-request-pull.txt +++ b/Documentation/git-request-pull.txt @@ -46,8 +46,8 @@ ref that is different from the ref you have locally, you can use the its remote name. -EXAMPLE -------- +EXAMPLES +-------- Imagine that you built your work on your `master` branch on top of the `v1.0` release, and want it to be integrated to the project. diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt index 95326b85ff..e72d332b83 100644 --- a/Documentation/git-rev-parse.txt +++ b/Documentation/git-rev-parse.txt @@ -9,7 +9,7 @@ git-rev-parse - Pick out and massage parameters SYNOPSIS -------- [verse] -'git rev-parse' [ --option ] <args>... +'git rev-parse' [<options>] <args>... DESCRIPTION ----------- @@ -360,7 +360,7 @@ Example ------------ OPTS_SPEC="\ -some-command [options] <args>... +some-command [<options>] <args>... some-command does foo and bar! -- @@ -385,7 +385,7 @@ When `"$@"` is `-h` or `--help` in the above example, the following usage text would be shown: ------------ -usage: some-command [options] <args>... +usage: some-command [<options>] <args>... some-command does foo and bar! diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index 8060ea35c5..4f3efde80c 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -9,7 +9,7 @@ git-send-email - Send a collection of patches as emails SYNOPSIS -------- [verse] -'git send-email' [options] <file|directory|rev-list options>... +'git send-email' [<options>] <file|directory|rev-list options>... 'git send-email' --dump-aliases @@ -84,6 +84,11 @@ See the CONFIGURATION section for `sendemail.multiEdit`. the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not set, as returned by "git var -l". +--reply-to=<address>:: + Specify the address where replies from recipients should go to. + Use this if replies to messages should go to another address than what + is specified with the --from parameter. + --in-reply-to=<identifier>:: Make the first mail (or all the mails with `--no-thread`) appear as a reply to the given Message-Id, which avoids breaking threads to @@ -250,7 +255,7 @@ must be used for each option. --batch-size=<num>:: Some email servers (e.g. smtp.163.com) limit the number emails to be - sent per session (connection) and this will lead to a faliure when + sent per session (connection) and this will lead to a failure when sending many messages. With this option, send-email will disconnect after sending $<num> messages and wait for a few seconds (see --relogin-delay) and reconnect, to work around such a limit. You may want to @@ -453,8 +458,8 @@ sendemail.confirm:: one of 'always', 'never', 'cc', 'compose', or 'auto'. See `--confirm` in the previous section for the meaning of these values. -EXAMPLE -------- +EXAMPLES +-------- Use gmail as the smtp server ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To use 'git send-email' to send your patches through the GMail SMTP server, @@ -468,16 +473,7 @@ edit ~/.gitconfig to specify your account settings: If you have multifactor authentication setup on your gmail account, you will need to generate an app-specific password for use with 'git send-email'. Visit -https://security.google.com/settings/security/apppasswords to setup an -app-specific password. Once setup, you can store it with the credentials -helper: - - $ git credential fill - protocol=smtp - host=smtp.gmail.com - username=youname@gmail.com - password=app-password - +https://security.google.com/settings/security/apppasswords to create it. Once your commits are ready to be sent to the mailing list, run the following commands: @@ -486,6 +482,11 @@ following commands: $ edit outgoing/0000-* $ git send-email outgoing/* +The first time you run it, you will be prompted for your credentials. Enter the +app-specific or your regular password as appropriate. If you have credential +helper configured (see linkgit:git-credential[1]), the password will be saved in +the credential store so you won't have to type it the next time. + Note: the following perl modules are required Net::SMTP::SSL, MIME::Base64 and Authen::SASL diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt index f51c64939b..44fd146b91 100644 --- a/Documentation/git-send-pack.txt +++ b/Documentation/git-send-pack.txt @@ -99,7 +99,7 @@ be in a separate packet, and the list must end with a flush packet. The remote refs to update. -Specifying the Refs +SPECIFYING THE REFS ------------------- There are three ways to specify which refs to update on the diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt index 54cf2560be..11361f33e9 100644 --- a/Documentation/git-shell.txt +++ b/Documentation/git-shell.txt @@ -62,8 +62,8 @@ permissions. If a `no-interactive-login` command exists, then it is run and the interactive shell is aborted. -EXAMPLE -------- +EXAMPLES +-------- To disable interactive logins, displaying a greeting instead: diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index ee6c5476c1..bc80905a8a 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -8,8 +8,8 @@ git-shortlog - Summarize 'git log' output SYNOPSIS -------- [verse] +'git shortlog' [<options>] [<revision range>] [[--] <path>...] git log --pretty=short | 'git shortlog' [<options>] -'git shortlog' [<options>] [<revision range>] [[\--] <path>...] DESCRIPTION ----------- @@ -69,11 +69,11 @@ them. ways to spell <revision range>, see the "Specifying Ranges" section of linkgit:gitrevisions[7]. -[\--] <path>...:: +[--] <path>...:: Consider only commits that are enough to explain how the files that match the specified paths came to be. + -Paths may need to be prefixed with "\-- " to separate them from +Paths may need to be prefixed with `--` to separate them from options or the revision range, when confusion arises. MAPPING AUTHORS diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt index 7818e0f098..262db049d7 100644 --- a/Documentation/git-show-branch.txt +++ b/Documentation/git-show-branch.txt @@ -173,8 +173,8 @@ The "fixes" branch adds one commit "Introduce "reset type" flag to The current branch is "master". -EXAMPLE -------- +EXAMPLES +-------- If you keep your primary branches immediately under `refs/heads`, and topic branches in subdirectories of diff --git a/Documentation/git-show-index.txt b/Documentation/git-show-index.txt index a8a9509e0e..424e4ba84c 100644 --- a/Documentation/git-show-index.txt +++ b/Documentation/git-show-index.txt @@ -14,13 +14,27 @@ SYNOPSIS DESCRIPTION ----------- -Read the idx file for a Git packfile created with -'git pack-objects' command from the standard input, and -dump its contents. +Read the `.idx` file for a Git packfile (created with +linkgit:git-pack-objects[1] or linkgit:git-index-pack[1]) from the +standard input, and dump its contents. The output consists of one object +per line, with each line containing two or three space-separated +columns: -The information it outputs is subset of what you can get from -'git verify-pack -v'; this command only shows the packfile -offset and SHA-1 of each object. + - the first column is the offset in bytes of the object within the + corresponding packfile + + - the second column is the object id of the object + + - if the index version is 2 or higher, the third column contains the + CRC32 of the object data + +The objects are output in the order in which they are found in the index +file, which should be (in a correctly constructed file) sorted by object +id. + +Note that you can get more information on a packfile by calling +linkgit:git-verify-pack[1]. However, as this command considers only the +index file itself, it's both faster and more flexible. GIT --- diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt index c0aa871c9e..d28e6154c6 100644 --- a/Documentation/git-show-ref.txt +++ b/Documentation/git-show-ref.txt @@ -120,8 +120,8 @@ $ git show-ref --heads --hash ... ----------------------------------------------------------------------------- -EXAMPLE -------- +EXAMPLES +-------- To show all references called "master", whether tags or heads or anything else, and regardless of how deep in the reference naming hierarchy they are, diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt index e73ef54017..fcf528c1b3 100644 --- a/Documentation/git-show.txt +++ b/Documentation/git-show.txt @@ -9,7 +9,7 @@ git-show - Show various types of objects SYNOPSIS -------- [verse] -'git show' [options] [<object>...] +'git show' [<options>] [<object>...] DESCRIPTION ----------- @@ -77,7 +77,7 @@ EXAMPLES Concatenates the contents of said Makefiles in the head of the branch `master`. -Discussion +DISCUSSION ---------- include::i18n.txt[] diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt index 056dfb8661..7ef8c47911 100644 --- a/Documentation/git-stash.txt +++ b/Documentation/git-stash.txt @@ -14,7 +14,7 @@ SYNOPSIS 'git stash' ( pop | apply ) [--index] [-q|--quiet] [<stash>] 'git stash' branch <branchname> [<stash>] 'git stash' [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] - [-u|--include-untracked] [-a|--all] [-m|--message <message>]] + [-u|--include-untracked] [-a|--all] [-m|--message <message>] [--] [<pathspec>...]] 'git stash' clear 'git stash' create [<message>] diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index f9c91c721e..c4467ffb98 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -113,7 +113,7 @@ The possible options are: - 'matching' - Shows ignored files and directories matching an ignore pattern. + -When 'matching' mode is specified, paths that explicity match an +When 'matching' mode is specified, paths that explicitly match an ignored pattern are shown. If a directory matches an ignore pattern, then it is shown, but not paths contained in the ignored directory. If a directory does not match an ignore pattern, but all contents are @@ -130,6 +130,21 @@ ignored, then the directory is not shown, but all contents are shown. without options are equivalent to 'always' and 'never' respectively. +--ahead-behind:: +--no-ahead-behind:: + Display or do not display detailed ahead/behind counts for the + branch relative to its upstream branch. Defaults to true. + +--renames:: +--no-renames:: + Turn on/off rename detection regardless of user configuration. + See also linkgit:git-diff[1] `--no-renames`. + +--find-renames[=<n>]:: + Turn on rename detection, optionally setting the similarity + threshold. + See also linkgit:git-diff[1] `--find-renames`. + <pathspec>...:: See the 'pathspec' entry in linkgit:gitglossary[7]. diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 71c5618e82..ba3c4df550 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -42,8 +42,8 @@ have to use '../foo.git' instead of './foo.git' - as one might expect when following the rules for relative URLs - because the evaluation of relative URLs in Git is identical to that of relative directories). + -The default remote is the remote of the remote tracking branch -of the current branch. If no such remote tracking branch exists or +The default remote is the remote of the remote-tracking branch +of the current branch. If no such remote-tracking branch exists or the HEAD is detached, "origin" is assumed to be the default remote. If the superproject doesn't have a default remote configured the superproject is its own authoritative upstream and the current @@ -183,12 +183,17 @@ information too. foreach [--recursive] <command>:: Evaluates an arbitrary shell command in each checked out submodule. - The command has access to the variables $name, $path, $sha1 and - $toplevel: + The command has access to the variables $name, $sm_path, $displaypath, + $sha1 and $toplevel: $name is the name of the relevant submodule section in `.gitmodules`, - $path is the name of the submodule directory relative to the - superproject, $sha1 is the commit as recorded in the superproject, - and $toplevel is the absolute path to the top-level of the superproject. + $sm_path is the path of the submodule as recorded in the immediate + superproject, $displaypath contains the relative path from the + current working directory to the submodules root directory, + $sha1 is the commit as recorded in the immediate + superproject, and $toplevel is the absolute path to the top-level + of the immediate superproject. + Note that to avoid conflicts with '$PATH' on Windows, the '$path' + variable is now a deprecated synonym of '$sm_path' variable. Any submodules defined in the superproject but not checked out are ignored by this command. Unless given `--quiet`, foreach prints the name of each submodule before evaluating the command. @@ -213,8 +218,8 @@ sync [--recursive] [--] [<path>...]:: submodule URLs change upstream and you need to update your local repositories accordingly. + -"git submodule sync" synchronizes all submodules while -"git submodule sync \-- A" synchronizes submodule "A" only. +`git submodule sync` synchronizes all submodules while +`git submodule sync -- A` synchronizes submodule "A" only. + If `--recursive` is specified, this command will recurse into the registered submodules, and sync any nested submodules within. @@ -239,6 +244,13 @@ OPTIONS --quiet:: Only print error messages. +--progress:: + This option is only valid for add and update commands. + Progress status is reported on the standard error stream + by default when it is attached to a terminal, unless -q + is specified. This flag forces progress status even if the + standard error stream is not directed to a terminal. + --all:: This option is only valid for the deinit command. Unregister all submodules in the working tree. @@ -362,7 +374,15 @@ the submodule itself. this option will be passed to the linkgit:git-clone[1] command. + *NOTE*: Do *not* use this option unless you have read the note -for linkgit:git-clone[1]'s `--reference` and `--shared` options carefully. +for linkgit:git-clone[1]'s `--reference`, `--shared`, and `--dissociate` +options carefully. + +--dissociate:: + This option is only valid for add and update commands. These + commands sometimes need to clone a remote repository. In this case, + this option will be passed to the linkgit:git-clone[1] command. ++ +*NOTE*: see the NOTE for the `--reference` option. --recursive:: This option is only valid for foreach, update, status and sync commands. diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 636e09048e..7ea24fc942 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -8,7 +8,7 @@ git-svn - Bidirectional operation between a Subversion repository and Git SYNOPSIS -------- [verse] -'git svn' <command> [options] [arguments] +'git svn' <command> [<options>] [<arguments>] DESCRIPTION ----------- @@ -635,7 +635,8 @@ config key: svn.findcopiesharder -A<filename>:: --authors-file=<filename>:: - Syntax is compatible with the file used by 'git cvsimport': + Syntax is compatible with the file used by 'git cvsimport' but + an empty email address can be supplied with '<>': + ------------------------------------------------------------------------ loginname = Joe User <user@example.com> @@ -654,8 +655,14 @@ config key: svn.authorsfile If this option is specified, for each SVN committer name that does not exist in the authors file, the given file is executed with the committer name as the first argument. The program is - expected to return a single line of the form "Name <email>", - which will be treated as if included in the authors file. + expected to return a single line of the form "Name <email>" or + "Name <>", which will be treated as if included in the authors + file. ++ +Due to historical reasons a relative 'filename' is first searched +relative to the current directory for 'init' and 'clone' and relative +to the root of the working tree for 'fetch'. If 'filename' is +not found, it is searched like any other command in '$PATH'. + [verse] config key: svn.authorsProg @@ -700,7 +707,7 @@ creating the branch or tag. config key: svn.useLogAuthor --add-author-from:: - When committing to svn from Git (as part of 'commit-diff', 'set-tree' or 'dcommit' + When committing to svn from Git (as part of 'set-tree' or 'dcommit' operations), if the existing log message doesn't already have a `From:` or `Signed-off-by:` line, append a `From:` line based on the Git commit's author string. If you use this, then `--use-log-author` diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 956fc019f9..87c4288ffc 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -9,7 +9,7 @@ git-tag - Create, list, delete or verify a tag object signed with GPG SYNOPSIS -------- [verse] -'git tag' [-a | -s | -u <keyid>] [-f] [-m <msg> | -F <file>] +'git tag' [-a | -s | -u <keyid>] [-f] [-m <msg> | -F <file>] [-e] <tagname> [<commit> | <object>] 'git tag' -d <tagname>... 'git tag' [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>] @@ -34,8 +34,8 @@ in the tag message. If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <keyid>` are absent, `-a` is implied. -Otherwise just a tag reference for the SHA-1 object name of the commit object is -created (i.e. a lightweight tag). +Otherwise, a tag reference that points directly at the given object +(i.e., a lightweight tag) is created. A GnuPG signed tag object will be created when `-s` or `-u <keyid>` is used. When `-u <keyid>` is not used, the @@ -167,6 +167,12 @@ This option is only applicable when listing tags without annotation lines. Implies `-a` if none of `-a`, `-s`, or `-u <keyid>` is given. +-e:: +--edit:: + The message taken from file with `-F` and command line with + `-m` are usually used as the tag message unmodified. + This option lets you further edit the message taken from these sources. + --cleanup=<mode>:: This option sets how the tag message is cleaned up. The '<mode>' can be one of 'verbatim', 'whitespace' and 'strip'. The diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt index ad2383d7ed..4e8e762e68 100644 --- a/Documentation/git-update-index.txt +++ b/Documentation/git-update-index.txt @@ -228,7 +228,7 @@ will remove the intended effect of the option. cleaner names. The same applies to directories ending '/' and paths with '//' -Using --refresh +USING --REFRESH --------------- `--refresh` does not calculate a new sha1 file or bring the index up to date for mode/content changes. But what it *does* do is to @@ -239,7 +239,7 @@ the stat entry is out of date. For example, you'd want to do this after doing a 'git read-tree', to link up the stat index details with the proper files. -Using --cacheinfo or --info-only +USING --CACHEINFO OR --INFO-ONLY -------------------------------- `--cacheinfo` is used to register a file that is not in the current working directory. This is useful for minimum-checkout @@ -261,7 +261,7 @@ useful when the file is available, but you do not wish to update the object database. -Using --index-info +USING --INDEX-INFO ------------------ `--index-info` is a more powerful mechanism that lets you feed @@ -317,7 +317,7 @@ $ git ls-files -s ------------ -Using ``assume unchanged'' bit +USING ``ASSUME UNCHANGED'' BIT ------------------------------ Many operations in Git depend on your filesystem to have an @@ -350,7 +350,7 @@ the index (use `git update-index --really-refresh` if you want to mark them as "assume unchanged"). -Examples +EXAMPLES -------- To update and refresh only the files already checked out: @@ -387,7 +387,7 @@ M foo.c <9> now it checks with lstat(2) and finds it has been changed. -Skip-worktree bit +SKIP-WORKTREE BIT ----------------- Skip-worktree bit can be defined in one (long) sentence: When reading @@ -407,7 +407,7 @@ Although this bit looks similar to assume-unchanged bit, its goal is different from assume-unchanged bit's. Skip-worktree also takes precedence over assume-unchanged bit when both are set. -Split index +SPLIT INDEX ----------- This mode is designed for repositories with very large indexes, and @@ -432,7 +432,7 @@ To avoid deleting a shared index file that is still used, its modification time is updated to the current time everytime a new split index based on the shared index file is either created or read from. -Untracked cache +UNTRACKED CACHE --------------- This cache is meant to speed up commands that involve determining @@ -464,7 +464,33 @@ command reads the index; while when `--[no-|force-]untracked-cache` are used, the untracked cache is immediately added to or removed from the index. -File System Monitor +Before 2.17, the untracked cache had a bug where replacing a directory +with a symlink to another directory could cause it to incorrectly show +files tracked by git as untracked. See the "status: add a failing test +showing a core.untrackedCache bug" commit to git.git. A workaround for +that is (and this might work for other undiscovered bugs in the +future): + +---------------- +$ git -c core.untrackedCache=false status +---------------- + +This bug has also been shown to affect non-symlink cases of replacing +a directory with a file when it comes to the internal structures of +the untracked cache, but no case has been reported where this resulted in +wrong "git status" output. + +There are also cases where existing indexes written by git versions +before 2.17 will reference directories that don't exist anymore, +potentially causing many "could not open directory" warnings to be +printed on "git status". These are new warnings for existing issues +that were previously silently discarded. + +As with the bug described above the solution is to one-off do a "git +status" run with `core.untrackedCache=false` to flush out the leftover +bad data. + +FILE SYSTEM MONITOR ------------------- This feature is intended to speed up git operations for repos that have @@ -492,7 +518,7 @@ file system monitor is added to or removed from the index the next time a command reads the index. When `--[no-]fsmonitor` are used, the file system monitor is immediately added to or removed from the index. -Configuration +CONFIGURATION ------------- The command honors `core.filemode` configuration variable. If diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt index 969bfab2ab..bc8fdfd469 100644 --- a/Documentation/git-update-ref.txt +++ b/Documentation/git-update-ref.txt @@ -120,7 +120,7 @@ modifications are performed. Note that while each individual <ref> is updated or deleted atomically, a concurrent reader may still see a subset of the modifications. -Logging Updates +LOGGING UPDATES --------------- If config parameter "core.logAllRefUpdates" is true and the ref is one under "refs/heads/", "refs/remotes/", "refs/notes/", or the symbolic ref HEAD; or diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt index 44ff9541df..6072f936ab 100644 --- a/Documentation/git-var.txt +++ b/Documentation/git-var.txt @@ -23,14 +23,14 @@ OPTIONS as well. (However, the configuration variables listing functionality is deprecated in favor of `git config -l`.) -EXAMPLE +EXAMPLES -------- $ git var GIT_AUTHOR_IDENT Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600 VARIABLES ----------- +--------- GIT_AUTHOR_IDENT:: The author of a piece of code. diff --git a/Documentation/git-web--browse.txt b/Documentation/git-web--browse.txt index 2d6b09a43c..fd952a5ff9 100644 --- a/Documentation/git-web--browse.txt +++ b/Documentation/git-web--browse.txt @@ -8,7 +8,7 @@ git-web--browse - Git helper script to launch a web browser SYNOPSIS -------- [verse] -'git web{litdd}browse' [OPTIONS] URL/FILE ... +'git web{litdd}browse' [<options>] <url|file>... DESCRIPTION ----------- @@ -84,7 +84,7 @@ variable exists then 'git web{litdd}browse' will treat the specified tool as a custom command and will use a shell eval to run the command with the URLs passed as arguments. -Note about konqueror +NOTE ABOUT KONQUEROR -------------------- When 'konqueror' is specified by a command-line option or a diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt index 5ac3f68ab5..afc6576a14 100644 --- a/Documentation/git-worktree.txt +++ b/Documentation/git-worktree.txt @@ -12,7 +12,9 @@ SYNOPSIS 'git worktree add' [-f] [--detach] [--checkout] [--lock] [-b <new-branch>] <path> [<commit-ish>] 'git worktree list' [--porcelain] 'git worktree lock' [--reason <string>] <worktree> +'git worktree move' <worktree> <new-path> 'git worktree prune' [-n] [-v] [--expire <expire>] +'git worktree remove' [-f] <worktree> 'git worktree unlock' <worktree> DESCRIPTION @@ -25,19 +27,16 @@ out more than one branch at a time. With `git worktree add` a new working tree is associated with the repository. This new working tree is called a "linked working tree" as opposed to the "main working tree" prepared by "git init" or "git clone". A repository has one main working tree (if it's not a -bare repository) and zero or more linked working trees. +bare repository) and zero or more linked working trees. When you are done +with a linked working tree, remove it with `git worktree remove`. -When you are done with a linked working tree you can simply delete it. -The working tree's administrative files in the repository (see -"DETAILS" below) will eventually be removed automatically (see +If a working tree is deleted without using `git worktree remove`, then +its associated administrative files, which reside in the repository +(see "DETAILS" below), will eventually be removed automatically (see `gc.worktreePruneExpire` in linkgit:git-config[1]), or you can run `git worktree prune` in the main or any linked working tree to clean up any stale administrative files. -If you move a linked working tree, you need to manually update the -administrative files so that they do not get pruned automatically. See -section "DETAILS" for more information. - If a linked working tree is stored on a portable device or network share which is not always mounted, you can prevent its administrative files from being pruned by issuing the `git worktree lock` command, optionally @@ -62,8 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch> ------------ + If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used, -then, as a convenience, a new branch based at HEAD is created automatically, -as if `-b $(basename <path>)` was specified. +then, as a convenience, the new worktree is associated with a branch +(call it `<branch>`) named after `$(basename <path>)`. If `<branch>` +doesn't exist, a new branch based on HEAD is automatically created as +if `-b <branch>` was given. If `<branch>` does exist, it will be +checked out in the new worktree, if it's not checked out anywhere +else, otherwise the command will refuse to create the worktree (unless +`--force` is used). list:: @@ -80,10 +84,22 @@ files from being pruned automatically. This also prevents it from being moved or deleted. Optionally, specify a reason for the lock with `--reason`. +move:: + +Move a working tree to a new location. Note that the main working tree +or linked working trees containing submodules cannot be moved. + prune:: Prune working tree information in $GIT_DIR/worktrees. +remove:: + +Remove a working tree. Only clean working trees (no untracked files +and no modification in tracked files) can be removed. Unclean working +trees or ones with submodules can be removed with `--force`. The main +working tree cannot be removed. + unlock:: Unlock a working tree, allowing it to be pruned, moved or deleted. @@ -93,9 +109,10 @@ OPTIONS -f:: --force:: - By default, `add` refuses to create a new working tree when `<commit-ish>` is a branch name and - is already checked out by another working tree. This option overrides - that safeguard. + By default, `add` refuses to create a new working tree when + `<commit-ish>` is a branch name and is already checked out by + another working tree and `remove` refuses to remove an unclean + working tree. This option overrides these safeguards. -b <new-branch>:: -B <new-branch>:: @@ -197,7 +214,7 @@ thumb is do not make any assumption about whether a path belongs to $GIT_DIR or $GIT_COMMON_DIR when you need to directly access something inside $GIT_DIR. Use `git rev-parse --git-path` to get the final path. -If you move a linked working tree, you need to update the 'gitdir' file +If you manually move a linked working tree, you need to update the 'gitdir' file in the entry's directory. For example, if a linked working tree is moved to `/newpath/test-next` and its `.git` file points to `/path/main/.git/worktrees/test-next`, then update @@ -221,7 +238,7 @@ The worktree list command has two output formats. The default format shows the details on a single line with columns. For example: ------------ -S git worktree list +$ git worktree list /path/to/bare-source (bare) /path/to/linked-worktree abcd1234 [master] /path/to/other-linked-worktree 1234abc (detached HEAD) @@ -236,7 +253,7 @@ if the value is true. An empty line indicates the end of a worktree. For example: ------------ -S git worktree list --porcelain +$ git worktree list --porcelain worktree /path/to/bare-source bare @@ -267,8 +284,7 @@ $ pushd ../temp # ... hack hack hack ... $ git commit -a -m 'emergency fix for boss' $ popd -$ rm -rf ../temp -$ git worktree prune +$ git worktree remove ../temp ------------ BUGS @@ -277,13 +293,6 @@ Multiple checkout in general is still experimental, and the support for submodules is incomplete. It is NOT recommended to make multiple checkouts of a superproject. -git-worktree could provide more automation for tasks currently -performed manually, such as: - -- `remove` to remove a linked working tree and its administrative files (and - warn if the working tree is dirty) -- `mv` to move or rename a working tree and update its administrative files - GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git.txt b/Documentation/git.txt index 8163b5796b..dba7f0c18e 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -11,7 +11,7 @@ SYNOPSIS [verse] 'git' [--version] [--help] [-C <path>] [-c <name>=<value>] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path] - [-p|--paginate|--no-pager] [--no-replace-objects] [--bare] + [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare] [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>] [--super-prefix=<path>] <command> [<args>] @@ -103,6 +103,7 @@ foo.bar= ...`) sets `foo.bar` to the empty string which `git config configuration options (see the "Configuration Mechanism" section below). +-P:: --no-pager:: Do not pipe Git output into a pager. @@ -163,6 +164,16 @@ foo.bar= ...`) sets `foo.bar` to the empty string which `git config Do not perform optional operations that require locks. This is equivalent to setting the `GIT_OPTIONAL_LOCKS` to `0`. +--list-cmds=group[,group...]:: + List commands by group. This is an internal/experimental + option and may change or be removed in the future. Supported + groups are: builtins, parseopt (builtin commands that use + parse-options), main (all commands in libexec directory), + others (all other commands in `$PATH` that have git- prefix), + list-<category> (see categories in command-list.txt), + nohelpers (exclude helper commands), alias and config + (retrieve command list from config variable completion.commands) + GIT COMMANDS ------------ @@ -849,6 +860,9 @@ Report bugs to the Git mailing list <git@vger.kernel.org> where the development and maintenance is primarily done. You do not have to be subscribed to the list to send a message there. +Issues which are security relevant should be disclosed privately to +the Git Security mailing list <git-security@googlegroups.com>. + SEE ALSO -------- linkgit:gittutorial[7], linkgit:gittutorial-2[7], diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index 30687de81a..92010b062e 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -3,7 +3,7 @@ gitattributes(5) NAME ---- -gitattributes - defining attributes per path +gitattributes - Defining attributes per path SYNOPSIS -------- @@ -56,9 +56,16 @@ Unspecified:: When more than one pattern matches the path, a later line overrides an earlier line. This overriding is done per -attribute. The rules how the pattern matches paths are the -same as in `.gitignore` files; see linkgit:gitignore[5]. -Unlike `.gitignore`, negative patterns are forbidden. +attribute. + +The rules by which the pattern matches paths are the same as in +`.gitignore` files (see linkgit:gitignore[5]), with a few exceptions: + + - negative patterns are forbidden + + - patterns that match a directory do not recursively match paths + inside that directory (so using the trailing-slash `path/` syntax is + pointless in an attributes file; use `path/**` instead) When deciding what attributes are assigned to a path, Git consults `$GIT_DIR/info/attributes` file (which has the highest @@ -272,6 +279,94 @@ few exceptions. Even though... catch potential problems early, safety triggers. +`working-tree-encoding` +^^^^^^^^^^^^^^^^^^^^^^^ + +Git recognizes files encoded in ASCII or one of its supersets (e.g. +UTF-8, ISO-8859-1, ...) as text files. Files encoded in certain other +encodings (e.g. UTF-16) are interpreted as binary and consequently +built-in Git text processing tools (e.g. 'git diff') as well as most Git +web front ends do not visualize the contents of these files by default. + +In these cases you can tell Git the encoding of a file in the working +directory with the `working-tree-encoding` attribute. If a file with this +attribute is added to Git, then Git reencodes the content from the +specified encoding to UTF-8. Finally, Git stores the UTF-8 encoded +content in its internal data structure (called "the index"). On checkout +the content is reencoded back to the specified encoding. + +Please note that using the `working-tree-encoding` attribute may have a +number of pitfalls: + +- Alternative Git implementations (e.g. JGit or libgit2) and older Git + versions (as of March 2018) do not support the `working-tree-encoding` + attribute. If you decide to use the `working-tree-encoding` attribute + in your repository, then it is strongly recommended to ensure that all + clients working with the repository support it. + + For example, Microsoft Visual Studio resources files (`*.rc`) or + PowerShell script files (`*.ps1`) are sometimes encoded in UTF-16. + If you declare `*.ps1` as files as UTF-16 and you add `foo.ps1` with + a `working-tree-encoding` enabled Git client, then `foo.ps1` will be + stored as UTF-8 internally. A client without `working-tree-encoding` + support will checkout `foo.ps1` as UTF-8 encoded file. This will + typically cause trouble for the users of this file. + + If a Git client, that does not support the `working-tree-encoding` + attribute, adds a new file `bar.ps1`, then `bar.ps1` will be + stored "as-is" internally (in this example probably as UTF-16). + A client with `working-tree-encoding` support will interpret the + internal contents as UTF-8 and try to convert it to UTF-16 on checkout. + That operation will fail and cause an error. + +- Reencoding content to non-UTF encodings can cause errors as the + conversion might not be UTF-8 round trip safe. If you suspect your + encoding to not be round trip safe, then add it to + `core.checkRoundtripEncoding` to make Git check the round trip + encoding (see linkgit:git-config[1]). SHIFT-JIS (Japanese character + set) is known to have round trip issues with UTF-8 and is checked by + default. + +- Reencoding content requires resources that might slow down certain + Git operations (e.g 'git checkout' or 'git add'). + +Use the `working-tree-encoding` attribute only if you cannot store a file +in UTF-8 encoding and if you want Git to be able to process the content +as text. + +As an example, use the following attributes if your '*.ps1' files are +UTF-16 encoded with byte order mark (BOM) and you want Git to perform +automatic line ending conversion based on your platform. + +------------------------ +*.ps1 text working-tree-encoding=UTF-16 +------------------------ + +Use the following attributes if your '*.ps1' files are UTF-16 little +endian encoded without BOM and you want Git to use Windows line endings +in the working directory. Please note, it is highly recommended to +explicitly define the line endings with `eol` if the `working-tree-encoding` +attribute is used to avoid ambiguity. + +------------------------ +*.ps1 text working-tree-encoding=UTF-16LE eol=CRLF +------------------------ + +You can get a list of all available encodings on your platform with the +following command: + +------------------------ +iconv --list +------------------------ + +If you do not know the encoding of a file, then you can use the `file` +command to guess the encoding: + +------------------------ +file foo.ps1 +------------------------ + + `ident` ^^^^^^^ @@ -392,46 +487,14 @@ Long Running Filter Process If the filter command (a string value) is defined via `filter.<driver>.process` then Git can process all blobs with a single filter invocation for the entire life of a single Git -command. This is achieved by using a packet format (pkt-line, -see technical/protocol-common.txt) based protocol over standard -input and standard output as follows. All packets, except for the -"*CONTENT" packets and the "0000" flush packet, are considered -text and therefore are terminated by a LF. - -Git starts the filter when it encounters the first file -that needs to be cleaned or smudged. After the filter started -Git sends a welcome message ("git-filter-client"), a list of supported -protocol version numbers, and a flush packet. Git expects to read a welcome -response message ("git-filter-server"), exactly one protocol version number -from the previously sent list, and a flush packet. All further -communication will be based on the selected version. The remaining -protocol description below documents "version=2". Please note that -"version=42" in the example below does not exist and is only there -to illustrate how the protocol would look like with more than one -version. - -After the version negotiation Git sends a list of all capabilities that -it supports and a flush packet. Git expects to read a list of desired -capabilities, which must be a subset of the supported capabilities list, -and a flush packet as response: ------------------------- -packet: git> git-filter-client -packet: git> version=2 -packet: git> version=42 -packet: git> 0000 -packet: git< git-filter-server -packet: git< version=2 -packet: git< 0000 -packet: git> capability=clean -packet: git> capability=smudge -packet: git> capability=not-yet-invented -packet: git> 0000 -packet: git< capability=clean -packet: git< capability=smudge -packet: git< 0000 ------------------------- -Supported filter capabilities in version 2 are "clean", "smudge", -and "delay". +command. This is achieved by using the long-running process protocol +(described in technical/long-running-process-protocol.txt). + +When Git encounters the first file that needs to be cleaned or smudged, +it starts the filter and performs the handshake. In the handshake, the +welcome message sent by Git is "git-filter-client", only version 2 is +suppported, and the supported capabilities are "clean", "smudge", and +"delay". Afterwards Git sends a list of "key=value" pairs terminated with a flush packet. The list will contain at least the filter command @@ -517,12 +580,6 @@ the protocol then Git will stop the filter process and restart it with the next file that needs to be processed. Depending on the `filter.<driver>.required` flag Git will interpret that as error. -After the filter has processed a command it is expected to wait for -a "key=value" list containing the next command. Git will close -the command pipe on exit. The filter is expected to detect EOF -and exit gracefully on its own. Git will wait until the filter -process has stopped. - Delay ^^^^^ @@ -752,6 +809,8 @@ patterns are available: - `fountain` suitable for Fountain documents. +- `golang` suitable for source code in the Go language. + - `html` suitable for HTML/XHTML documents. - `java` suitable for source code in the Java language. @@ -1170,8 +1229,8 @@ to: ------------ -EXAMPLE -------- +EXAMPLES +-------- If you have these three `gitattributes` file: diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt index 9f13266a68..592e06d839 100644 --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -110,8 +110,8 @@ couple of magic command-line options: + --------------------------------------------- $ git describe -h -usage: git describe [options] <commit-ish>* - or: git describe [options] --dirty +usage: git describe [<options>] <commit-ish>* + or: git describe [<options>] --dirty --contains find the tag that comes after the commit --debug debug search strategy on stderr diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index f877f7b7cd..e3c283a174 100644 --- a/Documentation/githooks.txt +++ b/Documentation/githooks.txt @@ -31,7 +31,7 @@ Hooks can get their arguments via the environment, command-line arguments, and stdin. See the documentation for each hook below for details. -'git init' may copy hooks to the new repository, depending on its +`git init` may copy hooks to the new repository, depending on its configuration. See the "TEMPLATE DIRECTORY" section in linkgit:git-init[1] for details. When the rest of this document refers to "default hooks" it's talking about the default template shipped @@ -45,9 +45,9 @@ HOOKS applypatch-msg ~~~~~~~~~~~~~~ -This hook is invoked by 'git am'. It takes a single +This hook is invoked by linkgit:git-am[1]. It takes a single parameter, the name of the file that holds the proposed commit -log message. Exiting with a non-zero status causes 'git am' to abort +log message. Exiting with a non-zero status causes `git am` to abort before applying the patch. The hook is allowed to edit the message file in place, and can @@ -61,7 +61,7 @@ The default 'applypatch-msg' hook, when enabled, runs the pre-applypatch ~~~~~~~~~~~~~~ -This hook is invoked by 'git am'. It takes no parameter, and is +This hook is invoked by linkgit:git-am[1]. It takes no parameter, and is invoked after the patch is applied, but before a commit is made. If it exits with non-zero status, then the working tree will not be @@ -76,33 +76,33 @@ The default 'pre-applypatch' hook, when enabled, runs the post-applypatch ~~~~~~~~~~~~~~~ -This hook is invoked by 'git am'. It takes no parameter, +This hook is invoked by linkgit:git-am[1]. It takes no parameter, and is invoked after the patch is applied and a commit is made. This hook is meant primarily for notification, and cannot affect -the outcome of 'git am'. +the outcome of `git am`. pre-commit ~~~~~~~~~~ -This hook is invoked by 'git commit', and can be bypassed +This hook is invoked by linkgit:git-commit[1], and can be bypassed with the `--no-verify` option. It takes no parameters, and is invoked before obtaining the proposed commit log message and making a commit. Exiting with a non-zero status from this script -causes the 'git commit' command to abort before creating a commit. +causes the `git commit` command to abort before creating a commit. The default 'pre-commit' hook, when enabled, catches introduction of lines with trailing whitespaces and aborts the commit when such a line is found. -All the 'git commit' hooks are invoked with the environment +All the `git commit` hooks are invoked with the environment variable `GIT_EDITOR=:` if the command will not bring up an editor to modify the commit message. prepare-commit-msg ~~~~~~~~~~~~~~~~~~ -This hook is invoked by 'git commit' right after preparing the +This hook is invoked by linkgit:git-commit[1] right after preparing the default log message, and before the editor is started. It takes one to three parameters. The first is the name of the file @@ -114,7 +114,7 @@ commit is a merge or a `.git/MERGE_MSG` file exists); `squash` (if a `.git/SQUASH_MSG` file exists); or `commit`, followed by a commit SHA-1 (if a `-c`, `-C` or `--amend` option was given). -If the exit status is non-zero, 'git commit' will abort. +If the exit status is non-zero, `git commit` will abort. The purpose of the hook is to edit the message file in place, and it is not suppressed by the `--no-verify` option. A non-zero exit @@ -127,7 +127,7 @@ help message found in the commented portion of the commit template. commit-msg ~~~~~~~~~~ -This hook is invoked by 'git commit' and 'git merge', and can be +This hook is invoked by linkgit:git-commit[1] and linkgit:git-merge[1], and can be bypassed with the `--no-verify` option. It takes a single parameter, the name of the file that holds the proposed commit log message. Exiting with a non-zero status causes the command to abort. @@ -143,16 +143,16 @@ The default 'commit-msg' hook, when enabled, detects duplicate post-commit ~~~~~~~~~~~ -This hook is invoked by 'git commit'. It takes no parameters, and is +This hook is invoked by linkgit:git-commit[1]. It takes no parameters, and is invoked after a commit is made. This hook is meant primarily for notification, and cannot affect -the outcome of 'git commit'. +the outcome of `git commit`. pre-rebase ~~~~~~~~~~ -This hook is called by 'git rebase' and can be used to prevent a +This hook is called by linkgit:git-rebase[1] and can be used to prevent a branch from getting rebased. The hook may be called with one or two parameters. The first parameter is the upstream from which the series was forked. The second parameter is the branch being @@ -161,17 +161,17 @@ rebased, and is not set when rebasing the current branch. post-checkout ~~~~~~~~~~~~~ -This hook is invoked when a 'git checkout' is run after having updated the +This hook is invoked when a linkgit:git-checkout[1] is run after having updated the worktree. The hook is given three parameters: the ref of the previous HEAD, the ref of the new HEAD (which may or may not have changed), and a flag indicating whether the checkout was a branch checkout (changing branches, flag=1) or a file checkout (retrieving a file from the index, flag=0). -This hook cannot affect the outcome of 'git checkout'. +This hook cannot affect the outcome of `git checkout`. -It is also run after 'git clone', unless the --no-checkout (-n) option is +It is also run after linkgit:git-clone[1], unless the `--no-checkout` (`-n`) option is used. The first parameter given to the hook is the null-ref, the second the -ref of the new HEAD and the flag is always 1. Likewise for 'git worktree add' -unless --no-checkout is used. +ref of the new HEAD and the flag is always 1. Likewise for `git worktree add` +unless `--no-checkout` is used. This hook can be used to perform repository validity checks, auto-display differences from the previous HEAD if different, or set working dir metadata @@ -180,10 +180,10 @@ properties. post-merge ~~~~~~~~~~ -This hook is invoked by 'git merge', which happens when a 'git pull' +This hook is invoked by linkgit:git-merge[1], which happens when a `git pull` is done on a local repository. The hook takes a single parameter, a status flag specifying whether or not the merge being done was a squash merge. -This hook cannot affect the outcome of 'git merge' and is not executed, +This hook cannot affect the outcome of `git merge` and is not executed, if the merge failed due to conflicts. This hook can be used in conjunction with a corresponding pre-commit hook to @@ -194,10 +194,10 @@ for an example of how to do this. pre-push ~~~~~~~~ -This hook is called by 'git push' and can be used to prevent a push from taking -place. The hook is called with two parameters which provide the name and -location of the destination remote, if a named remote is not being used both -values will be the same. +This hook is called by linkgit:git-push[1] and can be used to prevent +a push from taking place. The hook is called with two parameters +which provide the name and location of the destination remote, if a +named remote is not being used both values will be the same. Information about what is to be pushed is provided on the hook's standard input with lines of the form: @@ -216,7 +216,7 @@ SHA-1>` will be 40 `0`. If the local commit was specified by something other than a name which could be expanded (such as `HEAD~`, or a SHA-1) it will be supplied as it was originally given. -If this hook exits with a non-zero status, 'git push' will abort without +If this hook exits with a non-zero status, `git push` will abort without pushing anything. Information about why the push is rejected may be sent to the user by writing to standard error. @@ -224,8 +224,8 @@ to the user by writing to standard error. pre-receive ~~~~~~~~~~~ -This hook is invoked by 'git-receive-pack' when it reacts to -'git push' and updates reference(s) in its repository. +This hook is invoked by linkgit:git-receive-pack[1] when it reacts to +`git push` and updates reference(s) in its repository. Just before starting to update refs on the remote repository, the pre-receive hook is invoked. Its exit status determines the success or failure of the update. @@ -246,7 +246,7 @@ updated. If the hook exits with zero, updating of individual refs can still be prevented by the <<update,'update'>> hook. Both standard output and standard error output are forwarded to -'git send-pack' on the other end, so you can simply `echo` messages +`git send-pack` on the other end, so you can simply `echo` messages for the user. The number of push options given on the command line of @@ -265,8 +265,8 @@ linkgit:git-receive-pack[1] for some caveats. update ~~~~~~ -This hook is invoked by 'git-receive-pack' when it reacts to -'git push' and updates reference(s) in its repository. +This hook is invoked by linkgit:git-receive-pack[1] when it reacts to +`git push` and updates reference(s) in its repository. Just before updating the ref on the remote repository, the update hook is invoked. Its exit status determines the success or failure of the ref update. @@ -279,7 +279,7 @@ three parameters: - 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' +Exiting with a non-zero status prevents `git receive-pack` from updating that ref. This hook can be used to prevent 'forced' update on certain refs by @@ -299,7 +299,7 @@ membership. See linkgit:git-shell[1] for how you might use the login shell to restrict the user's access to only git commands. Both standard output and standard error output are forwarded to -'git send-pack' on the other end, so you can simply `echo` messages +`git send-pack` on the other end, so you can simply `echo` messages for the user. The default 'update' hook, when enabled--and with @@ -310,8 +310,8 @@ unannotated tags to be pushed. post-receive ~~~~~~~~~~~~ -This hook is invoked by 'git-receive-pack' when it reacts to -'git push' and updates reference(s) in its repository. +This hook is invoked by linkgit:git-receive-pack[1] when it reacts to +`git push` and updates reference(s) in its repository. It executes on the remote repository once after all the refs have been updated. @@ -320,7 +320,7 @@ arguments, but gets the same information as the <<pre-receive,'pre-receive'>> hook does on its standard input. -This hook does not affect the outcome of 'git-receive-pack', as it +This hook does not affect the outcome of `git receive-pack`, as it is called after the real work is done. This supersedes the <<post-update,'post-update'>> hook in that it gets @@ -328,7 +328,7 @@ both old and new values of all the refs in addition to their names. Both standard output and standard error output are forwarded to -'git send-pack' on the other end, so you can simply `echo` messages +`git send-pack` on the other end, so you can simply `echo` messages for the user. The default 'post-receive' hook is empty, but there is @@ -349,8 +349,8 @@ will be set to zero, `GIT_PUSH_OPTION_COUNT=0`. post-update ~~~~~~~~~~~ -This hook is invoked by 'git-receive-pack' when it reacts to -'git push' and updates reference(s) in its repository. +This hook is invoked by linkgit:git-receive-pack[1] when it reacts to +`git push` and updates reference(s) in its repository. It executes on the remote repository once after all the refs have been updated. @@ -358,7 +358,7 @@ It takes a variable number of parameters, each of which is the name of ref that was actually updated. This hook is meant primarily for notification, and cannot affect -the outcome of 'git-receive-pack'. +the outcome of `git receive-pack`. The 'post-update' hook can tell what are the heads that were pushed, but it does not know what their original and updated values are, @@ -368,20 +368,20 @@ updated values of the refs. You might consider it instead if you need them. When enabled, the default 'post-update' hook runs -'git update-server-info' to keep the information used by dumb +`git update-server-info` to keep the information used by dumb transports (e.g., HTTP) up to date. If you are publishing a Git repository that is accessible via HTTP, you should probably enable this hook. Both standard output and standard error output are forwarded to -'git send-pack' on the other end, so you can simply `echo` messages +`git send-pack` on the other end, so you can simply `echo` messages for the user. push-to-checkout ~~~~~~~~~~~~~~~~ -This hook is invoked by 'git-receive-pack' when it reacts to -'git push' and updates reference(s) in its repository, and when +This hook is invoked by linkgit:git-receive-pack[1] when it reacts to +`git push` and updates reference(s) in its repository, and when the push tries to update the branch that is currently checked out and the `receive.denyCurrentBranch` configuration variable is set to `updateInstead`. Such a push by default is refused if the working @@ -400,8 +400,8 @@ when the tip of the current branch is updated to the new commit, and exit with a zero status. For example, the hook can simply run `git read-tree -u -m HEAD "$1"` -in order to emulate 'git fetch' that is run in the reverse direction -with `git push`, as the two-tree form of `read-tree -u -m` is +in order to emulate `git fetch` that is run in the reverse direction +with `git push`, as the two-tree form of `git read-tree -u -m` is essentially the same as `git checkout` that switches branches while keeping the local changes in the working tree that do not interfere with the difference between the branches. @@ -410,15 +410,16 @@ with the difference between the branches. pre-auto-gc ~~~~~~~~~~~ -This hook is invoked by 'git gc --auto'. It takes no parameter, and -exiting with non-zero status from this script causes the 'git gc --auto' -to abort. +This hook is invoked by `git gc --auto` (see linkgit:git-gc[1]). It +takes no parameter, and exiting with non-zero status from this script +causes the `git gc --auto` to abort. post-rewrite ~~~~~~~~~~~~ -This hook is invoked by commands that rewrite commits (`git commit ---amend`, 'git-rebase'; currently 'git-filter-branch' does 'not' call +This hook is invoked by commands that rewrite commits +(linkgit:git-commit[1] when called with `--amend` and +linkgit:git-rebase[1]; currently `git filter-branch` does 'not' call it!). Its first argument denotes the command it was invoked by: currently one of `amend` or `rebase`. Further command-dependent arguments may be passed in the future. @@ -450,16 +451,16 @@ processed by rebase. sendemail-validate ~~~~~~~~~~~~~~~~~~ -This hook is invoked by 'git send-email'. It takes a single parameter, +This hook is invoked by linkgit:git-send-email[1]. It takes a single parameter, the name of the file that holds the e-mail to be sent. Exiting with a -non-zero status causes 'git send-email' to abort before sending any +non-zero status causes `git send-email` to abort before sending any e-mails. fsmonitor-watchman ~~~~~~~~~~~~~~~~~~ -This hook is invoked when the configuration option core.fsmonitor is -set to .git/hooks/fsmonitor-watchman. It takes two arguments, a version +This hook is invoked when the configuration option `core.fsmonitor` is +set to `.git/hooks/fsmonitor-watchman`. It takes two arguments, a version (currently 1) and the time in elapsed nanoseconds since midnight, January 1, 1970. @@ -478,7 +479,7 @@ directories are checked for untracked files based on the path names given. An optimized way to tell git "all files have changed" is to return -the filename '/'. +the filename `/`. The exit status determines whether git will use the data from the hook to limit its search. On error, it will fall back to verifying diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index ca96c281d1..244cd01493 100644 --- a/Documentation/gitk.txt +++ b/Documentation/gitk.txt @@ -8,7 +8,7 @@ gitk - The Git repository browser SYNOPSIS -------- [verse] -'gitk' [<options>] [<revision range>] [\--] [<path>...] +'gitk' [<options>] [<revision range>] [--] [<path>...] DESCRIPTION ----------- diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt index db5d47eb19..4d63def206 100644 --- a/Documentation/gitmodules.txt +++ b/Documentation/gitmodules.txt @@ -3,7 +3,7 @@ gitmodules(5) NAME ---- -gitmodules - defining submodule properties +gitmodules - Defining submodule properties SYNOPSIS -------- diff --git a/Documentation/gitremote-helpers.txt b/Documentation/gitremote-helpers.txt index 4a584f3c5d..9d1459aac6 100644 --- a/Documentation/gitremote-helpers.txt +++ b/Documentation/gitremote-helpers.txt @@ -102,6 +102,14 @@ Capabilities for Pushing + Supported commands: 'connect'. +'stateless-connect':: + Experimental; for internal use only. + Can attempt to connect to a remote server for communication + using git's wire-protocol version 2. See the documentation + for the stateless-connect command for more information. ++ +Supported commands: 'stateless-connect'. + 'push':: Can discover remote refs and push local commits and the history leading up to them to new or existing remote refs. @@ -136,6 +144,14 @@ Capabilities for Fetching + Supported commands: 'connect'. +'stateless-connect':: + Experimental; for internal use only. + Can attempt to connect to a remote server for communication + using git's wire-protocol version 2. See the documentation + for the stateless-connect command for more information. ++ +Supported commands: 'stateless-connect'. + 'fetch':: Can discover remote refs and transfer objects reachable from them to the local object store. @@ -375,6 +391,22 @@ Supported if the helper has the "export" capability. + Supported if the helper has the "connect" capability. +'stateless-connect' <service>:: + Experimental; for internal use only. + Connects to the given remote service for communication using + git's wire-protocol version 2. Valid replies to this command + are empty line (connection established), 'fallback' (no smart + transport support, fall back to dumb transports) and just + exiting with error message printed (can't connect, don't bother + trying to fall back). After line feed terminating the positive + (empty) response, the output of the service starts. Messages + (both request and response) must consist of zero or more + PKT-LINEs, terminating in a flush packet. The client must not + expect the server to store any state in between request-response + pairs. After the connection ends, the remote helper exits. ++ +Supported if the helper has the "stateless-connect" capability. + If a fatal error occurs, the program writes the error message to stderr and exits. The caller should expect that a suitable error message has been printed if the child closes the connection without @@ -466,6 +498,13 @@ set by Git if the remote helper has the 'option' capability. Transmit <string> as a push option. As the push option must not contain LF or NUL characters, the string is not encoded. +'option from-promisor' {'true'|'false'}:: + Indicate that these objects are being fetched from a promisor. + +'option no-dependents' {'true'|'false'}:: + Indicate that only the objects wanted need to be fetched, not + their dependents. + SEE ALSO -------- linkgit:git-remote[1] diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt index c60bcad44a..e85148f05e 100644 --- a/Documentation/gitrepository-layout.txt +++ b/Documentation/gitrepository-layout.txt @@ -275,11 +275,6 @@ worktrees/<id>/locked:: or manually by `git worktree prune`. The file may contain a string explaining why the repository is locked. -worktrees/<id>/link:: - If this file exists, it is a hard link to the linked .git - file. It is used to detect if the linked repository is - manually removed. - SEE ALSO -------- linkgit:git-init[1], diff --git a/Documentation/gitrevisions.txt b/Documentation/gitrevisions.txt index 27dec5b91d..1f6cceaefb 100644 --- a/Documentation/gitrevisions.txt +++ b/Documentation/gitrevisions.txt @@ -3,7 +3,7 @@ gitrevisions(7) NAME ---- -gitrevisions - specifying revisions and ranges for Git +gitrevisions - Specifying revisions and ranges for Git SYNOPSIS -------- diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt index 926e044d09..ca11c7bdaf 100644 --- a/Documentation/gitworkflows.txt +++ b/Documentation/gitworkflows.txt @@ -107,7 +107,7 @@ the unstable branch into the stable one. Hence the following: .Merge upwards [caption="Rule: "] ===================================== -Always commit your fixes to the oldest supported branch that require +Always commit your fixes to the oldest supported branch that requires them. Then (periodically) merge the integration branches upwards into each other. ===================================== diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index 6b8888d123..6c2d23dc48 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -463,7 +463,7 @@ exclude;; [[def_push]]push:: Pushing a <<def_branch,branch>> means to get the branch's <<def_head_ref,head ref>> from a remote <<def_repository,repository>>, - find out if it is a direct ancestor to the branch's local + find out if it is an ancestor to the branch's local head ref, and in that case, putting all objects, which are <<def_reachable,reachable>> from the local head ref, and which are missing from the remote diff --git a/Documentation/howto/recover-corrupted-object-harder.txt b/Documentation/howto/recover-corrupted-object-harder.txt index 9c4cd0915f..8994e2559e 100644 --- a/Documentation/howto/recover-corrupted-object-harder.txt +++ b/Documentation/howto/recover-corrupted-object-harder.txt @@ -80,7 +80,7 @@ valid pack like: # now add our object data cat object >>tmp.pack # and then append the pack trailer - /path/to/git.git/test-sha1 -b <tmp.pack >trailer + /path/to/git.git/t/helper/test-tool sha1 -b <tmp.pack >trailer cat trailer >>tmp.pack ------------ diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt index 12b6bbf591..662c2713ca 100644 --- a/Documentation/merge-config.txt +++ b/Documentation/merge-config.txt @@ -35,7 +35,13 @@ include::fmt-merge-msg-config.txt[] merge.renameLimit:: The number of files to consider when performing rename detection during a merge; if not specified, defaults to the value of - diff.renameLimit. + diff.renameLimit. This setting has no effect if rename detection + is turned off. + +merge.renames:: + Whether and how Git detects renames. If set to "false", + rename detection is disabled. If set to "true", basic rename + detection is enabled. Defaults to the value of diff.renames. merge.renormalize:: Tell Git that canonical representation of files in the diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index 3888c3ff85..63a3fc0954 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -35,7 +35,8 @@ set to `no` at the beginning of them. --no-ff:: Create a merge commit even when the merge resolves as a fast-forward. This is the default behaviour when merging an - annotated (and possibly signed) tag. + annotated (and possibly signed) tag that is not stored in + its natural place in 'refs/tags/' hierarchy. --ff-only:: Refuse to merge and exit with a non-zero status unless the diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index fd5d748d1b..aa66cbe41e 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -23,8 +23,9 @@ recursive:: 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 - pulling or merging one branch. + renames, but currently cannot make use of detected + copies. This is the default merge strategy when pulling + or merging one branch. + The 'recursive' strategy can take the following options: @@ -40,7 +41,7 @@ the other tree did, declaring 'our' history contains all that happened in it. theirs;; This is the opposite of 'ours'; note that, unlike 'ours', there is - no 'theirs' merge stragegy to confuse this merge option with. + no 'theirs' merge strategy to confuse this merge option with. patience;; With this option, 'merge-recursive' spends a little extra time @@ -84,12 +85,14 @@ no-renormalize;; `merge.renormalize` configuration variable. no-renames;; - Turn off rename detection. + Turn off rename detection. This overrides the `merge.renames` + configuration variable. See also linkgit:git-diff[1] `--no-renames`. find-renames[=<n>];; Turn on rename detection, optionally setting the similarity - threshold. This is the default. + threshold. This is the default. This overrides the + 'merge.renames' configuration variable. See also linkgit:git-diff[1] `--find-renames`. rename-threshold=<n>;; diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt index e664c088a5..6109ef09aa 100644 --- a/Documentation/pretty-formats.txt +++ b/Documentation/pretty-formats.txt @@ -202,7 +202,7 @@ endif::git-rev-list[] - '%>>(<N>)', '%>>|(<N>)': similar to '%>(<N>)', '%>|(<N>)' respectively, except that if the next placeholder takes more spaces than given and there are spaces on its left, use those spaces -- '%><(<N>)', '%><|(<N>)': similar to '% <(<N>)', '%<|(<N>)' +- '%><(<N>)', '%><|(<N>)': similar to '%<(<N>)', '%<|(<N>)' respectively, but padding both sides (i.e. the text is centered) - %(trailers[:options]): display the trailers of the body as interpreted by linkgit:git-interpret-trailers[1]. The `trailers` string may be diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 22f5c9b43d..7b273635de 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -750,10 +750,21 @@ The form '--missing=allow-any' will allow object traversal to continue if a missing object is encountered. Missing objects will silently be omitted from the results. + +The form '--missing=allow-promisor' is like 'allow-any', but will only +allow object traversal to continue for EXPECTED promisor missing objects. +Unexpected missing objects will raise an error. ++ The form '--missing=print' is like 'allow-any', but will also print a list of the missing objects. Object IDs are prefixed with a ``?'' character. endif::git-rev-list[] +--exclude-promisor-objects:: + (For internal use only.) Prefilter object traversal at + promisor boundary. This is used with partial clone. This is + stronger than `--missing=allow-promisor` because it limits the + traversal, rather than just silencing errors about missing + objects. + --no-walk[=(sorted|unsorted)]:: Only show the given commits, but do not traverse their ancestors. This has no effect if a range is specified. If the argument diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt index dfcc49c72c..7d1bd44094 100644 --- a/Documentation/revisions.txt +++ b/Documentation/revisions.txt @@ -7,6 +7,10 @@ syntax. Here are various ways to spell object names. The ones listed near the end of this list name trees and blobs contained in a commit. +NOTE: This document shows the "raw" syntax as seen by git. The shell +and other UIs might require additional quoting to protect special +characters and to avoid word splitting. + '<sha1>', e.g. 'dae86e1950b1277e545cee180551750029cfe735', 'dae86e':: The full SHA-1 object name (40-byte hexadecimal string), or a leading substring that is unique within the repository. @@ -186,6 +190,8 @@ existing tag object. is matched. ':/!-foo' performs a negative match, while ':/!!foo' matches a literal '!' character, followed by 'foo'. Any other sequence beginning with ':/!' is reserved for now. + Depending on the given text, the shell's word splitting rules might + require additional quoting. '<rev>:<path>', e.g. 'HEAD:README', ':README', 'master:./README':: A suffix ':' followed by a path names the blob or tree @@ -345,6 +351,7 @@ Here are a handful of examples using the Loeliger illustration above, with each step in the notation's expansion and selection carefully spelt out: +.... Args Expanded arguments Selected commits D G H D D F G H I J D F @@ -367,3 +374,4 @@ spelt out: = B ^B^1 ^B^2 ^B^3 = B ^D ^E ^F B F^! D = F ^I ^J D G H D F +.... diff --git a/Documentation/technical/api-config.txt b/Documentation/technical/api-config.txt index 9a778b0cad..fa39ac9d71 100644 --- a/Documentation/technical/api-config.txt +++ b/Documentation/technical/api-config.txt @@ -47,21 +47,23 @@ will first feed the user-wide one to the callback, and then the repo-specific one; by overwriting, the higher-priority repo-specific value is left at the end). -The `git_config_with_options` function lets the caller examine config +The `config_with_options` function lets the caller examine config while adjusting some of the default behavior of `git_config`. It should almost never be used by "regular" Git code that is looking up configuration variables. It is intended for advanced callers like `git-config`, which are intentionally tweaking the normal config-lookup process. It takes two extra parameters: -`filename`:: -If this parameter is non-NULL, it specifies the name of a file to -parse for configuration, rather than looking in the usual files. Regular -`git_config` defaults to `NULL`. +`config_source`:: +If this parameter is non-NULL, it specifies the source to parse for +configuration, rather than looking in the usual files. See `struct +git_config_source` in `config.h` for details. Regular `git_config` defaults +to `NULL`. -`respect_includes`:: -Specify whether include directives should be followed in parsed files. -Regular `git_config` defaults to `1`. +`opts`:: +Specify options to adjust the behavior of parsing config files. See `struct +config_options` in `config.h` for details. As an example: regular `git_config` +sets `opts.respect_includes` to `1` by default. Reading Specific Files ---------------------- diff --git a/Documentation/technical/api-directory-listing.txt b/Documentation/technical/api-directory-listing.txt index 7fae00f44f..4f44ca24f6 100644 --- a/Documentation/technical/api-directory-listing.txt +++ b/Documentation/technical/api-directory-listing.txt @@ -53,7 +53,7 @@ The notable options are: not be returned even if all of its contents are ignored. In this case, the contents are returned as individual entries. + -If this is set, files and directories that explicity match an ignore +If this is set, files and directories that explicitly match an ignore pattern are reported. Implicity ignored directories (directories that do not match an ignore pattern, but whose contents are all ignored) are not reported, instead all of the contents are reported. diff --git a/Documentation/technical/api-object-access.txt b/Documentation/technical/api-object-access.txt index 03bb0e950d..5b29622d00 100644 --- a/Documentation/technical/api-object-access.txt +++ b/Documentation/technical/api-object-access.txt @@ -1,13 +1,13 @@ object access API ================= -Talk about <sha1_file.c> and <object.h> family, things like +Talk about <sha1-file.c> and <object.h> family, things like * read_sha1_file() * read_object_with_reference() * has_sha1_file() * write_sha1_file() -* pretend_sha1_file() +* pretend_object_file() * lookup_{object,commit,tag,blob,tree} * parse_{object,commit,tag,blob,tree} * Use of object flags diff --git a/Documentation/technical/api-oid-array.txt b/Documentation/technical/api-oid-array.txt index b0c11f868d..9febfb1d52 100644 --- a/Documentation/technical/api-oid-array.txt +++ b/Documentation/technical/api-oid-array.txt @@ -35,13 +35,18 @@ Functions Free all memory associated with the array and return it to the initial, empty state. +`oid_array_for_each`:: + Iterate over each element of the list, executing the callback + function for each one. Does not sort the list, so any custom + hash order is retained. If the callback returns a non-zero + value, the iteration ends immediately and the callback's + return is propagated; otherwise, 0 is returned. + `oid_array_for_each_unique`:: - Efficiently iterate over each unique element of the list, - executing the callback function for each one. If the array is - not sorted, this function has the side effect of sorting it. If - the callback returns a non-zero value, the iteration ends - immediately and the callback's return is propagated; otherwise, - 0 is returned. + Iterate over each unique element of the list in sorted order, + but otherwise behave like `oid_array_for_each`. If the array + is not sorted, this function has the side effect of sorting + it. Examples -------- diff --git a/Documentation/technical/api-submodule-config.txt b/Documentation/technical/api-submodule-config.txt index ee907c4a82..fb06089393 100644 --- a/Documentation/technical/api-submodule-config.txt +++ b/Documentation/technical/api-submodule-config.txt @@ -38,7 +38,7 @@ Data Structures Functions --------- -`void submodule_free()`:: +`void submodule_free(struct repository *r)`:: Use these to free the internally cached values. diff --git a/Documentation/technical/commit-graph-format.txt b/Documentation/technical/commit-graph-format.txt new file mode 100644 index 0000000000..ad6af8105c --- /dev/null +++ b/Documentation/technical/commit-graph-format.txt @@ -0,0 +1,97 @@ +Git commit graph format +======================= + +The Git commit graph stores a list of commit OIDs and some associated +metadata, including: + +- The generation number of the commit. Commits with no parents have + generation number 1; commits with parents have generation number + one more than the maximum generation number of its parents. We + reserve zero as special, and can be used to mark a generation + number invalid or as "not computed". + +- The root tree OID. + +- The commit date. + +- The parents of the commit, stored using positional references within + the graph file. + +These positional references are stored as unsigned 32-bit integers +corresponding to the array position withing the list of commit OIDs. We +use the most-significant bit for special purposes, so we can store at most +(1 << 31) - 1 (around 2 billion) commits. + +== Commit graph files have the following format: + +In order to allow extensions that add extra data to the graph, we organize +the body into "chunks" and provide a binary lookup table at the beginning +of the body. The header includes certain values, such as number of chunks +and hash type. + +All 4-byte numbers are in network order. + +HEADER: + + 4-byte signature: + The signature is: {'C', 'G', 'P', 'H'} + + 1-byte version number: + Currently, the only valid version is 1. + + 1-byte Hash Version (1 = SHA-1) + We infer the hash length (H) from this value. + + 1-byte number (C) of "chunks" + + 1-byte (reserved for later use) + Current clients should ignore this value. + +CHUNK LOOKUP: + + (C + 1) * 12 bytes listing the table of contents for the chunks: + First 4 bytes describe the chunk id. Value 0 is a terminating label. + Other 8 bytes provide the byte-offset in current file for chunk to + start. (Chunks are ordered contiguously in the file, so you can infer + the length using the next chunk position if necessary.) Each chunk + ID appears at most once. + + The remaining data in the body is described one chunk at a time, and + these chunks may be given in any order. Chunks are required unless + otherwise specified. + +CHUNK DATA: + + OID Fanout (ID: {'O', 'I', 'D', 'F'}) (256 * 4 bytes) + The ith entry, F[i], stores the number of OIDs with first + byte at most i. Thus F[255] stores the total + number of commits (N). + + OID Lookup (ID: {'O', 'I', 'D', 'L'}) (N * H bytes) + The OIDs for all commits in the graph, sorted in ascending order. + + Commit Data (ID: {'C', 'G', 'E', 'T' }) (N * (H + 16) bytes) + * The first H bytes are for the OID of the root tree. + * The next 8 bytes are for the positions of the first two parents + of the ith commit. Stores value 0xffffffff if no parent in that + position. If there are more than two parents, the second value + has its most-significant bit on and the other bits store an array + position into the Large Edge List chunk. + * The next 8 bytes store the generation number of the commit and + the commit time in seconds since EPOCH. The generation number + uses the higher 30 bits of the first 4 bytes, while the commit + time uses the 32 bits of the second 4 bytes, along with the lowest + 2 bits of the lowest byte, storing the 33rd and 34th bit of the + commit time. + + Large Edge List (ID: {'E', 'D', 'G', 'E'}) [Optional] + This list of 4-byte values store the second through nth parents for + all octopus merges. The second parent value in the commit data stores + an array position within this list along with the most-significant bit + on. Starting at that array position, iterate through this list of commit + positions for the parents until reaching a value with the most-significant + bit on. The other bits correspond to the position of the last parent. + +TRAILER: + + H-byte HASH-checksum of all of the above. diff --git a/Documentation/technical/commit-graph.txt b/Documentation/technical/commit-graph.txt new file mode 100644 index 0000000000..e1a883eb46 --- /dev/null +++ b/Documentation/technical/commit-graph.txt @@ -0,0 +1,182 @@ +Git Commit Graph Design Notes +============================= + +Git walks the commit graph for many reasons, including: + +1. Listing and filtering commit history. +2. Computing merge bases. + +These operations can become slow as the commit count grows. The merge +base calculation shows up in many user-facing commands, such as 'merge-base' +or 'status' and can take minutes to compute depending on history shape. + +There are two main costs here: + +1. Decompressing and parsing commits. +2. Walking the entire graph to satisfy topological order constraints. + +The commit graph file is a supplemental data structure that accelerates +commit graph walks. If a user downgrades or disables the 'core.commitGraph' +config setting, then the existing ODB is sufficient. The file is stored +as "commit-graph" either in the .git/objects/info directory or in the info +directory of an alternate. + +The commit graph file stores the commit graph structure along with some +extra metadata to speed up graph walks. By listing commit OIDs in lexi- +cographic order, we can identify an integer position for each commit and +refer to the parents of a commit using those integer positions. We use +binary search to find initial commits and then use the integer positions +for fast lookups during the walk. + +A consumer may load the following info for a commit from the graph: + +1. The commit OID. +2. The list of parents, along with their integer position. +3. The commit date. +4. The root tree OID. +5. The generation number (see definition below). + +Values 1-4 satisfy the requirements of parse_commit_gently(). + +Define the "generation number" of a commit recursively as follows: + + * A commit with no parents (a root commit) has generation number one. + + * A commit with at least one parent has generation number one more than + the largest generation number among its parents. + +Equivalently, the generation number of a commit A is one more than the +length of a longest path from A to a root commit. The recursive definition +is easier to use for computation and observing the following property: + + If A and B are commits with generation numbers N and M, respectively, + and N <= M, then A cannot reach B. That is, we know without searching + that B is not an ancestor of A because it is further from a root commit + than A. + + Conversely, when checking if A is an ancestor of B, then we only need + to walk commits until all commits on the walk boundary have generation + number at most N. If we walk commits using a priority queue seeded by + generation numbers, then we always expand the boundary commit with highest + generation number and can easily detect the stopping condition. + +This property can be used to significantly reduce the time it takes to +walk commits and determine topological relationships. Without generation +numbers, the general heuristic is the following: + + If A and B are commits with commit time X and Y, respectively, and + X < Y, then A _probably_ cannot reach B. + +This heuristic is currently used whenever the computation is allowed to +violate topological relationships due to clock skew (such as "git log" +with default order), but is not used when the topological order is +required (such as merge base calculations, "git log --graph"). + +In practice, we expect some commits to be created recently and not stored +in the commit graph. We can treat these commits as having "infinite" +generation number and walk until reaching commits with known generation +number. + +We use the macro GENERATION_NUMBER_INFINITY = 0xFFFFFFFF to mark commits not +in the commit-graph file. If a commit-graph file was written by a version +of Git that did not compute generation numbers, then those commits will +have generation number represented by the macro GENERATION_NUMBER_ZERO = 0. + +Since the commit-graph file is closed under reachability, we can guarantee +the following weaker condition on all commits: + + If A and B are commits with generation numbers N amd M, respectively, + and N < M, then A cannot reach B. + +Note how the strict inequality differs from the inequality when we have +fully-computed generation numbers. Using strict inequality may result in +walking a few extra commits, but the simplicity in dealing with commits +with generation number *_INFINITY or *_ZERO is valuable. + +We use the macro GENERATION_NUMBER_MAX = 0x3FFFFFFF to for commits whose +generation numbers are computed to be at least this value. We limit at +this value since it is the largest value that can be stored in the +commit-graph file using the 30 bits available to generation numbers. This +presents another case where a commit can have generation number equal to +that of a parent. + +Design Details +-------------- + +- The commit graph file is stored in a file named 'commit-graph' in the + .git/objects/info directory. This could be stored in the info directory + of an alternate. + +- The core.commitGraph config setting must be on to consume graph files. + +- The file format includes parameters for the object ID hash function, + so a future change of hash algorithm does not require a change in format. + +Future Work +----------- + +- The commit graph feature currently does not honor commit grafts. This can + be remedied by duplicating or refactoring the current graft logic. + +- The 'commit-graph' subcommand does not have a "verify" mode that is + necessary for integration with fsck. + +- After computing and storing generation numbers, we must make graph + walks aware of generation numbers to gain the performance benefits they + enable. This will mostly be accomplished by swapping a commit-date-ordered + priority queue with one ordered by generation number. The following + operations are important candidates: + + - 'log --topo-order' + - 'tag --merged' + +- Currently, parse_commit_gently() requires filling in the root tree + object for a commit. This passes through lookup_tree() and consequently + lookup_object(). Also, it calls lookup_commit() when loading the parents. + These method calls check the ODB for object existence, even if the + consumer does not need the content. For example, we do not need the + tree contents when computing merge bases. Now that commit parsing is + removed from the computation time, these lookup operations are the + slowest operations keeping graph walks from being fast. Consider + loading these objects without verifying their existence in the ODB and + only loading them fully when consumers need them. Consider a method + such as "ensure_tree_loaded(commit)" that fully loads a tree before + using commit->tree. + +- The current design uses the 'commit-graph' subcommand to generate the graph. + When this feature stabilizes enough to recommend to most users, we should + add automatic graph writes to common operations that create many commits. + For example, one could compute a graph on 'clone', 'fetch', or 'repack' + commands. + +- A server could provide a commit graph file as part of the network protocol + to avoid extra calculations by clients. This feature is only of benefit if + the user is willing to trust the file, because verifying the file is correct + is as hard as computing it from scratch. + +Related Links +------------- +[0] https://bugs.chromium.org/p/git/issues/detail?id=8 + Chromium work item for: Serialized Commit Graph + +[1] https://public-inbox.org/git/20110713070517.GC18566@sigill.intra.peff.net/ + An abandoned patch that introduced generation numbers. + +[2] https://public-inbox.org/git/20170908033403.q7e6dj7benasrjes@sigill.intra.peff.net/ + Discussion about generation numbers on commits and how they interact + with fsck. + +[3] https://public-inbox.org/git/20170908034739.4op3w4f2ma5s65ku@sigill.intra.peff.net/ + More discussion about generation numbers and not storing them inside + commit objects. A valuable quote: + + "I think we should be moving more in the direction of keeping + repo-local caches for optimizations. Reachability bitmaps have been + a big performance win. I think we should be doing the same with our + properties of commits. Not just generation numbers, but making it + cheap to access the graph structure without zlib-inflating whole + commit objects (i.e., packv4 or something like the "metapacks" I + proposed a few years ago)." + +[4] https://public-inbox.org/git/20180108154822.54829-1-git@jeffhostetler.com/T/#u + A patch to remove the ahead-behind calculation from 'status'. diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt index 417ba491d0..4ab6cd1012 100644 --- a/Documentation/technical/hash-function-transition.txt +++ b/Documentation/technical/hash-function-transition.txt @@ -28,11 +28,30 @@ advantages: address stored content. Over time some flaws in SHA-1 have been discovered by security -researchers. https://shattered.io demonstrated a practical SHA-1 hash -collision. As a result, SHA-1 cannot be considered cryptographically -secure any more. This impacts the communication of hash values because -we cannot trust that a given hash value represents the known good -version of content that the speaker intended. +researchers. On 23 February 2017 the SHAttered attack +(https://shattered.io) demonstrated a practical SHA-1 hash collision. + +Git v2.13.0 and later subsequently moved to a hardened SHA-1 +implementation by default, which isn't vulnerable to the SHAttered +attack. + +Thus Git has in effect already migrated to a new hash that isn't SHA-1 +and doesn't share its vulnerabilities, its new hash function just +happens to produce exactly the same output for all known inputs, +except two PDFs published by the SHAttered researchers, and the new +implementation (written by those researchers) claims to detect future +cryptanalytic collision attacks. + +Regardless, it's considered prudent to move past any variant of SHA-1 +to a new hash. There's no guarantee that future attacks on SHA-1 won't +be published in the future, and those attacks may not have viable +mitigations. + +If SHA-1 and its variants were to be truly broken, Git's hash function +could not be considered cryptographically secure any more. This would +impact the communication of hash values because we could not trust +that a given hash value represented the known good version of content +that the speaker intended. SHA-1 still possesses the other properties such as fast object lookup and safe error checking, but other hash functions are equally suitable @@ -116,10 +135,15 @@ Documentation/technical/repository-version.txt) with extensions objectFormat = newhash compatObjectFormat = sha1 -Specifying a repository format extension ensures that versions of Git -not aware of NewHash do not try to operate on these repositories, -instead producing an error message: +The combination of setting `core.repositoryFormatVersion=1` and +populating `extensions.*` ensures that all versions of Git later than +`v0.99.9l` will die instead of trying to operate on the NewHash +repository, instead producing an error message. + # Between v0.99.9l and v2.7.0 + $ git status + fatal: Expected git repo version <= 0, found 1 + # After v2.7.0 $ git status fatal: unknown repository extensions found: objectformat diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt index a0e45f2889..64f49d0bbb 100644 --- a/Documentation/technical/http-protocol.txt +++ b/Documentation/technical/http-protocol.txt @@ -214,10 +214,12 @@ smart server reply: S: Cache-Control: no-cache S: S: 001e# service=git-upload-pack\n + S: 0000 S: 004895dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\0multi_ack\n S: 0042d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\n S: 003c2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0\n S: 003fa3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}\n + S: 0000 The client may send Extra Parameters (see Documentation/technical/pack-protocol.txt) as a colon-separated string @@ -277,6 +279,7 @@ The returned response contains "version 1" if "version=1" was sent as an Extra Parameter. smart_reply = PKT-LINE("# service=$servicename" LF) + "0000" *1("version 1") ref_list "0000" diff --git a/Documentation/technical/long-running-process-protocol.txt b/Documentation/technical/long-running-process-protocol.txt new file mode 100644 index 0000000000..aa0aa9af1c --- /dev/null +++ b/Documentation/technical/long-running-process-protocol.txt @@ -0,0 +1,50 @@ +Long-running process protocol +============================= + +This protocol is used when Git needs to communicate with an external +process throughout the entire life of a single Git command. All +communication is in pkt-line format (see technical/protocol-common.txt) +over standard input and standard output. + +Handshake +--------- + +Git starts by sending a welcome message (for example, +"git-filter-client"), a list of supported protocol version numbers, and +a flush packet. Git expects to read the welcome message with "server" +instead of "client" (for example, "git-filter-server"), exactly one +protocol version number from the previously sent list, and a flush +packet. All further communication will be based on the selected version. +The remaining protocol description below documents "version=2". Please +note that "version=42" in the example below does not exist and is only +there to illustrate how the protocol would look like with more than one +version. + +After the version negotiation Git sends a list of all capabilities that +it supports and a flush packet. Git expects to read a list of desired +capabilities, which must be a subset of the supported capabilities list, +and a flush packet as response: +------------------------ +packet: git> git-filter-client +packet: git> version=2 +packet: git> version=42 +packet: git> 0000 +packet: git< git-filter-server +packet: git< version=2 +packet: git< 0000 +packet: git> capability=clean +packet: git> capability=smudge +packet: git> capability=not-yet-invented +packet: git> 0000 +packet: git< capability=clean +packet: git< capability=smudge +packet: git< 0000 +------------------------ + +Shutdown +-------- + +Git will close +the command pipe on exit. The filter is expected to detect EOF +and exit gracefully on its own. Git will wait until the filter +process has stopped. diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt index 8e5bf60be3..70a99fd142 100644 --- a/Documentation/technical/pack-format.txt +++ b/Documentation/technical/pack-format.txt @@ -36,6 +36,98 @@ Git pack format - The trailer records 20-byte SHA-1 checksum of all of the above. +=== Object types + +Valid object types are: + +- OBJ_COMMIT (1) +- OBJ_TREE (2) +- OBJ_BLOB (3) +- OBJ_TAG (4) +- OBJ_OFS_DELTA (6) +- OBJ_REF_DELTA (7) + +Type 5 is reserved for future expansion. Type 0 is invalid. + +=== Deltified representation + +Conceptually there are only four object types: commit, tree, tag and +blob. However to save space, an object could be stored as a "delta" of +another "base" object. These representations are assigned new types +ofs-delta and ref-delta, which is only valid in a pack file. + +Both ofs-delta and ref-delta store the "delta" to be applied to +another object (called 'base object') to reconstruct the object. The +difference between them is, ref-delta directly encodes 20-byte base +object name. If the base object is in the same pack, ofs-delta encodes +the offset of the base object in the pack instead. + +The base object could also be deltified if it's in the same pack. +Ref-delta can also refer to an object outside the pack (i.e. the +so-called "thin pack"). When stored on disk however, the pack should +be self contained to avoid cyclic dependency. + +The delta data is a sequence of instructions to reconstruct an object +from the base object. If the base object is deltified, it must be +converted to canonical form first. Each instruction appends more and +more data to the target object until it's complete. There are two +supported instructions so far: one for copy a byte range from the +source object and one for inserting new data embedded in the +instruction itself. + +Each instruction has variable length. Instruction type is determined +by the seventh bit of the first octet. The following diagrams follow +the convention in RFC 1951 (Deflate compressed data format). + +==== Instruction to copy from base object + + +----------+---------+---------+---------+---------+-------+-------+-------+ + | 1xxxxxxx | offset1 | offset2 | offset3 | offset4 | size1 | size2 | size3 | + +----------+---------+---------+---------+---------+-------+-------+-------+ + +This is the instruction format to copy a byte range from the source +object. It encodes the offset to copy from and the number of bytes to +copy. Offset and size are in little-endian order. + +All offset and size bytes are optional. This is to reduce the +instruction size when encoding small offsets or sizes. The first seven +bits in the first octet determines which of the next seven octets is +present. If bit zero is set, offset1 is present. If bit one is set +offset2 is present and so on. + +Note that a more compact instruction does not change offset and size +encoding. For example, if only offset2 is omitted like below, offset3 +still contains bits 16-23. It does not become offset2 and contains +bits 8-15 even if it's right next to offset1. + + +----------+---------+---------+ + | 10000101 | offset1 | offset3 | + +----------+---------+---------+ + +In its most compact form, this instruction only takes up one byte +(0x80) with both offset and size omitted, which will have default +values zero. There is another exception: size zero is automatically +converted to 0x10000. + +==== Instruction to add new data + + +----------+============+ + | 0xxxxxxx | data | + +----------+============+ + +This is the instruction to construct target object without the base +object. The following data is appended to the target object. The first +seven bits of the first octet determines the size of data in +bytes. The size must be non-zero. + +==== Reserved instruction + + +----------+============ + | 00000000 | + +----------+============ + +This is the instruction reserved for future expansion. + == Original (version 1) pack-*.idx files have the following format: - The header consists of 256 4-byte network byte order diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index cd31edc91e..7fee6b780a 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -241,6 +241,7 @@ out of what the server said it could do with the first 'want' line. upload-request = want-list *shallow-line *1depth-request + [filter-request] flush-pkt want-list = first-want @@ -256,6 +257,8 @@ out of what the server said it could do with the first 'want' line. additional-want = PKT-LINE("want" SP obj-id) depth = 1*DIGIT + + filter-request = PKT-LINE("filter" SP filter-spec) ---- Clients MUST send all the obj-ids it wants from the reference @@ -278,6 +281,11 @@ complete those commits. Commits whose parents are not received as a result are defined as shallow and marked as such in the server. This information is sent back to the client in the next step. +The client can optionally request that pack-objects omit various +objects from the packfile using one of several filtering techniques. +These are intended for use with partial clone and partial fetch +operations. See `rev-list` for possible "filter-spec" values. + Once all the 'want's and 'shallow's (and optional 'deepen') are transferred, clients MUST send a flush-pkt, to tell the server side that it is done sending the list. diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index 26dcc6f502..332d209b58 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -309,3 +309,11 @@ to accept a signed push certificate, and asks the <nonce> to be included in the push certificate. A send-pack client MUST NOT send a push-cert packet unless the receive-pack server advertises this capability. + +filter +------ + +If the upload-pack server advertises the 'filter' capability, +fetch-pack may send "filter" commands to request a partial clone +or partial fetch and request that the server omit various objects +from the packfile. diff --git a/Documentation/technical/protocol-v2.txt b/Documentation/technical/protocol-v2.txt new file mode 100644 index 0000000000..49bda76d23 --- /dev/null +++ b/Documentation/technical/protocol-v2.txt @@ -0,0 +1,414 @@ + Git Wire Protocol, Version 2 +============================== + +This document presents a specification for a version 2 of Git's wire +protocol. Protocol v2 will improve upon v1 in the following ways: + + * Instead of multiple service names, multiple commands will be + supported by a single service + * Easily extendable as capabilities are moved into their own section + of the protocol, no longer being hidden behind a NUL byte and + limited by the size of a pkt-line + * Separate out other information hidden behind NUL bytes (e.g. agent + string as a capability and symrefs can be requested using 'ls-refs') + * Reference advertisement will be omitted unless explicitly requested + * ls-refs command to explicitly request some refs + * Designed with http and stateless-rpc in mind. With clear flush + semantics the http remote helper can simply act as a proxy + +In protocol v2 communication is command oriented. When first contacting a +server a list of capabilities will advertised. Some of these capabilities +will be commands which a client can request be executed. Once a command +has completed, a client can reuse the connection and request that other +commands be executed. + + Packet-Line Framing +--------------------- + +All communication is done using packet-line framing, just as in v1. See +`Documentation/technical/pack-protocol.txt` and +`Documentation/technical/protocol-common.txt` for more information. + +In protocol v2 these special packets will have the following semantics: + + * '0000' Flush Packet (flush-pkt) - indicates the end of a message + * '0001' Delimiter Packet (delim-pkt) - separates sections of a message + + Initial Client Request +------------------------ + +In general a client can request to speak protocol v2 by sending +`version=2` through the respective side-channel for the transport being +used which inevitably sets `GIT_PROTOCOL`. More information can be +found in `pack-protocol.txt` and `http-protocol.txt`. In all cases the +response from the server is the capability advertisement. + + Git Transport +~~~~~~~~~~~~~~~ + +When using the git:// transport, you can request to use protocol v2 by +sending "version=2" as an extra parameter: + + 003egit-upload-pack /project.git\0host=myserver.com\0\0version=2\0 + + SSH and File Transport +~~~~~~~~~~~~~~~~~~~~~~~~ + +When using either the ssh:// or file:// transport, the GIT_PROTOCOL +environment variable must be set explicitly to include "version=2". + + HTTP Transport +~~~~~~~~~~~~~~~~ + +When using the http:// or https:// transport a client makes a "smart" +info/refs request as described in `http-protocol.txt` and requests that +v2 be used by supplying "version=2" in the `Git-Protocol` header. + + C: Git-Protocol: version=2 + C: + C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0 + +A v2 server would reply: + + S: 200 OK + S: <Some headers> + S: ... + S: + S: 000eversion 2\n + S: <capability-advertisement> + +Subsequent requests are then made directly to the service +`$GIT_URL/git-upload-pack`. (This works the same for git-receive-pack). + + Capability Advertisement +-------------------------- + +A server which decides to communicate (based on a request from a client) +using protocol version 2, notifies the client by sending a version string +in its initial response followed by an advertisement of its capabilities. +Each capability is a key with an optional value. Clients must ignore all +unknown keys. Semantics of unknown values are left to the definition of +each key. Some capabilities will describe commands which can be requested +to be executed by the client. + + capability-advertisement = protocol-version + capability-list + flush-pkt + + protocol-version = PKT-LINE("version 2" LF) + capability-list = *capability + capability = PKT-LINE(key[=value] LF) + + key = 1*(ALPHA | DIGIT | "-_") + value = 1*(ALPHA | DIGIT | " -_.,?\/{}[]()<>!@#$%^&*+=:;") + + Command Request +----------------- + +After receiving the capability advertisement, a client can then issue a +request to select the command it wants with any particular capabilities +or arguments. There is then an optional section where the client can +provide any command specific parameters or queries. Only a single +command can be requested at a time. + + request = empty-request | command-request + empty-request = flush-pkt + command-request = command + capability-list + [command-args] + flush-pkt + command = PKT-LINE("command=" key LF) + command-args = delim-pkt + *command-specific-arg + + command-specific-args are packet line framed arguments defined by + each individual command. + +The server will then check to ensure that the client's request is +comprised of a valid command as well as valid capabilities which were +advertised. If the request is valid the server will then execute the +command. A server MUST wait till it has received the client's entire +request before issuing a response. The format of the response is +determined by the command being executed, but in all cases a flush-pkt +indicates the end of the response. + +When a command has finished, and the client has received the entire +response from the server, a client can either request that another +command be executed or can terminate the connection. A client may +optionally send an empty request consisting of just a flush-pkt to +indicate that no more requests will be made. + + Capabilities +-------------- + +There are two different types of capabilities: normal capabilities, +which can be used to to convey information or alter the behavior of a +request, and commands, which are the core actions that a client wants to +perform (fetch, push, etc). + +Protocol version 2 is stateless by default. This means that all commands +must only last a single round and be stateless from the perspective of the +server side, unless the client has requested a capability indicating that +state should be maintained by the server. Clients MUST NOT require state +management on the server side in order to function correctly. This +permits simple round-robin load-balancing on the server side, without +needing to worry about state management. + + agent +~~~~~~~ + +The server can advertise the `agent` capability with a value `X` (in the +form `agent=X`) to notify the client that the server is running version +`X`. The client may optionally send its own agent string by including +the `agent` capability with a value `Y` (in the form `agent=Y`) in its +request to the server (but it MUST NOT do so if the server did not +advertise the agent capability). The `X` and `Y` strings may contain any +printable ASCII characters except space (i.e., the byte range 32 < x < +127), and are typically of the form "package/version" (e.g., +"git/1.8.3.1"). The agent strings are purely informative for statistics +and debugging purposes, and MUST NOT be used to programmatically assume +the presence or absence of particular features. + + ls-refs +~~~~~~~~~ + +`ls-refs` is the command used to request a reference advertisement in v2. +Unlike the current reference advertisement, ls-refs takes in arguments +which can be used to limit the refs sent from the server. + +Additional features not supported in the base command will be advertised +as the value of the command in the capability advertisement in the form +of a space separated list of features: "<command>=<feature 1> <feature 2>" + +ls-refs takes in the following arguments: + + symrefs + In addition to the object pointed by it, show the underlying ref + pointed by it when showing a symbolic ref. + peel + Show peeled tags. + ref-prefix <prefix> + When specified, only references having a prefix matching one of + the provided prefixes are displayed. + +The output of ls-refs is as follows: + + output = *ref + flush-pkt + ref = PKT-LINE(obj-id SP refname *(SP ref-attribute) LF) + ref-attribute = (symref | peeled) + symref = "symref-target:" symref-target + peeled = "peeled:" obj-id + + fetch +~~~~~~~ + +`fetch` is the command used to fetch a packfile in v2. It can be looked +at as a modified version of the v1 fetch where the ref-advertisement is +stripped out (since the `ls-refs` command fills that role) and the +message format is tweaked to eliminate redundancies and permit easy +addition of future extensions. + +Additional features not supported in the base command will be advertised +as the value of the command in the capability advertisement in the form +of a space separated list of features: "<command>=<feature 1> <feature 2>" + +A `fetch` request can take the following arguments: + + want <oid> + Indicates to the server an object which the client wants to + retrieve. Wants can be anything and are not limited to + advertised objects. + + have <oid> + Indicates to the server an object which the client has locally. + This allows the server to make a packfile which only contains + the objects that the client needs. Multiple 'have' lines can be + supplied. + + done + Indicates to the server that negotiation should terminate (or + not even begin if performing a clone) and that the server should + use the information supplied in the request to construct the + packfile. + + thin-pack + Request that a thin pack be sent, which is a pack 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. + + no-progress + Request that progress information that would normally be sent on + side-band channel 2, during the packfile transfer, should not be + sent. However, the side-band channel 3 is still used for error + responses. + + include-tag + Request that annotated tags should be sent if the objects they + point to are being sent. + + ofs-delta + Indicate that the client understands PACKv2 with delta referring + to its base by position in pack rather than by an oid. That is, + they can read OBJ_OFS_DELTA (ake type 6) in a packfile. + +If the 'shallow' feature is advertised the following arguments can be +included in the clients request as well as the potential addition of the +'shallow-info' section in the server's response as explained below. + + shallow <oid> + A client must notify the server of all commits for which it only + has shallow copies (meaning that it doesn't have the parents of + a commit) by supplying a 'shallow <oid>' line for each such + object so that the server is aware of the limitations of the + client's history. This is so that the server is aware that the + client may not have all objects reachable from such commits. + + deepen <depth> + Requests that the fetch/clone should be shallow having a commit + depth of <depth> relative to the remote side. + + deepen-relative + Requests that the semantics of the "deepen" command be changed + to indicate that the depth requested is relative to the client's + current shallow boundary, instead of relative to the requested + commits. + + deepen-since <timestamp> + Requests that the shallow clone/fetch should be cut at a + specific time, instead of depth. Internally it's equivalent to + doing "git rev-list --max-age=<timestamp>". Cannot be used with + "deepen". + + deepen-not <rev> + Requests that the shallow clone/fetch should be cut at a + specific revision specified by '<rev>', instead of a depth. + Internally it's equivalent of doing "git rev-list --not <rev>". + Cannot be used with "deepen", but can be used with + "deepen-since". + +If the 'filter' feature is advertised, the following argument can be +included in the client's request: + + filter <filter-spec> + Request that various objects from the packfile be omitted + using one of several filtering techniques. These are intended + for use with partial clone and partial fetch operations. See + `rev-list` for possible "filter-spec" values. + +The response of `fetch` is broken into a number of sections separated by +delimiter packets (0001), with each section beginning with its section +header. + + output = *section + section = (acknowledgments | shallow-info | packfile) + (flush-pkt | delim-pkt) + + acknowledgments = PKT-LINE("acknowledgments" LF) + (nak | *ack) + (ready) + ready = PKT-LINE("ready" LF) + nak = PKT-LINE("NAK" LF) + ack = PKT-LINE("ACK" SP obj-id LF) + + shallow-info = PKT-LINE("shallow-info" LF) + *PKT-LINE((shallow | unshallow) LF) + shallow = "shallow" SP obj-id + unshallow = "unshallow" SP obj-id + + packfile = PKT-LINE("packfile" LF) + *PKT-LINE(%x01-03 *%x00-ff) + + acknowledgments section + * If the client determines that it is finished with negotiations + by sending a "done" line, the acknowledgments sections MUST be + omitted from the server's response. + + * Always begins with the section header "acknowledgments" + + * The server will respond with "NAK" if none of the object ids sent + as have lines were common. + + * The server will respond with "ACK obj-id" for all of the + object ids sent as have lines which are common. + + * A response cannot have both "ACK" lines as well as a "NAK" + line. + + * The server will respond with a "ready" line indicating that + the server has found an acceptable common base and is ready to + make and send a packfile (which will be found in the packfile + section of the same response) + + * If the server has found a suitable cut point and has decided + to send a "ready" line, then the server can decide to (as an + optimization) omit any "ACK" lines it would have sent during + its response. This is because the server will have already + determined the objects it plans to send to the client and no + further negotiation is needed. + + shallow-info section + * If the client has requested a shallow fetch/clone, a shallow + client requests a fetch or the server is shallow then the + server's response may include a shallow-info section. The + shallow-info section will be included if (due to one of the + above conditions) the server needs to inform the client of any + shallow boundaries or adjustments to the clients already + existing shallow boundaries. + + * Always begins with the section header "shallow-info" + + * If a positive depth is requested, the server will compute the + set of commits which are no deeper than the desired depth. + + * The server sends a "shallow obj-id" line for each commit whose + parents will not be sent in the following packfile. + + * The server sends an "unshallow obj-id" line for each commit + which the client has indicated is shallow, but is no longer + shallow as a result of the fetch (due to its parents being + sent in the following packfile). + + * The server MUST NOT send any "unshallow" lines for anything + which the client has not indicated was shallow as a part of + its request. + + * This section is only included if a packfile section is also + included in the response. + + packfile section + * This section is only included if the client has sent 'want' + lines in its request and either requested that no more + negotiation be done by sending 'done' or if the server has + decided it has found a sufficient cut point to produce a + packfile. + + * Always begins with the section header "packfile" + + * The transmission of the packfile begins immediately after the + section header + + * The data transfer of the packfile is always multiplexed, using + the same semantics of the 'side-band-64k' capability from + protocol version 1. This means that each packet, during the + packfile data stream, is made up of a leading 4-byte pkt-line + length (typical of the pkt-line format), followed by a 1-byte + stream code, followed by the actual data. + + The stream code can be one of: + 1 - pack data + 2 - progress messages + 3 - fatal error message just before stream aborts + + server-option +~~~~~~~~~~~~~~~ + +If advertised, indicates that any number of server specific options can be +included in a request. This is done by sending each option as a +"server-option=<option>" capability line in the capability-list section of +a request. + +The provided options must not contain a NUL or LF character. diff --git a/Documentation/technical/repository-version.txt b/Documentation/technical/repository-version.txt index 00ad37986e..e03eaccebc 100644 --- a/Documentation/technical/repository-version.txt +++ b/Documentation/technical/repository-version.txt @@ -86,3 +86,15 @@ for testing format-1 compatibility. When the config key `extensions.preciousObjects` is set to `true`, objects in the repository MUST NOT be deleted (e.g., by `git-prune` or `git repack -d`). + +`partialclone` +~~~~~~~~~~~~~~ + +When the config key `extensions.partialclone` is set, it indicates +that the repo was created with a partial clone (or later performed +a partial fetch) and that the remote may have omitted sending +certain unwanted objects. Such a remote is called a "promisor remote" +and it promises that all such omitted objects can be fetched from it +in the future. + +The value of this key is the name of the promisor remote. diff --git a/Documentation/technical/shallow.txt b/Documentation/technical/shallow.txt index 5183b15422..01dedfe9ff 100644 --- a/Documentation/technical/shallow.txt +++ b/Documentation/technical/shallow.txt @@ -8,20 +8,22 @@ repo, and therefore grafts are introduced pretending that these commits have no parents. ********************************************************* -The basic idea is to write the SHA-1s of shallow commits into -$GIT_DIR/shallow, and handle its contents like the contents -of $GIT_DIR/info/grafts (with the difference that shallow -cannot contain parent information). - -This information is stored in a new file instead of grafts, or -even the config, since the user should not touch that file -at all (even throughout development of the shallow clone, it -was never manually edited!). +$GIT_DIR/shallow lists commit object names and tells Git to +pretend as if they are root commits (e.g. "git log" traversal +stops after showing them; "git fsck" does not complain saying +the commits listed on their "parent" lines do not exist). Each line contains exactly one SHA-1. When read, a commit_graft will be constructed, which has nr_parent < 0 to make it easier to discern from user provided grafts. +Note that the shallow feature could not be changed easily to +use replace refs: a commit containing a `mergetag` is not allowed +to be replaced, not even by a root commit. Such a commit can be +made shallow, though. Also, having a `shallow` file explicitly +listing all the commits made shallow makes it a *lot* easier to +do shallow-specific things such as to deepen the history. + Since fsck-objects relies on the library to read the objects, it honours shallow commits automatically. |