diff options
Diffstat (limited to 'Documentation')
67 files changed, 2581 insertions, 256 deletions
diff --git a/Documentation/RelNotes/2.10.0.txt b/Documentation/RelNotes/2.10.0.txt new file mode 100644 index 0000000..f4da28a --- /dev/null +++ b/Documentation/RelNotes/2.10.0.txt @@ -0,0 +1,675 @@ +Git 2.10 Release Notes +====================== + +Backward compatibility notes +---------------------------- + +Updates since v2.9 +------------------ + +UI, Workflows & Features + + * "git pull --rebase --verify-signature" learned to warn the user + that "--verify-signature" is a no-op when rebasing. + + * An upstream project can make a recommendation to shallowly clone + some submodules in the .gitmodules file it ships. + + * "git worktree add" learned that '-' can be used as a short-hand for + "@{-1}", the previous branch. + + * Update the funcname definition to support css files. + + * The completion script (in contrib/) learned to complete "git + status" options. + + * Messages that are generated by auto gc during "git push" on the + receiving end are now passed back to the sending end in such a way + that they are shown with "remote: " prefix to avoid confusing the + users. + + * "git add -i/-p" learned to honor diff.compactionHeuristic + experimental knob, so that the user can work on the same hunk split + as "git diff" output. + + * "upload-pack" allows a custom "git pack-objects" replacement when + responding to "fetch/clone" via the uploadpack.packObjectsHook. + (merge b738396 jk/upload-pack-hook later to maint). + + * Teach format-patch and mailsplit (hence "am") how a line that + happens to begin with "From " in the e-mail message is quoted with + ">", so that these lines can be restored to their original shape. + (merge d9925d1 ew/mboxrd-format-am later to maint). + + * "git repack" learned the "--keep-unreachable" option, which sends + loose unreachable objects to a pack instead of leaving them loose. + This helps heuristics based on the number of loose objects + (e.g. "gc --auto"). + (merge e26a8c4 jk/repack-keep-unreachable later to maint). + + * "log --graph --format=" learned that "%>|(N)" specifies the width + relative to the terminal's left edge, not relative to the area to + draw text that is to the right of the ancestry-graph section. It + also now accepts negative N that means the column limit is relative + to the right border. + + * A careless invocation of "git send-email directory/" after editing + 0001-change.patch with an editor often ends up sending both + 0001-change.patch and its backup file, 0001-change.patch~, causing + embarrassment and a minor confusion. Detect such an input and + offer to skip the backup files when sending the patches out. + (merge 531220b jc/send-email-skip-backup later to maint). + + * "git submodule update" that drives many "git clone" could + eventually hit flaky servers/network conditions on one of the + submodules; the command learned to retry the attempt. + + * The output coloring scheme learned two new attributes, italic and + strike, in addition to existing bold, reverse, etc. + + * "git log" learns log.showSignature configuration variable, and a + command line option "--no-show-signature" to countermand it. + (merge fce04c3 mj/log-show-signature-conf later to maint). + + * More markings of messages for i18n, with updates to various tests + to pass GETTEXT_POISON tests. + + * "git archive" learned to handle files that are larger than 8GB and + commits far in the future than expressible by the traditional US-TAR + format. + (merge 560b0e8 jk/big-and-future-archive-tar later to maint). + + + * A new configuration variable core.sshCommand has been added to + specify what value for GIT_SSH_COMMAND to use per repository. + + * "git worktree prune" protected worktrees that are marked as + "locked" by creating a file in a known location. "git worktree" + command learned a dedicated command pair to create and remove such + a file, so that the users do not have to do this with editor. + + * A handful of "git svn" updates. + + * "git push" learned to accept and pass extra options to the + receiving end so that hooks can read and react to them. + + * "git status" learned to suggest "merge --abort" during a conflicted + merge, just like it already suggests "rebase --abort" during a + conflicted rebase. + + * "git jump" script (in contrib/) has been updated a bit. + (merge a91e692 jk/git-jump later to maint). + + * "git push" and "git clone" learned to give better progress meters + to the end user who is waiting on the terminal. + + * An entry "git log --decorate" for the tip of the current branch is + shown as "HEAD -> name" (where "name" is the name of the branch); + the arrow is now painted in the same color as "HEAD", not in the + color for commits. + + * "git format-patch" learned format.from configuration variable to + specify the default settings for its "--from" option. + + * "git am -3" calls "git merge-recursive" when it needs to fall back + to a three-way merge; this call has been turned into an internal + subroutine call instead of spawning a separate subprocess. + + * The command line completion scripts (in contrib/) now knows about + "git branch --delete/--move [--remote]". + (merge 2703c22 vs/completion-branch-fully-spelled-d-m-r later to maint). + + * "git rev-parse --git-path hooks/<hook>" learned to take + core.hooksPath configuration variable (introduced during 2.9 cycle) + into account. + (merge 9445b49 ab/hooks later to maint). + + * "git log --show-signature" and other commands that display the + verification status of PGP signature now shows the longer key-id, + as 32-bit key-id is so last century. + + +Performance, Internal Implementation, Development Support etc. + + * "git fast-import" learned the same performance trick to avoid + creating too small a packfile as "git fetch" and "git push" have, + using *.unpackLimit configuration. + + * When "git daemon" is run without --[init-]timeout specified, a + connection from a client that silently goes offline can hang around + for a long time, wasting resources. The socket-level KEEPALIVE has + been enabled to allow the OS to notice such failed connections. + + * "git upload-pack" command has been updated to use the parse-options + API. + + * The "git apply" standalone program is being libified; the first + step to move many state variables into a structure that can be + explicitly (re)initialized to make the machinery callable more + than once has been merged. + + * HTTP transport gained an option to produce more detailed debugging + trace. + (merge 73e57aa ep/http-curl-trace later to maint). + + * Instead of taking advantage of the fact that a struct string_list + that is allocated with all NULs happens to be the INIT_NODUP kind, + the users of string_list structures are taught to initialize them + explicitly as such, to document their behaviour better. + (merge 2721ce2 jk/string-list-static-init later to maint). + + * HTTPd tests learned to show the server error log to help diagnosing + a failing tests. + (merge 44f243d nd/test-lib-httpd-show-error-log-in-verbose later to maint). + + * The ownership rule for the piece of memory that hold references to + be fetched in "git fetch" was screwy, which has been cleaned up. + + * "git bisect" makes an internal call to "git diff-tree" when + bisection finds the culprit, but this call did not initialize the + data structure to pass to the diff-tree API correctly. + + * Further preparatory clean-up for "worktree" feature continues. + (merge 0409e0b nd/worktree-cleanup-post-head-protection later to maint). + + * Formats of the various data (and how to validate them) where we use + GPG signature have been documented. + + * A new run-command API function pipe_command() is introduced to + sanely feed data to the standard input while capturing data from + the standard output and the standard error of an external process, + which is cumbersome to hand-roll correctly without deadlocking. + + * The codepath to sign data in a prepared buffer with GPG has been + updated to use this API to read from the status-fd to check for + errors (instead of relying on GPG's exit status). + (merge efee955 jk/gpg-interface-cleanup later to maint). + + * Allow t/perf framework to use the features from the most recent + version of Git even when testing an older installed version. + + * The commands in the "log/diff" family have had an FILE* pointer in the + data structure they pass around for a long time, but some codepaths + used to always write to the standard output. As a preparatory step + to make "git format-patch" available to the internal callers, these + codepaths have been updated to consistently write into that FILE* + instead. + + * Conversion from unsigned char sha1[20] to struct object_id + continues. + + * Improve the look of the way "git fetch" reports what happened to + each ref that was fetched. + + * The .c/.h sources are marked as such in our .gitattributes file so + that "git diff -W" and friends would work better. + + * Code clean-up to avoid using a variable string that compilers may + feel untrustable as printf-style format given to write_file() + helper function. + + * "git p4" used a location outside $GIT_DIR/refs/ to place its + temporary branches, which has been moved to refs/git-p4-tmp/. + + * Existing autoconf generated test for the need to link with pthread + library did not check all the functions from pthread libraries; + recent FreeBSD has some functions in libc but not others, and we + mistakenly thought linking with libc is enough when it is not. + + * When "git fsck" reports a broken link (e.g. a tree object contains + a blob that does not exist), both containing object and the object + that is referred to were reported with their 40-hex object names. + The command learned the "--name-objects" option to show the path to + the containing object from existing refs (e.g. "HEAD~24^2:file.txt"). + + * Allow http daemon tests in Travis CI tests. + + * Makefile assumed that -lrt is always available on platforms that + want to use clock_gettime() and CLOCK_MONOTONIC, which is not a + case for recent Mac OS X. The necessary symbols are often found in + libc on many modern systems and having -lrt on the command line, as + long as the library exists, had no effect, but when the platform + removes librt.a that is a different matter--having -lrt will break + the linkage. + + This change could be seen as a regression for those who do need to + specify -lrt, as they now specifically ask for NEEDS_LIBRT when + building. Hopefully they are in the minority these days. + + * Further preparatory work on the refs API before the pluggable + backend series can land. + + * Error handling in the codepaths that updates refs has been + improved. + + * The API to iterate over all the refs (i.e. for_each_ref(), etc.) + has been revamped. + + * The handling of the "text=auto" attribute has been corrected. + $ echo "* text=auto eol=crlf" >.gitattributes + used to have the same effect as + $ echo "* text eol=crlf" >.gitattributes + i.e. declaring all files are text (ignoring "auto"). The + combination has been fixed to be equivalent to doing + $ git config core.autocrlf true + + * Documentation has been updated to show better example usage + of the updated "text=auto" attribute. + + * A few tests that specifically target "git rebase -i" have been + added. + + * Dumb http transport on the client side has been optimized. + (merge ecba195 ew/http-walker later to maint). + + * Users of the parse_options_concat() API function need to allocate + extra slots in advance and fill them with OPT_END() when they want + to decide the set of supported options dynamically, which makes the + code error-prone and hard to read. This has been corrected by tweaking + the API to allocate and return a new copy of "struct option" array. + + * "git fetch" exchanges batched have/ack messages between the sender + and the receiver, initially doubling every time and then falling + back to enlarge the window size linearly. The "smart http" + transport, being an half-duplex protocol, outgrows the preset limit + too quickly and becomes inefficient when interacting with a large + repository. The internal mechanism learned to grow the window size + more aggressively when working with the "smart http" transport. + + * Tests for "git svn" have been taught to reuse the lib-httpd test + infrastructure when testing the subversion integration that + interacts with subversion repositories served over the http:// + protocol. + (merge a8a5d25 ew/git-svn-http-tests later to maint). + + * "git pack-objects" has a few options that tell it not to pack + objects found in certain packfiles, which require it to scan .idx + files of all available packs. The codepaths involved in these + operations have been optimized for a common case of not having any + non-local pack and/or any .kept pack. + + * The t3700 test about "add --chmod=-x" have been made a bit more + robust and generally cleaned up. + (merge 766cdc4 ib/t3700-add-chmod-x-updates later to maint). + + * The build procedure learned PAGER_ENV knob that lists what default + environment variable settings to export for popular pagers. This + mechanism is used to tweak the default settings to MORE on FreeBSD. + (merge 995bc22 ew/build-time-pager-tweaks later to maint). + + * The http-backend (the server-side component of smart-http + transport) used to trickle the HTTP header one at a time. Now + these write(2)s are batched. + (merge b36045c ew/http-backend-batch-headers later to maint). + + * When "git rebase" tries to compare set of changes on the updated + upstream and our own branch, it computes patch-id for all of these + changes and attempts to find matches. This has been optimized by + lazily computing the full patch-id (which is expensive) to be + compared only for changes that touch the same set of paths. + (merge ba67504 kw/patch-ids-optim later to maint). + + * A handful of tests that were broken under gettext-poison build have + been fixed. + + * The recent i18n patch we added during this cycle did a bit too much + refactoring of the messages to avoid word-legos; the repetition has + been reduced to help translators. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v2.9 +---------------- + +Unless otherwise noted, all the fixes since v2.8 in the maintenance +track are contained in this release (see the maintenance releases' +notes for details). + + * The commands in `git log` family take %C(auto) in a custom format + string. This unconditionally turned the color on, ignoring + --no-color or with --color=auto when the output is not connected to + a tty; this was corrected to make the format truly behave as + "auto". + + * "git rev-list --count" whose walk-length is limited with "-n" + option did not work well with the counting optimized to look at the + bitmap index. + + * "git show -W" (extend hunks to cover the entire function, delimited + by lines that match the "funcname" pattern) used to show the entire + file when a change added an entire function at the end of the file, + which has been fixed. + + * The documentation set has been updated so that literal commands, + configuration variables and environment variables are consistently + typeset in fixed-width font and bold in manpages. + + * "git svn propset" subcommand that was added in 2.3 days is + documented now. + + * The documentation tries to consistently spell "GPG"; when + referring to the specific program name, "gpg" is used. + + * "git reflog" stopped upon seeing an entry that denotes a branch + creation event (aka "unborn"), which made it appear as if the + reflog was truncated. + + * The git-prompt scriptlet (in contrib/) was not friendly with those + who uses "set -u", which has been fixed. + + * compat/regex code did not cleanly compile. + + * A codepath that used alloca(3) to place an unbounded amount of data + on the stack has been updated to avoid doing so. + + * "git update-index --add --chmod=+x file" may be usable as an escape + hatch, but not a friendly thing to force for people who do need to + use it regularly. "git add --chmod=+x file" can be used instead. + + * Build improvements for gnome-keyring (in contrib/) + + * "git status" used to say "working directory" when it meant "working + tree". + + * Comments about misbehaving FreeBSD shells have been clarified with + the version number (9.x and before are broken, newer ones are OK). + + * "git cherry-pick A" worked on an unborn branch, but "git + cherry-pick A..B" didn't. + + * Fix an unintended regression in v2.9 that breaks "clone --depth" + that recurses down to submodules by forcing the submodules to also + be cloned shallowly, which many server instances that host upstream + of the submodules are not prepared for. + + * Fix unnecessarily waste in the idiomatic use of ': ${VAR=default}' + to set the default value, without enclosing it in double quotes. + + * Some platform-specific code had non-ANSI strict declarations of C + functions that do not take any parameters, which has been + corrected. + + * The internal code used to show local timezone offset is not + prepared to handle timestamps beyond year 2100, and gave a + bogus offset value to the caller. Use a more benign looking + +0000 instead and let "git log" going in such a case, instead + of aborting. + + * One among four invocations of readlink(1) in our test suite has + been rewritten so that the test can run on systems without the + command (others are in valgrind test framework and t9802). + + * t/perf needs /usr/bin/time with GNU extension; the invocation of it + is updated to "gtime" on Darwin. + + * A bug, which caused "git p4" while running under verbose mode to + report paths that are omitted due to branch prefix incorrectly, has + been fixed; the command said "Ignoring file outside of prefix" for + paths that are _inside_. + + * The top level documentation "git help git" still pointed at the + documentation set hosted at now-defunct google-code repository. + Update it to point to https://git.github.io/htmldocs/git.html + instead. + + * A helper function that takes the contents of a commit object and + finds its subject line did not ignore leading blank lines, as is + commonly done by other codepaths. Make it ignore leading blank + lines to match. + + * For a long time, we carried an in-code comment that said our + colored output would work only when we use fprintf/fputs on + Windows, which no longer is the case for the past few years. + + * "gc.autoPackLimit" when set to 1 should not trigger a repacking + when there is only one pack, but the code counted poorly and did + so. + + * Add a test to specify the desired behaviour that currently is not + available in "git rebase -Xsubtree=...". + + * More mark-up updates to typeset strings that are expected to + literally typed by the end user in fixed-width font. + + * "git commit --amend --allow-empty-message -S" for a commit without + any message body could have misidentified where the header of the + commit object ends. + + * "git rebase -i --autostash" did not restore the auto-stashed change + when the operation was aborted. + + * Git does not know what the contents in the index should be for a + path added with "git add -N" yet, so "git grep --cached" should not + show hits (or show lack of hits, with -L) in such a path, but that + logic does not apply to "git grep", i.e. searching in the working + tree files. But we did so by mistake, which has been corrected. + + * "git blame -M" missed a single line that was moved within the file. + + * Fix recently introduced codepaths that are involved in parallel + submodule operations, which gave up on reading too early, and + could have wasted CPU while attempting to write under a corner + case condition. + + * "git grep -i" has been taught to fold case in non-ascii locales + correctly. + + * A test that unconditionally used "mktemp" learned that the command + is not necessarily available everywhere. + + * There are certain house-keeping tasks that need to be performed at + the very beginning of any Git program, and programs that are not + built-in commands had to do them exactly the same way as "git" + potty does. It was easy to make mistakes in one-off standalone + programs (like test helpers). A common "main()" function that + calls cmd_main() of individual program has been introduced to + make it harder to make mistakes. + (merge de61ceb jk/common-main later to maint). + + * The test framework learned a new helper test_match_signal to + check an exit code from getting killed by an expected signal. + + * General code clean-up around a helper function to write a + single-liner to a file. + (merge 7eb6e10 jk/write-file later to maint). + + * One part of "git am" had an oddball helper function that called + stuff from outside "his" as opposed to calling what we have "ours", + which was not gender-neutral and also inconsistent with the rest of + the system where outside stuff is usuall called "theirs" in + contrast to "ours". + + * "git blame file" allowed the lineage of lines in the uncommitted, + unadded contents of "file" to be inspected, but it refused when + "file" did not appear in the current commit. When "file" was + created by renaming an existing file (but the change has not been + committed), this restriction was unnecessarily tight. + + * "git add -N dir/file && git write-tree" produced an incorrect tree + when there are other paths in the same directory that sorts after + "file". + + * "git fetch http://user:pass@host/repo..." scrubbed the userinfo + part, but "git push" didn't. + + * "git merge" with renormalization did not work well with + merge-recursive, due to "safer crlf" conversion kicking in when it + shouldn't. + (merge 1335d76 jc/renormalize-merge-kill-safer-crlf later to maint). + + * The use of strbuf in "git rm" to build filename to remove was a bit + suboptimal, which has been fixed. + + * An age old bug that caused "git diff --ignore-space-at-eol" + misbehave has been fixed. + + * "git notes merge" had a code to see if a path exists (and fails if + it does) and then open the path for writing (when it doesn't). + Replace it with open with O_EXCL. + + * "git pack-objects" and "git index-pack" mostly operate with off_t + when talking about the offset of objects in a packfile, but there + were a handful of places that used "unsigned long" to hold that + value, leading to an unintended truncation. + + * Recent update to "git daemon" tries to enable the socket-level + KEEPALIVE, but when it is spawned via inetd, the standard input + file descriptor may not necessarily be connected to a socket. + Suppress an ENOTSOCK error from setsockopt(). + + * Recent FreeBSD stopped making perl available at /usr/bin/perl; + switch the default the built-in path to /usr/local/bin/perl on not + too ancient FreeBSD releases. + + * "git commit --help" said "--no-verify" is only about skipping the + pre-commit hook, and failed to say that it also skipped the + commit-msg hook. + + * "git merge" in Git v2.9 was taught to forbid merging an unrelated + lines of history by default, but that is exactly the kind of thing + the "--rejoin" mode of "git subtree" (in contrib/) wants to do. + "git subtree" has been taught to use the "--allow-unrelated-histories" + option to override the default. + + * The build procedure for "git persistent-https" helper (in contrib/) + has been updated so that it can be built with more recent versions + of Go. + + * There is an optimization used in "git diff $treeA $treeB" to borrow + an already checked-out copy in the working tree when it is known to + be the same as the blob being compared, expecting that open/mmap of + such a file is faster than reading it from the object store, which + involves inflating and applying delta. This however kicked in even + when the checked-out copy needs to go through the convert-to-git + conversion (including the clean filter), which defeats the whole + point of the optimization. The optimization has been disabled when + the conversion is necessary. + + * "git -c grep.patternType=extended log --basic-regexp" misbehaved + because the internal API to access the grep machinery was not + designed well. + + * Windows port was failing some tests in t4130, due to the lack of + inum in the returned values by its lstat(2) emulation. + + * The reflog output format is documented better, and a new format + --date=unix to report the seconds-since-epoch (without timezone) + has been added. + (merge 442f6fd jk/reflog-date later to maint). + + * "git difftool <paths>..." started in a subdirectory failed to + interpret the paths relative to that directory, which has been + fixed. + + * The characters in the label shown for tags/refs for commits in + "gitweb" output are now properly escaped for proper HTML output. + + * FreeBSD can lie when asked mtime of a directory, which made the + untracked cache code to fall back to a slow-path, which in turn + caused tests in t7063 to fail because it wanted to verify the + behaviour of the fast-path. + + * Squelch compiler warnings for nedmalloc (in compat/) library. + + * A small memory leak in the command line parsing of "git blame" + has been plugged. + + * The API documentation for hashmap was unclear if hashmap_entry + can be safely discarded without any other consideration. State + that it is safe to do so. + + * Not-so-recent rewrite of "git am" that started making internal + calls into the commit machinery had an unintended regression, in + that no matter how many seconds it took to apply many patches, the + resulting committer timestamp for the resulting commits were all + the same. + + * "git push --force-with-lease" already had enough logic to allow + ensuring that such a push results in creation of a ref (i.e. the + receiving end did not have another push from sideways that would be + discarded by our force-pushing), but didn't expose this possibility + to the users. It does so now. + (merge 9eed4f3 jk/push-force-with-lease-creation later to maint). + + * The mechanism to limit the pack window memory size, when packing is + done using multiple threads (which is the default), is per-thread, + but this was not documented clearly. + (merge 954176c ms/document-pack-window-memory-is-per-thread later to maint). + + * "import-tars" fast-import script (in contrib/) used to ignore a + hardlink target and replaced it with an empty file, which has been + corrected to record the same blob as the other file the hardlink is + shared with. + (merge 04e0869 js/import-tars-hardlinks later to maint). + + * "git mv dir non-existing-dir/" did not work in some environments + the same way as existing mainstream platforms. The code now moves + "dir" to "non-existing-dir", without relying on rename("A", "B/") + that strips the trailing slash of '/'. + (merge 189d035 js/mv-dir-to-new-directory later to maint). + + * The "t/" hierarchy is prone to get an unusual pathname; "make test" + has been taught to make sure they do not contain paths that cannot + be checked out on Windows (and the mechanism can be reusable to + catch pathnames that are not portable to other platforms as need + arises). + (merge c2cafd3 js/test-lint-pathname later to maint). + + * When "git merge-recursive" works on history with many criss-cross + merges in "verbose" mode, the names the command assigns to the + virtual merge bases could have overwritten each other by unintended + reuse of the same piece of memory. + (merge 5447a76 rs/pull-signed-tag later to maint). + + * "git checkout --detach <branch>" used to give the same advice + message as that is issued when "git checkout <tag>" (or anything + that is not a branch name) is given, but asking with "--detach" is + an explicit enough sign that the user knows what is going on. The + advice message has been squelched in this case. + (merge 779b88a sb/checkout-explit-detach-no-advice later to maint). + + * "git difftool" by default ignores the error exit from the backend + commands it spawns, because often they signal that they found + differences by exiting with a non-zero status code just like "diff" + does; the exit status codes 126 and above however are special in + that they are used to signal that the command is not executable, + does not exist, or killed by a signal. "git difftool" has been + taught to notice these exit status codes. + (merge 45a4f5d jk/difftool-command-not-found later to maint). + + * On Windows, help.browser configuration variable used to be ignored, + which has been corrected. + (merge 6db5967 js/no-html-bypass-on-windows later to maint). + + * The "git -c var[=val] cmd" facility to append a configuration + variable definition at the end of the search order was described in + git(1) manual page, but not in git-config(1), which was more likely + place for people to look for when they ask "can I make a one-shot + override, and if so how?" + (merge ae1f709 dg/document-git-c-in-git-config-doc later to maint). + + * The tempfile (hence its user lockfile) API lets the caller to open + a file descriptor to a temporary file, write into it and then + finalize it by first closing the filehandle and then either + removing or renaming the temporary file. When the process spawns a + subprocess after obtaining the file descriptor, and if the + subprocess has not exited when the attempt to remove or rename is + made, the last step fails on Windows, because the subprocess has + the file descriptor still open. Open tempfile with O_CLOEXEC flag + to avoid this (on Windows, this is mapped to O_NOINHERIT). + (merge 05d1ed6 bw/mingw-avoid-inheriting-fd-to-lockfile later to maint). + + * Correct an age-old calco (is that a typo-like word for calc) + in the documentation. + (merge 7841c48 ls/packet-line-protocol-doc-fix later to maint). + + * Other minor clean-ups and documentation updates + (merge 02a8cfa rs/merge-add-strategies-simplification later to maint). + (merge af4941d rs/merge-recursive-string-list-init later to maint). + (merge 1eb47f1 rs/use-strbuf-add-unique-abbrev later to maint). + (merge ddd0bfa jk/tighten-alloc later to maint). + (merge ecf30b2 rs/mailinfo-lib later to maint). + (merge 0eb75ce sg/reflog-past-root later to maint). + (merge 4369523 hv/doc-commit-reference-style later to maint). diff --git a/Documentation/RelNotes/2.10.1.txt b/Documentation/RelNotes/2.10.1.txt new file mode 100644 index 0000000..70462f7 --- /dev/null +++ b/Documentation/RelNotes/2.10.1.txt @@ -0,0 +1,131 @@ +Git v2.10.1 Release Notes +========================= + +Fixes since v2.10 +----------------- + + * Clarify various ways to specify the "revision ranges" in the + documentation. + + * "diff-highlight" script (in contrib/) learned to work better with + "git log -p --graph" output. + + * The test framework left the number of tests and success/failure + count in the t/test-results directory, keyed by the name of the + test script plus the process ID. The latter however turned out not + to serve any useful purpose. The process ID part of the filename + has been removed. + + * Having a submodule whose ".git" repository is somehow corrupt + caused a few commands that recurse into submodules loop forever. + + * "git symbolic-ref -d HEAD" happily removes the symbolic ref, but + the resulting repository becomes an invalid one. Teach the command + to forbid removal of HEAD. + + * A test spawned a short-lived background process, which sometimes + prevented the test directory from getting removed at the end of the + script on some platforms. + + * Update a few tests that used to use GIT_CURL_VERBOSE to use the + newer GIT_TRACE_CURL. + + * Update Japanese translation for "git-gui". + + * "git fetch http::/site/path" did not die correctly and segfaulted + instead. + + * "git commit-tree" stopped reading commit.gpgsign configuration + variable that was meant for Porcelain "git commit" in Git 2.9; we + forgot to update "git gui" to look at the configuration to match + this change. + + * "git log --cherry-pick" used to include merge commits as candidates + to be matched up with other commits, resulting a lot of wasted time. + The patch-id generation logic has been updated to ignore merges to + avoid the wastage. + + * The http transport (with curl-multi option, which is the default + these days) failed to remove curl-easy handle from a curlm session, + which led to unnecessary API failures. + + * "git diff -W" output needs to extend the context backward to + include the header line of the current function and also forward to + include the body of the entire current function up to the header + line of the next one. This process may have to merge to adjacent + hunks, but the code forgot to do so in some cases. + + * Performance tests done via "t/perf" did not use the same set of + build configuration if the user relied on autoconf generated + configuration. + + * "git format-patch --base=..." feature that was recently added + showed the base commit information after "-- " e-mail signature + line, which turned out to be inconvenient. The base information + has been moved above the signature line. + + * Even when "git pull --rebase=preserve" (and the underlying "git + rebase --preserve") can complete without creating any new commit + (i.e. fast-forwards), it still insisted on having a usable ident + information (read: user.email is set correctly), which was less + than nice. As the underlying commands used inside "git rebase" + would fail with a more meaningful error message and advice text + when the bogus ident matters, this extra check was removed. + + * "git gc --aggressive" used to limit the delta-chain length to 250, + which is way too deep for gaining additional space savings and is + detrimental for runtime performance. The limit has been reduced to + 50. + + * Documentation for individual configuration variables to control use + of color (like `color.grep`) said that their default value is + 'false', instead of saying their default is taken from `color.ui`. + When we updated the default value for color.ui from 'false' to + 'auto' quite a while ago, all of them broke. This has been + corrected. + + * A shell script example in check-ref-format documentation has been + fixed. + + * "git checkout <word>" does not follow the usual disambiguation + rules when the <word> can be both a rev and a path, to allow + checking out a branch 'foo' in a project that happens to have a + file 'foo' in the working tree without having to disambiguate. + This was poorly documented and the check was incorrect when the + command was run from a subdirectory. + + * Some codepaths in "git diff" used regexec(3) on a buffer that was + mmap(2)ed, which may not have a terminating NUL, leading to a read + beyond the end of the mapped region. This was fixed by introducing + a regexec_buf() helper that takes a <ptr,len> pair with REG_STARTEND + extension. + + * The procedure to build Git on Mac OS X for Travis CI hardcoded the + internal directory structure we assumed HomeBrew uses, which was a + no-no. The procedure has been updated to ask HomeBrew things we + need to know to fix this. + + * When "git rebase -i" is given a broken instruction, it told the + user to fix it with "--edit-todo", but didn't say what the step + after that was (i.e. "--continue"). + + * "git add --chmod=+x" added recently lacked documentation, which has + been corrected. + + * "git add --chmod=+x <pathspec>" added recently only toggled the + executable bit for paths that are either new or modified. This has + been corrected to flip the executable bit for all paths that match + the given pathspec. + + * "git pack-objects --include-tag" was taught that when we know that + we are sending an object C, we want a tag B that directly points at + C but also a tag A that points at the tag B. We used to miss the + intermediate tag B in some cases. + + * Documentation around tools to import from CVS was fairly outdated. + + * In the codepath that comes up with the hostname to be used in an + e-mail when the user didn't tell us, we looked at ai_canonname + field in struct addrinfo without making sure it is not NULL first. + +Also contains minor documentation updates and code clean-ups. diff --git a/Documentation/RelNotes/2.10.2.txt b/Documentation/RelNotes/2.10.2.txt new file mode 100644 index 0000000..c4d4397 --- /dev/null +++ b/Documentation/RelNotes/2.10.2.txt @@ -0,0 +1,111 @@ +Git v2.10.2 Release Notes +========================= + +Fixes since v2.10.1 +------------------- + + * The code that parses the format parameter of for-each-ref command + has seen a micro-optimization. + + * The "graph" API used in "git log --graph" miscounted the number of + output columns consumed so far when drawing a padding line, which + has been fixed; this did not affect any existing code as nobody + tried to write anything after the padding on such a line, though. + + * Almost everybody uses DEFAULT_ABBREV to refer to the default + setting for the abbreviation, but "git blame" peeked into + underlying variable bypassing the macro for no good reason. + + * Doc update to clarify what "log -3 --reverse" does. + + * An author name, that spelled a backslash-quoted double quote in the + human readable part "My \"double quoted\" name", was not unquoted + correctly while applying a patch from a piece of e-mail. + + * The original command line syntax for "git merge", which was "git + merge <msg> HEAD <parent>...", has been deprecated for quite some + time, and "git gui" was the last in-tree user of the syntax. This + is finally fixed, so that we can move forward with the deprecation. + + * Codepaths that read from an on-disk loose object were too loose in + validating what they are reading is a proper object file and + sometimes read past the data they read from the disk, which has + been corrected. H/t to Gustavo Grieco for reporting. + + * "git worktree", even though it used the default_abbrev setting that + ought to be affected by core.abbrev configuration variable, ignored + the variable setting. The command has been taught to read the + default set of configuration variables to correct this. + + * A low-level function verify_packfile() was meant to show errors + that were detected without dying itself, but under some conditions + it didn't and died instead, which has been fixed. + + * When "git fetch" tries to find where the history of the repository + it runs in has diverged from what the other side has, it has a + mechanism to avoid digging too deep into irrelevant side branches. + This however did not work well over the "smart-http" transport due + to a design bug, which has been fixed. + + * When we started cURL to talk to imap server when a new enough + version of cURL library is available, we forgot to explicitly add + imap(s):// before the destination. To some folks, that didn't work + and the library tried to make HTTP(s) requests instead. + + * The ./configure script generated from configure.ac was taught how + to detect support of SSL by libcurl better. + + * http.emptyauth configuration is a way to allow an empty username to + pass when attempting to authenticate using mechanisms like + Kerberos. We took an unspecified (NULL) username and sent ":" + (i.e. no username, no password) to CURLOPT_USERPWD, but did not do + the same when the username is explicitly set to an empty string. + + * "git clone" of a local repository can be done at the filesystem + level, but the codepath did not check errors while copying and + adjusting the file that lists alternate object stores. + + * Documentation for "git commit" was updated to clarify that "commit + -p <paths>" adds to the current contents of the index to come up + with what to commit. + + * A stray symbolic link in $GIT_DIR/refs/ directory could make name + resolution loop forever, which has been corrected. + + * The "submodule.<name>.path" stored in .gitmodules is never copied + to .git/config and such a key in .git/config has no meaning, but + the documentation described it and submodule.<name>.url next to + each other as if both belong to .git/config. This has been fixed. + + * Recent git allows submodule.<name>.branch to use a special token + "." instead of the branch name; the documentation has been updated + to describe it. + + * In a worktree connected to a repository elsewhere, created via "git + worktree", "git checkout" attempts to protect users from confusion + by refusing to check out a branch that is already checked out in + another worktree. However, this also prevented checking out a + branch, which is designated as the primary branch of a bare + reopsitory, in a worktree that is connected to the bare + repository. The check has been corrected to allow it. + + * "git rebase" immediately after "git clone" failed to find the fork + point from the upstream. + + * When fetching from a remote that has many tags that are irrelevant + to branches we are following, we used to waste way too many cycles + when checking if the object pointed at by a tag (that we are not + going to fetch!) exists in our repository too carefully. + + * The Travis CI configuration we ship ran the tests with --verbose + option but this risks non-TAP output that happens to be "ok" to be + misinterpreted as TAP signalling a test that passed. This resulted + in unnecessary failure. This has been corrected by introducing a + new mode to run our tests in the test harness to send the verbose + output separately to the log file. + + * Some AsciiDoc formatter mishandles a displayed illustration with + tabs in it. Adjust a few of them in merge-base documentation to + work around them. + +Also contains minor documentation updates and code clean-ups. diff --git a/Documentation/RelNotes/2.11.0.txt b/Documentation/RelNotes/2.11.0.txt new file mode 100644 index 0000000..7a1fce7 --- /dev/null +++ b/Documentation/RelNotes/2.11.0.txt @@ -0,0 +1,585 @@ +Git 2.11 Release Notes +====================== + +Backward compatibility notes. + + * An empty string used as a pathspec element has always meant + 'everything matches', but it is too easy to write a script that + finds a path to remove in $path and run 'git rm "$paht"' by + mistake (when the user meant to give "$path"), which ends up + removing everything. This release starts warning about the + use of an empty string that is used for 'everything matches' and + asks users to use a more explicit '.' for that instead. + + The hope is that existing users will not mind this change, and + eventually the warning can be turned into a hard error, upgrading + the deprecation into removal of this (mis)feature. + + * The historical argument order "git merge <msg> HEAD <commit>..." + has been deprecated for quite some time, and will be removed in the + next release (not this one). + + * The default abbreviation length, which has historically been 7, now + scales as the repository grows, using the approximate number of + objects in the repository and a bit of math around the birthday + paradox. The logic suggests to use 12 hexdigits for the Linux + kernel, and 9 to 10 for Git itself. + + +Updates since v2.10 +------------------- + +UI, Workflows & Features + + * Comes with new version of git-gui, now at its 0.21.0 tag. + + * "git format-patch --cover-letter HEAD^" to format a single patch + with a separate cover letter now numbers the output as [PATCH 0/1] + and [PATCH 1/1] by default. + + * An incoming "git push" that attempts to push too many bytes can now + be rejected by setting a new configuration variable at the receiving + end. + + * "git nosuchcommand --help" said "No manual entry for gitnosuchcommand", + which was not intuitive, given that "git nosuchcommand" said "git: + 'nosuchcommand' is not a git command". + + * "git clone --recurse-submodules --reference $path $URL" is a way to + reduce network transfer cost by borrowing objects in an existing + $path repository when cloning the superproject from $URL; it + learned to also peek into $path for presence of corresponding + repositories of submodules and borrow objects from there when able. + + * The "git diff --submodule={short,log}" mechanism has been enhanced + to allow "--submodule=diff" to show the patch between the submodule + commits bound to the superproject. + + * Even though "git hash-objects", which is a tool to take an + on-filesystem data stream and put it into the Git object store, + allowed to perform the "outside-world-to-Git" conversions (e.g. + end-of-line conversions and application of the clean-filter), and + it had the feature on by default from very early days, its reverse + operation "git cat-file", which takes an object from the Git object + store and externalize for the consumption by the outside world, + lacked an equivalent mechanism to run the "Git-to-outside-world" + conversion. The command learned the "--filters" option to do so. + + * Output from "git diff" can be made easier to read by selecting + which lines are common and which lines are added/deleted + intelligently when the lines before and after the changed section + are the same. A command line option is added to help with the + experiment to find a good heuristics. + + * In some projects, it is common to use "[RFC PATCH]" as the subject + prefix for a patch meant for discussion rather than application. A + new option "--rfc" is a short-hand for "--subject-prefix=RFC PATCH" + to help the participants of such projects. + + * "git add --chmod=+x <pathspec>" added recently only toggled the + executable bit for paths that are either new or modified. This has + been corrected to flip the executable bit for all paths that match + the given pathspec. + + * When "git format-patch --stdout" output is placed as an in-body + header and it uses the RFC2822 header folding, "git am" failed to + put the header line back into a single logical line. The + underlying "git mailinfo" was taught to handle this properly. + + * "gitweb" can spawn "highlight" to show blob contents with + (programming) language-specific syntax highlighting, but only + when the language is known. "highlight" can however be told + to make the guess itself by giving it "--force" option, which + has been enabled. + + * "git gui" l10n to Portuguese. + + * When given an abbreviated object name that is not (or more + realistically, "no longer") unique, we gave a fatal error + "ambiguous argument". This error is now accompanied by a hint that + lists the objects beginning with the given prefix. During the + course of development of this new feature, numerous minor bugs were + uncovered and corrected, the most notable one of which is that we + gave "short SHA1 xxxx is ambiguous." twice without good reason. + + * "git log rev^..rev" is an often-used revision range specification + to show what was done on a side branch merged at rev. This has + gained a short-hand "rev^-1". In general "rev^-$n" is the same as + "^rev^$n rev", i.e. what has happened on other branches while the + history leading to nth parent was looking the other way. + + * In recent versions of cURL, GSSAPI credential delegation is + disabled by default due to CVE-2011-2192; introduce a configuration + to selectively allow enabling this. + (merge 26a7b23429 ps/http-gssapi-cred-delegation later to maint). + + * "git mergetool" learned to honor "-O<orderfile>" to control the + order of paths to present to the end user. + + * "git diff/log --ws-error-highlight=<kind>" lacked the corresponding + configuration variable to set it by default. + + * "git ls-files" learned "--recurse-submodules" option that can be + used to get a listing of tracked files across submodules (i.e. this + only works with "--cached" option, not for listing untracked or + ignored files). This would be a useful tool to sit on the upstream + side of a pipe that is read with xargs to work on all working tree + files from the top-level superproject. + + * A new credential helper that talks via "libsecret" with + implementations of XDG Secret Service API has been added to + contrib/credential/. + + * The GPG verification status shown in "%G?" pretty format specifier + was not rich enough to differentiate a signature made by an expired + key, a signature made by a revoked key, etc. New output letters + have been assigned to express them. + + * In addition to purely abbreviated commit object names, "gitweb" + learned to turn "git describe" output (e.g. v2.9.3-599-g2376d31787) + into clickable links in its output. + + * When new paths were added by "git add -N" to the index, it was + enough to circumvent the check by "git commit" to refrain from + making an empty commit without "--allow-empty". The same logic + prevented "git status" to show such a path as "new file" in the + "Changes not staged for commit" section. + + * The smudge/clean filter API expect an external process is spawned + to filter the contents for each path that has a filter defined. A + new type of "process" filter API has been added to allow the first + request to run the filter for a path to spawn a single process, and + all filtering need is served by this single process for multiple + paths, reducing the process creation overhead. + + * The user always has to say "stash@{$N}" when naming a single + element in the default location of the stash, i.e. reflogs in + refs/stash. The "git stash" command learned to accept "git stash + apply 4" as a short-hand for "git stash apply stash@{4}". + + +Performance, Internal Implementation, Development Support etc. + + * The delta-base-cache mechanism has been a key to the performance in + a repository with a tightly packed packfile, but it did not scale + well even with a larger value of core.deltaBaseCacheLimit. + + * Enhance "git status --porcelain" output by collecting more data on + the state of the index and the working tree files, which may + further be used to teach git-prompt (in contrib/) to make fewer + calls to git. + + * Extract a small helper out of the function that reads the authors + script file "git am" internally uses. + (merge a77598e jc/am-read-author-file later to maint). + + * Lifts calls to exit(2) and die() higher in the callchain in + sequencer.c files so that more helper functions in it can be used + by callers that want to handle error conditions themselves. + + * "git am" has been taught to make an internal call to "git apply"'s + innards without spawning the latter as a separate process. + + * The ref-store abstraction was introduced to the refs API so that we + can plug in different backends to store references. + + * The "unsigned char sha1[20]" to "struct object_id" conversion + continues. Notable changes in this round includes that ce->sha1, + i.e. the object name recorded in the cache_entry, turns into an + object_id. + + * JGit can show a fake ref "capabilities^{}" to "git fetch" when it + does not advertise any refs, but "git fetch" was not prepared to + see such an advertisement. When the other side disconnects without + giving any ref advertisement, we used to say "there may not be a + repository at that URL", but we may have seen other advertisement + like "shallow" and ".have" in which case we definitely know that a + repository is there. The code to detect this case has also been + updated. + + * Some codepaths in "git pack-objects" were not ready to use an + existing pack bitmap; now they are and as the result they have + become faster. + + * The codepath in "git fsck" to detect malformed tree objects has + been updated not to die but keep going after detecting them. + + * We call "qsort(array, nelem, sizeof(array[0]), fn)", and most of + the time third parameter is redundant. A new QSORT() macro lets us + omit it. + + * "git pack-objects" in a repository with many packfiles used to + spend a lot of time looking for/at objects in them; the accesses to + the packfiles are now optimized by checking the most-recently-used + packfile first. + (merge c9af708b1a jk/pack-objects-optim-mru later to maint). + + * Codepaths involved in interacting alternate object store have + been cleaned up. + + * In order for the receiving end of "git push" to inspect the + received history and decide to reject the push, the objects sent + from the sending end need to be made available to the hook and + the mechanism for the connectivity check, and this was done + traditionally by storing the objects in the receiving repository + and letting "git gc" to expire it. Instead, store the newly + received objects in a temporary area, and make them available by + reusing the alternate object store mechanism to them only while we + decide if we accept the check, and once we decide, either migrate + them to the repository or purge them immediately. + + * The require_clean_work_tree() helper was recreated in C when "git + pull" was rewritten from shell; the helper is now made available to + other callers in preparation for upcoming "rebase -i" work. + + * "git upload-pack" had its code cleaned-up and performance improved + by reducing use of timestamp-ordered commit-list, which was + replaced with a priority queue. + + * "git diff --no-index" codepath has been updated not to try to peek + into .git/ directory that happens to be under the current + directory, when we know we are operating outside any repository. + + * Update of the sequencer codebase to make it reusable to reimplement + "rebase -i" continues. + + * Git generally does not explicitly close file descriptors that were + open in the parent process when spawning a child process, but most + of the time the child does not want to access them. As Windows does + not allow removing or renaming a file that has a file descriptor + open, a slow-to-exit child can even break the parent process by + holding onto them. Use O_CLOEXEC flag to open files in various + codepaths. + + * Update "interpret-trailers" machinery and teaches it that people in + real world write all sorts of crufts in the "trailer" that was + originally designed to have the neat-o "Mail-Header: like thing" + and nothing else. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v2.10 +----------------- + +Unless otherwise noted, all the fixes since v2.9 in the maintenance +track are contained in this release (see the maintenance releases' +notes for details). + + * Clarify various ways to specify the "revision ranges" in the + documentation. + + * "diff-highlight" script (in contrib/) learned to work better with + "git log -p --graph" output. + + * The test framework left the number of tests and success/failure + count in the t/test-results directory, keyed by the name of the + test script plus the process ID. The latter however turned out not + to serve any useful purpose. The process ID part of the filename + has been removed. + + * Having a submodule whose ".git" repository is somehow corrupt + caused a few commands that recurse into submodules loop forever. + + * "git symbolic-ref -d HEAD" happily removes the symbolic ref, but + the resulting repository becomes an invalid one. Teach the command + to forbid removal of HEAD. + + * A test spawned a short-lived background process, which sometimes + prevented the test directory from getting removed at the end of the + script on some platforms. + + * Update a few tests that used to use GIT_CURL_VERBOSE to use the + newer GIT_TRACE_CURL. + + * "git pack-objects --include-tag" was taught that when we know that + we are sending an object C, we want a tag B that directly points at + C but also a tag A that points at the tag B. We used to miss the + intermediate tag B in some cases. + + * Update Japanese translation for "git-gui". + + * "git fetch http::/site/path" did not die correctly and segfaulted + instead. + + * "git commit-tree" stopped reading commit.gpgsign configuration + variable that was meant for Porcelain "git commit" in Git 2.9; we + forgot to update "git gui" to look at the configuration to match + this change. + + * "git add --chmod=+x" added recently lacked documentation, which has + been corrected. + + * "git log --cherry-pick" used to include merge commits as candidates + to be matched up with other commits, resulting a lot of wasted time. + The patch-id generation logic has been updated to ignore merges to + avoid the wastage. + + * The http transport (with curl-multi option, which is the default + these days) failed to remove curl-easy handle from a curlm session, + which led to unnecessary API failures. + + * There were numerous corner cases in which the configuration files + are read and used or not read at all depending on the directory a + Git command was run, leading to inconsistent behaviour. The code + to set-up repository access at the beginning of a Git process has + been updated to fix them. + (merge 4d0efa1 jk/setup-sequence-update later to maint). + + * "git diff -W" output needs to extend the context backward to + include the header line of the current function and also forward to + include the body of the entire current function up to the header + line of the next one. This process may have to merge two adjacent + hunks, but the code forgot to do so in some cases. + + * Performance tests done via "t/perf" did not use the same set of + build configuration if the user relied on autoconf generated + configuration. + + * "git format-patch --base=..." feature that was recently added + showed the base commit information after "-- " e-mail signature + line, which turned out to be inconvenient. The base information + has been moved above the signature line. + + * More i18n. + + * Even when "git pull --rebase=preserve" (and the underlying "git + rebase --preserve") can complete without creating any new commit + (i.e. fast-forwards), it still insisted on having a usable ident + information (read: user.email is set correctly), which was less + than nice. As the underlying commands used inside "git rebase" + would fail with a more meaningful error message and advice text + when the bogus ident matters, this extra check was removed. + + * "git gc --aggressive" used to limit the delta-chain length to 250, + which is way too deep for gaining additional space savings and is + detrimental for runtime performance. The limit has been reduced to + 50. + + * Documentation for individual configuration variables to control use + of color (like `color.grep`) said that their default value is + 'false', instead of saying their default is taken from `color.ui`. + When we updated the default value for color.ui from 'false' to + 'auto' quite a while ago, all of them broke. This has been + corrected. + + * The pretty-format specifier "%C(auto)" used by the "log" family of + commands to enable coloring of the output is taught to also issue a + color-reset sequence to the output. + + * A shell script example in check-ref-format documentation has been + fixed. + + * "git checkout <word>" does not follow the usual disambiguation + rules when the <word> can be both a rev and a path, to allow + checking out a branch 'foo' in a project that happens to have a + file 'foo' in the working tree without having to disambiguate. + This was poorly documented and the check was incorrect when the + command was run from a subdirectory. + + * Some codepaths in "git diff" used regexec(3) on a buffer that was + mmap(2)ed, which may not have a terminating NUL, leading to a read + beyond the end of the mapped region. This was fixed by introducing + a regexec_buf() helper that takes a <ptr,len> pair with REG_STARTEND + extension. + + * The procedure to build Git on Mac OS X for Travis CI hardcoded the + internal directory structure we assumed HomeBrew uses, which was a + no-no. The procedure has been updated to ask HomeBrew things we + need to know to fix this. + + * When "git rebase -i" is given a broken instruction, it told the + user to fix it with "--edit-todo", but didn't say what the step + after that was (i.e. "--continue"). + + * Documentation around tools to import from CVS was fairly outdated. + + * "git clone --recurse-submodules" lost the progress eye-candy in + recent update, which has been corrected. + + * A low-level function verify_packfile() was meant to show errors + that were detected without dying itself, but under some conditions + it didn't and died instead, which has been fixed. + + * When "git fetch" tries to find where the history of the repository + it runs in has diverged from what the other side has, it has a + mechanism to avoid digging too deep into irrelevant side branches. + This however did not work well over the "smart-http" transport due + to a design bug, which has been fixed. + + * In the codepath that comes up with the hostname to be used in an + e-mail when the user didn't tell us, we looked at ai_canonname + field in struct addrinfo without making sure it is not NULL first. + + * "git worktree", even though it used the default_abbrev setting that + ought to be affected by core.abbrev configuration variable, ignored + the variable setting. The command has been taught to read the + default set of configuration variables to correct this. + + * "git init" tried to record core.worktree in the repository's + 'config' file when GIT_WORK_TREE environment variable was set and + it was different from where GIT_DIR appears as ".git" at its top, + but the logic was faulty when .git is a "gitdir:" file that points + at the real place, causing trouble in working trees that are + managed by "git worktree". This has been corrected. + + * Codepaths that read from an on-disk loose object were too loose in + validating what they are reading is a proper object file and + sometimes read past the data they read from the disk, which has + been corrected. H/t to Gustavo Grieco for reporting. + + * The original command line syntax for "git merge", which was "git + merge <msg> HEAD <parent>...", has been deprecated for quite some + time, and "git gui" was the last in-tree user of the syntax. This + is finally fixed, so that we can move forward with the deprecation. + + * An author name, that spelled a backslash-quoted double quote in the + human readable part "My \"double quoted\" name", was not unquoted + correctly while applying a patch from a piece of e-mail. + + * Doc update to clarify what "log -3 --reverse" does. + + * Almost everybody uses DEFAULT_ABBREV to refer to the default + setting for the abbreviation, but "git blame" peeked into + underlying variable bypassing the macro for no good reason. + + * The "graph" API used in "git log --graph" miscounted the number of + output columns consumed so far when drawing a padding line, which + has been fixed; this did not affect any existing code as nobody + tried to write anything after the padding on such a line, though. + + * The code that parses the format parameter of for-each-ref command + has seen a micro-optimization. + + * When we started cURL to talk to imap server when a new enough + version of cURL library is available, we forgot to explicitly add + imap(s):// before the destination. To some folks, that didn't work + and the library tried to make HTTP(s) requests instead. + + * The ./configure script generated from configure.ac was taught how + to detect support of SSL by libcurl better. + + * The command-line completion script (in contrib/) learned to + complete "git cmd ^mas<HT>" to complete the negative end of + reference to "git cmd ^master". + (merge 49416ad22a cp/completion-negative-refs later to maint). + + * The existing "git fetch --depth=<n>" option was hard to use + correctly when making the history of an existing shallow clone + deeper. A new option, "--deepen=<n>", has been added to make this + easier to use. "git clone" also learned "--shallow-since=<date>" + and "--shallow-exclude=<tag>" options to make it easier to specify + "I am interested only in the recent N months worth of history" and + "Give me only the history since that version". + (merge cccf74e2da nd/shallow-deepen later to maint). + + * It is a common mistake to say "git blame --reverse OLD path", + expecting that the command line is dwimmed as if asking how lines + in path in an old revision OLD have survived up to the current + commit. + (merge e1d09701a4 jc/blame-reverse later to maint). + + * http.emptyauth configuration is a way to allow an empty username to + pass when attempting to authenticate using mechanisms like + Kerberos. We took an unspecified (NULL) username and sent ":" + (i.e. no username, no password) to CURLOPT_USERPWD, but did not do + the same when the username is explicitly set to an empty string. + + * "git clone" of a local repository can be done at the filesystem + level, but the codepath did not check errors while copying and + adjusting the file that lists alternate object stores. + + * Documentation for "git commit" was updated to clarify that "commit + -p <paths>" adds to the current contents of the index to come up + with what to commit. + + * A stray symbolic link in $GIT_DIR/refs/ directory could make name + resolution loop forever, which has been corrected. + + * The "submodule.<name>.path" stored in .gitmodules is never copied + to .git/config and such a key in .git/config has no meaning, but + the documentation described it and submodule.<name>.url next to + each other as if both belong to .git/config. This has been fixed. + + * In a worktree connected to a repository elsewhere, created via "git + worktree", "git checkout" attempts to protect users from confusion + by refusing to check out a branch that is already checked out in + another worktree. However, this also prevented checking out a + branch, which is designated as the primary branch of a bare + reopsitory, in a worktree that is connected to the bare + repository. The check has been corrected to allow it. + + * "git rebase" immediately after "git clone" failed to find the fork + point from the upstream. + + * When fetching from a remote that has many tags that are irrelevant + to branches we are following, we used to waste way too many cycles + when checking if the object pointed at by a tag (that we are not + going to fetch!) exists in our repository too carefully. + + * Protect our code from over-eager compilers. + + * Recent git allows submodule.<name>.branch to use a special token + "." instead of the branch name; the documentation has been updated + to describe it. + + * A hot-fix for a test added by a recent topic that went to both + 'master' and 'maint' already. + + * "git send-email" attempts to pick up valid e-mails from the + trailers, but people in real world write non-addresses there, like + "Cc: Stable <add@re.ss> # 4.8+", which broke the output depending + on the availability and vintage of Mail::Address perl module. + (merge dcfafc5214 mm/send-email-cc-cruft-after-address later to maint). + + * The Travis CI configuration we ship ran the tests with --verbose + option but this risks non-TAP output that happens to be "ok" to be + misinterpreted as TAP signalling a test that passed. This resulted + in unnecessary failure. This has been corrected by introducing a + new mode to run our tests in the test harness to send the verbose + output separately to the log file. + + * Some AsciiDoc formatter mishandles a displayed illustration with + tabs in it. Adjust a few of them in merge-base documentation to + work around them. + + * A minor regression fix for "git submodule" that was introduced + when more helper functions were reimplemented in C. + (merge 77b63ac31e sb/submodule-ignore-trailing-slash later to maint). + + * The code that we have used for the past 10+ years to cycle + 4-element ring buffers turns out to be not quite portable in + theoretical world. + (merge bb84735c80 rs/ring-buffer-wraparound later to maint). + + * "git daemon" used fixed-length buffers to turn URL to the + repository the client asked for into the server side directory + path, using snprintf() to avoid overflowing these buffers, but + allowed possibly truncated paths to the directory. This has been + tightened to reject such a request that causes overlong path to be + required to serve. + (merge 6bdb0083be jk/daemon-path-ok-check-truncation later to maint). + + * Recent update to git-sh-setup (a library of shell functions that + are used by our in-tree scripted Porcelain commands) included + another shell library git-sh-i18n without specifying where it is, + relying on the $PATH. This has been fixed to be more explicit by + prefixing $(git --exec-path) output in front. + (merge 1073094f30 ak/sh-setup-dot-source-i18n-fix later to maint). + + * Fix for a racy false-positive test failure. + (merge fdf4f6c79b as/merge-attr-sleep later to maint). + + * Portability update and workaround for builds on recent Mac OS X. + (merge a296bc0132 ls/macos-update later to maint). + + * Other minor doc, test and build updates and code cleanups. + (merge 5c238e29a8 jk/common-main later to maint). + (merge 5a5749e45b ak/pre-receive-hook-template-modefix later to maint). + (merge 6d834ac8f1 jk/rebase-config-insn-fmt-docfix later to maint). + (merge de9f7fa3b0 rs/commit-pptr-simplify later to maint). + (merge 4259d693fc sc/fmt-merge-msg-doc-markup-fix later to maint). + (merge 28fab7b23d nd/test-helpers later to maint). + (merge c2bb0c1d1e rs/cocci later to maint). + (merge 3285b7badb ps/common-info-doc later to maint). diff --git a/Documentation/RelNotes/2.3.10.txt b/Documentation/RelNotes/2.3.10.txt index 9d425d8..20c2d2c 100644 --- a/Documentation/RelNotes/2.3.10.txt +++ b/Documentation/RelNotes/2.3.10.txt @@ -7,7 +7,7 @@ Fixes since v2.3.9 * xdiff code we use to generate diffs is not prepared to handle extremely large files. It uses "int" in many places, which can overflow if we have a very large number of lines or even bytes in - our input files, for example. Cap the input size to soemwhere + our input files, for example. Cap the input size to somewhere around 1GB for now. * Some protocols (like git-remote-ext) can execute arbitrary code diff --git a/Documentation/RelNotes/2.4.10.txt b/Documentation/RelNotes/2.4.10.txt index 8621199..702d8d4 100644 --- a/Documentation/RelNotes/2.4.10.txt +++ b/Documentation/RelNotes/2.4.10.txt @@ -7,7 +7,7 @@ Fixes since v2.4.9 * xdiff code we use to generate diffs is not prepared to handle extremely large files. It uses "int" in many places, which can overflow if we have a very large number of lines or even bytes in - our input files, for example. Cap the input size to soemwhere + our input files, for example. Cap the input size to somewhere around 1GB for now. * Some protocols (like git-remote-ext) can execute arbitrary code diff --git a/Documentation/RelNotes/2.5.4.txt b/Documentation/RelNotes/2.5.4.txt index a5e8477..b8a2f93 100644 --- a/Documentation/RelNotes/2.5.4.txt +++ b/Documentation/RelNotes/2.5.4.txt @@ -7,7 +7,7 @@ Fixes since v2.5.4 * xdiff code we use to generate diffs is not prepared to handle extremely large files. It uses "int" in many places, which can overflow if we have a very large number of lines or even bytes in - our input files, for example. Cap the input size to soemwhere + our input files, for example. Cap the input size to somewhere around 1GB for now. * Some protocols (like git-remote-ext) can execute arbitrary code diff --git a/Documentation/RelNotes/2.6.1.txt b/Documentation/RelNotes/2.6.1.txt index 1e51363..f37ea89 100644 --- a/Documentation/RelNotes/2.6.1.txt +++ b/Documentation/RelNotes/2.6.1.txt @@ -7,7 +7,7 @@ Fixes since v2.6 * xdiff code we use to generate diffs is not prepared to handle extremely large files. It uses "int" in many places, which can overflow if we have a very large number of lines or even bytes in - our input files, for example. Cap the input size to soemwhere + our input files, for example. Cap the input size to somewhere around 1GB for now. * Some protocols (like git-remote-ext) can execute arbitrary code diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt index 02cb684..2669b87 100644 --- a/Documentation/blame-options.txt +++ b/Documentation/blame-options.txt @@ -28,12 +28,13 @@ include::line-range-format.txt[] -S <revs-file>:: Use revisions from revs-file instead of calling linkgit:git-rev-list[1]. ---reverse:: +--reverse <rev>..<rev>:: Walk history forward instead of backward. Instead of showing the revision in which a line appeared, this shows the last revision in which a line has existed. This requires a range of revision like START..END where the path to blame exists in - START. + START. `git blame --reverse START` is taken as `git blame + --reverse START..HEAD` for convenience. -p:: --porcelain:: diff --git a/Documentation/config.txt b/Documentation/config.txt index f4721a0..a0ab66a 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -150,27 +150,34 @@ integer:: 1024", "by 1024x1024", etc. color:: - The value for a variables that takes a color is a list of - colors (at most two) and attributes (at most one), separated - by spaces. The colors accepted are `normal`, `black`, - `red`, `green`, `yellow`, `blue`, `magenta`, `cyan` and - `white`; the attributes are `bold`, `dim`, `ul`, `blink` and - `reverse`. The first color given is the foreground; the - second is the background. The position of the attribute, if - any, doesn't matter. Attributes may be turned off specifically - by prefixing them with `no` (e.g., `noreverse`, `noul`, etc). -+ -Colors (foreground and background) may also be given as numbers between -0 and 255; these use ANSI 256-color mode (but note that not all -terminals may support this). If your terminal supports it, you may also -specify 24-bit RGB values as hex, like `#ff0ab3`. -+ -The attributes are meant to be reset at the beginning of each item -in the colored output, so setting color.decorate.branch to `black` -will paint that branch name in a plain `black`, even if the previous -thing on the same output line (e.g. opening parenthesis before the -list of branch names in `log --decorate` output) is set to be -painted with `bold` or some other attribute. + The value for a variable that takes a color is a list of + colors (at most two, one for foreground and one for background) + and attributes (as many as you want), separated by spaces. ++ +The basic colors accepted are `normal`, `black`, `red`, `green`, `yellow`, +`blue`, `magenta`, `cyan` and `white`. The first color given is the +foreground; the second is the background. ++ +Colors may also be given as numbers between 0 and 255; these use ANSI +256-color mode (but note that not all terminals may support this). If +your terminal supports it, you may also specify 24-bit RGB values as +hex, like `#ff0ab3`. ++ +The accepted attributes are `bold`, `dim`, `ul`, `blink`, `reverse`, +`italic`, and `strike` (for crossed-out or "strikethrough" letters). +The position of any attributes with respect to the colors +(before, after, or in between), doesn't matter. Specific attributes may +be turned off by prefixing them with `no` or `no-` (e.g., `noreverse`, +`no-ul`, etc). ++ +For git's pre-defined color slots, the attributes are meant to be reset +at the beginning of each item in the colored output. So setting +`color.decorate.branch` to `black` will paint that branch name in a +plain `black`, even if the previous thing on the same output line (e.g. +opening parenthesis before the list of branch names in `log --decorate` +output) is set to be painted with `bold` or some other attribute. +However, custom log formats may do more complicated and layered +coloring, and the negated forms may be useful there. pathname:: A variable that takes a pathname value can be given a @@ -441,6 +448,13 @@ specify that no proxy be used for a given domain pattern. This is useful for excluding servers inside a firewall from proxy use, while defaulting to a common proxy for external domains. +core.sshCommand:: + If this variable is set, `git fetch` and `git push` will + use the specified command instead of `ssh` when they need to + connect to a remote system. The command is in the same form as + the `GIT_SSH_COMMAND` environment variable and is overridden + when the environment variable is set. + core.ignoreStat:: If true, Git will avoid using lstat() calls to detect if files have changed by setting the "assume-unchanged" bit for those tracked files @@ -939,7 +953,8 @@ color.branch:: A boolean to enable/disable color in the output of linkgit:git-branch[1]. May be set to `always`, `false` (or `never`) or `auto` (or `true`), in which case colors are used - only when the output is to a terminal. Defaults to false. + only when the output is to a terminal. If unset, then the + value of `color.ui` is used (`auto` by default). color.branch.<slot>:: Use customized color for branch coloration. `<slot>` is one of @@ -954,7 +969,8 @@ color.diff:: linkgit:git-log[1], and linkgit:git-show[1] will use color for all patches. If it is set to `true` or `auto`, those commands will only use color when output is to the terminal. - Defaults to false. + If unset, then the value of `color.ui` is used (`auto` by + default). + This does not affect linkgit:git-format-patch[1] or the 'git-diff-{asterisk}' plumbing commands. Can be overridden on the @@ -977,7 +993,8 @@ color.decorate.<slot>:: color.grep:: When set to `always`, always highlight matches. When `false` (or `never`), never. When set to `true` or `auto`, use color only - when the output is written to the terminal. Defaults to `false`. + when the output is written to the terminal. If unset, then the + value of `color.ui` is used (`auto` by default). color.grep.<slot>:: Use customized color for grep colorization. `<slot>` specifies which @@ -1010,7 +1027,8 @@ color.interactive:: and displays (such as those used by "git-add --interactive" and "git-clean --interactive"). When false (or `never`), never. When set to `true` or `auto`, use colors only when the output is - to the terminal. Defaults to false. + to the terminal. If unset, then the value of `color.ui` is + used (`auto` by default). color.interactive.<slot>:: Use customized color for 'git add --interactive' and 'git clean @@ -1026,13 +1044,15 @@ color.showBranch:: A boolean to enable/disable color in the output of linkgit:git-show-branch[1]. May be set to `always`, `false` (or `never`) or `auto` (or `true`), in which case colors are used - only when the output is to a terminal. Defaults to false. + only when the output is to a terminal. If unset, then the + value of `color.ui` is used (`auto` by default). color.status:: A boolean to enable/disable color in the output of linkgit:git-status[1]. May be set to `always`, `false` (or `never`) or `auto` (or `true`), in which case colors are used - only when the output is to a terminal. Defaults to false. + only when the output is to a terminal. If unset, then the + value of `color.ui` is used (`auto` by default). color.status.<slot>:: Use customized color for status colorization. `<slot>` is @@ -1187,6 +1207,15 @@ difftool.<tool>.cmd:: difftool.prompt:: Prompt before each invocation of the diff tool. +fastimport.unpackLimit:: + If the number of objects imported by linkgit:git-fast-import[1] + is below this limit, then the objects will be unpacked into + loose object files. However if the number of imported objects + equals or exceeds this limit then the pack will be stored as a + pack. Storing the pack from a fast-import can make the import + operation complete faster, especially on slow filesystems. If + not set, the value of `transfer.unpackLimit` is used instead. + fetch.recurseSubmodules:: This option can be either set to a boolean value or to 'on-demand'. Setting it to a boolean changes the behavior of fetch and pull to @@ -1218,6 +1247,11 @@ fetch.prune:: If true, fetch will automatically behave as if the `--prune` option was given on the command line. See also `remote.<name>.prune`. +fetch.output:: + Control how ref update status is printed. Valid values are + `full` and `compact`. Default value is `full`. See section + OUTPUT in linkgit:git-fetch[1] for detail. + format.attach:: Enable multipart/mixed attachments as the default for 'format-patch'. The value can also be a double quoted string @@ -1225,6 +1259,16 @@ format.attach:: value as the boundary. See the --attach option in linkgit:git-format-patch[1]. +format.from:: + Provides the default value for the `--from` option to format-patch. + Accepts a boolean value, or a name and email address. If false, + format-patch defaults to `--no-from`, using commit authors directly in + the "From:" field of patch mails. If true, format-patch defaults to + `--from`, using your committer identity in the "From:" field of patch + mails and including a "From:" field in the body of the patch mail if + different. If set to a non-boolean value, format-patch uses that + value instead of your committer identity. Defaults to false. + format.numbered:: A boolean which can enable or disable sequence numbers in patch subjects. It defaults to "auto" which enables it only if there @@ -1328,7 +1372,7 @@ fsck.skipList:: gc.aggressiveDepth:: The depth parameter used in the delta compression algorithm used by 'git gc --aggressive'. This defaults - to 250. + to 50. gc.aggressiveWindow:: The window size parameter used in the delta compression @@ -1692,6 +1736,20 @@ http.emptyAuth:: a username in the URL, as libcurl normally requires a username for authentication. +http.delegation:: + Control GSSAPI credential delegation. The delegation is disabled + by default in libcurl since version 7.21.7. Set parameter to tell + the server what it is allowed to delegate when it comes to user + credentials. Used with GSS/kerberos. Possible values are: ++ +-- +* `none` - Don't allow any delegation. +* `policy` - Delegates if and only if the OK-AS-DELEGATE flag is set in the + Kerberos service ticket, which is a matter of realm policy. +* `always` - Unconditionally allow the server to delegate. +-- + + http.extraHeader:: Pass an additional HTTP header when communicating with a server. If more than one such entry exists, all of them are added as extra @@ -2392,15 +2450,20 @@ rebase.missingCommitsCheck:: command in the todo-list. Defaults to "ignore". -rebase.instructionFormat +rebase.instructionFormat:: A format string, as specified in linkgit:git-log[1], to be used for the instruction list during an interactive rebase. The format will automatically have the long commit hash prepended to the format. receive.advertiseAtomic:: By default, git-receive-pack will advertise the atomic push - capability to its clients. If you don't want to this capability - to be advertised, set this variable to false. + capability to its clients. If you don't want to advertise this + capability, set this variable to false. + +receive.advertisePushOptions:: + By default, git-receive-pack will advertise the push options + capability to its clients. If you don't want to advertise this + capability, set this variable to false. receive.autogc:: By default, git-receive-pack will run "git-gc --auto" after @@ -2455,6 +2518,15 @@ receive.fsck.skipList:: can be safely ignored such as invalid committer email addresses. Note: corrupt objects cannot be skipped with this setting. +receive.keepAlive:: + After receiving the pack from the client, `receive-pack` may + produce no output (if `--quiet` was specified) while processing + the pack, causing some networks to drop the TCP connection. + With this option set, if `receive-pack` does not transmit + any data in this phase for `receive.keepAlive` seconds, it will + send a short keepalive packet. The default is 5 seconds; set + to 0 to disable keepalives entirely. + receive.unpackLimit:: If the number of objects received in a push is below this limit then the objects will be unpacked into loose object @@ -2465,6 +2537,12 @@ receive.unpackLimit:: especially on slow filesystems. If not set, the value of `transfer.unpackLimit` is used instead. +receive.maxInputSize:: + If the size of the incoming pack stream is larger than this + limit, then git-receive-pack will error out, instead of + accepting the pack file. If not set or set to 0, then the size + is unlimited. + receive.denyDeletes:: If set to true, git-receive-pack will deny a ref update that deletes the ref. Use this to prevent such a ref deletion via a push. @@ -2747,12 +2825,13 @@ stash.showStat:: option will show diffstat of the stash. Defaults to true. See description of 'show' command in linkgit:git-stash[1]. -submodule.<name>.path:: submodule.<name>.url:: - The path within this project and URL for a submodule. These - variables are initially populated by 'git submodule init'. See - linkgit:git-submodule[1] and linkgit:gitmodules[5] for - details. + The URL for a submodule. This variable is copied from the .gitmodules + file to the git config via 'git submodule init'. The user can change + the configured URL before obtaining the submodule via 'git submodule + update'. After obtaining the submodule, the presence of this variable + is used as a sign whether the submodule is of interest to git commands. + See linkgit:git-submodule[1] and linkgit:gitmodules[5] for details. submodule.<name>.update:: The default update procedure for a submodule. This variable @@ -2795,6 +2874,18 @@ submodule.fetchJobs:: in parallel. A value of 0 will give some reasonable default. If unset, it defaults to 1. +submodule.alternateLocation:: + Specifies how the submodules obtain alternates when submodules are + cloned. Possible values are `no`, `superproject`. + By default `no` is assumed, which doesn't add references. When the + value is set to `superproject` the submodule to be cloned computes + its alternates location relative to the superprojects alternate. + +submodule.alternateErrorStrategy + Specifies how to treat errors with the alternates for a submodule + as computed via `submodule.alternateLocation`. Possible values are + `ignore`, `info`, `die`. Default is `die`. + tag.forceSignAnnotated:: A boolean to specify whether annotated tags created should be GPG signed. If `--annotate` is specified on the command line, it takes @@ -2881,6 +2972,21 @@ uploadpack.keepAlive:: `uploadpack.keepAlive` seconds. Setting this option to 0 disables keepalive packets entirely. The default is 5 seconds. +uploadpack.packObjectsHook:: + If this option is set, when `upload-pack` would run + `git pack-objects` to create a packfile for a client, it will + run this shell command instead. The `pack-objects` command and + arguments it _would_ have run (including the `git pack-objects` + at the beginning) are appended to the shell command. The stdin + and stdout of the hook are treated as if `pack-objects` itself + was run. I.e., `upload-pack` will feed input intended for + `pack-objects` to the hook, and expects a completed packfile on + stdout. ++ +Note that this configuration variable is ignored if it is seen in the +repository-level config (this is a safety measure against fetching from +untrusted repositories). + url.<base>.insteadOf:: Any URL that starts with this value will be rewritten to start, instead, with <base>. In cases where some site serves a diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt index d5a5b17..58f4bd6 100644 --- a/Documentation/diff-config.txt +++ b/Documentation/diff-config.txt @@ -122,10 +122,11 @@ diff.suppressBlankEmpty:: diff.submodule:: Specify the format in which differences in submodules are - shown. The "log" format lists the commits in the range like - linkgit:git-submodule[1] `summary` does. The "short" format - format just shows the names of the commits at the beginning - and end of the range. Defaults to short. + shown. The "short" format just shows the names of the commits + at the beginning and end of the range. The "log" format lists + the commits in the range like linkgit:git-submodule[1] `summary` + does. The "diff" format shows an inline diff of the changed + contents of the submodule. Defaults to "short". diff.wordRegex:: A POSIX Extended Regular Expression used to determine what is a "word" @@ -170,10 +171,11 @@ diff.tool:: include::mergetools-diff.txt[] +diff.indentHeuristic:: diff.compactionHeuristic:: - Set this option to `true` to enable an experimental heuristic that - shifts the hunk boundary in an attempt to make the resulting - patch easier to read. + Set one of these options to `true` to enable one of two + experimental heuristics that shift diff hunk boundaries to + make patches easier to read. diff.algorithm:: Choose a diff algorithm. The variants are as follows: @@ -191,3 +193,9 @@ diff.algorithm:: low-occurrence common elements". -- + + +diff.wsErrorHighlight:: + A comma separated list of `old`, `new`, `context`, that + specifies how whitespace errors on lines are highlighted + with `color.diff.whitespace`. Can be overridden by the + command line option `--ws-error-highlight=<kind>` diff --git a/Documentation/diff-heuristic-options.txt b/Documentation/diff-heuristic-options.txt new file mode 100644 index 0000000..36cb549 --- /dev/null +++ b/Documentation/diff-heuristic-options.txt @@ -0,0 +1,7 @@ +--indent-heuristic:: +--no-indent-heuristic:: +--compaction-heuristic:: +--no-compaction-heuristic:: + These are to help debugging and tuning experimental heuristics + (which are off by default) that shift diff hunk boundaries to + make patches easier to read. diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index 705a873..e6215c3 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -63,12 +63,7 @@ ifndef::git-format-patch[] Synonym for `-p --raw`. endif::git-format-patch[] ---compaction-heuristic:: ---no-compaction-heuristic:: - These are to help debugging and tuning an experimental - heuristic (which is off by default) that shifts the hunk - boundary in an attempt to make the resulting patch easier - to read. +include::diff-heuristic-options.txt[] --minimal:: Spend extra time to make sure the smallest possible @@ -210,13 +205,16 @@ any of those replacements occurred. of the `--diff-filter` option on what the status letters mean. --submodule[=<format>]:: - Specify how differences in submodules are shown. When `--submodule` - or `--submodule=log` is given, the 'log' format is used. This format lists - the commits in the range like linkgit:git-submodule[1] `summary` does. - Omitting the `--submodule` option or specifying `--submodule=short`, - uses the 'short' format. This format just shows the names of the commits - at the beginning and end of the range. Can be tweaked via the - `diff.submodule` configuration variable. + Specify how differences in submodules are shown. When specifying + `--submodule=short` the 'short' format is used. This format just + shows the names of the commits at the beginning and end of the range. + When `--submodule` or `--submodule=log` is specified, the 'log' + format is used. This format lists the commits in the range like + linkgit:git-submodule[1] `summary` does. When `--submodule=diff` + is specified, the 'diff' format is used. This format shows an + inline diff of the changes in the submodule contents between the + commit range. Defaults to `diff.submodule` or the 'short' format + if the config option is unset. --color[=<when>]:: Show colored diff. @@ -310,6 +308,8 @@ ifndef::git-format-patch[] lines are highlighted. E.g. `--ws-error-highlight=new,old` highlights whitespace errors on both deleted and added lines. `all` can be used as a short-hand for `old,new,context`. + The `diff.wsErrorHighlight` configuration variable can be + used to specify the default behaviour. endif::git-format-patch[] @@ -569,5 +569,16 @@ endif::git-format-patch[] --no-prefix:: Do not show any source or destination prefix. +--line-prefix=<prefix>:: + Prepend an additional prefix to every line of output. + +--ita-invisible-in-index:: + By default entries added by "git add -N" appear as an existing + empty file in "git diff" and a new file in "git diff --cached". + This option makes the entry appear as a new file in "git diff" + and non-existent in "git diff --cached". This option could be + reverted with `--ita-visible-in-index`. Both options are + experimental and could be removed in future. + For more detailed explanation on these common options, see also linkgit:gitdiffcore[7]. diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index 9eab1f5..fb6bebb 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -14,6 +14,20 @@ linkgit:git-clone[1]), deepen or shorten the history to the specified number of commits. Tags for the deepened commits are not fetched. +--deepen=<depth>:: + Similar to --depth, except it specifies the number of commits + from the current shallow boundary instead of from the tip of + each remote branch history. + +--shallow-since=<date>:: + Deepen or shorten the history of a shallow repository to + include all reachable commits after <date>. + +--shallow-exclude=<revision>:: + Deepen or shorten the history of a shallow repository to + exclude commits reachable from a specified remote branch or tag. + This option can be specified multiple times. + --unshallow:: If the source repository is complete, convert a shallow repository to a complete one, removing all the limitations diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 6a96a66..7ed63dc 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -11,7 +11,7 @@ SYNOPSIS 'git add' [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p] [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] - [--] [<pathspec>...] + [--chmod=(+|-)x] [--] [<pathspec>...] DESCRIPTION ----------- @@ -165,6 +165,11 @@ for "git add --no-all <pathspec>...", i.e. ignored removed files. be ignored, no matter if they are already present in the work tree or not. +--chmod=(+|-)x:: + Override the executable bit of the added files. The executable + bit is only changed in the index, the files on disk are left + unchanged. + \--:: This option can be used to separate command-line options from the list of files, (useful when filenames might be mistaken diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt index 8dd9e4f..12879e4 100644 --- a/Documentation/git-am.txt +++ b/Documentation/git-am.txt @@ -116,7 +116,8 @@ default. You can use `--no-utf8` to override this. By default the command will try to detect the patch format automatically. This option allows the user to bypass the automatic detection and specify the patch format that the patch(es) should be - interpreted as. Valid formats are mbox, stgit, stgit-series and hg. + interpreted as. Valid formats are mbox, mboxrd, + stgit, stgit-series and hg. -i:: --interactive:: diff --git a/Documentation/git-annotate.txt b/Documentation/git-annotate.txt index 05fd482..94be4b8 100644 --- a/Documentation/git-annotate.txt +++ b/Documentation/git-annotate.txt @@ -23,6 +23,7 @@ familiar command name for people coming from other SCM systems. OPTIONS ------- include::blame-options.txt[] +include::diff-heuristic-options.txt[] SEE ALSO -------- diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt index ba54175..fdc3aea 100644 --- a/Documentation/git-blame.txt +++ b/Documentation/git-blame.txt @@ -10,7 +10,7 @@ SYNOPSIS [verse] 'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental] [-L <range>] [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>] - [--progress] [--abbrev=<n>] [<rev> | --contents <file> | --reverse <rev>] + [--progress] [--abbrev=<n>] [<rev> | --contents <file> | --reverse <rev>..<rev>] [--] <file> DESCRIPTION @@ -89,6 +89,8 @@ include::blame-options.txt[] abbreviated object name, use <n>+1 digits. Note that 1 column is used for a caret to mark the boundary commit. +include::diff-heuristic-options.txt[] + THE PORCELAIN FORMAT -------------------- diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt index 18d03d8..204541c 100644 --- a/Documentation/git-cat-file.txt +++ b/Documentation/git-cat-file.txt @@ -9,18 +9,22 @@ git-cat-file - Provide content or type and size information for repository objec SYNOPSIS -------- [verse] -'git cat-file' (-t [--allow-unknown-type]| -s [--allow-unknown-type]| -e | -p | <type> | --textconv ) <object> -'git cat-file' (--batch | --batch-check) [--follow-symlinks] +'git cat-file' (-t [--allow-unknown-type]| -s [--allow-unknown-type]| -e | -p | <type> | --textconv | --filters ) [--path=<path>] <object> +'git cat-file' (--batch | --batch-check) [ --textconv | --filters ] [--follow-symlinks] DESCRIPTION ----------- In its first form, the command provides the content or the type of an object in the repository. The type is required unless `-t` or `-p` is used to find the -object type, or `-s` is used to find the object size, or `--textconv` is used -(which implies type "blob"). +object type, or `-s` is used to find the object size, or `--textconv` or +`--filters` is used (which imply type "blob"). In the second form, a list of objects (separated by linefeeds) is provided on -stdin, and the SHA-1, type, and size of each object is printed on stdout. +stdin, and the SHA-1, type, and size of each object is printed on stdout. The +output format can be overridden using the optional `<format>` argument. If +either `--textconv` or `--filters` was specified, the input is expected to +list the object names followed by the path name, separated by a single white +space, so that the appropriate drivers can be determined. OPTIONS ------- @@ -54,19 +58,35 @@ OPTIONS --textconv:: Show the content as transformed by a textconv filter. In this case, - <object> has be of the form <tree-ish>:<path>, or :<path> in order - to apply the filter to the content recorded in the index at <path>. + <object> has to be of the form <tree-ish>:<path>, or :<path> in + order to apply the filter to the content recorded in the index at + <path>. + +--filters:: + Show the content as converted by the filters configured in + the current working tree for the given <path> (i.e. smudge filters, + end-of-line conversion, etc). In this case, <object> has to be of + the form <tree-ish>:<path>, or :<path>. + +--path=<path>:: + For use with --textconv or --filters, to allow specifying an object + name and a path separately, e.g. when it is difficult to figure out + the revision from which the blob came. --batch:: --batch=<format>:: Print object information and contents for each object provided - on stdin. May not be combined with any other options or arguments. - See the section `BATCH OUTPUT` below for details. + on stdin. May not be combined with any other options or arguments + except `--textconv` or `--filters`, in which case the input lines + also need to specify the path, separated by white space. See the + section `BATCH OUTPUT` below for details. --batch-check:: --batch-check=<format>:: Print object information for each object provided on stdin. May - not be combined with any other options or arguments. See the + not be combined with any other options or arguments except + `--textconv` or `--filters`, in which case the input lines also + need to specify the path, separated by white space. See the section `BATCH OUTPUT` below for details. --batch-all-objects:: diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt index 91a3622..8611a99 100644 --- a/Documentation/git-check-ref-format.txt +++ b/Documentation/git-check-ref-format.txt @@ -118,8 +118,8 @@ $ git check-ref-format --branch @{-1} * Determine the reference name to use for a new branch: + ------------ -$ ref=$(git check-ref-format --normalize "refs/heads/$newbranch") || -die "we do not like '$newbranch' as a branch name." +$ ref=$(git check-ref-format --normalize "refs/heads/$newbranch")|| +{ echo "we do not like '$newbranch' as a branch name." >&2 ; exit 1 ; } ------------ GIT diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index 7a2201b..8e2c066 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -419,6 +419,18 @@ $ git reflog -2 HEAD # or $ git log -g -2 HEAD ------------ +ARGUMENT DISAMBIGUATION +----------------------- + +When there is only one argument given and it is not `--` (e.g. "git +checkout abc"), and when the argument is both a valid `<tree-ish>` +(e.g. a branch "abc" exists) and a valid `<pathspec>` (e.g. a file +or a directory whose name is "abc" exists), Git would usually ask +you to disambiguate. Because checking out a branch is so common an +operation, however, "git checkout abc" takes "abc" as a `<tree-ish>` +in such a situation. Use `git checkout -- <pathspec>` if you want +to checkout these paths out of the index. + EXAMPLES -------- diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index ec41d3d..35cc34b 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -90,13 +90,16 @@ If you want to break the dependency of a repository cloned with `-s` on its source repository, you can simply run `git repack -a` to copy all objects from the source repository into a pack in the cloned repository. ---reference <repository>:: +--reference[-if-able] <repository>:: If the reference repository is on the local machine, automatically setup `.git/objects/info/alternates` to obtain objects from the reference repository. Using an already existing repository as an alternate will require fewer objects to be copied from the repository being cloned, reducing network and local storage costs. + When using the `--reference-if-able`, a non existing + directory is skipped with a warning instead of aborting + the clone. + *NOTE*: see the NOTE for the `--shared` option, and also the `--dissociate` option. @@ -194,6 +197,14 @@ objects from the source repository into a pack in the cloned repository. tips of all branches. If you want to clone submodules shallowly, also pass `--shallow-submodules`. +--shallow-since=<date>:: + Create a shallow clone with a history after the specified time. + +--shallow-exclude=<revision>:: + Create a shallow clone with a history, excluding commits + reachable from a specified remote branch or tag. This option + can be specified multiple times. + --[no-]single-branch:: Clone only the history leading to the tip of a single branch, either specified by the `--branch` option or the primary diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index b0a294d..f2ab0ee 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -29,7 +29,8 @@ The content to be added can be specified in several ways: 2. by using 'git rm' to remove files from the working tree and the index, again before using the 'commit' command; -3. by listing files as arguments to the 'commit' command, in which +3. by listing files as arguments to the 'commit' command + (without --interactive or --patch switch), in which case the commit will ignore changes staged in the index, and instead record the current content of the listed files (which must already be known to Git); @@ -41,7 +42,8 @@ The content to be added can be specified in several ways: actual commit; 5. by using the --interactive or --patch switches with the 'commit' command - to decide one by one which files or hunks should be part of the commit, + to decide one by one which files or hunks should be part of the commit + in addition to contents in the index, before finalizing the operation. See the ``Interactive Mode'' section of linkgit:git-add[1] to learn how to operate these modes. diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt index 2ff3568..cb9b4d2 100644 --- a/Documentation/git-count-objects.txt +++ b/Documentation/git-count-objects.txt @@ -38,6 +38,11 @@ objects nor valid packs + size-garbage: disk space consumed by garbage files, in KiB (unless -H is specified) ++ +alternate: absolute path of alternate object databases; may appear +multiple times, one line per path. Note that if the path contains +non-printable characters, it may be surrounded by double-quotes and +contain C-style backslashed escape sequences. -H:: --human-readable:: diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt index 41207a2..de1ebed 100644 --- a/Documentation/git-cvsimport.txt +++ b/Documentation/git-cvsimport.txt @@ -22,7 +22,7 @@ DESCRIPTION deprecated; it does not work with cvsps version 3 and later. If you are performing a one-shot import of a CVS repository consider using http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or -https://github.com/BartMassey/parsecvs[parsecvs]. +http://www.catb.org/esr/cvs-fast-export/[cvs-fast-export]. Imports a CVS repository into Git. It will either create a new repository, or incrementally import into an existing one. diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index c105f21..2b76265 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -136,6 +136,8 @@ Performance and Compression Tuning Maximum size of each output packfile. The default is unlimited. +fastimport.unpackLimit:: + See linkgit:git-config[1] Performance ----------- diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt index 24417ee..d45f6ad 100644 --- a/Documentation/git-fetch-pack.txt +++ b/Documentation/git-fetch-pack.txt @@ -87,6 +87,20 @@ be in a separate packet, and the list must end with a flush packet. 'git-upload-pack' treats the special depth 2147483647 as infinite even if there is an ancestor-chain that long. +--shallow-since=<date>:: + Deepen or shorten the history of a shallow'repository to + include all reachable commits after <date>. + +--shallow-exclude=<revision>:: + Deepen or shorten the history of a shallow repository to + exclude commits reachable from a specified remote branch or tag. + This option can be specified multiple times. + +--deepen-relative:: + Argument --depth specifies the number of commits from the + current shallow boundary instead of from the tip of each + remote branch history. + --no-progress:: Do not show the progress. diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt index efe56e0..9e42169 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -99,6 +99,57 @@ The latter use of the `remote.<repository>.fetch` values can be overridden by giving the `--refmap=<refspec>` parameter(s) on the command line. +OUTPUT +------ + +The output of "git fetch" depends on the transport method used; this +section describes the output when fetching over the Git protocol +(either locally or via ssh) and Smart HTTP protocol. + +The status of the fetch is output in tabular form, with each line +representing the status of a single ref. Each line is of the form: + +------------------------------- + <flag> <summary> <from> -> <to> [<reason>] +------------------------------- + +The status of up-to-date refs is shown only if the --verbose option is +used. + +In compact output mode, specified with configuration variable +fetch.output, if either entire `<from>` or `<to>` is found in the +other string, it will be substituted with `*` in the other string. For +example, `master -> origin/master` becomes `master -> origin/*`. + +flag:: + A single character indicating the status of the ref: +(space);; for a successfully fetched fast-forward; +`+`;; for a successful forced update; +`-`;; for a successfully pruned ref; +`t`;; for a successful tag update; +`*`;; for a successfully fetched new ref; +`!`;; for a ref that was rejected or failed to update; and +`=`;; for a ref that was up to date and did not need fetching. + +summary:: + For a successfully fetched ref, the summary shows the old and new + values of the ref in a form suitable for using as an argument to + `git log` (this is `<old>..<new>` in most cases, and + `<old>...<new>` for forced non-fast-forward updates). + +from:: + The name of the remote ref being fetched from, minus its + `refs/<type>/` prefix. In the case of deletion, the name of + the remote ref is "(none)". + +to:: + The name of the local ref being updated, minus its + `refs/<type>/` prefix. + +reason:: + A human-readable explanation. In the case of successfully fetched + refs, no explanation is needed. For a failed ref, the reason for + failure is described. EXAMPLES -------- diff --git a/Documentation/git-fmt-merge-msg.txt b/Documentation/git-fmt-merge-msg.txt index 6526b17..44892c4 100644 --- a/Documentation/git-fmt-merge-msg.txt +++ b/Documentation/git-fmt-merge-msg.txt @@ -60,10 +60,10 @@ merge.summary:: EXAMPLE ------- --- +--------- $ git fetch origin master $ git fmt-merge-msg --log <$GIT_DIR/FETCH_HEAD --- +--------- Print a log message describing a merge of the "master" branch from the "origin" remote. diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 9624c84..9b200b3 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -19,7 +19,8 @@ SYNOPSIS [--start-number <n>] [--numbered-files] [--in-reply-to=Message-Id] [--suffix=.<sfx>] [--ignore-if-in-upstream] - [--subject-prefix=Subject-Prefix] [(--reroll-count|-v) <n>] + [--rfc] [--subject-prefix=Subject-Prefix] + [(--reroll-count|-v) <n>] [--to=<email>] [--cc=<email>] [--[no-]cover-letter] [--quiet] [--notes[=<ref>]] [<common diff options>] @@ -172,6 +173,11 @@ will want to ensure that threading is disabled for `git send-email`. allows for useful naming of a patch series, and can be combined with the `--numbered` option. +--rfc:: + Alias for `--subject-prefix="RFC PATCH"`. RFC means "Request For + Comments"; use this when sending an experimental patch for + discussion rather than application. + -v <n>:: --reroll-count=<n>:: Mark the series as the <n>-th iteration of the topic. The diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt index 7fc68eb..b9f060e 100644 --- a/Documentation/git-fsck.txt +++ b/Documentation/git-fsck.txt @@ -11,7 +11,8 @@ SYNOPSIS [verse] 'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs] [--[no-]full] [--strict] [--verbose] [--lost-found] - [--[no-]dangling] [--[no-]progress] [--connectivity-only] [<object>*] + [--[no-]dangling] [--[no-]progress] [--connectivity-only] + [--[no-]name-objects] [<object>*] DESCRIPTION ----------- @@ -82,6 +83,12 @@ index file, all SHA-1 references in `refs` namespace, and all reflogs a blob, the contents are written into the file, rather than its object name. +--name-objects:: + When displaying names of reachable objects, in addition to the + SHA-1 also display a name that describes *how* they are reachable, + compatible with linkgit:git-rev-parse[1], e.g. + `HEAD@{1234567890}~25^2:src/`. + --[no-]progress:: Progress status is reported on the standard error stream by default when it is attached to a terminal, unless diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt index 7a4e055..1b4b65d 100644 --- a/Documentation/git-index-pack.txt +++ b/Documentation/git-index-pack.txt @@ -87,6 +87,8 @@ OPTIONS Specifying 0 will cause Git to auto-detect the number of CPU's and use maximum 3 threads. +--max-input-size=<size>:: + Die, if the pack is larger than <size>. Note ---- diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt index 93d1db6..e99bda6 100644 --- a/Documentation/git-interpret-trailers.txt +++ b/Documentation/git-interpret-trailers.txt @@ -48,19 +48,21 @@ with only spaces at the end of the commit message part, one blank line will be added before the new trailer. Existing trailers are extracted from the input message by looking for -a group of one or more lines that contain a colon (by default), where -the group is preceded by one or more empty (or whitespace-only) lines. +a group of one or more lines that (i) are all trailers, or (ii) contains at +least one Git-generated trailer and consists of at least 25% trailers. +The group must be preceded by one or more empty (or whitespace-only) lines. The group must either be at the end of the message or be the last non-whitespace lines before a line that starts with '---'. Such three minus signs start the patch part of the message. -When reading trailers, there can be whitespaces before and after the +When reading trailers, there can be whitespaces after the token, the separator and the value. There can also be whitespaces -inside the token and the value. +inside the token and the value. The value may be split over multiple lines with +each subsequent line starting with whitespace, like the "folding" in RFC 822. Note that 'trailers' do not follow and are not intended to follow many -rules for RFC 822 headers. For example they do not follow the line -folding rules, the encoding rules and probably many other rules. +rules for RFC 822 headers. For example they do not follow +the encoding rules and probably many other rules. OPTIONS ------- diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 4a6c47f..32246fd 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -198,6 +198,10 @@ log.showRoot:: `git log -p` output would be shown without a diff attached. The default is `true`. +log.showSignature:: + If `true`, `git log` and related commands will act as if the + `--show-signature` option was passed to them. + mailmap.*:: See linkgit:git-shortlog[1]. diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt index 078b556..446209e 100644 --- a/Documentation/git-ls-files.txt +++ b/Documentation/git-ls-files.txt @@ -18,7 +18,8 @@ SYNOPSIS [--exclude-per-directory=<file>] [--exclude-standard] [--error-unmatch] [--with-tree=<tree-ish>] - [--full-name] [--abbrev] [--] [<file>...] + [--full-name] [--recurse-submodules] + [--abbrev] [--] [<file>...] DESCRIPTION ----------- @@ -137,6 +138,10 @@ a space) at the start of each line: option forces paths to be output relative to the project top directory. +--recurse-submodules:: + Recursively calls ls-files on each submodule in the repository. + Currently there is only support for the --cached mode. + --abbrev[=<n>]:: Instead of showing the full 40-byte hexadecimal object lines, show only a partial prefix. @@ -159,8 +164,7 @@ not accessible in the working tree. + <eolattr> is the attribute that is used when checking out or committing, it is either "", "-text", "text", "text=auto", "text eol=lf", "text eol=crlf". -Note: Currently Git does not support "text=auto eol=lf" or "text=auto eol=crlf", -that may change in the future. +Since Git 2.10 "text=auto eol=lf" and "text=auto eol=crlf" are supported. + Both the <eolinfo> in the index ("i/<eolinfo>") and in the working tree ("w/<eolinfo>") are shown for regular files, diff --git a/Documentation/git-mailsplit.txt b/Documentation/git-mailsplit.txt index 4d1b871..e3b2a88 100644 --- a/Documentation/git-mailsplit.txt +++ b/Documentation/git-mailsplit.txt @@ -8,7 +8,8 @@ git-mailsplit - Simple UNIX mbox splitter program SYNOPSIS -------- [verse] -'git mailsplit' [-b] [-f<nn>] [-d<prec>] [--keep-cr] -o<directory> [--] [(<mbox>|<Maildir>)...] +'git mailsplit' [-b] [-f<nn>] [-d<prec>] [--keep-cr] [--mboxrd] + -o<directory> [--] [(<mbox>|<Maildir>)...] DESCRIPTION ----------- @@ -47,6 +48,10 @@ OPTIONS --keep-cr:: Do not remove `\r` from lines ending with `\r\n`. +--mboxrd:: + Input is of the "mboxrd" format and "^>+From " line escaping is + reversed. + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt index 808426f..b968b64 100644 --- a/Documentation/git-merge-base.txt +++ b/Documentation/git-merge-base.txt @@ -80,8 +80,8 @@ which is reachable from both 'A' and 'B' through the parent relationship. For example, with this topology: - o---o---o---B - / + o---o---o---B + / ---o---1---o---o---o---A the merge base between 'A' and 'B' is '1'. @@ -116,11 +116,11 @@ the best common ancestor of all commits. When the history involves criss-cross merges, there can be more than one 'best' common ancestor for two commits. For example, with this topology: - ---1---o---A - \ / - X - / \ - ---2---o---o---B + ---1---o---A + \ / + X + / \ + ---2---o---o---B both '1' and '2' are merge-bases of A and B. Neither one is better than the other (both are 'best' merge bases). When the `--all` option is not given, @@ -154,13 +154,13 @@ topic origin/master`, the history of remote-tracking branch `origin/master` may have been rewound and rebuilt, leading to a history of this shape: - o---B1 - / + o---B1 + / ---o---o---B2--o---o---o---B (origin/master) - \ - B3 - \ - Derived (topic) + \ + B3 + \ + Derived (topic) where `origin/master` used to point at commits B3, B2, B1 and now it points at B, and your `topic` branch was started on top of it back diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt index e846c2e..3622d66 100644 --- a/Documentation/git-mergetool.txt +++ b/Documentation/git-mergetool.txt @@ -79,6 +79,13 @@ success of the resolution after the custom tool has exited. Prompt before each invocation of the merge resolution program to give the user a chance to skip the path. +-O<orderfile>:: + Process files in the order specified in the + <orderfile>, which has one shell glob pattern per line. + This overrides the `diff.orderFile` configuration variable + (see linkgit:git-config[1]). To cancel `diff.orderFile`, + use `-O/dev/null`. + TEMPORARY FILES --------------- `git mergetool` creates `*.orig` backup files while resolving merges. diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 927a034..47b77e6 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] + [-u | --set-upstream] [--push-option=<string>] [--[no-]signed|--sign=(true|false|if-asked)] [--force-with-lease[=<refname>[:<expect>]]] [--no-verify] [<repository> [<refspec>...]] @@ -156,6 +156,12 @@ already exists on the remote side. Either all refs are updated, or on error, no refs are updated. If the server does not support atomic pushes the push will fail. +-o:: +--push-option:: + Transmit the given string to the server, which passes them to + the pre-receive as well as the post-receive hook. The given string + must not contain a NUL or LF character. + --receive-pack=<git-receive-pack>:: --exec=<git-receive-pack>:: Path to the 'git-receive-pack' program on the remote diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt index 000ee8d..0ccd5fb 100644 --- a/Documentation/git-receive-pack.txt +++ b/Documentation/git-receive-pack.txt @@ -33,6 +33,9 @@ post-update hooks found in the Documentation/howto directory. option, which tells it if updates to a ref should be denied if they are not fast-forwards. +A number of other receive.* config options are available to tweak +its behavior, see linkgit:git-config[1]. + OPTIONS ------- <directory>:: diff --git a/Documentation/git-remote-fd.txt b/Documentation/git-remote-fd.txt index e700baf..80afca8 100644 --- a/Documentation/git-remote-fd.txt +++ b/Documentation/git-remote-fd.txt @@ -17,7 +17,7 @@ fetch, push or archive. If only <infd> is given, it is assumed to be a bidirectional socket connected to remote Git server (git-upload-pack, git-receive-pack or -git-upload-achive). If both <infd> and <outfd> are given, they are assumed +git-upload-archive). If both <infd> and <outfd> are given, they are assumed to be pipes connected to a remote Git server (<infd> being the inbound pipe and <outfd> being the outbound pipe. diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt index 9597777..26afe6e 100644 --- a/Documentation/git-repack.txt +++ b/Documentation/git-repack.txt @@ -130,6 +130,19 @@ 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. +--unpack-unreachable=<when>:: + When loosening unreachable objects, do not bother loosening any + objects older than `<when>`. This can be used to optimize out + the write of any objects that would be immediately pruned by + a follow-up `git prune`. + +-k:: +--keep-unreachable:: + When used with `-ad`, any unreachable objects from existing + packs will be appended to the end of the packfile instead of + being removed. In addition, any unreachable loose objects will + be packed (and their loose counterparts removed). + Configuration ------------- diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt index 92df596..2e9cef0 100644 --- a/Documentation/git-stash.txt +++ b/Documentation/git-stash.txt @@ -39,7 +39,8 @@ The latest stash you created is stored in `refs/stash`; older stashes are found in the reflog of this reference and can be named using the usual reflog syntax (e.g. `stash@{0}` is the most recently created stash, `stash@{1}` is the one before it, `stash@{2.hours.ago}` -is also possible). +is also possible). Stashes may also be referenced by specifying just the +stash index (e.g. the integer `n` is equivalent to `stash@{n}`). OPTIONS ------- diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index e1e8f57..725065e 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -32,11 +32,14 @@ OPTIONS --branch:: Show the branch and tracking info even in short-format. ---porcelain:: +--porcelain[=<version>]:: Give the output in an easy-to-parse format for scripts. This is similar to the short output, but will remain stable across Git versions and regardless of user configuration. See below for details. ++ +The version parameter is used to specify the format version. +This is optional and defaults to the original version 'v1' format. --long:: Give the output in the long-format. This is the default. @@ -96,7 +99,7 @@ configuration variable documented in linkgit:git-config[1]. -z:: Terminate entries with NUL, instead of LF. This implies - the `--porcelain` output format if no other format is given. + the `--porcelain=v1` output format if no other format is given. --column[=<options>]:: --no-column:: @@ -180,12 +183,12 @@ in which case `XY` are `!!`. If -b is used the short-format status is preceded by a line -## branchname tracking info + ## branchname tracking info -Porcelain Format -~~~~~~~~~~~~~~~~ +Porcelain Format Version 1 +~~~~~~~~~~~~~~~~~~~~~~~~~~ -The porcelain format is similar to the short format, but is guaranteed +Version 1 porcelain format is similar to the short format, but is guaranteed not to change in a backwards-incompatible way between Git versions or based on user configuration. This makes it ideal for parsing by scripts. The description of the short format above also describes the porcelain @@ -207,6 +210,124 @@ field from the first filename). Third, filenames containing special characters are not specially formatted; no quoting or backslash-escaping is performed. +Porcelain Format Version 2 +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Version 2 format adds more detailed information about the state of +the worktree and changed items. Version 2 also defines an extensible +set of easy to parse optional headers. + +Header lines start with "#" and are added in response to specific +command line arguments. Parsers should ignore headers they +don't recognize. + +### Branch Headers + +If `--branch` is given, a series of header lines are printed with +information about the current branch. + + Line Notes + ------------------------------------------------------------ + # branch.oid <commit> | (initial) Current commit. + # branch.head <branch> | (detached) Current branch. + # branch.upstream <upstream_branch> If upstream is set. + # branch.ab +<ahead> -<behind> If upstream is set and + the commit is present. + ------------------------------------------------------------ + +### Changed Tracked Entries + +Following the headers, a series of lines are printed for tracked +entries. One of three different line formats may be used to describe +an entry depending on the type of change. Tracked entries are printed +in an undefined order; parsers should allow for a mixture of the 3 +line types in any order. + +Ordinary changed entries have the following format: + + 1 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <path> + +Renamed or copied entries have the following format: + + 2 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <X><score> <path><sep><origPath> + + Field Meaning + -------------------------------------------------------- + <XY> A 2 character field containing the staged and + unstaged XY values described in the short format, + with unchanged indicated by a "." rather than + a space. + <sub> A 4 character field describing the submodule state. + "N..." when the entry is not a submodule. + "S<c><m><u>" when the entry is a submodule. + <c> is "C" if the commit changed; otherwise ".". + <m> is "M" if it has tracked changes; otherwise ".". + <u> is "U" if there are untracked changes; otherwise ".". + <mH> The octal file mode in HEAD. + <mI> The octal file mode in the index. + <mW> The octal file mode in the worktree. + <hH> The object name in HEAD. + <hI> The object name in the index. + <X><score> The rename or copy score (denoting the percentage + of similarity between the source and target of the + move or copy). For example "R100" or "C75". + <path> The pathname. In a renamed/copied entry, this + is the path in the index and in the working tree. + <sep> When the `-z` option is used, the 2 pathnames are separated + with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09) + byte separates them. + <origPath> The pathname in the commit at HEAD. This is only + present in a renamed/copied entry, and tells + where the renamed/copied contents came from. + -------------------------------------------------------- + +Unmerged entries have the following format; the first character is +a "u" to distinguish from ordinary changed entries. + + u <xy> <sub> <m1> <m2> <m3> <mW> <h1> <h2> <h3> <path> + + Field Meaning + -------------------------------------------------------- + <XY> A 2 character field describing the conflict type + as described in the short format. + <sub> A 4 character field describing the submodule state + as described above. + <m1> The octal file mode in stage 1. + <m2> The octal file mode in stage 2. + <m3> The octal file mode in stage 3. + <mW> The octal file mode in the worktree. + <h1> The object name in stage 1. + <h2> The object name in stage 2. + <h3> The object name in stage 3. + <path> The pathname. + -------------------------------------------------------- + +### Other Items + +Following the tracked entries (and if requested), a series of +lines will be printed for untracked and then ignored items +found in the worktree. + +Untracked items have the following format: + + ? <path> + +Ignored items have the following format: + + ! <path> + +### Pathname Format Notes and -z + +When the `-z` option is given, pathnames are printed as is and +without any quoting and lines are terminated with a NUL (ASCII 0x00) +byte. + +Otherwise, all pathnames will be "C-quoted" if they contain any tab, +linefeed, double quote, or backslash characters. In C-quoting, these +characters will be replaced with the corresponding C-style escape +sequences and the resulting pathname will be double quoted. + + CONFIGURATION ------------- diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 9226c43..d841573 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -15,8 +15,9 @@ SYNOPSIS 'git submodule' [--quiet] init [--] [<path>...] 'git submodule' [--quiet] deinit [-f|--force] (--all|[--] <path>...) 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] - [-f|--force] [--rebase|--merge] [--reference <repository>] - [--depth <depth>] [--recursive] [--jobs <n>] [--] [<path>...] + [--[no-]recommend-shallow] [-f|--force] [--rebase|--merge] + [--reference <repository>] [--depth <depth>] [--recursive] + [--jobs <n>] [--] [<path>...] 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>] [commit] [--] [<path>...] 'git submodule' [--quiet] foreach [--recursive] <command> @@ -258,7 +259,9 @@ OPTIONS --branch:: Branch of repository to add as submodule. The name of the branch is recorded as `submodule.<name>.branch` in - `.gitmodules` for `update --remote`. + `.gitmodules` for `update --remote`. A special value of `.` is used to + indicate that the name of the branch in the submodule should be the + same name as the current branch in the current repository. -f:: --force:: @@ -384,6 +387,12 @@ for linkgit:git-clone[1]'s `--reference` and `--shared` options carefully. clone with a history truncated to the specified number of revisions. See linkgit:git-clone[1] +--[no-]recommend-shallow:: + This option is only valid for the update command. + The initial clone of a submodule will use the recommended + `submodule.<name>.shallow` as provided by the .gitmodules file + by default. To ignore the suggestions use `--no-recommend-shallow`. + -j <n>:: --jobs <n>:: This option is only valid for the update command. diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 7e17cad..5f9e65b 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -625,6 +625,9 @@ config key: svn.authorsfile 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. ++ +[verse] +config key: svn.authorsProg -q:: --quiet:: diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 7ecca8e..80019c5 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -253,9 +253,8 @@ On Automatic following ~~~~~~~~~~~~~~~~~~~~~~ If you are following somebody else's tree, you are most likely -using remote-tracking branches (`refs/heads/origin` in traditional -layout, or `refs/remotes/origin/master` in the separate-remote -layout). You usually want the tags from the other end. +using remote-tracking branches (eg. `refs/remotes/origin/master`). +You usually want the tags from the other end. On the other hand, if you are fetching because you would want a one-shot merge from somebody else, you typically do not want to diff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt index 3e887d1..b3de50d 100644 --- a/Documentation/git-unpack-objects.txt +++ b/Documentation/git-unpack-objects.txt @@ -44,6 +44,9 @@ OPTIONS --strict:: Don't write objects with broken content or links. +--max-input-size=<size>:: + Die, if the pack is larger than <size>. + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt index 0abc806..822ad59 100644 --- a/Documentation/git-upload-pack.txt +++ b/Documentation/git-upload-pack.txt @@ -9,8 +9,8 @@ git-upload-pack - Send objects packed back to git-fetch-pack SYNOPSIS -------- [verse] -'git-upload-pack' [--strict] [--timeout=<n>] <directory> - +'git-upload-pack' [--[no-]strict] [--timeout=<n>] [--stateless-rpc] + [--advertise-refs] <directory> DESCRIPTION ----------- Invoked by 'git fetch-pack', learns what @@ -25,12 +25,22 @@ repository. For push operations, see 'git send-pack'. OPTIONS ------- ---strict:: +--[no-]strict:: Do not try <directory>/.git/ if <directory> is no Git directory. --timeout=<n>:: Interrupt transfer after <n> seconds of inactivity. +--stateless-rpc:: + Perform only a single read-write cycle with stdin and stdout. + This fits with the HTTP POST request processing model where + a program may read the request, write a response, and must exit. + +--advertise-refs:: + Only the initial ref advertisement is output, and the program exits + immediately. This fits with the HTTP GET request model, where + no request content is received but a response must be produced. + <directory>:: The repository to sync from. diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt index c622345..e257c19 100644 --- a/Documentation/git-worktree.txt +++ b/Documentation/git-worktree.txt @@ -10,8 +10,10 @@ SYNOPSIS -------- [verse] 'git worktree add' [-f] [--detach] [--checkout] [-b <new-branch>] <path> [<branch>] -'git worktree prune' [-n] [-v] [--expire <expire>] 'git worktree list' [--porcelain] +'git worktree lock' [--reason <string>] <worktree> +'git worktree prune' [-n] [-v] [--expire <expire>] +'git worktree unlock' <worktree> DESCRIPTION ----------- @@ -38,9 +40,8 @@ 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 creating a file named 'locked' alongside the other -administrative files, optionally containing a plain text reason that -pruning should be suppressed. See section "DETAILS" for more information. +being pruned by issuing the `git worktree lock` command, optionally +specifying `--reason` to explain why the working tree is locked. COMMANDS -------- @@ -48,16 +49,13 @@ add <path> [<branch>]:: Create `<path>` and checkout `<branch>` into it. The new working directory is linked to the current repository, sharing everything except working -directory specific files such as HEAD, index, etc. +directory specific files such as HEAD, index, etc. `-` may also be +specified as `<branch>`; it is synonymous with `@{-1}`. + If `<branch>` is omitted and neither `-b` nor `-B` nor `--detached` used, then, as a convenience, a new branch based at HEAD is created automatically, as if `-b $(basename <path>)` was specified. -prune:: - -Prune working tree information in $GIT_DIR/worktrees. - list:: List details of each worktree. The main worktree is listed first, followed by @@ -65,6 +63,22 @@ each of the linked worktrees. The output details include if the worktree is bare, the revision currently checked out, and the branch currently checked out (or 'detached HEAD' if none). +lock:: + +If a working tree is on a portable device or network share which +is not always mounted, lock it to prevent its administrative +files from being pruned automatically. This also prevents it from +being moved or deleted. Optionally, specify a reason for the lock +with `--reason`. + +prune:: + +Prune working tree information in $GIT_DIR/worktrees. + +unlock:: + +Unlock a working tree, allowing it to be pruned, moved or deleted. + OPTIONS ------- @@ -110,6 +124,18 @@ OPTIONS --expire <time>:: With `prune`, only expire unused working trees older than <time>. +--reason <string>:: + With `lock`, an explanation why the working tree is locked. + +<worktree>:: + Working trees can be identified by path, either relative or + absolute. ++ +If the last path components in the working tree's path is unique among +working trees, it can be used to identify worktrees. For example if +you only have two working trees, at "/abc/def/ghi" and "/abc/def/ggg", +then "ghi" or "def/ghi" is enough to point to the former working tree. + DETAILS ------- Each linked working tree has a private sub-directory in the repository's @@ -150,7 +176,8 @@ instead. To prevent a $GIT_DIR/worktrees entry from being pruned (which can be useful in some situations, such as when the -entry's working tree is stored on a portable device), add a file named +entry's working tree is stored on a portable device), use the +`git worktree lock` command, which adds a file named 'locked' to the entry's directory. The file contains the reason in plain text. For example, if a linked working tree's `.git` file points to `/path/main/.git/worktrees/test-next` then a file named @@ -226,8 +253,6 @@ 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 -- `lock` to prevent automatic pruning of administrative files (for instance, - for a working tree on a portable device) GIT --- diff --git a/Documentation/git.txt b/Documentation/git.txt index 923aa49..ab7215e 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -13,6 +13,7 @@ SYNOPSIS [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path] [-p|--paginate|--no-pager] [--no-replace-objects] [--bare] [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>] + [--super-prefix=<path>] <command> [<args>] DESCRIPTION @@ -43,6 +44,13 @@ unreleased) version of Git, that is available from the 'master' branch of the `git.git` repository. Documentation for older releases are available here: +* link:v2.10.2/git.html[documentation for release 2.10.2] + +* release notes for + link:RelNotes/2.10.2.txt[2.10.2], + link:RelNotes/2.10.1.txt[2.10.1], + link:RelNotes/2.10.0.txt[2.10]. + * link:v2.9.3/git.html[documentation for release 2.9.3] * release notes for @@ -596,6 +604,11 @@ foo.bar= ...`) sets `foo.bar` to the empty string. details. Equivalent to setting the `GIT_NAMESPACE` environment variable. +--super-prefix=<path>:: + Currently for internal use only. Set a prefix which gives a path from + above a repository down to its root. One use is to give submodules + context about the superproject that invoked it. + --bare:: Treat the repository as a bare repository. If GIT_DIR environment is not set, it is set to the current working @@ -1086,6 +1099,14 @@ of clones and fetches. cloning of shallow repositories. See `GIT_TRACE` for available trace output options. +`GIT_TRACE_CURL`:: + Enables a curl full trace dump of all incoming and outgoing data, + including descriptive information, of the git transport protocol. + This is similar to doing curl `--trace-ascii` on the command line. + This option overrides setting the `GIT_CURL_VERBOSE` environment + variable. + See `GIT_TRACE` for available trace output options. + `GIT_LITERAL_PATHSPECS`:: Setting this variable to `1` will cause Git to treat all pathspecs literally, rather than as glob patterns. For example, diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index 6d20400..976243a 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -133,7 +133,7 @@ Set to string value "auto":: When `text` is set to "auto", the path is marked for automatic end-of-line conversion. If Git decides that the content is text, its line endings are converted to LF on checkin. - When the file has been commited with CRLF, no conversion is done. + When the file has been committed with CRLF, no conversion is done. Unspecified:: @@ -182,23 +182,6 @@ While Git normally leaves file contents alone, it can be configured to normalize line endings to LF in the repository and, optionally, to convert them to CRLF when files are checked out. -Here is an example that will make Git normalize .txt, .vcproj and .sh -files, ensure that .vcproj files have CRLF and .sh files have LF in -the working directory, and prevent .jpg files from being normalized -regardless of their content. - ------------------------- -* text=auto -*.txt text -*.vcproj text eol=crlf -*.sh text eol=lf -*.jpg -text ------------------------- - -Other source code management systems normalize all text files in their -repositories, and there are two ways to enable similar automatic -normalization in Git. - If you simply want to have CRLF line endings in your working directory regardless of the repository you are working with, you can set the config variable "core.autocrlf" without using any attributes. @@ -208,35 +191,42 @@ config variable "core.autocrlf" without using any attributes. autocrlf = true ------------------------ -This does not force normalization of all text files, but does ensure +This does not force normalization of text files, but does ensure that text files that you introduce to the repository have their line endings normalized to LF when they are added, and that files that are already normalized in the repository stay normalized. -If you want to interoperate with a source code management system that -enforces end-of-line normalization, or you simply want all text files -in your repository to be normalized, you should instead set the `text` -attribute to "auto" for _all_ files. +If you want to ensure that text files that any contributor introduces to +the repository have their line endings normalized, you can set the +`text` attribute to "auto" for _all_ files. ------------------------ * text=auto ------------------------ -This ensures that all files that Git considers to be text will have -normalized (LF) line endings in the repository. The `core.eol` -configuration variable controls which line endings Git will use for -normalized files in your working directory; the default is to use the -native line ending for your platform, or CRLF if `core.autocrlf` is -set. +The attributes allow a fine-grained control, how the line endings +are converted. +Here is an example that will make Git normalize .txt, .vcproj and .sh +files, ensure that .vcproj files have CRLF and .sh files have LF in +the working directory, and prevent .jpg files from being normalized +regardless of their content. + +------------------------ +* text=auto +*.txt text +*.vcproj text eol=crlf +*.sh text eol=lf +*.jpg -text +------------------------ + +NOTE: When `text=auto` conversion is enabled in a cross-platform +project using push and pull to a central repository the text files +containing CRLFs should be normalized. -NOTE: When `text=auto` normalization is enabled in an existing -repository, any text files containing CRLFs should be normalized. If -they are not they will be normalized the next time someone tries to -change them, causing unfortunate misattribution. From a clean working -directory: +From a clean working directory: ------------------------------------------------- -$ echo "* text=auto" >>.gitattributes +$ echo "* text=auto" >.gitattributes $ rm .git/index # Remove the index to force Git to $ git reset # re-scan the working directory $ git status # Show files that will be normalized @@ -303,7 +293,15 @@ checkout, when the `smudge` command is specified, the command is fed the blob object from its standard input, and its standard output is used to update the worktree file. Similarly, the `clean` command is used to convert the contents of worktree file -upon checkin. +upon checkin. By default these commands process only a single +blob and terminate. If a long running `process` filter is used +in place of `clean` and/or `smudge` filters, then Git can process +all blobs with a single filter command invocation for the entire +life of a single Git command, for example `git add --all`. If a +long running `process` filter is configured then it always takes +precedence over a configured single blob filter. See section +below for the description of the protocol used to communicate with +a `process` filter. One use of the content filtering is to massage the content into a shape that is more convenient for the platform, filesystem, and the user to use. @@ -383,6 +381,153 @@ not exist, or may have different contents. So, smudge and clean commands should not try to access the file on disk, but only act as filters on the content provided to them on standard input. +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" and +"smudge". + +Afterwards Git sends a list of "key=value" pairs terminated with +a flush packet. The list will contain at least the filter command +(based on the supported capabilities) and the pathname of the file +to filter relative to the repository root. Right after the flush packet +Git sends the content split in zero or more pkt-line packets and a +flush packet to terminate content. Please note, that the filter +must not send any response before it received the content and the +final flush packet. +------------------------ +packet: git> command=smudge +packet: git> pathname=path/testfile.dat +packet: git> 0000 +packet: git> CONTENT +packet: git> 0000 +------------------------ + +The filter is expected to respond with a list of "key=value" pairs +terminated with a flush packet. If the filter does not experience +problems then the list must contain a "success" status. Right after +these packets the filter is expected to send the content in zero +or more pkt-line packets and a flush packet at the end. Finally, a +second list of "key=value" pairs terminated with a flush packet +is expected. The filter can change the status in the second list +or keep the status as is with an empty list. Please note that the +empty list must be terminated with a flush packet regardless. + +------------------------ +packet: git< status=success +packet: git< 0000 +packet: git< SMUDGED_CONTENT +packet: git< 0000 +packet: git< 0000 # empty list, keep "status=success" unchanged! +------------------------ + +If the result content is empty then the filter is expected to respond +with a "success" status and a flush packet to signal the empty content. +------------------------ +packet: git< status=success +packet: git< 0000 +packet: git< 0000 # empty content! +packet: git< 0000 # empty list, keep "status=success" unchanged! +------------------------ + +In case the filter cannot or does not want to process the content, +it is expected to respond with an "error" status. +------------------------ +packet: git< status=error +packet: git< 0000 +------------------------ + +If the filter experiences an error during processing, then it can +send the status "error" after the content was (partially or +completely) sent. +------------------------ +packet: git< status=success +packet: git< 0000 +packet: git< HALF_WRITTEN_ERRONEOUS_CONTENT +packet: git< 0000 +packet: git< status=error +packet: git< 0000 +------------------------ + +In case the filter cannot or does not want to process the content +as well as any future content for the lifetime of the Git process, +then it is expected to respond with an "abort" status at any point +in the protocol. +------------------------ +packet: git< status=abort +packet: git< 0000 +------------------------ + +Git neither stops nor restarts the filter process in case the +"error"/"abort" status is set. However, Git sets its exit code +according to the `filter.<driver>.required` flag, mimicking the +behavior of the `filter.<driver>.clean` / `filter.<driver>.smudge` +mechanism. + +If the filter dies during the communication or does not adhere to +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 blob it is expected to wait for +the next "key=value" list containing a 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. + +A long running filter demo implementation can be found in +`contrib/long-running-filter/example.pl` located in the Git +core repository. If you develop your own long running filter +process then the `GIT_TRACE_PACKET` environment variables can be +very helpful for debugging (see linkgit:git[1]). + +Please note that you cannot use an existing `filter.<driver>.clean` +or `filter.<driver>.smudge` command with `filter.<driver>.process` +because the former two use a different inter process communication +protocol than the latter one. + + Interaction between checkin/checkout attributes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -533,6 +678,8 @@ patterns are available: - `csharp` suitable for source code in the C# language. +- `css` suitable for cascading style sheets. + - `fortran` suitable for source code in the Fortran language. - `fountain` suitable for Fountain documents. diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt index b06e852..4c6143c 100644 --- a/Documentation/gitcvs-migration.txt +++ b/Documentation/gitcvs-migration.txt @@ -116,8 +116,12 @@ they create are writable and searchable by other group members. Importing a CVS archive ----------------------- +NOTE: These instructions use the `git-cvsimport` script which ships with +git, but other importers may provide better results. See the note in +linkgit:git-cvsimport[1] for other options. + First, install version 2.1 or higher of cvsps from -http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make +https://github.com/andreyvit/cvsps[https://github.com/andreyvit/cvsps] and make sure it is in your path. Then cd to a checked out CVS working directory of the project you are interested in and run linkgit:git-cvsimport[1]: diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index d82e912..9565dc3 100644 --- a/Documentation/githooks.txt +++ b/Documentation/githooks.txt @@ -247,6 +247,15 @@ Both standard output and standard error output are forwarded to '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 +`git push --push-option=...` can be read from the environment +variable `GIT_PUSH_OPTION_COUNT`, and the options themselves are +found in `GIT_PUSH_OPTION_0`, `GIT_PUSH_OPTION_1`,... +If it is negotiated to not use the push options phase, the +environment variables will not be set. If the client selects +to use push options, but doesn't transmit any, the count variable +will be set to zero, `GIT_PUSH_OPTION_COUNT=0`. + [[update]] update ~~~~~~ @@ -322,6 +331,15 @@ a sample script `post-receive-email` provided in the `contrib/hooks` directory in Git distribution, which implements sending commit emails. +The number of push options given on the command line of +`git push --push-option=...` can be read from the environment +variable `GIT_PUSH_OPTION_COUNT`, and the options themselves are +found in `GIT_PUSH_OPTION_0`, `GIT_PUSH_OPTION_1`,... +If it is negotiated to not use the push options phase, the +environment variables will not be set. If the client selects +to use push options, but doesn't transmit any, the count variable +will be set to zero, `GIT_PUSH_OPTION_COUNT=0`. + [[post-update]] post-update ~~~~~~~~~~~ diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index a68d860..e382dd9 100644 --- a/Documentation/gitk.txt +++ b/Documentation/gitk.txt @@ -70,7 +70,7 @@ linkgit:git-rev-list[1] for a complete list. --left-right:: - Mark which side of a symmetric diff a commit is reachable + Mark which side of a symmetric difference a commit is reachable from. Commits from the left side are prefixed with a `<` symbol and those from the right with a `>` symbol. diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt index 07cdd73..8f7c50f 100644 --- a/Documentation/gitmodules.txt +++ b/Documentation/gitmodules.txt @@ -50,8 +50,11 @@ submodule.<name>.update:: submodule.<name>.branch:: A remote branch name for tracking updates in the upstream submodule. - If the option is not specified, it defaults to 'master'. See the - `--remote` documentation in linkgit:git-submodule[1] for details. + If the option is not specified, it defaults to 'master'. A special + value of `.` is used to indicate that the name of the branch in the + submodule should be the same name as the current branch in the + current repository. See the `--remote` documentation in + linkgit:git-submodule[1] for details. submodule.<name>.fetchRecurseSubmodules:: This option can be used to control recursive fetching of this @@ -79,6 +82,11 @@ submodule.<name>.ignore:: "--ignore-submodule" option. The 'git submodule' commands are not affected by this setting. +submodule.<name>.shallow:: + When set to true, a clone of this submodule will be performed as a + shallow clone unless the user explicitly asks for a non-shallow + clone. + EXAMPLES -------- diff --git a/Documentation/gitremote-helpers.txt b/Documentation/gitremote-helpers.txt index a4de50a..9e8681f 100644 --- a/Documentation/gitremote-helpers.txt +++ b/Documentation/gitremote-helpers.txt @@ -415,6 +415,17 @@ set by Git if the remote helper has the 'option' capability. 'option depth' <depth>:: Deepens the history of a shallow repository. +'option deepen-since <timestamp>:: + Deepens the history of a shallow repository based on time. + +'option deepen-not <ref>:: + Deepens the history of a shallow repository excluding ref. + Multiple options add up. + +'option deepen-relative {'true'|'false'}:: + Deepens the history of a shallow repository relative to + current boundary. Only valid when used with "option depth". + 'option followtags' {'true'|'false'}:: If enabled the helper should automatically fetch annotated tag objects if the object the tag points at was transferred diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt index 577ee84..a5f99cb 100644 --- a/Documentation/gitrepository-layout.txt +++ b/Documentation/gitrepository-layout.txt @@ -177,7 +177,7 @@ sharedindex.<SHA-1>:: info:: Additional information about the repository is recorded in this directory. This directory is ignored if $GIT_COMMON_DIR - is set and "$GIT_COMMON_DIR/index" will be used instead. + is set and "$GIT_COMMON_DIR/info" will be used instead. info/refs:: This file helps dumb transports discover what refs are diff --git a/Documentation/gitrevisions.txt b/Documentation/gitrevisions.txt index e903eb7..27dec5b 100644 --- a/Documentation/gitrevisions.txt +++ b/Documentation/gitrevisions.txt @@ -15,9 +15,9 @@ DESCRIPTION Many Git commands take revision parameters as arguments. Depending on the command, they denote a specific commit or, for commands which -walk the revision graph (such as linkgit:git-log[1]), all commits which can -be reached from that commit. In the latter case one can also specify a -range of revisions explicitly. +walk the revision graph (such as linkgit:git-log[1]), all commits which are +reachable from that commit. For commands that walk the revision graph one can +also specify a range of revisions explicitly. In addition, some Git commands (such as linkgit:git-show[1]) also take revision parameters which denote other objects than commits, e.g. blobs diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt index a79e350..e632089 100644 --- a/Documentation/gitweb.conf.txt +++ b/Documentation/gitweb.conf.txt @@ -246,13 +246,20 @@ $highlight_bin:: Note that 'highlight' feature must be set for gitweb to actually use syntax highlighting. + -*NOTE*: if you want to add support for new file type (supported by -"highlight" but not used by gitweb), you need to modify `%highlight_ext` -or `%highlight_basename`, depending on whether you detect type of file -based on extension (for example "sh") or on its basename (for example -"Makefile"). The keys of these hashes are extension and basename, -respectively, and value for given key is name of syntax to be passed via -`--syntax <syntax>` to highlighter. +*NOTE*: for a file to be highlighted, its syntax type must be detected +and that syntax must be supported by "highlight". The default syntax +detection is minimal, and there are many supported syntax types with no +detection by default. There are three options for adding syntax +detection. The first and second priority are `%highlight_basename` and +`%highlight_ext`, which detect based on basename (the full filename, for +example "Makefile") and extension (for example "sh"). The keys of these +hashes are the basename and extension, respectively, and the value for a +given key is the name of the syntax to be passed via `--syntax <syntax>` +to "highlight". The last priority is the "highlight" configuration of +`Shebang` regular expressions to detect the language based on the first +line in the file, (for example, matching the line "#!/bin/bash"). See +the highlight documentation and the default config at +/etc/highlight/filetypes.conf for more details. + For example if repositories you are hosting use "phtml" extension for PHP files, and you want to have correct syntax-highlighting for those diff --git a/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt index 462255e..19f59cc 100644 --- a/Documentation/howto/revert-a-faulty-merge.txt +++ b/Documentation/howto/revert-a-faulty-merge.txt @@ -30,7 +30,7 @@ The history immediately after the "revert of the merge" would look like this: ---o---o---o---M---x---x---W - / + / ---A---B where A and B are on the side development that was not so good, M is the @@ -47,7 +47,7 @@ After the developers of the side branch fix their mistakes, the history may look like this: ---o---o---o---M---x---x---W---x - / + / ---A---B-------------------C---D where C and D are to fix what was broken in A and B, and you may already @@ -81,7 +81,7 @@ In such a situation, you would want to first revert the previous revert, which would make the history look like this: ---o---o---o---M---x---x---W---x---Y - / + / ---A---B-------------------C---D where Y is the revert of W. Such a "revert of the revert" can be done @@ -93,14 +93,14 @@ This history would (ignoring possible conflicts between what W and W..Y changed) be equivalent to not having W or Y at all in the history: ---o---o---o---M---x---x-------x---- - / + / ---A---B-------------------C---D and merging the side branch again will not have conflict arising from an earlier revert and revert of the revert. ---o---o---o---M---x---x-------x-------* - / / + / / ---A---B-------------------C---D Of course the changes made in C and D still can conflict with what was @@ -111,13 +111,13 @@ faulty A and B, and redone the changes on top of the updated mainline after the revert, the history would have looked like this: ---o---o---o---M---x---x---W---x---x - / \ + / \ ---A---B A'--B'--C' If you reverted the revert in such a case as in the previous example: ---o---o---o---M---x---x---W---x---x---Y---* - / \ / + / \ / ---A---B A'--B'--C' where Y is the revert of W, A' and B' are rerolled A and B, and there may @@ -129,7 +129,7 @@ lot of overlapping changes that result in conflicts. So do not do "revert of revert" blindly without thinking.. ---o---o---o---M---x---x---W---x---x - / \ + / \ ---A---B A'--B'--C' In the history with rebased side branch, W (and M) are behind the merge diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt index b95d67e..3bcee2d 100644 --- a/Documentation/pretty-formats.txt +++ b/Documentation/pretty-formats.txt @@ -143,8 +143,14 @@ ifndef::git-rev-list[] - '%N': commit notes endif::git-rev-list[] - '%GG': raw verification message from GPG for a signed commit -- '%G?': show "G" for a good (valid) signature, "B" for a bad signature, - "U" for a good signature with unknown validity and "N" for no signature +- '%G?': show "G" for a good (valid) signature, + "B" for a bad signature, + "U" for a good signature with unknown validity, + "X" for a good signature that has expired, + "Y" for a good signature made by an expired key, + "R" for a good signature made by a revoked key, + "E" if the signature cannot be checked (e.g. missing key) + and "N" for no signature - '%GS': show the name of the signer for a signed commit - '%GK': show the key used to sign a signed commit - '%gD': reflog selector, e.g., `refs/stash@{1}` or @@ -166,13 +172,14 @@ endif::git-rev-list[] - '%Cgreen': switch color to green - '%Cblue': switch color to blue - '%Creset': reset color -- '%C(...)': color specification, as described in color.branch.* config option; +- '%C(...)': color specification, as described under Values in the + "CONFIGURATION FILE" section of linkgit:git-config[1]; adding `auto,` at the beginning will emit color only when colors are enabled for log output (by `color.diff`, `color.ui`, or `--color`, and respecting the `auto` settings of the former if we are going to a terminal). `auto` alone (i.e. `%C(auto)`) will turn on auto coloring on the next placeholders until the color is switched again. -- '%m': left, right or boundary mark +- '%m': left (`<`), right (`>`) or boundary (`-`) mark - '%n': newline - '%%': a raw '%' - '%x00': print a byte from a hex code diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index eac982c..5da7cf5 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -225,7 +225,7 @@ excluded from the output. --left-only:: --right-only:: - List only commits on the respective side of a symmetric range, + List only commits on the respective side of a symmetric difference, i.e. only those which would be marked `<` resp. `>` by `--left-right`. + @@ -289,6 +289,10 @@ ifdef::git-rev-list[] Try to speed up the traversal using the pack bitmap index (if one is available). Note that when traversing with `--objects`, trees and blobs will not have their associated path printed. + +--progress=<header>:: + Show progress reports on stderr as objects are considered. The + `<header>` text will be printed with each progress update. endif::git-rev-list[] -- @@ -653,8 +657,9 @@ avoid showing the commits from two parallel development track mixed together. --reverse:: - Output the commits in reverse order. - Cannot be combined with `--walk-reflogs`. + Output the commits chosen to be shown (see Commit Limiting + section above) in reverse order. Cannot be combined with + `--walk-reflogs`. Object Traversal ~~~~~~~~~~~~~~~~ @@ -792,7 +797,7 @@ ifdef::git-rev-list[] endif::git-rev-list[] --left-right:: - Mark which side of a symmetric diff a commit is reachable from. + Mark which side of a symmetric difference a commit is reachable from. Commits from the left side are prefixed with `<` and those from the right with `>`. If combined with `--boundary`, those commits are prefixed with `-`. diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt index abae363..ba11b9c 100644 --- a/Documentation/revisions.txt +++ b/Documentation/revisions.txt @@ -237,48 +237,81 @@ SPECIFYING RANGES ----------------- History traversing commands such as `git log` operate on a set -of commits, not just a single commit. To these commands, -specifying a single revision with the notation described in the -previous section means the set of commits reachable from that -commit, following the commit ancestry chain. - -To exclude commits reachable from a commit, a prefix '{caret}' -notation is used. E.g. '{caret}r1 r2' means commits reachable -from 'r2' but exclude the ones reachable from 'r1'. - -This set operation appears so often that there is a shorthand -for it. When you have two commits 'r1' and 'r2' (named according -to the syntax explained in SPECIFYING REVISIONS above), you can ask -for commits that are reachable from r2 excluding those that are reachable -from r1 by '{caret}r1 r2' and it can be written as 'r1..r2'. - -A similar notation 'r1\...r2' is called symmetric difference -of 'r1' and 'r2' and is defined as -'r1 r2 --not $(git merge-base --all r1 r2)'. -It is the set of commits that are reachable from either one of -'r1' or 'r2' but not from both. - -In these two shorthands, you can omit one end and let it default to HEAD. +of commits, not just a single commit. + +For these commands, +specifying a single revision, using the notation described in the +previous section, means the set of commits `reachable` from the given +commit. + +A commit's reachable set is the commit itself and the commits in +its ancestry chain. + + +Commit Exclusions +~~~~~~~~~~~~~~~~~ + +'{caret}<rev>' (caret) Notation:: + To exclude commits reachable from a commit, a prefix '{caret}' + notation is used. E.g. '{caret}r1 r2' means commits reachable + from 'r2' but exclude the ones reachable from 'r1' (i.e. 'r1' and + its ancestors). + +Dotted Range Notations +~~~~~~~~~~~~~~~~~~~~~~ + +The '..' (two-dot) Range Notation:: + The '{caret}r1 r2' set operation appears so often that there is a shorthand + for it. When you have two commits 'r1' and 'r2' (named according + to the syntax explained in SPECIFYING REVISIONS above), you can ask + for commits that are reachable from r2 excluding those that are reachable + from r1 by '{caret}r1 r2' and it can be written as 'r1..r2'. + +The '...' (three dot) Symmetric Difference Notation:: + A similar notation 'r1\...r2' is called symmetric difference + of 'r1' and 'r2' and is defined as + 'r1 r2 --not $(git merge-base --all r1 r2)'. + It is the set of commits that are reachable from either one of + 'r1' (left side) or 'r2' (right side) but not from both. + +In these two shorthand notations, you can omit one end and let it default to HEAD. For example, 'origin..' is a shorthand for 'origin..HEAD' and asks "What did I do since I forked from the origin branch?" Similarly, '..origin' is a shorthand for 'HEAD..origin' and asks "What did the origin do since I forked from them?" Note that '..' would mean 'HEAD..HEAD' which is an empty range that is both reachable and unreachable from HEAD. -Two other shorthands for naming a set that is formed by a commit -and its parent commits exist. The 'r1{caret}@' notation means all -parents of 'r1'. 'r1{caret}!' includes commit 'r1' but excludes -all of its parents. +Other <rev>{caret} Parent Shorthand Notations +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Three other shorthands exist, particularly useful for merge commits, +for naming a set that is formed by a commit and its parent commits. + +The 'r1{caret}@' notation means all parents of 'r1'. + +The 'r1{caret}!' notation includes commit 'r1' but excludes all of its parents. +By itself, this notation denotes the single commit 'r1'. + +The '<rev>{caret}-{<n>}' notation includes '<rev>' but excludes the <n>th +parent (i.e. a shorthand for '<rev>{caret}<n>..<rev>'), with '<n>' = 1 if +not given. This is typically useful for merge commits where you +can just pass '<commit>{caret}-' to get all the commits in the branch +that was merged in merge commit '<commit>' (including '<commit>' +itself). + +While '<rev>{caret}<n>' was about specifying a single commit parent, these +three notations also consider its parents. For example you can say +'HEAD{caret}2{caret}@', however you cannot say 'HEAD{caret}@{caret}2'. -To summarize: +Revision Range Summary +---------------------- '<rev>':: - Include commits that are reachable from (i.e. ancestors of) - <rev>. + Include commits that are reachable from <rev> (i.e. <rev> and its + ancestors). '{caret}<rev>':: - Exclude commits that are reachable from (i.e. ancestors of) - <rev>. + Exclude commits that are reachable from <rev> (i.e. <rev> and its + ancestors). '<rev1>..<rev2>':: Include commits that are reachable from <rev2> but exclude @@ -300,16 +333,33 @@ To summarize: as giving commit '<rev>' and then all its parents prefixed with '{caret}' to exclude them (and their ancestors). -Here are a handful of examples: - - D G H D - D F G H I J D F - ^G D H D - ^D B E I J F B - B..C C - B...C G H D E B C - ^D B C E I J F B C - C I J F C - C^@ I J F - C^! C - F^! D G H D F +'<rev>{caret}-{<n>}', e.g. 'HEAD{caret}-, HEAD{caret}-2':: + Equivalent to '<rev>{caret}<n>..<rev>', with '<n>' = 1 if not + given. + +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 + ^G D H D + ^D B E I J F B + ^D B C E I J F B C + C I J F C + B..C = ^B C C + B...C = B ^F C G H D E B C + B^- = B^..B + = ^B^1 B E I J F B + C^@ = C^1 + = F I J F + B^@ = B^1 B^2 B^3 + = D E F D G H E F I J + C^! = C ^C^@ + = C ^C^1 + = C ^F C + B^! = B ^B^@ + = 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-sha1-array.txt b/Documentation/technical/api-sha1-array.txt index 3e75497..dcc5294 100644 --- a/Documentation/technical/api-sha1-array.txt +++ b/Documentation/technical/api-sha1-array.txt @@ -38,16 +38,20 @@ Functions `sha1_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. + 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. Examples -------- ----------------------------------------- -void print_callback(const unsigned char sha1[20], +int print_callback(const unsigned char sha1[20], void *data) { printf("%s\n", sha1_to_hex(sha1)); + return 0; /* always continue */ } void some_func(void) diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index d40ab65..c59ac99 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -219,7 +219,9 @@ out of what the server said it could do with the first 'want' line. shallow-line = PKT-LINE("shallow" SP obj-id) - depth-request = PKT-LINE("deepen" SP depth) + depth-request = PKT-LINE("deepen" SP depth) / + PKT-LINE("deepen-since" SP timestamp) / + PKT-LINE("deepen-not" SP ref) first-want = PKT-LINE("want" SP obj-id SP capability-list) additional-want = PKT-LINE("want" SP obj-id) @@ -454,7 +456,8 @@ The reference discovery phase is done nearly the same way as it is in the fetching protocol. Each reference obj-id and name on the server is sent in packet-line format to the client, followed by a flush-pkt. The only real difference is that the capability listing is different - the only -possible values are 'report-status', 'delete-refs' and 'ofs-delta'. +possible values are 'report-status', 'delete-refs', 'ofs-delta' and +'push-options'. Reference Update Request and Packfile Transfer ---------------------------------------------- @@ -465,9 +468,10 @@ that it wants to update, it sends a line listing the obj-id currently on the server, the obj-id the client would like to update it to and the name of the reference. -This list is followed by a flush-pkt and then the packfile that should -contain all the objects that the server will need to complete the new -references. +This list is followed by a flush-pkt. Then the push options are transmitted +one per packet followed by another flush-pkt. After that the packfile that +should contain all the objects that the server will need to complete the new +references will be sent. ---- update-request = *shallow ( command-list | push-cert ) [packfile] diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index eaab6b4..26dcc6f 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -179,6 +179,31 @@ This capability adds "deepen", "shallow" and "unshallow" commands to the fetch-pack/upload-pack protocol so clients can request shallow clones. +deepen-since +------------ + +This capability adds "deepen-since" command to fetch-pack/upload-pack +protocol so the client can request shallow clones that are cut at a +specific time, instead of depth. Internally it's equivalent of doing +"rev-list --max-age=<timestamp>" on the server side. "deepen-since" +cannot be used with "deepen". + +deepen-not +---------- + +This capability adds "deepen-not" command to fetch-pack/upload-pack +protocol so the client can request shallow clones that are cut at a +specific revision, instead of depth. Internally it's equivalent of +doing "rev-list --not <rev>" on the server side. "deepen-not" +cannot be used with "deepen", but can be used with "deepen-since". + +deepen-relative +--------------- + +If this capability is requested by the client, the semantics of +"deepen" command is changed. The "depth" argument is the depth from +the current shallow boundary, instead of the depth from remote refs. + no-progress ----------- @@ -253,6 +278,15 @@ atomic pushes. If the pushing client requests this capability, the server will update the refs in one atomic transaction. Either all refs are updated or none. +push-options +------------ + +If the server sends the 'push-options' capability it is able to accept +push options after the update commands have been sent, but before the +packfile is streamed. If the pushing client requests this capability, +the server will pass the options to the pre- and post- receive hooks +that process this push request. + allow-tip-sha1-in-want ---------------------- |