diff options
Diffstat (limited to 'third_party/git/Documentation')
724 files changed, 0 insertions, 106408 deletions
diff --git a/third_party/git/Documentation/.gitattributes b/third_party/git/Documentation/.gitattributes deleted file mode 100644 index ddb030137d..0000000000 --- a/third_party/git/Documentation/.gitattributes +++ /dev/null @@ -1 +0,0 @@ -*.txt whitespace diff --git a/third_party/git/Documentation/.gitignore b/third_party/git/Documentation/.gitignore deleted file mode 100644 index 9022d48355..0000000000 --- a/third_party/git/Documentation/.gitignore +++ /dev/null @@ -1,17 +0,0 @@ -*.xml -*.html -*.[1-8] -*.made -*.texi -*.pdf -git.info -gitman.info -howto-index.txt -doc.dep -cmds-*.txt -mergetools-*.txt -manpage-base-url.xsl -SubmittingPatches.txt -tmp-doc-diff/ -GIT-ASCIIDOCFLAGS -/GIT-EXCLUDED-PROGRAMS diff --git a/third_party/git/Documentation/CodingGuidelines b/third_party/git/Documentation/CodingGuidelines deleted file mode 100644 index f45db5b727..0000000000 --- a/third_party/git/Documentation/CodingGuidelines +++ /dev/null @@ -1,639 +0,0 @@ -Like other projects, we also have some guidelines to keep to the -code. For Git in general, a few rough rules are: - - - Most importantly, we never say "It's in POSIX; we'll happily - ignore your needs should your system not conform to it." - We live in the real world. - - - However, we often say "Let's stay away from that construct, - it's not even in POSIX". - - - In spite of the above two rules, we sometimes say "Although - this is not in POSIX, it (is so convenient | makes the code - much more readable | has other good characteristics) and - practically all the platforms we care about support it, so - let's use it". - - Again, we live in the real world, and it is sometimes a - judgement call, the decision based more on real world - constraints people face than what the paper standard says. - - - Fixing style violations while working on a real change as a - preparatory clean-up step is good, but otherwise avoid useless code - churn for the sake of conforming to the style. - - "Once it _is_ in the tree, it's not really worth the patch noise to - go and fix it up." - Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html - -Make your code readable and sensible, and don't try to be clever. - -As for more concrete guidelines, just imitate the existing code -(this is a good guideline, no matter which project you are -contributing to). It is always preferable to match the _local_ -convention. New code added to Git suite is expected to match -the overall style of existing code. Modifications to existing -code is expected to match the style the surrounding code already -uses (even if it doesn't match the overall style of existing code). - -But if you must have a list of rules, here they are. - -For shell scripts specifically (not exhaustive): - - - We use tabs for indentation. - - - Case arms are indented at the same depth as case and esac lines, - like this: - - case "$variable" in - pattern1) - do this - ;; - pattern2) - do that - ;; - esac - - - Redirection operators should be written with space before, but no - space after them. In other words, write 'echo test >"$file"' - instead of 'echo test> $file' or 'echo test > $file'. Note that - even though it is not required by POSIX to double-quote the - redirection target in a variable (as shown above), our code does so - because some versions of bash issue a warning without the quotes. - - (incorrect) - cat hello > world < universe - echo hello >$world - - (correct) - cat hello >world <universe - echo hello >"$world" - - - We prefer $( ... ) for command substitution; unlike ``, it - properly nests. It should have been the way Bourne spelled - it from day one, but unfortunately isn't. - - - If you want to find out if a command is available on the user's - $PATH, you should use 'type <command>', instead of 'which <command>'. - The output of 'which' is not machine parseable and its exit code - is not reliable across platforms. - - - We use POSIX compliant parameter substitutions and avoid bashisms; - namely: - - - We use ${parameter-word} and its [-=?+] siblings, and their - colon'ed "unset or null" form. - - - We use ${parameter#word} and its [#%] siblings, and their - doubled "longest matching" form. - - - No "Substring Expansion" ${parameter:offset:length}. - - - No shell arrays. - - - No strlen ${#parameter}. - - - No pattern replacement ${parameter/pattern/string}. - - - We use Arithmetic Expansion $(( ... )). - - - Inside Arithmetic Expansion, spell shell variables with $ in front - of them, as some shells do not grok $((x)) while accepting $(($x)) - just fine (e.g. dash older than 0.5.4). - - - We do not use Process Substitution <(list) or >(list). - - - Do not write control structures on a single line with semicolon. - "then" should be on the next line for if statements, and "do" - should be on the next line for "while" and "for". - - (incorrect) - if test -f hello; then - do this - fi - - (correct) - if test -f hello - then - do this - fi - - - If a command sequence joined with && or || or | spans multiple - lines, put each command on a separate line and put && and || and | - operators at the end of each line, rather than the start. This - means you don't need to use \ to join lines, since the above - operators imply the sequence isn't finished. - - (incorrect) - grep blob verify_pack_result \ - | awk -f print_1.awk \ - | sort >actual && - ... - - (correct) - grep blob verify_pack_result | - awk -f print_1.awk | - sort >actual && - ... - - - We prefer "test" over "[ ... ]". - - - We do not write the noiseword "function" in front of shell - functions. - - - We prefer a space between the function name and the parentheses, - and no space inside the parentheses. The opening "{" should also - be on the same line. - - (incorrect) - my_function(){ - ... - - (correct) - my_function () { - ... - - - As to use of grep, stick to a subset of BRE (namely, no \{m,n\}, - [::], [==], or [..]) for portability. - - - We do not use \{m,n\}; - - - We do not use -E; - - - We do not use ? or + (which are \{0,1\} and \{1,\} - respectively in BRE) but that goes without saying as these - are ERE elements not BRE (note that \? and \+ are not even part - of BRE -- making them accessible from BRE is a GNU extension). - - - Use Git's gettext wrappers in git-sh-i18n to make the user - interface translatable. See "Marking strings for translation" in - po/README. - - - We do not write our "test" command with "-a" and "-o" and use "&&" - or "||" to concatenate multiple "test" commands instead, because - the use of "-a/-o" is often error-prone. E.g. - - test -n "$x" -a "$a" = "$b" - - is buggy and breaks when $x is "=", but - - test -n "$x" && test "$a" = "$b" - - does not have such a problem. - - -For C programs: - - - We use tabs to indent, and interpret tabs as taking up to - 8 spaces. - - - We try to keep to at most 80 characters per line. - - - As a Git developer we assume you have a reasonably modern compiler - and we recommend you to enable the DEVELOPER makefile knob to - ensure your patch is clear of all compiler warnings we care about, - by e.g. "echo DEVELOPER=1 >>config.mak". - - - We try to support a wide range of C compilers to compile Git with, - including old ones. You should not use features from newer C - standard, even if your compiler groks them. - - There are a few exceptions to this guideline: - - . since early 2012 with e1327023ea, we have been using an enum - definition whose last element is followed by a comma. This, like - an array initializer that ends with a trailing comma, can be used - to reduce the patch noise when adding a new identifer at the end. - - . since mid 2017 with cbc0f81d, we have been using designated - initializers for struct (e.g. "struct t v = { .val = 'a' };"). - - . since mid 2017 with 512f41cf, we have been using designated - initializers for array (e.g. "int array[10] = { [5] = 2 }"). - - These used to be forbidden, but we have not heard any breakage - report, and they are assumed to be safe. - - - Variables have to be declared at the beginning of the block, before - the first statement (i.e. -Wdeclaration-after-statement). - - - Declaring a variable in the for loop "for (int i = 0; i < 10; i++)" - is still not allowed in this codebase. - - - NULL pointers shall be written as NULL, not as 0. - - - When declaring pointers, the star sides with the variable - name, i.e. "char *string", not "char* string" or - "char * string". This makes it easier to understand code - like "char *string, c;". - - - Use whitespace around operators and keywords, but not inside - parentheses and not around functions. So: - - while (condition) - func(bar + 1); - - and not: - - while( condition ) - func (bar+1); - - - We avoid using braces unnecessarily. I.e. - - if (bla) { - x = 1; - } - - is frowned upon. But there are a few exceptions: - - - When the statement extends over a few lines (e.g., a while loop - with an embedded conditional, or a comment). E.g.: - - while (foo) { - if (x) - one(); - else - two(); - } - - if (foo) { - /* - * This one requires some explanation, - * so we're better off with braces to make - * it obvious that the indentation is correct. - */ - doit(); - } - - - When there are multiple arms to a conditional and some of them - require braces, enclose even a single line block in braces for - consistency. E.g.: - - if (foo) { - doit(); - } else { - one(); - two(); - three(); - } - - - We try to avoid assignments in the condition of an "if" statement. - - - Try to make your code understandable. You may put comments - in, but comments invariably tend to stale out when the code - they were describing changes. Often splitting a function - into two makes the intention of the code much clearer. - - - Multi-line comments include their delimiters on separate lines from - the text. E.g. - - /* - * A very long - * multi-line comment. - */ - - Note however that a comment that explains a translatable string to - translators uses a convention of starting with a magic token - "TRANSLATORS: ", e.g. - - /* - * TRANSLATORS: here is a comment that explains the string to - * be translated, that follows immediately after it. - */ - _("Here is a translatable string explained by the above."); - - - Double negation is often harder to understand than no negation - at all. - - - There are two schools of thought when it comes to comparison, - especially inside a loop. Some people prefer to have the less stable - value on the left hand side and the more stable value on the right hand - side, e.g. if you have a loop that counts variable i down to the - lower bound, - - while (i > lower_bound) { - do something; - i--; - } - - Other people prefer to have the textual order of values match the - actual order of values in their comparison, so that they can - mentally draw a number line from left to right and place these - values in order, i.e. - - while (lower_bound < i) { - do something; - i--; - } - - Both are valid, and we use both. However, the more "stable" the - stable side becomes, the more we tend to prefer the former - (comparison with a constant, "i > 0", is an extreme example). - Just do not mix styles in the same part of the code and mimic - existing styles in the neighbourhood. - - - There are two schools of thought when it comes to splitting a long - logical line into multiple lines. Some people push the second and - subsequent lines far enough to the right with tabs and align them: - - if (the_beginning_of_a_very_long_expression_that_has_to || - span_more_than_a_single_line_of || - the_source_text) { - ... - - while other people prefer to align the second and the subsequent - lines with the column immediately inside the opening parenthesis, - with tabs and spaces, following our "tabstop is always a multiple - of 8" convention: - - if (the_beginning_of_a_very_long_expression_that_has_to || - span_more_than_a_single_line_of || - the_source_text) { - ... - - Both are valid, and we use both. Again, just do not mix styles in - the same part of the code and mimic existing styles in the - neighbourhood. - - - When splitting a long logical line, some people change line before - a binary operator, so that the result looks like a parse tree when - you turn your head 90-degrees counterclockwise: - - if (the_beginning_of_a_very_long_expression_that_has_to - || span_more_than_a_single_line_of_the_source_text) { - - while other people prefer to leave the operator at the end of the - line: - - if (the_beginning_of_a_very_long_expression_that_has_to || - span_more_than_a_single_line_of_the_source_text) { - - Both are valid, but we tend to use the latter more, unless the - expression gets fairly complex, in which case the former tends to - be easier to read. Again, just do not mix styles in the same part - of the code and mimic existing styles in the neighbourhood. - - - When splitting a long logical line, with everything else being - equal, it is preferable to split after the operator at higher - level in the parse tree. That is, this is more preferable: - - if (a_very_long_variable * that_is_used_in + - a_very_long_expression) { - ... - - than - - if (a_very_long_variable * - that_is_used_in + a_very_long_expression) { - ... - - - Some clever tricks, like using the !! operator with arithmetic - constructs, can be extremely confusing to others. Avoid them, - unless there is a compelling reason to use them. - - - Use the API. No, really. We have a strbuf (variable length - string), several arrays with the ALLOC_GROW() macro, a - string_list for sorted string lists, a hash map (mapping struct - objects) named "struct decorate", amongst other things. - - - When you come up with an API, document its functions and structures - in the header file that exposes the API to its callers. Use what is - in "strbuf.h" as a model for the appropriate tone and level of - detail. - - - The first #include in C files, except in platform specific compat/ - implementations, must be either "git-compat-util.h", "cache.h" or - "builtin.h". You do not have to include more than one of these. - - - A C file must directly include the header files that declare the - functions and the types it uses, except for the functions and types - that are made available to it by including one of the header files - it must include by the previous rule. - - - If you are planning a new command, consider writing it in shell - or perl first, so that changes in semantics can be easily - changed and discussed. Many Git commands started out like - that, and a few are still scripts. - - - Avoid introducing a new dependency into Git. This means you - usually should stay away from scripting languages not already - used in the Git core command set (unless your command is clearly - separate from it, such as an importer to convert random-scm-X - repositories to Git). - - - When we pass <string, length> pair to functions, we should try to - pass them in that order. - - - Use Git's gettext wrappers to make the user interface - translatable. See "Marking strings for translation" in po/README. - - - Variables and functions local to a given source file should be marked - with "static". Variables that are visible to other source files - must be declared with "extern" in header files. However, function - declarations should not use "extern", as that is already the default. - - - You can launch gdb around your program using the shorthand GIT_DEBUGGER. - Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or - run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to - use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb" - ./bin-wrappers/git log` (See `wrap-for-bin.sh`.) - -For Perl programs: - - - Most of the C guidelines above apply. - - - We try to support Perl 5.8 and later ("use Perl 5.008"). - - - use strict and use warnings are strongly preferred. - - - Don't overuse statement modifiers unless using them makes the - result easier to follow. - - ... do something ... - do_this() unless (condition); - ... do something else ... - - is more readable than: - - ... do something ... - unless (condition) { - do_this(); - } - ... do something else ... - - *only* when the condition is so rare that do_this() will be almost - always called. - - - We try to avoid assignments inside "if ()" conditions. - - - Learn and use Git.pm if you need that functionality. - - - For Emacs, it's useful to put the following in - GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode: - - ;; note the first part is useful for C editing, too - ((nil . ((indent-tabs-mode . t) - (tab-width . 8) - (fill-column . 80))) - (cperl-mode . ((cperl-indent-level . 8) - (cperl-extra-newline-before-brace . nil) - (cperl-merge-trailing-else . t)))) - -For Python scripts: - - - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/). - - - As a minimum, we aim to be compatible with Python 2.6 and 2.7. - - - Where required libraries do not restrict us to Python 2, we try to - also be compatible with Python 3.1 and later. - - - When you must differentiate between Unicode literals and byte string - literals, it is OK to use the 'b' prefix. Even though the Python - documentation for version 2.6 does not mention this prefix, it has - been supported since version 2.6.0. - -Error Messages - - - Do not end error messages with a full stop. - - - Do not capitalize ("unable to open %s", not "Unable to open %s") - - - Say what the error is first ("cannot open %s", not "%s: cannot open") - - -Externally Visible Names - - - For configuration variable names, follow the existing convention: - - . The section name indicates the affected subsystem. - - . The subsection name, if any, indicates which of an unbounded set - of things to set the value for. - - . The variable name describes the effect of tweaking this knob. - - The section and variable names that consist of multiple words are - formed by concatenating the words without punctuations (e.g. `-`), - and are broken using bumpyCaps in documentation as a hint to the - reader. - - When choosing the variable namespace, do not use variable name for - specifying possibly unbounded set of things, most notably anything - an end user can freely come up with (e.g. branch names). Instead, - use subsection names or variable values, like the existing variable - branch.<name>.description does. - - -Writing Documentation: - - Most (if not all) of the documentation pages are written in the - AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and - processed into HTML and manpages (e.g. git.html and git.1 in the - same directory). - - The documentation liberally mixes US and UK English (en_US/UK) - norms for spelling and grammar, which is somewhat unfortunate. - In an ideal world, it would have been better if it consistently - used only one and not the other, and we would have picked en_US - (if you wish to correct the English of some of the existing - documentation, please see the documentation-related advice in the - Documentation/SubmittingPatches file). - - Every user-visible change should be reflected in the documentation. - The same general rule as for code applies -- imitate the existing - conventions. - - A few commented examples follow to provide reference when writing or - modifying command usage strings and synopsis sections in the manual - pages: - - Placeholders are spelled in lowercase and enclosed in angle brackets: - <file> - --sort=<key> - --abbrev[=<n>] - - If a placeholder has multiple words, they are separated by dashes: - <new-branch-name> - --template=<template-directory> - - Possibility of multiple occurrences is indicated by three dots: - <file>... - (One or more of <file>.) - - Optional parts are enclosed in square brackets: - [<extra>] - (Zero or one <extra>.) - - --exec-path[=<path>] - (Option with an optional argument. Note that the "=" is inside the - brackets.) - - [<patch>...] - (Zero or more of <patch>. Note that the dots are inside, not - outside the brackets.) - - Multiple alternatives are indicated with vertical bars: - [-q | --quiet] - [--utf8 | --no-utf8] - - Parentheses are used for grouping: - [(<rev> | <range>)...] - (Any number of either <rev> or <range>. Parens are needed to make - it clear that "..." pertains to both <rev> and <range>.) - - [(-p <parent>)...] - (Any number of option -p, each with one <parent> argument.) - - git remote set-head <name> (-a | -d | <branch>) - (One and only one of "-a", "-d" or "<branch>" _must_ (no square - brackets) be provided.) - - And a somewhat more contrived example: - --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]] - Here "=" is outside the brackets, because "--diff-filter=" is a - valid usage. "*" has its own pair of brackets, because it can - (optionally) be specified only when one or more of the letters is - also provided. - - A note on notation: - Use 'git' (all lowercase) when talking about commands i.e. something - the user would type into a shell and use 'Git' (uppercase first letter) - when talking about the version control system and its properties. - - A few commented examples follow to provide reference when writing or - modifying paragraphs or option/command explanations that contain options - or commands: - - Literal examples (e.g. use of command-line options, command names, - branch names, URLs, pathnames (files and directories), configuration and - environment variables) must be typeset in monospace (i.e. wrapped with - backticks): - `--pretty=oneline` - `git rev-list` - `remote.pushDefault` - `http://git.example.com` - `.git/config` - `GIT_DIR` - `HEAD` - - An environment variable must be prefixed with "$" only when referring to its - value and not when referring to the variable itself, in this case there is - nothing to add except the backticks: - `GIT_DIR` is specified - `$GIT_DIR/hooks/pre-receive` - - Word phrases enclosed in `backtick characters` are rendered literally - and will not be further expanded. The use of `backticks` to achieve the - previous rule means that literal examples should not use AsciiDoc - escapes. - Correct: - `--pretty=oneline` - Incorrect: - `\--pretty=oneline` - - If some place in the documentation needs to typeset a command usage - example with inline substitutions, it is fine to use +monospaced and - inline substituted text+ instead of `monospaced literal text`, and with - the former, the part that should not get substituted must be - quoted/escaped. diff --git a/third_party/git/Documentation/Makefile b/third_party/git/Documentation/Makefile deleted file mode 100644 index 76f2ecfc1b..0000000000 --- a/third_party/git/Documentation/Makefile +++ /dev/null @@ -1,487 +0,0 @@ -# Guard against environment variables -MAN1_TXT = -MAN5_TXT = -MAN7_TXT = -TECH_DOCS = -ARTICLES = -SP_ARTICLES = -OBSOLETE_HTML = - --include GIT-EXCLUDED-PROGRAMS - -MAN1_TXT += $(filter-out \ - $(patsubst %,%.txt,$(EXCLUDED_PROGRAMS)) \ - $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ - $(wildcard git-*.txt)) -MAN1_TXT += git.txt -MAN1_TXT += gitk.txt -MAN1_TXT += gitweb.txt - -MAN5_TXT += gitattributes.txt -MAN5_TXT += githooks.txt -MAN5_TXT += gitignore.txt -MAN5_TXT += gitmodules.txt -MAN5_TXT += gitrepository-layout.txt -MAN5_TXT += gitweb.conf.txt - -MAN7_TXT += gitcli.txt -MAN7_TXT += gitcore-tutorial.txt -MAN7_TXT += gitcredentials.txt -MAN7_TXT += gitcvs-migration.txt -MAN7_TXT += gitdiffcore.txt -MAN7_TXT += giteveryday.txt -MAN7_TXT += gitglossary.txt -MAN7_TXT += gitnamespaces.txt -MAN7_TXT += gitremote-helpers.txt -MAN7_TXT += gitrevisions.txt -MAN7_TXT += gitsubmodules.txt -MAN7_TXT += gittutorial-2.txt -MAN7_TXT += gittutorial.txt -MAN7_TXT += gitworkflows.txt - -ifdef MAN_FILTER -MAN_TXT = $(filter $(MAN_FILTER),$(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)) -else -MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT) -MAN_FILTER = $(MAN_TXT) -endif - -MAN_XML = $(patsubst %.txt,%.xml,$(MAN_TXT)) -MAN_HTML = $(patsubst %.txt,%.html,$(MAN_TXT)) -GIT_MAN_REF = master - -OBSOLETE_HTML += everyday.html -OBSOLETE_HTML += git-remote-helpers.html - -ARTICLES += howto-index -ARTICLES += git-tools -ARTICLES += git-bisect-lk2009 -# with their own formatting rules. -SP_ARTICLES += user-manual -SP_ARTICLES += howto/new-command -SP_ARTICLES += howto/revert-branch-rebase -SP_ARTICLES += howto/using-merge-subtree -SP_ARTICLES += howto/using-signed-tag-in-pull-request -SP_ARTICLES += howto/use-git-daemon -SP_ARTICLES += howto/update-hook-example -SP_ARTICLES += howto/setup-git-server-over-http -SP_ARTICLES += howto/separating-topic-branches -SP_ARTICLES += howto/revert-a-faulty-merge -SP_ARTICLES += howto/recover-corrupted-blob-object -SP_ARTICLES += howto/recover-corrupted-object-harder -SP_ARTICLES += howto/rebuild-from-update-hook -SP_ARTICLES += howto/rebase-from-internal-branch -SP_ARTICLES += howto/keep-canonical-history-correct -SP_ARTICLES += howto/maintain-git -API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) -SP_ARTICLES += $(API_DOCS) - -TECH_DOCS += MyFirstContribution -TECH_DOCS += SubmittingPatches -TECH_DOCS += technical/hash-function-transition -TECH_DOCS += technical/http-protocol -TECH_DOCS += technical/index-format -TECH_DOCS += technical/long-running-process-protocol -TECH_DOCS += technical/multi-pack-index -TECH_DOCS += technical/pack-format -TECH_DOCS += technical/pack-heuristics -TECH_DOCS += technical/pack-protocol -TECH_DOCS += technical/partial-clone -TECH_DOCS += technical/protocol-capabilities -TECH_DOCS += technical/protocol-common -TECH_DOCS += technical/protocol-v2 -TECH_DOCS += technical/racy-git -TECH_DOCS += technical/send-pack-pipeline -TECH_DOCS += technical/shallow -TECH_DOCS += technical/signature-format -TECH_DOCS += technical/trivial-merge -SP_ARTICLES += $(TECH_DOCS) -SP_ARTICLES += technical/api-index - -ARTICLES_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES)) -HTML_FILTER ?= $(ARTICLES_HTML) $(OBSOLETE_HTML) -DOC_HTML = $(MAN_HTML) $(filter $(HTML_FILTER),$(ARTICLES_HTML) $(OBSOLETE_HTML)) - -DOC_MAN1 = $(patsubst %.txt,%.1,$(filter $(MAN_FILTER),$(MAN1_TXT))) -DOC_MAN5 = $(patsubst %.txt,%.5,$(filter $(MAN_FILTER),$(MAN5_TXT))) -DOC_MAN7 = $(patsubst %.txt,%.7,$(filter $(MAN_FILTER),$(MAN7_TXT))) - -prefix ?= $(HOME) -bindir ?= $(prefix)/bin -htmldir ?= $(prefix)/share/doc/git-doc -infodir ?= $(prefix)/share/info -pdfdir ?= $(prefix)/share/doc/git-doc -mandir ?= $(prefix)/share/man -man1dir = $(mandir)/man1 -man5dir = $(mandir)/man5 -man7dir = $(mandir)/man7 -# DESTDIR = - -ASCIIDOC = asciidoc -ASCIIDOC_EXTRA = -ASCIIDOC_HTML = xhtml11 -ASCIIDOC_DOCBOOK = docbook -ASCIIDOC_CONF = -f asciidoc.conf -ASCIIDOC_COMMON = $(ASCIIDOC) $(ASCIIDOC_EXTRA) $(ASCIIDOC_CONF) \ - -agit_version=$(GIT_VERSION) -TXT_TO_HTML = $(ASCIIDOC_COMMON) -b $(ASCIIDOC_HTML) -TXT_TO_XML = $(ASCIIDOC_COMMON) -b $(ASCIIDOC_DOCBOOK) -MANPAGE_XSL = manpage-normal.xsl -XMLTO = xmlto -XMLTO_EXTRA = -INSTALL ?= install -RM ?= rm -f -MAN_REPO = ../../git-manpages -HTML_REPO = ../../git-htmldocs - -MAKEINFO = makeinfo -INSTALL_INFO = install-info -DOCBOOK2X_TEXI = docbook2x-texi -DBLATEX = dblatex -ASCIIDOC_DBLATEX_DIR = /etc/asciidoc/dblatex -DBLATEX_COMMON = -p $(ASCIIDOC_DBLATEX_DIR)/asciidoc-dblatex.xsl -s $(ASCIIDOC_DBLATEX_DIR)/asciidoc-dblatex.sty -ifndef PERL_PATH - PERL_PATH = /usr/bin/perl -endif - --include ../config.mak.autogen --include ../config.mak - -# -# For docbook-xsl ... -# -1.68.1, no extra settings are needed? -# 1.69.0, set ASCIIDOC_ROFF? -# 1.69.1-1.71.0, set DOCBOOK_SUPPRESS_SP? -# 1.71.1, set ASCIIDOC_ROFF? -# 1.72.0, set DOCBOOK_XSL_172. -# 1.73.0-, no extra settings are needed -# - -ifdef DOCBOOK_XSL_172 -ASCIIDOC_EXTRA += -a git-asciidoc-no-roff -MANPAGE_XSL = manpage-1.72.xsl -else - ifndef ASCIIDOC_ROFF - # docbook-xsl after 1.72 needs the regular XSL, but will not - # pass-thru raw roff codes from asciidoc.conf, so turn them off. - ASCIIDOC_EXTRA += -a git-asciidoc-no-roff - endif -endif -ifndef NO_MAN_BOLD_LITERAL -XMLTO_EXTRA += -m manpage-bold-literal.xsl -endif -ifdef DOCBOOK_SUPPRESS_SP -XMLTO_EXTRA += -m manpage-suppress-sp.xsl -endif - -# Newer DocBook stylesheet emits warning cruft in the output when -# this is not set, and if set it shows an absolute link. Older -# stylesheets simply ignore this parameter. -# -# Distros may want to use MAN_BASE_URL=file:///path/to/git/docs/ -# or similar. -ifndef MAN_BASE_URL -MAN_BASE_URL = file://$(htmldir)/ -endif -XMLTO_EXTRA += -m manpage-base-url.xsl - -# If your target system uses GNU groff, it may try to render -# apostrophes as a "pretty" apostrophe using unicode. This breaks -# cut&paste, so you should set GNU_ROFF to force them to be ASCII -# apostrophes. Unfortunately does not work with non-GNU roff. -ifdef GNU_ROFF -XMLTO_EXTRA += -m manpage-quote-apos.xsl -endif - -ifdef USE_ASCIIDOCTOR -ASCIIDOC = asciidoctor -ASCIIDOC_CONF = -ASCIIDOC_HTML = xhtml5 -ASCIIDOC_DOCBOOK = docbook45 -ASCIIDOC_EXTRA += -acompat-mode -atabsize=8 -ASCIIDOC_EXTRA += -I. -rasciidoctor-extensions -ASCIIDOC_EXTRA += -alitdd='&\#x2d;&\#x2d;' -DBLATEX_COMMON = -endif - -SHELL_PATH ?= $(SHELL) -# Shell quote; -SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH)) - -ifdef DEFAULT_PAGER -DEFAULT_PAGER_SQ = $(subst ','\'',$(DEFAULT_PAGER)) -ASCIIDOC_EXTRA += -a 'git-default-pager=$(DEFAULT_PAGER_SQ)' -endif - -ifdef DEFAULT_EDITOR -DEFAULT_EDITOR_SQ = $(subst ','\'',$(DEFAULT_EDITOR)) -ASCIIDOC_EXTRA += -a 'git-default-editor=$(DEFAULT_EDITOR_SQ)' -endif - -QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir -QUIET_SUBDIR1 = - -ifneq ($(findstring $(MAKEFLAGS),w),w) -PRINT_DIR = --no-print-directory -else # "make -w" -NO_SUBDIR = : -endif - -ifneq ($(findstring $(MAKEFLAGS),s),s) -ifndef V - QUIET_ASCIIDOC = @echo ' ' ASCIIDOC $@; - QUIET_XMLTO = @echo ' ' XMLTO $@; - QUIET_DB2TEXI = @echo ' ' DB2TEXI $@; - QUIET_MAKEINFO = @echo ' ' MAKEINFO $@; - QUIET_DBLATEX = @echo ' ' DBLATEX $@; - QUIET_XSLTPROC = @echo ' ' XSLTPROC $@; - QUIET_GEN = @echo ' ' GEN $@; - QUIET_LINT = @echo ' ' LINT $@; - QUIET_STDERR = 2> /dev/null - QUIET_SUBDIR0 = +@subdir= - QUIET_SUBDIR1 = ;$(NO_SUBDIR) echo ' ' SUBDIR $$subdir; \ - $(MAKE) $(PRINT_DIR) -C $$subdir - export V -endif -endif - -all: html man - -html: $(DOC_HTML) - -man: man1 man5 man7 -man1: $(DOC_MAN1) -man5: $(DOC_MAN5) -man7: $(DOC_MAN7) - -info: git.info gitman.info - -pdf: user-manual.pdf - -install: install-man - -install-man: man - $(INSTALL) -d -m 755 $(DESTDIR)$(man1dir) - $(INSTALL) -d -m 755 $(DESTDIR)$(man5dir) - $(INSTALL) -d -m 755 $(DESTDIR)$(man7dir) - $(INSTALL) -m 644 $(DOC_MAN1) $(DESTDIR)$(man1dir) - $(INSTALL) -m 644 $(DOC_MAN5) $(DESTDIR)$(man5dir) - $(INSTALL) -m 644 $(DOC_MAN7) $(DESTDIR)$(man7dir) - -install-info: info - $(INSTALL) -d -m 755 $(DESTDIR)$(infodir) - $(INSTALL) -m 644 git.info gitman.info $(DESTDIR)$(infodir) - if test -r $(DESTDIR)$(infodir)/dir; then \ - $(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) git.info ;\ - $(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) gitman.info ;\ - else \ - echo "No directory found in $(DESTDIR)$(infodir)" >&2 ; \ - fi - -install-pdf: pdf - $(INSTALL) -d -m 755 $(DESTDIR)$(pdfdir) - $(INSTALL) -m 644 user-manual.pdf $(DESTDIR)$(pdfdir) - -install-html: html - '$(SHELL_PATH_SQ)' ./install-webdoc.sh $(DESTDIR)$(htmldir) - -../GIT-VERSION-FILE: FORCE - $(QUIET_SUBDIR0)../ $(QUIET_SUBDIR1) GIT-VERSION-FILE - --include ../GIT-VERSION-FILE - -# -# Determine "include::" file references in asciidoc files. -# -docdep_prereqs = \ - mergetools-list.made $(mergetools_txt) \ - cmd-list.made $(cmds_txt) - -doc.dep : $(docdep_prereqs) $(wildcard *.txt) $(wildcard config/*.txt) build-docdep.perl - $(QUIET_GEN)$(RM) $@+ $@ && \ - $(PERL_PATH) ./build-docdep.perl >$@+ $(QUIET_STDERR) && \ - mv $@+ $@ - --include doc.dep - -cmds_txt = cmds-ancillaryinterrogators.txt \ - cmds-ancillarymanipulators.txt \ - cmds-mainporcelain.txt \ - cmds-plumbinginterrogators.txt \ - cmds-plumbingmanipulators.txt \ - cmds-synchingrepositories.txt \ - cmds-synchelpers.txt \ - cmds-purehelpers.txt \ - cmds-foreignscminterface.txt - -$(cmds_txt): cmd-list.made - -cmd-list.made: cmd-list.perl ../command-list.txt $(MAN1_TXT) - $(QUIET_GEN)$(RM) $@ && \ - $(PERL_PATH) ./cmd-list.perl ../command-list.txt $(QUIET_STDERR) && \ - date >$@ - -mergetools_txt = mergetools-diff.txt mergetools-merge.txt - -$(mergetools_txt): mergetools-list.made - -mergetools-list.made: ../git-mergetool--lib.sh $(wildcard ../mergetools/*) - $(QUIET_GEN)$(RM) $@ && \ - $(SHELL_PATH) -c 'MERGE_TOOLS_DIR=../mergetools && \ - . ../git-mergetool--lib.sh && \ - show_tool_names can_diff "* " || :' >mergetools-diff.txt && \ - $(SHELL_PATH) -c 'MERGE_TOOLS_DIR=../mergetools && \ - . ../git-mergetool--lib.sh && \ - show_tool_names can_merge "* " || :' >mergetools-merge.txt && \ - date >$@ - -TRACK_ASCIIDOCFLAGS = $(subst ','\'',$(ASCIIDOC_COMMON):$(ASCIIDOC_HTML):$(ASCIIDOC_DOCBOOK)) - -GIT-ASCIIDOCFLAGS: FORCE - @FLAGS='$(TRACK_ASCIIDOCFLAGS)'; \ - if test x"$$FLAGS" != x"`cat GIT-ASCIIDOCFLAGS 2>/dev/null`" ; then \ - echo >&2 " * new asciidoc flags"; \ - echo "$$FLAGS" >GIT-ASCIIDOCFLAGS; \ - fi - -clean: - $(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7 - $(RM) *.texi *.texi+ *.texi++ git.info gitman.info - $(RM) *.pdf - $(RM) howto-index.txt howto/*.html doc.dep - $(RM) technical/*.html technical/api-index.txt - $(RM) SubmittingPatches.txt - $(RM) $(cmds_txt) $(mergetools_txt) *.made - $(RM) manpage-base-url.xsl - $(RM) GIT-ASCIIDOCFLAGS - -$(MAN_HTML): %.html : %.txt asciidoc.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS - $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(TXT_TO_HTML) -d manpage -o $@+ $< && \ - mv $@+ $@ - -$(OBSOLETE_HTML): %.html : %.txto asciidoc.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS - $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(TXT_TO_HTML) -o $@+ $< && \ - mv $@+ $@ - -manpage-base-url.xsl: manpage-base-url.xsl.in - $(QUIET_GEN)sed "s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|" $< > $@ - -%.1 %.5 %.7 : %.xml manpage-base-url.xsl $(wildcard manpage*.xsl) - $(QUIET_XMLTO)$(RM) $@ && \ - $(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $< - -%.xml : %.txt asciidoc.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS - $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(TXT_TO_XML) -d manpage -o $@+ $< && \ - mv $@+ $@ - -user-manual.xml: user-manual.txt user-manual.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS - $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(TXT_TO_XML) -d book -o $@+ $< && \ - mv $@+ $@ - -technical/api-index.txt: technical/api-index-skel.txt \ - technical/api-index.sh $(patsubst %,%.txt,$(API_DOCS)) - $(QUIET_GEN)cd technical && '$(SHELL_PATH_SQ)' ./api-index.sh - -technical/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../ -$(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : %.txt \ - asciidoc.conf GIT-ASCIIDOCFLAGS - $(QUIET_ASCIIDOC)$(TXT_TO_HTML) $*.txt - -SubmittingPatches.txt: SubmittingPatches - $(QUIET_GEN) cp $< $@ - -XSLT = docbook.xsl -XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css - -user-manual.html: user-manual.xml $(XSLT) - $(QUIET_XSLTPROC)$(RM) $@+ $@ && \ - xsltproc $(XSLTOPTS) -o $@+ $(XSLT) $< && \ - mv $@+ $@ - -git.info: user-manual.texi - $(QUIET_MAKEINFO)$(MAKEINFO) --no-split -o $@ user-manual.texi - -user-manual.texi: user-manual.xml - $(QUIET_DB2TEXI)$(RM) $@+ $@ && \ - $(DOCBOOK2X_TEXI) user-manual.xml --encoding=UTF-8 --to-stdout >$@++ && \ - $(PERL_PATH) fix-texi.perl <$@++ >$@+ && \ - rm $@++ && \ - mv $@+ $@ - -user-manual.pdf: user-manual.xml - $(QUIET_DBLATEX)$(RM) $@+ $@ && \ - $(DBLATEX) -o $@+ $(DBLATEX_COMMON) $< && \ - mv $@+ $@ - -gitman.texi: $(MAN_XML) cat-texi.perl texi.xsl - $(QUIET_DB2TEXI)$(RM) $@+ $@ && \ - ($(foreach xml,$(sort $(MAN_XML)),xsltproc -o $(xml)+ texi.xsl $(xml) && \ - $(DOCBOOK2X_TEXI) --encoding=UTF-8 --to-stdout $(xml)+ && \ - rm $(xml)+ &&) true) > $@++ && \ - $(PERL_PATH) cat-texi.perl $@ <$@++ >$@+ && \ - rm $@++ && \ - mv $@+ $@ - -gitman.info: gitman.texi - $(QUIET_MAKEINFO)$(MAKEINFO) --no-split --no-validate $*.texi - -$(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml - $(QUIET_DB2TEXI)$(RM) $@+ $@ && \ - $(DOCBOOK2X_TEXI) --to-stdout $*.xml >$@+ && \ - mv $@+ $@ - -howto-index.txt: howto-index.sh $(wildcard howto/*.txt) - $(QUIET_GEN)$(RM) $@+ $@ && \ - '$(SHELL_PATH_SQ)' ./howto-index.sh $(sort $(wildcard howto/*.txt)) >$@+ && \ - mv $@+ $@ - -$(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt - $(QUIET_ASCIIDOC)$(TXT_TO_HTML) $*.txt - -WEBDOC_DEST = /pub/software/scm/git/docs - -howto/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../ -$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt GIT-ASCIIDOCFLAGS - $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - sed -e '1,/^$$/d' $< | \ - $(TXT_TO_HTML) - >$@+ && \ - mv $@+ $@ - -install-webdoc : html - '$(SHELL_PATH_SQ)' ./install-webdoc.sh $(WEBDOC_DEST) - -# You must have a clone of 'git-htmldocs' and 'git-manpages' repositories -# next to the 'git' repository itself for the following to work. - -quick-install: quick-install-man - -require-manrepo:: - @if test ! -d $(MAN_REPO); \ - then echo "git-manpages repository must exist at $(MAN_REPO)"; exit 1; fi - -quick-install-man: require-manrepo - '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(MAN_REPO) $(DESTDIR)$(mandir) $(GIT_MAN_REF) - -require-htmlrepo:: - @if test ! -d $(HTML_REPO); \ - then echo "git-htmldocs repository must exist at $(HTML_REPO)"; exit 1; fi - -quick-install-html: require-htmlrepo - '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(HTML_REPO) $(DESTDIR)$(htmldir) $(GIT_MAN_REF) - -print-man1: - @for i in $(MAN1_TXT); do echo $$i; done - -lint-docs:: - $(QUIET_LINT)$(PERL_PATH) lint-gitlink.perl - -ifeq ($(wildcard po/Makefile),po/Makefile) -doc-l10n install-l10n:: - $(MAKE) -C po $@ -endif - -.PHONY: FORCE diff --git a/third_party/git/Documentation/MyFirstContribution.txt b/third_party/git/Documentation/MyFirstContribution.txt deleted file mode 100644 index f8670379c0..0000000000 --- a/third_party/git/Documentation/MyFirstContribution.txt +++ /dev/null @@ -1,1134 +0,0 @@ -My First Contribution to the Git Project -======================================== -:sectanchors: - -[[summary]] -== Summary - -This is a tutorial demonstrating the end-to-end workflow of creating a change to -the Git tree, sending it for review, and making changes based on comments. - -[[prerequisites]] -=== Prerequisites - -This tutorial assumes you're already fairly familiar with using Git to manage -source code. The Git workflow steps will largely remain unexplained. - -[[related-reading]] -=== Related Reading - -This tutorial aims to summarize the following documents, but the reader may find -useful additional context: - -- `Documentation/SubmittingPatches` -- `Documentation/howto/new-command.txt` - -[[getting-started]] -== Getting Started - -[[cloning]] -=== Clone the Git Repository - -Git is mirrored in a number of locations. Clone the repository from one of them; -https://git-scm.com/downloads suggests one of the best places to clone from is -the mirror on GitHub. - ----- -$ git clone https://github.com/git/git git -$ cd git ----- - -[[identify-problem]] -=== Identify Problem to Solve - -//// -Use + to indicate fixed-width here; couldn't get ` to work nicely with the -quotes around "Pony Saying 'Um, Hello'". -//// -In this tutorial, we will add a new command, +git psuh+, short for ``Pony Saying -`Um, Hello''' - a feature which has gone unimplemented despite a high frequency -of invocation during users' typical daily workflow. - -(We've seen some other effort in this space with the implementation of popular -commands such as `sl`.) - -[[setup-workspace]] -=== Set Up Your Workspace - -Let's start by making a development branch to work on our changes. Per -`Documentation/SubmittingPatches`, since a brand new command is a new feature, -it's fine to base your work on `master`. However, in the future for bugfixes, -etc., you should check that document and base it on the appropriate branch. - -For the purposes of this document, we will base all our work on the `master` -branch of the upstream project. Create the `psuh` branch you will use for -development like so: - ----- -$ git checkout -b psuh origin/master ----- - -We'll make a number of commits here in order to demonstrate how to send a topic -with multiple patches up for review simultaneously. - -[[code-it-up]] -== Code It Up! - -NOTE: A reference implementation can be found at -https://github.com/nasamuffin/git/tree/psuh. - -[[add-new-command]] -=== Adding a New Command - -Lots of the subcommands are written as builtins, which means they are -implemented in C and compiled into the main `git` executable. Implementing the -very simple `psuh` command as a built-in will demonstrate the structure of the -codebase, the internal API, and the process of working together as a contributor -with the reviewers and maintainer to integrate this change into the system. - -Built-in subcommands are typically implemented in a function named "cmd_" -followed by the name of the subcommand, in a source file named after the -subcommand and contained within `builtin/`. So it makes sense to implement your -command in `builtin/psuh.c`. Create that file, and within it, write the entry -point for your command in a function matching the style and signature: - ----- -int cmd_psuh(int argc, const char **argv, const char *prefix) ----- - -We'll also need to add the declaration of psuh; open up `builtin.h`, find the -declaration for `cmd_push`, and add a new line for `psuh` immediately before it, -in order to keep the declarations sorted: - ----- -int cmd_psuh(int argc, const char **argv, const char *prefix); ----- - -Be sure to `#include "builtin.h"` in your `psuh.c`. - -Go ahead and add some throwaway printf to that function. This is a decent -starting point as we can now add build rules and register the command. - -NOTE: Your throwaway text, as well as much of the text you will be adding over -the course of this tutorial, is user-facing. That means it needs to be -localizable. Take a look at `po/README` under "Marking strings for translation". -Throughout the tutorial, we will mark strings for translation as necessary; you -should also do so when writing your user-facing commands in the future. - ----- -int cmd_psuh(int argc, const char **argv, const char *prefix) -{ - printf(_("Pony saying hello goes here.\n")); - return 0; -} ----- - -Let's try to build it. Open `Makefile`, find where `builtin/push.o` is added -to `BUILTIN_OBJS`, and add `builtin/psuh.o` in the same way next to it in -alphabetical order. Once you've done so, move to the top-level directory and -build simply with `make`. Also add the `DEVELOPER=1` variable to turn on -some additional warnings: - ----- -$ echo DEVELOPER=1 >config.mak -$ make ----- - -NOTE: When you are developing the Git project, it's preferred that you use the -`DEVELOPER` flag; if there's some reason it doesn't work for you, you can turn -it off, but it's a good idea to mention the problem to the mailing list. - -NOTE: The Git build is parallelizable. `-j#` is not included above but you can -use it as you prefer, here and elsewhere. - -Great, now your new command builds happily on its own. But nobody invokes it. -Let's change that. - -The list of commands lives in `git.c`. We can register a new command by adding -a `cmd_struct` to the `commands[]` array. `struct cmd_struct` takes a string -with the command name, a function pointer to the command implementation, and a -setup option flag. For now, let's keep mimicking `push`. Find the line where -`cmd_push` is registered, copy it, and modify it for `cmd_psuh`, placing the new -line in alphabetical order. - -The options are documented in `builtin.h` under "Adding a new built-in." Since -we hope to print some data about the user's current workspace context later, -we need a Git directory, so choose `RUN_SETUP` as your only option. - -Go ahead and build again. You should see a clean build, so let's kick the tires -and see if it works. There's a binary you can use to test with in the -`bin-wrappers` directory. - ----- -$ ./bin-wrappers/git psuh ----- - -Check it out! You've got a command! Nice work! Let's commit this. - -`git status` reveals modified `Makefile`, `builtin.h`, and `git.c` as well as -untracked `builtin/psuh.c` and `git-psuh`. First, let's take care of the binary, -which should be ignored. Open `.gitignore` in your editor, find `/git-push`, and -add an entry for your new command in alphabetical order: - ----- -... -/git-prune-packed -/git-psuh -/git-pull -/git-push -/git-quiltimport -/git-range-diff -... ----- - -Checking `git status` again should show that `git-psuh` has been removed from -the untracked list and `.gitignore` has been added to the modified list. Now we -can stage and commit: - ----- -$ git add Makefile builtin.h builtin/psuh.c git.c .gitignore -$ git commit -s ----- - -You will be presented with your editor in order to write a commit message. Start -the commit with a 50-column or less subject line, including the name of the -component you're working on, followed by a blank line (always required) and then -the body of your commit message, which should provide the bulk of the context. -Remember to be explicit and provide the "Why" of your change, especially if it -couldn't easily be understood from your diff. When editing your commit message, -don't remove the Signed-off-by line which was added by `-s` above. - ----- -psuh: add a built-in by popular demand - -Internal metrics indicate this is a command many users expect to be -present. So here's an implementation to help drive customer -satisfaction and engagement: a pony which doubtfully greets the user, -or, a Pony Saying "Um, Hello" (PSUH). - -This commit message is intentionally formatted to 72 columns per line, -starts with a single line as "commit message subject" that is written as -if to command the codebase to do something (add this, teach a command -that). The body of the message is designed to add information about the -commit that is not readily deduced from reading the associated diff, -such as answering the question "why?". - -Signed-off-by: A U Thor <author@example.com> ----- - -Go ahead and inspect your new commit with `git show`. "psuh:" indicates you -have modified mainly the `psuh` command. The subject line gives readers an idea -of what you've changed. The sign-off line (`-s`) indicates that you agree to -the Developer's Certificate of Origin 1.1 (see the -`Documentation/SubmittingPatches` +++[[dco]]+++ header). - -For the remainder of the tutorial, the subject line only will be listed for the -sake of brevity. However, fully-fleshed example commit messages are available -on the reference implementation linked at the top of this document. - -[[implementation]] -=== Implementation - -It's probably useful to do at least something besides printing out a string. -Let's start by having a look at everything we get. - -Modify your `cmd_psuh` implementation to dump the args you're passed, keeping -existing `printf()` calls in place: - ----- - int i; - - ... - - printf(Q_("Your args (there is %d):\n", - "Your args (there are %d):\n", - argc), - argc); - for (i = 0; i < argc; i++) - printf("%d: %s\n", i, argv[i]); - - printf(_("Your current working directory:\n<top-level>%s%s\n"), - prefix ? "/" : "", prefix ? prefix : ""); - ----- - -Build and try it. As you may expect, there's pretty much just whatever we give -on the command line, including the name of our command. (If `prefix` is empty -for you, try `cd Documentation/ && ../bin-wrappers/git psuh`). That's not so -helpful. So what other context can we get? - -Add a line to `#include "config.h"`. Then, add the following bits to the -function body: - ----- - const char *cfg_name; - -... - - git_config(git_default_config, NULL); - if (git_config_get_string_const("user.name", &cfg_name) > 0) - printf(_("No name is found in config\n")); - else - printf(_("Your name: %s\n"), cfg_name); ----- - -`git_config()` will grab the configuration from config files known to Git and -apply standard precedence rules. `git_config_get_string_const()` will look up -a specific key ("user.name") and give you the value. There are a number of -single-key lookup functions like this one; you can see them all (and more info -about how to use `git_config()`) in `Documentation/technical/api-config.txt`. - -You should see that the name printed matches the one you see when you run: - ----- -$ git config --get user.name ----- - -Great! Now we know how to check for values in the Git config. Let's commit this -too, so we don't lose our progress. - ----- -$ git add builtin/psuh.c -$ git commit -sm "psuh: show parameters & config opts" ----- - -NOTE: Again, the above is for sake of brevity in this tutorial. In a real change -you should not use `-m` but instead use the editor to write a meaningful -message. - -Still, it'd be nice to know what the user's working context is like. Let's see -if we can print the name of the user's current branch. We can mimic the -`git status` implementation; the printer is located in `wt-status.c` and we can -see that the branch is held in a `struct wt_status`. - -`wt_status_print()` gets invoked by `cmd_status()` in `builtin/commit.c`. -Looking at that implementation we see the status config being populated like so: - ----- -status_init_config(&s, git_status_config); ----- - -But as we drill down, we can find that `status_init_config()` wraps a call -to `git_config()`. Let's modify the code we wrote in the previous commit. - -Be sure to include the header to allow you to use `struct wt_status`: ----- -#include "wt-status.h" ----- - -Then modify your `cmd_psuh` implementation to declare your `struct wt_status`, -prepare it, and print its contents: - ----- - struct wt_status status; - -... - - wt_status_prepare(the_repository, &status); - git_config(git_default_config, &status); - -... - - printf(_("Your current branch: %s\n"), status.branch); ----- - -Run it again. Check it out - here's the (verbose) name of your current branch! - -Let's commit this as well. - ----- -$ git add builtin/psuh.c -$ git commit -sm "psuh: print the current branch" ----- - -Now let's see if we can get some info about a specific commit. - -Luckily, there are some helpers for us here. `commit.h` has a function called -`lookup_commit_reference_by_name` to which we can simply provide a hardcoded -string; `pretty.h` has an extremely handy `pp_commit_easy()` call which doesn't -require a full format object to be passed. - -Add the following includes: - ----- -#include "commit.h" -#include "pretty.h" ----- - -Then, add the following lines within your implementation of `cmd_psuh()` near -the declarations and the logic, respectively. - ----- - struct commit *c = NULL; - struct strbuf commitline = STRBUF_INIT; - -... - - c = lookup_commit_reference_by_name("origin/master"); - - if (c != NULL) { - pp_commit_easy(CMIT_FMT_ONELINE, c, &commitline); - printf(_("Current commit: %s\n"), commitline.buf); - } ----- - -The `struct strbuf` provides some safety belts to your basic `char*`, one of -which is a length member to prevent buffer overruns. It needs to be initialized -nicely with `STRBUF_INIT`. Keep it in mind when you need to pass around `char*`. - -`lookup_commit_reference_by_name` resolves the name you pass it, so you can play -with the value there and see what kind of things you can come up with. - -`pp_commit_easy` is a convenience wrapper in `pretty.h` that takes a single -format enum shorthand, rather than an entire format struct. It then -pretty-prints the commit according to that shorthand. These are similar to the -formats available with `--pretty=FOO` in many Git commands. - -Build it and run, and if you're using the same name in the example, you should -see the subject line of the most recent commit in `origin/master` that you know -about. Neat! Let's commit that as well. - ----- -$ git add builtin/psuh.c -$ git commit -sm "psuh: display the top of origin/master" ----- - -[[add-documentation]] -=== Adding Documentation - -Awesome! You've got a fantastic new command that you're ready to share with the -community. But hang on just a minute - this isn't very user-friendly. Run the -following: - ----- -$ ./bin-wrappers/git help psuh ----- - -Your new command is undocumented! Let's fix that. - -Take a look at `Documentation/git-*.txt`. These are the manpages for the -subcommands that Git knows about. You can open these up and take a look to get -acquainted with the format, but then go ahead and make a new file -`Documentation/git-psuh.txt`. Like with most of the documentation in the Git -project, help pages are written with AsciiDoc (see CodingGuidelines, "Writing -Documentation" section). Use the following template to fill out your own -manpage: - -// Surprisingly difficult to embed AsciiDoc source within AsciiDoc. -[listing] -.... -git-psuh(1) -=========== - -NAME ----- -git-psuh - Delight users' typo with a shy horse - - -SYNOPSIS --------- -[verse] -'git-psuh [<arg>...]' - -DESCRIPTION ------------ -... - -OPTIONS[[OPTIONS]] ------------------- -... - -OUTPUT ------- -... - -GIT ---- -Part of the linkgit:git[1] suite -.... - -The most important pieces of this to note are the file header, underlined by =, -the NAME section, and the SYNOPSIS, which would normally contain the grammar if -your command took arguments. Try to use well-established manpage headers so your -documentation is consistent with other Git and UNIX manpages; this makes life -easier for your user, who can skip to the section they know contains the -information they need. - -Now that you've written your manpage, you'll need to build it explicitly. We -convert your AsciiDoc to troff which is man-readable like so: - ----- -$ make all doc -$ man Documentation/git-psuh.1 ----- - -or - ----- -$ make -C Documentation/ git-psuh.1 -$ man Documentation/git-psuh.1 ----- - -NOTE: You may need to install the package `asciidoc` to get this to work. - -While this isn't as satisfying as running through `git help`, you can at least -check that your help page looks right. - -You can also check that the documentation coverage is good (that is, the project -sees that your command has been implemented as well as documented) by running -`make check-docs` from the top-level. - -Go ahead and commit your new documentation change. - -[[add-usage]] -=== Adding Usage Text - -Try and run `./bin-wrappers/git psuh -h`. Your command should crash at the end. -That's because `-h` is a special case which your command should handle by -printing usage. - -Take a look at `Documentation/technical/api-parse-options.txt`. This is a handy -tool for pulling out options you need to be able to handle, and it takes a -usage string. - -In order to use it, we'll need to prepare a NULL-terminated array of usage -strings and a `builtin_psuh_options` array. - -Add a line to `#include "parse-options.h"`. - -At global scope, add your array of usage strings: - ----- -static const char * const psuh_usage[] = { - N_("git psuh [<arg>...]"), - NULL, -}; ----- - -Then, within your `cmd_psuh()` implementation, we can declare and populate our -`option` struct. Ours is pretty boring but you can add more to it if you want to -explore `parse_options()` in more detail: - ----- - struct option options[] = { - OPT_END() - }; ----- - -Finally, before you print your args and prefix, add the call to -`parse-options()`: - ----- - argc = parse_options(argc, argv, prefix, options, psuh_usage, 0); ----- - -This call will modify your `argv` parameter. It will strip the options you -specified in `options` from `argv` and the locations pointed to from `options` -entries will be updated. Be sure to replace your `argc` with the result from -`parse_options()`, or you will be confused if you try to parse `argv` later. - -It's worth noting the special argument `--`. As you may be aware, many Unix -commands use `--` to indicate "end of named parameters" - all parameters after -the `--` are interpreted merely as positional arguments. (This can be handy if -you want to pass as a parameter something which would usually be interpreted as -a flag.) `parse_options()` will terminate parsing when it reaches `--` and give -you the rest of the options afterwards, untouched. - -Build again. Now, when you run with `-h`, you should see your usage printed and -your command terminated before anything else interesting happens. Great! - -Go ahead and commit this one, too. - -[[testing]] -== Testing - -It's important to test your code - even for a little toy command like this one. -Moreover, your patch won't be accepted into the Git tree without tests. Your -tests should: - -* Illustrate the current behavior of the feature -* Prove the current behavior matches the expected behavior -* Ensure the externally-visible behavior isn't broken in later changes - -So let's write some tests. - -Related reading: `t/README` - -[[overview-test-structure]] -=== Overview of Testing Structure - -The tests in Git live in `t/` and are named with a 4-digit decimal number using -the schema shown in the Naming Tests section of `t/README`. - -[[write-new-test]] -=== Writing Your Test - -Since this a toy command, let's go ahead and name the test with t9999. However, -as many of the family/subcmd combinations are full, best practice seems to be -to find a command close enough to the one you've added and share its naming -space. - -Create a new file `t/t9999-psuh-tutorial.sh`. Begin with the header as so (see -"Writing Tests" and "Source 'test-lib.sh'" in `t/README`): - ----- -#!/bin/sh - -test_description='git-psuh test - -This test runs git-psuh and makes sure it does not crash.' - -. ./test-lib.sh ----- - -Tests are framed inside of a `test_expect_success` in order to output TAP -formatted results. Let's make sure that `git psuh` doesn't exit poorly and does -mention the right animal somewhere: - ----- -test_expect_success 'runs correctly with no args and good output' ' - git psuh >actual && - test_i18ngrep Pony actual -' ----- - -Indicate that you've run everything you wanted by adding the following at the -bottom of your script: - ----- -test_done ----- - -Make sure you mark your test script executable: - ----- -$ chmod +x t/t9999-psuh-tutorial.sh ----- - -You can get an idea of whether you created your new test script successfully -by running `make -C t test-lint`, which will check for things like test number -uniqueness, executable bit, and so on. - -[[local-test]] -=== Running Locally - -Let's try and run locally: - ----- -$ make -$ cd t/ && prove t9999-psuh-tutorial.sh ----- - -You can run the full test suite and ensure `git-psuh` didn't break anything: - ----- -$ cd t/ -$ prove -j$(nproc) --shuffle t[0-9]*.sh ----- - -NOTE: You can also do this with `make test` or use any testing harness which can -speak TAP. `prove` can run concurrently. `shuffle` randomizes the order the -tests are run in, which makes them resilient against unwanted inter-test -dependencies. `prove` also makes the output nicer. - -Go ahead and commit this change, as well. - -[[ready-to-share]] -== Getting Ready to Share - -You may have noticed already that the Git project performs its code reviews via -emailed patches, which are then applied by the maintainer when they are ready -and approved by the community. The Git project does not accept patches from -pull requests, and the patches emailed for review need to be formatted a -specific way. At this point the tutorial diverges, in order to demonstrate two -different methods of formatting your patchset and getting it reviewed. - -The first method to be covered is GitGitGadget, which is useful for those -already familiar with GitHub's common pull request workflow. This method -requires a GitHub account. - -The second method to be covered is `git send-email`, which can give slightly -more fine-grained control over the emails to be sent. This method requires some -setup which can change depending on your system and will not be covered in this -tutorial. - -Regardless of which method you choose, your engagement with reviewers will be -the same; the review process will be covered after the sections on GitGitGadget -and `git send-email`. - -[[howto-ggg]] -== Sending Patches via GitGitGadget - -One option for sending patches is to follow a typical pull request workflow and -send your patches out via GitGitGadget. GitGitGadget is a tool created by -Johannes Schindelin to make life as a Git contributor easier for those used to -the GitHub PR workflow. It allows contributors to open pull requests against its -mirror of the Git project, and does some magic to turn the PR into a set of -emails and send them out for you. It also runs the Git continuous integration -suite for you. It's documented at http://gitgitgadget.github.io. - -[[create-fork]] -=== Forking `git/git` on GitHub - -Before you can send your patch off to be reviewed using GitGitGadget, you will -need to fork the Git project and upload your changes. First thing - make sure -you have a GitHub account. - -Head to the https://github.com/git/git[GitHub mirror] and look for the Fork -button. Place your fork wherever you deem appropriate and create it. - -[[upload-to-fork]] -=== Uploading to Your Own Fork - -To upload your branch to your own fork, you'll need to add the new fork as a -remote. You can use `git remote -v` to show the remotes you have added already. -From your new fork's page on GitHub, you can press "Clone or download" to get -the URL; then you need to run the following to add, replacing your own URL and -remote name for the examples provided: - ----- -$ git remote add remotename git@github.com:remotename/git.git ----- - -or to use the HTTPS URL: - ----- -$ git remote add remotename https://github.com/remotename/git/.git ----- - -Run `git remote -v` again and you should see the new remote showing up. -`git fetch remotename` (with the real name of your remote replaced) in order to -get ready to push. - -Next, double-check that you've been doing all your development in a new branch -by running `git branch`. If you didn't, now is a good time to move your new -commits to their own branch. - -As mentioned briefly at the beginning of this document, we are basing our work -on `master`, so go ahead and update as shown below, or using your preferred -workflow. - ----- -$ git checkout master -$ git pull -r -$ git rebase master psuh ----- - -Finally, you're ready to push your new topic branch! (Due to our branch and -command name choices, be careful when you type the command below.) - ----- -$ git push remotename psuh ----- - -Now you should be able to go and check out your newly created branch on GitHub. - -[[send-pr-ggg]] -=== Sending a PR to GitGitGadget - -In order to have your code tested and formatted for review, you need to start by -opening a Pull Request against `gitgitgadget/git`. Head to -https://github.com/gitgitgadget/git and open a PR either with the "New pull -request" button or the convenient "Compare & pull request" button that may -appear with the name of your newly pushed branch. - -Review the PR's title and description, as it's used by GitGitGadget as the cover -letter for your change. When you're happy, submit your pull request. - -[[run-ci-ggg]] -=== Running CI and Getting Ready to Send - -If it's your first time using GitGitGadget (which is likely, as you're using -this tutorial) then someone will need to give you permission to use the tool. -As mentioned in the GitGitGadget documentation, you just need someone who -already uses it to comment on your PR with `/allow <username>`. GitGitGadget -will automatically run your PRs through the CI even without the permission given -but you will not be able to `/submit` your changes until someone allows you to -use the tool. - -If the CI fails, you can update your changes with `git rebase -i` and push your -branch again: - ----- -$ git push -f remotename psuh ----- - -In fact, you should continue to make changes this way up until the point when -your patch is accepted into `next`. - -//// -TODO https://github.com/gitgitgadget/gitgitgadget/issues/83 -It'd be nice to be able to verify that the patch looks good before sending it -to everyone on Git mailing list. -[[check-work-ggg]] -=== Check Your Work -//// - -[[send-mail-ggg]] -=== Sending Your Patches - -Now that your CI is passing and someone has granted you permission to use -GitGitGadget with the `/allow` command, sending out for review is as simple as -commenting on your PR with `/submit`. - -[[responding-ggg]] -=== Updating With Comments - -Skip ahead to <<reviewing,Responding to Reviews>> for information on how to -reply to review comments you will receive on the mailing list. - -Once you have your branch again in the shape you want following all review -comments, you can submit again: - ----- -$ git push -f remotename psuh ----- - -Next, go look at your pull request against GitGitGadget; you should see the CI -has been kicked off again. Now while the CI is running is a good time for you -to modify your description at the top of the pull request thread; it will be -used again as the cover letter. You should use this space to describe what -has changed since your previous version, so that your reviewers have some idea -of what they're looking at. When the CI is done running, you can comment once -more with `/submit` - GitGitGadget will automatically add a v2 mark to your -changes. - -[[howto-git-send-email]] -== Sending Patches with `git send-email` - -If you don't want to use GitGitGadget, you can also use Git itself to mail your -patches. Some benefits of using Git this way include finer grained control of -subject line (for example, being able to use the tag [RFC PATCH] in the subject) -and being able to send a ``dry run'' mail to yourself to ensure it all looks -good before going out to the list. - -[[setup-git-send-email]] -=== Prerequisite: Setting Up `git send-email` - -Configuration for `send-email` can vary based on your operating system and email -provider, and so will not be covered in this tutorial, beyond stating that in -many distributions of Linux, `git-send-email` is not packaged alongside the -typical `git` install. You may need to install this additional package; there -are a number of resources online to help you do so. You will also need to -determine the right way to configure it to use your SMTP server; again, as this -configuration can change significantly based on your system and email setup, it -is out of scope for the context of this tutorial. - -[[format-patch]] -=== Preparing Initial Patchset - -Sending emails with Git is a two-part process; before you can prepare the emails -themselves, you'll need to prepare the patches. Luckily, this is pretty simple: - ----- -$ git format-patch --cover-letter -o psuh/ master..psuh ----- - -The `--cover-letter` parameter tells `format-patch` to create a cover letter -template for you. You will need to fill in the template before you're ready -to send - but for now, the template will be next to your other patches. - -The `-o psuh/` parameter tells `format-patch` to place the patch files into a -directory. This is useful because `git send-email` can take a directory and -send out all the patches from there. - -`master..psuh` tells `format-patch` to generate patches for the difference -between `master` and `psuh`. It will make one patch file per commit. After you -run, you can go have a look at each of the patches with your favorite text -editor and make sure everything looks alright; however, it's not recommended to -make code fixups via the patch file. It's a better idea to make the change the -normal way using `git rebase -i` or by adding a new commit than by modifying a -patch. - -NOTE: Optionally, you can also use the `--rfc` flag to prefix your patch subject -with ``[RFC PATCH]'' instead of ``[PATCH]''. RFC stands for ``request for -comments'' and indicates that while your code isn't quite ready for submission, -you'd like to begin the code review process. This can also be used when your -patch is a proposal, but you aren't sure whether the community wants to solve -the problem with that approach or not - to conduct a sort of design review. You -may also see on the list patches marked ``WIP'' - this means they are incomplete -but want reviewers to look at what they have so far. You can add this flag with -`--subject-prefix=WIP`. - -Check and make sure that your patches and cover letter template exist in the -directory you specified - you're nearly ready to send out your review! - -[[cover-letter]] -=== Preparing Email - -In addition to an email per patch, the Git community also expects your patches -to come with a cover letter, typically with a subject line [PATCH 0/x] (where -x is the number of patches you're sending). Since you invoked `format-patch` -with `--cover-letter`, you've already got a template ready. Open it up in your -favorite editor. - -You should see a number of headers present already. Check that your `From:` -header is correct. Then modify your `Subject:` to something which succinctly -covers the purpose of your entire topic branch, for example: - ----- -Subject: [PATCH 0/7] adding the 'psuh' command ----- - -Make sure you retain the ``[PATCH 0/X]'' part; that's what indicates to the Git -community that this email is the beginning of a review, and many reviewers -filter their email for this type of flag. - -You'll need to add some extra parameters when you invoke `git send-email` to add -the cover letter. - -Next you'll have to fill out the body of your cover letter. This is an important -component of change submission as it explains to the community from a high level -what you're trying to do, and why, in a way that's more apparent than just -looking at your diff. Be sure to explain anything your diff doesn't make clear -on its own. - -Here's an example body for `psuh`: - ----- -Our internal metrics indicate widespread interest in the command -git-psuh - that is, many users are trying to use it, but finding it is -unavailable, using some unknown workaround instead. - -The following handful of patches add the psuh command and implement some -handy features on top of it. - -This patchset is part of the MyFirstContribution tutorial and should not -be merged. ----- - -The template created by `git format-patch --cover-letter` includes a diffstat. -This gives reviewers a summary of what they're in for when reviewing your topic. -The one generated for `psuh` from the sample implementation looks like this: - ----- - Documentation/git-psuh.txt | 40 +++++++++++++++++++++ - Makefile | 1 + - builtin.h | 1 + - builtin/psuh.c | 73 ++++++++++++++++++++++++++++++++++++++ - git.c | 1 + - t/t9999-psuh-tutorial.sh | 12 +++++++ - 6 files changed, 128 insertions(+) - create mode 100644 Documentation/git-psuh.txt - create mode 100644 builtin/psuh.c - create mode 100755 t/t9999-psuh-tutorial.sh ----- - -Finally, the letter will include the version of Git used to generate the -patches. You can leave that string alone. - -[[sending-git-send-email]] -=== Sending Email - -At this point you should have a directory `psuh/` which is filled with your -patches and a cover letter. Time to mail it out! You can send it like this: - ----- -$ git send-email --to=target@example.com psuh/*.patch ----- - -NOTE: Check `git help send-email` for some other options which you may find -valuable, such as changing the Reply-to address or adding more CC and BCC lines. - -NOTE: When you are sending a real patch, it will go to git@vger.kernel.org - but -please don't send your patchset from the tutorial to the real mailing list! For -now, you can send it to yourself, to make sure you understand how it will look. - -After you run the command above, you will be presented with an interactive -prompt for each patch that's about to go out. This gives you one last chance to -edit or quit sending something (but again, don't edit code this way). Once you -press `y` or `a` at these prompts your emails will be sent! Congratulations! - -Awesome, now the community will drop everything and review your changes. (Just -kidding - be patient!) - -[[v2-git-send-email]] -=== Sending v2 - -Skip ahead to <<reviewing,Responding to Reviews>> for information on how to -handle comments from reviewers. Continue this section when your topic branch is -shaped the way you want it to look for your patchset v2. - -When you're ready with the next iteration of your patch, the process is fairly -similar. - -First, generate your v2 patches again: - ----- -$ git format-patch -v2 --cover-letter -o psuh/ master..psuh ----- - -This will add your v2 patches, all named like `v2-000n-my-commit-subject.patch`, -to the `psuh/` directory. You may notice that they are sitting alongside the v1 -patches; that's fine, but be careful when you are ready to send them. - -Edit your cover letter again. Now is a good time to mention what's different -between your last version and now, if it's something significant. You do not -need the exact same body in your second cover letter; focus on explaining to -reviewers the changes you've made that may not be as visible. - -You will also need to go and find the Message-Id of your previous cover letter. -You can either note it when you send the first series, from the output of `git -send-email`, or you can look it up on the -https://public-inbox.org/git[mailing list]. Find your cover letter in the -archives, click on it, then click "permalink" or "raw" to reveal the Message-Id -header. It should match: - ----- -Message-Id: <foo.12345.author@example.com> ----- - -Your Message-Id is `<foo.12345.author@example.com>`. This example will be used -below as well; make sure to replace it with the correct Message-Id for your -**previous cover letter** - that is, if you're sending v2, use the Message-Id -from v1; if you're sending v3, use the Message-Id from v2. - -While you're looking at the email, you should also note who is CC'd, as it's -common practice in the mailing list to keep all CCs on a thread. You can add -these CC lines directly to your cover letter with a line like so in the header -(before the Subject line): - ----- -CC: author@example.com, Othe R <other@example.com> ----- - -Now send the emails again, paying close attention to which messages you pass in -to the command: - ----- -$ git send-email --to=target@example.com - --in-reply-to="<foo.12345.author@example.com>" - psuh/v2* ----- - -[[single-patch]] -=== Bonus Chapter: One-Patch Changes - -In some cases, your very small change may consist of only one patch. When that -happens, you only need to send one email. Your commit message should already be -meaningful and explain at a high level the purpose (what is happening and why) -of your patch, but if you need to supply even more context, you can do so below -the `---` in your patch. Take the example below, which was generated with `git -format-patch` on a single commit, and then edited to add the content between -the `---` and the diffstat. - ----- -From 1345bbb3f7ac74abde040c12e737204689a72723 Mon Sep 17 00:00:00 2001 -From: A U Thor <author@example.com> -Date: Thu, 18 Apr 2019 15:11:02 -0700 -Subject: [PATCH] README: change the grammar - -I think it looks better this way. This part of the commit message will -end up in the commit-log. - -Signed-off-by: A U Thor <author@example.com> ---- -Let's have a wild discussion about grammar on the mailing list. This -part of my email will never end up in the commit log. Here is where I -can add additional context to the mailing list about my intent, outside -of the context of the commit log. This section was added after `git -format-patch` was run, by editing the patch file in a text editor. - - README.md | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/README.md b/README.md -index 88f126184c..38da593a60 100644 ---- a/README.md -+++ b/README.md -@@ -3,7 +3,7 @@ - Git - fast, scalable, distributed revision control system - ========================================================= - --Git is a fast, scalable, distributed revision control system with an -+Git is a fast, scalable, and distributed revision control system with an - unusually rich command set that provides both high-level operations - and full access to internals. - --- -2.21.0.392.gf8f6787159e-goog ----- - -[[now-what]] -== My Patch Got Emailed - Now What? - -[[reviewing]] -=== Responding to Reviews - -After a few days, you will hopefully receive a reply to your patchset with some -comments. Woohoo! Now you can get back to work. - -It's good manners to reply to each comment, notifying the reviewer that you have -made the change requested, feel the original is better, or that the comment -inspired you to do something a new way which is superior to both the original -and the suggested change. This way reviewers don't need to inspect your v2 to -figure out whether you implemented their comment or not. - -If you are going to push back on a comment, be polite and explain why you feel -your original is better; be prepared that the reviewer may still disagree with -you, and the rest of the community may weigh in on one side or the other. As -with all code reviews, it's important to keep an open mind to doing something a -different way than you originally planned; other reviewers have a different -perspective on the project than you do, and may be thinking of a valid side -effect which had not occurred to you. It is always okay to ask for clarification -if you aren't sure why a change was suggested, or what the reviewer is asking -you to do. - -Make sure your email client has a plaintext email mode and it is turned on; the -Git list rejects HTML email. Please also follow the mailing list etiquette -outlined in the -https://kernel.googlesource.com/pub/scm/git/git/+/todo/MaintNotes[Maintainer's -Note], which are similar to etiquette rules in most open source communities -surrounding bottom-posting and inline replies. - -When you're making changes to your code, it is cleanest - that is, the resulting -commits are easiest to look at - if you use `git rebase -i` (interactive -rebase). Take a look at this -https://www.oreilly.com/library/view/git-pocket-guide/9781449327507/ch10.html[overview] -from O'Reilly. The general idea is to modify each commit which requires changes; -this way, instead of having a patch A with a mistake, a patch B which was fine -and required no upstream reviews in v1, and a patch C which fixes patch A for -v2, you can just ship a v2 with a correct patch A and correct patch B. This is -changing history, but since it's local history which you haven't shared with -anyone, that is okay for now! (Later, it may not make sense to do this; take a -look at the section below this one for some context.) - -[[after-approval]] -=== After Review Approval - -The Git project has four integration branches: `pu`, `next`, `master`, and -`maint`. Your change will be placed into `pu` fairly early on by the maintainer -while it is still in the review process; from there, when it is ready for wider -testing, it will be merged into `next`. Plenty of early testers use `next` and -may report issues. Eventually, changes in `next` will make it to `master`, -which is typically considered stable. Finally, when a new release is cut, -`maint` is used to base bugfixes onto. As mentioned at the beginning of this -document, you can read `Documents/SubmittingPatches` for some more info about -the use of the various integration branches. - -Back to now: your code has been lauded by the upstream reviewers. It is perfect. -It is ready to be accepted. You don't need to do anything else; the maintainer -will merge your topic branch to `next` and life is good. - -However, if you discover it isn't so perfect after this point, you may need to -take some special steps depending on where you are in the process. - -If the maintainer has announced in the "What's cooking in git.git" email that -your topic is marked for `next` - that is, that they plan to merge it to `next` -but have not yet done so - you should send an email asking the maintainer to -wait a little longer: "I've sent v4 of my series and you marked it for `next`, -but I need to change this and that - please wait for v5 before you merge it." - -If the topic has already been merged to `next`, rather than modifying your -patches with `git rebase -i`, you should make further changes incrementally - -that is, with another commit, based on top of the maintainer's topic branch as -detailed in https://github.com/gitster/git. Your work is still in the same topic -but is now incremental, rather than a wholesale rewrite of the topic branch. - -The topic branches in the maintainer's GitHub are mirrored in GitGitGadget, so -if you're sending your reviews out that way, you should be sure to open your PR -against the appropriate GitGitGadget/Git branch. - -If you're using `git send-email`, you can use it the same way as before, but you -should generate your diffs from `<topic>..<mybranch>` and base your work on -`<topic>` instead of `master`. diff --git a/third_party/git/Documentation/RelNotes/1.5.0.1.txt b/third_party/git/Documentation/RelNotes/1.5.0.1.txt deleted file mode 100644 index fea3f9935b..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.0.1.txt +++ /dev/null @@ -1,42 +0,0 @@ -GIT v1.5.0.1 Release Notes -========================== - -Fixes since v1.5.0 ------------------- - -* Documentation updates - - - Clarifications and corrections to 1.5.0 release notes. - - - The main documentation did not link to git-remote documentation. - - - Clarified introductory text of git-rebase documentation. - - - Converted remaining mentions of update-index on Porcelain - documents to git-add/git-rm. - - - Some i18n.* configuration variables were incorrectly - described as core.*; fixed. - -* Bugfixes - - - git-add and git-update-index on a filesystem on which - executable bits are unreliable incorrectly reused st_mode - bits even when the path changed between symlink and regular - file. - - - git-daemon marks the listening sockets with FD_CLOEXEC so - that it won't be leaked into the children. - - - segfault from git-blame when the mandatory pathname - parameter was missing was fixed; usage() message is given - instead. - - - git-rev-list did not read $GIT_DIR/config file, which means - that did not honor i18n.logoutputencoding correctly. - -* Tweaks - - - sliding mmap() inefficiently mmaped the same region of a - packfile with an access pattern that used objects in the - reverse order. This has been made more efficient. diff --git a/third_party/git/Documentation/RelNotes/1.5.0.2.txt b/third_party/git/Documentation/RelNotes/1.5.0.2.txt deleted file mode 100644 index b061e50ff0..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.0.2.txt +++ /dev/null @@ -1,65 +0,0 @@ -GIT v1.5.0.2 Release Notes -========================== - -Fixes since v1.5.0.1 --------------------- - -* Bugfixes - - - Automated merge conflict handling when changes to symbolic - links conflicted were completely broken. The merge-resolve - strategy created a regular file with conflict markers in it - in place of the symbolic link. The default strategy, - merge-recursive was even more broken. It removed the path - that was pointed at by the symbolic link. Both of these - problems have been fixed. - - - 'git diff maint master next' did not correctly give combined - diff across three trees. - - - 'git fast-import' portability fix for Solaris. - - - 'git show-ref --verify' without arguments did not error out - but segfaulted. - - - 'git diff :tracked-file `pwd`/an-untracked-file' gave an extra - slashes after a/ and b/. - - - 'git format-patch' produced too long filenames if the commit - message had too long line at the beginning. - - - Running 'make all' and then without changing anything - running 'make install' still rebuilt some files. This - was inconvenient when building as yourself and then - installing as root (especially problematic when the source - directory is on NFS and root is mapped to nobody). - - - 'git-rerere' failed to deal with two unconflicted paths that - sorted next to each other. - - - 'git-rerere' attempted to open(2) a symlink and failed if - there was a conflict. Since a conflicting change to a - symlink would not benefit from rerere anyway, the command - now ignores conflicting changes to symlinks. - - - 'git-repack' did not like to pass more than 64 arguments - internally to underlying 'rev-list' logic, which made it - impossible to repack after accumulating many (small) packs - in the repository. - - - 'git-diff' to review the combined diff during a conflicted - merge were not reading the working tree version correctly - when changes to a symbolic link conflicted. It should have - read the data using readlink(2) but read from the regular - file the symbolic link pointed at. - - - 'git-remote' did not like period in a remote's name. - -* Documentation updates - - - added and clarified core.bare, core.legacyheaders configurations. - - - updated "git-clone --depth" documentation. - - -* Assorted git-gui fixes. diff --git a/third_party/git/Documentation/RelNotes/1.5.0.3.txt b/third_party/git/Documentation/RelNotes/1.5.0.3.txt deleted file mode 100644 index cd500f96bf..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.0.3.txt +++ /dev/null @@ -1,58 +0,0 @@ -GIT v1.5.0.3 Release Notes -========================== - -Fixes since v1.5.0.2 --------------------- - -* Bugfixes - - - 'git.el' honors the commit coding system from the configuration. - - - 'blameview' in contrib/ correctly digs deeper when a line is - clicked. - - - 'http-push' correctly makes sure the remote side has leading - path. Earlier it started in the middle of the path, and - incorrectly. - - - 'git-merge' did not exit with non-zero status when the - working tree was dirty and cannot fast forward. It does - now. - - - 'cvsexportcommit' does not lose yet-to-be-used message file. - - - int-vs-size_t typefix when running combined diff on files - over 2GB long. - - - 'git apply --whitespace=strip' should not touch unmodified - lines. - - - 'git-mailinfo' choke when a logical header line was too long. - - - 'git show A..B' did not error out. Negative ref ("not A" in - this example) does not make sense for the purpose of the - command, so now it errors out. - - - 'git fmt-merge-msg --file' without file parameter did not - correctly error out. - - - 'git archimport' barfed upon encountering a commit without - summary. - - - 'git index-pack' did not protect itself from getting a short - read out of pread(2). - - - 'git http-push' had a few buffer overruns. - - - Build dependency fixes to rebuild fetch.o when other headers - change. - -* Documentation updates - - - user-manual updates. - - - Options to 'git remote add' were described insufficiently. - - - Configuration format.suffix was not documented. - - - Other formatting and spelling fixes. diff --git a/third_party/git/Documentation/RelNotes/1.5.0.4.txt b/third_party/git/Documentation/RelNotes/1.5.0.4.txt deleted file mode 100644 index feefa5dfd4..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.0.4.txt +++ /dev/null @@ -1,22 +0,0 @@ -GIT v1.5.0.4 Release Notes -========================== - -Fixes since v1.5.0.3 --------------------- - -* Bugfixes - - - git.el does not add duplicate sign-off lines. - - - git-commit shows the full stat of the resulting commit, not - just about the files in the current directory, when run from - a subdirectory. - - - "git-checkout -m '@{8 hours ago}'" had a funny failure from - eval; fixed. - - - git-gui updates. - -* Documentation updates - -* User manual updates diff --git a/third_party/git/Documentation/RelNotes/1.5.0.5.txt b/third_party/git/Documentation/RelNotes/1.5.0.5.txt deleted file mode 100644 index eeec3d73d0..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.0.5.txt +++ /dev/null @@ -1,26 +0,0 @@ -GIT v1.5.0.5 Release Notes -========================== - -Fixes since v1.5.0.3 --------------------- - -* Bugfixes - - - git-merge (hence git-pull) did not refuse fast-forwarding - when the working tree had local changes that would have - conflicted with it. - - - git.el does not add duplicate sign-off lines. - - - git-commit shows the full stat of the resulting commit, not - just about the files in the current directory, when run from - a subdirectory. - - - "git-checkout -m '@{8 hours ago}'" had a funny failure from - eval; fixed. - - - git-gui updates. - -* Documentation updates - -* User manual updates diff --git a/third_party/git/Documentation/RelNotes/1.5.0.6.txt b/third_party/git/Documentation/RelNotes/1.5.0.6.txt deleted file mode 100644 index c02015ad5f..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.0.6.txt +++ /dev/null @@ -1,21 +0,0 @@ -GIT v1.5.0.6 Release Notes -========================== - -Fixes since v1.5.0.5 --------------------- - -* Bugfixes - - - a handful small fixes to gitweb. - - - build procedure for user-manual is fixed not to require locally - installed stylesheets. - - - "git commit $paths" on paths whose earlier contents were - already updated in the index were failing out. - -* Documentation - - - user-manual has better cross references. - - - gitweb installation/deployment procedure is now documented. diff --git a/third_party/git/Documentation/RelNotes/1.5.0.7.txt b/third_party/git/Documentation/RelNotes/1.5.0.7.txt deleted file mode 100644 index 670ad32b85..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.0.7.txt +++ /dev/null @@ -1,18 +0,0 @@ -GIT v1.5.0.7 Release Notes -========================== - -Fixes since v1.5.0.6 --------------------- - -* Bugfixes - - - git-upload-pack failed to close unused pipe ends, resulting - in many zombies to hang around. - - - git-rerere was recording the contents of earlier hunks - duplicated in later hunks. This prevented resolving the same - conflict when performing the same merge the other way around. - -* Documentation - - - a few documentation fixes from Debian package maintainer. diff --git a/third_party/git/Documentation/RelNotes/1.5.0.txt b/third_party/git/Documentation/RelNotes/1.5.0.txt deleted file mode 100644 index daf4bdb0d7..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.0.txt +++ /dev/null @@ -1,469 +0,0 @@ -GIT v1.5.0 Release Notes -======================== - -Old news --------- - -This section is for people who are upgrading from ancient -versions of git. Although all of the changes in this section -happened before the current v1.4.4 release, they are summarized -here in the v1.5.0 release notes for people who skipped earlier -versions. - -As of git v1.5.0 there are some optional features that changes -the repository to allow data to be stored and transferred more -efficiently. These features are not enabled by default, as they -will make the repository unusable with older versions of git. -Specifically, the available options are: - - - There is a configuration variable core.legacyheaders that - changes the format of loose objects so that they are more - efficient to pack and to send out of the repository over git - native protocol, since v1.4.2. However, loose objects - written in the new format cannot be read by git older than - that version; people fetching from your repository using - older clients over dumb transports (e.g. http) using older - versions of git will also be affected. - - To let git use the new loose object format, you have to - set core.legacyheaders to false. - - - Since v1.4.3, configuration repack.usedeltabaseoffset allows - packfile to be created in more space efficient format, which - cannot be read by git older than that version. - - To let git use the new format for packfiles, you have to - set repack.usedeltabaseoffset to true. - -The above two new features are not enabled by default and you -have to explicitly ask for them, because they make repositories -unreadable by older versions of git, and in v1.5.0 we still do -not enable them by default for the same reason. We will change -this default probably 1 year after 1.4.2's release, when it is -reasonable to expect everybody to have new enough version of -git. - - - 'git pack-refs' appeared in v1.4.4; this command allows tags - to be accessed much more efficiently than the traditional - 'one-file-per-tag' format. Older git-native clients can - still fetch from a repository that packed and pruned refs - (the server side needs to run the up-to-date version of git), - but older dumb transports cannot. Packing of refs is done by - an explicit user action, either by use of "git pack-refs - --prune" command or by use of "git gc" command. - - - 'git -p' to paginate anything -- many commands do pagination - by default on a tty. Introduced between v1.4.1 and v1.4.2; - this may surprise old timers. - - - 'git archive' superseded 'git tar-tree' in v1.4.3; - - - 'git cvsserver' was new invention in v1.3.0; - - - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were - seriously enhanced during v1.4.0 timeperiod. - - - 'gitweb' became part of git.git during v1.4.0 timeperiod and - seriously modified since then. - - - reflog is an v1.4.0 invention. This allows you to name a - revision that a branch used to be at (e.g. "git diff - master@{yesterday} master" allows you to see changes since - yesterday's tip of the branch). - - -Updates in v1.5.0 since v1.4.4 series -------------------------------------- - -* Index manipulation - - - git-add is to add contents to the index (aka "staging area" - for the next commit), whether the file the contents happen to - be is an existing one or a newly created one. - - - git-add without any argument does not add everything - anymore. Use 'git-add .' instead. Also you can add - otherwise ignored files with an -f option. - - - git-add tries to be more friendly to users by offering an - interactive mode ("git-add -i"). - - - git-commit <path> used to refuse to commit if <path> was - different between HEAD and the index (i.e. update-index was - used on it earlier). This check was removed. - - - git-rm is much saner and safer. It is used to remove paths - from both the index file and the working tree, and makes sure - you are not losing any local modification before doing so. - - - git-reset <tree> <paths>... can be used to revert index - entries for selected paths. - - - git-update-index is much less visible. Many suggestions to - use the command in git output and documentation have now been - replaced by simpler commands such as "git add" or "git rm". - - -* Repository layout and objects transfer - - - The data for origin repository is stored in the configuration - file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly - created clones. The latter is still supported and there is - no need to convert your existing repository if you are - already comfortable with your workflow with the layout. - - - git-clone always uses what is known as "separate remote" - layout for a newly created repository with a working tree. - - A repository with the separate remote layout starts with only - one default branch, 'master', to be used for your own - development. Unlike the traditional layout that copied all - the upstream branches into your branch namespace (while - renaming their 'master' to your 'origin'), the new layout - puts upstream branches into local "remote-tracking branches" - with their own namespace. These can be referenced with names - such as "origin/$upstream_branch_name" and are stored in - .git/refs/remotes rather than .git/refs/heads where normal - branches are stored. - - This layout keeps your own branch namespace less cluttered, - avoids name collision with your upstream, makes it possible - to automatically track new branches created at the remote - after you clone from it, and makes it easier to interact with - more than one remote repository (you can use "git remote" to - add other repositories to track). There might be some - surprises: - - * 'git branch' does not show the remote tracking branches. - It only lists your own branches. Use '-r' option to view - the tracking branches. - - * If you are forking off of a branch obtained from the - upstream, you would have done something like 'git branch - my-next next', because traditional layout dropped the - tracking branch 'next' into your own branch namespace. - With the separate remote layout, you say 'git branch next - origin/next', which allows you to use the matching name - 'next' for your own branch. It also allows you to track a - remote other than 'origin' (i.e. where you initially cloned - from) and fork off of a branch from there the same way - (e.g. "git branch mingw j6t/master"). - - Repositories initialized with the traditional layout continue - to work. - - - New branches that appear on the origin side after a clone is - made are also tracked automatically. This is done with an - wildcard refspec "refs/heads/*:refs/remotes/origin/*", which - older git does not understand, so if you clone with 1.5.0, - you would need to downgrade remote.*.fetch in the - configuration file to specify each branch you are interested - in individually if you plan to fetch into the repository with - older versions of git (but why would you?). - - - Similarly, wildcard refspec "refs/heads/*:refs/remotes/me/*" - can be given to "git-push" command to update the tracking - branches that is used to track the repository you are pushing - from on the remote side. - - - git-branch and git-show-branch know remote tracking branches - (use the command line switch "-r" to list only tracked branches). - - - git-push can now be used to delete a remote branch or a tag. - This requires the updated git on the remote side (use "git - push <remote> :refs/heads/<branch>" to delete "branch"). - - - git-push more aggressively keeps the transferred objects - packed. Earlier we recommended to monitor amount of loose - objects and repack regularly, but you should repack when you - accumulated too many small packs this way as well. Updated - git-count-objects helps you with this. - - - git-fetch also more aggressively keeps the transferred objects - packed. This behavior of git-push and git-fetch can be - tweaked with a single configuration transfer.unpacklimit (but - usually there should not be any need for a user to tweak it). - - - A new command, git-remote, can help you manage your remote - tracking branch definitions. - - - You may need to specify explicit paths for upload-pack and/or - receive-pack due to your ssh daemon configuration on the - other end. This can now be done via remote.*.uploadpack and - remote.*.receivepack configuration. - - -* Bare repositories - - - Certain commands change their behavior in a bare repository - (i.e. a repository without associated working tree). We use - a fairly conservative heuristic (if $GIT_DIR is ".git", or - ends with "/.git", the repository is not bare) to decide if a - repository is bare, but "core.bare" configuration variable - can be used to override the heuristic when it misidentifies - your repository. - - - git-fetch used to complain updating the current branch but - this is now allowed for a bare repository. So is the use of - 'git-branch -f' to update the current branch. - - - Porcelain-ish commands that require a working tree refuses to - work in a bare repository. - - -* Reflog - - - Reflog records the history from the view point of the local - repository. In other words, regardless of the real history, - the reflog shows the history as seen by one particular - repository (this enables you to ask "what was the current - revision in _this_ repository, yesterday at 1pm?"). This - facility is enabled by default for repositories with working - trees, and can be accessed with the "branch@{time}" and - "branch@{Nth}" notation. - - - "git show-branch" learned showing the reflog data with the - new -g option. "git log" has -g option to view reflog - entries in a more verbose manner. - - - git-branch knows how to rename branches and moves existing - reflog data from the old branch to the new one. - - - In addition to the reflog support in v1.4.4 series, HEAD - reference maintains its own log. "HEAD@{5.minutes.ago}" - means the commit you were at 5 minutes ago, which takes - branch switching into account. If you want to know where the - tip of your current branch was at 5 minutes ago, you need to - explicitly say its name (e.g. "master@{5.minutes.ago}") or - omit the refname altogether i.e. "@{5.minutes.ago}". - - - The commits referred to by reflog entries are now protected - against pruning. The new command "git reflog expire" can be - used to truncate older reflog entries and entries that refer - to commits that have been pruned away previously with older - versions of git. - - Existing repositories that have been using reflog may get - complaints from fsck-objects and may not be able to run - git-repack, if you had run git-prune from older git; please - run "git reflog expire --stale-fix --all" first to remove - reflog entries that refer to commits that are no longer in - the repository when that happens. - - -* Crufts removal - - - We used to say "old commits are retrievable using reflog and - 'master@{yesterday}' syntax as long as you haven't run - git-prune". We no longer have to say the latter half of the - above sentence, as git-prune does not remove things reachable - from reflog entries. - - - There is a toplevel garbage collector script, 'git-gc', that - runs periodic cleanup functions, including 'git-repack -a -d', - 'git-reflog expire', 'git-pack-refs --prune', and 'git-rerere - gc'. - - - The output from fsck ("fsck-objects" is called just "fsck" - now, but the old name continues to work) was needlessly - alarming in that it warned missing objects that are reachable - only from dangling objects. This has been corrected and the - output is much more useful. - - -* Detached HEAD - - - You can use 'git-checkout' to check out an arbitrary revision - or a tag as well, instead of named branches. This will - dissociate your HEAD from the branch you are currently on. - - A typical use of this feature is to "look around". E.g. - - $ git checkout v2.6.16 - ... compile, test, etc. - $ git checkout v2.6.17 - ... compile, test, etc. - - - After detaching your HEAD, you can go back to an existing - branch with usual "git checkout $branch". Also you can - start a new branch using "git checkout -b $newbranch" to - start a new branch at that commit. - - - You can even pull from other repositories, make merges and - commits while your HEAD is detached. Also you can use "git - reset" to jump to arbitrary commit, while still keeping your - HEAD detached. - - Remember that a detached state is volatile, i.e. it will be forgotten - as soon as you move away from it with the checkout or reset command, - unless a branch is created from it as mentioned above. It is also - possible to rescue a lost detached state from the HEAD reflog. - - -* Packed refs - - - Repositories with hundreds of tags have been paying large - overhead, both in storage and in runtime, due to the - traditional one-ref-per-file format. A new command, - git-pack-refs, can be used to "pack" them in more efficient - representation (you can let git-gc do this for you). - - - Clones and fetches over dumb transports are now aware of - packed refs and can download from repositories that use - them. - - -* Configuration - - - configuration related to color setting are consolidated under - color.* namespace (older diff.color.*, status.color.* are - still supported). - - - 'git-repo-config' command is accessible as 'git-config' now. - - -* Updated features - - - git-describe uses better criteria to pick a base ref. It - used to pick the one with the newest timestamp, but now it - picks the one that is topologically the closest (that is, - among ancestors of commit C, the ref T that has the shortest - output from "git-rev-list T..C" is chosen). - - - git-describe gives the number of commits since the base ref - between the refname and the hash suffix. E.g. the commit one - before v2.6.20-rc6 in the kernel repository is: - - v2.6.20-rc5-306-ga21b069 - - which tells you that its object name begins with a21b069, - v2.6.20-rc5 is an ancestor of it (meaning, the commit - contains everything -rc5 has), and there are 306 commits - since v2.6.20-rc5. - - - git-describe with --abbrev=0 can be used to show only the - name of the base ref. - - - git-blame learned a new option, --incremental, that tells it - to output the blames as they are assigned. A sample script - to use it is also included as contrib/blameview. - - - git-blame starts annotating from the working tree by default. - - -* Less external dependency - - - We no longer require the "merge" program from the RCS suite. - All 3-way file-level merges are now done internally. - - - The original implementation of git-merge-recursive which was - in Python has been removed; we have a C implementation of it - now. - - - git-shortlog is no longer a Perl script. It no longer - requires output piped from git-log; it can accept revision - parameters directly on the command line. - - -* I18n - - - We have always encouraged the commit message to be encoded in - UTF-8, but the users are allowed to use legacy encoding as - appropriate for their projects. This will continue to be the - case. However, a non UTF-8 commit encoding _must_ be - explicitly set with i18n.commitencoding in the repository - where a commit is made; otherwise git-commit-tree will - complain if the log message does not look like a valid UTF-8 - string. - - - The value of i18n.commitencoding in the originating - repository is recorded in the commit object on the "encoding" - header, if it is not UTF-8. git-log and friends notice this, - and reencodes the message to the log output encoding when - displaying, if they are different. The log output encoding - is determined by "git log --encoding=<encoding>", - i18n.logoutputencoding configuration, or i18n.commitencoding - configuration, in the decreasing order of preference, and - defaults to UTF-8. - - - Tools for e-mailed patch application now default to -u - behavior; i.e. it always re-codes from the e-mailed encoding - to the encoding specified with i18n.commitencoding. This - unfortunately forces projects that have happily been using a - legacy encoding without setting i18n.commitencoding to set - the configuration, but taken with other improvement, please - excuse us for this very minor one-time inconvenience. - - -* e-mailed patches - - - See the above I18n section. - - - git-format-patch now enables --binary without being asked. - git-am does _not_ default to it, as sending binary patch via - e-mail is unusual and is harder to review than textual - patches and it is prudent to require the person who is - applying the patch to explicitly ask for it. - - - The default suffix for git-format-patch output is now ".patch", - not ".txt". This can be changed with --suffix=.txt option, - or setting the config variable "format.suffix" to ".txt". - - -* Foreign SCM interfaces - - - git-svn now requires the Perl SVN:: libraries, the - command-line backend was too slow and limited. - - - the 'commit' subcommand of git-svn has been renamed to - 'set-tree', and 'dcommit' is the recommended replacement for - day-to-day work. - - - git fast-import backend. - - -* User support - - - Quite a lot of documentation updates. - - - Bash completion scripts have been updated heavily. - - - Better error messages for often used Porcelainish commands. - - - Git GUI. This is a simple Tk based graphical interface for - common Git operations. - - -* Sliding mmap - - - We used to assume that we can mmap the whole packfile while - in use, but with a large project this consumes huge virtual - memory space and truly huge ones would not fit in the - userland address space on 32-bit platforms. We now mmap huge - packfile in pieces to avoid this problem. - - -* Shallow clones - - - There is a partial support for 'shallow' repositories that - keeps only recent history. A 'shallow clone' is created by - specifying how deep that truncated history should be - (e.g. "git clone --depth 5 git://some.where/repo.git"). - - Currently a shallow repository has number of limitations: - - - Cloning and fetching _from_ a shallow clone are not - supported (nor tested -- so they might work by accident but - they are not expected to). - - - Pushing from nor into a shallow clone are not expected to - work. - - - Merging inside a shallow repository would work as long as a - merge base is found in the recent history, but otherwise it - will be like merging unrelated histories and may result in - huge conflicts. - - but this would be more than adequate for people who want to - look at near the tip of a big project with a deep history and - send patches in e-mail format. diff --git a/third_party/git/Documentation/RelNotes/1.5.1.1.txt b/third_party/git/Documentation/RelNotes/1.5.1.1.txt deleted file mode 100644 index 91471213bd..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.1.1.txt +++ /dev/null @@ -1,65 +0,0 @@ -GIT v1.5.1.1 Release Notes -========================== - -Fixes since v1.5.1 ------------------- - -* Documentation updates - - - The --left-right option of rev-list and friends is documented. - - - The documentation for cvsimport has been majorly improved. - - - "git-show-ref --exclude-existing" was documented. - -* Bugfixes - - - The implementation of -p option in "git cvsexportcommit" had - the meaning of -C (context reduction) option wrong, and - loosened the context requirements when it was told to be - strict. - - - "git cvsserver" did not behave like the real cvsserver when - client side removed a file from the working tree without - doing anything else on the path. In such a case, it should - restore it from the checked out revision. - - - "git fsck" issued an alarming error message on detached - HEAD. It is not an error since at least 1.5.0. - - - "git send-email" produced of References header of unbounded length; - fixed this with line-folding. - - - "git archive" to download from remote site should not - require you to be in a git repository, but it incorrectly - did. - - - "git apply" ignored -p<n> for "diff --git" formatted - patches. - - - "git rerere" recorded a conflict that had one side empty - (the other side adds) incorrectly; this made merging in the - other direction fail to use previously recorded resolution. - - - t4200 test was broken where "wc -l" pads its output with - spaces. - - - "git branch -m old new" to rename branch did not work - without a configuration file in ".git/config". - - - The sample hook for notification e-mail was misnamed. - - - gitweb did not show type-changing patch correctly in the - blobdiff view. - - - git-svn did not error out with incorrect command line options. - - - git-svn fell into an infinite loop when insanely long commit - message was found. - - - git-svn dcommit and rebase was confused by patches that were - merged from another branch that is managed by git-svn. - - - git-svn used to get confused when globbing remote branch/tag - spec (e.g. "branches = proj/branches/*:refs/remotes/origin/*") - is used and there was a plain file that matched the glob. diff --git a/third_party/git/Documentation/RelNotes/1.5.1.2.txt b/third_party/git/Documentation/RelNotes/1.5.1.2.txt deleted file mode 100644 index d88456306c..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.1.2.txt +++ /dev/null @@ -1,50 +0,0 @@ -GIT v1.5.1.2 Release Notes -========================== - -Fixes since v1.5.1.1 --------------------- - -* Bugfixes - - - "git clone" over http from a repository that has lost the - loose refs by running "git pack-refs" were broken (a code to - deal with this was added to "git fetch" in v1.5.0, but it - was missing from "git clone"). - - - "git diff a/ b/" incorrectly fell in "diff between two - filesystem objects" codepath, when the user most likely - wanted to limit the extent of output to two tracked - directories. - - - git-quiltimport had the same bug as we fixed for - git-applymbox in v1.5.1.1 -- it gave an alarming "did not - have any patch" message (but did not actually fail and was - harmless). - - - various git-svn fixes. - - - Sample update hook incorrectly always refused requests to - delete branches through push. - - - git-blame on a very long working tree path had buffer - overrun problem. - - - git-apply did not like to be fed two patches in a row that created - and then modified the same file. - - - git-svn was confused when a non-project was stored directly under - trunk/, branches/ and tags/. - - - git-svn wants the Error.pm module that was at least as new - as what we ship as part of git; install ours in our private - installation location if the one on the system is older. - - - An earlier update to command line integer parameter parser was - botched and made 'update-index --cacheinfo' completely useless. - - -* Documentation updates - - - Various documentation updates from J. Bruce Fields, Frank - Lichtenheld, Alex Riesen and others. Andrew Ruder started a - war on undocumented options. diff --git a/third_party/git/Documentation/RelNotes/1.5.1.3.txt b/third_party/git/Documentation/RelNotes/1.5.1.3.txt deleted file mode 100644 index 876408b65a..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.1.3.txt +++ /dev/null @@ -1,45 +0,0 @@ -GIT v1.5.1.3 Release Notes -========================== - -Fixes since v1.5.1.2 --------------------- - -* Bugfixes - - - git-add tried to optimize by finding common leading - directories across its arguments but botched, causing very - confused behaviour. - - - unofficial rpm.spec file shipped with git was letting - ETC_GITCONFIG set to /usr/etc/gitconfig. Tweak the official - Makefile to make it harder for distro people to make the - same mistake, by setting the variable to /etc/gitconfig if - prefix is set to /usr. - - - git-svn inconsistently stripped away username from the URL - only when svnsync_props was in use. - - - git-svn got confused when handling symlinks on Mac OS. - - - git-send-email was not quoting recipient names that have - period '.' in them. Also it did not allow overriding - envelope sender, which made it impossible to send patches to - certain subscriber-only lists. - - - built-in write_tree() routine had a sequence that renamed a - file that is still open, which some systems did not like. - - - when memory is very tight, sliding mmap code to read - packfiles incorrectly closed the fd that was still being - used to read the pack. - - - import-tars contributed front-end for fastimport was passing - wrong directory modes without checking. - - - git-fastimport trusted its input too much and allowed to - create corrupt tree objects with entries without a name. - - - git-fetch needlessly barfed when too long reflog action - description was given by the caller. - -Also contains various documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.5.1.4.txt b/third_party/git/Documentation/RelNotes/1.5.1.4.txt deleted file mode 100644 index df2f66ccb5..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.1.4.txt +++ /dev/null @@ -1,30 +0,0 @@ -GIT v1.5.1.4 Release Notes -========================== - -Fixes since v1.5.1.3 --------------------- - -* Bugfixes - - - "git-http-fetch" did not work around a bug in libcurl - earlier than 7.16 (curl_multi_remove_handle() was broken). - - - "git cvsserver" handles a file that was once removed and - then added again correctly. - - - import-tars script (in contrib/) handles GNU tar archives - that contain pathnames longer than 100 bytes (long-link - extension) correctly. - - - xdelta test program did not build correctly. - - - gitweb sometimes tried incorrectly to apply function to - decode utf8 twice, resulting in corrupt output. - - - "git blame -C" mishandled text at the end of a group of - lines. - - - "git log/rev-list --boundary" did not produce output - correctly without --left-right option. - - - Many documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.5.1.5.txt b/third_party/git/Documentation/RelNotes/1.5.1.5.txt deleted file mode 100644 index b0ab8eb371..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.1.5.txt +++ /dev/null @@ -1,42 +0,0 @@ -GIT v1.5.1.5 Release Notes -========================== - -Fixes since v1.5.1.4 --------------------- - -* Bugfixes - - - git-send-email did not understand aliases file for mutt, which - allows leading whitespaces. - - - git-format-patch emitted Content-Type and Content-Transfer-Encoding - headers for non ASCII contents, but failed to add MIME-Version. - - - git-name-rev had a buffer overrun with a deep history. - - - contributed script import-tars did not get the directory in - tar archives interpreted correctly. - - - git-svn was reported to segfault for many people on list and - #git; hopefully this has been fixed. - - - "git-svn clone" does not try to minimize the URL - (i.e. connect to higher level hierarchy) by default, as this - can prevent clone to fail if only part of the repository - (e.g. 'trunk') is open to public. - - - "git checkout branch^0" did not detach the head when you are - already on 'branch'; backported the fix from the 'master'. - - - "git-config section.var" did not correctly work when - existing configuration file had both [section] and [section "name"] - next to each other. - - - "git clone ../other-directory" was fooled if the current - directory $PWD points at is a symbolic link. - - - (build) tree_entry_extract() function was both static inline - and extern, which caused trouble compiling with Forte12 - compilers on Sun. - - - Many many documentation fixes and updates. diff --git a/third_party/git/Documentation/RelNotes/1.5.1.6.txt b/third_party/git/Documentation/RelNotes/1.5.1.6.txt deleted file mode 100644 index 55f3ac13e3..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.1.6.txt +++ /dev/null @@ -1,45 +0,0 @@ -GIT v1.5.1.6 Release Notes -========================== - -Fixes since v1.5.1.4 --------------------- - -* Bugfixes - - - git-send-email did not understand aliases file for mutt, which - allows leading whitespaces. - - - git-format-patch emitted Content-Type and Content-Transfer-Encoding - headers for non ASCII contents, but failed to add MIME-Version. - - - git-name-rev had a buffer overrun with a deep history. - - - contributed script import-tars did not get the directory in - tar archives interpreted correctly. - - - git-svn was reported to segfault for many people on list and - #git; hopefully this has been fixed. - - - git-svn also had a bug to crash svnserve by sending a bad - sequence of requests. - - - "git-svn clone" does not try to minimize the URL - (i.e. connect to higher level hierarchy) by default, as this - can prevent clone to fail if only part of the repository - (e.g. 'trunk') is open to public. - - - "git checkout branch^0" did not detach the head when you are - already on 'branch'; backported the fix from the 'master'. - - - "git-config section.var" did not correctly work when - existing configuration file had both [section] and [section "name"] - next to each other. - - - "git clone ../other-directory" was fooled if the current - directory $PWD points at is a symbolic link. - - - (build) tree_entry_extract() function was both static inline - and extern, which caused trouble compiling with Forte12 - compilers on Sun. - - - Many many documentation fixes and updates. diff --git a/third_party/git/Documentation/RelNotes/1.5.1.txt b/third_party/git/Documentation/RelNotes/1.5.1.txt deleted file mode 100644 index daed367270..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.1.txt +++ /dev/null @@ -1,371 +0,0 @@ -GIT v1.5.1 Release Notes -======================== - -Updates since v1.5.0 --------------------- - -* Deprecated commands and options. - - - git-diff-stages and git-resolve have been removed. - -* New commands and options. - - - "git log" and friends take --reverse, which instructs them - to give their output in the order opposite from their usual. - They typically output from new to old, but with this option - their output would read from old to new. "git shortlog" - usually lists older commits first, but with this option, - they are shown from new to old. - - - "git log --pretty=format:<string>" to allow more flexible - custom log output. - - - "git diff" learned --ignore-space-at-eol. This is a weaker - form of --ignore-space-change. - - - "git diff --no-index pathA pathB" can be used as diff - replacement with git specific enhancements. - - - "git diff --no-index" can read from '-' (standard input). - - - "git diff" also learned --exit-code to exit with non-zero - status when it found differences. In the future we might - want to make this the default but that would be a rather big - backward incompatible change; it will stay as an option for - now. - - - "git diff --quiet" is --exit-code with output turned off, - meant for scripted use to quickly determine if there is any - tree-level difference. - - - Textual patch generation with "git diff" without -w/-b - option has been significantly optimized. "git blame" got - faster because of the same change. - - - "git log" and "git rev-list" has been optimized - significantly when they are used with pathspecs. - - - "git branch --track" can be used to set up configuration - variables to help it easier to base your work on branches - you track from a remote site. - - - "git format-patch --attach" now emits attachments. Use - --inline to get an inlined multipart/mixed. - - - "git name-rev" learned --refs=<pattern>, to limit the tags - used for naming the given revisions only to the ones - matching the given pattern. - - - "git remote update" is to run "git fetch" for defined remotes - to update tracking branches. - - - "git cvsimport" can now take '-d' to talk with a CVS - repository different from what are recorded in CVS/Root - (overriding it with environment CVSROOT does not work). - - - "git bundle" can help sneaker-netting your changes between - repositories. - - - "git mergetool" can help 3-way file-level conflict - resolution with your favorite graphical merge tools. - - - A new configuration "core.symlinks" can be used to disable - symlinks on filesystems that do not support them; they are - checked out as regular files instead. - - - You can name a commit object with its first line of the - message. The syntax to use is ':/message text'. E.g. - - $ git show ":/object name: introduce ':/<oneline prefix>' notation" - - means the same thing as: - - $ git show 28a4d940443806412effa246ecc7768a21553ec7 - - - "git bisect" learned a new command "run" that takes a script - to run after each revision is checked out to determine if it - is good or bad, to automate the bisection process. - - - "git log" family learned a new traversal option --first-parent, - which does what the name suggests. - - -* Updated behavior of existing commands. - - - "git-merge-recursive" used to barf when there are more than - one common ancestors for the merge, and merging them had a - rename/rename conflict. This has been fixed. - - - "git fsck" does not barf on corrupt loose objects. - - - "git rm" does not remove newly added files without -f. - - - "git archimport" allows remapping when coming up with git - branch names from arch names. - - - git-svn got almost a rewrite. - - - core.autocrlf configuration, when set to 'true', makes git - to convert CRLF at the end of lines in text files to LF when - reading from the filesystem, and convert in reverse when - writing to the filesystem. The variable can be set to - 'input', in which case the conversion happens only while - reading from the filesystem but files are written out with - LF at the end of lines. Currently, which paths to consider - 'text' (i.e. be subjected to the autocrlf mechanism) is - decided purely based on the contents, but the plan is to - allow users to explicitly override this heuristic based on - paths. - - - The behavior of 'git-apply', when run in a subdirectory, - without --index nor --cached were inconsistent with that of - the command with these options. This was fixed to match the - behavior with --index. A patch that is meant to be applied - with -p1 from the toplevel of the project tree can be - applied with any custom -p<n> option. A patch that is not - relative to the toplevel needs to be applied with -p<n> - option with or without --index (or --cached). - - - "git diff" outputs a trailing HT when pathnames have embedded - SP on +++/--- header lines, in order to help "GNU patch" to - parse its output. "git apply" was already updated to accept - this modified output format since ce74618d (Sep 22, 2006). - - - "git cvsserver" runs hooks/update and honors its exit status. - - - "git cvsserver" can be told to send everything with -kb. - - - "git diff --check" also honors the --color output option. - - - "git name-rev" used to stress the fact that a ref is a tag too - much, by saying something like "v1.2.3^0~22". It now says - "v1.2.3~22" in such a case (it still says "v1.2.3^0" if it does - not talk about an ancestor of the commit that is tagged, which - makes sense). - - - "git rev-list --boundary" now shows boundary markers for the - commits omitted by --max-age and --max-count condition. - - - The configuration mechanism now reads $(prefix)/etc/gitconfig. - - - "git apply --verbose" shows what preimage lines were wanted - when it couldn't find them. - - - "git status" in a read-only repository got a bit saner. - - - "git fetch" (hence "git clone" and "git pull") are less - noisy when the output does not go to tty. - - - "git fetch" between repositories with many refs were slow - even when there are not many changes that needed - transferring. This has been sped up by partially rewriting - the heaviest parts in C. - - - "git mailinfo" which splits an e-mail into a patch and the - meta-information was rewritten, thanks to Don Zickus. It - handles nested multipart better. The command was broken for - a brief period on 'master' branch since 1.5.0 but the - breakage is fixed now. - - - send-email learned configurable bcc and chain-reply-to. - - - "git remote show $remote" also talks about branches that - would be pushed if you run "git push remote". - - - Using objects from packs is now seriously optimized by clever - use of a cache. This should be most noticeable in git-log - family of commands that involve reading many tree objects. - In addition, traversing revisions while filtering changes - with pathspecs is made faster by terminating the comparison - between the trees as early as possible. - - -* Hooks - - - The part to send out notification e-mails was removed from - the sample update hook, as it was not an appropriate place - to do so. The proper place to do this is the new post-receive - hook. An example hook has been added to contrib/hooks/. - - -* Others - - - git-revert, git-gc and git-cherry-pick are now built-ins. - -Fixes since v1.5.0 ------------------- - -These are all in v1.5.0.x series. - -* Documentation updates - - - Clarifications and corrections to 1.5.0 release notes. - - - The main documentation did not link to git-remote documentation. - - - Clarified introductory text of git-rebase documentation. - - - Converted remaining mentions of update-index on Porcelain - documents to git-add/git-rm. - - - Some i18n.* configuration variables were incorrectly - described as core.*; fixed. - - - added and clarified core.bare, core.legacyheaders configurations. - - - updated "git-clone --depth" documentation. - - - user-manual updates. - - - Options to 'git remote add' were described insufficiently. - - - Configuration format.suffix was not documented. - - - Other formatting and spelling fixes. - - - user-manual has better cross references. - - - gitweb installation/deployment procedure is now documented. - - -* Bugfixes - - - git-upload-pack closes unused pipe ends; earlier this caused - many zombies to hang around. - - - git-rerere was recording the contents of earlier hunks - duplicated in later hunks. This prevented resolving the same - conflict when performing the same merge the other way around. - - - git-add and git-update-index on a filesystem on which - executable bits are unreliable incorrectly reused st_mode - bits even when the path changed between symlink and regular - file. - - - git-daemon marks the listening sockets with FD_CLOEXEC so - that it won't be leaked into the children. - - - segfault from git-blame when the mandatory pathname - parameter was missing was fixed; usage() message is given - instead. - - - git-rev-list did not read $GIT_DIR/config file, which means - that did not honor i18n.logoutputencoding correctly. - - - Automated merge conflict handling when changes to symbolic - links conflicted were completely broken. The merge-resolve - strategy created a regular file with conflict markers in it - in place of the symbolic link. The default strategy, - merge-recursive was even more broken. It removed the path - that was pointed at by the symbolic link. Both of these - problems have been fixed. - - - 'git diff maint master next' did not correctly give combined - diff across three trees. - - - 'git fast-import' portability fix for Solaris. - - - 'git show-ref --verify' without arguments did not error out - but segfaulted. - - - 'git diff :tracked-file `pwd`/an-untracked-file' gave an extra - slashes after a/ and b/. - - - 'git format-patch' produced too long filenames if the commit - message had too long line at the beginning. - - - Running 'make all' and then without changing anything - running 'make install' still rebuilt some files. This - was inconvenient when building as yourself and then - installing as root (especially problematic when the source - directory is on NFS and root is mapped to nobody). - - - 'git-rerere' failed to deal with two unconflicted paths that - sorted next to each other. - - - 'git-rerere' attempted to open(2) a symlink and failed if - there was a conflict. Since a conflicting change to a - symlink would not benefit from rerere anyway, the command - now ignores conflicting changes to symlinks. - - - 'git-repack' did not like to pass more than 64 arguments - internally to underlying 'rev-list' logic, which made it - impossible to repack after accumulating many (small) packs - in the repository. - - - 'git-diff' to review the combined diff during a conflicted - merge were not reading the working tree version correctly - when changes to a symbolic link conflicted. It should have - read the data using readlink(2) but read from the regular - file the symbolic link pointed at. - - - 'git-remote' did not like period in a remote's name. - - - 'git.el' honors the commit coding system from the configuration. - - - 'blameview' in contrib/ correctly digs deeper when a line is - clicked. - - - 'http-push' correctly makes sure the remote side has leading - path. Earlier it started in the middle of the path, and - incorrectly. - - - 'git-merge' did not exit with non-zero status when the - working tree was dirty and cannot fast forward. It does - now. - - - 'cvsexportcommit' does not lose yet-to-be-used message file. - - - int-vs-size_t typefix when running combined diff on files - over 2GB long. - - - 'git apply --whitespace=strip' should not touch unmodified - lines. - - - 'git-mailinfo' choke when a logical header line was too long. - - - 'git show A..B' did not error out. Negative ref ("not A" in - this example) does not make sense for the purpose of the - command, so now it errors out. - - - 'git fmt-merge-msg --file' without file parameter did not - correctly error out. - - - 'git archimport' barfed upon encountering a commit without - summary. - - - 'git index-pack' did not protect itself from getting a short - read out of pread(2). - - - 'git http-push' had a few buffer overruns. - - - Build dependency fixes to rebuild fetch.o when other headers - change. - - - git.el does not add duplicate sign-off lines. - - - git-commit shows the full stat of the resulting commit, not - just about the files in the current directory, when run from - a subdirectory. - - - "git-checkout -m '@{8 hours ago}'" had a funny failure from - eval; fixed. - - - git-merge (hence git-pull) did not refuse fast-forwarding - when the working tree had local changes that would have - conflicted with it. - - - a handful small fixes to gitweb. - - - build procedure for user-manual is fixed not to require locally - installed stylesheets. - - - "git commit $paths" on paths whose earlier contents were - already updated in the index were failing out. - - -* Tweaks - - - sliding mmap() inefficiently mmaped the same region of a - packfile with an access pattern that used objects in the - reverse order. This has been made more efficient. diff --git a/third_party/git/Documentation/RelNotes/1.5.2.1.txt b/third_party/git/Documentation/RelNotes/1.5.2.1.txt deleted file mode 100644 index d41984df0b..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.2.1.txt +++ /dev/null @@ -1,47 +0,0 @@ -GIT v1.5.2.1 Release Notes -========================== - -Fixes since v1.5.2 ------------------- - -* Bugfixes - - - Temporary files that are used when invoking external diff - programs did not tolerate a long TMPDIR. - - - git-daemon did not notice when it could not write into its - pid file. - - - git-status did not honor core.excludesFile configuration like - git-add did. - - - git-annotate did not work from a subdirectory while - git-blame did. - - - git-cvsserver should have disabled access to a repository - with "gitcvs.pserver.enabled = false" set even when - "gitcvs.enabled = true" was set at the same time. It - didn't. - - - git-cvsimport did not work correctly in a repository with - its branch heads were packed with pack-refs. - - - ident unexpansion to squash "$Id: xxx $" that is in the - repository copy removed incorrect number of bytes. - - - git-svn misbehaved when the subversion repository did not - provide MD5 checksums for files. - - - git rebase (and git am) misbehaved on commits that have '\n' - (literally backslash and en, not a linefeed) in the title. - - - code to decode base85 used in binary patches had one error - return codepath wrong. - - - RFC2047 Q encoding output by git-format-patch used '_' for a - space, which is not understood by some programs. It uses =20 - which is safer. - - - git-fastimport --import-marks was broken; fixed. - - - A lot of documentation updates, clarifications and fixes. diff --git a/third_party/git/Documentation/RelNotes/1.5.2.2.txt b/third_party/git/Documentation/RelNotes/1.5.2.2.txt deleted file mode 100644 index 7bfa341750..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.2.2.txt +++ /dev/null @@ -1,61 +0,0 @@ -GIT v1.5.2.2 Release Notes -========================== - -Fixes since v1.5.2.1 --------------------- - -* Usability fix - - - git-gui is shipped with its updated blame interface. It is - rumored that the older one was not just unusable but was - active health hazard, but this one is actually pretty. - Please see for yourself. - -* Bugfixes - - - "git checkout fubar" was utterly confused when there is a - branch fubar and a tag fubar at the same time. It correctly - checks out the branch fubar now. - - - "git clone /path/foo" to clone a local /path/foo.git - repository left an incorrect configuration. - - - "git send-email" correctly unquotes RFC 2047 quoted names in - the patch-email before using their values. - - - We did not accept number of seconds since epoch older than - year 2000 as a valid timestamp. We now interpret positive - integers more than 8 digits as such, which allows us to - express timestamps more recent than March 1973. - - - git-cvsimport did not work when you have GIT_DIR to point - your repository at a nonstandard location. - - - Some systems (notably, Solaris) lack hstrerror() to make - h_errno human readable; prepare a replacement - implementation. - - - .gitignore file listed git-core.spec but what we generate is - git.spec, and nobody noticed for a long time. - - - "git-merge-recursive" does not try to run file level merge - on binary files. - - - "git-branch --track" did not create tracking configuration - correctly when the branch name had slash in it. - - - The email address of the user specified with user.email - configuration was overridden by EMAIL environment variable. - - - The tree parser did not warn about tree entries with - nonsense file modes, and assumed they must be blobs. - - - "git log -z" without any other request to generate diff still - invoked the diff machinery, wasting cycles. - -* Documentation - - - Many updates to fix stale or missing documentation. - - - Although our documentation was primarily meant to be formatted - with AsciiDoc7, formatting with AsciiDoc8 is supported better. diff --git a/third_party/git/Documentation/RelNotes/1.5.2.3.txt b/third_party/git/Documentation/RelNotes/1.5.2.3.txt deleted file mode 100644 index addb22955b..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.2.3.txt +++ /dev/null @@ -1,27 +0,0 @@ -GIT v1.5.2.3 Release Notes -========================== - -Fixes since v1.5.2.2 --------------------- - - * Bugfixes - - - Version 2 pack index format was introduced in version 1.5.2 - to support pack files that has offset that cannot be - represented in 32-bit. The runtime code to validate such - an index mishandled such an index for an empty pack. - - - Commit walkers (most notably, fetch over http protocol) - tried to traverse commit objects contained in trees (aka - subproject); they shouldn't. - - - A build option NO_R_TO_GCC_LINKER was not explained in Makefile - comment correctly. - - * Documentation Fixes and Updates - - - git-config --regexp was not documented properly. - - - git-repack -a was not documented properly. - - - git-remote -n was not documented properly. diff --git a/third_party/git/Documentation/RelNotes/1.5.2.4.txt b/third_party/git/Documentation/RelNotes/1.5.2.4.txt deleted file mode 100644 index 75cff475f6..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.2.4.txt +++ /dev/null @@ -1,28 +0,0 @@ -GIT v1.5.2.4 Release Notes -========================== - -Fixes since v1.5.2.3 --------------------- - - * Bugfixes - - - "git-gui" bugfixes, including a handful fixes to run it - better on Cygwin/MSYS. - - - "git checkout" failed to switch back and forth between - branches, one of which has "frotz -> xyzzy" symlink and - file "xyzzy/filfre", while the other one has a file - "frotz/filfre". - - - "git prune" used to segfault upon seeing a commit that is - referred to by a tree object (aka "subproject"). - - - "git diff --name-status --no-index" mishandled an added file. - - - "git apply --reverse --whitespace=warn" still complained - about whitespaces that a forward application would have - introduced. - - * Documentation Fixes and Updates - - - A handful documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.5.2.5.txt b/third_party/git/Documentation/RelNotes/1.5.2.5.txt deleted file mode 100644 index e8281c72a0..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.2.5.txt +++ /dev/null @@ -1,30 +0,0 @@ -GIT v1.5.2.5 Release Notes -========================== - -Fixes since v1.5.2.4 --------------------- - - * Bugfixes - - - "git add -u" had a serious data corruption problem in one - special case (when the changes to a subdirectory's files - consist only deletion of files). - - - "git add -u <path>" did not work from a subdirectory. - - - "git apply" left an empty directory after all its files are - renamed away. - - - "git $anycmd foo/bar", when there is a file 'foo' in the - working tree, complained that "git $anycmd foo/bar --" form - should be used to disambiguate between revs and files, - which was completely bogus. - - - "git checkout-index" and other commands that checks out - files to the work tree tried unlink(2) on directories, - which is a sane thing to do on sane systems, but not on - Solaris when you are root. - - * Documentation Fixes and Updates - - - A handful documentation fixes. diff --git a/third_party/git/Documentation/RelNotes/1.5.2.txt b/third_party/git/Documentation/RelNotes/1.5.2.txt deleted file mode 100644 index e8328d090a..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.2.txt +++ /dev/null @@ -1,197 +0,0 @@ -GIT v1.5.2 Release Notes -======================== - -Updates since v1.5.1 --------------------- - -* Plumbing level superproject support. - - You can include a subdirectory that has an independent git - repository in your index and tree objects of your project - ("superproject"). This plumbing (i.e. "core") level - superproject support explicitly excludes recursive behaviour. - - The "subproject" entries in the index and trees of a superproject - are incompatible with older versions of git. Experimenting with - the plumbing level support is encouraged, but be warned that - unless everybody in your project updates to this release or - later, using this feature would make your project - inaccessible by people with older versions of git. - -* Plumbing level gitattributes support. - - The gitattributes mechanism allows you to add 'attributes' to - paths in your project, and affect the way certain git - operations work. Currently you can influence if a path is - considered a binary or text (the former would be treated by - 'git diff' not to produce textual output; the latter can go - through the line endings conversion process in repositories - with core.autocrlf set), expand and unexpand '$Id$' keyword - with blob object name, specify a custom 3-way merge driver, - and specify a custom diff driver. You can also apply - arbitrary filter to contents on check-in/check-out codepath - but this feature is an extremely sharp-edged razor and needs - to be handled with caution (do not use it unless you - understand the earlier mailing list discussion on keyword - expansion). These conversions apply when checking files in - or out, and exporting via git-archive. - -* The packfile format now optionally supports 64-bit index. - - This release supports the "version 2" format of the .idx - file. This is automatically enabled when a huge packfile - needs more than 32-bit to express offsets of objects in the - pack. - -* Comes with an updated git-gui 0.7.1 - -* Updated gitweb: - - - can show combined diff for merges; - - uses font size of user's preference, not hardcoded in pixels; - - can now 'grep'; - -* New commands and options. - - - "git bisect start" can optionally take a single bad commit and - zero or more good commits on the command line. - - - "git shortlog" can optionally be told to wrap its output. - - - "subtree" merge strategy allows another project to be merged in as - your subdirectory. - - - "git format-patch" learned a new --subject-prefix=<string> - option, to override the built-in "[PATCH]". - - - "git add -u" is a quick way to do the first stage of "git - commit -a" (i.e. update the index to match the working - tree); it obviously does not make a commit. - - - "git clean" honors a new configuration, "clean.requireforce". When - set to true, this makes "git clean" a no-op, preventing you - from losing files by typing "git clean" when you meant to - say "make clean". You can still say "git clean -f" to - override this. - - - "git log" family of commands learned --date={local,relative,default} - option. --date=relative is synonym to the --relative-date. - --date=local gives the timestamp in local timezone. - -* Updated behavior of existing commands. - - - When $GIT_COMMITTER_EMAIL or $GIT_AUTHOR_EMAIL is not set - but $EMAIL is set, the latter is used as a substitute. - - - "git diff --stat" shows size of preimage and postimage blobs - for binary contents. Earlier it only said "Bin". - - - "git lost-found" shows stuff that are unreachable except - from reflogs. - - - "git checkout branch^0" now detaches HEAD at the tip commit - on the named branch, instead of just switching to the - branch (use "git checkout branch" to switch to the branch, - as before). - - - "git bisect next" can be used after giving only a bad commit - without giving a good one (this starts bisection half-way to - the root commit). We used to refuse to operate without a - good and a bad commit. - - - "git push", when pushing into more than one repository, does - not stop at the first error. - - - "git archive" does not insist you to give --format parameter - anymore; it defaults to "tar". - - - "git cvsserver" can use backends other than sqlite. - - - "gitview" (in contrib/ section) learned to better support - "git-annotate". - - - "git diff $commit1:$path2 $commit2:$path2" can now report - mode changes between the two blobs. - - - Local "git fetch" from a repository whose object store is - one of the alternates (e.g. fetching from the origin in a - repository created with "git clone -l -s") avoids - downloading objects unnecessarily. - - - "git blame" uses .mailmap to canonicalize the author name - just like "git shortlog" does. - - - "git pack-objects" pays attention to pack.depth - configuration variable. - - - "git cherry-pick" and "git revert" does not use .msg file in - the working tree to prepare commit message; instead it uses - $GIT_DIR/MERGE_MSG as other commands do. - -* Builds - - - git-p4import has never been installed; now there is an - installation option to do so. - - - gitk and git-gui can be configured out. - - - Generated documentation pages automatically get version - information from GIT_VERSION. - - - Parallel build with "make -j" descending into subdirectory - was fixed. - -* Performance Tweaks - - - Optimized "git-rev-list --bisect" (hence "git-bisect"). - - - Optimized "git-add $path" in a large directory, most of - whose contents are ignored. - - - Optimized "git-diff-tree" for reduced memory footprint. - - - The recursive merge strategy updated a worktree file that - was changed identically in two branches, when one of them - renamed it. We do not do that when there is no rename, so - match that behaviour. This avoids excessive rebuilds. - - - The default pack depth has been increased to 50, as the - recent addition of delta_base_cache makes deeper delta chains - much less expensive to access. Depending on the project, it was - reported that this reduces the resulting pack file by 10% - or so. - - -Fixes since v1.5.1 ------------------- - -All of the fixes in v1.5.1 maintenance series are included in -this release, unless otherwise noted. - -* Bugfixes - - - Switching branches with "git checkout" refused to work when - a path changes from a file to a directory between the - current branch and the new branch, in order not to lose - possible local changes in the directory that is being turned - into a file with the switch. We now allow such a branch - switch after making sure that there is no locally modified - file nor un-ignored file in the directory. This has not - been backported to 1.5.1.x series, as it is rather an - intrusive change. - - - Merging branches that have a file in one and a directory in - another at the same path used to get quite confused. We - handle such a case a bit more carefully, even though that is - still left as a conflict for the user to sort out. This - will not be backported to 1.5.1.x series, as it is rather an - intrusive change. - - - git-fetch had trouble with a remote with insanely large number - of refs. - - - "git clean -d -X" now does not remove non-excluded directories. - - - rebasing (without -m) a series that changes a symlink to a directory - in the middle of a path confused git-apply greatly and refused to - operate. diff --git a/third_party/git/Documentation/RelNotes/1.5.3.1.txt b/third_party/git/Documentation/RelNotes/1.5.3.1.txt deleted file mode 100644 index 7ff546c743..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.3.1.txt +++ /dev/null @@ -1,10 +0,0 @@ -GIT v1.5.3.1 Release Notes -========================== - -Fixes since v1.5.3 ------------------- - -This is solely to fix the generated RPM's dependencies. We used -to have git-p4 package but we do not anymore. As suggested on -the mailing list, this release makes git-core "Obsolete" git-p4, -so that yum update would not complain. diff --git a/third_party/git/Documentation/RelNotes/1.5.3.2.txt b/third_party/git/Documentation/RelNotes/1.5.3.2.txt deleted file mode 100644 index 4bbde3cab4..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.3.2.txt +++ /dev/null @@ -1,58 +0,0 @@ -GIT v1.5.3.2 Release Notes -========================== - -Fixes since v1.5.3.1 --------------------- - - * git-push sent thin packs by default, which was not good for - the public distribution server (no point in saving transfer - while pushing; no point in making the resulting pack less - optimum). - - * git-svn sometimes terminated with "Malformed network data" when - talking over svn:// protocol. - - * git-send-email re-issued the same message-id about 10% of the - time if you fired off 30 messages within a single second. - - * git-stash was not terminating the log message of commits it - internally creates with LF. - - * git-apply failed to check the size of the patch hunk when its - beginning part matched the remainder of the preimage exactly, - even though the preimage recorded in the hunk was much larger - (therefore the patch should not have applied), leading to a - segfault. - - * "git rm foo && git commit foo" complained that 'foo' needs to - be added first, instead of committing the removal, which was a - nonsense. - - * git grep -c said "/dev/null: 0". - - * git-add -u failed to recognize a blob whose type changed - between the index and the work tree. - - * The limit to rename detection has been tightened a lot to - reduce performance problems with a huge change. - - * cvsimport and svnimport barfed when the input tried to move - a tag. - - * "git apply -pN" did not chop the right number of directories. - - * "git svnimport" did not like SVN tags with funny characters in them. - - * git-gui 0.8.3, with assorted fixes, including: - - - font-chooser on X11 was unusable with large number of fonts; - - a diff that contained a deleted symlink made it barf; - - an untracked symbolic link to a directory made it fart; - - a file with % in its name made it vomit; - - -Documentation updates ---------------------- - -User manual has been somewhat restructured. I think the new -organization is much easier to read. diff --git a/third_party/git/Documentation/RelNotes/1.5.3.3.txt b/third_party/git/Documentation/RelNotes/1.5.3.3.txt deleted file mode 100644 index d213846951..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.3.3.txt +++ /dev/null @@ -1,31 +0,0 @@ -GIT v1.5.3.3 Release Notes -========================== - -Fixes since v1.5.3.2 --------------------- - - * git-quiltimport did not like it when a patch described in the - series file does not exist. - - * p4 importer missed executable bit in some cases. - - * The default shell on some FreeBSD did not execute the - argument parsing code correctly and made git unusable. - - * git-svn incorrectly spawned pager even when the user - explicitly asked not to. - - * sample post-receive hook overquoted the envelope sender - value. - - * git-am got confused when the patch contained a change that is - only about type and not contents. - - * git-mergetool did not show our and their version of the - conflicted file when started from a subdirectory of the - project. - - * git-mergetool did not pass correct options when invoking diff3. - - * git-log sometimes invoked underlying "diff" machinery - unnecessarily. diff --git a/third_party/git/Documentation/RelNotes/1.5.3.4.txt b/third_party/git/Documentation/RelNotes/1.5.3.4.txt deleted file mode 100644 index b04b3a45a5..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.3.4.txt +++ /dev/null @@ -1,35 +0,0 @@ -GIT v1.5.3.4 Release Notes -========================== - -Fixes since v1.5.3.3 --------------------- - - * Change to "git-ls-files" in v1.5.3.3 that was introduced to support - partial commit of removal better had a segfaulting bug, which was - diagnosed and fixed by Keith and Carl. - - * Performance improvements for rename detection has been backported - from the 'master' branch. - - * "git-for-each-ref --format='%(numparent)'" was not working - correctly at all, and --format='%(parent)' was not working for - merge commits. - - * Sample "post-receive-hook" incorrectly sent out push - notification e-mails marked as "From: " the committer of the - commit that happened to be at the tip of the branch that was - pushed, not from the person who pushed. - - * "git-remote" did not exit non-zero status upon error. - - * "git-add -i" did not respond very well to EOF from tty nor - bogus input. - - * "git-rebase -i" squash subcommand incorrectly made the - author of later commit the author of resulting commit, - instead of taking from the first one in the squashed series. - - * "git-stash apply --index" was not documented. - - * autoconfiguration learned that "ar" command is found as "gas" on - some systems. diff --git a/third_party/git/Documentation/RelNotes/1.5.3.5.txt b/third_party/git/Documentation/RelNotes/1.5.3.5.txt deleted file mode 100644 index 7ff1d5d0d1..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.3.5.txt +++ /dev/null @@ -1,94 +0,0 @@ -GIT v1.5.3.5 Release Notes -========================== - -Fixes since v1.5.3.4 --------------------- - - * Comes with git-gui 0.8.4. - - * "git-config" silently ignored options after --list; now it will - error out with a usage message. - - * "git-config --file" failed if the argument used a relative path - as it changed directories before opening the file. - - * "git-config --file" now displays a proper error message if it - cannot read the file specified on the command line. - - * "git-config", "git-diff", "git-apply" failed if run from a - subdirectory with relative GIT_DIR and GIT_WORK_TREE set. - - * "git-blame" crashed if run during a merge conflict. - - * "git-add -i" did not handle single line hunks correctly. - - * "git-rebase -i" and "git-stash apply" failed if external diff - drivers were used for one or more files in a commit. They now - avoid calling the external diff drivers. - - * "git-log --follow" did not work unless diff generation (e.g. -p) - was also requested. - - * "git-log --follow -B" did not work at all. Fixed. - - * "git-log -M -B" did not correctly handle cases of very large files - being renamed and replaced by very small files in the same commit. - - * "git-log" printed extra newlines between commits when a diff - was generated internally (e.g. -S or --follow) but not displayed. - - * "git-push" error message is more helpful when pushing to a - repository with no matching refs and none specified. - - * "git-push" now respects + (force push) on wildcard refspecs, - matching the behavior of git-fetch. - - * "git-filter-branch" now updates the working directory when it - has finished filtering the current branch. - - * "git-instaweb" no longer fails on Mac OS X. - - * "git-cvsexportcommit" didn't always create new parent directories - before trying to create new child directories. Fixed. - - * "git-fetch" printed a scary (but bogus) error message while - fetching a tag that pointed to a tree or blob. The error did - not impact correctness, only user perception. The bogus error - is no longer printed. - - * "git-ls-files --ignored" did not properly descend into non-ignored - directories that themselves contained ignored files if d_type - was not supported by the filesystem. This bug impacted systems - such as AFS. Fixed. - - * Git segfaulted when reading an invalid .gitattributes file. Fixed. - - * post-receive-email example hook was fixed for non-fast-forward - updates. - - * Documentation updates for supported (but previously undocumented) - options of "git-archive" and "git-reflog". - - * "make clean" no longer deletes the configure script that ships - with the git tarball, making multiple architecture builds easier. - - * "git-remote show origin" spewed a warning message from Perl - when no remote is defined for the current branch via - branch.<name>.remote configuration settings. - - * Building with NO_PERL_MAKEMAKER excessively rebuilt contents - of perl/ subdirectory by rewriting perl.mak. - - * http.sslVerify configuration settings were not used in scripted - Porcelains. - - * "git-add" leaked a bit of memory while scanning for files to add. - - * A few workarounds to squelch false warnings from recent gcc have - been added. - - * "git-send-pack $remote frotz" segfaulted when there is nothing - named 'frotz' on the local end. - - * "git-rebase --interactive" did not handle its "--strategy" option - properly. diff --git a/third_party/git/Documentation/RelNotes/1.5.3.6.txt b/third_party/git/Documentation/RelNotes/1.5.3.6.txt deleted file mode 100644 index 069a2b2cf9..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.3.6.txt +++ /dev/null @@ -1,48 +0,0 @@ -GIT v1.5.3.6 Release Notes -========================== - -Fixes since v1.5.3.5 --------------------- - - * git-cvsexportcommit handles root commits better. - - * git-svn dcommit used to clobber when sending a series of - patches. - - * git-svn dcommit failed after attempting to rebase when - started with a dirty index; now it stops upfront. - - * git-grep sometimes refused to work when your index was - unmerged. - - * "git-grep -A1 -B2" acted as if it was told to run "git -A1 -B21". - - * git-hash-object did not honor configuration variables, such as - core.compression. - - * git-index-pack choked on a huge pack on 32-bit machines, even when - large file offsets are supported. - - * atom feeds from git-web said "10" for the month of November. - - * a memory leak in commit walker was plugged. - - * When git-send-email inserted the original author's From: - address in body, it did not mark the message with - Content-type: as needed. - - * git-revert and git-cherry-pick incorrectly refused to start - when the work tree was dirty. - - * git-clean did not honor core.excludesfile configuration. - - * git-add mishandled ".gitignore" files when applying them to - subdirectories. - - * While importing a too branchy history, git-fastimport did not - honor delta depth limit properly. - - * Support for zlib implementations that lack ZLIB_VERNUM and definition - of deflateBound() has been added. - - * Quite a lot of documentation clarifications. diff --git a/third_party/git/Documentation/RelNotes/1.5.3.7.txt b/third_party/git/Documentation/RelNotes/1.5.3.7.txt deleted file mode 100644 index 2f690616c8..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.3.7.txt +++ /dev/null @@ -1,45 +0,0 @@ -GIT v1.5.3.7 Release Notes -========================== - -Fixes since v1.5.3.6 --------------------- - - * git-send-email added 8-bit contents to the payload without - marking it as 8-bit in a CTE header. - - * "git-bundle create a.bndl HEAD" dereferenced the symref and - did not record the ref as 'HEAD'; this prevented a bundle - from being used as a normal source of git-clone. - - * The code to reject nonsense command line of the form - "git-commit -a paths..." and "git-commit --interactive - paths..." were broken. - - * Adding a signature that is not ASCII-only to an original - commit that is ASCII-only would make the result non-ASCII. - "git-format-patch -s" did not mark such a message correctly - with MIME encoding header. - - * git-add sometimes did not mark the resulting index entry - stat-clean. This affected only cases when adding the - contents with the same length as the previously staged - contents, and the previous staging made the index entry - "racily clean". - - * git-commit did not honor GIT_INDEX_FILE the user had in the - environment. - - * When checking out a revision, git-checkout did not report where the - updated HEAD is if you happened to have a file called HEAD in the - work tree. - - * "git-rev-list --objects" mishandled a tree that points at a - submodule. - - * "git cvsimport" was not ready for packed refs that "git gc" can - produce and gave incorrect results. - - * Many scripted Porcelains were confused when you happened to have a - file called "HEAD" in your work tree. - -Also it contains updates to the user manual and documentation. diff --git a/third_party/git/Documentation/RelNotes/1.5.3.8.txt b/third_party/git/Documentation/RelNotes/1.5.3.8.txt deleted file mode 100644 index 0e3ff58a46..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.3.8.txt +++ /dev/null @@ -1,25 +0,0 @@ -GIT v1.5.3.8 Release Notes -========================== - -Fixes since v1.5.3.7 --------------------- - - * Some documentation used "email.com" as an example domain. - - * git-svn fix to handle funky branch and project names going over - http/https correctly. - - * git-svn fix to tone down a needlessly alarming warning message. - - * git-clone did not correctly report errors while fetching over http. - - * git-send-email added redundant Message-Id: header to the outgoing - e-mail when the patch text already had one. - - * a read-beyond-end-of-buffer bug in configuration file updater was fixed. - - * git-grep used to show the same hit repeatedly for unmerged paths. - - * After amending the patch title in "git-am -i", the command did not - report the patch it applied with the updated title. - diff --git a/third_party/git/Documentation/RelNotes/1.5.3.txt b/third_party/git/Documentation/RelNotes/1.5.3.txt deleted file mode 100644 index 0668d3c0ca..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.3.txt +++ /dev/null @@ -1,366 +0,0 @@ -GIT v1.5.3 Release Notes -======================== - -Updates since v1.5.2 --------------------- - -* The commit walkers other than http are officially deprecated, - but still supported for now. - -* The submodule support has Porcelain layer. - - Note that the current submodule support is minimal and this is - deliberately so. A design decision we made is that operations - at the supermodule level do not recurse into submodules by - default. The expectation is that later we would add a - mechanism to tell git which submodules the user is interested - in, and this information might be used to determine the - recursive behaviour of certain commands (e.g. "git checkout" - and "git diff"), but currently we haven't agreed on what that - mechanism should look like. Therefore, if you use submodules, - you would probably need "git submodule update" on the - submodules you care about after running a "git checkout" at - the supermodule level. - -* There are a handful pack-objects changes to help you cope better - with repositories with pathologically large blobs in them. - -* For people who need to import from Perforce, a front-end for - fast-import is in contrib/fast-import/. - -* Comes with git-gui 0.8.2. - -* Comes with updated gitk. - -* New commands and options. - - - "git log --date=<format>" can use more formats: iso8601, rfc2822. - - - The hunk header output from "git diff" family can be customized - with the attributes mechanism. See gitattributes(5) for details. - - - "git stash" allows you to quickly save away your work in - progress and replay it later on an updated state. - - - "git rebase" learned an "interactive" mode that let you - pick and reorder which commits to rebuild. - - - "git fsck" can save its findings in $GIT_DIR/lost-found, without a - separate invocation of "git lost-found" command. The blobs stored by - lost-found are stored in plain format to allow you to grep in them. - - - $GIT_WORK_TREE environment variable can be used together with - $GIT_DIR to work in a subdirectory of a working tree that is - not located at "$GIT_DIR/..". - - - Giving "--file=<file>" option to "git config" is the same as - running the command with GIT_CONFIG=<file> environment. - - - "git log" learned a new option "--follow", to follow - renaming history of a single file. - - - "git filter-branch" lets you rewrite the revision history of - specified branches. You can specify a number of filters to - modify the commits, files and trees. - - - "git cvsserver" learned new options (--base-path, --export-all, - --strict-paths) inspired by "git daemon". - - - "git daemon --base-path-relaxed" can help migrating a repository URL - that did not use to use --base-path to use --base-path. - - - "git commit" can use "-t templatefile" option and commit.template - configuration variable to prime the commit message given to you in the - editor. - - - "git submodule" command helps you manage the projects from - the superproject that contain them. - - - In addition to core.compression configuration option, - core.loosecompression and pack.compression options can - independently tweak zlib compression levels used for loose - and packed objects. - - - "git ls-tree -l" shows size of blobs pointed at by the - tree entries, similar to "/bin/ls -l". - - - "git rev-list" learned --regexp-ignore-case and - --extended-regexp options to tweak its matching logic used - for --grep filtering. - - - "git describe --contains" is a handier way to call more - obscure command "git name-rev --tags". - - - "git gc --aggressive" tells the command to spend more cycles - to optimize the repository harder. - - - "git repack" learned a "window-memory" limit which - dynamically reduces the window size to stay within the - specified memory usage. - - - "git repack" can be told to split resulting packs to avoid - exceeding limit specified with "--max-pack-size". - - - "git fsck" gained --verbose option. This is really really - verbose but it might help you identify exact commit that is - corrupt in your repository. - - - "git format-patch" learned --numbered-files option. This - may be useful for MH users. - - - "git format-patch" learned format.subjectprefix configuration - variable, which serves the same purpose as "--subject-prefix" - option. - - - "git tag -n -l" shows tag annotations while listing tags. - - - "git cvsimport" can optionally use the separate-remote layout. - - - "git blame" can be told to see through commits that change - whitespaces and indentation levels with "-w" option. - - - "git send-email" can be told not to thread the messages when - sending out more than one patches. - - - "git send-email" can also be told how to find whom to cc the - message to for each message via --cc-cmd. - - - "git config" learned NUL terminated output format via -z to - help scripts. - - - "git add" learned "--refresh <paths>..." option to selectively refresh - the cached stat information. - - - "git init -q" makes the command quieter. - - - "git -p command" now has a cousin of opposite sex, "git --no-pager - command". - -* Updated behavior of existing commands. - - - "gitweb" can offer multiple snapshot formats. - - ***NOTE*** Unfortunately, this changes the format of the - $feature{snapshot}{default} entry in the per-site - configuration file 'gitweb_config.perl'. It used to be a - three-element tuple that describe a single format; with the - new configuration item format, you only have to say the name - of the format ('tgz', 'tbz2' or 'zip'). Please update the - your configuration file accordingly. - - - "git clone" uses -l (hardlink files under .git) by default when - cloning locally. - - - URL used for "git clone" and friends can specify nonstandard SSH port - by using ssh://host:port/path/to/repo syntax. - - - "git bundle create" can now create a bundle without negative refs, - i.e. "everything since the beginning up to certain points". - - - "git diff" (but not the plumbing level "git diff-tree") now - recursively descends into trees by default. - - - "git diff" does not show differences that come only from - stat-dirtiness in the form of "diff --git" header anymore. - It runs "update-index --refresh" silently as needed. - - - "git tag -l" used to match tags by globbing its parameter as if it - has wildcard '*' on both ends, which made "git tag -l gui" to match - tag 'gitgui-0.7.0'; this was very annoying. You now have to add - asterisk on the sides you want to wildcard yourself. - - - The editor to use with many interactive commands can be - overridden with GIT_EDITOR environment variable, or if it - does not exist, with core.editor configuration variable. As - before, if you have neither, environment variables VISUAL - and EDITOR are consulted in this order, and then finally we - fall back on "vi". - - - "git rm --cached" does not complain when removing a newly - added file from the index anymore. - - - Options to "git log" to affect how --grep/--author options look for - given strings now have shorter abbreviations. -i is for ignore case, - and -E is for extended regexp. - - - "git log" learned --log-size to show the number of bytes in - the log message part of the output to help qgit. - - - "git log --name-status" does not require you to give "-r" anymore. - As a general rule, Porcelain commands should recurse when showing - diff. - - - "git format-patch --root A" can be used to format everything - since the beginning up to A. This was supported with - "git format-patch --root A A" for a long time, but was not - properly documented. - - - "git svn dcommit" retains local merge information. - - - "git svnimport" allows an empty string to be specified as the - trunk/ directory. This is necessary to suck data from a SVN - repository that doe not have trunk/ branches/ and tags/ organization - at all. - - - "git config" to set values also honors type flags like --bool - and --int. - - - core.quotepath configuration can be used to make textual git - output to emit most of the characters in the path literally. - - - "git mergetool" chooses its backend more wisely, taking - notice of its environment such as use of X, Gnome/KDE, etc. - - - "gitweb" shows merge commits a lot nicer than before. The - default view uses more compact --cc format, while the UI - allows to choose normal diff with any parent. - - - snapshot files "gitweb" creates from a repository at - $path/$project/.git are more useful. We use $project part - in the filename, which we used to discard. - - - "git cvsimport" creates lightweight tags; there is no - interesting information we can record in an annotated tag, - and the handcrafted ones the old code created was not - properly formed anyway. - - - "git push" pretends that you immediately fetched back from - the remote by updating corresponding remote tracking - branches if you have any. - - - The diffstat given after a merge (or a pull) honors the - color.diff configuration. - - - "git commit --amend" is now compatible with various message source - options such as -m/-C/-c/-F. - - - "git apply --whitespace=strip" removes blank lines added at - the end of the file. - - - "git fetch" over git native protocols with "-v" option shows - connection status, and the IP address of the other end, to - help diagnosing problems. - - - We used to have core.legacyheaders configuration, when - set to false, allowed git to write loose objects in a format - that mimics the format used by objects stored in packs. It - turns out that this was not so useful. Although we will - continue to read objects written in that format, we do not - honor that configuration anymore and create loose objects in - the legacy/traditional format. - - - "--find-copies-harder" option to diff family can now be - spelled as "-C -C" for brevity. - - - "git mailsplit" (hence "git am") can read from Maildir - formatted mailboxes. - - - "git cvsserver" does not barf upon seeing "cvs login" - request. - - - "pack-objects" honors "delta" attribute set in - .gitattributes. It does not attempt to deltify blobs that - come from paths with delta attribute set to false. - - - "new-workdir" script (in contrib) can now be used with a - bare repository. - - - "git mergetool" learned to use gvimdiff. - - - "gitview" (in contrib) has a better blame interface. - - - "git log" and friends did not handle a commit log message - that is larger than 16kB; they do now. - - - "--pretty=oneline" output format for "git log" and friends - deals with "malformed" commit log messages that have more - than one lines in the first paragraph better. We used to - show the first line, cutting the title at mid-sentence; we - concatenate them into a single line and treat the result as - "oneline". - - - "git p4import" has been demoted to contrib status. For - a superior option, checkout the "git p4" front end to - "git fast-import" (also in contrib). The man page and p4 - rpm have been removed as well. - - - "git mailinfo" (hence "am") now tries to see if the message - is in utf-8 first, instead of assuming iso-8859-1, if - incoming e-mail does not say what encoding it is in. - -* Builds - - - old-style function definitions (most notably, a function - without parameter defined with "func()", not "func(void)") - have been eradicated. - - - "git tag" and "git verify-tag" have been rewritten in C. - -* Performance Tweaks - - - "git pack-objects" avoids re-deltification cost by caching - small enough delta results it creates while looking for the - best delta candidates. - - - "git pack-objects" learned a new heuristic to prefer delta - that is shallower in depth over the smallest delta - possible. This improves both overall packfile access - performance and packfile density. - - - diff-delta code that is used for packing has been improved - to work better on big files. - - - when there are more than one pack files in the repository, - the runtime used to try finding an object always from the - newest packfile; it now tries the same packfile as we found - the object requested the last time, which exploits the - locality of references. - - - verifying pack contents done by "git fsck --full" got boost - by carefully choosing the order to verify objects in them. - - - "git read-tree -m" to read into an already populated index - has been optimized vastly. The effect of this can be seen - when switching branches that have differences in only a - handful paths. - - - "git add paths..." and "git commit paths..." has also been - heavily optimized. - -Fixes since v1.5.2 ------------------- - -All of the fixes in v1.5.2 maintenance series are included in -this release, unless otherwise noted. - -* Bugfixes - - - "gitweb" had trouble handling non UTF-8 text with older - Encode.pm Perl module. - - - "git svn" misparsed the data from the commits in the repository when - the user had "color.diff = true" in the configuration. This has been - fixed. - - - There was a case where "git svn dcommit" clobbered changes made on the - SVN side while committing multiple changes. - - - "git-write-tree" had a bad interaction with racy-git avoidance and - gitattributes mechanisms. - - - "git --bare command" overrode existing GIT_DIR setting and always - made it treat the current working directory as GIT_DIR. - - - "git ls-files --error-unmatch" does not complain if you give the - same path pattern twice by mistake. - - - "git init" autodetected core.filemode but not core.symlinks, which - made a new directory created automatically by "git clone" cumbersome - to use on filesystems that require these configurations to be set. - - - "git log" family of commands behaved differently when run as "git - log" (no pathspec) and as "git log --" (again, no pathspec). This - inconsistency was introduced somewhere in v1.3.0 series but now has - been corrected. - - - "git rebase -m" incorrectly displayed commits that were skipped. diff --git a/third_party/git/Documentation/RelNotes/1.5.4.1.txt b/third_party/git/Documentation/RelNotes/1.5.4.1.txt deleted file mode 100644 index d4e44b8b09..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.4.1.txt +++ /dev/null @@ -1,17 +0,0 @@ -GIT v1.5.4.1 Release Notes -========================== - -Fixes since v1.5.4 ------------------- - - * "git-commit -C $tag" used to work but rewrite in C done in - 1.5.4 broke it. - - * An entry in the .gitattributes file that names a pattern in a - subdirectory of the directory it is in did not match - correctly (e.g. pattern "b/*.c" in "a/.gitattributes" should - match "a/b/foo.c" but it didn't). - - * Customized color specification was parsed incorrectly when - numeric color values are used. This was fixed in 1.5.4.1. - diff --git a/third_party/git/Documentation/RelNotes/1.5.4.2.txt b/third_party/git/Documentation/RelNotes/1.5.4.2.txt deleted file mode 100644 index 21d0df59fb..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.4.2.txt +++ /dev/null @@ -1,43 +0,0 @@ -GIT v1.5.4.2 Release Notes -========================== - -Fixes since v1.5.4 ------------------- - - * The configuration parser was not prepared to see string - valued variables misspelled as boolean and segfaulted. - - * Temporary files left behind due to interrupted object - transfers were not cleaned up with "git prune". - - * "git config --unset" was confused when the unset variables - were spelled with continuation lines in the config file. - - * The merge message detection in "git cvsimport" did not catch - a message that began with "Merge...". - - * "git status" suggests "git rm --cached" for unstaging the - earlier "git add" before the initial commit. - - * "git status" output was incorrect during a partial commit. - - * "git bisect" refused to start when the HEAD was detached. - - * "git bisect" allowed a wildcard character in the commit - message expanded while writing its log file. - - * Manual pages were not formatted correctly with docbook xsl - 1.72; added a workaround. - - * "git-commit -C $tag" used to work but rewrite in C done in - 1.5.4 broke it. This was fixed in 1.5.4.1. - - * An entry in the .gitattributes file that names a pattern in a - subdirectory of the directory it is in did not match - correctly (e.g. pattern "b/*.c" in "a/.gitattributes" should - match "a/b/foo.c" but it didn't). This was fixed in 1.5.4.1. - - * Customized color specification was parsed incorrectly when - numeric color values are used. This was fixed in 1.5.4.1. - - * http transport misbehaved when linked with curl-gnutls. diff --git a/third_party/git/Documentation/RelNotes/1.5.4.3.txt b/third_party/git/Documentation/RelNotes/1.5.4.3.txt deleted file mode 100644 index b0fc67fb2a..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.4.3.txt +++ /dev/null @@ -1,27 +0,0 @@ -GIT v1.5.4.3 Release Notes -========================== - -Fixes since v1.5.4.2 --------------------- - - * RPM spec used to pull in everything with 'git'. This has been - changed so that 'git' package contains just the core parts, - and we now supply 'git-all' metapackage to slurp in everything. - This should match end user's expectation better. - - * When some refs failed to update, git-push reported "failure" - which was unclear if some other refs were updated or all of - them failed atomically (the answer is the former). Reworded - the message to clarify this. - - * "git clone" from a repository whose HEAD was misconfigured - did not set up the remote properly. Now it tries to do - better. - - * Updated git-push documentation to clarify what "matching" - means, in order to reduce user confusion. - - * Updated git-add documentation to clarify "add -u" operates in - the current subdirectory you are in, just like other commands. - - * git-gui updates to work on OSX and Windows better. diff --git a/third_party/git/Documentation/RelNotes/1.5.4.4.txt b/third_party/git/Documentation/RelNotes/1.5.4.4.txt deleted file mode 100644 index 323c1a88c7..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.4.4.txt +++ /dev/null @@ -1,66 +0,0 @@ -GIT v1.5.4.4 Release Notes -========================== - -Fixes since v1.5.4.3 --------------------- - - * Building and installing with an overtight umask such as 077 made - installed templates unreadable by others, while the rest of the install - are done in a way that is friendly to umask 022. - - * "git cvsexportcommit -w $cvsdir" misbehaved when GIT_DIR is set to a - relative directory. - - * "git http-push" had an invalid memory access that could lead it to - segfault. - - * When "git rebase -i" gave control back to the user for a commit that is - marked to be edited, it just said "modify it with commit --amend", - without saying what to do to continue after modifying it. Give an - explicit instruction to run "rebase --continue" to be more helpful. - - * "git send-email" in 1.5.4.3 issued a bogus empty In-Reply-To: header. - - * "git bisect" showed mysterious "won't bisect on seeked tree" error message. - This was leftover from Cogito days to prevent "bisect" starting from a - cg-seeked state. We still keep the Cogito safety, but running "git bisect - start" when another bisect was in effect will clean up and start over. - - * "git push" with an explicit PATH to receive-pack did not quite work if - receive-pack was not on usual PATH. We earlier fixed the same issue - with "git fetch" and upload-pack, but somehow forgot to do so in the - other direction. - - * git-gui's info dialog was not displayed correctly when the user tries - to commit nothing (i.e. without staging anything). - - * "git revert" did not properly fail when attempting to run with a - dirty index. - - * "git merge --no-commit --no-ff <other>" incorrectly made commits. - - * "git merge --squash --no-ff <other>", which is a nonsense combination - of options, was not rejected. - - * "git ls-remote" and "git remote show" against an empty repository - failed, instead of just giving an empty result (regression). - - * "git fast-import" did not handle a renamed path whose name needs to be - quoted, due to a bug in unquote_c_style() function. - - * "git cvsexportcommit" was confused when multiple files with the same - basename needed to be pushed out in the same commit. - - * "git daemon" did not send early errors to syslog. - - * "git log --merge" did not work well with --left-right option. - - * "git svn" prompted for client cert password every time it accessed the - server. - - * The reset command in "git fast-import" data stream was documented to - end with an optional LF, but it actually required one. - - * "git svn dcommit/rebase" did not honor --rewrite-root option. - -Also included are a handful documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.5.4.5.txt b/third_party/git/Documentation/RelNotes/1.5.4.5.txt deleted file mode 100644 index bbd130e36d..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.4.5.txt +++ /dev/null @@ -1,56 +0,0 @@ -GIT v1.5.4.5 Release Notes -========================== - -Fixes since v1.5.4.4 --------------------- - - * "git fetch there" when the URL information came from the Cogito style - branches/there file did not update refs/heads/there (regression in - 1.5.4). - - * Bogus refspec configuration such as "remote.there.fetch = =" were not - detected as errors (regression in 1.5.4). - - * You couldn't specify a custom editor whose path contains a whitespace - via GIT_EDITOR (and core.editor). - - * The subdirectory filter to "git filter-branch" mishandled a history - where the subdirectory becomes empty and then later becomes non-empty. - - * "git shortlog" gave an empty line if the original commit message was - malformed (e.g. a botched import from foreign SCM). Now it finds the - first non-empty line and uses it for better information. - - * When the user fails to give a revision parameter to "git svn", an error - from the Perl interpreter was issued because the script lacked proper - error checking. - - * After "git rebase" stopped due to conflicts, if the user played with - "git reset" and friends, "git rebase --abort" failed to go back to the - correct commit. - - * Additional work trees prepared with git-new-workdir (in contrib/) did - not share git-svn metadata directory .git/svn with the original. - - * "git-merge-recursive" did not mark addition of the same path with - different filemodes correctly as a conflict. - - * "gitweb" gave malformed URL when pathinfo stype paths are in use. - - * "-n" stands for "--no-tags" again for "git fetch". - - * "git format-patch" did not detect the need to add 8-bit MIME header - when the user used format.header configuration. - - * "rev~" revision specifier used to mean "rev", which was inconsistent - with how "rev^" worked. Now "rev~" is the same as "rev~1" (hence it - also is the same as "rev^1"), and "rev~0" is the same as "rev^0" - (i.e. it has to be a commit). - - * "git quiltimport" did not grok empty lines, lines in "file -pNNN" - format to specify the prefix levels and lines with trailing comments. - - * "git rebase -m" triggered pre-commit verification, which made - "rebase --continue" impossible. - -As usual, it also comes with many documentation fixes and clarifications. diff --git a/third_party/git/Documentation/RelNotes/1.5.4.6.txt b/third_party/git/Documentation/RelNotes/1.5.4.6.txt deleted file mode 100644 index 3e3c3e55a3..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.4.6.txt +++ /dev/null @@ -1,43 +0,0 @@ -GIT v1.5.4.6 Release Notes -========================== - -I personally do not think there is any reason anybody should want to -run v1.5.4.X series these days, because 'master' version is always -more stable than any tagged released version of git. - -This is primarily to futureproof "git-shell" to accept requests -without a dash between "git" and subcommand name (e.g. "git -upload-pack") which the newer client will start to make sometime in -the future. - -Fixes since v1.5.4.5 --------------------- - - * Command line option "-n" to "git-repack" was not correctly parsed. - - * Error messages from "git-apply" when the patchfile cannot be opened - have been improved. - - * Error messages from "git-bisect" when given nonsense revisions have - been improved. - - * reflog syntax that uses time e.g. "HEAD@{10 seconds ago}:path" did not - stop parsing at the closing "}". - - * "git rev-parse --symbolic-full-name ^master^2" printed solitary "^", - but it should print nothing. - - * "git apply" did not enforce "match at the beginning" correctly. - - * a path specification "a/b" in .gitattributes file should not match - "sub/a/b", but it did. - - * "git log --date-order --topo-order" did not override the earlier - date-order with topo-order as expected. - - * "git fast-export" did not export octopus merges correctly. - - * "git archive --prefix=$path/" mishandled gitattributes. - -As usual, it also comes with many documentation fixes and clarifications. - diff --git a/third_party/git/Documentation/RelNotes/1.5.4.7.txt b/third_party/git/Documentation/RelNotes/1.5.4.7.txt deleted file mode 100644 index 9065a0e273..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.4.7.txt +++ /dev/null @@ -1,10 +0,0 @@ -GIT v1.5.4.7 Release Notes -========================== - -Fixes since 1.5.4.7 -------------------- - - * Removed support for an obsolete gitweb request URI, whose - implementation ran "git diff" Porcelain, instead of using plumbing, - which would have run an external diff command specified in the - repository configuration as the gitweb user. diff --git a/third_party/git/Documentation/RelNotes/1.5.4.txt b/third_party/git/Documentation/RelNotes/1.5.4.txt deleted file mode 100644 index f1323b6174..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.4.txt +++ /dev/null @@ -1,377 +0,0 @@ -GIT v1.5.4 Release Notes -======================== - -Removal -------- - - * "git svnimport" was removed in favor of "git svn". It is still there - in the source tree (contrib/examples) but unsupported. - - * As git-commit and git-status have been rewritten, "git runstatus" - helper script lost all its users and has been removed. - - -Temporarily disabled --------------------- - - * "git http-push" is known not to work well with cURL library older - than 7.16, and we had reports of repository corruption. It is - disabled on such platforms for now. Unfortunately, 1.5.3.8 shares - the same issue. In other words, this does not mean you will be - fine if you stick to an older git release. For now, please do not - use http-push from older git with cURL older than 7.16 if you - value your data. A proper fix will hopefully materialize in - later versions. - - -Deprecation notices -------------------- - - * From v1.6.0, git will by default install dashed form of commands - (e.g. "git-commit") outside of users' normal $PATH, and will install - only selected commands ("git" itself, and "gitk") in $PATH. This - implies: - - - Using dashed forms of git commands (e.g. "git-commit") from the - command line has been informally deprecated since early 2006, but - now it officially is, and will be removed in the future. Use - dash-less forms (e.g. "git commit") instead. - - - Using dashed forms from your scripts, without first prepending the - return value from "git --exec-path" to the scripts' PATH, has been - informally deprecated since early 2006, but now it officially is. - - - Use of dashed forms with "PATH=$(git --exec-path):$PATH; export - PATH" early in your script is not deprecated with this change. - - Users are strongly encouraged to adjust their habits and scripts now - to prepare for this change. - - * The post-receive hook was introduced in March 2007 to supersede - the post-update hook, primarily to overcome the command line length - limitation of the latter. Use of post-update hook will be deprecated - in future versions of git, starting from v1.6.0. - - * "git lost-found" was deprecated in favor of "git fsck"'s --lost-found - option, and will be removed in the future. - - * "git peek-remote" is deprecated, as "git ls-remote" was written in C - and works for all transports; "git peek-remote" will be removed in - the future. - - * "git repo-config" which was an old name for "git config" command - has been supported without being advertised for a long time. The - next feature release will remove it. - - * From v1.6.0, the repack.usedeltabaseoffset config option will default - to true, which will give denser packfiles (i.e. more efficient storage). - The downside is that git older than version 1.4.4 will not be able - to directly use a repository packed using this setting. - - * From v1.6.0, the pack.indexversion config option will default to 2, - which is slightly more efficient, and makes repacking more immune to - data corruptions. Git older than version 1.5.2 may revert to version 1 - of the pack index with a manual "git index-pack" to be able to directly - access corresponding pack files. - - -Updates since v1.5.3 --------------------- - - * Comes with much improved gitk, with i18n. - - * Comes with git-gui 0.9.2 with i18n. - - * gitk is now merged as a subdirectory of git.git project, in - preparation for its i18n. - - * progress displays from many commands are a lot nicer to the eye. - Transfer commands show throughput data. - - * many commands that pay attention to per-directory .gitignore now do - so lazily, which makes the usual case go much faster. - - * Output processing for '--pretty=format:<user format>' has been - optimized. - - * Rename detection of diff family while detecting exact matches has - been greatly optimized. - - * Rename detection of diff family tries to make more natural looking - pairing. Earlier, if multiple identical rename sources were - found in the preimage, the source used was picked pretty much at random. - - * Value "true" for color.diff and color.status configuration used to - mean "always" (even when the output is not going to a terminal). - This has been corrected to mean the same thing as "auto". - - * "git diff" Porcelain now respects diff.external configuration, which - is another way to specify GIT_EXTERNAL_DIFF. - - * "git diff" can be told to use different prefixes other than - "a/" and "b/" e.g. "git diff --src-prefix=l/ --dst-prefix=k/". - - * "git diff" sometimes did not quote paths with funny - characters properly. - - * "git log" (and any revision traversal commands) misbehaved - when --diff-filter is given but was not asked to actually - produce diff. - - * HTTP proxy can be specified per remote repository using - remote.*.httpproxy configuration, or global http.proxy configuration - variable. - - * Various Perforce importer updates. - - * Example update and post-receive hooks have been improved. - - * Any command that wants to take a commit object name can now use - ":/string" syntax to name a commit. - - * "git reset" is now built-in and its output can be squelched with -q. - - * "git reset --hard" does not make any sense in a bare - repository, but did not error out; fixed. - - * "git send-email" can optionally talk over ssmtp and use SMTP-AUTH. - - * "git rebase" learned --whitespace option. - - * In "git rebase", when you decide not to replay a particular change - after the command stopped with a conflict, you can say "git rebase - --skip" without first running "git reset --hard", as the command now - runs it for you. - - * "git rebase --interactive" mode can now work on detached HEAD. - - * Other minor to serious bugs in "git rebase -i" have been fixed. - - * "git rebase" now detaches head during its operation, so after a - successful "git rebase" operation, the reflog entry branch@{1} for - the current branch points at the commit before the rebase was - started. - - * "git rebase -i" also triggers rerere to help your repeated merges. - - * "git merge" can call the "post-merge" hook. - - * "git pack-objects" can optionally run deltification with multiple - threads. - - * "git archive" can optionally substitute keywords in files marked with - export-subst attribute. - - * "git cherry-pick" made a misguided attempt to repeat the original - command line in the generated log message, when told to cherry-pick a - commit by naming a tag that points at it. It does not anymore. - - * "git for-each-ref" learned %(xxxdate:<date-format>) syntax to show the - various date fields in different formats. - - * "git gc --auto" is a low-impact way to automatically run a variant of - "git repack" that does not lose unreferenced objects (read: safer - than the usual one) after the user accumulates too many loose - objects. - - * "git clean" has been rewritten in C. - - * You need to explicitly set clean.requireForce to "false" to allow - "git clean" without -f to do any damage (lack of the configuration - variable used to mean "do not require -f option to lose untracked - files", but we now use the safer default). - - * The kinds of whitespace errors "git diff" and "git apply" notice (and - fix) can be controlled via 'core.whitespace' configuration variable - and 'whitespace' attribute in .gitattributes file. - - * "git push" learned --dry-run option to show what would happen if a - push is run. - - * "git push" does not update a tracking ref on the local side when the - remote refused to update the corresponding ref. - - * "git push" learned --mirror option. This is to push the local refs - one-to-one to the remote, and deletes refs from the remote that do - not exist anymore in the repository on the pushing side. - - * "git push" can remove a corrupt ref at the remote site with the usual - ":ref" refspec. - - * "git remote" knows --mirror mode. This is to set up configuration to - push into a remote repository to store local branch heads to the same - branch on the remote side, and remove branch heads locally removed - from local repository at the same time. Suitable for pushing into a - back-up repository. - - * "git remote" learned "rm" subcommand. - - * "git cvsserver" can be run via "git shell". Also, "cvs" is - recognized as a synonym for "git cvsserver", so that CVS users - can be switched to git just by changing their login shell. - - * "git cvsserver" acts more like receive-pack by running post-receive - and post-update hooks. - - * "git am" and "git rebase" are far less verbose. - - * "git pull" learned to pass --[no-]ff option to underlying "git - merge". - - * "git pull --rebase" is a different way to integrate what you fetched - into your current branch. - - * "git fast-export" produces data-stream that can be fed to fast-import - to reproduce the history recorded in a git repository. - - * "git add -i" takes pathspecs to limit the set of files to work on. - - * "git add -p" is a short-hand to go directly to the selective patch - subcommand in the interactive command loop and to exit when done. - - * "git add -i" UI has been colorized. The interactive prompt - and menu can be colored by setting color.interactive - configuration. The diff output (including the hunk picker) - are colored with color.diff configuration. - - * "git commit --allow-empty" allows you to create a single-parent - commit that records the same tree as its parent, overriding the usual - safety valve. - - * "git commit --amend" can amend a merge that does not change the tree - from its first parent. - - * "git commit" used to unconditionally strip comment lines that - began with '#' and removed excess blank lines. This behavior has - been made configurable. - - * "git commit" has been rewritten in C. - - * "git stash random-text" does not create a new stash anymore. It was - a UI mistake. Use "git stash save random-text", or "git stash" - (without extra args) for that. - - * "git stash clear extra-text" does not clear the whole stash - anymore. It is tempting to expect "git stash clear stash@{2}" - to drop only a single named stash entry, and it is rude to - discard everything when that is asked (but not provided). - - * "git prune --expire <time>" can exempt young loose objects from - getting pruned. - - * "git branch --contains <commit>" can list branches that are - descendants of a given commit. - - * "git log" learned --early-output option to help interactive GUI - implementations. - - * "git bisect" learned "skip" action to mark untestable commits. - - * "git bisect visualize" learned a shorter synonym "git bisect view". - - * "git bisect visualize" runs "git log" in a non-windowed - environments. It also can be told what command to run (e.g. "git - bisect visualize tig"). - - * "git format-patch" learned "format.numbered" configuration variable - to automatically turn --numbered option on when more than one commits - are formatted. - - * "git ls-files" learned "--exclude-standard" to use the canned set of - exclude files. - - * "git tag -a -f existing" begins the editor session using the existing - annotation message. - - * "git tag -m one -m bar" (multiple -m options) behaves similarly to - "git commit"; the parameters to -m options are formatted as separate - paragraphs. - - * The format "git show" outputs an annotated tag has been updated to - include "Tagger: " and "Date: " lines from the tag itself. Strictly - speaking this is a backward incompatible change, but this is a - reasonable usability fix and people's scripts shouldn't have been - relying on the exact output from "git show" Porcelain anyway. - - * "git cvsimport" did not notice errors from underlying "cvsps" - and produced a corrupt import silently. - - * "git cvsexportcommit" learned -w option to specify and switch to the - CVS working directory. - - * "git checkout" from a subdirectory learned to use "../path" to allow - checking out a path outside the current directory without cd'ing up. - - * "git checkout" from and to detached HEAD leaves a bit more - information in the reflog. - - * "git send-email --dry-run" shows full headers for easier diagnosis. - - * "git merge-ours" is now built-in. - - * "git svn" learned "info" and "show-externals" subcommands. - - * "git svn" run from a subdirectory failed to read settings from the - .git/config. - - * "git svn" learned --use-log-author option, which picks up more - descriptive name from From: and Signed-off-by: lines in the commit - message. - - * "git svn" wasted way too much disk to record revision mappings - between svn and git; a new representation that is much more compact - for this information has been introduced to correct this. - - * "git svn" left temporary index files it used without cleaning them - up; this was corrected. - - * "git status" from a subdirectory now shows relative paths, which - makes copy-and-pasting for git-checkout/git-add/git-rm easier. The - traditional behavior to show the full path relative to the top of - the work tree can be had by setting status.relativepaths - configuration variable to false. - - * "git blame" kept text for each annotated revision in core needlessly; - this has been corrected. - - * "git shortlog" learned to default to HEAD when the standard input is - a terminal and the user did not give any revision parameter. - - * "git shortlog" learned "-e" option to show e-mail addresses as well as - authors' names. - - * "git help" learned "-w" option to show documentation in browsers. - - * In addition there are quite a few internal clean-ups. Notably: - - - many fork/exec have been replaced with run-command API, - brought from the msysgit effort. - - - introduction and more use of the option parser API. - - - enhancement and more use of the strbuf API. - - * Makefile tweaks to support HP-UX is in. - -Fixes since v1.5.3 ------------------- - -All of the fixes in v1.5.3 maintenance series are included in -this release, unless otherwise noted. - -These fixes are only in v1.5.4 and not backported to v1.5.3 maintenance -series. - - * The way "git diff --check" behaves is much more consistent with the way - "git apply --whitespace=warn" works. - - * "git svn" talking with the SVN over HTTP will correctly quote branch - and project names. - - * "git config" did not work correctly on platforms that define - REG_NOMATCH to an even number. - - * Recent versions of AsciiDoc 8 has a change to break our - documentation; a workaround has been implemented. - - * "git diff --color-words" colored context lines in a wrong color. diff --git a/third_party/git/Documentation/RelNotes/1.5.5.1.txt b/third_party/git/Documentation/RelNotes/1.5.5.1.txt deleted file mode 100644 index 7de419708f..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.5.1.txt +++ /dev/null @@ -1,44 +0,0 @@ -GIT v1.5.5.1 Release Notes -========================== - -Fixes since v1.5.5 ------------------- - - * "git archive --prefix=$path/" mishandled gitattributes. - - * "git fetch -v" that fetches into FETCH_HEAD did not report the summary - the same way as done for updating the tracking refs. - - * "git svn" misbehaved when the configuration file customized the "git - log" output format using format.pretty. - - * "git submodule status" leaked an unnecessary error message. - - * "git log --date-order --topo-order" did not override the earlier - date-order with topo-order as expected. - - * "git bisect good $this" did not check the validity of the revision - given properly. - - * "url.<there>.insteadOf" did not work correctly. - - * "git clean" ran inside subdirectory behaved as if the directory was - explicitly specified for removal by the end user from the top level. - - * "git bisect" from a detached head leaked an unnecessary error message. - - * "git bisect good $a $b" when $a is Ok but $b is bogus should have - atomically failed before marking $a as good. - - * "git fmt-merge-msg" did not clean up leading empty lines from commit - log messages like "git log" family does. - - * "git am" recorded a commit with empty Subject: line without - complaining. - - * when given a commit log message whose first paragraph consists of - multiple lines, "git rebase" squashed it into a single line. - - * "git remote add $bogus_name $url" did not complain properly. - -Also comes with various documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.5.5.2.txt b/third_party/git/Documentation/RelNotes/1.5.5.2.txt deleted file mode 100644 index 391a7b02ea..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.5.2.txt +++ /dev/null @@ -1,27 +0,0 @@ -GIT v1.5.5.2 Release Notes -========================== - -Fixes since v1.5.5.1 --------------------- - - * "git repack -n" was mistakenly made no-op earlier. - - * "git imap-send" wanted to always have imap.host even when use of - imap.tunnel made it unnecessary. - - * reflog syntax that uses time e.g. "HEAD@{10 seconds ago}:path" did not - stop parsing at the closing "}". - - * "git rev-parse --symbolic-full-name ^master^2" printed solitary "^", - but it should print nothing. - - * "git commit" did not detect when it failed to write tree objects. - - * "git fetch" sometimes transferred too many objects unnecessarily. - - * a path specification "a/b" in .gitattributes file should not match - "sub/a/b". - - * various gitweb fixes. - -Also comes with various documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.5.5.3.txt b/third_party/git/Documentation/RelNotes/1.5.5.3.txt deleted file mode 100644 index f22f98b734..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.5.3.txt +++ /dev/null @@ -1,12 +0,0 @@ -GIT v1.5.5.3 Release Notes -========================== - -Fixes since v1.5.5.2 --------------------- - - * "git send-email --compose" did not notice that non-ascii contents - needed some MIME magic. - - * "git fast-export" did not export octopus merges correctly. - -Also comes with various documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.5.5.4.txt b/third_party/git/Documentation/RelNotes/1.5.5.4.txt deleted file mode 100644 index 2d0279ecce..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.5.4.txt +++ /dev/null @@ -1,7 +0,0 @@ -GIT v1.5.5.4 Release Notes -========================== - -Fixes since v1.5.5.4 --------------------- - - * "git name-rev --all" used to segfault. diff --git a/third_party/git/Documentation/RelNotes/1.5.5.5.txt b/third_party/git/Documentation/RelNotes/1.5.5.5.txt deleted file mode 100644 index 30fa3615c7..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.5.5.txt +++ /dev/null @@ -1,11 +0,0 @@ -GIT v1.5.5.5 Release Notes -========================== - -I personally do not think there is any reason anybody should want to -run v1.5.5.X series these days, because 'master' version is always -more stable than any tagged released version of git. - -This is primarily to futureproof "git-shell" to accept requests -without a dash between "git" and subcommand name (e.g. "git -upload-pack") which the newer client will start to make sometime in -the future. diff --git a/third_party/git/Documentation/RelNotes/1.5.5.6.txt b/third_party/git/Documentation/RelNotes/1.5.5.6.txt deleted file mode 100644 index d5e85cb70e..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.5.6.txt +++ /dev/null @@ -1,10 +0,0 @@ -GIT v1.5.5.6 Release Notes -========================== - -Fixes since 1.5.5.5 -------------------- - - * Removed support for an obsolete gitweb request URI, whose - implementation ran "git diff" Porcelain, instead of using plumbing, - which would have run an external diff command specified in the - repository configuration as the gitweb user. diff --git a/third_party/git/Documentation/RelNotes/1.5.5.txt b/third_party/git/Documentation/RelNotes/1.5.5.txt deleted file mode 100644 index 2932212488..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.5.txt +++ /dev/null @@ -1,207 +0,0 @@ -GIT v1.5.5 Release Notes -======================== - -Updates since v1.5.4 --------------------- - -(subsystems) - - * Comes with git-gui 0.10.1 - -(portability) - - * We shouldn't ask for BSD group ownership semantics by setting g+s bit - on directories on older BSD systems that refuses chmod() by non root - users. BSD semantics is the default there anyway. - - * Bunch of portability improvement patches coming from an effort to port - to Solaris has been applied. - -(performance) - - * On platforms with suboptimal qsort(3) implementation, there - is an option to use more reasonable substitute we ship with - our software. - - * New configuration variable "pack.packsizelimit" can be used - in place of command line option --max-pack-size. - - * "git fetch" over the native git protocol used to make a - connection to find out the set of current remote refs and - another to actually download the pack data. We now use only - one connection for these tasks. - - * "git commit" does not run lstat(2) more than necessary - anymore. - -(usability, bells and whistles) - - * Bash completion script (in contrib) are aware of more commands and - options. - - * You can be warned when core.autocrlf conversion is applied in - such a way that results in an irreversible conversion. - - * A catch-all "color.ui" configuration variable can be used to - enable coloring of all color-capable commands, instead of - individual ones such as "color.status" and "color.branch". - - * The commands refused to take absolute pathnames where they - require pathnames relative to the work tree or the current - subdirectory. They now can take absolute pathnames in such a - case as long as the pathnames do not refer outside of the - work tree. E.g. "git add $(pwd)/foo" now works. - - * Error messages used to be sent to stderr, only to get hidden, - when $PAGER was in use. They now are sent to stdout along - with the command output to be shown in the $PAGER. - - * A pattern "foo/" in .gitignore file now matches a directory - "foo". Pattern "foo" also matches as before. - - * bash completion's prompt helper function can talk about - operation in-progress (e.g. merge, rebase, etc.). - - * Configuration variables "url.<usethis>.insteadof = <otherurl>" can be - used to tell "git-fetch" and "git-push" to use different URL than what - is given from the command line. - - * "git add -i" behaves better even before you make an initial commit. - - * "git am" refused to run from a subdirectory without a good reason. - - * After "git apply --whitespace=fix" fixes whitespace errors in a patch, - a line before the fix can appear as a context or preimage line in a - later patch, causing the patch not to apply. The command now knows to - see through whitespace fixes done to context lines to successfully - apply such a patch series. - - * "git branch" (and "git checkout -b") to branch from a local branch can - optionally set "branch.<name>.merge" to mark the new branch to build on - the other local branch, when "branch.autosetupmerge" is set to - "always", or when passing the command line option "--track" (this option - was ignored when branching from local branches). By default, this does - not happen when branching from a local branch. - - * "git checkout" to switch to a branch that has "branch.<name>.merge" set - (i.e. marked to build on another branch) reports how much the branch - and the other branch diverged. - - * When "git checkout" has to update a lot of paths, it used to be silent - for 4 seconds before it showed any progress report. It is now a bit - more impatient and starts showing progress report early. - - * "git commit" learned a new hook "prepare-commit-msg" that can - inspect what is going to be committed and prepare the commit - log message template to be edited. - - * "git cvsimport" can now take more than one -M options. - - * "git describe" learned to limit the tags to be used for - naming with --match option. - - * "git describe --contains" now barfs when the named commit - cannot be described. - - * "git describe --exact-match" describes only commits that are tagged. - - * "git describe --long" describes a tagged commit as $tag-0-$sha1, - instead of just showing the exact tagname. - - * "git describe" warns when using a tag whose name and path contradict - with each other. - - * "git diff" learned "--relative" option to limit and output paths - relative to the current directory when working in a subdirectory. - - * "git diff" learned "--dirstat" option to show birds-eye-summary of - changes more concisely than "--diffstat". - - * "git format-patch" learned --cover-letter option to generate a cover - letter template. - - * "git gc" learned --quiet option. - - * "git gc" now automatically prunes unreachable objects that are two - weeks old or older. - - * "git gc --auto" can be disabled more easily by just setting gc.auto - to zero. It also tolerates more packfiles by default. - - * "git grep" now knows "--name-only" is a synonym for the "-l" option. - - * "git help <alias>" now reports "'git <alias>' is alias to <what>", - instead of saying "No manual entry for git-<alias>". - - * "git help" can use different backends to show manual pages and this can - be configured using "man.viewer" configuration. - - * "gitk" does not restore window position from $HOME/.gitk anymore (it - still restores the size). - - * "git log --grep=<what>" learned "--fixed-strings" option to look for - <what> without treating it as a regular expression. - - * "git gui" learned an auto-spell checking. - - * "git push <somewhere> HEAD" and "git push <somewhere> +HEAD" works as - expected; they push the current branch (and only the current branch). - In addition, HEAD can be written as the value of "remote.<there>.push" - configuration variable. - - * When the configuration variable "pack.threads" is set to 0, "git - repack" auto detects the number of CPUs and uses that many threads. - - * "git send-email" learned to prompt for passwords - interactively. - - * "git send-email" learned an easier way to suppress CC - recipients. - - * "git stash" learned "pop" command, that applies the latest stash and - removes it from the stash, and "drop" command to discard the named - stash entry. - - * "git submodule" learned a new subcommand "summary" to show the - symmetric difference between the HEAD version and the work tree version - of the submodule commits. - - * Various "git cvsimport", "git cvsexportcommit", "git cvsserver", - "git svn" and "git p4" improvements. - -(internal) - - * Duplicated code between git-help and git-instaweb that - launches user's preferred browser has been refactored. - - * It is now easier to write test scripts that records known - breakages. - - * "git checkout" is rewritten in C. - - * "git remote" is rewritten in C. - - * Two conflict hunks that are separated by a very short span of common - lines are now coalesced into one larger hunk, to make the result easier - to read. - - * Run-command API's use of file descriptors is documented clearer and - is more consistent now. - - * diff output can be sent to FILE * that is different from stdout. This - will help reimplementing more things in C. - -Fixes since v1.5.4 ------------------- - -All of the fixes in v1.5.4 maintenance series are included in -this release, unless otherwise noted. - - * "git-http-push" did not allow deletion of remote ref with the usual - "push <remote> :<branch>" syntax. - - * "git-rebase --abort" did not go back to the right location if - "git-reset" was run during the "git-rebase" session. - - * "git imap-send" without setting imap.host did not error out but - segfaulted. diff --git a/third_party/git/Documentation/RelNotes/1.5.6.1.txt b/third_party/git/Documentation/RelNotes/1.5.6.1.txt deleted file mode 100644 index 4864b16445..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.6.1.txt +++ /dev/null @@ -1,28 +0,0 @@ -GIT v1.5.6.1 Release Notes -========================== - -Fixes since v1.5.6 ------------------- - -* Last minute change broke loose object creation on AIX. - -* (performance fix) We used to make $GIT_DIR absolute path early in the - programs but keeping it relative to the current directory internally - gives 1-3 per-cent performance boost. - -* bash completion knows the new --graph option to git-log family. - - -* git-diff -c/--cc showed unnecessary "deletion" lines at the context - boundary. - -* git-for-each-ref ignored %(object) and %(type) requests for tag - objects. - -* git-merge usage had a typo. - -* Rebuilding of git-svn metainfo database did not take rewriteRoot - option into account. - -* Running "git-rebase --continue/--skip/--abort" before starting a - rebase gave nonsense error messages. diff --git a/third_party/git/Documentation/RelNotes/1.5.6.2.txt b/third_party/git/Documentation/RelNotes/1.5.6.2.txt deleted file mode 100644 index 5902a85a78..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.6.2.txt +++ /dev/null @@ -1,40 +0,0 @@ -GIT v1.5.6.2 Release Notes -========================== - -Futureproof ------------ - - * "git-shell" accepts requests without a dash between "git" and - subcommand name (e.g. "git upload-pack") which the newer client will - start to make sometime in the future. - -Fixes since v1.5.6.1 --------------------- - -* "git clone" from a remote that is named with url.insteadOf setting in - $HOME/.gitconfig did not work well. - -* "git describe --long --tags" segfaulted when the described revision was - tagged with a lightweight tag. - -* "git diff --check" did not report the result via its exit status - reliably. - -* When remote side used to have branch 'foo' and git-fetch finds that now - it has branch 'foo/bar', it refuses to lose the existing remote tracking - branch and its reflog. The error message has been improved to suggest - pruning the remote if the user wants to proceed and get the latest set - of branches from the remote, including such 'foo/bar'. - -* "git reset file" should mean the same thing as "git reset HEAD file", - but we required disambiguating -- even when "file" is not ambiguous. - -* "git show" segfaulted when an annotated tag that points at another - annotated tag was given to it. - -* Optimization for a large import via "git-svn" introduced in v1.5.6 had a - serious memory and temporary file leak, which made it unusable for - moderately large import. - -* "git-svn" mangled remote nickname used in the configuration file - unnecessarily. diff --git a/third_party/git/Documentation/RelNotes/1.5.6.3.txt b/third_party/git/Documentation/RelNotes/1.5.6.3.txt deleted file mode 100644 index f61dd3504a..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.6.3.txt +++ /dev/null @@ -1,52 +0,0 @@ -GIT v1.5.6.3 Release Notes -========================== - -Fixes since v1.5.6.2 --------------------- - -* Setting core.sharedrepository to traditional "true" value was supposed to make - the repository group writable but should not affect permission for others. - However, since 1.5.6, it was broken to drop permission for others when umask is - 022, making the repository unreadable by others. - -* Setting GIT_TRACE will report spawning of external process via run_command(). - -* Using an object with very deep delta chain pinned memory needed for extracting - intermediate base objects unnecessarily long, leading to excess memory usage. - -* Bash completion script did not notice '--' marker on the command - line and tried the relatively slow "ref completion" even when - completing arguments after one. - -* Registering a non-empty blob racily and then truncating the working - tree file for it confused "racy-git avoidance" logic into thinking - that the path is now unchanged. - -* The section that describes attributes related to git-archive were placed - in a wrong place in the gitattributes(5) manual page. - -* "git am" was not helpful to the users when it detected that the committer - information is not set up properly yet. - -* "git clone" had a leftover debugging fprintf(). - -* "git clone -q" was not quiet enough as it used to and gave object count - and progress reports. - -* "git clone" marked downloaded packfile with .keep; this could be a - good thing if the remote side is well packed but otherwise not, - especially for a project that is not really big. - -* "git daemon" used to call syslog() from a signal handler, which - could raise signals of its own but generally is not reentrant. This - was fixed by restructuring the code to report syslog() after the handler - returns. - -* When "git push" tries to remove a remote ref, and corresponding - tracking ref is missing, we used to report error (i.e. failure to - remove something that does not exist). - -* "git mailinfo" (hence "git am") did not handle commit log messages in a - MIME multipart mail correctly. - -Contains other various documentation fixes. diff --git a/third_party/git/Documentation/RelNotes/1.5.6.4.txt b/third_party/git/Documentation/RelNotes/1.5.6.4.txt deleted file mode 100644 index d8968f1ecb..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.6.4.txt +++ /dev/null @@ -1,47 +0,0 @@ -GIT v1.5.6.4 Release Notes -========================== - -Fixes since v1.5.6.3 --------------------- - -* Various commands could overflow its internal buffer on a platform - with small PATH_MAX value in a repository that has contents with - long pathnames. - -* There wasn't a way to make --pretty=format:%<> specifiers to honor - .mailmap name rewriting for authors and committers. Now you can with - %aN and %cN. - -* Bash completion wasted too many cycles; this has been optimized to be - usable again. - -* Bash completion lost ref part when completing something like "git show - pu:Makefile". - -* "git-cvsserver" did not clean up its temporary working area after annotate - request. - -* "git-daemon" called syslog() from its signal handler, which was a - no-no. - -* "git-fetch" into an empty repository used to remind that the fetch will - be huge by saying "no common commits", but this was an unnecessary - noise; it is already known by the user anyway. - -* "git-http-fetch" would have segfaulted when pack idx file retrieved - from the other side was corrupt. - -* "git-index-pack" used too much memory when dealing with a deep delta chain. - -* "git-mailinfo" (hence "git-am") did not correctly handle in-body [PATCH] - line to override the commit title taken from the mail Subject header. - -* "git-rebase -i -p" lost parents that are not involved in the history - being rewritten. - -* "git-rm" lost track of where the index file was when GIT_DIR was - specified as a relative path. - -* "git-rev-list --quiet" was not quiet as advertised. - -Contains other various documentation fixes. diff --git a/third_party/git/Documentation/RelNotes/1.5.6.5.txt b/third_party/git/Documentation/RelNotes/1.5.6.5.txt deleted file mode 100644 index 47ca172462..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.6.5.txt +++ /dev/null @@ -1,29 +0,0 @@ -GIT v1.5.6.5 Release Notes -========================== - -Fixes since v1.5.6.4 --------------------- - -* "git cvsimport" used to spit out "UNKNOWN LINE..." diagnostics to stdout. - -* "git commit -F filename" and "git tag -F filename" run from subdirectories - did not read the right file. - -* "git init --template=" with blank "template" parameter linked files - under root directories to .git, which was a total nonsense. Instead, it - means "I do not want to use anything from the template directory". - -* "git diff-tree" and other diff plumbing ignored diff.renamelimit configuration - variable when the user explicitly asked for rename detection. - -* "git name-rev --name-only" did not work when "--stdin" option was in effect. - -* "git show-branch" mishandled its 8th branch. - -* Addition of "git update-index --ignore-submodules" that happened during - 1.5.6 cycle broke "git update-index --ignore-missing". - -* "git send-email" did not parse charset from an existing Content-type: - header properly. - -Contains other various documentation fixes. diff --git a/third_party/git/Documentation/RelNotes/1.5.6.6.txt b/third_party/git/Documentation/RelNotes/1.5.6.6.txt deleted file mode 100644 index 79da23db5a..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.6.6.txt +++ /dev/null @@ -1,10 +0,0 @@ -GIT v1.5.6.6 Release Notes -========================== - -Fixes since 1.5.6.5 -------------------- - - * Removed support for an obsolete gitweb request URI, whose - implementation ran "git diff" Porcelain, instead of using plumbing, - which would have run an external diff command specified in the - repository configuration as the gitweb user. diff --git a/third_party/git/Documentation/RelNotes/1.5.6.txt b/third_party/git/Documentation/RelNotes/1.5.6.txt deleted file mode 100644 index e143d8d61b..0000000000 --- a/third_party/git/Documentation/RelNotes/1.5.6.txt +++ /dev/null @@ -1,115 +0,0 @@ -GIT v1.5.6 Release Notes -======================== - -Updates since v1.5.5 --------------------- - -(subsystems) - -* Comes with updated gitk and git-gui. - -(portability) - -* git will build on AIX better than before now. - -* core.ignorecase configuration variable can be used to work better on - filesystems that are not case sensitive. - -* "git init" now autodetects the case sensitivity of the filesystem and - sets core.ignorecase accordingly. - -* cpio is no longer used; neither "curl" binary (libcurl is still used). - -(documentation) - -* Many freestanding documentation pages have been converted and made - available to "git help" (aka "man git<something>") as section 7 of - the manual pages. This means bookmarks to some HTML documentation - files may need to be updated (eg "tutorial.html" became - "gittutorial.html"). - -(performance) - -* "git clone" was rewritten in C. This will hopefully help cloning a - repository with insane number of refs. - -* "git rebase --onto $there $from $branch" used to switch to the tip of - $branch only to immediately reset back to $from, smudging work tree - files unnecessarily. This has been optimized. - -* Object creation codepath in "git-svn" has been optimized by enhancing - plumbing commands git-cat-file and git-hash-object. - -(usability, bells and whistles) - -* "git add -p" (and the "patch" subcommand of "git add -i") can choose to - apply (or not apply) mode changes independently from contents changes. - -* "git bisect help" gives longer and more helpful usage information. - -* "git bisect" does not use a special branch "bisect" anymore; instead, it - does its work on a detached HEAD. - -* "git branch" (and "git checkout -b") can be told to set up - branch.<name>.rebase automatically, so that later you can say "git pull" - and magically cause "git pull --rebase" to happen. - -* "git branch --merged" and "git branch --no-merged" can be used to list - branches that have already been merged (or not yet merged) to the - current branch. - -* "git cherry-pick" and "git revert" can add a sign-off. - -* "git commit" mentions the author identity when you are committing - somebody else's changes. - -* "git diff/log --dirstat" output is consistent between binary and textual - changes. - -* "git filter-branch" rewrites signed tags by demoting them to annotated. - -* "git format-patch --no-binary" can produce a patch that lack binary - changes (i.e. cannot be used to propagate the whole changes) meant only - for reviewing. - -* "git init --bare" is a synonym for "git --bare init" now. - -* "git gc --auto" honors a new pre-auto-gc hook to temporarily disable it. - -* "git log --pretty=tformat:<custom format>" gives a LF after each entry, - instead of giving a LF between each pair of entries which is how - "git log --pretty=format:<custom format>" works. - -* "git log" and friends learned the "--graph" option to show the ancestry - graph at the left margin of the output. - -* "git log" and friends can be told to use date format that is different - from the default via 'log.date' configuration variable. - -* "git send-email" now can send out messages outside a git repository. - -* "git send-email --compose" was made aware of rfc2047 quoting. - -* "git status" can optionally include output from "git submodule - summary". - -* "git svn" learned --add-author-from option to propagate the authorship - by munging the commit log message. - -* new object creation and looking up in "git svn" has been optimized. - -* "gitweb" can read from a system-wide configuration file. - -(internal) - -* "git unpack-objects" and "git receive-pack" is now more strict about - detecting breakage in the objects they receive over the wire. - - -Fixes since v1.5.5 ------------------- - -All of the fixes in v1.5.5 maintenance series are included in -this release, unless otherwise noted. - -And there are too numerous small fixes to otherwise note here ;-) diff --git a/third_party/git/Documentation/RelNotes/1.6.0.1.txt b/third_party/git/Documentation/RelNotes/1.6.0.1.txt deleted file mode 100644 index 49d7a1cafa..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.0.1.txt +++ /dev/null @@ -1,36 +0,0 @@ -GIT v1.6.0.1 Release Notes -========================== - -Fixes since v1.6.0 ------------------- - -* "git diff --cc" did not honor content mangling specified by - gitattributes and core.autocrlf when reading from the work tree. - -* "git diff --check" incorrectly detected new trailing blank lines when - whitespace check was in effect. - -* "git for-each-ref" tried to dereference NULL when asked for '%(body)" on - a tag with a single incomplete line as its payload. - -* "git format-patch" peeked before the beginning of a string when - "format.headers" variable is empty (a misconfiguration). - -* "git help help" did not work correctly. - -* "git mailinfo" (hence "git am") was unhappy when MIME multipart message - contained garbage after the finishing boundary. - -* "git mailinfo" also was unhappy when the "From: " line only had a bare - e-mail address. - -* "git merge" did not refresh the index correctly when a merge resulted in - a fast-forward. - -* "git merge" did not resolve a truly trivial merges that can be done - without content level merges. - -* "git svn dcommit" to a repository with URL that has embedded usernames - did not work correctly. - -Contains other various documentation fixes. diff --git a/third_party/git/Documentation/RelNotes/1.6.0.2.txt b/third_party/git/Documentation/RelNotes/1.6.0.2.txt deleted file mode 100644 index 7d8fb85e1b..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.0.2.txt +++ /dev/null @@ -1,81 +0,0 @@ -GIT v1.6.0.2 Release Notes -========================== - -Fixes since v1.6.0.1 --------------------- - -* Installation on platforms that needs .exe suffix to git-* programs were - broken in 1.6.0.1. - -* Installation on filesystems without symbolic links support did not - work well. - -* In-tree documentations and test scripts now use "git foo" form to set a - better example, instead of the "git-foo" form (which is an acceptable - form if you have "PATH=$(git --exec-path):$PATH" in your script) - -* Many commands did not use the correct working tree location when used - with GIT_WORK_TREE environment settings. - -* Some systems need to use compatibility fnmatch and regex libraries - independent from each other; the compat/ area has been reorganized to - allow this. - - -* "git apply --unidiff-zero" incorrectly applied a -U0 patch that inserts - a new line before the second line. - -* "git blame -c" did not exactly work like "git annotate" when range - boundaries are involved. - -* "git checkout file" when file is still unmerged checked out contents from - a random high order stage, which was confusing. - -* "git clone $there $here/" with extra trailing slashes after explicit - local directory name $here did not work as expected. - -* "git diff" on tracked contents with CRLF line endings did not drive "less" - intelligently when showing added or removed lines. - -* "git diff --dirstat -M" did not add changes in subdirectories up - correctly for renamed paths. - -* "git diff --cumulative" did not imply "--dirstat". - -* "git for-each-ref refs/heads/" did not work as expected. - -* "git gui" allowed users to feed patch without any context to be applied. - -* "git gui" botched parsing "diff" output when a line that begins with two - dashes and a space gets removed or a line that begins with two pluses - and a space gets added. - -* "git gui" translation updates and i18n fixes. - -* "git index-pack" is more careful against disk corruption while completing - a thin pack. - -* "git log -i --grep=pattern" did not ignore case; neither "git log -E - --grep=pattern" triggered extended regexp. - -* "git log --pretty="%ad" --date=short" did not use short format when - showing the timestamp. - -* "git log --author=author" match incorrectly matched with the - timestamp part of "author " line in commit objects. - -* "git log -F --author=author" did not work at all. - -* Build procedure for "git shell" that used stub versions of some - functions and globals was not understood by linkers on some platforms. - -* "git stash" was fooled by a stat-dirty but otherwise unmodified paths - and refused to work until the user refreshed the index. - -* "git svn" was broken on Perl before 5.8 with recent fixes to reduce - use of temporary files. - -* "git verify-pack -v" did not work correctly when given more than one - packfile. - -Also contains many documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.6.0.3.txt b/third_party/git/Documentation/RelNotes/1.6.0.3.txt deleted file mode 100644 index ae0577836a..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.0.3.txt +++ /dev/null @@ -1,117 +0,0 @@ -GIT v1.6.0.3 Release Notes -========================== - -Fixes since v1.6.0.2 --------------------- - -* "git archive --format=zip" did not honor core.autocrlf while - --format=tar did. - -* Continuing "git rebase -i" was very confused when the user left modified - files in the working tree while resolving conflicts. - -* Continuing "git rebase -i" was also very confused when the user left - some staged changes in the index after "edit". - -* "git rebase -i" now honors the pre-rebase hook, just like the - other rebase implementations "git rebase" and "git rebase -m". - -* "git rebase -i" incorrectly aborted when there is no commit to replay. - -* Behaviour of "git diff --quiet" was inconsistent with "diff --exit-code" - with the output redirected to /dev/null. - -* "git diff --no-index" on binary files no longer outputs a bogus - "diff --git" header line. - -* "git diff" hunk header patterns with multiple elements separated by LF - were not used correctly. - -* Hunk headers in "git diff" default to using extended regular - expressions, fixing some of the internal patterns on non-GNU - platforms. - -* New config "diff.*.xfuncname" exposes extended regular expressions - for user specified hunk header patterns. - -* "git gc" when ejecting otherwise unreachable objects from packfiles into - loose form leaked memory. - -* "git index-pack" was recently broken and mishandled objects added by - thin-pack completion processing under memory pressure. - -* "git index-pack" was recently broken and misbehaved when run from inside - .git/objects/pack/ directory. - -* "git stash apply sash@{1}" was fixed to error out. Prior versions - would have applied stash@{0} incorrectly. - -* "git stash apply" now offers a better suggestion on how to continue - if the working tree is currently dirty. - -* "git for-each-ref --format=%(subject)" fixed for commits with no - no newline in the message body. - -* "git remote" fixed to protect printf from user input. - -* "git remote show -v" now displays all URLs of a remote. - -* "git checkout -b branch" was confused when branch already existed. - -* "git checkout -q" once again suppresses the locally modified file list. - -* "git clone -q", "git fetch -q" asks remote side to not send - progress messages, actually making their output quiet. - -* Cross-directory renames are no longer used when creating packs. This - allows more graceful behavior on filesystems like sshfs. - -* Stale temporary files under $GIT_DIR/objects/pack are now cleaned up - automatically by "git prune". - -* "git merge" once again removes directories after the last file has - been removed from it during the merge. - -* "git merge" did not allocate enough memory for the structure itself when - enumerating the parents of the resulting commit. - -* "git blame -C -C" no longer segfaults while trying to pass blame if - it encounters a submodule reference. - -* "git rm" incorrectly claimed that you have local modifications when a - path was merely stat-dirty. - -* "git svn" fixed to display an error message when 'set-tree' failed, - instead of a Perl compile error. - -* "git submodule" fixed to handle checking out a different commit - than HEAD after initializing the submodule. - -* The "git commit" error message when there are still unmerged - files present was clarified to match "git write-tree". - -* "git init" was confused when core.bare or core.sharedRepository are set - in system or user global configuration file by mistake. When --bare or - --shared is given from the command line, these now override such - settings made outside the repositories. - -* Some segfaults due to uncaught NULL pointers were fixed in multiple - tools such as apply, reset, update-index. - -* Solaris builds now default to OLD_ICONV=1 to avoid compile warnings; - Solaris 8 does not define NEEDS_LIBICONV by default. - -* "Git.pm" tests relied on unnecessarily more recent version of Perl. - -* "gitweb" triggered undef warning on commits without log messages. - -* "gitweb" triggered undef warnings on missing trees. - -* "gitweb" now removes PATH_INFO from its URLs so users don't have - to manually set the URL in the gitweb configuration. - -* Bash completion removed support for legacy "git-fetch", "git-push" - and "git-pull" as these are no longer installed. Dashless form - ("git fetch") is still however supported. - -Many other documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.6.0.4.txt b/third_party/git/Documentation/RelNotes/1.6.0.4.txt deleted file mode 100644 index d522661d31..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.0.4.txt +++ /dev/null @@ -1,39 +0,0 @@ -GIT v1.6.0.4 Release Notes -========================== - -Fixes since v1.6.0.3 --------------------- - -* 'git add -p' said "No changes" when only binary files were changed. - -* 'git archive' did not work correctly in bare repositories. - -* 'git checkout -t -b newbranch' when you are on detached HEAD was broken. - -* when we refuse to detect renames because there are too many new or - deleted files, 'git diff' did not say how many there are. - -* 'git push --mirror' tried and failed to push the stash; there is no - point in sending it to begin with. - -* 'git push' did not update the remote tracking reference if the corresponding - ref on the remote end happened to be already up to date. - -* 'git pull $there $branch:$current_branch' did not work when you were on - a branch yet to be born. - -* when giving up resolving a conflicted merge, 'git reset --hard' failed - to remove new paths from the working tree. - -* 'git send-email' had a small fd leak while scanning directory. - -* 'git status' incorrectly reported a submodule directory as an untracked - directory. - -* 'git svn' used deprecated 'git-foo' form of subcommand invocation. - -* 'git update-ref -d' to remove a reference did not honor --no-deref option. - -* Plugged small memleaks here and there. - -* Also contains many documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.6.0.5.txt b/third_party/git/Documentation/RelNotes/1.6.0.5.txt deleted file mode 100644 index a08bb96738..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.0.5.txt +++ /dev/null @@ -1,56 +0,0 @@ -GIT v1.6.0.5 Release Notes -========================== - -Fixes since v1.6.0.4 --------------------- - -* "git checkout" used to crash when your HEAD was pointing at a deleted - branch. - -* "git checkout" from an un-checked-out state did not allow switching out - of the current branch. - -* "git diff" always allowed GIT_EXTERNAL_DIFF and --no-ext-diff was no-op for - the command. - -* Giving 3 or more tree-ish to "git diff" is supposed to show the combined - diff from second and subsequent trees to the first one, but the order was - screwed up. - -* "git fast-export" did not export all tags. - -* "git ls-files --with-tree=<tree>" did not work with options other - than -c, most notably with -m. - -* "git pack-objects" did not make its best effort to honor --max-pack-size - option when a single first object already busted the given limit and - placed many objects in a single pack. - -* "git-p4" fast import frontend was too eager to trigger its keyword expansion - logic, even on a keyword-looking string that does not have closing '$' on the - same line. - -* "git push $there" when the remote $there is defined in $GIT_DIR/branches/$there - behaves more like what cg-push from Cogito used to work. - -* when giving up resolving a conflicted merge, "git reset --hard" failed - to remove new paths from the working tree. - -* "git tag" did not complain when given mutually incompatible set of options. - -* The message constructed in the internal editor was discarded when "git - tag -s" failed to sign the message, which was often caused by the user - not configuring GPG correctly. - -* "make check" cannot be run without sparse; people may have meant to say - "make test" instead, so suggest that. - -* Internal diff machinery had a corner case performance bug that choked on - a large file with many repeated contents. - -* "git repack" used to grab objects out of packs marked with .keep - into a new pack. - -* Many unsafe call to sprintf() style varargs functions are corrected. - -* Also contains quite a few documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.6.0.6.txt b/third_party/git/Documentation/RelNotes/1.6.0.6.txt deleted file mode 100644 index 64ece1ffd5..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.0.6.txt +++ /dev/null @@ -1,33 +0,0 @@ -GIT v1.6.0.6 Release Notes -========================== - -Fixes since 1.6.0.5 -------------------- - - * "git fsck" had a deep recursion that wasted stack space. - - * "git fast-export" and "git fast-import" choked on an old style - annotated tag that lack the tagger information. - - * "git mergetool -- file" did not correctly skip "--" marker that - signals the end of options list. - - * "git show $tag" segfaulted when an annotated $tag pointed at a - nonexistent object. - - * "git show 2>error" when the standard output is automatically redirected - to the pager redirected the standard error to the pager as well; there - was no need to. - - * "git send-email" did not correctly handle list of addresses when - they had quoted comma (e.g. "Lastname, Givenname" <mail@addre.ss>). - - * Logic to discover branch ancestry in "git svn" was unreliable when - the process to fetch history was interrupted. - - * Removed support for an obsolete gitweb request URI, whose - implementation ran "git diff" Porcelain, instead of using plumbing, - which would have run an external diff command specified in the - repository configuration as the gitweb user. - -Also contains numerous documentation typofixes. diff --git a/third_party/git/Documentation/RelNotes/1.6.0.txt b/third_party/git/Documentation/RelNotes/1.6.0.txt deleted file mode 100644 index de7ef166b6..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.0.txt +++ /dev/null @@ -1,258 +0,0 @@ -GIT v1.6.0 Release Notes -======================== - -User visible changes --------------------- - -With the default Makefile settings, most of the programs are now -installed outside your $PATH, except for "git", "gitk" and -some server side programs that need to be accessible for technical -reasons. Invoking a git subcommand as "git-xyzzy" from the command -line has been deprecated since early 2006 (and officially announced in -1.5.4 release notes); use of them from your scripts after adding -output from "git --exec-path" to the $PATH is still supported in this -release, but users are again strongly encouraged to adjust their -scripts to use "git xyzzy" form, as we will stop installing -"git-xyzzy" hardlinks for built-in commands in later releases. - -An earlier change to page "git status" output was overwhelmingly unpopular -and has been reverted. - -Source changes needed for porting to MinGW environment are now all in the -main git.git codebase. - -By default, packfiles created with this version uses delta-base-offset -encoding introduced in v1.4.4. Pack idx files are using version 2 that -allows larger packs and added robustness thanks to its CRC checking, -introduced in v1.5.2 and v1.4.4.5. If you want to keep your repositories -backwards compatible past these versions, set repack.useDeltaBaseOffset -to false or pack.indexVersion to 1, respectively. - -We used to prevent sample hook scripts shipped in templates/ from -triggering by default by relying on the fact that we install them as -unexecutable, but on some filesystems, this approach does not work. -They are now shipped with ".sample" suffix. If you want to activate -any of these samples as-is, rename them to drop the ".sample" suffix, -instead of running "chmod +x" on them. For example, you can rename -hooks/post-update.sample to hooks/post-update to enable the sample -hook that runs update-server-info, in order to make repositories -friendly to dumb protocols (i.e. HTTP). - -GIT_CONFIG, which was only documented as affecting "git config", but -actually affected all git commands, now only affects "git config". -GIT_LOCAL_CONFIG, also only documented as affecting "git config" and -not different from GIT_CONFIG in a useful way, is removed. - -The ".dotest" temporary area "git am" and "git rebase" use is now moved -inside the $GIT_DIR, to avoid mistakes of adding it to the project by -accident. - -An ancient merge strategy "stupid" has been removed. - - -Updates since v1.5.6 --------------------- - -(subsystems) - -* git-p4 in contrib learned "allowSubmit" configuration to control on - which branch to allow "submit" subcommand. - -* git-gui learned to stage changes per-line. - -(portability) - -* Changes for MinGW port have been merged, thanks to Johannes Sixt and - gangs. - -* Sample hook scripts shipped in templates/ are now suffixed with - *.sample. - -* perl's in-place edit (-i) does not work well without backup files on Windows; - some tests are rewritten to cope with this. - -(documentation) - -* Updated howto/update-hook-example - -* Got rid of usage of "git-foo" from the tutorial and made typography - more consistent. - -* Disambiguating "--" between revs and paths is finally documented. - -(performance, robustness, sanity etc.) - -* index-pack used too much memory when dealing with a deep delta chain. - This has been optimized. - -* reduced excessive inlining to shrink size of the "git" binary. - -* verify-pack checks the object CRC when using version 2 idx files. - -* When an object is corrupt in a pack, the object became unusable even - when the same object is available in a loose form, We now try harder to - fall back to these redundant objects when able. In particular, "git - repack -a -f" can be used to fix such a corruption as long as necessary - objects are available. - -* Performance of "git-blame -C -C" operation is vastly improved. - -* git-clone does not create refs in loose form anymore (it behaves as - if you immediately ran git-pack-refs after cloning). This will help - repositories with insanely large number of refs. - -* core.fsyncobjectfiles configuration can be used to ensure that the loose - objects created will be fsync'ed (this is only useful on filesystems - that does not order data writes properly). - -* "git commit-tree" plumbing can make Octopus with more than 16 parents. - "git commit" has been capable of this for quite some time. - -(usability, bells and whistles) - -* even more documentation pages are now accessible via "man" and "git help". - -* A new environment variable GIT_CEILING_DIRECTORIES can be used to stop - the discovery process of the toplevel of working tree; this may be useful - when you are working in a slow network disk and are outside any working tree, - as bash-completion and "git help" may still need to run in these places. - -* By default, stash entries never expire. Set reflogexpire in [gc - "refs/stash"] to a reasonable value to get traditional auto-expiration - behaviour back - -* Longstanding latency issue with bash completion script has been - addressed. This will need to be backmerged to 'maint' later. - -* pager.<cmd> configuration variable can be used to enable/disable the - default paging behaviour per command. - -* "git-add -i" has a new action 'e/dit' to allow you edit the patch hunk - manually. - -* git-am records the original tip of the branch in ORIG_HEAD before it - starts applying patches. - -* git-apply can handle a patch that touches the same path more than once - much better than before. - -* git-apply can be told not to trust the line counts recorded in the input - patch but recount, with the new --recount option. - -* git-apply can be told to apply a patch to a path deeper than what the - patch records with --directory option. - -* git-archive can be told to omit certain paths from its output using - export-ignore attributes. - -* git-archive uses the zlib default compression level when creating - zip archive. - -* git-archive's command line options --exec and --remote can take their - parameters as separate command line arguments, similar to other commands. - IOW, both "--exec=path" and "--exec path" are now supported. - -* With -v option, git-branch describes the remote tracking statistics - similar to the way git-checkout reports by how many commits your branch - is ahead/behind. - -* git-branch's --contains option used to always require a commit parameter - to limit the branches with; it now defaults to list branches that - contains HEAD if this parameter is omitted. - -* git-branch's --merged and --no-merged option used to always limit the - branches relative to the HEAD, but they can now take an optional commit - argument that is used in place of HEAD. - -* git-bundle can read the revision arguments from the standard input. - -* git-cherry-pick can replay a root commit now. - -* git-clone can clone from a remote whose URL would be rewritten by - configuration stored in $HOME/.gitconfig now. - -* "git-clone --mirror" is a handy way to set up a bare mirror repository. - -* git-cvsserver learned to respond to "cvs co -c". - -* git-diff --check now checks leftover merge conflict markers. - -* "git-diff -p" learned to grab a better hunk header lines in - BibTex, Pascal/Delphi, and Ruby files and also pays attention to - chapter and part boundary in TeX documents. - -* When remote side used to have branch 'foo' and git-fetch finds that now - it has branch 'foo/bar', it refuses to lose the existing remote tracking - branch and its reflog. The error message has been improved to suggest - pruning the remote if the user wants to proceed and get the latest set - of branches from the remote, including such 'foo/bar'. - -* fast-export learned to export and import marks file; this can be used to - interface with fast-import incrementally. - -* fast-import and fast-export learned to export and import gitlinks. - -* "gitk" left background process behind after being asked to dig very deep - history and the user killed the UI; the process is killed when the UI goes - away now. - -* git-rebase records the original tip of branch in ORIG_HEAD before it is - rewound. - -* "git rerere" can be told to update the index with auto-reused resolution - with rerere.autoupdate configuration variable. - -* git-rev-parse learned $commit^! and $commit^@ notations used in "log" - family. These notations are available in gitk as well, because the gitk - command internally uses rev-parse to interpret its arguments. - -* git-rev-list learned --children option to show child commits it - encountered during the traversal, instead of showing parent commits. - -* git-send-mail can talk not just over SSL but over TLS now. - -* git-shortlog honors custom output format specified with "--pretty=format:". - -* "git-stash save" learned --keep-index option. This lets you stash away the - local changes and bring the changes staged in the index to your working - tree for examination and testing. - -* git-stash also learned branch subcommand to create a new branch out of - stashed changes. - -* git-status gives the remote tracking statistics similar to the way - git-checkout reports by how many commits your branch is ahead/behind. - -* "git-svn dcommit" is now aware of auto-props setting the subversion user - has. - -* You can tell "git status -u" to even more aggressively omit checking - untracked files with --untracked-files=no. - -* Original SHA-1 value for "update-ref -d" is optional now. - -* Error codes from gitweb are made more descriptive where possible, rather - than "403 forbidden" as we used to issue everywhere. - -(internal) - -* git-merge has been reimplemented in C. - - -Fixes since v1.5.6 ------------------- - -All of the fixes in v1.5.6 maintenance series are included in -this release, unless otherwise noted. - - * git-clone ignored its -u option; the fix needs to be backported to - 'maint'; - - * git-mv used to lose the distinction between changes that are staged - and that are only in the working tree, by staging both in the index - after moving such a path. - - * "git-rebase -i -p" rewrote the parents to wrong ones when amending - (either edit or squash) was involved, and did not work correctly - when fast forwarding. - diff --git a/third_party/git/Documentation/RelNotes/1.6.1.1.txt b/third_party/git/Documentation/RelNotes/1.6.1.1.txt deleted file mode 100644 index 8c594ba02f..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.1.1.txt +++ /dev/null @@ -1,59 +0,0 @@ -GIT v1.6.1.1 Release Notes -========================== - -Fixes since v1.6.1 ------------------- - -* "git add frotz/nitfol" when "frotz" is a submodule should have errored - out, but it didn't. - -* "git apply" took file modes from the patch text and updated the mode - bits of the target tree even when the patch was not about mode changes. - -* "git bisect view" on Cygwin did not launch gitk - -* "git checkout $tree" did not trigger an error. - -* "git commit" tried to remove COMMIT_EDITMSG from the work tree by mistake. - -* "git describe --all" complained when a commit is described with a tag, - which was nonsense. - -* "git diff --no-index --" did not trigger no-index (aka "use git-diff as - a replacement of diff on untracked files") behaviour. - -* "git format-patch -1 HEAD" on a root commit failed to produce patch - text. - -* "git fsck branch" did not work as advertised; instead it behaved the same - way as "git fsck". - -* "git log --pretty=format:%s" did not handle a multi-line subject the - same way as built-in log listers (i.e. shortlog, --pretty=oneline, etc.) - -* "git daemon", and "git merge-file" are more careful when freopen fails - and barf, instead of going on and writing to unopened filehandle. - -* "git http-push" did not like some RFC 4918 compliant DAV server - responses. - -* "git merge -s recursive" mistakenly overwritten an untracked file in the - work tree upon delete/modify conflict. - -* "git merge -s recursive" didn't leave the index unmerged for entries with - rename/delete conflicts. - -* "git merge -s recursive" clobbered untracked files in the work tree. - -* "git mv -k" with more than one erroneous paths misbehaved. - -* "git read-tree -m -u" hence branch switching incorrectly lost a - subdirectory in rare cases. - -* "git rebase -i" issued an unnecessary error message upon a user error of - marking the first commit to be "squash"ed. - -* "git shortlog" did not format a commit message with multi-line - subject correctly. - -Many documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.6.1.2.txt b/third_party/git/Documentation/RelNotes/1.6.1.2.txt deleted file mode 100644 index be37cbb858..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.1.2.txt +++ /dev/null @@ -1,39 +0,0 @@ -GIT v1.6.1.2 Release Notes -========================== - -Fixes since v1.6.1.1 --------------------- - -* The logic for rename detection in internal diff used by commands like - "git diff" and "git blame" has been optimized to avoid loading the same - blob repeatedly. - -* We did not allow writing out a blob that is larger than 2GB for no good - reason. - -* "git format-patch -o $dir", when $dir is a relative directory, used it - as relative to the root of the work tree, not relative to the current - directory. - -* v1.6.1 introduced an optimization for "git push" into a repository (A) - that borrows its objects from another repository (B) to avoid sending - objects that are available in repository B, when they are not yet used - by repository A. However the code on the "git push" sender side was - buggy and did not work when repository B had new objects that are not - known by the sender. This caused pushing into a "forked" repository - served by v1.6.1 software using "git push" from v1.6.1 sometimes did not - work. The bug was purely on the "git push" sender side, and has been - corrected. - -* "git status -v" did not paint its diff output in colour even when - color.ui configuration was set. - -* "git ls-tree" learned --full-tree option to help Porcelain scripts that - want to always see the full path regardless of the current working - directory. - -* "git grep" incorrectly searched in work tree paths even when they are - marked as assume-unchanged. It now searches in the index entries. - -* "git gc" with no grace period needlessly ejected packed but unreachable - objects in their loose form, only to delete them right away. diff --git a/third_party/git/Documentation/RelNotes/1.6.1.3.txt b/third_party/git/Documentation/RelNotes/1.6.1.3.txt deleted file mode 100644 index cd08d8174e..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.1.3.txt +++ /dev/null @@ -1,28 +0,0 @@ -GIT v1.6.1.3 Release Notes -========================== - -Fixes since v1.6.1.2 --------------------- - -* "git diff --binary | git apply" pipeline did not work well when - a binary blob is changed to a symbolic link. - -* Some combinations of -b/-w/--ignore-space-at-eol to "git diff" did - not work as expected. - -* "git grep" did not pass the -I (ignore binary) option when - calling out an external grep program. - -* "git log" and friends include HEAD to the set of starting points - when --all is given. This makes a difference when you are not - on any branch. - -* "git mv" to move an untracked file to overwrite a tracked - contents misbehaved. - -* "git merge -s octopus" with many potential merge bases did not - work correctly. - -* RPM binary package installed the html manpages in a wrong place. - -Also includes minor documentation fixes and updates. diff --git a/third_party/git/Documentation/RelNotes/1.6.1.4.txt b/third_party/git/Documentation/RelNotes/1.6.1.4.txt deleted file mode 100644 index ccbad794c0..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.1.4.txt +++ /dev/null @@ -1,41 +0,0 @@ -GIT v1.6.1.4 Release Notes -========================== - -Fixes since v1.6.1.3 --------------------- - -* .gitignore learned to handle backslash as a quoting mechanism for - comment introduction character "#". - This fix was first merged to 1.6.2.1. - -* "git fast-export" produced wrong output with some parents missing from - commits, when the history is clock-skewed. - -* "git fast-import" sometimes failed to read back objects it just wrote - out and aborted, because it failed to flush stale cached data. - -* "git-ls-tree" and "git-diff-tree" used a pathspec correctly when - deciding to descend into a subdirectory but they did not match the - individual paths correctly. This caused pathspecs "abc/d ab" to match - "abc/0" ("abc/d" made them decide to descend into the directory "abc/", - and then "ab" incorrectly matched "abc/0" when it shouldn't). - This fix was first merged to 1.6.2.3. - -* import-zips script (in contrib) did not compute the common directory - prefix correctly. - This fix was first merged to 1.6.2.2. - -* "git init" segfaulted when given an overlong template location via - the --template= option. - This fix was first merged to 1.6.2.4. - -* "git repack" did not error out when necessary object was missing in the - repository. - -* git-repack (invoked from git-gc) did not work as nicely as it should in - a repository that borrows objects from neighbours via alternates - mechanism especially when some packs are marked with the ".keep" flag - to prevent them from being repacked. - This fix was first merged to 1.6.2.3. - -Also includes minor documentation fixes and updates. diff --git a/third_party/git/Documentation/RelNotes/1.6.1.txt b/third_party/git/Documentation/RelNotes/1.6.1.txt deleted file mode 100644 index 7b152a6fdc..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.1.txt +++ /dev/null @@ -1,280 +0,0 @@ -GIT v1.6.1 Release Notes -======================== - -Updates since v1.6.0 --------------------- - -When some commands (e.g. "git log", "git diff") spawn pager internally, we -used to make the pager the parent process of the git command that produces -output. This meant that the exit status of the whole thing comes from the -pager, not the underlying git command. We swapped the order of the -processes around and you will see the exit code from the command from now -on. - -(subsystems) - -* gitk can call out to git-gui to view "git blame" output; git-gui in turn - can run gitk from its blame view. - -* Various git-gui updates including updated translations. - -* Various gitweb updates from repo.or.cz installation. - -* Updates to emacs bindings. - -(portability) - -* A few test scripts used nonportable "grep" that did not work well on - some platforms, e.g. Solaris. - -* Sample pre-auto-gc script has OS X support. - -* Makefile has support for (ancient) FreeBSD 4.9. - -(performance) - -* Many operations that are lstat(3) heavy can be told to pre-execute - necessary lstat(3) in parallel before their main operations, which - potentially gives much improved performance for cold-cache cases or in - environments with weak metadata caching (e.g. NFS). - -* The underlying diff machinery to produce textual output has been - optimized, which would result in faster "git blame" processing. - -* Most of the test scripts (but not the ones that try to run servers) - can be run in parallel. - -* Bash completion of refnames in a repository with massive number of - refs has been optimized. - -* Cygwin port uses native stat/lstat implementations when applicable, - which leads to improved performance. - -* "git push" pays attention to alternate repositories to avoid sending - unnecessary objects. - -* "git svn" can rebuild an out-of-date rev_map file. - -(usability, bells and whistles) - -* When you mistype a command name, git helpfully suggests what it guesses - you might have meant to say. help.autocorrect configuration can be set - to a non-zero value to accept the suggestion when git can uniquely - guess. - -* The packfile machinery hopefully is more robust when dealing with - corrupt packs if redundant objects involved in the corruption are - available elsewhere. - -* "git add -N path..." adds the named paths as an empty blob, so that - subsequent "git diff" will show a diff as if they are creation events. - -* "git add" gained a built-in synonym for people who want to say "stage - changes" instead of "add contents to the staging area" which amounts - to the same thing. - -* "git apply" learned --include=paths option, similar to the existing - --exclude=paths option. - -* "git bisect" is careful about a user mistake and suggests testing of - merge base first when good is not a strict ancestor of bad. - -* "git bisect skip" can take a range of commits. - -* "git blame" re-encodes the commit metainfo to UTF-8 from i18n.commitEncoding - by default. - -* "git check-attr --stdin" can check attributes for multiple paths. - -* "git checkout --track origin/hack" used to be a syntax error. It now - DWIMs to create a corresponding local branch "hack", i.e. acts as if you - said "git checkout --track -b hack origin/hack". - -* "git checkout --ours/--theirs" can be used to check out one side of a - conflicting merge during conflict resolution. - -* "git checkout -m" can be used to recreate the initial conflicted state - during conflict resolution. - -* "git cherry-pick" can also utilize rerere for conflict resolution. - -* "git clone" learned to be verbose with -v - -* "git commit --author=$name" can look up author name from existing - commits. - -* output from "git commit" has been reworded in a more concise and yet - more informative way. - -* "git count-objects" reports the on-disk footprint for packfiles and - their corresponding idx files. - -* "git daemon" learned --max-connections=<count> option. - -* "git daemon" exports REMOTE_ADDR to record client address, so that - spawned programs can act differently on it. - -* "git describe --tags" favours closer lightweight tags than farther - annotated tags now. - -* "git diff" learned to mimic --suppress-blank-empty from GNU diff via a - configuration option. - -* "git diff" learned to put more sensible hunk headers for Python, - HTML and ObjC contents. - -* "git diff" learned to vary the a/ vs b/ prefix depending on what are - being compared, controlled by diff.mnemonicprefix configuration. - -* "git diff" learned --dirstat-by-file to count changed files, not number - of lines, when summarizing the global picture. - -* "git diff" learned "textconv" filters --- a binary or hard-to-read - contents can be munged into human readable form and the difference - between the results of the conversion can be viewed (obviously this - cannot produce a patch that can be applied, so this is disabled in - format-patch among other things). - -* "--cached" option to "git diff has an easier to remember synonym "--staged", - to ask "what is the difference between the given commit and the - contents staged in the index?" - -* "git for-each-ref" learned "refname:short" token that gives an - unambiguously abbreviated refname. - -* Auto-numbering of the subject lines is the default for "git - format-patch" now. - -* "git grep" learned to accept -z similar to GNU grep. - -* "git help" learned to use GIT_MAN_VIEWER environment variable before - using "man" program. - -* "git imap-send" can optionally talk SSL. - -* "git index-pack" is more careful against disk corruption while - completing a thin pack. - -* "git log --check" and "git log --exit-code" passes their underlying diff - status with their exit status code. - -* "git log" learned --simplify-merges, a milder variant of --full-history; - "gitk --simplify-merges" is easier to view than with --full-history. - -* "git log" learned "--source" to show what ref each commit was reached - from. - -* "git log" also learned "--simplify-by-decoration" to show the - birds-eye-view of the topology of the history. - -* "git log --pretty=format:" learned "%d" format element that inserts - names of tags that point at the commit. - -* "git merge --squash" and "git merge --no-ff" into an unborn branch are - noticed as user errors. - -* "git merge -s $strategy" can use a custom built strategy if you have a - command "git-merge-$strategy" on your $PATH. - -* "git pull" (and "git fetch") can be told to operate "-v"erbosely or - "-q"uietly. - -* "git push" can be told to reject deletion of refs with receive.denyDeletes - configuration. - -* "git rebase" honours pre-rebase hook; use --no-verify to bypass it. - -* "git rebase -p" uses interactive rebase machinery now to preserve the merges. - -* "git reflog expire branch" can be used in place of "git reflog expire - refs/heads/branch". - -* "git remote show $remote" lists remote branches one-per-line now. - -* "git send-email" can be given revision range instead of files and - maildirs on the command line, and automatically runs format-patch to - generate patches for the given revision range. - -* "git submodule foreach" subcommand allows you to iterate over checked - out submodules. - -* "git submodule sync" subcommands allows you to update the origin URL - recorded in submodule directories from the toplevel .gitmodules file. - -* "git svn branch" can create new branches on the other end. - -* "gitweb" can use more saner PATH_INFO based URL. - -(internal) - -* "git hash-object" learned to lie about the path being hashed, so that - correct gitattributes processing can be done while hashing contents - stored in a temporary file. - -* various callers of git-merge-recursive avoid forking it as an external - process. - -* Git class defined in "Git.pm" can be subclasses a bit more easily. - -* We used to link GNU regex library as a compatibility layer for some - platforms, but it turns out it is not necessary on most of them. - -* Some path handling routines used fixed number of buffers used alternately - but depending on the call depth, this arrangement led to hard to track - bugs. This issue is being addressed. - - -Fixes since v1.6.0 ------------------- - -All of the fixes in v1.6.0.X maintenance series are included in this -release, unless otherwise noted. - -* Porcelains implemented as shell scripts were utterly confused when you - entered to a subdirectory of a work tree from sideways, following a - symbolic link (this may need to be backported to older releases later). - -* Tracking symbolic links would work better on filesystems whose lstat() - returns incorrect st_size value for them. - -* "git add" and "git update-index" incorrectly allowed adding S/F when S - is a tracked symlink that points at a directory D that has a path F in - it (we still need to fix a similar nonsense when S is a submodule and F - is a path in it). - -* "git am" after stopping at a broken patch lost --whitespace, -C, -p and - --3way options given from the command line initially. - -* "git diff --stdin" used to take two trees on a line and compared them, - but we dropped support for such a use case long time ago. This has - been resurrected. - -* "git filter-branch" failed to rewrite a tag name with slashes in it. - -* "git http-push" did not understand URI scheme other than opaquelocktoken - when acquiring a lock from the server (this may need to be backported to - older releases later). - -* After "git rebase -p" stopped with conflicts while replaying a merge, - "git rebase --continue" did not work (may need to be backported to older - releases). - -* "git revert" records relative to which parent a revert was made when - reverting a merge. Together with new documentation that explains issues - around reverting a merge and merging from the updated branch later, this - hopefully will reduce user confusion (this may need to be backported to - older releases later). - -* "git rm --cached" used to allow an empty blob that was added earlier to - be removed without --force, even when the file in the work tree has - since been modified. - -* "git push --tags --all $there" failed with generic usage message without - telling saying these two options are incompatible. - -* "git log --author/--committer" match used to potentially match the - timestamp part, exposing internal implementation detail. Also these did - not work with --fixed-strings match at all. - -* "gitweb" did not mark non-ASCII characters imported from external HTML fragments - correctly. diff --git a/third_party/git/Documentation/RelNotes/1.6.2.1.txt b/third_party/git/Documentation/RelNotes/1.6.2.1.txt deleted file mode 100644 index dfa36416af..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.2.1.txt +++ /dev/null @@ -1,19 +0,0 @@ -GIT v1.6.2.1 Release Notes -========================== - -Fixes since v1.6.2 ------------------- - -* .gitignore learned to handle backslash as a quoting mechanism for - comment introduction character "#". - -* timestamp output in --date=relative mode used to display timestamps that - are long time ago in the default mode; it now uses "N years M months - ago", and "N years ago". - -* git-add -i/-p now works with non-ASCII pathnames. - -* "git hash-object -w" did not read from the configuration file from the - correct .git directory. - -* git-send-email learned to correctly handle multiple Cc: addresses. diff --git a/third_party/git/Documentation/RelNotes/1.6.2.2.txt b/third_party/git/Documentation/RelNotes/1.6.2.2.txt deleted file mode 100644 index fafa9986b0..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.2.2.txt +++ /dev/null @@ -1,45 +0,0 @@ -GIT v1.6.2.2 Release Notes -========================== - -Fixes since v1.6.2.1 --------------------- - -* A longstanding confusing description of what --pickaxe option of - git-diff does has been clarified in the documentation. - -* "git-blame -S" did not quite work near the commits that were given - on the command line correctly. - -* "git diff --pickaxe-regexp" did not count overlapping matches - correctly. - -* "git diff" did not feed files in work-tree representation to external - diff and textconv. - -* "git-fetch" in a repository that was not cloned from anywhere said - it cannot find 'origin', which was hard to understand for new people. - -* "git-format-patch --numbered-files --stdout" did not have to die of - incompatible options; it now simply ignores --numbered-files as no files - are produced anyway. - -* "git-ls-files --deleted" did not work well with GIT_DIR&GIT_WORK_TREE. - -* "git-read-tree A B C..." without -m option has been broken for a long - time. - -* git-send-email ignored --in-reply-to when --no-thread was given. - -* 'git-submodule add' did not tolerate extra slashes and ./ in the path it - accepted from the command line; it now is more lenient. - -* git-svn misbehaved when the project contained a path that began with - two dashes. - -* import-zips script (in contrib) did not compute the common directory - prefix correctly. - -* miscompilation of negated enum constants by old gcc (2.9) affected the - codepaths to spawn subprocesses. - -Many small documentation updates are included as well. diff --git a/third_party/git/Documentation/RelNotes/1.6.2.3.txt b/third_party/git/Documentation/RelNotes/1.6.2.3.txt deleted file mode 100644 index 4d3c1ac91c..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.2.3.txt +++ /dev/null @@ -1,22 +0,0 @@ -GIT v1.6.2.3 Release Notes -========================== - -Fixes since v1.6.2.2 --------------------- - -* Setting an octal mode value to core.sharedrepository configuration to - restrict access to the repository to group members did not work as - advertised. - -* A fairly large and trivial memory leak while rev-list shows list of - reachable objects has been identified and plugged. - -* "git-commit --interactive" did not abort when underlying "git-add -i" - signaled a failure. - -* git-repack (invoked from git-gc) did not work as nicely as it should in - a repository that borrows objects from neighbours via alternates - mechanism especially when some packs are marked with the ".keep" flag - to prevent them from being repacked. - -Many small documentation updates are included as well. diff --git a/third_party/git/Documentation/RelNotes/1.6.2.4.txt b/third_party/git/Documentation/RelNotes/1.6.2.4.txt deleted file mode 100644 index f4bf1d0986..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.2.4.txt +++ /dev/null @@ -1,39 +0,0 @@ -GIT v1.6.2.4 Release Notes -========================== - -Fixes since v1.6.2.3 --------------------- - -* The configuration parser had a buffer overflow while parsing an overlong - value. - -* pruning reflog entries that are unreachable from the tip of the ref - during "git reflog prune" (hence "git gc") was very inefficient. - -* "git-add -p" lacked a way to say "q"uit to refuse staging any hunks for - the remaining paths. You had to say "d" and then ^C. - -* "git-checkout <tree-ish> <submodule>" did not update the index entry at - the named path; it now does. - -* "git-fast-export" choked when seeing a tag that does not point at commit. - -* "git init" segfaulted when given an overlong template location via - the --template= option. - -* "git-ls-tree" and "git-diff-tree" used a pathspec correctly when - deciding to descend into a subdirectory but they did not match the - individual paths correctly. This caused pathspecs "abc/d ab" to match - "abc/0" ("abc/d" made them decide to descend into the directory "abc/", - and then "ab" incorrectly matched "abc/0" when it shouldn't). - -* "git-merge-recursive" was broken when a submodule entry was involved in - a criss-cross merge situation. - -Many small documentation updates are included as well. - ---- -exec >/var/tmp/1 -echo O=$(git describe maint) -O=v1.6.2.3-38-g318b847 -git shortlog --no-merges $O..maint diff --git a/third_party/git/Documentation/RelNotes/1.6.2.5.txt b/third_party/git/Documentation/RelNotes/1.6.2.5.txt deleted file mode 100644 index b23f9e95d1..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.2.5.txt +++ /dev/null @@ -1,21 +0,0 @@ -GIT v1.6.2.5 Release Notes -========================== - -Fixes since v1.6.2.4 --------------------- - -* "git apply" mishandled if you fed a git generated patch that renames - file A to B and file B to A at the same time. - -* "git diff -c -p" (and "diff --cc") did not expect to see submodule - differences and instead refused to work. - -* "git grep -e '('" segfaulted, instead of diagnosing a mismatched - parentheses error. - -* "git fetch" generated packs with offset-delta encoding when both ends of - the connection are capable of producing one; this cannot be read by - ancient git and the user should be able to disable this by setting - repack.usedeltabaseoffset configuration to false. - - diff --git a/third_party/git/Documentation/RelNotes/1.6.2.txt b/third_party/git/Documentation/RelNotes/1.6.2.txt deleted file mode 100644 index ad060f4f89..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.2.txt +++ /dev/null @@ -1,164 +0,0 @@ -GIT v1.6.2 Release Notes -======================== - -With the next major release, "git push" into a branch that is -currently checked out will be refused by default. You can choose -what should happen upon such a push by setting the configuration -variable receive.denyCurrentBranch in the receiving repository. - -To ease the transition plan, the receiving repository of such a -push running this release will issue a big warning when the -configuration variable is missing. Please refer to: - - http://git.or.cz/gitwiki/GitFaq#non-bare - http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 - -for more details on the reason why this change is needed and the -transition plan. - -For a similar reason, "git push $there :$killed" to delete the branch -$killed in a remote repository $there, if $killed branch is the current -branch pointed at by its HEAD, gets a large warning. You can choose what -should happen upon such a push by setting the configuration variable -receive.denyDeleteCurrent in the receiving repository. - - -Updates since v1.6.1 --------------------- - -(subsystems) - -* git-svn updates. - -* gitweb updates, including a new patch view and RSS/Atom feed - improvements. - -* (contrib/emacs) git.el now has commands for checking out a branch, - creating a branch, cherry-picking and reverting commits; vc-git.el - is not shipped with git anymore (it is part of official Emacs). - -(performance) - -* pack-objects autodetects the number of CPUs available and uses threaded - version. - -(usability, bells and whistles) - -* automatic typo correction works on aliases as well - -* @{-1} is a way to refer to the last branch you were on. This is - accepted not only where an object name is expected, but anywhere - a branch name is expected and acts as if you typed the branch name. - E.g. "git branch --track mybranch @{-1}", "git merge @{-1}", and - "git rev-parse --symbolic-full-name @{-1}" would work as expected. - -* When refs/remotes/origin/HEAD points at a remote tracking branch that - has been pruned away, many git operations issued warning when they - internally enumerated the refs. We now warn only when you say "origin" - to refer to that pruned branch. - -* The location of .mailmap file can be configured, and its file format was - enhanced to allow mapping an incorrect e-mail field as well. - -* "git add -p" learned 'g'oto action to jump directly to a hunk. - -* "git add -p" learned to find a hunk with given text with '/'. - -* "git add -p" optionally can be told to work with just the command letter - without Enter. - -* when "git am" stops upon a patch that does not apply, it shows the - title of the offending patch. - -* "git am --directory=<dir>" and "git am --reject" passes these options - to underlying "git apply". - -* "git am" learned --ignore-date option. - -* "git blame" aligns author names better when they are spelled in - non US-ASCII encoding. - -* "git clone" now makes its best effort when cloning from an empty - repository to set up configuration variables to refer to the remote - repository. - -* "git checkout -" is a shorthand for "git checkout @{-1}". - -* "git cherry" defaults to whatever the current branch is tracking (if - exists) when the <upstream> argument is not given. - -* "git cvsserver" can be told not to add extra "via git-CVS emulator" to - the commit log message it serves via gitcvs.commitmsgannotation - configuration. - -* "git cvsserver" learned to handle 'noop' command some CVS clients seem - to expect to work. - -* "git diff" learned a new option --inter-hunk-context to coalesce close - hunks together and show context between them. - -* The definition of what constitutes a word for "git diff --color-words" - can be customized via gitattributes, command line or a configuration. - -* "git diff" learned --patience to run "patience diff" algorithm. - -* "git filter-branch" learned --prune-empty option that discards commits - that do not change the contents. - -* "git fsck" now checks loose objects in alternate object stores, instead - of misreporting them as missing. - -* "git gc --prune" was resurrected to allow "git gc --no-prune" and - giving non-default expiration period e.g. "git gc --prune=now". - -* "git grep -w" and "git grep" for fixed strings have been optimized. - -* "git mergetool" learned -y(--no-prompt) option to disable prompting. - -* "git rebase -i" can transplant a history down to root to elsewhere - with --root option. - -* "git reset --merge" is a new mode that works similar to the way - "git checkout" switches branches, taking the local changes while - switching to another commit. - -* "git submodule update" learned --no-fetch option. - -* "git tag" learned --contains that works the same way as the same option - from "git branch". - - -Fixes since v1.6.1 ------------------- - -All of the fixes in v1.6.1.X maintenance series are included in this -release, unless otherwise noted. - -Here are fixes that this release has, but have not been backported to -v1.6.1.X series. - -* "git-add sub/file" when sub is a submodule incorrectly added the path to - the superproject. - -* "git bundle" did not exclude annotated tags even when a range given - from the command line wanted to. - -* "git filter-branch" unnecessarily refused to work when you had - checked out a different commit from what is recorded in the superproject - index in a submodule. - -* "git filter-branch" incorrectly tried to update a nonexistent work tree - at the end when it is run in a bare repository. - -* "git gc" did not work if your repository was created with an ancient git - and never had any pack files in it before. - -* "git mergetool" used to ignore autocrlf and other attributes - based content rewriting. - -* branch switching and merges had a silly bug that did not validate - the correct directory when making sure an existing subdirectory is - clean. - -* "git -p cmd" when cmd is not a built-in one left the display in funny state - when killed in the middle. diff --git a/third_party/git/Documentation/RelNotes/1.6.3.1.txt b/third_party/git/Documentation/RelNotes/1.6.3.1.txt deleted file mode 100644 index 2400b72ef7..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.3.1.txt +++ /dev/null @@ -1,10 +0,0 @@ -GIT v1.6.3.1 Release Notes -========================== - -Fixes since v1.6.3 ------------------- - -* "git checkout -b new-branch" with a staged change in the index - incorrectly primed the in-index cache-tree, resulting a wrong tree - object to be written out of the index. This is a grave regression - since the last 1.6.2.X maintenance release. diff --git a/third_party/git/Documentation/RelNotes/1.6.3.2.txt b/third_party/git/Documentation/RelNotes/1.6.3.2.txt deleted file mode 100644 index b2f3f0293c..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.3.2.txt +++ /dev/null @@ -1,61 +0,0 @@ -GIT v1.6.3.2 Release Notes -========================== - -Fixes since v1.6.3.1 --------------------- - - * A few codepaths picked up the first few bytes from an sha1[] by - casting the (char *) pointer to (int *); GCC 4.4 did not like this, - and aborted compilation. - - * Some unlink(2) failures went undiagnosed. - - * The "recursive" merge strategy misbehaved when faced rename/delete - conflicts while coming up with an intermediate merge base. - - * The low-level merge algorithm did not handle a degenerate case of - merging a file with itself using itself as the common ancestor - gracefully. It should produce the file itself, but instead - produced an empty result. - - * GIT_TRACE mechanism segfaulted when tracing a shell-quoted aliases. - - * OpenBSD also uses st_ctimspec in "struct stat", instead of "st_ctim". - - * With NO_CROSS_DIRECTORY_HARDLINKS, "make install" can be told not to - create hardlinks between $(gitexecdir)/git-$builtin_commands and - $(bindir)/git. - - * command completion code in bash did not reliably detect that we are - in a bare repository. - - * "git add ." in an empty directory complained that pathspec "." did not - match anything, which may be technically correct, but not useful. We - silently make it a no-op now. - - * "git add -p" (and "patch" action in "git add -i") was broken when - the first hunk that adds a line at the top was split into two and - both halves are marked to be used. - - * "git blame path" misbehaved at the commit where path became file - from a directory with some files in it. - - * "git for-each-ref" had a segfaulting bug when dealing with a tag object - created by an ancient git. - - * "git format-patch -k" still added patch numbers if format.numbered - configuration was set. - - * "git grep --color ''" did not terminate. The command also had - subtle bugs with its -w option. - - * http-push had a small use-after-free bug. - - * "git push" was converting OFS_DELTA pack representation into less - efficient REF_DELTA representation unconditionally upon transfer, - making the transferred data unnecessarily larger. - - * "git remote show origin" segfaulted when origin was still empty. - -Many other general usability updates around help text, diagnostic messages -and documentation are included as well. diff --git a/third_party/git/Documentation/RelNotes/1.6.3.3.txt b/third_party/git/Documentation/RelNotes/1.6.3.3.txt deleted file mode 100644 index 1c28398bb6..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.3.3.txt +++ /dev/null @@ -1,38 +0,0 @@ -GIT v1.6.3.3 Release Notes -========================== - -Fixes since v1.6.3.2 --------------------- - - * "git archive" running on Cygwin can get stuck in an infinite loop. - - * "git daemon" did not correctly parse the initial line that carries - virtual host request information. - - * "git diff --textconv" leaked memory badly when the textconv filter - errored out. - - * The built-in regular expressions to pick function names to put on - hunk header lines for java and objc were very inefficiently written. - - * in certain error situations git-fetch (and git-clone) on Windows didn't - detect connection abort and ended up waiting indefinitely. - - * import-tars script (in contrib) did not import symbolic links correctly. - - * http.c used CURLOPT_SSLKEY even on libcURL version 7.9.2, even though - it was only available starting 7.9.3. - - * low-level filelevel merge driver used return value from strdup() - without checking if we ran out of memory. - - * "git rebase -i" left stray closing parenthesis in its reflog message. - - * "git remote show" did not show all the URLs associated with the named - remote, even though "git remote -v" did. Made them consistent by - making the former show all URLs. - - * "whitespace" attribute that is set was meant to detect all errors known - to git, but it told git to ignore trailing carriage-returns. - -Includes other documentation fixes. diff --git a/third_party/git/Documentation/RelNotes/1.6.3.4.txt b/third_party/git/Documentation/RelNotes/1.6.3.4.txt deleted file mode 100644 index cad461bc76..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.3.4.txt +++ /dev/null @@ -1,36 +0,0 @@ -GIT v1.6.3.4 Release Notes -========================== - -Fixes since v1.6.3.3 --------------------- - - * "git add --no-ignore-errors" did not override configured - add.ignore-errors configuration. - - * "git apply --whitespace=fix" did not fix trailing whitespace on an - incomplete line. - - * "git branch" opened too many commit objects unnecessarily. - - * "git checkout -f $commit" with a path that is a file (or a symlink) in - the work tree to a commit that has a directory at the path issued an - unnecessary error message. - - * "git diff -c/--cc" was very inefficient in coalescing the removed lines - shared between parents. - - * "git diff -c/--cc" showed removed lines at the beginning of a file - incorrectly. - - * "git remote show nickname" did not honor configured - remote.nickname.uploadpack when inspecting the branches at the remote. - - * "git request-pull" when talking to the terminal for a preview - showed some of the output in the pager. - - * "git request-pull start nickname [end]" did not honor configured - remote.nickname.uploadpack when it ran git-ls-remote against the remote - repository to learn the current tip of branches. - -Includes other documentation updates and minor fixes. - diff --git a/third_party/git/Documentation/RelNotes/1.6.3.txt b/third_party/git/Documentation/RelNotes/1.6.3.txt deleted file mode 100644 index 418c685cf8..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.3.txt +++ /dev/null @@ -1,182 +0,0 @@ -GIT v1.6.3 Release Notes -======================== - -With the next major release, "git push" into a branch that is -currently checked out will be refused by default. You can choose -what should happen upon such a push by setting the configuration -variable receive.denyCurrentBranch in the receiving repository. - -To ease the transition plan, the receiving repository of such a -push running this release will issue a big warning when the -configuration variable is missing. Please refer to: - - http://git.or.cz/gitwiki/GitFaq#non-bare - http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 - -for more details on the reason why this change is needed and the -transition plan. - -For a similar reason, "git push $there :$killed" to delete the branch -$killed in a remote repository $there, if $killed branch is the current -branch pointed at by its HEAD, gets a large warning. You can choose what -should happen upon such a push by setting the configuration variable -receive.denyDeleteCurrent in the receiving repository. - -When the user does not tell "git push" what to push, it has always -pushed matching refs. For some people it is unexpected, and a new -configuration variable push.default has been introduced to allow -changing a different default behaviour. To advertise the new feature, -a big warning is issued if this is not configured and a git push without -arguments is attempted. - - -Updates since v1.6.2 --------------------- - -(subsystems) - -* various git-svn updates. - -* git-gui updates, including an update to Russian translation, and a - fix to an infinite loop when showing an empty diff. - -* gitk updates, including an update to Russian translation and improved Windows - support. - -(performance) - -* many uses of lstat(2) in the codepath for "git checkout" have been - optimized out. - -(usability, bells and whistles) - -* Boolean configuration variable yes/no can be written as on/off. - -* rsync:/path/to/repo can be used to run git over rsync for local - repositories. It may not be useful in practice; meant primarily for - testing. - -* http transport learned to prompt and use password when fetching from or - pushing to http://user@host.xz/ URL. - -* (msysgit) progress output that is sent over the sideband protocol can - be handled appropriately in Windows console. - -* "--pretty=<style>" option to the log family of commands can now be - spelled as "--format=<style>". In addition, --format=%formatstring - is a short-hand for --pretty=tformat:%formatstring. - -* "--oneline" is a synonym for "--pretty=oneline --abbrev-commit". - -* "--graph" to the "git log" family can draw the commit ancestry graph - in colors. - -* If you realize that you botched the patch when you are editing hunks - with the 'edit' action in git-add -i/-p, you can abort the editor to - tell git not to apply it. - -* @{-1} is a new way to refer to the last branch you were on introduced in - 1.6.2, but the initial implementation did not teach this to a few - commands. Now the syntax works with "branch -m @{-1} newname". - -* git-archive learned --output=<file> option. - -* git-archive takes attributes from the tree being archived; strictly - speaking, this is an incompatible behaviour change, but is a good one. - Use --worktree-attributes option to allow it to read attributes from - the work tree as before (deprecated git-tar tree command always reads - attributes from the work tree). - -* git-bisect shows not just the number of remaining commits whose goodness - is unknown, but also shows the estimated number of remaining rounds. - -* You can give --date=<format> option to git-blame. - -* "git-branch -r" shows HEAD symref that points at a remote branch in - interest of each tracked remote repository. - -* "git-branch -v -v" is a new way to get list of names for branches and the - "upstream" branch for them. - -* git-config learned -e option to open an editor to edit the config file - directly. - -* git-clone runs post-checkout hook when run without --no-checkout. - -* git-difftool is now part of the officially supported command, primarily - maintained by David Aguilar. - -* git-for-each-ref learned a new "upstream" token. - -* git-format-patch can be told to use attachment with a new configuration, - format.attach. - -* git-format-patch can be told to produce deep or shallow message threads. - -* git-format-patch can be told to always add sign-off with a configuration - variable. - -* git-format-patch learned format.headers configuration to add extra - header fields to the output. This behaviour is similar to the existing - --add-header=<header> option of the command. - -* git-format-patch gives human readable names to the attached files, when - told to send patches as attachments. - -* git-grep learned to highlight the found substrings in color. - -* git-imap-send learned to work around Thunderbird's inability to easily - disable format=flowed with a new configuration, imap.preformattedHTML. - -* git-rebase can be told to rebase the series even if your branch is a - descendant of the commit you are rebasing onto with --force-rebase - option. - -* git-rebase can be told to report diffstat with the --stat option. - -* Output from git-remote command has been vastly improved. - -* "git remote update --prune $remote" updates from the named remote and - then prunes stale tracking branches. - -* git-send-email learned --confirm option to review the Cc: list before - sending the messages out. - -(developers) - -* Test scripts can be run under valgrind. - -* Test scripts can be run with installed git. - -* Makefile learned 'coverage' option to run the test suites with - coverage tracking enabled. - -* Building the manpages with docbook-xsl between 1.69.1 and 1.71.1 now - requires setting DOCBOOK_SUPPRESS_SP to work around a docbook-xsl bug. - This workaround used to be enabled by default, but causes problems - with newer versions of docbook-xsl. In addition, there are a few more - knobs you can tweak to work around issues with various versions of the - docbook-xsl package. See comments in Documentation/Makefile for details. - -* Support for building and testing a subset of git on a system without a - working perl has been improved. - - -Fixes since v1.6.2 ------------------- - -All of the fixes in v1.6.2.X maintenance series are included in this -release, unless otherwise noted. - -Here are fixes that this release has, but have not been backported to -v1.6.2.X series. - -* "git-apply" rejected a patch that swaps two files (i.e. renames A to B - and B to A at the same time). May need to be backported by cherry - picking d8c81df and then 7fac0ee). - -* The initial checkout did not read the attributes from the .gitattribute - file that is being checked out. - -* git-gc spent excessive amount of time to decide if an object appears - in a locally existing pack (if needed, backport by merging 69e020a). diff --git a/third_party/git/Documentation/RelNotes/1.6.4.1.txt b/third_party/git/Documentation/RelNotes/1.6.4.1.txt deleted file mode 100644 index e439e45b96..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.4.1.txt +++ /dev/null @@ -1,46 +0,0 @@ -GIT v1.6.4.1 Release Notes -========================== - -Fixes since v1.6.4 ------------------- - - * An unquoted value in the configuration file, when it contains more than - one whitespaces in a row, got them replaced with a single space. - - * "git am" used to accept a single piece of e-mail per file (not a mbox) - as its input, but multiple input format support in v1.6.4 broke it. - Apparently many people have been depending on this feature. - - * The short help text for "git filter-branch" command was a single long - line, wrapped by terminals, and was hard to read. - - * The "recursive" strategy of "git merge" segfaulted when a merge has - more than one merge-bases, and merging of these merge-bases involves - a rename/rename or a rename/add conflict. - - * "git pull --rebase" did not use the right fork point when the - repository has already fetched from the upstream that rewinds the - branch it is based on in an earlier fetch. - - * Explain the concept of fast-forward more fully in "git push" - documentation, and hint to refer to it from an error message when the - command refuses an update to protect the user. - - * The default value for pack.deltacachesize, used by "git repack", is now - 256M, instead of unbounded. Otherwise a repack of a moderately sized - repository would needlessly eat into swap. - - * Document how "git repack" (hence "git gc") interacts with a repository - that borrows its objects from other repositories (e.g. ones created by - "git clone -s"). - - * "git show" on an annotated tag lacked a delimiting blank line between - the tag itself and the contents of the object it tags. - - * "git verify-pack -v" erroneously reported number of objects with too - deep delta depths as "chain length 0" objects. - - * Long names of authors and committers outside US-ASCII were sometimes - incorrectly shown in "gitweb". - -Other minor documentation updates are included. diff --git a/third_party/git/Documentation/RelNotes/1.6.4.2.txt b/third_party/git/Documentation/RelNotes/1.6.4.2.txt deleted file mode 100644 index c11ec0115c..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.4.2.txt +++ /dev/null @@ -1,32 +0,0 @@ -GIT v1.6.4.2 Release Notes -========================== - -Fixes since v1.6.4.1 --------------------- - -* --date=relative output between 1 and 5 years ago rounded the number of - years when saying X years Y months ago, instead of rounding it down. - -* "git add -p" did not handle changes in executable bits correctly - (a regression around 1.6.3). - -* "git apply" did not honor GNU diff's convention to mark the creation/deletion - event with UNIX epoch timestamp on missing side. - -* "git checkout" incorrectly removed files in a directory pointed by a - symbolic link during a branch switch that replaces a directory with - a symbolic link. - -* "git clean -d -f" happily descended into a subdirectory that is managed by a - separate git repository. It now requires two -f options for safety. - -* "git fetch/push" over http transports had two rather grave bugs. - -* "git format-patch --cover-letter" did not prepare the cover letter file - for use with non-ASCII strings when there are the series contributors with - non-ASCII names. - -* "git pull origin branch" and "git fetch origin && git merge origin/branch" - left different merge messages in the resulting commit. - -Other minor documentation updates are included. diff --git a/third_party/git/Documentation/RelNotes/1.6.4.3.txt b/third_party/git/Documentation/RelNotes/1.6.4.3.txt deleted file mode 100644 index 5643e6537d..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.4.3.txt +++ /dev/null @@ -1,29 +0,0 @@ -GIT v1.6.4.3 Release Notes -========================== - -Fixes since v1.6.4.2 --------------------- - -* "git clone" from an empty repository gave unnecessary error message, - even though it did everything else correctly. - -* "git cvsserver" invoked git commands via "git-foo" style, which has long - been deprecated. - -* "git fetch" and "git clone" had an extra sanity check to verify the - presence of the corresponding *.pack file before downloading *.idx - file by issuing a HEAD request. Github server however sometimes - gave 500 (Internal server error) response to HEAD even if a GET - request for *.pack file to the same URL would have succeeded, and broke - clone over HTTP from some of their repositories. As a workaround, this - verification has been removed (as it is not absolutely necessary). - -* "git grep" did not like relative pathname to refer outside the current - directory when run from a subdirectory. - -* an error message from "git push" was formatted in a very ugly way. - -* "git svn" did not quote the subversion user name correctly when - running its author-prog helper program. - -Other minor documentation updates are included. diff --git a/third_party/git/Documentation/RelNotes/1.6.4.4.txt b/third_party/git/Documentation/RelNotes/1.6.4.4.txt deleted file mode 100644 index 0ead45fc72..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.4.4.txt +++ /dev/null @@ -1,26 +0,0 @@ -GIT v1.6.4.4 Release Notes -========================== - -Fixes since v1.6.4.4 --------------------- - -* The workaround for Github server that sometimes gave 500 (Internal server - error) response to HEAD requests in 1.6.4.3 introduced a regression that - caused re-fetching projects over http to segfault in certain cases due - to uninitialized pointer being freed. - -* "git pull" on an unborn branch used to consider anything in the work - tree and the index discardable. - -* "git diff -b/w" did not work well on the incomplete line at the end of - the file, due to an incorrect hashing of lines in the low-level xdiff - routines. - -* "git checkout-index --prefix=$somewhere" used to work when $somewhere is - a symbolic link to a directory elsewhere, but v1.6.4.2 broke it. - -* "git unpack-objects --strict", invoked when receive.fsckobjects - configuration is set in the receiving repository of "git push", did not - properly check the objects, especially the submodule links, it received. - -Other minor documentation updates are included. diff --git a/third_party/git/Documentation/RelNotes/1.6.4.5.txt b/third_party/git/Documentation/RelNotes/1.6.4.5.txt deleted file mode 100644 index eb6307dcbb..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.4.5.txt +++ /dev/null @@ -1,20 +0,0 @@ -Git v1.6.4.5 Release Notes -========================== - -Fixes since v1.6.4.4 --------------------- - - * Simplified base85 implementation. - - * An overlong line after ".gitdir: " in a git file caused out of bounds - access to an array on the stack. - - * "git count-objects" did not handle packs larger than 4G. - - * "git rev-parse --parseopt --stop-at-non-option" did not stop at non option - when --keep-dashdash was in effect. - - * "gitweb" can sometimes be tricked into parrotting a filename argument - given in a request without properly quoting. - -Other minor fixes and documentation updates are included. diff --git a/third_party/git/Documentation/RelNotes/1.6.4.txt b/third_party/git/Documentation/RelNotes/1.6.4.txt deleted file mode 100644 index 7a904419f7..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.4.txt +++ /dev/null @@ -1,147 +0,0 @@ -GIT v1.6.4 Release Notes -======================== - -With the next major release, "git push" into a branch that is -currently checked out will be refused by default. You can choose -what should happen upon such a push by setting the configuration -variable receive.denyCurrentBranch in the receiving repository. - -To ease the transition plan, the receiving repository of such a -push running this release will issue a big warning when the -configuration variable is missing. Please refer to: - - http://git.or.cz/gitwiki/GitFaq#non-bare - http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 - -for more details on the reason why this change is needed and the -transition plan. - -For a similar reason, "git push $there :$killed" to delete the branch -$killed in a remote repository $there, if $killed branch is the current -branch pointed at by its HEAD, gets a large warning. You can choose what -should happen upon such a push by setting the configuration variable -receive.denyDeleteCurrent in the receiving repository. - - -Updates since v1.6.3 --------------------- - -(subsystems) - - * gitweb Perl style clean-up. - - * git-svn updates, including a new --authors-prog option to map author - names by invoking an external program, 'git svn reset' to unwind - 'git svn fetch', support for more than one branches, documenting - of the useful --minimize-url feature, new "git svn gc" command, etc. - -(portability) - - * We feed iconv with "UTF-8" instead of "utf8"; the former is - understood more widely. Similarly updated test scripts to use - encoding names more widely understood (e.g. use "ISO8859-1" instead - of "ISO-8859-1"). - - * Various portability fixes/workarounds for different vintages of - SunOS, IRIX, and Windows. - - * Git-over-ssh transport on Windows supports PuTTY plink and TortoisePlink. - -(performance) - - * Many repeated use of lstat() are optimized out in "checkout" codepath. - - * git-status (and underlying git-diff-index --cached) are optimized - to take advantage of cache-tree information in the index. - -(usability, bells and whistles) - - * "git add --edit" lets users edit the whole patch text to fine-tune what - is added to the index. - - * "git am" accepts StGIT series file as its input. - - * "git bisect skip" skips to a more randomly chosen place in the hope - to avoid testing a commit that is too close to a commit that is - already known to be untestable. - - * "git cvsexportcommit" learned -k option to stop CVS keywords expansion - - * "git fast-export" learned to handle history simplification more - gracefully. - - * "git fast-export" learned an option --tag-of-filtered-object to handle - dangling tags resulting from history simplification more usefully. - - * "git grep" learned -p option to show the location of the match using the - same context hunk marker "git diff" uses. - - * https transport can optionally be told that the used client - certificate is password protected, in which case it asks the - password only once. - - * "git imap-send" is IPv6 aware. - - * "git log --graph" draws graphs more compactly by using horizontal lines - when able. - - * "git log --decorate" shows shorter refnames by stripping well-known - refs/* prefix. - - * "git push $name" honors remote.$name.pushurl if present before - using remote.$name.url. In other words, the URL used for fetching - and pushing can be different. - - * "git send-email" understands quoted aliases in .mailrc files (might - have to be backported to 1.6.3.X). - - * "git send-email" can fetch the sender address from the configuration - variable "sendmail.from" (and "sendmail.<identity>.from"). - - * "git show-branch" can color its output. - - * "add" and "update" subcommands to "git submodule" learned --reference - option to use local clone with references. - - * "git submodule update" learned --rebase option to update checked - out submodules by rebasing the local changes. - - * "gitweb" can optionally use gravatar to adorn author/committer names. - -(developers) - - * A major part of the "git bisect" wrapper has moved to C. - - * Formatting with the new version of AsciiDoc 8.4.1 is now supported. - -Fixes since v1.6.3 ------------------- - -All of the fixes in v1.6.3.X maintenance series are included in this -release, unless otherwise noted. - -Here are fixes that this release has, but have not been backported to -v1.6.3.X series. - - * "git diff-tree -r -t" used to omit new or removed directories from - the output. df533f3 (diff-tree -r -t: include added/removed - directories in the output, 2009-06-13) may need to be cherry-picked - to backport this fix. - - * The way Git.pm sets up a Repository object was not friendly to callers - that chdir around. It now internally records the repository location - as an absolute path when autodetected. - - * Removing a section with "git config --remove-section", when its - section header has a variable definition on the same line, lost - that variable definition. - - * "git rebase -p --onto" used to always leave side branches of a merge - intact, even when both branches are subject to rewriting. - - * "git repack" used to faithfully follow grafts and considered true - parents recorded in the commit object unreachable from the commit. - After such a repacking, you cannot remove grafts without corrupting - the repository. - - * "git send-email" did not detect erroneous loops in alias expansion. diff --git a/third_party/git/Documentation/RelNotes/1.6.5.1.txt b/third_party/git/Documentation/RelNotes/1.6.5.1.txt deleted file mode 100644 index 309ba181b2..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.5.1.txt +++ /dev/null @@ -1,20 +0,0 @@ -GIT v1.6.5.1 Release Notes -========================== - -Fixes since v1.6.5 ------------------- - - * An corrupt pack could make codepath to read objects into an - infinite loop. - - * Download throughput display was always shown in KiB/s but on fast links - it is more appropriate to show it in MiB/s. - - * "git grep -f filename" used uninitialized variable and segfaulted. - - * "git clone -b branch" gave a wrong commit object name to post-checkout - hook. - - * "git pull" over http did not work on msys. - -Other minor documentation updates are included. diff --git a/third_party/git/Documentation/RelNotes/1.6.5.2.txt b/third_party/git/Documentation/RelNotes/1.6.5.2.txt deleted file mode 100644 index aa7ccce3a2..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.5.2.txt +++ /dev/null @@ -1,19 +0,0 @@ -GIT v1.6.5.2 Release Notes -========================== - -Fixes since v1.6.5.1 --------------------- - - * Installation of templates triggered a bug in busybox when using tar - implementation from it. - - * "git add -i" incorrectly ignored paths that are already in the index - if they matched .gitignore patterns. - - * "git describe --always" should have produced some output even there - were no tags in the repository, but it didn't. - - * "git ls-files" when showing tracked files incorrectly paid attention - to the exclude patterns. - -Other minor documentation updates are included. diff --git a/third_party/git/Documentation/RelNotes/1.6.5.3.txt b/third_party/git/Documentation/RelNotes/1.6.5.3.txt deleted file mode 100644 index b2fad1b22e..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.5.3.txt +++ /dev/null @@ -1,63 +0,0 @@ -Git v1.6.5.3 Release Notes -========================== - -Fixes since v1.6.5.2 --------------------- - - * info/grafts file didn't ignore trailing CR at the end of lines. - - * Packages generated on newer FC were unreadable by older versions of - RPM as the new default is to use stronger hash. - - * output from "git blame" was unreadable when the file ended in an - incomplete line. - - * "git add -i/-p" didn't handle deletion of empty files correctly. - - * "git clone" takes up to two parameters, but did not complain when - given more arguments than necessary and silently ignored them. - - * "git cvsimport" did not read files given as command line arguments - correctly when it is run from a subdirectory. - - * "git diff --color-words -U0" didn't work correctly. - - * The handling of blank lines at the end of file by "git diff/apply - --whitespace" was inconsistent with the other kinds of errors. - They are now colored, warned against, and fixed the same way as others. - - * There was no way to allow blank lines at the end of file without - allowing extra blanks at the end of lines. You can use blank-at-eof - and blank-at-eol whitespace error class to specify them separately. - The old trailing-space error class is now a short-hand to set both. - - * "-p" option to "git format-patch" was supposed to suppress diffstat - generation, but it was broken since 1.6.1. - - * "git imap-send" did not compile cleanly with newer OpenSSL. - - * "git help -a" outside of a git repository was broken. - - * "git ls-files -i" was supposed to be inverse of "git ls-files" without -i - with respect to exclude patterns, but it was broken since 1.6.5.2. - - * "git ls-remote" outside of a git repository over http was broken. - - * "git rebase -i" gave bogus error message when the command word was - misspelled. - - * "git receive-pack" that is run in response to "git push" did not run - garbage collection nor update-server-info, but in larger hosting sites, - these almost always need to be run. To help site administrators, the - command now runs "gc --auto" and "u-s-i" by setting receive.autogc - and receive.updateserverinfo configuration variables, respectively. - - * Release notes spelled the package name with incorrect capitalization. - - * "gitweb" did not escape non-ascii characters correctly in the URL. - - * "gitweb" showed "patch" link even for merge commits. - - * "gitweb" showed incorrect links for blob line numbers in pathinfo mode. - -Other minor documentation updates are included. diff --git a/third_party/git/Documentation/RelNotes/1.6.5.4.txt b/third_party/git/Documentation/RelNotes/1.6.5.4.txt deleted file mode 100644 index d3a2a3e712..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.5.4.txt +++ /dev/null @@ -1,32 +0,0 @@ -Git v1.6.5.4 Release Notes -========================== - -Fixes since v1.6.5.3 --------------------- - - * "git help" (without argument) used to check if you are in a directory - under git control. There was no breakage in behaviour per-se, but this - was unnecessary. - - * "git prune-packed" gave progress output even when its standard error is - not connected to a terminal; this caused cron jobs that run it to - produce crufts. - - * "git pack-objects --all-progress" is an option to ask progress output - from write-object phase _if_ progress output were to be produced, and - shouldn't have forced the progress output. - - * "git apply -p<n> --directory=<elsewhere>" did not work well for a - non-default value of n. - - * "git merge foo HEAD" was misparsed as an old-style invocation of the - command and produced a confusing error message. As it does not specify - any other branch to merge, it shouldn't be mistaken as such. We will - remove the old style "git merge <message> HEAD <commit>..." syntax in - future versions, but not in this release, - - * "git merge -m <message> <branch>..." added the standard merge message - on its own after user-supplied message, which should have overridden the - standard one. - -Other minor documentation updates are included. diff --git a/third_party/git/Documentation/RelNotes/1.6.5.5.txt b/third_party/git/Documentation/RelNotes/1.6.5.5.txt deleted file mode 100644 index ecfc57d875..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.5.5.txt +++ /dev/null @@ -1,49 +0,0 @@ -Git v1.6.5.5 Release Notes -========================== - -Fixes since v1.6.5.4 --------------------- - - * Manual pages can be formatted with older xmlto again. - - * GREP_OPTIONS exported from user's environment could have broken - our scripted commands. - - * In configuration files, a few variables that name paths can begin with - ~/ and ~username/ and they are expanded as expected. This is not a - bugfix but 1.6.6 will have this and without backporting users cannot - easily use the same ~/.gitconfig across versions. - - * "git diff -B -M" did the same computation to hash lines of contents - twice, and held onto memory after it has used the data in it - unnecessarily before it freed. - - * "git diff -B" and "git diff --dirstat" was not counting newly added - contents correctly. - - * "git format-patch revisions... -- path" issued an incorrect error - message that suggested to use "--" on the command line when path - does not exist in the current work tree (it is a separate matter if - it makes sense to limit format-patch with pathspecs like that - without using the --full-diff option). - - * "git grep -F -i StRiNg" did not work as expected. - - * Enumeration of available merge strategies iterated over the list of - commands in a wrong way, sometimes producing an incorrect result. - - * "git shortlog" did not honor the "encoding" header embedded in the - commit object like "git log" did. - - * Reading progress messages that come from the remote side while running - "git pull" is given precedence over reading the actual pack data to - prevent garbled progress message on the user's terminal. - - * "git rebase" got confused when the log message began with certain - strings that looked like Subject:, Date: or From: header. - - * "git reset" accidentally run in .git/ directory checked out the - work tree contents in there. - - -Other minor documentation updates are included. diff --git a/third_party/git/Documentation/RelNotes/1.6.5.6.txt b/third_party/git/Documentation/RelNotes/1.6.5.6.txt deleted file mode 100644 index a9eaf76f62..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.5.6.txt +++ /dev/null @@ -1,23 +0,0 @@ -Git v1.6.5.6 Release Notes -========================== - -Fixes since v1.6.5.5 --------------------- - - * "git add -p" had a regression since v1.6.5.3 that broke deletion of - non-empty files. - - * "git archive -o o.zip -- Makefile" produced an archive in o.zip - but in POSIX tar format. - - * Error message given to "git pull --rebase" when the user didn't give - enough clue as to what branch to integrate with still talked about - "merging with" the branch. - - * Error messages given by "git merge" when the merge resulted in a - fast-forward still were in plumbing lingo, even though in v1.6.5 - we reworded messages in other cases. - - * The post-upload-hook run by upload-pack in response to "git fetch" has - been removed, due to security concerns (the hook first appeared in - 1.6.5). diff --git a/third_party/git/Documentation/RelNotes/1.6.5.7.txt b/third_party/git/Documentation/RelNotes/1.6.5.7.txt deleted file mode 100644 index dc5302c21c..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.5.7.txt +++ /dev/null @@ -1,19 +0,0 @@ -Git v1.6.5.7 Release Notes -========================== - -Fixes since v1.6.5.6 --------------------- - -* If a user specifies a color for a <slot> (i.e. a class of things to show - in a particular color) that is known only by newer versions of git - (e.g. "color.diff.func" was recently added for upcoming 1.6.6 release), - an older version of git should just ignore them. Instead we diagnosed - it as an error. - -* With help.autocorrect set to non-zero value, the logic to guess typos - in the subcommand name misfired and ran a random nonsense command. - -* If a command is run with an absolute path as a pathspec inside a bare - repository, e.g. "rev-list HEAD -- /home", the code tried to run - strlen() on NULL, which is the result of get_git_work_tree(), and - segfaulted. diff --git a/third_party/git/Documentation/RelNotes/1.6.5.8.txt b/third_party/git/Documentation/RelNotes/1.6.5.8.txt deleted file mode 100644 index 8b24bebb96..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.5.8.txt +++ /dev/null @@ -1,28 +0,0 @@ -Git v1.6.5.8 Release Notes -========================== - -Fixes since v1.6.5.7 --------------------- - -* "git count-objects" did not handle packfiles that are bigger than 4G on - platforms with 32-bit off_t. - -* "git rebase -i" did not abort cleanly if it failed to launch the editor. - -* "git blame" did not work well when commit lacked the author name. - -* "git fast-import" choked when handling a tag that points at an object - that is not a commit. - -* "git reset --hard" did not work correctly when GIT_WORK_TREE environment - variable is used to point at the root of the true work tree. - -* "git grep" fed a buffer that is not NUL-terminated to underlying - regexec(). - -* "git checkout -m other" while on a branch that does not have any commit - segfaulted, instead of failing. - -* "git branch -a other" should have diagnosed the command as an error. - -Other minor documentation updates are also included. diff --git a/third_party/git/Documentation/RelNotes/1.6.5.9.txt b/third_party/git/Documentation/RelNotes/1.6.5.9.txt deleted file mode 100644 index bb469dd71e..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.5.9.txt +++ /dev/null @@ -1,18 +0,0 @@ -Git v1.6.5.9 Release Notes -========================== - -Fixes since v1.6.5.8 --------------------- - - * An overlong line after ".gitdir: " in a git file caused out of bounds - access to an array on the stack. - - * "git blame -L $start,$end" segfaulted when too large $start was given. - - * "git rev-parse --parseopt --stop-at-non-option" did not stop at non option - when --keep-dashdash was in effect. - - * "gitweb" can sometimes be tricked into parrotting a filename argument - given in a request without properly quoting. - -Other minor fixes and documentation updates are included. diff --git a/third_party/git/Documentation/RelNotes/1.6.5.txt b/third_party/git/Documentation/RelNotes/1.6.5.txt deleted file mode 100644 index ee141c19ad..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.5.txt +++ /dev/null @@ -1,169 +0,0 @@ -GIT v1.6.5 Release Notes -======================== - -In git 1.7.0, which was planned to be the release after 1.6.5, "git -push" into a branch that is currently checked out will be refused by -default. - -You can choose what should happen upon such a push by setting the -configuration variable receive.denyCurrentBranch in the receiving -repository. - -Also, "git push $there :$killed" to delete the branch $killed in a remote -repository $there, when $killed branch is the current branch pointed at by -its HEAD, will be refused by default. - -You can choose what should happen upon such a push by setting the -configuration variable receive.denyDeleteCurrent in the receiving -repository. - -To ease the transition plan, the receiving repository of such a -push running this release will issue a big warning when the -configuration variable is missing. Please refer to: - - http://git.or.cz/gitwiki/GitFaq#non-bare - http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 - -for more details on the reason why this change is needed and the -transition plan. - -Updates since v1.6.4 --------------------- - -(subsystems) - - * various updates to gitk, git-svn and gitweb. - -(portability) - - * more improvements on mingw port. - - * mingw will also give FRSX as the default value for the LESS - environment variable when the user does not have one. - - * initial support to compile git on Windows with MSVC. - -(performance) - - * On major platforms, the system can be compiled to use with Linus's - block-sha1 implementation of the SHA-1 hash algorithm, which - outperforms the default fallback implementation we borrowed from - Mozilla. - - * Unnecessary inefficiency in deepening of a shallow repository has - been removed. - - * "git clone" does not grab objects that it does not need (i.e. - referenced only from refs outside refs/heads and refs/tags - hierarchy) anymore. - - * The "git" main binary used to link with libcurl, which then dragged - in a large number of external libraries. When using basic plumbing - commands in scripts, this unnecessarily slowed things down. We now - implement http/https/ftp transfer as a separate executable as we - used to. - - * "git clone" run locally hardlinks or copies the files in .git/ to - newly created repository. It used to give new mtime to copied files, - but this delayed garbage collection to trigger unnecessarily in the - cloned repository. We now preserve mtime for these files to avoid - this issue. - -(usability, bells and whistles) - - * Human writable date format to various options, e.g. --since=yesterday, - master@{2000.09.17}, are taught to infer some omitted input properly. - - * A few programs gave verbose "advice" messages to help uninitiated - people when issuing error messages. An infrastructure to allow - users to squelch them has been introduced, and a few such messages - can be silenced now. - - * refs/replace/ hierarchy is designed to be usable as a replacement - of the "grafts" mechanism, with the added advantage that it can be - transferred across repositories. - - * "git am" learned to optionally ignore whitespace differences. - - * "git am" handles input e-mail files that has CRLF line endings sensibly. - - * "git am" learned "--scissors" option to allow you to discard early part - of an incoming e-mail. - - * "git archive -o output.zip" works without being told what format to - use with an explicit "--format=zip".option. - - * "git checkout", "git reset" and "git stash" learned to pick and - choose to use selected changes you made, similar to "git add -p". - - * "git clone" learned a "-b" option to pick a HEAD to check out - different from the remote's default branch. - - * "git clone" learned --recursive option. - - * "git clone" from a local repository on a different filesystem used to - copy individual object files without preserving the old timestamp, giving - them extra lifetime in the new repository until they gc'ed. - - * "git commit --dry-run $args" is a new recommended way to ask "what would - happen if I try to commit with these arguments." - - * "git commit --dry-run" and "git status" shows conflicted paths in a - separate section to make them easier to spot during a merge. - - * "git cvsimport" now supports password-protected pserver access even - when the password is not taken from ~/.cvspass file. - - * "git fast-export" learned --no-data option that can be useful when - reordering commits and trees without touching the contents of - blobs. - - * "git fast-import" has a pair of new front-end in contrib/ area. - - * "git init" learned to mkdir/chdir into a directory when given an - extra argument (i.e. "git init this"). - - * "git instaweb" optionally can use mongoose as the web server. - - * "git log --decorate" can optionally be told with --decorate=full to - give the reference name in full. - - * "git merge" issued an unnecessarily scary message when it detected - that the merge may have to touch the path that the user has local - uncommitted changes to. The message has been reworded to make it - clear that the command aborted, without doing any harm. - - * "git push" can be told to be --quiet. - - * "git push" pays attention to url.$base.pushInsteadOf and uses a URL - that is derived from the URL used for fetching. - - * informational output from "git reset" that lists the locally modified - paths is made consistent with that of "git checkout $another_branch". - - * "git submodule" learned to give submodule name to scripts run with - "foreach" subcommand. - - * various subcommands to "git submodule" learned --recursive option. - - * "git submodule summary" learned --files option to compare the work - tree vs the commit bound at submodule path, instead of comparing - the index. - - * "git upload-pack", which is the server side support for "git clone" and - "git fetch", can call a new post-upload-pack hook for statistics purposes. - -(developers) - - * With GIT_TEST_OPTS="--root=/p/a/t/h", tests can be run outside the - source directory; using tmpfs may give faster turnaround. - - * With NO_PERL_MAKEMAKER set, DESTDIR= is now honoured, so you can - build for one location, and install into another location to tar it - up. - -Fixes since v1.6.4 ------------------- - -All of the fixes in v1.6.4.X maintenance series are included in this -release, unless otherwise noted. diff --git a/third_party/git/Documentation/RelNotes/1.6.6.1.txt b/third_party/git/Documentation/RelNotes/1.6.6.1.txt deleted file mode 100644 index f1d0a4ae2d..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.6.1.txt +++ /dev/null @@ -1,37 +0,0 @@ -Git v1.6.6.1 Release Notes -========================== - -Fixes since v1.6.6 ------------------- - - * "git blame" did not work well when commit lacked the author name. - - * "git branch -a name" wasn't diagnosed as an error. - - * "git count-objects" did not handle packfiles that are bigger than 4G on - platforms with 32-bit off_t. - - * "git checkout -m other" while on a branch that does not have any commit - segfaulted, instead of failing. - - * "git fast-import" choked when fed a tag that do not point at a - commit. - - * "git grep" finding from work tree files could have fed garbage to - the underlying regexec(3). - - * "git grep -L" didn't show empty files (they should never match, and - they should always appear in -L output as unmatching). - - * "git rebase -i" did not abort cleanly if it failed to launch the editor. - - * "git reset --hard" did not work correctly when GIT_WORK_TREE environment - variable is used to point at the root of the true work tree. - - * http-backend was not listed in the command list in the documentation. - - * Building on FreeBSD (both 7 and 8) needs OLD_ICONV set in the Makefile - - * "git checkout -m some-branch" while on an unborn branch crashed. - -Other minor documentation updates are included. diff --git a/third_party/git/Documentation/RelNotes/1.6.6.2.txt b/third_party/git/Documentation/RelNotes/1.6.6.2.txt deleted file mode 100644 index 4eaddc0106..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.6.2.txt +++ /dev/null @@ -1,46 +0,0 @@ -Git v1.6.6.2 Release Notes -========================== - -Fixes since v1.6.6.1 --------------------- - - * recursive merge didn't correctly diagnose its own programming errors, - and instead caused the caller to segfault. - - * The new "smart http" aware clients probed the web servers to see if - they support smart http, but did not fall back to dumb http transport - correctly with some servers. - - * Time based reflog syntax e.g. "@{yesterday}" didn't diagnose a misspelled - time specification and instead assumed "@{now}". - - * "git archive HEAD -- no-such-directory" produced an empty archive - without complaining. - - * "git blame -L start,end -- file" misbehaved when given a start that is - larger than the number of lines in the file. - - * "git checkout -m" didn't correctly call custom merge backend supplied - by the end user. - - * "git config -f <file>" misbehaved when run from a subdirectory. - - * "git cvsserver" didn't like having regex metacharacters (e.g. '+') in - CVSROOT environment. - - * "git fast-import" did not correctly handle large blobs that may - bust the pack size limit. - - * "git gui" is supposed to work even when launched from inside a .git - directory. - - * "git gui" misbehaved when applying a hunk that ends with deletion. - - * "git imap-send" did not honor imap.preformattedHTML as documented. - - * "git log" family incorrectly showed the commit notes unconditionally by - mistake, which was especially irritating when running "git log --oneline". - - * "git status" shouldn't require an write access to the repository. - -Other minor documentation updates are included. diff --git a/third_party/git/Documentation/RelNotes/1.6.6.3.txt b/third_party/git/Documentation/RelNotes/1.6.6.3.txt deleted file mode 100644 index 11483acaec..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.6.3.txt +++ /dev/null @@ -1,23 +0,0 @@ -Git v1.6.6.3 Release Notes -========================== - -Fixes since v1.6.6.2 --------------------- - - * An overlong line after ".gitdir: " in a git file caused out of bounds - access to an array on the stack. - - * "git bisect $path" did not correctly diagnose an error when given a - non-existent path. - - * "git blame -L $start,$end" segfaulted when too large $start was given. - - * "git imap-send" did not write draft box with CRLF line endings per RFC. - - * "git rev-parse --parseopt --stop-at-non-option" did not stop at non option - when --keep-dashdash was in effect. - - * "gitweb" can sometimes be tricked into parrotting a filename argument - given in a request without properly quoting. - -Other minor fixes and documentation updates are included. diff --git a/third_party/git/Documentation/RelNotes/1.6.6.txt b/third_party/git/Documentation/RelNotes/1.6.6.txt deleted file mode 100644 index c50b59c495..0000000000 --- a/third_party/git/Documentation/RelNotes/1.6.6.txt +++ /dev/null @@ -1,224 +0,0 @@ -Git v1.6.6 Release Notes -======================== - -Notes on behaviour change -------------------------- - - * In this release, "git fsck" defaults to "git fsck --full" and - checks packfiles, and because of this it will take much longer to - complete than before. If you prefer a quicker check only on loose - objects (the old default), you can say "git fsck --no-full". This - has been supported by 1.5.4 and newer versions of git, so it is - safe to write it in your script even if you use slightly older git - on some of your machines. - -Preparing yourselves for compatibility issues in 1.7.0 ------------------------------------------------------- - -In git 1.7.0, which is planned to be the release after 1.6.6, there will -be a handful of behaviour changes that will break backward compatibility. - -These changes were discussed long time ago and existing behaviours have -been identified as more problematic to the userbase than keeping them for -the sake of backward compatibility. - -When necessary, a transition strategy for existing users has been designed -not to force them running around setting configuration variables and -updating their scripts in order to either keep the traditional behaviour -or adjust to the new behaviour, on the day their sysadmin decides to install -the new version of git. When we switched from "git-foo" to "git foo" in -1.6.0, even though the change had been advertised and the transition -guide had been provided for a very long time, the users procrastinated -during the entire transition period, and ended up panicking on the day -their sysadmins updated their git installation. We are trying to avoid -repeating that unpleasantness in the 1.7.0 release. - -For changes decided to be in 1.7.0, commands that will be affected -have been much louder to strongly discourage such procrastination, and -they continue to be in this release. If you have been using recent -versions of git, you would have seen warnings issued when you used -features whose behaviour will change, with a clear instruction on how -to keep the existing behaviour if you want to. You hopefully are -already well prepared. - -Of course, we have also been giving "this and that will change in -1.7.0; prepare yourselves" warnings in the release notes and -announcement messages for the past few releases. Let's see how well -users will fare this time. - - * "git push" into a branch that is currently checked out (i.e. pointed by - HEAD in a repository that is not bare) will be refused by default. - - Similarly, "git push $there :$killed" to delete the branch $killed - in a remote repository $there, when $killed branch is the current - branch pointed at by its HEAD, will be refused by default. - - Setting the configuration variables receive.denyCurrentBranch and - receive.denyDeleteCurrent to 'ignore' in the receiving repository - can be used to override these safety features. Versions of git - since 1.6.2 have issued a loud warning when you tried to do these - operations without setting the configuration, so repositories of - people who still need to be able to perform such a push should - already have been future proofed. - - Please refer to: - - http://git.or.cz/gitwiki/GitFaq#non-bare - http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 - - for more details on the reason why this change is needed and the - transition process that already took place so far. - - * "git send-email" will not make deep threads by default when sending a - patch series with more than two messages. All messages will be sent - as a reply to the first message, i.e. cover letter. Git 1.6.6 (this - release) will issue a warning about the upcoming default change, when - it uses the traditional "deep threading" behaviour as the built-in - default. To squelch the warning but still use the "deep threading" - behaviour, give --chain-reply-to option or set sendemail.chainreplyto - to true. - - It has been possible to configure send-email to send "shallow thread" - by setting sendemail.chainreplyto configuration variable to false. - The only thing 1.7.0 release will do is to change the default when - you haven't configured that variable. - - * "git status" will not be "git commit --dry-run". This change does not - affect you if you run the command without pathspec. - - Nobody sane found the current behaviour of "git status Makefile" useful - nor meaningful, and it confused users. "git commit --dry-run" has been - provided as a way to get the current behaviour of this command since - 1.6.5. - - * "git diff" traditionally treated various "ignore whitespace" options - only as a way to filter the patch output. "git diff --exit-code -b" - exited with non-zero status even if all changes were about changing the - amount of whitespace and nothing else. and "git diff -b" showed the - "diff --git" header line for such a change without patch text. - - In 1.7.0, the "ignore whitespaces" will affect the semantics of the - diff operation itself. A change that does not affect anything but - whitespaces will be reported with zero exit status when run with - --exit-code, and there will not be "diff --git" header for such a - change. - - -Updates since v1.6.5 --------------------- - -(subsystems) - - * various gitk updates including use of themed widgets under Tk 8.5, - Japanese translation, a fix to a bug when running "gui blame" from - a subdirectory, etc. - - * various git-gui updates including new translations, wm states fixes, - Tk bug workaround after quitting, improved heuristics to trigger gc, - etc. - - * various git-svn updates. - - * "git fetch" over http learned a new mode that is different from the - traditional "dumb commit walker". - -(portability) - - * imap-send can be built on mingw port. - -(performance) - - * "git diff -B" has smaller memory footprint. - -(usability, bells and whistles) - - * The object replace mechanism can be bypassed with --no-replace-objects - global option given to the "git" program. - - * In configuration files, a few variables that name paths can begin with ~/ - and ~username/ and they are expanded as expected. - - * "git subcmd -h" now shows short usage help for many more subcommands. - - * "git bisect reset" can reset to an arbitrary commit. - - * "git checkout frotz" when there is no local branch "frotz" but there - is only one remote tracking branch "frotz" is taken as a request to - start the named branch at the corresponding remote tracking branch. - - * "git commit -c/-C/--amend" can be told with a new "--reset-author" option - to ignore authorship information in the commit it is taking the message - from. - - * "git describe" can be told to add "-dirty" suffix with "--dirty" option. - - * "git diff" learned --submodule option to show a list of one-line logs - instead of differences between the commit object names. - - * "git diff" learned to honor diff.color.func configuration to paint - function name hint printed on the hunk header "@@ -j,k +l,m @@" line - in the specified color. - - * "git fetch" learned --all and --multiple options, to run fetch from - many repositories, and --prune option to remove remote tracking - branches that went stale. These make "git remote update" and "git - remote prune" less necessary (there is no plan to remove "remote - update" nor "remote prune", though). - - * "git fsck" by default checks the packfiles (i.e. "--full" is the - default); you can turn it off with "git fsck --no-full". - - * "git grep" can use -F (fixed strings) and -i (ignore case) together. - - * import-tars contributed fast-import frontend learned more types of - compressed tarballs. - - * "git instaweb" knows how to talk with mod_cgid to apache2. - - * "git log --decorate" shows the location of HEAD as well. - - * "git log" and "git rev-list" learned to take revs and pathspecs from - the standard input with the new "--stdin" option. - - * "--pretty=format" option to "log" family of commands learned: - - . to wrap text with the "%w()" specifier. - . to show reflog information with "%g[sdD]" specifier. - - * "git notes" command to annotate existing commits. - - * "git merge" (and "git pull") learned --ff-only option to make it fail - if the merge does not result in a fast-forward. - - * "git mergetool" learned to use p4merge. - - * "git rebase -i" learned "reword" that acts like "edit" but immediately - starts an editor to tweak the log message without returning control to - the shell, which is done by "edit" to give an opportunity to tweak the - contents. - - * "git send-email" can be told with "--envelope-sender=auto" to use the - same address as "From:" address as the envelope sender address. - - * "git send-email" will issue a warning when it defaults to the - --chain-reply-to behaviour without being told by the user and - instructs to prepare for the change of the default in 1.7.0 release. - - * In "git submodule add <repository> <path>", <path> is now optional and - inferred from <repository> the same way "git clone <repository>" does. - - * "git svn" learned to read SVN 1.5+ and SVK merge tickets. - - * "git svn" learned to recreate empty directories tracked only by SVN. - - * "gitweb" can optionally render its "blame" output incrementally (this - requires JavaScript on the client side). - - * Author names shown in gitweb output are links to search commits by the - author. - -Fixes since v1.6.5 ------------------- - -All of the fixes in v1.6.5.X maintenance series are included in this -release, unless otherwise noted. diff --git a/third_party/git/Documentation/RelNotes/1.7.0.1.txt b/third_party/git/Documentation/RelNotes/1.7.0.1.txt deleted file mode 100644 index 8ff5bcada8..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.0.1.txt +++ /dev/null @@ -1,35 +0,0 @@ -Git v1.7.0.1 Release Notes -========================== - -Fixes since v1.7.0 ------------------- - - * In a freshly created repository "rev-parse HEAD^0" complained that - it is dangling symref, even though "rev-parse HEAD" didn't. - - * "git show :no-such-name" tried to access the index without bounds - check, leading to a potential segfault. - - * Message from "git cherry-pick" was harder to read and use than necessary - when it stopped due to conflicting changes. - - * We referred to ".git/refs/" throughout the documentation when we - meant to talk about abstract notion of "ref namespace". Because - people's repositories often have packed refs these days, this was - confusing. - - * "git diff --output=/path/that/cannot/be/written" did not correctly - error out. - - * "git grep -e -pattern-that-begin-with-dash paths..." could not be - spelled as "git grep -- -pattern-that-begin-with-dash paths..." which - would be a GNU way to use "--" as "end of options". - - * "git grep" compiled with threading support tried to access an - uninitialized mutex on boxes with a single CPU. - - * "git stash pop -q --index" failed because the unnecessary --index - option was propagated to "git stash drop" that is internally run at the - end. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.0.2.txt b/third_party/git/Documentation/RelNotes/1.7.0.2.txt deleted file mode 100644 index fcb46ca6a4..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.0.2.txt +++ /dev/null @@ -1,40 +0,0 @@ -Git v1.7.0.2 Release Notes -========================== - -Fixes since v1.7.0.1 --------------------- - - * GIT_PAGER was not honored consistently by some scripted Porcelains, most - notably "git am". - - * updating working tree files after telling git to add them to the - index and while it is still working created garbage object files in - the repository without diagnosing it as an error. - - * "git bisect -- pathspec..." did not diagnose an error condition properly when - the simplification with given pathspec made the history empty. - - * "git rev-list --cherry-pick A...B" now has an obvious optimization when the - histories haven't diverged (i.e. when one end is an ancestor of the other). - - * "git diff --quiet -w" did not work as expected. - - * "git fast-import" didn't work with a large input, as it lacked support - for producing the pack index in v2 format. - - * "git imap-send" didn't use CRLF line endings over the imap protocol - when storing its payload to the draft box, violating RFC 3501. - - * "git log --format='%w(x,y,z)%b'" and friends that rewrap message - has been optimized for utf-8 payload. - - * Error messages generated on the receiving end did not come back to "git - push". - - * "git status" in 1.7.0 lacked the optimization we used to have in 1.6.X series - to speed up scanning of large working tree. - - * "gitweb" did not diagnose parsing errors properly while reading tis configuration - file. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.0.3.txt b/third_party/git/Documentation/RelNotes/1.7.0.3.txt deleted file mode 100644 index 3b355737c0..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.0.3.txt +++ /dev/null @@ -1,34 +0,0 @@ -Git v1.7.0.3 Release Notes -========================== - -Fixes since v1.7.0.2 --------------------- - - * Object files are created in a more ACL friendly way in repositories - where group permission is ACL controlled. - - * "git add -i" didn't handle a deleted path very well. - - * "git blame" padded line numbers with one extra SP when the total number - of lines was one less than multiple of ten due to an off-by-one error. - - * "git fetch --all/--multi" used to discard information for remotes that - are fetched earlier. - - * "git log --author=me --grep=it" tried to find commits that have "it" - or are written by "me", instead of the ones that have "it" _and_ are - written by "me". - - * "git log -g branch" misbehaved when there was no entries in the reflog - for the named branch. - - * "git mailinfo" (hence "git am") incorrectly removed initial indent from - paragraphs. - - * "git prune" and "git reflog" (hence "git gc" as well) didn't honor - an instruction never to expire by setting gc.reflogexpire to never. - - * "git push" misbehaved when branch.<name>.merge was configured without - matching branch.<name>.remote. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.0.4.txt b/third_party/git/Documentation/RelNotes/1.7.0.4.txt deleted file mode 100644 index cf7f60e60d..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.0.4.txt +++ /dev/null @@ -1,27 +0,0 @@ -Git v1.7.0.4 Release Notes -========================== - -Fixes since v1.7.0.3 --------------------- - - * Optimized ntohl/htonl on big-endian machines were broken. - - * Color values given to "color.<cmd>.<slot>" configuration can now have - more than one attributes (e.g. "bold ul"). - - * "git add -u nonexistent-path" did not complain. - - * "git apply --whitespace=fix" didn't work well when an early patch in - a patch series adds trailing blank lines and a later one depended on - such a block of blank lines at the end. - - * "git fast-export" didn't check error status and stop when marks file - cannot be opened. - - * "git format-patch --ignore-if-in-upstream" gave unwarranted errors - when the range was empty, instead of silently finishing. - - * "git remote prune" did not detect remote tracking refs that became - dangling correctly. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.0.5.txt b/third_party/git/Documentation/RelNotes/1.7.0.5.txt deleted file mode 100644 index 3149c91b7b..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.0.5.txt +++ /dev/null @@ -1,26 +0,0 @@ -Git v1.7.0.5 Release Notes -========================== - -Fixes since v1.7.0.4 --------------------- - - * "git daemon" failed to compile on platforms without sockaddr_storage type. - - * Output from "git rev-list --pretty=oneline" was unparsable when a - commit did not have any message, which is abnormal but possible in a - repository converted from foreign scm. - - * "git stash show <commit-that-is-not-a-stash>" gave an error message - that was not so useful. Reworded the message to "<it> is not a - stash". - - * Python scripts in contrib/ area now start with "#!/usr/bin/env python" - to honor user's PATH. - - * "git imap-send" used to mistake any line that begins with "From " as a - message separator in format-patch output. - - * Smart http server backend failed to report an internal server error and - infinitely looped instead after output pipe was closed. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.0.6.txt b/third_party/git/Documentation/RelNotes/1.7.0.6.txt deleted file mode 100644 index b2852b67d0..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.0.6.txt +++ /dev/null @@ -1,13 +0,0 @@ -Git v1.7.0.6 Release Notes -========================== - -Fixes since v1.7.0.5 --------------------- - - * "git diff --stat" used "int" to count the size of differences, - which could result in overflowing. - - * "git rev-list --abbrev-commit" defaulted to 40-byte abbreviations, unlike - newer tools in the git toolset. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.0.7.txt b/third_party/git/Documentation/RelNotes/1.7.0.7.txt deleted file mode 100644 index d0cb7ca7e2..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.0.7.txt +++ /dev/null @@ -1,16 +0,0 @@ -Git v1.7.0.7 Release Notes -========================== - -Fixes since v1.7.0.6 --------------------- - - * "make NO_CURL=NoThanks install" was broken. - - * An overlong line after ".gitdir: " in a git file caused out of bounds - access to an array on the stack. - - * "git config --path conf.var" to attempt to expand a variable conf.var - that uses "~/" short-hand segfaulted when $HOME environment variable - was not set. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.0.8.txt b/third_party/git/Documentation/RelNotes/1.7.0.8.txt deleted file mode 100644 index 7f05b48e17..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.0.8.txt +++ /dev/null @@ -1,10 +0,0 @@ -Git v1.7.0.8 Release Notes -========================== - -This is primarily to backport support for the new "add.ignoreErrors" -name given to the existing "add.ignore-errors" configuration variable. - -The next version, Git 1.7.4, and future versions, will support both -old and incorrect name and the new corrected name, but without this -backport, users who want to use the new name "add.ignoreErrors" in -their repositories cannot use older versions of Git. diff --git a/third_party/git/Documentation/RelNotes/1.7.0.9.txt b/third_party/git/Documentation/RelNotes/1.7.0.9.txt deleted file mode 100644 index bfb3166387..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.0.9.txt +++ /dev/null @@ -1,8 +0,0 @@ -Git v1.7.0.9 Release Notes -========================== - -Fixes since v1.7.0.8 --------------------- - - * "gitweb" can sometimes be tricked into parrotting a filename argument - given in a request without properly quoting. diff --git a/third_party/git/Documentation/RelNotes/1.7.0.txt b/third_party/git/Documentation/RelNotes/1.7.0.txt deleted file mode 100644 index 0bb8c0b2a2..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.0.txt +++ /dev/null @@ -1,214 +0,0 @@ -Git v1.7.0 Release Notes -======================== - -Notes on behaviour change -------------------------- - - * "git push" into a branch that is currently checked out (i.e. pointed at by - HEAD in a repository that is not bare) is refused by default. - - Similarly, "git push $there :$killed" to delete the branch $killed - in a remote repository $there, when $killed branch is the current - branch pointed at by its HEAD, will be refused by default. - - Setting the configuration variables receive.denyCurrentBranch and - receive.denyDeleteCurrent to 'ignore' in the receiving repository - can be used to override these safety features. - - * "git send-email" does not make deep threads by default when sending a - patch series with more than two messages. All messages will be sent - as a reply to the first message, i.e. cover letter. - - It has been possible already to configure send-email to send "shallow thread" - by setting sendemail.chainreplyto configuration variable to false. The - only thing this release does is to change the default when you haven't - configured that variable. - - * "git status" is not "git commit --dry-run" anymore. This change does - not affect you if you run the command without argument. - - * "git diff" traditionally treated various "ignore whitespace" options - only as a way to filter the patch output. "git diff --exit-code -b" - exited with non-zero status even if all changes were about changing the - amount of whitespace and nothing else; and "git diff -b" showed the - "diff --git" header line for such a change without patch text. - - In this release, the "ignore whitespaces" options affect the semantics - of the diff operation. A change that does not affect anything but - whitespaces is reported with zero exit status when run with - --exit-code, and there is no "diff --git" header for such a change. - - * External diff and textconv helpers are now executed using the shell. - This makes them consistent with other programs executed by git, and - allows you to pass command-line parameters to the helpers. Any helper - paths containing spaces or other metacharacters now need to be - shell-quoted. The affected helpers are GIT_EXTERNAL_DIFF in the - environment, and diff.*.command and diff.*.textconv in the config - file. - - * The --max-pack-size argument to 'git repack', 'git pack-objects', and - 'git fast-import' was assuming the provided size to be expressed in MiB, - unlike the corresponding config variable and other similar options accepting - a size value. It is now expecting a size expressed in bytes, with a possible - unit suffix of 'k', 'm', or 'g'. - -Updates since v1.6.6 --------------------- - -(subsystems) - - * "git fast-import" updates; adds "option" and "feature" to detect the - mismatch between fast-import and the frontends that produce the input - stream. - - * "git svn" support of subversion "merge tickets" and miscellaneous fixes. - - * "gitk" and "git gui" translation updates. - - * "gitweb" updates (code clean-up, load checking etc.) - -(portability) - - * Some more MSVC portability patches for msysgit port. - - * Minimum Pthreads emulation for msysgit port. - -(performance) - - * More performance improvement patches for msysgit port. - -(usability, bells and whistles) - - * More commands learned "--quiet" and "--[no-]progress" options. - - * Various commands given by the end user (e.g. diff.type.textconv, - and GIT_EDITOR) can be specified with command line arguments. E.g. it - is now possible to say "[diff "utf8doc"] textconv = nkf -w". - - * "sparse checkout" feature allows only part of the work tree to be - checked out. - - * HTTP transfer can use authentication scheme other than basic - (i.e./e.g. digest). - - * Switching from a version of superproject that used to have a submodule - to another version of superproject that no longer has it did not remove - the submodule directory when it should (namely, when you are not - interested in the submodule at all and didn't clone/checkout). - - * A new attribute conflict-marker-size can be used to change the size of - the conflict markers from the default 7; this is useful when tracked - contents (e.g. git-merge documentation) have strings that resemble the - conflict markers. - - * A new syntax "<branch>@{upstream}" can be used on the command line to - substitute the name of the "upstream" of the branch. Missing branch - defaults to the current branch, so "git fetch && git merge @{upstream}" - will be equivalent to "git pull". - - * "git am --resolved" has a synonym "git am --continue". - - * "git branch --set-upstream" can be used to update the (surprise!) upstream, - i.e. where the branch is supposed to pull and merge from (or rebase onto). - - * "git checkout A...B" is a way to detach HEAD at the merge base between - A and B. - - * "git checkout -m path" to reset the work tree file back into the - conflicted state works even when you already ran "git add path" and - resolved the conflicts. - - * "git commit --date='<date>'" can be used to override the author date - just like "git commit --author='<name> <email>'" can be used to - override the author identity. - - * "git commit --no-status" can be used to omit the listing of the index - and the work tree status in the editor used to prepare the log message. - - * "git commit" warns a bit more aggressively until you configure user.email, - whose default value almost always is not (and fundamentally cannot be) - what you want. - - * "git difftool" has been extended to make it easier to integrate it - with gitk. - - * "git fetch --all" can now be used in place of "git remote update". - - * "git grep" does not rely on external grep anymore. It can use more than - one thread to accelerate the operation. - - * "git grep" learned "--quiet" option. - - * "git log" and friends learned "--glob=heads/*" syntax that is a more - flexible way to complement "--branches/--tags/--remotes". - - * "git merge" learned to pass options specific to strategy-backends. E.g. - - - "git merge -Xsubtree=path/to/directory" can be used to tell the subtree - strategy how much to shift the trees explicitly. - - - "git merge -Xtheirs" can be used to auto-merge as much as possible, - while discarding your own changes and taking merged version in - conflicted regions. - - * "git push" learned "git push origin --delete branch", a syntactic sugar - for "git push origin :branch". - - * "git push" learned "git push --set-upstream origin forker:forkee" that - lets you configure your "forker" branch to later pull from "forkee" - branch at "origin". - - * "git rebase --onto A...B" means the history is replayed on top of the - merge base between A and B. - - * "git rebase -i" learned new action "fixup" that squashes the change - but does not affect existing log message. - - * "git rebase -i" also learned --autosquash option that is useful - together with the new "fixup" action. - - * "git remote" learned set-url subcommand that updates (surprise!) url - for an existing remote nickname. - - * "git rerere" learned "forget path" subcommand. Together with "git - checkout -m path" it will be useful when you recorded a wrong - resolution. - - * Use of "git reset --merge" has become easier when resetting away a - conflicted mess left in the work tree. - - * "git rerere" had rerere.autoupdate configuration but there was no way - to countermand it from the command line; --no-rerere-autoupdate option - given to "merge", "revert", etc. fixes this. - - * "git status" learned "-s(hort)" output format. - -(developers) - - * The infrastructure to build foreign SCM interface has been updated. - - * Many more commands are now built-in. - - * THREADED_DELTA_SEARCH is no more. If you build with threads, delta - compression will always take advantage of it. - -Fixes since v1.6.6 ------------------- - -All of the fixes in v1.6.6.X maintenance series are included in this -release, unless otherwise noted. - - * "git branch -d branch" used to refuse deleting the branch even when - the branch is fully merged to its upstream branch if it is not merged - to the current branch. It now deletes it in such a case. - - * "filter-branch" command incorrectly said --prune-empty and --filter-commit - were incompatible; the latter should be read as --commit-filter. - - * When using "git status" or asking "git diff" to compare the work tree - with something, they used to consider that a checked-out submodule with - uncommitted changes is not modified; this could cause people to forget - committing these changes in the submodule before committing in the - superproject. They now consider such a change as a modification and - "git diff" will append a "-dirty" to the work tree side when generating - patch output or when used with the --submodule option. diff --git a/third_party/git/Documentation/RelNotes/1.7.1.1.txt b/third_party/git/Documentation/RelNotes/1.7.1.1.txt deleted file mode 100644 index 3f6b3148a3..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.1.1.txt +++ /dev/null @@ -1,96 +0,0 @@ -Git v1.7.1.1 Release Notes -========================== - -Fixes since v1.7.1 ------------------- - - * Authentication over http transport can now be made lazily, in that the - request can first go to a URL without username, get a 401 response and - then the client will ask for the username to use. - - * We used to mistakenly think "../work" is a subdirectory of the current - directory when we are in "../work-xyz". - - * The attribute mechanism now allows an entry that uses an attribute - macro that set/unset one attribute, immediately followed by an - overriding setting; this makes attribute macros much easier to use. - - * We didn't recognize timezone "Z" as a synonym for "UTC" (75b37e70). - - * In 1.7.0, read-tree and user commands that use the mechanism such as - checkout and merge were fixed to handle switching between branches one - of which has a file while the other has a directory at the same path - correctly even when there are some "confusing" pathnames in them. But - the algorithm used for this fix was suboptimal and had a terrible - performance degradation especially in larger trees. - - * "git am -3" did not show diagnosis when the patch in the message was corrupt. - - * After "git apply --whitespace=fix" removed trailing blank lines in an - patch in a patch series, it failed to apply later patches that depend - on the presence of such blank lines. - - * "git bundle --stdin" segfaulted. - - * "git checkout" and "git rebase" overwrote paths that are marked "assume - unchanged". - - * "git commit --amend" on a commit with an invalid author-name line that - lacks the display name didn't work. - - * "git describe" did not tie-break tags that point at the same commit - correctly; newer ones are preferred by paying attention to the - tagger date now. - - * "git diff" used to tell underlying xdiff machinery to work very hard to - minimize the output, but this often was spending too many extra cycles - for very little gain. - - * "git diff --color" did not paint extended diff headers per line - (i.e. the coloring escape sequence didn't end at the end of line), - which confused "less -R". - - * "git fetch" over HTTP verifies the downloaded packfiles more robustly. - - * The memory usage by "git index-pack" (run during "git fetch" and "git - push") got leaner. - - * "GIT_DIR=foo.git git init --bare bar.git" created foo.git instead of bar.git. - - * "git log --abbrev=$num --format='%h' ignored --abbrev=$num. - - * "git ls-files ../out/side/cwd" refused to work. - - * "git merge --log" used to replace the custom message given by "-m" with - the shortlog, instead of appending to it. - - * "git notes copy" without any other argument segfaulted. - - * "git pull" accepted "--dry-run", gave it to underlying "git fetch" but - ignored the option itself, resulting in a bogus attempt to merge - unrelated commit. - - * "git rebase" did not faithfully reproduce a malformed author ident, that - is often seen in a repository converted from foreign SCMs. - - * "git reset --hard" started from a wrong directory and a working tree in - a nonstandard location is in use got confused. - - * "git send-email" lacked a way to specify the domainname used in the - EHLO/HELO exchange, causing rejected connection from picky servers. - It learned --smtp-domain option to solve this issue. - - * "git send-email" did not declare a content-transfer-encoding and - content-type even when its payload needs to be sent in 8-bit. - - * "git show -C -C" and other corner cases lost diff metainfo output - in 1.7.0. - - * "git stash" incorrectly lost paths in the working tree that were - previously removed from the index. - - * "git status" stopped refreshing the index by mistake in 1.7.1. - - * "git status" showed excess "hints" even when advice.statusHints is set to false. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.1.2.txt b/third_party/git/Documentation/RelNotes/1.7.1.2.txt deleted file mode 100644 index 61ba14e262..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.1.2.txt +++ /dev/null @@ -1,28 +0,0 @@ -Git v1.7.1.2 Release Notes -========================== - -Fixes since v1.7.1.1 --------------------- - - * "git commit" did not honor GIT_REFLOG_ACTION environment variable, resulting - reflog messages for cherry-pick and revert actions to be recorded as "commit". - - * "git clone/fetch/pull" issued an incorrect error message when a ref and - a symref that points to the ref were updated at the same time. This - obviously would update them to the same value, and should not result in - an error condition. - - * "git diff" inside a tree with many pathnames that have certain - characters has become very slow in 1.7.0 by mistake. - - * "git rev-parse --parseopt --stop-at-non-option" did not stop at non option - when --keep-dashdash was in effect. - - * An overlong line after ".gitdir: " in a git file caused out of bounds - access to an array on the stack. - - * "git config --path conf.var" to attempt to expand a variable conf.var - that uses "~/" short-hand segfaulted when $HOME environment variable - was not set. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.1.3.txt b/third_party/git/Documentation/RelNotes/1.7.1.3.txt deleted file mode 100644 index 5b18518449..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.1.3.txt +++ /dev/null @@ -1,10 +0,0 @@ -Git v1.7.1.3 Release Notes -========================== - -This is primarily to backport support for the new "add.ignoreErrors" -name given to the existing "add.ignore-errors" configuration variable. - -The next version, Git 1.7.4, and future versions, will support both -old and incorrect name and the new corrected name, but without this -backport, users who want to use the new name "add.ignoreErrors" in -their repositories cannot use older versions of Git. diff --git a/third_party/git/Documentation/RelNotes/1.7.1.4.txt b/third_party/git/Documentation/RelNotes/1.7.1.4.txt deleted file mode 100644 index 7c734b4f7b..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.1.4.txt +++ /dev/null @@ -1,8 +0,0 @@ -Git v1.7.1.4 Release Notes -========================== - -Fixes since v1.7.1.3 --------------------- - - * "gitweb" can sometimes be tricked into parrotting a filename argument - given in a request without properly quoting. diff --git a/third_party/git/Documentation/RelNotes/1.7.1.txt b/third_party/git/Documentation/RelNotes/1.7.1.txt deleted file mode 100644 index 9d89fedb36..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.1.txt +++ /dev/null @@ -1,89 +0,0 @@ -Git v1.7.1 Release Notes -======================== - -Updates since v1.7.0 --------------------- - - * Eric Raymond is the maintainer of updated CIAbot scripts, in contrib/. - - * gitk updates. - - * Some commands (e.g. svn and http interfaces) that interactively ask - for a password can be told to use an external program given via - GIT_ASKPASS. - - * Conflict markers that lead the common ancestor in diff3-style output - now have a label, which hopefully would help third-party tools that - expect one. - - * Comes with an updated bash-completion script. - - * "git am" learned "--keep-cr" option to handle inputs that are - a mixture of changes to files with and without CRLF line endings. - - * "git cvsimport" learned -R option to leave revision mapping between - CVS revisions and resulting git commits. - - * "git diff --submodule" notices and describes dirty submodules. - - * "git for-each-ref" learned %(symref), %(symref:short) and %(flag) - tokens. - - * "git hash-object --stdin-paths" can take "--no-filters" option now. - - * "git init" can be told to look at init.templatedir configuration - variable (obviously that has to come from either /etc/gitconfig or - $HOME/.gitconfig). - - * "git grep" learned "--no-index" option, to search inside contents that - are not managed by git. - - * "git grep" learned --color=auto/always/never. - - * "git grep" learned to paint filename and line-number in colors. - - * "git log -p --first-parent -m" shows one-parent diff for merge - commits, instead of showing combined diff. - - * "git merge-file" learned to use custom conflict marker size and also - to use the "union merge" behaviour. - - * "git notes" command has been rewritten in C and learned many commands - and features to help you carry notes forward across rebases and amends. - - * "git request-pull" identifies the commit the request is relative to in - a more readable way. - - * "git reset" learned "--keep" option that lets you discard commits - near the tip while preserving your local changes in a way similar - to how "git checkout branch" does. - - * "git status" notices and describes dirty submodules. - - * "git svn" should work better when interacting with repositories - with CRLF line endings. - - * "git imap-send" learned to support CRAM-MD5 authentication. - - * "gitweb" installation procedure can use "minified" js/css files - better. - - * Various documentation updates. - -Fixes since v1.7.0 ------------------- - -All of the fixes in v1.7.0.X maintenance series are included in this -release, unless otherwise noted. - - * "git add frotz/nitfol" did not complain when the entire frotz/ directory - was ignored. - - * "git diff --stat" used "int" to count the size of differences, - which could result in overflowing. - - * "git rev-list --pretty=oneline" didn't terminate a record with LF for - commits without any message. - - * "git rev-list --abbrev-commit" defaulted to 40-byte abbreviations, unlike - newer tools in the git toolset. diff --git a/third_party/git/Documentation/RelNotes/1.7.10.1.txt b/third_party/git/Documentation/RelNotes/1.7.10.1.txt deleted file mode 100644 index 71a86cb7c6..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.10.1.txt +++ /dev/null @@ -1,78 +0,0 @@ -Git v1.7.10.1 Release Notes -=========================== - -Additions since v1.7.10 ------------------------ - -Localization message files for Danish and German have been added. - - -Fixes since v1.7.10 -------------------- - - * "git add -p" is not designed to deal with unmerged paths but did - not exclude them and tried to apply funny patches only to fail. - - * "git blame" started missing quite a few changes from the origin - since we stopped using the diff minimization by default in v1.7.2 - era. - - * When PATH contains an unreadable directory, alias expansion code - did not kick in, and failed with an error that said "git-subcmd" - was not found. - - * "git clean -d -f" (not "-d -f -f") is supposed to protect nested - working trees of independent git repositories that exist in the - current project working tree from getting removed, but the - protection applied only to such working trees that are at the - top-level of the current project by mistake. - - * "git commit --author=$name" did not tell the name that was being - recorded in the resulting commit to hooks, even though it does do - so when the end user overrode the authorship via the - "GIT_AUTHOR_NAME" environment variable. - - * When "git commit --template F" errors out because the user did not - touch the message, it claimed that it aborts due to "empty - message", which was utterly wrong. - - * The regexp configured with diff.wordregex was incorrectly reused - across files. - - * An age-old corner case bug in combine diff (only triggered with -U0 - and the hunk at the beginning of the file needs to be shown) has - been fixed. - - * Rename detection logic used to match two empty files as renames - during merge-recursive, leading to unnatural mismerges. - - * The parser in "fast-import" did not diagnose ":9" style references - that is not followed by required SP/LF as an error. - - * When "git fetch" encounters repositories with too many references, - the command line of "fetch-pack" that is run by a helper - e.g. remote-curl, may fail to hold all of them. Now such an - internal invocation can feed the references through the standard - input of "fetch-pack". - - * "git fetch" that recurses into submodules on demand did not check - if it needs to go into submodules when non branches (most notably, - tags) are fetched. - - * "log -p --graph" used with "--stat" had a few formatting error. - - * Running "notes merge --commit" failed to perform correctly when run - from any directory inside $GIT_DIR/. When "notes merge" stops with - conflicts, $GIT_DIR/NOTES_MERGE_WORKTREE is the place a user edits - to resolve it. - - * The 'push to upstream' implementation was broken in some corner - cases. "git push $there" without refspec, when the current branch - is set to push to a remote different from $there, used to push to - $there using the upstream information to a remote unrelated to - $there. - - * Giving "--continue" to a conflicted "rebase -i" session skipped a - commit that only results in changes to submodules. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.10.2.txt b/third_party/git/Documentation/RelNotes/1.7.10.2.txt deleted file mode 100644 index 7a7e9d6fd1..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.10.2.txt +++ /dev/null @@ -1,85 +0,0 @@ -Git v1.7.10.2 Release Notes -=========================== - -Fixes since v1.7.10.1 ---------------------- - - * The test scaffolding for git-daemon was flaky. - - * The test scaffolding for fast-import was flaky. - - * The filesystem boundary was not correctly reported when .git directory - discovery stopped at a mount point. - - * HTTP transport that requires authentication did not work correctly when - multiple connections are used simultaneously. - - * Minor memory leak during unpack_trees (hence "merge" and "checkout" - to check out another branch) has been plugged. - - * In the older days, the header "Conflicts:" in "cherry-pick" and "merge" - was separated by a blank line from the list of paths that follow for - readability, but when "merge" was rewritten in C, we lost it by - mistake. Remove the newline from "cherry-pick" to make them match - again. - - * The command line parser choked "git cherry-pick $name" when $name can - be both revision name and a pathname, even though $name can never be a - path in the context of the command. - - * The "include.path" facility in the configuration mechanism added in - 1.7.10 forgot to interpret "~/path" and "~user/path" as it should. - - * "git config --rename-section" to rename an existing section into a - bogus one did not check the new name. - - * The "diff --no-index" codepath used limited-length buffers, risking - pathnames getting truncated. Update it to use the strbuf API. - - * The report from "git fetch" said "new branch" even for a non branch - ref. - - * The http-backend (the server side of the smart http transfer) used - to overwrite GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL with the - value obtained from REMOTE_USER unconditionally, making it - impossible for the server side site-specific customization to use - different identity sources to affect the names logged. It now uses - REMOTE_USER only as a fallback value. - - * "log --graph" was not very friendly with "--stat" option and its - output had line breaks at wrong places. - - * Octopus merge strategy did not reduce heads that are recorded in the - final commit correctly. - - * "git push" over smart-http lost progress output a few releases ago; - this release resurrects it. - - * The error and advice messages given by "git push" when it fails due - to non-ff were not very helpful to new users; it has been broken - into three cases, and each is given a separate advice message. - - * The insn sheet given by "rebase -i" did not make it clear that the - insn lines can be re-ordered to affect the order of the commits in - the resulting history. - - * "git repack" used to write out unreachable objects as loose objects - when repacking, even if such loose objects will immediately pruned - due to its age. - - * A contrib script "rerere-train" did not work out of the box unless - user futzed with her $PATH. - - * "git rev-parse --show-prefix" used to emit nothing when run at the - top-level of the working tree, but now it gives a blank line. - - * The i18n of error message "git stash save" was not properly done. - - * "git submodule" used a sed script that some platforms mishandled. - - * When using a Perl script on a system where "perl" found on user's - $PATH could be ancient or otherwise broken, we allow builders to - specify the path to a good copy of Perl with $PERL_PATH. The - gitweb test forgot to use that Perl when running its test. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.10.3.txt b/third_party/git/Documentation/RelNotes/1.7.10.3.txt deleted file mode 100644 index 703fbf1d60..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.10.3.txt +++ /dev/null @@ -1,43 +0,0 @@ -Git v1.7.10.3 Release Notes -=========================== - -Fixes since v1.7.10.2 ---------------------- - - * The message file for German translation has been updated a bit. - - * Running "git checkout" on an unborn branch used to corrupt HEAD. - - * When checking out another commit from an already detached state, we - used to report all commits that are not reachable from any of the - refs as lossage, but some of them might be reachable from the new - HEAD, and there is no need to warn about them. - - * Some time ago, "git clone" lost the progress output for its - "checkout" phase; when run without any "--quiet" option, it should - give progress to the lengthy operation. - - * The directory path used in "git diff --no-index", when it recurses - down, was broken with a recent update after v1.7.10.1 release. - - * "log -z --pretty=tformat:..." did not terminate each record with - NUL. The fix is not entirely correct when the output also asks for - --patch and/or --stat, though. - - * The DWIM behaviour for "log --pretty=format:%gd -g" was somewhat - broken and gave undue precedence to configured log.date, causing - "git stash list" to show "stash@{time stamp string}". - - * "git status --porcelain" ignored "--branch" option by mistake. The - output for "git status --branch -z" was also incorrect and did not - terminate the record for the current branch name with NUL as asked. - - * When a submodule repository uses alternate object store mechanism, - some commands that were started from the superproject did not - notice it and failed with "No such object" errors. The subcommands - of "git submodule" command that recursed into the submodule in a - separate process were OK; only the ones that cheated and peeked - directly into the submodule's repository from the primary process - were affected. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.10.4.txt b/third_party/git/Documentation/RelNotes/1.7.10.4.txt deleted file mode 100644 index 326670df6e..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.10.4.txt +++ /dev/null @@ -1,29 +0,0 @@ -Git v1.7.10.4 Release Notes -=========================== - -Fixes since v1.7.10.3 ---------------------- - - * The message file for Swedish translation has been updated a bit. - - * A name taken from mailmap was copied into an internal buffer - incorrectly and could overun the buffer if it is too long. - - * A malformed commit object that has a header line chomped in the - middle could kill git with a NULL pointer dereference. - - * An author/committer name that is a single character was mishandled - as an invalid name by mistake. - - * The progress indicator for a large "git checkout" was sent to - stderr even if it is not a terminal. - - * "git grep -e '$pattern'", unlike the case where the patterns are - read from a file, did not treat individual lines in the given - pattern argument as separate regular expressions as it should. - - * When "git rebase" was given a bad commit to replay the history on, - its error message did not correctly give the command line argument - it had trouble parsing. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.10.5.txt b/third_party/git/Documentation/RelNotes/1.7.10.5.txt deleted file mode 100644 index 4db1770e38..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.10.5.txt +++ /dev/null @@ -1,12 +0,0 @@ -Git v1.7.10.5 Release Notes -=========================== - -Fixes since v1.7.10.4 ---------------------- - - * "git fast-export" did not give a readable error message when the - same mark erroneously appeared twice in the --import-marks input. - - * "git rebase -p" used to pay attention to rebase.autosquash which - was wrong. "git rebase -p -i" should, but "git rebase -p" by - itself should not. diff --git a/third_party/git/Documentation/RelNotes/1.7.10.txt b/third_party/git/Documentation/RelNotes/1.7.10.txt deleted file mode 100644 index 58100bf04e..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.10.txt +++ /dev/null @@ -1,219 +0,0 @@ -Git v1.7.10 Release Notes -========================= - -Compatibility Notes -------------------- - - * From this release on, the "git merge" command in an interactive - session will start an editor when it automatically resolves the - merge for the user to explain the resulting commit, just like the - "git commit" command does when it wasn't given a commit message. - - If you have a script that runs "git merge" and keeps its standard - input and output attached to the user's terminal, and if you do not - want the user to explain the resulting merge commits, you can - export GIT_MERGE_AUTOEDIT environment variable set to "no", like - this: - - #!/bin/sh - GIT_MERGE_AUTOEDIT=no - export GIT_MERGE_AUTOEDIT - - to disable this behavior (if you want your users to explain their - merge commits, you do not have to do anything). Alternatively, you - can give the "--no-edit" option to individual invocations of the - "git merge" command if you know everybody who uses your script has - Git v1.7.8 or newer. - - * The "--binary/-b" options to "git am" have been a no-op for quite a - while and were deprecated in mid 2008 (v1.6.0). When you give these - options to "git am", it will now warn and ask you not to use them. - - * When you do not tell which branches and tags to push to the "git - push" command in any way, the command used "matching refs" rule to - update remote branches and tags with branches and tags with the - same name you locally have. In future versions of Git, this will - change to push out only your current branch according to either the - "upstream" or the "current" rule. Although "upstream" may be more - powerful once the user understands Git better, the semantics - "current" gives is simpler and easier to understand for beginners - and may be a safer and better default option. We haven't decided - yet which one to switch to. - - -Updates since v1.7.9 --------------------- - -UI, Workflows & Features - - * various "gitk" updates. - - show the path to the top level directory in the window title - - update preference edit dialog - - display file list correctly when directories are given on command line - - make "git-describe" output in the log message into a clickable link - - avoid matching the UNIX timestamp part when searching all fields - - give preference to symbolic font names like sans & monospace - - allow comparing two commits using a mark - - "gitk" honors log.showroot configuration. - - * Teams for localizing the messages from the Porcelain layer of - commands are starting to form, thanks to Jiang Xin who volunteered - to be the localization coordinator. Translated messages for - simplified Chinese, Swedish and Portuguese are available. - - * The configuration mechanism learned an "include" facility; an - assignment to the include.path pseudo-variable causes the named - file to be included in-place when Git looks up configuration - variables. - - * A content filter (clean/smudge) used to be just a way to make the - recorded contents "more useful", and allowed to fail; a filter can - now optionally be marked as "required". - - * Options whose names begin with "--no-" (e.g. the "--no-verify" - option of the "git commit" command) can be negated by omitting - "no-" from its name, e.g. "git commit --verify". - - * "git am" learned to pass "-b" option to underlying "git mailinfo", so - that a bracketed string other than "PATCH" at the beginning can be kept. - - * "git clone" learned "--single-branch" option to limit cloning to a - single branch (surprise!); tags that do not point into the history - of the branch are not fetched. - - * "git clone" learned to detach the HEAD in the resulting repository - when the user specifies a tag with "--branch" (e.g., "--branch=v1.0"). - Clone also learned to print the usual "detached HEAD" advice in such - a case, similar to "git checkout v1.0". - - * When showing a patch while ignoring whitespace changes, the context - lines are taken from the postimage, in order to make it easier to - view the output. - - * "git diff --stat" learned to adjust the width of the output on - wider terminals, and give more columns to pathnames as needed. - - * "diff-highlight" filter (in contrib/) was updated to produce more - aesthetically pleasing output. - - * "fsck" learned "--no-dangling" option to omit dangling object - information. - - * "git log -G" and "git log -S" learned to pay attention to the "-i" - option. With "-i", "log -G" ignores the case when finding patch - hunks that introduce or remove a string that matches the given - pattern. Similarly with "-i", "log -S" ignores the case when - finding the commit the given block of text appears or disappears - from the file. - - * "git merge" in an interactive session learned to spawn the editor - by default to let the user edit the auto-generated merge message, - to encourage people to explain their merges better. Legacy scripts - can export GIT_MERGE_AUTOEDIT=no to retain the historical behavior. - Both "git merge" and "git pull" can be given --no-edit from the - command line to accept the auto-generated merge message. - - * The advice message given when the user didn't give enough clue on - what to merge to "git pull" and "git merge" has been updated to - be more concise and easier to understand. - - * "git push" learned the "--prune" option, similar to "git fetch". - - * The whole directory that houses a top-level superproject managed by - "git submodule" can be moved to another place. - - * "git symbolic-ref" learned the "--short" option to abbreviate the - refname it shows unambiguously. - - * "git tag --list" can be given "--points-at <object>" to limit its - output to those that point at the given object. - - * "gitweb" allows intermediate entries in the directory hierarchy - that leads to a project to be clicked, which in turn shows the - list of projects inside that directory. - - * "gitweb" learned to read various pieces of information for the - repositories lazily, instead of reading everything that could be - needed (including the ones that are not necessary for a specific - task). - - * Project search in "gitweb" shows the substring that matched in the - project name and description highlighted. - - * HTTP transport learned to authenticate with a proxy if needed. - - * A new script "diffall" is added to contrib/; it drives an - external tool to perform a directory diff of two Git revisions - in one go, unlike "difftool" that compares one file at a time. - -Foreign Interface - - * Improved handling of views, labels and branches in "git-p4" (in contrib). - - * "git-p4" (in contrib) suffered from unnecessary merge conflicts when - p4 expanded the embedded $RCS$-like keywords; it can be now told to - unexpand them. - - * Some "git-svn" updates. - - * "vcs-svn"/"svn-fe" learned to read dumps with svn-deltas and - support incremental imports. - - * "git difftool/mergetool" learned to drive DeltaWalker. - -Performance - - * Unnecessary calls to parse_object() "git upload-pack" makes in - response to "git fetch", have been eliminated, to help performance - in repositories with excessive number of refs. - -Internal Implementation (please report possible regressions) - - * Recursive call chains in "git index-pack" to deal with long delta - chains have been flattened, to reduce the stack footprint. - - * Use of add_extra_ref() API is now gone, to make it possible to - cleanly restructure the overall refs API. - - * The command line parser of "git pack-objects" now uses parse-options - API. - - * The test suite supports the new "test_pause" helper function. - - * Parallel to the test suite, there is a beginning of performance - benchmarking framework. - - * t/Makefile is adjusted to prevent newer versions of GNU make from - running tests in seemingly random order. - - * The code to check if a path points at a file beyond a symbolic link - has been restructured to be thread-safe. - - * When pruning directories that has become empty during "git prune" - and "git prune-packed", call closedir() that iterates over a - directory before rmdir() it. - -Also contains minor documentation updates and code clean-ups. - - -Fixes since v1.7.9 ------------------- - -Unless otherwise noted, all the fixes since v1.7.9 in the maintenance -releases are contained in this release (see release notes to them for -details). - - * Build with NO_PERL_MAKEMAKER was broken and Git::I18N did not work - with versions of Perl older than 5.8.3. - (merge 5eb660e ab/perl-i18n later to maint). - - * "git tag -s" honored "gpg.program" configuration variable since - 1.7.9, but "git tag -v" and "git verify-tag" didn't. - (merge a2c2506 az/verify-tag-use-gpg-config later to maint). - - * "configure" script learned to take "--with-sane-tool-path" from the - command line to record SANE_TOOL_PATH (used to avoid broken platform - tools in /usr/bin) in config.mak.autogen. This may be useful for - people on Solaris who have saner tools outside /usr/xpg[46]/bin. - - * zsh port of bash completion script needed another workaround. diff --git a/third_party/git/Documentation/RelNotes/1.7.11.1.txt b/third_party/git/Documentation/RelNotes/1.7.11.1.txt deleted file mode 100644 index 577eccaacd..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.11.1.txt +++ /dev/null @@ -1,9 +0,0 @@ -Git v1.7.11.1 Release Notes -=========================== - -Fixes since v1.7.11 -------------------- - - * The cross links in the HTML version of manual pages were broken. - -Also contains minor typofixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.11.2.txt b/third_party/git/Documentation/RelNotes/1.7.11.2.txt deleted file mode 100644 index f0cfd02d6f..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.11.2.txt +++ /dev/null @@ -1,53 +0,0 @@ -Git v1.7.11.2 Release Notes -=========================== - -Fixes since v1.7.11.1 ---------------------- - - * On Cygwin, the platform pread(2) is not thread safe, just like our - own compat/ emulation, and cannot be used in the index-pack - program. Makefile variable NO_THREAD_SAFE_PREAD can be defined to - avoid use of this function in a threaded program. - - * "git add" allows adding a regular file to the path where a - submodule used to exist, but "git update-index" does not allow an - equivalent operation to Porcelain writers. - - * "git archive" incorrectly computed the header checksum; the symptom - was observed only when using pathnames with hi-bit set. - - * "git blame" did not try to make sure that the abbreviated commit - object names in its output are unique. - - * Running "git bundle verify" on a bundle that records a complete - history said "it requires these 0 commits". - - * "git clone --single-branch" to clone a single branch did not limit - the cloning to the specified branch. - - * "git diff --no-index" did not correctly handle relative paths and - did not correctly give exit codes when run under "--quiet" option. - - * "git diff --no-index" did not work with pagers correctly. - - * "git diff COPYING HEAD:COPYING" gave a nonsense error message that - claimed that the tree-ish HEAD did not have COPYING in it. - - * When "git log" gets "--simplify-merges/by-decoration" together with - "--first-parent", the combination of these options makes the - simplification logic to use in-core commit objects that haven't - been examined for relevance, either producing incorrect result or - taking too long to produce any output. Teach the simplification - logic to ignore commits that the first-parent traversal logic - ignored when both are in effect to work around the issue. - - * "git ls-files --exclude=t -i" did not consider anything under t/ as - excluded, as it did not pay attention to exclusion of leading paths - while walking the index. Other two users of excluded() are also - updated. - - * "git request-pull $url dev" when the tip of "dev" branch was tagged - with "ext4-for-linus" used the contents from the tag in the output - but still asked the "dev" branch to be pulled, not the tag. - -Also contains minor typofixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.11.3.txt b/third_party/git/Documentation/RelNotes/1.7.11.3.txt deleted file mode 100644 index 64494f89d9..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.11.3.txt +++ /dev/null @@ -1,53 +0,0 @@ -Git v1.7.11.3 Release Notes -=========================== - -Fixes since v1.7.11.3 ---------------------- - - * The error message from "git push $there :bogo" (and its equivalent - "git push $there --delete bogo") mentioned that we tried and failed - to guess what ref is being deleted based on the LHS of the refspec, - which we don't. - - * A handful of files and directories we create had tighter than - necessary permission bits when the user wanted to have group - writability (e.g. by setting "umask 002"). - - * "commit --amend" used to refuse amending a commit with an empty log - message, with or without "--allow-empty-message". - - * "git commit --amend --only --" was meant to allow "Clever" people to - rewrite the commit message without making any change even when they - have already changes for the next commit added to their index, but - it never worked as advertised since it was introduced in 1.3.0 era. - - * Even though the index can record pathnames longer than 1<<12 bytes, - in some places we were not comparing them in full, potentially - replacing index entries instead of adding. - - * "git show"'s auto-walking behaviour was an unreliable and - unpredictable hack; it now behaves just like "git log" does when it - walks. - - * "git diff", "git status" and anything that internally uses the - comparison machinery was utterly broken when the difference - involved a file with "-" as its name. This was due to the way "git - diff --no-index" was incorrectly bolted on to the system, making - any comparison that involves a file "-" at the root level - incorrectly read from the standard input. - - * We did not have test to make sure "git rebase" without extra options - filters out an empty commit in the original history. - - * "git fast-export" produced an input stream for fast-import without - properly quoting pathnames when they contain SPs in them. - - * "git checkout --detach", when you are still on an unborn branch, - should be forbidden, but it wasn't. - - * Some implementations of Perl terminates "lines" with CRLF even when - the script is operating on just a sequence of bytes. Make sure to - use "$PERL_PATH", the version of Perl the user told Git to use, in - our tests to avoid unnecessary breakages in tests. - -Also contains minor typofixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.11.4.txt b/third_party/git/Documentation/RelNotes/1.7.11.4.txt deleted file mode 100644 index 3a640c2d4d..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.11.4.txt +++ /dev/null @@ -1,31 +0,0 @@ -Git v1.7.11.4 Release Notes -=========================== - -Fixes since v1.7.11.3 ---------------------- - - * "$GIT_DIR/COMMIT_EDITMSG" file that is used to hold the commit log - message user edits was not documented. - - * The advise() function did not use varargs correctly to format - its message. - - * When "git am" failed, old timers knew to check .git/rebase-apply/patch - to see what went wrong, but we never told the users about it. - - * "git commit-tree" learned a more natural "-p <parent> <tree>" order - of arguments long time ago, but recently forgot it by mistake. - - * "git diff --no-ext-diff" did not output anything for a typechange - filepair when GIT_EXTERNAL_DIFF is in effect. - - * In 1.7.9 era, we taught "git rebase" about the raw timestamp format - but we did not teach the same trick to "filter-branch", which rolled - a similar logic on its own. - - * When "git submodule add" clones a submodule repository, it can get - confused where to store the resulting submodule repository in the - superproject's .git/ directory when there is a symbolic link in the - path to the current directory. - -Also contains minor typofixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.11.5.txt b/third_party/git/Documentation/RelNotes/1.7.11.5.txt deleted file mode 100644 index 0a2ed855c5..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.11.5.txt +++ /dev/null @@ -1,36 +0,0 @@ -Git v1.7.11.5 Release Notes -=========================== - -Fixes since v1.7.11.4 ---------------------- - - * The Makefile rule to create assembly output (primarily for - debugging purposes) did not create it next to the source. - - * The code to avoid mistaken attempt to add the object directory - itself as its own alternate could read beyond end of a string while - comparison. - - * On some architectures, "block-sha1" did not compile correctly - when compilers inferred alignment guarantees from our source we - did not intend to make. - - * When talking to a remote running ssh on IPv6 enabled host, whose - address is spelled as "[HOST]:PORT", we did not parse the address - correctly and failed to connect. - - * git-blame.el (in compat/) have been updated to use Elisp more - correctly. - - * "git checkout <branchname>" to come back from a detached HEAD state - incorrectly computed reachability of the detached HEAD, resulting - in unnecessary warnings. - - * "git mergetool" did not support --tool-help option to give the list - of supported backends, like "git difftool" does. - - * "git grep" stopped spawning an external "grep" long time ago, but a - duplicated test to check internal and external "grep" was left - behind. - -Also contains minor typofixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.11.6.txt b/third_party/git/Documentation/RelNotes/1.7.11.6.txt deleted file mode 100644 index ba7d3c3966..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.11.6.txt +++ /dev/null @@ -1,84 +0,0 @@ -Git v1.7.11.6 Release Notes -=========================== - -Fixes since v1.7.11.5 ---------------------- - - * "ciabot" script (in contrib/) has been updated with extensive - documentation. - - * "git foo" errored out with "Not a directory" when the user had a - non-directory on $PATH, and worse yet it masked an alias "foo" from - running. - - * When the user exports a non-default IFS without HT, scripts that - rely on being able to parse "ls-files -s | while read a b c..." - started to fail. Protect them from such a misconfiguration. - - * When the user gives an argument that can be taken as both a - revision name and a pathname without disambiguating with "--", we - used to give a help message "Use '--' to separate". The message - has been clarified to show where that '--' goes on the command - line. - - * Documentation for the configuration file format had a confusing - example. - - * Older parts of the documentation described as if having a regular - file in .git/refs/ hierarchy were the only way to have branches and - tags, which is not true for quite some time. - - * It was generally understood that "--long-option"s to many of our - subcommands can be abbreviated to the unique prefix, but it was not - easy to find it described for new readers of the documentation set. - - * The "--topo-order", "--date-order" (and the lack of either means - the default order) options to "rev-list" and "log" family of - commands were poorly described in the documentation. - - * "git commit --amend" let the user edit the log message and then - died when the human-readable committer name was given - insufficiently by getpwent(3). - - * The exit status code from "git config" was way overspecified while - being incorrect. The implementation has been updated to give the - documented status for a case that was documented, and introduce a - new code for "all other errors". - - * The output from "git diff -B" for a file that ends with an - incomplete line did not put "\ No newline..." on a line of its own. - - * "git diff" had a confusion between taking data from a path in the - working tree and taking data from an object that happens to have - name 0{40} recorded in a tree. - - * The "--rebase" option to "git pull" can be abbreviated to "-r", - but we didn't document it. - - * When "git push" triggered the automatic gc on the receiving end, a - message from "git prune" that said it was removing cruft leaked to - the standard output, breaking the communication protocol. - - * The reflog entries left by "git rebase" and "git rebase -i" were - inconsistent (the interactive one gave an abbreviated object name). - - * "git send-email" did not unquote encoded words that appear on the - header correctly, and lost "_" from strings. - - * "git stash apply/pop" did not trigger "rerere" upon conflicts - unlike other mergy operations. - - * "git submodule <cmd> path" did not error out when the path to the - submodule was misspelt. - - * "git submodule update -f" did not update paths in the working tree - that has local changes. - (merge 01d4721 sz/submodule-force-update later to maint). - - * "gitweb" when used with PATH_INFO failed to notice directories with - SP (and other characters that need URL-style quoting) in them. - - * Fallback 'getpass' implementation made unportable use of stdio API. - - * A utility shell function test_seq has been added as a replacement - for the 'seq' utility found on some platforms. diff --git a/third_party/git/Documentation/RelNotes/1.7.11.7.txt b/third_party/git/Documentation/RelNotes/1.7.11.7.txt deleted file mode 100644 index e743a2a8e4..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.11.7.txt +++ /dev/null @@ -1,46 +0,0 @@ -Git v1.7.11.7 Release Notes -=========================== - -Fixes since v1.7.11.6 ---------------------- - - * The synopsis said "checkout [-B branch]" to make it clear the - branch name is a parameter to the option, but the heading for the - option description was "-B::", not "-B branch::", making the - documentation misleading. - - * Git ships with a fall-back regexp implementation for platforms with - buggy regexp library, but it was easy for people to keep using their - platform regexp. A new test has been added to check this. - - * "git apply -p0" did not parse pathnames on "diff --git" line - correctly. This caused patches that had pathnames in no other - places to be mistakenly rejected (most notably, binary patch that - does not rename nor change mode). Textual patches, renames or mode - changes have preimage and postimage pathnames in different places - in a form that can be parsed unambiguously and did not suffer from - this problem. - - * After "gitk" showed the contents of a tag, neither "Reread - references" nor "Reload" did not update what is shown as the - contents of it, when the user overwrote the tag with "git tag -f". - - * "git for-each-ref" did not correctly support more than one --sort - option. - - * "git log .." errored out saying it is both rev range and a path - when there is no disambiguating "--" is on the command line. - Update the command line parser to interpret ".." as a path in such - a case. - - * Pushing to smart HTTP server with recent Git fails without having - the username in the URL to force authentication, if the server is - configured to allow GET anonymously, while requiring authentication - for POST. - - * "git show --format='%ci'" did not give timestamp correctly for - commits created without human readable name on "committer" line. - (merge e27ddb6 jc/maint-ident-missing-human-name later to maint). - - * "git show --quiet" ought to be a synonym for "git show -s", but - wasn't. diff --git a/third_party/git/Documentation/RelNotes/1.7.11.txt b/third_party/git/Documentation/RelNotes/1.7.11.txt deleted file mode 100644 index 15b954ca4b..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.11.txt +++ /dev/null @@ -1,139 +0,0 @@ -Git v1.7.11 Release Notes -========================= - -Updates since v1.7.10 ---------------------- - -UI, Workflows & Features - - * A new mode for push, "simple", which is a cross between "current" - and "upstream", has been introduced. "git push" without any refspec - will push the current branch out to the same name at the remote - repository only when it is set to track the branch with the same - name over there. The plan is to make this mode the new default - value when push.default is not configured. - - * A couple of commands learned the "--column" option to produce - columnar output. - - * A third-party tool "git subtree" is distributed in contrib/ - - * A remote helper that acts as a proxy and caches ssl session for the - https:// transport is added to the contrib/ area. - - * Error messages given when @{u} is used for a branch without its - upstream configured have been clarified. - - * Even with the "-q"uiet option, "checkout" used to report setting up - tracking. Also "branch" learned the "-q"uiet option to squelch - informational message. - - * Your build platform may support hardlinks but you may prefer not to - use them, e.g. when installing to DESTDIR to make a tarball and - untarring on a filesystem that has poor support for hardlinks. - There is a Makefile option NO_INSTALL_HARDLINKS for you. - - * The smart-http backend used to always override GIT_COMMITTER_* - variables with REMOTE_USER and REMOTE_ADDR, but these variables are - now preserved when set. - - * "git am" learned the "--include" option, which is an opposite of - existing the "--exclude" option. - - * When "git am -3" needs to fall back to an application of the patch - to a synthesized preimage followed by a 3-way merge, the paths that - needed such treatment are now reported to the end user, so that the - result in them can be eyeballed with extra care. - - * The output from "diff/log --stat" used to always allocate 4 columns - to show the number of modified lines, but not anymore. - - * "git difftool" learned the "--dir-diff" option to spawn external - diff tools that can compare two directory hierarchies at a time - after populating two temporary directories, instead of running an - instance of the external tool once per a file pair. - - * The "fmt-merge-msg" command learned to list the primary contributors - involved in the side topic you are merging in a comment in the merge - commit template. - - * "git rebase" learned to optionally keep commits that do not - introduce any change in the original history. - - * "git push --recurse-submodules" learned to optionally look into the - histories of submodules bound to the superproject and push them - out. - - * A 'snapshot' request to "gitweb" honors If-Modified-Since: header, - based on the commit date. - - * "gitweb" learned to highlight the patch it outputs even more. - -Foreign Interface - - * "git svn" used to die with unwanted SIGPIPE when talking with an HTTP - server that uses keep-alive. - - * "git svn" learned to use platform specific authentication - providers, e.g. gnome-keyring, kwallet, etc. - - * "git p4" has been moved out of the contrib/ area and has seen more - work on importing labels as tags from (and exporting tags as labels - to) p4. - -Performance and Internal Implementation (please report possible regressions) - - * Bash completion script (in contrib/) have been cleaned up to make - future work on it simpler. - - * An experimental "version 4" format of the index file has been - introduced to reduce on-disk footprint and I/O overhead. - - * "git archive" learned to produce its output without reading the - blob object it writes out in memory in its entirety. - - * "git index-pack" that runs when fetching or pushing objects to - complete the packfile on the receiving end learned to use multiple - threads to do its job when available. - - * The code to compute hash values for lines used by the internal diff - engine was optimized on little-endian machines, using the same - trick the kernel folks came up with. - - * "git apply" had some memory leaks plugged. - - * Setting up a revision traversal with many starting points was - inefficient as these were placed in a date-order priority queue - one-by-one. Now they are collected in the queue unordered first, - and sorted immediately before getting used. - - * More lower-level commands learned to use the streaming API to read - from the object store without keeping everything in core. - - * The weighting parameters to suggestion command name typo have been - tweaked, so that "git tags" will suggest "tag?" and not "stage?". - - * Because "sh" on the user's PATH may be utterly broken on some - systems, run-command API now uses SHELL_PATH, not /bin/sh, when - spawning an external command (not applicable to Windows port). - - * The API to iterate over the refs/ hierarchy has been tweaked to - allow walking only a subset of it more efficiently. - -Also contains minor documentation updates and code clean-ups. - - -Fixes since v1.7.10 -------------------- - -Unless otherwise noted, all the fixes since v1.7.10 in the maintenance -releases are contained in this release (see release notes to them for -details). - - * "git submodule init" used to report "registered for path ..." - even for submodules that were registered earlier. - (cherry-pick c1c259e jl/submodule-report-new-path-once later to maint). - - * "git diff --stat" used to fully count a binary file with modified - execution bits whose contents is unmodified, which was not quite - right. diff --git a/third_party/git/Documentation/RelNotes/1.7.12.1.txt b/third_party/git/Documentation/RelNotes/1.7.12.1.txt deleted file mode 100644 index b8f04af19f..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.12.1.txt +++ /dev/null @@ -1,134 +0,0 @@ -Git 1.7.12.1 Release Notes -========================== - -Fixes since v1.7.12 -------------------- - - * "git apply -p0" did not parse pathnames on "diff --git" line - correctly. This caused patches that had pathnames in no other - places to be mistakenly rejected (most notably, binary patch that - does not rename nor change mode). Textual patches, renames or mode - changes have preimage and postimage pathnames in different places - in a form that can be parsed unambiguously and did not suffer from - this problem. - - * "git cherry-pick A C B" used to replay changes in A and then B and - then C if these three commits had committer timestamps in that - order, which is not what the user who said "A C B" naturally - expects. - - * "git commit --amend" let the user edit the log message and then - died when the human-readable committer name was given - insufficiently by getpwent(3). - - * Some capabilities were asked by fetch-pack even when upload-pack - did not advertise that they are available. fetch-pack has been - fixed not to do so. - - * "git diff" had a confusion between taking data from a path in the - working tree and taking data from an object that happens to have - name 0{40} recorded in a tree. - - * "git for-each-ref" did not correctly support more than one --sort - option. - - * "git log .." errored out saying it is both rev range and a path - when there is no disambiguating "--" is on the command line. - Update the command line parser to interpret ".." as a path in such - a case. - - * The "--topo-order", "--date-order" (and the lack of either means - the default order) options to "rev-list" and "log" family of - commands were poorly described in the documentation. - - * "git prune" without "-v" used to warn about leftover temporary - files (which is an indication of an earlier aborted operation). - - * Pushing to smart HTTP server with recent Git fails without having - the username in the URL to force authentication, if the server is - configured to allow GET anonymously, while requiring authentication - for POST. - - * The reflog entries left by "git rebase" and "git rebase -i" were - inconsistent (the interactive one gave an abbreviated object name). - - * When "git push" triggered the automatic gc on the receiving end, a - message from "git prune" that said it was removing cruft leaked to - the standard output, breaking the communication protocol. - - * "git show --quiet" ought to be a synonym for "git show -s", but - wasn't. - - * "git show --format='%ci'" did not give timestamp correctly for - commits created without human readable name on "committer" line. - - * "git send-email" did not unquote encoded words that appear on the - header correctly, and lost "_" from strings. - - * The interactive prompt "git send-email" gives was error prone. It - asked "What e-mail address do you want to use?" with the address it - guessed (correctly) the user would want to use in its prompt, - tempting the user to say "y". But the response was taken as "No, - please use 'y' as the e-mail address instead", which is most - certainly not what the user meant. - - * "gitweb" when used with PATH_INFO failed to notice directories with - SP (and other characters that need URL-style quoting) in them. - - * When the user gives an argument that can be taken as both a - revision name and a pathname without disambiguating with "--", we - used to give a help message "Use '--' to separate". The message - has been clarified to show where that '--' goes on the command - line. - - * When the user exports a non-default IFS without HT, scripts that - rely on being able to parse "ls-files -s | while read a b c..." - started to fail. Protect them from such a misconfiguration. - - * The attribute system may be asked for a path that itself or its - leading directories no longer exists in the working tree, and it is - fine if we cannot open .gitattribute file in such a case. Failure - to open per-directory .gitattributes with error status other than - ENOENT and ENOTDIR should be diagnosed, but it wasn't. - - * After "gitk" showed the contents of a tag, neither "Reread - references" nor "Reload" did not update what is shown as the - contents of it, when the user overwrote the tag with "git tag -f". - - * "ciabot" script (in contrib/) has been updated with extensive - documentation. - - * "git-jump" script (in contrib/) did not work well when - diff.noprefix or diff.mnemonicprefix is in effect. - - * Older parts of the documentation described as if having a regular - file in .git/refs/ hierarchy were the only way to have branches and - tags, which is not true for quite some time. - - * A utility shell function test_seq has been added as a replacement - for the 'seq' utility found on some platforms. - - * Compatibility wrapper to learn the maximum number of file - descriptors we can open around sysconf(_SC_OPEN_MAX) and - getrlimit(RLIMIT_NO_FILE) has been introduced for portability. - - * We used curl_easy_strerror() without checking version of cURL, - breaking the build for versions before curl 7.12.0. - - * Code to work around MacOS X UTF-8 gotcha has been cleaned up. - - * Fallback 'getpass' implementation made unportable use of stdio API. - - * The "--rebase" option to "git pull" can be abbreviated to "-r", - but we didn't document it. - - * It was generally understood that "--long-option"s to many of our - subcommands can be abbreviated to the unique prefix, but it was not - easy to find it described for new readers of the documentation set. - - * The synopsis said "checkout [-B branch]" to make it clear the - branch name is a parameter to the option, but the heading for the - option description was "-B::", not "-B branch::", making the - documentation misleading. - -Also contains numerous documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.12.2.txt b/third_party/git/Documentation/RelNotes/1.7.12.2.txt deleted file mode 100644 index 69255745e6..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.12.2.txt +++ /dev/null @@ -1,40 +0,0 @@ -Git 1.7.12.2 Release Notes -========================== - -Fixes since v1.7.12.1 ---------------------- - - * When "git am" is fed an input that has multiple "Content-type: ..." - header, it did not grok charset= attribute correctly. - - * Even during a conflicted merge, "git blame $path" always meant to - blame uncommitted changes to the "working tree" version; make it - more useful by showing cleanly merged parts as coming from the other - branch that is being merged. - - * "git blame MAKEFILE" run in a history that has "Makefile" but not - "MAKEFILE" should say "No such file MAKEFILE in HEAD", but got - confused on a case insensitive filesystem and failed to do so. - - * "git fetch --all", when passed "--no-tags", did not honor the - "--no-tags" option while fetching from individual remotes (the same - issue existed with "--tags", but combination "--all --tags" makes - much less sense than "--all --no-tags"). - - * "git log/diff/format-patch --stat" showed the "N line(s) added" - comment in user's locale and caused careless submitters to send - patches with such a line in them to projects whose project language - is not their language, mildly irritating others. Localization to - the line has been disabled for now. - - * "git log --all-match --grep=A --grep=B" ought to show commits that - mention both A and B, but when these three options are used with - --author or --committer, it showed commits that mention either A or - B (or both) instead. - - * The subcommand to remove the definition of a remote in "git remote" - was named "rm" even though all other subcommands were spelled out. - Introduce "git remote remove" to remove confusion, and keep "rm" as - a backward compatible synonym. - -Also contains a handful of documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.12.3.txt b/third_party/git/Documentation/RelNotes/1.7.12.3.txt deleted file mode 100644 index ecda427a35..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.12.3.txt +++ /dev/null @@ -1,34 +0,0 @@ -Git 1.7.12.3 Release Notes -========================== - -Fixes since v1.7.12.2 ---------------------- - - * "git am" mishandled a patch attached as application/octet-stream - (e.g. not text/*); Content-Transfer-Encoding (e.g. base64) was not - honored correctly. - - * It was unclear in the documentation for "git blame" that it is - unnecessary for users to use the "--follow" option. - - * A repository created with "git clone --single" had its fetch - refspecs set up just like a clone without "--single", leading the - subsequent "git fetch" to slurp all the other branches, defeating - the whole point of specifying "only this branch". - - * "git fetch" over http had an old workaround for an unlikely server - misconfiguration; it turns out that this hurts debuggability of the - configuration in general, and has been reverted. - - * "git fetch" over http advertised that it supports "deflate", which - is much less common, and did not advertise the more common "gzip" on - its Accept-Encoding header. - - * "git receive-pack" (the counterpart to "git push") did not give - progress output while processing objects it received to the puser - when run over the smart-http protocol. - - * "git status" honored the ignore=dirty settings in .gitmodules but - "git commit" didn't. - -Also contains a handful of documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.12.4.txt b/third_party/git/Documentation/RelNotes/1.7.12.4.txt deleted file mode 100644 index c6da3cc939..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.12.4.txt +++ /dev/null @@ -1,23 +0,0 @@ -Git 1.7.12.4 Release Notes -========================== - -Fixes since v1.7.12.3 ---------------------- - - * "git fetch" over the dumb-http revision walker could segfault when - curl's multi interface was used. - - * It was possible to give specific paths for "asciidoc" and other - tools in the documentation toolchain, but not for "xmlto". - - * "gitweb" did not give the correct committer timezone in its feed - output due to a typo. - - * The "-Xours" (and similarly -Xtheirs) backend option to "git - merge -s recursive" was ignored for binary files. Now it is - honored. - - * The "binary" synthetic attribute made "diff" to treat the path as - binary, but not "merge". - -Also contains many documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.12.txt b/third_party/git/Documentation/RelNotes/1.7.12.txt deleted file mode 100644 index 010d8c7de4..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.12.txt +++ /dev/null @@ -1,136 +0,0 @@ -Git v1.7.12 Release Notes -========================= - -Updates since v1.7.11 ---------------------- - -UI, Workflows & Features - - * Git can be told to normalize pathnames it read from readdir(3) and - all arguments it got from the command line into precomposed UTF-8 - (assuming that they come as decomposed UTF-8), in order to work - around issues on Mac OS. - - I think there still are other places that need conversion - (e.g. paths that are read from stdin for some commands), but this - should be a good first step in the right direction. - - * Per-user $HOME/.gitconfig file can optionally be stored in - $HOME/.config/git/config instead, which is in line with XDG. - - * The value of core.attributesfile and core.excludesfile default to - $HOME/.config/git/attributes and $HOME/.config/git/ignore respectively - when these files exist. - - * Logic to disambiguate abbreviated object names have been taught to - take advantage of object types that are expected in the context, - e.g. XXXXXX in the "git describe" output v1.2.3-gXXXXXX must be a - commit object, not a blob nor a tree. This will help us prolong - the lifetime of abbreviated object names. - - * "git apply" learned to wiggle the base version and perform three-way - merge when a patch does not exactly apply to the version you have. - - * Scripted Porcelain writers now have access to the credential API via - the "git credential" plumbing command. - - * "git help" used to always default to "man" format even on platforms - where "man" viewer is not widely available. - - * "git clone --local $path" started its life as an experiment to - optionally use link/copy when cloning a repository on the disk, but - we didn't deprecate it after we made the option a no-op to always - use the optimization. The command learned "--no-local" option to - turn this off, as a more explicit alternative over use of file:// - URL. - - * "git fetch" and friends used to say "remote side hung up - unexpectedly" when they failed to get response they expect from the - other side, but one common reason why they don't get expected - response is that the remote repository does not exist or cannot be - read. The error message in this case was updated to give better - hints to the user. - - * "git help -w $cmd" can show HTML version of documentation for - "git-$cmd" by setting help.htmlpath to somewhere other than the - default location where the build procedure installs them locally; - the variable can even point at a http:// URL. - - * "git rebase [-i] --root $tip" can now be used to rewrite all the - history leading to "$tip" down to the root commit. - - * "git rebase -i" learned "-x <cmd>" to insert "exec <cmd>" after - each commit in the resulting history. - - * "git status" gives finer classification to various states of paths - in conflicted state and offer advice messages in its output. - - * "git submodule" learned to deal with nested submodule structure - where a module is contained within a module whose origin is - specified as a relative URL to its superproject's origin. - - * A rather heavy-ish "git completion" script has been split to create - a separate "git prompting" script, to help lazy-autoloading of the - completion part while making prompting part always available. - - * "gitweb" pays attention to various forms of credits that are - similar to "Signed-off-by:" lines in the commit objects and - highlights them accordingly. - - -Foreign Interface - - * "mediawiki" remote helper (in contrib/) learned to handle file - attachments. - - * "git p4" now uses "Jobs:" and "p4 move" when appropriate. - - * vcs-svn has been updated to clean-up compilation, lift 32-bit - limitations, etc. - - -Performance, Internal Implementation, etc. (please report possible regressions) - - * Some tests showed false failures caused by a bug in ecryptofs. - - * We no longer use AsciiDoc7 syntax in our documentation and favor a - more modern style. - - * "git am --rebasing" codepath was taught to grab authorship, log - message and the patch text directly out of existing commits. This - will help rebasing commits that have confusing "diff" output in - their log messages. - - * "git index-pack" and "git pack-objects" use streaming API to read - from the object store to avoid having to hold a large blob object - in-core while they are doing their thing. - - * Code to match paths with exclude patterns learned to avoid calling - fnmatch() by comparing fixed leading substring literally when - possible. - - * "git log -n 1 -- rarely-touched-path" was spending unnecessary - cycles after showing the first change to find the next one, only to - discard it. - - * "git svn" got a large-looking code reorganization at the last - minute before the code freeze. - - -Also contains minor documentation updates and code clean-ups. - - -Fixes since v1.7.11 -------------------- - -Unless otherwise noted, all the fixes since v1.7.11 in the maintenance -releases are contained in this release (see release notes to them for -details). - - * "git submodule add" was confused when the superproject did not have - its repository in its usual place in the working tree and GIT_DIR - and GIT_WORK_TREE was used to access it. - - * "git commit --amend" let the user edit the log message and then died - when the human-readable committer name was given insufficiently by - getpwent(3). diff --git a/third_party/git/Documentation/RelNotes/1.7.2.1.txt b/third_party/git/Documentation/RelNotes/1.7.2.1.txt deleted file mode 100644 index 1103c47a4f..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.2.1.txt +++ /dev/null @@ -1,25 +0,0 @@ -Git v1.7.2.1 Release Notes -========================== - -Fixes since v1.7.2 ------------------- - - * "git instaweb" wasn't useful when your Apache was installed under a - name other than apache2 (e.g. "httpd"). - - * Similarly, "git web--browse" (invoked by "git help -w") learned that - chrome browser is sometimes called google-chrome. - - * An overlong line after ".gitdir: " in a git file caused out of bounds - access to an array on the stack. - - * "git config --path conf.var" to attempt to expand a variable conf.var - that uses "~/" short-hand segfaulted when $HOME environment variable - was not set. - - * Documentation on Cygwin failed to build. - - * The error message from "git pull blarg" when 'blarg' is an unknown - remote name has been improved. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.2.2.txt b/third_party/git/Documentation/RelNotes/1.7.2.2.txt deleted file mode 100644 index 71eb6a8b0a..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.2.2.txt +++ /dev/null @@ -1,22 +0,0 @@ -Git v1.7.2.2 Release Notes -========================== - -Fixes since v1.7.2.1 --------------------- - - * Object transfer over smart http transport deadlocked the client when - the remote HTTP server returned a failure, instead of erroring it out. - - * git-gui honors custom textconv filters when showing diff and blame; - - * git diff --relative=subdir (without the necessary trailing /) did not - work well; - - * "git diff-files -p --submodule" was recently broken; - - * "git checkout -b n ':/token'" did not work; - - * "git index-pack" (hence "git fetch/clone/pull/push") enabled the object - replacement machinery by mistake (it never should have); - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.2.3.txt b/third_party/git/Documentation/RelNotes/1.7.2.3.txt deleted file mode 100644 index 610960cfe1..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.2.3.txt +++ /dev/null @@ -1,39 +0,0 @@ -Git v1.7.2.3 Release Notes -========================== - -Fixes since v1.7.2.2 --------------------- - - * When people try insane things such as delta-compressing 4GiB files, we - threw an assertion failure. - - * "git archive" gave the full commit ID for "$Format:%h$". - - * "git fetch --tags" did not fetch tags when remote.<nick>.tagopt was set - to --no-tags. The command line option now overrides the configuration - setting. - - * "git for-each-ref --format='%(objectname:short)'" has been completely - broken for a long time. - - * "git gc" incorrectly pruned a rerere record that was created long - time ago but still is actively and repeatedly used. - - * "git log --follow -M -p" was seriously broken in 1.7.2, reporting - assertion failure. - - * Running "git log" with an incorrect option started pager nevertheless, - forcing the user to dismiss it. - - * "git rebase" did not work well when the user has diff.renames - configuration variable set. - - * An earlier (and rather old) fix to "git rebase" against a rebased - upstream broke a more normal, non rebased upstream case rather badly, - attempting to re-apply patches that are already accepted upstream. - - * "git submodule sync" forgot to update the superproject's config file - when submodule URL changed. - - * "git pack-refs --all --prune" did not remove a directory that has - become empty. diff --git a/third_party/git/Documentation/RelNotes/1.7.2.4.txt b/third_party/git/Documentation/RelNotes/1.7.2.4.txt deleted file mode 100644 index f7950a4c04..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.2.4.txt +++ /dev/null @@ -1,10 +0,0 @@ -Git v1.7.2.4 Release Notes -========================== - -This is primarily to backport support for the new "add.ignoreErrors" -name given to the existing "add.ignore-errors" configuration variable. - -The next version, Git 1.7.4, and future versions, will support both -old and incorrect name and the new corrected name, but without this -backport, users who want to use the new name "add.ignoreErrors" in -their repositories cannot use older versions of Git. diff --git a/third_party/git/Documentation/RelNotes/1.7.2.5.txt b/third_party/git/Documentation/RelNotes/1.7.2.5.txt deleted file mode 100644 index bf976c40db..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.2.5.txt +++ /dev/null @@ -1,8 +0,0 @@ -Git v1.7.2.5 Release Notes -========================== - -Fixes since v1.7.2.4 --------------------- - - * "gitweb" can sometimes be tricked into parrotting a filename argument - given in a request without properly quoting. diff --git a/third_party/git/Documentation/RelNotes/1.7.2.txt b/third_party/git/Documentation/RelNotes/1.7.2.txt deleted file mode 100644 index 15cf01178c..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.2.txt +++ /dev/null @@ -1,151 +0,0 @@ -Git v1.7.2 Release Notes -======================== - -Updates since v1.7.1 --------------------- - - * core.eol configuration and text/eol attributes are the new way to control - the end of line conventions for files in the working tree. - - * core.autocrlf has been made safer - it will now only handle line - endings for new files and files that are LF-only in the - repository. To normalize content that has been checked in with - CRLF, use the new eol/text attributes. - - * The whitespace rules used in "git apply --whitespace" and "git diff" - gained a new member in the family (tab-in-indent) to help projects with - policy to indent only with spaces. - - * When working from a subdirectory, by default, git does not look for its - metadirectory ".git" across filesystems, primarily to help people who - have invocations of git in their custom PS1 prompts, as being outside - of a git repository would look for ".git" all the way up to the root - directory, and NFS mounts are often slow. DISCOVERY_ACROSS_FILESYSTEM - environment variable can be used to tell git not to stop at a - filesystem boundary. - - * Usage help messages generated by parse-options library (i.e. most - of the Porcelain commands) are sent to the standard output now. - - * ':/<string>' notation to look for a commit now takes regular expression - and it is not anchored at the beginning of the commit log message - anymore (this is a backward incompatible change). - - * "git" wrapper learned "-c name=value" option to override configuration - variable from the command line. - - * Improved portability for various platforms including older SunOS, - HP-UX 10/11, AIX, Tru64, etc. and platforms with Python 2.4. - - * The message from "git am -3" has been improved when conflict - resolution ended up making the patch a no-op. - - * "git blame" applies the textconv filter to the contents it works - on, when available. - - * "git checkout --orphan newbranch" is similar to "-b newbranch" but - prepares to create a root commit that is not connected to any existing - commit. - - * "git cherry-pick" learned to pick a range of commits - (e.g. "cherry-pick A..B" and "cherry-pick --stdin"), so did "git - revert"; these do not support the nicer sequencing control "rebase - [-i]" has, though. - - * "git cherry-pick" and "git revert" learned --strategy option to specify - the merge strategy to be used when performing three-way merges. - - * "git cvsserver" can be told to use pserver; its password file can be - stored outside the repository. - - * The output from the textconv filter used by "git diff" can be cached to - speed up their reuse. - - * "git diff --word-diff=<mode>" extends the existing "--color-words" - option, making it more useful in color-challenged environments. - - * The regexp to detect function headers used by "git diff" for PHP has - been enhanced for visibility modifiers (public, protected, etc.) to - better support PHP5. - - * "diff.noprefix" configuration variable can be used to implicitly - ask for "diff --no-prefix" behaviour. - - * "git for-each-ref" learned "%(objectname:short)" that gives the object - name abbreviated. - - * "git format-patch" learned --signature option and format.signature - configuration variable to customize the e-mail signature used in the - output. - - * Various options to "git grep" (e.g. --count, --name-only) work better - with binary files. - - * "git grep" learned "-Ovi" to open the files with hits in your editor. - - * "git help -w" learned "chrome" and "chromium" browsers. - - * "git log --decorate" shows commit decorations in various colours. - - * "git log --follow <path>" follows across copies (it used to only follow - renames). This may make the processing more expensive. - - * "git log --pretty=format:<template>" specifier learned "% <something>" - magic that inserts a space only when %<something> expands to a - non-empty string; this is similar to "%+<something>" magic, but is - useful in a context to generate a single line output. - - * "git notes prune" learned "-n" (dry-run) and "-v" options, similar to - what "git prune" has. - - * "git patch-id" can be fed a mbox without getting confused by the - signature line in the format-patch output. - - * "git remote" learned "set-branches" subcommand. - - * "git rev-list A..B" learned --ancestry-path option to further limit - the result to the commits that are on the ancestry chain between A and - B (i.e. commits that are not descendants of A are excluded). - - * "git show -5" is equivalent to "git show --do-walk 5"; this is similar - to the update to make "git show master..next" walk the history, - introduced in 1.6.4. - - * "git status [-s] --ignored" can be used to list ignored paths. - - * "git status -s -b" shows the current branch in the output. - - * "git status" learned "--ignore-submodules" option. - - * Various "gitweb" enhancements and clean-ups, including syntax - highlighting, "plackup" support for instaweb, .fcgi suffix to run - it as FastCGI script, etc. - - * The test harness has been updated to produce TAP-friendly output. - - * Many documentation improvement patches are also included. - - -Fixes since v1.7.1 ------------------- - -All of the fixes in v1.7.1.X maintenance series are included in this -release, unless otherwise noted. - - * We didn't URL decode "file:///path/to/repo" correctly when path/to/repo - had percent-encoded characters (638794c, 9d2e942, ce83eda, 3c73a1d). - - * "git clone" did not configure remote.origin.url correctly for bare - clones (df61c889). - - * "git diff --graph" works better with "--color-words" and other options - (81fa024..4297c0a). - - * "git diff" could show ambiguous abbreviation of blob object names on - its "index" line (3e5a188). - - * "git reset --hard" started from a wrong directory and a working tree in - a nonstandard location is in use got confused (560fb6a1). - - * "git read-tree -m A B" used to switch to branch B while retaining - local changes added an incorrect cache-tree information (b1f47514). diff --git a/third_party/git/Documentation/RelNotes/1.7.3.1.txt b/third_party/git/Documentation/RelNotes/1.7.3.1.txt deleted file mode 100644 index 002c93b961..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.3.1.txt +++ /dev/null @@ -1,14 +0,0 @@ -Git v1.7.3.1 Release Notes -========================== - -Fixes since v1.7.3 ------------------- - - * "git stash show stash@{$n}" was accidentally broken in 1.7.3 ("git - stash show" without any argument still worked, though). - - * "git stash branch $branch stash@{$n}" was accidentally broken in - 1.7.3 and started dropping the named stash even when branch creation - failed. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.3.2.txt b/third_party/git/Documentation/RelNotes/1.7.3.2.txt deleted file mode 100644 index 5c93b85af4..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.3.2.txt +++ /dev/null @@ -1,5 +0,0 @@ -Git v1.7.3.2 Release Notes -========================== - -This is primarily to push out many documentation fixes accumulated since -the 1.7.3.1 release. diff --git a/third_party/git/Documentation/RelNotes/1.7.3.3.txt b/third_party/git/Documentation/RelNotes/1.7.3.3.txt deleted file mode 100644 index 9b2b2448df..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.3.3.txt +++ /dev/null @@ -1,54 +0,0 @@ -Git v1.7.3.3 Release Notes -========================== - -In addition to the usual fixes, this release also includes support for -the new "add.ignoreErrors" name given to the existing "add.ignore-errors" -configuration variable. - -The next version, Git 1.7.4, and future versions, will support both -old and incorrect name and the new corrected name, but without this -backport, users who want to use the new name "add.ignoreErrors" in -their repositories cannot use older versions of Git. - -Fixes since v1.7.3.2 --------------------- - - * "git apply" segfaulted when a bogus input is fed to it. - - * Running "git cherry-pick --ff" on a root commit segfaulted. - - * "diff", "blame" and friends incorrectly applied textconv filters to - symlinks. - - * Highlighting of whitespace breakage in "diff" output was showing - incorrect amount of whitespaces when blank-at-eol is set and the line - consisted only of whitespaces and a TAB. - - * "diff" was overly inefficient when trying to find the line to use for - the function header (i.e. equivalent to --show-c-function of GNU diff). - - * "git imap-send" depends on libcrypto but our build rule relied on the - linker to implicitly link it via libssl, which was wrong. - - * "git merge-file" can be called from within a subdirectory now. - - * "git repack -f" expanded and recompressed non-delta objects in the - existing pack, which was wasteful. Use new "-F" option if you really - want to (e.g. when changing the pack.compression level). - - * "git rev-list --format="...%x00..." incorrectly chopped its output - at NUL. - - * "git send-email" did not correctly remove duplicate mail addresses from - the Cc: header that appear on the To: header. - - * The completion script (in contrib/completion) ignored lightweight tags - in __git_ps1(). - - * "git-blame" mode (in contrib/emacs) didn't say (require 'format-spec) - even though it depends on it; it didn't work with Emacs 22 or older - unless Gnus is used. - - * "git-p4" (in contrib/) did not correctly handle deleted files. - -Other minor fixes and documentation updates are also included. diff --git a/third_party/git/Documentation/RelNotes/1.7.3.4.txt b/third_party/git/Documentation/RelNotes/1.7.3.4.txt deleted file mode 100644 index e57f7c176d..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.3.4.txt +++ /dev/null @@ -1,45 +0,0 @@ -Git v1.7.3.4 Release Notes -========================== - -Fixes since v1.7.3.3 --------------------- - - * Smart HTTP transport used to incorrectly retry redirected POST - request with GET request. - - * "git apply" did not correctly handle patches that only change modes - if told to apply while stripping leading paths with -p option. - - * "git apply" can deal with patches with timezone formatted with a - colon between the hours and minutes part (e.g. "-08:00" instead of - "-0800"). - - * "git checkout" removed an untracked file "foo" from the working - tree when switching to a branch that contains a tracked path - "foo/bar". Prevent this, just like the case where the conflicting - path were "foo" (c752e7f..7980872d). - - * "git cherry-pick" or "git revert" refused to work when a path that - would be modified by the operation was stat-dirty without a real - difference in the contents of the file. - - * "git diff --check" reported an incorrect line number for added - blank lines at the end of file. - - * "git imap-send" failed to build under NO_OPENSSL. - - * Setting log.decorate configuration variable to "0" or "1" to mean - "false" or "true" did not work. - - * "git push" over dumb HTTP protocol did not work against WebDAV - servers that did not terminate a collection name with a slash. - - * "git tag -v" did not work with GPG signatures in rfc1991 mode. - - * The post-receive-email sample hook was accidentally broken in 1.7.3.3 - update. - - * "gitweb" can sometimes be tricked into parrotting a filename argument - given in a request without properly quoting. - -Other minor fixes and documentation updates are also included. diff --git a/third_party/git/Documentation/RelNotes/1.7.3.5.txt b/third_party/git/Documentation/RelNotes/1.7.3.5.txt deleted file mode 100644 index 40f3ba5795..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.3.5.txt +++ /dev/null @@ -1,34 +0,0 @@ -Git 1.7.3.5 Release Notes -========================= - - * The xfuncname pattern used by "git diff" and "git grep" to show the - last notable line in context were broken for python and ruby for a long - time. - - * "git merge" into an unborn branch removed an untracked file "foo" from - the working tree when merged branch had "foo" (this fix was already in - 1.7.3.3 but was omitted from the release notes by mistake). - - * "git status -s" did not quote unprintable characters in paths as - documented. - - * "git am --abort" used to always reset to the commit at the beginning of - the last "am" invocation that has stopped, losing any unrelated commits - that may have been made since then. Now it refrains from doing so and - instead issues a warning. - - * "git blame" incorrectly reused bogusly cached result of textconv - filter for files from the working tree. - - * "git commit" used to abort after the user edited the log message - when the committer information was not correctly set up. It now - aborts before starting the editor. - - * "git commit --date=invalid" used to silently ignore the incorrectly - specified date; it is now diagnosed as an error. - - * "git rebase --skip" to skip the last commit in a series used to fail - to run post-rewrite hook and to copy notes from old commits that have - successfully been rebased so far. Now it do (backmerge ef88ad2). - - * "gitweb" tried to show a wrong feed logo when none was specified. diff --git a/third_party/git/Documentation/RelNotes/1.7.3.txt b/third_party/git/Documentation/RelNotes/1.7.3.txt deleted file mode 100644 index 309c33181f..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.3.txt +++ /dev/null @@ -1,76 +0,0 @@ -Git v1.7.3 Release Notes -======================== - -Updates since v1.7.2 --------------------- - - * git-gui, now at version 0.13.0, got various updates and a new - maintainer, Pat Thoyts. - - * Gitweb allows its configuration to change per each request; it used to - read the configuration once upon startup. - - * When git finds a corrupt object, it now reports the file that contains - it. - - * "git checkout -B <it>" is a shorter way to say "git branch -f <it>" - followed by "git checkout <it>". - - * When "git checkout" or "git merge" refuse to proceed in order to - protect local modification to your working tree, they used to stop - after showing just one path that might be lost. They now show all, - in a format that is easier to read. - - * "git clean" learned "-e" ("--exclude") option. - - * Hunk headers produced for C# files by "git diff" and friends show more - relevant context than before. - - * diff.ignoresubmodules configuration variable can be used to squelch the - differences in submodules reported when running commands (e.g. "diff", - "status", etc.) at the superproject level. - - * http.useragent configuration can be used to lie who you are to your - restrictive firewall. - - * "git rebase --strategy <s>" learned "-X" option to pass extra options - that are understood by the chosen merge strategy. - - * "git rebase -i" learned "exec" that you can insert into the insn sheet - to run a command between its steps. - - * "git rebase" between branches that have many binary changes that do - not conflict should be faster. - - * "git rebase -i" peeks into rebase.autosquash configuration and acts as - if you gave --autosquash from the command line. - - -Also contains various documentation updates. - - -Fixes since v1.7.2 ------------------- - -All of the fixes in v1.7.2.X maintenance series are included in this -release, unless otherwise noted. - - * "git merge -s recursive" (which is the default) did not handle cases - where a directory becomes a file (or vice versa) very well. - - * "git fetch" and friends were accidentally broken for url with "+" in - its path, e.g. "git://git.gnome.org/gtk+". - - * "git fetch $url" (i.e. without refspecs) was broken for quite some - time, if the current branch happen to be tracking some remote. - - * "git ls-tree dir dirgarbage", when "dir" was a directory, - incorrectly recursed into "dir". - - * "git note remove" created unnecessary extra commit when named object - did not have any note to begin with. - - * "git rebase" did not work well if you had diff.noprefix configured. - - * "git -c foo=bar subcmd" did not work well for subcmd that is not - implemented as a built-in command. diff --git a/third_party/git/Documentation/RelNotes/1.7.4.1.txt b/third_party/git/Documentation/RelNotes/1.7.4.1.txt deleted file mode 100644 index 79923a6d2f..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.4.1.txt +++ /dev/null @@ -1,27 +0,0 @@ -Git v1.7.4.1 Release Notes -========================== - -Fixes since v1.7.4 ------------------- - - * On Windows platform, the codepath to spawn a new child process forgot - to first flush the output buffer. - - * "git bundle" did not use OFS_DELTA encoding, making its output a few - per-cent larger than necessarily. - - * The option to tell "git clone" to recurse into the submodules was - misspelled with an underscore "--recurse_submodules". - - * "git diff --cached HEAD" before the first commit does what an end user - would expect (namely, show what would be committed without further "git - add"). - - * "git fast-import" didn't accept the command to ask for "notes" feature - to be present in its input stream, even though it was capable of the - feature. - - * "git fsck" gave up scanning loose object files in directories with - garbage files. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.4.2.txt b/third_party/git/Documentation/RelNotes/1.7.4.2.txt deleted file mode 100644 index ef4ce1fcd3..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.4.2.txt +++ /dev/null @@ -1,58 +0,0 @@ -Git v1.7.4.2 Release Notes -========================== - -Fixes since v1.7.4.1 --------------------- - - * Many documentation updates to match "git cmd -h" output and the - git-cmd manual page. - - * We used to keep one file descriptor open for each and every packfile - that we have a mmap window on it (read: "in use"), even when for very - tiny packfiles. We now close the file descriptor early when the entire - packfile fits inside one mmap window. - - * "git bisect visualize" tried to run "gitk" in windowing - environments even when "gitk" is not installed, resulting in a - strange error message. - - * "git clone /no/such/path" did not fail correctly. - - * "git commit" did not correctly error out when the user asked to use a - non existent file as the commit message template. - - * "git diff --stat -B" ran on binary files counted the changes in lines, - which was nonsensical. - - * "git diff -M" opportunistically detected copies, which was not - necessarily a good thing, especially when it is internally run by - recursive merge. - - * "git difftool" didn't tell (g)vimdiff that the files it is reading are - to be opened read-only. - - * "git merge" didn't pay attention to prepare-commit-msg hook, even - though if a merge is conflicted and manually resolved, the subsequent - "git commit" would have triggered the hook, which was inconsistent. - - * "git patch-id" (and commands like "format-patch --ignore-in-upstream" - that use it as their internal logic) handled changes to files that end - with incomplete lines incorrectly. - - * The official value to tell "git push" to push the current branch back - to update the upstream branch it forked from is now called "upstream". - The old name "tracking" is and will be supported. - - * "git submodule update" used to honor the --merge/--rebase option (or - corresponding configuration variables) even for a newly cloned - subproject, which made no sense (so/submodule-no-update-first-time). - - * gitweb's "highlight" interface mishandled tabs. - - * gitweb didn't understand timezones with GMT offset that is not - multiple of a whole hour. - - * gitweb had a few forward-incompatible syntactic constructs and - also used incorrect variable when showing the file mode in a diff. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.4.3.txt b/third_party/git/Documentation/RelNotes/1.7.4.3.txt deleted file mode 100644 index 02a3d5bdf6..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.4.3.txt +++ /dev/null @@ -1,32 +0,0 @@ -Git v1.7.4.3 Release Notes -========================== - -Fixes since v1.7.4.2 --------------------- - - * "git apply" used to confuse lines updated by previous hunks as lines - that existed before when applying a hunk, contributing misapplication - of patches with offsets. - - * "git branch --track" (and "git checkout --track --branch") used to - allow setting up a random non-branch that does not make sense to follow - as the "upstream". The command correctly diagnoses it as an error. - - * "git checkout $other_branch" silently removed untracked symbolic links - in the working tree that are in the way in order to check out paths - under it from the named branch. - - * "git cvsimport" did not bail out immediately when the cvs server cannot - be reached, spewing unnecessary error messages that complain about the - server response that it never got. - - * "git diff --quiet" did not work very well with the "--diff-filter" - option. - - * "git grep -n" lacked a long-hand synonym --line-number. - - * "git stash apply" reported the result of its operation by running - "git status" from the top-level of the working tree; it should (and - now does) run it from the user's working directory. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.4.4.txt b/third_party/git/Documentation/RelNotes/1.7.4.4.txt deleted file mode 100644 index ff06e04a58..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.4.4.txt +++ /dev/null @@ -1,35 +0,0 @@ -Git v1.7.4.4 Release Notes -========================== - -Fixes since v1.7.4.3 --------------------- - - * Compilation of sha1_file.c on BSD platforms were broken due to our - recent use of getrlimit() without including <sys/resource.h>. - - * "git config" did not diagnose incorrect configuration variable names. - - * "git format-patch" did not wrap a long subject line that resulted from - rfc2047 encoding. - - * "git instaweb" should work better again with plackup. - - * "git log --max-count=4 -Sfoobar" now shows 4 commits that changes the - number of occurrences of string "foobar"; it used to scan only for 4 - commits and then emitted only matching ones. - - * "git log --first-parent --boundary $c^..$c" segfaulted on a merge. - - * "git pull" into an empty branch should have behaved as if - fast-forwarding from emptiness to the version being pulled, with - the usual protection against overwriting untracked files. - - * "git submodule" that is run while a merge in the superproject is in - conflicted state tried to process each conflicted submodule up to - three times. - - * "git status" spent all the effort to notice racily-clean index entries - but didn't update the index file to help later operations go faster in - some cases. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.4.5.txt b/third_party/git/Documentation/RelNotes/1.7.4.5.txt deleted file mode 100644 index b7a0eeb22f..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.4.5.txt +++ /dev/null @@ -1,4 +0,0 @@ -Git v1.7.4.5 Release Notes -========================== - -This contains only minor documentation fixes accumulated since 1.7.4.4. diff --git a/third_party/git/Documentation/RelNotes/1.7.4.txt b/third_party/git/Documentation/RelNotes/1.7.4.txt deleted file mode 100644 index d5bca731b5..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.4.txt +++ /dev/null @@ -1,156 +0,0 @@ -Git v1.7.4 Release Notes -======================== - -Updates since v1.7.3 --------------------- - - * The documentation Makefile now assumes by default asciidoc 8 and - docbook-xsl >= 1.73. If you have older versions, you can set - ASCIIDOC7 and ASCIIDOC_ROFF, respectively. - - * The option parsers of various commands that create new branches (or - rename existing ones to a new name) were too loose and users were - allowed to give a branch a name that begins with a dash by creative - abuse of their command line options, which only led to burning - themselves. The name of a branch cannot begin with a dash now. - - * System-wide fallback default attributes can be stored in - /etc/gitattributes; the core.attributesfile configuration variable can - be used to customize the path to this file. - - * The thread structure generated by "git send-email" has changed - slightly. Setting the cover letter of the latest series as a reply - to the cover letter of the previous series with --in-reply-to used - to make the new cover letter and all the patches replies to the - cover letter of the previous series; this has been changed to make - the patches in the new series replies to the new cover letter. - - * The Bash completion script in contrib/ has been adjusted to be usable with - Bash 4 (options with '=value' didn't complete). It has been also made - usable with zsh. - - * Different pagers can be chosen depending on which subcommand is - being run under the pager, using the "pager.<subcommand>" variable. - - * The hardcoded tab-width of 8 that is used in whitespace breakage checks is now - configurable via the attributes mechanism. - - * Support of case insensitive filesystems (i.e. "core.ignorecase") has - been improved. For example, the gitignore mechanism didn't pay attention - to case insensitivity. - - * The <tree>:<path> syntax for naming a blob in a tree, and the :<path> - syntax for naming a blob in the index (e.g. "master:Makefile", - ":hello.c") have been extended. You can start <path> with "./" to - implicitly have the (sub)directory you are in prefixed to the - lookup. Similarly, ":../Makefile" from a subdirectory would mean - "the Makefile of the parent directory in the index". - - * "git blame" learned the --show-email option to display the e-mail - addresses instead of the names of authors. - - * "git commit" learned the --fixup and --squash options to help later invocation - of interactive rebase. - - * Command line options to "git cvsimport" whose names are in capital - letters (-A, -M, -R and -S) can now be specified as the default in - the .git/config file by their longer names (cvsimport.authorsFile, - cvsimport.mergeRegex, cvsimport.trackRevisions, cvsimport.ignorePaths). - - * "git daemon" can be built in the MinGW environment. - - * "git daemon" can take more than one --listen option to listen to - multiple addresses. - - * "git describe --exact-match" was optimized not to read commit - objects unnecessarily. - - * "git diff" and "git grep" learned what functions and subroutines - in Fortran, Pascal and Perl look like. - - * "git fetch" learned the "--recurse-submodules" option. - - * "git mergetool" tells vim/gvim to show a three-way diff by default - (use vimdiff2/gvimdiff2 as the tool name for old behavior). - - * "git log -G<pattern>" limits the output to commits whose change has - added or deleted lines that match the given pattern. - - * "git read-tree" with no argument as a way to empty the index is - deprecated; we might want to remove it in the future. Users can - use the new --empty option to be more explicit instead. - - * "git repack -f" does not spend cycles to recompress objects in the - non-delta representation anymore (use -F if you really mean it - e.g. after you changed the core.compression variable setting). - - * "git merge --log" used to limit the resulting merge log to 20 - entries; this is now customizable by giving e.g. "--log=47". - - * "git merge" may work better when all files were moved out of a - directory in one branch while a new file is created in place of that - directory in the other branch. - - * "git merge" learned the "--abort" option, synonymous to - "git reset --merge" when a merge is in progress. - - * "git notes" learned the "merge" subcommand to merge notes refs. - In addition to the default manual conflict resolution, there are - also several notes merge strategies for automatically resolving - notes merge conflicts. - - * "git rebase --autosquash" can use SHA-1 object names to name the - commit which is to be fixed up (e.g. "fixup! e83c5163"). - - * The default "recursive" merge strategy learned the --rename-threshold - option to influence the rename detection, similar to the -M option - of "git diff". From the "git merge" frontend, the "-X<strategy option>" - interface, e.g. "git merge -Xrename-threshold=50% ...", can be used - to trigger this. - - * The "recursive" strategy also learned to ignore various whitespace - changes; the most notable is -Xignore-space-at-eol. - - * "git send-email" learned "--to-cmd", similar to "--cc-cmd", to read - the recipient list from a command output. - - * "git send-email" learned to read and use "To:" from its input files. - - * you can extend "git shell", which is often used on boxes that allow - git-only login over ssh as login shell, with a custom set of - commands. - - * The current branch name in "git status" output can be colored differently - from the generic header color by setting the "color.status.branch" variable. - - * "git submodule sync" updates metainformation for all submodules, - not just the ones that have been checked out. - - * gitweb can use a custom 'highlight' command with its configuration file. - - * other gitweb updates. - - -Also contains various documentation updates. - - -Fixes since v1.7.3 ------------------- - -All of the fixes in the v1.7.3.X maintenance series are included in this -release, unless otherwise noted. - - * "git log --author=me --author=her" did not find commits written by - me or by her; instead it looked for commits written by me and by - her, which is impossible. - - * "git push --progress" shows progress indicators now. - - * "git rebase -i" showed a confusing error message when given a - branch name that does not exist. - - * "git repack" places its temporary packs under $GIT_OBJECT_DIRECTORY/pack - instead of $GIT_OBJECT_DIRECTORY/ to avoid cross directory renames. - - * "git submodule update --recursive --other-flags" passes flags down - to its subinvocations. diff --git a/third_party/git/Documentation/RelNotes/1.7.5.1.txt b/third_party/git/Documentation/RelNotes/1.7.5.1.txt deleted file mode 100644 index c6ebd76d19..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.5.1.txt +++ /dev/null @@ -1,47 +0,0 @@ -Git v1.7.5.1 Release Notes -========================== - -Fixes since v1.7.5 ------------------- - - * When an object "$tree:$path" does not exist, if $path does exist in the - subtree of $tree that corresponds to the subdirectory the user is in, - git now suggests using "$tree:./$path" in addition to the advice to use - the full path from the root of the working tree. - - * The "--date=relative" output format used to say "X years, 12 months" - when it should have said "X+1 years". - - * The smart-HTTP transfer was broken in 1.7.5 when the client needs - to issue a small POST (which uses content-length) and then a large - POST (which uses chunked) back to back. - - * "git clean" used to fail on an empty directory that is not readable, - even though rmdir(2) could remove such a directory. Now we attempt it - as the last resort. - - * The "--dirstat" option of "diff" family of commands used to totally - ignore a change that only rearranged lines within a file. Such a - change now counts as at least a minimum but non zero change. - - * The "--dirstat" option of "diff" family of commands used to use the - pathname in the original, instead of the pathname in the result, - when renames are involved. - - * "git pack-object" did not take core.bigfilethreashold into account - (unlike fast-import); now it does. - - * "git reflog" ignored options like "--format=.." on the command line. - - * "git stash apply" used to refuse to work if there was any change in - the working tree, even when the change did not overlap with the change - the stash recorded. - - * "git stash apply @{99999}" was not diagnosed as an error, even when you - did not have that many stash entries. - - * An error message from "git send-email" to diagnose a broken SMTP - connection configuration lacked a space between "hello=<smtp-domain>" - and "port=<smtp-server-port>". - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.5.2.txt b/third_party/git/Documentation/RelNotes/1.7.5.2.txt deleted file mode 100644 index 951eb7cb08..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.5.2.txt +++ /dev/null @@ -1,57 +0,0 @@ -Git v1.7.5.2 Release Notes -========================== - -The release notes to 1.7.5.1 forgot to mention: - - * "git stash -p --no-keep-index" and "git stash --no-keep-index -p" now - mean the same thing. - - * "git upload-pack" (hence "git push" over git native protocol) had a - subtle race condition that could lead to a deadlock. - -Fixes since v1.7.5.1 --------------------- - - * "git add -p" did not work correctly when a hunk is split and then - one of them was given to the editor. - - * "git add -u" did not resolve a conflict where our history deleted and - their history modified the same file, and the working tree resolved to - keep a file. - - * "git cvsimport" did not know that CVSNT stores its password file in a - location different from the traditional CVS. - - * "git diff-files" did not show the mode information from the working - tree side of an unmerged path correctly. - - * "git diff -M --cached" used to use unmerged path as a possible rename - source candidate, which made no sense. - - * The option name parser in "git fast-import" used prefix matches for - some options where it shouldn't, and accepted non-existent options, - e.g. "--relative-marksmith" or "--forceps". - - * "git format-patch" did not quote RFC822 special characters in the - email address (e.g From: Junio C. Hamano <jch@example.com>, not - From: "Junio C. Hamano" <jch@example.com>). - - * "git format-patch" when run with "--quiet" option used to produce a - nonsense result that consists of alternating empty output. - - * In "git merge", per-branch branch.<name>.mergeoptions configuration - variables did not override the fallback default merge.<option> - configuration variables such as merge.ff, merge.log, etc. - - * "git merge-one-file" did not honor GIT_WORK_TREE settings when - handling a "both sides added, differently" conflict. - - * "git mergetool" did not handle conflicted submoudules gracefully. - - * "git-p4" (in contrib) used a wrong base image while merge a file that - was added on both branches differently. - - * "git rebase -i -p" failed to preserve the history when there is a - redundant merge created with the --no-ff option. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.5.3.txt b/third_party/git/Documentation/RelNotes/1.7.5.3.txt deleted file mode 100644 index 9c03353af2..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.5.3.txt +++ /dev/null @@ -1,32 +0,0 @@ -Git v1.7.5.3 Release Notes -========================== - -Fixes since v1.7.5.2 --------------------- - - * The bash completion scripts should correctly work using zsh's bash - completion emulation layer now. - - * Setting $(prefix) in config.mak did not affect where etc/gitconfig - file is read from, even though passing it from the command line of - $(MAKE) did. - - * The logic to handle "&" (expand to UNIX username) in GECOS field - miscounted the length of the name it formatted. - - * "git cherry-pick -s resolve" failed to cherry-pick a root commit. - - * "git diff --word-diff" misbehaved when diff.suppress-blank-empty was - in effect. - - * "git log --stdin path" with an input that has additional pathspec - used to corrupt memory. - - * "git send-pack" (hence "git push") over smalt-HTTP protocol could - deadlock when the client side pack-object died early. - - * Compressed tarball gitweb generates used to be made with the timestamp - of the tarball generation; this was bad because snapshot from the same - tree should result in a same tarball. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.5.4.txt b/third_party/git/Documentation/RelNotes/1.7.5.4.txt deleted file mode 100644 index 7796df3fe4..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.5.4.txt +++ /dev/null @@ -1,21 +0,0 @@ -Git v1.7.5.4 Release Notes -========================== - -Fixes since v1.7.5.3 --------------------- - - * The single-key mode of "git add -p" was easily fooled into thinking - that it was told to add everything ('a') when up-arrow was pressed by - mistake. - - * Setting a git command that uses custom configuration via "-c var=val" - as an alias caused a crash due to a realloc(3) failure. - - * "git diff -C -C" used to disable the rename detection entirely when - there are too many copy candidate paths in the tree; now it falls - back to "-C" when doing so would keep the copy candidate paths - under the rename detection limit. - - * "git rerere" did not diagnose a corrupt MERGE_RR file in some cases. - -And other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.5.txt b/third_party/git/Documentation/RelNotes/1.7.5.txt deleted file mode 100644 index 987919c321..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.5.txt +++ /dev/null @@ -1,132 +0,0 @@ -Git v1.7.5 Release Notes -======================== - -Updates since v1.7.4 --------------------- - - * Various MinGW portability fixes. - - * Various git-p4 enhancements (in contrib). - - * Various vcs-svn, git-svn and gitk enhancements and fixes. - - * Various git-gui updates (0.14.0). - - * Update to more modern HP-UX port. - - * The codebase is getting prepared for i18n/l10n; no translated - strings nor translation mechanism in the code yet, but the strings - are being marked for l10n. - - * The bash completion script can now complete symmetric difference - for "git diff" command, e.g. "git diff ...bra<TAB>". - - * The default minimum length of abbreviated and unique object names - can now be configured by setting the core.abbrev configuration - variable. - - * "git apply -v" reports offset lines when the patch does not apply at - the exact location recorded in the diff output. - - * "git config" used to be also known as "git repo-config", but the old - name is now officially deprecated. - - * "git checkout --detach <commit>" is a more user friendly synonym for - "git checkout <commit>^0". - - * "git checkout" performed on detached HEAD gives a warning and - advice when the commit being left behind will become unreachable from - any branch or tag. - - * "git cherry-pick" and "git revert" can be told to use a custom merge - strategy, similar to "git rebase". - - * "git cherry-pick" remembers which commit failed to apply when it is - stopped by conflicts, making it unnecessary to use "commit -c $commit" - to conclude it. - - * "git cvsimport" bails out immediately when the cvs server cannot be - reached, without spewing unnecessary error messages that complain about - the server response it never got. - - * "git fetch" vs "git upload-pack" transfer learned 'no-done' - protocol extension to save one round-trip after the content - negotiation is done. This saves one HTTP RPC, reducing the overall - latency for a trivial fetch. - - * "git fetch" can be told to recursively fetch submodules on-demand. - - * "git grep -f <filename>" learned to treat "-" as "read from the - standard input stream". - - * "git grep --no-index" did not honor pathspecs correctly, returning - paths outside the specified area. - - * "git init" learned the --separate-git-dir option to allow the git - directory for a new repository created elsewhere and linked via the - gitdir mechanism. This is primarily to help submodule support later - to switch between a branch of superproject that has the submodule - and another that does not. - - * "git log" type commands now understand globbing pathspecs. You - can say "git log -- '*.txt'" for example. - - * "git log" family of commands learned --cherry and --cherry-mark - options that can be used to view two diverged branches while omitting - or highlighting equivalent changes that appear on both sides of a - symmetric difference (e.g. "log --cherry A...B"). - - * A lazy "git merge" that didn't say what to merge used to be an error. - When run on a branch that has an upstream defined, however, the command - now merges from the configured upstream. - - * "git mergetool" learned how to drive "beyond compare 3" as well. - - * "git rerere forget" without pathspec used to forget all the saved - conflicts that relate to the current merge; it now requires you to - give it pathspecs. - - * "git rev-list --objects $revs -- $pathspec" now limits the objects listed - in its output properly with the pathspec, in preparation for narrow - clones. - - * "git push" with no parameters gives better advice messages when - "tracking" is used as the push.default semantics or there is no remote - configured yet. - - * A possible value to the "push.default" configuration variable, - 'tracking', gained a synonym that more naturally describes what it - does, 'upstream'. - - * "git rerere" learned a new subcommand "remaining" that is similar to - "status" and lists the paths that had conflicts which are known to - rerere, but excludes the paths that have already been marked as - resolved in the index from its output. "git mergetool" has been - updated to use this facility. - -Also contains various documentation updates. - - -Fixes since v1.7.4 ------------------- - -All of the fixes in the v1.7.4.X maintenance series are included in this -release, unless otherwise noted. - - * "git fetch" from a client that is mostly following the remote - needlessly told all of its refs to the server for both sides to - compute the set of objects that need to be transferred efficiently, - instead of stopping when the server heard enough. In a project with - many tags, this turns out to be extremely wasteful, especially over - the smart HTTP transport (sp/maint-{upload,fetch}-pack-stop-early~1). - - * "git fetch" run from a repository that uses the same repository as - its alternate object store as the repository it is fetching from - did not tell the server that it already has access to objects - reachable from the refs in their common alternate object store, - causing it to fetch unnecessary objects (jc/maint-fetch-alt). - - * "git remote add --mirror" created a configuration that is suitable for - doing both a mirror fetch and a mirror push at the same time, which - made little sense. We now warn and require the command line to specify - either --mirror=fetch or --mirror=push. diff --git a/third_party/git/Documentation/RelNotes/1.7.6.1.txt b/third_party/git/Documentation/RelNotes/1.7.6.1.txt deleted file mode 100644 index 42e46ab17f..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.6.1.txt +++ /dev/null @@ -1,63 +0,0 @@ -Git v1.7.6.1 Release Notes -========================== - -Fixes since v1.7.6 ------------------- - - * Various codepaths that invoked zlib deflate/inflate assumed that these - functions can compress or uncompress more than 4GB data in one call on - platforms with 64-bit long, which has been corrected. - - * "git unexecutable" reported that "unexecutable" was not found, even - though the actual error was that "unexecutable" was found but did - not have a proper she-bang line to be executed. - - * Error exits from $PAGER were silently ignored. - - * "git checkout -b <branch>" was confused when attempting to create a - branch whose name ends with "-g" followed by hexadecimal digits, - and refused to work. - - * "git checkout -b <branch>" sometimes wrote a bogus reflog entry, - causing later "git checkout -" to fail. - - * "git diff --cc" learned to correctly ignore binary files. - - * "git diff -c/--cc" mishandled a deletion that resolves a conflict, and - looked in the working tree instead. - - * "git fast-export" forgot to quote pathnames with unsafe characters - in its output. - - * "git fetch" over smart-http transport used to abort when the - repository was updated between the initial connection and the - subsequent object transfer. - - * "git fetch" did not recurse into submodules in subdirectories. - - * "git ls-tree" did not error out when asked to show a corrupt tree. - - * "git pull" without any argument left an extra whitespace after the - command name in its reflog. - - * "git push --quiet" was not really quiet. - - * "git rebase -i -p" incorrectly dropped commits from side branches. - - * "git reset [<commit>] paths..." did not reset the index entry correctly - for unmerged paths. - - * "git submodule add" did not allow a relative repository path when - the superproject did not have any default remote url. - - * "git submodule foreach" failed to correctly give the standard input to - the user-supplied command it invoked. - - * submodules that the user has never showed interest in by running - "git submodule init" was incorrectly marked as interesting by "git - submodule sync". - - * "git submodule update --quiet" was not really quiet. - - * "git tag -l <glob>..." did not take multiple glob patterns from the - command line. diff --git a/third_party/git/Documentation/RelNotes/1.7.6.2.txt b/third_party/git/Documentation/RelNotes/1.7.6.2.txt deleted file mode 100644 index 67ae414965..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.6.2.txt +++ /dev/null @@ -1,8 +0,0 @@ -Git v1.7.6.2 Release Notes -========================== - -Fixes since v1.7.6.1 --------------------- - - * v1.7.6.1 broke "git push --quiet"; it used to be a no-op against an old - version of Git running on the other end, but v1.7.6.1 made it abort. diff --git a/third_party/git/Documentation/RelNotes/1.7.6.3.txt b/third_party/git/Documentation/RelNotes/1.7.6.3.txt deleted file mode 100644 index 95971831b9..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.6.3.txt +++ /dev/null @@ -1,24 +0,0 @@ -Git v1.7.6.3 Release Notes -========================== - -Fixes since v1.7.6.2 --------------------- - - * "git -c var=value subcmd" misparsed the custom configuration when - value contained an equal sign. - - * "git fetch" had a major performance regression, wasting many - needless cycles in a repository where there is no submodules - present. This was especially bad, when there were many refs. - - * "git reflog $refname" did not default to the "show" subcommand as - the documentation advertised the command to do. - - * "git reset" did not leave meaningful log message in the reflog. - - * "git status --ignored" did not show ignored items when there is no - untracked items. - - * "git tag --contains $commit" was unnecessarily inefficient. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.6.4.txt b/third_party/git/Documentation/RelNotes/1.7.6.4.txt deleted file mode 100644 index e19acac2da..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.6.4.txt +++ /dev/null @@ -1,32 +0,0 @@ -Git v1.7.6.4 Release Notes -========================== - -Fixes since v1.7.6.3 --------------------- - - * The error reporting logic of "git am" when the command is fed a file - whose mail-storage format is unknown was fixed. - - * "git branch --set-upstream @{-1} foo" did not expand @{-1} correctly. - - * "git check-ref-format --print" used to parrot a candidate string that - began with a slash (e.g. /refs/heads/master) without stripping it, to make - the result a suitably normalized string the caller can append to "$GIT_DIR/". - - * "git clone" failed to clone locally from a ".git" file that itself - is not a directory but is a pointer to one. - - * "git clone" from a local repository that borrows from another - object store using a relative path in its objects/info/alternates - file did not adjust the alternates in the resulting repository. - - * "git describe --dirty" did not refresh the index before checking the - state of the working tree files. - - * "git ls-files ../$path" that is run from a subdirectory reported errors - incorrectly when there is no such path that matches the given pathspec. - - * "git mergetool" could loop forever prompting when nothing can be read - from the standard input. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.6.5.txt b/third_party/git/Documentation/RelNotes/1.7.6.5.txt deleted file mode 100644 index 6713132a9e..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.6.5.txt +++ /dev/null @@ -1,26 +0,0 @@ -Git v1.7.6.5 Release Notes -========================== - -Fixes since v1.7.6.4 --------------------- - - * The date parser did not accept timezone designators that lack minutes - part and also has a colon between "hh:mm". - - * After fetching from a remote that has very long refname, the reporting - output could have corrupted by overrunning a static buffer. - - * "git mergetool" did not use its arguments as pathspec, but as a path to - the file that may not even have any conflict. - - * "git name-rev --all" tried to name all _objects_, naturally failing to - describe many blobs and trees, instead of showing only commits as - advertised in its documentation. - - * "git remote rename $a $b" were not careful to match the remote name - against $a (i.e. source side of the remote nickname). - - * "gitweb" used to produce a non-working link while showing the contents - of a blob, when JavaScript actions are enabled. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.6.6.txt b/third_party/git/Documentation/RelNotes/1.7.6.6.txt deleted file mode 100644 index 5343e00400..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.6.6.txt +++ /dev/null @@ -1,16 +0,0 @@ -Git v1.7.6.6 Release Notes -========================== - -Fixes since v1.7.6.5 --------------------- - - * The code to look up attributes for paths reused entries from a wrong - directory when two paths in question are in adjacent directories and - the name of the one directory is a prefix of the other. - - * When producing a "thin pack" (primarily used in bundles and smart - HTTP transfers) out of a fully packed repository, we unnecessarily - avoided sending recent objects as a delta against objects we know - the other side has. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.6.txt b/third_party/git/Documentation/RelNotes/1.7.6.txt deleted file mode 100644 index 9ec498ea39..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.6.txt +++ /dev/null @@ -1,136 +0,0 @@ -Git v1.7.6 Release Notes -======================== - -Updates since v1.7.5 --------------------- - - * Various git-svn updates. - - * Updates the way content tags are handled in gitweb. Also adds - a UI to choose common timezone for displaying the dates. - - * Similar to branch names, tagnames that begin with "-" are now - disallowed. - - * Clean-up of the C part of i18n (but not l10n---please wait) - continues. - - * The scripting part of the codebase is getting prepared for i18n/l10n. - - * Pushing and pulling from a repository with large number of refs that - point to identical commits are optimized by not listing the same commit - during the common ancestor negotiation exchange with the other side. - - * Adding a file larger than core.bigfilethreshold (defaults to 1/2 Gig) - using "git add" will send the contents straight to a packfile without - having to hold it and its compressed representation both at the same - time in memory. - - * Processes spawned by "[alias] <name> = !process" in the configuration - can inspect GIT_PREFIX environment variable to learn where in the - working tree the original command was invoked. - - * A magic pathspec ":/" tells a command that limits its operation to - the current directory when ran from a subdirectory to work on the - entire working tree. In general, ":/path/to/file" would be relative - to the root of the working tree hierarchy. - - After "git reset --hard; edit Makefile; cd t/", "git add -u" would - be a no-op, but "git add -u :/" would add the updated contents of - the Makefile at the top level. If you want to name a path in the - current subdirectory whose unusual name begins with ":/", you can - name it by "./:/that/path" or by "\:/that/path". - - * "git blame" learned "--abbrev[=<n>]" option to control the minimum - number of hexdigits shown for commit object names. - - * "git blame" learned "--line-porcelain" that is less efficient but is - easier to parse. - - * Aborting "git commit --interactive" discards updates to the index - made during the interactive session. - - * "git commit" learned a "--patch" option to directly jump to the - per-hunk selection UI of the interactive mode. - - * "git diff" and its family of commands learned --dirstat=0 to show - directories that contribute less than 0.1% of changes. - - * "git diff" and its family of commands learned --dirstat=lines mode to - assess damage to the directory based on number of lines in the patch - output, not based on the similarity numbers. - - * "git format-patch" learned "--quiet" option to suppress the output of - the names of generated files. - - * "git format-patch" quotes people's names when it has RFC822 special - characters in it, e.g. "Junio C. Hamano" <jch@example.com>. Earlier - it was up to the user to do this when using its output. - - * "git format-patch" can take an empty --subject-prefix now. - - * "git grep" learned the "-P" option to take pcre regular expressions. - - * "git log" and friends learned a new "--notes" option to replace the - "--show-notes" option. Unlike "--show-notes", "--notes=<ref>" does - not imply showing the default notes. - - * They also learned a log.abbrevCommit configuration variable to augment - the --abbrev-commit command line option. - - * "git ls-remote" learned "--exit-code" option to consider it a - different kind of error when no remote ref to be shown. - - * "git merge" learned "-" as a short-hand for "the previous branch", just - like the way "git checkout -" works. - - * "git merge" uses "merge.ff" configuration variable to decide to always - create a merge commit (i.e. --no-ff, aka merge.ff=no), refuse to create - a merge commit (i.e. --ff-only, aka merge.ff=only). Setting merge.ff=yes - (or not setting it at all) restores the default behaviour of allowing - fast-forward to happen when possible. - - * p4-import (from contrib) learned a new option --preserve-user. - - * "git read-tree -m" learned "--dry-run" option that reports if a merge - would fail without touching the index nor the working tree. - - * "git rebase" that does not specify on top of which branch to rebase - the current branch now uses @{upstream} of the current branch. - - * "git rebase" finished either normally or with --abort did not - update the reflog for HEAD to record the event to come back to - where it started from. - - * "git remote add -t only-this-branch --mirror=fetch" is now allowed. Earlier - a fetch-mode mirror meant mirror everything, but now it only means refs are - not renamed. - - * "git rev-list --count" used with "--cherry-mark" counts the cherry-picked - commits separately, producing more a useful output. - - * "git submodule update" learned "--force" option to get rid of local - changes in submodules and replace them with the up-to-date version. - - * "git status" and friends ignore .gitmodules file while the file is - still in a conflicted state during a merge, to avoid using information - that is not final and possibly corrupt with conflict markers. - -Also contains various documentation updates and minor miscellaneous -changes. - - -Fixes since v1.7.5 ------------------- - -Unless otherwise noted, all the fixes in 1.7.5.X maintenance track are -included in this release. - - * "git config" used to choke with an insanely long line. - (merge ef/maint-strbuf-init later) - - * "git diff --quiet" did not work well with --diff-filter. - (merge jk/diff-not-so-quick later) - - * "git status -z" did not default to --porcelain output format. - (merge bc/maint-status-z-to-use-porcelain later) diff --git a/third_party/git/Documentation/RelNotes/1.7.7.1.txt b/third_party/git/Documentation/RelNotes/1.7.7.1.txt deleted file mode 100644 index ac9b838e25..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.7.1.txt +++ /dev/null @@ -1,60 +0,0 @@ -Git v1.7.7.1 Release Notes -========================== - -Fixes since v1.7.7 ------------------- - - * On some BSD systems, adding +s bit on directories is detrimental - (it is not necessary on BSD to begin with). "git init --shared" - has been updated to take this into account without extra makefile - settings on platforms the Makefile knows about. - - * After incorrectly written third-party tools store a tag object in - HEAD, git diagnosed it as a repository corruption and refused to - proceed in order to avoid spreading the damage. We now gracefully - recover from such a situation by pretending as if the commit that - is pointed at by the tag were in HEAD. - - * "git apply --whitespace=error" did not bother to report the exact - line number in the patch that introduced new blank lines at the end - of the file. - - * "git apply --index" did not check corrupted patch. - - * "git checkout $tree $directory/" resurrected paths locally removed or - modified only in the working tree in $directory/ that did not appear - in $directory of the given $tree. They should have been kept intact. - - * "git diff $tree $path" used to apply the pathspec at the output stage, - reading the whole tree, wasting resources. - - * The code to check for updated submodules during a "git fetch" of the - superproject had an unnecessary quadratic loop. - - * "git fetch" from a large bundle did not enable the progress output. - - * When "git fsck --lost-and-found" found that an empty blob object in the - object store is unreachable, it incorrectly reported an error after - writing the lost blob out successfully. - - * "git filter-branch" did not refresh the index before checking that the - working tree was clean. - - * "git grep $tree" when run with multiple threads had an unsafe access to - the object database that should have been protected with mutex. - - * The "--ancestry-path" option to "git log" and friends misbehaved in a - history with complex criss-cross merges and showed an uninteresting - side history as well. - - * Test t1304 assumed LOGNAME is always set, which may not be true on - some systems. - - * Tests with --valgrind failed to find "mergetool" scriptlets. - - * "git patch-id" miscomputed the patch-id in a patch that has a line longer - than 1kB. - - * When an "exec" insn failed after modifying the index and/or the working - tree during "rebase -i", we now check and warn that the changes need to - be cleaned up. diff --git a/third_party/git/Documentation/RelNotes/1.7.7.2.txt b/third_party/git/Documentation/RelNotes/1.7.7.2.txt deleted file mode 100644 index e6bbef2f01..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.7.2.txt +++ /dev/null @@ -1,44 +0,0 @@ -Git v1.7.7.2 Release Notes -========================== - -Fixes since v1.7.7.1 --------------------- - - * We used to drop error messages from libcurl on certain kinds of - errors. - - * Error report from smart HTTP transport, when the connection was - broken in the middle of a transfer, showed a useless message on - a corrupt packet. - - * "git fetch --prune" was unsafe when used with refspecs from the - command line. - - * The attribute mechanism did not use case insensitive match when - core.ignorecase was set. - - * "git bisect" did not notice when it failed to update the working tree - to the next commit to be tested. - - * "git config --bool --get-regexp" failed to separate the variable name - and its value "true" when the variable is defined without "= true". - - * "git remote rename $a $b" were not careful to match the remote name - against $a (i.e. source side of the remote nickname). - - * "git mergetool" did not use its arguments as pathspec, but as a path to - the file that may not even have any conflict. - - * "git diff --[num]stat" used to use the number of lines of context - different from the default, potentially giving different results from - "git diff | diffstat" and confusing the users. - - * "git pull" and "git rebase" did not work well even when GIT_WORK_TREE is - set correctly with GIT_DIR if the current directory is outside the working - tree. - - * "git send-email" did not honor the configured hostname when restarting - the HELO/EHLO exchange after switching TLS on. - - * "gitweb" used to produce a non-working link while showing the contents - of a blob, when JavaScript actions are enabled. diff --git a/third_party/git/Documentation/RelNotes/1.7.7.3.txt b/third_party/git/Documentation/RelNotes/1.7.7.3.txt deleted file mode 100644 index 09301f0957..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.7.3.txt +++ /dev/null @@ -1,19 +0,0 @@ -Git v1.7.7.3 Release Notes -========================== - -Fixes since v1.7.7.2 --------------------- - - * Adjust the "quick-install-doc" procedures as preformatted - html/manpage are no longer in the source repository. - - * The logic to optimize the locality of the data in a pack introduced in - 1.7.7 was grossly inefficient. - - * The logic to filter out forked projects in the project list in - "gitweb" was broken for some time. - - * "git branch -m/-M" advertised to update RENAME_REF ref in the - commit log message that introduced the feature but not anywhere in - the documentation, and never did update such a ref anyway. This - undocumented misfeature that did not exist has been excised. diff --git a/third_party/git/Documentation/RelNotes/1.7.7.4.txt b/third_party/git/Documentation/RelNotes/1.7.7.4.txt deleted file mode 100644 index e5234485e7..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.7.4.txt +++ /dev/null @@ -1,14 +0,0 @@ -Git v1.7.7.4 Release Notes -========================== - -Fixes since v1.7.7.3 --------------------- - - * A few header dependencies were missing from the Makefile. - - * Some newer parts of the code used C99 __VA_ARGS__ while we still - try to cater to older compilers. - - * "git name-rev --all" tried to name all _objects_, naturally failing to - describe many blobs and trees, instead of showing only commits as - advertised in its documentation. diff --git a/third_party/git/Documentation/RelNotes/1.7.7.5.txt b/third_party/git/Documentation/RelNotes/1.7.7.5.txt deleted file mode 100644 index 7b0931987b..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.7.5.txt +++ /dev/null @@ -1,14 +0,0 @@ -Git v1.7.7.5 Release Notes -========================== - -Fixes since v1.7.7.4 --------------------- - - * After fetching from a remote that has very long refname, the reporting - output could have corrupted by overrunning a static buffer. - - * "git checkout" and "git merge" treated in-tree .gitignore and exclude - file in $GIT_DIR/info/ directory inconsistently when deciding which - untracked files are ignored and expendable. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.7.6.txt b/third_party/git/Documentation/RelNotes/1.7.7.6.txt deleted file mode 100644 index 8df606d452..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.7.6.txt +++ /dev/null @@ -1,20 +0,0 @@ -Git v1.7.7.6 Release Notes -========================== - -Fixes since v1.7.7.5 --------------------- - - * The code to look up attributes for paths reused entries from a wrong - directory when two paths in question are in adjacent directories and - the name of the one directory is a prefix of the other. - - * A wildcard that matches deeper hierarchy given to the "diff-index" command, - e.g. "git diff-index HEAD -- '*.txt'", incorrectly reported additions of - matching files even when there is no change. - - * When producing a "thin pack" (primarily used in bundles and smart - HTTP transfers) out of a fully packed repository, we unnecessarily - avoided sending recent objects as a delta against objects we know - the other side has. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.7.7.txt b/third_party/git/Documentation/RelNotes/1.7.7.7.txt deleted file mode 100644 index e79118d063..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.7.7.txt +++ /dev/null @@ -1,13 +0,0 @@ -Git v1.7.7.7 Release Notes -========================== - -Fixes since v1.7.7.6 --------------------- - - * An error message from 'git bundle' had an unmatched single quote pair in it. - - * 'git diff --histogram' option was not described. - - * 'git imap-send' carried an unused dead code. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.7.txt b/third_party/git/Documentation/RelNotes/1.7.7.txt deleted file mode 100644 index 6eff128c80..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.7.txt +++ /dev/null @@ -1,134 +0,0 @@ -Git v1.7.7 Release Notes -======================== - -Updates since v1.7.6 --------------------- - - * The scripting part of the codebase is getting prepared for i18n/l10n. - - * Interix, Cygwin and Minix ports got updated. - - * Various updates to git-p4 (in contrib/), fast-import, and git-svn. - - * Gitweb learned to read from /etc/gitweb-common.conf when it exists, - before reading from gitweb_config.perl or from /etc/gitweb.conf - (this last one is read only when per-repository gitweb_config.perl - does not exist). - - * Various codepaths that invoked zlib deflate/inflate assumed that these - functions can compress or uncompress more than 4GB data in one call on - platforms with 64-bit long, which has been corrected. - - * Git now recognizes loose objects written by other implementations that - use a non-standard window size for zlib deflation (e.g. Agit running on - Android with 4kb window). We used to reject anything that was not - deflated with 32kb window. - - * Interaction between the use of pager and coloring of the output has - been improved, especially when a command that is not built-in was - involved. - - * "git am" learned to pass the "--exclude=<path>" option through to underlying - "git apply". - - * You can now feed many empty lines before feeding an mbox file to - "git am". - - * "git archive" can be told to pass the output to gzip compression and - produce "archive.tar.gz". - - * "git bisect" can be used in a bare repository (provided that the test - you perform per each iteration does not need a working tree, of - course). - - * The length of abbreviated object names in "git branch -v" output - now honors the core.abbrev configuration variable. - - * "git check-attr" can take relative paths from the command line. - - * "git check-attr" learned an "--all" option to list the attributes for a - given path. - - * "git checkout" (both the code to update the files upon checking out a - different branch and the code to checkout a specific set of files) learned - to stream the data from object store when possible, without having to - read the entire contents of a file into memory first. An earlier round - of this code that is not in any released version had a large leak but - now it has been plugged. - - * "git clone" can now take a "--config key=value" option to set the - repository configuration options that affect the initial checkout. - - * "git commit <paths>..." now lets you feed relative pathspecs that - refer to outside your current subdirectory. - - * "git diff --stat" learned a --stat-count option to limit the output of - a diffstat report. - - * "git diff" learned a "--histogram" option to use a different diff - generation machinery stolen from jgit, which might give better - performance. - - * "git diff" had a weird worst case behaviour that can be triggered - when comparing files with potentially many places that could match. - - * "git fetch", "git push" and friends no longer show connection - errors for addresses that couldn't be connected to when at least one - address succeeds (this is arguably a regression but a deliberate - one). - - * "git grep" learned "--break" and "--heading" options, to let users mimic - the output format of "ack". - - * "git grep" learned a "-W" option that shows wider context using the same - logic used by "git diff" to determine the hunk header. - - * Invoking the low-level "git http-fetch" without "-a" option (which - git itself never did--normal users should not have to worry about - this) is now deprecated. - - * The "--decorate" option to "git log" and its family learned to - highlight grafted and replaced commits. - - * "git rebase master topci" no longer spews usage hints after giving - the "fatal: no such branch: topci" error message. - - * The recursive merge strategy implementation got a fairly large - fix for many corner cases that may rarely happen in real world - projects (it has been verified that none of the 16000+ merges in - the Linux kernel history back to v2.6.12 is affected with the - corner case bugs this update fixes). - - * "git stash" learned an "--include-untracked option". - - * "git submodule update" used to stop at the first error updating a - submodule; it now goes on to update other submodules that can be - updated, and reports the ones with errors at the end. - - * "git push" can be told with the "--recurse-submodules=check" option to - refuse pushing of the supermodule, if any of its submodules' - commits hasn't been pushed out to their remotes. - - * "git upload-pack" and "git receive-pack" learned to pretend that only a - subset of the refs exist in a repository. This may help a site to - put many tiny repositories into one repository (this would not be - useful for larger repositories as repacking would be problematic). - - * "git verify-pack" has been rewritten to use the "index-pack" machinery - that is more efficient in reading objects in packfiles. - - * test scripts for gitweb tried to run even when CGI-related perl modules - are not installed; they now exit early when the latter are unavailable. - -Also contains various documentation updates and minor miscellaneous -changes. - - -Fixes since v1.7.6 ------------------- - -Unless otherwise noted, all fixes in the 1.7.6.X maintenance track are -included in this release. - - * "git branch -m" and "git checkout -b" incorrectly allowed the tip - of the branch that is currently checked out updated. diff --git a/third_party/git/Documentation/RelNotes/1.7.8.1.txt b/third_party/git/Documentation/RelNotes/1.7.8.1.txt deleted file mode 100644 index 33dc948b94..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.8.1.txt +++ /dev/null @@ -1,38 +0,0 @@ -Git v1.7.8.1 Release Notes -========================== - -Fixes since v1.7.8 ------------------- - - * In some codepaths (notably, checkout and merge), the ignore patterns - recorded in $GIT_DIR/info/exclude were not honored. They now are. - - * "git apply --check" did not error out when given an empty input - without any patch. - - * "git archive" mistakenly allowed remote clients to ask for commits - that are not at the tip of any ref. - - * "git checkout" and "git merge" treated in-tree .gitignore and exclude - file in $GIT_DIR/info/ directory inconsistently when deciding which - untracked files are ignored and expendable. - - * LF-to-CRLF streaming filter used when checking out a large-ish blob - fell into an infinite loop with a rare input. - - * The function header pattern for files with "diff=cpp" attribute did - not consider "type *funcname(type param1,..." as the beginning of a - function. - - * The error message from "git diff" and "git status" when they fail - to inspect changes in submodules did not report which submodule they - had trouble with. - - * After fetching from a remote that has very long refname, the reporting - output could have corrupted by overrunning a static buffer. - - * "git pack-objects" avoids creating cyclic dependencies among deltas - when seeing a broken packfile that records the same object in both - the deflated form and as a delta. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.8.2.txt b/third_party/git/Documentation/RelNotes/1.7.8.2.txt deleted file mode 100644 index b9c66aa1b7..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.8.2.txt +++ /dev/null @@ -1,71 +0,0 @@ -Git v1.7.8.2 Release Notes -========================== - -Fixes since v1.7.8.1 --------------------- - - * Porcelain commands like "git reset" did not distinguish deletions - and type-changes from ordinary modification, and reported them with - the same 'M' moniker. They now use 'D' (for deletion) and 'T' (for - type-change) to match "git status -s" and "git diff --name-status". - - * The configuration file parser used for sizes (e.g. bigFileThreshold) - did not correctly interpret 'g' suffix. - - * The replacement implementation for snprintf used on platforms with - native snprintf that is broken did not use va_copy correctly. - - * LF-to-CRLF streaming filter replaced all LF with CRLF, which might - be technically correct but not friendly to people who are trying - to recover from earlier mistakes of using CRLF in the repository - data in the first place. It now refrains from doing so for LF that - follows a CR. - - * git native connection going over TCP (not over SSH) did not set - SO_KEEPALIVE option which failed to receive link layer errors. - - * "git branch -m <current branch> HEAD" is an obvious no-op but was not - allowed. - - * "git checkout -m" did not recreate the conflicted state in a "both - sides added, without any common ancestor version" conflict - situation. - - * "git cherry-pick $commit" (not a range) created an unnecessary - sequencer state and interfered with valid workflow to use the - command during a session to cherry-pick multiple commits. - - * You could make "git commit" segfault by giving the "--no-message" - option. - - * "fast-import" did not correctly update an existing notes tree, - possibly corrupting the fan-out. - - * "git fetch-pack" accepted unqualified refs that do not begin with - refs/ by mistake and compensated it by matching the refspec with - tail-match, which was doubly wrong. This broke fetching from a - repository with a funny named ref "refs/foo/refs/heads/master" and a - 'master' branch with "git fetch-pack refs/heads/master", as the - command incorrectly considered the former a "match". - - * "git log --follow" did not honor the rename threshold score given - with the -M option (e.g. "-M50%"). - - * "git mv" gave suboptimal error/warning messages when it overwrites - target files. It also did not pay attention to "-v" option. - - * Authenticated "git push" over dumb HTTP were broken with a recent - change and failed without asking for password when username is - given. - - * "git push" to an empty repository over HTTP were broken with a - recent change to the ref handling. - - * "git push -v" forgot how to be verbose by mistake. It now properly - becomes verbose when asked to. - - * When a "reword" action in "git rebase -i" failed to run "commit --amend", - we did not give the control back to the user to resolve the situation, and - instead kept the original commit log message. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.8.3.txt b/third_party/git/Documentation/RelNotes/1.7.8.3.txt deleted file mode 100644 index a92714c14b..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.8.3.txt +++ /dev/null @@ -1,16 +0,0 @@ -Git v1.7.8.3 Release Notes -========================== - -Fixes since v1.7.8.2 --------------------- - - * Attempt to fetch from an empty file pretending it to be a bundle did - not error out correctly. - - * gitweb did not correctly fall back to configured $fallback_encoding - that is not 'latin1'. - - * "git clone --depth $n" did not catch a non-number given as $n as an - error. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.8.4.txt b/third_party/git/Documentation/RelNotes/1.7.8.4.txt deleted file mode 100644 index 9bebdbf13d..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.8.4.txt +++ /dev/null @@ -1,23 +0,0 @@ -Git v1.7.8.4 Release Notes -========================== - -Fixes since v1.7.8.3 --------------------- - - * The code to look up attributes for paths reused entries from a wrong - directory when two paths in question are in adjacent directories and - the name of the one directory is a prefix of the other. - - * A wildcard that matches deeper hierarchy given to the "diff-index" command, - e.g. "git diff-index HEAD -- '*.txt'", incorrectly reported additions of - matching files even when there is no change. - - * When producing a "thin pack" (primarily used in bundles and smart - HTTP transfers) out of a fully packed repository, we unnecessarily - avoided sending recent objects as a delta against objects we know - the other side has. - - * "git send-email" did not properly treat sendemail.multiedit as a - boolean (e.g. setting it to "false" did not turn it off). - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.8.5.txt b/third_party/git/Documentation/RelNotes/1.7.8.5.txt deleted file mode 100644 index 011fd2a428..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.8.5.txt +++ /dev/null @@ -1,19 +0,0 @@ -Git v1.7.8.5 Release Notes -========================== - -Fixes since v1.7.8.4 --------------------- - - * Dependency on our thread-utils.h header file was missing for - objects that depend on it in the Makefile. - - * "git am" when fed an empty file did not correctly finish reading it - when it attempts to guess the input format. - - * "git grep -P" (when PCRE is enabled in the build) did not match the - beginning and the end of the line correctly with ^ and $. - - * "git rebase -m" tried to run "git notes copy" needlessly when - nothing was rewritten. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.8.6.txt b/third_party/git/Documentation/RelNotes/1.7.8.6.txt deleted file mode 100644 index d9bf2b741a..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.8.6.txt +++ /dev/null @@ -1,22 +0,0 @@ -Git v1.7.8.6 Release Notes -========================== - -Fixes since v1.7.8.5 --------------------- - - * An error message from 'git bundle' had an unmatched single quote pair in it. - - * 'git diff --histogram' option was not described. - - * Documentation for 'git rev-list' had minor formatting errors. - - * 'git imap-send' carried an unused dead code. - - * The way 'git fetch' implemented its connectivity check over - received objects was overly pessimistic, and wasted a lot of - cycles. - - * Various minor backports of fixes from the 'master' and the 'maint' - branch. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.8.txt b/third_party/git/Documentation/RelNotes/1.7.8.txt deleted file mode 100644 index 249311361e..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.8.txt +++ /dev/null @@ -1,161 +0,0 @@ -Git v1.7.8 Release Notes -======================== - -Updates since v1.7.7 --------------------- - - * Some git-svn, git-gui, git-p4 (in contrib) and msysgit updates. - - * Updates to bash completion scripts. - - * The build procedure has been taught to take advantage of computed - dependency automatically when the compiler supports it. - - * The date parser now accepts timezone designators that lack minutes - part and also has a colon between "hh:mm". - - * The contents of the /etc/mailname file, if exists, is used as the - default value of the hostname part of the committer/author e-mail. - - * "git am" learned how to read from patches generated by Hg. - - * "git archive" talking with a remote repository can report errors - from the remote side in a more informative way. - - * "git branch" learned an explicit --list option to ask for branches - listed, optionally with a glob matching pattern to limit its output. - - * "git check-attr" learned "--cached" option to look at .gitattributes - files from the index, not from the working tree. - - * Variants of "git cherry-pick" and "git revert" that take multiple - commits learned to "--continue" and "--abort". - - * "git daemon" gives more human readable error messages to clients - using ERR packets when appropriate. - - * Errors at the network layer is logged by "git daemon". - - * "git diff" learned "--minimal" option to spend extra cycles to come - up with a minimal patch output. - - * "git diff" learned "--function-context" option to show the whole - function as context that was affected by a change. - - * "git difftool" can be told to skip launching the tool for a path by - answering 'n' to its prompt. - - * "git fetch" learned to honor transfer.fsckobjects configuration to - validate the objects that were received from the other end, just like - "git receive-pack" (the receiving end of "git push") does. - - * "git fetch" makes sure that the set of objects it received from the - other end actually completes the history before updating the refs. - "git receive-pack" (the receiving end of "git push") learned to do the - same. - - * "git fetch" learned that fetching/cloning from a regular file on the - filesystem is not necessarily a request to unpack a bundle file; the - file could be ".git" with "gitdir: <path>" in it. - - * "git for-each-ref" learned "%(contents:subject)", "%(contents:body)" - and "%(contents:signature)". The last one is useful for signed tags. - - * "git grep" used to incorrectly pay attention to .gitignore files - scattered in the directory it was working in even when "--no-index" - option was used. It no longer does this. The "--exclude-standard" - option needs to be given to explicitly activate the ignore - mechanism. - - * "git grep" learned "--untracked" option, where given patterns are - searched in untracked (but not ignored) files as well as tracked - files in the working tree, so that matches in new but not yet - added files do not get missed. - - * The recursive merge backend no longer looks for meaningless - existing merges in submodules unless in the outermost merge. - - * "git log" and friends learned "--children" option. - - * "git ls-remote" learned to respond to "-h"(elp) requests. - - * "mediawiki" remote helper can interact with (surprise!) MediaWiki - with "git fetch" & "git push". - - * "git merge" learned the "--edit" option to allow users to edit the - merge commit log message. - - * "git rebase -i" can be told to use special purpose editor suitable - only for its insn sheet via sequence.editor configuration variable. - - * "git send-email" learned to respond to "-h"(elp) requests. - - * "git send-email" allows the value given to sendemail.aliasfile to begin - with "~/" to refer to the $HOME directory. - - * "git send-email" forces use of Authen::SASL::Perl to work around - issues between Authen::SASL::Cyrus and AUTH PLAIN/LOGIN. - - * "git stash" learned "--include-untracked" option to stash away - untracked/ignored cruft from the working tree. - - * "git submodule clone" does not leak an error message to the UI - level unnecessarily anymore. - - * "git submodule update" learned to honor "none" as the value for - submodule.<name>.update to specify that the named submodule should - not be checked out by default. - - * When populating a new submodule directory with "git submodule init", - the $GIT_DIR metainformation directory for submodules is created inside - $GIT_DIR/modules/<name>/ directory of the superproject and referenced - via the gitfile mechanism. This is to make it possible to switch - between commits in the superproject that has and does not have the - submodule in the tree without re-cloning. - - * "gitweb" leaked unescaped control characters from syntax hiliter - outputs. - - * "gitweb" can be told to give custom string at the end of the HTML - HEAD element. - - * "gitweb" now has its own manual pages. - - -Also contains other documentation updates and minor code cleanups. - - -Fixes since v1.7.7 ------------------- - -Unless otherwise noted, all fixes in the 1.7.7.X maintenance track are -included in this release. - - * HTTP transport did not use pushurl correctly, and also did not tell - what host it is trying to authenticate with when asking for - credentials. - (merge deba493 jk/http-auth later to maint). - - * "git blame" was aborted if started from an uncommitted content and - the path had the textconv filter in effect. - (merge 8518088 ss/blame-textconv-fake-working-tree later to maint). - - * Adding many refs to the local repository in one go (e.g. "git fetch" - that fetches many tags) and looking up a ref by name in a repository - with too many refs were unnecessarily slow. - (merge 17d68a54d jp/get-ref-dir-unsorted later to maint). - - * Report from "git commit" on untracked files was confused under - core.ignorecase option. - (merge 395c7356 jk/name-hash-dirent later to maint). - - * "git merge" did not understand ":/<pattern>" as a way to name a commit. - - " "git push" on the receiving end used to call post-receive and post-update - hooks for attempted removal of non-existing refs. - (merge 160b81ed ph/push-to-delete-nothing later to maint). - - * Help text for "git remote set-url" and "git remote set-branches" - were misspelled. - (merge c49904e fc/remote-seturl-usage-fix later to maint). - (merge 656cdf0 jc/remote-setbranches-usage-fix later to maint). diff --git a/third_party/git/Documentation/RelNotes/1.7.9.1.txt b/third_party/git/Documentation/RelNotes/1.7.9.1.txt deleted file mode 100644 index 6957183dbb..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.9.1.txt +++ /dev/null @@ -1,63 +0,0 @@ -Git v1.7.9.1 Release Notes -========================== - -Fixes since v1.7.9 ------------------- - - * The makefile allowed environment variable X seep into it result in - command names suffixed with unnecessary strings. - - * The set of included header files in compat/inet-{ntop,pton} - wrappers was updated for Windows some time ago, but in a way that - broke Solaris build. - - * rpmbuild noticed an unpackaged but installed *.mo file and failed. - - * Subprocesses spawned from various git programs were often left running - to completion even when the top-level process was killed. - - * "git add -e" learned not to show a diff for an otherwise unmodified - submodule that only has uncommitted local changes in the patch - prepared by for the user to edit. - - * Typo in "git branch --edit-description my-tpoic" was not diagnosed. - - * Using "git grep -l/-L" together with options -W or --break may not - make much sense as the output is to only count the number of hits - and there is no place for file breaks, but the latter options made - "-l/-L" to miscount the hits. - - * "git log --first-parent $pathspec" did not stay on the first parent - chain and veered into side branch from which the whole change to the - specified paths came. - - * "git merge --no-edit $tag" failed to honor the --no-edit option. - - * "git merge --ff-only $tag" failed because it cannot record the - required mergetag without creating a merge, but this is so common - operation for branch that is used _only_ to follow the upstream, so - it was changed to allow fast-forwarding without recording the mergetag. - - * "git mergetool" now gives an empty file as the common base version - to the backend when dealing with the "both sides added, differently" - case. - - * "git push -q" was not sufficiently quiet. - - * When "git push" fails to update any refs, the client side did not - report an error correctly to the end user. - - * "rebase" and "commit --amend" failed to work on commits with ancient - timestamps near year 1970. - - * When asking for a tag to be pulled, "request-pull" did not show the - name of the tag prefixed with "tags/", which would have helped older - clients. - - * "git submodule add $path" forgot to recompute the name to be stored - in .gitmodules when the submodule at $path was once added to the - superproject and already initialized. - - * Many small corner case bugs on "git tag -n" was corrected. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.9.2.txt b/third_party/git/Documentation/RelNotes/1.7.9.2.txt deleted file mode 100644 index e500da75dd..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.9.2.txt +++ /dev/null @@ -1,69 +0,0 @@ -Git v1.7.9.2 Release Notes -========================== - -Fixes since v1.7.9.1 --------------------- - - * Bash completion script (in contrib/) did not like a pattern that - begins with a dash to be passed to __git_ps1 helper function. - - * Adaptation of the bash completion script (in contrib/) for zsh - incorrectly listed all subcommands when "git <TAB><TAB>" was given - to ask for list of porcelain subcommands. - - * The build procedure for profile-directed optimized binary was not - working very well. - - * Some systems need to explicitly link -lcharset to get locale_charset(). - - * t5541 ignored user-supplied port number used for HTTP server testing. - - * The error message emitted when we see an empty loose object was - not phrased correctly. - - * The code to ask for password did not fall back to the terminal - input when GIT_ASKPASS is set but does not work (e.g. lack of X - with GUI askpass helper). - - * We failed to give the true terminal width to any subcommand when - they are invoked with the pager, i.e. "git -p cmd". - - * map_user() was not rewriting its output correctly, which resulted - in the user visible symptom that "git blame -e" sometimes showed - excess '>' at the end of email addresses. - - * "git checkout -b" did not allow switching out of an unborn branch. - - * When you have both .../foo and .../foo.git, "git clone .../foo" did not - favor the former but the latter. - - * "git commit" refused to create a commit when entries added with - "add -N" remained in the index, without telling Git what their content - in the next commit should be. We should have created the commit without - these paths. - - * "git diff --stat" said "files", "insertions", and "deletions" even - when it is showing one "file", one "insertion" or one "deletion". - - * The output from "git diff --stat" for two paths that have the same - amount of changes showed graph bars of different length due to the - way we handled rounding errors. - - * "git grep" did not pay attention to -diff (hence -binary) attribute. - - * The transport programs (fetch, push, clone)ignored --no-progress - and showed progress when sending their output to a terminal. - - * Sometimes error status detected by a check in an earlier phase of - "git receive-pack" (the other end of "git push") was lost by later - checks, resulting in false indication of success. - - * "git rev-list --verify" sometimes skipped verification depending on - the phase of the moon, which dates back to 1.7.8.x series. - - * Search box in "gitweb" did not accept non-ASCII characters correctly. - - * Search interface of "gitweb" did not show multiple matches in the same file - correctly. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.9.3.txt b/third_party/git/Documentation/RelNotes/1.7.9.3.txt deleted file mode 100644 index 91c65012f9..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.9.3.txt +++ /dev/null @@ -1,51 +0,0 @@ -Git v1.7.9.3 Release Notes -========================== - -Fixes since v1.7.9.2 --------------------- - - * "git p4" (in contrib/) submit the changes to a wrong place when the - "--use-client-spec" option is set. - - * The config.mak.autogen generated by optional autoconf support tried - to link the binary with -lintl even when libintl.h is missing from - the system. - - * When the filter driver exits before reading the content before the - main git process writes the contents to be filtered to the pipe to - it, the latter could be killed with SIGPIPE instead of ignoring - such an event as an error. - - * "git add --refresh <pathspec>" used to warn about unmerged paths - outside the given pathspec. - - * The bulk check-in codepath in "git add" streamed contents that - needs smudge/clean filters without running them, instead of punting - and delegating to the codepath to run filters after slurping - everything to core. - - * "git branch --with $that" assumed incorrectly that the user will never - ask the question with nonsense value in $that. - - * "git bundle create" produced a corrupt bundle file upon seeing - commits with excessively long subject line. - - * When a remote helper exits before reading the blank line from the - main git process to signal the end of commands, the latter could be - killed with SIGPIPE. Instead we should ignore such event as a - non-error. - - * The commit log template given with "git merge --edit" did not have - a short instructive text like what "git commit" gives. - - * "git rev-list --verify-objects -q" omitted the extra verification - it needs to do over "git rev-list --objects -q" by mistake. - - * "gitweb" used to drop warnings in the log file when "heads" view is - accessed in a repository whose HEAD does not point at a valid - branch. - - * An invalid regular expression pattern given by an end user made - "gitweb" to return garbled response. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.9.4.txt b/third_party/git/Documentation/RelNotes/1.7.9.4.txt deleted file mode 100644 index e5217a1889..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.9.4.txt +++ /dev/null @@ -1,24 +0,0 @@ -Git v1.7.9.4 Release Notes -========================== - -Fixes since v1.7.9.3 --------------------- - - * The code to synthesize the fake ancestor tree used by 3-way merge - fallback in "git am" was not prepared to read a patch created with - a non-standard -p<num> value. - - * "git bundle" did not record boundary commits correctly when there - are many of them. - - * "git diff-index" and its friends at the plumbing level showed the - "diff --git" header and nothing else for a path whose cached stat - info is dirty without actual difference when asked to produce a - patch. This was a longstanding bug that we could have fixed long - time ago. - - * "gitweb" did use quotemeta() to prepare search string when asked to - do a fixed-string project search, but did not use it by mistake and - used the user-supplied string instead. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.9.5.txt b/third_party/git/Documentation/RelNotes/1.7.9.5.txt deleted file mode 100644 index 95cc2bbf2c..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.9.5.txt +++ /dev/null @@ -1,23 +0,0 @@ -Git v1.7.9.5 Release Notes -========================== - -Fixes since v1.7.9.4 --------------------- - - * When "git config" diagnoses an error in a configuration file and - shows the line number for the offending line, it miscounted if the - error was at the end of line. - - * "git fast-import" accepted "ls" command with an empty path by - mistake. - - * Various new-ish output decoration modes of "git grep" were not - documented in the manual's synopsis section. - - * The "remaining" subcommand to "git rerere" was not documented. - - * "gitweb" used to drop warnings in the log file when "heads" view is - accessed in a repository whose HEAD does not point at a valid - branch. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.9.6.txt b/third_party/git/Documentation/RelNotes/1.7.9.6.txt deleted file mode 100644 index 74bf8825e2..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.9.6.txt +++ /dev/null @@ -1,12 +0,0 @@ -Git v1.7.9.6 Release Notes -========================== - -Fixes since v1.7.9.5 --------------------- - - * "git merge $tag" to merge an annotated tag always opens the editor - during an interactive edit session. v1.7.10 series introduced an - environment variable GIT_MERGE_AUTOEDIT to help older scripts decline - this behaviour, but the maintenance track should also support it. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.9.7.txt b/third_party/git/Documentation/RelNotes/1.7.9.7.txt deleted file mode 100644 index 59667d0f2a..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.9.7.txt +++ /dev/null @@ -1,13 +0,0 @@ -Git v1.7.9.7 Release Notes -========================== - -Fixes since v1.7.9.6 --------------------- - - * An error message from 'git bundle' had an unmatched single quote pair in it. - - * The way 'git fetch' implemented its connectivity check over - received objects was overly pessimistic, and wasted a lot of - cycles. - -Also contains minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.7.9.txt b/third_party/git/Documentation/RelNotes/1.7.9.txt deleted file mode 100644 index 95320aad5d..0000000000 --- a/third_party/git/Documentation/RelNotes/1.7.9.txt +++ /dev/null @@ -1,112 +0,0 @@ -Git v1.7.9 Release Notes -======================== - -Updates since v1.7.8 --------------------- - - * gitk updates accumulated since early 2011. - - * git-gui updated to 0.16.0. - - * git-p4 (in contrib/) updates. - - * Git uses gettext to translate its most common interface messages - into the user's language if translations are available and the - locale is appropriately set. Distributors can drop new PO files - in po/ to add new translations. - - * The code to handle username/password for HTTP transactions used in - "git push" & "git fetch" learned to talk "credential API" to - external programs to cache or store them, to allow integration with - platform native keychain mechanisms. - - * The input prompts in the terminal use our own getpass() replacement - when possible. HTTP transactions used to ask for the username without - echoing back what was typed, but with this change you will see it as - you type. - - * The internals of "revert/cherry-pick" have been tweaked to prepare - building more generic "sequencer" on top of the implementation that - drives them. - - * "git rev-parse FETCH_HEAD" after "git fetch" without specifying - what to fetch from the command line will now show the commit that - would be merged if the command were "git pull". - - * "git add" learned to stream large files directly into a packfile - instead of writing them into individual loose object files. - - * "git checkout -B <current branch> <elsewhere>" is a more intuitive - way to spell "git reset --keep <elsewhere>". - - * "git checkout" and "git merge" learned "--no-overwrite-ignore" option - to tell Git that untracked and ignored files are not expendable. - - * "git commit --amend" learned "--no-edit" option to say that the - user is amending the tree being recorded, without updating the - commit log message. - - * "git commit" and "git reset" re-learned the optimization to prime - the cache-tree information in the index, which makes it faster to - write a tree object out after the index entries are updated. - - * "git commit" detects and rejects an attempt to stuff NUL byte in - the commit log message. - - * "git commit" learned "-S" to GPG-sign the commit; this can be shown - with the "--show-signature" option to "git log". - - * fsck and prune are relatively lengthy operations that still go - silent while making the end-user wait. They learned to give progress - output like other slow operations. - - * The set of built-in function-header patterns for various languages - knows MATLAB. - - * "git log --format='<format>'" learned new %g[nNeE] specifiers to - show information from the reflog entries when walking the reflog - (i.e. with "-g"). - - * "git pull" can be used to fetch and merge an annotated/signed tag, - instead of the tip of a topic branch. The GPG signature from the - signed tag is recorded in the resulting merge commit for later - auditing. - - * "git log" learned "--show-signature" option to show the signed tag - that was merged that is embedded in the merge commit. It also can - show the signature made on the commit with "git commit -S". - - * "git branch --edit-description" can be used to add descriptive text - to explain what a topic branch is about. - - * "git fmt-merge-msg" learned to take the branch description into - account when preparing a merge summary that "git merge" records - when merging a local branch. - - * "git request-pull" has been updated to convey more information - useful for integrators to decide if a topic is worth merging and - what is pulled is indeed what the requestor asked to pull, - including: - - - the tip of the branch being requested to be merged; - - the branch description describing what the topic is about; - - the contents of the annotated tag, when requesting to pull a tag. - - * "git pull" learned to notice 'pull.rebase' configuration variable, - which serves as a global fallback for setting 'branch.<name>.rebase' - configuration variable per branch. - - * "git tag" learned "--cleanup" option to control how the whitespaces - and empty lines in tag message are cleaned up. - - * "gitweb" learned to show side-by-side diff. - -Also contains minor documentation updates and code clean-ups. - - -Fixes since v1.7.8 ------------------- - -Unless otherwise noted, all the fixes since v1.7.8 in the maintenance -releases are contained in this release (see release notes to them for -details). diff --git a/third_party/git/Documentation/RelNotes/1.8.0.1.txt b/third_party/git/Documentation/RelNotes/1.8.0.1.txt deleted file mode 100644 index 1f372fa0b5..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.0.1.txt +++ /dev/null @@ -1,64 +0,0 @@ -Git v1.8.0.1 Release Notes -========================== - -Fixes since v1.8.0 ------------------- - - * The configuration parser had an unnecessary hardcoded limit on - variable names that was not checked consistently. - - * The "say" function in the test scaffolding incorrectly allowed - "echo" to interpret "\a" as if it were a C-string asking for a - BEL output. - - * "git mergetool" feeds /dev/null as a common ancestor when dealing - with an add/add conflict, but p4merge backend cannot handle - it. Work it around by passing a temporary empty file. - - * "git log -F -E --grep='<ere>'" failed to use the given <ere> - pattern as extended regular expression, and instead looked for the - string literally. - - * "git grep -e pattern <tree>" asked the attribute system to read - "<tree>:.gitattributes" file in the working tree, which was - nonsense. - - * A symbolic ref refs/heads/SYM was not correctly removed with "git - branch -d SYM"; the command removed the ref pointed by SYM - instead. - - * Earlier we fixed documentation to hyphenate "remote-tracking branch" - to clarify that these are not a remote entity, but unhyphenated - spelling snuck in to a few places since then. - - * "git pull --rebase" run while the HEAD is detached tried to find - the upstream branch of the detached HEAD (which by definition - does not exist) and emitted unnecessary error messages. - - * The refs/replace hierarchy was not mentioned in the - repository-layout docs. - - * Sometimes curl_multi_timeout() function suggested a wrong timeout - value when there is no file descriptors to wait on and the http - transport ended up sleeping for minutes in select(2) system call. - A workaround has been added for this. - - * Various rfc2047 quoting issues around a non-ASCII name on the - From: line in the output from format-patch have been corrected. - - * "git diff -G<pattern>" did not honor textconv filter when looking - for changes. - - * Bash completion script (in contrib/) did not correctly complete a - lazy "git checkout $name_of_remote_tracking_branch_that_is_unique" - command line. - - * RSS feed from "gitweb" had a xss hole in its title output. - - * "git config --path $key" segfaulted on "[section] key" (a boolean - "true" spelled without "=", not "[section] key = true"). - - * "git checkout -b foo" while on an unborn branch did not say - "Switched to a new branch 'foo'" like other cases. - -Also contains other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.8.0.2.txt b/third_party/git/Documentation/RelNotes/1.8.0.2.txt deleted file mode 100644 index 8497e051de..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.0.2.txt +++ /dev/null @@ -1,34 +0,0 @@ -Git v1.8.0.2 Release Notes -========================== - -Fixes since v1.8.0.1 --------------------- - - * Various codepaths have workaround for a common misconfiguration to - spell "UTF-8" as "utf8", but it was not used uniformly. Most - notably, mailinfo (which is used by "git am") lacked this support. - - * We failed to mention a file without any content change but whose - permission bit was modified, or (worse yet) a new file without any - content in the "git diff --stat" output. - - * When "--stat-count" hides a diffstat for binary contents, the total - number of added and removed lines at the bottom was computed - incorrectly. - - * When "--stat-count" hides a diffstat for unmerged paths, the total - number of affected files at the bottom of the "diff --stat" output - was computed incorrectly. - - * "diff --shortstat" miscounted the total number of affected files - when there were unmerged paths. - - * "git p4" used to try expanding malformed "$keyword$" that spans - across multiple lines. - - * "git update-ref -d --deref SYM" to delete a ref through a symbolic - ref that points to it did not remove it correctly. - - * Syntax highlighting in "gitweb" was not quite working. - -Also contains other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.8.0.3.txt b/third_party/git/Documentation/RelNotes/1.8.0.3.txt deleted file mode 100644 index 92b1e4b363..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.0.3.txt +++ /dev/null @@ -1,14 +0,0 @@ -Git v1.8.0.3 Release Notes -========================== - -Fixes since v1.8.0.2 --------------------- - - * "git log -p -S<string>" did not apply the textconv filter while - looking for the <string>. - - * In the documentation, some invalid example e-mail addresses were - formatted into mailto: links. - -Also contains many documentation updates backported from the 'master' -branch that is preparing for the upcoming 1.8.1 release. diff --git a/third_party/git/Documentation/RelNotes/1.8.0.txt b/third_party/git/Documentation/RelNotes/1.8.0.txt deleted file mode 100644 index 43883c14f0..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.0.txt +++ /dev/null @@ -1,267 +0,0 @@ -Git v1.8.0 Release Notes -======================== - -Backward compatibility notes ----------------------------- - -In the next major release (not *this* one), we will change the -behavior of the "git push" command. - -When "git push [$there]" does not say what to push, we have used the -traditional "matching" semantics so far (all your branches were sent -to the remote as long as there already are branches of the same name -over there). We will use the "simple" semantics that pushes the -current branch to the branch with the same name, only when the current -branch is set to integrate with that remote branch. There is a user -preference configuration variable "push.default" to change this, and -"git push" will warn about the upcoming change until you set this -variable in this release. - -"git branch --set-upstream" is deprecated and may be removed in a -relatively distant future. "git branch [-u|--set-upstream-to]" has -been introduced with a saner order of arguments. - - -Updates since v1.7.12 ---------------------- - -UI, Workflows & Features - - * A credential helper for Win32 to allow access to the keychain of - the logged-in user has been added. - - * An initial port to HP NonStop. - - * A credential helper to allow access to the Gnome keyring has been - added. - - * When "git am" sanitizes the "Subject:" line, we strip the prefix from - "Re: subject" and also from a less common "re: subject", but left - the even less common "RE: subject" intact. Now we strip that too. - - * It was tempting to say "git branch --set-upstream origin/master", - but that tells Git to arrange the local branch "origin/master" to - integrate with the currently checked out branch, which is highly - unlikely what the user meant. The option is deprecated; use the - new "--set-upstream-to" (with a short-and-sweet "-u") option - instead. - - * "git cherry-pick" learned the "--allow-empty-message" option to - allow it to replay a commit without any log message. - - * After "git cherry-pick -s" gave control back to the user asking - help to resolve conflicts, concluding "git commit" used to need to - be run with "-s" if the user wants to sign it off; now the command - leaves the sign-off line in the log template. - - * "git daemon" learned the "--access-hook" option to allow an - external command to decline service based on the client address, - repository path, etc. - - * "git difftool --dir-diff" learned to use symbolic links to prepare - a temporary copy of the working tree when available. - - * "git grep" learned to use a non-standard pattern type by default if - a configuration variable tells it to. - - * Accumulated updates to "git gui" has been merged. - - * "git log -g" learned the "--grep-reflog=<pattern>" option to limit - its output to commits with a reflog message that matches the given - pattern. - - * "git merge-base" learned the "--is-ancestor A B" option to tell if A is - an ancestor of B. The result is indicated by its exit status code. - - * "git mergetool" now allows users to override the actual command used - with the mergetool.$name.cmd configuration variable even for built-in - mergetool backends. - - * "git rebase -i" learned the "--edit-todo" option to open an editor - to edit the instruction sheet. - - -Foreign Interface - - * "git svn" has been updated to work with SVN 1.7. - - * "git p4" learned the "--conflicts" option to specify what to do when - encountering a conflict during "p4 submit". - - -Performance, Internal Implementation, etc. - - * Git ships with a fall-back regexp implementation for platforms with - buggy regexp library, but it was easy for people to keep using their - platform regexp by mistake. A new test has been added to check this. - - * The "check-docs" build target has been updated and greatly - simplified. - - * The test suite is run under MALLOC_CHECK_ when running with a glibc - that supports the feature. - - * The documentation in the TeXinfo format was using indented output - for materials meant to be examples that are better typeset in - monospace. - - * Compatibility wrapper around some mkdir(2) implementations that - reject parameters with trailing slash has been introduced. - - * Compatibility wrapper for systems that lack usable setitimer() has - been added. - - * The option parsing of "git checkout" had error checking, dwim and - defaulting missing options, all mixed in the code, and issuing an - appropriate error message with useful context was getting harder. - The code has been reorganized to allow giving a proper diagnosis - when the user says "git checkout -b -t foo bar" (e.g. "-t" is not a - good name for a branch). - - * Many internal uses of a "git merge-base" equivalent were only to see - if one commit fast-forwards to the other, which did not need the - full set of merge bases to be computed. They have been updated to - use less expensive checks. - - * The heuristics to detect and silently convert latin1 to utf8 when - we were told to use utf-8 in the log message has been transplanted - from "mailinfo" to "commit" and "commit-tree". - - * Messages given by "git <subcommand> -h" from many subcommands have - been marked for translation. - - -Also contains minor documentation updates and code clean-ups. - - -Fixes since v1.7.12 -------------------- - -Unless otherwise noted, all the fixes since v1.7.12 in the -maintenance track are contained in this release (see release notes -to them for details). - - * The attribute system may be asked for a path that itself or its - leading directories no longer exists in the working tree, and it is - fine if we cannot open .gitattribute file in such a case. Failure - to open per-directory .gitattributes with error status other than - ENOENT and ENOTDIR should be diagnosed, but it wasn't. - - * When looking for $HOME/.gitconfig etc., it is OK if we cannot read - them because they do not exist, but we did not diagnose existing - files that we cannot read. - - * When "git am" is fed an input that has multiple "Content-type: ..." - header, it did not grok charset= attribute correctly. - - * "git am" mishandled a patch attached as application/octet-stream - (e.g. not text/*); Content-Transfer-Encoding (e.g. base64) was not - honored correctly. - - * "git blame MAKEFILE" run in a history that has "Makefile" but not - "MAKEFILE" should say "No such file MAKEFILE in HEAD", but got - confused on a case insensitive filesystem and failed to do so. - - * Even during a conflicted merge, "git blame $path" always meant to - blame uncommitted changes to the "working tree" version; make it - more useful by showing cleanly merged parts as coming from the other - branch that is being merged. - - * It was unclear in the documentation for "git blame" that it is - unnecessary for users to use the "--follow" option. - - * Output from "git branch -v" contains "(no branch)" that could be - localized, but the code to align it along with the names of - branches was counting in bytes, not in display columns. - - * "git cherry-pick A C B" used to replay changes in A and then B and - then C if these three commits had committer timestamps in that - order, which is not what the user who said "A C B" naturally - expects. - - * A repository created with "git clone --single" had its fetch - refspecs set up just like a clone without "--single", leading the - subsequent "git fetch" to slurp all the other branches, defeating - the whole point of specifying "only this branch". - - * Documentation talked about "first line of commit log" when it meant - the title of the commit. The description was clarified by defining - how the title is decided and rewording the casual mention of "first - line" to "title". - - * "git cvsimport" did not thoroughly cleanse tag names that it - inferred from the names of the tags it obtained from CVS, which - caused "git tag" to barf and stop the import in the middle. - - * Earlier we made the diffstat summary line that shows the number of - lines added/deleted localizable, but it was found irritating having - to see them in various languages on a list whose discussion language - is English, and this change has been reverted. - - * "git fetch --all", when passed "--no-tags", did not honor the - "--no-tags" option while fetching from individual remotes (the same - issue existed with "--tags", but the combination "--all --tags" makes - much less sense than "--all --no-tags"). - - * "git fetch" over http had an old workaround for an unlikely server - misconfiguration; it turns out that this hurts debuggability of the - configuration in general, and has been reverted. - - * "git fetch" over http advertised that it supports "deflate", which - is much less common, and did not advertise the more common "gzip" on - its Accept-Encoding header. - - * "git fetch" over the dumb-http revision walker could segfault when - curl's multi interface was used. - - * "git gc --auto" notified the user that auto-packing has triggered - even under the "--quiet" option. - - * After "gitk" showed the contents of a tag, neither "Reread - references" nor "Reload" updated what is shown as the - contents of it when the user overwrote the tag with "git tag -f". - - * "git log --all-match --grep=A --grep=B" ought to show commits that - mention both A and B, but when these three options are used with - --author or --committer, it showed commits that mention either A or - B (or both) instead. - - * The "-Xours" backend option to "git merge -s recursive" was ignored - for binary files. - - * "git p4", when "--use-client-spec" and "--detect-branches" are used - together, misdetected branches. - - * "git receive-pack" (the counterpart to "git push") did not give - progress output while processing objects it received to the puser - when run over the smart-http protocol. - - * When you misspell the command name you give to the "exec" action in - the "git rebase -i" instruction sheet you were told that 'rebase' is not a - git subcommand from "git rebase --continue". - - * The subcommand in "git remote" to remove a defined remote was - "rm" and the command did not take a fully-spelled "remove". - - * The interactive prompt that "git send-email" gives was error prone. It - asked "What e-mail address do you want to use?" with the address it - guessed (correctly) the user would want to use in its prompt, - tempting the user to say "y". But the response was taken as "No, - please use 'y' as the e-mail address instead", which is most - certainly not what the user meant. - - * "git show --format='%ci'" did not give the timestamp correctly for - commits created without human readable name on the "committer" line. - - * "git show --quiet" ought to be a synonym for "git show -s", but - wasn't. - - * "git submodule frotz" was not diagnosed as "frotz" being an unknown - subcommand to "git submodule"; the user instead got a complaint - that "git submodule status" was run with an unknown path "frotz". - - * "git status" honored the ignore=dirty settings in .gitmodules but - "git commit" didn't. - - * "gitweb" did not give the correct committer timezone in its feed - output due to a typo. diff --git a/third_party/git/Documentation/RelNotes/1.8.1.1.txt b/third_party/git/Documentation/RelNotes/1.8.1.1.txt deleted file mode 100644 index 6cde07ba29..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.1.1.txt +++ /dev/null @@ -1,87 +0,0 @@ -Git 1.8.1.1 Release Notes -========================= - -Fixes since v1.8.1 ------------------- - - * The attribute mechanism didn't allow limiting attributes to be - applied to only a single directory itself with "path/" like the - exclude mechanism does. - - * When attempting to read the XDG-style $HOME/.config/git/config and - finding that $HOME/.config/git is a file, we gave a wrong error - message, instead of treating the case as "a custom config file does - not exist there" and moving on. - - * After failing to create a temporary file using mkstemp(), failing - pathname was not reported correctly on some platforms. - - * http transport was wrong to ask for the username when the - authentication is done by certificate identity. - - * The behaviour visible to the end users was confusing, when they - attempt to kill a process spawned in the editor that was in turn - launched by Git with SIGINT (or SIGQUIT), as Git would catch that - signal and die. We ignore these signals now. - - * A child process that was killed by a signal (e.g. SIGINT) was - reported in an inconsistent way depending on how the process was - spawned by us, with or without a shell in between. - - * After "git add -N" and then writing a tree object out of the - index, the cache-tree data structure got corrupted. - - * "git apply" misbehaved when fixing whitespace breakages by removing - excess trailing blank lines in some corner cases. - - * A tar archive created by "git archive" recorded a directory in a - way that made NetBSD's implementation of "tar" sometimes unhappy. - - * When "git clone --separate-git-dir=$over_there" is interrupted, it - failed to remove the real location of the $GIT_DIR it created. - This was most visible when interrupting a submodule update. - - * "git fetch --mirror" and fetch that uses other forms of refspec - with wildcard used to attempt to update a symbolic ref that match - the wildcard on the receiving end, which made little sense (the - real ref that is pointed at by the symbolic ref would be updated - anyway). Symbolic refs no longer are affected by such a fetch. - - * The "log --graph" codepath fell into infinite loop in some - corner cases. - - * "git merge" started calling prepare-commit-msg hook like "git - commit" does some time ago, but forgot to pay attention to the exit - status of the hook. - - * "git pack-refs" that ran in parallel to another process that - created new refs had a race that can lose new ones. - - * When a line to be wrapped has a solid run of non space characters - whose length exactly is the wrap width, "git shortlog -w" failed - to add a newline after such a line. - - * The way "git svn" asked for password using SSH_ASKPASS and - GIT_ASKPASS was not in line with the rest of the system. - - * "gitweb", when sorting by age to show repositories with new - activities first, used to sort repositories with absolutely - nothing in it early, which was not very useful. - - * "gitweb", when sorting by age to show repositories with new - activities first, used to sort repositories with absolutely - nothing in it early, which was not very useful. - - * When autoconf is used, any build on a different commit always ran - "config.status --recheck" even when unnecessary. - - * Some scripted programs written in Python did not get updated when - PYTHON_PATH changed. - - * We have been carrying a translated and long-unmaintained copy of an - old version of the tutorial; removed. - - * Portability issues in many self-test scripts have been addressed. - - -Also contains other minor fixes and documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.8.1.2.txt b/third_party/git/Documentation/RelNotes/1.8.1.2.txt deleted file mode 100644 index 5ab7b18906..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.1.2.txt +++ /dev/null @@ -1,25 +0,0 @@ -Git 1.8.1.2 Release Notes -========================= - -Fixes since v1.8.1.1 --------------------- - - * An element on GIT_CEILING_DIRECTORIES list that does not name the - real path to a directory (i.e. a symbolic link) could have caused - the GIT_DIR discovery logic to escape the ceiling. - - * Command line completion for "tcsh" emitted an unwanted space - after completing a single directory name. - - * Command line completion leaked an unnecessary error message while - looking for possible matches with paths in <tree-ish>. - - * "git archive" did not record uncompressed size in the header when - streaming a zip archive, which confused some implementations of unzip. - - * When users spelled "cc:" in lowercase in the fake "header" in the - trailer part, "git send-email" failed to pick up the addresses from - there. As e-mail headers field names are case insensitive, this - script should follow suit and treat "cc:" and "Cc:" the same way. - -Also contains various documentation fixes. diff --git a/third_party/git/Documentation/RelNotes/1.8.1.3.txt b/third_party/git/Documentation/RelNotes/1.8.1.3.txt deleted file mode 100644 index 681cb35c0a..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.1.3.txt +++ /dev/null @@ -1,47 +0,0 @@ -Git 1.8.1.3 Release Notes -========================= - -Fixes since v1.8.1.2 --------------------- - - * The attribute mechanism didn't allow limiting attributes to be - applied to only a single directory itself with "path/" like the - exclude mechanism does. The fix for this in 1.8.1.2 had - performance degradations. - - * Command line completion code was inadvertently made incompatible with - older versions of bash by using a newer array notation. - - * Scripts to test bash completion was inherently flaky as it was - affected by whatever random things the user may have on $PATH. - - * A fix was added to the build procedure to work around buggy - versions of ccache broke the auto-generation of dependencies, which - unfortunately is still relevant because some people use ancient - distros. - - * We used to stuff "user@" and then append what we read from - /etc/mailname to come up with a default e-mail ident, but a bug - lost the "user@" part. - - * "git am" did not parse datestamp correctly from Hg generated patch, - when it is run in a locale outside C (or en). - - * Attempt to "branch --edit-description" an existing branch, while - being on a detached HEAD, errored out. - - * "git cherry-pick" did not replay a root commit to an unborn branch. - - * We forgot to close the file descriptor reading from "gpg" output, - killing "git log --show-signature" on a long history. - - * "git rebase --preserve-merges" lost empty merges in recent versions - of Git. - - * Rebasing the history of superproject with change in the submodule - has been broken since v1.7.12. - - * A failure to push due to non-ff while on an unborn branch - dereferenced a NULL pointer when showing an error message. - -Also contains various documentation fixes. diff --git a/third_party/git/Documentation/RelNotes/1.8.1.4.txt b/third_party/git/Documentation/RelNotes/1.8.1.4.txt deleted file mode 100644 index 22af1d1643..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.1.4.txt +++ /dev/null @@ -1,11 +0,0 @@ -Git 1.8.1.4 Release Notes -========================= - -Fixes since v1.8.1.3 --------------------- - - * "git imap-send" talking over imaps:// did make sure it received a - valid certificate from the other end, but did not check if the - certificate matched the host it thought it was talking to. - -Also contains various documentation fixes. diff --git a/third_party/git/Documentation/RelNotes/1.8.1.5.txt b/third_party/git/Documentation/RelNotes/1.8.1.5.txt deleted file mode 100644 index efa68aef22..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.1.5.txt +++ /dev/null @@ -1,47 +0,0 @@ -Git 1.8.1.5 Release Notes -========================= - -Fixes since v1.8.1.4 --------------------- - - * Given a string with a multi-byte character that begins with '-' on - the command line where an option is expected, the option parser - used just one byte of the unknown letter when reporting an error. - - * In v1.8.1, the attribute parser was tightened too restrictive to - error out upon seeing an entry that begins with an ! (exclamation), - which may confuse users to expect a "negative match", which does - not exist. This has been demoted to a warning; such an entry is - still ignored. - - * "git apply --summary" has been taught to make sure the similarity - value shown in its output is sensible, even when the input had a - bogus value. - - * "git clean" showed what it was going to do, but sometimes ended - up finding that it was not allowed to do so, which resulted in a - confusing output (e.g. after saying that it will remove an - untracked directory, it found an embedded git repository there - which it is not allowed to remove). It now performs the actions - and then reports the outcome more faithfully. - - * "git clone" used to allow --bare and --separate-git-dir=$there - options at the same time, which was nonsensical. - - * "git cvsimport" mishandled timestamps at DST boundary. - - * We used to have an arbitrary 32 limit for combined diff input, - resulting in incorrect number of leading colons shown when showing - the "--raw --cc" output. - - * The smart HTTP clients forgot to verify the content-type that comes - back from the server side to make sure that the request is being - handled properly. - - * "git help remote-helpers" failed to find the documentation. - - * "gitweb" pages served over HTTPS, when configured to show picon or - gravatar, referred to these external resources to be fetched via - HTTP, resulting in mixed contents warning in browsers. - -Also contains various documentation fixes. diff --git a/third_party/git/Documentation/RelNotes/1.8.1.6.txt b/third_party/git/Documentation/RelNotes/1.8.1.6.txt deleted file mode 100644 index c15cf2e805..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.1.6.txt +++ /dev/null @@ -1,39 +0,0 @@ -Git 1.8.1.6 Release Notes -========================= - -Fixes since v1.8.1.5 --------------------- - - * An earlier change to the attribute system introduced at v1.8.1.2 by - mistake stopped a pattern "dir" (without trailing slash) from - matching a directory "dir" (it only wanted to allow pattern "dir/" - to also match). - - * The code to keep track of what directory names are known to Git on - platforms with case insensitive filesystems can get confused upon a - hash collision between these pathnames and looped forever. - - * When the "--prefix" option is used to "checkout-index", the code - did not pick the correct output filter based on the attribute - setting. - - * Annotated tags outside refs/tags/ hierarchy were not advertised - correctly to the ls-remote and fetch with recent version of Git. - - * The logic used by "git diff -M --stat" to shorten the names of - files before and after a rename did not work correctly when the - common prefix and suffix between the two filenames overlapped. - - * "git update-index -h" did not do the usual "-h(elp)" thing. - - * perl/Git.pm::cat_blob slurped everything in core only to write it - out to a file descriptor, which was not a very smart thing to do. - - * The SSL peer verification done by "git imap-send" did not ask for - Server Name Indication (RFC 4366), failing to connect SSL/TLS - sites that serve multiple hostnames on a single IP. - - * "git bundle verify" did not say "records a complete history" for a - bundle that does not have any prerequisites. - -Also contains various documentation fixes. diff --git a/third_party/git/Documentation/RelNotes/1.8.1.txt b/third_party/git/Documentation/RelNotes/1.8.1.txt deleted file mode 100644 index d6f9555923..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.1.txt +++ /dev/null @@ -1,241 +0,0 @@ -Git v1.8.1 Release Notes -======================== - -Backward compatibility notes ----------------------------- - -In the next major release (not *this* one), we will change the -behavior of the "git push" command. - -When "git push [$there]" does not say what to push, we have used the -traditional "matching" semantics so far (all your branches were sent -to the remote as long as there already are branches of the same name -over there). We will use the "simple" semantics that pushes the -current branch to the branch with the same name, only when the current -branch is set to integrate with that remote branch. There is a user -preference configuration variable "push.default" to change this, and -"git push" will warn about the upcoming change until you set this -variable in this release. - -"git branch --set-upstream" is deprecated and may be removed in a -relatively distant future. "git branch [-u|--set-upstream-to]" has -been introduced with a saner order of arguments to replace it. - - -Updates since v1.8.0 --------------------- - -UI, Workflows & Features - - * Command-line completion scripts for tcsh and zsh have been added. - - * "git-prompt" scriptlet (in contrib/completion) can be told to paint - pieces of the hints in the prompt string in colors. - - * Some documentation pages that used to ship only in the plain text - format are now formatted in HTML as well. - - * We used to have a workaround for a bug in ancient "less" that - causes it to exit without any output when the terminal is resized. - The bug has been fixed in "less" version 406 (June 2007), and the - workaround has been removed in this release. - - * When "git checkout" checks out a branch, it tells the user how far - behind (or ahead) the new branch is relative to the remote tracking - branch it builds upon. The message now also advises how to sync - them up by pushing or pulling. This can be disabled with the - advice.statusHints configuration variable. - - * "git config --get" used to diagnose presence of multiple - definitions of the same variable in the same configuration file as - an error, but it now applies the "last one wins" rule used by the - internal configuration logic. Strictly speaking, this may be an - API regression but it is expected that nobody will notice it in - practice. - - * A new configuration variable "diff.context" can be used to - give the default number of context lines in the patch output, to - override the hardcoded default of 3 lines. - - * "git format-patch" learned the "--notes=<ref>" option to give - notes for the commit after the three-dash lines in its output. - - * "git log -p -S<string>" now looks for the <string> after applying - the textconv filter (if defined); earlier it inspected the contents - of the blobs without filtering. - - * "git log --grep=<pcre>" learned to honor the "grep.patterntype" - configuration set to "perl". - - * "git replace -d <object>" now interprets <object> as an extended - SHA-1 (e.g. HEAD~4 is allowed), instead of only accepting full hex - object name. - - * "git rm $submodule" used to punt on removing a submodule working - tree to avoid losing the repository embedded in it. Because - recent git uses a mechanism to separate the submodule repository - from the submodule working tree, "git rm" learned to detect this - case and removes the submodule working tree when it is safe to do so. - - * "git send-email" used to prompt for the sender address, even when - the committer identity is well specified (e.g. via user.name and - user.email configuration variables). The command no longer gives - this prompt when not necessary. - - * "git send-email" did not allow non-address garbage strings to - appear after addresses on Cc: lines in the patch files (and when - told to pick them up to find more recipients), e.g. - - Cc: Stable Kernel <stable@k.org> # for v3.2 and up - - The command now strips " # for v3.2 and up" part before adding the - remainder of this line to the list of recipients. - - * "git submodule add" learned to add a new submodule at the same - path as the path where an unrelated submodule was bound to in an - existing revision via the "--name" option. - - * "git submodule sync" learned the "--recursive" option. - - * "diff.submodule" configuration variable can be used to give custom - default value to the "git diff --submodule" option. - - * "git symbolic-ref" learned the "-d $symref" option to delete the - named symbolic ref, which is more intuitive way to spell it than - "update-ref -d --no-deref $symref". - - -Foreign Interface - - * "git cvsimport" can be told to record timezones (other than GMT) - per-author via its author info file. - - * The remote helper interface to interact with subversion - repositories (one of the GSoC 2012 projects) has been merged. - - * A new remote-helper interface for Mercurial has been added to - contrib/remote-helpers. - - * The documentation for git(1) was pointing at a page at an external - site for the list of authors that no longer existed. The link has - been updated to point at an alternative site. - - -Performance, Internal Implementation, etc. - - * Compilation on Cygwin with newer header files are supported now. - - * A couple of low-level implementation updates on MinGW. - - * The logic to generate the initial advertisement from "upload-pack" - (i.e. what is invoked by "git fetch" on the other side of the - connection) to list what refs are available in the repository has - been optimized. - - * The logic to find set of attributes that match a given path has - been optimized. - - * Use preloadindex in "git diff-index" and "git update-index", which - has a nice speedup on systems with slow stat calls (and even on - Linux). - - -Also contains minor documentation updates and code clean-ups. - - -Fixes since v1.8.0 ------------------- - -Unless otherwise noted, all the fixes since v1.8.0 in the maintenance -track are contained in this release (see release notes to them for -details). - - * The configuration parser had an unnecessary hardcoded limit on - variable names that was not checked consistently. - - * The "say" function in the test scaffolding incorrectly allowed - "echo" to interpret "\a" as if it were a C-string asking for a - BEL output. - - * "git mergetool" feeds /dev/null as a common ancestor when dealing - with an add/add conflict, but p4merge backend cannot handle - it. Work it around by passing a temporary empty file. - - * "git log -F -E --grep='<ere>'" failed to use the given <ere> - pattern as extended regular expression, and instead looked for the - string literally. - - * "git grep -e pattern <tree>" asked the attribute system to read - "<tree>:.gitattributes" file in the working tree, which was - nonsense. - - * A symbolic ref refs/heads/SYM was not correctly removed with "git - branch -d SYM"; the command removed the ref pointed by SYM - instead. - - * Update "remote tracking branch" in the documentation to - "remote-tracking branch". - - * "git pull --rebase" run while the HEAD is detached tried to find - the upstream branch of the detached HEAD (which by definition - does not exist) and emitted unnecessary error messages. - - * The refs/replace hierarchy was not mentioned in the - repository-layout docs. - - * Various rfc2047 quoting issues around a non-ASCII name on the - From: line in the output from format-patch have been corrected. - - * Sometimes curl_multi_timeout() function suggested a wrong timeout - value when there is no file descriptor to wait on and the http - transport ended up sleeping for minutes in select(2) system call. - A workaround has been added for this. - - * For a fetch refspec (or the result of applying wildcard on one), - we always want the RHS to map to something inside "refs/" - hierarchy, but the logic to check it was not exactly right. - (merge 5c08c1f jc/maint-fetch-tighten-refname-check later to maint). - - * "git diff -G<pattern>" did not honor textconv filter when looking - for changes. - - * Some HTTP servers ask for auth only during the actual packing phase - (not in ls-remote phase); this is not really a recommended - configuration, but the clients used to fail to authenticate with - such servers. - (merge 2e736fd jk/maint-http-half-auth-fetch later to maint). - - * "git p4" used to try expanding malformed "$keyword$" that spans - across multiple lines. - - * Syntax highlighting in "gitweb" was not quite working. - - * RSS feed from "gitweb" had a xss hole in its title output. - - * "git config --path $key" segfaulted on "[section] key" (a boolean - "true" spelled without "=", not "[section] key = true"). - - * "git checkout -b foo" while on an unborn branch did not say - "Switched to a new branch 'foo'" like other cases. - - * Various codepaths have workaround for a common misconfiguration to - spell "UTF-8" as "utf8", but it was not used uniformly. Most - notably, mailinfo (which is used by "git am") lacked this support. - - * We failed to mention a file without any content change but whose - permission bit was modified, or (worse yet) a new file without any - content in the "git diff --stat" output. - - * When "--stat-count" hides a diffstat for binary contents, the total - number of added and removed lines at the bottom was computed - incorrectly. - - * When "--stat-count" hides a diffstat for unmerged paths, the total - number of affected files at the bottom of the "diff --stat" output - was computed incorrectly. - - * "diff --shortstat" miscounted the total number of affected files - when there were unmerged paths. - - * "update-ref -d --deref SYM" to delete a ref through a symbolic ref - that points to it did not remove it correctly. diff --git a/third_party/git/Documentation/RelNotes/1.8.2.1.txt b/third_party/git/Documentation/RelNotes/1.8.2.1.txt deleted file mode 100644 index 769a6fc06c..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.2.1.txt +++ /dev/null @@ -1,115 +0,0 @@ -Git v1.8.2.1 Release Notes -========================== - -Fixes since v1.8.2 ------------------- - - * An earlier change to the attribute system introduced at v1.8.1.2 by - mistake stopped a pattern "dir" (without trailing slash) from - matching a directory "dir" (it only wanted to allow pattern "dir/" - to also match). - - * Verification of signed tags were not done correctly when not in C - or en/US locale. - - * 'git commit -m "$msg"' used to add an extra newline even when - $msg already ended with one. - - * The "--match=<pattern>" option of "git describe", when used with - "--all" to allow refs that are not annotated tags to be used as a - base of description, did not restrict the output from the command - to those that match the given pattern. - - * An aliased command spawned from a bare repository that does not say - it is bare with "core.bare = yes" is treated as non-bare by mistake. - - * When "format-patch" quoted a non-ascii strings on the header files, - it incorrectly applied rfc2047 and chopped a single character in - the middle of it. - - * "git archive" reports a failure when asked to create an archive out - of an empty tree. It would be more intuitive to give an empty - archive back in such a case. - - * "git tag -f <tag>" always said "Updated tag '<tag>'" even when - creating a new tag (i.e. not overwriting nor updating). - - * "git cmd -- ':(top'" was not diagnosed as an invalid syntax, and - instead the parser kept reading beyond the end of the string. - - * Annotated tags outside refs/tags/ hierarchy were not advertised - correctly to the ls-remote and fetch with recent version of Git. - - * The code to keep track of what directory names are known to Git on - platforms with case insensitive filesystems can get confused upon a - hash collision between these pathnames and looped forever. - - * The logic used by "git diff -M --stat" to shorten the names of - files before and after a rename did not work correctly when the - common prefix and suffix between the two filenames overlapped. - - * "git submodule update", when recursed into sub-submodules, did not - accumulate the prefix paths. - - * "git am $maildir/" applied messages in an unexpected order; sort - filenames read from the maildir/ in a way that is more likely to - sort messages in the order the writing MUA meant to, by sorting - numeric segment in numeric order and non-numeric segment in - alphabetical order. - - * When export-subst is used, "zip" output recorded incorrect - size of the file. - - * Some platforms and users spell UTF-8 differently; retry with the - most official "UTF-8" when the system does not understand the - user-supplied encoding name that are the common alternative - spellings of UTF-8. - - * "git branch" did not bother to check nonsense command line - parameters and issue errors in many cases. - - * "git update-index -h" did not do the usual "-h(elp)" thing. - - * perl/Git.pm::cat_blob slurped everything in core only to write it - out to a file descriptor, which was not a very smart thing to do. - - * The SSL peer verification done by "git imap-send" did not ask for - Server Name Indication (RFC 4366), failing to connect SSL/TLS - sites that serve multiple hostnames on a single IP. - - * "git index-pack" had a buffer-overflow while preparing an - informational message when the translated version of it was too - long. - - * Clarify in the documentation "what" gets pushed to "where" when the - command line to "git push" does not say these explicitly. - - * In "git reflog expire", REACHABLE bit was not cleared from the - correct objects. - - * The "--color=<when>" argument to the commands in the diff family - was described poorly. - - * The arguments given to pre-rebase hook were not documented. - - * The v4 index format was not documented. - - * The "--match=<pattern>" argument "git describe" takes uses glob - pattern but it wasn't obvious from the documentation. - - * Some sources failed to compile on systems that lack NI_MAXHOST in - their system header (e.g. z/OS). - - * Add an example use of "--env-filter" in "filter-branch" - documentation. - - * "git bundle verify" did not say "records a complete history" for a - bundle that does not have any prerequisites. - - * In the v1.8.0 era, we changed symbols that do not have to be global - to file scope static, but a few functions in graph.c were used by - CGit from sideways bypassing the entry points of the API the - in-tree users use. - - * "git merge-tree" had a typo in the logic to detect d/f conflicts, - which caused it to segfault in some cases. diff --git a/third_party/git/Documentation/RelNotes/1.8.2.2.txt b/third_party/git/Documentation/RelNotes/1.8.2.2.txt deleted file mode 100644 index 708df1ae19..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.2.2.txt +++ /dev/null @@ -1,61 +0,0 @@ -Git v1.8.2.2 Release Notes -========================== - -Fixes since v1.8.2.1 --------------------- - - * Zsh completion forgot that '%' character used to signal untracked - files needs to be escaped with another '%'. - - * A commit object whose author or committer ident are malformed - crashed some code that trusted that a name, an email and an - timestamp can always be found in it. - - * The new core.commentchar configuration was not applied to a few - places. - - * "git pull --rebase" did not pass "-v/-q" options to underlying - "git rebase". - - * When receive-pack detects error in the pack header it received in - order to decide which of unpack-objects or index-pack to run, it - returned without closing the error stream, which led to a hang - sideband thread. - - * "git diff --diff-algorithm=algo" was understood by the command line - parser, but "git diff --diff-algorithm algo" was not. - - * "git log -S/-G" started paying attention to textconv filter, but - there was no way to disable this. Make it honor --no-textconv - option. - - * "git merge $(git rev-parse v1.8.2)" behaved quite differently from - "git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did - not pay much attention to the annotated tag payload. Make the code - notice the type of the tag object, in addition to the dwim_ref() - based classification the current code uses (i.e. the name appears - in refs/tags/) to decide when to special case merging of tags. - - * "git cherry-pick" and "git revert" can take more than one commit - on the command line these days, but it was not mentioned on the usage - text. - - * Perl scripts like "git-svn" closed (not redirecting to /dev/null) - the standard error stream, which is not a very smart thing to do. - Later open may return file descriptor #2 for unrelated purpose, and - error reporting code may write into them. - - * "git apply --whitespace=fix" was not prepared to see a line getting - longer after fixing whitespaces (e.g. tab-in-indent aka Python). - - * "git diff/log --cc" did not work well with options that ignore - whitespace changes. - - * Documentation on setting up a http server that requires - authentication only on the push but not fetch has been clarified. - - * A few bugfixes to "git rerere" working on corner case merge - conflicts have been applied. - - * "git bundle" did not like a bundle created using a commit without - any message as its one of the prerequisites. diff --git a/third_party/git/Documentation/RelNotes/1.8.2.3.txt b/third_party/git/Documentation/RelNotes/1.8.2.3.txt deleted file mode 100644 index 613948251a..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.2.3.txt +++ /dev/null @@ -1,19 +0,0 @@ -Git v1.8.2.3 Release Notes -========================== - -Fixes since v1.8.2.2 --------------------- - - * "rev-list --stdin" and friends kept bogus pointers into the input - buffer around as human readable object names. This was not a - huge problem but was exposed by a new change that uses these - names in error output. - - * When "git difftool" drove "kdiff3", it mistakenly passed --auto - option that was meant while resolving merge conflicts. - - * "git remote add" command did not diagnose extra command line - arguments as an error and silently ignored them. - -Also contains a handful of trivial code clean-ups, documentation -updates, updates to the test suite, etc. diff --git a/third_party/git/Documentation/RelNotes/1.8.2.txt b/third_party/git/Documentation/RelNotes/1.8.2.txt deleted file mode 100644 index fc606ae116..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.2.txt +++ /dev/null @@ -1,495 +0,0 @@ -Git v1.8.2 Release Notes -======================== - -Backward compatibility notes (this release) -------------------------------------------- - -"git push $there tag v1.2.3" used to allow replacing a tag v1.2.3 -that already exists in the repository $there, if the rewritten tag -you are pushing points at a commit that is a descendant of a commit -that the old tag v1.2.3 points at. This was found to be error prone -and starting with this release, any attempt to update an existing -ref under refs/tags/ hierarchy will fail, without "--force". - -When "git add -u" and "git add -A" that does not specify what paths -to add on the command line is run from inside a subdirectory, the -scope of the operation has always been limited to the subdirectory. -Many users found this counter-intuitive, given that "git commit -a" -and other commands operate on the entire tree regardless of where you -are. In this release, these commands give a warning message that -suggests the users to use "git add -u/-A ." when they want to limit -the scope to the current directory; doing so will squelch the message, -while training their fingers. - - -Backward compatibility notes (for Git 2.0) ------------------------------------------- - -When "git push [$there]" does not say what to push, we have used the -traditional "matching" semantics so far (all your branches were sent -to the remote as long as there already are branches of the same name -over there). In Git 2.0, the default will change to the "simple" -semantics that pushes the current branch to the branch with the same -name, only when the current branch is set to integrate with that -remote branch. There is a user preference configuration variable -"push.default" to change this. If you are an old-timer who is used -to the "matching" semantics, you can set it to "matching" to keep the -traditional behaviour. If you want to live in the future early, -you can set it to "simple" today without waiting for Git 2.0. - -When "git add -u" and "git add -A", that does not specify what paths -to add on the command line is run from inside a subdirectory, these -commands will operate on the entire tree in Git 2.0 for consistency -with "git commit -a" and other commands. Because there will be no -mechanism to make "git add -u" behave as if "git add -u .", it is -important for those who are used to "git add -u" (without pathspec) -updating the index only for paths in the current subdirectory to start -training their fingers to explicitly say "git add -u ." when they mean -it before Git 2.0 comes. - - -Updates since v1.8.1 --------------------- - -UI, Workflows & Features - - * Initial ports to QNX and z/OS UNIX System Services have started. - - * Output from the tests is coloured using "green is okay, yellow is - questionable, red is bad and blue is informative" scheme. - - * Mention of "GIT/Git/git" in the documentation have been updated to - be more uniform and consistent. The name of the system and the - concept it embodies is "Git"; the command the users type is "git". - All-caps "GIT" was merely a way to imitate "Git" typeset in small - caps in our ASCII text only documentation and to be avoided. - - * The completion script (in contrib/completion) used to let the - default completer to suggest pathnames, which gave too many - irrelevant choices (e.g. "git add" would not want to add an - unmodified path). It learnt to use a more git-aware logic to - enumerate only relevant ones. - - * In bare repositories, "git shortlog" and other commands now read - mailmap files from the tip of the history, to help running these - tools in server settings. - - * Color specifiers, e.g. "%C(blue)Hello%C(reset)", used in the - "--format=" option of "git log" and friends can be disabled when - the output is not sent to a terminal by prefixing them with - "auto,", e.g. "%C(auto,blue)Hello%C(auto,reset)". - - * Scripts can ask Git that wildcard patterns in pathspecs they give do - not have any significance, i.e. take them as literal strings. - - * The patterns in .gitignore and .gitattributes files can have **/, - as a pattern that matches 0 or more levels of subdirectory. - E.g. "foo/**/bar" matches "bar" in "foo" itself or in a - subdirectory of "foo". - - * When giving arguments without "--" disambiguation, object names - that come earlier on the command line must not be interpretable as - pathspecs and pathspecs that come later on the command line must - not be interpretable as object names. This disambiguation rule has - been tweaked so that ":/" (no other string before or after) is - always interpreted as a pathspec; "git cmd -- :/" is no longer - needed, you can just say "git cmd :/". - - * Various "hint" lines Git gives when it asks the user to edit - messages in the editor are commented out with '#' by default. The - core.commentchar configuration variable can be used to customize - this '#' to a different character. - - * "git add -u" and "git add -A" without pathspec issues warning to - make users aware that they are only operating on paths inside the - subdirectory they are in. Use ":/" (everything from the top) or - "." (everything from the $cwd) to disambiguate. - - * "git blame" (and "git diff") learned the "--no-follow" option. - - * "git branch" now rejects some nonsense combinations of command line - arguments (e.g. giving more than one branch name to rename) with - more case-specific error messages. - - * "git check-ignore" command to help debugging .gitignore files has - been added. - - * "git cherry-pick" can be used to replay a root commit to an unborn - branch. - - * "git commit" can be told to use --cleanup=whitespace by setting the - configuration variable commit.cleanup to 'whitespace'. - - * "git diff" and other Porcelain commands can be told to use a - non-standard algorithm by setting diff.algorithm configuration - variable. - - * "git fetch --mirror" and fetch that uses other forms of refspec - with wildcard used to attempt to update a symbolic ref that match - the wildcard on the receiving end, which made little sense (the - real ref that is pointed at by the symbolic ref would be updated - anyway). Symbolic refs no longer are affected by such a fetch. - - * "git format-patch" now detects more cases in which a whole branch - is being exported, and uses the description for the branch, when - asked to write a cover letter for the series. - - * "git format-patch" learned "-v $count" option, and prepends a - string "v$count-" to the names of its output files, and also - automatically sets the subject prefix to "PATCH v$count". This - allows patches from rerolled series to be stored under different - names and makes it easier to reuse cover letter messages. - - * "git log" and friends can be told with --use-mailmap option to - rewrite the names and email addresses of people using the mailmap - mechanism. - - * "git log --cc --graph" now shows the combined diff output with the - ancestry graph. - - * "git log --grep=<pattern>" honors i18n.logoutputencoding to look - for the pattern after fixing the log message to the specified - encoding. - - * "git mergetool" and "git difftool" learned to list the available - tool backends in a more consistent manner. - - * "git mergetool" is aware of TortoiseGitMerge now and uses it over - TortoiseMerge when available. - - * "git push" now requires "-f" to update a tag, even if it is a - fast-forward, as tags are meant to be fixed points. - - * Error messages from "git push" when it stops to prevent remote refs - from getting overwritten by mistake have been improved to explain - various situations separately. - - * "git push" will stop without doing anything if the new "pre-push" - hook exists and exits with a failure. - - * When "git rebase" fails to generate patches to be applied (e.g. due - to oom), it failed to detect the failure and instead behaved as if - there were nothing to do. A workaround to use a temporary file has - been applied, but we probably would want to revisit this later, as - it hurts the common case of not failing at all. - - * Input and preconditions to "git reset" has been loosened where - appropriate. "git reset $fromtree Makefile" requires $fromtree to - be any tree (it used to require it to be a commit), for example. - "git reset" (without options or parameters) used to error out when - you do not have any commits in your history, but it now gives you - an empty index (to match non-existent commit you are not even on). - - * "git status" says what branch is being bisected or rebased when - able, not just "bisecting" or "rebasing". - - * "git submodule" started learning a new mode to integrate with the - tip of the remote branch (as opposed to integrating with the commit - recorded in the superproject's gitlink). - - * "git upload-pack" which implements the service "ls-remote" and - "fetch" talk to can be told to hide ref hierarchies the server - side internally uses (and that clients have no business learning - about) with transfer.hiderefs configuration. - - -Foreign Interface - - * "git fast-export" has been updated for its use in the context of - the remote helper interface. - - * A new remote helper to interact with bzr has been added to contrib/. - - * "git p4" got various bugfixes around its branch handling. It is - also made usable with Python 2.4/2.5. In addition, its various - portability issues for Cygwin have been addressed. - - * The remote helper to interact with Hg in contrib/ has seen a few - fixes. - - -Performance, Internal Implementation, etc. - - * "git fsck" has been taught to be pickier about entries in tree - objects that should not be there, e.g. ".", ".git", and "..". - - * Matching paths with common forms of pathspecs that contain wildcard - characters has been optimized further. - - * We stopped paying attention to $GIT_CONFIG environment that points - at a single configuration file from any command other than "git config" - quite a while ago, but "git clone" internally set, exported, and - then unexported the variable during its operation unnecessarily. - - * "git reset" internals has been reworked and should be faster in - general. We tried to be careful not to break any behaviour but - there could be corner cases, especially when running the command - from a conflicted state, that we may have missed. - - * The implementation of "imap-send" has been updated to reuse xml - quoting code from http-push codepath, and lost a lot of unused - code. - - * There is a simple-minded checker for the test scripts in t/ - directory to catch most common mistakes (it is not enabled by - default). - - * You can build with USE_WILDMATCH=YesPlease to use a replacement - implementation of pattern matching logic used for pathname-like - things, e.g. refnames and paths in the repository. This new - implementation is not expected change the existing behaviour of Git - in this release, except for "git for-each-ref" where you can now - say "refs/**/master" and match with both refs/heads/master and - refs/remotes/origin/master. We plan to use this new implementation - in wider places (e.g. "git ls-files '**/Makefile' may find Makefile - at the top-level, and "git log '**/t*.sh'" may find commits that - touch a shell script whose name begins with "t" at any level) in - future versions of Git, but we are not there yet. By building with - USE_WILDMATCH, using the resulting Git daily and reporting when you - find breakages, you can help us get closer to that goal. - - * Some reimplementations of Git do not write all the stat info back - to the index due to their implementation limitations (e.g. jgit). - A configuration option can tell Git to ignore changes to most of - the stat fields and only pay attention to mtime and size, which - these implementations can reliably update. This can be used to - avoid excessive revalidation of contents. - - * Some platforms ship with old version of expat where xmlparse.h - needs to be included instead of expat.h; the build procedure has - been taught about this. - - * "make clean" on platforms that cannot compute header dependencies - on the fly did not work with implementations of "rm" that do not - like an empty argument list. - -Also contains minor documentation updates and code clean-ups. - - -Fixes since v1.8.1 ------------------- - -Unless otherwise noted, all the fixes since v1.8.1 in the maintenance -track are contained in this release (see release notes to them for -details). - - * An element on GIT_CEILING_DIRECTORIES list that does not name the - real path to a directory (i.e. a symbolic link) could have caused - the GIT_DIR discovery logic to escape the ceiling. - - * When attempting to read the XDG-style $HOME/.config/git/config and - finding that $HOME/.config/git is a file, we gave a wrong error - message, instead of treating the case as "a custom config file does - not exist there" and moving on. - - * The behaviour visible to the end users was confusing, when they - attempt to kill a process spawned in the editor that was in turn - launched by Git with SIGINT (or SIGQUIT), as Git would catch that - signal and die. We ignore these signals now. - (merge 0398fc34 pf/editor-ignore-sigint later to maint). - - * A child process that was killed by a signal (e.g. SIGINT) was - reported in an inconsistent way depending on how the process was - spawned by us, with or without a shell in between. - - * After failing to create a temporary file using mkstemp(), failing - pathname was not reported correctly on some platforms. - - * We used to stuff "user@" and then append what we read from - /etc/mailname to come up with a default e-mail ident, but a bug - lost the "user@" part. - - * The attribute mechanism didn't allow limiting attributes to be - applied to only a single directory itself with "path/" like the - exclude mechanism does. The initial implementation of this that - was merged to 'maint' and 1.8.1.2 was with a severe performance - degradations and needs to merge a fix-up topic. - - * The smart HTTP clients forgot to verify the content-type that comes - back from the server side to make sure that the request is being - handled properly. - - * "git am" did not parse datestamp correctly from Hg generated patch, - when it is run in a locale outside C (or en). - - * "git apply" misbehaved when fixing whitespace breakages by removing - excess trailing blank lines. - - * "git apply --summary" has been taught to make sure the similarity - value shown in its output is sensible, even when the input had a - bogus value. - - * A tar archive created by "git archive" recorded a directory in a - way that made NetBSD's implementation of "tar" sometimes unhappy. - - * "git archive" did not record uncompressed size in the header when - streaming a zip archive, which confused some implementations of unzip. - - * "git archive" did not parse configuration values in tar.* namespace - correctly. - (merge b3873c3 jk/config-parsing-cleanup later to maint). - - * Attempt to "branch --edit-description" an existing branch, while - being on a detached HEAD, errored out. - - * "git clean" showed what it was going to do, but sometimes end up - finding that it was not allowed to do so, which resulted in a - confusing output (e.g. after saying that it will remove an - untracked directory, it found an embedded git repository there - which it is not allowed to remove). It now performs the actions - and then reports the outcome more faithfully. - - * When "git clone --separate-git-dir=$over_there" is interrupted, it - failed to remove the real location of the $GIT_DIR it created. - This was most visible when interrupting a submodule update. - - * "git cvsimport" mishandled timestamps at DST boundary. - - * We used to have an arbitrary 32 limit for combined diff input, - resulting in incorrect number of leading colons shown when showing - the "--raw --cc" output. - - * "git fetch --depth" was broken in at least three ways. The - resulting history was deeper than specified by one commit, it was - unclear how to wipe the shallowness of the repository with the - command, and documentation was misleading. - (merge cfb70e1 nd/fetch-depth-is-broken later to maint). - - * "git log --all -p" that walked refs/notes/textconv/ ref can later - try to use the textconv data incorrectly after it gets freed. - - * We forgot to close the file descriptor reading from "gpg" output, - killing "git log --show-signature" on a long history. - - * The way "git svn" asked for password using SSH_ASKPASS and - GIT_ASKPASS was not in line with the rest of the system. - - * The --graph code fell into infinite loop when asked to do what the - code did not expect. - - * http transport was wrong to ask for the username when the - authentication is done by certificate identity. - - * "git pack-refs" that ran in parallel to another process that - created new refs had a nasty race. - - * Rebasing the history of superproject with change in the submodule - has been broken since v1.7.12. - - * After "git add -N" and then writing a tree object out of the - index, the cache-tree data structure got corrupted. - - * "git clone" used to allow --bare and --separate-git-dir=$there - options at the same time, which was nonsensical. - - * "git rebase --preserve-merges" lost empty merges in recent versions - of Git. - - * "git merge --no-edit" computed who were involved in the work done - on the side branch, even though that information is to be discarded - without getting seen in the editor. - - * "git merge" started calling prepare-commit-msg hook like "git - commit" does some time ago, but forgot to pay attention to the exit - status of the hook. - - * A failure to push due to non-ff while on an unborn branch - dereferenced a NULL pointer when showing an error message. - - * When users spell "cc:" in lowercase in the fake "header" in the - trailer part, "git send-email" failed to pick up the addresses from - there. As e-mail headers field names are case insensitive, this - script should follow suit and treat "cc:" and "Cc:" the same way. - - * Output from "git status --ignored" showed an unexpected interaction - with "--untracked". - - * "gitweb", when sorting by age to show repositories with new - activities first, used to sort repositories with absolutely - nothing in it early, which was not very useful. - - * "gitweb"'s code to sanitize control characters before passing it to - "highlight" filter lost known-to-be-safe control characters by - mistake. - - * "gitweb" pages served over HTTPS, when configured to show picon or - gravatar, referred to these external resources to be fetched via - HTTP, resulting in mixed contents warning in browsers. - - * When a line to be wrapped has a solid run of non space characters - whose length exactly is the wrap width, "git shortlog -w" failed - to add a newline after such a line. - - * Command line completion leaked an unnecessary error message while - looking for possible matches with paths in <tree-ish>. - - * Command line completion for "tcsh" emitted an unwanted space - after completing a single directory name. - - * Command line completion code was inadvertently made incompatible with - older versions of bash by using a newer array notation. - - * "git push" was taught to refuse updating the branch that is - currently checked out long time ago, but the user manual was left - stale. - (merge 50995ed wk/man-deny-current-branch-is-default-these-days later to maint). - - * Some shells do not behave correctly when IFS is unset; work it - around by explicitly setting it to the default value. - - * Some scripted programs written in Python did not get updated when - PYTHON_PATH changed. - (cherry-pick 96a4647fca54031974cd6ad1 later to maint). - - * When autoconf is used, any build on a different commit always ran - "config.status --recheck" even when unnecessary. - - * A fix was added to the build procedure to work around buggy - versions of ccache broke the auto-generation of dependencies, which - unfortunately is still relevant because some people use ancient - distros. - - * The autoconf subsystem passed --mandir down to generated - config.mak.autogen but forgot to do the same for --htmldir. - (merge 55d9bf0 ct/autoconf-htmldir later to maint). - - * A change made on v1.8.1.x maintenance track had a nasty regression - to break the build when autoconf is used. - (merge 7f1b697 jn/less-reconfigure later to maint). - - * We have been carrying a translated and long-unmaintained copy of an - old version of the tutorial; removed. - - * t0050 had tests expecting failures from a bug that was fixed some - time ago. - - * t4014, t9502 and t0200 tests had various portability issues that - broke on OpenBSD. - - * t9020 and t3600 tests had various portability issues. - - * t9200 runs "cvs init" on a directory that already exists, but a - platform can configure this fail for the current user (e.g. you - need to be in the cvsadmin group on NetBSD 6.0). - - * t9020 and t9810 had a few non-portable shell script construct. - - * Scripts to test bash completion was inherently flaky as it was - affected by whatever random things the user may have on $PATH. - - * An element on GIT_CEILING_DIRECTORIES could be a "logical" pathname - that uses a symbolic link to point at somewhere else (e.g. /home/me - that points at /net/host/export/home/me, and the latter directory - is automounted). Earlier when Git saw such a pathname e.g. /home/me - on this environment variable, the "ceiling" mechanism did not take - effect. With this release (the fix has also been merged to the - v1.8.1.x maintenance series), elements on GIT_CEILING_DIRECTORIES - are by default checked for such aliasing coming from symbolic - links. As this needs to actually resolve symbolic links for each - element on the GIT_CEILING_DIRECTORIES, you can disable this - mechanism for some elements by listing them after an empty element - on the GIT_CEILING_DIRECTORIES. e.g. Setting /home/me::/home/him to - GIT_CEILING_DIRECTORIES makes Git resolve symbolic links in - /home/me when checking if the current directory is under /home/me, - but does not do so for /home/him. - (merge 7ec30aa mh/maint-ceil-absolute later to maint). diff --git a/third_party/git/Documentation/RelNotes/1.8.3.1.txt b/third_party/git/Documentation/RelNotes/1.8.3.1.txt deleted file mode 100644 index 986637b755..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.3.1.txt +++ /dev/null @@ -1,14 +0,0 @@ -Git v1.8.3.1 Release Notes -========================== - -Fixes since v1.8.3 ------------------- - - * When $HOME is misconfigured to point at an unreadable directory, we - used to complain and die. The check has been loosened. - - * Handling of negative exclude pattern for directories "!dir" was - broken in the update to v1.8.3. - -Also contains a handful of trivial code clean-ups, documentation -updates, updates to the test suite, etc. diff --git a/third_party/git/Documentation/RelNotes/1.8.3.2.txt b/third_party/git/Documentation/RelNotes/1.8.3.2.txt deleted file mode 100644 index 26ae142c3d..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.3.2.txt +++ /dev/null @@ -1,59 +0,0 @@ -Git v1.8.3.2 Release Notes -========================== - -Fixes since v1.8.3.1 --------------------- - - * Cloning with "git clone --depth N" while fetch.fsckobjects (or - transfer.fsckobjects) is set to true did not tell the cut-off - points of the shallow history to the process that validates the - objects and the history received, causing the validation to fail. - - * "git checkout foo" DWIMs the intended "upstream" and turns it into - "git checkout -t -b foo remotes/origin/foo". This codepath has been - updated to correctly take existing remote definitions into account. - - * "git fetch" into a shallow repository from a repository that does - not know about the shallow boundary commits (e.g. a different fork - from the repository the current shallow repository was cloned from) - did not work correctly. - - * "git subtree" (in contrib/) had one codepath with loose error - checks to lose data at the remote side. - - * "git log --ancestry-path A...B" did not work as expected, as it did - not pay attention to the fact that the merge base between A and B - was the bottom of the range being specified. - - * "git diff -c -p" was not showing a deleted line from a hunk when - another hunk immediately begins where the earlier one ends. - - * "git merge @{-1}~22" was rewritten to "git merge frotz@{1}~22" - incorrectly when your previous branch was "frotz" (it should be - rewritten to "git merge frotz~22" instead). - - * "git commit --allow-empty-message -m ''" should not start an - editor. - - * "git push --[no-]verify" was not documented. - - * An entry for "file://" scheme in the enumeration of URL types Git - can take in the HTML documentation was made into a clickable link - by mistake. - - * zsh prompt script that borrowed from bash prompt script did not - work due to slight differences in array variable notation between - these two shells. - - * The bash prompt code (in contrib/) displayed the name of the branch - being rebased when "rebase -i/-m/-p" modes are in use, but not the - plain vanilla "rebase". - - * "git push $there HEAD:branch" did not resolve HEAD early enough, so - it was easy to flip it around while push is still going on and push - out a branch that the user did not originally intended when the - command was started. - - * "difftool --dir-diff" did not copy back changes made by the - end-user in the diff tool backend to the working tree in some - cases. diff --git a/third_party/git/Documentation/RelNotes/1.8.3.3.txt b/third_party/git/Documentation/RelNotes/1.8.3.3.txt deleted file mode 100644 index 9ba4f4da0f..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.3.3.txt +++ /dev/null @@ -1,47 +0,0 @@ -Git v1.8.3.3 Release Notes -========================== - -Fixes since v1.8.3.2 --------------------- - - * "git apply" parsed patches that add new files, generated by programs - other than Git, incorrectly. This is an old breakage in v1.7.11. - - * Older cURL wanted piece of memory we call it with to be stable, but - we updated the auth material after handing it to a call. - - * "git pull" into nothing trashed "local changes" that were in the - index. - - * Many "git submodule" operations did not work on a submodule at a - path whose name is not in ASCII. - - * "cherry-pick" had a small leak in its error codepath. - - * Logic used by git-send-email to suppress cc mishandled names like - "A U. Thor" <author@example.xz>, where the human readable part - needs to be quoted (the user input may not have the double quotes - around the name, and comparison was done between quoted and - unquoted strings). It also mishandled names that need RFC2047 - quoting. - - * "gitweb" forgot to clear a global variable $search_regexp upon each - request, mistakenly carrying over the previous search to a new one - when used as a persistent CGI. - - * The wildmatch engine did not honor WM_CASEFOLD option correctly. - - * "git log -c --follow $path" segfaulted upon hitting the commit that - renamed the $path being followed. - - * When a reflog notation is used for implicit "current branch", - e.g. "git log @{u}", we did not say which branch and worse said - "branch ''" in the error messages. - - * Mac OS X does not like to write(2) more than INT_MAX number of - bytes; work it around by chopping write(2) into smaller pieces. - - * Newer MacOS X encourages the programs to compile and link with - their CommonCrypto, not with OpenSSL. - -Also contains various minor documentation updates. diff --git a/third_party/git/Documentation/RelNotes/1.8.3.4.txt b/third_party/git/Documentation/RelNotes/1.8.3.4.txt deleted file mode 100644 index 56f106e262..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.3.4.txt +++ /dev/null @@ -1,20 +0,0 @@ -Git v1.8.3.4 Release Notes -========================== - -This update is mostly to propagate documentation fixes and test -updates from the master front back to the maintenance track. - -Fixes since v1.8.3.3 --------------------- - - * The bisect log listed incorrect commits when bisection ends with - only skipped ones. - - * The test coverage framework was left broken for some time. - - * The test suite for HTTP transport did not run with Apache 2.4. - - * "git diff" used to fail when core.safecrlf is set and the working - tree contents had mixed CRLF/LF line endings. Committing such a - content must be prohibited, but "git diff" should help the user to - locate and fix such problems without failing. diff --git a/third_party/git/Documentation/RelNotes/1.8.3.txt b/third_party/git/Documentation/RelNotes/1.8.3.txt deleted file mode 100644 index ead568e7f1..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.3.txt +++ /dev/null @@ -1,436 +0,0 @@ -Git v1.8.3 Release Notes -======================== - -Backward compatibility notes (for Git 2.0) ------------------------------------------- - -When "git push [$there]" does not say what to push, we have used the -traditional "matching" semantics so far (all your branches were sent -to the remote as long as there already are branches of the same name -over there). In Git 2.0, the default will change to the "simple" -semantics that pushes only the current branch to the branch with the same -name, and only when the current branch is set to integrate with that -remote branch. Use the user preference configuration variable -"push.default" to change this. If you are an old-timer who is used -to the "matching" semantics, you can set the variable to "matching" -to keep the traditional behaviour. If you want to live in the future -early, you can set it to "simple" today without waiting for Git 2.0. - -When "git add -u" (and "git add -A") is run inside a subdirectory and -does not specify which paths to add on the command line, it -will operate on the entire tree in Git 2.0 for consistency -with "git commit -a" and other commands. There will be no -mechanism to make plain "git add -u" behave like "git add -u .". -Current users of "git add -u" (without a pathspec) should start -training their fingers to explicitly say "git add -u ." -before Git 2.0 comes. A warning is issued when these commands are -run without a pathspec and when you have local changes outside the -current directory, because the behaviour in Git 2.0 will be different -from today's version in such a situation. - -In Git 2.0, "git add <path>" will behave as "git add -A <path>", so -that "git add dir/" will notice paths you removed from the directory -and record the removal. Versions before Git 2.0, including this -release, will keep ignoring removals, but the users who rely on this -behaviour are encouraged to start using "git add --ignore-removal <path>" -now before 2.0 is released. - - -Updates since v1.8.2 --------------------- - -Foreign interface - - * remote-hg and remote-bzr helpers (in contrib/ since v1.8.2) have - been updated; especially, the latter has been done in an - accelerated schedule (read: we may not have merged to this release - if we were following the usual "cook sufficiently in next before - unleashing it to the world" workflow) in order to help Emacs folks, - whose primary SCM seems to be stagnating. - - -UI, Workflows & Features - - * A handful of updates applied to gitk, including an addition of - "revert" action, showing dates in tags in a nicer way, making - colors configurable, and support for -G'pickaxe' search. - - * The prompt string generator (in contrib/completion/) learned to - show how many changes there are in total and how many have been - replayed during a "git rebase" session. - - * "git branch --vv" learned to paint the name of the branch it - integrates with in a different color (color.branch.upstream, - which defaults to blue). - - * In a sparsely populated working tree, "git checkout <pathspec>" no - longer unmarks paths that match the given pathspec that were - originally ignored with "--sparse" (use --ignore-skip-worktree-bits - option to resurrect these paths out of the index if you really want - to). - - * "git log --format" specifier learned %C(auto) token that tells Git - to use color when interpolating %d (decoration), %h (short commit - object name), etc. for terminal output. - - * "git bisect" leaves the final outcome as a comment in its bisect - log file. - - * "git clone --reference" can now refer to a gitfile "textual symlink" - that points at the real location of the repository. - - * "git count-objects" learned "--human-readable" aka "-H" option to - show various large numbers in Ki/Mi/GiB scaled as necessary. - - * "git cherry-pick $blob" and "git cherry-pick $tree" are nonsense, - and a more readable error message e.g. "can't cherry-pick a tree" - is given (we used to say "expected exactly one commit"). - - * The "--annotate" option to "git send-email" can be turned on (or - off) by default with sendemail.annotate configuration variable (you - can use --no-annotate from the command line to override it). - - * The "--cover-letter" option to "git format-patch" can be turned on - (or off) by default with format.coverLetter configuration - variable. By setting it to 'auto', you can turn it on only for a - series with two or more patches. - - * The bash completion support (in contrib/) learned that cherry-pick - takes a few more options than it already knew about. - - * "git help" learned "-g" option to show the list of guides just like - list of commands are given with "-a". - - * A triangular "pull from one place, push to another place" workflow - is supported better by new remote.pushdefault (overrides the - "origin" thing) and branch.*.pushremote (overrides the - branch.*.remote) configuration variables. - - * "git status" learned to report that you are in the middle of a - revert session, just like it does for a cherry-pick and a bisect - session. - - * The handling by "git branch --set-upstream-to" against various forms - of erroneous inputs was suboptimal and has been improved. - - * When the interactive access to git-shell is not enabled, it issues - a message meant to help the system administrator to enable it. An - explicit way has been added to issue custom messages to refuse an - access over the network to help the end users who connect to the - service expecting an interactive shell. - - * In addition to the case where the user edits the log message with - the "e)dit" option of "am -i", replace the "Applying: this patch" - message with the final log message contents after applymsg hook - munges it. - - * "git status" suggests users to look into using --untracked=no option - when it takes too long. - - * "git status" shows a bit more information during a rebase/bisect - session. - - * "git fetch" learned to fetch a commit at the tip of an unadvertised - ref by specifying a raw object name from the command line when the - server side supports this feature. - - * Output from "git log --graph" works better with submodule log - output now. - - * "git count-objects -v" learned to report leftover temporary - packfiles and other garbage in the object store. - - * A new read-only credential helper (in contrib/) to interact with - the .netrc/.authinfo files has been added. - - * "git send-email" can be used with the credential helper system. - - * There was no Porcelain way to say "I no longer am interested in - this submodule", once you express your interest in a submodule with - "submodule init". "submodule deinit" is the way to do so. - - * "git pull --rebase" learned to pass "-v/-q" options to underlying - "git rebase". - - * The new "--follow-tags" option tells "git push" to push relevant - annotated tags when pushing branches out. - - * "git merge" and "git pull" can optionally be told to inspect and - reject when merging a commit that does not carry a trusted GPG - signature. - - * "git mergetool" now feeds files to the "p4merge" backend in the - order that matches the p4 convention, where "theirs" is usually - shown on the left side, which is the opposite from what other backends - expect. - - * "show/log" now honors gpg.program configuration just like other - parts of the code that use GnuPG. - - * "git log" that shows the difference between the parent and the - child has been optimized somewhat. - - * "git difftool" allows the user to write into the temporary files - being shown; if the user makes changes to the working tree at the - same time, it now refrains from overwriting the copy in the working - tree and leaves the temporary file so that changes can be merged - manually. - - * There was no good way to ask "I have a random string that came from - outside world. I want to turn it into a 40-hex object name while - making sure such an object exists". A new peeling suffix ^{object} - can be used for that purpose, together with "rev-parse --verify". - - -Performance, Internal Implementation, etc. - - * Updates for building under msvc. - - * A handful of issues in the code that traverses the working tree to find - untracked and/or ignored files have been fixed, and the general - codepath involved in "status -u" and "clean" have been cleaned up - and optimized. - - * The stack footprint of some codepaths that access an object from a - pack has been shrunk. - - * The logic to coalesce the same lines removed from the parents in - the output from "diff -c/--cc" has been updated, but with O(n^2) - complexity, so this might turn out to be undesirable. - - * The code to enforce permission bits on files in $GIT_DIR/ for - shared repositories has been simplified. - - * A few codepaths know how much data they need to put in the - hashtables they use when they start, but still began with small tables - and repeatedly grew and rehashed them. - - * The API to walk reflog entries from the latest to older, which was - necessary for operations such as "git checkout -", was cumbersome - to use correctly and also inefficient. - - * Codepaths that inspect log-message-to-be and decide when to add a - new Signed-off-by line in various commands have been consolidated. - - * The pkt-line API, implementation and its callers have been cleaned - up to make them more robust. - - * The Cygwin port has a faster-but-lying lstat(2) emulation whose - incorrectness does not matter in practice except for a few - codepaths, and setting permission bits on directories is a codepath - that needs to use a more correct one. - - * "git checkout" had repeated pathspec matches on the same paths, - which have been consolidated. Also a bug in "git checkout dir/" - that is started from an unmerged index has been fixed. - - * A few bugfixes to "git rerere" working on corner case merge - conflicts have been applied. - - -Also contains various documentation updates and code clean-ups. - - -Fixes since v1.8.2 ------------------- - -Unless otherwise noted, all the fixes since v1.8.2 in the maintenance -track are contained in this release (see release notes to them for -details). - - * Recent versions of File::Temp (used by "git svn") started blowing - up when its tempfile sub is called as a class method; updated the - callsite to call it as a plain vanilla function to fix it. - (merge eafc2dd hb/git-pm-tempfile later to maint). - - * Various subcommands of "git remote" simply ignored extraneous - command line arguments instead of diagnosing them as errors. - - * When receive-pack detects an error in the pack header it received in - order to decide which of unpack-objects or index-pack to run, it - returned without closing the error stream, which led to a hung - sideband thread. - - * Zsh completion forgot that the '%' character used to signal untracked - files needs to be escaped with another '%'. - - * A commit object whose author or committer ident are malformed - crashed some code that trusted that a name, an email and a - timestamp can always be found in it. - - * When "upload-pack" fails while generating a pack in response to - "git fetch" (or "git clone"), the receiving side had - a programming error that triggered the die handler - recursively. - - * "rev-list --stdin" and friends kept bogus pointers into the input - buffer around as human readable object names. This was not a huge - problem but was exposed by a new change that uses these names in - error output. - - * Smart-capable HTTP servers were not restricted via the - GIT_NAMESPACE mechanism when talking with commit-walking clients, - like they are when talking with smart HTTP clients. - (merge 6130f86 jk/http-dumb-namespaces later to maint). - - * "git merge-tree" did not omit a merge result that is identical to - the "our" side in certain cases. - (merge aacecc3 jk/merge-tree-added-identically later to maint). - - * Perl scripts like "git-svn" closed (instead of redirecting to /dev/null) - the standard error stream, which is not a very smart thing to do. - A later open may return file descriptor #2 for an unrelated purpose, and - error reporting code may write into it. - - * "git show-branch" was not prepared to show a very long run of - ancestor operators e.g. foobar^2~2^2^2^2...^2~4 correctly. - - * "git diff --diff-algorithm algo" is also understood as "git diff - --diff-algorithm=algo". - - * The new core.commentchar configuration was not applied in a few - places. - - * "git bundle" erroneously bailed out when parsing a valid bundle - containing a prerequisite commit without a commit message. - - * "git log -S/-G" started paying attention to textconv filter, but - there was no way to disable this. Make it honor the --no-textconv - option. - - * When used with the "-d temporary-directory" option, "git filter-branch" - failed to come back to the original working tree to perform the - final clean-up procedure. - - * "git merge $(git rev-parse v1.8.2)" behaved quite differently from - "git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did - not pay much attention to the annotated tag payload. Make the code - notice the type of the tag object, in addition to the dwim_ref() - based classification the current code uses (i.e. the name appears - in refs/tags/) to decide when to special-case tag merging. - - * Fix a 1.8.1.x regression that stopped matching "dir" (without a - trailing slash) to a directory "dir". - - * "git apply --whitespace=fix" was not prepared to see a line getting - longer after fixing whitespaces (e.g. tab-in-indent aka Python). - - * The prompt string generator (in contrib/completion/) did not notice - when we are in a middle of a "git revert" session. - - * "submodule summary --summary-limit" option did not support the - "--option=value" form. - - * "index-pack --fix-thin" used an uninitialized value to compute - the delta depths of objects it appends to the resulting pack. - - * "index-pack --verify-stat" used a few counters outside the protection - of a mutex, possibly showing incorrect numbers. - - * The code to keep track of what directory names are known to Git on - platforms with case insensitive filesystems could get confused upon a - hash collision between these pathnames and would loop forever. - - * Annotated tags outside the refs/tags/ hierarchy were not advertised - correctly to ls-remote and fetch with recent versions of Git. - - * Recent optimizations broke shallow clones. - - * "git cmd -- ':(top'" was not diagnosed as an invalid syntax, and - instead the parser kept reading beyond the end of the string. - - * "git tag -f <tag>" always said "Updated tag '<tag>'" even when - creating a new tag (i.e. neither overwriting nor updating). - - * "git p4" did not behave well when the path to the root of the P4 - client was not its real path. - (merge bbd8486 pw/p4-symlinked-root later to maint). - - * "git archive" reported a failure when asked to create an archive out - of an empty tree. It is more intuitive to give an empty - archive back in such a case. - - * When "format-patch" quoted a non-ascii string in header files, - it incorrectly applied rfc2047 and chopped a single character in - the middle of the string. - - * An aliased command spawned from a bare repository that does not say - it is bare with "core.bare = yes" was treated as non-bare by mistake. - - * In "git reflog expire", the REACHABLE bit was not cleared from the - correct objects. - - * The logic used by "git diff -M --stat" to shorten the names of - files before and after a rename did not work correctly when the - common prefix and suffix between the two filenames overlapped. - - * The "--match=<pattern>" option of "git describe", when used with - "--all" to allow refs that are not annotated tags to be a - base of description, did not restrict the output from the command - to those refs that match the given pattern. - - * Clarify in the documentation "what" gets pushed to "where" when the - command line to "git push" does not say these explicitly. - - * The "--color=<when>" argument to the commands in the diff family - was described poorly. - - * The arguments given to the pre-rebase hook were not documented. - - * The v4 index format was not documented. - - * The "--match=<pattern>" argument "git describe" takes uses glob - pattern but it wasn't obvious from the documentation. - - * Some sources failed to compile on systems that lack NI_MAXHOST in - their system header (e.g. z/OS). - - * Add an example use of "--env-filter" in "filter-branch" - documentation. - - * "git bundle verify" did not say "records a complete history" for a - bundle that does not have any prerequisites. - - * In the v1.8.0 era, we changed symbols that do not have to be global - to file scope static, but a few functions in graph.c were used by - CGit sideways, bypassing the entry points of the API the - in-tree users use. - - * "git update-index -h" did not do the usual "-h(elp)" thing. - - * "git index-pack" had a buffer-overflow while preparing an - informational message when the translated version of it was too - long. - - * 'git commit -m "$msg"' used to add an extra newline even when - $msg already ended with one. - - * The SSL peer verification done by "git imap-send" did not ask for - Server Name Indication (RFC 4366), failing to connect to SSL/TLS - sites that serve multiple hostnames on a single IP. - - * perl/Git.pm::cat_blob slurped everything in core only to write it - out to a file descriptor, which was not a very smart thing to do. - - * "git branch" did not bother to check nonsense command line - parameters. It now issues errors in many cases. - - * Verification of signed tags was not done correctly when not in C - or en/US locale. - - * Some platforms and users spell UTF-8 differently; retry with the - most official "UTF-8" when the system does not understand the - user-supplied encoding name that is a common alternative - spelling of UTF-8. - - * When export-subst is used, "zip" output recorded an incorrect - size of the file. - - * "git am $maildir/" applied messages in an unexpected order; sort - filenames read from the maildir/ in a way that is more likely to - sort the messages in the order the writing MUA meant to, by sorting - numeric segments in numeric order and non-numeric segments in - alphabetical order. - - * "git submodule update", when recursed into sub-submodules, did not - accumulate the prefix paths. diff --git a/third_party/git/Documentation/RelNotes/1.8.4.1.txt b/third_party/git/Documentation/RelNotes/1.8.4.1.txt deleted file mode 100644 index 96090ef599..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.4.1.txt +++ /dev/null @@ -1,71 +0,0 @@ -Git v1.8.4.1 Release Notes -========================== - -Fixes since v1.8.4 ------------------- - - * Some old versions of bash do not grok some constructs like - 'printf -v varname' which the prompt and completion code started - to use recently. The completion and prompt scripts have been - adjusted to work better with these old versions of bash. - - * In FreeBSD's and NetBSD's "sh", a return in a dot script in a - function returns from the function, not only in the dot script, - breaking "git rebase" on these platforms (regression introduced - in 1.8.4-rc1). - - * "git rebase -i" and other scripted commands were feeding a - random, data dependant error message to 'echo' and expecting it - to come out literally. - - * Setting the "submodule.<name>.path" variable to the empty - "true" caused the configuration parser to segfault. - - * Output from "git log --full-diff -- <pathspec>" looked strange - because comparison was done with the previous ancestor that - touched the specified <pathspec>, causing the patches for paths - outside the pathspec to show more than the single commit has - changed. - - * The auto-tag-following code in "git fetch" tries to reuse the - same transport twice when the serving end does not cooperate and - does not give tags that point to commits that are asked for as - part of the primary transfer. Unfortunately, Git-aware transport - helper interface is not designed to be used more than once, hence - this did not work over smart-http transfer. Fixed. - - * Send a large request to read(2)/write(2) as a smaller but still - reasonably large chunks, which would improve the latency when the - operation needs to be killed and incidentally works around broken - 64-bit systems that cannot take a 2GB write or read in one go. - - * A ".mailmap" file that ends with an incomplete line, when read - from a blob, was not handled properly. - - * The recent "short-cut clone connectivity check" topic broke a - shallow repository when a fetch operation tries to auto-follow - tags. - - * When send-email comes up with an error message to die with upon - failure to start an SSL session, it tried to read the error - string from a wrong place. - - * A call to xread() was used without a loop to cope with short - read in the codepath to stream large blobs to a pack. - - * On platforms with fgetc() and friends defined as macros, the - configuration parser did not compile. - - * New versions of MediaWiki introduced a new API for returning - more than 500 results in response to a query, which would cause - the MediaWiki remote helper to go into an infinite loop. - - * Subversion's serf access method (the only one available in - Subversion 1.8) for http and https URLs in skelta mode tells its - caller to open multiple files at a time, which made "git svn - fetch" complain that "Temp file with moniker 'svn_delta' already - in use" instead of fetching. - - -Also contains a handful of trivial code clean-ups, documentation -updates, updates to the test suite, etc. diff --git a/third_party/git/Documentation/RelNotes/1.8.4.2.txt b/third_party/git/Documentation/RelNotes/1.8.4.2.txt deleted file mode 100644 index bf6fb1a023..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.4.2.txt +++ /dev/null @@ -1,77 +0,0 @@ -Git v1.8.4.2 Release Notes -========================== - -Fixes since v1.8.4.1 --------------------- - - * "git clone" gave some progress messages to the standard output, not - to the standard error, and did not allow suppressing them with the - "--no-progress" option. - - * "format-patch --from=<whom>" forgot to omit unnecessary in-body - from line, i.e. when <whom> is the same as the real author. - - * "git shortlog" used to choke and die when there is a malformed - commit (e.g. missing authors); it now simply ignore such a commit - and keeps going. - - * "git merge-recursive" did not parse its "--diff-algorithm=" command - line option correctly. - - * "git branch --track" had a minor regression in v1.8.3.2 and later - that made it impossible to base your local work on anything but a - local branch of the upstream repository you are tracking from. - - * "git ls-files -k" needs to crawl only the part of the working tree - that may overlap the paths in the index to find killed files, but - shared code with the logic to find all the untracked files, which - made it unnecessarily inefficient. - - * When there is no sufficient overlap between old and new history - during a "git fetch" into a shallow repository, objects that the - sending side knows the receiving end has were unnecessarily sent. - - * When running "fetch -q", a long silence while the sender side - computes the set of objects to send can be mistaken by proxies as - dropped connection. The server side has been taught to send a - small empty messages to keep the connection alive. - - * When the webserver responds with "405 Method Not Allowed", "git - http-backend" should tell the client what methods are allowed with - the "Allow" header. - - * "git cvsserver" computed the permission mode bits incorrectly for - executable files. - - * The implementation of "add -i" has a crippling code to work around - ActiveState Perl limitation but it by mistake also triggered on Git - for Windows where MSYS perl is used. - - * We made sure that we notice the user-supplied GIT_DIR is actually a - gitfile, but did not do the same when the default ".git" is a - gitfile. - - * When an object is not found after checking the packfiles and then - loose object directory, read_sha1_file() re-checks the packfiles to - prevent racing with a concurrent repacker; teach the same logic to - has_sha1_file(). - - * "git commit --author=$name", when $name is not in the canonical - "A. U. Thor <au.thor@example.xz>" format, looks for a matching name - from existing history, but did not consult mailmap to grab the - preferred author name. - - * The commit object names in the insn sheet that was prepared at the - beginning of "rebase -i" session can become ambiguous as the - rebasing progresses and the repository gains more commits. Make - sure the internal record is kept with full 40-hex object names. - - * "git rebase --preserve-merges" internally used the merge machinery - and as a side effect, left merge summary message in the log, but - when rebasing, there should not be a need for merge summary. - - * "git rebase -i" forgot that the comment character can be - configurable while reading its insn sheet. - -Also contains a handful of trivial code clean-ups, documentation -updates, updates to the test suite, etc. diff --git a/third_party/git/Documentation/RelNotes/1.8.4.3.txt b/third_party/git/Documentation/RelNotes/1.8.4.3.txt deleted file mode 100644 index 267a1b34b4..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.4.3.txt +++ /dev/null @@ -1,54 +0,0 @@ -Git v1.8.4.3 Release Notes -========================== - -Fixes since v1.8.4.2 --------------------- - - * The interaction between use of Perl in our test suite and NO_PERL - has been clarified a bit. - - * A fast-import stream expresses a pathname with funny characters by - quoting them in C style; remote-hg remote helper (in contrib/) - forgot to unquote such a path. - - * One long-standing flaw in the pack transfer protocol used by "git - clone" was that there was no way to tell the other end which branch - "HEAD" points at, and the receiving end needed to guess. A new - capability has been defined in the pack protocol to convey this - information so that cloning from a repository with more than one - branches pointing at the same commit where the HEAD is at now - reliably sets the initial branch in the resulting repository. - - * We did not handle cases where http transport gets redirected during - the authorization request (e.g. from http:// to https://). - - * "git rev-list --objects ^v1.0^ v1.0" gave v1.0 tag itself in the - output, but "git rev-list --objects v1.0^..v1.0" did not. - - * The fall-back parsing of commit objects with broken author or - committer lines were less robust than ideal in picking up the - timestamps. - - * Bash prompting code to deal with an SVN remote as an upstream - were coded in a way not supported by older Bash versions (3.x). - - * "git checkout topic", when there is not yet a local "topic" branch - but there is a unique remote-tracking branch for a remote "topic" - branch, pretended as if "git checkout -t -b topic remote/$r/topic" - (for that unique remote $r) was run. This hack however was not - implemented for "git checkout topic --". - - * Coloring around octopus merges in "log --graph" output was screwy. - - * We did not generate HTML version of documentation to "git subtree" - in contrib/. - - * The synopsis section of "git unpack-objects" documentation has been - clarified a bit. - - * An ancient How-To on serving Git repositories on an HTTP server - lacked a warning that it has been mostly superseded with more - modern way. - -Also contains a handful of trivial code clean-ups, documentation -updates, updates to the test suite, etc. diff --git a/third_party/git/Documentation/RelNotes/1.8.4.4.txt b/third_party/git/Documentation/RelNotes/1.8.4.4.txt deleted file mode 100644 index a7c1ce15c0..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.4.4.txt +++ /dev/null @@ -1,10 +0,0 @@ -Git v1.8.4.4 Release Notes -========================== - -Fixes since v1.8.4.3 --------------------- - - * The fix in v1.8.4.3 to the pack transfer protocol to propagate - the target of symbolic refs broke "git clone/git fetch" from a - repository with too many symbolic refs. As a hotfix/workaround, - we transfer only the information on HEAD. diff --git a/third_party/git/Documentation/RelNotes/1.8.4.5.txt b/third_party/git/Documentation/RelNotes/1.8.4.5.txt deleted file mode 100644 index 215bd1a7a2..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.4.5.txt +++ /dev/null @@ -1,13 +0,0 @@ -Git v1.8.4.5 Release Notes -========================== - -Fixes since v1.8.4.4 --------------------- - - * Recent update to remote-hg that attempted to make it work better - with non ASCII pathnames fed Unicode strings to the underlying Hg - API, which was wrong. - - * "git submodule init" copied "submodule.$name.update" settings from - .gitmodules to .git/config without making sure if the suggested - value was sensible. diff --git a/third_party/git/Documentation/RelNotes/1.8.4.txt b/third_party/git/Documentation/RelNotes/1.8.4.txt deleted file mode 100644 index 02f681b710..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.4.txt +++ /dev/null @@ -1,486 +0,0 @@ -Git v1.8.4 Release Notes -======================== - -Backward compatibility notes (for Git 2.0) ------------------------------------------- - -When "git push [$there]" does not say what to push, we have used the -traditional "matching" semantics so far (all your branches were sent -to the remote as long as there already are branches of the same name -over there). In Git 2.0, the default will change to the "simple" -semantics that pushes: - - - only the current branch to the branch with the same name, and only - when the current branch is set to integrate with that remote - branch, if you are pushing to the same remote as you fetch from; or - - - only the current branch to the branch with the same name, if you - are pushing to a remote that is not where you usually fetch from. - -Use the user preference configuration variable "push.default" to -change this. If you are an old-timer who is used to the "matching" -semantics, you can set the variable to "matching" to keep the -traditional behaviour. If you want to live in the future early, you -can set it to "simple" today without waiting for Git 2.0. - -When "git add -u" (and "git add -A") is run inside a subdirectory and -does not specify which paths to add on the command line, it -will operate on the entire tree in Git 2.0 for consistency -with "git commit -a" and other commands. There will be no -mechanism to make plain "git add -u" behave like "git add -u .". -Current users of "git add -u" (without a pathspec) should start -training their fingers to explicitly say "git add -u ." -before Git 2.0 comes. A warning is issued when these commands are -run without a pathspec and when you have local changes outside the -current directory, because the behaviour in Git 2.0 will be different -from today's version in such a situation. - -In Git 2.0, "git add <path>" will behave as "git add -A <path>", so -that "git add dir/" will notice paths you removed from the directory -and record the removal. Versions before Git 2.0, including this -release, will keep ignoring removals, but the users who rely on this -behaviour are encouraged to start using "git add --ignore-removal <path>" -now before 2.0 is released. - - -Updates since v1.8.3 --------------------- - -Foreign interfaces, subsystems and ports. - - * Cygwin port has been updated for more recent Cygwin 1.7. - - * "git rebase -i" now honors --strategy and -X options. - - * Git-gui has been updated to its 0.18.0 version. - - * MediaWiki remote helper (in contrib/) has been updated to use the - credential helper interface from Git.pm. - - * Update build for Cygwin 1.[57]. Torsten Bรถgershausen reports that - this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it - ahead. - - * The credential helper to talk to keychain on OS X (in contrib/) has - been updated to kick in not just when talking http/https but also - imap(s) and smtp. - - * Remote transport helper has been updated to report errors and - maintain ref hierarchy used to keep track of its own state better. - - * With "export" remote-helper protocol, (1) a push that tries to - update a remote ref whose name is different from the pushing side - does not work yet, and (2) the helper may not know how to do - --dry-run; these problematic cases are disabled for now. - - * git-remote-hg/bzr (in contrib/) updates. - - * git-remote-mw (in contrib/) hints users to check the certificate, - when https:// connection failed. - - * git-remote-mw (in contrib/) adds a command to allow previewing the - contents locally before pushing it out, when working with a - MediaWiki remote. - - -UI, Workflows & Features - - * Sample "post-receive-email" hook script got an enhanced replacement - "multimail" (in contrib/). - - * Also in contrib/ is a new "contacts" script that runs "git blame" - to find out the people who may be interested in a set of changes. - - * "git clean" command learned an interactive mode. - - * The "--head" option to "git show-ref" was only to add "HEAD" to the - list of candidate refs to be filtered by the usual rules - (e.g. "--heads" that only show refs under refs/heads). The meaning - of the option has been changed to always show "HEAD" regardless of - what filtering will be applied to any other ref. - - This is a backward incompatible change and might cause breakages to - people's existing scripts. - - * "git show -s" was less discoverable than it should have been. It - now has a natural synonym "git show --no-patch". - - * "git check-mailmap" is a new command that lets you map usernames - and e-mail addresses through the mailmap mechanism, just like many - built-in commands do. - - * "git name-rev" learned to name an annotated tag object back to its - tagname; "git name-rev $(git rev-parse v1.0.0)" gives "tags/v1.0.0", - for example. - - * "git cat-file --batch-check=<format>" is added, primarily to allow - on-disk footprint of objects in packfiles (often they are a lot - smaller than their true size, when expressed as deltas) to be - reported. - - * "git rebase [-i]" used to leave just "rebase" as its reflog messages - for some operations. They have been reworded to be more informative. - - * In addition to the choice from "rebase, merge, or checkout-detach", - "submodule update" can allow a custom command to be used in to - update the working tree of submodules via the "submodule.*.update" - configuration variable. - - * "git submodule update" can optionally clone the submodule - repositories shallowly. - - * "git format-patch" learned "--from[=whom]" option, which sets the - "From: " header to the specified person (or the person who runs the - command, if "=whom" part is missing) and move the original author - information to an in-body From: header as necessary. - - * The configuration variable "merge.ff" was cleary a tri-state to - choose one from "favor fast-forward when possible", "always create - a merge even when the history could fast-forward" and "do not - create any merge, only update when the history fast-forwards", but - the command line parser did not implement the usual convention of - "last one wins, and command line overrides the configuration" - correctly. - - * "gitweb" learned to optionally place extra links that point at the - levels higher than the Gitweb pages themselves in the breadcrumbs, - so that it can be used as part of a larger installation. - - * "git log --format=" now honors i18n.logoutputencoding configuration - variable. - - * The "push.default=simple" mode of "git push" has been updated to - behave like "current" without requiring a remote tracking - information, when you push to a remote that is different from where - you fetch from (i.e. a triangular workflow). - - * Having multiple "fixup!" on a line in the rebase instruction sheet - did not work very well with "git rebase -i --autosquash". - - * "git log" learned the "--author-date-order" option, with which the - output is topologically sorted and commits in parallel histories - are shown intermixed together based on the author timestamp. - - * Various subcommands of "git submodule" refused to run from anywhere - other than the top of the working tree of the superproject, but - they have been taught to let you run from a subdirectory. - - * "git diff" learned a mode that ignores hunks whose change consists - only of additions and removals of blank lines, which is the same as - "diff -B" (ignore blank lines) of GNU diff. - - * "git rm" gives a single message followed by list of paths to report - multiple paths that cannot be removed. - - * "git rebase" can be told with ":/look for this string" syntax commits - to replay the changes onto and where the work to be replayed begins. - - * Many tutorials teach users to set "color.ui" to "auto" as the first - thing after you set "user.name/email" to introduce yourselves to - Git. Now the variable defaults to "auto". - - * On Cygwin, "cygstart" is now recognised as a possible way to start - a web browser (used in "help -w" and "instaweb" among others). - - * "git status" learned status.branch and status.short configuration - variables to use --branch and --short options by default (override - with --no-branch and --no-short options from the command line). - - * "git cmd <name>", when <name> happens to be a 40-hex string, - directly uses the 40-hex string as an object name, even if a ref - "refs/<some hierarchy>/<name>" exists. This disambiguation order - is unlikely to change, but we should warn about the ambiguity just - like we warn when more than one refs/ hierarchies share the same - name. - - * "git rebase" learned "--[no-]autostash" option to save local - changes instead of refusing to run (to which people's normal - response was to stash them and re-run). This introduced a corner - case breakage to "git am --abort" but it has been fixed. - - * "check-ignore" (new feature since 1.8.2) has been updated to work - more like "check-attr" over bidi-pipes. - - * "git describe" learned "--first-parent" option to limit its closest - tagged commit search to the first-parent chain. - - * "git merge foo" that might have meant "git merge origin/foo" is - diagnosed with a more informative error message. - - * "git log -L<line>,<range>:<filename>" has been added. This may - still have leaks and rough edges, though. - - * We used the approxidate() parser for "--expire=<timestamp>" options - of various commands, but it is better to treat --expire=all and - --expire=now a bit more specially than using the current timestamp. - "git gc" and "git reflog" have been updated with a new parsing - function for expiry dates. - - * Updates to completion (both bash and zsh) helpers. - - * The behaviour of the "--chain-reply-to" option of "git send-email" - have changed at 1.7.0, and we added a warning/advice message to - help users adjust to the new behaviour back then, but we kept it - around for too long. The message has finally been removed. - - * "git fetch origin master" unlike "git fetch origin" or "git fetch" - did not update "refs/remotes/origin/master"; this was an early - design decision to keep the update of remote tracking branches - predictable, but in practice it turns out that people find it more - convenient to opportunistically update them whenever we have a - chance, and we have been updating them when we run "git push" which - already breaks the original "predictability" anyway. - - * The configuration variable core.checkstat was advertised in the - documentation but the code expected core.statinfo instead. - For now, we accept both core.checkstat and core.statinfo, but the - latter will be removed in the longer term. - - -Performance, Internal Implementation, etc. - - * On Cygwin, we used to use our own lstat(2) emulation that is - allegedly faster than the platform one in codepaths where some of - the information it returns did not matter, but it started to bite - us in a few codepaths where the trick it uses to cheat does show - breakages. This emulation has been removed and we use the native - lstat(2) emulation supplied by Cygwin now. - - * The function attributes extensions are used to catch mistakes in - use of our own variadic functions that use NULL sentinel at the end - (i.e. like execl(3)) and format strings (i.e. like printf(3)). - - * The code to allow configuration data to be read from in-tree blob - objects is in. This may help working in a bare repository and - submodule updates. - - * Fetching between repositories with many refs employed O(n^2) - algorithm to match up the common objects, which has been corrected. - - * The original way to specify remote repository using .git/branches/ - used to have a nifty feature. The code to support the feature was - still in a function but the caller was changed not to call it 5 - years ago, breaking that feature and leaving the supporting code - unreachable. The dead code has been removed. - - * "git pack-refs" that races with new ref creation or deletion have - been susceptible to lossage of refs under right conditions, which - has been tightened up. - - * We read loose and packed references in two steps, but after - deciding to read a loose ref but before actually opening it to read - it, another process racing with us can unlink it, which would cause - us to barf. The codepath has been updated to retry when such a - race is detected, instead of outright failing. - - * Uses of the platform fnmatch(3) function (many places in the code, - matching pathspec, .gitignore and .gitattributes to name a few) - have been replaced with wildmatch, allowing "foo/**/bar" that would - match foo/bar, foo/a/bar, foo/a/b/bar, etc. - - * Memory ownership and lifetime rules for what for-each-ref feeds to - its callbacks have been clarified (in short, "you do not own it, so - make a copy if you want to keep it"). - - * The revision traversal logic to improve culling of irrelevant - parents while traversing a mergy history has been updated. - - * Some leaks in unpack-trees (used in merge, cherry-pick and other - codepaths) have been plugged. - - * The codepath to read from marks files in fast-import/export did not - have to accept anything but 40-hex representation of the object - name. Further, fast-export did not need full in-core object - representation to have parsed wen reading from them. These - codepaths have been optimized by taking advantage of these access - patterns. - - * Object lookup logic, when the object hashtable starts to become - crowded, has been optimized. - - * When TEST_OUTPUT_DIRECTORY setting is used, it was handled somewhat - inconsistently between the test framework and t/Makefile, and logic - to summarize the results looked at a wrong place. - - * "git clone" uses a lighter-weight implementation when making sure - that the history behind refs are complete. - - * Many warnings from sparse source checker in compat/ area has been - squelched. - - * The code to reading and updating packed-refs file has been updated, - correcting corner case bugs. - - -Also contains various documentation updates and code clean-ups. - - -Fixes since v1.8.3 ------------------- - -Unless otherwise noted, all the fixes since v1.8.3 in the maintenance -track are contained in this release (see release notes to them for -details). - - * Newer Net::SMTP::SSL module does not want the user programs to use - the default behaviour to let server certificate go without - verification, so by default enable the verification with a - mechanism to turn it off if needed. - (merge 35035bb rr/send-email-ssl-verify later to maint). - - * When "git" is spawned in such a way that any of the low 3 file - descriptors is closed, our first open() may yield file descriptor 2, - and writing error message to it would screw things up in a big way. - (merge a11c396 tr/protect-low-3-fds later to maint). - - * The mailmap mechanism unnecessarily downcased the e-mail addresses - in the output, and also ignored the human name when it is a single - character name. - (merge bd23794 jc/mailmap-case-insensitivity later to maint). - - * In two places we did not check return value (expected to be a file - descriptor) correctly. - (merge a77f106 tr/fd-gotcha-fixes later to maint). - - * Logic to auto-detect character encodings in the commit log message - did not reject overlong and invalid UTF-8 characters. - (merge 81050ac bc/commit-invalid-utf8 later to maint). - - * Pass port number as a separate argument when "send-email" initializes - Net::SMTP, instead of as a part of the hostname, i.e. host:port. - This allows GSSAPI codepath to match with the hostname given. - (merge 1a741bf bc/send-email-use-port-as-separate-param later to maint). - - * "git diff" refused to even show difference when core.safecrlf is - set to true (i.e. error out) and there are offending lines in the - working tree files. - (merge 5430bb2 jc/maint-diff-core-safecrlf later to maint). - - * A test that should have failed but didn't revealed a bug that needs - to be corrected. - (merge 94d75d1 jc/t1512-fix later to maint). - - * An overlong path to a .git directory may have overflown the - temporary path buffer used to create a name for lockfiles. - (merge 2fbd4f9 mh/maint-lockfile-overflow later to maint). - - * Invocations of "git checkout" used internally by "git rebase" were - counted as "checkout", and affected later "git checkout -" to the - the user to an unexpected place. - (merge 3bed291 rr/rebase-checkout-reflog later to maint). - - * The configuration variable column.ui was poorly documented. - (merge 5e62cc1 rr/column-doc later to maint). - - * "git name-rev --refs=tags/v*" were forbidden, which was a bit - inconvenient (you had to give a pattern to match refs fully, like - --refs=refs/tags/v*). - (merge 98c5c4a nk/name-rev-abbreviated-refs later to maint). - - * "git apply" parsed patches that add new files, generated by - programs other than Git, incorrectly. This is an old breakage in - v1.7.11 and will need to be merged down to the maintenance tracks. - - * Older cURL wanted piece of memory we call it with to be stable, but - we updated the auth material after handing it to a call. - - * "git pull" into nothing trashed "local changes" that were in the - index, and this avoids it. - - * Many "git submodule" operations do not work on a submodule at a - path whose name is not in ASCII. - - * "cherry-pick" had a small leak in an error codepath. - - * Logic used by git-send-email to suppress cc mishandled names like - "A U. Thor" <author@example.xz>, where the human readable part - needs to be quoted (the user input may not have the double quotes - around the name, and comparison was done between quoted and - unquoted strings). It also mishandled names that need RFC2047 - quoting. - - * Call to discard_cache/discard_index (used when we use different - contents of the index in-core, in many operations like commit, - apply, and merge) used to leak memory that held the array of index - entries, which has been plugged. - (merge a0fc4db rs/discard-index-discard-array later to maint). - - * "gitweb" forgot to clear a global variable $search_regexp upon each - request, mistakenly carrying over the previous search to a new one - when used as a persistent CGI. - - * The wildmatch engine did not honor WM_CASEFOLD option correctly. - - * "git log -c --follow $path" segfaulted upon hitting the commit that - renamed the $path being followed. - - * When a reflog notation is used for implicit "current branch", we - did not say which branch and worse said "branch ''". - - * "difftool --dir-diff" did not copy back changes made by the - end-user in the diff tool backend to the working tree in some - cases. - - * "git push $there HEAD:branch" did not resolve HEAD early enough, so - it was easy to flip it around while push is still going on and push - out a branch that the user did not originally intended when the - command was started. - - * The bash prompt code (in contrib/) displayed the name of the branch - being rebased when "rebase -i/-m/-p" modes are in use, but not the - plain vanilla "rebase". - - * Handling of negative exclude pattern for directories "!dir" was - broken in the update to v1.8.3. - - * zsh prompt script that borrowed from bash prompt script did not - work due to slight differences in array variable notation between - these two shells. - - * An entry for "file://" scheme in the enumeration of URL types Git - can take in the HTML documentation was made into a clickable link - by mistake. - - * "git push --[no-]verify" was not documented. - - * Stop installing the git-remote-testpy script that is only used for - testing. - - * "git commit --allow-empty-message -m ''" should not start an - editor. - - * "git merge @{-1}~22" was rewritten to "git merge frotz@{1}~22" - incorrectly when your previous branch was "frotz" (it should be - rewritten to "git merge frotz~22" instead). - - * "git diff -c -p" was not showing a deleted line from a hunk when - another hunk immediately begins where the earlier one ends. - - * "git log --ancestry-path A...B" did not work as expected, as it did - not pay attention to the fact that the merge base between A and B - was the bottom of the range being specified. - - * Mac OS X does not like to write(2) more than INT_MAX number of - bytes; work it around by chopping write(2) into smaller pieces. - - * Newer MacOS X encourages the programs to compile and link with - their CommonCrypto, not with OpenSSL. - - * "git clone foo/bar:baz" cannot be a request to clone from a remote - over git-over-ssh specified in the scp style. This case is now - detected and clones from a local repository at "foo/bar:baz". - - * When $HOME is misconfigured to point at an unreadable directory, we - used to complain and die. Loosen the check. - - * "git subtree" (in contrib/) had one codepath with loose error - checks to lose data at the remote side. - - * "git fetch" into a shallow repository from a repository that does - not know about the shallow boundary commits (e.g. a different fork - from the repository the current shallow repository was cloned from) - did not work correctly. - - * "git checkout foo" DWIMs the intended "upstream" and turns it into - "git checkout -t -b foo remotes/origin/foo". This codepath has been - updated to correctly take existing remote definitions into account. diff --git a/third_party/git/Documentation/RelNotes/1.8.5.1.txt b/third_party/git/Documentation/RelNotes/1.8.5.1.txt deleted file mode 100644 index 7236aaf232..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.5.1.txt +++ /dev/null @@ -1,9 +0,0 @@ -Git v1.8.5.1 Release Notes -========================== - -Fixes since v1.8.5 ------------------- - - * "git submodule init" copied "submodule.$name.update" settings from - .gitmodules to .git/config without making sure if the suggested - value was sensible. diff --git a/third_party/git/Documentation/RelNotes/1.8.5.2.txt b/third_party/git/Documentation/RelNotes/1.8.5.2.txt deleted file mode 100644 index 3ac4984f10..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.5.2.txt +++ /dev/null @@ -1,20 +0,0 @@ -Git v1.8.5.2 Release Notes -========================== - -Fixes since v1.8.5.1 --------------------- - - * "git diff -- ':(icase)makefile'" was unnecessarily rejected at the - command line parser. - - * "git cat-file --batch-check=ok" did not check the existence of - the named object. - - * "git am --abort" sometimes complained about not being able to write - a tree with an 0{40} object in it. - - * Two processes creating loose objects at the same time could have - failed unnecessarily when the name of their new objects started - with the same byte value, due to a race condition. - -Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/1.8.5.3.txt b/third_party/git/Documentation/RelNotes/1.8.5.3.txt deleted file mode 100644 index 3de2dd0f19..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.5.3.txt +++ /dev/null @@ -1,27 +0,0 @@ -Git v1.8.5.3 Release Notes -========================== - -Fixes since v1.8.5.2 --------------------- - - * The "--[no-]informative-errors" options to "git daemon" were parsed - a bit too loosely, allowing any other string after these option - names. - - * A "gc" process running as a different user should be able to stop a - new "gc" process from starting. - - * An earlier "clean-up" introduced an unnecessary memory leak to the - credential subsystem. - - * "git mv A B/", when B does not exist as a directory, should error - out, but it didn't. - - * "git rev-parse <revs> -- <paths>" did not implement the usual - disambiguation rules the commands in the "git log" family used in - the same way. - - * "git cat-file --batch=", an admittedly useless command, did not - behave very well. - -Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/1.8.5.4.txt b/third_party/git/Documentation/RelNotes/1.8.5.4.txt deleted file mode 100644 index d18c40389e..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.5.4.txt +++ /dev/null @@ -1,48 +0,0 @@ -Git v1.8.5.4 Release Notes -========================== - -Fixes since v1.8.5.3 --------------------- - - * "git fetch --depth=0" was a no-op, and was silently ignored. - Diagnose it as an error. - - * Remote repository URL expressed in scp-style host:path notation are - parsed more carefully (e.g. "foo/bar:baz" is local, "[::1]:/~user" asks - to connect to user's home directory on host at address ::1. - - * SSL-related options were not passed correctly to underlying socket - layer in "git send-email". - - * "git commit -v" appends the patch to the log message before - editing, and then removes the patch when the editor returned - control. However, the patch was not stripped correctly when the - first modified path was a submodule. - - * "git mv A B/", when B does not exist as a directory, should error - out, but it didn't. - - * When we figure out how many file descriptors to allocate for - keeping packfiles open, a system with non-working getrlimit() could - cause us to die(), but because we make this call only to get a - rough estimate of how many is available and we do not even attempt - to use up all file descriptors available ourselves, it is nicer to - fall back to a reasonable low value rather than dying. - - * "git log --decorate" did not handle a tag pointed by another tag - nicely. - - * "git add -A" (no other arguments) in a totally empty working tree - used to emit an error. - - * There is no reason to have a hardcoded upper limit of the number of - parents for an octopus merge, created via the graft mechanism, but - there was. - - * The implementation of 'git stash $cmd "stash@{...}"' did not quote - the stash argument properly and left it split at IFS whitespace. - - * The documentation to "git pull" hinted there is an "-m" option - because it incorrectly shared the documentation with "git merge". - -Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/1.8.5.5.txt b/third_party/git/Documentation/RelNotes/1.8.5.5.txt deleted file mode 100644 index 9191ce948f..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.5.5.txt +++ /dev/null @@ -1,37 +0,0 @@ -Git v1.8.5.5 Release Notes -========================== - -Fixes since v1.8.5.4 --------------------- - - * The pathspec matching code, while comparing two trees (e.g. "git - diff A B -- path1 path2") was too aggressive and failed to match - some paths when multiple pathspecs were involved. - - * "git repack --max-pack-size=8g" stopped being parsed correctly when - the command was reimplemented in C. - - * A recent update to "git send-email" broke platforms where - /etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path - (e.g. Fedora rawhide). - - * A handful of bugs around interpreting $branch@{upstream} notation - and its lookalike, when $branch part has interesting characters, - e.g. "@", and ":", have been fixed. - - * "git clone" would fail to clone from a repository that has a ref - directly under "refs/", e.g. "refs/stash", because different - validation paths do different things on such a refname. Loosen the - client side's validation to allow such a ref. - - * "git log --left-right A...B" lost the "leftness" of commits - reachable from A when A is a tag as a side effect of a recent - bugfix. This is a regression in 1.8.4.x series. - - * "git merge-base --octopus" used to leave cleaning up suboptimal - result to the caller, but now it does the clean-up itself. - - * "git mv A B/", when B does not exist as a directory, should error - out, but it didn't. - -Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/1.8.5.6.txt b/third_party/git/Documentation/RelNotes/1.8.5.6.txt deleted file mode 100644 index 92ff92b1e6..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.5.6.txt +++ /dev/null @@ -1,34 +0,0 @@ -Git v1.8.5.6 Release Notes -========================== - -Fixes since v1.8.5.5 --------------------- - - * We used to allow committing a path ".Git/config" with Git that is - running on a case sensitive filesystem, but an attempt to check out - such a path with Git that runs on a case insensitive filesystem - would have clobbered ".git/config", which is definitely not what - the user would have expected. Git now prevents you from tracking - a path with ".Git" (in any case combination) as a path component. - - * On Windows, certain path components that are different from ".git" - are mapped to ".git", e.g. "git~1/config" is treated as if it were - ".git/config". HFS+ has a similar issue, where certain unicode - codepoints are ignored, e.g. ".g\u200cit/config" is treated as if - it were ".git/config". Pathnames with these potential issues are - rejected on the affected systems. Git on systems that are not - affected by this issue (e.g. Linux) can also be configured to - reject them to ensure cross platform interoperability of the hosted - projects. - - * "git fsck" notices a tree object that records such a path that can - be confused with ".git", and with receive.fsckObjects configuration - set to true, an attempt to "git push" such a tree object will be - rejected. Such a path may not be a problem on a well behaving - filesystem but in order to protect those on HFS+ and on case - insensitive filesystems, this check is enabled on all platforms. - -A big "thanks!" for bringing this issue to us goes to our friends in -the Mercurial land, namely, Matt Mackall and Augie Fackler. - -Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/1.8.5.txt b/third_party/git/Documentation/RelNotes/1.8.5.txt deleted file mode 100644 index 602df0cac2..0000000000 --- a/third_party/git/Documentation/RelNotes/1.8.5.txt +++ /dev/null @@ -1,456 +0,0 @@ -Git v1.8.5 Release Notes -======================== - -Backward compatibility notes (for Git 2.0) ------------------------------------------- - -When "git push [$there]" does not say what to push, we have used the -traditional "matching" semantics so far (all your branches were sent -to the remote as long as there already are branches of the same name -over there). In Git 2.0, the default will change to the "simple" -semantics, which pushes: - - - only the current branch to the branch with the same name, and only - when the current branch is set to integrate with that remote - branch, if you are pushing to the same remote as you fetch from; or - - - only the current branch to the branch with the same name, if you - are pushing to a remote that is not where you usually fetch from. - -Use the user preference configuration variable "push.default" to -change this. If you are an old-timer who is used to the "matching" -semantics, you can set the variable to "matching" to keep the -traditional behaviour. If you want to live in the future early, you -can set it to "simple" today without waiting for Git 2.0. - -When "git add -u" (and "git add -A") is run inside a subdirectory and -does not specify which paths to add on the command line, it -will operate on the entire tree in Git 2.0 for consistency -with "git commit -a" and other commands. There will be no -mechanism to make plain "git add -u" behave like "git add -u .". -Current users of "git add -u" (without a pathspec) should start -training their fingers to explicitly say "git add -u ." -before Git 2.0 comes. A warning is issued when these commands are -run without a pathspec and when you have local changes outside the -current directory, because the behaviour in Git 2.0 will be different -from today's version in such a situation. - -In Git 2.0, "git add <path>" will behave as "git add -A <path>", so -that "git add dir/" will notice paths you removed from the directory -and record the removal. Versions before Git 2.0, including this -release, will keep ignoring removals, but the users who rely on this -behaviour are encouraged to start using "git add --ignore-removal <path>" -now before 2.0 is released. - -The default prefix for "git svn" will change in Git 2.0. For a long -time, "git svn" created its remote-tracking branches directly under -refs/remotes, but it will place them under refs/remotes/origin/ unless -it is told otherwise with its --prefix option. - - -Updates since v1.8.4 --------------------- - -Foreign interfaces, subsystems and ports. - - * "git-svn" has been taught to use the serf library, which is the - only option SVN 1.8.0 offers us when talking the HTTP protocol. - - * "git-svn" talking over an https:// connection using the serf library - dumped core due to a bug in the serf library that SVN uses. Work - around it on our side, even though the SVN side is being fixed. - - * On MacOS X, we detected if the filesystem needs the "pre-composed - unicode strings" workaround, but did not automatically enable it. - Now we do. - - * remote-hg remote helper misbehaved when interacting with a local Hg - repository relative to the home directory, e.g. "clone hg::~/there". - - * imap-send ported to OS X uses Apple's security framework instead of - OpenSSL's. - - * "git fast-import" treats an empty path given to "ls" as the root of - the tree. - - -UI, Workflows & Features - - * xdg-open can be used as a browser backend for "git web-browse" - (hence to show "git help -w" output), when available. - - * "git grep" and "git show" pay attention to the "--textconv" option - when these commands are told to operate on blob objects (e.g. "git - grep -e pattern --textconv HEAD:Makefile"). - - * "git replace" helper no longer allows an object to be replaced with - another object of a different type to avoid confusion (you can - still manually craft such a replacement using "git update-ref", as an - escape hatch). - - * "git status" no longer prints the dirty status information of - submodules for which submodule.$name.ignore is set to "all". - - * "git rebase -i" honours core.abbrev when preparing the insn sheet - for editing. - - * "git status" during a cherry-pick shows which original commit is - being picked. - - * Instead of typing four capital letters "HEAD", you can say "@" now, - e.g. "git log @". - - * "git check-ignore" follows the same rule as "git add" and "git - status" in that the ignore/exclude mechanism does not take effect - on paths that are already tracked. With the "--no-index" option, it - can be used to diagnose which paths that should have been ignored - have been mistakenly added to the index. - - * Some irrelevant "advice" messages that are shared with "git status" - output have been removed from the commit log template. - - * "update-refs" learned a "--stdin" option to read multiple update - requests and perform them in an all-or-none fashion. - - * Just like "make -C <directory>", "git -C <directory> ..." tells Git - to go there before doing anything else. - - * Just like "git checkout -" knows to check out, and "git merge -" - knows to merge, the branch you were previously on, "git cherry-pick" - now understands "git cherry-pick -" to pick from the previous - branch. - - * "git status" now omits the prefix to make its output a comment in a - commit log editor, which is not necessary for human consumption. - Scripts that parse the output of "git status" are advised to use - "git status --porcelain" instead, as its format is stable and easier - to parse. - - * The ref syntax "foo^{tag}" (with the literal string "{tag}") peels a - tag ref to itself, i.e. it's a no-op., and fails if - "foo" is not a tag. "git rev-parse --verify v1.0^{tag}" is - a more convenient way than "test $(git cat-file -t v1.0) = tag" to - check if v1.0 is a tag. - - * "git branch -v -v" (and "git status") did not distinguish among a - branch that is not based on any other branch, a branch that is in - sync with its upstream branch, and a branch that is configured with an - upstream branch that no longer exists. - - * Earlier we started rejecting any attempt to add the 0{40} object name to - the index and to tree objects, but it sometimes is necessary to - allow this to be able to use tools like filter-branch to correct such - broken tree objects. "filter-branch" can again be used to do this. - - * "git config" did not provide a way to set or access numbers larger - than a native "int" on the platform; it now provides 64-bit signed - integers on all platforms. - - * "git pull --rebase" always chose to do the bog-standard flattening - rebase. You can tell it to run "rebase --preserve-merges" with - "git pull --rebase=preserve" or by - setting "pull.rebase" configuration to "preserve". - - * "git push --no-thin" actually disables the "thin pack transfer" - optimization. - - * Magic pathspecs like ":(icase)makefile" (matches both Makefile - and makefile) and ":(glob)foo/**/bar" (matches "bar" in "foo" - and any subdirectory of "foo") can be used in more places. - - * The "http.*" variables can now be specified for individual URLs. - For example, - - [http] - sslVerify = true - [http "https://weak.example.com/"] - sslVerify = false - - would flip http.sslVerify off only when talking to that specific - site. - - * "git mv A B" when moving a submodule has been taught to - relocate the submodule's working tree and to adjust the paths in the - .gitmodules file. - - * "git blame" can now take more than one -L option to discover the - origin of multiple blocks of lines. - - * The http transport clients can optionally ask to save cookies - with the http.savecookies configuration variable. - - * "git push" learned a more fine grained control over a blunt - "--force" when requesting a non-fast-forward update with the - "--force-with-lease=<refname>:<expected object name>" option. - - * "git diff --diff-filter=<classes of changes>" can now take - lowercase letters (e.g. "--diff-filter=d") to mean "show - everything but these classes". "git diff-files -q" is now a - deprecated synonym for "git diff-files --diff-filter=d". - - * "git fetch" (hence "git pull" as well) learned to check - "fetch.prune" and "remote.*.prune" configuration variables and - to behave as if the "--prune" command line option was given. - - * "git check-ignore -z" applied the NUL termination to both its input - (with --stdin) and its output, but "git check-attr -z" ignored the - option on the output side. Make both honor -z on the input and - output side the same way. - - * "git whatchanged" may still be used by old timers, but mention of - it in documents meant for new users will only waste readers' time - wondering what the difference is between it and "git log". Make it - less prominent in the general part of the documentation and explain - that it is merely a "git log" with different default behaviour in - its own document. - - -Performance, Internal Implementation, etc. - - * "git for-each-ref" when asking for merely the object name does not - have to parse the object pointed at by the refs; the codepath has - been optimized. - - * The HTTP transport will try to use TCP keepalive when able. - - * "git repack" is now written in C. - - * Build procedure for MSVC has been updated. - - * If a build-time fallback is set to "cat" instead of "less", we - should apply the same "no subprocess or pipe" optimization as we - apply to user-supplied GIT_PAGER=cat. - - * Many commands use a --dashed-option as an operation mode selector - (e.g. "git tag --delete") that excludes other operation modes - (e.g. "git tag --delete --verify" is nonsense) and that cannot be - negated (e.g. "git tag --no-delete" is nonsense). The parse-options - API learned a new OPT_CMDMODE macro to make it easier to implement - such a set of options. - - * OPT_BOOLEAN() in the parse-options API was misdesigned to be "counting - up" but many subcommands expect it to behave as "on/off". Update - them to use OPT_BOOL() which is a proper boolean. - - * "git gc" exits early without doing any work when it detects - that another instance of itself is already running. - - * Under memory pressure and/or file descriptor pressure, we used to - close pack windows that are not used and also closed filehandles to - open but unused packfiles. These are now controlled separately - to better cope with the load. - -Also contains various documentation updates and code clean-ups. - - -Fixes since v1.8.4 ------------------- - -Unless otherwise noted, all the fixes since v1.8.4 in the maintenance -track are contained in this release (see the maintenance releases' notes for -details). - - * An ancient How-To on serving Git repositories on an HTTP server - lacked a warning that it has been mostly superseded with a more - modern way. - (merge 6d52bc3 sc/doc-howto-dumb-http later to maint). - - * The interaction between the use of Perl in our test suite and NO_PERL - has been clarified a bit. - (merge f8fc0ee jn/test-prereq-perl-doc later to maint). - - * The synopsis section of the "git unpack-objects" documentation has been - clarified a bit. - (merge 61e2e22 vd/doc-unpack-objects later to maint). - - * We did not generate the HTML version of the documentation to "git subtree" - in contrib/. - (merge 95c62fb jk/subtree-install-fix later to maint). - - * A fast-import stream expresses a pathname with funny characters by - quoting them in C style; the remote-hg remote helper forgot to unquote - such a path. - (merge 1136265 ap/remote-hg-unquote-cquote later to maint). - - * "git reset -p HEAD" has a codepath to special-case it to behave - differently from resetting to contents of other commits, but a - recent change broke it. - - * Coloring around octopus merges in "log --graph" output was screwy. - (merge 339c17b hn/log-graph-color-octopus later to maint). - - * "git checkout topic", when there is not yet a local "topic" branch - but there is a unique remote-tracking branch for a remote "topic" - branch, pretended as if "git checkout -t -b topic remote/$r/topic" - (for that unique remote $r) was run. This hack however was not - implemented for "git checkout topic --". - (merge bca3969 mm/checkout-auto-track-fix later to maint). - - * One long-standing flaw in the pack transfer protocol used by "git - clone" was that there was no way to tell the other end which branch - "HEAD" points at, and the receiving end needed to guess. A new - capability has been defined in the pack protocol to convey this - information so that cloning from a repository with more than one - branch pointing at the same commit where the HEAD is at now - reliably sets the initial branch in the resulting repository. - (merge 360a326 jc/upload-pack-send-symref later to maint). - - * We did not handle cases where the http transport gets redirected during - the authorization request (e.g. from http:// to https://). - (merge 70900ed jk/http-auth-redirects later to maint). - - * Bash prompting code to deal with an SVN remote as an upstream - was coded in a way unsupported by older Bash versions (3.x). - (merge 52ec889 sg/prompt-svn-remote-fix later to maint). - - * The fall-back parsing of commit objects with broken author or - committer lines was less robust than ideal in picking up the - timestamps. - (merge 03818a4 jk/split-broken-ident later to maint). - - * "git rev-list --objects ^v1.0^ v1.0" gave the v1.0 tag itself in the - output, but "git rev-list --objects v1.0^..v1.0" did not. - (merge 895c5ba jc/revision-range-unpeel later to maint). - - * "git clone" wrote some progress messages to standard output, not - to standard error, and did not suppress them with the - --no-progress option. - (merge 643f918 jk/clone-progress-to-stderr later to maint). - - * "format-patch --from=<whom>" forgot to omit an unnecessary in-body - from line, i.e. when <whom> is the same as the real author. - (merge 662cc30 jk/format-patch-from later to maint). - - * "git shortlog" used to choke and die when there is a malformed - commit (e.g. missing authors); it now simply ignores such a commit - and keeps going. - (merge cd4f09e jk/shortlog-tolerate-broken-commit later to maint). - - * "git merge-recursive" did not parse its "--diff-algorithm=" command - line option correctly. - (merge 6562928 jk/diff-algo later to maint). - - * When running "fetch -q", a long silence while the sender side - computes the set of objects to send can be mistaken by proxies as - dropped connection. The server side has been taught to send a - small empty messages to keep the connection alive. - (merge 115dedd jk/upload-pack-keepalive later to maint). - - * "git rebase" had a portability regression in v1.8.4 that triggered a - bug in some BSD shell implementations. - (merge 99855dd mm/rebase-continue-freebsd-WB later to maint). - - * "git branch --track" had a minor regression in v1.8.3.2 and later - that made it impossible to base your local work on anything but a - local branch of the upstream repository you are tracking. - (merge b0f49ff jh/checkout-auto-tracking later to maint). - - * When the web server responds with "405 Method Not Allowed", "git - http-backend" should tell the client what methods are allowed with - the "Allow" header. - (merge 9247be0 bc/http-backend-allow-405 later to maint). - - * When there is no sufficient overlap between old and new history - during a "git fetch" into a shallow repository, objects that the - sending side knows the receiving end has were unnecessarily sent. - (merge f21d2a7 nd/fetch-into-shallow later to maint). - - * "git cvsserver" computed the permission mode bits incorrectly for - executable files. - (merge 1b48d56 jc/cvsserver-perm-bit-fix later to maint). - - * When send-email obtains an error message to die with upon - failure to start an SSL session, it tried to read the error string - from a wrong place. - (merge 6cb0c88 bc/send-email-ssl-die-message-fix later to maint). - - * The implementation of "add -i" has some crippling code to work around an - ActiveState Perl limitation but it by mistake also triggered on Git - for Windows where MSYS perl is used. - (merge df17e77 js/add-i-mingw later to maint). - - * We made sure that we notice when the user-supplied GIT_DIR is actually a - gitfile, but did not do the same when the default ".git" is a - gitfile. - (merge 487a2b7 nd/git-dir-pointing-at-gitfile later to maint). - - * When an object is not found after checking the packfiles and the - loose object directory, read_sha1_file() re-checks the packfiles to - prevent racing with a concurrent repacker; teach the same logic to - has_sha1_file(). - (merge 45e8a74 jk/has-sha1-file-retry-packed later to maint). - - * "git commit --author=$name", when $name is not in the canonical - "A. U. Thor <au.thor@example.xz>" format, looks for a matching name - from existing history, but did not consult mailmap to grab the - preferred author name. - (merge ea16794 ap/commit-author-mailmap later to maint). - - * "git ls-files -k" needs to crawl only the part of the working tree - that may overlap the paths in the index to find killed files, but - shared code with the logic to find all the untracked files, which - made it unnecessarily inefficient. - (merge 680be04 jc/ls-files-killed-optim later to maint). - - * The shortened commit object names in the insn sheet that is prepared at the - beginning of a "rebase -i" session can become ambiguous as the - rebasing progresses and the repository gains more commits. Make - sure the internal record is kept with full 40-hex object names. - (merge 75c6976 es/rebase-i-no-abbrev later to maint). - - * "git rebase --preserve-merges" internally used the merge machinery - and as a side effect left the merge summary message in the log, but - when rebasing there is no need for the merge summary. - (merge a9f739c rt/rebase-p-no-merge-summary later to maint). - - * A call to xread() was used without a loop around it to cope with short - reads in the codepath to stream new contents to a pack. - (merge e92527c js/xread-in-full later to maint). - - * "git rebase -i" forgot that the comment character is - configurable while reading its insn sheet. - (merge 7bca7af es/rebase-i-respect-core-commentchar later to maint). - - * The mailmap support code read past the allocated buffer when the - mailmap file ended with an incomplete line. - (merge f972a16 jk/mailmap-incomplete-line later to maint). - - * We used to send a large request to read(2)/write(2) as a single - system call, which was bad from the latency point of view when - the operation needs to be killed, and also triggered an error on - broken 64-bit systems that refuse to read or write more than 2GB - in one go. - (merge a487916 sp/clip-read-write-to-8mb later to maint). - - * "git fetch" that auto-followed tags incorrectly reused the - connection with Git-aware transport helper (like the sample "ext::" - helper shipped with Git). - (merge 0f73f8b jc/transport-do-not-use-connect-twice-in-fetch later to maint). - - * "git log --full-diff -- <pathspec>" showed a huge diff for paths - outside the given <pathspec> for each commit, instead of showing - the change relative to the parent of the commit. "git reflog -p" - had a similar problem. - (merge 838f9a1 tr/log-full-diff-keep-true-parents later to maint). - - * Setting a submodule.*.path configuration variable to true (without - giving "= value") caused Git to segfault. - (merge 4b05440 jl/some-submodule-config-are-not-boolean later to maint). - - * "git rebase -i" (there could be others, as the root cause is pretty - generic) fed a random, data dependent string to 'echo' and - expected it to come out literally, corrupting its error message. - (merge 89b0230 mm/no-shell-escape-in-die-message later to maint). - - * Some people still use rather old versions of bash, which cannot - grok some constructs like 'printf -v varname' which the prompt and - completion code started to use recently. - (merge a44aa69 bc/completion-for-bash-3.0 later to maint). - - * Code to read configuration from a blob object did not compile on - platforms with fgetc() etc. implemented as macros. - (merge 49d6cfa hv/config-from-blob later to maint-1.8.3). - - * The recent "short-cut clone connectivity check" topic broke a - shallow repository when a fetch operation tries to auto-follow tags. - (merge 6da8bdc nd/fetch-pack-shallow-fix later to maint-1.8.3). diff --git a/third_party/git/Documentation/RelNotes/1.9.0.txt b/third_party/git/Documentation/RelNotes/1.9.0.txt deleted file mode 100644 index 4e4b88aa5c..0000000000 --- a/third_party/git/Documentation/RelNotes/1.9.0.txt +++ /dev/null @@ -1,345 +0,0 @@ -Git v1.9.0 Release Notes -======================== - -Backward compatibility notes ----------------------------- - -"git submodule foreach $cmd $args" used to treat "$cmd $args" the same -way "ssh" did, concatenating them into a single string and letting the -shell unquote. Careless users who forget to sufficiently quote $args -get their argument split at $IFS whitespaces by the shell, and got -unexpected results due to this. Starting from this release, the -command line is passed directly to the shell, if it has an argument. - -Read-only support for experimental loose-object format, in which users -could optionally choose to write their loose objects for a short -while between v1.4.3 and v1.5.3 era, has been dropped. - -The meanings of the "--tags" option to "git fetch" has changed; the -command fetches tags _in addition to_ what is fetched by the same -command line without the option. - -The way "git push $there $what" interprets the $what part given on the -command line, when it does not have a colon that explicitly tells us -what ref at the $there repository is to be updated, has been enhanced. - -A handful of ancient commands that have long been deprecated are -finally gone (repo-config, tar-tree, lost-found, and peek-remote). - - -Backward compatibility notes (for Git 2.0.0) --------------------------------------------- - -When "git push [$there]" does not say what to push, we have used the -traditional "matching" semantics so far (all your branches were sent -to the remote as long as there already are branches of the same name -over there). In Git 2.0, the default will change to the "simple" -semantics, which pushes: - - - only the current branch to the branch with the same name, and only - when the current branch is set to integrate with that remote - branch, if you are pushing to the same remote as you fetch from; or - - - only the current branch to the branch with the same name, if you - are pushing to a remote that is not where you usually fetch from. - -Use the user preference configuration variable "push.default" to -change this. If you are an old-timer who is used to the "matching" -semantics, you can set the variable to "matching" to keep the -traditional behaviour. If you want to live in the future early, you -can set it to "simple" today without waiting for Git 2.0. - -When "git add -u" (and "git add -A") is run inside a subdirectory and -does not specify which paths to add on the command line, it -will operate on the entire tree in Git 2.0 for consistency -with "git commit -a" and other commands. There will be no -mechanism to make plain "git add -u" behave like "git add -u .". -Current users of "git add -u" (without a pathspec) should start -training their fingers to explicitly say "git add -u ." -before Git 2.0 comes. A warning is issued when these commands are -run without a pathspec and when you have local changes outside the -current directory, because the behaviour in Git 2.0 will be different -from today's version in such a situation. - -In Git 2.0, "git add <path>" will behave as "git add -A <path>", so -that "git add dir/" will notice paths you removed from the directory -and record the removal. Versions before Git 2.0, including this -release, will keep ignoring removals, but the users who rely on this -behaviour are encouraged to start using "git add --ignore-removal <path>" -now before 2.0 is released. - -The default prefix for "git svn" will change in Git 2.0. For a long -time, "git svn" created its remote-tracking branches directly under -refs/remotes, but it will place them under refs/remotes/origin/ unless -it is told otherwise with its --prefix option. - - -Updates since v1.8.5 --------------------- - -Foreign interfaces, subsystems and ports. - - * The HTTP transport, when talking GSS-Negotiate, uses "100 - Continue" response to avoid having to rewind and resend a large - payload, which may not be always doable. - - * Various bugfixes to remote-bzr and remote-hg (in contrib/). - - * The build procedure is aware of MirBSD now. - - * Various "git p4", "git svn" and "gitk" updates. - - -UI, Workflows & Features - - * Fetching from a shallowly-cloned repository used to be forbidden, - primarily because the codepaths involved were not carefully vetted - and we did not bother supporting such usage. This release attempts - to allow object transfer out of a shallowly-cloned repository in a - more controlled way (i.e. the receiver becomes a shallow repository - with a truncated history). - - * Just like we give a reasonable default for "less" via the LESS - environment variable, we now specify a reasonable default for "lv" - via the "LV" environment variable when spawning the pager. - - * Two-level configuration variable names in "branch.*" and "remote.*" - hierarchies, whose variables are predominantly three-level, were - not completed by hitting a <TAB> in bash and zsh completions. - - * Fetching a 'frotz' branch with "git fetch", while a 'frotz/nitfol' - remote-tracking branch from an earlier fetch was still there, would - error out, primarily because the command was not told that it is - allowed to lose any information on our side. "git fetch --prune" - now can be used to remove 'frotz/nitfol' to make room for fetching and - storing the 'frotz' remote-tracking branch. - - * "diff.orderfile=<file>" configuration variable can be used to - pretend as if the "-O<file>" option were given from the command - line of "git diff", etc. - - * The negative pathspec syntax allows "git log -- . ':!dir'" to tell - us "I am interested in everything but 'dir' directory". - - * "git difftool" shows how many different paths there are in total, - and how many of them have been shown so far, to indicate progress. - - * "git push origin master" used to push our 'master' branch to update - the 'master' branch at the 'origin' repository. This has been - enhanced to use the same ref mapping "git push origin" would use to - determine what ref at the 'origin' to be updated with our 'master'. - For example, with this configuration - - [remote "origin"] - push = refs/heads/*:refs/review/* - - that would cause "git push origin" to push out our local branches - to corresponding refs under refs/review/ hierarchy at 'origin', - "git push origin master" would update 'refs/review/master' over - there. Alternatively, if push.default is set to 'upstream' and our - 'master' is set to integrate with 'topic' from the 'origin' branch, - running "git push origin" while on our 'master' would update their - 'topic' branch, and running "git push origin master" while on any - of our branches does the same. - - * "gitweb" learned to treat ref hierarchies other than refs/heads as - if they are additional branch namespaces (e.g. refs/changes/ in - Gerrit). - - * "git for-each-ref --format=..." learned a few formatting directives; - e.g. "%(color:red)%(HEAD)%(color:reset) %(refname:short) %(subject)". - - * The command string given to "git submodule foreach" is passed - directly to the shell, without being eval'ed. This is a backward - incompatible change that may break existing users. - - * "git log" and friends learned the "--exclude=<glob>" option, to - allow people to say "list history of all branches except those that - match this pattern" with "git log --exclude='*/*' --branches". - - * "git rev-parse --parseopt" learned a new "--stuck-long" option to - help scripts parse options with an optional parameter. - - * The "--tags" option to "git fetch" no longer tells the command to - fetch _only_ the tags. It instead fetches tags _in addition to_ - what are fetched by the same command line without the option. - - -Performance, Internal Implementation, etc. - - * When parsing a 40-hex string into the object name, the string is - checked to see if it can be interpreted as a ref so that a warning - can be given for ambiguity. The code kicked in even when the - core.warnambiguousrefs is set to false to squelch this warning, in - which case the cycles spent to look at the ref namespace were an - expensive no-op, as the result was discarded without being used. - - * The naming convention of the packfiles has been updated; it used to - be based on the enumeration of names of the objects that are - contained in the pack, but now it also depends on how the packed - result is represented--packing the same set of objects using - different settings (or delta order) would produce a pack with - different name. - - * "git diff --no-index" mode used to unnecessarily attempt to read - the index when there is one. - - * The deprecated parse-options macro OPT_BOOLEAN has been removed; - use OPT_BOOL or OPT_COUNTUP in new code. - - * A few duplicate implementations of prefix/suffix string comparison - functions have been unified to starts_with() and ends_with(). - - * The new PERLLIB_EXTRA makefile variable can be used to specify - additional directories Perl modules (e.g. the ones necessary to run - git-svn) are installed on the platform when building. - - * "git merge-base" learned the "--fork-point" mode, that implements - the same logic used in "git pull --rebase" to find a suitable fork - point out of the reflog entries for the remote-tracking branch the - work has been based on. "git rebase" has the same logic that can be - triggered with the "--fork-point" option. - - * A third-party "receive-pack" (the responder to "git push") can - advertise the "no-thin" capability to tell "git push" not to use - the thin-pack optimization. Our receive-pack has always been - capable of accepting and fattening a thin-pack, and will continue - not to ask "git push" to use a non-thin pack. - - -Also contains various documentation updates and code clean-ups. - - -Fixes since v1.8.5 ------------------- - -Unless otherwise noted, all the fixes since v1.8.5 in the maintenance -track are contained in this release (see the maintenance releases' notes -for details). - - * The pathspec matching code, while comparing two trees (e.g. "git - diff A B -- path1 path2") was too aggressive and failed to match - some paths when multiple pathspecs were involved. - - * "git repack --max-pack-size=8g" stopped being parsed correctly when - the command was reimplemented in C. - - * An earlier update in v1.8.4.x to "git rev-list --objects" with - negative ref had a performance regression. - (merge 200abe7 jk/mark-edges-uninteresting later to maint). - - * A recent update to "git send-email" broke platforms where - /etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path - (e.g. Fedora rawhide). - - * A handful of bugs around interpreting $branch@{upstream} notation - and its lookalike, when $branch part has interesting characters, - e.g. "@", and ":", have been fixed. - - * "git clone" would fail to clone from a repository that has a ref - directly under "refs/", e.g. "refs/stash", because different - validation paths do different things on such a refname. Loosen the - client side's validation to allow such a ref. - - * "git log --left-right A...B" lost the "leftness" of commits - reachable from A when A is a tag as a side effect of a recent - bugfix. This is a regression in 1.8.4.x series. - - * documentations to "git pull" hinted there is an "-m" option because - it incorrectly shared the documentation with "git merge". - - * "git diff A B submod" and "git diff A B submod/" ought to have done - the same for a submodule "submod", but didn't. - - * "git clone $origin foo\bar\baz" on Windows failed to create the - leading directories (i.e. a moral-equivalent of "mkdir -p"). - - * "submodule.*.update=checkout", when propagated from .gitmodules to - .git/config, turned into a "submodule.*.update=none", which did not - make much sense. - (merge efa8fd7 fp/submodule-checkout-mode later to maint). - - * The implementation of 'git stash $cmd "stash@{...}"' did not quote - the stash argument properly and left it split at IFS whitespace. - - * The "--[no-]informative-errors" options to "git daemon" were parsed - a bit too loosely, allowing any other string after these option - names. - - * There is no reason to have a hardcoded upper limit for the number of - parents of an octopus merge, created via the graft mechanism, but - there was. - - * The basic test used to leave unnecessary trash directories in the - t/ directory. - (merge 738a8be jk/test-framework-updates later to maint). - - * "git merge-base --octopus" used to leave cleaning up suboptimal - result to the caller, but now it does the clean-up itself. - - * A "gc" process running as a different user should be able to stop a - new "gc" process from starting, but it didn't. - - * An earlier "clean-up" introduced an unnecessary memory leak. - - * "git add -A" (no other arguments) in a totally empty working tree - used to emit an error. - - * "git log --decorate" did not handle a tag pointed by another tag - nicely. - - * When we figure out how many file descriptors to allocate for - keeping packfiles open, a system with non-working getrlimit() could - cause us to die(), but because we make this call only to get a - rough estimate of how many are available and we do not even attempt - to use up all available file descriptors ourselves, it is nicer to - fall back to a reasonable low value rather than dying. - - * read_sha1_file(), that is the workhorse to read the contents given - an object name, honoured object replacements, but there was no - corresponding mechanism to sha1_object_info() that was used to - obtain the metainfo (e.g. type & size) about the object. This led - callers to weird inconsistencies. - (merge 663a856 cc/replace-object-info later to maint). - - * "git cat-file --batch=", an admittedly useless command, did not - behave very well. - - * "git rev-parse <revs> -- <paths>" did not implement the usual - disambiguation rules the commands in the "git log" family used in - the same way. - - * "git mv A B/", when B does not exist as a directory, should error - out, but it didn't. - - * A workaround to an old bug in glibc prior to glibc 2.17 has been - retired; this would remove a side effect of the workaround that - corrupts system error messages in non-C locales. - - * SSL-related options were not passed correctly to underlying socket - layer in "git send-email". - - * "git commit -v" appends the patch to the log message before - editing, and then removes the patch when the editor returned - control. However, the patch was not stripped correctly when the - first modified path was a submodule. - - * "git fetch --depth=0" was a no-op, and was silently ignored. - Diagnose it as an error. - - * Remote repository URLs expressed in scp-style host:path notation are - parsed more carefully (e.g. "foo/bar:baz" is local, "[::1]:/~user" asks - to connect to user's home directory on host at address ::1. - - * "git diff -- ':(icase)makefile'" was unnecessarily rejected at the - command line parser. - - * "git cat-file --batch-check=ok" did not check the existence of - the named object. - - * "git am --abort" sometimes complained about not being able to write - a tree with an 0{40} object in it. - - * Two processes creating loose objects at the same time could have - failed unnecessarily when the name of their new objects started - with the same byte value, due to a race condition. diff --git a/third_party/git/Documentation/RelNotes/1.9.1.txt b/third_party/git/Documentation/RelNotes/1.9.1.txt deleted file mode 100644 index 5b0602053c..0000000000 --- a/third_party/git/Documentation/RelNotes/1.9.1.txt +++ /dev/null @@ -1,59 +0,0 @@ -Git v1.9.1 Release Notes -======================== - -Fixes since v1.9.0 ------------------- - - * "git clean -d pathspec" did not use the given pathspec correctly - and ended up cleaning too much. - - * "git difftool" misbehaved when the repository is bound to the - working tree with the ".git file" mechanism, where a textual file - ".git" tells us where it is. - - * "git push" did not pay attention to branch.*.pushremote if it is - defined earlier than remote.pushdefault; the order of these two - variables in the configuration file should not matter, but it did - by mistake. - - * Codepaths that parse timestamps in commit objects have been - tightened. - - * "git diff --external-diff" incorrectly fed the submodule directory - in the working tree to the external diff driver when it knew it is - the same as one of the versions being compared. - - * "git reset" needs to refresh the index when working in a working - tree (it can also be used to match the index to the HEAD in an - otherwise bare repository), but it failed to set up the working - tree properly, causing GIT_WORK_TREE to be ignored. - - * "git check-attr" when working on a repository with a working tree - did not work well when the working tree was specified via the - --work-tree (and obviously with --git-dir) option. - - * "merge-recursive" was broken in 1.7.7 era and stopped working in - an empty (temporary) working tree, when there are renames - involved. This has been corrected. - - * "git rev-parse" was loose in rejecting command line arguments - that do not make sense, e.g. "--default" without the required - value for that option. - - * include.path variable (or any variable that expects a path that - can use ~username expansion) in the configuration file is not a - boolean, but the code failed to check it. - - * "git diff --quiet -- pathspec1 pathspec2" sometimes did not return - correct status value. - - * Attempting to deepen a shallow repository by fetching over smart - HTTP transport failed in the protocol exchange, when no-done - extension was used. The fetching side waited for the list of - shallow boundary commits after the sending end stopped talking to - it. - - * Allow "git cmd path/", when the 'path' is where a submodule is - bound to the top-level working tree, to match 'path', despite the - extra and unnecessary trailing slash (such a slash is often - given by command line completion). diff --git a/third_party/git/Documentation/RelNotes/1.9.2.txt b/third_party/git/Documentation/RelNotes/1.9.2.txt deleted file mode 100644 index 47a34ca964..0000000000 --- a/third_party/git/Documentation/RelNotes/1.9.2.txt +++ /dev/null @@ -1,67 +0,0 @@ -Git v1.9.2 Release Notes -======================== - -Fixes since v1.9.1 ------------------- - - * Documentation and in-code comments had many instances of mistaken - use of "nor", which have been corrected. - - * "git fetch --prune", when the right-hand-side of multiple fetch - refspecs overlap (e.g. storing "refs/heads/*" to - "refs/remotes/origin/*", while storing "refs/frotz/*" to - "refs/remotes/origin/fr/*"), aggressively thought that lack of - "refs/heads/fr/otz" on the origin site meant we should remove - "refs/remotes/origin/fr/otz" from us, without checking their - "refs/frotz/otz" first. - - Note that such a configuration is inherently unsafe (think what - should happen when "refs/heads/fr/otz" does appear on the origin - site), but that is not a reason not to be extra careful. - - * "git update-ref --stdin" did not fail a request to create a ref - when the ref already existed. - - * "git diff --no-index -Mq a b" fell into an infinite loop. - - * When it is not necessary to edit a commit log message (e.g. "git - commit -m" is given a message without specifying "-e"), we used to - disable the spawning of the editor by overriding GIT_EDITOR, but - this means all the uses of the editor, other than to edit the - commit log message, are also affected. - - * "git status --porcelain --branch" showed its output with labels - "ahead/behind/gone" translated to the user's locale. - - * "git mv" that moves a submodule forgot to adjust the array that - uses to keep track of which submodules were to be moved to update - its configuration. - - * Length limit for the pathname used when removing a path in a deep - subdirectory has been removed to avoid buffer overflows. - - * The test helper lib-terminal always run an actual test_expect_* - when included, which screwed up with the use of skil-all that may - have to be done later. - - * "git index-pack" used a wrong variable to name the keep-file in an - error message when the file cannot be written or closed. - - * "rebase -i" produced a broken insn sheet when the title of a commit - happened to contain '\n' (or ended with '\c') due to a careless use - of 'echo'. - - * There were a few instances of 'git-foo' remaining in the - documentation that should have been spelled 'git foo'. - - * Serving objects from a shallow repository needs to write a - new file to hold the temporary shallow boundaries but it was not - cleaned when we exit due to die() or a signal. - - * When "git stash pop" stops after failing to apply the stash - (e.g. due to conflicting changes), the stash is not dropped. State - that explicitly in the output to let the users know. - - * The labels in "git status" output that describe the nature of - conflicts (e.g. "both deleted") were limited to 20 bytes, which was - too short for some l10n (e.g. fr). diff --git a/third_party/git/Documentation/RelNotes/1.9.3.txt b/third_party/git/Documentation/RelNotes/1.9.3.txt deleted file mode 100644 index 17b05ca7b5..0000000000 --- a/third_party/git/Documentation/RelNotes/1.9.3.txt +++ /dev/null @@ -1,21 +0,0 @@ -Git v1.9.3 Release Notes -======================== - -Fixes since v1.9.2 ------------------- - - * "git p4" dealing with changes in binary files were broken by a - change in 1.9 release. - - * The shell prompt script (in contrib/), when using the PROMPT_COMMAND - interface, used an unsafe construct when showing the branch name in - $PS1. - - * "git rebase" used a POSIX shell construct FreeBSD /bin/sh does not - work well with. - - * Some more Unicode codepoints defined in Unicode 6.3 as having - zero width have been taught to our display column counting logic. - - * Some tests used shell constructs that did not work well on - FreeBSD. diff --git a/third_party/git/Documentation/RelNotes/1.9.4.txt b/third_party/git/Documentation/RelNotes/1.9.4.txt deleted file mode 100644 index e1d1835436..0000000000 --- a/third_party/git/Documentation/RelNotes/1.9.4.txt +++ /dev/null @@ -1,16 +0,0 @@ -Git v1.9.4 Release Notes -======================== - -Fixes since v1.9.3 ------------------- - - * Commands that take pathspecs on the command line misbehaved when - the pathspec is given as an absolute pathname (which is a - practice not particularly encouraged) that points at a symbolic - link in the working tree. - - * An earlier fix to the shell prompt script (in contrib/) for using - the PROMPT_COMMAND interface did not correctly check if the extra - code path needs to trigger, causing the branch name not to appear - when 'promptvars' option is disabled in bash or PROMPT_SUBST is - unset in zsh. diff --git a/third_party/git/Documentation/RelNotes/1.9.5.txt b/third_party/git/Documentation/RelNotes/1.9.5.txt deleted file mode 100644 index 8d6ac0cf53..0000000000 --- a/third_party/git/Documentation/RelNotes/1.9.5.txt +++ /dev/null @@ -1,34 +0,0 @@ -Git v1.9.5 Release Notes -======================== - -Fixes since v1.9.4 ------------------- - - * We used to allow committing a path ".Git/config" with Git that is - running on a case sensitive filesystem, but an attempt to check out - such a path with Git that runs on a case insensitive filesystem - would have clobbered ".git/config", which is definitely not what - the user would have expected. Git now prevents you from tracking - a path with ".Git" (in any case combination) as a path component. - - * On Windows, certain path components that are different from ".git" - are mapped to ".git", e.g. "git~1/config" is treated as if it were - ".git/config". HFS+ has a similar issue, where certain unicode - codepoints are ignored, e.g. ".g\u200cit/config" is treated as if - it were ".git/config". Pathnames with these potential issues are - rejected on the affected systems. Git on systems that are not - affected by this issue (e.g. Linux) can also be configured to - reject them to ensure cross platform interoperability of the hosted - projects. - - * "git fsck" notices a tree object that records such a path that can - be confused with ".git", and with receive.fsckObjects configuration - set to true, an attempt to "git push" such a tree object will be - rejected. Such a path may not be a problem on a well behaving - filesystem but in order to protect those on HFS+ and on case - insensitive filesystems, this check is enabled on all platforms. - -A big "thanks!" for bringing this issue to us goes to our friends in -the Mercurial land, namely, Matt Mackall and Augie Fackler. - -Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.0.0.txt b/third_party/git/Documentation/RelNotes/2.0.0.txt deleted file mode 100644 index 2617372a0c..0000000000 --- a/third_party/git/Documentation/RelNotes/2.0.0.txt +++ /dev/null @@ -1,364 +0,0 @@ -Git v2.0 Release Notes -====================== - -Backward compatibility notes ----------------------------- - -When "git push [$there]" does not say what to push, we have used the -traditional "matching" semantics so far (all your branches were sent -to the remote as long as there already are branches of the same name -over there). In Git 2.0, the default is now the "simple" semantics, -which pushes: - - - only the current branch to the branch with the same name, and only - when the current branch is set to integrate with that remote - branch, if you are pushing to the same remote as you fetch from; or - - - only the current branch to the branch with the same name, if you - are pushing to a remote that is not where you usually fetch from. - -You can use the configuration variable "push.default" to change -this. If you are an old-timer who wants to keep using the -"matching" semantics, you can set the variable to "matching", for -example. Read the documentation for other possibilities. - -When "git add -u" and "git add -A" are run inside a subdirectory -without specifying which paths to add on the command line, they -operate on the entire tree for consistency with "git commit -a" and -other commands (these commands used to operate only on the current -subdirectory). Say "git add -u ." or "git add -A ." if you want to -limit the operation to the current directory. - -"git add <path>" is the same as "git add -A <path>" now, so that -"git add dir/" will notice paths you removed from the directory and -record the removal. In older versions of Git, "git add <path>" used -to ignore removals. You can say "git add --ignore-removal <path>" to -add only added or modified paths in <path>, if you really want to. - -The "-q" option to "git diff-files", which does *NOT* mean "quiet", -has been removed (it told Git to ignore deletion, which you can do -with "git diff-files --diff-filter=d"). - -"git request-pull" lost a few "heuristics" that often led to mistakes. - -The default prefix for "git svn" has changed in Git 2.0. For a long -time, "git svn" created its remote-tracking branches directly under -refs/remotes, but it now places them under refs/remotes/origin/ unless -it is told otherwise with its "--prefix" option. - - -Updates since v1.9 series -------------------------- - -UI, Workflows & Features - - * The "multi-mail" post-receive hook (in contrib/) has been updated - to a more recent version from upstream. - - * The "remote-hg/bzr" remote-helper interfaces (used to be in - contrib/) are no more. They are now maintained separately as - third-party plug-ins in their own repositories. - - * "git gc --aggressive" learned "--depth" option and - "gc.aggressiveDepth" configuration variable to allow use of a less - insane depth than the built-in default value of 250. - - * "git log" learned the "--show-linear-break" option to show where a - single strand-of-pearls is broken in its output. - - * The "rev-parse --parseopt" mechanism used by scripted Porcelains to - parse command-line options and to give help text learned to take - the argv-help (the placeholder string for an option parameter, - e.g. "key-id" in "--gpg-sign=<key-id>"). - - * The pattern to find where the function begins in C/C++ used in - "diff" and "grep -p" has been updated to improve viewing C++ - sources. - - * "git rebase" learned to interpret a lone "-" as "@{-1}", the - branch that we were previously on. - - * "git commit --cleanup=<mode>" learned a new mode, scissors. - - * "git tag --list" output can be sorted using "version sort" with - "--sort=version:refname". - - * Discard the accumulated "heuristics" to guess from which branch the - result wants to be pulled from and make sure that what the end user - specified is not second-guessed by "git request-pull", to avoid - mistakes. When you pushed out your 'master' branch to your public - repository as 'for-linus', use the new "master:for-linus" syntax to - denote the branch to be pulled. - - * "git grep" learned to behave in a way similar to native grep when - "-h" (no header) and "-c" (count) options are given. - - * "git push" via transport-helper interface has been updated to - allow forced ref updates in a way similar to the natively - supported transports. - - * The "simple" mode is the default for "git push". - - * "git add -u" and "git add -A", when run without any pathspec, is a - tree-wide operation even when run inside a subdirectory of a - working tree. - - * "git add <path>" is the same as "git add -A <path>" now. - - * "core.statinfo" configuration variable, which is a - never-advertised synonym to "core.checkstat", has been removed. - - * The "-q" option to "git diff-files", which does *NOT* mean - "quiet", has been removed (it told Git to ignore deletion, which - you can do with "git diff-files --diff-filter=d"). - - * Server operators can loosen the "tips of refs only" restriction for - the remote archive service with the uploadarchive.allowUnreachable - configuration option. - - * The progress indicators from various time-consuming commands have - been marked for i18n/l10n. - - * "git notes -C <blob>" diagnoses as an error an attempt to use an - object that is not a blob. - - * "git config" learned to read from the standard input when "-" is - given as the value to its "--file" parameter (attempting an - operation to update the configuration in the standard input is - rejected, of course). - - * Trailing whitespaces in .gitignore files, unless they are quoted - for fnmatch(3), e.g. "path\ ", are warned and ignored. Strictly - speaking, this is a backward-incompatible change, but very unlikely - to bite any sane user and adjusting should be obvious and easy. - - * Many commands that create commits, e.g. "pull" and "rebase", - learned to take the "--gpg-sign" option on the command line. - - * "git commit" can be told to always GPG sign the resulting commit - by setting the "commit.gpgsign" configuration variable to "true" - (the command-line option "--no-gpg-sign" should override it). - - * "git pull" can be told to only accept fast-forward by setting the - new "pull.ff" configuration variable. - - * "git reset" learned the "-N" option, which does not reset the index - fully for paths the index knows about but the tree-ish the command - resets to does not (these paths are kept as intend-to-add entries). - - -Performance, Internal Implementation, etc. - - * The compilation options to port to AIX and to MSVC have been - updated. - - * We started using wildmatch() in place of fnmatch(3) a few releases - ago; complete the process and stop using fnmatch(3). - - * Uses of curl's "multi" interface and "easy" interface do not mix - well when we attempt to reuse outgoing connections. Teach the RPC - over HTTP code, used in the smart HTTP transport, not to use the - "easy" interface. - - * The bitmap-index feature from JGit has been ported, which should - significantly improve performance when serving objects from a - repository that uses it. - - * The way "git log --cc" shows a combined diff against multiple - parents has been optimized. - - * The prefixcmp() and suffixcmp() functions are gone. Use - starts_with() and ends_with(), and also consider if skip_prefix() - suits your needs better when using the former. - - -Also contains various documentation updates and code clean-ups. Many -of them came from flurry of activities as GSoC candidate microproject -exercises. - - -Fixes since v1.9 series ------------------------ - -Unless otherwise noted, all the fixes since v1.9 in the maintenance -track are contained in this release (see the maintenance releases' -notes for details). - - * "git p4" was broken in 1.9 release to deal with changes in binary - files. - (merge 749b668 cl/p4-use-diff-tree later to maint). - - * The shell prompt script (in contrib/), when using the PROMPT_COMMAND - interface, used an unsafe construct when showing the branch name in - $PS1. - (merge 1e4119c8 rh/prompt-pcmode-avoid-eval-on-refname later to maint). - - * "git rebase" used a POSIX shell construct FreeBSD's /bin/sh does not - work well with. - (merge 8cd6596 km/avoid-non-function-return-in-rebase later to maint). - - * zsh prompt (in contrib/) leaked unnecessary error messages. - - * Bash completion (in contrib/) did not complete the refs and remotes - correctly given "git pu<TAB>" when "pu" is aliased to "push". - - * Some more Unicode code points, defined in Unicode 6.3 as having zero - width, have been taught to our display column counting logic. - (merge d813ab9 tb/unicode-6.3-zero-width later to maint). - - * Some tests used shell constructs that did not work well on FreeBSD - (merge ff7a1c6 km/avoid-bs-in-shell-glob later to maint). - (merge 00764ca km/avoid-cp-a later to maint). - - * "git update-ref --stdin" did not fail a request to create a ref - when the ref already existed. - (merge b9d56b5 mh/update-ref-batch-create-fix later to maint). - - * "git diff --no-index -Mq a b" fell into an infinite loop. - (merge ad1c3fb jc/fix-diff-no-index-diff-opt-parse later to maint). - - * "git fetch --prune", when the right-hand side of multiple fetch - refspecs overlap (e.g. storing "refs/heads/*" to - "refs/remotes/origin/*", while storing "refs/frotz/*" to - "refs/remotes/origin/fr/*"), aggressively thought that lack of - "refs/heads/fr/otz" on the origin site meant we should remove - "refs/remotes/origin/fr/otz" from us, without checking their - "refs/frotz/otz" first. - - Note that such a configuration is inherently unsafe (think what - should happen when "refs/heads/fr/otz" does appear on the origin - site), but that is not a reason not to be extra careful. - (merge e6f6371 cn/fetch-prune-overlapping-destination later to maint). - - * "git status --porcelain --branch" showed its output with labels - "ahead/behind/gone" translated to the user's locale. - (merge 7a76c28 mm/status-porcelain-format-i18n-fix later to maint). - - * A stray environment variable $prefix could have leaked into and - affected the behaviour of the "subtree" script (in contrib/). - - * When it is not necessary to edit a commit log message (e.g. "git - commit -m" is given a message without specifying "-e"), we used to - disable the spawning of the editor by overriding GIT_EDITOR, but - this means all the uses of the editor, other than to edit the - commit log message, are also affected. - (merge b549be0 bp/commit-p-editor later to maint). - - * "git mv" that moves a submodule forgot to adjust the array that - uses to keep track of which submodules were to be moved to update - its configuration. - (merge fb8a4e8 jk/mv-submodules-fix later to maint). - - * Length limit for the pathname used when removing a path in a deep - subdirectory has been removed to avoid buffer overflows. - (merge 2f29e0c mh/remove-subtree-long-pathname-fix later to maint). - - * The test helper lib-terminal always run an actual test_expect_* - when included, which screwed up with the use of skil-all that may - have to be done later. - (merge 7e27173 jk/lib-terminal-lazy later to maint). - - * "git index-pack" used a wrong variable to name the keep-file in an - error message when the file cannot be written or closed. - (merge de983a0 nd/index-pack-error-message later to maint). - - * "rebase -i" produced a broken insn sheet when the title of a commit - happened to contain '\n' (or ended with '\c') due to a careless use - of 'echo'. - (merge cb1aefd us/printf-not-echo later to maint). - - * There were a few instances of 'git-foo' remaining in the - documentation that should have been spelled 'git foo'. - (merge 3c3e6f5 rr/doc-merge-strategies later to maint). - - * Serving objects from a shallow repository needs to write a - new file to hold the temporary shallow boundaries, but it was not - cleaned when we exit due to die() or a signal. - (merge 7839632 jk/shallow-update-fix later to maint). - - * When "git stash pop" stops after failing to apply the stash - (e.g. due to conflicting changes), the stash is not dropped. State - that explicitly in the output to let the users know. - (merge 2d4c993 jc/stash-pop-not-popped later to maint). - - * The labels in "git status" output that describe the nature of - conflicts (e.g. "both deleted") were limited to 20 bytes, which was - too short for some l10n (e.g. fr). - (merge c7cb333 jn/wt-status later to maint). - - * "git clean -d pathspec" did not use the given pathspec correctly - and ended up cleaning too much. - (merge 1f2e108 jk/clean-d-pathspec later to maint). - - * "git difftool" misbehaved when the repository is bound to the - working tree with the ".git file" mechanism, where a textual file - ".git" tells us where it is. - (merge fcfec8b da/difftool-git-files later to maint). - - * "git push" did not pay attention to "branch.*.pushremote" if it is - defined earlier than "remote.pushdefault"; the order of these two - variables in the configuration file should not matter, but it did - by mistake. - (merge 98b406f jk/remote-pushremote-config-reading later to maint). - - * Code paths that parse timestamps in commit objects have been - tightened. - (merge f80d1f9 jk/commit-dates-parsing-fix later to maint). - - * "git diff --external-diff" incorrectly fed the submodule directory - in the working tree to the external diff driver when it knew that it - is the same as one of the versions being compared. - (merge aba4727 tr/diff-submodule-no-reuse-worktree later to maint). - - * "git reset" needs to refresh the index when working in a working - tree (it can also be used to match the index to the HEAD in an - otherwise bare repository), but it failed to set up the working - tree properly, causing GIT_WORK_TREE to be ignored. - (merge b7756d4 nd/reset-setup-worktree later to maint). - - * "git check-attr" when working on a repository with a working tree - did not work well when the working tree was specified via the - "--work-tree" (and obviously with "--git-dir") option. - (merge cdbf623 jc/check-attr-honor-working-tree later to maint). - - * "merge-recursive" was broken in 1.7.7 era and stopped working in - an empty (temporary) working tree, when there are renames - involved. This has been corrected. - (merge 6e2068a bk/refresh-missing-ok-in-merge-recursive later to maint.) - - * "git rev-parse" was loose in rejecting command-line arguments - that do not make sense, e.g. "--default" without the required - value for that option. - (merge a43219f ds/rev-parse-required-args later to maint.) - - * "include.path" variable (or any variable that expects a path that - can use ~username expansion) in the configuration file is not a - boolean, but the code failed to check it. - (merge 67beb60 jk/config-path-include-fix later to maint.) - - * Commands that take pathspecs on the command line misbehaved when - the pathspec is given as an absolute pathname (which is a - practice not particularly encouraged) that points at a symbolic - link in the working tree. - (merge 6127ff6 mw/symlinks later to maint.) - - * "git diff --quiet -- pathspec1 pathspec2" sometimes did not return - the correct status value. - (merge f34b205 nd/diff-quiet-stat-dirty later to maint.) - - * Attempting to deepen a shallow repository by fetching over smart - HTTP transport failed in the protocol exchange, when the no-done - extension was used. The fetching side waited for the list of - shallow boundary commits after the sending side stopped talking to - it. - (merge 0232852 nd/http-fetch-shallow-fix later to maint.) - - * Allow "git cmd path/", when the 'path' is where a submodule is - bound to the top-level working tree, to match 'path', despite the - extra and unnecessary trailing slash (such a slash is often - given by command-line completion). - (merge 2e70c01 nd/submodule-pathspec-ending-with-slash later to maint.) - - * Documentation and in-code comments had many instances of mistaken - use of "nor", which have been corrected. - (merge 235e8d5 jl/nor-or-nand-and later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.0.1.txt b/third_party/git/Documentation/RelNotes/2.0.1.txt deleted file mode 100644 index ce5579db3e..0000000000 --- a/third_party/git/Documentation/RelNotes/2.0.1.txt +++ /dev/null @@ -1,115 +0,0 @@ -Git v2.0.1 Release Notes -======================== - - * We used to unconditionally disable the pager in the pager process - we spawn to feed out output, but that prevented people who want to - run "less" within "less" from doing so. - - * Tools that read diagnostic output in our standard error stream do - not want to see terminal control sequence (e.g. erase-to-eol). - Detect them by checking if the standard error stream is connected - to a tty. - * Reworded the error message given upon a failure to open an existing - loose object file due to e.g. permission issues; it was reported as - the object being corrupt, but that is not quite true. - - * "git log -2master" is a common typo that shows two commits starting - from whichever random branch that is not 'master' that happens to - be checked out currently. - - * The "%<(10,trunc)%s" pretty format specifier in the log family of - commands is used to truncate the string to a given length (e.g. 10 - in the example) with padding to column-align the output, but did - not take into account that number of bytes and number of display - columns are different. - - * The "mailmap.file" configuration option did not support the tilde - expansion (i.e. ~user/path and ~/path). - - * The completion scripts (in contrib/) did not know about quite a few - options that are common between "git merge" and "git pull", and a - couple of options unique to "git merge". - - * "--ignore-space-change" option of "git apply" ignored the spaces - at the beginning of line too aggressively, which is inconsistent - with the option of the same name "diff" and "git diff" have. - - * "git blame" miscounted number of columns needed to show localized - timestamps, resulting in jaggy left-side-edge of the source code - lines in its output. - - * "git blame" assigned the blame to the copy in the working-tree if - the repository is set to core.autocrlf=input and the file used CRLF - line endings. - - * "git commit --allow-empty-message -C $commit" did not work when the - commit did not have any log message. - - * "git diff --find-copies-harder" sometimes pretended as if the mode - bits have changed for paths that are marked with assume-unchanged - bit. - - * "git format-patch" did not enforce the rule that the "--follow" - option from the log/diff family of commands must be used with - exactly one pathspec. - - * "git gc --auto" was recently changed to run in the background to - give control back early to the end-user sitting in front of the - terminal, but it forgot that housekeeping involving reflogs should - be done without other processes competing for accesses to the refs. - - * "git grep -O" to show the lines that hit in the pager did not work - well with case insensitive search. We now spawn "less" with its - "-I" option when it is used as the pager (which is the default). - - * We used to disable threaded "git index-pack" on platforms without - thread-safe pread(); use a different workaround for such - platforms to allow threaded "git index-pack". - - * The error reporting from "git index-pack" has been improved to - distinguish missing objects from type errors. - - * "git mailinfo" used to read beyond the end of header string while - parsing an incoming e-mail message to extract the patch. - - * On a case insensitive filesystem, merge-recursive incorrectly - deleted the file that is to be renamed to a name that is the same - except for case differences. - - * "git pack-objects" unnecessarily copied the previous contents when - extending the hashtable, even though it will populate the table - from scratch anyway. - - * "git rerere forget" did not work well when merge.conflictstyle - was set to a non-default value. - - * "git remote rm" and "git remote prune" can involve removing many - refs at once, which is not a very efficient thing to do when very - many refs exist in the packed-refs file. - - * "git log --exclude=<glob> --all | git shortlog" worked as expected, - but "git shortlog --exclude=<glob> --all", which is supposed to be - identical to the above pipeline, was not accepted at the command - line argument parser level. - - * The autostash mode of "git rebase -i" did not restore the dirty - working tree state if the user aborted the interactive rebase by - emptying the insn sheet. - - * "git show -s" (i.e. show log message only) used to incorrectly emit - an extra blank line after a merge commit. - - * "git status", even though it is a read-only operation, tries to - update the index with refreshed lstat(2) info to optimize future - accesses to the working tree opportunistically, but this could - race with a "read-write" operation that modify the index while it - is running. Detect such a race and avoid overwriting the index. - - * "git status" (and "git commit") behaved as if changes in a modified - submodule are not there if submodule.*.ignore configuration is set, - which was misleading. The configuration is only to unclutter diff - output during the course of development, and should not to hide - changes in the "status" output to cause the users forget to commit - them. - - * The mode to run tests with HTTP server tests disabled was broken. diff --git a/third_party/git/Documentation/RelNotes/2.0.2.txt b/third_party/git/Documentation/RelNotes/2.0.2.txt deleted file mode 100644 index 8e8321b2ef..0000000000 --- a/third_party/git/Documentation/RelNotes/2.0.2.txt +++ /dev/null @@ -1,32 +0,0 @@ -Git v2.0.2 Release Notes -======================== - - * Documentation for "git submodule sync" forgot to say that the subcommand - can take the "--recursive" option. - - * Mishandling of patterns in .gitignore that has trailing SPs quoted - with backslashes (e.g. ones that end with "\ ") have been - corrected. - - * Recent updates to "git repack" started to duplicate objects that - are in packfiles marked with .keep flag into the new packfile by - mistake. - - * "git clone -b brefs/tags/bar" would have mistakenly thought we were - following a single tag, even though it was a name of the branch, - because it incorrectly used strstr(). - - * "%G" (nothing after G) is an invalid pretty format specifier, but - the parser did not notice it as garbage. - - * Code to avoid adding the same alternate object store twice was - subtly broken for a long time, but nobody seems to have noticed. - - * A handful of code paths had to read the commit object more than - once when showing header fields that are usually not parsed. The - internal data structure to keep track of the contents of the commit - object has been updated to reduce the need for this double-reading, - and to allow the caller find the length of the object. - - * During "git rebase --merge", a conflicted patch could not be - skipped with "--skip" if the next one also conflicted. diff --git a/third_party/git/Documentation/RelNotes/2.0.3.txt b/third_party/git/Documentation/RelNotes/2.0.3.txt deleted file mode 100644 index 4047b46bbe..0000000000 --- a/third_party/git/Documentation/RelNotes/2.0.3.txt +++ /dev/null @@ -1,17 +0,0 @@ -Git v2.0.3 Release Notes -======================== - - * An ancient rewrite passed a wrong pointer to a curl library - function in a rarely used code path. - - * "filter-branch" left an empty single-parent commit that results when - all parents of a merge commit gets mapped to the same commit, even - under "--prune-empty". - - * "log --show-signature" incorrectly decided the color to paint a - mergetag that was and was not correctly validated. - - * "log --show-signature" did not pay attention to "--graph" option. - -Also a lot of fixes to the tests and some updates to the docs are -included. diff --git a/third_party/git/Documentation/RelNotes/2.0.4.txt b/third_party/git/Documentation/RelNotes/2.0.4.txt deleted file mode 100644 index 7e340921a2..0000000000 --- a/third_party/git/Documentation/RelNotes/2.0.4.txt +++ /dev/null @@ -1,5 +0,0 @@ -Git v2.0.4 Release Notes -======================== - - * An earlier update to v2.0.2 broken output from "git diff-tree", - which is fixed in this release. diff --git a/third_party/git/Documentation/RelNotes/2.0.5.txt b/third_party/git/Documentation/RelNotes/2.0.5.txt deleted file mode 100644 index 3a16f697e8..0000000000 --- a/third_party/git/Documentation/RelNotes/2.0.5.txt +++ /dev/null @@ -1,34 +0,0 @@ -Git v2.0.5 Release Notes -======================== - -Fixes since v2.0.4 ------------------- - - * We used to allow committing a path ".Git/config" with Git that is - running on a case sensitive filesystem, but an attempt to check out - such a path with Git that runs on a case insensitive filesystem - would have clobbered ".git/config", which is definitely not what - the user would have expected. Git now prevents you from tracking - a path with ".Git" (in any case combination) as a path component. - - * On Windows, certain path components that are different from ".git" - are mapped to ".git", e.g. "git~1/config" is treated as if it were - ".git/config". HFS+ has a similar issue, where certain unicode - codepoints are ignored, e.g. ".g\u200cit/config" is treated as if - it were ".git/config". Pathnames with these potential issues are - rejected on the affected systems. Git on systems that are not - affected by this issue (e.g. Linux) can also be configured to - reject them to ensure cross platform interoperability of the hosted - projects. - - * "git fsck" notices a tree object that records such a path that can - be confused with ".git", and with receive.fsckObjects configuration - set to true, an attempt to "git push" such a tree object will be - rejected. Such a path may not be a problem on a well behaving - filesystem but in order to protect those on HFS+ and on case - insensitive filesystems, this check is enabled on all platforms. - -A big "thanks!" for bringing this issue to us goes to our friends in -the Mercurial land, namely, Matt Mackall and Augie Fackler. - -Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.1.0.txt b/third_party/git/Documentation/RelNotes/2.1.0.txt deleted file mode 100644 index ae4753728e..0000000000 --- a/third_party/git/Documentation/RelNotes/2.1.0.txt +++ /dev/null @@ -1,391 +0,0 @@ -Git v2.1 Release Notes -====================== - -Backward compatibility notes ----------------------------- - - * The default value we give to the environment variable LESS has been - changed from "FRSX" to "FRX", losing "S" (chop long lines instead - of wrapping). Existing users who prefer not to see line-wrapped - output may want to set - - $ git config core.pager "less -S" - - to restore the traditional behaviour. It is expected that people - find output from most subcommands easier to read with the new - default, except for "blame" which tends to produce really long - lines. To override the new default only for "git blame", you can - do this: - - $ git config pager.blame "less -S" - - * A few disused directories in contrib/ have been retired. - - -Updates since v2.0 ------------------- - -UI, Workflows & Features - - * Since the very beginning of Git, we gave the LESS environment a - default value "FRSX" when we spawn "less" as the pager. "S" (chop - long lines instead of wrapping) has been removed from this default - set of options, because it is more or less a personal taste thing, - as opposed to the others that have good justifications (i.e. "R" is - very much justified because many kinds of output we produce are - colored and "FX" is justified because output we produce is often - shorter than a page). - - * The logic and data used to compute the display width needed for - UTF-8 strings have been updated to match Unicode 7.0 better. - - * HTTP-based transports learned to better propagate the error messages from - the webserver to the client coming over the HTTP transport. - - * The completion script for bash (in contrib/) has been updated to - better handle aliases that define a complex sequence of commands. - - * The "core.preloadindex" configuration variable is enabled by default, - allowing modern platforms to take advantage of their - multiple cores. - - * "git clone" applies the "if cloning from a local disk, physically - copy the repository using hardlinks, unless otherwise told not to with - --no-local" optimization when the url.*.insteadOf mechanism rewrites a - remote-repository "git clone $URL" into a - clone from a local disk. - - * "git commit --date=<date>" option learned more - timestamp formats, including "--date=now". - - * The `core.commentChar` configuration variable is used to specify a - custom comment character (other than the default "#") for - the commit message editor. This can be set to `auto` to attempt to - choose a different character that does not conflict with any that - already starts a line in the message being edited, for cases like - "git commit --amend". - - * "git format-patch" learned --signature-file=<file> to add the contents - of a file as a signature to the mail message it produces. - - * "git grep" learned the grep.fullname configuration variable to force - "--full-name" to be the default. This may cause regressions for - scripted users who do not expect this new behaviour. - - * "git imap-send" learned to ask the credential helper for auth - material. - - * "git log" and friends now understand the value "auto" for the - "log.decorate" configuration variable to enable the "--decorate" - option automatically when the output is sent to tty. - - * "git merge" without an argument, even when there is an upstream - defined for the current branch, refused to run until - merge.defaultToUpstream is set to true. Flip the default of that - configuration variable to true. - - * "git mergetool" learned to drive the vimdiff3 backend. - - * mergetool.prompt used to default to 'true', always asking "do you - really want to run the tool on this path?". The default has been - changed to 'false'. However, the prompt will still appear if - mergetool used its autodetection system to guess which tool to use. - Users who explicitly specify or configure a tool will no longer see - the prompt by default. - - Strictly speaking, this is a backward incompatible change and - users need to explicitly set the variable to 'true' if they want - to be prompted to confirm running the tool on each path. - - * "git replace" learned the "--edit" subcommand to create a - replacement by editing an existing object. - - * "git replace" learned a "--graft" option to rewrite the parents of a - commit. - - * "git send-email" learned "--to-cover" and "--cc-cover" options, to - tell it to copy To: and Cc: headers found in the first input file - when emitting later input files. - - * "git svn" learned to cope with malformed timestamps with only one - digit in the hour part, e.g. 2014-01-07T5:01:02.048176Z, emitted - by some broken subversion server implementations. - - * "git tag" when editing the tag message shows the name of the tag - being edited as a comment in the editor. - - * "git tag" learned to pay attention to "tag.sort" configuration, to - be used as the default sort order when no --sort=<value> option - is given. - - * A new "git verify-commit" command, to check GPG signatures in signed - commits, in a way similar to "git verify-tag" is used to check - signed tags, was added. - - -Performance, Internal Implementation, etc. - - * Build procedure for 'subtree' (in contrib/) has been cleaned up. - - * Support for the profile-feedback build, which has - bit-rotted for quite a while, has been updated. - - * An experimental format to use two files (the base file and - incremental changes relative to it) to represent the index has been - introduced; this may reduce I/O cost of rewriting a large index - when only small part of the working tree changes. - - * Effort to shrink the size of patches Windows folks maintain on top - by upstreaming them continues. More tests that are not applicable - to the Windows environment are identified and either skipped or - made more portable. - - * Eradication of "test $condition -a $condition" from our scripts - continues. - - * The `core.deltabasecachelimit` used to default to 16 MiB , but this - proved to be too small, and has been bumped to 96 MiB. - - * "git blame" has been optimized greatly by reorganising the data - structure that is used to keep track of the work to be done. - - * "git diff" that compares 3-or-more trees (e.g. parents and the - result of a merge) has been optimized. - - * The API to update/delete references are being converted to handle - updates to multiple references in a transactional way. As an - example, "update-ref --stdin [-z]" has been updated to use this - API. - - * skip_prefix() and strip_suffix() API functions are used a lot more - widely throughout the codebase now. - - * Parts of the test scripts can be skipped by using a range notation, - e.g. "sh t1234-test.sh --run='1-4 6 8-'" to omit test piece 5 and 7 - and run everything else. - - -Also contains various documentation updates and code clean-ups. - - -Fixes since v2.0 ----------------- - -Unless otherwise noted, all the fixes since v2.0 in the maintenance -track are contained in this release (see the maintenance releases' -notes for details). - - * We used to unconditionally disable the pager in the pager process - we spawn to feed out output, but that prevented people who want to - run "less" within "less" from doing so. - (merge c0459ca je/pager-do-not-recurse later to maint). - - * Tools that read diagnostic output in our standard error stream do - not want to see terminal control sequence (e.g. erase-to-eol). - Detect them by checking if the standard error stream is connected - to a tty. - (merge 38de156 mn/sideband-no-ansi later to maint). - - * Mishandling of patterns in .gitignore that have trailing SPs quoted - with backslashes (e.g. ones that end with "\ ") has been - corrected. - (merge 97c1364be6b pb/trim-trailing-spaces later to maint). - - * Reworded the error message given upon a failure to open an existing - loose object file due to e.g. permission issues; it was reported as - the object being corrupt, but that is not quite true. - (merge d6c8a05 jk/report-fail-to-read-objects-better later to maint). - - * "git log -2master" is a common typo that shows two commits starting - from whichever random branch that is not 'master' that happens to - be checked out currently. - (merge e3fa568 jc/revision-dash-count-parsing later to maint). - - * Code to avoid adding the same alternate object store twice was - subtly broken for a long time, but nobody seems to have noticed. - (merge 80b4785 rs/fix-alt-odb-path-comparison later to maint). - (merge 539e750 ek/alt-odb-entry-fix later to maint). - - * The "%<(10,trunc)%s" pretty format specifier in the log family of - commands is used to truncate the string to a given length (e.g. 10 - in the example) with padding to column-align the output, but did - not take into account that number of bytes and number of display - columns are different. - (merge 7d50987 as/pretty-truncate later to maint). - - * "%G" (nothing after G) is an invalid pretty format specifier, but - the parser did not notice it as garbage. - (merge 958b2eb jk/pretty-G-format-fixes later to maint). - - * A handful of code paths had to read the commit object more than - once when showing header fields that are usually not parsed. The - internal data structure to keep track of the contents of the commit - object has been updated to reduce the need for this double-reading, - and to allow the caller find the length of the object. - (merge 218aa3a jk/commit-buffer-length later to maint). - - * The "mailmap.file" configuration option did not support tilde - expansion (i.e. ~user/path and ~/path). - (merge 9352fd5 ow/config-mailmap-pathname later to maint). - - * The completion scripts (in contrib/) did not know about quite a few - options that are common between "git merge" and "git pull", and a - couple of options unique to "git merge". - (merge 8fee872 jk/complete-merge-pull later to maint). - - * The unix-domain socket used by the sample credential cache daemon - tried to unlink an existing stale one at a wrong path, if the path - to the socket was given as an overlong path that does not fit in - the sun_path member of the sockaddr_un structure. - (merge 2869b3e rs/fix-unlink-unix-socket later to maint). - - * An ancient rewrite passed a wrong pointer to a curl library - function in a rarely used code path. - (merge 479eaa8 ah/fix-http-push later to maint). - - * "--ignore-space-change" option of "git apply" ignored the spaces - at the beginning of lines too aggressively, which is inconsistent - with the option of the same name that "diff" and "git diff" have. - (merge 14d3bb4 jc/apply-ignore-whitespace later to maint). - - * "git blame" miscounted the number of columns needed to show localized - timestamps, resulting in a jaggy left-side-edge for the source code - lines in its output. - (merge dd75553 jx/blame-align-relative-time later to maint). - - * "git blame" assigned the blame to the copy in the working-tree if - the repository is set to core.autocrlf=input and the file used CRLF - line endings. - (merge 4d4813a bc/blame-crlf-test later to maint). - - * "git clone -b brefs/tags/bar" would have mistakenly thought we were - following a single tag, even though it was a name of the branch, - because it incorrectly used strstr(). - (merge 60a5f5f jc/fix-clone-single-starting-at-a-tag later to maint). - - * "git commit --allow-empty-message -C $commit" did not work when the - commit did not have any log message. - (merge 076cbd6 jk/commit-C-pick-empty later to maint). - - * "git diff --find-copies-harder" sometimes pretended as if the mode - bits have changed for paths that are marked with the assume-unchanged - bit. - (merge 5304810 jk/diff-files-assume-unchanged later to maint). - - * "filter-branch" left an empty single-parent commit that results when - all parents of a merge commit get mapped to the same commit, even - under "--prune-empty". - (merge 79bc4ef cb/filter-branch-prune-empty-degenerate-merges later to maint). - - * "git format-patch" did not enforce the rule that the "--follow" - option from the log/diff family of commands must be used with - exactly one pathspec. - (merge dd63f16 jk/diff-follow-must-take-one-pathspec later to maint). - - * "git gc --auto" was recently changed to run in the background to - give control back early to the end-user sitting in front of the - terminal, but it forgot that housekeeping involving reflogs should - be done without other processes competing for accesses to the refs. - (merge 62aad18 nd/daemonize-gc later to maint). - - * "git grep -O" to show the lines that hit in the pager did not work - well with case insensitive search. We now spawn "less" with its - "-I" option when it is used as the pager (which is the default). - (merge f7febbe sk/spawn-less-case-insensitively-from-grep-O-i later to maint). - - * We used to disable threaded "git index-pack" on platforms without - thread-safe pread(); use a different workaround for such - platforms to allow threaded "git index-pack". - (merge 3953949 nd/index-pack-one-fd-per-thread later to maint). - - * The error reporting from "git index-pack" has been improved to - distinguish missing objects from type errors. - (merge 77583e7 jk/index-pack-report-missing later to maint). - - * "log --show-signature" incorrectly decided the color to paint a - mergetag that was and was not correctly validated. - (merge 42c55ce mg/fix-log-mergetag-color later to maint). - - * "log --show-signature" did not pay attention to the "--graph" option. - (merge cf3983d zk/log-graph-showsig later to maint). - - * "git mailinfo" used to read beyond the ends of header strings while - parsing an incoming e-mail message to extract the patch. - (merge b1a013d rs/mailinfo-header-cmp later to maint). - - * On a case insensitive filesystem, merge-recursive incorrectly - deleted the file that is to be renamed to a name that is the same - except for case differences. - (merge baa37bf dt/merge-recursive-case-insensitive later to maint). - - * Merging changes into a file that ends in an incomplete line made the - last line into a complete one, even when the other branch did not - change anything around the end of file. - (merge ba31180 mk/merge-incomplete-files later to maint). - - * "git pack-objects" unnecessarily copied the previous contents when - extending the hashtable, even though it will populate the table - from scratch anyway. - (merge fb79947 rs/pack-objects-no-unnecessary-realloc later to maint). - - * Recent updates to "git repack" started to duplicate objects that - are in packfiles marked with the .keep flag into the new packfile by - mistake. - (merge d078d85 jk/repack-pack-keep-objects later to maint). - - * "git rerere forget" did not work well when merge.conflictstyle - was set to a non-default value. - (merge de3d8bb fc/rerere-conflict-style later to maint). - - * "git remote rm" and "git remote prune" can involve removing many - refs at once, which is not a very efficient thing to do when very - many refs exist in the packed-refs file. - (merge e6bea66 jl/remote-rm-prune later to maint). - - * "git log --exclude=<glob> --all | git shortlog" worked as expected, - but "git shortlog --exclude=<glob> --all", which is supposed to be - identical to the above pipeline, was not accepted at the command - line argument parser level. - (merge eb07774 jc/shortlog-ref-exclude later to maint). - - * The autostash mode of "git rebase -i" did not restore the dirty - working tree state if the user aborted the interactive rebase by - emptying the insn sheet. - (merge ddb5432 rr/rebase-autostash-fix later to maint). - - * "git rebase --fork-point" did not filter out patch-identical - commits correctly. - - * During "git rebase --merge", a conflicted patch could not be - skipped with "--skip" if the next one also conflicted. - (merge 95104c7 bc/fix-rebase-merge-skip later to maint). - - * "git show -s" (i.e. show log message only) used to incorrectly emit - an extra blank line after a merge commit. - (merge ad2f725 mk/show-s-no-extra-blank-line-for-merges later to maint). - - * "git status", even though it is a read-only operation, tries to - update the index with refreshed lstat(2) info to optimize future - accesses to the working tree opportunistically, but this could - race with a "read-write" operation that modifies the index while it - is running. Detect such a race and avoid overwriting the index. - (merge 426ddee ym/fix-opportunistic-index-update-race later to maint). - - * "git status" (and "git commit") behaved as if changes in a modified - submodule are not there if submodule.*.ignore configuration is set, - which was misleading. The configuration is only to unclutter diff - output during the course of development, and not to hide - changes in the "status" output to cause the users forget to commit - them. - (merge c215d3d jl/status-added-submodule-is-never-ignored later to maint). - - * Documentation for "git submodule sync" forgot to say that the subcommand - can take the "--recursive" option. - (merge 9393ae7 mc/doc-submodule-sync-recurse later to maint). - - * "git update-index --cacheinfo" in 2.0 release crashed on a - malformed command line. - (merge c8e1ee4 jc/rev-parse-argh-dashed-multi-words later to maint). - - * The mode to run tests with HTTP server tests disabled was broken. - (merge afa53fe na/no-http-test-in-the-middle later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.1.1.txt b/third_party/git/Documentation/RelNotes/2.1.1.txt deleted file mode 100644 index 830fc3cc6d..0000000000 --- a/third_party/git/Documentation/RelNotes/2.1.1.txt +++ /dev/null @@ -1,44 +0,0 @@ -Git v2.1.1 Release Notes -======================== - - * Git 2.0 had a regression where "git fetch" into a shallowly - cloned repository from a repository with bitmap object index - enabled did not work correctly. This has been corrected. - - * Git 2.0 had a regression which broke (rarely used) "git diff-tree - -t". This has been corrected. - - * "git log --pretty/format=" with an empty format string did not - mean the more obvious "No output whatsoever" but "Use default - format", which was counterintuitive. Now it means "nothing shown - for the log message part". - - * "git -c section.var command" and "git -c section.var= command" - should pass the configuration differently (the former should be a - boolean true, the latter should be an empty string), but they - didn't work that way. Now it does. - - * Applying a patch not generated by Git in a subdirectory used to - check the whitespace breakage using the attributes for incorrect - paths. Also whitespace checks were performed even for paths - excluded via "git apply --exclude=<path>" mechanism. - - * "git bundle create" with date-range specification were meant to - exclude tags outside the range, but it did not work correctly. - - * "git add x" where x that used to be a directory has become a - symbolic link to a directory misbehaved. - - * The prompt script checked $GIT_DIR/ref/stash file to see if there - is a stash, which was a no-no. - - * "git checkout -m" did not switch to another branch while carrying - the local changes forward when a path was deleted from the index. - - * With sufficiently long refnames, fast-import could have overflown - an on-stack buffer. - - * After "pack-refs --prune" packed refs at the top-level, it failed - to prune them. - - * "git gc --auto" triggered from "git fetch --quiet" was not quiet. diff --git a/third_party/git/Documentation/RelNotes/2.1.2.txt b/third_party/git/Documentation/RelNotes/2.1.2.txt deleted file mode 100644 index abc3b8928a..0000000000 --- a/third_party/git/Documentation/RelNotes/2.1.2.txt +++ /dev/null @@ -1,20 +0,0 @@ -Git v2.1.2 Release Notes -======================== - - * "git push" over HTTP transport had an artificial limit on number of - refs that can be pushed imposed by the command line length. - - * When receiving an invalid pack stream that records the same object - twice, multiple threads got confused due to a race. - - * An attempt to remove the entire tree in the "git fast-import" input - stream caused it to misbehave. - - * Reachability check (used in "git prune" and friends) did not add a - detached HEAD as a starting point to traverse objects still in use. - - * "git config --add section.var val" used to lose existing - section.var whose value was an empty string. - - * "git fsck" failed to report that it found corrupt objects via its - exit status in some cases. diff --git a/third_party/git/Documentation/RelNotes/2.1.3.txt b/third_party/git/Documentation/RelNotes/2.1.3.txt deleted file mode 100644 index acc9ebb886..0000000000 --- a/third_party/git/Documentation/RelNotes/2.1.3.txt +++ /dev/null @@ -1,26 +0,0 @@ -Git v2.1.3 Release Notes -======================== - - * Some MUAs mangled a line in a message that begins with "From " to - ">From " when writing to a mailbox file and feeding such an input to - "git am" used to lose such a line. - - * "git daemon" (with NO_IPV6 build configuration) used to incorrectly - use the hostname even when gethostbyname() reported that the given - hostname is not found. - - * Newer versions of 'meld' breaks the auto-detection we use to see if - they are new enough to support the `--output` option. - - * "git pack-objects" forgot to disable the codepath to generate - object recheability bitmap when it needs to split the resulting - pack. - - * "gitweb" used deprecated CGI::startfrom, which was removed from - CGI.pm as of 4.04; use CGI::start_from instead. - - * "git log" documentation had an example section marked up not - quite correctly, which passed AsciiDoc but failed with - AsciiDoctor. - -Also contains some documentation updates. diff --git a/third_party/git/Documentation/RelNotes/2.1.4.txt b/third_party/git/Documentation/RelNotes/2.1.4.txt deleted file mode 100644 index d16e5f041f..0000000000 --- a/third_party/git/Documentation/RelNotes/2.1.4.txt +++ /dev/null @@ -1,34 +0,0 @@ -Git v2.1.4 Release Notes -======================== - -Fixes since v2.1.3 ------------------- - - * We used to allow committing a path ".Git/config" with Git that is - running on a case sensitive filesystem, but an attempt to check out - such a path with Git that runs on a case insensitive filesystem - would have clobbered ".git/config", which is definitely not what - the user would have expected. Git now prevents you from tracking - a path with ".Git" (in any case combination) as a path component. - - * On Windows, certain path components that are different from ".git" - are mapped to ".git", e.g. "git~1/config" is treated as if it were - ".git/config". HFS+ has a similar issue, where certain unicode - codepoints are ignored, e.g. ".g\u200cit/config" is treated as if - it were ".git/config". Pathnames with these potential issues are - rejected on the affected systems. Git on systems that are not - affected by this issue (e.g. Linux) can also be configured to - reject them to ensure cross platform interoperability of the hosted - projects. - - * "git fsck" notices a tree object that records such a path that can - be confused with ".git", and with receive.fsckObjects configuration - set to true, an attempt to "git push" such a tree object will be - rejected. Such a path may not be a problem on a well behaving - filesystem but in order to protect those on HFS+ and on case - insensitive filesystems, this check is enabled on all platforms. - -A big "thanks!" for bringing this issue to us goes to our friends in -the Mercurial land, namely, Matt Mackall and Augie Fackler. - -Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.10.0.txt b/third_party/git/Documentation/RelNotes/2.10.0.txt deleted file mode 100644 index f4da28ab66..0000000000 --- a/third_party/git/Documentation/RelNotes/2.10.0.txt +++ /dev/null @@ -1,675 +0,0 @@ -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/third_party/git/Documentation/RelNotes/2.10.1.txt b/third_party/git/Documentation/RelNotes/2.10.1.txt deleted file mode 100644 index 70462f7f7e..0000000000 --- a/third_party/git/Documentation/RelNotes/2.10.1.txt +++ /dev/null @@ -1,131 +0,0 @@ -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/third_party/git/Documentation/RelNotes/2.10.2.txt b/third_party/git/Documentation/RelNotes/2.10.2.txt deleted file mode 100644 index c4d4397023..0000000000 --- a/third_party/git/Documentation/RelNotes/2.10.2.txt +++ /dev/null @@ -1,111 +0,0 @@ -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/third_party/git/Documentation/RelNotes/2.10.3.txt b/third_party/git/Documentation/RelNotes/2.10.3.txt deleted file mode 100644 index ad6a01bf83..0000000000 --- a/third_party/git/Documentation/RelNotes/2.10.3.txt +++ /dev/null @@ -1,55 +0,0 @@ -Git v2.10.3 Release Notes -========================= - -Fixes since v2.10.2 -------------------- - - * Extract a small helper out of the function that reads the authors - script file "git am" internally uses. - This by itself is not useful until a second caller appears in the - future for "rebase -i" helper. - - * 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". - - * "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. - - * 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. - - * "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. - - * 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. - - * Fix for a racy false-positive test failure. - - * Portability update and workaround for builds on recent Mac OS X. - - * Update to the test framework made in 2.9 timeframe broke running - the tests under valgrind, which has been fixed. - - * Improve the rule to convert "unsigned char [20]" into "struct - object_id *" in contrib/coccinelle/ - - * "git-shell" rejects a request to serve a repository whose name - begins with a dash, which makes it no longer possible to get it - confused into spawning service programs like "git-upload-pack" with - an option like "--help", which in turn would spawn an interactive - pager, instead of working with the repository user asked to access - (i.e. the one whose name is "--help"). - -Also contains minor documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.10.4.txt b/third_party/git/Documentation/RelNotes/2.10.4.txt deleted file mode 100644 index ee8142ad24..0000000000 --- a/third_party/git/Documentation/RelNotes/2.10.4.txt +++ /dev/null @@ -1,4 +0,0 @@ -Git v2.10.4 Release Notes -========================= - -This release forward-ports the fix for "ssh://..." URL from Git v2.7.6 diff --git a/third_party/git/Documentation/RelNotes/2.10.5.txt b/third_party/git/Documentation/RelNotes/2.10.5.txt deleted file mode 100644 index a498fd6fdc..0000000000 --- a/third_party/git/Documentation/RelNotes/2.10.5.txt +++ /dev/null @@ -1,17 +0,0 @@ -Git v2.10.5 Release Notes -========================= - -Fixes since v2.10.4 -------------------- - - * "git cvsserver" no longer is invoked by "git daemon" by default, - as it is old and largely unmaintained. - - * Various Perl scripts did not use safe_pipe_capture() instead of - backticks, leaving them susceptible to end-user input. They have - been corrected. - -Credits go to joernchen <joernchen@phenoelit.de> for finding the -unsafe constructs in "git cvsserver", and to Jeff King at GitHub for -finding and fixing instances of the same issue in other scripts. - diff --git a/third_party/git/Documentation/RelNotes/2.11.0.txt b/third_party/git/Documentation/RelNotes/2.11.0.txt deleted file mode 100644 index b7b7dd361e..0000000000 --- a/third_party/git/Documentation/RelNotes/2.11.0.txt +++ /dev/null @@ -1,593 +0,0 @@ -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, - can perform "outside-world-to-Git" conversions (e.g. - end-of-line conversions and application of the clean-filter), and - it has had this feature on by default from very early days, its reverse - operation "git cat-file", which takes an object from the Git object - store and externalizes it for 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 intelligently selecting - which lines are common and which lines are added/deleted - when the lines before and after the changed section - are the same. A command line option (--indent-heuristic) and a - configuration variable (diff.indentHeuristic) are added to help with the - experiment to find 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 format-patch option "--rfc" is a short-hand for "--subject-prefix=RFC PATCH" - to help the participants of such projects. - - * "git add --chmod={+,-}x <pathspec>" only changed the - executable bit for paths that are either new or modified. This has - been corrected to change 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 RFC2822 header folding, "git am" fails 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 guess the language 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 http.delegation - configuration variable 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 (diff.wsErrorHighlight) to set it by default. - - * "git ls-files" learned the "--recurse-submodules" option - to get a listing of tracked files across submodules (i.e. this - only works with the "--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 by the "%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. - - * "git commit" created an empty commit when invoked with an index - consisting solely of intend-to-add paths (added with "git add -N"). - It now requires the "--allow-empty" option to create such a commit. - The same logic prevented "git status" from showing such paths as "new files" in the - "Changes not staged for commit" section. - - * The smudge/clean filter API spawns an external process - to filter the contents of 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 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). - - * Lift 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 advertisements - 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 a 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 stores 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" expire them. 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 a .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 teach it that people in - the real world write all sorts of cruft 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 to 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 and - 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 right - 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 the "-- " 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 commits - (i.e. fast-forwards), it still insisted on having 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 - a 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 the 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 the 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 the 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 that they are reading 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 has 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 the for-each-ref command - has seen a micro-optimization. - - * When we started to use cURL to talk to an imap server, 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). - - * "git blame --reverse OLD path" is now DWIMmed to show how lines - in path in an old revision OLD have survived up to the current - commit. - (merge e1d09701a4 jc/blame-reverse later to maint). - - * The http.emptyauth configuration variable 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 the $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 next to submodule.<name>.url - as if both belong to .git/config. This has been fixed. - - * In a worktree 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 - repository, 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 - 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. - - * "git send-email" attempts to pick up valid e-mails from the - trailers, but people in the 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 the 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 the --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 failures. 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 formatters mishandle a displayed illustration with - tabs in it. Adjust a few of them in merge-base documentation to - work around them. - - * Fixed a minor regression in "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 URLs to the - repository the client asked for into the server side directory - paths, 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 an overlong path to be - served. - (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 with $(git --exec-path) output. - (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). - - * Using a %(HEAD) placeholder in "for-each-ref --format=" option - caused the command to segfault when on an unborn branch. - (merge 84679d470d jc/for-each-ref-head-segfault-fix later to maint). - - * "git rebase -i" did not work well with the core.commentchar - configuration variable for two reasons, both of which have been - fixed. - (merge 882cd23777 js/rebase-i-commentchar-fix 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). - (merge 2b090822e8 nd/worktree-lock later to maint). - (merge 4bd488ea7c jk/create-branch-remove-unused-param later to maint). - (merge 974e0044d6 tk/diffcore-delta-remove-unused later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.11.1.txt b/third_party/git/Documentation/RelNotes/2.11.1.txt deleted file mode 100644 index 9cd14c8197..0000000000 --- a/third_party/git/Documentation/RelNotes/2.11.1.txt +++ /dev/null @@ -1,168 +0,0 @@ -Git v2.11.1 Release Notes -========================= - -Fixes since v2.11 ------------------ - - * The default Travis-CI configuration specifies newer P4 and GitLFS. - - * The character width table has been updated to match Unicode 9.0 - - * Update the isatty() emulation for Windows by updating the previous - hack that depended on internals of (older) MSVC runtime. - - * "git rev-parse --symbolic" failed with a more recent notation like - "HEAD^-1" and "HEAD^!". - - * An empty directory in a working tree that can simply be nuked used - to interfere while merging or cherry-picking a change to create a - submodule directory there, which has been fixed.. - - * The code in "git push" to compute if any commit being pushed in the - superproject binds a commit in a submodule that hasn't been pushed - out was overly inefficient, making it unusable even for a small - project that does not have any submodule but have a reasonable - number of refs. - - * "git push --dry-run --recurse-submodule=on-demand" wasn't - "--dry-run" in the submodules. - - * The output from "git worktree list" was made in readdir() order, - and was unstable. - - * mergetool.<tool>.trustExitCode configuration variable did not apply - to built-in tools, but now it does. - - * "git p4" LFS support was broken when LFS stores an empty blob. - - * Fix a corner case in merge-recursive regression that crept in - during 2.10 development cycle. - - * Update the error messages from the dumb-http client when it fails - to obtain loose objects; we used to give sensible error message - only upon 404 but we now forbid unexpected redirects that needs to - be reported with something sensible. - - * When diff.renames configuration is on (and with Git 2.9 and later, - it is enabled by default, which made it worse), "git stash" - misbehaved if a file is removed and another file with a very - similar content is added. - - * "git diff --no-index" did not take "--no-abbrev" option. - - * "git difftool --dir-diff" had a minor regression when started from - a subdirectory, which has been fixed. - - * "git commit --allow-empty --only" (no pathspec) with dirty index - ought to be an acceptable way to create a new commit that does not - change any paths, but it was forbidden, perhaps because nobody - needed it so far. - - * A pathname that begins with "//" or "\\" on Windows is special but - path normalization logic was unaware of it. - - * "git pull --rebase", when there is no new commits on our side since - we forked from the upstream, should be able to fast-forward without - invoking "git rebase", but it didn't. - - * The way to specify hotkeys to "xxdiff" that is used by "git - mergetool" has been modernized to match recent versions of xxdiff. - - * Unlike "git am --abort", "git cherry-pick --abort" moved HEAD back - to where cherry-pick started while picking multiple changes, when - the cherry-pick stopped to ask for help from the user, and the user - did "git reset --hard" to a different commit in order to re-attempt - the operation. - - * Code cleanup in shallow boundary computation. - - * A recent update to receive-pack to make it easier to drop garbage - objects made it clear that GIT_ALTERNATE_OBJECT_DIRECTORIES cannot - have a pathname with a colon in it (no surprise!), and this in turn - made it impossible to push into a repository at such a path. This - has been fixed by introducing a quoting mechanism used when - appending such a path to the colon-separated list. - - * The function usage_msg_opt() has been updated to say "fatal:" - before the custom message programs give, when they want to die - with a message about wrong command line options followed by the - standard usage string. - - * "git index-pack --stdin" needs an access to an existing repository, - but "git index-pack file.pack" to generate an .idx file that - corresponds to a packfile does not. - - * Fix for NDEBUG builds. - - * A lazy "git push" without refspec did not internally use a fully - specified refspec to perform 'current', 'simple', or 'upstream' - push, causing unnecessary "ambiguous ref" errors. - - * "git p4" misbehaved when swapping a directory and a symbolic link. - - * Even though an fix was attempted in Git 2.9.3 days, but running - "git difftool --dir-diff" from a subdirectory never worked. This - has been fixed. - - * "git p4" that tracks multile p4 paths imported a single changelist - that touches files in these multiple paths as one commit, followed - by many empty commits. This has been fixed. - - * A potential but unlikely buffer overflow in Windows port has been - fixed. - - * When the http server gives an incomplete response to a smart-http - rpc call, it could lead to client waiting for a full response that - will never come. Teach the client side to notice this condition - and abort the transfer. - - * Some platforms no longer understand "latin-1" that is still seen in - the wild in e-mail headers; replace them with "iso-8859-1" that is - more widely known when conversion fails from/to it. - - * Update the procedure to generate "tags" for developer support. - - * Update the definition of the MacOSX test environment used by - TravisCI. - - * A few git-svn updates. - - * Compression setting for producing packfiles were spread across - three codepaths, one of which did not honor any configuration. - Unify these so that all of them honor core.compression and - pack.compression variables the same way. - - * "git fast-import" sometimes mishandled while rebalancing notes - tree, which has been fixed. - - * Recent update to the default abbreviation length that auto-scales - lacked documentation update, which has been corrected. - - * Leakage of lockfiles in the config subsystem has been fixed. - - * It is natural that "git gc --auto" may not attempt to pack - everything into a single pack, and there is no point in warning - when the user has configured the system to use the pack bitmap, - leading to disabling further "gc". - - * "git archive" did not read the standard configuration files, and - failed to notice a file that is marked as binary via the userdiff - driver configuration. - - * "git blame --porcelain" misidentified the "previous" <commit, path> - pair (aka "source") when contents came from two or more files. - - * "git rebase -i" with a recent update started showing an incorrect - count when squashing more than 10 commits. - - * "git <cmd> @{push}" on a detached HEAD used to segfault; it has - been corrected to error out with a message. - - * Tighten a test to avoid mistaking an extended ERE regexp engine as - a PRE regexp engine. - - * Typing ^C to pager, which usually does not kill it, killed Git and - took the pager down as a collateral damage in certain process-tree - structure. This has been fixed. - -Also contains various documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.11.2.txt b/third_party/git/Documentation/RelNotes/2.11.2.txt deleted file mode 100644 index 7428851168..0000000000 --- a/third_party/git/Documentation/RelNotes/2.11.2.txt +++ /dev/null @@ -1,12 +0,0 @@ -Git v2.11.2 Release Notes -========================= - -Fixes since v2.11.1 -------------------- - - * "git-shell" rejects a request to serve a repository whose name - begins with a dash, which makes it no longer possible to get it - confused into spawning service programs like "git-upload-pack" with - an option like "--help", which in turn would spawn an interactive - pager, instead of working with the repository user asked to access - (i.e. the one whose name is "--help"). diff --git a/third_party/git/Documentation/RelNotes/2.11.3.txt b/third_party/git/Documentation/RelNotes/2.11.3.txt deleted file mode 100644 index 4e3b78d0e8..0000000000 --- a/third_party/git/Documentation/RelNotes/2.11.3.txt +++ /dev/null @@ -1,4 +0,0 @@ -Git v2.11.3 Release Notes -========================= - -This release forward-ports the fix for "ssh://..." URL from Git v2.7.6 diff --git a/third_party/git/Documentation/RelNotes/2.11.4.txt b/third_party/git/Documentation/RelNotes/2.11.4.txt deleted file mode 100644 index ad4da8eb09..0000000000 --- a/third_party/git/Documentation/RelNotes/2.11.4.txt +++ /dev/null @@ -1,17 +0,0 @@ -Git v2.11.4 Release Notes -========================= - -Fixes since v2.11.3 -------------------- - - * "git cvsserver" no longer is invoked by "git daemon" by default, - as it is old and largely unmaintained. - - * Various Perl scripts did not use safe_pipe_capture() instead of - backticks, leaving them susceptible to end-user input. They have - been corrected. - -Credits go to joernchen <joernchen@phenoelit.de> for finding the -unsafe constructs in "git cvsserver", and to Jeff King at GitHub for -finding and fixing instances of the same issue in other scripts. - diff --git a/third_party/git/Documentation/RelNotes/2.12.0.txt b/third_party/git/Documentation/RelNotes/2.12.0.txt deleted file mode 100644 index ef8b97da9b..0000000000 --- a/third_party/git/Documentation/RelNotes/2.12.0.txt +++ /dev/null @@ -1,500 +0,0 @@ -Git 2.12 Release Notes -====================== - -Backward compatibility notes. - - * Use of an empty string that is used for 'everything matches' is - still warned and Git 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. That - is not scheduled to happen in the upcoming release (yet). - - * The historical argument order "git merge <msg> HEAD <commit>..." - has been deprecated for quite some time, and will be removed in a - future release. - - * An ancient script "git relink" has been removed. - - -Updates since v2.11 -------------------- - -UI, Workflows & Features - - * Various updates to "git p4". - - * "git p4" didn't interact with the internal of .git directory - correctly in the modern "git-worktree"-enabled world. - - * "git branch --list" and friends learned "--ignore-case" option to - optionally sort branches and tags case insensitively. - - * In addition to %(subject), %(body), "log --pretty=format:..." - learned a new placeholder %(trailers). - - * "git rebase" learned "--quit" option, which allows a user to - remove the metadata left by an earlier "git rebase" that was - manually aborted without using "git rebase --abort". - - * "git clone --reference $there --recurse-submodules $super" has been - taught to guess repositories usable as references for submodules of - $super that are embedded in $there while making a clone of the - superproject borrow objects from $there; extend the mechanism to - also allow submodules of these submodules to borrow repositories - embedded in these clones of the submodules embedded in the clone of - the superproject. - - * Porcelain scripts written in Perl are getting internationalized. - - * "git merge --continue" has been added as a synonym to "git commit" - to conclude a merge that has stopped due to conflicts. - - * Finer-grained control of what protocols are allowed for transports - during clone/fetch/push have been enabled via a new configuration - mechanism. - - * "git shortlog" learned "--committer" option to group commits by - committer, instead of author. - - * GitLFS integration with "git p4" has been updated. - - * The isatty() emulation for Windows has been updated to eradicate - the previous hack that depended on internals of (older) MSVC - runtime. - - * Some platforms no longer understand "latin-1" that is still seen in - the wild in e-mail headers; replace them with "iso-8859-1" that is - more widely known when conversion fails from/to it. - - * "git grep" has been taught to optionally recurse into submodules. - - * "git rm" used to refuse to remove a submodule when it has its own - git repository embedded in its working tree. It learned to move - the repository away to $GIT_DIR/modules/ of the superproject - instead, and allow the submodule to be deleted (as long as there - will be no loss of local modifications, that is). - - * A recent updates to "git p4" was not usable for older p4 but it - could be made to work with minimum changes. Do so. - - * "git diff" learned diff.interHunkContext configuration variable - that gives the default value for its --inter-hunk-context option. - - * The prereleaseSuffix feature of version comparison that is used in - "git tag -l" did not correctly when two or more prereleases for the - same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2 - are there and the code needs to compare 2.0-beta1 and 2.0-beta2). - - * "git submodule push" learned "--recurse-submodules=only option to - push submodules out without pushing the top-level superproject. - - * "git tag" and "git verify-tag" learned to put GPG verification - status in their "--format=<placeholders>" output format. - - * An ancient repository conversion tool left in contrib/ has been - removed. - - * "git show-ref HEAD" used with "--verify" because the user is not - interested in seeing refs/remotes/origin/HEAD, and used with - "--head" because the user does not want HEAD to be filtered out, - i.e. "git show-ref --head --verify HEAD", did not work as expected. - - * "git submodule add" used to be confused and refused to add a - locally created repository; users can now use "--force" option - to add them. - (merge 619acfc78c sb/submodule-add-force later to maint). - - * Some people feel the default set of colors used by "git log --graph" - rather limiting. A mechanism to customize the set of colors has - been introduced. - - * "git read-tree" and its underlying unpack_trees() machinery learned - to report problematic paths prefixed with the --super-prefix option. - - * When a submodule "A", which has another submodule "B" nested within - it, is "absorbed" into the top-level superproject, the inner - submodule "B" used to be left in a strange state. The logic to - adjust the .git pointers in these submodules has been corrected. - - * The user can specify a custom update method that is run when - "submodule update" updates an already checked out submodule. This - was ignored when checking the submodule out for the first time and - we instead always just checked out the commit that is bound to the - path in the superproject's index. - - * The command line completion (in contrib/) learned that - "git diff --submodule=" can take "diff" as a recently added option. - - * The "core.logAllRefUpdates" that used to be boolean has been - enhanced to take 'always' as well, to record ref updates to refs - other than the ones that are expected to be updated (i.e. branches, - remote-tracking branches and notes). - - * Comes with more command line completion (in contrib/) for recently - introduced options. - - -Performance, Internal Implementation, Development Support etc. - - * Commands that operate on a log message and add lines to the trailer - blocks, such as "format-patch -s", "cherry-pick (-x|-s)", and - "commit -s", have been taught to use the logic of and share the - code with "git interpret-trailer". - - * The default Travis-CI configuration specifies newer P4 and GitLFS. - - * The "fast hash" that had disastrous performance issues in some - corner cases has been retired from the internal diff. - - * The character width table has been updated to match Unicode 9.0 - - * Update the procedure to generate "tags" for developer support. - - * The codeflow of setting NOATIME and CLOEXEC on file descriptors Git - opens has been simplified. - - * "git diff" and its family had two experimental heuristics to shift - the contents of a hunk to make the patch easier to read. One of - them turns out to be better than the other, so leave only the - "--indent-heuristic" option and remove the other one. - - * A new submodule helper "git submodule embedgitdirs" to make it - easier to move embedded .git/ directory for submodules in a - superproject to .git/modules/ (and point the latter with the former - that is turned into a "gitdir:" file) has been added. - - * "git push \\server\share\dir" has recently regressed and then - fixed. A test has retroactively been added for this breakage. - - * Build updates for Cygwin. - - * The implementation of "real_path()" was to go there with chdir(2) - and call getcwd(3), but this obviously wouldn't be usable in a - threaded environment. Rewrite it to manually resolve relative - paths including symbolic links in path components. - - * Adjust documentation to help AsciiDoctor render better while not - breaking the rendering done by AsciiDoc. - - * The sequencer machinery has been further enhanced so that a later - set of patches can start using it to reimplement "rebase -i". - - * Update the definition of the MacOSX test environment used by - TravisCI. - - * Rewrite a scripted porcelain "git difftool" in C. - - * "make -C t failed" will now run only the tests that failed in the - previous run. This is usable only when prove is not use, and gives - a useless error message when run after "make clean", but otherwise - is serviceable. - - * "uchar [40]" to "struct object_id" conversion continues. - - -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). - - * We often decide if a session is interactive by checking if the - standard I/O streams are connected to a TTY, but isatty() that - comes with Windows incorrectly returned true if it is used on NUL - (i.e. an equivalent to /dev/null). This has been fixed. - - * "git svn" did not work well with path components that are "0", and - some configuration variable it uses were not documented. - - * "git rev-parse --symbolic" failed with a more recent notation like - "HEAD^-1" and "HEAD^!". - - * An empty directory in a working tree that can simply be nuked used - to interfere while merging or cherry-picking a change to create a - submodule directory there, which has been fixed.. - - * The code in "git push" to compute if any commit being pushed in the - superproject binds a commit in a submodule that hasn't been pushed - out was overly inefficient, making it unusable even for a small - project that does not have any submodule but have a reasonable - number of refs. - - * "git push --dry-run --recurse-submodule=on-demand" wasn't - "--dry-run" in the submodules. - - * The output from "git worktree list" was made in readdir() order, - and was unstable. - - * mergetool.<tool>.trustExitCode configuration variable did not apply - to built-in tools, but now it does. - - * "git p4" LFS support was broken when LFS stores an empty blob. - - * A corner case in merge-recursive regression that crept in - during 2.10 development cycle has been fixed. - - * Transport with dumb http can be fooled into following foreign URLs - that the end user does not intend to, especially with the server - side redirects and http-alternates mechanism, which can lead to - security issues. Tighten the redirection and make it more obvious - to the end user when it happens. - - * Update the error messages from the dumb-http client when it fails - to obtain loose objects; we used to give sensible error message - only upon 404 but we now forbid unexpected redirects that needs to - be reported with something sensible. - - * When diff.renames configuration is on (and with Git 2.9 and later, - it is enabled by default, which made it worse), "git stash" - misbehaved if a file is removed and another file with a very - similar content is added. - - * "git diff --no-index" did not take "--no-abbrev" option. - - * "git difftool --dir-diff" had a minor regression when started from - a subdirectory, which has been fixed. - - * "git commit --allow-empty --only" (no pathspec) with dirty index - ought to be an acceptable way to create a new commit that does not - change any paths, but it was forbidden, perhaps because nobody - needed it so far. - - * Git 2.11 had a minor regression in "merge --ff-only" that competed - with another process that simultaneously attempted to update the - index. We used to explain what went wrong with an error message, - but the new code silently failed. The error message has been - resurrected. - - * A pathname that begins with "//" or "\\" on Windows is special but - path normalization logic was unaware of it. - - * "git pull --rebase", when there is no new commits on our side since - we forked from the upstream, should be able to fast-forward without - invoking "git rebase", but it didn't. - - * The way to specify hotkeys to "xxdiff" that is used by "git - mergetool" has been modernized to match recent versions of xxdiff. - - * Unlike "git am --abort", "git cherry-pick --abort" moved HEAD back - to where cherry-pick started while picking multiple changes, when - the cherry-pick stopped to ask for help from the user, and the user - did "git reset --hard" to a different commit in order to re-attempt - the operation. - - * Code cleanup in shallow boundary computation. - - * A recent update to receive-pack to make it easier to drop garbage - objects made it clear that GIT_ALTERNATE_OBJECT_DIRECTORIES cannot - have a pathname with a colon in it (no surprise!), and this in turn - made it impossible to push into a repository at such a path. This - has been fixed by introducing a quoting mechanism used when - appending such a path to the colon-separated list. - - * The function usage_msg_opt() has been updated to say "fatal:" - before the custom message programs give, when they want to die - with a message about wrong command line options followed by the - standard usage string. - - * "git index-pack --stdin" needs an access to an existing repository, - but "git index-pack file.pack" to generate an .idx file that - corresponds to a packfile does not. - - * Fix for NDEBUG builds. - - * A lazy "git push" without refspec did not internally use a fully - specified refspec to perform 'current', 'simple', or 'upstream' - push, causing unnecessary "ambiguous ref" errors. - - * "git p4" misbehaved when swapping a directory and a symbolic link. - - * Even though an fix was attempted in Git 2.9.3 days, but running - "git difftool --dir-diff" from a subdirectory never worked. This - has been fixed. - - * "git p4" that tracks multile p4 paths imported a single changelist - that touches files in these multiple paths as one commit, followed - by many empty commits. This has been fixed. - - * A potential but unlikely buffer overflow in Windows port has been - fixed. - - * When the http server gives an incomplete response to a smart-http - rpc call, it could lead to client waiting for a full response that - will never come. Teach the client side to notice this condition - and abort the transfer. - - * Compression setting for producing packfiles were spread across - three codepaths, one of which did not honor any configuration. - Unify these so that all of them honor core.compression and - pack.compression variables the same way. - - * "git fast-import" sometimes mishandled while rebalancing notes - tree, which has been fixed. - - * Recent update to the default abbreviation length that auto-scales - lacked documentation update, which has been corrected. - - * Leakage of lockfiles in the config subsystem has been fixed. - - * It is natural that "git gc --auto" may not attempt to pack - everything into a single pack, and there is no point in warning - when the user has configured the system to use the pack bitmap, - leading to disabling further "gc". - - * "git archive" did not read the standard configuration files, and - failed to notice a file that is marked as binary via the userdiff - driver configuration. - - * "git blame --porcelain" misidentified the "previous" <commit, path> - pair (aka "source") when contents came from two or more files. - - * "git rebase -i" with a recent update started showing an incorrect - count when squashing more than 10 commits. - - * "git <cmd> @{push}" on a detached HEAD used to segfault; it has - been corrected to error out with a message. - - * Running "git add a/b" when "a" is a submodule correctly errored - out, but without a meaningful error message. - (merge 2d81c48fa7 sb/pathspec-errors later to maint). - - * Typing ^C to pager, which usually does not kill it, killed Git and - took the pager down as a collateral damage in certain process-tree - structure. This has been fixed. - - * "git mergetool" without any pathspec on the command line that is - run from a subdirectory became no-op in Git v2.11 by mistake, which - has been fixed. - - * Retire long unused/unmaintained gitview from the contrib/ area. - (merge 3120925c25 sb/remove-gitview later to maint). - - * Tighten a test to avoid mistaking an extended ERE regexp engine as - a PRE regexp engine. - - * An error message with an ASCII control character like '\r' in it - can alter the message to hide its early part, which is problematic - when a remote side gives such an error message that the local side - will relay with a "remote: " prefix. - (merge f290089879 jk/vreport-sanitize later to maint). - - * "git fsck" inspects loose objects more carefully now. - (merge cce044df7f jk/loose-object-fsck later to maint). - - * A crashing bug introduced in v2.11 timeframe has been found (it is - triggerable only in fast-import) and fixed. - (merge abd5a00268 jk/clear-delta-base-cache-fix later to maint). - - * With an anticipatory tweak for remotes defined in ~/.gitconfig - (e.g. "remote.origin.prune" set to true, even though there may or - may not actually be "origin" remote defined in a particular Git - repository), "git remote rename" and other commands misinterpreted - and behaved as if such a non-existing remote actually existed. - (merge e459b073fb js/remote-rename-with-half-configured-remote later to maint). - - * A few codepaths had to rely on a global variable when sorting - elements of an array because sort(3) API does not allow extra data - to be passed to the comparison function. Use qsort_s() when - natively available, and a fallback implementation of it when not, - to eliminate the need, which is a prerequisite for making the - codepath reentrant. - - * "git fsck --connectivity-check" was not working at all. - (merge a2b22854bd jk/fsck-connectivity-check-fix later to maint). - - * After starting "git rebase -i", which first opens the user's editor - to edit the series of patches to apply, but before saving the - contents of that file, "git status" failed to show the current - state (i.e. you are in an interactive rebase session, but you have - applied no steps yet) correctly. - (merge df9ded4984 js/status-pre-rebase-i later to maint). - - * Test tweak for FreeBSD where /usr/bin/unzip is unsuitable to run - our tests but /usr/local/bin/unzip is usable. - (merge d98b2c5fce js/unzip-in-usr-bin-workaround later to maint). - - * "git p4" did not work well with multiple git-p4.mapUser entries on - Windows. - (merge c3c2b05776 gv/mingw-p4-mapuser later to maint). - - * "git help" enumerates executable files in $PATH; the implementation - of "is this file executable?" on Windows has been optimized. - (merge c755015f79 hv/mingw-help-is-executable later to maint). - - * Test tweaks for those who have default ACL in their git source tree - that interfere with the umask test. - (merge d549d21307 mm/reset-facl-before-umask-test later to maint). - - * Names of the various hook scripts must be spelled exactly, but on - Windows, an .exe binary must be named with .exe suffix; notice - $GIT_DIR/hooks/<hookname>.exe as a valid <hookname> hook. - (merge 235be51fbe js/mingw-hooks-with-exe-suffix later to maint). - - * Asciidoctor, an alternative reimplementation of AsciiDoc, still - needs some changes to work with documents meant to be formatted - with AsciiDoc. "make USE_ASCIIDOCTOR=YesPlease" to use it out of - the box to document our pages is getting closer to reality. - - * Correct command line completion (in contrib/) on "git svn" - (merge 2cbad17642 ew/complete-svn-authorship-options later to maint). - - * Incorrect usage help message for "git worktree prune" has been fixed. - (merge 2488dcab22 ps/worktree-prune-help-fix later to maint). - - * Adjust a perf test to new world order where commands that do - require a repository are really strict about having a repository. - (merge c86000c1a7 rs/p5302-create-repositories-before-tests later to maint). - - * "git log --graph" did not work well with "--name-only", even though - other forms of "diff" output were handled correctly. - (merge f5022b5fed jk/log-graph-name-only later to maint). - - * The push-options given via the "--push-options" option were not - passed through to external remote helpers such as "smart HTTP" that - are invoked via the transport helper. - - * The documentation explained what "git stash" does to the working - tree (after stashing away the local changes) in terms of "reset - --hard", which was exposing an unnecessary implementation detail. - (merge 20a7e06172 tg/stash-doc-cleanup later to maint). - - * When "git p4" imports changelist that removes paths, it failed to - convert pathnames when the p4 used encoding different from the one - used on the Git side. This has been corrected. - (merge a8b05162e8 ls/p4-path-encoding later to maint). - - * A new coccinelle rule that catches a check of !pointer before the - pointer is free(3)d, which most likely is a bug. - (merge ec6cd14c7a rs/cocci-check-free-only-null later to maint). - - * "ls-files" run with pathspec has been micro-optimized to avoid - having to memmove(3) unnecessary bytes. - (merge 96f6d3f61a rs/ls-files-partial-optim later to maint). - - * A hotfix for a topic already in 'master'. - (merge a4d92d579f js/mingw-isatty later to maint). - - * Other minor doc, test and build updates and code cleanups. - (merge f2627d9b19 sb/submodule-config-cleanup later to maint). - (merge 384f1a167b sb/unpack-trees-cleanup later to maint). - (merge 874444b704 rh/diff-orderfile-doc later to maint). - (merge eafd5d9483 cw/doc-sign-off later to maint). - (merge 0aaad415bc rs/absolute-pathdup later to maint). - (merge 4432dd6b5b rs/receive-pack-cleanup later to maint). - (merge 540a398e9c sg/mailmap-self later to maint). - (merge 209df269a6 nd/rev-list-all-includes-HEAD-doc later to maint). - (merge 941b9c5270 sb/doc-unify-bottom later to maint). - (merge 2aaf37b62c jk/doc-remote-helpers-markup-fix later to maint). - (merge e91461b332 jk/doc-submodule-markup-fix later to maint). - (merge 8ab9740d9f dp/submodule-doc-markup-fix later to maint). - (merge 0838cbc22f jk/tempfile-ferror-fclose-confusion later to maint). - (merge 115a40add6 dr/doc-check-ref-format-normalize later to maint). - (merge 133f0a299d gp/document-dotfiles-in-templates-are-not-copied later to maint). - (merge 2b35a9f4c7 bc/blame-doc-fix later to maint). - (merge 7e82388024 ps/doc-gc-aggressive-depth-update later to maint). - (merge 9993a7c5f1 bc/worktree-doc-fix-detached later to maint). - (merge e519eccdf4 rt/align-add-i-help-text later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.12.1.txt b/third_party/git/Documentation/RelNotes/2.12.1.txt deleted file mode 100644 index a74f7db747..0000000000 --- a/third_party/git/Documentation/RelNotes/2.12.1.txt +++ /dev/null @@ -1,41 +0,0 @@ -Git v2.12.1 Release Notes -========================= - -Fixes since v2.12 ------------------ - - * Reduce authentication round-trip over HTTP when the server supports - just a single authentication method. This also improves the - behaviour when Git is misconfigured to enable http.emptyAuth - against a server that does not authenticate without a username - (i.e. not using Kerberos etc., which makes http.emptyAuth - pointless). - - * Windows port wants to use OpenSSL's implementation of SHA-1 - routines, so let them. - - * Add 32-bit Linux variant to the set of platforms to be tested with - Travis CI. - - * When a redirected http transport gets an error during the - redirected request, we ignored the error we got from the server, - and ended up giving a not-so-useful error message. - - * The patch subcommand of "git add -i" was meant to have paths - selection prompt just like other subcommand, unlike "git add -p" - directly jumps to hunk selection. Recently, this was broken and - "add -i" lost the paths selection dialog, but it now has been - fixed. - - * Git v2.12 was shipped with an embarrassing breakage where various - operations that verify paths given from the user stopped dying when - seeing an issue, and instead later triggering segfault. - - * The code to parse "git log -L..." command line was buggy when there - are many ranges specified with -L; overrun of the allocated buffer - has been fixed. - - * The command-line parsing of "git log -L" copied internal data - structures using incorrect size on ILP32 systems. - -Also contains various documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.12.2.txt b/third_party/git/Documentation/RelNotes/2.12.2.txt deleted file mode 100644 index 441939709c..0000000000 --- a/third_party/git/Documentation/RelNotes/2.12.2.txt +++ /dev/null @@ -1,83 +0,0 @@ -Git v2.12.2 Release Notes -========================= - -Fixes since v2.12.1 -------------------- - - * "git status --porcelain" is supposed to give a stable output, but a - few strings were left as translatable by mistake. - - * "Dumb http" transport used to misparse a nonsense http-alternates - response, which has been fixed. - - * "git diff --quiet" relies on the size field in diff_filespec to be - correctly populated, but diff_populate_filespec() helper function - made an incorrect short-cut when asked only to populate the size - field for paths that need to go through convert_to_git() (e.g. CRLF - conversion). - - * There is no need for Python only to give a few messages to the - standard error stream, but we somehow did. - - * A leak in a codepath to read from a packed object in (rare) cases - has been plugged. - - * "git upload-pack", which is a counter-part of "git fetch", did not - report a request for a ref that was not advertised as invalid. - This is generally not a problem (because "git fetch" will stop - before making such a request), but is the right thing to do. - - * A "gc.log" file left by a backgrounded "gc --auto" disables further - automatic gc; it has been taught to run at least once a day (by - default) by ignoring a stale "gc.log" file that is too old. - - * "git remote rm X", when a branch has remote X configured as the - value of its branch.*.remote, tried to remove branch.*.remote and - branch.*.merge and failed if either is unset. - - * A caller of tempfile API that uses stdio interface to write to - files may ignore errors while writing, which is detected when - tempfile is closed (with a call to ferror()). By that time, the - original errno that may have told us what went wrong is likely to - be long gone and was overwritten by an irrelevant value. - close_tempfile() now resets errno to EIO to make errno at least - predictable. - - * "git show-branch" expected there were only very short branch names - in the repository and used a fixed-length buffer to hold them - without checking for overflow. - - * The code that parses header fields in the commit object has been - updated for (micro)performance and code hygiene. - - * A test that creates a confusing branch whose name is HEAD has been - corrected not to do so. - - * "Cc:" on the trailer part does not have to conform to RFC strictly, - unlike in the e-mail header. "git send-email" has been updated to - ignore anything after '>' when picking addresses, to allow non-address - cruft like " # stable 4.4" after the address. - - * "git push" had a handful of codepaths that could lead to a deadlock - when unexpected error happened, which has been fixed. - - * Code to read submodule.<name>.ignore config did not state the - variable name correctly when giving an error message diagnosing - misconfiguration. - - * "git ls-remote" and "git archive --remote" are designed to work - without being in a directory under Git's control. However, recent - updates revealed that we randomly look into a directory called - .git/ without actually doing necessary set-up when working in a - repository. Stop doing so. - - * The code to parse the command line "git grep <patterns>... <rev> - [[--] <pathspec>...]" has been cleaned up, and a handful of bugs - have been fixed (e.g. we used to check "--" if it is a rev). - - * The code to parse "git -c VAR=VAL cmd" and set configuration - variable for the duration of cmd had two small bugs, which have - been fixed. - This supersedes jc/config-case-cmdline topic that has been discarded. - -Also contains various documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.12.3.txt b/third_party/git/Documentation/RelNotes/2.12.3.txt deleted file mode 100644 index ebca846d5d..0000000000 --- a/third_party/git/Documentation/RelNotes/2.12.3.txt +++ /dev/null @@ -1,64 +0,0 @@ -Git v2.12.3 Release Notes -========================= - -Fixes since v2.12.2 -------------------- - - * The "parse_config_key()" API function has been cleaned up. - - * An helper function to make it easier to append the result from - real_path() to a strbuf has been added. - - * The t/perf performance test suite was not prepared to test not so - old versions of Git, but now it covers versions of Git that are not - so ancient. - - * Picking two versions of Git and running tests to make sure the - older one and the newer one interoperate happily has now become - possible. - - * Teach the "debug" helper used in the test framework that allows a - command to run under "gdb" to make the session interactive. - - * "git repack --depth=<n>" for a long time busted the specified depth - when reusing delta from existing packs. This has been corrected. - - * user.email that consists of only cruft chars should consistently - error out, but didn't. - - * A few tests were run conditionally under (rare) conditions where - they cannot be run (like running cvs tests under 'root' account). - - * "git branch @" created refs/heads/@ as a branch, and in general the - code that handled @{-1} and @{upstream} was a bit too loose in - disambiguating. - - * "git fetch" that requests a commit by object name, when the other - side does not allow such an request, failed without much - explanation. - - * "git filter-branch --prune-empty" drops a single-parent commit that - becomes a no-op, but did not drop a root commit whose tree is empty. - - * Recent versions of Git treats http alternates (used in dumb http - transport) just like HTTP redirects and requires the client to - enable following it, due to security concerns. But we forgot to - give a warning when we decide not to honor the alternates. - - * NO_PTHREADS build has been broken for some time; now fixed. - - * Fix for potential segv introduced in v2.11.0 and later (also - v2.10.2). - - * A few unterminated here documents in tests were fixed, which in - turn revealed incorrect expectations the tests make. These tests - have been updated. - - * "git-shell" rejects a request to serve a repository whose name - begins with a dash, which makes it no longer possible to get it - confused into spawning service programs like "git-upload-pack" with - an option like "--help", which in turn would spawn an interactive - pager, instead of working with the repository user asked to access - (i.e. the one whose name is "--help"). - -Also contains various documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.12.4.txt b/third_party/git/Documentation/RelNotes/2.12.4.txt deleted file mode 100644 index 3f56938221..0000000000 --- a/third_party/git/Documentation/RelNotes/2.12.4.txt +++ /dev/null @@ -1,4 +0,0 @@ -Git v2.12.4 Release Notes -========================= - -This release forward-ports the fix for "ssh://..." URL from Git v2.7.6 diff --git a/third_party/git/Documentation/RelNotes/2.12.5.txt b/third_party/git/Documentation/RelNotes/2.12.5.txt deleted file mode 100644 index 8fa73cfce7..0000000000 --- a/third_party/git/Documentation/RelNotes/2.12.5.txt +++ /dev/null @@ -1,17 +0,0 @@ -Git v2.12.5 Release Notes -========================= - -Fixes since v2.12.4 -------------------- - - * "git cvsserver" no longer is invoked by "git daemon" by default, - as it is old and largely unmaintained. - - * Various Perl scripts did not use safe_pipe_capture() instead of - backticks, leaving them susceptible to end-user input. They have - been corrected. - -Credits go to joernchen <joernchen@phenoelit.de> for finding the -unsafe constructs in "git cvsserver", and to Jeff King at GitHub for -finding and fixing instances of the same issue in other scripts. - diff --git a/third_party/git/Documentation/RelNotes/2.13.0.txt b/third_party/git/Documentation/RelNotes/2.13.0.txt deleted file mode 100644 index aa99d4b3ce..0000000000 --- a/third_party/git/Documentation/RelNotes/2.13.0.txt +++ /dev/null @@ -1,618 +0,0 @@ -Git 2.13 Release Notes -====================== - -Backward compatibility notes. - - * Use of an empty string as a pathspec element that is used for - 'everything matches' is still warned and Git 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. That is not scheduled to happen in the upcoming - release (yet). - - * The historical argument order "git merge <msg> HEAD <commit>..." - has been deprecated for quite some time, and is now removed. - - * The default location "~/.git-credential-cache/socket" for the - socket used to communicate with the credential-cache daemon has - been moved to "~/.cache/git/credential/socket". - - * Git now avoids blindly falling back to ".git" when the setup - sequence said we are _not_ in Git repository. A corner case that - happens to work right now may be broken by a call to die("BUG"). - We've tried hard to locate such cases and fixed them, but there - might still be cases that need to be addressed--bug reports are - greatly appreciated. - - -Updates since v2.12 -------------------- - -UI, Workflows & Features - - * "git describe" and "git name-rev" have been taught to take more - than one refname patterns to restrict the set of refs to base their - naming output on, and also learned to take negative patterns to - name refs not to be used for naming via their "--exclude" option. - - * Deletion of a branch "foo/bar" could remove .git/refs/heads/foo - once there no longer is any other branch whose name begins with - "foo/", but we didn't do so so far. Now we do. - - * When "git merge" detects a path that is renamed in one history - while the other history deleted (or modified) it, it now reports - both paths to help the user understand what is going on in the two - histories being merged. - - * The <url> part in "http.<url>.<variable>" configuration variable - can now be spelled with '*' that serves as wildcard. - E.g. "http.https://*.example.com.proxy" can be used to specify the - proxy used for https://a.example.com, https://b.example.com, etc., - i.e. any host in the example.com domain. - - * "git tag" did not leave useful message when adding a new entry to - reflog; this was left unnoticed for a long time because refs/tags/* - doesn't keep reflog by default. - - * The "negative" pathspec feature was somewhat more cumbersome to use - than necessary in that its short-hand used "!" which needed to be - escaped from shells, and it required "exclude from what?" specified. - - * The command line options for ssh invocation needs to be tweaked for - some implementations of SSH (e.g. PuTTY plink wants "-P <port>" - while OpenSSH wants "-p <port>" to specify port to connect to), and - the variant was guessed when GIT_SSH environment variable is used - to specify it. The logic to guess now applies to the command - specified by the newer GIT_SSH_COMMAND and also core.sshcommand - configuration variable, and comes with an escape hatch for users to - deal with misdetected cases. - - * The "--git-path", "--git-common-dir", and "--shared-index-path" - options of "git rev-parse" did not produce usable output. They are - now updated to show the path to the correct file, relative to where - the caller is. - - * "git diff -W" has been taught to handle the case where a new - function is added at the end of the file better. - - * "git update-ref -d" and other operations to delete references did - not leave any entry in HEAD's reflog when the reference being - deleted was the current branch. This is not a problem in practice - because you do not want to delete the branch you are currently on, - but caused renaming of the current branch to something else not to - be logged in a useful way. - - * "Cc:" on the trailer part does not have to conform to RFC strictly, - unlike in the e-mail header. "git send-email" has been updated to - ignore anything after '>' when picking addresses, to allow non-address - cruft like " # stable 4.4" after the address. - - * When "git submodule init" decides that the submodule in the working - tree is its upstream, it now gives a warning as it is not a very - common setup. - - * "git stash push" takes a pathspec so that the local changes can be - stashed away only partially. - - * Documentation for "git ls-files" did not refer to core.quotePath. - - * The experimental "split index" feature has gained a few - configuration variables to make it easier to use. - - * From a working tree of a repository, a new option of "rev-parse" - lets you ask if the repository is used as a submodule of another - project, and where the root level of the working tree of that - project (i.e. your superproject) is. - - * The pathspec mechanism learned to further limit the paths that - match the pattern to those that have specified attributes attached - via the gitattributes mechanism. - - * Our source code has used the SHA1_HEADER cpp macro after "#include" - in the C code to switch among the SHA-1 implementations. Instead, - list the exact header file names and switch among implementations - using "#ifdef BLK_SHA1/#include "block-sha1/sha1.h"/.../#endif"; - this helps some IDE tools. - - * The start-up sequence of "git" needs to figure out some configured - settings before it finds and set itself up in the location of the - repository and was quite messy due to its "chicken-and-egg" nature. - The code has been restructured. - - * The command line prompt (in contrib/) learned a new 'tag' style - that can be specified with GIT_PS1_DESCRIBE_STYLE, to describe a - detached HEAD with "git describe --tags". - - * The configuration file learned a new "includeIf.<condition>.path" - that includes the contents of the given path only when the - condition holds. This allows you to say "include this work-related - bit only in the repositories under my ~/work/ directory". - - * Recent update to "rebase -i" started showing a message that is not - a warning with "warning:" prefix by mistake. This has been fixed. - - * Recently we started passing the "--push-options" through the - external remote helper interface; now the "smart HTTP" remote - helper understands what to do with the passed information. - - * "git describe --dirty" dies when it cannot be determined if the - state in the working tree matches that of HEAD (e.g. broken - repository or broken submodule). The command learned a new option - "git describe --broken" to give "$name-broken" (where $name is the - description of HEAD) in such a case. - - * "git checkout" is taught the "--recurse-submodules" option. - - * Recent enhancement to "git stash push" command to support pathspec - to allow only a subset of working tree changes to be stashed away - was found to be too chatty and exposed the internal implementation - detail (e.g. when it uses reset to match the index to HEAD before - doing other things, output from reset seeped out). These, and - other chattyness has been fixed. - - * "git merge <message> HEAD <commit>" syntax that has been deprecated - since October 2007 has been removed. - - * The refs completion for large number of refs has been sped up, - partly by giving up disambiguating ambiguous refs and partly by - eliminating most of the shell processing between 'git for-each-ref' - and 'ls-remote' and Bash's completion facility. - - * On many keyboards, typing "@{" involves holding down SHIFT key and - one can easily end up with "@{Up..." when typing "@{upstream}". As - the upstream/push keywords do not appear anywhere else in the syntax, - we can safely accept them case insensitively without introducing - ambiguity or confusion to solve this. - - * "git tag/branch/for-each-ref" family of commands long allowed to - filter the refs by "--contains X" (show only the refs that are - descendants of X), "--merged X" (show only the refs that are - ancestors of X), "--no-merged X" (show only the refs that are not - ancestors of X). One curious omission, "--no-contains X" (show - only the refs that are not descendants of X) has been added to - them. - - * The default behaviour of "git log" in an interactive session has - been changed to enable "--decorate". - - * The output from "git status --short" has been extended to show - various kinds of dirtyness in submodules differently; instead of to - "M" for modified, 'm' and '?' can be shown to signal changes only - to the working tree of the submodule but not the commit that is - checked out. - - * Allow the http.postbuffer configuration variable to be set to a - size that can be expressed in size_t, which can be larger than - ulong on some platforms. - - * "git rebase" learns "--signoff" option. - - * The completion script (in contrib/) learned to complete "git push - --delete b<TAB>" to complete branch name to be deleted. - - * "git worktree add --lock" allows to lock a worktree immediately - after it's created. This helps prevent a race between "git worktree - add; git worktree lock" and "git worktree prune". - - * Completion for "git checkout <branch>" that auto-creates the branch - out of a remote tracking branch can now be disabled, as this - completion often gets in the way when completing to checkout an - existing local branch that happens to share the same prefix with - bunch of remote tracking branches. - - -Performance, Internal Implementation, Development Support etc. - - * The code to list branches in "git branch" has been consolidated - with the more generic ref-filter API. - - * Resource usage while enumerating refs from alternate object store - has been optimized to help receiving end of "push" that hosts a - repository with many "forks". - - * The gitattributes machinery is being taught to work better in a - multi-threaded environment. - - * "git rebase -i" starts using the recently updated "sequencer" code. - - * Code and design clean-up for the refs API. - - * The preload-index code has been taught not to bother with the index - entries that are paths that are not checked out by "sparse checkout". - - * Some warning() messages from "git clean" were updated to show the - errno from failed system calls. - - * The "parse_config_key()" API function has been cleaned up. - - * A test that creates a confusing branch whose name is HEAD has been - corrected not to do so. - - * The code that parses header fields in the commit object has been - updated for (micro)performance and code hygiene. - - * An helper function to make it easier to append the result from - real_path() to a strbuf has been added. - - * Reduce authentication round-trip over HTTP when the server supports - just a single authentication method. This also improves the - behaviour when Git is misconfigured to enable http.emptyAuth - against a server that does not authenticate without a username - (i.e. not using Kerberos etc., which makes http.emptyAuth - pointless). - - * Windows port wants to use OpenSSL's implementation of SHA-1 - routines, so let them. - - * The t/perf performance test suite was not prepared to test not so - old versions of Git, but now it covers versions of Git that are not - so ancient. - - * Add 32-bit Linux variant to the set of platforms to be tested with - Travis CI. - - * "git branch --list" takes the "--abbrev" and "--no-abbrev" options - to control the output of the object name in its "-v"(erbose) - output, but a recent update started ignoring them; fix it before - the breakage reaches to any released version. - - * Picking two versions of Git and running tests to make sure the - older one and the newer one interoperate happily has now become - possible. - - * "git tag --contains" used to (ab)use the object bits to keep track - of the state of object reachability without clearing them after - use; this has been cleaned up and made to use the newer commit-slab - facility. - - * The "debug" helper used in the test framework learned to run - a command under "gdb" interactively. - - * The "detect attempt to create collisions" variant of SHA-1 - implementation by Marc Stevens (CWI) and Dan Shumow (Microsoft) - has been integrated and made the default. - - * The test framework learned to detect unterminated here documents. - - * The name-hash used for detecting paths that are different only in - cases (which matter on case insensitive filesystems) has been - optimized to take advantage of multi-threading when it makes sense. - - * An earlier version of sha1dc/sha1.c that was merged to 'master' - compiled incorrectly on Windows, which has been fixed. - - * "what URL do we want to update this submodule?" and "are we - interested in this submodule?" are split into two distinct - concepts, and then the way used to express the latter got extended, - paving a way to make it easier to manage a project with many - submodules and make it possible to later extend use of multiple - worktrees for a project with submodules. - - * Some debugging output from "git describe" were marked for l10n, - but some weren't. Mark missing ones for l10n. - - * Define a new task in .travis.yml that triggers a test session on - Windows run elsewhere. - - * Conversion from uchar[20] to struct object_id continues. - - * The "submodule" specific field in the ref_store structure is - replaced with a more generic "gitdir" that can later be used also - when dealing with ref_store that represents the set of refs visible - from the other worktrees. - - * The string-list API used a custom reallocation strategy that was - very inefficient, instead of using the usual ALLOC_GROW() macro, - which has been fixed. - (merge 950a234cbd jh/string-list-micro-optim later to maint). - - * In a 2- and 3-way merge of trees, more than one source trees often - end up sharing an identical subtree; optimize by not reading the - same tree multiple times in such a case. - (merge d12a8cf0af jh/unpack-trees-micro-optim later to maint). - - * The index file has a trailing SHA-1 checksum to detect file - corruption, and historically we checked it every time the index - file is used. Omit the validation during normal use, and instead - verify only in "git fsck". - - * Having a git command on the upstream side of a pipe in a test - script will hide the exit status from the command, which may cause - us to fail to notice a breakage; rewrite tests in a script to avoid - this issue. - - * Travis CI learns to run coccicheck. - - * "git checkout" that handles a lot of paths has been optimized by - reducing the number of unnecessary checks of paths in the - has_dir_name() function. - - * The internals of the refs API around the cached refs has been - streamlined. - - * Output from perf tests have been updated to align their titles. - -Also contains various documentation updates and code clean-ups. - - -Fixes since v2.12 ------------------ - -Unless otherwise noted, all the fixes since v2.12 in the maintenance -track are contained in this release (see the maintenance releases' -notes for details). - - * "git repack --depth=<n>" for a long time busted the specified depth - when reusing delta from existing packs. This has been corrected. - - * The code to parse the command line "git grep <patterns>... <rev> - [[--] <pathspec>...]" has been cleaned up, and a handful of bugs - have been fixed (e.g. we used to check "--" if it is a rev). - - * "git ls-remote" and "git archive --remote" are designed to work - without being in a directory under Git's control. However, recent - updates revealed that we randomly look into a directory called - .git/ without actually doing necessary set-up when working in a - repository. Stop doing so. - - * "git show-branch" expected there were only very short branch names - in the repository and used a fixed-length buffer to hold them - without checking for overflow. - - * A caller of tempfile API that uses stdio interface to write to - files may ignore errors while writing, which is detected when - tempfile is closed (with a call to ferror()). By that time, the - original errno that may have told us what went wrong is likely to - be long gone and was overwritten by an irrelevant value. - close_tempfile() now resets errno to EIO to make errno at least - predictable. - - * "git remote rm X", when a branch has remote X configured as the - value of its branch.*.remote, tried to remove branch.*.remote and - branch.*.merge and failed if either is unset. - - * A "gc.log" file left by a backgrounded "gc --auto" disables further - automatic gc; it has been taught to run at least once a day (by - default) by ignoring a stale "gc.log" file that is too old. - - * The code to parse "git -c VAR=VAL cmd" and set configuration - variable for the duration of cmd had two small bugs, which have - been fixed. - - * user.email that consists of only cruft chars should consistently - error out, but didn't. - - * "git upload-pack", which is a counter-part of "git fetch", did not - report a request for a ref that was not advertised as invalid. - This is generally not a problem (because "git fetch" will stop - before making such a request), but is the right thing to do. - - * A leak in a codepath to read from a packed object in (rare) cases - has been plugged. - - * When a redirected http transport gets an error during the - redirected request, we ignored the error we got from the server, - and ended up giving a not-so-useful error message. - - * The patch subcommand of "git add -i" was meant to have paths - selection prompt just like other subcommand, unlike "git add -p" - directly jumps to hunk selection. Recently, this was broken and - "add -i" lost the paths selection dialog, but it now has been - fixed. - - * Git v2.12 was shipped with an embarrassing breakage where various - operations that verify paths given from the user stopped dying when - seeing an issue, and instead later triggering segfault. - - * There is no need for Python only to give a few messages to the - standard error stream, but we somehow did. - - * The code to parse "git log -L..." command line was buggy when there - are many ranges specified with -L; overrun of the allocated buffer - has been fixed. - - * The command-line parsing of "git log -L" copied internal data - structures using incorrect size on ILP32 systems. - - * "git diff --quiet" relies on the size field in diff_filespec to be - correctly populated, but diff_populate_filespec() helper function - made an incorrect short-cut when asked only to populate the size - field for paths that need to go through convert_to_git() (e.g. CRLF - conversion). - - * A few tests were run conditionally under (rare) conditions where - they cannot be run (like running cvs tests under 'root' account). - - * "git branch @" created refs/heads/@ as a branch, and in general the - code that handled @{-1} and @{upstream} was a bit too loose in - disambiguating. - - * "git fetch" that requests a commit by object name, when the other - side does not allow such an request, failed without much - explanation. - - * "git filter-branch --prune-empty" drops a single-parent commit that - becomes a no-op, but did not drop a root commit whose tree is empty. - - * Recent versions of Git treats http alternates (used in dumb http - transport) just like HTTP redirects and requires the client to - enable following it, due to security concerns. But we forgot to - give a warning when we decide not to honor the alternates. - - * "git push" had a handful of codepaths that could lead to a deadlock - when unexpected error happened, which has been fixed. - - * "Dumb http" transport used to misparse a nonsense http-alternates - response, which has been fixed. - - * "git add -p <pathspec>" unnecessarily expanded the pathspec to a - list of individual files that matches the pathspec by running "git - ls-files <pathspec>", before feeding it to "git diff-index" to see - which paths have changes, because historically the pathspec - language supported by "diff-index" was weaker. These days they are - equivalent and there is no reason to internally expand it. This - helps both performance and avoids command line argument limit on - some platforms. - (merge 7288e12cce jk/add-i-use-pathspecs later to maint). - - * "git status --porcelain" is supposed to give a stable output, but a - few strings were left as translatable by mistake. - - * "git revert -m 0 $merge_commit" complained that reverting a merge - needs to say relative to which parent the reversion needs to - happen, as if "-m 0" weren't given. The correct diagnosis is that - "-m 0" does not refer to the first parent ("-m 1" does). This has - been fixed. - - * Code to read submodule.<name>.ignore config did not state the - variable name correctly when giving an error message diagnosing - misconfiguration. - - * Fix for NO_PTHREADS build. - - * Fix for potential segv introduced in v2.11.0 and later (also - v2.10.2) to "git log --pickaxe-regex -S". - - * A few unterminated here documents in tests were fixed, which in - turn revealed incorrect expectations the tests make. These tests - have been updated. - - * Fix for NO_PTHREADS option. - (merge 2225e1ea20 bw/grep-recurse-submodules later to maint). - - * Git now avoids blindly falling back to ".git" when the setup - sequence said we are _not_ in Git repository. A corner case that - happens to work right now may be broken by a call to die("BUG"). - (merge b1ef400eec jk/no-looking-at-dotgit-outside-repo-final later to maint). - - * A few commands that recently learned the "--recurse-submodule" - option misbehaved when started from a subdirectory of the - superproject. - (merge b2dfeb7c00 bw/recurse-submodules-relative-fix later to maint). - - * FreeBSD implementation of getcwd(3) behaved differently when an - intermediate directory is unreadable/unsearchable depending on the - length of the buffer provided, which our strbuf_getcwd() was not - aware of. strbuf_getcwd() has been taught to cope with it better. - (merge a54e938e5b rs/freebsd-getcwd-workaround later to maint). - - * A recent update to "rebase -i" stopped running hooks for the "git - commit" command during "reword" action, which has been fixed. - - * Removing an entry from a notes tree and then looking another note - entry from the resulting tree using the internal notes API - functions did not work as expected. No in-tree users of the API - has such access pattern, but it still is worth fixing. - - * "git receive-pack" could have been forced to die by attempting - allocate an unreasonably large amount of memory with a crafted push - certificate; this has been fixed. - (merge f2214dede9 bc/push-cert-receive-fix later to maint). - - * Update error handling for codepath that deals with corrupt loose - objects. - (merge 51054177b3 jk/loose-object-info-report-error later to maint). - - * "git diff --submodule=diff" learned to work better in a project - with a submodule that in turn has its own submodules. - (merge 17b254cda6 sb/show-diff-for-submodule-in-diff-fix later to maint). - - * Update the build dependency so that an update to /usr/bin/perl - etc. result in recomputation of perl.mak file. - (merge c59c4939c2 ab/regen-perl-mak-with-different-perl later to maint). - - * "git push --recurse-submodules --push-option=<string>" learned to - propagate the push option recursively down to pushes in submodules. - - * If a patch e-mail had its first paragraph after an in-body header - indented (even after a blank line after the in-body header line), - the indented line was mistook as a continuation of the in-body - header. This has been fixed. - (merge fd1062e52e lt/mailinfo-in-body-header-continuation later to maint). - - * Clean up fallouts from recent tightening of the set-up sequence, - where Git barfs when repository information is accessed without - first ensuring that it was started in a repository. - (merge bccb22cbb1 jk/no-looking-at-dotgit-outside-repo later to maint). - - * "git p4" used "name-rev HEAD" when it wants to learn what branch is - checked out; it should use "symbolic-ref HEAD". - (merge eff451101d ld/p4-current-branch-fix later to maint). - - * "http.proxy" set to an empty string is used to disable the usage of - proxy. We broke this early last year. - (merge ae51d91105 sr/http-proxy-configuration-fix later to maint). - - * $GIT_DIR may in some cases be normalized with all symlinks resolved - while "gitdir" path expansion in the pattern does not receive the - same treatment, leading to incorrect mismatch. This has been fixed. - - * "git submodule" script does not work well with strange pathnames. - Protect it from a path with slashes in them, at least. - - * "git fetch-pack" was not prepared to accept ERR packet that the - upload-pack can send with a human-readable error message. It - showed the packet contents with ERR prefix, so there was no data - loss, but it was redundant to say "ERR" in an error message. - (merge 8e2c7bef03 jt/fetch-pack-error-reporting later to maint). - - * "ls-files --recurse-submodules" did not quite work well in a - project with nested submodules. - - * gethostname(2) may not NUL terminate the buffer if hostname does - not fit; unfortunately there is no easy way to see if our buffer - was too small, but at least this will make sure we will not end up - using garbage past the end of the buffer. - (merge 5781a9a270 dt/xgethostname-nul-termination later to maint). - - * A recent update broke "git add -p ../foo" from a subdirectory. - - * While handy, "git_path()" is a dangerous function to use as a - callsite that uses it safely one day can be broken by changes - to other code that calls it. Reduction of its use continues. - (merge 16d2676c9e jk/war-on-git-path later to maint). - - * The split-index code configuration code used an unsafe git_path() - function without copying its result out. - - * Many stale HTTP(s) links have been updated in our documentation. - (merge 613416f0be jk/update-links-in-docs later to maint). - - * "git-shell" rejects a request to serve a repository whose name - begins with a dash, which makes it no longer possible to get it - confused into spawning service programs like "git-upload-pack" with - an option like "--help", which in turn would spawn an interactive - pager, instead of working with the repository user asked to access - (i.e. the one whose name is "--help"). - - * Other minor doc, test and build updates and code cleanups. - (merge df2a6e38b7 jk/pager-in-use later to maint). - (merge 75ec4a6cb0 ab/branch-list-doc later to maint). - (merge 3e5b36c637 sg/skip-prefix-in-prettify-refname later to maint). - (merge 2c5e2865cc jk/fast-import-cleanup later to maint). - (merge 4473060bc2 ab/test-readme-updates later to maint). - (merge 48a96972fd ab/doc-submitting later to maint). - (merge f5c2bc2b96 jk/make-coccicheck-detect-errors later to maint). - (merge c105f563d1 cc/untracked later to maint). - (merge 8668976b53 jc/unused-symbols later to maint). - (merge fba275dc93 jc/bs-t-is-not-a-tab-for-sed later to maint). - (merge be6ed145de mm/ls-files-s-doc later to maint). - (merge 60b091c679 qp/bisect-docfix later to maint). - (merge 47242cd103 ah/diff-files-ours-theirs-doc later to maint). - (merge 35ad44cbd8 sb/submodule-rm-absorb later to maint). - (merge 0301f1fd92 va/i18n-perl-scripts later to maint). - (merge 733e064d98 vn/revision-shorthand-for-side-branch-log later to maint). - (merge 85999743e7 tb/doc-eol-normalization later to maint). - (merge 0747fb49fd jk/loose-object-fsck later to maint). - (merge d8f4481c4f jk/quarantine-received-objects later to maint). - (merge 7ba1ceef95 xy/format-patch-base later to maint). - (merge fa1912c89a rs/misc-cppcheck-fixes later to maint). - (merge f17d642d3b ab/push-cas-doc-n-test later to maint). - (merge 61e282425a ss/gitmodules-ignore-doc later to maint). - (merge 8d3047cd5b ss/submodule-shallow-doc later to maint). - (merge 1f9e18b772 jk/prio-queue-avoid-swap-with-self later to maint). - (merge 627fde1025 jk/submodule-init-segv-fix later to maint). - (merge d395745d81 rg/doc-pull-typofix later to maint). - (merge 01e60a9a22 rg/doc-submittingpatches-wordfix later to maint). - (merge 501d3cd7b8 sr/hooks-cwd-doc later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.13.1.txt b/third_party/git/Documentation/RelNotes/2.13.1.txt deleted file mode 100644 index ed7cd976d9..0000000000 --- a/third_party/git/Documentation/RelNotes/2.13.1.txt +++ /dev/null @@ -1,114 +0,0 @@ -Git v2.13.1 Release Notes -========================= - -Fixes since v2.13 ------------------ - - * The Web interface to gmane news archive is long gone, even though - the articles are still accessible via NTTP. Replace the links with - ones to public-inbox.org. Because their message identification is - based on the actual message-id, it is likely that it will be easier - to migrate away from it if/when necessary. - - * Update tests to pass under GETTEXT_POISON (a mechanism to ensure - that output strings that should not be translated are not - translated by mistake), and tell TravisCI to run them. - - * Setting "log.decorate=false" in the configuration file did not take - effect in v2.13, which has been corrected. - - * An earlier update to test 7400 needed to be skipped on CYGWIN. - - * Git sometimes gives an advice in a rhetorical question that does - not require an answer, which can confuse new users and non native - speakers. Attempt to rephrase them. - - * "git read-tree -m" (no tree-ish) gave a nonsense suggestion "use - --empty if you want to clear the index". With "-m", such a request - will still fail anyway, as you'd need to name at least one tree-ish - to be merged. - - * The codepath in "git am" that is used when running "git rebase" - leaked memory held for the log message of the commits being rebased. - - * "pack-objects" can stream a slice of an existing packfile out when - the pack bitmap can tell that the reachable objects are all needed - in the output, without inspecting individual objects. This - strategy however would not work well when "--local" and other - options are in use, and need to be disabled. - - * Clarify documentation for include.path and includeIf.<condition>.path - configuration variables. - - * Tag objects, which are not reachable from any ref, that point at - missing objects were mishandled by "git gc" and friends (they - should silently be ignored instead) - - * A few http:// links that are redirected to https:// in the - documentation have been updated to https:// links. - - * Make sure our tests would pass when the sources are checked out - with "platform native" line ending convention by default on - Windows. Some "text" files out tests use and the test scripts - themselves that are meant to be run with /bin/sh, ought to be - checked out with eol=LF even on Windows. - - * Fix memory leaks pointed out by Coverity (and people). - - * The receive-pack program now makes sure that the push certificate - records the same set of push options used for pushing. - - * "git cherry-pick" and other uses of the sequencer machinery - mishandled a trailer block whose last line is an incomplete line. - This has been fixed so that an additional sign-off etc. are added - after completing the existing incomplete line. - - * The shell completion script (in contrib/) learned "git stash" has - a new "push" subcommand. - - * Travis CI gained a task to format the documentation with both - AsciiDoc and AsciiDoctor. - - * Update the C style recommendation for notes for translators, as - recent versions of gettext tools can work with our style of - multi-line comments. - - * "git clone --config var=val" is a way to populate the - per-repository configuration file of the new repository, but it did - not work well when val is an empty string. This has been fixed. - - * A few codepaths in "checkout" and "am" working on an unborn branch - tried to access an uninitialized piece of memory. - - * "git for-each-ref --format=..." with %(HEAD) in the format used to - resolve the HEAD symref as many times as it had processed refs, - which was wasteful, and "git branch" shared the same problem. - - * "git interpret-trailers", when used as GIT_EDITOR for "git commit - -v", looked for and appended to a trailer block at the very end, - i.e. at the end of the "diff" output. The command has been - corrected to pay attention to the cut-mark line "commit -v" adds to - the buffer---the real trailer block should appear just before it. - - * A test allowed both "git push" and "git receive-pack" on the other - end write their traces into the same file. This is OK on platforms - that allows atomically appending to a file opened with O_APPEND, - but on other platforms led to a mangled output, causing - intermittent test failures. This has been fixed by disabling - traces from "receive-pack" in the test. - - * "foo\bar\baz" in "git fetch foo\bar\baz", even though there is no - slashes in it, cannot be a nickname for a remote on Windows, as - that is likely to be a pathname on a local filesystem. - - * The "collision detecting" SHA-1 implementation shipped with 2.13 - was quite broken on some big-endian platforms and/or platforms that - do not like unaligned fetches. Update to the upstream code which - has already fixed these issues. - - * "git am -h" triggered a BUG(). - - * The interaction of "url.*.insteadOf" and custom URL scheme's - whitelisting is now documented better. - -Also contains various documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.13.2.txt b/third_party/git/Documentation/RelNotes/2.13.2.txt deleted file mode 100644 index 8c2b20071e..0000000000 --- a/third_party/git/Documentation/RelNotes/2.13.2.txt +++ /dev/null @@ -1,54 +0,0 @@ -Git v2.13.2 Release Notes -========================= - -Fixes since v2.13.1 -------------------- - - * The "collision detecting" SHA-1 implementation shipped with 2.13.1 - was still broken on some platforms. Update to the upstream code - again to take their fix. - - * "git checkout --recurse-submodules" did not quite work with a - submodule that itself has submodules. - - * Introduce the BUG() macro to improve die("BUG: ..."). - - * The "run-command" API implementation has been made more robust - against dead-locking in a threaded environment. - - * A recent update to t5545-push-options.sh started skipping all the - tests in the script when a web server testing is disabled or - unavailable, not just the ones that require a web server. Non HTTP - tests have been salvaged to always run in this script. - - * "git clean -d" used to clean directories that has ignored files, - even though the command should not lose ignored ones without "-x". - "git status --ignored" did not list ignored and untracked files - without "-uall". These have been corrected. - - * The timestamp of the index file is now taken after the file is - closed, to help Windows, on which a stale timestamp is reported by - fstat() on a file that is opened for writing and data was written - but not yet closed. - - * "git pull --rebase --autostash" didn't auto-stash when the local history - fast-forwards to the upstream. - - * "git describe --contains" penalized light-weight tags so much that - they were almost never considered. Instead, give them about the - same chance to be considered as an annotated tag that is the same - age as the underlying commit would. - - * The result from "git diff" that compares two blobs, e.g. "git diff - $commit1:$path $commit2:$path", used to be shown with the full - object name as given on the command line, but it is more natural to - use the $path in the output and use it to look up .gitattributes. - - * A flaky test has been corrected. - - * Help contributors that visit us at GitHub. - - * "git stash push <pathspec>" did not work from a subdirectory at all. - Bugfix for a topic in v2.13 - -Also contains various documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.13.3.txt b/third_party/git/Documentation/RelNotes/2.13.3.txt deleted file mode 100644 index 5d76ad5310..0000000000 --- a/third_party/git/Documentation/RelNotes/2.13.3.txt +++ /dev/null @@ -1,62 +0,0 @@ -Git v2.13.3 Release Notes -========================= - -Fixes since v2.13.2 -------------------- - - * The "collision detecting" SHA-1 implementation shipped with 2.13.2 - was still broken on some platforms. Update to the upstream code - again to take their fix. - - * The 'diff-highlight' program (in contrib/) has been restructured - for easier reuse by an external project 'diff-so-fancy'. - - * "git mergetool" learned to work around a wrapper MacOS X adds - around underlying meld. - - * An example in documentation that does not work in multi worktree - configuration has been corrected. - - * The pretty-format specifiers like '%h', '%t', etc. had an - optimization that no longer works correctly. In preparation/hope - of getting it correctly implemented, first discard the optimization - that is broken. - - * The code to pick up and execute command alias definition from the - configuration used to switch to the top of the working tree and - then come back when the expanded alias was executed, which was - unnecessarilyl complex. Attempt to simplify the logic by using the - early-config mechanism that does not chdir around. - - * "git add -p" were updated in 2.12 timeframe to cope with custom - core.commentchar but the implementation was buggy and a - metacharacter like $ and * did not work. - - * Fix a recent regression to "git rebase -i" and add tests that would - have caught it and others. - - * An unaligned 32-bit access in pack-bitmap code ahs been corrected. - - * Tighten error checks for invalid "git apply" input. - - * The split index code did not honor core.sharedrepository setting - correctly. - - * The Makefile rule in contrib/subtree for building documentation - learned to honour USE_ASCIIDOCTOR just like the main documentation - set does. - - * A few tests that tried to verify the contents of push certificates - did not use 'git rev-parse' to formulate the line to look for in - the certificate correctly. - - * After "git branch --move" of the currently checked out branch, the - code to walk the reflog of HEAD via "log -g" and friends - incorrectly stopped at the reflog entry that records the renaming - of the branch. - - * The rewrite of "git branch --list" using for-each-ref's internals - that happened in v2.13 regressed its handling of color.branch.local; - this has been fixed. - -Also contains various documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.13.4.txt b/third_party/git/Documentation/RelNotes/2.13.4.txt deleted file mode 100644 index 9a9f8f9599..0000000000 --- a/third_party/git/Documentation/RelNotes/2.13.4.txt +++ /dev/null @@ -1,28 +0,0 @@ -Git v2.13.4 Release Notes -========================= - -Fixes since v2.13.3 -------------------- - - * Update the character width tables. - - * A recent update broke an alias that contained an uppercase letter, - which has been fixed. - - * On Cygwin, similar to Windows, "git push //server/share/repository" - ought to mean a repository on a network share that can be accessed - locally, but this did not work correctly due to stripping the double - slashes at the beginning. - - * The progress meter did not give a useful output when we haven't had - 0.5 seconds to measure the throughput during the interval. Instead - show the overall throughput rate at the end, which is a much more - useful number. - - * We run an early part of "git gc" that deals with refs before - daemonising (and not under lock) even when running a background - auto-gc, which caused multiple gc processes attempting to run the - early part at the same time. This is now prevented by running the - early part also under the GC lock. - -Also contains a handful of small code and documentation clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.13.5.txt b/third_party/git/Documentation/RelNotes/2.13.5.txt deleted file mode 100644 index 6949fcda78..0000000000 --- a/third_party/git/Documentation/RelNotes/2.13.5.txt +++ /dev/null @@ -1,4 +0,0 @@ -Git v2.13.5 Release Notes -========================= - -This release forward-ports the fix for "ssh://..." URL from Git v2.7.6 diff --git a/third_party/git/Documentation/RelNotes/2.13.6.txt b/third_party/git/Documentation/RelNotes/2.13.6.txt deleted file mode 100644 index afcae9c808..0000000000 --- a/third_party/git/Documentation/RelNotes/2.13.6.txt +++ /dev/null @@ -1,17 +0,0 @@ -Git v2.13.6 Release Notes -========================= - -Fixes since v2.13.5 -------------------- - - * "git cvsserver" no longer is invoked by "git daemon" by default, - as it is old and largely unmaintained. - - * Various Perl scripts did not use safe_pipe_capture() instead of - backticks, leaving them susceptible to end-user input. They have - been corrected. - -Credits go to joernchen <joernchen@phenoelit.de> for finding the -unsafe constructs in "git cvsserver", and to Jeff King at GitHub for -finding and fixing instances of the same issue in other scripts. - diff --git a/third_party/git/Documentation/RelNotes/2.13.7.txt b/third_party/git/Documentation/RelNotes/2.13.7.txt deleted file mode 100644 index 09fc01406c..0000000000 --- a/third_party/git/Documentation/RelNotes/2.13.7.txt +++ /dev/null @@ -1,20 +0,0 @@ -Git v2.13.7 Release Notes -========================= - -Fixes since v2.13.6 -------------------- - - * Submodule "names" come from the untrusted .gitmodules file, but we - blindly append them to $GIT_DIR/modules to create our on-disk repo - paths. This means you can do bad things by putting "../" into the - name. We now enforce some rules for submodule names which will cause - Git to ignore these malicious names (CVE-2018-11235). - - Credit for finding this vulnerability and the proof of concept from - which the test script was adapted goes to Etienne Stalmans. - - * It was possible to trick the code that sanity-checks paths on NTFS - into reading random piece of memory (CVE-2018-11233). - -Credit for fixing for these bugs goes to Jeff King, Johannes -Schindelin and others. diff --git a/third_party/git/Documentation/RelNotes/2.14.0.txt b/third_party/git/Documentation/RelNotes/2.14.0.txt deleted file mode 100644 index 4246c68ff5..0000000000 --- a/third_party/git/Documentation/RelNotes/2.14.0.txt +++ /dev/null @@ -1,517 +0,0 @@ -Git 2.14 Release Notes -====================== - -Backward compatibility notes and other notable changes. - - * Use of an empty string as a pathspec element that is used for - 'everything matches' is still warned and Git 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. That is not scheduled to happen in the upcoming - release (yet). - - * Git now avoids blindly falling back to ".git" when the setup - sequence said we are _not_ in Git repository. A corner case that - happens to work right now may be broken by a call to die("BUG"). - We've tried hard to locate such cases and fixed them, but there - might still be cases that need to be addressed--bug reports are - greatly appreciated. - - * The experiment to improve the hunk-boundary selection of textual - diff output has finished, and the "indent heuristics" has now - become the default. - - * Git can now be built with PCRE v2 instead of v1 of the PCRE - library. Replace USE_LIBPCRE=YesPlease with USE_LIBPCRE2=YesPlease - in existing build scripts to build against the new version. As the - upstream PCRE maintainer has abandoned v1 maintenance for all but - the most critical bug fixes, use of v2 is recommended. - - -Updates since v2.13 -------------------- - -UI, Workflows & Features - - * The colors in which "git status --short --branch" showed the names - of the current branch and its remote-tracking branch are now - configurable. - - * "git clone" learned the "--no-tags" option not to fetch all tags - initially, and also set up the tagopt not to follow any tags in - subsequent fetches. - - * "git archive --format=zip" learned to use zip64 extension when - necessary to go beyond the 4GB limit. - - * "git reset" learned "--recurse-submodules" option. - - * "git diff --submodule=diff" now recurses into nested submodules. - - * "git repack" learned to accept the --threads=<n> option and pass it - to pack-objects. - - * "git send-email" learned to run sendemail-validate hook to inspect - and reject a message before sending it out. - - * There is no good reason why "git fetch $there $sha1" should fail - when the $sha1 names an object at the tip of an advertised ref, - even when the other side hasn't enabled allowTipSHA1InWant. - - * The "[includeIf "gitdir:$dir"] path=..." mechanism introduced in - 2.13.0 would canonicalize the path of the gitdir being matched, - and did not match e.g. "gitdir:~/work/*" against a repo in - "~/work/main" if "~/work" was a symlink to "/mnt/storage/work". - Now we match both the resolved canonical path and what "pwd" would - show. The include will happen if either one matches. - - * The "indent" heuristics is now the default in "diff". The - diff.indentHeuristic configuration variable can be set to "false" - for those who do not want it. - - * Many commands learned to pay attention to submodule.recurse - configuration. - - * The convention for a command line is to follow "git cmdname - --options" with revisions followed by an optional "--" - disambiguator and then finally pathspecs. When "--" is not there, - we make sure early ones are all interpretable as revs (and do not - look like paths) and later ones are the other way around. A - pathspec with "magic" (e.g. ":/p/a/t/h" that matches p/a/t/h from - the top-level of the working tree, no matter what subdirectory you - are working from) are conservatively judged as "not a path", which - required disambiguation more often. The command line parser - learned to say "it's a pathspec" a bit more often when the syntax - looks like so. - - * Update "perl-compatible regular expression" support to enable JIT - and also allow linking with the newer PCRE v2 library. - - * "filter-branch" learned a pseudo filter "--setup" that can be used - to define common functions/variables that can be used by other - filters. - - * Using "git add d/i/r" when d/i/r is the top of the working tree of - a separate repository would create a gitlink in the index, which - would appear as a not-quite-initialized submodule to others. We - learned to give warnings when this happens. - - * "git status" learned to optionally give how many stash entries there - are in its output. - - * "git status" has long shown essentially the same message as "git - commit"; the message it gives while preparing for the root commit, - i.e. "Initial commit", was hard to understand for some new users. - Now it says "No commits yet" to stress more on the current status - (rather than the commit the user is preparing for, which is more in - line with the focus of "git commit"). - - * "git send-email" now has --batch-size and --relogin-delay options - which can be used to overcome limitations on SMTP servers that - restrict on how many of e-mails can be sent in a single session. - - * An old message shown in the commit log template was removed, as it - has outlived its usefulness. - - * "git pull --rebase --recurse-submodules" learns to rebase the - branch in the submodules to an updated base. - - * "git log" learned -P as a synonym for --perl-regexp, "git grep" - already had such a synonym. - - * "git log" didn't understand --regexp-ignore-case when combined with - --perl-regexp. This has been fixed. - -Performance, Internal Implementation, Development Support etc. - - * The default packed-git limit value has been raised on larger - platforms to save "git fetch" from a (recoverable) failure while - "gc" is running in parallel. - - * Code to update the cache-tree has been tightened so that we won't - accidentally write out any 0{40} entry in the tree object. - - * Attempt to allow us notice "fishy" situation where we fail to - remove the temporary directory used during the test. - - * Travis CI gained a task to format the documentation with both - AsciiDoc and AsciiDoctor. - - * Some platforms have ulong that is smaller than time_t, and our - historical use of ulong for timestamp would mean they cannot - represent some timestamp that the platform allows. Invent a - separate and dedicated timestamp_t (so that we can distingiuish - timestamps and a vanilla ulongs, which along is already a good - move), and then declare uintmax_t is the type to be used as the - timestamp_t. - - * We can trigger Windows auto-build tester (credits: Dscho & - Microsoft) from our existing Travis CI tester now. - - * Conversion from uchar[20] to struct object_id continues. - - * Simplify parse_pathspec() codepath and stop it from looking at the - default in-core index. - - * Add perf-test for wildmatch. - - * Code from "conversion using external process" codepath has been - extracted to a separate sub-process.[ch] module. - - * When "git checkout", "git merge", etc. manipulates the in-core - index, various pieces of information in the index extensions are - discarded from the original state, as it is usually not the case - that they are kept up-to-date and in-sync with the operation on the - main index. The untracked cache extension is copied across these - operations now, which would speed up "git status" (as long as the - cache is properly invalidated). - - * The internal implementation of "git grep" has seen some clean-up. - - * Update the C style recommendation for notes for translators, as - recent versions of gettext tools can work with our style of - multi-line comments. - - * The implementation of "ref" API around the "packed refs" have been - cleaned up, in preparation for further changes. - - * The internal logic used in "git blame" has been libified to make it - easier to use by cgit. - - * Our code often opens a path to an optional file, to work on its - contents when we can successfully open it. We can ignore a failure - to open if such an optional file does not exist, but we do want to - report a failure in opening for other reasons (e.g. we got an I/O - error, or the file is there, but we lack the permission to open). - - The exact errors we need to ignore are ENOENT (obviously) and - ENOTDIR (less obvious). Instead of repeating comparison of errno - with these two constants, introduce a helper function to do so. - - * We often try to open a file for reading whose existence is - optional, and silently ignore errors from open/fopen; report such - errors if they are not due to missing files. - - * When an existing repository is used for t/perf testing, we first - create bit-for-bit copy of it, which may grab a transient state of - the repository and freeze it into the repository used for testing, - which then may cause Git operations to fail. Single out "the index - being locked" case and forcibly drop the lock from the copy. - - * Three instances of the same helper function have been consolidated - to one. - - * "fast-import" uses a default pack chain depth that is consistent - with other parts of the system. - - * A new test to show the interaction between the pattern [^a-z] - (which matches '/') and a slash in a path has been added. The - pattern should not match the slash with "pathmatch", but should - with "wildmatch". - - * The 'diff-highlight' program (in contrib/) has been restructured - for easier reuse by an external project 'diff-so-fancy'. - - * A common pattern to free a piece of memory and assign NULL to the - pointer that used to point at it has been replaced with a new - FREE_AND_NULL() macro. - - * Traditionally, the default die() routine had a code to prevent it - from getting called multiple times, which interacted badly when a - threaded program used it (one downside is that the real error may - be hidden and instead the only error message given to the user may - end up being "die recursion detected", which is not very useful). - - * Introduce a "repository" object to eventually make it easier to - work in multiple repositories (the primary focus is to work with - the superproject and its submodules) in a single process. - - * Optimize "what are the object names already taken in an alternate - object database?" query that is used to derive the length of prefix - an object name is uniquely abbreviated to. - - * The hashmap API has been updated so that data to customize the - behaviour of the comparison function can be specified at the time a - hashmap is initialized. - - * The "collision detecting" SHA-1 implementation shipped with 2.13 is - now integrated into git.git as a submodule (the first submodule to - ship with git.git). Clone git.git with --recurse-submodules to get - it. For now a non-submodule copy of the same code is also shipped - as part of the tree. - - * A recent update made it easier to use "-fsanitize=" option while - compiling but supported only one sanitize option. Allow more than - one to be combined, joined with a comma, like "make SANITIZE=foo,bar". - - * Use "p4 -G" to make "p4 changes" output more Python-friendly - to parse. - - * We started using "%" PRItime, imitating "%" PRIuMAX and friends, as - a way to format the internal timestamp value, but this does not - play well with gettext(1) i18n framework, and causes "make pot" - that is run by the l10n coordinator to create a broken po/git.pot - file. This is a possible workaround for that problem. - - * It turns out that Cygwin also needs the fopen() wrapper that - returns failure when a directory is opened for reading. - -Also contains various documentation updates and code clean-ups. - - -Fixes since v2.13 ------------------ - -Unless otherwise noted, all the fixes since v2.13 in the maintenance -track are contained in this release (see the maintenance releases' -notes for details). - - * "git gc" did not interact well with "git worktree"-managed - per-worktree refs. - - * "git cherry-pick" and other uses of the sequencer machinery - mishandled a trailer block whose last line is an incomplete line. - This has been fixed so that an additional sign-off etc. are added - after completing the existing incomplete line. - - * The codepath in "git am" that is used when running "git rebase" - leaked memory held for the log message of the commits being rebased. - - * "git clone --config var=val" is a way to populate the - per-repository configuration file of the new repository, but it did - not work well when val is an empty string. This has been fixed. - - * Setting "log.decorate=false" in the configuration file did not take - effect in v2.13, which has been corrected. - - * A few codepaths in "checkout" and "am" working on an unborn branch - tried to access an uninitialized piece of memory. - - * The Web interface to gmane news archive is long gone, even though - the articles are still accessible via NTTP. Replace the links with - ones to public-inbox.org. Because their message identification is - based on the actual message-id, it is likely that it will be easier - to migrate away from it if/when necessary. - - * The receive-pack program now makes sure that the push certificate - records the same set of push options used for pushing. - - * Tests have been updated to pass under GETTEXT_POISON (a mechanism - to ensure that output strings that should not be translated are - not translated by mistake), and TravisCI is told to run them. - - * "git checkout --recurse-submodules" did not quite work with a - submodule that itself has submodules. - - * "pack-objects" can stream a slice of an existing packfile out when - the pack bitmap can tell that the reachable objects are all needed - in the output, without inspecting individual objects. This - strategy however would not work well when "--local" and other - options are in use, and need to be disabled. - - * Fix memory leaks pointed out by Coverity (and people). - - * "git read-tree -m" (no tree-ish) gave a nonsense suggestion "use - --empty if you want to clear the index". With "-m", such a request - will still fail anyway, as you'd need to name at least one tree-ish - to be merged. - - * Make sure our tests would pass when the sources are checked out - with "platform native" line ending convention by default on - Windows. Some "text" files out tests use and the test scripts - themselves that are meant to be run with /bin/sh, ought to be - checked out with eol=LF even on Windows. - - * Introduce the BUG() macro to improve die("BUG: ..."). - - * Clarify documentation for include.path and includeIf.<condition>.path - configuration variables. - - * Git sometimes gives an advice in a rhetorical question that does - not require an answer, which can confuse new users and non native - speakers. Attempt to rephrase them. - - * A few http:// links that are redirected to https:// in the - documentation have been updated to https:// links. - - * "git for-each-ref --format=..." with %(HEAD) in the format used to - resolve the HEAD symref as many times as it had processed refs, - which was wasteful, and "git branch" shared the same problem. - - * Regression fix to topic recently merged to 'master'. - - * The shell completion script (in contrib/) learned "git stash" has - a new "push" subcommand. - - * "git interpret-trailers", when used as GIT_EDITOR for "git commit - -v", looked for and appended to a trailer block at the very end, - i.e. at the end of the "diff" output. The command has been - corrected to pay attention to the cut-mark line "commit -v" adds to - the buffer---the real trailer block should appear just before it. - - * A test allowed both "git push" and "git receive-pack" on the other - end write their traces into the same file. This is OK on platforms - that allows atomically appending to a file opened with O_APPEND, - but on other platforms led to a mangled output, causing - intermittent test failures. This has been fixed by disabling - traces from "receive-pack" in the test. - - * Tag objects, which are not reachable from any ref, that point at - missing objects were mishandled by "git gc" and friends (they - should silently be ignored instead) - - * "git describe --contains" penalized light-weight tags so much that - they were almost never considered. Instead, give them about the - same chance to be considered as an annotated tag that is the same - age as the underlying commit would. - - * The "run-command" API implementation has been made more robust - against dead-locking in a threaded environment. - - * A recent update to t5545-push-options.sh started skipping all the - tests in the script when a web server testing is disabled or - unavailable, not just the ones that require a web server. Non HTTP - tests have been salvaged to always run in this script. - - * "git send-email" now uses Net::SMTP::SSL, which is obsolete, only - when needed. Recent versions of Net::SMTP can do TLS natively. - - * "foo\bar\baz" in "git fetch foo\bar\baz", even though there is no - slashes in it, cannot be a nickname for a remote on Windows, as - that is likely to be a pathname on a local filesystem. - - * "git clean -d" used to clean directories that has ignored files, - even though the command should not lose ignored ones without "-x". - "git status --ignored" did not list ignored and untracked files - without "-uall". These have been corrected. - - * The result from "git diff" that compares two blobs, e.g. "git diff - $commit1:$path $commit2:$path", used to be shown with the full - object name as given on the command line, but it is more natural to - use the $path in the output and use it to look up .gitattributes. - - * The "collision detecting" SHA-1 implementation shipped with 2.13 - was quite broken on some big-endian platforms and/or platforms that - do not like unaligned fetches. Update to the upstream code which - has already fixed these issues. - - * "git am -h" triggered a BUG(). - - * The interaction of "url.*.insteadOf" and custom URL scheme's - whitelisting is now documented better. - - * The timestamp of the index file is now taken after the file is - closed, to help Windows, on which a stale timestamp is reported by - fstat() on a file that is opened for writing and data was written - but not yet closed. - - * "git pull --rebase --autostash" didn't auto-stash when the local history - fast-forwards to the upstream. - - * A flaky test has been corrected. - - * "git $cmd -h" for builtin commands calls the implementation of the - command (i.e. cmd_$cmd() function) without doing any repository - set-up, and the commands that expect RUN_SETUP is done by the Git - potty needs to be prepared to show the help text without barfing. - (merge d691551192 jk/consistent-h later to maint). - - * Help contributors that visit us at GitHub. - - * "git stash push <pathspec>" did not work from a subdirectory at all. - Bugfix for a topic in v2.13 - - * As there is no portable way to pass timezone information to - strftime, some output format from "git log" and friends are - impossible to produce. Teach our own strbuf_addftime to replace %z - and %Z with caller-supplied values to help working around this. - (merge 6eced3ec5e rs/strbuf-addftime-zZ later to maint). - - * "git mergetool" learned to work around a wrapper MacOS X adds - around underlying meld. - - * An example in documentation that does not work in multi worktree - configuration has been corrected. - - * The pretty-format specifiers like '%h', '%t', etc. had an - optimization that no longer works correctly. In preparation/hope - of getting it correctly implemented, first discard the optimization - that is broken. - - * The code to pick up and execute command alias definition from the - configuration used to switch to the top of the working tree and - then come back when the expanded alias was executed, which was - unnecessarilyl complex. Attempt to simplify the logic by using the - early-config mechanism that does not chdir around. - - * Fix configuration codepath to pay proper attention to commondir - that is used in multi-worktree situation, and isolate config API - into its own header file. - (merge dc8441fdb4 bw/config-h later to maint). - - * "git add -p" were updated in 2.12 timeframe to cope with custom - core.commentchar but the implementation was buggy and a - metacharacter like $ and * did not work. - - * A recent regression in "git rebase -i" has been fixed and tests - that would have caught it and others have been added. - - * An unaligned 32-bit access in pack-bitmap code has been corrected. - - * Tighten error checks for invalid "git apply" input. - - * The split index code did not honor core.sharedRepository setting - correctly. - - * The Makefile rule in contrib/subtree for building documentation - learned to honour USE_ASCIIDOCTOR just like the main documentation - set does. - - * Code clean-up to fix possible buffer over-reading. - - * A few tests that tried to verify the contents of push certificates - did not use 'git rev-parse' to formulate the line to look for in - the certificate correctly. - - * Update the character width tables. - - * After "git branch --move" of the currently checked out branch, the - code to walk the reflog of HEAD via "log -g" and friends - incorrectly stopped at the reflog entry that records the renaming - of the branch. - - * The rewrite of "git branch --list" using for-each-ref's internals - that happened in v2.13 regressed its handling of color.branch.local; - this has been fixed. - - * The build procedure has been improved to allow building and testing - Git with address sanitizer more easily. - (merge 425ca6710b jk/build-with-asan later to maint). - - * On Cygwin, similar to Windows, "git push //server/share/repository" - ought to mean a repository on a network share that can be accessed - locally, but this did not work correctly due to stripping the double - slashes at the beginning. - - * The progress meter did not give a useful output when we haven't had - 0.5 seconds to measure the throughput during the interval. Instead - show the overall throughput rate at the end, which is a much more - useful number. - - * Code clean-up, that makes us in sync with Debian by one patch. - - * We run an early part of "git gc" that deals with refs before - daemonising (and not under lock) even when running a background - auto-gc, which caused multiple gc processes attempting to run the - early part at the same time. This is now prevented by running the - early part also under the GC lock. - - * A recent update broke an alias that contained an uppercase letter. - - * Other minor doc, test and build updates and code cleanups. - (merge 5053313562 rs/urlmatch-cleanup later to maint). - (merge 42c78a216e rs/use-div-round-up later to maint). - (merge 5e8d2729ae rs/wt-status-cleanup later to maint). - (merge bc9b7e207f as/diff-options-grammofix later to maint). - (merge ac05222b31 ah/patch-id-doc later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.14.1.txt b/third_party/git/Documentation/RelNotes/2.14.1.txt deleted file mode 100644 index 9403340f7f..0000000000 --- a/third_party/git/Documentation/RelNotes/2.14.1.txt +++ /dev/null @@ -1,4 +0,0 @@ -Git v2.14.1 Release Notes -========================= - -This release forward-ports the fix for "ssh://..." URL from Git v2.7.6 diff --git a/third_party/git/Documentation/RelNotes/2.14.2.txt b/third_party/git/Documentation/RelNotes/2.14.2.txt deleted file mode 100644 index bec9186ade..0000000000 --- a/third_party/git/Documentation/RelNotes/2.14.2.txt +++ /dev/null @@ -1,105 +0,0 @@ -Git v2.14.2 Release Notes -========================= - -Fixes since v2.14.1 -------------------- - - * Because recent Git for Windows do come with a real msgfmt, the - build procedure for git-gui has been updated to use it instead of a - hand-rolled substitute. - - * "%C(color name)" in the pretty print format always produced ANSI - color escape codes, which was an early design mistake. They now - honor the configuration (e.g. "color.ui = never") and also tty-ness - of the output medium. - - * The http.{sslkey,sslCert} configuration variables are to be - interpreted as a pathname that honors "~[username]/" prefix, but - weren't, which has been fixed. - - * Numerous bugs in walking of reflogs via "log -g" and friends have - been fixed. - - * "git commit" when seeing an totally empty message said "you did not - edit the message", which is clearly wrong. The message has been - corrected. - - * When a directory is not readable, "gitweb" fails to build the - project list. Work this around by skipping such a directory. - - * A recently added test for the "credential-cache" helper revealed - that EOF detection done around the time the connection to the cache - daemon is torn down were flaky. This was fixed by reacting to - ECONNRESET and behaving as if we got an EOF. - - * Some versions of GnuPG fail to kill gpg-agent it auto-spawned - and such a left-over agent can interfere with a test. Work it - around by attempting to kill one before starting a new test. - - * "git log --tag=no-such-tag" showed log starting from HEAD, which - has been fixed---it now shows nothing. - - * The "tag.pager" configuration variable was useless for those who - actually create tag objects, as it interfered with the use of an - editor. A new mechanism has been introduced for commands to enable - pager depending on what operation is being carried out to fix this, - and then "git tag -l" is made to run pager by default. - - * "git push --recurse-submodules $there HEAD:$target" was not - propagated down to the submodules, but now it is. - - * Commands like "git rebase" accepted the --rerere-autoupdate option - from the command line, but did not always use it. This has been - fixed. - - * "git clone --recurse-submodules --quiet" did not pass the quiet - option down to submodules. - - * "git am -s" has been taught that some input may end with a trailer - block that is not Signed-off-by: and it should refrain from adding - an extra blank line before adding a new sign-off in such a case. - - * "git svn" used with "--localtime" option did not compute the tz - offset for the timestamp in question and instead always used the - current time, which has been corrected. - - * Memory leaks in a few error codepaths have been plugged. - - * bash 4.4 or newer gave a warning on NUL byte in command - substitution done in "git stash"; this has been squelched. - - * "git grep -L" and "git grep --quiet -L" reported different exit - codes; this has been corrected. - - * When handshake with a subprocess filter notices that the process - asked for an unknown capability, Git did not report what program - the offending subprocess was running. This has been corrected. - - * "git apply" that is used as a better "patch -p1" failed to apply a - taken from a file with CRLF line endings to a file with CRLF line - endings. The root cause was because it misused convert_to_git() - that tried to do "safe-crlf" processing by looking at the index - entry at the same path, which is a nonsense---in that mode, "apply" - is not working on the data in (or derived from) the index at all. - This has been fixed. - - * Killing "git merge --edit" before the editor returns control left - the repository in a state with MERGE_MSG but without MERGE_HEAD, - which incorrectly tells the subsequent "git commit" that there was - a squash merge in progress. This has been fixed. - - * "git archive" did not work well with pathspecs and the - export-ignore attribute. - - * "git cvsserver" no longer is invoked by "git daemon" by default, - as it is old and largely unmaintained. - - * Various Perl scripts did not use safe_pipe_capture() instead of - backticks, leaving them susceptible to end-user input. They have - been corrected. - -Also contains various documentation updates and code clean-ups. - -Credits go to joernchen <joernchen@phenoelit.de> for finding the -unsafe constructs in "git cvsserver", and to Jeff King at GitHub for -finding and fixing instances of the same issue in other scripts. diff --git a/third_party/git/Documentation/RelNotes/2.14.3.txt b/third_party/git/Documentation/RelNotes/2.14.3.txt deleted file mode 100644 index 977c9e857c..0000000000 --- a/third_party/git/Documentation/RelNotes/2.14.3.txt +++ /dev/null @@ -1,99 +0,0 @@ -Git v2.14.3 Release Notes -========================= - -Fixes since v2.14.2 -------------------- - - * A helper function to read a single whole line into strbuf - mistakenly triggered OOM error at EOF under certain conditions, - which has been fixed. - - * In addition to "cc: <a@dd.re.ss> # cruft", "cc: a@dd.re.ss # cruft" - was taught to "git send-email" as a valid way to tell it that it - needs to also send a carbon copy to <a@dd.re.ss> in the trailer - section. - - * Fix regression to "gitk --bisect" by a recent update. - - * Unlike "git commit-tree < file", "git commit-tree -F file" did not - pass the contents of the file verbatim and instead completed an - incomplete line at the end, if exists. The latter has been updated - to match the behaviour of the former. - - * "git archive", especially when used with pathspec, stored an empty - directory in its output, even though Git itself never does so. - This has been fixed. - - * API error-proofing which happens to also squelch warnings from GCC. - - * "git gc" tries to avoid running two instances at the same time by - reading and writing pid/host from and to a lock file; it used to - use an incorrect fscanf() format when reading, which has been - corrected. - - * The test linter has been taught that we do not like "echo -e". - - * Code cmp.std.c nitpick. - - * "git describe --match" learned to take multiple patterns in v2.13 - series, but the feature ignored the patterns after the first one - and did not work at all. This has been fixed. - - * "git cat-file --textconv" started segfaulting recently, which - has been corrected. - - * The built-in pattern to detect the "function header" for HTML did - not match <H1>..<H6> elements without any attributes, which has - been fixed. - - * "git mailinfo" was loose in decoding quoted printable and produced - garbage when the two letters after the equal sign are not - hexadecimal. This has been fixed. - - * The documentation for '-X<option>' for merges was misleadingly - written to suggest that "-s theirs" exists, which is not the case. - - * Spell the name of our system as "Git" in the output from - request-pull script. - - * Fixes for a handful memory access issues identified by valgrind. - - * Backports a moral equivalent of 2015 fix to the poll emulation from - the upstream gnulib to fix occasional breakages on HPE NonStop. - - * In the "--format=..." option of the "git for-each-ref" command (and - its friends, i.e. the listing mode of "git branch/tag"), "%(atom:)" - (e.g. "%(refname:)", "%(body:)" used to error out. Instead, treat - them as if the colon and an empty string that follows it were not - there. - - * Users with "color.ui = always" in their configuration were broken - by a recent change that made plumbing commands to pay attention to - them as the patch created internally by "git add -p" were colored - (heh) and made unusable. This has been fixed. - - * "git branch -M a b" while on a branch that is completely unrelated - to either branch a or branch b misbehaved when multiple worktree - was in use. This has been fixed. - - * "git fast-export" with -M/-C option issued "copy" instruction on a - path that is simultaneously modified, which was incorrect. - - * The checkpoint command "git fast-import" did not flush updates to - refs and marks unless at least one object was created since the - last checkpoint, which has been corrected, as these things can - happen without any new object getting created. - - * The scripts to drive TravisCI has been reorganized and then an - optimization to avoid spending cycles on a branch whose tip is - tagged has been implemented. - - * "git fetch <there> <src>:<dst>" allows an object name on the <src> - side when the other side accepts such a request since Git v2.5, but - the documentation was left stale. - - * A regression in 2.11 that made the code to read the list of - alternate object stores overrun the end of the string has been - fixed. - -Also contains various documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.14.4.txt b/third_party/git/Documentation/RelNotes/2.14.4.txt deleted file mode 100644 index 97755a89d9..0000000000 --- a/third_party/git/Documentation/RelNotes/2.14.4.txt +++ /dev/null @@ -1,5 +0,0 @@ -Git v2.14.4 Release Notes -========================= - -This release is to forward-port the fixes made in the v2.13.7 version -of Git. See its release notes for details. diff --git a/third_party/git/Documentation/RelNotes/2.14.5.txt b/third_party/git/Documentation/RelNotes/2.14.5.txt deleted file mode 100644 index 130645fb29..0000000000 --- a/third_party/git/Documentation/RelNotes/2.14.5.txt +++ /dev/null @@ -1,16 +0,0 @@ -Git v2.14.5 Release Notes -========================= - -This release is to address the recently reported CVE-2018-17456. - -Fixes since v2.14.4 -------------------- - - * Submodules' "URL"s come from the untrusted .gitmodules file, but - we blindly gave it to "git clone" to clone submodules when "git - clone --recurse-submodules" was used to clone a project that has - such a submodule. The code has been hardened to reject such - malformed URLs (e.g. one that begins with a dash). - -Credit for finding and fixing this vulnerability goes to joernchen -and Jeff King, respectively. diff --git a/third_party/git/Documentation/RelNotes/2.15.0.txt b/third_party/git/Documentation/RelNotes/2.15.0.txt deleted file mode 100644 index cdd761bcc2..0000000000 --- a/third_party/git/Documentation/RelNotes/2.15.0.txt +++ /dev/null @@ -1,508 +0,0 @@ -Git 2.15 Release Notes -====================== - -Backward compatibility notes and other notable changes. - - * Use of an empty string as a pathspec element that is used for - 'everything matches' is still warned and Git 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. That is now scheduled to happen in Git v2.16, - the next major release after this one. - - * Git now avoids blindly falling back to ".git" when the setup - sequence said we are _not_ in Git repository. A corner case that - happens to work right now may be broken by a call to BUG(). - We've tried hard to locate such cases and fixed them, but there - might still be cases that need to be addressed--bug reports are - greatly appreciated. - - * "branch --set-upstream" that has been deprecated in Git 1.8 has - finally been retired. - - -Updates since v2.14 -------------------- - -UI, Workflows & Features - - * An example that is now obsolete has been removed from a sample hook, - and an old example in it that added a sign-off manually has been - improved to use the interpret-trailers command. - - * The advice message given when "git rebase" stops for conflicting - changes has been improved. - - * The "rerere-train" script (in contrib/) learned the "--overwrite" - option to allow overwriting existing recorded resolutions. - - * "git contacts" (in contrib/) now lists the address on the - "Reported-by:" trailer to its output, in addition to those on - S-o-b: and other trailers, to make it easier to notify (and thank) - the original bug reporter. - - * "git rebase", especially when it is run by mistake and ends up - trying to replay many changes, spent long time in silence. The - command has been taught to show progress report when it spends - long time preparing these many changes to replay (which would give - the user a chance to abort with ^C). - - * "git merge" learned a "--signoff" option to add the Signed-off-by: - trailer with the committer's name. - - * "git diff" learned to optionally paint new lines that are the same - as deleted lines elsewhere differently from genuinely new lines. - - * "git interpret-trailers" learned to take the trailer specifications - from the command line that overrides the configured values. - - * "git interpret-trailers" has been taught a "--parse" and a few - other options to make it easier for scripts to grab existing - trailer lines from a commit log message. - - * The "--format=%(trailers)" option "git log" and its friends take - learned to take the 'unfold' and 'only' modifiers to normalize its - output, e.g. "git log --format=%(trailers:only,unfold)". - - * "gitweb" shows a link to visit the 'raw' contents of blobs in the - history overview page. - - * "[gc] rerereResolved = 5.days" used to be invalid, as the variable - is defined to take an integer counting the number of days. It now - is allowed. - - * The code to acquire a lock on a reference (e.g. while accepting a - push from a client) used to immediately fail when the reference is - already locked---now it waits for a very short while and retries, - which can make it succeed if the lock holder was holding it during - a read-only operation. - - * "branch --set-upstream" that has been deprecated in Git 1.8 has - finally been retired. - - * The codepath to call external process filter for smudge/clean - operation learned to show the progress meter. - - * "git rev-parse" learned "--is-shallow-repository", that is to be - used in a way similar to existing "--is-bare-repository" and - friends. - - * "git describe --match <pattern>" has been taught to play well with - the "--all" option. - - * "git branch" learned "-c/-C" to create a new branch by copying an - existing one. - - * Some commands (most notably "git status") makes an opportunistic - update when performing a read-only operation to help optimize later - operations in the same repository. The new "--no-optional-locks" - option can be passed to Git to disable them. - - * "git for-each-ref --format=..." learned a new format element, - %(trailers), to show only the commit log trailer part of the log - message. - - -Performance, Internal Implementation, Development Support etc. - - * Conversion from uchar[20] to struct object_id continues. - - * Start using selected c99 constructs in small, stable and - essential part of the system to catch people who care about - older compilers that do not grok them. - - * The filter-process interface learned to allow a process with long - latency give a "delayed" response. - - * Many uses of comparison callback function the hashmap API uses - cast the callback function type when registering it to - hashmap_init(), which defeats the compile time type checking when - the callback interface changes (e.g. gaining more parameters). - The callback implementations have been updated to take "void *" - pointers and cast them to the type they expect instead. - - * Because recent Git for Windows do come with a real msgfmt, the - build procedure for git-gui has been updated to use it instead of a - hand-rolled substitute. - - * "git grep --recurse-submodules" has been reworked to give a more - consistent output across submodule boundary (and do its thing - without having to fork a separate process). - - * A helper function to read a single whole line into strbuf - mistakenly triggered OOM error at EOF under certain conditions, - which has been fixed. - - * The "ref-store" code reorganization continues. - - * "git commit" used to discard the index and re-read from the filesystem - just in case the pre-commit hook has updated it in the middle; this - has been optimized out when we know we do not run the pre-commit hook. - (merge 680ee550d7 kw/commit-keep-index-when-pre-commit-is-not-run later to maint). - - * Updates to the HTTP layer we made recently unconditionally used - features of libCurl without checking the existence of them, causing - compilation errors, which has been fixed. Also migrate the code to - check feature macros, not version numbers, to cope better with - libCurl that vendor ships with backported features. - - * The API to start showing progress meter after a short delay has - been simplified. - (merge 8aade107dd jc/simplify-progress later to maint). - - * Code clean-up to avoid mixing values read from the .gitmodules file - and values read from the .git/config file. - - * We used to spend more than necessary cycles allocating and freeing - piece of memory while writing each index entry out. This has been - optimized. - - * Platforms that ship with a separate sha1 with collision detection - library can link to it instead of using the copy we ship as part of - our source tree. - - * Code around "notes" have been cleaned up. - (merge 3964281524 mh/notes-cleanup later to maint). - - * The long-standing rule that an in-core lockfile instance, once it - is used, must not be freed, has been lifted and the lockfile and - tempfile APIs have been updated to reduce the chance of programming - errors. - - * Our hashmap implementation in hashmap.[ch] is not thread-safe when - adding a new item needs to expand the hashtable by rehashing; add - an API to disable the automatic rehashing to work it around. - - * Many of our programs consider that it is OK to release dynamic - storage that is used throughout the life of the program by simply - exiting, but this makes it harder to leak detection tools to avoid - reporting false positives. Plug many existing leaks and introduce - a mechanism for developers to mark that the region of memory - pointed by a pointer is not lost/leaking to help these tools. - - * As "git commit" to conclude a conflicted "git merge" honors the - commit-msg hook, "git merge" that records a merge commit that - cleanly auto-merges should, but it didn't. - - * The codepath for "git merge-recursive" has been cleaned up. - - * Many leaks of strbuf have been fixed. - - * "git imap-send" has our own implementation of the protocol and also - can use more recent libCurl with the imap protocol support. Update - the latter so that it can use the credential subsystem, and then - make it the default option to use, so that we can eventually - deprecate and remove the former. - - * "make style" runs git-clang-format to help developers by pointing - out coding style issues. - - * A test to demonstrate "git mv" failing to adjust nested submodules - has been added. - (merge c514167df2 hv/mv-nested-submodules-test later to maint). - - * On Cygwin, "ulimit -s" does not report failure but it does not work - at all, which causes an unexpected success of some tests that - expect failures under a limited stack situation. This has been - fixed. - - * Many codepaths have been updated to squelch -Wimplicit-fallthrough - warnings from Gcc 7 (which is a good code hygiene). - - * Add a helper for DLL loading in anticipation for its need in a - future topic RSN. - - * "git status --ignored", when noticing that a directory without any - tracked path is ignored, still enumerated all the ignored paths in - the directory, which is unnecessary. The codepath has been - optimized to avoid this overhead. - - * The final batch to "git rebase -i" updates to move more code from - the shell script to C has been merged. - - * Operations that do not touch (majority of) packed refs have been - optimized by making accesses to packed-refs file lazy; we no longer - pre-parse everything, and an access to a single ref in the - packed-refs does not touch majority of irrelevant refs, either. - - * Add comment to clarify that the style file is meant to be used with - clang-5 and the rules are still work in progress. - - * Many variables that points at a region of memory that will live - throughout the life of the program have been marked with UNLEAK - marker to help the leak checkers concentrate on real leaks.. - - * Plans for weaning us off of SHA-1 has been documented. - - * A new "oidmap" API has been introduced and oidset API has been - rewritten to use it. - - -Also contains various documentation updates and code clean-ups. - - -Fixes since v2.14 ------------------ - - * "%C(color name)" in the pretty print format always produced ANSI - color escape codes, which was an early design mistake. They now - honor the configuration (e.g. "color.ui = never") and also tty-ness - of the output medium. - - * The http.{sslkey,sslCert} configuration variables are to be - interpreted as a pathname that honors "~[username]/" prefix, but - weren't, which has been fixed. - - * Numerous bugs in walking of reflogs via "log -g" and friends have - been fixed. - - * "git commit" when seeing an totally empty message said "you did not - edit the message", which is clearly wrong. The message has been - corrected. - - * When a directory is not readable, "gitweb" fails to build the - project list. Work this around by skipping such a directory. - - * Some versions of GnuPG fails to kill gpg-agent it auto-spawned - and such a left-over agent can interfere with a test. Work it - around by attempting to kill one before starting a new test. - - * A recently added test for the "credential-cache" helper revealed - that EOF detection done around the time the connection to the cache - daemon is torn down were flaky. This was fixed by reacting to - ECONNRESET and behaving as if we got an EOF. - - * "git log --tag=no-such-tag" showed log starting from HEAD, which - has been fixed---it now shows nothing. - - * The "tag.pager" configuration variable was useless for those who - actually create tag objects, as it interfered with the use of an - editor. A new mechanism has been introduced for commands to enable - pager depending on what operation is being carried out to fix this, - and then "git tag -l" is made to run pager by default. - - * "git push --recurse-submodules $there HEAD:$target" was not - propagated down to the submodules, but now it is. - - * Commands like "git rebase" accepted the --rerere-autoupdate option - from the command line, but did not always use it. This has been - fixed. - - * "git clone --recurse-submodules --quiet" did not pass the quiet - option down to submodules. - - * Test portability fix for OBSD. - - * Portability fix for OBSD. - - * "git am -s" has been taught that some input may end with a trailer - block that is not Signed-off-by: and it should refrain from adding - an extra blank line before adding a new sign-off in such a case. - - * "git svn" used with "--localtime" option did not compute the tz - offset for the timestamp in question and instead always used the - current time, which has been corrected. - - * Memory leak in an error codepath has been plugged. - - * "git stash -u" used the contents of the committed version of the - ".gitignore" file to decide which paths are ignored, even when the - file has local changes. The command has been taught to instead use - the locally modified contents. - - * bash 4.4 or newer gave a warning on NUL byte in command - substitution done in "git stash"; this has been squelched. - - * "git grep -L" and "git grep --quiet -L" reported different exit - codes; this has been corrected. - - * When handshake with a subprocess filter notices that the process - asked for an unknown capability, Git did not report what program - the offending subprocess was running. This has been corrected. - - * "git apply" that is used as a better "patch -p1" failed to apply a - taken from a file with CRLF line endings to a file with CRLF line - endings. The root cause was because it misused convert_to_git() - that tried to do "safe-crlf" processing by looking at the index - entry at the same path, which is a nonsense---in that mode, "apply" - is not working on the data in (or derived from) the index at all. - This has been fixed. - - * Killing "git merge --edit" before the editor returns control left - the repository in a state with MERGE_MSG but without MERGE_HEAD, - which incorrectly tells the subsequent "git commit" that there was - a squash merge in progress. This has been fixed. - - * "git archive" did not work well with pathspecs and the - export-ignore attribute. - - * In addition to "cc: <a@dd.re.ss> # cruft", "cc: a@dd.re.ss # cruft" - was taught to "git send-email" as a valid way to tell it that it - needs to also send a carbon copy to <a@dd.re.ss> in the trailer - section. - - * "git branch -M a b" while on a branch that is completely unrelated - to either branch a or branch b misbehaved when multiple worktree - was in use. This has been fixed. - (merge 31824d180d nd/worktree-kill-parse-ref later to maint). - - * "git gc" and friends when multiple worktrees are used off of a - single repository did not consider the index and per-worktree refs - of other worktrees as the root for reachability traversal, making - objects that are in use only in other worktrees to be subject to - garbage collection. - - * A regression to "gitk --bisect" by a recent update has been fixed. - - * "git -c submodule.recurse=yes pull" did not work as if the - "--recurse-submodules" option was given from the command line. - This has been corrected. - - * Unlike "git commit-tree < file", "git commit-tree -F file" did not - pass the contents of the file verbatim and instead completed an - incomplete line at the end, if exists. The latter has been updated - to match the behaviour of the former. - - * Many codepaths did not diagnose write failures correctly when disks - go full, due to their misuse of write_in_full() helper function, - which have been corrected. - (merge f48ecd38cb jk/write-in-full-fix later to maint). - - * "git help co" now says "co is aliased to ...", not "git co is". - (merge b3a8076e0d ks/help-alias-label later to maint). - - * "git archive", especially when used with pathspec, stored an empty - directory in its output, even though Git itself never does so. - This has been fixed. - - * API error-proofing which happens to also squelch warnings from GCC. - - * The explanation of the cut-line in the commit log editor has been - slightly tweaked. - (merge 8c4b1a3593 ks/commit-do-not-touch-cut-line later to maint). - - * "git gc" tries to avoid running two instances at the same time by - reading and writing pid/host from and to a lock file; it used to - use an incorrect fscanf() format when reading, which has been - corrected. - - * The scripts to drive TravisCI has been reorganized and then an - optimization to avoid spending cycles on a branch whose tip is - tagged has been implemented. - (merge 8376eb4a8f ls/travis-scriptify later to maint). - - * The test linter has been taught that we do not like "echo -e". - - * Code cmp.std.c nitpick. - - * A regression fix for 2.11 that made the code to read the list of - alternate object stores overrun the end of the string. - (merge f0f7bebef7 jk/info-alternates-fix later to maint). - - * "git describe --match" learned to take multiple patterns in v2.13 - series, but the feature ignored the patterns after the first one - and did not work at all. This has been fixed. - - * "git filter-branch" cannot reproduce a history with a tag without - the tagger field, which only ancient versions of Git allowed to be - created. This has been corrected. - (merge b2c1ca6b4b ic/fix-filter-branch-to-handle-tag-without-tagger later to maint). - - * "git cat-file --textconv" started segfaulting recently, which - has been corrected. - - * The built-in pattern to detect the "function header" for HTML did - not match <H1>..<H6> elements without any attributes, which has - been fixed. - - * "git mailinfo" was loose in decoding quoted printable and produced - garbage when the two letters after the equal sign are not - hexadecimal. This has been fixed. - - * The machinery to create xdelta used in pack files received the - sizes of the data in size_t, but lost the higher bits of them by - storing them in "unsigned int" during the computation, which is - fixed. - - * The delta format used in the packfile cannot reference data at - offset larger than what can be expressed in 4-byte, but the - generator for the data failed to make sure the offset does not - overflow. This has been corrected. - - * The documentation for '-X<option>' for merges was misleadingly - written to suggest that "-s theirs" exists, which is not the case. - - * "git fast-export" with -M/-C option issued "copy" instruction on a - path that is simultaneously modified, which was incorrect. - (merge b3e8ca89cf jt/fast-export-copy-modify-fix later to maint). - - * Many codepaths have been updated to squelch -Wsign-compare - warnings. - (merge 071bcaab64 rj/no-sign-compare later to maint). - - * Memory leaks in various codepaths have been plugged. - (merge 4d01a7fa65 ma/leakplugs later to maint). - - * Recent versions of "git rev-parse --parseopt" did not parse the - option specification that does not have the optional flags (*=?!) - correctly, which has been corrected. - (merge a6304fa4c2 bc/rev-parse-parseopt-fix later to maint). - - * The checkpoint command "git fast-import" did not flush updates to - refs and marks unless at least one object was created since the - last checkpoint, which has been corrected, as these things can - happen without any new object getting created. - (merge 30e215a65c er/fast-import-dump-refs-on-checkpoint later to maint). - - * Spell the name of our system as "Git" in the output from - request-pull script. - - * Fixes for a handful memory access issues identified by valgrind. - - * Backports a moral equivalent of 2015 fix to the poll() emulation - from the upstream gnulib to fix occasional breakages on HPE NonStop. - - * Users with "color.ui = always" in their configuration were broken - by a recent change that made plumbing commands to pay attention to - them as the patch created internally by "git add -p" were colored - (heh) and made unusable. This has been fixed by reverting the - offending change. - - * In the "--format=..." option of the "git for-each-ref" command (and - its friends, i.e. the listing mode of "git branch/tag"), "%(atom:)" - (e.g. "%(refname:)", "%(body:)" used to error out. Instead, treat - them as if the colon and an empty string that follows it were not - there. - - * An ancient bug that made Git misbehave with creation/renaming of - refs has been fixed. - - * "git fetch <there> <src>:<dst>" allows an object name on the <src> - side when the other side accepts such a request since Git v2.5, but - the documentation was left stale. - (merge 83558a412a jc/fetch-refspec-doc-update later to maint). - - * Update the documentation for "git filter-branch" so that the filter - options are listed in the same order as they are applied, as - described in an earlier part of the doc. - (merge 07c4984508 dg/filter-branch-filter-order-doc later to maint). - - * A possible oom error is now caught as a fatal error, instead of - continuing and dereferencing NULL. - (merge 55d7d15847 ao/path-use-xmalloc later to maint). - - * Other minor doc, test and build updates and code cleanups. - (merge f094b89a4d ma/parse-maybe-bool later to maint). - (merge 6cdf8a7929 ma/ts-cleanups later to maint). - (merge 7560f547e6 ma/up-to-date later to maint). - (merge 0db3dc75f3 rs/apply-epoch later to maint). - (merge 276d0e35c0 ma/split-symref-update-fix later to maint). - (merge f777623514 ks/branch-tweak-error-message-for-extra-args later to maint). - (merge 33f3c683ec ks/verify-filename-non-option-error-message-tweak later to maint). - (merge 7cbbf9d6a2 ls/filter-process-delayed later to maint). - (merge 488aa65c8f wk/merge-options-gpg-sign-doc later to maint). - (merge e61cb19a27 jc/branch-force-doc-readability-fix later to maint). - (merge 32fceba3fd np/config-path-doc later to maint). - (merge e38c681fb7 sb/rev-parse-show-superproject-root later to maint). - (merge 4f851dc883 sg/rev-list-doc-reorder-fix later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.15.1.txt b/third_party/git/Documentation/RelNotes/2.15.1.txt deleted file mode 100644 index ec06704e63..0000000000 --- a/third_party/git/Documentation/RelNotes/2.15.1.txt +++ /dev/null @@ -1,88 +0,0 @@ -Git v2.15.1 Release Notes -========================= - -Fixes since v2.15 ------------------ - - * TravisCI build updates. - - * "auto" as a value for the columnar output configuration ought to - judge "is the output consumed by humans?" with the same criteria as - "auto" for coloured output configuration, i.e. either the standard - output stream is going to tty, or a pager is in use. We forgot the - latter, which has been fixed. - - * The experimental "color moved lines differently in diff output" - feature was buggy around "ignore whitespace changes" edges, which - has been corrected. - - * Instead of using custom line comparison and hashing functions to - implement "moved lines" coloring in the diff output, use the pair - of these functions from lower-layer xdiff/ code. - - * Some codepaths did not check for errors when asking what branch the - HEAD points at, which have been fixed. - - * "git commit", after making a commit, did not check for errors when - asking on what branch it made the commit, which has been corrected. - - * "git status --ignored -u" did not stop at a working tree of a - separate project that is embedded in an ignored directory and - listed files in that other project, instead of just showing the - directory itself as ignored. - - * A broken access to object databases in recent update to "git grep - --recurse-submodules" has been fixed. - - * A recent regression in "git rebase -i" that broke execution of git - commands from subdirectories via "exec" instruction has been fixed. - - * "git check-ref-format --branch @{-1}" bit a "BUG()" when run - outside a repository for obvious reasons; clarify the documentation - and make sure we do not even try to expand the at-mark magic in - such a case, but still call the validation logic for branch names. - - * Command line completion (in contrib/) update. - - * Description of blame.{showroot,blankboundary,showemail,date} - configuration variables have been added to "git config --help". - - * After an error from lstat(), diff_populate_filespec() function - sometimes still went ahead and used invalid data in struct stat, - which has been fixed. - - * UNC paths are also relevant in Cygwin builds and they are now - tested just like Mingw builds. - - * Correct start-up sequence so that a repository could be placed - immediately under the root directory again (which was broken at - around Git 2.13). - - * The credential helper for libsecret (in contrib/) has been improved - to allow possibly prompting the end user to unlock secrets that are - currently locked (otherwise the secrets may not be loaded). - - * Updates from GfW project. - - * "git rebase -i" recently started misbehaving when a submodule that - is configured with 'submodule.<name>.ignore' is dirty; this has - been corrected. - - * Some error messages did not quote filenames shown in it, which have - been fixed. - - * Building with NO_LIBPCRE1_JIT did not disable it, which has been fixed. - - * We used to add an empty alternate object database to the system - that does not help anything; it has been corrected. - - * Error checking in "git imap-send" for empty response has been - improved. - - * An ancient bug in "git apply --ignore-space-change" codepath has - been fixed. - - * There was a recent semantic mismerge in the codepath to write out a - section of a configuration section, which has been corrected. - -Also contains various documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.15.2.txt b/third_party/git/Documentation/RelNotes/2.15.2.txt deleted file mode 100644 index b480e56b68..0000000000 --- a/third_party/git/Documentation/RelNotes/2.15.2.txt +++ /dev/null @@ -1,50 +0,0 @@ -Git v2.15.2 Release Notes -========================= - -Fixes since v2.15.1 -------------------- - - * Recent update to the refs infrastructure implementation started - rewriting packed-refs file more often than before; this has been - optimized again for most trivial cases. - - * The SubmittingPatches document has been converted to produce an - HTML version via AsciiDoc/Asciidoctor. - - * Contrary to the documentation, "git pull -4/-6 other-args" did not - ask the underlying "git fetch" to go over IPv4/IPv6, which has been - corrected. - - * When "git rebase" prepared an mailbox of changes and fed it to "git - am" to replay them, it was confused when a stray "From " happened - to be in the log message of one of the replayed changes. This has - been corrected. - - * Command line completion (in contrib/) has been taught about the - "--copy" option of "git branch". - - * "git apply --inaccurate-eof" when used with "--ignore-space-change" - triggered an internal sanity check, which has been fixed. - - * The sequencer machinery (used by "git cherry-pick A..B", and "git - rebase -i", among other things) would have lost a commit if stopped - due to an unlockable index file, which has been fixed. - - * The three-way merge performed by "git cherry-pick" was confused - when a new submodule was added in the meantime, which has been - fixed (or "papered over"). - - * "git notes" sent its error message to its standard output stream, - which was corrected. - - * A few scripts (both in production and tests) incorrectly redirected - their error output. These have been corrected. - - * Clarify and enhance documentation for "merge-base --fork-point", as - it was clear what it computed but not why/what for. - - * This release also contains the fixes made in the v2.13.7 version of - Git. See its release notes for details. - - -Also contains various documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.15.3.txt b/third_party/git/Documentation/RelNotes/2.15.3.txt deleted file mode 100644 index fd2e6f8df7..0000000000 --- a/third_party/git/Documentation/RelNotes/2.15.3.txt +++ /dev/null @@ -1,6 +0,0 @@ -Git v2.15.3 Release Notes -========================= - -This release merges up the fixes that appear in v2.14.5 to address -the recently reported CVE-2018-17456; see the release notes for that -version for details. diff --git a/third_party/git/Documentation/RelNotes/2.16.0.txt b/third_party/git/Documentation/RelNotes/2.16.0.txt deleted file mode 100644 index 0c81c5915f..0000000000 --- a/third_party/git/Documentation/RelNotes/2.16.0.txt +++ /dev/null @@ -1,482 +0,0 @@ -Git 2.16 Release Notes -====================== - -Backward compatibility notes and other notable changes. - - * Use of an empty string as a pathspec element that is used for - 'everything matches' is now an error. - - -Updates since v2.15 -------------------- - -UI, Workflows & Features - - * An empty string as a pathspec element that means "everything" - i.e. 'git add ""', is now illegal. We started this by first - deprecating and warning a pathspec that has such an element in - 2.11 (Nov 2016). - - * A hook script that is set unexecutable is simply ignored. Git - notifies when such a file is ignored, unless the message is - squelched via advice.ignoredHook configuration. - - * "git pull" has been taught to accept "--[no-]signoff" option and - pass it down to "git merge". - - * The "--push-option=<string>" option to "git push" now defaults to a - list of strings configured via push.pushOption variable. - - * "gitweb" checks if a directory is searchable with Perl's "-x" - operator, which can be enhanced by using "filetest 'access'" - pragma, which now we do. - - * "git stash save" has been deprecated in favour of "git stash push". - - * The set of paths output from "git status --ignored" was tied - closely with its "--untracked=<mode>" option, but now it can be - controlled more flexibly. Most notably, a directory that is - ignored because it is listed to be ignored in the ignore/exclude - mechanism can be handled differently from a directory that ends up - to be ignored only because all files in it are ignored. - - * The remote-helper for talking to MediaWiki has been updated to - truncate an overlong pagename so that ".mw" suffix can still be - added. - - * The remote-helper for talking to MediaWiki has been updated to - work with mediawiki namespaces. - - * The "--format=..." option "git for-each-ref" takes learned to show - the name of the 'remote' repository and the ref at the remote side - that is affected for 'upstream' and 'push' via "%(push:remotename)" - and friends. - - * Doc and message updates to teach users "bisect view" is a synonym - for "bisect visualize". - - * "git bisect run" that did not specify any command to run used to go - ahead and treated all commits to be tested as 'good'. This has - been corrected by making the command error out. - - * The SubmittingPatches document has been converted to produce an - HTML version via AsciiDoc/Asciidoctor. - - * We learned to optionally talk to a file system monitor via new - fsmonitor extension to speed up "git status" and other operations - that need to see which paths have been modified. Currently we only - support "watchman". See File System Monitor section of - git-update-index(1) for more detail. - - * The "diff" family of commands learned to ignore differences in - carriage return at the end of line. - - * Places that know about "sendemail.to", like documentation and shell - completion (in contrib/) have been taught about "sendemail.tocmd", - too. - - * "git add --renormalize ." is a new and safer way to record the fact - that you are correcting the end-of-line convention and other - "convert_to_git()" glitches in the in-repository data. - - * "git branch" and "git checkout -b" are now forbidden from creating - a branch whose name is "HEAD". - - * "git branch --list" learned to show its output through the pager by - default when the output is going to a terminal, which is controlled - by the pager.branch configuration variable. This is similar to a - recent change to "git tag --list". - - * "git grep -W", "git diff -W" and their friends learned a heuristic - to extend a pre-context beyond the line that matches the "function - pattern" (aka "diff.*.xfuncname") to include a comment block, if - exists, that immediately precedes it. - - * "git config --expiry-date gc.reflogexpire" can read "2.weeks" from - the configuration and report it as a timestamp, just like "--int" - would read "1k" and report 1024, to help consumption by scripts. - - * The shell completion (in contrib/) learned that "git pull" can take - the "--autostash" option. - - * The tagnames "git log --decorate" uses to annotate the commits can - now be limited to subset of available refs with the two additional - options, --decorate-refs[-exclude]=<pattern>. - - * "git grep" compiled with libpcre2 sometimes triggered a segfault, - which is being fixed. - - * "git send-email" tries to see if the sendmail program is available - in /usr/lib and /usr/sbin; extend the list of locations to be - checked to also include directories on $PATH. - - * "git diff" learned, "--anchored", a variant of the "--patience" - algorithm, to which the user can specify which 'unique' line to be - used as anchoring points. - - * The way "git worktree add" determines what branch to create from - where and checkout in the new worktree has been updated a bit. - - * Ancient part of codebase still shows dots after an abbreviated - object name just to show that it is not a full object name, but - these ellipses are confusing to people who newly discovered Git - who are used to seeing abbreviated object names and find them - confusing with the range syntax. - - * With a configuration variable rebase.abbreviateCommands set, - "git rebase -i" produces the todo list with a single-letter - command names. - - * "git worktree add" learned to run the post-checkout hook, just like - "git checkout" does, after the initial checkout. - - * "git svn" has been updated to strip CRs in the commit messages, as - recent versions of Subversion rejects them. - - * "git imap-send" did not correctly quote the folder name when - making a request to the server, which has been corrected. - - * Error messages from "git rebase" have been somewhat cleaned up. - - * Git has been taught to support an https:// URL used for http.proxy - when using recent versions of libcurl. - - * "git merge" learned to pay attention to merge.verifySignatures - configuration variable and pretend as if '--verify-signatures' - option was given from the command line. - - * "git describe" was taught to dig trees deeper to find a - <commit-ish>:<path> that refers to a given blob object. - - -Performance, Internal Implementation, Development Support etc. - - * An earlier update made it possible to use an on-stack in-core - lockfile structure (as opposed to having to deliberately leak an - on-heap one). Many codepaths have been updated to take advantage - of this new facility. - - * Calling cmd_foo() as if it is a general purpose helper function is - a no-no. Correct two instances of such to set an example. - - * We try to see if somebody runs our test suite with a shell that - does not support "local" like bash/dash does. - - * An early part of piece-by-piece rewrite of "git bisect" in C. - - * GSoC to piece-by-piece rewrite "git submodule" in C. - - * Optimize the code to find shortest unique prefix of object names. - - * Pathspec-limited revision traversal was taught not to keep finding - unneeded differences once it knows two trees are different inside - given pathspec. - - * Conversion from uchar[20] to struct object_id continues. - - * Code cleanup. - - * A single-word "unsigned flags" in the diff options is being split - into a structure with many bitfields. - - * TravisCI build updates. - - * Parts of a test to drive the long-running content filter interface - has been split into its own module, hopefully to eventually become - reusable. - - * Drop (perhaps overly cautious) sanity check before using the index - read from the filesystem at runtime. - - * The build procedure has been taught to avoid some unnecessary - instability in the build products. - - * A new mechanism to upgrade the wire protocol in place is proposed - and demonstrated that it works with the older versions of Git - without harming them. - - * An infrastructure to define what hash function is used in Git is - introduced, and an effort to plumb that throughout various - codepaths has been started. - - * The code to iterate over loose object files got optimized. - - * An internal function that was left for backward compatibility has - been removed, as there is no remaining callers. - - * Historically, the diff machinery for rename detection had a - hardcoded limit of 32k paths; this is being lifted to allow users - trade cycles with a (possibly) easier to read result. - - * The tracing infrastructure has been optimized for cases where no - tracing is requested. - - * In preparation for implementing narrow/partial clone, the object - walking machinery has been taught a way to tell it to "filter" some - objects from enumeration. - - * A few structures and variables that are implementation details of - the decorate API have been renamed and then the API got documented - better. - - * Assorted updates for TravisCI integration. - (merge 4f26366679 sg/travis-fixes later to maint). - - * Introduce a helper to simplify code to parse a common pattern that - expects either "--key" or "--key=<something>". - - * "git version --build-options" learned to report the host CPU and - the exact commit object name the binary was built from. - -Also contains various documentation updates and code clean-ups. - - -Fixes since v2.15 ------------------ - - * "auto" as a value for the columnar output configuration ought to - judge "is the output consumed by humans?" with the same criteria as - "auto" for coloured output configuration, i.e. either the standard - output stream is going to tty, or a pager is in use. We forgot the - latter, which has been fixed. - - * The experimental "color moved lines differently in diff output" - feature was buggy around "ignore whitespace changes" edges, which - has been corrected. - - * Instead of using custom line comparison and hashing functions to - implement "moved lines" coloring in the diff output, use the pair - of these functions from lower-layer xdiff/ code. - - * Some codepaths did not check for errors when asking what branch the - HEAD points at, which have been fixed. - - * "git commit", after making a commit, did not check for errors when - asking on what branch it made the commit, which has been corrected. - - * "git status --ignored -u" did not stop at a working tree of a - separate project that is embedded in an ignored directory and - listed files in that other project, instead of just showing the - directory itself as ignored. - - * A broken access to object databases in recent update to "git grep - --recurse-submodules" has been fixed. - - * A recent regression in "git rebase -i" that broke execution of git - commands from subdirectories via "exec" instruction has been fixed. - - * A (possibly flakey) test fix. - - * "git check-ref-format --branch @{-1}" bit a "BUG()" when run - outside a repository for obvious reasons; clarify the documentation - and make sure we do not even try to expand the at-mark magic in - such a case, but still call the validation logic for branch names. - - * "git fetch --recurse-submodules" now knows that submodules can be - moved around in the superproject in addition to getting updated, - and finds the ones that need to be fetched accordingly. - - * Command line completion (in contrib/) update. - - * Description of blame.{showroot,blankboundary,showemail,date} - configuration variables have been added to "git config --help". - - * After an error from lstat(), diff_populate_filespec() function - sometimes still went ahead and used invalid data in struct stat, - which has been fixed. - - * UNC paths are also relevant in Cygwin builds and they are now - tested just like Mingw builds. - - * Correct start-up sequence so that a repository could be placed - immediately under the root directory again (which was broken at - around Git 2.13). - - * The credential helper for libsecret (in contrib/) has been improved - to allow possibly prompting the end user to unlock secrets that are - currently locked (otherwise the secrets may not be loaded). - - * MinGW updates. - - * Error checking in "git imap-send" for empty response has been - improved. - - * Recent update to the refs infrastructure implementation started - rewriting packed-refs file more often than before; this has been - optimized again for most trivial cases. - - * Some error messages did not quote filenames shown in it, which have - been fixed. - - * "git rebase -i" recently started misbehaving when a submodule that - is configured with 'submodule.<name>.ignore' is dirty; this has - been corrected. - - * Building with NO_LIBPCRE1_JIT did not disable it, which has been fixed. - - * We used to add an empty alternate object database to the system - that does not help anything; it has been corrected. - - * Doc update around use of "format-patch --subject-prefix" etc. - - * A fix for an ancient bug in "git apply --ignore-space-change" codepath. - - * Clarify and enhance documentation for "merge-base --fork-point", as - it was clear what it computed but not why/what for. - - * A few scripts (both in production and tests) incorrectly redirected - their error output. These have been corrected. - - * "git notes" sent its error message to its standard output stream, - which was corrected. - - * The three-way merge performed by "git cherry-pick" was confused - when a new submodule was added in the meantime, which has been - fixed (or "papered over"). - - * The sequencer machinery (used by "git cherry-pick A..B", and "git - rebase -i", among other things) would have lost a commit if stopped - due to an unlockable index file, which has been fixed. - - * "git apply --inaccurate-eof" when used with "--ignore-space-change" - triggered an internal sanity check, which has been fixed. - - * Command line completion (in contrib/) has been taught about the - "--copy" option of "git branch". - - * When "git rebase" prepared a mailbox of changes and fed it to "git - am" to replay them, it was confused when a stray "From " happened - to be in the log message of one of the replayed changes. This has - been corrected. - - * There was a recent semantic mismerge in the codepath to write out a - section of a configuration section, which has been corrected. - - * Mentions of "git-rebase" and "git-am" (dashed form) still remained - in end-user visible strings emitted by the "git rebase" command; - they have been corrected. - - * Contrary to the documentation, "git pull -4/-6 other-args" did not - ask the underlying "git fetch" to go over IPv4/IPv6, which has been - corrected. - - * "git checkout --recursive" may overwrite and rewind the history of - the branch that happens to be checked out in submodule - repositories, which might not be desirable. Detach the HEAD but - still allow the recursive checkout to succeed in such a case. - (merge 57f22bf997 sb/submodule-recursive-checkout-detach-head later to maint). - - * "git branch --set-upstream" has been deprecated and (sort of) - removed, as "--set-upstream-to" is the preferred one these days. - The documentation still had "--set-upstream" listed on its - synopsis section, which has been corrected. - (merge a060f3d3d8 tz/branch-doc-remove-set-upstream later to maint). - - * Internally we use 0{40} as a placeholder object name to signal the - codepath that there is no such object (e.g. the fast-forward check - while "git fetch" stores a new remote-tracking ref says "we know - there is no 'old' thing pointed at by the ref, as we are creating - it anew" by passing 0{40} for the 'old' side), and expect that a - codepath to locate an in-core object to return NULL as a sign that - the object does not exist. A look-up for an object that does not - exist however is quite costly with a repository with large number - of packfiles. This access pattern has been optimized. - (merge 87b5e236a1 jk/fewer-pack-rescan later to maint). - - * In addition to "git stash -m message", the command learned to - accept "git stash -mmessage" form. - (merge 5675473fcb ph/stash-save-m-option-fix later to maint). - - * @{-N} in "git checkout @{-N}" may refer to a detached HEAD state, - but the documentation was not clear about it, which has been fixed. - (merge 75ce149575 ks/doc-checkout-previous later to maint). - - * A regression in the progress eye-candy was fixed. - (merge 9c5951cacf jk/progress-delay-fix later to maint). - - * The code internal to the recursive merge strategy was not fully - prepared to see a path that is renamed to try overwriting another - path that is only different in case on case insensitive systems. - This does not matter in the current code, but will start to matter - once the rename detection logic starts taking hints from nearby - paths moving to some directory and moves a new path along with them. - (merge 4cba2b0108 en/merge-recursive-icase-removal later to maint). - - * An v2.12-era regression in pathspec match logic, which made it look - into submodule tree even when it is not desired, has been fixed. - (merge eef3df5a93 bw/pathspec-match-submodule-boundary later to maint). - - * Amending commits in git-gui broke the author name that is non-ascii - due to incorrect enconding conversion. - - * Recent update to the submodule configuration code broke "diff-tree" - by accidentally stopping to read from the index upfront. - (merge fd66bcc31f bw/submodule-config-cleanup later to maint). - - * Git shows a message to tell the user that it is waiting for the - user to finish editing when spawning an editor, in case the editor - opens to a hidden window or somewhere obscure and the user gets - lost. - (merge abfb04d0c7 ls/editor-waiting-message later to maint). - - * The "safe crlf" check incorrectly triggered for contents that does - not use CRLF as line endings, which has been corrected. - (merge 649f1f0948 tb/check-crlf-for-safe-crlf later to maint). - - * "git clone --shared" to borrow from a (secondary) worktree did not - work, even though "git clone --local" did. Both are now accepted. - (merge b3b05971c1 es/clone-shared-worktree later to maint). - - * The build procedure now allows not just the repositories but also - the refs to be used to take pre-formatted manpages and html - documents to install. - (merge 65289e9dcd rb/quick-install-doc later to maint). - - * Update the shell prompt script (in contrib/) to strip trailing CR - from strings read from various "state" files. - (merge 041fe8fc83 ra/prompt-eread-fix later to maint). - - * "git merge -s recursive" did not correctly abort when the index is - dirty, if the merged tree happened to be the same as the current - HEAD, which has been fixed. - - * Bytes with high-bit set were encoded incorrectly and made - credential helper fail. - (merge 4c267f2ae3 jd/fix-strbuf-add-urlencode-bytes later to maint). - - * "git rebase -p -X<option>" did not propagate the option properly - down to underlying merge strategy backend. - (merge dd6fb0053c js/fix-merge-arg-quoting-in-rebase-p later to maint). - - * "git merge -s recursive" did not correctly abort when the index is - dirty, if the merged tree happened to be the same as the current - HEAD, which has been fixed. - (merge f309e8e768 ew/empty-merge-with-dirty-index-maint later to maint). - - * Other minor doc, test and build updates and code cleanups. - (merge 1a1fc2d5b5 rd/man-prune-progress later to maint). - (merge 0ba014035a rd/man-reflog-add-n later to maint). - (merge e54b63359f rd/doc-notes-prune-fix later to maint). - (merge ff4c9b413a sp/doc-info-attributes later to maint). - (merge 7db2cbf4f1 jc/receive-pack-hook-doc later to maint). - (merge 5a0526264b tg/t-readme-updates later to maint). - (merge 5e83cca0b8 jk/no-optional-locks later to maint). - (merge 826c778f7c js/hashmap-update-sample later to maint). - (merge 176b2d328c sg/setup-doc-update later to maint). - (merge 1b09073514 rs/am-builtin-leakfix later to maint). - (merge addcf6cfde rs/fmt-merge-msg-string-leak-fix later to maint). - (merge c3ff8f6c14 rs/strbuf-read-once-reset-length later to maint). - (merge 6b0eb884f9 db/doc-workflows-neuter-the-maintainer later to maint). - (merge 8c87bdfb21 jk/cvsimport-quoting later to maint). - (merge 176cb979fe rs/fmt-merge-msg-leakfix later to maint). - (merge 5a03360e73 tb/delimit-pretty-trailers-args-with-comma later to maint). - (merge d0e6326026 ot/pretty later to maint). - (merge 44103f4197 sb/test-helper-excludes later to maint). - (merge 170078693f jt/transport-no-more-rsync later to maint). - (merge c07b3adff1 bw/path-doc later to maint). - (merge bf9d7df950 tz/lib-git-svn-svnserve-tests later to maint). - (merge dec366c9a8 sr/http-sslverify-config-doc later to maint). - (merge 3f824e91c8 jk/test-suite-tracing later to maint). - (merge 1feb061701 db/doc-config-section-names-with-bs later to maint). - (merge 74dea0e13c jh/memihash-opt later to maint). - (merge 2e9fdc795c ma/bisect-leakfix later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.16.1.txt b/third_party/git/Documentation/RelNotes/2.16.1.txt deleted file mode 100644 index 66e64361fd..0000000000 --- a/third_party/git/Documentation/RelNotes/2.16.1.txt +++ /dev/null @@ -1,11 +0,0 @@ -Git v2.16.1 Release Notes -========================= - -Fixes since v2.16 ------------------ - - * "git clone" segfaulted when cloning a project that happens to - track two paths that differ only in case on a case insensitive - filesystem. - -Does not contain any other documentation updates or code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.16.2.txt b/third_party/git/Documentation/RelNotes/2.16.2.txt deleted file mode 100644 index a216466d3d..0000000000 --- a/third_party/git/Documentation/RelNotes/2.16.2.txt +++ /dev/null @@ -1,30 +0,0 @@ -Git v2.16.2 Release Notes -========================= - -Fixes since v2.16.1 -------------------- - - * An old regression in "git describe --all $annotated_tag^0" has been - fixed. - - * "git svn dcommit" did not take into account the fact that a - svn+ssh:// URL with a username@ (typically used for pushing) refers - to the same SVN repository without the username@ and failed when - svn.pushmergeinfo option is set. - - * "git merge -Xours/-Xtheirs" learned to use our/their version when - resolving a conflicting updates to a symbolic link. - - * "git clone $there $here" is allowed even when here directory exists - as long as it is an empty directory, but the command incorrectly - removed it upon a failure of the operation. - - * "git stash -- <pathspec>" incorrectly blew away untracked files in - the directory that matched the pathspec, which has been corrected. - - * "git add -p" was taught to ignore local changes to submodules as - they do not interfere with the partial addition of regular changes - anyway. - - -Also contains various documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.16.3.txt b/third_party/git/Documentation/RelNotes/2.16.3.txt deleted file mode 100644 index 64a0bcb0d2..0000000000 --- a/third_party/git/Documentation/RelNotes/2.16.3.txt +++ /dev/null @@ -1,49 +0,0 @@ -Git v2.16.3 Release Notes -========================= - -Fixes since v2.16.2 -------------------- - - * "git status" after moving a path in the working tree (hence making - it appear "removed") and then adding with the -N option (hence - making that appear "added") detected it as a rename, but did not - report the old and new pathnames correctly. - - * "git commit --fixup" did not allow "-m<message>" option to be used - at the same time; allow it to annotate resulting commit with more - text. - - * When resetting the working tree files recursively, the working tree - of submodules are now also reset to match. - - * Fix for a commented-out code to adjust it to a rather old API change - around object ID. - - * When there are too many changed paths, "git diff" showed a warning - message but in the middle of a line. - - * The http tracing code, often used to debug connection issues, - learned to redact potentially sensitive information from its output - so that it can be more safely sharable. - - * Crash fix for a corner case where an error codepath tried to unlock - what it did not acquire lock on. - - * The split-index mode had a few corner case bugs fixed. - - * Assorted fixes to "git daemon". - - * Completion of "git merge -s<strategy>" (in contrib/) did not work - well in non-C locale. - - * Workaround for segfault with more recent versions of SVN. - - * Recently introduced leaks in fsck have been plugged. - - * Travis CI integration now builds the executable in 'script' phase - to follow the established practice, rather than during - 'before_script' phase. This allows the CI categorize the failures - better ('failed' is project's fault, 'errored' is build - environment's). - -Also contains various documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.16.4.txt b/third_party/git/Documentation/RelNotes/2.16.4.txt deleted file mode 100644 index 6be538ba30..0000000000 --- a/third_party/git/Documentation/RelNotes/2.16.4.txt +++ /dev/null @@ -1,5 +0,0 @@ -Git v2.16.4 Release Notes -========================= - -This release is to forward-port the fixes made in the v2.13.7 version -of Git. See its release notes for details. diff --git a/third_party/git/Documentation/RelNotes/2.16.5.txt b/third_party/git/Documentation/RelNotes/2.16.5.txt deleted file mode 100644 index cb8ee02a9a..0000000000 --- a/third_party/git/Documentation/RelNotes/2.16.5.txt +++ /dev/null @@ -1,6 +0,0 @@ -Git v2.16.5 Release Notes -========================= - -This release merges up the fixes that appear in v2.14.5 to address -the recently reported CVE-2018-17456; see the release notes for that -version for details. diff --git a/third_party/git/Documentation/RelNotes/2.17.0.txt b/third_party/git/Documentation/RelNotes/2.17.0.txt deleted file mode 100644 index c2cf891f71..0000000000 --- a/third_party/git/Documentation/RelNotes/2.17.0.txt +++ /dev/null @@ -1,398 +0,0 @@ -Git 2.17 Release Notes -====================== - -Updates since v2.16 -------------------- - -UI, Workflows & Features - - * "diff" family of commands learned "--find-object=<object-id>" option - to limit the findings to changes that involve the named object. - - * "git format-patch" learned to give 72-cols to diffstat, which is - consistent with other line length limits the subcommand uses for - its output meant for e-mails. - - * The log from "git daemon" can be redirected with a new option; one - relevant use case is to send the log to standard error (instead of - syslog) when running it from inetd. - - * "git rebase" learned to take "--allow-empty-message" option. - - * "git am" has learned the "--quit" option, in addition to the - existing "--abort" option; having the pair mirrors a few other - commands like "rebase" and "cherry-pick". - - * "git worktree add" learned to run the post-checkout hook, just like - "git clone" runs it upon the initial checkout. - - * "git tag" learned an explicit "--edit" option that allows the - message given via "-m" and "-F" to be further edited. - - * "git fetch --prune-tags" may be used as a handy short-hand for - getting rid of stale tags that are locally held. - - * The new "--show-current-patch" option gives an end-user facing way - to get the diff being applied when "git rebase" (and "git am") - stops with a conflict. - - * "git add -p" used to offer "/" (look for a matching hunk) as a - choice, even there was only one hunk, which has been corrected. - Also the single-key help is now given only for keys that are - enabled (e.g. help for '/' won't be shown when there is only one - hunk). - - * Since Git 1.7.9, "git merge" defaulted to --no-ff (i.e. even when - the side branch being merged is a descendant of the current commit, - create a merge commit instead of fast-forwarding) when merging a - tag object. This was appropriate default for integrators who pull - signed tags from their downstream contributors, but caused an - unnecessary merges when used by downstream contributors who - habitually "catch up" their topic branches with tagged releases - from the upstream. Update "git merge" to default to --no-ff only - when merging a tag object that does *not* sit at its usual place in - refs/tags/ hierarchy, and allow fast-forwarding otherwise, to - mitigate the problem. - - * "git status" can spend a lot of cycles to compute the relation - between the current branch and its upstream, which can now be - disabled with "--no-ahead-behind" option. - - * "git diff" and friends learned funcname patterns for Go language - source files. - - * "git send-email" learned "--reply-to=<address>" option. - - * Funcname pattern used for C# now recognizes "async" keyword. - - * In a way similar to how "git tag" learned to honor the pager - setting only in the list mode, "git config" learned to ignore the - pager setting when it is used for setting values (i.e. when the - purpose of the operation is not to "show"). - - -Performance, Internal Implementation, Development Support etc. - - * More perf tests for threaded grep - - * "perf" test output can be sent to codespeed server. - - * The build procedure for perl/ part has been greatly simplified by - weaning ourselves off of MakeMaker. - - * Perl 5.8 or greater has been required since Git 1.7.4 released in - 2010, but we continued to assume some core modules may not exist and - used a conditional "eval { require <<module>> }"; we no longer do - this. Some platforms (Fedora/RedHat/CentOS, for example) ship Perl - without all core modules by default (e.g. Digest::MD5, File::Temp, - File::Spec, Net::Domain, Net::SMTP). Users on such platforms may - need to install these additional modules. - - * As a convenience, we install copies of Perl modules we require which - are not part of the core Perl distribution (e.g. Error and - Mail::Address). Users and packagers whose operating system provides - these modules can set NO_PERL_CPAN_FALLBACKS to avoid installing the - bundled modules. - - * In preparation for implementing narrow/partial clone, the machinery - for checking object connectivity used by gc and fsck has been - taught that a missing object is OK when it is referenced by a - packfile specially marked as coming from trusted repository that - promises to make them available on-demand and lazily. - - * The machinery to clone & fetch, which in turn involves packing and - unpacking objects, has been told how to omit certain objects using - the filtering mechanism introduced by another topic. It now knows - to mark the resulting pack as a promisor pack to tolerate missing - objects, laying foundation for "narrow" clones. - - * The first step to getting rid of mru API and using the - doubly-linked list API directly instead. - - * Retire mru API as it does not give enough abstraction over - underlying list API to be worth it. - - * Rewrite two more "git submodule" subcommands in C. - - * The tracing machinery learned to report tweaking of environment - variables as well. - - * Update Coccinelle rules to catch and optimize strbuf_addf(&buf, "%s", str) - - * Prevent "clang-format" from breaking line after function return type. - - * The sequencer infrastructure is shared across "git cherry-pick", - "git rebase -i", etc., and has always spawned "git commit" when it - needs to create a commit. It has been taught to do so internally, - when able, by reusing the codepath "git commit" itself uses, which - gives performance boost for a few tens of percents in some sample - scenarios. - - * Push the submodule version of collision-detecting SHA-1 hash - implementation a bit harder on builders. - - * Avoid mmapping small files while using packed refs (especially ones - with zero size, which would cause later munmap() to fail). - - * Conversion from uchar[20] to struct object_id continues. - - * More tests for wildmatch functions. - - * The code to binary search starting from a fan-out table (which is - how the packfile is indexed with object names) has been refactored - into a reusable helper. - - * We now avoid using identifiers that clash with C++ keywords. Even - though it is not a goal to compile Git with C++ compilers, changes - like this help use of code analysis tools that targets C++ on our - codebase. - - * The executable is now built in 'script' phase in Travis CI integration, - to follow the established practice, rather than during 'before_script' - phase. This allows the CI categorize the failures better ('failed' - is project's fault, 'errored' is build environment's). - (merge 3c93b82920 sg/travis-build-during-script-phase later to maint). - - * Writing out the index file when the only thing that changed in it - is the untracked cache information is often wasteful, and this has - been optimized out. - - * Various pieces of Perl code we have have been cleaned up. - - * Internal API clean-up to allow write_locked_index() optionally skip - writing the in-core index when it is not modified. - - -Also contains various documentation updates and code clean-ups. - - -Fixes since v2.16 ------------------ - - * An old regression in "git describe --all $annotated_tag^0" has been - fixed. - - * "git status" after moving a path in the working tree (hence making - it appear "removed") and then adding with the -N option (hence - making that appear "added") detected it as a rename, but did not - report the old and new pathnames correctly. - - * "git svn dcommit" did not take into account the fact that a - svn+ssh:// URL with a username@ (typically used for pushing) refers - to the same SVN repository without the username@ and failed when - svn.pushmergeinfo option is set. - - * API clean-up around revision traversal. - - * "git merge -Xours/-Xtheirs" learned to use our/their version when - resolving a conflicting updates to a symbolic link. - - * "git clone $there $here" is allowed even when here directory exists - as long as it is an empty directory, but the command incorrectly - removed it upon a failure of the operation. - - * "git commit --fixup" did not allow "-m<message>" option to be used - at the same time; allow it to annotate resulting commit with more - text. - - * When resetting the working tree files recursively, the working tree - of submodules are now also reset to match. - - * "git stash -- <pathspec>" incorrectly blew away untracked files in - the directory that matched the pathspec, which has been corrected. - - * Instead of maintaining home-grown email address parsing code, ship - a copy of reasonably recent Mail::Address to be used as a fallback - in 'git send-email' when the platform lacks it. - (merge d60be8acab mm/send-email-fallback-to-local-mail-address later to maint). - - * "git add -p" was taught to ignore local changes to submodules as - they do not interfere with the partial addition of regular changes - anyway. - - * Avoid showing a warning message in the middle of a line of "git - diff" output. - (merge 4e056c989f nd/diff-flush-before-warning later to maint). - - * The http tracing code, often used to debug connection issues, - learned to redact potentially sensitive information from its output - so that it can be more safely sharable. - (merge 8ba18e6fa4 jt/http-redact-cookies later to maint). - - * Crash fix for a corner case where an error codepath tried to unlock - what it did not acquire lock on. - (merge 81fcb698e0 mr/packed-ref-store-fix later to maint). - - * The split-index mode had a few corner case bugs fixed. - (merge ae59a4e44f tg/split-index-fixes later to maint). - - * Assorted fixes to "git daemon". - (merge ed15e58efe jk/daemon-fixes later to maint). - - * Completion of "git merge -s<strategy>" (in contrib/) did not work - well in non-C locale. - (merge 7cc763aaa3 nd/list-merge-strategy later to maint). - - * Workaround for segfault with more recent versions of SVN. - (merge 7f6f75e97a ew/svn-branch-segfault-fix later to maint). - - * Plug recently introduced leaks in fsck. - (merge ba3a08ca0e jt/fsck-code-cleanup later to maint). - - * "git pull --rebase" did not pass verbosity setting down when - recursing into a submodule. - (merge a56771a668 sb/pull-rebase-submodule later to maint). - - * The way "git reset --hard" reports the commit the updated HEAD - points at is made consistent with the way how the commit title is - generated by the other parts of the system. This matters when the - title is spread across physically multiple lines. - (merge 1cf823fb68 tg/reset-hard-show-head-with-pretty later to maint). - - * Test fixes. - (merge 63b1a175ee sg/test-i18ngrep later to maint). - - * Some bugs around "untracked cache" feature have been fixed. This - will notice corrupt data in the untracked cache left by old and - buggy code and issue a warning---the index can be fixed by clearing - the untracked cache from it. - (merge 0cacebf099 nd/fix-untracked-cache-invalidation later to maint). - (merge 7bf0be7501 ab/untracked-cache-invalidation-docs later to maint). - - * "git blame HEAD COPYING" in a bare repository failed to run, while - "git blame HEAD -- COPYING" run just fine. This has been corrected. - - * "git add" files in the same directory, but spelling the directory - path in different cases on case insensitive filesystem, corrupted - the name hash data structure and led to unexpected results. This - has been corrected. - (merge c95525e90d bp/name-hash-dirname-fix later to maint). - - * "git rebase -p" mangled log messages of a merge commit, which is - now fixed. - (merge ed5144d7eb js/fix-merge-arg-quoting-in-rebase-p later to maint). - - * Some low level protocol codepath could crash when they get an - unexpected flush packet, which is now fixed. - (merge bb1356dc64 js/packet-read-line-check-null later to maint). - - * "git check-ignore" with multiple paths got confused when one is a - file and the other is a directory, which has been fixed. - (merge d60771e930 rs/check-ignore-multi later to maint). - - * "git describe $garbage" stopped giving any errors when the garbage - happens to be a string with 40 hexadecimal letters. - (merge a8e7a2bf0f sb/describe-blob later to maint). - - * Code to unquote single-quoted string (used in the parser for - configuration files, etc.) did not diagnose bogus input correctly - and produced bogus results instead. - (merge ddbbf8eb25 jk/sq-dequote-on-bogus-input later to maint). - - * Many places in "git apply" knew that "/dev/null" that signals - "there is no such file on this side of the diff" can be followed by - whitespace and garbage when parsing a patch, except for one, which - made an otherwise valid patch (e.g. ones from subversion) rejected. - (merge e454ad4bec tk/apply-dev-null-verify-name-fix later to maint). - - * We no longer create any *.spec file, so "make clean" should not - remove it. - (merge 4321bdcabb tz/do-not-clean-spec-file later to maint). - - * "git push" over http transport did not unquote the push-options - correctly. - (merge 90dce21eb0 jk/push-options-via-transport-fix later to maint). - - * "git send-email" learned to complain when the batch-size option is - not defined when the relogin-delay option is, since these two are - mutually required. - (merge 9caa70697b xz/send-email-batch-size later to maint). - - * Y2k20 fix ;-) for our perl scripts. - (merge a40e06ee33 bw/perl-timegm-timelocal-fix later to maint). - - * Threaded "git grep" has been optimized to avoid allocation in code - section that is covered under a mutex. - (merge 38ef24dccf rv/grep-cleanup later to maint). - - * "git subtree" script (in contrib/) scripted around "git log", whose - output got affected by end-user configuration like log.showsignature - (merge 8841b5222c sg/subtree-signed-commits later to maint). - - * While finding unique object name abbreviation, the code may - accidentally have read beyond the end of the array of object names - in a pack. - (merge 21abed500c ds/find-unique-abbrev-optim later to maint). - - * Micro optimization in revision traversal code. - (merge ebbed3ba04 ds/mark-parents-uninteresting-optim later to maint). - - * "git commit" used to run "gc --auto" near the end, which was lost - when the command was reimplemented in C by mistake. - (merge 095c741edd ab/gc-auto-in-commit later to maint). - - * Allow running a couple of tests with "sh -x". - (merge c20bf94abc sg/cvs-tests-with-x later to maint). - - * The codepath to replace an existing entry in the index had a bug in - updating the name hash structure, which has been fixed. - (merge 0e267b7a24 bp/refresh-cache-ent-rehash-fix later to maint). - - * The transfer.fsckobjects configuration tells "git fetch" to - validate the data and connected-ness of objects in the received - pack; the code to perform this check has been taught about the - narrow clone's convention that missing objects that are reachable - from objects in a pack that came from a promisor remote is OK. - - * There was an unused file-scope static variable left in http.c when - building for versions of libCURL that is older than 7.19.4, which - has been fixed. - (merge b8fd6008ec rj/http-code-cleanup later to maint). - - * Shell script portability fix. - (merge 206a6ae013 ml/filter-branch-portability-fix later to maint). - - * Other minor doc, test and build updates and code cleanups. - (merge e2a5a028c7 bw/oidmap-autoinit later to maint). - (merge ec3b4b06f8 cl/t9001-cleanup later to maint). - (merge e1b3f3dd38 ks/submodule-doc-updates later to maint). - (merge fbac558a9b rs/describe-unique-abbrev later to maint). - (merge 8462ff43e4 tb/crlf-conv-flags later to maint). - (merge 7d68bb0766 rb/hashmap-h-compilation-fix later to maint). - (merge 3449847168 cc/sha1-file-name later to maint). - (merge ad622a256f ds/use-get-be64 later to maint). - (merge f919ffebed sg/cocci-move-array later to maint). - (merge 4e801463c7 jc/mailinfo-cleanup-fix later to maint). - (merge ef5b3a6c5e nd/shared-index-fix later to maint). - (merge 9f5258cbb8 tz/doc-show-defaults-to-head later to maint). - (merge b780e4407d jc/worktree-add-short-help later to maint). - (merge ae239fc8e5 rs/cocci-strbuf-addf-to-addstr later to maint). - (merge 2e22a85e5c nd/ignore-glob-doc-update later to maint). - (merge 3738031581 jk/gettext-poison later to maint). - (merge 54360a1956 rj/sparse-updates later to maint). - (merge 12e31a6b12 sg/doc-test-must-fail-args later to maint). - (merge 760f1ad101 bc/doc-interpret-trailers-grammofix later to maint). - (merge 4ccf461f56 bp/fsmonitor later to maint). - (merge a6119f82b1 jk/test-hashmap-updates later to maint). - (merge 5aea9fe6cc rd/typofix later to maint). - (merge e4e5da2796 sb/status-doc-fix later to maint). - (merge 7976e901c8 gs/test-unset-xdg-cache-home later to maint). - (merge d023df1ee6 tg/worktree-create-tracking later to maint). - (merge 4cbe92fd41 sm/mv-dry-run-update later to maint). - (merge 75e5e9c3f7 sb/color-h-cleanup later to maint). - (merge 2708ef4af6 sg/t6300-modernize later to maint). - (merge d88e92d4e0 bw/doc-submodule-recurse-config-with-clone later to maint). - (merge f74bbc8dd2 jk/cached-commit-buffer later to maint). - (merge 1316416903 ms/non-ascii-ticks later to maint). - (merge 878056005e rs/strbuf-read-file-or-whine later to maint). - (merge 79f0ba1547 jk/strbuf-read-file-close-error later to maint). - (merge edfb8ba068 ot/ref-filter-cleanup later to maint). - (merge 11395a3b4b jc/test-must-be-empty later to maint). - (merge 768b9d6db7 mk/doc-pretty-fill later to maint). - (merge 2caa7b8d27 ab/man-sec-list later to maint). - (merge 40c17eb184 ks/t3200-typofix later to maint). - (merge bd9958c358 dp/merge-strategy-doc-fix later to maint). - (merge 9ee0540a40 js/ming-strftime later to maint). - (merge 1775e990f7 tz/complete-tag-delete-tagname later to maint). - (merge 00a4b03501 rj/warning-uninitialized-fix later to maint). - (merge b635ed97a0 jk/attributes-path-doc later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.17.1.txt b/third_party/git/Documentation/RelNotes/2.17.1.txt deleted file mode 100644 index e01384fe8e..0000000000 --- a/third_party/git/Documentation/RelNotes/2.17.1.txt +++ /dev/null @@ -1,16 +0,0 @@ -Git v2.17.1 Release Notes -========================= - -Fixes since v2.17 ------------------ - - * This release contains the same fixes made in the v2.13.7 version of - Git, covering CVE-2018-11233 and 11235, and forward-ported to - v2.14.4, v2.15.2 and v2.16.4 releases. See release notes to - v2.13.7 for details. - - * In addition to the above fixes, this release has support on the - server side to reject pushes to repositories that attempt to create - such problematic .gitmodules file etc. as tracked contents, to help - hosting sites protect their customers by preventing malicious - contents from spreading. diff --git a/third_party/git/Documentation/RelNotes/2.17.2.txt b/third_party/git/Documentation/RelNotes/2.17.2.txt deleted file mode 100644 index ef021be870..0000000000 --- a/third_party/git/Documentation/RelNotes/2.17.2.txt +++ /dev/null @@ -1,12 +0,0 @@ -Git v2.17.2 Release Notes -========================= - -This release merges up the fixes that appear in v2.14.5 to address -the recently reported CVE-2018-17456; see the release notes for that -version for details. - -In addition, this release also teaches "fsck" and the server side -logic to reject pushes to repositories that attempt to create such a -problematic ".gitmodules" file as tracked contents, to help hosting -sites protect their customers by preventing malicious contents from -spreading. diff --git a/third_party/git/Documentation/RelNotes/2.18.0.txt b/third_party/git/Documentation/RelNotes/2.18.0.txt deleted file mode 100644 index 3ea280cf68..0000000000 --- a/third_party/git/Documentation/RelNotes/2.18.0.txt +++ /dev/null @@ -1,583 +0,0 @@ -Git 2.18 Release Notes -====================== - -Updates since v2.17 -------------------- - -UI, Workflows & Features - - * Rename detection logic that is used in "merge" and "cherry-pick" has - learned to guess when all of x/a, x/b and x/c have moved to z/a, - z/b and z/c, it is likely that x/d added in the meantime would also - want to move to z/d by taking the hint that the entire directory - 'x' moved to 'z'. A bug causing dirty files involved in a rename - to be overwritten during merge has also been fixed as part of this - work. Incidentally, this also avoids updating a file in the - working tree after a (non-trivial) merge whose result matches what - our side originally had. - - * "git filter-branch" learned to use a different exit code to allow - the callers to tell the case where there was no new commits to - rewrite from other error cases. - - * When built with more recent cURL, GIT_SSL_VERSION can now specify - "tlsv1.3" as its value. - - * "git gui" learned that "~/.ssh/id_ecdsa.pub" and - "~/.ssh/id_ed25519.pub" are also possible SSH key files. - (merge 2e2f0288ef bb/git-gui-ssh-key-files later to maint). - - * "git gui" performs commit upon CTRL/CMD+ENTER but the - CTRL/CMD+KP_ENTER (i.e. enter key on the numpad) did not have the - same key binding. It now does. - (merge 28a1d94a06 bp/git-gui-bind-kp-enter later to maint). - - * "git gui" has been taught to work with old versions of tk (like - 8.5.7) that do not support "ttk::style theme use" as a way to query - the current theme. - (merge 4891961105 cb/git-gui-ttk-style later to maint). - - * "git rebase" has learned to honor "--signoff" option when using - backends other than "am" (but not "--preserve-merges"). - - * "git branch --list" during an interrupted "rebase -i" now lets - users distinguish the case where a detached HEAD is being rebased - and a normal branch is being rebased. - - * "git mergetools" learned talking to guiffy. - - * The scripts in contrib/emacs/ have outlived their usefulness and - have been replaced with a stub that errors out and tells the user - there are replacements. - - * The new "working-tree-encoding" attribute can ask Git to convert the - contents to the specified encoding when checking out to the working - tree (and the other way around when checking in). - - * The "git config" command uses separate options e.g. "--int", - "--bool", etc. to specify what type the caller wants the value to - be interpreted as. A new "--type=<typename>" option has been - introduced, which would make it cleaner to define new types. - - * "git config --get" learned the "--default" option, to help the - calling script. Building on top of the above changes, the - "git config" learns "--type=color" type. Taken together, you can - do things like "git config --get foo.color --default blue" and get - the ANSI color sequence for the color given to foo.color variable, - or "blue" if the variable does not exist. - - * "git ls-remote" learned an option to allow sorting its output based - on the refnames being shown. - - * The command line completion (in contrib/) has been taught that "git - stash save" has been deprecated ("git stash push" is the preferred - spelling in the new world) and does not offer it as a possible - completion candidate when "git stash push" can be. - - * "git gc --prune=nonsense" spent long time repacking and then - silently failed when underlying "git prune --expire=nonsense" - failed to parse its command line. This has been corrected. - - * Error messages from "git push" can be painted for more visibility. - - * "git http-fetch" (deprecated) had an optional and experimental - "feature" to fetch only commits and/or trees, which nobody used. - This has been removed. - - * The functionality of "$GIT_DIR/info/grafts" has been superseded by - the "refs/replace/" mechanism for some time now, but the internal - code had support for it in many places, which has been cleaned up - in order to drop support of the "grafts" mechanism. - - * "git worktree add" learned to check out an existing branch. - - * "git --no-pager cmd" did not have short-and-sweet single letter - option. Now it does as "-P". - (merge 7213c28818 js/no-pager-shorthand later to maint). - - * "git rebase" learned "--rebase-merges" to transplant the whole - topology of commit graph elsewhere. - - * "git status" learned to pay attention to UI related diff - configuration variables such as diff.renames. - - * The command line completion mechanism (in contrib/) learned to load - custom completion file for "git $command" where $command is a - custom "git-$command" that the end user has on the $PATH when using - newer version of bash-completion. - - * "git send-email" can sometimes offer confirmation dialog "Send this - email?" with choices 'Yes', 'No', 'Quit', and 'All'. A new action - 'Edit' has been added to this dialog's choice. - - * With merge.renames configuration set to false, the recursive merge - strategy can be told not to spend cycles trying to find renamed - paths and merge them accordingly. - - * "git status" learned to honor a new status.renames configuration to - skip rename detection, which could be useful for those who want to - do so without disabling the default rename detection done by the - "git diff" command. - - * Command line completion (in contrib/) learned to complete pathnames - for various commands better. - - * "git blame" learns to unhighlight uninteresting metadata from the - originating commit on lines that are the same as the previous one, - and also paint lines in different colors depending on the age of - the commit. - - * Transfer protocol v2 learned to support the partial clone. - - * When a short hexadecimal string is used to name an object but there - are multiple objects that share the string as the prefix of their - names, the code lists these ambiguous candidates in a help message. - These object names are now sorted according to their types for - easier eyeballing. - - * "git fetch $there $refspec" that talks over protocol v2 can take - advantage of server-side ref filtering; the code has been extended - so that this mechanism triggers also when fetching with configured - refspec. - - * Our HTTP client code used to advertise that we accept gzip encoding - from the other side; instead, just let cURL library to advertise - and negotiate the best one. - - * "git p4" learned to "unshelve" shelved commit from P4. - (merge 123f631761 ld/p4-unshelve later to maint). - - -Performance, Internal Implementation, Development Support etc. - - * A "git fetch" from a repository with insane number of refs into a - repository that is already up-to-date still wasted too many cycles - making many lstat(2) calls to see if these objects at the tips - exist as loose objects locally. These lstat(2) calls are optimized - away by enumerating all loose objects beforehand. - It is unknown if the new strategy negatively affects existing use - cases, fetching into a repository with many loose objects from a - repository with small number of refs. - - * Git can be built to use either v1 or v2 of the PCRE library, and so - far, the build-time configuration USE_LIBPCRE=YesPlease instructed - the build procedure to use v1, but now it means v2. USE_LIBPCRE1 - and USE_LIBPCRE2 can be used to explicitly choose which version to - use, as before. - - * The build procedure learned to optionally use symbolic links - (instead of hardlinks and copies) to install "git-foo" for built-in - commands, whose binaries are all identical. - - * Conversion from uchar[20] to struct object_id continues. - - * The way "git worktree prune" worked internally has been simplified, - by assuming how "git worktree move" moves an existing worktree to a - different place. - - * Code clean-up for the "repository" abstraction. - (merge 00a3da2a13 nd/remove-ignore-env-field later to maint). - - * Code to find the length to uniquely abbreviate object names based - on packfile content, which is a relatively recent addtion, has been - optimized to use the same fan-out table. - - * The mechanism to use parse-options API to automate the command line - completion continues to get extended and polished. - - * Copies of old scripted Porcelain commands in contrib/examples/ have - been removed. - - * Some tests that rely on the exact hardcoded values of object names - have been updated in preparation for hash function migration. - - * Perf-test update. - - * Test helper update. - - * The effort continues to refactor the internal global data structure - to make it possible to open multiple repositories, work with and - then close them, - - * Small test-helper programs have been consolidated into a single - binary. - - * API clean-up around ref-filter code. - - * Shell completion (in contrib) that gives list of paths have been - optimized somewhat. - - * The index file is updated to record the fsmonitor section after a - full scan was made, to avoid wasting the effort that has already - spent. - - * Performance measuring framework in t/perf learned to help bisecting - performance regressions. - - * Some multi-word source filenames are being renamed to separate - words with dashes instead of underscores. - - * An reusable "memory pool" implementation has been extracted from - fast-import.c, which in turn has become the first user of the - mem-pool API. - - * A build-time option has been added to allow Git to be told to refer - to its associated files relative to the main binary, in the same - way that has been possible on Windows for quite some time, for - Linux, BSDs and Darwin. - - * Precompute and store information necessary for ancestry traversal - in a separate file to optimize graph walking. - - * The effort to pass the repository in-core structure throughout the - API continues. This round deals with the code that implements the - refs/replace/ mechanism. - - * The build procedure "make DEVELOPER=YesPlease" learned to enable a - bit more warning options depending on the compiler used to help - developers more. There also is "make DEVOPTS=tokens" knob - available now, for those who want to help fixing warnings we - usually ignore, for example. - - * A new version of the transport protocol is being worked on. - - * The code to interface to GPG has been restructured somewhat to make - it cleaner to integrate with other types of signature systems later. - - * The code has been taught to use the duplicated information stored - in the commit-graph file to learn the tree object name for a commit - to avoid opening and parsing the commit object when it makes sense - to do so. - - * "git gc" in a large repository takes a lot of time as it considers - to repack all objects into one pack by default. The command has - been taught to pretend as if the largest existing packfile is - marked with ".keep" so that it is left untouched while objects in - other packs and loose ones are repacked. - - * The transport protocol v2 is getting updated further. - - * The codepath around object-info API has been taught to take the - repository object (which in turn tells the API which object store - the objects are to be located). - - * "git pack-objects" needs to allocate tons of "struct object_entry" - while doing its work, and shrinking its size helps the performance - quite a bit. - - * The implementation of "git rebase -i --root" has been updated to use - the sequencer machinery more. - - * Developer support update, by using BUG() macro instead of die() to - mark codepaths that should not happen more clearly. - - * Developer support. Use newer GCC on one of the builds done at - TravisCI.org to get more warnings and errors diagnosed. - - * Conversion from uchar[20] to struct object_id continues. - - * By code restructuring of submodule merge in merge-recursive, - informational messages from the codepath are now given using the - same mechanism as other output, and honor the merge.verbosity - configuration. The code also learned to give a few new messages - when a submodule three-way merge resolves cleanly when one side - records a descendant of the commit chosen by the other side. - - * Avoid unchecked snprintf() to make future code auditing easier. - (merge ac4896f007 jk/snprintf-truncation later to maint). - - * Many tests hardcode the raw object names, which would change once - we migrate away from SHA-1. While some of them must test against - exact object names, most of them do not have to use hardcoded - constants in the test. The latter kind of tests have been updated - to test the moral equivalent of the original without hardcoding the - actual object names. - - * The list of commands with their various attributes were spread - across a few places in the build procedure, but it now is getting a - bit more consolidated to allow more automation. - - * Quite a many tests assumed that newly created refs are made as - loose refs using the files backend, which have been updated to use - proper plumbing like rev-parse and update-ref, to avoid breakage - once we start using different ref backends. - - -Also contains various documentation updates and code clean-ups. - - -Fixes since v2.17 ------------------ - - * "git shortlog cruft" aborted with a BUG message when run outside a - Git repository. The command has been taught to complain about - extra and unwanted arguments on its command line instead in such a - case. - (merge 4aa0161e83 ma/shortlog-revparse later to maint). - - * "git stash push -u -- <pathspec>" gave an unnecessary and confusing - error message when there was no tracked files that match the - <pathspec>, which has been fixed. - (merge 353278687e tg/stash-untracked-with-pathspec-fix later to maint). - - * "git tag --contains no-such-commit" gave a full list of options - after giving an error message. - (merge 3bb0923f06 ps/contains-id-error-message later to maint). - - * "diff-highlight" filter (in contrib/) learned to understand "git log - --graph" output better. - (merge 4551fbba14 jk/diff-highlight-graph-fix later to maint). - - * when refs that do not point at committish are given, "git - filter-branch" gave a misleading error messages. This has been - corrected. - (merge f78ab355e7 yk/filter-branch-non-committish-refs later to maint). - - * "git submodule status" misbehaved on a submodule that has been - removed from the working tree. - (merge 74b6bda32f rs/status-with-removed-submodule later to maint). - - * When credential helper exits very quickly without reading its - input, it used to cause Git to die with SIGPIPE, which has been - fixed. - (merge a0d51e8d0e eb/cred-helper-ignore-sigpipe later to maint). - - * "git rebase --keep-empty" still removed an empty commit if the - other side contained an empty commit (due to the "does an - equivalent patch exist already?" check), which has been corrected. - (merge 3d946165e1 pw/rebase-keep-empty-fixes later to maint). - - * Some codepaths, including the refs API, get and keep relative - paths, that go out of sync when the process does chdir(2). The - chdir-notify API is introduced to let these codepaths adjust these - cached paths to the new current directory. - (merge fb9c2d2703 jk/relative-directory-fix later to maint). - - * "cd sub/dir && git commit ../path" ought to record the changes to - the file "sub/path", but this regressed long time ago. - (merge 86238e07ef bw/commit-partial-from-subdirectory-fix later to maint). - - * Recent introduction of "--log-destination" option to "git daemon" - did not work well when the daemon was run under "--inetd" mode. - (merge e67d906d73 lw/daemon-log-destination later to maint). - - * Small fix to the autoconf build procedure. - (merge 249482daf0 es/fread-reads-dir-autoconf-fix later to maint). - - * Fix an unexploitable (because the oversized contents are not under - attacker's control) buffer overflow. - (merge d8579accfa bp/fsmonitor-bufsize-fix later to maint). - - * Recent simplification of build procedure forgot a bit of tweak to - the build procedure of contrib/mw-to-git/ - (merge d8698987f3 ab/simplify-perl-makefile later to maint). - - * Moving a submodule that itself has submodule in it with "git mv" - forgot to make necessary adjustment to the nested sub-submodules; - now the codepath learned to recurse into the submodules. - - * "git config --unset a.b", when "a.b" is the last variable in an - otherwise empty section "a", left an empty section "a" behind, and - worse yet, a subsequent "git config a.c value" did not reuse that - empty shell and instead created a new one. These have been - (partially) corrected. - (merge c71d8bb38a js/empty-config-section-fix later to maint). - - * "git worktree remove" learned that "-f" is a shorthand for - "--force" option, just like for "git worktree add". - (merge d228eea514 sb/worktree-remove-opt-force later to maint). - - * The completion script (in contrib/) learned to clear cached list of - command line options upon dot-sourcing it again in a more efficient - way. - (merge 94408dc71c sg/completion-clear-cached later to maint). - - * "git svn" had a minor thinko/typo which has been fixed. - (merge 51db271587 ab/git-svn-get-record-typofix later to maint). - - * During a "rebase -i" session, the code could give older timestamp - to commits created by later "pick" than an earlier "reword", which - has been corrected. - (merge 12f7babd6b js/ident-date-fix later to maint). - - * "git submodule status" did not check the symbolic revision name it - computed for the submodule HEAD is not the NULL, and threw it at - printf routines, which has been corrected. - (merge 0b5e2ea7cf nd/submodule-status-fix later to maint). - - * When fed input that already has In-Reply-To: and/or References: - headers and told to add the same information, "git send-email" - added these headers separately, instead of appending to an existing - one, which is a violation of the RFC. This has been corrected. - (merge 256be1d3f0 sa/send-email-dedup-some-headers later to maint). - - * "git fast-export" had a regression in v2.15.0 era where it skipped - some merge commits in certain cases, which has been corrected. - (merge be011bbe00 ma/fast-export-skip-merge-fix later to maint). - - * The code did not propagate the terminal width to subprocesses via - COLUMNS environment variable, which it now does. This caused - trouble to "git column" helper subprocess when "git tag --column=row" - tried to list the existing tags on a display with non-default width. - (merge b5d5a567fb nd/term-columns later to maint). - - * We learned that our source files with ".pl" and ".py" extensions - are Perl and Python files respectively and changes to them are - better viewed as such with appropriate diff drivers. - (merge 7818b619e2 ab/perl-python-attrs later to maint). - - * "git rebase -i" sometimes left intermediate "# This is a - combination of N commits" message meant for the human consumption - inside an editor in the final result in certain corner cases, which - has been fixed. - (merge 15ef69314d js/rebase-i-clean-msg-after-fixup-continue later to maint). - - * A test to see if the filesystem normalizes UTF-8 filename has been - updated to check what we need to know in a more direct way, i.e. a - path created in NFC form can be accessed with NFD form (or vice - versa) to cope with APFS as well as HFS. - (merge 742ae10e35 tb/test-apfs-utf8-normalization later to maint). - - * "git format-patch --cover --attach" created a broken MIME multipart - message for the cover letter, which has been fixed by keeping the - cover letter as plain text file. - (merge 50cd54ef4e bc/format-patch-cover-no-attach later to maint). - - * The split-index feature had a long-standing and dormant bug in - certain use of the in-core merge machinery, which has been fixed. - (merge 7db118303a en/unpack-trees-split-index-fix later to maint). - - * Asciidoctor gives a reasonable imitation for AsciiDoc, but does not - render illustration in a literal block correctly when indented with - HT by default. The problem is fixed by forcing 8-space tabs. - (merge 379805051d bc/asciidoctor-tab-width later to maint). - - * Code clean-up to adjust to a more recent lockfile API convention that - allows lockfile instances kept on the stack. - (merge 0fa5a2ed8d ma/lockfile-cleanup later to maint). - - * the_repository->index is not a allocated piece of memory but - repo_clear() indiscriminately attempted to free(3) it, which has - been corrected. - (merge 74373b5f10 nd/repo-clear-keep-the-index later to maint). - - * Code clean-up to avoid non-standard-conformant pointer arithmetic. - (merge c112084af9 rs/no-null-ptr-arith-in-fast-export later to maint). - - * Code clean-up to turn history traversal more robust in a - semi-corrupt repository. - (merge 8702b30fd7 jk/unavailable-can-be-missing later to maint). - - * "git update-ref A B" is supposed to ensure that ref A does not yet - exist when B is a NULL OID, but this check was not done correctly - for pseudo-refs outside refs/ hierarchy, e.g. MERGE_HEAD. - - * "git submodule update" and "git submodule add" supported the - "--reference" option to borrow objects from a neighbouring local - repository like "git clone" does, but lacked the more recent - invention "--dissociate". Also "git submodule add" has been taught - to take the "--progress" option. - (merge a0ef29341a cf/submodule-progress-dissociate later to maint). - - * Update credential-netrc helper (in contrib/) to allow customizing - the GPG used to decrypt the encrypted .netrc file. - (merge 786ef50a23 lm/credential-netrc later to maint). - - * "git submodule update" attempts two different kinds of "git fetch" - against the upstream repository to grab a commit bound at the - submodule's path, but it incorrectly gave up if the first kind - (i.e. a normal fetch) failed, making the second "last resort" one - (i.e. fetching an exact commit object by object name) ineffective. - This has been corrected. - (merge e30d833671 sb/submodule-update-try-harder later to maint). - - * Error behaviour of "git grep" when it cannot read the index was - inconsistent with other commands that uses the index, which has - been corrected to error out early. - (merge b2aa84c789 sb/grep-die-on-unreadable-index later to maint). - - * We used to call regfree() after regcomp() failed in some codepaths, - which have been corrected. - (merge 17154b1576 ma/regex-no-regfree-after-comp-fail later to maint). - - * The import-tars script (in contrib/) has been taught to handle - tarballs with overly long paths that use PAX extended headers. - (merge 12ecea46e3 pa/import-tars-long-names later to maint). - - * "git rev-parse Y..." etc. misbehaved when given endpoints were - not committishes. - (merge 0ed556d38f en/rev-parse-invalid-range later to maint). - - * "git pull --recurse-submodules --rebase", when the submodule - repository's history did not have anything common between ours and - the upstream's, failed to execute. We need to fetch from them to - continue even in such a case. - (merge 4d36f88be7 jt/submodule-pull-recurse-rebase later to maint). - - * "git remote update" can take both a single remote nickname and a - nickname for remote groups, but only one of them was documented. - (merge a97447a42a nd/remote-update-doc later to maint). - - * "index-pack --strict" has been taught to make sure that it runs the - final object integrity checks after making the freshly indexed - packfile available to itself. - (merge 3737746120 jk/index-pack-maint later to maint). - - * Make zlib inflate codepath more robust against versions of zlib - that clobber unused portion of outbuf. - (merge b611396e97 jl/zlib-restore-nul-termination later to maint). - - * Fix old merge glitch in Documentation during v2.13-rc0 era. - (merge 28cb06020b mw/doc-merge-enumfix later to maint). - - * The code to read compressed bitmap was not careful to avoid reading - past the end of the file, which has been corrected. - (merge 1140bf01ec jk/ewah-bounds-check later to maint). - - * "make NO_ICONV=NoThanks" did not override NEEDS_LIBICONV - (i.e. linkage of -lintl, -liconv, etc. that are platform-specific - tweaks), which has been corrected. - (merge fdb1fbbc7d es/make-no-iconv later to maint). - - * Other minor doc, test and build updates and code cleanups. - (merge 248f66ed8e nd/trace-with-env later to maint). - (merge 14ced5562c ys/bisect-object-id-missing-conversion-fix later to maint). - (merge 5988eb631a ab/doc-hash-brokenness later to maint). - (merge a4d4e32a70 pk/test-avoid-pipe-hiding-exit-status later to maint). - (merge 05e293c1ac jk/flockfile-stdio later to maint). - (merge e9184b0789 jk/t5561-missing-curl later to maint). - (merge b1801b85a3 nd/worktree-move later to maint). - (merge bbd374dd20 ak/bisect-doc-typofix later to maint). - (merge 4855f06fb3 mn/send-email-credential-doc later to maint). - (merge 8523b1e355 en/doc-typoes later to maint). - (merge 43b44ccfe7 js/t5404-path-fix later to maint). - (merge decf711fc1 ps/test-chmtime-get later to maint). - (merge 22d11a6e8e es/worktree-docs later to maint). - (merge 92a5dbbc22 tg/use-git-contacts later to maint). - (merge adc887221f tq/t1510 later to maint). - (merge bed21a8ad6 sg/doc-gc-quote-mismatch-fix later to maint). - (merge 73364e4f10 tz/doc-git-urls-reference later to maint). - (merge cd1e606bad bc/mailmap-self later to maint). - (merge f7997e3682 ao/config-api-doc later to maint). - (merge ee930754d8 jk/apply-p-doc later to maint). - (merge 011b648646 nd/pack-format-doc later to maint). - (merge 87a6bb701a sg/t5310-jgit-bitmap-test later to maint). - (merge f6b82970aa sg/t5516-fixes later to maint). - (merge 4362da078e sg/t7005-spaces-in-filenames-cleanup later to maint). - (merge 7d0ee47c11 js/test-unset-prereq later to maint). - (merge 5356a3c354 ah/misc-doc-updates later to maint). - (merge 92c4a7a129 nd/completion-aliasfiletype-typofix later to maint). - (merge 58bd77b66a nd/pack-unreachable-objects-doc later to maint). - (merge 4ed79d5203 sg/t6500-no-redirect-of-stdin later to maint). - (merge 17b8a2d6cd jk/config-blob-sans-repo later to maint). - (merge 590551ca2c rd/tag-doc-lightweight later to maint). - (merge 44f560fc16 rd/init-typo later to maint). - (merge f156a0934a rd/p4-doc-markup-env later to maint). - (merge 2a00502b14 tg/doc-sec-list later to maint). - (merge 47cc91310a jk/submodule-fsck-loose-fixup later to maint). - (merge efde7b725c rd/comment-typofix-in-sha1-file later to maint). - (merge 7eedad15df rd/diff-options-typofix later to maint). - (merge 58ebd936cc km/doc-workflows-typofix later to maint). - (merge 30aa96cdf8 rd/doc-remote-tracking-with-hyphen later to maint). - (merge cf317877e3 ks/branch-set-upstream later to maint). - (merge 8de19d6be8 sg/t7406-chain-fix later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.18.1.txt b/third_party/git/Documentation/RelNotes/2.18.1.txt deleted file mode 100644 index 2098cdd776..0000000000 --- a/third_party/git/Documentation/RelNotes/2.18.1.txt +++ /dev/null @@ -1,6 +0,0 @@ -Git v2.18.1 Release Notes -========================= - -This release merges up the fixes that appear in v2.14.5 and in -v2.17.2 to address the recently reported CVE-2018-17456; see the -release notes for those versions for details. diff --git a/third_party/git/Documentation/RelNotes/2.19.0.txt b/third_party/git/Documentation/RelNotes/2.19.0.txt deleted file mode 100644 index a06ccf6e2a..0000000000 --- a/third_party/git/Documentation/RelNotes/2.19.0.txt +++ /dev/null @@ -1,615 +0,0 @@ -Git 2.19 Release Notes -====================== - -Updates since v2.18 -------------------- - -UI, Workflows & Features - - * "git diff" compares the index and the working tree. For paths - added with intent-to-add bit, the command shows the full contents - of them as added, but the paths themselves were not marked as new - files. They are now shown as new by default. - - "git apply" learned the "--intent-to-add" option so that an - otherwise working-tree-only application of a patch will add new - paths to the index marked with the "intent-to-add" bit. - - * "git grep" learned the "--column" option that gives not just the - line number but the column number of the hit. - - * The "-l" option in "git branch -l" is an unfortunate short-hand for - "--create-reflog", but many users, both old and new, somehow expect - it to be something else, perhaps "--list". This step warns when "-l" - is used as a short-hand for "--create-reflog" and warns about the - future repurposing of the it when it is used. - - * The userdiff pattern for .php has been updated. - - * The content-transfer-encoding of the message "git send-email" sends - out by default was 8bit, which can cause trouble when there is an - overlong line to bust RFC 5322/2822 limit. A new option 'auto' to - automatically switch to quoted-printable when there is such a line - in the payload has been introduced and is made the default. - - * "git checkout" and "git worktree add" learned to honor - checkout.defaultRemote when auto-vivifying a local branch out of a - remote tracking branch in a repository with multiple remotes that - have tracking branches that share the same names. - (merge 8d7b558bae ab/checkout-default-remote later to maint). - - * "git grep" learned the "--only-matching" option. - - * "git rebase --rebase-merges" mode now handles octopus merges as - well. - - * Add a server-side knob to skip commits in exponential/fibbonacci - stride in an attempt to cover wider swath of history with a smaller - number of iterations, potentially accepting a larger packfile - transfer, instead of going back one commit a time during common - ancestor discovery during the "git fetch" transaction. - (merge 42cc7485a2 jt/fetch-negotiator-skipping later to maint). - - * A new configuration variable core.usereplacerefs has been added, - primarily to help server installations that want to ignore the - replace mechanism altogether. - - * Teach "git tag -s" etc. a few configuration variables (gpg.format - that can be set to "openpgp" or "x509", and gpg.<format>.program - that is used to specify what program to use to deal with the format) - to allow x.509 certs with CMS via "gpgsm" to be used instead of - openpgp via "gnupg". - - * Many more strings are prepared for l10n. - - * "git p4 submit" learns to ask its own pre-submit hook if it should - continue with submitting. - - * The test performed at the receiving end of "git push" to prevent - bad objects from entering repository can be customized via - receive.fsck.* configuration variables; we now have gained a - counterpart to do the same on the "git fetch" side, with - fetch.fsck.* configuration variables. - - * "git pull --rebase=interactive" learned "i" as a short-hand for - "interactive". - - * "git instaweb" has been adjusted to run better with newer Apache on - RedHat based distros. - - * "git range-diff" is a reimplementation of "git tbdiff" that lets us - compare individual patches in two iterations of a topic. - - * The sideband code learned to optionally paint selected keywords at - the beginning of incoming lines on the receiving end. - - * "git branch --list" learned to take the default sort order from the - 'branch.sort' configuration variable, just like "git tag --list" - pays attention to 'tag.sort'. - - * "git worktree" command learned "--quiet" option to make it less - verbose. - - -Performance, Internal Implementation, Development Support etc. - - * The bulk of "git submodule foreach" has been rewritten in C. - - * The in-core "commit" object had an all-purpose "void *util" field, - which was tricky to use especially in library-ish part of the - code. All of the existing uses of the field has been migrated to a - more dedicated "commit-slab" mechanism and the field is eliminated. - - * A less often used command "git show-index" has been modernized. - (merge fb3010c31f jk/show-index later to maint). - - * The conversion to pass "the_repository" and then "a_repository" - throughout the object access API continues. - - * Continuing with the idea to programatically enumerate various - pieces of data required for command line completion, teach the - codebase to report the list of configuration variables - subcommands care about to help complete them. - - * Separate "rebase -p" codepath out of "rebase -i" implementation to - slim down the latter and make it easier to manage. - - * Make refspec parsing codepath more robust. - - * Some flaky tests have been fixed. - - * Continuing with the idea to programmatically enumerate various - pieces of data required for command line completion, the codebase - has been taught to enumerate options prefixed with "--no-" to - negate them. - - * Build and test procedure for netrc credential helper (in contrib/) - has been updated. - - * Remove unused function definitions and declarations from ewah - bitmap subsystem. - - * Code preparation to make "git p4" closer to be usable with Python 3. - - * Tighten the API to make it harder to misuse in-tree .gitmodules - file, even though it shares the same syntax with configuration - files, to read random configuration items from it. - - * "git fast-import" has been updated to avoid attempting to create - delta against a zero-byte-long string, which is pointless. - - * The codebase has been updated to compile cleanly with -pedantic - option. - (merge 2b647a05d7 bb/pedantic later to maint). - - * The character display width table has been updated to match the - latest Unicode standard. - (merge 570951eea2 bb/unicode-11-width later to maint). - - * test-lint now looks for broken use of "VAR=VAL shell_func" in test - scripts. - - * Conversion from uchar[40] to struct object_id continues. - - * Recent "security fix" to pay attention to contents of ".gitmodules" - while accepting "git push" was a bit overly strict than necessary, - which has been adjusted. - - * "git fsck" learns to make sure the optional commit-graph file is in - a sane state. - - * "git diff --color-moved" feature has further been tweaked. - - * Code restructuring and a small fix to transport protocol v2 during - fetching. - - * Parsing of -L[<N>][,[<M>]] parameters "git blame" and "git log" - take has been tweaked. - - * lookup_commit_reference() and friends have been updated to find - in-core object for a specific in-core repository instance. - - * Various glitches in the heuristics of merge-recursive strategy have - been documented in new tests. - - * "git fetch" learned a new option "--negotiation-tip" to limit the - set of commits it tells the other end as "have", to reduce wasted - bandwidth and cycles, which would be helpful when the receiving - repository has a lot of refs that have little to do with the - history at the remote it is fetching from. - - * For a large tree, the index needs to hold many cache entries - allocated on heap. These cache entries are now allocated out of a - dedicated memory pool to amortize malloc(3) overhead. - - * Tests to cover various conflicting cases have been added for - merge-recursive. - - * Tests to cover conflict cases that involve submodules have been - added for merge-recursive. - - * Look for broken "&&" chains that are hidden in subshell, many of - which have been found and corrected. - - * The singleton commit-graph in-core instance is made per in-core - repository instance. - - * "make DEVELOPER=1 DEVOPTS=pedantic" allows developers to compile - with -pedantic option, which may catch more problematic program - constructs and potential bugs. - - * Preparatory code to later add json output for telemetry data has - been added. - - * Update the way we use Coccinelle to find out-of-style code that - need to be modernised. - - * It is too easy to misuse system API functions such as strcat(); - these selected functions are now forbidden in this codebase and - will cause a compilation failure. - - * Add a script (in contrib/) to help users of VSCode work better with - our codebase. - - * The Travis CI scripts were taught to ship back the test data from - failed tests. - (merge aea8879a6a sg/travis-retrieve-trash-upon-failure later to maint). - - * The parse-options machinery learned to refrain from enclosing - placeholder string inside a "<bra" and "ket>" pair automatically - without PARSE_OPT_LITERAL_ARGHELP. Existing help text for option - arguments that are not formatted correctly have been identified and - fixed. - (merge 5f0df44cd7 rs/parse-opt-lithelp later to maint). - - * Noiseword "extern" has been removed from function decls in the - header files. - - * A few atoms like %(objecttype) and %(objectsize) in the format - specifier of "for-each-ref --format=<format>" can be filled without - getting the full contents of the object, but just with the object - header. These cases have been optimized by calling - oid_object_info() API (instead of reading and inspecting the data). - - * The end result of documentation update has been made to be - inspected more easily to help developers. - - * The API to iterate over all objects learned to optionally list - objects in the order they appear in packfiles, which helps locality - of access if the caller accesses these objects while as objects are - enumerated. - - * Improve built-in facility to catch broken &&-chain in the tests. - - * The more library-ish parts of the codebase learned to work on the - in-core index-state instance that is passed in by their callers, - instead of always working on the singleton "the_index" instance. - - * A test prerequisite defined by various test scripts with slightly - different semantics has been consolidated into a single copy and - made into a lazily defined one. - (merge 6ec633059a wc/make-funnynames-shared-lazy-prereq later to maint). - - * After a partial clone, repeated fetches from promisor remote would - have accumulated many packfiles marked with .promisor bit without - getting them coalesced into fewer packfiles, hurting performance. - "git repack" now learned to repack them. - - * Partially revert the support for multiple hash functions to regain - hash comparison performance; we'd think of a way to do this better - in the next cycle. - - * "git help --config" (which is used in command line completion) - missed the configuration variables not described in the main - config.txt file but are described in another file that is included - by it, which has been corrected. - - * The test linter code has learned that the end of here-doc mark - "EOF" can be quoted in a double-quote pair, not just in a - single-quote pair. - - -Fixes since v2.18 ------------------ - - * "git remote update" can take both a single remote nickname and a - nickname for remote groups, and the completion script (in contrib/) - has been taught about it. - (merge 9cd4382ad5 ls/complete-remote-update-names later to maint). - - * "git fetch --shallow-since=<cutoff>" that specifies the cut-off - point that is newer than the existing history used to end up - grabbing the entire history. Such a request now errors out. - (merge e34de73c56 nd/reject-empty-shallow-request later to maint). - - * Fix for 2.17-era regression around `core.safecrlf`. - (merge 6cb09125be as/safecrlf-quiet-fix later to maint). - - * The recent addition of "partial clone" experimental feature kicked - in when it shouldn't, namely, when there is no partial-clone filter - defined even if extensions.partialclone is set. - (merge cac1137dc4 jh/partial-clone later to maint). - - * "git send-pack --signed" (hence "git push --signed" over the http - transport) did not read user ident from the config mechanism to - determine whom to sign the push certificate as, which has been - corrected. - (merge d067d98887 ms/send-pack-honor-config later to maint). - - * "git fetch-pack --all" used to unnecessarily fail upon seeing an - annotated tag that points at an object other than a commit. - (merge c12c9df527 jk/fetch-all-peeled-fix later to maint). - - * When user edits the patch in "git add -p" and the user's editor is - set to strip trailing whitespaces indiscriminately, an empty line - that is unchanged in the patch would become completely empty - (instead of a line with a sole SP on it). The code introduced in - Git 2.17 timeframe failed to parse such a patch, but now it learned - to notice the situation and cope with it. - (merge f4d35a6b49 pw/add-p-recount later to maint). - - * The code to try seeing if a fetch is necessary in a submodule - during a fetch with --recurse-submodules got confused when the path - to the submodule was changed in the range of commits in the - superproject, sometimes showing "(null)". This has been corrected. - - * Bugfix for "rebase -i" corner case regression. - (merge a9279c6785 pw/rebase-i-keep-reword-after-conflict later to maint). - - * Recently added "--base" option to "git format-patch" command did - not correctly generate prereq patch ids. - (merge 15b76c1fb3 xy/format-patch-prereq-patch-id-fix later to maint). - - * POSIX portability fix in Makefile to fix a glitch introduced a few - releases ago. - (merge 6600054e9b dj/runtime-prefix later to maint). - - * "git filter-branch" when used with the "--state-branch" option - still attempted to rewrite the commits whose filtered result is - known from the previous attempt (which is recorded on the state - branch); the command has been corrected not to waste cycles doing - so. - (merge 709cfe848a mb/filter-branch-optim later to maint). - - * Clarify that setting core.ignoreCase to deviate from reality would - not turn a case-incapable filesystem into a case-capable one. - (merge 48294b512a ms/core-icase-doc later to maint). - - * "fsck.skipList" did not prevent a blob object listed there from - being inspected for is contents (e.g. we recently started to - inspect the contents of ".gitmodules" for certain malicious - patterns), which has been corrected. - (merge fb16287719 rj/submodule-fsck-skip later to maint). - - * "git checkout --recurse-submodules another-branch" did not report - in which submodule it failed to update the working tree, which - resulted in an unhelpful error message. - (merge ba95d4e4bd sb/submodule-move-head-error-msg later to maint). - - * "git rebase" behaved slightly differently depending on which one of - the three backends gets used; this has been documented and an - effort to make them more uniform has begun. - (merge b00bf1c9a8 en/rebase-consistency later to maint). - - * The "--ignore-case" option of "git for-each-ref" (and its friends) - did not work correctly, which has been fixed. - (merge e674eb2528 jk/for-each-ref-icase later to maint). - - * "git fetch" failed to correctly validate the set of objects it - received when making a shallow history deeper, which has been - corrected. - (merge cf1e7c0770 jt/connectivity-check-after-unshallow later to maint). - - * Partial clone support of "git clone" has been updated to correctly - validate the objects it receives from the other side. The server - side has been corrected to send objects that are directly - requested, even if they may match the filtering criteria (e.g. when - doing a "lazy blob" partial clone). - (merge a7e67c11b8 jt/partial-clone-fsck-connectivity later to maint). - - * Handling of an empty range by "git cherry-pick" was inconsistent - depending on how the range ended up to be empty, which has been - corrected. - (merge c5e358d073 jk/empty-pick-fix later to maint). - - * "git reset --merge" (hence "git merge ---abort") and "git reset --hard" - had trouble working correctly in a sparsely checked out working - tree after a conflict, which has been corrected. - (merge b33fdfc34c mk/merge-in-sparse-checkout later to maint). - - * Correct a broken use of "VAR=VAL shell_func" in a test. - (merge 650161a277 jc/t3404-one-shot-export-fix later to maint). - - * "git rev-parse ':/substring'" did not consider the history leading - only to HEAD when looking for a commit with the given substring, - when the HEAD is detached. This has been fixed. - (merge 6b3351e799 wc/find-commit-with-pattern-on-detached-head later to maint). - - * Build doc update for Windows. - (merge ede8d89bb1 nd/command-list later to maint). - - * core.commentchar is now honored when preparing the list of commits - to replay in "rebase -i". - - * "git pull --rebase" on a corrupt HEAD caused a segfault. In - general we substitute an empty tree object when running the in-core - equivalent of the diff-index command, and the codepath has been - corrected to do so as well to fix this issue. - (merge 3506dc9445 jk/has-uncommitted-changes-fix later to maint). - - * httpd tests saw occasional breakage due to the way its access log - gets inspected by the tests, which has been updated to make them - less flaky. - (merge e8b3b2e275 sg/httpd-test-unflake later to maint). - - * Tests to cover more D/F conflict cases have been added for - merge-recursive. - - * "git gc --auto" opens file descriptors for the packfiles before - spawning "git repack/prune", which would upset Windows that does - not want a process to work on a file that is open by another - process. The issue has been worked around. - (merge 12e73a3ce4 kg/gc-auto-windows-workaround later to maint). - - * The recursive merge strategy did not properly ensure there was no - change between HEAD and the index before performing its operation, - which has been corrected. - (merge 55f39cf755 en/dirty-merge-fixes later to maint). - - * "git rebase" started exporting GIT_DIR environment variable and - exposing it to hook scripts when part of it got rewritten in C. - Instead of matching the old scripted Porcelains' behaviour, - compensate by also exporting GIT_WORK_TREE environment as well to - lessen the damage. This can harm existing hooks that want to - operate on different repository, but the current behaviour is - already broken for them anyway. - (merge ab5e67d751 bc/sequencer-export-work-tree-as-well later to maint). - - * "git send-email" when using in a batched mode that limits the - number of messages sent in a single SMTP session lost the contents - of the variable used to choose between tls/ssl, unable to send the - second and later batches, which has been fixed. - (merge 636f3d7ac5 jm/send-email-tls-auth-on-batch later to maint). - - * The lazy clone support had a few places where missing but promised - objects were not correctly tolerated, which have been fixed. - - * One of the "diff --color-moved" mode "dimmed_zebra" that was named - in an unusual way has been deprecated and replaced by - "dimmed-zebra". - (merge e3f2f5f9cd es/diff-color-moved-fix later to maint). - - * The wire-protocol v2 relies on the client to send "ref prefixes" to - limit the bandwidth spent on the initial ref advertisement. "git - clone" when learned to speak v2 forgot to do so, which has been - corrected. - (merge 402c47d939 bw/clone-ref-prefixes later to maint). - - * "git diff --histogram" had a bad memory usage pattern, which has - been rearranged to reduce the peak usage. - (merge 79cb2ebb92 sb/histogram-less-memory later to maint). - - * Code clean-up to use size_t/ssize_t when they are the right type. - (merge 7726d360b5 jk/size-t later to maint). - - * The wire-protocol v2 relies on the client to send "ref prefixes" to - limit the bandwidth spent on the initial ref advertisement. "git - fetch $remote branch:branch" that asks tags that point into the - history leading to the "branch" automatically followed sent to - narrow prefix and broke the tag following, which has been fixed. - (merge 2b554353a5 jt/tag-following-with-proto-v2-fix later to maint). - - * When the sparse checkout feature is in use, "git cherry-pick" and - other mergy operations lost the skip_worktree bit when a path that - is excluded from checkout requires content level merge, which is - resolved as the same as the HEAD version, without materializing the - merge result in the working tree, which made the path appear as - deleted. This has been corrected by preserving the skip_worktree - bit (and not materializing the file in the working tree). - (merge 2b75fb601c en/merge-recursive-skip-fix later to maint). - - * The "author-script" file "git rebase -i" creates got broken when - we started to move the command away from shell script, which is - getting fixed now. - (merge 5522bbac20 es/rebase-i-author-script-fix later to maint). - - * The automatic tree-matching in "git merge -s subtree" was broken 5 - years ago and nobody has noticed since then, which is now fixed. - (merge 2ec4150713 jk/merge-subtree-heuristics later to maint). - - * "git fetch $there refs/heads/s" ought to fetch the tip of the - branch 's', but when "refs/heads/refs/heads/s", i.e. a branch whose - name is "refs/heads/s" exists at the same time, fetched that one - instead by mistake. This has been corrected to honor the usual - disambiguation rules for abbreviated refnames. - (merge 60650a48c0 jt/refspec-dwim-precedence-fix later to maint). - - * Futureproofing a helper function that can easily be misused. - (merge 65bb21e77e es/want-color-fd-defensive later to maint). - - * The http-backend (used for smart-http transport) used to slurp the - whole input until EOF, without paying attention to CONTENT_LENGTH - that is supplied in the environment and instead expecting the Web - server to close the input stream. This has been fixed. - (merge eebfe40962 mk/http-backend-content-length later to maint). - - * "git merge --abort" etc. did not clean things up properly when - there were conflicted entries in the index in certain order that - are involved in D/F conflicts. This has been corrected. - (merge ad3762042a en/abort-df-conflict-fixes later to maint). - - * "git diff --indent-heuristic" had a bad corner case performance. - (merge 301ef85401 sb/indent-heuristic-optim later to maint). - - * The "--exec" option to "git rebase --rebase-merges" placed the exec - commands at wrong places, which has been corrected. - - * "git verify-tag" and "git verify-commit" have been taught to use - the exit status of underlying "gpg --verify" to signal bad or - untrusted signature they found. - (merge 4e5dc9ca17 jc/gpg-status later to maint). - - * "git mergetool" stopped and gave an extra prompt to continue after - the last path has been handled, which did not make much sense. - (merge d651a54b8a ng/mergetool-lose-final-prompt later to maint). - - * Among the three codepaths we use O_APPEND to open a file for - appending, one used for writing GIT_TRACE output requires O_APPEND - implementation that behaves sensibly when multiple processes are - writing to the same file. POSIX emulation used in the Windows port - has been updated to improve in this area. - (merge d641097589 js/mingw-o-append later to maint). - - * "git pull --rebase -v" in a repository with a submodule barfed as - an intermediate process did not understand what "-v(erbose)" flag - meant, which has been fixed. - (merge e84c3cf3dc sb/pull-rebase-submodule later to maint). - - * Recent update to "git config" broke updating variable in a - subsection, which has been corrected. - (merge bff7df7a87 sb/config-write-fix later to maint). - - * When "git rebase -i" is told to squash two or more commits into - one, it labeled the log message for each commit with its number. - It correctly called the first one "1st commit", but the next one - was "commit #1", which was off-by-one. This has been corrected. - (merge dd2e36ebac pw/rebase-i-squash-number-fix later to maint). - - * "git rebase -i", when a 'merge <branch>' insn in its todo list - fails, segfaulted, which has been (minimally) corrected. - (merge bc9238bb09 pw/rebase-i-merge-segv-fix later to maint). - - * "git cherry-pick --quit" failed to remove CHERRY_PICK_HEAD even - though we won't be in a cherry-pick session after it returns, which - has been corrected. - (merge 3e7dd99208 nd/cherry-pick-quit-fix later to maint). - - * In a recent update in 2.18 era, "git pack-objects" started - producing a larger than necessary packfiles by missing - opportunities to use large deltas. This has been corrected. - - * The meaning of the possible values the "core.checkStat" - configuration variable can take were not adequately documented, - which has been fixed. - (merge 9bf5d4c4e2 nd/config-core-checkstat-doc later to maint). - - * Recent "git rebase -i" update started to write bogusly formatted - author-script, with a matching broken reading code. These are - fixed. - - * Recent addition of "directory rename" heuristics to the - merge-recursive backend makes the command susceptible to false - positives and false negatives. In the context of "git am -3", - which does not know about surrounding unmodified paths and thus - cannot inform the merge machinery about the full trees involved, - this risk is particularly severe. As such, the heuristic is - disabled for "git am -3" to keep the machinery "more stupid but - predictable". - - * "git merge-base" in 2.19-rc1 has performance regression when the - (experimental) commit-graph feature is in use, which has been - mitigated. - - * Code cleanup, docfix, build fix, etc. - (merge aee9be2ebe sg/update-ref-stdin-cleanup later to maint). - (merge 037714252f jc/clean-after-sanity-tests later to maint). - (merge 5b26c3c941 en/merge-recursive-cleanup later to maint). - (merge 0dcbc0392e bw/config-refer-to-gitsubmodules-doc later to maint). - (merge bb4d000e87 bw/protocol-v2 later to maint). - (merge 928f0ab4ba vs/typofixes later to maint). - (merge d7f590be84 en/rebase-i-microfixes later to maint). - (merge 81d395cc85 js/rebase-recreate-merge later to maint). - (merge 51d1863168 tz/exclude-doc-smallfixes later to maint). - (merge a9aa3c0927 ds/commit-graph later to maint). - (merge 5cf8e06474 js/enhanced-version-info later to maint). - (merge 6aaded5509 tb/config-default later to maint). - (merge 022d2ac1f3 sb/blame-color later to maint). - (merge 5a06a20e0c bp/test-drop-caches-for-windows later to maint). - (merge dd61cc1c2e jk/ui-color-always-to-auto later to maint). - (merge 1e83b9bfdd sb/trailers-docfix later to maint). - (merge ab29f1b329 sg/fast-import-dump-refs-on-checkpoint-fix later to maint). - (merge 6a8ad880f0 jn/subtree-test-fixes later to maint). - (merge ffbd51cc60 nd/pack-objects-threading-doc later to maint). - (merge e9dac7be60 es/mw-to-git-chain-fix later to maint). - (merge fe583c6c7a rs/remote-mv-leakfix later to maint). - (merge 69885ab015 en/t3031-title-fix later to maint). - (merge 8578037bed nd/config-blame-sort later to maint). - (merge 8ad169c4ba hn/config-in-code-comment later to maint). - (merge b7446fcfdf ar/t4150-am-scissors-test-fix later to maint). - (merge a8132410ee js/typofixes later to maint). - (merge 388d0ff6e5 en/update-index-doc later to maint). - (merge e05aa688dd jc/update-index-doc later to maint). - (merge 10c600172c sg/t5310-empty-input-fix later to maint). - (merge 5641eb9465 jh/partial-clone-doc later to maint). - (merge 2711b1ad5e ab/submodule-relative-url-tests later to maint). - (merge ce528de023 ab/unconditional-free-and-null later to maint). - (merge bbc072f5d8 rs/opt-updates later to maint). - (merge 69d846f053 jk/use-compat-util-in-test-tool later to maint). - (merge 1820703045 js/larger-timestamps later to maint). - (merge c8b35b95e1 sg/t4051-fix later to maint). - (merge 30612cb670 sg/t0020-conversion-fix later to maint). - (merge 15da753709 sg/t7501-thinkofix later to maint). - (merge 79b04f9b60 sg/t3903-missing-fix later to maint). - (merge 2745817028 sg/t3420-autostash-fix later to maint). - (merge 7afb0d6777 sg/test-rebase-editor-fix later to maint). - (merge 6c6ce21baa es/freebsd-iconv-portability later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.19.1.txt b/third_party/git/Documentation/RelNotes/2.19.1.txt deleted file mode 100644 index da7672674e..0000000000 --- a/third_party/git/Documentation/RelNotes/2.19.1.txt +++ /dev/null @@ -1,6 +0,0 @@ -Git v2.19.1 Release Notes -========================= - -This release merges up the fixes that appear in v2.14.5 and in -v2.17.2 to address the recently reported CVE-2018-17456; see the -release notes for those versions for details. diff --git a/third_party/git/Documentation/RelNotes/2.19.2.txt b/third_party/git/Documentation/RelNotes/2.19.2.txt deleted file mode 100644 index 759e6ca957..0000000000 --- a/third_party/git/Documentation/RelNotes/2.19.2.txt +++ /dev/null @@ -1,108 +0,0 @@ -Git v2.19.2 Release Notes -========================= - -Fixes since v2.19.1 -------------------- - - * "git interpret-trailers" and its underlying machinery had a buggy - code that attempted to ignore patch text after commit log message, - which triggered in various codepaths that will always get the log - message alone and never get such an input. - - * "git rebase -i" did not clear the state files correctly when a run - of "squash/fixup" is aborted and then the user manually amended the - commit instead, which has been corrected. - - * When fsmonitor is in use, after operation on submodules updates - .gitmodules, we lost track of the fact that we did so and relied on - stale fsmonitor data. - - * Fix for a long-standing bug that leaves the index file corrupt when - it shrinks during a partial commit. - - * Further fix for O_APPEND emulation on Windows - - * A corner case bugfix in "git rerere" code. - - * "git add ':(attr:foo)'" is not supported and is supposed to be - rejected while the command line arguments are parsed, but we fail - to reject such a command line upfront. - - * "git rebase" etc. in Git 2.19 fails to abort when given an empty - commit log message as result of editing, which has been corrected. - - * The code to backfill objects in lazily cloned repository did not - work correctly, which has been corrected. - - * Update error messages given by "git remote" and make them consistent. - - * "git update-ref" learned to make both "--no-deref" and "--stdin" - work at the same time. - - * Recently added "range-diff" had a corner-case bug to cause it - segfault, which has been corrected. - - * The recently introduced commit-graph auxiliary data is incompatible - with mechanisms such as replace & grafts that "breaks" immutable - nature of the object reference relationship. Disable optimizations - based on its use (and updating existing commit-graph) when these - incompatible features are in use in the repository. - - * The mailmap file update. - - * The code in "git status" sometimes hit an assertion failure. This - was caused by a structure that was reused without cleaning the data - used for the first run, which has been corrected. - - * A corner-case bugfix. - - * A partial clone that is configured to lazily fetch missing objects - will on-demand issue a "git fetch" request to the originating - repository to fill not-yet-obtained objects. The request has been - optimized for requesting a tree object (and not the leaf blob - objects contained in it) by telling the originating repository that - no blobs are needed. - - * The codepath to support the experimental split-index mode had - remaining "racily clean" issues fixed. - - * "git log --graph" showing an octopus merge sometimes miscounted the - number of display columns it is consuming to show the merge and its - parent commits, which has been corrected. - - * The implementation of run_command() API on the UNIX platforms had a - bug that caused a command not on $PATH to be found in the current - directory. - - * A mutex used in "git pack-objects" were not correctly initialized - and this caused "git repack" to dump core on Windows. - - * Under certain circumstances, "git diff D:/a/b/c D:/a/b/d" on - Windows would strip initial parts from the paths because they - were not recognized as absolute, which has been corrected. - - * The receive.denyCurrentBranch=updateInstead codepath kicked in even - when the push should have been rejected due to other reasons, such - as it does not fast-forward or the update-hook rejects it, which - has been corrected. - - * "git repack" in a shallow clone did not correctly update the - shallow points in the repository, leading to a repository that - does not pass fsck. - - * Operations on promisor objects make sense in the context of only a - small subset of the commands that internally use the revisions - machinery, but the "--exclude-promisor-objects" option were taken - and led to nonsense results by commands like "log", to which it - didn't make much sense. This has been corrected. - - * The "container" mode of TravisCI is going away. Our .travis.yml - file is getting prepared for the transition. - - * Our test scripts can now take the '-V' option as a synonym for the - '--verbose-log' option. - - * A regression in Git 2.12 era made "git fsck" fall into an infinite - loop while processing truncated loose objects. - -Also contains various documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.2.0.txt b/third_party/git/Documentation/RelNotes/2.2.0.txt deleted file mode 100644 index e98ecbcff6..0000000000 --- a/third_party/git/Documentation/RelNotes/2.2.0.txt +++ /dev/null @@ -1,313 +0,0 @@ -Git v2.2 Release Notes -====================== - -Updates since v2.1 ------------------- - -Ports - - * Building on older MacOS X systems automatically sets - the necessary NO_APPLE_COMMON_CRYPTO build-time option. - - * Building with NO_PTHREADS has been resurrected. - - * Compilation options have been updated a bit to better support the - z/OS port. - - -UI, Workflows & Features - - * "git archive" learned to filter what gets archived with a pathspec. - - * "git config --edit --global" starts from a skeletal per-user - configuration file contents, instead of a total blank, when the - user does not already have any global config. This immediately - reduces the need to later ask "Have you forgotten to set - core.user?", and we can add more to the template as we gain - more experience. - - * "git stash list -p" used to be almost always a no-op because each - stash entry is represented as a merge commit. It learned to show - the difference between the base commit version and the working tree - version, which is in line with what "git stash show" gives. - - * Sometimes users want to report a bug they experience on their - repository, but they are not at liberty to share the contents of - the repository. "fast-export" was taught an "--anonymize" option - to replace blob contents, names of people, paths and log - messages with bland and simple strings to help them. - - * "git difftool" learned an option to stop feeding paths to the - diff backend when it exits with a non-zero status. - - * "git grep" learned to paint (or not paint) partial matches on - context lines when showing "grep -C<num>" output in color. - - * "log --date=iso" uses a slight variant of the ISO 8601 format that is - more human readable. A new "--date=iso-strict" option gives - datetime output that conforms more strictly. - - * The logic "git prune" uses is more resilient against various corner - cases. - - * A broken reimplementation of Git could write an invalid index that - records both stage #0 and higher-stage entries for the same path. - We now notice and reject such an index, as there is no sensible - fallback (we do not know if the broken tool wanted to resolve and - forgot to remove the higher-stage entries, or if it wanted to unresolve - and forgot to remove the stage #0 entry). - - * The temporary files "git mergetool" uses are renamed to avoid too - many dots in them (e.g. a temporary file for "hello.c" used to be - named e.g. "hello.BASE.4321.c" but now uses underscore instead, - e.g. "hello_BASE_4321.c", to allow us to have multiple variants). - - * The temporary files "git mergetool" uses can be placed in a newly - created temporary directory, instead of the current directory, by - setting the mergetool.writeToTemp configuration variable. - - * "git mergetool" understands "--tool bc" now, as version 4 of - BeyondCompare can be driven the same way as its version 3 and it - feels awkward to say "--tool bc3" to run version 4. - - * The "pre-receive" and "post-receive" hooks are no longer required - to consume their input fully (not following this requirement used - to result in intermittent errors in "git push"). - - * The pretty-format specifier "%d", which expands to " (tagname)" - for a tagged commit, gained a cousin "%D" that just gives the - "tagname" without frills. - - * "git push" learned "--signed" push, that allows a push (i.e. - request to update the refs on the other side to point at a new - history, together with the transmission of necessary objects) to be - signed, so that it can be verified and audited, using the GPG - signature of the person who pushed, that the tips of branches at a - public repository really point the commits the pusher wanted to, - without having to "trust" the server. - - * "git interpret-trailers" is a new filter to programmatically edit - the tail end of the commit log messages, e.g. "Signed-off-by:". - - * "git help everyday" shows the "Everyday Git in 20 commands or so" - document, whose contents have been updated to match more modern - Git practice. - - * On the "git svn" front, work progresses to reduce memory consumption and - to improve handling of mergeinfo. - - -Performance, Internal Implementation, Development Support etc. - - * The API to manipulate the "refs" has been restructured to make it - more transactional, with the eventual goal to allow all-or-none - atomic updates and migrating the storage to something other than - the traditional filesystem based one (e.g. databases). - - * The lockfile API and its users have been cleaned up. - - * We no longer attempt to keep track of individual dependencies to - the header files in the build procedure, relying instead on automated - dependency generation support from modern compilers. - - * In tests, we have been using NOT_{MINGW,CYGWIN} test prerequisites - long before negated prerequisites e.g. !MINGW were invented. - The former has been converted to the latter to avoid confusion. - - * Optimized looking up a remote's configuration in a repository with very many - remotes defined. - - * There are cases where you lock and open to write a file, close it - to show the updated contents to an external processes, and then have - to update the file again while still holding the lock; now the - lockfile API has support for such an access pattern. - - * The API to allocate the structure to keep track of commit - decoration has been updated to make it less cumbersome to use. - - * An in-core caching layer to let us avoid reading the same - configuration files several times has been added. A few commands - have been converted to use this subsystem. - - * Various code paths have been cleaned up and simplified by using - the "strbuf", "starts_with()", and "skip_prefix()" APIs more. - - * A few codepaths that died when large blobs that would not fit in - core are involved in their operation have been taught to punt - instead, by e.g. marking a too-large blob as not to be diffed. - - * A few more code paths in "commit" and "checkout" have been taught - to repopulate the cache-tree in the index, to help speed up later - "write-tree" (used in "commit") and "diff-index --cached" (used in - "status"). - - * A common programming mistake to assign the same short option name - to two separate options is detected by the parse_options() API to help - developers. - - * The code path to write out the packed-refs file has been optimized, - which especially matters in a repository with a large number of - refs. - - * The check to see if a ref $F can be created by making sure no - existing ref has $F/ as its prefix has been optimized, which - especially matters in a repository with a large number of existing - refs. - - * "git fsck" was taught to check the contents of tag objects a bit more. - - * "git hash-object" was taught a "--literally" option to help - debugging. - - * When running a required clean filter, we do not have to mmap the - original before feeding the filter. Instead, stream the file - contents directly to the filter and process its output. - - * The scripts in the test suite can be run with the "-x" option to show - a shell-trace of each command they run. - - * The "run-command" API learned to manage the argv and environment - arrays for child process, alleviating the need for the callers to - allocate and deallocate them. - - * Some people use AsciiDoctor, instead of AsciiDoc, to format our - documentation set; the documentation has been adjusted to be usable - by both, as AsciiDoctor is pickier than AsciiDoc about its input - mark-up. - - -Also contains various documentation updates and code clean-ups. - - -Fixes since v2.1 ----------------- - -Unless otherwise noted, all the fixes since v2.1 in the maintenance -track are contained in this release (see the maintenance releases' -notes for details). - - * "git log --pretty/format=" with an empty format string did not - mean the more obvious "No output whatsoever" but "Use default - format", which was counterintuitive. - - * "git -c section.var command" and "git -c section.var= command" - should pass the configuration value differently (the former should be a - boolean true, the latter should be an empty string). - - * Applying a patch not generated by Git in a subdirectory used to - check for whitespace breakage using the attributes of incorrect - paths. Also whitespace checks were performed even for paths - excluded via the "git apply --exclude=<path>" mechanism. - - * "git bundle create" with a date-range specification was meant to - exclude tags outside the range, but it didn't. - - * "git add x" where x used to be a directory and is now a - symbolic link to a directory misbehaved. - - * The prompt script checked the $GIT_DIR/ref/stash file to see if there - is a stash, which was a no-no. - - * Pack-protocol documentation had a minor typo. - - * "git checkout -m" did not switch to another branch while carrying - the local changes forward when a path was deleted from the index. - - * "git daemon" (with NO_IPV6 build configuration) used to incorrectly - use the hostname even when gethostbyname() reported that the given - hostname is not found. - (merge 107efbe rs/daemon-fixes later to maint). - - * With sufficiently long refnames, "git fast-import" could have - overflowed an on-stack buffer. - - * After "pack-refs --prune" packed refs at the top-level, it failed - to prune them. - - * Progress output from "git gc --auto" was visible in "git fetch -q". - - * We used to pass -1000 to poll(2), expecting it to also mean "no - timeout", which should be spelled as -1. - - * "git rebase" documentation was unclear that it is required to - specify on what <upstream> the rebase is to be done when telling it - to first check out <branch>. - (merge 95c6826 so/rebase-doc later to maint). - - * "git push" over HTTP transport had an artificial limit on the number of - refs that can be pushed, imposed by the command line length. - (merge 26be19b jk/send-pack-many-refspecs later to maint). - - * When receiving an invalid pack stream that records the same object - twice, multiple threads got confused due to a race. - (merge ab791dd jk/index-pack-threading-races later to maint). - - * An attempt to remove the entire tree in the "git fast-import" input - stream caused it to misbehave. - (merge 2668d69 mb/fast-import-delete-root later to maint). - - * Reachability check (used in "git prune" and friends) did not add a - detached HEAD as a starting point to traverse objects still in use. - (merge c40fdd0 mk/reachable-protect-detached-head later to maint). - - * "git config --add section.var val" when section.var already has an - empty-string value used to lose the empty-string value. - (merge c1063be ta/config-add-to-empty-or-true-fix later to maint). - - * "git fsck" failed to report that it found corrupt objects via its - exit status in some cases. - (merge 30d1038 jk/fsck-exit-code-fix later to maint). - - * Use of the "--verbose" option used to break "git branch --merged". - (merge 12994dd jk/maint-branch-verbose-merged later to maint). - - * Some MUAs mangle a line in a message that begins with "From " to - ">From " when writing to a mailbox file, and feeding such an input - to "git am" used to lose such a line. - (merge 85de86a jk/mbox-from-line later to maint). - - * "rev-parse --verify --quiet $name" is meant to quietly exit with a - non-zero status when $name is not a valid object name, but still - gave error messages in some cases. - - * A handful of C source files have been updated to include - "git-compat-util.h" as the first thing, to conform better to our - coding guidelines. - (merge 1c4b660 da/include-compat-util-first-in-c later to maint). - - * The t7004 test, which tried to run Git with small stack space, has been - updated to use a bit larger stack to avoid false breakage on some - platforms. - (merge b9a1907 sk/tag-contains-wo-recursion later to maint). - - * A few documentation pages had example sections marked up not quite - correctly, which passed AsciiDoc but failed with AsciiDoctor. - (merge c30c43c bc/asciidoc-pretty-formats-fix later to maint). - (merge f8a48af bc/asciidoc later to maint). - - * "gitweb" used deprecated CGI::startfrom, which was removed from - CGI.pm as of 4.04; use CGI::start_from instead. - (merge 4750f4b rm/gitweb-start-form later to maint). - - * Newer versions of 'meld' break the auto-detection we use to see if - they are new enough to support the `--output` option. - (merge b12d045 da/mergetool-meld later to maint). - - * "git pack-objects" forgot to disable the codepath to generate the - object reachability bitmap when it needs to split the resulting - pack. - (merge 2113471 jk/pack-objects-no-bitmap-when-splitting later to maint). - - * The code to use cache-tree trusted the on-disk data too much and - fell into an infinite loop upon seeing an incorrectly recorded - index file. - (merge 729dbbd jk/cache-tree-protect-from-broken-libgit2 later to maint). - - * "git fetch" into a repository where branch B was deleted earlier, - back when it had reflog enabled, and then branch B/C is fetched - into it without reflog enabled, which is arguably an unlikely - corner case, unnecessarily failed. - (merge aae828b jk/fetch-reflog-df-conflict later to maint). - - * "git log --first-parent -L..." used to crash. - (merge a8787c5 tm/line-log-first-parent later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.2.1.txt b/third_party/git/Documentation/RelNotes/2.2.1.txt deleted file mode 100644 index d5a3cd9e73..0000000000 --- a/third_party/git/Documentation/RelNotes/2.2.1.txt +++ /dev/null @@ -1,34 +0,0 @@ -Git v2.2.1 Release Notes -======================== - -Fixes since v2.2 ----------------- - - * We used to allow committing a path ".Git/config" with Git that is - running on a case sensitive filesystem, but an attempt to check out - such a path with Git that runs on a case insensitive filesystem - would have clobbered ".git/config", which is definitely not what - the user would have expected. Git now prevents you from tracking - a path with ".Git" (in any case combination) as a path component. - - * On Windows, certain path components that are different from ".git" - are mapped to ".git", e.g. "git~1/config" is treated as if it were - ".git/config". HFS+ has a similar issue, where certain unicode - codepoints are ignored, e.g. ".g\u200cit/config" is treated as if - it were ".git/config". Pathnames with these potential issues are - rejected on the affected systems. Git on systems that are not - affected by this issue (e.g. Linux) can also be configured to - reject them to ensure cross platform interoperability of the hosted - projects. - - * "git fsck" notices a tree object that records such a path that can - be confused with ".git", and with receive.fsckObjects configuration - set to true, an attempt to "git push" such a tree object will be - rejected. Such a path may not be a problem on a well behaving - filesystem but in order to protect those on HFS+ and on case - insensitive filesystems, this check is enabled on all platforms. - -A big "thanks!" for bringing this issue to us goes to our friends in -the Mercurial land, namely, Matt Mackall and Augie Fackler. - -Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.2.2.txt b/third_party/git/Documentation/RelNotes/2.2.2.txt deleted file mode 100644 index b19a35d94f..0000000000 --- a/third_party/git/Documentation/RelNotes/2.2.2.txt +++ /dev/null @@ -1,63 +0,0 @@ -Git v2.2.2 Release Notes -======================== - -Fixes since v2.2.1 ------------------- - - * "git checkout $treeish $path", when $path in the index and the - working tree already matched what is in $treeish at the $path, - still overwrote the $path unnecessarily. - - * "git config --get-color" did not parse its command line arguments - carefully. - - * open() emulated on Windows platforms did not give EISDIR upon - an attempt to open a directory for writing. - - * A few code paths used abs() when they should have used labs() on - long integers. - - * "gitweb" used to depend on a behaviour recent CGI.pm deprecated. - - * "git init" (hence "git clone") initialized the per-repository - configuration file .git/config with x-bit by mistake. - - * Git 2.0 was supposed to make the "simple" mode for the default of - "git push", but it didn't. - - * "Everyday" document had a broken link. - - * The build procedure did not bother fixing perl and python scripts - when NO_PERL and NO_PYTHON build-time configuration changed. - - * The code that reads the reflog from the newer to the older entries - did not handle an entry that crosses a boundary of block it uses to - read them correctly. - - * "git apply" was described in the documentation to take --ignore-date - option, which it does not. - - * Traditionally we tried to avoid interpreting date strings given by - the user as future dates, e.g. GIT_COMMITTER_DATE=2014-12-10 when - used early November 2014 was taken as "October 12, 2014" because it - is likely that a date in the future, December 10, is a mistake. - This heuristics has been loosened to allow people to express future - dates (most notably, --until=<date> may want to be far in the - future) and we no longer tiebreak by future-ness of the date when - - (1) ISO-like format is used, and - (2) the string can make sense interpreted as both y-m-d and y-d-m. - - Git may still have to use the heuristics to tiebreak between dd/mm/yy - and mm/dd/yy, though. - - * The code to abbreviate an object name to its short unique prefix - has been optimized when no abbreviation was requested. - - * "git add --ignore-errors ..." did not ignore an error to - give a file that did not exist. - - * Git did not correctly read an overlong refname from a packed refs - file. - -Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.2.3.txt b/third_party/git/Documentation/RelNotes/2.2.3.txt deleted file mode 100644 index 5bfffa4106..0000000000 --- a/third_party/git/Documentation/RelNotes/2.2.3.txt +++ /dev/null @@ -1,9 +0,0 @@ -Git v2.2.3 Release Notes -======================== - -Fixes since v2.2.2 ------------------- - - * A handful of codepaths that used to use fixed-sized arrays to hold - pathnames have been corrected to use strbuf and other mechanisms to - allow longer pathnames without fearing overflows. diff --git a/third_party/git/Documentation/RelNotes/2.20.0.txt b/third_party/git/Documentation/RelNotes/2.20.0.txt deleted file mode 100644 index e71fe3dee1..0000000000 --- a/third_party/git/Documentation/RelNotes/2.20.0.txt +++ /dev/null @@ -1,700 +0,0 @@ -Git 2.20 Release Notes -====================== - -Backward Compatibility Notes ----------------------------- - - * "git branch -l <foo>" used to be a way to ask a reflog to be - created while creating a new branch, but that is no longer the - case. It is a short-hand for "git branch --list <foo>" now. - - * "git push" into refs/tags/* hierarchy is rejected without getting - forced, but "git fetch" (misguidedly) used the "fast forwarding" - rule used for the refs/heads/* hierarchy; this has been corrected, - which means some fetches of tags that did not fail with older - version of Git will fail without "--force" with this version. - - * "git help -a" now gives verbose output (same as "git help -av"). - Those who want the old output may say "git help --no-verbose -a".. - - * "git cpn --help", when "cpn" is an alias to, say, "cherry-pick -n", - reported only the alias expansion of "cpn" in earlier versions of - Git. It now runs "git cherry-pick --help" to show the manual page - of the command, while sending the alias expansion to the standard - error stream. - - * "git send-email" learned to grab address-looking string on any - trailer whose name ends with "-by". This is a backward-incompatible - change. Adding "--suppress-cc=misc-by" on the command line, or - setting sendemail.suppresscc configuration variable to "misc-by", - can be used to disable this behaviour. - - -Updates since v2.19 -------------------- - -UI, Workflows & Features - - * Running "git clone" against a project that contain two files with - pathnames that differ only in cases on a case insensitive - filesystem would result in one of the files lost because the - underlying filesystem is incapable of holding both at the same - time. An attempt is made to detect such a case and warn. - - * "git checkout -b newbranch [HEAD]" should not have to do as much as - checking out a commit different from HEAD. An attempt is made to - optimize this special case. - - * "git rev-list --stdin </dev/null" used to be an error; it now shows - no output without an error. "git rev-list --stdin --default HEAD" - still falls back to the given default when nothing is given on the - standard input. - - * Lift code from GitHub to restrict delta computation so that an - object that exists in one fork is not made into a delta against - another object that does not appear in the same forked repository. - - * "git format-patch" learned new "--interdiff" and "--range-diff" - options to explain the difference between this version and the - previous attempt in the cover letter (or after the three-dashes as - a comment). - - * "git mailinfo" used in "git am" learned to make a best-effort - recovery of a patch corrupted by MUA that sends text/plain with - format=flawed option. - (merge 3aa4d81f88 rs/mailinfo-format-flowed later to maint). - - * The rules used by "git push" and "git fetch" to determine if a ref - can or cannot be updated were inconsistent; specifically, fetching - to update existing tags were allowed even though tags are supposed - to be unmoving anchoring points. "git fetch" was taught to forbid - updates to existing tags without the "--force" option. - - * "git multi-pack-index" learned to detect corruption in the .midx - file it uses, and this feature has been integrated into "git fsck". - - * Generation of (experimental) commit-graph files have so far been - fairly silent, even though it takes noticeable amount of time in a - meaningfully large repository. The users will now see progress - output. - - * The minimum version of Windows supported by Windows port of Git is - now set to Vista. - - * The completion script (in contrib/) learned to complete a handful of - options "git stash list" command takes. - - * The completion script (in contrib/) learned that "git fetch - --multiple" only takes remote names as arguments and no refspecs. - - * "git status" learns to show progress bar when refreshing the index - takes a long time. - (merge ae9af12287 nd/status-refresh-progress later to maint). - - * "git help -a" and "git help -av" give different pieces of - information, and generally the "verbose" version is more friendly - to the new users. "git help -a" by default now uses the more - verbose output (with "--no-verbose", you can go back to the - original). Also "git help -av" now lists aliases and external - commands, which it did not used to. - - * Unlike "grep", "git grep" by default recurses to the whole tree. - The command learned "git grep --recursive" option, so that "git - grep --no-recursive" can serve as a synonym to setting the - max-depth to 0. - - * When pushing into a repository that borrows its objects from an - alternate object store, "git receive-pack" that responds to the - push request on the other side lists the tips of refs in the - alternate to reduce the amount of objects transferred. This - sometimes is detrimental when the number of refs in the alternate - is absurdly large, in which case the bandwidth saved in potentially - fewer objects transferred is wasted in excessively large ref - advertisement. The alternate refs that are advertised are now - configurable with a pair of configuration variables. - - * "git cmd --help" when "cmd" is aliased used to only say "cmd is - aliased to ...". Now it shows that to the standard error stream - and runs "git $cmd --help" where $cmd is the first word of the - alias expansion. - - * The documentation of "git gc" has been updated to mention that it - is no longer limited to "pruning away crufts" but also updates - ancillary files like commit-graph as a part of repository - optimization. - - * "git p4 unshelve" improvements. - - * The logic to select the default user name and e-mail on Windows has - been improved. - (merge 501afcb8b0 js/mingw-default-ident later to maint). - - * The "rev-list --filter" feature learned to exclude all trees via - "tree:0" filter. - - * "git send-email" learned to grab address-looking string on any - trailer whose name ends with "-by"; --suppress-cc=misc-by on the - command line, or setting sendemail.suppresscc configuration - variable to "misc-by", can be used to disable this behaviour. - - * "git mergetool" learned to take the "--[no-]gui" option, just like - "git difftool" does. - - * "git rebase -i" learned a new insn, 'break', that the user can - insert in the to-do list. Upon hitting it, the command returns - control back to the user. - - * New "--pretty=format:" placeholders %GF and %GP that show the GPG - key fingerprints have been invented. - - * On platforms with recent cURL library, http.sslBackend configuration - variable can be used to choose a different SSL backend at runtime. - The Windows port uses this mechanism to switch between OpenSSL and - Secure Channel while talking over the HTTPS protocol. - - * "git send-email" learned to disable SMTP authentication via the - "--smtp-auth=none" option, even when the smtp username is given - (which turns the authentication on by default). - - * A fourth class of configuration files (in addition to the - traditional "system wide", "per user in the $HOME directory" and - "per repository in the $GIT_DIR/config") has been introduced so - that different worktrees that share the same repository (hence the - same $GIT_DIR/config file) can use different customization. - - * A pattern with '**' that does not have a slash on either side used - to be an invalid one, but the code now treats such double-asterisks - the same way as two normal asterisks that happen to be adjacent to - each other. - (merge e5bbe09e88 nd/wildmatch-double-asterisk later to maint). - - * The "--no-patch" option, which can be used to get a high-level - overview without the actual line-by-line patch difference shown, of - the "range-diff" command was earlier broken, which has been - corrected. - - * The recently merged "rebase in C" has an escape hatch to use the - scripted version when necessary, but it hasn't been documented, - which has been corrected. - - -Performance, Internal Implementation, Development Support etc. - - * Developer builds now use -Wunused-function compilation option. - - * One of our CI tests to run with "unusual/experimental/random" - settings now also uses commit-graph and midx. - - * When there are too many packfiles in a repository (which is not - recommended), looking up an object in these would require - consulting many pack .idx files; a new mechanism to have a single - file that consolidates all of these .idx files is introduced. - - * "git submodule update" is getting rewritten piece-by-piece into C. - - * The code for computing history reachability has been shuffled, - obtained a bunch of new tests to cover them, and then being - improved. - - * The unpack_trees() API used in checking out a branch and merging - walks one or more trees along with the index. When the cache-tree - in the index tells us that we are walking a tree whose flattened - contents is known (i.e. matches a span in the index), as linearly - scanning a span in the index is much more efficient than having to - open tree objects recursively and listing their entries, the walk - can be optimized, which has been done. - - * When creating a thin pack, which allows objects to be made into a - delta against another object that is not in the resulting pack but - is known to be present on the receiving end, the code learned to - take advantage of the reachability bitmap; this allows the server - to send a delta against a base beyond the "boundary" commit. - - * spatch transformation to replace boolean uses of !hashcmp() to - newly introduced oideq() is added, and applied, to regain - performance lost due to support of multiple hash algorithms. - - * Fix a bug in which the same path could be registered under multiple - worktree entries if the path was missing (for instance, was removed - manually). Also, as a convenience, expand the number of cases in - which --force is applicable. - - * Split Documentation/config.txt for easier maintenance. - (merge 6014363f0b nd/config-split later to maint). - - * Test helper binaries clean-up. - (merge c9a1f4161f nd/test-tool later to maint). - - * Various tests have been updated to make it easier to swap the - hash function used for object identification. - (merge ae0c89d41b bc/hash-independent-tests later to maint). - - * Update fsck.skipList implementation and documentation. - (merge 371a655074 ab/fsck-skiplist later to maint). - - * An alias that expands to another alias has so far been forbidden, - but now it is allowed to create such an alias. - - * Various test scripts have been updated for style and also correct - handling of exit status of various commands. - - * "gc --auto" ended up calling exit(-1) upon error, which has been - corrected to use exit(1). Also the error reporting behaviour when - daemonized has been updated to exit with zero status when stopping - due to a previously discovered error (which implies there is no - point running gc to improve the situation); we used to exit with - failure in such a case. - - * Various codepaths in the core-ish part learned to work on an - arbitrary in-core index structure, not necessarily the default - instance "the_index". - (merge b3c7eef9b0 nd/the-index later to maint). - - * Code clean-up in the internal machinery used by "git status" and - "git commit --dry-run". - (merge 73ba5d78b4 ss/wt-status-committable later to maint). - - * Some environment variables that control the runtime options of Git - used during tests are getting renamed for consistency. - (merge 4231d1ba99 bp/rename-test-env-var later to maint). - - * A pair of new extensions to the index file have been introduced. - They allow the index file to be read in parallel for performance. - - * The oidset API was built on top of the oidmap API which in turn is - on the hashmap API. Replace the implementation to build on top of - the khash API and gain performance. - - * Over some transports, fetching objects with an exact commit object - name can be done without first seeing the ref advertisements. The - code has been optimized to exploit this. - - * In a partial clone that will lazily be hydrated from the - originating repository, we generally want to avoid "does this - object exist (locally)?" on objects that we deliberately omitted - when we created the clone. The cache-tree codepath (which is used - to write a tree object out of the index) however insisted that the - object exists, even for paths that are outside of the partial - checkout area. The code has been updated to avoid such a check. - - * To help developers, an EditorConfig file that attempts to follow - the project convention has been added. - (merge b548d698a0 bc/editorconfig later to maint). - - * The result of coverage test can be combined with "git blame" to - check the test coverage of code introduced recently with a new - 'coverage-diff' tool (in contrib/). - (merge 783faedd65 ds/coverage-diff later to maint). - - * An experiment to fuzz test a few areas, hopefully we can gain more - coverage to various areas. - - * More codepaths are moving away from hardcoded hash sizes. - - * The way the Windows port figures out the current directory has been - improved. - - * The way DLLs are loaded on the Windows port has been improved. - - * Some tests have been reorganized and renamed; "ls t/" now gives a - better overview of what is tested for these scripts than before. - - * "git rebase" and "git rebase -i" have been reimplemented in C. - - * Windows port learned to use nano-second resolution file timestamps. - - * The overly large Documentation/config.txt file have been split into - million little pieces. This potentially allows each individual piece - to be included into the manual page of the command it affects more easily. - - * Replace three string-list instances used as look-up tables in "git - fetch" with hashmaps. - - * Unify code to read the author-script used in "git am" and the - commands that use the sequencer machinery, e.g. "git rebase -i". - - * In preparation to the day when we can deprecate and remove the - "rebase -p", make sure we can skip and later remove tests for - it. - - * The history traversal used to implement the tag-following has been - optimized by introducing a new helper. - - * The helper function to refresh the cached stat information in the - in-core index has learned to perform the lstat() part of the - operation in parallel on multi-core platforms. - - * The code to traverse objects for reachability, used to decide what - objects are unreferenced and expendable, have been taught to also - consider per-worktree refs of other worktrees as starting points to - prevent data loss. - - * "git add" needs to internally run "diff-files" equivalent, and the - codepath learned the same optimization as "diff-files" has to run - lstat(2) in parallel to find which paths have been updated in the - working tree. - - * The procedure to install dependencies before testing at Travis CI - is getting revamped for both simplicity and flexibility, taking - advantage of the recent move to the vm-based environment. - - * The support for format-patch (and send-email) by the command-line - completion script (in contrib/) has been simplified a bit. - - * The revision walker machinery learned to take advantage of the - commit generation numbers stored in the commit-graph file. - - * The codebase has been cleaned up to reduce "#ifndef NO_PTHREADS". - - * The way -lcurl library gets linked has been simplified by taking - advantage of the fact that we can just ask curl-config command how. - - * Various functions have been audited for "-Wunused-parameter" warnings - and bugs in them got fixed. - - * A sanity check for start-up sequence has been added in the config - API codepath. - - * The build procedure to link for fuzzing test has been made - customizable with a new Makefile variable. - - * The way "git rebase" parses and forwards the command line options - meant for underlying "git am" has been revamped, which fixed for - options with parameters that were not passed correctly. - - * Our testing framework uses a special i18n "poisoned localization" - feature to find messages that ought to stay constant but are - incorrectly marked to be translated. This feature has been made - into a runtime option (it used to be a compile-time option). - - * "git push" used to check ambiguities between object-names and - refnames while processing the list of refs' old and new values, - which was unnecessary (as it knew that it is feeding raw object - names). This has been optimized out. - - * The xcurl_off_t() helper function is used to cast size_t to - curl_off_t, but some compilers gave warnings against the code to - ensure the casting is done without wraparound, when size_t is - narrower than curl_off_t. This warning has been squelched. - - * Code preparation to replace ulong vars with size_t vars where - appropriate continues. - - * The "test installed Git" mode of our test suite has been updated to - work better. - - * A coding convention around the Coccinelle semantic patches to have - two classes to ease code migration process has been proposed and - its support has been added to the Makefile. - - * The "container" mode of TravisCI is going away. Our .travis.yml - file is getting prepared for the transition. - (merge 32ee384be8 ss/travis-ci-force-vm-mode later to maint). - - * Our test scripts can now take the '-V' option as a synonym for the - '--verbose-log' option. - (merge a5f52c6dab sg/test-verbose-log later to maint). - - -Fixes since v2.19 ------------------ - - * "git interpret-trailers" and its underlying machinery had a buggy - code that attempted to ignore patch text after commit log message, - which triggered in various codepaths that will always get the log - message alone and never get such an input. - (merge 66e83d9b41 jk/trailer-fixes later to maint). - - * Malformed or crafted data in packstream can make our code attempt - to read or write past the allocated buffer and abort, instead of - reporting an error, which has been fixed. - - * "git rebase -i" did not clear the state files correctly when a run - of "squash/fixup" is aborted and then the user manually amended the - commit instead, which has been corrected. - (merge 10d2f35436 js/rebase-i-autosquash-fix later to maint). - - * When fsmonitor is in use, after operation on submodules updates - .gitmodules, we lost track of the fact that we did so and relied on - stale fsmonitor data. - (merge 43f1180814 bp/mv-submodules-with-fsmonitor later to maint). - - * Fix for a long-standing bug that leaves the index file corrupt when - it shrinks during a partial commit. - (merge 6c003d6ffb jk/reopen-tempfile-truncate later to maint). - - * Further fix for O_APPEND emulation on Windows - (merge eeaf7ddac7 js/mingw-o-append later to maint). - - * A corner case bugfix in "git rerere" code. - (merge ad2bf0d9b4 en/rerere-multi-stage-1-fix later to maint). - - * "git add ':(attr:foo)'" is not supported and is supposed to be - rejected while the command line arguments are parsed, but we fail - to reject such a command line upfront. - (merge 84d938b732 nd/attr-pathspec-fix later to maint). - - * Recent update broke the reachability algorithm when refs (e.g. - tags) that point at objects that are not commit were involved, - which has been fixed. - - * "git rebase" etc. in Git 2.19 fails to abort when given an empty - commit log message as result of editing, which has been corrected. - (merge a3ec9eaf38 en/sequencer-empty-edit-result-aborts later to maint). - - * The code to backfill objects in lazily cloned repository did not - work correctly, which has been corrected. - (merge e68302011c jt/lazy-object-fetch-fix later to maint). - - * Update error messages given by "git remote" and make them consistent. - (merge 5025425dff ms/remote-error-message-update later to maint). - - * "git update-ref" learned to make both "--no-deref" and "--stdin" - work at the same time. - (merge d345e9fbe7 en/update-ref-no-deref-stdin later to maint). - - * Recently added "range-diff" had a corner-case bug to cause it - segfault, which has been corrected. - (merge e467a90c7a tg/range-diff-corner-case-fix later to maint). - - * The recently introduced commit-graph auxiliary data is incompatible - with mechanisms such as replace & grafts that "breaks" immutable - nature of the object reference relationship. Disable optimizations - based on its use (and updating existing commit-graph) when these - incompatible features are in use in the repository. - (merge 829a321569 ds/commit-graph-with-grafts later to maint). - - * The mailmap file update. - (merge 255eb03edf jn/mailmap-update later to maint). - - * The code in "git status" sometimes hit an assertion failure. This - was caused by a structure that was reused without cleaning the data - used for the first run, which has been corrected. - (merge 3e73cc62c0 en/status-multiple-renames-to-the-same-target-fix later to maint). - - * "git fetch $repo $object" in a partial clone did not correctly - fetch the asked-for object that is referenced by an object in - promisor packfile, which has been fixed. - - * A corner-case bugfix. - (merge c5cbb27cb5 sm/show-superproject-while-conflicted later to maint). - - * Various fixes to "diff --color-moved-ws". - - * A partial clone that is configured to lazily fetch missing objects - will on-demand issue a "git fetch" request to the originating - repository to fill not-yet-obtained objects. The request has been - optimized for requesting a tree object (and not the leaf blob - objects contained in it) by telling the originating repository that - no blobs are needed. - (merge 4c7f9567ea jt/non-blob-lazy-fetch later to maint). - - * The codepath to support the experimental split-index mode had - remaining "racily clean" issues fixed. - (merge 4c490f3d32 sg/split-index-racefix later to maint). - - * "git log --graph" showing an octopus merge sometimes miscounted the - number of display columns it is consuming to show the merge and its - parent commits, which has been corrected. - (merge 04005834ed np/log-graph-octopus-fix later to maint). - - * "git range-diff" did not work well when the compared ranges had - changes in submodules and the "--submodule=log" was used. - - * The implementation of run_command() API on the UNIX platforms had a - bug that caused a command not on $PATH to be found in the current - directory. - (merge f67b980771 jk/run-command-notdot later to maint). - - * A mutex used in "git pack-objects" were not correctly initialized - and this caused "git repack" to dump core on Windows. - (merge 34204c8166 js/pack-objects-mutex-init-fix later to maint). - - * Under certain circumstances, "git diff D:/a/b/c D:/a/b/d" on - Windows would strip initial parts from the paths because they - were not recognized as absolute, which has been corrected. - (merge ffd04e92e2 js/diff-notice-has-drive-prefix later to maint). - - * The receive.denyCurrentBranch=updateInstead codepath kicked in even - when the push should have been rejected due to other reasons, such - as it does not fast-forward or the update-hook rejects it, which - has been corrected. - (merge b072a25fad jc/receive-deny-current-branch-fix later to maint). - - * The logic to determine the archive type "git archive" uses did not - correctly kick in for "git archive --remote", which has been - corrected. - - * "git repack" in a shallow clone did not correctly update the - shallow points in the repository, leading to a repository that - does not pass fsck. - (merge 5dcfbf564c js/shallow-and-fetch-prune later to maint). - - * Some codepaths failed to form a proper URL when .gitmodules record - the URL to a submodule repository as relative to the repository of - superproject, which has been corrected. - (merge e0a862fdaf sb/submodule-url-to-absolute later to maint). - - * "git fetch" over protocol v2 into a shallow repository failed to - fetch full history behind a new tip of history that was diverged - before the cut-off point of the history that was previously fetched - shallowly. - - * The command line completion machinery (in contrib/) has been - updated to allow the completion script to tweak the list of options - that are reported by the parse-options machinery correctly. - (merge 276b49ff34 nd/completion-negation later to maint). - - * Operations on promisor objects make sense in the context of only a - small subset of the commands that internally use the revisions - machinery, but the "--exclude-promisor-objects" option were taken - and led to nonsense results by commands like "log", to which it - didn't make much sense. This has been corrected. - (merge 669b1d2aae md/exclude-promisor-objects-fix later to maint). - - * A regression in Git 2.12 era made "git fsck" fall into an infinite - loop while processing truncated loose objects. - (merge 18ad13e5b2 jk/detect-truncated-zlib-input later to maint). - - * "git ls-remote $there foo" was broken by recent update for the - protocol v2 and stopped showing refs that match 'foo' that are not - refs/{heads,tags}/foo, which has been fixed. - (merge 6a139cdd74 jk/proto-v2-ref-prefix-fix later to maint). - - * Additional comment on a tricky piece of code to help developers. - (merge 0afbe3e806 jk/stream-pack-non-delta-clarification later to maint). - - * A couple of tests used to leave the repository in a state that is - deliberately corrupt, which have been corrected. - (merge aa984dbe5e ab/pack-tests-cleanup later to maint). - - * The submodule support has been updated to read from the blob at - HEAD:.gitmodules when the .gitmodules file is missing from the - working tree. - (merge 2b1257e463 ao/submodule-wo-gitmodules-checked-out later to maint). - - * "git fetch" was a bit loose in parsing responses from the other side - when talking over the protocol v2. - - * "git rev-parse --exclude=* --branches --branches" (i.e. first - saying "add only things that do not match '*' out of all branches" - and then adding all branches, without any exclusion this time) - worked as expected, but "--exclude=* --all --all" did not work the - same way, which has been fixed. - (merge 5221048092 ag/rev-parse-all-exclude-fix later to maint). - - * "git send-email --transfer-encoding=..." in recent versions of Git - sometimes produced an empty "Content-Transfer-Encoding:" header, - which has been corrected. - (merge 3c88e46f1a al/send-email-auto-cte-fixup later to maint). - - * The interface into "xdiff" library used to discover the offset and - size of a generated patch hunk by first formatting it into the - textual hunk header "@@ -n,m +k,l @@" and then parsing the numbers - out. A new interface has been introduced to allow callers a more - direct access to them. - (merge 5eade0746e jk/xdiff-interface later to maint). - - * Pathspec matching against a tree object were buggy when negative - pathspec elements were involved, which has been fixed. - (merge b7845cebc0 nd/tree-walk-path-exclusion later to maint). - - * "git merge" and "git pull" that merges into an unborn branch used - to completely ignore "--verify-signatures", which has been - corrected. - (merge 01a31f3bca jk/verify-sig-merge-into-void later to maint). - - * "git rebase --autostash" did not correctly re-attach the HEAD at times. - - * "rev-parse --exclude=<pattern> --branches=<pattern>" etc. did not - quite work, which has been corrected. - (merge 9ab9b5df0e ra/rev-parse-exclude-glob later to maint). - - * When editing a patch in a "git add -i" session, a hunk could be - made to no-op. The "git apply" program used to reject a patch with - such a no-op hunk to catch user mistakes, but it is now updated to - explicitly allow a no-op hunk in an edited patch. - (merge 22cb3835b9 js/apply-recount-allow-noop later to maint). - - * The URL to an MSDN page in a comment has been updated. - (merge 2ef2ae2917 js/mingw-msdn-url later to maint). - - * "git ls-remote --sort=<thing>" can feed an object that is not yet - available into the comparison machinery and segfault, which has - been corrected to check such a request upfront and reject it. - - * When "git bundle" aborts due to an empty commit ranges - (i.e. resulting in an empty pack), it left a file descriptor to an - lockfile open, which resulted in leftover lockfile on Windows where - you cannot remove a file with an open file descriptor. This has - been corrected. - (merge 2c8ee1f53c jk/close-duped-fd-before-unlock-for-bundle later to maint). - - * "git format-patch --stat=<width>" can be used to specify the width - used by the diffstat (shown in the cover letter). - (merge 284aeb7e60 nd/format-patch-cover-letter-stat-width later to maint). - - * The way .git/index and .git/sharedindex* files were initially - created gave these files different perm bits until they were - adjusted for shared repository settings. This was made consistent. - (merge c9d6c78870 cc/shared-index-permbits later to maint). - - * "git rebase --stat" to transplant a piece of history onto a totally - unrelated history were not working before and silently showed wrong - result. With the recent reimplementation in C, it started to instead - die with an error message, as the original logic was not prepared - to cope with this case. This has now been fixed. - - * The advice message to tell the user to migrate an existing graft - file to the replace system when a graft file was read was shown - even when "git replace --convert-graft-file" command, which is the - way the message suggests to use, was running, which made little - sense. - (merge 8821e90a09 ab/replace-graft-with-replace-advice later to maint). - - * "git diff --raw" lost ellipses to adjust the output columns for - some time now, but the documentation still showed them. - - * Code cleanup, docfix, build fix, etc. - (merge 96a7501aad ts/doc-build-manpage-xsl-quietly later to maint). - (merge b9b07efdb2 tg/conflict-marker-size later to maint). - (merge fa0aeea770 sg/doc-trace-appends later to maint). - (merge d64324cb60 tb/void-check-attr later to maint). - (merge c3b9bc94b9 en/double-semicolon-fix later to maint). - (merge 79336116f5 sg/t3701-tighten-trace later to maint). - (merge 801fa63a90 jk/dev-build-format-security later to maint). - (merge 0597dd62ba sb/string-list-remove-unused later to maint). - (merge db2d36fad8 bw/protocol-v2 later to maint). - (merge 456d7cd3a9 sg/split-index-test later to maint). - (merge 7b6057c852 tq/refs-internal-comment-fix later to maint). - (merge 29e8dc50ad tg/t5551-with-curl-7.61.1 later to maint). - (merge 55f6bce2c9 fe/doc-updates later to maint). - (merge 7987d2232d jk/check-everything-connected-is-long-gone later to maint). - (merge 4ba3c9be47 dz/credential-doc-url-matching-rules later to maint). - (merge 4c399442f7 ma/commit-graph-docs later to maint). - (merge fc0503b04e ma/t1400-undebug-test later to maint). - (merge e56b53553a nd/packobjectshook-doc-fix later to maint). - (merge c56170a0c4 ma/mailing-list-address-in-git-help later to maint). - (merge 6e8fc70fce rs/sequencer-oidset-insert-avoids-dups later to maint). - (merge ad0b8f9575 mw/doc-typofixes later to maint). - (merge d9f079ad1a jc/how-to-document-api later to maint). - (merge b1492bf315 ma/t7005-bash-workaround later to maint). - (merge ac1f98a0df du/rev-parse-is-plumbing later to maint). - (merge ca8ed443a5 mm/doc-no-dashed-git later to maint). - (merge ce366a8144 du/get-tar-commit-id-is-plumbing later to maint). - (merge 61018fe9e0 du/cherry-is-plumbing later to maint). - (merge c7e5fe79b9 sb/strbuf-h-update later to maint). - (merge 8d2008196b tq/branch-create-wo-branch-get later to maint). - (merge 2e3c894f4b tq/branch-style-fix later to maint). - (merge c5d844af9c sg/doc-show-branch-typofix later to maint). - (merge 081d91618b ah/doc-updates later to maint). - (merge b84c783882 jc/cocci-preincr later to maint). - (merge 5e495f8122 uk/merge-subtree-doc-update later to maint). - (merge aaaa881822 jk/uploadpack-packobjectshook-fix later to maint). - (merge 3063477445 tb/char-may-be-unsigned later to maint). - (merge 8c64bc9420 sg/test-rebase-editor-fix later to maint). - (merge 71571cd7d6 ma/sequencer-do-reset-saner-loop-termination later to maint). - (merge 9a4cb8781e cb/notes-freeing-always-null-fix later to maint). - (merge 3006f5ee16 ma/reset-doc-rendering-fix later to maint). - (merge 4c2eb06419 sg/daemon-test-signal-fix later to maint). - (merge d27525e519 ss/msvc-strcasecmp later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.20.1.txt b/third_party/git/Documentation/RelNotes/2.20.1.txt deleted file mode 100644 index dcba888dba..0000000000 --- a/third_party/git/Documentation/RelNotes/2.20.1.txt +++ /dev/null @@ -1,20 +0,0 @@ -Git v2.20.1 Release Notes -========================= - -This release is primarily to fix brown-paper-bag breakages in the -2.20.0 release. - -Fixes since v2.20 ------------------ - - * A few newly added tests were not portable and caused minority - platforms to report false breakages, which have been fixed. - - * Portability fix for a recent update to parse-options API. - - * "git help -a" did not work well when an overly long alias is - defined, which has been corrected. - - * A recent update accidentally squelched an error message when the - run_command API failed to run a missing command, which has been - corrected. diff --git a/third_party/git/Documentation/RelNotes/2.21.0.txt b/third_party/git/Documentation/RelNotes/2.21.0.txt deleted file mode 100644 index 7a49deddf3..0000000000 --- a/third_party/git/Documentation/RelNotes/2.21.0.txt +++ /dev/null @@ -1,451 +0,0 @@ -Git 2.21 Release Notes -====================== - -Backward Compatibility Notes ----------------------------- - - * Historically, the "-m" (mainline) option can only be used for "git - cherry-pick" and "git revert" when working with a merge commit. - This version of Git no longer warns or errors out when working with - a single-parent commit, as long as the argument to the "-m" option - is 1 (i.e. it has only one parent, and the request is to pick or - revert relative to that first parent). Scripts that relied on the - behaviour may get broken with this change. - - -Updates since v2.20 -------------------- - -UI, Workflows & Features - - * The "http.version" configuration variable can be used with recent - enough versions of cURL library to force the version of HTTP used - to talk when fetching and pushing. - - * Small fixes and features for fast-export and fast-import, mostly on - the fast-export side has been made. - - * "git push $there $src:$dst" rejects when $dst is not a fully - qualified refname and it is not clear what the end user meant. The - codepath has been taught to give a clearer error message, and also - guess where the push should go by taking the type of the pushed - object into account (e.g. a tag object would want to go under - refs/tags/). - - * "git checkout [<tree-ish>] path..." learned to report the number of - paths that have been checked out of the index or the tree-ish, - which gives it the same degree of noisy-ness as the case in which - the command checks out a branch. "git checkout -m <pathspec>" to - undo conflict resolution gives a similar message. - - * "git quiltimport" learned "--keep-non-patch" option. - - * "git worktree remove" and "git worktree move" refused to work when - there is a submodule involved. This has been loosened to ignore - uninitialized submodules. - - * "git cherry-pick -m1" was forbidden when picking a non-merge - commit, even though there _is_ parent number 1 for such a commit. - This was done to avoid mistakes back when "cherry-pick" was about - picking a single commit, but is no longer useful with "cherry-pick" - that can pick a range of commits. Now the "-m$num" option is - allowed when picking any commit, as long as $num names an existing - parent of the commit. - - * Update "git multimail" from the upstream. - - * "git p4" update. - - * The "--format=<placeholder>" option of for-each-ref, branch and tag - learned to show a few more traits of objects that can be learned by - the object_info API. - - * "git rebase -i" learned to re-execute a command given with 'exec' - to run after it failed the last time. - - * "git diff --color-moved-ws" updates. - - * Custom userformat "log --format" learned %S atom that stands for - the tip the traversal reached the commit from, i.e. --source. - - * "git instaweb" learned to drive http.server that comes with - "batteries included" Python installation (both Python2 & 3). - - * A new encoding UTF-16LE-BOM has been invented to force encoding to - UTF-16 with BOM in little endian byte order, which cannot be directly - generated by using iconv. - - * A new date format "--date=human" that morphs its output depending - on how far the time is from the current time has been introduced. - "--date=auto:human" can be used to use this new format (or any - existing format) when the output is going to the pager or to the - terminal, and otherwise the default format. - - -Performance, Internal Implementation, Development Support etc. - - * Code clean-up with optimization for the codepath that checks - (non-)existence of loose objects. - - * More codepaths have become aware of working with in-core repository - instances other than the default "the_repository". - - * The "strncat()" function is now among the banned functions. - - * Portability updates for the HPE NonStop platform. - - * Earlier we added "-Wformat-security" to developer builds, assuming - that "-Wall" (which includes "-Wformat" which in turn is required - to use "-Wformat-security") is always in effect. This is not true - when config.mak.autogen is in use, unfortunately. This has been - fixed by unconditionally adding "-Wall" to developer builds. - - * The loose object cache used to optimize existence look-up has been - updated. - - * Flaky tests can now be repeatedly run under load with the - "--stress" option. - - * Documentation/Makefile is getting prepared for manpage - localization. - - * "git fetch-pack" now can talk the version 2 protocol. - - * sha-256 hash has been added and plumbed through the code to allow - building Git with the "NewHash". - - * Debugging help for http transport. - - * "git fetch --deepen=<more>" has been corrected to work over v2 - protocol. - - * The code to walk tree objects has been taught that we may be - working with object names that are not computed with SHA-1. - - * The in-core repository instances are passed through more codepaths. - - * Update the protocol message specification to allow only the limited - use of scaled quantities. This is to ensure potential compatibility - issues will not get out of hand. - - * Micro-optimize the code that prepares commit objects to be walked - by "git rev-list" when the commit-graph is available. - - * "git fetch" and "git upload-pack" learned to send all exchanges over - the sideband channel while talking the v2 protocol. - - * The codepath to write out commit-graph has been optimized by - following the usual pattern of visiting objects in in-pack order. - - * The codepath to show progress meter while writing out commit-graph - file has been improved. - - * Cocci rules have been updated to encourage use of strbuf_addbuf(). - - * "git rebase --merge" has been reimplemented by reusing the internal - machinery used for "git rebase -i". - - * More code in "git bisect" has been rewritten in C. - - * Instead of going through "git-rebase--am" scriptlet to use the "am" - backend, the built-in version of "git rebase" learned to drive the - "am" backend directly. - - * The assumption to work on the single "in-core index" instance has - been reduced from the library-ish part of the codebase. - - * The test lint learned to catch non-portable "sed" options. - - * "git pack-objects" learned another algorithm to compute the set of - objects to send, that trades the resulting packfile off to save - traversal cost to favor small pushes. - - * The travis CI scripts have been corrected to build Git with the - compiler(s) of our choice. - - * "git submodule update" learned to abort early when core.worktree - for the submodule is not set correctly to prevent spreading damage. - - * Test suite has been adjusted to run on Azure Pipeline. - - * Running "Documentation/doc-diff x" from anywhere other than the - top-level of the working tree did not show the usage string - correctly, which has been fixed. - - * Use of the sparse tool got easier to customize from the command - line to help developers. - - * A new target "coverage-prove" to run the coverage test under - "prove" has been added. - - * A flakey "p4" test has been removed. - - * The code and tests assume that the system supplied iconv() would - always use BOM in its output when asked to encode to UTF-16 (or - UTF-32), but apparently some implementations output big-endian - without BOM. A compile-time knob has been added to help such - systems (e.g. NonStop) to add BOM to the output to increase - portability. - - -Fixes since v2.20 ------------------ - - * Updates for corner cases in merge-recursive. - (merge cc4cb0902c en/merge-path-collision later to maint). - - * "git checkout frotz" (without any double-dash) avoids ambiguity by - making sure 'frotz' cannot be interpreted as a revision and as a - path at the same time. This safety has been updated to check also - a unique remote-tracking branch 'frotz' in a remote, when dwimming - to create a local branch 'frotz' out of a remote-tracking branch - 'frotz' from a remote. - (merge be4908f103 nd/checkout-dwim-fix later to maint). - - * Refspecs configured with "git -c var=val clone" did not propagate - to the resulting repository, which has been corrected. - (merge 7eae4a3ac4 sg/clone-initial-fetch-configuration later to maint). - - * A properly configured username/email is required under - user.useConfigOnly in order to create commits; now "git stash" - (even though it creates commit objects to represent stash entries) - command is exempt from the requirement. - (merge 3bc2111fc2 sd/stash-wo-user-name later to maint). - - * The http-backend CGI process did not correctly clean up the child - processes it spawns to run upload-pack etc. when it dies itself, - which has been corrected. - (merge 02818a98d7 mk/http-backend-kill-children-before-exit later to maint). - - * "git rev-list --exclude-promisor-objects" had to take an object - that does not exist locally (and is lazily available) from the - command line without barfing, but the code dereferenced NULL. - (merge 4cf67869b2 md/list-lazy-objects-fix later to maint). - - * The traversal over tree objects has learned to honor - ":(attr:label)" pathspec match, which has been implemented only for - enumerating paths on the filesystem. - (merge 5a0b97b34c nd/attr-pathspec-in-tree-walk later to maint). - - * BSD port updates. - (merge 4e3ecbd439 cb/openbsd-allows-reading-directory later to maint). - (merge b6bdc2a0f5 cb/t5004-empty-tar-archive-fix later to maint). - (merge 82cbc8cde2 cb/test-lint-cp-a later to maint). - - * Lines that begin with a certain keyword that come over the wire, as - well as lines that consist only of one of these keywords, ought to - be painted in color for easier eyeballing, but the latter was - broken ever since the feature was introduced in 2.19, which has - been corrected. - (merge 1f67290450 hn/highlight-sideband-keywords later to maint). - - * "git log -G<regex>" looked for a hunk in the "git log -p" patch - output that contained a string that matches the given pattern. - Optimize this code to ignore binary files, which by default will - not show any hunk that would match any pattern (unless textconv or - the --text option is in effect, that is). - (merge e0e7cb8080 tb/log-G-binary later to maint). - - * "git submodule update" ought to use a single job unless asked, but - by mistake used multiple jobs, which has been fixed. - (merge e3a9d1aca9 sb/submodule-fetchjobs-default-to-one later to maint). - - * "git stripspace" should be usable outside a git repository, but - under the "-s" or "-c" mode, it didn't. - (merge 957da75802 jn/stripspace-wo-repository later to maint). - - * Some of the documentation pages formatted incorrectly with - Asciidoctor, which have been fixed. - (merge b62eb1d2f4 ma/asciidoctor later to maint). - - * The core.worktree setting in a submodule repository should not be - pointing at a directory when the submodule loses its working tree - (e.g. getting deinit'ed), but the code did not properly maintain - this invariant. - - * With zsh, "git cmd path<TAB>" was completed to "git cmd path name" - when the completed path has a special character like SP in it, - without any attempt to keep "path name" a single filename. This - has been fixed to complete it to "git cmd path\ name" just like - Bash completion does. - - * The test suite tried to see if it is run under bash, but the check - itself failed under some other implementations of shell (notably - under NetBSD). This has been corrected. - (merge 54ea72f09c sg/test-bash-version-fix later to maint). - - * "git gc" and "git repack" did not close the open packfiles that - they found unneeded before removing them, which didn't work on a - platform incapable of removing an open file. This has been - corrected. - (merge 5bdece0d70 js/gc-repack-close-before-remove later to maint). - - * The code to drive GIT_EXTERNAL_DIFF command relied on the string - returned from getenv() to be non-volatile, which is not true, that - has been corrected. - (merge 6776a84dae kg/external-diff-save-env later to maint). - - * There were many places the code relied on the string returned from - getenv() to be non-volatile, which is not true, that have been - corrected. - (merge 0da0e9268b jk/save-getenv-result later to maint). - - * The v2 upload-pack protocol implementation failed to honor - hidden-ref configuration, which has been corrected. - (merge e20b4192a3 jk/proto-v2-hidden-refs-fix later to maint). - - * "git fetch --recurse-submodules" may not fetch the necessary commit - that is bound to the superproject, which is getting corrected. - (merge be76c21282 sb/submodule-recursive-fetch-gets-the-tip later to maint). - - * "git rebase" internally runs "checkout" to switch between branches, - and the command used to call the post-checkout hook, but the - reimplementation stopped doing so, which is getting fixed. - - * "git add -e" got confused when the change it wants to let the user - edit is smaller than the previous change that was left over in a - temporary file. - (merge fa6f225e01 js/add-e-clear-patch-before-stating later to maint). - - * "git p4" failed to update a shelved change when there were moved - files, which has been corrected. - (merge 7a10946ab9 ld/git-p4-shelve-update-fix later to maint). - - * The codepath to read from the commit-graph file attempted to read - past the end of it when the file's table-of-contents was corrupt. - - * The compat/obstack code had casts that -Wcast-function-type - compilation option found questionable. - (merge 764473d257 sg/obstack-cast-function-type-fix later to maint). - - * An obvious typo in an assertion error message has been fixed. - (merge 3c27e2e059 cc/test-ref-store-typofix later to maint). - - * In Git for Windows, "git clone \\server\share\path" etc. that uses - UNC paths from command line had bad interaction with its shell - emulation. - - * "git add --ignore-errors" did not work as advertised and instead - worked as an unintended synonym for "git add --renormalize", which - has been fixed. - (merge e2c2a37545 jk/add-ignore-errors-bit-assignment-fix later to maint). - - * On a case-insensitive filesystem, we failed to compare the part of - the path that is above the worktree directory in an absolute - pathname, which has been corrected. - - * Asking "git check-attr" about a macro (e.g. "binary") on a specific - path did not work correctly, even though "git check-attr -a" listed - such a macro correctly. This has been corrected. - (merge 7b95849be4 jk/attr-macro-fix later to maint). - - * "git pack-objects" incorrectly used uninitialized mutex, which has - been corrected. - (merge edb673cf10 ph/pack-objects-mutex-fix later to maint). - - * "git checkout -b <new> [HEAD]" to create a new branch from the - current commit and check it out ought to be a no-op in the index - and the working tree in normal cases, but there are corner cases - that do require updates to the index and the working tree. Running - it immediately after "git clone --no-checkout" is one of these - cases that an earlier optimization kicked in incorrectly, which has - been fixed. - (merge 8424bfd45b bp/checkout-new-branch-optim later to maint). - - * "git diff --color-moved --cc --stat -p" did not work well due to - funny interaction between a bug in color-moved and the rest, which - has been fixed. - (merge dac03b5518 jk/diff-cc-stat-fixes later to maint). - - * When GIT_SEQUENCE_EDITOR is set, the command was incorrectly - started when modes of "git rebase" that implicitly uses the - machinery for the interactive rebase are run, which has been - corrected. - (merge 891d4a0313 pw/no-editor-in-rebase-i-implicit later to maint). - - * The commit-graph facility did not work when in-core objects that - are promoted from unknown type to commit (e.g. a commit that is - accessed via a tag that refers to it) were involved, which has been - corrected. - (merge 4468d4435c sg/object-as-type-commit-graph-fix later to maint). - - * "git fetch" output cleanup. - (merge dc40b24df4 nd/fetch-compact-update later to maint). - - * "git cat-file --batch" reported a dangling symbolic link by - mistake, when it wanted to report that a given name is ambiguous. - - * Documentation around core.crlf has been updated. - (merge c9446f0504 jk/autocrlf-overrides-eol-doc later to maint). - - * The documentation of "git commit-tree" said that the command - understands "--gpg-sign" in addition to "-S", but the command line - parser did not know about the longhand, which has been corrected. - - * "git rebase -x $cmd" did not reject multi-line command, even though - the command is incapable of handling such a command. It now is - rejected upfront. - (merge c762aada1a pw/rebase-x-sanity-check later to maint). - - * Output from "git help" was not correctly aligned, which has been - fixed. - (merge 6195a76da4 nd/help-align-command-desc later to maint). - - * The "git submodule summary" subcommand showed shortened commit - object names by mechanically truncating them at 7-hexdigit, which - has been improved to let "rev-parse --short" scale the length of - the abbreviation with the size of the repository. - (merge 0586a438f6 sh/submodule-summary-abbrev-fix later to maint). - - * The way the OSX build jobs updates its build environment used the - "--quiet" option to "brew update" command, but it wasn't all that - quiet to be useful. The use of the option has been replaced with - an explicit redirection to the /dev/null (which incidentally would - have worked around a breakage by recent updates to homebrew, which - has fixed itself already). - (merge a1ccaedd62 sg/travis-osx-brew-breakage-workaround later to maint). - - * "git --work-tree=$there --git-dir=$here describe --dirty" did not - work correctly as it did not pay attention to the location of the - worktree specified by the user by mistake, which has been - corrected. - (merge c801170b0c ss/describe-dirty-in-the-right-directory later to maint). - - * "git fetch" over protocol v2 that needs to make a second connection - to backfill tags did not clear a variable that holds shallow - repository information correctly, leading to an access of freed - piece of memory. - - * Some errors from the other side coming over smart HTTP transport - were not noticed, which has been corrected. - - * Code cleanup, docfix, build fix, etc. - (merge 89ba9a79ae hb/t0061-dot-in-path-fix later to maint). - (merge d173e799ea sb/diff-color-moved-config-option-fixup later to maint). - (merge a8f5a59067 en/directory-renames-nothanks-doc-update later to maint). - (merge ec36c42a63 nd/indentation-fix later to maint). - (merge f116ee21cd do/gitweb-strict-export-conf-doc later to maint). - (merge 112ea42663 fd/gitweb-snapshot-conf-doc-fix later to maint). - (merge 1cadad6f65 tb/use-common-win32-pathfuncs-on-cygwin later to maint). - (merge 57e9dcaa65 km/rebase-doc-typofix later to maint). - (merge b8b4cb27e6 ds/gc-doc-typofix later to maint). - (merge 3b3357626e nd/style-opening-brace later to maint). - (merge b4583d5595 es/doc-worktree-guessremote-config later to maint). - (merge cce99cd8c6 ds/commit-graph-assert-missing-parents later to maint). - (merge 0650614982 cy/completion-typofix later to maint). - (merge 6881925ef5 rs/sha1-file-close-mapped-file-on-error later to maint). - (merge bd8d6f0def en/show-ref-doc-fix later to maint). - (merge 1747125e2c cc/partial-clone-doc-typofix later to maint). - (merge e01378753d cc/fetch-error-message-fix later to maint). - (merge 54e8c11215 jk/remote-insteadof-cleanup later to maint). - (merge d609615f48 js/test-git-installed later to maint). - (merge ba170517be ja/doc-style-fix later to maint). - (merge 86fb1c4e77 km/init-doc-typofix later to maint). - (merge 5cfd4a9d10 nd/commit-doc later to maint). - (merge 9fce19a431 ab/diff-tree-doc-fix later to maint). - (merge 2e285e7803 tz/gpg-test-fix later to maint). - (merge 5427de960b kl/pretty-doc-markup-fix later to maint). - (merge 3815f64b0d js/mingw-host-cpu later to maint). - (merge 5fe81438b5 rj/sequencer-sign-off-header-static later to maint). - (merge 18a4f6be6b nd/fileno-may-be-macro later to maint). - (merge 99e9ab54ab kd/t0028-octal-del-is-377-not-777 later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.22.0.txt b/third_party/git/Documentation/RelNotes/2.22.0.txt deleted file mode 100644 index 91e6ae9887..0000000000 --- a/third_party/git/Documentation/RelNotes/2.22.0.txt +++ /dev/null @@ -1,597 +0,0 @@ -Git 2.22 Release Notes -====================== - -Updates since v2.21 -------------------- - -Backward compatibility note - - * The filter specification "--filter=sparse:path=<path>" used to - create a lazy/partial clone has been removed. Using a blob that is - part of the project as sparse specification is still supported with - the "--filter=sparse:oid=<blob>" option. - -UI, Workflows & Features - - * "git checkout --no-overlay" can be used to trigger a new mode of - checking out paths out of the tree-ish, that allows paths that - match the pathspec that are in the current index and working tree - and are not in the tree-ish. - - * The %(trailers) formatter in "git log --format=..." now allows to - optionally pick trailers selectively by keyword, show only values, - etc. - - * Four new configuration variables {author,committer}.{name,email} - have been introduced to override user.{name,email} in more specific - cases. - - * Command-line completion (in contrib/) learned to tab-complete the - "git submodule absorbgitdirs" subcommand. - - * "git branch" learned a new subcommand "--show-current". - - * Output from "diff --cc" did not show the original paths when the - merge involved renames. A new option adds the paths in the - original trees to the output. - - * The command line completion (in contrib/) has been taught to - complete more subcommand parameters. - - * The final report from "git bisect" used to show the suspected - culprit using a raw "diff-tree", with which there is no output for - a merge commit. This has been updated to use a more modern and - human readable output that still is concise enough. - - * "git rebase --rebase-merges" replaces its old "--preserve-merges" - option; the latter is now marked as deprecated. - - * Error message given while cloning with --recurse-submodules has - been updated. - - * The completion helper code now pays attention to repository-local - configuration (when available), which allows --list-cmds to honour - a repository specific setting of completion.commands, for example. - - * "git mergetool" learned to offer Sublime Merge (smerge) as one of - its backends. - - * A new hook "post-index-change" is called when the on-disk index - file changes, which can help e.g. a virtualized working tree - implementation. - - * "git difftool" can now run outside a repository. - - * "git checkout -m <other>" was about carrying the differences - between HEAD and the working-tree files forward while checking out - another branch, and ignored the differences between HEAD and the - index. The command has been taught to abort when the index and the - HEAD are different. - - * A progress indicator has been added to the "index-pack" step, which - often makes users wait for completion during "git clone". - - * "git submodule" learns "set-branch" subcommand that allows the - submodule.*.branch settings to be modified. - - * "git merge-recursive" backend recently learned a new heuristics to - infer file movement based on how other files in the same directory - moved. As this is inherently less robust heuristics than the one - based on the content similarity of the file itself (rather than - based on what its neighbours are doing), it sometimes gives an - outcome unexpected by the end users. This has been toned down to - leave the renamed paths in higher/conflicted stages in the index so - that the user can examine and confirm the result. - - * "git tag" learned to give an advice suggesting it might be a - mistake when creating an annotated or signed tag that points at - another tag. - - * The "git pack-objects" command learned to report the number of - objects it packed via the trace2 mechanism. - - * The list of conflicted paths shown in the editor while concluding a - conflicted merge was shown above the scissors line when the - clean-up mode is set to "scissors", even though it was commented - out just like the list of updated paths and other information to - help the user explain the merge better. - - * The trace2 tracing facility learned to auto-generate a filename - when told to log to a directory. - - * "git clone" learned a new --server-option option when talking over - the protocol version 2. - - * The connectivity bitmaps are created by default in bare - repositories now; also the pathname hash-cache is created by - default to avoid making crappy deltas when repacking. - - * "git branch new A...B" and "git checkout -b new A...B" have been - taught that in their contexts, the notation A...B means "the merge - base between these two commits", just like "git checkout A...B" - detaches HEAD at that commit. - - * Update "git difftool" and "git mergetool" so that the combinations - of {diff,merge}.{tool,guitool} configuration variables serve as - fallback settings of each other in a sensible order. - - * The "--dir-diff" mode of "git difftool" is not useful in "--no-index" - mode; they are now explicitly marked as mutually incompatible. - - -Performance, Internal Implementation, Development Support etc. - - * The diff machinery, one of the oldest parts of the system, which - long predates the parse-options API, uses fairly long and complex - handcrafted option parser. This is being rewritten to use the - parse-options API. - - * The implementation of pack-redundant has been updated for - performance in a repository with many packfiles. - - * A more structured way to obtain execution trace has been added. - - * "git prune" has been taught to take advantage of reachability - bitmap when able. - - * The command line parser of "git commit-tree" has been rewritten to - use the parse-options API. - - * Suggest GitGitGadget instead of submitGit as a way to submit - patches based on GitHub PR to us. - - * The test framework has been updated to help developers by making it - easier to run most of the tests under different versions of - over-the-wire protocols. - - * Dev support update to make it easier to compare two formatted - results from our documentation. - - * The scripted "git rebase" implementation has been retired. - - * "git multi-pack-index verify" did not scale well with the number of - packfiles, which is being improved. - - * "git stash" has been rewritten in C. - - * The "check-docs" Makefile target to support developers has been - updated. - - * The tests have been updated not to rely on the abbreviated option - names the parse-options API offers, to protect us from an - abbreviated form of an option that used to be unique within the - command getting non-unique when a new option that share the same - prefix is added. - - * The scripted version of "git rebase -i" wrote and rewrote the todo - list many times during a single step of its operation, and the - recent C-rewrite made a faithful conversion of the logic to C. The - implementation has been updated to carry necessary information - around in-core to avoid rewriting the same file over and over - unnecessarily. - - * Test framework update to more robustly clean up leftover files and - processes after tests are done. - - * Conversion from unsigned char[20] to struct object_id continues. - - * While running "git diff" in a lazy clone, we can upfront know which - missing blobs we will need, instead of waiting for the on-demand - machinery to discover them one by one. The code learned to aim to - achieve better performance by batching the request for these - promised blobs. - - * During an initial "git clone --depth=..." partial clone, it is - pointless to spend cycles for a large portion of the connectivity - check that enumerates and skips promisor objects (which by - definition is all objects fetched from the other side). This has - been optimized out. - - * Mechanically and systematically drop "extern" from function - declaration. - - * The script to aggregate perf result unconditionally depended on - libjson-perl even though it did not have to, which has been - corrected. - - * The internal implementation of "git rebase -i" has been updated to - avoid forking a separate "rebase--interactive" process. - - * Allow DEP and ASLR for Windows build to for security hardening. - - * Performance test framework has been broken and measured the version - of Git that happens to be on $PATH, not the specified one to - measure, for a while, which has been corrected. - - * Optionally "make coccicheck" can feed multiple source files to - spatch, gaining performance while spending more memory. - - * Attempt to use an abbreviated option in "git clone --recurs" is - responded by a request to disambiguate between --recursive and - --recurse-submodules, which is bad because these two are synonyms. - The parse-options API has been extended to define such synonyms - more easily and not produce an unnecessary failure. - - * A pair of private functions in http.c that had names similar to - fread/fwrite did not return the number of elements, which was found - to be confusing. - - * Update collision-detecting SHA-1 code to build properly on HP-UX. - - -Fixes since v2.21 ------------------ - - * "git prune-packed" did not notice and complain against excess - arguments given from the command line, which now it does. - (merge 9b0bd87ed2 rj/prune-packed-excess-args later to maint). - - * Split-index fix. - (merge 6e37c8ed3c nd/split-index-null-base-fix later to maint). - - * "git diff --no-index" may still want to access Git goodies like - --ext-diff and --textconv, but so far these have been ignored, - which has been corrected. - (merge 287ab28bfa jk/diff-no-index-initialize later to maint). - - * Unify RPC code for smart http in protocol v0/v1 and v2, which fixes - a bug in the latter (lack of authentication retry) and generally - improves the code base. - (merge a97d00799a jt/http-auth-proto-v2-fix later to maint). - - * The include file compat/bswap.h has been updated so that it is safe - to (accidentally) include it more than once. - (merge 33aa579a55 jk/guard-bswap-header later to maint). - - * The set of header files used by "make hdr-check" unconditionally - included sha256/gcrypt.h, even when it is not used, causing the - make target to fail. We now skip it when GCRYPT_SHA256 is not in - use. - (merge f23aa18e7f rj/hdr-check-gcrypt-fix later to maint). - - * The Makefile uses 'find' utility to enumerate all the *.h header - files, which is expensive on platforms with slow filesystems; it - now optionally uses "ls-files" if working within a repository, - which is a trick similar to how all sources are enumerated to run - ETAGS on. - (merge 92b88eba9f js/find-lib-h-with-ls-files-when-possible later to maint). - - * "git rebase" that was reimplemented in C did not set ORIG_HEAD - correctly, which has been corrected. - (merge cbd29ead92 js/rebase-orig-head-fix later to maint). - - * Dev support. - (merge f545737144 js/stress-test-ui-tweak later to maint). - - * CFLAGS now can be tweaked when invoking Make while using - DEVELOPER=YesPlease; this did not work well before. - (merge 6d5d4b4e93 ab/makefile-help-devs-more later to maint). - - * "git fsck --connectivity-only" omits computation necessary to sift - the objects that are not reachable from any of the refs into - unreachable and dangling. This is now enabled when dangling - objects are requested (which is done by default, but can be - overridden with the "--no-dangling" option). - (merge 8d8c2a5aef jk/fsck-doc later to maint). - - * On platforms where "git fetch" is killed with SIGPIPE (e.g. OSX), - the upload-pack that runs on the other end that hangs up after - detecting an error could cause "git fetch" to die with a signal, - which led to a flaky test. "git fetch" now ignores SIGPIPE during - the network portion of its operation (this is not a problem as we - check the return status from our write(2)s). - (merge 143588949c jk/no-sigpipe-during-network-transport later to maint). - - * A recent update broke "is this object available to us?" check for - well-known objects like an empty tree (which should yield "yes", - even when there is no on-disk object for an empty tree), which has - been corrected. - (merge f06ab027ef jk/virtual-objects-do-exist later to maint). - - * The setup code has been cleaned up to avoid leaks around the - repository_format structure. - (merge e8805af1c3 ma/clear-repository-format later to maint). - - * "git config --type=color ..." is meant to replace "git config --get-color" - but there is a slight difference that wasn't documented, which is - now fixed. - (merge cd8e7593b9 jk/config-type-color-ends-with-lf later to maint). - - * When the "clean" filter can reduce the size of a huge file in the - working tree down to a small "token" (a la Git LFS), there is no - point in allocating a huge scratch area upfront, but the buffer is - sized based on the original file size. The convert mechanism now - allocates very minimum and reallocates as it receives the output - from the clean filter process. - (merge 02156ab031 jh/resize-convert-scratch-buffer later to maint). - - * "git rebase" uses the refs/rewritten/ hierarchy to store its - intermediate states, which inherently makes the hierarchy per - worktree, but it didn't quite work well. - (merge b9317d55a3 nd/rewritten-ref-is-per-worktree later to maint). - - * "git log -L<from>,<to>:<path>" with "-s" did not suppress the patch - output as it should. This has been corrected. - (merge 05314efaea jk/line-log-with-patch later to maint). - - * "git worktree add" used to do a "find an available name with stat - and then mkdir", which is race-prone. This has been fixed by using - mkdir and reacting to EEXIST in a loop. - (merge 7af01f2367 ms/worktree-add-atomic-mkdir later to maint). - - * Build update for SHA-1 with collision detection. - (merge 07a20f569b jk/sha1dc later to maint). - - * Build procedure has been fixed around use of asciidoctor instead of - asciidoc. - (merge 185f9a0ea0 ma/asciidoctor-fixes later to maint). - - * remote-http transport did not anonymize URLs reported in its error - messages at places. - (merge c1284b21f2 js/anonymize-remote-curl-diag later to maint). - - * Error messages given from the http transport have been updated so - that they can be localized. - (merge ed8b4132c8 js/remote-curl-i18n later to maint). - - * "git init" forgot to read platform-specific repository - configuration, which made Windows port to ignore settings of - core.hidedotfiles, for example. - - * A corner-case object name ambiguity while the sequencer machinery - is working (e.g. "rebase -i -x") has been fixed. - - * "git format-patch" did not diagnose an error while opening the - output file for the cover-letter, which has been corrected. - (merge 2fe95f494c jc/format-patch-error-check later to maint). - - * "git checkout -f <branch>" while the index has an unmerged path - incorrectly left some paths in an unmerged state, which has been - corrected. - - * A corner case bug in the refs API has been corrected. - (merge d3322eb28b jk/refs-double-abort later to maint). - - * Unicode update. - (merge 584b62c37b bb/unicode-12 later to maint). - - * dumb-http walker has been updated to share more error recovery - strategy with the normal codepath. - - * A buglet in configuration parser has been fixed. - (merge 19e7fdaa58 nd/include-if-wildmatch later to maint). - - * The documentation for "git read-tree --reset -u" has been updated. - (merge b5a0bd694c nd/read-tree-reset-doc later to maint). - - * Code clean-up around a much-less-important-than-it-used-to-be - update_server_info() function. - (merge b3223761c8 jk/server-info-rabbit-hole later to maint). - - * The message given when "git commit -a <paths>" errors out has been - updated. - (merge 5a1dbd48bc nd/commit-a-with-paths-msg-update later to maint). - - * "git cherry-pick --options A..B", after giving control back to the - user to ask help resolving a conflicted step, did not honor the - options it originally received, which has been corrected. - - * Various glitches in "git gc" around reflog handling have been fixed. - - * The code to read from commit-graph file has been cleanup with more - careful error checking before using data read from it. - - * Performance fix around "git fetch" that grabs many refs. - (merge b764300912 jt/fetch-pack-wanted-refs-optim later to maint). - - * Protocol v2 support in "git fetch-pack" of shallow clones has been - corrected. - - * Performance fix around "git blame", especially in a linear history - (which is the norm we should optimize for). - (merge f892014943 dk/blame-keep-origin-blob later to maint). - - * Performance fix for "rev-list --parents -- pathspec". - (merge 8320b1dbe7 jk/revision-rewritten-parents-in-prio-queue later to maint). - - * Updating the display with progress message has been cleaned up to - deal better with overlong messages. - (merge 545dc345eb sg/overlong-progress-fix later to maint). - - * "git blame -- path" in a non-bare repository starts blaming from - the working tree, and the same command in a bare repository errors - out because there is no working tree by definition. The command - has been taught to instead start blaming from the commit at HEAD, - which is more useful. - (merge a544fb08f8 sg/blame-in-bare-start-at-head later to maint). - - * An underallocation in the code to read the untracked cache - extension has been corrected. - (merge 3a7b45a623 js/untracked-cache-allocfix later to maint). - - * The code is updated to check the result of memory allocation before - it is used in more places, by using xmalloc and/or xcalloc calls. - (merge 999b951b28 jk/xmalloc later to maint). - - * The GETTEXT_POISON test option has been quite broken ever since it - was made runtime-tunable, which has been fixed. - (merge f88b9cb603 jc/gettext-test-fix later to maint). - - * Test fix on APFS that is incapable of store paths in Latin-1. - (merge 3889149619 js/iso8895-test-on-apfs later to maint). - - * "git submodule foreach <command> --quiet" did not pass the option - down correctly, which has been corrected. - (merge a282f5a906 nd/submodule-foreach-quiet later to maint). - - * "git send-email" has been taught to use quoted-printable when the - payload contains carriage-return. The use of the mechanism is in - line with the design originally added the codepath that chooses QP - when the payload has overly long lines. - (merge 74d76a1701 bc/send-email-qp-cr later to maint). - - * The recently added feature to add addresses that are on - anything-by: trailers in 'git send-email' was found to be way too - eager and considered nonsense strings as if they can be legitimate - beginning of *-by: trailer. This has been tightened. - - * Builds with gettext broke on recent macOS w/ Homebrew, which - seems to have stopped including from /usr/local/include; this - has been corrected. - (merge 92a1377a2a js/macos-gettext-build later to maint). - - * Running "git add" on a repository created inside the current - repository is an explicit indication that the user wants to add it - as a submodule, but when the HEAD of the inner repository is on an - unborn branch, it cannot be added as a submodule. Worse, the files - in its working tree can be added as if they are a part of the outer - repository, which is not what the user wants. These problems are - being addressed. - (merge f937bc2f86 km/empty-repo-is-still-a-repo later to maint). - - * "git cherry-pick" run with the "-x" or the "--signoff" option used - to (and more importantly, ought to) clean up the commit log message - with the --cleanup=space option by default, but this has been - broken since late 2017. This has been fixed. - - * When given a tag that points at a commit-ish, "git replace --graft" - failed to peel the tag before writing a replace ref, which did not - make sense because the old graft mechanism the feature wants to - mimic only allowed to replace one commit object with another. - This has been fixed. - (merge ee521ec4cb cc/replace-graft-peel-tags later to maint). - - * Code tightening against a "wrong" object appearing where an object - of a different type is expected, instead of blindly assuming that - the connection between objects are correctly made. - (merge 97dd512af7 tb/unexpected later to maint). - - * An earlier update for MinGW and Cygwin accidentally broke MSVC build, - which has been fixed. - (merge 22c3634c0f ss/msvc-path-utils-fix later to maint). - - * %(push:track) token used in the --format option to "git - for-each-ref" and friends was not showing the right branch, which - has been fixed. - (merge c646d0934e dr/ref-filter-push-track-fix later to maint). - - * "make check-docs", "git help -a", etc. did not account for cases - where a particular build may deliberately omit some subcommands, - which has been corrected. - - * The logic to tell if a Git repository has a working tree protects - "git branch -D" from removing the branch that is currently checked - out by mistake. The implementation of this logic was broken for - repositories with unusual name, which unfortunately is the norm for - submodules these days. This has been fixed. - (merge f3534c98e4 jt/submodule-repo-is-with-worktree later to maint). - - * AIX shared the same build issues with other BSDs around fileno(fp), - which has been corrected. - (merge ee662bf5c6 cc/aix-has-fileno-as-a-macro later to maint). - - * The autoconf generated configure script failed to use the right - gettext() implementations from -libintl by ignoring useless stub - implementations shipped in some C library, which has been - corrected. - (merge b71e56a683 vk/autoconf-gettext later to maint). - - * Fix index-pack perf test so that the repeated invocations always - run in an empty repository, which emulates the initial clone - situation better. - (merge 775c71e16d jk/p5302-avoid-collision-check-cost later to maint). - - * A "ls-files" that emulates "find" to enumerate files in the working - tree resulted in duplicated Makefile rules that caused the build to - issue an unnecessary warning during a trial build after merge - conflicts are resolved in working tree *.h files but before the - resolved results are added to the index. This has been corrected. - - * "git cherry-pick" (and "revert" that shares the same runtime engine) - that deals with multiple commits got confused when the final step - gets stopped with a conflict and the user concluded the sequence - with "git commit". Attempt to fix it by cleaning up the state - files used by these commands in such a situation. - (merge 4a72486de9 pw/clean-sequencer-state-upon-final-commit later to maint). - - * On a filesystem like HFS+, the names of the refs stored as filesystem - entities may become different from what the end-user expects, just - like files in the working tree get "renamed". Work around the - mismatch by paying attention to the core.precomposeUnicode - configuration. - (merge 8e712ef6fc en/unicode-in-refnames later to maint). - - * The code to generate the multi-pack idx file was not prepared to - see too many packfiles and ran out of open file descriptor, which - has been corrected. - - * To run tests for Git SVN, our scripts for CI used to install the - git-svn package (in the hope that it would bring in the right - dependencies). This has been updated to install the more direct - dependency, namely, libsvn-perl. - (merge db864306cf sg/ci-libsvn-perl later to maint). - - * "git cvsexportcommit" running on msys did not expect cvsnt showed - "cvs status" output with CRLF line endings. - - * The fsmonitor interface got out of sync after the in-core index - file gets discarded, which has been corrected. - (merge 398a3b0899 js/fsmonitor-refresh-after-discarding-index later to maint). - - * "git status" did not know that the "label" instruction in the - todo-list "rebase -i -r" uses should not be shown as a hex object - name. - - * A prerequisite check in the test suite to see if a working jgit is - available was made more robust. - (merge abd0f28983 tz/test-lib-check-working-jgit later to maint). - - * The codepath to parse :<path> that obtains the object name for an - indexed object has been made more robust. - - * Code cleanup, docfix, build fix, etc. - (merge 11f470aee7 jc/test-yes-doc later to maint). - (merge 90503a240b js/doc-symref-in-proto-v1 later to maint). - (merge 5c326d1252 jk/unused-params later to maint). - (merge 68cabbfda3 dl/doc-submodule-wo-subcommand later to maint). - (merge 9903623761 ab/receive-pack-use-after-free-fix later to maint). - (merge 1ede45e44b en/merge-options-doc later to maint). - (merge 3e14dd2c8e rd/doc-hook-used-in-sample later to maint). - (merge c271dc28fd nd/no-more-check-racy later to maint). - (merge e6e15194a8 yb/utf-16le-bom-spellfix later to maint). - (merge bb101aaf0c rd/attr.c-comment-typofix later to maint). - (merge 716a5af812 rd/gc-prune-doc-fix later to maint). - (merge 50b206371d js/untravis-windows later to maint). - (merge dbf47215e3 js/rebase-recreate-merge later to maint). - (merge 56cb2d30f8 dl/reset-doc-no-wrt-abbrev later to maint). - (merge 64eca306a2 ja/dir-rename-doc-markup-fix later to maint). - (merge af91b0230c dl/ignore-docs later to maint). - (merge 59a06e947b ra/t3600-test-path-funcs later to maint). - (merge e041d0781b ar/t4150-remove-cruft later to maint). - (merge 8d75a1d183 ma/asciidoctor-fixes-more later to maint). - (merge 74cc547b0f mh/pack-protocol-doc-fix later to maint). - (merge ed31851fa6 ab/doc-misc-typofixes later to maint). - (merge a7256debd4 nd/checkout-m-doc-update later to maint). - (merge 3a9e1ad78d jt/t5551-protocol-v2-does-not-have-half-auth later to maint). - (merge 0b918b75af sg/t5318-cleanup later to maint). - (merge 68ed71b53c cb/doco-mono later to maint). - (merge a34dca2451 nd/interpret-trailers-docfix later to maint). - (merge cf7b857a77 en/fast-import-parsing-fix later to maint). - (merge fe61ccbc35 po/rerere-doc-fmt later to maint). - (merge ffea0248bf po/describe-not-necessarily-7 later to maint). - (merge 7cb7283adb tg/ls-files-debug-format-fix later to maint). - (merge f64a21bd82 tz/doc-apostrophe-no-longer-needed later to maint). - (merge dbe7b41019 js/t3301-unbreak-notes-test later to maint). - (merge d8083e4180 km/t3000-retitle later to maint). - (merge 9e4cbccbd7 tz/git-svn-doc-markup-fix later to maint). - (merge da9ca955a7 jk/ls-files-doc-markup-fix later to maint). - (merge 6804ba3a58 cw/diff-highlight later to maint). - (merge 1a8787144d nd/submodule-helper-incomplete-line-fix later to maint). - (merge d9ef573837 jk/apache-lsan later to maint). - (merge c871fbee2b js/t6500-use-windows-pid-on-mingw later to maint). - (merge ce4c7bfc90 bl/t4253-exit-code-from-format-patch later to maint). - (merge 397a46db78 js/t5580-unc-alternate-test later to maint). - (merge d4907720a2 cm/notes-comment-fix later to maint). - (merge 9dde06de13 cb/http-push-null-in-message-fix later to maint). - (merge 4c785c0edc js/rebase-config-bitfix later to maint). - (merge 8e9fe16c87 es/doc-gitsubmodules-markup later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.22.1.txt b/third_party/git/Documentation/RelNotes/2.22.1.txt deleted file mode 100644 index 432762f270..0000000000 --- a/third_party/git/Documentation/RelNotes/2.22.1.txt +++ /dev/null @@ -1,150 +0,0 @@ -Git 2.22.1 Release Notes -======================== - -Fixes since v2.22 ------------------ - - * A relative pathname given to "git init --template=<path> <repo>" - ought to be relative to the directory "git init" gets invoked in, - but it instead was made relative to the repository, which has been - corrected. - - * "git worktree add" used to fail when another worktree connected to - the same repository was corrupt, which has been corrected. - - * The ownership rule for the file descriptor to fast-import remote - backend was mixed up, leading to unrelated file descriptor getting - closed, which has been fixed. - - * "git update-server-info" used to leave stale packfiles in its - output, which has been corrected. - - * The server side support for "git fetch" used to show incorrect - value for the HEAD symbolic ref when the namespace feature is in - use, which has been corrected. - - * "git am -i --resolved" segfaulted after trying to see a commit as - if it were a tree, which has been corrected. - - * "git bundle verify" needs to see if prerequisite objects exist in - the receiving repository, but the command did not check if we are - in a repository upfront, which has been corrected. - - * "git merge --squash" is designed to update the working tree and the - index without creating the commit, and this cannot be countermanded - by adding the "--commit" option; the command now refuses to work - when both options are given. - - * The data collected by fsmonitor was not properly written back to - the on-disk index file, breaking t7519 tests occasionally, which - has been corrected. - - * Update to Unicode 12.1 width table. - - * The command line to invoke a "git cat-file" command from inside - "git p4" was not properly quoted to protect a caret and running a - broken command on Windows, which has been corrected. - - * "git request-pull" learned to warn when the ref we ask them to pull - from in the local repository and in the published repository are - different. - - * When creating a partial clone, the object filtering criteria is - recorded for the origin of the clone, but this incorrectly used a - hardcoded name "origin" to name that remote; it has been corrected - to honor the "--origin <name>" option. - - * "git fetch" into a lazy clone forgot to fetch base objects that are - necessary to complete delta in a thin packfile, which has been - corrected. - - * The filter_data used in the list-objects-filter (which manages a - lazily sparse clone repository) did not use the dynamic array API - correctly---'nr' is supposed to point at one past the last element - of the array in use. This has been corrected. - - * The description about slashes in gitignore patterns (used to - indicate things like "anchored to this level only" and "only - matches directories") has been revamped. - - * The URL decoding code has been updated to avoid going past the end - of the string while parsing %-<hex>-<hex> sequence. - - * The list of for-each like macros used by clang-format has been - updated. - - * "git push --atomic" that goes over the transport-helper (namely, - the smart http transport) failed to prevent refs to be pushed when - it can locally tell that one of the ref update will fail without - having to consult the other end, which has been corrected. - - * "git clean" silently skipped a path when it cannot lstat() it; now - it gives a warning. - - * A codepath that reads from GPG for signed object verification read - past the end of allocated buffer, which has been fixed. - - * "git rm" to resolve a conflicted path leaked an internal message - "needs merge" before actually removing the path, which was - confusing. This has been corrected. - - * The "git clone" documentation refers to command line options in its - description in the short form; they have been replaced with long - forms to make them more recognisable. - - * The configuration variable rebase.rescheduleFailedExec should be - effective only while running an interactive rebase and should not - affect anything when running a non-interactive one, which was not - the case. This has been corrected. - - * "git submodule foreach" did not protect command line options passed - to the command to be run in each submodule correctly, when the - "--recursive" option was in use. - - * Use "Erase in Line" CSI sequence that is already used in the editor - support to clear cruft in the progress output. - - * The codepath to compute delta islands used to spew progress output - without giving the callers any way to squelch it, which has been - fixed. - - * The code to parse scaled numbers out of configuration files has - been made more robust and also easier to follow. - - * An incorrect list of options was cached after command line - completion failed (e.g. trying to complete a command that requires - a repository outside one), which has been corrected. - - * "git rebase --abort" used to leave refs/rewritten/ when concluding - "git rebase -r", which has been corrected. - - * "git stash show 23" used to work, but no more after getting - rewritten in C; this regression has been corrected. - - * "git interpret-trailers" always treated '#' as the comment - character, regardless of core.commentChar setting, which has been - corrected. - - * Code clean-up to avoid signed integer overlaps during binary search. - - * "git checkout -p" needs to selectively apply a patch in reverse, - which did not work well. - - * The commit-graph file is now part of the "files that the runtime - may keep open file descriptors on, all of which would need to be - closed when done with the object store", and the file descriptor to - an existing commit-graph file now is closed before "gc" finalizes a - new instance to replace it. - - * Code restructuring during 2.20 period broke fetching tags via - "import" based transports. - - * We have been trying out a few language features outside c89; the - coding guidelines document did not talk about them and instead had - a blanket ban against them. - - * The internal diff machinery can be made to read out of bounds while - looking for --funcion-context line in a corner case, which has been - corrected. - -Also contains various documentation updates, code clean-ups and minor fixups. diff --git a/third_party/git/Documentation/RelNotes/2.23.0.txt b/third_party/git/Documentation/RelNotes/2.23.0.txt deleted file mode 100644 index e3c4e78265..0000000000 --- a/third_party/git/Documentation/RelNotes/2.23.0.txt +++ /dev/null @@ -1,348 +0,0 @@ -Git 2.23 Release Notes -====================== - -Updates since v2.22 -------------------- - -Backward compatibility note - - * The "--base" option of "format-patch" computed the patch-ids for - prerequisite patches in an unstable way, which has been updated to - compute in a way that is compatible with "git patch-id --stable". - - * The "git log" command by default behaves as if the --mailmap option - was given. - - -UI, Workflows & Features - - * The "git fast-export/import" pair has been taught to handle commits - with log messages in encoding other than UTF-8 better. - - * In recent versions of Git, per-worktree refs are exposed in - refs/worktrees/<wtname>/ hierarchy, which means that worktree names - must be a valid refname component. The code now sanitizes the names - given to worktrees, to make sure these refs are well-formed. - - * "git merge" learned "--quit" option that cleans up the in-progress - merge while leaving the working tree and the index still in a mess. - - * "git format-patch" learns a configuration to set the default for - its --notes=<ref> option. - - * The code to show args with potential typo that cannot be - interpreted as a commit-ish has been improved. - - * "git clone --recurse-submodules" learned to set up the submodules - to ignore commit object names recorded in the superproject gitlink - and instead use the commits that happen to be at the tip of the - remote-tracking branches from the get-go, by passing the new - "--remote-submodules" option. - - * The pattern "git diff/grep" use to extract funcname and words - boundary for Matlab has been extend to cover Octave, which is more - or less equivalent. - - * "git help git" was hard to discover (well, at least for some - people). - - * The pattern "git diff/grep" use to extract funcname and words - boundary for Rust has been added. - - * "git status" can be told a non-standard default value for the - "--[no-]ahead-behind" option with a new configuration variable - status.aheadBehind. - - * "git fetch" and "git pull" reports when a fetch results in - non-fast-forward updates to let the user notice unusual situation. - The commands learned "--no-show-forced-updates" option to disable - this safety feature. - - * Two new commands "git switch" and "git restore" are introduced to - split "checking out a branch to work on advancing its history" and - "checking out paths out of the index and/or a tree-ish to work on - advancing the current history" out of the single "git checkout" - command. - - * "git branch --list" learned to always output the detached HEAD as - the first item (when the HEAD is detached, of course), regardless - of the locale. - - * The conditional inclusion mechanism learned to base the choice on - the branch the HEAD currently is on. - - * "git rev-list --objects" learned the "--no-object-names" option to - squelch the path to the object that is used as a grouping hint for - pack-objects. - - * A new tag.gpgSign configuration variable turns "git tag -a" into - "git tag -s". - - * "git multi-pack-index" learned expire and repack subcommands. - - * "git blame" learned to "ignore" commits in the history, whose - effects (as well as their presence) get ignored. - - * "git cherry-pick/revert" learned a new "--skip" action. - - * The tips of refs from the alternate object store can be used as - starting point for reachability computation now. - - * Extra blank lines in "git status" output have been reduced. - - * The commits in a repository can be described by multiple - commit-graph files now, which allows the commit-graph files to be - updated incrementally. - - * "git range-diff" output has been tweaked for easier identification - of which part of what file the patch shown is about. - - -Performance, Internal Implementation, Development Support etc. - - * Update supporting parts of "git rebase" to remove code that should - no longer be used. - - * Developer support to emulate unsatisfied prerequisites in tests to - ensure that the remainder of the tests still succeeds when tests - with prerequisites are skipped. - - * "git update-server-info" learned not to rewrite the file with the - same contents. - - * The way of specifying the path to find dynamic libraries at runtime - has been simplified. The old default to pass -R/path/to/dir has been - replaced with the new default to pass -Wl,-rpath,/path/to/dir, - which is the more recent GCC uses. Those who need to build with an - old GCC can still use "CC_LD_DYNPATH=-R" - - * Prepare use of reachability index in topological walker that works - on a range (A..B). - - * A new tutorial targeting specifically aspiring git-core - developers has been added. - - * Auto-detect how to tell HP-UX aCC where to use dynamically linked - libraries from at runtime. - - * "git mergetool" and its tests now spawn fewer subprocesses. - - * Dev support update to help tracing out tests. - - * Support to build with MSVC has been updated. - - * "git fetch" that grabs from a group of remotes learned to run the - auto-gc only once at the very end. - - * A handful of Windows build patches have been upstreamed. - - * The code to read state files used by the sequencer machinery for - "git status" has been made more robust against a corrupt or stale - state files. - - * "git for-each-ref" with multiple patterns have been optimized. - - * The tree-walk API learned to pass an in-core repository - instance throughout more codepaths. - - * When one step in multi step cherry-pick or revert is reset or - committed, the command line prompt script failed to notice the - current status, which has been improved. - - * Many GIT_TEST_* environment variables control various aspects of - how our tests are run, but a few followed "non-empty is true, empty - or unset is false" while others followed the usual "there are a few - ways to spell true, like yes, on, etc., and also ways to spell - false, like no, off, etc." convention. - - * Adjust the dir-iterator API and apply it to the local clone - optimization codepath. - - * We have been trying out a few language features outside c89; the - coding guidelines document did not talk about them and instead had - a blanket ban against them. - - * A test helper has been introduced to optimize preparation of test - repositories with many simple commits, and a handful of test - scripts have been updated to use it. - - -Fixes since v2.22 ------------------ - - * A relative pathname given to "git init --template=<path> <repo>" - ought to be relative to the directory "git init" gets invoked in, - but it instead was made relative to the repository, which has been - corrected. - - * "git worktree add" used to fail when another worktree connected to - the same repository was corrupt, which has been corrected. - - * The ownership rule for the file descriptor to fast-import remote - backend was mixed up, leading to an unrelated file descriptor getting - closed, which has been fixed. - - * A "merge -c" instruction during "git rebase --rebase-merges" should - give the user a chance to edit the log message, even when there is - otherwise no need to create a new merge and replace the existing - one (i.e. fast-forward instead), but did not. Which has been - corrected. - - * Code cleanup and futureproof. - - * More parameter validation. - - * "git update-server-info" used to leave stale packfiles in its - output, which has been corrected. - - * The server side support for "git fetch" used to show incorrect - value for the HEAD symbolic ref when the namespace feature is in - use, which has been corrected. - - * "git am -i --resolved" segfaulted after trying to see a commit as - if it were a tree, which has been corrected. - - * "git bundle verify" needs to see if prerequisite objects exist in - the receiving repository, but the command did not check if we are - in a repository upfront, which has been corrected. - - * "git merge --squash" is designed to update the working tree and the - index without creating the commit, and this cannot be countermanded - by adding the "--commit" option; the command now refuses to work - when both options are given. - - * The data collected by fsmonitor was not properly written back to - the on-disk index file, breaking t7519 tests occasionally, which - has been corrected. - - * Update to Unicode 12.1 width table. - - * The command line to invoke a "git cat-file" command from inside - "git p4" was not properly quoted to protect a caret and running a - broken command on Windows, which has been corrected. - - * "git request-pull" learned to warn when the ref we ask them to pull - from in the local repository and in the published repository are - different. - - * When creating a partial clone, the object filtering criteria is - recorded for the origin of the clone, but this incorrectly used a - hardcoded name "origin" to name that remote; it has been corrected - to honor the "--origin <name>" option. - - * "git fetch" into a lazy clone forgot to fetch base objects that are - necessary to complete delta in a thin packfile, which has been - corrected. - - * The filter_data used in the list-objects-filter (which manages a - lazily sparse clone repository) did not use the dynamic array API - correctly---'nr' is supposed to point at one past the last element - of the array in use. This has been corrected. - - * The description about slashes in gitignore patterns (used to - indicate things like "anchored to this level only" and "only - matches directories") has been revamped. - - * The URL decoding code has been updated to avoid going past the end - of the string while parsing %-<hex>-<hex> sequence. - - * The list of for-each like macros used by clang-format has been - updated. - - * "git branch --list" learned to show branches that are checked out - in other worktrees connected to the same repository prefixed with - '+', similar to the way the currently checked out branch is shown - with '*' in front. - (merge 6e9381469e nb/branch-show-other-worktrees-head later to maint). - - * Code restructuring during 2.20 period broke fetching tags via - "import" based transports. - - * The commit-graph file is now part of the "files that the runtime - may keep open file descriptors on, all of which would need to be - closed when done with the object store", and the file descriptor to - an existing commit-graph file now is closed before "gc" finalizes a - new instance to replace it. - - * "git checkout -p" needs to selectively apply a patch in reverse, - which did not work well. - - * Code clean-up to avoid signed integer wraparounds during binary search. - - * "git interpret-trailers" always treated '#' as the comment - character, regardless of core.commentChar setting, which has been - corrected. - - * "git stash show 23" used to work, but no more after getting - rewritten in C; this regression has been corrected. - - * "git rebase --abort" used to leave refs/rewritten/ when concluding - "git rebase -r", which has been corrected. - - * An incorrect list of options was cached after command line - completion failed (e.g. trying to complete a command that requires - a repository outside one), which has been corrected. - - * The code to parse scaled numbers out of configuration files has - been made more robust and also easier to follow. - - * The codepath to compute delta islands used to spew progress output - without giving the callers any way to squelch it, which has been - fixed. - - * Protocol capabilities that go over wire should never be translated, - but it was incorrectly marked for translation, which has been - corrected. The output of protocol capabilities for debugging has - been tweaked a bit. - - * Use "Erase in Line" CSI sequence that is already used in the editor - support to clear cruft in the progress output. - - * "git submodule foreach" did not protect command line options passed - to the command to be run in each submodule correctly, when the - "--recursive" option was in use. - - * The configuration variable rebase.rescheduleFailedExec should be - effective only while running an interactive rebase and should not - affect anything when running a non-interactive one, which was not - the case. This has been corrected. - - * The "git clone" documentation refers to command line options in its - description in the short form; they have been replaced with long - forms to make them more recognisable. - - * Generation of pack bitmaps are now disabled when .keep files exist, - as these are mutually exclusive features. - (merge 7328482253 ew/repack-with-bitmaps-by-default later to maint). - - * "git rm" to resolve a conflicted path leaked an internal message - "needs merge" before actually removing the path, which was - confusing. This has been corrected. - - * "git stash --keep-index" did not work correctly on paths that have - been removed, which has been fixed. - (merge b932f6a5e8 tg/stash-keep-index-with-removed-paths later to maint). - - * Window 7 update ;-) - - * A codepath that reads from GPG for signed object verification read - past the end of allocated buffer, which has been fixed. - - * "git clean" silently skipped a path when it cannot lstat() it; now - it gives a warning. - - * "git push --atomic" that goes over the transport-helper (namely, - the smart http transport) failed to prevent refs to be pushed when - it can locally tell that one of the ref update will fail without - having to consult the other end, which has been corrected. - - * The internal diff machinery can be made to read out of bounds while - looking for --function-context line in a corner case, which has been - corrected. - (merge b777f3fd61 jk/xdiff-clamp-funcname-context-index later to maint). - - * Other code cleanup, docfix, build fix, etc. - (merge fbec05c210 cc/test-oidmap later to maint). - (merge 7a06fb038c jk/no-system-includes-in-dot-c later to maint). - (merge 81ed2b405c cb/xdiff-no-system-includes-in-dot-c later to maint). - (merge d61e6ce1dd sg/fsck-config-in-doc later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.3.0.txt b/third_party/git/Documentation/RelNotes/2.3.0.txt deleted file mode 100644 index e3c639c840..0000000000 --- a/third_party/git/Documentation/RelNotes/2.3.0.txt +++ /dev/null @@ -1,300 +0,0 @@ -Git v2.3 Release Notes -====================== - -This one ended up to be a release with lots of small corrections and -improvements without big uncomfortably exciting features. The recent -security fix that went to 2.2.1 and older maintenance tracks is also -contained in this update. - - -Updates since v2.2 ------------------- - -Ports - - * Recent gcc toolchain on Cygwin started throwing compilation warning, - which has been squelched. - - * A few updates to build on platforms that lack tv_nsec, - clock_gettime, CLOCK_MONOTONIC and HMAC_CTX_cleanup (e.g. older - RHEL) have been added. - - -UI, Workflows & Features - - * It was cumbersome to use "GIT_SSH" mechanism when the user wanted - to pass an extra set of arguments to the underlying ssh. A new - environment variable GIT_SSH_COMMAND can be used for this. - - * A request to store an empty note via "git notes" meant to remove - note from the object but with --allow-empty we will store a - (surprise!) note that is empty. - - * "git interpret-trailers" learned to properly handle the - "Conflicts:" block at the end. - - * "git am" learned "--message-id" option to copy the message ID of - the incoming e-mail to the log message of resulting commit. - - * "git clone --reference=<over there>" learned the "--dissociate" - option to go with it; it borrows objects from the reference object - store while cloning only to reduce network traffic and then - dissociates the resulting clone from the reference by performing - local copies of borrowed objects. - - * "git send-email" learned "--transfer-encoding" option to force a - non-fault Content-Transfer-Encoding header (e.g. base64). - - * "git send-email" normally identifies itself via X-Mailer: header in - the message it sends out. A new command line flag --no-xmailer - allows the user to squelch the header. - - * "git push" into a repository with a working tree normally refuses - to modify the branch that is checked out. The command learned to - optionally do an equivalent of "git reset --hard" only when there - is no change to the working tree and the index instead, which would - be useful to "deploy" by pushing into a repository. - - * "git new-workdir" (in contrib/) can be used to populate an empty - and existing directory now. - - * Credential helpers are asked in turn until one of them give - positive response, which is cumbersome to turn off when you need to - run Git in an automated setting. The credential helper interface - learned to allow a helper to say "stop, don't ask other helpers." - Also GIT_TERMINAL_PROMPT environment can be set to false to disable - our built-in prompt mechanism for passwords. - - * "git branch -d" (delete) and "git branch -m" (move) learned to - honor "-f" (force) flag; unlike many other subcommands, the way to - force these have been with separate "-D/-M" options, which was - inconsistent. - - * "diff-highlight" filter (in contrib/) allows its color output to be - customized via configuration variables. - - * "git imap-send" learned to take "-v" (verbose) and "-q" (quiet) - command line options. - - * "git remote add $name $URL" is now allowed when "url.$URL.insteadOf" - is already defined. - - * "git imap-send" now can be built to use cURL library to talk to - IMAP servers (if the library is recent enough, of course). - This allows you to use authenticate method other than CRAM-MD5, - among other things. - - * "git imap-send" now allows GIT_CURL_VERBOSE environment variable to - control the verbosity when talking via the cURL library. - - * The prompt script (in contrib/) learned to optionally hide prompt - when in an ignored directory by setting GIT_PS1_HIDE_IF_PWD_IGNORED - shell variable. - - -Performance, Internal Implementation, Development Support etc. - - * Earlier we made "rev-list --object-edge" more aggressively list the - objects at the edge commits, in order to reduce number of objectsใ - fetched into a shallow repository, but the change affected cases - other than "fetching into a shallow repository" and made it - unusably slow (e.g. fetching into a normal repository should not - have to suffer the overhead from extra processing). Limit it to a - more specific case by introducing --objects-edge-aggressive, a new - option to rev-list. - - * Squelched useless compiler warnings on Mac OS X regarding the - crypto API. - - * The procedure to generate unicode table has been simplified. - - * Some filesystems assign filemodes in a strange way, fooling then - automatic "filemode trustability" check done during a new - repository creation. The initialization codepath has been hardened - against this issue. - - * The codepath in "git remote update --prune" to drop many refs has - been optimized. - - * The API into get_merge_bases*() family of functions was easy to - misuse, which has been corrected to make it harder to do so. - - * Long overdue departure from the assumption that S_IFMT is shared by - everybody made in 2005, which was necessary to port to z/OS. - - * "git push" and "git fetch" did not communicate an overlong refname - correctly. Now it uses 64kB sideband to accommodate longer ones. - - * Recent GPG changes the keyring format and drops support for RFC1991 - formatted signatures, breaking our existing tests. - - * "git-prompt" (in contrib/) used a variable from the global scope, - possibly contaminating end-user's namespace. - - -Also contains various documentation updates and code clean-ups. - - -Fixes since v2.2 ----------------- - -Unless otherwise noted, all the fixes since v2.2 in the maintenance -track are contained in this release (see the maintenance releases' -notes for details). - - * "git http-push" over WebDAV (aka dumb http-push) was broken in - v2.2.2 when parsing a symbolic ref, resulting in a bogus request - that gets rejected by recent versions of cURL library. - (merge f6786c8 jk/http-push-symref-fix later to maint). - - * The logic in "git bisect bad HEAD" etc. to avoid forcing the test - of the common ancestor of bad and good commits was broken. - (merge 07913d5 cc/bisect-rev-parsing later to maint). - - * "git checkout-index --temp=$target $path" did not work correctly - for paths outside the current subdirectory in the project. - (merge 74c4de5 es/checkout-index-temp later to maint). - - * The report from "git checkout" on a branch that builds on another - local branch by setting its branch.*.merge to branch name (not a - full refname) incorrectly said that the upstream is gone. - (merge 05e7368 jc/checkout-local-track-report later to maint). - - * With The git-prompt support (in contrib/), using the exit status of - the last command in the prompt, e.g. PS1='$(__git_ps1) $? ', did - not work well, because the helper function stomped on the exit - status. - (merge 6babe76 tf/prompt-preserve-exit-status later to maint). - - * Recent update to "git commit" broke amending an existing commit - with bogus author/committer lines without a valid e-mail address. - (merge c83a509 jk/commit-date-approxidate later to maint). - - * The lockfile API used to get confused which file to clean up when - the process moved the $cwd after creating a lockfile. - (merge fa137f6 nd/lockfile-absolute later to maint). - - * Traditionally we tried to avoid interpreting date strings given by - the user as future dates, e.g. GIT_COMMITTER_DATE=2014-12-10 when - used early November 2014 was taken as "October 12, 2014" because it - is likely that a date in the future, December 10, is a mistake. - This heuristics has been loosened to allow people to express future - dates (most notably, --until=<date> may want to be far in the - future) and we no longer tiebreak by future-ness of the date when - - (1) ISO-like format is used, and - (2) the string can make sense interpreted as both y-m-d and y-d-m. - - Git may still have to use the heuristics to tiebreak between dd/mm/yy - and mm/dd/yy, though. - (merge d372395 jk/approxidate-avoid-y-d-m-over-future-dates later to maint). - - * Git did not correctly read an overlong refname from a packed refs - file. - (merge ea41783 jk/read-packed-refs-without-path-max later to maint). - - * "git apply" was described in the documentation to take --ignore-date - option, which it does not. - (merge 0cef4e7 rw/apply-does-not-take-ignore-date later to maint). - - * "git add -i" did not notice when the interactive command input - stream went away and kept asking the same question. - (merge a8bec7a jk/add-i-read-error later to maint). - - * "git send-email" did not handle RFC 2047 encoded headers quite - right. - (merge ab47e2a rd/send-email-2047-fix later to maint). - - * New tag object format validation added in 2.2 showed garbage after - a tagname it reported in its error message. - (merge a1e920a js/fsck-tag-validation later to maint). - - * The code that reads the reflog from the newer to the older entries - did not handle an entry that crosses a boundary of block it uses to - read them correctly. - (merge 69216bf jk/for-each-reflog-ent-reverse later to maint). - - * "git diff -B -M" after making a new copy B out of an existing file - A and then editing A extensively ought to report that B was created - by copying A and A was modified, which is what "git diff -C" - reports, but it instead said A was renamed to B and A was edited - heavily in place. This was not just incoherent but also failed to - apply with "git apply". The report has been corrected to match what - "git diff -C" produces for this case. - (merge 6936b58 jc/diff-b-m later to maint). - - * In files we pre-populate for the user to edit with commented hints, - a line of hint that is indented with a tab used to show as '#' (or - any comment char), ' ' (space), and then the hint text that began - with the tab, which some editors flag as an indentation error (tab - following space). We now omit the space after the comment char in - such a case. - (merge d55aeb7 jc/strbuf-add-lines-avoid-sp-ht-sequence later to maint). - - * "git ls-tree" does not support path selection based on negative - pathspecs, but did not error out when negative pathspecs are given. - (merge f1f6224 nd/ls-tree-pathspec later to maint). - - * The function sometimes returned a non-freeable memory and some - other times returned a piece of memory that must be freed, leading - to inevitable leaks. - (merge 59362e5 jc/exec-cmd-system-path-leak-fix later to maint). - - * The code to abbreviate an object name to its short unique prefix - has been optimized when no abbreviation was requested. - (merge 61e704e mh/find-uniq-abbrev later to maint). - - * "git add --ignore-errors ..." did not ignore an error to - give a file that did not exist. - (merge 1d31e5a mg/add-ignore-errors later to maint). - - * "git checkout $treeish $path", when $path in the index and the - working tree already matched what is in $treeish at the $path, - still overwrote the $path unnecessarily. - (merge c5326bd jk/checkout-from-tree later to maint). - - * "git config --get-color" did not parse its command line arguments - carefully. - (merge cb35722 jk/colors-fix later to maint). - - * open() emulated on Windows platforms did not give EISDIR upon - an attempt to open a directory for writing. - (merge ba6fad0 js/windows-open-eisdir-error later to maint). - - * A few code paths used abs() when they should have used labs() on - long integers. - (merge 83915ba rs/maint-config-use-labs later to maint). - (merge 31a8aa1 rs/receive-pack-use-labs later to maint). - - * "gitweb" used to depend on a behaviour recent CGI.pm deprecated. - (merge 13dbf46 jk/gitweb-with-newer-cgi-multi-param later to maint). - - * "git init" (hence "git clone") initialized the per-repository - configuration file .git/config with x-bit by mistake. - (merge 1f32ecf mh/config-flip-xbit-back-after-checking later to maint). - - * Recent update in Git 2.2 started creating objects/info/packs and - info/refs files with permission bits tighter than user's umask. - (merge d91175b jk/prune-packed-server-info later to maint). - - * Git 2.0 was supposed to make the "simple" mode for the default of - "git push", but it didn't. - (merge 00a6fa0 jk/push-simple later to maint). - - * "Everyday" document had a broken link. - (merge 366c8d4 po/everyday-doc later to maint). - - * A few test fixes. - (merge 880ef58 jk/no-perl-tests later to maint). - - * The build procedure did not bother fixing perl and python scripts - when NO_PERL and NO_PYTHON build-time configuration changed. - (merge ca2051d jk/rebuild-perl-scripts-with-no-perl-seting-change later to maint). - - * The usage string of "git log" command was marked incorrectly for - l10n. - (merge e66dc0c km/log-usage-string-i18n later to maint). - - * "git for-each-ref" mishandled --format="%(upstream:track)" when a - branch is marked to have forked from a non-existing branch. - (merge b6160d9 rc/for-each-ref-tracking later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.3.1.txt b/third_party/git/Documentation/RelNotes/2.3.1.txt deleted file mode 100644 index cf96186288..0000000000 --- a/third_party/git/Documentation/RelNotes/2.3.1.txt +++ /dev/null @@ -1,52 +0,0 @@ -Git v2.3.1 Release Notes -======================== - -Fixes since v2.3 ----------------- - - * The interactive "show a list and let the user choose from it" - interface "add -i" used showed and prompted to the user even when - the candidate list was empty, against which the only "choice" the - user could have made was to choose nothing. - - * "git apply --whitespace=fix" used to under-allocate the memory - when the fix resulted in a longer text than the original patch. - - * "git log --help" used to show rev-list options that are irrelevant - to the "log" command. - - * The error message from "git commit", when a non-existing author - name was given as value to the "--author=" parameter, has been - reworded to avoid misunderstanding. - - * A broken pack .idx file in the receiving repository prevented the - dumb http transport from fetching a good copy of it from the other - side. - - * The documentation incorrectly said that C(opy) and R(ename) are the - only ones that can be followed by the score number in the output in - the --raw format. - - * Fix a misspelled conditional that is always true. - - * Code to read branch name from various files in .git/ directory - would have misbehaved if the code to write them left an empty file. - - * The "git push" documentation made the "--repo=<there>" option - easily misunderstood. - - * After attempting and failing a password-less authentication - (e.g. kerberos), libcURL refuses to fall back to password based - Basic authentication without a bit of help/encouragement. - - * Setting diff.submodule to 'log' made "git format-patch" produce - broken patches. - - * "git rerere" (invoked internally from many mergy operations) did - not correctly signal errors when told to update the working tree - files and failed to do so for whatever reason. - - * "git blame HEAD -- missing" failed to correctly say "HEAD" when it - tried to say "No such path 'missing' in HEAD". - -Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.3.10.txt b/third_party/git/Documentation/RelNotes/2.3.10.txt deleted file mode 100644 index 20c2d2cacc..0000000000 --- a/third_party/git/Documentation/RelNotes/2.3.10.txt +++ /dev/null @@ -1,18 +0,0 @@ -Git v2.3.10 Release Notes -========================= - -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 somewhere - around 1GB for now. - - * Some protocols (like git-remote-ext) can execute arbitrary code - found in the URL. The URLs that submodules use may come from - arbitrary sources (e.g., .gitmodules files in a remote - repository), and can hurt those who blindly enable recursive - fetch. Restrict the allowed protocols to well known and safe - ones. diff --git a/third_party/git/Documentation/RelNotes/2.3.2.txt b/third_party/git/Documentation/RelNotes/2.3.2.txt deleted file mode 100644 index 93462e45c2..0000000000 --- a/third_party/git/Documentation/RelNotes/2.3.2.txt +++ /dev/null @@ -1,79 +0,0 @@ -Git v2.3.2 Release Notes -======================== - -Fixes since v2.3.1 ------------------- - - * "update-index --refresh" used to leak when an entry cannot be - refreshed for whatever reason. - - * "git fast-import" used to crash when it could not close and - conclude the resulting packfile cleanly. - - * "git blame" died, trying to free an uninitialized piece of memory. - - * "git merge-file" did not work correctly in a subdirectory. - - * "git submodule add" failed to squash "path/to/././submodule" to - "path/to/submodule". - - * In v2.2.0, we broke "git prune" that runs in a repository that - borrows from an alternate object store. - - * Certain older vintages of cURL give irregular output from - "curl-config --vernum", which confused our build system. - - * An earlier workaround to squelch unhelpful deprecation warnings - from the compiler on Mac OSX unnecessarily set minimum required - version of the OS, which the user might want to raise (or lower) - for other reasons. - - * Longstanding configuration variable naming rules has been added to - the documentation. - - * The credential helper for Windows (in contrib/) used to mishandle - a user name with an at-sign in it. - - * Older GnuPG implementations may not correctly import the keyring - material we prepare for the tests to use. - - * Clarify in the documentation that "remote.<nick>.pushURL" and - "remote.<nick>.URL" are there to name the same repository accessed - via different transports, not two separate repositories. - - * The pack bitmap support did not build with older versions of GCC. - - * Reading configuration from a blob object, when it ends with a lone - CR, use to confuse the configuration parser. - - * We didn't format an integer that wouldn't fit in "int" but in - "uintmax_t" correctly. - - * "git push --signed" gave an incorrectly worded error message when - the other side did not support the capability. - - * "git fetch" over a remote-helper that cannot respond to "list" - command could not fetch from a symbolic reference e.g. HEAD. - - * The insn sheet "git rebase -i" creates did not fully honor - core.abbrev settings. - - * The tests that wanted to see that file becomes unreadable after - running "chmod a-r file", and the tests that wanted to make sure it - is not run as root, we used "can we write into the / directory?" as - a cheap substitute, but on some platforms that is not a good - heuristics. The tests and their prerequisites have been updated to - check what they really require. - - * The configuration variable 'mailinfo.scissors' was hard to - discover in the documentation. - - * Correct a breakage to git-svn around v2.2 era that triggers - premature closing of FileHandle. - - * Even though we officially haven't dropped Perl 5.8 support, the - Getopt::Long package that came with it does not support "--no-" - prefix to negate a boolean option; manually add support to help - people with older Getopt::Long package. - -Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.3.3.txt b/third_party/git/Documentation/RelNotes/2.3.3.txt deleted file mode 100644 index 5ef12644c2..0000000000 --- a/third_party/git/Documentation/RelNotes/2.3.3.txt +++ /dev/null @@ -1,39 +0,0 @@ -Git v2.3.3 Release Notes -======================== - -Fixes since v2.3.2 ------------------- - - * A corrupt input to "git diff -M" used cause us to segfault. - - * The borrowed code in kwset API did not follow our usual convention - to use "unsigned char" to store values that range from 0-255. - - * Description given by "grep -h" for its --exclude-standard option - was phrased poorly. - - * Documentaton for "git remote add" mentioned "--tags" and - "--no-tags" and it was not clear that fetch from the remote in - the future will use the default behaviour when neither is given - to override it. - - * "git diff --shortstat --dirstat=changes" showed a dirstat based on - lines that was never asked by the end user in addition to the - dirstat that the user asked for. - - * The interaction between "git submodule update" and the - submodule.*.update configuration was not clearly documented. - - * "git apply" was not very careful about reading from, removing, - updating and creating paths outside the working tree (under - --index/--cached) or the current directory (when used as a - replacement for GNU patch). - - * "git daemon" looked up the hostname even when "%CH" and "%IP" - interpolations are not requested, which was unnecessary. - - * The "interpolated-path" option of "git daemon" inserted any string - client declared on the "host=" capability request without checking. - Sanitize and limit %H and %CH to a saner and a valid DNS name. - -Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.3.4.txt b/third_party/git/Documentation/RelNotes/2.3.4.txt deleted file mode 100644 index 094c7b853b..0000000000 --- a/third_party/git/Documentation/RelNotes/2.3.4.txt +++ /dev/null @@ -1,32 +0,0 @@ -Git v2.3.4 Release Notes -======================== - -Fixes since v2.3.3 ------------------- - - * The 'color.status.unmerged' configuration was not described. - - * "git log --decorate" did not reset colors correctly around the - branch names. - - * "git -C '' subcmd" refused to work in the current directory, unlike - "cd ''" which silently behaves as a no-op. - - * "git imap-send" learned to optionally talk with an IMAP server via - libcURL; because there is no other option when Git is built with - NO_OPENSSL option, use that codepath by default under such - configuration. - - * A workaround for certain build of GPG that triggered false breakage - in a test has been added. - - * "git rebase -i" recently started to include the number of - commits in the insn sheet to be processed, but on a platform - that prepends leading whitespaces to "wc -l" output, the numbers - are shown with extra whitespaces that aren't necessary. - - * We did not parse username followed by literal IPv6 address in SSH - transport URLs, e.g. ssh://user@[2001:db8::1]:22/repo.git - correctly. - -Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.3.5.txt b/third_party/git/Documentation/RelNotes/2.3.5.txt deleted file mode 100644 index 5b309db689..0000000000 --- a/third_party/git/Documentation/RelNotes/2.3.5.txt +++ /dev/null @@ -1,44 +0,0 @@ -Git v2.3.5 Release Notes -======================== - -Fixes since v2.3.4 ------------------- - - * The prompt script (in contrib/) did not show the untracked sign - when working in a subdirectory without any untracked files. - - * Even though "git grep --quiet" is run merely to ask for the exit - status, we spawned the pager regardless. Stop doing that. - - * Recommend format-patch and send-email for those who want to submit - patches to this project. - - * An failure early in the "git clone" that started creating the - working tree and repository could have resulted in some directories - and files left without getting cleaned up. - - * "git fetch" that fetches a commit using the allow-tip-sha1-in-want - extension could have failed to fetch all the requested refs. - - * The split-index mode introduced at v2.3.0-rc0~41 was broken in the - codepath to protect us against a broken reimplementation of Git - that writes an invalid index with duplicated index entries, etc. - - * "git prune" used to largely ignore broken refs when deciding which - objects are still being used, which could spread an existing small - damage and make it a larger one. - - * "git tag -h" used to show the "--column" and "--sort" options - that are about listing in a wrong section. - - * The transfer.hiderefs support did not quite work for smart-http - transport. - - * The code that reads from the ctags file in the completion script - (in contrib/) did not spell ${param/pattern/string} substitution - correctly, which happened to work with bash but not with zsh. - - * The explanation on "rebase --preserve-merges", "pull --rebase=preserve", - and "push --force-with-lease" in the documentation was unclear. - -Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.3.6.txt b/third_party/git/Documentation/RelNotes/2.3.6.txt deleted file mode 100644 index 432f770ef3..0000000000 --- a/third_party/git/Documentation/RelNotes/2.3.6.txt +++ /dev/null @@ -1,13 +0,0 @@ -Git v2.3.6 Release Notes -======================== - -Fixes since v2.3.5 ------------------- - - * "diff-highlight" (in contrib/) used to show byte-by-byte - differences, which meant that multi-byte characters can be chopped - in the middle. It learned to pay attention to character boundaries - (assuming the UTF-8 payload). - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.3.7.txt b/third_party/git/Documentation/RelNotes/2.3.7.txt deleted file mode 100644 index fc95812cb3..0000000000 --- a/third_party/git/Documentation/RelNotes/2.3.7.txt +++ /dev/null @@ -1,21 +0,0 @@ -Git v2.3.7 Release Notes -======================== - -Fixes since v2.3.6 ------------------- - - * An earlier update to the parser that disects a URL broke an - address, followed by a colon, followed by an empty string (instead - of the port number), e.g. ssh://example.com:/path/to/repo. - - * The completion script (in contrib/) contaminated global namespace - and clobbered on a shell variable $x. - - * The "git push --signed" protocol extension did not limit what the - "nonce" that is a server-chosen string can contain or how long it - can be, which was unnecessarily lax. Limit both the length and the - alphabet to a reasonably small space that can still have enough - entropy. - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.3.8.txt b/third_party/git/Documentation/RelNotes/2.3.8.txt deleted file mode 100644 index 0b67268a96..0000000000 --- a/third_party/git/Documentation/RelNotes/2.3.8.txt +++ /dev/null @@ -1,22 +0,0 @@ -Git v2.3.8 Release Notes -======================== - -Fixes since v2.3.7 ------------------- - - * The usual "git diff" when seeing a file turning into a directory - showed a patchset to remove the file and create all files in the - directory, but "git diff --no-index" simply refused to work. Also, - when asked to compare a file and a directory, imitate POSIX "diff" - and compare the file with the file with the same name in the - directory, instead of refusing to run. - - * The default $HOME/.gitconfig file created upon "git config --global" - that edits it had incorrectly spelled user.name and user.email - entries in it. - - * "git commit --date=now" or anything that relies on approxidate lost - the daylight-saving-time offset. - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.3.9.txt b/third_party/git/Documentation/RelNotes/2.3.9.txt deleted file mode 100644 index 1a2ad3235a..0000000000 --- a/third_party/git/Documentation/RelNotes/2.3.9.txt +++ /dev/null @@ -1,9 +0,0 @@ -Git v2.3.9 Release Notes -======================== - -Fixes since v2.3.8 ------------------- - - * A handful of codepaths that used to use fixed-sized arrays to hold - pathnames have been corrected to use strbuf and other mechanisms to - allow longer pathnames without fearing overflows. diff --git a/third_party/git/Documentation/RelNotes/2.4.0.txt b/third_party/git/Documentation/RelNotes/2.4.0.txt deleted file mode 100644 index cde64be535..0000000000 --- a/third_party/git/Documentation/RelNotes/2.4.0.txt +++ /dev/null @@ -1,514 +0,0 @@ -Git 2.4 Release Notes -===================== - -Backward compatibility warning(s) ---------------------------------- - -This release has a few changes in the user-visible output from -Porcelain commands. These are not meant to be parsed by scripts, but -users still may want to be aware of the changes: - - * The output from "git log --decorate" (and, more generally, the "%d" - format specifier used in the "--format=<string>" parameter to the - "git log" family of commands) has changed. It used to list "HEAD" - just like other branches; e.g., - - $ git log --decorate -1 master - commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD, master) - ... - - This release changes the output slightly when HEAD refers to a - branch whose name is also shown in the output. The above is now - shown as: - - $ git log --decorate -1 master - commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD -> master) - ... - - * The phrasing "git branch" uses to describe a detached HEAD has been - updated to agree with the phrasing used by "git status": - - - When HEAD is at the same commit as when it was originally - detached, they now both show "detached at <commit object name>". - - - When HEAD has moved since it was originally detached, they now - both show "detached from <commit object name>". - - Previously, "git branch" always used "from". - - -Updates since v2.3 ------------------- - -Ports - - * Our default I/O size (8 MiB) for large files was too large for some - platforms with smaller SSIZE_MAX, leading to read(2)/write(2) - failures. - - * We did not check the curl library version before using the - CURLOPT_PROXYAUTH feature, which did not exist in older versions of - the library. - - * We now detect number of CPUs on older BSD-derived systems. - - * Portability fixes and workarounds for shell scripts have been added - to help BSD-derived systems. - - -UI, Workflows & Features - - * The command usage info strings given by "git cmd -h" and in - documentation have been tweaked for consistency. - - * The "sync" subcommand of "git p4" now allows users to exclude - subdirectories like its "clone" subcommand does. - - * "git log --invert-grep --grep=WIP" will show only commits that do - not have the string "WIP" in their messages. - - * "git push" has been taught an "--atomic" option that makes a push - that updates more than one ref an "all-or-none" affair. - - * Extending the "push to deploy" feature that was added in 2.3, the - behaviour of "git push" when updating the branch that is checked - out can now be tweaked by a "push-to-checkout" hook. - - * HTTP-based transports now send Accept-Language when making - requests. The languages to accept are inferred from environment - variables on the client side (LANGUAGE, etc). - - * "git send-email" used to accept a mistaken "y" (or "yes") as an - answer to "What encoding do you want to use [UTF-8]?" without - questioning. Now it asks for confirmation when the answer looks too - short to be a valid encoding name. - - * When "git apply --whitespace=fix" fixed whitespace errors in the - common context lines, the command reports that it did so. - - * "git status" now allows the "-v" option to be given twice, in which - case it also shows the differences in the working tree that are not - staged to be committed. - - * "git cherry-pick" used to clean up the log message even when it is - merely replaying an existing commit. It now replays the message - verbatim unless you are editing the message of the resulting - commit. - - * "git archive" can now be told to set the 'text' attribute in the - resulting zip archive. - - * Output from "git log --decorate" now distinguishes between a - detached HEAD vs. a HEAD that points at a branch. - - This is a potentially backward-incompatible change; see above for - more information. - - * When HEAD was detached when at commit xyz and hasn't been moved - since it was detached, "git status" would report "detached at xyz" - whereas "git branch" would report "detached from xyz". Now the - output of "git branch" agrees with that of "git status". - - This is a potentially backward-incompatible change; see above for - more information. - - * "git -C '' subcmd" now works in the current directory (analogously - to "cd ''") rather than dying with an error message. - (merge 6a536e2 kn/git-cd-to-empty later to maint). - - * The versionsort.prereleaseSuffix configuration variable can be used - to specify that, for example, v1.0-pre1 comes before v1.0. - - * A new "push.followTags" configuration turns the "--follow-tags" - option on by default for the "git push" command. - - * "git log --graph --no-walk A B..." is a nonsensical combination of - options: "--no-walk" requests discrete points in the history, while - "--graph" asks to draw connections between these discrete points. - Forbid the use of these options together. - - * "git rev-list --bisect --first-parent" does not work (yet) and can - even cause SEGV; forbid it. "git log --bisect --first-parent" would - not be useful until "git bisect --first-parent" materializes, so - also forbid it for now. - - -Performance, Internal Implementation, Development Support etc. - - * Slightly change the implementation of the N_() macro to help us - detect mistakes. - - * Restructure the implementation of "reflog expire" to fit better - with the recently updated reference API. - - * The transport-helper did not pass transport options such as - verbosity, progress, cloning, etc. to import and export based - helpers, like it did for fetch and push based helpers, robbing them - of the chance to honor the wish of the end-users better. - - * The tests that wanted to see that a file becomes unreadable after - running "chmod a-r file", and the tests that wanted to make sure - that they are not run as root, used "can we write into the / - directory?" as a cheap substitute. But on some platforms that is - not a good heuristic. The tests and their prerequisites have been - updated to check what they really require. - (merge f400e51 jk/sanity later to maint). - - * Various issues around "reflog expire", e.g. using --updateref when - expiring a reflog for a symbolic reference, have been corrected - and/or made saner. - - * The documentation for the strbuf API had been split between the API - documentation and the header file. Consolidate the documentation in - strbuf.h. - - * The error handling functions and conventions are now documented in - the API manual (in api-error-handling.txt). - - * Optimize gitattribute look-up, mostly useful in "git grep" on a - project that does not use many attributes, by avoiding it when we - (should) know that the attributes are not defined in the first - place. - - * Typofix in comments. - (merge ef2956a ak/git-pm-typofix later to maint). - - * Code clean-up. - (merge 0b868f0 sb/hex-object-name-is-at-most-41-bytes-long later to maint). - (merge 5d30851 dp/remove-duplicated-header-inclusion later to maint). - - * Simplify the ref transaction API for verifying that "the ref should - be pointing at this object". - - * Simplify the code in "git daemon" that parses out and holds - hostnames used in request interpolation. - - * Restructure the "git push" codepath to make it easier to add new - configuration bits. - - * The run-command interface made it easy to make a pipe for us to - read from a process, wait for the process to finish, and then - attempt to read its output. But this pattern can lead to deadlock. - So introduce a helper to do this correctly (i.e., first read, and - then wait the process to finish) and also add code to prevent such - abuse in the run-command helper. - - * People often forget to chain the commands in their test together - with &&, letting a failure from an earlier command in the test go - unnoticed. The new GIT_TEST_CHAIN_LINT mechanism allows you to - catch such a mistake more easily. - - -Also contains various documentation updates and code clean-ups. - - -Fixes since v2.3 ----------------- - -Unless otherwise noted, all the fixes since v2.3 in the maintenance -track are contained in this release (see the maintenance releases' -notes for details). - - * "git blame HEAD -- missing" failed to correctly say "HEAD" when it - tried to say "No such path 'missing' in HEAD". - (merge a46442f jk/blame-commit-label later to maint). - - * "git rerere" (invoked internally from many mergy operations) did - not correctly signal errors when it attempted to update the working - tree files but failed for whatever reason. - (merge 89ea903 jn/rerere-fail-on-auto-update-failure later to maint). - - * Setting diff.submodule to 'log' made "git format-patch" produce - broken patches. - (merge 339de50 dk/format-patch-ignore-diff-submodule later to maint). - - * After attempting and failing a password-less authentication (e.g., - Kerberos), libcURL refuses to fall back to password-based Basic - authentication without a bit of help/encouragement. - (merge 4dbe664 bc/http-fallback-to-password-after-krb-fails later to maint). - - * The "git push" documentation for the "--repo=<there>" option was - easily misunderstood. - (merge 57b92a7 mg/push-repo-option-doc later to maint). - - * Code to read a branch name from various files in the .git/ - directory would have overrun array limits if asked to read an empty - file. - (merge 66ec904 jk/status-read-branch-name-fix later to maint). - - * Remove a superfluous conditional that is always true. - (merge 94ee8e2 jk/remote-curl-an-array-in-struct-cannot-be-null later to maint). - - * The "git diff --raw" documentation incorrectly implied that C(opy) - and R(ename) are the only statuses that can be followed by a score - number. - (merge ac1c2d9 jc/diff-format-doc later to maint). - - * A broken pack .idx file in the receiving repository prevented the - dumb http transport from fetching a good copy of it from the other - side. - (merge 8b9c2dd jk/dumb-http-idx-fetch-fix later to maint). - - * The error message from "git commit", when a non-existing author - name was given as value to the "--author=" parameter, has been - reworded to avoid misunderstanding. - (merge 1044b1f mg/commit-author-no-match-malformed-message later to maint). - - * "git log --help" used to show rev-list options that are irrelevant - to the "log" command. - (merge 3cab02d jc/doc-log-rev-list-options later to maint). - - * "git apply --whitespace=fix" used to under-allocate memory when the - fix resulted in a longer text than the original patch. - (merge 407a792 jc/apply-ws-fix-expands later to maint). - - * The interactive "show a list and let the user choose from it" - interface used by "git add -i" unnecessarily prompted the user even - when the candidate list was empty, against which the only "choice" - the user could have made was to choose nothing. - (merge a9c4641 ak/add-i-empty-candidates later to maint). - - * The todo list created by "git rebase -i" did not fully honor - core.abbrev settings. - (merge edb72d5 ks/rebase-i-abbrev later to maint). - - * "git fetch" over a remote-helper that cannot respond to the "list" - command could not fetch from a symbolic reference (e.g., HEAD). - (merge 33cae54 mh/deref-symref-over-helper-transport later to maint). - - * "git push --signed" gave an incorrectly worded error message when - the other side did not support the capability. - - * The "git push --signed" protocol extension did not limit what the - "nonce" (a server-chosen string) could contain nor how long it - could be, which was unnecessarily lax. Limit both the length and - the alphabet to a reasonably small space that can still have enough - entropy. - (merge afcb6ee jc/push-cert later to maint). - - * The completion script (in contrib/) clobbered the shell variable $x - in the global shell namespace. - (merge 852ff1c ma/bash-completion-leaking-x later to maint). - - * We incorrectly formatted a "uintmax_t" integer that doesn't fit in - "int". - (merge d306f3d jk/decimal-width-for-uintmax later to maint). - - * The configuration parser used to be confused when reading - configuration from a blob object that ends with a lone CR. - (merge 1d0655c jk/config-no-ungetc-eof later to maint). - - * The pack bitmap support did not build with older versions of GCC. - (merge bd4e882 jk/pack-bitmap later to maint). - - * The documentation wasn't clear that "remote.<nick>.pushURL" and - "remote.<nick>.URL" are there to name the same repository accessed - via different transports, not two separate repositories. - (merge 697f652 jc/remote-set-url-doc later to maint). - - * Older GnuPG implementations may not correctly import the keyring - material we prepare for the tests to use. - (merge 1f985d6 ch/new-gpg-drops-rfc-1991 later to maint). - - * The credential helper for Windows (in contrib/) used to mishandle - user names that contain an at-sign. - (merge 13d261e av/wincred-with-at-in-username-fix later to maint). - - * "diff-highlight" (in contrib/) used to show byte-by-byte - differences, which could cause multi-byte characters to be chopped - in the middle. It learned to pay attention to character boundaries - (assuming UTF-8). - (merge 8d00662 jk/colors later to maint). - - * Document longstanding configuration variable naming rules in - CodingGuidelines. - (merge 35840a3 jc/conf-var-doc later to maint). - - * An earlier workaround to squelch unhelpful deprecation warnings - from the compiler on OS X unnecessarily set a minimum required - version of the OS, which the user might want to raise (or lower) - for other reasons. - (merge 88c03eb es/squelch-openssl-warnings-on-macosx later to maint). - - * Certain older vintages of cURL give irregular output from - "curl-config --vernum", which confused our build system. - (merge 3af6792 tc/curl-vernum-output-broken-in-7.11 later to maint). - - * In v2.2.0, we broke "git prune" that runs in a repository that - borrows from an alternate object store. - (merge b0a4264 jk/prune-mtime later to maint). - - * "git submodule add" failed to squash "path/to/././submodule" to - "path/to/submodule". - (merge 8196e72 ps/submodule-sanitize-path-upon-add later to maint). - - * "git merge-file" did not work correctly when invoked in a - subdirectory. - (merge 204a8ff ab/merge-file-prefix later to maint). - - * "git blame" could die trying to free an uninitialized piece of - memory. - (merge e600592 es/blame-commit-info-fix later to maint). - - * "git fast-import" used to crash when it could not close and - finalize the resulting packfile cleanly. - (merge 5e915f3 jk/fast-import-die-nicely-fix later to maint). - - * "update-index --refresh" used to leak memory when an entry could - not be refreshed for whatever reason. - (merge bc1c2ca sb/plug-leak-in-make-cache-entry later to maint). - - * The "interpolated-path" option of "git daemon" inserted any string - the client declared on the "host=" capability request without - checking. Sanitize and limit %H and %CH to a saner and a valid DNS - name. - (merge b485373 jk/daemon-interpolate later to maint). - - * "git daemon" unnecessarily looked up the hostname even when "%CH" - and "%IP" interpolations were not requested. - (merge dc8edc8 rs/daemon-interpolate later to maint). - - * We relied on "--no-" prefix handling in Perl's Getopt::Long - package, even though that support didn't exist in Perl 5.8 (which - we still support). Manually add support to help people with older - Getopt::Long packages. - (merge f471494 km/send-email-getopt-long-workarounds later to maint). - - * "git apply" was not very careful about reading from, removing, - updating and creating paths outside the working tree (under - --index/--cached) or the current directory (when used as a - replacement for GNU patch). - (merge e0d201b jc/apply-beyond-symlink later to maint). - - * Correct a breakage in git-svn, introduced around the v2.2 era, that - can cause FileHandles to be closed prematurely. - (merge e426311 ew/svn-maint-fixes later to maint). - - * We did not parse usernames followed by literal IPv6 addresses - correctly in SSH transport URLs; e.g., - ssh://user@[2001:db8::1]:22/repo.git. - (merge 6b6c5f7 tb/connect-ipv6-parse-fix later to maint). - - * The configuration variable 'mailinfo.scissors' was hard to - discover in the documentation. - (merge afb5de7 mm/am-c-doc later to maint). - - * The interaction between "git submodule update" and the - submodule.*.update configuration was not clearly documented. - (merge 5c31acf ms/submodule-update-config-doc later to maint). - - * "git diff --shortstat" used together with "--dirstat=changes" or - "--dirstat=files" incorrectly output dirstat information twice. - (merge ab27389 mk/diff-shortstat-dirstat-fix later to maint). - - * The manpage for "git remote add" mentioned "--tags" and "--no-tags" - but did not explain what happens if neither option is provided. - (merge aaba0ab mg/doc-remote-tags-or-not later to maint). - - * The description of "--exclude-standard option" in the output of - "git grep -h" was phrased poorly. - (merge 77fdb8a nd/grep-exclude-standard-help-fix later to maint). - - * "git rebase -i" recently started to include the number of commits - in the todo list, but that output included extraneous whitespace on - a platform that prepends leading whitespaces to its "wc -l" output. - (merge 2185d3b es/rebase-i-count-todo later to maint). - - * The borrowed code in the kwset API did not follow our usual - convention to use "unsigned char" to store values that range from - 0-255. - (merge 189c860 bw/kwset-use-unsigned later to maint). - - * A corrupt input to "git diff -M" used to cause it to segfault. - (merge 4d6be03 jk/diffcore-rename-duplicate later to maint). - - * Certain builds of GPG triggered false breakages in a test. - (merge 3f88c1b mg/verify-commit later to maint). - - * "git imap-send" learned to optionally talk with an IMAP server via - libcURL. Because there is no other option when Git is built with - the NO_OPENSSL option, use libcURL by default in that case. - (merge dcd01ea km/imap-send-libcurl-options later to maint). - - * "git log --decorate" did not reset colors correctly around the - branch names. - (merge 5ee8758 jc/decorate-leaky-separator-color later to maint). - - * The code that reads from the ctags file in the completion script - (in contrib/) did not spell ${param/pattern/string} substitution - correctly, which happened to work with bash but not with zsh. - (merge db8d750 js/completion-ctags-pattern-substitution-fix later to maint). - - * The transfer.hiderefs support did not quite work for smart-http - transport. - (merge 8ddf3ca jk/smart-http-hide-refs later to maint). - - * In the "git tag -h" output, move the documentation for the - "--column" and "--sort" options to the "Tag listing options" - section. - (merge dd059c6 jk/tag-h-column-is-a-listing-option later to maint). - - * "git prune" used to largely ignore broken refs when deciding which - objects are still being used, which could cause reference - corruption to lead to object loss. - (merge ea56c4e jk/prune-with-corrupt-refs later to maint). - - * The split-index mode introduced in v2.3.0-rc0~41 was broken in the - codepath to protect us against a broken reimplementation of Git - that writes an invalid index with duplicated index entries, etc. - (merge 03f15a7 tg/fix-check-order-with-split-index later to maint). - - * "git fetch", when fetching a commit using the - allow-tip-sha1-in-want extension, could have failed to fetch all of - the requested refs. - (merge 32d0462 jk/fetch-pack later to maint). - - * An failure early in the "git clone" that started creating the - working tree and repository could have resulted in the failure to - clean up some directories and files. - (merge 16eff6c jk/cleanup-failed-clone later to maint). - - * Recommend format-patch and send-email for those who want to submit - patches to this project. - (merge b25c469 jc/submitting-patches-mention-send-email later to maint). - - * Do not spawn the pager when "git grep" is run with "--quiet". - (merge c2048f0 ws/grep-quiet-no-pager later to maint). - - * The prompt script (in contrib/) did not show the untracked sign - when working in a subdirectory without any untracked files. - (merge 9bdc517 ct/prompt-untracked-fix later to maint). - - * An earlier update to the URL parser broke an address that contains - a colon but an empty string for the port number, like - ssh://example.com:/path/to/repo. - (merge 6b6c5f7 tb/connect-ipv6-parse-fix later to maint). - - * Code cleanups and documentation updates. - (merge 2ce63e9 rs/simple-cleanups later to maint). - (merge 33baa69 rj/no-xopen-source-for-cygwin later to maint). - (merge 817d03e jc/diff-test-updates later to maint). - (merge eb32c66 ak/t5516-typofix later to maint). - (merge bcd57cb mr/doc-clean-f-f later to maint). - (merge 0d6accc mg/doc-status-color-slot later to maint). - (merge 53e53c7 sg/completion-remote later to maint). - (merge 8fa7975 ak/git-done-help-cleanup later to maint). - (merge 9a6f128 rs/deflate-init-cleanup later to maint). - (merge 6f75d45 rs/use-isxdigit later to maint). - (merge 376e4b3 jk/test-annoyances later to maint). - (merge 7032054 nd/doc-git-index-version later to maint). - (merge e869c5e tg/test-index-v4 later to maint). - (merge 599d223 jk/simplify-csum-file-sha1fd-check later to maint). - (merge 260d585 sg/completion-gitcomp-nl-for-refs later to maint). - (merge 777c55a jc/report-path-error-to-dir later to maint). - (merge fddfaf8 ph/push-doc-cas later to maint). - (merge d50d31e ss/pull-rebase-preserve later to maint). - (merge c8c3f1d pt/enter-repo-comment-fix later to maint). - (merge d7bfb9e jz/gitweb-conf-doc-fix later to maint). - (merge f907282 jk/cherry-pick-docfix later to maint). - (merge d3c0811 iu/fix-parse-options-h-comment later to maint). - (merge 6c3b2af jg/cguide-we-cannot-count later to maint). - (merge 2b8bd44 jk/pack-corruption-post-mortem later to maint). - (merge 9585cb8 jn/doc-fast-import-no-16-octopus-limit later to maint). - (merge 5dcd1b1 ps/grep-help-all-callback-arg later to maint). - (merge f1f4c84 va/fix-git-p4-tests later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.4.1.txt b/third_party/git/Documentation/RelNotes/2.4.1.txt deleted file mode 100644 index a65a6c5829..0000000000 --- a/third_party/git/Documentation/RelNotes/2.4.1.txt +++ /dev/null @@ -1,40 +0,0 @@ -Git v2.4.1 Release Notes -======================== - -Fixes since v2.4 ----------------- - - * The usual "git diff" when seeing a file turning into a directory - showed a patchset to remove the file and create all files in the - directory, but "git diff --no-index" simply refused to work. Also, - when asked to compare a file and a directory, imitate POSIX "diff" - and compare the file with the file with the same name in the - directory, instead of refusing to run. - - * The default $HOME/.gitconfig file created upon "git config --global" - that edits it had incorrectly spelled user.name and user.email - entries in it. - - * "git commit --date=now" or anything that relies on approxidate lost - the daylight-saving-time offset. - - * "git cat-file bl $blob" failed to barf even though there is no - object type that is "bl". - - * Teach the codepaths that read .gitignore and .gitattributes files - that these files encoded in UTF-8 may have UTF-8 BOM marker at the - beginning; this makes it in line with what we do for configuration - files already. - - * Access to objects in repositories that borrow from another one on a - slow NFS server unnecessarily got more expensive due to recent code - becoming more cautious in a naive way not to lose objects to pruning. - - * We avoid setting core.worktree when the repository location is the - ".git" directory directly at the top level of the working tree, but - the code misdetected the case in which the working tree is at the - root level of the filesystem (which arguably is a silly thing to - do, but still valid). - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.4.10.txt b/third_party/git/Documentation/RelNotes/2.4.10.txt deleted file mode 100644 index 702d8d4e22..0000000000 --- a/third_party/git/Documentation/RelNotes/2.4.10.txt +++ /dev/null @@ -1,18 +0,0 @@ -Git v2.4.10 Release Notes -========================= - -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 somewhere - around 1GB for now. - - * Some protocols (like git-remote-ext) can execute arbitrary code - found in the URL. The URLs that submodules use may come from - arbitrary sources (e.g., .gitmodules files in a remote - repository), and can hurt those who blindly enable recursive - fetch. Restrict the allowed protocols to well known and safe - ones. diff --git a/third_party/git/Documentation/RelNotes/2.4.11.txt b/third_party/git/Documentation/RelNotes/2.4.11.txt deleted file mode 100644 index 723360295c..0000000000 --- a/third_party/git/Documentation/RelNotes/2.4.11.txt +++ /dev/null @@ -1,11 +0,0 @@ -Git v2.4.11 Release Notes -========================= - -Fixes since v2.4.10 -------------------- - - * Bugfix patches were backported from the 'master' front to plug heap - corruption holes, to catch integer overflow in the computation of - pathname lengths, and to get rid of the name_path API. Both of - these would have resulted in writing over an under-allocated buffer - when formulating pathnames while tree traversal. diff --git a/third_party/git/Documentation/RelNotes/2.4.12.txt b/third_party/git/Documentation/RelNotes/2.4.12.txt deleted file mode 100644 index 7d15f94725..0000000000 --- a/third_party/git/Documentation/RelNotes/2.4.12.txt +++ /dev/null @@ -1,12 +0,0 @@ -Git v2.4.12 Release Notes -========================= - -Fixes since v2.4.11 -------------------- - - * "git-shell" rejects a request to serve a repository whose name - begins with a dash, which makes it no longer possible to get it - confused into spawning service programs like "git-upload-pack" with - an option like "--help", which in turn would spawn an interactive - pager, instead of working with the repository user asked to access - (i.e. the one whose name is "--help"). diff --git a/third_party/git/Documentation/RelNotes/2.4.2.txt b/third_party/git/Documentation/RelNotes/2.4.2.txt deleted file mode 100644 index 250cdc423c..0000000000 --- a/third_party/git/Documentation/RelNotes/2.4.2.txt +++ /dev/null @@ -1,45 +0,0 @@ -Git v2.4.2 Release Notes -======================== - -Fixes since v2.4.1 ------------------- - - * "git rev-list --objects $old --not --all" to see if everything that - is reachable from $old is already connected to the existing refs - was very inefficient. - - * "hash-object --literally" introduced in v2.2 was not prepared to - take a really long object type name. - - * "git rebase --quiet" was not quite quiet when there is nothing to - do. - - * The completion for "log --decorate=" parameter value was incorrect. - - * "filter-branch" corrupted commit log message that ends with an - incomplete line on platforms with some "sed" implementations that - munge such a line. Work it around by avoiding to use "sed". - - * "git daemon" fails to build from the source under NO_IPV6 - configuration (regression in 2.4). - - * "git stash pop/apply" forgot to make sure that not just the working - tree is clean but also the index is clean. The latter is important - as a stash application can conflict and the index will be used for - conflict resolution. - - * We have prepended $GIT_EXEC_PATH and the path "git" is installed in - (typically "/usr/bin") to $PATH when invoking subprograms and hooks - for almost eternity, but the original use case the latter tried to - support was semi-bogus (i.e. install git to /opt/foo/git and run it - without having /opt/foo on $PATH), and more importantly it has - become less and less relevant as Git grew more mainstream (i.e. the - users would _want_ to have it on their $PATH). Stop prepending the - path in which "git" is installed to users' $PATH, as that would - interfere the command search order people depend on (e.g. they may - not like versions of programs that are unrelated to Git in /usr/bin - and want to override them by having different ones in /usr/local/bin - and have the latter directory earlier in their $PATH). - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.4.3.txt b/third_party/git/Documentation/RelNotes/2.4.3.txt deleted file mode 100644 index 914d2c1860..0000000000 --- a/third_party/git/Documentation/RelNotes/2.4.3.txt +++ /dev/null @@ -1,76 +0,0 @@ -Git v2.4.3 Release Notes -======================== - -Fixes since v2.4.3 ------------------- - - * Error messages from "git branch" called remote-tracking branches as - "remote branches". - - * "git rerere forget" in a repository without rerere enabled gave a - cryptic error message; it should be a silent no-op instead. - - * "git pull --log" and "git pull --no-log" worked as expected, but - "git pull --log=20" did not. - - * The pull.ff configuration was supposed to override the merge.ff - configuration, but it didn't. - - * The code to read pack-bitmap wanted to allocate a few hundred - pointers to a structure, but by mistake allocated and leaked memory - enough to hold that many actual structures. Correct the allocation - size and also have it on stack, as it is small enough. - - * Various documentation mark-up fixes to make the output more - consistent in general and also make AsciiDoctor (an alternative - formatter) happier. - - * "git bundle verify" did not diagnose extra parameters on the - command line. - - * Multi-ref transaction support we merged a few releases ago - unnecessarily kept many file descriptors open, risking to fail with - resource exhaustion. - - * The ref API did not handle cases where 'refs/heads/xyzzy/frotz' is - removed at the same time as 'refs/heads/xyzzy' is added (or vice - versa) very well. - - * The "log --decorate" enhancement in Git 2.4 that shows the commit - at the tip of the current branch e.g. "HEAD -> master", did not - work with --decorate=full. - - * There was a commented-out (instead of being marked to expect - failure) test that documented a breakage that was fixed since the - test was written; turn it into a proper test. - - * core.excludesfile (defaulting to $XDG_HOME/git/ignore) is supposed - to be overridden by repository-specific .git/info/exclude file, but - the order was swapped from the beginning. This belatedly fixes it. - - * The connection initiation code for "ssh" transport tried to absorb - differences between the stock "ssh" and Putty-supplied "plink" and - its derivatives, but the logic to tell that we are using "plink" - variants were too loose and falsely triggered when "plink" appeared - anywhere in the path (e.g. "/home/me/bin/uplink/ssh"). - - * "git rebase -i" moved the "current" command from "todo" to "done" a - bit too prematurely, losing a step when a "pick" did not even start. - - * "git add -e" did not allow the user to abort the operation by - killing the editor. - - * Git 2.4 broke setting verbosity and progress levels on "git clone" - with native transports. - - * Some time ago, "git blame" (incorrectly) lost the convert_to_git() - call when synthesizing a fake "tip" commit that represents the - state in the working tree, which broke folks who record the history - with LF line ending to make their project portabile across - platforms while terminating lines in their working tree files with - CRLF for their platform. - - * Code clean-up for xdg configuration path support. - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.4.4.txt b/third_party/git/Documentation/RelNotes/2.4.4.txt deleted file mode 100644 index f1ccd001be..0000000000 --- a/third_party/git/Documentation/RelNotes/2.4.4.txt +++ /dev/null @@ -1,35 +0,0 @@ -Git v2.4.4 Release Notes -======================== - -Fixes since v2.4.3 ------------------- - - * l10n updates for German. - - * An earlier leakfix to bitmap testing code was incomplete. - - * "git clean pathspec..." tried to lstat(2) and complain even for - paths outside the given pathspec. - - * Communication between the HTTP server and http_backend process can - lead to a dead-lock when relaying a large ref negotiation request. - Diagnose the situation better, and mitigate it by reading such a - request first into core (to a reasonable limit). - - * The clean/smudge interface did not work well when filtering an - empty contents (failed and then passed the empty input through). - It can be argued that a filter that produces anything but empty for - an empty input is nonsense, but if the user wants to do strange - things, then why not? - - * Make "git stash something --help" error out, so that users can - safely say "git stash drop --help". - - * Clarify that "log --raw" and "log --format=raw" are unrelated - concepts. - - * Catch a programmer mistake to feed a pointer not an array to - ARRAY_SIZE() macro, by using a couple of GCC extensions. - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.4.5.txt b/third_party/git/Documentation/RelNotes/2.4.5.txt deleted file mode 100644 index 568297ccb7..0000000000 --- a/third_party/git/Documentation/RelNotes/2.4.5.txt +++ /dev/null @@ -1,28 +0,0 @@ -Git v2.4.5 Release Notes -======================== - -Fixes since v2.4.4 ------------------- - - * The setup code used to die when core.bare and core.worktree are set - inconsistently, even for commands that do not need working tree. - - * There was a dead code that used to handle "git pull --tags" and - show special-cased error message, which was made irrelevant when - the semantics of the option changed back in Git 1.9 days. - - * "color.diff.plain" was a misnomer; give it 'color.diff.context' as - a more logical synonym. - - * The configuration reader/writer uses mmap(2) interface to access - the files; when we find a directory, it barfed with "Out of memory?". - - * Recent "git prune" traverses young unreachable objects to safekeep - old objects in the reachability chain from them, which sometimes - showed unnecessary error messages that are alarming. - - * "git rebase -i" fired post-rewrite hook when it shouldn't (namely, - when it was told to stop sequencing with 'exec' insn). - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.4.6.txt b/third_party/git/Documentation/RelNotes/2.4.6.txt deleted file mode 100644 index b53f353939..0000000000 --- a/third_party/git/Documentation/RelNotes/2.4.6.txt +++ /dev/null @@ -1,23 +0,0 @@ -Git v2.4.6 Release Notes -======================== - -Fixes since v2.4.5 ------------------- - - * "git fetch --depth=<depth>" and "git clone --depth=<depth>" issued - a shallow transfer request even to an upload-pack that does not - support the capability. - - * "git fsck" used to ignore missing or invalid objects recorded in reflog. - - * The tcsh completion writes a bash scriptlet but that would have - failed for users with noclobber set. - - * Recent Mac OS X updates breaks the logic to detect that the machine - is on the AC power in the sample pre-auto-gc script. - - * "git format-patch --ignore-if-upstream A..B" did not like to be fed - tags as boundary commits. - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.4.7.txt b/third_party/git/Documentation/RelNotes/2.4.7.txt deleted file mode 100644 index b3ac412b82..0000000000 --- a/third_party/git/Documentation/RelNotes/2.4.7.txt +++ /dev/null @@ -1,53 +0,0 @@ -Git v2.4.7 Release Notes -======================== - -Fixes since v2.4.6 ------------------- - - * A minor regression to "git fsck" in v2.2 era was fixed; it - complained about a body-less tag object when it lacked a - separator empty line after its header to separate it with a - non-existent body. - - * We used to ask libCURL to use the most secure authentication method - available when talking to an HTTP proxy only when we were told to - talk to one via configuration variables. We now ask libCURL to - always use the most secure authentication method, because the user - can tell libCURL to use an HTTP proxy via an environment variable - without using configuration variables. - - * When you say "!<ENTER>" while running say "git log", you'd confuse - yourself in the resulting shell, that may look as if you took - control back to the original shell you spawned "git log" from but - that isn't what is happening. To that new shell, we leaked - GIT_PAGER_IN_USE environment variable that was meant as a local - communication between the original "Git" and subprocesses that was - spawned by it after we launched the pager, which caused many - "interesting" things to happen, e.g. "git diff | cat" still paints - its output in color by default. - - Stop leaking that environment variable to the pager's half of the - fork; we only need it on "Git" side when we spawn the pager. - - * Avoid possible ssize_t to int truncation. - - * "git config" failed to update the configuration file when the - underlying filesystem is incapable of renaming a file that is still - open. - - * A minor bugfix when pack bitmap is used with "rev-list --count". - - * An ancient test framework enhancement to allow color was not - entirely correct; this makes it work even when tput needs to read - from the ~/.terminfo under the user's real HOME directory. - - * Fix a small bug in our use of umask() return value. - - * "git rebase" did not exit with failure when format-patch it invoked - failed for whatever reason. - - * Disable "have we lost a race with competing repack?" check while - receiving a huge object transfer that runs index-pack. - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.4.8.txt b/third_party/git/Documentation/RelNotes/2.4.8.txt deleted file mode 100644 index ad946b2673..0000000000 --- a/third_party/git/Documentation/RelNotes/2.4.8.txt +++ /dev/null @@ -1,21 +0,0 @@ -Git v2.4.8 Release Notes -======================== - -Fixes since v2.4.7 ------------------- - - * Abandoning an already applied change in "git rebase -i" with - "--continue" left CHERRY_PICK_HEAD and confused later steps. - - * Various fixes around "git am" that applies a patch to a history - that is not there yet. - - * "git for-each-ref" reported "missing object" for 0{40} when it - encounters a broken ref. The lack of object whose name is 0{40} is - not the problem; the ref being broken is. - - * "git commit --cleanup=scissors" was not careful enough to protect - against getting fooled by a line that looked like scissors. - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.4.9.txt b/third_party/git/Documentation/RelNotes/2.4.9.txt deleted file mode 100644 index 09af9ddbc7..0000000000 --- a/third_party/git/Documentation/RelNotes/2.4.9.txt +++ /dev/null @@ -1,9 +0,0 @@ -Git v2.4.9 Release Notes -======================== - -Fixes since v2.4.9 ------------------- - - * A handful of codepaths that used to use fixed-sized arrays to hold - pathnames have been corrected to use strbuf and other mechanisms to - allow longer pathnames without fearing overflows. diff --git a/third_party/git/Documentation/RelNotes/2.5.0.txt b/third_party/git/Documentation/RelNotes/2.5.0.txt deleted file mode 100644 index 87044504c5..0000000000 --- a/third_party/git/Documentation/RelNotes/2.5.0.txt +++ /dev/null @@ -1,563 +0,0 @@ -Git 2.5 Release Notes -===================== - -Updates since v2.4 ------------------- - -UI, Workflows & Features - - * The bash completion script (in contrib/) learned a few options that - "git revert" takes. - - * Whitespace breakages in deleted and context lines can also be - painted in the output of "git diff" and friends with the new - --ws-error-highlight option. - - * List of commands shown by "git help" are grouped along the workflow - elements to help early learners. - - * "git p4" now detects the filetype (e.g. binary) correctly even when - the files are opened exclusively. - - * git p4 attempts to better handle branches in Perforce. - - * "git p4" learned "--changes-block-size <n>" to read the changes in - chunks from Perforce, instead of making one call to "p4 changes" - that may trigger "too many rows scanned" error from Perforce. - - * More workaround for Perforce's row number limit in "git p4". - - * Unlike "$EDITOR" and "$GIT_EDITOR" that can hold the path to the - command and initial options (e.g. "/path/to/emacs -nw"), 'git p4' - did not let the shell interpolate the contents of the environment - variable that name the editor "$P4EDITOR" (and "$EDITOR", too). - This release makes it in line with the rest of Git, as well as with - Perforce. - - * A new short-hand <branch>@{push} denotes the remote-tracking branch - that tracks the branch at the remote the <branch> would be pushed - to. - - * "git show-branch --topics HEAD" (with no other arguments) did not - do anything interesting. Instead, contrast the given revision - against all the local branches by default. - - * A replacement for contrib/workdir/git-new-workdir that does not - rely on symbolic links and make sharing of objects and refs safer - by making the borrowee and borrowers aware of each other. - - Consider this as still an experimental feature; its UI is still - likely to change. - - * Tweak the sample "store" backend of the credential helper to honor - XDG configuration file locations when specified. - - * A heuristic we use to catch mistyped paths on the command line - "git <cmd> <revs> <pathspec>" is to make sure that all the non-rev - parameters in the later part of the command line are names of the - files in the working tree, but that means "git grep $str -- \*.c" - must always be disambiguated with "--", because nobody sane will - create a file whose name literally is asterisk-dot-see. Loosen the - heuristic to declare that with a wildcard string the user likely - meant to give us a pathspec. - - * "git merge FETCH_HEAD" learned that the previous "git fetch" could - be to create an Octopus merge, i.e. recording multiple branches - that are not marked as "not-for-merge"; this allows us to lose an - old style invocation "git merge <msg> HEAD $commits..." in the - implementation of "git pull" script; the old style syntax can now - be deprecated (but not removed yet). - - * Filter scripts were run with SIGPIPE disabled on the Git side, - expecting that they may not read what Git feeds them to filter. - We however treated a filter that does not read its input fully - before exiting as an error. We no longer do and ignore EPIPE - when writing to feed the filter scripts. - - This changes semantics, but arguably in a good way. If a filter - can produce its output without fully consuming its input using - whatever magic, we now let it do so, instead of diagnosing it - as a programming error. - - * Instead of dying immediately upon failing to obtain a lock, the - locking (of refs etc) retries after a short while with backoff. - - * Introduce http.<url>.SSLCipherList configuration variable to tweak - the list of cipher suite to be used with libcURL when talking with - https:// sites. - - * "git subtree" script (in contrib/) used "echo -n" to produce - progress messages in a non-portable way. - - * "git subtree" script (in contrib/) does not have --squash option - when pushing, but the documentation and help text pretended as if - it did. - - * The Git subcommand completion (in contrib/) no longer lists credential - helpers among candidates; they are not something the end user would - invoke interactively. - - * The index file can be taught with "update-index --untracked-cache" - to optionally remember already seen untracked files, in order to - speed up "git status" in a working tree with tons of cruft. - - * "git mergetool" learned to drive WinMerge as a backend. - - * "git upload-pack" that serves "git fetch" can be told to serve - commits that are not at the tip of any ref, as long as they are - reachable from a ref, with uploadpack.allowReachableSHA1InWant - configuration variable. - - * "git cat-file --batch(-check)" learned the "--follow-symlinks" - option that follows an in-tree symbolic link when asked about an - object via extended SHA-1 syntax, e.g. HEAD:RelNotes that points at - Documentation/RelNotes/2.5.0.txt. With the new option, the command - behaves as if HEAD:Documentation/RelNotes/2.5.0.txt was given as - input instead. - - Consider this as still an experimental and incomplete feature: - - - We may want to do the same for in-index objects, e.g. - asking for :RelNotes with this option should give - :Documentation/RelNotes/2.5.0.txt, too - - - "git cat-file --follow-symlinks blob HEAD:RelNotes" - may also be something we want to allow in the future. - - * "git send-email" learned the alias file format used by the sendmail - program (in a simplified form; we obviously do not feed pipes). - - * Traditionally, external low-level 3-way merge drivers are expected - to produce their results based solely on the contents of the three - variants given in temporary files named by %O, %A and %B on their - command line. Additionally allow them to look at the final path - (given by %P). - - * "git blame" learned blame.showEmail configuration variable. - - * "git apply" cannot diagnose a patch corruption when the breakage is - to mark the length of the hunk shorter than it really is on the - hunk header line "@@ -l,k +m,n @@"; one special case it could is - when the hunk becomes no-op (e.g. k == n == 2 for two-line context - patch output), and it learned to do so in this special case. - - * Add the "--allow-unknown-type" option to "cat-file" to allow - inspecting loose objects of an experimental or a broken type. - - * Many long-running operations show progress eye-candy, even when - they are later backgrounded. Hide the eye-candy when the process - is sent to the background instead. - (merge a4fb76c lm/squelch-bg-progress later to maint). - - -Performance, Internal Implementation, Development Support etc. - - * "unsigned char [20]" used throughout the code to represent object - names are being converted into a semi-opaque "struct object_id". - This effort is expected to interfere with other topics in flight, - but hopefully will give us one extra level of abstraction in the - end, when completed. - - * for_each_ref() callback functions were taught to name the objects - not with "unsigned char sha1[20]" but with "struct object_id". - - * Catch a programmer mistake to feed a pointer not an array to - ARRAY_SIZE() macro, by using a couple of GCC extensions. - - * Some error messages in "git config" were emitted without calling - the usual error() facility. - - * When "add--interactive" splits a hunk into two overlapping hunks - and then let the user choose only one, it sometimes feeds an - incorrect patch text to "git apply". Add tests to demonstrate - this. - - I have a slight suspicion that this may be $gmane/87202 coming back - and biting us (I seem to have said "let's run with this and see - what happens" back then). - - * More line-ending tests. - - * An earlier rewrite to use strbuf_getwholeline() instead of fgets(3) - to read packed-refs file revealed that the former is unacceptably - inefficient. It has been optimized by using getdelim(3) when - available. - - * The refs API uses ref_lock struct which had its own "int fd", even - though the same file descriptor was in the lock struct it contains. - Clean-up the code to lose this redundant field. - - * There was a dead code that used to handle "git pull --tags" and - show special-cased error message, which was made irrelevant when - the semantics of the option changed back in Git 1.9 days. - (merge 19d122b pt/pull-tags-error-diag later to maint). - - * Help us to find broken test script that splits the body part of the - test by mistaken use of wrong kind of quotes. - (merge d93d5d5 jc/test-prereq-validate later to maint). - - * Developer support to automatically detect broken &&-chain in the - test scripts is now turned on by default. - (merge 92b269f jk/test-chain-lint later to maint). - - * Error reporting mechanism used in "refs" API has been made more - consistent. - - * "git pull" has more test coverage now. - - * "git pull" has become more aware of the options meant for - underlying "git fetch" and then learned to use parse-options - parser. - - * Clarify in the Makefile a guideline to decide use of USE_NSEC. - -Also contains various documentation updates and code clean-ups. - - -Fixes since v2.4 ----------------- - -Unless otherwise noted, all the fixes since v2.4 in the maintenance -track are contained in this release (see the maintenance releases' -notes for details). - - * Git 2.4 broke setting verbosity and progress levels on "git clone" - with native transports. - (merge 822f0c4 mh/clone-verbosity-fix later to maint). - - * "git add -e" did not allow the user to abort the operation by - killing the editor. - (merge cb64800 jk/add-e-kill-editor later to maint). - - * Memory usage of "git index-pack" has been trimmed by tens of - per-cent. - (merge f0e7f11 nd/slim-index-pack-memory-usage later to maint). - - * "git rev-list --objects $old --not --all" to see if everything that - is reachable from $old is already connected to the existing refs - was very inefficient. - (merge b6e8a3b jk/still-interesting later to maint). - - * "hash-object --literally" introduced in v2.2 was not prepared to - take a really long object type name. - (merge 1427a7f jc/hash-object later to maint). - - * "git rebase --quiet" was not quite quiet when there is nothing to - do. - (merge 22946a9 jk/rebase-quiet-noop later to maint). - - * The completion for "log --decorate=" parameter value was incorrect. - (merge af16bda sg/complete-decorate-full-not-long later to maint). - - * "filter-branch" corrupted commit log message that ends with an - incomplete line on platforms with some "sed" implementations that - munge such a line. Work it around by avoiding to use "sed". - (merge df06201 jk/filter-branch-use-of-sed-on-incomplete-line later to maint). - - * "git daemon" fails to build from the source under NO_IPV6 - configuration (regression in 2.4). - (merge d358f77 jc/daemon-no-ipv6-for-2.4.1 later to maint). - - * Some time ago, "git blame" (incorrectly) lost the convert_to_git() - call when synthesizing a fake "tip" commit that represents the - state in the working tree, which broke folks who record the history - with LF line ending to make their project portable across platforms - while terminating lines in their working tree files with CRLF for - their platform. - (merge 4bf256d tb/blame-resurrect-convert-to-git later to maint). - - * We avoid setting core.worktree when the repository location is the - ".git" directory directly at the top level of the working tree, but - the code misdetected the case in which the working tree is at the - root level of the filesystem (which arguably is a silly thing to - do, but still valid). - (merge 84ccad8 jk/init-core-worktree-at-root later to maint). - - * "git commit --date=now" or anything that relies on approxidate lost - the daylight-saving-time offset. - (merge f6e6362 jc/epochtime-wo-tz later to maint). - - * Access to objects in repositories that borrow from another one on a - slow NFS server unnecessarily got more expensive due to recent code - becoming more cautious in a naive way not to lose objects to pruning. - (merge ee1c6c3 jk/prune-mtime later to maint). - - * The codepaths that read .gitignore and .gitattributes files have been - taught that these files encoded in UTF-8 may have UTF-8 BOM marker at - the beginning; this makes it in line with what we do for configuration - files already. - (merge 27547e5 cn/bom-in-gitignore later to maint). - - * a few helper scripts in the test suite did not report errors - correctly. - (merge de248e9 ep/fix-test-lib-functions-report later to maint). - - * The default $HOME/.gitconfig file created upon "git config --global" - that edits it had incorrectly spelled user.name and user.email - entries in it. - (merge 7e11052 oh/fix-config-default-user-name-section later to maint). - - * "git cat-file bl $blob" failed to barf even though there is no - object type that is "bl". - (merge b7994af jk/type-from-string-gently later to maint). - - * The usual "git diff" when seeing a file turning into a directory - showed a patchset to remove the file and create all files in the - directory, but "git diff --no-index" simply refused to work. Also, - when asked to compare a file and a directory, imitate POSIX "diff" - and compare the file with the file with the same name in the - directory, instead of refusing to run. - (merge 0615173 jc/diff-no-index-d-f later to maint). - - * "git rebase -i" moved the "current" command from "todo" to "done" a - bit too prematurely, losing a step when a "pick" did not even start. - (merge 8cbc57c ph/rebase-i-redo later to maint). - - * The connection initiation code for "ssh" transport tried to absorb - differences between the stock "ssh" and Putty-supplied "plink" and - its derivatives, but the logic to tell that we are using "plink" - variants were too loose and falsely triggered when "plink" appeared - anywhere in the path (e.g. "/home/me/bin/uplink/ssh"). - (merge baaf233 bc/connect-plink later to maint). - - * We have prepended $GIT_EXEC_PATH and the path "git" is installed in - (typically "/usr/bin") to $PATH when invoking subprograms and hooks - for almost eternity, but the original use case the latter tried to - support was semi-bogus (i.e. install git to /opt/foo/git and run it - without having /opt/foo on $PATH), and more importantly it has - become less and less relevant as Git grew more mainstream (i.e. the - users would _want_ to have it on their $PATH). Stop prepending the - path in which "git" is installed to users' $PATH, as that would - interfere the command search order people depend on (e.g. they may - not like versions of programs that are unrelated to Git in /usr/bin - and want to override them by having different ones in /usr/local/bin - and have the latter directory earlier in their $PATH). - (merge a0b4507 jk/git-no-more-argv0-path-munging later to maint). - - * core.excludesfile (defaulting to $XDG_HOME/git/ignore) is supposed - to be overridden by repository-specific .git/info/exclude file, but - the order was swapped from the beginning. This belatedly fixes it. - (merge 099d2d8 jc/gitignore-precedence later to maint). - - * There was a commented-out (instead of being marked to expect - failure) test that documented a breakage that was fixed since the - test was written; turn it into a proper test. - (merge 66d2e04 sb/t1020-cleanup later to maint). - - * The "log --decorate" enhancement in Git 2.4 that shows the commit - at the tip of the current branch e.g. "HEAD -> master", did not - work with --decorate=full. - (merge 429ad20 mg/log-decorate-HEAD later to maint). - - * The ref API did not handle cases where 'refs/heads/xyzzy/frotz' is - removed at the same time as 'refs/heads/xyzzy' is added (or vice - versa) very well. - (merge c628edf mh/ref-directory-file later to maint). - - * Multi-ref transaction support we merged a few releases ago - unnecessarily kept many file descriptors open, risking to fail with - resource exhaustion. This is for 2.4.x track. - (merge 185ce3a mh/write-refs-sooner-2.4 later to maint). - - * "git bundle verify" did not diagnose extra parameters on the - command line. - (merge 7886cfa ps/bundle-verify-arg later to maint). - - * Various documentation mark-up fixes to make the output more - consistent in general and also make AsciiDoctor (an alternative - formatter) happier. - (merge d0258b9 jk/asciidoc-markup-fix later to maint). - (merge ad3967a jk/stripspace-asciidoctor-fix later to maint). - (merge 975e382 ja/tutorial-asciidoctor-fix later to maint). - - * The code to read pack-bitmap wanted to allocate a few hundred - pointers to a structure, but by mistake allocated and leaked memory - enough to hold that many actual structures. Correct the allocation - size and also have it on stack, as it is small enough. - (merge 599dc76 rs/plug-leak-in-pack-bitmaps later to maint). - - * The pull.ff configuration was supposed to override the merge.ff - configuration, but it didn't. - (merge db9bb28 pt/pull-ff-vs-merge-ff later to maint). - - * "git pull --log" and "git pull --no-log" worked as expected, but - "git pull --log=20" did not. - (merge 5061a44 pt/pull-log-n later to maint). - - * "git rerere forget" in a repository without rerere enabled gave a - cryptic error message; it should be a silent no-op instead. - (merge 0544574 jk/rerere-forget-check-enabled later to maint). - - * "git rebase -i" fired post-rewrite hook when it shouldn't (namely, - when it was told to stop sequencing with 'exec' insn). - (merge 141ff8f mm/rebase-i-post-rewrite-exec later to maint). - - * Clarify that "log --raw" and "log --format=raw" are unrelated - concepts. - (merge 92de921 mm/log-format-raw-doc later to maint). - - * Make "git stash something --help" error out, so that users can - safely say "git stash drop --help". - (merge 5ba2831 jk/stash-options later to maint). - - * The clean/smudge interface did not work well when filtering an - empty contents (failed and then passed the empty input through). - It can be argued that a filter that produces anything but empty for - an empty input is nonsense, but if the user wants to do strange - things, then why not? - (merge f6a1e1e jh/filter-empty-contents later to maint). - - * Communication between the HTTP server and http_backend process can - lead to a dead-lock when relaying a large ref negotiation request. - Diagnose the situation better, and mitigate it by reading such a - request first into core (to a reasonable limit). - (merge 636614f jk/http-backend-deadlock later to maint). - - * "git clean pathspec..." tried to lstat(2) and complain even for - paths outside the given pathspec. - (merge 838d6a9 dt/clean-pathspec-filter-then-lstat later to maint). - - * Recent "git prune" traverses young unreachable objects to safekeep - old objects in the reachability chain from them, which sometimes - caused error messages that are unnecessarily alarming. - (merge ce4e7b2 jk/squelch-missing-link-warning-for-unreachable later to maint). - - * The configuration reader/writer uses mmap(2) interface to access - the files; when we find a directory, it barfed with "Out of memory?". - (merge 9ca0aaf jk/diagnose-config-mmap-failure later to maint). - - * "color.diff.plain" was a misnomer; give it 'color.diff.context' as - a more logical synonym. - (merge 8dbf3eb jk/color-diff-plain-is-context later to maint). - - * The setup code used to die when core.bare and core.worktree are set - inconsistently, even for commands that do not need working tree. - (merge fada767 jk/die-on-bogus-worktree-late later to maint). - - * Recent Mac OS X updates breaks the logic to detect that the machine - is on the AC power in the sample pre-auto-gc script. - (merge c54c7b3 pa/auto-gc-mac-osx later to maint). - - * "git commit --cleanup=scissors" was not careful enough to protect - against getting fooled by a line that looked like scissors. - (merge fbfa097 sg/commit-cleanup-scissors later to maint). - - * "Have we lost a race with competing repack?" check was too - expensive, especially while receiving a huge object transfer - that runs index-pack (e.g. "clone" or "fetch"). - (merge 0eeb077 jk/index-pack-reduce-recheck later to maint). - - * The tcsh completion writes a bash scriptlet but that would have - failed for users with noclobber set. - (merge 0b1f688 af/tcsh-completion-noclobber later to maint). - - * "git for-each-ref" reported "missing object" for 0{40} when it - encounters a broken ref. The lack of object whose name is 0{40} is - not the problem; the ref being broken is. - (merge 501cf47 mh/reporting-broken-refs-from-for-each-ref later to maint). - - * Various fixes around "git am" that applies a patch to a history - that is not there yet. - (merge 6ea3b67 pt/am-abort-fix later to maint). - - * "git fsck" used to ignore missing or invalid objects recorded in reflog. - (merge 19bf6c9 mh/fsck-reflog-entries later to maint). - - * "git format-patch --ignore-if-upstream A..B" did not like to be fed - tags as boundary commits. - (merge 9b7a61d jc/do-not-feed-tags-to-clear-commit-marks later to maint). - - * "git fetch --depth=<depth>" and "git clone --depth=<depth>" issued - a shallow transfer request even to an upload-pack that does not - support the capability. - (merge eb86a50 me/fetch-into-shallow-safety later to maint). - - * "git rebase" did not exit with failure when format-patch it invoked - failed for whatever reason. - (merge 60d708b cb/rebase-am-exit-code later to maint). - - * Fix a small bug in our use of umask() return value. - (merge 3096b2e jk/fix-refresh-utime later to maint). - - * An ancient test framework enhancement to allow color was not - entirely correct; this makes it work even when tput needs to read - from the ~/.terminfo under the user's real HOME directory. - (merge d5c1b7c rh/test-color-avoid-terminfo-in-original-home later to maint). - - * A minor bugfix when pack bitmap is used with "rev-list --count". - (merge c8a70d3 jk/rev-list-no-bitmap-while-pruning later to maint). - - * "git config" failed to update the configuration file when the - underlying filesystem is incapable of renaming a file that is still - open. - (merge 7a64592 kb/config-unmap-before-renaming later to maint). - - * Avoid possible ssize_t to int truncation. - (merge 6c8afe4 mh/strbuf-read-file-returns-ssize-t later to maint). - - * When you say "!<ENTER>" while running say "git log", you'd confuse - yourself in the resulting shell, that may look as if you took - control back to the original shell you spawned "git log" from but - that isn't what is happening. To that new shell, we leaked - GIT_PAGER_IN_USE environment variable that was meant as a local - communication between the original "Git" and subprocesses that was - spawned by it after we launched the pager, which caused many - "interesting" things to happen, e.g. "git diff | cat" still paints - its output in color by default. - - Stop leaking that environment variable to the pager's half of the - fork; we only need it on "Git" side when we spawn the pager. - (merge 124b519 jc/unexport-git-pager-in-use-in-pager later to maint). - - * Abandoning an already applied change in "git rebase -i" with - "--continue" left CHERRY_PICK_HEAD and confused later steps. - (merge 0e0aff4 js/rebase-i-clean-up-upon-continue-to-skip later to maint). - - * We used to ask libCURL to use the most secure authentication method - available when talking to an HTTP proxy only when we were told to - talk to one via configuration variables. We now ask libCURL to - always use the most secure authentication method, because the user - can tell libCURL to use an HTTP proxy via an environment variable - without using configuration variables. - (merge 5841520 et/http-proxyauth later to maint). - - * A fix to a minor regression to "git fsck" in v2.2 era that started - complaining about a body-less tag object when it lacks a separator - empty line after its header to separate it with a non-existent body. - (merge 84d18c0 jc/fsck-retire-require-eoh later to maint). - - * Code cleanups and documentation updates. - (merge 0269f96 mm/usage-log-l-can-take-regex later to maint). - (merge 64f2589 nd/t1509-chroot-test later to maint). - (merge d201a1e sb/test-bitmap-free-at-end later to maint). - (merge 05bfc7d sb/line-log-plug-pairdiff-leak later to maint). - (merge 846e5df pt/xdg-config-path later to maint). - (merge 1154aa4 jc/plug-fmt-merge-msg-leak later to maint). - (merge 319b678 jk/sha1-file-reduce-useless-warnings later to maint). - (merge 9a35c14 fg/document-commit-message-stripping later to maint). - (merge bbf431c ps/doc-packfile-vs-pack-file later to maint). - (merge 309a9e3 jk/skip-http-tests-under-no-curl later to maint). - (merge ccd593c dl/branch-error-message later to maint). - (merge 22570b6 rs/janitorial later to maint). - (merge 5c2a581 mc/commit-doc-grammofix later to maint). - (merge ce41720 ah/usage-strings later to maint). - (merge e6a268c sb/glossary-submodule later to maint). - (merge ec48a76 sb/submodule-doc-intro later to maint). - (merge 14f8b9b jk/clone-dissociate later to maint). - (merge 055c7e9 sb/pack-protocol-mention-smart-http later to maint). - (merge 7c37a5d jk/make-fix-dependencies later to maint). - (merge fc0aa39 sg/merge-summary-config later to maint). - (merge 329af6c pt/t0302-needs-sanity later to maint). - (merge d614f07 fk/doc-format-patch-vn later to maint). - (merge 72dbb36 sg/completion-commit-cleanup later to maint). - (merge e654eb2 es/utf8-stupid-compiler-workaround later to maint). - (merge 34b935c es/osx-header-pollutes-mask-macro later to maint). - (merge ab7fade jc/prompt-document-ps1-state-separator later to maint). - (merge 25f600e mm/describe-doc later to maint). - (merge 83fe167 mm/branch-doc-updates later to maint). - (merge 75d2e5a ls/hint-rev-list-count later to maint). - (merge edc8f71 cb/subtree-tests-update later to maint). - (merge 5330e6e sb/p5310-and-chain later to maint). - (merge c4ac525 tb/checkout-doc later to maint). - (merge e479c5f jk/pretty-encoding-doc later to maint). - (merge 7e837c6 ss/clone-guess-dir-name-simplify later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.5.1.txt b/third_party/git/Documentation/RelNotes/2.5.1.txt deleted file mode 100644 index b70553308a..0000000000 --- a/third_party/git/Documentation/RelNotes/2.5.1.txt +++ /dev/null @@ -1,65 +0,0 @@ -Git v2.5.1 Release Notes -======================== - -Fixes since v2.5 ----------------- - - * Running an aliased command from a subdirectory when the .git thing - in the working tree is a gitfile pointing elsewhere did not work. - - * Often a fast-import stream builds a new commit on top of the - previous commit it built, and it often unconditionally emits a - "from" command to specify the first parent, which can be omitted in - such a case. This caused fast-import to forget the tree of the - previous commit and then re-read it from scratch, which was - inefficient. Optimize for this common case. - - * The "rev-parse --parseopt" mode parsed the option specification - and the argument hint in a strange way to allow '=' and other - special characters in the option name while forbidding them from - the argument hint. This made it impossible to define an option - like "--pair <key>=<value>" with "pair=key=value" specification, - which instead would have defined a "--pair=key <value>" option. - - * A "rebase" replays changes of the local branch on top of something - else, as such they are placed in stage #3 and referred to as - "theirs", while the changes in the new base, typically a foreign - work, are placed in stage #2 and referred to as "ours". Clarify - the "checkout --ours/--theirs". - - * An experimental "untracked cache" feature used uname(2) in a - slightly unportable way. - - * "sparse checkout" misbehaved for a path that is excluded from the - checkout when switching between branches that differ at the path. - - * The low-level "git send-pack" did not honor 'user.signingkey' - configuration variable when sending a signed-push. - - * An attempt to delete a ref by pushing into a repository whose HEAD - symbolic reference points at an unborn branch that cannot be - created due to ref D/F conflict (e.g. refs/heads/a/b exists, HEAD - points at refs/heads/a) failed. - - * "git subtree" (in contrib/) depended on "git log" output to be - stable, which was a no-no. Apply a workaround to force a - particular date format. - - * "git clone $URL" in recent releases of Git contains a regression in - the code that invents a new repository name incorrectly based on - the $URL. This has been corrected. - (merge db2e220 jk/guess-repo-name-regression-fix later to maint). - - * Running tests with the "-x" option to make them verbose had some - unpleasant interactions with other features of the test suite. - (merge 9b5fe78 jk/test-with-x later to maint). - - * "git pull" in recent releases of Git has a regression in the code - that allows custom path to the --upload-pack=<program>. This has - been corrected. - - * pipe() emulation used in Git for Windows looked at a wrong variable - when checking for an error from an _open_osfhandle() call. - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.5.2.txt b/third_party/git/Documentation/RelNotes/2.5.2.txt deleted file mode 100644 index 3f749398bb..0000000000 --- a/third_party/git/Documentation/RelNotes/2.5.2.txt +++ /dev/null @@ -1,63 +0,0 @@ -Git v2.5.2 Release Notes -======================== - -Fixes since v2.5.1 ------------------- - - * "git init empty && git -C empty log" said "bad default revision 'HEAD'", - which was found to be a bit confusing to new users. - - * The "interpret-trailers" helper mistook a multi-paragraph title of - a commit log message with a colon in it as the end of the trailer - block. - - * When re-priming the cache-tree opportunistically while committing - the in-core index as-is, we mistakenly invalidated the in-core - index too aggressively, causing the experimental split-index code - to unnecessarily rewrite the on-disk index file(s). - - * "git archive" did not use zip64 extension when creating an archive - with more than 64k entries, which nobody should need, right ;-)? - - * The code in "multiple-worktree" support that attempted to recover - from an inconsistent state updated an incorrect file. - - * "git rev-list" does not take "--notes" option, but did not complain - when one is given. - - * Because the configuration system does not allow "alias.0foo" and - "pager.0foo" as the configuration key, the user cannot use '0foo' - as a custom command name anyway, but "git 0foo" tried to look these - keys up and emitted useless warnings before saying '0foo is not a - git command'. These warning messages have been squelched. - - * We recently rewrote one of the build scripts in Perl, which made it - necessary to have Perl to build Git. Reduced Perl dependency by - rewriting it again using sed. - - * t1509 test that requires a dedicated VM environment had some - bitrot, which has been corrected. - - * strbuf_read() used to have one extra iteration (and an unnecessary - strbuf_grow() of 8kB), which was eliminated. - - * The codepath to produce error messages had a hard-coded limit to - the size of the message, primarily to avoid memory allocation while - calling die(). - - * When trying to see that an object does not exist, a state errno - leaked from our "first try to open a packfile with O_NOATIME and - then if it fails retry without it" logic on a system that refuses - O_NOATIME. This confused us and caused us to die, saying that the - packfile is unreadable, when we should have just reported that the - object does not exist in that packfile to the caller. - - * An off-by-one error made "git remote" to mishandle a remote with a - single letter nickname. - - * A handful of codepaths that used to use fixed-sized arrays to hold - pathnames have been corrected to use strbuf and other mechanisms to - allow longer pathnames without fearing overflows. - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.5.3.txt b/third_party/git/Documentation/RelNotes/2.5.3.txt deleted file mode 100644 index d1436857cb..0000000000 --- a/third_party/git/Documentation/RelNotes/2.5.3.txt +++ /dev/null @@ -1,17 +0,0 @@ -Git v2.5.3 Release Notes -======================== - -Fixes since v2.5.2 ------------------- - - * The experimental untracked-cache feature were buggy when paths with - a few levels of subdirectories are involved. - - * Recent versions of scripted "git am" has a performance regression - in "git am --skip" codepath, which no longer exists in the - built-in version on the 'master' front. Fix the regression in - the last scripted version that appear in 2.5.x maintenance track - and older. - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.5.4.txt b/third_party/git/Documentation/RelNotes/2.5.4.txt deleted file mode 100644 index b8a2f93ee7..0000000000 --- a/third_party/git/Documentation/RelNotes/2.5.4.txt +++ /dev/null @@ -1,18 +0,0 @@ -Git v2.5.4 Release Notes -======================== - -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 somewhere - around 1GB for now. - - * Some protocols (like git-remote-ext) can execute arbitrary code - found in the URL. The URLs that submodules use may come from - arbitrary sources (e.g., .gitmodules files in a remote - repository), and can hurt those who blindly enable recursive - fetch. Restrict the allowed protocols to well known and safe - ones. diff --git a/third_party/git/Documentation/RelNotes/2.5.5.txt b/third_party/git/Documentation/RelNotes/2.5.5.txt deleted file mode 100644 index 37eae9a2d9..0000000000 --- a/third_party/git/Documentation/RelNotes/2.5.5.txt +++ /dev/null @@ -1,11 +0,0 @@ -Git v2.5.5 Release Notes -======================== - -Fixes since v2.5.4 ------------------- - - * Bugfix patches were backported from the 'master' front to plug heap - corruption holes, to catch integer overflow in the computation of - pathname lengths, and to get rid of the name_path API. Both of - these would have resulted in writing over an under-allocated buffer - when formulating pathnames while tree traversal. diff --git a/third_party/git/Documentation/RelNotes/2.5.6.txt b/third_party/git/Documentation/RelNotes/2.5.6.txt deleted file mode 100644 index 9cd025bb1c..0000000000 --- a/third_party/git/Documentation/RelNotes/2.5.6.txt +++ /dev/null @@ -1,12 +0,0 @@ -Git v2.5.6 Release Notes -======================== - -Fixes since v2.5.5 ------------------- - - * "git-shell" rejects a request to serve a repository whose name - begins with a dash, which makes it no longer possible to get it - confused into spawning service programs like "git-upload-pack" with - an option like "--help", which in turn would spawn an interactive - pager, instead of working with the repository user asked to access - (i.e. the one whose name is "--help"). diff --git a/third_party/git/Documentation/RelNotes/2.6.0.txt b/third_party/git/Documentation/RelNotes/2.6.0.txt deleted file mode 100644 index 7288aaf716..0000000000 --- a/third_party/git/Documentation/RelNotes/2.6.0.txt +++ /dev/null @@ -1,370 +0,0 @@ -Git 2.6 Release Notes -===================== - -Updates since v2.5 ------------------- - -UI, Workflows & Features - - * An asterisk as a substring (as opposed to the entirety) of a path - component for both side of a refspec, e.g. - "refs/heads/o*:refs/remotes/heads/i*", is now allowed. - - * New userdiff pattern definition for fountain screenwriting markup - format has been added. - - * "git log" and friends learned a new "--date=format:..." option to - format timestamps using system's strftime(3). - - * "git fast-import" learned to respond to the get-mark command via - its cat-blob-fd interface. - - * "git rebase -i" learned "drop commit-object-name subject" command - as another way to skip replaying of a commit. - - * A new configuration variable can enable "--follow" automatically - when "git log" is run with one pathspec argument. - - * "git status" learned to show a more detailed information regarding - the "rebase -i" session in progress. - - * "git cat-file" learned "--batch-all-objects" option to enumerate all - available objects in the repository more quickly than "rev-list - --all --objects" (the output includes unreachable objects, though). - - * "git fsck" learned to ignore errors on a set of known-to-be-bad - objects, and also allows the warning levels of various kinds of - non-critical breakages to be tweaked. - - * "git rebase -i"'s list of todo is made configurable. - - * "git send-email" now performs alias-expansion on names that are - given via --cccmd, etc. - - * An environment variable GIT_REPLACE_REF_BASE tells Git to look into - refs hierarchy other than refs/replace/ for the object replacement - data. - - * Allow untracked cache (experimental) to be used when sparse - checkout (experimental) is also in use. - - * "git pull --rebase" has been taught to pay attention to - rebase.autostash configuration. - - * The command-line completion script (in contrib/) has been updated. - - * A negative !ref entry in multi-value transfer.hideRefs - configuration can be used to say "don't hide this one". - - * After "git am" without "-3" stops, running "git am -3" pays attention - to "-3" only for the patch that caused the original invocation - to stop. - - * When linked worktree is used, simultaneous "notes merge" instances - for the same ref in refs/notes/* are prevented from stomping on - each other. - - * "git send-email" learned a new option --smtp-auth to limit the SMTP - AUTH mechanisms to be used to a subset of what the system library - supports. - - * A new configuration variable http.sslVersion can be used to specify - what specific version of SSL/TLS to use to make a connection. - - * "git notes merge" can be told with "--strategy=<how>" option how to - automatically handle conflicts; this can now be configured by - setting notes.mergeStrategy configuration variable. - - * "git log --cc" did not show any patch, even though most of the time - the user meant "git log --cc -p -m" to see patch output for commits - with a single parent, and combined diff for merge commits. The - command is taught to DWIM "--cc" (without "--raw" and other forms - of output specification) to "--cc -p -m". - - * "git config --list" output was hard to parse when values consist of - multiple lines. "--name-only" option is added to help this. - - * A handful of usability & cosmetic fixes to gitk and l10n updates. - - * A completely empty e-mail address <> is now allowed in the authors - file used by git-svn, to match the way it accepts the output from - authors-prog. - - -Performance, Internal Implementation, Development Support etc. - - * In preparation for allowing different "backends" to store the refs - in a way different from the traditional "one ref per file in - $GIT_DIR or in a $GIT_DIR/packed-refs file" filesystem storage, - direct filesystem access to ref-like things like CHERRY_PICK_HEAD - from scripts and programs has been reduced. - - * Computation of untracked status indicator by bash prompt - script (in contrib/) has been optimized. - - * Memory use reduction when commit-slab facility is used to annotate - sparsely (which is not recommended in the first place). - - * Clean up refs API and make "git clone" less intimate with the - implementation detail. - - * "git pull" was reimplemented in C. - - * The packet tracing machinery allows to capture an incoming pack - data to a file for debugging. - - * Move machinery to parse human-readable scaled numbers like 1k, 4M, - and 2G as an option parameter's value from pack-objects to - parse-options API, to make it available to other codepaths. - - * "git verify-tag" and "git verify-commit" have been taught to share - more code, and then learned to optionally show the verification - message from the underlying GPG implementation. - - * Various enhancements around "git am" reading patches generated by - foreign SCM have been made. - - * Ref listing by "git branch -l" and "git tag -l" commands has - started to be rebuilt, based on the for-each-ref machinery. - - * The code to perform multi-tree merges has been taught to repopulate - the cache-tree upon a successful merge into the index, so that - subsequent "diff-index --cached" (hence "status") and "write-tree" - (hence "commit") will go faster. - - The same logic in "git checkout" may now be removed, but that is a - separate issue. - - * Tests that assume how reflogs are represented on the filesystem too - much have been corrected. - - * "git am" has been rewritten in "C". - - * git_path() and mkpath() are handy helper functions but it is easy - to misuse, as the callers need to be careful to keep the number of - active results below 4. Their uses have been reduced. - - * The "lockfile" API has been rebuilt on top of a new "tempfile" API. - - * To prepare for allowing a different "ref" backend to be plugged in - to the system, update_ref()/delete_ref() have been taught about - ref-like things like MERGE_HEAD that are per-worktree (they will - always be written to the filesystem inside $GIT_DIR). - - * The gitmodules API that is accessed from the C code learned to - cache stuff lazily. - - -Also contains various documentation updates and code clean-ups. - - -Fixes since v2.5 ----------------- - -Unless otherwise noted, all the fixes since v2.5 in the maintenance -track are contained in this release (see the maintenance releases' -notes for details). - - * "git subtree" (in contrib/) depended on "git log" output to be - stable, which was a no-no. Apply a workaround to force a - particular date format. - (merge e7aac44 da/subtree-date-confusion later to maint). - - * An attempt to delete a ref by pushing into a repository whose HEAD - symbolic reference points at an unborn branch that cannot be - created due to ref D/F conflict (e.g. refs/heads/a/b exists, HEAD - points at refs/heads/a) failed. - (merge b112b14 jx/do-not-crash-receive-pack-wo-head later to maint). - - * The low-level "git send-pack" did not honor 'user.signingkey' - configuration variable when sending a signed-push. - (merge d830d39 db/send-pack-user-signingkey later to maint). - - * "sparse checkout" misbehaved for a path that is excluded from the - checkout when switching between branches that differ at the path. - (merge 7d78241 as/sparse-checkout-removal later to maint). - - * An experimental "untracked cache" feature used uname(2) in a - slightly unportable way. - (merge 100e433 cb/uname-in-untracked later to maint). - - * A "rebase" replays changes of the local branch on top of something - else, as such they are placed in stage #3 and referred to as - "theirs", while the changes in the new base, typically a foreign - work, are placed in stage #2 and referred to as "ours". Clarify - the "checkout --ours/--theirs". - (merge f303016 se/doc-checkout-ours-theirs later to maint). - - * The "rev-parse --parseopt" mode parsed the option specification - and the argument hint in a strange way to allow '=' and other - special characters in the option name while forbidding them from - the argument hint. This made it impossible to define an option - like "--pair <key>=<value>" with "pair=key=value" specification, - which instead would have defined a "--pair=key <value>" option. - (merge 2d893df ib/scripted-parse-opt-better-hint-string later to maint). - - * Often a fast-import stream builds a new commit on top of the - previous commit it built, and it often unconditionally emits a - "from" command to specify the first parent, which can be omitted in - such a case. This caused fast-import to forget the tree of the - previous commit and then re-read it from scratch, which was - inefficient. Optimize for this common case. - (merge 0df3245 mh/fast-import-optimize-current-from later to maint). - - * Running an aliased command from a subdirectory when the .git thing - in the working tree is a gitfile pointing elsewhere did not work. - (merge d95138e nd/export-worktree later to maint). - - * "Is this subdirectory a separate repository that should not be - touched?" check "git clean" was inefficient. This was replaced - with a more optimized check. - (merge fbf2fec ee/clean-remove-dirs later to maint). - - * The "new-worktree-mode" hack in "checkout" that was added in - nd/multiple-work-trees topic has been removed by updating the - implementation of new "worktree add". - (merge 65f9b75 es/worktree-add-cleanup later to maint). - - * Remove remaining cruft from "git checkout --to", which - transitioned to "git worktree add". - (merge 114ff88 es/worktree-add later to maint). - - * An off-by-one error made "git remote" to mishandle a remote with a - single letter nickname. - (merge bc598c3 mh/get-remote-group-fix later to maint). - - * "git clone $URL", when cloning from a site whose sole purpose is to - host a single repository (hence, no path after <scheme>://<site>/), - tried to use the site name as the new repository name, but did not - remove username or password when <site> part was of the form - <user>@<pass>:<host>. The code is taught to redact these. - (merge adef956 ps/guess-repo-name-at-root later to maint). - - * Running tests with the "-x" option to make them verbose had some - unpleasant interactions with other features of the test suite. - (merge 9b5fe78 jk/test-with-x later to maint). - - * t1509 test that requires a dedicated VM environment had some - bitrot, which has been corrected. - (merge faacc5a ps/t1509-chroot-test-fixup later to maint). - - * "git pull" in recent releases of Git has a regression in the code - that allows custom path to the --upload-pack=<program>. This has - been corrected. - - Note that this is irrelevant for 'master' with "git pull" rewritten - in C. - (merge 13e0e28 mm/pull-upload-pack later to maint). - - * When trying to see that an object does not exist, a state errno - leaked from our "first try to open a packfile with O_NOATIME and - then if it fails retry without it" logic on a system that refuses - O_NOATIME. This confused us and caused us to die, saying that the - packfile is unreadable, when we should have just reported that the - object does not exist in that packfile to the caller. - (merge dff6f28 cb/open-noatime-clear-errno later to maint). - - * The codepath to produce error messages had a hard-coded limit to - the size of the message, primarily to avoid memory allocation while - calling die(). - (merge f4c3edc jk/long-error-messages later to maint). - - * strbuf_read() used to have one extra iteration (and an unnecessary - strbuf_grow() of 8kB), which was eliminated. - (merge 3ebbd00 jh/strbuf-read-use-read-in-full later to maint). - - * We rewrote one of the build scripts in Perl but this reimplements - in Bourne shell. - (merge 57cee8a sg/help-group later to maint). - - * The experimental untracked-cache feature were buggy when paths with - a few levels of subdirectories are involved. - (merge 73f9145 dt/untracked-subdir later to maint). - - * "interpret-trailers" helper mistook a single-liner log message that - has a colon as the end of existing trailer. - - * The "interpret-trailers" helper mistook a multi-paragraph title of - a commit log message with a colon in it as the end of the trailer - block. - (merge 5c99995 cc/trailers-corner-case-fix later to maint). - - * "git describe" without argument defaulted to describe the HEAD - commit, but "git describe --contains" didn't. Arguably, in a - repository used for active development, such defaulting would not - be very useful as the tip of branch is typically not tagged, but it - is better to be consistent. - (merge 2bd0706 sg/describe-contains later to maint). - - * The client side codepaths in "git push" have been cleaned up - and the user can request to perform an optional "signed push", - i.e. sign only when the other end accepts signed push. - (merge 68c757f db/push-sign-if-asked later to maint). - - * Because the configuration system does not allow "alias.0foo" and - "pager.0foo" as the configuration key, the user cannot use '0foo' - as a custom command name anyway, but "git 0foo" tried to look these - keys up and emitted useless warnings before saying '0foo is not a - git command'. These warning messages have been squelched. - (merge 9e9de18 jk/fix-alias-pager-config-key-warnings later to maint). - - * "git rev-list" does not take "--notes" option, but did not complain - when one is given. - (merge 2aea7a5 jk/rev-list-has-no-notes later to maint). - - * When re-priming the cache-tree opportunistically while committing - the in-core index as-is, we mistakenly invalidated the in-core - index too aggressively, causing the experimental split-index code - to unnecessarily rewrite the on-disk index file(s). - (merge 475a344 dt/commit-preserve-base-index-upon-opportunistic-cache-tree-update later to maint). - - * "git archive" did not use zip64 extension when creating an archive - with more than 64k entries, which nobody should need, right ;-)? - (merge 88329ca rs/archive-zip-many later to maint). - - * The code in "multiple-worktree" support that attempted to recover - from an inconsistent state updated an incorrect file. - (merge 82fde87 nd/fixup-linked-gitdir later to maint). - - * On case insensitive systems, "git p4" did not work well with client - specs. - - * "git init empty && git -C empty log" said "bad default revision 'HEAD'", - which was found to be a bit confusing to new users. - (merge ce11360 jk/log-missing-default-HEAD later to maint). - - * Recent versions of scripted "git am" has a performance regression in - "git am --skip" codepath, which no longer exists in the built-in - version on the 'master' front. Fix the regression in the last - scripted version that appear in 2.5.x maintenance track and older. - (merge b9d6689 js/maint-am-skip-performance-regression later to maint). - - * The branch descriptions that are set with "git branch --edit-description" - option were used in many places but they weren't clearly documented. - (merge 561d2b7 po/doc-branch-desc later to maint). - - * Code cleanups and documentation updates. - (merge 1c601af es/doc-clean-outdated-tools later to maint). - (merge 3581304 kn/tag-doc-fix later to maint). - (merge 3a59e59 kb/i18n-doc later to maint). - (merge 45abdee sb/remove-unused-var-from-builtin-add later to maint). - (merge 14691e3 sb/parse-options-codeformat later to maint). - (merge 4a6ada3 ad/bisect-cleanup later to maint). - (merge da4c5ad ta/docfix-index-format-tech later to maint). - (merge ae25fd3 sb/check-return-from-read-ref later to maint). - (merge b3325df nd/dwim-wildcards-as-pathspecs later to maint). - (merge 7aa9b9b sg/wt-status-header-inclusion later to maint). - (merge f04c690 as/docfix-reflog-expire-unreachable later to maint). - (merge 1269847 sg/t3020-typofix later to maint). - (merge 8b54c23 jc/calloc-pathspec later to maint). - (merge a6926b8 po/po-readme later to maint). - (merge 54d160e ss/fix-config-fd-leak later to maint). - (merge b80fa84 ah/submodule-typofix-in-error later to maint). - (merge 99885bc ah/reflog-typofix-in-error later to maint). - (merge 9476c2c ah/read-tree-usage-string later to maint). - (merge b8c1d27 ah/pack-objects-usage-strings later to maint). - (merge 486e1e1 br/svn-doc-include-paths-config later to maint). - (merge 1733ed3 ee/clean-test-fixes later to maint). - (merge 5fcadc3 gb/apply-comment-typofix later to maint). - (merge b894d3e mp/t7060-diff-index-test later to maint). - (merge d238710 as/config-doc-markup-fix later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.6.1.txt b/third_party/git/Documentation/RelNotes/2.6.1.txt deleted file mode 100644 index f37ea89cda..0000000000 --- a/third_party/git/Documentation/RelNotes/2.6.1.txt +++ /dev/null @@ -1,18 +0,0 @@ -Git v2.6.1 Release Notes -======================== - -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 somewhere - around 1GB for now. - - * Some protocols (like git-remote-ext) can execute arbitrary code - found in the URL. The URLs that submodules use may come from - arbitrary sources (e.g., .gitmodules files in a remote - repository), and can hurt those who blindly enable recursive - fetch. Restrict the allowed protocols to well known and safe - ones. diff --git a/third_party/git/Documentation/RelNotes/2.6.2.txt b/third_party/git/Documentation/RelNotes/2.6.2.txt deleted file mode 100644 index 5b65e35245..0000000000 --- a/third_party/git/Documentation/RelNotes/2.6.2.txt +++ /dev/null @@ -1,65 +0,0 @@ -Git v2.6.2 Release Notes -======================== - -Fixes since v2.6.1 ------------------- - - * There were some classes of errors that "git fsck" diagnosed to its - standard error that did not cause it to exit with non-zero status. - - * A test script for the HTTP service had a timing dependent bug, - which was fixed. - - * Performance-measurement tests did not work without an installed Git. - - * On a case insensitive filesystems, setting GIT_WORK_TREE variable - using a random cases that does not agree with what the filesystem - thinks confused Git that it wasn't inside the working tree. - - * When "git am" was rewritten as a built-in, it stopped paying - attention to user.signingkey, which was fixed. - - * After "git checkout --detach", "git status" reported a fairly - useless "HEAD detached at HEAD", instead of saying at which exact - commit. - - * "git rebase -i" had a minor regression recently, which stopped - considering a line that begins with an indented '#' in its insn - sheet not a comment, which is now fixed. - - * Description of the "log.follow" configuration variable in "git log" - documentation is now also copied to "git config" documentation. - - * Allocation related functions and stdio are unsafe things to call - inside a signal handler, and indeed killing the pager can cause - glibc to deadlock waiting on allocation mutex as our signal handler - tries to free() some data structures in wait_for_pager(). Reduce - these unsafe calls. - - * The way how --ref/--notes to specify the notes tree reference are - DWIMmed was not clearly documented. - - * Customization to change the behaviour with "make -w" and "make -s" - in our Makefile was broken when they were used together. - - * The Makefile always runs the library archiver with hardcoded "crs" - options, which was inconvenient for exotic platforms on which - people want to use programs with totally different set of command - line options. - - * The ssh transport, just like any other transport over the network, - did not clear GIT_* environment variables, but it is possible to - use SendEnv and AcceptEnv to leak them to the remote invocation of - Git, which is not a good idea at all. Explicitly clear them just - like we do for the local transport. - - * "git blame --first-parent v1.0..v2.0" was not rejected but did not - limit the blame to commits on the first parent chain. - - * Very small number of options take a parameter that is optional - (which is not a great UI element as they can only appear at the end - of the command line). Add notice to documentation of each and - every one of them. - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.6.3.txt b/third_party/git/Documentation/RelNotes/2.6.3.txt deleted file mode 100644 index fc6fe1711f..0000000000 --- a/third_party/git/Documentation/RelNotes/2.6.3.txt +++ /dev/null @@ -1,111 +0,0 @@ -Git v2.6.3 Release Notes -======================== - -Fixes since v2.6.2 ------------------- - - * The error message from "git blame --contents --reverse" incorrectly - talked about "--contents --children". - - * "git merge-file" tried to signal how many conflicts it found, which - obviously would not work well when there are too many of them. - - * The name-hash subsystem that is used to cope with case insensitive - filesystems keeps track of directories and their on-filesystem - cases for all the paths in the index by holding a pointer to a - randomly chosen cache entry that is inside the directory (for its - ce->ce_name component). This pointer was not updated even when the - cache entry was removed from the index, leading to use after free. - This was fixed by recording the path for each directory instead of - borrowing cache entries and restructuring the API somewhat. - - * When the "git am" command was reimplemented in C, "git am -3" had a - small regression where it is aborted in its error handling codepath - when underlying merge-recursive failed in some ways. - - * The synopsis text and the usage string of subcommands that read - list of things from the standard input are often shown as if they - only take input from a file on a filesystem, which was misleading. - - * A couple of commands still showed "[options]" in their usage string - to note where options should come on their command line, but we - spell that "[<options>]" in most places these days. - - * The submodule code has been taught to work better with separate - work trees created via "git worktree add". - - * When "git gc --auto" is backgrounded, its diagnosis message is - lost. It now is saved to a file in $GIT_DIR and is shown next time - the "gc --auto" is run. - - * Work around "git p4" failing when the P4 depot records the contents - in UTF-16 without UTF-16 BOM. - - * Recent update to "rebase -i" that tries to sanity check the edited - insn sheet before it uses it has become too picky on Windows where - CRLF left by the editor is turned into a trailing CR on the line - read via the "read" built-in command. - - * "git clone --dissociate" runs a big "git repack" process at the - end, and it helps to close file descriptors that are open on the - packs and their idx files before doing so on filesystems that - cannot remove a file that is still open. - - * Correct "git p4 --detect-labels" so that it does not fail to create - a tag that points at a commit that is also being imported. - - * The internal stripspace() function has been moved to where it - logically belongs to, i.e. strbuf API, and the command line parser - of "git stripspace" has been updated to use the parse_options API. - - * Prepare for Git on-disk repository representation to undergo - backward incompatible changes by introducing a new repository - format version "1", with an extension mechanism. - - * "git gc" used to barf when a symbolic ref has gone dangling - (e.g. the branch that used to be your upstream's default when you - cloned from it is now gone, and you did "fetch --prune"). - - * The normalize_ceiling_entry() function does not muck with the end - of the path it accepts, and the real world callers do rely on that, - but a test insisted that the function drops a trailing slash. - - * "git gc" is safe to run anytime only because it has the built-in - grace period to protect young objects. In order to run with no - grace period, the user must make sure that the repository is - quiescent. - - * A recent "filter-branch --msg-filter" broke skipping of the commit - object header, which is fixed. - - * "git --literal-pathspecs add -u/-A" without any command line - argument misbehaved ever since Git 2.0. - - * Merging a branch that removes a path and another that changes the - mode bits on the same path should have conflicted at the path, but - it didn't and silently favoured the removal. - - * "git imap-send" did not compile well with older version of cURL library. - - * The linkage order of libraries was wrong in places around libcurl. - - * It was not possible to use a repository-lookalike created by "git - worktree add" as a local source of "git clone". - - * When "git send-email" wanted to talk over Net::SMTP::SSL, - Net::Cmd::datasend() did not like to be fed too many bytes at the - same time and failed to send messages. Send the payload one line - at a time to work around the problem. - - * We peek objects from submodule's object store by linking it to the - list of alternate object databases, but the code to do so forgot to - correctly initialize the list. - - * "git status --branch --short" accessed beyond the constant string - "HEAD", which has been corrected. - - * "git daemon" uses "run_command()" without "finish_command()", so it - needs to release resources itself, which it forgot to do. - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.6.4.txt b/third_party/git/Documentation/RelNotes/2.6.4.txt deleted file mode 100644 index b0256a2dc9..0000000000 --- a/third_party/git/Documentation/RelNotes/2.6.4.txt +++ /dev/null @@ -1,63 +0,0 @@ -Git v2.6.4 Release Notes -======================== - -Fixes since v2.6.3 ------------------- - - * The "configure" script did not test for -lpthread correctly, which - upset some linkers. - - * Add support for talking http/https over socks proxy. - - * Portability fix for Windows, which may rewrite $SHELL variable using - non-POSIX paths. - - * We now consistently allow all hooks to ignore their standard input, - rather than having git complain of SIGPIPE. - - * Fix shell quoting in contrib script. - - * Test portability fix for a topic in v2.6.1. - - * Allow tilde-expansion in some http config variables. - - * Give a useful special case "diff/show --word-diff-regex=." as an - example in the documentation. - - * Fix for a corner case in filter-branch. - - * Make git-p4 work on a detached head. - - * Documentation clarification for "check-ignore" without "--verbose". - - * Just like the working tree is cleaned up when the user cancelled - submission in P4Submit.applyCommit(), clean up the mess if "p4 - submit" fails. - - * Having a leftover .idx file without corresponding .pack file in - the repository hurts performance; "git gc" learned to prune them. - - * The code to prepare the working tree side of temporary directory - for the "dir-diff" feature forgot that symbolic links need not be - copied (or symlinked) to the temporary area, as the code already - special cases and overwrites them. Besides, it was wrong to try - computing the object name of the target of symbolic link, which may - not even exist or may be a directory. - - * There was no way to defeat a configured rebase.autostash variable - from the command line, as "git rebase --no-autostash" was missing. - - * Allow "git interpret-trailers" to run outside of a Git repository. - - * Produce correct "dirty" marker for shell prompts, even when we - are on an orphan or an unborn branch. - - * Some corner cases have been fixed in string-matching done in "git - status". - - * Apple's common crypto implementation of SHA1_Update() does not take - more than 4GB at a time, and we now have a compile-time workaround - for it. - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.6.5.txt b/third_party/git/Documentation/RelNotes/2.6.5.txt deleted file mode 100644 index f0924b62e0..0000000000 --- a/third_party/git/Documentation/RelNotes/2.6.5.txt +++ /dev/null @@ -1,58 +0,0 @@ -Git v2.6.5 Release Notes -======================== - -Fixes since v2.6.4 ------------------- - - * Because "test_when_finished" in our test framework queues the - clean-up tasks to be done in a shell variable, it should not be - used inside a subshell. Add a mechanism to allow 'bash' to catch - such uses, and fix the ones that were found. - - * Update "git subtree" (in contrib/) so that it can take whitespaces - in the pathnames, not only in the in-tree pathname but the name of - the directory that the repository is in. - - * Cosmetic improvement to lock-file error messages. - - * mark_tree_uninteresting() has code to handle the case where it gets - passed a NULL pointer in its 'tree' parameter, but the function had - 'object = &tree->object' assignment before checking if tree is - NULL. This gives a compiler an excuse to declare that tree will - never be NULL and apply a wrong optimization. Avoid it. - - * The helper used to iterate over loose object directories to prune - stale objects did not closedir() immediately when it is done with a - directory--a callback such as the one used for "git prune" may want - to do rmdir(), but it would fail on open directory on platforms - such as WinXP. - - * "git p4" used to import Perforce CLs that touch only paths outside - the client spec as empty commits. It has been corrected to ignore - them instead, with a new configuration git-p4.keepEmptyCommits as a - backward compatibility knob. - - * The exit code of git-fsck did not reflect some types of errors - found in packed objects, which has been corrected. - - * The completion script (in contrib/) used to list "git column" - (which is not an end-user facing command) as one of the choices - - * Improve error reporting when SMTP TLS fails. - - * When getpwuid() on the system returned NULL (e.g. the user is not - in the /etc/passwd file or other uid-to-name mappings), the - codepath to find who the user is to record it in the reflog barfed - and died. Loosen the check in this codepath, which already accepts - questionable ident string (e.g. host part of the e-mail address is - obviously bogus), and in general when we operate fmt_ident() function - in non-strict mode. - - * "git symbolic-ref" forgot to report a failure with its exit status. - - * History traversal with "git log --source" that starts with an - annotated tag failed to report the tag as "source", due to an - old regression in the command line parser back in v2.2 days. - -Also contains typofixes, documentation updates and trivial code -clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.6.6.txt b/third_party/git/Documentation/RelNotes/2.6.6.txt deleted file mode 100644 index 023ad85ec6..0000000000 --- a/third_party/git/Documentation/RelNotes/2.6.6.txt +++ /dev/null @@ -1,11 +0,0 @@ -Git v2.6.6 Release Notes -======================== - -Fixes since v2.6.5 ------------------- - - * Bugfix patches were backported from the 'master' front to plug heap - corruption holes, to catch integer overflow in the computation of - pathname lengths, and to get rid of the name_path API. Both of - these would have resulted in writing over an under-allocated buffer - when formulating pathnames while tree traversal. diff --git a/third_party/git/Documentation/RelNotes/2.6.7.txt b/third_party/git/Documentation/RelNotes/2.6.7.txt deleted file mode 100644 index 1335de49a6..0000000000 --- a/third_party/git/Documentation/RelNotes/2.6.7.txt +++ /dev/null @@ -1,12 +0,0 @@ -Git v2.6.7 Release Notes -======================== - -Fixes since v2.6.6 ------------------- - - * "git-shell" rejects a request to serve a repository whose name - begins with a dash, which makes it no longer possible to get it - confused into spawning service programs like "git-upload-pack" with - an option like "--help", which in turn would spawn an interactive - pager, instead of working with the repository user asked to access - (i.e. the one whose name is "--help"). diff --git a/third_party/git/Documentation/RelNotes/2.7.0.txt b/third_party/git/Documentation/RelNotes/2.7.0.txt deleted file mode 100644 index 563dadc57e..0000000000 --- a/third_party/git/Documentation/RelNotes/2.7.0.txt +++ /dev/null @@ -1,414 +0,0 @@ -Git 2.7 Release Notes -===================== - -Updates since v2.6 ------------------- - -UI, Workflows & Features - - * The appearance of "gitk", particularly on high DPI monitors, have - been improved. "gitk" also comes with an undated translation for - Swedish and Japanese. - - * "git remote" learned "get-url" subcommand to show the URL for a - given remote name used for fetching and pushing. - - * There was no way to defeat a configured rebase.autostash variable - from the command line, as "git rebase --no-autostash" was missing. - - * "git log --date=local" used to only show the normal (default) - format in the local timezone. The command learned to take 'local' - as an instruction to use the local timezone with other formats, - - * The refs used during a "git bisect" session is now per-worktree so - that independent bisect sessions can be done in different worktrees - created with "git worktree add". - - * Users who are too busy to type three extra keystrokes to ask for - "git stash show -p" can now set stash.showPatch configuration - variable to true to always see the actual patch, not just the list - of paths affected with feel for the extent of damage via diffstat. - - * "quiltimport" allows to specify the series file by honoring the - $QUILT_SERIES environment and also --series command line option. - - * The use of 'good/bad' in "git bisect" made it confusing to use when - hunting for a state change that is not a regression (e.g. bugfix). - The command learned 'old/new' and then allows the end user to - say e.g. "bisect start --term-old=fast --term-new=slow" to find a - performance regression. - - * "git interpret-trailers" can now run outside of a Git repository. - - * "git p4" learned to reencode the pathname it uses to communicate - with the p4 depot with a new option. - - * Give progress meter to "git filter-branch". - - * Allow a later "!/abc/def" to override an earlier "/abc" that - appears in the same .gitignore file to make it easier to express - "everything in /abc directory is ignored, except for ...". - - * Teach "git p4" to send large blobs outside the repository by - talking to Git LFS. - - * Prepare for Git on-disk repository representation to undergo - backward incompatible changes by introducing a new repository - format version "1", with an extension mechanism. - - * "git worktree" learned a "list" subcommand. - - * "git clone --dissociate" learned that it can be used even when - "--reference" was not used at the same time. - - * "git blame" learnt to take "--first-parent" and "--reverse" at the - same time when it makes sense. - - * "git checkout" did not follow the usual "--[no-]progress" - convention and implemented only "--quiet" that is essentially - a superset of "--no-progress". Extend the command to support the - usual "--[no-]progress". - - * The semantics of transfer.hideRefs configuration variable have been - extended to work better with the ref "namespace" feature that lets - you throw unrelated bunches of repositories in a single physical - repository and virtually serve them as separate ones. - - * send-email config variables whose values are pathnames now go - through the ~username/ expansion. - - * bash completion learnt to TAB-complete recipient addresses given - to send-email. - - * The credential-cache daemon can be told to ignore SIGHUP to work - around issue when running Git from inside emacs. - - * "git push" learned new configuration for doing "--recurse-submodules" - on each push. - - * "format-patch" has learned a new option to zero-out the commit - object name on the mbox "From " line. - - -Performance, Internal Implementation, Development Support etc. - - * The infrastructure to rewrite "git submodule" in C is being built - incrementally. Let's polish these early parts well enough and make - them graduate to 'next' and 'master', so that the more involved - follow-up can start cooking on a solid ground. - - * Some features from "git tag -l" and "git branch -l" have been made - available to "git for-each-ref" so that eventually the unified - implementation can be shared across all three. The version merged - to the 'master' branch earlier had a performance regression in "tag - --contains", which has since been corrected. - - * Because "test_when_finished" in our test framework queues the - clean-up tasks to be done in a shell variable, it should not be - used inside a subshell. Add a mechanism to allow 'bash' to catch - such uses, and fix the ones that were found. - - * The debugging infrastructure for pkt-line based communication has - been improved to mark the side-band communication specifically. - - * Update "git branch" that list existing branches, using the - ref-filter API that is shared with "git tag" and "git - for-each-ref". - - * The test for various line-ending conversions has been enhanced. - - * A few test scripts around "git p4" have been improved for - portability. - - * Many allocations that is manually counted (correctly) that are - followed by strcpy/sprintf have been replaced with a less error - prone constructs such as xstrfmt. - - * The internal stripspace() function has been moved to where it - logically belongs to, i.e. strbuf API, and the command line parser - of "git stripspace" has been updated to use the parse_options API. - - * "git am" used to spawn "git mailinfo" via run_command() API once - per each patch, but learned to make a direct call to mailinfo() - instead. - - * The implementation of "git mailinfo" was refactored so that a - mailinfo() function can be directly called from inside a process. - - * With a "debug" helper, debugging of a single "git" invocation in - our test scripts has become a lot easier. - - * The "configure" script did not test for -lpthread correctly, which - upset some linkers. - - * Cross completed task off of subtree project's todo list. - - * Test cleanups for the subtree project. - - * Clean up style in an ancient test t9300. - - * Work around some test flakiness with p4d. - - * Fsck did not correctly detect a NUL-truncated header in a tag. - - * Use a safer behavior when we hit errors verifying remote certificates. - - * Speed up filter-branch for cases where we only care about rewriting - commits, not tree data. - - * The parse-options API has been updated to make "-h" command line - option work more consistently in all commands. - - * "git svn rebase/mkdirs" got optimized by keeping track of empty - directories better. - - * Fix some racy client/server tests by treating SIGPIPE the same as a - normal non-zero exit. - - * The necessary infrastructure to build topics using the free Travis - CI has been added. Developers forking from this topic (and enabling - Travis) can do their own builds, and we can turn on auto-builds for - git/git (including build-status for pull requests that people - open). - - * The write(2) emulation for Windows learned to set errno to EPIPE - when necessary. - - -Also contains various documentation updates and code clean-ups. - - -Fixes since v2.6 ----------------- - -Unless otherwise noted, all the fixes since v2.6 in the maintenance -track are contained in this release (see the maintenance releases' -notes for details). - - * Very small number of options take a parameter that is optional - (which is not a great UI element as they can only appear at the end - of the command line). Add notice to documentation of each and - every one of them. - - * "git blame --first-parent v1.0..v2.0" was not rejected but did not - limit the blame to commits on the first parent chain. - - * "git subtree" (in contrib/) now can take whitespaces in the - pathnames, not only in the in-tree pathname but the name of the - directory that the repository is in. - - * The ssh transport, just like any other transport over the network, - did not clear GIT_* environment variables, but it is possible to - use SendEnv and AcceptEnv to leak them to the remote invocation of - Git, which is not a good idea at all. Explicitly clear them just - like we do for the local transport. - - * Correct "git p4 --detect-labels" so that it does not fail to create - a tag that points at a commit that is also being imported. - - * The Makefile always runs the library archiver with hardcoded "crs" - options, which was inconvenient for exotic platforms on which - people want to use programs with totally different set of command - line options. - - * Customization to change the behaviour with "make -w" and "make -s" - in our Makefile was broken when they were used together. - - * Allocation related functions and stdio are unsafe things to call - inside a signal handler, and indeed killing the pager can cause - glibc to deadlock waiting on allocation mutex as our signal handler - tries to free() some data structures in wait_for_pager(). Reduce - these unsafe calls. - - * The way how --ref/--notes to specify the notes tree reference are - DWIMmed was not clearly documented. - - * "git gc" used to barf when a symbolic ref has gone dangling - (e.g. the branch that used to be your upstream's default when you - cloned from it is now gone, and you did "fetch --prune"). - - * "git clone --dissociate" runs a big "git repack" process at the - end, and it helps to close file descriptors that are open on the - packs and their idx files before doing so on filesystems that - cannot remove a file that is still open. - - * Description of the "log.follow" configuration variable in "git log" - documentation is now also copied to "git config" documentation. - - * "git rebase -i" had a minor regression recently, which stopped - considering a line that begins with an indented '#' in its insn - sheet not a comment. Further, the code was still too picky on - Windows where CRLF left by the editor is turned into a trailing CR - on the line read via the "read" built-in command of bash. Both of - these issues are now fixed. - - * After "git checkout --detach", "git status" reported a fairly - useless "HEAD detached at HEAD", instead of saying at which exact - commit. - - * When "git send-email" wanted to talk over Net::SMTP::SSL, - Net::Cmd::datasend() did not like to be fed too many bytes at the - same time and failed to send messages. Send the payload one line - at a time to work around the problem. - - * When "git am" was rewritten as a built-in, it stopped paying - attention to user.signingkey, which was fixed. - - * It was not possible to use a repository-lookalike created by "git - worktree add" as a local source of "git clone". - - * On a case insensitive filesystems, setting GIT_WORK_TREE variable - using a random cases that does not agree with what the filesystem - thinks confused Git that it wasn't inside the working tree. - - * Performance-measurement tests did not work without an installed Git. - - * A test script for the HTTP service had a timing dependent bug, - which was fixed. - - * There were some classes of errors that "git fsck" diagnosed to its - standard error that did not cause it to exit with non-zero status. - - * Work around "git p4" failing when the P4 depot records the contents - in UTF-16 without UTF-16 BOM. - - * When "git gc --auto" is backgrounded, its diagnosis message is - lost. Save it to a file in $GIT_DIR and show it next time the "gc - --auto" is run. - - * The submodule code has been taught to work better with separate - work trees created via "git worktree add". - - * "git gc" is safe to run anytime only because it has the built-in - grace period to protect young objects. In order to run with no - grace period, the user must make sure that the repository is - quiescent. - - * A recent "filter-branch --msg-filter" broke skipping of the commit - object header, which is fixed. - - * The normalize_ceiling_entry() function does not muck with the end - of the path it accepts, and the real world callers do rely on that, - but a test insisted that the function drops a trailing slash. - - * A test for interaction between untracked cache and sparse checkout - added in Git 2.5 days were flaky. - - * A couple of commands still showed "[options]" in their usage string - to note where options should come on their command line, but we - spell that "[<options>]" in most places these days. - - * The synopsis text and the usage string of subcommands that read - list of things from the standard input are often shown as if they - only take input from a file on a filesystem, which was misleading. - - * "git am -3" had a small regression where it is aborted in its error - handling codepath when underlying merge-recursive failed in certain - ways, as it assumed that the internal call to merge-recursive will - never die, which is not the case (yet). - - * The linkage order of libraries was wrong in places around libcurl. - - * The name-hash subsystem that is used to cope with case insensitive - filesystems keeps track of directories and their on-filesystem - cases for all the paths in the index by holding a pointer to a - randomly chosen cache entry that is inside the directory (for its - ce->ce_name component). This pointer was not updated even when the - cache entry was removed from the index, leading to use after free. - This was fixed by recording the path for each directory instead of - borrowing cache entries and restructuring the API somewhat. - - * "git merge-file" tried to signal how many conflicts it found, which - obviously would not work well when there are too many of them. - - * The error message from "git blame --contents --reverse" incorrectly - talked about "--contents --children". - - * "git imap-send" did not compile well with older version of cURL library. - - * Merging a branch that removes a path and another that changes the - mode bits on the same path should have conflicted at the path, but - it didn't and silently favoured the removal. - - * "git --literal-pathspecs add -u/-A" without any command line - argument misbehaved ever since Git 2.0. - - * "git daemon" uses "run_command()" without "finish_command()", so it - needs to release resources itself, which it forgot to do. - - * "git status --branch --short" accessed beyond the constant string - "HEAD", which has been corrected. - - * We peek objects from submodule's object store by linking it to the - list of alternate object databases, but the code to do so forgot to - correctly initialize the list. - - * The code to prepare the working tree side of temporary directory - for the "dir-diff" feature forgot that symbolic links need not be - copied (or symlinked) to the temporary area, as the code already - special cases and overwrites them. Besides, it was wrong to try - computing the object name of the target of symbolic link, which may - not even exist or may be a directory. - - * A Range: request can be responded with a full response and when - asked properly libcurl knows how to strip the result down to the - requested range. However, we were hand-crafting a range request - and it did not kick in. - - * Having a leftover .idx file without corresponding .pack file in - the repository hurts performance; "git gc" learned to prune them. - - * Apple's common crypto implementation of SHA1_Update() does not take - more than 4GB at a time, and we now have a compile-time workaround - for it. - - * Produce correct "dirty" marker for shell prompts, even when we - are on an orphan or an unborn branch. - - * A build without NO_IPv6 used to use gethostbyname() when guessing - user's hostname, instead of getaddrinfo() that is used in other - codepaths in such a build. - - * The exit code of git-fsck did not reflect some types of errors - found in packed objects, which has been corrected. - - * The helper used to iterate over loose object directories to prune - stale objects did not closedir() immediately when it is done with a - directory--a callback such as the one used for "git prune" may want - to do rmdir(), but it would fail on open directory on platforms - such as WinXP. - - * "git p4" used to import Perforce CLs that touch only paths outside - the client spec as empty commits. It has been corrected to ignore - them instead, with a new configuration git-p4.keepEmptyCommits as a - backward compatibility knob. - - * The completion script (in contrib/) used to list "git column" - (which is not an end-user facing command) as one of the choices - (merge 160fcdb sg/completion-no-column later to maint). - - * The error reporting from "git send-email", when SMTP TLS fails, has - been improved. - (merge 9d60524 jk/send-email-ssl-errors later to maint). - - * When getpwuid() on the system returned NULL (e.g. the user is not - in the /etc/passwd file or other uid-to-name mappings), the - codepath to find who the user is to record it in the reflog barfed - and died. Loosen the check in this codepath, which already accepts - questionable ident string (e.g. host part of the e-mail address is - obviously bogus), and in general when we operate fmt_ident() function - in non-strict mode. - (merge 92bcbb9 jk/ident-loosen-getpwuid later to maint). - - * "git symbolic-ref" forgot to report a failure with its exit status. - (merge f91b273 jk/symbolic-ref-maint later to maint). - - * History traversal with "git log --source" that starts with an - annotated tag failed to report the tag as "source", due to an - old regression in the command line parser back in v2.2 days. - (merge 728350b jk/pending-keep-tag-name later to maint). - - * "git p4" when interacting with multiple depots at the same time - used to incorrectly drop changes. - - * Code clean-up, minor fixes etc. diff --git a/third_party/git/Documentation/RelNotes/2.7.1.txt b/third_party/git/Documentation/RelNotes/2.7.1.txt deleted file mode 100644 index 6553d69e33..0000000000 --- a/third_party/git/Documentation/RelNotes/2.7.1.txt +++ /dev/null @@ -1,87 +0,0 @@ -Git v2.7.1 Release Notes -======================== - -Fixes since v2.7 ----------------- - - * An earlier change in 2.5.x-era broke users' hooks and aliases by - exporting GIT_WORK_TREE to point at the root of the working tree, - interfering when they tried to use a different working tree without - setting GIT_WORK_TREE environment themselves. - - * The "exclude_list" structure has the usual "alloc, nr" pair of - fields to be used by ALLOC_GROW(), but clear_exclude_list() forgot - to reset 'alloc' to 0 when it cleared 'nr' to discard the managed - array. - - * "git send-email" was confused by escaped quotes stored in the alias - files saved by "mutt", which has been corrected. - - * A few unportable C construct have been spotted by clang compiler - and have been fixed. - - * The documentation has been updated to hint the connection between - the '--signoff' option and DCO. - - * "git reflog" incorrectly assumed that all objects that used to be - at the tip of a ref must be commits, which caused it to segfault. - - * The ignore mechanism saw a few regressions around untracked file - listing and sparse checkout selection areas in 2.7.0; the change - that is responsible for the regression has been reverted. - - * Some codepaths used fopen(3) when opening a fixed path in $GIT_DIR - (e.g. COMMIT_EDITMSG) that is meant to be left after the command is - done. This however did not work well if the repository is set to - be shared with core.sharedRepository and the umask of the previous - user is tighter. They have been made to work better by calling - unlink(2) and retrying after fopen(3) fails with EPERM. - - * Asking gitweb for a nonexistent commit left a warning in the server - log. - - * "git rebase", unlike all other callers of "gc --auto", did not - ignore the exit code from "gc --auto". - - * Many codepaths that run "gc --auto" before exiting kept packfiles - mapped and left the file descriptors to them open, which was not - friendly to systems that cannot remove files that are open. They - now close the packs before doing so. - - * A recent optimization to filter-branch in v2.7.0 introduced a - regression when --prune-empty filter is used, which has been - corrected. - - * The description for SANITY prerequisite the test suite uses has - been clarified both in the comment and in the implementation. - - * "git tag" started listing a tag "foo" as "tags/foo" when a branch - named "foo" exists in the same repository; remove this unnecessary - disambiguation, which is a regression introduced in v2.7.0. - - * The way "git svn" uses auth parameter was broken by Subversion - 1.9.0 and later. - - * The "split" subcommand of "git subtree" (in contrib/) incorrectly - skipped merges when it shouldn't, which was corrected. - - * A few options of "git diff" did not work well when the command was - run from a subdirectory. - - * dirname() emulation has been added, as Msys2 lacks it. - - * The underlying machinery used by "ls-files -o" and other commands - have been taught not to create empty submodule ref cache for a - directory that is not a submodule. This removes a ton of wasted - CPU cycles. - - * Drop a few old "todo" items by deciding that the change one of them - suggests is not such a good idea, and doing the change the other - one suggested to do. - - * Documentation for "git fetch --depth" has been updated for clarity. - - * The command line completion learned a handful of additional options - and command specific syntax. - -Also includes a handful of documentation and test updates. diff --git a/third_party/git/Documentation/RelNotes/2.7.2.txt b/third_party/git/Documentation/RelNotes/2.7.2.txt deleted file mode 100644 index 4feef76704..0000000000 --- a/third_party/git/Documentation/RelNotes/2.7.2.txt +++ /dev/null @@ -1,41 +0,0 @@ -Git v2.7.2 Release Notes -======================== - -Fixes since v2.7.1 ------------------- - - * The low-level merge machinery has been taught to use CRLF line - termination when inserting conflict markers to merged contents that - are themselves CRLF line-terminated. - - * "git worktree" had a broken code that attempted to auto-fix - possible inconsistency that results from end-users moving a - worktree to different places without telling Git (the original - repository needs to maintain backpointers to its worktrees, but - "mv" run by end-users who are not familiar with that fact will - obviously not adjust them), which actually made things worse - when triggered. - - * "git push --force-with-lease" has been taught to report if the push - needed to force (or fast-forwarded). - - * The emulated "yes" command used in our test scripts has been - tweaked not to spend too much time generating unnecessary output - that is not used, to help those who test on Windows where it would - not stop until it fills the pipe buffer due to lack of SIGPIPE. - - * The vimdiff backend for "git mergetool" has been tweaked to arrange - and number buffers in the order that would match the expectation of - majority of people who read left to right, then top down and assign - buffers 1 2 3 4 "mentally" to local base remote merge windows based - on that order. - - * The documentation for "git clean" has been corrected; it mentioned - that .git/modules/* are removed by giving two "-f", which has never - been the case. - - * Paths that have been told the index about with "add -N" are not - quite yet in the index, but a few commands behaved as if they - already are in a harmful way. - -Also includes tiny documentation and test updates. diff --git a/third_party/git/Documentation/RelNotes/2.7.3.txt b/third_party/git/Documentation/RelNotes/2.7.3.txt deleted file mode 100644 index 6adf038915..0000000000 --- a/third_party/git/Documentation/RelNotes/2.7.3.txt +++ /dev/null @@ -1,62 +0,0 @@ -Git v2.7.3 Release Notes -======================== - -Fixes since v2.7.2 ------------------- - - * Traditionally, the tests that try commands that work on the - contents in the working tree were named with "worktree" in their - filenames, but with the recent addition of "git worktree" - subcommand, whose tests are also named similarly, it has become - harder to tell them apart. The traditional tests have been renamed - to use "work-tree" instead in an attempt to differentiate them. - - * Many codepaths forget to check return value from git_config_set(); - the function is made to die() to make sure we do not proceed when - setting a configuration variable failed. - - * Handling of errors while writing into our internal asynchronous - process has been made more robust, which reduces flakiness in our - tests. - - * "git show 'HEAD:Foo[BAR]Baz'" did not interpret the argument as a - rev, i.e. the object named by the the pathname with wildcard - characters in a tree object. - - * "git rev-parse --git-common-dir" used in the worktree feature - misbehaved when run from a subdirectory. - - * The "v(iew)" subcommand of the interactive "git am -i" command was - broken in 2.6.0 timeframe when the command was rewritten in C. - - * "git merge-tree" used to mishandle "both sides added" conflict with - its own "create a fake ancestor file that has the common parts of - what both sides have added and do a 3-way merge" logic; this has - been updated to use the usual "3-way merge with an empty blob as - the fake common ancestor file" approach used in the rest of the - system. - - * The memory ownership rule of fill_textconv() API, which was a bit - tricky, has been documented a bit better. - - * The documentation did not clearly state that the 'simple' mode is - now the default for "git push" when push.default configuration is - not set. - - * Recent versions of GNU grep are pickier when their input contains - arbitrary binary data, which some of our tests uses. Rewrite the - tests to sidestep the problem. - - * A helper function "git submodule" uses since v2.7.0 to list the - modules that match the pathspec argument given to its subcommands - (e.g. "submodule add <repo> <path>") has been fixed. - - * "git config section.var value" to set a value in per-repository - configuration file failed when it was run outside any repository, - but didn't say the reason correctly. - - * The code to read the pack data using the offsets stored in the pack - idx file has been made more carefully check the validity of the - data in the idx. - -Also includes documentation and test updates. diff --git a/third_party/git/Documentation/RelNotes/2.7.4.txt b/third_party/git/Documentation/RelNotes/2.7.4.txt deleted file mode 100644 index 883ae896fe..0000000000 --- a/third_party/git/Documentation/RelNotes/2.7.4.txt +++ /dev/null @@ -1,11 +0,0 @@ -Git v2.7.4 Release Notes -======================== - -Fixes since v2.7.3 ------------------- - - * Bugfix patches were backported from the 'master' front to plug heap - corruption holes, to catch integer overflow in the computation of - pathname lengths, and to get rid of the name_path API. Both of - these would have resulted in writing over an under-allocated buffer - when formulating pathnames while tree traversal. diff --git a/third_party/git/Documentation/RelNotes/2.7.5.txt b/third_party/git/Documentation/RelNotes/2.7.5.txt deleted file mode 100644 index 83559ce3b2..0000000000 --- a/third_party/git/Documentation/RelNotes/2.7.5.txt +++ /dev/null @@ -1,14 +0,0 @@ -Git v2.7.5 Release Notes -======================== - -Fixes since v2.7.4 ------------------- - - * "git-shell" rejects a request to serve a repository whose name - begins with a dash, which makes it no longer possible to get it - confused into spawning service programs like "git-upload-pack" with - an option like "--help", which in turn would spawn an interactive - pager, instead of working with the repository user asked to access - (i.e. the one whose name is "--help"). - -Also contains a few fixes backported from later development tracks. diff --git a/third_party/git/Documentation/RelNotes/2.7.6.txt b/third_party/git/Documentation/RelNotes/2.7.6.txt deleted file mode 100644 index 4c6d1dcd4a..0000000000 --- a/third_party/git/Documentation/RelNotes/2.7.6.txt +++ /dev/null @@ -1,25 +0,0 @@ -Git v2.7.6 Release Notes -======================== - -Fixes since v2.7.5 ------------------- - - * A "ssh://..." URL can result in a "ssh" command line with a - hostname that begins with a dash "-", which would cause the "ssh" - command to instead (mis)treat it as an option. This is now - prevented by forbidding such a hostname (which will not be - necessary in the real world). - - * Similarly, when GIT_PROXY_COMMAND is configured, the command is - run with host and port that are parsed out from "ssh://..." URL; - a poorly written GIT_PROXY_COMMAND could be tricked into treating - a string that begins with a dash "-". This is now prevented by - forbidding such a hostname and port number (again, which will not - be necessary in the real world). - - * In the same spirit, a repository name that begins with a dash "-" - is also forbidden now. - -Credits go to Brian Neel at GitLab, Joern Schneeweisz of Recurity -Labs and Jeff King at GitHub. - diff --git a/third_party/git/Documentation/RelNotes/2.8.0.txt b/third_party/git/Documentation/RelNotes/2.8.0.txt deleted file mode 100644 index 25079710fa..0000000000 --- a/third_party/git/Documentation/RelNotes/2.8.0.txt +++ /dev/null @@ -1,439 +0,0 @@ -Git 2.8 Release Notes -===================== - -Backward compatibility note ---------------------------- - -The rsync:// transport has been removed. - - -Updates since v2.7 ------------------- - -UI, Workflows & Features - - * It turns out "git clone" over rsync transport has been broken when - the source repository has packed references for a long time, and - nobody noticed nor complained about it. - - * "push" learned that its "--delete" option can be shortened to - "-d", just like "branch --delete" and "branch -d" are the same - thing. - - * "git blame" learned to produce the progress eye-candy when it takes - too much time before emitting the first line of the result. - - * "git grep" can now be configured (or told from the command line) - how many threads to use when searching in the working tree files. - - * Some "git notes" operations, e.g. "git log --notes=<note>", should - be able to read notes from any tree-ish that is shaped like a notes - tree, but the notes infrastructure required that the argument must - be a ref under refs/notes/. Loosen it to require a valid ref only - when the operation would update the notes (in which case we must - have a place to store the updated notes tree, iow, a ref). - - * "git grep" by default does not fall back to its "--no-index" - behavior outside a directory under Git's control (otherwise the - user may by mistake end up running a huge recursive search); with a - new configuration (set in $HOME/.gitconfig--by definition this - cannot be set in the config file per project), this safety can be - disabled. - - * "git pull --rebase" has been extended to allow invoking - "rebase -i". - - * "git p4" learned to cope with the type of a file getting changed. - - * "git format-patch" learned to notice format.outputDirectory - configuration variable. This allows "-o <dir>" option to be - omitted on the command line if you always use the same directory in - your workflow. - - * "interpret-trailers" has been taught to optionally update a file in - place, instead of always writing the result to the standard output. - - * Many commands that read files that are expected to contain text - that is generated (or can be edited) by the end user to control - their behavior (e.g. "git grep -f <filename>") have been updated - to be more tolerant to lines that are terminated with CRLF (they - used to treat such a line to contain payload that ends with CR, - which is usually not what the users expect). - - * "git notes merge" used to limit the source of the merged notes tree - to somewhere under refs/notes/ hierarchy, which was too limiting - when inventing a workflow to exchange notes with remote - repositories using remote-tracking notes trees (located in e.g. - refs/remote-notes/ or somesuch). - - * "git ls-files" learned a new "--eol" option to help diagnose - end-of-line problems. - - * "ls-remote" learned an option to show which branch the remote - repository advertises as its primary by pointing its HEAD at. - - * New http.proxyAuthMethod configuration variable can be used to - specify what authentication method to use, as a way to work around - proxies that do not give error response expected by libcurl when - CURLAUTH_ANY is used. Also, the codepath for proxy authentication - has been taught to use credential API to store the authentication - material in user's keyrings. - - * Update the untracked cache subsystem and change its primary UI from - "git update-index" to "git config". - - * There were a few "now I am doing this thing" progress messages in - the TCP connection code that can be triggered by setting a verbose - option internally in the code, but "git fetch -v" and friends never - passed the verbose option down to that codepath. - - * Clean/smudge filters defined in a configuration file of lower - precedence can now be overridden to be a pass-through no-op by - setting the variable to an empty string. - - * A new "<branch>^{/!-<pattern>}" notation can be used to name a - commit that is reachable from <branch> that does not match the - given <pattern>. - - * The "user.useConfigOnly" configuration variable can be used to - force the user to always set user.email & user.name configuration - variables, serving as a reminder for those who work on multiple - projects and do not want to put these in their $HOME/.gitconfig. - - * "git fetch" and friends that make network connections can now be - told to only use ipv4 (or ipv6). - - * Some authentication methods do not need username or password, but - libcurl needs some hint that it needs to perform authentication. - Supplying an empty username and password string is a valid way to - do so, but you can set the http.[<url>.]emptyAuth configuration - variable to achieve the same, if you find it cleaner. - - * You can now set http.[<url>.]pinnedpubkey to specify the pinned - public key when building with recent enough versions of libcURL. - - * The configuration system has been taught to phrase where it found a - bad configuration variable in a better way in its error messages. - "git config" learnt a new "--show-origin" option to indicate where - the values come from. - - * The "credential-cache" daemon process used to run in whatever - directory it happened to start in, but this made umount(2)ing the - filesystem that houses the repository harder; now the process - chdir()s to the directory that house its own socket on startup. - - * When "git submodule update" did not result in fetching the commit - object in the submodule that is referenced by the superproject, the - command learned to retry another fetch, specifically asking for - that commit that may not be connected to the refs it usually - fetches. - - * "git merge-recursive" learned "--no-renames" option to disable its - rename detection logic. - - * Across the transition at around Git version 2.0, the user used to - get a pretty loud warning when running "git push" without setting - push.default configuration variable. We no longer warn because the - transition was completed a long time ago. - - * README has been renamed to README.md and its contents got tweaked - slightly to make it easier on the eyes. - - -Performance, Internal Implementation, Development Support etc. - - * Add a framework to spawn a group of processes in parallel, and use - it to run "git fetch --recurse-submodules" in parallel. - - * A slight update to the Makefile to mark ".PHONY" targets as such - correctly. - - * In-core storage of the reverse index for .pack files (which lets - you go from a pack offset to an object name) has been streamlined. - - * d95138e6 (setup: set env $GIT_WORK_TREE when work tree is set, like - $GIT_DIR, 2015-06-26) attempted to work around a glitch in alias - handling by overwriting GIT_WORK_TREE environment variable to - affect subprocesses when set_git_work_tree() gets called, which - resulted in a rather unpleasant regression to "clone" and "init". - Try to address the same issue by always restoring the environment - and respawning the real underlying command when handling alias. - - * The low-level code that is used to create symbolic references has - been updated to share more code with the code that deals with - normal references. - - * strbuf_getline() and friends have been redefined to make it easier - to identify which callsite of (new) strbuf_getline_lf() should - allow and silently ignore carriage-return at the end of the line to - help users on DOSsy systems. - - * "git shortlog" used to accumulate various pieces of information - regardless of what was asked to be shown in the final output. It - has been optimized by noticing what need not to be collected - (e.g. there is no need to collect the log messages when showing - only the number of changes). - - * "git checkout $branch" (and other operations that share the same - underlying machinery) has been optimized. - - * Automated tests in Travis CI environment has been optimized by - persisting runtime statistics of previous "prove" run, executing - tests that take longer before other ones; this reduces the total - wallclock time. - - * Test scripts have been updated to remove assumptions that are not - portable between Git for POSIX and Git for Windows, or to skip ones - with expectations that are not satisfiable on Git for Windows. - - * Some calls to strcpy(3) triggers a false warning from static - analyzers that are less intelligent than humans, and reducing the - number of these false hits helps us notice real issues. A few - calls to strcpy(3) in a couple of protrams that are already safe - has been rewritten to avoid false warnings. - - * The "name_path" API was an attempt to reduce the need to construct - the full path out of a series of path components while walking a - tree hierarchy, but over time made less efficient because the path - needs to be flattened, e.g. to be compared with another path that - is already flat. The API has been removed and its users have been - rewritten to simplify the overall code complexity. - - * Help those who debug http(s) part of the system. - (merge 0054045 sp/remote-curl-ssl-strerror later to maint). - - * The internal API to interact with "remote.*" configuration - variables has been streamlined. - - * The ref-filter's format-parsing code has been refactored, in - preparation for "branch --format" and friends. - - * Traditionally, the tests that try commands that work on the - contents in the working tree were named with "worktree" in their - filenames, but with the recent addition of "git worktree" - subcommand, whose tests are also named similarly, it has become - harder to tell them apart. The traditional tests have been renamed - to use "work-tree" instead in an attempt to differentiate them. - (merge 5549029 mg/work-tree-tests later to maint). - - * Many codepaths forget to check return value from git_config_set(); - the function is made to die() to make sure we do not proceed when - setting a configuration variable failed. - (merge 3d18064 ps/config-error later to maint). - - * Handling of errors while writing into our internal asynchronous - process has been made more robust, which reduces flakiness in our - tests. - (merge 43f3afc jk/epipe-in-async later to maint). - - * There is a new DEVELOPER knob that enables many compiler warning - options in the Makefile. - - * The way the test scripts configure the Apache web server has been - updated to work also for Apache 2.4 running on RedHat derived - distros. - - * Out of maintenance gcc on OSX 10.6 fails to compile the code in - 'master'; work it around by using clang by default on the platform. - - * The "name_path" API was an attempt to reduce the need to construct - the full path out of a series of path components while walking a - tree hierarchy, but over time made less efficient because the path - needs to be flattened, e.g. to be compared with another path that - is already flat, in many cases. The API has been removed and its - users have been rewritten to simplify the overall code complexity. - This incidentally also closes some heap-corruption holes. - - * Recent versions of GNU grep is pickier than before to decide if a - file is "binary" and refuse to give line-oriented hits when we - expect it to, unless explicitly told with "-a" option. As our - scripted Porcelains use sane_grep wrapper for line-oriented data, - even when the line may contain non-ASCII payload we took from - end-user data, use "grep -a" to implement sane_grep wrapper when - using an implementation of "grep" that takes the "-a" option. - - - -Also contains various documentation updates and code clean-ups. - - -Fixes since v2.7 ----------------- - -Unless otherwise noted, all the fixes since v2.7 in the maintenance -track are contained in this release (see the maintenance releases' -notes for details). - - * An earlier change in 2.5.x-era broke users' hooks and aliases by - exporting GIT_WORK_TREE to point at the root of the working tree, - interfering when they tried to use a different working tree without - setting GIT_WORK_TREE environment themselves. - - * The "exclude_list" structure has the usual "alloc, nr" pair of - fields to be used by ALLOC_GROW(), but clear_exclude_list() forgot - to reset 'alloc' to 0 when it cleared 'nr' to discard the managed - array. - - * Paths that have been told the index about with "add -N" are not - quite yet in the index, but a few commands behaved as if they - already are in a harmful way. - - * "git send-email" was confused by escaped quotes stored in the alias - files saved by "mutt", which has been corrected. - - * A few non-portable C construct have been spotted by clang compiler - and have been fixed. - - * The documentation has been updated to hint the connection between - the '--signoff' option and DCO. - - * "git reflog" incorrectly assumed that all objects that used to be - at the tip of a ref must be commits, which caused it to segfault. - - * The ignore mechanism saw a few regressions around untracked file - listing and sparse checkout selection areas in 2.7.0; the change - that is responsible for the regression has been reverted. - - * Some codepaths used fopen(3) when opening a fixed path in $GIT_DIR - (e.g. COMMIT_EDITMSG) that is meant to be left after the command is - done. This however did not work well if the repository is set to - be shared with core.sharedRepository and the umask of the previous - user is tighter. They have been made to work better by calling - unlink(2) and retrying after fopen(3) fails with EPERM. - - * Asking gitweb for a nonexistent commit left a warning in the server - log. - - Somebody may want to follow this up with an additional test, perhaps? - IIRC, we do test that no Perl warnings are given to the server log, - so this should have been caught if our test coverage were good. - - * "git rebase", unlike all other callers of "gc --auto", did not - ignore the exit code from "gc --auto". - - * Many codepaths that run "gc --auto" before exiting kept packfiles - mapped and left the file descriptors to them open, which was not - friendly to systems that cannot remove files that are open. They - now close the packs before doing so. - - * A recent optimization to filter-branch in v2.7.0 introduced a - regression when --prune-empty filter is used, which has been - corrected. - - * The description for SANITY prerequisite the test suite uses has - been clarified both in the comment and in the implementation. - - * "git tag" started listing a tag "foo" as "tags/foo" when a branch - named "foo" exists in the same repository; remove this unnecessary - disambiguation, which is a regression introduced in v2.7.0. - - * The way "git svn" uses auth parameter was broken by Subversion - 1.9.0 and later. - - * The "split" subcommand of "git subtree" (in contrib/) incorrectly - skipped merges when it shouldn't, which was corrected. - - * A few options of "git diff" did not work well when the command was - run from a subdirectory. - - * The command line completion learned a handful of additional options - and command specific syntax. - - * dirname() emulation has been added, as Msys2 lacks it. - - * The underlying machinery used by "ls-files -o" and other commands - has been taught not to create empty submodule ref cache for a - directory that is not a submodule. This removes a ton of wasted - CPU cycles. - - * "git worktree" had a broken code that attempted to auto-fix - possible inconsistency that results from end-users moving a - worktree to different places without telling Git (the original - repository needs to maintain back-pointers to its worktrees, - but "mv" run by end-users who are not familiar with that fact - will obviously not adjust them), which actually made things - worse when triggered. - - * The low-level merge machinery has been taught to use CRLF line - termination when inserting conflict markers to merged contents that - are themselves CRLF line-terminated. - - * "git push --force-with-lease" has been taught to report if the push - needed to force (or fast-forwarded). - - * The emulated "yes" command used in our test scripts has been - tweaked not to spend too much time generating unnecessary output - that is not used, to help those who test on Windows where it would - not stop until it fills the pipe buffer due to lack of SIGPIPE. - - * The documentation for "git clean" has been corrected; it mentioned - that .git/modules/* are removed by giving two "-f", which has never - been the case. - - * The vimdiff backend for "git mergetool" has been tweaked to arrange - and number buffers in the order that would match the expectation of - majority of people who read left to right, then top down and assign - buffers 1 2 3 4 "mentally" to local base remote merge windows based - on that order. - - * "git show 'HEAD:Foo[BAR]Baz'" did not interpret the argument as a - rev, i.e. the object named by the the pathname with wildcard - characters in a tree object. - (merge aac4fac nd/dwim-wildcards-as-pathspecs later to maint). - - * "git rev-parse --git-common-dir" used in the worktree feature - misbehaved when run from a subdirectory. - (merge 17f1365 nd/git-common-dir-fix later to maint). - - * "git worktree add -B <branchname>" did not work. - - * The "v(iew)" subcommand of the interactive "git am -i" command was - broken in 2.6.0 timeframe when the command was rewritten in C. - (merge 708b8cc jc/am-i-v-fix later to maint). - - * "git merge-tree" used to mishandle "both sides added" conflict with - its own "create a fake ancestor file that has the common parts of - what both sides have added and do a 3-way merge" logic; this has - been updated to use the usual "3-way merge with an empty blob as - the fake common ancestor file" approach used in the rest of the - system. - (merge 907681e jk/no-diff-emit-common later to maint). - - * The memory ownership rule of fill_textconv() API, which was a bit - tricky, has been documented a bit better. - (merge a64e6a4 jk/more-comments-on-textconv later to maint). - - * Update various codepaths to avoid manually-counted malloc(). - (merge 08c95df jk/tighten-alloc later to maint). - - * The documentation did not clearly state that the 'simple' mode is - now the default for "git push" when push.default configuration is - not set. - (merge f6b1fb3 mm/push-simple-doc later to maint). - - * Recent versions of GNU grep are pickier when their input contains - arbitrary binary data, which some of our tests uses. Rewrite the - tests to sidestep the problem. - (merge 3b1442d jk/grep-binary-workaround-in-test later to maint). - - * A helper function "git submodule" uses since v2.7.0 to list the - modules that match the pathspec argument given to its subcommands - (e.g. "submodule add <repo> <path>") has been fixed. - (merge 2b56bb7 sb/submodule-module-list-fix later to maint). - - * "git config section.var value" to set a value in per-repository - configuration file failed when it was run outside any repository, - but didn't say the reason correctly. - (merge 638fa62 js/config-set-in-non-repository later to maint). - - * The code to read the pack data using the offsets stored in the pack - idx file has been made more carefully check the validity of the - data in the idx. - (merge 7465feb jk/pack-idx-corruption-safety later to maint). - - * Other minor clean-ups and documentation updates - (merge f459823 ak/extract-argv0-last-dir-sep later to maint). - (merge 63ca1c0 ak/git-strip-extension-from-dashed-command later to maint). - (merge 4867f11 ps/plug-xdl-merge-leak later to maint). - (merge 4938686 dt/initial-ref-xn-commit-doc later to maint). - (merge 9537f21 ma/update-hooks-sample-typofix later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.8.1.txt b/third_party/git/Documentation/RelNotes/2.8.1.txt deleted file mode 100644 index ef6d80b008..0000000000 --- a/third_party/git/Documentation/RelNotes/2.8.1.txt +++ /dev/null @@ -1,9 +0,0 @@ -Git v2.8.1 Release Notes -======================== - -Fixes since v2.8 ----------------- - - * "make rpmbuild" target was broken as its input, git.spec.in, was - not updated to match a file it describes that has been renamed - recently. This has been fixed. diff --git a/third_party/git/Documentation/RelNotes/2.8.2.txt b/third_party/git/Documentation/RelNotes/2.8.2.txt deleted file mode 100644 index 447b1933a8..0000000000 --- a/third_party/git/Documentation/RelNotes/2.8.2.txt +++ /dev/null @@ -1,70 +0,0 @@ -Git v2.8.2 Release Notes -======================== - -Fixes since v2.8.1 ------------------- - - * The embedded args argv-array in the child process is used to build - the command line to run pack-objects instead of using a separate - array of strings. - - * Bunch of tests on "git clone" has been renumbered for better - organization. - - * The tests that involve running httpd leaked the system-wide - configuration in /etc/gitconfig to the tested environment. - - * "index-pack --keep=<msg>" was broken since v2.1.0 timeframe. - - * "git config --get-urlmatch", unlike other variants of the "git - config --get" family, did not signal error with its exit status - when there was no matching configuration. - - * The "--local-env-vars" and "--resolve-git-dir" options of "git - rev-parse" failed to work outside a repository when the command's - option parsing was rewritten in 1.8.5 era. - - * Fetching of history by naming a commit object name directly didn't - work across remote-curl transport. - - * A small memory leak in an error codepath has been plugged in xdiff - code. - - * strbuf_getwholeline() did not NUL-terminate the buffer on certain - corner cases in its error codepath. - - * The startup_info data, which records if we are working inside a - repository (among other things), are now uniformly available to Git - subcommand implementations, and Git avoids attempting to touch - references when we are not in a repository. - - * "git mergetool" did not work well with conflicts that both sides - deleted. - - * "git send-email" had trouble parsing alias file in mailrc format - when lines in it had trailing whitespaces on them. - - * When "git merge --squash" stopped due to conflict, the concluding - "git commit" failed to read in the SQUASH_MSG that shows the log - messages from all the squashed commits. - - * "git merge FETCH_HEAD" dereferenced NULL pointer when merging - nothing into an unborn history (which is arguably unusual usage, - which perhaps was the reason why nobody noticed it). - - * Build updates for MSVC. - - * "git diff -M" used to work better when two originally identical - files A and B got renamed to X/A and X/B by pairing A to X/A and B - to X/B, but this was broken in the 2.0 timeframe. - - * "git send-pack --all <there>" was broken when its command line - option parsing was written in the 2.6 timeframe. - - * When running "git blame $path" with unnormalized data in the index - for the path, the data in the working tree was blamed, even though - "git add" would not have changed what is already in the index, due - to "safe crlf" that disables the line-end conversion. It has been - corrected. - -Also contains minor documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.8.3.txt b/third_party/git/Documentation/RelNotes/2.8.3.txt deleted file mode 100644 index fedd9968e5..0000000000 --- a/third_party/git/Documentation/RelNotes/2.8.3.txt +++ /dev/null @@ -1,101 +0,0 @@ -Git v2.8.3 Release Notes -======================== - -Fixes since v2.8.2 ------------------- - - * "git send-email" now uses a more readable timestamps when - formulating a message ID. - - * The repository set-up sequence has been streamlined (the biggest - change is that there is no longer git_config_early()), so that we - do not attempt to look into refs/* when we know we do not have a - Git repository. - - * When "git worktree" feature is in use, "git branch -d" allowed - deletion of a branch that is checked out in another worktree - - * When "git worktree" feature is in use, "git branch -m" renamed a - branch that is checked out in another worktree without adjusting - the HEAD symbolic ref for the worktree. - - * "git format-patch --help" showed `-s` and `--no-patch` as if these - are valid options to the command. We already hide `--patch` option - from the documentation, because format-patch is about showing the - diff, and the documentation now hides these options as well. - - * A change back in version 2.7 to "git branch" broke display of a - symbolic ref in a non-standard place in the refs/ hierarchy (we - expect symbolic refs to appear in refs/remotes/*/HEAD to point at - the primary branch the remote has, and as .git/HEAD to point at the - branch we locally checked out). - - * A partial rewrite of "git submodule" in the 2.7 timeframe changed - the way the gitdir: pointer in the submodules point at the real - repository location to use absolute paths by accident. This has - been corrected. - - * "git commit" misbehaved in a few minor ways when an empty message - is given via -m '', all of which has been corrected. - - * Support for CRAM-MD5 authentication method in "git imap-send" did - not work well. - - * The socks5:// proxy support added back in 2.6.4 days was not aware - that socks5h:// proxies behave differently. - - * "git config" had a codepath that tried to pass a NULL to - printf("%s"), which nobody seems to have noticed. - - * On Cygwin, object creation uses the "create a temporary and then - rename it to the final name" pattern, not "create a temporary, - hardlink it to the final name and then unlink the temporary" - pattern. - - This is necessary to use Git on Windows shared directories, and is - already enabled for the MinGW and plain Windows builds. It also - has been used in Cygwin packaged versions of Git for quite a while. - See http://thread.gmane.org/gmane.comp.version-control.git/291853 - and http://thread.gmane.org/gmane.comp.version-control.git/275680. - - * "git replace -e" did not honour "core.editor" configuration. - - * Upcoming OpenSSL 1.1.0 will break compilation b updating a few APIs - we use in imap-send, which has been adjusted for the change. - - * "git submodule" reports the paths of submodules the command - recurses into, but this was incorrect when the command was not run - from the root level of the superproject. - - * The test scripts for "git p4" (but not "git p4" implementation - itself) has been updated so that they would work even on a system - where the installed version of Python is python 3. - - * The "user.useConfigOnly" configuration variable makes it an error - if users do not explicitly set user.name and user.email. However, - its check was not done early enough and allowed another error to - trigger, reporting that the default value we guessed from the - system setting was unusable. This was a suboptimal end-user - experience as we want the users to set user.name/user.email without - relying on the auto-detection at all. - - * "git mv old new" did not adjust the path for a submodule that lives - as a subdirectory inside old/ directory correctly. - - * "git push" from a corrupt repository that attempts to push a large - number of refs deadlocked; the thread to relay rejection notices - for these ref updates blocked on writing them to the main thread, - after the main thread at the receiving end notices that the push - failed and decides not to read these notices and return a failure. - - * A question by "git send-email" to ask the identity of the sender - has been updated. - - * Recent update to Git LFS broke "git p4" by changing the output from - its "lfs pointer" subcommand. - - * Some multi-byte encoding can have a backslash byte as a later part - of one letter, which would confuse "highlight" filter used in - gitweb. - -Also contains minor documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.8.4.txt b/third_party/git/Documentation/RelNotes/2.8.4.txt deleted file mode 100644 index f4e2552836..0000000000 --- a/third_party/git/Documentation/RelNotes/2.8.4.txt +++ /dev/null @@ -1,69 +0,0 @@ -Git v2.8.4 Release Notes -======================== - -Fixes since v2.8.3 ------------------- - - * Documentation for "git merge --verify-signatures" has been updated - to clarify that the signature of only the commit at the tip is - verified. Also the phrasing used for signature and key validity is - adjusted to align with that used by OpenPGP. - - * On Windows, .git and optionally any files whose name starts with a - dot are now marked as hidden, with a core.hideDotFiles knob to - customize this behaviour. - - * Portability enhancement for "rebase -i" to help platforms whose - shell does not like "for i in <empty>" (which is not POSIX-kosher). - - * "git fsck" learned to catch NUL byte in a commit object as - potential error and warn. - - * CI test was taught to build documentation pages. - - * Many 'linkgit:<git documentation page>' references were broken, - which are all fixed with this. - - * "git describe --contains" often made a hard-to-justify choice of - tag to give name to a given commit, because it tried to come up - with a name with smallest number of hops from a tag, causing an old - commit whose close descendant that is recently tagged were not - described with respect to an old tag but with a newer tag. It did - not help that its computation of "hop" count was further tweaked to - penalize being on a side branch of a merge. The logic has been - updated to favor using the tag with the oldest tagger date, which - is a lot easier to explain to the end users: "We describe a commit - in terms of the (chronologically) oldest tag that contains the - commit." - - * Running tests with '-x' option to trace the individual command - executions is a useful way to debug test scripts, but some tests - that capture the standard error stream and check what the command - said can be broken with the trace output mixed in. When running - our tests under "bash", however, we can redirect the trace output - to another file descriptor to keep the standard error of programs - being tested intact. - - * "http.cookieFile" configuration variable clearly wants a pathname, - but we forgot to treat it as such by e.g. applying tilde expansion. - - * When de-initialising all submodules, "git submodule deinit" gave a - faulty recommendation to use "git submodule deinit .", which would - result in a strange error message in a pathological corner case. - This has been corrected to suggest "submodule deinit --all" instead. - - * Many commands normalize command line arguments from NFD to NFC - variant of UTF-8 on OSX, but commands in the "diff" family did - not, causing "git diff $path" to complain that no such path is - known to Git. They have been taught to do the normalization. - - * A couple of bugs around core.autocrlf have been fixed. - - * "git difftool" learned to handle unmerged paths correctly in - dir-diff mode. - - * The "are we talking with TTY, doing an interactive session?" - detection has been updated to work better for "Git for Windows". - - -Also contains other minor documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.8.5.txt b/third_party/git/Documentation/RelNotes/2.8.5.txt deleted file mode 100644 index 7bd179fa12..0000000000 --- a/third_party/git/Documentation/RelNotes/2.8.5.txt +++ /dev/null @@ -1,12 +0,0 @@ -Git v2.8.5 Release Notes -======================== - -Fixes since v2.8.4 ------------------- - - * "git-shell" rejects a request to serve a repository whose name - begins with a dash, which makes it no longer possible to get it - confused into spawning service programs like "git-upload-pack" with - an option like "--help", which in turn would spawn an interactive - pager, instead of working with the repository user asked to access - (i.e. the one whose name is "--help"). diff --git a/third_party/git/Documentation/RelNotes/2.8.6.txt b/third_party/git/Documentation/RelNotes/2.8.6.txt deleted file mode 100644 index d8db55d920..0000000000 --- a/third_party/git/Documentation/RelNotes/2.8.6.txt +++ /dev/null @@ -1,4 +0,0 @@ -Git v2.8.6 Release Notes -======================== - -This release forward-ports the fix for "ssh://..." URL from Git v2.7.6 diff --git a/third_party/git/Documentation/RelNotes/2.9.0.txt b/third_party/git/Documentation/RelNotes/2.9.0.txt deleted file mode 100644 index b61d36712f..0000000000 --- a/third_party/git/Documentation/RelNotes/2.9.0.txt +++ /dev/null @@ -1,512 +0,0 @@ -Git 2.9 Release Notes -===================== - -Backward compatibility notes ----------------------------- - -The end-user facing Porcelain level commands in the "git diff" and -"git log" family by default enable the rename detection; you can still -use "diff.renames" configuration variable to disable this. - -Merging two branches that have no common ancestor with "git merge" is -by default forbidden now to prevent creating such an unusual merge by -mistake. - -The output formats of "git log" that indents the commit log message by -4 spaces now expands HT in the log message by default. You can use -the "--no-expand-tabs" option to disable this. - -"git commit-tree" plumbing command required the user to always sign -its result when the user sets the commit.gpgsign configuration -variable, which was an ancient mistake, which this release corrects. -A script that drives commit-tree, if it relies on this mistake, now -needs to read commit.gpgsign and pass the -S option as necessary. - - -Updates since v2.8 ------------------- - -UI, Workflows & Features - - * Comes with git-multimail 1.3.1 (in contrib/). - - * The end-user facing commands like "git diff" and "git log" - now enable the rename detection by default. - - * The credential.helper configuration variable is cumulative and - there is no good way to override it from the command line. As - a special case, giving an empty string as its value now serves - as the signal to clear the values specified in various files. - - * A new "interactive.diffFilter" configuration can be used to - customize the diff shown in "git add -i" sessions. - - * "git p4" now allows P4 author names to be mapped to Git author - names. - - * "git rebase -x" can be used without passing "-i" option. - - * "git -c credential.<var>=<value> submodule" can now be used to - propagate configuration variables related to credential helper - down to the submodules. - - * "git tag" can create an annotated tag without explicitly given an - "-a" (or "-s") option (i.e. when a tag message is given). A new - configuration variable, tag.forceSignAnnotated, can be used to tell - the command to create signed tag in such a situation. - - * "git merge" used to allow merging two branches that have no common - base by default, which led to a brand new history of an existing - project created and then get pulled by an unsuspecting maintainer, - which allowed an unnecessary parallel history merged into the - existing project. The command has been taught not to allow this by - default, with an escape hatch "--allow-unrelated-histories" option - to be used in a rare event that merges histories of two projects - that started their lives independently. - - * "git pull" has been taught to pass the "--allow-unrelated-histories" - option to underlying "git merge". - - * "git apply -v" learned to report paths in the patch that were - skipped via --include/--exclude mechanism or being outside the - current working directory. - - * Shell completion (in contrib/) updates. - - * The commit object name reported when "rebase -i" stops has been - shortened. - - * "git worktree add" can be given "--no-checkout" option to only - create an empty worktree without checking out the files. - - * "git mergetools" learned to drive ExamDiff. - - * "git pull --rebase" learned "--[no-]autostash" option, so that - the rebase.autostash configuration variable set to true can be - overridden from the command line. - - * When "git log" shows the log message indented by 4-spaces, the - remainder of a line after a HT does not align in the way the author - originally intended. The command now expands tabs by default to help - such a case, and allows the users to override it with a new option, - "--no-expand-tabs". - - * "git send-email" now uses a more readable timestamps when - formulating a message ID. - - * "git rerere" can encounter two or more files with the same conflict - signature that have to be resolved in different ways, but there was - no way to record these separate resolutions. - - * "git p4" learned to record P4 jobs in Git commit that imports from - the history in Perforce. - - * "git describe --contains" often made a hard-to-justify choice of - tag to name a given commit, because it tried to come up - with a name with smallest number of hops from a tag, causing an old - commit whose close descendant that is recently tagged were not - described with respect to an old tag but with a newer tag. It did - not help that its computation of "hop" count was further tweaked to - penalize being on a side branch of a merge. The logic has been - updated to favor using the tag with the oldest tagger date, which - is a lot easier to explain to the end users: "We describe a commit - in terms of the (chronologically) oldest tag that contains the - commit." - - * "git clone" learned the "--shallow-submodules" option. - - * HTTP transport clients learned to throw extra HTTP headers at the - server, specified via http.extraHeader configuration variable. - - * The "--compaction-heuristic" option to "git diff" family of - commands enables a heuristic to make the patch output more readable - by using a blank line as a strong hint that the contents before and - after it belong to logically separate units. It is still - experimental. - - * A new configuration variable core.hooksPath allows customizing - where the hook directory is. - - * An earlier addition of "sanitize_submodule_env" with 14111fc4 (git: - submodule honor -c credential.* from command line, 2016-02-29) - turned out to be a convoluted no-op; implement what it wanted to do - correctly, and stop filtering settings given via "git -c var=val". - - * "git commit --dry-run" reported "No, no, you cannot commit." in one - case where "git commit" would have allowed you to commit, and this - improves it a little bit ("git commit --dry-run --short" still does - not give you the correct answer, for example). This is a stop-gap - measure in that "commit --short --dry-run" still gives an incorrect - result. - - * The experimental "multiple worktree" feature gains more safety to - forbid operations on a branch that is checked out or being actively - worked on elsewhere, by noticing that e.g. it is being rebased. - - * "git format-patch" learned a new "--base" option to record what - (public, well-known) commit the original series was built on in - its output. - - * "git commit" learned to pay attention to the "commit.verbose" - configuration variable and act as if the "--verbose" option - was given from the command line. - - * Updated documentation gives hints to GMail users with two-factor - auth enabled that they need app-specific-password when using - "git send-email". - - * The manpage output of our documentation did not render well in - terminal; typeset literals in bold by default to make them stand - out more. - - * The mark-up in the top-level README.md file has been updated to - typeset CLI command names differently from the body text. - - -Performance, Internal Implementation, Development Support etc. - - * The embedded args argv-array in the child process is used to build - the command line to run pack-objects instead of using a separate - array of strings. - - * A test for tags has been restructured so that more parts of it can - easily be run on a platform without a working GnuPG. - - * The startup_info data, which records if we are working inside a - repository (among other things), are now uniformly available to Git - subcommand implementations, and Git avoids attempting to touch - references when we are not in a repository. - - * The command line argument parser for "receive-pack" has been - rewritten to use parse-options. - - * A major part of "git submodule update" has been ported to C to take - advantage of the recently added framework to run download tasks in - parallel. Other updates to "git submodule" that move pieces of - logic to C continues. - - * Rename bunch of tests on "git clone" for better organization. - - * The tests that involve running httpd leaked the system-wide - configuration in /etc/gitconfig to the tested environment. - - * Build updates for MSVC. - - * The repository set-up sequence has been streamlined (the biggest - change is that there is no longer git_config_early()), so that we - do not attempt to look into refs/* when we know we do not have a - Git repository. - - * Code restructuring around the "refs" API to prepare for pluggable - refs backends. - - * Sources to many test helper binaries and the generated helpers - have been moved to t/helper/ subdirectory to reduce clutter at the - top level of the tree. - - * Unify internal logic between "git tag -v" and "git verify-tag" - commands by making one directly call into the other. - - * "merge-recursive" strategy incorrectly checked if a path that is - involved in its internal merge exists in the working tree. - - * The test scripts for "git p4" (but not "git p4" implementation - itself) has been updated so that they would work even on a system - where the installed version of Python is python 3. - - * As nobody maintains our in-tree git.spec.in and distros use their - own spec file, we stopped pretending that we support "make rpm". - - * Move from "unsigned char[20]" to "struct object_id" continues. - - * The code for warning_errno/die_errno has been refactored and a new - error_errno() reporting helper is introduced. - (merge 1da045f nd/error-errno later to maint). - - * Running tests with '-x' option to trace the individual command - executions is a useful way to debug test scripts, but some tests - that capture the standard error stream and check what the command - said can be broken with the trace output mixed in. When running - our tests under "bash", however, we can redirect the trace output - to another file descriptor to keep the standard error of programs - being tested intact. - - * t0040 had too many unnecessary repetitions in its test data. Teach - test-parse-options program so that a caller can tell what it - expects in its output, so that these repetitions can be cleaned up. - - * Add perf test for "rebase -i". - - * Common mistakes when writing gitlink: in our documentation are - found by "make check-docs". - - * t9xxx series has been updated primarily for readability, while - fixing small bugs in it. A few scripted Porcelain commands have - also been updated to fix possible bugs around their use of - "test -z" and "test -n". - - * CI test was taught to run git-svn tests. - - * "git cat-file --batch-all" has been sped up, by taking advantage - of the fact that it does not have to read a list of objects, in two - ways. - - * test updates to make it more readable and maintainable. - (merge e6273f4 es/t1500-modernize later to maint). - - * "make DEVELOPER=1" worked as expected; setting DEVELOPER=1 in - config.mak didn't. - (merge 51dd3e8 mm/makefile-developer-can-be-in-config-mak later to maint). - - * The way how "submodule--helper list" signals unmatch error to its - callers has been updated. - - * A bash-ism "local" has been removed from "git submodule" scripted - Porcelain. - - -Also contains various documentation updates and code clean-ups. - - -Fixes since v2.8 ----------------- - -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). - - * "git config --get-urlmatch", unlike other variants of the "git - config --get" family, did not signal error with its exit status - when there was no matching configuration. - - * The "--local-env-vars" and "--resolve-git-dir" options of "git - rev-parse" failed to work outside a repository when the command's - option parsing was rewritten in 1.8.5 era. - - * "git index-pack --keep[=<msg>] pack-$name.pack" simply did not work. - - * Fetching of history by naming a commit object name directly didn't - work across remote-curl transport. - - * A small memory leak in an error codepath has been plugged in xdiff - code. - - * strbuf_getwholeline() did not NUL-terminate the buffer on certain - corner cases in its error codepath. - - * "git mergetool" did not work well with conflicts that both sides - deleted. - - * "git send-email" had trouble parsing alias file in mailrc format - when lines in it had trailing whitespaces on them. - - * When "git merge --squash" stopped due to conflict, the concluding - "git commit" failed to read in the SQUASH_MSG that shows the log - messages from all the squashed commits. - - * "git merge FETCH_HEAD" dereferenced NULL pointer when merging - nothing into an unborn history (which is arguably unusual usage, - which perhaps was the reason why nobody noticed it). - - * When "git worktree" feature is in use, "git branch -d" allowed - deletion of a branch that is checked out in another worktree, - which was wrong. - - * When "git worktree" feature is in use, "git branch -m" renamed a - branch that is checked out in another worktree without adjusting - the HEAD symbolic ref for the worktree. - - * "git diff -M" used to work better when two originally identical - files A and B got renamed to X/A and X/B by pairing A to X/A and B - to X/B, but this was broken in the 2.0 timeframe. - - * "git send-pack --all <there>" was broken when its command line - option parsing was written in the 2.6 timeframe. - - * "git format-patch --help" showed `-s` and `--no-patch` as if these - are valid options to the command. We already hide `--patch` option - from the documentation, because format-patch is about showing the - diff, and the documentation now hides these options as well. - - * When running "git blame $path" with unnormalized data in the index - for the path, the data in the working tree was blamed, even though - "git add" would not have changed what is already in the index, due - to "safe crlf" that disables the line-end conversion. It has been - corrected. - - * A change back in version 2.7 to "git branch" broke display of a - symbolic ref in a non-standard place in the refs/ hierarchy (we - expect symbolic refs to appear in refs/remotes/*/HEAD to point at - the primary branch the remote has, and as .git/HEAD to point at the - branch we locally checked out). - - * A partial rewrite of "git submodule" in the 2.7 timeframe changed - the way the gitdir: pointer in the submodules point at the real - repository location to use absolute paths by accident. This has - been corrected. - - * "git commit" misbehaved in a few minor ways when an empty message - is given via -m '', all of which has been corrected. - - * Support for CRAM-MD5 authentication method in "git imap-send" did - not work well. - - * Upcoming OpenSSL 1.1.0 will break compilation by updating a few API - elements we use in imap-send, which has been adjusted for the change. - - * The socks5:// proxy support added back in 2.6.4 days was not aware - that socks5h:// proxies behave differently from socks5:// proxies. - - * "git config" had a codepath that tried to pass a NULL to - printf("%s"), which nobody seems to have noticed. - - * On Cygwin, object creation uses the "create a temporary and then - rename it to the final name" pattern, not "create a temporary, - hardlink it to the final name and then unlink the temporary" - pattern. - - This is necessary to use Git on Windows shared directories, and is - already enabled for the MinGW and plain Windows builds. It also - has been used in Cygwin packaged versions of Git for quite a while. - See http://thread.gmane.org/gmane.comp.version-control.git/291853 - - * "merge-octopus" strategy did not ensure that the index is clean - when merge begins. - - * When "git merge" notices that the merge can be resolved purely at - the tree level (without having to merge blobs) and the resulting - tree happens to already exist in the object store, it forgot to - update the index, which left an inconsistent state that would - break later operations. - - * "git submodule" reports the paths of submodules the command - recurses into, but these paths were incorrectly reported when - the command was not run from the root level of the superproject. - - * The "user.useConfigOnly" configuration variable makes it an error - if users do not explicitly set user.name and user.email. However, - its check was not done early enough and allowed another error to - trigger, reporting that the default value we guessed from the - system setting was unusable. This was a suboptimal end-user - experience as we want the users to set user.name/user.email without - relying on the auto-detection at all. - - * "git mv old new" did not adjust the path for a submodule that lives - as a subdirectory inside old/ directory correctly. - - * "git replace -e" did not honour "core.editor" configuration. - - * "git push" from a corrupt repository that attempts to push a large - number of refs deadlocked; the thread to relay rejection notices - for these ref updates blocked on writing them to the main thread, - after the main thread at the receiving end notices that the push - failed and decides not to read these notices and return a failure. - - * mmap emulation on Windows has been optimized and work better without - consuming paging store when not needed. - - * A question by "git send-email" to ask the identity of the sender - has been updated. - - * UI consistency improvements for "git mergetool". - - * "git rebase -m" could be asked to rebase an entire branch starting - from the root, but failed by assuming that there always is a parent - commit to the first commit on the branch. - - * Fix a broken "p4 lfs" test. - - * Recent update to Git LFS broke "git p4" by changing the output from - its "lfs pointer" subcommand. - - * "git fetch" test t5510 was flaky while running a (forced) automagic - garbage collection. - - * Documentation updates to help contributors setting up Travis CI - test for their patches. - - * Some multi-byte encoding can have a backslash byte as a later part - of one letter, which would confuse "highlight" filter used in - gitweb. - - * "git commit-tree" plumbing command required the user to always sign - its result when the user sets the commit.gpgsign configuration - variable, which was an ancient mistake. Rework "git rebase" that - relied on this mistake so that it reads commit.gpgsign and pass (or - not pass) the -S option to "git commit-tree" to keep the end-user - expectation the same, while teaching "git commit-tree" to ignore - the configuration variable. This will stop requiring the users to - sign commit objects used internally as an implementation detail of - "git stash". - - * "http.cookieFile" configuration variable clearly wants a pathname, - but we forgot to treat it as such by e.g. applying tilde expansion. - - * Consolidate description of tilde-expansion that is done to - configuration variables that take pathname to a single place. - - * Correct faulty recommendation to use "git submodule deinit ." when - de-initialising all submodules, which would result in a strange - error message in a pathological corner case. - - * Many 'linkgit:<git documentation page>' references were broken, - which are all fixed with this. - - * "git rerere" can get confused by conflict markers deliberately left - by the inner merge step, because they are indistinguishable from - the real conflict markers left by the outermost merge which are - what the end user and "rerere" need to look at. This was fixed by - making the conflict markers left by the inner merges a bit longer. - (merge 0f9fd5c jc/ll-merge-internal later to maint). - - * CI test was taught to build documentation pages. - - * "git fsck" learned to catch NUL byte in a commit object as - potential error and warn. - - * Portability enhancement for "rebase -i" to help platforms whose - shell does not like "for i in <empty>" (which is not POSIX-kosher). - - * On Windows, .git and optionally any files whose name starts with a - dot are now marked as hidden, with a core.hideDotFiles knob to - customize this behaviour. - - * Documentation for "git merge --verify-signatures" has been updated - to clarify that the signature of only the commit at the tip is - verified. Also the phrasing used for signature and key validity is - adjusted to align with that used by OpenPGP. - - * A couple of bugs around core.autocrlf have been fixed. - - * Many commands normalize command line arguments from NFD to NFC - variant of UTF-8 on OSX, but commands in the "diff" family did - not, causing "git diff $path" to complain that no such path is - known to Git. They have been taught to do the normalization. - - * "git difftool" learned to handle unmerged paths correctly in - dir-diff mode. - - * The "are we talking with TTY, doing an interactive session?" - detection has been updated to work better for "Git for Windows". - - * We forgot to add "git log --decorate=auto" to documentation when we - added the feature back in v2.1.0 timeframe. - (merge 462cbb4 rj/log-decorate-auto later to maint). - - * "git fast-import --export-marks" would overwrite the existing marks - file even when it makes a dump from its custom die routine. - Prevent it from doing so when we have an import-marks file but - haven't finished reading it. - (merge f4beed6 fc/fast-import-broken-marks-file later to maint). - - * "git rebase -i", after it fails to auto-resolve the conflict, had - an unnecessary call to "git rerere" from its very early days, which - was spotted recently; the call has been removed. - (merge 7063693 js/rebase-i-dedup-call-to-rerere later to maint). - - * Other minor clean-ups and documentation updates - (merge cd82b7a pa/cherry-pick-doc-typo later to maint). - (merge 2bb73ae rs/patch-id-use-skip-prefix later to maint). - (merge aa20cbc rs/apply-name-terminate later to maint). - (merge fe17fc0 jc/t2300-setup later to maint). - (merge e256eec jk/shell-portability later to maint). diff --git a/third_party/git/Documentation/RelNotes/2.9.1.txt b/third_party/git/Documentation/RelNotes/2.9.1.txt deleted file mode 100644 index 338394097e..0000000000 --- a/third_party/git/Documentation/RelNotes/2.9.1.txt +++ /dev/null @@ -1,117 +0,0 @@ -Git v2.9.1 Release Notes -======================== - -Fixes since v2.9 ----------------- - - * 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. - - * 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. - - * 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. - - * "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. - - * "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. - - * 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. - - * Formats of the various data (and how to validate them) where we use - GPG signature have been documented. - - * 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. - -Also contains minor documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.9.2.txt b/third_party/git/Documentation/RelNotes/2.9.2.txt deleted file mode 100644 index 2620003dcf..0000000000 --- a/third_party/git/Documentation/RelNotes/2.9.2.txt +++ /dev/null @@ -1,13 +0,0 @@ -Git v2.9.2 Release Notes -======================== - -Fixes since v2.9.1 ------------------- - - * A fix merged to v2.9.1 had a few tests that are not meant to be - run on platforms without 64-bit long, which caused unnecessary - test failures on them because we didn't detect the platform and - skip them. These tests are now skipped on platforms that they - are not applicable to. - -No other change is included in this update. diff --git a/third_party/git/Documentation/RelNotes/2.9.3.txt b/third_party/git/Documentation/RelNotes/2.9.3.txt deleted file mode 100644 index 695b86f612..0000000000 --- a/third_party/git/Documentation/RelNotes/2.9.3.txt +++ /dev/null @@ -1,170 +0,0 @@ -Git v2.9.3 Release Notes -======================== - -Fixes since v2.9.2 ------------------- - - * 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. - - * 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 rebase -i --autostash" did not restore the auto-stashed change - when the operation was aborted. - - * "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. - - * More mark-up updates to typeset strings that are expected to - literally typed by the end user in fixed-width font. - - * 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. - - * 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". - - * The test framework learned a new helper test_match_signal to - check an exit code from getting killed by an expected signal. - - * "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. - - * "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. - - * 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 status" learned to suggest "merge --abort" during a conflicted - merge, just like it already suggests "rebase --abort" during a - conflicted rebase. - - * The .c/.h sources are marked as such in our .gitattributes file so - that "git diff -W" and friends would work better. - - * 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. - - * Allow http daemon tests in Travis CI tests. - - * 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. - - * The use of strbuf in "git rm" to build filename to remove was a bit - suboptimal, which has been fixed. - - * "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 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 netmalloc (in compat/) library. - - * 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 difftool <paths>..." started in a subdirectory failed to - interpret the paths relative to that directory, which has been - fixed. - -Also contains minor documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.9.4.txt b/third_party/git/Documentation/RelNotes/2.9.4.txt deleted file mode 100644 index 9768293831..0000000000 --- a/third_party/git/Documentation/RelNotes/2.9.4.txt +++ /dev/null @@ -1,90 +0,0 @@ -Git v2.9.4 Release Notes -======================== - -Fixes since v2.9.3 ------------------- - - * 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. - - * "git merge" with renormalization did not work well with - merge-recursive, due to "safer crlf" conversion kicking in when it - shouldn't. - - * The reflog output format is documented better, and a new format - --date=unix to report the seconds-since-epoch (without timezone) - has been added. - - * "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. - - * "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. - - * "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 '/'. - - * 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). - - * 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. - - * "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. - - * "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. - - * On Windows, help.browser configuration variable used to be ignored, - which has been corrected. - - * 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?" - - * 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). - - * "git-shell" rejects a request to serve a repository whose name - begins with a dash, which makes it no longer possible to get it - confused into spawning service programs like "git-upload-pack" with - an option like "--help", which in turn would spawn an interactive - pager, instead of working with the repository user asked to access - (i.e. the one whose name is "--help"). - -Also contains minor documentation updates and code clean-ups. diff --git a/third_party/git/Documentation/RelNotes/2.9.5.txt b/third_party/git/Documentation/RelNotes/2.9.5.txt deleted file mode 100644 index 668313ae55..0000000000 --- a/third_party/git/Documentation/RelNotes/2.9.5.txt +++ /dev/null @@ -1,4 +0,0 @@ -Git v2.9.5 Release Notes -======================== - -This release forward-ports the fix for "ssh://..." URL from Git v2.7.6 diff --git a/third_party/git/Documentation/SubmittingPatches b/third_party/git/Documentation/SubmittingPatches deleted file mode 100644 index 6d589e118c..0000000000 --- a/third_party/git/Documentation/SubmittingPatches +++ /dev/null @@ -1,569 +0,0 @@ -Submitting Patches -================== - -== Guidelines - -Here are some guidelines for people who want to contribute their code -to this software. - -[[base-branch]] -=== Decide what to base your work on. - -In general, always base your work on the oldest branch that your -change is relevant to. - -* A bugfix should be based on `maint` in general. If the bug is not - present in `maint`, base it on `master`. For a bug that's not yet - in `master`, find the topic that introduces the regression, and - base your work on the tip of the topic. - -* A new feature should be based on `master` in general. If the new - feature depends on a topic that is in `pu`, but not in `master`, - base your work on the tip of that topic. - -* Corrections and enhancements to a topic not yet in `master` should - be based on the tip of that topic. If the topic has not been merged - to `next`, it's alright to add a note to squash minor corrections - into the series. - -* In the exceptional case that a new feature depends on several topics - not in `master`, start working on `next` or `pu` privately and send - out patches for discussion. Before the final merge, you may have to - wait until some of the dependent topics graduate to `master`, and - rebase your work. - -* Some parts of the system have dedicated maintainers with their own - repositories (see the section "Subsystems" below). Changes to - these parts should be based on their trees. - -To find the tip of a topic branch, run `git log --first-parent -master..pu` and look for the merge commit. The second parent of this -commit is the tip of the topic branch. - -[[separate-commits]] -=== Make separate commits for logically separate changes. - -Unless your patch is really trivial, you should not be sending -out a patch that was generated between your working tree and -your commit head. Instead, always make a commit with complete -commit message and generate a series of patches from your -repository. It is a good discipline. - -Give an explanation for the change(s) that is detailed enough so -that people can judge if it is good thing to do, without reading -the actual patch text to determine how well the code does what -the explanation promises to do. - -If your description starts to get too long, that's a sign that you -probably need to split up your commit to finer grained pieces. -That being said, patches which plainly describe the things that -help reviewers check the patch, and future maintainers understand -the code, are the most beautiful patches. Descriptions that summarize -the point in the subject well, and describe the motivation for the -change, the approach taken by the change, and if relevant how this -differs substantially from the prior version, are all good things -to have. - -Make sure that you have tests for the bug you are fixing. See -`t/README` for guidance. - -[[tests]] -When adding a new feature, make sure that you have new tests to show -the feature triggers the new behavior when it should, and to show the -feature does not trigger when it shouldn't. After any code change, make -sure that the entire test suite passes. - -If you have an account at GitHub (and you can get one for free to work -on open source projects), you can use their Travis CI integration to -test your changes on Linux, Mac (and hopefully soon Windows). See -GitHub-Travis CI hints section for details. - -Do not forget to update the documentation to describe the updated -behavior and make sure that the resulting documentation set formats -well (try the Documentation/doc-diff script). - -We currently have a liberal mixture of US and UK English norms for -spelling and grammar, which is somewhat unfortunate. A huge patch that -touches the files all over the place only to correct the inconsistency -is not welcome, though. Potential clashes with other changes that can -result from such a patch are not worth it. We prefer to gradually -reconcile the inconsistencies in favor of US English, with small and -easily digestible patches, as a side effect of doing some other real -work in the vicinity (e.g. rewriting a paragraph for clarity, while -turning en_UK spelling to en_US). Obvious typographical fixes are much -more welcomed ("teh -> "the"), preferably submitted as independent -patches separate from other documentation changes. - -[[whitespace-check]] -Oh, another thing. We are picky about whitespaces. Make sure your -changes do not trigger errors with the sample pre-commit hook shipped -in `templates/hooks--pre-commit`. To help ensure this does not happen, -run `git diff --check` on your changes before you commit. - -[[describe-changes]] -=== Describe your changes well. - -The first line of the commit message should be a short description (50 -characters is the soft limit, see DISCUSSION in linkgit:git-commit[1]), -and should skip the full stop. It is also conventional in most cases to -prefix the first line with "area: " where the area is a filename or -identifier for the general area of the code being modified, e.g. - -* doc: clarify distinction between sign-off and pgp-signing -* githooks.txt: improve the intro section - -If in doubt which identifier to use, run `git log --no-merges` on the -files you are modifying to see the current conventions. - -[[summary-section]] -It's customary to start the remainder of the first line after "area: " -with a lower-case letter. E.g. "doc: clarify...", not "doc: -Clarify...", or "githooks.txt: improve...", not "githooks.txt: -Improve...". - -[[meaningful-message]] -The body should provide a meaningful commit message, which: - -. explains the problem the change tries to solve, i.e. what is wrong - with the current code without the change. - -. justifies the way the change solves the problem, i.e. why the - result with the change is better. - -. alternate solutions considered but discarded, if any. - -[[imperative-mood]] -Describe your changes in imperative mood, e.g. "make xyzzy do frotz" -instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy -to do frotz", as if you are giving orders to the codebase to change -its behavior. Try to make sure your explanation can be understood -without external resources. Instead of giving a URL to a mailing list -archive, summarize the relevant points of the discussion. - -[[commit-reference]] -If you want to reference a previous commit in the history of a stable -branch, use the format "abbreviated sha1 (subject, date)", -with the subject enclosed in a pair of double-quotes, like this: - -.... - Commit f86a374 ("pack-bitmap.c: fix a memleak", 2015-03-30) - noticed that ... -.... - -The "Copy commit summary" command of gitk can be used to obtain this -format, or this invocation of `git show`: - -.... - git show -s --date=short --pretty='format:%h ("%s", %ad)' <commit> -.... - -[[git-tools]] -=== Generate your patch using Git tools out of your commits. - -Git based diff tools generate unidiff which is the preferred format. - -You do not have to be afraid to use `-M` option to `git diff` or -`git format-patch`, if your patch involves file renames. The -receiving end can handle them just fine. - -[[review-patch]] -Please make sure your patch does not add commented out debugging code, -or include any extra files which do not relate to what your patch -is trying to achieve. Make sure to review -your patch after generating it, to ensure accuracy. Before -sending out, please make sure it cleanly applies to the `master` -branch head. If you are preparing a work based on "next" branch, -that is fine, but please mark it as such. - -[[send-patches]] -=== Sending your patches. - -:security-ml: footnoteref:[security-ml,The Git Security mailing list: git-security@googlegroups.com] - -Before sending any patches, please note that patches that may be -security relevant should be submitted privately to the Git Security -mailing list{security-ml}, instead of the public mailing list. - -Learn to use format-patch and send-email if possible. These commands -are optimized for the workflow of sending patches, avoiding many ways -your existing e-mail client that is optimized for "multipart/*" mime -type e-mails to corrupt and render your patches unusable. - -People on the Git mailing list need to be able to read and -comment on the changes you are submitting. It is important for -a developer to be able to "quote" your changes, using standard -e-mail tools, so that they may comment on specific portions of -your code. For this reason, each patch should be submitted -"inline" in a separate message. - -Multiple related patches should be grouped into their own e-mail -thread to help readers find all parts of the series. To that end, -send them as replies to either an additional "cover letter" message -(see below), the first patch, or the respective preceding patch. - -If your log message (including your name on the -Signed-off-by line) is not writable in ASCII, make sure that -you send off a message in the correct encoding. - -WARNING: Be wary of your MUAs word-wrap -corrupting your patch. Do not cut-n-paste your patch; you can -lose tabs that way if you are not careful. - -It is a common convention to prefix your subject line with -[PATCH]. This lets people easily distinguish patches from other -e-mail discussions. Use of markers in addition to PATCH within -the brackets to describe the nature of the patch is also -encouraged. E.g. [RFC PATCH] (where RFC stands for "request for -comments") is often used to indicate a patch needs further -discussion before being accepted, [PATCH v2], [PATCH v3] etc. -are often seen when you are sending an update to what you have -previously sent. - -The `git format-patch` command follows the best current practice to -format the body of an e-mail message. At the beginning of the -patch should come your commit message, ending with the -Signed-off-by: lines, and a line that consists of three dashes, -followed by the diffstat information and the patch itself. If -you are forwarding a patch from somebody else, optionally, at -the beginning of the e-mail message just before the commit -message starts, you can put a "From: " line to name that person. -To change the default "[PATCH]" in the subject to "[<text>]", use -`git format-patch --subject-prefix=<text>`. As a shortcut, you -can use `--rfc` instead of `--subject-prefix="RFC PATCH"`, or -`-v <n>` instead of `--subject-prefix="PATCH v<n>"`. - -You often want to add additional explanation about the patch, -other than the commit message itself. Place such "cover letter" -material between the three-dash line and the diffstat. For -patches requiring multiple iterations of review and discussion, -an explanation of changes between each iteration can be kept in -Git-notes and inserted automatically following the three-dash -line via `git format-patch --notes`. - -[[attachment]] -Do not attach the patch as a MIME attachment, compressed or not. -Do not let your e-mail client send quoted-printable. Do not let -your e-mail client send format=flowed which would destroy -whitespaces in your patches. Many -popular e-mail applications will not always transmit a MIME -attachment as plain text, making it impossible to comment on -your code. A MIME attachment also takes a bit more time to -process. This does not decrease the likelihood of your -MIME-attached change being accepted, but it makes it more likely -that it will be postponed. - -Exception: If your mailer is mangling patches then someone may ask -you to re-send them using MIME, that is OK. - -[[pgp-signature]] -Do not PGP sign your patch. Most likely, your maintainer or other people on the -list would not have your PGP key and would not bother obtaining it anyway. -Your patch is not judged by who you are; a good patch from an unknown origin -has a far better chance of being accepted than a patch from a known, respected -origin that is done poorly or does incorrect things. - -If you really really really really want to do a PGP signed -patch, format it as "multipart/signed", not a text/plain message -that starts with `-----BEGIN PGP SIGNED MESSAGE-----`. That is -not a text/plain, it's something else. - -:security-ml-ref: footnoteref:[security-ml] - -As mentioned at the beginning of the section, patches that may be -security relevant should not be submitted to the public mailing list -mentioned below, but should instead be sent privately to the Git -Security mailing list{security-ml-ref}. - -Send your patch with "To:" set to the mailing list, with "cc:" listing -people who are involved in the area you are touching (the `git -contacts` command in `contrib/contacts/` can help to -identify them), to solicit comments and reviews. - -:current-maintainer: footnote:[The current maintainer: gitster@pobox.com] -:git-ml: footnote:[The mailing list: git@vger.kernel.org] - -After the list reached a consensus that it is a good idea to apply the -patch, re-send it with "To:" set to the maintainer{current-maintainer} and "cc:" the -list{git-ml} for inclusion. - -Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and -`Tested-by:` lines as necessary to credit people who helped your -patch. - -[[sign-off]] -=== Certify your work by adding your "Signed-off-by: " line - -To improve tracking of who did what, we've borrowed the -"sign-off" procedure from the Linux kernel project on patches -that are being emailed around. Although core Git is a lot -smaller project it is a good discipline to follow it. - -The sign-off is a simple line at the end of the explanation for -the patch, which certifies that you wrote it or otherwise have -the right to pass it on as an open-source patch. The rules are -pretty simple: if you can certify the below D-C-O: - -[[dco]] -.Developer's Certificate of Origin 1.1 -____ -By making a contribution to this project, I certify that: - -a. The contribution was created in whole or in part by me and I - have the right to submit it under the open source license - indicated in the file; or - -b. The contribution is based upon previous work that, to the best - of my knowledge, is covered under an appropriate open source - license and I have the right under that license to submit that - work with modifications, whether created in whole or in part - by me, under the same open source license (unless I am - permitted to submit under a different license), as indicated - in the file; or - -c. The contribution was provided directly to me by some other - person who certified (a), (b) or (c) and I have not modified - it. - -d. I understand and agree that this project and the contribution - are public and that a record of the contribution (including all - personal information I submit with it, including my sign-off) is - maintained indefinitely and may be redistributed consistent with - this project or the open source license(s) involved. -____ - -then you just add a line saying - -.... - Signed-off-by: Random J Developer <random@developer.example.org> -.... - -This line can be automatically added by Git if you run the git-commit -command with the -s option. - -Notice that you can place your own Signed-off-by: line when -forwarding somebody else's patch with the above rules for -D-C-O. Indeed you are encouraged to do so. Do not forget to -place an in-body "From: " line at the beginning to properly attribute -the change to its true author (see (2) above). - -[[real-name]] -Also notice that a real name is used in the Signed-off-by: line. Please -don't hide your real name. - -[[commit-trailers]] -If you like, you can put extra tags at the end: - -. `Reported-by:` is used to credit someone who found the bug that - the patch attempts to fix. -. `Acked-by:` says that the person who is more familiar with the area - the patch attempts to modify liked the patch. -. `Reviewed-by:`, unlike the other tags, can only be offered by the - reviewer and means that she is completely satisfied that the patch - is ready for application. It is usually offered only after a - detailed review. -. `Tested-by:` is used to indicate that the person applied the patch - and found it to have the desired effect. - -You can also create your own tag or use one that's in common usage -such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:". - -== Subsystems with dedicated maintainers - -Some parts of the system have dedicated maintainers with their own -repositories. - -- `git-gui/` comes from git-gui project, maintained by Pat Thoyts: - - git://repo.or.cz/git-gui.git - -- `gitk-git/` comes from Paul Mackerras's gitk project: - - git://ozlabs.org/~paulus/gitk - -- `po/` comes from the localization coordinator, Jiang Xin: - - https://github.com/git-l10n/git-po/ - -Patches to these parts should be based on their trees. - -[[patch-flow]] -== An ideal patch flow - -Here is an ideal patch flow for this project the current maintainer -suggests to the contributors: - -. You come up with an itch. You code it up. - -. Send it to the list and cc people who may need to know about - the change. -+ -The people who may need to know are the ones whose code you -are butchering. These people happen to be the ones who are -most likely to be knowledgeable enough to help you, but -they have no obligation to help you (i.e. you ask for help, -don't demand). +git log -p {litdd} _$area_you_are_modifying_+ would -help you find out who they are. - -. You get comments and suggestions for improvements. You may - even get them in an "on top of your change" patch form. - -. Polish, refine, and re-send to the list and the people who - spend their time to improve your patch. Go back to step (2). - -. The list forms consensus that the last round of your patch is - good. Send it to the maintainer and cc the list. - -. A topic branch is created with the patch and is merged to `next`, - and cooked further and eventually graduates to `master`. - -In any time between the (2)-(3) cycle, the maintainer may pick it up -from the list and queue it to `pu`, in order to make it easier for -people play with it without having to pick up and apply the patch to -their trees themselves. - -[[patch-status]] -== Know the status of your patch after submission - -* You can use Git itself to find out when your patch is merged in - master. `git pull --rebase` will automatically skip already-applied - patches, and will let you know. This works only if you rebase on top - of the branch in which your patch has been merged (i.e. it will not - tell you if your patch is merged in pu if you rebase on top of - master). - -* Read the Git mailing list, the maintainer regularly posts messages - entitled "What's cooking in git.git" and "What's in git.git" giving - the status of various proposed changes. - -[[travis]] -== GitHub-Travis CI hints - -With an account at GitHub (you can get one for free to work on open -source projects), you can use Travis CI to test your changes on Linux, -Mac (and hopefully soon Windows). You can find a successful example -test build here: https://travis-ci.org/git/git/builds/120473209 - -Follow these steps for the initial setup: - -. Fork https://github.com/git/git to your GitHub account. - You can find detailed instructions how to fork here: - https://help.github.com/articles/fork-a-repo/ - -. Open the Travis CI website: https://travis-ci.org - -. Press the "Sign in with GitHub" button. - -. Grant Travis CI permissions to access your GitHub account. - You can find more information about the required permissions here: - https://docs.travis-ci.com/user/github-oauth-scopes - -. Open your Travis CI profile page: https://travis-ci.org/profile - -. Enable Travis CI builds for your Git fork. - -After the initial setup, Travis CI will run whenever you push new changes -to your fork of Git on GitHub. You can monitor the test state of all your -branches here: https://travis-ci.org/__<Your GitHub handle>__/git/branches - -If a branch did not pass all test cases then it is marked with a red -cross. In that case you can click on the failing Travis CI job and -scroll all the way down in the log. Find the line "<-- Click here to see -detailed test output!" and click on the triangle next to the log line -number to expand the detailed test output. Here is such a failing -example: https://travis-ci.org/git/git/jobs/122676187 - -Fix the problem and push your fix to your Git fork. This will trigger -a new Travis CI build to ensure all tests pass. - -[[mua]] -== MUA specific hints - -Some of patches I receive or pick up from the list share common -patterns of breakage. Please make sure your MUA is set up -properly not to corrupt whitespaces. - -See the DISCUSSION section of linkgit:git-format-patch[1] for hints on -checking your patch by mailing it to yourself and applying with -linkgit:git-am[1]. - -While you are at it, check the resulting commit log message from -a trial run of applying the patch. If what is in the resulting -commit is not exactly what you would want to see, it is very -likely that your maintainer would end up hand editing the log -message when he applies your patch. Things like "Hi, this is my -first patch.\n", if you really want to put in the patch e-mail, -should come after the three-dash line that signals the end of the -commit message. - - -=== Pine - -(Johannes Schindelin) - -.... -I don't know how many people still use pine, but for those poor -souls it may be good to mention that the quell-flowed-text is -needed for recent versions. - -... the "no-strip-whitespace-before-send" option, too. AFAIK it -was introduced in 4.60. -.... - -(Linus Torvalds) - -.... -And 4.58 needs at least this. - -diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from e886a61f76edf5410573e92e38ce22974f9c40f1) -Author: Linus Torvalds <torvalds@g5.osdl.org> -Date: Mon Aug 15 17:23:51 2005 -0700 - - Fix pine whitespace-corruption bug - - There's no excuse for unconditionally removing whitespace from - the pico buffers on close. - -diff --git a/pico/pico.c b/pico/pico.c ---- a/pico/pico.c -+++ b/pico/pico.c -@@ -219,7 +219,9 @@ PICO *pm; - switch(pico_all_done){ /* prepare for/handle final events */ - case COMP_EXIT : /* already confirmed */ - packheader(); -+#if 0 - stripwhitespace(); -+#endif - c |= COMP_EXIT; - break; -.... - -(Daniel Barkalow) - -.... -> A patch to SubmittingPatches, MUA specific help section for -> users of Pine 4.63 would be very much appreciated. - -Ah, it looks like a recent version changed the default behavior to do the -right thing, and inverted the sense of the configuration option. (Either -that or Gentoo did it.) So you need to set the -"no-strip-whitespace-before-send" option, unless the option you have is -"strip-whitespace-before-send", in which case you should avoid checking -it. -.... - -=== Thunderbird, KMail, GMail - -See the MUA-SPECIFIC HINTS section of linkgit:git-format-patch[1]. - -=== Gnus - -"|" in the `*Summary*` buffer can be used to pipe the current -message to an external program, and this is a handy way to drive -`git am`. However, if the message is MIME encoded, what is -piped into the program is the representation you see in your -`*Article*` buffer after unwrapping MIME. This is often not what -you would want for two reasons. It tends to screw up non ASCII -characters (most notably in people's names), and also -whitespaces (fatal in patches). Running "C-u g" to display the -message in raw form before using "|" to run the pipe can work -this problem around. diff --git a/third_party/git/Documentation/asciidoc.conf b/third_party/git/Documentation/asciidoc.conf deleted file mode 100644 index 2c16c536ba..0000000000 --- a/third_party/git/Documentation/asciidoc.conf +++ /dev/null @@ -1,97 +0,0 @@ -## linkgit: macro -# -# Usage: linkgit:command[manpage-section] -# -# Note, {0} is the manpage section, while {target} is the command. -# -# Show Git link as: <command>(<section>); if section is defined, else just show -# the command. - -[macros] -(?su)[\\]?(?P<name>linkgit):(?P<target>\S*?)\[(?P<attrlist>.*?)\]= - -[attributes] -asterisk=* -plus=+ -caret=^ -startsb=[ -endsb=] -backslash=\ -tilde=~ -apostrophe=' -backtick=` -litdd=-- - -ifdef::backend-docbook[] -[linkgit-inlinemacro] -{0%{target}} -{0#<citerefentry>} -{0#<refentrytitle>{target}</refentrytitle><manvolnum>{0}</manvolnum>} -{0#</citerefentry>} -endif::backend-docbook[] - -ifdef::backend-docbook[] -ifndef::git-asciidoc-no-roff[] -# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this. -# v1.72 breaks with this because it replaces dots not in roff requests. -[listingblock] -<example><title>{title}</title> -<literallayout class="monospaced"> -ifdef::doctype-manpage[] - .ft C -endif::doctype-manpage[] -| -ifdef::doctype-manpage[] - .ft -endif::doctype-manpage[] -</literallayout> -{title#}</example> -endif::git-asciidoc-no-roff[] - -ifdef::git-asciidoc-no-roff[] -ifdef::doctype-manpage[] -# The following two small workarounds insert a simple paragraph after screen -[listingblock] -<example><title>{title}</title> -<literallayout class="monospaced"> -| -</literallayout><simpara></simpara> -{title#}</example> - -[verseblock] -<formalpara{id? id="{id}"}><title>{title}</title><para> -{title%}<literallayout{id? id="{id}"}> -{title#}<literallayout> -| -</literallayout> -{title#}</para></formalpara> -{title%}<simpara></simpara> -endif::doctype-manpage[] -endif::git-asciidoc-no-roff[] -endif::backend-docbook[] - -ifdef::doctype-manpage[] -ifdef::backend-docbook[] -[header] -template::[header-declarations] -<refentry> -<refmeta> -<refentrytitle>{mantitle}</refentrytitle> -<manvolnum>{manvolnum}</manvolnum> -<refmiscinfo class="source">Git</refmiscinfo> -<refmiscinfo class="version">{git_version}</refmiscinfo> -<refmiscinfo class="manual">Git Manual</refmiscinfo> -</refmeta> -<refnamediv> - <refname>{manname}</refname> - <refpurpose>{manpurpose}</refpurpose> -</refnamediv> -endif::backend-docbook[] -endif::doctype-manpage[] - -ifdef::backend-xhtml11[] -[attributes] -git-relative-html-prefix= -[linkgit-inlinemacro] -<a href="{git-relative-html-prefix}{target}.html">{target}{0?({0})}</a> -endif::backend-xhtml11[] diff --git a/third_party/git/Documentation/asciidoctor-extensions.rb b/third_party/git/Documentation/asciidoctor-extensions.rb deleted file mode 100644 index 0089e0cfb8..0000000000 --- a/third_party/git/Documentation/asciidoctor-extensions.rb +++ /dev/null @@ -1,28 +0,0 @@ -require 'asciidoctor' -require 'asciidoctor/extensions' - -module Git - module Documentation - class LinkGitProcessor < Asciidoctor::Extensions::InlineMacroProcessor - use_dsl - - named :chrome - - def process(parent, target, attrs) - if parent.document.basebackend? 'html' - prefix = parent.document.attr('git-relative-html-prefix') - %(<a href="#{prefix}#{target}.html">#{target}(#{attrs[1]})</a>) - elsif parent.document.basebackend? 'docbook' - "<citerefentry>\n" \ - "<refentrytitle>#{target}</refentrytitle>" \ - "<manvolnum>#{attrs[1]}</manvolnum>\n" \ - "</citerefentry>" - end - end - end - end -end - -Asciidoctor::Extensions.register do - inline_macro Git::Documentation::LinkGitProcessor, :linkgit -end diff --git a/third_party/git/Documentation/blame-options.txt b/third_party/git/Documentation/blame-options.txt deleted file mode 100644 index 5d122db6e9..0000000000 --- a/third_party/git/Documentation/blame-options.txt +++ /dev/null @@ -1,133 +0,0 @@ --b:: - Show blank SHA-1 for boundary commits. This can also - be controlled via the `blame.blankboundary` config option. - ---root:: - Do not treat root commits as boundaries. This can also be - controlled via the `blame.showRoot` config option. - ---show-stats:: - Include additional statistics at the end of blame output. - --L <start>,<end>:: --L :<funcname>:: - Annotate only the given line range. May be specified multiple times. - Overlapping ranges are allowed. -+ -<start> and <end> are optional. ``-L <start>'' or ``-L <start>,'' spans from -<start> to end of file. ``-L ,<end>'' spans from start of file to <end>. -+ -include::line-range-format.txt[] - --l:: - Show long rev (Default: off). - --t:: - Show raw timestamp (Default: off). - --S <revs-file>:: - Use revisions from revs-file instead of calling linkgit:git-rev-list[1]. - ---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. `git blame --reverse START` is taken as `git blame - --reverse START..HEAD` for convenience. - --p:: ---porcelain:: - Show in a format designed for machine consumption. - ---line-porcelain:: - Show the porcelain format, but output commit information for - each line, not just the first time a commit is referenced. - Implies --porcelain. - ---incremental:: - Show the result incrementally in a format designed for - machine consumption. - ---encoding=<encoding>:: - Specifies the encoding used to output author names - and commit summaries. Setting it to `none` makes blame - output unconverted data. For more information see the - discussion about encoding in the linkgit:git-log[1] - manual page. - ---contents <file>:: - When <rev> is not specified, the command annotates the - changes starting backwards from the working tree copy. - This flag makes the command pretend as if the working - tree copy has the contents of the named file (specify - `-` to make the command read from the standard input). - ---date <format>:: - Specifies the format used to output dates. If --date is not - provided, the value of the blame.date config variable is - used. If the blame.date config variable is also not set, the - iso format is used. For supported values, see the discussion - of the --date option at linkgit:git-log[1]. - ---[no-]progress:: - Progress status is reported on the standard error stream - by default when it is attached to a terminal. This flag - enables progress reporting even if not attached to a - terminal. Can't use `--progress` together with `--porcelain` - or `--incremental`. - --M[<num>]:: - Detect moved or copied lines within a file. When a commit - moves or copies a block of lines (e.g. the original file - has A and then B, and the commit changes it to B and then - A), the traditional 'blame' algorithm notices only half of - the movement and typically blames the lines that were moved - up (i.e. B) to the parent and assigns blame to the lines that - were moved down (i.e. A) to the child commit. With this - option, both groups of lines are blamed on the parent by - running extra passes of inspection. -+ -<num> is optional but it is the lower bound on the number of -alphanumeric characters that Git must detect as moving/copying -within a file for it to associate those lines with the parent -commit. The default value is 20. - --C[<num>]:: - In addition to `-M`, detect lines moved or copied from other - files that were modified in the same commit. This is - useful when you reorganize your program and move code - around across files. When this option is given twice, - the command additionally looks for copies from other - files in the commit that creates the file. When this - option is given three times, the command additionally - looks for copies from other files in any commit. -+ -<num> is optional but it is the lower bound on the number of -alphanumeric characters that Git must detect as moving/copying -between files for it to associate those lines with the parent -commit. And the default value is 40. If there are more than one -`-C` options given, the <num> argument of the last `-C` will -take effect. - ---ignore-rev <rev>:: - Ignore changes made by the revision when assigning blame, as if the - change never happened. Lines that were changed or added by an ignored - commit will be blamed on the previous commit that changed that line or - nearby lines. This option may be specified multiple times to ignore - more than one revision. If the `blame.markIgnoredLines` config option - is set, then lines that were changed by an ignored commit and attributed to - another commit will be marked with a `?` in the blame output. If the - `blame.markUnblamableLines` config option is set, then those lines touched - by an ignored commit that we could not attribute to another revision are - marked with a '*'. - ---ignore-revs-file <file>:: - Ignore revisions listed in `file`, which must be in the same format as an - `fsck.skipList`. This option may be repeated, and these files will be - processed after any files specified with the `blame.ignoreRevsFile` config - option. An empty file name, `""`, will clear the list of revs from - previously processed files. - --h:: - Show help message. diff --git a/third_party/git/Documentation/build-docdep.perl b/third_party/git/Documentation/build-docdep.perl deleted file mode 100755 index ba4205e030..0000000000 --- a/third_party/git/Documentation/build-docdep.perl +++ /dev/null @@ -1,46 +0,0 @@ -#!/usr/bin/perl - -my %include = (); -my %included = (); - -for my $text (<*.txt>) { - open I, '<', $text || die "cannot read: $text"; - while (<I>) { - if (/^include::/) { - chomp; - s/^include::\s*//; - s/\[\]//; - $include{$text}{$_} = 1; - $included{$_} = 1; - } - } - close I; -} - -# Do we care about chained includes??? -my $changed = 1; -while ($changed) { - $changed = 0; - while (my ($text, $included) = each %include) { - for my $i (keys %$included) { - # $text has include::$i; if $i includes $j - # $text indirectly includes $j. - if (exists $include{$i}) { - for my $j (keys %{$include{$i}}) { - if (!exists $include{$text}{$j}) { - $include{$text}{$j} = 1; - $included{$j} = 1; - $changed = 1; - } - } - } - } - } -} - -while (my ($text, $included) = each %include) { - if (! exists $included{$text} && - (my $base = $text) =~ s/\.txt$//) { - print "$base.html $base.xml : ", join(" ", keys %$included), "\n"; - } -} diff --git a/third_party/git/Documentation/cat-texi.perl b/third_party/git/Documentation/cat-texi.perl deleted file mode 100755 index 14d2f83415..0000000000 --- a/third_party/git/Documentation/cat-texi.perl +++ /dev/null @@ -1,46 +0,0 @@ -#!/usr/bin/perl -w - -use strict; -use warnings; - -my @menu = (); -my $output = $ARGV[0]; - -open my $tmp, '>', "$output.tmp"; - -while (<STDIN>) { - next if (/^\\input texinfo/../\@node Top/); - next if (/^\@bye/ || /^\.ft/); - if (s/^\@top (.*)/\@node $1,,,Top/) { - push @menu, $1; - } - s/\(\@pxref\{\[(URLS|REMOTES)\]}\)//; - s/\@anchor\{[^{}]*\}//g; - print $tmp $_; -} -close $tmp; - -print '\input texinfo -@setfilename gitman.info -@documentencoding UTF-8 -@dircategory Development -@direntry -* Git Man Pages: (gitman). Manual pages for Git revision control system -@end direntry -@node Top,,, (dir) -@top Git Manual Pages -@documentlanguage en -@menu -'; - -for (@menu) { - print "* ${_}::\n"; -} -print "\@end menu\n"; -open $tmp, '<', "$output.tmp"; -while (<$tmp>) { - print; -} -close $tmp; -print "\@bye\n"; -unlink "$output.tmp"; diff --git a/third_party/git/Documentation/cmd-list.perl b/third_party/git/Documentation/cmd-list.perl deleted file mode 100755 index 5aa73cfe45..0000000000 --- a/third_party/git/Documentation/cmd-list.perl +++ /dev/null @@ -1,78 +0,0 @@ -#!/usr/bin/perl -w - -use File::Compare qw(compare); - -sub format_one { - my ($out, $nameattr) = @_; - my ($name, $attr) = @$nameattr; - my ($state, $description); - $state = 0; - open I, '<', "$name.txt" or die "No such file $name.txt"; - while (<I>) { - if (/^NAME$/) { - $state = 1; - next; - } - if ($state == 1 && /^----$/) { - $state = 2; - next; - } - next if ($state != 2); - chomp; - $description = $_; - last; - } - close I; - if (!defined $description) { - die "No description found in $name.txt"; - } - if (my ($verify_name, $text) = ($description =~ /^($name) - (.*)/)) { - print $out "linkgit:$name\[1\]::\n\t"; - if ($attr =~ / deprecated /) { - print $out "(deprecated) "; - } - print $out "$text.\n\n"; - } - else { - die "Description does not match $name: $description"; - } -} - -while (<>) { - last if /^### command list/; -} - -my %cmds = (); -for (sort <>) { - next if /^#/; - - chomp; - my ($name, $cat, $attr) = /^(\S+)\s+(.*?)(?:\s+(.*))?$/; - $attr = '' unless defined $attr; - push @{$cmds{$cat}}, [$name, " $attr "]; -} - -for my $cat (qw(ancillaryinterrogators - ancillarymanipulators - mainporcelain - plumbinginterrogators - plumbingmanipulators - synchingrepositories - foreignscminterface - purehelpers - synchelpers)) { - my $out = "cmds-$cat.txt"; - open O, '>', "$out+" or die "Cannot open output file $out+"; - for (@{$cmds{$cat}}) { - format_one(\*O, $_); - } - close O; - - if (-f "$out" && compare("$out", "$out+") == 0) { - unlink "$out+"; - } - else { - print STDERR "$out\n"; - rename "$out+", "$out"; - } -} diff --git a/third_party/git/Documentation/config.txt b/third_party/git/Documentation/config.txt deleted file mode 100644 index e3f5bc3396..0000000000 --- a/third_party/git/Documentation/config.txt +++ /dev/null @@ -1,460 +0,0 @@ -CONFIGURATION FILE ------------------- - -The Git configuration file contains a number of variables that affect -the Git commands' behavior. The files `.git/config` and optionally -`config.worktree` (see `extensions.worktreeConfig` below) in each -repository are used to store the configuration for that repository, and -`$HOME/.gitconfig` is used to store a per-user configuration as -fallback values for the `.git/config` file. The file `/etc/gitconfig` -can be used to store a system-wide default configuration. - -The configuration variables are used by both the Git plumbing -and the porcelains. The variables are divided into sections, wherein -the fully qualified variable name of the variable itself is the last -dot-separated segment and the section name is everything before the last -dot. The variable names are case-insensitive, allow only alphanumeric -characters and `-`, and must start with an alphabetic character. Some -variables may appear multiple times; we say then that the variable is -multivalued. - -Syntax -~~~~~~ - -The syntax is fairly flexible and permissive; whitespaces are mostly -ignored. The '#' and ';' characters begin comments to the end of line, -blank lines are ignored. - -The file consists of sections and variables. A section begins with -the name of the section in square brackets and continues until the next -section begins. Section names are case-insensitive. Only alphanumeric -characters, `-` and `.` are allowed in section names. Each variable -must belong to some section, which means that there must be a section -header before the first setting of a variable. - -Sections can be further divided into subsections. To begin a subsection -put its name in double quotes, separated by space from the section name, -in the section header, like in the example below: - --------- - [section "subsection"] - --------- - -Subsection names are case sensitive and can contain any characters except -newline and the null byte. Doublequote `"` and backslash can be included -by escaping them as `\"` and `\\`, respectively. Backslashes preceding -other characters are dropped when reading; for example, `\t` is read as -`t` and `\0` is read as `0` Section headers cannot span multiple lines. -Variables may belong directly to a section or to a given subsection. You -can have `[section]` if you have `[section "subsection"]`, but you don't -need to. - -There is also a deprecated `[section.subsection]` syntax. With this -syntax, the subsection name is converted to lower-case and is also -compared case sensitively. These subsection names follow the same -restrictions as section names. - -All the other lines (and the remainder of the line after the section -header) are recognized as setting variables, in the form -'name = value' (or just 'name', which is a short-hand to say that -the variable is the boolean "true"). -The variable names are case-insensitive, allow only alphanumeric characters -and `-`, and must start with an alphabetic character. - -A line that defines a value can be continued to the next line by -ending it with a `\`; the backquote and the end-of-line are -stripped. Leading whitespaces after 'name =', the remainder of the -line after the first comment character '#' or ';', and trailing -whitespaces of the line are discarded unless they are enclosed in -double quotes. Internal whitespaces within the value are retained -verbatim. - -Inside double quotes, double quote `"` and backslash `\` characters -must be escaped: use `\"` for `"` and `\\` for `\`. - -The following escape sequences (beside `\"` and `\\`) are recognized: -`\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB) -and `\b` for backspace (BS). Other char escape sequences (including octal -escape sequences) are invalid. - - -Includes -~~~~~~~~ - -The `include` and `includeIf` sections allow you to include config -directives from another source. These sections behave identically to -each other with the exception that `includeIf` sections may be ignored -if their condition does not evaluate to true; see "Conditional includes" -below. - -You can include a config file from another by setting the special -`include.path` (or `includeIf.*.path`) variable to the name of the file -to be included. The variable takes a pathname as its value, and is -subject to tilde expansion. These variables can be given multiple times. - -The contents of the included file are inserted immediately, as if they -had been found at the location of the include directive. If the value of the -variable is a relative path, the path is considered to -be relative to the configuration file in which the include directive -was found. See below for examples. - -Conditional includes -~~~~~~~~~~~~~~~~~~~~ - -You can include a config file from another conditionally by setting a -`includeIf.<condition>.path` variable to the name of the file to be -included. - -The condition starts with a keyword followed by a colon and some data -whose format and meaning depends on the keyword. Supported keywords -are: - -`gitdir`:: - - The data that follows the keyword `gitdir:` is used as a glob - pattern. If the location of the .git directory matches the - pattern, the include condition is met. -+ -The .git location may be auto-discovered, or come from `$GIT_DIR` -environment variable. If the repository is auto discovered via a .git -file (e.g. from submodules, or a linked worktree), the .git location -would be the final location where the .git directory is, not where the -.git file is. -+ -The pattern can contain standard globbing wildcards and two additional -ones, `**/` and `/**`, that can match multiple path components. Please -refer to linkgit:gitignore[5] for details. For convenience: - - * If the pattern starts with `~/`, `~` will be substituted with the - content of the environment variable `HOME`. - - * If the pattern starts with `./`, it is replaced with the directory - containing the current config file. - - * If the pattern does not start with either `~/`, `./` or `/`, `**/` - will be automatically prepended. For example, the pattern `foo/bar` - becomes `**/foo/bar` and would match `/any/path/to/foo/bar`. - - * If the pattern ends with `/`, `**` will be automatically added. For - example, the pattern `foo/` becomes `foo/**`. In other words, it - matches "foo" and everything inside, recursively. - -`gitdir/i`:: - This is the same as `gitdir` except that matching is done - case-insensitively (e.g. on case-insensitive file sytems) - -`onbranch`:: - The data that follows the keyword `onbranch:` is taken to be a - pattern with standard globbing wildcards and two additional - ones, `**/` and `/**`, that can match multiple path components. - If we are in a worktree where the name of the branch that is - currently checked out matches the pattern, the include condition - is met. -+ -If the pattern ends with `/`, `**` will be automatically added. For -example, the pattern `foo/` becomes `foo/**`. In other words, it matches -all branches that begin with `foo/`. This is useful if your branches are -organized hierarchically and you would like to apply a configuration to -all the branches in that hierarchy. - -A few more notes on matching via `gitdir` and `gitdir/i`: - - * Symlinks in `$GIT_DIR` are not resolved before matching. - - * Both the symlink & realpath versions of paths will be matched - outside of `$GIT_DIR`. E.g. if ~/git is a symlink to - /mnt/storage/git, both `gitdir:~/git` and `gitdir:/mnt/storage/git` - will match. -+ -This was not the case in the initial release of this feature in -v2.13.0, which only matched the realpath version. Configuration that -wants to be compatible with the initial release of this feature needs -to either specify only the realpath version, or both versions. - - * Note that "../" is not special and will match literally, which is - unlikely what you want. - -Example -~~~~~~~ - - # Core variables - [core] - ; Don't trust file modes - filemode = false - - # Our diff algorithm - [diff] - external = /usr/local/bin/diff-wrapper - renames = true - - [branch "devel"] - remote = origin - merge = refs/heads/devel - - # Proxy settings - [core] - gitProxy="ssh" for "kernel.org" - gitProxy=default-proxy ; for the rest - - [include] - path = /path/to/foo.inc ; include by absolute path - path = foo.inc ; find "foo.inc" relative to the current file - path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory - - ; include if $GIT_DIR is /path/to/foo/.git - [includeIf "gitdir:/path/to/foo/.git"] - path = /path/to/foo.inc - - ; include for all repositories inside /path/to/group - [includeIf "gitdir:/path/to/group/"] - path = /path/to/foo.inc - - ; include for all repositories inside $HOME/to/group - [includeIf "gitdir:~/to/group/"] - path = /path/to/foo.inc - - ; relative paths are always relative to the including - ; file (if the condition is true); their location is not - ; affected by the condition - [includeIf "gitdir:/path/to/group/"] - path = foo.inc - - ; include only if we are in a worktree where foo-branch is - ; currently checked out - [includeIf "onbranch:foo-branch"] - path = foo.inc - -Values -~~~~~~ - -Values of many variables are treated as a simple string, but there -are variables that take values of specific types and there are rules -as to how to spell them. - -boolean:: - - When a variable is said to take a boolean value, many - synonyms are accepted for 'true' and 'false'; these are all - case-insensitive. - - true;; Boolean true literals are `yes`, `on`, `true`, - and `1`. Also, a variable defined without `= <value>` - is taken as true. - - false;; Boolean false literals are `no`, `off`, `false`, - `0` and the empty string. -+ -When converting a value to its canonical form using the `--type=bool` type -specifier, 'git config' will ensure that the output is "true" or -"false" (spelled in lowercase). - -integer:: - The value for many variables that specify various sizes can - be suffixed with `k`, `M`,... to mean "scale the number by - 1024", "by 1024x1024", etc. - -color:: - 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). -+ -An empty color string produces no color effect at all. This can be used -to avoid coloring specific elements without disabling color entirely. -+ -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 - string that begins with "`~/`" or "`~user/`", and the usual - tilde expansion happens to such a string: `~/` - is expanded to the value of `$HOME`, and `~user/` to the - specified user's home directory. - - -Variables -~~~~~~~~~ - -Note that this list is non-comprehensive and not necessarily complete. -For command-specific variables, you will find a more detailed description -in the appropriate manual page. - -Other git-related tools may and do use their own variables. When -inventing new variables for use in your own tool, make sure their -names do not conflict with those that are used by Git itself and -other popular tools, and describe them in your documentation. - -include::config/advice.txt[] - -include::config/core.txt[] - -include::config/add.txt[] - -include::config/alias.txt[] - -include::config/am.txt[] - -include::config/apply.txt[] - -include::config/blame.txt[] - -include::config/branch.txt[] - -include::config/browser.txt[] - -include::config/checkout.txt[] - -include::config/clean.txt[] - -include::config/color.txt[] - -include::config/column.txt[] - -include::config/commit.txt[] - -include::config/credential.txt[] - -include::config/completion.txt[] - -include::config/diff.txt[] - -include::config/difftool.txt[] - -include::config/fastimport.txt[] - -include::config/fetch.txt[] - -include::config/format.txt[] - -include::config/filter.txt[] - -include::config/fsck.txt[] - -include::config/gc.txt[] - -include::config/gitcvs.txt[] - -include::config/gitweb.txt[] - -include::config/grep.txt[] - -include::config/gpg.txt[] - -include::config/gui.txt[] - -include::config/guitool.txt[] - -include::config/help.txt[] - -include::config/http.txt[] - -include::config/i18n.txt[] - -include::config/imap.txt[] - -include::config/index.txt[] - -include::config/init.txt[] - -include::config/instaweb.txt[] - -include::config/interactive.txt[] - -include::config/log.txt[] - -include::config/mailinfo.txt[] - -include::config/mailmap.txt[] - -include::config/man.txt[] - -include::config/merge.txt[] - -include::config/mergetool.txt[] - -include::config/notes.txt[] - -include::config/pack.txt[] - -include::config/pager.txt[] - -include::config/pretty.txt[] - -include::config/protocol.txt[] - -include::config/pull.txt[] - -include::config/push.txt[] - -include::config/rebase.txt[] - -include::config/receive.txt[] - -include::config/remote.txt[] - -include::config/remotes.txt[] - -include::config/repack.txt[] - -include::config/rerere.txt[] - -include::config/reset.txt[] - -include::config/sendemail.txt[] - -include::config/sequencer.txt[] - -include::config/showbranch.txt[] - -include::config/splitindex.txt[] - -include::config/ssh.txt[] - -include::config/status.txt[] - -include::config/stash.txt[] - -include::config/submodule.txt[] - -include::config/tag.txt[] - -include::config/trace2.txt[] - -include::config/transfer.txt[] - -include::config/uploadarchive.txt[] - -include::config/uploadpack.txt[] - -include::config/url.txt[] - -include::config/user.txt[] - -include::config/versionsort.txt[] - -include::config/web.txt[] - -include::config/worktree.txt[] diff --git a/third_party/git/Documentation/config/add.txt b/third_party/git/Documentation/config/add.txt deleted file mode 100644 index 4d753f006e..0000000000 --- a/third_party/git/Documentation/config/add.txt +++ /dev/null @@ -1,7 +0,0 @@ -add.ignoreErrors:: -add.ignore-errors (deprecated):: - Tells 'git add' to continue adding files when some files cannot be - added due to indexing errors. Equivalent to the `--ignore-errors` - option of linkgit:git-add[1]. `add.ignore-errors` is deprecated, - as it does not follow the usual naming convention for configuration - variables. diff --git a/third_party/git/Documentation/config/advice.txt b/third_party/git/Documentation/config/advice.txt deleted file mode 100644 index 6aaa360202..0000000000 --- a/third_party/git/Documentation/config/advice.txt +++ /dev/null @@ -1,110 +0,0 @@ -advice.*:: - These variables control various optional help messages designed to - aid new users. All 'advice.*' variables default to 'true', and you - can tell Git that you do not need help by setting these to 'false': -+ --- - fetchShowForcedUpdates:: - Advice shown when linkgit:git-fetch[1] takes a long time - to calculate forced updates after ref updates, or to warn - that the check is disabled. - pushUpdateRejected:: - Set this variable to 'false' if you want to disable - 'pushNonFFCurrent', - 'pushNonFFMatching', 'pushAlreadyExists', - 'pushFetchFirst', and 'pushNeedsForce' - simultaneously. - pushNonFFCurrent:: - Advice shown when linkgit:git-push[1] fails due to a - non-fast-forward update to the current branch. - pushNonFFMatching:: - Advice shown when you ran linkgit:git-push[1] and pushed - 'matching refs' explicitly (i.e. you used ':', or - specified a refspec that isn't your current branch) and - it resulted in a non-fast-forward error. - pushAlreadyExists:: - Shown when linkgit:git-push[1] rejects an update that - does not qualify for fast-forwarding (e.g., a tag.) - pushFetchFirst:: - Shown when linkgit:git-push[1] rejects an update that - tries to overwrite a remote ref that points at an - object we do not have. - pushNeedsForce:: - Shown when linkgit:git-push[1] rejects an update that - tries to overwrite a remote ref that points at an - object that is not a commit-ish, or make the remote - ref point at an object that is not a commit-ish. - pushUnqualifiedRefname:: - Shown when linkgit:git-push[1] gives up trying to - guess based on the source and destination refs what - remote ref namespace the source belongs in, but where - we can still suggest that the user push to either - refs/heads/* or refs/tags/* based on the type of the - source object. - statusAheadBehind:: - Shown when linkgit:git-status[1] computes the ahead/behind - counts for a local ref compared to its remote tracking ref, - and that calculation takes longer than expected. Will not - appear if `status.aheadBehind` is false or the option - `--no-ahead-behind` is given. - statusHints:: - Show directions on how to proceed from the current - state in the output of linkgit:git-status[1], in - the template shown when writing commit messages in - linkgit:git-commit[1], and in the help message shown - by linkgit:git-switch[1] or - linkgit:git-checkout[1] when switching branch. - statusUoption:: - Advise to consider using the `-u` option to linkgit:git-status[1] - when the command takes more than 2 seconds to enumerate untracked - files. - commitBeforeMerge:: - Advice shown when linkgit:git-merge[1] refuses to - merge to avoid overwriting local changes. - resetQuiet:: - Advice to consider using the `--quiet` option to linkgit:git-reset[1] - when the command takes more than 2 seconds to enumerate unstaged - changes after reset. - resolveConflict:: - Advice shown by various commands when conflicts - prevent the operation from being performed. - sequencerInUse:: - Advice shown when a sequencer command is already in progress. - implicitIdentity:: - Advice on how to set your identity configuration when - your information is guessed from the system username and - domain name. - detachedHead:: - Advice shown when you used - linkgit:git-switch[1] or linkgit:git-checkout[1] - to move to the detach HEAD state, to instruct how to - create a local branch after the fact. - checkoutAmbiguousRemoteBranchName:: - Advice shown when the argument to - linkgit:git-checkout[1] and linkgit:git-switch[1] - ambiguously resolves to a - remote tracking branch on more than one remote in - situations where an unambiguous argument would have - otherwise caused a remote-tracking branch to be - checked out. See the `checkout.defaultRemote` - configuration variable for how to set a given remote - to used by default in some situations where this - advice would be printed. - amWorkDir:: - Advice that shows the location of the patch file when - linkgit:git-am[1] fails to apply it. - rmHints:: - In case of failure in the output of linkgit:git-rm[1], - show directions on how to proceed from the current state. - addEmbeddedRepo:: - Advice on what to do when you've accidentally added one - git repo inside of another. - ignoredHook:: - Advice shown if a hook is ignored because the hook is not - set as executable. - waitingForEditor:: - Print a message to the terminal whenever Git is waiting for - editor input from the user. - nestedTag:: - Advice shown if a user attempts to recursively tag a tag object. --- diff --git a/third_party/git/Documentation/config/alias.txt b/third_party/git/Documentation/config/alias.txt deleted file mode 100644 index f1ca739d57..0000000000 --- a/third_party/git/Documentation/config/alias.txt +++ /dev/null @@ -1,28 +0,0 @@ -alias.*:: - Command aliases for the linkgit:git[1] command wrapper - e.g. - after defining `alias.last = cat-file commit HEAD`, the invocation - `git last` is equivalent to `git cat-file commit HEAD`. To avoid - confusion and troubles with script usage, aliases that - hide existing Git commands are ignored. Arguments are split by - spaces, the usual shell quoting and escaping is supported. - A quote pair or a backslash can be used to quote them. -+ -Note that the first word of an alias does not necessarily have to be a -command. It can be a command-line option that will be passed into the -invocation of `git`. In particular, this is useful when used with `-c` -to pass in one-time configurations or `-p` to force pagination. For example, -`loud-rebase = -c commit.verbose=true rebase` can be defined such that -running `git loud-rebase` would be equivalent to -`git -c commit.verbose=true rebase`. Also, `ps = -p status` would be a -helpful alias since `git ps` would paginate the output of `git status` -where the original command does not. -+ -If the alias expansion is prefixed with an exclamation point, -it will be treated as a shell command. For example, defining -`alias.new = !gitk --all --not ORIG_HEAD`, the invocation -`git new` is equivalent to running the shell command -`gitk --all --not ORIG_HEAD`. Note that shell commands will be -executed from the top-level directory of a repository, which may -not necessarily be the current directory. -`GIT_PREFIX` is set as returned by running `git rev-parse --show-prefix` -from the original current directory. See linkgit:git-rev-parse[1]. diff --git a/third_party/git/Documentation/config/am.txt b/third_party/git/Documentation/config/am.txt deleted file mode 100644 index 5bcad2efb1..0000000000 --- a/third_party/git/Documentation/config/am.txt +++ /dev/null @@ -1,14 +0,0 @@ -am.keepcr:: - If true, git-am will call git-mailsplit for patches in mbox format - with parameter `--keep-cr`. In this case git-mailsplit will - not remove `\r` from lines ending with `\r\n`. Can be overridden - by giving `--no-keep-cr` from the command line. - See linkgit:git-am[1], linkgit:git-mailsplit[1]. - -am.threeWay:: - By default, `git am` will fail if the patch does not apply cleanly. When - set to true, this setting tells `git am` to fall back on 3-way merge if - the patch records the identity of blobs it is supposed to apply to and - we have those blobs available locally (equivalent to giving the `--3way` - option from the command line). Defaults to `false`. - See linkgit:git-am[1]. diff --git a/third_party/git/Documentation/config/apply.txt b/third_party/git/Documentation/config/apply.txt deleted file mode 100644 index 8fb8ef763d..0000000000 --- a/third_party/git/Documentation/config/apply.txt +++ /dev/null @@ -1,11 +0,0 @@ -apply.ignoreWhitespace:: - When set to 'change', tells 'git apply' to ignore changes in - whitespace, in the same way as the `--ignore-space-change` - option. - When set to one of: no, none, never, false tells 'git apply' to - respect all whitespace differences. - See linkgit:git-apply[1]. - -apply.whitespace:: - Tells 'git apply' how to handle whitespaces, in the same way - as the `--whitespace` option. See linkgit:git-apply[1]. diff --git a/third_party/git/Documentation/config/blame.txt b/third_party/git/Documentation/config/blame.txt deleted file mode 100644 index 9468e8599c..0000000000 --- a/third_party/git/Documentation/config/blame.txt +++ /dev/null @@ -1,37 +0,0 @@ -blame.blankBoundary:: - Show blank commit object name for boundary commits in - linkgit:git-blame[1]. This option defaults to false. - -blame.coloring:: - This determines the coloring scheme to be applied to blame - output. It can be 'repeatedLines', 'highlightRecent', - or 'none' which is the default. - -blame.date:: - Specifies the format used to output dates in linkgit:git-blame[1]. - If unset the iso format is used. For supported values, - see the discussion of the `--date` option at linkgit:git-log[1]. - -blame.showEmail:: - Show the author email instead of author name in linkgit:git-blame[1]. - This option defaults to false. - -blame.showRoot:: - Do not treat root commits as boundaries in linkgit:git-blame[1]. - This option defaults to false. - -blame.ignoreRevsFile:: - Ignore revisions listed in the file, one unabbreviated object name per - line, in linkgit:git-blame[1]. Whitespace and comments beginning with - `#` are ignored. This option may be repeated multiple times. Empty - file names will reset the list of ignored revisions. This option will - be handled before the command line option `--ignore-revs-file`. - -blame.markUnblamables:: - Mark lines that were changed by an ignored revision that we could not - attribute to another commit with a '*' in the output of - linkgit:git-blame[1]. - -blame.markIgnoredLines:: - Mark lines that were changed by an ignored revision that we attributed to - another commit with a '?' in the output of linkgit:git-blame[1]. diff --git a/third_party/git/Documentation/config/branch.txt b/third_party/git/Documentation/config/branch.txt deleted file mode 100644 index a592d522a7..0000000000 --- a/third_party/git/Documentation/config/branch.txt +++ /dev/null @@ -1,102 +0,0 @@ -branch.autoSetupMerge:: - Tells 'git branch', 'git switch' and 'git checkout' to set up new branches - so that linkgit:git-pull[1] will appropriately merge from the - starting point branch. Note that even if this option is not set, - this behavior can be chosen per-branch using the `--track` - and `--no-track` options. The valid settings are: `false` -- no - automatic setup is done; `true` -- automatic setup is done when the - starting point is a remote-tracking branch; `always` -- - automatic setup is done when the starting point is either a - local branch or remote-tracking - branch. This option defaults to true. - -branch.autoSetupRebase:: - When a new branch is created with 'git branch', 'git switch' or 'git checkout' - that tracks another branch, this variable tells Git to set - up pull to rebase instead of merge (see "branch.<name>.rebase"). - When `never`, rebase is never automatically set to true. - When `local`, rebase is set to true for tracked branches of - other local branches. - When `remote`, rebase is set to true for tracked branches of - remote-tracking branches. - When `always`, rebase will be set to true for all tracking - branches. - See "branch.autoSetupMerge" for details on how to set up a - branch to track another branch. - This option defaults to never. - -branch.sort:: - This variable controls the sort ordering of branches when displayed by - linkgit:git-branch[1]. Without the "--sort=<value>" option provided, the - value of this variable will be used as the default. - See linkgit:git-for-each-ref[1] field names for valid values. - -branch.<name>.remote:: - When on branch <name>, it tells 'git fetch' and 'git push' - which remote to fetch from/push to. The remote to push to - may be overridden with `remote.pushDefault` (for all branches). - The remote to push to, for the current branch, may be further - overridden by `branch.<name>.pushRemote`. If no remote is - configured, or if you are not on any branch, it defaults to - `origin` for fetching and `remote.pushDefault` for pushing. - Additionally, `.` (a period) is the current local repository - (a dot-repository), see `branch.<name>.merge`'s final note below. - -branch.<name>.pushRemote:: - When on branch <name>, it overrides `branch.<name>.remote` for - pushing. It also overrides `remote.pushDefault` for pushing - from branch <name>. When you pull from one place (e.g. your - upstream) and push to another place (e.g. your own publishing - repository), you would want to set `remote.pushDefault` to - specify the remote to push to for all branches, and use this - option to override it for a specific branch. - -branch.<name>.merge:: - Defines, together with branch.<name>.remote, the upstream branch - for the given branch. It tells 'git fetch'/'git pull'/'git rebase' which - branch to merge and can also affect 'git push' (see push.default). - When in branch <name>, it tells 'git fetch' the default - refspec to be marked for merging in FETCH_HEAD. The value is - handled like the remote part of a refspec, and must match a - ref which is fetched from the remote given by - "branch.<name>.remote". - The merge information is used by 'git pull' (which at first calls - 'git fetch') to lookup the default branch for merging. Without - this option, 'git pull' defaults to merge the first refspec fetched. - Specify multiple values to get an octopus merge. - If you wish to setup 'git pull' so that it merges into <name> from - another branch in the local repository, you can point - branch.<name>.merge to the desired branch, and use the relative path - setting `.` (a period) for branch.<name>.remote. - -branch.<name>.mergeOptions:: - Sets default options for merging into branch <name>. The syntax and - supported options are the same as those of linkgit:git-merge[1], but - option values containing whitespace characters are currently not - supported. - -branch.<name>.rebase:: - When true, rebase the branch <name> on top of the fetched branch, - instead of merging the default branch from the default remote when - "git pull" is run. See "pull.rebase" for doing this in a non - branch-specific manner. -+ -When `merges`, pass the `--rebase-merges` option to 'git rebase' -so that the local merge commits are included in the rebase (see -linkgit:git-rebase[1] for details). -+ -When `preserve` (deprecated in favor of `merges`), also pass -`--preserve-merges` along to 'git rebase' so that locally committed merge -commits will not be flattened by running 'git pull'. -+ -When the value is `interactive`, the rebase is run in interactive mode. -+ -*NOTE*: this is a possibly dangerous operation; do *not* use -it unless you understand the implications (see linkgit:git-rebase[1] -for details). - -branch.<name>.description:: - Branch description, can be edited with - `git branch --edit-description`. Branch description is - automatically added in the format-patch cover letter or - request-pull summary. diff --git a/third_party/git/Documentation/config/browser.txt b/third_party/git/Documentation/config/browser.txt deleted file mode 100644 index 195df207a6..0000000000 --- a/third_party/git/Documentation/config/browser.txt +++ /dev/null @@ -1,9 +0,0 @@ -browser.<tool>.cmd:: - Specify the command to invoke the specified browser. The - specified command is evaluated in shell with the URLs passed - as arguments. (See linkgit:git-web{litdd}browse[1].) - -browser.<tool>.path:: - Override the path for the given tool that may be used to - browse HTML help (see `-w` option in linkgit:git-help[1]) or a - working repository in gitweb (see linkgit:git-instaweb[1]). diff --git a/third_party/git/Documentation/config/checkout.txt b/third_party/git/Documentation/config/checkout.txt deleted file mode 100644 index 6b646813ab..0000000000 --- a/third_party/git/Documentation/config/checkout.txt +++ /dev/null @@ -1,18 +0,0 @@ -checkout.defaultRemote:: - When you run 'git checkout <something>' - or 'git switch <something>' and only have one - remote, it may implicitly fall back on checking out and - tracking e.g. 'origin/<something>'. This stops working as soon - as you have more than one remote with a '<something>' - reference. This setting allows for setting the name of a - preferred remote that should always win when it comes to - disambiguation. The typical use-case is to set this to - `origin`. -+ -Currently this is used by linkgit:git-switch[1] and -linkgit:git-checkout[1] when 'git checkout <something>' -or 'git switch <something>' -will checkout the '<something>' branch on another remote, -and by linkgit:git-worktree[1] when 'git worktree add' refers to a -remote branch. This setting might be used for other checkout-like -commands or functionality in the future. diff --git a/third_party/git/Documentation/config/clean.txt b/third_party/git/Documentation/config/clean.txt deleted file mode 100644 index a807c925b9..0000000000 --- a/third_party/git/Documentation/config/clean.txt +++ /dev/null @@ -1,3 +0,0 @@ -clean.requireForce:: - A boolean to make git-clean do nothing unless given -f, - -i or -n. Defaults to true. diff --git a/third_party/git/Documentation/config/color.txt b/third_party/git/Documentation/config/color.txt deleted file mode 100644 index d5daacb13a..0000000000 --- a/third_party/git/Documentation/config/color.txt +++ /dev/null @@ -1,201 +0,0 @@ -color.advice:: - A boolean to enable/disable color in hints (e.g. when a push - failed, see `advice.*` for a list). May be set to `always`, - `false` (or `never`) or `auto` (or `true`), in which case colors - are used only when the error output goes to a terminal. If - unset, then the value of `color.ui` is used (`auto` by default). - -color.advice.hint:: - Use customized color for hints. - -color.blame.highlightRecent:: - This can be used to color the metadata of a blame line depending - on age of the line. -+ -This setting should be set to a comma-separated list of color and date settings, -starting and ending with a color, the dates should be set from oldest to newest. -The metadata will be colored given the colors if the line was introduced -before the given timestamp, overwriting older timestamped colors. -+ -Instead of an absolute timestamp relative timestamps work as well, e.g. -2.weeks.ago is valid to address anything older than 2 weeks. -+ -It defaults to 'blue,12 month ago,white,1 month ago,red', which colors -everything older than one year blue, recent changes between one month and -one year old are kept white, and lines introduced within the last month are -colored red. - -color.blame.repeatedLines:: - Use the customized color for the part of git-blame output that - is repeated meta information per line (such as commit id, - author name, date and timezone). Defaults to cyan. - -color.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. 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 - `current` (the current branch), `local` (a local branch), - `remote` (a remote-tracking branch in refs/remotes/), - `upstream` (upstream tracking branch), `plain` (other - refs). - -color.diff:: - Whether to use ANSI escape sequences to add color to patches. - If this is set to `always`, linkgit:git-diff[1], - 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. - 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 -command line with the `--color[=<when>]` option. - -color.diff.<slot>:: - Use customized color for diff colorization. `<slot>` specifies - which part of the patch to use the specified color, and is one - of `context` (context text - `plain` is a historical synonym), - `meta` (metainformation), `frag` - (hunk header), 'func' (function in hunk header), `old` (removed lines), - `new` (added lines), `commit` (commit headers), `whitespace` - (highlighting whitespace errors), `oldMoved` (deleted lines), - `newMoved` (added lines), `oldMovedDimmed`, `oldMovedAlternative`, - `oldMovedAlternativeDimmed`, `newMovedDimmed`, `newMovedAlternative` - `newMovedAlternativeDimmed` (See the '<mode>' - setting of '--color-moved' in linkgit:git-diff[1] for details), - `contextDimmed`, `oldDimmed`, `newDimmed`, `contextBold`, - `oldBold`, and `newBold` (see linkgit:git-range-diff[1] for details). - -color.decorate.<slot>:: - Use customized color for 'git log --decorate' output. `<slot>` is one - of `branch`, `remoteBranch`, `tag`, `stash` or `HEAD` for local - branches, remote-tracking branches, tags, stash and HEAD, respectively - and `grafted` for grafted commits. - -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. 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 - part of the line to use the specified color, and is one of -+ --- -`context`;; - non-matching text in context lines (when using `-A`, `-B`, or `-C`) -`filename`;; - filename prefix (when not using `-h`) -`function`;; - function name lines (when using `-p`) -`lineNumber`;; - line number prefix (when using `-n`) -`column`;; - column number prefix (when using `--column`) -`match`;; - matching text (same as setting `matchContext` and `matchSelected`) -`matchContext`;; - matching text in context lines -`matchSelected`;; - matching text in selected lines -`selected`;; - non-matching text in selected lines -`separator`;; - separators between fields on a line (`:`, `-`, and `=`) - and between hunks (`--`) --- - -color.interactive:: - When set to `always`, always use colors for interactive prompts - 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. 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 - --interactive' output. `<slot>` may be `prompt`, `header`, `help` - or `error`, for four distinct types of normal output from - interactive commands. - -color.pager:: - A boolean to enable/disable colored output when the pager is in - use (default is true). - -color.push:: - A boolean to enable/disable color in push errors. May be set to - `always`, `false` (or `never`) or `auto` (or `true`), in which - case colors are used only when the error output goes to a terminal. - If unset, then the value of `color.ui` is used (`auto` by default). - -color.push.error:: - Use customized color for push errors. - -color.remote:: - If set, keywords at the start of the line are highlighted. The - keywords are "error", "warning", "hint" and "success", and are - matched case-insensitively. May be set to `always`, `false` (or - `never`) or `auto` (or `true`). If unset, then the value of - `color.ui` is used (`auto` by default). - -color.remote.<slot>:: - Use customized color for each remote keyword. `<slot>` may be - `hint`, `warning`, `success` or `error` which match the - corresponding keyword. - -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. 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. If unset, then the - value of `color.ui` is used (`auto` by default). - -color.status.<slot>:: - Use customized color for status colorization. `<slot>` is - one of `header` (the header text of the status message), - `added` or `updated` (files which are added but not committed), - `changed` (files which are changed but not added in the index), - `untracked` (files which are not tracked by Git), - `branch` (the current branch), - `nobranch` (the color the 'no branch' warning is shown in, defaulting - to red), - `localBranch` or `remoteBranch` (the local and remote branch names, - respectively, when branch and tracking information is displayed in the - status short-format), or - `unmerged` (files which have unmerged changes). - -color.transport:: - A boolean to enable/disable color when pushes are rejected. May be - set to `always`, `false` (or `never`) or `auto` (or `true`), in which - case colors are used only when the error output goes to a terminal. - If unset, then the value of `color.ui` is used (`auto` by default). - -color.transport.rejected:: - Use customized color when a push was rejected. - -color.ui:: - This variable determines the default value for variables such - as `color.diff` and `color.grep` that control the use of color - per command family. Its scope will expand as more commands learn - configuration to set a default for the `--color` option. Set it - to `false` or `never` if you prefer Git commands not to use - color unless enabled explicitly with some other configuration - or the `--color` option. Set it to `always` if you want all - output not intended for machine consumption to use color, to - `true` or `auto` (this is the default since Git 1.8.4) if you - want such output to use color when written to the terminal. diff --git a/third_party/git/Documentation/config/column.txt b/third_party/git/Documentation/config/column.txt deleted file mode 100644 index 76aa2f29dc..0000000000 --- a/third_party/git/Documentation/config/column.txt +++ /dev/null @@ -1,55 +0,0 @@ -column.ui:: - Specify whether supported commands should output in columns. - This variable consists of a list of tokens separated by spaces - or commas: -+ -These options control when the feature should be enabled -(defaults to 'never'): -+ --- -`always`;; - always show in columns -`never`;; - never show in columns -`auto`;; - show in columns if the output is to the terminal --- -+ -These options control layout (defaults to 'column'). Setting any -of these implies 'always' if none of 'always', 'never', or 'auto' are -specified. -+ --- -`column`;; - fill columns before rows -`row`;; - fill rows before columns -`plain`;; - show in one column --- -+ -Finally, these options can be combined with a layout option (defaults -to 'nodense'): -+ --- -`dense`;; - make unequal size columns to utilize more space -`nodense`;; - make equal size columns --- - -column.branch:: - Specify whether to output branch listing in `git branch` in columns. - See `column.ui` for details. - -column.clean:: - Specify the layout when list items in `git clean -i`, which always - shows files and directories in columns. See `column.ui` for details. - -column.status:: - Specify whether to output untracked files in `git status` in columns. - See `column.ui` for details. - -column.tag:: - Specify whether to output tag listing in `git tag` in columns. - See `column.ui` for details. diff --git a/third_party/git/Documentation/config/commit.txt b/third_party/git/Documentation/config/commit.txt deleted file mode 100644 index 2c95573930..0000000000 --- a/third_party/git/Documentation/config/commit.txt +++ /dev/null @@ -1,29 +0,0 @@ -commit.cleanup:: - This setting overrides the default of the `--cleanup` option in - `git commit`. See linkgit:git-commit[1] for details. Changing the - default can be useful when you always want to keep lines that begin - with comment character `#` in your log message, in which case you - would do `git config commit.cleanup whitespace` (note that you will - have to remove the help lines that begin with `#` in the commit log - template yourself, if you do this). - -commit.gpgSign:: - - A boolean to specify whether all commits should be GPG signed. - Use of this option when doing operations such as rebase can - result in a large number of commits being signed. It may be - convenient to use an agent to avoid typing your GPG passphrase - several times. - -commit.status:: - A boolean to enable/disable inclusion of status information in the - commit message template when using an editor to prepare the commit - message. Defaults to true. - -commit.template:: - Specify the pathname of a file to use as the template for - new commit messages. - -commit.verbose:: - A boolean or int to specify the level of verbose with `git commit`. - See linkgit:git-commit[1]. diff --git a/third_party/git/Documentation/config/completion.txt b/third_party/git/Documentation/config/completion.txt deleted file mode 100644 index 4d99bf33c9..0000000000 --- a/third_party/git/Documentation/config/completion.txt +++ /dev/null @@ -1,7 +0,0 @@ -completion.commands:: - This is only used by git-completion.bash to add or remove - commands from the list of completed commands. Normally only - porcelain commands and a few select others are completed. You - can add more commands, separated by space, in this - variable. Prefixing the command with '-' will remove it from - the existing list. diff --git a/third_party/git/Documentation/config/core.txt b/third_party/git/Documentation/config/core.txt deleted file mode 100644 index 75538d27e7..0000000000 --- a/third_party/git/Documentation/config/core.txt +++ /dev/null @@ -1,603 +0,0 @@ -core.fileMode:: - Tells Git if the executable bit of files in the working tree - is to be honored. -+ -Some filesystems lose the executable bit when a file that is -marked as executable is checked out, or checks out a -non-executable file with executable bit on. -linkgit:git-clone[1] or linkgit:git-init[1] probe the filesystem -to see if it handles the executable bit correctly -and this variable is automatically set as necessary. -+ -A repository, however, may be on a filesystem that handles -the filemode correctly, and this variable is set to 'true' -when created, but later may be made accessible from another -environment that loses the filemode (e.g. exporting ext4 via -CIFS mount, visiting a Cygwin created repository with -Git for Windows or Eclipse). -In such a case it may be necessary to set this variable to 'false'. -See linkgit:git-update-index[1]. -+ -The default is true (when core.filemode is not specified in the config file). - -core.hideDotFiles:: - (Windows-only) If true, mark newly-created directories and files whose - name starts with a dot as hidden. If 'dotGitOnly', only the `.git/` - directory is hidden, but no other files starting with a dot. The - default mode is 'dotGitOnly'. - -core.ignoreCase:: - Internal variable which enables various workarounds to enable - Git to work better on filesystems that are not case sensitive, - like APFS, HFS+, FAT, NTFS, etc. For example, if a directory listing - finds "makefile" when Git expects "Makefile", Git will assume - it is really the same file, and continue to remember it as - "Makefile". -+ -The default is false, except linkgit:git-clone[1] or linkgit:git-init[1] -will probe and set core.ignoreCase true if appropriate when the repository -is created. -+ -Git relies on the proper configuration of this variable for your operating -and file system. Modifying this value may result in unexpected behavior. - -core.precomposeUnicode:: - This option is only used by Mac OS implementation of Git. - When core.precomposeUnicode=true, Git reverts the unicode decomposition - of filenames done by Mac OS. This is useful when sharing a repository - between Mac OS and Linux or Windows. - (Git for Windows 1.7.10 or higher is needed, or Git under cygwin 1.7). - When false, file names are handled fully transparent by Git, - which is backward compatible with older versions of Git. - -core.protectHFS:: - If set to true, do not allow checkout of paths that would - be considered equivalent to `.git` on an HFS+ filesystem. - Defaults to `true` on Mac OS, and `false` elsewhere. - -core.protectNTFS:: - If set to true, do not allow checkout of paths that would - cause problems with the NTFS filesystem, e.g. conflict with - 8.3 "short" names. - Defaults to `true` on Windows, and `false` elsewhere. - -core.fsmonitor:: - If set, the value of this variable is used as a command which - will identify all files that may have changed since the - requested date/time. This information is used to speed up git by - avoiding unnecessary processing of files that have not changed. - See the "fsmonitor-watchman" section of linkgit:githooks[5]. - -core.trustctime:: - If false, the ctime differences between the index and the - working tree are ignored; useful when the inode change time - is regularly modified by something outside Git (file system - crawlers and some backup systems). - See linkgit:git-update-index[1]. True by default. - -core.splitIndex:: - If true, the split-index feature of the index will be used. - See linkgit:git-update-index[1]. False by default. - -core.untrackedCache:: - Determines what to do about the untracked cache feature of the - index. It will be kept, if this variable is unset or set to - `keep`. It will automatically be added if set to `true`. And - it will automatically be removed, if set to `false`. Before - setting it to `true`, you should check that mtime is working - properly on your system. - See linkgit:git-update-index[1]. `keep` by default. - -core.checkStat:: - When missing or is set to `default`, many fields in the stat - structure are checked to detect if a file has been modified - since Git looked at it. When this configuration variable is - set to `minimal`, sub-second part of mtime and ctime, the - uid and gid of the owner of the file, the inode number (and - the device number, if Git was compiled to use it), are - excluded from the check among these fields, leaving only the - whole-second part of mtime (and ctime, if `core.trustCtime` - is set) and the filesize to be checked. -+ -There are implementations of Git that do not leave usable values in -some fields (e.g. JGit); by excluding these fields from the -comparison, the `minimal` mode may help interoperability when the -same repository is used by these other systems at the same time. - -core.quotePath:: - Commands that output paths (e.g. 'ls-files', 'diff'), will - quote "unusual" characters in the pathname by enclosing the - pathname in double-quotes and escaping those characters with - backslashes in the same way C escapes control characters (e.g. - `\t` for TAB, `\n` for LF, `\\` for backslash) or bytes with - values larger than 0x80 (e.g. octal `\302\265` for "micro" in - UTF-8). If this variable is set to false, bytes higher than - 0x80 are not considered "unusual" any more. Double-quotes, - backslash and control characters are always escaped regardless - of the setting of this variable. A simple space character is - not considered "unusual". Many commands can output pathnames - completely verbatim using the `-z` option. The default value - is true. - -core.eol:: - Sets the line ending type to use in the working directory for - files that are marked as text (either by having the `text` - attribute set, or by having `text=auto` and Git auto-detecting - the contents as text). - Alternatives are 'lf', 'crlf' and 'native', which uses the platform's - native line ending. The default value is `native`. See - linkgit:gitattributes[5] for more information on end-of-line - conversion. Note that this value is ignored if `core.autocrlf` - is set to `true` or `input`. - -core.safecrlf:: - If true, makes Git check if converting `CRLF` is reversible when - end-of-line conversion is active. Git will verify if a command - modifies a file in the work tree either directly or indirectly. - For example, committing a file followed by checking out the - same file should yield the original file in the work tree. If - this is not the case for the current setting of - `core.autocrlf`, Git will reject the file. The variable can - be set to "warn", in which case Git will only warn about an - irreversible conversion but continue the operation. -+ -CRLF conversion bears a slight chance of corrupting data. -When it is enabled, Git will convert CRLF to LF during commit and LF to -CRLF during checkout. A file that contains a mixture of LF and -CRLF before the commit cannot be recreated by Git. For text -files this is the right thing to do: it corrects line endings -such that we have only LF line endings in the repository. -But for binary files that are accidentally classified as text the -conversion can corrupt data. -+ -If you recognize such corruption early you can easily fix it by -setting the conversion type explicitly in .gitattributes. Right -after committing you still have the original file in your work -tree and this file is not yet corrupted. You can explicitly tell -Git that this file is binary and Git will handle the file -appropriately. -+ -Unfortunately, the desired effect of cleaning up text files with -mixed line endings and the undesired effect of corrupting binary -files cannot be distinguished. In both cases CRLFs are removed -in an irreversible way. For text files this is the right thing -to do because CRLFs are line endings, while for binary files -converting CRLFs corrupts data. -+ -Note, this safety check does not mean that a checkout will generate a -file identical to the original file for a different setting of -`core.eol` and `core.autocrlf`, but only for the current one. For -example, a text file with `LF` would be accepted with `core.eol=lf` -and could later be checked out with `core.eol=crlf`, in which case the -resulting file would contain `CRLF`, although the original file -contained `LF`. However, in both work trees the line endings would be -consistent, that is either all `LF` or all `CRLF`, but never mixed. A -file with mixed line endings would be reported by the `core.safecrlf` -mechanism. - -core.autocrlf:: - Setting this variable to "true" is the same as setting - the `text` attribute to "auto" on all files and core.eol to "crlf". - Set to true if you want to have `CRLF` line endings in your - working directory and the repository has LF line endings. - This variable can be set to 'input', - in which case no output conversion is performed. - -core.checkRoundtripEncoding:: - A comma and/or whitespace separated list of encodings that Git - performs UTF-8 round trip checks on if they are used in an - `working-tree-encoding` attribute (see linkgit:gitattributes[5]). - The default value is `SHIFT-JIS`. - -core.symlinks:: - If false, symbolic links are checked out as small plain files that - contain the link text. linkgit:git-update-index[1] and - linkgit:git-add[1] will not change the recorded type to regular - file. Useful on filesystems like FAT that do not support - symbolic links. -+ -The default is true, except linkgit:git-clone[1] or linkgit:git-init[1] -will probe and set core.symlinks false if appropriate when the repository -is created. - -core.gitProxy:: - A "proxy command" to execute (as 'command host port') instead - of establishing direct connection to the remote server when - using the Git protocol for fetching. If the variable value is - in the "COMMAND for DOMAIN" format, the command is applied only - on hostnames ending with the specified domain string. This variable - may be set multiple times and is matched in the given order; - the first match wins. -+ -Can be overridden by the `GIT_PROXY_COMMAND` environment variable -(which always applies universally, without the special "for" -handling). -+ -The special string `none` can be used as the proxy command to -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 - which it has updated identically in both the index and working tree. -+ -When files are modified outside of Git, the user will need to stage -the modified files explicitly (e.g. see 'Examples' section in -linkgit:git-update-index[1]). -Git will not normally detect changes to those files. -+ -This is useful on systems where lstat() calls are very slow, such as -CIFS/Microsoft Windows. -+ -False by default. - -core.preferSymlinkRefs:: - Instead of the default "symref" format for HEAD - and other symbolic reference files, use symbolic links. - This is sometimes needed to work with old scripts that - expect HEAD to be a symbolic link. - -core.alternateRefsCommand:: - When advertising tips of available history from an alternate, use the shell to - execute the specified command instead of linkgit:git-for-each-ref[1]. The - first argument is the absolute path of the alternate. Output must contain one - hex object id per line (i.e., the same as produced by `git for-each-ref - --format='%(objectname)'`). -+ -Note that you cannot generally put `git for-each-ref` directly into the config -value, as it does not take a repository path as an argument (but you can wrap -the command above in a shell script). - -core.alternateRefsPrefixes:: - When listing references from an alternate, list only references that begin - with the given prefix. Prefixes match as if they were given as arguments to - linkgit:git-for-each-ref[1]. To list multiple prefixes, separate them with - whitespace. If `core.alternateRefsCommand` is set, setting - `core.alternateRefsPrefixes` has no effect. - -core.bare:: - If true this repository is assumed to be 'bare' and has no - working directory associated with it. If this is the case a - number of commands that require a working directory will be - disabled, such as linkgit:git-add[1] or linkgit:git-merge[1]. -+ -This setting is automatically guessed by linkgit:git-clone[1] or -linkgit:git-init[1] when the repository was created. By default a -repository that ends in "/.git" is assumed to be not bare (bare = -false), while all other repositories are assumed to be bare (bare -= true). - -core.worktree:: - Set the path to the root of the working tree. - If `GIT_COMMON_DIR` environment variable is set, core.worktree - is ignored and not used for determining the root of working tree. - This can be overridden by the `GIT_WORK_TREE` environment - variable and the `--work-tree` command-line option. - The value can be an absolute path or relative to the path to - the .git directory, which is either specified by --git-dir - or GIT_DIR, or automatically discovered. - If --git-dir or GIT_DIR is specified but none of - --work-tree, GIT_WORK_TREE and core.worktree is specified, - the current working directory is regarded as the top level - of your working tree. -+ -Note that this variable is honored even when set in a configuration -file in a ".git" subdirectory of a directory and its value differs -from the latter directory (e.g. "/path/to/.git/config" has -core.worktree set to "/different/path"), which is most likely a -misconfiguration. Running Git commands in the "/path/to" directory will -still use "/different/path" as the root of the work tree and can cause -confusion unless you know what you are doing (e.g. you are creating a -read-only snapshot of the same index to a location different from the -repository's usual working tree). - -core.logAllRefUpdates:: - Enable the reflog. Updates to a ref <ref> is logged to the file - "`$GIT_DIR/logs/<ref>`", by appending the new and old - SHA-1, the date/time and the reason of the update, but - only when the file exists. If this configuration - variable is set to `true`, missing "`$GIT_DIR/logs/<ref>`" - file is automatically created for branch heads (i.e. under - `refs/heads/`), remote refs (i.e. under `refs/remotes/`), - note refs (i.e. under `refs/notes/`), and the symbolic ref `HEAD`. - If it is set to `always`, then a missing reflog is automatically - created for any ref under `refs/`. -+ -This information can be used to determine what commit -was the tip of a branch "2 days ago". -+ -This value is true by default in a repository that has -a working directory associated with it, and false by -default in a bare repository. - -core.repositoryFormatVersion:: - Internal variable identifying the repository format and layout - version. - -core.sharedRepository:: - When 'group' (or 'true'), the repository is made shareable between - several users in a group (making sure all the files and objects are - group-writable). When 'all' (or 'world' or 'everybody'), the - repository will be readable by all users, additionally to being - group-shareable. When 'umask' (or 'false'), Git will use permissions - reported by umask(2). When '0xxx', where '0xxx' is an octal number, - files in the repository will have this mode value. '0xxx' will override - user's umask value (whereas the other options will only override - requested parts of the user's umask value). Examples: '0660' will make - the repo read/write-able for the owner and group, but inaccessible to - others (equivalent to 'group' unless umask is e.g. '0022'). '0640' is a - repository that is group-readable but not group-writable. - See linkgit:git-init[1]. False by default. - -core.warnAmbiguousRefs:: - If true, Git will warn you if the ref name you passed it is ambiguous - and might match multiple refs in the repository. True by default. - -core.compression:: - An integer -1..9, indicating a default compression level. - -1 is the zlib default. 0 means no compression, - and 1..9 are various speed/size tradeoffs, 9 being slowest. - If set, this provides a default to other compression variables, - such as `core.looseCompression` and `pack.compression`. - -core.looseCompression:: - An integer -1..9, indicating the compression level for objects that - are not in a pack file. -1 is the zlib default. 0 means no - compression, and 1..9 are various speed/size tradeoffs, 9 being - slowest. If not set, defaults to core.compression. If that is - not set, defaults to 1 (best speed). - -core.packedGitWindowSize:: - Number of bytes of a pack file to map into memory in a - single mapping operation. Larger window sizes may allow - your system to process a smaller number of large pack files - more quickly. Smaller window sizes will negatively affect - performance due to increased calls to the operating system's - memory manager, but may improve performance when accessing - a large number of large pack files. -+ -Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32 -MiB on 32 bit platforms and 1 GiB on 64 bit platforms. This should -be reasonable for all users/operating systems. You probably do -not need to adjust this value. -+ -Common unit suffixes of 'k', 'm', or 'g' are supported. - -core.packedGitLimit:: - Maximum number of bytes to map simultaneously into memory - from pack files. If Git needs to access more than this many - bytes at once to complete an operation it will unmap existing - regions to reclaim virtual address space within the process. -+ -Default is 256 MiB on 32 bit platforms and 32 TiB (effectively -unlimited) on 64 bit platforms. -This should be reasonable for all users/operating systems, except on -the largest projects. You probably do not need to adjust this value. -+ -Common unit suffixes of 'k', 'm', or 'g' are supported. - -core.deltaBaseCacheLimit:: - Maximum number of bytes to reserve for caching base objects - that may be referenced by multiple deltified objects. By storing the - entire decompressed base objects in a cache Git is able - to avoid unpacking and decompressing frequently used base - objects multiple times. -+ -Default is 96 MiB on all platforms. This should be reasonable -for all users/operating systems, except on the largest projects. -You probably do not need to adjust this value. -+ -Common unit suffixes of 'k', 'm', or 'g' are supported. - -core.bigFileThreshold:: - Files larger than this size are stored deflated, without - attempting delta compression. Storing large files without - delta compression avoids excessive memory usage, at the - slight expense of increased disk usage. Additionally files - larger than this size are always treated as binary. -+ -Default is 512 MiB on all platforms. This should be reasonable -for most projects as source code and other text files can still -be delta compressed, but larger binary media files won't be. -+ -Common unit suffixes of 'k', 'm', or 'g' are supported. - -core.excludesFile:: - Specifies the pathname to the file that contains patterns to - describe paths that are not meant to be tracked, in addition - to `.gitignore` (per-directory) and `.git/info/exclude`. - Defaults to `$XDG_CONFIG_HOME/git/ignore`. - If `$XDG_CONFIG_HOME` is either not set or empty, `$HOME/.config/git/ignore` - is used instead. See linkgit:gitignore[5]. - -core.askPass:: - Some commands (e.g. svn and http interfaces) that interactively - ask for a password can be told to use an external program given - via the value of this variable. Can be overridden by the `GIT_ASKPASS` - environment variable. If not set, fall back to the value of the - `SSH_ASKPASS` environment variable or, failing that, a simple password - prompt. The external program shall be given a suitable prompt as - command-line argument and write the password on its STDOUT. - -core.attributesFile:: - In addition to `.gitattributes` (per-directory) and - `.git/info/attributes`, Git looks into this file for attributes - (see linkgit:gitattributes[5]). Path expansions are made the same - way as for `core.excludesFile`. Its default value is - `$XDG_CONFIG_HOME/git/attributes`. If `$XDG_CONFIG_HOME` is either not - set or empty, `$HOME/.config/git/attributes` is used instead. - -core.hooksPath:: - By default Git will look for your hooks in the - `$GIT_DIR/hooks` directory. Set this to different path, - e.g. `/etc/git/hooks`, and Git will try to find your hooks in - that directory, e.g. `/etc/git/hooks/pre-receive` instead of - in `$GIT_DIR/hooks/pre-receive`. -+ -The path can be either absolute or relative. A relative path is -taken as relative to the directory where the hooks are run (see -the "DESCRIPTION" section of linkgit:githooks[5]). -+ -This configuration variable is useful in cases where you'd like to -centrally configure your Git hooks instead of configuring them on a -per-repository basis, or as a more flexible and centralized -alternative to having an `init.templateDir` where you've changed -default hooks. - -core.editor:: - Commands such as `commit` and `tag` that let you edit - messages by launching an editor use the value of this - variable when it is set, and the environment variable - `GIT_EDITOR` is not set. See linkgit:git-var[1]. - -core.commentChar:: - Commands such as `commit` and `tag` that let you edit - messages consider a line that begins with this character - commented, and removes them after the editor returns - (default '#'). -+ -If set to "auto", `git-commit` would select a character that is not -the beginning character of any line in existing commit messages. - -core.filesRefLockTimeout:: - The length of time, in milliseconds, to retry when trying to - lock an individual reference. Value 0 means not to retry at - all; -1 means to try indefinitely. Default is 100 (i.e., - retry for 100ms). - -core.packedRefsTimeout:: - The length of time, in milliseconds, to retry when trying to - lock the `packed-refs` file. Value 0 means not to retry at - all; -1 means to try indefinitely. Default is 1000 (i.e., - retry for 1 second). - -core.pager:: - Text viewer for use by Git commands (e.g., 'less'). The value - is meant to be interpreted by the shell. The order of preference - is the `$GIT_PAGER` environment variable, then `core.pager` - configuration, then `$PAGER`, and then the default chosen at - compile time (usually 'less'). -+ -When the `LESS` environment variable is unset, Git sets it to `FRX` -(if `LESS` environment variable is set, Git does not change it at -all). If you want to selectively override Git's default setting -for `LESS`, you can set `core.pager` to e.g. `less -S`. This will -be passed to the shell by Git, which will translate the final -command to `LESS=FRX less -S`. The environment does not set the -`S` option but the command line does, instructing less to truncate -long lines. Similarly, setting `core.pager` to `less -+F` will -deactivate the `F` option specified by the environment from the -command-line, deactivating the "quit if one screen" behavior of -`less`. One can specifically activate some flags for particular -commands: for example, setting `pager.blame` to `less -S` enables -line truncation only for `git blame`. -+ -Likewise, when the `LV` environment variable is unset, Git sets it -to `-c`. You can override this setting by exporting `LV` with -another value or setting `core.pager` to `lv +c`. - -core.whitespace:: - A comma separated list of common whitespace problems to - notice. 'git diff' will use `color.diff.whitespace` to - highlight them, and 'git apply --whitespace=error' will - consider them as errors. You can prefix `-` to disable - any of them (e.g. `-trailing-space`): -+ -* `blank-at-eol` treats trailing whitespaces at the end of the line - as an error (enabled by default). -* `space-before-tab` treats a space character that appears immediately - before a tab character in the initial indent part of the line as an - error (enabled by default). -* `indent-with-non-tab` treats a line that is indented with space - characters instead of the equivalent tabs as an error (not enabled by - default). -* `tab-in-indent` treats a tab character in the initial indent part of - the line as an error (not enabled by default). -* `blank-at-eof` treats blank lines added at the end of file as an error - (enabled by default). -* `trailing-space` is a short-hand to cover both `blank-at-eol` and - `blank-at-eof`. -* `cr-at-eol` treats a carriage-return at the end of line as - part of the line terminator, i.e. with it, `trailing-space` - does not trigger if the character before such a carriage-return - is not a whitespace (not enabled by default). -* `tabwidth=<n>` tells how many character positions a tab occupies; this - is relevant for `indent-with-non-tab` and when Git fixes `tab-in-indent` - errors. The default tab width is 8. Allowed values are 1 to 63. - -core.fsyncObjectFiles:: - This boolean will enable 'fsync()' when writing object files. -+ -This is a total waste of time and effort on a filesystem that orders -data writes properly, but can be useful for filesystems that do not use -journalling (traditional UNIX filesystems) or that only journal metadata -and not file contents (OS X's HFS+, or Linux ext3 with "data=writeback"). - -core.preloadIndex:: - Enable parallel index preload for operations like 'git diff' -+ -This can speed up operations like 'git diff' and 'git status' especially -on filesystems like NFS that have weak caching semantics and thus -relatively high IO latencies. When enabled, Git will do the -index comparison to the filesystem data in parallel, allowing -overlapping IO's. Defaults to true. - -core.unsetenvvars:: - Windows-only: comma-separated list of environment variables' - names that need to be unset before spawning any other process. - Defaults to `PERL5LIB` to account for the fact that Git for - Windows insists on using its own Perl interpreter. - -core.createObject:: - You can set this to 'link', in which case a hardlink followed by - a delete of the source are used to make sure that object creation - will not overwrite existing objects. -+ -On some file system/operating system combinations, this is unreliable. -Set this config setting to 'rename' there; However, This will remove the -check that makes sure that existing object files will not get overwritten. - -core.notesRef:: - When showing commit messages, also show notes which are stored in - the given ref. The ref must be fully qualified. If the given - ref does not exist, it is not an error but means that no - notes should be printed. -+ -This setting defaults to "refs/notes/commits", and it can be overridden by -the `GIT_NOTES_REF` environment variable. See linkgit:git-notes[1]. - -core.commitGraph:: - If true, then git will read the commit-graph file (if it exists) - to parse the graph structure of commits. Defaults to false. See - linkgit:git-commit-graph[1] for more information. - -core.useReplaceRefs:: - If set to `false`, behave as if the `--no-replace-objects` - option was given on the command line. See linkgit:git[1] and - linkgit:git-replace[1] for more information. - -core.multiPackIndex:: - Use the multi-pack-index file to track multiple packfiles using a - single index. See link:technical/multi-pack-index.html[the - multi-pack-index design document]. - -core.sparseCheckout:: - Enable "sparse checkout" feature. See section "Sparse checkout" in - linkgit:git-read-tree[1] for more information. - -core.abbrev:: - Set the length object names are abbreviated to. If - unspecified or set to "auto", an appropriate value is - computed based on the approximate number of packed objects - in your repository, which hopefully is enough for - abbreviated object names to stay unique for some time. - The minimum length is 4. diff --git a/third_party/git/Documentation/config/credential.txt b/third_party/git/Documentation/config/credential.txt deleted file mode 100644 index 60fb3189e1..0000000000 --- a/third_party/git/Documentation/config/credential.txt +++ /dev/null @@ -1,26 +0,0 @@ -credential.helper:: - Specify an external helper to be called when a username or - password credential is needed; the helper may consult external - storage to avoid prompting the user for the credentials. Note - that multiple helpers may be defined. See linkgit:gitcredentials[7] - for details. - -credential.useHttpPath:: - When acquiring credentials, consider the "path" component of an http - or https URL to be important. Defaults to false. See - linkgit:gitcredentials[7] for more information. - -credential.username:: - If no username is set for a network authentication, use this username - by default. See credential.<context>.* below, and - linkgit:gitcredentials[7]. - -credential.<url>.*:: - Any of the credential.* options above can be applied selectively to - some credentials. For example "credential.https://example.com.username" - would set the default username only for https connections to - example.com. See linkgit:gitcredentials[7] for details on how URLs are - matched. - -credentialCache.ignoreSIGHUP:: - Tell git-credential-cache--daemon to ignore SIGHUP, instead of quitting. diff --git a/third_party/git/Documentation/config/diff.txt b/third_party/git/Documentation/config/diff.txt deleted file mode 100644 index 5afb5a2cbc..0000000000 --- a/third_party/git/Documentation/config/diff.txt +++ /dev/null @@ -1,231 +0,0 @@ -diff.autoRefreshIndex:: - When using 'git diff' to compare with work tree - files, do not consider stat-only change as changed. - Instead, silently run `git update-index --refresh` to - update the cached stat information for paths whose - contents in the work tree match the contents in the - index. This option defaults to true. Note that this - affects only 'git diff' Porcelain, and not lower level - 'diff' commands such as 'git diff-files'. - -diff.dirstat:: - A comma separated list of `--dirstat` parameters specifying the - default behavior of the `--dirstat` option to linkgit:git-diff[1] - and friends. The defaults can be overridden on the command line - (using `--dirstat=<param1,param2,...>`). The fallback defaults - (when not changed by `diff.dirstat`) are `changes,noncumulative,3`. - The following parameters are available: -+ --- -`changes`;; - Compute the dirstat numbers by counting the lines that have been - removed from the source, or added to the destination. This ignores - the amount of pure code movements within a file. In other words, - rearranging lines in a file is not counted as much as other changes. - This is the default behavior when no parameter is given. -`lines`;; - Compute the dirstat numbers by doing the regular line-based diff - analysis, and summing the removed/added line counts. (For binary - files, count 64-byte chunks instead, since binary files have no - natural concept of lines). This is a more expensive `--dirstat` - behavior than the `changes` behavior, but it does count rearranged - lines within a file as much as other changes. The resulting output - is consistent with what you get from the other `--*stat` options. -`files`;; - Compute the dirstat numbers by counting the number of files changed. - Each changed file counts equally in the dirstat analysis. This is - the computationally cheapest `--dirstat` behavior, since it does - not have to look at the file contents at all. -`cumulative`;; - Count changes in a child directory for the parent directory as well. - Note that when using `cumulative`, the sum of the percentages - reported may exceed 100%. The default (non-cumulative) behavior can - be specified with the `noncumulative` parameter. -<limit>;; - An integer parameter specifies a cut-off percent (3% by default). - Directories contributing less than this percentage of the changes - are not shown in the output. --- -+ -Example: The following will count changed files, while ignoring -directories with less than 10% of the total amount of changed files, -and accumulating child directory counts in the parent directories: -`files,10,cumulative`. - -diff.statGraphWidth:: - Limit the width of the graph part in --stat output. If set, applies - to all commands generating --stat output except format-patch. - -diff.context:: - Generate diffs with <n> lines of context instead of the default - of 3. This value is overridden by the -U option. - -diff.interHunkContext:: - Show the context between diff hunks, up to the specified number - of lines, thereby fusing the hunks that are close to each other. - This value serves as the default for the `--inter-hunk-context` - command line option. - -diff.external:: - If this config variable is set, diff generation is not - performed using the internal diff machinery, but using the - given command. Can be overridden with the `GIT_EXTERNAL_DIFF' - environment variable. The command is called with parameters - as described under "git Diffs" in linkgit:git[1]. Note: if - you want to use an external diff program only on a subset of - your files, you might want to use linkgit:gitattributes[5] instead. - -diff.ignoreSubmodules:: - Sets the default value of --ignore-submodules. Note that this - affects only 'git diff' Porcelain, and not lower level 'diff' - commands such as 'git diff-files'. 'git checkout' - and 'git switch' also honor - this setting when reporting uncommitted changes. Setting it to - 'all' disables the submodule summary normally shown by 'git commit' - and 'git status' when `status.submoduleSummary` is set unless it is - overridden by using the --ignore-submodules command-line option. - The 'git submodule' commands are not affected by this setting. - -diff.mnemonicPrefix:: - If set, 'git diff' uses a prefix pair that is different from the - standard "a/" and "b/" depending on what is being compared. When - this configuration is in effect, reverse diff output also swaps - the order of the prefixes: -`git diff`;; - compares the (i)ndex and the (w)ork tree; -`git diff HEAD`;; - compares a (c)ommit and the (w)ork tree; -`git diff --cached`;; - compares a (c)ommit and the (i)ndex; -`git diff HEAD:file1 file2`;; - compares an (o)bject and a (w)ork tree entity; -`git diff --no-index a b`;; - compares two non-git things (1) and (2). - -diff.noprefix:: - If set, 'git diff' does not show any source or destination prefix. - -diff.orderFile:: - File indicating how to order files within a diff. - See the '-O' option to linkgit:git-diff[1] for details. - If `diff.orderFile` is a relative pathname, it is treated as - relative to the top of the working tree. - -diff.renameLimit:: - The number of files to consider when performing the copy/rename - detection; equivalent to the 'git diff' option `-l`. This setting - has no effect if rename detection is turned off. - -diff.renames:: - Whether and how Git detects renames. If set to "false", - rename detection is disabled. If set to "true", basic rename - detection is enabled. If set to "copies" or "copy", Git will - detect copies, as well. Defaults to true. Note that this - affects only 'git diff' Porcelain like linkgit:git-diff[1] and - linkgit:git-log[1], and not lower level commands such as - linkgit:git-diff-files[1]. - -diff.suppressBlankEmpty:: - A boolean to inhibit the standard behavior of printing a space - before each empty output line. Defaults to false. - -diff.submodule:: - Specify the format in which differences in submodules are - 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" - when performing word-by-word difference calculations. Character - sequences that match the regular expression are "words", all other - characters are *ignorable* whitespace. - -diff.<driver>.command:: - The custom diff driver command. See linkgit:gitattributes[5] - for details. - -diff.<driver>.xfuncname:: - The regular expression that the diff driver should use to - recognize the hunk header. A built-in pattern may also be used. - See linkgit:gitattributes[5] for details. - -diff.<driver>.binary:: - Set this option to true to make the diff driver treat files as - binary. See linkgit:gitattributes[5] for details. - -diff.<driver>.textconv:: - The command that the diff driver should call to generate the - text-converted version of a file. The result of the - conversion is used to generate a human-readable diff. See - linkgit:gitattributes[5] for details. - -diff.<driver>.wordRegex:: - The regular expression that the diff driver should use to - split words in a line. See linkgit:gitattributes[5] for - details. - -diff.<driver>.cachetextconv:: - Set this option to true to make the diff driver cache the text - conversion outputs. See linkgit:gitattributes[5] for details. - -diff.tool:: - Controls which diff tool is used by linkgit:git-difftool[1]. - This variable overrides the value configured in `merge.tool`. - The list below shows the valid built-in values. - Any other value is treated as a custom diff tool and requires - that a corresponding difftool.<tool>.cmd variable is defined. - -diff.guitool:: - Controls which diff tool is used by linkgit:git-difftool[1] when - the -g/--gui flag is specified. This variable overrides the value - configured in `merge.guitool`. The list below shows the valid - built-in values. Any other value is treated as a custom diff tool - and requires that a corresponding difftool.<guitool>.cmd variable - is defined. - -include::../mergetools-diff.txt[] - -diff.indentHeuristic:: - Set this option to `true` to enable experimental heuristics - that shift diff hunk boundaries to make patches easier to read. - -diff.algorithm:: - Choose a diff algorithm. The variants are as follows: -+ --- -`default`, `myers`;; - The basic greedy diff algorithm. Currently, this is the default. -`minimal`;; - Spend extra time to make sure the smallest possible diff is - produced. -`patience`;; - Use "patience diff" algorithm when generating patches. -`histogram`;; - This algorithm extends the patience algorithm to "support - low-occurrence common elements". --- -+ - -diff.wsErrorHighlight:: - Highlight whitespace errors in the `context`, `old` or `new` - lines of the diff. Multiple values are separated by comma, - `none` resets previous values, `default` reset the list to - `new` and `all` is a shorthand for `old,new,context`. The - whitespace errors are colored with `color.diff.whitespace`. - The command line option `--ws-error-highlight=<kind>` - overrides this setting. - -diff.colorMoved:: - If set to either a valid `<mode>` or a true value, moved lines - in a diff are colored differently, for details of valid modes - see '--color-moved' in linkgit:git-diff[1]. If simply set to - true the default color mode will be used. When set to false, - moved lines are not colored. - -diff.colorMovedWS:: - When moved lines are colored using e.g. the `diff.colorMoved` setting, - this option controls the `<mode>` how spaces are treated - for details of valid modes see '--color-moved-ws' in linkgit:git-diff[1]. diff --git a/third_party/git/Documentation/config/difftool.txt b/third_party/git/Documentation/config/difftool.txt deleted file mode 100644 index 6762594480..0000000000 --- a/third_party/git/Documentation/config/difftool.txt +++ /dev/null @@ -1,14 +0,0 @@ -difftool.<tool>.path:: - Override the path for the given tool. This is useful in case - your tool is not in the PATH. - -difftool.<tool>.cmd:: - Specify the command to invoke the specified diff tool. - The specified command is evaluated in shell with the following - variables available: 'LOCAL' is set to the name of the temporary - file containing the contents of the diff pre-image and 'REMOTE' - is set to the name of the temporary file containing the contents - of the diff post-image. - -difftool.prompt:: - Prompt before each invocation of the diff tool. diff --git a/third_party/git/Documentation/config/fastimport.txt b/third_party/git/Documentation/config/fastimport.txt deleted file mode 100644 index c1166e330d..0000000000 --- a/third_party/git/Documentation/config/fastimport.txt +++ /dev/null @@ -1,8 +0,0 @@ -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. diff --git a/third_party/git/Documentation/config/fetch.txt b/third_party/git/Documentation/config/fetch.txt deleted file mode 100644 index ba890b5884..0000000000 --- a/third_party/git/Documentation/config/fetch.txt +++ /dev/null @@ -1,70 +0,0 @@ -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 - unconditionally recurse into submodules when set to true or to not - recurse at all when set to false. When set to 'on-demand' (the default - value), fetch and pull will only recurse into a populated submodule - when its superproject retrieves a commit that updates the submodule's - reference. - -fetch.fsckObjects:: - If it is set to true, git-fetch-pack will check all fetched - objects. See `transfer.fsckObjects` for what's - checked. Defaults to false. If not set, the value of - `transfer.fsckObjects` is used instead. - -fetch.fsck.<msg-id>:: - Acts like `fsck.<msg-id>`, but is used by - linkgit:git-fetch-pack[1] instead of linkgit:git-fsck[1]. See - the `fsck.<msg-id>` documentation for details. - -fetch.fsck.skipList:: - Acts like `fsck.skipList`, but is used by - linkgit:git-fetch-pack[1] instead of linkgit:git-fsck[1]. See - the `fsck.skipList` documentation for details. - -fetch.unpackLimit:: - If the number of objects fetched over the Git native - transfer is below this - limit, then the objects will be unpacked into loose object - files. However if the number of received objects equals or - exceeds this limit then the received pack will be stored as - a pack, after adding any missing delta bases. Storing the - pack from a push can make the push operation complete faster, - especially on slow filesystems. If not set, the value of - `transfer.unpackLimit` is used instead. - -fetch.prune:: - If true, fetch will automatically behave as if the `--prune` - option was given on the command line. See also `remote.<name>.prune` - and the PRUNING section of linkgit:git-fetch[1]. - -fetch.pruneTags:: - If true, fetch will automatically behave as if the - `refs/tags/*:refs/tags/*` refspec was provided when pruning, - if not set already. This allows for setting both this option - and `fetch.prune` to maintain a 1=1 mapping to upstream - refs. See also `remote.<name>.pruneTags` and the PRUNING - section of linkgit:git-fetch[1]. - -fetch.output:: - Control how ref update status is printed. Valid values are - `full` and `compact`. Default value is `full`. See section - OUTPUT in linkgit:git-fetch[1] for detail. - -fetch.negotiationAlgorithm:: - Control how information about the commits in the local repository is - sent when negotiating the contents of the packfile to be sent by the - server. Set to "skipping" to use an algorithm that skips commits in an - effort to converge faster, but may result in a larger-than-necessary - packfile; The default is "default" which instructs Git to use the default algorithm - that never skips commits (unless the server has acknowledged it or one - of its descendants). - Unknown values will cause 'git fetch' to error out. -+ -See also the `--negotiation-tip` option for linkgit:git-fetch[1]. - -fetch.showForcedUpdates:: - Set to false to enable `--no-show-forced-updates` in - linkgit:git-fetch[1] and linkgit:git-pull[1] commands. - Defaults to true. diff --git a/third_party/git/Documentation/config/filter.txt b/third_party/git/Documentation/config/filter.txt deleted file mode 100644 index 90dfe0ba5a..0000000000 --- a/third_party/git/Documentation/config/filter.txt +++ /dev/null @@ -1,9 +0,0 @@ -filter.<driver>.clean:: - The command which is used to convert the content of a worktree - file to a blob upon checkin. See linkgit:gitattributes[5] for - details. - -filter.<driver>.smudge:: - The command which is used to convert the content of a blob - object to a worktree file upon checkout. See - linkgit:gitattributes[5] for details. diff --git a/third_party/git/Documentation/config/fmt-merge-msg.txt b/third_party/git/Documentation/config/fmt-merge-msg.txt deleted file mode 100644 index c73cfa90b7..0000000000 --- a/third_party/git/Documentation/config/fmt-merge-msg.txt +++ /dev/null @@ -1,10 +0,0 @@ -merge.branchdesc:: - In addition to branch names, populate the log message with - the branch description text associated with them. Defaults - to false. - -merge.log:: - In addition to branch names, populate the log message with at - most the specified number of one-line descriptions from the - actual commits that are being merged. Defaults to false, and - true is a synonym for 20. diff --git a/third_party/git/Documentation/config/format.txt b/third_party/git/Documentation/config/format.txt deleted file mode 100644 index 414a5a8a9d..0000000000 --- a/third_party/git/Documentation/config/format.txt +++ /dev/null @@ -1,102 +0,0 @@ -format.attach:: - Enable multipart/mixed attachments as the default for - 'format-patch'. The value can also be a double quoted string - which will enable attachments as the default and set the - 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 - is more than one patch. It can be enabled or disabled for all - messages by setting it to "true" or "false". See --numbered - option in linkgit:git-format-patch[1]. - -format.headers:: - Additional email headers to include in a patch to be submitted - by mail. See linkgit:git-format-patch[1]. - -format.to:: -format.cc:: - Additional recipients to include in a patch to be submitted - by mail. See the --to and --cc options in - linkgit:git-format-patch[1]. - -format.subjectPrefix:: - The default for format-patch is to output files with the '[PATCH]' - subject prefix. Use this variable to change that prefix. - -format.signature:: - The default for format-patch is to output a signature containing - the Git version number. Use this variable to change that default. - Set this variable to the empty string ("") to suppress - signature generation. - -format.signatureFile:: - Works just like format.signature except the contents of the - file specified by this variable will be used as the signature. - -format.suffix:: - The default for format-patch is to output files with the suffix - `.patch`. Use this variable to change that suffix (make sure to - include the dot if you want it). - -format.pretty:: - The default pretty format for log/show/whatchanged command, - See linkgit:git-log[1], linkgit:git-show[1], - linkgit:git-whatchanged[1]. - -format.thread:: - The default threading style for 'git format-patch'. Can be - a boolean value, or `shallow` or `deep`. `shallow` threading - makes every mail a reply to the head of the series, - where the head is chosen from the cover letter, the - `--in-reply-to`, and the first patch mail, in this order. - `deep` threading makes every mail a reply to the previous one. - A true boolean value is the same as `shallow`, and a false - value disables threading. - -format.signOff:: - A boolean value which lets you enable the `-s/--signoff` option of - format-patch by default. *Note:* Adding the Signed-off-by: line to a - patch should be a conscious act and means that you certify you have - the rights to submit this work under the same open source license. - Please see the 'SubmittingPatches' document for further discussion. - -format.coverLetter:: - A boolean that controls whether to generate a cover-letter when - format-patch is invoked, but in addition can be set to "auto", to - generate a cover-letter only when there's more than one patch. - -format.outputDirectory:: - Set a custom directory to store the resulting files instead of the - current working directory. - -format.useAutoBase:: - A boolean value which lets you enable the `--base=auto` option of - format-patch by default. - -format.notes:: - Provides the default value for the `--notes` option to - format-patch. Accepts a boolean value, or a ref which specifies - where to get notes. If false, format-patch defaults to - `--no-notes`. If true, format-patch defaults to `--notes`. If - set to a non-boolean value, format-patch defaults to - `--notes=<ref>`, where `ref` is the non-boolean value. Defaults - to false. -+ -If one wishes to use the ref `ref/notes/true`, please use that literal -instead. -+ -This configuration can be specified multiple times in order to allow -multiple notes refs to be included. diff --git a/third_party/git/Documentation/config/fsck.txt b/third_party/git/Documentation/config/fsck.txt deleted file mode 100644 index 450e8c38e3..0000000000 --- a/third_party/git/Documentation/config/fsck.txt +++ /dev/null @@ -1,67 +0,0 @@ -fsck.<msg-id>:: - During fsck git may find issues with legacy data which - wouldn't be generated by current versions of git, and which - wouldn't be sent over the wire if `transfer.fsckObjects` was - set. This feature is intended to support working with legacy - repositories containing such data. -+ -Setting `fsck.<msg-id>` will be picked up by linkgit:git-fsck[1], but -to accept pushes of such data set `receive.fsck.<msg-id>` instead, or -to clone or fetch it set `fetch.fsck.<msg-id>`. -+ -The rest of the documentation discusses `fsck.*` for brevity, but the -same applies for the corresponding `receive.fsck.*` and -`fetch.<msg-id>.*`. variables. -+ -Unlike variables like `color.ui` and `core.editor` the -`receive.fsck.<msg-id>` and `fetch.fsck.<msg-id>` variables will not -fall back on the `fsck.<msg-id>` configuration if they aren't set. To -uniformly configure the same fsck settings in different circumstances -all three of them they must all set to the same values. -+ -When `fsck.<msg-id>` is set, errors can be switched to warnings and -vice versa by configuring the `fsck.<msg-id>` setting where the -`<msg-id>` is the fsck message ID and the value is one of `error`, -`warn` or `ignore`. For convenience, fsck prefixes the error/warning -with the message ID, e.g. "missingEmail: invalid author/committer -line - missing email" means that setting `fsck.missingEmail = ignore` -will hide that issue. -+ -In general, it is better to enumerate existing objects with problems -with `fsck.skipList`, instead of listing the kind of breakages these -problematic objects share to be ignored, as doing the latter will -allow new instances of the same breakages go unnoticed. -+ -Setting an unknown `fsck.<msg-id>` value will cause fsck to die, but -doing the same for `receive.fsck.<msg-id>` and `fetch.fsck.<msg-id>` -will only cause git to warn. - -fsck.skipList:: - The path to a list of object names (i.e. one unabbreviated SHA-1 per - line) that are known to be broken in a non-fatal way and should - be ignored. On versions of Git 2.20 and later comments ('#'), empty - lines, and any leading and trailing whitespace is ignored. Everything - but a SHA-1 per line will error out on older versions. -+ -This feature is useful when an established project should be accepted -despite early commits containing errors that can be safely ignored -such as invalid committer email addresses. Note: corrupt objects -cannot be skipped with this setting. -+ -Like `fsck.<msg-id>` this variable has corresponding -`receive.fsck.skipList` and `fetch.fsck.skipList` variants. -+ -Unlike variables like `color.ui` and `core.editor` the -`receive.fsck.skipList` and `fetch.fsck.skipList` variables will not -fall back on the `fsck.skipList` configuration if they aren't set. To -uniformly configure the same fsck settings in different circumstances -all three of them they must all set to the same values. -+ -Older versions of Git (before 2.20) documented that the object names -list should be sorted. This was never a requirement, the object names -could appear in any order, but when reading the list we tracked whether -the list was sorted for the purposes of an internal binary search -implementation, which could save itself some work with an already sorted -list. Unless you had a humongous list there was no reason to go out of -your way to pre-sort the list. After Git version 2.20 a hash implementation -is used instead, so there's now no reason to pre-sort the list. diff --git a/third_party/git/Documentation/config/gc.txt b/third_party/git/Documentation/config/gc.txt deleted file mode 100644 index 02b92b18b5..0000000000 --- a/third_party/git/Documentation/config/gc.txt +++ /dev/null @@ -1,136 +0,0 @@ -gc.aggressiveDepth:: - The depth parameter used in the delta compression - algorithm used by 'git gc --aggressive'. This defaults - to 50, which is the default for the `--depth` option when - `--aggressive` isn't in use. -+ -See the documentation for the `--depth` option in -linkgit:git-repack[1] for more details. - -gc.aggressiveWindow:: - The window size parameter used in the delta compression - algorithm used by 'git gc --aggressive'. This defaults - to 250, which is a much more aggressive window size than - the default `--window` of 10. -+ -See the documentation for the `--window` option in -linkgit:git-repack[1] for more details. - -gc.auto:: - When there are approximately more than this many loose - objects in the repository, `git gc --auto` will pack them. - Some Porcelain commands use this command to perform a - light-weight garbage collection from time to time. The - default value is 6700. -+ -Setting this to 0 disables not only automatic packing based on the -number of loose objects, but any other heuristic `git gc --auto` will -otherwise use to determine if there's work to do, such as -`gc.autoPackLimit`. - -gc.autoPackLimit:: - When there are more than this many packs that are not - marked with `*.keep` file in the repository, `git gc - --auto` consolidates them into one larger pack. The - default value is 50. Setting this to 0 disables it. - Setting `gc.auto` to 0 will also disable this. -+ -See the `gc.bigPackThreshold` configuration variable below. When in -use, it'll affect how the auto pack limit works. - -gc.autoDetach:: - Make `git gc --auto` return immediately and run in background - if the system supports it. Default is true. - -gc.bigPackThreshold:: - If non-zero, all packs larger than this limit are kept when - `git gc` is run. This is very similar to `--keep-base-pack` - except that all packs that meet the threshold are kept, not - just the base pack. Defaults to zero. Common unit suffixes of - 'k', 'm', or 'g' are supported. -+ -Note that if the number of kept packs is more than gc.autoPackLimit, -this configuration variable is ignored, all packs except the base pack -will be repacked. After this the number of packs should go below -gc.autoPackLimit and gc.bigPackThreshold should be respected again. -+ -If the amount of memory estimated for `git repack` to run smoothly is -not available and `gc.bigPackThreshold` is not set, the largest pack -will also be excluded (this is the equivalent of running `git gc` with -`--keep-base-pack`). - -gc.writeCommitGraph:: - If true, then gc will rewrite the commit-graph file when - linkgit:git-gc[1] is run. When using `git gc --auto` - the commit-graph will be updated if housekeeping is - required. Default is false. See linkgit:git-commit-graph[1] - for details. - -gc.logExpiry:: - If the file gc.log exists, then `git gc --auto` will print - its content and exit with status zero instead of running - unless that file is more than 'gc.logExpiry' old. Default is - "1.day". See `gc.pruneExpire` for more ways to specify its - value. - -gc.packRefs:: - Running `git pack-refs` in a repository renders it - unclonable by Git versions prior to 1.5.1.2 over dumb - transports such as HTTP. This variable determines whether - 'git gc' runs `git pack-refs`. This can be set to `notbare` - to enable it within all non-bare repos or it can be set to a - boolean value. The default is `true`. - -gc.pruneExpire:: - When 'git gc' is run, it will call 'prune --expire 2.weeks.ago'. - Override the grace period with this config variable. The value - "now" may be used to disable this grace period and always prune - unreachable objects immediately, or "never" may be used to - suppress pruning. This feature helps prevent corruption when - 'git gc' runs concurrently with another process writing to the - repository; see the "NOTES" section of linkgit:git-gc[1]. - -gc.worktreePruneExpire:: - When 'git gc' is run, it calls - 'git worktree prune --expire 3.months.ago'. - This config variable can be used to set a different grace - period. The value "now" may be used to disable the grace - period and prune `$GIT_DIR/worktrees` immediately, or "never" - may be used to suppress pruning. - -gc.reflogExpire:: -gc.<pattern>.reflogExpire:: - 'git reflog expire' removes reflog entries older than - this time; defaults to 90 days. The value "now" expires all - entries immediately, and "never" suppresses expiration - altogether. With "<pattern>" (e.g. - "refs/stash") in the middle the setting applies only to - the refs that match the <pattern>. - -gc.reflogExpireUnreachable:: -gc.<pattern>.reflogExpireUnreachable:: - 'git reflog expire' removes reflog entries older than - this time and are not reachable from the current tip; - defaults to 30 days. The value "now" expires all entries - immediately, and "never" suppresses expiration altogether. - With "<pattern>" (e.g. "refs/stash") - in the middle, the setting applies only to the refs that - match the <pattern>. -+ -These types of entries are generally created as a result of using `git -commit --amend` or `git rebase` and are the commits prior to the amend -or rebase occurring. Since these changes are not part of the current -project most users will want to expire them sooner, which is why the -default is more aggressive than `gc.reflogExpire`. - -gc.rerereResolved:: - Records of conflicted merge you resolved earlier are - kept for this many days when 'git rerere gc' is run. - You can also use more human-readable "1.month.ago", etc. - The default is 60 days. See linkgit:git-rerere[1]. - -gc.rerereUnresolved:: - Records of conflicted merge you have not resolved are - kept for this many days when 'git rerere gc' is run. - You can also use more human-readable "1.month.ago", etc. - The default is 15 days. See linkgit:git-rerere[1]. diff --git a/third_party/git/Documentation/config/gitcvs.txt b/third_party/git/Documentation/config/gitcvs.txt deleted file mode 100644 index 02da427fd9..0000000000 --- a/third_party/git/Documentation/config/gitcvs.txt +++ /dev/null @@ -1,67 +0,0 @@ -gitcvs.commitMsgAnnotation:: - Append this string to each commit message. Set to empty string - to disable this feature. Defaults to "via git-CVS emulator". - -gitcvs.enabled:: - Whether the CVS server interface is enabled for this repository. - See linkgit:git-cvsserver[1]. - -gitcvs.logFile:: - Path to a log file where the CVS server interface well... logs - various stuff. See linkgit:git-cvsserver[1]. - -gitcvs.usecrlfattr:: - If true, the server will look up the end-of-line conversion - attributes for files to determine the `-k` modes to use. If - the attributes force Git to treat a file as text, - the `-k` mode will be left blank so CVS clients will - treat it as text. If they suppress text conversion, the file - will be set with '-kb' mode, which suppresses any newline munging - the client might otherwise do. If the attributes do not allow - the file type to be determined, then `gitcvs.allBinary` is - used. See linkgit:gitattributes[5]. - -gitcvs.allBinary:: - This is used if `gitcvs.usecrlfattr` does not resolve - the correct '-kb' mode to use. If true, all - unresolved files are sent to the client in - mode '-kb'. This causes the client to treat them - as binary files, which suppresses any newline munging it - otherwise might do. Alternatively, if it is set to "guess", - then the contents of the file are examined to decide if - it is binary, similar to `core.autocrlf`. - -gitcvs.dbName:: - Database used by git-cvsserver to cache revision information - derived from the Git repository. The exact meaning depends on the - used database driver, for SQLite (which is the default driver) this - is a filename. Supports variable substitution (see - linkgit:git-cvsserver[1] for details). May not contain semicolons (`;`). - Default: '%Ggitcvs.%m.sqlite' - -gitcvs.dbDriver:: - Used Perl DBI driver. You can specify any available driver - for this here, but it might not work. git-cvsserver is tested - with 'DBD::SQLite', reported to work with 'DBD::Pg', and - reported *not* to work with 'DBD::mysql'. Experimental feature. - May not contain double colons (`:`). Default: 'SQLite'. - See linkgit:git-cvsserver[1]. - -gitcvs.dbUser, gitcvs.dbPass:: - Database user and password. Only useful if setting `gitcvs.dbDriver`, - since SQLite has no concept of database users and/or passwords. - 'gitcvs.dbUser' supports variable substitution (see - linkgit:git-cvsserver[1] for details). - -gitcvs.dbTableNamePrefix:: - Database table name prefix. Prepended to the names of any - database tables used, allowing a single database to be used - for several repositories. Supports variable substitution (see - linkgit:git-cvsserver[1] for details). Any non-alphabetic - characters will be replaced with underscores. - -All gitcvs variables except for `gitcvs.usecrlfattr` and -`gitcvs.allBinary` can also be specified as -'gitcvs.<access_method>.<varname>' (where 'access_method' -is one of "ext" and "pserver") to make them apply only for the given -access method. diff --git a/third_party/git/Documentation/config/gitweb.txt b/third_party/git/Documentation/config/gitweb.txt deleted file mode 100644 index 1b51475108..0000000000 --- a/third_party/git/Documentation/config/gitweb.txt +++ /dev/null @@ -1,16 +0,0 @@ -gitweb.category:: -gitweb.description:: -gitweb.owner:: -gitweb.url:: - See linkgit:gitweb[1] for description. - -gitweb.avatar:: -gitweb.blame:: -gitweb.grep:: -gitweb.highlight:: -gitweb.patches:: -gitweb.pickaxe:: -gitweb.remote_heads:: -gitweb.showSizes:: -gitweb.snapshot:: - See linkgit:gitweb.conf[5] for description. diff --git a/third_party/git/Documentation/config/gpg.txt b/third_party/git/Documentation/config/gpg.txt deleted file mode 100644 index cce2c89245..0000000000 --- a/third_party/git/Documentation/config/gpg.txt +++ /dev/null @@ -1,20 +0,0 @@ -gpg.program:: - Use this custom program instead of "`gpg`" found on `$PATH` when - making or verifying a PGP signature. The program must support the - same command-line interface as GPG, namely, to verify a detached - signature, "`gpg --verify $signature - <$file`" is run, and the - program is expected to signal a good signature by exiting with - code 0, and to generate an ASCII-armored detached signature, the - standard input of "`gpg -bsau $key`" is fed with the contents to be - signed, and the program is expected to send the result to its - standard output. - -gpg.format:: - Specifies which key format to use when signing with `--gpg-sign`. - Default is "openpgp" and another possible value is "x509". - -gpg.<format>.program:: - Use this to customize the program used for the signing format you - chose. (see `gpg.program` and `gpg.format`) `gpg.program` can still - be used as a legacy synonym for `gpg.openpgp.program`. The default - value for `gpg.x509.program` is "gpgsm". diff --git a/third_party/git/Documentation/config/grep.txt b/third_party/git/Documentation/config/grep.txt deleted file mode 100644 index 44abe45a7c..0000000000 --- a/third_party/git/Documentation/config/grep.txt +++ /dev/null @@ -1,24 +0,0 @@ -grep.lineNumber:: - If set to true, enable `-n` option by default. - -grep.column:: - If set to true, enable the `--column` option by default. - -grep.patternType:: - Set the default matching behavior. Using a value of 'basic', 'extended', - 'fixed', or 'perl' will enable the `--basic-regexp`, `--extended-regexp`, - `--fixed-strings`, or `--perl-regexp` option accordingly, while the - value 'default' will return to the default matching behavior. - -grep.extendedRegexp:: - If set to true, enable `--extended-regexp` option by default. This - option is ignored when the `grep.patternType` option is set to a value - other than 'default'. - -grep.threads:: - Number of grep worker threads to use. - See `grep.threads` in linkgit:git-grep[1] for more information. - -grep.fallbackToNoIndex:: - If set to true, fall back to git grep --no-index if git grep - is executed outside of a git repository. Defaults to false. diff --git a/third_party/git/Documentation/config/gui.txt b/third_party/git/Documentation/config/gui.txt deleted file mode 100644 index d30831a130..0000000000 --- a/third_party/git/Documentation/config/gui.txt +++ /dev/null @@ -1,57 +0,0 @@ -gui.commitMsgWidth:: - Defines how wide the commit message window is in the - linkgit:git-gui[1]. "75" is the default. - -gui.diffContext:: - Specifies how many context lines should be used in calls to diff - made by the linkgit:git-gui[1]. The default is "5". - -gui.displayUntracked:: - Determines if linkgit:git-gui[1] shows untracked files - in the file list. The default is "true". - -gui.encoding:: - Specifies the default encoding to use for displaying of - file contents in linkgit:git-gui[1] and linkgit:gitk[1]. - It can be overridden by setting the 'encoding' attribute - for relevant files (see linkgit:gitattributes[5]). - If this option is not set, the tools default to the - locale encoding. - -gui.matchTrackingBranch:: - Determines if new branches created with linkgit:git-gui[1] should - default to tracking remote branches with matching names or - not. Default: "false". - -gui.newBranchTemplate:: - Is used as suggested name when creating new branches using the - linkgit:git-gui[1]. - -gui.pruneDuringFetch:: - "true" if linkgit:git-gui[1] should prune remote-tracking branches when - performing a fetch. The default value is "false". - -gui.trustmtime:: - Determines if linkgit:git-gui[1] should trust the file modification - timestamp or not. By default the timestamps are not trusted. - -gui.spellingDictionary:: - Specifies the dictionary used for spell checking commit messages in - the linkgit:git-gui[1]. When set to "none" spell checking is turned - off. - -gui.fastCopyBlame:: - If true, 'git gui blame' uses `-C` instead of `-C -C` for original - location detection. It makes blame significantly faster on huge - repositories at the expense of less thorough copy detection. - -gui.copyBlameThreshold:: - Specifies the threshold to use in 'git gui blame' original location - detection, measured in alphanumeric characters. See the - linkgit:git-blame[1] manual for more information on copy detection. - -gui.blamehistoryctx:: - Specifies the radius of history context in days to show in - linkgit:gitk[1] for the selected commit, when the `Show History - Context` menu item is invoked from 'git gui blame'. If this - variable is set to zero, the whole history is shown. diff --git a/third_party/git/Documentation/config/guitool.txt b/third_party/git/Documentation/config/guitool.txt deleted file mode 100644 index 43fb9466ff..0000000000 --- a/third_party/git/Documentation/config/guitool.txt +++ /dev/null @@ -1,50 +0,0 @@ -guitool.<name>.cmd:: - Specifies the shell command line to execute when the corresponding item - of the linkgit:git-gui[1] `Tools` menu is invoked. This option is - mandatory for every tool. The command is executed from the root of - the working directory, and in the environment it receives the name of - the tool as `GIT_GUITOOL`, the name of the currently selected file as - 'FILENAME', and the name of the current branch as 'CUR_BRANCH' (if - the head is detached, 'CUR_BRANCH' is empty). - -guitool.<name>.needsFile:: - Run the tool only if a diff is selected in the GUI. It guarantees - that 'FILENAME' is not empty. - -guitool.<name>.noConsole:: - Run the command silently, without creating a window to display its - output. - -guitool.<name>.noRescan:: - Don't rescan the working directory for changes after the tool - finishes execution. - -guitool.<name>.confirm:: - Show a confirmation dialog before actually running the tool. - -guitool.<name>.argPrompt:: - Request a string argument from the user, and pass it to the tool - through the `ARGS` environment variable. Since requesting an - argument implies confirmation, the 'confirm' option has no effect - if this is enabled. If the option is set to 'true', 'yes', or '1', - the dialog uses a built-in generic prompt; otherwise the exact - value of the variable is used. - -guitool.<name>.revPrompt:: - Request a single valid revision from the user, and set the - `REVISION` environment variable. In other aspects this option - is similar to 'argPrompt', and can be used together with it. - -guitool.<name>.revUnmerged:: - Show only unmerged branches in the 'revPrompt' subdialog. - This is useful for tools similar to merge or rebase, but not - for things like checkout or reset. - -guitool.<name>.title:: - Specifies the title to use for the prompt dialog. The default - is the tool name. - -guitool.<name>.prompt:: - Specifies the general prompt string to display at the top of - the dialog, before subsections for 'argPrompt' and 'revPrompt'. - The default value includes the actual command. diff --git a/third_party/git/Documentation/config/help.txt b/third_party/git/Documentation/config/help.txt deleted file mode 100644 index 224bbf5a28..0000000000 --- a/third_party/git/Documentation/config/help.txt +++ /dev/null @@ -1,23 +0,0 @@ -help.browser:: - Specify the browser that will be used to display help in the - 'web' format. See linkgit:git-help[1]. - -help.format:: - Override the default help format used by linkgit:git-help[1]. - Values 'man', 'info', 'web' and 'html' are supported. 'man' is - the default. 'web' and 'html' are the same. - -help.autoCorrect:: - Automatically correct and execute mistyped commands after - waiting for the given number of deciseconds (0.1 sec). If more - than one command can be deduced from the entered text, nothing - will be executed. If the value of this option is negative, - the corrected command will be executed immediately. If the - value is 0 - the command will be just shown but not executed. - This is the default. - -help.htmlPath:: - Specify the path where the HTML documentation resides. File system paths - and URLs are supported. HTML pages will be prefixed with this path when - help is displayed in the 'web' format. This defaults to the documentation - path of your Git installation. diff --git a/third_party/git/Documentation/config/http.txt b/third_party/git/Documentation/config/http.txt deleted file mode 100644 index 5a32f5b0a5..0000000000 --- a/third_party/git/Documentation/config/http.txt +++ /dev/null @@ -1,280 +0,0 @@ -http.proxy:: - Override the HTTP proxy, normally configured using the 'http_proxy', - 'https_proxy', and 'all_proxy' environment variables (see `curl(1)`). In - addition to the syntax understood by curl, it is possible to specify a - proxy string with a user name but no password, in which case git will - attempt to acquire one in the same way it does for other credentials. See - linkgit:gitcredentials[7] for more information. The syntax thus is - '[protocol://][user[:password]@]proxyhost[:port]'. This can be overridden - on a per-remote basis; see remote.<name>.proxy - -http.proxyAuthMethod:: - Set the method with which to authenticate against the HTTP proxy. This - only takes effect if the configured proxy string contains a user name part - (i.e. is of the form 'user@host' or 'user@host:port'). This can be - overridden on a per-remote basis; see `remote.<name>.proxyAuthMethod`. - Both can be overridden by the `GIT_HTTP_PROXY_AUTHMETHOD` environment - variable. Possible values are: -+ --- -* `anyauth` - Automatically pick a suitable authentication method. It is - assumed that the proxy answers an unauthenticated request with a 407 - status code and one or more Proxy-authenticate headers with supported - authentication methods. This is the default. -* `basic` - HTTP Basic authentication -* `digest` - HTTP Digest authentication; this prevents the password from being - transmitted to the proxy in clear text -* `negotiate` - GSS-Negotiate authentication (compare the --negotiate option - of `curl(1)`) -* `ntlm` - NTLM authentication (compare the --ntlm option of `curl(1)`) --- - -http.emptyAuth:: - Attempt authentication without seeking a username or password. This - can be used to attempt GSS-Negotiate authentication without specifying - 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 - headers. To allow overriding the settings inherited from the system - config, an empty value will reset the extra headers to the empty list. - -http.cookieFile:: - The pathname of a file containing previously stored cookie lines, - which should be used - in the Git http session, if they match the server. The file format - of the file to read cookies from should be plain HTTP headers or - the Netscape/Mozilla cookie file format (see `curl(1)`). - NOTE that the file specified with http.cookieFile is used only as - input unless http.saveCookies is set. - -http.saveCookies:: - If set, store cookies received during requests to the file specified by - http.cookieFile. Has no effect if http.cookieFile is unset. - -http.version:: - Use the specified HTTP protocol version when communicating with a server. - If you want to force the default. The available and default version depend - on libcurl. Actually the possible values of - this option are: - - - HTTP/2 - - HTTP/1.1 - -http.sslVersion:: - The SSL version to use when negotiating an SSL connection, if you - want to force the default. The available and default version - depend on whether libcurl was built against NSS or OpenSSL and the - particular configuration of the crypto library in use. Internally - this sets the 'CURLOPT_SSL_VERSION' option; see the libcurl - documentation for more details on the format of this option and - for the ssl version supported. Actually the possible values of - this option are: - - - sslv2 - - sslv3 - - tlsv1 - - tlsv1.0 - - tlsv1.1 - - tlsv1.2 - - tlsv1.3 - -+ -Can be overridden by the `GIT_SSL_VERSION` environment variable. -To force git to use libcurl's default ssl version and ignore any -explicit http.sslversion option, set `GIT_SSL_VERSION` to the -empty string. - -http.sslCipherList:: - A list of SSL ciphers to use when negotiating an SSL connection. - The available ciphers depend on whether libcurl was built against - NSS or OpenSSL and the particular configuration of the crypto - library in use. Internally this sets the 'CURLOPT_SSL_CIPHER_LIST' - option; see the libcurl documentation for more details on the format - of this list. -+ -Can be overridden by the `GIT_SSL_CIPHER_LIST` environment variable. -To force git to use libcurl's default cipher list and ignore any -explicit http.sslCipherList option, set `GIT_SSL_CIPHER_LIST` to the -empty string. - -http.sslVerify:: - Whether to verify the SSL certificate when fetching or pushing - over HTTPS. Defaults to true. Can be overridden by the - `GIT_SSL_NO_VERIFY` environment variable. - -http.sslCert:: - File containing the SSL certificate when fetching or pushing - over HTTPS. Can be overridden by the `GIT_SSL_CERT` environment - variable. - -http.sslKey:: - File containing the SSL private key when fetching or pushing - over HTTPS. Can be overridden by the `GIT_SSL_KEY` environment - variable. - -http.sslCertPasswordProtected:: - Enable Git's password prompt for the SSL certificate. Otherwise - OpenSSL will prompt the user, possibly many times, if the - certificate or private key is encrypted. Can be overridden by the - `GIT_SSL_CERT_PASSWORD_PROTECTED` environment variable. - -http.sslCAInfo:: - File containing the certificates to verify the peer with when - fetching or pushing over HTTPS. Can be overridden by the - `GIT_SSL_CAINFO` environment variable. - -http.sslCAPath:: - Path containing files with the CA certificates to verify the peer - with when fetching or pushing over HTTPS. Can be overridden - by the `GIT_SSL_CAPATH` environment variable. - -http.sslBackend:: - Name of the SSL backend to use (e.g. "openssl" or "schannel"). - This option is ignored if cURL lacks support for choosing the SSL - backend at runtime. - -http.schannelCheckRevoke:: - Used to enforce or disable certificate revocation checks in cURL - when http.sslBackend is set to "schannel". Defaults to `true` if - unset. Only necessary to disable this if Git consistently errors - and the message is about checking the revocation status of a - certificate. This option is ignored if cURL lacks support for - setting the relevant SSL option at runtime. - -http.schannelUseSSLCAInfo:: - As of cURL v7.60.0, the Secure Channel backend can use the - certificate bundle provided via `http.sslCAInfo`, but that would - override the Windows Certificate Store. Since this is not desirable - by default, Git will tell cURL not to use that bundle by default - when the `schannel` backend was configured via `http.sslBackend`, - unless `http.schannelUseSSLCAInfo` overrides this behavior. - -http.pinnedpubkey:: - Public key of the https service. It may either be the filename of - a PEM or DER encoded public key file or a string starting with - 'sha256//' followed by the base64 encoded sha256 hash of the - public key. See also libcurl 'CURLOPT_PINNEDPUBLICKEY'. git will - exit with an error if this option is set but not supported by - cURL. - -http.sslTry:: - Attempt to use AUTH SSL/TLS and encrypted data transfers - when connecting via regular FTP protocol. This might be needed - if the FTP server requires it for security reasons or you wish - to connect securely whenever remote FTP server supports it. - Default is false since it might trigger certificate verification - errors on misconfigured servers. - -http.maxRequests:: - How many HTTP requests to launch in parallel. Can be overridden - by the `GIT_HTTP_MAX_REQUESTS` environment variable. Default is 5. - -http.minSessions:: - The number of curl sessions (counted across slots) to be kept across - requests. They will not be ended with curl_easy_cleanup() until - http_cleanup() is invoked. If USE_CURL_MULTI is not defined, this - value will be capped at 1. Defaults to 1. - -http.postBuffer:: - Maximum size in bytes of the buffer used by smart HTTP - transports when POSTing data to the remote system. - For requests larger than this buffer size, HTTP/1.1 and - Transfer-Encoding: chunked is used to avoid creating a - massive pack file locally. Default is 1 MiB, which is - sufficient for most requests. - -http.lowSpeedLimit, http.lowSpeedTime:: - If the HTTP transfer speed is less than 'http.lowSpeedLimit' - for longer than 'http.lowSpeedTime' seconds, the transfer is aborted. - Can be overridden by the `GIT_HTTP_LOW_SPEED_LIMIT` and - `GIT_HTTP_LOW_SPEED_TIME` environment variables. - -http.noEPSV:: - A boolean which disables using of EPSV ftp command by curl. - This can helpful with some "poor" ftp servers which don't - support EPSV mode. Can be overridden by the `GIT_CURL_FTP_NO_EPSV` - environment variable. Default is false (curl will use EPSV). - -http.userAgent:: - The HTTP USER_AGENT string presented to an HTTP server. The default - value represents the version of the client Git such as git/1.7.1. - This option allows you to override this value to a more common value - such as Mozilla/4.0. This may be necessary, for instance, if - connecting through a firewall that restricts HTTP connections to a set - of common USER_AGENT strings (but not including those like git/1.7.1). - Can be overridden by the `GIT_HTTP_USER_AGENT` environment variable. - -http.followRedirects:: - Whether git should follow HTTP redirects. If set to `true`, git - will transparently follow any redirect issued by a server it - encounters. If set to `false`, git will treat all redirects as - errors. If set to `initial`, git will follow redirects only for - the initial request to a remote, but not for subsequent - follow-up HTTP requests. Since git uses the redirected URL as - the base for the follow-up requests, this is generally - sufficient. The default is `initial`. - -http.<url>.*:: - Any of the http.* options above can be applied selectively to some URLs. - For a config key to match a URL, each element of the config key is - compared to that of the URL, in the following order: -+ --- -. Scheme (e.g., `https` in `https://example.com/`). This field - must match exactly between the config key and the URL. - -. Host/domain name (e.g., `example.com` in `https://example.com/`). - This field must match between the config key and the URL. It is - possible to specify a `*` as part of the host name to match all subdomains - at this level. `https://*.example.com/` for example would match - `https://foo.example.com/`, but not `https://foo.bar.example.com/`. - -. Port number (e.g., `8080` in `http://example.com:8080/`). - This field must match exactly between the config key and the URL. - Omitted port numbers are automatically converted to the correct - default for the scheme before matching. - -. Path (e.g., `repo.git` in `https://example.com/repo.git`). The - path field of the config key must match the path field of the URL - either exactly or as a prefix of slash-delimited path elements. This means - a config key with path `foo/` matches URL path `foo/bar`. A prefix can only - match on a slash (`/`) boundary. Longer matches take precedence (so a config - key with path `foo/bar` is a better match to URL path `foo/bar` than a config - key with just path `foo/`). - -. User name (e.g., `user` in `https://user@example.com/repo.git`). If - the config key has a user name it must match the user name in the - URL exactly. If the config key does not have a user name, that - config key will match a URL with any user name (including none), - but at a lower precedence than a config key with a user name. --- -+ -The list above is ordered by decreasing precedence; a URL that matches -a config key's path is preferred to one that matches its user name. For example, -if the URL is `https://user@example.com/foo/bar` a config key match of -`https://example.com/foo` will be preferred over a config key match of -`https://user@example.com`. -+ -All URLs are normalized before attempting any matching (the password part, -if embedded in the URL, is always ignored for matching purposes) so that -equivalent URLs that are simply spelled differently will match properly. -Environment variable settings always override any matches. The URLs that are -matched against are those given directly to Git commands. This means any URLs -visited as a result of a redirection do not participate in matching. diff --git a/third_party/git/Documentation/config/i18n.txt b/third_party/git/Documentation/config/i18n.txt deleted file mode 100644 index cc25621731..0000000000 --- a/third_party/git/Documentation/config/i18n.txt +++ /dev/null @@ -1,10 +0,0 @@ -i18n.commitEncoding:: - Character encoding the commit messages are stored in; Git itself - does not care per se, but this information is necessary e.g. when - importing commits from emails or in the gitk graphical history - browser (and possibly at other places in the future or in other - porcelains). See e.g. linkgit:git-mailinfo[1]. Defaults to 'utf-8'. - -i18n.logOutputEncoding:: - Character encoding the commit messages are converted to when - running 'git log' and friends. diff --git a/third_party/git/Documentation/config/imap.txt b/third_party/git/Documentation/config/imap.txt deleted file mode 100644 index 06166fb5c0..0000000000 --- a/third_party/git/Documentation/config/imap.txt +++ /dev/null @@ -1,44 +0,0 @@ -imap.folder:: - The folder to drop the mails into, which is typically the Drafts - folder. For example: "INBOX.Drafts", "INBOX/Drafts" or - "[Gmail]/Drafts". Required. - -imap.tunnel:: - Command used to setup a tunnel to the IMAP server through which - commands will be piped instead of using a direct network connection - to the server. Required when imap.host is not set. - -imap.host:: - A URL identifying the server. Use an `imap://` prefix for non-secure - connections and an `imaps://` prefix for secure connections. - Ignored when imap.tunnel is set, but required otherwise. - -imap.user:: - The username to use when logging in to the server. - -imap.pass:: - The password to use when logging in to the server. - -imap.port:: - An integer port number to connect to on the server. - Defaults to 143 for imap:// hosts and 993 for imaps:// hosts. - Ignored when imap.tunnel is set. - -imap.sslverify:: - A boolean to enable/disable verification of the server certificate - used by the SSL/TLS connection. Default is `true`. Ignored when - imap.tunnel is set. - -imap.preformattedHTML:: - A boolean to enable/disable the use of html encoding when sending - a patch. An html encoded patch will be bracketed with <pre> - and have a content type of text/html. Ironically, enabling this - option causes Thunderbird to send the patch as a plain/text, - format=fixed email. Default is `false`. - -imap.authMethod:: - Specify authenticate method for authentication with IMAP server. - If Git was built with the NO_CURL option, or if your curl version is older - than 7.34.0, or if you're running git-imap-send with the `--no-curl` - option, the only supported method is 'CRAM-MD5'. If this is not set - then 'git imap-send' uses the basic IMAP plaintext LOGIN command. diff --git a/third_party/git/Documentation/config/index.txt b/third_party/git/Documentation/config/index.txt deleted file mode 100644 index f181503041..0000000000 --- a/third_party/git/Documentation/config/index.txt +++ /dev/null @@ -1,26 +0,0 @@ -index.recordEndOfIndexEntries:: - Specifies whether the index file should include an "End Of Index - Entry" section. This reduces index load time on multiprocessor - machines but produces a message "ignoring EOIE extension" when - reading the index using Git versions before 2.20. Defaults to - 'true' if index.threads has been explicitly enabled, 'false' - otherwise. - -index.recordOffsetTable:: - Specifies whether the index file should include an "Index Entry - Offset Table" section. This reduces index load time on - multiprocessor machines but produces a message "ignoring IEOT - extension" when reading the index using Git versions before 2.20. - Defaults to 'true' if index.threads has been explicitly enabled, - 'false' otherwise. - -index.threads:: - Specifies the number of threads to spawn when loading the index. - This is meant to reduce index load time on multiprocessor machines. - Specifying 0 or 'true' will cause Git to auto-detect the number of - CPU's and set the number of threads accordingly. Specifying 1 or - 'false' will disable multithreading. Defaults to 'true'. - -index.version:: - Specify the version with which new index files should be - initialized. This does not affect existing repositories. diff --git a/third_party/git/Documentation/config/init.txt b/third_party/git/Documentation/config/init.txt deleted file mode 100644 index 46fa8c6a08..0000000000 --- a/third_party/git/Documentation/config/init.txt +++ /dev/null @@ -1,3 +0,0 @@ -init.templateDir:: - Specify the directory from which templates will be copied. - (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].) diff --git a/third_party/git/Documentation/config/instaweb.txt b/third_party/git/Documentation/config/instaweb.txt deleted file mode 100644 index 50cb2f7d62..0000000000 --- a/third_party/git/Documentation/config/instaweb.txt +++ /dev/null @@ -1,20 +0,0 @@ -instaweb.browser:: - Specify the program that will be used to browse your working - repository in gitweb. See linkgit:git-instaweb[1]. - -instaweb.httpd:: - The HTTP daemon command-line to start gitweb on your working - repository. See linkgit:git-instaweb[1]. - -instaweb.local:: - If true the web server started by linkgit:git-instaweb[1] will - be bound to the local IP (127.0.0.1). - -instaweb.modulePath:: - The default module path for linkgit:git-instaweb[1] to use - instead of /usr/lib/apache2/modules. Only used if httpd - is Apache. - -instaweb.port:: - The port number to bind the gitweb httpd to. See - linkgit:git-instaweb[1]. diff --git a/third_party/git/Documentation/config/interactive.txt b/third_party/git/Documentation/config/interactive.txt deleted file mode 100644 index a2d3c7ec44..0000000000 --- a/third_party/git/Documentation/config/interactive.txt +++ /dev/null @@ -1,17 +0,0 @@ -interactive.singleKey:: - In interactive commands, allow the user to provide one-letter - input with a single key (i.e., without hitting enter). - Currently this is used by the `--patch` mode of - linkgit:git-add[1], linkgit:git-checkout[1], - linkgit:git-restore[1], linkgit:git-commit[1], - linkgit:git-reset[1], and linkgit:git-stash[1]. Note that this - setting is silently ignored if portable keystroke input - is not available; requires the Perl module Term::ReadKey. - -interactive.diffFilter:: - When an interactive command (such as `git add --patch`) shows - a colorized diff, git will pipe the diff through the shell - command defined by this configuration variable. The command may - mark up the diff further for human consumption, provided that it - retains a one-to-one correspondence with the lines in the - original diff. Defaults to disabled (no filtering). diff --git a/third_party/git/Documentation/config/log.txt b/third_party/git/Documentation/config/log.txt deleted file mode 100644 index e9e1e397f3..0000000000 --- a/third_party/git/Documentation/config/log.txt +++ /dev/null @@ -1,44 +0,0 @@ -log.abbrevCommit:: - If true, makes linkgit:git-log[1], linkgit:git-show[1], and - linkgit:git-whatchanged[1] assume `--abbrev-commit`. You may - override this option with `--no-abbrev-commit`. - -log.date:: - Set the default date-time mode for the 'log' command. - Setting a value for log.date is similar to using 'git log''s - `--date` option. See linkgit:git-log[1] for details. - -log.decorate:: - Print out the ref names of any commits that are shown by the log - command. If 'short' is specified, the ref name prefixes 'refs/heads/', - 'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is - specified, the full ref name (including prefix) will be printed. - If 'auto' is specified, then if the output is going to a terminal, - the ref names are shown as if 'short' were given, otherwise no ref - names are shown. This is the same as the `--decorate` option - of the `git log`. - -log.follow:: - If `true`, `git log` will act as if the `--follow` option was used when - a single <path> is given. This has the same limitations as `--follow`, - i.e. it cannot be used to follow multiple files and does not work well - on non-linear history. - -log.graphColors:: - A list of colors, separated by commas, that can be used to draw - history lines in `git log --graph`. - -log.showRoot:: - If true, the initial commit will be shown as a big creation event. - This is equivalent to a diff against an empty tree. - Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which - normally hide the root commit will now show it. True by default. - -log.showSignature:: - If true, makes linkgit:git-log[1], linkgit:git-show[1], and - linkgit:git-whatchanged[1] assume `--show-signature`. - -log.mailmap:: - If true, makes linkgit:git-log[1], linkgit:git-show[1], and - linkgit:git-whatchanged[1] assume `--use-mailmap`, otherwise - assume `--no-use-mailmap`. True by default. diff --git a/third_party/git/Documentation/config/mailinfo.txt b/third_party/git/Documentation/config/mailinfo.txt deleted file mode 100644 index 3854d4ae37..0000000000 --- a/third_party/git/Documentation/config/mailinfo.txt +++ /dev/null @@ -1,6 +0,0 @@ -mailinfo.scissors:: - If true, makes linkgit:git-mailinfo[1] (and therefore - linkgit:git-am[1]) act by default as if the --scissors option - was provided on the command-line. When active, this features - removes everything from the message body before a scissors - line (i.e. consisting mainly of ">8", "8<" and "-"). diff --git a/third_party/git/Documentation/config/mailmap.txt b/third_party/git/Documentation/config/mailmap.txt deleted file mode 100644 index 48cbc30722..0000000000 --- a/third_party/git/Documentation/config/mailmap.txt +++ /dev/null @@ -1,15 +0,0 @@ -mailmap.file:: - The location of an augmenting mailmap file. The default - mailmap, located in the root of the repository, is loaded - first, then the mailmap file pointed to by this variable. - The location of the mailmap file may be in a repository - subdirectory, or somewhere outside of the repository itself. - See linkgit:git-shortlog[1] and linkgit:git-blame[1]. - -mailmap.blob:: - Like `mailmap.file`, but consider the value as a reference to a - blob in the repository. If both `mailmap.file` and - `mailmap.blob` are given, both are parsed, with entries from - `mailmap.file` taking precedence. In a bare repository, this - defaults to `HEAD:.mailmap`. In a non-bare repository, it - defaults to empty. diff --git a/third_party/git/Documentation/config/man.txt b/third_party/git/Documentation/config/man.txt deleted file mode 100644 index a727d987a8..0000000000 --- a/third_party/git/Documentation/config/man.txt +++ /dev/null @@ -1,12 +0,0 @@ -man.viewer:: - Specify the programs that may be used to display help in the - 'man' format. See linkgit:git-help[1]. - -man.<tool>.cmd:: - Specify the command to invoke the specified man viewer. The - specified command is evaluated in shell with the man page - passed as argument. (See linkgit:git-help[1].) - -man.<tool>.path:: - Override the path for the given tool that may be used to - display help in the 'man' format. See linkgit:git-help[1]. diff --git a/third_party/git/Documentation/config/merge.txt b/third_party/git/Documentation/config/merge.txt deleted file mode 100644 index 6a313937f8..0000000000 --- a/third_party/git/Documentation/config/merge.txt +++ /dev/null @@ -1,106 +0,0 @@ -merge.conflictStyle:: - Specify the style in which conflicted hunks are written out to - working tree files upon merge. The default is "merge", which - shows a `<<<<<<<` conflict marker, changes made by one side, - a `=======` marker, changes made by the other side, and then - a `>>>>>>>` marker. An alternate style, "diff3", adds a `|||||||` - marker and the original text before the `=======` marker. - -merge.defaultToUpstream:: - If merge is called without any commit argument, merge the upstream - branches configured for the current branch by using their last - observed values stored in their remote-tracking branches. - The values of the `branch.<current branch>.merge` that name the - branches at the remote named by `branch.<current branch>.remote` - are consulted, and then they are mapped via `remote.<remote>.fetch` - to their corresponding remote-tracking branches, and the tips of - these tracking branches are merged. - -merge.ff:: - By default, Git does not create an extra merge commit when merging - a commit that is a descendant of the current commit. Instead, the - tip of the current branch is fast-forwarded. When set to `false`, - this variable tells Git to create an extra merge commit in such - a case (equivalent to giving the `--no-ff` option from the command - line). When set to `only`, only such fast-forward merges are - allowed (equivalent to giving the `--ff-only` option from the - command line). - -merge.verifySignatures:: - If true, this is equivalent to the --verify-signatures command - line option. See linkgit:git-merge[1] for details. - -include::fmt-merge-msg.txt[] - -merge.renameLimit:: - The number of files to consider when performing rename detection - during a merge; if not specified, defaults to the value of - diff.renameLimit. This setting has no effect if rename detection - is turned off. - -merge.renames:: - Whether Git detects renames. If set to "false", rename detection - is disabled. If set to "true", basic rename detection is enabled. - Defaults to the value of diff.renames. - -merge.directoryRenames:: - Whether Git detects directory renames, affecting what happens at - merge time to new files added to a directory on one side of - history when that directory was renamed on the other side of - history. If merge.directoryRenames is set to "false", directory - rename detection is disabled, meaning that such new files will be - left behind in the old directory. If set to "true", directory - rename detection is enabled, meaning that such new files will be - moved into the new directory. If set to "conflict", a conflict - will be reported for such paths. If merge.renames is false, - merge.directoryRenames is ignored and treated as false. Defaults - to "conflict". - -merge.renormalize:: - Tell Git that canonical representation of files in the - repository has changed over time (e.g. earlier commits record - text files with CRLF line endings, but recent ones use LF line - endings). In such a repository, Git can convert the data - recorded in commits to a canonical form before performing a - merge to reduce unnecessary conflicts. For more information, - see section "Merging branches with differing checkin/checkout - attributes" in linkgit:gitattributes[5]. - -merge.stat:: - Whether to print the diffstat between ORIG_HEAD and the merge result - at the end of the merge. True by default. - -merge.tool:: - Controls which merge tool is used by linkgit:git-mergetool[1]. - The list below shows the valid built-in values. - Any other value is treated as a custom merge tool and requires - that a corresponding mergetool.<tool>.cmd variable is defined. - -merge.guitool:: - Controls which merge tool is used by linkgit:git-mergetool[1] when the - -g/--gui flag is specified. The list below shows the valid built-in values. - Any other value is treated as a custom merge tool and requires that a - corresponding mergetool.<guitool>.cmd variable is defined. - -include::../mergetools-merge.txt[] - -merge.verbosity:: - Controls the amount of output shown by the recursive merge - strategy. Level 0 outputs nothing except a final error - message if conflicts were detected. Level 1 outputs only - conflicts, 2 outputs conflicts and file changes. Level 5 and - above outputs debugging information. The default is level 2. - Can be overridden by the `GIT_MERGE_VERBOSITY` environment variable. - -merge.<driver>.name:: - Defines a human-readable name for a custom low-level - merge driver. See linkgit:gitattributes[5] for details. - -merge.<driver>.driver:: - Defines the command that implements a custom low-level - merge driver. See linkgit:gitattributes[5] for details. - -merge.<driver>.recursive:: - Names a low-level merge driver to be used when - performing an internal merge between common ancestors. - See linkgit:gitattributes[5] for details. diff --git a/third_party/git/Documentation/config/mergetool.txt b/third_party/git/Documentation/config/mergetool.txt deleted file mode 100644 index 09ed31dbfa..0000000000 --- a/third_party/git/Documentation/config/mergetool.txt +++ /dev/null @@ -1,53 +0,0 @@ -mergetool.<tool>.path:: - Override the path for the given tool. This is useful in case - your tool is not in the PATH. - -mergetool.<tool>.cmd:: - Specify the command to invoke the specified merge tool. The - specified command is evaluated in shell with the following - variables available: 'BASE' is the name of a temporary file - containing the common base of the files to be merged, if available; - 'LOCAL' is the name of a temporary file containing the contents of - the file on the current branch; 'REMOTE' is the name of a temporary - file containing the contents of the file from the branch being - merged; 'MERGED' contains the name of the file to which the merge - tool should write the results of a successful merge. - -mergetool.<tool>.trustExitCode:: - For a custom merge command, specify whether the exit code of - the merge command can be used to determine whether the merge was - successful. If this is not set to true then the merge target file - timestamp is checked and the merge assumed to have been successful - if the file has been updated, otherwise the user is prompted to - indicate the success of the merge. - -mergetool.meld.hasOutput:: - Older versions of `meld` do not support the `--output` option. - Git will attempt to detect whether `meld` supports `--output` - by inspecting the output of `meld --help`. Configuring - `mergetool.meld.hasOutput` will make Git skip these checks and - use the configured value instead. Setting `mergetool.meld.hasOutput` - to `true` tells Git to unconditionally use the `--output` option, - and `false` avoids using `--output`. - -mergetool.keepBackup:: - After performing a merge, the original file with conflict markers - can be saved as a file with a `.orig` extension. If this variable - is set to `false` then this file is not preserved. Defaults to - `true` (i.e. keep the backup files). - -mergetool.keepTemporaries:: - When invoking a custom merge tool, Git uses a set of temporary - files to pass to the tool. If the tool returns an error and this - variable is set to `true`, then these temporary files will be - preserved, otherwise they will be removed after the tool has - exited. Defaults to `false`. - -mergetool.writeToTemp:: - Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of - conflicting files in the worktree by default. Git will attempt - to use a temporary directory for these files when set `true`. - Defaults to `false`. - -mergetool.prompt:: - Prompt before each invocation of the merge resolution program. diff --git a/third_party/git/Documentation/config/notes.txt b/third_party/git/Documentation/config/notes.txt deleted file mode 100644 index aeef56d49a..0000000000 --- a/third_party/git/Documentation/config/notes.txt +++ /dev/null @@ -1,59 +0,0 @@ -notes.mergeStrategy:: - Which merge strategy to choose by default when resolving notes - conflicts. Must be one of `manual`, `ours`, `theirs`, `union`, or - `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE STRATEGIES" - section of linkgit:git-notes[1] for more information on each strategy. - -notes.<name>.mergeStrategy:: - Which merge strategy to choose when doing a notes merge into - refs/notes/<name>. This overrides the more general - "notes.mergeStrategy". See the "NOTES MERGE STRATEGIES" section in - linkgit:git-notes[1] for more information on the available strategies. - -notes.displayRef:: - The (fully qualified) refname from which to show notes when - showing commit messages. The value of this variable can be set - to a glob, in which case notes from all matching refs will be - shown. You may also specify this configuration variable - several times. A warning will be issued for refs that do not - exist, but a glob that does not match any refs is silently - ignored. -+ -This setting can be overridden with the `GIT_NOTES_DISPLAY_REF` -environment variable, which must be a colon separated list of refs or -globs. -+ -The effective value of "core.notesRef" (possibly overridden by -GIT_NOTES_REF) is also implicitly added to the list of refs to be -displayed. - -notes.rewrite.<command>:: - When rewriting commits with <command> (currently `amend` or - `rebase`) and this variable is set to `true`, Git - automatically copies your notes from the original to the - rewritten commit. Defaults to `true`, but see - "notes.rewriteRef" below. - -notes.rewriteMode:: - When copying notes during a rewrite (see the - "notes.rewrite.<command>" option), determines what to do if - the target commit already has a note. Must be one of - `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`. - Defaults to `concatenate`. -+ -This setting can be overridden with the `GIT_NOTES_REWRITE_MODE` -environment variable. - -notes.rewriteRef:: - When copying notes during a rewrite, specifies the (fully - qualified) ref whose notes should be copied. The ref may be a - glob, in which case notes in all matching refs will be copied. - You may also specify this configuration several times. -+ -Does not have a default value; you must configure this variable to -enable note rewriting. Set it to `refs/notes/commits` to enable -rewriting for the default commit notes. -+ -This setting can be overridden with the `GIT_NOTES_REWRITE_REF` -environment variable, which must be a colon separated list of refs or -globs. diff --git a/third_party/git/Documentation/config/pack.txt b/third_party/git/Documentation/config/pack.txt deleted file mode 100644 index 9cdcfa7324..0000000000 --- a/third_party/git/Documentation/config/pack.txt +++ /dev/null @@ -1,127 +0,0 @@ -pack.window:: - The size of the window used by linkgit:git-pack-objects[1] when no - window size is given on the command line. Defaults to 10. - -pack.depth:: - The maximum delta depth used by linkgit:git-pack-objects[1] when no - maximum depth is given on the command line. Defaults to 50. - Maximum value is 4095. - -pack.windowMemory:: - The maximum size of memory that is consumed by each thread - in linkgit:git-pack-objects[1] for pack window memory when - no limit is given on the command line. The value can be - suffixed with "k", "m", or "g". When left unconfigured (or - set explicitly to 0), there will be no limit. - -pack.compression:: - An integer -1..9, indicating the compression level for objects - in a pack file. -1 is the zlib default. 0 means no - compression, and 1..9 are various speed/size tradeoffs, 9 being - slowest. If not set, defaults to core.compression. If that is - not set, defaults to -1, the zlib default, which is "a default - compromise between speed and compression (currently equivalent - to level 6)." -+ -Note that changing the compression level will not automatically recompress -all existing objects. You can force recompression by passing the -F option -to linkgit:git-repack[1]. - -pack.island:: - An extended regular expression configuring a set of delta - islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1] - for details. - -pack.islandCore:: - Specify an island name which gets to have its objects be - packed first. This creates a kind of pseudo-pack at the front - of one pack, so that the objects from the specified island are - hopefully faster to copy into any pack that should be served - to a user requesting these objects. In practice this means - that the island specified should likely correspond to what is - the most commonly cloned in the repo. See also "DELTA ISLANDS" - in linkgit:git-pack-objects[1]. - -pack.deltaCacheSize:: - The maximum memory in bytes used for caching deltas in - linkgit:git-pack-objects[1] before writing them out to a pack. - This cache is used to speed up the writing object phase by not - having to recompute the final delta result once the best match - for all objects is found. Repacking large repositories on machines - which are tight with memory might be badly impacted by this though, - especially if this cache pushes the system into swapping. - A value of 0 means no limit. The smallest size of 1 byte may be - used to virtually disable this cache. Defaults to 256 MiB. - -pack.deltaCacheLimit:: - The maximum size of a delta, that is cached in - linkgit:git-pack-objects[1]. This cache is used to speed up the - writing object phase by not having to recompute the final delta - result once the best match for all objects is found. - Defaults to 1000. Maximum value is 65535. - -pack.threads:: - Specifies the number of threads to spawn when searching for best - delta matches. This requires that linkgit:git-pack-objects[1] - be compiled with pthreads otherwise this option is ignored with a - warning. This is meant to reduce packing time on multiprocessor - machines. The required amount of memory for the delta search window - is however multiplied by the number of threads. - Specifying 0 will cause Git to auto-detect the number of CPU's - and set the number of threads accordingly. - -pack.indexVersion:: - Specify the default pack index version. Valid values are 1 for - legacy pack index used by Git versions prior to 1.5.2, and 2 for - the new pack index with capabilities for packs larger than 4 GB - as well as proper protection against the repacking of corrupted - packs. Version 2 is the default. Note that version 2 is enforced - and this config option ignored whenever the corresponding pack is - larger than 2 GB. -+ -If you have an old Git that does not understand the version 2 `*.idx` file, -cloning or fetching over a non native protocol (e.g. "http") -that will copy both `*.pack` file and corresponding `*.idx` file from the -other side may give you a repository that cannot be accessed with your -older version of Git. If the `*.pack` file is smaller than 2 GB, however, -you can use linkgit:git-index-pack[1] on the *.pack file to regenerate -the `*.idx` file. - -pack.packSizeLimit:: - The maximum size of a pack. This setting only affects - packing to a file when repacking, i.e. the git:// protocol - is unaffected. It can be overridden by the `--max-pack-size` - option of linkgit:git-repack[1]. Reaching this limit results - in the creation of multiple packfiles; which in turn prevents - bitmaps from being created. - The minimum size allowed is limited to 1 MiB. - The default is unlimited. - Common unit suffixes of 'k', 'm', or 'g' are - supported. - -pack.useBitmaps:: - When true, git will use pack bitmaps (if available) when packing - to stdout (e.g., during the server side of a fetch). Defaults to - true. You should not generally need to turn this off unless - you are debugging pack bitmaps. - -pack.useSparse:: - When true, git will default to using the '--sparse' option in - 'git pack-objects' when the '--revs' option is present. This - algorithm only walks trees that appear in paths that introduce new - objects. This can have significant performance benefits when - computing a pack to send a small change. However, it is possible - that extra objects are added to the pack-file if the included - commits contain certain types of direct renames. - -pack.writeBitmaps (deprecated):: - This is a deprecated synonym for `repack.writeBitmaps`. - -pack.writeBitmapHashCache:: - When true, git will include a "hash cache" section in the bitmap - index (if one is written). This cache can be used to feed git's - delta heuristics, potentially leading to better deltas between - bitmapped and non-bitmapped objects (e.g., when serving a fetch - between an older, bitmapped pack and objects that have been - pushed since the last gc). The downside is that it consumes 4 - bytes per object of disk space. Defaults to true. diff --git a/third_party/git/Documentation/config/pager.txt b/third_party/git/Documentation/config/pager.txt deleted file mode 100644 index d3731cf66c..0000000000 --- a/third_party/git/Documentation/config/pager.txt +++ /dev/null @@ -1,8 +0,0 @@ -pager.<cmd>:: - If the value is boolean, turns on or off pagination of the - output of a particular Git subcommand when writing to a tty. - Otherwise, turns on pagination for the subcommand using the - pager specified by the value of `pager.<cmd>`. If `--paginate` - or `--no-pager` is specified on the command line, it takes - precedence over this option. To disable pagination for all - commands, set `core.pager` or `GIT_PAGER` to `cat`. diff --git a/third_party/git/Documentation/config/pretty.txt b/third_party/git/Documentation/config/pretty.txt deleted file mode 100644 index 063c6b63d9..0000000000 --- a/third_party/git/Documentation/config/pretty.txt +++ /dev/null @@ -1,9 +0,0 @@ -pretty.<name>:: - Alias for a --pretty= format string, as specified in - linkgit:git-log[1]. Any aliases defined here can be used just - as the built-in pretty formats could. For example, - running `git config pretty.changelog "format:* %H %s"` - would cause the invocation `git log --pretty=changelog` - to be equivalent to running `git log "--pretty=format:* %H %s"`. - Note that an alias with the same name as a built-in format - will be silently ignored. diff --git a/third_party/git/Documentation/config/protocol.txt b/third_party/git/Documentation/config/protocol.txt deleted file mode 100644 index bfccc07491..0000000000 --- a/third_party/git/Documentation/config/protocol.txt +++ /dev/null @@ -1,64 +0,0 @@ -protocol.allow:: - If set, provide a user defined default policy for all protocols which - don't explicitly have a policy (`protocol.<name>.allow`). By default, - if unset, known-safe protocols (http, https, git, ssh, file) have a - default policy of `always`, known-dangerous protocols (ext) have a - default policy of `never`, and all other protocols have a default - policy of `user`. Supported policies: -+ --- - -* `always` - protocol is always able to be used. - -* `never` - protocol is never able to be used. - -* `user` - protocol is only able to be used when `GIT_PROTOCOL_FROM_USER` is - either unset or has a value of 1. This policy should be used when you want a - protocol to be directly usable by the user but don't want it used by commands which - execute clone/fetch/push commands without user input, e.g. recursive - submodule initialization. - --- - -protocol.<name>.allow:: - Set a policy to be used by protocol `<name>` with clone/fetch/push - commands. See `protocol.allow` above for the available policies. -+ -The protocol names currently used by git are: -+ --- - - `file`: any local file-based path (including `file://` URLs, - or local paths) - - - `git`: the anonymous git protocol over a direct TCP - connection (or proxy, if configured) - - - `ssh`: git over ssh (including `host:path` syntax, - `ssh://`, etc). - - - `http`: git over http, both "smart http" and "dumb http". - Note that this does _not_ include `https`; if you want to configure - both, you must do so individually. - - - any external helpers are named by their protocol (e.g., use - `hg` to allow the `git-remote-hg` helper) --- - -protocol.version:: - Experimental. If set, clients will attempt to communicate with a - server using the specified protocol version. If unset, no - attempt will be made by the client to communicate using a - particular protocol version, this results in protocol version 0 - being used. - Supported versions: -+ --- - -* `0` - the original wire protocol. - -* `1` - the original wire protocol with the addition of a version string - in the initial response from the server. - -* `2` - link:technical/protocol-v2.html[wire protocol version 2]. - --- diff --git a/third_party/git/Documentation/config/pull.txt b/third_party/git/Documentation/config/pull.txt deleted file mode 100644 index b87cab31b3..0000000000 --- a/third_party/git/Documentation/config/pull.txt +++ /dev/null @@ -1,36 +0,0 @@ -pull.ff:: - By default, Git does not create an extra merge commit when merging - a commit that is a descendant of the current commit. Instead, the - tip of the current branch is fast-forwarded. When set to `false`, - this variable tells Git to create an extra merge commit in such - a case (equivalent to giving the `--no-ff` option from the command - line). When set to `only`, only such fast-forward merges are - allowed (equivalent to giving the `--ff-only` option from the - command line). This setting overrides `merge.ff` when pulling. - -pull.rebase:: - When true, rebase branches on top of the fetched branch, instead - of merging the default branch from the default remote when "git - pull" is run. See "branch.<name>.rebase" for setting this on a - per-branch basis. -+ -When `merges`, pass the `--rebase-merges` option to 'git rebase' -so that the local merge commits are included in the rebase (see -linkgit:git-rebase[1] for details). -+ -When `preserve` (deprecated in favor of `merges`), also pass -`--preserve-merges` along to 'git rebase' so that locally committed merge -commits will not be flattened by running 'git pull'. -+ -When the value is `interactive`, the rebase is run in interactive mode. -+ -*NOTE*: this is a possibly dangerous operation; do *not* use -it unless you understand the implications (see linkgit:git-rebase[1] -for details). - -pull.octopus:: - The default merge strategy to use when pulling multiple branches - at once. - -pull.twohead:: - The default merge strategy to use when pulling a single branch. diff --git a/third_party/git/Documentation/config/push.txt b/third_party/git/Documentation/config/push.txt deleted file mode 100644 index 0a0e000569..0000000000 --- a/third_party/git/Documentation/config/push.txt +++ /dev/null @@ -1,113 +0,0 @@ -push.default:: - Defines the action `git push` should take if no refspec is - explicitly given. Different values are well-suited for - specific workflows; for instance, in a purely central workflow - (i.e. the fetch source is equal to the push destination), - `upstream` is probably what you want. Possible values are: -+ --- - -* `nothing` - do not push anything (error out) unless a refspec is - explicitly given. This is primarily meant for people who want to - avoid mistakes by always being explicit. - -* `current` - push the current branch to update a branch with the same - name on the receiving end. Works in both central and non-central - workflows. - -* `upstream` - push the current branch back to the branch whose - changes are usually integrated into the current branch (which is - called `@{upstream}`). This mode only makes sense if you are - pushing to the same repository you would normally pull from - (i.e. central workflow). - -* `tracking` - This is a deprecated synonym for `upstream`. - -* `simple` - in centralized workflow, work like `upstream` with an - added safety to refuse to push if the upstream branch's name is - different from the local one. -+ -When pushing to a remote that is different from the remote you normally -pull from, work as `current`. This is the safest option and is suited -for beginners. -+ -This mode has become the default in Git 2.0. - -* `matching` - push all branches having the same name on both ends. - This makes the repository you are pushing to remember the set of - branches that will be pushed out (e.g. if you always push 'maint' - and 'master' there and no other branches, the repository you push - to will have these two branches, and your local 'maint' and - 'master' will be pushed there). -+ -To use this mode effectively, you have to make sure _all_ the -branches you would push out are ready to be pushed out before -running 'git push', as the whole point of this mode is to allow you -to push all of the branches in one go. If you usually finish work -on only one branch and push out the result, while other branches are -unfinished, this mode is not for you. Also this mode is not -suitable for pushing into a shared central repository, as other -people may add new branches there, or update the tip of existing -branches outside your control. -+ -This used to be the default, but not since Git 2.0 (`simple` is the -new default). - --- - -push.followTags:: - If set to true enable `--follow-tags` option by default. You - may override this configuration at time of push by specifying - `--no-follow-tags`. - -push.gpgSign:: - May be set to a boolean value, or the string 'if-asked'. A true - value causes all pushes to be GPG signed, as if `--signed` is - passed to linkgit:git-push[1]. The string 'if-asked' causes - pushes to be signed if the server supports it, as if - `--signed=if-asked` is passed to 'git push'. A false value may - override a value from a lower-priority config file. An explicit - command-line flag always overrides this config option. - -push.pushOption:: - When no `--push-option=<option>` argument is given from the - command line, `git push` behaves as if each <value> of - this variable is given as `--push-option=<value>`. -+ -This is a multi-valued variable, and an empty value can be used in a -higher priority configuration file (e.g. `.git/config` in a -repository) to clear the values inherited from a lower priority -configuration files (e.g. `$HOME/.gitconfig`). -+ --- - -Example: - -/etc/gitconfig - push.pushoption = a - push.pushoption = b - -~/.gitconfig - push.pushoption = c - -repo/.git/config - push.pushoption = - push.pushoption = b - -This will result in only b (a and c are cleared). - --- - -push.recurseSubmodules:: - Make sure all submodule commits used by the revisions to be pushed - are available on a remote-tracking branch. If the value is 'check' - then Git will verify that all submodule commits that changed in the - revisions to be pushed are available on at least one remote of the - submodule. If any commits are missing, the push will be aborted and - exit with non-zero status. If the value is 'on-demand' then all - submodules that changed in the revisions to be pushed will be - pushed. If on-demand was not able to push all necessary revisions - it will also be aborted and exit with non-zero status. If the value - is 'no' then default behavior of ignoring submodules when pushing - is retained. You may override this configuration at time of push by - specifying '--recurse-submodules=check|on-demand|no'. diff --git a/third_party/git/Documentation/config/rebase.txt b/third_party/git/Documentation/config/rebase.txt deleted file mode 100644 index d98e32d812..0000000000 --- a/third_party/git/Documentation/config/rebase.txt +++ /dev/null @@ -1,64 +0,0 @@ -rebase.useBuiltin:: - Unused configuration variable. Used in Git versions 2.20 and - 2.21 as an escape hatch to enable the legacy shellscript - implementation of rebase. Now the built-in rewrite of it in C - is always used. Setting this will emit a warning, to alert any - remaining users that setting this now does nothing. - -rebase.stat:: - Whether to show a diffstat of what changed upstream since the last - rebase. False by default. - -rebase.autoSquash:: - If set to true enable `--autosquash` option by default. - -rebase.autoStash:: - When set to true, automatically create a temporary stash entry - before the operation begins, and apply it after the operation - ends. This means that you can run rebase on a dirty worktree. - However, use with care: the final stash application after a - successful rebase might result in non-trivial conflicts. - This option can be overridden by the `--no-autostash` and - `--autostash` options of linkgit:git-rebase[1]. - Defaults to false. - -rebase.missingCommitsCheck:: - If set to "warn", git rebase -i will print a warning if some - commits are removed (e.g. a line was deleted), however the - rebase will still proceed. If set to "error", it will print - the previous warning and stop the rebase, 'git rebase - --edit-todo' can then be used to correct the error. If set to - "ignore", no checking is done. - To drop a commit without warning or error, use the `drop` - command in the todo list. - Defaults to "ignore". - -rebase.instructionFormat:: - A format string, as specified in linkgit:git-log[1], to be used for the - todo list during an interactive rebase. The format will - automatically have the long commit hash prepended to the format. - -rebase.abbreviateCommands:: - If set to true, `git rebase` will use abbreviated command names in the - todo list resulting in something like this: -+ -------------------------------------------- - p deadbee The oneline of the commit - p fa1afe1 The oneline of the next commit - ... -------------------------------------------- -+ -instead of: -+ -------------------------------------------- - pick deadbee The oneline of the commit - pick fa1afe1 The oneline of the next commit - ... -------------------------------------------- -+ -Defaults to false. - -rebase.rescheduleFailedExec:: - Automatically reschedule `exec` commands that failed. This only makes - sense in interactive mode (or when an `--exec` option was provided). - This is the same as specifying the `--reschedule-failed-exec` option. diff --git a/third_party/git/Documentation/config/receive.txt b/third_party/git/Documentation/config/receive.txt deleted file mode 100644 index 65f78aac37..0000000000 --- a/third_party/git/Documentation/config/receive.txt +++ /dev/null @@ -1,123 +0,0 @@ -receive.advertiseAtomic:: - By default, git-receive-pack will advertise the atomic push - capability to its clients. If you don't want to advertise this - capability, set this variable to false. - -receive.advertisePushOptions:: - When set to true, git-receive-pack will advertise the push options - capability to its clients. False by default. - -receive.autogc:: - By default, git-receive-pack will run "git-gc --auto" after - receiving data from git-push and updating refs. You can stop - it by setting this variable to false. - -receive.certNonceSeed:: - By setting this variable to a string, `git receive-pack` - will accept a `git push --signed` and verifies it by using - a "nonce" protected by HMAC using this string as a secret - key. - -receive.certNonceSlop:: - When a `git push --signed` sent a push certificate with a - "nonce" that was issued by a receive-pack serving the same - repository within this many seconds, export the "nonce" - found in the certificate to `GIT_PUSH_CERT_NONCE` to the - hooks (instead of what the receive-pack asked the sending - side to include). This may allow writing checks in - `pre-receive` and `post-receive` a bit easier. Instead of - checking `GIT_PUSH_CERT_NONCE_SLOP` environment variable - that records by how many seconds the nonce is stale to - decide if they want to accept the certificate, they only - can check `GIT_PUSH_CERT_NONCE_STATUS` is `OK`. - -receive.fsckObjects:: - If it is set to true, git-receive-pack will check all received - objects. See `transfer.fsckObjects` for what's checked. - Defaults to false. If not set, the value of - `transfer.fsckObjects` is used instead. - -receive.fsck.<msg-id>:: - Acts like `fsck.<msg-id>`, but is used by - linkgit:git-receive-pack[1] instead of - linkgit:git-fsck[1]. See the `fsck.<msg-id>` documentation for - details. - -receive.fsck.skipList:: - Acts like `fsck.skipList`, but is used by - linkgit:git-receive-pack[1] instead of - linkgit:git-fsck[1]. See the `fsck.skipList` documentation for - details. - -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 - files. However if the number of received objects equals or - exceeds this limit then the received pack will be stored as - a pack, after adding any missing delta bases. Storing the - pack from a push can make the push operation complete faster, - 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. - -receive.denyDeleteCurrent:: - If set to true, git-receive-pack will deny a ref update that - deletes the currently checked out branch of a non-bare repository. - -receive.denyCurrentBranch:: - If set to true or "refuse", git-receive-pack will deny a ref update - to the currently checked out branch of a non-bare repository. - Such a push is potentially dangerous because it brings the HEAD - out of sync with the index and working tree. If set to "warn", - print a warning of such a push to stderr, but allow the push to - proceed. If set to false or "ignore", allow such pushes with no - message. Defaults to "refuse". -+ -Another option is "updateInstead" which will update the working -tree if pushing into the current branch. This option is -intended for synchronizing working directories when one side is not easily -accessible via interactive ssh (e.g. a live web site, hence the requirement -that the working directory be clean). This mode also comes in handy when -developing inside a VM to test and fix code on different Operating Systems. -+ -By default, "updateInstead" will refuse the push if the working tree or -the index have any difference from the HEAD, but the `push-to-checkout` -hook can be used to customize this. See linkgit:githooks[5]. - -receive.denyNonFastForwards:: - If set to true, git-receive-pack will deny a ref update which is - not a fast-forward. Use this to prevent such an update via a push, - even if that push is forced. This configuration variable is - set when initializing a shared repository. - -receive.hideRefs:: - This variable is the same as `transfer.hideRefs`, but applies - only to `receive-pack` (and so affects pushes, but not fetches). - An attempt to update or delete a hidden ref by `git push` is - rejected. - -receive.updateServerInfo:: - If set to true, git-receive-pack will run git-update-server-info - after receiving data from git-push and updating refs. - -receive.shallowUpdate:: - If set to true, .git/shallow can be updated when new refs - require new shallow roots. Otherwise those refs are rejected. diff --git a/third_party/git/Documentation/config/remote.txt b/third_party/git/Documentation/config/remote.txt deleted file mode 100644 index 6c4cad83a2..0000000000 --- a/third_party/git/Documentation/config/remote.txt +++ /dev/null @@ -1,78 +0,0 @@ -remote.pushDefault:: - The remote to push to by default. Overrides - `branch.<name>.remote` for all branches, and is overridden by - `branch.<name>.pushRemote` for specific branches. - -remote.<name>.url:: - The URL of a remote repository. See linkgit:git-fetch[1] or - linkgit:git-push[1]. - -remote.<name>.pushurl:: - The push URL of a remote repository. See linkgit:git-push[1]. - -remote.<name>.proxy:: - For remotes that require curl (http, https and ftp), the URL to - the proxy to use for that remote. Set to the empty string to - disable proxying for that remote. - -remote.<name>.proxyAuthMethod:: - For remotes that require curl (http, https and ftp), the method to use for - authenticating against the proxy in use (probably set in - `remote.<name>.proxy`). See `http.proxyAuthMethod`. - -remote.<name>.fetch:: - The default set of "refspec" for linkgit:git-fetch[1]. See - linkgit:git-fetch[1]. - -remote.<name>.push:: - The default set of "refspec" for linkgit:git-push[1]. See - linkgit:git-push[1]. - -remote.<name>.mirror:: - If true, pushing to this remote will automatically behave - as if the `--mirror` option was given on the command line. - -remote.<name>.skipDefaultUpdate:: - If true, this remote will be skipped by default when updating - using linkgit:git-fetch[1] or the `update` subcommand of - linkgit:git-remote[1]. - -remote.<name>.skipFetchAll:: - If true, this remote will be skipped by default when updating - using linkgit:git-fetch[1] or the `update` subcommand of - linkgit:git-remote[1]. - -remote.<name>.receivepack:: - The default program to execute on the remote side when pushing. See - option --receive-pack of linkgit:git-push[1]. - -remote.<name>.uploadpack:: - The default program to execute on the remote side when fetching. See - option --upload-pack of linkgit:git-fetch-pack[1]. - -remote.<name>.tagOpt:: - Setting this value to --no-tags disables automatic tag following when - fetching from remote <name>. Setting it to --tags will fetch every - tag from remote <name>, even if they are not reachable from remote - branch heads. Passing these flags directly to linkgit:git-fetch[1] can - override this setting. See options --tags and --no-tags of - linkgit:git-fetch[1]. - -remote.<name>.vcs:: - Setting this to a value <vcs> will cause Git to interact with - the remote with the git-remote-<vcs> helper. - -remote.<name>.prune:: - When set to true, fetching from this remote by default will also - remove any remote-tracking references that no longer exist on the - remote (as if the `--prune` option was given on the command line). - Overrides `fetch.prune` settings, if any. - -remote.<name>.pruneTags:: - When set to true, fetching from this remote by default will also - remove any local tags that no longer exist on the remote if pruning - is activated in general via `remote.<name>.prune`, `fetch.prune` or - `--prune`. Overrides `fetch.pruneTags` settings, if any. -+ -See also `remote.<name>.prune` and the PRUNING section of -linkgit:git-fetch[1]. diff --git a/third_party/git/Documentation/config/remotes.txt b/third_party/git/Documentation/config/remotes.txt deleted file mode 100644 index 4cfe03221e..0000000000 --- a/third_party/git/Documentation/config/remotes.txt +++ /dev/null @@ -1,3 +0,0 @@ -remotes.<group>:: - The list of remotes which are fetched by "git remote update - <group>". See linkgit:git-remote[1]. diff --git a/third_party/git/Documentation/config/repack.txt b/third_party/git/Documentation/config/repack.txt deleted file mode 100644 index 9c413e177e..0000000000 --- a/third_party/git/Documentation/config/repack.txt +++ /dev/null @@ -1,27 +0,0 @@ -repack.useDeltaBaseOffset:: - By default, linkgit:git-repack[1] creates packs that use - delta-base offset. If you need to share your repository with - Git older than version 1.4.4, either directly or via a dumb - protocol such as http, then you need to set this option to - "false" and repack. Access from old Git versions over the - native protocol are unaffected by this option. - -repack.packKeptObjects:: - If set to true, makes `git repack` act as if - `--pack-kept-objects` was passed. See linkgit:git-repack[1] for - details. Defaults to `false` normally, but `true` if a bitmap - index is being written (either via `--write-bitmap-index` or - `repack.writeBitmaps`). - -repack.useDeltaIslands:: - If set to true, makes `git repack` act as if `--delta-islands` - was passed. Defaults to `false`. - -repack.writeBitmaps:: - When true, git will write a bitmap index when packing all - objects to disk (e.g., when `git repack -a` is run). This - index can speed up the "counting objects" phase of subsequent - packs created for clones and fetches, at the cost of some disk - space and extra time spent on the initial repack. This has - no effect if multiple packfiles are created. - Defaults to true on bare repos, false otherwise. diff --git a/third_party/git/Documentation/config/rerere.txt b/third_party/git/Documentation/config/rerere.txt deleted file mode 100644 index 40abdf6a6b..0000000000 --- a/third_party/git/Documentation/config/rerere.txt +++ /dev/null @@ -1,12 +0,0 @@ -rerere.autoUpdate:: - When set to true, `git-rerere` updates the index with the - resulting contents after it cleanly resolves conflicts using - previously recorded resolution. Defaults to false. - -rerere.enabled:: - Activate recording of resolved conflicts, so that identical - conflict hunks can be resolved automatically, should they be - encountered again. By default, linkgit:git-rerere[1] is - enabled if there is an `rr-cache` directory under the - `$GIT_DIR`, e.g. if "rerere" was previously used in the - repository. diff --git a/third_party/git/Documentation/config/reset.txt b/third_party/git/Documentation/config/reset.txt deleted file mode 100644 index 63b7c45aac..0000000000 --- a/third_party/git/Documentation/config/reset.txt +++ /dev/null @@ -1,2 +0,0 @@ -reset.quiet:: - When set to true, 'git reset' will default to the '--quiet' option. diff --git a/third_party/git/Documentation/config/sendemail.txt b/third_party/git/Documentation/config/sendemail.txt deleted file mode 100644 index 0006faf800..0000000000 --- a/third_party/git/Documentation/config/sendemail.txt +++ /dev/null @@ -1,63 +0,0 @@ -sendemail.identity:: - A configuration identity. When given, causes values in the - 'sendemail.<identity>' subsection to take precedence over - values in the 'sendemail' section. The default identity is - the value of `sendemail.identity`. - -sendemail.smtpEncryption:: - See linkgit:git-send-email[1] for description. Note that this - setting is not subject to the 'identity' mechanism. - -sendemail.smtpssl (deprecated):: - Deprecated alias for 'sendemail.smtpEncryption = ssl'. - -sendemail.smtpsslcertpath:: - Path to ca-certificates (either a directory or a single file). - Set it to an empty string to disable certificate verification. - -sendemail.<identity>.*:: - Identity-specific versions of the 'sendemail.*' parameters - found below, taking precedence over those when this - identity is selected, through either the command-line or - `sendemail.identity`. - -sendemail.aliasesFile:: -sendemail.aliasFileType:: -sendemail.annotate:: -sendemail.bcc:: -sendemail.cc:: -sendemail.ccCmd:: -sendemail.chainReplyTo:: -sendemail.confirm:: -sendemail.envelopeSender:: -sendemail.from:: -sendemail.multiEdit:: -sendemail.signedoffbycc:: -sendemail.smtpPass:: -sendemail.suppresscc:: -sendemail.suppressFrom:: -sendemail.to:: -sendemail.tocmd:: -sendemail.smtpDomain:: -sendemail.smtpServer:: -sendemail.smtpServerPort:: -sendemail.smtpServerOption:: -sendemail.smtpUser:: -sendemail.thread:: -sendemail.transferEncoding:: -sendemail.validate:: -sendemail.xmailer:: - See linkgit:git-send-email[1] for description. - -sendemail.signedoffcc (deprecated):: - Deprecated alias for `sendemail.signedoffbycc`. - -sendemail.smtpBatchSize:: - Number of messages to be sent per connection, after that a relogin - will happen. If the value is 0 or undefined, send all messages in - one connection. - See also the `--batch-size` option of linkgit:git-send-email[1]. - -sendemail.smtpReloginDelay:: - Seconds wait before reconnecting to smtp server. - See also the `--relogin-delay` option of linkgit:git-send-email[1]. diff --git a/third_party/git/Documentation/config/sequencer.txt b/third_party/git/Documentation/config/sequencer.txt deleted file mode 100644 index b48d532a96..0000000000 --- a/third_party/git/Documentation/config/sequencer.txt +++ /dev/null @@ -1,5 +0,0 @@ -sequence.editor:: - Text editor used by `git rebase -i` for editing the rebase instruction file. - The value is meant to be interpreted by the shell when it is used. - It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable. - When not configured the default commit message editor is used instead. diff --git a/third_party/git/Documentation/config/showbranch.txt b/third_party/git/Documentation/config/showbranch.txt deleted file mode 100644 index e79ecd9ee9..0000000000 --- a/third_party/git/Documentation/config/showbranch.txt +++ /dev/null @@ -1,3 +0,0 @@ -showBranch.default:: - The default set of branches for linkgit:git-show-branch[1]. - See linkgit:git-show-branch[1]. diff --git a/third_party/git/Documentation/config/splitindex.txt b/third_party/git/Documentation/config/splitindex.txt deleted file mode 100644 index afdb186df8..0000000000 --- a/third_party/git/Documentation/config/splitindex.txt +++ /dev/null @@ -1,24 +0,0 @@ -splitIndex.maxPercentChange:: - When the split index feature is used, this specifies the - percent of entries the split index can contain compared to the - total number of entries in both the split index and the shared - index before a new shared index is written. - The value should be between 0 and 100. If the value is 0 then - a new shared index is always written, if it is 100 a new - shared index is never written. - By default the value is 20, so a new shared index is written - if the number of entries in the split index would be greater - than 20 percent of the total number of entries. - See linkgit:git-update-index[1]. - -splitIndex.sharedIndexExpire:: - When the split index feature is used, shared index files that - were not modified since the time this variable specifies will - be removed when a new shared index file is created. The value - "now" expires all entries immediately, and "never" suppresses - expiration altogether. - The default value is "2.weeks.ago". - Note that a shared index file is considered modified (for the - purpose of expiration) each time a new split-index file is - either created based on it or read from it. - See linkgit:git-update-index[1]. diff --git a/third_party/git/Documentation/config/ssh.txt b/third_party/git/Documentation/config/ssh.txt deleted file mode 100644 index 2ca4bf93e1..0000000000 --- a/third_party/git/Documentation/config/ssh.txt +++ /dev/null @@ -1,35 +0,0 @@ -ssh.variant:: - By default, Git determines the command line arguments to use - based on the basename of the configured SSH command (configured - using the environment variable `GIT_SSH` or `GIT_SSH_COMMAND` or - the config setting `core.sshCommand`). If the basename is - unrecognized, Git will attempt to detect support of OpenSSH - options by first invoking the configured SSH command with the - `-G` (print configuration) option and will subsequently use - OpenSSH options (if that is successful) or no options besides - the host and remote command (if it fails). -+ -The config variable `ssh.variant` can be set to override this detection. -Valid values are `ssh` (to use OpenSSH options), `plink`, `putty`, -`tortoiseplink`, `simple` (no options except the host and remote command). -The default auto-detection can be explicitly requested using the value -`auto`. Any other value is treated as `ssh`. This setting can also be -overridden via the environment variable `GIT_SSH_VARIANT`. -+ -The current command-line parameters used for each variant are as -follows: -+ --- - -* `ssh` - [-p port] [-4] [-6] [-o option] [username@]host command - -* `simple` - [username@]host command - -* `plink` or `putty` - [-P port] [-4] [-6] [username@]host command - -* `tortoiseplink` - [-P port] [-4] [-6] -batch [username@]host command - --- -+ -Except for the `simple` variant, command-line parameters are likely to -change as git gains new features. diff --git a/third_party/git/Documentation/config/stash.txt b/third_party/git/Documentation/config/stash.txt deleted file mode 100644 index abc7ef4a3a..0000000000 --- a/third_party/git/Documentation/config/stash.txt +++ /dev/null @@ -1,24 +0,0 @@ -stash.useBuiltin:: - Set to `false` to use the legacy shell script implementation of - linkgit:git-stash[1]. Is `true` by default, which means use - the built-in rewrite of it in C. -+ -The C rewrite is first included with Git version 2.22 (and Git for Windows -version 2.19). This option serves as an escape hatch to re-enable the -legacy version in case any bugs are found in the rewrite. This option and -the shell script version of linkgit:git-stash[1] will be removed in some -future release. -+ -If you find some reason to set this option to `false`, other than -one-off testing, you should report the behavior difference as a bug in -Git (see https://git-scm.com/community for details). - -stash.showPatch:: - If this is set to true, the `git stash show` command without an - option will show the stash entry in patch form. Defaults to false. - See description of 'show' command in linkgit:git-stash[1]. - -stash.showStat:: - If this is set to true, the `git stash show` command without an - option will show diffstat of the stash entry. Defaults to true. - See description of 'show' command in linkgit:git-stash[1]. diff --git a/third_party/git/Documentation/config/status.txt b/third_party/git/Documentation/config/status.txt deleted file mode 100644 index 0fc704ab80..0000000000 --- a/third_party/git/Documentation/config/status.txt +++ /dev/null @@ -1,77 +0,0 @@ -status.relativePaths:: - By default, linkgit:git-status[1] shows paths relative to the - current directory. Setting this variable to `false` shows paths - relative to the repository root (this was the default for Git - prior to v1.5.4). - -status.short:: - Set to true to enable --short by default in linkgit:git-status[1]. - The option --no-short takes precedence over this variable. - -status.branch:: - Set to true to enable --branch by default in linkgit:git-status[1]. - The option --no-branch takes precedence over this variable. - -status.aheadBehind:: - Set to true to enable `--ahead-behind` and false to enable - `--no-ahead-behind` by default in linkgit:git-status[1] for - non-porcelain status formats. Defaults to true. - -status.displayCommentPrefix:: - If set to true, linkgit:git-status[1] will insert a comment - prefix before each output line (starting with - `core.commentChar`, i.e. `#` by default). This was the - behavior of linkgit:git-status[1] in Git 1.8.4 and previous. - Defaults to false. - -status.renameLimit:: - The number of files to consider when performing rename detection - in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to - the value of diff.renameLimit. - -status.renames:: - Whether and how Git detects renames in linkgit:git-status[1] and - linkgit:git-commit[1] . If set to "false", rename detection is - disabled. If set to "true", basic rename detection is enabled. - If set to "copies" or "copy", Git will detect copies, as well. - Defaults to the value of diff.renames. - -status.showStash:: - If set to true, linkgit:git-status[1] will display the number of - entries currently stashed away. - Defaults to false. - -status.showUntrackedFiles:: - By default, linkgit:git-status[1] and linkgit:git-commit[1] show - files which are not currently tracked by Git. Directories which - contain only untracked files, are shown with the directory name - only. Showing untracked files means that Git needs to lstat() all - the files in the whole repository, which might be slow on some - systems. So, this variable controls how the commands displays - the untracked files. Possible values are: -+ --- -* `no` - Show no untracked files. -* `normal` - Show untracked files and directories. -* `all` - Show also individual files in untracked directories. --- -+ -If this variable is not specified, it defaults to 'normal'. -This variable can be overridden with the -u|--untracked-files option -of linkgit:git-status[1] and linkgit:git-commit[1]. - -status.submoduleSummary:: - Defaults to false. - If this is set to a non zero number or true (identical to -1 or an - unlimited number), the submodule summary will be enabled and a - summary of commits for modified submodules will be shown (see - --summary-limit option of linkgit:git-submodule[1]). Please note - that the summary output command will be suppressed for all - submodules when `diff.ignoreSubmodules` is set to 'all' or only - for those submodules where `submodule.<name>.ignore=all`. The only - exception to that rule is that status and commit will show staged - submodule changes. To - also view the summary for ignored submodules you can either use - the --ignore-submodules=dirty command-line option or the 'git - submodule summary' command, which shows a similar output but does - not honor these settings. diff --git a/third_party/git/Documentation/config/submodule.txt b/third_party/git/Documentation/config/submodule.txt deleted file mode 100644 index 0a1293b051..0000000000 --- a/third_party/git/Documentation/config/submodule.txt +++ /dev/null @@ -1,82 +0,0 @@ -submodule.<name>.url:: - 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'. If neither submodule.<name>.active or submodule.active are - set, the presence of this variable is used as a fallback to indicate - whether the submodule is of interest to git commands. - See linkgit:git-submodule[1] and linkgit:gitmodules[5] for details. - -submodule.<name>.update:: - The method by which a submodule is updated by 'git submodule update', - which is the only affected command, others such as - 'git checkout --recurse-submodules' are unaffected. It exists for - historical reasons, when 'git submodule' was the only command to - interact with submodules; settings like `submodule.active` - and `pull.rebase` are more specific. It is populated by - `git submodule init` from the linkgit:gitmodules[5] file. - See description of 'update' command in linkgit:git-submodule[1]. - -submodule.<name>.branch:: - The remote branch name for a submodule, used by `git submodule - update --remote`. Set this option to override the value found in - the `.gitmodules` file. See linkgit:git-submodule[1] and - linkgit:gitmodules[5] for details. - -submodule.<name>.fetchRecurseSubmodules:: - This option can be used to control recursive fetching of this - submodule. It can be overridden by using the --[no-]recurse-submodules - command-line option to "git fetch" and "git pull". - This setting will override that from in the linkgit:gitmodules[5] - file. - -submodule.<name>.ignore:: - Defines under what circumstances "git status" and the diff family show - a submodule as modified. When set to "all", it will never be considered - modified (but it will nonetheless show up in the output of status and - commit when it has been staged), "dirty" will ignore all changes - to the submodules work tree and - takes only differences between the HEAD of the submodule and the commit - recorded in the superproject into account. "untracked" will additionally - let submodules with modified tracked files in their work tree show up. - Using "none" (the default when this option is not set) also shows - submodules that have untracked files in their work tree as changed. - This setting overrides any setting made in .gitmodules for this submodule, - both settings can be overridden on the command line by using the - "--ignore-submodules" option. The 'git submodule' commands are not - affected by this setting. - -submodule.<name>.active:: - Boolean value indicating if the submodule is of interest to git - commands. This config option takes precedence over the - submodule.active config option. See linkgit:gitsubmodules[7] for - details. - -submodule.active:: - A repeated field which contains a pathspec used to match against a - submodule's path to determine if the submodule is of interest to git - commands. See linkgit:gitsubmodules[7] for details. - -submodule.recurse:: - Specifies if commands recurse into submodules by default. This - applies to all commands that have a `--recurse-submodules` option, - except `clone`. - Defaults to false. - -submodule.fetchJobs:: - Specifies how many submodules are fetched/cloned at the same time. - A positive integer allows up to that number of submodules fetched - 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`. diff --git a/third_party/git/Documentation/config/tag.txt b/third_party/git/Documentation/config/tag.txt deleted file mode 100644 index ef5adb3f42..0000000000 --- a/third_party/git/Documentation/config/tag.txt +++ /dev/null @@ -1,24 +0,0 @@ -tag.forceSignAnnotated:: - A boolean to specify whether annotated tags created should be GPG signed. - If `--annotate` is specified on the command line, it takes - precedence over this option. - -tag.sort:: - This variable controls the sort ordering of tags when displayed by - linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the - value of this variable will be used as the default. - -tag.gpgSign:: - A boolean to specify whether all tags should be GPG signed. - Use of this option when running in an automated script can - result in a large number of tags being signed. It is therefore - convenient to use an agent to avoid typing your gpg passphrase - several times. Note that this option doesn't affects tag signing - behavior enabled by "-u <keyid>" or "--local-user=<keyid>" options. - -tar.umask:: - This variable can be used to restrict the permission bits of - tar archive entries. The default is 0002, which turns off the - world write bit. The special value "user" indicates that the - archiving user's umask will be used instead. See umask(2) and - linkgit:git-archive[1]. diff --git a/third_party/git/Documentation/config/trace2.txt b/third_party/git/Documentation/config/trace2.txt deleted file mode 100644 index 2edbfb02fe..0000000000 --- a/third_party/git/Documentation/config/trace2.txt +++ /dev/null @@ -1,56 +0,0 @@ -Trace2 config settings are only read from the system and global -config files; repository local and worktree config files and `-c` -command line arguments are not respected. - -trace2.normalTarget:: - This variable controls the normal target destination. - It may be overridden by the `GIT_TRACE2` environment variable. - The following table shows possible values. - -trace2.perfTarget:: - This variable controls the performance target destination. - It may be overridden by the `GIT_TRACE2_PERF` environment variable. - The following table shows possible values. - -trace2.eventTarget:: - This variable controls the event target destination. - It may be overridden by the `GIT_TRACE2_EVENT` environment variable. - The following table shows possible values. -+ -include::../trace2-target-values.txt[] - -trace2.normalBrief:: - Boolean. When true `time`, `filename`, and `line` fields are - omitted from normal output. May be overridden by the - `GIT_TRACE2_BRIEF` environment variable. Defaults to false. - -trace2.perfBrief:: - Boolean. When true `time`, `filename`, and `line` fields are - omitted from PERF output. May be overridden by the - `GIT_TRACE2_PERF_BRIEF` environment variable. Defaults to false. - -trace2.eventBrief:: - Boolean. When true `time`, `filename`, and `line` fields are - omitted from event output. May be overridden by the - `GIT_TRACE2_EVENT_BRIEF` environment variable. Defaults to false. - -trace2.eventNesting:: - Integer. Specifies desired depth of nested regions in the - event output. Regions deeper than this value will be - omitted. May be overridden by the `GIT_TRACE2_EVENT_NESTING` - environment variable. Defaults to 2. - -trace2.configParams:: - A comma-separated list of patterns of "important" config - settings that should be recorded in the trace2 output. - For example, `core.*,remote.*.url` would cause the trace2 - output to contain events listing each configured remote. - May be overridden by the `GIT_TRACE2_CONFIG_PARAMS` environment - variable. Unset by default. - -trace2.destinationDebug:: - Boolean. When true Git will print error messages when a - trace target destination cannot be opened for writing. - By default, these errors are suppressed and tracing is - silently disabled. May be overridden by the - `GIT_TRACE2_DST_DEBUG` environment variable. diff --git a/third_party/git/Documentation/config/transfer.txt b/third_party/git/Documentation/config/transfer.txt deleted file mode 100644 index f5b6245270..0000000000 --- a/third_party/git/Documentation/config/transfer.txt +++ /dev/null @@ -1,71 +0,0 @@ -transfer.fsckObjects:: - When `fetch.fsckObjects` or `receive.fsckObjects` are - not set, the value of this variable is used instead. - Defaults to false. -+ -When set, the fetch or receive will abort in the case of a malformed -object or a link to a nonexistent object. In addition, various other -issues are checked for, including legacy issues (see `fsck.<msg-id>`), -and potential security issues like the existence of a `.GIT` directory -or a malicious `.gitmodules` file (see the release notes for v2.2.1 -and v2.17.1 for details). Other sanity and security checks may be -added in future releases. -+ -On the receiving side, failing fsckObjects will make those objects -unreachable, see "QUARANTINE ENVIRONMENT" in -linkgit:git-receive-pack[1]. On the fetch side, malformed objects will -instead be left unreferenced in the repository. -+ -Due to the non-quarantine nature of the `fetch.fsckObjects` -implementation it cannot be relied upon to leave the object store -clean like `receive.fsckObjects` can. -+ -As objects are unpacked they're written to the object store, so there -can be cases where malicious objects get introduced even though the -"fetch" failed, only to have a subsequent "fetch" succeed because only -new incoming objects are checked, not those that have already been -written to the object store. That difference in behavior should not be -relied upon. In the future, such objects may be quarantined for -"fetch" as well. -+ -For now, the paranoid need to find some way to emulate the quarantine -environment if they'd like the same protection as "push". E.g. in the -case of an internal mirror do the mirroring in two steps, one to fetch -the untrusted objects, and then do a second "push" (which will use the -quarantine) to another internal repo, and have internal clients -consume this pushed-to repository, or embargo internal fetches and -only allow them once a full "fsck" has run (and no new fetches have -happened in the meantime). - -transfer.hideRefs:: - String(s) `receive-pack` and `upload-pack` use to decide which - refs to omit from their initial advertisements. Use more than - one definition to specify multiple prefix strings. A ref that is - under the hierarchies listed in the value of this variable is - excluded, and is hidden when responding to `git push` or `git - fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for - program-specific versions of this config. -+ -You may also include a `!` in front of the ref name to negate the entry, -explicitly exposing it, even if an earlier entry marked it as hidden. -If you have multiple hideRefs values, later entries override earlier ones -(and entries in more-specific config files override less-specific ones). -+ -If a namespace is in use, the namespace prefix is stripped from each -reference before it is matched against `transfer.hiderefs` patterns. -For example, if `refs/heads/master` is specified in `transfer.hideRefs` and -the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master` -is omitted from the advertisements but `refs/heads/master` and -`refs/namespaces/bar/refs/heads/master` are still advertised as so-called -"have" lines. In order to match refs before stripping, add a `^` in front of -the ref name. If you combine `!` and `^`, `!` must be specified first. -+ -Even if you hide refs, a client may still be able to steal the target -objects via the techniques described in the "SECURITY" section of the -linkgit:gitnamespaces[7] man page; it's best to keep private data in a -separate repository. - -transfer.unpackLimit:: - When `fetch.unpackLimit` or `receive.unpackLimit` are - not set, the value of this variable is used instead. - The default value is 100. diff --git a/third_party/git/Documentation/config/uploadarchive.txt b/third_party/git/Documentation/config/uploadarchive.txt deleted file mode 100644 index e0698e8c1d..0000000000 --- a/third_party/git/Documentation/config/uploadarchive.txt +++ /dev/null @@ -1,6 +0,0 @@ -uploadarchive.allowUnreachable:: - If true, allow clients to use `git archive --remote` to request - any tree, whether reachable from the ref tips or not. See the - discussion in the "SECURITY" section of - linkgit:git-upload-archive[1] for more details. Defaults to - `false`. diff --git a/third_party/git/Documentation/config/uploadpack.txt b/third_party/git/Documentation/config/uploadpack.txt deleted file mode 100644 index ed1c835695..0000000000 --- a/third_party/git/Documentation/config/uploadpack.txt +++ /dev/null @@ -1,65 +0,0 @@ -uploadpack.hideRefs:: - This variable is the same as `transfer.hideRefs`, but applies - only to `upload-pack` (and so affects only fetches, not pushes). - An attempt to fetch a hidden ref by `git fetch` will fail. See - also `uploadpack.allowTipSHA1InWant`. - -uploadpack.allowTipSHA1InWant:: - When `uploadpack.hideRefs` is in effect, allow `upload-pack` - to accept a fetch request that asks for an object at the tip - of a hidden ref (by default, such a request is rejected). - See also `uploadpack.hideRefs`. Even if this is false, a client - may be able to steal objects via the techniques described in the - "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's - best to keep private data in a separate repository. - -uploadpack.allowReachableSHA1InWant:: - Allow `upload-pack` to accept a fetch request that asks for an - object that is reachable from any ref tip. However, note that - calculating object reachability is computationally expensive. - Defaults to `false`. Even if this is false, a client may be able - to steal objects via the techniques described in the "SECURITY" - section of the linkgit:gitnamespaces[7] man page; it's best to - keep private data in a separate repository. - -uploadpack.allowAnySHA1InWant:: - Allow `upload-pack` to accept a fetch request that asks for any - object at all. - Defaults to `false`. - -uploadpack.keepAlive:: - When `upload-pack` has started `pack-objects`, there may be a - quiet period while `pack-objects` prepares the pack. Normally - it would output progress information, but if `--quiet` was used - for the fetch, `pack-objects` will output nothing at all until - the pack data begins. Some clients and networks may consider - the server to be hung and give up. Setting this option instructs - `upload-pack` to send an empty keepalive packet every - `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). - -uploadpack.allowFilter:: - If this option is set, `upload-pack` will support partial - clone and partial fetch object filtering. - -uploadpack.allowRefInWant:: - If this option is set, `upload-pack` will support the `ref-in-want` - feature of the protocol version 2 `fetch` command. This feature - is intended for the benefit of load-balanced servers which may - not have the same view of what OIDs their refs point to due to - replication delay. diff --git a/third_party/git/Documentation/config/url.txt b/third_party/git/Documentation/config/url.txt deleted file mode 100644 index e5566c371d..0000000000 --- a/third_party/git/Documentation/config/url.txt +++ /dev/null @@ -1,30 +0,0 @@ -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 - large number of repositories, and serves them with multiple - access methods, and some users need to use different access - methods, this feature allows people to specify any of the - equivalent URLs and have Git automatically rewrite the URL to - the best alternative for the particular user, even for a - never-before-seen repository on the site. When more than one - insteadOf strings match a given URL, the longest match is used. -+ -Note that any protocol restrictions will be applied to the rewritten -URL. If the rewrite changes the URL to use a custom protocol or remote -helper, you may need to adjust the `protocol.*.allow` config to permit -the request. In particular, protocols you expect to use for submodules -must be set to `always` rather than the default of `user`. See the -description of `protocol.allow` above. - -url.<base>.pushInsteadOf:: - Any URL that starts with this value will not be pushed to; - instead, it will be rewritten to start with <base>, and the - resulting URL will be pushed to. In cases where some site serves - a large number of repositories, and serves them with multiple - access methods, some of which do not allow push, this feature - allows people to specify a pull-only URL and have Git - automatically use an appropriate URL to push, even for a - never-before-seen repository on the site. When more than one - pushInsteadOf strings match a given URL, the longest match is - used. If a remote has an explicit pushurl, Git will ignore this - setting for that remote. diff --git a/third_party/git/Documentation/config/user.txt b/third_party/git/Documentation/config/user.txt deleted file mode 100644 index 0557cbbceb..0000000000 --- a/third_party/git/Documentation/config/user.txt +++ /dev/null @@ -1,33 +0,0 @@ -user.name:: -user.email:: -author.name:: -author.email:: -committer.name:: -committer.email:: - The `user.name` and `user.email` variables determine what ends - up in the `author` and `committer` field of commit - objects. - If you need the `author` or `committer` to be different, the - `author.name`, `author.email`, `committer.name` or - `committer.email` variables can be set. - Also, all of these can be overridden by the `GIT_AUTHOR_NAME`, - `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_NAME`, - `GIT_COMMITTER_EMAIL` and `EMAIL` environment variables. - See linkgit:git-commit-tree[1] for more information. - -user.useConfigOnly:: - Instruct Git to avoid trying to guess defaults for `user.email` - and `user.name`, and instead retrieve the values only from the - configuration. For example, if you have multiple email addresses - and would like to use a different one for each repository, then - with this configuration option set to `true` in the global config - along with a name, Git will prompt you to set up an email before - making new commits in a newly cloned repository. - Defaults to `false`. - -user.signingKey:: - If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the - key you want it to automatically when creating a signed tag or - commit, you can override the default selection with this variable. - This option is passed unchanged to gpg's --local-user parameter, - so you may specify a key using any method that gpg supports. diff --git a/third_party/git/Documentation/config/versionsort.txt b/third_party/git/Documentation/config/versionsort.txt deleted file mode 100644 index 6c7cc054fa..0000000000 --- a/third_party/git/Documentation/config/versionsort.txt +++ /dev/null @@ -1,33 +0,0 @@ -versionsort.prereleaseSuffix (deprecated):: - Deprecated alias for `versionsort.suffix`. Ignored if - `versionsort.suffix` is set. - -versionsort.suffix:: - Even when version sort is used in linkgit:git-tag[1], tagnames - with the same base version but different suffixes are still sorted - lexicographically, resulting e.g. in prerelease tags appearing - after the main release (e.g. "1.0-rc1" after "1.0"). This - variable can be specified to determine the sorting order of tags - with different suffixes. -+ -By specifying a single suffix in this variable, any tagname containing -that suffix will appear before the corresponding main release. E.g. if -the variable is set to "-rc", then all "1.0-rcX" tags will appear before -"1.0". If specified multiple times, once per suffix, then the order of -suffixes in the configuration will determine the sorting order of tagnames -with those suffixes. E.g. if "-pre" appears before "-rc" in the -configuration, then all "1.0-preX" tags will be listed before any -"1.0-rcX" tags. The placement of the main release tag relative to tags -with various suffixes can be determined by specifying the empty suffix -among those other suffixes. E.g. if the suffixes "-rc", "", "-ck" and -"-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags -are listed first, followed by "v4.8", then "v4.8-ckX" and finally -"v4.8-bfsX". -+ -If more than one suffixes match the same tagname, then that tagname will -be sorted according to the suffix which starts at the earliest position in -the tagname. If more than one different matching suffixes start at -that earliest position, then that tagname will be sorted according to the -longest of those suffixes. -The sorting order between different suffixes is undefined if they are -in multiple config files. diff --git a/third_party/git/Documentation/config/web.txt b/third_party/git/Documentation/config/web.txt deleted file mode 100644 index beec8d1303..0000000000 --- a/third_party/git/Documentation/config/web.txt +++ /dev/null @@ -1,4 +0,0 @@ -web.browser:: - Specify a web browser that may be used by some commands. - Currently only linkgit:git-instaweb[1] and linkgit:git-help[1] - may use it. diff --git a/third_party/git/Documentation/config/worktree.txt b/third_party/git/Documentation/config/worktree.txt deleted file mode 100644 index 048e349482..0000000000 --- a/third_party/git/Documentation/config/worktree.txt +++ /dev/null @@ -1,9 +0,0 @@ -worktree.guessRemote:: - If no branch is specified and neither `-b` nor `-B` nor - `--detach` is used, then `git worktree add` defaults to - creating a new branch from HEAD. If `worktree.guessRemote` is - set to true, `worktree add` tries to find a remote-tracking - branch whose name uniquely matches the new branch name. If - such a branch exists, it is checked out and set as "upstream" - for the new branch. If no such match can be found, it falls - back to creating a new branch from the current HEAD. diff --git a/third_party/git/Documentation/date-formats.txt b/third_party/git/Documentation/date-formats.txt deleted file mode 100644 index 6926e0a4c8..0000000000 --- a/third_party/git/Documentation/date-formats.txt +++ /dev/null @@ -1,26 +0,0 @@ -DATE FORMATS ------------- - -The `GIT_AUTHOR_DATE`, `GIT_COMMITTER_DATE` environment variables -ifdef::git-commit[] -and the `--date` option -endif::git-commit[] -support the following date formats: - -Git internal format:: - It is `<unix timestamp> <time zone offset>`, where `<unix - timestamp>` is the number of seconds since the UNIX epoch. - `<time zone offset>` is a positive or negative offset from UTC. - For example CET (which is 1 hour ahead of UTC) is `+0100`. - -RFC 2822:: - The standard email format as described by RFC 2822, for example - `Thu, 07 Apr 2005 22:13:13 +0200`. - -ISO 8601:: - Time and date specified by the ISO 8601 standard, for example - `2005-04-07T22:13:13`. The parser accepts a space instead of the - `T` character as well. -+ -NOTE: In addition, the date part is accepted in the following formats: -`YYYY.MM.DD`, `MM/DD/YYYY` and `DD.MM.YYYY`. diff --git a/third_party/git/Documentation/diff-format.txt b/third_party/git/Documentation/diff-format.txt deleted file mode 100644 index 4d846d7346..0000000000 --- a/third_party/git/Documentation/diff-format.txt +++ /dev/null @@ -1,185 +0,0 @@ -Raw output format ------------------ - -The raw output format from "git-diff-index", "git-diff-tree", -"git-diff-files" and "git diff --raw" are very similar. - -These commands all compare two sets of things; what is -compared differs: - -git-diff-index <tree-ish>:: - compares the <tree-ish> and the files on the filesystem. - -git-diff-index --cached <tree-ish>:: - compares the <tree-ish> and the index. - -git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>...]:: - compares the trees named by the two arguments. - -git-diff-files [<pattern>...]:: - compares the index and the files on the filesystem. - -The "git-diff-tree" command begins its output by printing the hash of -what is being compared. After that, all the commands print one output -line per changed file. - -An output line is formatted this way: - ------------------------------------------------- -in-place edit :100644 100644 bcd1234 0123456 M file0 -copy-edit :100644 100644 abcd123 1234567 C68 file1 file2 -rename-edit :100644 100644 abcd123 1234567 R86 file1 file3 -create :000000 100644 0000000 1234567 A file4 -delete :100644 000000 1234567 0000000 D file5 -unmerged :000000 000000 0000000 0000000 U file6 ------------------------------------------------- - -That is, from the left to the right: - -. a colon. -. mode for "src"; 000000 if creation or unmerged. -. a space. -. mode for "dst"; 000000 if deletion or unmerged. -. a space. -. sha1 for "src"; 0\{40\} if creation or unmerged. -. a space. -. sha1 for "dst"; 0\{40\} if creation, unmerged or "look at work tree". -. a space. -. status, followed by optional "score" number. -. a tab or a NUL when `-z` option is used. -. path for "src" -. a tab or a NUL when `-z` option is used; only exists for C or R. -. path for "dst"; only exists for C or R. -. an LF or a NUL when `-z` option is used, to terminate the record. - -Possible status letters are: - -- A: addition of a file -- C: copy of a file into a new one -- D: deletion of a file -- M: modification of the contents or mode of a file -- R: renaming of a file -- T: change in the type of the file -- U: file is unmerged (you must complete the merge before it can -be committed) -- X: "unknown" change type (most probably a bug, please report it) - -Status letters C and R are always followed by a score (denoting the -percentage of similarity between the source and target of the move or -copy). Status letter M may be followed by a score (denoting the -percentage of dissimilarity) for file rewrites. - -<sha1> is shown as all 0's if a file is new on the filesystem -and it is out of sync with the index. - -Example: - ------------------------------------------------- -:100644 100644 5be4a4a 0000000 M file.c ------------------------------------------------- - -Without the `-z` option, pathnames with "unusual" characters are -quoted as explained for the configuration variable `core.quotePath` -(see linkgit:git-config[1]). Using `-z` the filename is output -verbatim and the line is terminated by a NUL byte. - -diff format for merges ----------------------- - -"git-diff-tree", "git-diff-files" and "git-diff --raw" -can take `-c` or `--cc` option -to generate diff output also for merge commits. The output differs -from the format described above in the following way: - -. there is a colon for each parent -. there are more "src" modes and "src" sha1 -. status is concatenated status characters for each parent -. no optional "score" number -. tab-separated pathname(s) of the file - -For `-c` and `--cc`, only the destination or final path is shown even -if the file was renamed on any side of history. With -`--combined-all-paths`, the name of the path in each parent is shown -followed by the name of the path in the merge commit. - -Examples for `-c` and `--cc` without `--combined-all-paths`: ------------------------------------------------- -::100644 100644 100644 fabadb8 cc95eb0 4866510 MM desc.c -::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM bar.sh -::100644 100644 100644 e07d6c5 9042e82 ee91881 RR phooey.c ------------------------------------------------- - -Examples when `--combined-all-paths` added to either `-c` or `--cc`: - ------------------------------------------------- -::100644 100644 100644 fabadb8 cc95eb0 4866510 MM desc.c desc.c desc.c -::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM foo.sh bar.sh bar.sh -::100644 100644 100644 e07d6c5 9042e82 ee91881 RR fooey.c fuey.c phooey.c ------------------------------------------------- - -Note that 'combined diff' lists only files which were modified from -all parents. - - -include::diff-generate-patch.txt[] - - -other diff formats ------------------- - -The `--summary` option describes newly added, deleted, renamed and -copied files. The `--stat` option adds diffstat(1) graph to the -output. These options can be combined with other options, such as -`-p`, and are meant for human consumption. - -When showing a change that involves a rename or a copy, `--stat` output -formats the pathnames compactly by combining common prefix and suffix of -the pathnames. For example, a change that moves `arch/i386/Makefile` to -`arch/x86/Makefile` while modifying 4 lines will be shown like this: - ------------------------------------- -arch/{i386 => x86}/Makefile | 4 +-- ------------------------------------- - -The `--numstat` option gives the diffstat(1) information but is designed -for easier machine consumption. An entry in `--numstat` output looks -like this: - ----------------------------------------- -1 2 README -3 1 arch/{i386 => x86}/Makefile ----------------------------------------- - -That is, from left to right: - -. the number of added lines; -. a tab; -. the number of deleted lines; -. a tab; -. pathname (possibly with rename/copy information); -. a newline. - -When `-z` output option is in effect, the output is formatted this way: - ----------------------------------------- -1 2 README NUL -3 1 NUL arch/i386/Makefile NUL arch/x86/Makefile NUL ----------------------------------------- - -That is: - -. the number of added lines; -. a tab; -. the number of deleted lines; -. a tab; -. a NUL (only exists if renamed/copied); -. pathname in preimage; -. a NUL (only exists if renamed/copied); -. pathname in postimage (only exists if renamed/copied); -. a NUL. - -The extra `NUL` before the preimage path in renamed case is to allow -scripts that read the output to tell if the current record being read is -a single-path record or a rename/copy record without reading ahead. -After reading added and deleted lines, reading up to `NUL` would yield -the pathname, but if that is `NUL`, the record will show two paths. diff --git a/third_party/git/Documentation/diff-generate-patch.txt b/third_party/git/Documentation/diff-generate-patch.txt deleted file mode 100644 index f10ca410ad..0000000000 --- a/third_party/git/Documentation/diff-generate-patch.txt +++ /dev/null @@ -1,197 +0,0 @@ -Generating patches with -p --------------------------- - -When "git-diff-index", "git-diff-tree", or "git-diff-files" are run -with a `-p` option, "git diff" without the `--raw` option, or -"git log" with the "-p" option, they -do not produce the output described above; instead they produce a -patch file. You can customize the creation of such patches via the -`GIT_EXTERNAL_DIFF` and the `GIT_DIFF_OPTS` environment variables. - -What the -p option produces is slightly different from the traditional -diff format: - -1. It is preceded with a "git diff" header that looks like this: - - diff --git a/file1 b/file2 -+ -The `a/` and `b/` filenames are the same unless rename/copy is -involved. Especially, even for a creation or a deletion, -`/dev/null` is _not_ used in place of the `a/` or `b/` filenames. -+ -When rename/copy is involved, `file1` and `file2` show the -name of the source file of the rename/copy and the name of -the file that rename/copy produces, respectively. - -2. It is followed by one or more extended header lines: - - old mode <mode> - new mode <mode> - deleted file mode <mode> - new file mode <mode> - copy from <path> - copy to <path> - rename from <path> - rename to <path> - similarity index <number> - dissimilarity index <number> - index <hash>..<hash> <mode> -+ -File modes are printed as 6-digit octal numbers including the file type -and file permission bits. -+ -Path names in extended headers do not include the `a/` and `b/` prefixes. -+ -The similarity index is the percentage of unchanged lines, and -the dissimilarity index is the percentage of changed lines. It -is a rounded down integer, followed by a percent sign. The -similarity index value of 100% is thus reserved for two equal -files, while 100% dissimilarity means that no line from the old -file made it into the new one. -+ -The index line includes the SHA-1 checksum before and after the change. -The <mode> is included if the file mode does not change; otherwise, -separate lines indicate the old and the new mode. - -3. Pathnames with "unusual" characters are quoted as explained for - the configuration variable `core.quotePath` (see - linkgit:git-config[1]). - -4. All the `file1` files in the output refer to files before the - commit, and all the `file2` files refer to files after the commit. - It is incorrect to apply each change to each file sequentially. For - example, this patch will swap a and b: - - diff --git a/a b/b - rename from a - rename to b - diff --git a/b b/a - rename from b - rename to a - - -combined diff format --------------------- - -Any diff-generating command can take the `-c` or `--cc` option to -produce a 'combined diff' when showing a merge. This is the default -format when showing merges with linkgit:git-diff[1] or -linkgit:git-show[1]. Note also that you can give the `-m` option to any -of these commands to force generation of diffs with individual parents -of a merge. - -A 'combined diff' format looks like this: - ------------- -diff --combined describe.c -index fabadb8,cc95eb0..4866510 ---- a/describe.c -+++ b/describe.c -@@@ -98,20 -98,12 +98,20 @@@ - return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1; - } - -- static void describe(char *arg) - -static void describe(struct commit *cmit, int last_one) -++static void describe(char *arg, int last_one) - { - + unsigned char sha1[20]; - + struct commit *cmit; - struct commit_list *list; - static int initialized = 0; - struct commit_name *n; - - + if (get_sha1(arg, sha1) < 0) - + usage(describe_usage); - + cmit = lookup_commit_reference(sha1); - + if (!cmit) - + usage(describe_usage); - + - if (!initialized) { - initialized = 1; - for_each_ref(get_name); ------------- - -1. It is preceded with a "git diff" header, that looks like - this (when `-c` option is used): - - diff --combined file -+ -or like this (when `--cc` option is used): - - diff --cc file - -2. It is followed by one or more extended header lines - (this example shows a merge with two parents): - - index <hash>,<hash>..<hash> - mode <mode>,<mode>..<mode> - new file mode <mode> - deleted file mode <mode>,<mode> -+ -The `mode <mode>,<mode>..<mode>` line appears only if at least one of -the <mode> is different from the rest. Extended headers with -information about detected contents movement (renames and -copying detection) are designed to work with diff of two -<tree-ish> and are not used by combined diff format. - -3. It is followed by two-line from-file/to-file header - - --- a/file - +++ b/file -+ -Similar to two-line header for traditional 'unified' diff -format, `/dev/null` is used to signal created or deleted -files. -+ -However, if the --combined-all-paths option is provided, instead of a -two-line from-file/to-file you get a N+1 line from-file/to-file header, -where N is the number of parents in the merge commit - - --- a/file - --- a/file - --- a/file - +++ b/file -+ -This extended format can be useful if rename or copy detection is -active, to allow you to see the original name of the file in different -parents. - -4. Chunk header format is modified to prevent people from - accidentally feeding it to `patch -p1`. Combined diff format - was created for review of merge commit changes, and was not - meant for apply. The change is similar to the change in the - extended 'index' header: - - @@@ <from-file-range> <from-file-range> <to-file-range> @@@ -+ -There are (number of parents + 1) `@` characters in the chunk -header for combined diff format. - -Unlike the traditional 'unified' diff format, which shows two -files A and B with a single column that has `-` (minus -- -appears in A but removed in B), `+` (plus -- missing in A but -added to B), or `" "` (space -- unchanged) prefix, this format -compares two or more files file1, file2,... with one file X, and -shows how X differs from each of fileN. One column for each of -fileN is prepended to the output line to note how X's line is -different from it. - -A `-` character in the column N means that the line appears in -fileN but it does not appear in the result. A `+` character -in the column N means that the line appears in the result, -and fileN does not have that line (in other words, the line was -added, from the point of view of that parent). - -In the above example output, the function signature was changed -from both files (hence two `-` removals from both file1 and -file2, plus `++` to mean one line that was added does not appear -in either file1 or file2). Also eight other lines are the same -from file1 but do not appear in file2 (hence prefixed with `+`). - -When shown by `git diff-tree -c`, it compares the parents of a -merge commit with the merge result (i.e. file1..fileN are the -parents). When shown by `git diff-files -c`, it compares the -two unresolved merge parents with the working tree file -(i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka -"their version"). diff --git a/third_party/git/Documentation/diff-options.txt b/third_party/git/Documentation/diff-options.txt deleted file mode 100644 index 09faee3b44..0000000000 --- a/third_party/git/Documentation/diff-options.txt +++ /dev/null @@ -1,756 +0,0 @@ -// Please don't remove this comment as asciidoc behaves badly when -// the first non-empty line is ifdef/ifndef. The symptom is that -// without this comment the <git-diff-core> attribute conditionally -// defined below ends up being defined unconditionally. -// Last checked with asciidoc 7.0.2. - -ifndef::git-format-patch[] -ifndef::git-diff[] -ifndef::git-log[] -:git-diff-core: 1 -endif::git-log[] -endif::git-diff[] -endif::git-format-patch[] - -ifdef::git-format-patch[] --p:: ---no-stat:: - Generate plain patches without any diffstats. -endif::git-format-patch[] - -ifndef::git-format-patch[] --p:: --u:: ---patch:: - Generate patch (see section on generating patches). -ifdef::git-diff[] - This is the default. -endif::git-diff[] - --s:: ---no-patch:: - Suppress diff output. Useful for commands like `git show` that - show the patch by default, or to cancel the effect of `--patch`. -endif::git-format-patch[] - --U<n>:: ---unified=<n>:: - Generate diffs with <n> lines of context instead of - the usual three. Implies `--patch`. -ifndef::git-format-patch[] - Implies `-p`. -endif::git-format-patch[] - ---output=<file>:: - Output to a specific file instead of stdout. - ---output-indicator-new=<char>:: ---output-indicator-old=<char>:: ---output-indicator-context=<char>:: - Specify the character used to indicate new, old or context - lines in the generated patch. Normally they are '+', '-' and - ' ' respectively. - -ifndef::git-format-patch[] ---raw:: -ifndef::git-log[] - Generate the diff in raw format. -ifdef::git-diff-core[] - This is the default. -endif::git-diff-core[] -endif::git-log[] -ifdef::git-log[] - For each commit, show a summary of changes using the raw diff - format. See the "RAW OUTPUT FORMAT" section of - linkgit:git-diff[1]. This is different from showing the log - itself in raw format, which you can achieve with - `--format=raw`. -endif::git-log[] -endif::git-format-patch[] - -ifndef::git-format-patch[] ---patch-with-raw:: - Synonym for `-p --raw`. -endif::git-format-patch[] - ---indent-heuristic:: - Enable the heuristic that shifts diff hunk boundaries to make patches - easier to read. This is the default. - ---no-indent-heuristic:: - Disable the indent heuristic. - ---minimal:: - Spend extra time to make sure the smallest possible - diff is produced. - ---patience:: - Generate a diff using the "patience diff" algorithm. - ---histogram:: - Generate a diff using the "histogram diff" algorithm. - ---anchored=<text>:: - Generate a diff using the "anchored diff" algorithm. -+ -This option may be specified more than once. -+ -If a line exists in both the source and destination, exists only once, -and starts with this text, this algorithm attempts to prevent it from -appearing as a deletion or addition in the output. It uses the "patience -diff" algorithm internally. - ---diff-algorithm={patience|minimal|histogram|myers}:: - Choose a diff algorithm. The variants are as follows: -+ --- -`default`, `myers`;; - The basic greedy diff algorithm. Currently, this is the default. -`minimal`;; - Spend extra time to make sure the smallest possible diff is - produced. -`patience`;; - Use "patience diff" algorithm when generating patches. -`histogram`;; - This algorithm extends the patience algorithm to "support - low-occurrence common elements". --- -+ -For instance, if you configured the `diff.algorithm` variable to a -non-default value and want to use the default one, then you -have to use `--diff-algorithm=default` option. - ---stat[=<width>[,<name-width>[,<count>]]]:: - Generate a diffstat. By default, as much space as necessary - will be used for the filename part, and the rest for the graph - part. Maximum width defaults to terminal width, or 80 columns - if not connected to a terminal, and can be overridden by - `<width>`. The width of the filename part can be limited by - giving another width `<name-width>` after a comma. The width - of the graph part can be limited by using - `--stat-graph-width=<width>` (affects all commands generating - a stat graph) or by setting `diff.statGraphWidth=<width>` - (does not affect `git format-patch`). - By giving a third parameter `<count>`, you can limit the - output to the first `<count>` lines, followed by `...` if - there are more. -+ -These parameters can also be set individually with `--stat-width=<width>`, -`--stat-name-width=<name-width>` and `--stat-count=<count>`. - ---compact-summary:: - Output a condensed summary of extended header information such - as file creations or deletions ("new" or "gone", optionally "+l" - if it's a symlink) and mode changes ("+x" or "-x" for adding - or removing executable bit respectively) in diffstat. The - information is put between the filename part and the graph - part. Implies `--stat`. - ---numstat:: - Similar to `--stat`, but shows number of added and - deleted lines in decimal notation and pathname without - abbreviation, to make it more machine friendly. For - binary files, outputs two `-` instead of saying - `0 0`. - ---shortstat:: - Output only the last line of the `--stat` format containing total - number of modified files, as well as number of added and deleted - lines. - --X[<param1,param2,...>]:: ---dirstat[=<param1,param2,...>]:: - Output the distribution of relative amount of changes for each - sub-directory. The behavior of `--dirstat` can be customized by - passing it a comma separated list of parameters. - The defaults are controlled by the `diff.dirstat` configuration - variable (see linkgit:git-config[1]). - The following parameters are available: -+ --- -`changes`;; - Compute the dirstat numbers by counting the lines that have been - removed from the source, or added to the destination. This ignores - the amount of pure code movements within a file. In other words, - rearranging lines in a file is not counted as much as other changes. - This is the default behavior when no parameter is given. -`lines`;; - Compute the dirstat numbers by doing the regular line-based diff - analysis, and summing the removed/added line counts. (For binary - files, count 64-byte chunks instead, since binary files have no - natural concept of lines). This is a more expensive `--dirstat` - behavior than the `changes` behavior, but it does count rearranged - lines within a file as much as other changes. The resulting output - is consistent with what you get from the other `--*stat` options. -`files`;; - Compute the dirstat numbers by counting the number of files changed. - Each changed file counts equally in the dirstat analysis. This is - the computationally cheapest `--dirstat` behavior, since it does - not have to look at the file contents at all. -`cumulative`;; - Count changes in a child directory for the parent directory as well. - Note that when using `cumulative`, the sum of the percentages - reported may exceed 100%. The default (non-cumulative) behavior can - be specified with the `noncumulative` parameter. -<limit>;; - An integer parameter specifies a cut-off percent (3% by default). - Directories contributing less than this percentage of the changes - are not shown in the output. --- -+ -Example: The following will count changed files, while ignoring -directories with less than 10% of the total amount of changed files, -and accumulating child directory counts in the parent directories: -`--dirstat=files,10,cumulative`. - ---cumulative:: - Synonym for --dirstat=cumulative - ---dirstat-by-file[=<param1,param2>...]:: - Synonym for --dirstat=files,param1,param2... - ---summary:: - Output a condensed summary of extended header information - such as creations, renames and mode changes. - -ifndef::git-format-patch[] ---patch-with-stat:: - Synonym for `-p --stat`. -endif::git-format-patch[] - -ifndef::git-format-patch[] - --z:: -ifdef::git-log[] - Separate the commits with NULs instead of with new newlines. -+ -Also, when `--raw` or `--numstat` has been given, do not munge -pathnames and use NULs as output field terminators. -endif::git-log[] -ifndef::git-log[] - When `--raw`, `--numstat`, `--name-only` or `--name-status` has been - given, do not munge pathnames and use NULs as output field terminators. -endif::git-log[] -+ -Without this option, pathnames with "unusual" characters are quoted as -explained for the configuration variable `core.quotePath` (see -linkgit:git-config[1]). - ---name-only:: - Show only names of changed files. - ---name-status:: - Show only names and status of changed files. See the description - of the `--diff-filter` option on what the status letters mean. - ---submodule[=<format>]:: - 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. - `--color` (i.e. without '=<when>') is the same as `--color=always`. - '<when>' can be one of `always`, `never`, or `auto`. -ifdef::git-diff[] - It can be changed by the `color.ui` and `color.diff` - configuration settings. -endif::git-diff[] - ---no-color:: - Turn off colored diff. -ifdef::git-diff[] - This can be used to override configuration settings. -endif::git-diff[] - It is the same as `--color=never`. - ---color-moved[=<mode>]:: - Moved lines of code are colored differently. -ifdef::git-diff[] - It can be changed by the `diff.colorMoved` configuration setting. -endif::git-diff[] - The <mode> defaults to 'no' if the option is not given - and to 'zebra' if the option with no mode is given. - The mode must be one of: -+ --- -no:: - Moved lines are not highlighted. -default:: - Is a synonym for `zebra`. This may change to a more sensible mode - in the future. -plain:: - Any line that is added in one location and was removed - in another location will be colored with 'color.diff.newMoved'. - Similarly 'color.diff.oldMoved' will be used for removed lines - that are added somewhere else in the diff. This mode picks up any - moved line, but it is not very useful in a review to determine - if a block of code was moved without permutation. -blocks:: - Blocks of moved text of at least 20 alphanumeric characters - are detected greedily. The detected blocks are - painted using either the 'color.diff.{old,new}Moved' color. - Adjacent blocks cannot be told apart. -zebra:: - Blocks of moved text are detected as in 'blocks' mode. The blocks - are painted using either the 'color.diff.{old,new}Moved' color or - 'color.diff.{old,new}MovedAlternative'. The change between - the two colors indicates that a new block was detected. -dimmed-zebra:: - Similar to 'zebra', but additional dimming of uninteresting parts - of moved code is performed. The bordering lines of two adjacent - blocks are considered interesting, the rest is uninteresting. - `dimmed_zebra` is a deprecated synonym. --- - ---no-color-moved:: - Turn off move detection. This can be used to override configuration - settings. It is the same as `--color-moved=no`. - ---color-moved-ws=<modes>:: - This configures how whitespace is ignored when performing the - move detection for `--color-moved`. -ifdef::git-diff[] - It can be set by the `diff.colorMovedWS` configuration setting. -endif::git-diff[] - These modes can be given as a comma separated list: -+ --- -no:: - Do not ignore whitespace when performing move detection. -ignore-space-at-eol:: - Ignore changes in whitespace at EOL. -ignore-space-change:: - Ignore changes in amount of whitespace. This ignores whitespace - at line end, and considers all other sequences of one or - more whitespace characters to be equivalent. -ignore-all-space:: - Ignore whitespace when comparing lines. This ignores differences - even if one line has whitespace where the other line has none. -allow-indentation-change:: - Initially ignore any whitespace in the move detection, then - group the moved code blocks only into a block if the change in - whitespace is the same per line. This is incompatible with the - other modes. --- - ---no-color-moved-ws:: - Do not ignore whitespace when performing move detection. This can be - used to override configuration settings. It is the same as - `--color-moved-ws=no`. - ---word-diff[=<mode>]:: - Show a word diff, using the <mode> to delimit changed words. - By default, words are delimited by whitespace; see - `--word-diff-regex` below. The <mode> defaults to 'plain', and - must be one of: -+ --- -color:: - Highlight changed words using only colors. Implies `--color`. -plain:: - Show words as `[-removed-]` and `{+added+}`. Makes no - attempts to escape the delimiters if they appear in the input, - so the output may be ambiguous. -porcelain:: - Use a special line-based format intended for script - consumption. Added/removed/unchanged runs are printed in the - usual unified diff format, starting with a `+`/`-`/` ` - character at the beginning of the line and extending to the - end of the line. Newlines in the input are represented by a - tilde `~` on a line of its own. -none:: - Disable word diff again. --- -+ -Note that despite the name of the first mode, color is used to -highlight the changed parts in all modes if enabled. - ---word-diff-regex=<regex>:: - Use <regex> to decide what a word is, instead of considering - runs of non-whitespace to be a word. Also implies - `--word-diff` unless it was already enabled. -+ -Every non-overlapping match of the -<regex> is considered a word. Anything between these matches is -considered whitespace and ignored(!) for the purposes of finding -differences. You may want to append `|[^[:space:]]` to your regular -expression to make sure that it matches all non-whitespace characters. -A match that contains a newline is silently truncated(!) at the -newline. -+ -For example, `--word-diff-regex=.` will treat each character as a word -and, correspondingly, show differences character by character. -+ -The regex can also be set via a diff driver or configuration option, see -linkgit:gitattributes[5] or linkgit:git-config[1]. Giving it explicitly -overrides any diff driver or configuration setting. Diff drivers -override configuration settings. - ---color-words[=<regex>]:: - Equivalent to `--word-diff=color` plus (if a regex was - specified) `--word-diff-regex=<regex>`. -endif::git-format-patch[] - ---no-renames:: - Turn off rename detection, even when the configuration - file gives the default to do so. - ---[no-]rename-empty:: - Whether to use empty blobs as rename source. - -ifndef::git-format-patch[] ---check:: - Warn if changes introduce conflict markers or whitespace errors. - What are considered whitespace errors is controlled by `core.whitespace` - configuration. By default, trailing whitespaces (including - lines that consist solely of whitespaces) and a space character - that is immediately followed by a tab character inside the - initial indent of the line are considered whitespace errors. - Exits with non-zero status if problems are found. Not compatible - with --exit-code. - ---ws-error-highlight=<kind>:: - Highlight whitespace errors in the `context`, `old` or `new` - lines of the diff. Multiple values are separated by comma, - `none` resets previous values, `default` reset the list to - `new` and `all` is a shorthand for `old,new,context`. When - this option is not given, and the configuration variable - `diff.wsErrorHighlight` is not set, only whitespace errors in - `new` lines are highlighted. The whitespace errors are colored - with `color.diff.whitespace`. - -endif::git-format-patch[] - ---full-index:: - Instead of the first handful of characters, show the full - pre- and post-image blob object names on the "index" - line when generating patch format output. - ---binary:: - In addition to `--full-index`, output a binary diff that - can be applied with `git-apply`. Implies `--patch`. - ---abbrev[=<n>]:: - Instead of showing the full 40-byte hexadecimal object - name in diff-raw format output and diff-tree header - lines, show only a partial prefix. This is - independent of the `--full-index` option above, which controls - the diff-patch output format. Non default number of - digits can be specified with `--abbrev=<n>`. - --B[<n>][/<m>]:: ---break-rewrites[=[<n>][/<m>]]:: - Break complete rewrite changes into pairs of delete and - create. This serves two purposes: -+ -It affects the way a change that amounts to a total rewrite of a file -not as a series of deletion and insertion mixed together with a very -few lines that happen to match textually as the context, but as a -single deletion of everything old followed by a single insertion of -everything new, and the number `m` controls this aspect of the -B -option (defaults to 60%). `-B/70%` specifies that less than 30% of the -original should remain in the result for Git to consider it a total -rewrite (i.e. otherwise the resulting patch will be a series of -deletion and insertion mixed together with context lines). -+ -When used with -M, a totally-rewritten file is also considered as the -source of a rename (usually -M only considers a file that disappeared -as the source of a rename), and the number `n` controls this aspect of -the -B option (defaults to 50%). `-B20%` specifies that a change with -addition and deletion compared to 20% or more of the file's size are -eligible for being picked up as a possible source of a rename to -another file. - --M[<n>]:: ---find-renames[=<n>]:: -ifndef::git-log[] - Detect renames. -endif::git-log[] -ifdef::git-log[] - If generating diffs, detect and report renames for each commit. - For following files across renames while traversing history, see - `--follow`. -endif::git-log[] - If `n` is specified, it is a threshold on the similarity - index (i.e. amount of addition/deletions compared to the - file's size). For example, `-M90%` means Git should consider a - delete/add pair to be a rename if more than 90% of the file - hasn't changed. Without a `%` sign, the number is to be read as - a fraction, with a decimal point before it. I.e., `-M5` becomes - 0.5, and is thus the same as `-M50%`. Similarly, `-M05` is - the same as `-M5%`. To limit detection to exact renames, use - `-M100%`. The default similarity index is 50%. - --C[<n>]:: ---find-copies[=<n>]:: - Detect copies as well as renames. See also `--find-copies-harder`. - If `n` is specified, it has the same meaning as for `-M<n>`. - ---find-copies-harder:: - For performance reasons, by default, `-C` option finds copies only - if the original file of the copy was modified in the same - changeset. This flag makes the command - inspect unmodified files as candidates for the source of - copy. This is a very expensive operation for large - projects, so use it with caution. Giving more than one - `-C` option has the same effect. - --D:: ---irreversible-delete:: - Omit the preimage for deletes, i.e. print only the header but not - the diff between the preimage and `/dev/null`. The resulting patch - is not meant to be applied with `patch` or `git apply`; this is - solely for people who want to just concentrate on reviewing the - text after the change. In addition, the output obviously lacks - enough information to apply such a patch in reverse, even manually, - hence the name of the option. -+ -When used together with `-B`, omit also the preimage in the deletion part -of a delete/create pair. - --l<num>:: - The `-M` and `-C` options require O(n^2) processing time where n - is the number of potential rename/copy targets. This - option prevents rename/copy detection from running if - the number of rename/copy targets exceeds the specified - number. - -ifndef::git-format-patch[] ---diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]:: - Select only files that are Added (`A`), Copied (`C`), - Deleted (`D`), Modified (`M`), Renamed (`R`), have their - type (i.e. regular file, symlink, submodule, ...) changed (`T`), - are Unmerged (`U`), are - Unknown (`X`), or have had their pairing Broken (`B`). - Any combination of the filter characters (including none) can be used. - When `*` (All-or-none) is added to the combination, all - paths are selected if there is any file that matches - other criteria in the comparison; if there is no file - that matches other criteria, nothing is selected. -+ -Also, these upper-case letters can be downcased to exclude. E.g. -`--diff-filter=ad` excludes added and deleted paths. -+ -Note that not all diffs can feature all types. For instance, diffs -from the index to the working tree can never have Added entries -(because the set of paths included in the diff is limited by what is in -the index). Similarly, copied and renamed entries cannot appear if -detection for those types is disabled. - --S<string>:: - Look for differences that change the number of occurrences of - the specified string (i.e. addition/deletion) in a file. - Intended for the scripter's use. -+ -It is useful when you're looking for an exact block of code (like a -struct), and want to know the history of that block since it first -came into being: use the feature iteratively to feed the interesting -block in the preimage back into `-S`, and keep going until you get the -very first version of the block. -+ -Binary files are searched as well. - --G<regex>:: - Look for differences whose patch text contains added/removed - lines that match <regex>. -+ -To illustrate the difference between `-S<regex> --pickaxe-regex` and -`-G<regex>`, consider a commit with the following diff in the same -file: -+ ----- -+ return !regexec(regexp, two->ptr, 1, ®match, 0); -... -- hit = !regexec(regexp, mf2.ptr, 1, ®match, 0); ----- -+ -While `git log -G"regexec\(regexp"` will show this commit, `git log --S"regexec\(regexp" --pickaxe-regex` will not (because the number of -occurrences of that string did not change). -+ -Unless `--text` is supplied patches of binary files without a textconv -filter will be ignored. -+ -See the 'pickaxe' entry in linkgit:gitdiffcore[7] for more -information. - ---find-object=<object-id>:: - Look for differences that change the number of occurrences of - the specified object. Similar to `-S`, just the argument is different - in that it doesn't search for a specific string but for a specific - object id. -+ -The object can be a blob or a submodule commit. It implies the `-t` option in -`git-log` to also find trees. - ---pickaxe-all:: - When `-S` or `-G` finds a change, show all the changes in that - changeset, not just the files that contain the change - in <string>. - ---pickaxe-regex:: - Treat the <string> given to `-S` as an extended POSIX regular - expression to match. - -endif::git-format-patch[] - --O<orderfile>:: - Control the order in which files appear in the output. - This overrides the `diff.orderFile` configuration variable - (see linkgit:git-config[1]). To cancel `diff.orderFile`, - use `-O/dev/null`. -+ -The output order is determined by the order of glob patterns in -<orderfile>. -All files with pathnames that match the first pattern are output -first, all files with pathnames that match the second pattern (but not -the first) are output next, and so on. -All files with pathnames that do not match any pattern are output -last, as if there was an implicit match-all pattern at the end of the -file. -If multiple pathnames have the same rank (they match the same pattern -but no earlier patterns), their output order relative to each other is -the normal order. -+ -<orderfile> is parsed as follows: -+ --- - - Blank lines are ignored, so they can be used as separators for - readability. - - - Lines starting with a hash ("`#`") are ignored, so they can be used - for comments. Add a backslash ("`\`") to the beginning of the - pattern if it starts with a hash. - - - Each other line contains a single pattern. --- -+ -Patterns have the same syntax and semantics as patterns used for -fnmatch(3) without the FNM_PATHNAME flag, except a pathname also -matches a pattern if removing any number of the final pathname -components matches the pattern. For example, the pattern "`foo*bar`" -matches "`fooasdfbar`" and "`foo/bar/baz/asdf`" but not "`foobarx`". - -ifndef::git-format-patch[] --R:: - Swap two inputs; that is, show differences from index or - on-disk file to tree contents. - ---relative[=<path>]:: - When run from a subdirectory of the project, it can be - told to exclude changes outside the directory and show - pathnames relative to it with this option. When you are - not in a subdirectory (e.g. in a bare repository), you - can name which subdirectory to make the output relative - to by giving a <path> as an argument. -endif::git-format-patch[] - --a:: ---text:: - Treat all files as text. - ---ignore-cr-at-eol:: - Ignore carriage-return at the end of line when doing a comparison. - ---ignore-space-at-eol:: - Ignore changes in whitespace at EOL. - --b:: ---ignore-space-change:: - Ignore changes in amount of whitespace. This ignores whitespace - at line end, and considers all other sequences of one or - more whitespace characters to be equivalent. - --w:: ---ignore-all-space:: - Ignore whitespace when comparing lines. This ignores - differences even if one line has whitespace where the other - line has none. - ---ignore-blank-lines:: - Ignore changes whose lines are all blank. - ---inter-hunk-context=<lines>:: - Show the context between diff hunks, up to the specified number - of lines, thereby fusing hunks that are close to each other. - Defaults to `diff.interHunkContext` or 0 if the config option - is unset. - --W:: ---function-context:: - Show whole surrounding functions of changes. - -ifndef::git-format-patch[] -ifndef::git-log[] ---exit-code:: - Make the program exit with codes similar to diff(1). - That is, it exits with 1 if there were differences and - 0 means no differences. - ---quiet:: - Disable all output of the program. Implies `--exit-code`. -endif::git-log[] -endif::git-format-patch[] - ---ext-diff:: - Allow an external diff helper to be executed. If you set an - external diff driver with linkgit:gitattributes[5], you need - to use this option with linkgit:git-log[1] and friends. - ---no-ext-diff:: - Disallow external diff drivers. - ---textconv:: ---no-textconv:: - Allow (or disallow) external text conversion filters to be run - when comparing binary files. See linkgit:gitattributes[5] for - details. Because textconv filters are typically a one-way - conversion, the resulting diff is suitable for human - consumption, but cannot be applied. For this reason, textconv - filters are enabled by default only for linkgit:git-diff[1] and - linkgit:git-log[1], but not for linkgit:git-format-patch[1] or - diff plumbing commands. - ---ignore-submodules[=<when>]:: - Ignore changes to submodules in the diff generation. <when> can be - either "none", "untracked", "dirty" or "all", which is the default. - Using "none" will consider the submodule modified when it either contains - untracked or modified files or its HEAD differs from the commit recorded - in the superproject and can be used to override any settings of the - 'ignore' option in linkgit:git-config[1] or linkgit:gitmodules[5]. When - "untracked" is used submodules are not considered dirty when they only - contain untracked content (but they are still scanned for modified - content). Using "dirty" ignores all changes to the work tree of submodules, - only changes to the commits stored in the superproject are shown (this was - the behavior until 1.7.0). Using "all" hides all changes to submodules. - ---src-prefix=<prefix>:: - Show the given source prefix instead of "a/". - ---dst-prefix=<prefix>:: - Show the given destination prefix instead of "b/". - ---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/third_party/git/Documentation/doc-diff b/third_party/git/Documentation/doc-diff deleted file mode 100755 index 3355be4798..0000000000 --- a/third_party/git/Documentation/doc-diff +++ /dev/null @@ -1,187 +0,0 @@ -#!/bin/sh -# -# Build two documentation trees and diff the resulting formatted output. -# Compared to a source diff, this can reveal mistakes in the formatting. -# For example: -# -# ./doc-diff origin/master HEAD -# -# would show the differences introduced by a branch based on master. - -OPTIONS_SPEC="\ -doc-diff [options] <from> <to> [-- <diff-options>] -doc-diff (-c|--clean) --- -j=n parallel argument to pass to make -f force rebuild; do not rely on cached results -c,clean cleanup temporary working files -from-asciidoc use asciidoc with the 'from'-commit -from-asciidoctor use asciidoctor with the 'from'-commit -asciidoc use asciidoc with both commits -to-asciidoc use asciidoc with the 'to'-commit -to-asciidoctor use asciidoctor with the 'to'-commit -asciidoctor use asciidoctor with both commits -cut-header-footer cut away header and footer -" -SUBDIRECTORY_OK=1 -. "$(git --exec-path)/git-sh-setup" - -parallel= -force= -clean= -from_program= -to_program= -cut_header_footer= -while test $# -gt 0 -do - case "$1" in - -j) - parallel=$2; shift ;; - -c|--clean) - clean=t ;; - -f) - force=t ;; - --from-asciidoctor) - from_program=-asciidoctor ;; - --to-asciidoctor) - to_program=-asciidoctor ;; - --asciidoctor) - from_program=-asciidoctor - to_program=-asciidoctor ;; - --from-asciidoc) - from_program=-asciidoc ;; - --to-asciidoc) - to_program=-asciidoc ;; - --asciidoc) - from_program=-asciidoc - to_program=-asciidoc ;; - --cut-header-footer) - cut_header_footer=-cut-header-footer ;; - --) - shift; break ;; - *) - usage ;; - esac - shift -done - -tmp="$(git rev-parse --show-toplevel)/Documentation/tmp-doc-diff" || exit 1 - -if test -n "$clean" -then - test $# -eq 0 || usage - git worktree remove --force "$tmp/worktree" 2>/dev/null - rm -rf "$tmp" - exit 0 -fi - -if test -z "$parallel" -then - parallel=$(getconf _NPROCESSORS_ONLN 2>/dev/null) - if test $? != 0 || test -z "$parallel" - then - parallel=1 - fi -fi - -test $# -gt 1 || usage -from=$1; shift -to=$1; shift - -from_oid=$(git rev-parse --verify "$from") || exit 1 -to_oid=$(git rev-parse --verify "$to") || exit 1 - -if test -n "$force" -then - rm -rf "$tmp" -fi - -# We'll do both builds in a single worktree, which lets "make" reuse -# results that don't differ between the two trees. -if ! test -d "$tmp/worktree" -then - git worktree add -f --detach "$tmp/worktree" "$from" && - dots=$(echo "$tmp/worktree" | sed 's#[^/]*#..#g') && - ln -s "$dots/config.mak" "$tmp/worktree/config.mak" -fi - -construct_makemanflags () { - if test "$1" = "-asciidoc" - then - echo USE_ASCIIDOCTOR= - elif test "$1" = "-asciidoctor" - then - echo USE_ASCIIDOCTOR=YesPlease - fi -} - -from_makemanflags=$(construct_makemanflags "$from_program") && -to_makemanflags=$(construct_makemanflags "$to_program") && - -from_dir=$from_oid$from_program$cut_header_footer && -to_dir=$to_oid$to_program$cut_header_footer && - -# generate_render_makefile <srcdir> <dstdir> -generate_render_makefile () { - find "$1" -type f | - while read src - do - dst=$2/${src#$1/} - printf 'all:: %s\n' "$dst" - printf '%s: %s\n' "$dst" "$src" - printf '\t@echo >&2 " RENDER $(notdir $@)" && \\\n' - printf '\tmkdir -p $(dir $@) && \\\n' - printf '\tMANWIDTH=80 man $< >$@+ && \\\n' - printf '\tmv $@+ $@\n' - done -} - -# render_tree <committish_oid> <directory_name> <makemanflags> -render_tree () { - # Skip install-man entirely if we already have an installed directory. - # We can't rely on make here, since "install-man" unconditionally - # copies the files (spending effort, but also updating timestamps that - # we then can't rely on during the render step). We use "mv" to make - # sure we don't get confused by a previous run that failed partway - # through. - oid=$1 && - dname=$2 && - makemanflags=$3 && - if ! test -d "$tmp/installed/$dname" - then - git -C "$tmp/worktree" checkout --detach "$oid" && - make -j$parallel -C "$tmp/worktree" \ - $makemanflags \ - GIT_VERSION=omitted \ - SOURCE_DATE_EPOCH=0 \ - DESTDIR="$tmp/installed/$dname+" \ - install-man && - mv "$tmp/installed/$dname+" "$tmp/installed/$dname" - fi && - - # As with "installed" above, we skip the render if it's already been - # done. So using make here is primarily just about running in - # parallel. - if ! test -d "$tmp/rendered/$dname" - then - generate_render_makefile "$tmp/installed/$dname" \ - "$tmp/rendered/$dname+" | - make -j$parallel -f - && - mv "$tmp/rendered/$dname+" "$tmp/rendered/$dname" - - if test "$cut_header_footer" = "-cut-header-footer" - then - for f in $(find "$tmp/rendered/$dname" -type f) - do - tail -n +3 "$f" | head -n -2 | - sed -e '1{/^$/d}' -e '${/^$/d}' >"$f+" && - mv "$f+" "$f" || - return 1 - done - fi - fi -} - -render_tree $from_oid $from_dir $from_makemanflags && -render_tree $to_oid $to_dir $to_makemanflags && -git -C $tmp/rendered diff --no-index "$@" $from_dir $to_dir diff --git a/third_party/git/Documentation/docbook-xsl.css b/third_party/git/Documentation/docbook-xsl.css deleted file mode 100644 index e11c8f053a..0000000000 --- a/third_party/git/Documentation/docbook-xsl.css +++ /dev/null @@ -1,296 +0,0 @@ -/* - CSS stylesheet for XHTML produced by DocBook XSL stylesheets. - Tested with XSL stylesheets 1.61.2, 1.67.2 -*/ - -span.strong { - font-weight: bold; -} - -body blockquote { - margin-top: .75em; - line-height: 1.5; - margin-bottom: .75em; -} - -html body { - margin: 1em 5% 1em 5%; - line-height: 1.2; - font-family: sans-serif; -} - -body div { - margin: 0; -} - -h1, h2, h3, h4, h5, h6, -div.toc p b, -div.list-of-figures p b, -div.list-of-tables p b, -div.abstract p.title -{ - color: #527bbd; - font-family: tahoma, verdana, sans-serif; -} - -div.toc p:first-child, -div.list-of-figures p:first-child, -div.list-of-tables p:first-child, -div.example p.title -{ - margin-bottom: 0.2em; -} - -body h1 { - margin: .0em 0 0 -4%; - line-height: 1.3; - border-bottom: 2px solid silver; -} - -body h2 { - margin: 0.5em 0 0 -4%; - line-height: 1.3; - border-bottom: 2px solid silver; -} - -body h3 { - margin: .8em 0 0 -3%; - line-height: 1.3; -} - -body h4 { - margin: .8em 0 0 -3%; - line-height: 1.3; -} - -body h5 { - margin: .8em 0 0 -2%; - line-height: 1.3; -} - -body h6 { - margin: .8em 0 0 -1%; - line-height: 1.3; -} - -body hr { - border: none; /* Broken on IE6 */ -} -div.footnotes hr { - border: 1px solid silver; -} - -div.navheader th, div.navheader td, div.navfooter td { - font-family: sans-serif; - font-size: 0.9em; - font-weight: bold; - color: #527bbd; -} -div.navheader img, div.navfooter img { - border-style: none; -} -div.navheader a, div.navfooter a { - font-weight: normal; -} -div.navfooter hr { - border: 1px solid silver; -} - -body td { - line-height: 1.2 -} - -body th { - line-height: 1.2; -} - -ol { - line-height: 1.2; -} - -ul, body dir, body menu { - line-height: 1.2; -} - -html { - margin: 0; - padding: 0; -} - -body h1, body h2, body h3, body h4, body h5, body h6 { - margin-left: 0 -} - -body pre { - margin: 0.5em 10% 0.5em 1em; - line-height: 1.0; - color: navy; -} - -tt.literal, code.literal { - color: navy; - font-family: sans-serif; -} - -code.literal:before { content: "'"; } -code.literal:after { content: "'"; } - -em { - font-style: italic; - color: #064; -} - -div.literallayout p { - padding: 0em; - margin: 0em; -} - -div.literallayout { - font-family: monospace; - margin: 0em; - color: navy; - border: 1px solid silver; - background: #f4f4f4; - padding: 0.5em; -} - -.programlisting, .screen { - border: 1px solid silver; - background: #f4f4f4; - margin: 0.5em 10% 0.5em 0; - padding: 0.5em 1em; -} - -div.sidebar { - background: #ffffee; - margin: 1.0em 10% 0.5em 0; - padding: 0.5em 1em; - border: 1px solid silver; -} -div.sidebar * { padding: 0; } -div.sidebar div { margin: 0; } -div.sidebar p.title { - font-family: sans-serif; - margin-top: 0.5em; - margin-bottom: 0.2em; -} - -div.bibliomixed { - margin: 0.5em 5% 0.5em 1em; -} - -div.glossary dt { - font-weight: bold; -} -div.glossary dd p { - margin-top: 0.2em; -} - -dl { - margin: .8em 0; - line-height: 1.2; -} - -dt { - margin-top: 0.5em; -} - -dt span.term { - font-style: normal; - color: navy; -} - -div.variablelist dd p { - margin-top: 0; -} - -div.itemizedlist li, div.orderedlist li { - margin-left: -0.8em; - margin-top: 0.5em; -} - -ul, ol { - list-style-position: outside; -} - -div.sidebar ul, div.sidebar ol { - margin-left: 2.8em; -} - -div.itemizedlist p.title, -div.orderedlist p.title, -div.variablelist p.title -{ - margin-bottom: -0.8em; -} - -div.revhistory table { - border-collapse: collapse; - border: none; -} -div.revhistory th { - border: none; - color: #527bbd; - font-family: tahoma, verdana, sans-serif; -} -div.revhistory td { - border: 1px solid silver; -} - -/* Keep TOC and index lines close together. */ -div.toc dl, div.toc dt, -div.list-of-figures dl, div.list-of-figures dt, -div.list-of-tables dl, div.list-of-tables dt, -div.indexdiv dl, div.indexdiv dt -{ - line-height: normal; - margin-top: 0; - margin-bottom: 0; -} - -/* - Table styling does not work because of overriding attributes in - generated HTML. -*/ -div.table table, -div.informaltable table -{ - margin-left: 0; - margin-right: 5%; - margin-bottom: 0.8em; -} -div.informaltable table -{ - margin-top: 0.4em -} -div.table thead, -div.table tfoot, -div.table tbody, -div.informaltable thead, -div.informaltable tfoot, -div.informaltable tbody -{ - /* No effect in IE6. */ - border-top: 2px solid #527bbd; - border-bottom: 2px solid #527bbd; -} -div.table thead, div.table tfoot, -div.informaltable thead, div.informaltable tfoot -{ - font-weight: bold; -} - -div.mediaobject img { - border: 1px solid silver; - margin-bottom: 0.8em; -} -div.figure p.title, -div.table p.title -{ - margin-top: 1em; - margin-bottom: 0.4em; -} - -@media print { - div.navheader, div.navfooter { display: none; } -} diff --git a/third_party/git/Documentation/docbook.xsl b/third_party/git/Documentation/docbook.xsl deleted file mode 100644 index da8b05b922..0000000000 --- a/third_party/git/Documentation/docbook.xsl +++ /dev/null @@ -1,8 +0,0 @@ -<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - version='1.0'> - <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl"/> - <xsl:output method="html" - encoding="UTF-8" indent="no" - doctype-public="-//W3C//DTD HTML 4.01//EN" - doctype-system="http://www.w3.org/TR/html4/strict.dtd" /> -</xsl:stylesheet> diff --git a/third_party/git/Documentation/everyday.txto b/third_party/git/Documentation/everyday.txto deleted file mode 100644 index ae555bd47e..0000000000 --- a/third_party/git/Documentation/everyday.txto +++ /dev/null @@ -1,9 +0,0 @@ -Everyday Git With 20 Commands Or So -=================================== - -This document has been moved to linkgit:giteveryday[7]. - -Please let the owners of the referring site know so that they can update the -link you clicked to get here. - -Thanks. diff --git a/third_party/git/Documentation/fetch-options.txt b/third_party/git/Documentation/fetch-options.txt deleted file mode 100644 index 3c9b4f9e09..0000000000 --- a/third_party/git/Documentation/fetch-options.txt +++ /dev/null @@ -1,247 +0,0 @@ ---all:: - Fetch all remotes. - --a:: ---append:: - Append ref names and object names of fetched refs to the - existing contents of `.git/FETCH_HEAD`. Without this - option old data in `.git/FETCH_HEAD` will be overwritten. - ---depth=<depth>:: - Limit fetching to the specified number of commits from the tip of - each remote branch history. If fetching to a 'shallow' repository - created by `git clone` with `--depth=<depth>` option (see - 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 - imposed by shallow repositories. -+ -If the source repository is shallow, fetch as much as possible so that -the current repository has the same history as the source repository. - ---update-shallow:: - By default when fetching from a shallow repository, - `git fetch` refuses refs that require updating - .git/shallow. This option updates .git/shallow and accept such - refs. - ---negotiation-tip=<commit|glob>:: - By default, Git will report, to the server, commits reachable - from all local refs to find common commits in an attempt to - reduce the size of the to-be-received packfile. If specified, - Git will only report commits reachable from the given tips. - This is useful to speed up fetches when the user knows which - local ref is likely to have commits in common with the - upstream ref being fetched. -+ -This option may be specified more than once; if so, Git will report -commits reachable from any of the given commits. -+ -The argument to this option may be a glob on ref names, a ref, or the (possibly -abbreviated) SHA-1 of a commit. Specifying a glob is equivalent to specifying -this option multiple times, one for each matching ref name. -+ -See also the `fetch.negotiationAlgorithm` configuration variable -documented in linkgit:git-config[1]. - -ifndef::git-pull[] ---dry-run:: - Show what would be done, without making any changes. -endif::git-pull[] - --f:: ---force:: - When 'git fetch' is used with `<src>:<dst>` refspec it may - refuse to update the local branch as discussed -ifdef::git-pull[] - in the `<refspec>` part of the linkgit:git-fetch[1] - documentation. -endif::git-pull[] -ifndef::git-pull[] - in the `<refspec>` part below. -endif::git-pull[] - This option overrides that check. - --k:: ---keep:: - Keep downloaded pack. - -ifndef::git-pull[] ---multiple:: - Allow several <repository> and <group> arguments to be - specified. No <refspec>s may be specified. - ---[no-]auto-gc:: - Run `git gc --auto` at the end to perform garbage collection - if needed. This is enabled by default. - --p:: ---prune:: - Before fetching, remove any remote-tracking references that no - longer exist on the remote. Tags are not subject to pruning - if they are fetched only because of the default tag - auto-following or due to a --tags option. However, if tags - are fetched due to an explicit refspec (either on the command - line or in the remote configuration, for example if the remote - was cloned with the --mirror option), then they are also - subject to pruning. Supplying `--prune-tags` is a shorthand for - providing the tag refspec. -+ -See the PRUNING section below for more details. - --P:: ---prune-tags:: - Before fetching, remove any local tags that no longer exist on - the remote if `--prune` is enabled. This option should be used - more carefully, unlike `--prune` it will remove any local - references (local tags) that have been created. This option is - a shorthand for providing the explicit tag refspec along with - `--prune`, see the discussion about that in its documentation. -+ -See the PRUNING section below for more details. - -endif::git-pull[] - -ifndef::git-pull[] --n:: -endif::git-pull[] ---no-tags:: - By default, tags that point at objects that are downloaded - from the remote repository are fetched and stored locally. - This option disables this automatic tag following. The default - behavior for a remote may be specified with the remote.<name>.tagOpt - setting. See linkgit:git-config[1]. - -ifndef::git-pull[] ---refmap=<refspec>:: - When fetching refs listed on the command line, use the - specified refspec (can be given more than once) to map the - refs to remote-tracking branches, instead of the values of - `remote.*.fetch` configuration variables for the remote - repository. See section on "Configured Remote-tracking - Branches" for details. - --t:: ---tags:: - Fetch all tags from the remote (i.e., fetch remote tags - `refs/tags/*` into local tags with the same name), in addition - to whatever else would otherwise be fetched. Using this - option alone does not subject tags to pruning, even if --prune - is used (though tags may be pruned anyway if they are also the - destination of an explicit refspec; see `--prune`). - ---recurse-submodules[=yes|on-demand|no]:: - This option controls if and under what conditions new commits of - populated submodules should be fetched too. It can be used as a - boolean option to completely disable recursion when set to 'no' or to - unconditionally recurse into all populated submodules when set to - 'yes', which is the default when this option is used without any - value. Use 'on-demand' to only recurse into a populated submodule - when the superproject retrieves a commit that updates the submodule's - reference to a commit that isn't already in the local submodule - clone. - --j:: ---jobs=<n>:: - Number of parallel children to be used for fetching submodules. - Each will fetch from different submodules, such that fetching many - submodules will be faster. By default submodules will be fetched - one at a time. - ---no-recurse-submodules:: - Disable recursive fetching of submodules (this has the same effect as - using the `--recurse-submodules=no` option). - ---submodule-prefix=<path>:: - Prepend <path> to paths printed in informative messages - such as "Fetching submodule foo". This option is used - internally when recursing over submodules. - ---recurse-submodules-default=[yes|on-demand]:: - This option is used internally to temporarily provide a - non-negative default value for the --recurse-submodules - option. All other methods of configuring fetch's submodule - recursion (such as settings in linkgit:gitmodules[5] and - linkgit:git-config[1]) override this option, as does - specifying --[no-]recurse-submodules directly. -endif::git-pull[] - --u:: ---update-head-ok:: - By default 'git fetch' refuses to update the head which - corresponds to the current branch. This flag disables the - check. This is purely for the internal use for 'git pull' - to communicate with 'git fetch', and unless you are - implementing your own Porcelain you are not supposed to - use it. - ---upload-pack <upload-pack>:: - When given, and the repository to fetch from is handled - by 'git fetch-pack', `--exec=<upload-pack>` is passed to - the command to specify non-default path for the command - run on the other end. - -ifndef::git-pull[] --q:: ---quiet:: - Pass --quiet to git-fetch-pack and silence any other internally - used git commands. Progress is not reported to the standard error - stream. - --v:: ---verbose:: - Be verbose. -endif::git-pull[] - ---progress:: - Progress status is reported on the standard error stream - by default when it is attached to a terminal, unless -q - is specified. This flag forces progress status even if the - standard error stream is not directed to a terminal. - --o <option>:: ---server-option=<option>:: - Transmit the given string to the server when communicating using - protocol version 2. The given string must not contain a NUL or LF - character. The server's handling of server options, including - unknown ones, is server-specific. - When multiple `--server-option=<option>` are given, they are all - sent to the other side in the order listed on the command line. - ---show-forced-updates:: - By default, git checks if a branch is force-updated during - fetch. This can be disabled through fetch.showForcedUpdates, but - the --show-forced-updates option guarantees this check occurs. - See linkgit:git-config[1]. - ---no-show-forced-updates:: - By default, git checks if a branch is force-updated during - fetch. Pass --no-show-forced-updates or set fetch.showForcedUpdates - to false to skip this check for performance reasons. If used during - 'git-pull' the --ff-only option will still check for forced updates - before attempting a fast-forward update. See linkgit:git-config[1]. - --4:: ---ipv4:: - Use IPv4 addresses only, ignoring IPv6 addresses. - --6:: ---ipv6:: - Use IPv6 addresses only, ignoring IPv4 addresses. diff --git a/third_party/git/Documentation/fix-texi.perl b/third_party/git/Documentation/fix-texi.perl deleted file mode 100755 index ff7d78f620..0000000000 --- a/third_party/git/Documentation/fix-texi.perl +++ /dev/null @@ -1,15 +0,0 @@ -#!/usr/bin/perl -w - -while (<>) { - if (/^\@setfilename/) { - $_ = "\@setfilename git.info\n"; - } elsif (/^\@direntry/) { - print '@dircategory Development -@direntry -* Git: (git). A fast distributed revision control system -@end direntry -'; } - unless (/^\@direntry/../^\@end direntry/) { - print; - } -} diff --git a/third_party/git/Documentation/git-add.txt b/third_party/git/Documentation/git-add.txt deleted file mode 100644 index 8b0e4c7fa8..0000000000 --- a/third_party/git/Documentation/git-add.txt +++ /dev/null @@ -1,424 +0,0 @@ -git-add(1) -========== - -NAME ----- -git-add - Add file contents to the index - -SYNOPSIS --------- -[verse] -'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] [--renormalize] - [--chmod=(+|-)x] [--] [<pathspec>...] - -DESCRIPTION ------------ -This command updates the index using the current content found in -the working tree, to prepare the content staged for the next commit. -It typically adds the current content of existing paths as a whole, -but with some options it can also be used to add content with -only part of the changes made to the working tree files applied, or -remove paths that do not exist in the working tree anymore. - -The "index" holds a snapshot of the content of the working tree, and it -is this snapshot that is taken as the contents of the next commit. Thus -after making any changes to the working tree, and before running -the commit command, you must use the `add` command to add any new or -modified files to the index. - -This command can be performed multiple times before a commit. It only -adds the content of the specified file(s) at the time the add command is -run; if you want subsequent changes included in the next commit, then -you must run `git add` again to add the new content to the index. - -The `git status` command can be used to obtain a summary of which -files have changes that are staged for the next commit. - -The `git add` command will not add ignored files by default. If any -ignored files were explicitly specified on the command line, `git add` -will fail with a list of ignored files. Ignored files reached by -directory recursion or filename globbing performed by Git (quote your -globs before the shell) will be silently ignored. The 'git add' command can -be used to add ignored files with the `-f` (force) option. - -Please see linkgit:git-commit[1] for alternative ways to add content to a -commit. - - -OPTIONS -------- -<pathspec>...:: - Files to add content from. Fileglobs (e.g. `*.c`) can - be given to add all matching files. Also a - leading directory name (e.g. `dir` to add `dir/file1` - and `dir/file2`) can be given to update the index to - match the current state of the directory as a whole (e.g. - specifying `dir` will record not just a file `dir/file1` - modified in the working tree, a file `dir/file2` added to - the working tree, but also a file `dir/file3` removed from - the working tree). Note that older versions of Git used - to ignore removed files; use `--no-all` option if you want - to add modified or new files but ignore removed ones. -+ -For more details about the <pathspec> syntax, see the 'pathspec' entry -in linkgit:gitglossary[7]. - --n:: ---dry-run:: - Don't actually add the file(s), just show if they exist and/or will - be ignored. - --v:: ---verbose:: - Be verbose. - --f:: ---force:: - Allow adding otherwise ignored files. - --i:: ---interactive:: - Add modified contents in the working tree interactively to - the index. Optional path arguments may be supplied to limit - operation to a subset of the working tree. See ``Interactive - mode'' for details. - --p:: ---patch:: - Interactively choose hunks of patch between the index and the - work tree and add them to the index. This gives the user a chance - to review the difference before adding modified contents to the - index. -+ -This effectively runs `add --interactive`, but bypasses the -initial command menu and directly jumps to the `patch` subcommand. -See ``Interactive mode'' for details. - --e:: ---edit:: - Open the diff vs. the index in an editor and let the user - edit it. After the editor was closed, adjust the hunk headers - and apply the patch to the index. -+ -The intent of this option is to pick and choose lines of the patch to -apply, or even to modify the contents of lines to be staged. This can be -quicker and more flexible than using the interactive hunk selector. -However, it is easy to confuse oneself and create a patch that does not -apply to the index. See EDITING PATCHES below. - --u:: ---update:: - Update the index just where it already has an entry matching - <pathspec>. This removes as well as modifies index entries to - match the working tree, but adds no new files. -+ -If no <pathspec> is given when `-u` option is used, all -tracked files in the entire working tree are updated (old versions -of Git used to limit the update to the current directory and its -subdirectories). - --A:: ---all:: ---no-ignore-removal:: - Update the index not only where the working tree has a file - matching <pathspec> but also where the index already has an - entry. This adds, modifies, and removes index entries to - match the working tree. -+ -If no <pathspec> is given when `-A` option is used, all -files in the entire working tree are updated (old versions -of Git used to limit the update to the current directory and its -subdirectories). - ---no-all:: ---ignore-removal:: - Update the index by adding new files that are unknown to the - index and files modified in the working tree, but ignore - files that have been removed from the working tree. This - option is a no-op when no <pathspec> is used. -+ -This option is primarily to help users who are used to older -versions of Git, whose "git add <pathspec>..." was a synonym -for "git add --no-all <pathspec>...", i.e. ignored removed files. - --N:: ---intent-to-add:: - Record only the fact that the path will be added later. An entry - for the path is placed in the index with no content. This is - useful for, among other things, showing the unstaged content of - such files with `git diff` and committing them with `git commit - -a`. - ---refresh:: - Don't add the file(s), but only refresh their stat() - information in the index. - ---ignore-errors:: - If some files could not be added because of errors indexing - them, do not abort the operation, but continue adding the - others. The command shall still exit with non-zero status. - The configuration variable `add.ignoreErrors` can be set to - true to make this the default behaviour. - ---ignore-missing:: - This option can only be used together with --dry-run. By using - this option the user can check if any of the given files would - be ignored, no matter if they are already present in the work - tree or not. - ---no-warn-embedded-repo:: - By default, `git add` will warn when adding an embedded - repository to the index without using `git submodule add` to - create an entry in `.gitmodules`. This option will suppress the - warning (e.g., if you are manually performing operations on - submodules). - ---renormalize:: - Apply the "clean" process freshly to all tracked files to - forcibly add them again to the index. This is useful after - changing `core.autocrlf` configuration or the `text` attribute - in order to correct files added with wrong CRLF/LF line endings. - This option implies `-u`. - ---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 - for command-line options). - - -EXAMPLES --------- - -* Adds content from all `*.txt` files under `Documentation` directory - and its subdirectories: -+ ------------- -$ git add Documentation/\*.txt ------------- -+ -Note that the asterisk `*` is quoted from the shell in this -example; this lets the command include the files from -subdirectories of `Documentation/` directory. - -* Considers adding content from all git-*.sh scripts: -+ ------------- -$ git add git-*.sh ------------- -+ -Because this example lets the shell expand the asterisk (i.e. you are -listing the files explicitly), it does not consider -`subdir/git-foo.sh`. - -INTERACTIVE MODE ----------------- -When the command enters the interactive mode, it shows the -output of the 'status' subcommand, and then goes into its -interactive command loop. - -The command loop shows the list of subcommands available, and -gives a prompt "What now> ". In general, when the prompt ends -with a single '>', you can pick only one of the choices given -and type return, like this: - ------------- - *** Commands *** - 1: status 2: update 3: revert 4: add untracked - 5: patch 6: diff 7: quit 8: help - What now> 1 ------------- - -You also could say `s` or `sta` or `status` above as long as the -choice is unique. - -The main command loop has 6 subcommands (plus help and quit). - -status:: - - This shows the change between HEAD and index (i.e. what will be - committed if you say `git commit`), and between index and - working tree files (i.e. what you could stage further before - `git commit` using `git add`) for each path. A sample output - looks like this: -+ ------------- - staged unstaged path - 1: binary nothing foo.png - 2: +403/-35 +1/-1 git-add--interactive.perl ------------- -+ -It shows that foo.png has differences from HEAD (but that is -binary so line count cannot be shown) and there is no -difference between indexed copy and the working tree -version (if the working tree version were also different, -'binary' would have been shown in place of 'nothing'). The -other file, git-add{litdd}interactive.perl, has 403 lines added -and 35 lines deleted if you commit what is in the index, but -working tree file has further modifications (one addition and -one deletion). - -update:: - - This shows the status information and issues an "Update>>" - prompt. When the prompt ends with double '>>', you can - make more than one selection, concatenated with whitespace or - comma. Also you can say ranges. E.g. "2-5 7,9" to choose - 2,3,4,5,7,9 from the list. If the second number in a range is - omitted, all remaining patches are taken. E.g. "7-" to choose - 7,8,9 from the list. You can say '*' to choose everything. -+ -What you chose are then highlighted with '*', -like this: -+ ------------- - staged unstaged path - 1: binary nothing foo.png -* 2: +403/-35 +1/-1 git-add--interactive.perl ------------- -+ -To remove selection, prefix the input with `-` -like this: -+ ------------- -Update>> -2 ------------- -+ -After making the selection, answer with an empty line to stage the -contents of working tree files for selected paths in the index. - -revert:: - - This has a very similar UI to 'update', and the staged - information for selected paths are reverted to that of the - HEAD version. Reverting new paths makes them untracked. - -add untracked:: - - This has a very similar UI to 'update' and - 'revert', and lets you add untracked paths to the index. - -patch:: - - This lets you choose one path out of a 'status' like selection. - After choosing the path, it presents the diff between the index - and the working tree file and asks you if you want to stage - the change of each hunk. You can select one of the following - options and type return: - - y - stage this hunk - n - do not stage this hunk - q - quit; do not stage this hunk or any of the remaining ones - a - stage this hunk and all later hunks in the file - d - do not stage this hunk or any of the later hunks in the file - g - select a hunk to go to - / - search for a hunk matching the given regex - j - leave this hunk undecided, see next undecided hunk - J - leave this hunk undecided, see next hunk - k - leave this hunk undecided, see previous undecided hunk - K - leave this hunk undecided, see previous hunk - s - split the current hunk into smaller hunks - e - manually edit the current hunk - ? - print help -+ -After deciding the fate for all hunks, if there is any hunk -that was chosen, the index is updated with the selected hunks. -+ -You can omit having to type return here, by setting the configuration -variable `interactive.singleKey` to `true`. - -diff:: - - This lets you review what will be committed (i.e. between - HEAD and index). - - -EDITING PATCHES ---------------- - -Invoking `git add -e` or selecting `e` from the interactive hunk -selector will open a patch in your editor; after the editor exits, the -result is applied to the index. You are free to make arbitrary changes -to the patch, but note that some changes may have confusing results, or -even result in a patch that cannot be applied. If you want to abort the -operation entirely (i.e., stage nothing new in the index), simply delete -all lines of the patch. The list below describes some common things you -may see in a patch, and which editing operations make sense on them. - --- -added content:: - -Added content is represented by lines beginning with "{plus}". You can -prevent staging any addition lines by deleting them. - -removed content:: - -Removed content is represented by lines beginning with "-". You can -prevent staging their removal by converting the "-" to a " " (space). - -modified content:: - -Modified content is represented by "-" lines (removing the old content) -followed by "{plus}" lines (adding the replacement content). You can -prevent staging the modification by converting "-" lines to " ", and -removing "{plus}" lines. Beware that modifying only half of the pair is -likely to introduce confusing changes to the index. --- - -There are also more complex operations that can be performed. But beware -that because the patch is applied only to the index and not the working -tree, the working tree will appear to "undo" the change in the index. -For example, introducing a new line into the index that is in neither -the HEAD nor the working tree will stage the new line for commit, but -the line will appear to be reverted in the working tree. - -Avoid using these constructs, or do so with extreme caution. - --- -removing untouched content:: - -Content which does not differ between the index and working tree may be -shown on context lines, beginning with a " " (space). You can stage -context lines for removal by converting the space to a "-". The -resulting working tree file will appear to re-add the content. - -modifying existing content:: - -One can also modify context lines by staging them for removal (by -converting " " to "-") and adding a "{plus}" line with the new content. -Similarly, one can modify "{plus}" lines for existing additions or -modifications. In all cases, the new modification will appear reverted -in the working tree. - -new content:: - -You may also add new content that does not exist in the patch; simply -add new lines, each starting with "{plus}". The addition will appear -reverted in the working tree. --- - -There are also several operations which should be avoided entirely, as -they will make the patch impossible to apply: - -* adding context (" ") or removal ("-") lines -* deleting context or removal lines -* modifying the contents of context or removal lines - -SEE ALSO --------- -linkgit:git-status[1] -linkgit:git-rm[1] -linkgit:git-reset[1] -linkgit:git-mv[1] -linkgit:git-commit[1] -linkgit:git-update-index[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-am.txt b/third_party/git/Documentation/git-am.txt deleted file mode 100644 index fc3b993c33..0000000000 --- a/third_party/git/Documentation/git-am.txt +++ /dev/null @@ -1,245 +0,0 @@ -git-am(1) -========= - -NAME ----- -git-am - Apply a series of patches from a mailbox - - -SYNOPSIS --------- -[verse] -'git am' [--signoff] [--keep] [--[no-]keep-cr] [--[no-]utf8] - [--[no-]3way] [--interactive] [--committer-date-is-author-date] - [--ignore-date] [--ignore-space-change | --ignore-whitespace] - [--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>] - [--exclude=<path>] [--include=<path>] [--reject] [-q | --quiet] - [--[no-]scissors] [-S[<keyid>]] [--patch-format=<format>] - [(<mbox> | <Maildir>)...] -'git am' (--continue | --skip | --abort | --quit | --show-current-patch) - -DESCRIPTION ------------ -Splits mail messages in a mailbox into commit log message, -authorship information and patches, and applies them to the -current branch. - -OPTIONS -------- -(<mbox>|<Maildir>)...:: - The list of mailbox files to read patches from. If you do not - supply this argument, the command reads from the standard input. - If you supply directories, they will be treated as Maildirs. - --s:: ---signoff:: - Add a `Signed-off-by:` line to the commit message, using - the committer identity of yourself. - See the signoff option in linkgit:git-commit[1] for more information. - --k:: ---keep:: - Pass `-k` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]). - ---keep-non-patch:: - Pass `-b` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]). - ---[no-]keep-cr:: - With `--keep-cr`, call 'git mailsplit' (see linkgit:git-mailsplit[1]) - with the same option, to prevent it from stripping CR at the end of - lines. `am.keepcr` configuration variable can be used to specify the - default behaviour. `--no-keep-cr` is useful to override `am.keepcr`. - --c:: ---scissors:: - Remove everything in body before a scissors line (see - linkgit:git-mailinfo[1]). Can be activated by default using - the `mailinfo.scissors` configuration variable. - ---no-scissors:: - Ignore scissors lines (see linkgit:git-mailinfo[1]). - --m:: ---message-id:: - Pass the `-m` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]), - so that the Message-ID header is added to the commit message. - The `am.messageid` configuration variable can be used to specify - the default behaviour. - ---no-message-id:: - Do not add the Message-ID header to the commit message. - `no-message-id` is useful to override `am.messageid`. - --q:: ---quiet:: - Be quiet. Only print error messages. - --u:: ---utf8:: - Pass `-u` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]). - The proposed commit log message taken from the e-mail - is re-coded into UTF-8 encoding (configuration variable - `i18n.commitencoding` can be used to specify project's - preferred encoding if it is not UTF-8). -+ -This was optional in prior versions of git, but now it is the -default. You can use `--no-utf8` to override this. - ---no-utf8:: - Pass `-n` flag to 'git mailinfo' (see - linkgit:git-mailinfo[1]). - --3:: ---3way:: ---no-3way:: - When the patch does not apply cleanly, fall back on - 3-way merge if the patch records the identity of blobs - it is supposed to apply to and we have those blobs - available locally. `--no-3way` can be used to override - am.threeWay configuration variable. For more information, - see am.threeWay in linkgit:git-config[1]. - ---rerere-autoupdate:: ---no-rerere-autoupdate:: - Allow the rerere mechanism to update the index with the - result of auto-conflict resolution if possible. - ---ignore-space-change:: ---ignore-whitespace:: ---whitespace=<option>:: --C<n>:: --p<n>:: ---directory=<dir>:: ---exclude=<path>:: ---include=<path>:: ---reject:: - These flags are passed to the 'git apply' (see linkgit:git-apply[1]) - program that applies - the patch. - ---patch-format:: - By default the command will try to detect the patch format - automatically. This option allows the user to bypass the automatic - detection and specify the patch format that the patch(es) should be - interpreted as. Valid formats are mbox, mboxrd, - stgit, stgit-series and hg. - --i:: ---interactive:: - Run interactively. - ---committer-date-is-author-date:: - By default the command records the date from the e-mail - message as the commit author date, and uses the time of - commit creation as the committer date. This allows the - user to lie about the committer date by using the same - value as the author date. - ---ignore-date:: - By default the command records the date from the e-mail - message as the commit author date, and uses the time of - commit creation as the committer date. This allows the - user to lie about the author date by using the same - value as the committer date. - ---skip:: - Skip the current patch. This is only meaningful when - restarting an aborted patch. - --S[<keyid>]:: ---gpg-sign[=<keyid>]:: - GPG-sign commits. The `keyid` argument is optional and - defaults to the committer identity; if specified, it must be - stuck to the option without a space. - ---continue:: --r:: ---resolved:: - After a patch failure (e.g. attempting to apply - conflicting patch), the user has applied it by hand and - the index file stores the result of the application. - Make a commit using the authorship and commit log - extracted from the e-mail message and the current index - file, and continue. - ---resolvemsg=<msg>:: - When a patch failure occurs, <msg> will be printed - to the screen before exiting. This overrides the - standard message informing you to use `--continue` - or `--skip` to handle the failure. This is solely - for internal use between 'git rebase' and 'git am'. - ---abort:: - Restore the original branch and abort the patching operation. - ---quit:: - Abort the patching operation but keep HEAD and the index - untouched. - ---show-current-patch:: - Show the patch being applied when "git am" is stopped because - of conflicts. - -DISCUSSION ----------- - -The commit author name is taken from the "From: " line of the -message, and commit author date is taken from the "Date: " line -of the message. The "Subject: " line is used as the title of -the commit, after stripping common prefix "[PATCH <anything>]". -The "Subject: " line is supposed to concisely describe what the -commit is about in one line of text. - -"From: " and "Subject: " lines starting the body override the respective -commit author name and title values taken from the headers. - -The commit message is formed by the title taken from the -"Subject: ", a blank line and the body of the message up to -where the patch begins. Excess whitespace at the end of each -line is automatically stripped. - -The patch is expected to be inline, directly following the -message. Any line that is of the form: - -* three-dashes and end-of-line, or -* a line that begins with "diff -", or -* a line that begins with "Index: " - -is taken as the beginning of a patch, and the commit log message -is terminated before the first occurrence of such a line. - -When initially invoking `git am`, you give it the names of the mailboxes -to process. Upon seeing the first patch that does not apply, it -aborts in the middle. You can recover from this in one of two ways: - -. skip the current patch by re-running the command with the `--skip` - option. - -. hand resolve the conflict in the working directory, and update - the index file to bring it into a state that the patch should - have produced. Then run the command with the `--continue` option. - -The command refuses to process new mailboxes until the current -operation is finished, so if you decide to start over from scratch, -run `git am --abort` before running the command with mailbox -names. - -Before any patches are applied, ORIG_HEAD is set to the tip of the -current branch. This is useful if you have problems with multiple -commits, like running 'git am' on the wrong branch or an error in the -commits that is more easily fixed by changing the mailbox (e.g. -errors in the "From:" lines). - -HOOKS ------ -This command can run `applypatch-msg`, `pre-applypatch`, -and `post-applypatch` hooks. See linkgit:githooks[5] for more -information. - -SEE ALSO --------- -linkgit:git-apply[1]. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-annotate.txt b/third_party/git/Documentation/git-annotate.txt deleted file mode 100644 index e44a831339..0000000000 --- a/third_party/git/Documentation/git-annotate.txt +++ /dev/null @@ -1,33 +0,0 @@ -git-annotate(1) -=============== - -NAME ----- -git-annotate - Annotate file lines with commit information - -SYNOPSIS --------- -[verse] -'git annotate' [<options>] <file> [<revision>] - -DESCRIPTION ------------ -Annotates each line in the given file with information from the commit -which introduced the line. Optionally annotates from a given revision. - -The only difference between this command and linkgit:git-blame[1] is that -they use slightly different output formats, and this command exists only -for backward compatibility to support existing scripts, and provide a more -familiar command name for people coming from other SCM systems. - -OPTIONS -------- -include::blame-options.txt[] - -SEE ALSO --------- -linkgit:git-blame[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-apply.txt b/third_party/git/Documentation/git-apply.txt deleted file mode 100644 index b9aa39000f..0000000000 --- a/third_party/git/Documentation/git-apply.txt +++ /dev/null @@ -1,285 +0,0 @@ -git-apply(1) -============ - -NAME ----- -git-apply - Apply a patch to files and/or to the index - - -SYNOPSIS --------- -[verse] -'git apply' [--stat] [--numstat] [--summary] [--check] [--index | --intent-to-add] [--3way] - [--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse] - [--allow-binary-replacement | --binary] [--reject] [-z] - [-p<n>] [-C<n>] [--inaccurate-eof] [--recount] [--cached] - [--ignore-space-change | --ignore-whitespace] - [--whitespace=(nowarn|warn|fix|error|error-all)] - [--exclude=<path>] [--include=<path>] [--directory=<root>] - [--verbose] [--unsafe-paths] [<patch>...] - -DESCRIPTION ------------ -Reads the supplied diff output (i.e. "a patch") and applies it to files. -When running from a subdirectory in a repository, patched paths -outside the directory are ignored. -With the `--index` option the patch is also applied to the index, and -with the `--cached` option the patch is only applied to the index. -Without these options, the command applies the patch only to files, -and does not require them to be in a Git repository. - -This command applies the patch but does not create a commit. Use -linkgit:git-am[1] to create commits from patches generated by -linkgit:git-format-patch[1] and/or received by email. - -OPTIONS -------- -<patch>...:: - The files to read the patch from. '-' can be used to read - from the standard input. - ---stat:: - Instead of applying the patch, output diffstat for the - input. Turns off "apply". - ---numstat:: - Similar to `--stat`, but shows the number of added and - deleted lines in decimal notation and the pathname without - abbreviation, to make it more machine friendly. For - binary files, outputs two `-` instead of saying - `0 0`. Turns off "apply". - ---summary:: - Instead of applying the patch, output a condensed - summary of information obtained from git diff extended - headers, such as creations, renames and mode changes. - Turns off "apply". - ---check:: - Instead of applying the patch, see if the patch is - applicable to the current working tree and/or the index - file and detects errors. Turns off "apply". - ---index:: - When `--check` is in effect, or when applying the patch - (which is the default when none of the options that - disables it is in effect), make sure the patch is - applicable to what the current index file records. If - the file to be patched in the working tree is not - up to date, it is flagged as an error. This flag also - causes the index file to be updated. - ---cached:: - Apply a patch without touching the working tree. Instead take the - cached data, apply the patch, and store the result in the index - without using the working tree. This implies `--index`. - ---intent-to-add:: - When applying the patch only to the working tree, mark new - files to be added to the index later (see `--intent-to-add` - option in linkgit:git-add[1]). This option is ignored unless - running in a Git repository and `--index` is not specified. - Note that `--index` could be implied by other options such - as `--cached` or `--3way`. - --3:: ---3way:: - When the patch does not apply cleanly, fall back on 3-way merge if - the patch records the identity of blobs it is supposed to apply to, - and we have those blobs available locally, possibly leaving the - conflict markers in the files in the working tree for the user to - resolve. This option implies the `--index` option, and is incompatible - with the `--reject` and the `--cached` options. - ---build-fake-ancestor=<file>:: - Newer 'git diff' output has embedded 'index information' - for each blob to help identify the original version that - the patch applies to. When this flag is given, and if - the original versions of the blobs are available locally, - builds a temporary index containing those blobs. -+ -When a pure mode change is encountered (which has no index information), -the information is read from the current index instead. - --R:: ---reverse:: - Apply the patch in reverse. - ---reject:: - For atomicity, 'git apply' by default fails the whole patch and - does not touch the working tree when some of the hunks - do not apply. This option makes it apply - the parts of the patch that are applicable, and leave the - rejected hunks in corresponding *.rej files. - --z:: - When `--numstat` has been given, do not munge pathnames, - but use a NUL-terminated machine-readable format. -+ -Without this option, pathnames with "unusual" characters are quoted as -explained for the configuration variable `core.quotePath` (see -linkgit:git-config[1]). - --p<n>:: - Remove <n> leading path components (separated by slashes) from - traditional diff paths. E.g., with `-p2`, a patch against - `a/dir/file` will be applied directly to `file`. The default is - 1. - --C<n>:: - Ensure at least <n> lines of surrounding context match before - and after each change. When fewer lines of surrounding - context exist they all must match. By default no context is - ever ignored. - ---unidiff-zero:: - By default, 'git apply' expects that the patch being - applied is a unified diff with at least one line of context. - This provides good safety measures, but breaks down when - applying a diff generated with `--unified=0`. To bypass these - checks use `--unidiff-zero`. -+ -Note, for the reasons stated above usage of context-free patches is -discouraged. - ---apply:: - If you use any of the options marked "Turns off - 'apply'" above, 'git apply' reads and outputs the - requested information without actually applying the - patch. Give this flag after those flags to also apply - the patch. - ---no-add:: - When applying a patch, ignore additions made by the - patch. This can be used to extract the common part between - two files by first running 'diff' on them and applying - the result with this option, which would apply the - deletion part but not the addition part. - ---allow-binary-replacement:: ---binary:: - Historically we did not allow binary patch applied - without an explicit permission from the user, and this - flag was the way to do so. Currently we always allow binary - patch application, so this is a no-op. - ---exclude=<path-pattern>:: - Don't apply changes to files matching the given path pattern. This can - be useful when importing patchsets, where you want to exclude certain - files or directories. - ---include=<path-pattern>:: - Apply changes to files matching the given path pattern. This can - be useful when importing patchsets, where you want to include certain - files or directories. -+ -When `--exclude` and `--include` patterns are used, they are examined in the -order they appear on the command line, and the first match determines if a -patch to each path is used. A patch to a path that does not match any -include/exclude pattern is used by default if there is no include pattern -on the command line, and ignored if there is any include pattern. - ---ignore-space-change:: ---ignore-whitespace:: - When applying a patch, ignore changes in whitespace in context - lines if necessary. - Context lines will preserve their whitespace, and they will not - undergo whitespace fixing regardless of the value of the - `--whitespace` option. New lines will still be fixed, though. - ---whitespace=<action>:: - When applying a patch, detect a new or modified line that has - whitespace errors. What are considered whitespace errors is - controlled by `core.whitespace` configuration. By default, - trailing whitespaces (including lines that solely consist of - whitespaces) and a space character that is immediately followed - by a tab character inside the initial indent of the line are - considered whitespace errors. -+ -By default, the command outputs warning messages but applies the patch. -When `git-apply` is used for statistics and not applying a -patch, it defaults to `nowarn`. -+ -You can use different `<action>` values to control this -behavior: -+ -* `nowarn` turns off the trailing whitespace warning. -* `warn` outputs warnings for a few such errors, but applies the - patch as-is (default). -* `fix` outputs warnings for a few such errors, and applies the - patch after fixing them (`strip` is a synonym --- the tool - used to consider only trailing whitespace characters as errors, and the - fix involved 'stripping' them, but modern Gits do more). -* `error` outputs warnings for a few such errors, and refuses - to apply the patch. -* `error-all` is similar to `error` but shows all errors. - ---inaccurate-eof:: - Under certain circumstances, some versions of 'diff' do not correctly - detect a missing new-line at the end of the file. As a result, patches - created by such 'diff' programs do not record incomplete lines - correctly. This option adds support for applying such patches by - working around this bug. - --v:: ---verbose:: - Report progress to stderr. By default, only a message about the - current patch being applied will be printed. This option will cause - additional information to be reported. - ---recount:: - Do not trust the line counts in the hunk headers, but infer them - by inspecting the patch (e.g. after editing the patch without - adjusting the hunk headers appropriately). - ---directory=<root>:: - Prepend <root> to all filenames. If a "-p" argument was also passed, - it is applied before prepending the new root. -+ -For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh` -can be applied to the file in the working tree `modules/git-gui/git-gui.sh` by -running `git apply --directory=modules/git-gui`. - ---unsafe-paths:: - By default, a patch that affects outside the working area - (either a Git controlled working tree, or the current working - directory when "git apply" is used as a replacement of GNU - patch) is rejected as a mistake (or a mischief). -+ -When `git apply` is used as a "better GNU patch", the user can pass -the `--unsafe-paths` option to override this safety check. This option -has no effect when `--index` or `--cached` is in use. - -CONFIGURATION -------------- - -apply.ignoreWhitespace:: - Set to 'change' if you want changes in whitespace to be ignored by default. - Set to one of: no, none, never, false if you want changes in - whitespace to be significant. -apply.whitespace:: - When no `--whitespace` flag is given from the command - line, this configuration item is used as the default. - -SUBMODULES ----------- -If the patch contains any changes to submodules then 'git apply' -treats these changes as follows. - -If `--index` is specified (explicitly or implicitly), then the submodule -commits must match the index exactly for the patch to apply. If any -of the submodules are checked-out, then these check-outs are completely -ignored, i.e., they are not required to be up to date or clean and they -are not updated. - -If `--index` is not specified, then the submodule commits in the patch -are ignored and only the absence or presence of the corresponding -subdirectory is checked and (if possible) updated. - -SEE ALSO --------- -linkgit:git-am[1]. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-archimport.txt b/third_party/git/Documentation/git-archimport.txt deleted file mode 100644 index a595a0ffee..0000000000 --- a/third_party/git/Documentation/git-archimport.txt +++ /dev/null @@ -1,113 +0,0 @@ -git-archimport(1) -================= - -NAME ----- -git-archimport - Import a GNU Arch repository into Git - - -SYNOPSIS --------- -[verse] -'git archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir] - <archive/branch>[:<git-branch>] ... - -DESCRIPTION ------------ -Imports a project from one or more GNU Arch repositories. -It will follow branches -and repositories within the namespaces defined by the <archive/branch> -parameters supplied. If it cannot find the remote branch a merge comes from -it will just import it as a regular commit. If it can find it, it will mark it -as a merge whenever possible (see discussion below). - -The script expects you to provide the key roots where it can start the import -from an 'initial import' or 'tag' type of Arch commit. It will follow and -import new branches within the provided roots. - -It expects to be dealing with one project only. If it sees -branches that have different roots, it will refuse to run. In that case, -edit your <archive/branch> parameters to define clearly the scope of the -import. - -'git archimport' uses `tla` extensively in the background to access the -Arch repository. -Make sure you have a recent version of `tla` available in the path. `tla` must -know about the repositories you pass to 'git archimport'. - -For the initial import, 'git archimport' expects to find itself in an empty -directory. To follow the development of a project that uses Arch, rerun -'git archimport' with the same parameters as the initial import to perform -incremental imports. - -While 'git archimport' will try to create sensible branch names for the -archives that it imports, it is also possible to specify Git branch names -manually. To do so, write a Git branch name after each <archive/branch> -parameter, separated by a colon. This way, you can shorten the Arch -branch names and convert Arch jargon to Git jargon, for example mapping a -"PROJECT{litdd}devo{litdd}VERSION" branch to "master". - -Associating multiple Arch branches to one Git branch is possible; the -result will make the most sense only if no commits are made to the first -branch, after the second branch is created. Still, this is useful to -convert Arch repositories that had been rotated periodically. - - -MERGES ------- -Patch merge data from Arch is used to mark merges in Git as well. Git -does not care much about tracking patches, and only considers a merge when a -branch incorporates all the commits since the point they forked. The end result -is that Git will have a good idea of how far branches have diverged. So the -import process does lose some patch-trading metadata. - -Fortunately, when you try and merge branches imported from Arch, -Git will find a good merge base, and it has a good chance of identifying -patches that have been traded out-of-sequence between the branches. - -OPTIONS -------- - --h:: - Display usage. - --v:: - Verbose output. - --T:: - Many tags. Will create a tag for every commit, reflecting the commit - name in the Arch repository. - --f:: - Use the fast patchset import strategy. This can be significantly - faster for large trees, but cannot handle directory renames or - permissions changes. The default strategy is slow and safe. - --o:: - Use this for compatibility with old-style branch names used by - earlier versions of 'git archimport'. Old-style branch names - were category{litdd}branch, whereas new-style branch names are - archive,category{litdd}branch{litdd}version. In both cases, names given - on the command-line will override the automatically-generated - ones. - --D <depth>:: - Follow merge ancestry and attempt to import trees that have been - merged from. Specify a depth greater than 1 if patch logs have been - pruned. - --a:: - Attempt to auto-register archives at `http://mirrors.sourcecontrol.net` - This is particularly useful with the -D option. - --t <tmpdir>:: - Override the default tempdir. - - -<archive/branch>:: - Archive/branch identifier in a format that `tla log` understands. - - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-archive.txt b/third_party/git/Documentation/git-archive.txt deleted file mode 100644 index cfa1e4ebe4..0000000000 --- a/third_party/git/Documentation/git-archive.txt +++ /dev/null @@ -1,197 +0,0 @@ -git-archive(1) -============== - -NAME ----- -git-archive - Create an archive of files from a named tree - - -SYNOPSIS --------- -[verse] -'git archive' [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>] - [-o <file> | --output=<file>] [--worktree-attributes] - [--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish> - [<path>...] - -DESCRIPTION ------------ -Creates an archive of the specified format containing the tree -structure for the named tree, and writes it out to the standard -output. If <prefix> is specified it is -prepended to the filenames in the archive. - -'git archive' behaves differently when given a tree ID versus when -given a commit ID or tag ID. In the first case the current time is -used as the modification time of each file in the archive. In the latter -case the commit time as recorded in the referenced commit object is -used instead. Additionally the commit ID is stored in a global -extended pax header if the tar format is used; it can be extracted -using 'git get-tar-commit-id'. In ZIP files it is stored as a file -comment. - -OPTIONS -------- - ---format=<fmt>:: - Format of the resulting archive: 'tar' or 'zip'. If this option - is not given, and the output file is specified, the format is - inferred from the filename if possible (e.g. writing to "foo.zip" - makes the output to be in the zip format). Otherwise the output - format is `tar`. - --l:: ---list:: - Show all available formats. - --v:: ---verbose:: - Report progress to stderr. - ---prefix=<prefix>/:: - Prepend <prefix>/ to each filename in the archive. - --o <file>:: ---output=<file>:: - Write the archive to <file> instead of stdout. - ---worktree-attributes:: - Look for attributes in .gitattributes files in the working tree - as well (see <<ATTRIBUTES>>). - -<extra>:: - This can be any options that the archiver backend understands. - See next section. - ---remote=<repo>:: - Instead of making a tar archive from the local repository, - retrieve a tar archive from a remote repository. Note that the - remote repository may place restrictions on which sha1 - expressions may be allowed in `<tree-ish>`. See - linkgit:git-upload-archive[1] for details. - ---exec=<git-upload-archive>:: - Used with --remote to specify the path to the - 'git-upload-archive' on the remote side. - -<tree-ish>:: - The tree or commit to produce an archive for. - -<path>:: - Without an optional path parameter, all files and subdirectories - of the current working directory are included in the archive. - If one or more paths are specified, only these are included. - -BACKEND EXTRA OPTIONS ---------------------- - -zip -~~~ --0:: - Store the files instead of deflating them. --9:: - Highest and slowest compression level. You can specify any - number from 1 to 9 to adjust compression speed and ratio. - - -CONFIGURATION -------------- - -tar.umask:: - This variable can be used to restrict the permission bits of - tar archive entries. The default is 0002, which turns off the - world write bit. The special value "user" indicates that the - archiving user's umask will be used instead. See umask(2) for - details. If `--remote` is used then only the configuration of - the remote repository takes effect. - -tar.<format>.command:: - This variable specifies a shell command through which the tar - output generated by `git archive` should be piped. The command - is executed using the shell with the generated tar file on its - standard input, and should produce the final output on its - standard output. Any compression-level options will be passed - to the command (e.g., "-9"). An output file with the same - extension as `<format>` will be use this format if no other - format is given. -+ -The "tar.gz" and "tgz" formats are defined automatically and default to -`gzip -cn`. You may override them with custom commands. - -tar.<format>.remote:: - If true, enable `<format>` for use by remote clients via - linkgit:git-upload-archive[1]. Defaults to false for - user-defined formats, but true for the "tar.gz" and "tgz" - formats. - -[[ATTRIBUTES]] -ATTRIBUTES ----------- - -export-ignore:: - Files and directories with the attribute export-ignore won't be - added to archive files. See linkgit:gitattributes[5] for details. - -export-subst:: - If the attribute export-subst is set for a file then Git will - expand several placeholders when adding this file to an archive. - See linkgit:gitattributes[5] for details. - -Note that attributes are by default taken from the `.gitattributes` files -in the tree that is being archived. If you want to tweak the way the -output is generated after the fact (e.g. you committed without adding an -appropriate export-ignore in its `.gitattributes`), adjust the checked out -`.gitattributes` file as necessary and use `--worktree-attributes` -option. Alternatively you can keep necessary attributes that should apply -while archiving any tree in your `$GIT_DIR/info/attributes` file. - -EXAMPLES --------- -`git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)`:: - - Create a tar archive that contains the contents of the - latest commit on the current branch, and extract it in the - `/var/tmp/junk` directory. - -`git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz`:: - - Create a compressed tarball for v1.4.0 release. - -`git archive --format=tar.gz --prefix=git-1.4.0/ v1.4.0 >git-1.4.0.tar.gz`:: - - Same as above, but using the builtin tar.gz handling. - -`git archive --prefix=git-1.4.0/ -o git-1.4.0.tar.gz v1.4.0`:: - - Same as above, but the format is inferred from the output file. - -`git archive --format=tar --prefix=git-1.4.0/ v1.4.0^{tree} | gzip >git-1.4.0.tar.gz`:: - - Create a compressed tarball for v1.4.0 release, but without a - global extended pax header. - -`git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs.zip`:: - - Put everything in the current head's Documentation/ directory - into 'git-1.4.0-docs.zip', with the prefix 'git-docs/'. - -`git archive -o latest.zip HEAD`:: - - Create a Zip archive that contains the contents of the latest - commit on the current branch. Note that the output format is - inferred by the extension of the output file. - -`git config tar.tar.xz.command "xz -c"`:: - - Configure a "tar.xz" format for making LZMA-compressed tarfiles. - You can use it specifying `--format=tar.xz`, or by creating an - output file like `-o foo.tar.xz`. - - -SEE ALSO --------- -linkgit:gitattributes[5] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-bisect-lk2009.txt b/third_party/git/Documentation/git-bisect-lk2009.txt deleted file mode 100644 index e99925184d..0000000000 --- a/third_party/git/Documentation/git-bisect-lk2009.txt +++ /dev/null @@ -1,1358 +0,0 @@ -Fighting regressions with git bisect -==================================== -:Author: Christian Couder -:Email: chriscool@tuxfamily.org -:Date: 2009/11/08 - -Abstract --------- - -"git bisect" enables software users and developers to easily find the -commit that introduced a regression. We show why it is important to -have good tools to fight regressions. We describe how "git bisect" -works from the outside and the algorithms it uses inside. Then we -explain how to take advantage of "git bisect" to improve current -practices. And we discuss how "git bisect" could improve in the -future. - - -Introduction to "git bisect" ----------------------------- - -Git is a Distributed Version Control system (DVCS) created by Linus -Torvalds and maintained by Junio Hamano. - -In Git like in many other Version Control Systems (VCS), the different -states of the data that is managed by the system are called -commits. And, as VCS are mostly used to manage software source code, -sometimes "interesting" changes of behavior in the software are -introduced in some commits. - -In fact people are specially interested in commits that introduce a -"bad" behavior, called a bug or a regression. They are interested in -these commits because a commit (hopefully) contains a very small set -of source code changes. And it's much easier to understand and -properly fix a problem when you only need to check a very small set of -changes, than when you don't know where look in the first place. - -So to help people find commits that introduce a "bad" behavior, the -"git bisect" set of commands was invented. And it follows of course -that in "git bisect" parlance, commits where the "interesting -behavior" is present are called "bad" commits, while other commits are -called "good" commits. And a commit that introduce the behavior we are -interested in is called a "first bad commit". Note that there could be -more than one "first bad commit" in the commit space we are searching. - -So "git bisect" is designed to help find a "first bad commit". And to -be as efficient as possible, it tries to perform a binary search. - - -Fighting regressions overview ------------------------------ - -Regressions: a big problem -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Regressions are a big problem in the software industry. But it's -difficult to put some real numbers behind that claim. - -There are some numbers about bugs in general, like a NIST study in -2002 <<1>> that said: - -_____________ -Software bugs, or errors, are so prevalent and so detrimental that -they cost the U.S. economy an estimated $59.5 billion annually, or -about 0.6 percent of the gross domestic product, according to a newly -released study commissioned by the Department of Commerce's National -Institute of Standards and Technology (NIST). At the national level, -over half of the costs are borne by software users and the remainder -by software developers/vendors. The study also found that, although -all errors cannot be removed, more than a third of these costs, or an -estimated $22.2 billion, could be eliminated by an improved testing -infrastructure that enables earlier and more effective identification -and removal of software defects. These are the savings associated with -finding an increased percentage (but not 100 percent) of errors closer -to the development stages in which they are introduced. Currently, -over half of all errors are not found until "downstream" in the -development process or during post-sale software use. -_____________ - -And then: - -_____________ -Software developers already spend approximately 80 percent of -development costs on identifying and correcting defects, and yet few -products of any type other than software are shipped with such high -levels of errors. -_____________ - -Eventually the conclusion started with: - -_____________ -The path to higher software quality is significantly improved software -testing. -_____________ - -There are other estimates saying that 80% of the cost related to -software is about maintenance <<2>>. - -Though, according to Wikipedia <<3>>: - -_____________ -A common perception of maintenance is that it is merely fixing -bugs. However, studies and surveys over the years have indicated that -the majority, over 80%, of the maintenance effort is used for -non-corrective actions (Pigosky 1997). This perception is perpetuated -by users submitting problem reports that in reality are functionality -enhancements to the system. -_____________ - -But we can guess that improving on existing software is very costly -because you have to watch out for regressions. At least this would -make the above studies consistent among themselves. - -Of course some kind of software is developed, then used during some -time without being improved on much, and then finally thrown away. In -this case, of course, regressions may not be a big problem. But on the -other hand, there is a lot of big software that is continually -developed and maintained during years or even tens of years by a lot -of people. And as there are often many people who depend (sometimes -critically) on such software, regressions are a really big problem. - -One such software is the Linux kernel. And if we look at the Linux -kernel, we can see that a lot of time and effort is spent to fight -regressions. The release cycle start with a 2 weeks long merge -window. Then the first release candidate (rc) version is tagged. And -after that about 7 or 8 more rc versions will appear with around one -week between each of them, before the final release. - -The time between the first rc release and the final release is -supposed to be used to test rc versions and fight bugs and especially -regressions. And this time is more than 80% of the release cycle -time. But this is not the end of the fight yet, as of course it -continues after the release. - -And then this is what Ingo Molnar (a well known Linux kernel -developer) says about his use of git bisect: - -_____________ -I most actively use it during the merge window (when a lot of trees -get merged upstream and when the influx of bugs is the highest) - and -yes, there have been cases that i used it multiple times a day. My -average is roughly once a day. -_____________ - -So regressions are fought all the time by developers, and indeed it is -well known that bugs should be fixed as soon as possible, so as soon -as they are found. That's why it is interesting to have good tools for -this purpose. - -Other tools to fight regressions -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -So what are the tools used to fight regressions? They are nearly the -same as those used to fight regular bugs. The only specific tools are -test suites and tools similar as "git bisect". - -Test suites are very nice. But when they are used alone, they are -supposed to be used so that all the tests are checked after each -commit. This means that they are not very efficient, because many -tests are run for no interesting result, and they suffer from -combinational explosion. - -In fact the problem is that big software often has many different -configuration options and that each test case should pass for each -configuration after each commit. So if you have for each release: N -configurations, M commits and T test cases, you should perform: - -------------- -N * M * T tests -------------- - -where N, M and T are all growing with the size your software. - -So very soon it will not be possible to completely test everything. - -And if some bugs slip through your test suite, then you can add a test -to your test suite. But if you want to use your new improved test -suite to find where the bug slipped in, then you will either have to -emulate a bisection process or you will perhaps bluntly test each -commit backward starting from the "bad" commit you have which may be -very wasteful. - -"git bisect" overview ---------------------- - -Starting a bisection -~~~~~~~~~~~~~~~~~~~~ - -The first "git bisect" subcommand to use is "git bisect start" to -start the search. Then bounds must be set to limit the commit -space. This is done usually by giving one "bad" and at least one -"good" commit. They can be passed in the initial call to "git bisect -start" like this: - -------------- -$ git bisect start [BAD [GOOD...]] -------------- - -or they can be set using: - -------------- -$ git bisect bad [COMMIT] -------------- - -and: - -------------- -$ git bisect good [COMMIT...] -------------- - -where BAD, GOOD and COMMIT are all names that can be resolved to a -commit. - -Then "git bisect" will checkout a commit of its choosing and ask the -user to test it, like this: - -------------- -$ git bisect start v2.6.27 v2.6.25 -Bisecting: 10928 revisions left to test after this (roughly 14 steps) -[2ec65f8b89ea003c27ff7723525a2ee335a2b393] x86: clean up using max_low_pfn on 32-bit -------------- - -Note that the example that we will use is really a toy example, we -will be looking for the first commit that has a version like -"2.6.26-something", that is the commit that has a "SUBLEVEL = 26" line -in the top level Makefile. This is a toy example because there are -better ways to find this commit with Git than using "git bisect" (for -example "git blame" or "git log -S<string>"). - -Driving a bisection manually -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -At this point there are basically 2 ways to drive the search. It can -be driven manually by the user or it can be driven automatically by a -script or a command. - -If the user is driving it, then at each step of the search, the user -will have to test the current commit and say if it is "good" or "bad" -using the "git bisect good" or "git bisect bad" commands respectively -that have been described above. For example: - -------------- -$ git bisect bad -Bisecting: 5480 revisions left to test after this (roughly 13 steps) -[66c0b394f08fd89236515c1c84485ea712a157be] KVM: kill file->f_count abuse in kvm -------------- - -And after a few more steps like that, "git bisect" will eventually -find a first bad commit: - -------------- -$ git bisect bad -2ddcca36c8bcfa251724fe342c8327451988be0d is the first bad commit -commit 2ddcca36c8bcfa251724fe342c8327451988be0d -Author: Linus Torvalds <torvalds@linux-foundation.org> -Date: Sat May 3 11:59:44 2008 -0700 - - Linux 2.6.26-rc1 - -:100644 100644 5cf82581... 4492984e... M Makefile -------------- - -At this point we can see what the commit does, check it out (if it's -not already checked out) or tinker with it, for example: - -------------- -$ git show HEAD -commit 2ddcca36c8bcfa251724fe342c8327451988be0d -Author: Linus Torvalds <torvalds@linux-foundation.org> -Date: Sat May 3 11:59:44 2008 -0700 - - Linux 2.6.26-rc1 - -diff --git a/Makefile b/Makefile -index 5cf8258..4492984 100644 ---- a/Makefile -+++ b/Makefile -@@ -1,7 +1,7 @@ - VERSION = 2 - PATCHLEVEL = 6 --SUBLEVEL = 25 --EXTRAVERSION = -+SUBLEVEL = 26 -+EXTRAVERSION = -rc1 - NAME = Funky Weasel is Jiggy wit it - - # *DOCUMENTATION* -------------- - -And when we are finished we can use "git bisect reset" to go back to -the branch we were in before we started bisecting: - -------------- -$ git bisect reset -Checking out files: 100% (21549/21549), done. -Previous HEAD position was 2ddcca3... Linux 2.6.26-rc1 -Switched to branch 'master' -------------- - -Driving a bisection automatically -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The other way to drive the bisection process is to tell "git bisect" -to launch a script or command at each bisection step to know if the -current commit is "good" or "bad". To do that, we use the "git bisect -run" command. For example: - -------------- -$ git bisect start v2.6.27 v2.6.25 -Bisecting: 10928 revisions left to test after this (roughly 14 steps) -[2ec65f8b89ea003c27ff7723525a2ee335a2b393] x86: clean up using max_low_pfn on 32-bit -$ -$ git bisect run grep '^SUBLEVEL = 25' Makefile -running grep ^SUBLEVEL = 25 Makefile -Bisecting: 5480 revisions left to test after this (roughly 13 steps) -[66c0b394f08fd89236515c1c84485ea712a157be] KVM: kill file->f_count abuse in kvm -running grep ^SUBLEVEL = 25 Makefile -SUBLEVEL = 25 -Bisecting: 2740 revisions left to test after this (roughly 12 steps) -[671294719628f1671faefd4882764886f8ad08cb] V4L/DVB(7879): Adding cx18 Support for mxl5005s -... -... -running grep ^SUBLEVEL = 25 Makefile -Bisecting: 0 revisions left to test after this (roughly 0 steps) -[2ddcca36c8bcfa251724fe342c8327451988be0d] Linux 2.6.26-rc1 -running grep ^SUBLEVEL = 25 Makefile -2ddcca36c8bcfa251724fe342c8327451988be0d is the first bad commit -commit 2ddcca36c8bcfa251724fe342c8327451988be0d -Author: Linus Torvalds <torvalds@linux-foundation.org> -Date: Sat May 3 11:59:44 2008 -0700 - - Linux 2.6.26-rc1 - -:100644 100644 5cf82581... 4492984e... M Makefile -bisect run success -------------- - -In this example, we passed "grep '^SUBLEVEL = 25' Makefile" as -parameter to "git bisect run". This means that at each step, the grep -command we passed will be launched. And if it exits with code 0 (that -means success) then git bisect will mark the current state as -"good". If it exits with code 1 (or any code between 1 and 127 -included, except the special code 125), then the current state will be -marked as "bad". - -Exit code between 128 and 255 are special to "git bisect run". They -make it stop immediately the bisection process. This is useful for -example if the command passed takes too long to complete, because you -can kill it with a signal and it will stop the bisection process. - -It can also be useful in scripts passed to "git bisect run" to "exit -255" if some very abnormal situation is detected. - -Avoiding untestable commits -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Sometimes it happens that the current state cannot be tested, for -example if it does not compile because there was a bug preventing it -at that time. This is what the special exit code 125 is for. It tells -"git bisect run" that the current commit should be marked as -untestable and that another one should be chosen and checked out. - -If the bisection process is driven manually, you can use "git bisect -skip" to do the same thing. (In fact the special exit code 125 makes -"git bisect run" use "git bisect skip" in the background.) - -Or if you want more control, you can inspect the current state using -for example "git bisect visualize". It will launch gitk (or "git log" -if the `DISPLAY` environment variable is not set) to help you find a -better bisection point. - -Either way, if you have a string of untestable commits, it might -happen that the regression you are looking for has been introduced by -one of these untestable commits. In this case it's not possible to -tell for sure which commit introduced the regression. - -So if you used "git bisect skip" (or the run script exited with -special code 125) you could get a result like this: - -------------- -There are only 'skip'ped commits left to test. -The first bad commit could be any of: -15722f2fa328eaba97022898a305ffc8172db6b1 -78e86cf3e850bd755bb71831f42e200626fbd1e0 -e15b73ad3db9b48d7d1ade32f8cd23a751fe0ace -070eab2303024706f2924822bfec8b9847e4ac1b -We cannot bisect more! -------------- - -Saving a log and replaying it -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -If you want to show other people your bisection process, you can get a -log using for example: - -------------- -$ git bisect log > bisect_log.txt -------------- - -And it is possible to replay it using: - -------------- -$ git bisect replay bisect_log.txt -------------- - - -"git bisect" details --------------------- - -Bisection algorithm -~~~~~~~~~~~~~~~~~~~ - -As the Git commits form a directed acyclic graph (DAG), finding the -best bisection commit to test at each step is not so simple. Anyway -Linus found and implemented a "truly stupid" algorithm, later improved -by Junio Hamano, that works quite well. - -So the algorithm used by "git bisect" to find the best bisection -commit when there are no skipped commits is the following: - -1) keep only the commits that: - -a) are ancestor of the "bad" commit (including the "bad" commit itself), -b) are not ancestor of a "good" commit (excluding the "good" commits). - -This means that we get rid of the uninteresting commits in the DAG. - -For example if we start with a graph like this: - -------------- -G-Y-G-W-W-W-X-X-X-X - \ / - W-W-B - / -Y---G-W---W - \ / \ -Y-Y X-X-X-X - --> time goes this way -> -------------- - -where B is the "bad" commit, "G" are "good" commits and W, X, and Y -are other commits, we will get the following graph after this first -step: - -------------- -W-W-W - \ - W-W-B - / -W---W -------------- - -So only the W and B commits will be kept. Because commits X and Y will -have been removed by rules a) and b) respectively, and because commits -G are removed by rule b) too. - -Note for Git users, that it is equivalent as keeping only the commit -given by: - -------------- -git rev-list BAD --not GOOD1 GOOD2... -------------- - -Also note that we don't require the commits that are kept to be -descendants of a "good" commit. So in the following example, commits W -and Z will be kept: - -------------- -G-W-W-W-B - / -Z-Z -------------- - -2) starting from the "good" ends of the graph, associate to each -commit the number of ancestors it has plus one - -For example with the following graph where H is the "bad" commit and A -and D are some parents of some "good" commits: - -------------- -A-B-C - \ - F-G-H - / -D---E -------------- - -this will give: - -------------- -1 2 3 -A-B-C - \6 7 8 - F-G-H -1 2/ -D---E -------------- - -3) associate to each commit: min(X, N - X) - -where X is the value associated to the commit in step 2) and N is the -total number of commits in the graph. - -In the above example we have N = 8, so this will give: - -------------- -1 2 3 -A-B-C - \2 1 0 - F-G-H -1 2/ -D---E -------------- - -4) the best bisection point is the commit with the highest associated -number - -So in the above example the best bisection point is commit C. - -5) note that some shortcuts are implemented to speed up the algorithm - -As we know N from the beginning, we know that min(X, N - X) can't be -greater than N/2. So during steps 2) and 3), if we would associate N/2 -to a commit, then we know this is the best bisection point. So in this -case we can just stop processing any other commit and return the -current commit. - -Bisection algorithm debugging -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -For any commit graph, you can see the number associated with each -commit using "git rev-list --bisect-all". - -For example, for the above graph, a command like: - -------------- -$ git rev-list --bisect-all BAD --not GOOD1 GOOD2 -------------- - -would output something like: - -------------- -e15b73ad3db9b48d7d1ade32f8cd23a751fe0ace (dist=3) -15722f2fa328eaba97022898a305ffc8172db6b1 (dist=2) -78e86cf3e850bd755bb71831f42e200626fbd1e0 (dist=2) -a1939d9a142de972094af4dde9a544e577ddef0e (dist=2) -070eab2303024706f2924822bfec8b9847e4ac1b (dist=1) -a3864d4f32a3bf5ed177ddef598490a08760b70d (dist=1) -a41baa717dd74f1180abf55e9341bc7a0bb9d556 (dist=1) -9e622a6dad403b71c40979743bb9d5be17b16bd6 (dist=0) -------------- - -Bisection algorithm discussed -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -First let's define "best bisection point". We will say that a commit X -is a best bisection point or a best bisection commit if knowing its -state ("good" or "bad") gives as much information as possible whether -the state of the commit happens to be "good" or "bad". - -This means that the best bisection commits are the commits where the -following function is maximum: - -------------- -f(X) = min(information_if_good(X), information_if_bad(X)) -------------- - -where information_if_good(X) is the information we get if X is good -and information_if_bad(X) is the information we get if X is bad. - -Now we will suppose that there is only one "first bad commit". This -means that all its descendants are "bad" and all the other commits are -"good". And we will suppose that all commits have an equal probability -of being good or bad, or of being the first bad commit, so knowing the -state of c commits gives always the same amount of information -wherever these c commits are on the graph and whatever c is. (So we -suppose that these commits being for example on a branch or near a -good or a bad commit does not give more or less information). - -Let's also suppose that we have a cleaned up graph like one after step -1) in the bisection algorithm above. This means that we can measure -the information we get in terms of number of commit we can remove from -the graph.. - -And let's take a commit X in the graph. - -If X is found to be "good", then we know that its ancestors are all -"good", so we want to say that: - -------------- -information_if_good(X) = number_of_ancestors(X) (TRUE) -------------- - -And this is true because at step 1) b) we remove the ancestors of the -"good" commits. - -If X is found to be "bad", then we know that its descendants are all -"bad", so we want to say that: - -------------- -information_if_bad(X) = number_of_descendants(X) (WRONG) -------------- - -But this is wrong because at step 1) a) we keep only the ancestors of -the bad commit. So we get more information when a commit is marked as -"bad", because we also know that the ancestors of the previous "bad" -commit that are not ancestors of the new "bad" commit are not the -first bad commit. We don't know if they are good or bad, but we know -that they are not the first bad commit because they are not ancestor -of the new "bad" commit. - -So when a commit is marked as "bad" we know we can remove all the -commits in the graph except those that are ancestors of the new "bad" -commit. This means that: - -------------- -information_if_bad(X) = N - number_of_ancestors(X) (TRUE) -------------- - -where N is the number of commits in the (cleaned up) graph. - -So in the end this means that to find the best bisection commits we -should maximize the function: - -------------- -f(X) = min(number_of_ancestors(X), N - number_of_ancestors(X)) -------------- - -And this is nice because at step 2) we compute number_of_ancestors(X) -and so at step 3) we compute f(X). - -Let's take the following graph as an example: - -------------- - G-H-I-J - / \ -A-B-C-D-E-F O - \ / - K-L-M-N -------------- - -If we compute the following non optimal function on it: - -------------- -g(X) = min(number_of_ancestors(X), number_of_descendants(X)) -------------- - -we get: - -------------- - 4 3 2 1 - G-H-I-J -1 2 3 4 5 6/ \0 -A-B-C-D-E-F O - \ / - K-L-M-N - 4 3 2 1 -------------- - -but with the algorithm used by git bisect we get: - -------------- - 7 7 6 5 - G-H-I-J -1 2 3 4 5 6/ \0 -A-B-C-D-E-F O - \ / - K-L-M-N - 7 7 6 5 -------------- - -So we chose G, H, K or L as the best bisection point, which is better -than F. Because if for example L is bad, then we will know not only -that L, M and N are bad but also that G, H, I and J are not the first -bad commit (since we suppose that there is only one first bad commit -and it must be an ancestor of L). - -So the current algorithm seems to be the best possible given what we -initially supposed. - -Skip algorithm -~~~~~~~~~~~~~~ - -When some commits have been skipped (using "git bisect skip"), then -the bisection algorithm is the same for step 1) to 3). But then we use -roughly the following steps: - -6) sort the commit by decreasing associated value - -7) if the first commit has not been skipped, we can return it and stop -here - -8) otherwise filter out all the skipped commits in the sorted list - -9) use a pseudo random number generator (PRNG) to generate a random -number between 0 and 1 - -10) multiply this random number with its square root to bias it toward -0 - -11) multiply the result by the number of commits in the filtered list -to get an index into this list - -12) return the commit at the computed index - -Skip algorithm discussed -~~~~~~~~~~~~~~~~~~~~~~~~ - -After step 7) (in the skip algorithm), we could check if the second -commit has been skipped and return it if it is not the case. And in -fact that was the algorithm we used from when "git bisect skip" was -developed in Git version 1.5.4 (released on February 1st 2008) until -Git version 1.6.4 (released July 29th 2009). - -But Ingo Molnar and H. Peter Anvin (another well known linux kernel -developer) both complained that sometimes the best bisection points -all happened to be in an area where all the commits are -untestable. And in this case the user was asked to test many -untestable commits, which could be very inefficient. - -Indeed untestable commits are often untestable because a breakage was -introduced at one time, and that breakage was fixed only after many -other commits were introduced. - -This breakage is of course most of the time unrelated to the breakage -we are trying to locate in the commit graph. But it prevents us to -know if the interesting "bad behavior" is present or not. - -So it is a fact that commits near an untestable commit have a high -probability of being untestable themselves. And the best bisection -commits are often found together too (due to the bisection algorithm). - -This is why it is a bad idea to just chose the next best unskipped -bisection commit when the first one has been skipped. - -We found that most commits on the graph may give quite a lot of -information when they are tested. And the commits that will not on -average give a lot of information are the one near the good and bad -commits. - -So using a PRNG with a bias to favor commits away from the good and -bad commits looked like a good choice. - -One obvious improvement to this algorithm would be to look for a -commit that has an associated value near the one of the best bisection -commit, and that is on another branch, before using the PRNG. Because -if such a commit exists, then it is not very likely to be untestable -too, so it will probably give more information than a nearly randomly -chosen one. - -Checking merge bases -~~~~~~~~~~~~~~~~~~~~ - -There is another tweak in the bisection algorithm that has not been -described in the "bisection algorithm" above. - -We supposed in the previous examples that the "good" commits were -ancestors of the "bad" commit. But this is not a requirement of "git -bisect". - -Of course the "bad" commit cannot be an ancestor of a "good" commit, -because the ancestors of the good commits are supposed to be -"good". And all the "good" commits must be related to the bad commit. -They cannot be on a branch that has no link with the branch of the -"bad" commit. But it is possible for a good commit to be related to a -bad commit and yet not be neither one of its ancestor nor one of its -descendants. - -For example, there can be a "main" branch, and a "dev" branch that was -forked of the main branch at a commit named "D" like this: - -------------- -A-B-C-D-E-F-G <--main - \ - H-I-J <--dev -------------- - -The commit "D" is called a "merge base" for branch "main" and "dev" -because it's the best common ancestor for these branches for a merge. - -Now let's suppose that commit J is bad and commit G is good and that -we apply the bisection algorithm like it has been previously -described. - -As described in step 1) b) of the bisection algorithm, we remove all -the ancestors of the good commits because they are supposed to be good -too. - -So we would be left with only: - -------------- -H-I-J -------------- - -But what happens if the first bad commit is "B" and if it has been -fixed in the "main" branch by commit "F"? - -The result of such a bisection would be that we would find that H is -the first bad commit, when in fact it's B. So that would be wrong! - -And yes it can happen in practice that people working on one branch -are not aware that people working on another branch fixed a bug! It -could also happen that F fixed more than one bug or that it is a -revert of some big development effort that was not ready to be -released. - -In fact development teams often maintain both a development branch and -a maintenance branch, and it would be quite easy for them if "git -bisect" just worked when they want to bisect a regression on the -development branch that is not on the maintenance branch. They should -be able to start bisecting using: - -------------- -$ git bisect start dev main -------------- - -To enable that additional nice feature, when a bisection is started -and when some good commits are not ancestors of the bad commit, we -first compute the merge bases between the bad and the good commits and -we chose these merge bases as the first commits that will be checked -out and tested. - -If it happens that one merge base is bad, then the bisection process -is stopped with a message like: - -------------- -The merge base BBBBBB is bad. -This means the bug has been fixed between BBBBBB and [GGGGGG,...]. -------------- - -where BBBBBB is the sha1 hash of the bad merge base and [GGGGGG,...] -is a comma separated list of the sha1 of the good commits. - -If some of the merge bases are skipped, then the bisection process -continues, but the following message is printed for each skipped merge -base: - -------------- -Warning: the merge base between BBBBBB and [GGGGGG,...] must be skipped. -So we cannot be sure the first bad commit is between MMMMMM and BBBBBB. -We continue anyway. -------------- - -where BBBBBB is the sha1 hash of the bad commit, MMMMMM is the sha1 -hash of the merge base that is skipped and [GGGGGG,...] is a comma -separated list of the sha1 of the good commits. - -So if there is no bad merge base, the bisection process continues as -usual after this step. - -Best bisecting practices ------------------------- - -Using test suites and git bisect together -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -If you both have a test suite and use git bisect, then it becomes less -important to check that all tests pass after each commit. Though of -course it is probably a good idea to have some checks to avoid -breaking too many things because it could make bisecting other bugs -more difficult. - -You can focus your efforts to check at a few points (for example rc -and beta releases) that all the T test cases pass for all the N -configurations. And when some tests don't pass you can use "git -bisect" (or better "git bisect run"). So you should perform roughly: - -------------- -c * N * T + b * M * log2(M) tests -------------- - -where c is the number of rounds of test (so a small constant) and b is -the ratio of bug per commit (hopefully a small constant too). - -So of course it's much better as it's O(N * T) vs O(N * T * M) if -you would test everything after each commit. - -This means that test suites are good to prevent some bugs from being -committed and they are also quite good to tell you that you have some -bugs. But they are not so good to tell you where some bugs have been -introduced. To tell you that efficiently, git bisect is needed. - -The other nice thing with test suites, is that when you have one, you -already know how to test for bad behavior. So you can use this -knowledge to create a new test case for "git bisect" when it appears -that there is a regression. So it will be easier to bisect the bug and -fix it. And then you can add the test case you just created to your -test suite. - -So if you know how to create test cases and how to bisect, you will be -subject to a virtuous circle: - -more tests => easier to create tests => easier to bisect => more tests - -So test suites and "git bisect" are complementary tools that are very -powerful and efficient when used together. - -Bisecting build failures -~~~~~~~~~~~~~~~~~~~~~~~~ - -You can very easily automatically bisect broken builds using something -like: - -------------- -$ git bisect start BAD GOOD -$ git bisect run make -------------- - -Passing sh -c "some commands" to "git bisect run" -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -For example: - -------------- -$ git bisect run sh -c "make || exit 125; ./my_app | grep 'good output'" -------------- - -On the other hand if you do this often, then it can be worth having -scripts to avoid too much typing. - -Finding performance regressions -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Here is an example script that comes slightly modified from a real -world script used by Junio Hamano <<4>>. - -This script can be passed to "git bisect run" to find the commit that -introduced a performance regression: - -------------- -#!/bin/sh - -# Build errors are not what I am interested in. -make my_app || exit 255 - -# We are checking if it stops in a reasonable amount of time, so -# let it run in the background... - -./my_app >log 2>&1 & - -# ... and grab its process ID. -pid=$! - -# ... and then wait for sufficiently long. -sleep $NORMAL_TIME - -# ... and then see if the process is still there. -if kill -0 $pid -then - # It is still running -- that is bad. - kill $pid; sleep 1; kill $pid; - exit 1 -else - # It has already finished (the $pid process was no more), - # and we are happy. - exit 0 -fi -------------- - -Following general best practices -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -It is obviously a good idea not to have commits with changes that -knowingly break things, even if some other commits later fix the -breakage. - -It is also a good idea when using any VCS to have only one small -logical change in each commit. - -The smaller the changes in your commit, the most effective "git -bisect" will be. And you will probably need "git bisect" less in the -first place, as small changes are easier to review even if they are -only reviewed by the committer. - -Another good idea is to have good commit messages. They can be very -helpful to understand why some changes were made. - -These general best practices are very helpful if you bisect often. - -Avoiding bug prone merges -~~~~~~~~~~~~~~~~~~~~~~~~~ - -First merges by themselves can introduce some regressions even when -the merge needs no source code conflict resolution. This is because a -semantic change can happen in one branch while the other branch is not -aware of it. - -For example one branch can change the semantic of a function while the -other branch add more calls to the same function. - -This is made much worse if many files have to be fixed to resolve -conflicts. That's why such merges are called "evil merges". They can -make regressions very difficult to track down. It can even be -misleading to know the first bad commit if it happens to be such a -merge, because people might think that the bug comes from bad conflict -resolution when it comes from a semantic change in one branch. - -Anyway "git rebase" can be used to linearize history. This can be used -either to avoid merging in the first place. Or it can be used to -bisect on a linear history instead of the non linear one, as this -should give more information in case of a semantic change in one -branch. - -Merges can be also made simpler by using smaller branches or by using -many topic branches instead of only long version related branches. - -And testing can be done more often in special integration branches -like linux-next for the linux kernel. - -Adapting your work-flow -~~~~~~~~~~~~~~~~~~~~~~~ - -A special work-flow to process regressions can give great results. - -Here is an example of a work-flow used by Andreas Ericsson: - -* write, in the test suite, a test script that exposes the regression -* use "git bisect run" to find the commit that introduced it -* fix the bug that is often made obvious by the previous step -* commit both the fix and the test script (and if needed more tests) - -And here is what Andreas said about this work-flow <<5>>: - -_____________ -To give some hard figures, we used to have an average report-to-fix -cycle of 142.6 hours (according to our somewhat weird bug-tracker -which just measures wall-clock time). Since we moved to Git, we've -lowered that to 16.2 hours. Primarily because we can stay on top of -the bug fixing now, and because everyone's jockeying to get to fix -bugs (we're quite proud of how lazy we are to let Git find the bugs -for us). Each new release results in ~40% fewer bugs (almost certainly -due to how we now feel about writing tests). -_____________ - -Clearly this work-flow uses the virtuous circle between test suites -and "git bisect". In fact it makes it the standard procedure to deal -with regression. - -In other messages Andreas says that they also use the "best practices" -described above: small logical commits, topic branches, no evil -merge,... These practices all improve the bisectability of the commit -graph, by making it easier and more useful to bisect. - -So a good work-flow should be designed around the above points. That -is making bisecting easier, more useful and standard. - -Involving QA people and if possible end users -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -One nice about "git bisect" is that it is not only a developer -tool. It can effectively be used by QA people or even end users (if -they have access to the source code or if they can get access to all -the builds). - -There was a discussion at one point on the linux kernel mailing list -of whether it was ok to always ask end user to bisect, and very good -points were made to support the point of view that it is ok. - -For example David Miller wrote <<6>>: - -_____________ -What people don't get is that this is a situation where the "end node -principle" applies. When you have limited resources (here: developers) -you don't push the bulk of the burden upon them. Instead you push -things out to the resource you have a lot of, the end nodes (here: -users), so that the situation actually scales. -_____________ - -This means that it is often "cheaper" if QA people or end users can do -it. - -What is interesting too is that end users that are reporting bugs (or -QA people that reproduced a bug) have access to the environment where -the bug happens. So they can often more easily reproduce a -regression. And if they can bisect, then more information will be -extracted from the environment where the bug happens, which means that -it will be easier to understand and then fix the bug. - -For open source projects it can be a good way to get more useful -contributions from end users, and to introduce them to QA and -development activities. - -Using complex scripts -~~~~~~~~~~~~~~~~~~~~~ - -In some cases like for kernel development it can be worth developing -complex scripts to be able to fully automate bisecting. - -Here is what Ingo Molnar says about that <<7>>: - -_____________ -i have a fully automated bootup-hang bisection script. It is based on -"git-bisect run". I run the script, it builds and boots kernels fully -automatically, and when the bootup fails (the script notices that via -the serial log, which it continuously watches - or via a timeout, if -the system does not come up within 10 minutes it's a "bad" kernel), -the script raises my attention via a beep and i power cycle the test -box. (yeah, i should make use of a managed power outlet to 100% -automate it) -_____________ - -Combining test suites, git bisect and other systems together -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -We have seen that test suites and git bisect are very powerful when -used together. It can be even more powerful if you can combine them -with other systems. - -For example some test suites could be run automatically at night with -some unusual (or even random) configurations. And if a regression is -found by a test suite, then "git bisect" can be automatically -launched, and its result can be emailed to the author of the first bad -commit found by "git bisect", and perhaps other people too. And a new -entry in the bug tracking system could be automatically created too. - - -The future of bisecting ------------------------ - -"git replace" -~~~~~~~~~~~~~ - -We saw earlier that "git bisect skip" is now using a PRNG to try to -avoid areas in the commit graph where commits are untestable. The -problem is that sometimes the first bad commit will be in an -untestable area. - -To simplify the discussion we will suppose that the untestable area is -a simple string of commits and that it was created by a breakage -introduced by one commit (let's call it BBC for bisect breaking -commit) and later fixed by another one (let's call it BFC for bisect -fixing commit). - -For example: - -------------- -...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z-... -------------- - -where we know that Y is good and BFC is bad, and where BBC and X1 to -X6 are untestable. - -In this case if you are bisecting manually, what you can do is create -a special branch that starts just before the BBC. The first commit in -this branch should be the BBC with the BFC squashed into it. And the -other commits in the branch should be the commits between BBC and BFC -rebased on the first commit of the branch and then the commit after -BFC also rebased on. - -For example: - -------------- - (BBC+BFC)-X1'-X2'-X3'-X4'-X5'-X6'-Z' - / -...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z-... -------------- - -where commits quoted with ' have been rebased. - -You can easily create such a branch with Git using interactive rebase. - -For example using: - -------------- -$ git rebase -i Y Z -------------- - -and then moving BFC after BBC and squashing it. - -After that you can start bisecting as usual in the new branch and you -should eventually find the first bad commit. - -For example: - -------------- -$ git bisect start Z' Y -------------- - -If you are using "git bisect run", you can use the same manual fix up -as above, and then start another "git bisect run" in the special -branch. Or as the "git bisect" man page says, the script passed to -"git bisect run" can apply a patch before it compiles and test the -software <<8>>. The patch should turn a current untestable commits -into a testable one. So the testing will result in "good" or "bad" and -"git bisect" will be able to find the first bad commit. And the script -should not forget to remove the patch once the testing is done before -exiting from the script. - -(Note that instead of a patch you can use "git cherry-pick BFC" to -apply the fix, and in this case you should use "git reset --hard -HEAD^" to revert the cherry-pick after testing and before returning -from the script.) - -But the above ways to work around untestable areas are a little bit -clunky. Using special branches is nice because these branches can be -shared by developers like usual branches, but the risk is that people -will get many such branches. And it disrupts the normal "git bisect" -work-flow. So, if you want to use "git bisect run" completely -automatically, you have to add special code in your script to restart -bisection in the special branches. - -Anyway one can notice in the above special branch example that the Z' -and Z commits should point to the same source code state (the same -"tree" in git parlance). That's because Z' result from applying the -same changes as Z just in a slightly different order. - -So if we could just "replace" Z by Z' when we bisect, then we would -not need to add anything to a script. It would just work for anyone in -the project sharing the special branches and the replacements. - -With the example above that would give: - -------------- - (BBC+BFC)-X1'-X2'-X3'-X4'-X5'-X6'-Z'-... - / -...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z -------------- - -That's why the "git replace" command was created. Technically it -stores replacements "refs" in the "refs/replace/" hierarchy. These -"refs" are like branches (that are stored in "refs/heads/") or tags -(that are stored in "refs/tags"), and that means that they can -automatically be shared like branches or tags among developers. - -"git replace" is a very powerful mechanism. It can be used to fix -commits in already released history, for example to change the commit -message or the author. And it can also be used instead of git "grafts" -to link a repository with another old repository. - -In fact it's this last feature that "sold" it to the Git community, so -it is now in the "master" branch of Git's Git repository and it should -be released in Git 1.6.5 in October or November 2009. - -One problem with "git replace" is that currently it stores all the -replacements refs in "refs/replace/", but it would be perhaps better -if the replacement refs that are useful only for bisecting would be in -"refs/replace/bisect/". This way the replacement refs could be used -only for bisecting, while other refs directly in "refs/replace/" would -be used nearly all the time. - -Bisecting sporadic bugs -~~~~~~~~~~~~~~~~~~~~~~~ - -Another possible improvement to "git bisect" would be to optionally -add some redundancy to the tests performed so that it would be more -reliable when tracking sporadic bugs. - -This has been requested by some kernel developers because some bugs -called sporadic bugs do not appear in all the kernel builds because -they are very dependent on the compiler output. - -The idea is that every 3 test for example, "git bisect" could ask the -user to test a commit that has already been found to be "good" or -"bad" (because one of its descendants or one of its ancestors has been -found to be "good" or "bad" respectively). If it happens that a commit -has been previously incorrectly classified then the bisection can be -aborted early, hopefully before too many mistakes have been made. Then -the user will have to look at what happened and then restart the -bisection using a fixed bisect log. - -There is already a project called BBChop created by Ealdwulf Wuffinga -on Github that does something like that using Bayesian Search Theory -<<9>>: - -_____________ -BBChop is like 'git bisect' (or equivalent), but works when your bug -is intermittent. That is, it works in the presence of false negatives -(when a version happens to work this time even though it contains the -bug). It assumes that there are no false positives (in principle, the -same approach would work, but adding it may be non-trivial). -_____________ - -But BBChop is independent of any VCS and it would be easier for Git -users to have something integrated in Git. - -Conclusion ----------- - -We have seen that regressions are an important problem, and that "git -bisect" has nice features that complement very well practices and -other tools, especially test suites, that are generally used to fight -regressions. But it might be needed to change some work-flows and -(bad) habits to get the most out of it. - -Some improvements to the algorithms inside "git bisect" are possible -and some new features could help in some cases, but overall "git -bisect" works already very well, is used a lot, and is already very -useful. To back up that last claim, let's give the final word to Ingo -Molnar when he was asked by the author how much time does he think -"git bisect" saves him when he uses it: - -_____________ -a _lot_. - -About ten years ago did i do my first 'bisection' of a Linux patch -queue. That was prior the Git (and even prior the BitKeeper) days. I -literally days spent sorting out patches, creating what in essence -were standalone commits that i guessed to be related to that bug. - -It was a tool of absolute last resort. I'd rather spend days looking -at printk output than do a manual 'patch bisection'. - -With Git bisect it's a breeze: in the best case i can get a ~15 step -kernel bisection done in 20-30 minutes, in an automated way. Even with -manual help or when bisecting multiple, overlapping bugs, it's rarely -more than an hour. - -In fact it's invaluable because there are bugs i would never even -_try_ to debug if it wasn't for git bisect. In the past there were bug -patterns that were immediately hopeless for me to debug - at best i -could send the crash/bug signature to lkml and hope that someone else -can think of something. - -And even if a bisection fails today it tells us something valuable -about the bug: that it's non-deterministic - timing or kernel image -layout dependent. - -So git bisect is unconditional goodness - and feel free to quote that -;-) -_____________ - -Acknowledgments ---------------- - -Many thanks to Junio Hamano for his help in reviewing this paper, for -reviewing the patches I sent to the Git mailing list, for discussing -some ideas and helping me improve them, for improving "git bisect" a -lot and for his awesome work in maintaining and developing Git. - -Many thanks to Ingo Molnar for giving me very useful information that -appears in this paper, for commenting on this paper, for his -suggestions to improve "git bisect" and for evangelizing "git bisect" -on the linux kernel mailing lists. - -Many thanks to Linus Torvalds for inventing, developing and -evangelizing "git bisect", Git and Linux. - -Many thanks to the many other great people who helped one way or -another when I worked on Git, especially to Andreas Ericsson, Johannes -Schindelin, H. Peter Anvin, Daniel Barkalow, Bill Lear, John Hawley, -Shawn O. Pierce, Jeff King, Sam Vilain, Jon Seymour. - -Many thanks to the Linux-Kongress program committee for choosing the -author to given a talk and for publishing this paper. - -References ----------- - -- [[[1]]] https://www.nist.gov/sites/default/files/documents/director/planning/report02-3.pdf['The Economic Impacts of Inadequate Infratructure for Software Testing'. Nist Planning Report 02-3], see Executive Summary and Chapter 8. -- [[[2]]] http://www.oracle.com/technetwork/java/codeconvtoc-136057.html['Code Conventions for the Java Programming Language'. Sun Microsystems.] -- [[[3]]] https://en.wikipedia.org/wiki/Software_maintenance['Software maintenance'. Wikipedia.] -- [[[4]]] https://public-inbox.org/git/7vps5xsbwp.fsf_-_@assigned-by-dhcp.cox.net/[Junio C Hamano. 'Automated bisect success story'.] -- [[[5]]] https://lwn.net/Articles/317154/[Christian Couder. 'Fully automated bisecting with "git bisect run"'. LWN.net.] -- [[[6]]] https://lwn.net/Articles/277872/[Jonathan Corbet. 'Bisection divides users and developers'. LWN.net.] -- [[[7]]] http://marc.info/?l=linux-kernel&m=119702753411680&w=2[Ingo Molnar. 'Re: BUG 2.6.23-rc3 can't see sd partitions on Alpha'. Linux-kernel mailing list.] -- [[[8]]] https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html[Junio C Hamano and the git-list. 'git-bisect(1) Manual Page'. Linux Kernel Archives.] -- [[[9]]] https://github.com/Ealdwulf/bbchop[Ealdwulf. 'bbchop'. GitHub.] diff --git a/third_party/git/Documentation/git-bisect.txt b/third_party/git/Documentation/git-bisect.txt deleted file mode 100644 index 4b45d837a7..0000000000 --- a/third_party/git/Documentation/git-bisect.txt +++ /dev/null @@ -1,499 +0,0 @@ -git-bisect(1) -============= - -NAME ----- -git-bisect - Use binary search to find the commit that introduced a bug - - -SYNOPSIS --------- -[verse] -'git bisect' <subcommand> <options> - -DESCRIPTION ------------ -The command takes various subcommands, and different options depending -on the subcommand: - - git bisect start [--term-{old,good}=<term> --term-{new,bad}=<term>] - [--no-checkout] [<bad> [<good>...]] [--] [<paths>...] - git bisect (bad|new|<term-new>) [<rev>] - git bisect (good|old|<term-old>) [<rev>...] - git bisect terms [--term-good | --term-bad] - git bisect skip [(<rev>|<range>)...] - git bisect reset [<commit>] - git bisect (visualize|view) - git bisect replay <logfile> - git bisect log - git bisect run <cmd>... - git bisect help - -This command uses a binary search algorithm to find which commit in -your project's history introduced a bug. You use it by first telling -it a "bad" commit that is known to contain the bug, and a "good" -commit that is known to be before the bug was introduced. Then `git -bisect` picks a commit between those two endpoints and asks you -whether the selected commit is "good" or "bad". It continues narrowing -down the range until it finds the exact commit that introduced the -change. - -In fact, `git bisect` can be used to find the commit that changed -*any* property of your project; e.g., the commit that fixed a bug, or -the commit that caused a benchmark's performance to improve. To -support this more general usage, the terms "old" and "new" can be used -in place of "good" and "bad", or you can choose your own terms. See -section "Alternate terms" below for more information. - -Basic bisect commands: start, bad, good -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -As an example, suppose you are trying to find the commit that broke a -feature that was known to work in version `v2.6.13-rc2` of your -project. You start a bisect session as follows: - ------------------------------------------------- -$ git bisect start -$ git bisect bad # Current version is bad -$ git bisect good v2.6.13-rc2 # v2.6.13-rc2 is known to be good ------------------------------------------------- - -Once you have specified at least one bad and one good commit, `git -bisect` selects a commit in the middle of that range of history, -checks it out, and outputs something similar to the following: - ------------------------------------------------- -Bisecting: 675 revisions left to test after this (roughly 10 steps) ------------------------------------------------- - -You should now compile the checked-out version and test it. If that -version works correctly, type - ------------------------------------------------- -$ git bisect good ------------------------------------------------- - -If that version is broken, type - ------------------------------------------------- -$ git bisect bad ------------------------------------------------- - -Then `git bisect` will respond with something like - ------------------------------------------------- -Bisecting: 337 revisions left to test after this (roughly 9 steps) ------------------------------------------------- - -Keep repeating the process: compile the tree, test it, and depending -on whether it is good or bad run `git bisect good` or `git bisect bad` -to ask for the next commit that needs testing. - -Eventually there will be no more revisions left to inspect, and the -command will print out a description of the first bad commit. The -reference `refs/bisect/bad` will be left pointing at that commit. - - -Bisect reset -~~~~~~~~~~~~ - -After a bisect session, to clean up the bisection state and return to -the original HEAD, issue the following command: - ------------------------------------------------- -$ git bisect reset ------------------------------------------------- - -By default, this will return your tree to the commit that was checked -out before `git bisect start`. (A new `git bisect start` will also do -that, as it cleans up the old bisection state.) - -With an optional argument, you can return to a different commit -instead: - ------------------------------------------------- -$ git bisect reset <commit> ------------------------------------------------- - -For example, `git bisect reset bisect/bad` will check out the first -bad revision, while `git bisect reset HEAD` will leave you on the -current bisection commit and avoid switching commits at all. - - -Alternate terms -~~~~~~~~~~~~~~~ - -Sometimes you are not looking for the commit that introduced a -breakage, but rather for a commit that caused a change between some -other "old" state and "new" state. For example, you might be looking -for the commit that introduced a particular fix. Or you might be -looking for the first commit in which the source-code filenames were -finally all converted to your company's naming standard. Or whatever. - -In such cases it can be very confusing to use the terms "good" and -"bad" to refer to "the state before the change" and "the state after -the change". So instead, you can use the terms "old" and "new", -respectively, in place of "good" and "bad". (But note that you cannot -mix "good" and "bad" with "old" and "new" in a single session.) - -In this more general usage, you provide `git bisect` with a "new" -commit that has some property and an "old" commit that doesn't have that -property. Each time `git bisect` checks out a commit, you test if that -commit has the property. If it does, mark the commit as "new"; -otherwise, mark it as "old". When the bisection is done, `git bisect` -will report which commit introduced the property. - -To use "old" and "new" instead of "good" and bad, you must run `git -bisect start` without commits as argument and then run the following -commands to add the commits: - ------------------------------------------------- -git bisect old [<rev>] ------------------------------------------------- - -to indicate that a commit was before the sought change, or - ------------------------------------------------- -git bisect new [<rev>...] ------------------------------------------------- - -to indicate that it was after. - -To get a reminder of the currently used terms, use - ------------------------------------------------- -git bisect terms ------------------------------------------------- - -You can get just the old (respectively new) term with `git bisect terms ---term-old` or `git bisect terms --term-good`. - -If you would like to use your own terms instead of "bad"/"good" or -"new"/"old", you can choose any names you like (except existing bisect -subcommands like `reset`, `start`, ...) by starting the -bisection using - ------------------------------------------------- -git bisect start --term-old <term-old> --term-new <term-new> ------------------------------------------------- - -For example, if you are looking for a commit that introduced a -performance regression, you might use - ------------------------------------------------- -git bisect start --term-old fast --term-new slow ------------------------------------------------- - -Or if you are looking for the commit that fixed a bug, you might use - ------------------------------------------------- -git bisect start --term-new fixed --term-old broken ------------------------------------------------- - -Then, use `git bisect <term-old>` and `git bisect <term-new>` instead -of `git bisect good` and `git bisect bad` to mark commits. - -Bisect visualize/view -~~~~~~~~~~~~~~~~~~~~~ - -To see the currently remaining suspects in 'gitk', issue the following -command during the bisection process (the subcommand `view` can be used -as an alternative to `visualize`): - ------------- -$ git bisect visualize ------------- - -If the `DISPLAY` environment variable is not set, 'git log' is used -instead. You can also give command-line options such as `-p` and -`--stat`. - ------------- -$ git bisect visualize --stat ------------- - -Bisect log and bisect replay -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -After having marked revisions as good or bad, issue the following -command to show what has been done so far: - ------------- -$ git bisect log ------------- - -If you discover that you made a mistake in specifying the status of a -revision, you can save the output of this command to a file, edit it to -remove the incorrect entries, and then issue the following commands to -return to a corrected state: - ------------- -$ git bisect reset -$ git bisect replay that-file ------------- - -Avoiding testing a commit -~~~~~~~~~~~~~~~~~~~~~~~~~ - -If, in the middle of a bisect session, you know that the suggested -revision is not a good one to test (e.g. it fails to build and you -know that the failure does not have anything to do with the bug you -are chasing), you can manually select a nearby commit and test that -one instead. - -For example: - ------------- -$ git bisect good/bad # previous round was good or bad. -Bisecting: 337 revisions left to test after this (roughly 9 steps) -$ git bisect visualize # oops, that is uninteresting. -$ git reset --hard HEAD~3 # try 3 revisions before what - # was suggested ------------- - -Then compile and test the chosen revision, and afterwards mark -the revision as good or bad in the usual manner. - -Bisect skip -~~~~~~~~~~~ - -Instead of choosing a nearby commit by yourself, you can ask Git to do -it for you by issuing the command: - ------------- -$ git bisect skip # Current version cannot be tested ------------- - -However, if you skip a commit adjacent to the one you are looking for, -Git will be unable to tell exactly which of those commits was the -first bad one. - -You can also skip a range of commits, instead of just one commit, -using range notation. For example: - ------------- -$ git bisect skip v2.5..v2.6 ------------- - -This tells the bisect process that no commit after `v2.5`, up to and -including `v2.6`, should be tested. - -Note that if you also want to skip the first commit of the range you -would issue the command: - ------------- -$ git bisect skip v2.5 v2.5..v2.6 ------------- - -This tells the bisect process that the commits between `v2.5` and -`v2.6` (inclusive) should be skipped. - - -Cutting down bisection by giving more parameters to bisect start -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You can further cut down the number of trials, if you know what part of -the tree is involved in the problem you are tracking down, by specifying -path parameters when issuing the `bisect start` command: - ------------- -$ git bisect start -- arch/i386 include/asm-i386 ------------- - -If you know beforehand more than one good commit, you can narrow the -bisect space down by specifying all of the good commits immediately after -the bad commit when issuing the `bisect start` command: - ------------- -$ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 -- - # v2.6.20-rc6 is bad - # v2.6.20-rc4 and v2.6.20-rc1 are good ------------- - -Bisect run -~~~~~~~~~~ - -If you have a script that can tell if the current source code is good -or bad, you can bisect by issuing the command: - ------------- -$ git bisect run my_script arguments ------------- - -Note that the script (`my_script` in the above example) should exit -with code 0 if the current source code is good/old, and exit with a -code between 1 and 127 (inclusive), except 125, if the current source -code is bad/new. - -Any other exit code will abort the bisect process. It should be noted -that a program that terminates via `exit(-1)` leaves $? = 255, (see the -exit(3) manual page), as the value is chopped with `& 0377`. - -The special exit code 125 should be used when the current source code -cannot be tested. If the script exits with this code, the current -revision will be skipped (see `git bisect skip` above). 125 was chosen -as the highest sensible value to use for this purpose, because 126 and 127 -are used by POSIX shells to signal specific error status (127 is for -command not found, 126 is for command found but not executable--these -details do not matter, as they are normal errors in the script, as far as -`bisect run` is concerned). - -You may often find that during a bisect session you want to have -temporary modifications (e.g. s/#define DEBUG 0/#define DEBUG 1/ in a -header file, or "revision that does not have this commit needs this -patch applied to work around another problem this bisection is not -interested in") applied to the revision being tested. - -To cope with such a situation, after the inner 'git bisect' finds the -next revision to test, the script can apply the patch -before compiling, run the real test, and afterwards decide if the -revision (possibly with the needed patch) passed the test and then -rewind the tree to the pristine state. Finally the script should exit -with the status of the real test to let the `git bisect run` command loop -determine the eventual outcome of the bisect session. - -OPTIONS -------- ---no-checkout:: -+ -Do not checkout the new working tree at each iteration of the bisection -process. Instead just update a special reference named `BISECT_HEAD` to make -it point to the commit that should be tested. -+ -This option may be useful when the test you would perform in each step -does not require a checked out tree. -+ -If the repository is bare, `--no-checkout` is assumed. - -EXAMPLES --------- - -* Automatically bisect a broken build between v1.2 and HEAD: -+ ------------- -$ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good -$ git bisect run make # "make" builds the app -$ git bisect reset # quit the bisect session ------------- - -* Automatically bisect a test failure between origin and HEAD: -+ ------------- -$ git bisect start HEAD origin -- # HEAD is bad, origin is good -$ git bisect run make test # "make test" builds and tests -$ git bisect reset # quit the bisect session ------------- - -* Automatically bisect a broken test case: -+ ------------- -$ cat ~/test.sh -#!/bin/sh -make || exit 125 # this skips broken builds -~/check_test_case.sh # does the test case pass? -$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10 -$ git bisect run ~/test.sh -$ git bisect reset # quit the bisect session ------------- -+ -Here we use a `test.sh` custom script. In this script, if `make` -fails, we skip the current commit. -`check_test_case.sh` should `exit 0` if the test case passes, -and `exit 1` otherwise. -+ -It is safer if both `test.sh` and `check_test_case.sh` are -outside the repository to prevent interactions between the bisect, -make and test processes and the scripts. - -* Automatically bisect with temporary modifications (hot-fix): -+ ------------- -$ cat ~/test.sh -#!/bin/sh - -# tweak the working tree by merging the hot-fix branch -# and then attempt a build -if git merge --no-commit hot-fix && - make -then - # run project specific test and report its status - ~/check_test_case.sh - status=$? -else - # tell the caller this is untestable - status=125 -fi - -# undo the tweak to allow clean flipping to the next commit -git reset --hard - -# return control -exit $status ------------- -+ -This applies modifications from a hot-fix branch before each test run, -e.g. in case your build or test environment changed so that older -revisions may need a fix which newer ones have already. (Make sure the -hot-fix branch is based off a commit which is contained in all revisions -which you are bisecting, so that the merge does not pull in too much, or -use `git cherry-pick` instead of `git merge`.) - -* Automatically bisect a broken test case: -+ ------------- -$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10 -$ git bisect run sh -c "make || exit 125; ~/check_test_case.sh" -$ git bisect reset # quit the bisect session ------------- -+ -This shows that you can do without a run script if you write the test -on a single line. - -* Locate a good region of the object graph in a damaged repository -+ ------------- -$ git bisect start HEAD <known-good-commit> [ <boundary-commit> ... ] --no-checkout -$ git bisect run sh -c ' - GOOD=$(git for-each-ref "--format=%(objectname)" refs/bisect/good-*) && - git rev-list --objects BISECT_HEAD --not $GOOD >tmp.$$ && - git pack-objects --stdout >/dev/null <tmp.$$ - rc=$? - rm -f tmp.$$ - test $rc = 0' - -$ git bisect reset # quit the bisect session ------------- -+ -In this case, when 'git bisect run' finishes, bisect/bad will refer to a commit that -has at least one parent whose reachable graph is fully traversable in the sense -required by 'git pack objects'. - -* Look for a fix instead of a regression in the code -+ ------------- -$ git bisect start -$ git bisect new HEAD # current commit is marked as new -$ git bisect old HEAD~10 # the tenth commit from now is marked as old ------------- -+ -or: ------------- -$ git bisect start --term-old broken --term-new fixed -$ git bisect fixed -$ git bisect broken HEAD~10 ------------- - -Getting help -~~~~~~~~~~~~ - -Use `git bisect` to get a short usage description, and `git bisect -help` or `git bisect -h` to get a long usage description. - -SEE ALSO --------- -link:git-bisect-lk2009.html[Fighting regressions with git bisect], -linkgit:git-blame[1]. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-blame.txt b/third_party/git/Documentation/git-blame.txt deleted file mode 100644 index 7e81541996..0000000000 --- a/third_party/git/Documentation/git-blame.txt +++ /dev/null @@ -1,236 +0,0 @@ -git-blame(1) -============ - -NAME ----- -git-blame - Show what revision and author last modified each line of a file - -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>] - [--ignore-rev <rev>] [--ignore-revs-file <file>] - [--progress] [--abbrev=<n>] [<rev> | --contents <file> | --reverse <rev>..<rev>] - [--] <file> - -DESCRIPTION ------------ - -Annotates each line in the given file with information from the revision which -last modified the line. Optionally, start annotating from the given revision. - -When specified one or more times, `-L` restricts annotation to the requested -lines. - -The origin of lines is automatically followed across whole-file -renames (currently there is no option to turn the rename-following -off). To follow lines moved from one file to another, or to follow -lines that were copied and pasted from another file, etc., see the -`-C` and `-M` options. - -The report does not tell you anything about lines which have been deleted or -replaced; you need to use a tool such as 'git diff' or the "pickaxe" -interface briefly mentioned in the following paragraph. - -Apart from supporting file annotation, Git also supports searching the -development history for when a code snippet occurred in a change. This makes it -possible to track when a code snippet was added to a file, moved or copied -between files, and eventually deleted or replaced. It works by searching for -a text string in the diff. A small example of the pickaxe interface -that searches for `blame_usage`: - ------------------------------------------------------------------------------ -$ git log --pretty=oneline -S'blame_usage' -5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file> -ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output ------------------------------------------------------------------------------ - -OPTIONS -------- -include::blame-options.txt[] - --c:: - Use the same output mode as linkgit:git-annotate[1] (Default: off). - ---score-debug:: - Include debugging information related to the movement of - lines between files (see `-C`) and lines moved within a - file (see `-M`). The first number listed is the score. - This is the number of alphanumeric characters detected - as having been moved between or within files. This must be above - a certain threshold for 'git blame' to consider those lines - of code to have been moved. - --f:: ---show-name:: - Show the filename in the original commit. By default - the filename is shown if there is any line that came from a - file with a different name, due to rename detection. - --n:: ---show-number:: - Show the line number in the original commit (Default: off). - --s:: - Suppress the author name and timestamp from the output. - --e:: ---show-email:: - Show the author email instead of author name (Default: off). - This can also be controlled via the `blame.showEmail` config - option. - --w:: - Ignore whitespace when comparing the parent's version and - the child's to find where the lines came from. - ---abbrev=<n>:: - Instead of using the default 7+1 hexadecimal digits as the - abbreviated object name, use <n>+1 digits. Note that 1 column - is used for a caret to mark the boundary commit. - - -THE PORCELAIN FORMAT --------------------- - -In this format, each line is output after a header; the -header at the minimum has the first line which has: - -- 40-byte SHA-1 of the commit the line is attributed to; -- the line number of the line in the original file; -- the line number of the line in the final file; -- on a line that starts a group of lines from a different - commit than the previous one, the number of lines in this - group. On subsequent lines this field is absent. - -This header line is followed by the following information -at least once for each commit: - -- the author name ("author"), email ("author-mail"), time - ("author-time"), and time zone ("author-tz"); similarly - for committer. -- the filename in the commit that the line is attributed to. -- the first line of the commit log message ("summary"). - -The contents of the actual line is output after the above -header, prefixed by a TAB. This is to allow adding more -header elements later. - -The porcelain format generally suppresses commit information that has -already been seen. For example, two lines that are blamed to the same -commit will both be shown, but the details for that commit will be shown -only once. This is more efficient, but may require more state be kept by -the reader. The `--line-porcelain` option can be used to output full -commit information for each line, allowing simpler (but less efficient) -usage like: - - # count the number of lines attributed to each author - git blame --line-porcelain file | - sed -n 's/^author //p' | - sort | uniq -c | sort -rn - - -SPECIFYING RANGES ------------------ - -Unlike 'git blame' and 'git annotate' in older versions of git, the extent -of the annotation can be limited to both line ranges and revision -ranges. The `-L` option, which limits annotation to a range of lines, may be -specified multiple times. - -When you are interested in finding the origin for -lines 40-60 for file `foo`, you can use the `-L` option like so -(they mean the same thing -- both ask for 21 lines starting at -line 40): - - git blame -L 40,60 foo - git blame -L 40,+21 foo - -Also you can use a regular expression to specify the line range: - - git blame -L '/^sub hello {/,/^}$/' foo - -which limits the annotation to the body of the `hello` subroutine. - -When you are not interested in changes older than version -v2.6.18, or changes older than 3 weeks, you can use revision -range specifiers similar to 'git rev-list': - - git blame v2.6.18.. -- foo - git blame --since=3.weeks -- foo - -When revision range specifiers are used to limit the annotation, -lines that have not changed since the range boundary (either the -commit v2.6.18 or the most recent commit that is more than 3 -weeks old in the above example) are blamed for that range -boundary commit. - -A particularly useful way is to see if an added file has lines -created by copy-and-paste from existing files. Sometimes this -indicates that the developer was being sloppy and did not -refactor the code properly. You can first find the commit that -introduced the file with: - - git log --diff-filter=A --pretty=short -- foo - -and then annotate the change between the commit and its -parents, using `commit^!` notation: - - git blame -C -C -f $commit^! -- foo - - -INCREMENTAL OUTPUT ------------------- - -When called with `--incremental` option, the command outputs the -result as it is built. The output generally will talk about -lines touched by more recent commits first (i.e. the lines will -be annotated out of order) and is meant to be used by -interactive viewers. - -The output format is similar to the Porcelain format, but it -does not contain the actual lines from the file that is being -annotated. - -. Each blame entry always starts with a line of: - - <40-byte hex sha1> <sourceline> <resultline> <num_lines> -+ -Line numbers count from 1. - -. The first time that a commit shows up in the stream, it has various - other information about it printed out with a one-word tag at the - beginning of each line describing the extra commit information (author, - email, committer, dates, summary, etc.). - -. Unlike the Porcelain format, the filename information is always - given and terminates the entry: - - "filename" <whitespace-quoted-filename-goes-here> -+ -and thus it is really quite easy to parse for some line- and word-oriented -parser (which should be quite natural for most scripting languages). -+ -[NOTE] -For people who do parsing: to make it more robust, just ignore any -lines between the first and last one ("<sha1>" and "filename" lines) -where you do not recognize the tag words (or care about that particular -one) at the beginning of the "extended information" lines. That way, if -there is ever added information (like the commit encoding or extended -commit commentary), a blame viewer will not care. - - -MAPPING AUTHORS ---------------- - -include::mailmap.txt[] - - -SEE ALSO --------- -linkgit:git-annotate[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-branch.txt b/third_party/git/Documentation/git-branch.txt deleted file mode 100644 index 135206ff4a..0000000000 --- a/third_party/git/Documentation/git-branch.txt +++ /dev/null @@ -1,383 +0,0 @@ -git-branch(1) -============= - -NAME ----- -git-branch - List, create, or delete branches - -SYNOPSIS --------- -[verse] -'git branch' [--color[=<when>] | --no-color] [--show-current] - [-v [--abbrev=<length> | --no-abbrev]] - [--column[=<options>] | --no-column] [--sort=<key>] - [(--merged | --no-merged) [<commit>]] - [--contains [<commit]] [--no-contains [<commit>]] - [--points-at <object>] [--format=<format>] - [(-r | --remotes) | (-a | --all)] - [--list] [<pattern>...] -'git branch' [--track | --no-track] [-f] <branchname> [<start-point>] -'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>] -'git branch' --unset-upstream [<branchname>] -'git branch' (-m | -M) [<oldbranch>] <newbranch> -'git branch' (-c | -C) [<oldbranch>] <newbranch> -'git branch' (-d | -D) [-r] <branchname>... -'git branch' --edit-description [<branchname>] - -DESCRIPTION ------------ - -If `--list` is given, or if there are no non-option arguments, existing -branches are listed; the current branch will be highlighted in green and -marked with an asterisk. Any branches checked out in linked worktrees will -be highlighted in cyan and marked with a plus sign. Option `-r` causes the -remote-tracking branches to be listed, -and option `-a` shows both local and remote branches. - -If a `<pattern>` -is given, it is used as a shell wildcard to restrict the output to -matching branches. If multiple patterns are given, a branch is shown if -it matches any of the patterns. - -Note that when providing a -`<pattern>`, you must use `--list`; otherwise the command may be interpreted -as branch creation. - -With `--contains`, shows only the branches that contain the named commit -(in other words, the branches whose tip commits are descendants of the -named commit), `--no-contains` inverts it. With `--merged`, only branches -merged into the named commit (i.e. the branches whose tip commits are -reachable from the named commit) will be listed. With `--no-merged` only -branches not merged into the named commit will be listed. If the <commit> -argument is missing it defaults to `HEAD` (i.e. the tip of the current -branch). - -The command's second form creates a new branch head named <branchname> -which points to the current `HEAD`, or <start-point> if given. As a -special case, for <start-point>, you may use `"A...B"` as a shortcut for -the merge base of `A` and `B` if there is exactly one merge base. You -can leave out at most one of `A` and `B`, in which case it defaults to -`HEAD`. - -Note that this will create the new branch, but it will not switch the -working tree to it; use "git switch <newbranch>" to switch to the -new branch. - -When a local branch is started off a remote-tracking branch, Git sets up the -branch (specifically the `branch.<name>.remote` and `branch.<name>.merge` -configuration entries) so that 'git pull' will appropriately merge from -the remote-tracking branch. This behavior may be changed via the global -`branch.autoSetupMerge` configuration flag. That setting can be -overridden by using the `--track` and `--no-track` options, and -changed later using `git branch --set-upstream-to`. - -With a `-m` or `-M` option, <oldbranch> will be renamed to <newbranch>. -If <oldbranch> had a corresponding reflog, it is renamed to match -<newbranch>, and a reflog entry is created to remember the branch -renaming. If <newbranch> exists, -M must be used to force the rename -to happen. - -The `-c` and `-C` options have the exact same semantics as `-m` and -`-M`, except instead of the branch being renamed it along with its -config and reflog will be copied to a new name. - -With a `-d` or `-D` option, `<branchname>` will be deleted. You may -specify more than one branch for deletion. If the branch currently -has a reflog then the reflog will also be deleted. - -Use `-r` together with `-d` to delete remote-tracking branches. Note, that it -only makes sense to delete remote-tracking branches if they no longer exist -in the remote repository or if 'git fetch' was configured not to fetch -them again. See also the 'prune' subcommand of linkgit:git-remote[1] for a -way to clean up all obsolete remote-tracking branches. - - -OPTIONS -------- --d:: ---delete:: - Delete a branch. The branch must be fully merged in its - upstream branch, or in `HEAD` if no upstream was set with - `--track` or `--set-upstream-to`. - --D:: - Shortcut for `--delete --force`. - ---create-reflog:: - Create the branch's reflog. This activates recording of - all changes made to the branch ref, enabling use of date - based sha1 expressions such as "<branchname>@\{yesterday}". - Note that in non-bare repositories, reflogs are usually - enabled by default by the `core.logAllRefUpdates` config option. - The negated form `--no-create-reflog` only overrides an earlier - `--create-reflog`, but currently does not negate the setting of - `core.logAllRefUpdates`. - --f:: ---force:: - Reset <branchname> to <startpoint>, even if <branchname> exists - already. Without `-f`, 'git branch' refuses to change an existing branch. - In combination with `-d` (or `--delete`), allow deleting the - branch irrespective of its merged status. In combination with - `-m` (or `--move`), allow renaming the branch even if the new - branch name already exists, the same applies for `-c` (or `--copy`). - --m:: ---move:: - Move/rename a branch and the corresponding reflog. - --M:: - Shortcut for `--move --force`. - --c:: ---copy:: - Copy a branch and the corresponding reflog. - --C:: - Shortcut for `--copy --force`. - ---color[=<when>]:: - Color branches to highlight current, local, and - remote-tracking branches. - The value must be always (the default), never, or auto. - ---no-color:: - Turn off branch colors, even when the configuration file gives the - default to color output. - Same as `--color=never`. - --i:: ---ignore-case:: - Sorting and filtering branches are case insensitive. - ---column[=<options>]:: ---no-column:: - Display branch listing in columns. See configuration variable - column.branch for option syntax.`--column` and `--no-column` - without options are equivalent to 'always' and 'never' respectively. -+ -This option is only applicable in non-verbose mode. - --r:: ---remotes:: - List or delete (if used with -d) the remote-tracking branches. - Combine with `--list` to match the optional pattern(s). - --a:: ---all:: - List both remote-tracking branches and local branches. - Combine with `--list` to match optional pattern(s). - --l:: ---list:: - List branches. With optional `<pattern>...`, e.g. `git - branch --list 'maint-*'`, list only the branches that match - the pattern(s). - ---show-current:: - Print the name of the current branch. In detached HEAD state, - nothing is printed. - --v:: --vv:: ---verbose:: - When in list mode, - show sha1 and commit subject line for each head, along with - relationship to upstream branch (if any). If given twice, print - the path of the linked worktree (if any) and the name of the upstream - branch, as well (see also `git remote show <remote>`). Note that the - current worktree's HEAD will not have its path printed (it will always - be your current directory). - --q:: ---quiet:: - Be more quiet when creating or deleting a branch, suppressing - non-error messages. - ---abbrev=<length>:: - Alter the sha1's minimum display length in the output listing. - The default value is 7 and can be overridden by the `core.abbrev` - config option. - ---no-abbrev:: - Display the full sha1s in the output listing rather than abbreviating them. - --t:: ---track:: - When creating a new branch, set up `branch.<name>.remote` and - `branch.<name>.merge` configuration entries to mark the - start-point branch as "upstream" from the new branch. This - configuration will tell git to show the relationship between the - two branches in `git status` and `git branch -v`. Furthermore, - it directs `git pull` without arguments to pull from the - upstream when the new branch is checked out. -+ -This behavior is the default when the start point is a remote-tracking branch. -Set the branch.autoSetupMerge configuration variable to `false` if you -want `git switch`, `git checkout` and `git branch` to always behave as if `--no-track` -were given. Set it to `always` if you want this behavior when the -start-point is either a local or remote-tracking branch. - ---no-track:: - Do not set up "upstream" configuration, even if the - branch.autoSetupMerge configuration variable is true. - ---set-upstream:: - As this option had confusing syntax, it is no longer supported. - Please use `--track` or `--set-upstream-to` instead. - --u <upstream>:: ---set-upstream-to=<upstream>:: - Set up <branchname>'s tracking information so <upstream> is - considered <branchname>'s upstream branch. If no <branchname> - is specified, then it defaults to the current branch. - ---unset-upstream:: - Remove the upstream information for <branchname>. If no branch - is specified it defaults to the current branch. - ---edit-description:: - Open an editor and edit the text to explain what the branch is - for, to be used by various other commands (e.g. `format-patch`, - `request-pull`, and `merge` (if enabled)). Multi-line explanations - may be used. - ---contains [<commit>]:: - Only list branches which contain the specified commit (HEAD - if not specified). Implies `--list`. - ---no-contains [<commit>]:: - Only list branches which don't contain the specified commit - (HEAD if not specified). Implies `--list`. - ---merged [<commit>]:: - Only list branches whose tips are reachable from the - specified commit (HEAD if not specified). Implies `--list`, - incompatible with `--no-merged`. - ---no-merged [<commit>]:: - Only list branches whose tips are not reachable from the - specified commit (HEAD if not specified). Implies `--list`, - incompatible with `--merged`. - -<branchname>:: - The name of the branch to create or delete. - The new branch name must pass all checks defined by - linkgit:git-check-ref-format[1]. Some of these checks - may restrict the characters allowed in a branch name. - -<start-point>:: - The new branch head will point to this commit. It may be - given as a branch name, a commit-id, or a tag. If this - option is omitted, the current HEAD will be used instead. - -<oldbranch>:: - The name of an existing branch to rename. - -<newbranch>:: - The new name for an existing branch. The same restrictions as for - <branchname> apply. - ---sort=<key>:: - Sort based on the key given. Prefix `-` to sort in descending - order of the value. You may use the --sort=<key> option - multiple times, in which case the last key becomes the primary - key. The keys supported are the same as those in `git - for-each-ref`. Sort order defaults to the value configured for the - `branch.sort` variable if exists, or to sorting based on the - full refname (including `refs/...` prefix). This lists - detached HEAD (if present) first, then local branches and - finally remote-tracking branches. See linkgit:git-config[1]. - - ---points-at <object>:: - Only list branches of the given object. - ---format <format>:: - A string that interpolates `%(fieldname)` from a branch ref being shown - and the object it points at. The format is the same as - that of linkgit:git-for-each-ref[1]. - -CONFIGURATION -------------- -`pager.branch` is only respected when listing branches, i.e., when -`--list` is used or implied. The default is to use a pager. -See linkgit:git-config[1]. - -EXAMPLES --------- - -Start development from a known tag:: -+ ------------- -$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 -$ cd my2.6 -$ git branch my2.6.14 v2.6.14 <1> -$ git switch my2.6.14 ------------- -+ -<1> This step and the next one could be combined into a single step with - "checkout -b my2.6.14 v2.6.14". - -Delete an unneeded branch:: -+ ------------- -$ git clone git://git.kernel.org/.../git.git my.git -$ cd my.git -$ git branch -d -r origin/todo origin/html origin/man <1> -$ git branch -D test <2> ------------- -+ -<1> Delete the remote-tracking branches "todo", "html" and "man". The next - 'fetch' or 'pull' will create them again unless you configure them not to. - See linkgit:git-fetch[1]. -<2> Delete the "test" branch even if the "master" branch (or whichever branch - is currently checked out) does not have all commits from the test branch. - -Listing branches from a specific remote:: -+ ------------- -$ git branch -r -l '<remote>/<pattern>' <1> -$ git for-each-ref 'refs/remotes/<remote>/<pattern>' <2> ------------- -+ -<1> Using `-a` would conflate <remote> with any local branches you happen to - have been prefixed with the same <remote> pattern. -<2> `for-each-ref` can take a wide range of options. See linkgit:git-for-each-ref[1] - -Patterns will normally need quoting. - -NOTES ------ - -If you are creating a branch that you want to switch to immediately, -it is easier to use the "git switch" command with its `-c` option to -do the same thing with a single command. - -The options `--contains`, `--no-contains`, `--merged` and `--no-merged` -serve four related but different purposes: - -- `--contains <commit>` is used to find all branches which will need - special attention if <commit> were to be rebased or amended, since those - branches contain the specified <commit>. - -- `--no-contains <commit>` is the inverse of that, i.e. branches that don't - contain the specified <commit>. - -- `--merged` is used to find all branches which can be safely deleted, - since those branches are fully contained by HEAD. - -- `--no-merged` is used to find branches which are candidates for merging - into HEAD, since those branches are not fully contained by HEAD. - -SEE ALSO --------- -linkgit:git-check-ref-format[1], -linkgit:git-fetch[1], -linkgit:git-remote[1], -link:user-manual.html#what-is-a-branch[``Understanding history: What is -a branch?''] in the Git User's Manual. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-bundle.txt b/third_party/git/Documentation/git-bundle.txt deleted file mode 100644 index 7d6c9dcd17..0000000000 --- a/third_party/git/Documentation/git-bundle.txt +++ /dev/null @@ -1,205 +0,0 @@ -git-bundle(1) -============= - -NAME ----- -git-bundle - Move objects and refs by archive - - -SYNOPSIS --------- -[verse] -'git bundle' create <file> <git-rev-list-args> -'git bundle' verify <file> -'git bundle' list-heads <file> [<refname>...] -'git bundle' unbundle <file> [<refname>...] - -DESCRIPTION ------------ - -Some workflows require that one or more branches of development on one -machine be replicated on another machine, but the two machines cannot -be directly connected, and therefore the interactive Git protocols (git, -ssh, http) cannot be used. This command provides support for -'git fetch' and 'git pull' to operate by packaging objects and references -in an archive at the originating machine, then importing those into -another repository using 'git fetch' and 'git pull' -after moving the archive by some means (e.g., by sneakernet). As no -direct connection between the repositories exists, the user must specify a -basis for the bundle that is held by the destination repository: the -bundle assumes that all objects in the basis are already in the -destination repository. - -OPTIONS -------- - -create <file>:: - Used to create a bundle named 'file'. This requires the - 'git-rev-list-args' arguments to define the bundle contents. - -verify <file>:: - Used to check that a bundle file is valid and will apply - cleanly to the current repository. This includes checks on the - bundle format itself as well as checking that the prerequisite - commits exist and are fully linked in the current repository. - 'git bundle' prints a list of missing commits, if any, and exits - with a non-zero status. - -list-heads <file>:: - Lists the references defined in the bundle. If followed by a - list of references, only references matching those given are - printed out. - -unbundle <file>:: - Passes the objects in the bundle to 'git index-pack' - for storage in the repository, then prints the names of all - defined references. If a list of references is given, only - references matching those in the list are printed. This command is - really plumbing, intended to be called only by 'git fetch'. - -<git-rev-list-args>:: - A list of arguments, acceptable to 'git rev-parse' and - 'git rev-list' (and containing a named ref, see SPECIFYING REFERENCES - below), that specifies the specific objects and references - to transport. For example, `master~10..master` causes the - current master reference to be packaged along with all objects - added since its 10th ancestor commit. There is no explicit - limit to the number of references and objects that may be - packaged. - - -[<refname>...]:: - A list of references used to limit the references reported as - available. This is principally of use to 'git fetch', which - expects to receive only those references asked for and not - necessarily everything in the pack (in this case, 'git bundle' acts - like 'git fetch-pack'). - -SPECIFYING REFERENCES ---------------------- - -'git bundle' will only package references that are shown by -'git show-ref': this includes heads, tags, and remote heads. References -such as `master~1` cannot be packaged, but are perfectly suitable for -defining the basis. More than one reference may be packaged, and more -than one basis can be specified. The objects packaged are those not -contained in the union of the given bases. Each basis can be -specified explicitly (e.g. `^master~10`), or implicitly (e.g. -`master~10..master`, `--since=10.days.ago master`). - -It is very important that the basis used be held by the destination. -It is okay to err on the side of caution, causing the bundle file -to contain objects already in the destination, as these are ignored -when unpacking at the destination. - -EXAMPLES --------- - -Assume you want to transfer the history from a repository R1 on machine A -to another repository R2 on machine B. -For whatever reason, direct connection between A and B is not allowed, -but we can move data from A to B via some mechanism (CD, email, etc.). -We want to update R2 with development made on the branch master in R1. - -To bootstrap the process, you can first create a bundle that does not have -any basis. You can use a tag to remember up to what commit you last -processed, in order to make it easy to later update the other repository -with an incremental bundle: - ----------------- -machineA$ cd R1 -machineA$ git bundle create file.bundle master -machineA$ git tag -f lastR2bundle master ----------------- - -Then you transfer file.bundle to the target machine B. Because this -bundle does not require any existing object to be extracted, you can -create a new repository on machine B by cloning from it: - ----------------- -machineB$ git clone -b master /home/me/tmp/file.bundle R2 ----------------- - -This will define a remote called "origin" in the resulting repository that -lets you fetch and pull from the bundle. The $GIT_DIR/config file in R2 will -have an entry like this: - ------------------------- -[remote "origin"] - url = /home/me/tmp/file.bundle - fetch = refs/heads/*:refs/remotes/origin/* ------------------------- - -To update the resulting mine.git repository, you can fetch or pull after -replacing the bundle stored at /home/me/tmp/file.bundle with incremental -updates. - -After working some more in the original repository, you can create an -incremental bundle to update the other repository: - ----------------- -machineA$ cd R1 -machineA$ git bundle create file.bundle lastR2bundle..master -machineA$ git tag -f lastR2bundle master ----------------- - -You then transfer the bundle to the other machine to replace -/home/me/tmp/file.bundle, and pull from it. - ----------------- -machineB$ cd R2 -machineB$ git pull ----------------- - -If you know up to what commit the intended recipient repository should -have the necessary objects, you can use that knowledge to specify the -basis, giving a cut-off point to limit the revisions and objects that go -in the resulting bundle. The previous example used the lastR2bundle tag -for this purpose, but you can use any other options that you would give to -the linkgit:git-log[1] command. Here are more examples: - -You can use a tag that is present in both: - ----------------- -$ git bundle create mybundle v1.0.0..master ----------------- - -You can use a basis based on time: - ----------------- -$ git bundle create mybundle --since=10.days master ----------------- - -You can use the number of commits: - ----------------- -$ git bundle create mybundle -10 master ----------------- - -You can run `git-bundle verify` to see if you can extract from a bundle -that was created with a basis: - ----------------- -$ git bundle verify mybundle ----------------- - -This will list what commits you must have in order to extract from the -bundle and will error out if you do not have them. - -A bundle from a recipient repository's point of view is just like a -regular repository which it fetches or pulls from. You can, for example, map -references when fetching: - ----------------- -$ git fetch mybundle master:localRef ----------------- - -You can also see what references it offers: - ----------------- -$ git ls-remote mybundle ----------------- - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-cat-file.txt b/third_party/git/Documentation/git-cat-file.txt deleted file mode 100644 index 8eca671b82..0000000000 --- a/third_party/git/Documentation/git-cat-file.txt +++ /dev/null @@ -1,319 +0,0 @@ -git-cat-file(1) -=============== - -NAME ----- -git-cat-file - Provide content or type and size information for repository objects - - -SYNOPSIS --------- -[verse] -'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` 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. 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 -whitespace, so that the appropriate drivers can be determined. - -OPTIONS -------- -<object>:: - The name of the object to show. - For a more complete list of ways to spell object names, see - the "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7]. - --t:: - Instead of the content, show the object type identified by - <object>. - --s:: - Instead of the content, show the object size identified by - <object>. - --e:: - Exit with zero status if <object> exists and is a valid - object. If <object> is of an invalid format exit with non-zero and - emits an error on stderr. - --p:: - Pretty-print the contents of <object> based on its type. - -<type>:: - Typically this matches the real type of <object> but asking - for a type that can trivially be dereferenced from the given - <object> is also permitted. An example is to ask for a - "tree" with <object> being a commit object that contains it, - or to ask for a "blob" with <object> being a tag object that - points at it. - ---textconv:: - Show the content as transformed by a textconv filter. In this case, - <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 - except `--textconv` or `--filters`, in which case the input lines - also need to specify the path, separated by whitespace. 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 except - `--textconv` or `--filters`, in which case the input lines also - need to specify the path, separated by whitespace. See the - section `BATCH OUTPUT` below for details. - ---batch-all-objects:: - Instead of reading a list of objects on stdin, perform the - requested batch operation on all objects in the repository and - any alternate object stores (not just reachable objects). - Requires `--batch` or `--batch-check` be specified. Note that - the objects are visited in order sorted by their hashes. - ---buffer:: - Normally batch output is flushed after each object is output, so - that a process can interactively read and write from - `cat-file`. With this option, the output uses normal stdio - buffering; this is much more efficient when invoking - `--batch-check` on a large number of objects. - ---unordered:: - When `--batch-all-objects` is in use, visit objects in an - order which may be more efficient for accessing the object - contents than hash order. The exact details of the order are - unspecified, but if you do not require a specific order, this - should generally result in faster output, especially with - `--batch`. Note that `cat-file` will still show each object - only once, even if it is stored multiple times in the - repository. - ---allow-unknown-type:: - Allow -s or -t to query broken/corrupt objects of unknown type. - ---follow-symlinks:: - With --batch or --batch-check, follow symlinks inside the - repository when requesting objects with extended SHA-1 - expressions of the form tree-ish:path-in-tree. Instead of - providing output about the link itself, provide output about - the linked-to object. If a symlink points outside the - tree-ish (e.g. a link to /foo or a root-level link to ../foo), - the portion of the link which is outside the tree will be - printed. -+ -This option does not (currently) work correctly when an object in the -index is specified (e.g. `:link` instead of `HEAD:link`) rather than -one in the tree. -+ -This option cannot (currently) be used unless `--batch` or -`--batch-check` is used. -+ -For example, consider a git repository containing: -+ --- - f: a file containing "hello\n" - link: a symlink to f - dir/link: a symlink to ../f - plink: a symlink to ../f - alink: a symlink to /etc/passwd --- -+ -For a regular file `f`, `echo HEAD:f | git cat-file --batch` would print -+ --- - ce013625030ba8dba906f756967f9e9ca394464a blob 6 --- -+ -And `echo HEAD:link | git cat-file --batch --follow-symlinks` would -print the same thing, as would `HEAD:dir/link`, as they both point at -`HEAD:f`. -+ -Without `--follow-symlinks`, these would print data about the symlink -itself. In the case of `HEAD:link`, you would see -+ --- - 4d1ae35ba2c8ec712fa2a379db44ad639ca277bd blob 1 --- -+ -Both `plink` and `alink` point outside the tree, so they would -respectively print: -+ --- - symlink 4 - ../f - - symlink 11 - /etc/passwd --- - - -OUTPUT ------- -If `-t` is specified, one of the <type>. - -If `-s` is specified, the size of the <object> in bytes. - -If `-e` is specified, no output, unless the <object> is malformed. - -If `-p` is specified, the contents of <object> are pretty-printed. - -If <type> is specified, the raw (though uncompressed) contents of the <object> -will be returned. - -BATCH OUTPUT ------------- - -If `--batch` or `--batch-check` is given, `cat-file` will read objects -from stdin, one per line, and print information about them. By default, -the whole line is considered as an object, as if it were fed to -linkgit:git-rev-parse[1]. - -You can specify the information shown for each object by using a custom -`<format>`. The `<format>` is copied literally to stdout for each -object, with placeholders of the form `%(atom)` expanded, followed by a -newline. The available atoms are: - -`objectname`:: - The 40-hex object name of the object. - -`objecttype`:: - The type of the object (the same as `cat-file -t` reports). - -`objectsize`:: - The size, in bytes, of the object (the same as `cat-file -s` - reports). - -`objectsize:disk`:: - The size, in bytes, that the object takes up on disk. See the - note about on-disk sizes in the `CAVEATS` section below. - -`deltabase`:: - If the object is stored as a delta on-disk, this expands to the - 40-hex sha1 of the delta base object. Otherwise, expands to the - null sha1 (40 zeroes). See `CAVEATS` below. - -`rest`:: - If this atom is used in the output string, input lines are split - at the first whitespace boundary. All characters before that - whitespace are considered to be the object name; characters - after that first run of whitespace (i.e., the "rest" of the - line) are output in place of the `%(rest)` atom. - -If no format is specified, the default format is `%(objectname) -%(objecttype) %(objectsize)`. - -If `--batch` is specified, the object information is followed by the -object contents (consisting of `%(objectsize)` bytes), followed by a -newline. - -For example, `--batch` without a custom format would produce: - ------------- -<sha1> SP <type> SP <size> LF -<contents> LF ------------- - -Whereas `--batch-check='%(objectname) %(objecttype)'` would produce: - ------------- -<sha1> SP <type> LF ------------- - -If a name is specified on stdin that cannot be resolved to an object in -the repository, then `cat-file` will ignore any custom format and print: - ------------- -<object> SP missing LF ------------- - -If a name is specified that might refer to more than one object (an ambiguous short sha), then `cat-file` will ignore any custom format and print: - ------------- -<object> SP ambiguous LF ------------- - -If --follow-symlinks is used, and a symlink in the repository points -outside the repository, then `cat-file` will ignore any custom format -and print: - ------------- -symlink SP <size> LF -<symlink> LF ------------- - -The symlink will either be absolute (beginning with a /), or relative -to the tree root. For instance, if dir/link points to ../../foo, then -<symlink> will be ../foo. <size> is the size of the symlink in bytes. - -If --follow-symlinks is used, the following error messages will be -displayed: - ------------- -<object> SP missing LF ------------- -is printed when the initial symlink requested does not exist. - ------------- -dangling SP <size> LF -<object> LF ------------- -is printed when the initial symlink exists, but something that -it (transitive-of) points to does not. - ------------- -loop SP <size> LF -<object> LF ------------- -is printed for symlink loops (or any symlinks that -require more than 40 link resolutions to resolve). - ------------- -notdir SP <size> LF -<object> LF ------------- -is printed when, during symlink resolution, a file is used as a -directory name. - -CAVEATS -------- - -Note that the sizes of objects on disk are reported accurately, but care -should be taken in drawing conclusions about which refs or objects are -responsible for disk usage. The size of a packed non-delta object may be -much larger than the size of objects which delta against it, but the -choice of which object is the base and which is the delta is arbitrary -and is subject to change during a repack. - -Note also that multiple copies of an object may be present in the object -database; in this case, it is undefined which copy's size or delta base -will be reported. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-check-attr.txt b/third_party/git/Documentation/git-check-attr.txt deleted file mode 100644 index 3c0578217b..0000000000 --- a/third_party/git/Documentation/git-check-attr.txt +++ /dev/null @@ -1,120 +0,0 @@ -git-check-attr(1) -================= - -NAME ----- -git-check-attr - Display gitattributes information - - -SYNOPSIS --------- -[verse] -'git check-attr' [-a | --all | <attr>...] [--] <pathname>... -'git check-attr' --stdin [-z] [-a | --all | <attr>...] - -DESCRIPTION ------------ -For every pathname, this command will list if each attribute is 'unspecified', -'set', or 'unset' as a gitattribute on that pathname. - -OPTIONS -------- --a, --all:: - List all attributes that are associated with the specified - paths. If this option is used, then 'unspecified' attributes - will not be included in the output. - ---cached:: - Consider `.gitattributes` in the index only, ignoring the working tree. - ---stdin:: - Read pathnames from the standard input, one per line, - instead of from the command-line. - --z:: - The output format is modified to be machine-parseable. - If `--stdin` is also given, input paths are separated - with a NUL character instead of a linefeed character. - -\--:: - Interpret all preceding arguments as attributes and all following - arguments as path names. - -If none of `--stdin`, `--all`, or `--` is used, the first argument -will be treated as an attribute and the rest of the arguments as -pathnames. - -OUTPUT ------- - -The output is of the form: -<path> COLON SP <attribute> COLON SP <info> LF - -unless `-z` is in effect, in which case NUL is used as delimiter: -<path> NUL <attribute> NUL <info> NUL - - -<path> is the path of a file being queried, <attribute> is an attribute -being queried and <info> can be either: - -'unspecified';; when the attribute is not defined for the path. -'unset';; when the attribute is defined as false. -'set';; when the attribute is defined as true. -<value>;; when a value has been assigned to the attribute. - -Buffering happens as documented under the `GIT_FLUSH` option in -linkgit:git[1]. The caller is responsible for avoiding deadlocks -caused by overfilling an input buffer or reading from an empty output -buffer. - -EXAMPLES --------- - -In the examples, the following '.gitattributes' file is used: ---------------- -*.java diff=java -crlf myAttr -NoMyAttr.java !myAttr -README caveat=unspecified ---------------- - -* Listing a single attribute: ---------------- -$ git check-attr diff org/example/MyClass.java -org/example/MyClass.java: diff: java ---------------- - -* Listing multiple attributes for a file: ---------------- -$ git check-attr crlf diff myAttr -- org/example/MyClass.java -org/example/MyClass.java: crlf: unset -org/example/MyClass.java: diff: java -org/example/MyClass.java: myAttr: set ---------------- - -* Listing all attributes for a file: ---------------- -$ git check-attr --all -- org/example/MyClass.java -org/example/MyClass.java: diff: java -org/example/MyClass.java: myAttr: set ---------------- - -* Listing an attribute for multiple files: ---------------- -$ git check-attr myAttr -- org/example/MyClass.java org/example/NoMyAttr.java -org/example/MyClass.java: myAttr: set -org/example/NoMyAttr.java: myAttr: unspecified ---------------- - -* Not all values are equally unambiguous: ---------------- -$ git check-attr caveat README -README: caveat: unspecified ---------------- - -SEE ALSO --------- -linkgit:gitattributes[5]. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-check-ignore.txt b/third_party/git/Documentation/git-check-ignore.txt deleted file mode 100644 index 8b42cb3fb2..0000000000 --- a/third_party/git/Documentation/git-check-ignore.txt +++ /dev/null @@ -1,120 +0,0 @@ -git-check-ignore(1) -=================== - -NAME ----- -git-check-ignore - Debug gitignore / exclude files - - -SYNOPSIS --------- -[verse] -'git check-ignore' [<options>] <pathname>... -'git check-ignore' [<options>] --stdin - -DESCRIPTION ------------ - -For each pathname given via the command-line or from a file via -`--stdin`, check whether the file is excluded by .gitignore (or other -input files to the exclude mechanism) and output the path if it is -excluded. - -By default, tracked files are not shown at all since they are not -subject to exclude rules; but see `--no-index'. - -OPTIONS -------- --q, --quiet:: - Don't output anything, just set exit status. This is only - valid with a single pathname. - --v, --verbose:: - Also output details about the matching pattern (if any) - for each given pathname. For precedence rules within and - between exclude sources, see linkgit:gitignore[5]. - ---stdin:: - Read pathnames from the standard input, one per line, - instead of from the command-line. - --z:: - The output format is modified to be machine-parseable (see - below). If `--stdin` is also given, input paths are separated - with a NUL character instead of a linefeed character. - --n, --non-matching:: - Show given paths which don't match any pattern. This only - makes sense when `--verbose` is enabled, otherwise it would - not be possible to distinguish between paths which match a - pattern and those which don't. - ---no-index:: - Don't look in the index when undertaking the checks. This can - be used to debug why a path became tracked by e.g. `git add .` - and was not ignored by the rules as expected by the user or when - developing patterns including negation to match a path previously - added with `git add -f`. - -OUTPUT ------- - -By default, any of the given pathnames which match an ignore pattern -will be output, one per line. If no pattern matches a given path, -nothing will be output for that path; this means that path will not be -ignored. - -If `--verbose` is specified, the output is a series of lines of the form: - -<source> <COLON> <linenum> <COLON> <pattern> <HT> <pathname> - -<pathname> is the path of a file being queried, <pattern> is the -matching pattern, <source> is the pattern's source file, and <linenum> -is the line number of the pattern within that source. If the pattern -contained a `!` prefix or `/` suffix, it will be preserved in the -output. <source> will be an absolute path when referring to the file -configured by `core.excludesFile`, or relative to the repository root -when referring to `.git/info/exclude` or a per-directory exclude file. - -If `-z` is specified, the pathnames in the output are delimited by the -null character; if `--verbose` is also specified then null characters -are also used instead of colons and hard tabs: - -<source> <NULL> <linenum> <NULL> <pattern> <NULL> <pathname> <NULL> - -If `-n` or `--non-matching` are specified, non-matching pathnames will -also be output, in which case all fields in each output record except -for <pathname> will be empty. This can be useful when running -non-interactively, so that files can be incrementally streamed to -STDIN of a long-running check-ignore process, and for each of these -files, STDOUT will indicate whether that file matched a pattern or -not. (Without this option, it would be impossible to tell whether the -absence of output for a given file meant that it didn't match any -pattern, or that the output hadn't been generated yet.) - -Buffering happens as documented under the `GIT_FLUSH` option in -linkgit:git[1]. The caller is responsible for avoiding deadlocks -caused by overfilling an input buffer or reading from an empty output -buffer. - -EXIT STATUS ------------ - -0:: - One or more of the provided paths is ignored. - -1:: - None of the provided paths are ignored. - -128:: - A fatal error was encountered. - -SEE ALSO --------- -linkgit:gitignore[5] -linkgit:git-config[1] -linkgit:git-ls-files[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-check-mailmap.txt b/third_party/git/Documentation/git-check-mailmap.txt deleted file mode 100644 index aa2055dbeb..0000000000 --- a/third_party/git/Documentation/git-check-mailmap.txt +++ /dev/null @@ -1,47 +0,0 @@ -git-check-mailmap(1) -==================== - -NAME ----- -git-check-mailmap - Show canonical names and email addresses of contacts - - -SYNOPSIS --------- -[verse] -'git check-mailmap' [<options>] <contact>... - - -DESCRIPTION ------------ - -For each ``Name $$<user@host>$$'' or ``$$<user@host>$$'' from the command-line -or standard input (when using `--stdin`), look up the person's canonical name -and email address (see "Mapping Authors" below). If found, print them; -otherwise print the input as-is. - - -OPTIONS -------- ---stdin:: - Read contacts, one per line, from the standard input after exhausting - contacts provided on the command-line. - - -OUTPUT ------- - -For each contact, a single line is output, terminated by a newline. If the -name is provided or known to the 'mailmap', ``Name $$<user@host>$$'' is -printed; otherwise only ``$$<user@host>$$'' is printed. - - -MAPPING AUTHORS ---------------- - -include::mailmap.txt[] - - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-check-ref-format.txt b/third_party/git/Documentation/git-check-ref-format.txt deleted file mode 100644 index ee6a4144fb..0000000000 --- a/third_party/git/Documentation/git-check-ref-format.txt +++ /dev/null @@ -1,140 +0,0 @@ -git-check-ref-format(1) -======================= - -NAME ----- -git-check-ref-format - Ensures that a reference name is well formed - -SYNOPSIS --------- -[verse] -'git check-ref-format' [--normalize] - [--[no-]allow-onelevel] [--refspec-pattern] - <refname> -'git check-ref-format' --branch <branchname-shorthand> - -DESCRIPTION ------------ -Checks if a given 'refname' is acceptable, and exits with a non-zero -status if it is not. - -A reference is used in Git to specify branches and tags. A -branch head is stored in the `refs/heads` hierarchy, while -a tag is stored in the `refs/tags` hierarchy of the ref namespace -(typically in `$GIT_DIR/refs/heads` and `$GIT_DIR/refs/tags` -directories or, as entries in file `$GIT_DIR/packed-refs` -if refs are packed by `git gc`). - -Git imposes the following rules on how references are named: - -. They can include slash `/` for hierarchical (directory) - grouping, but no slash-separated component can begin with a - dot `.` or end with the sequence `.lock`. - -. They must contain at least one `/`. This enforces the presence of a - category like `heads/`, `tags/` etc. but the actual names are not - restricted. If the `--allow-onelevel` option is used, this rule - is waived. - -. They cannot have two consecutive dots `..` anywhere. - -. They cannot have ASCII control characters (i.e. bytes whose - values are lower than \040, or \177 `DEL`), space, tilde `~`, - caret `^`, or colon `:` anywhere. - -. They cannot have question-mark `?`, asterisk `*`, or open - bracket `[` anywhere. See the `--refspec-pattern` option below for - an exception to this rule. - -. They cannot begin or end with a slash `/` or contain multiple - consecutive slashes (see the `--normalize` option below for an - exception to this rule) - -. They cannot end with a dot `.`. - -. They cannot contain a sequence `@{`. - -. They cannot be the single character `@`. - -. They cannot contain a `\`. - -These rules make it easy for shell script based tools to parse -reference names, pathname expansion by the shell when a reference name is used -unquoted (by mistake), and also avoid ambiguities in certain -reference name expressions (see linkgit:gitrevisions[7]): - -. A double-dot `..` is often used as in `ref1..ref2`, and in some - contexts this notation means `^ref1 ref2` (i.e. not in - `ref1` and in `ref2`). - -. A tilde `~` and caret `^` are used to introduce the postfix - 'nth parent' and 'peel onion' operation. - -. A colon `:` is used as in `srcref:dstref` to mean "use srcref\'s - value and store it in dstref" in fetch and push operations. - It may also be used to select a specific object such as with - 'git cat-file': "git cat-file blob v1.3.3:refs.c". - -. at-open-brace `@{` is used as a notation to access a reflog entry. - -With the `--branch` option, the command takes a name and checks if -it can be used as a valid branch name (e.g. when creating a new -branch). But be cautious when using the -previous checkout syntax that may refer to a detached HEAD state. -The rule `git check-ref-format --branch $name` implements -may be stricter than what `git check-ref-format refs/heads/$name` -says (e.g. a dash may appear at the beginning of a ref component, -but it is explicitly forbidden at the beginning of a branch name). -When run with `--branch` option in a repository, the input is first -expanded for the ``previous checkout syntax'' -`@{-n}`. For example, `@{-1}` is a way to refer the last thing that -was checked out using "git switch" or "git checkout" operation. -This option should be -used by porcelains to accept this syntax anywhere a branch name is -expected, so they can act as if you typed the branch name. As an -exception note that, the ``previous checkout operation'' might result -in a commit object name when the N-th last thing checked out was not -a branch. - -OPTIONS -------- ---[no-]allow-onelevel:: - Controls whether one-level refnames are accepted (i.e., - refnames that do not contain multiple `/`-separated - components). The default is `--no-allow-onelevel`. - ---refspec-pattern:: - Interpret <refname> as a reference name pattern for a refspec - (as used with remote repositories). If this option is - enabled, <refname> is allowed to contain a single `*` - in the refspec (e.g., `foo/bar*/baz` or `foo/bar*baz/` - but not `foo/bar*/baz*`). - ---normalize:: - Normalize 'refname' by removing any leading slash (`/`) - characters and collapsing runs of adjacent slashes between - name components into a single slash. If the normalized - refname is valid then print it to standard output and exit - with a status of 0, otherwise exit with a non-zero status. - (`--print` is a deprecated way to spell `--normalize`.) - - -EXAMPLES --------- - -* Print the name of the previous thing checked out: -+ ------------- -$ 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")|| -{ echo "we do not like '$newbranch' as a branch name." >&2 ; exit 1 ; } ------------- - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-checkout-index.txt b/third_party/git/Documentation/git-checkout-index.txt deleted file mode 100644 index 4d33e7be0f..0000000000 --- a/third_party/git/Documentation/git-checkout-index.txt +++ /dev/null @@ -1,177 +0,0 @@ -git-checkout-index(1) -===================== - -NAME ----- -git-checkout-index - Copy files from the index to the working tree - - -SYNOPSIS --------- -[verse] -'git checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>] - [--stage=<number>|all] - [--temp] - [-z] [--stdin] - [--] [<file>...] - -DESCRIPTION ------------ -Will copy all files listed from the index to the working directory -(not overwriting existing files). - -OPTIONS -------- --u:: ---index:: - update stat information for the checked out entries in - the index file. - --q:: ---quiet:: - be quiet if files exist or are not in the index - --f:: ---force:: - forces overwrite of existing files - --a:: ---all:: - checks out all files in the index. Cannot be used - together with explicit filenames. - --n:: ---no-create:: - Don't checkout new files, only refresh files already checked - out. - ---prefix=<string>:: - When creating files, prepend <string> (usually a directory - including a trailing /) - ---stage=<number>|all:: - Instead of checking out unmerged entries, copy out the - files from named stage. <number> must be between 1 and 3. - Note: --stage=all automatically implies --temp. - ---temp:: - Instead of copying the files to the working directory - write the content to temporary files. The temporary name - associations will be written to stdout. - ---stdin:: - Instead of taking list of paths from the command line, - read list of paths from the standard input. Paths are - separated by LF (i.e. one path per line) by default. - --z:: - Only meaningful with `--stdin`; paths are separated with - NUL character instead of LF. - -\--:: - Do not interpret any more arguments as options. - -The order of the flags used to matter, but not anymore. - -Just doing `git checkout-index` does nothing. You probably meant -`git checkout-index -a`. And if you want to force it, you want -`git checkout-index -f -a`. - -Intuitiveness is not the goal here. Repeatability is. The reason for -the "no arguments means no work" behavior is that from scripts you are -supposed to be able to do: - ----------------- -$ find . -name '*.h' -print0 | xargs -0 git checkout-index -f -- ----------------- - -which will force all existing `*.h` files to be replaced with their -cached copies. If an empty command line implied "all", then this would -force-refresh everything in the index, which was not the point. But -since 'git checkout-index' accepts --stdin it would be faster to use: - ----------------- -$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin ----------------- - -The `--` is just a good idea when you know the rest will be filenames; -it will prevent problems with a filename of, for example, `-a`. -Using `--` is probably a good policy in scripts. - - -Using --temp or --stage=all ---------------------------- -When `--temp` is used (or implied by `--stage=all`) -'git checkout-index' will create a temporary file for each index -entry being checked out. The index will not be updated with stat -information. These options can be useful if the caller needs all -stages of all unmerged entries so that the unmerged files can be -processed by an external merge tool. - -A listing will be written to stdout providing the association of -temporary file names to tracked path names. The listing format -has two variations: - - . tempname TAB path RS -+ -The first format is what gets used when `--stage` is omitted or -is not `--stage=all`. The field tempname is the temporary file -name holding the file content and path is the tracked path name in -the index. Only the requested entries are output. - - . stage1temp SP stage2temp SP stage3tmp TAB path RS -+ -The second format is what gets used when `--stage=all`. The three -stage temporary fields (stage1temp, stage2temp, stage3temp) list the -name of the temporary file if there is a stage entry in the index -or `.` if there is no stage entry. Paths which only have a stage 0 -entry will always be omitted from the output. - -In both formats RS (the record separator) is newline by default -but will be the null byte if -z was passed on the command line. -The temporary file names are always safe strings; they will never -contain directory separators or whitespace characters. The path -field is always relative to the current directory and the temporary -file names are always relative to the top level directory. - -If the object being copied out to a temporary file is a symbolic -link the content of the link will be written to a normal file. It is -up to the end-user or the Porcelain to make use of this information. - - -EXAMPLES --------- -To update and refresh only the files already checked out:: -+ ----------------- -$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh ----------------- - -Using 'git checkout-index' to "export an entire tree":: - The prefix ability basically makes it trivial to use - 'git checkout-index' as an "export as tree" function. - Just read the desired tree into the index, and do: -+ ----------------- -$ git checkout-index --prefix=git-export-dir/ -a ----------------- -+ -`git checkout-index` will "export" the index into the specified -directory. -+ -The final "/" is important. The exported name is literally just -prefixed with the specified string. Contrast this with the -following example. - -Export files with a prefix:: -+ ----------------- -$ git checkout-index --prefix=.merged- Makefile ----------------- -+ -This will check out the currently cached copy of `Makefile` -into the file `.merged-Makefile`. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-checkout.txt b/third_party/git/Documentation/git-checkout.txt deleted file mode 100644 index cf3cac0a2b..0000000000 --- a/third_party/git/Documentation/git-checkout.txt +++ /dev/null @@ -1,584 +0,0 @@ -git-checkout(1) -=============== - -NAME ----- -git-checkout - Switch branches or restore working tree files - -SYNOPSIS --------- -[verse] -'git checkout' [-q] [-f] [-m] [<branch>] -'git checkout' [-q] [-f] [-m] --detach [<branch>] -'git checkout' [-q] [-f] [-m] [--detach] <commit> -'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>] -'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>... -'git checkout' [<tree-ish>] [--] <pathspec>... -'git checkout' (-p|--patch) [<tree-ish>] [--] [<paths>...] - -DESCRIPTION ------------ -Updates files in the working tree to match the version in the index -or the specified tree. If no paths are given, 'git checkout' will -also update `HEAD` to set the specified branch as the current -branch. - -'git checkout' [<branch>]:: - To prepare for working on `<branch>`, switch to it by updating - the index and the files in the working tree, and by pointing - `HEAD` at the branch. Local modifications to the files in the - working tree are kept, so that they can be committed to the - `<branch>`. -+ -If `<branch>` is not found but there does exist a tracking branch in -exactly one remote (call it `<remote>`) with a matching name and -`--no-guess` is not specified, treat as equivalent to -+ ------------- -$ git checkout -b <branch> --track <remote>/<branch> ------------- -+ -You could omit `<branch>`, in which case the command degenerates to -"check out the current branch", which is a glorified no-op with -rather expensive side-effects to show only the tracking information, -if exists, for the current branch. - -'git checkout' -b|-B <new_branch> [<start point>]:: - - Specifying `-b` causes a new branch to be created as if - linkgit:git-branch[1] were called and then checked out. In - this case you can use the `--track` or `--no-track` options, - which will be passed to 'git branch'. As a convenience, - `--track` without `-b` implies branch creation; see the - description of `--track` below. -+ -If `-B` is given, `<new_branch>` is created if it doesn't exist; otherwise, it -is reset. This is the transactional equivalent of -+ ------------- -$ git branch -f <branch> [<start point>] -$ git checkout <branch> ------------- -+ -that is to say, the branch is not reset/created unless "git checkout" is -successful. - -'git checkout' --detach [<branch>]:: -'git checkout' [--detach] <commit>:: - - Prepare to work on top of `<commit>`, by detaching `HEAD` at it - (see "DETACHED HEAD" section), and updating the index and the - files in the working tree. Local modifications to the files - in the working tree are kept, so that the resulting working - tree will be the state recorded in the commit plus the local - modifications. -+ -When the `<commit>` argument is a branch name, the `--detach` option can -be used to detach `HEAD` at the tip of the branch (`git checkout -<branch>` would check out that branch without detaching `HEAD`). -+ -Omitting `<branch>` detaches `HEAD` at the tip of the current branch. - -'git checkout' [<tree-ish>] [--] <pathspec>...:: - - Overwrite paths in the working tree by replacing with the - contents in the index or in the `<tree-ish>` (most often a - commit). When a `<tree-ish>` is given, the paths that - match the `<pathspec>` are updated both in the index and in - the working tree. -+ -The index may contain unmerged entries because of a previous failed merge. -By default, if you try to check out such an entry from the index, the -checkout operation will fail and nothing will be checked out. -Using `-f` will ignore these unmerged entries. The contents from a -specific side of the merge can be checked out of the index by -using `--ours` or `--theirs`. With `-m`, changes made to the working tree -file can be discarded to re-create the original conflicted merge result. - -'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]:: - This is similar to the "check out paths to the working tree - from either the index or from a tree-ish" mode described - above, but lets you use the interactive interface to show - the "diff" output and choose which hunks to use in the - result. See below for the description of `--patch` option. - - -OPTIONS -------- --q:: ---quiet:: - Quiet, suppress feedback messages. - ---progress:: ---no-progress:: - Progress status is reported on the standard error stream - by default when it is attached to a terminal, unless `--quiet` - is specified. This flag enables progress reporting even if not - attached to a terminal, regardless of `--quiet`. - --f:: ---force:: - When switching branches, proceed even if the index or the - working tree differs from `HEAD`. This is used to throw away - local changes. -+ -When checking out paths from the index, do not fail upon unmerged -entries; instead, unmerged entries are ignored. - ---ours:: ---theirs:: - When checking out paths from the index, check out stage #2 - ('ours') or #3 ('theirs') for unmerged paths. -+ -Note that during `git rebase` and `git pull --rebase`, 'ours' and -'theirs' may appear swapped; `--ours` gives the version from the -branch the changes are rebased onto, while `--theirs` gives the -version from the branch that holds your work that is being rebased. -+ -This is because `rebase` is used in a workflow that treats the -history at the remote as the shared canonical one, and treats the -work done on the branch you are rebasing as the third-party work to -be integrated, and you are temporarily assuming the role of the -keeper of the canonical history during the rebase. As the keeper of -the canonical history, you need to view the history from the remote -as `ours` (i.e. "our shared canonical history"), while what you did -on your side branch as `theirs` (i.e. "one contributor's work on top -of it"). - --b <new_branch>:: - Create a new branch named `<new_branch>` and start it at - `<start_point>`; see linkgit:git-branch[1] for details. - --B <new_branch>:: - Creates the branch `<new_branch>` and start it at `<start_point>`; - if it already exists, then reset it to `<start_point>`. This is - equivalent to running "git branch" with "-f"; see - linkgit:git-branch[1] for details. - --t:: ---track:: - When creating a new branch, set up "upstream" configuration. See - "--track" in linkgit:git-branch[1] for details. -+ -If no `-b` option is given, the name of the new branch will be -derived from the remote-tracking branch, by looking at the local part of -the refspec configured for the corresponding remote, and then stripping -the initial part up to the "*". -This would tell us to use `hack` as the local branch when branching -off of `origin/hack` (or `remotes/origin/hack`, or even -`refs/remotes/origin/hack`). If the given name has no slash, or the above -guessing results in an empty name, the guessing is aborted. You can -explicitly give a name with `-b` in such a case. - ---no-track:: - Do not set up "upstream" configuration, even if the - `branch.autoSetupMerge` configuration variable is true. - ---guess:: ---no-guess:: - If `<branch>` is not found but there does exist a tracking - branch in exactly one remote (call it `<remote>`) with a - matching name, treat as equivalent to -+ ------------- -$ git checkout -b <branch> --track <remote>/<branch> ------------- -+ -If the branch exists in multiple remotes and one of them is named by -the `checkout.defaultRemote` configuration variable, we'll use that -one for the purposes of disambiguation, even if the `<branch>` isn't -unique across all remotes. Set it to -e.g. `checkout.defaultRemote=origin` to always checkout remote -branches from there if `<branch>` is ambiguous but exists on the -'origin' remote. See also `checkout.defaultRemote` in -linkgit:git-config[1]. -+ -Use `--no-guess` to disable this. - --l:: - Create the new branch's reflog; see linkgit:git-branch[1] for - details. - ---detach:: - Rather than checking out a branch to work on it, check out a - commit for inspection and discardable experiments. - This is the default behavior of `git checkout <commit>` when - `<commit>` is not a branch name. See the "DETACHED HEAD" section - below for details. - ---orphan <new_branch>:: - Create a new 'orphan' branch, named `<new_branch>`, started from - `<start_point>` and switch to it. The first commit made on this - new branch will have no parents and it will be the root of a new - history totally disconnected from all the other branches and - commits. -+ -The index and the working tree are adjusted as if you had previously run -`git checkout <start_point>`. This allows you to start a new history -that records a set of paths similar to `<start_point>` by easily running -`git commit -a` to make the root commit. -+ -This can be useful when you want to publish the tree from a commit -without exposing its full history. You might want to do this to publish -an open source branch of a project whose current tree is "clean", but -whose full history contains proprietary or otherwise encumbered bits of -code. -+ -If you want to start a disconnected history that records a set of paths -that is totally different from the one of `<start_point>`, then you should -clear the index and the working tree right after creating the orphan -branch by running `git rm -rf .` from the top level of the working tree. -Afterwards you will be ready to prepare your new files, repopulating the -working tree, by copying them from elsewhere, extracting a tarball, etc. - ---ignore-skip-worktree-bits:: - In sparse checkout mode, `git checkout -- <paths>` would - update only entries matched by `<paths>` and sparse patterns - in `$GIT_DIR/info/sparse-checkout`. This option ignores - the sparse patterns and adds back any files in `<paths>`. - --m:: ---merge:: - When switching branches, - if you have local modifications to one or more files that - are different between the current branch and the branch to - which you are switching, the command refuses to switch - branches in order to preserve your modifications in context. - However, with this option, a three-way merge between the current - branch, your working tree contents, and the new branch - is done, and you will be on the new branch. -+ -When a merge conflict happens, the index entries for conflicting -paths are left unmerged, and you need to resolve the conflicts -and mark the resolved paths with `git add` (or `git rm` if the merge -should result in deletion of the path). -+ -When checking out paths from the index, this option lets you recreate -the conflicted merge in the specified paths. -+ -When switching branches with `--merge`, staged changes may be lost. - ---conflict=<style>:: - The same as `--merge` option above, but changes the way the - conflicting hunks are presented, overriding the - `merge.conflictStyle` configuration variable. Possible values are - "merge" (default) and "diff3" (in addition to what is shown by - "merge" style, shows the original contents). - --p:: ---patch:: - Interactively select hunks in the difference between the - `<tree-ish>` (or the index, if unspecified) and the working - tree. The chosen hunks are then applied in reverse to the - working tree (and if a `<tree-ish>` was specified, the index). -+ -This means that you can use `git checkout -p` to selectively discard -edits from your current working tree. See the ``Interactive Mode'' -section of linkgit:git-add[1] to learn how to operate the `--patch` mode. -+ -Note that this option uses the no overlay mode by default (see also -`--overlay`), and currently doesn't support overlay mode. - ---ignore-other-worktrees:: - `git checkout` refuses when the wanted ref is already checked - out by another worktree. This option makes it check the ref - out anyway. In other words, the ref can be held by more than one - worktree. - ---overwrite-ignore:: ---no-overwrite-ignore:: - Silently overwrite ignored files when switching branches. This - is the default behavior. Use `--no-overwrite-ignore` to abort - the operation when the new branch contains ignored files. - ---recurse-submodules:: ---no-recurse-submodules:: - Using `--recurse-submodules` will update the content of all initialized - submodules according to the commit recorded in the superproject. If - local modifications in a submodule would be overwritten the checkout - will fail unless `-f` is used. If nothing (or `--no-recurse-submodules`) - is used, the work trees of submodules will not be updated. - Just like linkgit:git-submodule[1], this will detach `HEAD` of the - submodule. - ---overlay:: ---no-overlay:: - In the default overlay mode, `git checkout` never - removes files from the index or the working tree. When - specifying `--no-overlay`, files that appear in the index and - working tree, but not in `<tree-ish>` are removed, to make them - match `<tree-ish>` exactly. - -<branch>:: - Branch to checkout; if it refers to a branch (i.e., a name that, - when prepended with "refs/heads/", is a valid ref), then that - branch is checked out. Otherwise, if it refers to a valid - commit, your `HEAD` becomes "detached" and you are no longer on - any branch (see below for details). -+ -You can use the `@{-N}` syntax to refer to the N-th last -branch/commit checked out using "git checkout" operation. You may -also specify `-` which is synonymous to `@{-1}`. -+ -As a special case, you may use `A...B` as a shortcut for the -merge base of `A` and `B` if there is exactly one merge base. You can -leave out at most one of `A` and `B`, in which case it defaults to `HEAD`. - -<new_branch>:: - Name for the new branch. - -<start_point>:: - The name of a commit at which to start the new branch; see - linkgit:git-branch[1] for details. Defaults to `HEAD`. -+ -As a special case, you may use `"A...B"` as a shortcut for the -merge base of `A` and `B` if there is exactly one merge base. You can -leave out at most one of `A` and `B`, in which case it defaults to `HEAD`. - -<tree-ish>:: - Tree to checkout from (when paths are given). If not specified, - the index will be used. - - - -DETACHED HEAD -------------- -`HEAD` normally refers to a named branch (e.g. `master`). Meanwhile, each -branch refers to a specific commit. Let's look at a repo with three -commits, one of them tagged, and with branch `master` checked out: - ------------- - HEAD (refers to branch 'master') - | - v -a---b---c branch 'master' (refers to commit 'c') - ^ - | - tag 'v2.0' (refers to commit 'b') ------------- - -When a commit is created in this state, the branch is updated to refer to -the new commit. Specifically, 'git commit' creates a new commit `d`, whose -parent is commit `c`, and then updates branch `master` to refer to new -commit `d`. `HEAD` still refers to branch `master` and so indirectly now refers -to commit `d`: - ------------- -$ edit; git add; git commit - - HEAD (refers to branch 'master') - | - v -a---b---c---d branch 'master' (refers to commit 'd') - ^ - | - tag 'v2.0' (refers to commit 'b') ------------- - -It is sometimes useful to be able to checkout a commit that is not at -the tip of any named branch, or even to create a new commit that is not -referenced by a named branch. Let's look at what happens when we -checkout commit `b` (here we show two ways this may be done): - ------------- -$ git checkout v2.0 # or -$ git checkout master^^ - - HEAD (refers to commit 'b') - | - v -a---b---c---d branch 'master' (refers to commit 'd') - ^ - | - tag 'v2.0' (refers to commit 'b') ------------- - -Notice that regardless of which checkout command we use, `HEAD` now refers -directly to commit `b`. This is known as being in detached `HEAD` state. -It means simply that `HEAD` refers to a specific commit, as opposed to -referring to a named branch. Let's see what happens when we create a commit: - ------------- -$ edit; git add; git commit - - HEAD (refers to commit 'e') - | - v - e - / -a---b---c---d branch 'master' (refers to commit 'd') - ^ - | - tag 'v2.0' (refers to commit 'b') ------------- - -There is now a new commit `e`, but it is referenced only by `HEAD`. We can -of course add yet another commit in this state: - ------------- -$ edit; git add; git commit - - HEAD (refers to commit 'f') - | - v - e---f - / -a---b---c---d branch 'master' (refers to commit 'd') - ^ - | - tag 'v2.0' (refers to commit 'b') ------------- - -In fact, we can perform all the normal Git operations. But, let's look -at what happens when we then checkout `master`: - ------------- -$ git checkout master - - HEAD (refers to branch 'master') - e---f | - / v -a---b---c---d branch 'master' (refers to commit 'd') - ^ - | - tag 'v2.0' (refers to commit 'b') ------------- - -It is important to realize that at this point nothing refers to commit -`f`. Eventually commit `f` (and by extension commit `e`) will be deleted -by the routine Git garbage collection process, unless we create a reference -before that happens. If we have not yet moved away from commit `f`, -any of these will create a reference to it: - ------------- -$ git checkout -b foo <1> -$ git branch foo <2> -$ git tag foo <3> ------------- - -<1> creates a new branch `foo`, which refers to commit `f`, and then - updates `HEAD` to refer to branch `foo`. In other words, we'll no longer - be in detached `HEAD` state after this command. - -<2> similarly creates a new branch `foo`, which refers to commit `f`, - but leaves `HEAD` detached. - -<3> creates a new tag `foo`, which refers to commit `f`, - leaving `HEAD` detached. - -If we have moved away from commit `f`, then we must first recover its object -name (typically by using git reflog), and then we can create a reference to -it. For example, to see the last two commits to which `HEAD` referred, we -can use either of these commands: - ------------- -$ 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 --------- - -. The following sequence checks out the `master` branch, reverts - the `Makefile` to two revisions back, deletes `hello.c` by - mistake, and gets it back from the index. -+ ------------- -$ git checkout master <1> -$ git checkout master~2 Makefile <2> -$ rm -f hello.c -$ git checkout hello.c <3> ------------- -+ -<1> switch branch -<2> take a file out of another commit -<3> restore `hello.c` from the index -+ -If you want to check out _all_ C source files out of the index, -you can say -+ ------------- -$ git checkout -- '*.c' ------------- -+ -Note the quotes around `*.c`. The file `hello.c` will also be -checked out, even though it is no longer in the working tree, -because the file globbing is used to match entries in the index -(not in the working tree by the shell). -+ -If you have an unfortunate branch that is named `hello.c`, this -step would be confused as an instruction to switch to that branch. -You should instead write: -+ ------------- -$ git checkout -- hello.c ------------- - -. After working in the wrong branch, switching to the correct - branch would be done using: -+ ------------- -$ git checkout mytopic ------------- -+ -However, your "wrong" branch and correct `mytopic` branch may -differ in files that you have modified locally, in which case -the above checkout would fail like this: -+ ------------- -$ git checkout mytopic -error: You have local changes to 'frotz'; not switching branches. ------------- -+ -You can give the `-m` flag to the command, which would try a -three-way merge: -+ ------------- -$ git checkout -m mytopic -Auto-merging frotz ------------- -+ -After this three-way merge, the local modifications are _not_ -registered in your index file, so `git diff` would show you what -changes you made since the tip of the new branch. - -. When a merge conflict happens during switching branches with - the `-m` option, you would see something like this: -+ ------------- -$ git checkout -m mytopic -Auto-merging frotz -ERROR: Merge conflict in frotz -fatal: merge program failed ------------- -+ -At this point, `git diff` shows the changes cleanly merged as in -the previous example, as well as the changes in the conflicted -files. Edit and resolve the conflict and mark it resolved with -`git add` as usual: -+ ------------- -$ edit frotz -$ git add frotz ------------- - -SEE ALSO --------- -linkgit:git-switch[1], -linkgit:git-restore[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-cherry-pick.txt b/third_party/git/Documentation/git-cherry-pick.txt deleted file mode 100644 index 83ce51aedf..0000000000 --- a/third_party/git/Documentation/git-cherry-pick.txt +++ /dev/null @@ -1,243 +0,0 @@ -git-cherry-pick(1) -================== - -NAME ----- -git-cherry-pick - Apply the changes introduced by some existing commits - -SYNOPSIS --------- -[verse] -'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] - [-S[<keyid>]] <commit>... -'git cherry-pick' (--continue | --skip | --abort | --quit) - -DESCRIPTION ------------ - -Given one or more existing commits, apply the change each one -introduces, recording a new commit for each. This requires your -working tree to be clean (no modifications from the HEAD commit). - -When it is not obvious how to apply a change, the following -happens: - -1. The current branch and `HEAD` pointer stay at the last commit - successfully made. -2. The `CHERRY_PICK_HEAD` ref is set to point at the commit that - introduced the change that is difficult to apply. -3. Paths in which the change applied cleanly are updated both - in the index file and in your working tree. -4. For conflicting paths, the index file records up to three - versions, as described in the "TRUE MERGE" section of - linkgit:git-merge[1]. The working tree files will include - a description of the conflict bracketed by the usual - conflict markers `<<<<<<<` and `>>>>>>>`. -5. No other modifications are made. - -See linkgit:git-merge[1] for some hints on resolving such -conflicts. - -OPTIONS -------- -<commit>...:: - Commits to cherry-pick. - For a more complete list of ways to spell commits, see - linkgit:gitrevisions[7]. - Sets of commits can be passed but no traversal is done by - default, as if the `--no-walk` option was specified, see - linkgit:git-rev-list[1]. Note that specifying a range will - feed all <commit>... arguments to a single revision walk - (see a later example that uses 'maint master..next'). - --e:: ---edit:: - With this option, 'git cherry-pick' will let you edit the commit - message prior to committing. - ---cleanup=<mode>:: - This option determines how the commit message will be cleaned up before - being passed on to the commit machinery. See linkgit:git-commit[1] for more - details. In particular, if the '<mode>' is given a value of `scissors`, - scissors will be appended to `MERGE_MSG` before being passed on in the case - of a conflict. - --x:: - When recording the commit, append a line that says - "(cherry picked from commit ...)" to the original commit - message in order to indicate which commit this change was - cherry-picked from. This is done only for cherry - picks without conflicts. Do not use this option if - you are cherry-picking from your private branch because - the information is useless to the recipient. If on the - other hand you are cherry-picking between two publicly - visible branches (e.g. backporting a fix to a - maintenance branch for an older release from a - development branch), adding this information can be - useful. - --r:: - It used to be that the command defaulted to do `-x` - described above, and `-r` was to disable it. Now the - default is not to do `-x` so this option is a no-op. - --m parent-number:: ---mainline parent-number:: - Usually you cannot cherry-pick a merge because you do not know which - side of the merge should be considered the mainline. This - option specifies the parent number (starting from 1) of - the mainline and allows cherry-pick to replay the change - relative to the specified parent. - --n:: ---no-commit:: - Usually the command automatically creates a sequence of commits. - This flag applies the changes necessary to cherry-pick - each named commit to your working tree and the index, - without making any commit. In addition, when this - option is used, your index does not have to match the - HEAD commit. The cherry-pick is done against the - beginning state of your index. -+ -This is useful when cherry-picking more than one commits' -effect to your index in a row. - --s:: ---signoff:: - Add Signed-off-by line at the end of the commit message. - See the signoff option in linkgit:git-commit[1] for more information. - --S[<keyid>]:: ---gpg-sign[=<keyid>]:: - GPG-sign commits. The `keyid` argument is optional and - defaults to the committer identity; if specified, it must be - stuck to the option without a space. - ---ff:: - If the current HEAD is the same as the parent of the - cherry-pick'ed commit, then a fast forward to this commit will - be performed. - ---allow-empty:: - By default, cherry-picking an empty commit will fail, - indicating that an explicit invocation of `git commit - --allow-empty` is required. This option overrides that - behavior, allowing empty commits to be preserved automatically - in a cherry-pick. Note that when "--ff" is in effect, empty - commits that meet the "fast-forward" requirement will be kept - even without this option. Note also, that use of this option only - keeps commits that were initially empty (i.e. the commit recorded the - same tree as its parent). Commits which are made empty due to a - previous commit are dropped. To force the inclusion of those commits - use `--keep-redundant-commits`. - ---allow-empty-message:: - By default, cherry-picking a commit with an empty message will fail. - This option overrides that behavior, allowing commits with empty - messages to be cherry picked. - ---keep-redundant-commits:: - If a commit being cherry picked duplicates a commit already in the - current history, it will become empty. By default these - redundant commits cause `cherry-pick` to stop so the user can - examine the commit. This option overrides that behavior and - creates an empty commit object. Implies `--allow-empty`. - ---strategy=<strategy>:: - Use the given merge strategy. Should only be used once. - See the MERGE STRATEGIES section in linkgit:git-merge[1] - for details. - --X<option>:: ---strategy-option=<option>:: - Pass the merge strategy-specific option through to the - merge strategy. See linkgit:git-merge[1] for details. - ---rerere-autoupdate:: ---no-rerere-autoupdate:: - Allow the rerere mechanism to update the index with the - result of auto-conflict resolution if possible. - -SEQUENCER SUBCOMMANDS ---------------------- -include::sequencer.txt[] - -EXAMPLES --------- -`git cherry-pick master`:: - - Apply the change introduced by the commit at the tip of the - master branch and create a new commit with this change. - -`git cherry-pick ..master`:: -`git cherry-pick ^HEAD master`:: - - Apply the changes introduced by all commits that are ancestors - of master but not of HEAD to produce new commits. - -`git cherry-pick maint next ^master`:: -`git cherry-pick maint master..next`:: - - Apply the changes introduced by all commits that are - ancestors of maint or next, but not master or any of its - ancestors. Note that the latter does not mean `maint` and - everything between `master` and `next`; specifically, - `maint` will not be used if it is included in `master`. - -`git cherry-pick master~4 master~2`:: - - Apply the changes introduced by the fifth and third last - commits pointed to by master and create 2 new commits with - these changes. - -`git cherry-pick -n master~1 next`:: - - Apply to the working tree and the index the changes introduced - by the second last commit pointed to by master and by the last - commit pointed to by next, but do not create any commit with - these changes. - -`git cherry-pick --ff ..next`:: - - If history is linear and HEAD is an ancestor of next, update - the working tree and advance the HEAD pointer to match next. - Otherwise, apply the changes introduced by those commits that - are in next but not HEAD to the current branch, creating a new - commit for each new change. - -`git rev-list --reverse master -- README | git cherry-pick -n --stdin`:: - - Apply the changes introduced by all commits on the master - branch that touched README to the working tree and index, - so the result can be inspected and made into a single new - commit if suitable. - -The following sequence attempts to backport a patch, bails out because -the code the patch applies to has changed too much, and then tries -again, this time exercising more care about matching up context lines. - ------------- -$ git cherry-pick topic^ <1> -$ git diff <2> -$ git reset --merge ORIG_HEAD <3> -$ git cherry-pick -Xpatience topic^ <4> ------------- -<1> apply the change that would be shown by `git show topic^`. - In this example, the patch does not apply cleanly, so - information about the conflict is written to the index and - working tree and no new commit results. -<2> summarize changes to be reconciled -<3> cancel the cherry-pick. In other words, return to the - pre-cherry-pick state, preserving any local modifications - you had in the working tree. -<4> try to apply the change introduced by `topic^` again, - spending extra time to avoid mistakes based on incorrectly - matching context lines. - -SEE ALSO --------- -linkgit:git-revert[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-cherry.txt b/third_party/git/Documentation/git-cherry.txt deleted file mode 100644 index 0ea921a593..0000000000 --- a/third_party/git/Documentation/git-cherry.txt +++ /dev/null @@ -1,145 +0,0 @@ -git-cherry(1) -============= - -NAME ----- -git-cherry - Find commits yet to be applied to upstream - -SYNOPSIS --------- -[verse] -'git cherry' [-v] [<upstream> [<head> [<limit>]]] - -DESCRIPTION ------------ -Determine whether there are commits in `<head>..<upstream>` that are -equivalent to those in the range `<limit>..<head>`. - -The equivalence test is based on the diff, after removing whitespace -and line numbers. git-cherry therefore detects when commits have been -"copied" by means of linkgit:git-cherry-pick[1], linkgit:git-am[1] or -linkgit:git-rebase[1]. - -Outputs the SHA1 of every commit in `<limit>..<head>`, prefixed with -`-` for commits that have an equivalent in <upstream>, and `+` for -commits that do not. - -OPTIONS -------- --v:: - Show the commit subjects next to the SHA1s. - -<upstream>:: - Upstream branch to search for equivalent commits. - Defaults to the upstream branch of HEAD. - -<head>:: - Working branch; defaults to HEAD. - -<limit>:: - Do not report commits up to (and including) limit. - -EXAMPLES --------- - -Patch workflows -~~~~~~~~~~~~~~~ - -git-cherry is frequently used in patch-based workflows (see -linkgit:gitworkflows[7]) to determine if a series of patches has been -applied by the upstream maintainer. In such a workflow you might -create and send a topic branch like this: - ------------- -$ git checkout -b topic origin/master -# work and create some commits -$ git format-patch origin/master -$ git send-email ... 00* ------------- - -Later, you can see whether your changes have been applied by saying -(still on `topic`): - ------------- -$ git fetch # update your notion of origin/master -$ git cherry -v ------------- - -Concrete example -~~~~~~~~~~~~~~~~ - -In a situation where topic consisted of three commits, and the -maintainer applied two of them, the situation might look like: - ------------- -$ git log --graph --oneline --decorate --boundary origin/master...topic -* 7654321 (origin/master) upstream tip commit -[... snip some other commits ...] -* cccc111 cherry-pick of C -* aaaa111 cherry-pick of A -[... snip a lot more that has happened ...] -| * cccc000 (topic) commit C -| * bbbb000 commit B -| * aaaa000 commit A -|/ -o 1234567 branch point ------------- - -In such cases, git-cherry shows a concise summary of what has yet to -be applied: - ------------- -$ git cherry origin/master topic -- cccc000... commit C -+ bbbb000... commit B -- aaaa000... commit A ------------- - -Here, we see that the commits A and C (marked with `-`) can be -dropped from your `topic` branch when you rebase it on top of -`origin/master`, while the commit B (marked with `+`) still needs to -be kept so that it will be sent to be applied to `origin/master`. - - -Using a limit -~~~~~~~~~~~~~ - -The optional <limit> is useful in cases where your topic is based on -other work that is not in upstream. Expanding on the previous -example, this might look like: - ------------- -$ git log --graph --oneline --decorate --boundary origin/master...topic -* 7654321 (origin/master) upstream tip commit -[... snip some other commits ...] -* cccc111 cherry-pick of C -* aaaa111 cherry-pick of A -[... snip a lot more that has happened ...] -| * cccc000 (topic) commit C -| * bbbb000 commit B -| * aaaa000 commit A -| * 0000fff (base) unpublished stuff F -[... snip ...] -| * 0000aaa unpublished stuff A -|/ -o 1234567 merge-base between upstream and topic ------------- - -By specifying `base` as the limit, you can avoid listing commits -between `base` and `topic`: - ------------- -$ git cherry origin/master topic base -- cccc000... commit C -+ bbbb000... commit B -- aaaa000... commit A ------------- - - -SEE ALSO --------- -linkgit:git-patch-id[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-citool.txt b/third_party/git/Documentation/git-citool.txt deleted file mode 100644 index c7a11c36c1..0000000000 --- a/third_party/git/Documentation/git-citool.txt +++ /dev/null @@ -1,25 +0,0 @@ -git-citool(1) -============= - -NAME ----- -git-citool - Graphical alternative to git-commit - -SYNOPSIS --------- -[verse] -'git citool' - -DESCRIPTION ------------ -A Tcl/Tk based graphical interface to review modified files, stage -them into the index, enter a commit message and record the new -commit onto the current branch. This interface is an alternative -to the less interactive 'git commit' program. - -'git citool' is actually a standard alias for `git gui citool`. -See linkgit:git-gui[1] for more details. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-clean.txt b/third_party/git/Documentation/git-clean.txt deleted file mode 100644 index 0028ff12d1..0000000000 --- a/third_party/git/Documentation/git-clean.txt +++ /dev/null @@ -1,140 +0,0 @@ -git-clean(1) -============ - -NAME ----- -git-clean - Remove untracked files from the working tree - -SYNOPSIS --------- -[verse] -'git clean' [-d] [-f] [-i] [-n] [-q] [-e <pattern>] [-x | -X] [--] <path>... - -DESCRIPTION ------------ - -Cleans the working tree by recursively removing files that are not -under version control, starting from the current directory. - -Normally, only files unknown to Git are removed, but if the `-x` -option is specified, ignored files are also removed. This can, for -example, be useful to remove all build products. - -If any optional `<path>...` arguments are given, only those paths -are affected. - -OPTIONS -------- --d:: - Remove untracked directories in addition to untracked files. - If an untracked directory is managed by a different Git - repository, it is not removed by default. Use -f option twice - if you really want to remove such a directory. - --f:: ---force:: - If the Git configuration variable clean.requireForce is not set - to false, 'git clean' will refuse to delete files or directories - unless given -f, -n or -i. Git will refuse to delete directories - with .git sub directory or file unless a second -f - is given. - --i:: ---interactive:: - Show what would be done and clean files interactively. See - ``Interactive mode'' for details. - --n:: ---dry-run:: - Don't actually remove anything, just show what would be done. - --q:: ---quiet:: - Be quiet, only report errors, but not the files that are - successfully removed. - --e <pattern>:: ---exclude=<pattern>:: - Use the given exclude pattern in addition to the standard ignore rules - (see linkgit:gitignore[5]). - --x:: - Don't use the standard ignore rules (see linkgit:gitignore[5]), but - still use the ignore rules given with `-e` options from the command - line. This allows removing all untracked - files, including build products. This can be used (possibly in - conjunction with 'git restore' or 'git reset') to create a pristine - working directory to test a clean build. - --X:: - Remove only files ignored by Git. This may be useful to rebuild - everything from scratch, but keep manually created files. - -Interactive mode ----------------- -When the command enters the interactive mode, it shows the -files and directories to be cleaned, and goes into its -interactive command loop. - -The command loop shows the list of subcommands available, and -gives a prompt "What now> ". In general, when the prompt ends -with a single '>', you can pick only one of the choices given -and type return, like this: - ------------- - *** Commands *** - 1: clean 2: filter by pattern 3: select by numbers - 4: ask each 5: quit 6: help - What now> 1 ------------- - -You also could say `c` or `clean` above as long as the choice is unique. - -The main command loop has 6 subcommands. - -clean:: - - Start cleaning files and directories, and then quit. - -filter by pattern:: - - This shows the files and directories to be deleted and issues an - "Input ignore patterns>>" prompt. You can input space-separated - patterns to exclude files and directories from deletion. - E.g. "*.c *.h" will excludes files end with ".c" and ".h" from - deletion. When you are satisfied with the filtered result, press - ENTER (empty) back to the main menu. - -select by numbers:: - - This shows the files and directories to be deleted and issues an - "Select items to delete>>" prompt. When the prompt ends with double - '>>' like this, you can make more than one selection, concatenated - with whitespace or comma. Also you can say ranges. E.g. "2-5 7,9" - to choose 2,3,4,5,7,9 from the list. If the second number in a - range is omitted, all remaining items are selected. E.g. "7-" to - choose 7,8,9 from the list. You can say '*' to choose everything. - Also when you are satisfied with the filtered result, press ENTER - (empty) back to the main menu. - -ask each:: - - This will start to clean, and you must confirm one by one in order - to delete items. Please note that this action is not as efficient - as the above two actions. - -quit:: - - This lets you quit without do cleaning. - -help:: - - Show brief usage of interactive git-clean. - -SEE ALSO --------- -linkgit:gitignore[5] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-clone.txt b/third_party/git/Documentation/git-clone.txt deleted file mode 100644 index 34011c2940..0000000000 --- a/third_party/git/Documentation/git-clone.txt +++ /dev/null @@ -1,337 +0,0 @@ -git-clone(1) -============ - -NAME ----- -git-clone - Clone a repository into a new directory - - -SYNOPSIS --------- -[verse] -'git clone' [--template=<template_directory>] - [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] - [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] - [--dissociate] [--separate-git-dir <git dir>] - [--depth <depth>] [--[no-]single-branch] [--no-tags] - [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules] - [--[no-]remote-submodules] [--jobs <n>] [--] <repository> - [<directory>] - -DESCRIPTION ------------ - -Clones a repository into a newly created directory, creates -remote-tracking branches for each branch in the cloned repository -(visible using `git branch --remotes`), and creates and checks out an -initial branch that is forked from the cloned repository's -currently active branch. - -After the clone, a plain `git fetch` without arguments will update -all the remote-tracking branches, and a `git pull` without -arguments will in addition merge the remote master branch into the -current master branch, if any (this is untrue when "--single-branch" -is given; see below). - -This default configuration is achieved by creating references to -the remote branch heads under `refs/remotes/origin` and -by initializing `remote.origin.url` and `remote.origin.fetch` -configuration variables. - - -OPTIONS -------- --l:: ---local:: - When the repository to clone from is on a local machine, - this flag bypasses the normal "Git aware" transport - mechanism and clones the repository by making a copy of - HEAD and everything under objects and refs directories. - The files under `.git/objects/` directory are hardlinked - to save space when possible. -+ -If the repository is specified as a local path (e.g., `/path/to/repo`), -this is the default, and --local is essentially a no-op. If the -repository is specified as a URL, then this flag is ignored (and we -never use the local optimizations). Specifying `--no-local` will -override the default when `/path/to/repo` is given, using the regular -Git transport instead. - ---no-hardlinks:: - Force the cloning process from a repository on a local - filesystem to copy the files under the `.git/objects` - directory instead of using hardlinks. This may be desirable - if you are trying to make a back-up of your repository. - --s:: ---shared:: - When the repository to clone is on the local machine, - instead of using hard links, automatically setup - `.git/objects/info/alternates` to share the objects - with the source repository. The resulting repository - starts out without any object of its own. -+ -*NOTE*: this is a possibly dangerous operation; do *not* use -it unless you understand what it does. If you clone your -repository using this option and then delete branches (or use any -other Git command that makes any existing commit unreferenced) in the -source repository, some objects may become unreferenced (or dangling). -These objects may be removed by normal Git operations (such as `git commit`) -which automatically call `git gc --auto`. (See linkgit:git-gc[1].) -If these objects are removed and were referenced by the cloned repository, -then the cloned repository will become corrupt. -+ -Note that running `git repack` without the `--local` option in a repository -cloned with `--shared` will copy objects from the source repository into a pack -in the cloned repository, removing the disk space savings of `clone --shared`. -It is safe, however, to run `git gc`, which uses the `--local` option by -default. -+ -If you want to break the dependency of a repository cloned with `--shared` 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[-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. - ---dissociate:: - Borrow the objects from reference repositories specified - with the `--reference` options only to reduce network - transfer, and stop borrowing from them after a clone is made - by making necessary local copies of borrowed objects. This - option can also be used when cloning locally from a - repository that already borrows objects from another - repository--the new repository will borrow objects from the - same repository, and this option can be used to stop the - borrowing. - --q:: ---quiet:: - Operate quietly. Progress is not reported to the standard - error stream. - --v:: ---verbose:: - Run verbosely. Does not affect the reporting of progress status - to the standard error stream. - ---progress:: - Progress status is reported on the standard error stream - by default when it is attached to a terminal, unless `--quiet` - is specified. This flag forces progress status even if the - standard error stream is not directed to a terminal. - ---server-option=<option>:: - Transmit the given string to the server when communicating using - protocol version 2. The given string must not contain a NUL or LF - character. The server's handling of server options, including - unknown ones, is server-specific. - When multiple `--server-option=<option>` are given, they are all - sent to the other side in the order listed on the command line. - --n:: ---no-checkout:: - No checkout of HEAD is performed after the clone is complete. - ---bare:: - Make a 'bare' Git repository. That is, instead of - creating `<directory>` and placing the administrative - files in `<directory>/.git`, make the `<directory>` - itself the `$GIT_DIR`. This obviously implies the `--no-checkout` - because there is nowhere to check out the working tree. - Also the branch heads at the remote are copied directly - to corresponding local branch heads, without mapping - them to `refs/remotes/origin/`. When this option is - used, neither remote-tracking branches nor the related - configuration variables are created. - ---mirror:: - Set up a mirror of the source repository. This implies `--bare`. - Compared to `--bare`, `--mirror` not only maps local branches of the - source to local branches of the target, it maps all refs (including - remote-tracking branches, notes etc.) and sets up a refspec configuration such - that all these refs are overwritten by a `git remote update` in the - target repository. - --o <name>:: ---origin <name>:: - Instead of using the remote name `origin` to keep track - of the upstream repository, use `<name>`. - --b <name>:: ---branch <name>:: - Instead of pointing the newly created HEAD to the branch pointed - to by the cloned repository's HEAD, point to `<name>` branch - instead. In a non-bare repository, this is the branch that will - be checked out. - `--branch` can also take tags and detaches the HEAD at that commit - in the resulting repository. - --u <upload-pack>:: ---upload-pack <upload-pack>:: - When given, and the repository to clone from is accessed - via ssh, this specifies a non-default path for the command - run on the other end. - ---template=<template_directory>:: - Specify the directory from which templates will be used; - (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].) - --c <key>=<value>:: ---config <key>=<value>:: - Set a configuration variable in the newly-created repository; - this takes effect immediately after the repository is - initialized, but before the remote history is fetched or any - files checked out. The key is in the same format as expected by - linkgit:git-config[1] (e.g., `core.eol=true`). If multiple - values are given for the same key, each value will be written to - the config file. This makes it safe, for example, to add - additional fetch refspecs to the origin remote. -+ -Due to limitations of the current implementation, some configuration -variables do not take effect until after the initial fetch and checkout. -Configuration variables known to not take effect are: -`remote.<name>.mirror` and `remote.<name>.tagOpt`. Use the -corresponding `--mirror` and `--no-tags` options instead. - ---depth <depth>:: - Create a 'shallow' clone with a history truncated to the - specified number of commits. Implies `--single-branch` unless - `--no-single-branch` is given to fetch the histories near the - 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 - branch remote's `HEAD` points at. - Further fetches into the resulting repository will only update the - remote-tracking branch for the branch this option was used for the - initial cloning. If the HEAD at the remote did not point at any - branch when `--single-branch` clone was made, no remote-tracking - branch is created. - ---no-tags:: - Don't clone any tags, and set - `remote.<remote>.tagOpt=--no-tags` in the config, ensuring - that future `git pull` and `git fetch` operations won't follow - any tags. Subsequent explicit tag fetches will still work, - (see linkgit:git-fetch[1]). -+ -Can be used in conjunction with `--single-branch` to clone and -maintain a branch with no references other than a single cloned -branch. This is useful e.g. to maintain minimal clones of the default -branch of some repository for search indexing. - ---recurse-submodules[=<pathspec]:: - After the clone is created, initialize and clone submodules - within based on the provided pathspec. If no pathspec is - provided, all submodules are initialized and cloned. - This option can be given multiple times for pathspecs consisting - of multiple entries. The resulting clone has `submodule.active` set to - the provided pathspec, or "." (meaning all submodules) if no - pathspec is provided. -+ -Submodules are initialized and cloned using their default settings. This is -equivalent to running -`git submodule update --init --recursive <pathspec>` immediately after -the clone is finished. This option is ignored if the cloned repository does -not have a worktree/checkout (i.e. if any of `--no-checkout`/`-n`, `--bare`, -or `--mirror` is given) - ---[no-]shallow-submodules:: - All submodules which are cloned will be shallow with a depth of 1. - ---[no-]remote-submodules:: - All submodules which are cloned will use the status of the submoduleโs - remote-tracking branch to update the submodule, rather than the - superprojectโs recorded SHA-1. Equivalent to passing `--remote` to - `git submodule update`. - ---separate-git-dir=<git dir>:: - Instead of placing the cloned repository where it is supposed - to be, place the cloned repository at the specified directory, - then make a filesystem-agnostic Git symbolic link to there. - The result is Git repository can be separated from working - tree. - --j <n>:: ---jobs <n>:: - The number of submodules fetched at the same time. - Defaults to the `submodule.fetchJobs` option. - -<repository>:: - The (possibly remote) repository to clone from. See the - <<URLS,GIT URLS>> section below for more information on specifying - repositories. - -<directory>:: - The name of a new directory to clone into. The "humanish" - part of the source repository is used if no directory is - explicitly given (`repo` for `/path/to/repo.git` and `foo` - for `host.xz:foo/.git`). Cloning into an existing directory - is only allowed if the directory is empty. - -:git-clone: 1 -include::urls.txt[] - -EXAMPLES --------- - -* Clone from upstream: -+ ------------- -$ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux -$ cd my-linux -$ make ------------- - - -* Make a local clone that borrows from the current directory, without checking things out: -+ ------------- -$ git clone -l -s -n . ../copy -$ cd ../copy -$ git show-branch ------------- - - -* Clone from upstream while borrowing from an existing local directory: -+ ------------- -$ git clone --reference /git/linux.git \ - git://git.kernel.org/pub/scm/.../linux.git \ - my-linux -$ cd my-linux ------------- - - -* Create a bare repository to publish your changes to the public: -+ ------------- -$ git clone --bare -l /home/proj/.git /pub/scm/proj.git ------------- - - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-column.txt b/third_party/git/Documentation/git-column.txt deleted file mode 100644 index f58e9c43e6..0000000000 --- a/third_party/git/Documentation/git-column.txt +++ /dev/null @@ -1,79 +0,0 @@ -git-column(1) -============= - -NAME ----- -git-column - Display data in columns - -SYNOPSIS --------- -[verse] -'git column' [--command=<name>] [--[raw-]mode=<mode>] [--width=<width>] - [--indent=<string>] [--nl=<string>] [--padding=<n>] - -DESCRIPTION ------------ -This command formats the lines of its standard input into a table with -multiple columns. Each input line occupies one cell of the table. It -is used internally by other git commands to format output into -columns. - -OPTIONS -------- ---command=<name>:: - Look up layout mode using configuration variable column.<name> and - column.ui. - ---mode=<mode>:: - Specify layout mode. See configuration variable column.ui for option - syntax in linkgit:git-config[1]. - ---raw-mode=<n>:: - Same as --mode but take mode encoded as a number. This is mainly used - by other commands that have already parsed layout mode. - ---width=<width>:: - Specify the terminal width. By default 'git column' will detect the - terminal width, or fall back to 80 if it is unable to do so. - ---indent=<string>:: - String to be printed at the beginning of each line. - ---nl=<N>:: - String to be printed at the end of each line, - including newline character. - ---padding=<N>:: - The number of spaces between columns. One space by default. - -EXAMPLES --------- - -Format data by columns: ------------- -$ seq 1 24 | git column --mode=column --padding=5 -1 4 7 10 13 16 19 22 -2 5 8 11 14 17 20 23 -3 6 9 12 15 18 21 24 ------------- - -Format data by rows: ------------- -$ seq 1 21 | git column --mode=row --padding=5 -1 2 3 4 5 6 7 -8 9 10 11 12 13 14 -15 16 17 18 19 20 21 ------------- - -List some tags in a table with unequal column widths: ------------- -$ git tag --list 'v2.4.*' --column=row,dense -v2.4.0 v2.4.0-rc0 v2.4.0-rc1 v2.4.0-rc2 v2.4.0-rc3 -v2.4.1 v2.4.10 v2.4.11 v2.4.12 v2.4.2 -v2.4.3 v2.4.4 v2.4.5 v2.4.6 v2.4.7 -v2.4.8 v2.4.9 ------------- - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-commit-graph.txt b/third_party/git/Documentation/git-commit-graph.txt deleted file mode 100644 index eb5e7865f0..0000000000 --- a/third_party/git/Documentation/git-commit-graph.txt +++ /dev/null @@ -1,127 +0,0 @@ -git-commit-graph(1) -=================== - -NAME ----- -git-commit-graph - Write and verify Git commit-graph files - - -SYNOPSIS --------- -[verse] -'git commit-graph read' [--object-dir <dir>] -'git commit-graph verify' [--object-dir <dir>] [--shallow] -'git commit-graph write' <options> [--object-dir <dir>] - - -DESCRIPTION ------------ - -Manage the serialized commit-graph file. - - -OPTIONS -------- ---object-dir:: - Use given directory for the location of packfiles and commit-graph - file. This parameter exists to specify the location of an alternate - that only has the objects directory, not a full `.git` directory. The - commit-graph file is expected to be in the `<dir>/info` directory and - the packfiles are expected to be in `<dir>/pack`. - - -COMMANDS --------- -'write':: - -Write a commit-graph file based on the commits found in packfiles. -+ -With the `--stdin-packs` option, generate the new commit graph by -walking objects only in the specified pack-indexes. (Cannot be combined -with `--stdin-commits` or `--reachable`.) -+ -With the `--stdin-commits` option, generate the new commit graph by -walking commits starting at the commits specified in stdin as a list -of OIDs in hex, one OID per line. (Cannot be combined with -`--stdin-packs` or `--reachable`.) -+ -With the `--reachable` option, generate the new commit graph by walking -commits starting at all refs. (Cannot be combined with `--stdin-commits` -or `--stdin-packs`.) -+ -With the `--append` option, include all commits that are present in the -existing commit-graph file. -+ -With the `--split` option, write the commit-graph as a chain of multiple -commit-graph files stored in `<dir>/info/commit-graphs`. The new commits -not already in the commit-graph are added in a new "tip" file. This file -is merged with the existing file if the following merge conditions are -met: -+ -* If `--size-multiple=<X>` is not specified, let `X` equal 2. If the new -tip file would have `N` commits and the previous tip has `M` commits and -`X` times `N` is greater than `M`, instead merge the two files into a -single file. -+ -* If `--max-commits=<M>` is specified with `M` a positive integer, and the -new tip file would have more than `M` commits, then instead merge the new -tip with the previous tip. -+ -Finally, if `--expire-time=<datetime>` is not specified, let `datetime` -be the current time. After writing the split commit-graph, delete all -unused commit-graph whose modified times are older than `datetime`. - -'read':: - -Read the commit-graph file and output basic details about it. -Used for debugging purposes. - -'verify':: - -Read the commit-graph file and verify its contents against the object -database. Used to check for corrupted data. -+ -With the `--shallow` option, only check the tip commit-graph file in -a chain of split commit-graphs. - - -EXAMPLES --------- - -* Write a commit-graph file for the packed commits in your local `.git` - directory. -+ ------------------------------------------------- -$ git commit-graph write ------------------------------------------------- - -* Write a commit-graph file, extending the current commit-graph file - using commits in `<pack-index>`. -+ ------------------------------------------------- -$ echo <pack-index> | git commit-graph write --stdin-packs ------------------------------------------------- - -* Write a commit-graph file containing all reachable commits. -+ ------------------------------------------------- -$ git show-ref -s | git commit-graph write --stdin-commits ------------------------------------------------- - -* Write a commit-graph file containing all commits in the current - commit-graph file along with those reachable from `HEAD`. -+ ------------------------------------------------- -$ git rev-parse HEAD | git commit-graph write --stdin-commits --append ------------------------------------------------- - -* Read basic information from the commit-graph file. -+ ------------------------------------------------- -$ git commit-graph read ------------------------------------------------- - - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-commit-tree.txt b/third_party/git/Documentation/git-commit-tree.txt deleted file mode 100644 index 4b90b9c12a..0000000000 --- a/third_party/git/Documentation/git-commit-tree.txt +++ /dev/null @@ -1,123 +0,0 @@ -git-commit-tree(1) -================== - -NAME ----- -git-commit-tree - Create a new commit object - - -SYNOPSIS --------- -[verse] -'git commit-tree' <tree> [(-p <parent>)...] -'git commit-tree' [(-p <parent>)...] [-S[<keyid>]] [(-m <message>)...] - [(-F <file>)...] <tree> - - -DESCRIPTION ------------ -This is usually not what an end user wants to run directly. See -linkgit:git-commit[1] instead. - -Creates a new commit object based on the provided tree object and -emits the new commit object id on stdout. The log message is read -from the standard input, unless `-m` or `-F` options are given. - -The `-m` and `-F` options can be given any number of times, in any -order. The commit log message will be composed in the order in which -the options are given. - -A commit object may have any number of parents. With exactly one -parent, it is an ordinary commit. Having more than one parent makes -the commit a merge between several lines of history. Initial (root) -commits have no parents. - -While a tree represents a particular directory state of a working -directory, a commit represents that state in "time", and explains how -to get there. - -Normally a commit would identify a new "HEAD" state, and while Git -doesn't care where you save the note about that state, in practice we -tend to just write the result to the file that is pointed at by -`.git/HEAD`, so that we can always see what the last committed -state was. - -OPTIONS -------- -<tree>:: - An existing tree object. - --p <parent>:: - Each `-p` indicates the id of a parent commit object. - --m <message>:: - A paragraph in the commit log message. This can be given more than - once and each <message> becomes its own paragraph. - --F <file>:: - Read the commit log message from the given file. Use `-` to read - from the standard input. This can be given more than once and the - content of each file becomes its own paragraph. - --S[<keyid>]:: ---gpg-sign[=<keyid>]:: - GPG-sign commits. The `keyid` argument is optional and - defaults to the committer identity; if specified, it must be - stuck to the option without a space. - ---no-gpg-sign:: - Do not GPG-sign commit, to countermand a `--gpg-sign` option - given earlier on the command line. - - -Commit Information ------------------- - -A commit encapsulates: - -- all parent object ids -- author name, email and date -- committer name and email and the commit time. - -While parent object ids are provided on the command line, author and -committer information is taken from the following environment variables, -if set: - - GIT_AUTHOR_NAME - GIT_AUTHOR_EMAIL - GIT_AUTHOR_DATE - GIT_COMMITTER_NAME - GIT_COMMITTER_EMAIL - GIT_COMMITTER_DATE - -(nb "<", ">" and "\n"s are stripped) - -In case (some of) these environment variables are not set, the information -is taken from the configuration items user.name and user.email, or, if not -present, the environment variable EMAIL, or, if that is not set, -system user name and the hostname used for outgoing mail (taken -from `/etc/mailname` and falling back to the fully qualified hostname when -that file does not exist). - -A commit comment is read from stdin. If a changelog -entry is not provided via "<" redirection, 'git commit-tree' will just wait -for one to be entered and terminated with ^D. - -include::date-formats.txt[] - -Discussion ----------- - -include::i18n.txt[] - -FILES ------ -/etc/mailname - -SEE ALSO --------- -linkgit:git-write-tree[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-commit.txt b/third_party/git/Documentation/git-commit.txt deleted file mode 100644 index 7628193284..0000000000 --- a/third_party/git/Documentation/git-commit.txt +++ /dev/null @@ -1,496 +0,0 @@ -git-commit(1) -============= - -NAME ----- -git-commit - Record changes to the repository - -SYNOPSIS --------- -[verse] -'git commit' [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend] - [--dry-run] [(-c | -C | --fixup | --squash) <commit>] - [-F <file> | -m <msg>] [--reset-author] [--allow-empty] - [--allow-empty-message] [--no-verify] [-e] [--author=<author>] - [--date=<date>] [--cleanup=<mode>] [--[no-]status] - [-i | -o] [-S[<keyid>]] [--] [<file>...] - -DESCRIPTION ------------ -Create a new commit containing the current contents of the index and -the given log message describing the changes. The new commit is a -direct child of HEAD, usually the tip of the current branch, and the -branch is updated to point to it (unless no branch is associated with -the working tree, in which case HEAD is "detached" as described in -linkgit:git-checkout[1]). - -The content to be committed can be specified in several ways: - -1. by using linkgit:git-add[1] to incrementally "add" changes to the - index before using the 'commit' command (Note: even modified files - must be "added"); - -2. by using linkgit:git-rm[1] 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 - (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); - -4. by using the -a switch with the 'commit' command to automatically - "add" changes from all known files (i.e. all files that are already - listed in the index) and to automatically "rm" files in the index - that have been removed from the working tree, and then perform the - 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 - 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. - -The `--dry-run` option can be used to obtain a -summary of what is included by any of the above for the next -commit by giving the same set of parameters (options and paths). - -If you make a commit and then find a mistake immediately after -that, you can recover from it with 'git reset'. - - -OPTIONS -------- --a:: ---all:: - Tell the command to automatically stage files that have - been modified and deleted, but new files you have not - told Git about are not affected. - --p:: ---patch:: - Use the interactive patch selection interface to chose - which changes to commit. See linkgit:git-add[1] for - details. - --C <commit>:: ---reuse-message=<commit>:: - Take an existing commit object, and reuse the log message - and the authorship information (including the timestamp) - when creating the commit. - --c <commit>:: ---reedit-message=<commit>:: - Like '-C', but with `-c` the editor is invoked, so that - the user can further edit the commit message. - ---fixup=<commit>:: - Construct a commit message for use with `rebase --autosquash`. - The commit message will be the subject line from the specified - commit with a prefix of "fixup! ". See linkgit:git-rebase[1] - for details. - ---squash=<commit>:: - Construct a commit message for use with `rebase --autosquash`. - The commit message subject line is taken from the specified - commit with a prefix of "squash! ". Can be used with additional - commit message options (`-m`/`-c`/`-C`/`-F`). See - linkgit:git-rebase[1] for details. - ---reset-author:: - When used with -C/-c/--amend options, or when committing after a - conflicting cherry-pick, declare that the authorship of the - resulting commit now belongs to the committer. This also renews - the author timestamp. - ---short:: - When doing a dry-run, give the output in the short-format. See - linkgit:git-status[1] for details. Implies `--dry-run`. - ---branch:: - Show the branch and tracking info even in short-format. - ---porcelain:: - When doing a dry-run, give the output in a porcelain-ready - format. See linkgit:git-status[1] for details. Implies - `--dry-run`. - ---long:: - When doing a dry-run, give the output in the long-format. - Implies `--dry-run`. - --z:: ---null:: - When showing `short` or `porcelain` status output, print the - filename verbatim and terminate the entries with NUL, instead of LF. - If no format is given, implies the `--porcelain` output format. - Without the `-z` option, filenames with "unusual" characters are - quoted as explained for the configuration variable `core.quotePath` - (see linkgit:git-config[1]). - --F <file>:: ---file=<file>:: - Take the commit message from the given file. Use '-' to - read the message from the standard input. - ---author=<author>:: - Override the commit author. Specify an explicit author using the - standard `A U Thor <author@example.com>` format. Otherwise <author> - is assumed to be a pattern and is used to search for an existing - commit by that author (i.e. rev-list --all -i --author=<author>); - the commit author is then copied from the first such commit found. - ---date=<date>:: - Override the author date used in the commit. - --m <msg>:: ---message=<msg>:: - Use the given <msg> as the commit message. - If multiple `-m` options are given, their values are - concatenated as separate paragraphs. -+ -The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`. - --t <file>:: ---template=<file>:: - When editing the commit message, start the editor with the - contents in the given file. The `commit.template` configuration - variable is often used to give this option implicitly to the - command. This mechanism can be used by projects that want to - guide participants with some hints on what to write in the message - in what order. If the user exits the editor without editing the - message, the commit is aborted. This has no effect when a message - is given by other means, e.g. with the `-m` or `-F` options. - --s:: ---signoff:: - Add Signed-off-by line by the committer at the end of the commit - log message. The meaning of a signoff depends on the project, - but it typically certifies that committer has - the rights to submit this work under the same license and - agrees to a Developer Certificate of Origin - (see http://developercertificate.org/ for more information). - --n:: ---no-verify:: - This option bypasses the pre-commit and commit-msg hooks. - See also linkgit:githooks[5]. - ---allow-empty:: - Usually recording a commit that has the exact same tree as its - sole parent commit is a mistake, and the command prevents you - from making such a commit. This option bypasses the safety, and - is primarily for use by foreign SCM interface scripts. - ---allow-empty-message:: - Like --allow-empty this command is primarily for use by foreign - SCM interface scripts. It allows you to create a commit with an - empty commit message without using plumbing commands like - linkgit:git-commit-tree[1]. - ---cleanup=<mode>:: - This option determines how the supplied commit message should be - cleaned up before committing. The '<mode>' can be `strip`, - `whitespace`, `verbatim`, `scissors` or `default`. -+ --- -strip:: - Strip leading and trailing empty lines, trailing whitespace, - commentary and collapse consecutive empty lines. -whitespace:: - Same as `strip` except #commentary is not removed. -verbatim:: - Do not change the message at all. -scissors:: - Same as `whitespace` except that everything from (and including) - the line found below is truncated, if the message is to be edited. - "`#`" can be customized with core.commentChar. - - # ------------------------ >8 ------------------------ - -default:: - Same as `strip` if the message is to be edited. - Otherwise `whitespace`. --- -+ -The default can be changed by the `commit.cleanup` configuration -variable (see linkgit:git-config[1]). - --e:: ---edit:: - The message taken from file with `-F`, command line with - `-m`, and from commit object with `-C` are usually used as - the commit log message unmodified. This option lets you - further edit the message taken from these sources. - ---no-edit:: - Use the selected commit message without launching an editor. - For example, `git commit --amend --no-edit` amends a commit - without changing its commit message. - ---amend:: - Replace the tip of the current branch by creating a new - commit. The recorded tree is prepared as usual (including - the effect of the `-i` and `-o` options and explicit - pathspec), and the message from the original commit is used - as the starting point, instead of an empty message, when no - other message is specified from the command line via options - such as `-m`, `-F`, `-c`, etc. The new commit has the same - parents and author as the current one (the `--reset-author` - option can countermand this). -+ --- -It is a rough equivalent for: ------- - $ git reset --soft HEAD^ - $ ... do something else to come up with the right tree ... - $ git commit -c ORIG_HEAD - ------- -but can be used to amend a merge commit. --- -+ -You should understand the implications of rewriting history if you -amend a commit that has already been published. (See the "RECOVERING -FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].) - ---no-post-rewrite:: - Bypass the post-rewrite hook. - --i:: ---include:: - Before making a commit out of staged contents so far, - stage the contents of paths given on the command line - as well. This is usually not what you want unless you - are concluding a conflicted merge. - --o:: ---only:: - Make a commit by taking the updated working tree contents - of the paths specified on the - command line, disregarding any contents that have been - staged for other paths. This is the default mode of operation of - 'git commit' if any paths are given on the command line, - in which case this option can be omitted. - If this option is specified together with `--amend`, then - no paths need to be specified, which can be used to amend - the last commit without committing changes that have - already been staged. If used together with `--allow-empty` - paths are also not required, and an empty commit will be created. - --u[<mode>]:: ---untracked-files[=<mode>]:: - Show untracked files. -+ -The mode parameter is optional (defaults to 'all'), and is used to -specify the handling of untracked files; when -u is not used, the -default is 'normal', i.e. show untracked files and directories. -+ -The possible options are: -+ - - 'no' - Show no untracked files - - 'normal' - Shows untracked files and directories - - 'all' - Also shows individual files in untracked directories. -+ -The default can be changed using the status.showUntrackedFiles -configuration variable documented in linkgit:git-config[1]. - --v:: ---verbose:: - Show unified diff between the HEAD commit and what - would be committed at the bottom of the commit message - template to help the user describe the commit by reminding - what changes the commit has. - Note that this diff output doesn't have its - lines prefixed with '#'. This diff will not be a part - of the commit message. See the `commit.verbose` configuration - variable in linkgit:git-config[1]. -+ -If specified twice, show in addition the unified diff between -what would be committed and the worktree files, i.e. the unstaged -changes to tracked files. - --q:: ---quiet:: - Suppress commit summary message. - ---dry-run:: - Do not create a commit, but show a list of paths that are - to be committed, paths with local changes that will be left - uncommitted and paths that are untracked. - ---status:: - Include the output of linkgit:git-status[1] in the commit - message template when using an editor to prepare the commit - message. Defaults to on, but can be used to override - configuration variable commit.status. - ---no-status:: - Do not include the output of linkgit:git-status[1] in the - commit message template when using an editor to prepare the - default commit message. - --S[<keyid>]:: ---gpg-sign[=<keyid>]:: - GPG-sign commits. The `keyid` argument is optional and - defaults to the committer identity; if specified, it must be - stuck to the option without a space. - ---no-gpg-sign:: - Countermand `commit.gpgSign` configuration variable that is - set to force each and every commit to be signed. - -\--:: - Do not interpret any more arguments as options. - -<file>...:: - When files are given on the command line, the command - commits the contents of the named files, without - recording the changes already staged. The contents of - these files are also staged for the next commit on top - of what have been staged before. - -:git-commit: 1 -include::date-formats.txt[] - -EXAMPLES --------- -When recording your own work, the contents of modified files in -your working tree are temporarily stored to a staging area -called the "index" with 'git add'. A file can be -reverted back, only in the index but not in the working tree, -to that of the last commit with `git restore --staged <file>`, -which effectively reverts 'git add' and prevents the changes to -this file from participating in the next commit. After building -the state to be committed incrementally with these commands, -`git commit` (without any pathname parameter) is used to record what -has been staged so far. This is the most basic form of the -command. An example: - ------------- -$ edit hello.c -$ git rm goodbye.c -$ git add hello.c -$ git commit ------------- - -Instead of staging files after each individual change, you can -tell `git commit` to notice the changes to the files whose -contents are tracked in -your working tree and do corresponding `git add` and `git rm` -for you. That is, this example does the same as the earlier -example if there is no other change in your working tree: - ------------- -$ edit hello.c -$ rm goodbye.c -$ git commit -a ------------- - -The command `git commit -a` first looks at your working tree, -notices that you have modified hello.c and removed goodbye.c, -and performs necessary `git add` and `git rm` for you. - -After staging changes to many files, you can alter the order the -changes are recorded in, by giving pathnames to `git commit`. -When pathnames are given, the command makes a commit that -only records the changes made to the named paths: - ------------- -$ edit hello.c hello.h -$ git add hello.c hello.h -$ edit Makefile -$ git commit Makefile ------------- - -This makes a commit that records the modification to `Makefile`. -The changes staged for `hello.c` and `hello.h` are not included -in the resulting commit. However, their changes are not lost -- -they are still staged and merely held back. After the above -sequence, if you do: - ------------- -$ git commit ------------- - -this second commit would record the changes to `hello.c` and -`hello.h` as expected. - -After a merge (initiated by 'git merge' or 'git pull') stops -because of conflicts, cleanly merged -paths are already staged to be committed for you, and paths that -conflicted are left in unmerged state. You would have to first -check which paths are conflicting with 'git status' -and after fixing them manually in your working tree, you would -stage the result as usual with 'git add': - ------------- -$ git status | grep unmerged -unmerged: hello.c -$ edit hello.c -$ git add hello.c ------------- - -After resolving conflicts and staging the result, `git ls-files -u` -would stop mentioning the conflicted path. When you are done, -run `git commit` to finally record the merge: - ------------- -$ git commit ------------- - -As with the case to record your own changes, you can use `-a` -option to save typing. One difference is that during a merge -resolution, you cannot use `git commit` with pathnames to -alter the order the changes are committed, because the merge -should be recorded as a single commit. In fact, the command -refuses to run when given pathnames (but see `-i` option). - - -DISCUSSION ----------- - -Though not required, it's a good idea to begin the commit message -with a single short (less than 50 character) line summarizing the -change, followed by a blank line and then a more thorough description. -The text up to the first blank line in a commit message is treated -as the commit title, and that title is used throughout Git. -For example, linkgit:git-format-patch[1] turns a commit into email, and it uses -the title on the Subject line and the rest of the commit in the body. - -include::i18n.txt[] - -ENVIRONMENT AND CONFIGURATION VARIABLES ---------------------------------------- -The editor used to edit the commit log message will be chosen from the -`GIT_EDITOR` environment variable, the core.editor configuration variable, the -`VISUAL` environment variable, or the `EDITOR` environment variable (in that -order). See linkgit:git-var[1] for details. - -HOOKS ------ -This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`, -`post-commit` and `post-rewrite` hooks. See linkgit:githooks[5] for more -information. - -FILES ------ - -`$GIT_DIR/COMMIT_EDITMSG`:: - This file contains the commit message of a commit in progress. - If `git commit` exits due to an error before creating a commit, - any commit message that has been provided by the user (e.g., in - an editor session) will be available in this file, but will be - overwritten by the next invocation of `git commit`. - -SEE ALSO --------- -linkgit:git-add[1], -linkgit:git-rm[1], -linkgit:git-mv[1], -linkgit:git-merge[1], -linkgit:git-commit-tree[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-config.txt b/third_party/git/Documentation/git-config.txt deleted file mode 100644 index ff9310f958..0000000000 --- a/third_party/git/Documentation/git-config.txt +++ /dev/null @@ -1,493 +0,0 @@ -git-config(1) -============= - -NAME ----- -git-config - Get and set repository or global options - - -SYNOPSIS --------- -[verse] -'git config' [<file-option>] [--type=<type>] [--show-origin] [-z|--null] name [value [value_regex]] -'git config' [<file-option>] [--type=<type>] --add name value -'git config' [<file-option>] [--type=<type>] --replace-all name value [value_regex] -'git config' [<file-option>] [--type=<type>] [--show-origin] [-z|--null] --get name [value_regex] -'git config' [<file-option>] [--type=<type>] [--show-origin] [-z|--null] --get-all name [value_regex] -'git config' [<file-option>] [--type=<type>] [--show-origin] [-z|--null] [--name-only] --get-regexp name_regex [value_regex] -'git config' [<file-option>] [--type=<type>] [-z|--null] --get-urlmatch name URL -'git config' [<file-option>] --unset name [value_regex] -'git config' [<file-option>] --unset-all name [value_regex] -'git config' [<file-option>] --rename-section old_name new_name -'git config' [<file-option>] --remove-section name -'git config' [<file-option>] [--show-origin] [-z|--null] [--name-only] -l | --list -'git config' [<file-option>] --get-color name [default] -'git config' [<file-option>] --get-colorbool name [stdout-is-tty] -'git config' [<file-option>] -e | --edit - -DESCRIPTION ------------ -You can query/set/replace/unset options with this command. The name is -actually the section and the key separated by a dot, and the value will be -escaped. - -Multiple lines can be added to an option by using the `--add` option. -If you want to update or unset an option which can occur on multiple -lines, a POSIX regexp `value_regex` needs to be given. Only the -existing values that match the regexp are updated or unset. If -you want to handle the lines that do *not* match the regex, just -prepend a single exclamation mark in front (see also <<EXAMPLES>>). - -The `--type=<type>` option instructs 'git config' to ensure that incoming and -outgoing values are canonicalize-able under the given <type>. If no -`--type=<type>` is given, no canonicalization will be performed. Callers may -unset an existing `--type` specifier with `--no-type`. - -When reading, the values are read from the system, global and -repository local configuration files by default, and options -`--system`, `--global`, `--local`, `--worktree` and -`--file <filename>` can be used to tell the command to read from only -that location (see <<FILES>>). - -When writing, the new value is written to the repository local -configuration file by default, and options `--system`, `--global`, -`--worktree`, `--file <filename>` can be used to tell the command to -write to that location (you can say `--local` but that is the -default). - -This command will fail with non-zero status upon error. Some exit -codes are: - -- The section or key is invalid (ret=1), -- no section or name was provided (ret=2), -- the config file is invalid (ret=3), -- the config file cannot be written (ret=4), -- you try to unset an option which does not exist (ret=5), -- you try to unset/set an option for which multiple lines match (ret=5), or -- you try to use an invalid regexp (ret=6). - -On success, the command returns the exit code 0. - -OPTIONS -------- - ---replace-all:: - Default behavior is to replace at most one line. This replaces - all lines matching the key (and optionally the value_regex). - ---add:: - Adds a new line to the option without altering any existing - values. This is the same as providing '^$' as the value_regex - in `--replace-all`. - ---get:: - Get the value for a given key (optionally filtered by a regex - matching the value). Returns error code 1 if the key was not - found and the last value if multiple key values were found. - ---get-all:: - Like get, but returns all values for a multi-valued key. - ---get-regexp:: - Like --get-all, but interprets the name as a regular expression and - writes out the key names. Regular expression matching is currently - case-sensitive and done against a canonicalized version of the key - in which section and variable names are lowercased, but subsection - names are not. - ---get-urlmatch name URL:: - When given a two-part name section.key, the value for - section.<url>.key whose <url> part matches the best to the - given URL is returned (if no such key exists, the value for - section.key is used as a fallback). When given just the - section as name, do so for all the keys in the section and - list them. Returns error code 1 if no value is found. - ---global:: - For writing options: write to global `~/.gitconfig` file - rather than the repository `.git/config`, write to - `$XDG_CONFIG_HOME/git/config` file if this file exists and the - `~/.gitconfig` file doesn't. -+ -For reading options: read only from global `~/.gitconfig` and from -`$XDG_CONFIG_HOME/git/config` rather than from all available files. -+ -See also <<FILES>>. - ---system:: - For writing options: write to system-wide - `$(prefix)/etc/gitconfig` rather than the repository - `.git/config`. -+ -For reading options: read only from system-wide `$(prefix)/etc/gitconfig` -rather than from all available files. -+ -See also <<FILES>>. - ---local:: - For writing options: write to the repository `.git/config` file. - This is the default behavior. -+ -For reading options: read only from the repository `.git/config` rather than -from all available files. -+ -See also <<FILES>>. - ---worktree:: - Similar to `--local` except that `.git/config.worktree` is - read from or written to if `extensions.worktreeConfig` is - present. If not it's the same as `--local`. - --f config-file:: ---file config-file:: - Use the given config file instead of the one specified by GIT_CONFIG. - ---blob blob:: - Similar to `--file` but use the given blob instead of a file. E.g. - you can use 'master:.gitmodules' to read values from the file - '.gitmodules' in the master branch. See "SPECIFYING REVISIONS" - section in linkgit:gitrevisions[7] for a more complete list of - ways to spell blob names. - ---remove-section:: - Remove the given section from the configuration file. - ---rename-section:: - Rename the given section to a new name. - ---unset:: - Remove the line matching the key from config file. - ---unset-all:: - Remove all lines matching the key from config file. - --l:: ---list:: - List all variables set in config file, along with their values. - ---type <type>:: - 'git config' will ensure that any input or output is valid under the given - type constraint(s), and will canonicalize outgoing values in `<type>`'s - canonical form. -+ -Valid `<type>`'s include: -+ -- 'bool': canonicalize values as either "true" or "false". -- 'int': canonicalize values as simple decimal numbers. An optional suffix of - 'k', 'm', or 'g' will cause the value to be multiplied by 1024, 1048576, or - 1073741824 upon input. -- 'bool-or-int': canonicalize according to either 'bool' or 'int', as described - above. -- 'path': canonicalize by adding a leading `~` to the value of `$HOME` and - `~user` to the home directory for the specified user. This specifier has no - effect when setting the value (but you can use `git config section.variable - ~/` from the command line to let your shell do the expansion.) -- 'expiry-date': canonicalize by converting from a fixed or relative date-string - to a timestamp. This specifier has no effect when setting the value. -- 'color': When getting a value, canonicalize by converting to an ANSI color - escape sequence. When setting a value, a sanity-check is performed to ensure - that the given value is canonicalize-able as an ANSI color, but it is written - as-is. -+ - ---bool:: ---int:: ---bool-or-int:: ---path:: ---expiry-date:: - Historical options for selecting a type specifier. Prefer instead `--type` - (see above). - ---no-type:: - Un-sets the previously set type specifier (if one was previously set). This - option requests that 'git config' not canonicalize the retrieved variable. - `--no-type` has no effect without `--type=<type>` or `--<type>`. - --z:: ---null:: - For all options that output values and/or keys, always - end values with the null character (instead of a - newline). Use newline instead as a delimiter between - key and value. This allows for secure parsing of the - output without getting confused e.g. by values that - contain line breaks. - ---name-only:: - Output only the names of config variables for `--list` or - `--get-regexp`. - ---show-origin:: - Augment the output of all queried config options with the - origin type (file, standard input, blob, command line) and - the actual origin (config file path, ref, or blob id if - applicable). - ---get-colorbool name [stdout-is-tty]:: - - Find the color setting for `name` (e.g. `color.diff`) and output - "true" or "false". `stdout-is-tty` should be either "true" or - "false", and is taken into account when configuration says - "auto". If `stdout-is-tty` is missing, then checks the standard - output of the command itself, and exits with status 0 if color - is to be used, or exits with status 1 otherwise. - When the color setting for `name` is undefined, the command uses - `color.ui` as fallback. - ---get-color name [default]:: - - Find the color configured for `name` (e.g. `color.diff.new`) and - output it as the ANSI color escape sequence to the standard - output. The optional `default` parameter is used instead, if - there is no color configured for `name`. -+ -`--type=color [--default=<default>]` is preferred over `--get-color` -(but note that `--get-color` will omit the trailing newline printed by -`--type=color`). - --e:: ---edit:: - Opens an editor to modify the specified config file; either - `--system`, `--global`, or repository (default). - ---[no-]includes:: - Respect `include.*` directives in config files when looking up - values. Defaults to `off` when a specific file is given (e.g., - using `--file`, `--global`, etc) and `on` when searching all - config files. - ---default <value>:: - When using `--get`, and the requested variable is not found, behave as if - <value> were the value assigned to the that variable. - -CONFIGURATION -------------- -`pager.config` is only respected when listing configuration, i.e., when -using `--list` or any of the `--get-*` which may return multiple results. -The default is to use a pager. - -[[FILES]] -FILES ------ - -If not set explicitly with `--file`, there are four files where -'git config' will search for configuration options: - -$(prefix)/etc/gitconfig:: - System-wide configuration file. - -$XDG_CONFIG_HOME/git/config:: - Second user-specific configuration file. If $XDG_CONFIG_HOME is not set - or empty, `$HOME/.config/git/config` will be used. Any single-valued - variable set in this file will be overwritten by whatever is in - `~/.gitconfig`. It is a good idea not to create this file if - you sometimes use older versions of Git, as support for this - file was added fairly recently. - -~/.gitconfig:: - User-specific configuration file. Also called "global" - configuration file. - -$GIT_DIR/config:: - Repository specific configuration file. - -$GIT_DIR/config.worktree:: - This is optional and is only searched when - `extensions.worktreeConfig` is present in $GIT_DIR/config. - -If no further options are given, all reading options will read all of these -files that are available. If the global or the system-wide configuration -file are not available they will be ignored. If the repository configuration -file is not available or readable, 'git config' will exit with a non-zero -error code. However, in neither case will an error message be issued. - -The files are read in the order given above, with last value found taking -precedence over values read earlier. When multiple values are taken then all -values of a key from all files will be used. - -You may override individual configuration parameters when running any git -command by using the `-c` option. See linkgit:git[1] for details. - -All writing options will per default write to the repository specific -configuration file. Note that this also affects options like `--replace-all` -and `--unset`. *'git config' will only ever change one file at a time*. - -You can override these rules either by command-line options or by environment -variables. The `--global`, `--system` and `--worktree` options will limit -the file used to the global, system-wide or per-worktree file respectively. -The `GIT_CONFIG` environment variable has a similar effect, but you -can specify any filename you want. - - -ENVIRONMENT ------------ - -GIT_CONFIG:: - Take the configuration from the given file instead of .git/config. - Using the "--global" option forces this to ~/.gitconfig. Using the - "--system" option forces this to $(prefix)/etc/gitconfig. - -GIT_CONFIG_NOSYSTEM:: - Whether to skip reading settings from the system-wide - $(prefix)/etc/gitconfig file. See linkgit:git[1] for details. - -See also <<FILES>>. - - -[[EXAMPLES]] -EXAMPLES --------- - -Given a .git/config like this: - - # - # This is the config file, and - # a '#' or ';' character indicates - # a comment - # - - ; core variables - [core] - ; Don't trust file modes - filemode = false - - ; Our diff algorithm - [diff] - external = /usr/local/bin/diff-wrapper - renames = true - - ; Proxy settings - [core] - gitproxy=proxy-command for kernel.org - gitproxy=default-proxy ; for all the rest - - ; HTTP - [http] - sslVerify - [http "https://weak.example.com"] - sslVerify = false - cookieFile = /tmp/cookie.txt - -you can set the filemode to true with - ------------- -% git config core.filemode true ------------- - -The hypothetical proxy command entries actually have a postfix to discern -what URL they apply to. Here is how to change the entry for kernel.org -to "ssh". - ------------- -% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$' ------------- - -This makes sure that only the key/value pair for kernel.org is replaced. - -To delete the entry for renames, do - ------------- -% git config --unset diff.renames ------------- - -If you want to delete an entry for a multivar (like core.gitproxy above), -you have to provide a regex matching the value of exactly one line. - -To query the value for a given key, do - ------------- -% git config --get core.filemode ------------- - -or - ------------- -% git config core.filemode ------------- - -or, to query a multivar: - ------------- -% git config --get core.gitproxy "for kernel.org$" ------------- - -If you want to know all the values for a multivar, do: - ------------- -% git config --get-all core.gitproxy ------------- - -If you like to live dangerously, you can replace *all* core.gitproxy by a -new one with - ------------- -% git config --replace-all core.gitproxy ssh ------------- - -However, if you really only want to replace the line for the default proxy, -i.e. the one without a "for ..." postfix, do something like this: - ------------- -% git config core.gitproxy ssh '! for ' ------------- - -To actually match only values with an exclamation mark, you have to - ------------- -% git config section.key value '[!]' ------------- - -To add a new proxy, without altering any of the existing ones, use - ------------- -% git config --add core.gitproxy '"proxy-command" for example.com' ------------- - -An example to use customized color from the configuration in your -script: - ------------- -#!/bin/sh -WS=$(git config --get-color color.diff.whitespace "blue reverse") -RESET=$(git config --get-color "" "reset") -echo "${WS}your whitespace color or blue reverse${RESET}" ------------- - -For URLs in `https://weak.example.com`, `http.sslVerify` is set to -false, while it is set to `true` for all others: - ------------- -% git config --type=bool --get-urlmatch http.sslverify https://good.example.com -true -% git config --type=bool --get-urlmatch http.sslverify https://weak.example.com -false -% git config --get-urlmatch http https://weak.example.com -http.cookieFile /tmp/cookie.txt -http.sslverify false ------------- - -include::config.txt[] - -BUGS ----- -When using the deprecated `[section.subsection]` syntax, changing a value -will result in adding a multi-line key instead of a change, if the subsection -is given with at least one uppercase character. For example when the config -looks like - --------- - [section.subsection] - key = value1 --------- - -and running `git config section.Subsection.key value2` will result in - --------- - [section.subsection] - key = value1 - key = value2 --------- - - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-count-objects.txt b/third_party/git/Documentation/git-count-objects.txt deleted file mode 100644 index cb9b4d2e46..0000000000 --- a/third_party/git/Documentation/git-count-objects.txt +++ /dev/null @@ -1,54 +0,0 @@ -git-count-objects(1) -==================== - -NAME ----- -git-count-objects - Count unpacked number of objects and their disk consumption - -SYNOPSIS --------- -[verse] -'git count-objects' [-v] [-H | --human-readable] - -DESCRIPTION ------------ -This counts the number of unpacked object files and disk space consumed by -them, to help you decide when it is a good time to repack. - - -OPTIONS -------- --v:: ---verbose:: - Report in more detail: -+ -count: the number of loose objects -+ -size: disk space consumed by loose objects, in KiB (unless -H is specified) -+ -in-pack: the number of in-pack objects -+ -size-pack: disk space consumed by the packs, in KiB (unless -H is specified) -+ -prune-packable: the number of loose objects that are also present in -the packs. These objects could be pruned using `git prune-packed`. -+ -garbage: the number of files in object database that are neither valid loose -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:: - -Print sizes in human readable format - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-credential-cache--daemon.txt b/third_party/git/Documentation/git-credential-cache--daemon.txt deleted file mode 100644 index 7051c6bdf8..0000000000 --- a/third_party/git/Documentation/git-credential-cache--daemon.txt +++ /dev/null @@ -1,30 +0,0 @@ -git-credential-cache--daemon(1) -=============================== - -NAME ----- -git-credential-cache--daemon - Temporarily store user credentials in memory - -SYNOPSIS --------- -[verse] -git credential-cache--daemon [--debug] <socket> - -DESCRIPTION ------------ - -NOTE: You probably don't want to invoke this command yourself; it is -started automatically when you use linkgit:git-credential-cache[1]. - -This command listens on the Unix domain socket specified by `<socket>` -for `git-credential-cache` clients. Clients may store and retrieve -credentials. Each credential is held for a timeout specified by the -client; once no credentials are held, the daemon exits. - -If the `--debug` option is specified, the daemon does not close its -stderr stream, and may output extra diagnostics to it even after it has -begun listening for clients. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-credential-cache.txt b/third_party/git/Documentation/git-credential-cache.txt deleted file mode 100644 index 0216c18ef8..0000000000 --- a/third_party/git/Documentation/git-credential-cache.txt +++ /dev/null @@ -1,80 +0,0 @@ -git-credential-cache(1) -======================= - -NAME ----- -git-credential-cache - Helper to temporarily store passwords in memory - -SYNOPSIS --------- ------------------------------ -git config credential.helper 'cache [<options>]' ------------------------------ - -DESCRIPTION ------------ - -This command caches credentials in memory for use by future Git -programs. The stored credentials never touch the disk, and are forgotten -after a configurable timeout. The cache is accessible over a Unix -domain socket, restricted to the current user by filesystem permissions. - -You probably don't want to invoke this command directly; it is meant to -be used as a credential helper by other parts of Git. See -linkgit:gitcredentials[7] or `EXAMPLES` below. - -OPTIONS -------- - ---timeout <seconds>:: - - Number of seconds to cache credentials (default: 900). - ---socket <path>:: - - Use `<path>` to contact a running cache daemon (or start a new - cache daemon if one is not started). - Defaults to `$XDG_CACHE_HOME/git/credential/socket` unless - `~/.git-credential-cache/` exists in which case - `~/.git-credential-cache/socket` is used instead. - If your home directory is on a network-mounted filesystem, you - may need to change this to a local filesystem. You must specify - an absolute path. - -CONTROLLING THE DAEMON ----------------------- - -If you would like the daemon to exit early, forgetting all cached -credentials before their timeout, you can issue an `exit` action: - --------------------------------------- -git credential-cache exit --------------------------------------- - -EXAMPLES --------- - -The point of this helper is to reduce the number of times you must type -your username or password. For example: - ------------------------------------- -$ git config credential.helper cache -$ git push http://example.com/repo.git -Username: <type your username> -Password: <type your password> - -[work for 5 more minutes] -$ git push http://example.com/repo.git -[your credentials are used automatically] ------------------------------------- - -You can provide options via the credential.helper configuration -variable (this example drops the cache time to 5 minutes): - -------------------------------------------------------- -$ git config credential.helper 'cache --timeout=300' -------------------------------------------------------- - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-credential-store.txt b/third_party/git/Documentation/git-credential-store.txt deleted file mode 100644 index 693dd9d9d7..0000000000 --- a/third_party/git/Documentation/git-credential-store.txt +++ /dev/null @@ -1,106 +0,0 @@ -git-credential-store(1) -======================= - -NAME ----- -git-credential-store - Helper to store credentials on disk - -SYNOPSIS --------- -------------------- -git config credential.helper 'store [<options>]' -------------------- - -DESCRIPTION ------------ - -NOTE: Using this helper will store your passwords unencrypted on disk, -protected only by filesystem permissions. If this is not an acceptable -security tradeoff, try linkgit:git-credential-cache[1], or find a helper -that integrates with secure storage provided by your operating system. - -This command stores credentials indefinitely on disk for use by future -Git programs. - -You probably don't want to invoke this command directly; it is meant to -be used as a credential helper by other parts of git. See -linkgit:gitcredentials[7] or `EXAMPLES` below. - -OPTIONS -------- - ---file=<path>:: - - Use `<path>` to lookup and store credentials. The file will have its - filesystem permissions set to prevent other users on the system - from reading it, but will not be encrypted or otherwise - protected. If not specified, credentials will be searched for from - `~/.git-credentials` and `$XDG_CONFIG_HOME/git/credentials`, and - credentials will be written to `~/.git-credentials` if it exists, or - `$XDG_CONFIG_HOME/git/credentials` if it exists and the former does - not. See also <<FILES>>. - -[[FILES]] -FILES ------ - -If not set explicitly with `--file`, there are two files where -git-credential-store will search for credentials in order of precedence: - -~/.git-credentials:: - User-specific credentials file. - -$XDG_CONFIG_HOME/git/credentials:: - Second user-specific credentials file. If '$XDG_CONFIG_HOME' is not set - or empty, `$HOME/.config/git/credentials` will be used. Any credentials - stored in this file will not be used if `~/.git-credentials` has a - matching credential as well. It is a good idea not to create this file - if you sometimes use older versions of Git that do not support it. - -For credential lookups, the files are read in the order given above, with the -first matching credential found taking precedence over credentials found in -files further down the list. - -Credential storage will by default write to the first existing file in the -list. If none of these files exist, `~/.git-credentials` will be created and -written to. - -When erasing credentials, matching credentials will be erased from all files. - -EXAMPLES --------- - -The point of this helper is to reduce the number of times you must type -your username or password. For example: - ------------------------------------------- -$ git config credential.helper store -$ git push http://example.com/repo.git -Username: <type your username> -Password: <type your password> - -[several days later] -$ git push http://example.com/repo.git -[your credentials are used automatically] ------------------------------------------- - -STORAGE FORMAT --------------- - -The `.git-credentials` file is stored in plaintext. Each credential is -stored on its own line as a URL like: - ------------------------------- -https://user:pass@example.com ------------------------------- - -When Git needs authentication for a particular URL context, -credential-store will consider that context a pattern to match against -each entry in the credentials file. If the protocol, hostname, and -username (if we already have one) match, then the password is returned -to Git. See the discussion of configuration in linkgit:gitcredentials[7] -for more information. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-credential.txt b/third_party/git/Documentation/git-credential.txt deleted file mode 100644 index b211440373..0000000000 --- a/third_party/git/Documentation/git-credential.txt +++ /dev/null @@ -1,154 +0,0 @@ -git-credential(1) -================= - -NAME ----- -git-credential - Retrieve and store user credentials - -SYNOPSIS --------- ------------------- -git credential <fill|approve|reject> ------------------- - -DESCRIPTION ------------ - -Git has an internal interface for storing and retrieving credentials -from system-specific helpers, as well as prompting the user for -usernames and passwords. The git-credential command exposes this -interface to scripts which may want to retrieve, store, or prompt for -credentials in the same manner as Git. The design of this scriptable -interface models the internal C API; see -link:technical/api-credentials.html[the Git credential API] for more -background on the concepts. - -git-credential takes an "action" option on the command-line (one of -`fill`, `approve`, or `reject`) and reads a credential description -on stdin (see <<IOFMT,INPUT/OUTPUT FORMAT>>). - -If the action is `fill`, git-credential will attempt to add "username" -and "password" attributes to the description by reading config files, -by contacting any configured credential helpers, or by prompting the -user. The username and password attributes of the credential -description are then printed to stdout together with the attributes -already provided. - -If the action is `approve`, git-credential will send the description -to any configured credential helpers, which may store the credential -for later use. - -If the action is `reject`, git-credential will send the description to -any configured credential helpers, which may erase any stored -credential matching the description. - -If the action is `approve` or `reject`, no output should be emitted. - -TYPICAL USE OF GIT CREDENTIAL ------------------------------ - -An application using git-credential will typically use `git -credential` following these steps: - - 1. Generate a credential description based on the context. -+ -For example, if we want a password for -`https://example.com/foo.git`, we might generate the following -credential description (don't forget the blank line at the end; it -tells `git credential` that the application finished feeding all the -information it has): - - protocol=https - host=example.com - path=foo.git - - 2. Ask git-credential to give us a username and password for this - description. This is done by running `git credential fill`, - feeding the description from step (1) to its standard input. The complete - credential description (including the credential per se, i.e. the - login and password) will be produced on standard output, like: - - protocol=https - host=example.com - username=bob - password=secr3t -+ -In most cases, this means the attributes given in the input will be -repeated in the output, but Git may also modify the credential -description, for example by removing the `path` attribute when the -protocol is HTTP(s) and `credential.useHttpPath` is false. -+ -If the `git credential` knew about the password, this step may -not have involved the user actually typing this password (the -user may have typed a password to unlock the keychain instead, -or no user interaction was done if the keychain was already -unlocked) before it returned `password=secr3t`. - - 3. Use the credential (e.g., access the URL with the username and - password from step (2)), and see if it's accepted. - - 4. Report on the success or failure of the password. If the - credential allowed the operation to complete successfully, then - it can be marked with an "approve" action to tell `git - credential` to reuse it in its next invocation. If the credential - was rejected during the operation, use the "reject" action so - that `git credential` will ask for a new password in its next - invocation. In either case, `git credential` should be fed with - the credential description obtained from step (2) (which also - contain the ones provided in step (1)). - -[[IOFMT]] -INPUT/OUTPUT FORMAT -------------------- - -`git credential` reads and/or writes (depending on the action used) -credential information in its standard input/output. This information -can correspond either to keys for which `git credential` will obtain -the login/password information (e.g. host, protocol, path), or to the -actual credential data to be obtained (login/password). - -The credential is split into a set of named attributes, with one -attribute per line. Each attribute is -specified by a key-value pair, separated by an `=` (equals) sign, -followed by a newline. The key may contain any bytes except `=`, -newline, or NUL. The value may contain any bytes except newline or NUL. -In both cases, all bytes are treated as-is (i.e., there is no quoting, -and one cannot transmit a value with newline or NUL in it). The list of -attributes is terminated by a blank line or end-of-file. -Git understands the following attributes: - -`protocol`:: - - The protocol over which the credential will be used (e.g., - `https`). - -`host`:: - - The remote hostname for a network credential. - -`path`:: - - The path with which the credential will be used. E.g., for - accessing a remote https repository, this will be the - repository's path on the server. - -`username`:: - - The credential's username, if we already have one (e.g., from a - URL, from the user, or from a previously run helper). - -`password`:: - - The credential's password, if we are asking it to be stored. - -`url`:: - - When this special attribute is read by `git credential`, the - value is parsed as a URL and treated as if its constituent parts - were read (e.g., `url=https://example.com` would behave as if - `protocol=https` and `host=example.com` had been provided). This - can help callers avoid parsing URLs themselves. Note that any - components which are missing from the URL (e.g., there is no - username in the example above) will be set to empty; if you want - to provide a URL and override some attributes, provide the URL - attribute first, followed by any overrides. diff --git a/third_party/git/Documentation/git-cvsexportcommit.txt b/third_party/git/Documentation/git-cvsexportcommit.txt deleted file mode 100644 index 00154b6c85..0000000000 --- a/third_party/git/Documentation/git-cvsexportcommit.txt +++ /dev/null @@ -1,118 +0,0 @@ -git-cvsexportcommit(1) -====================== - -NAME ----- -git-cvsexportcommit - Export a single commit to a CVS checkout - - -SYNOPSIS --------- -[verse] -'git cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] - [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID - - -DESCRIPTION ------------ -Exports a commit from Git to a CVS checkout, making it easier -to merge patches from a Git repository into a CVS repository. - -Specify the name of a CVS checkout using the -w switch or execute it -from the root of the CVS working copy. In the latter case GIT_DIR must -be defined. See examples below. - -It does its best to do the safe thing, it will check that the files are -unchanged and up to date in the CVS checkout, and it will not autocommit -by default. - -Supports file additions, removals, and commits that affect binary files. - -If the commit is a merge commit, you must tell 'git cvsexportcommit' what -parent the changeset should be done against. - -OPTIONS -------- - --c:: - Commit automatically if the patch applied cleanly. It will not - commit if any hunks fail to apply or there were other problems. - --p:: - Be pedantic (paranoid) when applying patches. Invokes patch with - --fuzz=0 - --a:: - Add authorship information. Adds Author line, and Committer (if - different from Author) to the message. - --d:: - Set an alternative CVSROOT to use. This corresponds to the CVS - -d parameter. Usually users will not want to set this, except - if using CVS in an asymmetric fashion. - --f:: - Force the merge even if the files are not up to date. - --P:: - Force the parent commit, even if it is not a direct parent. - --m:: - Prepend the commit message with the provided prefix. - Useful for patch series and the like. - --u:: - Update affected files from CVS repository before attempting export. - --k:: - Reverse CVS keyword expansion (e.g. $Revision: 1.2.3.4$ - becomes $Revision$) in working CVS checkout before applying patch. - --w:: - Specify the location of the CVS checkout to use for the export. This - option does not require GIT_DIR to be set before execution if the - current directory is within a Git repository. The default is the - value of 'cvsexportcommit.cvsdir'. - --W:: - Tell cvsexportcommit that the current working directory is not only - a Git checkout, but also the CVS checkout. Therefore, Git will - reset the working directory to the parent commit before proceeding. - --v:: - Verbose. - -CONFIGURATION -------------- -cvsexportcommit.cvsdir:: - The default location of the CVS checkout to use for the export. - -EXAMPLES --------- - -Merge one patch into CVS:: -+ ------------- -$ export GIT_DIR=~/project/.git -$ cd ~/project_cvs_checkout -$ git cvsexportcommit -v <commit-sha1> -$ cvs commit -F .msg <files> ------------- - -Merge one patch into CVS (-c and -w options). The working directory is within the Git Repo:: -+ ------------- - $ git cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1> ------------- - -Merge pending patches into CVS automatically -- only if you really know what you are doing:: -+ ------------- -$ export GIT_DIR=~/project/.git -$ cd ~/project_cvs_checkout -$ git cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git cvsexportcommit -c -p -v ------------- - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-cvsimport.txt b/third_party/git/Documentation/git-cvsimport.txt deleted file mode 100644 index de1ebed67d..0000000000 --- a/third_party/git/Documentation/git-cvsimport.txt +++ /dev/null @@ -1,228 +0,0 @@ -git-cvsimport(1) -================ - -NAME ----- -git-cvsimport - Salvage your data out of another SCM people love to hate - - -SYNOPSIS --------- -[verse] -'git cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>] - [-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>] - [-C <git_repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>] - [-a] [-m] [-M <regex>] [-S <regex>] [-L <commitlimit>] - [-r <remote>] [-R] [<CVS_module>] - - -DESCRIPTION ------------ -*WARNING:* `git cvsimport` uses cvsps version 2, which is considered -deprecated; it does not work with cvsps version 3 and later. If you are -performing a one-shot import of a CVS repository consider using -http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or -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. - -Splitting the CVS log into patch sets is done by 'cvsps'. -At least version 2.1 is required. - -*WARNING:* for certain situations the import leads to incorrect results. -Please see the section <<issues,ISSUES>> for further reference. - -You should *never* do any work of your own on the branches that are -created by 'git cvsimport'. By default initial import will create and populate a -"master" branch from the CVS repository's main branch which you're free -to work with; after that, you need to 'git merge' incremental imports, or -any CVS branches, yourself. It is advisable to specify a named remote via --r to separate and protect the incoming branches. - -If you intend to set up a shared public repository that all developers can -read/write, or if you want to use linkgit:git-cvsserver[1], then you -probably want to make a bare clone of the imported repository, -and use the clone as the shared repository. -See linkgit:gitcvs-migration[7]. - - -OPTIONS -------- --v:: - Verbosity: let 'cvsimport' report what it is doing. - --d <CVSROOT>:: - The root of the CVS archive. May be local (a simple path) or remote; - currently, only the :local:, :ext: and :pserver: access methods - are supported. If not given, 'git cvsimport' will try to read it - from `CVS/Root`. If no such file exists, it checks for the - `CVSROOT` environment variable. - -<CVS_module>:: - The CVS module you want to import. Relative to <CVSROOT>. - If not given, 'git cvsimport' tries to read it from - `CVS/Repository`. - --C <target-dir>:: - The Git repository to import to. If the directory doesn't - exist, it will be created. Default is the current directory. - --r <remote>:: - The Git remote to import this CVS repository into. - Moves all CVS branches into remotes/<remote>/<branch> - akin to the way 'git clone' uses 'origin' by default. - --o <branch-for-HEAD>:: - When no remote is specified (via -r) the `HEAD` branch - from CVS is imported to the 'origin' branch within the Git - repository, as `HEAD` already has a special meaning for Git. - When a remote is specified the `HEAD` branch is named - remotes/<remote>/master mirroring 'git clone' behaviour. - Use this option if you want to import into a different - branch. -+ -Use '-o master' for continuing an import that was initially done by -the old cvs2git tool. - --i:: - Import-only: don't perform a checkout after importing. This option - ensures the working directory and index remain untouched and will - not create them if they do not exist. - --k:: - Kill keywords: will extract files with '-kk' from the CVS archive - to avoid noisy changesets. Highly recommended, but off by default - to preserve compatibility with early imported trees. - --u:: - Convert underscores in tag and branch names to dots. - --s <subst>:: - Substitute the character "/" in branch names with <subst> - --p <options-for-cvsps>:: - Additional options for cvsps. - The options `-u` and '-A' are implicit and should not be used here. -+ -If you need to pass multiple options, separate them with a comma. - --z <fuzz>:: - Pass the timestamp fuzz factor to cvsps, in seconds. If unset, - cvsps defaults to 300s. - --P <cvsps-output-file>:: - Instead of calling cvsps, read the provided cvsps output file. Useful - for debugging or when cvsps is being handled outside cvsimport. - --m:: - Attempt to detect merges based on the commit message. This option - will enable default regexes that try to capture the source - branch name from the commit message. - --M <regex>:: - Attempt to detect merges based on the commit message with a custom - regex. It can be used with `-m` to enable the default regexes - as well. You must escape forward slashes. -+ -The regex must capture the source branch name in $1. -+ -This option can be used several times to provide several detection regexes. - --S <regex>:: - Skip paths matching the regex. - --a:: - Import all commits, including recent ones. cvsimport by default - skips commits that have a timestamp less than 10 minutes ago. - --L <limit>:: - Limit the number of commits imported. Workaround for cases where - cvsimport leaks memory. - --A <author-conv-file>:: - CVS by default uses the Unix username when writing its - commit logs. Using this option and an author-conv-file - maps the name recorded in CVS to author name, e-mail and - optional time zone: -+ ---------- - exon=Andreas Ericsson <ae@op5.se> - spawn=Simon Pawn <spawn@frog-pond.org> America/Chicago - ---------- -+ -'git cvsimport' will make it appear as those authors had -their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly -all along. If a time zone is specified, GIT_AUTHOR_DATE will -have the corresponding offset applied. -+ -For convenience, this data is saved to `$GIT_DIR/cvs-authors` -each time the '-A' option is provided and read from that same -file each time 'git cvsimport' is run. -+ -It is not recommended to use this feature if you intend to -export changes back to CVS again later with -'git cvsexportcommit'. - --R:: - Generate a `$GIT_DIR/cvs-revisions` file containing a mapping from CVS - revision numbers to newly-created Git commit IDs. The generated file - will contain one line for each (filename, revision) pair imported; - each line will look like -+ ---------- -src/widget.c 1.1 1d862f173cdc7325b6fa6d2ae1cfd61fd1b512b7 ---------- -+ -The revision data is appended to the file if it already exists, for use when -doing incremental imports. -+ -This option may be useful if you have CVS revision numbers stored in commit -messages, bug-tracking systems, email archives, and the like. - --h:: - Print a short usage message and exit. - -OUTPUT ------- -If `-v` is specified, the script reports what it is doing. - -Otherwise, success is indicated the Unix way, i.e. by simply exiting with -a zero exit status. - -[[issues]] -ISSUES ------- -Problems related to timestamps: - - * If timestamps of commits in the CVS repository are not stable enough - to be used for ordering commits changes may show up in the wrong - order. - * If any files were ever "cvs import"ed more than once (e.g., import of - more than one vendor release) the HEAD contains the wrong content. - * If the timestamp order of different files cross the revision order - within the commit matching time window the order of commits may be - wrong. - -Problems related to branches: - - * Branches on which no commits have been made are not imported. - * All files from the branching point are added to a branch even if - never added in CVS. - * This applies to files added to the source branch *after* a daughter - branch was created: if previously no commit was made on the daughter - branch they will erroneously be added to the daughter branch in git. - -Problems related to tags: - -* Multiple tags on the same revision are not imported. - -If you suspect that any of these issues may apply to the repository you -want to import, consider using cvs2git: - -* cvs2git (part of cvs2svn), `http://subversion.apache.org/` - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-cvsserver.txt b/third_party/git/Documentation/git-cvsserver.txt deleted file mode 100644 index 79e22b1f3a..0000000000 --- a/third_party/git/Documentation/git-cvsserver.txt +++ /dev/null @@ -1,433 +0,0 @@ -git-cvsserver(1) -================ - -NAME ----- -git-cvsserver - A CVS server emulator for Git - -SYNOPSIS --------- - -SSH: - -[verse] -export CVS_SERVER="git cvsserver" -'cvs' -d :ext:user@server/path/repo.git co <HEAD_name> - -pserver (/etc/inetd.conf): - -[verse] -cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver - -Usage: - -[verse] -'git-cvsserver' [<options>] [pserver|server] [<directory> ...] - -OPTIONS -------- - -All these options obviously only make sense if enforced by the server side. -They have been implemented to resemble the linkgit:git-daemon[1] options as -closely as possible. - ---base-path <path>:: -Prepend 'path' to requested CVSROOT - ---strict-paths:: -Don't allow recursing into subdirectories - ---export-all:: -Don't check for `gitcvs.enabled` in config. You also have to specify a list -of allowed directories (see below) if you want to use this option. - --V:: ---version:: -Print version information and exit - --h:: --H:: ---help:: -Print usage information and exit - -<directory>:: -You can specify a list of allowed directories. If no directories -are given, all are allowed. This is an additional restriction, gitcvs -access still needs to be enabled by the `gitcvs.enabled` config option -unless `--export-all` was given, too. - - -DESCRIPTION ------------ - -This application is a CVS emulation layer for Git. - -It is highly functional. However, not all methods are implemented, -and for those methods that are implemented, -not all switches are implemented. - -Testing has been done using both the CLI CVS client, and the Eclipse CVS -plugin. Most functionality works fine with both of these clients. - -LIMITATIONS ------------ - -CVS clients cannot tag, branch or perform Git merges. - -'git-cvsserver' maps Git branches to CVS modules. This is very different -from what most CVS users would expect since in CVS modules usually represent -one or more directories. - -INSTALLATION ------------- - -1. If you are going to offer CVS access via pserver, add a line in - /etc/inetd.conf like -+ --- ------- - cvspserver stream tcp nowait nobody git-cvsserver pserver - ------- -Note: Some inetd servers let you specify the name of the executable -independently of the value of argv[0] (i.e. the name the program assumes -it was executed with). In this case the correct line in /etc/inetd.conf -looks like - ------- - cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver - ------- - -Only anonymous access is provided by pserve by default. To commit you -will have to create pserver accounts, simply add a gitcvs.authdb -setting in the config file of the repositories you want the cvsserver -to allow writes to, for example: - ------- - - [gitcvs] - authdb = /etc/cvsserver/passwd - ------- -The format of these files is username followed by the encrypted password, -for example: - ------- - myuser:$1Oyx5r9mdGZ2 - myuser:$1$BA)@$vbnMJMDym7tA32AamXrm./ ------- -You can use the 'htpasswd' facility that comes with Apache to make these -files, but Apache's MD5 crypt method differs from the one used by most C -library's crypt() function, so don't use the -m option. - -Alternatively you can produce the password with perl's crypt() operator: ------ - perl -e 'my ($user, $pass) = @ARGV; printf "%s:%s\n", $user, crypt($user, $pass)' $USER password ------ - -Then provide your password via the pserver method, for example: ------- - cvs -d:pserver:someuser:somepassword <at> server/path/repo.git co <HEAD_name> ------- -No special setup is needed for SSH access, other than having Git tools -in the PATH. If you have clients that do not accept the CVS_SERVER -environment variable, you can rename 'git-cvsserver' to `cvs`. - -Note: Newer CVS versions (>= 1.12.11) also support specifying -CVS_SERVER directly in CVSROOT like - ------- -cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name> ------- -This has the advantage that it will be saved in your 'CVS/Root' files and -you don't need to worry about always setting the correct environment -variable. SSH users restricted to 'git-shell' don't need to override the default -with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean -'git-cvsserver' and pretends that the other end runs the real 'cvs' better. --- -2. For each repo that you want accessible from CVS you need to edit config in - the repo and add the following section. -+ --- ------- - [gitcvs] - enabled=1 - # optional for debugging - logFile=/path/to/logfile - ------- -Note: you need to ensure each user that is going to invoke 'git-cvsserver' has -write access to the log file and to the database (see -<<dbbackend,Database Backend>>. If you want to offer write access over -SSH, the users of course also need write access to the Git repository itself. - -You also need to ensure that each repository is "bare" (without a Git index -file) for `cvs commit` to work. See linkgit:gitcvs-migration[7]. - -[[configaccessmethod]] -All configuration variables can also be overridden for a specific method of -access. Valid method names are "ext" (for SSH access) and "pserver". The -following example configuration would disable pserver access while still -allowing access over SSH. ------- - [gitcvs] - enabled=0 - - [gitcvs "ext"] - enabled=1 ------- --- -3. If you didn't specify the CVSROOT/CVS_SERVER directly in the checkout command, - automatically saving it in your 'CVS/Root' files, then you need to set them - explicitly in your environment. CVSROOT should be set as per normal, but the - directory should point at the appropriate Git repo. As above, for SSH clients - _not_ restricted to 'git-shell', CVS_SERVER should be set to 'git-cvsserver'. -+ --- ------- - export CVSROOT=:ext:user@server:/var/git/project.git - export CVS_SERVER="git cvsserver" ------- --- -4. For SSH clients that will make commits, make sure their server-side - .ssh/environment files (or .bashrc, etc., according to their specific shell) - export appropriate values for GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, - GIT_COMMITTER_NAME, and GIT_COMMITTER_EMAIL. For SSH clients whose login - shell is bash, .bashrc may be a reasonable alternative. - -5. Clients should now be able to check out the project. Use the CVS 'module' - name to indicate what Git 'head' you want to check out. This also sets the - name of your newly checked-out directory, unless you tell it otherwise with - `-d <dir_name>`. For example, this checks out 'master' branch to the - `project-master` directory: -+ ------- - cvs co -d project-master master ------- - -[[dbbackend]] -DATABASE BACKEND ----------------- - -'git-cvsserver' uses one database per Git head (i.e. CVS module) to -store information about the repository to maintain consistent -CVS revision numbers. The database needs to be -updated (i.e. written to) after every commit. - -If the commit is done directly by using `git` (as opposed to -using 'git-cvsserver') the update will need to happen on the -next repository access by 'git-cvsserver', independent of -access method and requested operation. - -That means that even if you offer only read access (e.g. by using -the pserver method), 'git-cvsserver' should have write access to -the database to work reliably (otherwise you need to make sure -that the database is up to date any time 'git-cvsserver' is executed). - -By default it uses SQLite databases in the Git directory, named -`gitcvs.<module_name>.sqlite`. Note that the SQLite backend creates -temporary files in the same directory as the database file on -write so it might not be enough to grant the users using -'git-cvsserver' write access to the database file without granting -them write access to the directory, too. - -The database cannot be reliably regenerated in a -consistent form after the branch it is tracking has changed. -Example: For merged branches, 'git-cvsserver' only tracks -one branch of development, and after a 'git merge' an -incrementally updated database may track a different branch -than a database regenerated from scratch, causing inconsistent -CVS revision numbers. `git-cvsserver` has no way of knowing which -branch it would have picked if it had been run incrementally -pre-merge. So if you have to fully or partially (from old -backup) regenerate the database, you should be suspicious -of pre-existing CVS sandboxes. - -You can configure the database backend with the following -configuration variables: - -Configuring database backend -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -'git-cvsserver' uses the Perl DBI module. Please also read -its documentation if changing these variables, especially -about `DBI->connect()`. - -gitcvs.dbName:: - Database name. The exact meaning depends on the - selected database driver, for SQLite this is a filename. - Supports variable substitution (see below). May - not contain semicolons (`;`). - Default: '%Ggitcvs.%m.sqlite' - -gitcvs.dbDriver:: - Used DBI driver. You can specify any available driver - for this here, but it might not work. cvsserver is tested - with 'DBD::SQLite', reported to work with - 'DBD::Pg', and reported *not* to work with 'DBD::mysql'. - Please regard this as an experimental feature. May not - contain colons (`:`). - Default: 'SQLite' - -gitcvs.dbuser:: - Database user. Only useful if setting `dbDriver`, since - SQLite has no concept of database users. Supports variable - substitution (see below). - -gitcvs.dbPass:: - Database password. Only useful if setting `dbDriver`, since - SQLite has no concept of database passwords. - -gitcvs.dbTableNamePrefix:: - Database table name prefix. Supports variable substitution - (see below). Any non-alphabetic characters will be replaced - with underscores. - -All variables can also be set per access method, see <<configaccessmethod,above>>. - -Variable substitution -^^^^^^^^^^^^^^^^^^^^^ -In `dbDriver` and `dbUser` you can use the following variables: - -%G:: - Git directory name -%g:: - Git directory name, where all characters except for - alpha-numeric ones, `.`, and `-` are replaced with - `_` (this should make it easier to use the directory - name in a filename if wanted) -%m:: - CVS module/Git head name -%a:: - access method (one of "ext" or "pserver") -%u:: - Name of the user running 'git-cvsserver'. - If no name can be determined, the - numeric uid is used. - -ENVIRONMENT ------------ - -These variables obviate the need for command-line options in some -circumstances, allowing easier restricted usage through git-shell. - -GIT_CVSSERVER_BASE_PATH takes the place of the argument to --base-path. - -GIT_CVSSERVER_ROOT specifies a single-directory whitelist. The -repository must still be configured to allow access through -git-cvsserver, as described above. - -When these environment variables are set, the corresponding -command-line arguments may not be used. - -ECLIPSE CVS CLIENT NOTES ------------------------- - -To get a checkout with the Eclipse CVS client: - -1. Select "Create a new project -> From CVS checkout" -2. Create a new location. See the notes below for details on how to choose the - right protocol. -3. Browse the 'modules' available. It will give you a list of the heads in - the repository. You will not be able to browse the tree from there. Only - the heads. -4. Pick `HEAD` when it asks what branch/tag to check out. Untick the - "launch commit wizard" to avoid committing the .project file. - -Protocol notes: If you are using anonymous access via pserver, just select that. -Those using SSH access should choose the 'ext' protocol, and configure 'ext' -access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to -"`git cvsserver`". Note that password support is not good when using 'ext', -you will definitely want to have SSH keys setup. - -Alternatively, you can just use the non-standard extssh protocol that Eclipse -offer. In that case CVS_SERVER is ignored, and you will have to replace -the cvs utility on the server with 'git-cvsserver' or manipulate your `.bashrc` -so that calling 'cvs' effectively calls 'git-cvsserver'. - -CLIENTS KNOWN TO WORK ---------------------- - -- CVS 1.12.9 on Debian -- CVS 1.11.17 on MacOSX (from Fink package) -- Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes) -- TortoiseCVS - -OPERATIONS SUPPORTED --------------------- - -All the operations required for normal use are supported, including -checkout, diff, status, update, log, add, remove, commit. - -Most CVS command arguments that read CVS tags or revision numbers -(typically -r) work, and also support any git refspec -(tag, branch, commit ID, etc). -However, CVS revision numbers for non-default branches are not well -emulated, and cvs log does not show tags or branches at -all. (Non-main-branch CVS revision numbers superficially resemble CVS -revision numbers, but they actually encode a git commit ID directly, -rather than represent the number of revisions since the branch point.) - -Note that there are two ways to checkout a particular branch. -As described elsewhere on this page, the "module" parameter -of cvs checkout is interpreted as a branch name, and it becomes -the main branch. It remains the main branch for a given sandbox -even if you temporarily make another branch sticky with -cvs update -r. Alternatively, the -r argument can indicate -some other branch to actually checkout, even though the module -is still the "main" branch. Tradeoffs (as currently -implemented): Each new "module" creates a new database on disk with -a history for the given module, and after the database is created, -operations against that main branch are fast. Or alternatively, --r doesn't take any extra disk space, but may be significantly slower for -many operations, like cvs update. - -If you want to refer to a git refspec that has characters that are -not allowed by CVS, you have two options. First, it may just work -to supply the git refspec directly to the appropriate CVS -r argument; -some CVS clients don't seem to do much sanity checking of the argument. -Second, if that fails, you can use a special character escape mechanism -that only uses characters that are valid in CVS tags. A sequence -of 4 or 5 characters of the form (underscore (`"_"`), dash (`"-"`), -one or two characters, and dash (`"-"`)) can encode various characters based -on the one or two letters: `"s"` for slash (`"/"`), `"p"` for -period (`"."`), `"u"` for underscore (`"_"`), or two hexadecimal digits -for any byte value at all (typically an ASCII number, or perhaps a part -of a UTF-8 encoded character). - -Legacy monitoring operations are not supported (edit, watch and related). -Exports and tagging (tags and branches) are not supported at this stage. - -CRLF Line Ending Conversions -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -By default the server leaves the `-k` mode blank for all files, -which causes the CVS client to treat them as a text files, subject -to end-of-line conversion on some platforms. - -You can make the server use the end-of-line conversion attributes to -set the `-k` modes for files by setting the `gitcvs.usecrlfattr` -config variable. See linkgit:gitattributes[5] for more information -about end-of-line conversion. - -Alternatively, if `gitcvs.usecrlfattr` config is not enabled -or the attributes do not allow automatic detection for a filename, then -the server uses the `gitcvs.allBinary` config for the default setting. -If `gitcvs.allBinary` is set, then file not otherwise -specified will default to '-kb' mode. Otherwise the `-k` mode -is left blank. But if `gitcvs.allBinary` is set to "guess", then -the correct `-k` mode will be guessed based on the contents of -the file. - -For best consistency with 'cvs', it is probably best to override the -defaults by setting `gitcvs.usecrlfattr` to true, -and `gitcvs.allBinary` to "guess". - -DEPENDENCIES ------------- -'git-cvsserver' depends on DBD::SQLite. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-daemon.txt b/third_party/git/Documentation/git-daemon.txt deleted file mode 100644 index fdc28c041c..0000000000 --- a/third_party/git/Documentation/git-daemon.txt +++ /dev/null @@ -1,340 +0,0 @@ -git-daemon(1) -============= - -NAME ----- -git-daemon - A really simple server for Git repositories - -SYNOPSIS --------- -[verse] -'git daemon' [--verbose] [--syslog] [--export-all] - [--timeout=<n>] [--init-timeout=<n>] [--max-connections=<n>] - [--strict-paths] [--base-path=<path>] [--base-path-relaxed] - [--user-path | --user-path=<path>] - [--interpolated-path=<pathtemplate>] - [--reuseaddr] [--detach] [--pid-file=<file>] - [--enable=<service>] [--disable=<service>] - [--allow-override=<service>] [--forbid-override=<service>] - [--access-hook=<path>] [--[no-]informative-errors] - [--inetd | - [--listen=<host_or_ipaddr>] [--port=<n>] - [--user=<user> [--group=<group>]]] - [--log-destination=(stderr|syslog|none)] - [<directory>...] - -DESCRIPTION ------------ -A really simple TCP Git daemon that normally listens on port "DEFAULT_GIT_PORT" -aka 9418. It waits for a connection asking for a service, and will serve -that service if it is enabled. - -It verifies that the directory has the magic file "git-daemon-export-ok", and -it will refuse to export any Git directory that hasn't explicitly been marked -for export this way (unless the `--export-all` parameter is specified). If you -pass some directory paths as 'git daemon' arguments, you can further restrict -the offers to a whitelist comprising of those. - -By default, only `upload-pack` service is enabled, which serves -'git fetch-pack' and 'git ls-remote' clients, which are invoked -from 'git fetch', 'git pull', and 'git clone'. - -This is ideally suited for read-only updates, i.e., pulling from -Git repositories. - -An `upload-archive` also exists to serve 'git archive'. - -OPTIONS -------- ---strict-paths:: - Match paths exactly (i.e. don't allow "/foo/repo" when the real path is - "/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths. - 'git daemon' will refuse to start when this option is enabled and no - whitelist is specified. - ---base-path=<path>:: - Remap all the path requests as relative to the given path. - This is sort of "Git root" - if you run 'git daemon' with - '--base-path=/srv/git' on example.com, then if you later try to pull - 'git://example.com/hello.git', 'git daemon' will interpret the path - as `/srv/git/hello.git`. - ---base-path-relaxed:: - If --base-path is enabled and repo lookup fails, with this option - 'git daemon' will attempt to lookup without prefixing the base path. - This is useful for switching to --base-path usage, while still - allowing the old paths. - ---interpolated-path=<pathtemplate>:: - To support virtual hosting, an interpolated path template can be - used to dynamically construct alternate paths. The template - supports %H for the target hostname as supplied by the client but - converted to all lowercase, %CH for the canonical hostname, - %IP for the server's IP address, %P for the port number, - and %D for the absolute path of the named repository. - After interpolation, the path is validated against the directory - whitelist. - ---export-all:: - Allow pulling from all directories that look like Git repositories - (have the 'objects' and 'refs' subdirectories), even if they - do not have the 'git-daemon-export-ok' file. - ---inetd:: - Have the server run as an inetd service. Implies --syslog (may be - overridden with `--log-destination=`). - Incompatible with --detach, --port, --listen, --user and --group - options. - ---listen=<host_or_ipaddr>:: - Listen on a specific IP address or hostname. IP addresses can - be either an IPv4 address or an IPv6 address if supported. If IPv6 - is not supported, then --listen=hostname is also not supported and - --listen must be given an IPv4 address. - Can be given more than once. - Incompatible with `--inetd` option. - ---port=<n>:: - Listen on an alternative port. Incompatible with `--inetd` option. - ---init-timeout=<n>:: - Timeout (in seconds) between the moment the connection is established - and the client request is received (typically a rather low value, since - that should be basically immediate). - ---timeout=<n>:: - Timeout (in seconds) for specific client sub-requests. This includes - the time it takes for the server to process the sub-request and the - time spent waiting for the next client's request. - ---max-connections=<n>:: - Maximum number of concurrent clients, defaults to 32. Set it to - zero for no limit. - ---syslog:: - Short for `--log-destination=syslog`. - ---log-destination=<destination>:: - Send log messages to the specified destination. - Note that this option does not imply --verbose, - thus by default only error conditions will be logged. - The <destination> must be one of: -+ --- -stderr:: - Write to standard error. - Note that if `--detach` is specified, - the process disconnects from the real standard error, - making this destination effectively equivalent to `none`. -syslog:: - Write to syslog, using the `git-daemon` identifier. -none:: - Disable all logging. --- -+ -The default destination is `syslog` if `--inetd` or `--detach` is specified, -otherwise `stderr`. - ---user-path:: ---user-path=<path>:: - Allow {tilde}user notation to be used in requests. When - specified with no parameter, requests to - git://host/{tilde}alice/foo is taken as a request to access - 'foo' repository in the home directory of user `alice`. - If `--user-path=path` is specified, the same request is - taken as a request to access `path/foo` repository in - the home directory of user `alice`. - ---verbose:: - Log details about the incoming connections and requested files. - ---reuseaddr:: - Use SO_REUSEADDR when binding the listening socket. - This allows the server to restart without waiting for - old connections to time out. - ---detach:: - Detach from the shell. Implies --syslog. - ---pid-file=<file>:: - Save the process id in 'file'. Ignored when the daemon - is run under `--inetd`. - ---user=<user>:: ---group=<group>:: - Change daemon's uid and gid before entering the service loop. - When only `--user` is given without `--group`, the - primary group ID for the user is used. The values of - the option are given to `getpwnam(3)` and `getgrnam(3)` - and numeric IDs are not supported. -+ -Giving these options is an error when used with `--inetd`; use -the facility of inet daemon to achieve the same before spawning -'git daemon' if needed. -+ -Like many programs that switch user id, the daemon does not reset -environment variables such as `$HOME` when it runs git programs, -e.g. `upload-pack` and `receive-pack`. When using this option, you -may also want to set and export `HOME` to point at the home -directory of `<user>` before starting the daemon, and make sure any -Git configuration files in that directory are readable by `<user>`. - ---enable=<service>:: ---disable=<service>:: - Enable/disable the service site-wide per default. Note - that a service disabled site-wide can still be enabled - per repository if it is marked overridable and the - repository enables the service with a configuration - item. - ---allow-override=<service>:: ---forbid-override=<service>:: - Allow/forbid overriding the site-wide default with per - repository configuration. By default, all the services - may be overridden. - ---[no-]informative-errors:: - When informative errors are turned on, git-daemon will report - more verbose errors to the client, differentiating conditions - like "no such repository" from "repository not exported". This - is more convenient for clients, but may leak information about - the existence of unexported repositories. When informative - errors are not enabled, all errors report "access denied" to the - client. The default is --no-informative-errors. - ---access-hook=<path>:: - Every time a client connects, first run an external command - specified by the <path> with service name (e.g. "upload-pack"), - path to the repository, hostname (%H), canonical hostname - (%CH), IP address (%IP), and TCP port (%P) as its command-line - arguments. The external command can decide to decline the - service by exiting with a non-zero status (or to allow it by - exiting with a zero status). It can also look at the $REMOTE_ADDR - and `$REMOTE_PORT` environment variables to learn about the - requestor when making this decision. -+ -The external command can optionally write a single line to its -standard output to be sent to the requestor as an error message when -it declines the service. - -<directory>:: - A directory to add to the whitelist of allowed directories. Unless - --strict-paths is specified this will also include subdirectories - of each named directory. - -SERVICES --------- - -These services can be globally enabled/disabled using the -command-line options of this command. If finer-grained -control is desired (e.g. to allow 'git archive' to be run -against only in a few selected repositories the daemon serves), -the per-repository configuration file can be used to enable or -disable them. - -upload-pack:: - This serves 'git fetch-pack' and 'git ls-remote' - clients. It is enabled by default, but a repository can - disable it by setting `daemon.uploadpack` configuration - item to `false`. - -upload-archive:: - This serves 'git archive --remote'. It is disabled by - default, but a repository can enable it by setting - `daemon.uploadarch` configuration item to `true`. - -receive-pack:: - This serves 'git send-pack' clients, allowing anonymous - push. It is disabled by default, as there is _no_ - authentication in the protocol (in other words, anybody - can push anything into the repository, including removal - of refs). This is solely meant for a closed LAN setting - where everybody is friendly. This service can be - enabled by setting `daemon.receivepack` configuration item to - `true`. - -EXAMPLES --------- -We assume the following in /etc/services:: -+ ------------- -$ grep 9418 /etc/services -git 9418/tcp # Git Version Control System ------------- - -'git daemon' as inetd server:: - To set up 'git daemon' as an inetd service that handles any - repository under the whitelisted set of directories, /pub/foo - and /pub/bar, place an entry like the following into - /etc/inetd all on one line: -+ ------------------------------------------------- - git stream tcp nowait nobody /usr/bin/git - git daemon --inetd --verbose --export-all - /pub/foo /pub/bar ------------------------------------------------- - - -'git daemon' as inetd server for virtual hosts:: - To set up 'git daemon' as an inetd service that handles - repositories for different virtual hosts, `www.example.com` - and `www.example.org`, place an entry like the following into - `/etc/inetd` all on one line: -+ ------------------------------------------------- - git stream tcp nowait nobody /usr/bin/git - git daemon --inetd --verbose --export-all - --interpolated-path=/pub/%H%D - /pub/www.example.org/software - /pub/www.example.com/software - /software ------------------------------------------------- -+ -In this example, the root-level directory `/pub` will contain -a subdirectory for each virtual host name supported. -Further, both hosts advertise repositories simply as -`git://www.example.com/software/repo.git`. For pre-1.4.0 -clients, a symlink from `/software` into the appropriate -default repository could be made as well. - - -'git daemon' as regular daemon for virtual hosts:: - To set up 'git daemon' as a regular, non-inetd service that - handles repositories for multiple virtual hosts based on - their IP addresses, start the daemon like this: -+ ------------------------------------------------- - git daemon --verbose --export-all - --interpolated-path=/pub/%IP/%D - /pub/192.168.1.200/software - /pub/10.10.220.23/software ------------------------------------------------- -+ -In this example, the root-level directory `/pub` will contain -a subdirectory for each virtual host IP address supported. -Repositories can still be accessed by hostname though, assuming -they correspond to these IP addresses. - -selectively enable/disable services per repository:: - To enable 'git archive --remote' and disable 'git fetch' against - a repository, have the following in the configuration file in the - repository (that is the file 'config' next to `HEAD`, 'refs' and - 'objects'). -+ ----------------------------------------------------------------- - [daemon] - uploadpack = false - uploadarch = true ----------------------------------------------------------------- - - -ENVIRONMENT ------------ -'git daemon' will set REMOTE_ADDR to the IP address of the client -that connected to it, if the IP address is available. REMOTE_ADDR will -be available in the environment of hooks called when -services are performed. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-describe.txt b/third_party/git/Documentation/git-describe.txt deleted file mode 100644 index a88f6ae2c6..0000000000 --- a/third_party/git/Documentation/git-describe.txt +++ /dev/null @@ -1,207 +0,0 @@ -git-describe(1) -=============== - -NAME ----- -git-describe - Give an object a human readable name based on an available ref - -SYNOPSIS --------- -[verse] -'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] [<commit-ish>...] -'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>] -'git describe' <blob> - -DESCRIPTION ------------ -The command finds the most recent tag that is reachable from a -commit. If the tag points to the commit, then only the tag is -shown. Otherwise, it suffixes the tag name with the number of -additional commits on top of the tagged object and the -abbreviated object name of the most recent commit. The result -is a "human-readable" object name which can also be used to -identify the commit to other git commands. - -By default (without --all or --tags) `git describe` only shows -annotated tags. For more information about creating annotated tags -see the -a and -s options to linkgit:git-tag[1]. - -If the given object refers to a blob, it will be described -as `<commit-ish>:<path>`, such that the blob can be found -at `<path>` in the `<commit-ish>`, which itself describes the -first commit in which this blob occurs in a reverse revision walk -from HEAD. - -OPTIONS -------- -<commit-ish>...:: - Commit-ish object names to describe. Defaults to HEAD if omitted. - ---dirty[=<mark>]:: ---broken[=<mark>]:: - Describe the state of the working tree. When the working - tree matches HEAD, the output is the same as "git describe - HEAD". If the working tree has local modification "-dirty" - is appended to it. If a repository is corrupt and Git - cannot determine if there is local modification, Git will - error out, unless `--broken' is given, which appends - the suffix "-broken" instead. - ---all:: - Instead of using only the annotated tags, use any ref - found in `refs/` namespace. This option enables matching - any known branch, remote-tracking branch, or lightweight tag. - ---tags:: - Instead of using only the annotated tags, use any tag - found in `refs/tags` namespace. This option enables matching - a lightweight (non-annotated) tag. - ---contains:: - Instead of finding the tag that predates the commit, find - the tag that comes after the commit, and thus contains it. - Automatically implies --tags. - ---abbrev=<n>:: - Instead of using the default 7 hexadecimal digits as the - abbreviated object name, use <n> digits, or as many digits - as needed to form a unique object name. An <n> of 0 - will suppress long format, only showing the closest tag. - ---candidates=<n>:: - Instead of considering only the 10 most recent tags as - candidates to describe the input commit-ish consider - up to <n> candidates. Increasing <n> above 10 will take - slightly longer but may produce a more accurate result. - An <n> of 0 will cause only exact matches to be output. - ---exact-match:: - Only output exact matches (a tag directly references the - supplied commit). This is a synonym for --candidates=0. - ---debug:: - Verbosely display information about the searching strategy - being employed to standard error. The tag name will still - be printed to standard out. - ---long:: - Always output the long format (the tag, the number of commits - and the abbreviated commit name) even when it matches a tag. - This is useful when you want to see parts of the commit object name - in "describe" output, even when the commit in question happens to be - a tagged version. Instead of just emitting the tag name, it will - describe such a commit as v1.2-0-gdeadbee (0th commit since tag v1.2 - that points at object deadbee....). - ---match <pattern>:: - Only consider tags matching the given `glob(7)` pattern, - excluding the "refs/tags/" prefix. If used with `--all`, it also - considers local branches and remote-tracking references matching the - pattern, excluding respectively "refs/heads/" and "refs/remotes/" - prefix; references of other types are never considered. If given - multiple times, a list of patterns will be accumulated, and tags - matching any of the patterns will be considered. Use `--no-match` to - clear and reset the list of patterns. - ---exclude <pattern>:: - Do not consider tags matching the given `glob(7)` pattern, excluding - the "refs/tags/" prefix. If used with `--all`, it also does not consider - local branches and remote-tracking references matching the pattern, - excluding respectively "refs/heads/" and "refs/remotes/" prefix; - references of other types are never considered. If given multiple times, - a list of patterns will be accumulated and tags matching any of the - patterns will be excluded. When combined with --match a tag will be - considered when it matches at least one --match pattern and does not - match any of the --exclude patterns. Use `--no-exclude` to clear and - reset the list of patterns. - ---always:: - Show uniquely abbreviated commit object as fallback. - ---first-parent:: - Follow only the first parent commit upon seeing a merge commit. - This is useful when you wish to not match tags on branches merged - in the history of the target commit. - -EXAMPLES --------- - -With something like git.git current tree, I get: - - [torvalds@g5 git]$ git describe parent - v1.0.4-14-g2414721 - -i.e. the current head of my "parent" branch is based on v1.0.4, -but since it has a few commits on top of that, -describe has added the number of additional commits ("14") and -an abbreviated object name for the commit itself ("2414721") -at the end. - -The number of additional commits is the number -of commits which would be displayed by "git log v1.0.4..parent". -The hash suffix is "-g" + unambiguous abbreviation for the tip commit -of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`). -The "g" prefix stands for "git" and is used to allow describing the version of -a software depending on the SCM the software is managed with. This is useful -in an environment where people may use different SCMs. - -Doing a 'git describe' on a tag-name will just show the tag name: - - [torvalds@g5 git]$ git describe v1.0.4 - v1.0.4 - -With --all, the command can use branch heads as references, so -the output shows the reference path as well: - - [torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2 - tags/v1.0.0-21-g975b - - [torvalds@g5 git]$ git describe --all --abbrev=4 HEAD^ - heads/lt/describe-7-g975b - -With --abbrev set to 0, the command can be used to find the -closest tagname without any suffix: - - [torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2 - tags/v1.0.0 - -Note that the suffix you get if you type these commands today may be -longer than what Linus saw above when he ran these commands, as your -Git repository may have new commits whose object names begin with -975b that did not exist back then, and "-g975b" suffix alone may not -be sufficient to disambiguate these commits. - - -SEARCH STRATEGY ---------------- - -For each commit-ish supplied, 'git describe' will first look for -a tag which tags exactly that commit. Annotated tags will always -be preferred over lightweight tags, and tags with newer dates will -always be preferred over tags with older dates. If an exact match -is found, its name will be output and searching will stop. - -If an exact match was not found, 'git describe' will walk back -through the commit history to locate an ancestor commit which -has been tagged. The ancestor's tag will be output along with an -abbreviation of the input commit-ish's SHA-1. If `--first-parent` was -specified then the walk will only consider the first parent of each -commit. - -If multiple tags were found during the walk then the tag which -has the fewest commits different from the input commit-ish will be -selected and output. Here fewest commits different is defined as -the number of commits which would be shown by `git log tag..input` -will be the smallest number of commits possible. - -BUGS ----- - -Tree objects as well as tag objects not pointing at commits, cannot be described. -When describing blobs, the lightweight tags pointing at blobs are ignored, -but the blob is still described as <committ-ish>:<path> despite the lightweight -tag being favorable. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-diff-files.txt b/third_party/git/Documentation/git-diff-files.txt deleted file mode 100644 index 906774f0f7..0000000000 --- a/third_party/git/Documentation/git-diff-files.txt +++ /dev/null @@ -1,52 +0,0 @@ -git-diff-files(1) -================= - -NAME ----- -git-diff-files - Compares files in the working tree and the index - - -SYNOPSIS --------- -[verse] -'git diff-files' [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>...] - -DESCRIPTION ------------ -Compares the files in the working tree and the index. When paths -are specified, compares only those named paths. Otherwise all -entries in the index are compared. The output format is the -same as for 'git diff-index' and 'git diff-tree'. - -OPTIONS -------- -include::diff-options.txt[] - --1 --base:: --2 --ours:: --3 --theirs:: --0:: - Diff against the "base" version, "our branch" or "their - branch" respectively. With these options, diffs for - merged entries are not shown. -+ -The default is to diff against our branch (-2) and the -cleanly resolved paths. The option -0 can be given to -omit diff output for unmerged entries and just show "Unmerged". - --c:: ---cc:: - This compares stage 2 (our branch), stage 3 (their - branch) and the working tree file and outputs a combined - diff, similar to the way 'diff-tree' shows a merge - commit with these flags. - --q:: - Remain silent even on nonexistent files - - -include::diff-format.txt[] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-diff-index.txt b/third_party/git/Documentation/git-diff-index.txt deleted file mode 100644 index f4bd8155c0..0000000000 --- a/third_party/git/Documentation/git-diff-index.txt +++ /dev/null @@ -1,122 +0,0 @@ -git-diff-index(1) -================= - -NAME ----- -git-diff-index - Compare a tree to the working tree or index - - -SYNOPSIS --------- -[verse] -'git diff-index' [-m] [--cached] [<common diff options>] <tree-ish> [<path>...] - -DESCRIPTION ------------ -Compares the content and mode of the blobs found in a tree object -with the corresponding tracked files in the working tree, or with the -corresponding paths in the index. When <path> arguments are present, -compares only paths matching those patterns. Otherwise all tracked -files are compared. - -OPTIONS -------- -include::diff-options.txt[] - -<tree-ish>:: - The id of a tree object to diff against. - ---cached:: - do not consider the on-disk file at all - --m:: - By default, files recorded in the index but not checked - out are reported as deleted. This flag makes - 'git diff-index' say that all non-checked-out files are up - to date. - -include::diff-format.txt[] - -OPERATING MODES ---------------- -You can choose whether you want to trust the index file entirely -(using the `--cached` flag) or ask the diff logic to show any files -that don't match the stat state as being "tentatively changed". Both -of these operations are very useful indeed. - -CACHED MODE ------------ -If `--cached` is specified, it allows you to ask: - - show me the differences between HEAD and the current index - contents (the ones I'd write using 'git write-tree') - -For example, let's say that you have worked on your working directory, updated -some files in the index and are ready to commit. You want to see exactly -*what* you are going to commit, without having to write a new tree -object and compare it that way, and to do that, you just do - - git diff-index --cached HEAD - -Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had -done an `update-index` to make that effective in the index file. -`git diff-files` wouldn't show anything at all, since the index file -matches my working directory. But doing a 'git diff-index' does: - - torvalds@ppc970:~/git> git diff-index --cached HEAD - -100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c - +100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c - -You can see easily that the above is a rename. - -In fact, `git diff-index --cached` *should* always be entirely equivalent to -actually doing a 'git write-tree' and comparing that. Except this one is much -nicer for the case where you just want to check where you are. - -So doing a `git diff-index --cached` is basically very useful when you are -asking yourself "what have I already marked for being committed, and -what's the difference to a previous tree". - -NON-CACHED MODE ---------------- -The "non-cached" mode takes a different approach, and is potentially -the more useful of the two in that what it does can't be emulated with -a 'git write-tree' + 'git diff-tree'. Thus that's the default mode. -The non-cached version asks the question: - - show me the differences between HEAD and the currently checked out - tree - index contents _and_ files that aren't up to date - -which is obviously a very useful question too, since that tells you what -you *could* commit. Again, the output matches the 'git diff-tree -r' -output to a tee, but with a twist. - -The twist is that if some file doesn't match the index, we don't have -a backing store thing for it, and we use the magic "all-zero" sha1 to -show that. So let's say that you have edited `kernel/sched.c`, but -have not actually done a 'git update-index' on it yet - there is no -"object" associated with the new state, and you get: - - torvalds@ppc970:~/v2.6/linux> git diff-index --abbrev HEAD - :100644 100664 7476bb... 000000... kernel/sched.c - -i.e., it shows that the tree has changed, and that `kernel/sched.c` is -not up to date and may contain new stuff. The all-zero sha1 means that to -get the real diff, you need to look at the object in the working directory -directly rather than do an object-to-object diff. - -NOTE: As with other commands of this type, 'git diff-index' does not -actually look at the contents of the file at all. So maybe -`kernel/sched.c` hasn't actually changed, and it's just that you -touched it. In either case, it's a note that you need to -'git update-index' it to make the index be in sync. - -NOTE: You can have a mixture of files show up as "has been updated" -and "is still dirty in the working directory" together. You can always -tell which file is in which state, since the "has been updated" ones -show a valid sha1, and the "not in sync with the index" ones will -always have the special all-zero sha1. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-diff-tree.txt b/third_party/git/Documentation/git-diff-tree.txt deleted file mode 100644 index 5c8a2a5e97..0000000000 --- a/third_party/git/Documentation/git-diff-tree.txt +++ /dev/null @@ -1,126 +0,0 @@ -git-diff-tree(1) -================ - -NAME ----- -git-diff-tree - Compares the content and mode of blobs found via two tree objects - - -SYNOPSIS --------- -[verse] -'git diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty] - [-t] [-r] [-c | --cc] [--combined-all-paths] [--root] - [<common diff options>] <tree-ish> [<tree-ish>] [<path>...] - -DESCRIPTION ------------ -Compares the content and mode of the blobs found via two tree objects. - -If there is only one <tree-ish> given, the commit is compared with its parents -(see --stdin below). - -Note that 'git diff-tree' can use the tree encapsulated in a commit object. - -OPTIONS -------- -include::diff-options.txt[] - -<tree-ish>:: - The id of a tree object. - -<path>...:: - If provided, the results are limited to a subset of files - matching one of the provided pathspecs. - --r:: - recurse into sub-trees - --t:: - show tree entry itself as well as subtrees. Implies -r. - ---root:: - When `--root` is specified the initial commit will be shown as a big - creation event. This is equivalent to a diff against the NULL tree. - ---stdin:: - When `--stdin` is specified, the command does not take - <tree-ish> arguments from the command line. Instead, it - reads lines containing either two <tree>, one <commit>, or a - list of <commit> from its standard input. (Use a single space - as separator.) -+ -When two trees are given, it compares the first tree with the second. -When a single commit is given, it compares the commit with its -parents. The remaining commits, when given, are used as if they are -parents of the first commit. -+ -When comparing two trees, the ID of both trees (separated by a space -and terminated by a newline) is printed before the difference. When -comparing commits, the ID of the first (or only) commit, followed by a -newline, is printed. -+ -The following flags further affect the behavior when comparing -commits (but not trees). - --m:: - By default, 'git diff-tree --stdin' does not show - differences for merge commits. With this flag, it shows - differences to that commit from all of its parents. See - also `-c`. - --s:: - By default, 'git diff-tree --stdin' shows differences, - either in machine-readable form (without `-p`) or in patch - form (with `-p`). This output can be suppressed. It is - only useful with `-v` flag. - --v:: - This flag causes 'git diff-tree --stdin' to also show - the commit message before the differences. - -include::pretty-options.txt[] - ---no-commit-id:: - 'git diff-tree' outputs a line with the commit ID when - applicable. This flag suppressed the commit ID output. - --c:: - This flag changes the way a merge commit is displayed - (which means it is useful only when the command is given - one <tree-ish>, or `--stdin`). It shows the differences - from each of the parents to the merge result simultaneously - instead of showing pairwise diff between a parent and the - result one at a time (which is what the `-m` option does). - Furthermore, it lists only files which were modified - from all parents. - ---cc:: - This flag changes the way a merge commit patch is displayed, - in a similar way to the `-c` option. It implies the `-c` - and `-p` options and further compresses the patch output - by omitting uninteresting hunks whose the contents in the parents - have only two variants and the merge result picks one of them - without modification. When all hunks are uninteresting, the commit - itself and the commit log message is not shown, just like in any other - "empty diff" case. - ---combined-all-paths:: - This flag causes combined diffs (used for merge commits) to - list the name of the file from all parents. It thus only has - effect when -c or --cc are specified, and is likely only - useful if filename changes are detected (i.e. when either - rename or copy detection have been requested). - ---always:: - Show the commit itself and the commit log message even - if the diff itself is empty. - - -include::pretty-formats.txt[] - -include::diff-format.txt[] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-diff.txt b/third_party/git/Documentation/git-diff.txt deleted file mode 100644 index 72179d993c..0000000000 --- a/third_party/git/Documentation/git-diff.txt +++ /dev/null @@ -1,203 +0,0 @@ -git-diff(1) -=========== - -NAME ----- -git-diff - Show changes between commits, commit and working tree, etc - - -SYNOPSIS --------- -[verse] -'git diff' [<options>] [<commit>] [--] [<path>...] -'git diff' [<options>] --cached [<commit>] [--] [<path>...] -'git diff' [<options>] <commit> <commit> [--] [<path>...] -'git diff' [<options>] <blob> <blob> -'git diff' [<options>] --no-index [--] <path> <path> - -DESCRIPTION ------------ -Show changes between the working tree and the index or a tree, changes -between the index and a tree, changes between two trees, changes between -two blob objects, or changes between two files on disk. - -'git diff' [<options>] [--] [<path>...]:: - - This form is to view the changes you made relative to - the index (staging area for the next commit). In other - words, the differences are what you _could_ tell Git to - further add to the index but you still haven't. You can - stage these changes by using linkgit:git-add[1]. - -'git diff' [<options>] --no-index [--] <path> <path>:: - - This form is to compare the given two paths on the - filesystem. You can omit the `--no-index` option when - running the command in a working tree controlled by Git and - at least one of the paths points outside the working tree, - or when running the command outside a working tree - controlled by Git. - -'git diff' [<options>] --cached [<commit>] [--] [<path>...]:: - - This form is to view the changes you staged for the next - commit relative to the named <commit>. Typically you - would want comparison with the latest commit, so if you - do not give <commit>, it defaults to HEAD. - If HEAD does not exist (e.g. unborn branches) and - <commit> is not given, it shows all staged changes. - --staged is a synonym of --cached. - -'git diff' [<options>] <commit> [--] [<path>...]:: - - This form is to view the changes you have in your - working tree relative to the named <commit>. You can - use HEAD to compare it with the latest commit, or a - branch name to compare with the tip of a different - branch. - -'git diff' [<options>] <commit> <commit> [--] [<path>...]:: - - This is to view the changes between two arbitrary - <commit>. - -'git diff' [<options>] <commit>..<commit> [--] [<path>...]:: - - This is synonymous to the previous form. If <commit> on - one side is omitted, it will have the same effect as - using HEAD instead. - -'git diff' [<options>] <commit>\...<commit> [--] [<path>...]:: - - This form is to view the changes on the branch containing - and up to the second <commit>, starting at a common ancestor - of both <commit>. "git diff A\...B" is equivalent to - "git diff $(git merge-base A B) B". You can omit any one - of <commit>, which has the same effect as using HEAD instead. - -Just in case you are doing something exotic, it should be -noted that all of the <commit> in the above description, except -in the last two forms that use ".." notations, can be any -<tree>. - -For a more complete list of ways to spell <commit>, see -"SPECIFYING REVISIONS" section in linkgit:gitrevisions[7]. -However, "diff" is about comparing two _endpoints_, not ranges, -and the range notations ("<commit>..<commit>" and -"<commit>\...<commit>") do not mean a range as defined in the -"SPECIFYING RANGES" section in linkgit:gitrevisions[7]. - -'git diff' [<options>] <blob> <blob>:: - - This form is to view the differences between the raw - contents of two blob objects. - -OPTIONS -------- -:git-diff: 1 -include::diff-options.txt[] - --1 --base:: --2 --ours:: --3 --theirs:: - Compare the working tree with the "base" version (stage #1), - "our branch" (stage #2) or "their branch" (stage #3). The - index contains these stages only for unmerged entries i.e. - while resolving conflicts. See linkgit:git-read-tree[1] - section "3-Way Merge" for detailed information. - --0:: - Omit diff output for unmerged entries and just show - "Unmerged". Can be used only when comparing the working tree - with the index. - -<path>...:: - The <paths> parameters, when given, are used to limit - the diff to the named paths (you can give directory - names and get diff for all files under them). - - -include::diff-format.txt[] - -EXAMPLES --------- - -Various ways to check your working tree:: -+ ------------- -$ git diff <1> -$ git diff --cached <2> -$ git diff HEAD <3> ------------- -+ -<1> Changes in the working tree not yet staged for the next commit. -<2> Changes between the index and your last commit; what you - would be committing if you run "git commit" without "-a" option. -<3> Changes in the working tree since your last commit; what you - would be committing if you run "git commit -a" - -Comparing with arbitrary commits:: -+ ------------- -$ git diff test <1> -$ git diff HEAD -- ./test <2> -$ git diff HEAD^ HEAD <3> ------------- -+ -<1> Instead of using the tip of the current branch, compare with the - tip of "test" branch. -<2> Instead of comparing with the tip of "test" branch, compare with - the tip of the current branch, but limit the comparison to the - file "test". -<3> Compare the version before the last commit and the last commit. - -Comparing branches:: -+ ------------- -$ git diff topic master <1> -$ git diff topic..master <2> -$ git diff topic...master <3> ------------- -+ -<1> Changes between the tips of the topic and the master branches. -<2> Same as above. -<3> Changes that occurred on the master branch since when the topic - branch was started off it. - -Limiting the diff output:: -+ ------------- -$ git diff --diff-filter=MRC <1> -$ git diff --name-status <2> -$ git diff arch/i386 include/asm-i386 <3> ------------- -+ -<1> Show only modification, rename, and copy, but not addition - or deletion. -<2> Show only names and the nature of change, but not actual - diff output. -<3> Limit diff output to named subtrees. - -Munging the diff output:: -+ ------------- -$ git diff --find-copies-harder -B -C <1> -$ git diff -R <2> ------------- -+ -<1> Spend extra cycles to find renames, copies and complete - rewrites (very expensive). -<2> Output diff in reverse. - -SEE ALSO --------- -diff(1), -linkgit:git-difftool[1], -linkgit:git-log[1], -linkgit:gitdiffcore[7], -linkgit:git-format-patch[1], -linkgit:git-apply[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-difftool.txt b/third_party/git/Documentation/git-difftool.txt deleted file mode 100644 index 484c485fd0..0000000000 --- a/third_party/git/Documentation/git-difftool.txt +++ /dev/null @@ -1,149 +0,0 @@ -git-difftool(1) -=============== - -NAME ----- -git-difftool - Show changes using common diff tools - -SYNOPSIS --------- -[verse] -'git difftool' [<options>] [<commit> [<commit>]] [--] [<path>...] - -DESCRIPTION ------------ -'git difftool' is a Git command that allows you to compare and edit files -between revisions using common diff tools. 'git difftool' is a frontend -to 'git diff' and accepts the same options and arguments. See -linkgit:git-diff[1]. - -OPTIONS -------- --d:: ---dir-diff:: - Copy the modified files to a temporary location and perform - a directory diff on them. This mode never prompts before - launching the diff tool. - --y:: ---no-prompt:: - Do not prompt before launching a diff tool. - ---prompt:: - Prompt before each invocation of the diff tool. - This is the default behaviour; the option is provided to - override any configuration settings. - --t <tool>:: ---tool=<tool>:: - Use the diff tool specified by <tool>. Valid values include - emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help` - for the list of valid <tool> settings. -+ -If a diff tool is not specified, 'git difftool' -will use the configuration variable `diff.tool`. If the -configuration variable `diff.tool` is not set, 'git difftool' -will pick a suitable default. -+ -You can explicitly provide a full path to the tool by setting the -configuration variable `difftool.<tool>.path`. For example, you -can configure the absolute path to kdiff3 by setting -`difftool.kdiff3.path`. Otherwise, 'git difftool' assumes the -tool is available in PATH. -+ -Instead of running one of the known diff tools, -'git difftool' can be customized to run an alternative program -by specifying the command line to invoke in a configuration -variable `difftool.<tool>.cmd`. -+ -When 'git difftool' is invoked with this tool (either through the -`-t` or `--tool` option or the `diff.tool` configuration variable) -the configured command line will be invoked with the following -variables available: `$LOCAL` is set to the name of the temporary -file containing the contents of the diff pre-image and `$REMOTE` -is set to the name of the temporary file containing the contents -of the diff post-image. `$MERGED` is the name of the file which is -being compared. `$BASE` is provided for compatibility -with custom merge tool commands and has the same value as `$MERGED`. - ---tool-help:: - Print a list of diff tools that may be used with `--tool`. - ---[no-]symlinks:: - 'git difftool''s default behavior is create symlinks to the - working tree when run in `--dir-diff` mode and the right-hand - side of the comparison yields the same content as the file in - the working tree. -+ -Specifying `--no-symlinks` instructs 'git difftool' to create copies -instead. `--no-symlinks` is the default on Windows. - --x <command>:: ---extcmd=<command>:: - Specify a custom command for viewing diffs. - 'git-difftool' ignores the configured defaults and runs - `$command $LOCAL $REMOTE` when this option is specified. - Additionally, `$BASE` is set in the environment. - --g:: ---[no-]gui:: - When 'git-difftool' is invoked with the `-g` or `--gui` option - the default diff tool will be read from the configured - `diff.guitool` variable instead of `diff.tool`. The `--no-gui` - option can be used to override this setting. If `diff.guitool` - is not set, we will fallback in the order of `merge.guitool`, - `diff.tool`, `merge.tool` until a tool is found. - ---[no-]trust-exit-code:: - 'git-difftool' invokes a diff tool individually on each file. - Errors reported by the diff tool are ignored by default. - Use `--trust-exit-code` to make 'git-difftool' exit when an - invoked diff tool returns a non-zero exit code. -+ -'git-difftool' will forward the exit code of the invoked tool when -`--trust-exit-code` is used. - -See linkgit:git-diff[1] for the full list of supported options. - -CONFIG VARIABLES ----------------- -'git difftool' falls back to 'git mergetool' config variables when the -difftool equivalents have not been defined. - -diff.tool:: - The default diff tool to use. - -diff.guitool:: - The default diff tool to use when `--gui` is specified. - -difftool.<tool>.path:: - Override the path for the given tool. This is useful in case - your tool is not in the PATH. - -difftool.<tool>.cmd:: - Specify the command to invoke the specified diff tool. -+ -See the `--tool=<tool>` option above for more details. - -difftool.prompt:: - Prompt before each invocation of the diff tool. - -difftool.trustExitCode:: - Exit difftool if the invoked diff tool returns a non-zero exit status. -+ -See the `--trust-exit-code` option above for more details. - -SEE ALSO --------- -linkgit:git-diff[1]:: - Show changes between commits, commit and working tree, etc - -linkgit:git-mergetool[1]:: - Run merge conflict resolution tools to resolve merge conflicts - -linkgit:git-config[1]:: - Get and set repository or global options - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-fast-export.txt b/third_party/git/Documentation/git-fast-export.txt deleted file mode 100644 index cc940eb9ad..0000000000 --- a/third_party/git/Documentation/git-fast-export.txt +++ /dev/null @@ -1,246 +0,0 @@ -git-fast-export(1) -================== - -NAME ----- -git-fast-export - Git data exporter - - -SYNOPSIS --------- -[verse] -'git fast-export [<options>]' | 'git fast-import' - -DESCRIPTION ------------ -This program dumps the given revisions in a form suitable to be piped -into 'git fast-import'. - -You can use it as a human-readable bundle replacement (see -linkgit:git-bundle[1]), or as a kind of an interactive -'git filter-branch'. - - -OPTIONS -------- ---progress=<n>:: - Insert 'progress' statements every <n> objects, to be shown by - 'git fast-import' during import. - ---signed-tags=(verbatim|warn|warn-strip|strip|abort):: - Specify how to handle signed tags. Since any transformation - after the export can change the tag names (which can also happen - when excluding revisions) the signatures will not match. -+ -When asking to 'abort' (which is the default), this program will die -when encountering a signed tag. With 'strip', the tags will silently -be made unsigned, with 'warn-strip' they will be made unsigned but a -warning will be displayed, with 'verbatim', they will be silently -exported and with 'warn', they will be exported, but you will see a -warning. - ---tag-of-filtered-object=(abort|drop|rewrite):: - Specify how to handle tags whose tagged object is filtered out. - Since revisions and files to export can be limited by path, - tagged objects may be filtered completely. -+ -When asking to 'abort' (which is the default), this program will die -when encountering such a tag. With 'drop' it will omit such tags from -the output. With 'rewrite', if the tagged object is a commit, it will -rewrite the tag to tag an ancestor commit (via parent rewriting; see -linkgit:git-rev-list[1]) - --M:: --C:: - Perform move and/or copy detection, as described in the - linkgit:git-diff[1] manual page, and use it to generate - rename and copy commands in the output dump. -+ -Note that earlier versions of this command did not complain and -produced incorrect results if you gave these options. - ---export-marks=<file>:: - Dumps the internal marks table to <file> when complete. - Marks are written one per line as `:markid SHA-1`. Only marks - for revisions are dumped; marks for blobs are ignored. - Backends can use this file to validate imports after they - have been completed, or to save the marks table across - incremental runs. As <file> is only opened and truncated - at completion, the same path can also be safely given to - --import-marks. - The file will not be written if no new object has been - marked/exported. - ---import-marks=<file>:: - Before processing any input, load the marks specified in - <file>. The input file must exist, must be readable, and - must use the same format as produced by --export-marks. -+ -Any commits that have already been marked will not be exported again. -If the backend uses a similar --import-marks file, this allows for -incremental bidirectional exporting of the repository by keeping the -marks the same across runs. - ---fake-missing-tagger:: - Some old repositories have tags without a tagger. The - fast-import protocol was pretty strict about that, and did not - allow that. So fake a tagger to be able to fast-import the - output. - ---use-done-feature:: - Start the stream with a 'feature done' stanza, and terminate - it with a 'done' command. - ---no-data:: - Skip output of blob objects and instead refer to blobs via - their original SHA-1 hash. This is useful when rewriting the - directory structure or history of a repository without - touching the contents of individual files. Note that the - resulting stream can only be used by a repository which - already contains the necessary objects. - ---full-tree:: - This option will cause fast-export to issue a "deleteall" - directive for each commit followed by a full list of all files - in the commit (as opposed to just listing the files which are - different from the commit's first parent). - ---anonymize:: - Anonymize the contents of the repository while still retaining - the shape of the history and stored tree. See the section on - `ANONYMIZING` below. - ---reference-excluded-parents:: - By default, running a command such as `git fast-export - master~5..master` will not include the commit master{tilde}5 - and will make master{tilde}4 no longer have master{tilde}5 as - a parent (though both the old master{tilde}4 and new - master{tilde}4 will have all the same files). Use - --reference-excluded-parents to instead have the stream - refer to commits in the excluded range of history by their - sha1sum. Note that the resulting stream can only be used by a - repository which already contains the necessary parent - commits. - ---show-original-ids:: - Add an extra directive to the output for commits and blobs, - `original-oid <SHA1SUM>`. While such directives will likely be - ignored by importers such as git-fast-import, it may be useful - for intermediary filters (e.g. for rewriting commit messages - which refer to older commits, or for stripping blobs by id). - ---reencode=(yes|no|abort):: - Specify how to handle `encoding` header in commit objects. When - asking to 'abort' (which is the default), this program will die - when encountering such a commit object. With 'yes', the commit - message will be reencoded into UTF-8. With 'no', the original - encoding will be preserved. - ---refspec:: - Apply the specified refspec to each ref exported. Multiple of them can - be specified. - -[<git-rev-list-args>...]:: - A list of arguments, acceptable to 'git rev-parse' and - 'git rev-list', that specifies the specific objects and references - to export. For example, `master~10..master` causes the - current master reference to be exported along with all objects - added since its 10th ancestor commit and (unless the - --reference-excluded-parents option is specified) all files - common to master{tilde}9 and master{tilde}10. - -EXAMPLES --------- - -------------------------------------------------------------------- -$ git fast-export --all | (cd /empty/repository && git fast-import) -------------------------------------------------------------------- - -This will export the whole repository and import it into the existing -empty repository. Except for reencoding commits that are not in -UTF-8, it would be a one-to-one mirror. - ------------------------------------------------------ -$ git fast-export master~5..master | - sed "s|refs/heads/master|refs/heads/other|" | - git fast-import ------------------------------------------------------ - -This makes a new branch called 'other' from 'master~5..master' -(i.e. if 'master' has linear history, it will take the last 5 commits). - -Note that this assumes that none of the blobs and commit messages -referenced by that revision range contains the string -'refs/heads/master'. - - -ANONYMIZING ------------ - -If the `--anonymize` option is given, git will attempt to remove all -identifying information from the repository while still retaining enough -of the original tree and history patterns to reproduce some bugs. The -goal is that a git bug which is found on a private repository will -persist in the anonymized repository, and the latter can be shared with -git developers to help solve the bug. - -With this option, git will replace all refnames, paths, blob contents, -commit and tag messages, names, and email addresses in the output with -anonymized data. Two instances of the same string will be replaced -equivalently (e.g., two commits with the same author will have the same -anonymized author in the output, but bear no resemblance to the original -author string). The relationship between commits, branches, and tags is -retained, as well as the commit timestamps (but the commit messages and -refnames bear no resemblance to the originals). The relative makeup of -the tree is retained (e.g., if you have a root tree with 10 files and 3 -trees, so will the output), but their names and the contents of the -files will be replaced. - -If you think you have found a git bug, you can start by exporting an -anonymized stream of the whole repository: - ---------------------------------------------------- -$ git fast-export --anonymize --all >anon-stream ---------------------------------------------------- - -Then confirm that the bug persists in a repository created from that -stream (many bugs will not, as they really do depend on the exact -repository contents): - ---------------------------------------------------- -$ git init anon-repo -$ cd anon-repo -$ git fast-import <../anon-stream -$ ... test your bug ... ---------------------------------------------------- - -If the anonymized repository shows the bug, it may be worth sharing -`anon-stream` along with a regular bug report. Note that the anonymized -stream compresses very well, so gzipping it is encouraged. If you want -to examine the stream to see that it does not contain any private data, -you can peruse it directly before sending. You may also want to try: - ---------------------------------------------------- -$ perl -pe 's/\d+/X/g' <anon-stream | sort -u | less ---------------------------------------------------- - -which shows all of the unique lines (with numbers converted to "X", to -collapse "User 0", "User 1", etc into "User X"). This produces a much -smaller output, and it is usually easy to quickly confirm that there is -no private data in the stream. - - -LIMITATIONS ------------ - -Since 'git fast-import' cannot tag trees, you will not be -able to export the linux.git repository completely, as it contains -a tag referencing a tree instead of a commit. - -SEE ALSO --------- -linkgit:git-fast-import[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-fast-import.txt b/third_party/git/Documentation/git-fast-import.txt deleted file mode 100644 index fad327aecc..0000000000 --- a/third_party/git/Documentation/git-fast-import.txt +++ /dev/null @@ -1,1508 +0,0 @@ -git-fast-import(1) -================== - -NAME ----- -git-fast-import - Backend for fast Git data importers - - -SYNOPSIS --------- -[verse] -frontend | 'git fast-import' [<options>] - -DESCRIPTION ------------ -This program is usually not what the end user wants to run directly. -Most end users want to use one of the existing frontend programs, -which parses a specific type of foreign source and feeds the contents -stored there to 'git fast-import'. - -fast-import reads a mixed command/data stream from standard input and -writes one or more packfiles directly into the current repository. -When EOF is received on standard input, fast import writes out -updated branch and tag refs, fully updating the current repository -with the newly imported data. - -The fast-import backend itself can import into an empty repository (one that -has already been initialized by 'git init') or incrementally -update an existing populated repository. Whether or not incremental -imports are supported from a particular foreign source depends on -the frontend program in use. - - -OPTIONS -------- - ---force:: - Force updating modified existing branches, even if doing - so would cause commits to be lost (as the new commit does - not contain the old commit). - ---quiet:: - Disable the output shown by --stats, making fast-import usually - be silent when it is successful. However, if the import stream - has directives intended to show user output (e.g. `progress` - directives), the corresponding messages will still be shown. - ---stats:: - Display some basic statistics about the objects fast-import has - created, the packfiles they were stored into, and the - memory used by fast-import during this run. Showing this output - is currently the default, but can be disabled with --quiet. - -Options for Frontends -~~~~~~~~~~~~~~~~~~~~~ - ---cat-blob-fd=<fd>:: - Write responses to `get-mark`, `cat-blob`, and `ls` queries to the - file descriptor <fd> instead of `stdout`. Allows `progress` - output intended for the end-user to be separated from other - output. - ---date-format=<fmt>:: - Specify the type of dates the frontend will supply to - fast-import within `author`, `committer` and `tagger` commands. - See ``Date Formats'' below for details about which formats - are supported, and their syntax. - ---done:: - Terminate with error if there is no `done` command at the end of - the stream. This option might be useful for detecting errors - that cause the frontend to terminate before it has started to - write a stream. - -Locations of Marks Files -~~~~~~~~~~~~~~~~~~~~~~~~ - ---export-marks=<file>:: - Dumps the internal marks table to <file> when complete. - Marks are written one per line as `:markid SHA-1`. - Frontends can use this file to validate imports after they - have been completed, or to save the marks table across - incremental runs. As <file> is only opened and truncated - at checkpoint (or completion) the same path can also be - safely given to --import-marks. - ---import-marks=<file>:: - Before processing any input, load the marks specified in - <file>. The input file must exist, must be readable, and - must use the same format as produced by --export-marks. - Multiple options may be supplied to import more than one - set of marks. If a mark is defined to different values, - the last file wins. - ---import-marks-if-exists=<file>:: - Like --import-marks but instead of erroring out, silently - skips the file if it does not exist. - ---[no-]relative-marks:: - After specifying --relative-marks the paths specified - with --import-marks= and --export-marks= are relative - to an internal directory in the current repository. - In git-fast-import this means that the paths are relative - to the .git/info/fast-import directory. However, other - importers may use a different location. -+ -Relative and non-relative marks may be combined by interweaving ---(no-)-relative-marks with the --(import|export)-marks= options. - -Performance and Compression Tuning -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - ---active-branches=<n>:: - Maximum number of branches to maintain active at once. - See ``Memory Utilization'' below for details. Default is 5. - ---big-file-threshold=<n>:: - Maximum size of a blob that fast-import will attempt to - create a delta for, expressed in bytes. The default is 512m - (512 MiB). Some importers may wish to lower this on systems - with constrained memory. - ---depth=<n>:: - Maximum delta depth, for blob and tree deltification. - Default is 50. - ---export-pack-edges=<file>:: - After creating a packfile, print a line of data to - <file> listing the filename of the packfile and the last - commit on each branch that was written to that packfile. - This information may be useful after importing projects - whose total object set exceeds the 4 GiB packfile limit, - as these commits can be used as edge points during calls - to 'git pack-objects'. - ---max-pack-size=<n>:: - Maximum size of each output packfile. - The default is unlimited. - -fastimport.unpackLimit:: - See linkgit:git-config[1] - -PERFORMANCE ------------ -The design of fast-import allows it to import large projects in a minimum -amount of memory usage and processing time. Assuming the frontend -is able to keep up with fast-import and feed it a constant stream of data, -import times for projects holding 10+ years of history and containing -100,000+ individual commits are generally completed in just 1-2 -hours on quite modest (~$2,000 USD) hardware. - -Most bottlenecks appear to be in foreign source data access (the -source just cannot extract revisions fast enough) or disk IO (fast-import -writes as fast as the disk will take the data). Imports will run -faster if the source data is stored on a different drive than the -destination Git repository (due to less IO contention). - - -DEVELOPMENT COST ----------------- -A typical frontend for fast-import tends to weigh in at approximately 200 -lines of Perl/Python/Ruby code. Most developers have been able to -create working importers in just a couple of hours, even though it -is their first exposure to fast-import, and sometimes even to Git. This is -an ideal situation, given that most conversion tools are throw-away -(use once, and never look back). - - -PARALLEL OPERATION ------------------- -Like 'git push' or 'git fetch', imports handled by fast-import are safe to -run alongside parallel `git repack -a -d` or `git gc` invocations, -or any other Git operation (including 'git prune', as loose objects -are never used by fast-import). - -fast-import does not lock the branch or tag refs it is actively importing. -After the import, during its ref update phase, fast-import tests each -existing branch ref to verify the update will be a fast-forward -update (the commit stored in the ref is contained in the new -history of the commit to be written). If the update is not a -fast-forward update, fast-import will skip updating that ref and instead -prints a warning message. fast-import will always attempt to update all -branch refs, and does not stop on the first failure. - -Branch updates can be forced with --force, but it's recommended that -this only be used on an otherwise quiet repository. Using --force -is not necessary for an initial import into an empty repository. - - -TECHNICAL DISCUSSION --------------------- -fast-import tracks a set of branches in memory. Any branch can be created -or modified at any point during the import process by sending a -`commit` command on the input stream. This design allows a frontend -program to process an unlimited number of branches simultaneously, -generating commits in the order they are available from the source -data. It also simplifies the frontend programs considerably. - -fast-import does not use or alter the current working directory, or any -file within it. (It does however update the current Git repository, -as referenced by `GIT_DIR`.) Therefore an import frontend may use -the working directory for its own purposes, such as extracting file -revisions from the foreign source. This ignorance of the working -directory also allows fast-import to run very quickly, as it does not -need to perform any costly file update operations when switching -between branches. - -INPUT FORMAT ------------- -With the exception of raw file data (which Git does not interpret) -the fast-import input format is text (ASCII) based. This text based -format simplifies development and debugging of frontend programs, -especially when a higher level language such as Perl, Python or -Ruby is being used. - -fast-import is very strict about its input. Where we say SP below we mean -*exactly* one space. Likewise LF means one (and only one) linefeed -and HT one (and only one) horizontal tab. -Supplying additional whitespace characters will cause unexpected -results, such as branch names or file names with leading or trailing -spaces in their name, or early termination of fast-import when it encounters -unexpected input. - -Stream Comments -~~~~~~~~~~~~~~~ -To aid in debugging frontends fast-import ignores any line that -begins with `#` (ASCII pound/hash) up to and including the line -ending `LF`. A comment line may contain any sequence of bytes -that does not contain an LF and therefore may be used to include -any detailed debugging information that might be specific to the -frontend and useful when inspecting a fast-import data stream. - -Date Formats -~~~~~~~~~~~~ -The following date formats are supported. A frontend should select -the format it will use for this import by passing the format name -in the --date-format=<fmt> command-line option. - -`raw`:: - This is the Git native format and is `<time> SP <offutc>`. - It is also fast-import's default format, if --date-format was - not specified. -+ -The time of the event is specified by `<time>` as the number of -seconds since the UNIX epoch (midnight, Jan 1, 1970, UTC) and is -written as an ASCII decimal integer. -+ -The local offset is specified by `<offutc>` as a positive or negative -offset from UTC. For example EST (which is 5 hours behind UTC) -would be expressed in `<tz>` by ``-0500'' while UTC is ``+0000''. -The local offset does not affect `<time>`; it is used only as an -advisement to help formatting routines display the timestamp. -+ -If the local offset is not available in the source material, use -``+0000'', or the most common local offset. For example many -organizations have a CVS repository which has only ever been accessed -by users who are located in the same location and time zone. In this -case a reasonable offset from UTC could be assumed. -+ -Unlike the `rfc2822` format, this format is very strict. Any -variation in formatting will cause fast-import to reject the value. - -`rfc2822`:: - This is the standard email format as described by RFC 2822. -+ -An example value is ``Tue Feb 6 11:22:18 2007 -0500''. The Git -parser is accurate, but a little on the lenient side. It is the -same parser used by 'git am' when applying patches -received from email. -+ -Some malformed strings may be accepted as valid dates. In some of -these cases Git will still be able to obtain the correct date from -the malformed string. There are also some types of malformed -strings which Git will parse wrong, and yet consider valid. -Seriously malformed strings will be rejected. -+ -Unlike the `raw` format above, the time zone/UTC offset information -contained in an RFC 2822 date string is used to adjust the date -value to UTC prior to storage. Therefore it is important that -this information be as accurate as possible. -+ -If the source material uses RFC 2822 style dates, -the frontend should let fast-import handle the parsing and conversion -(rather than attempting to do it itself) as the Git parser has -been well tested in the wild. -+ -Frontends should prefer the `raw` format if the source material -already uses UNIX-epoch format, can be coaxed to give dates in that -format, or its format is easily convertible to it, as there is no -ambiguity in parsing. - -`now`:: - Always use the current time and time zone. The literal - `now` must always be supplied for `<when>`. -+ -This is a toy format. The current time and time zone of this system -is always copied into the identity string at the time it is being -created by fast-import. There is no way to specify a different time or -time zone. -+ -This particular format is supplied as it's short to implement and -may be useful to a process that wants to create a new commit -right now, without needing to use a working directory or -'git update-index'. -+ -If separate `author` and `committer` commands are used in a `commit` -the timestamps may not match, as the system clock will be polled -twice (once for each command). The only way to ensure that both -author and committer identity information has the same timestamp -is to omit `author` (thus copying from `committer`) or to use a -date format other than `now`. - -Commands -~~~~~~~~ -fast-import accepts several commands to update the current repository -and control the current import process. More detailed discussion -(with examples) of each command follows later. - -`commit`:: - Creates a new branch or updates an existing branch by - creating a new commit and updating the branch to point at - the newly created commit. - -`tag`:: - Creates an annotated tag object from an existing commit or - branch. Lightweight tags are not supported by this command, - as they are not recommended for recording meaningful points - in time. - -`reset`:: - Reset an existing branch (or a new branch) to a specific - revision. This command must be used to change a branch to - a specific revision without making a commit on it. - -`blob`:: - Convert raw file data into a blob, for future use in a - `commit` command. This command is optional and is not - needed to perform an import. - -`checkpoint`:: - Forces fast-import to close the current packfile, generate its - unique SHA-1 checksum and index, and start a new packfile. - This command is optional and is not needed to perform - an import. - -`progress`:: - Causes fast-import to echo the entire line to its own - standard output. This command is optional and is not needed - to perform an import. - -`done`:: - Marks the end of the stream. This command is optional - unless the `done` feature was requested using the - `--done` command-line option or `feature done` command. - -`get-mark`:: - Causes fast-import to print the SHA-1 corresponding to a mark - to the file descriptor set with `--cat-blob-fd`, or `stdout` if - unspecified. - -`cat-blob`:: - Causes fast-import to print a blob in 'cat-file --batch' - format to the file descriptor set with `--cat-blob-fd` or - `stdout` if unspecified. - -`ls`:: - Causes fast-import to print a line describing a directory - entry in 'ls-tree' format to the file descriptor set with - `--cat-blob-fd` or `stdout` if unspecified. - -`feature`:: - Enable the specified feature. This requires that fast-import - supports the specified feature, and aborts if it does not. - -`option`:: - Specify any of the options listed under OPTIONS that do not - change stream semantic to suit the frontend's needs. This - command is optional and is not needed to perform an import. - -`commit` -~~~~~~~~ -Create or update a branch with a new commit, recording one logical -change to the project. - -.... - 'commit' SP <ref> LF - mark? - original-oid? - ('author' (SP <name>)? SP LT <email> GT SP <when> LF)? - 'committer' (SP <name>)? SP LT <email> GT SP <when> LF - ('encoding' SP <encoding>)? - data - ('from' SP <commit-ish> LF)? - ('merge' SP <commit-ish> LF)? - (filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)* - LF? -.... - -where `<ref>` is the name of the branch to make the commit on. -Typically branch names are prefixed with `refs/heads/` in -Git, so importing the CVS branch symbol `RELENG-1_0` would use -`refs/heads/RELENG-1_0` for the value of `<ref>`. The value of -`<ref>` must be a valid refname in Git. As `LF` is not valid in -a Git refname, no quoting or escaping syntax is supported here. - -A `mark` command may optionally appear, requesting fast-import to save a -reference to the newly created commit for future use by the frontend -(see below for format). It is very common for frontends to mark -every commit they create, thereby allowing future branch creation -from any imported commit. - -The `data` command following `committer` must supply the commit -message (see below for `data` command syntax). To import an empty -commit message use a 0 length data. Commit messages are free-form -and are not interpreted by Git. Currently they must be encoded in -UTF-8, as fast-import does not permit other encodings to be specified. - -Zero or more `filemodify`, `filedelete`, `filecopy`, `filerename`, -`filedeleteall` and `notemodify` commands -may be included to update the contents of the branch prior to -creating the commit. These commands may be supplied in any order. -However it is recommended that a `filedeleteall` command precede -all `filemodify`, `filecopy`, `filerename` and `notemodify` commands in -the same commit, as `filedeleteall` wipes the branch clean (see below). - -The `LF` after the command is optional (it used to be required). Note -that for reasons of backward compatibility, if the commit ends with a -`data` command (i.e. it has no `from`, `merge`, `filemodify`, -`filedelete`, `filecopy`, `filerename`, `filedeleteall` or -`notemodify` commands) then two `LF` commands may appear at the end of -the command instead of just one. - -`author` -^^^^^^^^ -An `author` command may optionally appear, if the author information -might differ from the committer information. If `author` is omitted -then fast-import will automatically use the committer's information for -the author portion of the commit. See below for a description of -the fields in `author`, as they are identical to `committer`. - -`committer` -^^^^^^^^^^^ -The `committer` command indicates who made this commit, and when -they made it. - -Here `<name>` is the person's display name (for example -``Com M Itter'') and `<email>` is the person's email address -(``\cm@example.com''). `LT` and `GT` are the literal less-than (\x3c) -and greater-than (\x3e) symbols. These are required to delimit -the email address from the other fields in the line. Note that -`<name>` and `<email>` are free-form and may contain any sequence -of bytes, except `LT`, `GT` and `LF`. `<name>` is typically UTF-8 encoded. - -The time of the change is specified by `<when>` using the date format -that was selected by the --date-format=<fmt> command-line option. -See ``Date Formats'' above for the set of supported formats, and -their syntax. - -`encoding` -^^^^^^^^^^ -The optional `encoding` command indicates the encoding of the commit -message. Most commits are UTF-8 and the encoding is omitted, but this -allows importing commit messages into git without first reencoding them. - -`from` -^^^^^^ -The `from` command is used to specify the commit to initialize -this branch from. This revision will be the first ancestor of the -new commit. The state of the tree built at this commit will begin -with the state at the `from` commit, and be altered by the content -modifications in this commit. - -Omitting the `from` command in the first commit of a new branch -will cause fast-import to create that commit with no ancestor. This -tends to be desired only for the initial commit of a project. -If the frontend creates all files from scratch when making a new -branch, a `merge` command may be used instead of `from` to start -the commit with an empty tree. -Omitting the `from` command on existing branches is usually desired, -as the current commit on that branch is automatically assumed to -be the first ancestor of the new commit. - -As `LF` is not valid in a Git refname or SHA-1 expression, no -quoting or escaping syntax is supported within `<commit-ish>`. - -Here `<commit-ish>` is any of the following: - -* The name of an existing branch already in fast-import's internal branch - table. If fast-import doesn't know the name, it's treated as a SHA-1 - expression. - -* A mark reference, `:<idnum>`, where `<idnum>` is the mark number. -+ -The reason fast-import uses `:` to denote a mark reference is this character -is not legal in a Git branch name. The leading `:` makes it easy -to distinguish between the mark 42 (`:42`) and the branch 42 (`42` -or `refs/heads/42`), or an abbreviated SHA-1 which happened to -consist only of base-10 digits. -+ -Marks must be declared (via `mark`) before they can be used. - -* A complete 40 byte or abbreviated commit SHA-1 in hex. - -* Any valid Git SHA-1 expression that resolves to a commit. See - ``SPECIFYING REVISIONS'' in linkgit:gitrevisions[7] for details. - -* The special null SHA-1 (40 zeros) specifies that the branch is to be - removed. - -The special case of restarting an incremental import from the -current branch value should be written as: ----- - from refs/heads/branch^0 ----- -The `^0` suffix is necessary as fast-import does not permit a branch to -start from itself, and the branch is created in memory before the -`from` command is even read from the input. Adding `^0` will force -fast-import to resolve the commit through Git's revision parsing library, -rather than its internal branch table, thereby loading in the -existing value of the branch. - -`merge` -^^^^^^^ -Includes one additional ancestor commit. The additional ancestry -link does not change the way the tree state is built at this commit. -If the `from` command is -omitted when creating a new branch, the first `merge` commit will be -the first ancestor of the current commit, and the branch will start -out with no files. An unlimited number of `merge` commands per -commit are permitted by fast-import, thereby establishing an n-way merge. - -Here `<commit-ish>` is any of the commit specification expressions -also accepted by `from` (see above). - -`filemodify` -^^^^^^^^^^^^ -Included in a `commit` command to add a new file or change the -content of an existing file. This command has two different means -of specifying the content of the file. - -External data format:: - The data content for the file was already supplied by a prior - `blob` command. The frontend just needs to connect it. -+ -.... - 'M' SP <mode> SP <dataref> SP <path> LF -.... -+ -Here usually `<dataref>` must be either a mark reference (`:<idnum>`) -set by a prior `blob` command, or a full 40-byte SHA-1 of an -existing Git blob object. If `<mode>` is `040000`` then -`<dataref>` must be the full 40-byte SHA-1 of an existing -Git tree object or a mark reference set with `--import-marks`. - -Inline data format:: - The data content for the file has not been supplied yet. - The frontend wants to supply it as part of this modify - command. -+ -.... - 'M' SP <mode> SP 'inline' SP <path> LF - data -.... -+ -See below for a detailed description of the `data` command. - -In both formats `<mode>` is the type of file entry, specified -in octal. Git only supports the following modes: - -* `100644` or `644`: A normal (not-executable) file. The majority - of files in most projects use this mode. If in doubt, this is - what you want. -* `100755` or `755`: A normal, but executable, file. -* `120000`: A symlink, the content of the file will be the link target. -* `160000`: A gitlink, SHA-1 of the object refers to a commit in - another repository. Git links can only be specified by SHA or through - a commit mark. They are used to implement submodules. -* `040000`: A subdirectory. Subdirectories can only be specified by - SHA or through a tree mark set with `--import-marks`. - -In both formats `<path>` is the complete path of the file to be added -(if not already existing) or modified (if already existing). - -A `<path>` string must use UNIX-style directory separators (forward -slash `/`), may contain any byte other than `LF`, and must not -start with double quote (`"`). - -A path can use C-style string quoting; this is accepted in all cases -and mandatory if the filename starts with double quote or contains -`LF`. In C-style quoting, the complete name should be surrounded with -double quotes, and any `LF`, backslash, or double quote characters -must be escaped by preceding them with a backslash (e.g., -`"path/with\n, \\ and \" in it"`). - -The value of `<path>` must be in canonical form. That is it must not: - -* contain an empty directory component (e.g. `foo//bar` is invalid), -* end with a directory separator (e.g. `foo/` is invalid), -* start with a directory separator (e.g. `/foo` is invalid), -* contain the special component `.` or `..` (e.g. `foo/./bar` and - `foo/../bar` are invalid). - -The root of the tree can be represented by an empty string as `<path>`. - -It is recommended that `<path>` always be encoded using UTF-8. - -`filedelete` -^^^^^^^^^^^^ -Included in a `commit` command to remove a file or recursively -delete an entire directory from the branch. If the file or directory -removal makes its parent directory empty, the parent directory will -be automatically removed too. This cascades up the tree until the -first non-empty directory or the root is reached. - -.... - 'D' SP <path> LF -.... - -here `<path>` is the complete path of the file or subdirectory to -be removed from the branch. -See `filemodify` above for a detailed description of `<path>`. - -`filecopy` -^^^^^^^^^^ -Recursively copies an existing file or subdirectory to a different -location within the branch. The existing file or directory must -exist. If the destination exists it will be completely replaced -by the content copied from the source. - -.... - 'C' SP <path> SP <path> LF -.... - -here the first `<path>` is the source location and the second -`<path>` is the destination. See `filemodify` above for a detailed -description of what `<path>` may look like. To use a source path -that contains SP the path must be quoted. - -A `filecopy` command takes effect immediately. Once the source -location has been copied to the destination any future commands -applied to the source location will not impact the destination of -the copy. - -`filerename` -^^^^^^^^^^^^ -Renames an existing file or subdirectory to a different location -within the branch. The existing file or directory must exist. If -the destination exists it will be replaced by the source directory. - -.... - 'R' SP <path> SP <path> LF -.... - -here the first `<path>` is the source location and the second -`<path>` is the destination. See `filemodify` above for a detailed -description of what `<path>` may look like. To use a source path -that contains SP the path must be quoted. - -A `filerename` command takes effect immediately. Once the source -location has been renamed to the destination any future commands -applied to the source location will create new files there and not -impact the destination of the rename. - -Note that a `filerename` is the same as a `filecopy` followed by a -`filedelete` of the source location. There is a slight performance -advantage to using `filerename`, but the advantage is so small -that it is never worth trying to convert a delete/add pair in -source material into a rename for fast-import. This `filerename` -command is provided just to simplify frontends that already have -rename information and don't want bother with decomposing it into a -`filecopy` followed by a `filedelete`. - -`filedeleteall` -^^^^^^^^^^^^^^^ -Included in a `commit` command to remove all files (and also all -directories) from the branch. This command resets the internal -branch structure to have no files in it, allowing the frontend -to subsequently add all interesting files from scratch. - -.... - 'deleteall' LF -.... - -This command is extremely useful if the frontend does not know -(or does not care to know) what files are currently on the branch, -and therefore cannot generate the proper `filedelete` commands to -update the content. - -Issuing a `filedeleteall` followed by the needed `filemodify` -commands to set the correct content will produce the same results -as sending only the needed `filemodify` and `filedelete` commands. -The `filedeleteall` approach may however require fast-import to use slightly -more memory per active branch (less than 1 MiB for even most large -projects); so frontends that can easily obtain only the affected -paths for a commit are encouraged to do so. - -`notemodify` -^^^^^^^^^^^^ -Included in a `commit` `<notes_ref>` command to add a new note -annotating a `<commit-ish>` or change this annotation contents. -Internally it is similar to filemodify 100644 on `<commit-ish>` -path (maybe split into subdirectories). It's not advised to -use any other commands to write to the `<notes_ref>` tree except -`filedeleteall` to delete all existing notes in this tree. -This command has two different means of specifying the content -of the note. - -External data format:: - The data content for the note was already supplied by a prior - `blob` command. The frontend just needs to connect it to the - commit that is to be annotated. -+ -.... - 'N' SP <dataref> SP <commit-ish> LF -.... -+ -Here `<dataref>` can be either a mark reference (`:<idnum>`) -set by a prior `blob` command, or a full 40-byte SHA-1 of an -existing Git blob object. - -Inline data format:: - The data content for the note has not been supplied yet. - The frontend wants to supply it as part of this modify - command. -+ -.... - 'N' SP 'inline' SP <commit-ish> LF - data -.... -+ -See below for a detailed description of the `data` command. - -In both formats `<commit-ish>` is any of the commit specification -expressions also accepted by `from` (see above). - -`mark` -~~~~~~ -Arranges for fast-import to save a reference to the current object, allowing -the frontend to recall this object at a future point in time, without -knowing its SHA-1. Here the current object is the object creation -command the `mark` command appears within. This can be `commit`, -`tag`, and `blob`, but `commit` is the most common usage. - -.... - 'mark' SP ':' <idnum> LF -.... - -where `<idnum>` is the number assigned by the frontend to this mark. -The value of `<idnum>` is expressed as an ASCII decimal integer. -The value 0 is reserved and cannot be used as -a mark. Only values greater than or equal to 1 may be used as marks. - -New marks are created automatically. Existing marks can be moved -to another object simply by reusing the same `<idnum>` in another -`mark` command. - -`original-oid` -~~~~~~~~~~~~~~ -Provides the name of the object in the original source control system. -fast-import will simply ignore this directive, but filter processes -which operate on and modify the stream before feeding to fast-import -may have uses for this information - -.... - 'original-oid' SP <object-identifier> LF -.... - -where `<object-identifer>` is any string not containing LF. - -`tag` -~~~~~ -Creates an annotated tag referring to a specific commit. To create -lightweight (non-annotated) tags see the `reset` command below. - -.... - 'tag' SP <name> LF - 'from' SP <commit-ish> LF - original-oid? - 'tagger' (SP <name>)? SP LT <email> GT SP <when> LF - data -.... - -where `<name>` is the name of the tag to create. - -Tag names are automatically prefixed with `refs/tags/` when stored -in Git, so importing the CVS branch symbol `RELENG-1_0-FINAL` would -use just `RELENG-1_0-FINAL` for `<name>`, and fast-import will write the -corresponding ref as `refs/tags/RELENG-1_0-FINAL`. - -The value of `<name>` must be a valid refname in Git and therefore -may contain forward slashes. As `LF` is not valid in a Git refname, -no quoting or escaping syntax is supported here. - -The `from` command is the same as in the `commit` command; see -above for details. - -The `tagger` command uses the same format as `committer` within -`commit`; again see above for details. - -The `data` command following `tagger` must supply the annotated tag -message (see below for `data` command syntax). To import an empty -tag message use a 0 length data. Tag messages are free-form and are -not interpreted by Git. Currently they must be encoded in UTF-8, -as fast-import does not permit other encodings to be specified. - -Signing annotated tags during import from within fast-import is not -supported. Trying to include your own PGP/GPG signature is not -recommended, as the frontend does not (easily) have access to the -complete set of bytes which normally goes into such a signature. -If signing is required, create lightweight tags from within fast-import with -`reset`, then create the annotated versions of those tags offline -with the standard 'git tag' process. - -`reset` -~~~~~~~ -Creates (or recreates) the named branch, optionally starting from -a specific revision. The reset command allows a frontend to issue -a new `from` command for an existing branch, or to create a new -branch from an existing commit without creating a new commit. - -.... - 'reset' SP <ref> LF - ('from' SP <commit-ish> LF)? - LF? -.... - -For a detailed description of `<ref>` and `<commit-ish>` see above -under `commit` and `from`. - -The `LF` after the command is optional (it used to be required). - -The `reset` command can also be used to create lightweight -(non-annotated) tags. For example: - -==== - reset refs/tags/938 - from :938 -==== - -would create the lightweight tag `refs/tags/938` referring to -whatever commit mark `:938` references. - -`blob` -~~~~~~ -Requests writing one file revision to the packfile. The revision -is not connected to any commit; this connection must be formed in -a subsequent `commit` command by referencing the blob through an -assigned mark. - -.... - 'blob' LF - mark? - original-oid? - data -.... - -The mark command is optional here as some frontends have chosen -to generate the Git SHA-1 for the blob on their own, and feed that -directly to `commit`. This is typically more work than it's worth -however, as marks are inexpensive to store and easy to use. - -`data` -~~~~~~ -Supplies raw data (for use as blob/file content, commit messages, or -annotated tag messages) to fast-import. Data can be supplied using an exact -byte count or delimited with a terminating line. Real frontends -intended for production-quality conversions should always use the -exact byte count format, as it is more robust and performs better. -The delimited format is intended primarily for testing fast-import. - -Comment lines appearing within the `<raw>` part of `data` commands -are always taken to be part of the body of the data and are therefore -never ignored by fast-import. This makes it safe to import any -file/message content whose lines might start with `#`. - -Exact byte count format:: - The frontend must specify the number of bytes of data. -+ -.... - 'data' SP <count> LF - <raw> LF? -.... -+ -where `<count>` is the exact number of bytes appearing within -`<raw>`. The value of `<count>` is expressed as an ASCII decimal -integer. The `LF` on either side of `<raw>` is not -included in `<count>` and will not be included in the imported data. -+ -The `LF` after `<raw>` is optional (it used to be required) but -recommended. Always including it makes debugging a fast-import -stream easier as the next command always starts in column 0 -of the next line, even if `<raw>` did not end with an `LF`. - -Delimited format:: - A delimiter string is used to mark the end of the data. - fast-import will compute the length by searching for the delimiter. - This format is primarily useful for testing and is not - recommended for real data. -+ -.... - 'data' SP '<<' <delim> LF - <raw> LF - <delim> LF - LF? -.... -+ -where `<delim>` is the chosen delimiter string. The string `<delim>` -must not appear on a line by itself within `<raw>`, as otherwise -fast-import will think the data ends earlier than it really does. The `LF` -immediately trailing `<raw>` is part of `<raw>`. This is one of -the limitations of the delimited format, it is impossible to supply -a data chunk which does not have an LF as its last byte. -+ -The `LF` after `<delim> LF` is optional (it used to be required). - -`checkpoint` -~~~~~~~~~~~~ -Forces fast-import to close the current packfile, start a new one, and to -save out all current branch refs, tags and marks. - -.... - 'checkpoint' LF - LF? -.... - -Note that fast-import automatically switches packfiles when the current -packfile reaches --max-pack-size, or 4 GiB, whichever limit is -smaller. During an automatic packfile switch fast-import does not update -the branch refs, tags or marks. - -As a `checkpoint` can require a significant amount of CPU time and -disk IO (to compute the overall pack SHA-1 checksum, generate the -corresponding index file, and update the refs) it can easily take -several minutes for a single `checkpoint` command to complete. - -Frontends may choose to issue checkpoints during extremely large -and long running imports, or when they need to allow another Git -process access to a branch. However given that a 30 GiB Subversion -repository can be loaded into Git through fast-import in about 3 hours, -explicit checkpointing may not be necessary. - -The `LF` after the command is optional (it used to be required). - -`progress` -~~~~~~~~~~ -Causes fast-import to print the entire `progress` line unmodified to -its standard output channel (file descriptor 1) when the command is -processed from the input stream. The command otherwise has no impact -on the current import, or on any of fast-import's internal state. - -.... - 'progress' SP <any> LF - LF? -.... - -The `<any>` part of the command may contain any sequence of bytes -that does not contain `LF`. The `LF` after the command is optional. -Callers may wish to process the output through a tool such as sed to -remove the leading part of the line, for example: - -==== - frontend | git fast-import | sed 's/^progress //' -==== - -Placing a `progress` command immediately after a `checkpoint` will -inform the reader when the `checkpoint` has been completed and it -can safely access the refs that fast-import updated. - -`get-mark` -~~~~~~~~~~ -Causes fast-import to print the SHA-1 corresponding to a mark to -stdout or to the file descriptor previously arranged with the -`--cat-blob-fd` argument. The command otherwise has no impact on the -current import; its purpose is to retrieve SHA-1s that later commits -might want to refer to in their commit messages. - -.... - 'get-mark' SP ':' <idnum> LF -.... - -See ``Responses To Commands'' below for details about how to read -this output safely. - -`cat-blob` -~~~~~~~~~~ -Causes fast-import to print a blob to a file descriptor previously -arranged with the `--cat-blob-fd` argument. The command otherwise -has no impact on the current import; its main purpose is to -retrieve blobs that may be in fast-import's memory but not -accessible from the target repository. - -.... - 'cat-blob' SP <dataref> LF -.... - -The `<dataref>` can be either a mark reference (`:<idnum>`) -set previously or a full 40-byte SHA-1 of a Git blob, preexisting or -ready to be written. - -Output uses the same format as `git cat-file --batch`: - -==== - <sha1> SP 'blob' SP <size> LF - <contents> LF -==== - -This command can be used where a `filemodify` directive can appear, -allowing it to be used in the middle of a commit. For a `filemodify` -using an inline directive, it can also appear right before the `data` -directive. - -See ``Responses To Commands'' below for details about how to read -this output safely. - -`ls` -~~~~ -Prints information about the object at a path to a file descriptor -previously arranged with the `--cat-blob-fd` argument. This allows -printing a blob from the active commit (with `cat-blob`) or copying a -blob or tree from a previous commit for use in the current one (with -`filemodify`). - -The `ls` command can also be used where a `filemodify` directive can -appear, allowing it to be used in the middle of a commit. - -Reading from the active commit:: - This form can only be used in the middle of a `commit`. - The path names a directory entry within fast-import's - active commit. The path must be quoted in this case. -+ -.... - 'ls' SP <path> LF -.... - -Reading from a named tree:: - The `<dataref>` can be a mark reference (`:<idnum>`) or the - full 40-byte SHA-1 of a Git tag, commit, or tree object, - preexisting or waiting to be written. - The path is relative to the top level of the tree - named by `<dataref>`. -+ -.... - 'ls' SP <dataref> SP <path> LF -.... - -See `filemodify` above for a detailed description of `<path>`. - -Output uses the same format as `git ls-tree <tree> -- <path>`: - -==== - <mode> SP ('blob' | 'tree' | 'commit') SP <dataref> HT <path> LF -==== - -The <dataref> represents the blob, tree, or commit object at <path> -and can be used in later 'get-mark', 'cat-blob', 'filemodify', or -'ls' commands. - -If there is no file or subtree at that path, 'git fast-import' will -instead report - -==== - missing SP <path> LF -==== - -See ``Responses To Commands'' below for details about how to read -this output safely. - -`feature` -~~~~~~~~~ -Require that fast-import supports the specified feature, or abort if -it does not. - -.... - 'feature' SP <feature> ('=' <argument>)? LF -.... - -The <feature> part of the command may be any one of the following: - -date-format:: -export-marks:: -relative-marks:: -no-relative-marks:: -force:: - Act as though the corresponding command-line option with - a leading `--` was passed on the command line - (see OPTIONS, above). - -import-marks:: -import-marks-if-exists:: - Like --import-marks except in two respects: first, only one - "feature import-marks" or "feature import-marks-if-exists" - command is allowed per stream; second, an --import-marks= - or --import-marks-if-exists command-line option overrides - any of these "feature" commands in the stream; third, - "feature import-marks-if-exists" like a corresponding - command-line option silently skips a nonexistent file. - -get-mark:: -cat-blob:: -ls:: - Require that the backend support the 'get-mark', 'cat-blob', - or 'ls' command respectively. - Versions of fast-import not supporting the specified command - will exit with a message indicating so. - This lets the import error out early with a clear message, - rather than wasting time on the early part of an import - before the unsupported command is detected. - -notes:: - Require that the backend support the 'notemodify' (N) - subcommand to the 'commit' command. - Versions of fast-import not supporting notes will exit - with a message indicating so. - -done:: - Error out if the stream ends without a 'done' command. - Without this feature, errors causing the frontend to end - abruptly at a convenient point in the stream can go - undetected. This may occur, for example, if an import - front end dies in mid-operation without emitting SIGTERM - or SIGKILL at its subordinate git fast-import instance. - -`option` -~~~~~~~~ -Processes the specified option so that git fast-import behaves in a -way that suits the frontend's needs. -Note that options specified by the frontend are overridden by any -options the user may specify to git fast-import itself. - -.... - 'option' SP <option> LF -.... - -The `<option>` part of the command may contain any of the options -listed in the OPTIONS section that do not change import semantics, -without the leading `--` and is treated in the same way. - -Option commands must be the first commands on the input (not counting -feature commands), to give an option command after any non-option -command is an error. - -The following command-line options change import semantics and may therefore -not be passed as option: - -* date-format -* import-marks -* export-marks -* cat-blob-fd -* force - -`done` -~~~~~~ -If the `done` feature is not in use, treated as if EOF was read. -This can be used to tell fast-import to finish early. - -If the `--done` command-line option or `feature done` command is -in use, the `done` command is mandatory and marks the end of the -stream. - -RESPONSES TO COMMANDS ---------------------- -New objects written by fast-import are not available immediately. -Most fast-import commands have no visible effect until the next -checkpoint (or completion). The frontend can send commands to -fill fast-import's input pipe without worrying about how quickly -they will take effect, which improves performance by simplifying -scheduling. - -For some frontends, though, it is useful to be able to read back -data from the current repository as it is being updated (for -example when the source material describes objects in terms of -patches to be applied to previously imported objects). This can -be accomplished by connecting the frontend and fast-import via -bidirectional pipes: - -==== - mkfifo fast-import-output - frontend <fast-import-output | - git fast-import >fast-import-output -==== - -A frontend set up this way can use `progress`, `get-mark`, `ls`, and -`cat-blob` commands to read information from the import in progress. - -To avoid deadlock, such frontends must completely consume any -pending output from `progress`, `ls`, `get-mark`, and `cat-blob` before -performing writes to fast-import that might block. - -CRASH REPORTS -------------- -If fast-import is supplied invalid input it will terminate with a -non-zero exit status and create a crash report in the top level of -the Git repository it was importing into. Crash reports contain -a snapshot of the internal fast-import state as well as the most -recent commands that lead up to the crash. - -All recent commands (including stream comments, file changes and -progress commands) are shown in the command history within the crash -report, but raw file data and commit messages are excluded from the -crash report. This exclusion saves space within the report file -and reduces the amount of buffering that fast-import must perform -during execution. - -After writing a crash report fast-import will close the current -packfile and export the marks table. This allows the frontend -developer to inspect the repository state and resume the import from -the point where it crashed. The modified branches and tags are not -updated during a crash, as the import did not complete successfully. -Branch and tag information can be found in the crash report and -must be applied manually if the update is needed. - -An example crash: - -==== - $ cat >in <<END_OF_INPUT - # my very first test commit - commit refs/heads/master - committer Shawn O. Pearce <spearce> 19283 -0400 - # who is that guy anyway? - data <<EOF - this is my commit - EOF - M 644 inline .gitignore - data <<EOF - .gitignore - EOF - M 777 inline bob - END_OF_INPUT - - $ git fast-import <in - fatal: Corrupt mode: M 777 inline bob - fast-import: dumping crash report to .git/fast_import_crash_8434 - - $ cat .git/fast_import_crash_8434 - fast-import crash report: - fast-import process: 8434 - parent process : 1391 - at Sat Sep 1 00:58:12 2007 - - fatal: Corrupt mode: M 777 inline bob - - Most Recent Commands Before Crash - --------------------------------- - # my very first test commit - commit refs/heads/master - committer Shawn O. Pearce <spearce> 19283 -0400 - # who is that guy anyway? - data <<EOF - M 644 inline .gitignore - data <<EOF - * M 777 inline bob - - Active Branch LRU - ----------------- - active_branches = 1 cur, 5 max - - pos clock name - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - 1) 0 refs/heads/master - - Inactive Branches - ----------------- - refs/heads/master: - status : active loaded dirty - tip commit : 0000000000000000000000000000000000000000 - old tree : 0000000000000000000000000000000000000000 - cur tree : 0000000000000000000000000000000000000000 - commit clock: 0 - last pack : - - - ------------------- - END OF CRASH REPORT -==== - -TIPS AND TRICKS ---------------- -The following tips and tricks have been collected from various -users of fast-import, and are offered here as suggestions. - -Use One Mark Per Commit -~~~~~~~~~~~~~~~~~~~~~~~ -When doing a repository conversion, use a unique mark per commit -(`mark :<n>`) and supply the --export-marks option on the command -line. fast-import will dump a file which lists every mark and the Git -object SHA-1 that corresponds to it. If the frontend can tie -the marks back to the source repository, it is easy to verify the -accuracy and completeness of the import by comparing each Git -commit to the corresponding source revision. - -Coming from a system such as Perforce or Subversion this should be -quite simple, as the fast-import mark can also be the Perforce changeset -number or the Subversion revision number. - -Freely Skip Around Branches -~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Don't bother trying to optimize the frontend to stick to one branch -at a time during an import. Although doing so might be slightly -faster for fast-import, it tends to increase the complexity of the frontend -code considerably. - -The branch LRU builtin to fast-import tends to behave very well, and the -cost of activating an inactive branch is so low that bouncing around -between branches has virtually no impact on import performance. - -Handling Renames -~~~~~~~~~~~~~~~~ -When importing a renamed file or directory, simply delete the old -name(s) and modify the new name(s) during the corresponding commit. -Git performs rename detection after-the-fact, rather than explicitly -during a commit. - -Use Tag Fixup Branches -~~~~~~~~~~~~~~~~~~~~~~ -Some other SCM systems let the user create a tag from multiple -files which are not from the same commit/changeset. Or to create -tags which are a subset of the files available in the repository. - -Importing these tags as-is in Git is impossible without making at -least one commit which ``fixes up'' the files to match the content -of the tag. Use fast-import's `reset` command to reset a dummy branch -outside of your normal branch space to the base commit for the tag, -then commit one or more file fixup commits, and finally tag the -dummy branch. - -For example since all normal branches are stored under `refs/heads/` -name the tag fixup branch `TAG_FIXUP`. This way it is impossible for -the fixup branch used by the importer to have namespace conflicts -with real branches imported from the source (the name `TAG_FIXUP` -is not `refs/heads/TAG_FIXUP`). - -When committing fixups, consider using `merge` to connect the -commit(s) which are supplying file revisions to the fixup branch. -Doing so will allow tools such as 'git blame' to track -through the real commit history and properly annotate the source -files. - -After fast-import terminates the frontend will need to do `rm .git/TAG_FIXUP` -to remove the dummy branch. - -Import Now, Repack Later -~~~~~~~~~~~~~~~~~~~~~~~~ -As soon as fast-import completes the Git repository is completely valid -and ready for use. Typically this takes only a very short time, -even for considerably large projects (100,000+ commits). - -However repacking the repository is necessary to improve data -locality and access performance. It can also take hours on extremely -large projects (especially if -f and a large --window parameter is -used). Since repacking is safe to run alongside readers and writers, -run the repack in the background and let it finish when it finishes. -There is no reason to wait to explore your new Git project! - -If you choose to wait for the repack, don't try to run benchmarks -or performance tests until repacking is completed. fast-import outputs -suboptimal packfiles that are simply never seen in real use -situations. - -Repacking Historical Data -~~~~~~~~~~~~~~~~~~~~~~~~~ -If you are repacking very old imported data (e.g. older than the -last year), consider expending some extra CPU time and supplying ---window=50 (or higher) when you run 'git repack'. -This will take longer, but will also produce a smaller packfile. -You only need to expend the effort once, and everyone using your -project will benefit from the smaller repository. - -Include Some Progress Messages -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Every once in a while have your frontend emit a `progress` message -to fast-import. The contents of the messages are entirely free-form, -so one suggestion would be to output the current month and year -each time the current commit date moves into the next month. -Your users will feel better knowing how much of the data stream -has been processed. - - -PACKFILE OPTIMIZATION ---------------------- -When packing a blob fast-import always attempts to deltify against the last -blob written. Unless specifically arranged for by the frontend, -this will probably not be a prior version of the same file, so the -generated delta will not be the smallest possible. The resulting -packfile will be compressed, but will not be optimal. - -Frontends which have efficient access to all revisions of a -single file (for example reading an RCS/CVS ,v file) can choose -to supply all revisions of that file as a sequence of consecutive -`blob` commands. This allows fast-import to deltify the different file -revisions against each other, saving space in the final packfile. -Marks can be used to later identify individual file revisions during -a sequence of `commit` commands. - -The packfile(s) created by fast-import do not encourage good disk access -patterns. This is caused by fast-import writing the data in the order -it is received on standard input, while Git typically organizes -data within packfiles to make the most recent (current tip) data -appear before historical data. Git also clusters commits together, -speeding up revision traversal through better cache locality. - -For this reason it is strongly recommended that users repack the -repository with `git repack -a -d` after fast-import completes, allowing -Git to reorganize the packfiles for faster data access. If blob -deltas are suboptimal (see above) then also adding the `-f` option -to force recomputation of all deltas can significantly reduce the -final packfile size (30-50% smaller can be quite typical). - -Instead of running `git repack` you can also run `git gc ---aggressive`, which will also optimize other things after an import -(e.g. pack loose refs). As noted in the "AGGRESSIVE" section in -linkgit:git-gc[1] the `--aggressive` option will find new deltas with -the `-f` option to linkgit:git-repack[1]. For the reasons elaborated -on above using `--aggressive` after a fast-import is one of the few -cases where it's known to be worthwhile. - -MEMORY UTILIZATION ------------------- -There are a number of factors which affect how much memory fast-import -requires to perform an import. Like critical sections of core -Git, fast-import uses its own memory allocators to amortize any overheads -associated with malloc. In practice fast-import tends to amortize any -malloc overheads to 0, due to its use of large block allocations. - -per object -~~~~~~~~~~ -fast-import maintains an in-memory structure for every object written in -this execution. On a 32 bit system the structure is 32 bytes, -on a 64 bit system the structure is 40 bytes (due to the larger -pointer sizes). Objects in the table are not deallocated until -fast-import terminates. Importing 2 million objects on a 32 bit system -will require approximately 64 MiB of memory. - -The object table is actually a hashtable keyed on the object name -(the unique SHA-1). This storage configuration allows fast-import to reuse -an existing or already written object and avoid writing duplicates -to the output packfile. Duplicate blobs are surprisingly common -in an import, typically due to branch merges in the source. - -per mark -~~~~~~~~ -Marks are stored in a sparse array, using 1 pointer (4 bytes or 8 -bytes, depending on pointer size) per mark. Although the array -is sparse, frontends are still strongly encouraged to use marks -between 1 and n, where n is the total number of marks required for -this import. - -per branch -~~~~~~~~~~ -Branches are classified as active and inactive. The memory usage -of the two classes is significantly different. - -Inactive branches are stored in a structure which uses 96 or 120 -bytes (32 bit or 64 bit systems, respectively), plus the length of -the branch name (typically under 200 bytes), per branch. fast-import will -easily handle as many as 10,000 inactive branches in under 2 MiB -of memory. - -Active branches have the same overhead as inactive branches, but -also contain copies of every tree that has been recently modified on -that branch. If subtree `include` has not been modified since the -branch became active, its contents will not be loaded into memory, -but if subtree `src` has been modified by a commit since the branch -became active, then its contents will be loaded in memory. - -As active branches store metadata about the files contained on that -branch, their in-memory storage size can grow to a considerable size -(see below). - -fast-import automatically moves active branches to inactive status based on -a simple least-recently-used algorithm. The LRU chain is updated on -each `commit` command. The maximum number of active branches can be -increased or decreased on the command line with --active-branches=. - -per active tree -~~~~~~~~~~~~~~~ -Trees (aka directories) use just 12 bytes of memory on top of the -memory required for their entries (see ``per active file'' below). -The cost of a tree is virtually 0, as its overhead amortizes out -over the individual file entries. - -per active file entry -~~~~~~~~~~~~~~~~~~~~~ -Files (and pointers to subtrees) within active trees require 52 or 64 -bytes (32/64 bit platforms) per entry. To conserve space, file and -tree names are pooled in a common string table, allowing the filename -``Makefile'' to use just 16 bytes (after including the string header -overhead) no matter how many times it occurs within the project. - -The active branch LRU, when coupled with the filename string pool -and lazy loading of subtrees, allows fast-import to efficiently import -projects with 2,000+ branches and 45,114+ files in a very limited -memory footprint (less than 2.7 MiB per active branch). - -SIGNALS -------- -Sending *SIGUSR1* to the 'git fast-import' process ends the current -packfile early, simulating a `checkpoint` command. The impatient -operator can use this facility to peek at the objects and refs from an -import in progress, at the cost of some added running time and worse -compression. - -SEE ALSO --------- -linkgit:git-fast-export[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-fetch-pack.txt b/third_party/git/Documentation/git-fetch-pack.txt deleted file mode 100644 index c975884793..0000000000 --- a/third_party/git/Documentation/git-fetch-pack.txt +++ /dev/null @@ -1,132 +0,0 @@ -git-fetch-pack(1) -================= - -NAME ----- -git-fetch-pack - Receive missing objects from another repository - - -SYNOPSIS --------- -[verse] -'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] - [--upload-pack=<git-upload-pack>] - [--depth=<n>] [--no-progress] - [-v] <repository> [<refs>...] - -DESCRIPTION ------------ -Usually you would want to use 'git fetch', which is a -higher level wrapper of this command, instead. - -Invokes 'git-upload-pack' on a possibly remote repository -and asks it to send objects missing from this repository, to -update the named heads. The list of commits available locally -is found out by scanning the local refs/ hierarchy and sent to -'git-upload-pack' running on the other end. - -This command degenerates to download everything to complete the -asked refs from the remote side when the local side does not -have a common ancestor commit. - - -OPTIONS -------- ---all:: - Fetch all remote refs. - ---stdin:: - Take the list of refs from stdin, one per line. If there - are refs specified on the command line in addition to this - option, then the refs from stdin are processed after those - on the command line. -+ -If `--stateless-rpc` is specified together with this option then -the list of refs must be in packet format (pkt-line). Each ref must -be in a separate packet, and the list must end with a flush packet. - --q:: ---quiet:: - Pass `-q` flag to 'git unpack-objects'; this makes the - cloning process less verbose. - --k:: ---keep:: - Do not invoke 'git unpack-objects' on received data, but - create a single packfile out of it instead, and store it - in the object database. If provided twice then the pack is - locked against repacking. - ---thin:: - Fetch a "thin" pack, which records objects in deltified form based - on objects not included in the pack to reduce network traffic. - ---include-tag:: - If the remote side supports it, annotated tags objects will - be downloaded on the same connection as the other objects if - the object the tag references is downloaded. The caller must - otherwise determine the tags this option made available. - ---upload-pack=<git-upload-pack>:: - Use this to specify the path to 'git-upload-pack' on the - remote side, if is not found on your $PATH. - Installations of sshd ignores the user's environment - setup scripts for login shells (e.g. .bash_profile) and - your privately installed git may not be found on the system - default $PATH. Another workaround suggested is to set - up your $PATH in ".bashrc", but this flag is for people - who do not want to pay the overhead for non-interactive - shells by having a lean .bashrc file (they set most of - the things up in .bash_profile). - ---exec=<git-upload-pack>:: - Same as --upload-pack=<git-upload-pack>. - ---depth=<n>:: - Limit fetching to ancestor-chains not longer than n. - '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. - ---check-self-contained-and-connected:: - Output "connectivity-ok" if the received pack is - self-contained and connected. - --v:: - Run verbosely. - -<repository>:: - The URL to the remote repository. - -<refs>...:: - The remote heads to update from. This is relative to - $GIT_DIR (e.g. "HEAD", "refs/heads/master"). When - unspecified, update from all heads the remote side has. -+ -If the remote has enabled the options `uploadpack.allowTipSHA1InWant`, -`uploadpack.allowReachableSHA1InWant`, or `uploadpack.allowAnySHA1InWant`, -they may alternatively be 40-hex sha1s present on the remote. - -SEE ALSO --------- -linkgit:git-fetch[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-fetch.txt b/third_party/git/Documentation/git-fetch.txt deleted file mode 100644 index 5b1909fdf4..0000000000 --- a/third_party/git/Documentation/git-fetch.txt +++ /dev/null @@ -1,299 +0,0 @@ -git-fetch(1) -============ - -NAME ----- -git-fetch - Download objects and refs from another repository - - -SYNOPSIS --------- -[verse] -'git fetch' [<options>] [<repository> [<refspec>...]] -'git fetch' [<options>] <group> -'git fetch' --multiple [<options>] [(<repository> | <group>)...] -'git fetch' --all [<options>] - - -DESCRIPTION ------------ -Fetch branches and/or tags (collectively, "refs") from one or more -other repositories, along with the objects necessary to complete their -histories. Remote-tracking branches are updated (see the description -of <refspec> below for ways to control this behavior). - -By default, any tag that points into the histories being fetched is -also fetched; the effect is to fetch tags that -point at branches that you are interested in. This default behavior -can be changed by using the --tags or --no-tags options or by -configuring remote.<name>.tagOpt. By using a refspec that fetches tags -explicitly, you can fetch tags that do not point into branches you -are interested in as well. - -'git fetch' can fetch from either a single named repository or URL, -or from several repositories at once if <group> is given and -there is a remotes.<group> entry in the configuration file. -(See linkgit:git-config[1]). - -When no remote is specified, by default the `origin` remote will be used, -unless there's an upstream branch configured for the current branch. - -The names of refs that are fetched, together with the object names -they point at, are written to `.git/FETCH_HEAD`. This information -may be used by scripts or other git commands, such as linkgit:git-pull[1]. - -OPTIONS -------- -include::fetch-options.txt[] - -include::pull-fetch-param.txt[] - -include::urls-remotes.txt[] - - -CONFIGURED REMOTE-TRACKING BRANCHES[[CRTB]] -------------------------------------------- - -You often interact with the same remote repository by -regularly and repeatedly fetching from it. In order to keep track -of the progress of such a remote repository, `git fetch` allows you -to configure `remote.<repository>.fetch` configuration variables. - -Typically such a variable may look like this: - ------------------------------------------------- -[remote "origin"] - fetch = +refs/heads/*:refs/remotes/origin/* ------------------------------------------------- - -This configuration is used in two ways: - -* When `git fetch` is run without specifying what branches - and/or tags to fetch on the command line, e.g. `git fetch origin` - or `git fetch`, `remote.<repository>.fetch` values are used as - the refspecs--they specify which refs to fetch and which local refs - to update. The example above will fetch - all branches that exist in the `origin` (i.e. any ref that matches - the left-hand side of the value, `refs/heads/*`) and update the - corresponding remote-tracking branches in the `refs/remotes/origin/*` - hierarchy. - -* When `git fetch` is run with explicit branches and/or tags - to fetch on the command line, e.g. `git fetch origin master`, the - <refspec>s given on the command line determine what are to be - fetched (e.g. `master` in the example, - which is a short-hand for `master:`, which in turn means - "fetch the 'master' branch but I do not explicitly say what - remote-tracking branch to update with it from the command line"), - and the example command will - fetch _only_ the 'master' branch. The `remote.<repository>.fetch` - values determine which - remote-tracking branch, if any, is updated. When used in this - way, the `remote.<repository>.fetch` values do not have any - effect in deciding _what_ gets fetched (i.e. the values are not - used as refspecs when the command-line lists refspecs); they are - only used to decide _where_ the refs that are fetched are stored - by acting as a mapping. - -The latter use of the `remote.<repository>.fetch` values can be -overridden by giving the `--refmap=<refspec>` parameter(s) on the -command line. - -PRUNING -------- - -Git has a default disposition of keeping data unless it's explicitly -thrown away; this extends to holding onto local references to branches -on remotes that have themselves deleted those branches. - -If left to accumulate, these stale references might make performance -worse on big and busy repos that have a lot of branch churn, and -e.g. make the output of commands like `git branch -a --contains -<commit>` needlessly verbose, as well as impacting anything else -that'll work with the complete set of known references. - -These remote-tracking references can be deleted as a one-off with -either of: - ------------------------------------------------- -# While fetching -$ git fetch --prune <name> - -# Only prune, don't fetch -$ git remote prune <name> ------------------------------------------------- - -To prune references as part of your normal workflow without needing to -remember to run that, set `fetch.prune` globally, or -`remote.<name>.prune` per-remote in the config. See -linkgit:git-config[1]. - -Here's where things get tricky and more specific. The pruning feature -doesn't actually care about branches, instead it'll prune local <-> -remote-references as a function of the refspec of the remote (see -`<refspec>` and <<CRTB,CONFIGURED REMOTE-TRACKING BRANCHES>> above). - -Therefore if the refspec for the remote includes -e.g. `refs/tags/*:refs/tags/*`, or you manually run e.g. `git fetch ---prune <name> "refs/tags/*:refs/tags/*"` it won't be stale remote -tracking branches that are deleted, but any local tag that doesn't -exist on the remote. - -This might not be what you expect, i.e. you want to prune remote -`<name>`, but also explicitly fetch tags from it, so when you fetch -from it you delete all your local tags, most of which may not have -come from the `<name>` remote in the first place. - -So be careful when using this with a refspec like -`refs/tags/*:refs/tags/*`, or any other refspec which might map -references from multiple remotes to the same local namespace. - -Since keeping up-to-date with both branches and tags on the remote is -a common use-case the `--prune-tags` option can be supplied along with -`--prune` to prune local tags that don't exist on the remote, and -force-update those tags that differ. Tag pruning can also be enabled -with `fetch.pruneTags` or `remote.<name>.pruneTags` in the config. See -linkgit:git-config[1]. - -The `--prune-tags` option is equivalent to having -`refs/tags/*:refs/tags/*` declared in the refspecs of the remote. This -can lead to some seemingly strange interactions: - ------------------------------------------------- -# These both fetch tags -$ git fetch --no-tags origin 'refs/tags/*:refs/tags/*' -$ git fetch --no-tags --prune-tags origin ------------------------------------------------- - -The reason it doesn't error out when provided without `--prune` or its -config versions is for flexibility of the configured versions, and to -maintain a 1=1 mapping between what the command line flags do, and -what the configuration versions do. - -It's reasonable to e.g. configure `fetch.pruneTags=true` in -`~/.gitconfig` to have tags pruned whenever `git fetch --prune` is -run, without making every invocation of `git fetch` without `--prune` -an error. - -Pruning tags with `--prune-tags` also works when fetching a URL -instead of a named remote. These will all prune tags not found on -origin: - ------------------------------------------------- -$ git fetch origin --prune --prune-tags -$ git fetch origin --prune 'refs/tags/*:refs/tags/*' -$ git fetch <url of origin> --prune --prune-tags -$ git fetch <url of origin> --prune 'refs/tags/*:refs/tags/*' ------------------------------------------------- - -OUTPUT ------- - -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 --------- - -* Update the remote-tracking branches: -+ ------------------------------------------------- -$ git fetch origin ------------------------------------------------- -+ -The above command copies all branches from the remote refs/heads/ -namespace and stores them to the local refs/remotes/origin/ namespace, -unless the branch.<name>.fetch option is used to specify a non-default -refspec. - -* Using refspecs explicitly: -+ ------------------------------------------------- -$ git fetch origin +pu:pu maint:tmp ------------------------------------------------- -+ -This updates (or creates, as necessary) branches `pu` and `tmp` in -the local repository by fetching from the branches (respectively) -`pu` and `maint` from the remote repository. -+ -The `pu` branch will be updated even if it does not fast-forward, -because it is prefixed with a plus sign; `tmp` will not be. - -* Peek at a remote's branch, without configuring the remote in your local - repository: -+ ------------------------------------------------- -$ git fetch git://git.kernel.org/pub/scm/git/git.git maint -$ git log FETCH_HEAD ------------------------------------------------- -+ -The first command fetches the `maint` branch from the repository at -`git://git.kernel.org/pub/scm/git/git.git` and the second command uses -`FETCH_HEAD` to examine the branch with linkgit:git-log[1]. The fetched -objects will eventually be removed by git's built-in housekeeping (see -linkgit:git-gc[1]). - -include::transfer-data-leaks.txt[] - -BUGS ----- -Using --recurse-submodules can only fetch new commits in already checked -out submodules right now. When e.g. upstream added a new submodule in the -just fetched commits of the superproject the submodule itself cannot be -fetched, making it impossible to check out that submodule later without -having to do a fetch again. This is expected to be fixed in a future Git -version. - -SEE ALSO --------- -linkgit:git-pull[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-filter-branch.txt b/third_party/git/Documentation/git-filter-branch.txt deleted file mode 100644 index 6b53dd7e06..0000000000 --- a/third_party/git/Documentation/git-filter-branch.txt +++ /dev/null @@ -1,481 +0,0 @@ -git-filter-branch(1) -==================== - -NAME ----- -git-filter-branch - Rewrite branches - -SYNOPSIS --------- -[verse] -'git filter-branch' [--setup <command>] [--subdirectory-filter <directory>] - [--env-filter <command>] [--tree-filter <command>] - [--index-filter <command>] [--parent-filter <command>] - [--msg-filter <command>] [--commit-filter <command>] - [--tag-name-filter <command>] [--prune-empty] - [--original <namespace>] [-d <directory>] [-f | --force] - [--state-branch <branch>] [--] [<rev-list options>...] - -DESCRIPTION ------------ -Lets you rewrite Git revision history by rewriting the branches mentioned -in the <rev-list options>, applying custom filters on each revision. -Those filters can modify each tree (e.g. removing a file or running -a perl rewrite on all files) or information about each commit. -Otherwise, all information (including original commit times or merge -information) will be preserved. - -The command will only rewrite the _positive_ refs mentioned in the -command line (e.g. if you pass 'a..b', only 'b' will be rewritten). -If you specify no filters, the commits will be recommitted without any -changes, which would normally have no effect. Nevertheless, this may be -useful in the future for compensating for some Git bugs or such, -therefore such a usage is permitted. - -*NOTE*: This command honors `.git/info/grafts` file and refs in -the `refs/replace/` namespace. -If you have any grafts or replacement refs defined, running this command -will make them permanent. - -*WARNING*! The rewritten history will have different object names for all -the objects and will not converge with the original branch. You will not -be able to easily push and distribute the rewritten branch on top of the -original branch. Please do not use this command if you do not know the -full implications, and avoid using it anyway, if a simple single commit -would suffice to fix your problem. (See the "RECOVERING FROM UPSTREAM -REBASE" section in linkgit:git-rebase[1] for further information about -rewriting published history.) - -Always verify that the rewritten version is correct: The original refs, -if different from the rewritten ones, will be stored in the namespace -'refs/original/'. - -Note that since this operation is very I/O expensive, it might -be a good idea to redirect the temporary directory off-disk with the -`-d` option, e.g. on tmpfs. Reportedly the speedup is very noticeable. - - -Filters -~~~~~~~ - -The filters are applied in the order as listed below. The <command> -argument is always evaluated in the shell context using the 'eval' command -(with the notable exception of the commit filter, for technical reasons). -Prior to that, the `$GIT_COMMIT` environment variable will be set to contain -the id of the commit being rewritten. Also, GIT_AUTHOR_NAME, -GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, -and GIT_COMMITTER_DATE are taken from the current commit and exported to -the environment, in order to affect the author and committer identities of -the replacement commit created by linkgit:git-commit-tree[1] after the -filters have run. - -If any evaluation of <command> returns a non-zero exit status, the whole -operation will be aborted. - -A 'map' function is available that takes an "original sha1 id" argument -and outputs a "rewritten sha1 id" if the commit has been already -rewritten, and "original sha1 id" otherwise; the 'map' function can -return several ids on separate lines if your commit filter emitted -multiple commits. - - -OPTIONS -------- - ---setup <command>:: - This is not a real filter executed for each commit but a one - time setup just before the loop. Therefore no commit-specific - variables are defined yet. Functions or variables defined here - can be used or modified in the following filter steps except - the commit filter, for technical reasons. - ---subdirectory-filter <directory>:: - Only look at the history which touches the given subdirectory. - The result will contain that directory (and only that) as its - project root. Implies <<Remap_to_ancestor>>. - ---env-filter <command>:: - This filter may be used if you only need to modify the environment - in which the commit will be performed. Specifically, you might - want to rewrite the author/committer name/email/time environment - variables (see linkgit:git-commit-tree[1] for details). - ---tree-filter <command>:: - This is the filter for rewriting the tree and its contents. - The argument is evaluated in shell with the working - directory set to the root of the checked out tree. The new tree - is then used as-is (new files are auto-added, disappeared files - are auto-removed - neither .gitignore files nor any other ignore - rules *HAVE ANY EFFECT*!). - ---index-filter <command>:: - This is the filter for rewriting the index. It is similar to the - tree filter but does not check out the tree, which makes it much - faster. Frequently used with `git rm --cached - --ignore-unmatch ...`, see EXAMPLES below. For hairy - cases, see linkgit:git-update-index[1]. - ---parent-filter <command>:: - This is the filter for rewriting the commit's parent list. - It will receive the parent string on stdin and shall output - the new parent string on stdout. The parent string is in - the format described in linkgit:git-commit-tree[1]: empty for - the initial commit, "-p parent" for a normal commit and - "-p parent1 -p parent2 -p parent3 ..." for a merge commit. - ---msg-filter <command>:: - This is the filter for rewriting the commit messages. - The argument is evaluated in the shell with the original - commit message on standard input; its standard output is - used as the new commit message. - ---commit-filter <command>:: - This is the filter for performing the commit. - If this filter is specified, it will be called instead of the - 'git commit-tree' command, with arguments of the form - "<TREE_ID> [(-p <PARENT_COMMIT_ID>)...]" and the log message on - stdin. The commit id is expected on stdout. -+ -As a special extension, the commit filter may emit multiple -commit ids; in that case, the rewritten children of the original commit will -have all of them as parents. -+ -You can use the 'map' convenience function in this filter, and other -convenience functions, too. For example, calling 'skip_commit "$@"' -will leave out the current commit (but not its changes! If you want -that, use 'git rebase' instead). -+ -You can also use the `git_commit_non_empty_tree "$@"` instead of -`git commit-tree "$@"` if you don't wish to keep commits with a single parent -and that makes no change to the tree. - ---tag-name-filter <command>:: - This is the filter for rewriting tag names. When passed, - it will be called for every tag ref that points to a rewritten - object (or to a tag object which points to a rewritten object). - The original tag name is passed via standard input, and the new - tag name is expected on standard output. -+ -The original tags are not deleted, but can be overwritten; -use "--tag-name-filter cat" to simply update the tags. In this -case, be very careful and make sure you have the old tags -backed up in case the conversion has run afoul. -+ -Nearly proper rewriting of tag objects is supported. If the tag has -a message attached, a new tag object will be created with the same message, -author, and timestamp. If the tag has a signature attached, the -signature will be stripped. It is by definition impossible to preserve -signatures. The reason this is "nearly" proper, is because ideally if -the tag did not change (points to the same object, has the same name, etc.) -it should retain any signature. That is not the case, signatures will always -be removed, buyer beware. There is also no support for changing the -author or timestamp (or the tag message for that matter). Tags which point -to other tags will be rewritten to point to the underlying commit. - ---prune-empty:: - Some filters will generate empty commits that leave the tree untouched. - This option instructs git-filter-branch to remove such commits if they - have exactly one or zero non-pruned parents; merge commits will - therefore remain intact. This option cannot be used together with - `--commit-filter`, though the same effect can be achieved by using the - provided `git_commit_non_empty_tree` function in a commit filter. - ---original <namespace>:: - Use this option to set the namespace where the original commits - will be stored. The default value is 'refs/original'. - --d <directory>:: - Use this option to set the path to the temporary directory used for - rewriting. When applying a tree filter, the command needs to - temporarily check out the tree to some directory, which may consume - considerable space in case of large projects. By default it - does this in the `.git-rewrite/` directory but you can override - that choice by this parameter. - --f:: ---force:: - 'git filter-branch' refuses to start with an existing temporary - directory or when there are already refs starting with - 'refs/original/', unless forced. - ---state-branch <branch>:: - This option will cause the mapping from old to new objects to - be loaded from named branch upon startup and saved as a new - commit to that branch upon exit, enabling incremental of large - trees. If '<branch>' does not exist it will be created. - -<rev-list options>...:: - Arguments for 'git rev-list'. All positive refs included by - these options are rewritten. You may also specify options - such as `--all`, but you must use `--` to separate them from - the 'git filter-branch' options. Implies <<Remap_to_ancestor>>. - - -[[Remap_to_ancestor]] -Remap to ancestor -~~~~~~~~~~~~~~~~~ - -By using linkgit:git-rev-list[1] arguments, e.g., path limiters, you can limit the -set of revisions which get rewritten. However, positive refs on the command -line are distinguished: we don't let them be excluded by such limiters. For -this purpose, they are instead rewritten to point at the nearest ancestor that -was not excluded. - - -EXIT STATUS ------------ - -On success, the exit status is `0`. If the filter can't find any commits to -rewrite, the exit status is `2`. On any other error, the exit status may be -any other non-zero value. - - -EXAMPLES --------- - -Suppose you want to remove a file (containing confidential information -or copyright violation) from all commits: - -------------------------------------------------------- -git filter-branch --tree-filter 'rm filename' HEAD -------------------------------------------------------- - -However, if the file is absent from the tree of some commit, -a simple `rm filename` will fail for that tree and commit. -Thus you may instead want to use `rm -f filename` as the script. - -Using `--index-filter` with 'git rm' yields a significantly faster -version. Like with using `rm filename`, `git rm --cached filename` -will fail if the file is absent from the tree of a commit. If you -want to "completely forget" a file, it does not matter when it entered -history, so we also add `--ignore-unmatch`: - --------------------------------------------------------------------------- -git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD --------------------------------------------------------------------------- - -Now, you will get the rewritten history saved in HEAD. - -To rewrite the repository to look as if `foodir/` had been its project -root, and discard all other history: - -------------------------------------------------------- -git filter-branch --subdirectory-filter foodir -- --all -------------------------------------------------------- - -Thus you can, e.g., turn a library subdirectory into a repository of -its own. Note the `--` that separates 'filter-branch' options from -revision options, and the `--all` to rewrite all branches and tags. - -To set a commit (which typically is at the tip of another -history) to be the parent of the current initial commit, in -order to paste the other history behind the current history: - -------------------------------------------------------------------- -git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' HEAD -------------------------------------------------------------------- - -(if the parent string is empty - which happens when we are dealing with -the initial commit - add graftcommit as a parent). Note that this assumes -history with a single root (that is, no merge without common ancestors -happened). If this is not the case, use: - --------------------------------------------------------------------------- -git filter-branch --parent-filter \ - 'test $GIT_COMMIT = <commit-id> && echo "-p <graft-id>" || cat' HEAD --------------------------------------------------------------------------- - -or even simpler: - ------------------------------------------------ -git replace --graft $commit-id $graft-id -git filter-branch $graft-id..HEAD ------------------------------------------------ - -To remove commits authored by "Darl McBribe" from the history: - ------------------------------------------------------------------------------- -git filter-branch --commit-filter ' - if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ]; - then - skip_commit "$@"; - else - git commit-tree "$@"; - fi' HEAD ------------------------------------------------------------------------------- - -The function 'skip_commit' is defined as follows: - --------------------------- -skip_commit() -{ - shift; - while [ -n "$1" ]; - do - shift; - map "$1"; - shift; - done; -} --------------------------- - -The shift magic first throws away the tree id and then the -p -parameters. Note that this handles merges properly! In case Darl -committed a merge between P1 and P2, it will be propagated properly -and all children of the merge will become merge commits with P1,P2 -as their parents instead of the merge commit. - -*NOTE* the changes introduced by the commits, and which are not reverted -by subsequent commits, will still be in the rewritten branch. If you want -to throw out _changes_ together with the commits, you should use the -interactive mode of 'git rebase'. - -You can rewrite the commit log messages using `--msg-filter`. For -example, 'git svn-id' strings in a repository created by 'git svn' can -be removed this way: - -------------------------------------------------------- -git filter-branch --msg-filter ' - sed -e "/^git-svn-id:/d" -' -------------------------------------------------------- - -If you need to add 'Acked-by' lines to, say, the last 10 commits (none -of which is a merge), use this command: - --------------------------------------------------------- -git filter-branch --msg-filter ' - cat && - echo "Acked-by: Bugs Bunny <bunny@bugzilla.org>" -' HEAD~10..HEAD --------------------------------------------------------- - -The `--env-filter` option can be used to modify committer and/or author -identity. For example, if you found out that your commits have the wrong -identity due to a misconfigured user.email, you can make a correction, -before publishing the project, like this: - --------------------------------------------------------- -git filter-branch --env-filter ' - if test "$GIT_AUTHOR_EMAIL" = "root@localhost" - then - GIT_AUTHOR_EMAIL=john@example.com - fi - if test "$GIT_COMMITTER_EMAIL" = "root@localhost" - then - GIT_COMMITTER_EMAIL=john@example.com - fi -' -- --all --------------------------------------------------------- - -To restrict rewriting to only part of the history, specify a revision -range in addition to the new branch name. The new branch name will -point to the top-most revision that a 'git rev-list' of this range -will print. - -Consider this history: - ------------------- - D--E--F--G--H - / / -A--B-----C ------------------- - -To rewrite only commits D,E,F,G,H, but leave A, B and C alone, use: - --------------------------------- -git filter-branch ... C..H --------------------------------- - -To rewrite commits E,F,G,H, use one of these: - ----------------------------------------- -git filter-branch ... C..H --not D -git filter-branch ... D..H --not C ----------------------------------------- - -To move the whole tree into a subdirectory, or remove it from there: - ---------------------------------------------------------------- -git filter-branch --index-filter \ - 'git ls-files -s | sed "s-\t\"*-&newsubdir/-" | - GIT_INDEX_FILE=$GIT_INDEX_FILE.new \ - git update-index --index-info && - mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' HEAD ---------------------------------------------------------------- - - - -CHECKLIST FOR SHRINKING A REPOSITORY ------------------------------------- - -git-filter-branch can be used to get rid of a subset of files, -usually with some combination of `--index-filter` and -`--subdirectory-filter`. People expect the resulting repository to -be smaller than the original, but you need a few more steps to -actually make it smaller, because Git tries hard not to lose your -objects until you tell it to. First make sure that: - -* You really removed all variants of a filename, if a blob was moved - over its lifetime. `git log --name-only --follow --all -- filename` - can help you find renames. - -* You really filtered all refs: use `--tag-name-filter cat -- --all` - when calling git-filter-branch. - -Then there are two ways to get a smaller repository. A safer way is -to clone, that keeps your original intact. - -* Clone it with `git clone file:///path/to/repo`. The clone - will not have the removed objects. See linkgit:git-clone[1]. (Note - that cloning with a plain path just hardlinks everything!) - -If you really don't want to clone it, for whatever reasons, check the -following points instead (in this order). This is a very destructive -approach, so *make a backup* or go back to cloning it. You have been -warned. - -* Remove the original refs backed up by git-filter-branch: say `git - for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git - update-ref -d`. - -* Expire all reflogs with `git reflog expire --expire=now --all`. - -* Garbage collect all unreferenced objects with `git gc --prune=now` - (or if your git-gc is not new enough to support arguments to - `--prune`, use `git repack -ad; git prune` instead). - -NOTES ------ - -git-filter-branch allows you to make complex shell-scripted rewrites -of your Git history, but you probably don't need this flexibility if -you're simply _removing unwanted data_ like large files or passwords. -For those operations you may want to consider -http://rtyley.github.io/bfg-repo-cleaner/[The BFG Repo-Cleaner], -a JVM-based alternative to git-filter-branch, typically at least -10-50x faster for those use-cases, and with quite different -characteristics: - -* Any particular version of a file is cleaned exactly _once_. The BFG, - unlike git-filter-branch, does not give you the opportunity to - handle a file differently based on where or when it was committed - within your history. This constraint gives the core performance - benefit of The BFG, and is well-suited to the task of cleansing bad - data - you don't care _where_ the bad data is, you just want it - _gone_. - -* By default The BFG takes full advantage of multi-core machines, - cleansing commit file-trees in parallel. git-filter-branch cleans - commits sequentially (i.e. in a single-threaded manner), though it - _is_ possible to write filters that include their own parallelism, - in the scripts executed against each commit. - -* The http://rtyley.github.io/bfg-repo-cleaner/#examples[command options] - are much more restrictive than git-filter branch, and dedicated just - to the tasks of removing unwanted data- e.g: - `--strip-blobs-bigger-than 1M`. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-fmt-merge-msg.txt b/third_party/git/Documentation/git-fmt-merge-msg.txt deleted file mode 100644 index 6793d8fc05..0000000000 --- a/third_party/git/Documentation/git-fmt-merge-msg.txt +++ /dev/null @@ -1,78 +0,0 @@ -git-fmt-merge-msg(1) -==================== - -NAME ----- -git-fmt-merge-msg - Produce a merge commit message - - -SYNOPSIS --------- -[verse] -'git fmt-merge-msg' [-m <message>] [--log[=<n>] | --no-log] -'git fmt-merge-msg' [-m <message>] [--log[=<n>] | --no-log] -F <file> - -DESCRIPTION ------------ -Takes the list of merged objects on stdin and produces a suitable -commit message to be used for the merge commit, usually to be -passed as the '<merge-message>' argument of 'git merge'. - -This command is intended mostly for internal use by scripts -automatically invoking 'git merge'. - -OPTIONS -------- - ---log[=<n>]:: - In addition to branch names, populate the log message with - one-line descriptions from the actual commits that are being - merged. At most <n> commits from each merge parent will be - used (20 if <n> is omitted). This overrides the `merge.log` - configuration variable. - ---no-log:: - Do not list one-line descriptions from the actual commits being - merged. - ---[no-]summary:: - Synonyms to --log and --no-log; these are deprecated and will be - removed in the future. - --m <message>:: ---message <message>:: - Use <message> instead of the branch names for the first line - of the log message. For use with `--log`. - --F <file>:: ---file <file>:: - Take the list of merged objects from <file> instead of - stdin. - -CONFIGURATION -------------- -include::config/fmt-merge-msg.txt[] - -merge.summary:: - Synonym to `merge.log`; this is deprecated and will be removed in - the future. - -EXAMPLES --------- - ---------- -$ 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. - - -SEE ALSO --------- -linkgit:git-merge[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-for-each-ref.txt b/third_party/git/Documentation/git-for-each-ref.txt deleted file mode 100644 index 6dcd39f6f6..0000000000 --- a/third_party/git/Documentation/git-for-each-ref.txt +++ /dev/null @@ -1,394 +0,0 @@ -git-for-each-ref(1) -=================== - -NAME ----- -git-for-each-ref - Output information on each ref - -SYNOPSIS --------- -[verse] -'git for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl] - [(--sort=<key>)...] [--format=<format>] [<pattern>...] - [--points-at=<object>] - (--merged[=<object>] | --no-merged[=<object>]) - [--contains[=<object>]] [--no-contains[=<object>]] - -DESCRIPTION ------------ - -Iterate over all refs that match `<pattern>` and show them -according to the given `<format>`, after sorting them according -to the given set of `<key>`. If `<count>` is given, stop after -showing that many refs. The interpolated values in `<format>` -can optionally be quoted as string literals in the specified -host language allowing their direct evaluation in that language. - -OPTIONS -------- -<pattern>...:: - If one or more patterns are given, only refs are shown that - match against at least one pattern, either using fnmatch(3) or - literally, in the latter case matching completely or from the - beginning up to a slash. - ---count=<count>:: - By default the command shows all refs that match - `<pattern>`. This option makes it stop after showing - that many refs. - ---sort=<key>:: - A field name to sort on. Prefix `-` to sort in - descending order of the value. When unspecified, - `refname` is used. You may use the --sort=<key> option - multiple times, in which case the last key becomes the primary - key. - ---format=<format>:: - A string that interpolates `%(fieldname)` from a ref being shown - and the object it points at. If `fieldname` - is prefixed with an asterisk (`*`) and the ref points - at a tag object, use the value for the field in the object - which the tag object refers to (instead of the field in the tag object). - When unspecified, `<format>` defaults to - `%(objectname) SPC %(objecttype) TAB %(refname)`. - It also interpolates `%%` to `%`, and `%xx` where `xx` - are hex digits interpolates to character with hex code - `xx`; for example `%00` interpolates to `\0` (NUL), - `%09` to `\t` (TAB) and `%0a` to `\n` (LF). - ---color[=<when>]:: - Respect any colors specified in the `--format` option. The - `<when>` field must be one of `always`, `never`, or `auto` (if - `<when>` is absent, behave as if `always` was given). - ---shell:: ---perl:: ---python:: ---tcl:: - If given, strings that substitute `%(fieldname)` - placeholders are quoted as string literals suitable for - the specified host language. This is meant to produce - a scriptlet that can directly be `eval`ed. - ---points-at=<object>:: - Only list refs which points at the given object. - ---merged[=<object>]:: - Only list refs whose tips are reachable from the - specified commit (HEAD if not specified), - incompatible with `--no-merged`. - ---no-merged[=<object>]:: - Only list refs whose tips are not reachable from the - specified commit (HEAD if not specified), - incompatible with `--merged`. - ---contains[=<object>]:: - Only list refs which contain the specified commit (HEAD if not - specified). - ---no-contains[=<object>]:: - Only list refs which don't contain the specified commit (HEAD - if not specified). - ---ignore-case:: - Sorting and filtering refs are case insensitive. - -FIELD NAMES ------------ - -Various values from structured fields in referenced objects can -be used to interpolate into the resulting output, or as sort -keys. - -For all objects, the following names can be used: - -refname:: - The name of the ref (the part after $GIT_DIR/). - For a non-ambiguous short name of the ref append `:short`. - The option core.warnAmbiguousRefs is used to select the strict - abbreviation mode. If `lstrip=<N>` (`rstrip=<N>`) is appended, strips `<N>` - slash-separated path components from the front (back) of the refname - (e.g. `%(refname:lstrip=2)` turns `refs/tags/foo` into `foo` and - `%(refname:rstrip=2)` turns `refs/tags/foo` into `refs`). - If `<N>` is a negative number, strip as many path components as - necessary from the specified end to leave `-<N>` path components - (e.g. `%(refname:lstrip=-2)` turns - `refs/tags/foo` into `tags/foo` and `%(refname:rstrip=-1)` - turns `refs/tags/foo` into `refs`). When the ref does not have - enough components, the result becomes an empty string if - stripping with positive <N>, or it becomes the full refname if - stripping with negative <N>. Neither is an error. -+ -`strip` can be used as a synonym to `lstrip`. - -objecttype:: - The type of the object (`blob`, `tree`, `commit`, `tag`). - -objectsize:: - The size of the object (the same as 'git cat-file -s' reports). - Append `:disk` to get the size, in bytes, that the object takes up on - disk. See the note about on-disk sizes in the `CAVEATS` section below. -objectname:: - The object name (aka SHA-1). - For a non-ambiguous abbreviation of the object name append `:short`. - For an abbreviation of the object name with desired length append - `:short=<length>`, where the minimum length is MINIMUM_ABBREV. The - length may be exceeded to ensure unique object names. -deltabase:: - This expands to the object name of the delta base for the - given object, if it is stored as a delta. Otherwise it - expands to the null object name (all zeroes). - -upstream:: - The name of a local ref which can be considered ``upstream'' - from the displayed ref. Respects `:short`, `:lstrip` and - `:rstrip` in the same way as `refname` above. Additionally - respects `:track` to show "[ahead N, behind M]" and - `:trackshort` to show the terse version: ">" (ahead), "<" - (behind), "<>" (ahead and behind), or "=" (in sync). `:track` - also prints "[gone]" whenever unknown upstream ref is - encountered. Append `:track,nobracket` to show tracking - information without brackets (i.e "ahead N, behind M"). -+ -For any remote-tracking branch `%(upstream)`, `%(upstream:remotename)` -and `%(upstream:remoteref)` refer to the name of the remote and the -name of the tracked remote ref, respectively. In other words, the -remote-tracking branch can be updated explicitly and individually by -using the refspec `%(upstream:remoteref):%(upstream)` to fetch from -`%(upstream:remotename)`. -+ -Has no effect if the ref does not have tracking information associated -with it. All the options apart from `nobracket` are mutually exclusive, -but if used together the last option is selected. - -push:: - The name of a local ref which represents the `@{push}` - location for the displayed ref. Respects `:short`, `:lstrip`, - `:rstrip`, `:track`, `:trackshort`, `:remotename`, and `:remoteref` - options as `upstream` does. Produces an empty string if no `@{push}` - ref is configured. - -HEAD:: - '*' if HEAD matches current ref (the checked out branch), ' ' - otherwise. - -color:: - Change output color. Followed by `:<colorname>`, where color - names are described under Values in the "CONFIGURATION FILE" - section of linkgit:git-config[1]. For example, - `%(color:bold red)`. - -align:: - Left-, middle-, or right-align the content between - %(align:...) and %(end). The "align:" is followed by - `width=<width>` and `position=<position>` in any order - separated by a comma, where the `<position>` is either left, - right or middle, default being left and `<width>` is the total - length of the content with alignment. For brevity, the - "width=" and/or "position=" prefixes may be omitted, and bare - <width> and <position> used instead. For instance, - `%(align:<width>,<position>)`. If the contents length is more - than the width then no alignment is performed. If used with - `--quote` everything in between %(align:...) and %(end) is - quoted, but if nested then only the topmost level performs - quoting. - -if:: - Used as %(if)...%(then)...%(end) or - %(if)...%(then)...%(else)...%(end). If there is an atom with - value or string literal after the %(if) then everything after - the %(then) is printed, else if the %(else) atom is used, then - everything after %(else) is printed. We ignore space when - evaluating the string before %(then), this is useful when we - use the %(HEAD) atom which prints either "*" or " " and we - want to apply the 'if' condition only on the 'HEAD' ref. - Append ":equals=<string>" or ":notequals=<string>" to compare - the value between the %(if:...) and %(then) atoms with the - given string. - -symref:: - The ref which the given symbolic ref refers to. If not a - symbolic ref, nothing is printed. Respects the `:short`, - `:lstrip` and `:rstrip` options in the same way as `refname` - above. - -worktreepath:: - The absolute path to the worktree in which the ref is checked - out, if it is checked out in any linked worktree. Empty string - otherwise. - -In addition to the above, for commit and tag objects, the header -field names (`tree`, `parent`, `object`, `type`, and `tag`) can -be used to specify the value in the header field. - -For commit and tag objects, the special `creatordate` and `creator` -fields will correspond to the appropriate date or name-email-date tuple -from the `committer` or `tagger` fields depending on the object type. -These are intended for working on a mix of annotated and lightweight tags. - -Fields that have name-email-date tuple as its value (`author`, -`committer`, and `tagger`) can be suffixed with `name`, `email`, -and `date` to extract the named component. - -The complete message in a commit and tag object is `contents`. -Its first line is `contents:subject`, where subject is the concatenation -of all lines of the commit message up to the first blank line. The next -line is `contents:body`, where body is all of the lines after the first -blank line. The optional GPG signature is `contents:signature`. The -first `N` lines of the message is obtained using `contents:lines=N`. -Additionally, the trailers as interpreted by linkgit:git-interpret-trailers[1] -are obtained as `trailers` (or by using the historical alias -`contents:trailers`). Non-trailer lines from the trailer block can be omitted -with `trailers:only`. Whitespace-continuations can be removed from trailers so -that each trailer appears on a line by itself with its full content with -`trailers:unfold`. Both can be used together as `trailers:unfold,only`. - -For sorting purposes, fields with numeric values sort in numeric order -(`objectsize`, `authordate`, `committerdate`, `creatordate`, `taggerdate`). -All other fields are used to sort in their byte-value order. - -There is also an option to sort by versions, this can be done by using -the fieldname `version:refname` or its alias `v:refname`. - -In any case, a field name that refers to a field inapplicable to -the object referred by the ref does not cause an error. It -returns an empty string instead. - -As a special case for the date-type fields, you may specify a format for -the date by adding `:` followed by date format name (see the -values the `--date` option to linkgit:git-rev-list[1] takes). - -Some atoms like %(align) and %(if) always require a matching %(end). -We call them "opening atoms" and sometimes denote them as %($open). - -When a scripting language specific quoting is in effect, everything -between a top-level opening atom and its matching %(end) is evaluated -according to the semantics of the opening atom and only its result -from the top-level is quoted. - - -EXAMPLES --------- - -An example directly producing formatted text. Show the most recent -3 tagged commits: - ------------- -#!/bin/sh - -git for-each-ref --count=3 --sort='-*authordate' \ ---format='From: %(*authorname) %(*authoremail) -Subject: %(*subject) -Date: %(*authordate) -Ref: %(*refname) - -%(*body) -' 'refs/tags' ------------- - - -A simple example showing the use of shell eval on the output, -demonstrating the use of --shell. List the prefixes of all heads: ------------- -#!/bin/sh - -git for-each-ref --shell --format="ref=%(refname)" refs/heads | \ -while read entry -do - eval "$entry" - echo `dirname $ref` -done ------------- - - -A bit more elaborate report on tags, demonstrating that the format -may be an entire script: ------------- -#!/bin/sh - -fmt=' - r=%(refname) - t=%(*objecttype) - T=${r#refs/tags/} - - o=%(*objectname) - n=%(*authorname) - e=%(*authoremail) - s=%(*subject) - d=%(*authordate) - b=%(*body) - - kind=Tag - if test "z$t" = z - then - # could be a lightweight tag - t=%(objecttype) - kind="Lightweight tag" - o=%(objectname) - n=%(authorname) - e=%(authoremail) - s=%(subject) - d=%(authordate) - b=%(body) - fi - echo "$kind $T points at a $t object $o" - if test "z$t" = zcommit - then - echo "The commit was authored by $n $e -at $d, and titled - - $s - -Its message reads as: -" - echo "$b" | sed -e "s/^/ /" - echo - fi -' - -eval=`git for-each-ref --shell --format="$fmt" \ - --sort='*objecttype' \ - --sort=-taggerdate \ - refs/tags` -eval "$eval" ------------- - - -An example to show the usage of %(if)...%(then)...%(else)...%(end). -This prefixes the current branch with a star. - ------------- -git for-each-ref --format="%(if)%(HEAD)%(then)* %(else) %(end)%(refname:short)" refs/heads/ ------------- - - -An example to show the usage of %(if)...%(then)...%(end). -This prints the authorname, if present. - ------------- -git for-each-ref --format="%(refname)%(if)%(authorname)%(then) Authored by: %(authorname)%(end)" ------------- - -CAVEATS -------- - -Note that the sizes of objects on disk are reported accurately, but care -should be taken in drawing conclusions about which refs or objects are -responsible for disk usage. The size of a packed non-delta object may be -much larger than the size of objects which delta against it, but the -choice of which object is the base and which is the delta is arbitrary -and is subject to change during a repack. - -Note also that multiple copies of an object may be present in the object -database; in this case, it is undefined which copy's size or delta base -will be reported. - -SEE ALSO --------- -linkgit:git-show-ref[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-format-patch.txt b/third_party/git/Documentation/git-format-patch.txt deleted file mode 100644 index b9b97e63ae..0000000000 --- a/third_party/git/Documentation/git-format-patch.txt +++ /dev/null @@ -1,684 +0,0 @@ -git-format-patch(1) -=================== - -NAME ----- -git-format-patch - Prepare patches for e-mail submission - - -SYNOPSIS --------- -[verse] -'git format-patch' [-k] [(-o|--output-directory) <dir> | --stdout] - [--no-thread | --thread[=<style>]] - [(--attach|--inline)[=<boundary>] | --no-attach] - [-s | --signoff] - [--signature=<signature> | --no-signature] - [--signature-file=<file>] - [-n | --numbered | -N | --no-numbered] - [--start-number <n>] [--numbered-files] - [--in-reply-to=Message-Id] [--suffix=.<sfx>] - [--ignore-if-in-upstream] - [--rfc] [--subject-prefix=Subject-Prefix] - [(--reroll-count|-v) <n>] - [--to=<email>] [--cc=<email>] - [--[no-]cover-letter] [--quiet] - [--no-notes | --notes[=<ref>]] - [--interdiff=<previous>] - [--range-diff=<previous> [--creation-factor=<percent>]] - [--progress] - [<common diff options>] - [ <since> | <revision range> ] - -DESCRIPTION ------------ - -Prepare each commit with its patch in -one file per commit, formatted to resemble UNIX mailbox format. -The output of this command is convenient for e-mail submission or -for use with 'git am'. - -There are two ways to specify which commits to operate on. - -1. A single commit, <since>, specifies that the commits leading - to the tip of the current branch that are not in the history - that leads to the <since> to be output. - -2. Generic <revision range> expression (see "SPECIFYING - REVISIONS" section in linkgit:gitrevisions[7]) means the - commits in the specified range. - -The first rule takes precedence in the case of a single <commit>. To -apply the second rule, i.e., format everything since the beginning of -history up until <commit>, use the `--root` option: `git format-patch ---root <commit>`. If you want to format only <commit> itself, you -can do this with `git format-patch -1 <commit>`. - -By default, each output file is numbered sequentially from 1, and uses the -first line of the commit message (massaged for pathname safety) as -the filename. With the `--numbered-files` option, the output file names -will only be numbers, without the first line of the commit appended. -The names of the output files are printed to standard -output, unless the `--stdout` option is specified. - -If `-o` is specified, output files are created in <dir>. Otherwise -they are created in the current working directory. The default path -can be set with the `format.outputDirectory` configuration option. -The `-o` option takes precedence over `format.outputDirectory`. -To store patches in the current working directory even when -`format.outputDirectory` points elsewhere, use `-o .`. - -By default, the subject of a single patch is "[PATCH] " followed by -the concatenation of lines from the commit message up to the first blank -line (see the DISCUSSION section of linkgit:git-commit[1]). - -When multiple patches are output, the subject prefix will instead be -"[PATCH n/m] ". To force 1/1 to be added for a single patch, use `-n`. -To omit patch numbers from the subject, use `-N`. - -If given `--thread`, `git-format-patch` will generate `In-Reply-To` and -`References` headers to make the second and subsequent patch mails appear -as replies to the first mail; this also generates a `Message-Id` header to -reference. - -OPTIONS -------- -:git-format-patch: 1 -include::diff-options.txt[] - --<n>:: - Prepare patches from the topmost <n> commits. - --o <dir>:: ---output-directory <dir>:: - Use <dir> to store the resulting files, instead of the - current working directory. - --n:: ---numbered:: - Name output in '[PATCH n/m]' format, even with a single patch. - --N:: ---no-numbered:: - Name output in '[PATCH]' format. - ---start-number <n>:: - Start numbering the patches at <n> instead of 1. - ---numbered-files:: - Output file names will be a simple number sequence - without the default first line of the commit appended. - --k:: ---keep-subject:: - Do not strip/add '[PATCH]' from the first line of the - commit log message. - --s:: ---signoff:: - Add `Signed-off-by:` line to the commit message, using - the committer identity of yourself. - See the signoff option in linkgit:git-commit[1] for more information. - ---stdout:: - Print all commits to the standard output in mbox format, - instead of creating a file for each one. - ---attach[=<boundary>]:: - Create multipart/mixed attachment, the first part of - which is the commit message and the patch itself in the - second part, with `Content-Disposition: attachment`. - ---no-attach:: - Disable the creation of an attachment, overriding the - configuration setting. - ---inline[=<boundary>]:: - Create multipart/mixed attachment, the first part of - which is the commit message and the patch itself in the - second part, with `Content-Disposition: inline`. - ---thread[=<style>]:: ---no-thread:: - Controls addition of `In-Reply-To` and `References` headers to - make the second and subsequent mails appear as replies to the - first. Also controls generation of the `Message-Id` header to - reference. -+ -The optional <style> argument can be either `shallow` or `deep`. -'shallow' threading makes every mail a reply to the head of the -series, where the head is chosen from the cover letter, the -`--in-reply-to`, and the first patch mail, in this order. 'deep' -threading makes every mail a reply to the previous one. -+ -The default is `--no-thread`, unless the `format.thread` configuration -is set. If `--thread` is specified without a style, it defaults to the -style specified by `format.thread` if any, or else `shallow`. -+ -Beware that the default for 'git send-email' is to thread emails -itself. If you want `git format-patch` to take care of threading, you -will want to ensure that threading is disabled for `git send-email`. - ---in-reply-to=Message-Id:: - Make the first mail (or all the mails with `--no-thread`) appear as a - reply to the given Message-Id, which avoids breaking threads to - provide a new patch series. - ---ignore-if-in-upstream:: - Do not include a patch that matches a commit in - <until>..<since>. This will examine all patches reachable - from <since> but not from <until> and compare them with the - patches being generated, and any patch that matches is - ignored. - ---subject-prefix=<Subject-Prefix>:: - Instead of the standard '[PATCH]' prefix in the subject - line, instead use '[<Subject-Prefix>]'. This - 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 - output filenames have `v<n>` prepended to them, and the - subject prefix ("PATCH" by default, but configurable via the - `--subject-prefix` option) has ` v<n>` appended to it. E.g. - `--reroll-count=4` may produce `v4-0001-add-makefile.patch` - file that has "Subject: [PATCH v4 1/20] Add makefile" in it. - ---to=<email>:: - Add a `To:` header to the email headers. This is in addition - to any configured headers, and may be used multiple times. - The negated form `--no-to` discards all `To:` headers added so - far (from config or command line). - ---cc=<email>:: - Add a `Cc:` header to the email headers. This is in addition - to any configured headers, and may be used multiple times. - The negated form `--no-cc` discards all `Cc:` headers added so - far (from config or command line). - ---from:: ---from=<ident>:: - Use `ident` in the `From:` header of each commit email. If the - author ident of the commit is not textually identical to the - provided `ident`, place a `From:` header in the body of the - message with the original author. If no `ident` is given, use - the committer ident. -+ -Note that this option is only useful if you are actually sending the -emails and want to identify yourself as the sender, but retain the -original author (and `git am` will correctly pick up the in-body -header). Note also that `git send-email` already handles this -transformation for you, and this option should not be used if you are -feeding the result to `git send-email`. - ---add-header=<header>:: - Add an arbitrary header to the email headers. This is in addition - to any configured headers, and may be used multiple times. - For example, `--add-header="Organization: git-foo"`. - The negated form `--no-add-header` discards *all* (`To:`, - `Cc:`, and custom) headers added so far from config or command - line. - ---[no-]cover-letter:: - In addition to the patches, generate a cover letter file - containing the branch description, shortlog and the overall diffstat. You can - fill in a description in the file before sending it out. - ---interdiff=<previous>:: - As a reviewer aid, insert an interdiff into the cover letter, - or as commentary of the lone patch of a 1-patch series, showing - the differences between the previous version of the patch series and - the series currently being formatted. `previous` is a single revision - naming the tip of the previous series which shares a common base with - the series being formatted (for example `git format-patch - --cover-letter --interdiff=feature/v1 -3 feature/v2`). - ---range-diff=<previous>:: - As a reviewer aid, insert a range-diff (see linkgit:git-range-diff[1]) - into the cover letter, or as commentary of the lone patch of a - 1-patch series, showing the differences between the previous - version of the patch series and the series currently being formatted. - `previous` can be a single revision naming the tip of the previous - series if it shares a common base with the series being formatted (for - example `git format-patch --cover-letter --range-diff=feature/v1 -3 - feature/v2`), or a revision range if the two versions of the series are - disjoint (for example `git format-patch --cover-letter - --range-diff=feature/v1~3..feature/v1 -3 feature/v2`). -+ -Note that diff options passed to the command affect how the primary -product of `format-patch` is generated, and they are not passed to -the underlying `range-diff` machinery used to generate the cover-letter -material (this may change in the future). - ---creation-factor=<percent>:: - Used with `--range-diff`, tweak the heuristic which matches up commits - between the previous and current series of patches by adjusting the - creation/deletion cost fudge factor. See linkgit:git-range-diff[1]) - for details. - ---notes[=<ref>]:: ---no-notes:: - Append the notes (see linkgit:git-notes[1]) for the commit - after the three-dash line. -+ -The expected use case of this is to write supporting explanation for -the commit that does not belong to the commit log message proper, -and include it with the patch submission. While one can simply write -these explanations after `format-patch` has run but before sending, -keeping them as Git notes allows them to be maintained between versions -of the patch series (but see the discussion of the `notes.rewrite` -configuration options in linkgit:git-notes[1] to use this workflow). -+ -The default is `--no-notes`, unless the `format.notes` configuration is -set. - ---[no-]signature=<signature>:: - Add a signature to each message produced. Per RFC 3676 the signature - is separated from the body by a line with '-- ' on it. If the - signature option is omitted the signature defaults to the Git version - number. - ---signature-file=<file>:: - Works just like --signature except the signature is read from a file. - ---suffix=.<sfx>:: - Instead of using `.patch` as the suffix for generated - filenames, use specified suffix. A common alternative is - `--suffix=.txt`. Leaving this empty will remove the `.patch` - suffix. -+ -Note that the leading character does not have to be a dot; for example, -you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`. - --q:: ---quiet:: - Do not print the names of the generated files to standard output. - ---no-binary:: - Do not output contents of changes in binary files, instead - display a notice that those files changed. Patches generated - using this option cannot be applied properly, but they are - still useful for code review. - ---zero-commit:: - Output an all-zero hash in each patch's From header instead - of the hash of the commit. - ---base=<commit>:: - Record the base tree information to identify the state the - patch series applies to. See the BASE TREE INFORMATION section - below for details. - ---root:: - Treat the revision argument as a <revision range>, even if it - is just a single commit (that would normally be treated as a - <since>). Note that root commits included in the specified - range are always formatted as creation patches, independently - of this flag. - ---progress:: - Show progress reports on stderr as patches are generated. - -CONFIGURATION -------------- -You can specify extra mail header lines to be added to each message, -defaults for the subject prefix and file suffix, number patches when -outputting more than one patch, add "To" or "Cc:" headers, configure -attachments, and sign off patches with configuration variables. - ------------- -[format] - headers = "Organization: git-foo\n" - subjectPrefix = CHANGE - suffix = .txt - numbered = auto - to = <email> - cc = <email> - attach [ = mime-boundary-string ] - signOff = true - coverletter = auto ------------- - - -DISCUSSION ----------- - -The patch produced by 'git format-patch' is in UNIX mailbox format, -with a fixed "magic" time stamp to indicate that the file is output -from format-patch rather than a real mailbox, like so: - ------------- -From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001 -From: Tony Luck <tony.luck@intel.com> -Date: Tue, 13 Jul 2010 11:42:54 -0700 -Subject: [PATCH] =?UTF-8?q?[IA64]=20Put=20ia64=20config=20files=20on=20the=20?= - =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20diet?= -MIME-Version: 1.0 -Content-Type: text/plain; charset=UTF-8 -Content-Transfer-Encoding: 8bit - -arch/arm config files were slimmed down using a python script -(See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment) - -Do the same for ia64 so we can have sleek & trim looking -... ------------- - -Typically it will be placed in a MUA's drafts folder, edited to add -timely commentary that should not go in the changelog after the three -dashes, and then sent as a message whose body, in our example, starts -with "arch/arm config files were...". On the receiving end, readers -can save interesting patches in a UNIX mailbox and apply them with -linkgit:git-am[1]. - -When a patch is part of an ongoing discussion, the patch generated by -'git format-patch' can be tweaked to take advantage of the 'git am ---scissors' feature. After your response to the discussion comes a -line that consists solely of "`-- >8 --`" (scissors and perforation), -followed by the patch with unnecessary header fields removed: - ------------- -... -> So we should do such-and-such. - -Makes sense to me. How about this patch? - --- >8 -- -Subject: [IA64] Put ia64 config files on the Uwe Kleine-Kรถnig diet - -arch/arm config files were slimmed down using a python script -... ------------- - -When sending a patch this way, most often you are sending your own -patch, so in addition to the "`From $SHA1 $magic_timestamp`" marker you -should omit `From:` and `Date:` lines from the patch file. The patch -title is likely to be different from the subject of the discussion the -patch is in response to, so it is likely that you would want to keep -the Subject: line, like the example above. - -Checking for patch corruption -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Many mailers if not set up properly will corrupt whitespace. Here are -two common types of corruption: - -* Empty context lines that do not have _any_ whitespace. - -* Non-empty context lines that have one extra whitespace at the - beginning. - -One way to test if your MUA is set up correctly is: - -* Send the patch to yourself, exactly the way you would, except - with To: and Cc: lines that do not contain the list and - maintainer address. - -* Save that patch to a file in UNIX mailbox format. Call it a.patch, - say. - -* Apply it: - - $ git fetch <project> master:test-apply - $ git switch test-apply - $ git restore --source=HEAD --staged --worktree :/ - $ git am a.patch - -If it does not apply correctly, there can be various reasons. - -* The patch itself does not apply cleanly. That is _bad_ but - does not have much to do with your MUA. You might want to rebase - the patch with linkgit:git-rebase[1] before regenerating it in - this case. - -* The MUA corrupted your patch; "am" would complain that - the patch does not apply. Look in the .git/rebase-apply/ subdirectory and - see what 'patch' file contains and check for the common - corruption patterns mentioned above. - -* While at it, check the 'info' and 'final-commit' files as well. - If what is in 'final-commit' is not exactly what you would want to - see in the commit log message, it is very likely that the - receiver would end up hand editing the log message when applying - your patch. Things like "Hi, this is my first patch.\n" in the - patch e-mail should come after the three-dash line that signals - the end of the commit message. - -MUA-SPECIFIC HINTS ------------------- -Here are some hints on how to successfully submit patches inline using -various mailers. - -GMail -~~~~~ -GMail does not have any way to turn off line wrapping in the web -interface, so it will mangle any emails that you send. You can however -use "git send-email" and send your patches through the GMail SMTP server, or -use any IMAP email client to connect to the google IMAP server and forward -the emails through that. - -For hints on using 'git send-email' to send your patches through the -GMail SMTP server, see the EXAMPLE section of linkgit:git-send-email[1]. - -For hints on submission using the IMAP interface, see the EXAMPLE -section of linkgit:git-imap-send[1]. - -Thunderbird -~~~~~~~~~~~ -By default, Thunderbird will both wrap emails as well as flag -them as being 'format=flowed', both of which will make the -resulting email unusable by Git. - -There are three different approaches: use an add-on to turn off line wraps, -configure Thunderbird to not mangle patches, or use -an external editor to keep Thunderbird from mangling the patches. - -Approach #1 (add-on) -^^^^^^^^^^^^^^^^^^^^ - -Install the Toggle Word Wrap add-on that is available from -https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/ -It adds a menu entry "Enable Word Wrap" in the composer's "Options" menu -that you can tick off. Now you can compose the message as you otherwise do -(cut + paste, 'git format-patch' | 'git imap-send', etc), but you have to -insert line breaks manually in any text that you type. - -Approach #2 (configuration) -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Three steps: - -1. Configure your mail server composition as plain text: - Edit...Account Settings...Composition & Addressing, - uncheck "Compose Messages in HTML". - -2. Configure your general composition window to not wrap. -+ -In Thunderbird 2: -Edit..Preferences..Composition, wrap plain text messages at 0 -+ -In Thunderbird 3: -Edit..Preferences..Advanced..Config Editor. Search for -"mail.wrap_long_lines". -Toggle it to make sure it is set to `false`. Also, search for -"mailnews.wraplength" and set the value to 0. - -3. Disable the use of format=flowed: - Edit..Preferences..Advanced..Config Editor. Search for - "mailnews.send_plaintext_flowed". - Toggle it to make sure it is set to `false`. - -After that is done, you should be able to compose email as you -otherwise would (cut + paste, 'git format-patch' | 'git imap-send', etc), -and the patches will not be mangled. - -Approach #3 (external editor) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The following Thunderbird extensions are needed: -AboutConfig from http://aboutconfig.mozdev.org/ and -External Editor from http://globs.org/articles.php?lng=en&pg=8 - -1. Prepare the patch as a text file using your method of choice. - -2. Before opening a compose window, use Edit->Account Settings to - uncheck the "Compose messages in HTML format" setting in the - "Composition & Addressing" panel of the account to be used to - send the patch. - -3. In the main Thunderbird window, 'before' you open the compose - window for the patch, use Tools->about:config to set the - following to the indicated values: -+ ----------- - mailnews.send_plaintext_flowed => false - mailnews.wraplength => 0 ----------- - -4. Open a compose window and click the external editor icon. - -5. In the external editor window, read in the patch file and exit - the editor normally. - -Side note: it may be possible to do step 2 with -about:config and the following settings but no one's tried yet. - ----------- - mail.html_compose => false - mail.identity.default.compose_html => false - mail.identity.id?.compose_html => false ----------- - -There is a script in contrib/thunderbird-patch-inline which can help -you include patches with Thunderbird in an easy way. To use it, do the -steps above and then use the script as the external editor. - -KMail -~~~~~ -This should help you to submit patches inline using KMail. - -1. Prepare the patch as a text file. - -2. Click on New Mail. - -3. Go under "Options" in the Composer window and be sure that - "Word wrap" is not set. - -4. Use Message -> Insert file... and insert the patch. - -5. Back in the compose window: add whatever other text you wish to the - message, complete the addressing and subject fields, and press send. - -BASE TREE INFORMATION ---------------------- - -The base tree information block is used for maintainers or third party -testers to know the exact state the patch series applies to. It consists -of the 'base commit', which is a well-known commit that is part of the -stable part of the project history everybody else works off of, and zero -or more 'prerequisite patches', which are well-known patches in flight -that is not yet part of the 'base commit' that need to be applied on top -of 'base commit' in topological order before the patches can be applied. - -The 'base commit' is shown as "base-commit: " followed by the 40-hex of -the commit object name. A 'prerequisite patch' is shown as -"prerequisite-patch-id: " followed by the 40-hex 'patch id', which can -be obtained by passing the patch through the `git patch-id --stable` -command. - -Imagine that on top of the public commit P, you applied well-known -patches X, Y and Z from somebody else, and then built your three-patch -series A, B, C, the history would be like: - -................................................ ----P---X---Y---Z---A---B---C -................................................ - -With `git format-patch --base=P -3 C` (or variants thereof, e.g. with -`--cover-letter` or using `Z..C` instead of `-3 C` to specify the -range), the base tree information block is shown at the end of the -first message the command outputs (either the first patch, or the -cover letter), like this: - ------------- -base-commit: P -prerequisite-patch-id: X -prerequisite-patch-id: Y -prerequisite-patch-id: Z ------------- - -For non-linear topology, such as - -................................................ ----P---X---A---M---C - \ / - Y---Z---B -................................................ - -You can also use `git format-patch --base=P -3 C` to generate patches -for A, B and C, and the identifiers for P, X, Y, Z are appended at the -end of the first message. - -If set `--base=auto` in cmdline, it will track base commit automatically, -the base commit will be the merge base of tip commit of the remote-tracking -branch and revision-range specified in cmdline. -For a local branch, you need to track a remote branch by `git branch ---set-upstream-to` before using this option. - -EXAMPLES --------- - -* Extract commits between revisions R1 and R2, and apply them on top of - the current branch using 'git am' to cherry-pick them: -+ ------------- -$ git format-patch -k --stdout R1..R2 | git am -3 -k ------------- - -* Extract all commits which are in the current branch but not in the - origin branch: -+ ------------- -$ git format-patch origin ------------- -+ -For each commit a separate file is created in the current directory. - -* Extract all commits that lead to 'origin' since the inception of the - project: -+ ------------- -$ git format-patch --root origin ------------- - -* The same as the previous one: -+ ------------- -$ git format-patch -M -B origin ------------- -+ -Additionally, it detects and handles renames and complete rewrites -intelligently to produce a renaming patch. A renaming patch reduces -the amount of text output, and generally makes it easier to review. -Note that non-Git "patch" programs won't understand renaming patches, so -use it only when you know the recipient uses Git to apply your patch. - -* Extract three topmost commits from the current branch and format them - as e-mailable patches: -+ ------------- -$ git format-patch -3 ------------- - -SEE ALSO --------- -linkgit:git-am[1], linkgit:git-send-email[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-fsck-objects.txt b/third_party/git/Documentation/git-fsck-objects.txt deleted file mode 100644 index eec4bdb600..0000000000 --- a/third_party/git/Documentation/git-fsck-objects.txt +++ /dev/null @@ -1,22 +0,0 @@ -git-fsck-objects(1) -=================== - -NAME ----- -git-fsck-objects - Verifies the connectivity and validity of the objects in the database - - -SYNOPSIS --------- -[verse] -'git fsck-objects' ... - -DESCRIPTION ------------ - -This is a synonym for linkgit:git-fsck[1]. Please refer to the -documentation of that command. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-fsck.txt b/third_party/git/Documentation/git-fsck.txt deleted file mode 100644 index d72d15be5b..0000000000 --- a/third_party/git/Documentation/git-fsck.txt +++ /dev/null @@ -1,175 +0,0 @@ -git-fsck(1) -=========== - -NAME ----- -git-fsck - Verifies the connectivity and validity of the objects in the database - - -SYNOPSIS --------- -[verse] -'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs] - [--[no-]full] [--strict] [--verbose] [--lost-found] - [--[no-]dangling] [--[no-]progress] [--connectivity-only] - [--[no-]name-objects] [<object>*] - -DESCRIPTION ------------ -Verifies the connectivity and validity of the objects in the database. - -OPTIONS -------- -<object>:: - An object to treat as the head of an unreachability trace. -+ -If no objects are given, 'git fsck' defaults to using the -index file, all SHA-1 references in `refs` namespace, and all reflogs -(unless --no-reflogs is given) as heads. - ---unreachable:: - Print out objects that exist but that aren't reachable from any - of the reference nodes. - ---[no-]dangling:: - Print objects that exist but that are never 'directly' used (default). - `--no-dangling` can be used to omit this information from the output. - ---root:: - Report root nodes. - ---tags:: - Report tags. - ---cache:: - Consider any object recorded in the index also as a head node for - an unreachability trace. - ---no-reflogs:: - Do not consider commits that are referenced only by an - entry in a reflog to be reachable. This option is meant - only to search for commits that used to be in a ref, but - now aren't, but are still in that corresponding reflog. - ---full:: - Check not just objects in GIT_OBJECT_DIRECTORY - ($GIT_DIR/objects), but also the ones found in alternate - object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES - or $GIT_DIR/objects/info/alternates, - and in packed Git archives found in $GIT_DIR/objects/pack - and corresponding pack subdirectories in alternate - object pools. This is now default; you can turn it off - with --no-full. - ---connectivity-only:: - Check only the connectivity of reachable objects, making sure - that any objects referenced by a reachable tag, commit, or tree - is present. This speeds up the operation by avoiding reading - blobs entirely (though it does still check that referenced blobs - exist). This will detect corruption in commits and trees, but - not do any semantic checks (e.g., for format errors). Corruption - in blob objects will not be detected at all. -+ -Unreachable tags, commits, and trees will also be accessed to find the -tips of dangling segments of history. Use `--no-dangling` if you don't -care about this output and want to speed it up further. - ---strict:: - Enable more strict checking, namely to catch a file mode - recorded with g+w bit set, which was created by older - versions of Git. Existing repositories, including the - Linux kernel, Git itself, and sparse repository have old - objects that triggers this check, but it is recommended - to check new projects with this flag. - ---verbose:: - Be chatty. - ---lost-found:: - Write dangling objects into .git/lost-found/commit/ or - .git/lost-found/other/, depending on type. If the object is - 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 - --no-progress or --verbose is specified. --progress forces - progress status even if the standard error stream is not - directed to a terminal. - -CONFIGURATION -------------- - -include::config/fsck.txt[] - -DISCUSSION ----------- - -git-fsck tests SHA-1 and general object sanity, and it does full tracking -of the resulting reachability and everything else. It prints out any -corruption it finds (missing or bad objects), and if you use the -`--unreachable` flag it will also print out objects that exist but that -aren't reachable from any of the specified head nodes (or the default -set, as mentioned above). - -Any corrupt objects you will have to find in backups or other archives -(i.e., you can just remove them and do an 'rsync' with some other site in -the hopes that somebody else has the object you have corrupted). - -If core.commitGraph is true, the commit-graph file will also be inspected -using 'git commit-graph verify'. See linkgit:git-commit-graph[1]. - -Extracted Diagnostics ---------------------- - -expect dangling commits - potential heads - due to lack of head information:: - You haven't specified any nodes as heads so it won't be - possible to differentiate between un-parented commits and - root nodes. - -missing sha1 directory '<dir>':: - The directory holding the sha1 objects is missing. - -unreachable <type> <object>:: - The <type> object <object>, isn't actually referred to directly - or indirectly in any of the trees or commits seen. This can - mean that there's another root node that you're not specifying - or that the tree is corrupt. If you haven't missed a root node - then you might as well delete unreachable nodes since they - can't be used. - -missing <type> <object>:: - The <type> object <object>, is referred to but isn't present in - the database. - -dangling <type> <object>:: - The <type> object <object>, is present in the database but never - 'directly' used. A dangling commit could be a root node. - -hash mismatch <object>:: - The database has an object whose hash doesn't match the - object database value. - This indicates a serious data integrity problem. - -Environment Variables ---------------------- - -GIT_OBJECT_DIRECTORY:: - used to specify the object database root (usually $GIT_DIR/objects) - -GIT_INDEX_FILE:: - used to specify the index file of the index - -GIT_ALTERNATE_OBJECT_DIRECTORIES:: - used to specify additional object database roots (usually unset) - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-gc.txt b/third_party/git/Documentation/git-gc.txt deleted file mode 100644 index 247f765604..0000000000 --- a/third_party/git/Documentation/git-gc.txt +++ /dev/null @@ -1,162 +0,0 @@ -git-gc(1) -========= - -NAME ----- -git-gc - Cleanup unnecessary files and optimize the local repository - - -SYNOPSIS --------- -[verse] -'git gc' [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack] - -DESCRIPTION ------------ -Runs a number of housekeeping tasks within the current repository, -such as compressing file revisions (to reduce disk space and increase -performance), removing unreachable objects which may have been -created from prior invocations of 'git add', packing refs, pruning -reflog, rerere metadata or stale working trees. May also update ancillary -indexes such as the commit-graph. - -When common porcelain operations that create objects are run, they -will check whether the repository has grown substantially since the -last maintenance, and if so run `git gc` automatically. See `gc.auto` -below for how to disable this behavior. - -Running `git gc` manually should only be needed when adding objects to -a repository without regularly running such porcelain commands, to do -a one-off repository optimization, or e.g. to clean up a suboptimal -mass-import. See the "PACKFILE OPTIMIZATION" section in -linkgit:git-fast-import[1] for more details on the import case. - -OPTIONS -------- - ---aggressive:: - Usually 'git gc' runs very quickly while providing good disk - space utilization and performance. This option will cause - 'git gc' to more aggressively optimize the repository at the expense - of taking much more time. The effects of this optimization are - mostly persistent. See the "AGGRESSIVE" section below for details. - ---auto:: - With this option, 'git gc' checks whether any housekeeping is - required; if not, it exits without performing any work. -+ -See the `gc.auto` option in the "CONFIGURATION" section below for how -this heuristic works. -+ -Once housekeeping is triggered by exceeding the limits of -configuration options such as `gc.auto` and `gc.autoPackLimit`, all -other housekeeping tasks (e.g. rerere, working trees, reflog...) will -be performed as well. - - ---prune=<date>:: - Prune loose objects older than date (default is 2 weeks ago, - overridable by the config variable `gc.pruneExpire`). - --prune=now prunes loose objects regardless of their age and - increases the risk of corruption if another process is writing to - the repository concurrently; see "NOTES" below. --prune is on by - default. - ---no-prune:: - Do not prune any loose objects. - ---quiet:: - Suppress all progress reports. - ---force:: - Force `git gc` to run even if there may be another `git gc` - instance running on this repository. - ---keep-largest-pack:: - All packs except the largest pack and those marked with a - `.keep` files are consolidated into a single pack. When this - option is used, `gc.bigPackThreshold` is ignored. - -AGGRESSIVE ----------- - -When the `--aggressive` option is supplied, linkgit:git-repack[1] will -be invoked with the `-f` flag, which in turn will pass -`--no-reuse-delta` to linkgit:git-pack-objects[1]. This will throw -away any existing deltas and re-compute them, at the expense of -spending much more time on the repacking. - -The effects of this are mostly persistent, e.g. when packs and loose -objects are coalesced into one another pack the existing deltas in -that pack might get re-used, but there are also various cases where we -might pick a sub-optimal delta from a newer pack instead. - -Furthermore, supplying `--aggressive` will tweak the `--depth` and -`--window` options passed to linkgit:git-repack[1]. See the -`gc.aggressiveDepth` and `gc.aggressiveWindow` settings below. By -using a larger window size we're more likely to find more optimal -deltas. - -It's probably not worth it to use this option on a given repository -without running tailored performance benchmarks on it. It takes a lot -more time, and the resulting space/delta optimization may or may not -be worth it. Not using this at all is the right trade-off for most -users and their repositories. - -CONFIGURATION -------------- - -The below documentation is the same as what's found in -linkgit:git-config[1]: - -include::config/gc.txt[] - -NOTES ------ - -'git gc' tries very hard not to delete objects that are referenced -anywhere in your repository. In -particular, it will keep not only objects referenced by your current set -of branches and tags, but also objects referenced by the index, -remote-tracking branches, refs saved by 'git filter-branch' in -refs/original/, reflogs (which may reference commits in branches -that were later amended or rewound), and anything else in the refs/* namespace. -If you are expecting some objects to be deleted and they aren't, check -all of those locations and decide whether it makes sense in your case to -remove those references. - -On the other hand, when 'git gc' runs concurrently with another process, -there is a risk of it deleting an object that the other process is using -but hasn't created a reference to. This may just cause the other process -to fail or may corrupt the repository if the other process later adds a -reference to the deleted object. Git has two features that significantly -mitigate this problem: - -. Any object with modification time newer than the `--prune` date is kept, - along with everything reachable from it. - -. Most operations that add an object to the database update the - modification time of the object if it is already present so that #1 - applies. - -However, these features fall short of a complete solution, so users who -run commands concurrently have to live with some risk of corruption (which -seems to be low in practice). - -HOOKS ------ - -The 'git gc --auto' command will run the 'pre-auto-gc' hook. See -linkgit:githooks[5] for more information. - - -SEE ALSO --------- -linkgit:git-prune[1] -linkgit:git-reflog[1] -linkgit:git-repack[1] -linkgit:git-rerere[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-get-tar-commit-id.txt b/third_party/git/Documentation/git-get-tar-commit-id.txt deleted file mode 100644 index ac44d85b0b..0000000000 --- a/third_party/git/Documentation/git-get-tar-commit-id.txt +++ /dev/null @@ -1,30 +0,0 @@ -git-get-tar-commit-id(1) -======================== - -NAME ----- -git-get-tar-commit-id - Extract commit ID from an archive created using git-archive - - -SYNOPSIS --------- -[verse] -'git get-tar-commit-id' - - -DESCRIPTION ------------ - -Read a tar archive created by 'git archive' from the standard input -and extract the commit ID stored in it. It reads only the first -1024 bytes of input, thus its runtime is not influenced by the size -of the tar archive very much. - -If no commit ID is found, 'git get-tar-commit-id' quietly exists with a -return code of 1. This can happen if the archive had not been created -using 'git archive' or if the first parameter of 'git archive' had been -a tree ID instead of a commit ID or tag. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-grep.txt b/third_party/git/Documentation/git-grep.txt deleted file mode 100644 index 2d27969057..0000000000 --- a/third_party/git/Documentation/git-grep.txt +++ /dev/null @@ -1,335 +0,0 @@ -git-grep(1) -=========== - -NAME ----- -git-grep - Print lines matching a pattern - - -SYNOPSIS --------- -[verse] -'git grep' [-a | --text] [-I] [--textconv] [-i | --ignore-case] [-w | --word-regexp] - [-v | --invert-match] [-h|-H] [--full-name] - [-E | --extended-regexp] [-G | --basic-regexp] - [-P | --perl-regexp] - [-F | --fixed-strings] [-n | --line-number] [--column] - [-l | --files-with-matches] [-L | --files-without-match] - [(-O | --open-files-in-pager) [<pager>]] - [-z | --null] - [ -o | --only-matching ] [-c | --count] [--all-match] [-q | --quiet] - [--max-depth <depth>] [--[no-]recursive] - [--color[=<when>] | --no-color] - [--break] [--heading] [-p | --show-function] - [-A <post-context>] [-B <pre-context>] [-C <context>] - [-W | --function-context] - [--threads <num>] - [-f <file>] [-e] <pattern> - [--and|--or|--not|(|)|-e <pattern>...] - [--recurse-submodules] [--parent-basename <basename>] - [ [--[no-]exclude-standard] [--cached | --no-index | --untracked] | <tree>...] - [--] [<pathspec>...] - -DESCRIPTION ------------ -Look for specified patterns in the tracked files in the work tree, blobs -registered in the index file, or blobs in given tree objects. Patterns -are lists of one or more search expressions separated by newline -characters. An empty string as search expression matches all lines. - - -CONFIGURATION -------------- - -grep.lineNumber:: - If set to true, enable `-n` option by default. - -grep.column:: - If set to true, enable the `--column` option by default. - -grep.patternType:: - Set the default matching behavior. Using a value of 'basic', 'extended', - 'fixed', or 'perl' will enable the `--basic-regexp`, `--extended-regexp`, - `--fixed-strings`, or `--perl-regexp` option accordingly, while the - value 'default' will return to the default matching behavior. - -grep.extendedRegexp:: - If set to true, enable `--extended-regexp` option by default. This - option is ignored when the `grep.patternType` option is set to a value - other than 'default'. - -grep.threads:: - Number of grep worker threads to use. If unset (or set to 0), - 8 threads are used by default (for now). - -grep.fullName:: - If set to true, enable `--full-name` option by default. - -grep.fallbackToNoIndex:: - If set to true, fall back to git grep --no-index if git grep - is executed outside of a git repository. Defaults to false. - - -OPTIONS -------- ---cached:: - Instead of searching tracked files in the working tree, search - blobs registered in the index file. - ---no-index:: - Search files in the current directory that is not managed by Git. - ---untracked:: - In addition to searching in the tracked files in the working - tree, search also in untracked files. - ---no-exclude-standard:: - Also search in ignored files by not honoring the `.gitignore` - mechanism. Only useful with `--untracked`. - ---exclude-standard:: - Do not pay attention to ignored files specified via the `.gitignore` - mechanism. Only useful when searching files in the current directory - with `--no-index`. - ---recurse-submodules:: - Recursively search in each submodule that has been initialized and - checked out in the repository. When used in combination with the - <tree> option the prefix of all submodule output will be the name of - the parent project's <tree> object. - --a:: ---text:: - Process binary files as if they were text. - ---textconv:: - Honor textconv filter settings. - ---no-textconv:: - Do not honor textconv filter settings. - This is the default. - --i:: ---ignore-case:: - Ignore case differences between the patterns and the - files. - --I:: - Don't match the pattern in binary files. - ---max-depth <depth>:: - For each <pathspec> given on command line, descend at most <depth> - levels of directories. A value of -1 means no limit. - This option is ignored if <pathspec> contains active wildcards. - In other words if "a*" matches a directory named "a*", - "*" is matched literally so --max-depth is still effective. - --r:: ---recursive:: - Same as `--max-depth=-1`; this is the default. - ---no-recursive:: - Same as `--max-depth=0`. - --w:: ---word-regexp:: - Match the pattern only at word boundary (either begin at the - beginning of a line, or preceded by a non-word character; end at - the end of a line or followed by a non-word character). - --v:: ---invert-match:: - Select non-matching lines. - --h:: --H:: - By default, the command shows the filename for each - match. `-h` option is used to suppress this output. - `-H` is there for completeness and does not do anything - except it overrides `-h` given earlier on the command - line. - ---full-name:: - When run from a subdirectory, the command usually - outputs paths relative to the current directory. This - option forces paths to be output relative to the project - top directory. - --E:: ---extended-regexp:: --G:: ---basic-regexp:: - Use POSIX extended/basic regexp for patterns. Default - is to use basic regexp. - --P:: ---perl-regexp:: - Use Perl-compatible regular expressions for patterns. -+ -Support for these types of regular expressions is an optional -compile-time dependency. If Git wasn't compiled with support for them -providing this option will cause it to die. - --F:: ---fixed-strings:: - Use fixed strings for patterns (don't interpret pattern - as a regex). - --n:: ---line-number:: - Prefix the line number to matching lines. - ---column:: - Prefix the 1-indexed byte-offset of the first match from the start of the - matching line. - --l:: ---files-with-matches:: ---name-only:: --L:: ---files-without-match:: - Instead of showing every matched line, show only the - names of files that contain (or do not contain) matches. - For better compatibility with 'git diff', `--name-only` is a - synonym for `--files-with-matches`. - --O[<pager>]:: ---open-files-in-pager[=<pager>]:: - Open the matching files in the pager (not the output of 'grep'). - If the pager happens to be "less" or "vi", and the user - specified only one pattern, the first file is positioned at - the first match automatically. The `pager` argument is - optional; if specified, it must be stuck to the option - without a space. If `pager` is unspecified, the default pager - will be used (see `core.pager` in linkgit:git-config[1]). - --z:: ---null:: - Output \0 instead of the character that normally follows a - file name. - --o:: ---only-matching:: - Print only the matched (non-empty) parts of a matching line, with each such - part on a separate output line. - --c:: ---count:: - Instead of showing every matched line, show the number of - lines that match. - ---color[=<when>]:: - Show colored matches. - The value must be always (the default), never, or auto. - ---no-color:: - Turn off match highlighting, even when the configuration file - gives the default to color output. - Same as `--color=never`. - ---break:: - Print an empty line between matches from different files. - ---heading:: - Show the filename above the matches in that file instead of - at the start of each shown line. - --p:: ---show-function:: - Show the preceding line that contains the function name of - the match, unless the matching line is a function name itself. - The name is determined in the same way as 'git diff' works out - patch hunk headers (see 'Defining a custom hunk-header' in - linkgit:gitattributes[5]). - --<num>:: --C <num>:: ---context <num>:: - Show <num> leading and trailing lines, and place a line - containing `--` between contiguous groups of matches. - --A <num>:: ---after-context <num>:: - Show <num> trailing lines, and place a line containing - `--` between contiguous groups of matches. - --B <num>:: ---before-context <num>:: - Show <num> leading lines, and place a line containing - `--` between contiguous groups of matches. - --W:: ---function-context:: - Show the surrounding text from the previous line containing a - function name up to the one before the next function name, - effectively showing the whole function in which the match was - found. - ---threads <num>:: - Number of grep worker threads to use. - See `grep.threads` in 'CONFIGURATION' for more information. - --f <file>:: - Read patterns from <file>, one per line. - --e:: - The next parameter is the pattern. This option has to be - used for patterns starting with `-` and should be used in - scripts passing user input to grep. Multiple patterns are - combined by 'or'. - ---and:: ---or:: ---not:: -( ... ):: - Specify how multiple patterns are combined using Boolean - expressions. `--or` is the default operator. `--and` has - higher precedence than `--or`. `-e` has to be used for all - patterns. - ---all-match:: - When giving multiple pattern expressions combined with `--or`, - this flag is specified to limit the match to files that - have lines to match all of them. - --q:: ---quiet:: - Do not output matched lines; instead, exit with status 0 when - there is a match and with non-zero status when there isn't. - -<tree>...:: - Instead of searching tracked files in the working tree, search - blobs in the given trees. - -\--:: - Signals the end of options; the rest of the parameters - are <pathspec> limiters. - -<pathspec>...:: - If given, limit the search to paths matching at least one pattern. - Both leading paths match and glob(7) patterns are supported. -+ -For more details about the <pathspec> syntax, see the 'pathspec' entry -in linkgit:gitglossary[7]. - -EXAMPLES --------- - -`git grep 'time_t' -- '*.[ch]'`:: - Looks for `time_t` in all tracked .c and .h files in the working - directory and its subdirectories. - -`git grep -e '#define' --and \( -e MAX_PATH -e PATH_MAX \)`:: - Looks for a line that has `#define` and either `MAX_PATH` or - `PATH_MAX`. - -`git grep --all-match -e NODE -e Unexpected`:: - Looks for a line that has `NODE` or `Unexpected` in - files that have lines that match both. - -`git grep solution -- :^Documentation`:: - Looks for `solution`, excluding files in `Documentation`. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-gui.txt b/third_party/git/Documentation/git-gui.txt deleted file mode 100644 index 5f93f8003d..0000000000 --- a/third_party/git/Documentation/git-gui.txt +++ /dev/null @@ -1,127 +0,0 @@ -git-gui(1) -========== - -NAME ----- -git-gui - A portable graphical interface to Git - -SYNOPSIS --------- -[verse] -'git gui' [<command>] [arguments] - -DESCRIPTION ------------ -A Tcl/Tk based graphical user interface to Git. 'git gui' focuses -on allowing users to make changes to their repository by making -new commits, amending existing ones, creating branches, performing -local merges, and fetching/pushing to remote repositories. - -Unlike 'gitk', 'git gui' focuses on commit generation -and single file annotation and does not show project history. -It does however supply menu actions to start a 'gitk' session from -within 'git gui'. - -'git gui' is known to work on all popular UNIX systems, Mac OS X, -and Windows (under both Cygwin and MSYS). To the extent possible -OS specific user interface guidelines are followed, making 'git gui' -a fairly native interface for users. - -COMMANDS --------- -blame:: - Start a blame viewer on the specified file on the given - version (or working directory if not specified). - -browser:: - Start a tree browser showing all files in the specified - commit. Files selected through the - browser are opened in the blame viewer. - -citool:: - Start 'git gui' and arrange to make exactly one commit before - exiting and returning to the shell. The interface is limited - to only commit actions, slightly reducing the application's - startup time and simplifying the menubar. - -version:: - Display the currently running version of 'git gui'. - - -Examples --------- -`git gui blame Makefile`:: - - Show the contents of the file 'Makefile' in the current - working directory, and provide annotations for both the - original author of each line, and who moved the line to its - current location. The uncommitted file is annotated, and - uncommitted changes (if any) are explicitly attributed to - 'Not Yet Committed'. - -`git gui blame v0.99.8 Makefile`:: - - Show the contents of 'Makefile' in revision 'v0.99.8' - and provide annotations for each line. Unlike the above - example the file is read from the object database and not - the working directory. - -`git gui blame --line=100 Makefile`:: - - Loads annotations as described above and automatically - scrolls the view to center on line '100'. - -`git gui citool`:: - - Make one commit and return to the shell when it is complete. - This command returns a non-zero exit code if the window was - closed in any way other than by making a commit. - -`git gui citool --amend`:: - - Automatically enter the 'Amend Last Commit' mode of - the interface. - -`git gui citool --nocommit`:: - - Behave as normal citool, but instead of making a commit - simply terminate with a zero exit code. It still checks - that the index does not contain any unmerged entries, so - you can use it as a GUI version of linkgit:git-mergetool[1] - -`git citool`:: - - Same as `git gui citool` (above). - -`git gui browser maint`:: - - Show a browser for the tree of the 'maint' branch. Files - selected in the browser can be viewed with the internal - blame viewer. - -SEE ALSO --------- -linkgit:gitk[1]:: - The Git repository browser. Shows branches, commit history - and file differences. gitk is the utility started by - 'git gui''s Repository Visualize actions. - -Other ------ -'git gui' is actually maintained as an independent project, but stable -versions are distributed as part of the Git suite for the convenience -of end users. - -A 'git gui' development repository can be obtained from: - - git clone git://repo.or.cz/git-gui.git - -or - - git clone http://repo.or.cz/r/git-gui.git - -or browsed online at http://repo.or.cz/w/git-gui.git/[]. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-hash-object.txt b/third_party/git/Documentation/git-hash-object.txt deleted file mode 100644 index df9e2c58bd..0000000000 --- a/third_party/git/Documentation/git-hash-object.txt +++ /dev/null @@ -1,63 +0,0 @@ -git-hash-object(1) -================== - -NAME ----- -git-hash-object - Compute object ID and optionally creates a blob from a file - - -SYNOPSIS --------- -[verse] -'git hash-object' [-t <type>] [-w] [--path=<file>|--no-filters] [--stdin [--literally]] [--] <file>... -'git hash-object' [-t <type>] [-w] --stdin-paths [--no-filters] - -DESCRIPTION ------------ -Computes the object ID value for an object with specified type -with the contents of the named file (which can be outside of the -work tree), and optionally writes the resulting object into the -object database. Reports its object ID to its standard output. -When <type> is not specified, it defaults to "blob". - -OPTIONS -------- - --t <type>:: - Specify the type (default: "blob"). - --w:: - Actually write the object into the object database. - ---stdin:: - Read the object from standard input instead of from a file. - ---stdin-paths:: - Read file names from the standard input, one per line, instead - of from the command-line. - ---path:: - Hash object as it were located at the given path. The location of - file does not directly influence on the hash value, but path is - used to determine what Git filters should be applied to the object - before it can be placed to the object database, and, as result of - applying filters, the actual blob put into the object database may - differ from the given file. This option is mainly useful for hashing - temporary files located outside of the working directory or files - read from stdin. - ---no-filters:: - Hash the contents as is, ignoring any input filter that would - have been chosen by the attributes mechanism, including the end-of-line - conversion. If the file is read from standard input then this - is always implied, unless the `--path` option is given. - ---literally:: - Allow `--stdin` to hash any garbage into a loose object which might not - otherwise pass standard object parsing or git-fsck checks. Useful for - stress-testing Git itself or reproducing characteristics of corrupt or - bogus objects encountered in the wild. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-help.txt b/third_party/git/Documentation/git-help.txt deleted file mode 100644 index f71db0daa2..0000000000 --- a/third_party/git/Documentation/git-help.txt +++ /dev/null @@ -1,204 +0,0 @@ -git-help(1) -=========== - -NAME ----- -git-help - Display help information about Git - -SYNOPSIS --------- -[verse] -'git help' [-a|--all [--[no-]verbose]] [-g|--guide] - [-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE] - -DESCRIPTION ------------ - -With no options and no COMMAND or GUIDE given, the synopsis of the 'git' -command and a list of the most commonly used Git commands are printed -on the standard output. - -If the option `--all` or `-a` is given, all available commands are -printed on the standard output. - -If the option `--guide` or `-g` is given, a list of the useful -Git guides is also printed on the standard output. - -If a command, or a guide, is given, a manual page for that command or -guide is brought up. The 'man' program is used by default for this -purpose, but this can be overridden by other options or configuration -variables. - -If an alias is given, git shows the definition of the alias on -standard output. To get the manual page for the aliased command, use -`git COMMAND --help`. - -Note that `git --help ...` is identical to `git help ...` because the -former is internally converted into the latter. - -To display the linkgit:git[1] man page, use `git help git`. - -This page can be displayed with 'git help help' or `git help --help` - -OPTIONS -------- --a:: ---all:: - Prints all the available commands on the standard output. This - option overrides any given command or guide name. - ---verbose:: - When used with `--all` print description for all recognized - commands. This is the default. - --c:: ---config:: - List all available configuration variables. This is a short - summary of the list in linkgit:git-config[1]. - --g:: ---guides:: - Prints a list of useful guides on the standard output. This - option overrides any given command or guide name. - --i:: ---info:: - Display manual page for the command in the 'info' format. The - 'info' program will be used for that purpose. - --m:: ---man:: - Display manual page for the command in the 'man' format. This - option may be used to override a value set in the - `help.format` configuration variable. -+ -By default the 'man' program will be used to display the manual page, -but the `man.viewer` configuration variable may be used to choose -other display programs (see below). - --w:: ---web:: - Display manual page for the command in the 'web' (HTML) - format. A web browser will be used for that purpose. -+ -The web browser can be specified using the configuration variable -`help.browser`, or `web.browser` if the former is not set. If none of -these config variables is set, the 'git web{litdd}browse' helper script -(called by 'git help') will pick a suitable default. See -linkgit:git-web{litdd}browse[1] for more information about this. - -CONFIGURATION VARIABLES ------------------------ - -help.format -~~~~~~~~~~~ - -If no command-line option is passed, the `help.format` configuration -variable will be checked. The following values are supported for this -variable; they make 'git help' behave as their corresponding command- -line option: - -* "man" corresponds to '-m|--man', -* "info" corresponds to '-i|--info', -* "web" or "html" correspond to '-w|--web'. - -help.browser, web.browser and browser.<tool>.path -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The `help.browser`, `web.browser` and `browser.<tool>.path` will also -be checked if the 'web' format is chosen (either by command-line -option or configuration variable). See '-w|--web' in the OPTIONS -section above and linkgit:git-web{litdd}browse[1]. - -man.viewer -~~~~~~~~~~ - -The `man.viewer` configuration variable will be checked if the 'man' -format is chosen. The following values are currently supported: - -* "man": use the 'man' program as usual, -* "woman": use 'emacsclient' to launch the "woman" mode in emacs - (this only works starting with emacsclient versions 22), -* "konqueror": use 'kfmclient' to open the man page in a new konqueror - tab (see 'Note about konqueror' below). - -Values for other tools can be used if there is a corresponding -`man.<tool>.cmd` configuration entry (see below). - -Multiple values may be given to the `man.viewer` configuration -variable. Their corresponding programs will be tried in the order -listed in the configuration file. - -For example, this configuration: - ------------------------------------------------- - [man] - viewer = konqueror - viewer = woman ------------------------------------------------- - -will try to use konqueror first. But this may fail (for example, if -DISPLAY is not set) and in that case emacs' woman mode will be tried. - -If everything fails, or if no viewer is configured, the viewer specified -in the `GIT_MAN_VIEWER` environment variable will be tried. If that -fails too, the 'man' program will be tried anyway. - -man.<tool>.path -~~~~~~~~~~~~~~~ - -You can explicitly provide a full path to your preferred man viewer by -setting the configuration variable `man.<tool>.path`. For example, you -can configure the absolute path to konqueror by setting -'man.konqueror.path'. Otherwise, 'git help' assumes the tool is -available in PATH. - -man.<tool>.cmd -~~~~~~~~~~~~~~ - -When the man viewer, specified by the `man.viewer` configuration -variables, is not among the supported ones, then the corresponding -`man.<tool>.cmd` configuration variable will be looked up. If this -variable exists then the specified tool will be treated as a custom -command and a shell eval will be used to run the command with the man -page passed as arguments. - -Note about konqueror -~~~~~~~~~~~~~~~~~~~~ - -When 'konqueror' is specified in the `man.viewer` configuration -variable, we launch 'kfmclient' to try to open the man page on an -already opened konqueror in a new tab if possible. - -For consistency, we also try such a trick if 'man.konqueror.path' is -set to something like `A_PATH_TO/konqueror`. That means we will try to -launch `A_PATH_TO/kfmclient` instead. - -If you really want to use 'konqueror', then you can use something like -the following: - ------------------------------------------------- - [man] - viewer = konq - - [man "konq"] - cmd = A_PATH_TO/konqueror ------------------------------------------------- - -Note about git config --global -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Note that all these configuration variables should probably be set -using the `--global` flag, for example like this: - ------------------------------------------------- -$ git config --global help.format web -$ git config --global web.browser firefox ------------------------------------------------- - -as they are probably more user specific than repository specific. -See linkgit:git-config[1] for more information about this. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-http-backend.txt b/third_party/git/Documentation/git-http-backend.txt deleted file mode 100644 index 558966aa83..0000000000 --- a/third_party/git/Documentation/git-http-backend.txt +++ /dev/null @@ -1,277 +0,0 @@ -git-http-backend(1) -=================== - -NAME ----- -git-http-backend - Server side implementation of Git over HTTP - -SYNOPSIS --------- -[verse] -'git http-backend' - -DESCRIPTION ------------ -A simple CGI program to serve the contents of a Git repository to Git -clients accessing the repository over http:// and https:// protocols. -The program supports clients fetching using both the smart HTTP protocol -and the backwards-compatible dumb HTTP protocol, as well as clients -pushing using the smart HTTP protocol. - -It verifies that the directory has the magic file -"git-daemon-export-ok", and it will refuse to export any Git directory -that hasn't explicitly been marked for export this way (unless the -`GIT_HTTP_EXPORT_ALL` environmental variable is set). - -By default, only the `upload-pack` service is enabled, which serves -'git fetch-pack' and 'git ls-remote' clients, which are invoked from -'git fetch', 'git pull', and 'git clone'. If the client is authenticated, -the `receive-pack` service is enabled, which serves 'git send-pack' -clients, which is invoked from 'git push'. - -SERVICES --------- -These services can be enabled/disabled using the per-repository -configuration file: - -http.getanyfile:: - This serves Git clients older than version 1.6.6 that are unable to use the - upload pack service. When enabled, clients are able to read - any file within the repository, including objects that are - no longer reachable from a branch but are still present. - It is enabled by default, but a repository can disable it - by setting this configuration item to `false`. - -http.uploadpack:: - This serves 'git fetch-pack' and 'git ls-remote' clients. - It is enabled by default, but a repository can disable it - by setting this configuration item to `false`. - -http.receivepack:: - This serves 'git send-pack' clients, allowing push. It is - disabled by default for anonymous users, and enabled by - default for users authenticated by the web server. It can be - disabled by setting this item to `false`, or enabled for all - users, including anonymous users, by setting it to `true`. - -URL TRANSLATION ---------------- -To determine the location of the repository on disk, 'git http-backend' -concatenates the environment variables PATH_INFO, which is set -automatically by the web server, and GIT_PROJECT_ROOT, which must be set -manually in the web server configuration. If GIT_PROJECT_ROOT is not -set, 'git http-backend' reads PATH_TRANSLATED, which is also set -automatically by the web server. - -EXAMPLES --------- -All of the following examples map `http://$hostname/git/foo/bar.git` -to `/var/www/git/foo/bar.git`. - -Apache 2.x:: - Ensure mod_cgi, mod_alias, and mod_env are enabled, set - GIT_PROJECT_ROOT (or DocumentRoot) appropriately, and - create a ScriptAlias to the CGI: -+ ----------------------------------------------------------------- -SetEnv GIT_PROJECT_ROOT /var/www/git -SetEnv GIT_HTTP_EXPORT_ALL -ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/ ----------------------------------------------------------------- -+ -To enable anonymous read access but authenticated write access, -require authorization for both the initial ref advertisement (which we -detect as a push via the service parameter in the query string), and the -receive-pack invocation itself: -+ ----------------------------------------------------------------- -RewriteCond %{QUERY_STRING} service=git-receive-pack [OR] -RewriteCond %{REQUEST_URI} /git-receive-pack$ -RewriteRule ^/git/ - [E=AUTHREQUIRED:yes] - -<LocationMatch "^/git/"> - Order Deny,Allow - Deny from env=AUTHREQUIRED - - AuthType Basic - AuthName "Git Access" - Require group committers - Satisfy Any - ... -</LocationMatch> ----------------------------------------------------------------- -+ -If you do not have `mod_rewrite` available to match against the query -string, it is sufficient to just protect `git-receive-pack` itself, -like: -+ ----------------------------------------------------------------- -<LocationMatch "^/git/.*/git-receive-pack$"> - AuthType Basic - AuthName "Git Access" - Require group committers - ... -</LocationMatch> ----------------------------------------------------------------- -+ -In this mode, the server will not request authentication until the -client actually starts the object negotiation phase of the push, rather -than during the initial contact. For this reason, you must also enable -the `http.receivepack` config option in any repositories that should -accept a push. The default behavior, if `http.receivepack` is not set, -is to reject any pushes by unauthenticated users; the initial request -will therefore report `403 Forbidden` to the client, without even giving -an opportunity for authentication. -+ -To require authentication for both reads and writes, use a Location -directive around the repository, or one of its parent directories: -+ ----------------------------------------------------------------- -<Location /git/private> - AuthType Basic - AuthName "Private Git Access" - Require group committers - ... -</Location> ----------------------------------------------------------------- -+ -To serve gitweb at the same url, use a ScriptAliasMatch to only -those URLs that 'git http-backend' can handle, and forward the -rest to gitweb: -+ ----------------------------------------------------------------- -ScriptAliasMatch \ - "(?x)^/git/(.*/(HEAD | \ - info/refs | \ - objects/(info/[^/]+ | \ - [0-9a-f]{2}/[0-9a-f]{38} | \ - pack/pack-[0-9a-f]{40}\.(pack|idx)) | \ - git-(upload|receive)-pack))$" \ - /usr/libexec/git-core/git-http-backend/$1 - -ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/ ----------------------------------------------------------------- -+ -To serve multiple repositories from different linkgit:gitnamespaces[7] in a -single repository: -+ ----------------------------------------------------------------- -SetEnvIf Request_URI "^/git/([^/]*)" GIT_NAMESPACE=$1 -ScriptAliasMatch ^/git/[^/]*(.*) /usr/libexec/git-core/git-http-backend/storage.git$1 ----------------------------------------------------------------- - -Accelerated static Apache 2.x:: - Similar to the above, but Apache can be used to return static - files that are stored on disk. On many systems this may - be more efficient as Apache can ask the kernel to copy the - file contents from the file system directly to the network: -+ ----------------------------------------------------------------- -SetEnv GIT_PROJECT_ROOT /var/www/git - -AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /var/www/git/$1 -AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1 -ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/ ----------------------------------------------------------------- -+ -This can be combined with the gitweb configuration: -+ ----------------------------------------------------------------- -SetEnv GIT_PROJECT_ROOT /var/www/git - -AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /var/www/git/$1 -AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1 -ScriptAliasMatch \ - "(?x)^/git/(.*/(HEAD | \ - info/refs | \ - objects/info/[^/]+ | \ - git-(upload|receive)-pack))$" \ - /usr/libexec/git-core/git-http-backend/$1 -ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/ ----------------------------------------------------------------- - -Lighttpd:: - Ensure that `mod_cgi`, `mod_alias`, `mod_auth`, `mod_setenv` are - loaded, then set `GIT_PROJECT_ROOT` appropriately and redirect - all requests to the CGI: -+ ----------------------------------------------------------------- -alias.url += ( "/git" => "/usr/lib/git-core/git-http-backend" ) -$HTTP["url"] =~ "^/git" { - cgi.assign = ("" => "") - setenv.add-environment = ( - "GIT_PROJECT_ROOT" => "/var/www/git", - "GIT_HTTP_EXPORT_ALL" => "" - ) -} ----------------------------------------------------------------- -+ -To enable anonymous read access but authenticated write access: -+ ----------------------------------------------------------------- -$HTTP["querystring"] =~ "service=git-receive-pack" { - include "git-auth.conf" -} -$HTTP["url"] =~ "^/git/.*/git-receive-pack$" { - include "git-auth.conf" -} ----------------------------------------------------------------- -+ -where `git-auth.conf` looks something like: -+ ----------------------------------------------------------------- -auth.require = ( - "/" => ( - "method" => "basic", - "realm" => "Git Access", - "require" => "valid-user" - ) -) -# ...and set up auth.backend here ----------------------------------------------------------------- -+ -To require authentication for both reads and writes: -+ ----------------------------------------------------------------- -$HTTP["url"] =~ "^/git/private" { - include "git-auth.conf" -} ----------------------------------------------------------------- - - -ENVIRONMENT ------------ -'git http-backend' relies upon the `CGI` environment variables set -by the invoking web server, including: - -* PATH_INFO (if GIT_PROJECT_ROOT is set, otherwise PATH_TRANSLATED) -* REMOTE_USER -* REMOTE_ADDR -* CONTENT_TYPE -* QUERY_STRING -* REQUEST_METHOD - -The `GIT_HTTP_EXPORT_ALL` environmental variable may be passed to -'git-http-backend' to bypass the check for the "git-daemon-export-ok" -file in each repository before allowing export of that repository. - -The `GIT_HTTP_MAX_REQUEST_BUFFER` environment variable (or the -`http.maxRequestBuffer` config variable) may be set to change the -largest ref negotiation request that git will handle during a fetch; any -fetch requiring a larger buffer will not succeed. This value should not -normally need to be changed, but may be helpful if you are fetching from -a repository with an extremely large number of refs. The value can be -specified with a unit (e.g., `100M` for 100 megabytes). The default is -10 megabytes. - -The backend process sets GIT_COMMITTER_NAME to '$REMOTE_USER' and -GIT_COMMITTER_EMAIL to '$\{REMOTE_USER}@http.$\{REMOTE_ADDR\}', -ensuring that any reflogs created by 'git-receive-pack' contain some -identifying information of the remote user who performed the push. - -All `CGI` environment variables are available to each of the hooks -invoked by the 'git-receive-pack'. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-http-fetch.txt b/third_party/git/Documentation/git-http-fetch.txt deleted file mode 100644 index 666b042679..0000000000 --- a/third_party/git/Documentation/git-http-fetch.txt +++ /dev/null @@ -1,49 +0,0 @@ -git-http-fetch(1) -================= - -NAME ----- -git-http-fetch - Download from a remote Git repository via HTTP - - -SYNOPSIS --------- -[verse] -'git http-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin] <commit> <url> - -DESCRIPTION ------------ -Downloads a remote Git repository via HTTP. - -This command always gets all objects. Historically, there were three options -`-a`, `-c` and `-t` for choosing which objects to download. They are now -silently ignored. - -OPTIONS -------- -commit-id:: - Either the hash or the filename under [URL]/refs/ to - pull. - --a, -c, -t:: - These options are ignored for historical reasons. --v:: - Report what is downloaded. - --w <filename>:: - Writes the commit-id into the filename under $GIT_DIR/refs/<filename> on - the local end after the transfer is complete. - ---stdin:: - Instead of a commit id on the command line (which is not expected in this - case), 'git http-fetch' expects lines on stdin in the format - - <commit-id>['\t'<filename-as-in--w>] - ---recover:: - Verify that everything reachable from target is fetched. Used after - an earlier fetch is interrupted. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-http-push.txt b/third_party/git/Documentation/git-http-push.txt deleted file mode 100644 index ea03a4eeb0..0000000000 --- a/third_party/git/Documentation/git-http-push.txt +++ /dev/null @@ -1,97 +0,0 @@ -git-http-push(1) -================ - -NAME ----- -git-http-push - Push objects over HTTP/DAV to another repository - - -SYNOPSIS --------- -[verse] -'git http-push' [--all] [--dry-run] [--force] [--verbose] <url> <ref> [<ref>...] - -DESCRIPTION ------------ -Sends missing objects to remote repository, and updates the -remote branch. - -*NOTE*: This command is temporarily disabled if your libcurl -is older than 7.16, as the combination has been reported -not to work and sometimes corrupts repository. - -OPTIONS -------- ---all:: - Do not assume that the remote repository is complete in its - current state, and verify all objects in the entire local - ref's history exist in the remote repository. - ---force:: - Usually, the command refuses to update a remote ref that - is not an ancestor of the local ref used to overwrite it. - This flag disables the check. What this means is that - the remote repository can lose commits; use it with - care. - ---dry-run:: - Do everything except actually send the updates. - ---verbose:: - Report the list of objects being walked locally and the - list of objects successfully sent to the remote repository. - --d:: --D:: - Remove <ref> from remote repository. The specified branch - cannot be the remote HEAD. If -d is specified the following - other conditions must also be met: - - - Remote HEAD must resolve to an object that exists locally - - Specified branch resolves to an object that exists locally - - Specified branch is an ancestor of the remote HEAD - -<ref>...:: - The remote refs to update. - - -SPECIFYING THE REFS -------------------- - -A '<ref>' specification can be either a single pattern, or a pair -of such patterns separated by a colon ":" (this means that a ref name -cannot have a colon in it). A single pattern '<name>' is just a -shorthand for '<name>:<name>'. - -Each pattern pair consists of the source side (before the colon) -and the destination side (after the colon). The ref to be -pushed is determined by finding a match that matches the source -side, and where it is pushed is determined by using the -destination side. - - - It is an error if <src> does not match exactly one of the - local refs. - - - If <dst> does not match any remote ref, either - - * it has to start with "refs/"; <dst> is used as the - destination literally in this case. - - * <src> == <dst> and the ref that matched the <src> must not - exist in the set of remote refs; the ref matched <src> - locally is used as the name of the destination. - -Without `--force`, the <src> ref is stored at the remote only if -<dst> does not exist, or <dst> is a proper subset (i.e. an -ancestor) of <src>. This check, known as "fast-forward check", -is performed in order to avoid accidentally overwriting the -remote ref and lose other peoples' commits from there. - -With `--force`, the fast-forward check is disabled for all refs. - -Optionally, a <ref> parameter can be prefixed with a plus '+' sign -to disable the fast-forward check only on that ref. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-imap-send.txt b/third_party/git/Documentation/git-imap-send.txt deleted file mode 100644 index 65b53fcc47..0000000000 --- a/third_party/git/Documentation/git-imap-send.txt +++ /dev/null @@ -1,140 +0,0 @@ -git-imap-send(1) -================ - -NAME ----- -git-imap-send - Send a collection of patches from stdin to an IMAP folder - - -SYNOPSIS --------- -[verse] -'git imap-send' [-v] [-q] [--[no-]curl] - - -DESCRIPTION ------------ -This command uploads a mailbox generated with 'git format-patch' -into an IMAP drafts folder. This allows patches to be sent as -other email is when using mail clients that cannot read mailbox -files directly. The command also works with any general mailbox -in which emails have the fields "From", "Date", and "Subject" in -that order. - -Typical usage is something like: - -git format-patch --signoff --stdout --attach origin | git imap-send - - -OPTIONS -------- - --v:: ---verbose:: - Be verbose. - --q:: ---quiet:: - Be quiet. - ---curl:: - Use libcurl to communicate with the IMAP server, unless tunneling - into it. Ignored if Git was built without the USE_CURL_FOR_IMAP_SEND - option set. - ---no-curl:: - Talk to the IMAP server using git's own IMAP routines instead of - using libcurl. Ignored if Git was built with the NO_OPENSSL option - set. - - -CONFIGURATION -------------- - -To use the tool, imap.folder and either imap.tunnel or imap.host must be set -to appropriate values. - -Variables -~~~~~~~~~ - -include::config/imap.txt[] - -Examples -~~~~~~~~ - -Using tunnel mode: - -.......................... -[imap] - folder = "INBOX.Drafts" - tunnel = "ssh -q -C user@example.com /usr/bin/imapd ./Maildir 2> /dev/null" -.......................... - -Using direct mode: - -......................... -[imap] - folder = "INBOX.Drafts" - host = imap://imap.example.com - user = bob - pass = p4ssw0rd -......................... - -Using direct mode with SSL: - -......................... -[imap] - folder = "INBOX.Drafts" - host = imaps://imap.example.com - user = bob - pass = p4ssw0rd - port = 123 - sslverify = false -......................... - - -EXAMPLES --------- -To submit patches using GMail's IMAP interface, first, edit your ~/.gitconfig -to specify your account settings: - ---------- -[imap] - folder = "[Gmail]/Drafts" - host = imaps://imap.gmail.com - user = user@gmail.com - port = 993 - sslverify = false ---------- - -You might need to instead use: folder = "[Google Mail]/Drafts" if you get an error -that the "Folder doesn't exist". - -Once the commits are ready to be sent, run the following command: - - $ git format-patch --cover-letter -M --stdout origin/master | git imap-send - -Just make sure to disable line wrapping in the email client (GMail's web -interface will wrap lines no matter what, so you need to use a real -IMAP client). - -CAUTION -------- -It is still your responsibility to make sure that the email message -sent by your email program meets the standards of your project. -Many projects do not like patches to be attached. Some mail -agents will transform patches (e.g. wrap lines, send them as -format=flowed) in ways that make them fail. You will get angry -flames ridiculing you if you don't check this. - -Thunderbird in particular is known to be problematic. Thunderbird -users may wish to visit this web page for more information: - http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email - -SEE ALSO --------- -linkgit:git-format-patch[1], linkgit:git-send-email[1], mbox(5) - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-index-pack.txt b/third_party/git/Documentation/git-index-pack.txt deleted file mode 100644 index d5b7560bfe..0000000000 --- a/third_party/git/Documentation/git-index-pack.txt +++ /dev/null @@ -1,108 +0,0 @@ -git-index-pack(1) -================= - -NAME ----- -git-index-pack - Build pack index file for an existing packed archive - - -SYNOPSIS --------- -[verse] -'git index-pack' [-v] [-o <index-file>] <pack-file> -'git index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>] - [<pack-file>] - - -DESCRIPTION ------------ -Reads a packed archive (.pack) from the specified file, and -builds a pack index file (.idx) for it. The packed archive -together with the pack index can then be placed in the -objects/pack/ directory of a Git repository. - - -OPTIONS -------- --v:: - Be verbose about what is going on, including progress status. - --o <index-file>:: - Write the generated pack index into the specified - file. Without this option the name of pack index - file is constructed from the name of packed archive - file by replacing .pack with .idx (and the program - fails if the name of packed archive does not end - with .pack). - ---stdin:: - When this flag is provided, the pack is read from stdin - instead and a copy is then written to <pack-file>. If - <pack-file> is not specified, the pack is written to - objects/pack/ directory of the current Git repository with - a default name determined from the pack content. If - <pack-file> is not specified consider using --keep to - prevent a race condition between this process and - 'git repack'. - ---fix-thin:: - Fix a "thin" pack produced by `git pack-objects --thin` (see - linkgit:git-pack-objects[1] for details) by adding the - excluded objects the deltified objects are based on to the - pack. This option only makes sense in conjunction with --stdin. - ---keep:: - Before moving the index into its final destination - create an empty .keep file for the associated pack file. - This option is usually necessary with --stdin to prevent a - simultaneous 'git repack' process from deleting - the newly constructed pack and index before refs can be - updated to use objects contained in the pack. - ---keep=<msg>:: - Like --keep create a .keep file before moving the index into - its final destination, but rather than creating an empty file - place '<msg>' followed by an LF into the .keep file. The '<msg>' - message can later be searched for within all .keep files to - locate any which have outlived their usefulness. - ---index-version=<version>[,<offset>]:: - This is intended to be used by the test suite only. It allows - to force the version for the generated pack index, and to force - 64-bit index entries on objects located above the given offset. - ---strict:: - Die, if the pack contains broken objects or links. - ---check-self-contained-and-connected:: - Die if the pack contains broken links. For internal use only. - ---fsck-objects:: - Die if the pack contains broken objects. For internal use only. - ---threads=<n>:: - Specifies the number of threads to spawn when resolving - deltas. This requires that index-pack be compiled with - pthreads otherwise this option is ignored with a warning. - This is meant to reduce packing time on multiprocessor - machines. The required amount of memory for the delta search - window is however multiplied by the number of threads. - 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>. - -NOTES ------ - -Once the index has been created, the list of object names is sorted -and the SHA-1 hash of that list is printed to stdout. If --stdin was -also used then this is prefixed by either "pack\t", or "keep\t" if a -new .keep file was successfully created. This is useful to remove a -.keep file used as a lock to prevent the race with 'git repack' -mentioned above. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-init-db.txt b/third_party/git/Documentation/git-init-db.txt deleted file mode 100644 index 648a6cd78a..0000000000 --- a/third_party/git/Documentation/git-init-db.txt +++ /dev/null @@ -1,23 +0,0 @@ -git-init-db(1) -============== - -NAME ----- -git-init-db - Creates an empty Git repository - - -SYNOPSIS --------- -[verse] -'git init-db' [-q | --quiet] [--bare] [--template=<template_directory>] [--separate-git-dir <git dir>] [--shared[=<permissions>]] - - -DESCRIPTION ------------ - -This is a synonym for linkgit:git-init[1]. Please refer to the -documentation of that command. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-init.txt b/third_party/git/Documentation/git-init.txt deleted file mode 100644 index 32880aafb0..0000000000 --- a/third_party/git/Documentation/git-init.txt +++ /dev/null @@ -1,154 +0,0 @@ -git-init(1) -=========== - -NAME ----- -git-init - Create an empty Git repository or reinitialize an existing one - - -SYNOPSIS --------- -[verse] -'git init' [-q | --quiet] [--bare] [--template=<template_directory>] - [--separate-git-dir <git dir>] - [--shared[=<permissions>]] [directory] - - -DESCRIPTION ------------ - -This command creates an empty Git repository - basically a `.git` -directory with subdirectories for `objects`, `refs/heads`, -`refs/tags`, and template files. An initial `HEAD` file that -references the HEAD of the master branch is also created. - -If the `$GIT_DIR` environment variable is set then it specifies a path -to use instead of `./.git` for the base of the repository. - -If the object storage directory is specified via the -`$GIT_OBJECT_DIRECTORY` environment variable then the sha1 directories -are created underneath - otherwise the default `$GIT_DIR/objects` -directory is used. - -Running 'git init' in an existing repository is safe. It will not -overwrite things that are already there. The primary reason for -rerunning 'git init' is to pick up newly added templates (or to move -the repository to another place if --separate-git-dir is given). - -OPTIONS -------- - --q:: ---quiet:: - -Only print error and warning messages; all other output will be suppressed. - ---bare:: - -Create a bare repository. If `GIT_DIR` environment is not set, it is set to the -current working directory. - ---template=<template_directory>:: - -Specify the directory from which templates will be used. (See the "TEMPLATE -DIRECTORY" section below.) - ---separate-git-dir=<git dir>:: - -Instead of initializing the repository as a directory to either `$GIT_DIR` or -`./.git/`, create a text file there containing the path to the actual -repository. This file acts as filesystem-agnostic Git symbolic link to the -repository. -+ -If this is reinitialization, the repository will be moved to the specified path. - ---shared[=(false|true|umask|group|all|world|everybody|0xxx)]:: - -Specify that the Git repository is to be shared amongst several users. This -allows users belonging to the same group to push into that -repository. When specified, the config variable "core.sharedRepository" is -set so that files and directories under `$GIT_DIR` are created with the -requested permissions. When not specified, Git will use permissions reported -by umask(2). -+ -The option can have the following values, defaulting to 'group' if no value -is given: -+ --- -'umask' (or 'false'):: - -Use permissions reported by umask(2). The default, when `--shared` is not -specified. - -'group' (or 'true'):: - -Make the repository group-writable, (and g+sx, since the git group may be not -the primary group of all users). This is used to loosen the permissions of an -otherwise safe umask(2) value. Note that the umask still applies to the other -permission bits (e.g. if umask is '0022', using 'group' will not remove read -privileges from other (non-group) users). See '0xxx' for how to exactly specify -the repository permissions. - -'all' (or 'world' or 'everybody'):: - -Same as 'group', but make the repository readable by all users. - -'0xxx':: - -'0xxx' is an octal number and each file will have mode '0xxx'. '0xxx' will -override users' umask(2) value (and not only loosen permissions as 'group' and -'all' does). '0640' will create a repository which is group-readable, but not -group-writable or accessible to others. '0660' will create a repo that is -readable and writable to the current user and group, but inaccessible to others. --- - -By default, the configuration flag `receive.denyNonFastForwards` is enabled -in shared repositories, so that you cannot force a non fast-forwarding push -into it. - -If you provide a 'directory', the command is run inside it. If this directory -does not exist, it will be created. - -TEMPLATE DIRECTORY ------------------- - -Files and directories in the template directory whose name do not start with a -dot will be copied to the `$GIT_DIR` after it is created. - -The template directory will be one of the following (in order): - - - the argument given with the `--template` option; - - - the contents of the `$GIT_TEMPLATE_DIR` environment variable; - - - the `init.templateDir` configuration variable; or - - - the default template directory: `/usr/share/git-core/templates`. - -The default template directory includes some directory structure, suggested -"exclude patterns" (see linkgit:gitignore[5]), and sample hook files. - -The sample hooks are all disabled by default. To enable one of the -sample hooks rename it by removing its `.sample` suffix. - -See linkgit:githooks[5] for more general info on hook execution. - -EXAMPLES --------- - -Start a new Git repository for an existing code base:: -+ ----------------- -$ cd /path/to/my/codebase -$ git init <1> -$ git add . <2> -$ git commit <3> ----------------- -+ -<1> Create a /path/to/my/codebase/.git directory. -<2> Add all existing files to the index. -<3> Record the pristine state as the first commit in the history. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-instaweb.txt b/third_party/git/Documentation/git-instaweb.txt deleted file mode 100644 index a54fe4401b..0000000000 --- a/third_party/git/Documentation/git-instaweb.txt +++ /dev/null @@ -1,94 +0,0 @@ -git-instaweb(1) -=============== - -NAME ----- -git-instaweb - Instantly browse your working repository in gitweb - -SYNOPSIS --------- -[verse] -'git instaweb' [--local] [--httpd=<httpd>] [--port=<port>] - [--browser=<browser>] -'git instaweb' [--start] [--stop] [--restart] - -DESCRIPTION ------------ -A simple script to set up `gitweb` and a web server for browsing the local -repository. - -OPTIONS -------- - --l:: ---local:: - Only bind the web server to the local IP (127.0.0.1). - --d:: ---httpd:: - The HTTP daemon command-line that will be executed. - Command-line options may be specified here, and the - configuration file will be added at the end of the command-line. - Currently apache2, lighttpd, mongoose, plackup, python and - webrick are supported. - (Default: lighttpd) - --m:: ---module-path:: - The module path (only needed if httpd is Apache). - (Default: /usr/lib/apache2/modules) - --p:: ---port:: - The port number to bind the httpd to. (Default: 1234) - --b:: ---browser:: - The web browser that should be used to view the gitweb - page. This will be passed to the 'git web{litdd}browse' helper - script along with the URL of the gitweb instance. See - linkgit:git-web{litdd}browse[1] for more information about this. If - the script fails, the URL will be printed to stdout. - -start:: ---start:: - Start the httpd instance and exit. Regenerate configuration files - as necessary for spawning a new instance. - -stop:: ---stop:: - Stop the httpd instance and exit. This does not generate - any of the configuration files for spawning a new instance, - nor does it close the browser. - -restart:: ---restart:: - Restart the httpd instance and exit. Regenerate configuration files - as necessary for spawning a new instance. - -CONFIGURATION -------------- - -You may specify configuration in your .git/config - ------------------------------------------------------------------------ -[instaweb] - local = true - httpd = apache2 -f - port = 4321 - browser = konqueror - modulePath = /usr/lib/apache2/modules - ------------------------------------------------------------------------ - -If the configuration variable `instaweb.browser` is not set, -`web.browser` will be used instead if it is defined. See -linkgit:git-web{litdd}browse[1] for more information about this. - -SEE ALSO --------- -linkgit:gitweb[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-interpret-trailers.txt b/third_party/git/Documentation/git-interpret-trailers.txt deleted file mode 100644 index 96ec6499f0..0000000000 --- a/third_party/git/Documentation/git-interpret-trailers.txt +++ /dev/null @@ -1,390 +0,0 @@ -git-interpret-trailers(1) -========================= - -NAME ----- -git-interpret-trailers - Add or parse structured information in commit messages - -SYNOPSIS --------- -[verse] -'git interpret-trailers' [<options>] [(--trailer <token>[(=|:)<value>])...] [<file>...] -'git interpret-trailers' [<options>] [--parse] [<file>...] - -DESCRIPTION ------------ -Help parsing or adding 'trailers' lines, that look similar to RFC 822 e-mail -headers, at the end of the otherwise free-form part of a commit -message. - -This command reads some patches or commit messages from either the -<file> arguments or the standard input if no <file> is specified. If -`--parse` is specified, the output consists of the parsed trailers. - -Otherwise, this command applies the arguments passed using the -`--trailer` option, if any, to the commit message part of each input -file. The result is emitted on the standard output. - -Some configuration variables control the way the `--trailer` arguments -are applied to each commit message and the way any existing trailer in -the commit message is changed. They also make it possible to -automatically add some trailers. - -By default, a '<token>=<value>' or '<token>:<value>' argument given -using `--trailer` will be appended after the existing trailers only if -the last trailer has a different (<token>, <value>) pair (or if there -is no existing trailer). The <token> and <value> parts will be trimmed -to remove starting and trailing whitespace, and the resulting trimmed -<token> and <value> will appear in the message like this: - ------------------------------------------------- -token: value ------------------------------------------------- - -This means that the trimmed <token> and <value> will be separated by -`': '` (one colon followed by one space). - -By default the new trailer will appear at the end of all the existing -trailers. If there is no existing trailer, the new trailer will appear -after the commit message part of the output, and, if there is no line -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 (i) is all trailers, or (ii) contains at -least one Git-generated or user-configured 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 '---' (followed by a -space or the end of the line). Such three minus signs start the patch -part of the message. See also `--no-divider` below. - -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. 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 encoding rules and probably many other rules. - -OPTIONS -------- ---in-place:: - Edit the files in place. - ---trim-empty:: - If the <value> part of any trailer contains only whitespace, - the whole trailer will be removed from the resulting message. - This applies to existing trailers as well as new trailers. - ---trailer <token>[(=|:)<value>]:: - Specify a (<token>, <value>) pair that should be applied as a - trailer to the input messages. See the description of this - command. - ---where <placement>:: ---no-where:: - Specify where all new trailers will be added. A setting - provided with '--where' overrides all configuration variables - and applies to all '--trailer' options until the next occurrence of - '--where' or '--no-where'. Possible values are `after`, `before`, - `end` or `start`. - ---if-exists <action>:: ---no-if-exists:: - Specify what action will be performed when there is already at - least one trailer with the same <token> in the message. A setting - provided with '--if-exists' overrides all configuration variables - and applies to all '--trailer' options until the next occurrence of - '--if-exists' or '--no-if-exists'. Possible actions are `addIfDifferent`, - `addIfDifferentNeighbor`, `add`, `replace` and `doNothing`. - ---if-missing <action>:: ---no-if-missing:: - Specify what action will be performed when there is no other - trailer with the same <token> in the message. A setting - provided with '--if-missing' overrides all configuration variables - and applies to all '--trailer' options until the next occurrence of - '--if-missing' or '--no-if-missing'. Possible actions are `doNothing` - or `add`. - ---only-trailers:: - Output only the trailers, not any other parts of the input. - ---only-input:: - Output only trailers that exist in the input; do not add any - from the command-line or by following configured `trailer.*` - rules. - ---unfold:: - Remove any whitespace-continuation in trailers, so that each - trailer appears on a line by itself with its full content. - ---parse:: - A convenience alias for `--only-trailers --only-input - --unfold`. - ---no-divider:: - Do not treat `---` as the end of the commit message. Use this - when you know your input contains just the commit message itself - (and not an email or the output of `git format-patch`). - -CONFIGURATION VARIABLES ------------------------ - -trailer.separators:: - This option tells which characters are recognized as trailer - separators. By default only ':' is recognized as a trailer - separator, except that '=' is always accepted on the command - line for compatibility with other git commands. -+ -The first character given by this option will be the default character -used when another separator is not specified in the config for this -trailer. -+ -For example, if the value for this option is "%=$", then only lines -using the format '<token><sep><value>' with <sep> containing '%', '=' -or '$' and then spaces will be considered trailers. And '%' will be -the default separator used, so by default trailers will appear like: -'<token>% <value>' (one percent sign and one space will appear between -the token and the value). - -trailer.where:: - This option tells where a new trailer will be added. -+ -This can be `end`, which is the default, `start`, `after` or `before`. -+ -If it is `end`, then each new trailer will appear at the end of the -existing trailers. -+ -If it is `start`, then each new trailer will appear at the start, -instead of the end, of the existing trailers. -+ -If it is `after`, then each new trailer will appear just after the -last trailer with the same <token>. -+ -If it is `before`, then each new trailer will appear just before the -first trailer with the same <token>. - -trailer.ifexists:: - This option makes it possible to choose what action will be - performed when there is already at least one trailer with the - same <token> in the message. -+ -The valid values for this option are: `addIfDifferentNeighbor` (this -is the default), `addIfDifferent`, `add`, `replace` or `doNothing`. -+ -With `addIfDifferentNeighbor`, a new trailer will be added only if no -trailer with the same (<token>, <value>) pair is above or below the line -where the new trailer will be added. -+ -With `addIfDifferent`, a new trailer will be added only if no trailer -with the same (<token>, <value>) pair is already in the message. -+ -With `add`, a new trailer will be added, even if some trailers with -the same (<token>, <value>) pair are already in the message. -+ -With `replace`, an existing trailer with the same <token> will be -deleted and the new trailer will be added. The deleted trailer will be -the closest one (with the same <token>) to the place where the new one -will be added. -+ -With `doNothing`, nothing will be done; that is no new trailer will be -added if there is already one with the same <token> in the message. - -trailer.ifmissing:: - This option makes it possible to choose what action will be - performed when there is not yet any trailer with the same - <token> in the message. -+ -The valid values for this option are: `add` (this is the default) and -`doNothing`. -+ -With `add`, a new trailer will be added. -+ -With `doNothing`, nothing will be done. - -trailer.<token>.key:: - This `key` will be used instead of <token> in the trailer. At - the end of this key, a separator can appear and then some - space characters. By default the only valid separator is ':', - but this can be changed using the `trailer.separators` config - variable. -+ -If there is a separator, then the key will be used instead of both the -<token> and the default separator when adding the trailer. - -trailer.<token>.where:: - This option takes the same values as the 'trailer.where' - configuration variable and it overrides what is specified by - that option for trailers with the specified <token>. - -trailer.<token>.ifexists:: - This option takes the same values as the 'trailer.ifexists' - configuration variable and it overrides what is specified by - that option for trailers with the specified <token>. - -trailer.<token>.ifmissing:: - This option takes the same values as the 'trailer.ifmissing' - configuration variable and it overrides what is specified by - that option for trailers with the specified <token>. - -trailer.<token>.command:: - This option can be used to specify a shell command that will - be called to automatically add or modify a trailer with the - specified <token>. -+ -When this option is specified, the behavior is as if a special -'<token>=<value>' argument were added at the beginning of the command -line, where <value> is taken to be the standard output of the -specified command with any leading and trailing whitespace trimmed -off. -+ -If the command contains the `$ARG` string, this string will be -replaced with the <value> part of an existing trailer with the same -<token>, if any, before the command is launched. -+ -If some '<token>=<value>' arguments are also passed on the command -line, when a 'trailer.<token>.command' is configured, the command will -also be executed for each of these arguments. And the <value> part of -these arguments, if any, will be used to replace the `$ARG` string in -the command. - -EXAMPLES --------- - -* Configure a 'sign' trailer with a 'Signed-off-by' key, and then - add two of these trailers to a message: -+ ------------- -$ git config trailer.sign.key "Signed-off-by" -$ cat msg.txt -subject - -message -$ cat msg.txt | git interpret-trailers --trailer 'sign: Alice <alice@example.com>' --trailer 'sign: Bob <bob@example.com>' -subject - -message - -Signed-off-by: Alice <alice@example.com> -Signed-off-by: Bob <bob@example.com> ------------- - -* Use the `--in-place` option to edit a message file in place: -+ ------------- -$ cat msg.txt -subject - -message - -Signed-off-by: Bob <bob@example.com> -$ git interpret-trailers --trailer 'Acked-by: Alice <alice@example.com>' --in-place msg.txt -$ cat msg.txt -subject - -message - -Signed-off-by: Bob <bob@example.com> -Acked-by: Alice <alice@example.com> ------------- - -* Extract the last commit as a patch, and add a 'Cc' and a - 'Reviewed-by' trailer to it: -+ ------------- -$ git format-patch -1 -0001-foo.patch -$ git interpret-trailers --trailer 'Cc: Alice <alice@example.com>' --trailer 'Reviewed-by: Bob <bob@example.com>' 0001-foo.patch >0001-bar.patch ------------- - -* Configure a 'sign' trailer with a command to automatically add a - 'Signed-off-by: ' with the author information only if there is no - 'Signed-off-by: ' already, and show how it works: -+ ------------- -$ git config trailer.sign.key "Signed-off-by: " -$ git config trailer.sign.ifmissing add -$ git config trailer.sign.ifexists doNothing -$ git config trailer.sign.command 'echo "$(git config user.name) <$(git config user.email)>"' -$ git interpret-trailers <<EOF -> EOF - -Signed-off-by: Bob <bob@example.com> -$ git interpret-trailers <<EOF -> Signed-off-by: Alice <alice@example.com> -> EOF - -Signed-off-by: Alice <alice@example.com> ------------- - -* Configure a 'fix' trailer with a key that contains a '#' and no - space after this character, and show how it works: -+ ------------- -$ git config trailer.separators ":#" -$ git config trailer.fix.key "Fix #" -$ echo "subject" | git interpret-trailers --trailer fix=42 -subject - -Fix #42 ------------- - -* Configure a 'see' trailer with a command to show the subject of a - commit that is related, and show how it works: -+ ------------- -$ git config trailer.see.key "See-also: " -$ git config trailer.see.ifExists "replace" -$ git config trailer.see.ifMissing "doNothing" -$ git config trailer.see.command "git log -1 --oneline --format=\"%h (%s)\" --abbrev-commit --abbrev=14 \$ARG" -$ git interpret-trailers <<EOF -> subject -> -> message -> -> see: HEAD~2 -> EOF -subject - -message - -See-also: fe3187489d69c4 (subject of related commit) ------------- - -* Configure a commit template with some trailers with empty values - (using sed to show and keep the trailing spaces at the end of the - trailers), then configure a commit-msg hook that uses - 'git interpret-trailers' to remove trailers with empty values and - to add a 'git-version' trailer: -+ ------------- -$ sed -e 's/ Z$/ /' >commit_template.txt <<EOF -> ***subject*** -> -> ***message*** -> -> Fixes: Z -> Cc: Z -> Reviewed-by: Z -> Signed-off-by: Z -> EOF -$ git config commit.template commit_template.txt -$ cat >.git/hooks/commit-msg <<EOF -> #!/bin/sh -> git interpret-trailers --trim-empty --trailer "git-version: \$(git describe)" "\$1" > "\$1.new" -> mv "\$1.new" "\$1" -> EOF -$ chmod +x .git/hooks/commit-msg ------------- - -SEE ALSO --------- -linkgit:git-commit[1], linkgit:git-format-patch[1], linkgit:git-config[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-log.txt b/third_party/git/Documentation/git-log.txt deleted file mode 100644 index b406bc4c48..0000000000 --- a/third_party/git/Documentation/git-log.txt +++ /dev/null @@ -1,235 +0,0 @@ -git-log(1) -========== - -NAME ----- -git-log - Show commit logs - - -SYNOPSIS --------- -[verse] -'git log' [<options>] [<revision range>] [[--] <path>...] - -DESCRIPTION ------------ -Shows the commit logs. - -The command takes options applicable to the `git rev-list` -command to control what is shown and how, and options applicable to -the `git diff-*` commands to control how the changes -each commit introduces are shown. - - -OPTIONS -------- - ---follow:: - Continue listing the history of a file beyond renames - (works only for a single file). - ---no-decorate:: ---decorate[=short|full|auto|no]:: - Print out the ref names of any commits that are shown. If 'short' is - specified, the ref name prefixes 'refs/heads/', 'refs/tags/' and - 'refs/remotes/' will not be printed. If 'full' is specified, the - full ref name (including prefix) will be printed. If 'auto' is - specified, then if the output is going to a terminal, the ref names - are shown as if 'short' were given, otherwise no ref names are - shown. The default option is 'short'. - ---decorate-refs=<pattern>:: ---decorate-refs-exclude=<pattern>:: - If no `--decorate-refs` is given, pretend as if all refs were - included. For each candidate, do not use it for decoration if it - matches any patterns given to `--decorate-refs-exclude` or if it - doesn't match any of the patterns given to `--decorate-refs`. - ---source:: - Print out the ref name given on the command line by which each - commit was reached. - ---[no-]use-mailmap:: - Use mailmap file to map author and committer names and email - addresses to canonical real names and email addresses. See - linkgit:git-shortlog[1]. - ---full-diff:: - Without this flag, `git log -p <path>...` shows commits that - touch the specified paths, and diffs about the same specified - paths. With this, the full diff is shown for commits that touch - the specified paths; this means that "<path>..." limits only - commits, and doesn't limit diff for those commits. -+ -Note that this affects all diff-based output types, e.g. those -produced by `--stat`, etc. - ---log-size:: - Include a line ``log size <number>'' in the output for each commit, - where <number> is the length of that commit's message in bytes. - Intended to speed up tools that read log messages from `git log` - output by allowing them to allocate space in advance. - --L <start>,<end>:<file>:: --L :<funcname>:<file>:: - Trace the evolution of the line range given by "<start>,<end>" - (or the function name regex <funcname>) within the <file>. You may - not give any pathspec limiters. This is currently limited to - a walk starting from a single revision, i.e., you may only - give zero or one positive revision arguments. - You can specify this option more than once. -+ -include::line-range-format.txt[] - -<revision range>:: - Show only commits in the specified revision range. When no - <revision range> is specified, it defaults to `HEAD` (i.e. the - whole history leading to the current commit). `origin..HEAD` - specifies all the commits reachable from the current commit - (i.e. `HEAD`), but not from `origin`. For a complete list of - ways to spell <revision range>, see the 'Specifying Ranges' - section of linkgit:gitrevisions[7]. - -[--] <path>...:: - Show only commits that are enough to explain how the files - that match the specified paths came to be. See 'History - Simplification' below for details and other simplification - modes. -+ -Paths may need to be prefixed with `--` to separate them from -options or the revision range, when confusion arises. - -include::rev-list-options.txt[] - -include::pretty-formats.txt[] - -COMMON DIFF OPTIONS -------------------- - -:git-log: 1 -include::diff-options.txt[] - -include::diff-generate-patch.txt[] - -EXAMPLES --------- -`git log --no-merges`:: - - Show the whole commit history, but skip any merges - -`git log v2.6.12.. include/scsi drivers/scsi`:: - - Show all commits since version 'v2.6.12' that changed any file - in the `include/scsi` or `drivers/scsi` subdirectories - -`git log --since="2 weeks ago" -- gitk`:: - - Show the changes during the last two weeks to the file 'gitk'. - The `--` is necessary to avoid confusion with the *branch* named - 'gitk' - -`git log --name-status release..test`:: - - Show the commits that are in the "test" branch but not yet - in the "release" branch, along with the list of paths - each commit modifies. - -`git log --follow builtin/rev-list.c`:: - - Shows the commits that changed `builtin/rev-list.c`, including - those commits that occurred before the file was given its - present name. - -`git log --branches --not --remotes=origin`:: - - Shows all commits that are in any of local branches but not in - any of remote-tracking branches for 'origin' (what you have that - origin doesn't). - -`git log master --not --remotes=*/master`:: - - Shows all commits that are in local master but not in any remote - repository master branches. - -`git log -p -m --first-parent`:: - - Shows the history including change diffs, but only from the - ``main branch'' perspective, skipping commits that come from merged - branches, and showing full diffs of changes introduced by the merges. - This makes sense only when following a strict policy of merging all - topic branches when staying on a single integration branch. - -`git log -L '/int main/',/^}/:main.c`:: - - Shows how the function `main()` in the file `main.c` evolved - over time. - -`git log -3`:: - - Limits the number of commits to show to 3. - -DISCUSSION ----------- - -include::i18n.txt[] - -CONFIGURATION -------------- - -See linkgit:git-config[1] for core variables and linkgit:git-diff[1] -for settings related to diff generation. - -format.pretty:: - Default for the `--format` option. (See 'Pretty Formats' above.) - Defaults to `medium`. - -i18n.logOutputEncoding:: - Encoding to use when displaying logs. (See 'Discussion' above.) - Defaults to the value of `i18n.commitEncoding` if set, and UTF-8 - otherwise. - -log.date:: - Default format for human-readable dates. (Compare the - `--date` option.) Defaults to "default", which means to write - dates like `Sat May 8 19:35:34 2010 -0500`. -+ -If the format is set to "auto:foo" and the pager is in use, format -"foo" will be the used for the date format. Otherwise "default" will -be used. - -log.follow:: - If `true`, `git log` will act as if the `--follow` option was used when - a single <path> is given. This has the same limitations as `--follow`, - i.e. it cannot be used to follow multiple files and does not work well - on non-linear history. - -log.showRoot:: - If `false`, `git log` and related commands will not treat the - initial commit as a big creation event. Any root commits in - `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]. - -notes.displayRef:: - Which refs, in addition to the default set by `core.notesRef` - or `GIT_NOTES_REF`, to read notes from when showing commit - messages with the `log` family of commands. See - linkgit:git-notes[1]. -+ -May be an unabbreviated ref name or a glob and may be specified -multiple times. A warning will be issued for refs that do not exist, -but a glob that does not match any refs is silently ignored. -+ -This setting can be disabled by the `--no-notes` option, -overridden by the `GIT_NOTES_DISPLAY_REF` environment variable, -and overridden by the `--notes=<ref>` option. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-ls-files.txt b/third_party/git/Documentation/git-ls-files.txt deleted file mode 100644 index 8461c0e83e..0000000000 --- a/third_party/git/Documentation/git-ls-files.txt +++ /dev/null @@ -1,250 +0,0 @@ -git-ls-files(1) -=============== - -NAME ----- -git-ls-files - Show information about files in the index and the working tree - - -SYNOPSIS --------- -[verse] -'git ls-files' [-z] [-t] [-v] [-f] - (--[cached|deleted|others|ignored|stage|unmerged|killed|modified])* - (-[c|d|o|i|s|u|k|m])* - [--eol] - [-x <pattern>|--exclude=<pattern>] - [-X <file>|--exclude-from=<file>] - [--exclude-per-directory=<file>] - [--exclude-standard] - [--error-unmatch] [--with-tree=<tree-ish>] - [--full-name] [--recurse-submodules] - [--abbrev] [--] [<file>...] - -DESCRIPTION ------------ -This merges the file listing in the directory cache index with the -actual working directory list, and shows different combinations of the -two. - -One or more of the options below may be used to determine the files -shown: - -OPTIONS -------- --c:: ---cached:: - Show cached files in the output (default) - --d:: ---deleted:: - Show deleted files in the output - --m:: ---modified:: - Show modified files in the output - --o:: ---others:: - Show other (i.e. untracked) files in the output - --i:: ---ignored:: - Show only ignored files in the output. When showing files in the - index, print only those matched by an exclude pattern. When - showing "other" files, show only those matched by an exclude - pattern. Standard ignore rules are not automatically activated, - therefore at least one of the `--exclude*` options is required. - --s:: ---stage:: - Show staged contents' mode bits, object name and stage number in the output. - ---directory:: - If a whole directory is classified as "other", show just its - name (with a trailing slash) and not its whole contents. - ---no-empty-directory:: - Do not list empty directories. Has no effect without --directory. - --u:: ---unmerged:: - Show unmerged files in the output (forces --stage) - --k:: ---killed:: - Show files on the filesystem that need to be removed due - to file/directory conflicts for checkout-index to - succeed. - --z:: - \0 line termination on output and do not quote filenames. - See OUTPUT below for more information. - --x <pattern>:: ---exclude=<pattern>:: - Skip untracked files matching pattern. - Note that pattern is a shell wildcard pattern. See EXCLUDE PATTERNS - below for more information. - --X <file>:: ---exclude-from=<file>:: - Read exclude patterns from <file>; 1 per line. - ---exclude-per-directory=<file>:: - Read additional exclude patterns that apply only to the - directory and its subdirectories in <file>. - ---exclude-standard:: - Add the standard Git exclusions: .git/info/exclude, .gitignore - in each directory, and the user's global exclusion file. - ---error-unmatch:: - If any <file> does not appear in the index, treat this as an - error (return 1). - ---with-tree=<tree-ish>:: - When using --error-unmatch to expand the user supplied - <file> (i.e. path pattern) arguments to paths, pretend - that paths which were removed in the index since the - named <tree-ish> are still present. Using this option - with `-s` or `-u` options does not make any sense. - --t:: - This feature is semi-deprecated. For scripting purpose, - linkgit:git-status[1] `--porcelain` and - linkgit:git-diff-files[1] `--name-status` are almost always - superior alternatives, and users should look at - linkgit:git-status[1] `--short` or linkgit:git-diff[1] - `--name-status` for more user-friendly alternatives. -+ --- -This option identifies the file status with the following tags (followed by -a space) at the start of each line: - - H:: cached - S:: skip-worktree - M:: unmerged - R:: removed/deleted - C:: modified/changed - K:: to be killed - ?:: other --- - --v:: - Similar to `-t`, but use lowercase letters for files - that are marked as 'assume unchanged' (see - linkgit:git-update-index[1]). - --f:: - Similar to `-t`, but use lowercase letters for files - that are marked as 'fsmonitor valid' (see - linkgit:git-update-index[1]). - ---full-name:: - When run from a subdirectory, the command usually - outputs paths relative to the current directory. This - 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. - Non default number of digits can be specified with --abbrev=<n>. - ---debug:: - After each line that describes a file, add more data about its - cache entry. This is intended to show as much information as - possible for manual inspection; the exact format may change at - any time. - ---eol:: - Show <eolinfo> and <eolattr> of files. - <eolinfo> is the file content identification used by Git when - the "text" attribute is "auto" (or not set and core.autocrlf is not false). - <eolinfo> is either "-text", "none", "lf", "crlf", "mixed" or "". -+ -"" means the file is not a regular file, it is not in the index or -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". -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, -followed by the ("attr/<eolattr>"). - -\--:: - Do not interpret any more arguments as options. - -<file>:: - Files to show. If no files are given all files which match the other - specified criteria are shown. - -OUTPUT ------- -'git ls-files' just outputs the filenames unless `--stage` is specified in -which case it outputs: - - [<tag> ]<mode> <object> <stage> <file> - -'git ls-files --eol' will show - i/<eolinfo><SPACES>w/<eolinfo><SPACES>attr/<eolattr><SPACE*><TAB><file> - -'git ls-files --unmerged' and 'git ls-files --stage' can be used to examine -detailed information on unmerged paths. - -For an unmerged path, instead of recording a single mode/SHA-1 pair, -the index records up to three such pairs; one from tree O in stage -1, A in stage 2, and B in stage 3. This information can be used by -the user (or the porcelain) to see what should eventually be recorded at the -path. (see linkgit:git-read-tree[1] for more information on state) - -Without the `-z` option, pathnames with "unusual" characters are -quoted as explained for the configuration variable `core.quotePath` -(see linkgit:git-config[1]). Using `-z` the filename is output -verbatim and the line is terminated by a NUL byte. - - -EXCLUDE PATTERNS ----------------- - -'git ls-files' can use a list of "exclude patterns" when -traversing the directory tree and finding files to show when the -flags --others or --ignored are specified. linkgit:gitignore[5] -specifies the format of exclude patterns. - -These exclude patterns come from these places, in order: - - 1. The command-line flag --exclude=<pattern> specifies a - single pattern. Patterns are ordered in the same order - they appear in the command line. - - 2. The command-line flag --exclude-from=<file> specifies a - file containing a list of patterns. Patterns are ordered - in the same order they appear in the file. - - 3. The command-line flag --exclude-per-directory=<name> specifies - a name of the file in each directory 'git ls-files' - examines, normally `.gitignore`. Files in deeper - directories take precedence. Patterns are ordered in the - same order they appear in the files. - -A pattern specified on the command line with --exclude or read -from the file specified with --exclude-from is relative to the -top of the directory tree. A pattern read from a file specified -by --exclude-per-directory is relative to the directory that the -pattern file appears in. - -SEE ALSO --------- -linkgit:git-read-tree[1], linkgit:gitignore[5] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-ls-remote.txt b/third_party/git/Documentation/git-ls-remote.txt deleted file mode 100644 index 0b057cbb10..0000000000 --- a/third_party/git/Documentation/git-ls-remote.txt +++ /dev/null @@ -1,117 +0,0 @@ -git-ls-remote(1) -================ - -NAME ----- -git-ls-remote - List references in a remote repository - - -SYNOPSIS --------- -[verse] -'git ls-remote' [--heads] [--tags] [--refs] [--upload-pack=<exec>] - [-q | --quiet] [--exit-code] [--get-url] [--sort=<key>] - [--symref] [<repository> [<refs>...]] - -DESCRIPTION ------------ -Displays references available in a remote repository along with the associated -commit IDs. - - -OPTIONS -------- --h:: ---heads:: --t:: ---tags:: - Limit to only refs/heads and refs/tags, respectively. - These options are _not_ mutually exclusive; when given - both, references stored in refs/heads and refs/tags are - displayed. - ---refs:: - Do not show peeled tags or pseudorefs like `HEAD` in the output. - --q:: ---quiet:: - Do not print remote URL to stderr. - ---upload-pack=<exec>:: - Specify the full path of 'git-upload-pack' on the remote - host. This allows listing references from repositories accessed via - SSH and where the SSH daemon does not use the PATH configured by the - user. - ---exit-code:: - Exit with status "2" when no matching refs are found in the remote - repository. Usually the command exits with status "0" to indicate - it successfully talked with the remote repository, whether it - found any matching refs. - ---get-url:: - Expand the URL of the given remote repository taking into account any - "url.<base>.insteadOf" config setting (See linkgit:git-config[1]) and - exit without talking to the remote. - ---symref:: - In addition to the object pointed by it, show the underlying - ref pointed by it when showing a symbolic ref. Currently, - upload-pack only shows the symref HEAD, so it will be the only - one shown by ls-remote. - ---sort=<key>:: - Sort based on the key given. Prefix `-` to sort in descending order - of the value. Supports "version:refname" or "v:refname" (tag names - are treated as versions). The "version:refname" sort order can also - be affected by the "versionsort.suffix" configuration variable. - See linkgit:git-for-each-ref[1] for more sort options, but be aware - keys like `committerdate` that require access to the objects - themselves will not work for refs whose objects have not yet been - fetched from the remote, and will give a `missing object` error. - --o <option>:: ---server-option=<option>:: - Transmit the given string to the server when communicating using - protocol version 2. The given string must not contain a NUL or LF - character. - When multiple `--server-option=<option>` are given, they are all - sent to the other side in the order listed on the command line. - -<repository>:: - The "remote" repository to query. This parameter can be - either a URL or the name of a remote (see the GIT URLS and - REMOTES sections of linkgit:git-fetch[1]). - -<refs>...:: - When unspecified, all references, after filtering done - with --heads and --tags, are shown. When <refs>... are - specified, only references matching the given patterns - are displayed. - -EXAMPLES --------- - - $ git ls-remote --tags ./. - d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99 - f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1 - 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3 - c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2 - 0918385dbd9656cab0d1d81ba7453d49bbc16250 refs/tags/junio-gpg-pub - $ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc - 5fe978a5381f1fbad26a80e682ddd2a401966740 refs/heads/master - c781a84b5204fb294c9ccc79f8b3baceeb32c061 refs/heads/pu - $ git remote add korg http://www.kernel.org/pub/scm/git/git.git - $ git ls-remote --tags korg v\* - d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99 - f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1 - c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2 - 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3 - -SEE ALSO --------- -linkgit:git-check-ref-format[1]. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-ls-tree.txt b/third_party/git/Documentation/git-ls-tree.txt deleted file mode 100644 index a7515714da..0000000000 --- a/third_party/git/Documentation/git-ls-tree.txt +++ /dev/null @@ -1,104 +0,0 @@ -git-ls-tree(1) -============== - -NAME ----- -git-ls-tree - List the contents of a tree object - - -SYNOPSIS --------- -[verse] -'git ls-tree' [-d] [-r] [-t] [-l] [-z] - [--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev[=<n>]] - <tree-ish> [<path>...] - -DESCRIPTION ------------ -Lists the contents of a given tree object, like what "/bin/ls -a" does -in the current working directory. Note that: - - - the behaviour is slightly different from that of "/bin/ls" in that the - '<path>' denotes just a list of patterns to match, e.g. so specifying - directory name (without `-r`) will behave differently, and order of the - arguments does not matter. - - - the behaviour is similar to that of "/bin/ls" in that the '<path>' is - taken as relative to the current working directory. E.g. when you are - in a directory 'sub' that has a directory 'dir', you can run 'git - ls-tree -r HEAD dir' to list the contents of the tree (that is - `sub/dir` in `HEAD`). You don't want to give a tree that is not at the - root level (e.g. `git ls-tree -r HEAD:sub dir`) in this case, as that - would result in asking for `sub/sub/dir` in the `HEAD` commit. - However, the current working directory can be ignored by passing - --full-tree option. - -OPTIONS -------- -<tree-ish>:: - Id of a tree-ish. - --d:: - Show only the named tree entry itself, not its children. - --r:: - Recurse into sub-trees. - --t:: - Show tree entries even when going to recurse them. Has no effect - if `-r` was not passed. `-d` implies `-t`. - --l:: ---long:: - Show object size of blob (file) entries. - --z:: - \0 line termination on output and do not quote filenames. - See OUTPUT FORMAT below for more information. - ---name-only:: ---name-status:: - List only filenames (instead of the "long" output), one per line. - ---abbrev[=<n>]:: - Instead of showing the full 40-byte hexadecimal object - lines, show only a partial prefix. - Non default number of digits can be specified with --abbrev=<n>. - ---full-name:: - Instead of showing the path names relative to the current working - directory, show the full path names. - ---full-tree:: - Do not limit the listing to the current working directory. - Implies --full-name. - -[<path>...]:: - When paths are given, show them (note that this isn't really raw - pathnames, but rather a list of patterns to match). Otherwise - implicitly uses the root level of the tree as the sole path argument. - - -Output Format -------------- - <mode> SP <type> SP <object> TAB <file> - -This output format is compatible with what `--index-info --stdin` of -'git update-index' expects. - -When the `-l` option is used, format changes to - - <mode> SP <type> SP <object> SP <object size> TAB <file> - -Object size identified by <object> is given in bytes, and right-justified -with minimum width of 7 characters. Object size is given only for blobs -(file) entries; for other entries `-` character is used in place of size. - -Without the `-z` option, pathnames with "unusual" characters are -quoted as explained for the configuration variable `core.quotePath` -(see linkgit:git-config[1]). Using `-z` the filename is output -verbatim and the line is terminated by a NUL byte. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-mailinfo.txt b/third_party/git/Documentation/git-mailinfo.txt deleted file mode 100644 index 3bbc731f67..0000000000 --- a/third_party/git/Documentation/git-mailinfo.txt +++ /dev/null @@ -1,102 +0,0 @@ -git-mailinfo(1) -=============== - -NAME ----- -git-mailinfo - Extracts patch and authorship from a single e-mail message - - -SYNOPSIS --------- -[verse] -'git mailinfo' [-k|-b] [-u | --encoding=<encoding> | -n] [--[no-]scissors] <msg> <patch> - - -DESCRIPTION ------------ -Reads a single e-mail message from the standard input, and -writes the commit log message in <msg> file, and the patches in -<patch> file. The author name, e-mail and e-mail subject are -written out to the standard output to be used by 'git am' -to create a commit. It is usually not necessary to use this -command directly. See linkgit:git-am[1] instead. - - -OPTIONS -------- --k:: - Usually the program removes email cruft from the Subject: - header line to extract the title line for the commit log - message. This option prevents this munging, and is most - useful when used to read back 'git format-patch -k' output. -+ -Specifically, the following are removed until none of them remain: -+ --- -* Leading and trailing whitespace. - -* Leading `Re:`, `re:`, and `:`. - -* Leading bracketed strings (between `[` and `]`, usually - `[PATCH]`). --- -+ -Finally, runs of whitespace are normalized to a single ASCII space -character. - --b:: - When -k is not in effect, all leading strings bracketed with '[' - and ']' pairs are stripped. This option limits the stripping to - only the pairs whose bracketed string contains the word "PATCH". - --u:: - The commit log message, author name and author email are - taken from the e-mail, and after minimally decoding MIME - transfer encoding, re-coded in the charset specified by - i18n.commitencoding (defaulting to UTF-8) by transliterating - them. This used to be optional but now it is the default. -+ -Note that the patch is always used as-is without charset -conversion, even with this flag. - ---encoding=<encoding>:: - Similar to -u. But when re-coding, the charset specified here is - used instead of the one specified by i18n.commitencoding or UTF-8. - --n:: - Disable all charset re-coding of the metadata. - --m:: ---message-id:: - Copy the Message-ID header at the end of the commit message. This - is useful in order to associate commits with mailing list discussions. - ---scissors:: - Remove everything in body before a scissors line. A line that - mainly consists of scissors (either ">8" or "8<") and perforation - (dash "-") marks is called a scissors line, and is used to request - the reader to cut the message at that line. If such a line - appears in the body of the message before the patch, everything - before it (including the scissors line itself) is ignored when - this option is used. -+ -This is useful if you want to begin your message in a discussion thread -with comments and suggestions on the message you are responding to, and to -conclude it with a patch submission, separating the discussion and the -beginning of the proposed commit log message with a scissors line. -+ -This can be enabled by default with the configuration option mailinfo.scissors. - ---no-scissors:: - Ignore scissors lines. Useful for overriding mailinfo.scissors settings. - -<msg>:: - The commit log message extracted from e-mail, usually - except the title line which comes from e-mail Subject. - -<patch>:: - The patch extracted from e-mail. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-mailsplit.txt b/third_party/git/Documentation/git-mailsplit.txt deleted file mode 100644 index e3b2a88c4b..0000000000 --- a/third_party/git/Documentation/git-mailsplit.txt +++ /dev/null @@ -1,57 +0,0 @@ -git-mailsplit(1) -================ - -NAME ----- -git-mailsplit - Simple UNIX mbox splitter program - -SYNOPSIS --------- -[verse] -'git mailsplit' [-b] [-f<nn>] [-d<prec>] [--keep-cr] [--mboxrd] - -o<directory> [--] [(<mbox>|<Maildir>)...] - -DESCRIPTION ------------ -Splits a mbox file or a Maildir into a list of files: "0001" "0002" .. in the -specified directory so you can process them further from there. - -IMPORTANT: Maildir splitting relies upon filenames being sorted to output -patches in the correct order. - -OPTIONS -------- -<mbox>:: - Mbox file to split. If not given, the mbox is read from - the standard input. - -<Maildir>:: - Root of the Maildir to split. This directory should contain the cur, tmp - and new subdirectories. - --o<directory>:: - Directory in which to place the individual messages. - --b:: - If any file doesn't begin with a From line, assume it is a - single mail message instead of signaling error. - --d<prec>:: - Instead of the default 4 digits with leading zeros, - different precision can be specified for the generated - filenames. - --f<nn>:: - Skip the first <nn> numbers, for example if -f3 is specified, - start the numbering with 0004. - ---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/third_party/git/Documentation/git-merge-base.txt b/third_party/git/Documentation/git-merge-base.txt deleted file mode 100644 index 261d5c1164..0000000000 --- a/third_party/git/Documentation/git-merge-base.txt +++ /dev/null @@ -1,231 +0,0 @@ -git-merge-base(1) -================= - -NAME ----- -git-merge-base - Find as good common ancestors as possible for a merge - - -SYNOPSIS --------- -[verse] -'git merge-base' [-a|--all] <commit> <commit>... -'git merge-base' [-a|--all] --octopus <commit>... -'git merge-base' --is-ancestor <commit> <commit> -'git merge-base' --independent <commit>... -'git merge-base' --fork-point <ref> [<commit>] - -DESCRIPTION ------------ - -'git merge-base' finds best common ancestor(s) between two commits to use -in a three-way merge. One common ancestor is 'better' than another common -ancestor if the latter is an ancestor of the former. A common ancestor -that does not have any better common ancestor is a 'best common -ancestor', i.e. a 'merge base'. Note that there can be more than one -merge base for a pair of commits. - -OPERATION MODES ---------------- - -As the most common special case, specifying only two commits on the -command line means computing the merge base between the given two commits. - -More generally, among the two commits to compute the merge base from, -one is specified by the first commit argument on the command line; -the other commit is a (possibly hypothetical) commit that is a merge -across all the remaining commits on the command line. - -As a consequence, the 'merge base' is not necessarily contained in each of the -commit arguments if more than two commits are specified. This is different -from linkgit:git-show-branch[1] when used with the `--merge-base` option. - ---octopus:: - Compute the best common ancestors of all supplied commits, - in preparation for an n-way merge. This mimics the behavior - of 'git show-branch --merge-base'. - ---independent:: - Instead of printing merge bases, print a minimal subset of - the supplied commits with the same ancestors. In other words, - among the commits given, list those which cannot be reached - from any other. This mimics the behavior of 'git show-branch - --independent'. - ---is-ancestor:: - Check if the first <commit> is an ancestor of the second <commit>, - and exit with status 0 if true, or with status 1 if not. - Errors are signaled by a non-zero status that is not 1. - ---fork-point:: - Find the point at which a branch (or any history that leads - to <commit>) forked from another branch (or any reference) - <ref>. This does not just look for the common ancestor of - the two commits, but also takes into account the reflog of - <ref> to see if the history leading to <commit> forked from - an earlier incarnation of the branch <ref> (see discussion - on this mode below). - -OPTIONS -------- --a:: ---all:: - Output all merge bases for the commits, instead of just one. - -DISCUSSION ----------- - -Given two commits 'A' and 'B', `git merge-base A B` will output a commit -which is reachable from both 'A' and 'B' through the parent relationship. - -For example, with this topology: - - o---o---o---B - / - ---o---1---o---o---o---A - -the merge base between 'A' and 'B' is '1'. - -Given three commits 'A', 'B' and 'C', `git merge-base A B C` will compute the -merge base between 'A' and a hypothetical commit 'M', which is a merge -between 'B' and 'C'. For example, with this topology: - - o---o---o---o---C - / - / o---o---o---B - / / - ---2---1---o---o---o---A - -the result of `git merge-base A B C` is '1'. This is because the -equivalent topology with a merge commit 'M' between 'B' and 'C' is: - - - o---o---o---o---o - / \ - / o---o---o---o---M - / / - ---2---1---o---o---o---A - -and the result of `git merge-base A M` is '1'. Commit '2' is also a -common ancestor between 'A' and 'M', but '1' is a better common ancestor, -because '2' is an ancestor of '1'. Hence, '2' is not a merge base. - -The result of `git merge-base --octopus A B C` is '2', because '2' is -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 - -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, -it is unspecified which best one is output. - -A common idiom to check "fast-forward-ness" between two commits A -and B is (or at least used to be) to compute the merge base between -A and B, and check if it is the same as A, in which case, A is an -ancestor of B. You will see this idiom used often in older scripts. - - A=$(git rev-parse --verify A) - if test "$A" = "$(git merge-base A B)" - then - ... A is an ancestor of B ... - fi - -In modern git, you can say this in a more direct way: - - if git merge-base --is-ancestor A B - then - ... A is an ancestor of B ... - fi - -instead. - -Discussion on fork-point mode ------------------------------ - -After working on the `topic` branch created with `git switch -c -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---B2 - / - ---o---o---B1--o---o---o---B (origin/master) - \ - B0 - \ - D0---D1---D (topic) - -where `origin/master` used to point at commits B0, B1, B2 and now it -points at B, and your `topic` branch was started on top of it back -when `origin/master` was at B0, and you built three commits, D0, D1, -and D, on top of it. Imagine that you now want to rebase the work -you did on the topic on top of the updated origin/master. - -In such a case, `git merge-base origin/master topic` would return the -parent of B0 in the above picture, but B0^..D is *not* the range of -commits you would want to replay on top of B (it includes B0, which -is not what you wrote; it is a commit the other side discarded when -it moved its tip from B0 to B1). - -`git merge-base --fork-point origin/master topic` is designed to -help in such a case. It takes not only B but also B0, B1, and B2 -(i.e. old tips of the remote-tracking branches your repository's -reflog knows about) into account to see on which commit your topic -branch was built and finds B0, allowing you to replay only the -commits on your topic, excluding the commits the other side later -discarded. - -Hence - - $ fork_point=$(git merge-base --fork-point origin/master topic) - -will find B0, and - - $ git rebase --onto origin/master $fork_point topic - -will replay D0, D1 and D on top of B to create a new history of this -shape: - - o---B2 - / - ---o---o---B1--o---o---o---B (origin/master) - \ \ - B0 D0'--D1'--D' (topic - updated) - \ - D0---D1---D (topic - old) - -A caveat is that older reflog entries in your repository may be -expired by `git gc`. If B0 no longer appears in the reflog of the -remote-tracking branch `origin/master`, the `--fork-point` mode -obviously cannot find it and fails, avoiding to give a random and -useless result (such as the parent of B0, like the same command -without the `--fork-point` option gives). - -Also, the remote-tracking branch you use the `--fork-point` mode -with must be the one your topic forked from its tip. If you forked -from an older commit than the tip, this mode would not find the fork -point (imagine in the above sample history B0 did not exist, -origin/master started at B1, moved to B2 and then B, and you forked -your topic at origin/master^ when origin/master was B1; the shape of -the history would be the same as above, without B0, and the parent -of B1 is what `git merge-base origin/master topic` correctly finds, -but the `--fork-point` mode will not, because it is not one of the -commits that used to be at the tip of origin/master). - - -See also --------- -linkgit:git-rev-list[1], -linkgit:git-show-branch[1], -linkgit:git-merge[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-merge-file.txt b/third_party/git/Documentation/git-merge-file.txt deleted file mode 100644 index f856032613..0000000000 --- a/third_party/git/Documentation/git-merge-file.txt +++ /dev/null @@ -1,95 +0,0 @@ -git-merge-file(1) -================= - -NAME ----- -git-merge-file - Run a three-way file merge - - -SYNOPSIS --------- -[verse] -'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]] - [--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>] - [--[no-]diff3] <current-file> <base-file> <other-file> - - -DESCRIPTION ------------ -'git merge-file' incorporates all changes that lead from the `<base-file>` -to `<other-file>` into `<current-file>`. The result ordinarily goes into -`<current-file>`. 'git merge-file' is useful for combining separate changes -to an original. Suppose `<base-file>` is the original, and both -`<current-file>` and `<other-file>` are modifications of `<base-file>`, -then 'git merge-file' combines both changes. - -A conflict occurs if both `<current-file>` and `<other-file>` have changes -in a common segment of lines. If a conflict is found, 'git merge-file' -normally outputs a warning and brackets the conflict with lines containing -<<<<<<< and >>>>>>> markers. A typical conflict will look like this: - - <<<<<<< A - lines in file A - ======= - lines in file B - >>>>>>> B - -If there are conflicts, the user should edit the result and delete one of -the alternatives. When `--ours`, `--theirs`, or `--union` option is in effect, -however, these conflicts are resolved favouring lines from `<current-file>`, -lines from `<other-file>`, or lines from both respectively. The length of the -conflict markers can be given with the `--marker-size` option. - -The exit value of this program is negative on error, and the number of -conflicts otherwise (truncated to 127 if there are more than that many -conflicts). If the merge was clean, the exit value is 0. - -'git merge-file' is designed to be a minimal clone of RCS 'merge'; that is, it -implements all of RCS 'merge''s functionality which is needed by -linkgit:git[1]. - - -OPTIONS -------- - --L <label>:: - This option may be given up to three times, and - specifies labels to be used in place of the - corresponding file names in conflict reports. That is, - `git merge-file -L x -L y -L z a b c` generates output that - looks like it came from files x, y and z instead of - from files a, b and c. - --p:: - Send results to standard output instead of overwriting - `<current-file>`. - --q:: - Quiet; do not warn about conflicts. - ---diff3:: - Show conflicts in "diff3" style. - ---ours:: ---theirs:: ---union:: - Instead of leaving conflicts in the file, resolve conflicts - favouring our (or their or both) side of the lines. - - -EXAMPLES --------- - -`git merge-file README.my README README.upstream`:: - - combines the changes of README.my and README.upstream since README, - tries to merge them and writes the result into README.my. - -`git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345`:: - - merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels - `a` and `c` instead of `tmp/a123` and `tmp/c345`. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-merge-index.txt b/third_party/git/Documentation/git-merge-index.txt deleted file mode 100644 index 02676fb391..0000000000 --- a/third_party/git/Documentation/git-merge-index.txt +++ /dev/null @@ -1,79 +0,0 @@ -git-merge-index(1) -================== - -NAME ----- -git-merge-index - Run a merge for files needing merging - - -SYNOPSIS --------- -[verse] -'git merge-index' [-o] [-q] <merge-program> (-a | [--] <file>*) - -DESCRIPTION ------------ -This looks up the <file>(s) in the index and, if there are any merge -entries, passes the SHA-1 hash for those files as arguments 1, 2, 3 (empty -argument if no file), and <file> as argument 4. File modes for the three -files are passed as arguments 5, 6 and 7. - -OPTIONS -------- -\--:: - Do not interpret any more arguments as options. - --a:: - Run merge against all files in the index that need merging. - --o:: - Instead of stopping at the first failed merge, do all of them - in one shot - continue with merging even when previous merges - returned errors, and only return the error code after all the - merges. - --q:: - Do not complain about a failed merge program (a merge program - failure usually indicates conflicts during the merge). This is for - porcelains which might want to emit custom messages. - -If 'git merge-index' is called with multiple <file>s (or -a) then it -processes them in turn only stopping if merge returns a non-zero exit -code. - -Typically this is run with a script calling Git's imitation of -the 'merge' command from the RCS package. - -A sample script called 'git merge-one-file' is included in the -distribution. - -ALERT ALERT ALERT! The Git "merge object order" is different from the -RCS 'merge' program merge object order. In the above ordering, the -original is first. But the argument order to the 3-way merge program -'merge' is to have the original in the middle. Don't ask me why. - -Examples: - - torvalds@ppc970:~/merge-test> git merge-index cat MM - This is MM from the original tree. # original - This is modified MM in the branch A. # merge1 - This is modified MM in the branch B. # merge2 - This is modified MM in the branch B. # current contents - -or - - torvalds@ppc970:~/merge-test> git merge-index cat AA MM - cat: : No such file or directory - This is added AA in the branch A. - This is added AA in the branch B. - This is added AA in the branch B. - fatal: merge program failed - -where the latter example shows how 'git merge-index' will stop trying to -merge once anything has returned an error (i.e., `cat` returned an error -for the AA file, because it didn't exist in the original, and thus -'git merge-index' didn't even try to merge the MM thing). - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-merge-one-file.txt b/third_party/git/Documentation/git-merge-one-file.txt deleted file mode 100644 index 04e803d5d3..0000000000 --- a/third_party/git/Documentation/git-merge-one-file.txt +++ /dev/null @@ -1,21 +0,0 @@ -git-merge-one-file(1) -===================== - -NAME ----- -git-merge-one-file - The standard helper program to use with git-merge-index - - -SYNOPSIS --------- -[verse] -'git merge-one-file' - -DESCRIPTION ------------ -This is the standard helper program to use with 'git merge-index' -to resolve a merge after the trivial merge done with 'git read-tree -m'. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-merge-tree.txt b/third_party/git/Documentation/git-merge-tree.txt deleted file mode 100644 index 58731c1942..0000000000 --- a/third_party/git/Documentation/git-merge-tree.txt +++ /dev/null @@ -1,29 +0,0 @@ -git-merge-tree(1) -================= - -NAME ----- -git-merge-tree - Show three-way merge without touching index - - -SYNOPSIS --------- -[verse] -'git merge-tree' <base-tree> <branch1> <branch2> - -DESCRIPTION ------------ -Reads three tree-ish, and output trivial merge results and -conflicting stages to the standard output. This is similar to -what three-way 'git read-tree -m' does, but instead of storing the -results in the index, the command outputs the entries to the -standard output. - -This is meant to be used by higher level scripts to compute -merge results outside of the index, and stuff the results back into the -index. For this reason, the output from the command omits -entries that match the <branch1> tree. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-merge.txt b/third_party/git/Documentation/git-merge.txt deleted file mode 100644 index 01fd52dc70..0000000000 --- a/third_party/git/Documentation/git-merge.txt +++ /dev/null @@ -1,372 +0,0 @@ -git-merge(1) -============ - -NAME ----- -git-merge - Join two or more development histories together - - -SYNOPSIS --------- -[verse] -'git merge' [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] - [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] - [--[no-]allow-unrelated-histories] - [--[no-]rerere-autoupdate] [-m <msg>] [-F <file>] [<commit>...] -'git merge' (--continue | --abort | --quit) - -DESCRIPTION ------------ -Incorporates changes from the named commits (since the time their -histories diverged from the current branch) into the current -branch. This command is used by 'git pull' to incorporate changes -from another repository and can be used by hand to merge changes -from one branch into another. - -Assume the following history exists and the current branch is -"`master`": - ------------- - A---B---C topic - / - D---E---F---G master ------------- - -Then "`git merge topic`" will replay the changes made on the -`topic` branch since it diverged from `master` (i.e., `E`) until -its current commit (`C`) on top of `master`, and record the result -in a new commit along with the names of the two parent commits and -a log message from the user describing the changes. - ------------- - A---B---C topic - / \ - D---E---F---G---H master ------------- - -The second syntax ("`git merge --abort`") can only be run after the -merge has resulted in conflicts. 'git merge --abort' will abort the -merge process and try to reconstruct the pre-merge state. However, -if there were uncommitted changes when the merge started (and -especially if those changes were further modified after the merge -was started), 'git merge --abort' will in some cases be unable to -reconstruct the original (pre-merge) changes. Therefore: - -*Warning*: Running 'git merge' with non-trivial uncommitted changes is -discouraged: while possible, it may leave you in a state that is hard to -back out of in the case of a conflict. - -The third syntax ("`git merge --continue`") can only be run after the -merge has resulted in conflicts. - -OPTIONS -------- -include::merge-options.txt[] - --m <msg>:: - Set the commit message to be used for the merge commit (in - case one is created). -+ -If `--log` is specified, a shortlog of the commits being merged -will be appended to the specified message. -+ -The 'git fmt-merge-msg' command can be -used to give a good default for automated 'git merge' -invocations. The automated message can include the branch description. - --F <file>:: ---file=<file>:: - Read the commit message to be used for the merge commit (in - case one is created). -+ -If `--log` is specified, a shortlog of the commits being merged -will be appended to the specified message. - ---rerere-autoupdate:: ---no-rerere-autoupdate:: - Allow the rerere mechanism to update the index with the - result of auto-conflict resolution if possible. - ---overwrite-ignore:: ---no-overwrite-ignore:: - Silently overwrite ignored files from the merge result. This - is the default behavior. Use `--no-overwrite-ignore` to abort. - ---abort:: - Abort the current conflict resolution process, and - try to reconstruct the pre-merge state. -+ -If there were uncommitted worktree changes present when the merge -started, 'git merge --abort' will in some cases be unable to -reconstruct these changes. It is therefore recommended to always -commit or stash your changes before running 'git merge'. -+ -'git merge --abort' is equivalent to 'git reset --merge' when -`MERGE_HEAD` is present. - ---quit:: - Forget about the current merge in progress. Leave the index - and the working tree as-is. - ---continue:: - After a 'git merge' stops due to conflicts you can conclude the - merge by running 'git merge --continue' (see "HOW TO RESOLVE - CONFLICTS" section below). - -<commit>...:: - Commits, usually other branch heads, to merge into our branch. - Specifying more than one commit will create a merge with - more than two parents (affectionately called an Octopus merge). -+ -If no commit is given from the command line, merge the remote-tracking -branches that the current branch is configured to use as its upstream. -See also the configuration section of this manual page. -+ -When `FETCH_HEAD` (and no other commit) is specified, the branches -recorded in the `.git/FETCH_HEAD` file by the previous invocation -of `git fetch` for merging are merged to the current branch. - - -PRE-MERGE CHECKS ----------------- - -Before applying outside changes, you should get your own work in -good shape and committed locally, so it will not be clobbered if -there are conflicts. See also linkgit:git-stash[1]. -'git pull' and 'git merge' will stop without doing anything when -local uncommitted changes overlap with files that 'git pull'/'git -merge' may need to update. - -To avoid recording unrelated changes in the merge commit, -'git pull' and 'git merge' will also abort if there are any changes -registered in the index relative to the `HEAD` commit. (Special -narrow exceptions to this rule may exist depending on which merge -strategy is in use, but generally, the index must match HEAD.) - -If all named commits are already ancestors of `HEAD`, 'git merge' -will exit early with the message "Already up to date." - -FAST-FORWARD MERGE ------------------- - -Often the current branch head is an ancestor of the named commit. -This is the most common case especially when invoked from 'git -pull': you are tracking an upstream repository, you have committed -no local changes, and now you want to update to a newer upstream -revision. In this case, a new commit is not needed to store the -combined history; instead, the `HEAD` (along with the index) is -updated to point at the named commit, without creating an extra -merge commit. - -This behavior can be suppressed with the `--no-ff` option. - -TRUE MERGE ----------- - -Except in a fast-forward merge (see above), the branches to be -merged must be tied together by a merge commit that has both of them -as its parents. - -A merged version reconciling the changes from all branches to be -merged is committed, and your `HEAD`, index, and working tree are -updated to it. It is possible to have modifications in the working -tree as long as they do not overlap; the update will preserve them. - -When it is not obvious how to reconcile the changes, the following -happens: - -1. The `HEAD` pointer stays the same. -2. The `MERGE_HEAD` ref is set to point to the other branch head. -3. Paths that merged cleanly are updated both in the index file and - in your working tree. -4. For conflicting paths, the index file records up to three - versions: stage 1 stores the version from the common ancestor, - stage 2 from `HEAD`, and stage 3 from `MERGE_HEAD` (you - can inspect the stages with `git ls-files -u`). The working - tree files contain the result of the "merge" program; i.e. 3-way - merge results with familiar conflict markers `<<<` `===` `>>>`. -5. No other changes are made. In particular, the local - modifications you had before you started merge will stay the - same and the index entries for them stay as they were, - i.e. matching `HEAD`. - -If you tried a merge which resulted in complex conflicts and -want to start over, you can recover with `git merge --abort`. - -MERGING TAG ------------ - -When merging an annotated (and possibly signed) tag, Git always -creates a merge commit even if a fast-forward merge is possible, and -the commit message template is prepared with the tag message. -Additionally, if the tag is signed, the signature check is reported -as a comment in the message template. See also linkgit:git-tag[1]. - -When you want to just integrate with the work leading to the commit -that happens to be tagged, e.g. synchronizing with an upstream -release point, you may not want to make an unnecessary merge commit. - -In such a case, you can "unwrap" the tag yourself before feeding it -to `git merge`, or pass `--ff-only` when you do not have any work on -your own. e.g. - ----- -git fetch origin -git merge v1.2.3^0 -git merge --ff-only v1.2.3 ----- - - -HOW CONFLICTS ARE PRESENTED ---------------------------- - -During a merge, the working tree files are updated to reflect the result -of the merge. Among the changes made to the common ancestor's version, -non-overlapping ones (that is, you changed an area of the file while the -other side left that area intact, or vice versa) are incorporated in the -final result verbatim. When both sides made changes to the same area, -however, Git cannot randomly pick one side over the other, and asks you to -resolve it by leaving what both sides did to that area. - -By default, Git uses the same style as the one used by the "merge" program -from the RCS suite to present such a conflicted hunk, like this: - ------------- -Here are lines that are either unchanged from the common -ancestor, or cleanly resolved because only one side changed. -<<<<<<< yours:sample.txt -Conflict resolution is hard; -let's go shopping. -======= -Git makes conflict resolution easy. ->>>>>>> theirs:sample.txt -And here is another line that is cleanly resolved or unmodified. ------------- - -The area where a pair of conflicting changes happened is marked with markers -`<<<<<<<`, `=======`, and `>>>>>>>`. The part before the `=======` -is typically your side, and the part afterwards is typically their side. - -The default format does not show what the original said in the conflicting -area. You cannot tell how many lines are deleted and replaced with -Barbie's remark on your side. The only thing you can tell is that your -side wants to say it is hard and you'd prefer to go shopping, while the -other side wants to claim it is easy. - -An alternative style can be used by setting the "merge.conflictStyle" -configuration variable to "diff3". In "diff3" style, the above conflict -may look like this: - ------------- -Here are lines that are either unchanged from the common -ancestor, or cleanly resolved because only one side changed. -<<<<<<< yours:sample.txt -Conflict resolution is hard; -let's go shopping. -||||||| -Conflict resolution is hard. -======= -Git makes conflict resolution easy. ->>>>>>> theirs:sample.txt -And here is another line that is cleanly resolved or unmodified. ------------- - -In addition to the `<<<<<<<`, `=======`, and `>>>>>>>` markers, it uses -another `|||||||` marker that is followed by the original text. You can -tell that the original just stated a fact, and your side simply gave in to -that statement and gave up, while the other side tried to have a more -positive attitude. You can sometimes come up with a better resolution by -viewing the original. - - -HOW TO RESOLVE CONFLICTS ------------------------- - -After seeing a conflict, you can do two things: - - * Decide not to merge. The only clean-ups you need are to reset - the index file to the `HEAD` commit to reverse 2. and to clean - up working tree changes made by 2. and 3.; `git merge --abort` - can be used for this. - - * Resolve the conflicts. Git will mark the conflicts in - the working tree. Edit the files into shape and - 'git add' them to the index. Use 'git commit' or - 'git merge --continue' to seal the deal. The latter command - checks whether there is a (interrupted) merge in progress - before calling 'git commit'. - -You can work through the conflict with a number of tools: - - * Use a mergetool. `git mergetool` to launch a graphical - mergetool which will work you through the merge. - - * Look at the diffs. `git diff` will show a three-way diff, - highlighting changes from both the `HEAD` and `MERGE_HEAD` - versions. - - * Look at the diffs from each branch. `git log --merge -p <path>` - will show diffs first for the `HEAD` version and then the - `MERGE_HEAD` version. - - * Look at the originals. `git show :1:filename` shows the - common ancestor, `git show :2:filename` shows the `HEAD` - version, and `git show :3:filename` shows the `MERGE_HEAD` - version. - - -EXAMPLES --------- - -* Merge branches `fixes` and `enhancements` on top of - the current branch, making an octopus merge: -+ ------------------------------------------------- -$ git merge fixes enhancements ------------------------------------------------- - -* Merge branch `obsolete` into the current branch, using `ours` - merge strategy: -+ ------------------------------------------------- -$ git merge -s ours obsolete ------------------------------------------------- - -* Merge branch `maint` into the current branch, but do not make - a new commit automatically: -+ ------------------------------------------------- -$ git merge --no-commit maint ------------------------------------------------- -+ -This can be used when you want to include further changes to the -merge, or want to write your own merge commit message. -+ -You should refrain from abusing this option to sneak substantial -changes into a merge commit. Small fixups like bumping -release/version name would be acceptable. - - -include::merge-strategies.txt[] - -CONFIGURATION -------------- -include::config/merge.txt[] - -branch.<name>.mergeOptions:: - Sets default options for merging into branch <name>. The syntax and - supported options are the same as those of 'git merge', but option - values containing whitespace characters are currently not supported. - -SEE ALSO --------- -linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1], -linkgit:gitattributes[5], -linkgit:git-reset[1], -linkgit:git-diff[1], linkgit:git-ls-files[1], -linkgit:git-add[1], linkgit:git-rm[1], -linkgit:git-mergetool[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-mergetool--lib.txt b/third_party/git/Documentation/git-mergetool--lib.txt deleted file mode 100644 index 4da9d24096..0000000000 --- a/third_party/git/Documentation/git-mergetool--lib.txt +++ /dev/null @@ -1,49 +0,0 @@ -git-mergetool{litdd}lib(1) -========================== - -NAME ----- -git-mergetool--lib - Common Git merge tool shell scriptlets - -SYNOPSIS --------- -[verse] -'TOOL_MODE=(diff|merge) . "$(git --exec-path)/git-mergetool{litdd}lib"' - -DESCRIPTION ------------ - -This is not a command the end user would want to run. Ever. -This documentation is meant for people who are studying the -Porcelain-ish scripts and/or are writing new ones. - -The 'git-mergetool{litdd}lib' scriptlet is designed to be sourced (using -`.`) by other shell scripts to set up functions for working -with Git merge tools. - -Before sourcing 'git-mergetool{litdd}lib', your script must set `TOOL_MODE` -to define the operation mode for the functions listed below. -'diff' and 'merge' are valid values. - -FUNCTIONS ---------- -get_merge_tool:: - returns a merge tool. the return code is 1 if we returned a guessed - merge tool, else 0. '$GIT_MERGETOOL_GUI' may be set to 'true' to - search for the appropriate guitool. - -get_merge_tool_cmd:: - returns the custom command for a merge tool. - -get_merge_tool_path:: - returns the custom path for a merge tool. - -run_merge_tool:: - launches a merge tool given the tool name and a true/false - flag to indicate whether a merge base is present. - '$MERGED', '$LOCAL', '$REMOTE', and '$BASE' must be defined - for use by the merge tool. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-mergetool.txt b/third_party/git/Documentation/git-mergetool.txt deleted file mode 100644 index 6b14702e78..0000000000 --- a/third_party/git/Documentation/git-mergetool.txt +++ /dev/null @@ -1,114 +0,0 @@ -git-mergetool(1) -================ - -NAME ----- -git-mergetool - Run merge conflict resolution tools to resolve merge conflicts - -SYNOPSIS --------- -[verse] -'git mergetool' [--tool=<tool>] [-y | --[no-]prompt] [<file>...] - -DESCRIPTION ------------ - -Use `git mergetool` to run one of several merge utilities to resolve -merge conflicts. It is typically run after 'git merge'. - -If one or more <file> parameters are given, the merge tool program will -be run to resolve differences on each file (skipping those without -conflicts). Specifying a directory will include all unresolved files in -that path. If no <file> names are specified, 'git mergetool' will run -the merge tool program on every file with merge conflicts. - -OPTIONS -------- --t <tool>:: ---tool=<tool>:: - Use the merge resolution program specified by <tool>. - Valid values include emerge, gvimdiff, kdiff3, - meld, vimdiff, and tortoisemerge. Run `git mergetool --tool-help` - for the list of valid <tool> settings. -+ -If a merge resolution program is not specified, 'git mergetool' -will use the configuration variable `merge.tool`. If the -configuration variable `merge.tool` is not set, 'git mergetool' -will pick a suitable default. -+ -You can explicitly provide a full path to the tool by setting the -configuration variable `mergetool.<tool>.path`. For example, you -can configure the absolute path to kdiff3 by setting -`mergetool.kdiff3.path`. Otherwise, 'git mergetool' assumes the -tool is available in PATH. -+ -Instead of running one of the known merge tool programs, -'git mergetool' can be customized to run an alternative program -by specifying the command line to invoke in a configuration -variable `mergetool.<tool>.cmd`. -+ -When 'git mergetool' is invoked with this tool (either through the -`-t` or `--tool` option or the `merge.tool` configuration -variable) the configured command line will be invoked with `$BASE` -set to the name of a temporary file containing the common base for -the merge, if available; `$LOCAL` set to the name of a temporary -file containing the contents of the file on the current branch; -`$REMOTE` set to the name of a temporary file containing the -contents of the file to be merged, and `$MERGED` set to the name -of the file to which the merge tool should write the result of the -merge resolution. -+ -If the custom merge tool correctly indicates the success of a -merge resolution with its exit code, then the configuration -variable `mergetool.<tool>.trustExitCode` can be set to `true`. -Otherwise, 'git mergetool' will prompt the user to indicate the -success of the resolution after the custom tool has exited. - ---tool-help:: - Print a list of merge tools that may be used with `--tool`. - --y:: ---no-prompt:: - Don't prompt before each invocation of the merge resolution - program. - This is the default if the merge resolution program is - explicitly specified with the `--tool` option or with the - `merge.tool` configuration variable. - ---prompt:: - Prompt before each invocation of the merge resolution program - to give the user a chance to skip the path. - --g:: ---gui:: - When 'git-mergetool' is invoked with the `-g` or `--gui` option - the default merge tool will be read from the configured - `merge.guitool` variable instead of `merge.tool`. If - `merge.guitool` is not set, we will fallback to the tool - configured under `merge.tool`. - ---no-gui:: - This overrides a previous `-g` or `--gui` setting and reads the - default merge tool will be read from the configured `merge.tool` - variable. - --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. -These are safe to remove once a file has been merged and its -`git mergetool` session has completed. - -Setting the `mergetool.keepBackup` configuration variable to `false` -causes `git mergetool` to automatically remove the backup as files -are successfully merged. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-mktag.txt b/third_party/git/Documentation/git-mktag.txt deleted file mode 100644 index fa6a756123..0000000000 --- a/third_party/git/Documentation/git-mktag.txt +++ /dev/null @@ -1,39 +0,0 @@ -git-mktag(1) -============ - -NAME ----- -git-mktag - Creates a tag object - - -SYNOPSIS --------- -[verse] -'git mktag' - -DESCRIPTION ------------ -Reads a tag contents on standard input and creates a tag object -that can also be used to sign other objects. - -The output is the new tag's <object> identifier. - -Tag Format ----------- -A tag signature file, to be fed to this command's standard input, -has a very simple fixed format: four lines of - - object <sha1> - type <typename> - tag <tagname> - tagger <tagger> - -followed by some 'optional' free-form message (some tags created -by older Git may not have `tagger` line). The message, when -exists, is separated by a blank line from the header. The -message part may contain a signature that Git itself doesn't -care about, but that can be verified with gpg. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-mktree.txt b/third_party/git/Documentation/git-mktree.txt deleted file mode 100644 index 27fe2b32e1..0000000000 --- a/third_party/git/Documentation/git-mktree.txt +++ /dev/null @@ -1,40 +0,0 @@ -git-mktree(1) -============= - -NAME ----- -git-mktree - Build a tree-object from ls-tree formatted text - - -SYNOPSIS --------- -[verse] -'git mktree' [-z] [--missing] [--batch] - -DESCRIPTION ------------ -Reads standard input in non-recursive `ls-tree` output format, and creates -a tree object. The order of the tree entries is normalized by mktree so -pre-sorting the input is not required. The object name of the tree object -built is written to the standard output. - -OPTIONS -------- --z:: - Read the NUL-terminated `ls-tree -z` output instead. - ---missing:: - Allow missing objects. The default behaviour (without this option) - is to verify that each tree entry's sha1 identifies an existing - object. This option has no effect on the treatment of gitlink entries - (aka "submodules") which are always allowed to be missing. - ---batch:: - Allow building of more than one tree object before exiting. Each - tree is separated by as single blank line. The final new-line is - optional. Note - if the `-z` option is used, lines are terminated - with NUL. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-multi-pack-index.txt b/third_party/git/Documentation/git-multi-pack-index.txt deleted file mode 100644 index 233b2b7862..0000000000 --- a/third_party/git/Documentation/git-multi-pack-index.txt +++ /dev/null @@ -1,88 +0,0 @@ -git-multi-pack-index(1) -======================= - -NAME ----- -git-multi-pack-index - Write and verify multi-pack-indexes - - -SYNOPSIS --------- -[verse] -'git multi-pack-index' [--object-dir=<dir>] <subcommand> - -DESCRIPTION ------------ -Write or verify a multi-pack-index (MIDX) file. - -OPTIONS -------- - ---object-dir=<dir>:: - Use given directory for the location of Git objects. We check - `<dir>/packs/multi-pack-index` for the current MIDX file, and - `<dir>/packs` for the pack-files to index. - -The following subcommands are available: - -write:: - Write a new MIDX file. - -verify:: - Verify the contents of the MIDX file. - -expire:: - Delete the pack-files that are tracked by the MIDX file, but - have no objects referenced by the MIDX. Rewrite the MIDX file - afterward to remove all references to these pack-files. - -repack:: - Create a new pack-file containing objects in small pack-files - referenced by the multi-pack-index. If the size given by the - `--batch-size=<size>` argument is zero, then create a pack - containing all objects referenced by the multi-pack-index. For - a non-zero batch size, Select the pack-files by examining packs - from oldest-to-newest, computing the "expected size" by counting - the number of objects in the pack referenced by the - multi-pack-index, then divide by the total number of objects in - the pack and multiply by the pack size. We select packs with - expected size below the batch size until the set of packs have - total expected size at least the batch size. If the total size - does not reach the batch size, then do nothing. If a new pack- - file is created, rewrite the multi-pack-index to reference the - new pack-file. A later run of 'git multi-pack-index expire' will - delete the pack-files that were part of this batch. - - -EXAMPLES --------- - -* Write a MIDX file for the packfiles in the current .git folder. -+ ------------------------------------------------ -$ git multi-pack-index write ------------------------------------------------ - -* Write a MIDX file for the packfiles in an alternate object store. -+ ------------------------------------------------ -$ git multi-pack-index --object-dir <alt> write ------------------------------------------------ - -* Verify the MIDX file for the packfiles in the current .git folder. -+ ------------------------------------------------ -$ git multi-pack-index verify ------------------------------------------------ - - -SEE ALSO --------- -See link:technical/multi-pack-index.html[The Multi-Pack-Index Design -Document] and link:technical/pack-format.html[The Multi-Pack-Index -Format] for more information on the multi-pack-index feature. - - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-mv.txt b/third_party/git/Documentation/git-mv.txt deleted file mode 100644 index 79449bf98f..0000000000 --- a/third_party/git/Documentation/git-mv.txt +++ /dev/null @@ -1,69 +0,0 @@ -git-mv(1) -========= - -NAME ----- -git-mv - Move or rename a file, a directory, or a symlink - - -SYNOPSIS --------- -[verse] -'git mv' <options>... <args>... - -DESCRIPTION ------------ -Move or rename a file, directory or symlink. - - git mv [-v] [-f] [-n] [-k] <source> <destination> - git mv [-v] [-f] [-n] [-k] <source> ... <destination directory> - -In the first form, it renames <source>, which must exist and be either -a file, symlink or directory, to <destination>. -In the second form, the last argument has to be an existing -directory; the given sources will be moved into this directory. - -The index is updated after successful completion, but the change must still be -committed. - -OPTIONS -------- --f:: ---force:: - Force renaming or moving of a file even if the target exists --k:: - Skip move or rename actions which would lead to an error - condition. An error happens when a source is neither existing nor - controlled by Git, or when it would overwrite an existing - file unless `-f` is given. --n:: ---dry-run:: - Do nothing; only show what would happen - --v:: ---verbose:: - Report the names of files as they are moved. - -SUBMODULES ----------- -Moving a submodule using a gitfile (which means they were cloned -with a Git version 1.7.8 or newer) will update the gitfile and -core.worktree setting to make the submodule work in the new location. -It also will attempt to update the submodule.<name>.path setting in -the linkgit:gitmodules[5] file and stage that file (unless -n is used). - -BUGS ----- -Each time a superproject update moves a populated submodule (e.g. when -switching between commits before and after the move) a stale submodule -checkout will remain in the old location and an empty directory will -appear in the new location. To populate the submodule again in the new -location the user will have to run "git submodule update" -afterwards. Removing the old directory is only safe when it uses a -gitfile, as otherwise the history of the submodule will be deleted -too. Both steps will be obsolete when recursive submodule update has -been implemented. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-name-rev.txt b/third_party/git/Documentation/git-name-rev.txt deleted file mode 100644 index 5cb0eb0855..0000000000 --- a/third_party/git/Documentation/git-name-rev.txt +++ /dev/null @@ -1,89 +0,0 @@ -git-name-rev(1) -=============== - -NAME ----- -git-name-rev - Find symbolic names for given revs - - -SYNOPSIS --------- -[verse] -'git name-rev' [--tags] [--refs=<pattern>] - ( --all | --stdin | <commit-ish>... ) - -DESCRIPTION ------------ -Finds symbolic names suitable for human digestion for revisions given in any -format parsable by 'git rev-parse'. - - -OPTIONS -------- - ---tags:: - Do not use branch names, but only tags to name the commits - ---refs=<pattern>:: - Only use refs whose names match a given shell pattern. The pattern - can be one of branch name, tag name or fully qualified ref name. If - given multiple times, use refs whose names match any of the given shell - patterns. Use `--no-refs` to clear any previous ref patterns given. - ---exclude=<pattern>:: - Do not use any ref whose name matches a given shell pattern. The - pattern can be one of branch name, tag name or fully qualified ref - name. If given multiple times, a ref will be excluded when it matches - any of the given patterns. When used together with --refs, a ref will - be used as a match only when it matches at least one --refs pattern and - does not match any --exclude patterns. Use `--no-exclude` to clear the - list of exclude patterns. - ---all:: - List all commits reachable from all refs - ---stdin:: - Transform stdin by substituting all the 40-character SHA-1 - hexes (say $hex) with "$hex ($rev_name)". When used with - --name-only, substitute with "$rev_name", omitting $hex - altogether. Intended for the scripter's use. - ---name-only:: - Instead of printing both the SHA-1 and the name, print only - the name. If given with --tags the usual tag prefix of - "tags/" is also omitted from the name, matching the output - of `git-describe` more closely. - ---no-undefined:: - Die with error code != 0 when a reference is undefined, - instead of printing `undefined`. - ---always:: - Show uniquely abbreviated commit object as fallback. - -EXAMPLES --------- - -Given a commit, find out where it is relative to the local refs. Say somebody -wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a. -Of course, you look into the commit, but that only tells you what happened, but -not the context. - -Enter 'git name-rev': - ------------- -% git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a -33db5f4d9027a10e477ccf054b2c1ab94f74c85a tags/v0.99~940 ------------- - -Now you are wiser, because you know that it happened 940 revisions before v0.99. - -Another nice thing you can do is: - ------------- -% git log | git name-rev --stdin ------------- - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-notes.txt b/third_party/git/Documentation/git-notes.txt deleted file mode 100644 index f56a5a9197..0000000000 --- a/third_party/git/Documentation/git-notes.txt +++ /dev/null @@ -1,405 +0,0 @@ -git-notes(1) -============ - -NAME ----- -git-notes - Add or inspect object notes - -SYNOPSIS --------- -[verse] -'git notes' [list [<object>]] -'git notes' add [-f] [--allow-empty] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] -'git notes' copy [-f] ( --stdin | <from-object> <to-object> ) -'git notes' append [--allow-empty] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] -'git notes' edit [--allow-empty] [<object>] -'git notes' show [<object>] -'git notes' merge [-v | -q] [-s <strategy> ] <notes-ref> -'git notes' merge --commit [-v | -q] -'git notes' merge --abort [-v | -q] -'git notes' remove [--ignore-missing] [--stdin] [<object>...] -'git notes' prune [-n] [-v] -'git notes' get-ref - - -DESCRIPTION ------------ -Adds, removes, or reads notes attached to objects, without touching -the objects themselves. - -By default, notes are saved to and read from `refs/notes/commits`, but -this default can be overridden. See the OPTIONS, CONFIGURATION, and -ENVIRONMENT sections below. If this ref does not exist, it will be -quietly created when it is first needed to store a note. - -A typical use of notes is to supplement a commit message without -changing the commit itself. Notes can be shown by 'git log' along with -the original commit message. To distinguish these notes from the -message stored in the commit object, the notes are indented like the -message, after an unindented line saying "Notes (<refname>):" (or -"Notes:" for `refs/notes/commits`). - -Notes can also be added to patches prepared with `git format-patch` by -using the `--notes` option. Such notes are added as a patch commentary -after a three dash separator line. - -To change which notes are shown by 'git log', see the -"notes.displayRef" configuration in linkgit:git-log[1]. - -See the "notes.rewrite.<command>" configuration for a way to carry -notes across commands that rewrite commits. - - -SUBCOMMANDS ------------ - -list:: - List the notes object for a given object. If no object is - given, show a list of all note objects and the objects they - annotate (in the format "<note object> <annotated object>"). - This is the default subcommand if no subcommand is given. - -add:: - Add notes for a given object (defaults to HEAD). Abort if the - object already has notes (use `-f` to overwrite existing notes). - However, if you're using `add` interactively (using an editor - to supply the notes contents), then - instead of aborting - - the existing notes will be opened in the editor (like the `edit` - subcommand). - -copy:: - Copy the notes for the first object onto the second object. - Abort if the second object already has notes, or if the first - object has none (use -f to overwrite existing notes to the - second object). This subcommand is equivalent to: - `git notes add [-f] -C $(git notes list <from-object>) <to-object>` -+ -In `--stdin` mode, take lines in the format -+ ----------- -<from-object> SP <to-object> [ SP <rest> ] LF ----------- -+ -on standard input, and copy the notes from each <from-object> to its -corresponding <to-object>. (The optional `<rest>` is ignored so that -the command can read the input given to the `post-rewrite` hook.) - -append:: - Append to the notes of an existing object (defaults to HEAD). - Creates a new notes object if needed. - -edit:: - Edit the notes for a given object (defaults to HEAD). - -show:: - Show the notes for a given object (defaults to HEAD). - -merge:: - Merge the given notes ref into the current notes ref. - This will try to merge the changes made by the given - notes ref (called "remote") since the merge-base (if - any) into the current notes ref (called "local"). -+ -If conflicts arise and a strategy for automatically resolving -conflicting notes (see the "NOTES MERGE STRATEGIES" section) is not given, -the "manual" resolver is used. This resolver checks out the -conflicting notes in a special worktree (`.git/NOTES_MERGE_WORKTREE`), -and instructs the user to manually resolve the conflicts there. -When done, the user can either finalize the merge with -'git notes merge --commit', or abort the merge with -'git notes merge --abort'. - -remove:: - Remove the notes for given objects (defaults to HEAD). When - giving zero or one object from the command line, this is - equivalent to specifying an empty note message to - the `edit` subcommand. - -prune:: - Remove all notes for non-existing/unreachable objects. - -get-ref:: - Print the current notes ref. This provides an easy way to - retrieve the current notes ref (e.g. from scripts). - -OPTIONS -------- --f:: ---force:: - When adding notes to an object that already has notes, - overwrite the existing notes (instead of aborting). - --m <msg>:: ---message=<msg>:: - Use the given note message (instead of prompting). - If multiple `-m` options are given, their values - are concatenated as separate paragraphs. - Lines starting with `#` and empty lines other than a - single line between paragraphs will be stripped out. - --F <file>:: ---file=<file>:: - Take the note message from the given file. Use '-' to - read the note message from the standard input. - Lines starting with `#` and empty lines other than a - single line between paragraphs will be stripped out. - --C <object>:: ---reuse-message=<object>:: - Take the given blob object (for example, another note) as the - note message. (Use `git notes copy <object>` instead to - copy notes between objects.) - --c <object>:: ---reedit-message=<object>:: - Like '-C', but with `-c` the editor is invoked, so that - the user can further edit the note message. - ---allow-empty:: - Allow an empty note object to be stored. The default behavior is - to automatically remove empty notes. - ---ref <ref>:: - Manipulate the notes tree in <ref>. This overrides - `GIT_NOTES_REF` and the "core.notesRef" configuration. The ref - specifies the full refname when it begins with `refs/notes/`; when it - begins with `notes/`, `refs/` and otherwise `refs/notes/` is prefixed - to form a full name of the ref. - ---ignore-missing:: - Do not consider it an error to request removing notes from an - object that does not have notes attached to it. - ---stdin:: - Also read the object names to remove notes from the standard - input (there is no reason you cannot combine this with object - names from the command line). - --n:: ---dry-run:: - Do not remove anything; just report the object names whose notes - would be removed. - --s <strategy>:: ---strategy=<strategy>:: - When merging notes, resolve notes conflicts using the given - strategy. The following strategies are recognized: "manual" - (default), "ours", "theirs", "union" and "cat_sort_uniq". - This option overrides the "notes.mergeStrategy" configuration setting. - See the "NOTES MERGE STRATEGIES" section below for more - information on each notes merge strategy. - ---commit:: - Finalize an in-progress 'git notes merge'. Use this option - when you have resolved the conflicts that 'git notes merge' - stored in .git/NOTES_MERGE_WORKTREE. This amends the partial - merge commit created by 'git notes merge' (stored in - .git/NOTES_MERGE_PARTIAL) by adding the notes in - .git/NOTES_MERGE_WORKTREE. The notes ref stored in the - .git/NOTES_MERGE_REF symref is updated to the resulting commit. - ---abort:: - Abort/reset an in-progress 'git notes merge', i.e. a notes merge - with conflicts. This simply removes all files related to the - notes merge. - --q:: ---quiet:: - When merging notes, operate quietly. - --v:: ---verbose:: - When merging notes, be more verbose. - When pruning notes, report all object names whose notes are - removed. - - -DISCUSSION ----------- - -Commit notes are blobs containing extra information about an object -(usually information to supplement a commit's message). These blobs -are taken from notes refs. A notes ref is usually a branch which -contains "files" whose paths are the object names for the objects -they describe, with some directory separators included for performance -reasons footnote:[Permitted pathnames have the form -'ab'`/`'cd'`/`'ef'`/`'...'`/`'abcdef...': a sequence of directory -names of two hexadecimal digits each followed by a filename with the -rest of the object ID.]. - -Every notes change creates a new commit at the specified notes ref. -You can therefore inspect the history of the notes by invoking, e.g., -`git log -p notes/commits`. Currently the commit message only records -which operation triggered the update, and the commit authorship is -determined according to the usual rules (see linkgit:git-commit[1]). -These details may change in the future. - -It is also permitted for a notes ref to point directly to a tree -object, in which case the history of the notes can be read with -`git log -p -g <refname>`. - - -NOTES MERGE STRATEGIES ----------------------- - -The default notes merge strategy is "manual", which checks out -conflicting notes in a special work tree for resolving notes conflicts -(`.git/NOTES_MERGE_WORKTREE`), and instructs the user to resolve the -conflicts in that work tree. -When done, the user can either finalize the merge with -'git notes merge --commit', or abort the merge with -'git notes merge --abort'. - -Users may select an automated merge strategy from among the following using -either -s/--strategy option or configuring notes.mergeStrategy accordingly: - -"ours" automatically resolves conflicting notes in favor of the local -version (i.e. the current notes ref). - -"theirs" automatically resolves notes conflicts in favor of the remote -version (i.e. the given notes ref being merged into the current notes -ref). - -"union" automatically resolves notes conflicts by concatenating the -local and remote versions. - -"cat_sort_uniq" is similar to "union", but in addition to concatenating -the local and remote versions, this strategy also sorts the resulting -lines, and removes duplicate lines from the result. This is equivalent -to applying the "cat | sort | uniq" shell pipeline to the local and -remote versions. This strategy is useful if the notes follow a line-based -format where one wants to avoid duplicated lines in the merge result. -Note that if either the local or remote version contain duplicate lines -prior to the merge, these will also be removed by this notes merge -strategy. - - -EXAMPLES --------- - -You can use notes to add annotations with information that was not -available at the time a commit was written. - ------------- -$ git notes add -m 'Tested-by: Johannes Sixt <j6t@kdbg.org>' 72a144e2 -$ git show -s 72a144e -[...] - Signed-off-by: Junio C Hamano <gitster@pobox.com> - -Notes: - Tested-by: Johannes Sixt <j6t@kdbg.org> ------------- - -In principle, a note is a regular Git blob, and any kind of -(non-)format is accepted. You can binary-safely create notes from -arbitrary files using 'git hash-object': - ------------- -$ cc *.c -$ blob=$(git hash-object -w a.out) -$ git notes --ref=built add --allow-empty -C "$blob" HEAD ------------- - -(You cannot simply use `git notes --ref=built add -F a.out HEAD` -because that is not binary-safe.) -Of course, it doesn't make much sense to display non-text-format notes -with 'git log', so if you use such notes, you'll probably need to write -some special-purpose tools to do something useful with them. - - -CONFIGURATION -------------- - -core.notesRef:: - Notes ref to read and manipulate instead of - `refs/notes/commits`. Must be an unabbreviated ref name. - This setting can be overridden through the environment and - command line. - -notes.mergeStrategy:: - Which merge strategy to choose by default when resolving notes - conflicts. Must be one of `manual`, `ours`, `theirs`, `union`, or - `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE STRATEGIES" - section above for more information on each strategy. -+ -This setting can be overridden by passing the `--strategy` option. - -notes.<name>.mergeStrategy:: - Which merge strategy to choose when doing a notes merge into - refs/notes/<name>. This overrides the more general - "notes.mergeStrategy". See the "NOTES MERGE STRATEGIES" section above - for more information on each available strategy. - -notes.displayRef:: - Which ref (or refs, if a glob or specified more than once), in - addition to the default set by `core.notesRef` or - `GIT_NOTES_REF`, to read notes from when showing commit - messages with the 'git log' family of commands. - This setting can be overridden on the command line or by the - `GIT_NOTES_DISPLAY_REF` environment variable. - See linkgit:git-log[1]. - -notes.rewrite.<command>:: - When rewriting commits with <command> (currently `amend` or - `rebase`), if this variable is `false`, git will not copy - notes from the original to the rewritten commit. Defaults to - `true`. See also "`notes.rewriteRef`" below. -+ -This setting can be overridden by the `GIT_NOTES_REWRITE_REF` -environment variable. - -notes.rewriteMode:: - When copying notes during a rewrite, what to do if the target - commit already has a note. Must be one of `overwrite`, - `concatenate`, `cat_sort_uniq`, or `ignore`. Defaults to - `concatenate`. -+ -This setting can be overridden with the `GIT_NOTES_REWRITE_MODE` -environment variable. - -notes.rewriteRef:: - When copying notes during a rewrite, specifies the (fully - qualified) ref whose notes should be copied. May be a glob, - in which case notes in all matching refs will be copied. You - may also specify this configuration several times. -+ -Does not have a default value; you must configure this variable to -enable note rewriting. -+ -Can be overridden with the `GIT_NOTES_REWRITE_REF` environment variable. - - -ENVIRONMENT ------------ - -`GIT_NOTES_REF`:: - Which ref to manipulate notes from, instead of `refs/notes/commits`. - This overrides the `core.notesRef` setting. - -`GIT_NOTES_DISPLAY_REF`:: - Colon-delimited list of refs or globs indicating which refs, - in addition to the default from `core.notesRef` or - `GIT_NOTES_REF`, to read notes from when showing commit - messages. - This overrides the `notes.displayRef` setting. -+ -A warning will be issued for refs that do not exist, but a glob that -does not match any refs is silently ignored. - -`GIT_NOTES_REWRITE_MODE`:: - When copying notes during a rewrite, what to do if the target - commit already has a note. - Must be one of `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`. - This overrides the `core.rewriteMode` setting. - -`GIT_NOTES_REWRITE_REF`:: - When rewriting commits, which notes to copy from the original - to the rewritten commit. Must be a colon-delimited list of - refs or globs. -+ -If not set in the environment, the list of notes to copy depends -on the `notes.rewrite.<command>` and `notes.rewriteRef` settings. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-p4.txt b/third_party/git/Documentation/git-p4.txt deleted file mode 100644 index 3494a1db3e..0000000000 --- a/third_party/git/Documentation/git-p4.txt +++ /dev/null @@ -1,723 +0,0 @@ -git-p4(1) -========= - -NAME ----- -git-p4 - Import from and submit to Perforce repositories - - -SYNOPSIS --------- -[verse] -'git p4 clone' [<sync options>] [<clone options>] <p4 depot path>... -'git p4 sync' [<sync options>] [<p4 depot path>...] -'git p4 rebase' -'git p4 submit' [<submit options>] [<master branch name>] - - -DESCRIPTION ------------ -This command provides a way to interact with p4 repositories -using Git. - -Create a new Git repository from an existing p4 repository using -'git p4 clone', giving it one or more p4 depot paths. Incorporate -new commits from p4 changes with 'git p4 sync'. The 'sync' command -is also used to include new branches from other p4 depot paths. -Submit Git changes back to p4 using 'git p4 submit'. The command -'git p4 rebase' does a sync plus rebases the current branch onto -the updated p4 remote branch. - - -EXAMPLES --------- -* Clone a repository: -+ ------------- -$ git p4 clone //depot/path/project ------------- - -* Do some work in the newly created Git repository: -+ ------------- -$ cd project -$ vi foo.h -$ git commit -a -m "edited foo.h" ------------- - -* Update the Git repository with recent changes from p4, rebasing your - work on top: -+ ------------- -$ git p4 rebase ------------- - -* Submit your commits back to p4: -+ ------------- -$ git p4 submit ------------- - - -COMMANDS --------- - -Clone -~~~~~ -Generally, 'git p4 clone' is used to create a new Git directory -from an existing p4 repository: ------------- -$ git p4 clone //depot/path/project ------------- -This: - -1. Creates an empty Git repository in a subdirectory called 'project'. -+ -2. Imports the full contents of the head revision from the given p4 - depot path into a single commit in the Git branch 'refs/remotes/p4/master'. -+ -3. Creates a local branch, 'master' from this remote and checks it out. - -To reproduce the entire p4 history in Git, use the '@all' modifier on -the depot path: ------------- -$ git p4 clone //depot/path/project@all ------------- - - -Sync -~~~~ -As development continues in the p4 repository, those changes can -be included in the Git repository using: ------------- -$ git p4 sync ------------- -This command finds new changes in p4 and imports them as Git commits. - -P4 repositories can be added to an existing Git repository using -'git p4 sync' too: ------------- -$ mkdir repo-git -$ cd repo-git -$ git init -$ git p4 sync //path/in/your/perforce/depot ------------- -This imports the specified depot into -'refs/remotes/p4/master' in an existing Git repository. The -`--branch` option can be used to specify a different branch to -be used for the p4 content. - -If a Git repository includes branches 'refs/remotes/origin/p4', these -will be fetched and consulted first during a 'git p4 sync'. Since -importing directly from p4 is considerably slower than pulling changes -from a Git remote, this can be useful in a multi-developer environment. - -If there are multiple branches, doing 'git p4 sync' will automatically -use the "BRANCH DETECTION" algorithm to try to partition new changes -into the right branch. This can be overridden with the `--branch` -option to specify just a single branch to update. - - -Rebase -~~~~~~ -A common working pattern is to fetch the latest changes from the p4 depot -and merge them with local uncommitted changes. Often, the p4 repository -is the ultimate location for all code, thus a rebase workflow makes -sense. This command does 'git p4 sync' followed by 'git rebase' to move -local commits on top of updated p4 changes. ------------- -$ git p4 rebase ------------- - - -Submit -~~~~~~ -Submitting changes from a Git repository back to the p4 repository -requires a separate p4 client workspace. This should be specified -using the `P4CLIENT` environment variable or the Git configuration -variable 'git-p4.client'. The p4 client must exist, but the client root -will be created and populated if it does not already exist. - -To submit all changes that are in the current Git branch but not in -the 'p4/master' branch, use: ------------- -$ git p4 submit ------------- - -To specify a branch other than the current one, use: ------------- -$ git p4 submit topicbranch ------------- - -To specify a single commit or a range of commits, use: ------------- -$ git p4 submit --commit <sha1> -$ git p4 submit --commit <sha1..sha1> ------------- - -The upstream reference is generally 'refs/remotes/p4/master', but can -be overridden using the `--origin=` command-line option. - -The p4 changes will be created as the user invoking 'git p4 submit'. The -`--preserve-user` option will cause ownership to be modified -according to the author of the Git commit. This option requires admin -privileges in p4, which can be granted using 'p4 protect'. - -To shelve changes instead of submitting, use `--shelve` and `--update-shelve`: - ----- -$ git p4 submit --shelve -$ git p4 submit --update-shelve 1234 --update-shelve 2345 ----- - - -Unshelve -~~~~~~~~ -Unshelving will take a shelved P4 changelist, and produce the equivalent git commit -in the branch refs/remotes/p4-unshelved/<changelist>. - -The git commit is created relative to the current origin revision (HEAD by default). -A parent commit is created based on the origin, and then the unshelve commit is -created based on that. - -The origin revision can be changed with the "--origin" option. - -If the target branch in refs/remotes/p4-unshelved already exists, the old one will -be renamed. - ----- -$ git p4 sync -$ git p4 unshelve 12345 -$ git show p4-unshelved/12345 -<submit more changes via p4 to the same files> -$ git p4 unshelve 12345 -<refuses to unshelve until git is in sync with p4 again> - ----- - -OPTIONS -------- - -General options -~~~~~~~~~~~~~~~ -All commands except clone accept these options. - ---git-dir <dir>:: - Set the `GIT_DIR` environment variable. See linkgit:git[1]. - --v:: ---verbose:: - Provide more progress information. - -Sync options -~~~~~~~~~~~~ -These options can be used in the initial 'clone' as well as in -subsequent 'sync' operations. - ---branch <ref>:: - Import changes into <ref> instead of refs/remotes/p4/master. - If <ref> starts with refs/, it is used as is. Otherwise, if - it does not start with p4/, that prefix is added. -+ -By default a <ref> not starting with refs/ is treated as the -name of a remote-tracking branch (under refs/remotes/). This -behavior can be modified using the --import-local option. -+ -The default <ref> is "master". -+ -This example imports a new remote "p4/proj2" into an existing -Git repository: -+ ----- - $ git init - $ git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2 ----- - ---detect-branches:: - Use the branch detection algorithm to find new paths in p4. It is - documented below in "BRANCH DETECTION". - ---changesfile <file>:: - Import exactly the p4 change numbers listed in 'file', one per - line. Normally, 'git p4' inspects the current p4 repository - state and detects the changes it should import. - ---silent:: - Do not print any progress information. - ---detect-labels:: - Query p4 for labels associated with the depot paths, and add - them as tags in Git. Limited usefulness as only imports labels - associated with new changelists. Deprecated. - ---import-labels:: - Import labels from p4 into Git. - ---import-local:: - By default, p4 branches are stored in 'refs/remotes/p4/', - where they will be treated as remote-tracking branches by - linkgit:git-branch[1] and other commands. This option instead - puts p4 branches in 'refs/heads/p4/'. Note that future - sync operations must specify `--import-local` as well so that - they can find the p4 branches in refs/heads. - ---max-changes <n>:: - Import at most 'n' changes, rather than the entire range of - changes included in the given revision specifier. A typical - usage would be use '@all' as the revision specifier, but then - to use '--max-changes 1000' to import only the last 1000 - revisions rather than the entire revision history. - ---changes-block-size <n>:: - The internal block size to use when converting a revision - specifier such as '@all' into a list of specific change - numbers. Instead of using a single call to 'p4 changes' to - find the full list of changes for the conversion, there are a - sequence of calls to 'p4 changes -m', each of which requests - one block of changes of the given size. The default block size - is 500, which should usually be suitable. - ---keep-path:: - The mapping of file names from the p4 depot path to Git, by - default, involves removing the entire depot path. With this - option, the full p4 depot path is retained in Git. For example, - path '//depot/main/foo/bar.c', when imported from - '//depot/main/', becomes 'foo/bar.c'. With `--keep-path`, the - Git path is instead 'depot/main/foo/bar.c'. - ---use-client-spec:: - Use a client spec to find the list of interesting files in p4. - See the "CLIENT SPEC" section below. - --/ <path>:: - Exclude selected depot paths when cloning or syncing. - -Clone options -~~~~~~~~~~~~~ -These options can be used in an initial 'clone', along with the 'sync' -options described above. - ---destination <directory>:: - Where to create the Git repository. If not provided, the last - component in the p4 depot path is used to create a new - directory. - ---bare:: - Perform a bare clone. See linkgit:git-clone[1]. - -Submit options -~~~~~~~~~~~~~~ -These options can be used to modify 'git p4 submit' behavior. - ---origin <commit>:: - Upstream location from which commits are identified to submit to - p4. By default, this is the most recent p4 commit reachable - from `HEAD`. - --M:: - Detect renames. See linkgit:git-diff[1]. Renames will be - represented in p4 using explicit 'move' operations. There - is no corresponding option to detect copies, but there are - variables for both moves and copies. - ---preserve-user:: - Re-author p4 changes before submitting to p4. This option - requires p4 admin privileges. - ---export-labels:: - Export tags from Git as p4 labels. Tags found in Git are applied - to the perforce working directory. - --n:: ---dry-run:: - Show just what commits would be submitted to p4; do not change - state in Git or p4. - ---prepare-p4-only:: - Apply a commit to the p4 workspace, opening, adding and deleting - files in p4 as for a normal submit operation. Do not issue the - final "p4 submit", but instead print a message about how to - submit manually or revert. This option always stops after the - first (oldest) commit. Git tags are not exported to p4. - ---shelve:: - Instead of submitting create a series of shelved changelists. - After creating each shelve, the relevant files are reverted/deleted. - If you have multiple commits pending multiple shelves will be created. - ---update-shelve CHANGELIST:: - Update an existing shelved changelist with this commit. Implies - --shelve. Repeat for multiple shelved changelists. - ---conflict=(ask|skip|quit):: - Conflicts can occur when applying a commit to p4. When this - happens, the default behavior ("ask") is to prompt whether to - skip this commit and continue, or quit. This option can be used - to bypass the prompt, causing conflicting commits to be automatically - skipped, or to quit trying to apply commits, without prompting. - ---branch <branch>:: - After submitting, sync this named branch instead of the default - p4/master. See the "Sync options" section above for more - information. - ---commit <sha1>|<sha1..sha1>:: - Submit only the specified commit or range of commits, instead of the full - list of changes that are in the current Git branch. - ---disable-rebase:: - Disable the automatic rebase after all commits have been successfully - submitted. Can also be set with git-p4.disableRebase. - ---disable-p4sync:: - Disable the automatic sync of p4/master from Perforce after commits have - been submitted. Implies --disable-rebase. Can also be set with - git-p4.disableP4Sync. Sync with origin/master still goes ahead if possible. - -Hook for submit -~~~~~~~~~~~~~~~ -The `p4-pre-submit` hook is executed if it exists and is executable. -The hook takes no parameters and nothing from standard input. Exiting with -non-zero status from this script prevents `git-p4 submit` from launching. - -One usage scenario is to run unit tests in the hook. - -Rebase options -~~~~~~~~~~~~~~ -These options can be used to modify 'git p4 rebase' behavior. - ---import-labels:: - Import p4 labels. - -Unshelve options -~~~~~~~~~~~~~~~~ - ---origin:: - Sets the git refspec against which the shelved P4 changelist is compared. - Defaults to p4/master. - -DEPOT PATH SYNTAX ------------------ -The p4 depot path argument to 'git p4 sync' and 'git p4 clone' can -be one or more space-separated p4 depot paths, with an optional -p4 revision specifier on the end: - -"//depot/my/project":: - Import one commit with all files in the '#head' change under that tree. - -"//depot/my/project@all":: - Import one commit for each change in the history of that depot path. - -"//depot/my/project@1,6":: - Import only changes 1 through 6. - -"//depot/proj1@all //depot/proj2@all":: - Import all changes from both named depot paths into a single - repository. Only files below these directories are included. - There is not a subdirectory in Git for each "proj1" and "proj2". - You must use the `--destination` option when specifying more - than one depot path. The revision specifier must be specified - identically on each depot path. If there are files in the - depot paths with the same name, the path with the most recently - updated version of the file is the one that appears in Git. - -See 'p4 help revisions' for the full syntax of p4 revision specifiers. - - -CLIENT SPEC ------------ -The p4 client specification is maintained with the 'p4 client' command -and contains among other fields, a View that specifies how the depot -is mapped into the client repository. The 'clone' and 'sync' commands -can consult the client spec when given the `--use-client-spec` option or -when the useClientSpec variable is true. After 'git p4 clone', the -useClientSpec variable is automatically set in the repository -configuration file. This allows future 'git p4 submit' commands to -work properly; the submit command looks only at the variable and does -not have a command-line option. - -The full syntax for a p4 view is documented in 'p4 help views'. 'git p4' -knows only a subset of the view syntax. It understands multi-line -mappings, overlays with '+', exclusions with '-' and double-quotes -around whitespace. Of the possible wildcards, 'git p4' only handles -'...', and only when it is at the end of the path. 'git p4' will complain -if it encounters an unhandled wildcard. - -Bugs in the implementation of overlap mappings exist. If multiple depot -paths map through overlays to the same location in the repository, -'git p4' can choose the wrong one. This is hard to solve without -dedicating a client spec just for 'git p4'. - -The name of the client can be given to 'git p4' in multiple ways. The -variable 'git-p4.client' takes precedence if it exists. Otherwise, -normal p4 mechanisms of determining the client are used: environment -variable `P4CLIENT`, a file referenced by `P4CONFIG`, or the local host name. - - -BRANCH DETECTION ----------------- -P4 does not have the same concept of a branch as Git. Instead, -p4 organizes its content as a directory tree, where by convention -different logical branches are in different locations in the tree. -The 'p4 branch' command is used to maintain mappings between -different areas in the tree, and indicate related content. 'git p4' -can use these mappings to determine branch relationships. - -If you have a repository where all the branches of interest exist as -subdirectories of a single depot path, you can use `--detect-branches` -when cloning or syncing to have 'git p4' automatically find -subdirectories in p4, and to generate these as branches in Git. - -For example, if the P4 repository structure is: ----- -//depot/main/... -//depot/branch1/... ----- - -And "p4 branch -o branch1" shows a View line that looks like: ----- -//depot/main/... //depot/branch1/... ----- - -Then this 'git p4 clone' command: ----- -git p4 clone --detect-branches //depot@all ----- -produces a separate branch in 'refs/remotes/p4/' for //depot/main, -called 'master', and one for //depot/branch1 called 'depot/branch1'. - -However, it is not necessary to create branches in p4 to be able to use -them like branches. Because it is difficult to infer branch -relationships automatically, a Git configuration setting -'git-p4.branchList' can be used to explicitly identify branch -relationships. It is a list of "source:destination" pairs, like a -simple p4 branch specification, where the "source" and "destination" are -the path elements in the p4 repository. The example above relied on the -presence of the p4 branch. Without p4 branches, the same result will -occur with: ----- -git init depot -cd depot -git config git-p4.branchList main:branch1 -git p4 clone --detect-branches //depot@all . ----- - - -PERFORMANCE ------------ -The fast-import mechanism used by 'git p4' creates one pack file for -each invocation of 'git p4 sync'. Normally, Git garbage compression -(linkgit:git-gc[1]) automatically compresses these to fewer pack files, -but explicit invocation of 'git repack -adf' may improve performance. - - -CONFIGURATION VARIABLES ------------------------ -The following config settings can be used to modify 'git p4' behavior. -They all are in the 'git-p4' section. - -General variables -~~~~~~~~~~~~~~~~~ -git-p4.user:: - User specified as an option to all p4 commands, with '-u <user>'. - The environment variable `P4USER` can be used instead. - -git-p4.password:: - Password specified as an option to all p4 commands, with - '-P <password>'. - The environment variable `P4PASS` can be used instead. - -git-p4.port:: - Port specified as an option to all p4 commands, with - '-p <port>'. - The environment variable `P4PORT` can be used instead. - -git-p4.host:: - Host specified as an option to all p4 commands, with - '-h <host>'. - The environment variable `P4HOST` can be used instead. - -git-p4.client:: - Client specified as an option to all p4 commands, with - '-c <client>', including the client spec. - -git-p4.retries:: - Specifies the number of times to retry a p4 command (notably, - 'p4 sync') if the network times out. The default value is 3. - Set the value to 0 to disable retries or if your p4 version - does not support retries (pre 2012.2). - -Clone and sync variables -~~~~~~~~~~~~~~~~~~~~~~~~ -git-p4.syncFromOrigin:: - Because importing commits from other Git repositories is much faster - than importing them from p4, a mechanism exists to find p4 changes - first in Git remotes. If branches exist under 'refs/remote/origin/p4', - those will be fetched and used when syncing from p4. This - variable can be set to 'false' to disable this behavior. - -git-p4.branchUser:: - One phase in branch detection involves looking at p4 branches - to find new ones to import. By default, all branches are - inspected. This option limits the search to just those owned - by the single user named in the variable. - -git-p4.branchList:: - List of branches to be imported when branch detection is - enabled. Each entry should be a pair of branch names separated - by a colon (:). This example declares that both branchA and - branchB were created from main: -+ -------------- -git config git-p4.branchList main:branchA -git config --add git-p4.branchList main:branchB -------------- - -git-p4.ignoredP4Labels:: - List of p4 labels to ignore. This is built automatically as - unimportable labels are discovered. - -git-p4.importLabels:: - Import p4 labels into git, as per --import-labels. - -git-p4.labelImportRegexp:: - Only p4 labels matching this regular expression will be imported. The - default value is '[a-zA-Z0-9_\-.]+$'. - -git-p4.useClientSpec:: - Specify that the p4 client spec should be used to identify p4 - depot paths of interest. This is equivalent to specifying the - option `--use-client-spec`. See the "CLIENT SPEC" section above. - This variable is a boolean, not the name of a p4 client. - -git-p4.pathEncoding:: - Perforce keeps the encoding of a path as given by the originating OS. - Git expects paths encoded as UTF-8. Use this config to tell git-p4 - what encoding Perforce had used for the paths. This encoding is used - to transcode the paths to UTF-8. As an example, Perforce on Windows - often uses "cp1252" to encode path names. - -git-p4.largeFileSystem:: - Specify the system that is used for large (binary) files. Please note - that large file systems do not support the 'git p4 submit' command. - Only Git LFS is implemented right now (see https://git-lfs.github.com/ - for more information). Download and install the Git LFS command line - extension to use this option and configure it like this: -+ -------------- -git config git-p4.largeFileSystem GitLFS -------------- - -git-p4.largeFileExtensions:: - All files matching a file extension in the list will be processed - by the large file system. Do not prefix the extensions with '.'. - -git-p4.largeFileThreshold:: - All files with an uncompressed size exceeding the threshold will be - processed by the large file system. By default the threshold is - defined in bytes. Add the suffix k, m, or g to change the unit. - -git-p4.largeFileCompressedThreshold:: - All files with a compressed size exceeding the threshold will be - processed by the large file system. This option might slow down - your clone/sync process. By default the threshold is defined in - bytes. Add the suffix k, m, or g to change the unit. - -git-p4.largeFilePush:: - Boolean variable which defines if large files are automatically - pushed to a server. - -git-p4.keepEmptyCommits:: - A changelist that contains only excluded files will be imported - as an empty commit if this boolean option is set to true. - -git-p4.mapUser:: - Map a P4 user to a name and email address in Git. Use a string - with the following format to create a mapping: -+ -------------- -git config --add git-p4.mapUser "p4user = First Last <mail@address.com>" -------------- -+ -A mapping will override any user information from P4. Mappings for -multiple P4 user can be defined. - -Submit variables -~~~~~~~~~~~~~~~~ -git-p4.detectRenames:: - Detect renames. See linkgit:git-diff[1]. This can be true, - false, or a score as expected by 'git diff -M'. - -git-p4.detectCopies:: - Detect copies. See linkgit:git-diff[1]. This can be true, - false, or a score as expected by 'git diff -C'. - -git-p4.detectCopiesHarder:: - Detect copies harder. See linkgit:git-diff[1]. A boolean. - -git-p4.preserveUser:: - On submit, re-author changes to reflect the Git author, - regardless of who invokes 'git p4 submit'. - -git-p4.allowMissingP4Users:: - When 'preserveUser' is true, 'git p4' normally dies if it - cannot find an author in the p4 user map. This setting - submits the change regardless. - -git-p4.skipSubmitEdit:: - The submit process invokes the editor before each p4 change - is submitted. If this setting is true, though, the editing - step is skipped. - -git-p4.skipSubmitEditCheck:: - After editing the p4 change message, 'git p4' makes sure that - the description really was changed by looking at the file - modification time. This option disables that test. - -git-p4.allowSubmit:: - By default, any branch can be used as the source for a 'git p4 - submit' operation. This configuration variable, if set, permits only - the named branches to be used as submit sources. Branch names - must be the short names (no "refs/heads/"), and should be - separated by commas (","), with no spaces. - -git-p4.skipUserNameCheck:: - If the user running 'git p4 submit' does not exist in the p4 - user map, 'git p4' exits. This option can be used to force - submission regardless. - -git-p4.attemptRCSCleanup:: - If enabled, 'git p4 submit' will attempt to cleanup RCS keywords - ($Header$, etc). These would otherwise cause merge conflicts and prevent - the submit going ahead. This option should be considered experimental at - present. - -git-p4.exportLabels:: - Export Git tags to p4 labels, as per --export-labels. - -git-p4.labelExportRegexp:: - Only p4 labels matching this regular expression will be exported. The - default value is '[a-zA-Z0-9_\-.]+$'. - -git-p4.conflict:: - Specify submit behavior when a conflict with p4 is found, as per - --conflict. The default behavior is 'ask'. - -git-p4.disableRebase:: - Do not rebase the tree against p4/master following a submit. - -git-p4.disableP4Sync:: - Do not sync p4/master with Perforce following a submit. Implies git-p4.disableRebase. - -IMPLEMENTATION DETAILS ----------------------- -* Changesets from p4 are imported using Git fast-import. -* Cloning or syncing does not require a p4 client; file contents are - collected using 'p4 print'. -* Submitting requires a p4 client, which is not in the same location - as the Git repository. Patches are applied, one at a time, to - this p4 client and submitted from there. -* Each commit imported by 'git p4' has a line at the end of the log - message indicating the p4 depot location and change number. This - line is used by later 'git p4 sync' operations to know which p4 - changes are new. diff --git a/third_party/git/Documentation/git-pack-objects.txt b/third_party/git/Documentation/git-pack-objects.txt deleted file mode 100644 index fecdf2600c..0000000000 --- a/third_party/git/Documentation/git-pack-objects.txt +++ /dev/null @@ -1,406 +0,0 @@ -git-pack-objects(1) -=================== - -NAME ----- -git-pack-objects - Create a packed archive of objects - - -SYNOPSIS --------- -[verse] -'git pack-objects' [-q | --progress | --all-progress] [--all-progress-implied] - [--no-reuse-delta] [--delta-base-offset] [--non-empty] - [--local] [--incremental] [--window=<n>] [--depth=<n>] - [--revs [--unpacked | --all]] [--keep-pack=<pack-name>] - [--stdout [--filter=<filter-spec>] | base-name] - [--shallow] [--keep-true-parents] [--sparse] < object-list - - -DESCRIPTION ------------ -Reads list of objects from the standard input, and writes either one or -more packed archives with the specified base-name to disk, or a packed -archive to the standard output. - -A packed archive is an efficient way to transfer a set of objects -between two repositories as well as an access efficient archival -format. In a packed archive, an object is either stored as a -compressed whole or as a difference from some other object. -The latter is often called a delta. - -The packed archive format (.pack) is designed to be self-contained -so that it can be unpacked without any further information. Therefore, -each object that a delta depends upon must be present within the pack. - -A pack index file (.idx) is generated for fast, random access to the -objects in the pack. Placing both the index file (.idx) and the packed -archive (.pack) in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or -any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES) -enables Git to read from the pack archive. - -The 'git unpack-objects' command can read the packed archive and -expand the objects contained in the pack into "one-file -one-object" format; this is typically done by the smart-pull -commands when a pack is created on-the-fly for efficient network -transport by their peers. - - -OPTIONS -------- -base-name:: - Write into pairs of files (.pack and .idx), using - <base-name> to determine the name of the created file. - When this option is used, the two files in a pair are written in - <base-name>-<SHA-1>.{pack,idx} files. <SHA-1> is a hash - based on the pack content and is written to the standard - output of the command. - ---stdout:: - Write the pack contents (what would have been written to - .pack file) out to the standard output. - ---revs:: - Read the revision arguments from the standard input, instead of - individual object names. The revision arguments are processed - the same way as 'git rev-list' with the `--objects` flag - uses its `commit` arguments to build the list of objects it - outputs. The objects on the resulting list are packed. - Besides revisions, `--not` or `--shallow <SHA-1>` lines are - also accepted. - ---unpacked:: - This implies `--revs`. When processing the list of - revision arguments read from the standard input, limit - the objects packed to those that are not already packed. - ---all:: - This implies `--revs`. In addition to the list of - revision arguments read from the standard input, pretend - as if all refs under `refs/` are specified to be - included. - ---include-tag:: - Include unasked-for annotated tags if the object they - reference was included in the resulting packfile. This - can be useful to send new tags to native Git clients. - ---window=<n>:: ---depth=<n>:: - These two options affect how the objects contained in - the pack are stored using delta compression. The - objects are first internally sorted by type, size and - optionally names and compared against the other objects - within --window to see if using delta compression saves - space. --depth limits the maximum delta depth; making - it too deep affects the performance on the unpacker - side, because delta data needs to be applied that many - times to get to the necessary object. -+ -The default value for --window is 10 and --depth is 50. The maximum -depth is 4095. - ---window-memory=<n>:: - This option provides an additional limit on top of `--window`; - the window size will dynamically scale down so as to not take - up more than '<n>' bytes in memory. This is useful in - repositories with a mix of large and small objects to not run - out of memory with a large window, but still be able to take - advantage of the large window for the smaller objects. The - size can be suffixed with "k", "m", or "g". - `--window-memory=0` makes memory usage unlimited. The default - is taken from the `pack.windowMemory` configuration variable. - ---max-pack-size=<n>:: - In unusual scenarios, you may not be able to create files - larger than a certain size on your filesystem, and this option - can be used to tell the command to split the output packfile - into multiple independent packfiles, each not larger than the - given size. The size can be suffixed with - "k", "m", or "g". The minimum size allowed is limited to 1 MiB. - This option - prevents the creation of a bitmap index. - The default is unlimited, unless the config variable - `pack.packSizeLimit` is set. - ---honor-pack-keep:: - This flag causes an object already in a local pack that - has a .keep file to be ignored, even if it would have - otherwise been packed. - ---keep-pack=<pack-name>:: - This flag causes an object already in the given pack to be - ignored, even if it would have otherwise been - packed. `<pack-name>` is the pack file name without - leading directory (e.g. `pack-123.pack`). The option could be - specified multiple times to keep multiple packs. - ---incremental:: - This flag causes an object already in a pack to be ignored - even if it would have otherwise been packed. - ---local:: - This flag causes an object that is borrowed from an alternate - object store to be ignored even if it would have otherwise been - packed. - ---non-empty:: - Only create a packed archive if it would contain at - least one object. - ---progress:: - Progress status is reported on the standard error stream - by default when it is attached to a terminal, unless -q - is specified. This flag forces progress status even if - the standard error stream is not directed to a terminal. - ---all-progress:: - When --stdout is specified then progress report is - displayed during the object count and compression phases - but inhibited during the write-out phase. The reason is - that in some cases the output stream is directly linked - to another command which may wish to display progress - status of its own as it processes incoming pack data. - This flag is like --progress except that it forces progress - report for the write-out phase as well even if --stdout is - used. - ---all-progress-implied:: - This is used to imply --all-progress whenever progress display - is activated. Unlike --all-progress this flag doesn't actually - force any progress display by itself. - --q:: - This flag makes the command not to report its progress - on the standard error stream. - ---no-reuse-delta:: - When creating a packed archive in a repository that - has existing packs, the command reuses existing deltas. - This sometimes results in a slightly suboptimal pack. - This flag tells the command not to reuse existing deltas - but compute them from scratch. - ---no-reuse-object:: - This flag tells the command not to reuse existing object data at all, - including non deltified object, forcing recompression of everything. - This implies --no-reuse-delta. Useful only in the obscure case where - wholesale enforcement of a different compression level on the - packed data is desired. - ---compression=<n>:: - Specifies compression level for newly-compressed data in the - generated pack. If not specified, pack compression level is - determined first by pack.compression, then by core.compression, - and defaults to -1, the zlib default, if neither is set. - Add --no-reuse-object if you want to force a uniform compression - level on all data no matter the source. - ---sparse:: - Use the "sparse" algorithm to determine which objects to include in - the pack, when combined with the "--revs" option. This algorithm - only walks trees that appear in paths that introduce new objects. - This can have significant performance benefits when computing - a pack to send a small change. However, it is possible that extra - objects are added to the pack-file if the included commits contain - certain types of direct renames. - ---thin:: - Create a "thin" pack by omitting the common objects between a - sender and a receiver in order to reduce network transfer. This - option only makes sense in conjunction with --stdout. -+ -Note: A thin pack violates the packed archive format by omitting -required objects and is thus unusable by Git without making it -self-contained. Use `git index-pack --fix-thin` -(see linkgit:git-index-pack[1]) to restore the self-contained property. - ---shallow:: - Optimize a pack that will be provided to a client with a shallow - repository. This option, combined with --thin, can result in a - smaller pack at the cost of speed. - ---delta-base-offset:: - A packed archive can express the base object of a delta as - either a 20-byte object name or as an offset in the - stream, but ancient versions of Git don't understand the - latter. By default, 'git pack-objects' only uses the - former format for better compatibility. This option - allows the command to use the latter format for - compactness. Depending on the average delta chain - length, this option typically shrinks the resulting - packfile by 3-5 per-cent. -+ -Note: Porcelain commands such as `git gc` (see linkgit:git-gc[1]), -`git repack` (see linkgit:git-repack[1]) pass this option by default -in modern Git when they put objects in your repository into pack files. -So does `git bundle` (see linkgit:git-bundle[1]) when it creates a bundle. - ---threads=<n>:: - Specifies the number of threads to spawn when searching for best - delta matches. This requires that pack-objects be compiled with - pthreads otherwise this option is ignored with a warning. - This is meant to reduce packing time on multiprocessor machines. - The required amount of memory for the delta search window is - however multiplied by the number of threads. - Specifying 0 will cause Git to auto-detect the number of CPU's - and set the number of threads accordingly. - ---index-version=<version>[,<offset>]:: - This is intended to be used by the test suite only. It allows - to force the version for the generated pack index, and to force - 64-bit index entries on objects located above the given offset. - ---keep-true-parents:: - With this option, parents that are hidden by grafts are packed - nevertheless. - ---filter=<filter-spec>:: - Requires `--stdout`. Omits certain objects (usually blobs) from - the resulting packfile. See linkgit:git-rev-list[1] for valid - `<filter-spec>` forms. - ---no-filter:: - Turns off any previous `--filter=` argument. - ---missing=<missing-action>:: - A debug option to help with future "partial clone" development. - This option specifies how missing objects are handled. -+ -The form '--missing=error' requests that pack-objects stop with an error if -a missing object is encountered. This is the default action. -+ -The form '--missing=allow-any' will allow object traversal to continue -if a missing object is encountered. Missing objects will silently be -omitted from the results. -+ -The form '--missing=allow-promisor' is like 'allow-any', but will only -allow object traversal to continue for EXPECTED promisor missing objects. -Unexpected missing object will raise an error. - ---exclude-promisor-objects:: - Omit objects that are known to be in the promisor remote. (This - option has the purpose of operating only on locally created objects, - so that when we repack, we still maintain a distinction between - locally created objects [without .promisor] and objects from the - promisor remote [with .promisor].) This is used with partial clone. - ---keep-unreachable:: - Objects unreachable from the refs in packs named with - --unpacked= option are added to the resulting pack, in - addition to the reachable objects that are not in packs marked - with *.keep files. This implies `--revs`. - ---pack-loose-unreachable:: - Pack unreachable loose objects (and their loose counterparts - removed). This implies `--revs`. - ---unpack-unreachable:: - Keep unreachable objects in loose form. This implies `--revs`. - ---delta-islands:: - Restrict delta matches based on "islands". See DELTA ISLANDS - below. - - -DELTA ISLANDS -------------- - -When possible, `pack-objects` tries to reuse existing on-disk deltas to -avoid having to search for new ones on the fly. This is an important -optimization for serving fetches, because it means the server can avoid -inflating most objects at all and just send the bytes directly from -disk. This optimization can't work when an object is stored as a delta -against a base which the receiver does not have (and which we are not -already sending). In that case the server "breaks" the delta and has to -find a new one, which has a high CPU cost. Therefore it's important for -performance that the set of objects in on-disk delta relationships match -what a client would fetch. - -In a normal repository, this tends to work automatically. The objects -are mostly reachable from the branches and tags, and that's what clients -fetch. Any deltas we find on the server are likely to be between objects -the client has or will have. - -But in some repository setups, you may have several related but separate -groups of ref tips, with clients tending to fetch those groups -independently. For example, imagine that you are hosting several "forks" -of a repository in a single shared object store, and letting clients -view them as separate repositories through `GIT_NAMESPACE` or separate -repos using the alternates mechanism. A naive repack may find that the -optimal delta for an object is against a base that is only found in -another fork. But when a client fetches, they will not have the base -object, and we'll have to find a new delta on the fly. - -A similar situation may exist if you have many refs outside of -`refs/heads/` and `refs/tags/` that point to related objects (e.g., -`refs/pull` or `refs/changes` used by some hosting providers). By -default, clients fetch only heads and tags, and deltas against objects -found only in those other groups cannot be sent as-is. - -Delta islands solve this problem by allowing you to group your refs into -distinct "islands". Pack-objects computes which objects are reachable -from which islands, and refuses to make a delta from an object `A` -against a base which is not present in all of `A`'s islands. This -results in slightly larger packs (because we miss some delta -opportunities), but guarantees that a fetch of one island will not have -to recompute deltas on the fly due to crossing island boundaries. - -When repacking with delta islands the delta window tends to get -clogged with candidates that are forbidden by the config. Repacking -with a big --window helps (and doesn't take as long as it otherwise -might because we can reject some object pairs based on islands before -doing any computation on the content). - -Islands are configured via the `pack.island` option, which can be -specified multiple times. Each value is a left-anchored regular -expressions matching refnames. For example: - -------------------------------------------- -[pack] -island = refs/heads/ -island = refs/tags/ -------------------------------------------- - -puts heads and tags into an island (whose name is the empty string; see -below for more on naming). Any refs which do not match those regular -expressions (e.g., `refs/pull/123`) is not in any island. Any object -which is reachable only from `refs/pull/` (but not heads or tags) is -therefore not a candidate to be used as a base for `refs/heads/`. - -Refs are grouped into islands based on their "names", and two regexes -that produce the same name are considered to be in the same -island. The names are computed from the regexes by concatenating any -capture groups from the regex, with a '-' dash in between. (And if -there are no capture groups, then the name is the empty string, as in -the above example.) This allows you to create arbitrary numbers of -islands. Only up to 14 such capture groups are supported though. - -For example, imagine you store the refs for each fork in -`refs/virtual/ID`, where `ID` is a numeric identifier. You might then -configure: - -------------------------------------------- -[pack] -island = refs/virtual/([0-9]+)/heads/ -island = refs/virtual/([0-9]+)/tags/ -island = refs/virtual/([0-9]+)/(pull)/ -------------------------------------------- - -That puts the heads and tags for each fork in their own island (named -"1234" or similar), and the pull refs for each go into their own -"1234-pull". - -Note that we pick a single island for each regex to go into, using "last -one wins" ordering (which allows repo-specific config to take precedence -over user-wide config, and so forth). - -SEE ALSO --------- -linkgit:git-rev-list[1] -linkgit:git-repack[1] -linkgit:git-prune-packed[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-pack-redundant.txt b/third_party/git/Documentation/git-pack-redundant.txt deleted file mode 100644 index f2869da572..0000000000 --- a/third_party/git/Documentation/git-pack-redundant.txt +++ /dev/null @@ -1,50 +0,0 @@ -git-pack-redundant(1) -===================== - -NAME ----- -git-pack-redundant - Find redundant pack files - - -SYNOPSIS --------- -[verse] -'git pack-redundant' [ --verbose ] [ --alt-odb ] < --all | .pack filename ... > - -DESCRIPTION ------------ -This program computes which packs in your repository -are redundant. The output is suitable for piping to -`xargs rm` if you are in the root of the repository. - -'git pack-redundant' accepts a list of objects on standard input. Any objects -given will be ignored when checking which packs are required. This makes the -following command useful when wanting to remove packs which contain unreachable -objects. - -git fsck --full --unreachable | cut -d ' ' -f3 | \ -git pack-redundant --all | xargs rm - -OPTIONS -------- - - ---all:: - Processes all packs. Any filenames on the command line are ignored. - ---alt-odb:: - Don't require objects present in packs from alternate object - directories to be present in local packs. - ---verbose:: - Outputs some statistics to stderr. Has a small performance penalty. - -SEE ALSO --------- -linkgit:git-pack-objects[1] -linkgit:git-repack[1] -linkgit:git-prune-packed[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-pack-refs.txt b/third_party/git/Documentation/git-pack-refs.txt deleted file mode 100644 index 154081f2de..0000000000 --- a/third_party/git/Documentation/git-pack-refs.txt +++ /dev/null @@ -1,73 +0,0 @@ -git-pack-refs(1) -================ - -NAME ----- -git-pack-refs - Pack heads and tags for efficient repository access - -SYNOPSIS --------- -[verse] -'git pack-refs' [--all] [--no-prune] - -DESCRIPTION ------------ - -Traditionally, tips of branches and tags (collectively known as -'refs') were stored one file per ref in a (sub)directory -under `$GIT_DIR/refs` -directory. While many branch tips tend to be updated often, -most tags and some branch tips are never updated. When a -repository has hundreds or thousands of tags, this -one-file-per-ref format both wastes storage and hurts -performance. - -This command is used to solve the storage and performance -problem by storing the refs in a single file, -`$GIT_DIR/packed-refs`. When a ref is missing from the -traditional `$GIT_DIR/refs` directory hierarchy, it is looked -up in this -file and used if found. - -Subsequent updates to branches always create new files under -`$GIT_DIR/refs` directory hierarchy. - -A recommended practice to deal with a repository with too many -refs is to pack its refs with `--all` once, and -occasionally run `git pack-refs`. Tags are by -definition stationary and are not expected to change. Branch -heads will be packed with the initial `pack-refs --all`, but -only the currently active branch heads will become unpacked, -and the next `pack-refs` (without `--all`) will leave them -unpacked. - - -OPTIONS -------- - ---all:: - -The command by default packs all tags and refs that are already -packed, and leaves other refs -alone. This is because branches are expected to be actively -developed and packing their tips does not help performance. -This option causes branch tips to be packed as well. Useful for -a repository with many branches of historical interests. - ---no-prune:: - -The command usually removes loose refs under `$GIT_DIR/refs` -hierarchy after packing them. This option tells it not to. - - -BUGS ----- - -Older documentation written before the packed-refs mechanism was -introduced may still say things like ".git/refs/heads/<branch> file -exists" when it means "branch <branch> exists". - - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-parse-remote.txt b/third_party/git/Documentation/git-parse-remote.txt deleted file mode 100644 index a45ea1ece8..0000000000 --- a/third_party/git/Documentation/git-parse-remote.txt +++ /dev/null @@ -1,23 +0,0 @@ -git-parse-remote(1) -=================== - -NAME ----- -git-parse-remote - Routines to help parsing remote repository access parameters - - -SYNOPSIS --------- -[verse] -'. "$(git --exec-path)/git-parse-remote"' - -DESCRIPTION ------------ -This script is included in various scripts to supply -routines to parse files under $GIT_DIR/remotes/ and -$GIT_DIR/branches/ and configuration variables that are related -to fetching, pulling and pushing. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-patch-id.txt b/third_party/git/Documentation/git-patch-id.txt deleted file mode 100644 index 442caff8a9..0000000000 --- a/third_party/git/Documentation/git-patch-id.txt +++ /dev/null @@ -1,61 +0,0 @@ -git-patch-id(1) -=============== - -NAME ----- -git-patch-id - Compute unique ID for a patch - -SYNOPSIS --------- -[verse] -'git patch-id' [--stable | --unstable] - -DESCRIPTION ------------ -Read a patch from the standard input and compute the patch ID for it. - -A "patch ID" is nothing but a sum of SHA-1 of the file diffs associated with a -patch, with whitespace and line numbers ignored. As such, it's "reasonably -stable", but at the same time also reasonably unique, i.e., two patches that -have the same "patch ID" are almost guaranteed to be the same thing. - -IOW, you can use this thing to look for likely duplicate commits. - -When dealing with 'git diff-tree' output, it takes advantage of -the fact that the patch is prefixed with the object name of the -commit, and outputs two 40-byte hexadecimal strings. The first -string is the patch ID, and the second string is the commit ID. -This can be used to make a mapping from patch ID to commit ID. - -OPTIONS -------- - ---stable:: - Use a "stable" sum of hashes as the patch ID. With this option: - - Reordering file diffs that make up a patch does not affect the ID. - In particular, two patches produced by comparing the same two trees - with two different settings for "-O<orderfile>" result in the same - patch ID signature, thereby allowing the computed result to be used - as a key to index some meta-information about the change between - the two trees; - - - Result is different from the value produced by git 1.9 and older - or produced when an "unstable" hash (see --unstable below) is - configured - even when used on a diff output taken without any use - of "-O<orderfile>", thereby making existing databases storing such - "unstable" or historical patch-ids unusable. - - This is the default if patchid.stable is set to true. - ---unstable:: - Use an "unstable" hash as the patch ID. With this option, - the result produced is compatible with the patch-id value produced - by git 1.9 and older. Users with pre-existing databases storing - patch-ids produced by git 1.9 and older (who do not deal with reordered - patches) may want to use this option. - - This is the default. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-prune-packed.txt b/third_party/git/Documentation/git-prune-packed.txt deleted file mode 100644 index 9fed59a317..0000000000 --- a/third_party/git/Documentation/git-prune-packed.txt +++ /dev/null @@ -1,47 +0,0 @@ -git-prune-packed(1) -=================== - -NAME ----- -git-prune-packed - Remove extra objects that are already in pack files - - -SYNOPSIS --------- -[verse] -'git prune-packed' [-n|--dry-run] [-q|--quiet] - - -DESCRIPTION ------------ -This program searches the `$GIT_OBJECT_DIRECTORY` for all objects that currently -exist in a pack file as well as the independent object directories. - -All such extra objects are removed. - -A pack is a collection of objects, individually compressed, with delta -compression applied, stored in a single file, with an associated index file. - -Packs are used to reduce the load on mirror systems, backup engines, -disk storage, etc. - - -OPTIONS -------- --n:: ---dry-run:: - Don't actually remove any objects, only show those that would have been - removed. - --q:: ---quiet:: - Squelch the progress indicator. - -SEE ALSO --------- -linkgit:git-pack-objects[1] -linkgit:git-repack[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-prune.txt b/third_party/git/Documentation/git-prune.txt deleted file mode 100644 index 03552dd86f..0000000000 --- a/third_party/git/Documentation/git-prune.txt +++ /dev/null @@ -1,89 +0,0 @@ -git-prune(1) -============ - -NAME ----- -git-prune - Prune all unreachable objects from the object database - - -SYNOPSIS --------- -[verse] -'git prune' [-n] [-v] [--progress] [--expire <time>] [--] [<head>...] - -DESCRIPTION ------------ - -NOTE: In most cases, users should run 'git gc', which calls -'git prune'. See the section "NOTES", below. - -This runs 'git fsck --unreachable' using all the refs -available in `refs/`, optionally with additional set of -objects specified on the command line, and prunes all unpacked -objects unreachable from any of these head objects from the object database. -In addition, it -prunes the unpacked objects that are also found in packs by -running 'git prune-packed'. -It also removes entries from .git/shallow that are not reachable by -any ref. - -Note that unreachable, packed objects will remain. If this is -not desired, see linkgit:git-repack[1]. - -OPTIONS -------- - --n:: ---dry-run:: - Do not remove anything; just report what it would - remove. - --v:: ---verbose:: - Report all removed objects. - ---progress:: - Show progress. - ---expire <time>:: - Only expire loose objects older than <time>. - -\--:: - Do not interpret any more arguments as options. - -<head>...:: - In addition to objects - reachable from any of our references, keep objects - reachable from listed <head>s. - -EXAMPLES --------- - -To prune objects not used by your repository or another that -borrows from your repository via its -`.git/objects/info/alternates`: - ------------- -$ git prune $(cd ../another && git rev-parse --all) ------------- - -NOTES ------ - -In most cases, users will not need to call 'git prune' directly, but -should instead call 'git gc', which handles pruning along with -many other housekeeping tasks. - -For a description of which objects are considered for pruning, see -'git fsck''s --unreachable option. - -SEE ALSO --------- - -linkgit:git-fsck[1], -linkgit:git-gc[1], -linkgit:git-reflog[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-pull.txt b/third_party/git/Documentation/git-pull.txt deleted file mode 100644 index dfb901f8b8..0000000000 --- a/third_party/git/Documentation/git-pull.txt +++ /dev/null @@ -1,263 +0,0 @@ -git-pull(1) -=========== - -NAME ----- -git-pull - Fetch from and integrate with another repository or a local branch - - -SYNOPSIS --------- -[verse] -'git pull' [<options>] [<repository> [<refspec>...]] - - -DESCRIPTION ------------ - -Incorporates changes from a remote repository into the current -branch. In its default mode, `git pull` is shorthand for -`git fetch` followed by `git merge FETCH_HEAD`. - -More precisely, 'git pull' runs 'git fetch' with the given -parameters and calls 'git merge' to merge the retrieved branch -heads into the current branch. -With `--rebase`, it runs 'git rebase' instead of 'git merge'. - -<repository> should be the name of a remote repository as -passed to linkgit:git-fetch[1]. <refspec> can name an -arbitrary remote ref (for example, the name of a tag) or even -a collection of refs with corresponding remote-tracking branches -(e.g., refs/heads/{asterisk}:refs/remotes/origin/{asterisk}), -but usually it is the name of a branch in the remote repository. - -Default values for <repository> and <branch> are read from the -"remote" and "merge" configuration for the current branch -as set by linkgit:git-branch[1] `--track`. - -Assume the following history exists and the current branch is -"`master`": - ------------- - A---B---C master on origin - / - D---E---F---G master - ^ - origin/master in your repository ------------- - -Then "`git pull`" will fetch and replay the changes from the remote -`master` branch since it diverged from the local `master` (i.e., `E`) -until its current commit (`C`) on top of `master` and record the -result in a new commit along with the names of the two parent commits -and a log message from the user describing the changes. - ------------- - A---B---C origin/master - / \ - D---E---F---G---H master ------------- - -See linkgit:git-merge[1] for details, including how conflicts -are presented and handled. - -In Git 1.7.0 or later, to cancel a conflicting merge, use -`git reset --merge`. *Warning*: In older versions of Git, running 'git pull' -with uncommitted changes is discouraged: while possible, it leaves you -in a state that may be hard to back out of in the case of a conflict. - -If any of the remote changes overlap with local uncommitted changes, -the merge will be automatically canceled and the work tree untouched. -It is generally best to get any local changes in working order before -pulling or stash them away with linkgit:git-stash[1]. - -OPTIONS -------- - --q:: ---quiet:: - This is passed to both underlying git-fetch to squelch reporting of - during transfer, and underlying git-merge to squelch output during - merging. - --v:: ---verbose:: - Pass --verbose to git-fetch and git-merge. - ---[no-]recurse-submodules[=yes|on-demand|no]:: - This option controls if new commits of all populated submodules should - be fetched and updated, too (see linkgit:git-config[1] and - linkgit:gitmodules[5]). -+ -If the checkout is done via rebase, local submodule commits are rebased as well. -+ -If the update is done via merge, the submodule conflicts are resolved and checked out. - -Options related to merging -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -:git-pull: 1 - -include::merge-options.txt[] - --r:: ---rebase[=false|true|merges|preserve|interactive]:: - When true, rebase the current branch on top of the upstream - branch after fetching. If there is a remote-tracking branch - corresponding to the upstream branch and the upstream branch - was rebased since last fetched, the rebase uses that information - to avoid rebasing non-local changes. -+ -When set to `merges`, rebase using `git rebase --rebase-merges` so that -the local merge commits are included in the rebase (see -linkgit:git-rebase[1] for details). -+ -When set to `preserve` (deprecated in favor of `merges`), rebase with the -`--preserve-merges` option passed to `git rebase` so that locally created -merge commits will not be flattened. -+ -When false, merge the current branch into the upstream branch. -+ -When `interactive`, enable the interactive mode of rebase. -+ -See `pull.rebase`, `branch.<name>.rebase` and `branch.autoSetupRebase` in -linkgit:git-config[1] if you want to make `git pull` always use -`--rebase` instead of merging. -+ -[NOTE] -This is a potentially _dangerous_ mode of operation. -It rewrites history, which does not bode well when you -published that history already. Do *not* use this option -unless you have read linkgit:git-rebase[1] carefully. - ---no-rebase:: - Override earlier --rebase. - ---autostash:: ---no-autostash:: - Before starting rebase, stash local modifications away (see - linkgit:git-stash[1]) if needed, and apply the stash entry when - done. `--no-autostash` is useful to override the `rebase.autoStash` - configuration variable (see linkgit:git-config[1]). -+ -This option is only valid when "--rebase" is used. - -Options related to fetching -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -include::fetch-options.txt[] - -include::pull-fetch-param.txt[] - -include::urls-remotes.txt[] - -include::merge-strategies.txt[] - -DEFAULT BEHAVIOUR ------------------ - -Often people use `git pull` without giving any parameter. -Traditionally, this has been equivalent to saying `git pull -origin`. However, when configuration `branch.<name>.remote` is -present while on branch `<name>`, that value is used instead of -`origin`. - -In order to determine what URL to use to fetch from, the value -of the configuration `remote.<origin>.url` is consulted -and if there is not any such variable, the value on the `URL:` line -in `$GIT_DIR/remotes/<origin>` is used. - -In order to determine what remote branches to fetch (and -optionally store in the remote-tracking branches) when the command is -run without any refspec parameters on the command line, values -of the configuration variable `remote.<origin>.fetch` are -consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>` -is consulted and its `Pull:` lines are used. -In addition to the refspec formats described in the OPTIONS -section, you can have a globbing refspec that looks like this: - ------------- -refs/heads/*:refs/remotes/origin/* ------------- - -A globbing refspec must have a non-empty RHS (i.e. must store -what were fetched in remote-tracking branches), and its LHS and RHS -must end with `/*`. The above specifies that all remote -branches are tracked using remote-tracking branches in -`refs/remotes/origin/` hierarchy under the same name. - -The rule to determine which remote branch to merge after -fetching is a bit involved, in order not to break backward -compatibility. - -If explicit refspecs were given on the command -line of `git pull`, they are all merged. - -When no refspec was given on the command line, then `git pull` -uses the refspec from the configuration or -`$GIT_DIR/remotes/<origin>`. In such cases, the following -rules apply: - -. If `branch.<name>.merge` configuration for the current - branch `<name>` exists, that is the name of the branch at the - remote site that is merged. - -. If the refspec is a globbing one, nothing is merged. - -. Otherwise the remote branch of the first refspec is merged. - - -EXAMPLES --------- - -* Update the remote-tracking branches for the repository - you cloned from, then merge one of them into your - current branch: -+ ------------------------------------------------- -$ git pull -$ git pull origin ------------------------------------------------- -+ -Normally the branch merged in is the HEAD of the remote repository, -but the choice is determined by the branch.<name>.remote and -branch.<name>.merge options; see linkgit:git-config[1] for details. - -* Merge into the current branch the remote branch `next`: -+ ------------------------------------------------- -$ git pull origin next ------------------------------------------------- -+ -This leaves a copy of `next` temporarily in FETCH_HEAD, but -does not update any remote-tracking branches. Using remote-tracking -branches, the same can be done by invoking fetch and merge: -+ ------------------------------------------------- -$ git fetch origin -$ git merge origin/next ------------------------------------------------- - - -If you tried a pull which resulted in complex conflicts and -would want to start over, you can recover with 'git reset'. - - -include::transfer-data-leaks.txt[] - -BUGS ----- -Using --recurse-submodules can only fetch new commits in already checked -out submodules right now. When e.g. upstream added a new submodule in the -just fetched commits of the superproject the submodule itself cannot be -fetched, making it impossible to check out that submodule later without -having to do a fetch again. This is expected to be fixed in a future Git -version. - -SEE ALSO --------- -linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-config[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-push.txt b/third_party/git/Documentation/git-push.txt deleted file mode 100644 index 3b8053447e..0000000000 --- a/third_party/git/Documentation/git-push.txt +++ /dev/null @@ -1,673 +0,0 @@ -git-push(1) -=========== - -NAME ----- -git-push - Update remote refs along with associated objects - - -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] [-o <string> | --push-option=<string>] - [--[no-]signed|--signed=(true|false|if-asked)] - [--force-with-lease[=<refname>[:<expect>]]] - [--no-verify] [<repository> [<refspec>...]] - -DESCRIPTION ------------ - -Updates remote refs using local refs, while sending objects -necessary to complete the given refs. - -You can make interesting things happen to a repository -every time you push into it, by setting up 'hooks' there. See -documentation for linkgit:git-receive-pack[1]. - -When the command line does not specify where to push with the -`<repository>` argument, `branch.*.remote` configuration for the -current branch is consulted to determine where to push. If the -configuration is missing, it defaults to 'origin'. - -When the command line does not specify what to push with `<refspec>...` -arguments or `--all`, `--mirror`, `--tags` options, the command finds -the default `<refspec>` by consulting `remote.*.push` configuration, -and if it is not found, honors `push.default` configuration to decide -what to push (See linkgit:git-config[1] for the meaning of `push.default`). - -When neither the command-line nor the configuration specify what to -push, the default behavior is used, which corresponds to the `simple` -value for `push.default`: the current branch is pushed to the -corresponding upstream branch, but as a safety measure, the push is -aborted if the upstream branch does not have the same name as the -local one. - - -OPTIONS[[OPTIONS]] ------------------- -<repository>:: - The "remote" repository that is destination of a push - operation. This parameter can be either a URL - (see the section <<URLS,GIT URLS>> below) or the name - of a remote (see the section <<REMOTES,REMOTES>> below). - -<refspec>...:: - Specify what destination ref to update with what source object. - The format of a <refspec> parameter is an optional plus - `+`, followed by the source object <src>, followed - by a colon `:`, followed by the destination ref <dst>. -+ -The <src> is often the name of the branch you would want to push, but -it can be any arbitrary "SHA-1 expression", such as `master~4` or -`HEAD` (see linkgit:gitrevisions[7]). -+ -The <dst> tells which ref on the remote side is updated with this -push. Arbitrary expressions cannot be used here, an actual ref must -be named. -If `git push [<repository>]` without any `<refspec>` argument is set to -update some ref at the destination with `<src>` with -`remote.<repository>.push` configuration variable, `:<dst>` part can -be omitted--such a push will update a ref that `<src>` normally updates -without any `<refspec>` on the command line. Otherwise, missing -`:<dst>` means to update the same ref as the `<src>`. -+ -If <dst> doesn't start with `refs/` (e.g. `refs/heads/master`) we will -try to infer where in `refs/*` on the destination <repository> it -belongs based on the type of <src> being pushed and whether <dst> -is ambiguous. -+ --- -* If <dst> unambiguously refers to a ref on the <repository> remote, - then push to that ref. - -* If <src> resolves to a ref starting with refs/heads/ or refs/tags/, - then prepend that to <dst>. - -* Other ambiguity resolutions might be added in the future, but for - now any other cases will error out with an error indicating what we - tried, and depending on the `advice.pushUnqualifiedRefname` - configuration (see linkgit:git-config[1]) suggest what refs/ - namespace you may have wanted to push to. - --- -+ -The object referenced by <src> is used to update the <dst> reference -on the remote side. Whether this is allowed depends on where in -`refs/*` the <dst> reference lives as described in detail below, in -those sections "update" means any modifications except deletes, which -as noted after the next few sections are treated differently. -+ -The `refs/heads/*` namespace will only accept commit objects, and -updates only if they can be fast-forwarded. -+ -The `refs/tags/*` namespace will accept any kind of object (as -commits, trees and blobs can be tagged), and any updates to them will -be rejected. -+ -It's possible to push any type of object to any namespace outside of -`refs/{tags,heads}/*`. In the case of tags and commits, these will be -treated as if they were the commits inside `refs/heads/*` for the -purposes of whether the update is allowed. -+ -I.e. a fast-forward of commits and tags outside `refs/{tags,heads}/*` -is allowed, even in cases where what's being fast-forwarded is not a -commit, but a tag object which happens to point to a new commit which -is a fast-forward of the commit the last tag (or commit) it's -replacing. Replacing a tag with an entirely different tag is also -allowed, if it points to the same commit, as well as pushing a peeled -tag, i.e. pushing the commit that existing tag object points to, or a -new tag object which an existing commit points to. -+ -Tree and blob objects outside of `refs/{tags,heads}/*` will be treated -the same way as if they were inside `refs/tags/*`, any update of them -will be rejected. -+ -All of the rules described above about what's not allowed as an update -can be overridden by adding an the optional leading `+` to a refspec -(or using `--force` command line option). The only exception to this -is that no amount of forcing will make the `refs/heads/*` namespace -accept a non-commit object. Hooks and configuration can also override -or amend these rules, see e.g. `receive.denyNonFastForwards` in -linkgit:git-config[1] and `pre-receive` and `update` in -linkgit:githooks[5]. -+ -Pushing an empty <src> allows you to delete the <dst> ref from the -remote repository. Deletions are always accepted without a leading `+` -in the refspec (or `--force`), except when forbidden by configuration -or hooks. See `receive.denyDeletes` in linkgit:git-config[1] and -`pre-receive` and `update` in linkgit:githooks[5]. -+ -The special refspec `:` (or `+:` to allow non-fast-forward updates) -directs Git to push "matching" branches: for every branch that exists on -the local side, the remote side is updated if a branch of the same name -already exists on the remote side. -+ -`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`. - ---all:: - Push all branches (i.e. refs under `refs/heads/`); cannot be - used with other <refspec>. - ---prune:: - Remove remote branches that don't have a local counterpart. For example - a remote branch `tmp` will be removed if a local branch with the same - name doesn't exist any more. This also respects refspecs, e.g. - `git push --prune remote refs/heads/*:refs/tmp/*` would - make sure that remote `refs/tmp/foo` will be removed if `refs/heads/foo` - doesn't exist. - ---mirror:: - Instead of naming each ref to push, specifies that all - refs under `refs/` (which includes but is not - limited to `refs/heads/`, `refs/remotes/`, and `refs/tags/`) - be mirrored to the remote repository. Newly created local - refs will be pushed to the remote end, locally updated refs - will be force updated on the remote end, and deleted refs - will be removed from the remote end. This is the default - if the configuration option `remote.<remote>.mirror` is - set. - --n:: ---dry-run:: - Do everything except actually send the updates. - ---porcelain:: - Produce machine-readable output. The output status line for each ref - will be tab-separated and sent to stdout instead of stderr. The full - symbolic names of the refs will be given. - --d:: ---delete:: - All listed refs are deleted from the remote repository. This is - the same as prefixing all refs with a colon. - ---tags:: - All refs under `refs/tags` are pushed, in - addition to refspecs explicitly listed on the command - line. - ---follow-tags:: - Push all the refs that would be pushed without this option, - and also push annotated tags in `refs/tags` that are missing - from the remote but are pointing at commit-ish that are - reachable from the refs being pushed. This can also be specified - with configuration variable `push.followTags`. For more - information, see `push.followTags` in linkgit:git-config[1]. - ---[no-]signed:: ---signed=(true|false|if-asked):: - GPG-sign the push request to update refs on the receiving - side, to allow it to be checked by the hooks and/or be - logged. If `false` or `--no-signed`, no signing will be - attempted. If `true` or `--signed`, the push will fail if the - server does not support signed pushes. If set to `if-asked`, - sign if and only if the server supports signed pushes. The push - will also fail if the actual call to `gpg --sign` fails. See - linkgit:git-receive-pack[1] for the details on the receiving end. - ---[no-]atomic:: - Use an atomic transaction on the remote side if available. - 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 <option>:: ---push-option=<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. - When multiple `--push-option=<option>` are given, they are - all sent to the other side in the order listed on the - command line. - When no `--push-option=<option>` is given from the command - line, the values of configuration variable `push.pushOption` - are used instead. - ---receive-pack=<git-receive-pack>:: ---exec=<git-receive-pack>:: - Path to the 'git-receive-pack' program on the remote - end. Sometimes useful when pushing to a remote - repository over ssh, and you do not have the program in - a directory on the default $PATH. - ---[no-]force-with-lease:: ---force-with-lease=<refname>:: ---force-with-lease=<refname>:<expect>:: - Usually, "git push" refuses to update a remote ref that is - not an ancestor of the local ref used to overwrite it. -+ -This option overrides this restriction if the current value of the -remote ref is the expected value. "git push" fails otherwise. -+ -Imagine that you have to rebase what you have already published. -You will have to bypass the "must fast-forward" rule in order to -replace the history you originally published with the rebased history. -If somebody else built on top of your original history while you are -rebasing, the tip of the branch at the remote may advance with her -commit, and blindly pushing with `--force` will lose her work. -+ -This option allows you to say that you expect the history you are -updating is what you rebased and want to replace. If the remote ref -still points at the commit you specified, you can be sure that no -other people did anything to the ref. It is like taking a "lease" on -the ref without explicitly locking it, and the remote ref is updated -only if the "lease" is still valid. -+ -`--force-with-lease` alone, without specifying the details, will protect -all remote refs that are going to be updated by requiring their -current value to be the same as the remote-tracking branch we have -for them. -+ -`--force-with-lease=<refname>`, without specifying the expected value, will -protect the named ref (alone), if it is going to be updated, by -requiring its current value to be the same as the remote-tracking -branch we have for it. -+ -`--force-with-lease=<refname>:<expect>` will protect the named ref (alone), -if it is going to be updated, by requiring its current value to be -the same as the specified value `<expect>` (which is allowed to be -different from the remote-tracking branch we have for the refname, -or we do not even have to have such a remote-tracking branch when -this form is used). If `<expect>` is the empty string, then the named ref -must not already exist. -+ -Note that all forms other than `--force-with-lease=<refname>:<expect>` -that specifies the expected current value of the ref explicitly are -still experimental and their semantics may change as we gain experience -with this feature. -+ -"--no-force-with-lease" will cancel all the previous --force-with-lease on the -command line. -+ -A general note on safety: supplying this option without an expected -value, i.e. as `--force-with-lease` or `--force-with-lease=<refname>` -interacts very badly with anything that implicitly runs `git fetch` on -the remote to be pushed to in the background, e.g. `git fetch origin` -on your repository in a cronjob. -+ -The protection it offers over `--force` is ensuring that subsequent -changes your work wasn't based on aren't clobbered, but this is -trivially defeated if some background process is updating refs in the -background. We don't have anything except the remote tracking info to -go by as a heuristic for refs you're expected to have seen & are -willing to clobber. -+ -If your editor or some other system is running `git fetch` in the -background for you a way to mitigate this is to simply set up another -remote: -+ - git remote add origin-push $(git config remote.origin.url) - git fetch origin-push -+ -Now when the background process runs `git fetch origin` the references -on `origin-push` won't be updated, and thus commands like: -+ - git push --force-with-lease origin-push -+ -Will fail unless you manually run `git fetch origin-push`. This method -is of course entirely defeated by something that runs `git fetch ---all`, in that case you'd need to either disable it or do something -more tedious like: -+ - git fetch # update 'master' from remote - git tag base master # mark our base point - git rebase -i master # rewrite some commits - git push --force-with-lease=master:base master:master -+ -I.e. create a `base` tag for versions of the upstream code that you've -seen and are willing to overwrite, then rewrite history, and finally -force push changes to `master` if the remote version is still at -`base`, regardless of what your local `remotes/origin/master` has been -updated to in the background. - --f:: ---force:: - Usually, the command refuses to update a remote ref that is - not an ancestor of the local ref used to overwrite it. - Also, when `--force-with-lease` option is used, the command refuses - to update a remote ref whose current value does not match - what is expected. -+ -This flag disables these checks, and can cause the remote repository -to lose commits; use it with care. -+ -Note that `--force` applies to all the refs that are pushed, hence -using it with `push.default` set to `matching` or with multiple push -destinations configured with `remote.*.push` may overwrite refs -other than the current branch (including local refs that are -strictly behind their remote counterpart). To force a push to only -one branch, use a `+` in front of the refspec to push (e.g `git push -origin +master` to force a push to the `master` branch). See the -`<refspec>...` section above for details. - ---repo=<repository>:: - This option is equivalent to the <repository> argument. If both - are specified, the command-line argument takes precedence. - --u:: ---set-upstream:: - For every branch that is up to date or successfully pushed, add - upstream (tracking) reference, used by argument-less - linkgit:git-pull[1] and other commands. For more information, - see `branch.<name>.merge` in linkgit:git-config[1]. - ---[no-]thin:: - These options are passed to linkgit:git-send-pack[1]. A thin transfer - significantly reduces the amount of sent data when the sender and - receiver share many of the same objects in common. The default is - `--thin`. - --q:: ---quiet:: - Suppress all output, including the listing of updated refs, - unless an error occurs. Progress is not reported to the standard - error stream. - --v:: ---verbose:: - Run verbosely. - ---progress:: - Progress status is reported on the standard error stream - by default when it is attached to a terminal, unless -q - is specified. This flag forces progress status even if the - standard error stream is not directed to a terminal. - ---no-recurse-submodules:: ---recurse-submodules=check|on-demand|only|no:: - May be used to make sure all submodule commits used by the - revisions to be pushed are available on a remote-tracking branch. - If 'check' is used Git will verify that all submodule commits that - changed in the revisions to be pushed are available on at least one - remote of the submodule. If any commits are missing the push will - be aborted and exit with non-zero status. If 'on-demand' is used - all submodules that changed in the revisions to be pushed will be - pushed. If on-demand was not able to push all necessary revisions it will - also be aborted and exit with non-zero status. If 'only' is used all - submodules will be recursively pushed while the superproject is left - unpushed. A value of 'no' or using `--no-recurse-submodules` can be used - to override the push.recurseSubmodules configuration variable when no - submodule recursion is required. - ---[no-]verify:: - Toggle the pre-push hook (see linkgit:githooks[5]). The - default is --verify, giving the hook a chance to prevent the - push. With --no-verify, the hook is bypassed completely. - --4:: ---ipv4:: - Use IPv4 addresses only, ignoring IPv6 addresses. - --6:: ---ipv6:: - Use IPv6 addresses only, ignoring IPv4 addresses. - -include::urls-remotes.txt[] - -OUTPUT ------- - -The output of "git push" depends on the transport method used; this -section describes the output when pushing over the Git protocol (either -locally or via ssh). - -The status of the push 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>) -------------------------------- - -If --porcelain is used, then each line of the output is of the form: - -------------------------------- - <flag> \t <from>:<to> \t <summary> (<reason>) -------------------------------- - -The status of up-to-date refs is shown only if --porcelain or --verbose -option is used. - -flag:: - A single character indicating the status of the ref: -(space);; for a successfully pushed fast-forward; -`+`;; for a successful forced update; -`-`;; for a successfully deleted ref; -`*`;; for a successfully pushed new ref; -`!`;; for a ref that was rejected or failed to push; and -`=`;; for a ref that was up to date and did not need pushing. - -summary:: - For a successfully pushed 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). -+ -For a failed update, more details are given: -+ --- -rejected:: - Git did not try to send the ref at all, typically because it - is not a fast-forward and you did not force the update. - -remote rejected:: - The remote end refused the update. Usually caused by a hook - on the remote side, or because the remote repository has one - of the following safety options in effect: - `receive.denyCurrentBranch` (for pushes to the checked out - branch), `receive.denyNonFastForwards` (for forced - non-fast-forward updates), `receive.denyDeletes` or - `receive.denyDeleteCurrent`. See linkgit:git-config[1]. - -remote failure:: - The remote end did not report the successful update of the ref, - perhaps because of a temporary error on the remote side, a - break in the network connection, or other transient error. --- - -from:: - The name of the local ref being pushed, minus its - `refs/<type>/` prefix. In the case of deletion, the - name of the local ref is omitted. - -to:: - The name of the remote ref being updated, minus its - `refs/<type>/` prefix. - -reason:: - A human-readable explanation. In the case of successfully pushed - refs, no explanation is needed. For a failed ref, the reason for - failure is described. - -NOTE ABOUT FAST-FORWARDS ------------------------- - -When an update changes a branch (or more in general, a ref) that used to -point at commit A to point at another commit B, it is called a -fast-forward update if and only if B is a descendant of A. - -In a fast-forward update from A to B, the set of commits that the original -commit A built on top of is a subset of the commits the new commit B -builds on top of. Hence, it does not lose any history. - -In contrast, a non-fast-forward update will lose history. For example, -suppose you and somebody else started at the same commit X, and you built -a history leading to commit B while the other person built a history -leading to commit A. The history looks like this: - ----------------- - - B - / - ---X---A - ----------------- - -Further suppose that the other person already pushed changes leading to A -back to the original repository from which you two obtained the original -commit X. - -The push done by the other person updated the branch that used to point at -commit X to point at commit A. It is a fast-forward. - -But if you try to push, you will attempt to update the branch (that -now points at A) with commit B. This does _not_ fast-forward. If you did -so, the changes introduced by commit A will be lost, because everybody -will now start building on top of B. - -The command by default does not allow an update that is not a fast-forward -to prevent such loss of history. - -If you do not want to lose your work (history from X to B) or the work by -the other person (history from X to A), you would need to first fetch the -history from the repository, create a history that contains changes done -by both parties, and push the result back. - -You can perform "git pull", resolve potential conflicts, and "git push" -the result. A "git pull" will create a merge commit C between commits A -and B. - ----------------- - - B---C - / / - ---X---A - ----------------- - -Updating A with the resulting merge commit will fast-forward and your -push will be accepted. - -Alternatively, you can rebase your change between X and B on top of A, -with "git pull --rebase", and push the result back. The rebase will -create a new commit D that builds the change between X and B on top of -A. - ----------------- - - B D - / / - ---X---A - ----------------- - -Again, updating A with this commit will fast-forward and your push will be -accepted. - -There is another common situation where you may encounter non-fast-forward -rejection when you try to push, and it is possible even when you are -pushing into a repository nobody else pushes into. After you push commit -A yourself (in the first picture in this section), replace it with "git -commit --amend" to produce commit B, and you try to push it out, because -forgot that you have pushed A out already. In such a case, and only if -you are certain that nobody in the meantime fetched your earlier commit A -(and started building on top of it), you can run "git push --force" to -overwrite it. In other words, "git push --force" is a method reserved for -a case where you do mean to lose history. - - -EXAMPLES --------- - -`git push`:: - Works like `git push <remote>`, where <remote> is the - current branch's remote (or `origin`, if no remote is - configured for the current branch). - -`git push origin`:: - Without additional configuration, pushes the current branch to - the configured upstream (`remote.origin.merge` configuration - variable) if it has the same name as the current branch, and - errors out without pushing otherwise. -+ -The default behavior of this command when no <refspec> is given can be -configured by setting the `push` option of the remote, or the `push.default` -configuration variable. -+ -For example, to default to pushing only the current branch to `origin` -use `git config remote.origin.push HEAD`. Any valid <refspec> (like -the ones in the examples below) can be configured as the default for -`git push origin`. - -`git push origin :`:: - Push "matching" branches to `origin`. See - <refspec> in the <<OPTIONS,OPTIONS>> section above for a - description of "matching" branches. - -`git push origin master`:: - Find a ref that matches `master` in the source repository - (most likely, it would find `refs/heads/master`), and update - the same ref (e.g. `refs/heads/master`) in `origin` repository - with it. If `master` did not exist remotely, it would be - created. - -`git push origin HEAD`:: - A handy way to push the current branch to the same name on the - remote. - -`git push mothership master:satellite/master dev:satellite/dev`:: - Use the source ref that matches `master` (e.g. `refs/heads/master`) - to update the ref that matches `satellite/master` (most probably - `refs/remotes/satellite/master`) in the `mothership` repository; - do the same for `dev` and `satellite/dev`. -+ -See the section describing `<refspec>...` above for a discussion of -the matching semantics. -+ -This is to emulate `git fetch` run on the `mothership` using `git -push` that is run in the opposite direction in order to integrate -the work done on `satellite`, and is often necessary when you can -only make connection in one way (i.e. satellite can ssh into -mothership but mothership cannot initiate connection to satellite -because the latter is behind a firewall or does not run sshd). -+ -After running this `git push` on the `satellite` machine, you would -ssh into the `mothership` and run `git merge` there to complete the -emulation of `git pull` that were run on `mothership` to pull changes -made on `satellite`. - -`git push origin HEAD:master`:: - Push the current branch to the remote ref matching `master` in the - `origin` repository. This form is convenient to push the current - branch without thinking about its local name. - -`git push origin master:refs/heads/experimental`:: - Create the branch `experimental` in the `origin` repository - by copying the current `master` branch. This form is only - needed to create a new branch or tag in the remote repository when - the local name and the remote name are different; otherwise, - the ref name on its own will work. - -`git push origin :experimental`:: - Find a ref that matches `experimental` in the `origin` repository - (e.g. `refs/heads/experimental`), and delete it. - -`git push origin +dev:master`:: - Update the origin repository's master branch with the dev branch, - allowing non-fast-forward updates. *This can leave unreferenced - commits dangling in the origin repository.* Consider the - following situation, where a fast-forward is not possible: -+ ----- - o---o---o---A---B origin/master - \ - X---Y---Z dev ----- -+ -The above command would change the origin repository to -+ ----- - A---B (unnamed branch) - / - o---o---o---X---Y---Z master ----- -+ -Commits A and B would no longer belong to a branch with a symbolic name, -and so would be unreachable. As such, these commits would be removed by -a `git gc` command on the origin repository. - -include::transfer-data-leaks.txt[] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-quiltimport.txt b/third_party/git/Documentation/git-quiltimport.txt deleted file mode 100644 index 70562dc4c0..0000000000 --- a/third_party/git/Documentation/git-quiltimport.txt +++ /dev/null @@ -1,64 +0,0 @@ -git-quiltimport(1) -================== - -NAME ----- -git-quiltimport - Applies a quilt patchset onto the current branch - - -SYNOPSIS --------- -[verse] -'git quiltimport' [--dry-run | -n] [--author <author>] [--patches <dir>] - [--series <file>] [--keep-non-patch] - - -DESCRIPTION ------------ -Applies a quilt patchset onto the current Git branch, preserving -the patch boundaries, patch order, and patch descriptions present -in the quilt patchset. - -For each patch the code attempts to extract the author from the -patch description. If that fails it falls back to the author -specified with --author. If the --author flag was not given -the patch description is displayed and the user is asked to -interactively enter the author of the patch. - -If a subject is not found in the patch description the patch name is -preserved as the 1 line subject in the Git description. - -OPTIONS -------- - --n:: ---dry-run:: - Walk through the patches in the series and warn - if we cannot find all of the necessary information to commit - a patch. At the time of this writing only missing author - information is warned about. - ---author Author Name <Author Email>:: - The author name and email address to use when no author - information can be found in the patch description. - ---patches <dir>:: - The directory to find the quilt patches. -+ -The default for the patch directory is patches -or the value of the `$QUILT_PATCHES` environment -variable. - ---series <file>:: - The quilt series file. -+ -The default for the series file is <patches>/series -or the value of the `$QUILT_SERIES` environment -variable. - ---keep-non-patch:: - Pass `-b` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]). - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-range-diff.txt b/third_party/git/Documentation/git-range-diff.txt deleted file mode 100644 index 8a6ea2c6c5..0000000000 --- a/third_party/git/Documentation/git-range-diff.txt +++ /dev/null @@ -1,269 +0,0 @@ -git-range-diff(1) -================= - -NAME ----- -git-range-diff - Compare two commit ranges (e.g. two versions of a branch) - -SYNOPSIS --------- -[verse] -'git range-diff' [--color=[<when>]] [--no-color] [<diff-options>] - [--no-dual-color] [--creation-factor=<factor>] - ( <range1> <range2> | <rev1>...<rev2> | <base> <rev1> <rev2> ) - -DESCRIPTION ------------ - -This command shows the differences between two versions of a patch -series, or more generally, two commit ranges (ignoring merge commits). - -To that end, it first finds pairs of commits from both commit ranges -that correspond with each other. Two commits are said to correspond when -the diff between their patches (i.e. the author information, the commit -message and the commit diff) is reasonably small compared to the -patches' size. See ``Algorithm`` below for details. - -Finally, the list of matching commits is shown in the order of the -second commit range, with unmatched commits being inserted just after -all of their ancestors have been shown. - - -OPTIONS -------- ---no-dual-color:: - When the commit diffs differ, `git range-diff` recreates the - original diffs' coloring, and adds outer -/+ diff markers with - the *background* being red/green to make it easier to see e.g. - when there was a change in what exact lines were added. -+ -Additionally, the commit diff lines that are only present in the first commit -range are shown "dimmed" (this can be overridden using the `color.diff.<slot>` -config setting where `<slot>` is one of `contextDimmed`, `oldDimmed` and -`newDimmed`), and the commit diff lines that are only present in the second -commit range are shown in bold (which can be overridden using the config -settings `color.diff.<slot>` with `<slot>` being one of `contextBold`, -`oldBold` or `newBold`). -+ -This is known to `range-diff` as "dual coloring". Use `--no-dual-color` -to revert to color all lines according to the outer diff markers -(and completely ignore the inner diff when it comes to color). - ---creation-factor=<percent>:: - Set the creation/deletion cost fudge factor to `<percent>`. - Defaults to 60. Try a larger value if `git range-diff` erroneously - considers a large change a total rewrite (deletion of one commit - and addition of another), and a smaller one in the reverse case. - See the ``Algorithm`` section below for an explanation why this is - needed. - -<range1> <range2>:: - Compare the commits specified by the two ranges, where - `<range1>` is considered an older version of `<range2>`. - -<rev1>...<rev2>:: - Equivalent to passing `<rev2>..<rev1>` and `<rev1>..<rev2>`. - -<base> <rev1> <rev2>:: - Equivalent to passing `<base>..<rev1>` and `<base>..<rev2>`. - Note that `<base>` does not need to be the exact branch point - of the branches. Example: after rebasing a branch `my-topic`, - `git range-diff my-topic@{u} my-topic@{1} my-topic` would - show the differences introduced by the rebase. - -`git range-diff` also accepts the regular diff options (see -linkgit:git-diff[1]), most notably the `--color=[<when>]` and -`--no-color` options. These options are used when generating the "diff -between patches", i.e. to compare the author, commit message and diff of -corresponding old/new commits. There is currently no means to tweak the -diff options passed to `git log` when generating those patches. - -OUTPUT STABILITY ----------------- - -The output of the `range-diff` command is subject to change. It is -intended to be human-readable porcelain output, not something that can -be used across versions of Git to get a textually stable `range-diff` -(as opposed to something like the `--stable` option to -linkgit:git-patch-id[1]). There's also no equivalent of -linkgit:git-apply[1] for `range-diff`, the output is not intended to -be machine-readable. - -This is particularly true when passing in diff options. Currently some -options like `--stat` can, as an emergent effect, produce output -that's quite useless in the context of `range-diff`. Future versions -of `range-diff` may learn to interpret such options in a manner -specific to `range-diff` (e.g. for `--stat` producing human-readable -output which summarizes how the diffstat changed). - -CONFIGURATION -------------- -This command uses the `diff.color.*` and `pager.range-diff` settings -(the latter is on by default). -See linkgit:git-config[1]. - - -EXAMPLES --------- - -When a rebase required merge conflicts to be resolved, compare the changes -introduced by the rebase directly afterwards using: - ------------- -$ git range-diff @{u} @{1} @ ------------- - - -A typical output of `git range-diff` would look like this: - ------------- --: ------- > 1: 0ddba11 Prepare for the inevitable! -1: c0debee = 2: cab005e Add a helpful message at the start -2: f00dbal ! 3: decafe1 Describe a bug - @@ -1,3 +1,3 @@ - Author: A U Thor <author@example.com> - - -TODO: Describe a bug - +Describe a bug - @@ -324,5 +324,6 - This is expected. - - -+What is unexpected is that it will also crash. - ++Unexpectedly, it also crashes. This is a bug, and the jury is - ++still out there how to fix it best. See ticket #314 for details. - - Contact -3: bedead < -: ------- TO-UNDO ------------- - -In this example, there are 3 old and 3 new commits, where the developer -removed the 3rd, added a new one before the first two, and modified the -commit message of the 2nd commit as well its diff. - -When the output goes to a terminal, it is color-coded by default, just -like regular `git diff`'s output. In addition, the first line (adding a -commit) is green, the last line (deleting a commit) is red, the second -line (with a perfect match) is yellow like the commit header of `git -show`'s output, and the third line colors the old commit red, the new -one green and the rest like `git show`'s commit header. - -A naive color-coded diff of diffs is actually a bit hard to read, -though, as it colors the entire lines red or green. The line that added -"What is unexpected" in the old commit, for example, is completely red, -even if the intent of the old commit was to add something. - -To help with that, `range` uses the `--dual-color` mode by default. In -this mode, the diff of diffs will retain the original diff colors, and -prefix the lines with -/+ markers that have their *background* red or -green, to make it more obvious that they describe how the diff itself -changed. - - -Algorithm ---------- - -The general idea is this: we generate a cost matrix between the commits -in both commit ranges, then solve the least-cost assignment. - -The cost matrix is populated thusly: for each pair of commits, both -diffs are generated and the "diff of diffs" is generated, with 3 context -lines, then the number of lines in that diff is used as cost. - -To avoid false positives (e.g. when a patch has been removed, and an -unrelated patch has been added between two iterations of the same patch -series), the cost matrix is extended to allow for that, by adding -fixed-cost entries for wholesale deletes/adds. - -Example: Let commits `1--2` be the first iteration of a patch series and -`A--C` the second iteration. Let's assume that `A` is a cherry-pick of -`2,` and `C` is a cherry-pick of `1` but with a small modification (say, -a fixed typo). Visualize the commits as a bipartite graph: - ------------- - 1 A - - 2 B - - C ------------- - -We are looking for a "best" explanation of the new series in terms of -the old one. We can represent an "explanation" as an edge in the graph: - - ------------- - 1 A - / - 2 --------' B - - C ------------- - -This explanation comes for "free" because there was no change. Similarly -`C` could be explained using `1`, but that comes at some cost c>0 -because of the modification: - ------------- - 1 ----. A - | / - 2 ----+---' B - | - `----- C - c>0 ------------- - -In mathematical terms, what we are looking for is some sort of a minimum -cost bipartite matching; `1` is matched to `C` at some cost, etc. The -underlying graph is in fact a complete bipartite graph; the cost we -associate with every edge is the size of the diff between the two -commits' patches. To explain also new commits, we introduce dummy nodes -on both sides: - ------------- - 1 ----. A - | / - 2 ----+---' B - | - o `----- C - c>0 - o o - - o o ------------- - -The cost of an edge `o--C` is the size of `C`'s diff, modified by a -fudge factor that should be smaller than 100%. The cost of an edge -`o--o` is free. The fudge factor is necessary because even if `1` and -`C` have nothing in common, they may still share a few empty lines and -such, possibly making the assignment `1--C`, `o--o` slightly cheaper -than `1--o`, `o--C` even if `1` and `C` have nothing in common. With the -fudge factor we require a much larger common part to consider patches as -corresponding. - -The overall time needed to compute this algorithm is the time needed to -compute n+m commit diffs and then n*m diffs of patches, plus the time -needed to compute the least-cost assigment between n and m diffs. Git -uses an implementation of the Jonker-Volgenant algorithm to solve the -assignment problem, which has cubic runtime complexity. The matching -found in this case will look like this: - ------------- - 1 ----. A - | / - 2 ----+---' B - .--+-----' - o -' `----- C - c>0 - o ---------- o - - o ---------- o ------------- - - -SEE ALSO --------- -linkgit:git-log[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-read-tree.txt b/third_party/git/Documentation/git-read-tree.txt deleted file mode 100644 index d271842608..0000000000 --- a/third_party/git/Documentation/git-read-tree.txt +++ /dev/null @@ -1,443 +0,0 @@ -git-read-tree(1) -================ - -NAME ----- -git-read-tree - Reads tree information into the index - - -SYNOPSIS --------- -[verse] -'git read-tree' [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] - [-u [--exclude-per-directory=<gitignore>] | -i]] - [--index-output=<file>] [--no-sparse-checkout] - (--empty | <tree-ish1> [<tree-ish2> [<tree-ish3>]]) - - -DESCRIPTION ------------ -Reads the tree information given by <tree-ish> into the index, -but does not actually *update* any of the files it "caches". (see: -linkgit:git-checkout-index[1]) - -Optionally, it can merge a tree into the index, perform a -fast-forward (i.e. 2-way) merge, or a 3-way merge, with the `-m` -flag. When used with `-m`, the `-u` flag causes it to also update -the files in the work tree with the result of the merge. - -Trivial merges are done by 'git read-tree' itself. Only conflicting paths -will be in unmerged state when 'git read-tree' returns. - -OPTIONS -------- --m:: - Perform a merge, not just a read. The command will - refuse to run if your index file has unmerged entries, - indicating that you have not finished previous merge you - started. - ---reset:: - Same as -m, except that unmerged entries are discarded instead - of failing. When used with `-u`, updates leading to loss of - working tree changes will not abort the operation. - --u:: - After a successful merge, update the files in the work - tree with the result of the merge. - --i:: - Usually a merge requires the index file as well as the - files in the working tree to be up to date with the - current head commit, in order not to lose local - changes. This flag disables the check with the working - tree and is meant to be used when creating a merge of - trees that are not directly related to the current - working tree status into a temporary index file. - --n:: ---dry-run:: - Check if the command would error out, without updating the index - or the files in the working tree for real. - --v:: - Show the progress of checking files out. - ---trivial:: - Restrict three-way merge by 'git read-tree' to happen - only if there is no file-level merging required, instead - of resolving merge for trivial cases and leaving - conflicting files unresolved in the index. - ---aggressive:: - Usually a three-way merge by 'git read-tree' resolves - the merge for really trivial cases and leaves other - cases unresolved in the index, so that porcelains can - implement different merge policies. This flag makes the - command resolve a few more cases internally: -+ -* when one side removes a path and the other side leaves the path - unmodified. The resolution is to remove that path. -* when both sides remove a path. The resolution is to remove that path. -* when both sides add a path identically. The resolution - is to add that path. - ---prefix=<prefix>:: - Keep the current index contents, and read the contents - of the named tree-ish under the directory at `<prefix>`. - The command will refuse to overwrite entries that already - existed in the original index file. - ---exclude-per-directory=<gitignore>:: - When running the command with `-u` and `-m` options, the - merge result may need to overwrite paths that are not - tracked in the current branch. The command usually - refuses to proceed with the merge to avoid losing such a - path. However this safety valve sometimes gets in the - way. For example, it often happens that the other - branch added a file that used to be a generated file in - your branch, and the safety valve triggers when you try - to switch to that branch after you ran `make` but before - running `make clean` to remove the generated file. This - option tells the command to read per-directory exclude - file (usually '.gitignore') and allows such an untracked - but explicitly ignored file to be overwritten. - ---index-output=<file>:: - Instead of writing the results out to `$GIT_INDEX_FILE`, - write the resulting index in the named file. While the - command is operating, the original index file is locked - with the same mechanism as usual. The file must allow - to be rename(2)ed into from a temporary file that is - created next to the usual index file; typically this - means it needs to be on the same filesystem as the index - file itself, and you need write permission to the - directories the index file and index output file are - located in. - ---[no-]recurse-submodules:: - Using --recurse-submodules will update the content of all initialized - submodules according to the commit recorded in the superproject by - calling read-tree recursively, also setting the submodules HEAD to be - detached at that commit. - ---no-sparse-checkout:: - Disable sparse checkout support even if `core.sparseCheckout` - is true. - ---empty:: - Instead of reading tree object(s) into the index, just empty - it. - --q:: ---quiet:: - Quiet, suppress feedback messages. - -<tree-ish#>:: - The id of the tree object(s) to be read/merged. - - -MERGING -------- -If `-m` is specified, 'git read-tree' can perform 3 kinds of -merge, a single tree merge if only 1 tree is given, a -fast-forward merge with 2 trees, or a 3-way merge if 3 or more trees are -provided. - - -Single Tree Merge -~~~~~~~~~~~~~~~~~ -If only 1 tree is specified, 'git read-tree' operates as if the user did not -specify `-m`, except that if the original index has an entry for a -given pathname, and the contents of the path match with the tree -being read, the stat info from the index is used. (In other words, the -index's stat()s take precedence over the merged tree's). - -That means that if you do a `git read-tree -m <newtree>` followed by a -`git checkout-index -f -u -a`, the 'git checkout-index' only checks out -the stuff that really changed. - -This is used to avoid unnecessary false hits when 'git diff-files' is -run after 'git read-tree'. - - -Two Tree Merge -~~~~~~~~~~~~~~ - -Typically, this is invoked as `git read-tree -m $H $M`, where $H -is the head commit of the current repository, and $M is the head -of a foreign tree, which is simply ahead of $H (i.e. we are in a -fast-forward situation). - -When two trees are specified, the user is telling 'git read-tree' -the following: - - 1. The current index and work tree is derived from $H, but - the user may have local changes in them since $H. - - 2. The user wants to fast-forward to $M. - -In this case, the `git read-tree -m $H $M` command makes sure -that no local change is lost as the result of this "merge". -Here are the "carry forward" rules, where "I" denotes the index, -"clean" means that index and work tree coincide, and "exists"/"nothing" -refer to the presence of a path in the specified commit: - -.... - I H M Result - ------------------------------------------------------- - 0 nothing nothing nothing (does not happen) - 1 nothing nothing exists use M - 2 nothing exists nothing remove path from index - 3 nothing exists exists, use M if "initial checkout", - H == M keep index otherwise - exists, fail - H != M - - clean I==H I==M - ------------------ - 4 yes N/A N/A nothing nothing keep index - 5 no N/A N/A nothing nothing keep index - - 6 yes N/A yes nothing exists keep index - 7 no N/A yes nothing exists keep index - 8 yes N/A no nothing exists fail - 9 no N/A no nothing exists fail - - 10 yes yes N/A exists nothing remove path from index - 11 no yes N/A exists nothing fail - 12 yes no N/A exists nothing fail - 13 no no N/A exists nothing fail - - clean (H==M) - ------ - 14 yes exists exists keep index - 15 no exists exists keep index - - clean I==H I==M (H!=M) - ------------------ - 16 yes no no exists exists fail - 17 no no no exists exists fail - 18 yes no yes exists exists keep index - 19 no no yes exists exists keep index - 20 yes yes no exists exists use M - 21 no yes no exists exists fail -.... - -In all "keep index" cases, the index entry stays as in the -original index file. If the entry is not up to date, -'git read-tree' keeps the copy in the work tree intact when -operating under the -u flag. - -When this form of 'git read-tree' returns successfully, you can -see which of the "local changes" that you made were carried forward by running -`git diff-index --cached $M`. Note that this does not -necessarily match what `git diff-index --cached $H` would have -produced before such a two tree merge. This is because of cases -18 and 19 --- if you already had the changes in $M (e.g. maybe -you picked it up via e-mail in a patch form), `git diff-index ---cached $H` would have told you about the change before this -merge, but it would not show in `git diff-index --cached $M` -output after the two-tree merge. - -Case 3 is slightly tricky and needs explanation. The result from this -rule logically should be to remove the path if the user staged the removal -of the path and then switching to a new branch. That however will prevent -the initial checkout from happening, so the rule is modified to use M (new -tree) only when the content of the index is empty. Otherwise the removal -of the path is kept as long as $H and $M are the same. - -3-Way Merge -~~~~~~~~~~~ -Each "index" entry has two bits worth of "stage" state. stage 0 is the -normal one, and is the only one you'd see in any kind of normal use. - -However, when you do 'git read-tree' with three trees, the "stage" -starts out at 1. - -This means that you can do - ----------------- -$ git read-tree -m <tree1> <tree2> <tree3> ----------------- - -and you will end up with an index with all of the <tree1> entries in -"stage1", all of the <tree2> entries in "stage2" and all of the -<tree3> entries in "stage3". When performing a merge of another -branch into the current branch, we use the common ancestor tree -as <tree1>, the current branch head as <tree2>, and the other -branch head as <tree3>. - -Furthermore, 'git read-tree' has special-case logic that says: if you see -a file that matches in all respects in the following states, it -"collapses" back to "stage0": - - - stage 2 and 3 are the same; take one or the other (it makes no - difference - the same work has been done on our branch in - stage 2 and their branch in stage 3) - - - stage 1 and stage 2 are the same and stage 3 is different; take - stage 3 (our branch in stage 2 did not do anything since the - ancestor in stage 1 while their branch in stage 3 worked on - it) - - - stage 1 and stage 3 are the same and stage 2 is different take - stage 2 (we did something while they did nothing) - -The 'git write-tree' command refuses to write a nonsensical tree, and it -will complain about unmerged entries if it sees a single entry that is not -stage 0. - -OK, this all sounds like a collection of totally nonsensical rules, -but it's actually exactly what you want in order to do a fast -merge. The different stages represent the "result tree" (stage 0, aka -"merged"), the original tree (stage 1, aka "orig"), and the two trees -you are trying to merge (stage 2 and 3 respectively). - -The order of stages 1, 2 and 3 (hence the order of three -<tree-ish> command-line arguments) are significant when you -start a 3-way merge with an index file that is already -populated. Here is an outline of how the algorithm works: - -- if a file exists in identical format in all three trees, it will - automatically collapse to "merged" state by 'git read-tree'. - -- a file that has _any_ difference what-so-ever in the three trees - will stay as separate entries in the index. It's up to "porcelain - policy" to determine how to remove the non-0 stages, and insert a - merged version. - -- the index file saves and restores with all this information, so you - can merge things incrementally, but as long as it has entries in - stages 1/2/3 (i.e., "unmerged entries") you can't write the result. So - now the merge algorithm ends up being really simple: - - * you walk the index in order, and ignore all entries of stage 0, - since they've already been done. - - * if you find a "stage1", but no matching "stage2" or "stage3", you - know it's been removed from both trees (it only existed in the - original tree), and you remove that entry. - - * if you find a matching "stage2" and "stage3" tree, you remove one - of them, and turn the other into a "stage0" entry. Remove any - matching "stage1" entry if it exists too. .. all the normal - trivial rules .. - -You would normally use 'git merge-index' with supplied -'git merge-one-file' to do this last step. The script updates -the files in the working tree as it merges each path and at the -end of a successful merge. - -When you start a 3-way merge with an index file that is already -populated, it is assumed that it represents the state of the -files in your work tree, and you can even have files with -changes unrecorded in the index file. It is further assumed -that this state is "derived" from the stage 2 tree. The 3-way -merge refuses to run if it finds an entry in the original index -file that does not match stage 2. - -This is done to prevent you from losing your work-in-progress -changes, and mixing your random changes in an unrelated merge -commit. To illustrate, suppose you start from what has been -committed last to your repository: - ----------------- -$ JC=`git rev-parse --verify "HEAD^0"` -$ git checkout-index -f -u -a $JC ----------------- - -You do random edits, without running 'git update-index'. And then -you notice that the tip of your "upstream" tree has advanced -since you pulled from him: - ----------------- -$ git fetch git://.... linus -$ LT=`git rev-parse FETCH_HEAD` ----------------- - -Your work tree is still based on your HEAD ($JC), but you have -some edits since. Three-way merge makes sure that you have not -added or modified index entries since $JC, and if you haven't, -then does the right thing. So with the following sequence: - ----------------- -$ git read-tree -m -u `git merge-base $JC $LT` $JC $LT -$ git merge-index git-merge-one-file -a -$ echo "Merge with Linus" | \ - git commit-tree `git write-tree` -p $JC -p $LT ----------------- - -what you would commit is a pure merge between $JC and $LT without -your work-in-progress changes, and your work tree would be -updated to the result of the merge. - -However, if you have local changes in the working tree that -would be overwritten by this merge, 'git read-tree' will refuse -to run to prevent your changes from being lost. - -In other words, there is no need to worry about what exists only -in the working tree. When you have local changes in a part of -the project that is not involved in the merge, your changes do -not interfere with the merge, and are kept intact. When they -*do* interfere, the merge does not even start ('git read-tree' -complains loudly and fails without modifying anything). In such -a case, you can simply continue doing what you were in the -middle of doing, and when your working tree is ready (i.e. you -have finished your work-in-progress), attempt the merge again. - - -SPARSE CHECKOUT ---------------- - -"Sparse checkout" allows populating the working directory sparsely. -It uses the skip-worktree bit (see linkgit:git-update-index[1]) to tell -Git whether a file in the working directory is worth looking at. - -'git read-tree' and other merge-based commands ('git merge', 'git -checkout'...) can help maintaining the skip-worktree bitmap and working -directory update. `$GIT_DIR/info/sparse-checkout` is used to -define the skip-worktree reference bitmap. When 'git read-tree' needs -to update the working directory, it resets the skip-worktree bit in the index -based on this file, which uses the same syntax as .gitignore files. -If an entry matches a pattern in this file, skip-worktree will not be -set on that entry. Otherwise, skip-worktree will be set. - -Then it compares the new skip-worktree value with the previous one. If -skip-worktree turns from set to unset, it will add the corresponding -file back. If it turns from unset to set, that file will be removed. - -While `$GIT_DIR/info/sparse-checkout` is usually used to specify what -files are in, you can also specify what files are _not_ in, using -negate patterns. For example, to remove the file `unwanted`: - ----------------- -/* -!unwanted ----------------- - -Another tricky thing is fully repopulating the working directory when you -no longer want sparse checkout. You cannot just disable "sparse -checkout" because skip-worktree bits are still in the index and your working -directory is still sparsely populated. You should re-populate the working -directory with the `$GIT_DIR/info/sparse-checkout` file content as -follows: - ----------------- -/* ----------------- - -Then you can disable sparse checkout. Sparse checkout support in 'git -read-tree' and similar commands is disabled by default. You need to -turn `core.sparseCheckout` on in order to have sparse checkout -support. - - -SEE ALSO --------- -linkgit:git-write-tree[1]; linkgit:git-ls-files[1]; -linkgit:gitignore[5] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-rebase.txt b/third_party/git/Documentation/git-rebase.txt deleted file mode 100644 index 6156609cf7..0000000000 --- a/third_party/git/Documentation/git-rebase.txt +++ /dev/null @@ -1,1053 +0,0 @@ -git-rebase(1) -============= - -NAME ----- -git-rebase - Reapply commits on top of another base tip - -SYNOPSIS --------- -[verse] -'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>] - [<upstream> [<branch>]] -'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>] - --root [<branch>] -'git rebase' (--continue | --skip | --abort | --quit | --edit-todo | --show-current-patch) - -DESCRIPTION ------------ -If <branch> is specified, 'git rebase' will perform an automatic -`git switch <branch>` before doing anything else. Otherwise -it remains on the current branch. - -If <upstream> is not specified, the upstream configured in -branch.<name>.remote and branch.<name>.merge options will be used (see -linkgit:git-config[1] for details) and the `--fork-point` option is -assumed. If you are currently not on any branch or if the current -branch does not have a configured upstream, the rebase will abort. - -All changes made by commits in the current branch but that are not -in <upstream> are saved to a temporary area. This is the same set -of commits that would be shown by `git log <upstream>..HEAD`; or by -`git log 'fork_point'..HEAD`, if `--fork-point` is active (see the -description on `--fork-point` below); or by `git log HEAD`, if the -`--root` option is specified. - -The current branch is reset to <upstream>, or <newbase> if the ---onto option was supplied. This has the exact same effect as -`git reset --hard <upstream>` (or <newbase>). ORIG_HEAD is set -to point at the tip of the branch before the reset. - -The commits that were previously saved into the temporary area are -then reapplied to the current branch, one by one, in order. Note that -any commits in HEAD which introduce the same textual changes as a commit -in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream -with a different commit message or timestamp will be skipped). - -It is possible that a merge failure will prevent this process from being -completely automatic. You will have to resolve any such merge failure -and run `git rebase --continue`. Another option is to bypass the commit -that caused the merge failure with `git rebase --skip`. To check out the -original <branch> and remove the .git/rebase-apply working files, use the -command `git rebase --abort` instead. - -Assume the following history exists and the current branch is "topic": - ------------- - A---B---C topic - / - D---E---F---G master ------------- - -From this point, the result of either of the following commands: - - - git rebase master - git rebase master topic - -would be: - ------------- - A'--B'--C' topic - / - D---E---F---G master ------------- - -*NOTE:* The latter form is just a short-hand of `git checkout topic` -followed by `git rebase master`. When rebase exits `topic` will -remain the checked-out branch. - -If the upstream branch already contains a change you have made (e.g., -because you mailed a patch which was applied upstream), then that commit -will be skipped. For example, running `git rebase master` on the -following history (in which `A'` and `A` introduce the same set of changes, -but have different committer information): - ------------- - A---B---C topic - / - D---E---A'---F master ------------- - -will result in: - ------------- - B'---C' topic - / - D---E---A'---F master ------------- - -Here is how you would transplant a topic branch based on one -branch to another, to pretend that you forked the topic branch -from the latter branch, using `rebase --onto`. - -First let's assume your 'topic' is based on branch 'next'. -For example, a feature developed in 'topic' depends on some -functionality which is found in 'next'. - ------------- - o---o---o---o---o master - \ - o---o---o---o---o next - \ - o---o---o topic ------------- - -We want to make 'topic' forked from branch 'master'; for example, -because the functionality on which 'topic' depends was merged into the -more stable 'master' branch. We want our tree to look like this: - ------------- - o---o---o---o---o master - | \ - | o'--o'--o' topic - \ - o---o---o---o---o next ------------- - -We can get this using the following command: - - git rebase --onto master next topic - - -Another example of --onto option is to rebase part of a -branch. If we have the following situation: - ------------- - H---I---J topicB - / - E---F---G topicA - / - A---B---C---D master ------------- - -then the command - - git rebase --onto master topicA topicB - -would result in: - ------------- - H'--I'--J' topicB - / - | E---F---G topicA - |/ - A---B---C---D master ------------- - -This is useful when topicB does not depend on topicA. - -A range of commits could also be removed with rebase. If we have -the following situation: - ------------- - E---F---G---H---I---J topicA ------------- - -then the command - - git rebase --onto topicA~5 topicA~3 topicA - -would result in the removal of commits F and G: - ------------- - E---H'---I'---J' topicA ------------- - -This is useful if F and G were flawed in some way, or should not be -part of topicA. Note that the argument to --onto and the <upstream> -parameter can be any valid commit-ish. - -In case of conflict, 'git rebase' will stop at the first problematic commit -and leave conflict markers in the tree. You can use 'git diff' to locate -the markers (<<<<<<) and make edits to resolve the conflict. For each -file you edit, you need to tell Git that the conflict has been resolved, -typically this would be done with - - - git add <filename> - - -After resolving the conflict manually and updating the index with the -desired resolution, you can continue the rebasing process with - - - git rebase --continue - - -Alternatively, you can undo the 'git rebase' with - - - git rebase --abort - -CONFIGURATION -------------- - -include::config/rebase.txt[] - -OPTIONS -------- ---onto <newbase>:: - Starting point at which to create the new commits. If the - --onto option is not specified, the starting point is - <upstream>. May be any valid commit, and not just an - existing branch name. -+ -As a special case, you may use "A\...B" as a shortcut for the -merge base of A and B if there is exactly one merge base. You can -leave out at most one of A and B, in which case it defaults to HEAD. - -<upstream>:: - Upstream branch to compare against. May be any valid commit, - not just an existing branch name. Defaults to the configured - upstream for the current branch. - -<branch>:: - Working branch; defaults to HEAD. - ---continue:: - Restart the rebasing process after having resolved a merge conflict. - ---abort:: - Abort the rebase operation and reset HEAD to the original - branch. If <branch> was provided when the rebase operation was - started, then HEAD will be reset to <branch>. Otherwise HEAD - will be reset to where it was when the rebase operation was - started. - ---quit:: - Abort the rebase operation but HEAD is not reset back to the - original branch. The index and working tree are also left - unchanged as a result. - ---keep-empty:: - Keep the commits that do not change anything from its - parents in the result. -+ -See also INCOMPATIBLE OPTIONS below. - ---allow-empty-message:: - By default, rebasing commits with an empty message will fail. - This option overrides that behavior, allowing commits with empty - messages to be rebased. -+ -See also INCOMPATIBLE OPTIONS below. - ---skip:: - Restart the rebasing process by skipping the current patch. - ---edit-todo:: - Edit the todo list during an interactive rebase. - ---show-current-patch:: - Show the current patch in an interactive rebase or when rebase - is stopped because of conflicts. This is the equivalent of - `git show REBASE_HEAD`. - --m:: ---merge:: - Use merging strategies to rebase. When the recursive (default) merge - strategy is used, this allows rebase to be aware of renames on the - upstream side. -+ -Note that a rebase merge works by replaying each commit from the working -branch on top of the <upstream> branch. Because of this, when a merge -conflict happens, the side reported as 'ours' is the so-far rebased -series, starting with <upstream>, and 'theirs' is the working branch. In -other words, the sides are swapped. -+ -See also INCOMPATIBLE OPTIONS below. - --s <strategy>:: ---strategy=<strategy>:: - Use the given merge strategy. - If there is no `-s` option 'git merge-recursive' is used - instead. This implies --merge. -+ -Because 'git rebase' replays each commit from the working branch -on top of the <upstream> branch using the given strategy, using -the 'ours' strategy simply empties all patches from the <branch>, -which makes little sense. -+ -See also INCOMPATIBLE OPTIONS below. - --X <strategy-option>:: ---strategy-option=<strategy-option>:: - Pass the <strategy-option> through to the merge strategy. - This implies `--merge` and, if no strategy has been - specified, `-s recursive`. Note the reversal of 'ours' and - 'theirs' as noted above for the `-m` option. -+ -See also INCOMPATIBLE OPTIONS below. - ---rerere-autoupdate:: ---no-rerere-autoupdate:: - Allow the rerere mechanism to update the index with the - result of auto-conflict resolution if possible. - --S[<keyid>]:: ---gpg-sign[=<keyid>]:: - GPG-sign commits. The `keyid` argument is optional and - defaults to the committer identity; if specified, it must be - stuck to the option without a space. - --q:: ---quiet:: - Be quiet. Implies --no-stat. - --v:: ---verbose:: - Be verbose. Implies --stat. - ---stat:: - Show a diffstat of what changed upstream since the last rebase. The - diffstat is also controlled by the configuration option rebase.stat. - --n:: ---no-stat:: - Do not show a diffstat as part of the rebase process. - ---no-verify:: - This option bypasses the pre-rebase hook. See also linkgit:githooks[5]. - ---verify:: - Allows the pre-rebase hook to run, which is the default. This option can - be used to override --no-verify. See also linkgit:githooks[5]. - --C<n>:: - Ensure at least <n> lines of surrounding context match before - and after each change. When fewer lines of surrounding - context exist they all must match. By default no context is - ever ignored. -+ -See also INCOMPATIBLE OPTIONS below. - ---no-ff:: ---force-rebase:: --f:: - Individually replay all rebased commits instead of fast-forwarding - over the unchanged ones. This ensures that the entire history of - the rebased branch is composed of new commits. -+ -You may find this helpful after reverting a topic branch merge, as this option -recreates the topic branch with fresh commits so it can be remerged -successfully without needing to "revert the reversion" (see the -link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for -details). - ---fork-point:: ---no-fork-point:: - Use reflog to find a better common ancestor between <upstream> - and <branch> when calculating which commits have been - introduced by <branch>. -+ -When --fork-point is active, 'fork_point' will be used instead of -<upstream> to calculate the set of commits to rebase, where -'fork_point' is the result of `git merge-base --fork-point <upstream> -<branch>` command (see linkgit:git-merge-base[1]). If 'fork_point' -ends up being empty, the <upstream> will be used as a fallback. -+ -If either <upstream> or --root is given on the command line, then the -default is `--no-fork-point`, otherwise the default is `--fork-point`. - ---ignore-whitespace:: ---whitespace=<option>:: - These flag are passed to the 'git apply' program - (see linkgit:git-apply[1]) that applies the patch. -+ -See also INCOMPATIBLE OPTIONS below. - ---committer-date-is-author-date:: ---ignore-date:: - These flags are passed to 'git am' to easily change the dates - of the rebased commits (see linkgit:git-am[1]). -+ -See also INCOMPATIBLE OPTIONS below. - ---signoff:: - Add a Signed-off-by: trailer to all the rebased commits. Note - that if `--interactive` is given then only commits marked to be - picked, edited or reworded will have the trailer added. -+ -See also INCOMPATIBLE OPTIONS below. - --i:: ---interactive:: - Make a list of the commits which are about to be rebased. Let the - user edit that list before rebasing. This mode can also be used to - split commits (see SPLITTING COMMITS below). -+ -The commit list format can be changed by setting the configuration option -rebase.instructionFormat. A customized instruction format will automatically -have the long commit hash prepended to the format. -+ -See also INCOMPATIBLE OPTIONS below. - --r:: ---rebase-merges[=(rebase-cousins|no-rebase-cousins)]:: - By default, a rebase will simply drop merge commits from the todo - list, and put the rebased commits into a single, linear branch. - With `--rebase-merges`, the rebase will instead try to preserve - the branching structure within the commits that are to be rebased, - by recreating the merge commits. Any resolved merge conflicts or - manual amendments in these merge commits will have to be - resolved/re-applied manually. -+ -By default, or when `no-rebase-cousins` was specified, commits which do not -have `<upstream>` as direct ancestor will keep their original branch point, -i.e. commits that would be excluded by linkgit:git-log[1]'s -`--ancestry-path` option will keep their original ancestry by default. If -the `rebase-cousins` mode is turned on, such commits are instead rebased -onto `<upstream>` (or `<onto>`, if specified). -+ -The `--rebase-merges` mode is similar in spirit to the deprecated -`--preserve-merges`, but in contrast to that option works well in interactive -rebases: commits can be reordered, inserted and dropped at will. -+ -It is currently only possible to recreate the merge commits using the -`recursive` merge strategy; Different merge strategies can be used only via -explicit `exec git merge -s <strategy> [...]` commands. -+ -See also REBASING MERGES and INCOMPATIBLE OPTIONS below. - --p:: ---preserve-merges:: - [DEPRECATED: use `--rebase-merges` instead] Recreate merge commits - instead of flattening the history by replaying commits a merge commit - introduces. Merge conflict resolutions or manual amendments to merge - commits are not preserved. -+ -This uses the `--interactive` machinery internally, but combining it -with the `--interactive` option explicitly is generally not a good -idea unless you know what you are doing (see BUGS below). -+ -See also INCOMPATIBLE OPTIONS below. - --x <cmd>:: ---exec <cmd>:: - Append "exec <cmd>" after each line creating a commit in the - final history. <cmd> will be interpreted as one or more shell - commands. Any command that fails will interrupt the rebase, - with exit code 1. -+ -You may execute several commands by either using one instance of `--exec` -with several commands: -+ - git rebase -i --exec "cmd1 && cmd2 && ..." -+ -or by giving more than one `--exec`: -+ - git rebase -i --exec "cmd1" --exec "cmd2" --exec ... -+ -If `--autosquash` is used, "exec" lines will not be appended for -the intermediate commits, and will only appear at the end of each -squash/fixup series. -+ -This uses the `--interactive` machinery internally, but it can be run -without an explicit `--interactive`. -+ -See also INCOMPATIBLE OPTIONS below. - ---root:: - Rebase all commits reachable from <branch>, instead of - limiting them with an <upstream>. This allows you to rebase - the root commit(s) on a branch. When used with --onto, it - will skip changes already contained in <newbase> (instead of - <upstream>) whereas without --onto it will operate on every change. - When used together with both --onto and --preserve-merges, - 'all' root commits will be rewritten to have <newbase> as parent - instead. -+ -See also INCOMPATIBLE OPTIONS below. - ---autosquash:: ---no-autosquash:: - When the commit log message begins with "squash! ..." (or - "fixup! ..."), and there is already a commit in the todo list that - matches the same `...`, automatically modify the todo list of rebase - -i so that the commit marked for squashing comes right after the - commit to be modified, and change the action of the moved commit - from `pick` to `squash` (or `fixup`). A commit matches the `...` if - the commit subject matches, or if the `...` refers to the commit's - hash. As a fall-back, partial matches of the commit subject work, - too. The recommended way to create fixup/squash commits is by using - the `--fixup`/`--squash` options of linkgit:git-commit[1]. -+ -If the `--autosquash` option is enabled by default using the -configuration variable `rebase.autoSquash`, this option can be -used to override and disable this setting. -+ -See also INCOMPATIBLE OPTIONS below. - ---autostash:: ---no-autostash:: - Automatically create a temporary stash entry before the operation - begins, and apply it after the operation ends. This means - that you can run rebase on a dirty worktree. However, use - with care: the final stash application after a successful - rebase might result in non-trivial conflicts. - ---reschedule-failed-exec:: ---no-reschedule-failed-exec:: - Automatically reschedule `exec` commands that failed. This only makes - sense in interactive mode (or when an `--exec` option was provided). - -INCOMPATIBLE OPTIONS --------------------- - -The following options: - - * --committer-date-is-author-date - * --ignore-date - * --whitespace - * --ignore-whitespace - * -C - -are incompatible with the following options: - - * --merge - * --strategy - * --strategy-option - * --allow-empty-message - * --[no-]autosquash - * --rebase-merges - * --preserve-merges - * --interactive - * --exec - * --keep-empty - * --edit-todo - * --root when used in combination with --onto - -In addition, the following pairs of options are incompatible: - - * --preserve-merges and --interactive - * --preserve-merges and --signoff - * --preserve-merges and --rebase-merges - * --rebase-merges and --strategy - * --rebase-merges and --strategy-option - -BEHAVIORAL DIFFERENCES ------------------------ - -There are some subtle differences how the backends behave. - -Empty commits -~~~~~~~~~~~~~ - -The am backend drops any "empty" commits, regardless of whether the -commit started empty (had no changes relative to its parent to -start with) or ended empty (all changes were already applied -upstream in other commits). - -The interactive backend drops commits by default that -started empty and halts if it hits a commit that ended up empty. -The `--keep-empty` option exists for the interactive backend to allow -it to keep commits that started empty. - -Directory rename detection -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Directory rename heuristics are enabled in the merge and interactive -backends. Due to the lack of accurate tree information, directory -rename detection is disabled in the am backend. - -include::merge-strategies.txt[] - -NOTES ------ - -You should understand the implications of using 'git rebase' on a -repository that you share. See also RECOVERING FROM UPSTREAM REBASE -below. - -When the git-rebase command is run, it will first execute a "pre-rebase" -hook if one exists. You can use this hook to do sanity checks and -reject the rebase if it isn't appropriate. Please see the template -pre-rebase hook script for an example. - -Upon completion, <branch> will be the current branch. - -INTERACTIVE MODE ----------------- - -Rebasing interactively means that you have a chance to edit the commits -which are rebased. You can reorder the commits, and you can -remove them (weeding out bad or otherwise unwanted patches). - -The interactive mode is meant for this type of workflow: - -1. have a wonderful idea -2. hack on the code -3. prepare a series for submission -4. submit - -where point 2. consists of several instances of - -a) regular use - - 1. finish something worthy of a commit - 2. commit - -b) independent fixup - - 1. realize that something does not work - 2. fix that - 3. commit it - -Sometimes the thing fixed in b.2. cannot be amended to the not-quite -perfect commit it fixes, because that commit is buried deeply in a -patch series. That is exactly what interactive rebase is for: use it -after plenty of "a"s and "b"s, by rearranging and editing -commits, and squashing multiple commits into one. - -Start it with the last commit you want to retain as-is: - - git rebase -i <after-this-commit> - -An editor will be fired up with all the commits in your current branch -(ignoring merge commits), which come after the given commit. You can -reorder the commits in this list to your heart's content, and you can -remove them. The list looks more or less like this: - -------------------------------------------- -pick deadbee The oneline of this commit -pick fa1afe1 The oneline of the next commit -... -------------------------------------------- - -The oneline descriptions are purely for your pleasure; 'git rebase' will -not look at them but at the commit names ("deadbee" and "fa1afe1" in this -example), so do not delete or edit the names. - -By replacing the command "pick" with the command "edit", you can tell -'git rebase' to stop after applying that commit, so that you can edit -the files and/or the commit message, amend the commit, and continue -rebasing. - -To interrupt the rebase (just like an "edit" command would do, but without -cherry-picking any commit first), use the "break" command. - -If you just want to edit the commit message for a commit, replace the -command "pick" with the command "reword". - -To drop a commit, replace the command "pick" with "drop", or just -delete the matching line. - -If you want to fold two or more commits into one, replace the command -"pick" for the second and subsequent commits with "squash" or "fixup". -If the commits had different authors, the folded commit will be -attributed to the author of the first commit. The suggested commit -message for the folded commit is the concatenation of the commit -messages of the first commit and of those with the "squash" command, -but omits the commit messages of commits with the "fixup" command. - -'git rebase' will stop when "pick" has been replaced with "edit" or -when a command fails due to merge errors. When you are done editing -and/or resolving conflicts you can continue with `git rebase --continue`. - -For example, if you want to reorder the last 5 commits, such that what -was HEAD~4 becomes the new HEAD. To achieve that, you would call -'git rebase' like this: - ----------------------- -$ git rebase -i HEAD~5 ----------------------- - -And move the first patch to the end of the list. - -You might want to recreate merge commits, e.g. if you have a history -like this: - ------------------- - X - \ - A---M---B - / ----o---O---P---Q ------------------- - -Suppose you want to rebase the side branch starting at "A" to "Q". Make -sure that the current HEAD is "B", and call - ------------------------------ -$ git rebase -i -r --onto Q O ------------------------------ - -Reordering and editing commits usually creates untested intermediate -steps. You may want to check that your history editing did not break -anything by running a test, or at least recompiling at intermediate -points in history by using the "exec" command (shortcut "x"). You may -do so by creating a todo list like this one: - -------------------------------------------- -pick deadbee Implement feature XXX -fixup f1a5c00 Fix to feature XXX -exec make -pick c0ffeee The oneline of the next commit -edit deadbab The oneline of the commit after -exec cd subdir; make test -... -------------------------------------------- - -The interactive rebase will stop when a command fails (i.e. exits with -non-0 status) to give you an opportunity to fix the problem. You can -continue with `git rebase --continue`. - -The "exec" command launches the command in a shell (the one specified -in `$SHELL`, or the default shell if `$SHELL` is not set), so you can -use shell features (like "cd", ">", ";" ...). The command is run from -the root of the working tree. - ----------------------------------- -$ git rebase -i --exec "make test" ----------------------------------- - -This command lets you check that intermediate commits are compilable. -The todo list becomes like that: - --------------------- -pick 5928aea one -exec make test -pick 04d0fda two -exec make test -pick ba46169 three -exec make test -pick f4593f9 four -exec make test --------------------- - -SPLITTING COMMITS ------------------ - -In interactive mode, you can mark commits with the action "edit". However, -this does not necessarily mean that 'git rebase' expects the result of this -edit to be exactly one commit. Indeed, you can undo the commit, or you can -add other commits. This can be used to split a commit into two: - -- Start an interactive rebase with `git rebase -i <commit>^`, where - <commit> is the commit you want to split. In fact, any commit range - will do, as long as it contains that commit. - -- Mark the commit you want to split with the action "edit". - -- When it comes to editing that commit, execute `git reset HEAD^`. The - effect is that the HEAD is rewound by one, and the index follows suit. - However, the working tree stays the same. - -- Now add the changes to the index that you want to have in the first - commit. You can use `git add` (possibly interactively) or - 'git gui' (or both) to do that. - -- Commit the now-current index with whatever commit message is appropriate - now. - -- Repeat the last two steps until your working tree is clean. - -- Continue the rebase with `git rebase --continue`. - -If you are not absolutely sure that the intermediate revisions are -consistent (they compile, pass the testsuite, etc.) you should use -'git stash' to stash away the not-yet-committed changes -after each commit, test, and amend the commit if fixes are necessary. - - -RECOVERING FROM UPSTREAM REBASE -------------------------------- - -Rebasing (or any other form of rewriting) a branch that others have -based work on is a bad idea: anyone downstream of it is forced to -manually fix their history. This section explains how to do the fix -from the downstream's point of view. The real fix, however, would be -to avoid rebasing the upstream in the first place. - -To illustrate, suppose you are in a situation where someone develops a -'subsystem' branch, and you are working on a 'topic' that is dependent -on this 'subsystem'. You might end up with a history like the -following: - ------------- - o---o---o---o---o---o---o---o master - \ - o---o---o---o---o subsystem - \ - *---*---* topic ------------- - -If 'subsystem' is rebased against 'master', the following happens: - ------------- - o---o---o---o---o---o---o---o master - \ \ - o---o---o---o---o o'--o'--o'--o'--o' subsystem - \ - *---*---* topic ------------- - -If you now continue development as usual, and eventually merge 'topic' -to 'subsystem', the commits from 'subsystem' will remain duplicated forever: - ------------- - o---o---o---o---o---o---o---o master - \ \ - o---o---o---o---o o'--o'--o'--o'--o'--M subsystem - \ / - *---*---*-..........-*--* topic ------------- - -Such duplicates are generally frowned upon because they clutter up -history, making it harder to follow. To clean things up, you need to -transplant the commits on 'topic' to the new 'subsystem' tip, i.e., -rebase 'topic'. This becomes a ripple effect: anyone downstream from -'topic' is forced to rebase too, and so on! - -There are two kinds of fixes, discussed in the following subsections: - -Easy case: The changes are literally the same.:: - - This happens if the 'subsystem' rebase was a simple rebase and - had no conflicts. - -Hard case: The changes are not the same.:: - - This happens if the 'subsystem' rebase had conflicts, or used - `--interactive` to omit, edit, squash, or fixup commits; or - if the upstream used one of `commit --amend`, `reset`, or - `filter-branch`. - - -The easy case -~~~~~~~~~~~~~ - -Only works if the changes (patch IDs based on the diff contents) on -'subsystem' are literally the same before and after the rebase -'subsystem' did. - -In that case, the fix is easy because 'git rebase' knows to skip -changes that are already present in the new upstream. So if you say -(assuming you're on 'topic') ------------- - $ git rebase subsystem ------------- -you will end up with the fixed history ------------- - o---o---o---o---o---o---o---o master - \ - o'--o'--o'--o'--o' subsystem - \ - *---*---* topic ------------- - - -The hard case -~~~~~~~~~~~~~ - -Things get more complicated if the 'subsystem' changes do not exactly -correspond to the ones before the rebase. - -NOTE: While an "easy case recovery" sometimes appears to be successful - even in the hard case, it may have unintended consequences. For - example, a commit that was removed via `git rebase - --interactive` will be **resurrected**! - -The idea is to manually tell 'git rebase' "where the old 'subsystem' -ended and your 'topic' began", that is, what the old merge-base -between them was. You will have to find a way to name the last commit -of the old 'subsystem', for example: - -* With the 'subsystem' reflog: after 'git fetch', the old tip of - 'subsystem' is at `subsystem@{1}`. Subsequent fetches will - increase the number. (See linkgit:git-reflog[1].) - -* Relative to the tip of 'topic': knowing that your 'topic' has three - commits, the old tip of 'subsystem' must be `topic~3`. - -You can then transplant the old `subsystem..topic` to the new tip by -saying (for the reflog case, and assuming you are on 'topic' already): ------------- - $ git rebase --onto subsystem subsystem@{1} ------------- - -The ripple effect of a "hard case" recovery is especially bad: -'everyone' downstream from 'topic' will now have to perform a "hard -case" recovery too! - -REBASING MERGES ---------------- - -The interactive rebase command was originally designed to handle -individual patch series. As such, it makes sense to exclude merge -commits from the todo list, as the developer may have merged the -then-current `master` while working on the branch, only to rebase -all the commits onto `master` eventually (skipping the merge -commits). - -However, there are legitimate reasons why a developer may want to -recreate merge commits: to keep the branch structure (or "commit -topology") when working on multiple, inter-related branches. - -In the following example, the developer works on a topic branch that -refactors the way buttons are defined, and on another topic branch -that uses that refactoring to implement a "Report a bug" button. The -output of `git log --graph --format=%s -5` may look like this: - ------------- -* Merge branch 'report-a-bug' -|\ -| * Add the feedback button -* | Merge branch 'refactor-button' -|\ \ -| |/ -| * Use the Button class for all buttons -| * Extract a generic Button class from the DownloadButton one ------------- - -The developer might want to rebase those commits to a newer `master` -while keeping the branch topology, for example when the first topic -branch is expected to be integrated into `master` much earlier than the -second one, say, to resolve merge conflicts with changes to the -DownloadButton class that made it into `master`. - -This rebase can be performed using the `--rebase-merges` option. -It will generate a todo list looking like this: - ------------- -label onto - -# Branch: refactor-button -reset onto -pick 123456 Extract a generic Button class from the DownloadButton one -pick 654321 Use the Button class for all buttons -label refactor-button - -# Branch: report-a-bug -reset refactor-button # Use the Button class for all buttons -pick abcdef Add the feedback button -label report-a-bug - -reset onto -merge -C a1b2c3 refactor-button # Merge 'refactor-button' -merge -C 6f5e4d report-a-bug # Merge 'report-a-bug' ------------- - -In contrast to a regular interactive rebase, there are `label`, `reset` -and `merge` commands in addition to `pick` ones. - -The `label` command associates a label with the current HEAD when that -command is executed. These labels are created as worktree-local refs -(`refs/rewritten/<label>`) that will be deleted when the rebase -finishes. That way, rebase operations in multiple worktrees linked to -the same repository do not interfere with one another. If the `label` -command fails, it is rescheduled immediately, with a helpful message how -to proceed. - -The `reset` command resets the HEAD, index and worktree to the specified -revision. It is similar to an `exec git reset --hard <label>`, but -refuses to overwrite untracked files. If the `reset` command fails, it is -rescheduled immediately, with a helpful message how to edit the todo list -(this typically happens when a `reset` command was inserted into the todo -list manually and contains a typo). - -The `merge` command will merge the specified revision(s) into whatever -is HEAD at that time. With `-C <original-commit>`, the commit message of -the specified merge commit will be used. When the `-C` is changed to -a lower-case `-c`, the message will be opened in an editor after a -successful merge so that the user can edit the message. - -If a `merge` command fails for any reason other than merge conflicts (i.e. -when the merge operation did not even start), it is rescheduled immediately. - -At this time, the `merge` command will *always* use the `recursive` -merge strategy for regular merges, and `octopus` for octopus merges, -with no way to choose a different one. To work around -this, an `exec` command can be used to call `git merge` explicitly, -using the fact that the labels are worktree-local refs (the ref -`refs/rewritten/onto` would correspond to the label `onto`, for example). - -Note: the first command (`label onto`) labels the revision onto which -the commits are rebased; The name `onto` is just a convention, as a nod -to the `--onto` option. - -It is also possible to introduce completely new merge commits from scratch -by adding a command of the form `merge <merge-head>`. This form will -generate a tentative commit message and always open an editor to let the -user edit it. This can be useful e.g. when a topic branch turns out to -address more than a single concern and wants to be split into two or -even more topic branches. Consider this todo list: - ------------- -pick 192837 Switch from GNU Makefiles to CMake -pick 5a6c7e Document the switch to CMake -pick 918273 Fix detection of OpenSSL in CMake -pick afbecd http: add support for TLS v1.3 -pick fdbaec Fix detection of cURL in CMake on Windows ------------- - -The one commit in this list that is not related to CMake may very well -have been motivated by working on fixing all those bugs introduced by -switching to CMake, but it addresses a different concern. To split this -branch into two topic branches, the todo list could be edited like this: - ------------- -label onto - -pick afbecd http: add support for TLS v1.3 -label tlsv1.3 - -reset onto -pick 192837 Switch from GNU Makefiles to CMake -pick 918273 Fix detection of OpenSSL in CMake -pick fdbaec Fix detection of cURL in CMake on Windows -pick 5a6c7e Document the switch to CMake -label cmake - -reset onto -merge tlsv1.3 -merge cmake ------------- - -BUGS ----- -The todo list presented by the deprecated `--preserve-merges --interactive` -does not represent the topology of the revision graph (use `--rebase-merges` -instead). Editing commits and rewording their commit messages should work -fine, but attempts to reorder commits tend to produce counterintuitive results. -Use `--rebase-merges` in such scenarios instead. - -For example, an attempt to rearrange ------------- -1 --- 2 --- 3 --- 4 --- 5 ------------- -to ------------- -1 --- 2 --- 4 --- 3 --- 5 ------------- -by moving the "pick 4" line will result in the following history: ------------- - 3 - / -1 --- 2 --- 4 --- 5 ------------- - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-receive-pack.txt b/third_party/git/Documentation/git-receive-pack.txt deleted file mode 100644 index dedf97efbb..0000000000 --- a/third_party/git/Documentation/git-receive-pack.txt +++ /dev/null @@ -1,252 +0,0 @@ -git-receive-pack(1) -=================== - -NAME ----- -git-receive-pack - Receive what is pushed into the repository - - -SYNOPSIS --------- -[verse] -'git-receive-pack' <directory> - -DESCRIPTION ------------ -Invoked by 'git send-pack' and updates the repository with the -information fed from the remote end. - -This command is usually not invoked directly by the end user. -The UI for the protocol is on the 'git send-pack' side, and the -program pair is meant to be used to push updates to remote -repository. For pull operations, see linkgit:git-fetch-pack[1]. - -The command allows for creation and fast-forwarding of sha1 refs -(heads/tags) on the remote end (strictly speaking, it is the -local end 'git-receive-pack' runs, but to the user who is sitting at -the send-pack end, it is updating the remote. Confused?) - -There are other real-world examples of using update and -post-update hooks found in the Documentation/howto directory. - -'git-receive-pack' honours the receive.denyNonFastForwards config -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>:: - The repository to sync into. - -PRE-RECEIVE HOOK ----------------- -Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists -and is executable, it will be invoked once with no parameters. The -standard input of the hook will be one line per ref to be updated: - - sha1-old SP sha1-new SP refname LF - -The refname value is relative to $GIT_DIR; e.g. for the master -head this is "refs/heads/master". The two sha1 values before -each refname are the object names for the refname before and after -the update. Refs to be created will have sha1-old equal to 0\{40}, -while refs to be deleted will have sha1-new equal to 0\{40}, otherwise -sha1-old and sha1-new should be valid objects in the repository. - -When accepting a signed push (see linkgit:git-push[1]), the signed -push certificate is stored in a blob and an environment variable -`GIT_PUSH_CERT` can be consulted for its object name. See the -description of `post-receive` hook for an example. In addition, the -certificate is verified using GPG and the result is exported with -the following environment variables: - -`GIT_PUSH_CERT_SIGNER`:: - The name and the e-mail address of the owner of the key that - signed the push certificate. - -`GIT_PUSH_CERT_KEY`:: - The GPG key ID of the key that signed the push certificate. - -`GIT_PUSH_CERT_STATUS`:: - The status of GPG verification of the push certificate, - using the same mnemonic as used in `%G?` format of `git log` - family of commands (see linkgit:git-log[1]). - -`GIT_PUSH_CERT_NONCE`:: - The nonce string the process asked the signer to include - in the push certificate. If this does not match the value - recorded on the "nonce" header in the push certificate, it - may indicate that the certificate is a valid one that is - being replayed from a separate "git push" session. - -`GIT_PUSH_CERT_NONCE_STATUS`:: -`UNSOLICITED`;; - "git push --signed" sent a nonce when we did not ask it to - send one. -`MISSING`;; - "git push --signed" did not send any nonce header. -`BAD`;; - "git push --signed" sent a bogus nonce. -`OK`;; - "git push --signed" sent the nonce we asked it to send. -`SLOP`;; - "git push --signed" sent a nonce different from what we - asked it to send now, but in a previous session. See - `GIT_PUSH_CERT_NONCE_SLOP` environment variable. - -`GIT_PUSH_CERT_NONCE_SLOP`:: - "git push --signed" sent a nonce different from what we - asked it to send now, but in a different session whose - starting time is different by this many seconds from the - current session. Only meaningful when - `GIT_PUSH_CERT_NONCE_STATUS` says `SLOP`. - Also read about `receive.certNonceSlop` variable in - linkgit:git-config[1]. - -This hook is called before any refname is updated and before any -fast-forward checks are performed. - -If the pre-receive hook exits with a non-zero exit status no updates -will be performed, and the update, post-receive and post-update -hooks will not be invoked either. This can be useful to quickly -bail out if the update is not to be supported. - -See the notes on the quarantine environment below. - -UPDATE HOOK ------------ -Before each ref is updated, if $GIT_DIR/hooks/update file exists -and is executable, it is invoked once per ref, with three parameters: - - $GIT_DIR/hooks/update refname sha1-old sha1-new - -The refname parameter is relative to $GIT_DIR; e.g. for the master -head this is "refs/heads/master". The two sha1 arguments are -the object names for the refname before and after the update. -Note that the hook is called before the refname is updated, -so either sha1-old is 0\{40} (meaning there is no such ref yet), -or it should match what is recorded in refname. - -The hook should exit with non-zero status if it wants to disallow -updating the named ref. Otherwise it should exit with zero. - -Successful execution (a zero exit status) of this hook does not -ensure the ref will actually be updated, it is only a prerequisite. -As such it is not a good idea to send notices (e.g. email) from -this hook. Consider using the post-receive hook instead. - -POST-RECEIVE HOOK ------------------ -After all refs were updated (or attempted to be updated), if any -ref update was successful, and if $GIT_DIR/hooks/post-receive -file exists and is executable, it will be invoked once with no -parameters. The standard input of the hook will be one line -for each successfully updated ref: - - sha1-old SP sha1-new SP refname LF - -The refname value is relative to $GIT_DIR; e.g. for the master -head this is "refs/heads/master". The two sha1 values before -each refname are the object names for the refname before and after -the update. Refs that were created will have sha1-old equal to -0\{40}, while refs that were deleted will have sha1-new equal to -0\{40}, otherwise sha1-old and sha1-new should be valid objects in -the repository. - -The `GIT_PUSH_CERT*` environment variables can be inspected, just as -in `pre-receive` hook, after accepting a signed push. - -Using this hook, it is easy to generate mails describing the updates -to the repository. This example script sends one mail message per -ref listing the commits pushed to the repository, and logs the push -certificates of signed pushes with good signatures to a logger -service: - - #!/bin/sh - # mail out commit update information. - while read oval nval ref - do - if expr "$oval" : '0*$' >/dev/null - then - echo "Created a new ref, with the following commits:" - git rev-list --pretty "$nval" - else - echo "New commits:" - git rev-list --pretty "$nval" "^$oval" - fi | - mail -s "Changes to ref $ref" commit-list@mydomain - done - # log signed push certificate, if any - if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G - then - ( - echo expected nonce is ${GIT_PUSH_NONCE} - git cat-file blob ${GIT_PUSH_CERT} - ) | mail -s "push certificate from $GIT_PUSH_CERT_SIGNER" push-log@mydomain - fi - exit 0 - -The exit code from this hook invocation is ignored, however a -non-zero exit code will generate an error message. - -Note that it is possible for refname to not have sha1-new when this -hook runs. This can easily occur if another user modifies the ref -after it was updated by 'git-receive-pack', but before the hook was able -to evaluate it. It is recommended that hooks rely on sha1-new -rather than the current value of refname. - -POST-UPDATE HOOK ----------------- -After all other processing, if at least one ref was updated, and -if $GIT_DIR/hooks/post-update file exists and is executable, then -post-update will be called with the list of refs that have been updated. -This can be used to implement any repository wide cleanup tasks. - -The exit code from this hook invocation is ignored; the only thing -left for 'git-receive-pack' to do at that point is to exit itself -anyway. - -This hook can be used, for example, to run `git update-server-info` -if the repository is packed and is served via a dumb transport. - - #!/bin/sh - exec git update-server-info - - -QUARANTINE ENVIRONMENT ----------------------- - -When `receive-pack` takes in objects, they are placed into a temporary -"quarantine" directory within the `$GIT_DIR/objects` directory and -migrated into the main object store only after the `pre-receive` hook -has completed. If the push fails before then, the temporary directory is -removed entirely. - -This has a few user-visible effects and caveats: - - 1. Pushes which fail due to problems with the incoming pack, missing - objects, or due to the `pre-receive` hook will not leave any - on-disk data. This is usually helpful to prevent repeated failed - pushes from filling up your disk, but can make debugging more - challenging. - - 2. Any objects created by the `pre-receive` hook will be created in - the quarantine directory (and migrated only if it succeeds). - - 3. The `pre-receive` hook MUST NOT update any refs to point to - quarantined objects. Other programs accessing the repository will - not be able to see the objects (and if the pre-receive hook fails, - those refs would become corrupted). For safety, any ref updates - from within `pre-receive` are automatically rejected. - - -SEE ALSO --------- -linkgit:git-send-pack[1], linkgit:gitnamespaces[7] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-reflog.txt b/third_party/git/Documentation/git-reflog.txt deleted file mode 100644 index ff487ff77d..0000000000 --- a/third_party/git/Documentation/git-reflog.txt +++ /dev/null @@ -1,138 +0,0 @@ -git-reflog(1) -============= - -NAME ----- -git-reflog - Manage reflog information - - -SYNOPSIS --------- -[verse] -'git reflog' <subcommand> <options> - -DESCRIPTION ------------ -The command takes various subcommands, and different options -depending on the subcommand: - -[verse] -'git reflog' ['show'] [log-options] [<ref>] -'git reflog expire' [--expire=<time>] [--expire-unreachable=<time>] - [--rewrite] [--updateref] [--stale-fix] - [--dry-run | -n] [--verbose] [--all [--single-worktree] | <refs>...] -'git reflog delete' [--rewrite] [--updateref] - [--dry-run | -n] [--verbose] ref@\{specifier\}... -'git reflog exists' <ref> - -Reference logs, or "reflogs", record when the tips of branches and -other references were updated in the local repository. Reflogs are -useful in various Git commands, to specify the old value of a -reference. For example, `HEAD@{2}` means "where HEAD used to be two -moves ago", `master@{one.week.ago}` means "where master used to point -to one week ago in this local repository", and so on. See -linkgit:gitrevisions[7] for more details. - -This command manages the information recorded in the reflogs. - -The "show" subcommand (which is also the default, in the absence of -any subcommands) shows the log of the reference provided in the -command-line (or `HEAD`, by default). The reflog covers all recent -actions, and in addition the `HEAD` reflog records branch switching. -`git reflog show` is an alias for `git log -g --abbrev-commit ---pretty=oneline`; see linkgit:git-log[1] for more information. - -The "expire" subcommand prunes older reflog entries. Entries older -than `expire` time, or entries older than `expire-unreachable` time -and not reachable from the current tip, are removed from the reflog. -This is typically not used directly by end users -- instead, see -linkgit:git-gc[1]. - -The "delete" subcommand deletes single entries from the reflog. Its -argument must be an _exact_ entry (e.g. "`git reflog delete -master@{2}`"). This subcommand is also typically not used directly by -end users. - -The "exists" subcommand checks whether a ref has a reflog. It exits -with zero status if the reflog exists, and non-zero status if it does -not. - -OPTIONS -------- - -Options for `show` -~~~~~~~~~~~~~~~~~~ - -`git reflog show` accepts any of the options accepted by `git log`. - - -Options for `expire` -~~~~~~~~~~~~~~~~~~~~ - ---all:: - Process the reflogs of all references. - ---single-worktree:: - By default when `--all` is specified, reflogs from all working - trees are processed. This option limits the processing to reflogs - from the current working tree only. - ---expire=<time>:: - Prune entries older than the specified time. If this option is - not specified, the expiration time is taken from the - configuration setting `gc.reflogExpire`, which in turn - defaults to 90 days. `--expire=all` prunes entries regardless - of their age; `--expire=never` turns off pruning of reachable - entries (but see `--expire-unreachable`). - ---expire-unreachable=<time>:: - Prune entries older than `<time>` that are not reachable from - the current tip of the branch. If this option is not - specified, the expiration time is taken from the configuration - setting `gc.reflogExpireUnreachable`, which in turn defaults - to 30 days. `--expire-unreachable=all` prunes unreachable - entries regardless of their age; `--expire-unreachable=never` - turns off early pruning of unreachable entries (but see - `--expire`). - ---updateref:: - Update the reference to the value of the top reflog entry (i.e. - <ref>@\{0\}) if the previous top entry was pruned. (This - option is ignored for symbolic references.) - ---rewrite:: - If a reflog entry's predecessor is pruned, adjust its "old" - SHA-1 to be equal to the "new" SHA-1 field of the entry that - now precedes it. - ---stale-fix:: - Prune any reflog entries that point to "broken commits". A - broken commit is a commit that is not reachable from any of - the reference tips and that refers, directly or indirectly, to - a missing commit, tree, or blob object. -+ -This computation involves traversing all the reachable objects, i.e. it -has the same cost as 'git prune'. It is primarily intended to fix -corruption caused by garbage collecting using older versions of Git, -which didn't protect objects referred to by reflogs. - --n:: ---dry-run:: - Do not actually prune any entries; just show what would have - been pruned. - ---verbose:: - Print extra information on screen. - - -Options for `delete` -~~~~~~~~~~~~~~~~~~~~ - -`git reflog delete` accepts options `--updateref`, `--rewrite`, `-n`, -`--dry-run`, and `--verbose`, with the same meanings as when they are -used with `expire`. - - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-remote-ext.txt b/third_party/git/Documentation/git-remote-ext.txt deleted file mode 100644 index 88ea7e1cc0..0000000000 --- a/third_party/git/Documentation/git-remote-ext.txt +++ /dev/null @@ -1,125 +0,0 @@ -git-remote-ext(1) -================= - -NAME ----- -git-remote-ext - Bridge smart transport to external command. - -SYNOPSIS --------- -[verse] -git remote add <nick> "ext::<command>[ <arguments>...]" - -DESCRIPTION ------------ -This remote helper uses the specified '<command>' to connect -to a remote Git server. - -Data written to stdin of the specified '<command>' is assumed -to be sent to a git:// server, git-upload-pack, git-receive-pack -or git-upload-archive (depending on situation), and data read -from stdout of <command> is assumed to be received from -the same service. - -Command and arguments are separated by an unescaped space. - -The following sequences have a special meaning: - -'% ':: - Literal space in command or argument. - -'%%':: - Literal percent sign. - -'%s':: - Replaced with name (receive-pack, upload-pack, or - upload-archive) of the service Git wants to invoke. - -'%S':: - Replaced with long name (git-receive-pack, - git-upload-pack, or git-upload-archive) of the service - Git wants to invoke. - -'%G' (must be the first characters in an argument):: - This argument will not be passed to '<command>'. Instead, it - will cause the helper to start by sending git:// service requests to - the remote side with the service field set to an appropriate value and - the repository field set to rest of the argument. Default is not to send - such a request. -+ -This is useful if remote side is git:// server accessed over -some tunnel. - -'%V' (must be first characters in argument):: - This argument will not be passed to '<command>'. Instead it sets - the vhost field in the git:// service request (to rest of the argument). - Default is not to send vhost in such request (if sent). - -ENVIRONMENT VARIABLES ---------------------- - -GIT_TRANSLOOP_DEBUG:: - If set, prints debugging information about various reads/writes. - -ENVIRONMENT VARIABLES PASSED TO COMMAND ---------------------------------------- - -GIT_EXT_SERVICE:: - Set to long name (git-upload-pack, etc...) of service helper needs - to invoke. - -GIT_EXT_SERVICE_NOPREFIX:: - Set to long name (upload-pack, etc...) of service helper needs - to invoke. - - -EXAMPLES --------- -This remote helper is transparently used by Git when -you use commands such as "git fetch <URL>", "git clone <URL>", -, "git push <URL>" or "git remote add <nick> <URL>", where <URL> -begins with `ext::`. Examples: - -"ext::ssh -i /home/foo/.ssh/somekey user@host.example %S 'foo/repo'":: - Like host.example:foo/repo, but use /home/foo/.ssh/somekey as - keypair and user as user on remote side. This avoids needing to - edit .ssh/config. - -"ext::socat -t3600 - ABSTRACT-CONNECT:/git-server %G/somerepo":: - Represents repository with path /somerepo accessible over - git protocol at abstract namespace address /git-server. - -"ext::git-server-alias foo %G/repo":: - Represents a repository with path /repo accessed using the - helper program "git-server-alias foo". The path to the - repository and type of request are not passed on the command - line but as part of the protocol stream, as usual with git:// - protocol. - -"ext::git-server-alias foo %G/repo %Vfoo":: - Represents a repository with path /repo accessed using the - helper program "git-server-alias foo". The hostname for the - remote server passed in the protocol stream will be "foo" - (this allows multiple virtual Git servers to share a - link-level address). - -"ext::git-server-alias foo %G/repo% with% spaces %Vfoo":: - Represents a repository with path `/repo with spaces` accessed - using the helper program "git-server-alias foo". The hostname for - the remote server passed in the protocol stream will be "foo" - (this allows multiple virtual Git servers to share a - link-level address). - -"ext::git-ssl foo.example /bar":: - Represents a repository accessed using the helper program - "git-ssl foo.example /bar". The type of request can be - determined by the helper using environment variables (see - above). - -SEE ALSO --------- -linkgit:gitremote-helpers[7] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-remote-fd.txt b/third_party/git/Documentation/git-remote-fd.txt deleted file mode 100644 index 0451ceb8a2..0000000000 --- a/third_party/git/Documentation/git-remote-fd.txt +++ /dev/null @@ -1,59 +0,0 @@ -git-remote-fd(1) -================ - -NAME ----- -git-remote-fd - Reflect smart transport stream back to caller - -SYNOPSIS --------- -"fd::<infd>[,<outfd>][/<anything>]" (as URL) - -DESCRIPTION ------------ -This helper uses specified file descriptors to connect to a remote Git server. -This is not meant for end users but for programs and scripts calling git -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-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. - -It is assumed that any handshaking procedures have already been completed -(such as sending service request for git://) before this helper is started. - -<anything> can be any string. It is ignored. It is meant for providing -information to user in the URL in case that URL is displayed in some -context. - -ENVIRONMENT VARIABLES ---------------------- -GIT_TRANSLOOP_DEBUG:: - If set, prints debugging information about various reads/writes. - -EXAMPLES --------- -`git fetch fd::17 master`:: - Fetch master, using file descriptor #17 to communicate with - git-upload-pack. - -`git fetch fd::17/foo master`:: - Same as above. - -`git push fd::7,8 master (as URL)`:: - Push master, using file descriptor #7 to read data from - git-receive-pack and file descriptor #8 to write data to - same service. - -`git push fd::7,8/bar master`:: - Same as above. - -SEE ALSO --------- -linkgit:gitremote-helpers[7] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-remote-helpers.txto b/third_party/git/Documentation/git-remote-helpers.txto deleted file mode 100644 index 6f353ebfd3..0000000000 --- a/third_party/git/Documentation/git-remote-helpers.txto +++ /dev/null @@ -1,9 +0,0 @@ -git-remote-helpers -================== - -This document has been moved to linkgit:gitremote-helpers[7]. - -Please let the owners of the referring site know so that they can update the -link you clicked to get here. - -Thanks. diff --git a/third_party/git/Documentation/git-remote.txt b/third_party/git/Documentation/git-remote.txt deleted file mode 100644 index 9659abbf8e..0000000000 --- a/third_party/git/Documentation/git-remote.txt +++ /dev/null @@ -1,256 +0,0 @@ -git-remote(1) -============= - -NAME ----- -git-remote - Manage set of tracked repositories - - -SYNOPSIS --------- -[verse] -'git remote' [-v | --verbose] -'git remote add' [-t <branch>] [-m <master>] [-f] [--[no-]tags] [--mirror=<fetch|push>] <name> <url> -'git remote rename' <old> <new> -'git remote remove' <name> -'git remote set-head' <name> (-a | --auto | -d | --delete | <branch>) -'git remote set-branches' [--add] <name> <branch>... -'git remote get-url' [--push] [--all] <name> -'git remote set-url' [--push] <name> <newurl> [<oldurl>] -'git remote set-url --add' [--push] <name> <newurl> -'git remote set-url --delete' [--push] <name> <url> -'git remote' [-v | --verbose] 'show' [-n] <name>... -'git remote prune' [-n | --dry-run] <name>... -'git remote' [-v | --verbose] 'update' [-p | --prune] [(<group> | <remote>)...] - -DESCRIPTION ------------ - -Manage the set of repositories ("remotes") whose branches you track. - - -OPTIONS -------- - --v:: ---verbose:: - Be a little more verbose and show remote url after name. - NOTE: This must be placed between `remote` and `subcommand`. - - -COMMANDS --------- - -With no arguments, shows a list of existing remotes. Several -subcommands are available to perform operations on the remotes. - -'add':: - -Adds a remote named <name> for the repository at -<url>. The command `git fetch <name>` can then be used to create and -update remote-tracking branches <name>/<branch>. -+ -With `-f` option, `git fetch <name>` is run immediately after -the remote information is set up. -+ -With `--tags` option, `git fetch <name>` imports every tag from the -remote repository. -+ -With `--no-tags` option, `git fetch <name>` does not import tags from -the remote repository. -+ -By default, only tags on fetched branches are imported -(see linkgit:git-fetch[1]). -+ -With `-t <branch>` option, instead of the default glob -refspec for the remote to track all branches under -the `refs/remotes/<name>/` namespace, a refspec to track only `<branch>` -is created. You can give more than one `-t <branch>` to track -multiple branches without grabbing all branches. -+ -With `-m <master>` option, a symbolic-ref `refs/remotes/<name>/HEAD` is set -up to point at remote's `<master>` branch. See also the set-head command. -+ -When a fetch mirror is created with `--mirror=fetch`, the refs will not -be stored in the 'refs/remotes/' namespace, but rather everything in -'refs/' on the remote will be directly mirrored into 'refs/' in the -local repository. This option only makes sense in bare repositories, -because a fetch would overwrite any local commits. -+ -When a push mirror is created with `--mirror=push`, then `git push` -will always behave as if `--mirror` was passed. - -'rename':: - -Rename the remote named <old> to <new>. All remote-tracking branches and -configuration settings for the remote are updated. -+ -In case <old> and <new> are the same, and <old> is a file under -`$GIT_DIR/remotes` or `$GIT_DIR/branches`, the remote is converted to -the configuration file format. - -'remove':: -'rm':: - -Remove the remote named <name>. All remote-tracking branches and -configuration settings for the remote are removed. - -'set-head':: - -Sets or deletes the default branch (i.e. the target of the -symbolic-ref `refs/remotes/<name>/HEAD`) for -the named remote. Having a default branch for a remote is not required, -but allows the name of the remote to be specified in lieu of a specific -branch. For example, if the default branch for `origin` is set to -`master`, then `origin` may be specified wherever you would normally -specify `origin/master`. -+ -With `-d` or `--delete`, the symbolic ref `refs/remotes/<name>/HEAD` is deleted. -+ -With `-a` or `--auto`, the remote is queried to determine its `HEAD`, then the -symbolic-ref `refs/remotes/<name>/HEAD` is set to the same branch. e.g., if the remote -`HEAD` is pointed at `next`, "`git remote set-head origin -a`" will set -the symbolic-ref `refs/remotes/origin/HEAD` to `refs/remotes/origin/next`. This will -only work if `refs/remotes/origin/next` already exists; if not it must be -fetched first. -+ -Use `<branch>` to set the symbolic-ref `refs/remotes/<name>/HEAD` explicitly. e.g., "git -remote set-head origin master" will set the symbolic-ref `refs/remotes/origin/HEAD` to -`refs/remotes/origin/master`. This will only work if -`refs/remotes/origin/master` already exists; if not it must be fetched first. -+ - -'set-branches':: - -Changes the list of branches tracked by the named remote. -This can be used to track a subset of the available remote branches -after the initial setup for a remote. -+ -The named branches will be interpreted as if specified with the -`-t` option on the 'git remote add' command line. -+ -With `--add`, instead of replacing the list of currently tracked -branches, adds to that list. - -'get-url':: - -Retrieves the URLs for a remote. Configurations for `insteadOf` and -`pushInsteadOf` are expanded here. By default, only the first URL is listed. -+ -With `--push`, push URLs are queried rather than fetch URLs. -+ -With `--all`, all URLs for the remote will be listed. - -'set-url':: - -Changes URLs for the remote. Sets first URL for remote <name> that matches -regex <oldurl> (first URL if no <oldurl> is given) to <newurl>. If -<oldurl> doesn't match any URL, an error occurs and nothing is changed. -+ -With `--push`, push URLs are manipulated instead of fetch URLs. -+ -With `--add`, instead of changing existing URLs, new URL is added. -+ -With `--delete`, instead of changing existing URLs, all URLs matching -regex <url> are deleted for remote <name>. Trying to delete all -non-push URLs is an error. -+ -Note that the push URL and the fetch URL, even though they can -be set differently, must still refer to the same place. What you -pushed to the push URL should be what you would see if you -immediately fetched from the fetch URL. If you are trying to -fetch from one place (e.g. your upstream) and push to another (e.g. -your publishing repository), use two separate remotes. - - -'show':: - -Gives some information about the remote <name>. -+ -With `-n` option, the remote heads are not queried first with -`git ls-remote <name>`; cached information is used instead. - -'prune':: - -Deletes stale references associated with <name>. By default, stale -remote-tracking branches under <name> are deleted, but depending on -global configuration and the configuration of the remote we might even -prune local tags that haven't been pushed there. Equivalent to `git -fetch --prune <name>`, except that no new references will be fetched. -+ -See the PRUNING section of linkgit:git-fetch[1] for what it'll prune -depending on various configuration. -+ -With `--dry-run` option, report what branches will be pruned, but do not -actually prune them. - -'update':: - -Fetch updates for remotes or remote groups in the repository as defined by -remotes.<group>. If neither group nor remote is specified on the command line, -the configuration parameter remotes.default will be used; if -remotes.default is not defined, all remotes which do not have the -configuration parameter remote.<name>.skipDefaultUpdate set to true will -be updated. (See linkgit:git-config[1]). -+ -With `--prune` option, run pruning against all the remotes that are updated. - - -DISCUSSION ----------- - -The remote configuration is achieved using the `remote.origin.url` and -`remote.origin.fetch` configuration variables. (See -linkgit:git-config[1]). - -EXAMPLES --------- - -* Add a new remote, fetch, and check out a branch from it -+ ------------- -$ git remote -origin -$ git branch -r - origin/HEAD -> origin/master - origin/master -$ git remote add staging git://git.kernel.org/.../gregkh/staging.git -$ git remote -origin -staging -$ git fetch staging -... -From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging - * [new branch] master -> staging/master - * [new branch] staging-linus -> staging/staging-linus - * [new branch] staging-next -> staging/staging-next -$ git branch -r - origin/HEAD -> origin/master - origin/master - staging/master - staging/staging-linus - staging/staging-next -$ git switch -c staging staging/master -... ------------- - -* Imitate 'git clone' but track only selected branches -+ ------------- -$ mkdir project.git -$ cd project.git -$ git init -$ git remote add -f -t master -m master origin git://example.com/git.git/ -$ git merge origin ------------- - - -SEE ALSO --------- -linkgit:git-fetch[1] -linkgit:git-branch[1] -linkgit:git-config[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-repack.txt b/third_party/git/Documentation/git-repack.txt deleted file mode 100644 index 92f146d27d..0000000000 --- a/third_party/git/Documentation/git-repack.txt +++ /dev/null @@ -1,188 +0,0 @@ -git-repack(1) -============= - -NAME ----- -git-repack - Pack unpacked objects in a repository - - -SYNOPSIS --------- -[verse] -'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [-b] [--window=<n>] [--depth=<n>] [--threads=<n>] [--keep-pack=<pack-name>] - -DESCRIPTION ------------ - -This command is used to combine all objects that do not currently -reside in a "pack", into a pack. It can also be used to re-organize -existing packs into a single, more efficient pack. - -A pack is a collection of objects, individually compressed, with -delta compression applied, stored in a single file, with an -associated index file. - -Packs are used to reduce the load on mirror systems, backup -engines, disk storage, etc. - -OPTIONS -------- - --a:: - Instead of incrementally packing the unpacked objects, - pack everything referenced into a single pack. - Especially useful when packing a repository that is used - for private development. Use - with `-d`. This will clean up the objects that `git prune` - leaves behind, but `git fsck --full --dangling` shows as - dangling. -+ -Note that users fetching over dumb protocols will have to fetch the -whole new pack in order to get any contained object, no matter how many -other objects in that pack they already have locally. -+ -Promisor packfiles are repacked separately: if there are packfiles that -have an associated ".promisor" file, these packfiles will be repacked -into another separate pack, and an empty ".promisor" file corresponding -to the new separate pack will be written. - --A:: - Same as `-a`, unless `-d` is used. Then any unreachable - objects in a previous pack become loose, unpacked objects, - instead of being left in the old pack. Unreachable objects - are never intentionally added to a pack, even when repacking. - This option prevents unreachable objects from being immediately - deleted by way of being left in the old pack and then - removed. Instead, the loose unreachable objects - will be pruned according to normal expiry rules - with the next 'git gc' invocation. See linkgit:git-gc[1]. - --d:: - After packing, if the newly created packs make some - existing packs redundant, remove the redundant packs. - Also run 'git prune-packed' to remove redundant - loose object files. - --l:: - Pass the `--local` option to 'git pack-objects'. See - linkgit:git-pack-objects[1]. - --f:: - Pass the `--no-reuse-delta` option to `git-pack-objects`, see - linkgit:git-pack-objects[1]. - --F:: - Pass the `--no-reuse-object` option to `git-pack-objects`, see - linkgit:git-pack-objects[1]. - --q:: - Pass the `-q` option to 'git pack-objects'. See - linkgit:git-pack-objects[1]. - --n:: - Do not update the server information with - 'git update-server-info'. This option skips - updating local catalog files needed to publish - this repository (or a direct copy of it) - over HTTP or FTP. See linkgit:git-update-server-info[1]. - ---window=<n>:: ---depth=<n>:: - These two options affect how the objects contained in the pack are - stored using delta compression. The objects are first internally - sorted by type, size and optionally names and compared against the - other objects within `--window` to see if using delta compression saves - space. `--depth` limits the maximum delta depth; making it too deep - affects the performance on the unpacker side, because delta data needs - to be applied that many times to get to the necessary object. -+ -The default value for --window is 10 and --depth is 50. The maximum -depth is 4095. - ---threads=<n>:: - This option is passed through to `git pack-objects`. - ---window-memory=<n>:: - This option provides an additional limit on top of `--window`; - the window size will dynamically scale down so as to not take - up more than '<n>' bytes in memory. This is useful in - repositories with a mix of large and small objects to not run - out of memory with a large window, but still be able to take - advantage of the large window for the smaller objects. The - size can be suffixed with "k", "m", or "g". - `--window-memory=0` makes memory usage unlimited. The default - is taken from the `pack.windowMemory` configuration variable. - Note that the actual memory usage will be the limit multiplied - by the number of threads used by linkgit:git-pack-objects[1]. - ---max-pack-size=<n>:: - Maximum size of each output pack file. The size can be suffixed with - "k", "m", or "g". The minimum size allowed is limited to 1 MiB. - If specified, multiple packfiles may be created, which also - prevents the creation of a bitmap index. - The default is unlimited, unless the config variable - `pack.packSizeLimit` is set. - --b:: ---write-bitmap-index:: - Write a reachability bitmap index as part of the repack. This - only makes sense when used with `-a` or `-A`, as the bitmaps - must be able to refer to all reachable objects. This option - overrides the setting of `repack.writeBitmaps`. This option - has no effect if multiple packfiles are created. - ---pack-kept-objects:: - Include objects in `.keep` files when repacking. Note that we - still do not delete `.keep` packs after `pack-objects` finishes. - This means that we may duplicate objects, but this makes the - option safe to use when there are concurrent pushes or fetches. - This option is generally only useful if you are writing bitmaps - with `-b` or `repack.writeBitmaps`, as it ensures that the - bitmapped packfile has the necessary objects. - ---keep-pack=<pack-name>:: - Exclude the given pack from repacking. This is the equivalent - of having `.keep` file on the pack. `<pack-name>` is the - pack file name without leading directory (e.g. `pack-123.pack`). - The option could be specified multiple times to keep multiple - packs. - ---unpack-unreachable=<when>:: - When loosening unreachable objects, do not bother loosening any - objects older than `<when>`. This can be used to optimize out - 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). - --i:: ---delta-islands:: - Pass the `--delta-islands` option to `git-pack-objects`, see - linkgit:git-pack-objects[1]. - -Configuration -------------- - -By default, the command passes `--delta-base-offset` option to -'git pack-objects'; this typically results in slightly smaller packs, -but the generated packs are incompatible with versions of Git older than -version 1.4.4. If you need to share your repository with such ancient Git -versions, either directly or via the dumb http protocol, then you -need to set the configuration variable `repack.UseDeltaBaseOffset` to -"false" and repack. Access from old Git versions over the native protocol -is unaffected by this option as the conversion is performed on the fly -as needed in that case. - -SEE ALSO --------- -linkgit:git-pack-objects[1] -linkgit:git-prune-packed[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-replace.txt b/third_party/git/Documentation/git-replace.txt deleted file mode 100644 index 246dc9943c..0000000000 --- a/third_party/git/Documentation/git-replace.txt +++ /dev/null @@ -1,161 +0,0 @@ -git-replace(1) -============== - -NAME ----- -git-replace - Create, list, delete refs to replace objects - -SYNOPSIS --------- -[verse] -'git replace' [-f] <object> <replacement> -'git replace' [-f] --edit <object> -'git replace' [-f] --graft <commit> [<parent>...] -'git replace' [-f] --convert-graft-file -'git replace' -d <object>... -'git replace' [--format=<format>] [-l [<pattern>]] - -DESCRIPTION ------------ -Adds a 'replace' reference in `refs/replace/` namespace. - -The name of the 'replace' reference is the SHA-1 of the object that is -replaced. The content of the 'replace' reference is the SHA-1 of the -replacement object. - -The replaced object and the replacement object must be of the same type. -This restriction can be bypassed using `-f`. - -Unless `-f` is given, the 'replace' reference must not yet exist. - -There is no other restriction on the replaced and replacement objects. -Merge commits can be replaced by non-merge commits and vice versa. - -Replacement references will be used by default by all Git commands -except those doing reachability traversal (prune, pack transfer and -fsck). - -It is possible to disable use of replacement references for any -command using the `--no-replace-objects` option just after 'git'. - -For example if commit 'foo' has been replaced by commit 'bar': - ------------------------------------------------- -$ git --no-replace-objects cat-file commit foo ------------------------------------------------- - -shows information about commit 'foo', while: - ------------------------------------------------- -$ git cat-file commit foo ------------------------------------------------- - -shows information about commit 'bar'. - -The `GIT_NO_REPLACE_OBJECTS` environment variable can be set to -achieve the same effect as the `--no-replace-objects` option. - -OPTIONS -------- --f:: ---force:: - If an existing replace ref for the same object exists, it will - be overwritten (instead of failing). - --d:: ---delete:: - Delete existing replace refs for the given objects. - ---edit <object>:: - Edit an object's content interactively. The existing content - for <object> is pretty-printed into a temporary file, an - editor is launched on the file, and the result is parsed to - create a new object of the same type as <object>. A - replacement ref is then created to replace <object> with the - newly created object. See linkgit:git-var[1] for details about - how the editor will be chosen. - ---raw:: - When editing, provide the raw object contents rather than - pretty-printed ones. Currently this only affects trees, which - will be shown in their binary form. This is harder to work with, - but can help when repairing a tree that is so corrupted it - cannot be pretty-printed. Note that you may need to configure - your editor to cleanly read and write binary data. - ---graft <commit> [<parent>...]:: - Create a graft commit. A new commit is created with the same - content as <commit> except that its parents will be - [<parent>...] instead of <commit>'s parents. A replacement ref - is then created to replace <commit> with the newly created - commit. Use `--convert-graft-file` to convert a - `$GIT_DIR/info/grafts` file and use replace refs instead. - ---convert-graft-file:: - Creates graft commits for all entries in `$GIT_DIR/info/grafts` - and deletes that file upon success. The purpose is to help users - with transitioning off of the now-deprecated graft file. - --l <pattern>:: ---list <pattern>:: - List replace refs for objects that match the given pattern (or - all if no pattern is given). - Typing "git replace" without arguments, also lists all replace - refs. - ---format=<format>:: - When listing, use the specified <format>, which can be one of - 'short', 'medium' and 'long'. When omitted, the format - defaults to 'short'. - -FORMATS -------- - -The following format are available: - -* 'short': - <replaced sha1> -* 'medium': - <replaced sha1> -> <replacement sha1> -* 'long': - <replaced sha1> (<replaced type>) -> <replacement sha1> (<replacement type>) - -CREATING REPLACEMENT OBJECTS ----------------------------- - -linkgit:git-filter-branch[1], linkgit:git-hash-object[1] and -linkgit:git-rebase[1], among other git commands, can be used to create -replacement objects from existing objects. The `--edit` option can -also be used with 'git replace' to create a replacement object by -editing an existing object. - -If you want to replace many blobs, trees or commits that are part of a -string of commits, you may just want to create a replacement string of -commits and then only replace the commit at the tip of the target -string of commits with the commit at the tip of the replacement string -of commits. - -BUGS ----- -Comparing blobs or trees that have been replaced with those that -replace them will not work properly. And using `git reset --hard` to -go back to a replaced commit will move the branch to the replacement -commit instead of the replaced commit. - -There may be other problems when using 'git rev-list' related to -pending objects. - -SEE ALSO --------- -linkgit:git-hash-object[1] -linkgit:git-filter-branch[1] -linkgit:git-rebase[1] -linkgit:git-tag[1] -linkgit:git-branch[1] -linkgit:git-commit[1] -linkgit:git-var[1] -linkgit:git[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-request-pull.txt b/third_party/git/Documentation/git-request-pull.txt deleted file mode 100644 index 4d4392d0f8..0000000000 --- a/third_party/git/Documentation/git-request-pull.txt +++ /dev/null @@ -1,79 +0,0 @@ -git-request-pull(1) -=================== - -NAME ----- -git-request-pull - Generates a summary of pending changes - -SYNOPSIS --------- -[verse] -'git request-pull' [-p] <start> <url> [<end>] - -DESCRIPTION ------------ - -Generate a request asking your upstream project to pull changes into -their tree. The request, printed to the standard output, -begins with the branch description, summarizes -the changes and indicates from where they can be pulled. - -The upstream project is expected to have the commit named by -`<start>` and the output asks it to integrate the changes you made -since that commit, up to the commit named by `<end>`, by visiting -the repository named by `<url>`. - - -OPTIONS -------- --p:: - Include patch text in the output. - -<start>:: - Commit to start at. This names a commit that is already in - the upstream history. - -<url>:: - The repository URL to be pulled from. - -<end>:: - Commit to end at (defaults to HEAD). This names the commit - at the tip of the history you are asking to be pulled. -+ -When the repository named by `<url>` has the commit at a tip of a -ref that is different from the ref you have locally, you can use the -`<local>:<remote>` syntax, to have its local name, a colon `:`, and -its remote name. - - -EXAMPLES --------- - -Imagine that you built your work on your `master` branch on top of -the `v1.0` release, and want it to be integrated to the project. -First you push that change to your public repository for others to -see: - - git push https://git.ko.xz/project master - -Then, you run this command: - - git request-pull v1.0 https://git.ko.xz/project master - -which will produce a request to the upstream, summarizing the -changes between the `v1.0` release and your `master`, to pull it -from your public repository. - -If you pushed your change to a branch whose name is different from -the one you have locally, e.g. - - git push https://git.ko.xz/project master:for-linus - -then you can ask that to be pulled with - - git request-pull v1.0 https://git.ko.xz/project master:for-linus - - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-rerere.txt b/third_party/git/Documentation/git-rerere.txt deleted file mode 100644 index 4cfc883378..0000000000 --- a/third_party/git/Documentation/git-rerere.txt +++ /dev/null @@ -1,222 +0,0 @@ -git-rerere(1) -============= - -NAME ----- -git-rerere - Reuse recorded resolution of conflicted merges - -SYNOPSIS --------- -[verse] -'git rerere' ['clear'|'forget' <pathspec>|'diff'|'remaining'|'status'|'gc'] - -DESCRIPTION ------------ - -In a workflow employing relatively long lived topic branches, -the developer sometimes needs to resolve the same conflicts over -and over again until the topic branches are done (either merged -to the "release" branch, or sent out and accepted upstream). - -This command assists the developer in this process by recording -conflicted automerge results and corresponding hand resolve results -on the initial manual merge, and applying previously recorded -hand resolutions to their corresponding automerge results. - -[NOTE] -You need to set the configuration variable `rerere.enabled` in order to -enable this command. - - -COMMANDS --------- - -Normally, 'git rerere' is run without arguments or user-intervention. -However, it has several commands that allow it to interact with -its working state. - -'clear':: - -Reset the metadata used by rerere if a merge resolution is to be -aborted. Calling 'git am [--skip|--abort]' or 'git rebase [--skip|--abort]' -will automatically invoke this command. - -'forget' <pathspec>:: - -Reset the conflict resolutions which rerere has recorded for the current -conflict in <pathspec>. - -'diff':: - -Display diffs for the current state of the resolution. It is -useful for tracking what has changed while the user is resolving -conflicts. Additional arguments are passed directly to the system -'diff' command installed in PATH. - -'status':: - -Print paths with conflicts whose merge resolution rerere will record. - -'remaining':: - -Print paths with conflicts that have not been autoresolved by rerere. -This includes paths whose resolutions cannot be tracked by rerere, -such as conflicting submodules. - -'gc':: - -Prune records of conflicted merges that -occurred a long time ago. By default, unresolved conflicts older -than 15 days and resolved conflicts older than 60 -days are pruned. These defaults are controlled via the -`gc.rerereUnresolved` and `gc.rerereResolved` configuration -variables respectively. - - -DISCUSSION ----------- - -When your topic branch modifies an overlapping area that your -master branch (or upstream) touched since your topic branch -forked from it, you may want to test it with the latest master, -even before your topic branch is ready to be pushed upstream: - ------------- - o---*---o topic - / - o---o---o---*---o---o master ------------- - -For such a test, you need to merge master and topic somehow. -One way to do it is to pull master into the topic branch: - ------------- - $ git switch topic - $ git merge master - - o---*---o---+ topic - / / - o---o---o---*---o---o master ------------- - -The commits marked with `*` touch the same area in the same -file; you need to resolve the conflicts when creating the commit -marked with `+`. Then you can test the result to make sure your -work-in-progress still works with what is in the latest master. - -After this test merge, there are two ways to continue your work -on the topic. The easiest is to build on top of the test merge -commit `+`, and when your work in the topic branch is finally -ready, pull the topic branch into master, and/or ask the -upstream to pull from you. By that time, however, the master or -the upstream might have been advanced since the test merge `+`, -in which case the final commit graph would look like this: - ------------- - $ git switch topic - $ git merge master - $ ... work on both topic and master branches - $ git switch master - $ git merge topic - - o---*---o---+---o---o topic - / / \ - o---o---o---*---o---o---o---o---+ master ------------- - -When your topic branch is long-lived, however, your topic branch -would end up having many such "Merge from master" commits on it, -which would unnecessarily clutter the development history. -Readers of the Linux kernel mailing list may remember that Linus -complained about such too frequent test merges when a subsystem -maintainer asked to pull from a branch full of "useless merges". - -As an alternative, to keep the topic branch clean of test -merges, you could blow away the test merge, and keep building on -top of the tip before the test merge: - ------------- - $ git switch topic - $ git merge master - $ git reset --hard HEAD^ ;# rewind the test merge - $ ... work on both topic and master branches - $ git switch master - $ git merge topic - - o---*---o-------o---o topic - / \ - o---o---o---*---o---o---o---o---+ master ------------- - -This would leave only one merge commit when your topic branch is -finally ready and merged into the master branch. This merge -would require you to resolve the conflict, introduced by the -commits marked with `*`. However, this conflict is often the -same conflict you resolved when you created the test merge you -blew away. 'git rerere' helps you resolve this final -conflicted merge using the information from your earlier hand -resolve. - -Running the 'git rerere' command immediately after a conflicted -automerge records the conflicted working tree files, with the -usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in -them. Later, after you are done resolving the conflicts, -running 'git rerere' again will record the resolved state of these -files. Suppose you did this when you created the test merge of -master into the topic branch. - -Next time, after seeing the same conflicted automerge, -running 'git rerere' will perform a three-way merge between the -earlier conflicted automerge, the earlier manual resolution, and -the current conflicted automerge. -If this three-way merge resolves cleanly, the result is written -out to your working tree file, so you do not have to manually -resolve it. Note that 'git rerere' leaves the index file alone, -so you still need to do the final sanity checks with `git diff` -(or `git diff -c`) and 'git add' when you are satisfied. - -As a convenience measure, 'git merge' automatically invokes -'git rerere' upon exiting with a failed automerge and 'git rerere' -records the hand resolve when it is a new conflict, or reuses the earlier hand -resolve when it is not. 'git commit' also invokes 'git rerere' -when committing a merge result. What this means is that you do -not have to do anything special yourself (besides enabling -the rerere.enabled config variable). - -In our example, when you do the test merge, the manual -resolution is recorded, and it will be reused when you do the -actual merge later with the updated master and topic branch, as long -as the recorded resolution is still applicable. - -The information 'git rerere' records is also used when running -'git rebase'. After blowing away the test merge and continuing -development on the topic branch: - ------------- - o---*---o-------o---o topic - / - o---o---o---*---o---o---o---o master - - $ git rebase master topic - - o---*---o-------o---o topic - / - o---o---o---*---o---o---o---o master ------------- - -you could run `git rebase master topic`, to bring yourself -up to date before your topic is ready to be sent upstream. -This would result in falling back to a three-way merge, and it -would conflict the same way as the test merge you resolved earlier. -'git rerere' will be run by 'git rebase' to help you resolve this -conflict. - -[NOTE] 'git rerere' relies on the conflict markers in the file to -detect the conflict. If the file already contains lines that look the -same as lines with conflict markers, 'git rerere' may fail to record a -conflict resolution. To work around this, the `conflict-marker-size` -setting in linkgit:gitattributes[5] can be used. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-reset.txt b/third_party/git/Documentation/git-reset.txt deleted file mode 100644 index 97e0544d9e..0000000000 --- a/third_party/git/Documentation/git-reset.txt +++ /dev/null @@ -1,475 +0,0 @@ -git-reset(1) -============ - -NAME ----- -git-reset - Reset current HEAD to the specified state - -SYNOPSIS --------- -[verse] -'git reset' [-q] [<tree-ish>] [--] <paths>... -'git reset' (--patch | -p) [<tree-ish>] [--] [<paths>...] -'git reset' [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<commit>] - -DESCRIPTION ------------ -In the first and second form, copy entries from `<tree-ish>` to the index. -In the third form, set the current branch head (`HEAD`) to `<commit>`, -optionally modifying index and working tree to match. -The `<tree-ish>`/`<commit>` defaults to `HEAD` in all forms. - -'git reset' [-q] [<tree-ish>] [--] <paths>...:: - This form resets the index entries for all `<paths>` to their - state at `<tree-ish>`. (It does not affect the working tree or - the current branch.) -+ -This means that `git reset <paths>` is the opposite of `git add -<paths>`. This command is equivalent to -`git restore [--source=<tree-ish>] --staged <paths>...`. -+ -After running `git reset <paths>` to update the index entry, you can -use linkgit:git-restore[1] to check the contents out of the index to -the working tree. Alternatively, using linkgit:git-restore[1] -and specifying a commit with `--source`, you -can copy the contents of a path out of a commit to the index and to the -working tree in one go. - -'git reset' (--patch | -p) [<tree-ish>] [--] [<paths>...]:: - Interactively select hunks in the difference between the index - and `<tree-ish>` (defaults to `HEAD`). The chosen hunks are applied - in reverse to the index. -+ -This means that `git reset -p` is the opposite of `git add -p`, i.e. -you can use it to selectively reset hunks. See the ``Interactive Mode'' -section of linkgit:git-add[1] to learn how to operate the `--patch` mode. - -'git reset' [<mode>] [<commit>]:: - This form resets the current branch head to `<commit>` and - possibly updates the index (resetting it to the tree of `<commit>`) and - the working tree depending on `<mode>`. If `<mode>` is omitted, - defaults to `--mixed`. The `<mode>` must be one of the following: -+ --- ---soft:: - Does not touch the index file or the working tree at all (but - resets the head to `<commit>`, just like all modes do). This leaves - all your changed files "Changes to be committed", as `git status` - would put it. - ---mixed:: - Resets the index but not the working tree (i.e., the changed files - are preserved but not marked for commit) and reports what has not - been updated. This is the default action. -+ -If `-N` is specified, removed paths are marked as intent-to-add (see -linkgit:git-add[1]). - ---hard:: - Resets the index and working tree. Any changes to tracked files in the - working tree since `<commit>` are discarded. - ---merge:: - Resets the index and updates the files in the working tree that are - different between `<commit>` and `HEAD`, but keeps those which are - different between the index and working tree (i.e. which have changes - which have not been added). - If a file that is different between `<commit>` and the index has - unstaged changes, reset is aborted. -+ -In other words, `--merge` does something like a `git read-tree -u -m <commit>`, -but carries forward unmerged index entries. - ---keep:: - Resets index entries and updates files in the working tree that are - different between `<commit>` and `HEAD`. - If a file that is different between `<commit>` and `HEAD` has local - changes, reset is aborted. --- - -See "Reset, restore and revert" in linkgit:git[1] for the differences -between the three commands. - - -OPTIONS -------- - --q:: ---quiet:: ---no-quiet:: - Be quiet, only report errors. The default behavior is set by the - `reset.quiet` config option. `--quiet` and `--no-quiet` will - override the default behavior. - - -EXAMPLES --------- - -Undo add:: -+ ------------- -$ edit <1> -$ git add frotz.c filfre.c -$ mailx <2> -$ git reset <3> -$ git pull git://info.example.com/ nitfol <4> ------------- -+ -<1> You are happily working on something, and find the changes - in these files are in good order. You do not want to see them - when you run `git diff`, because you plan to work on other files - and changes with these files are distracting. -<2> Somebody asks you to pull, and the changes sound worthy of merging. -<3> However, you already dirtied the index (i.e. your index does - not match the `HEAD` commit). But you know the pull you are going - to make does not affect `frotz.c` or `filfre.c`, so you revert the - index changes for these two files. Your changes in working tree - remain there. -<4> Then you can pull and merge, leaving `frotz.c` and `filfre.c` - changes still in the working tree. - -Undo a commit and redo:: -+ ------------- -$ git commit ... -$ git reset --soft HEAD^ <1> -$ edit <2> -$ git commit -a -c ORIG_HEAD <3> ------------- -+ -<1> This is most often done when you remembered what you - just committed is incomplete, or you misspelled your commit - message, or both. Leaves working tree as it was before "reset". -<2> Make corrections to working tree files. -<3> "reset" copies the old head to `.git/ORIG_HEAD`; redo the - commit by starting with its log message. If you do not need to - edit the message further, you can give `-C` option instead. -+ -See also the `--amend` option to linkgit:git-commit[1]. - -Undo a commit, making it a topic branch:: -+ ------------- -$ git branch topic/wip <1> -$ git reset --hard HEAD~3 <2> -$ git switch topic/wip <3> ------------- -+ -<1> You have made some commits, but realize they were premature - to be in the `master` branch. You want to continue polishing - them in a topic branch, so create `topic/wip` branch off of the - current `HEAD`. -<2> Rewind the master branch to get rid of those three commits. -<3> Switch to `topic/wip` branch and keep working. - -Undo commits permanently:: -+ ------------- -$ git commit ... -$ git reset --hard HEAD~3 <1> ------------- -+ -<1> The last three commits (`HEAD`, `HEAD^`, and `HEAD~2`) were bad - and you do not want to ever see them again. Do *not* do this if - you have already given these commits to somebody else. (See the - "RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] - for the implications of doing so.) - -Undo a merge or pull:: -+ ------------- -$ git pull <1> -Auto-merging nitfol -CONFLICT (content): Merge conflict in nitfol -Automatic merge failed; fix conflicts and then commit the result. -$ git reset --hard <2> -$ git pull . topic/branch <3> -Updating from 41223... to 13134... -Fast-forward -$ git reset --hard ORIG_HEAD <4> ------------- -+ -<1> Try to update from the upstream resulted in a lot of - conflicts; you were not ready to spend a lot of time merging - right now, so you decide to do that later. -<2> "pull" has not made merge commit, so `git reset --hard` - which is a synonym for `git reset --hard HEAD` clears the mess - from the index file and the working tree. -<3> Merge a topic branch into the current branch, which resulted - in a fast-forward. -<4> But you decided that the topic branch is not ready for public - consumption yet. "pull" or "merge" always leaves the original - tip of the current branch in `ORIG_HEAD`, so resetting hard to it - brings your index file and the working tree back to that state, - and resets the tip of the branch to that commit. - -Undo a merge or pull inside a dirty working tree:: -+ ------------- -$ git pull <1> -Auto-merging nitfol -Merge made by recursive. - nitfol | 20 +++++---- - ... -$ git reset --merge ORIG_HEAD <2> ------------- -+ -<1> Even if you may have local modifications in your - working tree, you can safely say `git pull` when you know - that the change in the other branch does not overlap with - them. -<2> After inspecting the result of the merge, you may find - that the change in the other branch is unsatisfactory. Running - `git reset --hard ORIG_HEAD` will let you go back to where you - were, but it will discard your local changes, which you do not - want. `git reset --merge` keeps your local changes. - - -Interrupted workflow:: -+ -Suppose you are interrupted by an urgent fix request while you -are in the middle of a large change. The files in your -working tree are not in any shape to be committed yet, but you -need to get to the other branch for a quick bugfix. -+ ------------- -$ git switch feature ;# you were working in "feature" branch and -$ work work work ;# got interrupted -$ git commit -a -m "snapshot WIP" <1> -$ git switch master -$ fix fix fix -$ git commit ;# commit with real log -$ git switch feature -$ git reset --soft HEAD^ ;# go back to WIP state <2> -$ git reset <3> ------------- -+ -<1> This commit will get blown away so a throw-away log message is OK. -<2> This removes the 'WIP' commit from the commit history, and sets - your working tree to the state just before you made that snapshot. -<3> At this point the index file still has all the WIP changes you - committed as 'snapshot WIP'. This updates the index to show your - WIP files as uncommitted. -+ -See also linkgit:git-stash[1]. - -Reset a single file in the index:: -+ -Suppose you have added a file to your index, but later decide you do not -want to add it to your commit. You can remove the file from the index -while keeping your changes with git reset. -+ ------------- -$ git reset -- frotz.c <1> -$ git commit -m "Commit files in index" <2> -$ git add frotz.c <3> ------------- -+ -<1> This removes the file from the index while keeping it in the working - directory. -<2> This commits all other changes in the index. -<3> Adds the file to the index again. - -Keep changes in working tree while discarding some previous commits:: -+ -Suppose you are working on something and you commit it, and then you -continue working a bit more, but now you think that what you have in -your working tree should be in another branch that has nothing to do -with what you committed previously. You can start a new branch and -reset it while keeping the changes in your working tree. -+ ------------- -$ git tag start -$ git switch -c branch1 -$ edit -$ git commit ... <1> -$ edit -$ git switch -c branch2 <2> -$ git reset --keep start <3> ------------- -+ -<1> This commits your first edits in `branch1`. -<2> In the ideal world, you could have realized that the earlier - commit did not belong to the new topic when you created and switched - to `branch2` (i.e. `git switch -c branch2 start`), but nobody is - perfect. -<3> But you can use `reset --keep` to remove the unwanted commit after - you switched to `branch2`. - -Split a commit apart into a sequence of commits:: -+ -Suppose that you have created lots of logically separate changes and committed -them together. Then, later you decide that it might be better to have each -logical chunk associated with its own commit. You can use git reset to rewind -history without changing the contents of your local files, and then successively -use `git add -p` to interactively select which hunks to include into each commit, -using `git commit -c` to pre-populate the commit message. -+ ------------- -$ git reset -N HEAD^ <1> -$ git add -p <2> -$ git diff --cached <3> -$ git commit -c HEAD@{1} <4> -... <5> -$ git add ... <6> -$ git diff --cached <7> -$ git commit ... <8> ------------- -+ -<1> First, reset the history back one commit so that we remove the original - commit, but leave the working tree with all the changes. The -N ensures - that any new files added with `HEAD` are still marked so that `git add -p` - will find them. -<2> Next, we interactively select diff hunks to add using the `git add -p` - facility. This will ask you about each diff hunk in sequence and you can - use simple commands such as "yes, include this", "No don't include this" - or even the very powerful "edit" facility. -<3> Once satisfied with the hunks you want to include, you should verify what - has been prepared for the first commit by using `git diff --cached`. This - shows all the changes that have been moved into the index and are about - to be committed. -<4> Next, commit the changes stored in the index. The `-c` option specifies to - pre-populate the commit message from the original message that you started - with in the first commit. This is helpful to avoid retyping it. The - `HEAD@{1}` is a special notation for the commit that `HEAD` used to be at - prior to the original reset commit (1 change ago). - See linkgit:git-reflog[1] for more details. You may also use any other - valid commit reference. -<5> You can repeat steps 2-4 multiple times to break the original code into - any number of commits. -<6> Now you've split out many of the changes into their own commits, and might - no longer use the patch mode of `git add`, in order to select all remaining - uncommitted changes. -<7> Once again, check to verify that you've included what you want to. You may - also wish to verify that git diff doesn't show any remaining changes to be - committed later. -<8> And finally create the final commit. - - -DISCUSSION ----------- - -The tables below show what happens when running: - ----------- -git reset --option target ----------- - -to reset the `HEAD` to another commit (`target`) with the different -reset options depending on the state of the files. - -In these tables, `A`, `B`, `C` and `D` are some different states of a -file. For example, the first line of the first table means that if a -file is in state `A` in the working tree, in state `B` in the index, in -state `C` in `HEAD` and in state `D` in the target, then `git reset --soft -target` will leave the file in the working tree in state `A` and in the -index in state `B`. It resets (i.e. moves) the `HEAD` (i.e. the tip of -the current branch, if you are on one) to `target` (which has the file -in state `D`). - -.... -working index HEAD target working index HEAD ----------------------------------------------------- - A B C D --soft A B D - --mixed A D D - --hard D D D - --merge (disallowed) - --keep (disallowed) -.... - -.... -working index HEAD target working index HEAD ----------------------------------------------------- - A B C C --soft A B C - --mixed A C C - --hard C C C - --merge (disallowed) - --keep A C C -.... - -.... -working index HEAD target working index HEAD ----------------------------------------------------- - B B C D --soft B B D - --mixed B D D - --hard D D D - --merge D D D - --keep (disallowed) -.... - -.... -working index HEAD target working index HEAD ----------------------------------------------------- - B B C C --soft B B C - --mixed B C C - --hard C C C - --merge C C C - --keep B C C -.... - -.... -working index HEAD target working index HEAD ----------------------------------------------------- - B C C D --soft B C D - --mixed B D D - --hard D D D - --merge (disallowed) - --keep (disallowed) -.... - -.... -working index HEAD target working index HEAD ----------------------------------------------------- - B C C C --soft B C C - --mixed B C C - --hard C C C - --merge B C C - --keep B C C -.... - -`reset --merge` is meant to be used when resetting out of a conflicted -merge. Any mergy operation guarantees that the working tree file that is -involved in the merge does not have a local change with respect to the index -before it starts, and that it writes the result out to the working tree. So if -we see some difference between the index and the target and also -between the index and the working tree, then it means that we are not -resetting out from a state that a mergy operation left after failing -with a conflict. That is why we disallow `--merge` option in this case. - -`reset --keep` is meant to be used when removing some of the last -commits in the current branch while keeping changes in the working -tree. If there could be conflicts between the changes in the commit we -want to remove and the changes in the working tree we want to keep, -the reset is disallowed. That's why it is disallowed if there are both -changes between the working tree and `HEAD`, and between `HEAD` and the -target. To be safe, it is also disallowed when there are unmerged -entries. - -The following tables show what happens when there are unmerged -entries: - -.... -working index HEAD target working index HEAD ----------------------------------------------------- - X U A B --soft (disallowed) - --mixed X B B - --hard B B B - --merge B B B - --keep (disallowed) -.... - -.... -working index HEAD target working index HEAD ----------------------------------------------------- - X U A A --soft (disallowed) - --mixed X A A - --hard A A A - --merge A A A - --keep (disallowed) -.... - -`X` means any state and `U` means an unmerged index. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-restore.txt b/third_party/git/Documentation/git-restore.txt deleted file mode 100644 index 1ab2e40ea9..0000000000 --- a/third_party/git/Documentation/git-restore.txt +++ /dev/null @@ -1,185 +0,0 @@ -git-restore(1) -============== - -NAME ----- -git-restore - Restore working tree files - -SYNOPSIS --------- -[verse] -'git restore' [<options>] [--source=<tree>] [--staged] [--worktree] <pathspec>... -'git restore' (-p|--patch) [<options>] [--source=<tree>] [--staged] [--worktree] [<pathspec>...] - -DESCRIPTION ------------ -Restore specified paths in the working tree with some contents from a -restore source. If a path is tracked but does not exist in the restore -source, it will be removed to match the source. - -The command can also be used to restore the content in the index with -`--staged`, or restore both the working tree and the index with -`--staged --worktree`. - -By default, the restore sources for working tree and the index are the -index and `HEAD` respectively. `--source` could be used to specify a -commit as the restore source. - -See "Reset, restore and revert" in linkgit:git[1] for the differences -between the three commands. - -THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. - -OPTIONS -------- --s <tree>:: ---source=<tree>:: - Restore the working tree files with the content from the given - tree. It is common to specify the source tree by naming a - commit, branch or tag associated with it. -+ -If not specified, the default restore source for the working tree is -the index, and the default restore source for the index is -`HEAD`. When both `--staged` and `--worktree` are specified, -`--source` must also be specified. - --p:: ---patch:: - Interactively select hunks in the difference between the - restore source and the restore location. See the ``Interactive - Mode'' section of linkgit:git-add[1] to learn how to operate - the `--patch` mode. -+ -Note that `--patch` can accept no pathspec and will prompt to restore -all modified paths. - --W:: ---worktree:: --S:: ---staged:: - Specify the restore location. If neither option is specified, - by default the working tree is restored. Specifying `--staged` - will only restore the index. Specifying both restores both. - --q:: ---quiet:: - Quiet, suppress feedback messages. Implies `--no-progress`. - ---progress:: ---no-progress:: - Progress status is reported on the standard error stream - by default when it is attached to a terminal, unless `--quiet` - is specified. This flag enables progress reporting even if not - attached to a terminal, regardless of `--quiet`. - ---ours:: ---theirs:: - When restoring files in the working tree from the index, use - stage #2 ('ours') or #3 ('theirs') for unmerged paths. -+ -Note that during `git rebase` and `git pull --rebase`, 'ours' and -'theirs' may appear swapped. See the explanation of the same options -in linkgit:git-checkout[1] for details. - --m:: ---merge:: - When restoring files on the working tree from the index, - recreate the conflicted merge in the unmerged paths. - ---conflict=<style>:: - The same as `--merge` option above, but changes the way the - conflicting hunks are presented, overriding the - `merge.conflictStyle` configuration variable. Possible values - are "merge" (default) and "diff3" (in addition to what is - shown by "merge" style, shows the original contents). - ---ignore-unmerged:: - When restoring files on the working tree from the index, do - not abort the operation if there are unmerged entries and - neither `--ours`, `--theirs`, `--merge` or `--conflict` is - specified. Unmerged paths on the working tree are left alone. - ---ignore-skip-worktree-bits:: - In sparse checkout mode, by default is to only update entries - matched by `<pathspec>` and sparse patterns in - $GIT_DIR/info/sparse-checkout. This option ignores the sparse - patterns and unconditionally restores any files in - `<pathspec>`. - ---overlay:: ---no-overlay:: - In overlay mode, the command never removes files when - restoring. In no-overlay mode, tracked files that do not - appear in the `--source` tree are removed, to make them match - `<tree>` exactly. The default is no-overlay mode. - -EXAMPLES --------- - -The following sequence switches to the `master` branch, reverts the -`Makefile` to two revisions back, deletes hello.c by mistake, and gets -it back from the index. - ------------- -$ git switch master -$ git restore --source master~2 Makefile <1> -$ rm -f hello.c -$ git restore hello.c <2> ------------- - -<1> take a file out of another commit -<2> restore hello.c from the index - -If you want to restore _all_ C source files to match the version in -the index, you can say - ------------- -$ git restore '*.c' ------------- - -Note the quotes around `*.c`. The file `hello.c` will also be -restored, even though it is no longer in the working tree, because the -file globbing is used to match entries in the index (not in the -working tree by the shell). - -To restore all files in the current directory - ------------- -$ git restore . ------------- - -or to restore all working tree files with 'top' pathspec magic (see -linkgit:gitglossary[7]) - ------------- -$ git restore :/ ------------- - -To restore a file in the index to match the version in `HEAD` (this is -the same as using linkgit:git-reset[1]) - ------------- -$ git restore --staged hello.c ------------- - -or you can restore both the index and the working tree (this the same -as using linkgit:git-checkout[1]) - ------------- -$ git restore --source=HEAD --staged --worktree hello.c ------------- - -or the short form which is more practical but less readable: - ------------- -$ git restore -s@ -SW hello.c ------------- - -SEE ALSO --------- -linkgit:git-checkout[1], -linkgit:git-reset[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-rev-list.txt b/third_party/git/Documentation/git-rev-list.txt deleted file mode 100644 index 9392760b25..0000000000 --- a/third_party/git/Documentation/git-rev-list.txt +++ /dev/null @@ -1,124 +0,0 @@ -git-rev-list(1) -=============== - -NAME ----- -git-rev-list - Lists commit objects in reverse chronological order - - -SYNOPSIS --------- -[verse] -'git rev-list' [ --max-count=<number> ] - [ --skip=<number> ] - [ --max-age=<timestamp> ] - [ --min-age=<timestamp> ] - [ --sparse ] - [ --merges ] - [ --no-merges ] - [ --min-parents=<number> ] - [ --no-min-parents ] - [ --max-parents=<number> ] - [ --no-max-parents ] - [ --first-parent ] - [ --remove-empty ] - [ --full-history ] - [ --not ] - [ --all ] - [ --branches[=<pattern>] ] - [ --tags[=<pattern>] ] - [ --remotes[=<pattern>] ] - [ --glob=<glob-pattern> ] - [ --ignore-missing ] - [ --stdin ] - [ --quiet ] - [ --topo-order ] - [ --parents ] - [ --timestamp ] - [ --left-right ] - [ --left-only ] - [ --right-only ] - [ --cherry-mark ] - [ --cherry-pick ] - [ --encoding=<encoding> ] - [ --(author|committer|grep)=<pattern> ] - [ --regexp-ignore-case | -i ] - [ --extended-regexp | -E ] - [ --fixed-strings | -F ] - [ --date=<format>] - [ [ --objects | --objects-edge | --objects-edge-aggressive ] - [ --unpacked ] - [ --object-names | --no-object-names ] - [ --filter=<filter-spec> [ --filter-print-omitted ] ] ] - [ --missing=<missing-action> ] - [ --pretty | --header ] - [ --bisect ] - [ --bisect-vars ] - [ --bisect-all ] - [ --merge ] - [ --reverse ] - [ --walk-reflogs ] - [ --no-walk ] [ --do-walk ] - [ --count ] - [ --use-bitmap-index ] - <commit>... [ \-- <paths>... ] - -DESCRIPTION ------------ - -List commits that are reachable by following the `parent` links from the -given commit(s), but exclude commits that are reachable from the one(s) -given with a '{caret}' in front of them. The output is given in reverse -chronological order by default. - -You can think of this as a set operation. Commits given on the command -line form a set of commits that are reachable from any of them, and then -commits reachable from any of the ones given with '{caret}' in front are -subtracted from that set. The remaining commits are what comes out in the -command's output. Various other options and paths parameters can be used -to further limit the result. - -Thus, the following command: - ------------------------------------------------------------------------ - $ git rev-list foo bar ^baz ------------------------------------------------------------------------ - -means "list all the commits which are reachable from 'foo' or 'bar', but -not from 'baz'". - -A special notation "'<commit1>'..'<commit2>'" can be used as a -short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of -the following may be used interchangeably: - ------------------------------------------------------------------------ - $ git rev-list origin..HEAD - $ git rev-list HEAD ^origin ------------------------------------------------------------------------ - -Another special notation is "'<commit1>'...'<commit2>'" which is useful -for merges. The resulting set of commits is the symmetric difference -between the two operands. The following two commands are equivalent: - ------------------------------------------------------------------------ - $ git rev-list A B --not $(git merge-base --all A B) - $ git rev-list A...B ------------------------------------------------------------------------ - -'rev-list' is a very essential Git command, since it -provides the ability to build and traverse commit ancestry graphs. For -this reason, it has a lot of different options that enables it to be -used by commands as different as 'git bisect' and -'git repack'. - -OPTIONS -------- - -:git-rev-list: 1 -include::rev-list-options.txt[] - -include::pretty-formats.txt[] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-rev-parse.txt b/third_party/git/Documentation/git-rev-parse.txt deleted file mode 100644 index e72d332b83..0000000000 --- a/third_party/git/Documentation/git-rev-parse.txt +++ /dev/null @@ -1,456 +0,0 @@ -git-rev-parse(1) -================ - -NAME ----- -git-rev-parse - Pick out and massage parameters - - -SYNOPSIS --------- -[verse] -'git rev-parse' [<options>] <args>... - -DESCRIPTION ------------ - -Many Git porcelainish commands take mixture of flags -(i.e. parameters that begin with a dash '-') and parameters -meant for the underlying 'git rev-list' command they use internally -and flags and parameters for the other commands they use -downstream of 'git rev-list'. This command is used to -distinguish between them. - - -OPTIONS -------- - -Operation Modes -~~~~~~~~~~~~~~~ - -Each of these options must appear first on the command line. - ---parseopt:: - Use 'git rev-parse' in option parsing mode (see PARSEOPT section below). - ---sq-quote:: - Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE - section below). In contrast to the `--sq` option below, this - mode does only quoting. Nothing else is done to command input. - -Options for --parseopt -~~~~~~~~~~~~~~~~~~~~~~ - ---keep-dashdash:: - Only meaningful in `--parseopt` mode. Tells the option parser to echo - out the first `--` met instead of skipping it. - ---stop-at-non-option:: - Only meaningful in `--parseopt` mode. Lets the option parser stop at - the first non-option argument. This can be used to parse sub-commands - that take options themselves. - ---stuck-long:: - Only meaningful in `--parseopt` mode. Output the options in their - long form if available, and with their arguments stuck. - -Options for Filtering -~~~~~~~~~~~~~~~~~~~~~ - ---revs-only:: - Do not output flags and parameters not meant for - 'git rev-list' command. - ---no-revs:: - Do not output flags and parameters meant for - 'git rev-list' command. - ---flags:: - Do not output non-flag parameters. - ---no-flags:: - Do not output flag parameters. - -Options for Output -~~~~~~~~~~~~~~~~~~ - ---default <arg>:: - If there is no parameter given by the user, use `<arg>` - instead. - ---prefix <arg>:: - Behave as if 'git rev-parse' was invoked from the `<arg>` - subdirectory of the working tree. Any relative filenames are - resolved as if they are prefixed by `<arg>` and will be printed - in that form. -+ -This can be used to convert arguments to a command run in a subdirectory -so that they can still be used after moving to the top-level of the -repository. For example: -+ ----- -prefix=$(git rev-parse --show-prefix) -cd "$(git rev-parse --show-toplevel)" -# rev-parse provides the -- needed for 'set' -eval "set $(git rev-parse --sq --prefix "$prefix" -- "$@")" ----- - ---verify:: - Verify that exactly one parameter is provided, and that it - can be turned into a raw 20-byte SHA-1 that can be used to - access the object database. If so, emit it to the standard - output; otherwise, error out. -+ -If you want to make sure that the output actually names an object in -your object database and/or can be used as a specific type of object -you require, you can add the `^{type}` peeling operator to the parameter. -For example, `git rev-parse "$VAR^{commit}"` will make sure `$VAR` -names an existing object that is a commit-ish (i.e. a commit, or an -annotated tag that points at a commit). To make sure that `$VAR` -names an existing object of any type, `git rev-parse "$VAR^{object}"` -can be used. - --q:: ---quiet:: - Only meaningful in `--verify` mode. Do not output an error - message if the first argument is not a valid object name; - instead exit with non-zero status silently. - SHA-1s for valid object names are printed to stdout on success. - ---sq:: - Usually the output is made one line per flag and - parameter. This option makes output a single line, - properly quoted for consumption by shell. Useful when - you expect your parameter to contain whitespaces and - newlines (e.g. when using pickaxe `-S` with - 'git diff-{asterisk}'). In contrast to the `--sq-quote` option, - the command input is still interpreted as usual. - ---short[=length]:: - Same as `--verify` but shortens the object name to a unique - prefix with at least `length` characters. The minimum length - is 4, the default is the effective value of the `core.abbrev` - configuration variable (see linkgit:git-config[1]). - ---not:: - When showing object names, prefix them with '{caret}' and - strip '{caret}' prefix from the object names that already have - one. - ---abbrev-ref[=(strict|loose)]:: - A non-ambiguous short name of the objects name. - The option core.warnAmbiguousRefs is used to select the strict - abbreviation mode. - ---symbolic:: - Usually the object names are output in SHA-1 form (with - possible '{caret}' prefix); this option makes them output in a - form as close to the original input as possible. - ---symbolic-full-name:: - This is similar to --symbolic, but it omits input that - are not refs (i.e. branch or tag names; or more - explicitly disambiguating "heads/master" form, when you - want to name the "master" branch when there is an - unfortunately named tag "master"), and show them as full - refnames (e.g. "refs/heads/master"). - -Options for Objects -~~~~~~~~~~~~~~~~~~~ - ---all:: - Show all refs found in `refs/`. - ---branches[=pattern]:: ---tags[=pattern]:: ---remotes[=pattern]:: - Show all branches, tags, or remote-tracking branches, - respectively (i.e., refs found in `refs/heads`, - `refs/tags`, or `refs/remotes`, respectively). -+ -If a `pattern` is given, only refs matching the given shell glob are -shown. If the pattern does not contain a globbing character (`?`, -`*`, or `[`), it is turned into a prefix match by appending `/*`. - ---glob=pattern:: - Show all refs matching the shell glob pattern `pattern`. If - the pattern does not start with `refs/`, this is automatically - prepended. If the pattern does not contain a globbing - character (`?`, `*`, or `[`), it is turned into a prefix - match by appending `/*`. - ---exclude=<glob-pattern>:: - Do not include refs matching '<glob-pattern>' that the next `--all`, - `--branches`, `--tags`, `--remotes`, or `--glob` would otherwise - consider. Repetitions of this option accumulate exclusion patterns - up to the next `--all`, `--branches`, `--tags`, `--remotes`, or - `--glob` option (other options or arguments do not clear - accumulated patterns). -+ -The patterns given should not begin with `refs/heads`, `refs/tags`, or -`refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`, -respectively, and they must begin with `refs/` when applied to `--glob` -or `--all`. If a trailing '/{asterisk}' is intended, it must be given -explicitly. - ---disambiguate=<prefix>:: - Show every object whose name begins with the given prefix. - The <prefix> must be at least 4 hexadecimal digits long to - avoid listing each and every object in the repository by - mistake. - -Options for Files -~~~~~~~~~~~~~~~~~ - ---local-env-vars:: - List the GIT_* environment variables that are local to the - repository (e.g. GIT_DIR or GIT_WORK_TREE, but not GIT_EDITOR). - Only the names of the variables are listed, not their value, - even if they are set. - ---git-dir:: - Show `$GIT_DIR` if defined. Otherwise show the path to - the .git directory. The path shown, when relative, is - relative to the current working directory. -+ -If `$GIT_DIR` is not defined and the current directory -is not detected to lie in a Git repository or work tree -print a message to stderr and exit with nonzero status. - ---absolute-git-dir:: - Like `--git-dir`, but its output is always the canonicalized - absolute path. - ---git-common-dir:: - Show `$GIT_COMMON_DIR` if defined, else `$GIT_DIR`. - ---is-inside-git-dir:: - When the current working directory is below the repository - directory print "true", otherwise "false". - ---is-inside-work-tree:: - When the current working directory is inside the work tree of the - repository print "true", otherwise "false". - ---is-bare-repository:: - When the repository is bare print "true", otherwise "false". - ---is-shallow-repository:: - When the repository is shallow print "true", otherwise "false". - ---resolve-git-dir <path>:: - Check if <path> is a valid repository or a gitfile that - points at a valid repository, and print the location of the - repository. If <path> is a gitfile then the resolved path - to the real repository is printed. - ---git-path <path>:: - Resolve "$GIT_DIR/<path>" and takes other path relocation - variables such as $GIT_OBJECT_DIRECTORY, - $GIT_INDEX_FILE... into account. For example, if - $GIT_OBJECT_DIRECTORY is set to /foo/bar then "git rev-parse - --git-path objects/abc" returns /foo/bar/abc. - ---show-cdup:: - When the command is invoked from a subdirectory, show the - path of the top-level directory relative to the current - directory (typically a sequence of "../", or an empty string). - ---show-prefix:: - When the command is invoked from a subdirectory, show the - path of the current directory relative to the top-level - directory. - ---show-toplevel:: - Show the absolute path of the top-level directory. - ---show-superproject-working-tree:: - Show the absolute path of the root of the superproject's - working tree (if exists) that uses the current repository as - its submodule. Outputs nothing if the current repository is - not used as a submodule by any project. - ---shared-index-path:: - Show the path to the shared index file in split index mode, or - empty if not in split-index mode. - -Other Options -~~~~~~~~~~~~~ - ---since=datestring:: ---after=datestring:: - Parse the date string, and output the corresponding - --max-age= parameter for 'git rev-list'. - ---until=datestring:: ---before=datestring:: - Parse the date string, and output the corresponding - --min-age= parameter for 'git rev-list'. - -<args>...:: - Flags and parameters to be parsed. - - -include::revisions.txt[] - -PARSEOPT --------- - -In `--parseopt` mode, 'git rev-parse' helps massaging options to bring to shell -scripts the same facilities C builtins have. It works as an option normalizer -(e.g. splits single switches aggregate values), a bit like `getopt(1)` does. - -It takes on the standard input the specification of the options to parse and -understand, and echoes on the standard output a string suitable for `sh(1)` `eval` -to replace the arguments with normalized ones. In case of error, it outputs -usage on the standard error stream, and exits with code 129. - -Note: Make sure you quote the result when passing it to `eval`. See -below for an example. - -Input Format -~~~~~~~~~~~~ - -'git rev-parse --parseopt' input format is fully text based. It has two parts, -separated by a line that contains only `--`. The lines before the separator -(should be one or more) are used for the usage. -The lines after the separator describe the options. - -Each line of options has this format: - ------------- -<opt-spec><flags>*<arg-hint>? SP+ help LF ------------- - -`<opt-spec>`:: - its format is the short option character, then the long option name - separated by a comma. Both parts are not required, though at least one - is necessary. May not contain any of the `<flags>` characters. - `h,help`, `dry-run` and `f` are examples of correct `<opt-spec>`. - -`<flags>`:: - `<flags>` are of `*`, `=`, `?` or `!`. - * Use `=` if the option takes an argument. - - * Use `?` to mean that the option takes an optional argument. You - probably want to use the `--stuck-long` mode to be able to - unambiguously parse the optional argument. - - * Use `*` to mean that this option should not be listed in the usage - generated for the `-h` argument. It's shown for `--help-all` as - documented in linkgit:gitcli[7]. - - * Use `!` to not make the corresponding negated long option available. - -`<arg-hint>`:: - `<arg-hint>`, if specified, is used as a name of the argument in the - help output, for options that take arguments. `<arg-hint>` is - terminated by the first whitespace. It is customary to use a - dash to separate words in a multi-word argument hint. - -The remainder of the line, after stripping the spaces, is used -as the help associated to the option. - -Blank lines are ignored, and lines that don't match this specification are used -as option group headers (start the line with a space to create such -lines on purpose). - -Example -~~~~~~~ - ------------- -OPTS_SPEC="\ -some-command [<options>] <args>... - -some-command does foo and bar! --- -h,help show the help - -foo some nifty option --foo -bar= some cool option --bar with an argument -baz=arg another cool option --baz with a named argument -qux?path qux may take a path argument but has meaning by itself - - An option group Header -C? option C with an optional argument" - -eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)" ------------- - - -Usage text -~~~~~~~~~~ - -When `"$@"` is `-h` or `--help` in the above example, the following -usage text would be shown: - ------------- -usage: some-command [<options>] <args>... - - some-command does foo and bar! - - -h, --help show the help - --foo some nifty option --foo - --bar ... some cool option --bar with an argument - --baz <arg> another cool option --baz with a named argument - --qux[=<path>] qux may take a path argument but has meaning by itself - -An option group Header - -C[...] option C with an optional argument ------------- - -SQ-QUOTE --------- - -In `--sq-quote` mode, 'git rev-parse' echoes on the standard output a -single line suitable for `sh(1)` `eval`. This line is made by -normalizing the arguments following `--sq-quote`. Nothing other than -quoting the arguments is done. - -If you want command input to still be interpreted as usual by -'git rev-parse' before the output is shell quoted, see the `--sq` -option. - -Example -~~~~~~~ - ------------- -$ cat >your-git-script.sh <<\EOF -#!/bin/sh -args=$(git rev-parse --sq-quote "$@") # quote user-supplied arguments -command="git frotz -n24 $args" # and use it inside a handcrafted - # command line -eval "$command" -EOF - -$ sh your-git-script.sh "a b'c" ------------- - -EXAMPLES --------- - -* Print the object name of the current commit: -+ ------------- -$ git rev-parse --verify HEAD ------------- - -* Print the commit object name from the revision in the $REV shell variable: -+ ------------- -$ git rev-parse --verify $REV^{commit} ------------- -+ -This will error out if $REV is empty or not a valid revision. - -* Similar to above: -+ ------------- -$ git rev-parse --default master --verify $REV ------------- -+ -but if $REV is empty, the commit object name from master will be printed. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-revert.txt b/third_party/git/Documentation/git-revert.txt deleted file mode 100644 index 9d22270757..0000000000 --- a/third_party/git/Documentation/git-revert.txt +++ /dev/null @@ -1,142 +0,0 @@ -git-revert(1) -============= - -NAME ----- -git-revert - Revert some existing commits - -SYNOPSIS --------- -[verse] -'git revert' [--[no-]edit] [-n] [-m parent-number] [-s] [-S[<keyid>]] <commit>... -'git revert' (--continue | --skip | --abort | --quit) - -DESCRIPTION ------------ - -Given one or more existing commits, revert the changes that the -related patches introduce, and record some new commits that record -them. This requires your working tree to be clean (no modifications -from the HEAD commit). - -Note: 'git revert' is used to record some new commits to reverse the -effect of some earlier commits (often only a faulty one). If you want to -throw away all uncommitted changes in your working directory, you -should see linkgit:git-reset[1], particularly the `--hard` option. If -you want to extract specific files as they were in another commit, you -should see linkgit:git-restore[1], specifically the `--source` -option. Take care with these alternatives as -both will discard uncommitted changes in your working directory. - -See "Reset, restore and revert" in linkgit:git[1] for the differences -between the three commands. - -OPTIONS -------- -<commit>...:: - Commits to revert. - For a more complete list of ways to spell commit names, see - linkgit:gitrevisions[7]. - Sets of commits can also be given but no traversal is done by - default, see linkgit:git-rev-list[1] and its `--no-walk` - option. - --e:: ---edit:: - With this option, 'git revert' will let you edit the commit - message prior to committing the revert. This is the default if - you run the command from a terminal. - --m parent-number:: ---mainline parent-number:: - Usually you cannot revert a merge because you do not know which - side of the merge should be considered the mainline. This - option specifies the parent number (starting from 1) of - the mainline and allows revert to reverse the change - relative to the specified parent. -+ -Reverting a merge commit declares that you will never want the tree changes -brought in by the merge. As a result, later merges will only bring in tree -changes introduced by commits that are not ancestors of the previously -reverted merge. This may or may not be what you want. -+ -See the link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for -more details. - ---no-edit:: - With this option, 'git revert' will not start the commit - message editor. - ---cleanup=<mode>:: - This option determines how the commit message will be cleaned up before - being passed on to the commit machinery. See linkgit:git-commit[1] for more - details. In particular, if the '<mode>' is given a value of `scissors`, - scissors will be appended to `MERGE_MSG` before being passed on in the case - of a conflict. - --n:: ---no-commit:: - Usually the command automatically creates some commits with - commit log messages stating which commits were - reverted. This flag applies the changes necessary - to revert the named commits to your working tree - and the index, but does not make the commits. In addition, - when this option is used, your index does not have to match - the HEAD commit. The revert is done against the - beginning state of your index. -+ -This is useful when reverting more than one commits' -effect to your index in a row. - --S[<keyid>]:: ---gpg-sign[=<keyid>]:: - GPG-sign commits. The `keyid` argument is optional and - defaults to the committer identity; if specified, it must be - stuck to the option without a space. - --s:: ---signoff:: - Add Signed-off-by line at the end of the commit message. - See the signoff option in linkgit:git-commit[1] for more information. - ---strategy=<strategy>:: - Use the given merge strategy. Should only be used once. - See the MERGE STRATEGIES section in linkgit:git-merge[1] - for details. - --X<option>:: ---strategy-option=<option>:: - Pass the merge strategy-specific option through to the - merge strategy. See linkgit:git-merge[1] for details. - ---rerere-autoupdate:: ---no-rerere-autoupdate:: - Allow the rerere mechanism to update the index with the - result of auto-conflict resolution if possible. - -SEQUENCER SUBCOMMANDS ---------------------- -include::sequencer.txt[] - -EXAMPLES --------- -`git revert HEAD~3`:: - - Revert the changes specified by the fourth last commit in HEAD - and create a new commit with the reverted changes. - -`git revert -n master~5..master~2`:: - - Revert the changes done by commits from the fifth last commit - in master (included) to the third last commit in master - (included), but do not create any commit with the reverted - changes. The revert only modifies the working tree and the - index. - -SEE ALSO --------- -linkgit:git-cherry-pick[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-rm.txt b/third_party/git/Documentation/git-rm.txt deleted file mode 100644 index b5c46223c4..0000000000 --- a/third_party/git/Documentation/git-rm.txt +++ /dev/null @@ -1,189 +0,0 @@ -git-rm(1) -========= - -NAME ----- -git-rm - Remove files from the working tree and from the index - -SYNOPSIS --------- -[verse] -'git rm' [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>... - -DESCRIPTION ------------ -Remove files from the index, or from the working tree and the index. -`git rm` will not remove a file from just your working directory. -(There is no option to remove a file only from the working tree -and yet keep it in the index; use `/bin/rm` if you want to do that.) -The files being removed have to be identical to the tip of the branch, -and no updates to their contents can be staged in the index, -though that default behavior can be overridden with the `-f` option. -When `--cached` is given, the staged content has to -match either the tip of the branch or the file on disk, -allowing the file to be removed from just the index. - - -OPTIONS -------- -<file>...:: - Files to remove. Fileglobs (e.g. `*.c`) can be given to - remove all matching files. If you want Git to expand - file glob characters, you may need to shell-escape them. - A leading directory name - (e.g. `dir` to remove `dir/file1` and `dir/file2`) can be - given to remove all files in the directory, and recursively - all sub-directories, - but this requires the `-r` option to be explicitly given. - --f:: ---force:: - Override the up-to-date check. - --n:: ---dry-run:: - Don't actually remove any file(s). Instead, just show - if they exist in the index and would otherwise be removed - by the command. - --r:: - Allow recursive removal when a leading directory name is - given. - -\--:: - This option can be used to separate command-line options from - the list of files, (useful when filenames might be mistaken - for command-line options). - ---cached:: - Use this option to unstage and remove paths only from the index. - Working tree files, whether modified or not, will be - left alone. - ---ignore-unmatch:: - Exit with a zero status even if no files matched. - --q:: ---quiet:: - `git rm` normally outputs one line (in the form of an `rm` command) - for each file removed. This option suppresses that output. - - -DISCUSSION ----------- - -The <file> list given to the command can be exact pathnames, -file glob patterns, or leading directory names. The command -removes only the paths that are known to Git. Giving the name of -a file that you have not told Git about does not remove that file. - -File globbing matches across directory boundaries. Thus, given -two directories `d` and `d2`, there is a difference between -using `git rm 'd*'` and `git rm 'd/*'`, as the former will -also remove all of directory `d2`. - -REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM --------------------------------------------------------- -There is no option for `git rm` to remove from the index only -the paths that have disappeared from the filesystem. However, -depending on the use case, there are several ways that can be -done. - -Using ``git commit -a'' -~~~~~~~~~~~~~~~~~~~~~~~ -If you intend that your next commit should record all modifications -of tracked files in the working tree and record all removals of -files that have been removed from the working tree with `rm` -(as opposed to `git rm`), use `git commit -a`, as it will -automatically notice and record all removals. You can also have a -similar effect without committing by using `git add -u`. - -Using ``git add -A'' -~~~~~~~~~~~~~~~~~~~~ -When accepting a new code drop for a vendor branch, you probably -want to record both the removal of paths and additions of new paths -as well as modifications of existing paths. - -Typically you would first remove all tracked files from the working -tree using this command: - ----------------- -git ls-files -z | xargs -0 rm -f ----------------- - -and then untar the new code in the working tree. Alternately -you could 'rsync' the changes into the working tree. - -After that, the easiest way to record all removals, additions, and -modifications in the working tree is: - ----------------- -git add -A ----------------- - -See linkgit:git-add[1]. - -Other ways -~~~~~~~~~~ -If all you really want to do is to remove from the index the files -that are no longer present in the working tree (perhaps because -your working tree is dirty so that you cannot use `git commit -a`), -use the following command: - ----------------- -git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached ----------------- - -SUBMODULES ----------- -Only submodules using a gitfile (which means they were cloned -with a Git version 1.7.8 or newer) will be removed from the work -tree, as their repository lives inside the .git directory of the -superproject. If a submodule (or one of those nested inside it) -still uses a .git directory, `git rm` will move the submodules -git directory into the superprojects git directory to protect -the submodule's history. If it exists the submodule.<name> section -in the linkgit:gitmodules[5] file will also be removed and that file -will be staged (unless --cached or -n are used). - -A submodule is considered up to date when the HEAD is the same as -recorded in the index, no tracked files are modified and no untracked -files that aren't ignored are present in the submodules work tree. -Ignored files are deemed expendable and won't stop a submodule's work -tree from being removed. - -If you only want to remove the local checkout of a submodule from your -work tree without committing the removal, use linkgit:git-submodule[1] `deinit` -instead. Also see linkgit:gitsubmodules[7] for details on submodule removal. - -EXAMPLES --------- -`git rm Documentation/\*.txt`:: - Removes all `*.txt` files from the index that are under the - `Documentation` directory and any of its subdirectories. -+ -Note that the asterisk `*` is quoted from the shell in this -example; this lets Git, and not the shell, expand the pathnames -of files and subdirectories under the `Documentation/` directory. - -`git rm -f git-*.sh`:: - Because this example lets the shell expand the asterisk - (i.e. you are listing the files explicitly), it - does not remove `subdir/git-foo.sh`. - -BUGS ----- -Each time a superproject update removes a populated submodule -(e.g. when switching between commits before and after the removal) a -stale submodule checkout will remain in the old location. Removing the -old directory is only safe when it uses a gitfile, as otherwise the -history of the submodule will be deleted too. This step will be -obsolete when recursive submodule update has been implemented. - -SEE ALSO --------- -linkgit:git-add[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-send-email.txt b/third_party/git/Documentation/git-send-email.txt deleted file mode 100644 index d93e5d0f58..0000000000 --- a/third_party/git/Documentation/git-send-email.txt +++ /dev/null @@ -1,524 +0,0 @@ -git-send-email(1) -================= - -NAME ----- -git-send-email - Send a collection of patches as emails - - -SYNOPSIS --------- -[verse] -'git send-email' [<options>] <file|directory|rev-list options>... -'git send-email' --dump-aliases - - -DESCRIPTION ------------ -Takes the patches given on the command line and emails them out. -Patches can be specified as files, directories (which will send all -files in the directory), or directly as a revision list. In the -last case, any format accepted by linkgit:git-format-patch[1] can -be passed to git send-email. - -The header of the email is configurable via command-line options. If not -specified on the command line, the user will be prompted with a ReadLine -enabled interface to provide the necessary information. - -There are two formats accepted for patch files: - -1. mbox format files -+ -This is what linkgit:git-format-patch[1] generates. Most headers and MIME -formatting are ignored. - -2. The original format used by Greg Kroah-Hartman's 'send_lots_of_email.pl' - script -+ -This format expects the first line of the file to contain the "Cc:" value -and the "Subject:" of the message as the second line. - - -OPTIONS -------- - -Composing -~~~~~~~~~ - ---annotate:: - Review and edit each patch you're about to send. Default is the value - of `sendemail.annotate`. See the CONFIGURATION section for - `sendemail.multiEdit`. - ---bcc=<address>,...:: - Specify a "Bcc:" value for each email. Default is the value of - `sendemail.bcc`. -+ -This option may be specified multiple times. - ---cc=<address>,...:: - Specify a starting "Cc:" value for each email. - Default is the value of `sendemail.cc`. -+ -This option may be specified multiple times. - ---compose:: - Invoke a text editor (see GIT_EDITOR in linkgit:git-var[1]) - to edit an introductory message for the patch series. -+ -When `--compose` is used, git send-email will use the From, Subject, and -In-Reply-To headers specified in the message. If the body of the message -(what you type after the headers and a blank line) only contains blank -(or Git: prefixed) lines, the summary won't be sent, but From, Subject, -and In-Reply-To headers will be used unless they are removed. -+ -Missing From or In-Reply-To headers will be prompted for. -+ -See the CONFIGURATION section for `sendemail.multiEdit`. - ---from=<address>:: - Specify the sender of the emails. If not specified on the command line, - the value of the `sendemail.from` configuration option is used. If - neither the command-line option nor `sendemail.from` are set, then the - user will be prompted for the value. The default for the prompt will be - the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not - set, as returned by "git var -l". - ---reply-to=<address>:: - Specify the address where replies from recipients should go to. - Use this if replies to messages should go to another address than what - is specified with the --from parameter. - ---in-reply-to=<identifier>:: - Make the first mail (or all the mails with `--no-thread`) appear as a - reply to the given Message-Id, which avoids breaking threads to - provide a new patch series. - The second and subsequent emails will be sent as replies according to - the `--[no-]chain-reply-to` setting. -+ -So for example when `--thread` and `--no-chain-reply-to` are specified, the -second and subsequent patches will be replies to the first one like in the -illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`: -+ - [PATCH 0/2] Here is what I did... - [PATCH 1/2] Clean up and tests - [PATCH 2/2] Implementation - [PATCH v2 0/3] Here is a reroll - [PATCH v2 1/3] Clean up - [PATCH v2 2/3] New tests - [PATCH v2 3/3] Implementation -+ -Only necessary if --compose is also set. If --compose -is not set, this will be prompted for. - ---subject=<string>:: - Specify the initial subject of the email thread. - Only necessary if --compose is also set. If --compose - is not set, this will be prompted for. - ---to=<address>,...:: - Specify the primary recipient of the emails generated. Generally, this - will be the upstream maintainer of the project involved. Default is the - value of the `sendemail.to` configuration value; if that is unspecified, - and --to-cmd is not specified, this will be prompted for. -+ -This option may be specified multiple times. - ---8bit-encoding=<encoding>:: - When encountering a non-ASCII message or subject that does not - declare its encoding, add headers/quoting to indicate it is - encoded in <encoding>. Default is the value of the - 'sendemail.assume8bitEncoding'; if that is unspecified, this - will be prompted for if any non-ASCII files are encountered. -+ -Note that no attempts whatsoever are made to validate the encoding. - ---compose-encoding=<encoding>:: - Specify encoding of compose message. Default is the value of the - 'sendemail.composeencoding'; if that is unspecified, UTF-8 is assumed. - ---transfer-encoding=(7bit|8bit|quoted-printable|base64|auto):: - Specify the transfer encoding to be used to send the message over SMTP. - 7bit will fail upon encountering a non-ASCII message. quoted-printable - can be useful when the repository contains files that contain carriage - returns, but makes the raw patch email file (as saved from a MUA) much - harder to inspect manually. base64 is even more fool proof, but also - even more opaque. auto will use 8bit when possible, and quoted-printable - otherwise. -+ -Default is the value of the `sendemail.transferEncoding` configuration -value; if that is unspecified, default to `auto`. - ---xmailer:: ---no-xmailer:: - Add (or prevent adding) the "X-Mailer:" header. By default, - the header is added, but it can be turned off by setting the - `sendemail.xmailer` configuration variable to `false`. - -Sending -~~~~~~~ - ---envelope-sender=<address>:: - Specify the envelope sender used to send the emails. - This is useful if your default address is not the address that is - subscribed to a list. In order to use the 'From' address, set the - value to "auto". If you use the sendmail binary, you must have - suitable privileges for the -f parameter. Default is the value of the - `sendemail.envelopeSender` configuration variable; if that is - unspecified, choosing the envelope sender is left to your MTA. - ---smtp-encryption=<encryption>:: - Specify the encryption to use, either 'ssl' or 'tls'. Any other - value reverts to plain SMTP. Default is the value of - `sendemail.smtpEncryption`. - ---smtp-domain=<FQDN>:: - Specifies the Fully Qualified Domain Name (FQDN) used in the - HELO/EHLO command to the SMTP server. Some servers require the - FQDN to match your IP address. If not set, git send-email attempts - to determine your FQDN automatically. Default is the value of - `sendemail.smtpDomain`. - ---smtp-auth=<mechanisms>:: - Whitespace-separated list of allowed SMTP-AUTH mechanisms. This setting - forces using only the listed mechanisms. Example: -+ ------- -$ git send-email --smtp-auth="PLAIN LOGIN GSSAPI" ... ------- -+ -If at least one of the specified mechanisms matches the ones advertised by the -SMTP server and if it is supported by the utilized SASL library, the mechanism -is used for authentication. If neither 'sendemail.smtpAuth' nor `--smtp-auth` -is specified, all mechanisms supported by the SASL library can be used. The -special value 'none' maybe specified to completely disable authentication -independently of `--smtp-user` - ---smtp-pass[=<password>]:: - Password for SMTP-AUTH. The argument is optional: If no - argument is specified, then the empty string is used as - the password. Default is the value of `sendemail.smtpPass`, - however `--smtp-pass` always overrides this value. -+ -Furthermore, passwords need not be specified in configuration files -or on the command line. If a username has been specified (with -`--smtp-user` or a `sendemail.smtpUser`), but no password has been -specified (with `--smtp-pass` or `sendemail.smtpPass`), then -a password is obtained using 'git-credential'. - ---no-smtp-auth:: - Disable SMTP authentication. Short hand for `--smtp-auth=none` - ---smtp-server=<host>:: - If set, specifies the outgoing SMTP server to use (e.g. - `smtp.example.com` or a raw IP address). Alternatively it can - specify a full pathname of a sendmail-like program instead; - the program must support the `-i` option. Default value can - be specified by the `sendemail.smtpServer` configuration - option; the built-in default is to search for `sendmail` in - `/usr/sbin`, `/usr/lib` and $PATH if such program is - available, falling back to `localhost` otherwise. - ---smtp-server-port=<port>:: - Specifies a port different from the default port (SMTP - servers typically listen to smtp port 25, but may also listen to - submission port 587, or the common SSL smtp port 465); - symbolic port names (e.g. "submission" instead of 587) - are also accepted. The port can also be set with the - `sendemail.smtpServerPort` configuration variable. - ---smtp-server-option=<option>:: - If set, specifies the outgoing SMTP server option to use. - Default value can be specified by the `sendemail.smtpServerOption` - configuration option. -+ -The --smtp-server-option option must be repeated for each option you want -to pass to the server. Likewise, different lines in the configuration files -must be used for each option. - ---smtp-ssl:: - Legacy alias for '--smtp-encryption ssl'. - ---smtp-ssl-cert-path:: - Path to a store of trusted CA certificates for SMTP SSL/TLS - certificate validation (either a directory that has been processed - by 'c_rehash', or a single file containing one or more PEM format - certificates concatenated together: see verify(1) -CAfile and - -CApath for more information on these). Set it to an empty string - to disable certificate verification. Defaults to the value of the - `sendemail.smtpsslcertpath` configuration variable, if set, or the - backing SSL library's compiled-in default otherwise (which should - be the best choice on most platforms). - ---smtp-user=<user>:: - Username for SMTP-AUTH. Default is the value of `sendemail.smtpUser`; - if a username is not specified (with `--smtp-user` or `sendemail.smtpUser`), - then authentication is not attempted. - ---smtp-debug=0|1:: - Enable (1) or disable (0) debug output. If enabled, SMTP - commands and replies will be printed. Useful to debug TLS - connection and authentication problems. - ---batch-size=<num>:: - Some email servers (e.g. smtp.163.com) limit the number emails to be - sent per session (connection) and this will lead to a failure when - sending many messages. With this option, send-email will disconnect after - sending $<num> messages and wait for a few seconds (see --relogin-delay) - and reconnect, to work around such a limit. You may want to - use some form of credential helper to avoid having to retype - your password every time this happens. Defaults to the - `sendemail.smtpBatchSize` configuration variable. - ---relogin-delay=<int>:: - Waiting $<int> seconds before reconnecting to SMTP server. Used together - with --batch-size option. Defaults to the `sendemail.smtpReloginDelay` - configuration variable. - -Automating -~~~~~~~~~~ - ---no-[to|cc|bcc]:: - Clears any list of "To:", "Cc:", "Bcc:" addresses previously - set via config. - ---no-identity:: - Clears the previously read value of `sendemail.identity` set - via config, if any. - ---to-cmd=<command>:: - Specify a command to execute once per patch file which - should generate patch file specific "To:" entries. - Output of this command must be single email address per line. - Default is the value of 'sendemail.tocmd' configuration value. - ---cc-cmd=<command>:: - Specify a command to execute once per patch file which - should generate patch file specific "Cc:" entries. - Output of this command must be single email address per line. - Default is the value of `sendemail.ccCmd` configuration value. - ---[no-]chain-reply-to:: - If this is set, each email will be sent as a reply to the previous - email sent. If disabled with "--no-chain-reply-to", all emails after - the first will be sent as replies to the first email sent. When using - this, it is recommended that the first file given be an overview of the - entire patch series. Disabled by default, but the `sendemail.chainReplyTo` - configuration variable can be used to enable it. - ---identity=<identity>:: - A configuration identity. When given, causes values in the - 'sendemail.<identity>' subsection to take precedence over - values in the 'sendemail' section. The default identity is - the value of `sendemail.identity`. - ---[no-]signed-off-by-cc:: - If this is set, add emails found in Signed-off-by: or Cc: lines to the - cc list. Default is the value of `sendemail.signedoffbycc` configuration - value; if that is unspecified, default to --signed-off-by-cc. - ---[no-]cc-cover:: - If this is set, emails found in Cc: headers in the first patch of - the series (typically the cover letter) are added to the cc list - for each email set. Default is the value of 'sendemail.cccover' - configuration value; if that is unspecified, default to --no-cc-cover. - ---[no-]to-cover:: - If this is set, emails found in To: headers in the first patch of - the series (typically the cover letter) are added to the to list - for each email set. Default is the value of 'sendemail.tocover' - configuration value; if that is unspecified, default to --no-to-cover. - ---suppress-cc=<category>:: - Specify an additional category of recipients to suppress the - auto-cc of: -+ --- -- 'author' will avoid including the patch author. -- 'self' will avoid including the sender. -- 'cc' will avoid including anyone mentioned in Cc lines in the patch header - except for self (use 'self' for that). -- 'bodycc' will avoid including anyone mentioned in Cc lines in the - patch body (commit message) except for self (use 'self' for that). -- 'sob' will avoid including anyone mentioned in Signed-off-by lines except - for self (use 'self' for that). -- 'misc-by' will avoid including anyone mentioned in Acked-by, - Reviewed-by, Tested-by and other "-by" lines in the patch body, - except Signed-off-by (use 'sob' for that). -- 'cccmd' will avoid running the --cc-cmd. -- 'body' is equivalent to 'sob' + 'bodycc' + 'misc-by'. -- 'all' will suppress all auto cc values. --- -+ -Default is the value of `sendemail.suppresscc` configuration value; if -that is unspecified, default to 'self' if --suppress-from is -specified, as well as 'body' if --no-signed-off-cc is specified. - ---[no-]suppress-from:: - If this is set, do not add the From: address to the cc: list. - Default is the value of `sendemail.suppressFrom` configuration - value; if that is unspecified, default to --no-suppress-from. - ---[no-]thread:: - If this is set, the In-Reply-To and References headers will be - added to each email sent. Whether each mail refers to the - previous email (`deep` threading per 'git format-patch' - wording) or to the first email (`shallow` threading) is - governed by "--[no-]chain-reply-to". -+ -If disabled with "--no-thread", those headers will not be added -(unless specified with --in-reply-to). Default is the value of the -`sendemail.thread` configuration value; if that is unspecified, -default to --thread. -+ -It is up to the user to ensure that no In-Reply-To header already -exists when 'git send-email' is asked to add it (especially note that -'git format-patch' can be configured to do the threading itself). -Failure to do so may not produce the expected result in the -recipient's MUA. - - -Administering -~~~~~~~~~~~~~ - ---confirm=<mode>:: - Confirm just before sending: -+ --- -- 'always' will always confirm before sending -- 'never' will never confirm before sending -- 'cc' will confirm before sending when send-email has automatically - added addresses from the patch to the Cc list -- 'compose' will confirm before sending the first message when using --compose. -- 'auto' is equivalent to 'cc' + 'compose' --- -+ -Default is the value of `sendemail.confirm` configuration value; if that -is unspecified, default to 'auto' unless any of the suppress options -have been specified, in which case default to 'compose'. - ---dry-run:: - Do everything except actually send the emails. - ---[no-]format-patch:: - When an argument may be understood either as a reference or as a file name, - choose to understand it as a format-patch argument (`--format-patch`) - or as a file name (`--no-format-patch`). By default, when such a conflict - occurs, git send-email will fail. - ---quiet:: - Make git-send-email less verbose. One line per email should be - all that is output. - ---[no-]validate:: - Perform sanity checks on patches. - Currently, validation means the following: -+ --- - * Invoke the sendemail-validate hook if present (see linkgit:githooks[5]). - * Warn of patches that contain lines longer than - 998 characters unless a suitable transfer encoding - ('auto', 'base64', or 'quoted-printable') is used; - this is due to SMTP limits as described by - http://www.ietf.org/rfc/rfc5322.txt. --- -+ -Default is the value of `sendemail.validate`; if this is not set, -default to `--validate`. - ---force:: - Send emails even if safety checks would prevent it. - - -Information -~~~~~~~~~~~ - ---dump-aliases:: - Instead of the normal operation, dump the shorthand alias names from - the configured alias file(s), one per line in alphabetical order. Note, - this only includes the alias name and not its expanded email addresses. - See 'sendemail.aliasesfile' for more information about aliases. - - -CONFIGURATION -------------- - -sendemail.aliasesFile:: - To avoid typing long email addresses, point this to one or more - email aliases files. You must also supply `sendemail.aliasFileType`. - -sendemail.aliasFileType:: - Format of the file(s) specified in sendemail.aliasesFile. Must be - one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus', or 'sendmail'. -+ -What an alias file in each format looks like can be found in -the documentation of the email program of the same name. The -differences and limitations from the standard formats are -described below: -+ --- -sendmail;; -* Quoted aliases and quoted addresses are not supported: lines that - contain a `"` symbol are ignored. -* Redirection to a file (`/path/name`) or pipe (`|command`) is not - supported. -* File inclusion (`:include: /path/name`) is not supported. -* Warnings are printed on the standard error output for any - explicitly unsupported constructs, and any other lines that are not - recognized by the parser. --- - -sendemail.multiEdit:: - If true (default), a single editor instance will be spawned to edit - files you have to edit (patches when `--annotate` is used, and the - summary when `--compose` is used). If false, files will be edited one - after the other, spawning a new editor each time. - -sendemail.confirm:: - Sets the default for whether to confirm before sending. Must be - one of 'always', 'never', 'cc', 'compose', or 'auto'. See `--confirm` - in the previous section for the meaning of these values. - -EXAMPLES --------- -Use gmail as the smtp server -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -To use 'git send-email' to send your patches through the GMail SMTP server, -edit ~/.gitconfig to specify your account settings: - - [sendemail] - smtpEncryption = tls - smtpServer = smtp.gmail.com - smtpUser = yourname@gmail.com - smtpServerPort = 587 - -If you have multifactor authentication setup on your gmail account, you will -need to generate an app-specific password for use with 'git send-email'. Visit -https://security.google.com/settings/security/apppasswords to create it. - -Once your commits are ready to be sent to the mailing list, run the -following commands: - - $ git format-patch --cover-letter -M origin/master -o outgoing/ - $ edit outgoing/0000-* - $ git send-email outgoing/* - -The first time you run it, you will be prompted for your credentials. Enter the -app-specific or your regular password as appropriate. If you have credential -helper configured (see linkgit:git-credential[1]), the password will be saved in -the credential store so you won't have to type it the next time. - -Note: the following core Perl modules that may be installed with your -distribution of Perl are required: -MIME::Base64, MIME::QuotedPrint, Net::Domain and Net::SMTP. -These additional Perl modules are also required: -Authen::SASL and Mail::Address. - - -SEE ALSO --------- -linkgit:git-format-patch[1], linkgit:git-imap-send[1], mbox(5) - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-send-pack.txt b/third_party/git/Documentation/git-send-pack.txt deleted file mode 100644 index 44fd146b91..0000000000 --- a/third_party/git/Documentation/git-send-pack.txt +++ /dev/null @@ -1,156 +0,0 @@ -git-send-pack(1) -================ - -NAME ----- -git-send-pack - Push objects over Git protocol to another repository - - -SYNOPSIS --------- -[verse] -'git send-pack' [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] - [--verbose] [--thin] [--atomic] - [--[no-]signed|--signed=(true|false|if-asked)] - [<host>:]<directory> [<ref>...] - -DESCRIPTION ------------ -Usually you would want to use 'git push', which is a -higher-level wrapper of this command, instead. See linkgit:git-push[1]. - -Invokes 'git-receive-pack' on a possibly remote repository, and -updates it from the current repository, sending named refs. - - -OPTIONS -------- ---receive-pack=<git-receive-pack>:: - Path to the 'git-receive-pack' program on the remote - end. Sometimes useful when pushing to a remote - repository over ssh, and you do not have the program in - a directory on the default $PATH. - ---exec=<git-receive-pack>:: - Same as --receive-pack=<git-receive-pack>. - ---all:: - Instead of explicitly specifying which refs to update, - update all heads that locally exist. - ---stdin:: - Take the list of refs from stdin, one per line. If there - are refs specified on the command line in addition to this - option, then the refs from stdin are processed after those - on the command line. -+ -If `--stateless-rpc` is specified together with this option then -the list of refs must be in packet format (pkt-line). Each ref must -be in a separate packet, and the list must end with a flush packet. - ---dry-run:: - Do everything except actually send the updates. - ---force:: - Usually, the command refuses to update a remote ref that - is not an ancestor of the local ref used to overwrite it. - This flag disables the check. What this means is that - the remote repository can lose commits; use it with - care. - ---verbose:: - Run verbosely. - ---thin:: - Send a "thin" pack, which records objects in deltified form based - on objects not included in the pack to reduce network traffic. - ---atomic:: - Use an atomic transaction for updating the refs. If any of the refs - fails to update then the entire push will fail without changing any - refs. - ---[no-]signed:: ---signed=(true|false|if-asked):: - GPG-sign the push request to update refs on the receiving - side, to allow it to be checked by the hooks and/or be - logged. If `false` or `--no-signed`, no signing will be - attempted. If `true` or `--signed`, the push will fail if the - server does not support signed pushes. If set to `if-asked`, - sign if and only if the server supports signed pushes. The push - will also fail if the actual call to `gpg --sign` fails. See - linkgit:git-receive-pack[1] for the details on the receiving end. - ---push-option=<string>:: - Pass the specified string as a push option for consumption by - hooks on the server side. If the server doesn't support push - options, error out. See linkgit:git-push[1] and - linkgit:githooks[5] for details. - -<host>:: - A remote host to house the repository. When this - part is specified, 'git-receive-pack' is invoked via - ssh. - -<directory>:: - The repository to update. - -<ref>...:: - The remote refs to update. - - -SPECIFYING THE REFS -------------------- - -There are three ways to specify which refs to update on the -remote end. - -With `--all` flag, all refs that exist locally are transferred to -the remote side. You cannot specify any '<ref>' if you use -this flag. - -Without `--all` and without any '<ref>', the heads that exist -both on the local side and on the remote side are updated. - -When one or more '<ref>' are specified explicitly (whether on the -command line or via `--stdin`), it can be either a -single pattern, or a pair of such pattern separated by a colon -":" (this means that a ref name cannot have a colon in it). A -single pattern '<name>' is just a shorthand for '<name>:<name>'. - -Each pattern pair consists of the source side (before the colon) -and the destination side (after the colon). The ref to be -pushed is determined by finding a match that matches the source -side, and where it is pushed is determined by using the -destination side. The rules used to match a ref are the same -rules used by 'git rev-parse' to resolve a symbolic ref -name. See linkgit:git-rev-parse[1]. - - - It is an error if <src> does not match exactly one of the - local refs. - - - It is an error if <dst> matches more than one remote refs. - - - If <dst> does not match any remote ref, either - - * it has to start with "refs/"; <dst> is used as the - destination literally in this case. - - * <src> == <dst> and the ref that matched the <src> must not - exist in the set of remote refs; the ref matched <src> - locally is used as the name of the destination. - -Without `--force`, the <src> ref is stored at the remote only if -<dst> does not exist, or <dst> is a proper subset (i.e. an -ancestor) of <src>. This check, known as "fast-forward check", -is performed in order to avoid accidentally overwriting the -remote ref and lose other peoples' commits from there. - -With `--force`, the fast-forward check is disabled for all refs. - -Optionally, a <ref> parameter can be prefixed with a plus '+' sign -to disable the fast-forward check only on that ref. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-sh-i18n--envsubst.txt b/third_party/git/Documentation/git-sh-i18n--envsubst.txt deleted file mode 100644 index 2ffaf9392e..0000000000 --- a/third_party/git/Documentation/git-sh-i18n--envsubst.txt +++ /dev/null @@ -1,36 +0,0 @@ -git-sh-i18n{litdd}envsubst(1) -============================= - -NAME ----- -git-sh-i18n--envsubst - Git's own envsubst(1) for i18n fallbacks - -SYNOPSIS --------- -[verse] -eval_gettext () { - printf "%s" "$1" | ( - export PATH $('git sh-i18n{litdd}envsubst' --variables "$1"); - 'git sh-i18n{litdd}envsubst' "$1" - ) -} - -DESCRIPTION ------------ - -This is not a command the end user would want to run. Ever. -This documentation is meant for people who are studying the -plumbing scripts and/or are writing new ones. - -'git sh-i18n{litdd}envsubst' is Git's stripped-down copy of the GNU -`envsubst(1)` program that comes with the GNU gettext package. It's -used internally by linkgit:git-sh-i18n[1] to interpolate the variables -passed to the `eval_gettext` function. - -No promises are made about the interface, or that this -program won't disappear without warning in the next version -of Git. Don't use it. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-sh-i18n.txt b/third_party/git/Documentation/git-sh-i18n.txt deleted file mode 100644 index 60cf49cb2a..0000000000 --- a/third_party/git/Documentation/git-sh-i18n.txt +++ /dev/null @@ -1,43 +0,0 @@ -git-sh-i18n(1) -============== - -NAME ----- -git-sh-i18n - Git's i18n setup code for shell scripts - -SYNOPSIS --------- -[verse] -'. "$(git --exec-path)/git-sh-i18n"' - -DESCRIPTION ------------ - -This is not a command the end user would want to run. Ever. -This documentation is meant for people who are studying the -Porcelain-ish scripts and/or are writing new ones. - -The 'git sh-i18n scriptlet is designed to be sourced (using -`.`) by Git's porcelain programs implemented in shell -script. It provides wrappers for the GNU `gettext` and -`eval_gettext` functions accessible through the `gettext.sh` -script, and provides pass-through fallbacks on systems -without GNU gettext. - -FUNCTIONS ---------- - -gettext:: - Currently a dummy fall-through function implemented as a wrapper - around `printf(1)`. Will be replaced by a real gettext - implementation in a later version. - -eval_gettext:: - Currently a dummy fall-through function implemented as a wrapper - around `printf(1)` with variables expanded by the - linkgit:git-sh-i18n{litdd}envsubst[1] helper. Will be replaced by a - real gettext implementation in a later version. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-sh-setup.txt b/third_party/git/Documentation/git-sh-setup.txt deleted file mode 100644 index 8632612c31..0000000000 --- a/third_party/git/Documentation/git-sh-setup.txt +++ /dev/null @@ -1,95 +0,0 @@ -git-sh-setup(1) -=============== - -NAME ----- -git-sh-setup - Common Git shell script setup code - -SYNOPSIS --------- -[verse] -'. "$(git --exec-path)/git-sh-setup"' - -DESCRIPTION ------------ - -This is not a command the end user would want to run. Ever. -This documentation is meant for people who are studying the -Porcelain-ish scripts and/or are writing new ones. - -The 'git sh-setup' scriptlet is designed to be sourced (using -`.`) by other shell scripts to set up some variables pointing at -the normal Git directories and a few helper shell functions. - -Before sourcing it, your script should set up a few variables; -`USAGE` (and `LONG_USAGE`, if any) is used to define message -given by `usage()` shell function. `SUBDIRECTORY_OK` can be set -if the script can run from a subdirectory of the working tree -(some commands do not). - -The scriptlet sets `GIT_DIR` and `GIT_OBJECT_DIRECTORY` shell -variables, but does *not* export them to the environment. - -FUNCTIONS ---------- - -die:: - exit after emitting the supplied error message to the - standard error stream. - -usage:: - die with the usage message. - -set_reflog_action:: - Set `GIT_REFLOG_ACTION` environment to a given string (typically - the name of the program) unless it is already set. Whenever - the script runs a `git` command that updates refs, a reflog - entry is created using the value of this string to leave the - record of what command updated the ref. - -git_editor:: - runs an editor of user's choice (GIT_EDITOR, core.editor, VISUAL or - EDITOR) on a given file, but error out if no editor is specified - and the terminal is dumb. - -is_bare_repository:: - outputs `true` or `false` to the standard output stream - to indicate if the repository is a bare repository - (i.e. without an associated working tree). - -cd_to_toplevel:: - runs chdir to the toplevel of the working tree. - -require_work_tree:: - checks if the current directory is within the working tree - of the repository, and otherwise dies. - -require_work_tree_exists:: - checks if the working tree associated with the repository - exists, and otherwise dies. Often done before calling - cd_to_toplevel, which is impossible to do if there is no - working tree. - -require_clean_work_tree <action> [<hint>]:: - checks that the working tree and index associated with the - repository have no uncommitted changes to tracked files. - Otherwise it emits an error message of the form `Cannot - <action>: <reason>. <hint>`, and dies. Example: -+ ----------------- -require_clean_work_tree rebase "Please commit or stash them." ----------------- - -get_author_ident_from_commit:: - outputs code for use with eval to set the GIT_AUTHOR_NAME, - GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE variables for a given commit. - -create_virtual_base:: - modifies the first file so only lines in common with the - second file remain. If there is insufficient common material, - then the first file is left empty. The result is suitable - as a virtual base input for a 3-way merge. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-shell.txt b/third_party/git/Documentation/git-shell.txt deleted file mode 100644 index 11361f33e9..0000000000 --- a/third_party/git/Documentation/git-shell.txt +++ /dev/null @@ -1,106 +0,0 @@ -git-shell(1) -============ - -NAME ----- -git-shell - Restricted login shell for Git-only SSH access - - -SYNOPSIS --------- -[verse] -'chsh' -s $(command -v git-shell) <user> -'git clone' <user>`@localhost:/path/to/repo.git` -'ssh' <user>`@localhost` - -DESCRIPTION ------------ - -This is a login shell for SSH accounts to provide restricted Git access. -It permits execution only of server-side Git commands implementing the -pull/push functionality, plus custom commands present in a subdirectory -named `git-shell-commands` in the user's home directory. - -COMMANDS --------- - -'git shell' accepts the following commands after the `-c` option: - -'git receive-pack <argument>':: -'git upload-pack <argument>':: -'git upload-archive <argument>':: - Call the corresponding server-side command to support - the client's 'git push', 'git fetch', or 'git archive --remote' - request. -'cvs server':: - Imitate a CVS server. See linkgit:git-cvsserver[1]. - -If a `~/git-shell-commands` directory is present, 'git shell' will -also handle other, custom commands by running -"`git-shell-commands/<command> <arguments>`" from the user's home -directory. - -INTERACTIVE USE ---------------- - -By default, the commands above can be executed only with the `-c` -option; the shell is not interactive. - -If a `~/git-shell-commands` directory is present, 'git shell' -can also be run interactively (with no arguments). If a `help` -command is present in the `git-shell-commands` directory, it is -run to provide the user with an overview of allowed actions. Then a -"git> " prompt is presented at which one can enter any of the -commands from the `git-shell-commands` directory, or `exit` to close -the connection. - -Generally this mode is used as an administrative interface to allow -users to list repositories they have access to, create, delete, or -rename repositories, or change repository descriptions and -permissions. - -If a `no-interactive-login` command exists, then it is run and the -interactive shell is aborted. - -EXAMPLES --------- - -To disable interactive logins, displaying a greeting instead: - ----------------- -$ chsh -s /usr/bin/git-shell -$ mkdir $HOME/git-shell-commands -$ cat >$HOME/git-shell-commands/no-interactive-login <<\EOF -#!/bin/sh -printf '%s\n' "Hi $USER! You've successfully authenticated, but I do not" -printf '%s\n' "provide interactive shell access." -exit 128 -EOF -$ chmod +x $HOME/git-shell-commands/no-interactive-login ----------------- - -To enable git-cvsserver access (which should generally have the -`no-interactive-login` example above as a prerequisite, as creating -the git-shell-commands directory allows interactive logins): - ----------------- -$ cat >$HOME/git-shell-commands/cvs <<\EOF -if ! test $# = 1 && test "$1" = "server" -then - echo >&2 "git-cvsserver only handles \"server\"" - exit 1 -fi -exec git cvsserver server -EOF -$ chmod +x $HOME/git-shell-commands/cvs ----------------- - -SEE ALSO --------- -ssh(1), -linkgit:git-daemon[1], -contrib/git-shell-commands/README - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-shortlog.txt b/third_party/git/Documentation/git-shortlog.txt deleted file mode 100644 index bc80905a8a..0000000000 --- a/third_party/git/Documentation/git-shortlog.txt +++ /dev/null @@ -1,90 +0,0 @@ -git-shortlog(1) -=============== - -NAME ----- -git-shortlog - Summarize 'git log' output - -SYNOPSIS --------- -[verse] -'git shortlog' [<options>] [<revision range>] [[--] <path>...] -git log --pretty=short | 'git shortlog' [<options>] - -DESCRIPTION ------------ -Summarizes 'git log' output in a format suitable for inclusion -in release announcements. Each commit will be grouped by author and title. - -Additionally, "[PATCH]" will be stripped from the commit description. - -If no revisions are passed on the command line and either standard input -is not a terminal or there is no current branch, 'git shortlog' will -output a summary of the log read from standard input, without -reference to the current repository. - -OPTIONS -------- - --n:: ---numbered:: - Sort output according to the number of commits per author instead - of author alphabetic order. - --s:: ---summary:: - Suppress commit description and provide a commit count summary only. - --e:: ---email:: - Show the email address of each author. - ---format[=<format>]:: - Instead of the commit subject, use some other information to - describe each commit. '<format>' can be any string accepted - by the `--format` option of 'git log', such as '* [%h] %s'. - (See the "PRETTY FORMATS" section of linkgit:git-log[1].) - - Each pretty-printed commit will be rewrapped before it is shown. - --c:: ---committer:: - Collect and show committer identities instead of authors. - --w[<width>[,<indent1>[,<indent2>]]]:: - Linewrap the output by wrapping each line at `width`. The first - line of each entry is indented by `indent1` spaces, and the second - and subsequent lines are indented by `indent2` spaces. `width`, - `indent1`, and `indent2` default to 76, 6 and 9 respectively. -+ -If width is `0` (zero) then indent the lines of the output without wrapping -them. - -<revision range>:: - Show only commits in the specified revision range. When no - <revision range> is specified, it defaults to `HEAD` (i.e. the - whole history leading to the current commit). `origin..HEAD` - specifies all the commits reachable from the current commit - (i.e. `HEAD`), but not from `origin`. For a complete list of - ways to spell <revision range>, see the "Specifying Ranges" - section of linkgit:gitrevisions[7]. - -[--] <path>...:: - Consider only commits that are enough to explain how the files - that match the specified paths came to be. -+ -Paths may need to be prefixed with `--` to separate them from -options or the revision range, when confusion arises. - -MAPPING AUTHORS ---------------- - -The `.mailmap` feature is used to coalesce together commits by the same -person in the shortlog, where their name and/or email address was -spelled differently. - -include::mailmap.txt[] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-show-branch.txt b/third_party/git/Documentation/git-show-branch.txt deleted file mode 100644 index 5cc2fcefba..0000000000 --- a/third_party/git/Documentation/git-show-branch.txt +++ /dev/null @@ -1,204 +0,0 @@ -git-show-branch(1) -================== - -NAME ----- -git-show-branch - Show branches and their commits - -SYNOPSIS --------- -[verse] -'git show-branch' [-a|--all] [-r|--remotes] [--topo-order | --date-order] - [--current] [--color[=<when>] | --no-color] [--sparse] - [--more=<n> | --list | --independent | --merge-base] - [--no-name | --sha1-name] [--topics] - [(<rev> | <glob>)...] -'git show-branch' (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>] - -DESCRIPTION ------------ - -Shows the commit ancestry graph starting from the commits named -with <rev>s or <glob>s (or all refs under refs/heads -and/or refs/tags) semi-visually. - -It cannot show more than 29 branches and commits at a time. - -It uses `showbranch.default` multi-valued configuration items if -no <rev> or <glob> is given on the command line. - - -OPTIONS -------- -<rev>:: - Arbitrary extended SHA-1 expression (see linkgit:gitrevisions[7]) - that typically names a branch head or a tag. - -<glob>:: - A glob pattern that matches branch or tag names under - refs/. For example, if you have many topic - branches under refs/heads/topic, giving - `topic/*` would show all of them. - --r:: ---remotes:: - Show the remote-tracking branches. - --a:: ---all:: - Show both remote-tracking branches and local branches. - ---current:: - With this option, the command includes the current - branch to the list of revs to be shown when it is not - given on the command line. - ---topo-order:: - By default, the branches and their commits are shown in - reverse chronological order. This option makes them - appear in topological order (i.e., descendant commits - are shown before their parents). - ---date-order:: - This option is similar to `--topo-order` in the sense that no - parent comes before all of its children, but otherwise commits - are ordered according to their commit date. - ---sparse:: - By default, the output omits merges that are reachable - from only one tip being shown. This option makes them - visible. - ---more=<n>:: - Usually the command stops output upon showing the commit - that is the common ancestor of all the branches. This - flag tells the command to go <n> more common commits - beyond that. When <n> is negative, display only the - <reference>s given, without showing the commit ancestry - tree. - ---list:: - Synonym to `--more=-1` - ---merge-base:: - Instead of showing the commit list, determine possible - merge bases for the specified commits. All merge bases - will be contained in all specified commits. This is - different from how linkgit:git-merge-base[1] handles - the case of three or more commits. - ---independent:: - Among the <reference>s given, display only the ones that - cannot be reached from any other <reference>. - ---no-name:: - Do not show naming strings for each commit. - ---sha1-name:: - Instead of naming the commits using the path to reach - them from heads (e.g. "master~2" to mean the grandparent - of "master"), name them with the unique prefix of their - object names. - ---topics:: - Shows only commits that are NOT on the first branch given. - This helps track topic branches by hiding any commit that - is already in the main line of development. When given - "git show-branch --topics master topic1 topic2", this - will show the revisions given by "git rev-list {caret}master - topic1 topic2" - --g:: ---reflog[=<n>[,<base>]] [<ref>]:: - Shows <n> most recent ref-log entries for the given - ref. If <base> is given, <n> entries going back from - that entry. <base> can be specified as count or date. - When no explicit <ref> parameter is given, it defaults to the - current branch (or `HEAD` if it is detached). - ---color[=<when>]:: - Color the status sign (one of these: `*` `!` `+` `-`) of each commit - corresponding to the branch it's in. - The value must be always (the default), never, or auto. - ---no-color:: - Turn off colored output, even when the configuration file gives the - default to color output. - Same as `--color=never`. - -Note that --more, --list, --independent and --merge-base options -are mutually exclusive. - - -OUTPUT ------- -Given N <references>, the first N lines are the one-line -description from their commit message. The branch head that is -pointed at by $GIT_DIR/HEAD is prefixed with an asterisk `*` -character while other heads are prefixed with a `!` character. - -Following these N lines, one-line log for each commit is -displayed, indented N places. If a commit is on the I-th -branch, the I-th indentation character shows a `+` sign; -otherwise it shows a space. Merge commits are denoted by -a `-` sign. Each commit shows a short name that -can be used as an extended SHA-1 to name that commit. - -The following example shows three branches, "master", "fixes" -and "mhf": - ------------------------------------------------- -$ git show-branch master fixes mhf -* [master] Add 'git show-branch'. - ! [fixes] Introduce "reset type" flag to "git reset" - ! [mhf] Allow "+remote:local" refspec to cause --force when fetching. ---- - + [mhf] Allow "+remote:local" refspec to cause --force when fetching. - + [mhf~1] Use git-octopus when pulling more than one heads. - + [fixes] Introduce "reset type" flag to "git reset" - + [mhf~2] "git fetch --force". - + [mhf~3] Use .git/remote/origin, not .git/branches/origin. - + [mhf~4] Make "git pull" and "git fetch" default to origin - + [mhf~5] Infamous 'octopus merge' - + [mhf~6] Retire git-parse-remote. - + [mhf~7] Multi-head fetch. - + [mhf~8] Start adding the $GIT_DIR/remotes/ support. -*++ [master] Add 'git show-branch'. ------------------------------------------------- - -These three branches all forked from a common commit, [master], -whose commit message is "Add \'git show-branch'". -The "fixes" branch adds one commit "Introduce "reset type" flag to -"git reset"". The "mhf" branch adds many other commits. -The current branch is "master". - - -EXAMPLES --------- - -If you keep your primary branches immediately under -`refs/heads`, and topic branches in subdirectories of -it, having the following in the configuration file may help: - ------------- -[showbranch] - default = --topo-order - default = heads/* - ------------- - -With this, `git show-branch` without extra parameters would show -only the primary branches. In addition, if you happen to be on -your topic branch, it is shown as well. - ------------- -$ git show-branch --reflog="10,1 hour ago" --list master ------------- - -shows 10 reflog entries going back from the tip as of 1 hour ago. -Without `--list`, the output also shows how these tips are -topologically related with each other. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-show-index.txt b/third_party/git/Documentation/git-show-index.txt deleted file mode 100644 index 424e4ba84c..0000000000 --- a/third_party/git/Documentation/git-show-index.txt +++ /dev/null @@ -1,41 +0,0 @@ -git-show-index(1) -================= - -NAME ----- -git-show-index - Show packed archive index - - -SYNOPSIS --------- -[verse] -'git show-index' - - -DESCRIPTION ------------ -Read the `.idx` file for a Git packfile (created with -linkgit:git-pack-objects[1] or linkgit:git-index-pack[1]) from the -standard input, and dump its contents. The output consists of one object -per line, with each line containing two or three space-separated -columns: - - - the first column is the offset in bytes of the object within the - corresponding packfile - - - the second column is the object id of the object - - - if the index version is 2 or higher, the third column contains the - CRC32 of the object data - -The objects are output in the order in which they are found in the index -file, which should be (in a correctly constructed file) sorted by object -id. - -Note that you can get more information on a packfile by calling -linkgit:git-verify-pack[1]. However, as this command considers only the -index file itself, it's both faster and more flexible. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-show-ref.txt b/third_party/git/Documentation/git-show-ref.txt deleted file mode 100644 index ab4d271925..0000000000 --- a/third_party/git/Documentation/git-show-ref.txt +++ /dev/null @@ -1,186 +0,0 @@ -git-show-ref(1) -=============== - -NAME ----- -git-show-ref - List references in a local repository - -SYNOPSIS --------- -[verse] -'git show-ref' [-q|--quiet] [--verify] [--head] [-d|--dereference] - [-s|--hash[=<n>]] [--abbrev[=<n>]] [--tags] - [--heads] [--] [<pattern>...] -'git show-ref' --exclude-existing[=<pattern>] - -DESCRIPTION ------------ - -Displays references available in a local repository along with the associated -commit IDs. Results can be filtered using a pattern and tags can be -dereferenced into object IDs. Additionally, it can be used to test whether a -particular ref exists. - -By default, shows the tags, heads, and remote refs. - -The --exclude-existing form is a filter that does the inverse. It reads -refs from stdin, one ref per line, and shows those that don't exist in -the local repository. - -Use of this utility is encouraged in favor of directly accessing files under -the `.git` directory. - -OPTIONS -------- - ---head:: - - Show the HEAD reference, even if it would normally be filtered out. - ---heads:: ---tags:: - - Limit to "refs/heads" and "refs/tags", respectively. These options - are not mutually exclusive; when given both, references stored in - "refs/heads" and "refs/tags" are displayed. - --d:: ---dereference:: - - Dereference tags into object IDs as well. They will be shown with "{caret}{}" - appended. - --s:: ---hash[=<n>]:: - - Only show the SHA-1 hash, not the reference name. When combined with - --dereference the dereferenced tag will still be shown after the SHA-1. - ---verify:: - - Enable stricter reference checking by requiring an exact ref path. - Aside from returning an error code of 1, it will also print an error - message if `--quiet` was not specified. - ---abbrev[=<n>]:: - - Abbreviate the object name. When using `--hash`, you do - not have to say `--hash --abbrev`; `--hash=n` would do. - --q:: ---quiet:: - - Do not print any results to stdout. When combined with `--verify` this - can be used to silently check if a reference exists. - ---exclude-existing[=<pattern>]:: - - Make 'git show-ref' act as a filter that reads refs from stdin of the - form "`^(?:<anything>\s)?<refname>(?:\^{})?$`" - and performs the following actions on each: - (1) strip "{caret}{}" at the end of line if any; - (2) ignore if pattern is provided and does not head-match refname; - (3) warn if refname is not a well-formed refname and skip; - (4) ignore if refname is a ref that exists in the local repository; - (5) otherwise output the line. - - -<pattern>...:: - - Show references matching one or more patterns. Patterns are matched from - the end of the full name, and only complete parts are matched, e.g. - 'master' matches 'refs/heads/master', 'refs/remotes/origin/master', - 'refs/tags/jedi/master' but not 'refs/heads/mymaster' or - 'refs/remotes/master/jedi'. - -OUTPUT ------- - -The output is in the format: '<SHA-1 ID>' '<space>' '<reference name>'. - ------------------------------------------------------------------------------ -$ git show-ref --head --dereference -832e76a9899f560a90ffd62ae2ce83bbeff58f54 HEAD -832e76a9899f560a90ffd62ae2ce83bbeff58f54 refs/heads/master -832e76a9899f560a90ffd62ae2ce83bbeff58f54 refs/heads/origin -3521017556c5de4159da4615a39fa4d5d2c279b5 refs/tags/v0.99.9c -6ddc0964034342519a87fe013781abf31c6db6ad refs/tags/v0.99.9c^{} -055e4ae3ae6eb344cbabf2a5256a49ea66040131 refs/tags/v1.0rc4 -423325a2d24638ddcc82ce47be5e40be550f4507 refs/tags/v1.0rc4^{} -... ------------------------------------------------------------------------------ - -When using --hash (and not --dereference) the output format is: '<SHA-1 ID>' - ------------------------------------------------------------------------------ -$ git show-ref --heads --hash -2e3ba0114a1f52b47df29743d6915d056be13278 -185008ae97960c8d551adcd9e23565194651b5d1 -03adf42c988195b50e1a1935ba5fcbc39b2b029b -... ------------------------------------------------------------------------------ - -EXAMPLES --------- - -To show all references called "master", whether tags or heads or anything -else, and regardless of how deep in the reference naming hierarchy they are, -use: - ------------------------------------------------------------------------------ - git show-ref master ------------------------------------------------------------------------------ - -This will show "refs/heads/master" but also "refs/remote/other-repo/master", -if such references exists. - -When using the `--verify` flag, the command requires an exact path: - ------------------------------------------------------------------------------ - git show-ref --verify refs/heads/master ------------------------------------------------------------------------------ - -will only match the exact branch called "master". - -If nothing matches, 'git show-ref' will return an error code of 1, -and in the case of verification, it will show an error message. - -For scripting, you can ask it to be quiet with the "--quiet" flag, which -allows you to do things like - ------------------------------------------------------------------------------ - git show-ref --quiet --verify -- "refs/heads/$headname" || - echo "$headname is not a valid branch" ------------------------------------------------------------------------------ - -to check whether a particular branch exists or not (notice how we don't -actually want to show any results, and we want to use the full refname for it -in order to not trigger the problem with ambiguous partial matches). - -To show only tags, or only proper branch heads, use "--tags" and/or "--heads" -respectively (using both means that it shows tags and heads, but not other -random references under the refs/ subdirectory). - -To do automatic tag object dereferencing, use the "-d" or "--dereference" -flag, so you can do - ------------------------------------------------------------------------------ - git show-ref --tags --dereference ------------------------------------------------------------------------------ - -to get a listing of all tags together with what they dereference. - -FILES ------ -`.git/refs/*`, `.git/packed-refs` - -SEE ALSO --------- -linkgit:git-for-each-ref[1], -linkgit:git-ls-remote[1], -linkgit:git-update-ref[1], -linkgit:gitrepository-layout[5] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-show.txt b/third_party/git/Documentation/git-show.txt deleted file mode 100644 index fcf528c1b3..0000000000 --- a/third_party/git/Documentation/git-show.txt +++ /dev/null @@ -1,87 +0,0 @@ -git-show(1) -=========== - -NAME ----- -git-show - Show various types of objects - - -SYNOPSIS --------- -[verse] -'git show' [<options>] [<object>...] - -DESCRIPTION ------------ -Shows one or more objects (blobs, trees, tags and commits). - -For commits it shows the log message and textual diff. It also -presents the merge commit in a special format as produced by -'git diff-tree --cc'. - -For tags, it shows the tag message and the referenced objects. - -For trees, it shows the names (equivalent to 'git ls-tree' -with --name-only). - -For plain blobs, it shows the plain contents. - -The command takes options applicable to the 'git diff-tree' command to -control how the changes the commit introduces are shown. - -This manual page describes only the most frequently used options. - - -OPTIONS -------- -<object>...:: - The names of objects to show (defaults to 'HEAD'). - For a more complete list of ways to spell object names, see - "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7]. - -include::pretty-options.txt[] - - -include::pretty-formats.txt[] - - -COMMON DIFF OPTIONS -------------------- - -:git-log: 1 -include::diff-options.txt[] - -include::diff-generate-patch.txt[] - - -EXAMPLES --------- - -`git show v1.0.0`:: - Shows the tag `v1.0.0`, along with the object the tags - points at. - -`git show v1.0.0^{tree}`:: - Shows the tree pointed to by the tag `v1.0.0`. - -`git show -s --format=%s v1.0.0^{commit}`:: - Shows the subject of the commit pointed to by the - tag `v1.0.0`. - -`git show next~10:Documentation/README`:: - Shows the contents of the file `Documentation/README` as - they were current in the 10th last commit of the branch - `next`. - -`git show master:Makefile master:t/Makefile`:: - Concatenates the contents of said Makefiles in the head - of the branch `master`. - -DISCUSSION ----------- - -include::i18n.txt[] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-stage.txt b/third_party/git/Documentation/git-stage.txt deleted file mode 100644 index 25bcda936d..0000000000 --- a/third_party/git/Documentation/git-stage.txt +++ /dev/null @@ -1,23 +0,0 @@ -git-stage(1) -============ - -NAME ----- -git-stage - Add file contents to the staging area - - -SYNOPSIS --------- -[verse] -'git stage' args... - - -DESCRIPTION ------------ - -This is a synonym for linkgit:git-add[1]. Please refer to the -documentation of that command. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-stash.txt b/third_party/git/Documentation/git-stash.txt deleted file mode 100644 index 8fbe12c66c..0000000000 --- a/third_party/git/Documentation/git-stash.txt +++ /dev/null @@ -1,301 +0,0 @@ -git-stash(1) -============ - -NAME ----- -git-stash - Stash the changes in a dirty working directory away - -SYNOPSIS --------- -[verse] -'git stash' list [<options>] -'git stash' show [<options>] [<stash>] -'git stash' drop [-q|--quiet] [<stash>] -'git stash' ( pop | apply ) [--index] [-q|--quiet] [<stash>] -'git stash' branch <branchname> [<stash>] -'git stash' [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] - [-u|--include-untracked] [-a|--all] [-m|--message <message>] - [--] [<pathspec>...]] -'git stash' clear -'git stash' create [<message>] -'git stash' store [-m|--message <message>] [-q|--quiet] <commit> - -DESCRIPTION ------------ - -Use `git stash` when you want to record the current state of the -working directory and the index, but want to go back to a clean -working directory. The command saves your local modifications away -and reverts the working directory to match the `HEAD` commit. - -The modifications stashed away by this command can be listed with -`git stash list`, inspected with `git stash show`, and restored -(potentially on top of a different commit) with `git stash apply`. -Calling `git stash` without any arguments is equivalent to `git stash push`. -A stash is by default listed as "WIP on 'branchname' ...", but -you can give a more descriptive message on the command line when -you create one. - -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). Stashes may also be referenced by specifying just the -stash index (e.g. the integer `n` is equivalent to `stash@{n}`). - -OPTIONS -------- - -push [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [-m|--message <message>] [--] [<pathspec>...]:: - - Save your local modifications to a new 'stash entry' and roll them - back to HEAD (in the working tree and in the index). - The <message> part is optional and gives - the description along with the stashed state. -+ -For quickly making a snapshot, you can omit "push". In this mode, -non-option arguments are not allowed to prevent a misspelled -subcommand from making an unwanted stash entry. The two exceptions to this -are `stash -p` which acts as alias for `stash push -p` and pathspecs, -which are allowed after a double hyphen `--` for disambiguation. -+ -When pathspec is given to 'git stash push', the new stash entry records the -modified states only for the files that match the pathspec. The index -entries and working tree files are then rolled back to the state in -HEAD only for these files, too, leaving files that do not match the -pathspec intact. -+ -If the `--keep-index` option is used, all changes already added to the -index are left intact. -+ -If the `--include-untracked` option is used, all untracked files are also -stashed and then cleaned up with `git clean`, leaving the working directory -in a very clean state. If the `--all` option is used instead then the -ignored files are stashed and cleaned in addition to the untracked files. -+ -With `--patch`, you can interactively select hunks from the diff -between HEAD and the working tree to be stashed. The stash entry is -constructed such that its index state is the same as the index state -of your repository, and its worktree contains only the changes you -selected interactively. The selected changes are then rolled back -from your worktree. See the ``Interactive Mode'' section of -linkgit:git-add[1] to learn how to operate the `--patch` mode. -+ -The `--patch` option implies `--keep-index`. You can use -`--no-keep-index` to override this. - -save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]:: - - This option is deprecated in favour of 'git stash push'. It - differs from "stash push" in that it cannot take pathspecs, - and any non-option arguments form the message. - -list [<options>]:: - - List the stash entries that you currently have. Each 'stash entry' is - listed with its name (e.g. `stash@{0}` is the latest entry, `stash@{1}` is - the one before, etc.), the name of the branch that was current when the - entry was made, and a short description of the commit the entry was - based on. -+ ----------------------------------------------------------------- -stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation -stash@{1}: On master: 9cc0589... Add git-stash ----------------------------------------------------------------- -+ -The command takes options applicable to the 'git log' -command to control what is shown and how. See linkgit:git-log[1]. - -show [<options>] [<stash>]:: - - Show the changes recorded in the stash entry as a diff between the - stashed contents and the commit back when the stash entry was first - created. When no `<stash>` is given, it shows the latest one. - By default, the command shows the diffstat, but it will accept any - format known to 'git diff' (e.g., `git stash show -p stash@{1}` - to view the second most recent entry in patch form). - You can use stash.showStat and/or stash.showPatch config variables - to change the default behavior. - -pop [--index] [-q|--quiet] [<stash>]:: - - Remove a single stashed state from the stash list and apply it - on top of the current working tree state, i.e., do the inverse - operation of `git stash push`. The working directory must - match the index. -+ -Applying the state can fail with conflicts; in this case, it is not -removed from the stash list. You need to resolve the conflicts by hand -and call `git stash drop` manually afterwards. -+ -If the `--index` option is used, then tries to reinstate not only the working -tree's changes, but also the index's ones. However, this can fail, when you -have conflicts (which are stored in the index, where you therefore can no -longer apply the changes as they were originally). -+ -When no `<stash>` is given, `stash@{0}` is assumed, otherwise `<stash>` must -be a reference of the form `stash@{<revision>}`. - -apply [--index] [-q|--quiet] [<stash>]:: - - Like `pop`, but do not remove the state from the stash list. Unlike `pop`, - `<stash>` may be any commit that looks like a commit created by - `stash push` or `stash create`. - -branch <branchname> [<stash>]:: - - Creates and checks out a new branch named `<branchname>` starting from - the commit at which the `<stash>` was originally created, applies the - changes recorded in `<stash>` to the new working tree and index. - If that succeeds, and `<stash>` is a reference of the form - `stash@{<revision>}`, it then drops the `<stash>`. When no `<stash>` - is given, applies the latest one. -+ -This is useful if the branch on which you ran `git stash push` has -changed enough that `git stash apply` fails due to conflicts. Since -the stash entry is applied on top of the commit that was HEAD at the -time `git stash` was run, it restores the originally stashed state -with no conflicts. - -clear:: - Remove all the stash entries. Note that those entries will then - be subject to pruning, and may be impossible to recover (see - 'Examples' below for a possible strategy). - -drop [-q|--quiet] [<stash>]:: - - Remove a single stash entry from the list of stash entries. - When no `<stash>` is given, it removes the latest one. - i.e. `stash@{0}`, otherwise `<stash>` must be a valid stash - log reference of the form `stash@{<revision>}`. - -create:: - - Create a stash entry (which is a regular commit object) and - return its object name, without storing it anywhere in the ref - namespace. - This is intended to be useful for scripts. It is probably not - the command you want to use; see "push" above. - -store:: - - Store a given stash created via 'git stash create' (which is a - dangling merge commit) in the stash ref, updating the stash - reflog. This is intended to be useful for scripts. It is - probably not the command you want to use; see "push" above. - -DISCUSSION ----------- - -A stash entry is represented as a commit whose tree records the state -of the working directory, and its first parent is the commit at `HEAD` -when the entry was created. The tree of the second parent records the -state of the index when the entry is made, and it is made a child of -the `HEAD` commit. The ancestry graph looks like this: - - .----W - / / - -----H----I - -where `H` is the `HEAD` commit, `I` is a commit that records the state -of the index, and `W` is a commit that records the state of the working -tree. - - -EXAMPLES --------- - -Pulling into a dirty tree:: - -When you are in the middle of something, you learn that there are -upstream changes that are possibly relevant to what you are -doing. When your local changes do not conflict with the changes in -the upstream, a simple `git pull` will let you move forward. -+ -However, there are cases in which your local changes do conflict with -the upstream changes, and `git pull` refuses to overwrite your -changes. In such a case, you can stash your changes away, -perform a pull, and then unstash, like this: -+ ----------------------------------------------------------------- -$ git pull - ... -file foobar not up to date, cannot merge. -$ git stash -$ git pull -$ git stash pop ----------------------------------------------------------------- - -Interrupted workflow:: - -When you are in the middle of something, your boss comes in and -demands that you fix something immediately. Traditionally, you would -make a commit to a temporary branch to store your changes away, and -return to your original branch to make the emergency fix, like this: -+ ----------------------------------------------------------------- -# ... hack hack hack ... -$ git switch -c my_wip -$ git commit -a -m "WIP" -$ git switch master -$ edit emergency fix -$ git commit -a -m "Fix in a hurry" -$ git switch my_wip -$ git reset --soft HEAD^ -# ... continue hacking ... ----------------------------------------------------------------- -+ -You can use 'git stash' to simplify the above, like this: -+ ----------------------------------------------------------------- -# ... hack hack hack ... -$ git stash -$ edit emergency fix -$ git commit -a -m "Fix in a hurry" -$ git stash pop -# ... continue hacking ... ----------------------------------------------------------------- - -Testing partial commits:: - -You can use `git stash push --keep-index` when you want to make two or -more commits out of the changes in the work tree, and you want to test -each change before committing: -+ ----------------------------------------------------------------- -# ... hack hack hack ... -$ git add --patch foo # add just first part to the index -$ git stash push --keep-index # save all other changes to the stash -$ edit/build/test first part -$ git commit -m 'First part' # commit fully tested change -$ git stash pop # prepare to work on all other changes -# ... repeat above five steps until one commit remains ... -$ edit/build/test remaining parts -$ git commit foo -m 'Remaining parts' ----------------------------------------------------------------- - -Recovering stash entries that were cleared/dropped erroneously:: - -If you mistakenly drop or clear stash entries, they cannot be recovered -through the normal safety mechanisms. However, you can try the -following incantation to get a list of stash entries that are still in -your repository, but not reachable any more: -+ ----------------------------------------------------------------- -git fsck --unreachable | -grep commit | cut -d\ -f3 | -xargs git log --merges --no-walk --grep=WIP ----------------------------------------------------------------- - - -SEE ALSO --------- -linkgit:git-checkout[1], -linkgit:git-commit[1], -linkgit:git-reflog[1], -linkgit:git-reset[1], -linkgit:git-switch[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-status.txt b/third_party/git/Documentation/git-status.txt deleted file mode 100644 index d4e8f24f0c..0000000000 --- a/third_party/git/Documentation/git-status.txt +++ /dev/null @@ -1,439 +0,0 @@ -git-status(1) -============= - -NAME ----- -git-status - Show the working tree status - - -SYNOPSIS --------- -[verse] -'git status' [<options>...] [--] [<pathspec>...] - -DESCRIPTION ------------ -Displays paths that have differences between the index file and the -current HEAD commit, paths that have differences between the working -tree and the index file, and paths in the working tree that are not -tracked by Git (and are not ignored by linkgit:gitignore[5]). The first -are what you _would_ commit by running `git commit`; the second and -third are what you _could_ commit by running 'git add' before running -`git commit`. - -OPTIONS -------- - --s:: ---short:: - Give the output in the short-format. - --b:: ---branch:: - Show the branch and tracking info even in short-format. - ---show-stash:: - Show the number of entries currently stashed away. - ---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. - --v:: ---verbose:: - In addition to the names of files that have been changed, also - show the textual changes that are staged to be committed - (i.e., like the output of `git diff --cached`). If `-v` is specified - twice, then also show the changes in the working tree that - have not yet been staged (i.e., like the output of `git diff`). - --u[<mode>]:: ---untracked-files[=<mode>]:: - Show untracked files. -+ -The mode parameter is used to specify the handling of untracked files. -It is optional: it defaults to 'all', and if specified, it must be -stuck to the option (e.g. `-uno`, but not `-u no`). -+ -The possible options are: -+ - - 'no' - Show no untracked files. - - 'normal' - Shows untracked files and directories. - - 'all' - Also shows individual files in untracked directories. -+ -When `-u` option is not used, untracked files and directories are -shown (i.e. the same as specifying `normal`), to help you avoid -forgetting to add newly created files. Because it takes extra work -to find untracked files in the filesystem, this mode may take some -time in a large working tree. -Consider enabling untracked cache and split index if supported (see -`git update-index --untracked-cache` and `git update-index ---split-index`), Otherwise you can use `no` to have `git status` -return more quickly without showing untracked files. -+ -The default can be changed using the status.showUntrackedFiles -configuration variable documented in linkgit:git-config[1]. - ---ignore-submodules[=<when>]:: - Ignore changes to submodules when looking for changes. <when> can be - either "none", "untracked", "dirty" or "all", which is the default. - Using "none" will consider the submodule modified when it either contains - untracked or modified files or its HEAD differs from the commit recorded - in the superproject and can be used to override any settings of the - 'ignore' option in linkgit:git-config[1] or linkgit:gitmodules[5]. When - "untracked" is used submodules are not considered dirty when they only - contain untracked content (but they are still scanned for modified - content). Using "dirty" ignores all changes to the work tree of submodules, - only changes to the commits stored in the superproject are shown (this was - the behavior before 1.7.0). Using "all" hides all changes to submodules - (and suppresses the output of submodule summaries when the config option - `status.submoduleSummary` is set). - ---ignored[=<mode>]:: - Show ignored files as well. -+ -The mode parameter is used to specify the handling of ignored files. -It is optional: it defaults to 'traditional'. -+ -The possible options are: -+ - - 'traditional' - Shows ignored files and directories, unless - --untracked-files=all is specified, in which case - individual files in ignored directories are - displayed. - - 'no' - Show no ignored files. - - 'matching' - Shows ignored files and directories matching an - ignore pattern. -+ -When 'matching' mode is specified, paths that explicitly match an -ignored pattern are shown. If a directory matches an ignore pattern, -then it is shown, but not paths contained in the ignored directory. If -a directory does not match an ignore pattern, but all contents are -ignored, then the directory is not shown, but all contents are shown. - --z:: - Terminate entries with NUL, instead of LF. This implies - the `--porcelain=v1` output format if no other format is given. - ---column[=<options>]:: ---no-column:: - Display untracked files in columns. See configuration variable - column.status for option syntax.`--column` and `--no-column` - without options are equivalent to 'always' and 'never' - respectively. - ---ahead-behind:: ---no-ahead-behind:: - Display or do not display detailed ahead/behind counts for the - branch relative to its upstream branch. Defaults to true. - ---renames:: ---no-renames:: - Turn on/off rename detection regardless of user configuration. - See also linkgit:git-diff[1] `--no-renames`. - ---find-renames[=<n>]:: - Turn on rename detection, optionally setting the similarity - threshold. - See also linkgit:git-diff[1] `--find-renames`. - -<pathspec>...:: - See the 'pathspec' entry in linkgit:gitglossary[7]. - -OUTPUT ------- -The output from this command is designed to be used as a commit -template comment. -The default, long format, is designed to be human readable, -verbose and descriptive. Its contents and format are subject to change -at any time. - -The paths mentioned in the output, unlike many other Git commands, are -made relative to the current directory if you are working in a -subdirectory (this is on purpose, to help cutting and pasting). See -the status.relativePaths config option below. - -Short Format -~~~~~~~~~~~~ - -In the short-format, the status of each path is shown as one of these -forms - - XY PATH - XY ORIG_PATH -> PATH - -where `ORIG_PATH` is where the renamed/copied contents came -from. `ORIG_PATH` is only shown when the entry is renamed or -copied. The `XY` is a two-letter status code. - -The fields (including the `->`) are separated from each other by a -single space. If a filename contains whitespace or other nonprintable -characters, that field will be quoted in the manner of a C string -literal: surrounded by ASCII double quote (34) characters, and with -interior special characters backslash-escaped. - -For paths with merge conflicts, `X` and `Y` show the modification -states of each side of the merge. For paths that do not have merge -conflicts, `X` shows the status of the index, and `Y` shows the status -of the work tree. For untracked paths, `XY` are `??`. Other status -codes can be interpreted as follows: - -* ' ' = unmodified -* 'M' = modified -* 'A' = added -* 'D' = deleted -* 'R' = renamed -* 'C' = copied -* 'U' = updated but unmerged - -Ignored files are not listed, unless `--ignored` option is in effect, -in which case `XY` are `!!`. - -.... -X Y Meaning -------------------------------------------------- - [AMD] not updated -M [ MD] updated in index -A [ MD] added to index -D deleted from index -R [ MD] renamed in index -C [ MD] copied in index -[MARC] index and work tree matches -[ MARC] M work tree changed since index -[ MARC] D deleted in work tree -[ D] R renamed in work tree -[ D] C copied in work tree -------------------------------------------------- -D D unmerged, both deleted -A U unmerged, added by us -U D unmerged, deleted by them -U A unmerged, added by them -D U unmerged, deleted by us -A A unmerged, both added -U U unmerged, both modified -------------------------------------------------- -? ? untracked -! ! ignored -------------------------------------------------- -.... - -Submodules have more state and instead report - M the submodule has a different HEAD than - recorded in the index - m the submodule has modified content - ? the submodule has untracked files -since modified content or untracked files in a submodule cannot be added -via `git add` in the superproject to prepare a commit. - -'m' and '?' are applied recursively. For example if a nested submodule -in a submodule contains an untracked file, this is reported as '?' as well. - -If -b is used the short-format status is preceded by a line - - ## branchname tracking info - -Porcelain Format Version 1 -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -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 -format, with a few exceptions: - -1. The user's color.status configuration is not respected; color will - always be off. - -2. The user's status.relativePaths configuration is not respected; paths - shown will always be relative to the repository root. - -There is also an alternate -z format recommended for machine parsing. In -that format, the status field is the same, but some other things -change. First, the '\->' is omitted from rename entries and the field -order is reversed (e.g 'from \-> to' becomes 'to from'). Second, a NUL -(ASCII 0) follows each filename, replacing space as a field separator -and the terminating newline (but a space still separates the status -field from the first filename). Third, filenames containing special -characters are not specially formatted; no quoting or -backslash-escaping is performed. - -Any submodule changes are reported as modified `M` instead of `m` or single `?`. - -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 target path. -<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 or in the index. - 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. - -Without the `-z` option, pathnames with "unusual" characters are -quoted as explained for the configuration variable `core.quotePath` -(see linkgit:git-config[1]). - - -CONFIGURATION -------------- - -The command honors `color.status` (or `status.color` -- they -mean the same thing and the latter is kept for backward -compatibility) and `color.status.<slot>` configuration variables -to colorize its output. - -If the config variable `status.relativePaths` is set to false, then all -paths shown are relative to the repository root, not to the current -directory. - -If `status.submoduleSummary` is set to a non zero number or true (identical -to -1 or an unlimited number), the submodule summary will be enabled for -the long format and a summary of commits for modified submodules will be -shown (see --summary-limit option of linkgit:git-submodule[1]). Please note -that the summary output from the status command will be suppressed for all -submodules when `diff.ignoreSubmodules` is set to 'all' or only for those -submodules where `submodule.<name>.ignore=all`. To also view the summary for -ignored submodules you can either use the --ignore-submodules=dirty command -line option or the 'git submodule summary' command, which shows a similar -output but does not honor these settings. - -BACKGROUND REFRESH ------------------- - -By default, `git status` will automatically refresh the index, updating -the cached stat information from the working tree and writing out the -result. Writing out the updated index is an optimization that isn't -strictly necessary (`status` computes the values for itself, but writing -them out is just to save subsequent programs from repeating our -computation). When `status` is run in the background, the lock held -during the write may conflict with other simultaneous processes, causing -them to fail. Scripts running `status` in the background should consider -using `git --no-optional-locks status` (see linkgit:git[1] for details). - -SEE ALSO --------- -linkgit:gitignore[5] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-stripspace.txt b/third_party/git/Documentation/git-stripspace.txt deleted file mode 100644 index 2438f76da0..0000000000 --- a/third_party/git/Documentation/git-stripspace.txt +++ /dev/null @@ -1,94 +0,0 @@ -git-stripspace(1) -================= - -NAME ----- -git-stripspace - Remove unnecessary whitespace - - -SYNOPSIS --------- -[verse] -'git stripspace' [-s | --strip-comments] -'git stripspace' [-c | --comment-lines] - -DESCRIPTION ------------ - -Read text, such as commit messages, notes, tags and branch -descriptions, from the standard input and clean it in the manner -used by Git. - -With no arguments, this will: - -- remove trailing whitespace from all lines -- collapse multiple consecutive empty lines into one empty line -- remove empty lines from the beginning and end of the input -- add a missing '\n' to the last line if necessary. - -In the case where the input consists entirely of whitespace characters, no -output will be produced. - -*NOTE*: This is intended for cleaning metadata, prefer the `--whitespace=fix` -mode of linkgit:git-apply[1] for correcting whitespace of patches or files in -the repository. - -OPTIONS -------- --s:: ---strip-comments:: - Skip and remove all lines starting with comment character (default '#'). - --c:: ---comment-lines:: - Prepend comment character and blank to each line. Lines will automatically - be terminated with a newline. On empty lines, only the comment character - will be prepended. - -EXAMPLES --------- - -Given the following noisy input with '$' indicating the end of a line: - ---------- -|A brief introduction $ -| $ -|$ -|A new paragraph$ -|# with a commented-out line $ -|explaining lots of stuff.$ -|$ -|# An old paragraph, also commented-out. $ -| $ -|The end.$ -| $ ---------- - -Use 'git stripspace' with no arguments to obtain: - ---------- -|A brief introduction$ -|$ -|A new paragraph$ -|# with a commented-out line$ -|explaining lots of stuff.$ -|$ -|# An old paragraph, also commented-out.$ -|$ -|The end.$ ---------- - -Use 'git stripspace --strip-comments' to obtain: - ---------- -|A brief introduction$ -|$ -|A new paragraph$ -|explaining lots of stuff.$ -|$ -|The end.$ ---------- - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-submodule.txt b/third_party/git/Documentation/git-submodule.txt deleted file mode 100644 index 0ed5c24dc1..0000000000 --- a/third_party/git/Documentation/git-submodule.txt +++ /dev/null @@ -1,441 +0,0 @@ -git-submodule(1) -================ - -NAME ----- -git-submodule - Initialize, update or inspect submodules - - -SYNOPSIS --------- -[verse] -'git submodule' [--quiet] [--cached] -'git submodule' [--quiet] add [<options>] [--] <repository> [<path>] -'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...] -'git submodule' [--quiet] init [--] [<path>...] -'git submodule' [--quiet] deinit [-f|--force] (--all|[--] <path>...) -'git submodule' [--quiet] update [<options>] [--] [<path>...] -'git submodule' [--quiet] set-branch [<options>] [--] <path> -'git submodule' [--quiet] summary [<options>] [--] [<path>...] -'git submodule' [--quiet] foreach [--recursive] <command> -'git submodule' [--quiet] sync [--recursive] [--] [<path>...] -'git submodule' [--quiet] absorbgitdirs [--] [<path>...] - - -DESCRIPTION ------------ -Inspects, updates and manages submodules. - -For more information about submodules, see linkgit:gitsubmodules[7]. - -COMMANDS --------- -With no arguments, shows the status of existing submodules. Several -subcommands are available to perform operations on the submodules. - -add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--depth <depth>] [--] <repository> [<path>]:: - Add the given repository as a submodule at the given path - to the changeset to be committed next to the current - project: the current project is termed the "superproject". -+ -<repository> is the URL of the new submodule's origin repository. -This may be either an absolute URL, or (if it begins with ./ -or ../), the location relative to the superproject's default remote -repository (Please note that to specify a repository 'foo.git' -which is located right next to a superproject 'bar.git', you'll -have to use `../foo.git` instead of `./foo.git` - as one might expect -when following the rules for relative URLs - because the evaluation -of relative URLs in Git is identical to that of relative directories). -+ -The default remote is the remote of the remote-tracking branch -of the current branch. If no such remote-tracking branch exists or -the HEAD is detached, "origin" is assumed to be the default remote. -If the superproject doesn't have a default remote configured -the superproject is its own authoritative upstream and the current -working directory is used instead. -+ -The optional argument <path> is the relative location for the cloned -submodule to exist in the superproject. If <path> is not given, the -canonical part of the source repository is used ("repo" for -"/path/to/repo.git" and "foo" for "host.xz:foo/.git"). If <path> -exists and is already a valid Git repository, then it is staged -for commit without cloning. The <path> is also used as the submodule's -logical name in its configuration entries unless `--name` is used -to specify a logical name. -+ -The given URL is recorded into `.gitmodules` for use by subsequent users -cloning the superproject. If the URL is given relative to the -superproject's repository, the presumption is the superproject and -submodule repositories will be kept together in the same relative -location, and only the superproject's URL needs to be provided. -git-submodule will correctly locate the submodule using the relative -URL in `.gitmodules`. - -status [--cached] [--recursive] [--] [<path>...]:: - Show the status of the submodules. This will print the SHA-1 of the - currently checked out commit for each submodule, along with the - submodule path and the output of 'git describe' for the - SHA-1. Each SHA-1 will possibly be prefixed with `-` if the submodule is - not initialized, `+` if the currently checked out submodule commit - does not match the SHA-1 found in the index of the containing - repository and `U` if the submodule has merge conflicts. -+ -If `--recursive` is specified, this command will recurse into nested -submodules, and show their status as well. -+ -If you are only interested in changes of the currently initialized -submodules with respect to the commit recorded in the index or the HEAD, -linkgit:git-status[1] and linkgit:git-diff[1] will provide that information -too (and can also report changes to a submodule's work tree). - -init [--] [<path>...]:: - Initialize the submodules recorded in the index (which were - added and committed elsewhere) by setting `submodule.$name.url` - in .git/config. It uses the same setting from `.gitmodules` as - a template. If the URL is relative, it will be resolved using - the default remote. If there is no default remote, the current - repository will be assumed to be upstream. -+ -Optional <path> arguments limit which submodules will be initialized. -If no path is specified and submodule.active has been configured, submodules -configured to be active will be initialized, otherwise all submodules are -initialized. -+ -When present, it will also copy the value of `submodule.$name.update`. -This command does not alter existing information in .git/config. -You can then customize the submodule clone URLs in .git/config -for your local setup and proceed to `git submodule update`; -you can also just use `git submodule update --init` without -the explicit 'init' step if you do not intend to customize -any submodule locations. -+ -See the add subcommand for the definition of default remote. - -deinit [-f|--force] (--all|[--] <path>...):: - Unregister the given submodules, i.e. remove the whole - `submodule.$name` section from .git/config together with their work - tree. Further calls to `git submodule update`, `git submodule foreach` - and `git submodule sync` will skip any unregistered submodules until - they are initialized again, so use this command if you don't want to - have a local checkout of the submodule in your working tree anymore. -+ -When the command is run without pathspec, it errors out, -instead of deinit-ing everything, to prevent mistakes. -+ -If `--force` is specified, the submodule's working tree will -be removed even if it contains local modifications. -+ -If you really want to remove a submodule from the repository and commit -that use linkgit:git-rm[1] instead. See linkgit:gitsubmodules[7] for removal -options. - -update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow] [-f|--force] [--checkout|--rebase|--merge] [--reference <repository>] [--depth <depth>] [--recursive] [--jobs <n>] [--] [<path>...]:: -+ --- -Update the registered submodules to match what the superproject -expects by cloning missing submodules and updating the working tree of -the submodules. The "updating" can be done in several ways depending -on command line options and the value of `submodule.<name>.update` -configuration variable. The command line option takes precedence over -the configuration variable. If neither is given, a 'checkout' is performed. -The 'update' procedures supported both from the command line as well as -through the `submodule.<name>.update` configuration are: - - checkout;; the commit recorded in the superproject will be - checked out in the submodule on a detached HEAD. -+ -If `--force` is specified, the submodule will be checked out (using -`git checkout --force`), even if the commit specified -in the index of the containing repository already matches the commit -checked out in the submodule. - - rebase;; the current branch of the submodule will be rebased - onto the commit recorded in the superproject. - - merge;; the commit recorded in the superproject will be merged - into the current branch in the submodule. - -The following 'update' procedures are only available via the -`submodule.<name>.update` configuration variable: - - custom command;; arbitrary shell command that takes a single - argument (the sha1 of the commit recorded in the - superproject) is executed. When `submodule.<name>.update` - is set to '!command', the remainder after the exclamation mark - is the custom command. - - none;; the submodule is not updated. - -If the submodule is not yet initialized, and you just want to use the -setting as stored in `.gitmodules`, you can automatically initialize the -submodule with the `--init` option. - -If `--recursive` is specified, this command will recurse into the -registered submodules, and update any nested submodules within. --- -set-branch ((-d|--default)|(-b|--branch <branch>)) [--] <path>:: - Sets the default remote tracking branch for the submodule. The - `--branch` option allows the remote branch to be specified. The - `--default` option removes the submodule.<name>.branch configuration - key, which causes the tracking branch to default to 'master'. - -summary [--cached|--files] [(-n|--summary-limit) <n>] [commit] [--] [<path>...]:: - Show commit summary between the given commit (defaults to HEAD) and - working tree/index. For a submodule in question, a series of commits - in the submodule between the given super project commit and the - index or working tree (switched by `--cached`) are shown. If the option - `--files` is given, show the series of commits in the submodule between - the index of the super project and the working tree of the submodule - (this option doesn't allow to use the `--cached` option or to provide an - explicit commit). -+ -Using the `--submodule=log` option with linkgit:git-diff[1] will provide that -information too. - -foreach [--recursive] <command>:: - Evaluates an arbitrary shell command in each checked out submodule. - The command has access to the variables $name, $sm_path, $displaypath, - $sha1 and $toplevel: - $name is the name of the relevant submodule section in `.gitmodules`, - $sm_path is the path of the submodule as recorded in the immediate - superproject, $displaypath contains the relative path from the - current working directory to the submodules root directory, - $sha1 is the commit as recorded in the immediate - superproject, and $toplevel is the absolute path to the top-level - of the immediate superproject. - Note that to avoid conflicts with '$PATH' on Windows, the '$path' - variable is now a deprecated synonym of '$sm_path' variable. - Any submodules defined in the superproject but not checked out are - ignored by this command. Unless given `--quiet`, foreach prints the name - of each submodule before evaluating the command. - If `--recursive` is given, submodules are traversed recursively (i.e. - the given shell command is evaluated in nested submodules as well). - A non-zero return from the command in any submodule causes - the processing to terminate. This can be overridden by adding '|| :' - to the end of the command. -+ -As an example, the command below will show the path and currently -checked out commit for each submodule: -+ --------------- -git submodule foreach 'echo $path `git rev-parse HEAD`' --------------- - -sync [--recursive] [--] [<path>...]:: - Synchronizes submodules' remote URL configuration setting - to the value specified in `.gitmodules`. It will only affect those - submodules which already have a URL entry in .git/config (that is the - case when they are initialized or freshly added). This is useful when - submodule URLs change upstream and you need to update your local - repositories accordingly. -+ -`git submodule sync` synchronizes all submodules while -`git submodule sync -- A` synchronizes submodule "A" only. -+ -If `--recursive` is specified, this command will recurse into the -registered submodules, and sync any nested submodules within. - -absorbgitdirs:: - If a git directory of a submodule is inside the submodule, - move the git directory of the submodule into its superprojects - `$GIT_DIR/modules` path and then connect the git directory and - its working directory by setting the `core.worktree` and adding - a .git file pointing to the git directory embedded in the - superprojects git directory. -+ -A repository that was cloned independently and later added as a submodule or -old setups have the submodules git directory inside the submodule instead of -embedded into the superprojects git directory. -+ -This command is recursive by default. - -OPTIONS -------- --q:: ---quiet:: - Only print error messages. - ---progress:: - This option is only valid for add and update commands. - Progress status is reported on the standard error stream - by default when it is attached to a terminal, unless -q - is specified. This flag forces progress status even if the - standard error stream is not directed to a terminal. - ---all:: - This option is only valid for the deinit command. Unregister all - submodules in the working tree. - --b <branch>:: ---branch <branch>:: - Branch of repository to add as submodule. - The name of the branch is recorded as `submodule.<name>.branch` in - `.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. If the - option is not specified, it defaults to 'master'. - --f:: ---force:: - This option is only valid for add, deinit and update commands. - When running add, allow adding an otherwise ignored submodule path. - When running deinit the submodule working trees will be removed even - if they contain local changes. - When running update (only effective with the checkout procedure), - throw away local changes in submodules when switching to a - different commit; and always run a checkout operation in the - submodule, even if the commit listed in the index of the - containing repository matches the commit checked out in the - submodule. - ---cached:: - This option is only valid for status and summary commands. These - commands typically use the commit found in the submodule HEAD, but - with this option, the commit stored in the index is used instead. - ---files:: - This option is only valid for the summary command. This command - compares the commit in the index with that in the submodule HEAD - when this option is used. - --n:: ---summary-limit:: - This option is only valid for the summary command. - Limit the summary size (number of commits shown in total). - Giving 0 will disable the summary; a negative number means unlimited - (the default). This limit only applies to modified submodules. The - size is always limited to 1 for added/deleted/typechanged submodules. - ---remote:: - This option is only valid for the update command. Instead of using - the superproject's recorded SHA-1 to update the submodule, use the - status of the submodule's remote-tracking branch. The remote used - is branch's remote (`branch.<name>.remote`), defaulting to `origin`. - The remote branch used defaults to `master`, but the branch name may - be overridden by setting the `submodule.<name>.branch` option in - either `.gitmodules` or `.git/config` (with `.git/config` taking - precedence). -+ -This works for any of the supported update procedures (`--checkout`, -`--rebase`, etc.). The only change is the source of the target SHA-1. -For example, `submodule update --remote --merge` will merge upstream -submodule changes into the submodules, while `submodule update ---merge` will merge superproject gitlink changes into the submodules. -+ -In order to ensure a current tracking branch state, `update --remote` -fetches the submodule's remote repository before calculating the -SHA-1. If you don't want to fetch, you should use `submodule update ---remote --no-fetch`. -+ -Use this option to integrate changes from the upstream subproject with -your submodule's current HEAD. Alternatively, you can run `git pull` -from the submodule, which is equivalent except for the remote branch -name: `update --remote` uses the default upstream repository and -`submodule.<name>.branch`, while `git pull` uses the submodule's -`branch.<name>.merge`. Prefer `submodule.<name>.branch` if you want -to distribute the default upstream branch with the superproject and -`branch.<name>.merge` if you want a more native feel while working in -the submodule itself. - --N:: ---no-fetch:: - This option is only valid for the update command. - Don't fetch new objects from the remote site. - ---checkout:: - This option is only valid for the update command. - Checkout the commit recorded in the superproject on a detached HEAD - in the submodule. This is the default behavior, the main use of - this option is to override `submodule.$name.update` when set to - a value other than `checkout`. - If the key `submodule.$name.update` is either not explicitly set or - set to `checkout`, this option is implicit. - ---merge:: - This option is only valid for the update command. - Merge the commit recorded in the superproject into the current branch - of the submodule. If this option is given, the submodule's HEAD will - not be detached. If a merge failure prevents this process, you will - have to resolve the resulting conflicts within the submodule with the - usual conflict resolution tools. - If the key `submodule.$name.update` is set to `merge`, this option is - implicit. - ---rebase:: - This option is only valid for the update command. - Rebase the current branch onto the commit recorded in the - superproject. If this option is given, the submodule's HEAD will not - be detached. If a merge failure prevents this process, you will have - to resolve these failures with linkgit:git-rebase[1]. - If the key `submodule.$name.update` is set to `rebase`, this option is - implicit. - ---init:: - This option is only valid for the update command. - Initialize all submodules for which "git submodule init" has not been - called so far before updating. - ---name:: - This option is only valid for the add command. It sets the submodule's - name to the given string instead of defaulting to its path. The name - must be valid as a directory name and may not end with a '/'. - ---reference <repository>:: - This option is only valid for add and update commands. These - commands sometimes need to clone a remote repository. In this case, - this option will be passed to the linkgit:git-clone[1] command. -+ -*NOTE*: Do *not* use this option unless you have read the note -for linkgit:git-clone[1]'s `--reference`, `--shared`, and `--dissociate` -options carefully. - ---dissociate:: - This option is only valid for add and update commands. These - commands sometimes need to clone a remote repository. In this case, - this option will be passed to the linkgit:git-clone[1] command. -+ -*NOTE*: see the NOTE for the `--reference` option. - ---recursive:: - This option is only valid for foreach, update, status and sync commands. - Traverse submodules recursively. The operation is performed not - only in the submodules of the current repo, but also - in any nested submodules inside those submodules (and so on). - ---depth:: - This option is valid for add and update commands. Create a 'shallow' - 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. - Clone new submodules in parallel with as many jobs. - Defaults to the `submodule.fetchJobs` option. - -<path>...:: - Paths to submodule(s). When specified this will restrict the command - to only operate on the submodules found at the specified paths. - (This argument is required with add). - -FILES ------ -When initializing submodules, a `.gitmodules` file in the top-level directory -of the containing repository is used to find the url of each submodule. -This file should be formatted in the same way as `$GIT_DIR/config`. The key -to each submodule url is "submodule.$name.url". See linkgit:gitmodules[5] -for details. - -SEE ALSO --------- -linkgit:gitsubmodules[7], linkgit:gitmodules[5]. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-svn.txt b/third_party/git/Documentation/git-svn.txt deleted file mode 100644 index 30711625fd..0000000000 --- a/third_party/git/Documentation/git-svn.txt +++ /dev/null @@ -1,1174 +0,0 @@ -git-svn(1) -========== - -NAME ----- -git-svn - Bidirectional operation between a Subversion repository and Git - -SYNOPSIS --------- -[verse] -'git svn' <command> [<options>] [<arguments>] - -DESCRIPTION ------------ -'git svn' is a simple conduit for changesets between Subversion and Git. -It provides a bidirectional flow of changes between a Subversion and a Git -repository. - -'git svn' can track a standard Subversion repository, -following the common "trunk/branches/tags" layout, with the --stdlayout option. -It can also follow branches and tags in any layout with the -T/-t/-b options -(see options to 'init' below, and also the 'clone' command). - -Once tracking a Subversion repository (with any of the above methods), the Git -repository can be updated from Subversion by the 'fetch' command and -Subversion updated from Git by the 'dcommit' command. - -COMMANDS --------- - -'init':: - Initializes an empty Git repository with additional - metadata directories for 'git svn'. The Subversion URL - may be specified as a command-line argument, or as full - URL arguments to -T/-t/-b. Optionally, the target - directory to operate on can be specified as a second - argument. Normally this command initializes the current - directory. - --T<trunk_subdir>;; ---trunk=<trunk_subdir>;; --t<tags_subdir>;; ---tags=<tags_subdir>;; --b<branches_subdir>;; ---branches=<branches_subdir>;; --s;; ---stdlayout;; - These are optional command-line options for init. Each of - these flags can point to a relative repository path - (--tags=project/tags) or a full url - (--tags=https://foo.org/project/tags). - You can specify more than one --tags and/or --branches options, in case - your Subversion repository places tags or branches under multiple paths. - The option --stdlayout is - a shorthand way of setting trunk,tags,branches as the relative paths, - which is the Subversion default. If any of the other options are given - as well, they take precedence. ---no-metadata;; - Set the 'noMetadata' option in the [svn-remote] config. - This option is not recommended, please read the 'svn.noMetadata' - section of this manpage before using this option. ---use-svm-props;; - Set the 'useSvmProps' option in the [svn-remote] config. ---use-svnsync-props;; - Set the 'useSvnsyncProps' option in the [svn-remote] config. ---rewrite-root=<URL>;; - Set the 'rewriteRoot' option in the [svn-remote] config. ---rewrite-uuid=<UUID>;; - Set the 'rewriteUUID' option in the [svn-remote] config. ---username=<user>;; - For transports that SVN handles authentication for (http, - https, and plain svn), specify the username. For other - transports (e.g. `svn+ssh://`), you must include the username in - the URL, e.g. `svn+ssh://foo@svn.bar.com/project` ---prefix=<prefix>;; - This allows one to specify a prefix which is prepended - to the names of remotes if trunk/branches/tags are - specified. The prefix does not automatically include a - trailing slash, so be sure you include one in the - argument if that is what you want. If --branches/-b is - specified, the prefix must include a trailing slash. - Setting a prefix (with a trailing slash) is strongly - encouraged in any case, as your SVN-tracking refs will - then be located at "refs/remotes/$prefix/*", which is - compatible with Git's own remote-tracking ref layout - (refs/remotes/$remote/*). Setting a prefix is also useful - if you wish to track multiple projects that share a common - repository. - By default, the prefix is set to 'origin/'. -+ -NOTE: Before Git v2.0, the default prefix was "" (no prefix). This -meant that SVN-tracking refs were put at "refs/remotes/*", which is -incompatible with how Git's own remote-tracking refs are organized. -If you still want the old default, you can get it by passing -`--prefix ""` on the command line (`--prefix=""` may not work if -your Perl's Getopt::Long is < v2.37). - ---ignore-refs=<regex>;; - When passed to 'init' or 'clone' this regular expression will - be preserved as a config key. See 'fetch' for a description - of `--ignore-refs`. ---ignore-paths=<regex>;; - When passed to 'init' or 'clone' this regular expression will - be preserved as a config key. See 'fetch' for a description - of `--ignore-paths`. ---include-paths=<regex>;; - When passed to 'init' or 'clone' this regular expression will - be preserved as a config key. See 'fetch' for a description - of `--include-paths`. ---no-minimize-url;; - When tracking multiple directories (using --stdlayout, - --branches, or --tags options), git svn will attempt to connect - to the root (or highest allowed level) of the Subversion - repository. This default allows better tracking of history if - entire projects are moved within a repository, but may cause - issues on repositories where read access restrictions are in - place. Passing `--no-minimize-url` will allow git svn to - accept URLs as-is without attempting to connect to a higher - level directory. This option is off by default when only - one URL/branch is tracked (it would do little good). - -'fetch':: - Fetch unfetched revisions from the Subversion remote we are - tracking. The name of the [svn-remote "..."] section in the - $GIT_DIR/config file may be specified as an optional - command-line argument. -+ -This automatically updates the rev_map if needed (see -'$GIT_DIR/svn/\**/.rev_map.*' in the FILES section below for details). - ---localtime;; - Store Git commit times in the local time zone instead of UTC. This - makes 'git log' (even without --date=local) show the same times - that `svn log` would in the local time zone. -+ -This doesn't interfere with interoperating with the Subversion -repository you cloned from, but if you wish for your local Git -repository to be able to interoperate with someone else's local Git -repository, either don't use this option or you should both use it in -the same local time zone. - ---parent;; - Fetch only from the SVN parent of the current HEAD. - ---ignore-refs=<regex>;; - Ignore refs for branches or tags matching the Perl regular - expression. A "negative look-ahead assertion" like - `^refs/remotes/origin/(?!tags/wanted-tag|wanted-branch).*$` - can be used to allow only certain refs. -+ -[verse] -config key: svn-remote.<name>.ignore-refs -+ -If the ignore-refs configuration key is set, and the command-line -option is also given, both regular expressions will be used. - ---ignore-paths=<regex>;; - This allows one to specify a Perl regular expression that will - cause skipping of all matching paths from checkout from SVN. - The `--ignore-paths` option should match for every 'fetch' - (including automatic fetches due to 'clone', 'dcommit', - 'rebase', etc) on a given repository. -+ -[verse] -config key: svn-remote.<name>.ignore-paths -+ -If the ignore-paths configuration key is set, and the command-line -option is also given, both regular expressions will be used. -+ -Examples: -+ --- -Skip "doc*" directory for every fetch;; -+ ------------------------------------------------------------------------- ---ignore-paths="^doc" ------------------------------------------------------------------------- - -Skip "branches" and "tags" of first level directories;; -+ ------------------------------------------------------------------------- ---ignore-paths="^[^/]+/(?:branches|tags)" ------------------------------------------------------------------------- --- - ---include-paths=<regex>;; - This allows one to specify a Perl regular expression that will - cause the inclusion of only matching paths from checkout from SVN. - The `--include-paths` option should match for every 'fetch' - (including automatic fetches due to 'clone', 'dcommit', - 'rebase', etc) on a given repository. `--ignore-paths` takes - precedence over `--include-paths`. -+ -[verse] -config key: svn-remote.<name>.include-paths - ---log-window-size=<n>;; - Fetch <n> log entries per request when scanning Subversion history. - The default is 100. For very large Subversion repositories, larger - values may be needed for 'clone'/'fetch' to complete in reasonable - time. But overly large values may lead to higher memory usage and - request timeouts. - -'clone':: - Runs 'init' and 'fetch'. It will automatically create a - directory based on the basename of the URL passed to it; - or if a second argument is passed; it will create a directory - and work within that. It accepts all arguments that the - 'init' and 'fetch' commands accept; with the exception of - `--fetch-all` and `--parent`. After a repository is cloned, - the 'fetch' command will be able to update revisions without - affecting the working tree; and the 'rebase' command will be - able to update the working tree with the latest changes. - ---preserve-empty-dirs;; - Create a placeholder file in the local Git repository for each - empty directory fetched from Subversion. This includes directories - that become empty by removing all entries in the Subversion - repository (but not the directory itself). The placeholder files - are also tracked and removed when no longer necessary. - ---placeholder-filename=<filename>;; - Set the name of placeholder files created by --preserve-empty-dirs. - Default: ".gitignore" - -'rebase':: - This fetches revisions from the SVN parent of the current HEAD - and rebases the current (uncommitted to SVN) work against it. -+ -This works similarly to `svn update` or 'git pull' except that -it preserves linear history with 'git rebase' instead of -'git merge' for ease of dcommitting with 'git svn'. -+ -This accepts all options that 'git svn fetch' and 'git rebase' -accept. However, `--fetch-all` only fetches from the current -[svn-remote], and not all [svn-remote] definitions. -+ -Like 'git rebase'; this requires that the working tree be clean -and have no uncommitted changes. -+ -This automatically updates the rev_map if needed (see -'$GIT_DIR/svn/\**/.rev_map.*' in the FILES section below for details). - --l;; ---local;; - Do not fetch remotely; only run 'git rebase' against the - last fetched commit from the upstream SVN. - -'dcommit':: - Commit each diff from the current branch directly to the SVN - repository, and then rebase or reset (depending on whether or - not there is a diff between SVN and head). This will create - a revision in SVN for each commit in Git. -+ -When an optional Git branch name (or a Git commit object name) -is specified as an argument, the subcommand works on the specified -branch, not on the current branch. -+ -Use of 'dcommit' is preferred to 'set-tree' (below). -+ ---no-rebase;; - After committing, do not rebase or reset. ---commit-url <URL>;; - Commit to this SVN URL (the full path). This is intended to - allow existing 'git svn' repositories created with one transport - method (e.g. `svn://` or `http://` for anonymous read) to be - reused if a user is later given access to an alternate transport - method (e.g. `svn+ssh://` or `https://`) for commit. -+ -[verse] -config key: svn-remote.<name>.commiturl -config key: svn.commiturl (overwrites all svn-remote.<name>.commiturl options) -+ -Note that the SVN URL of the commiturl config key includes the SVN branch. -If you rather want to set the commit URL for an entire SVN repository use -svn-remote.<name>.pushurl instead. -+ -Using this option for any other purpose (don't ask) is very strongly -discouraged. - ---mergeinfo=<mergeinfo>;; - Add the given merge information during the dcommit - (e.g. `--mergeinfo="/branches/foo:1-10"`). All svn server versions can - store this information (as a property), and svn clients starting from - version 1.5 can make use of it. To specify merge information from multiple - branches, use a single space character between the branches - (`--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8"`) -+ -[verse] -config key: svn.pushmergeinfo -+ -This option will cause git-svn to attempt to automatically populate the -svn:mergeinfo property in the SVN repository when possible. Currently, this can -only be done when dcommitting non-fast-forward merges where all parents but the -first have already been pushed into SVN. - ---interactive;; - Ask the user to confirm that a patch set should actually be sent to SVN. - For each patch, one may answer "yes" (accept this patch), "no" (discard this - patch), "all" (accept all patches), or "quit". -+ -'git svn dcommit' returns immediately if answer is "no" or "quit", without -committing anything to SVN. - -'branch':: - Create a branch in the SVN repository. - --m;; ---message;; - Allows to specify the commit message. - --t;; ---tag;; - Create a tag by using the tags_subdir instead of the branches_subdir - specified during git svn init. - --d<path>;; ---destination=<path>;; - - If more than one --branches (or --tags) option was given to the 'init' - or 'clone' command, you must provide the location of the branch (or - tag) you wish to create in the SVN repository. <path> specifies which - path to use to create the branch or tag and should match the pattern - on the left-hand side of one of the configured branches or tags - refspecs. You can see these refspecs with the commands -+ - git config --get-all svn-remote.<name>.branches - git config --get-all svn-remote.<name>.tags -+ -where <name> is the name of the SVN repository as specified by the -R option to -'init' (or "svn" by default). - ---username;; - Specify the SVN username to perform the commit as. This option overrides - the 'username' configuration property. - ---commit-url;; - Use the specified URL to connect to the destination Subversion - repository. This is useful in cases where the source SVN - repository is read-only. This option overrides configuration - property 'commiturl'. -+ - git config --get-all svn-remote.<name>.commiturl -+ - ---parents;; - Create parent folders. This parameter is equivalent to the parameter - --parents on svn cp commands and is useful for non-standard repository - layouts. - -'tag':: - Create a tag in the SVN repository. This is a shorthand for - 'branch -t'. - -'log':: - This should make it easy to look up svn log messages when svn - users refer to -r/--revision numbers. -+ -The following features from `svn log' are supported: -+ --- --r <n>[:<n>];; ---revision=<n>[:<n>];; - is supported, non-numeric args are not: - HEAD, NEXT, BASE, PREV, etc ... --v;; ---verbose;; - it's not completely compatible with the --verbose - output in svn log, but reasonably close. ---limit=<n>;; - is NOT the same as --max-count, doesn't count - merged/excluded commits ---incremental;; - supported --- -+ -New features: -+ --- ---show-commit;; - shows the Git commit sha1, as well ---oneline;; - our version of --pretty=oneline --- -+ -NOTE: SVN itself only stores times in UTC and nothing else. The regular svn -client converts the UTC time to the local time (or based on the TZ= -environment). This command has the same behaviour. -+ -Any other arguments are passed directly to 'git log' - -'blame':: - Show what revision and author last modified each line of a file. The - output of this mode is format-compatible with the output of - `svn blame' by default. Like the SVN blame command, - local uncommitted changes in the working tree are ignored; - the version of the file in the HEAD revision is annotated. Unknown - arguments are passed directly to 'git blame'. -+ ---git-format;; - Produce output in the same format as 'git blame', but with - SVN revision numbers instead of Git commit hashes. In this mode, - changes that haven't been committed to SVN (including local - working-copy edits) are shown as revision 0. - -'find-rev':: - When given an SVN revision number of the form 'rN', returns the - corresponding Git commit hash (this can optionally be followed by a - tree-ish to specify which branch should be searched). When given a - tree-ish, returns the corresponding SVN revision number. -+ --B;; ---before;; - Don't require an exact match if given an SVN revision, instead find - the commit corresponding to the state of the SVN repository (on the - current branch) at the specified revision. -+ --A;; ---after;; - Don't require an exact match if given an SVN revision; if there is - not an exact match return the closest match searching forward in the - history. - -'set-tree':: - You should consider using 'dcommit' instead of this command. - Commit specified commit or tree objects to SVN. This relies on - your imported fetch data being up to date. This makes - absolutely no attempts to do patching when committing to SVN, it - simply overwrites files with those specified in the tree or - commit. All merging is assumed to have taken place - independently of 'git svn' functions. - -'create-ignore':: - Recursively finds the svn:ignore property on directories and - creates matching .gitignore files. The resulting files are staged to - be committed, but are not committed. Use -r/--revision to refer to a - specific revision. - -'show-ignore':: - Recursively finds and lists the svn:ignore property on - directories. The output is suitable for appending to - the $GIT_DIR/info/exclude file. - -'mkdirs':: - Attempts to recreate empty directories that core Git cannot track - based on information in $GIT_DIR/svn/<refname>/unhandled.log files. - Empty directories are automatically recreated when using - "git svn clone" and "git svn rebase", so "mkdirs" is intended - for use after commands like "git checkout" or "git reset". - (See the svn-remote.<name>.automkdirs config file option for - more information.) - -'commit-diff':: - Commits the diff of two tree-ish arguments from the - command-line. This command does not rely on being inside a `git svn - init`-ed repository. This command takes three arguments, (a) the - original tree to diff against, (b) the new tree result, (c) the - URL of the target Subversion repository. The final argument - (URL) may be omitted if you are working from a 'git svn'-aware - repository (that has been `init`-ed with 'git svn'). - The -r<revision> option is required for this. -+ -The commit message is supplied either directly with the `-m` or `-F` -option, or indirectly from the tag or commit when the second tree-ish -denotes such an object, or it is requested by invoking an editor (see -`--edit` option below). - --m <msg>;; ---message=<msg>;; - Use the given `msg` as the commit message. This option - disables the `--edit` option. - --F <filename>;; ---file=<filename>;; - Take the commit message from the given file. This option - disables the `--edit` option. - -'info':: - Shows information about a file or directory similar to what - `svn info' provides. Does not currently support a -r/--revision - argument. Use the --url option to output only the value of the - 'URL:' field. - -'proplist':: - Lists the properties stored in the Subversion repository about a - given file or directory. Use -r/--revision to refer to a specific - Subversion revision. - -'propget':: - Gets the Subversion property given as the first argument, for a - file. A specific revision can be specified with -r/--revision. - -'propset':: - Sets the Subversion property given as the first argument, to the - value given as the second argument for the file given as the - third argument. -+ -Example: -+ ------------------------------------------------------------------------- -git svn propset svn:keywords "FreeBSD=%H" devel/py-tipper/Makefile ------------------------------------------------------------------------- -+ -This will set the property 'svn:keywords' to 'FreeBSD=%H' for the file -'devel/py-tipper/Makefile'. - -'show-externals':: - Shows the Subversion externals. Use -r/--revision to specify a - specific revision. - -'gc':: - Compress $GIT_DIR/svn/<refname>/unhandled.log files and remove - $GIT_DIR/svn/<refname>/index files. - -'reset':: - Undoes the effects of 'fetch' back to the specified revision. - This allows you to re-'fetch' an SVN revision. Normally the - contents of an SVN revision should never change and 'reset' - should not be necessary. However, if SVN permissions change, - or if you alter your --ignore-paths option, a 'fetch' may fail - with "not found in commit" (file not previously visible) or - "checksum mismatch" (missed a modification). If the problem - file cannot be ignored forever (with --ignore-paths) the only - way to repair the repo is to use 'reset'. -+ -Only the rev_map and refs/remotes/git-svn are changed (see -'$GIT_DIR/svn/\**/.rev_map.*' in the FILES section below for details). -Follow 'reset' with a 'fetch' and then 'git reset' or 'git rebase' to -move local branches onto the new tree. - --r <n>;; ---revision=<n>;; - Specify the most recent revision to keep. All later revisions - are discarded. --p;; ---parent;; - Discard the specified revision as well, keeping the nearest - parent instead. -Example:;; -Assume you have local changes in "master", but you need to refetch "r2". -+ ------------- - r1---r2---r3 remotes/git-svn - \ - A---B master ------------- -+ -Fix the ignore-paths or SVN permissions problem that caused "r2" to -be incomplete in the first place. Then: -+ -[verse] -git svn reset -r2 -p -git svn fetch -+ ------------- - r1---r2'--r3' remotes/git-svn - \ - r2---r3---A---B master ------------- -+ -Then fixup "master" with 'git rebase'. -Do NOT use 'git merge' or your history will not be compatible with a -future 'dcommit'! -+ -[verse] -git rebase --onto remotes/git-svn A^ master -+ ------------- - r1---r2'--r3' remotes/git-svn - \ - A'--B' master ------------- - -OPTIONS -------- - ---shared[=(false|true|umask|group|all|world|everybody)]:: ---template=<template_directory>:: - Only used with the 'init' command. - These are passed directly to 'git init'. - --r <arg>:: ---revision <arg>:: - Used with the 'fetch' command. -+ -This allows revision ranges for partial/cauterized history -to be supported. $NUMBER, $NUMBER1:$NUMBER2 (numeric ranges), -$NUMBER:HEAD, and BASE:$NUMBER are all supported. -+ -This can allow you to make partial mirrors when running fetch; -but is generally not recommended because history will be skipped -and lost. - --:: ---stdin:: - Only used with the 'set-tree' command. -+ -Read a list of commits from stdin and commit them in reverse -order. Only the leading sha1 is read from each line, so -'git rev-list --pretty=oneline' output can be used. - ---rmdir:: - Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands. -+ -Remove directories from the SVN tree if there are no files left -behind. SVN can version empty directories, and they are not -removed by default if there are no files left in them. Git -cannot version empty directories. Enabling this flag will make -the commit to SVN act like Git. -+ -[verse] -config key: svn.rmdir - --e:: ---edit:: - Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands. -+ -Edit the commit message before committing to SVN. This is off by -default for objects that are commits, and forced on when committing -tree objects. -+ -[verse] -config key: svn.edit - --l<num>:: ---find-copies-harder:: - Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands. -+ -They are both passed directly to 'git diff-tree'; see -linkgit:git-diff-tree[1] for more information. -+ -[verse] -config key: svn.l -config key: svn.findcopiesharder - --A<filename>:: ---authors-file=<filename>:: - Syntax is compatible with the file used by 'git cvsimport' but - an empty email address can be supplied with '<>': -+ ------------------------------------------------------------------------- - loginname = Joe User <user@example.com> ------------------------------------------------------------------------- -+ -If this option is specified and 'git svn' encounters an SVN -committer name that does not exist in the authors-file, 'git svn' -will abort operation. The user will then have to add the -appropriate entry. Re-running the previous 'git svn' command -after the authors-file is modified should continue operation. -+ -[verse] -config key: svn.authorsfile - ---authors-prog=<filename>:: - If this option is specified, for each SVN committer name that - does not exist in the authors file, the given file is executed - with the committer name as the first argument. The program is - expected to return a single line of the form "Name <email>" or - "Name <>", which will be treated as if included in the authors - file. -+ -Due to historical reasons a relative 'filename' is first searched -relative to the current directory for 'init' and 'clone' and relative -to the root of the working tree for 'fetch'. If 'filename' is -not found, it is searched like any other command in '$PATH'. -+ -[verse] -config key: svn.authorsProg - --q:: ---quiet:: - Make 'git svn' less verbose. Specify a second time to make it - even less verbose. - --m:: ---merge:: --s<strategy>:: ---strategy=<strategy>:: --p:: ---preserve-merges:: - These are only used with the 'dcommit' and 'rebase' commands. -+ -Passed directly to 'git rebase' when using 'dcommit' if a -'git reset' cannot be used (see 'dcommit'). - --n:: ---dry-run:: - This can be used with the 'dcommit', 'rebase', 'branch' and - 'tag' commands. -+ -For 'dcommit', print out the series of Git arguments that would show -which diffs would be committed to SVN. -+ -For 'rebase', display the local branch associated with the upstream svn -repository associated with the current branch and the URL of svn -repository that will be fetched from. -+ -For 'branch' and 'tag', display the urls that will be used for copying when -creating the branch or tag. - ---use-log-author:: - When retrieving svn commits into Git (as part of 'fetch', 'rebase', or - 'dcommit' operations), look for the first `From:` or `Signed-off-by:` line - in the log message and use that as the author string. -+ -[verse] -config key: svn.useLogAuthor - ---add-author-from:: - When committing to svn from Git (as part of 'set-tree' or 'dcommit' - operations), if the existing log message doesn't already have a - `From:` or `Signed-off-by:` line, append a `From:` line based on the - Git commit's author string. If you use this, then `--use-log-author` - will retrieve a valid author string for all commits. -+ -[verse] -config key: svn.addAuthorFrom - -ADVANCED OPTIONS ----------------- - --i<GIT_SVN_ID>:: ---id <GIT_SVN_ID>:: - This sets GIT_SVN_ID (instead of using the environment). This - allows the user to override the default refname to fetch from - when tracking a single URL. The 'log' and 'dcommit' commands - no longer require this switch as an argument. - --R<remote name>:: ---svn-remote <remote name>:: - Specify the [svn-remote "<remote name>"] section to use, - this allows SVN multiple repositories to be tracked. - Default: "svn" - ---follow-parent:: - This option is only relevant if we are tracking branches (using - one of the repository layout options --trunk, --tags, - --branches, --stdlayout). For each tracked branch, try to find - out where its revision was copied from, and set - a suitable parent in the first Git commit for the branch. - This is especially helpful when we're tracking a directory - that has been moved around within the repository. If this - feature is disabled, the branches created by 'git svn' will all - be linear and not share any history, meaning that there will be - no information on where branches were branched off or merged. - However, following long/convoluted histories can take a long - time, so disabling this feature may speed up the cloning - process. This feature is enabled by default, use - --no-follow-parent to disable it. -+ -[verse] -config key: svn.followparent - -CONFIG FILE-ONLY OPTIONS ------------------------- - -svn.noMetadata:: -svn-remote.<name>.noMetadata:: - This gets rid of the 'git-svn-id:' lines at the end of every commit. -+ -This option can only be used for one-shot imports as 'git svn' -will not be able to fetch again without metadata. Additionally, -if you lose your '$GIT_DIR/svn/\**/.rev_map.*' files, 'git svn' will not -be able to rebuild them. -+ -The 'git svn log' command will not work on repositories using -this, either. Using this conflicts with the 'useSvmProps' -option for (hopefully) obvious reasons. -+ -This option is NOT recommended as it makes it difficult to track down -old references to SVN revision numbers in existing documentation, bug -reports and archives. If you plan to eventually migrate from SVN to Git -and are certain about dropping SVN history, consider -linkgit:git-filter-branch[1] instead. filter-branch also allows -reformatting of metadata for ease-of-reading and rewriting authorship -info for non-"svn.authorsFile" users. - -svn.useSvmProps:: -svn-remote.<name>.useSvmProps:: - This allows 'git svn' to re-map repository URLs and UUIDs from - mirrors created using SVN::Mirror (or svk) for metadata. -+ -If an SVN revision has a property, "svm:headrev", it is likely -that the revision was created by SVN::Mirror (also used by SVK). -The property contains a repository UUID and a revision. We want -to make it look like we are mirroring the original URL, so -introduce a helper function that returns the original identity -URL and UUID, and use it when generating metadata in commit -messages. - -svn.useSvnsyncProps:: -svn-remote.<name>.useSvnsyncprops:: - Similar to the useSvmProps option; this is for users - of the svnsync(1) command distributed with SVN 1.4.x and - later. - -svn-remote.<name>.rewriteRoot:: - This allows users to create repositories from alternate - URLs. For example, an administrator could run 'git svn' on the - server locally (accessing via file://) but wish to distribute - the repository with a public http:// or svn:// URL in the - metadata so users of it will see the public URL. - -svn-remote.<name>.rewriteUUID:: - Similar to the useSvmProps option; this is for users who need - to remap the UUID manually. This may be useful in situations - where the original UUID is not available via either useSvmProps - or useSvnsyncProps. - -svn-remote.<name>.pushurl:: - - Similar to Git's `remote.<name>.pushurl`, this key is designed - to be used in cases where 'url' points to an SVN repository - via a read-only transport, to provide an alternate read/write - transport. It is assumed that both keys point to the same - repository. Unlike 'commiturl', 'pushurl' is a base path. If - either 'commiturl' or 'pushurl' could be used, 'commiturl' - takes precedence. - -svn.brokenSymlinkWorkaround:: - This disables potentially expensive checks to workaround - broken symlinks checked into SVN by broken clients. Set this - option to "false" if you track a SVN repository with many - empty blobs that are not symlinks. This option may be changed - while 'git svn' is running and take effect on the next - revision fetched. If unset, 'git svn' assumes this option to - be "true". - -svn.pathnameencoding:: - This instructs git svn to recode pathnames to a given encoding. - It can be used by windows users and by those who work in non-utf8 - locales to avoid corrupted file names with non-ASCII characters. - Valid encodings are the ones supported by Perl's Encode module. - -svn-remote.<name>.automkdirs:: - Normally, the "git svn clone" and "git svn rebase" commands - attempt to recreate empty directories that are in the - Subversion repository. If this option is set to "false", then - empty directories will only be created if the "git svn mkdirs" - command is run explicitly. If unset, 'git svn' assumes this - option to be "true". - -Since the noMetadata, rewriteRoot, rewriteUUID, useSvnsyncProps and useSvmProps -options all affect the metadata generated and used by 'git svn'; they -*must* be set in the configuration file before any history is imported -and these settings should never be changed once they are set. - -Additionally, only one of these options can be used per svn-remote -section because they affect the 'git-svn-id:' metadata line, except -for rewriteRoot and rewriteUUID which can be used together. - - -BASIC EXAMPLES --------------- - -Tracking and contributing to the trunk of a Subversion-managed project -(ignoring tags and branches): - ------------------------------------------------------------------------- -# Clone a repo (like git clone): - git svn clone http://svn.example.com/project/trunk -# Enter the newly cloned directory: - cd trunk -# You should be on master branch, double-check with 'git branch' - git branch -# Do some work and commit locally to Git: - git commit ... -# Something is committed to SVN, rebase your local changes against the -# latest changes in SVN: - git svn rebase -# Now commit your changes (that were committed previously using Git) to SVN, -# as well as automatically updating your working HEAD: - git svn dcommit -# Append svn:ignore settings to the default Git exclude file: - git svn show-ignore >> .git/info/exclude ------------------------------------------------------------------------- - -Tracking and contributing to an entire Subversion-managed project -(complete with a trunk, tags and branches): - ------------------------------------------------------------------------- -# Clone a repo with standard SVN directory layout (like git clone): - git svn clone http://svn.example.com/project --stdlayout --prefix svn/ -# Or, if the repo uses a non-standard directory layout: - git svn clone http://svn.example.com/project -T tr -b branch -t tag --prefix svn/ -# View all branches and tags you have cloned: - git branch -r -# Create a new branch in SVN - git svn branch waldo -# Reset your master to trunk (or any other branch, replacing 'trunk' -# with the appropriate name): - git reset --hard svn/trunk -# You may only dcommit to one branch/tag/trunk at a time. The usage -# of dcommit/rebase/show-ignore should be the same as above. ------------------------------------------------------------------------- - -The initial 'git svn clone' can be quite time-consuming -(especially for large Subversion repositories). If multiple -people (or one person with multiple machines) want to use -'git svn' to interact with the same Subversion repository, you can -do the initial 'git svn clone' to a repository on a server and -have each person clone that repository with 'git clone': - ------------------------------------------------------------------------- -# Do the initial import on a server - ssh server "cd /pub && git svn clone http://svn.example.com/project [options...]" -# Clone locally - make sure the refs/remotes/ space matches the server - mkdir project - cd project - git init - git remote add origin server:/pub/project - git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*' - git fetch -# Prevent fetch/pull from remote Git server in the future, -# we only want to use git svn for future updates - git config --remove-section remote.origin -# Create a local branch from one of the branches just fetched - git checkout -b master FETCH_HEAD -# Initialize 'git svn' locally (be sure to use the same URL and -# --stdlayout/-T/-b/-t/--prefix options as were used on server) - git svn init http://svn.example.com/project [options...] -# Pull the latest changes from Subversion - git svn rebase ------------------------------------------------------------------------- - -REBASE VS. PULL/MERGE ---------------------- -Prefer to use 'git svn rebase' or 'git rebase', rather than -'git pull' or 'git merge' to synchronize unintegrated commits with a 'git svn' -branch. Doing so will keep the history of unintegrated commits linear with -respect to the upstream SVN repository and allow the use of the preferred -'git svn dcommit' subcommand to push unintegrated commits back into SVN. - -Originally, 'git svn' recommended that developers pulled or merged from -the 'git svn' branch. This was because the author favored -`git svn set-tree B` to commit a single head rather than the -`git svn set-tree A..B` notation to commit multiple commits. Use of -'git pull' or 'git merge' with `git svn set-tree A..B` will cause non-linear -history to be flattened when committing into SVN and this can lead to merge -commits unexpectedly reversing previous commits in SVN. - -MERGE TRACKING --------------- -While 'git svn' can track -copy history (including branches and tags) for repositories adopting a -standard layout, it cannot yet represent merge history that happened -inside git back upstream to SVN users. Therefore it is advised that -users keep history as linear as possible inside Git to ease -compatibility with SVN (see the CAVEATS section below). - -HANDLING OF SVN BRANCHES ------------------------- -If 'git svn' is configured to fetch branches (and --follow-branches -is in effect), it sometimes creates multiple Git branches for one -SVN branch, where the additional branches have names of the form -'branchname@nnn' (with nnn an SVN revision number). These additional -branches are created if 'git svn' cannot find a parent commit for the -first commit in an SVN branch, to connect the branch to the history of -the other branches. - -Normally, the first commit in an SVN branch consists -of a copy operation. 'git svn' will read this commit to get the SVN -revision the branch was created from. It will then try to find the -Git commit that corresponds to this SVN revision, and use that as the -parent of the branch. However, it is possible that there is no suitable -Git commit to serve as parent. This will happen, among other reasons, -if the SVN branch is a copy of a revision that was not fetched by 'git -svn' (e.g. because it is an old revision that was skipped with -`--revision`), or if in SVN a directory was copied that is not tracked -by 'git svn' (such as a branch that is not tracked at all, or a -subdirectory of a tracked branch). In these cases, 'git svn' will still -create a Git branch, but instead of using an existing Git commit as the -parent of the branch, it will read the SVN history of the directory the -branch was copied from and create appropriate Git commits. This is -indicated by the message "Initializing parent: <branchname>". - -Additionally, it will create a special branch named -'<branchname>@<SVN-Revision>', where <SVN-Revision> is the SVN revision -number the branch was copied from. This branch will point to the newly -created parent commit of the branch. If in SVN the branch was deleted -and later recreated from a different version, there will be multiple -such branches with an '@'. - -Note that this may mean that multiple Git commits are created for a -single SVN revision. - -An example: in an SVN repository with a standard -trunk/tags/branches layout, a directory trunk/sub is created in r.100. -In r.200, trunk/sub is branched by copying it to branches/. 'git svn -clone -s' will then create a branch 'sub'. It will also create new Git -commits for r.100 through r.199 and use these as the history of branch -'sub'. Thus there will be two Git commits for each revision from r.100 -to r.199 (one containing trunk/, one containing trunk/sub/). Finally, -it will create a branch 'sub@200' pointing to the new parent commit of -branch 'sub' (i.e. the commit for r.200 and trunk/sub/). - -CAVEATS -------- - -For the sake of simplicity and interoperating with Subversion, -it is recommended that all 'git svn' users clone, fetch and dcommit -directly from the SVN server, and avoid all 'git clone'/'pull'/'merge'/'push' -operations between Git repositories and branches. The recommended -method of exchanging code between Git branches and users is -'git format-patch' and 'git am', or just 'dcommit'ing to the SVN repository. - -Running 'git merge' or 'git pull' is NOT recommended on a branch you -plan to 'dcommit' from because Subversion users cannot see any -merges you've made. Furthermore, if you merge or pull from a Git branch -that is a mirror of an SVN branch, 'dcommit' may commit to the wrong -branch. - -If you do merge, note the following rule: 'git svn dcommit' will -attempt to commit on top of the SVN commit named in ------------------------------------------------------------------------- -git log --grep=^git-svn-id: --first-parent -1 ------------------------------------------------------------------------- -You 'must' therefore ensure that the most recent commit of the branch -you want to dcommit to is the 'first' parent of the merge. Chaos will -ensue otherwise, especially if the first parent is an older commit on -the same SVN branch. - -'git clone' does not clone branches under the refs/remotes/ hierarchy or -any 'git svn' metadata, or config. So repositories created and managed with -using 'git svn' should use 'rsync' for cloning, if cloning is to be done -at all. - -Since 'dcommit' uses rebase internally, any Git branches you 'git push' to -before 'dcommit' on will require forcing an overwrite of the existing ref -on the remote repository. This is generally considered bad practice, -see the linkgit:git-push[1] documentation for details. - -Do not use the --amend option of linkgit:git-commit[1] on a change you've -already dcommitted. It is considered bad practice to --amend commits -you've already pushed to a remote repository for other users, and -dcommit with SVN is analogous to that. - -When cloning an SVN repository, if none of the options for describing -the repository layout is used (--trunk, --tags, --branches, ---stdlayout), 'git svn clone' will create a Git repository with -completely linear history, where branches and tags appear as separate -directories in the working copy. While this is the easiest way to get a -copy of a complete repository, for projects with many branches it will -lead to a working copy many times larger than just the trunk. Thus for -projects using the standard directory structure (trunk/branches/tags), -it is recommended to clone with option `--stdlayout`. If the project -uses a non-standard structure, and/or if branches and tags are not -required, it is easiest to only clone one directory (typically trunk), -without giving any repository layout options. If the full history with -branches and tags is required, the options `--trunk` / `--branches` / -`--tags` must be used. - -When using multiple --branches or --tags, 'git svn' does not automatically -handle name collisions (for example, if two branches from different paths have -the same name, or if a branch and a tag have the same name). In these cases, -use 'init' to set up your Git repository then, before your first 'fetch', edit -the $GIT_DIR/config file so that the branches and tags are associated -with different name spaces. For example: - - branches = stable/*:refs/remotes/svn/stable/* - branches = debug/*:refs/remotes/svn/debug/* - -BUGS ----- - -We ignore all SVN properties except svn:executable. Any unhandled -properties are logged to $GIT_DIR/svn/<refname>/unhandled.log - -Renamed and copied directories are not detected by Git and hence not -tracked when committing to SVN. I do not plan on adding support for -this as it's quite difficult and time-consuming to get working for all -the possible corner cases (Git doesn't do it, either). Committing -renamed and copied files is fully supported if they're similar enough -for Git to detect them. - -In SVN, it is possible (though discouraged) to commit changes to a tag -(because a tag is just a directory copy, thus technically the same as a -branch). When cloning an SVN repository, 'git svn' cannot know if such a -commit to a tag will happen in the future. Thus it acts conservatively -and imports all SVN tags as branches, prefixing the tag name with 'tags/'. - -CONFIGURATION -------------- - -'git svn' stores [svn-remote] configuration information in the -repository $GIT_DIR/config file. It is similar the core Git -[remote] sections except 'fetch' keys do not accept glob -arguments; but they are instead handled by the 'branches' -and 'tags' keys. Since some SVN repositories are oddly -configured with multiple projects glob expansions such those -listed below are allowed: - ------------------------------------------------------------------------- -[svn-remote "project-a"] - url = http://server.org/svn - fetch = trunk/project-a:refs/remotes/project-a/trunk - branches = branches/*/project-a:refs/remotes/project-a/branches/* - branches = branches/release_*:refs/remotes/project-a/branches/release_* - branches = branches/re*se:refs/remotes/project-a/branches/* - tags = tags/*/project-a:refs/remotes/project-a/tags/* ------------------------------------------------------------------------- - -Keep in mind that the `*` (asterisk) wildcard of the local ref -(right of the `:`) *must* be the farthest right path component; -however the remote wildcard may be anywhere as long as it's an -independent path component (surrounded by `/` or EOL). This -type of configuration is not automatically created by 'init' and -should be manually entered with a text-editor or using 'git config'. - -Also note that only one asterisk is allowed per word. For example: - - branches = branches/re*se:refs/remotes/project-a/branches/* - -will match branches 'release', 'rese', 're123se', however - - branches = branches/re*s*e:refs/remotes/project-a/branches/* - -will produce an error. - -It is also possible to fetch a subset of branches or tags by using a -comma-separated list of names within braces. For example: - ------------------------------------------------------------------------- -[svn-remote "huge-project"] - url = http://server.org/svn - fetch = trunk/src:refs/remotes/trunk - branches = branches/{red,green}/src:refs/remotes/project-a/branches/* - tags = tags/{1.0,2.0}/src:refs/remotes/project-a/tags/* ------------------------------------------------------------------------- - -Multiple fetch, branches, and tags keys are supported: - ------------------------------------------------------------------------- -[svn-remote "messy-repo"] - url = http://server.org/svn - fetch = trunk/project-a:refs/remotes/project-a/trunk - fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo - branches = branches/server/*:refs/remotes/project-a/branches/* - branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/* - tags = tags/server/*:refs/remotes/project-a/tags/* ------------------------------------------------------------------------- - -Creating a branch in such a configuration requires disambiguating which -location to use using the -d or --destination flag: - ------------------------------------------------------------------------- -$ git svn branch -d branches/server release-2-3-0 ------------------------------------------------------------------------- - -Note that git-svn keeps track of the highest revision in which a branch -or tag has appeared. If the subset of branches or tags is changed after -fetching, then $GIT_DIR/svn/.metadata must be manually edited to remove -(or reset) branches-maxRev and/or tags-maxRev as appropriate. - -FILES ------ -$GIT_DIR/svn/\**/.rev_map.*:: - Mapping between Subversion revision numbers and Git commit - names. In a repository where the noMetadata option is not set, - this can be rebuilt from the git-svn-id: lines that are at the - end of every commit (see the 'svn.noMetadata' section above for - details). -+ -'git svn fetch' and 'git svn rebase' automatically update the rev_map -if it is missing or not up to date. 'git svn reset' automatically -rewinds it. - -SEE ALSO --------- -linkgit:git-rebase[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-switch.txt b/third_party/git/Documentation/git-switch.txt deleted file mode 100644 index 197900363b..0000000000 --- a/third_party/git/Documentation/git-switch.txt +++ /dev/null @@ -1,273 +0,0 @@ -git-switch(1) -============= - -NAME ----- -git-switch - Switch branches - -SYNOPSIS --------- -[verse] -'git switch' [<options>] [--no-guess] <branch> -'git switch' [<options>] --detach [<start-point>] -'git switch' [<options>] (-c|-C) <new-branch> [<start-point>] -'git switch' [<options>] --orphan <new-branch> - -DESCRIPTION ------------ -Switch to a specified branch. The working tree and the index are -updated to match the branch. All new commits will be added to the tip -of this branch. - -Optionally a new branch could be created with either `-c`, `-C`, -automatically from a remote branch of same name (see `--guess`), or -detach the working tree from any branch with `--detach`, along with -switching. - -Switching branches does not require a clean index and working tree -(i.e. no differences compared to `HEAD`). The operation is aborted -however if the operation leads to loss of local changes, unless told -otherwise with `--discard-changes` or `--merge`. - -THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. - -OPTIONS -------- -<branch>:: - Branch to switch to. - -<new-branch>:: - Name for the new branch. - -<start-point>:: - The starting point for the new branch. Specifying a - `<start-point>` allows you to create a branch based on some - other point in history than where HEAD currently points. (Or, - in the case of `--detach`, allows you to inspect and detach - from some other point.) -+ -You can use the `@{-N}` syntax to refer to the N-th last -branch/commit switched to using "git switch" or "git checkout" -operation. You may also specify `-` which is synonymous to `@{-1}`. -This is often used to switch quickly between two branches, or to undo -a branch switch by mistake. -+ -As a special case, you may use `A...B` as a shortcut for the merge -base of `A` and `B` if there is exactly one merge base. You can leave -out at most one of `A` and `B`, in which case it defaults to `HEAD`. - --c <new-branch>:: ---create <new-branch>:: - Create a new branch named `<new-branch>` starting at - `<start-point>` before switching to the branch. This is a - convenient shortcut for: -+ ------------- -$ git branch <new-branch> -$ git switch <new-branch> ------------- - --C <new-branch>:: ---force-create <new-branch>:: - Similar to `--create` except that if `<new-branch>` already - exists, it will be reset to `<start-point>`. This is a - convenient shortcut for: -+ ------------- -$ git branch -f <new-branch> -$ git switch <new-branch> ------------- - --d:: ---detach:: - Switch to a commit for inspection and discardable - experiments. See the "DETACHED HEAD" section in - linkgit:git-checkout[1] for details. - ---guess:: ---no-guess:: - If `<branch>` is not found but there does exist a tracking - branch in exactly one remote (call it `<remote>`) with a - matching name, treat as equivalent to -+ ------------- -$ git switch -c <branch> --track <remote>/<branch> ------------- -+ -If the branch exists in multiple remotes and one of them is named by -the `checkout.defaultRemote` configuration variable, we'll use that -one for the purposes of disambiguation, even if the `<branch>` isn't -unique across all remotes. Set it to e.g. `checkout.defaultRemote=origin` -to always checkout remote branches from there if `<branch>` is -ambiguous but exists on the 'origin' remote. See also -`checkout.defaultRemote` in linkgit:git-config[1]. -+ -`--guess` is the default behavior. Use `--no-guess` to disable it. - --f:: ---force:: - An alias for `--discard-changes`. - ---discard-changes:: - Proceed even if the index or the working tree differs from - `HEAD`. Both the index and working tree are restored to match - the switching target. If `--recurse-submodules` is specified, - submodule content is also restored to match the switching - target. This is used to throw away local changes. - --m:: ---merge:: - If you have local modifications to one or more files that are - different between the current branch and the branch to which - you are switching, the command refuses to switch branches in - order to preserve your modifications in context. However, - with this option, a three-way merge between the current - branch, your working tree contents, and the new branch is - done, and you will be on the new branch. -+ -When a merge conflict happens, the index entries for conflicting -paths are left unmerged, and you need to resolve the conflicts -and mark the resolved paths with `git add` (or `git rm` if the merge -should result in deletion of the path). - ---conflict=<style>:: - The same as `--merge` option above, but changes the way the - conflicting hunks are presented, overriding the - `merge.conflictStyle` configuration variable. Possible values are - "merge" (default) and "diff3" (in addition to what is shown by - "merge" style, shows the original contents). - --q:: ---quiet:: - Quiet, suppress feedback messages. - ---progress:: ---no-progress:: - Progress status is reported on the standard error stream - by default when it is attached to a terminal, unless `--quiet` - is specified. This flag enables progress reporting even if not - attached to a terminal, regardless of `--quiet`. - --t:: ---track:: - When creating a new branch, set up "upstream" configuration. - `-c` is implied. See `--track` in linkgit:git-branch[1] for - details. -+ -If no `-c` option is given, the name of the new branch will be derived -from the remote-tracking branch, by looking at the local part of the -refspec configured for the corresponding remote, and then stripping -the initial part up to the "*". This would tell us to use `hack` as -the local branch when branching off of `origin/hack` (or -`remotes/origin/hack`, or even `refs/remotes/origin/hack`). If the -given name has no slash, or the above guessing results in an empty -name, the guessing is aborted. You can explicitly give a name with -`-c` in such a case. - ---no-track:: - Do not set up "upstream" configuration, even if the - `branch.autoSetupMerge` configuration variable is true. - ---orphan <new-branch>:: - Create a new 'orphan' branch, named `<new-branch>`. All - tracked files are removed. - ---ignore-other-worktrees:: - `git switch` refuses when the wanted ref is already - checked out by another worktree. This option makes it check - the ref out anyway. In other words, the ref can be held by - more than one worktree. - ---recurse-submodules:: ---no-recurse-submodules:: - Using `--recurse-submodules` will update the content of all - initialized submodules according to the commit recorded in the - superproject. If nothing (or `--no-recurse-submodules`) is - used, the work trees of submodules will not be updated. Just - like linkgit:git-submodule[1], this will detach `HEAD` of the - submodules. - -EXAMPLES --------- - -The following command switches to the "master" branch: - ------------- -$ git switch master ------------- - -After working in the wrong branch, switching to the correct branch -would be done using: - ------------- -$ git switch mytopic ------------- - -However, your "wrong" branch and correct "mytopic" branch may differ -in files that you have modified locally, in which case the above -switch would fail like this: - ------------- -$ git switch mytopic -error: You have local changes to 'frotz'; not switching branches. ------------- - -You can give the `-m` flag to the command, which would try a three-way -merge: - ------------- -$ git switch -m mytopic -Auto-merging frotz ------------- - -After this three-way merge, the local modifications are _not_ -registered in your index file, so `git diff` would show you what -changes you made since the tip of the new branch. - -To switch back to the previous branch before we switched to mytopic -(i.e. "master" branch): - ------------- -$ git switch - ------------- - -You can grow a new branch from any commit. For example, switch to -"HEAD~3" and create branch "fixup": - ------------- -$ git switch -c fixup HEAD~3 -Switched to a new branch 'fixup' ------------- - -If you want to start a new branch from a remote branch of the same -name: - ------------- -$ git switch new-topic -Branch 'new-topic' set up to track remote branch 'new-topic' from 'origin' -Switched to a new branch 'new-topic' ------------- - -To check out commit `HEAD~3` for temporary inspection or experiment -without creating a new branch: - ------------- -$ git switch --detach HEAD~3 -HEAD is now at 9fc9555312 Merge branch 'cc/shared-index-permbits' ------------- - -If it turns out whatever you have done is worth keeping, you can -always create a new name for it (without switching away): - ------------- -$ git switch -c good-surprises ------------- - -SEE ALSO --------- -linkgit:git-checkout[1], -linkgit:git-branch[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-symbolic-ref.txt b/third_party/git/Documentation/git-symbolic-ref.txt deleted file mode 100644 index ef68ad2b71..0000000000 --- a/third_party/git/Documentation/git-symbolic-ref.txt +++ /dev/null @@ -1,69 +0,0 @@ -git-symbolic-ref(1) -=================== - -NAME ----- -git-symbolic-ref - Read, modify and delete symbolic refs - -SYNOPSIS --------- -[verse] -'git symbolic-ref' [-m <reason>] <name> <ref> -'git symbolic-ref' [-q] [--short] <name> -'git symbolic-ref' --delete [-q] <name> - -DESCRIPTION ------------ -Given one argument, reads which branch head the given symbolic -ref refers to and outputs its path, relative to the `.git/` -directory. Typically you would give `HEAD` as the <name> -argument to see which branch your working tree is on. - -Given two arguments, creates or updates a symbolic ref <name> to -point at the given branch <ref>. - -Given `--delete` and an additional argument, deletes the given -symbolic ref. - -A symbolic ref is a regular file that stores a string that -begins with `ref: refs/`. For example, your `.git/HEAD` is -a regular file whose contents is `ref: refs/heads/master`. - -OPTIONS -------- - --d:: ---delete:: - Delete the symbolic ref <name>. - --q:: ---quiet:: - Do not issue an error message if the <name> is not a - symbolic ref but a detached HEAD; instead exit with - non-zero status silently. - ---short:: - When showing the value of <name> as a symbolic ref, try to shorten the - value, e.g. from `refs/heads/master` to `master`. - --m:: - Update the reflog for <name> with <reason>. This is valid only - when creating or updating a symbolic ref. - -NOTES ------ -In the past, `.git/HEAD` was a symbolic link pointing at -`refs/heads/master`. When we wanted to switch to another branch, -we did `ln -sf refs/heads/newbranch .git/HEAD`, and when we wanted -to find out which branch we are on, we did `readlink .git/HEAD`. -But symbolic links are not entirely portable, so they are now -deprecated and symbolic refs (as described above) are used by -default. - -'git symbolic-ref' will exit with status 0 if the contents of the -symbolic ref were printed correctly, with status 1 if the requested -name is not a symbolic ref, or 128 if another error occurs. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-tag.txt b/third_party/git/Documentation/git-tag.txt deleted file mode 100644 index 2e5599a67f..0000000000 --- a/third_party/git/Documentation/git-tag.txt +++ /dev/null @@ -1,387 +0,0 @@ -git-tag(1) -========== - -NAME ----- -git-tag - Create, list, delete or verify a tag object signed with GPG - - -SYNOPSIS --------- -[verse] -'git tag' [-a | -s | -u <keyid>] [-f] [-m <msg> | -F <file>] [-e] - <tagname> [<commit> | <object>] -'git tag' -d <tagname>... -'git tag' [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>] - [--points-at <object>] [--column[=<options>] | --no-column] - [--create-reflog] [--sort=<key>] [--format=<format>] - [--[no-]merged [<commit>]] [<pattern>...] -'git tag' -v [--format=<format>] <tagname>... - -DESCRIPTION ------------ - -Add a tag reference in `refs/tags/`, unless `-d/-l/-v` is given -to delete, list or verify tags. - -Unless `-f` is given, the named tag must not yet exist. - -If one of `-a`, `-s`, or `-u <keyid>` is passed, the command -creates a 'tag' object, and requires a tag message. Unless -`-m <msg>` or `-F <file>` is given, an editor is started for the user to type -in the tag message. - -If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <keyid>` -are absent, `-a` is implied. - -Otherwise, a tag reference that points directly at the given object -(i.e., a lightweight tag) is created. - -A GnuPG signed tag object will be created when `-s` or `-u -<keyid>` is used. When `-u <keyid>` is not used, the -committer identity for the current user is used to find the -GnuPG key for signing. The configuration variable `gpg.program` -is used to specify custom GnuPG binary. - -Tag objects (created with `-a`, `-s`, or `-u`) are called "annotated" -tags; they contain a creation date, the tagger name and e-mail, a -tagging message, and an optional GnuPG signature. Whereas a -"lightweight" tag is simply a name for an object (usually a commit -object). - -Annotated tags are meant for release while lightweight tags are meant -for private or temporary object labels. For this reason, some git -commands for naming objects (like `git describe`) will ignore -lightweight tags by default. - - -OPTIONS -------- --a:: ---annotate:: - Make an unsigned, annotated tag object - --s:: ---sign:: - Make a GPG-signed tag, using the default e-mail address's key. - The default behavior of tag GPG-signing is controlled by `tag.gpgSign` - configuration variable if it exists, or disabled oder otherwise. - See linkgit:git-config[1]. - ---no-sign:: - Override `tag.gpgSign` configuration variable that is - set to force each and every tag to be signed. - --u <keyid>:: ---local-user=<keyid>:: - Make a GPG-signed tag, using the given key. - --f:: ---force:: - Replace an existing tag with the given name (instead of failing) - --d:: ---delete:: - Delete existing tags with the given names. - --v:: ---verify:: - Verify the GPG signature of the given tag names. - --n<num>:: - <num> specifies how many lines from the annotation, if any, - are printed when using -l. Implies `--list`. -+ -The default is not to print any annotation lines. -If no number is given to `-n`, only the first line is printed. -If the tag is not annotated, the commit message is displayed instead. - --l:: ---list:: - List tags. With optional `<pattern>...`, e.g. `git tag --list - 'v-*'`, list only the tags that match the pattern(s). -+ -Running "git tag" without arguments also lists all tags. The pattern -is a shell wildcard (i.e., matched using fnmatch(3)). Multiple -patterns may be given; if any of them matches, the tag is shown. -+ -This option is implicitly supplied if any other list-like option such -as `--contains` is provided. See the documentation for each of those -options for details. - ---sort=<key>:: - Sort based on the key given. Prefix `-` to sort in - descending order of the value. You may use the --sort=<key> option - multiple times, in which case the last key becomes the primary - key. Also supports "version:refname" or "v:refname" (tag - names are treated as versions). The "version:refname" sort - order can also be affected by the "versionsort.suffix" - configuration variable. - The keys supported are the same as those in `git for-each-ref`. - Sort order defaults to the value configured for the `tag.sort` - variable if it exists, or lexicographic order otherwise. See - linkgit:git-config[1]. - ---color[=<when>]:: - Respect any colors specified in the `--format` option. The - `<when>` field must be one of `always`, `never`, or `auto` (if - `<when>` is absent, behave as if `always` was given). - --i:: ---ignore-case:: - Sorting and filtering tags are case insensitive. - ---column[=<options>]:: ---no-column:: - Display tag listing in columns. See configuration variable - column.tag for option syntax.`--column` and `--no-column` - without options are equivalent to 'always' and 'never' respectively. -+ -This option is only applicable when listing tags without annotation lines. - ---contains [<commit>]:: - Only list tags which contain the specified commit (HEAD if not - specified). Implies `--list`. - ---no-contains [<commit>]:: - Only list tags which don't contain the specified commit (HEAD if - not specified). Implies `--list`. - ---merged [<commit>]:: - Only list tags whose commits are reachable from the specified - commit (`HEAD` if not specified), incompatible with `--no-merged`. - ---no-merged [<commit>]:: - Only list tags whose commits are not reachable from the specified - commit (`HEAD` if not specified), incompatible with `--merged`. - ---points-at <object>:: - Only list tags of the given object (HEAD if not - specified). Implies `--list`. - --m <msg>:: ---message=<msg>:: - Use the given tag message (instead of prompting). - If multiple `-m` options are given, their values are - concatenated as separate paragraphs. - Implies `-a` if none of `-a`, `-s`, or `-u <keyid>` - is given. - --F <file>:: ---file=<file>:: - Take the tag message from the given file. Use '-' to - read the message from the standard input. - Implies `-a` if none of `-a`, `-s`, or `-u <keyid>` - is given. - --e:: ---edit:: - The message taken from file with `-F` and command line with - `-m` are usually used as the tag message unmodified. - This option lets you further edit the message taken from these sources. - ---cleanup=<mode>:: - This option sets how the tag message is cleaned up. - The '<mode>' can be one of 'verbatim', 'whitespace' and 'strip'. The - 'strip' mode is default. The 'verbatim' mode does not change message at - all, 'whitespace' removes just leading/trailing whitespace lines and - 'strip' removes both whitespace and commentary. - ---create-reflog:: - Create a reflog for the tag. To globally enable reflogs for tags, see - `core.logAllRefUpdates` in linkgit:git-config[1]. - The negated form `--no-create-reflog` only overrides an earlier - `--create-reflog`, but currently does not negate the setting of - `core.logAllRefUpdates`. - ---format=<format>:: - A string that interpolates `%(fieldname)` from a tag ref being shown - and the object it points at. The format is the same as - that of linkgit:git-for-each-ref[1]. When unspecified, - defaults to `%(refname:strip=2)`. - -<tagname>:: - The name of the tag to create, delete, or describe. - The new tag name must pass all checks defined by - linkgit:git-check-ref-format[1]. Some of these checks - may restrict the characters allowed in a tag name. - -<commit>:: -<object>:: - The object that the new tag will refer to, usually a commit. - Defaults to HEAD. - -CONFIGURATION -------------- -By default, 'git tag' in sign-with-default mode (-s) will use your -committer identity (of the form `Your Name <your@email.address>`) to -find a key. If you want to use a different default key, you can specify -it in the repository configuration as follows: - -------------------------------------- -[user] - signingKey = <gpg-keyid> -------------------------------------- - -`pager.tag` is only respected when listing tags, i.e., when `-l` is -used or implied. The default is to use a pager. -See linkgit:git-config[1]. - -DISCUSSION ----------- - -On Re-tagging -~~~~~~~~~~~~~ - -What should you do when you tag a wrong commit and you would -want to re-tag? - -If you never pushed anything out, just re-tag it. Use "-f" to -replace the old one. And you're done. - -But if you have pushed things out (or others could just read -your repository directly), then others will have already seen -the old tag. In that case you can do one of two things: - -. The sane thing. - Just admit you screwed up, and use a different name. Others have - already seen one tag-name, and if you keep the same name, you - may be in the situation that two people both have "version X", - but they actually have 'different' "X"'s. So just call it "X.1" - and be done with it. - -. The insane thing. - You really want to call the new version "X" too, 'even though' - others have already seen the old one. So just use 'git tag -f' - again, as if you hadn't already published the old one. - -However, Git does *not* (and it should not) change tags behind -users back. So if somebody already got the old tag, doing a -'git pull' on your tree shouldn't just make them overwrite the old -one. - -If somebody got a release tag from you, you cannot just change -the tag for them by updating your own one. This is a big -security issue, in that people MUST be able to trust their -tag-names. If you really want to do the insane thing, you need -to just fess up to it, and tell people that you messed up. You -can do that by making a very public announcement saying: - ------------- -Ok, I messed up, and I pushed out an earlier version tagged as X. I -then fixed something, and retagged the *fixed* tree as X again. - -If you got the wrong tag, and want the new one, please delete -the old one and fetch the new one by doing: - - git tag -d X - git fetch origin tag X - -to get my updated tag. - -You can test which tag you have by doing - - git rev-parse X - -which should return 0123456789abcdef.. if you have the new version. - -Sorry for the inconvenience. ------------- - -Does this seem a bit complicated? It *should* be. There is no -way that it would be correct to just "fix" it automatically. -People need to know that their tags might have been changed. - - -On Automatic following -~~~~~~~~~~~~~~~~~~~~~~ - -If you are following somebody else's tree, you are most likely -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 -get tags from there. This happens more often for people near -the toplevel but not limited to them. Mere mortals when pulling -from each other do not necessarily want to automatically get -private anchor point tags from the other person. - -Often, "please pull" messages on the mailing list just provide -two pieces of information: a repo URL and a branch name; this -is designed to be easily cut&pasted at the end of a 'git fetch' -command line: - ------------- -Linus, please pull from - - git://git..../proj.git master - -to get the following updates... ------------- - -becomes: - ------------- -$ git pull git://git..../proj.git master ------------- - -In such a case, you do not want to automatically follow the other -person's tags. - -One important aspect of Git is its distributed nature, which -largely means there is no inherent "upstream" or -"downstream" in the system. On the face of it, the above -example might seem to indicate that the tag namespace is owned -by the upper echelon of people and that tags only flow downwards, but -that is not the case. It only shows that the usage pattern -determines who are interested in whose tags. - -A one-shot pull is a sign that a commit history is now crossing -the boundary between one circle of people (e.g. "people who are -primarily interested in the networking part of the kernel") who may -have their own set of tags (e.g. "this is the third release -candidate from the networking group to be proposed for general -consumption with 2.6.21 release") to another circle of people -(e.g. "people who integrate various subsystem improvements"). -The latter are usually not interested in the detailed tags used -internally in the former group (that is what "internal" means). -That is why it is desirable not to follow tags automatically in -this case. - -It may well be that among networking people, they may want to -exchange the tags internal to their group, but in that workflow -they are most likely tracking each other's progress by -having remote-tracking branches. Again, the heuristic to automatically -follow such tags is a good thing. - - -On Backdating Tags -~~~~~~~~~~~~~~~~~~ - -If you have imported some changes from another VCS and would like -to add tags for major releases of your work, it is useful to be able -to specify the date to embed inside of the tag object; such data in -the tag object affects, for example, the ordering of tags in the -gitweb interface. - -To set the date used in future tag objects, set the environment -variable GIT_COMMITTER_DATE (see the later discussion of possible -values; the most common form is "YYYY-MM-DD HH:MM"). - -For example: - ------------- -$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1 ------------- - -include::date-formats.txt[] - -SEE ALSO --------- -linkgit:git-check-ref-format[1]. -linkgit:git-config[1]. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-tools.txt b/third_party/git/Documentation/git-tools.txt deleted file mode 100644 index d0fec4cddd..0000000000 --- a/third_party/git/Documentation/git-tools.txt +++ /dev/null @@ -1,10 +0,0 @@ -Git Tools -========= - -When Git was young, people looking for third-party Git-related tools came -to the Git project itself to find them, thus a list of such tools was -maintained here. These days, however, search engines fill that role much -more efficiently, so this manually-maintained list has been retired. - -See also the `contrib/` area, and the Git wiki: -https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools diff --git a/third_party/git/Documentation/git-unpack-file.txt b/third_party/git/Documentation/git-unpack-file.txt deleted file mode 100644 index e9f148a00d..0000000000 --- a/third_party/git/Documentation/git-unpack-file.txt +++ /dev/null @@ -1,28 +0,0 @@ -git-unpack-file(1) -================== - -NAME ----- -git-unpack-file - Creates a temporary file with a blob's contents - - - -SYNOPSIS --------- -[verse] -'git unpack-file' <blob> - -DESCRIPTION ------------ -Creates a file holding the contents of the blob specified by sha1. It -returns the name of the temporary file in the following format: - .merge_file_XXXXX - -OPTIONS -------- -<blob>:: - Must be a blob id - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-unpack-objects.txt b/third_party/git/Documentation/git-unpack-objects.txt deleted file mode 100644 index b3de50d710..0000000000 --- a/third_party/git/Documentation/git-unpack-objects.txt +++ /dev/null @@ -1,52 +0,0 @@ -git-unpack-objects(1) -===================== - -NAME ----- -git-unpack-objects - Unpack objects from a packed archive - - -SYNOPSIS --------- -[verse] -'git unpack-objects' [-n] [-q] [-r] [--strict] - - -DESCRIPTION ------------ -Read a packed archive (.pack) from the standard input, expanding -the objects contained within and writing them into the repository in -"loose" (one object per file) format. - -Objects that already exist in the repository will *not* be unpacked -from the packfile. Therefore, nothing will be unpacked if you use -this command on a packfile that exists within the target repository. - -See linkgit:git-repack[1] for options to generate -new packs and replace existing ones. - -OPTIONS -------- --n:: - Dry run. Check the pack file without actually unpacking - the objects. - --q:: - The command usually shows percentage progress. This - flag suppresses it. - --r:: - When unpacking a corrupt packfile, the command dies at - the first corruption. This flag tells it to keep going - and make the best effort to recover as many objects as - possible. - ---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/third_party/git/Documentation/git-update-index.txt b/third_party/git/Documentation/git-update-index.txt deleted file mode 100644 index 1c4d146a41..0000000000 --- a/third_party/git/Documentation/git-update-index.txt +++ /dev/null @@ -1,554 +0,0 @@ -git-update-index(1) -=================== - -NAME ----- -git-update-index - Register file contents in the working tree to the index - - -SYNOPSIS --------- -[verse] -'git update-index' - [--add] [--remove | --force-remove] [--replace] - [--refresh] [-q] [--unmerged] [--ignore-missing] - [(--cacheinfo <mode>,<object>,<file>)...] - [--chmod=(+|-)x] - [--[no-]assume-unchanged] - [--[no-]skip-worktree] - [--[no-]fsmonitor-valid] - [--ignore-submodules] - [--[no-]split-index] - [--[no-|test-|force-]untracked-cache] - [--[no-]fsmonitor] - [--really-refresh] [--unresolve] [--again | -g] - [--info-only] [--index-info] - [-z] [--stdin] [--index-version <n>] - [--verbose] - [--] [<file>...] - -DESCRIPTION ------------ -Modifies the index or directory cache. Each file mentioned is updated -into the index and any 'unmerged' or 'needs updating' state is -cleared. - -See also linkgit:git-add[1] for a more user-friendly way to do some of -the most common operations on the index. - -The way 'git update-index' handles files it is told about can be modified -using the various options: - -OPTIONS -------- ---add:: - If a specified file isn't in the index already then it's - added. - Default behaviour is to ignore new files. - ---remove:: - If a specified file is in the index but is missing then it's - removed. - Default behavior is to ignore removed file. - ---refresh:: - Looks at the current index and checks to see if merges or - updates are needed by checking stat() information. - --q:: - Quiet. If --refresh finds that the index needs an update, the - default behavior is to error out. This option makes - 'git update-index' continue anyway. - ---ignore-submodules:: - Do not try to update submodules. This option is only respected - when passed before --refresh. - ---unmerged:: - If --refresh finds unmerged changes in the index, the default - behavior is to error out. This option makes 'git update-index' - continue anyway. - ---ignore-missing:: - Ignores missing files during a --refresh - ---cacheinfo <mode>,<object>,<path>:: ---cacheinfo <mode> <object> <path>:: - Directly insert the specified info into the index. For - backward compatibility, you can also give these three - arguments as three separate parameters, but new users are - encouraged to use a single-parameter form. - ---index-info:: - Read index information from stdin. - ---chmod=(+|-)x:: - Set the execute permissions on the updated files. - ---[no-]assume-unchanged:: - When this flag is specified, the object names recorded - for the paths are not updated. Instead, this option - sets/unsets the "assume unchanged" bit for the - paths. When the "assume unchanged" bit is on, the user - promises not to change the file and allows Git to assume - that the working tree file matches what is recorded in - the index. If you want to change the working tree file, - you need to unset the bit to tell Git. This is - sometimes helpful when working with a big project on a - filesystem that has very slow lstat(2) system call - (e.g. cifs). -+ -Git will fail (gracefully) in case it needs to modify this file -in the index e.g. when merging in a commit; -thus, in case the assumed-untracked file is changed upstream, -you will need to handle the situation manually. - ---really-refresh:: - Like `--refresh`, but checks stat information unconditionally, - without regard to the "assume unchanged" setting. - ---[no-]skip-worktree:: - When one of these flags is specified, the object name recorded - for the paths are not updated. Instead, these options - set and unset the "skip-worktree" bit for the paths. See - section "Skip-worktree bit" below for more information. - ---[no-]fsmonitor-valid:: - When one of these flags is specified, the object name recorded - for the paths are not updated. Instead, these options - set and unset the "fsmonitor valid" bit for the paths. See - section "File System Monitor" below for more information. - --g:: ---again:: - Runs 'git update-index' itself on the paths whose index - entries are different from those from the `HEAD` commit. - ---unresolve:: - Restores the 'unmerged' or 'needs updating' state of a - file during a merge if it was cleared by accident. - ---info-only:: - Do not create objects in the object database for all - <file> arguments that follow this flag; just insert - their object IDs into the index. - ---force-remove:: - Remove the file from the index even when the working directory - still has such a file. (Implies --remove.) - ---replace:: - By default, when a file `path` exists in the index, - 'git update-index' refuses an attempt to add `path/file`. - Similarly if a file `path/file` exists, a file `path` - cannot be added. With --replace flag, existing entries - that conflict with the entry being added are - automatically removed with warning messages. - ---stdin:: - Instead of taking list of paths from the command line, - read list of paths from the standard input. Paths are - separated by LF (i.e. one path per line) by default. - ---verbose:: - Report what is being added and removed from index. - ---index-version <n>:: - Write the resulting index out in the named on-disk format version. - Supported versions are 2, 3 and 4. The current default version is 2 - or 3, depending on whether extra features are used, such as - `git add -N`. -+ -Version 4 performs a simple pathname compression that reduces index -size by 30%-50% on large repositories, which results in faster load -time. Version 4 is relatively young (first released in 1.8.0 in -October 2012). Other Git implementations such as JGit and libgit2 -may not support it yet. - --z:: - Only meaningful with `--stdin` or `--index-info`; paths are - separated with NUL character instead of LF. - ---split-index:: ---no-split-index:: - Enable or disable split index mode. If split-index mode is - already enabled and `--split-index` is given again, all - changes in $GIT_DIR/index are pushed back to the shared index - file. -+ -These options take effect whatever the value of the `core.splitIndex` -configuration variable (see linkgit:git-config[1]). But a warning is -emitted when the change goes against the configured value, as the -configured value will take effect next time the index is read and this -will remove the intended effect of the option. - ---untracked-cache:: ---no-untracked-cache:: - Enable or disable untracked cache feature. Please use - `--test-untracked-cache` before enabling it. -+ -These options take effect whatever the value of the `core.untrackedCache` -configuration variable (see linkgit:git-config[1]). But a warning is -emitted when the change goes against the configured value, as the -configured value will take effect next time the index is read and this -will remove the intended effect of the option. - ---test-untracked-cache:: - Only perform tests on the working directory to make sure - untracked cache can be used. You have to manually enable - untracked cache using `--untracked-cache` or - `--force-untracked-cache` or the `core.untrackedCache` - configuration variable afterwards if you really want to use - it. If a test fails the exit code is 1 and a message - explains what is not working as needed, otherwise the exit - code is 0 and OK is printed. - ---force-untracked-cache:: - Same as `--untracked-cache`. Provided for backwards - compatibility with older versions of Git where - `--untracked-cache` used to imply `--test-untracked-cache` but - this option would enable the extension unconditionally. - ---fsmonitor:: ---no-fsmonitor:: - Enable or disable files system monitor feature. These options - take effect whatever the value of the `core.fsmonitor` - configuration variable (see linkgit:git-config[1]). But a warning - is emitted when the change goes against the configured value, as - the configured value will take effect next time the index is - read and this will remove the intended effect of the option. - -\--:: - Do not interpret any more arguments as options. - -<file>:: - Files to act on. - Note that files beginning with '.' are discarded. This includes - `./file` and `dir/./file`. If you don't want this, then use - cleaner names. - The same applies to directories ending '/' and paths with '//' - -USING --REFRESH ---------------- -`--refresh` does not calculate a new sha1 file or bring the index -up to date for mode/content changes. But what it *does* do is to -"re-match" the stat information of a file with the index, so that you -can refresh the index for a file that hasn't been changed but where -the stat entry is out of date. - -For example, you'd want to do this after doing a 'git read-tree', to link -up the stat index details with the proper files. - -USING --CACHEINFO OR --INFO-ONLY --------------------------------- -`--cacheinfo` is used to register a file that is not in the -current working directory. This is useful for minimum-checkout -merging. - -To pretend you have a file at path with mode and sha1, say: - ----------------- -$ git update-index --add --cacheinfo <mode>,<sha1>,<path> ----------------- - -`--info-only` is used to register files without placing them in the object -database. This is useful for status-only repositories. - -Both `--cacheinfo` and `--info-only` behave similarly: the index is updated -but the object database isn't. `--cacheinfo` is useful when the object is -in the database but the file isn't available locally. `--info-only` is -useful when the file is available, but you do not wish to update the -object database. - - -USING --INDEX-INFO ------------------- - -`--index-info` is a more powerful mechanism that lets you feed -multiple entry definitions from the standard input, and designed -specifically for scripts. It can take inputs of three formats: - - . mode SP type SP sha1 TAB path -+ -This format is to stuff `git ls-tree` output into the index. - - . mode SP sha1 SP stage TAB path -+ -This format is to put higher order stages into the -index file and matches 'git ls-files --stage' output. - - . mode SP sha1 TAB path -+ -This format is no longer produced by any Git command, but is -and will continue to be supported by `update-index --index-info`. - -To place a higher stage entry to the index, the path should -first be removed by feeding a mode=0 entry for the path, and -then feeding necessary input lines in the third format. - -For example, starting with this index: - ------------- -$ git ls-files -s -100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0 frotz ------------- - -you can feed the following input to `--index-info`: - ------------- -$ git update-index --index-info -0 0000000000000000000000000000000000000000 frotz -100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz -100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz ------------- - -The first line of the input feeds 0 as the mode to remove the -path; the SHA-1 does not matter as long as it is well formatted. -Then the second and third line feeds stage 1 and stage 2 entries -for that path. After the above, we would end up with this: - ------------- -$ git ls-files -s -100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz -100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz ------------- - - -USING ``ASSUME UNCHANGED'' BIT ------------------------------- - -Many operations in Git depend on your filesystem to have an -efficient `lstat(2)` implementation, so that `st_mtime` -information for working tree files can be cheaply checked to see -if the file contents have changed from the version recorded in -the index file. Unfortunately, some filesystems have -inefficient `lstat(2)`. If your filesystem is one of them, you -can set "assume unchanged" bit to paths you have not changed to -cause Git not to do this check. Note that setting this bit on a -path does not mean Git will check the contents of the file to -see if it has changed -- it makes Git to omit any checking and -assume it has *not* changed. When you make changes to working -tree files, you have to explicitly tell Git about it by dropping -"assume unchanged" bit, either before or after you modify them. - -In order to set "assume unchanged" bit, use `--assume-unchanged` -option. To unset, use `--no-assume-unchanged`. To see which files -have the "assume unchanged" bit set, use `git ls-files -v` -(see linkgit:git-ls-files[1]). - -The command looks at `core.ignorestat` configuration variable. When -this is true, paths updated with `git update-index paths...` and -paths updated with other Git commands that update both index and -working tree (e.g. 'git apply --index', 'git checkout-index -u', -and 'git read-tree -u') are automatically marked as "assume -unchanged". Note that "assume unchanged" bit is *not* set if -`git update-index --refresh` finds the working tree file matches -the index (use `git update-index --really-refresh` if you want -to mark them as "assume unchanged"). - - -EXAMPLES --------- -To update and refresh only the files already checked out: - ----------------- -$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh ----------------- - -On an inefficient filesystem with `core.ignorestat` set:: -+ ------------- -$ git update-index --really-refresh <1> -$ git update-index --no-assume-unchanged foo.c <2> -$ git diff --name-only <3> -$ edit foo.c -$ git diff --name-only <4> -M foo.c -$ git update-index foo.c <5> -$ git diff --name-only <6> -$ edit foo.c -$ git diff --name-only <7> -$ git update-index --no-assume-unchanged foo.c <8> -$ git diff --name-only <9> -M foo.c ------------- -+ -<1> forces lstat(2) to set "assume unchanged" bits for paths that match index. -<2> mark the path to be edited. -<3> this does lstat(2) and finds index matches the path. -<4> this does lstat(2) and finds index does *not* match the path. -<5> registering the new version to index sets "assume unchanged" bit. -<6> and it is assumed unchanged. -<7> even after you edit it. -<8> you can tell about the change after the fact. -<9> now it checks with lstat(2) and finds it has been changed. - - -SKIP-WORKTREE BIT ------------------ - -Skip-worktree bit can be defined in one (long) sentence: When reading -an entry, if it is marked as skip-worktree, then Git pretends its -working directory version is up to date and read the index version -instead. - -To elaborate, "reading" means checking for file existence, reading -file attributes or file content. The working directory version may be -present or absent. If present, its content may match against the index -version or not. Writing is not affected by this bit, content safety -is still first priority. Note that Git _can_ update working directory -file, that is marked skip-worktree, if it is safe to do so (i.e. -working directory version matches index version) - -Although this bit looks similar to assume-unchanged bit, its goal is -different from assume-unchanged bit's. Skip-worktree also takes -precedence over assume-unchanged bit when both are set. - -SPLIT INDEX ------------ - -This mode is designed for repositories with very large indexes, and -aims at reducing the time it takes to repeatedly write these indexes. - -In this mode, the index is split into two files, $GIT_DIR/index and -$GIT_DIR/sharedindex.<SHA-1>. Changes are accumulated in -$GIT_DIR/index, the split index, while the shared index file contains -all index entries and stays unchanged. - -All changes in the split index are pushed back to the shared index -file when the number of entries in the split index reaches a level -specified by the splitIndex.maxPercentChange config variable (see -linkgit:git-config[1]). - -Each time a new shared index file is created, the old shared index -files are deleted if their modification time is older than what is -specified by the splitIndex.sharedIndexExpire config variable (see -linkgit:git-config[1]). - -To avoid deleting a shared index file that is still used, its -modification time is updated to the current time everytime a new split -index based on the shared index file is either created or read from. - -UNTRACKED CACHE ---------------- - -This cache is meant to speed up commands that involve determining -untracked files such as `git status`. - -This feature works by recording the mtime of the working tree -directories and then omitting reading directories and stat calls -against files in those directories whose mtime hasn't changed. For -this to work the underlying operating system and file system must -change the `st_mtime` field of directories if files in the directory -are added, modified or deleted. - -You can test whether the filesystem supports that with the -`--test-untracked-cache` option. The `--untracked-cache` option used -to implicitly perform that test in older versions of Git, but that's -no longer the case. - -If you want to enable (or disable) this feature, it is easier to use -the `core.untrackedCache` configuration variable (see -linkgit:git-config[1]) than using the `--untracked-cache` option to -`git update-index` in each repository, especially if you want to do so -across all repositories you use, because you can set the configuration -variable to `true` (or `false`) in your `$HOME/.gitconfig` just once -and have it affect all repositories you touch. - -When the `core.untrackedCache` configuration variable is changed, the -untracked cache is added to or removed from the index the next time a -command reads the index; while when `--[no-|force-]untracked-cache` -are used, the untracked cache is immediately added to or removed from -the index. - -Before 2.17, the untracked cache had a bug where replacing a directory -with a symlink to another directory could cause it to incorrectly show -files tracked by git as untracked. See the "status: add a failing test -showing a core.untrackedCache bug" commit to git.git. A workaround for -that is (and this might work for other undiscovered bugs in the -future): - ----------------- -$ git -c core.untrackedCache=false status ----------------- - -This bug has also been shown to affect non-symlink cases of replacing -a directory with a file when it comes to the internal structures of -the untracked cache, but no case has been reported where this resulted in -wrong "git status" output. - -There are also cases where existing indexes written by git versions -before 2.17 will reference directories that don't exist anymore, -potentially causing many "could not open directory" warnings to be -printed on "git status". These are new warnings for existing issues -that were previously silently discarded. - -As with the bug described above the solution is to one-off do a "git -status" run with `core.untrackedCache=false` to flush out the leftover -bad data. - -FILE SYSTEM MONITOR -------------------- - -This feature is intended to speed up git operations for repos that have -large working directories. - -It enables git to work together with a file system monitor (see the -"fsmonitor-watchman" section of linkgit:githooks[5]) that can -inform it as to what files have been modified. This enables git to avoid -having to lstat() every file to find modified files. - -When used in conjunction with the untracked cache, it can further improve -performance by avoiding the cost of scanning the entire working directory -looking for new files. - -If you want to enable (or disable) this feature, it is easier to use -the `core.fsmonitor` configuration variable (see -linkgit:git-config[1]) than using the `--fsmonitor` option to -`git update-index` in each repository, especially if you want to do so -across all repositories you use, because you can set the configuration -variable in your `$HOME/.gitconfig` just once and have it affect all -repositories you touch. - -When the `core.fsmonitor` configuration variable is changed, the -file system monitor is added to or removed from the index the next time -a command reads the index. When `--[no-]fsmonitor` are used, the file -system monitor is immediately added to or removed from the index. - -CONFIGURATION -------------- - -The command honors `core.filemode` configuration variable. If -your repository is on a filesystem whose executable bits are -unreliable, this should be set to 'false' (see linkgit:git-config[1]). -This causes the command to ignore differences in file modes recorded -in the index and the file mode on the filesystem if they differ only on -executable bit. On such an unfortunate filesystem, you may -need to use 'git update-index --chmod='. - -Quite similarly, if `core.symlinks` configuration variable is set -to 'false' (see linkgit:git-config[1]), symbolic links are checked out -as plain files, and this command does not modify a recorded file mode -from symbolic link to regular file. - -The command looks at `core.ignorestat` configuration variable. See -'Using "assume unchanged" bit' section above. - -The command also looks at `core.trustctime` configuration variable. -It can be useful when the inode change time is regularly modified by -something outside Git (file system crawlers and backup systems use -ctime for marking files processed) (see linkgit:git-config[1]). - -The untracked cache extension can be enabled by the -`core.untrackedCache` configuration variable (see -linkgit:git-config[1]). - -SEE ALSO --------- -linkgit:git-config[1], -linkgit:git-add[1], -linkgit:git-ls-files[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-update-ref.txt b/third_party/git/Documentation/git-update-ref.txt deleted file mode 100644 index 9671423117..0000000000 --- a/third_party/git/Documentation/git-update-ref.txt +++ /dev/null @@ -1,152 +0,0 @@ -git-update-ref(1) -================= - -NAME ----- -git-update-ref - Update the object name stored in a ref safely - -SYNOPSIS --------- -[verse] -'git update-ref' [-m <reason>] [--no-deref] (-d <ref> [<oldvalue>] | [--create-reflog] <ref> <newvalue> [<oldvalue>] | --stdin [-z]) - -DESCRIPTION ------------ -Given two arguments, stores the <newvalue> in the <ref>, possibly -dereferencing the symbolic refs. E.g. `git update-ref HEAD -<newvalue>` updates the current branch head to the new object. - -Given three arguments, stores the <newvalue> in the <ref>, -possibly dereferencing the symbolic refs, after verifying that -the current value of the <ref> matches <oldvalue>. -E.g. `git update-ref refs/heads/master <newvalue> <oldvalue>` -updates the master branch head to <newvalue> only if its current -value is <oldvalue>. You can specify 40 "0" or an empty string -as <oldvalue> to make sure that the ref you are creating does -not exist. - -It also allows a "ref" file to be a symbolic pointer to another -ref file by starting with the four-byte header sequence of -"ref:". - -More importantly, it allows the update of a ref file to follow -these symbolic pointers, whether they are symlinks or these -"regular file symbolic refs". It follows *real* symlinks only -if they start with "refs/": otherwise it will just try to read -them and update them as a regular file (i.e. it will allow the -filesystem to follow them, but will overwrite such a symlink to -somewhere else with a regular filename). - -If --no-deref is given, <ref> itself is overwritten, rather than -the result of following the symbolic pointers. - -In general, using - - git update-ref HEAD "$head" - -should be a _lot_ safer than doing - - echo "$head" > "$GIT_DIR/HEAD" - -both from a symlink following standpoint *and* an error checking -standpoint. The "refs/" rule for symlinks means that symlinks -that point to "outside" the tree are safe: they'll be followed -for reading but not for writing (so we'll never write through a -ref symlink to some other tree, if you have copied a whole -archive by creating a symlink tree). - -With `-d` flag, it deletes the named <ref> after verifying it -still contains <oldvalue>. - -With `--stdin`, update-ref reads instructions from standard input and -performs all modifications together. Specify commands of the form: - - update SP <ref> SP <newvalue> [SP <oldvalue>] LF - create SP <ref> SP <newvalue> LF - delete SP <ref> [SP <oldvalue>] LF - verify SP <ref> [SP <oldvalue>] LF - option SP <opt> LF - -With `--create-reflog`, update-ref will create a reflog for each ref -even if one would not ordinarily be created. - -Quote fields containing whitespace as if they were strings in C source -code; i.e., surrounded by double-quotes and with backslash escapes. -Use 40 "0" characters or the empty string to specify a zero value. To -specify a missing value, omit the value and its preceding SP entirely. - -Alternatively, use `-z` to specify in NUL-terminated format, without -quoting: - - update SP <ref> NUL <newvalue> NUL [<oldvalue>] NUL - create SP <ref> NUL <newvalue> NUL - delete SP <ref> NUL [<oldvalue>] NUL - verify SP <ref> NUL [<oldvalue>] NUL - option SP <opt> NUL - -In this format, use 40 "0" to specify a zero value, and use the empty -string to specify a missing value. - -In either format, values can be specified in any form that Git -recognizes as an object name. Commands in any other format or a -repeated <ref> produce an error. Command meanings are: - -update:: - Set <ref> to <newvalue> after verifying <oldvalue>, if given. - Specify a zero <newvalue> to ensure the ref does not exist - after the update and/or a zero <oldvalue> to make sure the - ref does not exist before the update. - -create:: - Create <ref> with <newvalue> after verifying it does not - exist. The given <newvalue> may not be zero. - -delete:: - Delete <ref> after verifying it exists with <oldvalue>, if - given. If given, <oldvalue> may not be zero. - -verify:: - Verify <ref> against <oldvalue> but do not change it. If - <oldvalue> zero or missing, the ref must not exist. - -option:: - Modify behavior of the next command naming a <ref>. - The only valid option is `no-deref` to avoid dereferencing - a symbolic ref. - -If all <ref>s can be locked with matching <oldvalue>s -simultaneously, all modifications are performed. Otherwise, no -modifications are performed. Note that while each individual -<ref> is updated or deleted atomically, a concurrent reader may -still see a subset of the modifications. - -LOGGING UPDATES ---------------- -If config parameter "core.logAllRefUpdates" is true and the ref is one under -"refs/heads/", "refs/remotes/", "refs/notes/", or the symbolic ref HEAD; or -the file "$GIT_DIR/logs/<ref>" exists then `git update-ref` will append -a line to the log file "$GIT_DIR/logs/<ref>" (dereferencing all -symbolic refs before creating the log name) describing the change -in ref value. Log lines are formatted as: - - oldsha1 SP newsha1 SP committer LF - -Where "oldsha1" is the 40 character hexadecimal value previously -stored in <ref>, "newsha1" is the 40 character hexadecimal value of -<newvalue> and "committer" is the committer's name, email address -and date in the standard Git committer ident format. - -Optionally with -m: - - oldsha1 SP newsha1 SP committer TAB message LF - -Where all fields are as described above and "message" is the -value supplied to the -m option. - -An update will fail (without changing <ref>) if the current user is -unable to create a new log file, append to the existing log file -or does not have committer information available. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-update-server-info.txt b/third_party/git/Documentation/git-update-server-info.txt deleted file mode 100644 index 969bb2e15f..0000000000 --- a/third_party/git/Documentation/git-update-server-info.txt +++ /dev/null @@ -1,35 +0,0 @@ -git-update-server-info(1) -========================= - -NAME ----- -git-update-server-info - Update auxiliary info file to help dumb servers - - -SYNOPSIS --------- -[verse] -'git update-server-info' - -DESCRIPTION ------------ -A dumb server that does not do on-the-fly pack generations must -have some auxiliary information files in $GIT_DIR/info and -$GIT_OBJECT_DIRECTORY/info directories to help clients discover -what references and packs the server has. This command -generates such auxiliary files. - -OUTPUT ------- - -Currently the command updates the following files. Please see -linkgit:gitrepository-layout[5] for description of -what they are for: - -* objects/info/packs - -* info/refs - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-upload-archive.txt b/third_party/git/Documentation/git-upload-archive.txt deleted file mode 100644 index fba0f1c1b2..0000000000 --- a/third_party/git/Documentation/git-upload-archive.txt +++ /dev/null @@ -1,62 +0,0 @@ -git-upload-archive(1) -===================== - -NAME ----- -git-upload-archive - Send archive back to git-archive - - -SYNOPSIS --------- -[verse] -'git upload-archive' <directory> - -DESCRIPTION ------------ -Invoked by 'git archive --remote' and sends a generated archive to the -other end over the Git protocol. - -This command is usually not invoked directly by the end user. The UI -for the protocol is on the 'git archive' side, and the program pair -is meant to be used to get an archive from a remote repository. - -SECURITY --------- - -In order to protect the privacy of objects that have been removed from -history but may not yet have been pruned, `git-upload-archive` avoids -serving archives for commits and trees that are not reachable from the -repository's refs. However, because calculating object reachability is -computationally expensive, `git-upload-archive` implements a stricter -but easier-to-check set of rules: - - 1. Clients may request a commit or tree that is pointed to directly by - a ref. E.g., `git archive --remote=origin v1.0`. - - 2. Clients may request a sub-tree within a commit or tree using the - `ref:path` syntax. E.g., `git archive --remote=origin v1.0:Documentation`. - - 3. Clients may _not_ use other sha1 expressions, even if the end - result is reachable. E.g., neither a relative commit like `master^` - nor a literal sha1 like `abcd1234` is allowed, even if the result - is reachable from the refs. - -Note that rule 3 disallows many cases that do not have any privacy -implications. These rules are subject to change in future versions of -git, and the server accessed by `git archive --remote` may or may not -follow these exact rules. - -If the config option `uploadArchive.allowUnreachable` is true, these -rules are ignored, and clients may use arbitrary sha1 expressions. -This is useful if you do not care about the privacy of unreachable -objects, or if your object database is already publicly available for -access via non-smart-http. - -OPTIONS -------- -<directory>:: - The repository to get a tar archive from. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-upload-pack.txt b/third_party/git/Documentation/git-upload-pack.txt deleted file mode 100644 index 9822c1eb1a..0000000000 --- a/third_party/git/Documentation/git-upload-pack.txt +++ /dev/null @@ -1,53 +0,0 @@ -git-upload-pack(1) -================== - -NAME ----- -git-upload-pack - Send objects packed back to git-fetch-pack - - -SYNOPSIS --------- -[verse] -'git-upload-pack' [--[no-]strict] [--timeout=<n>] [--stateless-rpc] - [--advertise-refs] <directory> - -DESCRIPTION ------------ -Invoked by 'git fetch-pack', learns what -objects the other side is missing, and sends them after packing. - -This command is usually not invoked directly by the end user. -The UI for the protocol is on the 'git fetch-pack' side, and the -program pair is meant to be used to pull updates from a remote -repository. For push operations, see 'git send-pack'. - -OPTIONS -------- - ---[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. - -SEE ALSO --------- -linkgit:gitnamespaces[7] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-var.txt b/third_party/git/Documentation/git-var.txt deleted file mode 100644 index 6072f936ab..0000000000 --- a/third_party/git/Documentation/git-var.txt +++ /dev/null @@ -1,70 +0,0 @@ -git-var(1) -========== - -NAME ----- -git-var - Show a Git logical variable - - -SYNOPSIS --------- -[verse] -'git var' ( -l | <variable> ) - -DESCRIPTION ------------ -Prints a Git logical variable. - -OPTIONS -------- --l:: - Cause the logical variables to be listed. In addition, all the - variables of the Git configuration file .git/config are listed - as well. (However, the configuration variables listing functionality - is deprecated in favor of `git config -l`.) - -EXAMPLES --------- - $ git var GIT_AUTHOR_IDENT - Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600 - - -VARIABLES ---------- -GIT_AUTHOR_IDENT:: - The author of a piece of code. - -GIT_COMMITTER_IDENT:: - The person who put a piece of code into Git. - -GIT_EDITOR:: - Text editor for use by Git commands. The value is meant to be - interpreted by the shell when it is used. Examples: `~/bin/vi`, - `$SOME_ENVIRONMENT_VARIABLE`, `"C:\Program Files\Vim\gvim.exe" - --nofork`. The order of preference is the `$GIT_EDITOR` - environment variable, then `core.editor` configuration, then - `$VISUAL`, then `$EDITOR`, and then the default chosen at compile - time, which is usually 'vi'. -ifdef::git-default-editor[] - The build you are using chose '{git-default-editor}' as the default. -endif::git-default-editor[] - -GIT_PAGER:: - Text viewer for use by Git commands (e.g., 'less'). The value - is meant to be interpreted by the shell. The order of preference - is the `$GIT_PAGER` environment variable, then `core.pager` - configuration, then `$PAGER`, and then the default chosen at - compile time (usually 'less'). -ifdef::git-default-pager[] - The build you are using chose '{git-default-pager}' as the default. -endif::git-default-pager[] - -SEE ALSO --------- -linkgit:git-commit-tree[1] -linkgit:git-tag[1] -linkgit:git-config[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-verify-commit.txt b/third_party/git/Documentation/git-verify-commit.txt deleted file mode 100644 index 92097f6673..0000000000 --- a/third_party/git/Documentation/git-verify-commit.txt +++ /dev/null @@ -1,32 +0,0 @@ -git-verify-commit(1) -==================== - -NAME ----- -git-verify-commit - Check the GPG signature of commits - -SYNOPSIS --------- -[verse] -'git verify-commit' <commit>... - -DESCRIPTION ------------ -Validates the GPG signature created by 'git commit -S'. - -OPTIONS -------- ---raw:: - Print the raw gpg status output to standard error instead of the normal - human-readable output. - --v:: ---verbose:: - Print the contents of the commit object before validating it. - -<commit>...:: - SHA-1 identifiers of Git commit objects. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-verify-pack.txt b/third_party/git/Documentation/git-verify-pack.txt deleted file mode 100644 index 61ca6d04c2..0000000000 --- a/third_party/git/Documentation/git-verify-pack.txt +++ /dev/null @@ -1,53 +0,0 @@ -git-verify-pack(1) -================== - -NAME ----- -git-verify-pack - Validate packed Git archive files - - -SYNOPSIS --------- -[verse] -'git verify-pack' [-v|--verbose] [-s|--stat-only] [--] <pack>.idx ... - - -DESCRIPTION ------------ -Reads given idx file for packed Git archive created with the -'git pack-objects' command and verifies idx file and the -corresponding pack file. - -OPTIONS -------- -<pack>.idx ...:: - The idx files to verify. - --v:: ---verbose:: - After verifying the pack, show list of objects contained - in the pack and a histogram of delta chain length. - --s:: ---stat-only:: - Do not verify the pack contents; only show the histogram of delta - chain length. With `--verbose`, list of objects is also shown. - -\--:: - Do not interpret any more arguments as options. - -OUTPUT FORMAT -------------- -When specifying the -v option the format used is: - - SHA-1 type size size-in-packfile offset-in-packfile - -for objects that are not deltified in the pack, and - - SHA-1 type size size-in-packfile offset-in-packfile depth base-SHA-1 - -for objects that are deltified. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-verify-tag.txt b/third_party/git/Documentation/git-verify-tag.txt deleted file mode 100644 index 0b8075dad9..0000000000 --- a/third_party/git/Documentation/git-verify-tag.txt +++ /dev/null @@ -1,32 +0,0 @@ -git-verify-tag(1) -================= - -NAME ----- -git-verify-tag - Check the GPG signature of tags - -SYNOPSIS --------- -[verse] -'git verify-tag' [--format=<format>] <tag>... - -DESCRIPTION ------------ -Validates the gpg signature created by 'git tag'. - -OPTIONS -------- ---raw:: - Print the raw gpg status output to standard error instead of the normal - human-readable output. - --v:: ---verbose:: - Print the contents of the tag object before validating it. - -<tag>...:: - SHA-1 identifiers of Git tag objects. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-web--browse.txt b/third_party/git/Documentation/git-web--browse.txt deleted file mode 100644 index 8d162b56c5..0000000000 --- a/third_party/git/Documentation/git-web--browse.txt +++ /dev/null @@ -1,124 +0,0 @@ -git-web{litdd}browse(1) -======================= - -NAME ----- -git-web--browse - Git helper script to launch a web browser - -SYNOPSIS --------- -[verse] -'git web{litdd}browse' [<options>] <url|file>... - -DESCRIPTION ------------ - -This script tries, as much as possible, to display the URLs and FILEs -that are passed as arguments, as HTML pages in new tabs on an already -opened web browser. - -The following browsers (or commands) are currently supported: - -* firefox (this is the default under X Window when not using KDE) -* iceweasel -* seamonkey -* iceape -* chromium (also supported as chromium-browser) -* google-chrome (also supported as chrome) -* konqueror (this is the default under KDE, see 'Note about konqueror' below) -* opera -* w3m (this is the default outside graphical environments) -* elinks -* links -* lynx -* dillo -* open (this is the default under Mac OS X GUI) -* start (this is the default under MinGW) -* cygstart (this is the default under Cygwin) -* xdg-open - -Custom commands may also be specified. - -OPTIONS -------- --b <browser>:: ---browser=<browser>:: - Use the specified browser. It must be in the list of supported - browsers. - --t <browser>:: ---tool=<browser>:: - Same as above. - --c <conf.var>:: ---config=<conf.var>:: - CONF.VAR is looked up in the Git config files. If it's set, - then its value specifies the browser that should be used. - -CONFIGURATION VARIABLES ------------------------ - -CONF.VAR (from -c option) and web.browser -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The web browser can be specified using a configuration variable passed -with the -c (or --config) command-line option, or the `web.browser` -configuration variable if the former is not used. - -browser.<tool>.path -~~~~~~~~~~~~~~~~~~~ - -You can explicitly provide a full path to your preferred browser by -setting the configuration variable `browser.<tool>.path`. For example, -you can configure the absolute path to firefox by setting -'browser.firefox.path'. Otherwise, 'git web{litdd}browse' assumes the tool -is available in PATH. - -browser.<tool>.cmd -~~~~~~~~~~~~~~~~~~ - -When the browser, specified by options or configuration variables, is -not among the supported ones, then the corresponding -`browser.<tool>.cmd` configuration variable will be looked up. If this -variable exists then 'git web{litdd}browse' will treat the specified tool -as a custom command and will use a shell eval to run the command with -the URLs passed as arguments. - -NOTE ABOUT KONQUEROR --------------------- - -When 'konqueror' is specified by a command-line option or a -configuration variable, we launch 'kfmclient' to try to open the HTML -man page on an already opened konqueror in a new tab if possible. - -For consistency, we also try such a trick if 'browser.konqueror.path' is -set to something like `A_PATH_TO/konqueror`. That means we will try to -launch `A_PATH_TO/kfmclient` instead. - -If you really want to use 'konqueror', then you can use something like -the following: - ------------------------------------------------- - [web] - browser = konq - - [browser "konq"] - cmd = A_PATH_TO/konqueror ------------------------------------------------- - -Note about git-config --global -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Note that these configuration variables should probably be set using -the `--global` flag, for example like this: - ------------------------------------------------- -$ git config --global web.browser firefox ------------------------------------------------- - -as they are probably more user specific than repository specific. -See linkgit:git-config[1] for more information about this. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-whatchanged.txt b/third_party/git/Documentation/git-whatchanged.txt deleted file mode 100644 index 8b63ceb00e..0000000000 --- a/third_party/git/Documentation/git-whatchanged.txt +++ /dev/null @@ -1,43 +0,0 @@ -git-whatchanged(1) -================== - -NAME ----- -git-whatchanged - Show logs with difference each commit introduces - - -SYNOPSIS --------- -[verse] -'git whatchanged' <option>... - -DESCRIPTION ------------ - -Shows commit logs and diff output each commit introduces. - -New users are encouraged to use linkgit:git-log[1] instead. The -`whatchanged` command is essentially the same as linkgit:git-log[1] -but defaults to show the raw format diff output and to skip merges. - -The command is kept primarily for historical reasons; fingers of -many people who learned Git long before `git log` was invented by -reading Linux kernel mailing list are trained to type it. - - -Examples --------- -`git whatchanged -p v2.6.12.. include/scsi drivers/scsi`:: - - Show as patches the commits since version 'v2.6.12' that changed - any file in the include/scsi or drivers/scsi subdirectories - -`git whatchanged --since="2 weeks ago" -- gitk`:: - - Show the changes during the last two weeks to the file 'gitk'. - The "--" is necessary to avoid confusion with the *branch* named - 'gitk' - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-worktree.txt b/third_party/git/Documentation/git-worktree.txt deleted file mode 100644 index 85d92c9761..0000000000 --- a/third_party/git/Documentation/git-worktree.txt +++ /dev/null @@ -1,382 +0,0 @@ -git-worktree(1) -=============== - -NAME ----- -git-worktree - Manage multiple working trees - - -SYNOPSIS --------- -[verse] -'git worktree add' [-f] [--detach] [--checkout] [--lock] [-b <new-branch>] <path> [<commit-ish>] -'git worktree list' [--porcelain] -'git worktree lock' [--reason <string>] <worktree> -'git worktree move' <worktree> <new-path> -'git worktree prune' [-n] [-v] [--expire <expire>] -'git worktree remove' [-f] <worktree> -'git worktree unlock' <worktree> - -DESCRIPTION ------------ - -Manage multiple working trees attached to the same repository. - -A git repository can support multiple working trees, allowing you to check -out more than one branch at a time. With `git worktree add` a new working -tree is associated with the repository. This new working tree is called a -"linked working tree" as opposed to the "main working tree" prepared by "git -init" or "git clone". A repository has one main working tree (if it's not a -bare repository) and zero or more linked working trees. When you are done -with a linked working tree, remove it with `git worktree remove`. - -If a working tree is deleted without using `git worktree remove`, then -its associated administrative files, which reside in the repository -(see "DETAILS" below), will eventually be removed automatically (see -`gc.worktreePruneExpire` in linkgit:git-config[1]), or you can run -`git worktree prune` in the main or any linked working tree to -clean up any stale administrative files. - -If a linked working tree is stored on a portable device or network share -which is not always mounted, you can prevent its administrative files from -being pruned by issuing the `git worktree lock` command, optionally -specifying `--reason` to explain why the working tree is locked. - -COMMANDS --------- -add <path> [<commit-ish>]:: - -Create `<path>` and checkout `<commit-ish>` into it. The new working directory -is linked to the current repository, sharing everything except working -directory specific files such as HEAD, index, etc. `-` may also be -specified as `<commit-ish>`; it is synonymous with `@{-1}`. -+ -If <commit-ish> is a branch name (call it `<branch>`) and is not found, -and neither `-b` nor `-B` nor `--detach` are used, but there does -exist a tracking branch in exactly one remote (call it `<remote>`) -with a matching name, treat as equivalent to: -+ ------------- -$ git worktree add --track -b <branch> <path> <remote>/<branch> ------------- -+ -If the branch exists in multiple remotes and one of them is named by -the `checkout.defaultRemote` configuration variable, we'll use that -one for the purposes of disambiguation, even if the `<branch>` isn't -unique across all remotes. Set it to -e.g. `checkout.defaultRemote=origin` to always checkout remote -branches from there if `<branch>` is ambiguous but exists on the -'origin' remote. See also `checkout.defaultRemote` in -linkgit:git-config[1]. -+ -If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used, -then, as a convenience, the new worktree is associated with a branch -(call it `<branch>`) named after `$(basename <path>)`. If `<branch>` -doesn't exist, a new branch based on HEAD is automatically created as -if `-b <branch>` was given. If `<branch>` does exist, it will be -checked out in the new worktree, if it's not checked out anywhere -else, otherwise the command will refuse to create the worktree (unless -`--force` is used). - -list:: - -List details of each worktree. The main worktree is listed first, followed by -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`. - -move:: - -Move a working tree to a new location. Note that the main working tree -or linked working trees containing submodules cannot be moved. - -prune:: - -Prune working tree information in $GIT_DIR/worktrees. - -remove:: - -Remove a working tree. Only clean working trees (no untracked files -and no modification in tracked files) can be removed. Unclean working -trees or ones with submodules can be removed with `--force`. The main -working tree cannot be removed. - -unlock:: - -Unlock a working tree, allowing it to be pruned, moved or deleted. - -OPTIONS -------- - --f:: ---force:: - By default, `add` refuses to create a new working tree when - `<commit-ish>` is a branch name and is already checked out by - another working tree, or if `<path>` is already assigned to some - working tree but is missing (for instance, if `<path>` was deleted - manually). This option overrides these safeguards. To add a missing but - locked working tree path, specify `--force` twice. -+ -`move` refuses to move a locked working tree unless `--force` is specified -twice. -+ -`remove` refuses to remove an unclean working tree unless `--force` is used. -To remove a locked working tree, specify `--force` twice. - --b <new-branch>:: --B <new-branch>:: - With `add`, create a new branch named `<new-branch>` starting at - `<commit-ish>`, and check out `<new-branch>` into the new working tree. - If `<commit-ish>` is omitted, it defaults to HEAD. - By default, `-b` refuses to create a new branch if it already - exists. `-B` overrides this safeguard, resetting `<new-branch>` to - `<commit-ish>`. - ---detach:: - With `add`, detach HEAD in the new working tree. See "DETACHED HEAD" - in linkgit:git-checkout[1]. - ---[no-]checkout:: - By default, `add` checks out `<commit-ish>`, however, `--no-checkout` can - be used to suppress checkout in order to make customizations, - such as configuring sparse-checkout. See "Sparse checkout" - in linkgit:git-read-tree[1]. - ---[no-]guess-remote:: - With `worktree add <path>`, without `<commit-ish>`, instead - of creating a new branch from HEAD, if there exists a tracking - branch in exactly one remote matching the basename of `<path>`, - base the new branch on the remote-tracking branch, and mark - the remote-tracking branch as "upstream" from the new branch. -+ -This can also be set up as the default behaviour by using the -`worktree.guessRemote` config option. - ---[no-]track:: - When creating a new branch, if `<commit-ish>` is a branch, - mark it as "upstream" from the new branch. This is the - default if `<commit-ish>` is a remote-tracking branch. See - "--track" in linkgit:git-branch[1] for details. - ---lock:: - Keep the working tree locked after creation. This is the - equivalent of `git worktree lock` after `git worktree add`, - but without race condition. - --n:: ---dry-run:: - With `prune`, do not remove anything; just report what it would - remove. - ---porcelain:: - With `list`, output in an easy-to-parse format for scripts. - This format will remain stable across Git versions and regardless of user - configuration. See below for details. - --q:: ---quiet:: - With 'add', suppress feedback messages. - --v:: ---verbose:: - With `prune`, report all removals. - ---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. - -REFS ----- -In multiple working trees, some refs may be shared between all working -trees, some refs are local. One example is HEAD is different for all -working trees. This section is about the sharing rules and how to access -refs of one working tree from another. - -In general, all pseudo refs are per working tree and all refs starting -with "refs/" are shared. Pseudo refs are ones like HEAD which are -directly under GIT_DIR instead of inside GIT_DIR/refs. There is one -exception to this: refs inside refs/bisect and refs/worktree is not -shared. - -Refs that are per working tree can still be accessed from another -working tree via two special paths, main-worktree and worktrees. The -former gives access to per-worktree refs of the main working tree, -while the latter to all linked working trees. - -For example, main-worktree/HEAD or main-worktree/refs/bisect/good -resolve to the same value as the main working tree's HEAD and -refs/bisect/good respectively. Similarly, worktrees/foo/HEAD or -worktrees/bar/refs/bisect/bad are the same as -GIT_COMMON_DIR/worktrees/foo/HEAD and -GIT_COMMON_DIR/worktrees/bar/refs/bisect/bad. - -To access refs, it's best not to look inside GIT_DIR directly. Instead -use commands such as linkgit:git-rev-parse[1] or linkgit:git-update-ref[1] -which will handle refs correctly. - -CONFIGURATION FILE ------------------- -By default, the repository "config" file is shared across all working -trees. If the config variables `core.bare` or `core.worktree` are -already present in the config file, they will be applied to the main -working trees only. - -In order to have configuration specific to working trees, you can turn -on "worktreeConfig" extension, e.g.: - ------------- -$ git config extensions.worktreeConfig true ------------- - -In this mode, specific configuration stays in the path pointed by `git -rev-parse --git-path config.worktree`. You can add or update -configuration in this file with `git config --worktree`. Older Git -versions will refuse to access repositories with this extension. - -Note that in this file, the exception for `core.bare` and `core.worktree` -is gone. If you have them in $GIT_DIR/config before, you must move -them to the `config.worktree` of the main working tree. You may also -take this opportunity to review and move other configuration that you -do not want to share to all working trees: - - - `core.worktree` and `core.bare` should never be shared - - - `core.sparseCheckout` is recommended per working tree, unless you - are sure you always use sparse checkout for all working trees. - -DETAILS -------- -Each linked working tree has a private sub-directory in the repository's -$GIT_DIR/worktrees directory. The private sub-directory's name is usually -the base name of the linked working tree's path, possibly appended with a -number to make it unique. For example, when `$GIT_DIR=/path/main/.git` the -command `git worktree add /path/other/test-next next` creates the linked -working tree in `/path/other/test-next` and also creates a -`$GIT_DIR/worktrees/test-next` directory (or `$GIT_DIR/worktrees/test-next1` -if `test-next` is already taken). - -Within a linked working tree, $GIT_DIR is set to point to this private -directory (e.g. `/path/main/.git/worktrees/test-next` in the example) and -$GIT_COMMON_DIR is set to point back to the main working tree's $GIT_DIR -(e.g. `/path/main/.git`). These settings are made in a `.git` file located at -the top directory of the linked working tree. - -Path resolution via `git rev-parse --git-path` uses either -$GIT_DIR or $GIT_COMMON_DIR depending on the path. For example, in the -linked working tree `git rev-parse --git-path HEAD` returns -`/path/main/.git/worktrees/test-next/HEAD` (not -`/path/other/test-next/.git/HEAD` or `/path/main/.git/HEAD`) while `git -rev-parse --git-path refs/heads/master` uses -$GIT_COMMON_DIR and returns `/path/main/.git/refs/heads/master`, -since refs are shared across all working trees, except refs/bisect and -refs/worktree. - -See linkgit:gitrepository-layout[5] for more information. The rule of -thumb is do not make any assumption about whether a path belongs to -$GIT_DIR or $GIT_COMMON_DIR when you need to directly access something -inside $GIT_DIR. Use `git rev-parse --git-path` to get the final path. - -If you manually move a linked working tree, you need to update the 'gitdir' file -in the entry's directory. For example, if a linked working tree is moved -to `/newpath/test-next` and its `.git` file points to -`/path/main/.git/worktrees/test-next`, then update -`/path/main/.git/worktrees/test-next/gitdir` to reference `/newpath/test-next` -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), 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 -`/path/main/.git/worktrees/test-next/locked` will prevent the -`test-next` entry from being pruned. See -linkgit:gitrepository-layout[5] for details. - -When extensions.worktreeConfig is enabled, the config file -`.git/worktrees/<id>/config.worktree` is read after `.git/config` is. - -LIST OUTPUT FORMAT ------------------- -The worktree list command has two output formats. The default format shows the -details on a single line with columns. For example: - ------------- -$ git worktree list -/path/to/bare-source (bare) -/path/to/linked-worktree abcd1234 [master] -/path/to/other-linked-worktree 1234abc (detached HEAD) ------------- - -Porcelain Format -~~~~~~~~~~~~~~~~ -The porcelain format has a line per attribute. Attributes are listed with a -label and value separated by a single space. Boolean attributes (like 'bare' -and 'detached') are listed as a label only, and are only present if and only -if the value is true. The first attribute of a worktree is always `worktree`, -an empty line indicates the end of the record. For example: - ------------- -$ git worktree list --porcelain -worktree /path/to/bare-source -bare - -worktree /path/to/linked-worktree -HEAD abcd1234abcd1234abcd1234abcd1234abcd1234 -branch refs/heads/master - -worktree /path/to/other-linked-worktree -HEAD 1234abc1234abc1234abc1234abc1234abc1234a -detached - ------------- - -EXAMPLES --------- -You are in the middle of a refactoring session and your boss comes in and -demands that you fix something immediately. You might typically use -linkgit:git-stash[1] to store your changes away temporarily, however, your -working tree is in such a state of disarray (with new, moved, and removed -files, and other bits and pieces strewn around) that you don't want to risk -disturbing any of it. Instead, you create a temporary linked working tree to -make the emergency fix, remove it when done, and then resume your earlier -refactoring session. - ------------- -$ git worktree add -b emergency-fix ../temp master -$ pushd ../temp -# ... hack hack hack ... -$ git commit -a -m 'emergency fix for boss' -$ popd -$ git worktree remove ../temp ------------- - -BUGS ----- -Multiple checkout in general is still experimental, and the support -for submodules is incomplete. It is NOT recommended to make multiple -checkouts of a superproject. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git-write-tree.txt b/third_party/git/Documentation/git-write-tree.txt deleted file mode 100644 index f22041a9dc..0000000000 --- a/third_party/git/Documentation/git-write-tree.txt +++ /dev/null @@ -1,42 +0,0 @@ -git-write-tree(1) -================= - -NAME ----- -git-write-tree - Create a tree object from the current index - - -SYNOPSIS --------- -[verse] -'git write-tree' [--missing-ok] [--prefix=<prefix>/] - -DESCRIPTION ------------ -Creates a tree object using the current index. The name of the new -tree object is printed to standard output. - -The index must be in a fully merged state. - -Conceptually, 'git write-tree' sync()s the current index contents -into a set of tree files. -In order to have that match what is actually in your directory right -now, you need to have done a 'git update-index' phase before you did the -'git write-tree'. - - -OPTIONS -------- ---missing-ok:: - Normally 'git write-tree' ensures that the objects referenced by the - directory exist in the object database. This option disables this - check. - ---prefix=<prefix>/:: - Writes a tree object that represents a subdirectory - `<prefix>`. This can be used to write the tree object - for a subproject that is in the named subdirectory. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/git.txt b/third_party/git/Documentation/git.txt deleted file mode 100644 index 9b82564d1a..0000000000 --- a/third_party/git/Documentation/git.txt +++ /dev/null @@ -1,947 +0,0 @@ -git(1) -====== - -NAME ----- -git - the stupid content tracker - - -SYNOPSIS --------- -[verse] -'git' [--version] [--help] [-C <path>] [-c <name>=<value>] - [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path] - [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare] - [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>] - [--super-prefix=<path>] - <command> [<args>] - -DESCRIPTION ------------ -Git is a fast, scalable, distributed revision control system with an -unusually rich command set that provides both high-level operations -and full access to internals. - -See linkgit:gittutorial[7] to get started, then see -linkgit:giteveryday[7] for a useful minimum set of -commands. The link:user-manual.html[Git User's Manual] has a more -in-depth introduction. - -After you mastered the basic concepts, you can come back to this -page to learn what commands Git offers. You can learn more about -individual Git commands with "git help command". linkgit:gitcli[7] -manual page gives you an overview of the command-line command syntax. - -A formatted and hyperlinked copy of the latest Git documentation -can be viewed at https://git.github.io/htmldocs/git.html -or https://git-scm.com/docs. - - -OPTIONS -------- ---version:: - Prints the Git suite version that the 'git' program came from. - ---help:: - Prints the synopsis and a list of the most commonly used - commands. If the option `--all` or `-a` is given then all - available commands are printed. If a Git command is named this - option will bring up the manual page for that command. -+ -Other options are available to control how the manual page is -displayed. See linkgit:git-help[1] for more information, -because `git --help ...` is converted internally into `git -help ...`. - --C <path>:: - Run as if git was started in '<path>' instead of the current working - directory. When multiple `-C` options are given, each subsequent - non-absolute `-C <path>` is interpreted relative to the preceding `-C - <path>`. If '<path>' is present but empty, e.g. `-C ""`, then the - current working directory is left unchanged. -+ -This option affects options that expect path name like `--git-dir` and -`--work-tree` in that their interpretations of the path names would be -made relative to the working directory caused by the `-C` option. For -example the following invocations are equivalent: - - git --git-dir=a.git --work-tree=b -C c status - git --git-dir=c/a.git --work-tree=c/b status - --c <name>=<value>:: - Pass a configuration parameter to the command. The value - given will override values from configuration files. - The <name> is expected in the same format as listed by - 'git config' (subkeys separated by dots). -+ -Note that omitting the `=` in `git -c foo.bar ...` is allowed and sets -`foo.bar` to the boolean true value (just like `[foo]bar` would in a -config file). Including the equals but with an empty value (like `git -c -foo.bar= ...`) sets `foo.bar` to the empty string which `git config ---type=bool` will convert to `false`. - ---exec-path[=<path>]:: - Path to wherever your core Git programs are installed. - This can also be controlled by setting the GIT_EXEC_PATH - environment variable. If no path is given, 'git' will print - the current setting and then exit. - ---html-path:: - Print the path, without trailing slash, where Git's HTML - documentation is installed and exit. - ---man-path:: - Print the manpath (see `man(1)`) for the man pages for - this version of Git and exit. - ---info-path:: - Print the path where the Info files documenting this - version of Git are installed and exit. - --p:: ---paginate:: - Pipe all output into 'less' (or if set, $PAGER) if standard - output is a terminal. This overrides the `pager.<cmd>` - configuration options (see the "Configuration Mechanism" section - below). - --P:: ---no-pager:: - Do not pipe Git output into a pager. - ---git-dir=<path>:: - Set the path to the repository. This can also be controlled by - setting the `GIT_DIR` environment variable. It can be an absolute - path or relative path to current working directory. - ---work-tree=<path>:: - Set the path to the working tree. It can be an absolute path - or a path relative to the current working directory. - This can also be controlled by setting the GIT_WORK_TREE - environment variable and the core.worktree configuration - variable (see core.worktree in linkgit:git-config[1] for a - more detailed discussion). - ---namespace=<path>:: - Set the Git namespace. See linkgit:gitnamespaces[7] for more - 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 - directory. - ---no-replace-objects:: - Do not use replacement refs to replace Git objects. See - linkgit:git-replace[1] for more information. - ---literal-pathspecs:: - Treat pathspecs literally (i.e. no globbing, no pathspec magic). - This is equivalent to setting the `GIT_LITERAL_PATHSPECS` environment - variable to `1`. - ---glob-pathspecs:: - Add "glob" magic to all pathspec. This is equivalent to setting - the `GIT_GLOB_PATHSPECS` environment variable to `1`. Disabling - globbing on individual pathspecs can be done using pathspec - magic ":(literal)" - ---noglob-pathspecs:: - Add "literal" magic to all pathspec. This is equivalent to setting - the `GIT_NOGLOB_PATHSPECS` environment variable to `1`. Enabling - globbing on individual pathspecs can be done using pathspec - magic ":(glob)" - ---icase-pathspecs:: - Add "icase" magic to all pathspec. This is equivalent to setting - the `GIT_ICASE_PATHSPECS` environment variable to `1`. - ---no-optional-locks:: - Do not perform optional operations that require locks. This is - equivalent to setting the `GIT_OPTIONAL_LOCKS` to `0`. - ---list-cmds=group[,group...]:: - List commands by group. This is an internal/experimental - option and may change or be removed in the future. Supported - groups are: builtins, parseopt (builtin commands that use - parse-options), main (all commands in libexec directory), - others (all other commands in `$PATH` that have git- prefix), - list-<category> (see categories in command-list.txt), - nohelpers (exclude helper commands), alias and config - (retrieve command list from config variable completion.commands) - -GIT COMMANDS ------------- - -We divide Git into high level ("porcelain") commands and low level -("plumbing") commands. - -High-level commands (porcelain) -------------------------------- - -We separate the porcelain commands into the main commands and some -ancillary user utilities. - -Main porcelain commands -~~~~~~~~~~~~~~~~~~~~~~~ - -include::cmds-mainporcelain.txt[] - -Ancillary Commands -~~~~~~~~~~~~~~~~~~ -Manipulators: - -include::cmds-ancillarymanipulators.txt[] - -Interrogators: - -include::cmds-ancillaryinterrogators.txt[] - - -Interacting with Others -~~~~~~~~~~~~~~~~~~~~~~~ - -These commands are to interact with foreign SCM and with other -people via patch over e-mail. - -include::cmds-foreignscminterface.txt[] - -Reset, restore and revert -~~~~~~~~~~~~~~~~~~~~~~~~~ -There are three commands with similar names: `git reset`, -`git restore` and `git revert`. - -* linkgit:git-revert[1] is about making a new commit that reverts the - changes made by other commits. - -* linkgit:git-restore[1] is about restoring files in the working tree - from either the index or another commit. This command does not - update your branch. The command can also be used to restore files in - the index from another commit. - -* linkgit:git-reset[1] is about updating your branch, moving the tip - in order to add or remove commits from the branch. This operation - changes the commit history. -+ -`git reset` can also be used to restore the index, overlapping with -`git restore`. - - -Low-level commands (plumbing) ------------------------------ - -Although Git includes its -own porcelain layer, its low-level commands are sufficient to support -development of alternative porcelains. Developers of such porcelains -might start by reading about linkgit:git-update-index[1] and -linkgit:git-read-tree[1]. - -The interface (input, output, set of options and the semantics) -to these low-level commands are meant to be a lot more stable -than Porcelain level commands, because these commands are -primarily for scripted use. The interface to Porcelain commands -on the other hand are subject to change in order to improve the -end user experience. - -The following description divides -the low-level commands into commands that manipulate objects (in -the repository, index, and working tree), commands that interrogate and -compare objects, and commands that move objects and references between -repositories. - - -Manipulation commands -~~~~~~~~~~~~~~~~~~~~~ - -include::cmds-plumbingmanipulators.txt[] - - -Interrogation commands -~~~~~~~~~~~~~~~~~~~~~~ - -include::cmds-plumbinginterrogators.txt[] - -In general, the interrogate commands do not touch the files in -the working tree. - - -Synching repositories -~~~~~~~~~~~~~~~~~~~~~ - -include::cmds-synchingrepositories.txt[] - -The following are helper commands used by the above; end users -typically do not use them directly. - -include::cmds-synchelpers.txt[] - - -Internal helper commands -~~~~~~~~~~~~~~~~~~~~~~~~ - -These are internal helper commands used by other commands; end -users typically do not use them directly. - -include::cmds-purehelpers.txt[] - - -Configuration Mechanism ------------------------ - -Git uses a simple text format to store customizations that are per -repository and are per user. Such a configuration file may look -like this: - ------------- -# -# A '#' or ';' character indicates a comment. -# - -; core variables -[core] - ; Don't trust file modes - filemode = false - -; user identity -[user] - name = "Junio C Hamano" - email = "gitster@pobox.com" - ------------- - -Various commands read from the configuration file and adjust -their operation accordingly. See linkgit:git-config[1] for a -list and more details about the configuration mechanism. - - -Identifier Terminology ----------------------- -<object>:: - Indicates the object name for any type of object. - -<blob>:: - Indicates a blob object name. - -<tree>:: - Indicates a tree object name. - -<commit>:: - Indicates a commit object name. - -<tree-ish>:: - Indicates a tree, commit or tag object name. A - command that takes a <tree-ish> argument ultimately wants to - operate on a <tree> object but automatically dereferences - <commit> and <tag> objects that point at a <tree>. - -<commit-ish>:: - Indicates a commit or tag object name. A - command that takes a <commit-ish> argument ultimately wants to - operate on a <commit> object but automatically dereferences - <tag> objects that point at a <commit>. - -<type>:: - Indicates that an object type is required. - Currently one of: `blob`, `tree`, `commit`, or `tag`. - -<file>:: - Indicates a filename - almost always relative to the - root of the tree structure `GIT_INDEX_FILE` describes. - -Symbolic Identifiers --------------------- -Any Git command accepting any <object> can also use the following -symbolic notation: - -HEAD:: - indicates the head of the current branch. - -<tag>:: - a valid tag 'name' - (i.e. a `refs/tags/<tag>` reference). - -<head>:: - a valid head 'name' - (i.e. a `refs/heads/<head>` reference). - -For a more complete list of ways to spell object names, see -"SPECIFYING REVISIONS" section in linkgit:gitrevisions[7]. - - -File/Directory Structure ------------------------- - -Please see the linkgit:gitrepository-layout[5] document. - -Read linkgit:githooks[5] for more details about each hook. - -Higher level SCMs may provide and manage additional information in the -`$GIT_DIR`. - - -Terminology ------------ -Please see linkgit:gitglossary[7]. - - -Environment Variables ---------------------- -Various Git commands use the following environment variables: - -The Git Repository -~~~~~~~~~~~~~~~~~~ -These environment variables apply to 'all' core Git commands. Nb: it -is worth noting that they may be used/overridden by SCMS sitting above -Git so take care if using a foreign front-end. - -`GIT_INDEX_FILE`:: - This environment allows the specification of an alternate - index file. If not specified, the default of `$GIT_DIR/index` - is used. - -`GIT_INDEX_VERSION`:: - This environment variable allows the specification of an index - version for new repositories. It won't affect existing index - files. By default index file version 2 or 3 is used. See - linkgit:git-update-index[1] for more information. - -`GIT_OBJECT_DIRECTORY`:: - If the object storage directory is specified via this - environment variable then the sha1 directories are created - underneath - otherwise the default `$GIT_DIR/objects` - directory is used. - -`GIT_ALTERNATE_OBJECT_DIRECTORIES`:: - Due to the immutable nature of Git objects, old objects can be - archived into shared, read-only directories. This variable - specifies a ":" separated (on Windows ";" separated) list - of Git object directories which can be used to search for Git - objects. New objects will not be written to these directories. -+ -Entries that begin with `"` (double-quote) will be interpreted -as C-style quoted paths, removing leading and trailing -double-quotes and respecting backslash escapes. E.g., the value -`"path-with-\"-and-:-in-it":vanilla-path` has two paths: -`path-with-"-and-:-in-it` and `vanilla-path`. - -`GIT_DIR`:: - If the `GIT_DIR` environment variable is set then it - specifies a path to use instead of the default `.git` - for the base of the repository. - The `--git-dir` command-line option also sets this value. - -`GIT_WORK_TREE`:: - Set the path to the root of the working tree. - This can also be controlled by the `--work-tree` command-line - option and the core.worktree configuration variable. - -`GIT_NAMESPACE`:: - Set the Git namespace; see linkgit:gitnamespaces[7] for details. - The `--namespace` command-line option also sets this value. - -`GIT_CEILING_DIRECTORIES`:: - This should be a colon-separated list of absolute paths. If - set, it is a list of directories that Git should not chdir up - into while looking for a repository directory (useful for - excluding slow-loading network directories). It will not - exclude the current working directory or a GIT_DIR set on the - command line or in the environment. Normally, Git has to read - the entries in this list and resolve any symlink that - might be present in order to compare them with the current - directory. However, if even this access is slow, you - can add an empty entry to the list to tell Git that the - subsequent entries are not symlinks and needn't be resolved; - e.g., - `GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink`. - -`GIT_DISCOVERY_ACROSS_FILESYSTEM`:: - When run in a directory that does not have ".git" repository - directory, Git tries to find such a directory in the parent - directories to find the top of the working tree, but by default it - does not cross filesystem boundaries. This environment variable - can be set to true to tell Git not to stop at filesystem - boundaries. Like `GIT_CEILING_DIRECTORIES`, this will not affect - an explicit repository directory set via `GIT_DIR` or on the - command line. - -`GIT_COMMON_DIR`:: - If this variable is set to a path, non-worktree files that are - normally in $GIT_DIR will be taken from this path - instead. Worktree-specific files such as HEAD or index are - taken from $GIT_DIR. See linkgit:gitrepository-layout[5] and - linkgit:git-worktree[1] for - details. This variable has lower precedence than other path - variables such as GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY... - -Git Commits -~~~~~~~~~~~ -`GIT_AUTHOR_NAME`:: -`GIT_AUTHOR_EMAIL`:: -`GIT_AUTHOR_DATE`:: -`GIT_COMMITTER_NAME`:: -`GIT_COMMITTER_EMAIL`:: -`GIT_COMMITTER_DATE`:: -'EMAIL':: - see linkgit:git-commit-tree[1] - -Git Diffs -~~~~~~~~~ -`GIT_DIFF_OPTS`:: - Only valid setting is "--unified=??" or "-u??" to set the - number of context lines shown when a unified diff is created. - This takes precedence over any "-U" or "--unified" option - value passed on the Git diff command line. - -`GIT_EXTERNAL_DIFF`:: - When the environment variable `GIT_EXTERNAL_DIFF` is set, the - program named by it is called, instead of the diff invocation - described above. For a path that is added, removed, or modified, - `GIT_EXTERNAL_DIFF` is called with 7 parameters: - - path old-file old-hex old-mode new-file new-hex new-mode -+ -where: - - <old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the - contents of <old|new>, - <old|new>-hex:: are the 40-hexdigit SHA-1 hashes, - <old|new>-mode:: are the octal representation of the file modes. -+ -The file parameters can point at the user's working file -(e.g. `new-file` in "git-diff-files"), `/dev/null` (e.g. `old-file` -when a new file is added), or a temporary file (e.g. `old-file` in the -index). `GIT_EXTERNAL_DIFF` should not worry about unlinking the -temporary file --- it is removed when `GIT_EXTERNAL_DIFF` exits. -+ -For a path that is unmerged, `GIT_EXTERNAL_DIFF` is called with 1 -parameter, <path>. -+ -For each path `GIT_EXTERNAL_DIFF` is called, two environment variables, -`GIT_DIFF_PATH_COUNTER` and `GIT_DIFF_PATH_TOTAL` are set. - -`GIT_DIFF_PATH_COUNTER`:: - A 1-based counter incremented by one for every path. - -`GIT_DIFF_PATH_TOTAL`:: - The total number of paths. - -other -~~~~~ -`GIT_MERGE_VERBOSITY`:: - A number controlling the amount of output shown by - the recursive merge strategy. Overrides merge.verbosity. - See linkgit:git-merge[1] - -`GIT_PAGER`:: - This environment variable overrides `$PAGER`. If it is set - to an empty string or to the value "cat", Git will not launch - a pager. See also the `core.pager` option in - linkgit:git-config[1]. - -`GIT_EDITOR`:: - This environment variable overrides `$EDITOR` and `$VISUAL`. - It is used by several Git commands when, on interactive mode, - an editor is to be launched. See also linkgit:git-var[1] - and the `core.editor` option in linkgit:git-config[1]. - -`GIT_SSH`:: -`GIT_SSH_COMMAND`:: - If either of these environment variables is set then 'git fetch' - and 'git push' will use the specified command instead of 'ssh' - when they need to connect to a remote system. - The command-line parameters passed to the configured command are - determined by the ssh variant. See `ssh.variant` option in - linkgit:git-config[1] for details. -+ -`$GIT_SSH_COMMAND` takes precedence over `$GIT_SSH`, and is interpreted -by the shell, which allows additional arguments to be included. -`$GIT_SSH` on the other hand must be just the path to a program -(which can be a wrapper shell script, if additional arguments are -needed). -+ -Usually it is easier to configure any desired options through your -personal `.ssh/config` file. Please consult your ssh documentation -for further details. - -`GIT_SSH_VARIANT`:: - If this environment variable is set, it overrides Git's autodetection - whether `GIT_SSH`/`GIT_SSH_COMMAND`/`core.sshCommand` refer to OpenSSH, - plink or tortoiseplink. This variable overrides the config setting - `ssh.variant` that serves the same purpose. - -`GIT_ASKPASS`:: - If this environment variable is set, then Git commands which need to - acquire passwords or passphrases (e.g. for HTTP or IMAP authentication) - will call this program with a suitable prompt as command-line argument - and read the password from its STDOUT. See also the `core.askPass` - option in linkgit:git-config[1]. - -`GIT_TERMINAL_PROMPT`:: - If this environment variable is set to `0`, git will not prompt - on the terminal (e.g., when asking for HTTP authentication). - -`GIT_CONFIG_NOSYSTEM`:: - Whether to skip reading settings from the system-wide - `$(prefix)/etc/gitconfig` file. This environment variable can - be used along with `$HOME` and `$XDG_CONFIG_HOME` to create a - predictable environment for a picky script, or you can set it - temporarily to avoid using a buggy `/etc/gitconfig` file while - waiting for someone with sufficient permissions to fix it. - -`GIT_FLUSH`:: - If this environment variable is set to "1", then commands such - as 'git blame' (in incremental mode), 'git rev-list', 'git log', - 'git check-attr' and 'git check-ignore' will - force a flush of the output stream after each record have been - flushed. If this - variable is set to "0", the output of these commands will be done - using completely buffered I/O. If this environment variable is - not set, Git will choose buffered or record-oriented flushing - based on whether stdout appears to be redirected to a file or not. - -`GIT_TRACE`:: - Enables general trace messages, e.g. alias expansion, built-in - command execution and external command execution. -+ -If this variable is set to "1", "2" or "true" (comparison -is case insensitive), trace messages will be printed to -stderr. -+ -If the variable is set to an integer value greater than 2 -and lower than 10 (strictly) then Git will interpret this -value as an open file descriptor and will try to write the -trace messages into this file descriptor. -+ -Alternatively, if the variable is set to an absolute path -(starting with a '/' character), Git will interpret this -as a file path and will try to append the trace messages -to it. -+ -Unsetting the variable, or setting it to empty, "0" or -"false" (case insensitive) disables trace messages. - -`GIT_TRACE_FSMONITOR`:: - Enables trace messages for the filesystem monitor extension. - See `GIT_TRACE` for available trace output options. - -`GIT_TRACE_PACK_ACCESS`:: - Enables trace messages for all accesses to any packs. For each - access, the pack file name and an offset in the pack is - recorded. This may be helpful for troubleshooting some - pack-related performance problems. - See `GIT_TRACE` for available trace output options. - -`GIT_TRACE_PACKET`:: - Enables trace messages for all packets coming in or out of a - given program. This can help with debugging object negotiation - or other protocol issues. Tracing is turned off at a packet - starting with "PACK" (but see `GIT_TRACE_PACKFILE` below). - See `GIT_TRACE` for available trace output options. - -`GIT_TRACE_PACKFILE`:: - Enables tracing of packfiles sent or received by a - given program. Unlike other trace output, this trace is - verbatim: no headers, and no quoting of binary data. You almost - certainly want to direct into a file (e.g., - `GIT_TRACE_PACKFILE=/tmp/my.pack`) rather than displaying it on - the terminal or mixing it with other trace output. -+ -Note that this is currently only implemented for the client side -of clones and fetches. - -`GIT_TRACE_PERFORMANCE`:: - Enables performance related trace messages, e.g. total execution - time of each Git command. - See `GIT_TRACE` for available trace output options. - -`GIT_TRACE_SETUP`:: - Enables trace messages printing the .git, working tree and current - working directory after Git has completed its setup phase. - See `GIT_TRACE` for available trace output options. - -`GIT_TRACE_SHALLOW`:: - Enables trace messages that can help debugging fetching / - 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_TRACE_CURL_NO_DATA`:: - When a curl trace is enabled (see `GIT_TRACE_CURL` above), do not dump - data (that is, only dump info lines and headers). - -`GIT_TRACE2`:: - Enables more detailed trace messages from the "trace2" library. - Output from `GIT_TRACE2` is a simple text-based format for human - readability. -+ -If this variable is set to "1", "2" or "true" (comparison -is case insensitive), trace messages will be printed to -stderr. -+ -If the variable is set to an integer value greater than 2 -and lower than 10 (strictly) then Git will interpret this -value as an open file descriptor and will try to write the -trace messages into this file descriptor. -+ -Alternatively, if the variable is set to an absolute path -(starting with a '/' character), Git will interpret this -as a file path and will try to append the trace messages -to it. If the path already exists and is a directory, the -trace messages will be written to files (one per process) -in that directory, named according to the last component -of the SID and an optional counter (to avoid filename -collisions). -+ -In addition, if the variable is set to -`af_unix:[<socket_type>:]<absolute-pathname>`, Git will try -to open the path as a Unix Domain Socket. The socket type -can be either `stream` or `dgram`. -+ -Unsetting the variable, or setting it to empty, "0" or -"false" (case insensitive) disables trace messages. -+ -See link:technical/api-trace2.html[Trace2 documentation] -for full details. - - -`GIT_TRACE2_EVENT`:: - This setting writes a JSON-based format that is suited for machine - interpretation. - See `GIT_TRACE2` for available trace output options and - link:technical/api-trace2.html[Trace2 documentation] for full details. - -`GIT_TRACE2_PERF`:: - In addition to the text-based messages available in `GIT_TRACE2`, this - setting writes a column-based format for understanding nesting - regions. - See `GIT_TRACE2` for available trace output options and - link:technical/api-trace2.html[Trace2 documentation] for full details. - -`GIT_REDACT_COOKIES`:: - This can be set to a comma-separated list of strings. When a curl trace - is enabled (see `GIT_TRACE_CURL` above), whenever a "Cookies:" header - sent by the client is dumped, values of cookies whose key is in that - list (case-sensitive) are redacted. - -`GIT_LITERAL_PATHSPECS`:: - Setting this variable to `1` will cause Git to treat all - pathspecs literally, rather than as glob patterns. For example, - running `GIT_LITERAL_PATHSPECS=1 git log -- '*.c'` will search - for commits that touch the path `*.c`, not any paths that the - glob `*.c` matches. You might want this if you are feeding - literal paths to Git (e.g., paths previously given to you by - `git ls-tree`, `--raw` diff output, etc). - -`GIT_GLOB_PATHSPECS`:: - Setting this variable to `1` will cause Git to treat all - pathspecs as glob patterns (aka "glob" magic). - -`GIT_NOGLOB_PATHSPECS`:: - Setting this variable to `1` will cause Git to treat all - pathspecs as literal (aka "literal" magic). - -`GIT_ICASE_PATHSPECS`:: - Setting this variable to `1` will cause Git to treat all - pathspecs as case-insensitive. - -`GIT_REFLOG_ACTION`:: - When a ref is updated, reflog entries are created to keep - track of the reason why the ref was updated (which is - typically the name of the high-level command that updated - the ref), in addition to the old and new values of the ref. - A scripted Porcelain command can use set_reflog_action - helper function in `git-sh-setup` to set its name to this - variable when it is invoked as the top level command by the - end user, to be recorded in the body of the reflog. - -`GIT_REF_PARANOIA`:: - If set to `1`, include broken or badly named refs when iterating - over lists of refs. In a normal, non-corrupted repository, this - does nothing. However, enabling it may help git to detect and - abort some operations in the presence of broken refs. Git sets - this variable automatically when performing destructive - operations like linkgit:git-prune[1]. You should not need to set - it yourself unless you want to be paranoid about making sure - an operation has touched every ref (e.g., because you are - cloning a repository to make a backup). - -`GIT_ALLOW_PROTOCOL`:: - If set to a colon-separated list of protocols, behave as if - `protocol.allow` is set to `never`, and each of the listed - protocols has `protocol.<name>.allow` set to `always` - (overriding any existing configuration). In other words, any - protocol not mentioned will be disallowed (i.e., this is a - whitelist, not a blacklist). See the description of - `protocol.allow` in linkgit:git-config[1] for more details. - -`GIT_PROTOCOL_FROM_USER`:: - Set to 0 to prevent protocols used by fetch/push/clone which are - configured to the `user` state. This is useful to restrict recursive - submodule initialization from an untrusted repository or for programs - which feed potentially-untrusted URLS to git commands. See - linkgit:git-config[1] for more details. - -`GIT_PROTOCOL`:: - For internal use only. Used in handshaking the wire protocol. - Contains a colon ':' separated list of keys with optional values - 'key[=value]'. Presence of unknown keys and values must be - ignored. - -`GIT_OPTIONAL_LOCKS`:: - If set to `0`, Git will complete any requested operation without - performing any optional sub-operations that require taking a lock. - For example, this will prevent `git status` from refreshing the - index as a side effect. This is useful for processes running in - the background which do not want to cause lock contention with - other operations on the repository. Defaults to `1`. - -`GIT_REDIRECT_STDIN`:: -`GIT_REDIRECT_STDOUT`:: -`GIT_REDIRECT_STDERR`:: - Windows-only: allow redirecting the standard input/output/error - handles to paths specified by the environment variables. This is - particularly useful in multi-threaded applications where the - canonical way to pass standard handles via `CreateProcess()` is - not an option because it would require the handles to be marked - inheritable (and consequently *every* spawned process would - inherit them, possibly blocking regular Git operations). The - primary intended use case is to use named pipes for communication - (e.g. `\\.\pipe\my-git-stdin-123`). -+ -Two special values are supported: `off` will simply close the -corresponding standard handle, and if `GIT_REDIRECT_STDERR` is -`2>&1`, standard error will be redirected to the same handle as -standard output. - -`GIT_PRINT_SHA1_ELLIPSIS` (deprecated):: - If set to `yes`, print an ellipsis following an - (abbreviated) SHA-1 value. This affects indications of - detached HEADs (linkgit:git-checkout[1]) and the raw - diff output (linkgit:git-diff[1]). Printing an - ellipsis in the cases mentioned is no longer considered - adequate and support for it is likely to be removed in the - foreseeable future (along with the variable). - -Discussion[[Discussion]] ------------------------- - -More detail on the following is available from the -link:user-manual.html#git-concepts[Git concepts chapter of the -user-manual] and linkgit:gitcore-tutorial[7]. - -A Git project normally consists of a working directory with a ".git" -subdirectory at the top level. The .git directory contains, among other -things, a compressed object database representing the complete history -of the project, an "index" file which links that history to the current -contents of the working tree, and named pointers into that history such -as tags and branch heads. - -The object database contains objects of three main types: blobs, which -hold file data; trees, which point to blobs and other trees to build up -directory hierarchies; and commits, which each reference a single tree -and some number of parent commits. - -The commit, equivalent to what other systems call a "changeset" or -"version", represents a step in the project's history, and each parent -represents an immediately preceding step. Commits with more than one -parent represent merges of independent lines of development. - -All objects are named by the SHA-1 hash of their contents, normally -written as a string of 40 hex digits. Such names are globally unique. -The entire history leading up to a commit can be vouched for by signing -just that commit. A fourth object type, the tag, is provided for this -purpose. - -When first created, objects are stored in individual files, but for -efficiency may later be compressed together into "pack files". - -Named pointers called refs mark interesting points in history. A ref -may contain the SHA-1 name of an object or the name of another ref. Refs -with names beginning `ref/head/` contain the SHA-1 name of the most -recent commit (or "head") of a branch under development. SHA-1 names of -tags of interest are stored under `ref/tags/`. A special ref named -`HEAD` contains the name of the currently checked-out branch. - -The index file is initialized with a list of all paths and, for each -path, a blob object and a set of attributes. The blob object represents -the contents of the file as of the head of the current branch. The -attributes (last modified time, size, etc.) are taken from the -corresponding file in the working tree. Subsequent changes to the -working tree can be found by comparing these attributes. The index may -be updated with new content, and new commits may be created from the -content stored in the index. - -The index is also capable of storing multiple entries (called "stages") -for a given pathname. These stages are used to hold the various -unmerged version of a file when a merge is in progress. - -FURTHER DOCUMENTATION ---------------------- - -See the references in the "description" section to get started -using Git. The following is probably more detail than necessary -for a first-time user. - -The link:user-manual.html#git-concepts[Git concepts chapter of the -user-manual] and linkgit:gitcore-tutorial[7] both provide -introductions to the underlying Git architecture. - -See linkgit:gitworkflows[7] for an overview of recommended workflows. - -See also the link:howto-index.html[howto] documents for some useful -examples. - -The internals are documented in the -link:technical/api-index.html[Git API documentation]. - -Users migrating from CVS may also want to -read linkgit:gitcvs-migration[7]. - - -Authors -------- -Git was started by Linus Torvalds, and is currently maintained by Junio -C Hamano. Numerous contributions have come from the Git mailing list -<git@vger.kernel.org>. http://www.openhub.net/p/git/contributors/summary -gives you a more complete list of contributors. - -If you have a clone of git.git itself, the -output of linkgit:git-shortlog[1] and linkgit:git-blame[1] can show you -the authors for specific parts of the project. - -Reporting Bugs --------------- - -Report bugs to the Git mailing list <git@vger.kernel.org> where the -development and maintenance is primarily done. You do not have to be -subscribed to the list to send a message there. See the list archive -at https://public-inbox.org/git for previous bug reports and other -discussions. - -Issues which are security relevant should be disclosed privately to -the Git Security mailing list <git-security@googlegroups.com>. - -SEE ALSO --------- -linkgit:gittutorial[7], linkgit:gittutorial-2[7], -linkgit:giteveryday[7], linkgit:gitcvs-migration[7], -linkgit:gitglossary[7], linkgit:gitcore-tutorial[7], -linkgit:gitcli[7], link:user-manual.html[The Git User's Manual], -linkgit:gitworkflows[7] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitattributes.txt b/third_party/git/Documentation/gitattributes.txt deleted file mode 100644 index fb1d188d44..0000000000 --- a/third_party/git/Documentation/gitattributes.txt +++ /dev/null @@ -1,1294 +0,0 @@ -gitattributes(5) -================ - -NAME ----- -gitattributes - Defining attributes per path - -SYNOPSIS --------- -$GIT_DIR/info/attributes, .gitattributes - - -DESCRIPTION ------------ - -A `gitattributes` file is a simple text file that gives -`attributes` to pathnames. - -Each line in `gitattributes` file is of form: - - pattern attr1 attr2 ... - -That is, a pattern followed by an attributes list, -separated by whitespaces. Leading and trailing whitespaces are -ignored. Lines that begin with '#' are ignored. Patterns -that begin with a double quote are quoted in C style. -When the pattern matches the path in question, the attributes -listed on the line are given to the path. - -Each attribute can be in one of these states for a given path: - -Set:: - - The path has the attribute with special value "true"; - this is specified by listing only the name of the - attribute in the attribute list. - -Unset:: - - The path has the attribute with special value "false"; - this is specified by listing the name of the attribute - prefixed with a dash `-` in the attribute list. - -Set to a value:: - - The path has the attribute with specified string value; - this is specified by listing the name of the attribute - followed by an equal sign `=` and its value in the - attribute list. - -Unspecified:: - - No pattern matches the path, and nothing says if - the path has or does not have the attribute, the - attribute for the path is said to be Unspecified. - -When more than one pattern matches the path, a later line -overrides an earlier line. This overriding is done per -attribute. - -The rules by which the pattern matches paths are the same as in -`.gitignore` files (see linkgit:gitignore[5]), with a few exceptions: - - - negative patterns are forbidden - - - patterns that match a directory do not recursively match paths - inside that directory (so using the trailing-slash `path/` syntax is - pointless in an attributes file; use `path/**` instead) - -When deciding what attributes are assigned to a path, Git -consults `$GIT_DIR/info/attributes` file (which has the highest -precedence), `.gitattributes` file in the same directory as the -path in question, and its parent directories up to the toplevel of the -work tree (the further the directory that contains `.gitattributes` -is from the path in question, the lower its precedence). Finally -global and system-wide files are considered (they have the lowest -precedence). - -When the `.gitattributes` file is missing from the work tree, the -path in the index is used as a fall-back. During checkout process, -`.gitattributes` in the index is used and then the file in the -working tree is used as a fall-back. - -If you wish to affect only a single repository (i.e., to assign -attributes to files that are particular to -one user's workflow for that repository), then -attributes should be placed in the `$GIT_DIR/info/attributes` file. -Attributes which should be version-controlled and distributed to other -repositories (i.e., attributes of interest to all users) should go into -`.gitattributes` files. Attributes that should affect all repositories -for a single user should be placed in a file specified by the -`core.attributesFile` configuration option (see linkgit:git-config[1]). -Its default value is $XDG_CONFIG_HOME/git/attributes. If $XDG_CONFIG_HOME -is either not set or empty, $HOME/.config/git/attributes is used instead. -Attributes for all users on a system should be placed in the -`$(prefix)/etc/gitattributes` file. - -Sometimes you would need to override a setting of an attribute -for a path to `Unspecified` state. This can be done by listing -the name of the attribute prefixed with an exclamation point `!`. - - -EFFECTS -------- - -Certain operations by Git can be influenced by assigning -particular attributes to a path. Currently, the following -operations are attributes-aware. - -Checking-out and checking-in -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -These attributes affect how the contents stored in the -repository are copied to the working tree files when commands -such as 'git switch', 'git checkout' and 'git merge' run. -They also affect how -Git stores the contents you prepare in the working tree in the -repository upon 'git add' and 'git commit'. - -`text` -^^^^^^ - -This attribute enables and controls end-of-line normalization. When a -text file is normalized, its line endings are converted to LF in the -repository. To control what line ending style is used in the working -directory, use the `eol` attribute for a single file and the -`core.eol` configuration variable for all text files. -Note that setting `core.autocrlf` to `true` or `input` overrides -`core.eol` (see the definitions of those options in -linkgit:git-config[1]). - -Set:: - - Setting the `text` attribute on a path enables end-of-line - normalization and marks the path as a text file. End-of-line - conversion takes place without guessing the content type. - -Unset:: - - Unsetting the `text` attribute on a path tells Git not to - attempt any end-of-line conversion upon checkin or checkout. - -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 committed with CRLF, no conversion is done. - -Unspecified:: - - If the `text` attribute is unspecified, Git uses the - `core.autocrlf` configuration variable to determine if the - file should be converted. - -Any other value causes Git to act as if `text` has been left -unspecified. - -`eol` -^^^^^ - -This attribute sets a specific line-ending style to be used in the -working directory. It enables end-of-line conversion without any -content checks, effectively setting the `text` attribute. Note that -setting this attribute on paths which are in the index with CRLF line -endings may make the paths to be considered dirty. Adding the path to -the index again will normalize the line endings in the index. - -Set to string value "crlf":: - - This setting forces Git to normalize line endings for this - file on checkin and convert them to CRLF when the file is - checked out. - -Set to string value "lf":: - - This setting forces Git to normalize line endings to LF on - checkin and prevents conversion to CRLF when the file is - checked out. - -Backwards compatibility with `crlf` attribute -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -For backwards compatibility, the `crlf` attribute is interpreted as -follows: - ------------------------- -crlf text --crlf -text -crlf=input eol=lf ------------------------- - -End-of-line conversion -^^^^^^^^^^^^^^^^^^^^^^ - -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. - -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. - ------------------------- -[core] - autocrlf = true ------------------------- - -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 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 ------------------------- - -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. - -From a clean working directory: - -------------------------------------------------- -$ echo "* text=auto" >.gitattributes -$ git add --renormalize . -$ git status # Show files that will be normalized -$ git commit -m "Introduce end-of-line normalization" -------------------------------------------------- - -If any files that should not be normalized show up in 'git status', -unset their `text` attribute before running 'git add -u'. - ------------------------- -manual.pdf -text ------------------------- - -Conversely, text files that Git does not detect can have normalization -enabled manually. - ------------------------- -weirdchars.txt text ------------------------- - -If `core.safecrlf` is set to "true" or "warn", Git verifies if -the conversion is reversible for the current setting of -`core.autocrlf`. For "true", Git rejects irreversible -conversions; for "warn", Git only prints a warning but accepts -an irreversible conversion. The safety triggers to prevent such -a conversion done to the files in the work tree, but there are a -few exceptions. Even though... - -- 'git add' itself does not touch the files in the work tree, the - next checkout would, so the safety triggers; - -- 'git apply' to update a text file with a patch does touch the files - in the work tree, but the operation is about text files and CRLF - conversion is about fixing the line ending inconsistencies, so the - safety does not trigger; - -- 'git diff' itself does not touch the files in the work tree, it is - often run to inspect the changes you intend to next 'git add'. To - catch potential problems early, safety triggers. - - -`working-tree-encoding` -^^^^^^^^^^^^^^^^^^^^^^^ - -Git recognizes files encoded in ASCII or one of its supersets (e.g. -UTF-8, ISO-8859-1, ...) as text files. Files encoded in certain other -encodings (e.g. UTF-16) are interpreted as binary and consequently -built-in Git text processing tools (e.g. 'git diff') as well as most Git -web front ends do not visualize the contents of these files by default. - -In these cases you can tell Git the encoding of a file in the working -directory with the `working-tree-encoding` attribute. If a file with this -attribute is added to Git, then Git reencodes the content from the -specified encoding to UTF-8. Finally, Git stores the UTF-8 encoded -content in its internal data structure (called "the index"). On checkout -the content is reencoded back to the specified encoding. - -Please note that using the `working-tree-encoding` attribute may have a -number of pitfalls: - -- Alternative Git implementations (e.g. JGit or libgit2) and older Git - versions (as of March 2018) do not support the `working-tree-encoding` - attribute. If you decide to use the `working-tree-encoding` attribute - in your repository, then it is strongly recommended to ensure that all - clients working with the repository support it. -+ -For example, Microsoft Visual Studio resources files (`*.rc`) or -PowerShell script files (`*.ps1`) are sometimes encoded in UTF-16. -If you declare `*.ps1` as files as UTF-16 and you add `foo.ps1` with -a `working-tree-encoding` enabled Git client, then `foo.ps1` will be -stored as UTF-8 internally. A client without `working-tree-encoding` -support will checkout `foo.ps1` as UTF-8 encoded file. This will -typically cause trouble for the users of this file. -+ -If a Git client that does not support the `working-tree-encoding` -attribute adds a new file `bar.ps1`, then `bar.ps1` will be -stored "as-is" internally (in this example probably as UTF-16). -A client with `working-tree-encoding` support will interpret the -internal contents as UTF-8 and try to convert it to UTF-16 on checkout. -That operation will fail and cause an error. - -- Reencoding content to non-UTF encodings can cause errors as the - conversion might not be UTF-8 round trip safe. If you suspect your - encoding to not be round trip safe, then add it to - `core.checkRoundtripEncoding` to make Git check the round trip - encoding (see linkgit:git-config[1]). SHIFT-JIS (Japanese character - set) is known to have round trip issues with UTF-8 and is checked by - default. - -- Reencoding content requires resources that might slow down certain - Git operations (e.g 'git checkout' or 'git add'). - -Use the `working-tree-encoding` attribute only if you cannot store a file -in UTF-8 encoding and if you want Git to be able to process the content -as text. - -As an example, use the following attributes if your '*.ps1' files are -UTF-16 encoded with byte order mark (BOM) and you want Git to perform -automatic line ending conversion based on your platform. - ------------------------- -*.ps1 text working-tree-encoding=UTF-16 ------------------------- - -Use the following attributes if your '*.ps1' files are UTF-16 little -endian encoded without BOM and you want Git to use Windows line endings -in the working directory (use `UTF-16LE-BOM` instead of `UTF-16LE` if -you want UTF-16 little endian with BOM). -Please note, it is highly recommended to -explicitly define the line endings with `eol` if the `working-tree-encoding` -attribute is used to avoid ambiguity. - ------------------------- -*.ps1 text working-tree-encoding=UTF-16LE eol=CRLF ------------------------- - -You can get a list of all available encodings on your platform with the -following command: - ------------------------- -iconv --list ------------------------- - -If you do not know the encoding of a file, then you can use the `file` -command to guess the encoding: - ------------------------- -file foo.ps1 ------------------------- - - -`ident` -^^^^^^^ - -When the attribute `ident` is set for a path, Git replaces -`$Id$` in the blob object with `$Id:`, followed by the -40-character hexadecimal blob object name, followed by a dollar -sign `$` upon checkout. Any byte sequence that begins with -`$Id:` and ends with `$` in the worktree file is replaced -with `$Id$` upon check-in. - - -`filter` -^^^^^^^^ - -A `filter` attribute can be set to a string value that names a -filter driver specified in the configuration. - -A filter driver consists of a `clean` command and a `smudge` -command, either of which can be left unspecified. Upon -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. 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. -For this mode of operation, the key phrase here is "more convenient" and -not "turning something unusable into usable". In other words, the intent -is that if someone unsets the filter driver definition, or does not have -the appropriate filter program, the project should still be usable. - -Another use of the content filtering is to store the content that cannot -be directly used in the repository (e.g. a UUID that refers to the true -content stored outside Git, or an encrypted content) and turn it into a -usable form upon checkout (e.g. download the external content, or decrypt -the encrypted content). - -These two filters behave differently, and by default, a filter is taken as -the former, massaging the contents into more convenient shape. A missing -filter driver definition in the config, or a filter driver that exits with -a non-zero status, is not an error but makes the filter a no-op passthru. - -You can declare that a filter turns a content that by itself is unusable -into a usable content by setting the filter.<driver>.required configuration -variable to `true`. - -Note: Whenever the clean filter is changed, the repo should be renormalized: -$ git add --renormalize . - -For example, in .gitattributes, you would assign the `filter` -attribute for paths. - ------------------------- -*.c filter=indent ------------------------- - -Then you would define a "filter.indent.clean" and "filter.indent.smudge" -configuration in your .git/config to specify a pair of commands to -modify the contents of C programs when the source files are checked -in ("clean" is run) and checked out (no change is made because the -command is "cat"). - ------------------------- -[filter "indent"] - clean = indent - smudge = cat ------------------------- - -For best results, `clean` should not alter its output further if it is -run twice ("clean->clean" should be equivalent to "clean"), and -multiple `smudge` commands should not alter `clean`'s output -("smudge->smudge->clean" should be equivalent to "clean"). See the -section on merging below. - -The "indent" filter is well-behaved in this regard: it will not modify -input that is already correctly indented. In this case, the lack of a -smudge filter means that the clean filter _must_ accept its own output -without modifying it. - -If a filter _must_ succeed in order to make the stored contents usable, -you can declare that the filter is `required`, in the configuration: - ------------------------- -[filter "crypt"] - clean = openssl enc ... - smudge = openssl enc -d ... - required ------------------------- - -Sequence "%f" on the filter command line is replaced with the name of -the file the filter is working on. A filter might use this in keyword -substitution. For example: - ------------------------- -[filter "p4"] - clean = git-p4-filter --clean %f - smudge = git-p4-filter --smudge %f ------------------------- - -Note that "%f" is the name of the path that is being worked on. Depending -on the version that is being filtered, the corresponding file on disk may -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 the long-running process protocol -(described in technical/long-running-process-protocol.txt). - -When Git encounters the first file that needs to be cleaned or smudged, -it starts the filter and performs the handshake. In the handshake, the -welcome message sent by Git is "git-filter-client", only version 2 is -suppported, and the supported capabilities are "clean", "smudge", and -"delay". - -Afterwards Git sends a list of "key=value" pairs terminated with -a flush packet. The list will contain at least the filter command -(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. Also note that the "value" of a "key=value" pair -can contain the "=" character whereas the key would never contain -that character. ------------------------- -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. - -Delay -^^^^^ - -If the filter supports the "delay" capability, then Git can send the -flag "can-delay" after the filter command and pathname. This flag -denotes that the filter can delay filtering the current blob (e.g. to -compensate network latencies) by responding with no content but with -the status "delayed" and a flush packet. ------------------------- -packet: git> command=smudge -packet: git> pathname=path/testfile.dat -packet: git> can-delay=1 -packet: git> 0000 -packet: git> CONTENT -packet: git> 0000 -packet: git< status=delayed -packet: git< 0000 ------------------------- - -If the filter supports the "delay" capability then it must support the -"list_available_blobs" command. If Git sends this command, then the -filter is expected to return a list of pathnames representing blobs -that have been delayed earlier and are now available. -The list must be terminated with a flush packet followed -by a "success" status that is also terminated with a flush packet. If -no blobs for the delayed paths are available, yet, then the filter is -expected to block the response until at least one blob becomes -available. The filter can tell Git that it has no more delayed blobs -by sending an empty list. As soon as the filter responds with an empty -list, Git stops asking. All blobs that Git has not received at this -point are considered missing and will result in an error. - ------------------------- -packet: git> command=list_available_blobs -packet: git> 0000 -packet: git< pathname=path/testfile.dat -packet: git< pathname=path/otherfile.dat -packet: git< 0000 -packet: git< status=success -packet: git< 0000 ------------------------- - -After Git received the pathnames, it will request the corresponding -blobs again. These requests contain a pathname and an empty content -section. The filter is expected to respond with the smudged content -in the usual way as explained above. ------------------------- -packet: git> command=smudge -packet: git> pathname=path/testfile.dat -packet: git> 0000 -packet: git> 0000 # empty content! -packet: git< status=success -packet: git< 0000 -packet: git< SMUDGED_CONTENT -packet: git< 0000 -packet: git< 0000 # empty list, keep "status=success" unchanged! ------------------------- - -Example -^^^^^^^ - -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 -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In the check-in codepath, the worktree file is first converted -with `filter` driver (if specified and corresponding driver -defined), then the result is processed with `ident` (if -specified), and then finally with `text` (again, if specified -and applicable). - -In the check-out codepath, the blob content is first converted -with `text`, and then `ident` and fed to `filter`. - - -Merging branches with differing checkin/checkout attributes -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you have added attributes to a file that cause the canonical -repository format for that file to change, such as adding a -clean/smudge filter or text/eol/ident attributes, merging anything -where the attribute is not in place would normally cause merge -conflicts. - -To prevent these unnecessary merge conflicts, Git can be told to run a -virtual check-out and check-in of all three stages of a file when -resolving a three-way merge by setting the `merge.renormalize` -configuration variable. This prevents changes caused by check-in -conversion from causing spurious merge conflicts when a converted file -is merged with an unconverted file. - -As long as a "smudge->clean" results in the same output as a "clean" -even on files that are already smudged, this strategy will -automatically resolve all filter-related conflicts. Filters that do -not act in this way may cause additional merge conflicts that must be -resolved manually. - - -Generating diff text -~~~~~~~~~~~~~~~~~~~~ - -`diff` -^^^^^^ - -The attribute `diff` affects how Git generates diffs for particular -files. It can tell Git whether to generate a textual patch for the path -or to treat the path as a binary file. It can also affect what line is -shown on the hunk header `@@ -k,l +n,m @@` line, tell Git to use an -external command to generate the diff, or ask Git to convert binary -files to a text format before generating the diff. - -Set:: - - A path to which the `diff` attribute is set is treated - as text, even when they contain byte values that - normally never appear in text files, such as NUL. - -Unset:: - - A path to which the `diff` attribute is unset will - generate `Binary files differ` (or a binary patch, if - binary patches are enabled). - -Unspecified:: - - A path to which the `diff` attribute is unspecified - first gets its contents inspected, and if it looks like - text and is smaller than core.bigFileThreshold, it is treated - as text. Otherwise it would generate `Binary files differ`. - -String:: - - Diff is shown using the specified diff driver. Each driver may - specify one or more options, as described in the following - section. The options for the diff driver "foo" are defined - by the configuration variables in the "diff.foo" section of the - Git config file. - - -Defining an external diff driver -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The definition of a diff driver is done in `gitconfig`, not -`gitattributes` file, so strictly speaking this manual page is a -wrong place to talk about it. However... - -To define an external diff driver `jcdiff`, add a section to your -`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: - ----------------------------------------------------------------- -[diff "jcdiff"] - command = j-c-diff ----------------------------------------------------------------- - -When Git needs to show you a diff for the path with `diff` -attribute set to `jcdiff`, it calls the command you specified -with the above configuration, i.e. `j-c-diff`, with 7 -parameters, just like `GIT_EXTERNAL_DIFF` program is called. -See linkgit:git[1] for details. - - -Defining a custom hunk-header -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Each group of changes (called a "hunk") in the textual diff output -is prefixed with a line of the form: - - @@ -k,l +n,m @@ TEXT - -This is called a 'hunk header'. The "TEXT" portion is by default a line -that begins with an alphabet, an underscore or a dollar sign; this -matches what GNU 'diff -p' output uses. This default selection however -is not suited for some contents, and you can use a customized pattern -to make a selection. - -First, in .gitattributes, you would assign the `diff` attribute -for paths. - ------------------------- -*.tex diff=tex ------------------------- - -Then, you would define a "diff.tex.xfuncname" configuration to -specify a regular expression that matches a line that you would -want to appear as the hunk header "TEXT". Add a section to your -`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: - ------------------------- -[diff "tex"] - xfuncname = "^(\\\\(sub)*section\\{.*)$" ------------------------- - -Note. A single level of backslashes are eaten by the -configuration file parser, so you would need to double the -backslashes; the pattern above picks a line that begins with a -backslash, and zero or more occurrences of `sub` followed by -`section` followed by open brace, to the end of line. - -There are a few built-in patterns to make this easier, and `tex` -is one of them, so you do not have to write the above in your -configuration file (you still need to enable this with the -attribute mechanism, via `.gitattributes`). The following built in -patterns are available: - -- `ada` suitable for source code in the Ada language. - -- `bibtex` suitable for files with BibTeX coded references. - -- `cpp` suitable for source code in the C and C++ languages. - -- `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. - -- `golang` suitable for source code in the Go language. - -- `html` suitable for HTML/XHTML documents. - -- `java` suitable for source code in the Java language. - -- `matlab` suitable for source code in the MATLAB and Octave languages. - -- `objc` suitable for source code in the Objective-C language. - -- `pascal` suitable for source code in the Pascal/Delphi language. - -- `perl` suitable for source code in the Perl language. - -- `php` suitable for source code in the PHP language. - -- `python` suitable for source code in the Python language. - -- `ruby` suitable for source code in the Ruby language. - -- `rust` suitable for source code in the Rust language. - -- `tex` suitable for source code for LaTeX documents. - - -Customizing word diff -^^^^^^^^^^^^^^^^^^^^^ - -You can customize the rules that `git diff --word-diff` uses to -split words in a line, by specifying an appropriate regular expression -in the "diff.*.wordRegex" configuration variable. For example, in TeX -a backslash followed by a sequence of letters forms a command, but -several such commands can be run together without intervening -whitespace. To separate them, use a regular expression in your -`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: - ------------------------- -[diff "tex"] - wordRegex = "\\\\[a-zA-Z]+|[{}]|\\\\.|[^\\{}[:space:]]+" ------------------------- - -A built-in pattern is provided for all languages listed in the -previous section. - - -Performing text diffs of binary files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Sometimes it is desirable to see the diff of a text-converted -version of some binary files. For example, a word processor -document can be converted to an ASCII text representation, and -the diff of the text shown. Even though this conversion loses -some information, the resulting diff is useful for human -viewing (but cannot be applied directly). - -The `textconv` config option is used to define a program for -performing such a conversion. The program should take a single -argument, the name of a file to convert, and produce the -resulting text on stdout. - -For example, to show the diff of the exif information of a -file instead of the binary information (assuming you have the -exif tool installed), add the following section to your -`$GIT_DIR/config` file (or `$HOME/.gitconfig` file): - ------------------------- -[diff "jpg"] - textconv = exif ------------------------- - -NOTE: The text conversion is generally a one-way conversion; -in this example, we lose the actual image contents and focus -just on the text data. This means that diffs generated by -textconv are _not_ suitable for applying. For this reason, -only `git diff` and the `git log` family of commands (i.e., -log, whatchanged, show) will perform text conversion. `git -format-patch` will never generate this output. If you want to -send somebody a text-converted diff of a binary file (e.g., -because it quickly conveys the changes you have made), you -should generate it separately and send it as a comment _in -addition to_ the usual binary diff that you might send. - -Because text conversion can be slow, especially when doing a -large number of them with `git log -p`, Git provides a mechanism -to cache the output and use it in future diffs. To enable -caching, set the "cachetextconv" variable in your diff driver's -config. For example: - ------------------------- -[diff "jpg"] - textconv = exif - cachetextconv = true ------------------------- - -This will cache the result of running "exif" on each blob -indefinitely. If you change the textconv config variable for a -diff driver, Git will automatically invalidate the cache entries -and re-run the textconv filter. If you want to invalidate the -cache manually (e.g., because your version of "exif" was updated -and now produces better output), you can remove the cache -manually with `git update-ref -d refs/notes/textconv/jpg` (where -"jpg" is the name of the diff driver, as in the example above). - -Choosing textconv versus external diff -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you want to show differences between binary or specially-formatted -blobs in your repository, you can choose to use either an external diff -command, or to use textconv to convert them to a diff-able text format. -Which method you choose depends on your exact situation. - -The advantage of using an external diff command is flexibility. You are -not bound to find line-oriented changes, nor is it necessary for the -output to resemble unified diff. You are free to locate and report -changes in the most appropriate way for your data format. - -A textconv, by comparison, is much more limiting. You provide a -transformation of the data into a line-oriented text format, and Git -uses its regular diff tools to generate the output. There are several -advantages to choosing this method: - -1. Ease of use. It is often much simpler to write a binary to text - transformation than it is to perform your own diff. In many cases, - existing programs can be used as textconv filters (e.g., exif, - odt2txt). - -2. Git diff features. By performing only the transformation step - yourself, you can still utilize many of Git's diff features, - including colorization, word-diff, and combined diffs for merges. - -3. Caching. Textconv caching can speed up repeated diffs, such as those - you might trigger by running `git log -p`. - - -Marking files as binary -^^^^^^^^^^^^^^^^^^^^^^^ - -Git usually guesses correctly whether a blob contains text or binary -data by examining the beginning of the contents. However, sometimes you -may want to override its decision, either because a blob contains binary -data later in the file, or because the content, while technically -composed of text characters, is opaque to a human reader. For example, -many postscript files contain only ASCII characters, but produce noisy -and meaningless diffs. - -The simplest way to mark a file as binary is to unset the diff -attribute in the `.gitattributes` file: - ------------------------- -*.ps -diff ------------------------- - -This will cause Git to generate `Binary files differ` (or a binary -patch, if binary patches are enabled) instead of a regular diff. - -However, one may also want to specify other diff driver attributes. For -example, you might want to use `textconv` to convert postscript files to -an ASCII representation for human viewing, but otherwise treat them as -binary files. You cannot specify both `-diff` and `diff=ps` attributes. -The solution is to use the `diff.*.binary` config option: - ------------------------- -[diff "ps"] - textconv = ps2ascii - binary = true ------------------------- - -Performing a three-way merge -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -`merge` -^^^^^^^ - -The attribute `merge` affects how three versions of a file are -merged when a file-level merge is necessary during `git merge`, -and other commands such as `git revert` and `git cherry-pick`. - -Set:: - - Built-in 3-way merge driver is used to merge the - contents in a way similar to 'merge' command of `RCS` - suite. This is suitable for ordinary text files. - -Unset:: - - Take the version from the current branch as the - tentative merge result, and declare that the merge has - conflicts. This is suitable for binary files that do - not have a well-defined merge semantics. - -Unspecified:: - - By default, this uses the same built-in 3-way merge - driver as is the case when the `merge` attribute is set. - However, the `merge.default` configuration variable can name - different merge driver to be used with paths for which the - `merge` attribute is unspecified. - -String:: - - 3-way merge is performed using the specified custom - merge driver. The built-in 3-way merge driver can be - explicitly specified by asking for "text" driver; the - built-in "take the current branch" driver can be - requested with "binary". - - -Built-in merge drivers -^^^^^^^^^^^^^^^^^^^^^^ - -There are a few built-in low-level merge drivers defined that -can be asked for via the `merge` attribute. - -text:: - - Usual 3-way file level merge for text files. Conflicted - regions are marked with conflict markers `<<<<<<<`, - `=======` and `>>>>>>>`. The version from your branch - appears before the `=======` marker, and the version - from the merged branch appears after the `=======` - marker. - -binary:: - - Keep the version from your branch in the work tree, but - leave the path in the conflicted state for the user to - sort out. - -union:: - - Run 3-way file level merge for text files, but take - lines from both versions, instead of leaving conflict - markers. This tends to leave the added lines in the - resulting file in random order and the user should - verify the result. Do not use this if you do not - understand the implications. - - -Defining a custom merge driver -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The definition of a merge driver is done in the `.git/config` -file, not in the `gitattributes` file, so strictly speaking this -manual page is a wrong place to talk about it. However... - -To define a custom merge driver `filfre`, add a section to your -`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: - ----------------------------------------------------------------- -[merge "filfre"] - name = feel-free merge driver - driver = filfre %O %A %B %L %P - recursive = binary ----------------------------------------------------------------- - -The `merge.*.name` variable gives the driver a human-readable -name. - -The `merge.*.driver` variable's value is used to construct a -command to run to merge ancestor's version (`%O`), current -version (`%A`) and the other branches' version (`%B`). These -three tokens are replaced with the names of temporary files that -hold the contents of these versions when the command line is -built. Additionally, %L will be replaced with the conflict marker -size (see below). - -The merge driver is expected to leave the result of the merge in -the file named with `%A` by overwriting it, and exit with zero -status if it managed to merge them cleanly, or non-zero if there -were conflicts. - -The `merge.*.recursive` variable specifies what other merge -driver to use when the merge driver is called for an internal -merge between common ancestors, when there are more than one. -When left unspecified, the driver itself is used for both -internal merge and the final merge. - -The merge driver can learn the pathname in which the merged result -will be stored via placeholder `%P`. - - -`conflict-marker-size` -^^^^^^^^^^^^^^^^^^^^^^ - -This attribute controls the length of conflict markers left in -the work tree file during a conflicted merge. Only setting to -the value to a positive integer has any meaningful effect. - -For example, this line in `.gitattributes` can be used to tell the merge -machinery to leave much longer (instead of the usual 7-character-long) -conflict markers when merging the file `Documentation/git-merge.txt` -results in a conflict. - ------------------------- -Documentation/git-merge.txt conflict-marker-size=32 ------------------------- - - -Checking whitespace errors -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -`whitespace` -^^^^^^^^^^^^ - -The `core.whitespace` configuration variable allows you to define what -'diff' and 'apply' should consider whitespace errors for all paths in -the project (See linkgit:git-config[1]). This attribute gives you finer -control per path. - -Set:: - - Notice all types of potential whitespace errors known to Git. - The tab width is taken from the value of the `core.whitespace` - configuration variable. - -Unset:: - - Do not notice anything as error. - -Unspecified:: - - Use the value of the `core.whitespace` configuration variable to - decide what to notice as error. - -String:: - - Specify a comma separate list of common whitespace problems to - notice in the same format as the `core.whitespace` configuration - variable. - - -Creating an archive -~~~~~~~~~~~~~~~~~~~ - -`export-ignore` -^^^^^^^^^^^^^^^ - -Files and directories with the attribute `export-ignore` won't be added to -archive files. - -`export-subst` -^^^^^^^^^^^^^^ - -If the attribute `export-subst` is set for a file then Git will expand -several placeholders when adding this file to an archive. The -expansion depends on the availability of a commit ID, i.e., if -linkgit:git-archive[1] has been given a tree instead of a commit or a -tag then no replacement will be done. The placeholders are the same -as those for the option `--pretty=format:` of linkgit:git-log[1], -except that they need to be wrapped like this: `$Format:PLACEHOLDERS$` -in the file. E.g. the string `$Format:%H$` will be replaced by the -commit hash. - - -Packing objects -~~~~~~~~~~~~~~~ - -`delta` -^^^^^^^ - -Delta compression will not be attempted for blobs for paths with the -attribute `delta` set to false. - - -Viewing files in GUI tools -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -`encoding` -^^^^^^^^^^ - -The value of this attribute specifies the character encoding that should -be used by GUI tools (e.g. linkgit:gitk[1] and linkgit:git-gui[1]) to -display the contents of the relevant file. Note that due to performance -considerations linkgit:gitk[1] does not use this attribute unless you -manually enable per-file encodings in its options. - -If this attribute is not set or has an invalid value, the value of the -`gui.encoding` configuration variable is used instead -(See linkgit:git-config[1]). - - -USING MACRO ATTRIBUTES ----------------------- - -You do not want any end-of-line conversions applied to, nor textual diffs -produced for, any binary file you track. You would need to specify e.g. - ------------- -*.jpg -text -diff ------------- - -but that may become cumbersome, when you have many attributes. Using -macro attributes, you can define an attribute that, when set, also -sets or unsets a number of other attributes at the same time. The -system knows a built-in macro attribute, `binary`: - ------------- -*.jpg binary ------------- - -Setting the "binary" attribute also unsets the "text" and "diff" -attributes as above. Note that macro attributes can only be "Set", -though setting one might have the effect of setting or unsetting other -attributes or even returning other attributes to the "Unspecified" -state. - - -DEFINING MACRO ATTRIBUTES -------------------------- - -Custom macro attributes can be defined only in top-level gitattributes -files (`$GIT_DIR/info/attributes`, the `.gitattributes` file at the -top level of the working tree, or the global or system-wide -gitattributes files), not in `.gitattributes` files in working tree -subdirectories. The built-in macro attribute "binary" is equivalent -to: - ------------- -[attr]binary -diff -merge -text ------------- - - -EXAMPLES --------- - -If you have these three `gitattributes` file: - ----------------------------------------------------------------- -(in $GIT_DIR/info/attributes) - -a* foo !bar -baz - -(in .gitattributes) -abc foo bar baz - -(in t/.gitattributes) -ab* merge=filfre -abc -foo -bar -*.c frotz ----------------------------------------------------------------- - -the attributes given to path `t/abc` are computed as follows: - -1. By examining `t/.gitattributes` (which is in the same - directory as the path in question), Git finds that the first - line matches. `merge` attribute is set. It also finds that - the second line matches, and attributes `foo` and `bar` - are unset. - -2. Then it examines `.gitattributes` (which is in the parent - directory), and finds that the first line matches, but - `t/.gitattributes` file already decided how `merge`, `foo` - and `bar` attributes should be given to this path, so it - leaves `foo` and `bar` unset. Attribute `baz` is set. - -3. Finally it examines `$GIT_DIR/info/attributes`. This file - is used to override the in-tree settings. The first line is - a match, and `foo` is set, `bar` is reverted to unspecified - state, and `baz` is unset. - -As the result, the attributes assignment to `t/abc` becomes: - ----------------------------------------------------------------- -foo set to true -bar unspecified -baz set to false -merge set to string value "filfre" -frotz unspecified ----------------------------------------------------------------- - - -SEE ALSO --------- -linkgit:git-check-attr[1]. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitcli.txt b/third_party/git/Documentation/gitcli.txt deleted file mode 100644 index 1ed3ca33b7..0000000000 --- a/third_party/git/Documentation/gitcli.txt +++ /dev/null @@ -1,226 +0,0 @@ -gitcli(7) -========= - -NAME ----- -gitcli - Git command-line interface and conventions - -SYNOPSIS --------- -gitcli - - -DESCRIPTION ------------ - -This manual describes the convention used throughout Git CLI. - -Many commands take revisions (most often "commits", but sometimes -"tree-ish", depending on the context and command) and paths as their -arguments. Here are the rules: - - * Revisions come first and then paths. - E.g. in `git diff v1.0 v2.0 arch/x86 include/asm-x86`, - `v1.0` and `v2.0` are revisions and `arch/x86` and `include/asm-x86` - are paths. - - * When an argument can be misunderstood as either a revision or a path, - they can be disambiguated by placing `--` between them. - E.g. `git diff -- HEAD` is, "I have a file called HEAD in my work - tree. Please show changes between the version I staged in the index - and what I have in the work tree for that file", not "show difference - between the HEAD commit and the work tree as a whole". You can say - `git diff HEAD --` to ask for the latter. - - * Without disambiguating `--`, Git makes a reasonable guess, but errors - out and asking you to disambiguate when ambiguous. E.g. if you have a - file called HEAD in your work tree, `git diff HEAD` is ambiguous, and - you have to say either `git diff HEAD --` or `git diff -- HEAD` to - disambiguate. -+ -When writing a script that is expected to handle random user-input, it is -a good practice to make it explicit which arguments are which by placing -disambiguating `--` at appropriate places. - - * Many commands allow wildcards in paths, but you need to protect - them from getting globbed by the shell. These two mean different - things: -+ --------------------------------- -$ git restore *.c -$ git restore \*.c --------------------------------- -+ -The former lets your shell expand the fileglob, and you are asking -the dot-C files in your working tree to be overwritten with the version -in the index. The latter passes the `*.c` to Git, and you are asking -the paths in the index that match the pattern to be checked out to your -working tree. After running `git add hello.c; rm hello.c`, you will _not_ -see `hello.c` in your working tree with the former, but with the latter -you will. - - * Just as the filesystem '.' (period) refers to the current directory, - using a '.' as a repository name in Git (a dot-repository) is a relative - path and means your current repository. - -Here are the rules regarding the "flags" that you should follow when you are -scripting Git: - - * it's preferred to use the non-dashed form of Git commands, which means that - you should prefer `git foo` to `git-foo`. - - * splitting short options to separate words (prefer `git foo -a -b` - to `git foo -ab`, the latter may not even work). - - * when a command-line option takes an argument, use the 'stuck' form. In - other words, write `git foo -oArg` instead of `git foo -o Arg` for short - options, and `git foo --long-opt=Arg` instead of `git foo --long-opt Arg` - for long options. An option that takes optional option-argument must be - written in the 'stuck' form. - - * when you give a revision parameter to a command, make sure the parameter is - not ambiguous with a name of a file in the work tree. E.g. do not write - `git log -1 HEAD` but write `git log -1 HEAD --`; the former will not work - if you happen to have a file called `HEAD` in the work tree. - - * many commands allow a long option `--option` to be abbreviated - only to their unique prefix (e.g. if there is no other option - whose name begins with `opt`, you may be able to spell `--opt` to - invoke the `--option` flag), but you should fully spell them out - when writing your scripts; later versions of Git may introduce a - new option whose name shares the same prefix, e.g. `--optimize`, - to make a short prefix that used to be unique no longer unique. - - -ENHANCED OPTION PARSER ----------------------- -From the Git 1.5.4 series and further, many Git commands (not all of them at the -time of the writing though) come with an enhanced option parser. - -Here is a list of the facilities provided by this option parser. - - -Magic Options -~~~~~~~~~~~~~ -Commands which have the enhanced option parser activated all understand a -couple of magic command-line options: - --h:: - gives a pretty printed usage of the command. -+ ---------------------------------------------- -$ git describe -h -usage: git describe [<options>] <commit-ish>* - or: git describe [<options>] --dirty - - --contains find the tag that comes after the commit - --debug debug search strategy on stderr - --all use any ref - --tags use any tag, even unannotated - --long always use long format - --abbrev[=<n>] use <n> digits to display SHA-1s ---------------------------------------------- - ---help-all:: - Some Git commands take options that are only used for plumbing or that - are deprecated, and such options are hidden from the default usage. This - option gives the full list of options. - - -Negating options -~~~~~~~~~~~~~~~~ -Options with long option names can be negated by prefixing `--no-`. For -example, `git branch` has the option `--track` which is 'on' by default. You -can use `--no-track` to override that behaviour. The same goes for `--color` -and `--no-color`. - - -Aggregating short options -~~~~~~~~~~~~~~~~~~~~~~~~~ -Commands that support the enhanced option parser allow you to aggregate short -options. This means that you can for example use `git rm -rf` or -`git clean -fdx`. - - -Abbreviating long options -~~~~~~~~~~~~~~~~~~~~~~~~~ -Commands that support the enhanced option parser accepts unique -prefix of a long option as if it is fully spelled out, but use this -with a caution. For example, `git commit --amen` behaves as if you -typed `git commit --amend`, but that is true only until a later version -of Git introduces another option that shares the same prefix, -e.g. `git commit --amenity` option. - - -Separating argument from the option -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -You can write the mandatory option parameter to an option as a separate -word on the command line. That means that all the following uses work: - ----------------------------- -$ git foo --long-opt=Arg -$ git foo --long-opt Arg -$ git foo -oArg -$ git foo -o Arg ----------------------------- - -However, this is *NOT* allowed for switches with an optional value, where the -'stuck' form must be used: ----------------------------- -$ git describe --abbrev HEAD # correct -$ git describe --abbrev=10 HEAD # correct -$ git describe --abbrev 10 HEAD # NOT WHAT YOU MEANT ----------------------------- - - -NOTES ON FREQUENTLY CONFUSED OPTIONS ------------------------------------- - -Many commands that can work on files in the working tree -and/or in the index can take `--cached` and/or `--index` -options. Sometimes people incorrectly think that, because -the index was originally called cache, these two are -synonyms. They are *not* -- these two options mean very -different things. - - * The `--cached` option is used to ask a command that - usually works on files in the working tree to *only* work - with the index. For example, `git grep`, when used - without a commit to specify from which commit to look for - strings in, usually works on files in the working tree, - but with the `--cached` option, it looks for strings in - the index. - - * The `--index` option is used to ask a command that - usually works on files in the working tree to *also* - affect the index. For example, `git stash apply` usually - merges changes recorded in a stash entry to the working tree, - but with the `--index` option, it also merges changes to - the index as well. - -`git apply` command can be used with `--cached` and -`--index` (but not at the same time). Usually the command -only affects the files in the working tree, but with -`--index`, it patches both the files and their index -entries, and with `--cached`, it modifies only the index -entries. - -See also http://marc.info/?l=git&m=116563135620359 and -http://marc.info/?l=git&m=119150393620273 for further -information. - -Some other commands that also work on files in the working tree and/or -in the index can take `--staged` and/or `--worktree`. - -* `--staged` is exactly like `--cached`, which is used to ask a - command to only work on the index, not the working tree. - -* `--worktree` is the opposite, to ask a command to work on the - working tree only, not the index. - -* The two options can be specified together to ask a command to work - on both the index and the working tree. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitcore-tutorial.txt b/third_party/git/Documentation/gitcore-tutorial.txt deleted file mode 100644 index f880d21dfb..0000000000 --- a/third_party/git/Documentation/gitcore-tutorial.txt +++ /dev/null @@ -1,1660 +0,0 @@ -gitcore-tutorial(7) -=================== - -NAME ----- -gitcore-tutorial - A Git core tutorial for developers - -SYNOPSIS --------- -git * - -DESCRIPTION ------------ - -This tutorial explains how to use the "core" Git commands to set up and -work with a Git repository. - -If you just need to use Git as a revision control system you may prefer -to start with "A Tutorial Introduction to Git" (linkgit:gittutorial[7]) or -link:user-manual.html[the Git User Manual]. - -However, an understanding of these low-level tools can be helpful if -you want to understand Git's internals. - -The core Git is often called "plumbing", with the prettier user -interfaces on top of it called "porcelain". You may not want to use the -plumbing directly very often, but it can be good to know what the -plumbing does when the porcelain isn't flushing. - -Back when this document was originally written, many porcelain -commands were shell scripts. For simplicity, it still uses them as -examples to illustrate how plumbing is fit together to form the -porcelain commands. The source tree includes some of these scripts in -contrib/examples/ for reference. Although these are not implemented as -shell scripts anymore, the description of what the plumbing layer -commands do is still valid. - -[NOTE] -Deeper technical details are often marked as Notes, which you can -skip on your first reading. - - -Creating a Git repository -------------------------- - -Creating a new Git repository couldn't be easier: all Git repositories start -out empty, and the only thing you need to do is find yourself a -subdirectory that you want to use as a working tree - either an empty -one for a totally new project, or an existing working tree that you want -to import into Git. - -For our first example, we're going to start a totally new repository from -scratch, with no pre-existing files, and we'll call it 'git-tutorial'. -To start up, create a subdirectory for it, change into that -subdirectory, and initialize the Git infrastructure with 'git init': - ------------------------------------------------- -$ mkdir git-tutorial -$ cd git-tutorial -$ git init ------------------------------------------------- - -to which Git will reply - ----------------- -Initialized empty Git repository in .git/ ----------------- - -which is just Git's way of saying that you haven't been doing anything -strange, and that it will have created a local `.git` directory setup for -your new project. You will now have a `.git` directory, and you can -inspect that with 'ls'. For your new empty project, it should show you -three entries, among other things: - - - a file called `HEAD`, that has `ref: refs/heads/master` in it. - This is similar to a symbolic link and points at - `refs/heads/master` relative to the `HEAD` file. -+ -Don't worry about the fact that the file that the `HEAD` link points to -doesn't even exist yet -- you haven't created the commit that will -start your `HEAD` development branch yet. - - - a subdirectory called `objects`, which will contain all the - objects of your project. You should never have any real reason to - look at the objects directly, but you might want to know that these - objects are what contains all the real 'data' in your repository. - - - a subdirectory called `refs`, which contains references to objects. - -In particular, the `refs` subdirectory will contain two other -subdirectories, named `heads` and `tags` respectively. They do -exactly what their names imply: they contain references to any number -of different 'heads' of development (aka 'branches'), and to any -'tags' that you have created to name specific versions in your -repository. - -One note: the special `master` head is the default branch, which is -why the `.git/HEAD` file was created points to it even if it -doesn't yet exist. Basically, the `HEAD` link is supposed to always -point to the branch you are working on right now, and you always -start out expecting to work on the `master` branch. - -However, this is only a convention, and you can name your branches -anything you want, and don't have to ever even 'have' a `master` -branch. A number of the Git tools will assume that `.git/HEAD` is -valid, though. - -[NOTE] -An 'object' is identified by its 160-bit SHA-1 hash, aka 'object name', -and a reference to an object is always the 40-byte hex -representation of that SHA-1 name. The files in the `refs` -subdirectory are expected to contain these hex references -(usually with a final `\n` at the end), and you should thus -expect to see a number of 41-byte files containing these -references in these `refs` subdirectories when you actually start -populating your tree. - -[NOTE] -An advanced user may want to take a look at linkgit:gitrepository-layout[5] -after finishing this tutorial. - -You have now created your first Git repository. Of course, since it's -empty, that's not very useful, so let's start populating it with data. - - -Populating a Git repository ---------------------------- - -We'll keep this simple and stupid, so we'll start off with populating a -few trivial files just to get a feel for it. - -Start off with just creating any random files that you want to maintain -in your Git repository. We'll start off with a few bad examples, just to -get a feel for how this works: - ------------------------------------------------- -$ echo "Hello World" >hello -$ echo "Silly example" >example ------------------------------------------------- - -you have now created two files in your working tree (aka 'working directory'), -but to actually check in your hard work, you will have to go through two steps: - - - fill in the 'index' file (aka 'cache') with the information about your - working tree state. - - - commit that index file as an object. - -The first step is trivial: when you want to tell Git about any changes -to your working tree, you use the 'git update-index' program. That -program normally just takes a list of filenames you want to update, but -to avoid trivial mistakes, it refuses to add new entries to the index -(or remove existing ones) unless you explicitly tell it that you're -adding a new entry with the `--add` flag (or removing an entry with the -`--remove`) flag. - -So to populate the index with the two files you just created, you can do - ------------------------------------------------- -$ git update-index --add hello example ------------------------------------------------- - -and you have now told Git to track those two files. - -In fact, as you did that, if you now look into your object directory, -you'll notice that Git will have added two new objects to the object -database. If you did exactly the steps above, you should now be able to do - - ----------------- -$ ls .git/objects/??/* ----------------- - -and see two files: - ----------------- -.git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238 -.git/objects/f2/4c74a2e500f5ee1332c86b94199f52b1d1d962 ----------------- - -which correspond with the objects with names of `557db...` and -`f24c7...` respectively. - -If you want to, you can use 'git cat-file' to look at those objects, but -you'll have to use the object name, not the filename of the object: - ----------------- -$ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238 ----------------- - -where the `-t` tells 'git cat-file' to tell you what the "type" of the -object is. Git will tell you that you have a "blob" object (i.e., just a -regular file), and you can see the contents with - ----------------- -$ git cat-file blob 557db03 ----------------- - -which will print out "Hello World". The object `557db03` is nothing -more than the contents of your file `hello`. - -[NOTE] -Don't confuse that object with the file `hello` itself. The -object is literally just those specific *contents* of the file, and -however much you later change the contents in file `hello`, the object -we just looked at will never change. Objects are immutable. - -[NOTE] -The second example demonstrates that you can -abbreviate the object name to only the first several -hexadecimal digits in most places. - -Anyway, as we mentioned previously, you normally never actually take a -look at the objects themselves, and typing long 40-character hex -names is not something you'd normally want to do. The above digression -was just to show that 'git update-index' did something magical, and -actually saved away the contents of your files into the Git object -database. - -Updating the index did something else too: it created a `.git/index` -file. This is the index that describes your current working tree, and -something you should be very aware of. Again, you normally never worry -about the index file itself, but you should be aware of the fact that -you have not actually really "checked in" your files into Git so far, -you've only *told* Git about them. - -However, since Git knows about them, you can now start using some of the -most basic Git commands to manipulate the files or look at their status. - -In particular, let's not even check in the two files into Git yet, we'll -start off by adding another line to `hello` first: - ------------------------------------------------- -$ echo "It's a new day for git" >>hello ------------------------------------------------- - -and you can now, since you told Git about the previous state of `hello`, ask -Git what has changed in the tree compared to your old index, using the -'git diff-files' command: - ------------- -$ git diff-files ------------- - -Oops. That wasn't very readable. It just spit out its own internal -version of a 'diff', but that internal version really just tells you -that it has noticed that "hello" has been modified, and that the old object -contents it had have been replaced with something else. - -To make it readable, we can tell 'git diff-files' to output the -differences as a patch, using the `-p` flag: - ------------- -$ git diff-files -p -diff --git a/hello b/hello -index 557db03..263414f 100644 ---- a/hello -+++ b/hello -@@ -1 +1,2 @@ - Hello World -+It's a new day for git ------------- - -i.e. the diff of the change we caused by adding another line to `hello`. - -In other words, 'git diff-files' always shows us the difference between -what is recorded in the index, and what is currently in the working -tree. That's very useful. - -A common shorthand for `git diff-files -p` is to just write `git -diff`, which will do the same thing. - ------------- -$ git diff -diff --git a/hello b/hello -index 557db03..263414f 100644 ---- a/hello -+++ b/hello -@@ -1 +1,2 @@ - Hello World -+It's a new day for git ------------- - - -Committing Git state --------------------- - -Now, we want to go to the next stage in Git, which is to take the files -that Git knows about in the index, and commit them as a real tree. We do -that in two phases: creating a 'tree' object, and committing that 'tree' -object as a 'commit' object together with an explanation of what the -tree was all about, along with information of how we came to that state. - -Creating a tree object is trivial, and is done with 'git write-tree'. -There are no options or other input: `git write-tree` will take the -current index state, and write an object that describes that whole -index. In other words, we're now tying together all the different -filenames with their contents (and their permissions), and we're -creating the equivalent of a Git "directory" object: - ------------------------------------------------- -$ git write-tree ------------------------------------------------- - -and this will just output the name of the resulting tree, in this case -(if you have done exactly as I've described) it should be - ----------------- -8988da15d077d4829fc51d8544c097def6644dbb ----------------- - -which is another incomprehensible object name. Again, if you want to, -you can use `git cat-file -t 8988d...` to see that this time the object -is not a "blob" object, but a "tree" object (you can also use -`git cat-file` to actually output the raw object contents, but you'll see -mainly a binary mess, so that's less interesting). - -However -- normally you'd never use 'git write-tree' on its own, because -normally you always commit a tree into a commit object using the -'git commit-tree' command. In fact, it's easier to not actually use -'git write-tree' on its own at all, but to just pass its result in as an -argument to 'git commit-tree'. - -'git commit-tree' normally takes several arguments -- it wants to know -what the 'parent' of a commit was, but since this is the first commit -ever in this new repository, and it has no parents, we only need to pass in -the object name of the tree. However, 'git commit-tree' also wants to get a -commit message on its standard input, and it will write out the resulting -object name for the commit to its standard output. - -And this is where we create the `.git/refs/heads/master` file -which is pointed at by `HEAD`. This file is supposed to contain -the reference to the top-of-tree of the master branch, and since -that's exactly what 'git commit-tree' spits out, we can do this -all with a sequence of simple shell commands: - ------------------------------------------------- -$ tree=$(git write-tree) -$ commit=$(echo 'Initial commit' | git commit-tree $tree) -$ git update-ref HEAD $commit ------------------------------------------------- - -In this case this creates a totally new commit that is not related to -anything else. Normally you do this only *once* for a project ever, and -all later commits will be parented on top of an earlier commit. - -Again, normally you'd never actually do this by hand. There is a -helpful script called `git commit` that will do all of this for you. So -you could have just written `git commit` -instead, and it would have done the above magic scripting for you. - - -Making a change ---------------- - -Remember how we did the 'git update-index' on file `hello` and then we -changed `hello` afterward, and could compare the new state of `hello` with the -state we saved in the index file? - -Further, remember how I said that 'git write-tree' writes the contents -of the *index* file to the tree, and thus what we just committed was in -fact the *original* contents of the file `hello`, not the new ones. We did -that on purpose, to show the difference between the index state, and the -state in the working tree, and how they don't have to match, even -when we commit things. - -As before, if we do `git diff-files -p` in our git-tutorial project, -we'll still see the same difference we saw last time: the index file -hasn't changed by the act of committing anything. However, now that we -have committed something, we can also learn to use a new command: -'git diff-index'. - -Unlike 'git diff-files', which showed the difference between the index -file and the working tree, 'git diff-index' shows the differences -between a committed *tree* and either the index file or the working -tree. In other words, 'git diff-index' wants a tree to be diffed -against, and before we did the commit, we couldn't do that, because we -didn't have anything to diff against. - -But now we can do - ----------------- -$ git diff-index -p HEAD ----------------- - -(where `-p` has the same meaning as it did in 'git diff-files'), and it -will show us the same difference, but for a totally different reason. -Now we're comparing the working tree not against the index file, -but against the tree we just wrote. It just so happens that those two -are obviously the same, so we get the same result. - -Again, because this is a common operation, you can also just shorthand -it with - ----------------- -$ git diff HEAD ----------------- - -which ends up doing the above for you. - -In other words, 'git diff-index' normally compares a tree against the -working tree, but when given the `--cached` flag, it is told to -instead compare against just the index cache contents, and ignore the -current working tree state entirely. Since we just wrote the index -file to HEAD, doing `git diff-index --cached -p HEAD` should thus return -an empty set of differences, and that's exactly what it does. - -[NOTE] -================ -'git diff-index' really always uses the index for its -comparisons, and saying that it compares a tree against the working -tree is thus not strictly accurate. In particular, the list of -files to compare (the "meta-data") *always* comes from the index file, -regardless of whether the `--cached` flag is used or not. The `--cached` -flag really only determines whether the file *contents* to be compared -come from the working tree or not. - -This is not hard to understand, as soon as you realize that Git simply -never knows (or cares) about files that it is not told about -explicitly. Git will never go *looking* for files to compare, it -expects you to tell it what the files are, and that's what the index -is there for. -================ - -However, our next step is to commit the *change* we did, and again, to -understand what's going on, keep in mind the difference between "working -tree contents", "index file" and "committed tree". We have changes -in the working tree that we want to commit, and we always have to -work through the index file, so the first thing we need to do is to -update the index cache: - ------------------------------------------------- -$ git update-index hello ------------------------------------------------- - -(note how we didn't need the `--add` flag this time, since Git knew -about the file already). - -Note what happens to the different 'git diff-{asterisk}' versions here. -After we've updated `hello` in the index, `git diff-files -p` now shows no -differences, but `git diff-index -p HEAD` still *does* show that the -current state is different from the state we committed. In fact, now -'git diff-index' shows the same difference whether we use the `--cached` -flag or not, since now the index is coherent with the working tree. - -Now, since we've updated `hello` in the index, we can commit the new -version. We could do it by writing the tree by hand again, and -committing the tree (this time we'd have to use the `-p HEAD` flag to -tell commit that the HEAD was the *parent* of the new commit, and that -this wasn't an initial commit any more), but you've done that once -already, so let's just use the helpful script this time: - ------------------------------------------------- -$ git commit ------------------------------------------------- - -which starts an editor for you to write the commit message and tells you -a bit about what you have done. - -Write whatever message you want, and all the lines that start with '#' -will be pruned out, and the rest will be used as the commit message for -the change. If you decide you don't want to commit anything after all at -this point (you can continue to edit things and update the index), you -can just leave an empty message. Otherwise `git commit` will commit -the change for you. - -You've now made your first real Git commit. And if you're interested in -looking at what `git commit` really does, feel free to investigate: -it's a few very simple shell scripts to generate the helpful (?) commit -message headers, and a few one-liners that actually do the -commit itself ('git commit'). - - -Inspecting Changes ------------------- - -While creating changes is useful, it's even more useful if you can tell -later what changed. The most useful command for this is another of the -'diff' family, namely 'git diff-tree'. - -'git diff-tree' can be given two arbitrary trees, and it will tell you the -differences between them. Perhaps even more commonly, though, you can -give it just a single commit object, and it will figure out the parent -of that commit itself, and show the difference directly. Thus, to get -the same diff that we've already seen several times, we can now do - ----------------- -$ git diff-tree -p HEAD ----------------- - -(again, `-p` means to show the difference as a human-readable patch), -and it will show what the last commit (in `HEAD`) actually changed. - -[NOTE] -============ -Here is an ASCII art by Jon Loeliger that illustrates how -various 'diff-{asterisk}' commands compare things. - - diff-tree - +----+ - | | - | | - V V - +-----------+ - | Object DB | - | Backing | - | Store | - +-----------+ - ^ ^ - | | - | | diff-index --cached - | | - diff-index | V - | +-----------+ - | | Index | - | | "cache" | - | +-----------+ - | ^ - | | - | | diff-files - | | - V V - +-----------+ - | Working | - | Directory | - +-----------+ -============ - -More interestingly, you can also give 'git diff-tree' the `--pretty` flag, -which tells it to also show the commit message and author and date of the -commit, and you can tell it to show a whole series of diffs. -Alternatively, you can tell it to be "silent", and not show the diffs at -all, but just show the actual commit message. - -In fact, together with the 'git rev-list' program (which generates a -list of revisions), 'git diff-tree' ends up being a veritable fount of -changes. You can emulate `git log`, `git log -p`, etc. with a trivial -script that pipes the output of `git rev-list` to `git diff-tree --stdin`, -which was exactly how early versions of `git log` were implemented. - - -Tagging a version ------------------ - -In Git, there are two kinds of tags, a "light" one, and an "annotated tag". - -A "light" tag is technically nothing more than a branch, except we put -it in the `.git/refs/tags/` subdirectory instead of calling it a `head`. -So the simplest form of tag involves nothing more than - ------------------------------------------------- -$ git tag my-first-tag ------------------------------------------------- - -which just writes the current `HEAD` into the `.git/refs/tags/my-first-tag` -file, after which point you can then use this symbolic name for that -particular state. You can, for example, do - ----------------- -$ git diff my-first-tag ----------------- - -to diff your current state against that tag which at this point will -obviously be an empty diff, but if you continue to develop and commit -stuff, you can use your tag as an "anchor-point" to see what has changed -since you tagged it. - -An "annotated tag" is actually a real Git object, and contains not only a -pointer to the state you want to tag, but also a small tag name and -message, along with optionally a PGP signature that says that yes, -you really did -that tag. You create these annotated tags with either the `-a` or -`-s` flag to 'git tag': - ----------------- -$ git tag -s <tagname> ----------------- - -which will sign the current `HEAD` (but you can also give it another -argument that specifies the thing to tag, e.g., you could have tagged the -current `mybranch` point by using `git tag <tagname> mybranch`). - -You normally only do signed tags for major releases or things -like that, while the light-weight tags are useful for any marking you -want to do -- any time you decide that you want to remember a certain -point, just create a private tag for it, and you have a nice symbolic -name for the state at that point. - - -Copying repositories --------------------- - -Git repositories are normally totally self-sufficient and relocatable. -Unlike CVS, for example, there is no separate notion of -"repository" and "working tree". A Git repository normally *is* the -working tree, with the local Git information hidden in the `.git` -subdirectory. There is nothing else. What you see is what you got. - -[NOTE] -You can tell Git to split the Git internal information from -the directory that it tracks, but we'll ignore that for now: it's not -how normal projects work, and it's really only meant for special uses. -So the mental model of "the Git information is always tied directly to -the working tree that it describes" may not be technically 100% -accurate, but it's a good model for all normal use. - -This has two implications: - - - if you grow bored with the tutorial repository you created (or you've - made a mistake and want to start all over), you can just do simple -+ ----------------- -$ rm -rf git-tutorial ----------------- -+ -and it will be gone. There's no external repository, and there's no -history outside the project you created. - - - if you want to move or duplicate a Git repository, you can do so. There - is 'git clone' command, but if all you want to do is just to - create a copy of your repository (with all the full history that - went along with it), you can do so with a regular - `cp -a git-tutorial new-git-tutorial`. -+ -Note that when you've moved or copied a Git repository, your Git index -file (which caches various information, notably some of the "stat" -information for the files involved) will likely need to be refreshed. -So after you do a `cp -a` to create a new copy, you'll want to do -+ ----------------- -$ git update-index --refresh ----------------- -+ -in the new repository to make sure that the index file is up to date. - -Note that the second point is true even across machines. You can -duplicate a remote Git repository with *any* regular copy mechanism, be it -'scp', 'rsync' or 'wget'. - -When copying a remote repository, you'll want to at a minimum update the -index cache when you do this, and especially with other peoples' -repositories you often want to make sure that the index cache is in some -known state (you don't know *what* they've done and not yet checked in), -so usually you'll precede the 'git update-index' with a - ----------------- -$ git read-tree --reset HEAD -$ git update-index --refresh ----------------- - -which will force a total index re-build from the tree pointed to by `HEAD`. -It resets the index contents to `HEAD`, and then the 'git update-index' -makes sure to match up all index entries with the checked-out files. -If the original repository had uncommitted changes in its -working tree, `git update-index --refresh` notices them and -tells you they need to be updated. - -The above can also be written as simply - ----------------- -$ git reset ----------------- - -and in fact a lot of the common Git command combinations can be scripted -with the `git xyz` interfaces. You can learn things by just looking -at what the various git scripts do. For example, `git reset` used to be -the above two lines implemented in 'git reset', but some things like -'git status' and 'git commit' are slightly more complex scripts around -the basic Git commands. - -Many (most?) public remote repositories will not contain any of -the checked out files or even an index file, and will *only* contain the -actual core Git files. Such a repository usually doesn't even have the -`.git` subdirectory, but has all the Git files directly in the -repository. - -To create your own local live copy of such a "raw" Git repository, you'd -first create your own subdirectory for the project, and then copy the -raw repository contents into the `.git` directory. For example, to -create your own copy of the Git repository, you'd do the following - ----------------- -$ mkdir my-git -$ cd my-git -$ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git ----------------- - -followed by - ----------------- -$ git read-tree HEAD ----------------- - -to populate the index. However, now you have populated the index, and -you have all the Git internal files, but you will notice that you don't -actually have any of the working tree files to work on. To get -those, you'd check them out with - ----------------- -$ git checkout-index -u -a ----------------- - -where the `-u` flag means that you want the checkout to keep the index -up to date (so that you don't have to refresh it afterward), and the -`-a` flag means "check out all files" (if you have a stale copy or an -older version of a checked out tree you may also need to add the `-f` -flag first, to tell 'git checkout-index' to *force* overwriting of any old -files). - -Again, this can all be simplified with - ----------------- -$ git clone git://git.kernel.org/pub/scm/git/git.git/ my-git -$ cd my-git -$ git checkout ----------------- - -which will end up doing all of the above for you. - -You have now successfully copied somebody else's (mine) remote -repository, and checked it out. - - -Creating a new branch ---------------------- - -Branches in Git are really nothing more than pointers into the Git -object database from within the `.git/refs/` subdirectory, and as we -already discussed, the `HEAD` branch is nothing but a symlink to one of -these object pointers. - -You can at any time create a new branch by just picking an arbitrary -point in the project history, and just writing the SHA-1 name of that -object into a file under `.git/refs/heads/`. You can use any filename you -want (and indeed, subdirectories), but the convention is that the -"normal" branch is called `master`. That's just a convention, though, -and nothing enforces it. - -To show that as an example, let's go back to the git-tutorial repository we -used earlier, and create a branch in it. You do that by simply just -saying that you want to check out a new branch: - ------------- -$ git switch -c mybranch ------------- - -will create a new branch based at the current `HEAD` position, and switch -to it. - -[NOTE] -================================================ -If you make the decision to start your new branch at some -other point in the history than the current `HEAD`, you can do so by -just telling 'git checkout' what the base of the checkout would be. -In other words, if you have an earlier tag or branch, you'd just do - ------------- -$ git switch -c mybranch earlier-commit ------------- - -and it would create the new branch `mybranch` at the earlier commit, -and check out the state at that time. -================================================ - -You can always just jump back to your original `master` branch by doing - ------------- -$ git switch master ------------- - -(or any other branch-name, for that matter) and if you forget which -branch you happen to be on, a simple - ------------- -$ cat .git/HEAD ------------- - -will tell you where it's pointing. To get the list of branches -you have, you can say - ------------- -$ git branch ------------- - -which used to be nothing more than a simple script around `ls .git/refs/heads`. -There will be an asterisk in front of the branch you are currently on. - -Sometimes you may wish to create a new branch _without_ actually -checking it out and switching to it. If so, just use the command - ------------- -$ git branch <branchname> [startingpoint] ------------- - -which will simply _create_ the branch, but will not do anything further. -You can then later -- once you decide that you want to actually develop -on that branch -- switch to that branch with a regular 'git switch' -with the branchname as the argument. - - -Merging two branches --------------------- - -One of the ideas of having a branch is that you do some (possibly -experimental) work in it, and eventually merge it back to the main -branch. So assuming you created the above `mybranch` that started out -being the same as the original `master` branch, let's make sure we're in -that branch, and do some work there. - ------------------------------------------------- -$ git switch mybranch -$ echo "Work, work, work" >>hello -$ git commit -m "Some work." -i hello ------------------------------------------------- - -Here, we just added another line to `hello`, and we used a shorthand for -doing both `git update-index hello` and `git commit` by just giving the -filename directly to `git commit`, with an `-i` flag (it tells -Git to 'include' that file in addition to what you have done to -the index file so far when making the commit). The `-m` flag is to give the -commit log message from the command line. - -Now, to make it a bit more interesting, let's assume that somebody else -does some work in the original branch, and simulate that by going back -to the master branch, and editing the same file differently there: - ------------- -$ git switch master ------------- - -Here, take a moment to look at the contents of `hello`, and notice how they -don't contain the work we just did in `mybranch` -- because that work -hasn't happened in the `master` branch at all. Then do - ------------- -$ echo "Play, play, play" >>hello -$ echo "Lots of fun" >>example -$ git commit -m "Some fun." -i hello example ------------- - -since the master branch is obviously in a much better mood. - -Now, you've got two branches, and you decide that you want to merge the -work done. Before we do that, let's introduce a cool graphical tool that -helps you view what's going on: - ----------------- -$ gitk --all ----------------- - -will show you graphically both of your branches (that's what the `--all` -means: normally it will just show you your current `HEAD`) and their -histories. You can also see exactly how they came to be from a common -source. - -Anyway, let's exit 'gitk' (`^Q` or the File menu), and decide that we want -to merge the work we did on the `mybranch` branch into the `master` -branch (which is currently our `HEAD` too). To do that, there's a nice -script called 'git merge', which wants to know which branches you want -to resolve and what the merge is all about: - ------------- -$ git merge -m "Merge work in mybranch" mybranch ------------- - -where the first argument is going to be used as the commit message if -the merge can be resolved automatically. - -Now, in this case we've intentionally created a situation where the -merge will need to be fixed up by hand, though, so Git will do as much -of it as it can automatically (which in this case is just merge the `example` -file, which had no differences in the `mybranch` branch), and say: - ----------------- - Auto-merging hello - CONFLICT (content): Merge conflict in hello - Automatic merge failed; fix conflicts and then commit the result. ----------------- - -It tells you that it did an "Automatic merge", which -failed due to conflicts in `hello`. - -Not to worry. It left the (trivial) conflict in `hello` in the same form you -should already be well used to if you've ever used CVS, so let's just -open `hello` in our editor (whatever that may be), and fix it up somehow. -I'd suggest just making it so that `hello` contains all four lines: - ------------- -Hello World -It's a new day for git -Play, play, play -Work, work, work ------------- - -and once you're happy with your manual merge, just do a - ------------- -$ git commit -i hello ------------- - -which will very loudly warn you that you're now committing a merge -(which is correct, so never mind), and you can write a small merge -message about your adventures in 'git merge'-land. - -After you're done, start up `gitk --all` to see graphically what the -history looks like. Notice that `mybranch` still exists, and you can -switch to it, and continue to work with it if you want to. The -`mybranch` branch will not contain the merge, but next time you merge it -from the `master` branch, Git will know how you merged it, so you'll not -have to do _that_ merge again. - -Another useful tool, especially if you do not always work in X-Window -environment, is `git show-branch`. - ------------------------------------------------- -$ git show-branch --topo-order --more=1 master mybranch -* [master] Merge work in mybranch - ! [mybranch] Some work. --- -- [master] Merge work in mybranch -*+ [mybranch] Some work. -* [master^] Some fun. ------------------------------------------------- - -The first two lines indicate that it is showing the two branches -with the titles of their top-of-the-tree commits, you are currently on -`master` branch (notice the asterisk `*` character), and the first -column for the later output lines is used to show commits contained in the -`master` branch, and the second column for the `mybranch` -branch. Three commits are shown along with their titles. -All of them have non blank characters in the first column (`*` -shows an ordinary commit on the current branch, `-` is a merge commit), which -means they are now part of the `master` branch. Only the "Some -work" commit has the plus `+` character in the second column, -because `mybranch` has not been merged to incorporate these -commits from the master branch. The string inside brackets -before the commit log message is a short name you can use to -name the commit. In the above example, 'master' and 'mybranch' -are branch heads. 'master^' is the first parent of 'master' -branch head. Please see linkgit:gitrevisions[7] if you want to -see more complex cases. - -[NOTE] -Without the '--more=1' option, 'git show-branch' would not output the -'[master^]' commit, as '[mybranch]' commit is a common ancestor of -both 'master' and 'mybranch' tips. Please see linkgit:git-show-branch[1] -for details. - -[NOTE] -If there were more commits on the 'master' branch after the merge, the -merge commit itself would not be shown by 'git show-branch' by -default. You would need to provide `--sparse` option to make the -merge commit visible in this case. - -Now, let's pretend you are the one who did all the work in -`mybranch`, and the fruit of your hard work has finally been merged -to the `master` branch. Let's go back to `mybranch`, and run -'git merge' to get the "upstream changes" back to your branch. - ------------- -$ git switch mybranch -$ git merge -m "Merge upstream changes." master ------------- - -This outputs something like this (the actual commit object names -would be different) - ----------------- -Updating from ae3a2da... to a80b4aa.... -Fast-forward (no commit created; -m option ignored) - example | 1 + - hello | 1 + - 2 files changed, 2 insertions(+) ----------------- - -Because your branch did not contain anything more than what had -already been merged into the `master` branch, the merge operation did -not actually do a merge. Instead, it just updated the top of -the tree of your branch to that of the `master` branch. This is -often called 'fast-forward' merge. - -You can run `gitk --all` again to see how the commit ancestry -looks like, or run 'show-branch', which tells you this. - ------------------------------------------------- -$ git show-branch master mybranch -! [master] Merge work in mybranch - * [mybranch] Merge work in mybranch --- --- [master] Merge work in mybranch ------------------------------------------------- - - -Merging external work ---------------------- - -It's usually much more common that you merge with somebody else than -merging with your own branches, so it's worth pointing out that Git -makes that very easy too, and in fact, it's not that different from -doing a 'git merge'. In fact, a remote merge ends up being nothing -more than "fetch the work from a remote repository into a temporary tag" -followed by a 'git merge'. - -Fetching from a remote repository is done by, unsurprisingly, -'git fetch': - ----------------- -$ git fetch <remote-repository> ----------------- - -One of the following transports can be used to name the -repository to download from: - -SSH:: - `remote.machine:/path/to/repo.git/` or -+ -`ssh://remote.machine/path/to/repo.git/` -+ -This transport can be used for both uploading and downloading, -and requires you to have a log-in privilege over `ssh` to the -remote machine. It finds out the set of objects the other side -lacks by exchanging the head commits both ends have and -transfers (close to) minimum set of objects. It is by far the -most efficient way to exchange Git objects between repositories. - -Local directory:: - `/path/to/repo.git/` -+ -This transport is the same as SSH transport but uses 'sh' to run -both ends on the local machine instead of running other end on -the remote machine via 'ssh'. - -Git Native:: - `git://remote.machine/path/to/repo.git/` -+ -This transport was designed for anonymous downloading. Like SSH -transport, it finds out the set of objects the downstream side -lacks and transfers (close to) minimum set of objects. - -HTTP(S):: - `http://remote.machine/path/to/repo.git/` -+ -Downloader from http and https URL -first obtains the topmost commit object name from the remote site -by looking at the specified refname under `repo.git/refs/` directory, -and then tries to obtain the -commit object by downloading from `repo.git/objects/xx/xxx...` -using the object name of that commit object. Then it reads the -commit object to find out its parent commits and the associate -tree object; it repeats this process until it gets all the -necessary objects. Because of this behavior, they are -sometimes also called 'commit walkers'. -+ -The 'commit walkers' are sometimes also called 'dumb -transports', because they do not require any Git aware smart -server like Git Native transport does. Any stock HTTP server -that does not even support directory index would suffice. But -you must prepare your repository with 'git update-server-info' -to help dumb transport downloaders. - -Once you fetch from the remote repository, you `merge` that -with your current branch. - -However -- it's such a common thing to `fetch` and then -immediately `merge`, that it's called `git pull`, and you can -simply do - ----------------- -$ git pull <remote-repository> ----------------- - -and optionally give a branch-name for the remote end as a second -argument. - -[NOTE] -You could do without using any branches at all, by -keeping as many local repositories as you would like to have -branches, and merging between them with 'git pull', just like -you merge between branches. The advantage of this approach is -that it lets you keep a set of files for each `branch` checked -out and you may find it easier to switch back and forth if you -juggle multiple lines of development simultaneously. Of -course, you will pay the price of more disk usage to hold -multiple working trees, but disk space is cheap these days. - -It is likely that you will be pulling from the same remote -repository from time to time. As a short hand, you can store -the remote repository URL in the local repository's config file -like this: - ------------------------------------------------- -$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/ ------------------------------------------------- - -and use the "linus" keyword with 'git pull' instead of the full URL. - -Examples. - -. `git pull linus` -. `git pull linus tag v0.99.1` - -the above are equivalent to: - -. `git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD` -. `git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1` - - -How does the merge work? ------------------------- - -We said this tutorial shows what plumbing does to help you cope -with the porcelain that isn't flushing, but we so far did not -talk about how the merge really works. If you are following -this tutorial the first time, I'd suggest to skip to "Publishing -your work" section and come back here later. - -OK, still with me? To give us an example to look at, let's go -back to the earlier repository with "hello" and "example" file, -and bring ourselves back to the pre-merge state: - ------------- -$ git show-branch --more=2 master mybranch -! [master] Merge work in mybranch - * [mybranch] Merge work in mybranch --- --- [master] Merge work in mybranch -+* [master^2] Some work. -+* [master^] Some fun. ------------- - -Remember, before running 'git merge', our `master` head was at -"Some fun." commit, while our `mybranch` head was at "Some -work." commit. - ------------- -$ git switch -C mybranch master^2 -$ git switch master -$ git reset --hard master^ ------------- - -After rewinding, the commit structure should look like this: - ------------- -$ git show-branch -* [master] Some fun. - ! [mybranch] Some work. --- -* [master] Some fun. - + [mybranch] Some work. -*+ [master^] Initial commit ------------- - -Now we are ready to experiment with the merge by hand. - -`git merge` command, when merging two branches, uses 3-way merge -algorithm. First, it finds the common ancestor between them. -The command it uses is 'git merge-base': - ------------- -$ mb=$(git merge-base HEAD mybranch) ------------- - -The command writes the commit object name of the common ancestor -to the standard output, so we captured its output to a variable, -because we will be using it in the next step. By the way, the common -ancestor commit is the "Initial commit" commit in this case. You can -tell it by: - ------------- -$ git name-rev --name-only --tags $mb -my-first-tag ------------- - -After finding out a common ancestor commit, the second step is -this: - ------------- -$ git read-tree -m -u $mb HEAD mybranch ------------- - -This is the same 'git read-tree' command we have already seen, -but it takes three trees, unlike previous examples. This reads -the contents of each tree into different 'stage' in the index -file (the first tree goes to stage 1, the second to stage 2, -etc.). After reading three trees into three stages, the paths -that are the same in all three stages are 'collapsed' into stage -0. Also paths that are the same in two of three stages are -collapsed into stage 0, taking the SHA-1 from either stage 2 or -stage 3, whichever is different from stage 1 (i.e. only one side -changed from the common ancestor). - -After 'collapsing' operation, paths that are different in three -trees are left in non-zero stages. At this point, you can -inspect the index file with this command: - ------------- -$ git ls-files --stage -100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example -100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello -100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello -100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello ------------- - -In our example of only two files, we did not have unchanged -files so only 'example' resulted in collapsing. But in real-life -large projects, when only a small number of files change in one commit, -this 'collapsing' tends to trivially merge most of the paths -fairly quickly, leaving only a handful of real changes in non-zero -stages. - -To look at only non-zero stages, use `--unmerged` flag: - ------------- -$ git ls-files --unmerged -100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello -100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello -100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello ------------- - -The next step of merging is to merge these three versions of the -file, using 3-way merge. This is done by giving -'git merge-one-file' command as one of the arguments to -'git merge-index' command: - ------------- -$ git merge-index git-merge-one-file hello -Auto-merging hello -ERROR: Merge conflict in hello -fatal: merge program failed ------------- - -'git merge-one-file' script is called with parameters to -describe those three versions, and is responsible to leave the -merge results in the working tree. -It is a fairly straightforward shell script, and -eventually calls 'merge' program from RCS suite to perform a -file-level 3-way merge. In this case, 'merge' detects -conflicts, and the merge result with conflict marks is left in -the working tree.. This can be seen if you run `ls-files ---stage` again at this point: - ------------- -$ git ls-files --stage -100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example -100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello -100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello -100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello ------------- - -This is the state of the index file and the working file after -'git merge' returns control back to you, leaving the conflicting -merge for you to resolve. Notice that the path `hello` is still -unmerged, and what you see with 'git diff' at this point is -differences since stage 2 (i.e. your version). - - -Publishing your work --------------------- - -So, we can use somebody else's work from a remote repository, but -how can *you* prepare a repository to let other people pull from -it? - -You do your real work in your working tree that has your -primary repository hanging under it as its `.git` subdirectory. -You *could* make that repository accessible remotely and ask -people to pull from it, but in practice that is not the way -things are usually done. A recommended way is to have a public -repository, make it reachable by other people, and when the -changes you made in your primary working tree are in good shape, -update the public repository from it. This is often called -'pushing'. - -[NOTE] -This public repository could further be mirrored, and that is -how Git repositories at `kernel.org` are managed. - -Publishing the changes from your local (private) repository to -your remote (public) repository requires a write privilege on -the remote machine. You need to have an SSH account there to -run a single command, 'git-receive-pack'. - -First, you need to create an empty repository on the remote -machine that will house your public repository. This empty -repository will be populated and be kept up to date by pushing -into it later. Obviously, this repository creation needs to be -done only once. - -[NOTE] -'git push' uses a pair of commands, -'git send-pack' on your local machine, and 'git-receive-pack' -on the remote machine. The communication between the two over -the network internally uses an SSH connection. - -Your private repository's Git directory is usually `.git`, but -your public repository is often named after the project name, -i.e. `<project>.git`. Let's create such a public repository for -project `my-git`. After logging into the remote machine, create -an empty directory: - ------------- -$ mkdir my-git.git ------------- - -Then, make that directory into a Git repository by running -'git init', but this time, since its name is not the usual -`.git`, we do things slightly differently: - ------------- -$ GIT_DIR=my-git.git git init ------------- - -Make sure this directory is available for others you want your -changes to be pulled via the transport of your choice. Also -you need to make sure that you have the 'git-receive-pack' -program on the `$PATH`. - -[NOTE] -Many installations of sshd do not invoke your shell as the login -shell when you directly run programs; what this means is that if -your login shell is 'bash', only `.bashrc` is read and not -`.bash_profile`. As a workaround, make sure `.bashrc` sets up -`$PATH` so that you can run 'git-receive-pack' program. - -[NOTE] -If you plan to publish this repository to be accessed over http, -you should do `mv my-git.git/hooks/post-update.sample -my-git.git/hooks/post-update` at this point. -This makes sure that every time you push into this -repository, `git update-server-info` is run. - -Your "public repository" is now ready to accept your changes. -Come back to the machine you have your private repository. From -there, run this command: - ------------- -$ git push <public-host>:/path/to/my-git.git master ------------- - -This synchronizes your public repository to match the named -branch head (i.e. `master` in this case) and objects reachable -from them in your current repository. - -As a real example, this is how I update my public Git -repository. Kernel.org mirror network takes care of the -propagation to other publicly visible machines: - ------------- -$ git push master.kernel.org:/pub/scm/git/git.git/ ------------- - - -Packing your repository ------------------------ - -Earlier, we saw that one file under `.git/objects/??/` directory -is stored for each Git object you create. This representation -is efficient to create atomically and safely, but -not so convenient to transport over the network. Since Git objects are -immutable once they are created, there is a way to optimize the -storage by "packing them together". The command - ------------- -$ git repack ------------- - -will do it for you. If you followed the tutorial examples, you -would have accumulated about 17 objects in `.git/objects/??/` -directories by now. 'git repack' tells you how many objects it -packed, and stores the packed file in the `.git/objects/pack` -directory. - -[NOTE] -You will see two files, `pack-*.pack` and `pack-*.idx`, -in `.git/objects/pack` directory. They are closely related to -each other, and if you ever copy them by hand to a different -repository for whatever reason, you should make sure you copy -them together. The former holds all the data from the objects -in the pack, and the latter holds the index for random -access. - -If you are paranoid, running 'git verify-pack' command would -detect if you have a corrupt pack, but do not worry too much. -Our programs are always perfect ;-). - -Once you have packed objects, you do not need to leave the -unpacked objects that are contained in the pack file anymore. - ------------- -$ git prune-packed ------------- - -would remove them for you. - -You can try running `find .git/objects -type f` before and after -you run `git prune-packed` if you are curious. Also `git -count-objects` would tell you how many unpacked objects are in -your repository and how much space they are consuming. - -[NOTE] -`git pull` is slightly cumbersome for HTTP transport, as a -packed repository may contain relatively few objects in a -relatively large pack. If you expect many HTTP pulls from your -public repository you might want to repack & prune often, or -never. - -If you run `git repack` again at this point, it will say -"Nothing new to pack.". Once you continue your development and -accumulate the changes, running `git repack` again will create a -new pack, that contains objects created since you packed your -repository the last time. We recommend that you pack your project -soon after the initial import (unless you are starting your -project from scratch), and then run `git repack` every once in a -while, depending on how active your project is. - -When a repository is synchronized via `git push` and `git pull` -objects packed in the source repository are usually stored -unpacked in the destination. -While this allows you to use different packing strategies on -both ends, it also means you may need to repack both -repositories every once in a while. - - -Working with Others -------------------- - -Although Git is a truly distributed system, it is often -convenient to organize your project with an informal hierarchy -of developers. Linux kernel development is run this way. There -is a nice illustration (page 17, "Merges to Mainline") in -https://web.archive.org/web/20120915203609/http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation]. - -It should be stressed that this hierarchy is purely *informal*. -There is nothing fundamental in Git that enforces the "chain of -patch flow" this hierarchy implies. You do not have to pull -from only one remote repository. - -A recommended workflow for a "project lead" goes like this: - -1. Prepare your primary repository on your local machine. Your - work is done there. - -2. Prepare a public repository accessible to others. -+ -If other people are pulling from your repository over dumb -transport protocols (HTTP), you need to keep this repository -'dumb transport friendly'. After `git init`, -`$GIT_DIR/hooks/post-update.sample` copied from the standard templates -would contain a call to 'git update-server-info' -but you need to manually enable the hook with -`mv post-update.sample post-update`. This makes sure -'git update-server-info' keeps the necessary files up to date. - -3. Push into the public repository from your primary - repository. - -4. 'git repack' the public repository. This establishes a big - pack that contains the initial set of objects as the - baseline, and possibly 'git prune' if the transport - used for pulling from your repository supports packed - repositories. - -5. Keep working in your primary repository. Your changes - include modifications of your own, patches you receive via - e-mails, and merges resulting from pulling the "public" - repositories of your "subsystem maintainers". -+ -You can repack this private repository whenever you feel like. - -6. Push your changes to the public repository, and announce it - to the public. - -7. Every once in a while, 'git repack' the public repository. - Go back to step 5. and continue working. - - -A recommended work cycle for a "subsystem maintainer" who works -on that project and has an own "public repository" goes like this: - -1. Prepare your work repository, by running 'git clone' on the public - repository of the "project lead". The URL used for the - initial cloning is stored in the remote.origin.url - configuration variable. - -2. Prepare a public repository accessible to others, just like - the "project lead" person does. - -3. Copy over the packed files from "project lead" public - repository to your public repository, unless the "project - lead" repository lives on the same machine as yours. In the - latter case, you can use `objects/info/alternates` file to - point at the repository you are borrowing from. - -4. Push into the public repository from your primary - repository. Run 'git repack', and possibly 'git prune' if the - transport used for pulling from your repository supports - packed repositories. - -5. Keep working in your primary repository. Your changes - include modifications of your own, patches you receive via - e-mails, and merges resulting from pulling the "public" - repositories of your "project lead" and possibly your - "sub-subsystem maintainers". -+ -You can repack this private repository whenever you feel -like. - -6. Push your changes to your public repository, and ask your - "project lead" and possibly your "sub-subsystem - maintainers" to pull from it. - -7. Every once in a while, 'git repack' the public repository. - Go back to step 5. and continue working. - - -A recommended work cycle for an "individual developer" who does -not have a "public" repository is somewhat different. It goes -like this: - -1. Prepare your work repository, by 'git clone' the public - repository of the "project lead" (or a "subsystem - maintainer", if you work on a subsystem). The URL used for - the initial cloning is stored in the remote.origin.url - configuration variable. - -2. Do your work in your repository on 'master' branch. - -3. Run `git fetch origin` from the public repository of your - upstream every once in a while. This does only the first - half of `git pull` but does not merge. The head of the - public repository is stored in `.git/refs/remotes/origin/master`. - -4. Use `git cherry origin` to see which ones of your patches - were accepted, and/or use `git rebase origin` to port your - unmerged changes forward to the updated upstream. - -5. Use `git format-patch origin` to prepare patches for e-mail - submission to your upstream and send it out. Go back to - step 2. and continue. - - -Working with Others, Shared Repository Style --------------------------------------------- - -If you are coming from a CVS background, the style of cooperation -suggested in the previous section may be new to you. You do not -have to worry. Git supports the "shared public repository" style of -cooperation you are probably more familiar with as well. - -See linkgit:gitcvs-migration[7] for the details. - -Bundling your work together ---------------------------- - -It is likely that you will be working on more than one thing at -a time. It is easy to manage those more-or-less independent tasks -using branches with Git. - -We have already seen how branches work previously, -with "fun and work" example using two branches. The idea is the -same if there are more than two branches. Let's say you started -out from "master" head, and have some new code in the "master" -branch, and two independent fixes in the "commit-fix" and -"diff-fix" branches: - ------------- -$ git show-branch -! [commit-fix] Fix commit message normalization. - ! [diff-fix] Fix rename detection. - * [master] Release candidate #1 ---- - + [diff-fix] Fix rename detection. - + [diff-fix~1] Better common substring algorithm. -+ [commit-fix] Fix commit message normalization. - * [master] Release candidate #1 -++* [diff-fix~2] Pretty-print messages. ------------- - -Both fixes are tested well, and at this point, you want to merge -in both of them. You could merge in 'diff-fix' first and then -'commit-fix' next, like this: - ------------- -$ git merge -m "Merge fix in diff-fix" diff-fix -$ git merge -m "Merge fix in commit-fix" commit-fix ------------- - -Which would result in: - ------------- -$ git show-branch -! [commit-fix] Fix commit message normalization. - ! [diff-fix] Fix rename detection. - * [master] Merge fix in commit-fix ---- - - [master] Merge fix in commit-fix -+ * [commit-fix] Fix commit message normalization. - - [master~1] Merge fix in diff-fix - +* [diff-fix] Fix rename detection. - +* [diff-fix~1] Better common substring algorithm. - * [master~2] Release candidate #1 -++* [master~3] Pretty-print messages. ------------- - -However, there is no particular reason to merge in one branch -first and the other next, when what you have are a set of truly -independent changes (if the order mattered, then they are not -independent by definition). You could instead merge those two -branches into the current branch at once. First let's undo what -we just did and start over. We would want to get the master -branch before these two merges by resetting it to 'master~2': - ------------- -$ git reset --hard master~2 ------------- - -You can make sure `git show-branch` matches the state before -those two 'git merge' you just did. Then, instead of running -two 'git merge' commands in a row, you would merge these two -branch heads (this is known as 'making an Octopus'): - ------------- -$ git merge commit-fix diff-fix -$ git show-branch -! [commit-fix] Fix commit message normalization. - ! [diff-fix] Fix rename detection. - * [master] Octopus merge of branches 'diff-fix' and 'commit-fix' ---- - - [master] Octopus merge of branches 'diff-fix' and 'commit-fix' -+ * [commit-fix] Fix commit message normalization. - +* [diff-fix] Fix rename detection. - +* [diff-fix~1] Better common substring algorithm. - * [master~1] Release candidate #1 -++* [master~2] Pretty-print messages. ------------- - -Note that you should not do Octopus just because you can. An octopus -is a valid thing to do and often makes it easier to view the -commit history if you are merging more than two independent -changes at the same time. However, if you have merge conflicts -with any of the branches you are merging in and need to hand -resolve, that is an indication that the development happened in -those branches were not independent after all, and you should -merge two at a time, documenting how you resolved the conflicts, -and the reason why you preferred changes made in one side over -the other. Otherwise it would make the project history harder -to follow, not easier. - -SEE ALSO --------- -linkgit:gittutorial[7], -linkgit:gittutorial-2[7], -linkgit:gitcvs-migration[7], -linkgit:git-help[1], -linkgit:giteveryday[7], -link:user-manual.html[The Git User's Manual] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitcredentials.txt b/third_party/git/Documentation/gitcredentials.txt deleted file mode 100644 index adc759612d..0000000000 --- a/third_party/git/Documentation/gitcredentials.txt +++ /dev/null @@ -1,194 +0,0 @@ -gitcredentials(7) -================= - -NAME ----- -gitcredentials - providing usernames and passwords to Git - -SYNOPSIS --------- ------------------- -git config credential.https://example.com.username myusername -git config credential.helper "$helper $options" ------------------- - -DESCRIPTION ------------ - -Git will sometimes need credentials from the user in order to perform -operations; for example, it may need to ask for a username and password -in order to access a remote repository over HTTP. This manual describes -the mechanisms Git uses to request these credentials, as well as some -features to avoid inputting these credentials repeatedly. - -REQUESTING CREDENTIALS ----------------------- - -Without any credential helpers defined, Git will try the following -strategies to ask the user for usernames and passwords: - -1. If the `GIT_ASKPASS` environment variable is set, the program - specified by the variable is invoked. A suitable prompt is provided - to the program on the command line, and the user's input is read - from its standard output. - -2. Otherwise, if the `core.askPass` configuration variable is set, its - value is used as above. - -3. Otherwise, if the `SSH_ASKPASS` environment variable is set, its - value is used as above. - -4. Otherwise, the user is prompted on the terminal. - -AVOIDING REPETITION -------------------- - -It can be cumbersome to input the same credentials over and over. Git -provides two methods to reduce this annoyance: - -1. Static configuration of usernames for a given authentication context. - -2. Credential helpers to cache or store passwords, or to interact with - a system password wallet or keychain. - -The first is simple and appropriate if you do not have secure storage available -for a password. It is generally configured by adding this to your config: - ---------------------------------------- -[credential "https://example.com"] - username = me ---------------------------------------- - -Credential helpers, on the other hand, are external programs from which Git can -request both usernames and passwords; they typically interface with secure -storage provided by the OS or other programs. - -To use a helper, you must first select one to use. Git currently -includes the following helpers: - -cache:: - - Cache credentials in memory for a short period of time. See - linkgit:git-credential-cache[1] for details. - -store:: - - Store credentials indefinitely on disk. See - linkgit:git-credential-store[1] for details. - -You may also have third-party helpers installed; search for -`credential-*` in the output of `git help -a`, and consult the -documentation of individual helpers. Once you have selected a helper, -you can tell Git to use it by putting its name into the -credential.helper variable. - -1. Find a helper. -+ -------------------------------------------- -$ git help -a | grep credential- -credential-foo -------------------------------------------- - -2. Read its description. -+ -------------------------------------------- -$ git help credential-foo -------------------------------------------- - -3. Tell Git to use it. -+ -------------------------------------------- -$ git config --global credential.helper foo -------------------------------------------- - - -CREDENTIAL CONTEXTS -------------------- - -Git considers each credential to have a context defined by a URL. This context -is used to look up context-specific configuration, and is passed to any -helpers, which may use it as an index into secure storage. - -For instance, imagine we are accessing `https://example.com/foo.git`. When Git -looks into a config file to see if a section matches this context, it will -consider the two a match if the context is a more-specific subset of the -pattern in the config file. For example, if you have this in your config file: - --------------------------------------- -[credential "https://example.com"] - username = foo --------------------------------------- - -then we will match: both protocols are the same, both hosts are the same, and -the "pattern" URL does not care about the path component at all. However, this -context would not match: - --------------------------------------- -[credential "https://kernel.org"] - username = foo --------------------------------------- - -because the hostnames differ. Nor would it match `foo.example.com`; Git -compares hostnames exactly, without considering whether two hosts are part of -the same domain. Likewise, a config entry for `http://example.com` would not -match: Git compares the protocols exactly. - -If the "pattern" URL does include a path component, then this too must match -exactly: the context `https://example.com/bar/baz.git` will match a config -entry for `https://example.com/bar/baz.git` (in addition to matching the config -entry for `https://example.com`) but will not match a config entry for -`https://example.com/bar`. - - -CONFIGURATION OPTIONS ---------------------- - -Options for a credential context can be configured either in -`credential.*` (which applies to all credentials), or -`credential.<url>.*`, where <url> matches the context as described -above. - -The following options are available in either location: - -helper:: - - The name of an external credential helper, and any associated options. - If the helper name is not an absolute path, then the string `git - credential-` is prepended. The resulting string is executed by the - shell (so, for example, setting this to `foo --option=bar` will execute - `git credential-foo --option=bar` via the shell. See the manual of - specific helpers for examples of their use. -+ -If there are multiple instances of the `credential.helper` configuration -variable, each helper will be tried in turn, and may provide a username, -password, or nothing. Once Git has acquired both a username and a -password, no more helpers will be tried. -+ -If `credential.helper` is configured to the empty string, this resets -the helper list to empty (so you may override a helper set by a -lower-priority config file by configuring the empty-string helper, -followed by whatever set of helpers you would like). - -username:: - - A default username, if one is not provided in the URL. - -useHttpPath:: - - By default, Git does not consider the "path" component of an http URL - to be worth matching via external helpers. This means that a credential - stored for `https://example.com/foo.git` will also be used for - `https://example.com/bar.git`. If you do want to distinguish these - cases, set this option to `true`. - - -CUSTOM HELPERS --------------- - -You can write your own custom helpers to interface with any system in -which you keep credentials. See the documentation for Git's -link:technical/api-credentials.html[credentials API] for details. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitcvs-migration.txt b/third_party/git/Documentation/gitcvs-migration.txt deleted file mode 100644 index 1cd1283d0f..0000000000 --- a/third_party/git/Documentation/gitcvs-migration.txt +++ /dev/null @@ -1,206 +0,0 @@ -gitcvs-migration(7) -=================== - -NAME ----- -gitcvs-migration - Git for CVS users - -SYNOPSIS --------- -[verse] -'git cvsimport' * - -DESCRIPTION ------------ - -Git differs from CVS in that every working tree contains a repository with -a full copy of the project history, and no repository is inherently more -important than any other. However, you can emulate the CVS model by -designating a single shared repository which people can synchronize with; -this document explains how to do that. - -Some basic familiarity with Git is required. Having gone through -linkgit:gittutorial[7] and -linkgit:gitglossary[7] should be sufficient. - -Developing against a shared repository --------------------------------------- - -Suppose a shared repository is set up in /pub/repo.git on the host -foo.com. Then as an individual committer you can clone the shared -repository over ssh with: - ------------------------------------------------- -$ git clone foo.com:/pub/repo.git/ my-project -$ cd my-project ------------------------------------------------- - -and hack away. The equivalent of 'cvs update' is - ------------------------------------------------- -$ git pull origin ------------------------------------------------- - -which merges in any work that others might have done since the clone -operation. If there are uncommitted changes in your working tree, commit -them first before running git pull. - -[NOTE] -================================ -The 'pull' command knows where to get updates from because of certain -configuration variables that were set by the first 'git clone' -command; see `git config -l` and the linkgit:git-config[1] man -page for details. -================================ - -You can update the shared repository with your changes by first committing -your changes, and then using the 'git push' command: - ------------------------------------------------- -$ git push origin master ------------------------------------------------- - -to "push" those commits to the shared repository. If someone else has -updated the repository more recently, 'git push', like 'cvs commit', will -complain, in which case you must pull any changes before attempting the -push again. - -In the 'git push' command above we specify the name of the remote branch -to update (`master`). If we leave that out, 'git push' tries to update -any branches in the remote repository that have the same name as a branch -in the local repository. So the last 'push' can be done with either of: - ------------- -$ git push origin -$ git push foo.com:/pub/project.git/ ------------- - -as long as the shared repository does not have any branches -other than `master`. - -Setting Up a Shared Repository ------------------------------- - -We assume you have already created a Git repository for your project, -possibly created from scratch or from a tarball (see -linkgit:gittutorial[7]), or imported from an already existing CVS -repository (see the next section). - -Assume your existing repo is at /home/alice/myproject. Create a new "bare" -repository (a repository without a working tree) and fetch your project into -it: - ------------------------------------------------- -$ mkdir /pub/my-repo.git -$ cd /pub/my-repo.git -$ git --bare init --shared -$ git --bare fetch /home/alice/myproject master:master ------------------------------------------------- - -Next, give every team member read/write access to this repository. One -easy way to do this is to give all the team members ssh access to the -machine where the repository is hosted. If you don't want to give them a -full shell on the machine, there is a restricted shell which only allows -users to do Git pushes and pulls; see linkgit:git-shell[1]. - -Put all the committers in the same group, and make the repository -writable by that group: - ------------------------------------------------- -$ chgrp -R $group /pub/my-repo.git ------------------------------------------------- - -Make sure committers have a umask of at most 027, so that the directories -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 -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]: - -------------------------------------------- -$ git cvsimport -C <destination> <module> -------------------------------------------- - -This puts a Git archive of the named CVS module in the directory -<destination>, which will be created if necessary. - -The import checks out from CVS every revision of every file. Reportedly -cvsimport can average some twenty revisions per second, so for a -medium-sized project this should not take more than a couple of minutes. -Larger projects or remote repositories may take longer. - -The main trunk is stored in the Git branch named `origin`, and additional -CVS branches are stored in Git branches with the same names. The most -recent version of the main trunk is also left checked out on the `master` -branch, so you can start adding your own changes right away. - -The import is incremental, so if you call it again next month it will -fetch any CVS updates that have been made in the meantime. For this to -work, you must not modify the imported branches; instead, create new -branches for your own changes, and merge in the imported branches as -necessary. - -If you want a shared repository, you will need to make a bare clone -of the imported directory, as described above. Then treat the imported -directory as another development clone for purposes of merging -incremental imports. - -Advanced Shared Repository Management -------------------------------------- - -Git allows you to specify scripts called "hooks" to be run at certain -points. You can use these, for example, to send all commits to the shared -repository to a mailing list. See linkgit:githooks[5]. - -You can enforce finer grained permissions using update hooks. See -link:howto/update-hook-example.html[Controlling access to branches using -update hooks]. - -Providing CVS Access to a Git Repository ----------------------------------------- - -It is also possible to provide true CVS access to a Git repository, so -that developers can still use CVS; see linkgit:git-cvsserver[1] for -details. - -Alternative Development Models ------------------------------- - -CVS users are accustomed to giving a group of developers commit access to -a common repository. As we've seen, this is also possible with Git. -However, the distributed nature of Git allows other development models, -and you may want to first consider whether one of them might be a better -fit for your project. - -For example, you can choose a single person to maintain the project's -primary public repository. Other developers then clone this repository -and each work in their own clone. When they have a series of changes that -they're happy with, they ask the maintainer to pull from the branch -containing the changes. The maintainer reviews their changes and pulls -them into the primary repository, which other developers pull from as -necessary to stay coordinated. The Linux kernel and other projects use -variants of this model. - -With a small group, developers may just pull changes from each other's -repositories without the need for a central maintainer. - -SEE ALSO --------- -linkgit:gittutorial[7], -linkgit:gittutorial-2[7], -linkgit:gitcore-tutorial[7], -linkgit:gitglossary[7], -linkgit:giteveryday[7], -link:user-manual.html[The Git User's Manual] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitdiffcore.txt b/third_party/git/Documentation/gitdiffcore.txt deleted file mode 100644 index c970d9fe43..0000000000 --- a/third_party/git/Documentation/gitdiffcore.txt +++ /dev/null @@ -1,292 +0,0 @@ -gitdiffcore(7) -============== - -NAME ----- -gitdiffcore - Tweaking diff output - -SYNOPSIS --------- -[verse] -'git diff' * - -DESCRIPTION ------------ - -The diff commands 'git diff-index', 'git diff-files', and 'git diff-tree' -can be told to manipulate differences they find in -unconventional ways before showing 'diff' output. The manipulation -is collectively called "diffcore transformation". This short note -describes what they are and how to use them to produce 'diff' output -that is easier to understand than the conventional kind. - - -The chain of operation ----------------------- - -The 'git diff-{asterisk}' family works by first comparing two sets of -files: - - - 'git diff-index' compares contents of a "tree" object and the - working directory (when `--cached` flag is not used) or a - "tree" object and the index file (when `--cached` flag is - used); - - - 'git diff-files' compares contents of the index file and the - working directory; - - - 'git diff-tree' compares contents of two "tree" objects; - -In all of these cases, the commands themselves first optionally limit -the two sets of files by any pathspecs given on their command-lines, -and compare corresponding paths in the two resulting sets of files. - -The pathspecs are used to limit the world diff operates in. They remove -the filepairs outside the specified sets of pathnames. E.g. If the -input set of filepairs included: - ------------------------------------------------- -:100644 100644 bcd1234... 0123456... M junkfile ------------------------------------------------- - -but the command invocation was `git diff-files myfile`, then the -junkfile entry would be removed from the list because only "myfile" -is under consideration. - -The result of comparison is passed from these commands to what is -internally called "diffcore", in a format similar to what is output -when the -p option is not used. E.g. - ------------------------------------------------- -in-place edit :100644 100644 bcd1234... 0123456... M file0 -create :000000 100644 0000000... 1234567... A file4 -delete :100644 000000 1234567... 0000000... D file5 -unmerged :000000 000000 0000000... 0000000... U file6 ------------------------------------------------- - -The diffcore mechanism is fed a list of such comparison results -(each of which is called "filepair", although at this point each -of them talks about a single file), and transforms such a list -into another list. There are currently 5 such transformations: - -- diffcore-break -- diffcore-rename -- diffcore-merge-broken -- diffcore-pickaxe -- diffcore-order - -These are applied in sequence. The set of filepairs 'git diff-{asterisk}' -commands find are used as the input to diffcore-break, and -the output from diffcore-break is used as the input to the -next transformation. The final result is then passed to the -output routine and generates either diff-raw format (see Output -format sections of the manual for 'git diff-{asterisk}' commands) or -diff-patch format. - - -diffcore-break: For Splitting Up Complete Rewrites --------------------------------------------------- - -The second transformation in the chain is diffcore-break, and is -controlled by the -B option to the 'git diff-{asterisk}' commands. This is -used to detect a filepair that represents "complete rewrite" and -break such filepair into two filepairs that represent delete and -create. E.g. If the input contained this filepair: - ------------------------------------------------- -:100644 100644 bcd1234... 0123456... M file0 ------------------------------------------------- - -and if it detects that the file "file0" is completely rewritten, -it changes it to: - ------------------------------------------------- -:100644 000000 bcd1234... 0000000... D file0 -:000000 100644 0000000... 0123456... A file0 ------------------------------------------------- - -For the purpose of breaking a filepair, diffcore-break examines -the extent of changes between the contents of the files before -and after modification (i.e. the contents that have "bcd1234..." -and "0123456..." as their SHA-1 content ID, in the above -example). The amount of deletion of original contents and -insertion of new material are added together, and if it exceeds -the "break score", the filepair is broken into two. The break -score defaults to 50% of the size of the smaller of the original -and the result (i.e. if the edit shrinks the file, the size of -the result is used; if the edit lengthens the file, the size of -the original is used), and can be customized by giving a number -after "-B" option (e.g. "-B75" to tell it to use 75%). - - -diffcore-rename: For Detecting Renames and Copies -------------------------------------------------- - -This transformation is used to detect renames and copies, and is -controlled by the -M option (to detect renames) and the -C option -(to detect copies as well) to the 'git diff-{asterisk}' commands. If the -input contained these filepairs: - ------------------------------------------------- -:100644 000000 0123456... 0000000... D fileX -:000000 100644 0000000... 0123456... A file0 ------------------------------------------------- - -and the contents of the deleted file fileX is similar enough to -the contents of the created file file0, then rename detection -merges these filepairs and creates: - ------------------------------------------------- -:100644 100644 0123456... 0123456... R100 fileX file0 ------------------------------------------------- - -When the "-C" option is used, the original contents of modified files, -and deleted files (and also unmodified files, if the -"--find-copies-harder" option is used) are considered as candidates -of the source files in rename/copy operation. If the input were like -these filepairs, that talk about a modified file fileY and a newly -created file file0: - ------------------------------------------------- -:100644 100644 0123456... 1234567... M fileY -:000000 100644 0000000... bcd3456... A file0 ------------------------------------------------- - -the original contents of fileY and the resulting contents of -file0 are compared, and if they are similar enough, they are -changed to: - ------------------------------------------------- -:100644 100644 0123456... 1234567... M fileY -:100644 100644 0123456... bcd3456... C100 fileY file0 ------------------------------------------------- - -In both rename and copy detection, the same "extent of changes" -algorithm used in diffcore-break is used to determine if two -files are "similar enough", and can be customized to use -a similarity score different from the default of 50% by giving a -number after the "-M" or "-C" option (e.g. "-M8" to tell it to use -8/10 = 80%). - -Note. When the "-C" option is used with `--find-copies-harder` -option, 'git diff-{asterisk}' commands feed unmodified filepairs to -diffcore mechanism as well as modified ones. This lets the copy -detector consider unmodified files as copy source candidates at -the expense of making it slower. Without `--find-copies-harder`, -'git diff-{asterisk}' commands can detect copies only if the file that was -copied happened to have been modified in the same changeset. - - -diffcore-merge-broken: For Putting Complete Rewrites Back Together ------------------------------------------------------------------- - -This transformation is used to merge filepairs broken by -diffcore-break, and not transformed into rename/copy by -diffcore-rename, back into a single modification. This always -runs when diffcore-break is used. - -For the purpose of merging broken filepairs back, it uses a -different "extent of changes" computation from the ones used by -diffcore-break and diffcore-rename. It counts only the deletion -from the original, and does not count insertion. If you removed -only 10 lines from a 100-line document, even if you added 910 -new lines to make a new 1000-line document, you did not do a -complete rewrite. diffcore-break breaks such a case in order to -help diffcore-rename to consider such filepairs as candidate of -rename/copy detection, but if filepairs broken that way were not -matched with other filepairs to create rename/copy, then this -transformation merges them back into the original -"modification". - -The "extent of changes" parameter can be tweaked from the -default 80% (that is, unless more than 80% of the original -material is deleted, the broken pairs are merged back into a -single modification) by giving a second number to -B option, -like these: - -* -B50/60 (give 50% "break score" to diffcore-break, use 60% - for diffcore-merge-broken). - -* -B/60 (the same as above, since diffcore-break defaults to 50%). - -Note that earlier implementation left a broken pair as a separate -creation and deletion patches. This was an unnecessary hack and -the latest implementation always merges all the broken pairs -back into modifications, but the resulting patch output is -formatted differently for easier review in case of such -a complete rewrite by showing the entire contents of old version -prefixed with '-', followed by the entire contents of new -version prefixed with '+'. - - -diffcore-pickaxe: For Detecting Addition/Deletion of Specified String ---------------------------------------------------------------------- - -This transformation limits the set of filepairs to those that change -specified strings between the preimage and the postimage in a certain -way. -S<block of text> and -G<regular expression> options are used to -specify different ways these strings are sought. - -"-S<block of text>" detects filepairs whose preimage and postimage -have different number of occurrences of the specified block of text. -By definition, it will not detect in-file moves. Also, when a -changeset moves a file wholesale without affecting the interesting -string, diffcore-rename kicks in as usual, and `-S` omits the filepair -(since the number of occurrences of that string didn't change in that -rename-detected filepair). When used with `--pickaxe-regex`, treat -the <block of text> as an extended POSIX regular expression to match, -instead of a literal string. - -"-G<regular expression>" (mnemonic: grep) detects filepairs whose -textual diff has an added or a deleted line that matches the given -regular expression. This means that it will detect in-file (or what -rename-detection considers the same file) moves, which is noise. The -implementation runs diff twice and greps, and this can be quite -expensive. To speed things up binary files without textconv filters -will be ignored. - -When `-S` or `-G` are used without `--pickaxe-all`, only filepairs -that match their respective criterion are kept in the output. When -`--pickaxe-all` is used, if even one filepair matches their respective -criterion in a changeset, the entire changeset is kept. This behavior -is designed to make reviewing changes in the context of the whole -changeset easier. - -diffcore-order: For Sorting the Output Based on Filenames ---------------------------------------------------------- - -This is used to reorder the filepairs according to the user's -(or project's) taste, and is controlled by the -O option to the -'git diff-{asterisk}' commands. - -This takes a text file each of whose lines is a shell glob -pattern. Filepairs that match a glob pattern on an earlier line -in the file are output before ones that match a later line, and -filepairs that do not match any glob pattern are output last. - -As an example, a typical orderfile for the core Git probably -would look like this: - ------------------------------------------------- -README -Makefile -Documentation -*.h -*.c -t ------------------------------------------------- - -SEE ALSO --------- -linkgit:git-diff[1], -linkgit:git-diff-files[1], -linkgit:git-diff-index[1], -linkgit:git-diff-tree[1], -linkgit:git-format-patch[1], -linkgit:git-log[1], -linkgit:gitglossary[7], -link:user-manual.html[The Git User's Manual] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/giteveryday.txt b/third_party/git/Documentation/giteveryday.txt deleted file mode 100644 index 1bd919f92b..0000000000 --- a/third_party/git/Documentation/giteveryday.txt +++ /dev/null @@ -1,455 +0,0 @@ -giteveryday(7) -============== - -NAME ----- -giteveryday - A useful minimum set of commands for Everyday Git - -SYNOPSIS --------- - -Everyday Git With 20 Commands Or So - -DESCRIPTION ------------ - -Git users can broadly be grouped into four categories for the purposes of -describing here a small set of useful command for everyday Git. - -* <<STANDALONE,Individual Developer (Standalone)>> commands are essential - for anybody who makes a commit, even for somebody who works alone. - -* If you work with other people, you will need commands listed in - the <<PARTICIPANT,Individual Developer (Participant)>> section as well. - -* People who play the <<INTEGRATOR,Integrator>> role need to learn some - more commands in addition to the above. - -* <<ADMINISTRATION,Repository Administration>> commands are for system - administrators who are responsible for the care and feeding - of Git repositories. - - -Individual Developer (Standalone)[[STANDALONE]] ------------------------------------------------ - -A standalone individual developer does not exchange patches with -other people, and works alone in a single repository, using the -following commands. - - * linkgit:git-init[1] to create a new repository. - - * linkgit:git-log[1] to see what happened. - - * linkgit:git-switch[1] and linkgit:git-branch[1] to switch - branches. - - * linkgit:git-add[1] to manage the index file. - - * linkgit:git-diff[1] and linkgit:git-status[1] to see what - you are in the middle of doing. - - * linkgit:git-commit[1] to advance the current branch. - - * linkgit:git-restore[1] to undo changes. - - * linkgit:git-merge[1] to merge between local branches. - - * linkgit:git-rebase[1] to maintain topic branches. - - * linkgit:git-tag[1] to mark a known point. - -Examples -~~~~~~~~ - -Use a tarball as a starting point for a new repository.:: -+ ------------- -$ tar zxf frotz.tar.gz -$ cd frotz -$ git init -$ git add . <1> -$ git commit -m "import of frotz source tree." -$ git tag v2.43 <2> ------------- -+ -<1> add everything under the current directory. -<2> make a lightweight, unannotated tag. - -Create a topic branch and develop.:: -+ ------------- -$ git switch -c alsa-audio <1> -$ edit/compile/test -$ git restore curses/ux_audio_oss.c <2> -$ git add curses/ux_audio_alsa.c <3> -$ edit/compile/test -$ git diff HEAD <4> -$ git commit -a -s <5> -$ edit/compile/test -$ git diff HEAD^ <6> -$ git commit -a --amend <7> -$ git switch master <8> -$ git merge alsa-audio <9> -$ git log --since='3 days ago' <10> -$ git log v2.43.. curses/ <11> ------------- -+ -<1> create a new topic branch. -<2> revert your botched changes in `curses/ux_audio_oss.c`. -<3> you need to tell Git if you added a new file; removal and -modification will be caught if you do `git commit -a` later. -<4> to see what changes you are committing. -<5> commit everything, as you have tested, with your sign-off. -<6> look at all your changes including the previous commit. -<7> amend the previous commit, adding all your new changes, -using your original message. -<8> switch to the master branch. -<9> merge a topic branch into your master branch. -<10> review commit logs; other forms to limit output can be -combined and include `-10` (to show up to 10 commits), -`--until=2005-12-10`, etc. -<11> view only the changes that touch what's in `curses/` -directory, since `v2.43` tag. - - -Individual Developer (Participant)[[PARTICIPANT]] -------------------------------------------------- - -A developer working as a participant in a group project needs to -learn how to communicate with others, and uses these commands in -addition to the ones needed by a standalone developer. - - * linkgit:git-clone[1] from the upstream to prime your local - repository. - - * linkgit:git-pull[1] and linkgit:git-fetch[1] from "origin" - to keep up-to-date with the upstream. - - * linkgit:git-push[1] to shared repository, if you adopt CVS - style shared repository workflow. - - * linkgit:git-format-patch[1] to prepare e-mail submission, if - you adopt Linux kernel-style public forum workflow. - - * linkgit:git-send-email[1] to send your e-mail submission without - corruption by your MUA. - - * linkgit:git-request-pull[1] to create a summary of changes - for your upstream to pull. - - -Examples -~~~~~~~~ - -Clone the upstream and work on it. Feed changes to upstream.:: -+ ------------- -$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6 -$ cd my2.6 -$ git switch -c mine master <1> -$ edit/compile/test; git commit -a -s <2> -$ git format-patch master <3> -$ git send-email --to="person <email@example.com>" 00*.patch <4> -$ git switch master <5> -$ git pull <6> -$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <7> -$ git ls-remote --heads http://git.kernel.org/.../jgarzik/libata-dev.git <8> -$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <9> -$ git reset --hard ORIG_HEAD <10> -$ git gc <11> ------------- -+ -<1> checkout a new branch `mine` from master. -<2> repeat as needed. -<3> extract patches from your branch, relative to master, -<4> and email them. -<5> return to `master`, ready to see what's new -<6> `git pull` fetches from `origin` by default and merges into the -current branch. -<7> immediately after pulling, look at the changes done upstream -since last time we checked, only in the -area we are interested in. -<8> check the branch names in an external repository (if not known). -<9> fetch from a specific branch `ALL` from a specific repository -and merge it. -<10> revert the pull. -<11> garbage collect leftover objects from reverted pull. - - -Push into another repository.:: -+ ------------- -satellite$ git clone mothership:frotz frotz <1> -satellite$ cd frotz -satellite$ git config --get-regexp '^(remote|branch)\.' <2> -remote.origin.url mothership:frotz -remote.origin.fetch refs/heads/*:refs/remotes/origin/* -branch.master.remote origin -branch.master.merge refs/heads/master -satellite$ git config remote.origin.push \ - +refs/heads/*:refs/remotes/satellite/* <3> -satellite$ edit/compile/test/commit -satellite$ git push origin <4> - -mothership$ cd frotz -mothership$ git switch master -mothership$ git merge satellite/master <5> ------------- -+ -<1> mothership machine has a frotz repository under your home -directory; clone from it to start a repository on the satellite -machine. -<2> clone sets these configuration variables by default. -It arranges `git pull` to fetch and store the branches of mothership -machine to local `remotes/origin/*` remote-tracking branches. -<3> arrange `git push` to push all local branches to -their corresponding branch of the mothership machine. -<4> push will stash all our work away on `remotes/satellite/*` -remote-tracking branches on the mothership machine. You could use this -as a back-up method. Likewise, you can pretend that mothership -"fetched" from you (useful when access is one sided). -<5> on mothership machine, merge the work done on the satellite -machine into the master branch. - -Branch off of a specific tag.:: -+ ------------- -$ git switch -c private2.6.14 v2.6.14 <1> -$ edit/compile/test; git commit -a -$ git checkout master -$ git cherry-pick v2.6.14..private2.6.14 <2> ------------- -+ -<1> create a private branch based on a well known (but somewhat behind) -tag. -<2> forward port all changes in `private2.6.14` branch to `master` branch -without a formal "merging". Or longhand + -`git format-patch -k -m --stdout v2.6.14..private2.6.14 | - git am -3 -k` - -An alternate participant submission mechanism is using the -`git request-pull` or pull-request mechanisms (e.g as used on -GitHub (www.github.com) to notify your upstream of your -contribution. - -Integrator[[INTEGRATOR]] ------------------------- - -A fairly central person acting as the integrator in a group -project receives changes made by others, reviews and integrates -them and publishes the result for others to use, using these -commands in addition to the ones needed by participants. - -This section can also be used by those who respond to `git -request-pull` or pull-request on GitHub (www.github.com) to -integrate the work of others into their history. A sub-area -lieutenant for a repository will act both as a participant and -as an integrator. - - - * linkgit:git-am[1] to apply patches e-mailed in from your - contributors. - - * linkgit:git-pull[1] to merge from your trusted lieutenants. - - * linkgit:git-format-patch[1] to prepare and send suggested - alternative to contributors. - - * linkgit:git-revert[1] to undo botched commits. - - * linkgit:git-push[1] to publish the bleeding edge. - - -Examples -~~~~~~~~ - -A typical integrator's Git day.:: -+ ------------- -$ git status <1> -$ git branch --no-merged master <2> -$ mailx <3> -& s 2 3 4 5 ./+to-apply -& s 7 8 ./+hold-linus -& q -$ git switch -c topic/one master -$ git am -3 -i -s ./+to-apply <4> -$ compile/test -$ git switch -c hold/linus && git am -3 -i -s ./+hold-linus <5> -$ git switch topic/one && git rebase master <6> -$ git switch -C pu next <7> -$ git merge topic/one topic/two && git merge hold/linus <8> -$ git switch maint -$ git cherry-pick master~4 <9> -$ compile/test -$ git tag -s -m "GIT 0.99.9x" v0.99.9x <10> -$ git fetch ko && for branch in master maint next pu <11> - do - git show-branch ko/$branch $branch <12> - done -$ git push --follow-tags ko <13> ------------- -+ -<1> see what you were in the middle of doing, if anything. -<2> see which branches haven't been merged into `master` yet. -Likewise for any other integration branches e.g. `maint`, `next` -and `pu` (potential updates). -<3> read mails, save ones that are applicable, and save others -that are not quite ready (other mail readers are available). -<4> apply them, interactively, with your sign-offs. -<5> create topic branch as needed and apply, again with sign-offs. -<6> rebase internal topic branch that has not been merged to the -master or exposed as a part of a stable branch. -<7> restart `pu` every time from the next. -<8> and bundle topic branches still cooking. -<9> backport a critical fix. -<10> create a signed tag. -<11> make sure master was not accidentally rewound beyond that -already pushed out. -<12> In the output from `git show-branch`, `master` should have -everything `ko/master` has, and `next` should have -everything `ko/next` has, etc. -<13> push out the bleeding edge, together with new tags that point -into the pushed history. - -In this example, the `ko` shorthand points at the Git maintainer's -repository at kernel.org, and looks like this: - ------------- -(in .git/config) -[remote "ko"] - url = kernel.org:/pub/scm/git/git.git - fetch = refs/heads/*:refs/remotes/ko/* - push = refs/heads/master - push = refs/heads/next - push = +refs/heads/pu - push = refs/heads/maint ------------- - - -Repository Administration[[ADMINISTRATION]] -------------------------------------------- - -A repository administrator uses the following tools to set up -and maintain access to the repository by developers. - - * linkgit:git-daemon[1] to allow anonymous download from - repository. - - * linkgit:git-shell[1] can be used as a 'restricted login shell' - for shared central repository users. - - * linkgit:git-http-backend[1] provides a server side implementation - of Git-over-HTTP ("Smart http") allowing both fetch and push services. - - * linkgit:gitweb[1] provides a web front-end to Git repositories, - which can be set-up using the linkgit:git-instaweb[1] script. - -link:howto/update-hook-example.html[update hook howto] has a good -example of managing a shared central repository. - -In addition there are a number of other widely deployed hosting, browsing -and reviewing solutions such as: - - * gitolite, gerrit code review, cgit and others. - -Examples -~~~~~~~~ -We assume the following in /etc/services:: -+ ------------- -$ grep 9418 /etc/services -git 9418/tcp # Git Version Control System ------------- - -Run git-daemon to serve /pub/scm from inetd.:: -+ ------------- -$ grep git /etc/inetd.conf -git stream tcp nowait nobody \ - /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm ------------- -+ -The actual configuration line should be on one line. - -Run git-daemon to serve /pub/scm from xinetd.:: -+ ------------- -$ cat /etc/xinetd.d/git-daemon -# default: off -# description: The Git server offers access to Git repositories -service git -{ - disable = no - type = UNLISTED - port = 9418 - socket_type = stream - wait = no - user = nobody - server = /usr/bin/git-daemon - server_args = --inetd --export-all --base-path=/pub/scm - log_on_failure += USERID -} ------------- -+ -Check your xinetd(8) documentation and setup, this is from a Fedora system. -Others might be different. - -Give push/pull only access to developers using git-over-ssh.:: - -e.g. those using: -`$ git push/pull ssh://host.xz/pub/scm/project` -+ ------------- -$ grep git /etc/passwd <1> -alice:x:1000:1000::/home/alice:/usr/bin/git-shell -bob:x:1001:1001::/home/bob:/usr/bin/git-shell -cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell -david:x:1003:1003::/home/david:/usr/bin/git-shell -$ grep git /etc/shells <2> -/usr/bin/git-shell ------------- -+ -<1> log-in shell is set to /usr/bin/git-shell, which does not -allow anything but `git push` and `git pull`. The users require -ssh access to the machine. -<2> in many distributions /etc/shells needs to list what is used -as the login shell. - -CVS-style shared repository.:: -+ ------------- -$ grep git /etc/group <1> -git:x:9418:alice,bob,cindy,david -$ cd /home/devo.git -$ ls -l <2> - lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD -> refs/heads/master - drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches - -rw-rw-r-- 1 david git 84 Dec 4 22:40 config - -rw-rw-r-- 1 david git 58 Dec 4 22:40 description - drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks - -rw-rw-r-- 1 david git 37504 Dec 4 22:40 index - drwxrwsr-x 2 david git 4096 Dec 4 22:40 info - drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects - drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs - drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes -$ ls -l hooks/update <3> - -r-xr-xr-x 1 david git 3536 Dec 4 22:40 update -$ cat info/allowed-users <4> -refs/heads/master alice\|cindy -refs/heads/doc-update bob -refs/tags/v[0-9]* david ------------- -+ -<1> place the developers into the same git group. -<2> and make the shared repository writable by the group. -<3> use update-hook example by Carl from Documentation/howto/ -for branch policy control. -<4> alice and cindy can push into master, only bob can push into doc-update. -david is the release manager and is the only person who can -create and push version tags. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitglossary.txt b/third_party/git/Documentation/gitglossary.txt deleted file mode 100644 index 571f640f5c..0000000000 --- a/third_party/git/Documentation/gitglossary.txt +++ /dev/null @@ -1,27 +0,0 @@ -gitglossary(7) -============== - -NAME ----- -gitglossary - A Git Glossary - -SYNOPSIS --------- -* - -DESCRIPTION ------------ - -include::glossary-content.txt[] - -SEE ALSO --------- -linkgit:gittutorial[7], -linkgit:gittutorial-2[7], -linkgit:gitcvs-migration[7], -linkgit:giteveryday[7], -link:user-manual.html[The Git User's Manual] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/githooks.txt b/third_party/git/Documentation/githooks.txt deleted file mode 100644 index 82cd573776..0000000000 --- a/third_party/git/Documentation/githooks.txt +++ /dev/null @@ -1,521 +0,0 @@ -githooks(5) -=========== - -NAME ----- -githooks - Hooks used by Git - -SYNOPSIS --------- -$GIT_DIR/hooks/* (or \`git config core.hooksPath`/*) - - -DESCRIPTION ------------ - -Hooks are programs you can place in a hooks directory to trigger -actions at certain points in git's execution. Hooks that don't have -the executable bit set are ignored. - -By default the hooks directory is `$GIT_DIR/hooks`, but that can be -changed via the `core.hooksPath` configuration variable (see -linkgit:git-config[1]). - -Before Git invokes a hook, it changes its working directory to either -$GIT_DIR in a bare repository or the root of the working tree in a non-bare -repository. An exception are hooks triggered during a push ('pre-receive', -'update', 'post-receive', 'post-update', 'push-to-checkout') which are always -executed in $GIT_DIR. - -Hooks can get their arguments via the environment, command-line -arguments, and stdin. See the documentation for each hook below for -details. - -`git init` may copy hooks to the new repository, depending on its -configuration. See the "TEMPLATE DIRECTORY" section in -linkgit:git-init[1] for details. When the rest of this document refers -to "default hooks" it's talking about the default template shipped -with Git. - -The currently supported hooks are described below. - -HOOKS ------ - -applypatch-msg -~~~~~~~~~~~~~~ - -This hook is invoked by linkgit:git-am[1]. It takes a single -parameter, the name of the file that holds the proposed commit -log message. Exiting with a non-zero status causes `git am` to abort -before applying the patch. - -The hook is allowed to edit the message file in place, and can -be used to normalize the message into some project standard -format. It can also be used to refuse the commit after inspecting -the message file. - -The default 'applypatch-msg' hook, when enabled, runs the -'commit-msg' hook, if the latter is enabled. - -pre-applypatch -~~~~~~~~~~~~~~ - -This hook is invoked by linkgit:git-am[1]. It takes no parameter, and is -invoked after the patch is applied, but before a commit is made. - -If it exits with non-zero status, then the working tree will not be -committed after applying the patch. - -It can be used to inspect the current working tree and refuse to -make a commit if it does not pass certain test. - -The default 'pre-applypatch' hook, when enabled, runs the -'pre-commit' hook, if the latter is enabled. - -post-applypatch -~~~~~~~~~~~~~~~ - -This hook is invoked by linkgit:git-am[1]. It takes no parameter, -and is invoked after the patch is applied and a commit is made. - -This hook is meant primarily for notification, and cannot affect -the outcome of `git am`. - -pre-commit -~~~~~~~~~~ - -This hook is invoked by linkgit:git-commit[1], and can be bypassed -with the `--no-verify` option. It takes no parameters, and is -invoked before obtaining the proposed commit log message and -making a commit. Exiting with a non-zero status from this script -causes the `git commit` command to abort before creating a commit. - -The default 'pre-commit' hook, when enabled, catches introduction -of lines with trailing whitespaces and aborts the commit when -such a line is found. - -All the `git commit` hooks are invoked with the environment -variable `GIT_EDITOR=:` if the command will not bring up an editor -to modify the commit message. - -The default 'pre-commit' hook, when enabled--and with the -`hooks.allownonascii` config option unset or set to false--prevents -the use of non-ASCII filenames. - -prepare-commit-msg -~~~~~~~~~~~~~~~~~~ - -This hook is invoked by linkgit:git-commit[1] right after preparing the -default log message, and before the editor is started. - -It takes one to three parameters. The first is the name of the file -that contains the commit log message. The second is the source of the commit -message, and can be: `message` (if a `-m` or `-F` option was -given); `template` (if a `-t` option was given or the -configuration option `commit.template` is set); `merge` (if the -commit is a merge or a `.git/MERGE_MSG` file exists); `squash` -(if a `.git/SQUASH_MSG` file exists); or `commit`, followed by -a commit SHA-1 (if a `-c`, `-C` or `--amend` option was given). - -If the exit status is non-zero, `git commit` will abort. - -The purpose of the hook is to edit the message file in place, and -it is not suppressed by the `--no-verify` option. A non-zero exit -means a failure of the hook and aborts the commit. It should not -be used as replacement for pre-commit hook. - -The sample `prepare-commit-msg` hook that comes with Git removes the -help message found in the commented portion of the commit template. - -commit-msg -~~~~~~~~~~ - -This hook is invoked by linkgit:git-commit[1] and linkgit:git-merge[1], and can be -bypassed with the `--no-verify` option. It takes a single parameter, -the name of the file that holds the proposed commit log message. -Exiting with a non-zero status causes the command to abort. - -The hook is allowed to edit the message file in place, and can be used -to normalize the message into some project standard format. It -can also be used to refuse the commit after inspecting the message -file. - -The default 'commit-msg' hook, when enabled, detects duplicate -"Signed-off-by" lines, and aborts the commit if one is found. - -post-commit -~~~~~~~~~~~ - -This hook is invoked by linkgit:git-commit[1]. It takes no parameters, and is -invoked after a commit is made. - -This hook is meant primarily for notification, and cannot affect -the outcome of `git commit`. - -pre-rebase -~~~~~~~~~~ - -This hook is called by linkgit:git-rebase[1] and can be used to prevent a -branch from getting rebased. The hook may be called with one or -two parameters. The first parameter is the upstream from which -the series was forked. The second parameter is the branch being -rebased, and is not set when rebasing the current branch. - -post-checkout -~~~~~~~~~~~~~ - -This hook is invoked when a linkgit:git-checkout[1] or -linkgit:git-switch[1] is run after having updated the -worktree. The hook is given three parameters: the ref of the previous HEAD, -the ref of the new HEAD (which may or may not have changed), and a flag -indicating whether the checkout was a branch checkout (changing branches, -flag=1) or a file checkout (retrieving a file from the index, flag=0). -This hook cannot affect the outcome of `git switch` or `git checkout`. - -It is also run after linkgit:git-clone[1], unless the `--no-checkout` (`-n`) option is -used. The first parameter given to the hook is the null-ref, the second the -ref of the new HEAD and the flag is always 1. Likewise for `git worktree add` -unless `--no-checkout` is used. - -This hook can be used to perform repository validity checks, auto-display -differences from the previous HEAD if different, or set working dir metadata -properties. - -post-merge -~~~~~~~~~~ - -This hook is invoked by linkgit:git-merge[1], which happens when a `git pull` -is done on a local repository. The hook takes a single parameter, a status -flag specifying whether or not the merge being done was a squash merge. -This hook cannot affect the outcome of `git merge` and is not executed, -if the merge failed due to conflicts. - -This hook can be used in conjunction with a corresponding pre-commit hook to -save and restore any form of metadata associated with the working tree -(e.g.: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl -for an example of how to do this. - -pre-push -~~~~~~~~ - -This hook is called by linkgit:git-push[1] and can be used to prevent -a push from taking place. The hook is called with two parameters -which provide the name and location of the destination remote, if a -named remote is not being used both values will be the same. - -Information about what is to be pushed is provided on the hook's standard -input with lines of the form: - - <local ref> SP <local sha1> SP <remote ref> SP <remote sha1> LF - -For instance, if the command +git push origin master:foreign+ were run the -hook would receive a line like the following: - - refs/heads/master 67890 refs/heads/foreign 12345 - -although the full, 40-character SHA-1s would be supplied. If the foreign ref -does not yet exist the `<remote SHA-1>` will be 40 `0`. If a ref is to be -deleted, the `<local ref>` will be supplied as `(delete)` and the `<local -SHA-1>` will be 40 `0`. If the local commit was specified by something other -than a name which could be expanded (such as `HEAD~`, or a SHA-1) it will be -supplied as it was originally given. - -If this hook exits with a non-zero status, `git push` will abort without -pushing anything. Information about why the push is rejected may be sent -to the user by writing to standard error. - -[[pre-receive]] -pre-receive -~~~~~~~~~~~ - -This hook is invoked by linkgit:git-receive-pack[1] when it reacts to -`git push` and updates reference(s) in its repository. -Just before starting to update refs on the remote repository, the -pre-receive hook is invoked. Its exit status determines the success -or failure of the update. - -This hook executes once for the receive operation. It takes no -arguments, but for each ref to be updated it receives on standard -input a line of the format: - - <old-value> SP <new-value> SP <ref-name> LF - -where `<old-value>` is the old object name stored in the ref, -`<new-value>` is the new object name to be stored in the ref and -`<ref-name>` is the full name of the ref. -When creating a new ref, `<old-value>` is 40 `0`. - -If the hook exits with non-zero status, none of the refs will be -updated. If the hook exits with zero, updating of individual refs can -still be prevented by the <<update,'update'>> hook. - -Both standard output and standard error output are forwarded to -`git send-pack` on the other end, so you can simply `echo` messages -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`. - -See the section on "Quarantine Environment" in -linkgit:git-receive-pack[1] for some caveats. - -[[update]] -update -~~~~~~ - -This hook is invoked by linkgit:git-receive-pack[1] when it reacts to -`git push` and updates reference(s) in its repository. -Just before updating the ref on the remote repository, the update hook -is invoked. Its exit status determines the success or failure of -the ref update. - -The hook executes once for each ref to be updated, and takes -three parameters: - - - the name of the ref being updated, - - the old object name stored in the ref, - - and the new object name to be stored in the ref. - -A zero exit from the update hook allows the ref to be updated. -Exiting with a non-zero status prevents `git receive-pack` -from updating that ref. - -This hook can be used to prevent 'forced' update on certain refs by -making sure that the object name is a commit object that is a -descendant of the commit object named by the old object name. -That is, to enforce a "fast-forward only" policy. - -It could also be used to log the old..new status. However, it -does not know the entire set of branches, so it would end up -firing one e-mail per ref when used naively, though. The -<<post-receive,'post-receive'>> hook is more suited to that. - -In an environment that restricts the users' access only to git -commands over the wire, this hook can be used to implement access -control without relying on filesystem ownership and group -membership. See linkgit:git-shell[1] for how you might use the login -shell to restrict the user's access to only git commands. - -Both standard output and standard error output are forwarded to -`git send-pack` on the other end, so you can simply `echo` messages -for the user. - -The default 'update' hook, when enabled--and with -`hooks.allowunannotated` config option unset or set to false--prevents -unannotated tags to be pushed. - -[[post-receive]] -post-receive -~~~~~~~~~~~~ - -This hook is invoked by linkgit:git-receive-pack[1] when it reacts to -`git push` and updates reference(s) in its repository. -It executes on the remote repository once after all the refs have -been updated. - -This hook executes once for the receive operation. It takes no -arguments, but gets the same information as the -<<pre-receive,'pre-receive'>> -hook does on its standard input. - -This hook does not affect the outcome of `git receive-pack`, as it -is called after the real work is done. - -This supersedes the <<post-update,'post-update'>> hook in that it gets -both old and new values of all the refs in addition to their -names. - -Both standard output and standard error output are forwarded to -`git send-pack` on the other end, so you can simply `echo` messages -for the user. - -The default 'post-receive' hook is empty, but there is -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 -~~~~~~~~~~~ - -This hook is invoked by linkgit:git-receive-pack[1] when it reacts to -`git push` and updates reference(s) in its repository. -It executes on the remote repository once after all the refs have -been updated. - -It takes a variable number of parameters, each of which is the -name of ref that was actually updated. - -This hook is meant primarily for notification, and cannot affect -the outcome of `git receive-pack`. - -The 'post-update' hook can tell what are the heads that were pushed, -but it does not know what their original and updated values are, -so it is a poor place to do log old..new. The -<<post-receive,'post-receive'>> hook does get both original and -updated values of the refs. You might consider it instead if you need -them. - -When enabled, the default 'post-update' hook runs -`git update-server-info` to keep the information used by dumb -transports (e.g., HTTP) up to date. If you are publishing -a Git repository that is accessible via HTTP, you should -probably enable this hook. - -Both standard output and standard error output are forwarded to -`git send-pack` on the other end, so you can simply `echo` messages -for the user. - -push-to-checkout -~~~~~~~~~~~~~~~~ - -This hook is invoked by linkgit:git-receive-pack[1] when it reacts to -`git push` and updates reference(s) in its repository, and when -the push tries to update the branch that is currently checked out -and the `receive.denyCurrentBranch` configuration variable is set to -`updateInstead`. Such a push by default is refused if the working -tree and the index of the remote repository has any difference from -the currently checked out commit; when both the working tree and the -index match the current commit, they are updated to match the newly -pushed tip of the branch. This hook is to be used to override the -default behaviour. - -The hook receives the commit with which the tip of the current -branch is going to be updated. It can exit with a non-zero status -to refuse the push (when it does so, it must not modify the index or -the working tree). Or it can make any necessary changes to the -working tree and to the index to bring them to the desired state -when the tip of the current branch is updated to the new commit, and -exit with a zero status. - -For example, the hook can simply run `git read-tree -u -m HEAD "$1"` -in order to emulate `git fetch` that is run in the reverse direction -with `git push`, as the two-tree form of `git read-tree -u -m` is -essentially the same as `git switch` or `git checkout` -that switches branches while -keeping the local changes in the working tree that do not interfere -with the difference between the branches. - - -pre-auto-gc -~~~~~~~~~~~ - -This hook is invoked by `git gc --auto` (see linkgit:git-gc[1]). It -takes no parameter, and exiting with non-zero status from this script -causes the `git gc --auto` to abort. - -post-rewrite -~~~~~~~~~~~~ - -This hook is invoked by commands that rewrite commits -(linkgit:git-commit[1] when called with `--amend` and -linkgit:git-rebase[1]; currently `git filter-branch` does 'not' call -it!). Its first argument denotes the command it was invoked by: -currently one of `amend` or `rebase`. Further command-dependent -arguments may be passed in the future. - -The hook receives a list of the rewritten commits on stdin, in the -format - - <old-sha1> SP <new-sha1> [ SP <extra-info> ] LF - -The 'extra-info' is again command-dependent. If it is empty, the -preceding SP is also omitted. Currently, no commands pass any -'extra-info'. - -The hook always runs after the automatic note copying (see -"notes.rewrite.<command>" in linkgit:git-config[1]) has happened, and -thus has access to these notes. - -The following command-specific comments apply: - -rebase:: - For the 'squash' and 'fixup' operation, all commits that were - squashed are listed as being rewritten to the squashed commit. - This means that there will be several lines sharing the same - 'new-sha1'. -+ -The commits are guaranteed to be listed in the order that they were -processed by rebase. - -sendemail-validate -~~~~~~~~~~~~~~~~~~ - -This hook is invoked by linkgit:git-send-email[1]. It takes a single parameter, -the name of the file that holds the e-mail to be sent. Exiting with a -non-zero status causes `git send-email` to abort before sending any -e-mails. - -fsmonitor-watchman -~~~~~~~~~~~~~~~~~~ - -This hook is invoked when the configuration option `core.fsmonitor` is -set to `.git/hooks/fsmonitor-watchman`. It takes two arguments, a version -(currently 1) and the time in elapsed nanoseconds since midnight, -January 1, 1970. - -The hook should output to stdout the list of all files in the working -directory that may have changed since the requested time. The logic -should be inclusive so that it does not miss any potential changes. -The paths should be relative to the root of the working directory -and be separated by a single NUL. - -It is OK to include files which have not actually changed. All changes -including newly-created and deleted files should be included. When -files are renamed, both the old and the new name should be included. - -Git will limit what files it checks for changes as well as which -directories are checked for untracked files based on the path names -given. - -An optimized way to tell git "all files have changed" is to return -the filename `/`. - -The exit status determines whether git will use the data from the -hook to limit its search. On error, it will fall back to verifying -all files and folders. - -p4-pre-submit -~~~~~~~~~~~~~ - -This hook is invoked by `git-p4 submit`. It takes no parameters and nothing -from standard input. Exiting with non-zero status from this script prevent -`git-p4 submit` from launching. Run `git-p4 submit --help` for details. - -post-index-change -~~~~~~~~~~~~~~~~~ - -This hook is invoked when the index is written in read-cache.c -do_write_locked_index. - -The first parameter passed to the hook is the indicator for the -working directory being updated. "1" meaning working directory -was updated or "0" when the working directory was not updated. - -The second parameter passed to the hook is the indicator for whether -or not the index was updated and the skip-worktree bit could have -changed. "1" meaning skip-worktree bits could have been updated -and "0" meaning they were not. - -Only one parameter should be set to "1" when the hook runs. The hook -running passing "1", "1" should not be possible. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitignore.txt b/third_party/git/Documentation/gitignore.txt deleted file mode 100644 index d47b1ae296..0000000000 --- a/third_party/git/Documentation/gitignore.txt +++ /dev/null @@ -1,238 +0,0 @@ -gitignore(5) -============ - -NAME ----- -gitignore - Specifies intentionally untracked files to ignore - -SYNOPSIS --------- -$XDG_CONFIG_HOME/git/ignore, $GIT_DIR/info/exclude, .gitignore - -DESCRIPTION ------------ - -A `gitignore` file specifies intentionally untracked files that -Git should ignore. -Files already tracked by Git are not affected; see the NOTES -below for details. - -Each line in a `gitignore` file specifies a pattern. -When deciding whether to ignore a path, Git normally checks -`gitignore` patterns from multiple sources, with the following -order of precedence, from highest to lowest (within one level of -precedence, the last matching pattern decides the outcome): - - * Patterns read from the command line for those commands that support - them. - - * Patterns read from a `.gitignore` file in the same directory - as the path, or in any parent directory, with patterns in the - higher level files (up to the toplevel of the work tree) being overridden - by those in lower level files down to the directory containing the file. - These patterns match relative to the location of the - `.gitignore` file. A project normally includes such - `.gitignore` files in its repository, containing patterns for - files generated as part of the project build. - - * Patterns read from `$GIT_DIR/info/exclude`. - - * Patterns read from the file specified by the configuration - variable `core.excludesFile`. - -Which file to place a pattern in depends on how the pattern is meant to -be used. - - * Patterns which should be version-controlled and distributed to - other repositories via clone (i.e., files that all developers will want - to ignore) should go into a `.gitignore` file. - - * Patterns which are - specific to a particular repository but which do not need to be shared - with other related repositories (e.g., auxiliary files that live inside - the repository but are specific to one user's workflow) should go into - the `$GIT_DIR/info/exclude` file. - - * Patterns which a user wants Git to - ignore in all situations (e.g., backup or temporary files generated by - the user's editor of choice) generally go into a file specified by - `core.excludesFile` in the user's `~/.gitconfig`. Its default value is - $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or - empty, $HOME/.config/git/ignore is used instead. - -The underlying Git plumbing tools, such as -'git ls-files' and 'git read-tree', read -`gitignore` patterns specified by command-line options, or from -files specified by command-line options. Higher-level Git -tools, such as 'git status' and 'git add', -use patterns from the sources specified above. - -PATTERN FORMAT --------------- - - - A blank line matches no files, so it can serve as a separator - for readability. - - - A line starting with # serves as a comment. - Put a backslash ("`\`") in front of the first hash for patterns - that begin with a hash. - - - Trailing spaces are ignored unless they are quoted with backslash - ("`\`"). - - - An optional prefix "`!`" which negates the pattern; any - matching file excluded by a previous pattern will become - included again. It is not possible to re-include a file if a parent - directory of that file is excluded. Git doesn't list excluded - directories for performance reasons, so any patterns on contained - files have no effect, no matter where they are defined. - Put a backslash ("`\`") in front of the first "`!`" for patterns - that begin with a literal "`!`", for example, "`\!important!.txt`". - - - The slash '/' is used as the directory separator. Separators may - occur at the beginning, middle or end of the `.gitignore` search pattern. - - - If there is a separator at the beginning or middle (or both) of the - pattern, then the pattern is relative to the directory level of the - particular `.gitignore` file itself. Otherwise the pattern may also - match at any level below the `.gitignore` level. - - - If there is a separator at the end of the pattern then the pattern - will only match directories, otherwise the pattern can match both - files and directories. - - - For example, a pattern `doc/frotz/` matches `doc/frotz` directory, - but not `a/doc/frotz` directory; however `frotz/` matches `frotz` - and `a/frotz` that is a directory (all paths are relative from - the `.gitignore` file). - - - An asterisk "`*`" matches anything except a slash. - The character "`?`" matches any one character except "`/`". - The range notation, e.g. `[a-zA-Z]`, can be used to match - one of the characters in a range. See fnmatch(3) and the - FNM_PATHNAME flag for a more detailed description. - -Two consecutive asterisks ("`**`") in patterns matched against -full pathname may have special meaning: - - - A leading "`**`" followed by a slash means match in all - directories. For example, "`**/foo`" matches file or directory - "`foo`" anywhere, the same as pattern "`foo`". "`**/foo/bar`" - matches file or directory "`bar`" anywhere that is directly - under directory "`foo`". - - - A trailing "`/**`" matches everything inside. For example, - "`abc/**`" matches all files inside directory "`abc`", relative - to the location of the `.gitignore` file, with infinite depth. - - - A slash followed by two consecutive asterisks then a slash - matches zero or more directories. For example, "`a/**/b`" - matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on. - - - Other consecutive asterisks are considered regular asterisks and - will match according to the previous rules. - -CONFIGURATION -------------- - -The optional configuration variable `core.excludesFile` indicates a path to a -file containing patterns of file names to exclude, similar to -`$GIT_DIR/info/exclude`. Patterns in the exclude file are used in addition to -those in `$GIT_DIR/info/exclude`. - -NOTES ------ - -The purpose of gitignore files is to ensure that certain files -not tracked by Git remain untracked. - -To stop tracking a file that is currently tracked, use -'git rm --cached'. - -EXAMPLES --------- - - - The pattern `hello.*` matches any file or folder - whose name begins with `hello`. If one wants to restrict - this only to the directory and not in its subdirectories, - one can prepend the pattern with a slash, i.e. `/hello.*`; - the pattern now matches `hello.txt`, `hello.c` but not - `a/hello.java`. - - - The pattern `foo/` will match a directory `foo` and - paths underneath it, but will not match a regular file - or a symbolic link `foo` (this is consistent with the - way how pathspec works in general in Git) - - - The pattern `doc/frotz` and `/doc/frotz` have the same effect - in any `.gitignore` file. In other words, a leading slash - is not relevant if there is already a middle slash in - the pattern. - - - The pattern "foo/*", matches "foo/test.json" - (a regular file), "foo/bar" (a directory), but it does not match - "foo/bar/hello.c" (a regular file), as the asterisk in the - pattern does not match "bar/hello.c" which has a slash in it. - --------------------------------------------------------------- - $ git status - [...] - # Untracked files: - [...] - # Documentation/foo.html - # Documentation/gitignore.html - # file.o - # lib.a - # src/internal.o - [...] - $ cat .git/info/exclude - # ignore objects and archives, anywhere in the tree. - *.[oa] - $ cat Documentation/.gitignore - # ignore generated html files, - *.html - # except foo.html which is maintained by hand - !foo.html - $ git status - [...] - # Untracked files: - [...] - # Documentation/foo.html - [...] --------------------------------------------------------------- - -Another example: - --------------------------------------------------------------- - $ cat .gitignore - vmlinux* - $ ls arch/foo/kernel/vm* - arch/foo/kernel/vmlinux.lds.S - $ echo '!/vmlinux*' >arch/foo/kernel/.gitignore --------------------------------------------------------------- - -The second .gitignore prevents Git from ignoring -`arch/foo/kernel/vmlinux.lds.S`. - -Example to exclude everything except a specific directory `foo/bar` -(note the `/*` - without the slash, the wildcard would also exclude -everything within `foo/bar`): - --------------------------------------------------------------- - $ cat .gitignore - # exclude everything except directory foo/bar - /* - !/foo - /foo/* - !/foo/bar --------------------------------------------------------------- - -SEE ALSO --------- -linkgit:git-rm[1], -linkgit:gitrepository-layout[5], -linkgit:git-check-ignore[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitk.txt b/third_party/git/Documentation/gitk.txt deleted file mode 100644 index 1eabb0aaf3..0000000000 --- a/third_party/git/Documentation/gitk.txt +++ /dev/null @@ -1,202 +0,0 @@ -gitk(1) -======= - -NAME ----- -gitk - The Git repository browser - -SYNOPSIS --------- -[verse] -'gitk' [<options>] [<revision range>] [--] [<path>...] - -DESCRIPTION ------------ -Displays changes in a repository or a selected set of commits. This includes -visualizing the commit graph, showing information related to each commit, and -the files in the trees of each revision. - -OPTIONS -------- - -To control which revisions to show, gitk supports most options -applicable to the 'git rev-list' command. It also supports a few -options applicable to the 'git diff-*' commands to control how the -changes each commit introduces are shown. Finally, it supports some -gitk-specific options. - -gitk generally only understands options with arguments in the -'sticked' form (see linkgit:gitcli[7]) due to limitations in the -command-line parser. - -rev-list options and arguments -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -This manual page describes only the most frequently used options. See -linkgit:git-rev-list[1] for a complete list. - ---all:: - - Show all refs (branches, tags, etc.). - ---branches[=<pattern>]:: ---tags[=<pattern>]:: ---remotes[=<pattern>]:: - - Pretend as if all the branches (tags, remote branches, resp.) - are listed on the command line as '<commit>'. If '<pattern>' - is given, limit refs to ones matching given shell glob. If - pattern lacks '?', '{asterisk}', or '[', '/{asterisk}' at the - end is implied. - ---since=<date>:: - - Show commits more recent than a specific date. - ---until=<date>:: - - Show commits older than a specific date. - ---date-order:: - - Sort commits by date when possible. - ---merge:: - - After an attempt to merge stops with conflicts, show the commits on - the history between two branches (i.e. the HEAD and the MERGE_HEAD) - that modify the conflicted files and do not exist on all the heads - being merged. - ---left-right:: - - 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. - ---full-history:: - - When filtering history with '<path>...', does not prune some - history. (See "History simplification" in linkgit:git-log[1] - for a more detailed explanation.) - ---simplify-merges:: - - Additional option to `--full-history` to remove some needless - merges from the resulting history, as there are no selected - commits contributing to this merge. (See "History - simplification" in linkgit:git-log[1] for a more detailed - explanation.) - ---ancestry-path:: - - When given a range of commits to display - (e.g. 'commit1..commit2' or 'commit2 {caret}commit1'), only - display commits that exist directly on the ancestry chain - between the 'commit1' and 'commit2', i.e. commits that are - both descendants of 'commit1', and ancestors of 'commit2'. - (See "History simplification" in linkgit:git-log[1] for a more - detailed explanation.) - --L<start>,<end>:<file>:: --L:<funcname>:<file>:: - - Trace the evolution of the line range given by "<start>,<end>" - (or the function name regex <funcname>) within the <file>. You may - not give any pathspec limiters. This is currently limited to - a walk starting from a single revision, i.e., you may only - give zero or one positive revision arguments. - You can specify this option more than once. -+ -*Note:* gitk (unlike linkgit:git-log[1]) currently only understands -this option if you specify it "glued together" with its argument. Do -*not* put a space after `-L`. -+ -include::line-range-format.txt[] - -<revision range>:: - - Limit the revisions to show. This can be either a single revision - meaning show from the given revision and back, or it can be a range in - the form "'<from>'..'<to>'" to show all revisions between '<from>' and - back to '<to>'. Note, more advanced revision selection can be applied. - For a more complete list of ways to spell object names, see - linkgit:gitrevisions[7]. - -<path>...:: - - Limit commits to the ones touching files in the given paths. Note, to - avoid ambiguity with respect to revision names use "--" to separate the paths - from any preceding options. - -gitk-specific options -~~~~~~~~~~~~~~~~~~~~~ - ---argscmd=<command>:: - - Command to be run each time gitk has to determine the revision - range to show. The command is expected to print on its - standard output a list of additional revisions to be shown, - one per line. Use this instead of explicitly specifying a - '<revision range>' if the set of commits to show may vary - between refreshes. - ---select-commit=<ref>:: - - Select the specified commit after loading the graph. - Default behavior is equivalent to specifying '--select-commit=HEAD'. - -Examples --------- -gitk v2.6.12.. include/scsi drivers/scsi:: - - Show the changes since version 'v2.6.12' that changed any - file in the include/scsi or drivers/scsi subdirectories - -gitk --since="2 weeks ago" \-- gitk:: - - Show the changes during the last two weeks to the file 'gitk'. - The "--" is necessary to avoid confusion with the *branch* named - 'gitk' - -gitk --max-count=100 --all \-- Makefile:: - - Show at most 100 changes made to the file 'Makefile'. Instead of only - looking for changes in the current branch look in all branches. - -Files ------ -User configuration and preferences are stored at: - -* `$XDG_CONFIG_HOME/git/gitk` if it exists, otherwise -* `$HOME/.gitk` if it exists - -If neither of the above exist then `$XDG_CONFIG_HOME/git/gitk` is created and -used by default. If '$XDG_CONFIG_HOME' is not set it defaults to -`$HOME/.config` in all cases. - -History -------- -Gitk was the first graphical repository browser. It's written in -tcl/tk. - -'gitk' is actually maintained as an independent project, but stable -versions are distributed as part of the Git suite for the convenience -of end users. - -gitk-git/ comes from Paul Mackerras's gitk project: - - git://ozlabs.org/~paulus/gitk - -SEE ALSO --------- -'qgit(1)':: - A repository browser written in C++ using Qt. - -'tig(1)':: - A minimal repository browser and Git tool output highlighter written - in C using Ncurses. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitmodules.txt b/third_party/git/Documentation/gitmodules.txt deleted file mode 100644 index a66e95b70c..0000000000 --- a/third_party/git/Documentation/gitmodules.txt +++ /dev/null @@ -1,127 +0,0 @@ -gitmodules(5) -============= - -NAME ----- -gitmodules - Defining submodule properties - -SYNOPSIS --------- -$GIT_WORK_DIR/.gitmodules - - -DESCRIPTION ------------ - -The `.gitmodules` file, located in the top-level directory of a Git -working tree, is a text file with a syntax matching the requirements -of linkgit:git-config[1]. - -The file contains one subsection per submodule, and the subsection value -is the name of the submodule. The name is set to the path where the -submodule has been added unless it was customized with the `--name` -option of 'git submodule add'. Each submodule section also contains the -following required keys: - -submodule.<name>.path:: - Defines the path, relative to the top-level directory of the Git - working tree, where the submodule is expected to be checked out. - The path name must not end with a `/`. All submodule paths must - be unique within the .gitmodules file. - -submodule.<name>.url:: - Defines a URL from which the submodule repository can be cloned. - This may be either an absolute URL ready to be passed to - linkgit:git-clone[1] or (if it begins with ./ or ../) a location - relative to the superproject's origin repository. - -In addition, there are a number of optional keys: - -submodule.<name>.update:: - Defines the default update procedure for the named submodule, - i.e. how the submodule is updated by "git submodule update" - command in the superproject. This is only used by `git - submodule init` to initialize the configuration variable of - the same name. Allowed values here are 'checkout', 'rebase', - 'merge' or 'none'. See description of 'update' command in - linkgit:git-submodule[1] for their meaning. Note that the - '!command' form is intentionally ignored here for security - reasons. - -submodule.<name>.branch:: - A remote branch name for tracking updates in the upstream submodule. - 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 - submodule. If this option is also present in the submodules entry in - .git/config of the superproject, the setting there will override the - one found in .gitmodules. - Both settings can be overridden on the command line by using the - "--[no-]recurse-submodules" option to "git fetch" and "git pull". - -submodule.<name>.ignore:: - Defines under what circumstances "git status" and the diff family show - a submodule as modified. The following values are supported: -+ --- - all;; The submodule will never be considered modified (but will - nonetheless show up in the output of status and commit when it has - been staged). - - dirty;; All changes to the submodule's work tree will be ignored, only - committed differences between the HEAD of the submodule and its - recorded state in the superproject are taken into account. - - untracked;; Only untracked files in submodules will be ignored. - Committed differences and modifications to tracked files will show - up. - - none;; No modifiations to submodules are ignored, all of committed - differences, and modifications to tracked and untracked files are - shown. This is the default option. - -If this option is also present in the submodules entry in .git/config -of the superproject, the setting there will override the one found in -.gitmodules. - -Both settings can be overridden on the command line by using the -"--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 (with a history depth of 1) unless the user explicitly - asks for a non-shallow clone. - - -EXAMPLES --------- - -Consider the following .gitmodules file: - - [submodule "libfoo"] - path = include/foo - url = git://foo.com/git/lib.git - - [submodule "libbar"] - path = include/bar - url = git://bar.com/git/lib.git - - -This defines two submodules, `libfoo` and `libbar`. These are expected to -be checked out in the paths `include/foo` and `include/bar`, and for both -submodules a URL is specified which can be used for cloning the submodules. - -SEE ALSO --------- -linkgit:git-submodule[1] linkgit:git-config[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitnamespaces.txt b/third_party/git/Documentation/gitnamespaces.txt deleted file mode 100644 index b614969ad2..0000000000 --- a/third_party/git/Documentation/gitnamespaces.txt +++ /dev/null @@ -1,64 +0,0 @@ -gitnamespaces(7) -================ - -NAME ----- -gitnamespaces - Git namespaces - -SYNOPSIS --------- -[verse] -GIT_NAMESPACE=<namespace> 'git upload-pack' -GIT_NAMESPACE=<namespace> 'git receive-pack' - - -DESCRIPTION ------------ - -Git supports dividing the refs of a single repository into multiple -namespaces, each of which has its own branches, tags, and HEAD. Git can -expose each namespace as an independent repository to pull from and push -to, while sharing the object store, and exposing all the refs to -operations such as linkgit:git-gc[1]. - -Storing multiple repositories as namespaces of a single repository -avoids storing duplicate copies of the same objects, such as when -storing multiple branches of the same source. The alternates mechanism -provides similar support for avoiding duplicates, but alternates do not -prevent duplication between new objects added to the repositories -without ongoing maintenance, while namespaces do. - -To specify a namespace, set the `GIT_NAMESPACE` environment variable to -the namespace. For each ref namespace, Git stores the corresponding -refs in a directory under `refs/namespaces/`. For example, -`GIT_NAMESPACE=foo` will store refs under `refs/namespaces/foo/`. You -can also specify namespaces via the `--namespace` option to -linkgit:git[1]. - -Note that namespaces which include a `/` will expand to a hierarchy of -namespaces; for example, `GIT_NAMESPACE=foo/bar` will store refs under -`refs/namespaces/foo/refs/namespaces/bar/`. This makes paths in -`GIT_NAMESPACE` behave hierarchically, so that cloning with -`GIT_NAMESPACE=foo/bar` produces the same result as cloning with -`GIT_NAMESPACE=foo` and cloning from that repo with `GIT_NAMESPACE=bar`. It -also avoids ambiguity with strange namespace paths such as `foo/refs/heads/`, -which could otherwise generate directory/file conflicts within the `refs` -directory. - -linkgit:git-upload-pack[1] and linkgit:git-receive-pack[1] rewrite the -names of refs as specified by `GIT_NAMESPACE`. git-upload-pack and -git-receive-pack will ignore all references outside the specified -namespace. - -The smart HTTP server, linkgit:git-http-backend[1], will pass -GIT_NAMESPACE through to the backend programs; see -linkgit:git-http-backend[1] for sample configuration to expose -repository namespaces as repositories. - -For a simple local test, you can use linkgit:git-remote-ext[1]: - ----------- -git clone ext::'git --namespace=foo %s /tmp/prefixed.git' ----------- - -include::transfer-data-leaks.txt[] diff --git a/third_party/git/Documentation/gitremote-helpers.txt b/third_party/git/Documentation/gitremote-helpers.txt deleted file mode 100644 index 43f80c8068..0000000000 --- a/third_party/git/Documentation/gitremote-helpers.txt +++ /dev/null @@ -1,520 +0,0 @@ -gitremote-helpers(7) -==================== - -NAME ----- -gitremote-helpers - Helper programs to interact with remote repositories - -SYNOPSIS --------- -[verse] -'git remote-<transport>' <repository> [<URL>] - -DESCRIPTION ------------ - -Remote helper programs are normally not used directly by end users, -but they are invoked by Git when it needs to interact with remote -repositories Git does not support natively. A given helper will -implement a subset of the capabilities documented here. When Git -needs to interact with a repository using a remote helper, it spawns -the helper as an independent process, sends commands to the helper's -standard input, and expects results from the helper's standard -output. Because a remote helper runs as an independent process from -Git, there is no need to re-link Git to add a new helper, nor any -need to link the helper with the implementation of Git. - -Every helper must support the "capabilities" command, which Git -uses to determine what other commands the helper will accept. Those -other commands can be used to discover and update remote refs, -transport objects between the object database and the remote repository, -and update the local object store. - -Git comes with a "curl" family of remote helpers, that handle various -transport protocols, such as 'git-remote-http', 'git-remote-https', -'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities -'fetch', 'option', and 'push'. - -INVOCATION ----------- - -Remote helper programs are invoked with one or (optionally) two -arguments. The first argument specifies a remote repository as in Git; -it is either the name of a configured remote or a URL. The second -argument specifies a URL; it is usually of the form -'<transport>://<address>', but any arbitrary string is possible. -The `GIT_DIR` environment variable is set up for the remote helper -and can be used to determine where to store additional data or from -which directory to invoke auxiliary Git commands. - -When Git encounters a URL of the form '<transport>://<address>', where -'<transport>' is a protocol that it cannot handle natively, it -automatically invokes 'git remote-<transport>' with the full URL as -the second argument. If such a URL is encountered directly on the -command line, the first argument is the same as the second, and if it -is encountered in a configured remote, the first argument is the name -of that remote. - -A URL of the form '<transport>::<address>' explicitly instructs Git to -invoke 'git remote-<transport>' with '<address>' as the second -argument. If such a URL is encountered directly on the command line, -the first argument is '<address>', and if it is encountered in a -configured remote, the first argument is the name of that remote. - -Additionally, when a configured remote has `remote.<name>.vcs` set to -'<transport>', Git explicitly invokes 'git remote-<transport>' with -'<name>' as the first argument. If set, the second argument is -`remote.<name>.url`; otherwise, the second argument is omitted. - -INPUT FORMAT ------------- - -Git sends the remote helper a list of commands on standard input, one -per line. The first command is always the 'capabilities' command, in -response to which the remote helper must print a list of the -capabilities it supports (see below) followed by a blank line. The -response to the capabilities command determines what commands Git uses -in the remainder of the command stream. - -The command stream is terminated by a blank line. In some cases -(indicated in the documentation of the relevant commands), this blank -line is followed by a payload in some other protocol (e.g., the pack -protocol), while in others it indicates the end of input. - -Capabilities -~~~~~~~~~~~~ - -Each remote helper is expected to support only a subset of commands. -The operations a helper supports are declared to Git in the response -to the `capabilities` command (see COMMANDS, below). - -In the following, we list all defined capabilities and for -each we list which commands a helper with that capability -must provide. - -Capabilities for Pushing -^^^^^^^^^^^^^^^^^^^^^^^^ -'connect':: - Can attempt to connect to 'git receive-pack' (for pushing), - 'git upload-pack', etc for communication using - git's native packfile protocol. This - requires a bidirectional, full-duplex connection. -+ -Supported commands: 'connect'. - -'stateless-connect':: - Experimental; for internal use only. - Can attempt to connect to a remote server for communication - using git's wire-protocol version 2. See the documentation - for the stateless-connect command for more information. -+ -Supported commands: 'stateless-connect'. - -'push':: - Can discover remote refs and push local commits and the - history leading up to them to new or existing remote refs. -+ -Supported commands: 'list for-push', 'push'. - -'export':: - Can discover remote refs and push specified objects from a - fast-import stream to remote refs. -+ -Supported commands: 'list for-push', 'export'. - -If a helper advertises 'connect', Git will use it if possible and -fall back to another capability if the helper requests so when -connecting (see the 'connect' command under COMMANDS). -When choosing between 'push' and 'export', Git prefers 'push'. -Other frontends may have some other order of preference. - -'no-private-update':: - When using the 'refspec' capability, git normally updates the - private ref on successful push. This update is disabled when - the remote-helper declares the capability 'no-private-update'. - - -Capabilities for Fetching -^^^^^^^^^^^^^^^^^^^^^^^^^ -'connect':: - Can try to connect to 'git upload-pack' (for fetching), - 'git receive-pack', etc for communication using the - Git's native packfile protocol. This - requires a bidirectional, full-duplex connection. -+ -Supported commands: 'connect'. - -'stateless-connect':: - Experimental; for internal use only. - Can attempt to connect to a remote server for communication - using git's wire-protocol version 2. See the documentation - for the stateless-connect command for more information. -+ -Supported commands: 'stateless-connect'. - -'fetch':: - Can discover remote refs and transfer objects reachable from - them to the local object store. -+ -Supported commands: 'list', 'fetch'. - -'import':: - Can discover remote refs and output objects reachable from - them as a stream in fast-import format. -+ -Supported commands: 'list', 'import'. - -'check-connectivity':: - Can guarantee that when a clone is requested, the received - pack is self contained and is connected. - -If a helper advertises 'connect', Git will use it if possible and -fall back to another capability if the helper requests so when -connecting (see the 'connect' command under COMMANDS). -When choosing between 'fetch' and 'import', Git prefers 'fetch'. -Other frontends may have some other order of preference. - -Miscellaneous capabilities -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -'option':: - For specifying settings like `verbosity` (how much output to - write to stderr) and `depth` (how much history is wanted in the - case of a shallow clone) that affect how other commands are - carried out. - -'refspec' <refspec>:: - For remote helpers that implement 'import' or 'export', this capability - allows the refs to be constrained to a private namespace, instead of - writing to refs/heads or refs/remotes directly. - It is recommended that all importers providing the 'import' - capability use this. It's mandatory for 'export'. -+ -A helper advertising the capability -`refspec refs/heads/*:refs/svn/origin/branches/*` -is saying that, when it is asked to `import refs/heads/topic`, the -stream it outputs will update the `refs/svn/origin/branches/topic` -ref. -+ -This capability can be advertised multiple times. The first -applicable refspec takes precedence. The left-hand of refspecs -advertised with this capability must cover all refs reported by -the list command. If no 'refspec' capability is advertised, -there is an implied `refspec *:*`. -+ -When writing remote-helpers for decentralized version control -systems, it is advised to keep a local copy of the repository to -interact with, and to let the private namespace refs point to this -local repository, while the refs/remotes namespace is used to track -the remote repository. - -'bidi-import':: - This modifies the 'import' capability. - The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers - to retrieve information about blobs and trees that already exist in - fast-import's memory. This requires a channel from fast-import to the - remote-helper. - If it is advertised in addition to "import", Git establishes a pipe from - fast-import to the remote-helper's stdin. - It follows that Git and fast-import are both connected to the - remote-helper's stdin. Because Git can send multiple commands to - the remote-helper it is required that helpers that use 'bidi-import' - buffer all 'import' commands of a batch before sending data to fast-import. - This is to prevent mixing commands and fast-import responses on the - helper's stdin. - -'export-marks' <file>:: - This modifies the 'export' capability, instructing Git to dump the - internal marks table to <file> when complete. For details, - read up on `--export-marks=<file>` in linkgit:git-fast-export[1]. - -'import-marks' <file>:: - This modifies the 'export' capability, instructing Git to load the - marks specified in <file> before processing any input. For details, - read up on `--import-marks=<file>` in linkgit:git-fast-export[1]. - -'signed-tags':: - This modifies the 'export' capability, instructing Git to pass - `--signed-tags=verbatim` to linkgit:git-fast-export[1]. In the - absence of this capability, Git will use `--signed-tags=warn-strip`. - - - -COMMANDS --------- - -Commands are given by the caller on the helper's standard input, one per line. - -'capabilities':: - Lists the capabilities of the helper, one per line, ending - with a blank line. Each capability may be preceded with '*', - which marks them mandatory for Git versions using the remote - helper to understand. Any unknown mandatory capability is a - fatal error. -+ -Support for this command is mandatory. - -'list':: - Lists the refs, one per line, in the format "<value> <name> - [<attr> ...]". The value may be a hex sha1 hash, "@<dest>" for - a symref, or "?" to indicate that the helper could not get the - value of the ref. A space-separated list of attributes follows - the name; unrecognized attributes are ignored. The list ends - with a blank line. -+ -See REF LIST ATTRIBUTES for a list of currently defined attributes. -+ -Supported if the helper has the "fetch" or "import" capability. - -'list for-push':: - Similar to 'list', except that it is used if and only if - the caller wants to the resulting ref list to prepare - push commands. - A helper supporting both push and fetch can use this - to distinguish for which operation the output of 'list' - is going to be used, possibly reducing the amount - of work that needs to be performed. -+ -Supported if the helper has the "push" or "export" capability. - -'option' <name> <value>:: - Sets the transport helper option <name> to <value>. Outputs a - single line containing one of 'ok' (option successfully set), - 'unsupported' (option not recognized) or 'error <msg>' - (option <name> is supported but <value> is not valid - for it). Options should be set before other commands, - and may influence the behavior of those commands. -+ -See OPTIONS for a list of currently defined options. -+ -Supported if the helper has the "option" capability. - -'fetch' <sha1> <name>:: - Fetches the given object, writing the necessary objects - to the database. Fetch commands are sent in a batch, one - per line, terminated with a blank line. - Outputs a single blank line when all fetch commands in the - same batch are complete. Only objects which were reported - in the output of 'list' with a sha1 may be fetched this way. -+ -Optionally may output a 'lock <file>' line indicating a file under -GIT_DIR/objects/pack which is keeping a pack until refs can be -suitably updated. -+ -If option 'check-connectivity' is requested, the helper must output -'connectivity-ok' if the clone is self-contained and connected. -+ -Supported if the helper has the "fetch" capability. - -'push' +<src>:<dst>:: - Pushes the given local <src> commit or branch to the - remote branch described by <dst>. A batch sequence of - one or more 'push' commands is terminated with a blank line - (if there is only one reference to push, a single 'push' command - is followed by a blank line). For example, the following would - be two batches of 'push', the first asking the remote-helper - to push the local ref 'master' to the remote ref 'master' and - the local `HEAD` to the remote 'branch', and the second - asking to push ref 'foo' to ref 'bar' (forced update requested - by the '+'). -+ ------------- -push refs/heads/master:refs/heads/master -push HEAD:refs/heads/branch -\n -push +refs/heads/foo:refs/heads/bar -\n ------------- -+ -Zero or more protocol options may be entered after the last 'push' -command, before the batch's terminating blank line. -+ -When the push is complete, outputs one or more 'ok <dst>' or -'error <dst> <why>?' lines to indicate success or failure of -each pushed ref. The status report output is terminated by -a blank line. The option field <why> may be quoted in a C -style string if it contains an LF. -+ -Supported if the helper has the "push" capability. - -'import' <name>:: - Produces a fast-import stream which imports the current value - of the named ref. It may additionally import other refs as - needed to construct the history efficiently. The script writes - to a helper-specific private namespace. The value of the named - ref should be written to a location in this namespace derived - by applying the refspecs from the "refspec" capability to the - name of the ref. -+ -Especially useful for interoperability with a foreign versioning -system. -+ -Just like 'push', a batch sequence of one or more 'import' is -terminated with a blank line. For each batch of 'import', the remote -helper should produce a fast-import stream terminated by a 'done' -command. -+ -Note that if the 'bidi-import' capability is used the complete batch -sequence has to be buffered before starting to send data to fast-import -to prevent mixing of commands and fast-import responses on the helper's -stdin. -+ -Supported if the helper has the "import" capability. - -'export':: - Instructs the remote helper that any subsequent input is - part of a fast-import stream (generated by 'git fast-export') - containing objects which should be pushed to the remote. -+ -Especially useful for interoperability with a foreign versioning -system. -+ -The 'export-marks' and 'import-marks' capabilities, if specified, -affect this command in so far as they are passed on to 'git -fast-export', which then will load/store a table of marks for -local objects. This can be used to implement for incremental -operations. -+ -Supported if the helper has the "export" capability. - -'connect' <service>:: - Connects to given service. Standard input and standard output - of helper are connected to specified service (git prefix is - included in service name so e.g. fetching uses 'git-upload-pack' - as service) on remote side. Valid replies to this command are - empty line (connection established), 'fallback' (no smart - transport support, fall back to dumb transports) and just - exiting with error message printed (can't connect, don't - bother trying to fall back). After line feed terminating the - positive (empty) response, the output of service starts. After - the connection ends, the remote helper exits. -+ -Supported if the helper has the "connect" capability. - -'stateless-connect' <service>:: - Experimental; for internal use only. - Connects to the given remote service for communication using - git's wire-protocol version 2. Valid replies to this command - are empty line (connection established), 'fallback' (no smart - transport support, fall back to dumb transports) and just - exiting with error message printed (can't connect, don't bother - trying to fall back). After line feed terminating the positive - (empty) response, the output of the service starts. Messages - (both request and response) must consist of zero or more - PKT-LINEs, terminating in a flush packet. The client must not - expect the server to store any state in between request-response - pairs. After the connection ends, the remote helper exits. -+ -Supported if the helper has the "stateless-connect" capability. - -If a fatal error occurs, the program writes the error message to -stderr and exits. The caller should expect that a suitable error -message has been printed if the child closes the connection without -completing a valid response for the current command. - -Additional commands may be supported, as may be determined from -capabilities reported by the helper. - -REF LIST ATTRIBUTES -------------------- - -The 'list' command produces a list of refs in which each ref -may be followed by a list of attributes. The following ref list -attributes are defined. - -'unchanged':: - This ref is unchanged since the last import or fetch, although - the helper cannot necessarily determine what value that produced. - -OPTIONS -------- - -The following options are defined and (under suitable circumstances) -set by Git if the remote helper has the 'option' capability. - -'option verbosity' <n>:: - Changes the verbosity of messages displayed by the helper. - A value of 0 for <n> means that processes operate - quietly, and the helper produces only error output. - 1 is the default level of verbosity, and higher values - of <n> correspond to the number of -v flags passed on the - command line. - -'option progress' {'true'|'false'}:: - Enables (or disables) progress messages displayed by the - transport helper during a command. - -'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 - during the fetch command. If the tag is not fetched by - the helper a second fetch command will usually be sent to - ask for the tag specifically. Some helpers may be able to - use this option to avoid a second network connection. - -'option dry-run' {'true'|'false'}: - If true, pretend the operation completed successfully, - but don't actually change any repository data. For most - helpers this only applies to the 'push', if supported. - -'option servpath <c-style-quoted-path>':: - Sets service path (--upload-pack, --receive-pack etc.) for - next connect. Remote helper may support this option, but - must not rely on this option being set before - connect request occurs. - -'option check-connectivity' {'true'|'false'}:: - Request the helper to check connectivity of a clone. - -'option force' {'true'|'false'}:: - Request the helper to perform a force update. Defaults to - 'false'. - -'option cloning' {'true'|'false'}:: - Notify the helper this is a clone request (i.e. the current - repository is guaranteed empty). - -'option update-shallow' {'true'|'false'}:: - Allow to extend .git/shallow if the new refs require it. - -'option pushcert' {'true'|'false'}:: - GPG sign pushes. - -'option push-option <string>:: - Transmit <string> as a push option. As the push option - must not contain LF or NUL characters, the string is not encoded. - -'option from-promisor' {'true'|'false'}:: - Indicate that these objects are being fetched from a promisor. - -'option no-dependents' {'true'|'false'}:: - Indicate that only the objects wanted need to be fetched, not - their dependents. - -SEE ALSO --------- -linkgit:git-remote[1] - -linkgit:git-remote-ext[1] - -linkgit:git-remote-fd[1] - -linkgit:git-fast-import[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitrepository-layout.txt b/third_party/git/Documentation/gitrepository-layout.txt deleted file mode 100644 index 216b11ee88..0000000000 --- a/third_party/git/Documentation/gitrepository-layout.txt +++ /dev/null @@ -1,308 +0,0 @@ -gitrepository-layout(5) -======================= - -NAME ----- -gitrepository-layout - Git Repository Layout - -SYNOPSIS --------- -$GIT_DIR/* - -DESCRIPTION ------------ - -A Git repository comes in two different flavours: - - * a `.git` directory at the root of the working tree; - - * a `<project>.git` directory that is a 'bare' repository - (i.e. without its own working tree), that is typically used for - exchanging histories with others by pushing into it and fetching - from it. - -*Note*: Also you can have a plain text file `.git` at the root of -your working tree, containing `gitdir: <path>` to point at the real -directory that has the repository. This mechanism is often used for -a working tree of a submodule checkout, to allow you in the -containing superproject to `git checkout` a branch that does not -have the submodule. The `checkout` has to remove the entire -submodule working tree, without losing the submodule repository. - -These things may exist in a Git repository. - -objects:: - Object store associated with this repository. Usually - an object store is self sufficient (i.e. all the objects - that are referred to by an object found in it are also - found in it), but there are a few ways to violate it. -+ -. You could have an incomplete but locally usable repository -by creating a shallow clone. See linkgit:git-clone[1]. -. You could be using the `objects/info/alternates` or -`$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanisms to 'borrow' -objects from other object stores. A repository with this kind -of incomplete object store is not suitable to be published for -use with dumb transports but otherwise is OK as long as -`objects/info/alternates` points at the object stores it -borrows from. -+ -This directory is ignored if $GIT_COMMON_DIR is set and -"$GIT_COMMON_DIR/objects" will be used instead. - -objects/[0-9a-f][0-9a-f]:: - A newly created object is stored in its own file. - The objects are splayed over 256 subdirectories using - the first two characters of the sha1 object name to - keep the number of directory entries in `objects` - itself to a manageable number. Objects found - here are often called 'unpacked' (or 'loose') objects. - -objects/pack:: - Packs (files that store many object in compressed form, - along with index files to allow them to be randomly - accessed) are found in this directory. - -objects/info:: - Additional information about the object store is - recorded in this directory. - -objects/info/packs:: - This file is to help dumb transports discover what packs - are available in this object store. Whenever a pack is - added or removed, `git update-server-info` should be run - to keep this file up to date if the repository is - published for dumb transports. 'git repack' does this - by default. - -objects/info/alternates:: - This file records paths to alternate object stores that - this object store borrows objects from, one pathname per - line. Note that not only native Git tools use it locally, - but the HTTP fetcher also tries to use it remotely; this - will usually work if you have relative paths (relative - to the object database, not to the repository!) in your - alternates file, but it will not work if you use absolute - paths unless the absolute path in filesystem and web URL - is the same. See also `objects/info/http-alternates`. - -objects/info/http-alternates:: - This file records URLs to alternate object stores that - this object store borrows objects from, to be used when - the repository is fetched over HTTP. - -refs:: - References are stored in subdirectories of this - directory. The 'git prune' command knows to preserve - objects reachable from refs found in this directory and - its subdirectories. - This directory is ignored (except refs/bisect and - refs/worktree) if $GIT_COMMON_DIR is set and - "$GIT_COMMON_DIR/refs" will be used instead. - -refs/heads/`name`:: - records tip-of-the-tree commit objects of branch `name` - -refs/tags/`name`:: - records any object name (not necessarily a commit - object, or a tag object that points at a commit object). - -refs/remotes/`name`:: - records tip-of-the-tree commit objects of branches copied - from a remote repository. - -refs/replace/`<obj-sha1>`:: - records the SHA-1 of the object that replaces `<obj-sha1>`. - This is similar to info/grafts and is internally used and - maintained by linkgit:git-replace[1]. Such refs can be exchanged - between repositories while grafts are not. - -packed-refs:: - records the same information as refs/heads/, refs/tags/, - and friends record in a more efficient way. See - linkgit:git-pack-refs[1]. This file is ignored if $GIT_COMMON_DIR - is set and "$GIT_COMMON_DIR/packed-refs" will be used instead. - -HEAD:: - A symref (see glossary) to the `refs/heads/` namespace - describing the currently active branch. It does not mean - much if the repository is not associated with any working tree - (i.e. a 'bare' repository), but a valid Git repository - *must* have the HEAD file; some porcelains may use it to - guess the designated "default" branch of the repository - (usually 'master'). It is legal if the named branch - 'name' does not (yet) exist. In some legacy setups, it is - a symbolic link instead of a symref that points at the current - branch. -+ -HEAD can also record a specific commit directly, instead of -being a symref to point at the current branch. Such a state -is often called 'detached HEAD.' See linkgit:git-checkout[1] -for details. - -config:: - Repository specific configuration file. This file is ignored - if $GIT_COMMON_DIR is set and "$GIT_COMMON_DIR/config" will be - used instead. - -config.worktree:: - Working directory specific configuration file for the main - working directory in multiple working directory setup (see - linkgit:git-worktree[1]). - -branches:: - A slightly deprecated way to store shorthands to be used - to specify a URL to 'git fetch', 'git pull' and 'git push'. - A file can be stored as `branches/<name>` and then - 'name' can be given to these commands in place of - 'repository' argument. See the REMOTES section in - linkgit:git-fetch[1] for details. This mechanism is legacy - and not likely to be found in modern repositories. This - directory is ignored if $GIT_COMMON_DIR is set and - "$GIT_COMMON_DIR/branches" will be used instead. - - -hooks:: - Hooks are customization scripts used by various Git - commands. A handful of sample hooks are installed when - 'git init' is run, but all of them are disabled by - default. To enable, the `.sample` suffix has to be - removed from the filename by renaming. - Read linkgit:githooks[5] for more details about - each hook. This directory is ignored if $GIT_COMMON_DIR is set - and "$GIT_COMMON_DIR/hooks" will be used instead. - -common:: - When multiple working trees are used, most of files in - $GIT_DIR are per-worktree with a few known exceptions. All - files under 'common' however will be shared between all - working trees. - -index:: - The current index file for the repository. It is - usually not found in a bare repository. - -sharedindex.<SHA-1>:: - The shared index part, to be referenced by $GIT_DIR/index and - other temporary index files. Only valid in split index mode. - -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/info" will be used instead. - -info/refs:: - This file helps dumb transports discover what refs are - available in this repository. If the repository is - published for dumb transports, this file should be - regenerated by 'git update-server-info' every time a tag - or branch is created or modified. This is normally done - from the `hooks/update` hook, which is run by the - 'git-receive-pack' command when you 'git push' into the - repository. - -info/grafts:: - This file records fake commit ancestry information, to - pretend the set of parents a commit has is different - from how the commit was actually created. One record - per line describes a commit and its fake parents by - listing their 40-byte hexadecimal object names separated - by a space and terminated by a newline. -+ -Note that the grafts mechanism is outdated and can lead to problems -transferring objects between repositories; see linkgit:git-replace[1] -for a more flexible and robust system to do the same thing. - -info/exclude:: - This file, by convention among Porcelains, stores the - exclude pattern list. `.gitignore` is the per-directory - ignore file. 'git status', 'git add', 'git rm' and - 'git clean' look at it but the core Git commands do not look - at it. See also: linkgit:gitignore[5]. - -info/attributes:: - Defines which attributes to assign to a path, similar to per-directory - `.gitattributes` files. See also: linkgit:gitattributes[5]. - -info/sparse-checkout:: - This file stores sparse checkout patterns. - See also: linkgit:git-read-tree[1]. - -remotes:: - Stores shorthands for URL and default refnames for use - when interacting with remote repositories via 'git fetch', - 'git pull' and 'git push' commands. See the REMOTES section - in linkgit:git-fetch[1] for details. This mechanism is legacy - and not likely to be found in modern repositories. This - directory is ignored if $GIT_COMMON_DIR is set and - "$GIT_COMMON_DIR/remotes" will be used instead. - -logs:: - Records of changes made to refs are stored in this directory. - See linkgit:git-update-ref[1] for more information. This - directory is ignored if $GIT_COMMON_DIR is set and - "$GIT_COMMON_DIR/logs" will be used instead. - -logs/refs/heads/`name`:: - Records all changes made to the branch tip named `name`. - -logs/refs/tags/`name`:: - Records all changes made to the tag named `name`. - -shallow:: - This is similar to `info/grafts` but is internally used - and maintained by shallow clone mechanism. See `--depth` - option to linkgit:git-clone[1] and linkgit:git-fetch[1]. This - file is ignored if $GIT_COMMON_DIR is set and - "$GIT_COMMON_DIR/shallow" will be used instead. - -commondir:: - If this file exists, $GIT_COMMON_DIR (see linkgit:git[1]) will - be set to the path specified in this file if it is not - explicitly set. If the specified path is relative, it is - relative to $GIT_DIR. The repository with commondir is - incomplete without the repository pointed by "commondir". - -modules:: - Contains the git-repositories of the submodules. - -worktrees:: - Contains administrative data for linked - working trees. Each subdirectory contains the working tree-related - part of a linked working tree. This directory is ignored if - $GIT_COMMON_DIR is set, in which case - "$GIT_COMMON_DIR/worktrees" will be used instead. - -worktrees/<id>/gitdir:: - A text file containing the absolute path back to the .git file - that points to here. This is used to check if the linked - repository has been manually removed and there is no need to - keep this directory any more. The mtime of this file should be - updated every time the linked repository is accessed. - -worktrees/<id>/locked:: - If this file exists, the linked working tree may be on a - portable device and not available. The presence of this file - prevents `worktrees/<id>` from being pruned either automatically - or manually by `git worktree prune`. The file may contain a string - explaining why the repository is locked. - -worktrees/<id>/config.worktree:: - Working directory specific configuration file. - -include::technical/repository-version.txt[] - -SEE ALSO --------- -linkgit:git-init[1], -linkgit:git-clone[1], -linkgit:git-fetch[1], -linkgit:git-pack-refs[1], -linkgit:git-gc[1], -linkgit:git-checkout[1], -linkgit:gitglossary[7], -link:user-manual.html[The Git User's Manual] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitrevisions.txt b/third_party/git/Documentation/gitrevisions.txt deleted file mode 100644 index d407b7dee1..0000000000 --- a/third_party/git/Documentation/gitrevisions.txt +++ /dev/null @@ -1,36 +0,0 @@ -gitrevisions(7) -=============== - -NAME ----- -gitrevisions - Specifying revisions and ranges for Git - -SYNOPSIS --------- -gitrevisions - - -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 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] and -linkgit:git-push[1]) can also take revision parameters which denote -other objects than commits, e.g. blobs ("files") or trees -("directories of files"). - -include::revisions.txt[] - - -SEE ALSO --------- -linkgit:git-rev-parse[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitsubmodules.txt b/third_party/git/Documentation/gitsubmodules.txt deleted file mode 100644 index 0a890205b8..0000000000 --- a/third_party/git/Documentation/gitsubmodules.txt +++ /dev/null @@ -1,283 +0,0 @@ -gitsubmodules(7) -================ - -NAME ----- -gitsubmodules - mounting one repository inside another - -SYNOPSIS --------- - .gitmodules, $GIT_DIR/config ------------------- -git submodule -git <command> --recurse-submodules ------------------- - -DESCRIPTION ------------ - -A submodule is a repository embedded inside another repository. -The submodule has its own history; the repository it is embedded -in is called a superproject. - -On the filesystem, a submodule usually (but not always - see FORMS below) -consists of (i) a Git directory located under the `$GIT_DIR/modules/` -directory of its superproject, (ii) a working directory inside the -superproject's working directory, and a `.git` file at the root of -the submodule's working directory pointing to (i). - -Assuming the submodule has a Git directory at `$GIT_DIR/modules/foo/` -and a working directory at `path/to/bar/`, the superproject tracks the -submodule via a `gitlink` entry in the tree at `path/to/bar` and an entry -in its `.gitmodules` file (see linkgit:gitmodules[5]) of the form -`submodule.foo.path = path/to/bar`. - -The `gitlink` entry contains the object name of the commit that the -superproject expects the submodule's working directory to be at. - -The section `submodule.foo.*` in the `.gitmodules` file gives additional -hints to Git's porcelain layer. For example, the `submodule.foo.url` -setting specifies where to obtain the submodule. - -Submodules can be used for at least two different use cases: - -1. Using another project while maintaining independent history. - Submodules allow you to contain the working tree of another project - within your own working tree while keeping the history of both - projects separate. Also, since submodules are fixed to an arbitrary - version, the other project can be independently developed without - affecting the superproject, allowing the superproject project to - fix itself to new versions only when desired. - -2. Splitting a (logically single) project into multiple - repositories and tying them back together. This can be used to - overcome current limitations of Git's implementation to have - finer grained access: - - * Size of the Git repository: - In its current form Git scales up poorly for large repositories containing - content that is not compressed by delta computation between trees. - For example, you can use submodules to hold large binary assets - and these repositories can be shallowly cloned such that you do not - have a large history locally. - * Transfer size: - In its current form Git requires the whole working tree present. It - does not allow partial trees to be transferred in fetch or clone. - If the project you work on consists of multiple repositories tied - together as submodules in a superproject, you can avoid fetching the - working trees of the repositories you are not interested in. - * Access control: - By restricting user access to submodules, this can be used to implement - read/write policies for different users. - -The configuration of submodules -------------------------------- - -Submodule operations can be configured using the following mechanisms -(from highest to lowest precedence): - - * The command line for those commands that support taking submodules - as part of their pathspecs. Most commands have a boolean flag - `--recurse-submodules` which specify whether to recurse into submodules. - Examples are `grep` and `checkout`. - Some commands take enums, such as `fetch` and `push`, where you can - specify how submodules are affected. - - * The configuration inside the submodule. This includes `$GIT_DIR/config` - in the submodule, but also settings in the tree such as a `.gitattributes` - or `.gitignore` files that specify behavior of commands inside the - submodule. -+ -For example an effect from the submodule's `.gitignore` file -would be observed when you run `git status --ignore-submodules=none` in -the superproject. This collects information from the submodule's working -directory by running `status` in the submodule while paying attention -to the `.gitignore` file of the submodule. -+ -The submodule's `$GIT_DIR/config` file would come into play when running -`git push --recurse-submodules=check` in the superproject, as this would -check if the submodule has any changes not published to any remote. The -remotes are configured in the submodule as usual in the `$GIT_DIR/config` -file. - - * The configuration file `$GIT_DIR/config` in the superproject. - Git only recurses into active submodules (see "ACTIVE SUBMODULES" - section below). -+ -If the submodule is not yet initialized, then the configuration -inside the submodule does not exist yet, so where to -obtain the submodule from is configured here for example. - - * The `.gitmodules` file inside the superproject. A project usually - uses this file to suggest defaults for the upstream collection - of repositories for the mapping that is required between a - submodule's name and its path. -+ -This file mainly serves as the mapping between the name and path of submodules -in the superproject, such that the submodule's Git directory can be -located. -+ -If the submodule has never been initialized, this is the only place -where submodule configuration is found. It serves as the last fallback -to specify where to obtain the submodule from. - -FORMS ------ - -Submodules can take the following forms: - - * The basic form described in DESCRIPTION with a Git directory, -a working directory, a `gitlink`, and a `.gitmodules` entry. - - * "Old-form" submodule: A working directory with an embedded -`.git` directory, and the tracking `gitlink` and `.gitmodules` entry in -the superproject. This is typically found in repositories generated -using older versions of Git. -+ -It is possible to construct these old form repositories manually. -+ -When deinitialized or deleted (see below), the submodule's Git -directory is automatically moved to `$GIT_DIR/modules/<name>/` -of the superproject. - - * Deinitialized submodule: A `gitlink`, and a `.gitmodules` entry, -but no submodule working directory. The submodule's Git directory -may be there as after deinitializing the Git directory is kept around. -The directory which is supposed to be the working directory is empty instead. -+ -A submodule can be deinitialized by running `git submodule deinit`. -Besides emptying the working directory, this command only modifies -the superproject's `$GIT_DIR/config` file, so the superproject's history -is not affected. This can be undone using `git submodule init`. - - * Deleted submodule: A submodule can be deleted by running -`git rm <submodule path> && git commit`. This can be undone -using `git revert`. -+ -The deletion removes the superproject's tracking data, which are -both the `gitlink` entry and the section in the `.gitmodules` file. -The submodule's working directory is removed from the file -system, but the Git directory is kept around as it to make it -possible to checkout past commits without requiring fetching -from another repository. -+ -To completely remove a submodule, manually delete -`$GIT_DIR/modules/<name>/`. - -ACTIVE SUBMODULES ------------------ - -A submodule is considered active, - - 1. if `submodule.<name>.active` is set to `true` -+ -or - - 2. if the submodule's path matches the pathspec in `submodule.active` -+ -or - - 3. if `submodule.<name>.url` is set. - -and these are evaluated in this order. - -For example: - - [submodule "foo"] - active = false - url = https://example.org/foo - [submodule "bar"] - active = true - url = https://example.org/bar - [submodule "baz"] - url = https://example.org/baz - -In the above config only the submodule 'bar' and 'baz' are active, -'bar' due to (1) and 'baz' due to (3). 'foo' is inactive because -(1) takes precedence over (3) - -Note that (3) is a historical artefact and will be ignored if the -(1) and (2) specify that the submodule is not active. In other words, -if we have a `submodule.<name>.active` set to `false` or if the -submodule's path is excluded in the pathspec in `submodule.active`, the -url doesn't matter whether it is present or not. This is illustrated in -the example that follows. - - [submodule "foo"] - active = true - url = https://example.org/foo - [submodule "bar"] - url = https://example.org/bar - [submodule "baz"] - url = https://example.org/baz - [submodule "bob"] - ignore = true - [submodule] - active = b* - active = :(exclude) baz - -In here all submodules except 'baz' (foo, bar, bob) are active. -'foo' due to its own active flag and all the others due to the -submodule active pathspec, which specifies that any submodule -starting with 'b' except 'baz' are also active, regardless of the -presence of the .url field. - -Workflow for a third party library ----------------------------------- - - # add a submodule - git submodule add <url> <path> - - # occasionally update the submodule to a new version: - git -C <path> checkout <new version> - git add <path> - git commit -m "update submodule to new version" - - # See the list of submodules in a superproject - git submodule status - - # See FORMS on removing submodules - - -Workflow for an artificially split repo --------------------------------------- - - # Enable recursion for relevant commands, such that - # regular commands recurse into submodules by default - git config --global submodule.recurse true - - # Unlike the other commands below clone still needs - # its own recurse flag: - git clone --recurse <URL> <directory> - cd <directory> - - # Get to know the code: - git grep foo - git ls-files - - # Get new code - git fetch - git pull --rebase - - # change worktree - git checkout - git reset - -Implementation details ----------------------- - -When cloning or pulling a repository containing submodules the submodules -will not be checked out by default; You can instruct 'clone' to recurse -into submodules. The 'init' and 'update' subcommands of 'git submodule' -will maintain submodules checked out and at an appropriate revision in -your working tree. Alternatively you can set 'submodule.recurse' to have -'checkout' recursing into submodules. - - -SEE ALSO --------- -linkgit:git-submodule[1], linkgit:gitmodules[5]. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gittutorial-2.txt b/third_party/git/Documentation/gittutorial-2.txt deleted file mode 100644 index 8bdb7d0bd3..0000000000 --- a/third_party/git/Documentation/gittutorial-2.txt +++ /dev/null @@ -1,436 +0,0 @@ -gittutorial-2(7) -================ - -NAME ----- -gittutorial-2 - A tutorial introduction to Git: part two - -SYNOPSIS --------- -[verse] -git * - -DESCRIPTION ------------ - -You should work through linkgit:gittutorial[7] before reading this tutorial. - -The goal of this tutorial is to introduce two fundamental pieces of -Git's architecture--the object database and the index file--and to -provide the reader with everything necessary to understand the rest -of the Git documentation. - -The Git object database ------------------------ - -Let's start a new project and create a small amount of history: - ------------------------------------------------- -$ mkdir test-project -$ cd test-project -$ git init -Initialized empty Git repository in .git/ -$ echo 'hello world' > file.txt -$ git add . -$ git commit -a -m "initial commit" -[master (root-commit) 54196cc] initial commit - 1 file changed, 1 insertion(+) - create mode 100644 file.txt -$ echo 'hello world!' >file.txt -$ git commit -a -m "add emphasis" -[master c4d59f3] add emphasis - 1 file changed, 1 insertion(+), 1 deletion(-) ------------------------------------------------- - -What are the 7 digits of hex that Git responded to the commit with? - -We saw in part one of the tutorial that commits have names like this. -It turns out that every object in the Git history is stored under -a 40-digit hex name. That name is the SHA-1 hash of the object's -contents; among other things, this ensures that Git will never store -the same data twice (since identical data is given an identical SHA-1 -name), and that the contents of a Git object will never change (since -that would change the object's name as well). The 7 char hex strings -here are simply the abbreviation of such 40 character long strings. -Abbreviations can be used everywhere where the 40 character strings -can be used, so long as they are unambiguous. - -It is expected that the content of the commit object you created while -following the example above generates a different SHA-1 hash than -the one shown above because the commit object records the time when -it was created and the name of the person performing the commit. - -We can ask Git about this particular object with the `cat-file` -command. Don't copy the 40 hex digits from this example but use those -from your own version. Note that you can shorten it to only a few -characters to save yourself typing all 40 hex digits: - ------------------------------------------------- -$ git cat-file -t 54196cc2 -commit -$ git cat-file commit 54196cc2 -tree 92b8b694ffb1675e5975148e1121810081dbdffe -author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500 -committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500 - -initial commit ------------------------------------------------- - -A tree can refer to one or more "blob" objects, each corresponding to -a file. In addition, a tree can also refer to other tree objects, -thus creating a directory hierarchy. You can examine the contents of -any tree using ls-tree (remember that a long enough initial portion -of the SHA-1 will also work): - ------------------------------------------------- -$ git ls-tree 92b8b694 -100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad file.txt ------------------------------------------------- - -Thus we see that this tree has one file in it. The SHA-1 hash is a -reference to that file's data: - ------------------------------------------------- -$ git cat-file -t 3b18e512 -blob ------------------------------------------------- - -A "blob" is just file data, which we can also examine with cat-file: - ------------------------------------------------- -$ git cat-file blob 3b18e512 -hello world ------------------------------------------------- - -Note that this is the old file data; so the object that Git named in -its response to the initial tree was a tree with a snapshot of the -directory state that was recorded by the first commit. - -All of these objects are stored under their SHA-1 names inside the Git -directory: - ------------------------------------------------- -$ find .git/objects/ -.git/objects/ -.git/objects/pack -.git/objects/info -.git/objects/3b -.git/objects/3b/18e512dba79e4c8300dd08aeb37f8e728b8dad -.git/objects/92 -.git/objects/92/b8b694ffb1675e5975148e1121810081dbdffe -.git/objects/54 -.git/objects/54/196cc2703dc165cbd373a65a4dcf22d50ae7f7 -.git/objects/a0 -.git/objects/a0/423896973644771497bdc03eb99d5281615b51 -.git/objects/d0 -.git/objects/d0/492b368b66bdabf2ac1fd8c92b39d3db916e59 -.git/objects/c4 -.git/objects/c4/d59f390b9cfd4318117afde11d601c1085f241 ------------------------------------------------- - -and the contents of these files is just the compressed data plus a -header identifying their length and their type. The type is either a -blob, a tree, a commit, or a tag. - -The simplest commit to find is the HEAD commit, which we can find -from .git/HEAD: - ------------------------------------------------- -$ cat .git/HEAD -ref: refs/heads/master ------------------------------------------------- - -As you can see, this tells us which branch we're currently on, and it -tells us this by naming a file under the .git directory, which itself -contains a SHA-1 name referring to a commit object, which we can -examine with cat-file: - ------------------------------------------------- -$ cat .git/refs/heads/master -c4d59f390b9cfd4318117afde11d601c1085f241 -$ git cat-file -t c4d59f39 -commit -$ git cat-file commit c4d59f39 -tree d0492b368b66bdabf2ac1fd8c92b39d3db916e59 -parent 54196cc2703dc165cbd373a65a4dcf22d50ae7f7 -author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500 -committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500 - -add emphasis ------------------------------------------------- - -The "tree" object here refers to the new state of the tree: - ------------------------------------------------- -$ git ls-tree d0492b36 -100644 blob a0423896973644771497bdc03eb99d5281615b51 file.txt -$ git cat-file blob a0423896 -hello world! ------------------------------------------------- - -and the "parent" object refers to the previous commit: - ------------------------------------------------- -$ git cat-file commit 54196cc2 -tree 92b8b694ffb1675e5975148e1121810081dbdffe -author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500 -committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500 - -initial commit ------------------------------------------------- - -The tree object is the tree we examined first, and this commit is -unusual in that it lacks any parent. - -Most commits have only one parent, but it is also common for a commit -to have multiple parents. In that case the commit represents a -merge, with the parent references pointing to the heads of the merged -branches. - -Besides blobs, trees, and commits, the only remaining type of object -is a "tag", which we won't discuss here; refer to linkgit:git-tag[1] -for details. - -So now we know how Git uses the object database to represent a -project's history: - - * "commit" objects refer to "tree" objects representing the - snapshot of a directory tree at a particular point in the - history, and refer to "parent" commits to show how they're - connected into the project history. - * "tree" objects represent the state of a single directory, - associating directory names to "blob" objects containing file - data and "tree" objects containing subdirectory information. - * "blob" objects contain file data without any other structure. - * References to commit objects at the head of each branch are - stored in files under .git/refs/heads/. - * The name of the current branch is stored in .git/HEAD. - -Note, by the way, that lots of commands take a tree as an argument. -But as we can see above, a tree can be referred to in many different -ways--by the SHA-1 name for that tree, by the name of a commit that -refers to the tree, by the name of a branch whose head refers to that -tree, etc.--and most such commands can accept any of these names. - -In command synopses, the word "tree-ish" is sometimes used to -designate such an argument. - -The index file --------------- - -The primary tool we've been using to create commits is `git-commit --a`, which creates a commit including every change you've made to -your working tree. But what if you want to commit changes only to -certain files? Or only certain changes to certain files? - -If we look at the way commits are created under the cover, we'll see -that there are more flexible ways creating commits. - -Continuing with our test-project, let's modify file.txt again: - ------------------------------------------------- -$ echo "hello world, again" >>file.txt ------------------------------------------------- - -but this time instead of immediately making the commit, let's take an -intermediate step, and ask for diffs along the way to keep track of -what's happening: - ------------------------------------------------- -$ git diff ---- a/file.txt -+++ b/file.txt -@@ -1 +1,2 @@ - hello world! -+hello world, again -$ git add file.txt -$ git diff ------------------------------------------------- - -The last diff is empty, but no new commits have been made, and the -head still doesn't contain the new line: - ------------------------------------------------- -$ git diff HEAD -diff --git a/file.txt b/file.txt -index a042389..513feba 100644 ---- a/file.txt -+++ b/file.txt -@@ -1 +1,2 @@ - hello world! -+hello world, again ------------------------------------------------- - -So 'git diff' is comparing against something other than the head. -The thing that it's comparing against is actually the index file, -which is stored in .git/index in a binary format, but whose contents -we can examine with ls-files: - ------------------------------------------------- -$ git ls-files --stage -100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt -$ git cat-file -t 513feba2 -blob -$ git cat-file blob 513feba2 -hello world! -hello world, again ------------------------------------------------- - -So what our 'git add' did was store a new blob and then put -a reference to it in the index file. If we modify the file again, -we'll see that the new modifications are reflected in the 'git diff' -output: - ------------------------------------------------- -$ echo 'again?' >>file.txt -$ git diff -index 513feba..ba3da7b 100644 ---- a/file.txt -+++ b/file.txt -@@ -1,2 +1,3 @@ - hello world! - hello world, again -+again? ------------------------------------------------- - -With the right arguments, 'git diff' can also show us the difference -between the working directory and the last commit, or between the -index and the last commit: - ------------------------------------------------- -$ git diff HEAD -diff --git a/file.txt b/file.txt -index a042389..ba3da7b 100644 ---- a/file.txt -+++ b/file.txt -@@ -1 +1,3 @@ - hello world! -+hello world, again -+again? -$ git diff --cached -diff --git a/file.txt b/file.txt -index a042389..513feba 100644 ---- a/file.txt -+++ b/file.txt -@@ -1 +1,2 @@ - hello world! -+hello world, again ------------------------------------------------- - -At any time, we can create a new commit using 'git commit' (without -the "-a" option), and verify that the state committed only includes the -changes stored in the index file, not the additional change that is -still only in our working tree: - ------------------------------------------------- -$ git commit -m "repeat" -$ git diff HEAD -diff --git a/file.txt b/file.txt -index 513feba..ba3da7b 100644 ---- a/file.txt -+++ b/file.txt -@@ -1,2 +1,3 @@ - hello world! - hello world, again -+again? ------------------------------------------------- - -So by default 'git commit' uses the index to create the commit, not -the working tree; the "-a" option to commit tells it to first update -the index with all changes in the working tree. - -Finally, it's worth looking at the effect of 'git add' on the index -file: - ------------------------------------------------- -$ echo "goodbye, world" >closing.txt -$ git add closing.txt ------------------------------------------------- - -The effect of the 'git add' was to add one entry to the index file: - ------------------------------------------------- -$ git ls-files --stage -100644 8b9743b20d4b15be3955fc8d5cd2b09cd2336138 0 closing.txt -100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt ------------------------------------------------- - -And, as you can see with cat-file, this new entry refers to the -current contents of the file: - ------------------------------------------------- -$ git cat-file blob 8b9743b2 -goodbye, world ------------------------------------------------- - -The "status" command is a useful way to get a quick summary of the -situation: - ------------------------------------------------- -$ git status -On branch master -Changes to be committed: - (use "git restore --staged <file>..." to unstage) - - new file: closing.txt - -Changes not staged for commit: - (use "git add <file>..." to update what will be committed) - (use "git restore <file>..." to discard changes in working directory) - - modified: file.txt - ------------------------------------------------- - -Since the current state of closing.txt is cached in the index file, -it is listed as "Changes to be committed". Since file.txt has -changes in the working directory that aren't reflected in the index, -it is marked "changed but not updated". At this point, running "git -commit" would create a commit that added closing.txt (with its new -contents), but that didn't modify file.txt. - -Also, note that a bare `git diff` shows the changes to file.txt, but -not the addition of closing.txt, because the version of closing.txt -in the index file is identical to the one in the working directory. - -In addition to being the staging area for new commits, the index file -is also populated from the object database when checking out a -branch, and is used to hold the trees involved in a merge operation. -See linkgit:gitcore-tutorial[7] and the relevant man -pages for details. - -What next? ----------- - -At this point you should know everything necessary to read the man -pages for any of the git commands; one good place to start would be -with the commands mentioned in linkgit:giteveryday[7]. You -should be able to find any unknown jargon in linkgit:gitglossary[7]. - -The link:user-manual.html[Git User's Manual] provides a more -comprehensive introduction to Git. - -linkgit:gitcvs-migration[7] explains how to -import a CVS repository into Git, and shows how to use Git in a -CVS-like way. - -For some interesting examples of Git use, see the -link:howto-index.html[howtos]. - -For Git developers, linkgit:gitcore-tutorial[7] goes -into detail on the lower-level Git mechanisms involved in, for -example, creating a new commit. - -SEE ALSO --------- -linkgit:gittutorial[7], -linkgit:gitcvs-migration[7], -linkgit:gitcore-tutorial[7], -linkgit:gitglossary[7], -linkgit:git-help[1], -linkgit:giteveryday[7], -link:user-manual.html[The Git User's Manual] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gittutorial.txt b/third_party/git/Documentation/gittutorial.txt deleted file mode 100644 index 59ef5cef1f..0000000000 --- a/third_party/git/Documentation/gittutorial.txt +++ /dev/null @@ -1,677 +0,0 @@ -gittutorial(7) -============== - -NAME ----- -gittutorial - A tutorial introduction to Git - -SYNOPSIS --------- -[verse] -git * - -DESCRIPTION ------------ - -This tutorial explains how to import a new project into Git, make -changes to it, and share changes with other developers. - -If you are instead primarily interested in using Git to fetch a project, -for example, to test the latest version, you may prefer to start with -the first two chapters of link:user-manual.html[The Git User's Manual]. - -First, note that you can get documentation for a command such as -`git log --graph` with: - ------------------------------------------------- -$ man git-log ------------------------------------------------- - -or: - ------------------------------------------------- -$ git help log ------------------------------------------------- - -With the latter, you can use the manual viewer of your choice; see -linkgit:git-help[1] for more information. - -It is a good idea to introduce yourself to Git with your name and -public email address before doing any operation. The easiest -way to do so is: - ------------------------------------------------- -$ git config --global user.name "Your Name Comes Here" -$ git config --global user.email you@yourdomain.example.com ------------------------------------------------- - - -Importing a new project ------------------------ - -Assume you have a tarball project.tar.gz with your initial work. You -can place it under Git revision control as follows. - ------------------------------------------------- -$ tar xzf project.tar.gz -$ cd project -$ git init ------------------------------------------------- - -Git will reply - ------------------------------------------------- -Initialized empty Git repository in .git/ ------------------------------------------------- - -You've now initialized the working directory--you may notice a new -directory created, named ".git". - -Next, tell Git to take a snapshot of the contents of all files under the -current directory (note the '.'), with 'git add': - ------------------------------------------------- -$ git add . ------------------------------------------------- - -This snapshot is now stored in a temporary staging area which Git calls -the "index". You can permanently store the contents of the index in the -repository with 'git commit': - ------------------------------------------------- -$ git commit ------------------------------------------------- - -This will prompt you for a commit message. You've now stored the first -version of your project in Git. - -Making changes --------------- - -Modify some files, then add their updated contents to the index: - ------------------------------------------------- -$ git add file1 file2 file3 ------------------------------------------------- - -You are now ready to commit. You can see what is about to be committed -using 'git diff' with the --cached option: - ------------------------------------------------- -$ git diff --cached ------------------------------------------------- - -(Without --cached, 'git diff' will show you any changes that -you've made but not yet added to the index.) You can also get a brief -summary of the situation with 'git status': - ------------------------------------------------- -$ git status -On branch master -Changes to be committed: -Your branch is up to date with 'origin/master'. - (use "git restore --staged <file>..." to unstage) - - modified: file1 - modified: file2 - modified: file3 - ------------------------------------------------- - -If you need to make any further adjustments, do so now, and then add any -newly modified content to the index. Finally, commit your changes with: - ------------------------------------------------- -$ git commit ------------------------------------------------- - -This will again prompt you for a message describing the change, and then -record a new version of the project. - -Alternatively, instead of running 'git add' beforehand, you can use - ------------------------------------------------- -$ git commit -a ------------------------------------------------- - -which will automatically notice any modified (but not new) files, add -them to the index, and commit, all in one step. - -A note on commit messages: Though not required, it's a good idea to -begin the commit message with a single short (less than 50 character) -line summarizing the change, followed by a blank line and then a more -thorough description. The text up to the first blank line in a commit -message is treated as the commit title, and that title is used -throughout Git. For example, linkgit:git-format-patch[1] turns a -commit into email, and it uses the title on the Subject line and the -rest of the commit in the body. - -Git tracks content not files ----------------------------- - -Many revision control systems provide an `add` command that tells the -system to start tracking changes to a new file. Git's `add` command -does something simpler and more powerful: 'git add' is used both for new -and newly modified files, and in both cases it takes a snapshot of the -given files and stages that content in the index, ready for inclusion in -the next commit. - -Viewing project history ------------------------ - -At any point you can view the history of your changes using - ------------------------------------------------- -$ git log ------------------------------------------------- - -If you also want to see complete diffs at each step, use - ------------------------------------------------- -$ git log -p ------------------------------------------------- - -Often the overview of the change is useful to get a feel of -each step - ------------------------------------------------- -$ git log --stat --summary ------------------------------------------------- - -Managing branches ------------------ - -A single Git repository can maintain multiple branches of -development. To create a new branch named "experimental", use - ------------------------------------------------- -$ git branch experimental ------------------------------------------------- - -If you now run - ------------------------------------------------- -$ git branch ------------------------------------------------- - -you'll get a list of all existing branches: - ------------------------------------------------- - experimental -* master ------------------------------------------------- - -The "experimental" branch is the one you just created, and the -"master" branch is a default branch that was created for you -automatically. The asterisk marks the branch you are currently on; -type - ------------------------------------------------- -$ git switch experimental ------------------------------------------------- - -to switch to the experimental branch. Now edit a file, commit the -change, and switch back to the master branch: - ------------------------------------------------- -(edit file) -$ git commit -a -$ git switch master ------------------------------------------------- - -Check that the change you made is no longer visible, since it was -made on the experimental branch and you're back on the master branch. - -You can make a different change on the master branch: - ------------------------------------------------- -(edit file) -$ git commit -a ------------------------------------------------- - -at this point the two branches have diverged, with different changes -made in each. To merge the changes made in experimental into master, run - ------------------------------------------------- -$ git merge experimental ------------------------------------------------- - -If the changes don't conflict, you're done. If there are conflicts, -markers will be left in the problematic files showing the conflict; - ------------------------------------------------- -$ git diff ------------------------------------------------- - -will show this. Once you've edited the files to resolve the -conflicts, - ------------------------------------------------- -$ git commit -a ------------------------------------------------- - -will commit the result of the merge. Finally, - ------------------------------------------------- -$ gitk ------------------------------------------------- - -will show a nice graphical representation of the resulting history. - -At this point you could delete the experimental branch with - ------------------------------------------------- -$ git branch -d experimental ------------------------------------------------- - -This command ensures that the changes in the experimental branch are -already in the current branch. - -If you develop on a branch crazy-idea, then regret it, you can always -delete the branch with - -------------------------------------- -$ git branch -D crazy-idea -------------------------------------- - -Branches are cheap and easy, so this is a good way to try something -out. - -Using Git for collaboration ---------------------------- - -Suppose that Alice has started a new project with a Git repository in -/home/alice/project, and that Bob, who has a home directory on the -same machine, wants to contribute. - -Bob begins with: - ------------------------------------------------- -bob$ git clone /home/alice/project myrepo ------------------------------------------------- - -This creates a new directory "myrepo" containing a clone of Alice's -repository. The clone is on an equal footing with the original -project, possessing its own copy of the original project's history. - -Bob then makes some changes and commits them: - ------------------------------------------------- -(edit files) -bob$ git commit -a -(repeat as necessary) ------------------------------------------------- - -When he's ready, he tells Alice to pull changes from the repository -at /home/bob/myrepo. She does this with: - ------------------------------------------------- -alice$ cd /home/alice/project -alice$ git pull /home/bob/myrepo master ------------------------------------------------- - -This merges the changes from Bob's "master" branch into Alice's -current branch. If Alice has made her own changes in the meantime, -then she may need to manually fix any conflicts. - -The "pull" command thus performs two operations: it fetches changes -from a remote branch, then merges them into the current branch. - -Note that in general, Alice would want her local changes committed before -initiating this "pull". If Bob's work conflicts with what Alice did since -their histories forked, Alice will use her working tree and the index to -resolve conflicts, and existing local changes will interfere with the -conflict resolution process (Git will still perform the fetch but will -refuse to merge --- Alice will have to get rid of her local changes in -some way and pull again when this happens). - -Alice can peek at what Bob did without merging first, using the "fetch" -command; this allows Alice to inspect what Bob did, using a special -symbol "FETCH_HEAD", in order to determine if he has anything worth -pulling, like this: - ------------------------------------------------- -alice$ git fetch /home/bob/myrepo master -alice$ git log -p HEAD..FETCH_HEAD ------------------------------------------------- - -This operation is safe even if Alice has uncommitted local changes. -The range notation "HEAD..FETCH_HEAD" means "show everything that is reachable -from the FETCH_HEAD but exclude anything that is reachable from HEAD". -Alice already knows everything that leads to her current state (HEAD), -and reviews what Bob has in his state (FETCH_HEAD) that she has not -seen with this command. - -If Alice wants to visualize what Bob did since their histories forked -she can issue the following command: - ------------------------------------------------- -$ gitk HEAD..FETCH_HEAD ------------------------------------------------- - -This uses the same two-dot range notation we saw earlier with 'git log'. - -Alice may want to view what both of them did since they forked. -She can use three-dot form instead of the two-dot form: - ------------------------------------------------- -$ gitk HEAD...FETCH_HEAD ------------------------------------------------- - -This means "show everything that is reachable from either one, but -exclude anything that is reachable from both of them". - -Please note that these range notation can be used with both gitk -and "git log". - -After inspecting what Bob did, if there is nothing urgent, Alice may -decide to continue working without pulling from Bob. If Bob's history -does have something Alice would immediately need, Alice may choose to -stash her work-in-progress first, do a "pull", and then finally unstash -her work-in-progress on top of the resulting history. - -When you are working in a small closely knit group, it is not -unusual to interact with the same repository over and over -again. By defining 'remote' repository shorthand, you can make -it easier: - ------------------------------------------------- -alice$ git remote add bob /home/bob/myrepo ------------------------------------------------- - -With this, Alice can perform the first part of the "pull" operation -alone using the 'git fetch' command without merging them with her own -branch, using: - -------------------------------------- -alice$ git fetch bob -------------------------------------- - -Unlike the longhand form, when Alice fetches from Bob using a -remote repository shorthand set up with 'git remote', what was -fetched is stored in a remote-tracking branch, in this case -`bob/master`. So after this: - -------------------------------------- -alice$ git log -p master..bob/master -------------------------------------- - -shows a list of all the changes that Bob made since he branched from -Alice's master branch. - -After examining those changes, Alice -could merge the changes into her master branch: - -------------------------------------- -alice$ git merge bob/master -------------------------------------- - -This `merge` can also be done by 'pulling from her own remote-tracking -branch', like this: - -------------------------------------- -alice$ git pull . remotes/bob/master -------------------------------------- - -Note that git pull always merges into the current branch, -regardless of what else is given on the command line. - -Later, Bob can update his repo with Alice's latest changes using - -------------------------------------- -bob$ git pull -------------------------------------- - -Note that he doesn't need to give the path to Alice's repository; -when Bob cloned Alice's repository, Git stored the location of her -repository in the repository configuration, and that location is -used for pulls: - -------------------------------------- -bob$ git config --get remote.origin.url -/home/alice/project -------------------------------------- - -(The complete configuration created by 'git clone' is visible using -`git config -l`, and the linkgit:git-config[1] man page -explains the meaning of each option.) - -Git also keeps a pristine copy of Alice's master branch under the -name "origin/master": - -------------------------------------- -bob$ git branch -r - origin/master -------------------------------------- - -If Bob later decides to work from a different host, he can still -perform clones and pulls using the ssh protocol: - -------------------------------------- -bob$ git clone alice.org:/home/alice/project myrepo -------------------------------------- - -Alternatively, Git has a native protocol, or can use http; -see linkgit:git-pull[1] for details. - -Git can also be used in a CVS-like mode, with a central repository -that various users push changes to; see linkgit:git-push[1] and -linkgit:gitcvs-migration[7]. - -Exploring history ------------------ - -Git history is represented as a series of interrelated commits. We -have already seen that the 'git log' command can list those commits. -Note that first line of each git log entry also gives a name for the -commit: - -------------------------------------- -$ git log -commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 -Author: Junio C Hamano <junkio@cox.net> -Date: Tue May 16 17:18:22 2006 -0700 - - merge-base: Clarify the comments on post processing. -------------------------------------- - -We can give this name to 'git show' to see the details about this -commit. - -------------------------------------- -$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 -------------------------------------- - -But there are other ways to refer to commits. You can use any initial -part of the name that is long enough to uniquely identify the commit: - -------------------------------------- -$ git show c82a22c39c # the first few characters of the name are - # usually enough -$ git show HEAD # the tip of the current branch -$ git show experimental # the tip of the "experimental" branch -------------------------------------- - -Every commit usually has one "parent" commit -which points to the previous state of the project: - -------------------------------------- -$ git show HEAD^ # to see the parent of HEAD -$ git show HEAD^^ # to see the grandparent of HEAD -$ git show HEAD~4 # to see the great-great grandparent of HEAD -------------------------------------- - -Note that merge commits may have more than one parent: - -------------------------------------- -$ git show HEAD^1 # show the first parent of HEAD (same as HEAD^) -$ git show HEAD^2 # show the second parent of HEAD -------------------------------------- - -You can also give commits names of your own; after running - -------------------------------------- -$ git tag v2.5 1b2e1d63ff -------------------------------------- - -you can refer to 1b2e1d63ff by the name "v2.5". If you intend to -share this name with other people (for example, to identify a release -version), you should create a "tag" object, and perhaps sign it; see -linkgit:git-tag[1] for details. - -Any Git command that needs to know a commit can take any of these -names. For example: - -------------------------------------- -$ git diff v2.5 HEAD # compare the current HEAD to v2.5 -$ git branch stable v2.5 # start a new branch named "stable" based - # at v2.5 -$ git reset --hard HEAD^ # reset your current branch and working - # directory to its state at HEAD^ -------------------------------------- - -Be careful with that last command: in addition to losing any changes -in the working directory, it will also remove all later commits from -this branch. If this branch is the only branch containing those -commits, they will be lost. Also, don't use 'git reset' on a -publicly-visible branch that other developers pull from, as it will -force needless merges on other developers to clean up the history. -If you need to undo changes that you have pushed, use 'git revert' -instead. - -The 'git grep' command can search for strings in any version of your -project, so - -------------------------------------- -$ git grep "hello" v2.5 -------------------------------------- - -searches for all occurrences of "hello" in v2.5. - -If you leave out the commit name, 'git grep' will search any of the -files it manages in your current directory. So - -------------------------------------- -$ git grep "hello" -------------------------------------- - -is a quick way to search just the files that are tracked by Git. - -Many Git commands also take sets of commits, which can be specified -in a number of ways. Here are some examples with 'git log': - -------------------------------------- -$ git log v2.5..v2.6 # commits between v2.5 and v2.6 -$ git log v2.5.. # commits since v2.5 -$ git log --since="2 weeks ago" # commits from the last 2 weeks -$ git log v2.5.. Makefile # commits since v2.5 which modify - # Makefile -------------------------------------- - -You can also give 'git log' a "range" of commits where the first is not -necessarily an ancestor of the second; for example, if the tips of -the branches "stable" and "master" diverged from a common -commit some time ago, then - -------------------------------------- -$ git log stable..master -------------------------------------- - -will list commits made in the master branch but not in the -stable branch, while - -------------------------------------- -$ git log master..stable -------------------------------------- - -will show the list of commits made on the stable branch but not -the master branch. - -The 'git log' command has a weakness: it must present commits in a -list. When the history has lines of development that diverged and -then merged back together, the order in which 'git log' presents -those commits is meaningless. - -Most projects with multiple contributors (such as the Linux kernel, -or Git itself) have frequent merges, and 'gitk' does a better job of -visualizing their history. For example, - -------------------------------------- -$ gitk --since="2 weeks ago" drivers/ -------------------------------------- - -allows you to browse any commits from the last 2 weeks of commits -that modified files under the "drivers" directory. (Note: you can -adjust gitk's fonts by holding down the control key while pressing -"-" or "+".) - -Finally, most commands that take filenames will optionally allow you -to precede any filename by a commit, to specify a particular version -of the file: - -------------------------------------- -$ git diff v2.5:Makefile HEAD:Makefile.in -------------------------------------- - -You can also use 'git show' to see any such file: - -------------------------------------- -$ git show v2.5:Makefile -------------------------------------- - -Next Steps ----------- - -This tutorial should be enough to perform basic distributed revision -control for your projects. However, to fully understand the depth -and power of Git you need to understand two simple ideas on which it -is based: - - * The object database is the rather elegant system used to - store the history of your project--files, directories, and - commits. - - * The index file is a cache of the state of a directory tree, - used to create commits, check out working directories, and - hold the various trees involved in a merge. - -Part two of this tutorial explains the object -database, the index file, and a few other odds and ends that you'll -need to make the most of Git. You can find it at linkgit:gittutorial-2[7]. - -If you don't want to continue with that right away, a few other -digressions that may be interesting at this point are: - - * linkgit:git-format-patch[1], linkgit:git-am[1]: These convert - series of git commits into emailed patches, and vice versa, - useful for projects such as the Linux kernel which rely heavily - on emailed patches. - - * linkgit:git-bisect[1]: When there is a regression in your - project, one way to track down the bug is by searching through - the history to find the exact commit that's to blame. Git bisect - can help you perform a binary search for that commit. It is - smart enough to perform a close-to-optimal search even in the - case of complex non-linear history with lots of merged branches. - - * linkgit:gitworkflows[7]: Gives an overview of recommended - workflows. - - * linkgit:giteveryday[7]: Everyday Git with 20 Commands Or So. - - * linkgit:gitcvs-migration[7]: Git for CVS users. - -SEE ALSO --------- -linkgit:gittutorial-2[7], -linkgit:gitcvs-migration[7], -linkgit:gitcore-tutorial[7], -linkgit:gitglossary[7], -linkgit:git-help[1], -linkgit:gitworkflows[7], -linkgit:giteveryday[7], -link:user-manual.html[The Git User's Manual] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitweb.conf.txt b/third_party/git/Documentation/gitweb.conf.txt deleted file mode 100644 index 35317e71c8..0000000000 --- a/third_party/git/Documentation/gitweb.conf.txt +++ /dev/null @@ -1,970 +0,0 @@ -gitweb.conf(5) -============== - -NAME ----- -gitweb.conf - Gitweb (Git web interface) configuration file - -SYNOPSIS --------- -/etc/gitweb.conf, /etc/gitweb-common.conf, $GITWEBDIR/gitweb_config.perl - -DESCRIPTION ------------ - -The gitweb CGI script for viewing Git repositories over the web uses a -perl script fragment as its configuration file. You can set variables -using "`our $variable = value`"; text from a "#" character until the -end of a line is ignored. See *perlsyn*(1) for details. - -An example: - ------------------------------------------------- -# gitweb configuration file for http://git.example.org -# -our $projectroot = "/srv/git"; # FHS recommendation -our $site_name = 'Example.org >> Repos'; ------------------------------------------------- - - -The configuration file is used to override the default settings that -were built into gitweb at the time the 'gitweb.cgi' script was generated. - -While one could just alter the configuration settings in the gitweb -CGI itself, those changes would be lost upon upgrade. Configuration -settings might also be placed into a file in the same directory as the -CGI script with the default name 'gitweb_config.perl' -- allowing -one to have multiple gitweb instances with different configurations by -the use of symlinks. - -Note that some configuration can be controlled on per-repository rather than -gitweb-wide basis: see "Per-repository gitweb configuration" subsection on -linkgit:gitweb[1] manpage. - - -DISCUSSION ----------- -Gitweb reads configuration data from the following sources in the -following order: - - * built-in values (some set during build stage), - - * common system-wide configuration file (defaults to - `/etc/gitweb-common.conf`), - - * either per-instance configuration file (defaults to 'gitweb_config.perl' - in the same directory as the installed gitweb), or if it does not exists - then fallback system-wide configuration file (defaults to `/etc/gitweb.conf`). - -Values obtained in later configuration files override values obtained earlier -in the above sequence. - -Locations of the common system-wide configuration file, the fallback -system-wide configuration file and the per-instance configuration file -are defined at compile time using build-time Makefile configuration -variables, respectively `GITWEB_CONFIG_COMMON`, `GITWEB_CONFIG_SYSTEM` -and `GITWEB_CONFIG`. - -You can also override locations of gitweb configuration files during -runtime by setting the following environment variables: -`GITWEB_CONFIG_COMMON`, `GITWEB_CONFIG_SYSTEM` and `GITWEB_CONFIG` -to a non-empty value. - - -The syntax of the configuration files is that of Perl, since these files are -handled by sourcing them as fragments of Perl code (the language that -gitweb itself is written in). Variables are typically set using the -`our` qualifier (as in "`our $variable = <value>;`") to avoid syntax -errors if a new version of gitweb no longer uses a variable and therefore -stops declaring it. - -You can include other configuration file using read_config_file() -subroutine. For example, one might want to put gitweb configuration -related to access control for viewing repositories via Gitolite (one -of Git repository management tools) in a separate file, e.g. in -`/etc/gitweb-gitolite.conf`. To include it, put - --------------------------------------------------- -read_config_file("/etc/gitweb-gitolite.conf"); --------------------------------------------------- - -somewhere in gitweb configuration file used, e.g. in per-installation -gitweb configuration file. Note that read_config_file() checks itself -that the file it reads exists, and does nothing if it is not found. -It also handles errors in included file. - - -The default configuration with no configuration file at all may work -perfectly well for some installations. Still, a configuration file is -useful for customizing or tweaking the behavior of gitweb in many ways, and -some optional features will not be present unless explicitly enabled using -the configurable `%features` variable (see also "Configuring gitweb -features" section below). - - -CONFIGURATION VARIABLES ------------------------ -Some configuration variables have their default values (embedded in the CGI -script) set during building gitweb -- if that is the case, this fact is put -in their description. See gitweb's 'INSTALL' file for instructions on building -and installing gitweb. - - -Location of repositories -~~~~~~~~~~~~~~~~~~~~~~~~ -The configuration variables described below control how gitweb finds -Git repositories, and how repositories are displayed and accessed. - -See also "Repositories" and later subsections in linkgit:gitweb[1] manpage. - -$projectroot:: - Absolute filesystem path which will be prepended to project path; - the path to repository is `$projectroot/$project`. Set to - `$GITWEB_PROJECTROOT` during installation. This variable has to be - set correctly for gitweb to find repositories. -+ -For example, if `$projectroot` is set to "/srv/git" by putting the following -in gitweb config file: -+ ----------------------------------------------------------------------------- -our $projectroot = "/srv/git"; ----------------------------------------------------------------------------- -+ -then -+ ------------------------------------------------- -http://git.example.com/gitweb.cgi?p=foo/bar.git ------------------------------------------------- -+ -and its path_info based equivalent -+ ------------------------------------------------- -http://git.example.com/gitweb.cgi/foo/bar.git ------------------------------------------------- -+ -will map to the path `/srv/git/foo/bar.git` on the filesystem. - -$projects_list:: - Name of a plain text file listing projects, or a name of directory - to be scanned for projects. -+ -Project list files should list one project per line, with each line -having the following format -+ ------------------------------------------------------------------------------ -<URI-encoded filesystem path to repository> SP <URI-encoded repository owner> ------------------------------------------------------------------------------ -+ -The default value of this variable is determined by the `GITWEB_LIST` -makefile variable at installation time. If this variable is empty, gitweb -will fall back to scanning the `$projectroot` directory for repositories. - -$project_maxdepth:: - If `$projects_list` variable is unset, gitweb will recursively - scan filesystem for Git repositories. The `$project_maxdepth` - is used to limit traversing depth, relative to `$projectroot` - (starting point); it means that directories which are further - from `$projectroot` than `$project_maxdepth` will be skipped. -+ -It is purely performance optimization, originally intended for MacOS X, -where recursive directory traversal is slow. Gitweb follows symbolic -links, but it detects cycles, ignoring any duplicate files and directories. -+ -The default value of this variable is determined by the build-time -configuration variable `GITWEB_PROJECT_MAXDEPTH`, which defaults to -2007. - -$export_ok:: - Show repository only if this file exists (in repository). Only - effective if this variable evaluates to true. Can be set when - building gitweb by setting `GITWEB_EXPORT_OK`. This path is - relative to `GIT_DIR`. git-daemon[1] uses 'git-daemon-export-ok', - unless started with `--export-all`. By default this variable is - not set, which means that this feature is turned off. - -$export_auth_hook:: - Function used to determine which repositories should be shown. - This subroutine should take one parameter, the full path to - a project, and if it returns true, that project will be included - in the projects list and can be accessed through gitweb as long - as it fulfills the other requirements described by $export_ok, - $projects_list, and $projects_maxdepth. Example: -+ ----------------------------------------------------------------------------- -our $export_auth_hook = sub { return -e "$_[0]/git-daemon-export-ok"; }; ----------------------------------------------------------------------------- -+ -though the above might be done by using `$export_ok` instead -+ ----------------------------------------------------------------------------- -our $export_ok = "git-daemon-export-ok"; ----------------------------------------------------------------------------- -+ -If not set (default), it means that this feature is disabled. -+ -See also more involved example in "Controlling access to Git repositories" -subsection on linkgit:gitweb[1] manpage. - -$strict_export:: - Only allow viewing of repositories also shown on the overview page. - This for example makes `$export_ok` file decide if repository is - available and not only if it is shown. If `$projects_list` points to - file with list of project, only those repositories listed would be - available for gitweb. Can be set during building gitweb via - `GITWEB_STRICT_EXPORT`. By default this variable is not set, which - means that you can directly access those repositories that are hidden - from projects list page (e.g. the are not listed in the $projects_list - file). - - -Finding files -~~~~~~~~~~~~~ -The following configuration variables tell gitweb where to find files. -The values of these variables are paths on the filesystem. - -$GIT:: - Core git executable to use. By default set to `$GIT_BINDIR/git`, which - in turn is by default set to `$(bindir)/git`. If you use Git installed - from a binary package, you should usually set this to "/usr/bin/git". - This can just be "git" if your web server has a sensible PATH; from - security point of view it is better to use absolute path to git binary. - If you have multiple Git versions installed it can be used to choose - which one to use. Must be (correctly) set for gitweb to be able to - work. - -$mimetypes_file:: - File to use for (filename extension based) guessing of MIME types before - trying `/etc/mime.types`. *NOTE* that this path, if relative, is taken - as relative to the current Git repository, not to CGI script. If unset, - only `/etc/mime.types` is used (if present on filesystem). If no mimetypes - file is found, mimetype guessing based on extension of file is disabled. - Unset by default. - -$highlight_bin:: - Path to the highlight executable to use (it must be the one from - http://www.andre-simon.de[] due to assumptions about parameters and output). - By default set to 'highlight'; set it to full path to highlight - executable if it is not installed on your web server's PATH. - Note that 'highlight' feature must be set for gitweb to actually - use syntax highlighting. -+ -*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 -files, you can add the following to gitweb configuration: -+ ---------------------------------------------------------- -our %highlight_ext; -$highlight_ext{'phtml'} = 'php'; ---------------------------------------------------------- - - -Links and their targets -~~~~~~~~~~~~~~~~~~~~~~~ -The configuration variables described below configure some of gitweb links: -their target and their look (text or image), and where to find page -prerequisites (stylesheet, favicon, images, scripts). Usually they are left -at their default values, with the possible exception of `@stylesheets` -variable. - -@stylesheets:: - List of URIs of stylesheets (relative to the base URI of a page). You - might specify more than one stylesheet, for example to use "gitweb.css" - as base with site specific modifications in a separate stylesheet - to make it easier to upgrade gitweb. For example, you can add - a `site` stylesheet by putting -+ ----------------------------------------------------------------------------- -push @stylesheets, "gitweb-site.css"; ----------------------------------------------------------------------------- -+ -in the gitweb config file. Those values that are relative paths are -relative to base URI of gitweb. -+ -This list should contain the URI of gitweb's standard stylesheet. The default -URI of gitweb stylesheet can be set at build time using the `GITWEB_CSS` -makefile variable. Its default value is `static/gitweb.css` -(or `static/gitweb.min.css` if the `CSSMIN` variable is defined, -i.e. if CSS minifier is used during build). -+ -*Note*: there is also a legacy `$stylesheet` configuration variable, which was -used by older gitweb. If `$stylesheet` variable is defined, only CSS stylesheet -given by this variable is used by gitweb. - -$logo:: - Points to the location where you put 'git-logo.png' on your web - server, or to be more the generic URI of logo, 72x27 size). This image - is displayed in the top right corner of each gitweb page and used as - a logo for the Atom feed. Relative to the base URI of gitweb (as a path). - Can be adjusted when building gitweb using `GITWEB_LOGO` variable - By default set to `static/git-logo.png`. - -$favicon:: - Points to the location where you put 'git-favicon.png' on your web - server, or to be more the generic URI of favicon, which will be served - as "image/png" type. Web browsers that support favicons (website icons) - may display them in the browser's URL bar and next to the site name in - bookmarks. Relative to the base URI of gitweb. Can be adjusted at - build time using `GITWEB_FAVICON` variable. - By default set to `static/git-favicon.png`. - -$javascript:: - Points to the location where you put 'gitweb.js' on your web server, - or to be more generic the URI of JavaScript code used by gitweb. - Relative to the base URI of gitweb. Can be set at build time using - the `GITWEB_JS` build-time configuration variable. -+ -The default value is either `static/gitweb.js`, or `static/gitweb.min.js` if -the `JSMIN` build variable was defined, i.e. if JavaScript minifier was used -at build time. *Note* that this single file is generated from multiple -individual JavaScript "modules". - -$home_link:: - Target of the home link on the top of all pages (the first part of view - "breadcrumbs"). By default it is set to the absolute URI of a current page - (to the value of `$my_uri` variable, or to "/" if `$my_uri` is undefined - or is an empty string). - -$home_link_str:: - Label for the "home link" at the top of all pages, leading to `$home_link` - (usually the main gitweb page, which contains the projects list). It is - used as the first component of gitweb's "breadcrumb trail": - `<home link> / <project> / <action>`. Can be set at build time using - the `GITWEB_HOME_LINK_STR` variable. By default it is set to "projects", - as this link leads to the list of projects. Another popular choice is to - set it to the name of site. Note that it is treated as raw HTML so it - should not be set from untrusted sources. - -@extra_breadcrumbs:: - Additional links to be added to the start of the breadcrumb trail before - the home link, to pages that are logically "above" the gitweb projects - list, such as the organization and department which host the gitweb - server. Each element of the list is a reference to an array, in which - element 0 is the link text (equivalent to `$home_link_str`) and element - 1 is the target URL (equivalent to `$home_link`). -+ -For example, the following setting produces a breadcrumb trail like -"home / dev / projects / ..." where "projects" is the home link. -+ ----------------------------------------------------------------------------- - our @extra_breadcrumbs = ( - [ 'home' => 'https://www.example.org/' ], - [ 'dev' => 'https://dev.example.org/' ], - ); ----------------------------------------------------------------------------- - -$logo_url:: -$logo_label:: - URI and label (title) for the Git logo link (or your site logo, - if you chose to use different logo image). By default, these both - refer to Git homepage, https://git-scm.com[]; in the past, they pointed - to Git documentation at https://www.kernel.org[]. - - -Changing gitweb's look -~~~~~~~~~~~~~~~~~~~~~~ -You can adjust how pages generated by gitweb look using the variables described -below. You can change the site name, add common headers and footers for all -pages, and add a description of this gitweb installation on its main page -(which is the projects list page), etc. - -$site_name:: - Name of your site or organization, to appear in page titles. Set it - to something descriptive for clearer bookmarks etc. If this variable - is not set or is, then gitweb uses the value of the `SERVER_NAME` - `CGI` environment variable, setting site name to "$SERVER_NAME Git", - or "Untitled Git" if this variable is not set (e.g. if running gitweb - as standalone script). -+ -Can be set using the `GITWEB_SITENAME` at build time. Unset by default. - -$site_html_head_string:: - HTML snippet to be included in the <head> section of each page. - Can be set using `GITWEB_SITE_HTML_HEAD_STRING` at build time. - No default value. - -$site_header:: - Name of a file with HTML to be included at the top of each page. - Relative to the directory containing the 'gitweb.cgi' script. - Can be set using `GITWEB_SITE_HEADER` at build time. No default - value. - -$site_footer:: - Name of a file with HTML to be included at the bottom of each page. - Relative to the directory containing the 'gitweb.cgi' script. - Can be set using `GITWEB_SITE_FOOTER` at build time. No default - value. - -$home_text:: - Name of a HTML file which, if it exists, is included on the - gitweb projects overview page ("projects_list" view). Relative to - the directory containing the gitweb.cgi script. Default value - can be adjusted during build time using `GITWEB_HOMETEXT` variable. - By default set to 'indextext.html'. - -$projects_list_description_width:: - The width (in characters) of the "Description" column of the projects list. - Longer descriptions will be truncated (trying to cut at word boundary); - the full description is available in the 'title' attribute (usually shown on - mouseover). The default is 25, which might be too small if you - use long project descriptions. - -$default_projects_order:: - Default value of ordering of projects on projects list page, which - means the ordering used if you don't explicitly sort projects list - (if there is no "o" CGI query parameter in the URL). Valid values - are "none" (unsorted), "project" (projects are by project name, - i.e. path to repository relative to `$projectroot`), "descr" - (project description), "owner", and "age" (by date of most current - commit). -+ -Default value is "project". Unknown value means unsorted. - - -Changing gitweb's behavior -~~~~~~~~~~~~~~~~~~~~~~~~~~ -These configuration variables control _internal_ gitweb behavior. - -$default_blob_plain_mimetype:: - Default mimetype for the blob_plain (raw) view, if mimetype checking - doesn't result in some other type; by default "text/plain". - Gitweb guesses mimetype of a file to display based on extension - of its filename, using `$mimetypes_file` (if set and file exists) - and `/etc/mime.types` files (see *mime.types*(5) manpage; only - filename extension rules are supported by gitweb). - -$default_text_plain_charset:: - Default charset for text files. If this is not set, the web server - configuration will be used. Unset by default. - -$fallback_encoding:: - Gitweb assumes this charset when a line contains non-UTF-8 characters. - The fallback decoding is used without error checking, so it can be even - "utf-8". The value must be a valid encoding; see the *Encoding::Supported*(3pm) - man page for a list. The default is "latin1", aka. "iso-8859-1". - -@diff_opts:: - Rename detection options for git-diff and git-diff-tree. The default is - (\'-M'); set it to (\'-C') or (\'-C', \'-C') to also detect copies, - or set it to () i.e. empty list if you don't want to have renames - detection. -+ -*Note* that rename and especially copy detection can be quite -CPU-intensive. Note also that non Git tools can have problems with -patches generated with options mentioned above, especially when they -involve file copies (\'-C') or criss-cross renames (\'-B'). - - -Some optional features and policies -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Most of features are configured via `%feature` hash; however some of extra -gitweb features can be turned on and configured using variables described -below. This list beside configuration variables that control how gitweb -looks does contain variables configuring administrative side of gitweb -(e.g. cross-site scripting prevention; admittedly this as side effect -affects how "summary" pages look like, or load limiting). - -@git_base_url_list:: - List of Git base URLs. These URLs are used to generate URLs - describing from where to fetch a project, which are shown on - project summary page. The full fetch URL is "`$git_base_url/$project`", - for each element of this list. You can set up multiple base URLs - (for example one for `git://` protocol, and one for `http://` - protocol). -+ -Note that per repository configuration can be set in `$GIT_DIR/cloneurl` -file, or as values of multi-value `gitweb.url` configuration variable in -project config. Per-repository configuration takes precedence over value -composed from `@git_base_url_list` elements and project name. -+ -You can setup one single value (single entry/item in this list) at build -time by setting the `GITWEB_BASE_URL` build-time configuration variable. -By default it is set to (), i.e. an empty list. This means that gitweb -would not try to create project URL (to fetch) from project name. - -$projects_list_group_categories:: - Whether to enable the grouping of projects by category on the project - list page. The category of a project is determined by the - `$GIT_DIR/category` file or the `gitweb.category` variable in each - repository's configuration. Disabled by default (set to 0). - -$project_list_default_category:: - Default category for projects for which none is specified. If this is - set to the empty string, such projects will remain uncategorized and - listed at the top, above categorized projects. Used only if project - categories are enabled, which means if `$projects_list_group_categories` - is true. By default set to "" (empty string). - -$prevent_xss:: - If true, some gitweb features are disabled to prevent content in - repositories from launching cross-site scripting (XSS) attacks. Set this - to true if you don't trust the content of your repositories. - False by default (set to 0). - -$maxload:: - Used to set the maximum load that we will still respond to gitweb queries. - If the server load exceeds this value then gitweb will return - "503 Service Unavailable" error. The server load is taken to be 0 - if gitweb cannot determine its value. Currently it works only on Linux, - where it uses `/proc/loadavg`; the load there is the number of active - tasks on the system -- processes that are actually running -- averaged - over the last minute. -+ -Set `$maxload` to undefined value (`undef`) to turn this feature off. -The default value is 300. - -$omit_age_column:: - If true, omit the column with date of the most current commit on the - projects list page. It can save a bit of I/O and a fork per repository. - -$omit_owner:: - If true prevents displaying information about repository owner. - -$per_request_config:: - If this is set to code reference, it will be run once for each request. - You can set parts of configuration that change per session this way. - For example, one might use the following code in a gitweb configuration - file -+ --------------------------------------------------------------------------------- -our $per_request_config = sub { - $ENV{GL_USER} = $cgi->remote_user || "gitweb"; -}; --------------------------------------------------------------------------------- -+ -If `$per_request_config` is not a code reference, it is interpreted as boolean -value. If it is true gitweb will process config files once per request, -and if it is false gitweb will process config files only once, each time it -is executed. True by default (set to 1). -+ -*NOTE*: `$my_url`, `$my_uri`, and `$base_url` are overwritten with their default -values before every request, so if you want to change them, be sure to set -this variable to true or a code reference effecting the desired changes. -+ -This variable matters only when using persistent web environments that -serve multiple requests using single gitweb instance, like mod_perl, -FastCGI or Plackup. - - -Other variables -~~~~~~~~~~~~~~~ -Usually you should not need to change (adjust) any of configuration -variables described below; they should be automatically set by gitweb to -correct value. - - -$version:: - Gitweb version, set automatically when creating gitweb.cgi from - gitweb.perl. You might want to modify it if you are running modified - gitweb, for example -+ ---------------------------------------------------- -our $version .= " with caching"; ---------------------------------------------------- -+ -if you run modified version of gitweb with caching support. This variable -is purely informational, used e.g. in the "generator" meta header in HTML -header. - -$my_url:: -$my_uri:: - Full URL and absolute URL of the gitweb script; - in earlier versions of gitweb you might have need to set those - variables, but now there should be no need to do it. See - `$per_request_config` if you need to set them still. - -$base_url:: - Base URL for relative URLs in pages generated by gitweb, - (e.g. `$logo`, `$favicon`, `@stylesheets` if they are relative URLs), - needed and used '<base href="$base_url">' only for URLs with nonempty - PATH_INFO. Usually gitweb sets its value correctly, - and there is no need to set this variable, e.g. to $my_uri or "/". - See `$per_request_config` if you need to override it anyway. - - -CONFIGURING GITWEB FEATURES ---------------------------- -Many gitweb features can be enabled (or disabled) and configured using the -`%feature` hash. Names of gitweb features are keys of this hash. - -Each `%feature` hash element is a hash reference and has the following -structure: ----------------------------------------------------------------------- -"<feature_name>" => { - "sub" => <feature-sub (subroutine)>, - "override" => <allow-override (boolean)>, - "default" => [ <options>... ] -}, ----------------------------------------------------------------------- -Some features cannot be overridden per project. For those -features the structure of appropriate `%feature` hash element has a simpler -form: ----------------------------------------------------------------------- -"<feature_name>" => { - "override" => 0, - "default" => [ <options>... ] -}, ----------------------------------------------------------------------- -As one can see it lacks the \'sub' element. - -The meaning of each part of feature configuration is described -below: - -default:: - List (array reference) of feature parameters (if there are any), - used also to toggle (enable or disable) given feature. -+ -Note that it is currently *always* an array reference, even if -feature doesn't accept any configuration parameters, and \'default' -is used only to turn it on or off. In such case you turn feature on -by setting this element to `[1]`, and torn it off by setting it to -`[0]`. See also the passage about the "blame" feature in the "Examples" -section. -+ -To disable features that accept parameters (are configurable), you -need to set this element to empty list i.e. `[]`. - -override:: - If this field has a true value then the given feature is - overridable, which means that it can be configured - (or enabled/disabled) on a per-repository basis. -+ -Usually given "<feature>" is configurable via the `gitweb.<feature>` -config variable in the per-repository Git configuration file. -+ -*Note* that no feature is overridable by default. - -sub:: - Internal detail of implementation. What is important is that - if this field is not present then per-repository override for - given feature is not supported. -+ -You wouldn't need to ever change it in gitweb config file. - - -Features in `%feature` -~~~~~~~~~~~~~~~~~~~~~~ -The gitweb features that are configurable via `%feature` hash are listed -below. This should be a complete list, but ultimately the authoritative -and complete list is in gitweb.cgi source code, with features described -in the comments. - -blame:: - Enable the "blame" and "blame_incremental" blob views, showing for - each line the last commit that modified it; see linkgit:git-blame[1]. - This can be very CPU-intensive and is therefore disabled by default. -+ -This feature can be configured on a per-repository basis via -repository's `gitweb.blame` configuration variable (boolean). - -snapshot:: - Enable and configure the "snapshot" action, which allows user to - download a compressed archive of any tree or commit, as produced - by linkgit:git-archive[1] and possibly additionally compressed. - This can potentially generate high traffic if you have large project. -+ -The value of \'default' is a list of names of snapshot formats, -defined in `%known_snapshot_formats` hash, that you wish to offer. -Supported formats include "tgz", "tbz2", "txz" (gzip/bzip2/xz -compressed tar archive) and "zip"; please consult gitweb sources for -a definitive list. By default only "tgz" is offered. -+ -This feature can be configured on a per-repository basis via -repository's `gitweb.snapshot` configuration variable, which contains -a comma separated list of formats or "none" to disable snapshots. -Unknown values are ignored. - -grep:: - Enable grep search, which lists the files in currently selected - tree (directory) containing the given string; see linkgit:git-grep[1]. - This can be potentially CPU-intensive, of course. Enabled by default. -+ -This feature can be configured on a per-repository basis via -repository's `gitweb.grep` configuration variable (boolean). - -pickaxe:: - Enable the so called pickaxe search, which will list the commits - that introduced or removed a given string in a file. This can be - practical and quite faster alternative to "blame" action, but it is - still potentially CPU-intensive. Enabled by default. -+ -The pickaxe search is described in linkgit:git-log[1] (the -description of `-S<string>` option, which refers to pickaxe entry in -linkgit:gitdiffcore[7] for more details). -+ -This feature can be configured on a per-repository basis by setting -repository's `gitweb.pickaxe` configuration variable (boolean). - -show-sizes:: - Enable showing size of blobs (ordinary files) in a "tree" view, in a - separate column, similar to what `ls -l` does; see description of - `-l` option in linkgit:git-ls-tree[1] manpage. This costs a bit of - I/O. Enabled by default. -+ -This feature can be configured on a per-repository basis via -repository's `gitweb.showSizes` configuration variable (boolean). - -patches:: - Enable and configure "patches" view, which displays list of commits in email - (plain text) output format; see also linkgit:git-format-patch[1]. - The value is the maximum number of patches in a patchset generated - in "patches" view. Set the 'default' field to a list containing single - item of or to an empty list to disable patch view, or to a list - containing a single negative number to remove any limit. - Default value is 16. -+ -This feature can be configured on a per-repository basis via -repository's `gitweb.patches` configuration variable (integer). - -avatar:: - Avatar support. When this feature is enabled, views such as - "shortlog" or "commit" will display an avatar associated with - the email of each committer and author. -+ -Currently available providers are *"gravatar"* and *"picon"*. -Only one provider at a time can be selected ('default' is one element list). -If an unknown provider is specified, the feature is disabled. -*Note* that some providers might require extra Perl packages to be -installed; see `gitweb/INSTALL` for more details. -+ -This feature can be configured on a per-repository basis via -repository's `gitweb.avatar` configuration variable. -+ -See also `%avatar_size` with pixel sizes for icons and avatars -("default" is used for one-line like "log" and "shortlog", "double" -is used for two-line like "commit", "commitdiff" or "tag"). If the -default font sizes or lineheights are changed (e.g. via adding extra -CSS stylesheet in `@stylesheets`), it may be appropriate to change -these values. - -highlight:: - Server-side syntax highlight support in "blob" view. It requires - `$highlight_bin` program to be available (see the description of - this variable in the "Configuration variables" section above), - and therefore is disabled by default. -+ -This feature can be configured on a per-repository basis via -repository's `gitweb.highlight` configuration variable (boolean). - -remote_heads:: - Enable displaying remote heads (remote-tracking branches) in the "heads" - list. In most cases the list of remote-tracking branches is an - unnecessary internal private detail, and this feature is therefore - disabled by default. linkgit:git-instaweb[1], which is usually used - to browse local repositories, enables and uses this feature. -+ -This feature can be configured on a per-repository basis via -repository's `gitweb.remote_heads` configuration variable (boolean). - - -The remaining features cannot be overridden on a per project basis. - -search:: - Enable text search, which will list the commits which match author, - committer or commit text to a given string; see the description of - `--author`, `--committer` and `--grep` options in linkgit:git-log[1] - manpage. Enabled by default. -+ -Project specific override is not supported. - -forks:: - If this feature is enabled, gitweb considers projects in - subdirectories of project root (basename) to be forks of existing - projects. For each project +$projname.git+, projects in the - +$projname/+ directory and its subdirectories will not be - shown in the main projects list. Instead, a \'\+' mark is shown - next to +$projname+, which links to a "forks" view that lists all - the forks (all projects in +$projname/+ subdirectory). Additionally - a "forks" view for a project is linked from project summary page. -+ -If the project list is taken from a file (+$projects_list+ points to a -file), forks are only recognized if they are listed after the main project -in that file. -+ -Project specific override is not supported. - -actions:: - Insert custom links to the action bar of all project pages. This - allows you to link to third-party scripts integrating into gitweb. -+ -The "default" value consists of a list of triplets in the form -`("<label>", "<link>", "<position>")` where "position" is the label -after which to insert the link, "link" is a format string where `%n` -expands to the project name, `%f` to the project path within the -filesystem (i.e. "$projectroot/$project"), `%h` to the current hash -(\'h' gitweb parameter) and `%b` to the current hash base -(\'hb' gitweb parameter); `%%` expands to \'%'. -+ -For example, at the time this page was written, the http://repo.or.cz[] -Git hosting site set it to the following to enable graphical log -(using the third party tool *git-browser*): -+ ----------------------------------------------------------------------- -$feature{'actions'}{'default'} = - [ ('graphiclog', '/git-browser/by-commit.html?r=%n', 'summary')]; ----------------------------------------------------------------------- -+ -This adds a link titled "graphiclog" after the "summary" link, leading to -`git-browser` script, passing `r=<project>` as a query parameter. -+ -Project specific override is not supported. - -timed:: - Enable displaying how much time and how many Git commands it took to - generate and display each page in the page footer (at the bottom of - page). For example the footer might contain: "This page took 6.53325 - seconds and 13 Git commands to generate." Disabled by default. -+ -Project specific override is not supported. - -javascript-timezone:: - Enable and configure the ability to change a common time zone for dates - in gitweb output via JavaScript. Dates in gitweb output include - authordate and committerdate in "commit", "commitdiff" and "log" - views, and taggerdate in "tag" view. Enabled by default. -+ -The value is a list of three values: a default time zone (for if the client -hasn't selected some other time zone and saved it in a cookie), a name of cookie -where to store selected time zone, and a CSS class used to mark up -dates for manipulation. If you want to turn this feature off, set "default" -to empty list: `[]`. -+ -Typical gitweb config files will only change starting (default) time zone, -and leave other elements at their default values: -+ ---------------------------------------------------------------------------- -$feature{'javascript-timezone'}{'default'}[0] = "utc"; ---------------------------------------------------------------------------- -+ -The example configuration presented here is guaranteed to be backwards -and forward compatible. -+ -Time zone values can be "local" (for local time zone that browser uses), "utc" -(what gitweb uses when JavaScript or this feature is disabled), or numerical -time zones in the form of "+/-HHMM", such as "+0200". -+ -Project specific override is not supported. - -extra-branch-refs:: - List of additional directories under "refs" which are going to - be used as branch refs. For example if you have a gerrit setup - where all branches under refs/heads/ are official, - push-after-review ones and branches under refs/sandbox/, - refs/wip and refs/other are user ones where permissions are - much wider, then you might want to set this variable as - follows: -+ --------------------------------------------------------------------------------- -$feature{'extra-branch-refs'}{'default'} = - ['sandbox', 'wip', 'other']; --------------------------------------------------------------------------------- -+ -This feature can be configured on per-repository basis after setting -$feature{'extra-branch-refs'}{'override'} to true, via repository's -`gitweb.extraBranchRefs` configuration variable, which contains a -space separated list of refs. An example: -+ --------------------------------------------------------------------------------- -[gitweb] - extraBranchRefs = sandbox wip other --------------------------------------------------------------------------------- -+ -The gitweb.extraBranchRefs is actually a multi-valued configuration -variable, so following example is also correct and the result is the -same as of the snippet above: -+ --------------------------------------------------------------------------------- -[gitweb] - extraBranchRefs = sandbox - extraBranchRefs = wip other --------------------------------------------------------------------------------- -+ -It is an error to specify a ref that does not pass "git check-ref-format" -scrutiny. Duplicated values are filtered. - - -EXAMPLES --------- - -To enable blame, pickaxe search, and snapshot support (allowing "tar.gz" and -"zip" snapshots), while allowing individual projects to turn them off, put -the following in your GITWEB_CONFIG file: - --------------------------------------------------------------------------------- -$feature{'blame'}{'default'} = [1]; -$feature{'blame'}{'override'} = 1; - -$feature{'pickaxe'}{'default'} = [1]; -$feature{'pickaxe'}{'override'} = 1; - -$feature{'snapshot'}{'default'} = ['zip', 'tgz']; -$feature{'snapshot'}{'override'} = 1; --------------------------------------------------------------------------------- - -If you allow overriding for the snapshot feature, you can specify which -snapshot formats are globally disabled. You can also add any command-line -options you want (such as setting the compression level). For instance, you -can disable Zip compressed snapshots and set *gzip*(1) to run at level 6 by -adding the following lines to your gitweb configuration file: - - $known_snapshot_formats{'zip'}{'disabled'} = 1; - $known_snapshot_formats{'tgz'}{'compressor'} = ['gzip','-6']; - -BUGS ----- -Debugging would be easier if the fallback configuration file -(`/etc/gitweb.conf`) and environment variable to override its location -('GITWEB_CONFIG_SYSTEM') had names reflecting their "fallback" role. -The current names are kept to avoid breaking working setups. - -ENVIRONMENT ------------ -The location of per-instance and system-wide configuration files can be -overridden using the following environment variables: - -GITWEB_CONFIG:: - Sets location of per-instance configuration file. -GITWEB_CONFIG_SYSTEM:: - Sets location of fallback system-wide configuration file. - This file is read only if per-instance one does not exist. -GITWEB_CONFIG_COMMON:: - Sets location of common system-wide configuration file. - - -FILES ------ -gitweb_config.perl:: - This is default name of per-instance configuration file. The - format of this file is described above. -/etc/gitweb.conf:: - This is default name of fallback system-wide configuration - file. This file is used only if per-instance configuration - variable is not found. -/etc/gitweb-common.conf:: - This is default name of common system-wide configuration - file. - - -SEE ALSO --------- -linkgit:gitweb[1], linkgit:git-instaweb[1] - -'gitweb/README', 'gitweb/INSTALL' - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitweb.txt b/third_party/git/Documentation/gitweb.txt deleted file mode 100644 index 3cc9b034c4..0000000000 --- a/third_party/git/Documentation/gitweb.txt +++ /dev/null @@ -1,703 +0,0 @@ -gitweb(1) -========= - -NAME ----- -gitweb - Git web interface (web frontend to Git repositories) - -SYNOPSIS --------- -To get started with gitweb, run linkgit:git-instaweb[1] from a Git repository. -This would configure and start your web server, and run web browser pointing to -gitweb. - - -DESCRIPTION ------------ -Gitweb provides a web interface to Git repositories. Its features include: - -* Viewing multiple Git repositories with common root. -* Browsing every revision of the repository. -* Viewing the contents of files in the repository at any revision. -* Viewing the revision log of branches, history of files and directories, - see what was changed when, by who. -* Viewing the blame/annotation details of any file (if enabled). -* Generating RSS and Atom feeds of commits, for any branch. - The feeds are auto-discoverable in modern web browsers. -* Viewing everything that was changed in a revision, and step through - revisions one at a time, viewing the history of the repository. -* Finding commits which commit messages matches given search term. - -See http://repo.or.cz/w/git.git/tree/HEAD:/gitweb/[] for gitweb source code, -browsed using gitweb itself. - - -CONFIGURATION -------------- -Various aspects of gitweb's behavior can be controlled through the configuration -file `gitweb_config.perl` or `/etc/gitweb.conf`. See the linkgit:gitweb.conf[5] -for details. - -Repositories -~~~~~~~~~~~~ -Gitweb can show information from one or more Git repositories. These -repositories have to be all on local filesystem, and have to share common -repository root, i.e. be all under a single parent repository (but see also -"Advanced web server setup" section, "Webserver configuration with multiple -projects' root" subsection). - ------------------------------------------------------------------------ -our $projectroot = '/path/to/parent/directory'; ------------------------------------------------------------------------ - -The default value for `$projectroot` is `/pub/git`. You can change it during -building gitweb via `GITWEB_PROJECTROOT` build configuration variable. - -By default all Git repositories under `$projectroot` are visible and available -to gitweb. The list of projects is generated by default by scanning the -`$projectroot` directory for Git repositories (for object databases to be -more exact; gitweb is not interested in a working area, and is best suited -to showing "bare" repositories). - -The name of the repository in gitweb is the path to its `$GIT_DIR` (its object -database) relative to `$projectroot`. Therefore the repository $repo can be -found at "$projectroot/$repo". - - -Projects list file format -~~~~~~~~~~~~~~~~~~~~~~~~~ -Instead of having gitweb find repositories by scanning filesystem -starting from $projectroot, you can provide a pre-generated list of -visible projects by setting `$projects_list` to point to a plain text -file with a list of projects (with some additional info). - -This file uses the following format: - -* One record (for project / repository) per line; does not support line -continuation (newline escaping). - -* Leading and trailing whitespace are ignored. - -* Whitespace separated fields; any run of whitespace can be used as field -separator (rules for Perl's "`split(" ", $line)`"). - -* Fields use modified URI encoding, defined in RFC 3986, section 2.1 -(Percent-Encoding), or rather "Query string encoding" (see -https://en.wikipedia.org/wiki/Query_string#URL_encoding[]), the difference -being that SP (" ") can be encoded as "{plus}" (and therefore "{plus}" has to be -also percent-encoded). -+ -Reserved characters are: "%" (used for encoding), "{plus}" (can be used to -encode SPACE), all whitespace characters as defined in Perl, including SP, -TAB and LF, (used to separate fields in a record). - -* Currently recognized fields are: -<repository path>:: - path to repository GIT_DIR, relative to `$projectroot` -<repository owner>:: - displayed as repository owner, preferably full name, or email, - or both - -You can generate the projects list index file using the project_index action -(the 'TXT' link on projects list page) directly from gitweb; see also -"Generating projects list using gitweb" section below. - -Example contents: ------------------------------------------------------------------------ -foo.git Joe+R+Hacker+<joe@example.com> -foo/bar.git O+W+Ner+<owner@example.org> ------------------------------------------------------------------------ - - -By default this file controls only which projects are *visible* on projects -list page (note that entries that do not point to correctly recognized Git -repositories won't be displayed by gitweb). Even if a project is not -visible on projects list page, you can view it nevertheless by hand-crafting -a gitweb URL. By setting `$strict_export` configuration variable (see -linkgit:gitweb.conf[5]) to true value you can allow viewing only of -repositories also shown on the overview page (i.e. only projects explicitly -listed in projects list file will be accessible). - - -Generating projects list using gitweb -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -We assume that GITWEB_CONFIG has its default Makefile value, namely -'gitweb_config.perl'. Put the following in 'gitweb_make_index.perl' file: ----------------------------------------------------------------------------- -read_config_file("gitweb_config.perl"); -$projects_list = $projectroot; ----------------------------------------------------------------------------- - -Then create the following script to get list of project in the format -suitable for GITWEB_LIST build configuration variable (or -`$projects_list` variable in gitweb config): - ----------------------------------------------------------------------------- -#!/bin/sh - -export GITWEB_CONFIG="gitweb_make_index.perl" -export GATEWAY_INTERFACE="CGI/1.1" -export HTTP_ACCEPT="*/*" -export REQUEST_METHOD="GET" -export QUERY_STRING="a=project_index" - -perl -- /var/www/cgi-bin/gitweb.cgi ----------------------------------------------------------------------------- - -Run this script and save its output to a file. This file could then be used -as projects list file, which means that you can set `$projects_list` to its -filename. - - -Controlling access to Git repositories -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -By default all Git repositories under `$projectroot` are visible and -available to gitweb. You can however configure how gitweb controls access -to repositories. - -* As described in "Projects list file format" section, you can control which -projects are *visible* by selectively including repositories in projects -list file, and setting `$projects_list` gitweb configuration variable to -point to it. With `$strict_export` set, projects list file can be used to -control which repositories are *available* as well. - -* You can configure gitweb to only list and allow viewing of the explicitly -exported repositories, via `$export_ok` variable in gitweb config file; see -linkgit:gitweb.conf[5] manpage. If it evaluates to true, gitweb shows -repositories only if this file named by `$export_ok` exists in its object -database (if directory has the magic file named `$export_ok`). -+ -For example linkgit:git-daemon[1] by default (unless `--export-all` option -is used) allows pulling only for those repositories that have -'git-daemon-export-ok' file. Adding -+ --------------------------------------------------------------------------- -our $export_ok = "git-daemon-export-ok"; --------------------------------------------------------------------------- -+ -makes gitweb show and allow access only to those repositories that can be -fetched from via `git://` protocol. - -* Finally, it is possible to specify an arbitrary perl subroutine that will -be called for each repository to determine if it can be exported. The -subroutine receives an absolute path to the project (repository) as its only -parameter (i.e. "$projectroot/$project"). -+ -For example, if you use mod_perl to run the script, and have dumb -HTTP protocol authentication configured for your repositories, you -can use the following hook to allow access only if the user is -authorized to read the files: -+ --------------------------------------------------------------------------- -$export_auth_hook = sub { - use Apache2::SubRequest (); - use Apache2::Const -compile => qw(HTTP_OK); - my $path = "$_[0]/HEAD"; - my $r = Apache2::RequestUtil->request; - my $sub = $r->lookup_file($path); - return $sub->filename eq $path - && $sub->status == Apache2::Const::HTTP_OK; -}; --------------------------------------------------------------------------- - - -Per-repository gitweb configuration -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -You can configure individual repositories shown in gitweb by creating file -in the `GIT_DIR` of Git repository, or by setting some repo configuration -variable (in `GIT_DIR/config`, see linkgit:git-config[1]). - -You can use the following files in repository: - -README.html:: - A html file (HTML fragment) which is included on the gitweb project - "summary" page inside `<div>` block element. You can use it for longer - description of a project, to provide links (for example to project's - homepage), etc. This is recognized only if XSS prevention is off - (`$prevent_xss` is false, see linkgit:gitweb.conf[5]); a way to include - a README safely when XSS prevention is on may be worked out in the - future. - -description (or `gitweb.description`):: - Short (shortened to `$projects_list_description_width` in the projects - list page, which is 25 characters by default; see - linkgit:gitweb.conf[5]) single line description of a project (of a - repository). Plain text file; HTML will be escaped. By default set to -+ -------------------------------------------------------------------------------- -Unnamed repository; edit this file to name it for gitweb. -------------------------------------------------------------------------------- -+ -from the template during repository creation, usually installed in -`/usr/share/git-core/templates/`. You can use the `gitweb.description` repo -configuration variable, but the file takes precedence. - -category (or `gitweb.category`):: - Singe line category of a project, used to group projects if - `$projects_list_group_categories` is enabled. By default (file and - configuration variable absent), uncategorized projects are put in the - `$project_list_default_category` category. You can use the - `gitweb.category` repo configuration variable, but the file takes - precedence. -+ -The configuration variables `$projects_list_group_categories` and -`$project_list_default_category` are described in linkgit:gitweb.conf[5] - -cloneurl (or multiple-valued `gitweb.url`):: - File with repository URL (used for clone and fetch), one per line. - Displayed in the project summary page. You can use multiple-valued - `gitweb.url` repository configuration variable for that, but the file - takes precedence. -+ -This is per-repository enhancement / version of global prefix-based -`@git_base_url_list` gitweb configuration variable (see -linkgit:gitweb.conf[5]). - -gitweb.owner:: - You can use the `gitweb.owner` repository configuration variable to set - repository's owner. It is displayed in the project list and summary - page. -+ -If it's not set, filesystem directory's owner is used (via GECOS field, -i.e. real name field from *getpwuid*(3)) if `$projects_list` is unset -(gitweb scans `$projectroot` for repositories); if `$projects_list` -points to file with list of repositories, then project owner defaults to -value from this file for given repository. - -various `gitweb.*` config variables (in config):: - Read description of `%feature` hash for detailed list, and descriptions. - See also "Configuring gitweb features" section in linkgit:gitweb.conf[5] - - -ACTIONS, AND URLS ------------------ -Gitweb can use path_info (component) based URLs, or it can pass all necessary -information via query parameters. The typical gitweb URLs are broken down in to -five components: - ------------------------------------------------------------------------ -.../gitweb.cgi/<repo>/<action>/<revision>:/<path>?<arguments> ------------------------------------------------------------------------ - -repo:: - The repository the action will be performed on. -+ -All actions except for those that list all available projects, -in whatever form, require this parameter. - -action:: - The action that will be run. Defaults to 'projects_list' if repo - is not set, and to 'summary' otherwise. - -revision:: - Revision shown. Defaults to HEAD. - -path:: - The path within the <repository> that the action is performed on, - for those actions that require it. - -arguments:: - Any arguments that control the behaviour of the action. - -Some actions require or allow to specify two revisions, and sometimes even two -pathnames. In most general form such path_info (component) based gitweb URL -looks like this: - ------------------------------------------------------------------------ -.../gitweb.cgi/<repo>/<action>/<revision_from>:/<path_from>..<revision_to>:/<path_to>?<arguments> ------------------------------------------------------------------------ - - -Each action is implemented as a subroutine, and must be present in %actions -hash. Some actions are disabled by default, and must be turned on via feature -mechanism. For example to enable 'blame' view add the following to gitweb -configuration file: - ------------------------------------------------------------------------ -$feature{'blame'}{'default'} = [1]; ------------------------------------------------------------------------ - - -Actions: -~~~~~~~~ -The standard actions are: - -project_list:: - Lists the available Git repositories. This is the default command if no - repository is specified in the URL. - -summary:: - Displays summary about given repository. This is the default command if - no action is specified in URL, and only repository is specified. - -heads:: -remotes:: - Lists all local or all remote-tracking branches in given repository. -+ -The latter is not available by default, unless configured. - -tags:: - List all tags (lightweight and annotated) in given repository. - -blob:: -tree:: - Shows the files and directories in a given repository path, at given - revision. This is default command if no action is specified in the URL, - and path is given. - -blob_plain:: - Returns the raw data for the file in given repository, at given path and - revision. Links to this action are marked 'raw'. - -blobdiff:: - Shows the difference between two revisions of the same file. - -blame:: -blame_incremental:: - Shows the blame (also called annotation) information for a file. On a - per line basis it shows the revision in which that line was last changed - and the user that committed the change. The incremental version (which - if configured is used automatically when JavaScript is enabled) uses - Ajax to incrementally add blame info to the contents of given file. -+ -This action is disabled by default for performance reasons. - -commit:: -commitdiff:: - Shows information about a specific commit in a repository. The 'commit' - view shows information about commit in more detail, the 'commitdiff' - action shows changeset for given commit. - -patch:: - Returns the commit in plain text mail format, suitable for applying with - linkgit:git-am[1]. - -tag:: - Display specific annotated tag (tag object). - -log:: -shortlog:: - Shows log information (commit message or just commit subject) for a - given branch (starting from given revision). -+ -The 'shortlog' view is more compact; it shows one commit per line. - -history:: - Shows history of the file or directory in a given repository path, - starting from given revision (defaults to HEAD, i.e. default branch). -+ -This view is similar to 'shortlog' view. - -rss:: -atom:: - Generates an RSS (or Atom) feed of changes to repository. - - -WEBSERVER CONFIGURATION ------------------------ -This section explains how to configure some common webservers to run gitweb. In -all cases, `/path/to/gitweb` in the examples is the directory you ran installed -gitweb in, and contains `gitweb_config.perl`. - -If you've configured a web server that isn't listed here for gitweb, please send -in the instructions so they can be included in a future release. - -Apache as CGI -~~~~~~~~~~~~~ -Apache must be configured to support CGI scripts in the directory in -which gitweb is installed. Let's assume that it is `/var/www/cgi-bin` -directory. - ------------------------------------------------------------------------ -ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" - -<Directory "/var/www/cgi-bin"> - Options Indexes FollowSymlinks ExecCGI - AllowOverride None - Order allow,deny - Allow from all -</Directory> ------------------------------------------------------------------------ - -With that configuration the full path to browse repositories would be: - - http://server/cgi-bin/gitweb.cgi - -Apache with mod_perl, via ModPerl::Registry -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -You can use mod_perl with gitweb. You must install Apache::Registry -(for mod_perl 1.x) or ModPerl::Registry (for mod_perl 2.x) to enable -this support. - -Assuming that gitweb is installed to `/var/www/perl`, the following -Apache configuration (for mod_perl 2.x) is suitable. - ------------------------------------------------------------------------ -Alias /perl "/var/www/perl" - -<Directory "/var/www/perl"> - SetHandler perl-script - PerlResponseHandler ModPerl::Registry - PerlOptions +ParseHeaders - Options Indexes FollowSymlinks +ExecCGI - AllowOverride None - Order allow,deny - Allow from all -</Directory> ------------------------------------------------------------------------ - -With that configuration the full path to browse repositories would be: - - http://server/perl/gitweb.cgi - -Apache with FastCGI -~~~~~~~~~~~~~~~~~~~ -Gitweb works with Apache and FastCGI. First you need to rename, copy -or symlink gitweb.cgi to gitweb.fcgi. Let's assume that gitweb is -installed in `/usr/share/gitweb` directory. The following Apache -configuration is suitable (UNTESTED!) - ------------------------------------------------------------------------ -FastCgiServer /usr/share/gitweb/gitweb.cgi -ScriptAlias /gitweb /usr/share/gitweb/gitweb.cgi - -Alias /gitweb/static /usr/share/gitweb/static -<Directory /usr/share/gitweb/static> - SetHandler default-handler -</Directory> ------------------------------------------------------------------------ - -With that configuration the full path to browse repositories would be: - - http://server/gitweb - - -ADVANCED WEB SERVER SETUP -------------------------- -All of those examples use request rewriting, and need `mod_rewrite` -(or equivalent; examples below are written for Apache). - -Single URL for gitweb and for fetching -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -If you want to have one URL for both gitweb and your `http://` -repositories, you can configure Apache like this: - ------------------------------------------------------------------------ -<VirtualHost *:80> - ServerName git.example.org - DocumentRoot /pub/git - SetEnv GITWEB_CONFIG /etc/gitweb.conf - - # turning on mod rewrite - RewriteEngine on - - # make the front page an internal rewrite to the gitweb script - RewriteRule ^/$ /cgi-bin/gitweb.cgi - - # make access for "dumb clients" work - RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ \ - /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT] -</VirtualHost> ------------------------------------------------------------------------ - -The above configuration expects your public repositories to live under -`/pub/git` and will serve them as `http://git.domain.org/dir-under-pub-git`, -both as clonable Git URL and as browseable gitweb interface. If you then -start your linkgit:git-daemon[1] with `--base-path=/pub/git --export-all` -then you can even use the `git://` URL with exactly the same path. - -Setting the environment variable `GITWEB_CONFIG` will tell gitweb to use the -named file (i.e. in this example `/etc/gitweb.conf`) as a configuration for -gitweb. You don't really need it in above example; it is required only if -your configuration file is in different place than built-in (during -compiling gitweb) 'gitweb_config.perl' or `/etc/gitweb.conf`. See -linkgit:gitweb.conf[5] for details, especially information about precedence -rules. - -If you use the rewrite rules from the example you *might* also need -something like the following in your gitweb configuration file -(`/etc/gitweb.conf` following example): ----------------------------------------------------------------------------- -@stylesheets = ("/some/absolute/path/gitweb.css"); -$my_uri = "/"; -$home_link = "/"; -$per_request_config = 1; ----------------------------------------------------------------------------- -Nowadays though gitweb should create HTML base tag when needed (to set base -URI for relative links), so it should work automatically. - - -Webserver configuration with multiple projects' root -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -If you want to use gitweb with several project roots you can edit your -Apache virtual host and gitweb configuration files in the following way. - -The virtual host configuration (in Apache configuration file) should look -like this: --------------------------------------------------------------------------- -<VirtualHost *:80> - ServerName git.example.org - DocumentRoot /pub/git - SetEnv GITWEB_CONFIG /etc/gitweb.conf - - # turning on mod rewrite - RewriteEngine on - - # make the front page an internal rewrite to the gitweb script - RewriteRule ^/$ /cgi-bin/gitweb.cgi [QSA,L,PT] - - # look for a public_git folder in unix users' home - # http://git.example.org/~<user>/ - RewriteRule ^/\~([^\/]+)(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \ - [QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT] - - # http://git.example.org/+<user>/ - #RewriteRule ^/\+([^\/]+)(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \ - [QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT] - - # http://git.example.org/user/<user>/ - #RewriteRule ^/user/([^\/]+)/(gitweb.cgi)?$ /cgi-bin/gitweb.cgi \ - [QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT] - - # defined list of project roots - RewriteRule ^/scm(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \ - [QSA,E=GITWEB_PROJECTROOT:/pub/scm/,L,PT] - RewriteRule ^/var(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \ - [QSA,E=GITWEB_PROJECTROOT:/var/git/,L,PT] - - # make access for "dumb clients" work - RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ \ - /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT] -</VirtualHost> --------------------------------------------------------------------------- - -Here actual project root is passed to gitweb via `GITWEB_PROJECT_ROOT` -environment variable from a web server, so you need to put the following -line in gitweb configuration file (`/etc/gitweb.conf` in above example): --------------------------------------------------------------------------- -$projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/pub/git"; --------------------------------------------------------------------------- -*Note* that this requires to be set for each request, so either -`$per_request_config` must be false, or the above must be put in code -referenced by `$per_request_config`; - -These configurations enable two things. First, each unix user (`<user>`) of -the server will be able to browse through gitweb Git repositories found in -`~/public_git/` with the following url: - - http://git.example.org/~<user>/ - -If you do not want this feature on your server just remove the second -rewrite rule. - -If you already use `mod_userdir` in your virtual host or you don't want to -use the \'~' as first character, just comment or remove the second rewrite -rule, and uncomment one of the following according to what you want. - -Second, repositories found in `/pub/scm/` and `/var/git/` will be accessible -through `http://git.example.org/scm/` and `http://git.example.org/var/`. -You can add as many project roots as you want by adding rewrite rules like -the third and the fourth. - - -PATH_INFO usage -~~~~~~~~~~~~~~~ -If you enable PATH_INFO usage in gitweb by putting ----------------------------------------------------------------------------- -$feature{'pathinfo'}{'default'} = [1]; ----------------------------------------------------------------------------- -in your gitweb configuration file, it is possible to set up your server so -that it consumes and produces URLs in the form - - http://git.example.com/project.git/shortlog/sometag - -i.e. without 'gitweb.cgi' part, by using a configuration such as the -following. This configuration assumes that `/var/www/gitweb` is the -DocumentRoot of your webserver, contains the gitweb.cgi script and -complementary static files (stylesheet, favicon, JavaScript): - ----------------------------------------------------------------------------- -<VirtualHost *:80> - ServerAlias git.example.com - - DocumentRoot /var/www/gitweb - - <Directory /var/www/gitweb> - Options ExecCGI - AddHandler cgi-script cgi - - DirectoryIndex gitweb.cgi - - RewriteEngine On - RewriteCond %{REQUEST_FILENAME} !-f - RewriteCond %{REQUEST_FILENAME} !-d - RewriteRule ^.* /gitweb.cgi/$0 [L,PT] - </Directory> -</VirtualHost> ----------------------------------------------------------------------------- -The rewrite rule guarantees that existing static files will be properly -served, whereas any other URL will be passed to gitweb as PATH_INFO -parameter. - -*Notice* that in this case you don't need special settings for -`@stylesheets`, `$my_uri` and `$home_link`, but you lose "dumb client" -access to your project .git dirs (described in "Single URL for gitweb and -for fetching" section). A possible workaround for the latter is the -following: in your project root dir (e.g. `/pub/git`) have the projects -named *without* a .git extension (e.g. `/pub/git/project` instead of -`/pub/git/project.git`) and configure Apache as follows: ----------------------------------------------------------------------------- -<VirtualHost *:80> - ServerAlias git.example.com - - DocumentRoot /var/www/gitweb - - AliasMatch ^(/.*?)(\.git)(/.*)?$ /pub/git$1$3 - <Directory /var/www/gitweb> - Options ExecCGI - AddHandler cgi-script cgi - - DirectoryIndex gitweb.cgi - - RewriteEngine On - RewriteCond %{REQUEST_FILENAME} !-f - RewriteCond %{REQUEST_FILENAME} !-d - RewriteRule ^.* /gitweb.cgi/$0 [L,PT] - </Directory> -</VirtualHost> ----------------------------------------------------------------------------- - -The additional AliasMatch makes it so that - - http://git.example.com/project.git - -will give raw access to the project's Git dir (so that the project can be -cloned), while - - http://git.example.com/project - -will provide human-friendly gitweb access. - -This solution is not 100% bulletproof, in the sense that if some project has -a named ref (branch, tag) starting with `git/`, then paths such as - - http://git.example.com/project/command/abranch..git/abranch - -will fail with a 404 error. - - -BUGS ----- -Please report any bugs or feature requests to git@vger.kernel.org, -putting "gitweb" in the subject of email. - -SEE ALSO --------- -linkgit:gitweb.conf[5], linkgit:git-instaweb[1] - -`gitweb/README`, `gitweb/INSTALL` - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/gitworkflows.txt b/third_party/git/Documentation/gitworkflows.txt deleted file mode 100644 index abc0dc6bc7..0000000000 --- a/third_party/git/Documentation/gitworkflows.txt +++ /dev/null @@ -1,479 +0,0 @@ -gitworkflows(7) -=============== - -NAME ----- -gitworkflows - An overview of recommended workflows with Git - -SYNOPSIS --------- -[verse] -git * - - -DESCRIPTION ------------ - -This document attempts to write down and motivate some of the workflow -elements used for `git.git` itself. Many ideas apply in general, -though the full workflow is rarely required for smaller projects with -fewer people involved. - -We formulate a set of 'rules' for quick reference, while the prose -tries to motivate each of them. Do not always take them literally; -you should value good reasons for your actions higher than manpages -such as this one. - - -SEPARATE CHANGES ----------------- - -As a general rule, you should try to split your changes into small -logical steps, and commit each of them. They should be consistent, -working independently of any later commits, pass the test suite, etc. -This makes the review process much easier, and the history much more -useful for later inspection and analysis, for example with -linkgit:git-blame[1] and linkgit:git-bisect[1]. - -To achieve this, try to split your work into small steps from the very -beginning. It is always easier to squash a few commits together than -to split one big commit into several. Don't be afraid of making too -small or imperfect steps along the way. You can always go back later -and edit the commits with `git rebase --interactive` before you -publish them. You can use `git stash push --keep-index` to run the -test suite independent of other uncommitted changes; see the EXAMPLES -section of linkgit:git-stash[1]. - - -MANAGING BRANCHES ------------------ - -There are two main tools that can be used to include changes from one -branch on another: linkgit:git-merge[1] and -linkgit:git-cherry-pick[1]. - -Merges have many advantages, so we try to solve as many problems as -possible with merges alone. Cherry-picking is still occasionally -useful; see "Merging upwards" below for an example. - -Most importantly, merging works at the branch level, while -cherry-picking works at the commit level. This means that a merge can -carry over the changes from 1, 10, or 1000 commits with equal ease, -which in turn means the workflow scales much better to a large number -of contributors (and contributions). Merges are also easier to -understand because a merge commit is a "promise" that all changes from -all its parents are now included. - -There is a tradeoff of course: merges require a more careful branch -management. The following subsections discuss the important points. - - -Graduation -~~~~~~~~~~ - -As a given feature goes from experimental to stable, it also -"graduates" between the corresponding branches of the software. -`git.git` uses the following 'integration branches': - -* 'maint' tracks the commits that should go into the next "maintenance - release", i.e., update of the last released stable version; - -* 'master' tracks the commits that should go into the next release; - -* 'next' is intended as a testing branch for topics being tested for - stability for master. - -There is a fourth official branch that is used slightly differently: - -* 'pu' (proposed updates) is an integration branch for things that are - not quite ready for inclusion yet (see "Integration Branches" - below). - -Each of the four branches is usually a direct descendant of the one -above it. - -Conceptually, the feature enters at an unstable branch (usually 'next' -or 'pu'), and "graduates" to 'master' for the next release once it is -considered stable enough. - - -Merging upwards -~~~~~~~~~~~~~~~ - -The "downwards graduation" discussed above cannot be done by actually -merging downwards, however, since that would merge 'all' changes on -the unstable branch into the stable one. Hence the following: - -.Merge upwards -[caption="Rule: "] -===================================== -Always commit your fixes to the oldest supported branch that requires -them. Then (periodically) merge the integration branches upwards into each -other. -===================================== - -This gives a very controlled flow of fixes. If you notice that you -have applied a fix to e.g. 'master' that is also required in 'maint', -you will need to cherry-pick it (using linkgit:git-cherry-pick[1]) -downwards. This will happen a few times and is nothing to worry about -unless you do it very frequently. - - -Topic branches -~~~~~~~~~~~~~~ - -Any nontrivial feature will require several patches to implement, and -may get extra bugfixes or improvements during its lifetime. - -Committing everything directly on the integration branches leads to many -problems: Bad commits cannot be undone, so they must be reverted one -by one, which creates confusing histories and further error potential -when you forget to revert part of a group of changes. Working in -parallel mixes up the changes, creating further confusion. - -Use of "topic branches" solves these problems. The name is pretty -self explanatory, with a caveat that comes from the "merge upwards" -rule above: - -.Topic branches -[caption="Rule: "] -===================================== -Make a side branch for every topic (feature, bugfix, ...). Fork it off -at the oldest integration branch that you will eventually want to merge it -into. -===================================== - -Many things can then be done very naturally: - -* To get the feature/bugfix into an integration branch, simply merge - it. If the topic has evolved further in the meantime, merge again. - (Note that you do not necessarily have to merge it to the oldest - integration branch first. For example, you can first merge a bugfix - to 'next', give it some testing time, and merge to 'maint' when you - know it is stable.) - -* If you find you need new features from the branch 'other' to continue - working on your topic, merge 'other' to 'topic'. (However, do not - do this "just habitually", see below.) - -* If you find you forked off the wrong branch and want to move it - "back in time", use linkgit:git-rebase[1]. - -Note that the last point clashes with the other two: a topic that has -been merged elsewhere should not be rebased. See the section on -RECOVERING FROM UPSTREAM REBASE in linkgit:git-rebase[1]. - -We should point out that "habitually" (regularly for no real reason) -merging an integration branch into your topics -- and by extension, -merging anything upstream into anything downstream on a regular basis --- is frowned upon: - -.Merge to downstream only at well-defined points -[caption="Rule: "] -===================================== -Do not merge to downstream except with a good reason: upstream API -changes affect your branch; your branch no longer merges to upstream -cleanly; etc. -===================================== - -Otherwise, the topic that was merged to suddenly contains more than a -single (well-separated) change. The many resulting small merges will -greatly clutter up history. Anyone who later investigates the history -of a file will have to find out whether that merge affected the topic -in development. An upstream might even inadvertently be merged into a -"more stable" branch. And so on. - - -Throw-away integration -~~~~~~~~~~~~~~~~~~~~~~ - -If you followed the last paragraph, you will now have many small topic -branches, and occasionally wonder how they interact. Perhaps the -result of merging them does not even work? But on the other hand, we -want to avoid merging them anywhere "stable" because such merges -cannot easily be undone. - -The solution, of course, is to make a merge that we can undo: merge -into a throw-away branch. - -.Throw-away integration branches -[caption="Rule: "] -===================================== -To test the interaction of several topics, merge them into a -throw-away branch. You must never base any work on such a branch! -===================================== - -If you make it (very) clear that this branch is going to be deleted -right after the testing, you can even publish this branch, for example -to give the testers a chance to work with it, or other developers a -chance to see if their in-progress work will be compatible. `git.git` -has such an official throw-away integration branch called 'pu'. - - -Branch management for a release -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Assuming you are using the merge approach discussed above, when you -are releasing your project you will need to do some additional branch -management work. - -A feature release is created from the 'master' branch, since 'master' -tracks the commits that should go into the next feature release. - -The 'master' branch is supposed to be a superset of 'maint'. If this -condition does not hold, then 'maint' contains some commits that -are not included on 'master'. The fixes represented by those commits -will therefore not be included in your feature release. - -To verify that 'master' is indeed a superset of 'maint', use git log: - -.Verify 'master' is a superset of 'maint' -[caption="Recipe: "] -===================================== -`git log master..maint` -===================================== - -This command should not list any commits. Otherwise, check out -'master' and merge 'maint' into it. - -Now you can proceed with the creation of the feature release. Apply a -tag to the tip of 'master' indicating the release version: - -.Release tagging -[caption="Recipe: "] -===================================== -`git tag -s -m "Git X.Y.Z" vX.Y.Z master` -===================================== - -You need to push the new tag to a public Git server (see -"DISTRIBUTED WORKFLOWS" below). This makes the tag available to -others tracking your project. The push could also trigger a -post-update hook to perform release-related items such as building -release tarballs and preformatted documentation pages. - -Similarly, for a maintenance release, 'maint' is tracking the commits -to be released. Therefore, in the steps above simply tag and push -'maint' rather than 'master'. - - -Maintenance branch management after a feature release -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -After a feature release, you need to manage your maintenance branches. - -First, if you wish to continue to release maintenance fixes for the -feature release made before the recent one, then you must create -another branch to track commits for that previous release. - -To do this, the current maintenance branch is copied to another branch -named with the previous release version number (e.g. maint-X.Y.(Z-1) -where X.Y.Z is the current release). - -.Copy maint -[caption="Recipe: "] -===================================== -`git branch maint-X.Y.(Z-1) maint` -===================================== - -The 'maint' branch should now be fast-forwarded to the newly released -code so that maintenance fixes can be tracked for the current release: - -.Update maint to new release -[caption="Recipe: "] -===================================== -* `git checkout maint` -* `git merge --ff-only master` -===================================== - -If the merge fails because it is not a fast-forward, then it is -possible some fixes on 'maint' were missed in the feature release. -This will not happen if the content of the branches was verified as -described in the previous section. - - -Branch management for next and pu after a feature release -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -After a feature release, the integration branch 'next' may optionally be -rewound and rebuilt from the tip of 'master' using the surviving -topics on 'next': - -.Rewind and rebuild next -[caption="Recipe: "] -===================================== -* `git switch -C next master` -* `git merge ai/topic_in_next1` -* `git merge ai/topic_in_next2` -* ... -===================================== - -The advantage of doing this is that the history of 'next' will be -clean. For example, some topics merged into 'next' may have initially -looked promising, but were later found to be undesirable or premature. -In such a case, the topic is reverted out of 'next' but the fact -remains in the history that it was once merged and reverted. By -recreating 'next', you give another incarnation of such topics a clean -slate to retry, and a feature release is a good point in history to do -so. - -If you do this, then you should make a public announcement indicating -that 'next' was rewound and rebuilt. - -The same rewind and rebuild process may be followed for 'pu'. A public -announcement is not necessary since 'pu' is a throw-away branch, as -described above. - - -DISTRIBUTED WORKFLOWS ---------------------- - -After the last section, you should know how to manage topics. In -general, you will not be the only person working on the project, so -you will have to share your work. - -Roughly speaking, there are two important workflows: merge and patch. -The important difference is that the merge workflow can propagate full -history, including merges, while patches cannot. Both workflows can -be used in parallel: in `git.git`, only subsystem maintainers use -the merge workflow, while everyone else sends patches. - -Note that the maintainer(s) may impose restrictions, such as -"Signed-off-by" requirements, that all commits/patches submitted for -inclusion must adhere to. Consult your project's documentation for -more information. - - -Merge workflow -~~~~~~~~~~~~~~ - -The merge workflow works by copying branches between upstream and -downstream. Upstream can merge contributions into the official -history; downstream base their work on the official history. - -There are three main tools that can be used for this: - -* linkgit:git-push[1] copies your branches to a remote repository, - usually to one that can be read by all involved parties; - -* linkgit:git-fetch[1] that copies remote branches to your repository; - and - -* linkgit:git-pull[1] that does fetch and merge in one go. - -Note the last point. Do 'not' use 'git pull' unless you actually want -to merge the remote branch. - -Getting changes out is easy: - -.Push/pull: Publishing branches/topics -[caption="Recipe: "] -===================================== -`git push <remote> <branch>` and tell everyone where they can fetch -from. -===================================== - -You will still have to tell people by other means, such as mail. (Git -provides the linkgit:git-request-pull[1] to send preformatted pull -requests to upstream maintainers to simplify this task.) - -If you just want to get the newest copies of the integration branches, -staying up to date is easy too: - -.Push/pull: Staying up to date -[caption="Recipe: "] -===================================== -Use `git fetch <remote>` or `git remote update` to stay up to date. -===================================== - -Then simply fork your topic branches from the stable remotes as -explained earlier. - -If you are a maintainer and would like to merge other people's topic -branches to the integration branches, they will typically send a -request to do so by mail. Such a request looks like - -------------------------------------- -Please pull from - <url> <branch> -------------------------------------- - -In that case, 'git pull' can do the fetch and merge in one go, as -follows. - -.Push/pull: Merging remote topics -[caption="Recipe: "] -===================================== -`git pull <url> <branch>` -===================================== - -Occasionally, the maintainer may get merge conflicts when they try to -pull changes from downstream. In this case, they can ask downstream to -do the merge and resolve the conflicts themselves (perhaps they will -know better how to resolve them). It is one of the rare cases where -downstream 'should' merge from upstream. - - -Patch workflow -~~~~~~~~~~~~~~ - -If you are a contributor that sends changes upstream in the form of -emails, you should use topic branches as usual (see above). Then use -linkgit:git-format-patch[1] to generate the corresponding emails -(highly recommended over manually formatting them because it makes the -maintainer's life easier). - -.format-patch/am: Publishing branches/topics -[caption="Recipe: "] -===================================== -* `git format-patch -M upstream..topic` to turn them into preformatted - patch files -* `git send-email --to=<recipient> <patches>` -===================================== - -See the linkgit:git-format-patch[1] and linkgit:git-send-email[1] -manpages for further usage notes. - -If the maintainer tells you that your patch no longer applies to the -current upstream, you will have to rebase your topic (you cannot use a -merge because you cannot format-patch merges): - -.format-patch/am: Keeping topics up to date -[caption="Recipe: "] -===================================== -`git pull --rebase <url> <branch>` -===================================== - -You can then fix the conflicts during the rebase. Presumably you have -not published your topic other than by mail, so rebasing it is not a -problem. - -If you receive such a patch series (as maintainer, or perhaps as a -reader of the mailing list it was sent to), save the mails to files, -create a new topic branch and use 'git am' to import the commits: - -.format-patch/am: Importing patches -[caption="Recipe: "] -===================================== -`git am < patch` -===================================== - -One feature worth pointing out is the three-way merge, which can help -if you get conflicts: `git am -3` will use index information contained -in patches to figure out the merge base. See linkgit:git-am[1] for -other options. - - -SEE ALSO --------- -linkgit:gittutorial[7], -linkgit:git-push[1], -linkgit:git-pull[1], -linkgit:git-merge[1], -linkgit:git-rebase[1], -linkgit:git-format-patch[1], -linkgit:git-send-email[1], -linkgit:git-am[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/third_party/git/Documentation/glossary-content.txt b/third_party/git/Documentation/glossary-content.txt deleted file mode 100644 index 090c888335..0000000000 --- a/third_party/git/Documentation/glossary-content.txt +++ /dev/null @@ -1,671 +0,0 @@ -[[def_alternate_object_database]]alternate object database:: - Via the alternates mechanism, a <<def_repository,repository>> - can inherit part of its <<def_object_database,object database>> - from another object database, which is called an "alternate". - -[[def_bare_repository]]bare repository:: - A bare repository is normally an appropriately - named <<def_directory,directory>> with a `.git` suffix that does not - have a locally checked-out copy of any of the files under - revision control. That is, all of the Git - administrative and control files that would normally be present in the - hidden `.git` sub-directory are directly present in the - `repository.git` directory instead, - and no other files are present and checked out. Usually publishers of - public repositories make bare repositories available. - -[[def_blob_object]]blob object:: - Untyped <<def_object,object>>, e.g. the contents of a file. - -[[def_branch]]branch:: - A "branch" is an active line of development. The most recent - <<def_commit,commit>> on a branch is referred to as the tip of - that branch. The tip of the branch is referenced by a branch - <<def_head,head>>, which moves forward as additional development - is done on the branch. A single Git - <<def_repository,repository>> can track an arbitrary number of - branches, but your <<def_working_tree,working tree>> is - associated with just one of them (the "current" or "checked out" - branch), and <<def_HEAD,HEAD>> points to that branch. - -[[def_cache]]cache:: - Obsolete for: <<def_index,index>>. - -[[def_chain]]chain:: - A list of objects, where each <<def_object,object>> in the list contains - a reference to its successor (for example, the successor of a - <<def_commit,commit>> could be one of its <<def_parent,parents>>). - -[[def_changeset]]changeset:: - BitKeeper/cvsps speak for "<<def_commit,commit>>". Since Git does not - store changes, but states, it really does not make sense to use the term - "changesets" with Git. - -[[def_checkout]]checkout:: - The action of updating all or part of the - <<def_working_tree,working tree>> with a <<def_tree_object,tree object>> - or <<def_blob_object,blob>> from the - <<def_object_database,object database>>, and updating the - <<def_index,index>> and <<def_HEAD,HEAD>> if the whole working tree has - been pointed at a new <<def_branch,branch>>. - -[[def_cherry-picking]]cherry-picking:: - In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of - changes out of a series of changes (typically commits) and record them - as a new series of changes on top of a different codebase. In Git, this is - performed by the "git cherry-pick" command to extract the change introduced - by an existing <<def_commit,commit>> and to record it based on the tip - of the current <<def_branch,branch>> as a new commit. - -[[def_clean]]clean:: - A <<def_working_tree,working tree>> is clean, if it - corresponds to the <<def_revision,revision>> referenced by the current - <<def_head,head>>. Also see "<<def_dirty,dirty>>". - -[[def_commit]]commit:: - As a noun: A single point in the - Git history; the entire history of a project is represented as a - set of interrelated commits. The word "commit" is often - used by Git in the same places other revision control systems - use the words "revision" or "version". Also used as a short - hand for <<def_commit_object,commit object>>. -+ -As a verb: The action of storing a new snapshot of the project's -state in the Git history, by creating a new commit representing the current -state of the <<def_index,index>> and advancing <<def_HEAD,HEAD>> -to point at the new commit. - -[[def_commit_object]]commit object:: - An <<def_object,object>> which contains the information about a - particular <<def_revision,revision>>, such as <<def_parent,parents>>, committer, - author, date and the <<def_tree_object,tree object>> which corresponds - to the top <<def_directory,directory>> of the stored - revision. - -[[def_commit-ish]]commit-ish (also committish):: - A <<def_commit_object,commit object>> or an - <<def_object,object>> that can be recursively dereferenced to - a commit object. - The following are all commit-ishes: - a commit object, - a <<def_tag_object,tag object>> that points to a commit - object, - a tag object that points to a tag object that points to a - commit object, - etc. - -[[def_core_git]]core Git:: - Fundamental data structures and utilities of Git. Exposes only limited - source code management tools. - -[[def_DAG]]DAG:: - Directed acyclic graph. The <<def_commit_object,commit objects>> form a - directed acyclic graph, because they have parents (directed), and the - graph of commit objects is acyclic (there is no <<def_chain,chain>> - which begins and ends with the same <<def_object,object>>). - -[[def_dangling_object]]dangling object:: - An <<def_unreachable_object,unreachable object>> which is not - <<def_reachable,reachable>> even from other unreachable objects; a - dangling object has no references to it from any - reference or <<def_object,object>> in the <<def_repository,repository>>. - -[[def_detached_HEAD]]detached HEAD:: - Normally the <<def_HEAD,HEAD>> stores the name of a - <<def_branch,branch>>, and commands that operate on the - history HEAD represents operate on the history leading to the - tip of the branch the HEAD points at. However, Git also - allows you to <<def_checkout,check out>> an arbitrary - <<def_commit,commit>> that isn't necessarily the tip of any - particular branch. The HEAD in such a state is called - "detached". -+ -Note that commands that operate on the history of the current branch -(e.g. `git commit` to build a new history on top of it) still work -while the HEAD is detached. They update the HEAD to point at the tip -of the updated history without affecting any branch. Commands that -update or inquire information _about_ the current branch (e.g. `git -branch --set-upstream-to` that sets what remote-tracking branch the -current branch integrates with) obviously do not work, as there is no -(real) current branch to ask about in this state. - -[[def_directory]]directory:: - The list you get with "ls" :-) - -[[def_dirty]]dirty:: - A <<def_working_tree,working tree>> is said to be "dirty" if - it contains modifications which have not been <<def_commit,committed>> to the current - <<def_branch,branch>>. - -[[def_evil_merge]]evil merge:: - An evil merge is a <<def_merge,merge>> that introduces changes that - do not appear in any <<def_parent,parent>>. - -[[def_fast_forward]]fast-forward:: - A fast-forward is a special type of <<def_merge,merge>> where you have a - <<def_revision,revision>> and you are "merging" another - <<def_branch,branch>>'s changes that happen to be a descendant of what - you have. In such a case, you do not make a new <<def_merge,merge>> - <<def_commit,commit>> but instead just update to his - revision. This will happen frequently on a - <<def_remote_tracking_branch,remote-tracking branch>> of a remote - <<def_repository,repository>>. - -[[def_fetch]]fetch:: - Fetching a <<def_branch,branch>> means to get the - branch's <<def_head_ref,head ref>> from a remote - <<def_repository,repository>>, to find out which objects are - missing from the local <<def_object_database,object database>>, - and to get them, too. See also linkgit:git-fetch[1]. - -[[def_file_system]]file system:: - Linus Torvalds originally designed Git to be a user space file system, - i.e. the infrastructure to hold files and directories. That ensured the - efficiency and speed of Git. - -[[def_git_archive]]Git archive:: - Synonym for <<def_repository,repository>> (for arch people). - -[[def_gitfile]]gitfile:: - A plain file `.git` at the root of a working tree that - points at the directory that is the real repository. - -[[def_grafts]]grafts:: - Grafts enables two otherwise different lines of development to be joined - together by recording fake ancestry information for commits. This way - you can make Git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has - is different from what was recorded when the commit was - created. Configured via the `.git/info/grafts` file. -+ -Note that the grafts mechanism is outdated and can lead to problems -transferring objects between repositories; see linkgit:git-replace[1] -for a more flexible and robust system to do the same thing. - -[[def_hash]]hash:: - In Git's context, synonym for <<def_object_name,object name>>. - -[[def_head]]head:: - A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a - <<def_branch,branch>>. Heads are stored in a file in - `$GIT_DIR/refs/heads/` directory, except when using packed refs. (See - linkgit:git-pack-refs[1].) - -[[def_HEAD]]HEAD:: - The current <<def_branch,branch>>. In more detail: Your <<def_working_tree, - working tree>> is normally derived from the state of the tree - referred to by HEAD. HEAD is a reference to one of the - <<def_head,heads>> in your repository, except when using a - <<def_detached_HEAD,detached HEAD>>, in which case it directly - references an arbitrary commit. - -[[def_head_ref]]head ref:: - A synonym for <<def_head,head>>. - -[[def_hook]]hook:: - During the normal execution of several Git commands, call-outs are made - to optional scripts that allow a developer to add functionality or - checking. Typically, the hooks allow for a command to be pre-verified - and potentially aborted, and allow for a post-notification after the - operation is done. The hook scripts are found in the - `$GIT_DIR/hooks/` directory, and are enabled by simply - removing the `.sample` suffix from the filename. In earlier versions - of Git you had to make them executable. - -[[def_index]]index:: - A collection of files with stat information, whose contents are stored - as objects. The index is a stored version of your - <<def_working_tree,working tree>>. Truth be told, it can also contain a second, and even - a third version of a working tree, which are used - when <<def_merge,merging>>. - -[[def_index_entry]]index entry:: - The information regarding a particular file, stored in the - <<def_index,index>>. An index entry can be unmerged, if a - <<def_merge,merge>> was started, but not yet finished (i.e. if - the index contains multiple versions of that file). - -[[def_master]]master:: - The default development <<def_branch,branch>>. Whenever you - create a Git <<def_repository,repository>>, a branch named - "master" is created, and becomes the active branch. In most - cases, this contains the local development, though that is - purely by convention and is not required. - -[[def_merge]]merge:: - As a verb: To bring the contents of another - <<def_branch,branch>> (possibly from an external - <<def_repository,repository>>) into the current branch. In the - case where the merged-in branch is from a different repository, - this is done by first <<def_fetch,fetching>> the remote branch - and then merging the result into the current branch. This - combination of fetch and merge operations is called a - <<def_pull,pull>>. Merging is performed by an automatic process - that identifies changes made since the branches diverged, and - then applies all those changes together. In cases where changes - conflict, manual intervention may be required to complete the - merge. -+ -As a noun: unless it is a <<def_fast_forward,fast-forward>>, a -successful merge results in the creation of a new <<def_commit,commit>> -representing the result of the merge, and having as -<<def_parent,parents>> the tips of the merged <<def_branch,branches>>. -This commit is referred to as a "merge commit", or sometimes just a -"merge". - -[[def_object]]object:: - The unit of storage in Git. It is uniquely identified by the - <<def_SHA1,SHA-1>> of its contents. Consequently, an - object cannot be changed. - -[[def_object_database]]object database:: - Stores a set of "objects", and an individual <<def_object,object>> is - identified by its <<def_object_name,object name>>. The objects usually - live in `$GIT_DIR/objects/`. - -[[def_object_identifier]]object identifier:: - Synonym for <<def_object_name,object name>>. - -[[def_object_name]]object name:: - The unique identifier of an <<def_object,object>>. The - object name is usually represented by a 40 character - hexadecimal string. Also colloquially called <<def_SHA1,SHA-1>>. - -[[def_object_type]]object type:: - One of the identifiers "<<def_commit_object,commit>>", - "<<def_tree_object,tree>>", "<<def_tag_object,tag>>" or - "<<def_blob_object,blob>>" describing the type of an - <<def_object,object>>. - -[[def_octopus]]octopus:: - To <<def_merge,merge>> more than two <<def_branch,branches>>. - -[[def_origin]]origin:: - The default upstream <<def_repository,repository>>. Most projects have - at least one upstream project which they track. By default - 'origin' is used for that purpose. New upstream updates - will be fetched into <<def_remote_tracking_branch,remote-tracking branches>> named - origin/name-of-upstream-branch, which you can see using - `git branch -r`. - -[[def_overlay]]overlay:: - Only update and add files to the working directory, but don't - delete them, similar to how 'cp -R' would update the contents - in the destination directory. This is the default mode in a - <<def_checkout,checkout>> when checking out files from the - <<def_index,index>> or a <<def_tree-ish,tree-ish>>. In - contrast, no-overlay mode also deletes tracked files not - present in the source, similar to 'rsync --delete'. - -[[def_pack]]pack:: - A set of objects which have been compressed into one file (to save space - or to transmit them efficiently). - -[[def_pack_index]]pack index:: - The list of identifiers, and other information, of the objects in a - <<def_pack,pack>>, to assist in efficiently accessing the contents of a - pack. - -[[def_pathspec]]pathspec:: - Pattern used to limit paths in Git commands. -+ -Pathspecs are used on the command line of "git ls-files", "git -ls-tree", "git add", "git grep", "git diff", "git checkout", -and many other commands to -limit the scope of operations to some subset of the tree or -worktree. See the documentation of each command for whether -paths are relative to the current directory or toplevel. The -pathspec syntax is as follows: -+ --- - -* any path matches itself -* the pathspec up to the last slash represents a - directory prefix. The scope of that pathspec is - limited to that subtree. -* the rest of the pathspec is a pattern for the remainder - of the pathname. Paths relative to the directory - prefix will be matched against that pattern using fnmatch(3); - in particular, '*' and '?' _can_ match directory separators. - --- -+ -For example, Documentation/*.jpg will match all .jpg files -in the Documentation subtree, -including Documentation/chapter_1/figure_1.jpg. -+ -A pathspec that begins with a colon `:` has special meaning. In the -short form, the leading colon `:` is followed by zero or more "magic -signature" letters (which optionally is terminated by another colon `:`), -and the remainder is the pattern to match against the path. -The "magic signature" consists of ASCII symbols that are neither -alphanumeric, glob, regex special characters nor colon. -The optional colon that terminates the "magic signature" can be -omitted if the pattern begins with a character that does not belong to -"magic signature" symbol set and is not a colon. -+ -In the long form, the leading colon `:` is followed by an open -parenthesis `(`, a comma-separated list of zero or more "magic words", -and a close parentheses `)`, and the remainder is the pattern to match -against the path. -+ -A pathspec with only a colon means "there is no pathspec". This form -should not be combined with other pathspec. -+ --- -top;; - The magic word `top` (magic signature: `/`) makes the pattern - match from the root of the working tree, even when you are - running the command from inside a subdirectory. - -literal;; - Wildcards in the pattern such as `*` or `?` are treated - as literal characters. - -icase;; - Case insensitive match. - -glob;; - Git treats the pattern as a shell glob suitable for - consumption by fnmatch(3) with the FNM_PATHNAME flag: - wildcards in the pattern will not match a / in the pathname. - For example, "Documentation/{asterisk}.html" matches - "Documentation/git.html" but not "Documentation/ppc/ppc.html" - or "tools/perf/Documentation/perf.html". -+ -Two consecutive asterisks ("`**`") in patterns matched against -full pathname may have special meaning: - - - A leading "`**`" followed by a slash means match in all - directories. For example, "`**/foo`" matches file or directory - "`foo`" anywhere, the same as pattern "`foo`". "`**/foo/bar`" - matches file or directory "`bar`" anywhere that is directly - under directory "`foo`". - - - A trailing "`/**`" matches everything inside. For example, - "`abc/**`" matches all files inside directory "abc", relative - to the location of the `.gitignore` file, with infinite depth. - - - A slash followed by two consecutive asterisks then a slash - matches zero or more directories. For example, "`a/**/b`" - matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on. - - - Other consecutive asterisks are considered invalid. -+ -Glob magic is incompatible with literal magic. - -attr;; -After `attr:` comes a space separated list of "attribute -requirements", all of which must be met in order for the -path to be considered a match; this is in addition to the -usual non-magic pathspec pattern matching. -See linkgit:gitattributes[5]. -+ -Each of the attribute requirements for the path takes one of -these forms: - -- "`ATTR`" requires that the attribute `ATTR` be set. - -- "`-ATTR`" requires that the attribute `ATTR` be unset. - -- "`ATTR=VALUE`" requires that the attribute `ATTR` be - set to the string `VALUE`. - -- "`!ATTR`" requires that the attribute `ATTR` be - unspecified. -+ -Note that when matching against a tree object, attributes are still -obtained from working tree, not from the given tree object. - -exclude;; - After a path matches any non-exclude pathspec, it will be run - through all exclude pathspecs (magic signature: `!` or its - synonym `^`). If it matches, the path is ignored. When there - is no non-exclude pathspec, the exclusion is applied to the - result set as if invoked without any pathspec. --- - -[[def_parent]]parent:: - A <<def_commit_object,commit object>> contains a (possibly empty) list - of the logical predecessor(s) in the line of development, i.e. its - parents. - -[[def_pickaxe]]pickaxe:: - The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore - routines that help select changes that add or delete a given text - string. With the `--pickaxe-all` option, it can be used to view the full - <<def_changeset,changeset>> that introduced or removed, say, a - particular line of text. See linkgit:git-diff[1]. - -[[def_plumbing]]plumbing:: - Cute name for <<def_core_git,core Git>>. - -[[def_porcelain]]porcelain:: - Cute name for programs and program suites depending on - <<def_core_git,core Git>>, presenting a high level access to - core Git. Porcelains expose more of a <<def_SCM,SCM>> - interface than the <<def_plumbing,plumbing>>. - -[[def_per_worktree_ref]]per-worktree ref:: - Refs that are per-<<def_working_tree,worktree>>, rather than - global. This is presently only <<def_HEAD,HEAD>> and any refs - that start with `refs/bisect/`, but might later include other - unusual refs. - -[[def_pseudoref]]pseudoref:: - Pseudorefs are a class of files under `$GIT_DIR` which behave - like refs for the purposes of rev-parse, but which are treated - specially by git. Pseudorefs both have names that are all-caps, - and always start with a line consisting of a - <<def_SHA1,SHA-1>> followed by whitespace. So, HEAD is not a - pseudoref, because it is sometimes a symbolic ref. They might - optionally contain some additional data. `MERGE_HEAD` and - `CHERRY_PICK_HEAD` are examples. Unlike - <<def_per_worktree_ref,per-worktree refs>>, these files cannot - be symbolic refs, and never have reflogs. They also cannot be - updated through the normal ref update machinery. Instead, - they are updated by directly writing to the files. However, - they can be read as if they were refs, so `git rev-parse - MERGE_HEAD` will work. - -[[def_pull]]pull:: - Pulling a <<def_branch,branch>> means to <<def_fetch,fetch>> it and - <<def_merge,merge>> it. See also linkgit:git-pull[1]. - -[[def_push]]push:: - Pushing a <<def_branch,branch>> means to get the branch's - <<def_head_ref,head ref>> from a remote <<def_repository,repository>>, - find out if it is an ancestor to the branch's local - head ref, and in that case, putting all - objects, which are <<def_reachable,reachable>> from the local - head ref, and which are missing from the remote - repository, into the remote - <<def_object_database,object database>>, and updating the remote - head ref. If the remote <<def_head,head>> is not an - ancestor to the local head, the push fails. - -[[def_reachable]]reachable:: - All of the ancestors of a given <<def_commit,commit>> are said to be - "reachable" from that commit. More - generally, one <<def_object,object>> is reachable from - another if we can reach the one from the other by a <<def_chain,chain>> - that follows <<def_tag,tags>> to whatever they tag, - <<def_commit_object,commits>> to their parents or trees, and - <<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>> - that they contain. - -[[def_rebase]]rebase:: - To reapply a series of changes from a <<def_branch,branch>> to a - different base, and reset the <<def_head,head>> of that branch - to the result. - -[[def_ref]]ref:: - A name that begins with `refs/` (e.g. `refs/heads/master`) - that points to an <<def_object_name,object name>> or another - ref (the latter is called a <<def_symref,symbolic ref>>). - For convenience, a ref can sometimes be abbreviated when used - as an argument to a Git command; see linkgit:gitrevisions[7] - for details. - Refs are stored in the <<def_repository,repository>>. -+ -The ref namespace is hierarchical. -Different subhierarchies are used for different purposes (e.g. the -`refs/heads/` hierarchy is used to represent local branches). -+ -There are a few special-purpose refs that do not begin with `refs/`. -The most notable example is `HEAD`. - -[[def_reflog]]reflog:: - A reflog shows the local "history" of a ref. In other words, - it can tell you what the 3rd last revision in _this_ repository - was, and what was the current state in _this_ repository, - yesterday 9:14pm. See linkgit:git-reflog[1] for details. - -[[def_refspec]]refspec:: - A "refspec" is used by <<def_fetch,fetch>> and - <<def_push,push>> to describe the mapping between remote - <<def_ref,ref>> and local ref. - -[[def_remote]]remote repository:: - A <<def_repository,repository>> which is used to track the same - project but resides somewhere else. To communicate with remotes, - see <<def_fetch,fetch>> or <<def_push,push>>. - -[[def_remote_tracking_branch]]remote-tracking branch:: - A <<def_ref,ref>> that is used to follow changes from another - <<def_repository,repository>>. It typically looks like - 'refs/remotes/foo/bar' (indicating that it tracks a branch named - 'bar' in a remote named 'foo'), and matches the right-hand-side of - a configured fetch <<def_refspec,refspec>>. A remote-tracking - branch should not contain direct modifications or have local - commits made to it. - -[[def_repository]]repository:: - A collection of <<def_ref,refs>> together with an - <<def_object_database,object database>> containing all objects - which are <<def_reachable,reachable>> from the refs, possibly - accompanied by meta data from one or more <<def_porcelain,porcelains>>. A - repository can share an object database with other repositories - via <<def_alternate_object_database,alternates mechanism>>. - -[[def_resolve]]resolve:: - The action of fixing up manually what a failed automatic - <<def_merge,merge>> left behind. - -[[def_revision]]revision:: - Synonym for <<def_commit,commit>> (the noun). - -[[def_rewind]]rewind:: - To throw away part of the development, i.e. to assign the - <<def_head,head>> to an earlier <<def_revision,revision>>. - -[[def_SCM]]SCM:: - Source code management (tool). - -[[def_SHA1]]SHA-1:: - "Secure Hash Algorithm 1"; a cryptographic hash function. - In the context of Git used as a synonym for <<def_object_name,object name>>. - -[[def_shallow_clone]]shallow clone:: - Mostly a synonym to <<def_shallow_repository,shallow repository>> - but the phrase makes it more explicit that it was created by - running `git clone --depth=...` command. - -[[def_shallow_repository]]shallow repository:: - A shallow <<def_repository,repository>> has an incomplete - history some of whose <<def_commit,commits>> have <<def_parent,parents>> cauterized away (in other - words, Git is told to pretend that these commits do not have the - parents, even though they are recorded in the <<def_commit_object,commit - object>>). This is sometimes useful when you are interested only in the - recent history of a project even though the real history recorded in the - upstream is much larger. A shallow repository - is created by giving the `--depth` option to linkgit:git-clone[1], and - its history can be later deepened with linkgit:git-fetch[1]. - -[[def_stash]]stash entry:: - An <<def_object,object>> used to temporarily store the contents of a - <<def_dirty,dirty>> working directory and the index for future reuse. - -[[def_submodule]]submodule:: - A <<def_repository,repository>> that holds the history of a - separate project inside another repository (the latter of - which is called <<def_superproject, superproject>>). - -[[def_superproject]]superproject:: - A <<def_repository,repository>> that references repositories - of other projects in its working tree as <<def_submodule,submodules>>. - The superproject knows about the names of (but does not hold - copies of) commit objects of the contained submodules. - -[[def_symref]]symref:: - Symbolic reference: instead of containing the <<def_SHA1,SHA-1>> - id itself, it is of the format 'ref: refs/some/thing' and when - referenced, it recursively dereferences to this reference. - '<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic - references are manipulated with the linkgit:git-symbolic-ref[1] - command. - -[[def_tag]]tag:: - A <<def_ref,ref>> under `refs/tags/` namespace that points to an - object of an arbitrary type (typically a tag points to either a - <<def_tag_object,tag>> or a <<def_commit_object,commit object>>). - In contrast to a <<def_head,head>>, a tag is not updated by - the `commit` command. A Git tag has nothing to do with a Lisp - tag (which would be called an <<def_object_type,object type>> - in Git's context). A tag is most typically used to mark a particular - point in the commit ancestry <<def_chain,chain>>. - -[[def_tag_object]]tag object:: - An <<def_object,object>> containing a <<def_ref,ref>> pointing to - another object, which can contain a message just like a - <<def_commit_object,commit object>>. It can also contain a (PGP) - signature, in which case it is called a "signed tag object". - -[[def_topic_branch]]topic branch:: - A regular Git <<def_branch,branch>> that is used by a developer to - identify a conceptual line of development. Since branches are very easy - and inexpensive, it is often desirable to have several small branches - that each contain very well defined concepts or small incremental yet - related changes. - -[[def_tree]]tree:: - Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree - object>> together with the dependent <<def_blob_object,blob>> and tree objects - (i.e. a stored representation of a working tree). - -[[def_tree_object]]tree object:: - An <<def_object,object>> containing a list of file names and modes along - with refs to the associated blob and/or tree objects. A - <<def_tree,tree>> is equivalent to a <<def_directory,directory>>. - -[[def_tree-ish]]tree-ish (also treeish):: - A <<def_tree_object,tree object>> or an <<def_object,object>> - that can be recursively dereferenced to a tree object. - Dereferencing a <<def_commit_object,commit object>> yields the - tree object corresponding to the <<def_revision,revision>>'s - top <<def_directory,directory>>. - The following are all tree-ishes: - a <<def_commit-ish,commit-ish>>, - a tree object, - a <<def_tag_object,tag object>> that points to a tree object, - a tag object that points to a tag object that points to a tree - object, - etc. - -[[def_unmerged_index]]unmerged index:: - An <<def_index,index>> which contains unmerged - <<def_index_entry,index entries>>. - -[[def_unreachable_object]]unreachable object:: - An <<def_object,object>> which is not <<def_reachable,reachable>> from a - <<def_branch,branch>>, <<def_tag,tag>>, or any other reference. - -[[def_upstream_branch]]upstream branch:: - The default <<def_branch,branch>> that is merged into the branch in - question (or the branch in question is rebased onto). It is configured - via branch.<name>.remote and branch.<name>.merge. If the upstream branch - of 'A' is 'origin/B' sometimes we say "'A' is tracking 'origin/B'". - -[[def_working_tree]]working tree:: - The tree of actual checked out files. The working tree normally - contains the contents of the <<def_HEAD,HEAD>> commit's tree, - plus any local changes that you have made but not yet committed. diff --git a/third_party/git/Documentation/howto-index.sh b/third_party/git/Documentation/howto-index.sh deleted file mode 100755 index 167b363668..0000000000 --- a/third_party/git/Documentation/howto-index.sh +++ /dev/null @@ -1,56 +0,0 @@ -#!/bin/sh - -cat <<\EOF -Git Howto Index -=============== - -Here is a collection of mailing list postings made by various -people describing how they use Git in their workflow. - -EOF - -for txt -do - title=$(expr "$txt" : '.*/\(.*\)\.txt$') - from=$(sed -ne ' - /^$/q - /^From:[ ]/{ - s/// - s/^[ ]*// - s/[ ]*$// - s/^/by / - p - } - ' "$txt") - - abstract=$(sed -ne ' - /^Abstract:[ ]/{ - s/^[^ ]*// - x - s/.*// - x - : again - /^[ ]/{ - s/^[ ]*// - H - n - b again - } - x - p - q - }' "$txt") - - if grep 'Content-type: text/asciidoc' >/dev/null $txt - then - file=$(expr "$txt" : '\(.*\)\.txt$').html - else - file="$txt" - fi - - echo "* link:$file[$title] $from -$abstract - -" - -done diff --git a/third_party/git/Documentation/howto/keep-canonical-history-correct.txt b/third_party/git/Documentation/howto/keep-canonical-history-correct.txt deleted file mode 100644 index 35d48ef714..0000000000 --- a/third_party/git/Documentation/howto/keep-canonical-history-correct.txt +++ /dev/null @@ -1,216 +0,0 @@ -From: Junio C Hamano <gitster@pobox.com> -Date: Wed, 07 May 2014 13:15:39 -0700 -Subject: Beginner question on "Pull is mostly evil" -Abstract: This how-to explains a method for keeping a - project's history correct when using git pull. -Content-type: text/asciidoc - -Keep authoritative canonical history correct with git pull -========================================================== - -Sometimes a new project integrator will end up with project history -that appears to be "backwards" from what other project developers -expect. This howto presents a suggested integration workflow for -maintaining a central repository. - -Suppose that that central repository has this history: - ------------- - ---o---o---A ------------- - -which ends at commit `A` (time flows from left to right and each node -in the graph is a commit, lines between them indicating parent-child -relationship). - -Then you clone it and work on your own commits, which leads you to -have this history in *your* repository: - ------------- - ---o---o---A---B---C ------------- - -Imagine your coworker did the same and built on top of `A` in *his* -repository in the meantime, and then pushed it to the -central repository: - ------------- - ---o---o---A---X---Y---Z ------------- - -Now, if you `git push` at this point, because your history that leads -to `C` lacks `X`, `Y` and `Z`, it will fail. You need to somehow make -the tip of your history a descendant of `Z`. - -One suggested way to solve the problem is "fetch and then merge", aka -`git pull`. When you fetch, your repository will have a history like -this: - ------------- - ---o---o---A---B---C - \ - X---Y---Z ------------- - -Once you run merge after that, while still on *your* branch, i.e. `C`, -you will create a merge `M` and make the history look like this: - ------------- - ---o---o---A---B---C---M - \ / - X---Y---Z ------------- - -`M` is a descendant of `Z`, so you can push to update the central -repository. Such a merge `M` does not lose any commit in both -histories, so in that sense it may not be wrong, but when people want -to talk about "the authoritative canonical history that is shared -among the project participants", i.e. "the trunk", they often view -it as "commits you see by following the first-parent chain", and use -this command to view it: - ------------- - $ git log --first-parent ------------- - -For all other people who observed the central repository after your -coworker pushed `Z` but before you pushed `M`, the commit on the trunk -used to be `o-o-A-X-Y-Z`. But because you made `M` while you were on -`C`, `M`'s first parent is `C`, so by pushing `M` to advance the -central repository, you made `X-Y-Z` a side branch, not on the trunk. - -You would rather want to have a history of this shape: - ------------- - ---o---o---A---X---Y---Z---M' - \ / - B-----------C ------------- - -so that in the first-parent chain, it is clear that the project first -did `X` and then `Y` and then `Z` and merged a change that consists of -two commits `B` and `C` that achieves a single goal. You may have -worked on fixing the bug #12345 with these two patches, and the merge -`M'` with swapped parents can say in its log message "Merge -fix-bug-12345". Having a way to tell `git pull` to create a merge -but record the parents in reverse order may be a way to do so. - -Note that I said "achieves a single goal" above, because this is -important. "Swapping the merge order" only covers a special case -where the project does not care too much about having unrelated -things done on a single merge but cares a lot about first-parent -chain. - -There are multiple schools of thought about the "trunk" management. - - 1. Some projects want to keep a completely linear history without any - merges. Obviously, swapping the merge order would not match their - taste. You would need to flatten your history on top of the - updated upstream to result in a history of this shape instead: -+ ------------- - ---o---o---A---X---Y---Z---B---C ------------- -+ -with `git pull --rebase` or something. - - 2. Some projects tolerate merges in their history, but do not worry - too much about the first-parent order, and allow fast-forward - merges. To them, swapping the merge order does not hurt, but - it is unnecessary. - - 3. Some projects want each commit on the "trunk" to do one single - thing. The output of `git log --first-parent` in such a project - would show either a merge of a side branch that completes a single - theme, or a single commit that completes a single theme by itself. - If your two commits `B` and `C` (or they may even be two groups of - commits) were solving two independent issues, then the merge `M'` - we made in the earlier example by swapping the merge order is - still not up to the project standard. It merges two unrelated - efforts `B` and `C` at the same time. - -For projects in the last category (Git itself is one of them), -individual developers would want to prepare a history more like -this: - ------------- - C0--C1--C2 topic-c - / - ---o---o---A master - \ - B0--B1--B2 topic-b ------------- - -That is, keeping separate topics on separate branches, perhaps like -so: - ------------- - $ git clone $URL work && cd work - $ git checkout -b topic-b master - $ ... work to create B0, B1 and B2 to complete one theme - $ git checkout -b topic-c master - $ ... same for the theme of topic-c ------------- - -And then - ------------- - $ git checkout master - $ git pull --ff-only ------------- - -would grab `X`, `Y` and `Z` from the upstream and advance your master -branch: - ------------- - C0--C1--C2 topic-c - / - ---o---o---A---X---Y---Z master - \ - B0--B1--B2 topic-b ------------- - -And then you would merge these two branches separately: - ------------- - $ git merge topic-b - $ git merge topic-c ------------- - -to result in - ------------- - C0--C1---------C2 - / \ - ---o---o---A---X---Y---Z---M---N - \ / - B0--B1-----B2 ------------- - -and push it back to the central repository. - -It is very much possible that while you are merging topic-b and -topic-c, somebody again advanced the history in the central repository -to put `W` on top of `Z`, and make your `git push` fail. - -In such a case, you would rewind to discard `M` and `N`, update the -tip of your 'master' again and redo the two merges: - ------------- - $ git reset --hard origin/master - $ git pull --ff-only - $ git merge topic-b - $ git merge topic-c ------------- - -The procedure will result in a history that looks like this: - ------------- - C0--C1--------------C2 - / \ - ---o---o---A---X---Y---Z---W---M'--N' - \ / - B0--B1---------B2 ------------- - -See also http://git-blame.blogspot.com/2013/09/fun-with-first-parent-history.html diff --git a/third_party/git/Documentation/howto/maintain-git.txt b/third_party/git/Documentation/howto/maintain-git.txt deleted file mode 100644 index ca4378740c..0000000000 --- a/third_party/git/Documentation/howto/maintain-git.txt +++ /dev/null @@ -1,449 +0,0 @@ -From: Junio C Hamano <gitster@pobox.com> -Date: Wed, 21 Nov 2007 16:32:55 -0800 -Subject: Addendum to "MaintNotes" -Abstract: Imagine that Git development is racing along as usual, when our friendly - neighborhood maintainer is struck down by a wayward bus. Out of the - hordes of suckers (loyal developers), you have been tricked (chosen) to - step up as the new maintainer. This howto will show you "how to" do it. -Content-type: text/asciidoc - -How to maintain Git -=================== - -Activities ----------- - -The maintainer's Git time is spent on three activities. - - - Communication (45%) - - Mailing list discussions on general design, fielding user - questions, diagnosing bug reports; reviewing, commenting on, - suggesting alternatives to, and rejecting patches. - - - Integration (50%) - - Applying new patches from the contributors while spotting and - correcting minor mistakes, shuffling the integration and - testing branches, pushing the results out, cutting the - releases, and making announcements. - - - Own development (5%) - - Scratching my own itch and sending proposed patch series out. - -The Policy ----------- - -The policy on Integration is informally mentioned in "A Note -from the maintainer" message, which is periodically posted to -this mailing list after each feature release is made. - - - Feature releases are numbered as vX.Y.0 and are meant to - contain bugfixes and enhancements in any area, including - functionality, performance and usability, without regression. - - - One release cycle for a feature release is expected to last for - eight to ten weeks. - - - Maintenance releases are numbered as vX.Y.Z and are meant - to contain only bugfixes for the corresponding vX.Y.0 feature - release and earlier maintenance releases vX.Y.W (W < Z). - - - 'master' branch is used to prepare for the next feature - release. In other words, at some point, the tip of 'master' - branch is tagged with vX.Y.0. - - - 'maint' branch is used to prepare for the next maintenance - release. After the feature release vX.Y.0 is made, the tip - of 'maint' branch is set to that release, and bugfixes will - accumulate on the branch, and at some point, the tip of the - branch is tagged with vX.Y.1, vX.Y.2, and so on. - - - 'next' branch is used to publish changes (both enhancements - and fixes) that (1) have worthwhile goal, (2) are in a fairly - good shape suitable for everyday use, (3) but have not yet - demonstrated to be regression free. New changes are tested - in 'next' before merged to 'master'. - - - 'pu' branch is used to publish other proposed changes that do - not yet pass the criteria set for 'next'. - - - The tips of 'master' and 'maint' branches will not be rewound to - allow people to build their own customization on top of them. - Early in a new development cycle, 'next' is rewound to the tip of - 'master' once, but otherwise it will not be rewound until the end - of the cycle. - - - Usually 'master' contains all of 'maint' and 'next' contains all - of 'master'. 'pu' contains all the topics merged to 'next', but - is rebuilt directly on 'master'. - - - The tip of 'master' is meant to be more stable than any - tagged releases, and the users are encouraged to follow it. - - - The 'next' branch is where new action takes place, and the - users are encouraged to test it so that regressions and bugs - are found before new topics are merged to 'master'. - -Note that before v1.9.0 release, the version numbers used to be -structured slightly differently. vX.Y.Z were feature releases while -vX.Y.Z.W were maintenance releases for vX.Y.Z. - - -A Typical Git Day ------------------ - -A typical Git day for the maintainer implements the above policy -by doing the following: - - - Scan mailing list. Respond with review comments, suggestions - etc. Kibitz. Collect potentially usable patches from the - mailing list. Patches about a single topic go to one mailbox (I - read my mail in Gnus, and type \C-o to save/append messages in - files in mbox format). - - - Write his own patches to address issues raised on the list but - nobody has stepped up solving. Send it out just like other - contributors do, and pick them up just like patches from other - contributors (see above). - - - Review the patches in the saved mailboxes. Edit proposed log - message for typofixes and clarifications, and add Acks - collected from the list. Edit patch to incorporate "Oops, - that should have been like this" fixes from the discussion. - - - Classify the collected patches and handle 'master' and - 'maint' updates: - - - Obviously correct fixes that pertain to the tip of 'maint' - are directly applied to 'maint'. - - - Obviously correct fixes that pertain to the tip of 'master' - are directly applied to 'master'. - - - Other topics are not handled in this step. - - This step is done with "git am". - - $ git checkout master ;# or "git checkout maint" - $ git am -sc3 mailbox - $ make test - - In practice, almost no patch directly goes to 'master' or - 'maint'. - - - Review the last issue of "What's cooking" message, review the - topics ready for merging (topic->master and topic->maint). Use - "Meta/cook -w" script (where Meta/ contains a checkout of the - 'todo' branch) to aid this step. - - And perform the merge. Use "Meta/Reintegrate -e" script (see - later) to aid this step. - - $ Meta/cook -w last-issue-of-whats-cooking.mbox - - $ git checkout master ;# or "git checkout maint" - $ echo ai/topic | Meta/Reintegrate -e ;# "git merge ai/topic" - $ git log -p ORIG_HEAD.. ;# final review - $ git diff ORIG_HEAD.. ;# final review - $ make test ;# final review - - - Handle the remaining patches: - - - Anything unobvious that is applicable to 'master' (in other - words, does not depend on anything that is still in 'next' - and not in 'master') is applied to a new topic branch that - is forked from the tip of 'master'. This includes both - enhancements and unobvious fixes to 'master'. A topic - branch is named as ai/topic where "ai" is two-letter string - named after author's initial and "topic" is a descriptive name - of the topic (in other words, "what's the series is about"). - - - An unobvious fix meant for 'maint' is applied to a new - topic branch that is forked from the tip of 'maint'. The - topic is named as ai/maint-topic. - - - Changes that pertain to an existing topic are applied to - the branch, but: - - - obviously correct ones are applied first; - - - questionable ones are discarded or applied to near the tip; - - - Replacement patches to an existing topic are accepted only - for commits not in 'next'. - - The above except the "replacement" are all done with: - - $ git checkout ai/topic ;# or "git checkout -b ai/topic master" - $ git am -sc3 mailbox - - while patch replacement is often done by: - - $ git format-patch ai/topic~$n..ai/topic ;# export existing - - then replace some parts with the new patch, and reapplying: - - $ git checkout ai/topic - $ git reset --hard ai/topic~$n - $ git am -sc3 -s 000*.txt - - The full test suite is always run for 'maint' and 'master' - after patch application; for topic branches the tests are run - as time permits. - - - Merge maint to master as needed: - - $ git checkout master - $ git merge maint - $ make test - - - Merge master to next as needed: - - $ git checkout next - $ git merge master - $ make test - - - Review the last issue of "What's cooking" again and see if topics - that are ready to be merged to 'next' are still in good shape - (e.g. has there any new issue identified on the list with the - series?) - - - Prepare 'jch' branch, which is used to represent somewhere - between 'master' and 'pu' and often is slightly ahead of 'next'. - - $ Meta/Reintegrate master..pu >Meta/redo-jch.sh - - The result is a script that lists topics to be merged in order to - rebuild 'pu' as the input to Meta/Reintegrate script. Remove - later topics that should not be in 'jch' yet. Add a line that - consists of '### match next' before the name of the first topic - in the output that should be in 'jch' but not in 'next' yet. - - - Now we are ready to start merging topics to 'next'. For each - branch whose tip is not merged to 'next', one of three things can - happen: - - - The commits are all next-worthy; merge the topic to next; - - The new parts are of mixed quality, but earlier ones are - next-worthy; merge the early parts to next; - - Nothing is next-worthy; do not do anything. - - This step is aided with Meta/redo-jch.sh script created earlier. - If a topic that was already in 'next' gained a patch, the script - would list it as "ai/topic~1". To include the new patch to the - updated 'next', drop the "~1" part; to keep it excluded, do not - touch the line. If a topic that was not in 'next' should be - merged to 'next', add it at the end of the list. Then: - - $ git checkout -B jch master - $ Meta/redo-jch.sh -c1 - - to rebuild the 'jch' branch from scratch. "-c1" tells the script - to stop merging at the first line that begins with '###' - (i.e. the "### match next" line you added earlier). - - At this point, build-test the result. It may reveal semantic - conflicts (e.g. a topic renamed a variable, another added a new - reference to the variable under its old name), in which case - prepare an appropriate merge-fix first (see appendix), and - rebuild the 'jch' branch from scratch, starting at the tip of - 'master'. - - Then do the same to 'next' - - $ git checkout next - $ sh Meta/redo-jch.sh -c1 -e - - The "-e" option allows the merge message that comes from the - history of the topic and the comments in the "What's cooking" to - be edited. The resulting tree should match 'jch' as the same set - of topics are merged on 'master'; otherwise there is a mismerge. - Investigate why and do not proceed until the mismerge is found - and rectified. - - $ git diff jch next - - When all is well, clean up the redo-jch.sh script with - - $ sh Meta/redo-jch.sh -u - - This removes topics listed in the script that have already been - merged to 'master'. This may lose '### match next' marker; - add it again to the appropriate place when it happens. - - - Rebuild 'pu'. - - $ Meta/Reintegrate master..pu >Meta/redo-pu.sh - - Edit the result by adding new topics that are not still in 'pu' - in the script. Then - - $ git checkout -B pu jch - $ sh Meta/redo-pu.sh - - When all is well, clean up the redo-pu.sh script with - - $ sh Meta/redo-pu.sh -u - - Double check by running - - $ git branch --no-merged pu - - to see there is no unexpected leftover topics. - - At this point, build-test the result for semantic conflicts, and - if there are, prepare an appropriate merge-fix first (see - appendix), and rebuild the 'pu' branch from scratch, starting at - the tip of 'jch'. - - - Update "What's cooking" message to review the updates to - existing topics, newly added topics and graduated topics. - - This step is helped with Meta/cook script. - - $ Meta/cook - - This script inspects the history between master..pu, finds tips - of topic branches, compares what it found with the current - contents in Meta/whats-cooking.txt, and updates that file. - Topics not listed in the file but are found in master..pu are - added to the "New topics" section, topics listed in the file that - are no longer found in master..pu are moved to the "Graduated to - master" section, and topics whose commits changed their states - (e.g. used to be only in 'pu', now merged to 'next') are updated - with change markers "<<" and ">>". - - Look for lines enclosed in "<<" and ">>"; they hold contents from - old file that are replaced by this integration round. After - verifying them, remove the old part. Review the description for - each topic and update its doneness and plan as needed. To review - the updated plan, run - - $ Meta/cook -w - - which will pick up comments given to the topics, such as "Will - merge to 'next'", etc. (see Meta/cook script to learn what kind - of phrases are supported). - - - Compile, test and install all four (five) integration branches; - Meta/Dothem script may aid this step. - - - Format documentation if the 'master' branch was updated; - Meta/dodoc.sh script may aid this step. - - - Push the integration branches out to public places; Meta/pushall - script may aid this step. - -Observations ------------- - -Some observations to be made. - - * Each topic is tested individually, and also together with other - topics cooking first in 'pu', then in 'jch' and then in 'next'. - Until it matures, no part of it is merged to 'master'. - - * A topic already in 'next' can get fixes while still in - 'next'. Such a topic will have many merges to 'next' (in - other words, "git log --first-parent next" will show many - "Merge branch 'ai/topic' to next" for the same topic. - - * An unobvious fix for 'maint' is cooked in 'next' and then - merged to 'master' to make extra sure it is Ok and then - merged to 'maint'. - - * Even when 'next' becomes empty (in other words, all topics - prove stable and are merged to 'master' and "git diff master - next" shows empty), it has tons of merge commits that will - never be in 'master'. - - * In principle, "git log --first-parent master..next" should - show nothing but merges (in practice, there are fixup commits - and reverts that are not merges). - - * Commits near the tip of a topic branch that are not in 'next' - are fair game to be discarded, replaced or rewritten. - Commits already merged to 'next' will not be. - - * Being in the 'next' branch is not a guarantee for a topic to - be included in the next feature release. Being in the - 'master' branch typically is. - - -Appendix --------- - -Preparing a "merge-fix" -~~~~~~~~~~~~~~~~~~~~~~~ - -A merge of two topics may not textually conflict but still have -conflict at the semantic level. A classic example is for one topic -to rename an variable and all its uses, while another topic adds a -new use of the variable under its old name. When these two topics -are merged together, the reference to the variable newly added by -the latter topic will still use the old name in the result. - -The Meta/Reintegrate script that is used by redo-jch and redo-pu -scripts implements a crude but usable way to work this issue around. -When the script merges branch $X, it checks if "refs/merge-fix/$X" -exists, and if so, the effect of it is squashed into the result of -the mechanical merge. In other words, - - $ echo $X | Meta/Reintegrate - -is roughly equivalent to this sequence: - - $ git merge --rerere-autoupdate $X - $ git commit - $ git cherry-pick -n refs/merge-fix/$X - $ git commit --amend - -The goal of this "prepare a merge-fix" step is to come up with a -commit that can be squashed into a result of mechanical merge to -correct semantic conflicts. - -After finding that the result of merging branch "ai/topic" to an -integration branch had such a semantic conflict, say pu~4, check the -problematic merge out on a detached HEAD, edit the working tree to -fix the semantic conflict, and make a separate commit to record the -fix-up: - - $ git checkout pu~4 - $ git show -s --pretty=%s ;# double check - Merge branch 'ai/topic' to pu - $ edit - $ git commit -m 'merge-fix/ai/topic' -a - -Then make a reference "refs/merge-fix/ai/topic" to point at this -result: - - $ git update-ref refs/merge-fix/ai/topic HEAD - -Then double check the result by asking Meta/Reintegrate to redo the -merge: - - $ git checkout pu~5 ;# the parent of the problem merge - $ echo ai/topic | Meta/Reintegrate - $ git diff pu~4 - -This time, because you prepared refs/merge-fix/ai/topic, the -resulting merge should have been tweaked to include the fix for the -semantic conflict. - -Note that this assumes that the order in which conflicting branches -are merged does not change. If the reason why merging ai/topic -branch needs this merge-fix is because another branch merged earlier -to the integration branch changed the underlying assumption ai/topic -branch made (e.g. ai/topic branch added a site to refer to a -variable, while the other branch renamed that variable and adjusted -existing use sites), and if you changed redo-jch (or redo-pu) script -to merge ai/topic branch before the other branch, then the above -merge-fix should not be applied while merging ai/topic, but should -instead be applied while merging the other branch. You would need -to move the fix to apply to the other branch, perhaps like this: - - $ mf=refs/merge-fix - $ git update-ref $mf/$the_other_branch $mf/ai/topic - $ git update-ref -d $mf/ai/topic diff --git a/third_party/git/Documentation/howto/new-command.txt b/third_party/git/Documentation/howto/new-command.txt deleted file mode 100644 index 15a4c8031f..0000000000 --- a/third_party/git/Documentation/howto/new-command.txt +++ /dev/null @@ -1,106 +0,0 @@ -From: Eric S. Raymond <esr@thyrsus.com> -Abstract: This is how-to documentation for people who want to add extension - commands to Git. It should be read alongside api-builtin.txt. -Content-type: text/asciidoc - -How to integrate new subcommands -================================ - -This is how-to documentation for people who want to add extension -commands to Git. It should be read alongside api-builtin.txt. - -Runtime environment -------------------- - -Git subcommands are standalone executables that live in the Git exec -path, normally /usr/lib/git-core. The git executable itself is a -thin wrapper that knows where the subcommands live, and runs them by -passing command-line arguments to them. - -(If "git foo" is not found in the Git exec path, the wrapper -will look in the rest of your $PATH for it. Thus, it's possible -to write local Git extensions that don't live in system space.) - -Implementation languages ------------------------- - -Most subcommands are written in C or shell. A few are written in -Perl. - -While we strongly encourage coding in portable C for portability, -these specific scripting languages are also acceptable. We won't -accept more without a very strong technical case, as we don't want -to broaden the Git suite's required dependencies. Import utilities, -surgical tools, remote helpers and other code at the edges of the -Git suite are more lenient and we allow Python (and even Tcl/tk), -but they should not be used for core functions. - -This may change in the future. Especially Python is not allowed in -core because we need better Python integration in the Git Windows -installer before we can be confident people in that environment -won't experience an unacceptably large loss of capability. - -C commands are normally written as single modules, named after the -command, that link a collection of functions called libgit. Thus, -your command 'git-foo' would normally be implemented as a single -"git-foo.c" (or "builtin/foo.c" if it is to be linked to the main -binary); this organization makes it easy for people reading the code -to find things. - -See the CodingGuidelines document for other guidance on what we consider -good practice in C and shell, and api-builtin.txt for the support -functions available to built-in commands written in C. - -What every extension command needs ----------------------------------- - -You must have a man page, written in asciidoc (this is what Git help -followed by your subcommand name will display). Be aware that there is -a local asciidoc configuration and macros which you should use. It's -often helpful to start by cloning an existing page and replacing the -text content. - -You must have a test, written to report in TAP (Test Anything Protocol). -Tests are executables (usually shell scripts) that live in the 't' -subdirectory of the tree. Each test name begins with 't' and a sequence -number that controls where in the test sequence it will be executed; -conventionally the rest of the name stem is that of the command -being tested. - -Read the file t/README to learn more about the conventions to be used -in writing tests, and the test support library. - -Integrating a command ---------------------- - -Here are the things you need to do when you want to merge a new -subcommand into the Git tree. - -1. Don't forget to sign off your patch! - -2. Append your command name to one of the variables BUILTIN_OBJS, -EXTRA_PROGRAMS, SCRIPT_SH, SCRIPT_PERL or SCRIPT_PYTHON. - -3. Drop its test in the t directory. - -4. If your command is implemented in an interpreted language with a -p-code intermediate form, make sure .gitignore in the main directory -includes a pattern entry that ignores such files. Python .pyc and -.pyo files will already be covered. - -5. If your command has any dependency on a particular version of -your language, document it in the INSTALL file. - -6. There is a file command-list.txt in the distribution main directory -that categorizes commands by type, so they can be listed in appropriate -subsections in the documentation's summary command list. Add an entry -for yours. To understand the categories, look at command-list.txt -in the main directory. If the new command is part of the typical Git -workflow and you believe it common enough to be mentioned in 'git help', -map this command to a common group in the column [common]. - -7. Give the maintainer one paragraph to include in the RelNotes file -to describe the new feature; a good place to do so is in the cover -letter [PATCH 0/n]. - -That's all there is to it. diff --git a/third_party/git/Documentation/howto/rebase-from-internal-branch.txt b/third_party/git/Documentation/howto/rebase-from-internal-branch.txt deleted file mode 100644 index 02cb5f758d..0000000000 --- a/third_party/git/Documentation/howto/rebase-from-internal-branch.txt +++ /dev/null @@ -1,164 +0,0 @@ -From: Junio C Hamano <gitster@pobox.com> -To: git@vger.kernel.org -Cc: Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org> -Subject: Re: sending changesets from the middle of a git tree -Date: Sun, 14 Aug 2005 18:37:39 -0700 -Abstract: In this article, JC talks about how he rebases the - public "pu" branch using the core Git tools when he updates - the "master" branch, and how "rebase" works. Also discussed - is how this applies to individual developers who sends patches - upstream. -Content-type: text/asciidoc - -How to rebase from an internal branch -===================================== - --------------------------------------- -Petr Baudis <pasky@suse.cz> writes: - -> Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter -> where Junio C Hamano <junkio@cox.net> told me that... ->> Linus Torvalds <torvalds@osdl.org> writes: ->> ->> > Junio, maybe you want to talk about how you move patches from your "pu" ->> > branch to the real branches. ->> -> Actually, wouldn't this be also precisely for what StGIT is intended to? --------------------------------------- - -Exactly my feeling. I was sort of waiting for Catalin to speak -up. With its basing philosophical ancestry on quilt, this is -the kind of task StGIT is designed to do. - -I just have done a simpler one, this time using only the core -Git tools. - -I had a handful of commits that were ahead of master in pu, and I -wanted to add some documentation bypassing my usual habit of -placing new things in pu first. At the beginning, the commit -ancestry graph looked like this: - - *"pu" head - master --> #1 --> #2 --> #3 - -So I started from master, made a bunch of edits, and committed: - - $ git checkout master - $ cd Documentation; ed git.txt ... - $ cd ..; git add Documentation/*.txt - $ git commit -s - -After the commit, the ancestry graph would look like this: - - *"pu" head - master^ --> #1 --> #2 --> #3 - \ - \---> master - -The old master is now master^ (the first parent of the master). -The new master commit holds my documentation updates. - -Now I have to deal with "pu" branch. - -This is the kind of situation I used to have all the time when -Linus was the maintainer and I was a contributor, when you look -at "master" branch being the "maintainer" branch, and "pu" -branch being the "contributor" branch. Your work started at the -tip of the "maintainer" branch some time ago, you made a lot of -progress in the meantime, and now the maintainer branch has some -other commits you do not have yet. And "git rebase" was written -with the explicit purpose of helping to maintain branches like -"pu". You _could_ merge master to pu and keep going, but if you -eventually want to cherrypick and merge some but not necessarily -all changes back to the master branch, it often makes later -operations for _you_ easier if you rebase (i.e. carry forward -your changes) "pu" rather than merge. So I ran "git rebase": - - $ git checkout pu - $ git rebase master pu - -What this does is to pick all the commits since the current -branch (note that I now am on "pu" branch) forked from the -master branch, and forward port these changes. - - master^ --> #1 --> #2 --> #3 - \ *"pu" head - \---> master --> #1' --> #2' --> #3' - -The diff between master^ and #1 is applied to master and -committed to create #1' commit with the commit information (log, -author and date) taken from commit #1. On top of that #2' and #3' -commits are made similarly out of #2 and #3 commits. - -Old #3 is not recorded in any of the .git/refs/heads/ file -anymore, so after doing this you will have dangling commit if -you ran fsck-cache, which is normal. After testing "pu", you -can run "git prune" to get rid of those original three commits. - -While I am talking about "git rebase", I should talk about how -to do cherrypicking using only the core Git tools. - -Let's go back to the earlier picture, with different labels. - -You, as an individual developer, cloned upstream repository and -made a couple of commits on top of it. - - *your "master" head - upstream --> #1 --> #2 --> #3 - -You would want changes #2 and #3 incorporated in the upstream, -while you feel that #1 may need further improvements. So you -prepare #2 and #3 for e-mail submission. - - $ git format-patch master^^ master - -This creates two files, 0001-XXXX.patch and 0002-XXXX.patch. Send -them out "To: " your project maintainer and "Cc: " your mailing -list. You could use contributed script git-send-email if -your host has necessary perl modules for this, but your usual -MUA would do as long as it does not corrupt whitespaces in the -patch. - -Then you would wait, and you find out that the upstream picked -up your changes, along with other changes. - - where *your "master" head - upstream --> #1 --> #2 --> #3 - used \ - to be \--> #A --> #2' --> #3' --> #B --> #C - *upstream head - -The two commits #2' and #3' in the above picture record the same -changes your e-mail submission for #2 and #3 contained, but -probably with the new sign-off line added by the upstream -maintainer and definitely with different committer and ancestry -information, they are different objects from #2 and #3 commits. - -You fetch from upstream, but not merge. - - $ git fetch upstream - -This leaves the updated upstream head in .git/FETCH_HEAD but -does not touch your .git/HEAD or .git/refs/heads/master. -You run "git rebase" now. - - $ git rebase FETCH_HEAD master - -Earlier, I said that rebase applies all the commits from your -branch on top of the upstream head. Well, I lied. "git rebase" -is a bit smarter than that and notices that #2 and #3 need not -be applied, so it only applies #1. The commit ancestry graph -becomes something like this: - - where *your old "master" head - upstream --> #1 --> #2 --> #3 - used \ your new "master" head* - to be \--> #A --> #2' --> #3' --> #B --> #C --> #1' - *upstream - head - -Again, "git prune" would discard the disused commits #1-#3 and -you continue on starting from the new "master" head, which is -the #1' commit. - --jc diff --git a/third_party/git/Documentation/howto/rebuild-from-update-hook.txt b/third_party/git/Documentation/howto/rebuild-from-update-hook.txt deleted file mode 100644 index db219f5c07..0000000000 --- a/third_party/git/Documentation/howto/rebuild-from-update-hook.txt +++ /dev/null @@ -1,90 +0,0 @@ -Subject: [HOWTO] Using post-update hook -Message-ID: <7vy86o6usx.fsf@assigned-by-dhcp.cox.net> -From: Junio C Hamano <gitster@pobox.com> -Date: Fri, 26 Aug 2005 18:19:10 -0700 -Abstract: In this how-to article, JC talks about how he - uses the post-update hook to automate Git documentation page - shown at https://www.kernel.org/pub/software/scm/git/docs/. -Content-type: text/asciidoc - -How to rebuild from update hook -=============================== - -The pages under https://www.kernel.org/pub/software/scm/git/docs/ -are built from Documentation/ directory of the git.git project -and needed to be kept up-to-date. The www.kernel.org/ servers -are mirrored and I was told that the origin of the mirror is on -the machine $some.kernel.org, on which I was given an account -when I took over Git maintainership from Linus. - -The directories relevant to this how-to are these two: - - /pub/scm/git/git.git/ The public Git repository. - /pub/software/scm/git/docs/ The HTML documentation page. - -So I made a repository to generate the documentation under my -home directory over there. - - $ cd - $ mkdir doc-git && cd doc-git - $ git clone /pub/scm/git/git.git/ docgen - -What needs to happen is to update the $HOME/doc-git/docgen/ -working tree, build HTML docs there and install the result in -/pub/software/scm/git/docs/ directory. So I wrote a little -script: - - $ cat >dododoc.sh <<\EOF - #!/bin/sh - cd $HOME/doc-git/docgen || exit - - unset GIT_DIR - - git pull /pub/scm/git/git.git/ master && - cd Documentation && - make install-webdoc - EOF - -Initially I used to run this by hand whenever I push into the -public Git repository. Then I did a cron job that ran twice a -day. The current round uses the post-update hook mechanism, -like this: - - $ cat >/pub/scm/git/git.git/hooks/post-update <<\EOF - #!/bin/sh - # - # An example hook script to prepare a packed repository for use over - # dumb transports. - # - # To enable this hook, make this file executable by "chmod +x post-update". - - case " $* " in - *' refs/heads/master '*) - echo $HOME/doc-git/dododoc.sh | at now - ;; - esac - exec git-update-server-info - EOF - $ chmod +x /pub/scm/git/git.git/hooks/post-update - -There are four things worth mentioning: - - - The update-hook is run after the repository accepts a "git - push", under my user privilege. It is given the full names - of refs that have been updated as arguments. My post-update - runs the dododoc.sh script only when the master head is - updated. - - - When update-hook is run, GIT_DIR is set to '.' by the calling - receive-pack. This is inherited by the dododoc.sh run via - the "at" command, and needs to be unset; otherwise, "git - pull" it does into $HOME/doc-git/docgen/ repository would not - work correctly. - - - The stdout of update hook script is not connected to git - push; I run the heavy part of the command inside "at", to - receive the execution report via e-mail. - - - This is still crude and does not protect against simultaneous - make invocations stomping on each other. I would need to add - some locking mechanism for this. diff --git a/third_party/git/Documentation/howto/recover-corrupted-blob-object.txt b/third_party/git/Documentation/howto/recover-corrupted-blob-object.txt deleted file mode 100644 index 1b3b188d3c..0000000000 --- a/third_party/git/Documentation/howto/recover-corrupted-blob-object.txt +++ /dev/null @@ -1,144 +0,0 @@ -Date: Fri, 9 Nov 2007 08:28:38 -0800 (PST) -From: Linus Torvalds <torvalds@linux-foundation.org> -Subject: corrupt object on git-gc -Abstract: Some tricks to reconstruct blob objects in order to fix - a corrupted repository. -Content-type: text/asciidoc - -How to recover a corrupted blob object -====================================== - ------------------------------------------------------------ -On Fri, 9 Nov 2007, Yossi Leybovich wrote: -> -> Did not help still the repository look for this object? -> Any one know how can I track this object and understand which file is it ------------------------------------------------------------ - -So exactly *because* the SHA-1 hash is cryptographically secure, the hash -itself doesn't actually tell you anything, in order to fix a corrupt -object you basically have to find the "original source" for it. - -The easiest way to do that is almost always to have backups, and find the -same object somewhere else. Backups really are a good idea, and Git makes -it pretty easy (if nothing else, just clone the repository somewhere else, -and make sure that you do *not* use a hard-linked clone, and preferably -not the same disk/machine). - -But since you don't seem to have backups right now, the good news is that -especially with a single blob being corrupt, these things *are* somewhat -debuggable. - -First off, move the corrupt object away, and *save* it. The most common -cause of corruption so far has been memory corruption, but even so, there -are people who would be interested in seeing the corruption - but it's -basically impossible to judge the corruption until we can also see the -original object, so right now the corrupt object is useless, but it's very -interesting for the future, in the hope that you can re-create a -non-corrupt version. - ------------------------------------------------------------ -So: - -> ib]$ mv .git/objects/4b/9458b3786228369c63936db65827de3cc06200 ../ ------------------------------------------------------------ - -This is the right thing to do, although it's usually best to save it under -it's full SHA-1 name (you just dropped the "4b" from the result ;). - -Let's see what that tells us: - ------------------------------------------------------------ -> ib]$ git-fsck --full -> broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8 -> to blob 4b9458b3786228369c63936db65827de3cc06200 -> missing blob 4b9458b3786228369c63936db65827de3cc06200 ------------------------------------------------------------ - -Ok, I removed the "dangling commit" messages, because they are just -messages about the fact that you probably have rebased etc, so they're not -at all interesting. But what remains is still very useful. In particular, -we now know which tree points to it! - -Now you can do - - git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8 - -which will show something like - - 100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8 .gitignore - 100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883 .mailmap - 100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c COPYING - 100644 blob ee909f2cc49e54f0799a4739d24c4cb9151ae453 CREDITS - 040000 tree 0f5f709c17ad89e72bdbbef6ea221c69807009f6 Documentation - 100644 blob 1570d248ad9237e4fa6e4d079336b9da62d9ba32 Kbuild - 100644 blob 1c7c229a092665b11cd46a25dbd40feeb31661d9 MAINTAINERS - ... - -and you should now have a line that looks like - - 10064 blob 4b9458b3786228369c63936db65827de3cc06200 my-magic-file - -in the output. This already tells you a *lot* it tells you what file the -corrupt blob came from! - -Now, it doesn't tell you quite enough, though: it doesn't tell what -*version* of the file didn't get correctly written! You might be really -lucky, and it may be the version that you already have checked out in your -working tree, in which case fixing this problem is really simple, just do - - git hash-object -w my-magic-file - -again, and if it outputs the missing SHA-1 (4b945..) you're now all done! - -But that's the really lucky case, so let's assume that it was some older -version that was broken. How do you tell which version it was? - -The easiest way to do it is to do - - git log --raw --all --full-history -- subdirectory/my-magic-file - -and that will show you the whole log for that file (please realize that -the tree you had may not be the top-level tree, so you need to figure out -which subdirectory it was in on your own), and because you're asking for -raw output, you'll now get something like - - commit abc - Author: - Date: - .. - :100644 100644 4b9458b... newsha... M somedirectory/my-magic-file - - - commit xyz - Author: - Date: - - .. - :100644 100644 oldsha... 4b9458b... M somedirectory/my-magic-file - -and this actually tells you what the *previous* and *subsequent* versions -of that file were! So now you can look at those ("oldsha" and "newsha" -respectively), and hopefully you have done commits often, and can -re-create the missing my-magic-file version by looking at those older and -newer versions! - -If you can do that, you can now recreate the missing object with - - git hash-object -w <recreated-file> - -and your repository is good again! - -(Btw, you could have ignored the fsck, and started with doing a - - git log --raw --all - -and just looked for the sha of the missing object (4b9458b..) in that -whole thing. It's up to you - Git does *have* a lot of information, it is -just missing one particular blob version. - -Trying to recreate trees and especially commits is *much* harder. So you -were lucky that it's a blob. It's quite possible that you can recreate the -thing. - - Linus diff --git a/third_party/git/Documentation/howto/recover-corrupted-object-harder.txt b/third_party/git/Documentation/howto/recover-corrupted-object-harder.txt deleted file mode 100644 index 8994e2559e..0000000000 --- a/third_party/git/Documentation/howto/recover-corrupted-object-harder.txt +++ /dev/null @@ -1,479 +0,0 @@ -Date: Wed, 16 Oct 2013 04:34:01 -0400 -From: Jeff King <peff@peff.net> -Subject: pack corruption post-mortem -Abstract: Recovering a corrupted object when no good copy is available. -Content-type: text/asciidoc - -How to recover an object from scratch -===================================== - -I was recently presented with a repository with a corrupted packfile, -and was asked if the data was recoverable. This post-mortem describes -the steps I took to investigate and fix the problem. I thought others -might find the process interesting, and it might help somebody in the -same situation. - -******************************** -Note: In this case, no good copy of the repository was available. For -the much easier case where you can get the corrupted object from -elsewhere, see link:recover-corrupted-blob-object.html[this howto]. -******************************** - -I started with an fsck, which found a problem with exactly one object -(I've used $pack and $obj below to keep the output readable, and also -because I'll refer to them later): - ------------ - $ git fsck - error: $pack SHA1 checksum mismatch - error: index CRC mismatch for object $obj from $pack at offset 51653873 - error: inflate: data stream error (incorrect data check) - error: cannot unpack $obj from $pack at offset 51653873 ------------ - -The pack checksum failing means a byte is munged somewhere, and it is -presumably in the object mentioned (since both the index checksum and -zlib were failing). - -Reading the zlib source code, I found that "incorrect data check" means -that the adler-32 checksum at the end of the zlib data did not match the -inflated data. So stepping the data through zlib would not help, as it -did not fail until the very end, when we realize the CRC does not match. -The problematic bytes could be anywhere in the object data. - -The first thing I did was pull the broken data out of the packfile. I -needed to know how big the object was, which I found out with: - ------------- - $ git show-index <$idx | cut -d' ' -f1 | sort -n | grep -A1 51653873 - 51653873 - 51664736 ------------- - -Show-index gives us the list of objects and their offsets. We throw away -everything but the offsets, and then sort them so that our interesting -offset (which we got from the fsck output above) is followed immediately -by the offset of the next object. Now we know that the object data is -10863 bytes long, and we can grab it with: - ------------- - dd if=$pack of=object bs=1 skip=51653873 count=10863 ------------- - -I inspected a hexdump of the data, looking for any obvious bogosity -(e.g., a 4K run of zeroes would be a good sign of filesystem -corruption). But everything looked pretty reasonable. - -Note that the "object" file isn't fit for feeding straight to zlib; it -has the git packed object header, which is variable-length. We want to -strip that off so we can start playing with the zlib data directly. You -can either work your way through it manually (the format is described in -link:../technical/pack-format.html[Documentation/technical/pack-format.txt]), -or you can walk through it in a debugger. I did the latter, creating a -valid pack like: - ------------- - # pack magic and version - printf 'PACK\0\0\0\2' >tmp.pack - # pack has one object - printf '\0\0\0\1' >>tmp.pack - # now add our object data - cat object >>tmp.pack - # and then append the pack trailer - /path/to/git.git/t/helper/test-tool sha1 -b <tmp.pack >trailer - cat trailer >>tmp.pack ------------- - -and then running "git index-pack tmp.pack" in the debugger (stop at -unpack_raw_entry). Doing this, I found that there were 3 bytes of header -(and the header itself had a sane type and size). So I stripped those -off with: - ------------- - dd if=object of=zlib bs=1 skip=3 ------------- - -I ran the result through zlib's inflate using a custom C program. And -while it did report the error, I did get the right number of output -bytes (i.e., it matched git's size header that we decoded above). But -feeding the result back to "git hash-object" didn't produce the same -sha1. So there were some wrong bytes, but I didn't know which. The file -happened to be C source code, so I hoped I could notice something -obviously wrong with it, but I didn't. I even got it to compile! - -I also tried comparing it to other versions of the same path in the -repository, hoping that there would be some part of the diff that didn't -make sense. Unfortunately, this happened to be the only revision of this -particular file in the repository, so I had nothing to compare against. - -So I took a different approach. Working under the guess that the -corruption was limited to a single byte, I wrote a program to munge each -byte individually, and try inflating the result. Since the object was -only 10K compressed, that worked out to about 2.5M attempts, which took -a few minutes. - -The program I used is here: - ----------------------------------------------- -#include <stdio.h> -#include <unistd.h> -#include <string.h> -#include <signal.h> -#include <zlib.h> - -static int try_zlib(unsigned char *buf, int len) -{ - /* make this absurdly large so we don't have to loop */ - static unsigned char out[1024*1024]; - z_stream z; - int ret; - - memset(&z, 0, sizeof(z)); - inflateInit(&z); - - z.next_in = buf; - z.avail_in = len; - z.next_out = out; - z.avail_out = sizeof(out); - - ret = inflate(&z, 0); - inflateEnd(&z); - return ret >= 0; -} - -/* eye candy */ -static int counter = 0; -static void progress(int sig) -{ - fprintf(stderr, "\r%d", counter); - alarm(1); -} - -int main(void) -{ - /* oversized so we can read the whole buffer in */ - unsigned char buf[1024*1024]; - int len; - unsigned i, j; - - signal(SIGALRM, progress); - alarm(1); - - len = read(0, buf, sizeof(buf)); - for (i = 0; i < len; i++) { - unsigned char c = buf[i]; - for (j = 0; j <= 0xff; j++) { - buf[i] = j; - - counter++; - if (try_zlib(buf, len)) - printf("i=%d, j=%x\n", i, j); - } - buf[i] = c; - } - - alarm(0); - fprintf(stderr, "\n"); - return 0; -} ----------------------------------------------- - -I compiled and ran with: - -------- - gcc -Wall -Werror -O3 munge.c -o munge -lz - ./munge <zlib -------- - - -There were a few false positives early on (if you write "no data" in the -zlib header, zlib thinks it's just fine :) ). But I got a hit about -halfway through: - -------- - i=5642, j=c7 -------- - -I let it run to completion, and got a few more hits at the end (where it -was munging the CRC to match our broken data). So there was a good -chance this middle hit was the source of the problem. - -I confirmed by tweaking the byte in a hex editor, zlib inflating the -result (no errors!), and then piping the output into "git hash-object", -which reported the sha1 of the broken object. Success! - -I fixed the packfile itself with: - -------- - chmod +w $pack - printf '\xc7' | dd of=$pack bs=1 seek=51659518 conv=notrunc - chmod -w $pack -------- - -The `\xc7` comes from the replacement byte our "munge" program found. -The offset 51659518 is derived by taking the original object offset -(51653873), adding the replacement offset found by "munge" (5642), and -then adding back in the 3 bytes of git header we stripped. - -After that, "git fsck" ran clean. - -As for the corruption itself, I was lucky that it was indeed a single -byte. In fact, it turned out to be a single bit. The byte 0xc7 was -corrupted to 0xc5. So presumably it was caused by faulty hardware, or a -cosmic ray. - -And the aborted attempt to look at the inflated output to see what was -wrong? I could have looked forever and never found it. Here's the diff -between what the corrupted data inflates to, versus the real data: - --------------- - - cp = strtok (arg, "+"); - + cp = strtok (arg, "."); --------------- - -It tweaked one byte and still ended up as valid, readable C that just -happened to do something totally different! One takeaway is that on a -less unlucky day, looking at the zlib output might have actually been -helpful, as most random changes would actually break the C code. - -But more importantly, git's hashing and checksumming noticed a problem -that easily could have gone undetected in another system. The result -still compiled, but would have caused an interesting bug (that would -have been blamed on some random commit). - - -The adventure continues... --------------------------- - -I ended up doing this again! Same entity, new hardware. The assumption -at this point is that the old disk corrupted the packfile, and then the -corruption was migrated to the new hardware (because it was done by -rsync or similar, and no fsck was done at the time of migration). - -This time, the affected blob was over 20 megabytes, which was far too -large to do a brute-force on. I followed the instructions above to -create the `zlib` file. I then used the `inflate` program below to pull -the corrupted data from that. Examining that output gave me a hint about -where in the file the corruption was. But now I was working with the -file itself, not the zlib contents. So knowing the sha1 of the object -and the approximate area of the corruption, I used the `sha1-munge` -program below to brute-force the correct byte. - -Here's the inflate program (it's essentially `gunzip` but without the -`.gz` header processing): - --------------------------- -#include <stdio.h> -#include <string.h> -#include <zlib.h> -#include <stdlib.h> - -int main(int argc, char **argv) -{ - /* - * oversized so we can read the whole buffer in; - * this could actually be switched to streaming - * to avoid any memory limitations - */ - static unsigned char buf[25 * 1024 * 1024]; - static unsigned char out[25 * 1024 * 1024]; - int len; - z_stream z; - int ret; - - len = read(0, buf, sizeof(buf)); - memset(&z, 0, sizeof(z)); - inflateInit(&z); - - z.next_in = buf; - z.avail_in = len; - z.next_out = out; - z.avail_out = sizeof(out); - - ret = inflate(&z, 0); - if (ret != Z_OK && ret != Z_STREAM_END) - fprintf(stderr, "initial inflate failed (%d)\n", ret); - - fprintf(stderr, "outputting %lu bytes", z.total_out); - fwrite(out, 1, z.total_out, stdout); - return 0; -} --------------------------- - -And here is the `sha1-munge` program: - --------------------------- -#include <stdio.h> -#include <unistd.h> -#include <string.h> -#include <signal.h> -#include <openssl/sha.h> -#include <stdlib.h> - -/* eye candy */ -static int counter = 0; -static void progress(int sig) -{ - fprintf(stderr, "\r%d", counter); - alarm(1); -} - -static const signed char hexval_table[256] = { - -1, -1, -1, -1, -1, -1, -1, -1, /* 00-07 */ - -1, -1, -1, -1, -1, -1, -1, -1, /* 08-0f */ - -1, -1, -1, -1, -1, -1, -1, -1, /* 10-17 */ - -1, -1, -1, -1, -1, -1, -1, -1, /* 18-1f */ - -1, -1, -1, -1, -1, -1, -1, -1, /* 20-27 */ - -1, -1, -1, -1, -1, -1, -1, -1, /* 28-2f */ - 0, 1, 2, 3, 4, 5, 6, 7, /* 30-37 */ - 8, 9, -1, -1, -1, -1, -1, -1, /* 38-3f */ - -1, 10, 11, 12, 13, 14, 15, -1, /* 40-47 */ - -1, -1, -1, -1, -1, -1, -1, -1, /* 48-4f */ - -1, -1, -1, -1, -1, -1, -1, -1, /* 50-57 */ - -1, -1, -1, -1, -1, -1, -1, -1, /* 58-5f */ - -1, 10, 11, 12, 13, 14, 15, -1, /* 60-67 */ - -1, -1, -1, -1, -1, -1, -1, -1, /* 68-67 */ - -1, -1, -1, -1, -1, -1, -1, -1, /* 70-77 */ - -1, -1, -1, -1, -1, -1, -1, -1, /* 78-7f */ - -1, -1, -1, -1, -1, -1, -1, -1, /* 80-87 */ - -1, -1, -1, -1, -1, -1, -1, -1, /* 88-8f */ - -1, -1, -1, -1, -1, -1, -1, -1, /* 90-97 */ - -1, -1, -1, -1, -1, -1, -1, -1, /* 98-9f */ - -1, -1, -1, -1, -1, -1, -1, -1, /* a0-a7 */ - -1, -1, -1, -1, -1, -1, -1, -1, /* a8-af */ - -1, -1, -1, -1, -1, -1, -1, -1, /* b0-b7 */ - -1, -1, -1, -1, -1, -1, -1, -1, /* b8-bf */ - -1, -1, -1, -1, -1, -1, -1, -1, /* c0-c7 */ - -1, -1, -1, -1, -1, -1, -1, -1, /* c8-cf */ - -1, -1, -1, -1, -1, -1, -1, -1, /* d0-d7 */ - -1, -1, -1, -1, -1, -1, -1, -1, /* d8-df */ - -1, -1, -1, -1, -1, -1, -1, -1, /* e0-e7 */ - -1, -1, -1, -1, -1, -1, -1, -1, /* e8-ef */ - -1, -1, -1, -1, -1, -1, -1, -1, /* f0-f7 */ - -1, -1, -1, -1, -1, -1, -1, -1, /* f8-ff */ -}; - -static inline unsigned int hexval(unsigned char c) -{ -return hexval_table[c]; -} - -static int get_sha1_hex(const char *hex, unsigned char *sha1) -{ - int i; - for (i = 0; i < 20; i++) { - unsigned int val; - /* - * hex[1]=='\0' is caught when val is checked below, - * but if hex[0] is NUL we have to avoid reading - * past the end of the string: - */ - if (!hex[0]) - return -1; - val = (hexval(hex[0]) << 4) | hexval(hex[1]); - if (val & ~0xff) - return -1; - *sha1++ = val; - hex += 2; - } - return 0; -} - -int main(int argc, char **argv) -{ - /* oversized so we can read the whole buffer in */ - static unsigned char buf[25 * 1024 * 1024]; - char header[32]; - int header_len; - unsigned char have[20], want[20]; - int start, len; - SHA_CTX orig; - unsigned i, j; - - if (!argv[1] || get_sha1_hex(argv[1], want)) { - fprintf(stderr, "usage: sha1-munge <sha1> [start] <file.in\n"); - return 1; - } - - if (argv[2]) - start = atoi(argv[2]); - else - start = 0; - - len = read(0, buf, sizeof(buf)); - header_len = sprintf(header, "blob %d", len) + 1; - fprintf(stderr, "using header: %s\n", header); - - /* - * We keep a running sha1 so that if you are munging - * near the end of the file, we do not have to re-sha1 - * the unchanged earlier bytes - */ - SHA1_Init(&orig); - SHA1_Update(&orig, header, header_len); - if (start) - SHA1_Update(&orig, buf, start); - - signal(SIGALRM, progress); - alarm(1); - - for (i = start; i < len; i++) { - unsigned char c; - SHA_CTX x; - -#if 0 - /* - * deletion -- this would not actually work in practice, - * I think, because we've already committed to a - * particular size in the header. Ditto for addition - * below. In those cases, you'd have to do the whole - * sha1 from scratch, or possibly keep three running - * "orig" sha1 computations going. - */ - memcpy(&x, &orig, sizeof(x)); - SHA1_Update(&x, buf + i + 1, len - i - 1); - SHA1_Final(have, &x); - if (!memcmp(have, want, 20)) - printf("i=%d, deletion\n", i); -#endif - - /* - * replacement -- note that this tries each of the 256 - * possible bytes. If you suspect a single-bit flip, - * it would be much shorter to just try the 8 - * bit-flipped variants. - */ - c = buf[i]; - for (j = 0; j <= 0xff; j++) { - buf[i] = j; - - memcpy(&x, &orig, sizeof(x)); - SHA1_Update(&x, buf + i, len - i); - SHA1_Final(have, &x); - if (!memcmp(have, want, 20)) - printf("i=%d, j=%02x\n", i, j); - } - buf[i] = c; - -#if 0 - /* addition */ - for (j = 0; j <= 0xff; j++) { - unsigned char extra = j; - memcpy(&x, &orig, sizeof(x)); - SHA1_Update(&x, &extra, 1); - SHA1_Update(&x, buf + i, len - i); - SHA1_Final(have, &x); - if (!memcmp(have, want, 20)) - printf("i=%d, addition=%02x", i, j); - } -#endif - - SHA1_Update(&orig, buf + i, 1); - counter++; - } - - alarm(0); - fprintf(stderr, "\r%d\n", counter); - return 0; -} --------------------------- diff --git a/third_party/git/Documentation/howto/revert-a-faulty-merge.txt b/third_party/git/Documentation/howto/revert-a-faulty-merge.txt deleted file mode 100644 index 19f59cc888..0000000000 --- a/third_party/git/Documentation/howto/revert-a-faulty-merge.txt +++ /dev/null @@ -1,273 +0,0 @@ -Date: Fri, 19 Dec 2008 00:45:19 -0800 -From: Linus Torvalds <torvalds@linux-foundation.org>, Junio C Hamano <gitster@pobox.com> -Subject: Re: Odd merge behaviour involving reverts -Abstract: Sometimes a branch that was already merged to the mainline - is later found to be faulty. Linus and Junio give guidance on - recovering from such a premature merge and continuing development - after the offending branch is fixed. -Message-ID: <7vocz8a6zk.fsf@gitster.siamese.dyndns.org> -References: <alpine.LFD.2.00.0812181949450.14014@localhost.localdomain> -Content-type: text/asciidoc - -How to revert a faulty merge -============================ - -Alan <alan@clueserver.org> said: - - I have a master branch. We have a branch off of that that some - developers are doing work on. They claim it is ready. We merge it - into the master branch. It breaks something so we revert the merge. - They make changes to the code. they get it to a point where they say - it is ok and we merge again. - - When examined, we find that code changes made before the revert are - not in the master branch, but code changes after are in the master - branch. - -and asked for help recovering from this situation. - -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 -merge that brings these premature changes into the mainline, x are changes -unrelated to what the side branch did and already made on the mainline, -and W is the "revert of the merge M" (doesn't W look M upside down?). -IOW, `"diff W^..W"` is similar to `"diff -R M^..M"`. - -Such a "revert" of a merge can be made with: - - $ git revert -m 1 M - -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 -have some other changes on the mainline after W. - -If you merge the updated side branch (with D at its tip), none of the -changes made in A or B will be in the result, because they were reverted -by W. That is what Alan saw. - -Linus explains the situation: - - Reverting a regular commit just effectively undoes what that commit - did, and is fairly straightforward. But reverting a merge commit also - undoes the _data_ that the commit changed, but it does absolutely - nothing to the effects on _history_ that the merge had. - - So the merge will still exist, and it will still be seen as joining - the two branches together, and future merges will see that merge as - the last shared state - and the revert that reverted the merge brought - in will not affect that at all. - - So a "revert" undoes the data changes, but it's very much _not_ an - "undo" in the sense that it doesn't undo the effects of a commit on - the repository history. - - So if you think of "revert" as "undo", then you're going to always - miss this part of reverts. Yes, it undoes the data, but no, it doesn't - undo history. - -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 -with: - - $ git revert W - -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 -done by any of the x, but that is just a normal merge conflict. - -On the other hand, if the developers of the side branch discarded their -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 -also be a further fix-up C' on the side branch. `"diff Y^..Y"` is similar -to `"diff -R W^..W"` (which in turn means it is similar to `"diff M^..M"`), -and `"diff A'^..C'"` by definition would be similar but different from that, -because it is a rerolled series of the earlier change. There will be a -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 -base of the updated branch and the tip of the mainline, and they should -merge without the past faulty merge and its revert getting in the way. - -To recap, these are two very different scenarios, and they want two very -different resolution strategies: - - - If the faulty side branch was fixed by adding corrections on top, then - doing a revert of the previous revert would be the right thing to do. - - - If the faulty side branch whose effects were discarded by an earlier - revert of a merge was rebuilt from scratch (i.e. rebasing and fixing, - as you seem to have interpreted), then re-merging the result without - doing anything else fancy would be the right thing to do. - (See the ADDENDUM below for how to rebuild a branch from scratch - without changing its original branching-off point.) - -However, there are things to keep in mind when reverting a merge (and -reverting such a revert). - -For example, think about what reverting a merge (and then reverting the -revert) does to bisectability. Ignore the fact that the revert of a revert -is undoing it - just think of it as a "single commit that does a lot". -Because that is what it does. - -When you have a problem you are chasing down, and you hit a "revert this -merge", what you're hitting is essentially a single commit that contains -all the changes (but obviously in reverse) of all the commits that got -merged. So it's debugging hell, because now you don't have lots of small -changes that you can try to pinpoint which _part_ of it changes. - -But does it all work? Sure it does. You can revert a merge, and from a -purely technical angle, Git did it very naturally and had no real -troubles. It just considered it a change from "state before merge" to -"state after merge", and that was it. Nothing complicated, nothing odd, -nothing really dangerous. Git will do it without even thinking about it. - -So from a technical angle, there's nothing wrong with reverting a merge, -but from a workflow angle it's something that you generally should try to -avoid. - -If at all possible, for example, if you find a problem that got merged -into the main tree, rather than revert the merge, try _really_ hard to -bisect the problem down into the branch you merged, and just fix it, or -try to revert the individual commit that caused it. - -Yes, it's more complex, and no, it's not always going to work (sometimes -the answer is: "oops, I really shouldn't have merged it, because it wasn't -ready yet, and I really need to undo _all_ of the merge"). So then you -really should revert the merge, but when you want to re-do the merge, you -now need to do it by reverting the revert. - -ADDENDUM - -Sometimes you have to rewrite one of a topic branch's commits *and* you can't -change the topic's branching-off point. Consider the following situation: - - P---o---o---M---x---x---W---x - \ / - A---B---C - -where commit W reverted commit M because it turned out that commit B was wrong -and needs to be rewritten, but you need the rewritten topic to still branch -from commit P (perhaps P is a branching-off point for yet another branch, and -you want be able to merge the topic into both branches). - -The natural thing to do in this case is to checkout the A-B-C branch and use -"rebase -i P" to change commit B. However this does not rewrite commit A, -because "rebase -i" by default fast-forwards over any initial commits selected -with the "pick" command. So you end up with this: - - P---o---o---M---x---x---W---x - \ / - A---B---C <-- old branch - \ - B'---C' <-- naively rewritten branch - -To merge A-B'-C' into the mainline branch you would still have to first revert -commit W in order to pick up the changes in A, but then it's likely that the -changes in B' will conflict with the original B changes re-introduced by the -reversion of W. - -However, you can avoid these problems if you recreate the entire branch, -including commit A: - - A'---B'---C' <-- completely rewritten branch - / - P---o---o---M---x---x---W---x - \ / - A---B---C - -You can merge A'-B'-C' into the mainline branch without worrying about first -reverting W. Mainline's history would look like this: - - A'---B'---C'------------------ - / \ - P---o---o---M---x---x---W---x---M2 - \ / - A---B---C - -But if you don't actually need to change commit A, then you need some way to -recreate it as a new commit with the same changes in it. The rebase command's ---no-ff option provides a way to do this: - - $ git rebase [-i] --no-ff P - -The --no-ff option creates a new branch A'-B'-C' with all-new commits (all the -SHA IDs will be different) even if in the interactive case you only actually -modify commit B. You can then merge this new branch directly into the mainline -branch and be sure you'll get all of the branch's changes. - -You can also use --no-ff in cases where you just add extra commits to the topic -to fix it up. Let's revisit the situation discussed at the start of this howto: - - P---o---o---M---x---x---W---x - \ / - A---B---C----------------D---E <-- fixed-up topic branch - -At this point, you can use --no-ff to recreate the topic branch: - - $ git checkout E - $ git rebase --no-ff P - -yielding - - A'---B'---C'------------D'---E' <-- recreated topic branch - / - P---o---o---M---x---x---W---x - \ / - A---B---C----------------D---E - -You can merge the recreated branch into the mainline without reverting commit W, -and mainline's history will look like this: - - A'---B'---C'------------D'---E' - / \ - P---o---o---M---x---x---W---x---M2 - \ / - A---B---C diff --git a/third_party/git/Documentation/howto/revert-branch-rebase.txt b/third_party/git/Documentation/howto/revert-branch-rebase.txt deleted file mode 100644 index 149508e13b..0000000000 --- a/third_party/git/Documentation/howto/revert-branch-rebase.txt +++ /dev/null @@ -1,187 +0,0 @@ -From: Junio C Hamano <gitster@pobox.com> -To: git@vger.kernel.org -Subject: [HOWTO] Reverting an existing commit -Abstract: In this article, JC gives a small real-life example of using - 'git revert' command, and using a temporary branch and tag for safety - and easier sanity checking. -Date: Mon, 29 Aug 2005 21:39:02 -0700 -Content-type: text/asciidoc -Message-ID: <7voe7g3uop.fsf@assigned-by-dhcp.cox.net> - -How to revert an existing commit -================================ - -One of the changes I pulled into the 'master' branch turns out to -break building Git with GCC 2.95. While they were well-intentioned -portability fixes, keeping things working with gcc-2.95 was also -important. Here is what I did to revert the change in the 'master' -branch and to adjust the 'pu' branch, using core Git tools and -barebone Porcelain. - -First, prepare a throw-away branch in case I screw things up. - ------------------------------------------------- -$ git checkout -b revert-c99 master ------------------------------------------------- - -Now I am on the 'revert-c99' branch. Let's figure out which commit to -revert. I happen to know that the top of the 'master' branch is a -merge, and its second parent (i.e. foreign commit I merged from) has -the change I would want to undo. Further I happen to know that that -merge introduced 5 commits or so: - ------------------------------------------------- -$ git show-branch --more=4 master master^2 | head -* [master] Merge refs/heads/portable from http://www.cs.berkeley.... - ! [master^2] Replace C99 array initializers with code. --- -- [master] Merge refs/heads/portable from http://www.cs.berkeley.... -*+ [master^2] Replace C99 array initializers with code. -*+ [master^2~1] Replace unsetenv() and setenv() with older putenv(). -*+ [master^2~2] Include sys/time.h in daemon.c. -*+ [master^2~3] Fix ?: statements. -*+ [master^2~4] Replace zero-length array decls with []. -* [master~1] tutorial note about git branch ------------------------------------------------- - -The '--more=4' above means "after we reach the merge base of refs, -show until we display four more common commits". That last commit -would have been where the "portable" branch was forked from the main -git.git repository, so this would show everything on both branches -since then. I just limited the output to the first handful using -'head'. - -Now I know 'master^2~4' (pronounce it as "find the second parent of -the 'master', and then go four generations back following the first -parent") is the one I would want to revert. Since I also want to say -why I am reverting it, the '-n' flag is given to 'git revert'. This -prevents it from actually making a commit, and instead 'git revert' -leaves the commit log message it wanted to use in '.msg' file: - ------------------------------------------------- -$ git revert -n master^2~4 -$ cat .msg -Revert "Replace zero-length array decls with []." - -This reverts 6c5f9baa3bc0d63e141e0afc23110205379905a4 commit. -$ git diff HEAD ;# to make sure what we are reverting makes sense. -$ make CC=gcc-2.95 clean test ;# make sure it fixed the breakage. -$ make clean test ;# make sure it did not cause other breakage. ------------------------------------------------- - -The reverted change makes sense (from reading the 'diff' output), does -fix the problem (from 'make CC=gcc-2.95' test), and does not cause new -breakage (from the last 'make test'). I'm ready to commit: - ------------------------------------------------- -$ git commit -a -s ;# read .msg into the log, - # and explain why I am reverting. ------------------------------------------------- - -I could have screwed up in any of the above steps, but in the worst -case I could just have done 'git checkout master' to start over. -Fortunately I did not have to; what I have in the current branch -'revert-c99' is what I want. So merge that back into 'master': - ------------------------------------------------- -$ git checkout master -$ git merge revert-c99 ;# this should be a fast-forward -Updating from 10d781b9caa4f71495c7b34963bef137216f86a8 to e3a693c... - cache.h | 8 ++++---- - commit.c | 2 +- - ls-files.c | 2 +- - receive-pack.c | 2 +- - server-info.c | 2 +- - 5 files changed, 8 insertions(+), 8 deletions(-) ------------------------------------------------- - -There is no need to redo the test at this point. We fast-forwarded -and we know 'master' matches 'revert-c99' exactly. In fact: - ------------------------------------------------- -$ git diff master..revert-c99 ------------------------------------------------- - -says nothing. - -Then we rebase the 'pu' branch as usual. - ------------------------------------------------- -$ git checkout pu -$ git tag pu-anchor pu -$ git rebase master -* Applying: Redo "revert" using three-way merge machinery. -First trying simple merge strategy to cherry-pick. -* Applying: Remove git-apply-patch-script. -First trying simple merge strategy to cherry-pick. -Simple cherry-pick fails; trying Automatic cherry-pick. -Removing Documentation/git-apply-patch-script.txt -Removing git-apply-patch-script -* Applying: Document "git cherry-pick" and "git revert" -First trying simple merge strategy to cherry-pick. -* Applying: mailinfo and applymbox updates -First trying simple merge strategy to cherry-pick. -* Applying: Show commits in topo order and name all commits. -First trying simple merge strategy to cherry-pick. -* Applying: More documentation updates. -First trying simple merge strategy to cherry-pick. ------------------------------------------------- - -The temporary tag 'pu-anchor' is me just being careful, in case 'git -rebase' screws up. After this, I can do these for sanity check: - ------------------------------------------------- -$ git diff pu-anchor..pu ;# make sure we got the master fix. -$ make CC=gcc-2.95 clean test ;# make sure it fixed the breakage. -$ make clean test ;# make sure it did not cause other breakage. ------------------------------------------------- - -Everything is in the good order. I do not need the temporary branch -or tag anymore, so remove them: - ------------------------------------------------- -$ rm -f .git/refs/tags/pu-anchor -$ git branch -d revert-c99 ------------------------------------------------- - -It was an emergency fix, so we might as well merge it into the -'release candidate' branch, although I expect the next release would -be some days off: - ------------------------------------------------- -$ git checkout rc -$ git pull . master -Packing 0 objects -Unpacking 0 objects - -* commit-ish: e3a693c... refs/heads/master from . -Trying to merge e3a693c... into 8c1f5f0... using 10d781b... -Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f - cache.h | 8 ++++---- - commit.c | 2 +- - ls-files.c | 2 +- - receive-pack.c | 2 +- - server-info.c | 2 +- - 5 files changed, 8 insertions(+), 8 deletions(-) ------------------------------------------------- - -And the final repository status looks like this: - ------------------------------------------------- -$ git show-branch --more=1 master pu rc -! [master] Revert "Replace zero-length array decls with []." - ! [pu] git-repack: Add option to repack all objects. - * [rc] Merge refs/heads/master from . ---- - + [pu] git-repack: Add option to repack all objects. - + [pu~1] More documentation updates. - + [pu~2] Show commits in topo order and name all commits. - + [pu~3] mailinfo and applymbox updates - + [pu~4] Document "git cherry-pick" and "git revert" - + [pu~5] Remove git-apply-patch-script. - + [pu~6] Redo "revert" using three-way merge machinery. - - [rc] Merge refs/heads/master from . -++* [master] Revert "Replace zero-length array decls with []." - - [rc~1] Merge refs/heads/master from . -... [master~1] Merge refs/heads/portable from http://www.cs.berkeley.... ------------------------------------------------- diff --git a/third_party/git/Documentation/howto/separating-topic-branches.txt b/third_party/git/Documentation/howto/separating-topic-branches.txt deleted file mode 100644 index bd1027433b..0000000000 --- a/third_party/git/Documentation/howto/separating-topic-branches.txt +++ /dev/null @@ -1,94 +0,0 @@ -From: Junio C Hamano <gitster@pobox.com> -Subject: Separating topic branches -Abstract: In this article, JC describes how to separate topic branches. -Content-type: text/asciidoc - -How to separate topic branches -============================== - -This text was originally a footnote to a discussion about the -behaviour of the git diff commands. - -Often I find myself doing that [running diff against something other -than HEAD] while rewriting messy development history. For example, I -start doing some work without knowing exactly where it leads, and end -up with a history like this: - - "master" - o---o - \ "topic" - o---o---o---o---o---o - -At this point, "topic" contains something I know I want, but it -contains two concepts that turned out to be completely independent. -And often, one topic component is larger than the other. It may -contain more than two topics. - -In order to rewrite this mess to be more manageable, I would first do -"diff master..topic", to extract the changes into a single patch, start -picking pieces from it to get logically self-contained units, and -start building on top of "master": - - $ git diff master..topic >P.diff - $ git checkout -b topicA master - ... pick and apply pieces from P.diff to build - ... commits on topicA branch. - - o---o---o - / "topicA" - o---o"master" - \ "topic" - o---o---o---o---o---o - -Before doing each commit on "topicA" HEAD, I run "diff HEAD" -before update-index the affected paths, or "diff --cached HEAD" -after. Also I would run "diff --cached master" to make sure -that the changes are only the ones related to "topicA". Usually -I do this for smaller topics first. - -After that, I'd do the remainder of the original "topic", but -for that, I do not start from the patchfile I extracted by -comparing "master" and "topic" I used initially. Still on -"topicA", I extract "diff topic", and use it to rebuild the -other topic: - - $ git diff -R topic >P.diff ;# --cached also would work fine - $ git checkout -b topicB master - ... pick and apply pieces from P.diff to build - ... commits on topicB branch. - - "topicB" - o---o---o---o---o - / - /o---o---o - |/ "topicA" - o---o"master" - \ "topic" - o---o---o---o---o---o - -After I am done, I'd try a pretend-merge between "topicA" and -"topicB" in order to make sure I have not missed anything: - - $ git pull . topicA ;# merge it into current "topicB" - $ git diff topic - "topicB" - o---o---o---o---o---* (pretend merge) - / / - /o---o---o----------' - |/ "topicA" - o---o"master" - \ "topic" - o---o---o---o---o---o - -The last diff better not to show anything other than cleanups -for crufts. Then I can finally clean things up: - - $ git branch -D topic - $ git reset --hard HEAD^ ;# nuke pretend merge - - "topicB" - o---o---o---o---o - / - /o---o---o - |/ "topicA" - o---o"master" diff --git a/third_party/git/Documentation/howto/setup-git-server-over-http.txt b/third_party/git/Documentation/howto/setup-git-server-over-http.txt deleted file mode 100644 index bfe6f9b500..0000000000 --- a/third_party/git/Documentation/howto/setup-git-server-over-http.txt +++ /dev/null @@ -1,285 +0,0 @@ -From: Rutger Nijlunsing <rutger@nospam.com> -Subject: Setting up a Git repository which can be pushed into and pulled from over HTTP(S). -Date: Thu, 10 Aug 2006 22:00:26 +0200 -Content-type: text/asciidoc - -How to setup Git server over http -================================= - -NOTE: This document is from 2006. A lot has happened since then, and this -document is now relevant mainly if your web host is not CGI capable. -Almost everyone else should instead look at linkgit:git-http-backend[1]. - -Since Apache is one of those packages people like to compile -themselves while others prefer the bureaucrat's dream Debian, it is -impossible to give guidelines which will work for everyone. Just send -some feedback to the mailing list at git@vger.kernel.org to get this -document tailored to your favorite distro. - - -What's needed: - -- Have an Apache web-server - - On Debian: - $ apt-get install apache2 - To get apache2 by default started, - edit /etc/default/apache2 and set NO_START=0 - -- can edit the configuration of it. - - This could be found under /etc/httpd, or refer to your Apache documentation. - - On Debian: this means being able to edit files under /etc/apache2 - -- can restart it. - - 'apachectl --graceful' might do. If it doesn't, just stop and - restart apache. Be warning that active connections to your server - might be aborted by this. - - On Debian: - $ /etc/init.d/apache2 restart - or - $ /etc/init.d/apache2 force-reload - (which seems to do the same) - This adds symlinks from the /etc/apache2/mods-enabled to - /etc/apache2/mods-available. - -- have permissions to chown a directory - -- have Git installed on the client, and - -- either have Git installed on the server or have a webdav client on - the client. - -In effect, this means you're going to be root, or that you're using a -preconfigured WebDAV server. - - -Step 1: setup a bare Git repository ------------------------------------ - -At the time of writing, git-http-push cannot remotely create a Git -repository. So we have to do that at the server side with Git. Another -option is to generate an empty bare repository at the client and copy -it to the server with a WebDAV client (which is the only option if Git -is not installed on the server). - -Create the directory under the DocumentRoot of the directories served -by Apache. As an example we take /usr/local/apache2, but try "grep -DocumentRoot /where/ever/httpd.conf" to find your root: - - $ cd /usr/local/apache/htdocs - $ mkdir my-new-repo.git - - On Debian: - - $ cd /var/www - $ mkdir my-new-repo.git - - -Initialize a bare repository - - $ cd my-new-repo.git - $ git --bare init - - -Change the ownership to your web-server's credentials. Use `"grep ^User -httpd.conf"` and `"grep ^Group httpd.conf"` to find out: - - $ chown -R www.www . - - On Debian: - - $ chown -R www-data.www-data . - - -If you do not know which user Apache runs as, you can alternatively do -a "chmod -R a+w .", inspect the files which are created later on, and -set the permissions appropriately. - -Restart apache2, and check whether http://server/my-new-repo.git gives -a directory listing. If not, check whether apache started up -successfully. - - -Step 2: enable DAV on this repository -------------------------------------- - -First make sure the dav_module is loaded. For this, insert in httpd.conf: - - LoadModule dav_module libexec/httpd/libdav.so - AddModule mod_dav.c - -Also make sure that this line exists which is the file used for -locking DAV operations: - - DAVLockDB "/usr/local/apache2/temp/DAV.lock" - - On Debian these steps can be performed with: - - Enable the dav and dav_fs modules of apache: - $ a2enmod dav_fs - (just to be sure. dav_fs might be unneeded, I don't know) - $ a2enmod dav - The DAV lock is located in /etc/apache2/mods-available/dav_fs.conf: - DAVLockDB /var/lock/apache2/DAVLock - -Of course, it can point somewhere else, but the string is actually just a -prefix in some Apache configurations, and therefore the _directory_ has to -be writable by the user Apache runs as. - -Then, add something like this to your httpd.conf - - <Location /my-new-repo.git> - DAV on - AuthType Basic - AuthName "Git" - AuthUserFile /usr/local/apache2/conf/passwd.git - Require valid-user - </Location> - - On Debian: - Create (or add to) /etc/apache2/conf.d/git.conf : - - <Location /my-new-repo.git> - DAV on - AuthType Basic - AuthName "Git" - AuthUserFile /etc/apache2/passwd.git - Require valid-user - </Location> - - Debian automatically reads all files under /etc/apache2/conf.d. - -The password file can be somewhere else, but it has to be readable by -Apache and preferably not readable by the world. - -Create this file by - $ htpasswd -c /usr/local/apache2/conf/passwd.git <user> - - On Debian: - $ htpasswd -c /etc/apache2/passwd.git <user> - -You will be asked a password, and the file is created. Subsequent calls -to htpasswd should omit the '-c' option, since you want to append to the -existing file. - -You need to restart Apache. - -Now go to http://<username>@<servername>/my-new-repo.git in your -browser to check whether it asks for a password and accepts the right -password. - -On Debian: - - To test the WebDAV part, do: - - $ apt-get install litmus - $ litmus http://<servername>/my-new-repo.git <username> <password> - - Most tests should pass. - -A command-line tool to test WebDAV is cadaver. If you prefer GUIs, for -example, konqueror can open WebDAV URLs as "webdav://..." or -"webdavs://...". - -If you're into Windows, from XP onwards Internet Explorer supports -WebDAV. For this, do Internet Explorer -> Open Location -> -http://<servername>/my-new-repo.git [x] Open as webfolder -> login . - - -Step 3: setup the client ------------------------- - -Make sure that you have HTTP support, i.e. your Git was built with -libcurl (version more recent than 7.10). The command 'git http-push' with -no argument should display a usage message. - -Then, add the following to your $HOME/.netrc (you can do without, but will be -asked to input your password a _lot_ of times): - - machine <servername> - login <username> - password <password> - -...and set permissions: - chmod 600 ~/.netrc - -If you want to access the web-server by its IP, you have to type that in, -instead of the server name. - -To check whether all is OK, do: - - curl --netrc --location -v http://<username>@<servername>/my-new-repo.git/HEAD - -...this should give something like 'ref: refs/heads/master', which is -the content of the file HEAD on the server. - -Now, add the remote in your existing repository which contains the project -you want to export: - - $ git-config remote.upload.url \ - http://<username>@<servername>/my-new-repo.git/ - -It is important to put the last '/'; Without it, the server will send -a redirect which git-http-push does not (yet) understand, and git-http-push -will repeat the request infinitely. - - -Step 4: make the initial push ------------------------------ - -From your client repository, do - - $ git push upload master - -This pushes branch 'master' (which is assumed to be the branch you -want to export) to repository called 'upload', which we previously -defined with git-config. - - -Using a proxy: --------------- - -If you have to access the WebDAV server from behind an HTTP(S) proxy, -set the variable 'all_proxy' to `http://proxy-host.com:port`, or -`http://login-on-proxy:passwd-on-proxy@proxy-host.com:port`. See 'man -curl' for details. - - -Troubleshooting: ----------------- - -If git-http-push says - - Error: no DAV locking support on remote repo http://... - -then it means the web-server did not accept your authentication. Make sure -that the user name and password matches in httpd.conf, .netrc and the URL -you are uploading to. - -If git-http-push shows you an error (22/502) when trying to MOVE a blob, -it means that your web-server somehow does not recognize its name in the -request; This can happen when you start Apache, but then disable the -network interface. A simple restart of Apache helps. - -Errors like (22/502) are of format (curl error code/http error -code). So (22/404) means something like 'not found' at the server. - -Reading /usr/local/apache2/logs/error_log is often helpful. - - On Debian: Read /var/log/apache2/error.log instead. - -If you access HTTPS locations, Git may fail verifying the SSL -certificate (this is return code 60). Setting http.sslVerify=false can -help diagnosing the problem, but removes security checks. - - -Debian References: http://www.debian-administration.org/articles/285 - -Authors - Johannes Schindelin <Johannes.Schindelin@gmx.de> - Rutger Nijlunsing <git@wingding.demon.nl> - Matthieu Moy <Matthieu.Moy@imag.fr> diff --git a/third_party/git/Documentation/howto/update-hook-example.txt b/third_party/git/Documentation/howto/update-hook-example.txt deleted file mode 100644 index 89821ec74f..0000000000 --- a/third_party/git/Documentation/howto/update-hook-example.txt +++ /dev/null @@ -1,192 +0,0 @@ -From: Junio C Hamano <gitster@pobox.com> and Carl Baldwin <cnb@fc.hp.com> -Subject: control access to branches. -Date: Thu, 17 Nov 2005 23:55:32 -0800 -Message-ID: <7vfypumlu3.fsf@assigned-by-dhcp.cox.net> -Abstract: An example hooks/update script is presented to - implement repository maintenance policies, such as who can push - into which branch and who can make a tag. -Content-type: text/asciidoc - -How to use the update hook -========================== - -When your developer runs git-push into the repository, -git-receive-pack is run (either locally or over ssh) as that -developer, so is hooks/update script. Quoting from the relevant -section of the documentation: - - Before each ref is updated, if $GIT_DIR/hooks/update file exists - and executable, it is called with three parameters: - - $GIT_DIR/hooks/update refname sha1-old sha1-new - - The refname parameter is relative to $GIT_DIR; e.g. for the - master head this is "refs/heads/master". Two sha1 are the - object names for the refname before and after the update. Note - that the hook is called before the refname is updated, so either - sha1-old is 0{40} (meaning there is no such ref yet), or it - should match what is recorded in refname. - -So if your policy is (1) always require fast-forward push -(i.e. never allow "git-push repo +branch:branch"), (2) you -have a list of users allowed to update each branch, and (3) you -do not let tags to be overwritten, then you can use something -like this as your hooks/update script. - -[jc: editorial note. This is a much improved version by Carl -since I posted the original outline] - ----------------------------------------------------- -#!/bin/bash - -umask 002 - -# If you are having trouble with this access control hook script -# you can try setting this to true. It will tell you exactly -# why a user is being allowed/denied access. - -verbose=false - -# Default shell globbing messes things up downstream -GLOBIGNORE=* - -function grant { - $verbose && echo >&2 "-Grant- $1" - echo grant - exit 0 -} - -function deny { - $verbose && echo >&2 "-Deny- $1" - echo deny - exit 1 -} - -function info { - $verbose && echo >&2 "-Info- $1" -} - -# Implement generic branch and tag policies. -# - Tags should not be updated once created. -# - Branches should only be fast-forwarded unless their pattern starts with '+' -case "$1" in - refs/tags/*) - git rev-parse --verify -q "$1" && - deny >/dev/null "You can't overwrite an existing tag" - ;; - refs/heads/*) - # No rebasing or rewinding - if expr "$2" : '0*$' >/dev/null; then - info "The branch '$1' is new..." - else - # updating -- make sure it is a fast-forward - mb=$(git merge-base "$2" "$3") - case "$mb,$2" in - "$2,$mb") info "Update is fast-forward" ;; - *) noff=y; info "This is not a fast-forward update.";; - esac - fi - ;; - *) - deny >/dev/null \ - "Branch is not under refs/heads or refs/tags. What are you trying to do?" - ;; -esac - -# Implement per-branch controls based on username -allowed_users_file=$GIT_DIR/info/allowed-users -username=$(id -u -n) -info "The user is: '$username'" - -if test -f "$allowed_users_file" -then - rc=$(cat $allowed_users_file | grep -v '^#' | grep -v '^$' | - while read heads user_patterns - do - # does this rule apply to us? - head_pattern=${heads#+} - matchlen=$(expr "$1" : "${head_pattern#+}") - test "$matchlen" = ${#1} || continue - - # if non-ff, $heads must be with the '+' prefix - test -n "$noff" && - test "$head_pattern" = "$heads" && continue - - info "Found matching head pattern: '$head_pattern'" - for user_pattern in $user_patterns; do - info "Checking user: '$username' against pattern: '$user_pattern'" - matchlen=$(expr "$username" : "$user_pattern") - if test "$matchlen" = "${#username}" - then - grant "Allowing user: '$username' with pattern: '$user_pattern'" - fi - done - deny "The user is not in the access list for this branch" - done - ) - case "$rc" in - grant) grant >/dev/null "Granting access based on $allowed_users_file" ;; - deny) deny >/dev/null "Denying access based on $allowed_users_file" ;; - *) ;; - esac -fi - -allowed_groups_file=$GIT_DIR/info/allowed-groups -groups=$(id -G -n) -info "The user belongs to the following groups:" -info "'$groups'" - -if test -f "$allowed_groups_file" -then - rc=$(cat $allowed_groups_file | grep -v '^#' | grep -v '^$' | - while read heads group_patterns - do - # does this rule apply to us? - head_pattern=${heads#+} - matchlen=$(expr "$1" : "${head_pattern#+}") - test "$matchlen" = ${#1} || continue - - # if non-ff, $heads must be with the '+' prefix - test -n "$noff" && - test "$head_pattern" = "$heads" && continue - - info "Found matching head pattern: '$head_pattern'" - for group_pattern in $group_patterns; do - for groupname in $groups; do - info "Checking group: '$groupname' against pattern: '$group_pattern'" - matchlen=$(expr "$groupname" : "$group_pattern") - if test "$matchlen" = "${#groupname}" - then - grant "Allowing group: '$groupname' with pattern: '$group_pattern'" - fi - done - done - deny "None of the user's groups are in the access list for this branch" - done - ) - case "$rc" in - grant) grant >/dev/null "Granting access based on $allowed_groups_file" ;; - deny) deny >/dev/null "Denying access based on $allowed_groups_file" ;; - *) ;; - esac -fi - -deny >/dev/null "There are no more rules to check. Denying access" ----------------------------------------------------- - -This uses two files, $GIT_DIR/info/allowed-users and -allowed-groups, to describe which heads can be pushed into by -whom. The format of each file would look like this: - - refs/heads/master junio - +refs/heads/pu junio - refs/heads/cogito$ pasky - refs/heads/bw/.* linus - refs/heads/tmp/.* .* - refs/tags/v[0-9].* junio - -With this, Linus can push or create "bw/penguin" or "bw/zebra" -or "bw/panda" branches, Pasky can do only "cogito", and JC can -do master and pu branches and make versioned tags. And anybody -can do tmp/blah branches. The '+' sign at the pu record means -that JC can make non-fast-forward pushes on it. diff --git a/third_party/git/Documentation/howto/use-git-daemon.txt b/third_party/git/Documentation/howto/use-git-daemon.txt deleted file mode 100644 index 7af2e52cf3..0000000000 --- a/third_party/git/Documentation/howto/use-git-daemon.txt +++ /dev/null @@ -1,54 +0,0 @@ -Content-type: text/asciidoc - -How to use git-daemon -===================== - -Git can be run in inetd mode and in stand alone mode. But all you want is -let a coworker pull from you, and therefore need to set up a Git server -real quick, right? - -Note that git-daemon is not really chatty at the moment, especially when -things do not go according to plan (e.g. a socket could not be bound). - -Another word of warning: if you run - - $ git ls-remote git://127.0.0.1/rule-the-world.git - -and you see a message like - - fatal: The remote end hung up unexpectedly - -it only means that _something_ went wrong. To find out _what_ went wrong, -you have to ask the server. (Git refuses to be more precise for your -security only. Take off your shoes now. You have any coins in your pockets? -Sorry, not allowed -- who knows what you planned to do with them?) - -With these two caveats, let's see an example: - - $ git daemon --reuseaddr --verbose --base-path=/home/gitte/git \ - --export-all -- /home/gitte/git/rule-the-world.git - -(Of course, unless your user name is `gitte` _and_ your repository is in -~/rule-the-world.git, you have to adjust the paths. If your repository is -not bare, be aware that you have to type the path to the .git directory!) - -This invocation tries to reuse the address if it is already taken -(this can save you some debugging, because otherwise killing and restarting -git-daemon could just silently fail to bind to a socket). - -Also, it is (relatively) verbose when somebody actually connects to it. -It also sets the base path, which means that all the projects which can be -accessed using this daemon have to reside in or under that path. - -The option `--export-all` just means that you _don't_ have to create a -file named `git-daemon-export-ok` in each exported repository. (Otherwise, -git-daemon would complain loudly, and refuse to cooperate.) - -Last of all, the repository which should be exported is specified. It is -a good practice to put the paths after a "--" separator. - -Now, test your daemon with - - $ git ls-remote git://127.0.0.1/rule-the-world.git - -If this does not work, find out why, and submit a patch to this document. diff --git a/third_party/git/Documentation/howto/using-merge-subtree.txt b/third_party/git/Documentation/howto/using-merge-subtree.txt deleted file mode 100644 index a499a94ac2..0000000000 --- a/third_party/git/Documentation/howto/using-merge-subtree.txt +++ /dev/null @@ -1,75 +0,0 @@ -Date: Sat, 5 Jan 2008 20:17:40 -0500 -From: Sean <seanlkml@sympatico.ca> -To: Miklos Vajna <vmiklos@frugalware.org> -Cc: git@vger.kernel.org -Subject: how to use git merge -s subtree? -Abstract: In this article, Sean demonstrates how one can use the subtree merge - strategy. -Content-type: text/asciidoc -Message-ID: <BAYC1-PASMTP12374B54BA370A1E1C6E78AE4E0@CEZ.ICE> - -How to use the subtree merge strategy -===================================== - -There are situations where you want to include contents in your project -from an independently developed project. You can just pull from the -other project as long as there are no conflicting paths. - -The problematic case is when there are conflicting files. Potential -candidates are Makefiles and other standard filenames. You could merge -these files but probably you do not want to. A better solution for this -problem can be to merge the project as its own subdirectory. This is not -supported by the 'recursive' merge strategy, so just pulling won't work. - -What you want is the 'subtree' merge strategy, which helps you in such a -situation. - -In this example, let's say you have the repository at `/path/to/B` (but -it can be a URL as well, if you want). You want to merge the 'master' -branch of that repository to the `dir-B` subdirectory in your current -branch. - -Here is the command sequence you need: - ----------------- -$ git remote add -f Bproject /path/to/B <1> -$ git merge -s ours --no-commit --allow-unrelated-histories Bproject/master <2> -$ git read-tree --prefix=dir-B/ -u Bproject/master <3> -$ git commit -m "Merge B project as our subdirectory" <4> - -$ git pull -s subtree Bproject master <5> ----------------- -<1> name the other project "Bproject", and fetch. -<2> prepare for the later step to record the result as a merge. -<3> read "master" branch of Bproject to the subdirectory "dir-B". -<4> record the merge result. -<5> maintain the result with subsequent merges using "subtree" - -The first four commands are used for the initial merge, while the last -one is to merge updates from 'B project'. - -Comparing 'subtree' merge with submodules ------------------------------------------ - -- The benefit of using subtree merge is that it requires less - administrative burden from the users of your repository. It works with - older (before Git v1.5.2) clients and you have the code right after - clone. - -- However if you use submodules then you can choose not to transfer the - submodule objects. This may be a problem with the subtree merge. - -- Also, in case you make changes to the other project, it is easier to - submit changes if you just use submodules. - -Additional tips ---------------- - -- If you made changes to the other project in your repository, they may - want to merge from your project. This is possible using subtree -- it - can shift up the paths in your tree and then they can merge only the - relevant parts of your tree. - -- Please note that if the other project merges from you, then it will - connect its history to yours, which can be something they don't want - to. diff --git a/third_party/git/Documentation/howto/using-signed-tag-in-pull-request.txt b/third_party/git/Documentation/howto/using-signed-tag-in-pull-request.txt deleted file mode 100644 index bbf040eda8..0000000000 --- a/third_party/git/Documentation/howto/using-signed-tag-in-pull-request.txt +++ /dev/null @@ -1,217 +0,0 @@ -From: Junio C Hamano <gitster@pobox.com> -Date: Tue, 17 Jan 2011 13:00:00 -0800 -Subject: Using signed tag in pull requests -Abstract: Beginning v1.7.9, a contributor can push a signed tag to her - publishing repository and ask her integrator to pull it. This assures the - integrator that the pulled history is authentic and allows others to - later validate it. -Content-type: text/asciidoc - -How to use a signed tag in pull requests -======================================== - -A typical distributed workflow using Git is for a contributor to fork a -project, build on it, publish the result to her public repository, and ask -the "upstream" person (often the owner of the project where she forked -from) to pull from her public repository. Requesting such a "pull" is made -easy by the `git request-pull` command. - -Earlier, a typical pull request may have started like this: - ------------- - The following changes since commit 406da78032179...: - - Froboz 3.2 (2011-09-30 14:20:57 -0700) - - are available in the Git repository at: - - example.com:/git/froboz.git for-xyzzy ------------- - -followed by a shortlog of the changes and a diffstat. - -The request was for a branch name (e.g. `for-xyzzy`) in the public -repository of the contributor, and even though it stated where the -contributor forked her work from, the message did not say anything about -the commit to expect at the tip of the for-xyzzy branch. If the site that -hosts the public repository of the contributor cannot be fully trusted, it -was unnecessarily hard to make sure what was pulled by the integrator was -genuinely what the contributor had produced for the project. Also there -was no easy way for third-party auditors to later verify the resulting -history. - -Starting from Git release v1.7.9, a contributor can add a signed tag to -the commit at the tip of the history and ask the integrator to pull that -signed tag. When the integrator runs `git pull`, the signed tag is -automatically verified to assure that the history is not tampered with. -In addition, the resulting merge commit records the content of the signed -tag, so that other people can verify that the branch merged by the -integrator was signed by the contributor, without fetching the signed tag -used to validate the pull request separately and keeping it in the refs -namespace. - -This document describes the workflow between the contributor and the -integrator, using Git v1.7.9 or later. - - -A contributor or a lieutenant ------------------------------ - -After preparing her work to be pulled, the contributor uses `git tag -s` -to create a signed tag: - ------------- - $ git checkout work - $ ... "git pull" from sublieutenants, "git commit" your own work ... - $ git tag -s -m "Completed frotz feature" frotz-for-xyzzy work ------------- - -Note that this example uses the `-m` option to create a signed tag with -just a one-liner message, but this is for illustration purposes only. It -is advisable to compose a well-written explanation of what the topic does -to justify why it is worthwhile for the integrator to pull it, as this -message will eventually become part of the final history after the -integrator responds to the pull request (as we will see later). - -Then she pushes the tag out to her public repository: - ------------- - $ git push example.com:/git/froboz.git/ +frotz-for-xyzzy ------------- - -There is no need to push the `work` branch or anything else. - -Note that the above command line used a plus sign at the beginning of -`+frotz-for-xyzzy` to allow forcing the update of a tag, as the same -contributor may want to reuse a signed tag with the same name after the -previous pull request has already been responded to. - -The contributor then prepares a message to request a "pull": - ------------- - $ git request-pull v3.2 example.com:/git/froboz.git/ frotz-for-xyzzy >msg.txt ------------- - -The arguments are: - -. the version of the integrator's commit the contributor based her work on; -. the URL of the repository, to which the contributor has pushed what she - wants to get pulled; and -. the name of the tag the contributor wants to get pulled (earlier, she could - write only a branch name here). - -The resulting msg.txt file begins like so: - ------------- - The following changes since commit 406da78032179...: - - Froboz 3.2 (2011-09-30 14:20:57 -0700) - - are available in the Git repository at: - - example.com:/git/froboz.git tags/frotz-for-xyzzy - - for you to fetch changes up to 703f05ad5835c...: - - Add tests and documentation for frotz (2011-12-02 10:02:52 -0800) - - ----------------------------------------------- - Completed frotz feature - ----------------------------------------------- ------------- - -followed by a shortlog of the changes and a diffstat. Comparing this with -the earlier illustration of the output from the traditional `git request-pull` -command, the reader should notice that: - -. The tip commit to expect is shown to the integrator; and -. The signed tag message is shown prominently between the dashed lines - before the shortlog. - -The latter is why the contributor would want to justify why pulling her -work is worthwhile when creating the signed tag. The contributor then -opens her favorite MUA, reads msg.txt, edits and sends it to her upstream -integrator. - - -Integrator ----------- - -After receiving such a pull request message, the integrator fetches and -integrates the tag named in the request, with: - ------------- - $ git pull example.com:/git/froboz.git/ tags/frotz-for-xyzzy ------------- - -This operation will always open an editor to allow the integrator to fine -tune the commit log message when merging a signed tag. Also, pulling a -signed tag will always create a merge commit even when the integrator does -not have any new commit since the contributor's work forked (i.e. 'fast -forward'), so that the integrator can properly explain what the merge is -about and why it was made. - -In the editor, the integrator will see something like this: - ------------- - Merge tag 'frotz-for-xyzzy' of example.com:/git/froboz.git/ - - Completed frotz feature - # gpg: Signature made Fri 02 Dec 2011 10:03:01 AM PST using RSA key ID 96AFE6CB - # gpg: Good signature from "Con Tributor <nitfol@example.com>" ------------- - -Notice that the message recorded in the signed tag "Completed frotz -feature" appears here, and again that is why it is important for the -contributor to explain her work well when creating the signed tag. - -As usual, the lines commented with `#` are stripped out. The resulting -commit records the signed tag used for this validation in a hidden field -so that it can later be used by others to audit the history. There is no -need for the integrator to keep a separate copy of the tag in his -repository (i.e. `git tag -l` won't list the `frotz-for-xyzzy` tag in the -above example), and there is no need to publish the tag to his public -repository, either. - -After the integrator responds to the pull request and her work becomes -part of the permanent history, the contributor can remove the tag from -her public repository, if she chooses, in order to keep the tag namespace -of her public repository clean, with: - ------------- - $ git push example.com:/git/froboz.git :frotz-for-xyzzy ------------- - - -Auditors --------- - -The `--show-signature` option can be given to `git log` or `git show` and -shows the verification status of the embedded signed tag in merge commits -created when the integrator responded to a pull request of a signed tag. - -A typical output from `git show --show-signature` may look like this: - ------------- - $ git show --show-signature - commit 02306ef6a3498a39118aef9df7975bdb50091585 - merged tag 'frotz-for-xyzzy' - gpg: Signature made Fri 06 Jan 2012 12:41:49 PM PST using RSA key ID 96AFE6CB - gpg: Good signature from "Con Tributor <nitfol@example.com>" - Merge: 406da78 703f05a - Author: Inte Grator <xyzzy@example.com> - Date: Tue Jan 17 13:49:41 2012 -0800 - - Merge tag 'frotz-for-xyzzy' of example.com:/git/froboz.git/ - - Completed frotz feature - - * tag 'frotz-for-xyzzy' (100 commits) - Add tests and documentation for frotz - ... ------------- - -There is no need for the auditor to explicitly fetch the contributor's -signature, or to even be aware of what tag(s) the contributor and integrator -used to communicate the signature. All the required information is recorded -as part of the merge commit. diff --git a/third_party/git/Documentation/i18n.txt b/third_party/git/Documentation/i18n.txt deleted file mode 100644 index 7e36e5b55b..0000000000 --- a/third_party/git/Documentation/i18n.txt +++ /dev/null @@ -1,70 +0,0 @@ -Git is to some extent character encoding agnostic. - - - The contents of the blob objects are uninterpreted sequences - of bytes. There is no encoding translation at the core - level. - - - Path names are encoded in UTF-8 normalization form C. This - applies to tree objects, the index file, ref names, as well as - path names in command line arguments, environment variables - and config files (`.git/config` (see linkgit:git-config[1]), - linkgit:gitignore[5], linkgit:gitattributes[5] and - linkgit:gitmodules[5]). -+ -Note that Git at the core level treats path names simply as -sequences of non-NUL bytes, there are no path name encoding -conversions (except on Mac and Windows). Therefore, using -non-ASCII path names will mostly work even on platforms and file -systems that use legacy extended ASCII encodings. However, -repositories created on such systems will not work properly on -UTF-8-based systems (e.g. Linux, Mac, Windows) and vice versa. -Additionally, many Git-based tools simply assume path names to -be UTF-8 and will fail to display other encodings correctly. - - - Commit log messages are typically encoded in UTF-8, but other - extended ASCII encodings are also supported. This includes - ISO-8859-x, CP125x and many others, but _not_ UTF-16/32, - EBCDIC and CJK multi-byte encodings (GBK, Shift-JIS, Big5, - EUC-x, CP9xx etc.). - -Although we encourage that the commit log messages are encoded -in UTF-8, both the core and Git Porcelain are designed not to -force UTF-8 on projects. If all participants of a particular -project find it more convenient to use legacy encodings, Git -does not forbid it. However, there are a few things to keep in -mind. - -. 'git commit' and 'git commit-tree' issues - a warning if the commit log message given to it does not look - like a valid UTF-8 string, unless you explicitly say your - project uses a legacy encoding. The way to say this is to - have i18n.commitencoding in `.git/config` file, like this: -+ ------------- -[i18n] - commitEncoding = ISO-8859-1 ------------- -+ -Commit objects created with the above setting record the value -of `i18n.commitEncoding` in its `encoding` header. This is to -help other people who look at them later. Lack of this header -implies that the commit log message is encoded in UTF-8. - -. 'git log', 'git show', 'git blame' and friends look at the - `encoding` header of a commit object, and try to re-code the - log message into UTF-8 unless otherwise specified. You can - specify the desired output encoding with - `i18n.logOutputEncoding` in `.git/config` file, like this: -+ ------------- -[i18n] - logOutputEncoding = ISO-8859-1 ------------- -+ -If you do not have this configuration variable, the value of -`i18n.commitEncoding` is used instead. - -Note that we deliberately chose not to re-code the commit log -message when a commit is made to force UTF-8 at the commit -object level, because re-coding to UTF-8 is not necessarily a -reversible operation. diff --git a/third_party/git/Documentation/install-doc-quick.sh b/third_party/git/Documentation/install-doc-quick.sh deleted file mode 100755 index 17231d8e59..0000000000 --- a/third_party/git/Documentation/install-doc-quick.sh +++ /dev/null @@ -1,40 +0,0 @@ -#!/bin/sh -# This requires git-manpages and/or git-htmldocs repositories - -repository=${1?repository} -destdir=${2?destination} -GIT_MAN_REF=${3?master} - -GIT_DIR= -for d in "$repository/.git" "$repository" -do - if GIT_DIR="$d" git rev-parse "$GIT_MAN_REF" >/dev/null 2>&1 - then - GIT_DIR="$d" - export GIT_DIR - break - fi -done - -if test -z "$GIT_DIR" -then - echo >&2 "Neither $repository nor $repository/.git is a repository" - exit 1 -fi - -GIT_WORK_TREE=$(pwd) -GIT_INDEX_FILE=$(pwd)/.quick-doc.$$ -export GIT_INDEX_FILE GIT_WORK_TREE -rm -f "$GIT_INDEX_FILE" -trap 'rm -f "$GIT_INDEX_FILE"' 0 - -git read-tree "$GIT_MAN_REF" -git checkout-index -a -f --prefix="$destdir"/ - -if test -n "$GZ" -then - git ls-tree -r --name-only "$GIT_MAN_REF" | - xargs printf "$destdir/%s\n" | - xargs gzip -f -fi -rm -f "$GIT_INDEX_FILE" diff --git a/third_party/git/Documentation/install-webdoc.sh b/third_party/git/Documentation/install-webdoc.sh deleted file mode 100755 index ed8b4ff3e5..0000000000 --- a/third_party/git/Documentation/install-webdoc.sh +++ /dev/null @@ -1,39 +0,0 @@ -#!/bin/sh - -T="$1" - -for h in \ - *.txt *.html \ - howto/*.txt howto/*.html \ - technical/*.txt technical/*.html \ - RelNotes/*.txt *.css -do - if test ! -f "$h" - then - : did not match - elif test -f "$T/$h" && - $DIFF -u -I'^Last updated ' "$T/$h" "$h" - then - :; # up to date - else - echo >&2 "# install $h $T/$h" - rm -f "$T/$h" - mkdir -p $(dirname "$T/$h") - cp "$h" "$T/$h" - fi -done -strip_leading=$(echo "$T/" | sed -e 's|.|.|g') -for th in \ - "$T"/*.html "$T"/*.txt \ - "$T"/howto/*.txt "$T"/howto/*.html \ - "$T"/technical/*.txt "$T"/technical/*.html -do - h=$(expr "$th" : "$strip_leading"'\(.*\)') - case "$h" in - RelNotes-*.txt | index.html) continue ;; - esac - test -f "$h" && continue - echo >&2 "# rm -f $th" - rm -f "$th" -done -ln -sf git.html "$T/index.html" diff --git a/third_party/git/Documentation/line-range-format.txt b/third_party/git/Documentation/line-range-format.txt deleted file mode 100644 index 829676ff98..0000000000 --- a/third_party/git/Documentation/line-range-format.txt +++ /dev/null @@ -1,30 +0,0 @@ -<start> and <end> can take one of these forms: - -- number -+ -If <start> or <end> is a number, it specifies an -absolute line number (lines count from 1). -+ - -- /regex/ -+ -This form will use the first line matching the given -POSIX regex. If <start> is a regex, it will search from the end of -the previous `-L` range, if any, otherwise from the start of file. -If <start> is ``^/regex/'', it will search from the start of file. -If <end> is a regex, it will search -starting at the line given by <start>. -+ - -- +offset or -offset -+ -This is only valid for <end> and will specify a number -of lines before or after the line given by <start>. - -+ -If ``:<funcname>'' is given in place of <start> and <end>, it is a -regular expression that denotes the range from the first funcname line -that matches <funcname>, up to the next funcname line. ``:<funcname>'' -searches from the end of the previous `-L` range, if any, otherwise -from the start of file. ``^:<funcname>'' searches from the start of -file. diff --git a/third_party/git/Documentation/lint-gitlink.perl b/third_party/git/Documentation/lint-gitlink.perl deleted file mode 100755 index 476cc30b83..0000000000 --- a/third_party/git/Documentation/lint-gitlink.perl +++ /dev/null @@ -1,71 +0,0 @@ -#!/usr/bin/perl - -use File::Find; -use Getopt::Long; - -my $basedir = "."; -GetOptions("basedir=s" => \$basedir) - or die("Cannot parse command line arguments\n"); - -my $found_errors = 0; - -sub report { - my ($where, $what, $error) = @_; - print "$where: $error: $what\n"; - $found_errors = 1; -} - -sub grab_section { - my ($page) = @_; - open my $fh, "<", "$basedir/$page.txt"; - my $firstline = <$fh>; - chomp $firstline; - close $fh; - my ($section) = ($firstline =~ /.*\((\d)\)$/); - return $section; -} - -sub lint { - my ($file) = @_; - open my $fh, "<", $file - or return; - while (<$fh>) { - my $where = "$file:$."; - while (s/linkgit:((.*?)\[(\d)\])//) { - my ($target, $page, $section) = ($1, $2, $3); - - # De-AsciiDoc - $page =~ s/{litdd}/--/g; - - if ($page !~ /^git/) { - report($where, $target, "nongit link"); - next; - } - if (! -f "$basedir/$page.txt") { - report($where, $target, "no such source"); - next; - } - $real_section = grab_section($page); - if ($real_section != $section) { - report($where, $target, - "wrong section (should be $real_section)"); - next; - } - } - } - close $fh; -} - -sub lint_it { - lint($File::Find::name) if -f && /\.txt$/; -} - -if (!@ARGV) { - find({ wanted => \&lint_it, no_chdir => 1 }, $basedir); -} else { - for (@ARGV) { - lint($_); - } -} - -exit $found_errors; diff --git a/third_party/git/Documentation/mailmap.txt b/third_party/git/Documentation/mailmap.txt deleted file mode 100644 index 4a8c276529..0000000000 --- a/third_party/git/Documentation/mailmap.txt +++ /dev/null @@ -1,75 +0,0 @@ -If the file `.mailmap` exists at the toplevel of the repository, or at -the location pointed to by the mailmap.file or mailmap.blob -configuration options, it -is used to map author and committer names and email addresses to -canonical real names and email addresses. - -In the simple form, each line in the file consists of the canonical -real name of an author, whitespace, and an email address used in the -commit (enclosed by '<' and '>') to map to the name. For example: --- - Proper Name <commit@email.xx> --- - -The more complex forms are: --- - <proper@email.xx> <commit@email.xx> --- -which allows mailmap to replace only the email part of a commit, and: --- - Proper Name <proper@email.xx> <commit@email.xx> --- -which allows mailmap to replace both the name and the email of a -commit matching the specified commit email address, and: --- - Proper Name <proper@email.xx> Commit Name <commit@email.xx> --- -which allows mailmap to replace both the name and the email of a -commit matching both the specified commit name and email address. - -Example 1: Your history contains commits by two authors, Jane -and Joe, whose names appear in the repository under several forms: - ------------- -Joe Developer <joe@example.com> -Joe R. Developer <joe@example.com> -Jane Doe <jane@example.com> -Jane Doe <jane@laptop.(none)> -Jane D. <jane@desktop.(none)> ------------- - -Now suppose that Joe wants his middle name initial used, and Jane -prefers her family name fully spelled out. A proper `.mailmap` file -would look like: - ------------- -Jane Doe <jane@desktop.(none)> -Joe R. Developer <joe@example.com> ------------- - -Note how there is no need for an entry for `<jane@laptop.(none)>`, because the -real name of that author is already correct. - -Example 2: Your repository contains commits from the following -authors: - ------------- -nick1 <bugs@company.xx> -nick2 <bugs@company.xx> -nick2 <nick2@company.xx> -santa <me@company.xx> -claus <me@company.xx> -CTO <cto@coompany.xx> ------------- - -Then you might want a `.mailmap` file that looks like: ------------- -<cto@company.xx> <cto@coompany.xx> -Some Dude <some@dude.xx> nick1 <bugs@company.xx> -Other Author <other@author.xx> nick2 <bugs@company.xx> -Other Author <other@author.xx> <nick2@company.xx> -Santa Claus <santa.claus@northpole.xx> <me@company.xx> ------------- - -Use hash '#' for comments that are either on their own line, or after -the email address. diff --git a/third_party/git/Documentation/manpage-1.72.xsl b/third_party/git/Documentation/manpage-1.72.xsl deleted file mode 100644 index b4d315cb8c..0000000000 --- a/third_party/git/Documentation/manpage-1.72.xsl +++ /dev/null @@ -1,14 +0,0 @@ -<!-- manpage-1.72.xsl: - special settings for manpages rendered from asciidoc+docbook - handles peculiarities in docbook-xsl 1.72.0 --> -<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - version="1.0"> - -<xsl:import href="manpage-base.xsl"/> - -<!-- these are the special values for the roff control characters - needed for docbook-xsl 1.72.0 --> -<xsl:param name="git.docbook.backslash">▓</xsl:param> -<xsl:param name="git.docbook.dot" >⌂</xsl:param> - -</xsl:stylesheet> diff --git a/third_party/git/Documentation/manpage-base-url.xsl.in b/third_party/git/Documentation/manpage-base-url.xsl.in deleted file mode 100644 index e800904df3..0000000000 --- a/third_party/git/Documentation/manpage-base-url.xsl.in +++ /dev/null @@ -1,10 +0,0 @@ -<!-- manpage-base-url.xsl: - special settings for manpages rendered from newer docbook --> -<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - version="1.0"> - -<!-- set a base URL for relative links --> -<xsl:param name="man.base.url.for.relative.links" - >@@MAN_BASE_URL@@</xsl:param> - -</xsl:stylesheet> diff --git a/third_party/git/Documentation/manpage-base.xsl b/third_party/git/Documentation/manpage-base.xsl deleted file mode 100644 index a264fa6160..0000000000 --- a/third_party/git/Documentation/manpage-base.xsl +++ /dev/null @@ -1,35 +0,0 @@ -<!-- manpage-base.xsl: - special formatting for manpages rendered from asciidoc+docbook --> -<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - version="1.0"> - -<!-- these params silence some output from xmlto --> -<xsl:param name="man.output.quietly" select="1"/> -<xsl:param name="refentry.meta.get.quietly" select="1"/> - -<!-- convert asciidoc callouts to man page format; - git.docbook.backslash and git.docbook.dot params - must be supplied by another XSL file or other means --> -<xsl:template match="co"> - <xsl:value-of select="concat( - $git.docbook.backslash,'fB(', - substring-after(@id,'-'),')', - $git.docbook.backslash,'fR')"/> -</xsl:template> -<xsl:template match="calloutlist"> - <xsl:value-of select="$git.docbook.dot"/> - <xsl:text>sp </xsl:text> - <xsl:apply-templates/> - <xsl:text> </xsl:text> -</xsl:template> -<xsl:template match="callout"> - <xsl:value-of select="concat( - $git.docbook.backslash,'fB', - substring-after(@arearefs,'-'), - '. ',$git.docbook.backslash,'fR')"/> - <xsl:apply-templates/> - <xsl:value-of select="$git.docbook.dot"/> - <xsl:text>br </xsl:text> -</xsl:template> - -</xsl:stylesheet> diff --git a/third_party/git/Documentation/manpage-bold-literal.xsl b/third_party/git/Documentation/manpage-bold-literal.xsl deleted file mode 100644 index 608eb5df62..0000000000 --- a/third_party/git/Documentation/manpage-bold-literal.xsl +++ /dev/null @@ -1,17 +0,0 @@ -<!-- manpage-bold-literal.xsl: - special formatting for manpages rendered from asciidoc+docbook --> -<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - version="1.0"> - -<!-- render literal text as bold (instead of plain or monospace); - this makes literal text easier to distinguish in manpages - viewed on a tty --> -<xsl:template match="literal"> - <xsl:value-of select="$git.docbook.backslash"/> - <xsl:text>fB</xsl:text> - <xsl:apply-templates/> - <xsl:value-of select="$git.docbook.backslash"/> - <xsl:text>fR</xsl:text> -</xsl:template> - -</xsl:stylesheet> diff --git a/third_party/git/Documentation/manpage-normal.xsl b/third_party/git/Documentation/manpage-normal.xsl deleted file mode 100644 index a48f5b11f3..0000000000 --- a/third_party/git/Documentation/manpage-normal.xsl +++ /dev/null @@ -1,13 +0,0 @@ -<!-- manpage-normal.xsl: - special settings for manpages rendered from asciidoc+docbook - handles anything we want to keep away from docbook-xsl 1.72.0 --> -<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - version="1.0"> - -<xsl:import href="manpage-base.xsl"/> - -<!-- these are the normal values for the roff control characters --> -<xsl:param name="git.docbook.backslash">\</xsl:param> -<xsl:param name="git.docbook.dot" >.</xsl:param> - -</xsl:stylesheet> diff --git a/third_party/git/Documentation/manpage-quote-apos.xsl b/third_party/git/Documentation/manpage-quote-apos.xsl deleted file mode 100644 index aeb8839f33..0000000000 --- a/third_party/git/Documentation/manpage-quote-apos.xsl +++ /dev/null @@ -1,16 +0,0 @@ -<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - version="1.0"> - -<!-- work around newer groff/man setups using a prettier apostrophe - that unfortunately does not quote anything when cut&pasting - examples to the shell --> -<xsl:template name="escape.apostrophe"> - <xsl:param name="content"/> - <xsl:call-template name="string.subst"> - <xsl:with-param name="string" select="$content"/> - <xsl:with-param name="target">'</xsl:with-param> - <xsl:with-param name="replacement">\(aq</xsl:with-param> - </xsl:call-template> -</xsl:template> - -</xsl:stylesheet> diff --git a/third_party/git/Documentation/manpage-suppress-sp.xsl b/third_party/git/Documentation/manpage-suppress-sp.xsl deleted file mode 100644 index a63c7632a8..0000000000 --- a/third_party/git/Documentation/manpage-suppress-sp.xsl +++ /dev/null @@ -1,21 +0,0 @@ -<!-- manpage-suppress-sp.xsl: - special settings for manpages rendered from asciidoc+docbook - handles erroneous, inline .sp in manpage output of some - versions of docbook-xsl --> -<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - version="1.0"> - -<!-- attempt to work around spurious .sp at the tail of the line - that some versions of docbook stylesheets seem to add --> -<xsl:template match="simpara"> - <xsl:variable name="content"> - <xsl:apply-templates/> - </xsl:variable> - <xsl:value-of select="normalize-space($content)"/> - <xsl:if test="not(ancestor::authorblurb) and - not(ancestor::personblurb)"> - <xsl:text> </xsl:text> - </xsl:if> -</xsl:template> - -</xsl:stylesheet> diff --git a/third_party/git/Documentation/merge-options.txt b/third_party/git/Documentation/merge-options.txt deleted file mode 100644 index 79a00d2a4a..0000000000 --- a/third_party/git/Documentation/merge-options.txt +++ /dev/null @@ -1,158 +0,0 @@ ---commit:: ---no-commit:: - Perform the merge and commit the result. This option can - be used to override --no-commit. -+ -With --no-commit perform the merge and stop just before creating -a merge commit, to give the user a chance to inspect and further -tweak the merge result before committing. -+ -Note that fast-forward updates do not create a merge commit and -therefore there is no way to stop those merges with --no-commit. -Thus, if you want to ensure your branch is not changed or updated -by the merge command, use --no-ff with --no-commit. - ---edit:: --e:: ---no-edit:: - Invoke an editor before committing successful mechanical merge to - further edit the auto-generated merge message, so that the user - can explain and justify the merge. The `--no-edit` option can be - used to accept the auto-generated message (this is generally - discouraged). -ifndef::git-pull[] -The `--edit` (or `-e`) option is still useful if you are -giving a draft message with the `-m` option from the command line -and want to edit it in the editor. -endif::git-pull[] -+ -Older scripts may depend on the historical behaviour of not allowing the -user to edit the merge log message. They will see an editor opened when -they run `git merge`. To make it easier to adjust such scripts to the -updated behaviour, the environment variable `GIT_MERGE_AUTOEDIT` can be -set to `no` at the beginning of them. - ---cleanup=<mode>:: - This option determines how the merge message will be cleaned up before - commiting. See linkgit:git-commit[1] for more details. In addition, if - the '<mode>' is given a value of `scissors`, scissors will be appended - to `MERGE_MSG` before being passed on to the commit machinery in the - case of a merge conflict. - ---ff:: - When the merge resolves as a fast-forward, only update the branch - pointer, without creating a merge commit. This is the default - behavior. - ---no-ff:: - Create a merge commit even when the merge resolves as a - fast-forward. This is the default behaviour when merging an - annotated (and possibly signed) tag that is not stored in - its natural place in 'refs/tags/' hierarchy. - ---ff-only:: - Refuse to merge and exit with a non-zero status unless the - current `HEAD` is already up to date or the merge can be - resolved as a fast-forward. - --S[<keyid>]:: ---gpg-sign[=<keyid>]:: - GPG-sign the resulting merge commit. The `keyid` argument is - optional and defaults to the committer identity; if specified, - it must be stuck to the option without a space. - ---log[=<n>]:: ---no-log:: - In addition to branch names, populate the log message with - one-line descriptions from at most <n> actual commits that are being - merged. See also linkgit:git-fmt-merge-msg[1]. -+ -With --no-log do not list one-line descriptions from the -actual commits being merged. - ---signoff:: ---no-signoff:: - Add Signed-off-by line by the committer at the end of the commit - log message. The meaning of a signoff depends on the project, - but it typically certifies that committer has - the rights to submit this work under the same license and - agrees to a Developer Certificate of Origin - (see http://developercertificate.org/ for more information). -+ -With --no-signoff do not add a Signed-off-by line. - ---stat:: --n:: ---no-stat:: - Show a diffstat at the end of the merge. The diffstat is also - controlled by the configuration option merge.stat. -+ -With -n or --no-stat do not show a diffstat at the end of the -merge. - ---squash:: ---no-squash:: - Produce the working tree and index state as if a real merge - happened (except for the merge information), but do not actually - make a commit, move the `HEAD`, or record `$GIT_DIR/MERGE_HEAD` - (to cause the next `git commit` command to create a merge - commit). This allows you to create a single commit on top of - the current branch whose effect is the same as merging another - branch (or more in case of an octopus). -+ -With --no-squash perform the merge and commit the result. This -option can be used to override --squash. -+ -With --squash, --commit is not allowed, and will fail. - --s <strategy>:: ---strategy=<strategy>:: - Use the given merge strategy; can be supplied more than - once to specify them in the order they should be tried. - If there is no `-s` option, a built-in list of strategies - is used instead ('git merge-recursive' when merging a single - head, 'git merge-octopus' otherwise). - --X <option>:: ---strategy-option=<option>:: - Pass merge strategy specific option through to the merge - strategy. - ---verify-signatures:: ---no-verify-signatures:: - Verify that the tip commit of the side branch being merged is - signed with a valid key, i.e. a key that has a valid uid: in the - default trust model, this means the signing key has been signed by - a trusted key. If the tip commit of the side branch is not signed - with a valid key, the merge is aborted. - ---summary:: ---no-summary:: - Synonyms to --stat and --no-stat; these are deprecated and will be - removed in the future. - -ifndef::git-pull[] --q:: ---quiet:: - Operate quietly. Implies --no-progress. - --v:: ---verbose:: - Be verbose. - ---progress:: ---no-progress:: - Turn progress on/off explicitly. If neither is specified, - progress is shown if standard error is connected to a terminal. - Note that not all merge strategies may support progress - reporting. - -endif::git-pull[] - ---allow-unrelated-histories:: - By default, `git merge` command refuses to merge histories - that do not share a common ancestor. This option can be - used to override this safety when merging histories of two - projects that started their lives independently. As that is - a very rare occasion, no configuration variable to enable - this by default exists and will not be added. diff --git a/third_party/git/Documentation/merge-strategies.txt b/third_party/git/Documentation/merge-strategies.txt deleted file mode 100644 index aa66cbe41e..0000000000 --- a/third_party/git/Documentation/merge-strategies.txt +++ /dev/null @@ -1,136 +0,0 @@ -MERGE STRATEGIES ----------------- - -The merge mechanism (`git merge` and `git pull` commands) allows the -backend 'merge strategies' to be chosen with `-s` option. Some strategies -can also take their own options, which can be passed by giving `-X<option>` -arguments to `git merge` and/or `git pull`. - -resolve:: - This can only resolve two heads (i.e. the current branch - and another branch you pulled from) using a 3-way merge - algorithm. It tries to carefully detect criss-cross - merge ambiguities and is considered generally safe and - fast. - -recursive:: - This can only resolve two heads using a 3-way merge - algorithm. When there is more than one common - ancestor that can be used for 3-way merge, it creates a - merged tree of the common ancestors and uses that as - the reference tree for the 3-way merge. This has been - reported to result in fewer merge conflicts without - causing mismerges by tests done on actual merge commits - taken from Linux 2.6 kernel development history. - Additionally this can detect and handle merges involving - renames, but currently cannot make use of detected - copies. This is the default merge strategy when pulling - or merging one branch. -+ -The 'recursive' strategy can take the following options: - -ours;; - This option forces conflicting hunks to be auto-resolved cleanly by - favoring 'our' version. Changes from the other tree that do not - conflict with our side are reflected to the merge result. - For a binary file, the entire contents are taken from our side. -+ -This should not be confused with the 'ours' merge strategy, which does not -even look at what the other tree contains at all. It discards everything -the other tree did, declaring 'our' history contains all that happened in it. - -theirs;; - This is the opposite of 'ours'; note that, unlike 'ours', there is - no 'theirs' merge strategy to confuse this merge option with. - -patience;; - With this option, 'merge-recursive' spends a little extra time - to avoid mismerges that sometimes occur due to unimportant - matching lines (e.g., braces from distinct functions). Use - this when the branches to be merged have diverged wildly. - See also linkgit:git-diff[1] `--patience`. - -diff-algorithm=[patience|minimal|histogram|myers];; - Tells 'merge-recursive' to use a different diff algorithm, which - can help avoid mismerges that occur due to unimportant matching - lines (such as braces from distinct functions). See also - linkgit:git-diff[1] `--diff-algorithm`. - -ignore-space-change;; -ignore-all-space;; -ignore-space-at-eol;; -ignore-cr-at-eol;; - Treats lines with the indicated type of whitespace change as - unchanged for the sake of a three-way merge. Whitespace - changes mixed with other changes to a line are not ignored. - See also linkgit:git-diff[1] `-b`, `-w`, - `--ignore-space-at-eol`, and `--ignore-cr-at-eol`. -+ -* If 'their' version only introduces whitespace changes to a line, - 'our' version is used; -* If 'our' version introduces whitespace changes but 'their' - version includes a substantial change, 'their' version is used; -* Otherwise, the merge proceeds in the usual way. - -renormalize;; - This runs a virtual check-out and check-in of all three stages - of a file when resolving a three-way merge. This option is - meant to be used when merging branches with different clean - filters or end-of-line normalization rules. See "Merging - branches with differing checkin/checkout attributes" in - linkgit:gitattributes[5] for details. - -no-renormalize;; - Disables the `renormalize` option. This overrides the - `merge.renormalize` configuration variable. - -no-renames;; - Turn off rename detection. This overrides the `merge.renames` - configuration variable. - See also linkgit:git-diff[1] `--no-renames`. - -find-renames[=<n>];; - Turn on rename detection, optionally setting the similarity - threshold. This is the default. This overrides the - 'merge.renames' configuration variable. - See also linkgit:git-diff[1] `--find-renames`. - -rename-threshold=<n>;; - Deprecated synonym for `find-renames=<n>`. - -subtree[=<path>];; - This option is a more advanced form of 'subtree' strategy, where - the strategy makes a guess on how two trees must be shifted to - match with each other when merging. Instead, the specified path - is prefixed (or stripped from the beginning) to make the shape of - two trees to match. - -octopus:: - This resolves cases with more than two heads, but refuses to do - a complex merge that needs manual resolution. It is - primarily meant to be used for bundling topic branch - heads together. This is the default merge strategy when - pulling or merging more than one branch. - -ours:: - This resolves any number of heads, but the resulting tree of the - merge is always that of the current branch head, effectively - ignoring all changes from all other branches. It is meant to - be used to supersede old development history of side - branches. Note that this is different from the -Xours option to - the 'recursive' merge strategy. - -subtree:: - This is a modified recursive strategy. When merging trees A and - B, if B corresponds to a subtree of A, B is first adjusted to - match the tree structure of A, instead of reading the trees at - the same level. This adjustment is also done to the common - ancestor tree. - -With the strategies that use 3-way merge (including the default, 'recursive'), -if a change is made on both branches, but later reverted on one of the -branches, that change will be present in the merged result; some people find -this behavior confusing. It occurs because only the heads and the merge base -are considered when performing a merge, not the individual commits. The merge -algorithm therefore considers the reverted change as no change at all, and -substitutes the changed version instead. diff --git a/third_party/git/Documentation/pretty-formats.txt b/third_party/git/Documentation/pretty-formats.txt deleted file mode 100644 index 079598307a..0000000000 --- a/third_party/git/Documentation/pretty-formats.txt +++ /dev/null @@ -1,308 +0,0 @@ -PRETTY FORMATS --------------- - -If the commit is a merge, and if the pretty-format -is not 'oneline', 'email' or 'raw', an additional line is -inserted before the 'Author:' line. This line begins with -"Merge: " and the sha1s of ancestral commits are printed, -separated by spaces. Note that the listed commits may not -necessarily be the list of the *direct* parent commits if you -have limited your view of history: for example, if you are -only interested in changes related to a certain directory or -file. - -There are several built-in formats, and you can define -additional formats by setting a pretty.<name> -config option to either another format name, or a -'format:' string, as described below (see -linkgit:git-config[1]). Here are the details of the -built-in formats: - -* 'oneline' - - <sha1> <title line> -+ -This is designed to be as compact as possible. - -* 'short' - - commit <sha1> - Author: <author> - - <title line> - -* 'medium' - - commit <sha1> - Author: <author> - Date: <author date> - - <title line> - - <full commit message> - -* 'full' - - commit <sha1> - Author: <author> - Commit: <committer> - - <title line> - - <full commit message> - -* 'fuller' - - commit <sha1> - Author: <author> - AuthorDate: <author date> - Commit: <committer> - CommitDate: <committer date> - - <title line> - - <full commit message> - -* 'email' - - From <sha1> <date> - From: <author> - Date: <author date> - Subject: [PATCH] <title line> - - <full commit message> - -* 'raw' -+ -The 'raw' format shows the entire commit exactly as -stored in the commit object. Notably, the SHA-1s are -displayed in full, regardless of whether --abbrev or ---no-abbrev are used, and 'parents' information show the -true parent commits, without taking grafts or history -simplification into account. Note that this format affects the way -commits are displayed, but not the way the diff is shown e.g. with -`git log --raw`. To get full object names in a raw diff format, -use `--no-abbrev`. - -* 'format:<string>' -+ -The 'format:<string>' format allows you to specify which information -you want to show. It works a little bit like printf format, -with the notable exception that you get a newline with '%n' -instead of '\n'. -+ -E.g, 'format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"' -would show something like this: -+ -------- -The author of fe6e0ee was Junio C Hamano, 23 hours ago -The title was >>t4119: test autocomputing -p<n> for traditional diff input.<< - -------- -+ -The placeholders are: - -- Placeholders that expand to a single literal character: -'%n':: newline -'%%':: a raw '%' -'%x00':: print a byte from a hex code - -- Placeholders that affect formatting of later placeholders: -'%Cred':: switch color to red -'%Cgreen':: switch color to green -'%Cblue':: switch color to blue -'%Creset':: reset color -'%C(...)':: color specification, as described under Values in the - "CONFIGURATION FILE" section of linkgit:git-config[1]. By - default, colors are shown only when 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). `%C(auto,...)` is accepted as a historical - synonym for the default (e.g., `%C(auto,red)`). Specifying - `%C(always,...)` will show the colors even when color is - not otherwise enabled (though consider just using - `--color=always` to enable color for the whole output, - including this format and anything else git might color). - `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 -'%w([<w>[,<i1>[,<i2>]]])':: switch line wrapping, like the -w option of - linkgit:git-shortlog[1]. -'%<(<N>[,trunc|ltrunc|mtrunc])':: make the next placeholder take at - least N columns, padding spaces on - the right if necessary. Optionally - truncate at the beginning (ltrunc), - the middle (mtrunc) or the end - (trunc) if the output is longer than - N columns. Note that truncating - only works correctly with N >= 2. -'%<|(<N>)':: make the next placeholder take at least until Nth - columns, padding spaces on the right if necessary -'%>(<N>)', '%>|(<N>)':: similar to '%<(<N>)', '%<|(<N>)' respectively, - but padding spaces on the left -'%>>(<N>)', '%>>|(<N>)':: similar to '%>(<N>)', '%>|(<N>)' - respectively, except that if the next - placeholder takes more spaces than given and - there are spaces on its left, use those - spaces -'%><(<N>)', '%><|(<N>)':: similar to '%<(<N>)', '%<|(<N>)' - respectively, but padding both sides - (i.e. the text is centered) - -- Placeholders that expand to information extracted from the commit: -'%H':: commit hash -'%h':: abbreviated commit hash -'%T':: tree hash -'%t':: abbreviated tree hash -'%P':: parent hashes -'%p':: abbreviated parent hashes -'%an':: author name -'%aN':: author name (respecting .mailmap, see linkgit:git-shortlog[1] - or linkgit:git-blame[1]) -'%ae':: author email -'%aE':: author email (respecting .mailmap, see linkgit:git-shortlog[1] - or linkgit:git-blame[1]) -'%ad':: author date (format respects --date= option) -'%aD':: author date, RFC2822 style -'%ar':: author date, relative -'%at':: author date, UNIX timestamp -'%ai':: author date, ISO 8601-like format -'%aI':: author date, strict ISO 8601 format -'%cn':: committer name -'%cN':: committer name (respecting .mailmap, see - linkgit:git-shortlog[1] or linkgit:git-blame[1]) -'%ce':: committer email -'%cE':: committer email (respecting .mailmap, see - linkgit:git-shortlog[1] or linkgit:git-blame[1]) -'%cd':: committer date (format respects --date= option) -'%cD':: committer date, RFC2822 style -'%cr':: committer date, relative -'%ct':: committer date, UNIX timestamp -'%ci':: committer date, ISO 8601-like format -'%cI':: committer date, strict ISO 8601 format -'%d':: ref names, like the --decorate option of linkgit:git-log[1] -'%D':: ref names without the " (", ")" wrapping. -'%S':: ref name given on the command line by which the commit was reached - (like `git log --source`), only works with `git log` -'%e':: encoding -'%s':: subject -'%f':: sanitized subject line, suitable for a filename -'%b':: body -'%B':: raw body (unwrapped subject and body) -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, - "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 -'%GF':: show the fingerprint of the key used to sign a signed commit -'%GP':: show the fingerprint of the primary key whose subkey was used - to sign a signed commit -'%gD':: reflog selector, e.g., `refs/stash@{1}` or `refs/stash@{2 - minutes ago`}; the format follows the rules described for the - `-g` option. The portion before the `@` is the refname as - given on the command line (so `git log -g refs/heads/master` - would yield `refs/heads/master@{0}`). -'%gd':: shortened reflog selector; same as `%gD`, but the refname - portion is shortened for human readability (so - `refs/heads/master` becomes just `master`). -'%gn':: reflog identity name -'%gN':: reflog identity name (respecting .mailmap, see - linkgit:git-shortlog[1] or linkgit:git-blame[1]) -'%ge':: reflog identity email -'%gE':: reflog identity email (respecting .mailmap, see - linkgit:git-shortlog[1] or linkgit:git-blame[1]) -'%gs':: reflog subject -'%(trailers[:options])':: display the trailers of the body as - interpreted by - linkgit:git-interpret-trailers[1]. The - `trailers` string may be followed by a colon - and zero or more comma-separated options: -** 'key=<K>': only show trailers with specified key. Matching is done - case-insensitively and trailing colon is optional. If option is - given multiple times trailer lines matching any of the keys are - shown. This option automatically enables the `only` option so that - non-trailer lines in the trailer block are hidden. If that is not - desired it can be disabled with `only=false`. E.g., - `%(trailers:key=Reviewed-by)` shows trailer lines with key - `Reviewed-by`. -** 'only[=val]': select whether non-trailer lines from the trailer - block should be included. The `only` keyword may optionally be - followed by an equal sign and one of `true`, `on`, `yes` to omit or - `false`, `off`, `no` to show the non-trailer lines. If option is - given without value it is enabled. If given multiple times the last - value is used. -** 'separator=<SEP>': specify a separator inserted between trailer - lines. When this option is not given each trailer line is - terminated with a line feed character. The string SEP may contain - the literal formatting codes described above. To use comma as - separator one must use `%x2C` as it would otherwise be parsed as - next option. If separator option is given multiple times only the - last one is used. E.g., `%(trailers:key=Ticket,separator=%x2C )` - shows all trailer lines whose key is "Ticket" separated by a comma - and a space. -** 'unfold[=val]': make it behave as if interpret-trailer's `--unfold` - option was given. In same way as to for `only` it can be followed - by an equal sign and explicit value. E.g., - `%(trailers:only,unfold=true)` unfolds and shows all trailer lines. -** 'valueonly[=val]': skip over the key part of the trailer line and only - show the value part. Also this optionally allows explicit value. - -NOTE: Some placeholders may depend on other options given to the -revision traversal engine. For example, the `%g*` reflog options will -insert an empty string unless we are traversing reflog entries (e.g., by -`git log -g`). The `%d` and `%D` placeholders will use the "short" -decoration format if `--decorate` was not already provided on the command -line. - -If you add a `+` (plus sign) after '%' of a placeholder, a line-feed -is inserted immediately before the expansion if and only if the -placeholder expands to a non-empty string. - -If you add a `-` (minus sign) after '%' of a placeholder, all consecutive -line-feeds immediately preceding the expansion are deleted if and only if the -placeholder expands to an empty string. - -If you add a ` ` (space) after '%' of a placeholder, a space -is inserted immediately before the expansion if and only if the -placeholder expands to a non-empty string. - -* 'tformat:' -+ -The 'tformat:' format works exactly like 'format:', except that it -provides "terminator" semantics instead of "separator" semantics. In -other words, each commit has the message terminator character (usually a -newline) appended, rather than a separator placed between entries. -This means that the final entry of a single-line format will be properly -terminated with a new line, just as the "oneline" format does. -For example: -+ ---------------------- -$ git log -2 --pretty=format:%h 4da45bef \ - | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/' -4da45be -7134973 -- NO NEWLINE - -$ git log -2 --pretty=tformat:%h 4da45bef \ - | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/' -4da45be -7134973 ---------------------- -+ -In addition, any unrecognized string that has a `%` in it is interpreted -as if it has `tformat:` in front of it. For example, these two are -equivalent: -+ ---------------------- -$ git log -2 --pretty=tformat:%h 4da45bef -$ git log -2 --pretty=%h 4da45bef ---------------------- diff --git a/third_party/git/Documentation/pretty-options.txt b/third_party/git/Documentation/pretty-options.txt deleted file mode 100644 index e44fc8f738..0000000000 --- a/third_party/git/Documentation/pretty-options.txt +++ /dev/null @@ -1,96 +0,0 @@ ---pretty[=<format>]:: ---format=<format>:: - - Pretty-print the contents of the commit logs in a given format, - where '<format>' can be one of 'oneline', 'short', 'medium', - 'full', 'fuller', 'email', 'raw', 'format:<string>' - and 'tformat:<string>'. When '<format>' is none of the above, - and has '%placeholder' in it, it acts as if - '--pretty=tformat:<format>' were given. -+ -See the "PRETTY FORMATS" section for some additional details for each -format. When '=<format>' part is omitted, it defaults to 'medium'. -+ -Note: you can specify the default pretty format in the repository -configuration (see linkgit:git-config[1]). - ---abbrev-commit:: - Instead of showing the full 40-byte hexadecimal commit object - name, show only a partial prefix. Non default number of - digits can be specified with "--abbrev=<n>" (which also modifies - diff output, if it is displayed). -+ -This should make "--pretty=oneline" a whole lot more readable for -people using 80-column terminals. - ---no-abbrev-commit:: - Show the full 40-byte hexadecimal commit object name. This negates - `--abbrev-commit` and those options which imply it such as - "--oneline". It also overrides the `log.abbrevCommit` variable. - ---oneline:: - This is a shorthand for "--pretty=oneline --abbrev-commit" - used together. - ---encoding=<encoding>:: - The commit objects record the encoding used for the log message - in their encoding header; this option can be used to tell the - command to re-code the commit log message in the encoding - preferred by the user. For non plumbing commands this - defaults to UTF-8. Note that if an object claims to be encoded - in `X` and we are outputting in `X`, we will output the object - verbatim; this means that invalid sequences in the original - commit may be copied to the output. - ---expand-tabs=<n>:: ---expand-tabs:: ---no-expand-tabs:: - Perform a tab expansion (replace each tab with enough spaces - to fill to the next display column that is multiple of '<n>') - in the log message before showing it in the output. - `--expand-tabs` is a short-hand for `--expand-tabs=8`, and - `--no-expand-tabs` is a short-hand for `--expand-tabs=0`, - which disables tab expansion. -+ -By default, tabs are expanded in pretty formats that indent the log -message by 4 spaces (i.e. 'medium', which is the default, 'full', -and 'fuller'). - -ifndef::git-rev-list[] ---notes[=<treeish>]:: - Show the notes (see linkgit:git-notes[1]) that annotate the - commit, when showing the commit log message. This is the default - for `git log`, `git show` and `git whatchanged` commands when - there is no `--pretty`, `--format`, or `--oneline` option given - on the command line. -+ -By default, the notes shown are from the notes refs listed in the -`core.notesRef` and `notes.displayRef` variables (or corresponding -environment overrides). See linkgit:git-config[1] for more details. -+ -With an optional '<treeish>' argument, use the treeish to find the notes -to display. The treeish can specify the full refname when it begins -with `refs/notes/`; when it begins with `notes/`, `refs/` and otherwise -`refs/notes/` is prefixed to form a full name of the ref. -+ -Multiple --notes options can be combined to control which notes are -being displayed. Examples: "--notes=foo" will show only notes from -"refs/notes/foo"; "--notes=foo --notes" will show both notes from -"refs/notes/foo" and from the default notes ref(s). - ---no-notes:: - Do not show notes. This negates the above `--notes` option, by - resetting the list of notes refs from which notes are shown. - Options are parsed in the order given on the command line, so e.g. - "--notes --notes=foo --no-notes --notes=bar" will only show notes - from "refs/notes/bar". - ---show-notes[=<treeish>]:: ---[no-]standard-notes:: - These options are deprecated. Use the above --notes/--no-notes - options instead. -endif::git-rev-list[] - ---show-signature:: - Check the validity of a signed commit object by passing the signature - to `gpg --verify` and show the output. diff --git a/third_party/git/Documentation/pull-fetch-param.txt b/third_party/git/Documentation/pull-fetch-param.txt deleted file mode 100644 index 7d3a60f5b9..0000000000 --- a/third_party/git/Documentation/pull-fetch-param.txt +++ /dev/null @@ -1,102 +0,0 @@ -<repository>:: - The "remote" repository that is the source of a fetch - or pull operation. This parameter can be either a URL - (see the section <<URLS,GIT URLS>> below) or the name - of a remote (see the section <<REMOTES,REMOTES>> below). - -ifndef::git-pull[] -<group>:: - A name referring to a list of repositories as the value - of remotes.<group> in the configuration file. - (See linkgit:git-config[1]). -endif::git-pull[] - -<refspec>:: - Specifies which refs to fetch and which local refs to update. - When no <refspec>s appear on the command line, the refs to fetch - are read from `remote.<repository>.fetch` variables instead -ifndef::git-pull[] - (see <<CRTB,CONFIGURED REMOTE-TRACKING BRANCHES>> below). -endif::git-pull[] -ifdef::git-pull[] - (see linkgit:git-fetch[1]). -endif::git-pull[] -+ -The format of a <refspec> parameter is an optional plus -`+`, followed by the source <src>, followed -by a colon `:`, followed by the destination ref <dst>. -The colon can be omitted when <dst> is empty. <src> is -typically a ref, but it can also be a fully spelled hex object -name. -+ -`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`; -it requests fetching everything up to the given tag. -+ -The remote ref that matches <src> -is fetched, and if <dst> is not an empty string, an attempt -is made to update the local ref that matches it. -+ -Whether that update is allowed without `--force` depends on the ref -namespace it's being fetched to, the type of object being fetched, and -whether the update is considered to be a fast-forward. Generally, the -same rules apply for fetching as when pushing, see the `<refspec>...` -section of linkgit:git-push[1] for what those are. Exceptions to those -rules particular to 'git fetch' are noted below. -+ -Until Git version 2.20, and unlike when pushing with -linkgit:git-push[1], any updates to `refs/tags/*` would be accepted -without `+` in the refspec (or `--force`). When fetching, we promiscuously -considered all tag updates from a remote to be forced fetches. Since -Git version 2.20, fetching to update `refs/tags/*` works the same way -as when pushing. I.e. any updates will be rejected without `+` in the -refspec (or `--force`). -+ -Unlike when pushing with linkgit:git-push[1], any updates outside of -`refs/{tags,heads}/*` will be accepted without `+` in the refspec (or -`--force`), whether that's swapping e.g. a tree object for a blob, or -a commit for another commit that's doesn't have the previous commit as -an ancestor etc. -+ -Unlike when pushing with linkgit:git-push[1], there is no -configuration which'll amend these rules, and nothing like a -`pre-fetch` hook analogous to the `pre-receive` hook. -+ -As with pushing with linkgit:git-push[1], all of the rules described -above about what's not allowed as an update can be overridden by -adding an the optional leading `+` to a refspec (or using `--force` -command line option). The only exception to this is that no amount of -forcing will make the `refs/heads/*` namespace accept a non-commit -object. -+ -[NOTE] -When the remote branch you want to fetch is known to -be rewound and rebased regularly, it is expected that -its new tip will not be descendant of its previous tip -(as stored in your remote-tracking branch the last time -you fetched). You would want -to use the `+` sign to indicate non-fast-forward updates -will be needed for such branches. There is no way to -determine or declare that a branch will be made available -in a repository with this behavior; the pulling user simply -must know this is the expected usage pattern for a branch. -ifdef::git-pull[] -+ -[NOTE] -There is a difference between listing multiple <refspec> -directly on 'git pull' command line and having multiple -`remote.<repository>.fetch` entries in your configuration -for a <repository> and running a -'git pull' command without any explicit <refspec> parameters. -<refspec>s listed explicitly on the command line are always -merged into the current branch after fetching. In other words, -if you list more than one remote ref, 'git pull' will create -an Octopus merge. On the other hand, if you do not list any -explicit <refspec> parameter on the command line, 'git pull' -will fetch all the <refspec>s it finds in the -`remote.<repository>.fetch` configuration and merge -only the first <refspec> found into the current branch. -This is because making an -Octopus from remote refs is rarely done, while keeping track -of multiple remote heads in one-go by fetching more than one -is often useful. -endif::git-pull[] diff --git a/third_party/git/Documentation/rev-list-options.txt b/third_party/git/Documentation/rev-list-options.txt deleted file mode 100644 index fa4e70f511..0000000000 --- a/third_party/git/Documentation/rev-list-options.txt +++ /dev/null @@ -1,1005 +0,0 @@ -Commit Limiting -~~~~~~~~~~~~~~~ - -Besides specifying a range of commits that should be listed using the -special notations explained in the description, additional commit -limiting may be applied. - -Using more options generally further limits the output (e.g. -`--since=<date1>` limits to commits newer than `<date1>`, and using it -with `--grep=<pattern>` further limits to commits whose log message -has a line that matches `<pattern>`), unless otherwise noted. - -Note that these are applied before commit -ordering and formatting options, such as `--reverse`. - --<number>:: --n <number>:: ---max-count=<number>:: - Limit the number of commits to output. - ---skip=<number>:: - Skip 'number' commits before starting to show the commit output. - ---since=<date>:: ---after=<date>:: - Show commits more recent than a specific date. - ---until=<date>:: ---before=<date>:: - Show commits older than a specific date. - -ifdef::git-rev-list[] ---max-age=<timestamp>:: ---min-age=<timestamp>:: - Limit the commits output to specified time range. -endif::git-rev-list[] - ---author=<pattern>:: ---committer=<pattern>:: - Limit the commits output to ones with author/committer - header lines that match the specified pattern (regular - expression). With more than one `--author=<pattern>`, - commits whose author matches any of the given patterns are - chosen (similarly for multiple `--committer=<pattern>`). - ---grep-reflog=<pattern>:: - Limit the commits output to ones with reflog entries that - match the specified pattern (regular expression). With - more than one `--grep-reflog`, commits whose reflog message - matches any of the given patterns are chosen. It is an - error to use this option unless `--walk-reflogs` is in use. - ---grep=<pattern>:: - Limit the commits output to ones with log message that - matches the specified pattern (regular expression). With - more than one `--grep=<pattern>`, commits whose message - matches any of the given patterns are chosen (but see - `--all-match`). -ifndef::git-rev-list[] -+ -When `--show-notes` is in effect, the message from the notes is -matched as if it were part of the log message. -endif::git-rev-list[] - ---all-match:: - Limit the commits output to ones that match all given `--grep`, - instead of ones that match at least one. - ---invert-grep:: - Limit the commits output to ones with log message that do not - match the pattern specified with `--grep=<pattern>`. - --i:: ---regexp-ignore-case:: - Match the regular expression limiting patterns without regard to letter - case. - ---basic-regexp:: - Consider the limiting patterns to be basic regular expressions; - this is the default. - --E:: ---extended-regexp:: - Consider the limiting patterns to be extended regular expressions - instead of the default basic regular expressions. - --F:: ---fixed-strings:: - Consider the limiting patterns to be fixed strings (don't interpret - pattern as a regular expression). - --P:: ---perl-regexp:: - Consider the limiting patterns to be Perl-compatible regular - expressions. -+ -Support for these types of regular expressions is an optional -compile-time dependency. If Git wasn't compiled with support for them -providing this option will cause it to die. - ---remove-empty:: - Stop when a given path disappears from the tree. - ---merges:: - Print only merge commits. This is exactly the same as `--min-parents=2`. - ---no-merges:: - Do not print commits with more than one parent. This is - exactly the same as `--max-parents=1`. - ---min-parents=<number>:: ---max-parents=<number>:: ---no-min-parents:: ---no-max-parents:: - Show only commits which have at least (or at most) that many parent - commits. In particular, `--max-parents=1` is the same as `--no-merges`, - `--min-parents=2` is the same as `--merges`. `--max-parents=0` - gives all root commits and `--min-parents=3` all octopus merges. -+ -`--no-min-parents` and `--no-max-parents` reset these limits (to no limit) -again. Equivalent forms are `--min-parents=0` (any commit has 0 or more -parents) and `--max-parents=-1` (negative numbers denote no upper limit). - ---first-parent:: - Follow only the first parent commit upon seeing a merge - commit. This option can give a better overview when - viewing the evolution of a particular topic branch, - because merges into a topic branch tend to be only about - adjusting to updated upstream from time to time, and - this option allows you to ignore the individual commits - brought in to your history by such a merge. Cannot be - combined with --bisect. - ---not:: - Reverses the meaning of the '{caret}' prefix (or lack thereof) - for all following revision specifiers, up to the next `--not`. - ---all:: - Pretend as if all the refs in `refs/`, along with `HEAD`, are - listed on the command line as '<commit>'. - ---branches[=<pattern>]:: - Pretend as if all the refs in `refs/heads` are listed - on the command line as '<commit>'. If '<pattern>' is given, limit - branches to ones matching given shell glob. If pattern lacks '?', - '{asterisk}', or '[', '/{asterisk}' at the end is implied. - ---tags[=<pattern>]:: - Pretend as if all the refs in `refs/tags` are listed - on the command line as '<commit>'. If '<pattern>' is given, limit - tags to ones matching given shell glob. If pattern lacks '?', '{asterisk}', - or '[', '/{asterisk}' at the end is implied. - ---remotes[=<pattern>]:: - Pretend as if all the refs in `refs/remotes` are listed - on the command line as '<commit>'. If '<pattern>' is given, limit - remote-tracking branches to ones matching given shell glob. - If pattern lacks '?', '{asterisk}', or '[', '/{asterisk}' at the end is implied. - ---glob=<glob-pattern>:: - Pretend as if all the refs matching shell glob '<glob-pattern>' - are listed on the command line as '<commit>'. Leading 'refs/', - is automatically prepended if missing. If pattern lacks '?', '{asterisk}', - or '[', '/{asterisk}' at the end is implied. - ---exclude=<glob-pattern>:: - - Do not include refs matching '<glob-pattern>' that the next `--all`, - `--branches`, `--tags`, `--remotes`, or `--glob` would otherwise - consider. Repetitions of this option accumulate exclusion patterns - up to the next `--all`, `--branches`, `--tags`, `--remotes`, or - `--glob` option (other options or arguments do not clear - accumulated patterns). -+ -The patterns given should not begin with `refs/heads`, `refs/tags`, or -`refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`, -respectively, and they must begin with `refs/` when applied to `--glob` -or `--all`. If a trailing '/{asterisk}' is intended, it must be given -explicitly. - ---reflog:: - Pretend as if all objects mentioned by reflogs are listed on the - command line as `<commit>`. - ---alternate-refs:: - Pretend as if all objects mentioned as ref tips of alternate - repositories were listed on the command line. An alternate - repository is any repository whose object directory is specified - in `objects/info/alternates`. The set of included objects may - be modified by `core.alternateRefsCommand`, etc. See - linkgit:git-config[1]. - ---single-worktree:: - By default, all working trees will be examined by the - following options when there are more than one (see - linkgit:git-worktree[1]): `--all`, `--reflog` and - `--indexed-objects`. - This option forces them to examine the current working tree - only. - ---ignore-missing:: - Upon seeing an invalid object name in the input, pretend as if - the bad input was not given. - -ifndef::git-rev-list[] ---bisect:: - Pretend as if the bad bisection ref `refs/bisect/bad` - was listed and as if it was followed by `--not` and the good - bisection refs `refs/bisect/good-*` on the command - line. Cannot be combined with --first-parent. -endif::git-rev-list[] - ---stdin:: - In addition to the '<commit>' listed on the command - line, read them from the standard input. If a `--` separator is - seen, stop reading commits and start reading paths to limit the - result. - -ifdef::git-rev-list[] ---quiet:: - Don't print anything to standard output. This form - is primarily meant to allow the caller to - test the exit status to see if a range of objects is fully - connected (or not). It is faster than redirecting stdout - to `/dev/null` as the output does not have to be formatted. -endif::git-rev-list[] - ---cherry-mark:: - Like `--cherry-pick` (see below) but mark equivalent commits - with `=` rather than omitting them, and inequivalent ones with `+`. - ---cherry-pick:: - Omit any commit that introduces the same change as - another commit on the ``other side'' when the set of - commits are limited with symmetric difference. -+ -For example, if you have two branches, `A` and `B`, a usual way -to list all commits on only one side of them is with -`--left-right` (see the example below in the description of -the `--left-right` option). However, it shows the commits that were -cherry-picked from the other branch (for example, ``3rd on b'' may be -cherry-picked from branch A). With this option, such pairs of commits are -excluded from the output. - ---left-only:: ---right-only:: - List only commits on the respective side of a symmetric difference, - i.e. only those which would be marked `<` resp. `>` by - `--left-right`. -+ -For example, `--cherry-pick --right-only A...B` omits those -commits from `B` which are in `A` or are patch-equivalent to a commit in -`A`. In other words, this lists the `+` commits from `git cherry A B`. -More precisely, `--cherry-pick --right-only --no-merges` gives the exact -list. - ---cherry:: - A synonym for `--right-only --cherry-mark --no-merges`; useful to - limit the output to the commits on our side and mark those that - have been applied to the other side of a forked history with - `git log --cherry upstream...mybranch`, similar to - `git cherry upstream mybranch`. - --g:: ---walk-reflogs:: - Instead of walking the commit ancestry chain, walk - reflog entries from the most recent one to older ones. - When this option is used you cannot specify commits to - exclude (that is, '{caret}commit', 'commit1..commit2', - and 'commit1\...commit2' notations cannot be used). -+ -With `--pretty` format other than `oneline` (for obvious reasons), -this causes the output to have two extra lines of information -taken from the reflog. The reflog designator in the output may be shown -as `ref@{Nth}` (where `Nth` is the reverse-chronological index in the -reflog) or as `ref@{timestamp}` (with the timestamp for that entry), -depending on a few rules: -+ --- -1. If the starting point is specified as `ref@{Nth}`, show the index - format. -+ -2. If the starting point was specified as `ref@{now}`, show the - timestamp format. -+ -3. If neither was used, but `--date` was given on the command line, show - the timestamp in the format requested by `--date`. -+ -4. Otherwise, show the index format. --- -+ -Under `--pretty=oneline`, the commit message is -prefixed with this information on the same line. -This option cannot be combined with `--reverse`. -See also linkgit:git-reflog[1]. - ---merge:: - After a failed merge, show refs that touch files having a - conflict and don't exist on all heads to merge. - ---boundary:: - Output excluded boundary commits. Boundary commits are - prefixed with `-`. - -ifdef::git-rev-list[] ---use-bitmap-index:: - - Try to speed up the traversal using the pack bitmap index (if - one is available). Note that when traversing with `--objects`, - trees and blobs will not have their associated path printed. - ---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[] - -History Simplification -~~~~~~~~~~~~~~~~~~~~~~ - -Sometimes you are only interested in parts of the history, for example the -commits modifying a particular <path>. But there are two parts of -'History Simplification', one part is selecting the commits and the other -is how to do it, as there are various strategies to simplify the history. - -The following options select the commits to be shown: - -<paths>:: - Commits modifying the given <paths> are selected. - ---simplify-by-decoration:: - Commits that are referred by some branch or tag are selected. - -Note that extra commits can be shown to give a meaningful history. - -The following options affect the way the simplification is performed: - -Default mode:: - Simplifies the history to the simplest history explaining the - final state of the tree. Simplest because it prunes some side - branches if the end result is the same (i.e. merging branches - with the same content) - ---full-history:: - Same as the default mode, but does not prune some history. - ---dense:: - Only the selected commits are shown, plus some to have a - meaningful history. - ---sparse:: - All commits in the simplified history are shown. - ---simplify-merges:: - Additional option to `--full-history` to remove some needless - merges from the resulting history, as there are no selected - commits contributing to this merge. - ---ancestry-path:: - When given a range of commits to display (e.g. 'commit1..commit2' - or 'commit2 {caret}commit1'), only display commits that exist - directly on the ancestry chain between the 'commit1' and - 'commit2', i.e. commits that are both descendants of 'commit1', - and ancestors of 'commit2'. - -A more detailed explanation follows. - -Suppose you specified `foo` as the <paths>. We shall call commits -that modify `foo` !TREESAME, and the rest TREESAME. (In a diff -filtered for `foo`, they look different and equal, respectively.) - -In the following, we will always refer to the same example history to -illustrate the differences between simplification settings. We assume -that you are filtering for a file `foo` in this commit graph: ------------------------------------------------------------------------ - .-A---M---N---O---P---Q - / / / / / / - I B C D E Y - \ / / / / / - `-------------' X ------------------------------------------------------------------------ -The horizontal line of history A---Q is taken to be the first parent of -each merge. The commits are: - -* `I` is the initial commit, in which `foo` exists with contents - ``asdf'', and a file `quux` exists with contents ``quux''. Initial - commits are compared to an empty tree, so `I` is !TREESAME. - -* In `A`, `foo` contains just ``foo''. - -* `B` contains the same change as `A`. Its merge `M` is trivial and - hence TREESAME to all parents. - -* `C` does not change `foo`, but its merge `N` changes it to ``foobar'', - so it is not TREESAME to any parent. - -* `D` sets `foo` to ``baz''. Its merge `O` combines the strings from - `N` and `D` to ``foobarbaz''; i.e., it is not TREESAME to any parent. - -* `E` changes `quux` to ``xyzzy'', and its merge `P` combines the - strings to ``quux xyzzy''. `P` is TREESAME to `O`, but not to `E`. - -* `X` is an independent root commit that added a new file `side`, and `Y` - modified it. `Y` is TREESAME to `X`. Its merge `Q` added `side` to `P`, and - `Q` is TREESAME to `P`, but not to `Y`. - -`rev-list` walks backwards through history, including or excluding -commits based on whether `--full-history` and/or parent rewriting -(via `--parents` or `--children`) are used. The following settings -are available. - -Default mode:: - Commits are included if they are not TREESAME to any parent - (though this can be changed, see `--sparse` below). If the - commit was a merge, and it was TREESAME to one parent, follow - only that parent. (Even if there are several TREESAME - parents, follow only one of them.) Otherwise, follow all - parents. -+ -This results in: -+ ------------------------------------------------------------------------ - .-A---N---O - / / / - I---------D ------------------------------------------------------------------------ -+ -Note how the rule to only follow the TREESAME parent, if one is -available, removed `B` from consideration entirely. `C` was -considered via `N`, but is TREESAME. Root commits are compared to an -empty tree, so `I` is !TREESAME. -+ -Parent/child relations are only visible with `--parents`, but that does -not affect the commits selected in default mode, so we have shown the -parent lines. - ---full-history without parent rewriting:: - This mode differs from the default in one point: always follow - all parents of a merge, even if it is TREESAME to one of them. - Even if more than one side of the merge has commits that are - included, this does not imply that the merge itself is! In - the example, we get -+ ------------------------------------------------------------------------ - I A B N D O P Q ------------------------------------------------------------------------ -+ -`M` was excluded because it is TREESAME to both parents. `E`, -`C` and `B` were all walked, but only `B` was !TREESAME, so the others -do not appear. -+ -Note that without parent rewriting, it is not really possible to talk -about the parent/child relationships between the commits, so we show -them disconnected. - ---full-history with parent rewriting:: - Ordinary commits are only included if they are !TREESAME - (though this can be changed, see `--sparse` below). -+ -Merges are always included. However, their parent list is rewritten: -Along each parent, prune away commits that are not included -themselves. This results in -+ ------------------------------------------------------------------------ - .-A---M---N---O---P---Q - / / / / / - I B / D / - \ / / / / - `-------------' ------------------------------------------------------------------------ -+ -Compare to `--full-history` without rewriting above. Note that `E` -was pruned away because it is TREESAME, but the parent list of P was -rewritten to contain `E`'s parent `I`. The same happened for `C` and -`N`, and `X`, `Y` and `Q`. - -In addition to the above settings, you can change whether TREESAME -affects inclusion: - ---dense:: - Commits that are walked are included if they are not TREESAME - to any parent. - ---sparse:: - All commits that are walked are included. -+ -Note that without `--full-history`, this still simplifies merges: if -one of the parents is TREESAME, we follow only that one, so the other -sides of the merge are never walked. - ---simplify-merges:: - First, build a history graph in the same way that - `--full-history` with parent rewriting does (see above). -+ -Then simplify each commit `C` to its replacement `C'` in the final -history according to the following rules: -+ --- -* Set `C'` to `C`. -+ -* Replace each parent `P` of `C'` with its simplification `P'`. In - the process, drop parents that are ancestors of other parents or that are - root commits TREESAME to an empty tree, and remove duplicates, but take care - to never drop all parents that we are TREESAME to. -+ -* If after this parent rewriting, `C'` is a root or merge commit (has - zero or >1 parents), a boundary commit, or !TREESAME, it remains. - Otherwise, it is replaced with its only parent. --- -+ -The effect of this is best shown by way of comparing to -`--full-history` with parent rewriting. The example turns into: -+ ------------------------------------------------------------------------ - .-A---M---N---O - / / / - I B D - \ / / - `---------' ------------------------------------------------------------------------ -+ -Note the major differences in `N`, `P`, and `Q` over `--full-history`: -+ --- -* `N`'s parent list had `I` removed, because it is an ancestor of the - other parent `M`. Still, `N` remained because it is !TREESAME. -+ -* `P`'s parent list similarly had `I` removed. `P` was then - removed completely, because it had one parent and is TREESAME. -+ -* `Q`'s parent list had `Y` simplified to `X`. `X` was then removed, because it - was a TREESAME root. `Q` was then removed completely, because it had one - parent and is TREESAME. --- - -Finally, there is a fifth simplification mode available: - ---ancestry-path:: - Limit the displayed commits to those directly on the ancestry - chain between the ``from'' and ``to'' commits in the given commit - range. I.e. only display commits that are ancestor of the ``to'' - commit and descendants of the ``from'' commit. -+ -As an example use case, consider the following commit history: -+ ------------------------------------------------------------------------ - D---E-------F - / \ \ - B---C---G---H---I---J - / \ - A-------K---------------L--M ------------------------------------------------------------------------ -+ -A regular 'D..M' computes the set of commits that are ancestors of `M`, -but excludes the ones that are ancestors of `D`. This is useful to see -what happened to the history leading to `M` since `D`, in the sense -that ``what does `M` have that did not exist in `D`''. The result in this -example would be all the commits, except `A` and `B` (and `D` itself, -of course). -+ -When we want to find out what commits in `M` are contaminated with the -bug introduced by `D` and need fixing, however, we might want to view -only the subset of 'D..M' that are actually descendants of `D`, i.e. -excluding `C` and `K`. This is exactly what the `--ancestry-path` -option does. Applied to the 'D..M' range, it results in: -+ ------------------------------------------------------------------------ - E-------F - \ \ - G---H---I---J - \ - L--M ------------------------------------------------------------------------ - -The `--simplify-by-decoration` option allows you to view only the -big picture of the topology of the history, by omitting commits -that are not referenced by tags. Commits are marked as !TREESAME -(in other words, kept after history simplification rules described -above) if (1) they are referenced by tags, or (2) they change the -contents of the paths given on the command line. All other -commits are marked as TREESAME (subject to be simplified away). - -ifdef::git-rev-list[] -Bisection Helpers -~~~~~~~~~~~~~~~~~ - ---bisect:: - Limit output to the one commit object which is roughly halfway between - included and excluded commits. Note that the bad bisection ref - `refs/bisect/bad` is added to the included commits (if it - exists) and the good bisection refs `refs/bisect/good-*` are - added to the excluded commits (if they exist). Thus, supposing there - are no refs in `refs/bisect/`, if -+ ------------------------------------------------------------------------ - $ git rev-list --bisect foo ^bar ^baz ------------------------------------------------------------------------ -+ -outputs 'midpoint', the output of the two commands -+ ------------------------------------------------------------------------ - $ git rev-list foo ^midpoint - $ git rev-list midpoint ^bar ^baz ------------------------------------------------------------------------ -+ -would be of roughly the same length. Finding the change which -introduces a regression is thus reduced to a binary search: repeatedly -generate and test new 'midpoint's until the commit chain is of length -one. Cannot be combined with --first-parent. - ---bisect-vars:: - This calculates the same as `--bisect`, except that refs in - `refs/bisect/` are not used, and except that this outputs - text ready to be eval'ed by the shell. These lines will assign the - name of the midpoint revision to the variable `bisect_rev`, and the - expected number of commits to be tested after `bisect_rev` is tested - to `bisect_nr`, the expected number of commits to be tested if - `bisect_rev` turns out to be good to `bisect_good`, the expected - number of commits to be tested if `bisect_rev` turns out to be bad to - `bisect_bad`, and the number of commits we are bisecting right now to - `bisect_all`. - ---bisect-all:: - This outputs all the commit objects between the included and excluded - commits, ordered by their distance to the included and excluded - commits. Refs in `refs/bisect/` are not used. The farthest - from them is displayed first. (This is the only one displayed by - `--bisect`.) -+ -This is useful because it makes it easy to choose a good commit to -test when you want to avoid to test some of them for some reason (they -may not compile for example). -+ -This option can be used along with `--bisect-vars`, in this case, -after all the sorted commit objects, there will be the same text as if -`--bisect-vars` had been used alone. -endif::git-rev-list[] - - -Commit Ordering -~~~~~~~~~~~~~~~ - -By default, the commits are shown in reverse chronological order. - ---date-order:: - Show no parents before all of its children are shown, but - otherwise show commits in the commit timestamp order. - ---author-date-order:: - Show no parents before all of its children are shown, but - otherwise show commits in the author timestamp order. - ---topo-order:: - Show no parents before all of its children are shown, and - avoid showing commits on multiple lines of history - intermixed. -+ -For example, in a commit history like this: -+ ----------------------------------------------------------------- - - ---1----2----4----7 - \ \ - 3----5----6----8--- - ----------------------------------------------------------------- -+ -where the numbers denote the order of commit timestamps, `git -rev-list` and friends with `--date-order` show the commits in the -timestamp order: 8 7 6 5 4 3 2 1. -+ -With `--topo-order`, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5 -3 1); some older commits are shown before newer ones in order to -avoid showing the commits from two parallel development track mixed -together. - ---reverse:: - Output the commits chosen to be shown (see Commit Limiting - section above) in reverse order. Cannot be combined with - `--walk-reflogs`. - -Object Traversal -~~~~~~~~~~~~~~~~ - -These options are mostly targeted for packing of Git repositories. - -ifdef::git-rev-list[] ---objects:: - Print the object IDs of any object referenced by the listed - commits. `--objects foo ^bar` thus means ``send me - all object IDs which I need to download if I have the commit - object _bar_ but not _foo_''. - ---in-commit-order:: - Print tree and blob ids in order of the commits. The tree - and blob ids are printed after they are first referenced - by a commit. - ---objects-edge:: - Similar to `--objects`, but also print the IDs of excluded - commits prefixed with a ``-'' character. This is used by - linkgit:git-pack-objects[1] to build a ``thin'' pack, which records - objects in deltified form based on objects contained in these - excluded commits to reduce network traffic. - ---objects-edge-aggressive:: - Similar to `--objects-edge`, but it tries harder to find excluded - commits at the cost of increased time. This is used instead of - `--objects-edge` to build ``thin'' packs for shallow repositories. - ---indexed-objects:: - Pretend as if all trees and blobs used by the index are listed - on the command line. Note that you probably want to use - `--objects`, too. - ---unpacked:: - Only useful with `--objects`; print the object IDs that are not - in packs. - ---object-names:: - Only useful with `--objects`; print the names of the object IDs - that are found. This is the default behavior. - ---no-object-names:: - Only useful with `--objects`; does not print the names of the object - IDs that are found. This inverts `--object-names`. This flag allows - the output to be more easily parsed by commands such as - linkgit:git-cat-file[1]. - ---filter=<filter-spec>:: - Only useful with one of the `--objects*`; omits objects (usually - blobs) from the list of printed objects. The '<filter-spec>' - may be one of the following: -+ -The form '--filter=blob:none' omits all blobs. -+ -The form '--filter=blob:limit=<n>[kmg]' omits blobs larger than n bytes -or units. n may be zero. The suffixes k, m, and g can be used to name -units in KiB, MiB, or GiB. For example, 'blob:limit=1k' is the same -as 'blob:limit=1024'. -+ -The form '--filter=sparse:oid=<blob-ish>' uses a sparse-checkout -specification contained in the blob (or blob-expression) '<blob-ish>' -to omit blobs that would not be not required for a sparse checkout on -the requested refs. -+ -The form '--filter=tree:<depth>' omits all blobs and trees whose depth -from the root tree is >= <depth> (minimum depth if an object is located -at multiple depths in the commits traversed). <depth>=0 will not include -any trees or blobs unless included explicitly in the command-line (or -standard input when --stdin is used). <depth>=1 will include only the -tree and blobs which are referenced directly by a commit reachable from -<commit> or an explicitly-given object. <depth>=2 is like <depth>=1 -while also including trees and blobs one more level removed from an -explicitly-given commit or tree. -+ -Note that the form '--filter=sparse:path=<path>' that wants to read -from an arbitrary path on the filesystem has been dropped for security -reasons. - ---no-filter:: - Turn off any previous `--filter=` argument. - ---filter-print-omitted:: - Only useful with `--filter=`; prints a list of the objects omitted - by the filter. Object IDs are prefixed with a ``~'' character. - ---missing=<missing-action>:: - A debug option to help with future "partial clone" development. - This option specifies how missing objects are handled. -+ -The form '--missing=error' requests that rev-list stop with an error if -a missing object is encountered. This is the default action. -+ -The form '--missing=allow-any' will allow object traversal to continue -if a missing object is encountered. Missing objects will silently be -omitted from the results. -+ -The form '--missing=allow-promisor' is like 'allow-any', but will only -allow object traversal to continue for EXPECTED promisor missing objects. -Unexpected missing objects will raise an error. -+ -The form '--missing=print' is like 'allow-any', but will also print a -list of the missing objects. Object IDs are prefixed with a ``?'' character. - ---exclude-promisor-objects:: - (For internal use only.) Prefilter object traversal at - promisor boundary. This is used with partial clone. This is - stronger than `--missing=allow-promisor` because it limits the - traversal, rather than just silencing errors about missing - objects. -endif::git-rev-list[] - ---no-walk[=(sorted|unsorted)]:: - Only show the given commits, but do not traverse their ancestors. - This has no effect if a range is specified. If the argument - `unsorted` is given, the commits are shown in the order they were - given on the command line. Otherwise (if `sorted` or no argument - was given), the commits are shown in reverse chronological order - by commit time. - Cannot be combined with `--graph`. - ---do-walk:: - Overrides a previous `--no-walk`. - -Commit Formatting -~~~~~~~~~~~~~~~~~ - -ifdef::git-rev-list[] -Using these options, linkgit:git-rev-list[1] will act similar to the -more specialized family of commit log tools: linkgit:git-log[1], -linkgit:git-show[1], and linkgit:git-whatchanged[1] -endif::git-rev-list[] - -include::pretty-options.txt[] - ---relative-date:: - Synonym for `--date=relative`. - ---date=<format>:: - Only takes effect for dates shown in human-readable format, such - as when using `--pretty`. `log.date` config variable sets a default - value for the log command's `--date` option. By default, dates - are shown in the original time zone (either committer's or - author's). If `-local` is appended to the format (e.g., - `iso-local`), the user's local time zone is used instead. -+ --- -`--date=relative` shows dates relative to the current time, -e.g. ``2 hours ago''. The `-local` option has no effect for -`--date=relative`. - -`--date=local` is an alias for `--date=default-local`. - -`--date=iso` (or `--date=iso8601`) shows timestamps in a ISO 8601-like format. -The differences to the strict ISO 8601 format are: - - - a space instead of the `T` date/time delimiter - - a space between time and time zone - - no colon between hours and minutes of the time zone - -`--date=iso-strict` (or `--date=iso8601-strict`) shows timestamps in strict -ISO 8601 format. - -`--date=rfc` (or `--date=rfc2822`) shows timestamps in RFC 2822 -format, often found in email messages. - -`--date=short` shows only the date, but not the time, in `YYYY-MM-DD` format. - -`--date=raw` shows the date as seconds since the epoch (1970-01-01 -00:00:00 UTC), followed by a space, and then the timezone as an offset -from UTC (a `+` or `-` with four digits; the first two are hours, and -the second two are minutes). I.e., as if the timestamp were formatted -with `strftime("%s %z")`). -Note that the `-local` option does not affect the seconds-since-epoch -value (which is always measured in UTC), but does switch the accompanying -timezone value. - -`--date=human` shows the timezone if the timezone does not match the -current time-zone, and doesn't print the whole date if that matches -(ie skip printing year for dates that are "this year", but also skip -the whole date itself if it's in the last few days and we can just say -what weekday it was). For older dates the hour and minute is also -omitted. - -`--date=unix` shows the date as a Unix epoch timestamp (seconds since -1970). As with `--raw`, this is always in UTC and therefore `-local` -has no effect. - -`--date=dottime` shows the date in dottime format (rendered as UTC, -but suffixed with the local timezone offset if given) - -`--date=format:...` feeds the format `...` to your system `strftime`, -except for %z and %Z, which are handled internally. -Use `--date=format:%c` to show the date in your system locale's -preferred format. See the `strftime` manual for a complete list of -format placeholders. When using `-local`, the correct syntax is -`--date=format-local:...`. - -`--date=default` is the default format, and is similar to -`--date=rfc2822`, with a few exceptions: --- - - there is no comma after the day-of-week - - - the time zone is omitted when the local time zone is used - -ifdef::git-rev-list[] ---header:: - Print the contents of the commit in raw-format; each record is - separated with a NUL character. -endif::git-rev-list[] - ---parents:: - Print also the parents of the commit (in the form "commit parent..."). - Also enables parent rewriting, see 'History Simplification' above. - ---children:: - Print also the children of the commit (in the form "commit child..."). - Also enables parent rewriting, see 'History Simplification' above. - -ifdef::git-rev-list[] ---timestamp:: - Print the raw commit timestamp. -endif::git-rev-list[] - ---left-right:: - 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 `-`. -+ -For example, if you have this topology: -+ ------------------------------------------------------------------------ - y---b---b branch B - / \ / - / . - / / \ - o---x---a---a branch A ------------------------------------------------------------------------ -+ -you would get an output like this: -+ ------------------------------------------------------------------------ - $ git rev-list --left-right --boundary --pretty=oneline A...B - - >bbbbbbb... 3rd on b - >bbbbbbb... 2nd on b - <aaaaaaa... 3rd on a - <aaaaaaa... 2nd on a - -yyyyyyy... 1st on b - -xxxxxxx... 1st on a ------------------------------------------------------------------------ - ---graph:: - Draw a text-based graphical representation of the commit history - on the left hand side of the output. This may cause extra lines - to be printed in between commits, in order for the graph history - to be drawn properly. - Cannot be combined with `--no-walk`. -+ -This enables parent rewriting, see 'History Simplification' above. -+ -This implies the `--topo-order` option by default, but the -`--date-order` option may also be specified. - ---show-linear-break[=<barrier>]:: - When --graph is not used, all history branches are flattened - which can make it hard to see that the two consecutive commits - do not belong to a linear branch. This option puts a barrier - in between them in that case. If `<barrier>` is specified, it - is the string that will be shown instead of the default one. - -ifdef::git-rev-list[] ---count:: - Print a number stating how many commits would have been - listed, and suppress all other output. When used together - with `--left-right`, instead print the counts for left and - right commits, separated by a tab. When used together with - `--cherry-mark`, omit patch equivalent commits from these - counts and print the count for equivalent commits separated - by a tab. -endif::git-rev-list[] - -ifndef::git-rev-list[] -Diff Formatting -~~~~~~~~~~~~~~~ - -Listed below are options that control the formatting of diff output. -Some of them are specific to linkgit:git-rev-list[1], however other diff -options may be given. See linkgit:git-diff-files[1] for more options. - --c:: - With this option, diff output for a merge commit - shows the differences from each of the parents to the merge result - simultaneously instead of showing pairwise diff between a parent - and the result one at a time. Furthermore, it lists only files - which were modified from all parents. - ---cc:: - This flag implies the `-c` option and further compresses the - patch output by omitting uninteresting hunks whose contents in - the parents have only two variants and the merge result picks - one of them without modification. - ---combined-all-paths:: - This flag causes combined diffs (used for merge commits) to - list the name of the file from all parents. It thus only has - effect when -c or --cc are specified, and is likely only - useful if filename changes are detected (i.e. when either - rename or copy detection have been requested). - --m:: - This flag makes the merge commits show the full diff like - regular commits; for each merge parent, a separate log entry - and diff is generated. An exception is that only diff against - the first parent is shown when `--first-parent` option is given; - in that case, the output represents the changes the merge - brought _into_ the then-current branch. - --r:: - Show recursive diffs. - --t:: - Show the tree objects in the diff output. This implies `-r`. -endif::git-rev-list[] diff --git a/third_party/git/Documentation/revisions.txt b/third_party/git/Documentation/revisions.txt deleted file mode 100644 index 97f995e5a9..0000000000 --- a/third_party/git/Documentation/revisions.txt +++ /dev/null @@ -1,377 +0,0 @@ -SPECIFYING REVISIONS --------------------- - -A revision parameter '<rev>' typically, but not necessarily, names a -commit object. It uses what is called an 'extended SHA-1' -syntax. Here are various ways to spell object names. The -ones listed near the end of this list name trees and -blobs contained in a commit. - -NOTE: This document shows the "raw" syntax as seen by git. The shell -and other UIs might require additional quoting to protect special -characters and to avoid word splitting. - -'<sha1>', e.g. 'dae86e1950b1277e545cee180551750029cfe735', 'dae86e':: - The full SHA-1 object name (40-byte hexadecimal string), or - a leading substring that is unique within the repository. - E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both - name the same commit object if there is no other object in - your repository whose object name starts with dae86e. - -'<describeOutput>', e.g. 'v1.7.4.2-679-g3bee7fb':: - Output from `git describe`; i.e. a closest tag, optionally - followed by a dash and a number of commits, followed by a dash, a - 'g', and an abbreviated object name. - -'<refname>', e.g. 'master', 'heads/master', 'refs/heads/master':: - A symbolic ref name. E.g. 'master' typically means the commit - object referenced by 'refs/heads/master'. If you - happen to have both 'heads/master' and 'tags/master', you can - explicitly say 'heads/master' to tell Git which one you mean. - When ambiguous, a '<refname>' is disambiguated by taking the - first match in the following rules: - - . If '$GIT_DIR/<refname>' exists, that is what you mean (this is usually - useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD`, `MERGE_HEAD` - and `CHERRY_PICK_HEAD`); - - . otherwise, 'refs/<refname>' if it exists; - - . otherwise, 'refs/tags/<refname>' if it exists; - - . otherwise, 'refs/heads/<refname>' if it exists; - - . otherwise, 'refs/remotes/<refname>' if it exists; - - . otherwise, 'refs/remotes/<refname>/HEAD' if it exists. -+ -`HEAD` names the commit on which you based the changes in the working tree. -`FETCH_HEAD` records the branch which you fetched from a remote repository -with your last `git fetch` invocation. -`ORIG_HEAD` is created by commands that move your `HEAD` in a drastic -way, to record the position of the `HEAD` before their operation, so that -you can easily change the tip of the branch back to the state before you ran -them. -`MERGE_HEAD` records the commit(s) which you are merging into your branch -when you run `git merge`. -`CHERRY_PICK_HEAD` records the commit which you are cherry-picking -when you run `git cherry-pick`. -+ -Note that any of the 'refs/*' cases above may come either from -the `$GIT_DIR/refs` directory or from the `$GIT_DIR/packed-refs` file. -While the ref name encoding is unspecified, UTF-8 is preferred as -some output processing may assume ref names in UTF-8. - -'@':: - '@' alone is a shortcut for `HEAD`. - -'[<refname>]@{<date>}', e.g. 'master@\{yesterday\}', 'HEAD@{5 minutes ago}':: - A ref followed by the suffix '@' with a date specification - enclosed in a brace - pair (e.g. '\{yesterday\}', '{1 month 2 weeks 3 days 1 hour 1 - second ago}' or '{1979-02-26 18:30:00}') specifies the value - of the ref at a prior point in time. This suffix may only be - used immediately following a ref name and the ref must have an - existing log ('$GIT_DIR/logs/<ref>'). Note that this looks up the state - of your *local* ref at a given time; e.g., what was in your local - 'master' branch last week. If you want to look at commits made during - certain times, see `--since` and `--until`. - -'<refname>@{<n>}', e.g. 'master@\{1\}':: - A ref followed by the suffix '@' with an ordinal specification - enclosed in a brace pair (e.g. '\{1\}', '\{15\}') specifies - the n-th prior value of that ref. For example 'master@\{1\}' - is the immediate prior value of 'master' while 'master@\{5\}' - is the 5th prior value of 'master'. This suffix may only be used - immediately following a ref name and the ref must have an existing - log ('$GIT_DIR/logs/<refname>'). - -'@{<n>}', e.g. '@\{1\}':: - You can use the '@' construct with an empty ref part to get at a - reflog entry of the current branch. For example, if you are on - branch 'blabla' then '@\{1\}' means the same as 'blabla@\{1\}'. - -'@{-<n>}', e.g. '@{-1}':: - The construct '@{-<n>}' means the <n>th branch/commit checked out - before the current one. - -'[<branchname>]@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}':: - The suffix '@\{upstream\}' to a branchname (short form '<branchname>@\{u\}') - refers to the branch that the branch specified by branchname is set to build on - top of (configured with `branch.<name>.remote` and - `branch.<name>.merge`). A missing branchname defaults to the - current one. These suffixes are also accepted when spelled in uppercase, and - they mean the same thing no matter the case. - -'[<branchname>]@\{push\}', e.g. 'master@\{push\}', '@\{push\}':: - The suffix '@\{push}' reports the branch "where we would push to" if - `git push` were run while `branchname` was checked out (or the current - `HEAD` if no branchname is specified). Since our push destination is - in a remote repository, of course, we report the local tracking branch - that corresponds to that branch (i.e., something in `refs/remotes/`). -+ -Here's an example to make it more clear: -+ ------------------------------- -$ git config push.default current -$ git config remote.pushdefault myfork -$ git switch -c mybranch origin/master - -$ git rev-parse --symbolic-full-name @{upstream} -refs/remotes/origin/master - -$ git rev-parse --symbolic-full-name @{push} -refs/remotes/myfork/mybranch ------------------------------- -+ -Note in the example that we set up a triangular workflow, where we pull -from one location and push to another. In a non-triangular workflow, -'@\{push}' is the same as '@\{upstream}', and there is no need for it. -+ -This suffix is also accepted when spelled in uppercase, and means the same -thing no matter the case. - -'<rev>{caret}[<n>]', e.g. 'HEAD{caret}, v1.5.1{caret}0':: - A suffix '{caret}' to a revision parameter means the first parent of - that commit object. '{caret}<n>' means the <n>th parent (i.e. - '<rev>{caret}' - is equivalent to '<rev>{caret}1'). As a special rule, - '<rev>{caret}0' means the commit itself and is used when '<rev>' is the - object name of a tag object that refers to a commit object. - -'<rev>{tilde}[<n>]', e.g. 'HEAD{tilde}, master{tilde}3':: - A suffix '{tilde}' to a revision parameter means the first parent of - that commit object. - A suffix '{tilde}<n>' to a revision parameter means the commit - object that is the <n>th generation ancestor of the named - commit object, following only the first parents. I.e. '<rev>{tilde}3' is - equivalent to '<rev>{caret}{caret}{caret}' which is equivalent to - '<rev>{caret}1{caret}1{caret}1'. See below for an illustration of - the usage of this form. - -'<rev>{caret}{<type>}', e.g. 'v0.99.8{caret}\{commit\}':: - A suffix '{caret}' followed by an object type name enclosed in - brace pair means dereference the object at '<rev>' recursively until - an object of type '<type>' is found or the object cannot be - dereferenced anymore (in which case, barf). - For example, if '<rev>' is a commit-ish, '<rev>{caret}\{commit\}' - describes the corresponding commit object. - Similarly, if '<rev>' is a tree-ish, '<rev>{caret}\{tree\}' - describes the corresponding tree object. - '<rev>{caret}0' - is a short-hand for '<rev>{caret}\{commit\}'. -+ -'<rev>{caret}\{object\}' can be used to make sure '<rev>' names an -object that exists, without requiring '<rev>' to be a tag, and -without dereferencing '<rev>'; because a tag is already an object, -it does not have to be dereferenced even once to get to an object. -+ -'<rev>{caret}\{tag\}' can be used to ensure that '<rev>' identifies an -existing tag object. - -'<rev>{caret}{}', e.g. 'v0.99.8{caret}{}':: - A suffix '{caret}' followed by an empty brace pair - means the object could be a tag, - and dereference the tag recursively until a non-tag object is - found. - -'<rev>{caret}{/<text>}', e.g. 'HEAD^{/fix nasty bug}':: - A suffix '{caret}' to a revision parameter, followed by a brace - pair that contains a text led by a slash, - is the same as the ':/fix nasty bug' syntax below except that - it returns the youngest matching commit which is reachable from - the '<rev>' before '{caret}'. - -':/<text>', e.g. ':/fix nasty bug':: - A colon, followed by a slash, followed by a text, names - a commit whose commit message matches the specified regular expression. - This name returns the youngest matching commit which is - reachable from any ref, including HEAD. - The regular expression can match any part of the - commit message. To match messages starting with a string, one can use - e.g. ':/^foo'. The special sequence ':/!' is reserved for modifiers to what - is matched. ':/!-foo' performs a negative match, while ':/!!foo' matches a - literal '!' character, followed by 'foo'. Any other sequence beginning with - ':/!' is reserved for now. - Depending on the given text, the shell's word splitting rules might - require additional quoting. - -'<rev>:<path>', e.g. 'HEAD:README', 'master:./README':: - A suffix ':' followed by a path names the blob or tree - at the given path in the tree-ish object named by the part - before the colon. - A path starting with './' or '../' is relative to the current working directory. - The given path will be converted to be relative to the working tree's root directory. - This is most useful to address a blob or tree from a commit or tree that has - the same tree structure as the working tree. - -':[<n>:]<path>', e.g. ':0:README', ':README':: - A colon, optionally followed by a stage number (0 to 3) and a - colon, followed by a path, names a blob object in the - index at the given path. A missing stage number (and the colon - that follows it) names a stage 0 entry. During a merge, stage - 1 is the common ancestor, stage 2 is the target branch's version - (typically the current branch), and stage 3 is the version from - the branch which is being merged. - -Here is an illustration, by Jon Loeliger. Both commit nodes B -and C are parents of commit node A. Parent commits are ordered -left-to-right. - -........................................ -G H I J - \ / \ / - D E F - \ | / \ - \ | / | - \|/ | - B C - \ / - \ / - A -........................................ - - A = = A^0 - B = A^ = A^1 = A~1 - C = A^2 = A^2 - D = A^^ = A^1^1 = A~2 - E = B^2 = A^^2 - F = B^3 = A^^3 - G = A^^^ = A^1^1^1 = A~3 - H = D^2 = B^^2 = A^^^2 = A~2^2 - I = F^ = B^3^ = A^^3^ - J = F^2 = B^3^2 = A^^3^2 - - -SPECIFYING RANGES ------------------ - -History traversing commands such as `git log` operate on a set -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. - -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'. - -Revision Range Summary ----------------------- - -'<rev>':: - Include commits that are reachable from <rev> (i.e. <rev> and its - ancestors). - -'{caret}<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 - those that are reachable from <rev1>. When either <rev1> or - <rev2> is omitted, it defaults to `HEAD`. - -'<rev1>\...<rev2>':: - Include commits that are reachable from either <rev1> or - <rev2> but exclude those that are reachable from both. When - either <rev1> or <rev2> is omitted, it defaults to `HEAD`. - -'<rev>{caret}@', e.g. 'HEAD{caret}@':: - A suffix '{caret}' followed by an at sign is the same as listing - all parents of '<rev>' (meaning, include anything reachable from - its parents, but not the commit itself). - -'<rev>{caret}!', e.g. 'HEAD{caret}!':: - A suffix '{caret}' followed by an exclamation mark is the same - as giving commit '<rev>' and then all its parents prefixed with - '{caret}' to exclude them (and their ancestors). - -'<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/third_party/git/Documentation/sequencer.txt b/third_party/git/Documentation/sequencer.txt deleted file mode 100644 index 3bceb56474..0000000000 --- a/third_party/git/Documentation/sequencer.txt +++ /dev/null @@ -1,16 +0,0 @@ ---continue:: - Continue the operation in progress using the information in - `.git/sequencer`. Can be used to continue after resolving - conflicts in a failed cherry-pick or revert. - ---skip:: - Skip the current commit and continue with the rest of the - sequence. - ---quit:: - Forget about the current operation in progress. Can be used - to clear the sequencer state after a failed cherry-pick or - revert. - ---abort:: - Cancel the operation and return to the pre-sequence state. diff --git a/third_party/git/Documentation/technical/.gitignore b/third_party/git/Documentation/technical/.gitignore deleted file mode 100644 index 8aa891daee..0000000000 --- a/third_party/git/Documentation/technical/.gitignore +++ /dev/null @@ -1 +0,0 @@ -api-index.txt diff --git a/third_party/git/Documentation/technical/api-allocation-growing.txt b/third_party/git/Documentation/technical/api-allocation-growing.txt deleted file mode 100644 index 5a59b54844..0000000000 --- a/third_party/git/Documentation/technical/api-allocation-growing.txt +++ /dev/null @@ -1,39 +0,0 @@ -allocation growing API -====================== - -Dynamically growing an array using realloc() is error prone and boring. - -Define your array with: - -* a pointer (`item`) that points at the array, initialized to `NULL` - (although please name the variable based on its contents, not on its - type); - -* an integer variable (`alloc`) that keeps track of how big the current - allocation is, initialized to `0`; - -* another integer variable (`nr`) to keep track of how many elements the - array currently has, initialized to `0`. - -Then before adding `n`th element to the item, call `ALLOC_GROW(item, n, -alloc)`. This ensures that the array can hold at least `n` elements by -calling `realloc(3)` and adjusting `alloc` variable. - ------------- -sometype *item; -size_t nr; -size_t alloc - -for (i = 0; i < nr; i++) - if (we like item[i] already) - return; - -/* we did not like any existing one, so add one */ -ALLOC_GROW(item, nr + 1, alloc); -item[nr++] = value you like; ------------- - -You are responsible for updating the `nr` variable. - -If you need to specify the number of elements to allocate explicitly -then use the macro `REALLOC_ARRAY(item, alloc)` instead of `ALLOC_GROW`. diff --git a/third_party/git/Documentation/technical/api-argv-array.txt b/third_party/git/Documentation/technical/api-argv-array.txt deleted file mode 100644 index 870c8edbfb..0000000000 --- a/third_party/git/Documentation/technical/api-argv-array.txt +++ /dev/null @@ -1,65 +0,0 @@ -argv-array API -============== - -The argv-array API allows one to dynamically build and store -NULL-terminated lists. An argv-array maintains the invariant that the -`argv` member always points to a non-NULL array, and that the array is -always NULL-terminated at the element pointed to by `argv[argc]`. This -makes the result suitable for passing to functions expecting to receive -argv from main(), or the link:api-run-command.html[run-command API]. - -The string-list API (documented in string-list.h) is similar, but cannot be -used for these purposes; instead of storing a straight string pointer, -it contains an item structure with a `util` field that is not compatible -with the traditional argv interface. - -Each `argv_array` manages its own memory. Any strings pushed into the -array are duplicated, and all memory is freed by argv_array_clear(). - -Data Structures ---------------- - -`struct argv_array`:: - - A single array. This should be initialized by assignment from - `ARGV_ARRAY_INIT`, or by calling `argv_array_init`. The `argv` - member contains the actual array; the `argc` member contains the - number of elements in the array, not including the terminating - NULL. - -Functions ---------- - -`argv_array_init`:: - Initialize an array. This is no different than assigning from - `ARGV_ARRAY_INIT`. - -`argv_array_push`:: - Push a copy of a string onto the end of the array. - -`argv_array_pushl`:: - Push a list of strings onto the end of the array. The arguments - should be a list of `const char *` strings, terminated by a NULL - argument. - -`argv_array_pushf`:: - Format a string and push it onto the end of the array. This is a - convenience wrapper combining `strbuf_addf` and `argv_array_push`. - -`argv_array_pushv`:: - Push a null-terminated array of strings onto the end of the array. - -`argv_array_pop`:: - Remove the final element from the array. If there are no - elements in the array, do nothing. - -`argv_array_clear`:: - Free all memory associated with the array and return it to the - initial, empty state. - -`argv_array_detach`:: - Disconnect the `argv` member from the `argv_array` struct and - return it. The caller is responsible for freeing the memory used - by the array, and by the strings it references. After detaching, - the `argv_array` is in a reinitialized state and can be pushed - into again. diff --git a/third_party/git/Documentation/technical/api-config.txt b/third_party/git/Documentation/technical/api-config.txt deleted file mode 100644 index 7d20716c32..0000000000 --- a/third_party/git/Documentation/technical/api-config.txt +++ /dev/null @@ -1,319 +0,0 @@ -config API -========== - -The config API gives callers a way to access Git configuration files -(and files which have the same syntax). See linkgit:git-config[1] for a -discussion of the config file syntax. - -General Usage -------------- - -Config files are parsed linearly, and each variable found is passed to a -caller-provided callback function. The callback function is responsible -for any actions to be taken on the config option, and is free to ignore -some options. It is not uncommon for the configuration to be parsed -several times during the run of a Git program, with different callbacks -picking out different variables useful to themselves. - -A config callback function takes three parameters: - -- the name of the parsed variable. This is in canonical "flat" form: the - section, subsection, and variable segments will be separated by dots, - and the section and variable segments will be all lowercase. E.g., - `core.ignorecase`, `diff.SomeType.textconv`. - -- the value of the found variable, as a string. If the variable had no - value specified, the value will be NULL (typically this means it - should be interpreted as boolean true). - -- a void pointer passed in by the caller of the config API; this can - contain callback-specific data - -A config callback should return 0 for success, or -1 if the variable -could not be parsed properly. - -Basic Config Querying ---------------------- - -Most programs will simply want to look up variables in all config files -that Git knows about, using the normal precedence rules. To do this, -call `git_config` with a callback function and void data pointer. - -`git_config` will read all config sources in order of increasing -priority. Thus a callback should typically overwrite previously-seen -entries with new ones (e.g., if both the user-wide `~/.gitconfig` and -repo-specific `.git/config` contain `color.ui`, the config machinery -will first feed the user-wide one to the callback, and then the -repo-specific one; by overwriting, the higher-priority repo-specific -value is left at the end). - -The `config_with_options` function lets the caller examine config -while adjusting some of the default behavior of `git_config`. It should -almost never be used by "regular" Git code that is looking up -configuration variables. It is intended for advanced callers like -`git-config`, which are intentionally tweaking the normal config-lookup -process. It takes two extra parameters: - -`config_source`:: -If this parameter is non-NULL, it specifies the source to parse for -configuration, rather than looking in the usual files. See `struct -git_config_source` in `config.h` for details. Regular `git_config` defaults -to `NULL`. - -`opts`:: -Specify options to adjust the behavior of parsing config files. See `struct -config_options` in `config.h` for details. As an example: regular `git_config` -sets `opts.respect_includes` to `1` by default. - -Reading Specific Files ----------------------- - -To read a specific file in git-config format, use -`git_config_from_file`. This takes the same callback and data parameters -as `git_config`. - -Querying For Specific Variables -------------------------------- - -For programs wanting to query for specific variables in a non-callback -manner, the config API provides two functions `git_config_get_value` -and `git_config_get_value_multi`. They both read values from an internal -cache generated previously from reading the config files. - -`int git_config_get_value(const char *key, const char **value)`:: - - Finds the highest-priority value for the configuration variable `key`, - stores the pointer to it in `value` and returns 0. When the - configuration variable `key` is not found, returns 1 without touching - `value`. The caller should not free or modify `value`, as it is owned - by the cache. - -`const struct string_list *git_config_get_value_multi(const char *key)`:: - - Finds and returns the value list, sorted in order of increasing priority - for the configuration variable `key`. When the configuration variable - `key` is not found, returns NULL. The caller should not free or modify - the returned pointer, as it is owned by the cache. - -`void git_config_clear(void)`:: - - Resets and invalidates the config cache. - -The config API also provides type specific API functions which do conversion -as well as retrieval for the queried variable, including: - -`int git_config_get_int(const char *key, int *dest)`:: - - Finds and parses the value to an integer for the configuration variable - `key`. Dies on error; otherwise, stores the value of the parsed integer in - `dest` and returns 0. When the configuration variable `key` is not found, - returns 1 without touching `dest`. - -`int git_config_get_ulong(const char *key, unsigned long *dest)`:: - - Similar to `git_config_get_int` but for unsigned longs. - -`int git_config_get_bool(const char *key, int *dest)`:: - - Finds and parses the value into a boolean value, for the configuration - variable `key` respecting keywords like "true" and "false". Integer - values are converted into true/false values (when they are non-zero or - zero, respectively). Other values cause a die(). If parsing is successful, - stores the value of the parsed result in `dest` and returns 0. When the - configuration variable `key` is not found, returns 1 without touching - `dest`. - -`int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest)`:: - - Similar to `git_config_get_bool`, except that integers are copied as-is, - and `is_bool` flag is unset. - -`int git_config_get_maybe_bool(const char *key, int *dest)`:: - - Similar to `git_config_get_bool`, except that it returns -1 on error - rather than dying. - -`int git_config_get_string_const(const char *key, const char **dest)`:: - - Allocates and copies the retrieved string into the `dest` parameter for - the configuration variable `key`; if NULL string is given, prints an - error message and returns -1. When the configuration variable `key` is - not found, returns 1 without touching `dest`. - -`int git_config_get_string(const char *key, char **dest)`:: - - Similar to `git_config_get_string_const`, except that retrieved value - copied into the `dest` parameter is a mutable string. - -`int git_config_get_pathname(const char *key, const char **dest)`:: - - Similar to `git_config_get_string`, but expands `~` or `~user` into - the user's home directory when found at the beginning of the path. - -`git_die_config(const char *key, const char *err, ...)`:: - - First prints the error message specified by the caller in `err` and then - dies printing the line number and the file name of the highest priority - value for the configuration variable `key`. - -`void git_die_config_linenr(const char *key, const char *filename, int linenr)`:: - - Helper function which formats the die error message according to the - parameters entered. Used by `git_die_config()`. It can be used by callers - handling `git_config_get_value_multi()` to print the correct error message - for the desired value. - -See test-config.c for usage examples. - -Value Parsing Helpers ---------------------- - -To aid in parsing string values, the config API provides callbacks with -a number of helper functions, including: - -`git_config_int`:: -Parse the string to an integer, including unit factors. Dies on error; -otherwise, returns the parsed result. - -`git_config_ulong`:: -Identical to `git_config_int`, but for unsigned longs. - -`git_config_bool`:: -Parse a string into a boolean value, respecting keywords like "true" and -"false". Integer values are converted into true/false values (when they -are non-zero or zero, respectively). Other values cause a die(). If -parsing is successful, the return value is the result. - -`git_config_bool_or_int`:: -Same as `git_config_bool`, except that integers are returned as-is, and -an `is_bool` flag is unset. - -`git_parse_maybe_bool`:: -Same as `git_config_bool`, except that it returns -1 on error rather -than dying. - -`git_config_string`:: -Allocates and copies the value string into the `dest` parameter; if no -string is given, prints an error message and returns -1. - -`git_config_pathname`:: -Similar to `git_config_string`, but expands `~` or `~user` into the -user's home directory when found at the beginning of the path. - -Include Directives ------------------- - -By default, the config parser does not respect include directives. -However, a caller can use the special `git_config_include` wrapper -callback to support them. To do so, you simply wrap your "real" callback -function and data pointer in a `struct config_include_data`, and pass -the wrapper to the regular config-reading functions. For example: - -------------------------------------------- -int read_file_with_include(const char *file, config_fn_t fn, void *data) -{ - struct config_include_data inc = CONFIG_INCLUDE_INIT; - inc.fn = fn; - inc.data = data; - return git_config_from_file(git_config_include, file, &inc); -} -------------------------------------------- - -`git_config` respects includes automatically. The lower-level -`git_config_from_file` does not. - -Custom Configsets ------------------ - -A `config_set` can be used to construct an in-memory cache for -config-like files that the caller specifies (i.e., files like `.gitmodules`, -`~/.gitconfig` etc.). For example, - ----------------------------------------- -struct config_set gm_config; -git_configset_init(&gm_config); -int b; -/* we add config files to the config_set */ -git_configset_add_file(&gm_config, ".gitmodules"); -git_configset_add_file(&gm_config, ".gitmodules_alt"); - -if (!git_configset_get_bool(gm_config, "submodule.frotz.ignore", &b)) { - /* hack hack hack */ -} - -/* when we are done with the configset */ -git_configset_clear(&gm_config); ----------------------------------------- - -Configset API provides functions for the above mentioned work flow, including: - -`void git_configset_init(struct config_set *cs)`:: - - Initializes the config_set `cs`. - -`int git_configset_add_file(struct config_set *cs, const char *filename)`:: - - Parses the file and adds the variable-value pairs to the `config_set`, - dies if there is an error in parsing the file. Returns 0 on success, or - -1 if the file does not exist or is inaccessible. The user has to decide - if he wants to free the incomplete configset or continue using it when - the function returns -1. - -`int git_configset_get_value(struct config_set *cs, const char *key, const char **value)`:: - - Finds the highest-priority value for the configuration variable `key` - and config set `cs`, stores the pointer to it in `value` and returns 0. - When the configuration variable `key` is not found, returns 1 without - touching `value`. The caller should not free or modify `value`, as it - is owned by the cache. - -`const struct string_list *git_configset_get_value_multi(struct config_set *cs, const char *key)`:: - - Finds and returns the value list, sorted in order of increasing priority - for the configuration variable `key` and config set `cs`. When the - configuration variable `key` is not found, returns NULL. The caller - should not free or modify the returned pointer, as it is owned by the cache. - -`void git_configset_clear(struct config_set *cs)`:: - - Clears `config_set` structure, removes all saved variable-value pairs. - -In addition to above functions, the `config_set` API provides type specific -functions in the vein of `git_config_get_int` and family but with an extra -parameter, pointer to struct `config_set`. -They all behave similarly to the `git_config_get*()` family described in -"Querying For Specific Variables" above. - -Writing Config Files --------------------- - -Git gives multiple entry points in the Config API to write config values to -files namely `git_config_set_in_file` and `git_config_set`, which write to -a specific config file or to `.git/config` respectively. They both take a -key/value pair as parameter. -In the end they both call `git_config_set_multivar_in_file` which takes four -parameters: - -- the name of the file, as a string, to which key/value pairs will be written. - -- the name of key, as a string. This is in canonical "flat" form: the section, - subsection, and variable segments will be separated by dots, and the section - and variable segments will be all lowercase. - E.g., `core.ignorecase`, `diff.SomeType.textconv`. - -- the value of the variable, as a string. If value is equal to NULL, it will - remove the matching key from the config file. - -- the value regex, as a string. It will disregard key/value pairs where value - does not match. - -- a multi_replace value, as an int. If value is equal to zero, nothing or only - one matching key/value is replaced, else all matching key/values (regardless - how many) are removed, before the new pair is written. - -It returns 0 on success. - -Also, there are functions `git_config_rename_section` and -`git_config_rename_section_in_file` with parameters `old_name` and `new_name` -for renaming or removing sections in the config files. If NULL is passed -through `new_name` parameter, the section will be removed from the config file. diff --git a/third_party/git/Documentation/technical/api-credentials.txt b/third_party/git/Documentation/technical/api-credentials.txt deleted file mode 100644 index 75368f26ca..0000000000 --- a/third_party/git/Documentation/technical/api-credentials.txt +++ /dev/null @@ -1,271 +0,0 @@ -credentials API -=============== - -The credentials API provides an abstracted way of gathering username and -password credentials from the user (even though credentials in the wider -world can take many forms, in this document the word "credential" always -refers to a username and password pair). - -This document describes two interfaces: the C API that the credential -subsystem provides to the rest of Git, and the protocol that Git uses to -communicate with system-specific "credential helpers". If you are -writing Git code that wants to look up or prompt for credentials, see -the section "C API" below. If you want to write your own helper, see -the section on "Credential Helpers" below. - -Typical setup -------------- - ------------- -+-----------------------+ -| Git code (C) |--- to server requiring ---> -| | authentication -|.......................| -| C credential API |--- prompt ---> User -+-----------------------+ - ^ | - | pipe | - | v -+-----------------------+ -| Git credential helper | -+-----------------------+ ------------- - -The Git code (typically a remote-helper) will call the C API to obtain -credential data like a login/password pair (credential_fill). The -API will itself call a remote helper (e.g. "git credential-cache" or -"git credential-store") that may retrieve credential data from a -store. If the credential helper cannot find the information, the C API -will prompt the user. Then, the caller of the API takes care of -contacting the server, and does the actual authentication. - -C API ------ - -The credential C API is meant to be called by Git code which needs to -acquire or store a credential. It is centered around an object -representing a single credential and provides three basic operations: -fill (acquire credentials by calling helpers and/or prompting the user), -approve (mark a credential as successfully used so that it can be stored -for later use), and reject (mark a credential as unsuccessful so that it -can be erased from any persistent storage). - -Data Structures -~~~~~~~~~~~~~~~ - -`struct credential`:: - - This struct represents a single username/password combination - along with any associated context. All string fields should be - heap-allocated (or NULL if they are not known or not applicable). - The meaning of the individual context fields is the same as - their counterparts in the helper protocol; see the section below - for a description of each field. -+ -The `helpers` member of the struct is a `string_list` of helpers. Each -string specifies an external helper which will be run, in order, to -either acquire or store credentials. See the section on credential -helpers below. This list is filled-in by the API functions -according to the corresponding configuration variables before -consulting helpers, so there usually is no need for a caller to -modify the helpers field at all. -+ -This struct should always be initialized with `CREDENTIAL_INIT` or -`credential_init`. - - -Functions -~~~~~~~~~ - -`credential_init`:: - - Initialize a credential structure, setting all fields to empty. - -`credential_clear`:: - - Free any resources associated with the credential structure, - returning it to a pristine initialized state. - -`credential_fill`:: - - Instruct the credential subsystem to fill the username and - password fields of the passed credential struct by first - consulting helpers, then asking the user. After this function - returns, the username and password fields of the credential are - guaranteed to be non-NULL. If an error occurs, the function will - die(). - -`credential_reject`:: - - Inform the credential subsystem that the provided credentials - have been rejected. This will cause the credential subsystem to - notify any helpers of the rejection (which allows them, for - example, to purge the invalid credentials from storage). It - will also free() the username and password fields of the - credential and set them to NULL (readying the credential for - another call to `credential_fill`). Any errors from helpers are - ignored. - -`credential_approve`:: - - Inform the credential subsystem that the provided credentials - were successfully used for authentication. This will cause the - credential subsystem to notify any helpers of the approval, so - that they may store the result to be used again. Any errors - from helpers are ignored. - -`credential_from_url`:: - - Parse a URL into broken-down credential fields. - -Example -~~~~~~~ - -The example below shows how the functions of the credential API could be -used to login to a fictitious "foo" service on a remote host: - ------------------------------------------------------------------------ -int foo_login(struct foo_connection *f) -{ - int status; - /* - * Create a credential with some context; we don't yet know the - * username or password. - */ - - struct credential c = CREDENTIAL_INIT; - c.protocol = xstrdup("foo"); - c.host = xstrdup(f->hostname); - - /* - * Fill in the username and password fields by contacting - * helpers and/or asking the user. The function will die if it - * fails. - */ - credential_fill(&c); - - /* - * Otherwise, we have a username and password. Try to use it. - */ - status = send_foo_login(f, c.username, c.password); - switch (status) { - case FOO_OK: - /* It worked. Store the credential for later use. */ - credential_accept(&c); - break; - case FOO_BAD_LOGIN: - /* Erase the credential from storage so we don't try it - * again. */ - credential_reject(&c); - break; - default: - /* - * Some other error occurred. We don't know if the - * credential is good or bad, so report nothing to the - * credential subsystem. - */ - } - - /* Free any associated resources. */ - credential_clear(&c); - - return status; -} ------------------------------------------------------------------------ - - -Credential Helpers ------------------- - -Credential helpers are programs executed by Git to fetch or save -credentials from and to long-term storage (where "long-term" is simply -longer than a single Git process; e.g., credentials may be stored -in-memory for a few minutes, or indefinitely on disk). - -Each helper is specified by a single string in the configuration -variable `credential.helper` (and others, see linkgit:git-config[1]). -The string is transformed by Git into a command to be executed using -these rules: - - 1. If the helper string begins with "!", it is considered a shell - snippet, and everything after the "!" becomes the command. - - 2. Otherwise, if the helper string begins with an absolute path, the - verbatim helper string becomes the command. - - 3. Otherwise, the string "git credential-" is prepended to the helper - string, and the result becomes the command. - -The resulting command then has an "operation" argument appended to it -(see below for details), and the result is executed by the shell. - -Here are some example specifications: - ----------------------------------------------------- -# run "git credential-foo" -foo - -# same as above, but pass an argument to the helper -foo --bar=baz - -# the arguments are parsed by the shell, so use shell -# quoting if necessary -foo --bar="whitespace arg" - -# you can also use an absolute path, which will not use the git wrapper -/path/to/my/helper --with-arguments - -# or you can specify your own shell snippet -!f() { echo "password=`cat $HOME/.secret`"; }; f ----------------------------------------------------- - -Generally speaking, rule (3) above is the simplest for users to specify. -Authors of credential helpers should make an effort to assist their -users by naming their program "git-credential-$NAME", and putting it in -the $PATH or $GIT_EXEC_PATH during installation, which will allow a user -to enable it with `git config credential.helper $NAME`. - -When a helper is executed, it will have one "operation" argument -appended to its command line, which is one of: - -`get`:: - - Return a matching credential, if any exists. - -`store`:: - - Store the credential, if applicable to the helper. - -`erase`:: - - Remove a matching credential, if any, from the helper's storage. - -The details of the credential will be provided on the helper's stdin -stream. The exact format is the same as the input/output format of the -`git credential` plumbing command (see the section `INPUT/OUTPUT -FORMAT` in linkgit:git-credential[1] for a detailed specification). - -For a `get` operation, the helper should produce a list of attributes -on stdout in the same format. A helper is free to produce a subset, or -even no values at all if it has nothing useful to provide. Any provided -attributes will overwrite those already known about by Git. If a helper -outputs a `quit` attribute with a value of `true` or `1`, no further -helpers will be consulted, nor will the user be prompted (if no -credential has been provided, the operation will then fail). - -For a `store` or `erase` operation, the helper's output is ignored. -If it fails to perform the requested operation, it may complain to -stderr to inform the user. If it does not support the requested -operation (e.g., a read-only store), it should silently ignore the -request. - -If a helper receives any other operation, it should silently ignore the -request. This leaves room for future operations to be added (older -helpers will just ignore the new requests). - -See also --------- - -linkgit:gitcredentials[7] - -linkgit:git-config[1] (See configuration variables `credential.*`) diff --git a/third_party/git/Documentation/technical/api-diff.txt b/third_party/git/Documentation/technical/api-diff.txt deleted file mode 100644 index 30fc0e9c93..0000000000 --- a/third_party/git/Documentation/technical/api-diff.txt +++ /dev/null @@ -1,174 +0,0 @@ -diff API -======== - -The diff API is for programs that compare two sets of files (e.g. two -trees, one tree and the index) and present the found difference in -various ways. The calling program is responsible for feeding the API -pairs of files, one from the "old" set and the corresponding one from -"new" set, that are different. The library called through this API is -called diffcore, and is responsible for two things. - -* finding total rewrites (`-B`), renames (`-M`) and copies (`-C`), and - changes that touch a string (`-S`), as specified by the caller. - -* outputting the differences in various formats, as specified by the - caller. - -Calling sequence ----------------- - -* Prepare `struct diff_options` to record the set of diff options, and - then call `repo_diff_setup()` to initialize this structure. This - sets up the vanilla default. - -* Fill in the options structure to specify desired output format, rename - detection, etc. `diff_opt_parse()` can be used to parse options given - from the command line in a way consistent with existing git-diff - family of programs. - -* Call `diff_setup_done()`; this inspects the options set up so far for - internal consistency and make necessary tweaking to it (e.g. if - textual patch output was asked, recursive behaviour is turned on); - the callback set_default in diff_options can be used to tweak this more. - -* As you find different pairs of files, call `diff_change()` to feed - modified files, `diff_addremove()` to feed created or deleted files, - or `diff_unmerge()` to feed a file whose state is 'unmerged' to the - API. These are thin wrappers to a lower-level `diff_queue()` function - that is flexible enough to record any of these kinds of changes. - -* Once you finish feeding the pairs of files, call `diffcore_std()`. - This will tell the diffcore library to go ahead and do its work. - -* Calling `diff_flush()` will produce the output. - - -Data structures ---------------- - -* `struct diff_filespec` - -This is the internal representation for a single file (blob). It -records the blob object name (if known -- for a work tree file it -typically is a NUL SHA-1), filemode and pathname. This is what the -`diff_addremove()`, `diff_change()` and `diff_unmerge()` synthesize and -feed `diff_queue()` function with. - -* `struct diff_filepair` - -This records a pair of `struct diff_filespec`; the filespec for a file -in the "old" set (i.e. preimage) is called `one`, and the filespec for a -file in the "new" set (i.e. postimage) is called `two`. A change that -represents file creation has NULL in `one`, and file deletion has NULL -in `two`. - -A `filepair` starts pointing at `one` and `two` that are from the same -filename, but `diffcore_std()` can break pairs and match component -filespecs with other filespecs from a different filepair to form new -filepair. This is called 'rename detection'. - -* `struct diff_queue` - -This is a collection of filepairs. Notable members are: - -`queue`:: - - An array of pointers to `struct diff_filepair`. This - dynamically grows as you add filepairs; - -`alloc`:: - - The allocated size of the `queue` array; - -`nr`:: - - The number of elements in the `queue` array. - - -* `struct diff_options` - -This describes the set of options the calling program wants to affect -the operation of diffcore library with. - -Notable members are: - -`output_format`:: - The output format used when `diff_flush()` is run. - -`context`:: - Number of context lines to generate in patch output. - -`break_opt`, `detect_rename`, `rename-score`, `rename_limit`:: - Affects the way detection logic for complete rewrites, renames - and copies. - -`abbrev`:: - Number of hexdigits to abbreviate raw format output to. - -`pickaxe`:: - A constant string (can and typically does contain newlines to - look for a block of text, not just a single line) to filter out - the filepairs that do not change the number of strings contained - in its preimage and postimage of the diff_queue. - -`flags`:: - This is mostly a collection of boolean options that affects the - operation, but some do not have anything to do with the diffcore - library. - -`touched_flags`:: - Records whether a flag has been changed due to user request - (rather than just set/unset by default). - -`set_default`:: - Callback which allows tweaking the options in diff_setup_done(). - -BINARY, TEXT;; - Affects the way how a file that is seemingly binary is treated. - -FULL_INDEX;; - Tells the patch output format not to use abbreviated object - names on the "index" lines. - -FIND_COPIES_HARDER;; - Tells the diffcore library that the caller is feeding unchanged - filepairs to allow copies from unmodified files be detected. - -COLOR_DIFF;; - Output should be colored. - -COLOR_DIFF_WORDS;; - Output is a colored word-diff. - -NO_INDEX;; - Tells diff-files that the input is not tracked files but files - in random locations on the filesystem. - -ALLOW_EXTERNAL;; - Tells output routine that it is Ok to call user specified patch - output routine. Plumbing disables this to ensure stable output. - -QUIET;; - Do not show any output. - -REVERSE_DIFF;; - Tells the library that the calling program is feeding the - filepairs reversed; `one` is two, and `two` is one. - -EXIT_WITH_STATUS;; - For communication between the calling program and the options - parser; tell the calling program to signal the presence of - difference using program exit code. - -HAS_CHANGES;; - Internal; used for optimization to see if there is any change. - -SILENT_ON_REMOVE;; - Affects if diff-files shows removed files. - -RECURSIVE, TREE_IN_RECURSIVE;; - Tells if tree traversal done by tree-diff should recursively - descend into a tree object pair that are different in preimage - and postimage set. - -(JC) diff --git a/third_party/git/Documentation/technical/api-directory-listing.txt b/third_party/git/Documentation/technical/api-directory-listing.txt deleted file mode 100644 index 5abb8e8b1f..0000000000 --- a/third_party/git/Documentation/technical/api-directory-listing.txt +++ /dev/null @@ -1,130 +0,0 @@ -directory listing API -===================== - -The directory listing API is used to enumerate paths in the work tree, -optionally taking `.git/info/exclude` and `.gitignore` files per -directory into account. - -Data structure --------------- - -`struct dir_struct` structure is used to pass directory traversal -options to the library and to record the paths discovered. A single -`struct dir_struct` is used regardless of whether or not the traversal -recursively descends into subdirectories. - -The notable options are: - -`exclude_per_dir`:: - - The name of the file to be read in each directory for excluded - files (typically `.gitignore`). - -`flags`:: - - A bit-field of options: - -`DIR_SHOW_IGNORED`::: - - Return just ignored files in `entries[]`, not untracked - files. This flag is mutually exclusive with - `DIR_SHOW_IGNORED_TOO`. - -`DIR_SHOW_IGNORED_TOO`::: - - Similar to `DIR_SHOW_IGNORED`, but return ignored files in - `ignored[]` in addition to untracked files in - `entries[]`. This flag is mutually exclusive with - `DIR_SHOW_IGNORED`. - -`DIR_KEEP_UNTRACKED_CONTENTS`::: - - Only has meaning if `DIR_SHOW_IGNORED_TOO` is also set; if this is set, the - untracked contents of untracked directories are also returned in - `entries[]`. - -`DIR_SHOW_IGNORED_TOO_MODE_MATCHING`::: - - Only has meaning if `DIR_SHOW_IGNORED_TOO` is also set; if - this is set, returns ignored files and directories that match - an exclude pattern. If a directory matches an exclude pattern, - then the directory is returned and the contained paths are - not. A directory that does not match an exclude pattern will - not be returned even if all of its contents are ignored. In - this case, the contents are returned as individual entries. -+ -If this is set, files and directories that explicitly match an ignore -pattern are reported. Implicitly ignored directories (directories that -do not match an ignore pattern, but whose contents are all ignored) -are not reported, instead all of the contents are reported. - -`DIR_COLLECT_IGNORED`::: - - Special mode for git-add. Return ignored files in `ignored[]` and - untracked files in `entries[]`. Only returns ignored files that match - pathspec exactly (no wildcards). Does not recurse into ignored - directories. - -`DIR_SHOW_OTHER_DIRECTORIES`::: - - Include a directory that is not tracked. - -`DIR_HIDE_EMPTY_DIRECTORIES`::: - - Do not include a directory that is not tracked and is empty. - -`DIR_NO_GITLINKS`::: - - If set, recurse into a directory that looks like a Git - directory. Otherwise it is shown as a directory. - -The result of the enumeration is left in these fields: - -`entries[]`:: - - An array of `struct dir_entry`, each element of which describes - a path. - -`nr`:: - - The number of members in `entries[]` array. - -`alloc`:: - - Internal use; keeps track of allocation of `entries[]` array. - -`ignored[]`:: - - An array of `struct dir_entry`, used for ignored paths with the - `DIR_SHOW_IGNORED_TOO` and `DIR_COLLECT_IGNORED` flags. - -`ignored_nr`:: - - The number of members in `ignored[]` array. - -Calling sequence ----------------- - -Note: index may be looked at for .gitignore files that are CE_SKIP_WORKTREE -marked. If you to exclude files, make sure you have loaded index first. - -* Prepare `struct dir_struct dir` and clear it with `memset(&dir, 0, - sizeof(dir))`. - -* To add single exclude pattern, call `add_exclude_list()` and then - `add_exclude()`. - -* To add patterns from a file (e.g. `.git/info/exclude`), call - `add_excludes_from_file()` , and/or set `dir.exclude_per_dir`. A - short-hand function `setup_standard_excludes()` can be used to set - up the standard set of exclude settings. - -* Set options described in the Data Structure section above. - -* Call `read_directory()`. - -* Use `dir.entries[]`. - -* Call `clear_directory()` when none of the contained elements are no longer in use. - -(JC) diff --git a/third_party/git/Documentation/technical/api-error-handling.txt b/third_party/git/Documentation/technical/api-error-handling.txt deleted file mode 100644 index ceeedd485c..0000000000 --- a/third_party/git/Documentation/technical/api-error-handling.txt +++ /dev/null @@ -1,75 +0,0 @@ -Error reporting in git -====================== - -`die`, `usage`, `error`, and `warning` report errors of various -kinds. - -- `die` is for fatal application errors. It prints a message to - the user and exits with status 128. - -- `usage` is for errors in command line usage. After printing its - message, it exits with status 129. (See also `usage_with_options` - in the link:api-parse-options.html[parse-options API].) - -- `error` is for non-fatal library errors. It prints a message - to the user and returns -1 for convenience in signaling the error - to the caller. - -- `warning` is for reporting situations that probably should not - occur but which the user (and Git) can continue to work around - without running into too many problems. Like `error`, it - returns -1 after reporting the situation to the caller. - -Customizable error handlers ---------------------------- - -The default behavior of `die` and `error` is to write a message to -stderr and then exit or return as appropriate. This behavior can be -overridden using `set_die_routine` and `set_error_routine`. For -example, "git daemon" uses set_die_routine to write the reason `die` -was called to syslog before exiting. - -Library errors --------------- - -Functions return a negative integer on error. Details beyond that -vary from function to function: - -- Some functions return -1 for all errors. Others return a more - specific value depending on how the caller might want to react - to the error. - -- Some functions report the error to stderr with `error`, - while others leave that for the caller to do. - -- errno is not meaningful on return from most functions (except - for thin wrappers for system calls). - -Check the function's API documentation to be sure. - -Caller-handled errors ---------------------- - -An increasing number of functions take a parameter 'struct strbuf *err'. -On error, such functions append a message about what went wrong to the -'err' strbuf. The message is meant to be complete enough to be passed -to `die` or `error` as-is. For example: - - if (ref_transaction_commit(transaction, &err)) - die("%s", err.buf); - -The 'err' parameter will be untouched if no error occurred, so multiple -function calls can be chained: - - t = ref_transaction_begin(&err); - if (!t || - ref_transaction_update(t, "HEAD", ..., &err) || - ret_transaction_commit(t, &err)) - die("%s", err.buf); - -The 'err' parameter must be a pointer to a valid strbuf. To silence -a message, pass a strbuf that is explicitly ignored: - - if (thing_that_can_fail_in_an_ignorable_way(..., &err)) - /* This failure is okay. */ - strbuf_reset(&err); diff --git a/third_party/git/Documentation/technical/api-gitattributes.txt b/third_party/git/Documentation/technical/api-gitattributes.txt deleted file mode 100644 index 45f0df600f..0000000000 --- a/third_party/git/Documentation/technical/api-gitattributes.txt +++ /dev/null @@ -1,154 +0,0 @@ -gitattributes API -================= - -gitattributes mechanism gives a uniform way to associate various -attributes to set of paths. - - -Data Structure --------------- - -`struct git_attr`:: - - An attribute is an opaque object that is identified by its name. - Pass the name to `git_attr()` function to obtain the object of - this type. The internal representation of this structure is - of no interest to the calling programs. The name of the - attribute can be retrieved by calling `git_attr_name()`. - -`struct attr_check_item`:: - - This structure represents one attribute and its value. - -`struct attr_check`:: - - This structure represents a collection of `attr_check_item`. - It is passed to `git_check_attr()` function, specifying the - attributes to check, and receives their values. - - -Attribute Values ----------------- - -An attribute for a path can be in one of four states: Set, Unset, -Unspecified or set to a string, and `.value` member of `struct -attr_check_item` records it. There are three macros to check these: - -`ATTR_TRUE()`:: - - Returns true if the attribute is Set for the path. - -`ATTR_FALSE()`:: - - Returns true if the attribute is Unset for the path. - -`ATTR_UNSET()`:: - - Returns true if the attribute is Unspecified for the path. - -If none of the above returns true, `.value` member points at a string -value of the attribute for the path. - - -Querying Specific Attributes ----------------------------- - -* Prepare `struct attr_check` using attr_check_initl() - function, enumerating the names of attributes whose values you are - interested in, terminated with a NULL pointer. Alternatively, an - empty `struct attr_check` can be prepared by calling - `attr_check_alloc()` function and then attributes you want to - ask about can be added to it with `attr_check_append()` - function. - -* Call `git_check_attr()` to check the attributes for the path. - -* Inspect `attr_check` structure to see how each of the - attribute in the array is defined for the path. - - -Example -------- - -To see how attributes "crlf" and "ident" are set for different paths. - -. Prepare a `struct attr_check` with two elements (because - we are checking two attributes): - ------------- -static struct attr_check *check; -static void setup_check(void) -{ - if (check) - return; /* already done */ - check = attr_check_initl("crlf", "ident", NULL); -} ------------- - -. Call `git_check_attr()` with the prepared `struct attr_check`: - ------------- - const char *path; - - setup_check(); - git_check_attr(path, check); ------------- - -. Act on `.value` member of the result, left in `check->items[]`: - ------------- - const char *value = check->items[0].value; - - if (ATTR_TRUE(value)) { - The attribute is Set, by listing only the name of the - attribute in the gitattributes file for the path. - } else if (ATTR_FALSE(value)) { - The attribute is Unset, by listing the name of the - attribute prefixed with a dash - for the path. - } else if (ATTR_UNSET(value)) { - The attribute is neither set nor unset for the path. - } else if (!strcmp(value, "input")) { - If none of ATTR_TRUE(), ATTR_FALSE(), or ATTR_UNSET() is - true, the value is a string set in the gitattributes - file for the path by saying "attr=value". - } else if (... other check using value as string ...) { - ... - } ------------- - -To see how attributes in argv[] are set for different paths, only -the first step in the above would be different. - ------------- -static struct attr_check *check; -static void setup_check(const char **argv) -{ - check = attr_check_alloc(); - while (*argv) { - struct git_attr *attr = git_attr(*argv); - attr_check_append(check, attr); - argv++; - } -} ------------- - - -Querying All Attributes ------------------------ - -To get the values of all attributes associated with a file: - -* Prepare an empty `attr_check` structure by calling - `attr_check_alloc()`. - -* Call `git_all_attrs()`, which populates the `attr_check` - with the attributes attached to the path. - -* Iterate over the `attr_check.items[]` array to examine - the attribute names and values. The name of the attribute - described by an `attr_check.items[]` object can be retrieved via - `git_attr_name(check->items[i].attr)`. (Please note that no items - will be returned for unset attributes, so `ATTR_UNSET()` will return - false for all returned `attr_check.items[]` objects.) - -* Free the `attr_check` struct by calling `attr_check_free()`. diff --git a/third_party/git/Documentation/technical/api-grep.txt b/third_party/git/Documentation/technical/api-grep.txt deleted file mode 100644 index a69cc8964d..0000000000 --- a/third_party/git/Documentation/technical/api-grep.txt +++ /dev/null @@ -1,8 +0,0 @@ -grep API -======== - -Talk about <grep.h>, things like: - -* grep_buffer() - -(JC) diff --git a/third_party/git/Documentation/technical/api-history-graph.txt b/third_party/git/Documentation/technical/api-history-graph.txt deleted file mode 100644 index d0d1707c8c..0000000000 --- a/third_party/git/Documentation/technical/api-history-graph.txt +++ /dev/null @@ -1,173 +0,0 @@ -history graph API -================= - -The graph API is used to draw a text-based representation of the commit -history. The API generates the graph in a line-by-line fashion. - -Functions ---------- - -Core functions: - -* `graph_init()` creates a new `struct git_graph` - -* `graph_update()` moves the graph to a new commit. - -* `graph_next_line()` outputs the next line of the graph into a strbuf. It - does not add a terminating newline. - -* `graph_padding_line()` outputs a line of vertical padding in the graph. It - is similar to `graph_next_line()`, but is guaranteed to never print the line - containing the current commit. Where `graph_next_line()` would print the - commit line next, `graph_padding_line()` prints a line that simply extends - all branch lines downwards one row, leaving their positions unchanged. - -* `graph_is_commit_finished()` determines if the graph has output all lines - necessary for the current commit. If `graph_update()` is called before all - lines for the current commit have been printed, the next call to - `graph_next_line()` will output an ellipsis, to indicate that a portion of - the graph was omitted. - -The following utility functions are wrappers around `graph_next_line()` and -`graph_is_commit_finished()`. They always print the output to stdout. -They can all be called with a NULL graph argument, in which case no graph -output will be printed. - -* `graph_show_commit()` calls `graph_next_line()` and - `graph_is_commit_finished()` until one of them return non-zero. This prints - all graph lines up to, and including, the line containing this commit. - Output is printed to stdout. The last line printed does not contain a - terminating newline. - -* `graph_show_oneline()` calls `graph_next_line()` and prints the result to - stdout. The line printed does not contain a terminating newline. - -* `graph_show_padding()` calls `graph_padding_line()` and prints the result to - stdout. The line printed does not contain a terminating newline. - -* `graph_show_remainder()` calls `graph_next_line()` until - `graph_is_commit_finished()` returns non-zero. Output is printed to stdout. - The last line printed does not contain a terminating newline. Returns 1 if - output was printed, and 0 if no output was necessary. - -* `graph_show_strbuf()` prints the specified strbuf to stdout, prefixing all - lines but the first with a graph line. The caller is responsible for - ensuring graph output for the first line has already been printed to stdout. - (This can be done with `graph_show_commit()` or `graph_show_oneline()`.) If - a NULL graph is supplied, the strbuf is printed as-is. - -* `graph_show_commit_msg()` is similar to `graph_show_strbuf()`, but it also - prints the remainder of the graph, if more lines are needed after the strbuf - ends. It is better than directly calling `graph_show_strbuf()` followed by - `graph_show_remainder()` since it properly handles buffers that do not end in - a terminating newline. The output printed by `graph_show_commit_msg()` will - end in a newline if and only if the strbuf ends in a newline. - -Data structure --------------- -`struct git_graph` is an opaque data type used to store the current graph -state. - -Calling sequence ----------------- - -* Create a `struct git_graph` by calling `graph_init()`. When using the - revision walking API, this is done automatically by `setup_revisions()` if - the '--graph' option is supplied. - -* Use the revision walking API to walk through a group of contiguous commits. - The `get_revision()` function automatically calls `graph_update()` each time - it is invoked. - -* For each commit, call `graph_next_line()` repeatedly, until - `graph_is_commit_finished()` returns non-zero. Each call to - `graph_next_line()` will output a single line of the graph. The resulting - lines will not contain any newlines. `graph_next_line()` returns 1 if the - resulting line contains the current commit, or 0 if this is merely a line - needed to adjust the graph before or after the current commit. This return - value can be used to determine where to print the commit summary information - alongside the graph output. - -Limitations ------------ - -* `graph_update()` must be called with commits in topological order. It should - not be called on a commit if it has already been invoked with an ancestor of - that commit, or the graph output will be incorrect. - -* `graph_update()` must be called on a contiguous group of commits. If - `graph_update()` is called on a particular commit, it should later be called - on all parents of that commit. Parents must not be skipped, or the graph - output will appear incorrect. -+ -`graph_update()` may be used on a pruned set of commits only if the parent list -has been rewritten so as to include only ancestors from the pruned set. - -* The graph API does not currently support reverse commit ordering. In - order to implement reverse ordering, the graphing API needs an - (efficient) mechanism to find the children of a commit. - -Sample usage ------------- - ------------- -struct commit *commit; -struct git_graph *graph = graph_init(opts); - -while ((commit = get_revision(opts)) != NULL) { - while (!graph_is_commit_finished(graph)) - { - struct strbuf sb; - int is_commit_line; - - strbuf_init(&sb, 0); - is_commit_line = graph_next_line(graph, &sb); - fputs(sb.buf, stdout); - - if (is_commit_line) - log_tree_commit(opts, commit); - else - putchar(opts->diffopt.line_termination); - } -} ------------- - -Sample output -------------- - -The following is an example of the output from the graph API. This output does -not include any commit summary information--callers are responsible for -outputting that information, if desired. - ------------- -* -* -* -|\ -* | -| | * -| \ \ -| \ \ -*-. \ \ -|\ \ \ \ -| | * | | -| | | | | * -| | | | | * -| | | | | * -| | | | | |\ -| | | | | | * -| * | | | | | -| | | | | * \ -| | | | | |\ | -| | | | * | | | -| | | | * | | | -* | | | | | | | -| |/ / / / / / -|/| / / / / / -* | | | | | | -|/ / / / / / -* | | | | | -| | | | | * -| | | | |/ -| | | | * ------------- diff --git a/third_party/git/Documentation/technical/api-index-skel.txt b/third_party/git/Documentation/technical/api-index-skel.txt deleted file mode 100644 index eda8c195c1..0000000000 --- a/third_party/git/Documentation/technical/api-index-skel.txt +++ /dev/null @@ -1,13 +0,0 @@ -Git API Documents -================= - -Git has grown a set of internal API over time. This collection -documents them. - -//////////////////////////////////////////////////////////////// -// table of contents begin -//////////////////////////////////////////////////////////////// - -//////////////////////////////////////////////////////////////// -// table of contents end -//////////////////////////////////////////////////////////////// diff --git a/third_party/git/Documentation/technical/api-index.sh b/third_party/git/Documentation/technical/api-index.sh deleted file mode 100755 index 9c3f4131b8..0000000000 --- a/third_party/git/Documentation/technical/api-index.sh +++ /dev/null @@ -1,28 +0,0 @@ -#!/bin/sh - -( - c=//////////////////////////////////////////////////////////////// - skel=api-index-skel.txt - sed -e '/^\/\/ table of contents begin/q' "$skel" - echo "$c" - - ls api-*.txt | - while read filename - do - case "$filename" in - api-index-skel.txt | api-index.txt) continue ;; - esac - title=$(sed -e 1q "$filename") - html=${filename%.txt}.html - echo "* link:$html[$title]" - done - echo "$c" - sed -n -e '/^\/\/ table of contents end/,$p' "$skel" -) >api-index.txt+ - -if test -f api-index.txt && cmp api-index.txt api-index.txt+ >/dev/null -then - rm -f api-index.txt+ -else - mv api-index.txt+ api-index.txt -fi diff --git a/third_party/git/Documentation/technical/api-merge.txt b/third_party/git/Documentation/technical/api-merge.txt deleted file mode 100644 index 9dc1bed768..0000000000 --- a/third_party/git/Documentation/technical/api-merge.txt +++ /dev/null @@ -1,104 +0,0 @@ -merge API -========= - -The merge API helps a program to reconcile two competing sets of -improvements to some files (e.g., unregistered changes from the work -tree versus changes involved in switching to a new branch), reporting -conflicts if found. The library called through this API is -responsible for a few things. - - * determining which trees to merge (recursive ancestor consolidation); - - * lining up corresponding files in the trees to be merged (rename - detection, subtree shifting), reporting edge cases like add/add - and rename/rename conflicts to the user; - - * performing a three-way merge of corresponding files, taking - path-specific merge drivers (specified in `.gitattributes`) - into account. - -Data structures ---------------- - -* `mmbuffer_t`, `mmfile_t` - -These store data usable for use by the xdiff backend, for writing and -for reading, respectively. See `xdiff/xdiff.h` for the definitions -and `diff.c` for examples. - -* `struct ll_merge_options` - -This describes the set of options the calling program wants to affect -the operation of a low-level (single file) merge. Some options: - -`virtual_ancestor`:: - Behave as though this were part of a merge between common - ancestors in a recursive merge. - If a helper program is specified by the - `[merge "<driver>"] recursive` configuration, it will - be used (see linkgit:gitattributes[5]). - -`variant`:: - Resolve local conflicts automatically in favor - of one side or the other (as in 'git merge-file' - `--ours`/`--theirs`/`--union`). Can be `0`, - `XDL_MERGE_FAVOR_OURS`, `XDL_MERGE_FAVOR_THEIRS`, or - `XDL_MERGE_FAVOR_UNION`. - -`renormalize`:: - Resmudge and clean the "base", "theirs" and "ours" files - before merging. Use this when the merge is likely to have - overlapped with a change in smudge/clean or end-of-line - normalization rules. - -Low-level (single file) merge ------------------------------ - -`ll_merge`:: - - Perform a three-way single-file merge in core. This is - a thin wrapper around `xdl_merge` that takes the path and - any merge backend specified in `.gitattributes` or - `.git/info/attributes` into account. Returns 0 for a - clean merge. - -Calling sequence: - -* Prepare a `struct ll_merge_options` to record options. - If you have no special requests, skip this and pass `NULL` - as the `opts` parameter to use the default options. - -* Allocate an mmbuffer_t variable for the result. - -* Allocate and fill variables with the file's original content - and two modified versions (using `read_mmfile`, for example). - -* Call `ll_merge()`. - -* Read the merged content from `result_buf.ptr` and `result_buf.size`. - -* Release buffers when finished. A simple - `free(ancestor.ptr); free(ours.ptr); free(theirs.ptr); - free(result_buf.ptr);` will do. - -If the modifications do not merge cleanly, `ll_merge` will return a -nonzero value and `result_buf` will generally include a description of -the conflict bracketed by markers such as the traditional `<<<<<<<` -and `>>>>>>>`. - -The `ancestor_label`, `our_label`, and `their_label` parameters are -used to label the different sides of a conflict if the merge driver -supports this. - -Everything else ---------------- - -Talk about <merge-recursive.h> and merge_file(): - - - merge_trees() to merge with rename detection - - merge_recursive() for ancestor consolidation - - try_merge_command() for other strategies - - conflict format - - merge options - -(Daniel, Miklos, Stephan, JC) diff --git a/third_party/git/Documentation/technical/api-object-access.txt b/third_party/git/Documentation/technical/api-object-access.txt deleted file mode 100644 index 5b29622d00..0000000000 --- a/third_party/git/Documentation/technical/api-object-access.txt +++ /dev/null @@ -1,15 +0,0 @@ -object access API -================= - -Talk about <sha1-file.c> and <object.h> family, things like - -* read_sha1_file() -* read_object_with_reference() -* has_sha1_file() -* write_sha1_file() -* pretend_object_file() -* lookup_{object,commit,tag,blob,tree} -* parse_{object,commit,tag,blob,tree} -* Use of object flags - -(JC, Shawn, Daniel, Dscho, Linus) diff --git a/third_party/git/Documentation/technical/api-oid-array.txt b/third_party/git/Documentation/technical/api-oid-array.txt deleted file mode 100644 index c97428c2c3..0000000000 --- a/third_party/git/Documentation/technical/api-oid-array.txt +++ /dev/null @@ -1,90 +0,0 @@ -oid-array API -============== - -The oid-array API provides storage and manipulation of sets of object -identifiers. The emphasis is on storage and processing efficiency, -making them suitable for large lists. Note that the ordering of items is -not preserved over some operations. - -Data Structures ---------------- - -`struct oid_array`:: - - A single array of object IDs. This should be initialized by - assignment from `OID_ARRAY_INIT`. The `oid` member contains - the actual data. The `nr` member contains the number of items in - the set. The `alloc` and `sorted` members are used internally, - and should not be needed by API callers. - -Functions ---------- - -`oid_array_append`:: - Add an item to the set. The object ID will be placed at the end of - the array (but note that some operations below may lose this - ordering). - -`oid_array_lookup`:: - Perform a binary search of the array for a specific object ID. - If found, returns the offset (in number of elements) of the - object ID. If not found, returns a negative integer. If the array - is not sorted, this function has the side effect of sorting it. - -`oid_array_clear`:: - Free all memory associated with the array and return it to the - initial, empty state. - -`oid_array_for_each`:: - Iterate over each element of the list, executing the callback - function for each one. Does not sort the list, so any custom - hash order is retained. If the callback returns a non-zero - value, the iteration ends immediately and the callback's - return is propagated; otherwise, 0 is returned. - -`oid_array_for_each_unique`:: - Iterate over each unique element of the list in sorted order, - but otherwise behave like `oid_array_for_each`. If the array - is not sorted, this function has the side effect of sorting - it. - -`oid_array_filter`:: - Apply the callback function `want` to each entry in the array, - retaining only the entries for which the function returns true. - Preserve the order of the entries that are retained. - -Examples --------- - ------------------------------------------ -int print_callback(const struct object_id *oid, - void *data) -{ - printf("%s\n", oid_to_hex(oid)); - return 0; /* always continue */ -} - -void some_func(void) -{ - struct sha1_array hashes = OID_ARRAY_INIT; - struct object_id oid; - - /* Read objects into our set */ - while (read_object_from_stdin(oid.hash)) - oid_array_append(&hashes, &oid); - - /* Check if some objects are in our set */ - while (read_object_from_stdin(oid.hash)) { - if (oid_array_lookup(&hashes, &oid) >= 0) - printf("it's in there!\n"); - - /* - * Print the unique set of objects. We could also have - * avoided adding duplicate objects in the first place, - * but we would end up re-sorting the array repeatedly. - * Instead, this will sort once and then skip duplicates - * in linear time. - */ - oid_array_for_each_unique(&hashes, print_callback, NULL); -} ------------------------------------------ diff --git a/third_party/git/Documentation/technical/api-parse-options.txt b/third_party/git/Documentation/technical/api-parse-options.txt deleted file mode 100644 index 2e2e7c10c6..0000000000 --- a/third_party/git/Documentation/technical/api-parse-options.txt +++ /dev/null @@ -1,313 +0,0 @@ -parse-options API -================= - -The parse-options API is used to parse and massage options in Git -and to provide a usage help with consistent look. - -Basics ------- - -The argument vector `argv[]` may usually contain mandatory or optional -'non-option arguments', e.g. a filename or a branch, and 'options'. -Options are optional arguments that start with a dash and -that allow to change the behavior of a command. - -* There are basically three types of options: - 'boolean' options, - options with (mandatory) 'arguments' and - options with 'optional arguments' - (i.e. a boolean option that can be adjusted). - -* There are basically two forms of options: - 'Short options' consist of one dash (`-`) and one alphanumeric - character. - 'Long options' begin with two dashes (`--`) and some - alphanumeric characters. - -* Options are case-sensitive. - Please define 'lower-case long options' only. - -The parse-options API allows: - -* 'stuck' and 'separate form' of options with arguments. - `-oArg` is stuck, `-o Arg` is separate form. - `--option=Arg` is stuck, `--option Arg` is separate form. - -* Long options may be 'abbreviated', as long as the abbreviation - is unambiguous. - -* Short options may be bundled, e.g. `-a -b` can be specified as `-ab`. - -* Boolean long options can be 'negated' (or 'unset') by prepending - `no-`, e.g. `--no-abbrev` instead of `--abbrev`. Conversely, - options that begin with `no-` can be 'negated' by removing it. - Other long options can be unset (e.g., set string to NULL, set - integer to 0) by prepending `no-`. - -* Options and non-option arguments can clearly be separated using the `--` - option, e.g. `-a -b --option -- --this-is-a-file` indicates that - `--this-is-a-file` must not be processed as an option. - -Steps to parse options ----------------------- - -. `#include "parse-options.h"` - -. define a NULL-terminated - `static const char * const builtin_foo_usage[]` array - containing alternative usage strings - -. define `builtin_foo_options` array as described below - in section 'Data Structure'. - -. in `cmd_foo(int argc, const char **argv, const char *prefix)` - call - - argc = parse_options(argc, argv, prefix, builtin_foo_options, builtin_foo_usage, flags); -+ -`parse_options()` will filter out the processed options of `argv[]` and leave the -non-option arguments in `argv[]`. -`argc` is updated appropriately because of the assignment. -+ -You can also pass NULL instead of a usage array as the fifth parameter of -parse_options(), to avoid displaying a help screen with usage info and -option list. This should only be done if necessary, e.g. to implement -a limited parser for only a subset of the options that needs to be run -before the full parser, which in turn shows the full help message. -+ -Flags are the bitwise-or of: - -`PARSE_OPT_KEEP_DASHDASH`:: - Keep the `--` that usually separates options from - non-option arguments. - -`PARSE_OPT_STOP_AT_NON_OPTION`:: - Usually the whole argument vector is massaged and reordered. - Using this flag, processing is stopped at the first non-option - argument. - -`PARSE_OPT_KEEP_ARGV0`:: - Keep the first argument, which contains the program name. It's - removed from argv[] by default. - -`PARSE_OPT_KEEP_UNKNOWN`:: - Keep unknown arguments instead of erroring out. This doesn't - work for all combinations of arguments as users might expect - it to do. E.g. if the first argument in `--unknown --known` - takes a value (which we can't know), the second one is - mistakenly interpreted as a known option. Similarly, if - `PARSE_OPT_STOP_AT_NON_OPTION` is set, the second argument in - `--unknown value` will be mistakenly interpreted as a - non-option, not as a value belonging to the unknown option, - the parser early. That's why parse_options() errors out if - both options are set. - -`PARSE_OPT_NO_INTERNAL_HELP`:: - By default, parse_options() handles `-h`, `--help` and - `--help-all` internally, by showing a help screen. This option - turns it off and allows one to add custom handlers for these - options, or to just leave them unknown. - -Data Structure --------------- - -The main data structure is an array of the `option` struct, -say `static struct option builtin_add_options[]`. -There are some macros to easily define options: - -`OPT__ABBREV(&int_var)`:: - Add `--abbrev[=<n>]`. - -`OPT__COLOR(&int_var, description)`:: - Add `--color[=<when>]` and `--no-color`. - -`OPT__DRY_RUN(&int_var, description)`:: - Add `-n, --dry-run`. - -`OPT__FORCE(&int_var, description)`:: - Add `-f, --force`. - -`OPT__QUIET(&int_var, description)`:: - Add `-q, --quiet`. - -`OPT__VERBOSE(&int_var, description)`:: - Add `-v, --verbose`. - -`OPT_GROUP(description)`:: - Start an option group. `description` is a short string that - describes the group or an empty string. - Start the description with an upper-case letter. - -`OPT_BOOL(short, long, &int_var, description)`:: - Introduce a boolean option. `int_var` is set to one with - `--option` and set to zero with `--no-option`. - -`OPT_COUNTUP(short, long, &int_var, description)`:: - Introduce a count-up option. - Each use of `--option` increments `int_var`, starting from zero - (even if initially negative), and `--no-option` resets it to - zero. To determine if `--option` or `--no-option` was encountered at - all, initialize `int_var` to a negative value, and if it is still - negative after parse_options(), then neither `--option` nor - `--no-option` was seen. - -`OPT_BIT(short, long, &int_var, description, mask)`:: - Introduce a boolean option. - If used, `int_var` is bitwise-ored with `mask`. - -`OPT_NEGBIT(short, long, &int_var, description, mask)`:: - Introduce a boolean option. - If used, `int_var` is bitwise-anded with the inverted `mask`. - -`OPT_SET_INT(short, long, &int_var, description, integer)`:: - Introduce an integer option. - `int_var` is set to `integer` with `--option`, and - reset to zero with `--no-option`. - -`OPT_STRING(short, long, &str_var, arg_str, description)`:: - Introduce an option with string argument. - The string argument is put into `str_var`. - -`OPT_STRING_LIST(short, long, &struct string_list, arg_str, description)`:: - Introduce an option with string argument. - The string argument is stored as an element in `string_list`. - Use of `--no-option` will clear the list of preceding values. - -`OPT_INTEGER(short, long, &int_var, description)`:: - Introduce an option with integer argument. - The integer is put into `int_var`. - -`OPT_MAGNITUDE(short, long, &unsigned_long_var, description)`:: - Introduce an option with a size argument. The argument must be a - non-negative integer and may include a suffix of 'k', 'm' or 'g' to - scale the provided value by 1024, 1024^2 or 1024^3 respectively. - The scaled value is put into `unsigned_long_var`. - -`OPT_EXPIRY_DATE(short, long, ×tamp_t_var, description)`:: - Introduce an option with expiry date argument, see `parse_expiry_date()`. - The timestamp is put into `timestamp_t_var`. - -`OPT_CALLBACK(short, long, &var, arg_str, description, func_ptr)`:: - Introduce an option with argument. - The argument will be fed into the function given by `func_ptr` - and the result will be put into `var`. - See 'Option Callbacks' below for a more elaborate description. - -`OPT_FILENAME(short, long, &var, description)`:: - Introduce an option with a filename argument. - The filename will be prefixed by passing the filename along with - the prefix argument of `parse_options()` to `prefix_filename()`. - -`OPT_ARGUMENT(long, &int_var, description)`:: - Introduce a long-option argument that will be kept in `argv[]`. - If this option was seen, `int_var` will be set to one (except - if a `NULL` pointer was passed). - -`OPT_NUMBER_CALLBACK(&var, description, func_ptr)`:: - Recognize numerical options like -123 and feed the integer as - if it was an argument to the function given by `func_ptr`. - The result will be put into `var`. There can be only one such - option definition. It cannot be negated and it takes no - arguments. Short options that happen to be digits take - precedence over it. - -`OPT_COLOR_FLAG(short, long, &int_var, description)`:: - Introduce an option that takes an optional argument that can - have one of three values: "always", "never", or "auto". If the - argument is not given, it defaults to "always". The `--no-` form - works like `--long=never`; it cannot take an argument. If - "always", set `int_var` to 1; if "never", set `int_var` to 0; if - "auto", set `int_var` to 1 if stdout is a tty or a pager, - 0 otherwise. - -`OPT_NOOP_NOARG(short, long)`:: - Introduce an option that has no effect and takes no arguments. - Use it to hide deprecated options that are still to be recognized - and ignored silently. - -`OPT_PASSTHRU(short, long, &char_var, arg_str, description, flags)`:: - Introduce an option that will be reconstructed into a char* string, - which must be initialized to NULL. This is useful when you need to - pass the command-line option to another command. Any previous value - will be overwritten, so this should only be used for options where - the last one specified on the command line wins. - -`OPT_PASSTHRU_ARGV(short, long, &argv_array_var, arg_str, description, flags)`:: - Introduce an option where all instances of it on the command-line will - be reconstructed into an argv_array. This is useful when you need to - pass the command-line option, which can be specified multiple times, - to another command. - -`OPT_CMDMODE(short, long, &int_var, description, enum_val)`:: - Define an "operation mode" option, only one of which in the same - group of "operating mode" options that share the same `int_var` - can be given by the user. `enum_val` is set to `int_var` when the - option is used, but an error is reported if other "operating mode" - option has already set its value to the same `int_var`. - - -The last element of the array must be `OPT_END()`. - -If not stated otherwise, interpret the arguments as follows: - -* `short` is a character for the short option - (e.g. `'e'` for `-e`, use `0` to omit), - -* `long` is a string for the long option - (e.g. `"example"` for `--example`, use `NULL` to omit), - -* `int_var` is an integer variable, - -* `str_var` is a string variable (`char *`), - -* `arg_str` is the string that is shown as argument - (e.g. `"branch"` will result in `<branch>`). - If set to `NULL`, three dots (`...`) will be displayed. - -* `description` is a short string to describe the effect of the option. - It shall begin with a lower-case letter and a full stop (`.`) shall be - omitted at the end. - -Option Callbacks ----------------- - -The function must be defined in this form: - - int func(const struct option *opt, const char *arg, int unset) - -The callback mechanism is as follows: - -* Inside `func`, the only interesting member of the structure - given by `opt` is the void pointer `opt->value`. - `*opt->value` will be the value that is saved into `var`, if you - use `OPT_CALLBACK()`. - For example, do `*(unsigned long *)opt->value = 42;` to get 42 - into an `unsigned long` variable. - -* Return value `0` indicates success and non-zero return - value will invoke `usage_with_options()` and, thus, die. - -* If the user negates the option, `arg` is `NULL` and `unset` is 1. - -Sophisticated option parsing ----------------------------- - -If you need, for example, option callbacks with optional arguments -or without arguments at all, or if you need other special cases, -that are not handled by the macros above, you need to specify the -members of the `option` structure manually. - -This is not covered in this document, but well documented -in `parse-options.h` itself. - -Examples --------- - -See `test-parse-options.c` and -`builtin/add.c`, -`builtin/clone.c`, -`builtin/commit.c`, -`builtin/fetch.c`, -`builtin/fsck.c`, -`builtin/rm.c` -for real-world examples. diff --git a/third_party/git/Documentation/technical/api-quote.txt b/third_party/git/Documentation/technical/api-quote.txt deleted file mode 100644 index e8a1bce94e..0000000000 --- a/third_party/git/Documentation/technical/api-quote.txt +++ /dev/null @@ -1,10 +0,0 @@ -quote API -========= - -Talk about <quote.h>, things like - -* sq_quote and unquote -* c_style quote and unquote -* quoting for foreign languages - -(JC) diff --git a/third_party/git/Documentation/technical/api-ref-iteration.txt b/third_party/git/Documentation/technical/api-ref-iteration.txt deleted file mode 100644 index ad9d019ff9..0000000000 --- a/third_party/git/Documentation/technical/api-ref-iteration.txt +++ /dev/null @@ -1,78 +0,0 @@ -ref iteration API -================= - - -Iteration of refs is done by using an iterate function which will call a -callback function for every ref. The callback function has this -signature: - - int handle_one_ref(const char *refname, const struct object_id *oid, - int flags, void *cb_data); - -There are different kinds of iterate functions which all take a -callback of this type. The callback is then called for each found ref -until the callback returns nonzero. The returned value is then also -returned by the iterate function. - -Iteration functions -------------------- - -* `head_ref()` just iterates the head ref. - -* `for_each_ref()` iterates all refs. - -* `for_each_ref_in()` iterates all refs which have a defined prefix and - strips that prefix from the passed variable refname. - -* `for_each_tag_ref()`, `for_each_branch_ref()`, `for_each_remote_ref()`, - `for_each_replace_ref()` iterate refs from the respective area. - -* `for_each_glob_ref()` iterates all refs that match the specified glob - pattern. - -* `for_each_glob_ref_in()` the previous and `for_each_ref_in()` combined. - -* Use `refs_` API for accessing submodules. The submodule ref store could - be obtained with `get_submodule_ref_store()`. - -* `for_each_rawref()` can be used to learn about broken ref and symref. - -* `for_each_reflog()` iterates each reflog file. - -Submodules ----------- - -If you want to iterate the refs of a submodule you first need to add the -submodules object database. You can do this by a code-snippet like -this: - - const char *path = "path/to/submodule" - if (add_submodule_odb(path)) - die("Error submodule '%s' not populated.", path); - -`add_submodule_odb()` will return zero on success. If you -do not do this you will get an error for each ref that it does not point -to a valid object. - -Note: As a side-effect of this you cannot safely assume that all -objects you lookup are available in superproject. All submodule objects -will be available the same way as the superprojects objects. - -Example: --------- - ----- -static int handle_remote_ref(const char *refname, - const unsigned char *sha1, int flags, void *cb_data) -{ - struct strbuf *output = cb_data; - strbuf_addf(output, "%s\n", refname); - return 0; -} - -... - - struct strbuf output = STRBUF_INIT; - for_each_remote_ref(handle_remote_ref, &output); - printf("%s", output.buf); ----- diff --git a/third_party/git/Documentation/technical/api-remote.txt b/third_party/git/Documentation/technical/api-remote.txt deleted file mode 100644 index f10941b2e8..0000000000 --- a/third_party/git/Documentation/technical/api-remote.txt +++ /dev/null @@ -1,127 +0,0 @@ -Remotes configuration API -========================= - -The API in remote.h gives access to the configuration related to -remotes. It handles all three configuration mechanisms historically -and currently used by Git, and presents the information in a uniform -fashion. Note that the code also handles plain URLs without any -configuration, giving them just the default information. - -struct remote -------------- - -`name`:: - - The user's nickname for the remote - -`url`:: - - An array of all of the url_nr URLs configured for the remote - -`pushurl`:: - - An array of all of the pushurl_nr push URLs configured for the remote - -`push`:: - - An array of refspecs configured for pushing, with - push_refspec being the literal strings, and push_refspec_nr - being the quantity. - -`fetch`:: - - An array of refspecs configured for fetching, with - fetch_refspec being the literal strings, and fetch_refspec_nr - being the quantity. - -`fetch_tags`:: - - The setting for whether to fetch tags (as a separate rule from - the configured refspecs); -1 means never to fetch tags, 0 - means to auto-follow tags based on the default heuristic, 1 - means to always auto-follow tags, and 2 means to fetch all - tags. - -`receivepack`, `uploadpack`:: - - The configured helper programs to run on the remote side, for - Git-native protocols. - -`http_proxy`:: - - The proxy to use for curl (http, https, ftp, etc.) URLs. - -`http_proxy_authmethod`:: - - The method used for authenticating against `http_proxy`. - -struct remotes can be found by name with remote_get(), and iterated -through with for_each_remote(). remote_get(NULL) will return the -default remote, given the current branch and configuration. - -struct refspec --------------- - -A struct refspec holds the parsed interpretation of a refspec. If it -will force updates (starts with a '+'), force is true. If it is a -pattern (sides end with '*') pattern is true. src and dest are the -two sides (including '*' characters if present); if there is only one -side, it is src, and dst is NULL; if sides exist but are empty (i.e., -the refspec either starts or ends with ':'), the corresponding side is -"". - -An array of strings can be parsed into an array of struct refspecs -using parse_fetch_refspec() or parse_push_refspec(). - -remote_find_tracking(), given a remote and a struct refspec with -either src or dst filled out, will fill out the other such that the -result is in the "fetch" specification for the remote (note that this -evaluates patterns and returns a single result). - -struct branch -------------- - -Note that this may end up moving to branch.h - -struct branch holds the configuration for a branch. It can be looked -up with branch_get(name) for "refs/heads/{name}", or with -branch_get(NULL) for HEAD. - -It contains: - -`name`:: - - The short name of the branch. - -`refname`:: - - The full path for the branch ref. - -`remote_name`:: - - The name of the remote listed in the configuration. - -`merge_name`:: - - An array of the "merge" lines in the configuration. - -`merge`:: - - An array of the struct refspecs used for the merge lines. That - is, merge[i]->dst is a local tracking ref which should be - merged into this branch by default. - -`merge_nr`:: - - The number of merge configurations - -branch_has_merge_config() returns true if the given branch has merge -configuration given. - -Other stuff ------------ - -There is other stuff in remote.h that is related, in general, to the -process of interacting with remotes. - -(Daniel Barkalow) diff --git a/third_party/git/Documentation/technical/api-revision-walking.txt b/third_party/git/Documentation/technical/api-revision-walking.txt deleted file mode 100644 index 03f9ea6ac4..0000000000 --- a/third_party/git/Documentation/technical/api-revision-walking.txt +++ /dev/null @@ -1,72 +0,0 @@ -revision walking API -==================== - -The revision walking API offers functions to build a list of revisions -and then iterate over that list. - -Calling sequence ----------------- - -The walking API has a given calling sequence: first you need to -initialize a rev_info structure, then add revisions to control what kind -of revision list do you want to get, finally you can iterate over the -revision list. - -Functions ---------- - -`repo_init_revisions`:: - - Initialize a rev_info structure with default values. The third - parameter may be NULL or can be prefix path, and then the `.prefix` - variable will be set to it. This is typically the first function you - want to call when you want to deal with a revision list. After calling - this function, you are free to customize options, like set - `.ignore_merges` to 0 if you don't want to ignore merges, and so on. See - `revision.h` for a complete list of available options. - -`add_pending_object`:: - - This function can be used if you want to add commit objects as revision - information. You can use the `UNINTERESTING` object flag to indicate if - you want to include or exclude the given commit (and commits reachable - from the given commit) from the revision list. -+ -NOTE: If you have the commits as a string list then you probably want to -use setup_revisions(), instead of parsing each string and using this -function. - -`setup_revisions`:: - - Parse revision information, filling in the `rev_info` structure, and - removing the used arguments from the argument list. Returns the number - of arguments left that weren't recognized, which are also moved to the - head of the argument list. The last parameter is used in case no - parameter given by the first two arguments. - -`prepare_revision_walk`:: - - Prepares the rev_info structure for a walk. You should check if it - returns any error (non-zero return code) and if it does not, you can - start using get_revision() to do the iteration. - -`get_revision`:: - - Takes a pointer to a `rev_info` structure and iterates over it, - returning a `struct commit *` each time you call it. The end of the - revision list is indicated by returning a NULL pointer. - -`reset_revision_walk`:: - - Reset the flags used by the revision walking api. You can use - this to do multiple sequential revision walks. - -Data structures ---------------- - -Talk about <revision.h>, things like: - -* two diff_options, one for path limiting, another for output; -* remaining functions; - -(Linus, JC, Dscho) diff --git a/third_party/git/Documentation/technical/api-run-command.txt b/third_party/git/Documentation/technical/api-run-command.txt deleted file mode 100644 index 8bf3e37f53..0000000000 --- a/third_party/git/Documentation/technical/api-run-command.txt +++ /dev/null @@ -1,264 +0,0 @@ -run-command API -=============== - -The run-command API offers a versatile tool to run sub-processes with -redirected input and output as well as with a modified environment -and an alternate current directory. - -A similar API offers the capability to run a function asynchronously, -which is primarily used to capture the output that the function -produces in the caller in order to process it. - - -Functions ---------- - -`child_process_init`:: - - Initialize a struct child_process variable. - -`start_command`:: - - Start a sub-process. Takes a pointer to a `struct child_process` - that specifies the details and returns pipe FDs (if requested). - See below for details. - -`finish_command`:: - - Wait for the completion of a sub-process that was started with - start_command(). - -`run_command`:: - - A convenience function that encapsulates a sequence of - start_command() followed by finish_command(). Takes a pointer - to a `struct child_process` that specifies the details. - -`run_command_v_opt`, `run_command_v_opt_cd_env`:: - - Convenience functions that encapsulate a sequence of - start_command() followed by finish_command(). The argument argv - specifies the program and its arguments. The argument opt is zero - or more of the flags `RUN_COMMAND_NO_STDIN`, `RUN_GIT_CMD`, - `RUN_COMMAND_STDOUT_TO_STDERR`, or `RUN_SILENT_EXEC_FAILURE` - that correspond to the members .no_stdin, .git_cmd, - .stdout_to_stderr, .silent_exec_failure of `struct child_process`. - The argument dir corresponds the member .dir. The argument env - corresponds to the member .env. - -`child_process_clear`:: - - Release the memory associated with the struct child_process. - Most users of the run-command API don't need to call this - function explicitly because `start_command` invokes it on - failure and `finish_command` calls it automatically already. - -The functions above do the following: - -. If a system call failed, errno is set and -1 is returned. A diagnostic - is printed. - -. If the program was not found, then -1 is returned and errno is set to - ENOENT; a diagnostic is printed only if .silent_exec_failure is 0. - -. Otherwise, the program is run. If it terminates regularly, its exit - code is returned. No diagnostic is printed, even if the exit code is - non-zero. - -. If the program terminated due to a signal, then the return value is the - signal number + 128, ie. the same value that a POSIX shell's $? would - report. A diagnostic is printed. - - -`start_async`:: - - Run a function asynchronously. Takes a pointer to a `struct - async` that specifies the details and returns a set of pipe FDs - for communication with the function. See below for details. - -`finish_async`:: - - Wait for the completion of an asynchronous function that was - started with start_async(). - -`run_hook`:: - - Run a hook. - The first argument is a pathname to an index file, or NULL - if the hook uses the default index file or no index is needed. - The second argument is the name of the hook. - The further arguments correspond to the hook arguments. - The last argument has to be NULL to terminate the arguments list. - If the hook does not exist or is not executable, the return - value will be zero. - If it is executable, the hook will be executed and the exit - status of the hook is returned. - On execution, .stdout_to_stderr and .no_stdin will be set. - (See below.) - - -Data structures ---------------- - -* `struct child_process` - -This describes the arguments, redirections, and environment of a -command to run in a sub-process. - -The caller: - -1. allocates and clears (using child_process_init() or - CHILD_PROCESS_INIT) a struct child_process variable; -2. initializes the members; -3. calls start_command(); -4. processes the data; -5. closes file descriptors (if necessary; see below); -6. calls finish_command(). - -The .argv member is set up as an array of string pointers (NULL -terminated), of which .argv[0] is the program name to run (usually -without a path). If the command to run is a git command, set argv[0] to -the command name without the 'git-' prefix and set .git_cmd = 1. - -Note that the ownership of the memory pointed to by .argv stays with the -caller, but it should survive until `finish_command` completes. If the -.argv member is NULL, `start_command` will point it at the .args -`argv_array` (so you may use one or the other, but you must use exactly -one). The memory in .args will be cleaned up automatically during -`finish_command` (or during `start_command` when it is unsuccessful). - -The members .in, .out, .err are used to redirect stdin, stdout, -stderr as follows: - -. Specify 0 to request no special redirection. No new file descriptor - is allocated. The child process simply inherits the channel from the - parent. - -. Specify -1 to have a pipe allocated; start_command() replaces -1 - by the pipe FD in the following way: - - .in: Returns the writable pipe end into which the caller writes; - the readable end of the pipe becomes the child's stdin. - - .out, .err: Returns the readable pipe end from which the caller - reads; the writable end of the pipe end becomes child's - stdout/stderr. - - The caller of start_command() must close the so returned FDs - after it has completed reading from/writing to it! - -. Specify a file descriptor > 0 to be used by the child: - - .in: The FD must be readable; it becomes child's stdin. - .out: The FD must be writable; it becomes child's stdout. - .err: The FD must be writable; it becomes child's stderr. - - The specified FD is closed by start_command(), even if it fails to - run the sub-process! - -. Special forms of redirection are available by setting these members - to 1: - - .no_stdin, .no_stdout, .no_stderr: The respective channel is - redirected to /dev/null. - - .stdout_to_stderr: stdout of the child is redirected to its - stderr. This happens after stderr is itself redirected. - So stdout will follow stderr to wherever it is - redirected. - -To modify the environment of the sub-process, specify an array of -string pointers (NULL terminated) in .env: - -. If the string is of the form "VAR=value", i.e. it contains '=' - the variable is added to the child process's environment. - -. If the string does not contain '=', it names an environment - variable that will be removed from the child process's environment. - -If the .env member is NULL, `start_command` will point it at the -.env_array `argv_array` (so you may use one or the other, but not both). -The memory in .env_array will be cleaned up automatically during -`finish_command` (or during `start_command` when it is unsuccessful). - -To specify a new initial working directory for the sub-process, -specify it in the .dir member. - -If the program cannot be found, the functions return -1 and set -errno to ENOENT. Normally, an error message is printed, but if -.silent_exec_failure is set to 1, no message is printed for this -special error condition. - - -* `struct async` - -This describes a function to run asynchronously, whose purpose is -to produce output that the caller reads. - -The caller: - -1. allocates and clears (memset(&asy, 0, sizeof(asy));) a - struct async variable; -2. initializes .proc and .data; -3. calls start_async(); -4. processes communicates with proc through .in and .out; -5. closes .in and .out; -6. calls finish_async(). - -The members .in, .out are used to provide a set of fd's for -communication between the caller and the callee as follows: - -. Specify 0 to have no file descriptor passed. The callee will - receive -1 in the corresponding argument. - -. Specify < 0 to have a pipe allocated; start_async() replaces - with the pipe FD in the following way: - - .in: Returns the writable pipe end into which the caller - writes; the readable end of the pipe becomes the function's - in argument. - - .out: Returns the readable pipe end from which the caller - reads; the writable end of the pipe becomes the function's - out argument. - - The caller of start_async() must close the returned FDs after it - has completed reading from/writing from them. - -. Specify a file descriptor > 0 to be used by the function: - - .in: The FD must be readable; it becomes the function's in. - .out: The FD must be writable; it becomes the function's out. - - The specified FD is closed by start_async(), even if it fails to - run the function. - -The function pointer in .proc has the following signature: - - int proc(int in, int out, void *data); - -. in, out specifies a set of file descriptors to which the function - must read/write the data that it needs/produces. The function - *must* close these descriptors before it returns. A descriptor - may be -1 if the caller did not configure a descriptor for that - direction. - -. data is the value that the caller has specified in the .data member - of struct async. - -. The return value of the function is 0 on success and non-zero - on failure. If the function indicates failure, finish_async() will - report failure as well. - - -There are serious restrictions on what the asynchronous function can do -because this facility is implemented by a thread in the same address -space on most platforms (when pthreads is available), but by a pipe to -a forked process otherwise: - -. It cannot change the program's state (global variables, environment, - etc.) in a way that the caller notices; in other words, .in and .out - are the only communication channels to the caller. - -. It must not change the program's state that the caller of the - facility also uses. diff --git a/third_party/git/Documentation/technical/api-setup.txt b/third_party/git/Documentation/technical/api-setup.txt deleted file mode 100644 index eb1fa9853e..0000000000 --- a/third_party/git/Documentation/technical/api-setup.txt +++ /dev/null @@ -1,47 +0,0 @@ -setup API -========= - -Talk about - -* setup_git_directory() -* setup_git_directory_gently() -* is_inside_git_dir() -* is_inside_work_tree() -* setup_work_tree() - -(Dscho) - -Pathspec --------- - -See glossary-context.txt for the syntax of pathspec. In memory, a -pathspec set is represented by "struct pathspec" and is prepared by -parse_pathspec(). This function takes several arguments: - -- magic_mask specifies what features that are NOT supported by the - following code. If a user attempts to use such a feature, - parse_pathspec() can reject it early. - -- flags specifies other things that the caller wants parse_pathspec to - perform. - -- prefix and args come from cmd_* functions - -parse_pathspec() helps catch unsupported features and reject them -politely. At a lower level, different pathspec-related functions may -not support the same set of features. Such pathspec-sensitive -functions are guarded with GUARD_PATHSPEC(), which will die in an -unfriendly way when an unsupported feature is requested. - -The command designers are supposed to make sure that GUARD_PATHSPEC() -never dies. They have to make sure all unsupported features are caught -by parse_pathspec(), not by GUARD_PATHSPEC. grepping GUARD_PATHSPEC() -should give the designers all pathspec-sensitive codepaths and what -features they support. - -A similar process is applied when a new pathspec magic is added. The -designer lifts the GUARD_PATHSPEC restriction in the functions that -support the new magic. At the same time (s)he has to make sure this -new feature will be caught at parse_pathspec() in commands that cannot -handle the new magic in some cases. grepping parse_pathspec() should -help. diff --git a/third_party/git/Documentation/technical/api-sigchain.txt b/third_party/git/Documentation/technical/api-sigchain.txt deleted file mode 100644 index 9e1189ef01..0000000000 --- a/third_party/git/Documentation/technical/api-sigchain.txt +++ /dev/null @@ -1,41 +0,0 @@ -sigchain API -============ - -Code often wants to set a signal handler to clean up temporary files or -other work-in-progress when we die unexpectedly. For multiple pieces of -code to do this without conflicting, each piece of code must remember -the old value of the handler and restore it either when: - - 1. The work-in-progress is finished, and the handler is no longer - necessary. The handler should revert to the original behavior - (either another handler, SIG_DFL, or SIG_IGN). - - 2. The signal is received. We should then do our cleanup, then chain - to the next handler (or die if it is SIG_DFL). - -Sigchain is a tiny library for keeping a stack of handlers. Your handler -and installation code should look something like: - ------------------------------------------- - void clean_foo_on_signal(int sig) - { - clean_foo(); - sigchain_pop(sig); - raise(sig); - } - - void other_func() - { - sigchain_push_common(clean_foo_on_signal); - mess_up_foo(); - clean_foo(); - } ------------------------------------------- - -Handlers are given the typedef of sigchain_fun. This is the same type -that is given to signal() or sigaction(). It is perfectly reasonable to -push SIG_DFL or SIG_IGN onto the stack. - -You can sigchain_push and sigchain_pop individual signals. For -convenience, sigchain_push_common will push the handler onto the stack -for many common signals. diff --git a/third_party/git/Documentation/technical/api-submodule-config.txt b/third_party/git/Documentation/technical/api-submodule-config.txt deleted file mode 100644 index fb06089393..0000000000 --- a/third_party/git/Documentation/technical/api-submodule-config.txt +++ /dev/null @@ -1,66 +0,0 @@ -submodule config cache API -========================== - -The submodule config cache API allows to read submodule -configurations/information from specified revisions. Internally -information is lazily read into a cache that is used to avoid -unnecessary parsing of the same .gitmodules files. Lookups can be done by -submodule path or name. - -Usage ------ - -To initialize the cache with configurations from the worktree the caller -typically first calls `gitmodules_config()` to read values from the -worktree .gitmodules and then to overlay the local git config values -`parse_submodule_config_option()` from the config parsing -infrastructure. - -The caller can look up information about submodules by using the -`submodule_from_path()` or `submodule_from_name()` functions. They return -a `struct submodule` which contains the values. The API automatically -initializes and allocates the needed infrastructure on-demand. If the -caller does only want to lookup values from revisions the initialization -can be skipped. - -If the internal cache might grow too big or when the caller is done with -the API, all internally cached values can be freed with submodule_free(). - -Data Structures ---------------- - -`struct submodule`:: - - This structure is used to return the information about one - submodule for a certain revision. It is returned by the lookup - functions. - -Functions ---------- - -`void submodule_free(struct repository *r)`:: - - Use these to free the internally cached values. - -`int parse_submodule_config_option(const char *var, const char *value)`:: - - Can be passed to the config parsing infrastructure to parse - local (worktree) submodule configurations. - -`const struct submodule *submodule_from_path(const unsigned char *treeish_name, const char *path)`:: - - Given a tree-ish in the superproject and a path, return the - submodule that is bound at the path in the named tree. - -`const struct submodule *submodule_from_name(const unsigned char *treeish_name, const char *name)`:: - - The same as above but lookup by name. - -Whenever a submodule configuration is parsed in `parse_submodule_config_option` -via e.g. `gitmodules_config()`, it will overwrite the null_sha1 entry. -So in the normal case, when HEAD:.gitmodules is parsed first and then overlayed -with the repository configuration, the null_sha1 entry contains the local -configuration of a submodule (e.g. consolidated values from local git -configuration and the .gitmodules file in the worktree). - -For an example usage see test-submodule-config.c. diff --git a/third_party/git/Documentation/technical/api-trace.txt b/third_party/git/Documentation/technical/api-trace.txt deleted file mode 100644 index fadb5979c4..0000000000 --- a/third_party/git/Documentation/technical/api-trace.txt +++ /dev/null @@ -1,140 +0,0 @@ -trace API -========= - -The trace API can be used to print debug messages to stderr or a file. Trace -code is inactive unless explicitly enabled by setting `GIT_TRACE*` environment -variables. - -The trace implementation automatically adds `timestamp file:line ... \n` to -all trace messages. E.g.: - ------------- -23:59:59.123456 git.c:312 trace: built-in: git 'foo' -00:00:00.000001 builtin/foo.c:99 foo: some message ------------- - -Data Structures ---------------- - -`struct trace_key`:: - - Defines a trace key (or category). The default (for API functions that - don't take a key) is `GIT_TRACE`. -+ -E.g. to define a trace key controlled by environment variable `GIT_TRACE_FOO`: -+ ------------- -static struct trace_key trace_foo = TRACE_KEY_INIT(FOO); - -static void trace_print_foo(const char *message) -{ - trace_printf_key(&trace_foo, "%s", message); -} ------------- -+ -Note: don't use `const` as the trace implementation stores internal state in -the `trace_key` structure. - -Functions ---------- - -`int trace_want(struct trace_key *key)`:: - - Checks whether the trace key is enabled. Used to prevent expensive - string formatting before calling one of the printing APIs. - -`void trace_disable(struct trace_key *key)`:: - - Disables tracing for the specified key, even if the environment - variable was set. - -`void trace_printf(const char *format, ...)`:: -`void trace_printf_key(struct trace_key *key, const char *format, ...)`:: - - Prints a formatted message, similar to printf. - -`void trace_argv_printf(const char **argv, const char *format, ...)``:: - - Prints a formatted message, followed by a quoted list of arguments. - -`void trace_strbuf(struct trace_key *key, const struct strbuf *data)`:: - - Prints the strbuf, without additional formatting (i.e. doesn't - choke on `%` or even `\0`). - -`uint64_t getnanotime(void)`:: - - Returns nanoseconds since the epoch (01/01/1970), typically used - for performance measurements. -+ -Currently there are high precision timer implementations for Linux (using -`clock_gettime(CLOCK_MONOTONIC)`) and Windows (`QueryPerformanceCounter`). -Other platforms use `gettimeofday` as time source. - -`void trace_performance(uint64_t nanos, const char *format, ...)`:: -`void trace_performance_since(uint64_t start, const char *format, ...)`:: - - Prints the elapsed time (in nanoseconds), or elapsed time since - `start`, followed by a formatted message. Enabled via environment - variable `GIT_TRACE_PERFORMANCE`. Used for manual profiling, e.g.: -+ ------------- -uint64_t start = getnanotime(); -/* code section to measure */ -trace_performance_since(start, "foobar"); ------------- -+ ------------- -uint64_t t = 0; -for (;;) { - /* ignore */ - t -= getnanotime(); - /* code section to measure */ - t += getnanotime(); - /* ignore */ -} -trace_performance(t, "frotz"); ------------- - -Bugs & Caveats --------------- - -GIT_TRACE_* environment variables can be used to tell Git to show -trace output to its standard error stream. Git can often spawn a pager -internally to run its subcommand and send its standard output and -standard error to it. - -Because GIT_TRACE_PERFORMANCE trace is generated only at the very end -of the program with atexit(), which happens after the pager exits, it -would not work well if you send its log to the standard error output -and let Git spawn the pager at the same time. - -As a work around, you can for example use '--no-pager', or set -GIT_TRACE_PERFORMANCE to another file descriptor which is redirected -to stderr, or set GIT_TRACE_PERFORMANCE to a file specified by its -absolute path. - -For example instead of the following command which by default may not -print any performance information: - ------------- -GIT_TRACE_PERFORMANCE=2 git log -1 ------------- - -you may want to use: - ------------- -GIT_TRACE_PERFORMANCE=2 git --no-pager log -1 ------------- - -or: - ------------- -GIT_TRACE_PERFORMANCE=3 3>&2 git log -1 ------------- - -or: - ------------- -GIT_TRACE_PERFORMANCE=/path/to/log/file git log -1 ------------- diff --git a/third_party/git/Documentation/technical/api-trace2.txt b/third_party/git/Documentation/technical/api-trace2.txt deleted file mode 100644 index 71eb081fed..0000000000 --- a/third_party/git/Documentation/technical/api-trace2.txt +++ /dev/null @@ -1,1378 +0,0 @@ -= Trace2 API - -The Trace2 API can be used to print debug, performance, and telemetry -information to stderr or a file. The Trace2 feature is inactive unless -explicitly enabled by enabling one or more Trace2 Targets. - -The Trace2 API is intended to replace the existing (Trace1) -printf-style tracing provided by the existing `GIT_TRACE` and -`GIT_TRACE_PERFORMANCE` facilities. During initial implementation, -Trace2 and Trace1 may operate in parallel. - -The Trace2 API defines a set of high-level messages with known fields, -such as (`start`: `argv`) and (`exit`: {`exit-code`, `elapsed-time`}). - -Trace2 instrumentation throughout the Git code base sends Trace2 -messages to the enabled Trace2 Targets. Targets transform these -messages content into purpose-specific formats and write events to -their data streams. In this manner, the Trace2 API can drive -many different types of analysis. - -Targets are defined using a VTable allowing easy extension to other -formats in the future. This might be used to define a binary format, -for example. - -Trace2 is controlled using `trace2.*` config values in the system and -global config files and `GIT_TRACE2*` environment variables. Trace2 does -not read from repo local or worktree config files or respect `-c` -command line config settings. - -== Trace2 Targets - -Trace2 defines the following set of Trace2 Targets. -Format details are given in a later section. - -=== The Normal Format Target - -The normal format target is a tradition printf format and similar -to GIT_TRACE format. This format is enabled with the `GIT_TRACE2` -environment variable or the `trace2.normalTarget` system or global -config setting. - -For example - ------------- -$ export GIT_TRACE2=~/log.normal -$ git version -git version 2.20.1.155.g426c96fcdb ------------- - -or - ------------- -$ git config --global trace2.normalTarget ~/log.normal -$ git version -git version 2.20.1.155.g426c96fcdb ------------- - -yields - ------------- -$ cat ~/log.normal -12:28:42.620009 common-main.c:38 version 2.20.1.155.g426c96fcdb -12:28:42.620989 common-main.c:39 start git version -12:28:42.621101 git.c:432 cmd_name version (version) -12:28:42.621215 git.c:662 exit elapsed:0.001227 code:0 -12:28:42.621250 trace2/tr2_tgt_normal.c:124 atexit elapsed:0.001265 code:0 ------------- - -=== The Performance Format Target - -The performance format target (PERF) is a column-based format to -replace GIT_TRACE_PERFORMANCE and is suitable for development and -testing, possibly to complement tools like gprof. This format is -enabled with the `GIT_TRACE2_PERF` environment variable or the -`trace2.perfTarget` system or global config setting. - -For example - ------------- -$ export GIT_TRACE2_PERF=~/log.perf -$ git version -git version 2.20.1.155.g426c96fcdb ------------- - -or - ------------- -$ git config --global trace2.perfTarget ~/log.perf -$ git version -git version 2.20.1.155.g426c96fcdb ------------- - -yields - ------------- -$ cat ~/log.perf -12:28:42.620675 common-main.c:38 | d0 | main | version | | | | | 2.20.1.155.g426c96fcdb -12:28:42.621001 common-main.c:39 | d0 | main | start | | 0.001173 | | | git version -12:28:42.621111 git.c:432 | d0 | main | cmd_name | | | | | version (version) -12:28:42.621225 git.c:662 | d0 | main | exit | | 0.001227 | | | code:0 -12:28:42.621259 trace2/tr2_tgt_perf.c:211 | d0 | main | atexit | | 0.001265 | | | code:0 ------------- - -=== The Event Format Target - -The event format target is a JSON-based format of event data suitable -for telemetry analysis. This format is enabled with the `GIT_TRACE2_EVENT` -environment variable or the `trace2.eventTarget` system or global config -setting. - -For example - ------------- -$ export GIT_TRACE2_EVENT=~/log.event -$ git version -git version 2.20.1.155.g426c96fcdb ------------- - -or - ------------- -$ git config --global trace2.eventTarget ~/log.event -$ git version -git version 2.20.1.155.g426c96fcdb ------------- - -yields - ------------- -$ cat ~/log.event -{"event":"version","sid":"sid":"20190408T191610.507018Z-H9b68c35f-P000059a8","thread":"main","time":"2019-01-16T17:28:42.620713Z","file":"common-main.c","line":38,"evt":"1","exe":"2.20.1.155.g426c96fcdb"} -{"event":"start","sid":"20190408T191610.507018Z-H9b68c35f-P000059a8","thread":"main","time":"2019-01-16T17:28:42.621027Z","file":"common-main.c","line":39,"t_abs":0.001173,"argv":["git","version"]} -{"event":"cmd_name","sid":"20190408T191610.507018Z-H9b68c35f-P000059a8","thread":"main","time":"2019-01-16T17:28:42.621122Z","file":"git.c","line":432,"name":"version","hierarchy":"version"} -{"event":"exit","sid":"20190408T191610.507018Z-H9b68c35f-P000059a8","thread":"main","time":"2019-01-16T17:28:42.621236Z","file":"git.c","line":662,"t_abs":0.001227,"code":0} -{"event":"atexit","sid":"20190408T191610.507018Z-H9b68c35f-P000059a8","thread":"main","time":"2019-01-16T17:28:42.621268Z","file":"trace2/tr2_tgt_event.c","line":163,"t_abs":0.001265,"code":0} ------------- - -=== Enabling a Target - -To enable a target, set the corresponding environment variable or -system or global config value to one of the following: - -include::../trace2-target-values.txt[] - -If the target already exists and is a directory, the traces will be -written to files (one per process) underneath the given directory. They -will be named according to the last component of the SID (optionally -followed by a counter to avoid filename collisions). - -== Trace2 API - -All public Trace2 functions and macros are defined in `trace2.h` and -`trace2.c`. All public symbols are prefixed with `trace2_`. - -There are no public Trace2 data structures. - -The Trace2 code also defines a set of private functions and data types -in the `trace2/` directory. These symbols are prefixed with `tr2_` -and should only be used by functions in `trace2.c`. - -== Conventions for Public Functions and Macros - -The functions defined by the Trace2 API are declared and documented -in `trace2.h`. It defines the API functions and wrapper macros for -Trace2. - -Some functions have a `_fl()` suffix to indicate that they take `file` -and `line-number` arguments. - -Some functions have a `_va_fl()` suffix to indicate that they also -take a `va_list` argument. - -Some functions have a `_printf_fl()` suffix to indicate that they also -take a varargs argument. - -There are CPP wrapper macros and ifdefs to hide most of these details. -See `trace2.h` for more details. The following discussion will only -describe the simplified forms. - -== Public API - -All Trace2 API functions send a messsage to all of the active -Trace2 Targets. This section describes the set of available -messages. - -It helps to divide these functions into groups for discussion -purposes. - -=== Basic Command Messages - -These are concerned with the lifetime of the overall git process. - -`void trace2_initialize_clock()`:: - - Initialize the Trace2 start clock and nothing else. This should - be called at the very top of main() to capture the process start - time and reduce startup order dependencies. - -`void trace2_initialize()`:: - - Determines if any Trace2 Targets should be enabled and - initializes the Trace2 facility. This includes setting up the - Trace2 thread local storage (TLS). -+ -This function emits a "version" message containing the version of git -and the Trace2 protocol. -+ -This function should be called from `main()` as early as possible in -the life of the process after essential process initialization. - -`int trace2_is_enabled()`:: - - Returns 1 if Trace2 is enabled (at least one target is - active). - -`void trace2_cmd_start(int argc, const char **argv)`:: - - Emits a "start" message containing the process command line - arguments. - -`int trace2_cmd_exit(int exit_code)`:: - - Emits an "exit" message containing the process exit-code and - elapsed time. -+ -Returns the exit-code. - -`void trace2_cmd_error(const char *fmt, va_list ap)`:: - - Emits an "error" message containing a formatted error message. - -`void trace2_cmd_path(const char *pathname)`:: - - Emits a "cmd_path" message with the full pathname of the - current process. - -=== Command Detail Messages - -These are concerned with describing the specific Git command -after the command line, config, and environment are inspected. - -`void trace2_cmd_name(const char *name)`:: - - Emits a "cmd_name" message with the canonical name of the - command, for example "status" or "checkout". - -`void trace2_cmd_mode(const char *mode)`:: - - Emits a "cmd_mode" message with a qualifier name to further - describe the current git command. -+ -This message is intended to be used with git commands having multiple -major modes. For example, a "checkout" command can checkout a new -branch or it can checkout a single file, so the checkout code could -emit a cmd_mode message of "branch" or "file". - -`void trace2_cmd_alias(const char *alias, const char **argv_expansion)`:: - - Emits an "alias" message containing the alias used and the - argument expansion. - -`void trace2_def_param(const char *parameter, const char *value)`:: - - Emits a "def_param" message containing a key/value pair. -+ -This message is intended to report some global aspect of the current -command, such as a configuration setting or command line switch that -significantly affects program performance or behavior, such as -`core.abbrev`, `status.showUntrackedFiles`, or `--no-ahead-behind`. - -`void trace2_cmd_list_config()`:: - - Emits a "def_param" messages for "important" configuration - settings. -+ -The environment variable `GIT_TRACE2_CONFIG_PARAMS` or the `trace2.configParams` -config value can be set to a -list of patterns of important configuration settings, for example: -`core.*,remote.*.url`. This function will iterate over all config -settings and emit a "def_param" message for each match. - -`void trace2_cmd_set_config(const char *key, const char *value)`:: - - Emits a "def_param" message for a new or updated key/value - pair IF `key` is considered important. -+ -This is used to hook into `git_config_set()` and catch any -configuration changes and update a value previously reported by -`trace2_cmd_list_config()`. - -`void trace2_def_repo(struct repository *repo)`:: - - Registers a repository with the Trace2 layer. Assigns a - unique "repo-id" to `repo->trace2_repo_id`. -+ -Emits a "worktree" messages containing the repo-id and the worktree -pathname. -+ -Region and data messages (described later) may refer to this repo-id. -+ -The main/top-level repository will have repo-id value 1 (aka "r1"). -+ -The repo-id field is in anticipation of future in-proc submodule -repositories. - -=== Child Process Messages - -These are concerned with the various spawned child processes, -including shell scripts, git commands, editors, pagers, and hooks. - -`void trace2_child_start(struct child_process *cmd)`:: - - Emits a "child_start" message containing the "child-id", - "child-argv", and "child-classification". -+ -Before calling this, set `cmd->trace2_child_class` to a name -describing the type of child process, for example "editor". -+ -This function assigns a unique "child-id" to `cmd->trace2_child_id`. -This field is used later during the "child_exit" message to associate -it with the "child_start" message. -+ -This function should be called before spawning the child process. - -`void trace2_child_exit(struct child_proess *cmd, int child_exit_code)`:: - - Emits a "child_exit" message containing the "child-id", - the child's elapsed time and exit-code. -+ -The reported elapsed time includes the process creation overhead and -time spend waiting for it to exit, so it may be slightly longer than -the time reported by the child itself. -+ -This function should be called after reaping the child process. - -`int trace2_exec(const char *exe, const char **argv)`:: - - Emits a "exec" message containing the "exec-id" and the - argv of the new process. -+ -This function should be called before calling one of the `exec()` -variants, such as `execvp()`. -+ -This function returns a unique "exec-id". This value is used later -if the exec() fails and a "exec-result" message is necessary. - -`void trace2_exec_result(int exec_id, int error_code)`:: - - Emits a "exec_result" message containing the "exec-id" - and the error code. -+ -On Unix-based systems, `exec()` does not return if successful. -This message is used to indicate that the `exec()` failed and -that the current program is continuing. - -=== Git Thread Messages - -These messages are concerned with Git thread usage. - -`void trace2_thread_start(const char *thread_name)`:: - - Emits a "thread_start" message. -+ -The `thread_name` field should be a descriptive name, such as the -unique name of the thread-proc. A unique "thread-id" will be added -to the name to uniquely identify thread instances. -+ -Region and data messages (described later) may refer to this thread -name. -+ -This function must be called by the thread-proc of the new thread -(so that TLS data is properly initialized) and not by the caller -of `pthread_create()`. - -`void trace2_thread_exit()`:: - - Emits a "thread_exit" message containing the thread name - and the thread elapsed time. -+ -This function must be called by the thread-proc before it returns -(so that the coorect TLS data is used and cleaned up. It should -not be called by the caller of `pthread_join()`. - -=== Region and Data Messages - -These are concerned with recording performance data -over regions or spans of code. - -`void trace2_region_enter(const char *category, const char *label, const struct repository *repo)`:: - -`void trace2_region_enter_printf(const char *category, const char *label, const struct repository *repo, const char *fmt, ...)`:: - -`void trace2_region_enter_printf_va(const char *category, const char *label, const struct repository *repo, const char *fmt, va_list ap)`:: - - Emits a thread-relative "region_enter" message with optional - printf string. -+ -This function pushes a new region nesting stack level on the current -thread and starts a clock for the new stack frame. -+ -The `category` field is an arbitrary category name used to classify -regions by feature area, such as "status" or "index". At this time -it is only just printed along with the rest of the message. It may -be used in the future to filter messages. -+ -The `label` field is an arbitrary label used to describe the activity -being started, such as "read_recursive" or "do_read_index". -+ -The `repo` field, if set, will be used to get the "repo-id", so that -recursive oerations can be attributed to the correct repository. - -`void trace2_region_leave(const char *category, const char *label, const struct repository *repo)`:: - -`void trace2_region_leave_printf(const char *category, const char *label, const struct repository *repo, const char *fmt, ...)`:: - -`void trace2_region_leave_printf_va(const char *category, const char *label, const struct repository *repo, const char *fmt, va_list ap)`:: - - Emits a thread-relative "region_leave" message with optional - printf string. -+ -This function pops the region nesting stack on the current thread -and reports the elapsed time of the stack frame. -+ -The `category`, `label`, and `repo` fields are the same as above. -The `category` and `label` do not need to match the correpsonding -"region_enter" message, but it makes the data stream easier to -understand. - -`void trace2_data_string(const char *category, const struct repository *repo, const char *key, const char * value)`:: - -`void trace2_data_intmax(const char *category, const struct repository *repo, const char *key, intmax value)`:: - -`void trace2_data_json(const char *category, const struct repository *repo, const char *key, const struct json_writer *jw)`:: - - Emits a region- and thread-relative "data" or "data_json" message. -+ -This is a key/value pair message containing information about the -current thread, region stack, and repository. This could be used -to print the number of files in a directory during a multi-threaded -recursive tree walk. - -`void trace2_printf(const char *fmt, ...)`:: - -`void trace2_printf_va(const char *fmt, va_list ap)`:: - - Emits a region- and thread-relative "printf" message. - -== Trace2 Target Formats - -=== NORMAL Format - -Events are written as lines of the form: - ------------- -[<time> SP <filename>:<line> SP+] <event-name> [[SP] <event-message>] LF ------------- - -`<event-name>`:: - - is the event name. - -`<event-message>`:: - is a free-form printf message intended for human consumption. -+ -Note that this may contain embedded LF or CRLF characters that are -not escaped, so the event may spill across multiple lines. - -If `GIT_TRACE2_BRIEF` or `trace2.normalBrief` is true, the `time`, `filename`, -and `line` fields are omitted. - -This target is intended to be more of a summary (like GIT_TRACE) and -less detailed than the other targets. It ignores thread, region, and -data messages, for example. - -=== PERF Format - -Events are written as lines of the form: - ------------- -[<time> SP <filename>:<line> SP+ - BAR SP] d<depth> SP - BAR SP <thread-name> SP+ - BAR SP <event-name> SP+ - BAR SP [r<repo-id>] SP+ - BAR SP [<t_abs>] SP+ - BAR SP [<t_rel>] SP+ - BAR SP [<category>] SP+ - BAR SP DOTS* <perf-event-message> - LF ------------- - -`<depth>`:: - is the git process depth. This is the number of parent - git processes. A top-level git command has depth value "d0". - A child of it has depth value "d1". A second level child - has depth value "d2" and so on. - -`<thread-name>`:: - is a unique name for the thread. The primary thread - is called "main". Other thread names are of the form "th%d:%s" - and include a unique number and the name of the thread-proc. - -`<event-name>`:: - is the event name. - -`<repo-id>`:: - when present, is a number indicating the repository - in use. A `def_repo` event is emitted when a repository is - opened. This defines the repo-id and associated worktree. - Subsequent repo-specific events will reference this repo-id. -+ -Currently, this is always "r1" for the main repository. -This field is in anticipation of in-proc submodules in the future. - -`<t_abs>`:: - when present, is the absolute time in seconds since the - program started. - -`<t_rel>`:: - when present, is time in seconds relative to the start of - the current region. For a thread-exit event, it is the elapsed - time of the thread. - -`<category>`:: - is present on region and data events and is used to - indicate a broad category, such as "index" or "status". - -`<perf-event-message>`:: - is a free-form printf message intended for human consumption. - ------------- -15:33:33.532712 wt-status.c:2310 | d0 | main | region_enter | r1 | 0.126064 | | status | label:print -15:33:33.532712 wt-status.c:2331 | d0 | main | region_leave | r1 | 0.127568 | 0.001504 | status | label:print ------------- - -If `GIT_TRACE2_PERF_BRIEF` or `trace2.perfBrief` is true, the `time`, `file`, -and `line` fields are omitted. - ------------- -d0 | main | region_leave | r1 | 0.011717 | 0.009122 | index | label:preload ------------- - -The PERF target is intended for interactive performance analysis -during development and is quite noisy. - -=== EVENT Format - -Each event is a JSON-object containing multiple key/value pairs -written as a single line and followed by a LF. - ------------- -'{' <key> ':' <value> [',' <key> ':' <value>]* '}' LF ------------- - -Some key/value pairs are common to all events and some are -event-specific. - -==== Common Key/Value Pairs - -The following key/value pairs are common to all events: - ------------- -{ - "event":"version", - "sid":"20190408T191827.272759Z-H9b68c35f-P00003510", - "thread":"main", - "time":"2019-04-08T19:18:27.282761Z", - "file":"common-main.c", - "line":42, - ... -} ------------- - -`"event":<event>`:: - is the event name. - -`"sid":<sid>`:: - is the session-id. This is a unique string to identify the - process instance to allow all events emitted by a process to - be identified. A session-id is used instead of a PID because - PIDs are recycled by the OS. For child git processes, the - session-id is prepended with the session-id of the parent git - process to allow parent-child relationships to be identified - during post-processing. - -`"thread":<thread>`:: - is the thread name. - -`"time":<time>`:: - is the UTC time of the event. - -`"file":<filename>`:: - is source file generating the event. - -`"line":<line-number>`:: - is the integer source line number generating the event. - -`"repo":<repo-id>`:: - when present, is the integer repo-id as described previously. - -If `GIT_TRACE2_EVENT_BRIEF` or `trace2.eventBrief` is true, the `file` -and `line` fields are omitted from all events and the `time` field is -only present on the "start" and "atexit" events. - -==== Event-Specific Key/Value Pairs - -`"version"`:: - This event gives the version of the executable and the EVENT format. -+ ------------- -{ - "event":"version", - ... - "evt":"1", # EVENT format version - "exe":"2.20.1.155.g426c96fcdb" # git version -} ------------- - -`"start"`:: - This event contains the complete argv received by main(). -+ ------------- -{ - "event":"start", - ... - "t_abs":0.001227, # elapsed time in seconds - "argv":["git","version"] -} ------------- - -`"exit"`:: - This event is emitted when git calls `exit()`. -+ ------------- -{ - "event":"exit", - ... - "t_abs":0.001227, # elapsed time in seconds - "code":0 # exit code -} ------------- - -`"atexit"`:: - This event is emitted by the Trace2 `atexit` routine during - final shutdown. It should be the last event emitted by the - process. -+ -(The elapsed time reported here is greater than the time reported in -the "exit" event because it runs after all other atexit tasks have -completed.) -+ ------------- -{ - "event":"atexit", - ... - "t_abs":0.001227, # elapsed time in seconds - "code":0 # exit code -} ------------- - -`"signal"`:: - This event is emitted when the program is terminated by a user - signal. Depending on the platform, the signal event may - prevent the "atexit" event from being generated. -+ ------------- -{ - "event":"signal", - ... - "t_abs":0.001227, # elapsed time in seconds - "signo":13 # SIGTERM, SIGINT, etc. -} ------------- - -`"error"`:: - This event is emitted when one of the `error()`, `die()`, - or `usage()` functions are called. -+ ------------- -{ - "event":"error", - ... - "msg":"invalid option: --cahced", # formatted error message - "fmt":"invalid option: %s" # error format string -} ------------- -+ -The error event may be emitted more than once. The format string -allows post-processors to group errors by type without worrying -about specific error arguments. - -`"cmd_path"`:: - This event contains the discovered full path of the git - executable (on platforms that are configured to resolve it). -+ ------------- -{ - "event":"cmd_path", - ... - "path":"C:/work/gfw/git.exe" -} ------------- - -`"cmd_name"`:: - This event contains the command name for this git process - and the hierarchy of commands from parent git processes. -+ ------------- -{ - "event":"cmd_name", - ... - "name":"pack-objects", - "hierarchy":"push/pack-objects" -} ------------- -+ -Normally, the "name" field contains the canonical name of the -command. When a canonical name is not available, one of -these special values are used: -+ ------------- -"_query_" # "git --html-path" -"_run_dashed_" # when "git foo" tries to run "git-foo" -"_run_shell_alias_" # alias expansion to a shell command -"_run_git_alias_" # alias expansion to a git command -"_usage_" # usage error ------------- - -`"cmd_mode"`:: - This event, when present, describes the command variant This - event may be emitted more than once. -+ ------------- -{ - "event":"cmd_mode", - ... - "name":"branch" -} ------------- -+ -The "name" field is an arbitrary string to describe the command mode. -For example, checkout can checkout a branch or an individual file. -And these variations typically have different performance -characteristics that are not comparable. - -`"alias"`:: - This event is present when an alias is expanded. -+ ------------- -{ - "event":"alias", - ... - "alias":"l", # registered alias - "argv":["log","--graph"] # alias expansion -} ------------- - -`"child_start"`:: - This event describes a child process that is about to be - spawned. -+ ------------- -{ - "event":"child_start", - ... - "child_id":2, - "child_class":"?", - "use_shell":false, - "argv":["git","rev-list","--objects","--stdin","--not","--all","--quiet"] - - "hook_name":"<hook_name>" # present when child_class is "hook" - "cd":"<path>" # present when cd is required -} ------------- -+ -The "child_id" field can be used to match this child_start with the -corresponding child_exit event. -+ -The "child_class" field is a rough classification, such as "editor", -"pager", "transport/*", and "hook". Unclassified children are classified -with "?". - -`"child_exit"`:: - This event is generated after the current process has returned - from the waitpid() and collected the exit information from the - child. -+ ------------- -{ - "event":"child_exit", - ... - "child_id":2, - "pid":14708, # child PID - "code":0, # child exit-code - "t_rel":0.110605 # observed run-time of child process -} ------------- -+ -Note that the session-id of the child process is not available to -the current/spawning process, so the child's PID is reported here as -a hint for post-processing. (But it is only a hint because the child -proces may be a shell script which doesn't have a session-id.) -+ -Note that the `t_rel` field contains the observed run time in seconds -for the child process (starting before the fork/exec/spawn and -stopping after the waitpid() and includes OS process creation overhead). -So this time will be slightly larger than the atexit time reported by -the child process itself. - -`"exec"`:: - This event is generated before git attempts to `exec()` - another command rather than starting a child process. -+ ------------- -{ - "event":"exec", - ... - "exec_id":0, - "exe":"git", - "argv":["foo", "bar"] -} ------------- -+ -The "exec_id" field is a command-unique id and is only useful if the -`exec()` fails and a corresponding exec_result event is generated. - -`"exec_result"`:: - This event is generated if the `exec()` fails and control - returns to the current git command. -+ ------------- -{ - "event":"exec_result", - ... - "exec_id":0, - "code":1 # error code (errno) from exec() -} ------------- - -`"thread_start"`:: - This event is generated when a thread is started. It is - generated from *within* the new thread's thread-proc (for TLS - reasons). -+ ------------- -{ - "event":"thread_start", - ... - "thread":"th02:preload_thread" # thread name -} ------------- - -`"thread_exit"`:: - This event is generated when a thread exits. It is generated - from *within* the thread's thread-proc (for TLS reasons). -+ ------------- -{ - "event":"thread_exit", - ... - "thread":"th02:preload_thread", # thread name - "t_rel":0.007328 # thread elapsed time -} ------------- - -`"def_param"`:: - This event is generated to log a global parameter. -+ ------------- -{ - "event":"def_param", - ... - "param":"core.abbrev", - "value":"7" -} ------------- - -`"def_repo"`:: - This event defines a repo-id and associates it with the root - of the worktree. -+ ------------- -{ - "event":"def_repo", - ... - "repo":1, - "worktree":"/Users/jeffhost/work/gfw" -} ------------- -+ -As stated earlier, the repo-id is currently always 1, so there will -only be one def_repo event. Later, if in-proc submodules are -supported, a def_repo event should be emitted for each submodule -visited. - -`"region_enter"`:: - This event is generated when entering a region. -+ ------------- -{ - "event":"region_enter", - ... - "repo":1, # optional - "nesting":1, # current region stack depth - "category":"index", # optional - "label":"do_read_index", # optional - "msg":".git/index" # optional -} ------------- -+ -The `category` field may be used in a future enhancement to -do category-based filtering. -+ -`GIT_TRACE2_EVENT_NESTING` or `trace2.eventNesting` can be used to -filter deeply nested regions and data events. It defaults to "2". - -`"region_leave"`:: - This event is generated when leaving a region. -+ ------------- -{ - "event":"region_leave", - ... - "repo":1, # optional - "t_rel":0.002876, # time spent in region in seconds - "nesting":1, # region stack depth - "category":"index", # optional - "label":"do_read_index", # optional - "msg":".git/index" # optional -} ------------- - -`"data"`:: - This event is generated to log a thread- and region-local - key/value pair. -+ ------------- -{ - "event":"data", - ... - "repo":1, # optional - "t_abs":0.024107, # absolute elapsed time - "t_rel":0.001031, # elapsed time in region/thread - "nesting":2, # region stack depth - "category":"index", - "key":"read/cache_nr", - "value":"3552" -} ------------- -+ -The "value" field may be an integer or a string. - -`"data-json"`:: - This event is generated to log a pre-formatted JSON string - containing structured data. -+ ------------- -{ - "event":"data_json", - ... - "repo":1, # optional - "t_abs":0.015905, - "t_rel":0.015905, - "nesting":1, - "category":"process", - "key":"windows/ancestry", - "value":["bash.exe","bash.exe"] -} ------------- - -== Example Trace2 API Usage - -Here is a hypothetical usage of the Trace2 API showing the intended -usage (without worrying about the actual Git details). - -Initialization:: - - Initialization happens in `main()`. Behind the scenes, an - `atexit` and `signal` handler are registered. -+ ----------------- -int main(int argc, const char **argv) -{ - int exit_code; - - trace2_initialize(); - trace2_cmd_start(argv); - - exit_code = cmd_main(argc, argv); - - trace2_cmd_exit(exit_code); - - return exit_code; -} ----------------- - -Command Details:: - - After the basics are established, additional command - information can be sent to Trace2 as it is discovered. -+ ----------------- -int cmd_checkout(int argc, const char **argv) -{ - trace2_cmd_name("checkout"); - trace2_cmd_mode("branch"); - trace2_def_repo(the_repository); - - // emit "def_param" messages for "interesting" config settings. - trace2_cmd_list_config(); - - if (do_something()) - trace2_cmd_error("Path '%s': cannot do something", path); - - return 0; -} ----------------- - -Child Processes:: - - Wrap code spawning child processes. -+ ----------------- -void run_child(...) -{ - int child_exit_code; - struct child_process cmd = CHILD_PROCESS_INIT; - ... - cmd.trace2_child_class = "editor"; - - trace2_child_start(&cmd); - child_exit_code = spawn_child_and_wait_for_it(); - trace2_child_exit(&cmd, child_exit_code); -} ----------------- -+ -For example, the following fetch command spawned ssh, index-pack, -rev-list, and gc. This example also shows that fetch took -5.199 seconds and of that 4.932 was in ssh. -+ ----------------- -$ export GIT_TRACE2_BRIEF=1 -$ export GIT_TRACE2=~/log.normal -$ git fetch origin -... ----------------- -+ ----------------- -$ cat ~/log.normal -version 2.20.1.vfs.1.1.47.g534dbe1ad1 -start git fetch origin -worktree /Users/jeffhost/work/gfw -cmd_name fetch (fetch) -child_start[0] ssh git@github.com ... -child_start[1] git index-pack ... -... (Trace2 events from child processes omitted) -child_exit[1] pid:14707 code:0 elapsed:0.076353 -child_exit[0] pid:14706 code:0 elapsed:4.931869 -child_start[2] git rev-list ... -... (Trace2 events from child process omitted) -child_exit[2] pid:14708 code:0 elapsed:0.110605 -child_start[3] git gc --auto -... (Trace2 events from child process omitted) -child_exit[3] pid:14709 code:0 elapsed:0.006240 -exit elapsed:5.198503 code:0 -atexit elapsed:5.198541 code:0 ----------------- -+ -When a git process is a (direct or indirect) child of another -git process, it inherits Trace2 context information. This -allows the child to print the command hierarchy. This example -shows gc as child[3] of fetch. When the gc process reports -its name as "gc", it also reports the hierarchy as "fetch/gc". -(In this example, trace2 messages from the child process is -indented for clarity.) -+ ----------------- -$ export GIT_TRACE2_BRIEF=1 -$ export GIT_TRACE2=~/log.normal -$ git fetch origin -... ----------------- -+ ----------------- -$ cat ~/log.normal -version 2.20.1.160.g5676107ecd.dirty -start git fetch official -worktree /Users/jeffhost/work/gfw -cmd_name fetch (fetch) -... -child_start[3] git gc --auto - version 2.20.1.160.g5676107ecd.dirty - start /Users/jeffhost/work/gfw/git gc --auto - worktree /Users/jeffhost/work/gfw - cmd_name gc (fetch/gc) - exit elapsed:0.001959 code:0 - atexit elapsed:0.001997 code:0 -child_exit[3] pid:20303 code:0 elapsed:0.007564 -exit elapsed:3.868938 code:0 -atexit elapsed:3.868970 code:0 ----------------- - -Regions:: - - Regions can be use to time an interesting section of code. -+ ----------------- -void wt_status_collect(struct wt_status *s) -{ - trace2_region_enter("status", "worktrees", s->repo); - wt_status_collect_changes_worktree(s); - trace2_region_leave("status", "worktrees", s->repo); - - trace2_region_enter("status", "index", s->repo); - wt_status_collect_changes_index(s); - trace2_region_leave("status", "index", s->repo); - - trace2_region_enter("status", "untracked", s->repo); - wt_status_collect_untracked(s); - trace2_region_leave("status", "untracked", s->repo); -} - -void wt_status_print(struct wt_status *s) -{ - trace2_region_enter("status", "print", s->repo); - switch (s->status_format) { - ... - } - trace2_region_leave("status", "print", s->repo); -} ----------------- -+ -In this example, scanning for untracked files ran from +0.012568 to -+0.027149 (since the process started) and took 0.014581 seconds. -+ ----------------- -$ export GIT_TRACE2_PERF_BRIEF=1 -$ export GIT_TRACE2_PERF=~/log.perf -$ git status -... - -$ cat ~/log.perf -d0 | main | version | | | | | 2.20.1.160.g5676107ecd.dirty -d0 | main | start | | 0.001173 | | | git status -d0 | main | def_repo | r1 | | | | worktree:/Users/jeffhost/work/gfw -d0 | main | cmd_name | | | | | status (status) -... -d0 | main | region_enter | r1 | 0.010988 | | status | label:worktrees -d0 | main | region_leave | r1 | 0.011236 | 0.000248 | status | label:worktrees -d0 | main | region_enter | r1 | 0.011260 | | status | label:index -d0 | main | region_leave | r1 | 0.012542 | 0.001282 | status | label:index -d0 | main | region_enter | r1 | 0.012568 | | status | label:untracked -d0 | main | region_leave | r1 | 0.027149 | 0.014581 | status | label:untracked -d0 | main | region_enter | r1 | 0.027411 | | status | label:print -d0 | main | region_leave | r1 | 0.028741 | 0.001330 | status | label:print -d0 | main | exit | | 0.028778 | | | code:0 -d0 | main | atexit | | 0.028809 | | | code:0 ----------------- -+ -Regions may be nested. This causes messages to be indented in the -PERF target, for example. -Elapsed times are relative to the start of the correpsonding nesting -level as expected. For example, if we add region message to: -+ ----------------- -static enum path_treatment read_directory_recursive(struct dir_struct *dir, - struct index_state *istate, const char *base, int baselen, - struct untracked_cache_dir *untracked, int check_only, - int stop_at_first_file, const struct pathspec *pathspec) -{ - enum path_treatment state, subdir_state, dir_state = path_none; - - trace2_region_enter_printf("dir", "read_recursive", NULL, "%.*s", baselen, base); - ... - trace2_region_leave_printf("dir", "read_recursive", NULL, "%.*s", baselen, base); - return dir_state; -} ----------------- -+ -We can further investigate the time spent scanning for untracked files. -+ ----------------- -$ export GIT_TRACE2_PERF_BRIEF=1 -$ export GIT_TRACE2_PERF=~/log.perf -$ git status -... -$ cat ~/log.perf -d0 | main | version | | | | | 2.20.1.162.gb4ccea44db.dirty -d0 | main | start | | 0.001173 | | | git status -d0 | main | def_repo | r1 | | | | worktree:/Users/jeffhost/work/gfw -d0 | main | cmd_name | | | | | status (status) -... -d0 | main | region_enter | r1 | 0.015047 | | status | label:untracked -d0 | main | region_enter | | 0.015132 | | dir | ..label:read_recursive -d0 | main | region_enter | | 0.016341 | | dir | ....label:read_recursive vcs-svn/ -d0 | main | region_leave | | 0.016422 | 0.000081 | dir | ....label:read_recursive vcs-svn/ -d0 | main | region_enter | | 0.016446 | | dir | ....label:read_recursive xdiff/ -d0 | main | region_leave | | 0.016522 | 0.000076 | dir | ....label:read_recursive xdiff/ -d0 | main | region_enter | | 0.016612 | | dir | ....label:read_recursive git-gui/ -d0 | main | region_enter | | 0.016698 | | dir | ......label:read_recursive git-gui/po/ -d0 | main | region_enter | | 0.016810 | | dir | ........label:read_recursive git-gui/po/glossary/ -d0 | main | region_leave | | 0.016863 | 0.000053 | dir | ........label:read_recursive git-gui/po/glossary/ -... -d0 | main | region_enter | | 0.031876 | | dir | ....label:read_recursive builtin/ -d0 | main | region_leave | | 0.032270 | 0.000394 | dir | ....label:read_recursive builtin/ -d0 | main | region_leave | | 0.032414 | 0.017282 | dir | ..label:read_recursive -d0 | main | region_leave | r1 | 0.032454 | 0.017407 | status | label:untracked -... -d0 | main | exit | | 0.034279 | | | code:0 -d0 | main | atexit | | 0.034322 | | | code:0 ----------------- -+ -Trace2 regions are similar to the existing trace_performance_enter() -and trace_performance_leave() routines, but are thread safe and -maintain per-thread stacks of timers. - -Data Messages:: - - Data messages added to a region. -+ ----------------- -int read_index_from(struct index_state *istate, const char *path, - const char *gitdir) -{ - trace2_region_enter_printf("index", "do_read_index", the_repository, "%s", path); - - ... - - trace2_data_intmax("index", the_repository, "read/version", istate->version); - trace2_data_intmax("index", the_repository, "read/cache_nr", istate->cache_nr); - - trace2_region_leave_printf("index", "do_read_index", the_repository, "%s", path); -} ----------------- -+ -This example shows that the index contained 3552 entries. -+ ----------------- -$ export GIT_TRACE2_PERF_BRIEF=1 -$ export GIT_TRACE2_PERF=~/log.perf -$ git status -... -$ cat ~/log.perf -d0 | main | version | | | | | 2.20.1.156.gf9916ae094.dirty -d0 | main | start | | 0.001173 | | | git status -d0 | main | def_repo | r1 | | | | worktree:/Users/jeffhost/work/gfw -d0 | main | cmd_name | | | | | status (status) -d0 | main | region_enter | r1 | 0.001791 | | index | label:do_read_index .git/index -d0 | main | data | r1 | 0.002494 | 0.000703 | index | ..read/version:2 -d0 | main | data | r1 | 0.002520 | 0.000729 | index | ..read/cache_nr:3552 -d0 | main | region_leave | r1 | 0.002539 | 0.000748 | index | label:do_read_index .git/index -... ----------------- - -Thread Events:: - - Thread messages added to a thread-proc. -+ -For example, the multithreaded preload-index code can be -instrumented with a region around the thread pool and then -per-thread start and exit events within the threadproc. -+ ----------------- -static void *preload_thread(void *_data) -{ - // start the per-thread clock and emit a message. - trace2_thread_start("preload_thread"); - - // report which chunk of the array this thread was assigned. - trace2_data_intmax("index", the_repository, "offset", p->offset); - trace2_data_intmax("index", the_repository, "count", nr); - - do { - ... - } while (--nr > 0); - ... - - // report elapsed time taken by this thread. - trace2_thread_exit(); - return NULL; -} - -void preload_index(struct index_state *index, - const struct pathspec *pathspec, - unsigned int refresh_flags) -{ - trace2_region_enter("index", "preload", the_repository); - - for (i = 0; i < threads; i++) { - ... /* create thread */ - } - - for (i = 0; i < threads; i++) { - ... /* join thread */ - } - - trace2_region_leave("index", "preload", the_repository); -} ----------------- -+ -In this example preload_index() was executed by the `main` thread -and started the `preload` region. Seven threads, named -`th01:preload_thread` through `th07:preload_thread`, were started. -Events from each thread are atomically appended to the shared target -stream as they occur so they may appear in random order with respect -other threads. Finally, the main thread waits for the threads to -finish and leaves the region. -+ -Data events are tagged with the active thread name. They are used -to report the per-thread parameters. -+ ----------------- -$ export GIT_TRACE2_PERF_BRIEF=1 -$ export GIT_TRACE2_PERF=~/log.perf -$ git status -... -$ cat ~/log.perf -... -d0 | main | region_enter | r1 | 0.002595 | | index | label:preload -d0 | th01:preload_thread | thread_start | | 0.002699 | | | -d0 | th02:preload_thread | thread_start | | 0.002721 | | | -d0 | th01:preload_thread | data | r1 | 0.002736 | 0.000037 | index | offset:0 -d0 | th02:preload_thread | data | r1 | 0.002751 | 0.000030 | index | offset:2032 -d0 | th03:preload_thread | thread_start | | 0.002711 | | | -d0 | th06:preload_thread | thread_start | | 0.002739 | | | -d0 | th01:preload_thread | data | r1 | 0.002766 | 0.000067 | index | count:508 -d0 | th06:preload_thread | data | r1 | 0.002856 | 0.000117 | index | offset:2540 -d0 | th03:preload_thread | data | r1 | 0.002824 | 0.000113 | index | offset:1016 -d0 | th04:preload_thread | thread_start | | 0.002710 | | | -d0 | th02:preload_thread | data | r1 | 0.002779 | 0.000058 | index | count:508 -d0 | th06:preload_thread | data | r1 | 0.002966 | 0.000227 | index | count:508 -d0 | th07:preload_thread | thread_start | | 0.002741 | | | -d0 | th07:preload_thread | data | r1 | 0.003017 | 0.000276 | index | offset:3048 -d0 | th05:preload_thread | thread_start | | 0.002712 | | | -d0 | th05:preload_thread | data | r1 | 0.003067 | 0.000355 | index | offset:1524 -d0 | th05:preload_thread | data | r1 | 0.003090 | 0.000378 | index | count:508 -d0 | th07:preload_thread | data | r1 | 0.003037 | 0.000296 | index | count:504 -d0 | th03:preload_thread | data | r1 | 0.002971 | 0.000260 | index | count:508 -d0 | th04:preload_thread | data | r1 | 0.002983 | 0.000273 | index | offset:508 -d0 | th04:preload_thread | data | r1 | 0.007311 | 0.004601 | index | count:508 -d0 | th05:preload_thread | thread_exit | | 0.008781 | 0.006069 | | -d0 | th01:preload_thread | thread_exit | | 0.009561 | 0.006862 | | -d0 | th03:preload_thread | thread_exit | | 0.009742 | 0.007031 | | -d0 | th06:preload_thread | thread_exit | | 0.009820 | 0.007081 | | -d0 | th02:preload_thread | thread_exit | | 0.010274 | 0.007553 | | -d0 | th07:preload_thread | thread_exit | | 0.010477 | 0.007736 | | -d0 | th04:preload_thread | thread_exit | | 0.011657 | 0.008947 | | -d0 | main | region_leave | r1 | 0.011717 | 0.009122 | index | label:preload -... -d0 | main | exit | | 0.029996 | | | code:0 -d0 | main | atexit | | 0.030027 | | | code:0 ----------------- -+ -In this example, the preload region took 0.009122 seconds. The 7 threads -took between 0.006069 and 0.008947 seconds to work on their portion of -the index. Thread "th01" worked on 508 items at offset 0. Thread "th02" -worked on 508 items at offset 2032. Thread "th04" worked on 508 itemts -at offset 508. -+ -This example also shows that thread names are assigned in a racy manner -as each thread starts and allocates TLS storage. - -== Future Work - -=== Relationship to the Existing Trace Api (api-trace.txt) - -There are a few issues to resolve before we can completely -switch to Trace2. - -* Updating existing tests that assume GIT_TRACE format messages. - -* How to best handle custom GIT_TRACE_<key> messages? - -** The GIT_TRACE_<key> mechanism allows each <key> to write to a -different file (in addition to just stderr). - -** Do we want to maintain that ability or simply write to the existing -Trace2 targets (and convert <key> to a "category"). diff --git a/third_party/git/Documentation/technical/api-tree-walking.txt b/third_party/git/Documentation/technical/api-tree-walking.txt deleted file mode 100644 index bde18622a8..0000000000 --- a/third_party/git/Documentation/technical/api-tree-walking.txt +++ /dev/null @@ -1,147 +0,0 @@ -tree walking API -================ - -The tree walking API is used to traverse and inspect trees. - -Data Structures ---------------- - -`struct name_entry`:: - - An entry in a tree. Each entry has a sha1 identifier, pathname, and - mode. - -`struct tree_desc`:: - - A semi-opaque data structure used to maintain the current state of the - walk. -+ -* `buffer` is a pointer into the memory representation of the tree. It always -points at the current entry being visited. - -* `size` counts the number of bytes left in the `buffer`. - -* `entry` points to the current entry being visited. - -`struct traverse_info`:: - - A structure used to maintain the state of a traversal. -+ -* `prev` points to the traverse_info which was used to descend into the -current tree. If this is the top-level tree `prev` will point to -a dummy traverse_info. - -* `name` is the entry for the current tree (if the tree is a subtree). - -* `pathlen` is the length of the full path for the current tree. - -* `conflicts` can be used by callbacks to maintain directory-file conflicts. - -* `fn` is a callback called for each entry in the tree. See Traversing for more -information. - -* `data` can be anything the `fn` callback would want to use. - -* `show_all_errors` tells whether to stop at the first error or not. - -Initializing ------------- - -`init_tree_desc`:: - - Initialize a `tree_desc` and decode its first entry. The buffer and - size parameters are assumed to be the same as the buffer and size - members of `struct tree`. - -`fill_tree_descriptor`:: - - Initialize a `tree_desc` and decode its first entry given the - object ID of a tree. Returns the `buffer` member if the latter - is a valid tree identifier and NULL otherwise. - -`setup_traverse_info`:: - - Initialize a `traverse_info` given the pathname of the tree to start - traversing from. The `base` argument is assumed to be the `path` - member of the `name_entry` being recursed into unless the tree is a - top-level tree in which case the empty string ("") is used. - -Walking -------- - -`tree_entry`:: - - Visit the next entry in a tree. Returns 1 when there are more entries - left to visit and 0 when all entries have been visited. This is - commonly used in the test of a while loop. - -`tree_entry_len`:: - - Calculate the length of a tree entry's pathname. This utilizes the - memory structure of a tree entry to avoid the overhead of using a - generic strlen(). - -`update_tree_entry`:: - - Walk to the next entry in a tree. This is commonly used in conjunction - with `tree_entry_extract` to inspect the current entry. - -`tree_entry_extract`:: - - Decode the entry currently being visited (the one pointed to by - `tree_desc's` `entry` member) and return the sha1 of the entry. The - `pathp` and `modep` arguments are set to the entry's pathname and mode - respectively. - -`get_tree_entry`:: - - Find an entry in a tree given a pathname and the sha1 of a tree to - search. Returns 0 if the entry is found and -1 otherwise. The third - and fourth parameters are set to the entry's sha1 and mode - respectively. - -Traversing ----------- - -`traverse_trees`:: - - Traverse `n` number of trees in parallel. The `fn` callback member of - `traverse_info` is called once for each tree entry. - -`traverse_callback_t`:: - The arguments passed to the traverse callback are as follows: -+ -* `n` counts the number of trees being traversed. - -* `mask` has its nth bit set if something exists in the nth entry. - -* `dirmask` has its nth bit set if the nth tree's entry is a directory. - -* `entry` is an array of size `n` where the nth entry is from the nth tree. - -* `info` maintains the state of the traversal. - -+ -Returning a negative value will terminate the traversal. Otherwise the -return value is treated as an update mask. If the nth bit is set the nth tree -will be updated and if the bit is not set the nth tree entry will be the -same in the next callback invocation. - -`make_traverse_path`:: - - Generate the full pathname of a tree entry based from the root of the - traversal. For example, if the traversal has recursed into another - tree named "bar" the pathname of an entry "baz" in the "bar" - tree would be "bar/baz". - -`traverse_path_len`:: - - Calculate the length of a pathname returned by `make_traverse_path`. - This utilizes the memory structure of a tree entry to avoid the - overhead of using a generic strlen(). - -Authors -------- - -Written by Junio C Hamano <gitster@pobox.com> and Linus Torvalds -<torvalds@linux-foundation.org> diff --git a/third_party/git/Documentation/technical/api-xdiff-interface.txt b/third_party/git/Documentation/technical/api-xdiff-interface.txt deleted file mode 100644 index 6296ecad1d..0000000000 --- a/third_party/git/Documentation/technical/api-xdiff-interface.txt +++ /dev/null @@ -1,7 +0,0 @@ -xdiff interface API -=================== - -Talk about our calling convention to xdiff library, including -xdiff_emit_consume_fn. - -(Dscho, JC) diff --git a/third_party/git/Documentation/technical/bitmap-format.txt b/third_party/git/Documentation/technical/bitmap-format.txt deleted file mode 100644 index f8c18a0f7a..0000000000 --- a/third_party/git/Documentation/technical/bitmap-format.txt +++ /dev/null @@ -1,164 +0,0 @@ -GIT bitmap v1 format -==================== - - - A header appears at the beginning: - - 4-byte signature: {'B', 'I', 'T', 'M'} - - 2-byte version number (network byte order) - The current implementation only supports version 1 - of the bitmap index (the same one as JGit). - - 2-byte flags (network byte order) - - The following flags are supported: - - - BITMAP_OPT_FULL_DAG (0x1) REQUIRED - This flag must always be present. It implies that the bitmap - index has been generated for a packfile with full closure - (i.e. where every single object in the packfile can find - its parent links inside the same packfile). This is a - requirement for the bitmap index format, also present in JGit, - that greatly reduces the complexity of the implementation. - - - BITMAP_OPT_HASH_CACHE (0x4) - If present, the end of the bitmap file contains - `N` 32-bit name-hash values, one per object in the - pack. The format and meaning of the name-hash is - described below. - - 4-byte entry count (network byte order) - - The total count of entries (bitmapped commits) in this bitmap index. - - 20-byte checksum - - The SHA1 checksum of the pack this bitmap index belongs to. - - - 4 EWAH bitmaps that act as type indexes - - Type indexes are serialized after the hash cache in the shape - of four EWAH bitmaps stored consecutively (see Appendix A for - the serialization format of an EWAH bitmap). - - There is a bitmap for each Git object type, stored in the following - order: - - - Commits - - Trees - - Blobs - - Tags - - In each bitmap, the `n`th bit is set to true if the `n`th object - in the packfile is of that type. - - The obvious consequence is that the OR of all 4 bitmaps will result - in a full set (all bits set), and the AND of all 4 bitmaps will - result in an empty bitmap (no bits set). - - - N entries with compressed bitmaps, one for each indexed commit - - Where `N` is the total amount of entries in this bitmap index. - Each entry contains the following: - - - 4-byte object position (network byte order) - The position **in the index for the packfile** where the - bitmap for this commit is found. - - - 1-byte XOR-offset - The xor offset used to compress this bitmap. For an entry - in position `x`, a XOR offset of `y` means that the actual - bitmap representing this commit is composed by XORing the - bitmap for this entry with the bitmap in entry `x-y` (i.e. - the bitmap `y` entries before this one). - - Note that this compression can be recursive. In order to - XOR this entry with a previous one, the previous entry needs - to be decompressed first, and so on. - - The hard-limit for this offset is 160 (an entry can only be - xor'ed against one of the 160 entries preceding it). This - number is always positive, and hence entries are always xor'ed - with **previous** bitmaps, not bitmaps that will come afterwards - in the index. - - - 1-byte flags for this bitmap - At the moment the only available flag is `0x1`, which hints - that this bitmap can be re-used when rebuilding bitmap indexes - for the repository. - - - The compressed bitmap itself, see Appendix A. - -== Appendix A: Serialization format for an EWAH bitmap - -Ewah bitmaps are serialized in the same protocol as the JAVAEWAH -library, making them backwards compatible with the JGit -implementation: - - - 4-byte number of bits of the resulting UNCOMPRESSED bitmap - - - 4-byte number of words of the COMPRESSED bitmap, when stored - - - N x 8-byte words, as specified by the previous field - - This is the actual content of the compressed bitmap. - - - 4-byte position of the current RLW for the compressed - bitmap - -All words are stored in network byte order for their corresponding -sizes. - -The compressed bitmap is stored in a form of run-length encoding, as -follows. It consists of a concatenation of an arbitrary number of -chunks. Each chunk consists of one or more 64-bit words - - H L_1 L_2 L_3 .... L_M - -H is called RLW (run length word). It consists of (from lower to higher -order bits): - - - 1 bit: the repeated bit B - - - 32 bits: repetition count K (unsigned) - - - 31 bits: literal word count M (unsigned) - -The bitstream represented by the above chunk is then: - - - K repetitions of B - - - The bits stored in `L_1` through `L_M`. Within a word, bits at - lower order come earlier in the stream than those at higher - order. - -The next word after `L_M` (if any) must again be a RLW, for the next -chunk. For efficient appending to the bitstream, the EWAH stores a -pointer to the last RLW in the stream. - - -== Appendix B: Optional Bitmap Sections - -These sections may or may not be present in the `.bitmap` file; their -presence is indicated by the header flags section described above. - -Name-hash cache ---------------- - -If the BITMAP_OPT_HASH_CACHE flag is set, the end of the bitmap contains -a cache of 32-bit values, one per object in the pack. The value at -position `i` is the hash of the pathname at which the `i`th object -(counting in index order) in the pack can be found. This can be fed -into the delta heuristics to compare objects with similar pathnames. - -The hash algorithm used is: - - hash = 0; - while ((c = *name++)) - if (!isspace(c)) - hash = (hash >> 2) + (c << 24); - -Note that this hashing scheme is tied to the BITMAP_OPT_HASH_CACHE flag. -If implementations want to choose a different hashing scheme, they are -free to do so, but MUST allocate a new header flag (because comparing -hashes made under two different schemes would be pointless). diff --git a/third_party/git/Documentation/technical/commit-graph-format.txt b/third_party/git/Documentation/technical/commit-graph-format.txt deleted file mode 100644 index a4f17441ae..0000000000 --- a/third_party/git/Documentation/technical/commit-graph-format.txt +++ /dev/null @@ -1,104 +0,0 @@ -Git commit graph format -======================= - -The Git commit graph stores a list of commit OIDs and some associated -metadata, including: - -- The generation number of the commit. Commits with no parents have - generation number 1; commits with parents have generation number - one more than the maximum generation number of its parents. We - reserve zero as special, and can be used to mark a generation - number invalid or as "not computed". - -- The root tree OID. - -- The commit date. - -- The parents of the commit, stored using positional references within - the graph file. - -These positional references are stored as unsigned 32-bit integers -corresponding to the array position within the list of commit OIDs. Due -to some special constants we use to track parents, we can store at most -(1 << 30) + (1 << 29) + (1 << 28) - 1 (around 1.8 billion) commits. - -== Commit graph files have the following format: - -In order to allow extensions that add extra data to the graph, we organize -the body into "chunks" and provide a binary lookup table at the beginning -of the body. The header includes certain values, such as number of chunks -and hash type. - -All 4-byte numbers are in network order. - -HEADER: - - 4-byte signature: - The signature is: {'C', 'G', 'P', 'H'} - - 1-byte version number: - Currently, the only valid version is 1. - - 1-byte Hash Version (1 = SHA-1) - We infer the hash length (H) from this value. - - 1-byte number (C) of "chunks" - - 1-byte number (B) of base commit-graphs - We infer the length (H*B) of the Base Graphs chunk - from this value. - -CHUNK LOOKUP: - - (C + 1) * 12 bytes listing the table of contents for the chunks: - First 4 bytes describe the chunk id. Value 0 is a terminating label. - Other 8 bytes provide the byte-offset in current file for chunk to - start. (Chunks are ordered contiguously in the file, so you can infer - the length using the next chunk position if necessary.) Each chunk - ID appears at most once. - - The remaining data in the body is described one chunk at a time, and - these chunks may be given in any order. Chunks are required unless - otherwise specified. - -CHUNK DATA: - - OID Fanout (ID: {'O', 'I', 'D', 'F'}) (256 * 4 bytes) - The ith entry, F[i], stores the number of OIDs with first - byte at most i. Thus F[255] stores the total - number of commits (N). - - OID Lookup (ID: {'O', 'I', 'D', 'L'}) (N * H bytes) - The OIDs for all commits in the graph, sorted in ascending order. - - Commit Data (ID: {'C', 'D', 'A', 'T' }) (N * (H + 16) bytes) - * The first H bytes are for the OID of the root tree. - * The next 8 bytes are for the positions of the first two parents - of the ith commit. Stores value 0x7000000 if no parent in that - position. If there are more than two parents, the second value - has its most-significant bit on and the other bits store an array - position into the Extra Edge List chunk. - * The next 8 bytes store the generation number of the commit and - the commit time in seconds since EPOCH. The generation number - uses the higher 30 bits of the first 4 bytes, while the commit - time uses the 32 bits of the second 4 bytes, along with the lowest - 2 bits of the lowest byte, storing the 33rd and 34th bit of the - commit time. - - Extra Edge List (ID: {'E', 'D', 'G', 'E'}) [Optional] - This list of 4-byte values store the second through nth parents for - all octopus merges. The second parent value in the commit data stores - an array position within this list along with the most-significant bit - on. Starting at that array position, iterate through this list of commit - positions for the parents until reaching a value with the most-significant - bit on. The other bits correspond to the position of the last parent. - - Base Graphs List (ID: {'B', 'A', 'S', 'E'}) [Optional] - This list of H-byte hashes describe a set of B commit-graph files that - form a commit-graph chain. The graph position for the ith commit in this - file's OID Lookup chunk is equal to i plus the number of commits in all - base graphs. If B is non-zero, this chunk must exist. - -TRAILER: - - H-byte HASH-checksum of all of the above. diff --git a/third_party/git/Documentation/technical/commit-graph.txt b/third_party/git/Documentation/technical/commit-graph.txt deleted file mode 100644 index 729fbcb32f..0000000000 --- a/third_party/git/Documentation/technical/commit-graph.txt +++ /dev/null @@ -1,350 +0,0 @@ -Git Commit Graph Design Notes -============================= - -Git walks the commit graph for many reasons, including: - -1. Listing and filtering commit history. -2. Computing merge bases. - -These operations can become slow as the commit count grows. The merge -base calculation shows up in many user-facing commands, such as 'merge-base' -or 'status' and can take minutes to compute depending on history shape. - -There are two main costs here: - -1. Decompressing and parsing commits. -2. Walking the entire graph to satisfy topological order constraints. - -The commit-graph file is a supplemental data structure that accelerates -commit graph walks. If a user downgrades or disables the 'core.commitGraph' -config setting, then the existing ODB is sufficient. The file is stored -as "commit-graph" either in the .git/objects/info directory or in the info -directory of an alternate. - -The commit-graph file stores the commit graph structure along with some -extra metadata to speed up graph walks. By listing commit OIDs in lexi- -cographic order, we can identify an integer position for each commit and -refer to the parents of a commit using those integer positions. We use -binary search to find initial commits and then use the integer positions -for fast lookups during the walk. - -A consumer may load the following info for a commit from the graph: - -1. The commit OID. -2. The list of parents, along with their integer position. -3. The commit date. -4. The root tree OID. -5. The generation number (see definition below). - -Values 1-4 satisfy the requirements of parse_commit_gently(). - -Define the "generation number" of a commit recursively as follows: - - * A commit with no parents (a root commit) has generation number one. - - * A commit with at least one parent has generation number one more than - the largest generation number among its parents. - -Equivalently, the generation number of a commit A is one more than the -length of a longest path from A to a root commit. The recursive definition -is easier to use for computation and observing the following property: - - If A and B are commits with generation numbers N and M, respectively, - and N <= M, then A cannot reach B. That is, we know without searching - that B is not an ancestor of A because it is further from a root commit - than A. - - Conversely, when checking if A is an ancestor of B, then we only need - to walk commits until all commits on the walk boundary have generation - number at most N. If we walk commits using a priority queue seeded by - generation numbers, then we always expand the boundary commit with highest - generation number and can easily detect the stopping condition. - -This property can be used to significantly reduce the time it takes to -walk commits and determine topological relationships. Without generation -numbers, the general heuristic is the following: - - If A and B are commits with commit time X and Y, respectively, and - X < Y, then A _probably_ cannot reach B. - -This heuristic is currently used whenever the computation is allowed to -violate topological relationships due to clock skew (such as "git log" -with default order), but is not used when the topological order is -required (such as merge base calculations, "git log --graph"). - -In practice, we expect some commits to be created recently and not stored -in the commit graph. We can treat these commits as having "infinite" -generation number and walk until reaching commits with known generation -number. - -We use the macro GENERATION_NUMBER_INFINITY = 0xFFFFFFFF to mark commits not -in the commit-graph file. If a commit-graph file was written by a version -of Git that did not compute generation numbers, then those commits will -have generation number represented by the macro GENERATION_NUMBER_ZERO = 0. - -Since the commit-graph file is closed under reachability, we can guarantee -the following weaker condition on all commits: - - If A and B are commits with generation numbers N amd M, respectively, - and N < M, then A cannot reach B. - -Note how the strict inequality differs from the inequality when we have -fully-computed generation numbers. Using strict inequality may result in -walking a few extra commits, but the simplicity in dealing with commits -with generation number *_INFINITY or *_ZERO is valuable. - -We use the macro GENERATION_NUMBER_MAX = 0x3FFFFFFF to for commits whose -generation numbers are computed to be at least this value. We limit at -this value since it is the largest value that can be stored in the -commit-graph file using the 30 bits available to generation numbers. This -presents another case where a commit can have generation number equal to -that of a parent. - -Design Details --------------- - -- The commit-graph file is stored in a file named 'commit-graph' in the - .git/objects/info directory. This could be stored in the info directory - of an alternate. - -- The core.commitGraph config setting must be on to consume graph files. - -- The file format includes parameters for the object ID hash function, - so a future change of hash algorithm does not require a change in format. - -- Commit grafts and replace objects can change the shape of the commit - history. The latter can also be enabled/disabled on the fly using - `--no-replace-objects`. This leads to difficultly storing both possible - interpretations of a commit id, especially when computing generation - numbers. The commit-graph will not be read or written when - replace-objects or grafts are present. - -- Shallow clones create grafts of commits by dropping their parents. This - leads the commit-graph to think those commits have generation number 1. - If and when those commits are made unshallow, those generation numbers - become invalid. Since shallow clones are intended to restrict the commit - history to a very small set of commits, the commit-graph feature is less - helpful for these clones, anyway. The commit-graph will not be read or - written when shallow commits are present. - -Commit Graphs Chains --------------------- - -Typically, repos grow with near-constant velocity (commits per day). Over time, -the number of commits added by a fetch operation is much smaller than the -number of commits in the full history. By creating a "chain" of commit-graphs, -we enable fast writes of new commit data without rewriting the entire commit -history -- at least, most of the time. - -## File Layout - -A commit-graph chain uses multiple files, and we use a fixed naming convention -to organize these files. Each commit-graph file has a name -`$OBJDIR/info/commit-graphs/graph-{hash}.graph` where `{hash}` is the hex- -valued hash stored in the footer of that file (which is a hash of the file's -contents before that hash). For a chain of commit-graph files, a plain-text -file at `$OBJDIR/info/commit-graphs/commit-graph-chain` contains the -hashes for the files in order from "lowest" to "highest". - -For example, if the `commit-graph-chain` file contains the lines - -``` - {hash0} - {hash1} - {hash2} -``` - -then the commit-graph chain looks like the following diagram: - - +-----------------------+ - | graph-{hash2}.graph | - +-----------------------+ - | - +-----------------------+ - | | - | graph-{hash1}.graph | - | | - +-----------------------+ - | - +-----------------------+ - | | - | | - | | - | graph-{hash0}.graph | - | | - | | - | | - +-----------------------+ - -Let X0 be the number of commits in `graph-{hash0}.graph`, X1 be the number of -commits in `graph-{hash1}.graph`, and X2 be the number of commits in -`graph-{hash2}.graph`. If a commit appears in position i in `graph-{hash2}.graph`, -then we interpret this as being the commit in position (X0 + X1 + i), and that -will be used as its "graph position". The commits in `graph-{hash2}.graph` use these -positions to refer to their parents, which may be in `graph-{hash1}.graph` or -`graph-{hash0}.graph`. We can navigate to an arbitrary commit in position j by checking -its containment in the intervals [0, X0), [X0, X0 + X1), [X0 + X1, X0 + X1 + -X2). - -Each commit-graph file (except the base, `graph-{hash0}.graph`) contains data -specifying the hashes of all files in the lower layers. In the above example, -`graph-{hash1}.graph` contains `{hash0}` while `graph-{hash2}.graph` contains -`{hash0}` and `{hash1}`. - -## Merging commit-graph files - -If we only added a new commit-graph file on every write, we would run into a -linear search problem through many commit-graph files. Instead, we use a merge -strategy to decide when the stack should collapse some number of levels. - -The diagram below shows such a collapse. As a set of new commits are added, it -is determined by the merge strategy that the files should collapse to -`graph-{hash1}`. Thus, the new commits, the commits in `graph-{hash2}` and -the commits in `graph-{hash1}` should be combined into a new `graph-{hash3}` -file. - - +---------------------+ - | | - | (new commits) | - | | - +---------------------+ - | | - +-----------------------+ +---------------------+ - | graph-{hash2} |->| | - +-----------------------+ +---------------------+ - | | | - +-----------------------+ +---------------------+ - | | | | - | graph-{hash1} |->| | - | | | | - +-----------------------+ +---------------------+ - | tmp_graphXXX - +-----------------------+ - | | - | | - | | - | graph-{hash0} | - | | - | | - | | - +-----------------------+ - -During this process, the commits to write are combined, sorted and we write the -contents to a temporary file, all while holding a `commit-graph-chain.lock` -lock-file. When the file is flushed, we rename it to `graph-{hash3}` -according to the computed `{hash3}`. Finally, we write the new chain data to -`commit-graph-chain.lock`: - -``` - {hash3} - {hash0} -``` - -We then close the lock-file. - -## Merge Strategy - -When writing a set of commits that do not exist in the commit-graph stack of -height N, we default to creating a new file at level N + 1. We then decide to -merge with the Nth level if one of two conditions hold: - - 1. `--size-multiple=<X>` is specified or X = 2, and the number of commits in - level N is less than X times the number of commits in level N + 1. - - 2. `--max-commits=<C>` is specified with non-zero C and the number of commits - in level N + 1 is more than C commits. - -This decision cascades down the levels: when we merge a level we create a new -set of commits that then compares to the next level. - -The first condition bounds the number of levels to be logarithmic in the total -number of commits. The second condition bounds the total number of commits in -a `graph-{hashN}` file and not in the `commit-graph` file, preventing -significant performance issues when the stack merges and another process only -partially reads the previous stack. - -The merge strategy values (2 for the size multiple, 64,000 for the maximum -number of commits) could be extracted into config settings for full -flexibility. - -## Deleting graph-{hash} files - -After a new tip file is written, some `graph-{hash}` files may no longer -be part of a chain. It is important to remove these files from disk, eventually. -The main reason to delay removal is that another process could read the -`commit-graph-chain` file before it is rewritten, but then look for the -`graph-{hash}` files after they are deleted. - -To allow holding old split commit-graphs for a while after they are unreferenced, -we update the modified times of the files when they become unreferenced. Then, -we scan the `$OBJDIR/info/commit-graphs/` directory for `graph-{hash}` -files whose modified times are older than a given expiry window. This window -defaults to zero, but can be changed using command-line arguments or a config -setting. - -## Chains across multiple object directories - -In a repo with alternates, we look for the `commit-graph-chain` file starting -in the local object directory and then in each alternate. The first file that -exists defines our chain. As we look for the `graph-{hash}` files for -each `{hash}` in the chain file, we follow the same pattern for the host -directories. - -This allows commit-graphs to be split across multiple forks in a fork network. -The typical case is a large "base" repo with many smaller forks. - -As the base repo advances, it will likely update and merge its commit-graph -chain more frequently than the forks. If a fork updates their commit-graph after -the base repo, then it should "reparent" the commit-graph chain onto the new -chain in the base repo. When reading each `graph-{hash}` file, we track -the object directory containing it. During a write of a new commit-graph file, -we check for any changes in the source object directory and read the -`commit-graph-chain` file for that source and create a new file based on those -files. During this "reparent" operation, we necessarily need to collapse all -levels in the fork, as all of the files are invalid against the new base file. - -It is crucial to be careful when cleaning up "unreferenced" `graph-{hash}.graph` -files in this scenario. It falls to the user to define the proper settings for -their custom environment: - - 1. When merging levels in the base repo, the unreferenced files may still be - referenced by chains from fork repos. - - 2. The expiry time should be set to a length of time such that every fork has - time to recompute their commit-graph chain to "reparent" onto the new base - file(s). - - 3. If the commit-graph chain is updated in the base, the fork will not have - access to the new chain until its chain is updated to reference those files. - (This may change in the future [5].) - -Related Links -------------- -[0] https://bugs.chromium.org/p/git/issues/detail?id=8 - Chromium work item for: Serialized Commit Graph - -[1] https://public-inbox.org/git/20110713070517.GC18566@sigill.intra.peff.net/ - An abandoned patch that introduced generation numbers. - -[2] https://public-inbox.org/git/20170908033403.q7e6dj7benasrjes@sigill.intra.peff.net/ - Discussion about generation numbers on commits and how they interact - with fsck. - -[3] https://public-inbox.org/git/20170908034739.4op3w4f2ma5s65ku@sigill.intra.peff.net/ - More discussion about generation numbers and not storing them inside - commit objects. A valuable quote: - - "I think we should be moving more in the direction of keeping - repo-local caches for optimizations. Reachability bitmaps have been - a big performance win. I think we should be doing the same with our - properties of commits. Not just generation numbers, but making it - cheap to access the graph structure without zlib-inflating whole - commit objects (i.e., packv4 or something like the "metapacks" I - proposed a few years ago)." - -[4] https://public-inbox.org/git/20180108154822.54829-1-git@jeffhostetler.com/T/#u - A patch to remove the ahead-behind calculation from 'status'. - -[5] https://public-inbox.org/git/f27db281-abad-5043-6d71-cbb083b1c877@gmail.com/ - A discussion of a "two-dimensional graph position" that can allow reading - multiple commit-graph chains at the same time. diff --git a/third_party/git/Documentation/technical/directory-rename-detection.txt b/third_party/git/Documentation/technical/directory-rename-detection.txt deleted file mode 100644 index 844629c8c4..0000000000 --- a/third_party/git/Documentation/technical/directory-rename-detection.txt +++ /dev/null @@ -1,115 +0,0 @@ -Directory rename detection -========================== - -Rename detection logic in diffcore-rename that checks for renames of -individual files is aggregated and analyzed in merge-recursive for cases -where combinations of renames indicate that a full directory has been -renamed. - -Scope of abilities ------------------- - -It is perhaps easiest to start with an example: - - * When all of x/a, x/b and x/c have moved to z/a, z/b and z/c, it is - likely that x/d added in the meantime would also want to move to z/d by - taking the hint that the entire directory 'x' moved to 'z'. - -More interesting possibilities exist, though, such as: - - * one side of history renames x -> z, and the other renames some file to - x/e, causing the need for the merge to do a transitive rename. - - * one side of history renames x -> z, but also renames all files within x. - For example, x/a -> z/alpha, x/b -> z/bravo, etc. - - * both 'x' and 'y' being merged into a single directory 'z', with a - directory rename being detected for both x->z and y->z. - - * not all files in a directory being renamed to the same location; - i.e. perhaps most the files in 'x' are now found under 'z', but a few - are found under 'w'. - - * a directory being renamed, which also contained a subdirectory that was - renamed to some entirely different location. (And perhaps the inner - directory itself contained inner directories that were renamed to yet - other locations). - - * combinations of the above; see t/t6043-merge-rename-directories.sh for - various interesting cases. - -Limitations -- applicability of directory renames -------------------------------------------------- - -In order to prevent edge and corner cases resulting in either conflicts -that cannot be represented in the index or which might be too complex for -users to try to understand and resolve, a couple basic rules limit when -directory rename detection applies: - - 1) If a given directory still exists on both sides of a merge, we do - not consider it to have been renamed. - - 2) If a subset of to-be-renamed files have a file or directory in the - way (or would be in the way of each other), "turn off" the directory - rename for those specific sub-paths and report the conflict to the - user. - - 3) If the other side of history did a directory rename to a path that - your side of history renamed away, then ignore that particular - rename from the other side of history for any implicit directory - renames (but warn the user). - -Limitations -- detailed rules and testcases -------------------------------------------- - -t/t6043-merge-rename-directories.sh contains extensive tests and commentary -which generate and explore the rules listed above. It also lists a few -additional rules: - - a) If renames split a directory into two or more others, the directory - with the most renames, "wins". - - b) Avoid directory-rename-detection for a path, if that path is the - source of a rename on either side of a merge. - - c) Only apply implicit directory renames to directories if the other side - of history is the one doing the renaming. - -Limitations -- support in different commands --------------------------------------------- - -Directory rename detection is supported by 'merge' and 'cherry-pick'. -Other git commands which users might be surprised to see limited or no -directory rename detection support in: - - * diff - - Folks have requested in the past that `git diff` detect directory - renames and somehow simplify its output. It is not clear whether this - would be desirable or how the output should be simplified, so this was - simply not implemented. Further, to implement this, directory rename - detection logic would need to move from merge-recursive to - diffcore-rename. - - * am - - git-am tries to avoid a full three way merge, instead calling - git-apply. That prevents us from detecting renames at all, which may - defeat the directory rename detection. There is a fallback, though; if - the initial git-apply fails and the user has specified the -3 option, - git-am will fall back to a three way merge. However, git-am lacks the - necessary information to do a "real" three way merge. Instead, it has - to use build_fake_ancestor() to get a merge base that is missing files - whose rename may have been important to detect for directory rename - detection to function. - - * rebase - - Since am-based rebases work by first generating a bunch of patches - (which no longer record what the original commits were and thus don't - have the necessary info from which we can find a real merge-base), and - then calling git-am, this implies that am-based rebases will not always - successfully detect directory renames either (see the 'am' section - above). merged-based rebases (rebase -m) and cherry-pick-based rebases - (rebase -i) are not affected by this shortcoming, and fully support - directory rename detection. diff --git a/third_party/git/Documentation/technical/hash-function-transition.txt b/third_party/git/Documentation/technical/hash-function-transition.txt deleted file mode 100644 index 2ae8fa470a..0000000000 --- a/third_party/git/Documentation/technical/hash-function-transition.txt +++ /dev/null @@ -1,827 +0,0 @@ -Git hash function transition -============================ - -Objective ---------- -Migrate Git from SHA-1 to a stronger hash function. - -Background ----------- -At its core, the Git version control system is a content addressable -filesystem. It uses the SHA-1 hash function to name content. For -example, files, directories, and revisions are referred to by hash -values unlike in other traditional version control systems where files -or versions are referred to via sequential numbers. The use of a hash -function to address its content delivers a few advantages: - -* Integrity checking is easy. Bit flips, for example, are easily - detected, as the hash of corrupted content does not match its name. -* Lookup of objects is fast. - -Using a cryptographically secure hash function brings additional -advantages: - -* Object names can be signed and third parties can trust the hash to - address the signed object and all objects it references. -* Communication using Git protocol and out of band communication - methods have a short reliable string that can be used to reliably - address stored content. - -Over time some flaws in SHA-1 have been discovered by security -researchers. On 23 February 2017 the SHAttered attack -(https://shattered.io) demonstrated a practical SHA-1 hash collision. - -Git v2.13.0 and later subsequently moved to a hardened SHA-1 -implementation by default, which isn't vulnerable to the SHAttered -attack. - -Thus Git has in effect already migrated to a new hash that isn't SHA-1 -and doesn't share its vulnerabilities, its new hash function just -happens to produce exactly the same output for all known inputs, -except two PDFs published by the SHAttered researchers, and the new -implementation (written by those researchers) claims to detect future -cryptanalytic collision attacks. - -Regardless, it's considered prudent to move past any variant of SHA-1 -to a new hash. There's no guarantee that future attacks on SHA-1 won't -be published in the future, and those attacks may not have viable -mitigations. - -If SHA-1 and its variants were to be truly broken, Git's hash function -could not be considered cryptographically secure any more. This would -impact the communication of hash values because we could not trust -that a given hash value represented the known good version of content -that the speaker intended. - -SHA-1 still possesses the other properties such as fast object lookup -and safe error checking, but other hash functions are equally suitable -that are believed to be cryptographically secure. - -Goals ------ -1. The transition to SHA-256 can be done one local repository at a time. - a. Requiring no action by any other party. - b. A SHA-256 repository can communicate with SHA-1 Git servers - (push/fetch). - c. Users can use SHA-1 and SHA-256 identifiers for objects - interchangeably (see "Object names on the command line", below). - d. New signed objects make use of a stronger hash function than - SHA-1 for their security guarantees. -2. Allow a complete transition away from SHA-1. - a. Local metadata for SHA-1 compatibility can be removed from a - repository if compatibility with SHA-1 is no longer needed. -3. Maintainability throughout the process. - a. The object format is kept simple and consistent. - b. Creation of a generalized repository conversion tool. - -Non-Goals ---------- -1. Add SHA-256 support to Git protocol. This is valuable and the - logical next step but it is out of scope for this initial design. -2. Transparently improving the security of existing SHA-1 signed - objects. -3. Intermixing objects using multiple hash functions in a single - repository. -4. Taking the opportunity to fix other bugs in Git's formats and - protocols. -5. Shallow clones and fetches into a SHA-256 repository. (This will - change when we add SHA-256 support to Git protocol.) -6. Skip fetching some submodules of a project into a SHA-256 - repository. (This also depends on SHA-256 support in Git - protocol.) - -Overview --------- -We introduce a new repository format extension. Repositories with this -extension enabled use SHA-256 instead of SHA-1 to name their objects. -This affects both object names and object content --- both the names -of objects and all references to other objects within an object are -switched to the new hash function. - -SHA-256 repositories cannot be read by older versions of Git. - -Alongside the packfile, a SHA-256 repository stores a bidirectional -mapping between SHA-256 and SHA-1 object names. The mapping is generated -locally and can be verified using "git fsck". Object lookups use this -mapping to allow naming objects using either their SHA-1 and SHA-256 names -interchangeably. - -"git cat-file" and "git hash-object" gain options to display an object -in its sha1 form and write an object given its sha1 form. This -requires all objects referenced by that object to be present in the -object database so that they can be named using the appropriate name -(using the bidirectional hash mapping). - -Fetches from a SHA-1 based server convert the fetched objects into -SHA-256 form and record the mapping in the bidirectional mapping table -(see below for details). Pushes to a SHA-1 based server convert the -objects being pushed into sha1 form so the server does not have to be -aware of the hash function the client is using. - -Detailed Design ---------------- -Repository format extension -~~~~~~~~~~~~~~~~~~~~~~~~~~~ -A SHA-256 repository uses repository format version `1` (see -Documentation/technical/repository-version.txt) with extensions -`objectFormat` and `compatObjectFormat`: - - [core] - repositoryFormatVersion = 1 - [extensions] - objectFormat = sha256 - compatObjectFormat = sha1 - -The combination of setting `core.repositoryFormatVersion=1` and -populating `extensions.*` ensures that all versions of Git later than -`v0.99.9l` will die instead of trying to operate on the SHA-256 -repository, instead producing an error message. - - # Between v0.99.9l and v2.7.0 - $ git status - fatal: Expected git repo version <= 0, found 1 - # After v2.7.0 - $ git status - fatal: unknown repository extensions found: - objectformat - compatobjectformat - -See the "Transition plan" section below for more details on these -repository extensions. - -Object names -~~~~~~~~~~~~ -Objects can be named by their 40 hexadecimal digit sha1-name or 64 -hexadecimal digit sha256-name, plus names derived from those (see -gitrevisions(7)). - -The sha1-name of an object is the SHA-1 of the concatenation of its -type, length, a nul byte, and the object's sha1-content. This is the -traditional <sha1> used in Git to name objects. - -The sha256-name of an object is the SHA-256 of the concatenation of its -type, length, a nul byte, and the object's sha256-content. - -Object format -~~~~~~~~~~~~~ -The content as a byte sequence of a tag, commit, or tree object named -by sha1 and sha256 differ because an object named by sha256-name refers to -other objects by their sha256-names and an object named by sha1-name -refers to other objects by their sha1-names. - -The sha256-content of an object is the same as its sha1-content, except -that objects referenced by the object are named using their sha256-names -instead of sha1-names. Because a blob object does not refer to any -other object, its sha1-content and sha256-content are the same. - -The format allows round-trip conversion between sha256-content and -sha1-content. - -Object storage -~~~~~~~~~~~~~~ -Loose objects use zlib compression and packed objects use the packed -format described in Documentation/technical/pack-format.txt, just like -today. The content that is compressed and stored uses sha256-content -instead of sha1-content. - -Pack index -~~~~~~~~~~ -Pack index (.idx) files use a new v3 format that supports multiple -hash functions. They have the following format (all integers are in -network byte order): - -- A header appears at the beginning and consists of the following: - - The 4-byte pack index signature: '\377t0c' - - 4-byte version number: 3 - - 4-byte length of the header section, including the signature and - version number - - 4-byte number of objects contained in the pack - - 4-byte number of object formats in this pack index: 2 - - For each object format: - - 4-byte format identifier (e.g., 'sha1' for SHA-1) - - 4-byte length in bytes of shortened object names. This is the - shortest possible length needed to make names in the shortened - object name table unambiguous. - - 4-byte integer, recording where tables relating to this format - are stored in this index file, as an offset from the beginning. - - 4-byte offset to the trailer from the beginning of this file. - - Zero or more additional key/value pairs (4-byte key, 4-byte - value). Only one key is supported: 'PSRC'. See the "Loose objects - and unreachable objects" section for supported values and how this - is used. All other keys are reserved. Readers must ignore - unrecognized keys. -- Zero or more NUL bytes. This can optionally be used to improve the - alignment of the full object name table below. -- Tables for the first object format: - - A sorted table of shortened object names. These are prefixes of - the names of all objects in this pack file, packed together - without offset values to reduce the cache footprint of the binary - search for a specific object name. - - - A table of full object names in pack order. This allows resolving - a reference to "the nth object in the pack file" (from a - reachability bitmap or from the next table of another object - format) to its object name. - - - A table of 4-byte values mapping object name order to pack order. - For an object in the table of sorted shortened object names, the - value at the corresponding index in this table is the index in the - previous table for that same object. - - This can be used to look up the object in reachability bitmaps or - to look up its name in another object format. - - - A table of 4-byte CRC32 values of the packed object data, in the - order that the objects appear in the pack file. This is to allow - compressed data to be copied directly from pack to pack during - repacking without undetected data corruption. - - - A table of 4-byte offset values. For an object in the table of - sorted shortened object names, the value at the corresponding - index in this table indicates where that object can be found in - the pack file. These are usually 31-bit pack file offsets, but - large offsets are encoded as an index into the next table with the - most significant bit set. - - - A table of 8-byte offset entries (empty for pack files less than - 2 GiB). Pack files are organized with heavily used objects toward - the front, so most object references should not need to refer to - this table. -- Zero or more NUL bytes. -- Tables for the second object format, with the same layout as above, - up to and not including the table of CRC32 values. -- Zero or more NUL bytes. -- The trailer consists of the following: - - A copy of the 20-byte SHA-256 checksum at the end of the - corresponding packfile. - - - 20-byte SHA-256 checksum of all of the above. - -Loose object index -~~~~~~~~~~~~~~~~~~ -A new file $GIT_OBJECT_DIR/loose-object-idx contains information about -all loose objects. Its format is - - # loose-object-idx - (sha256-name SP sha1-name LF)* - -where the object names are in hexadecimal format. The file is not -sorted. - -The loose object index is protected against concurrent writes by a -lock file $GIT_OBJECT_DIR/loose-object-idx.lock. To add a new loose -object: - -1. Write the loose object to a temporary file, like today. -2. Open loose-object-idx.lock with O_CREAT | O_EXCL to acquire the lock. -3. Rename the loose object into place. -4. Open loose-object-idx with O_APPEND and write the new object -5. Unlink loose-object-idx.lock to release the lock. - -To remove entries (e.g. in "git pack-refs" or "git-prune"): - -1. Open loose-object-idx.lock with O_CREAT | O_EXCL to acquire the - lock. -2. Write the new content to loose-object-idx.lock. -3. Unlink any loose objects being removed. -4. Rename to replace loose-object-idx, releasing the lock. - -Translation table -~~~~~~~~~~~~~~~~~ -The index files support a bidirectional mapping between sha1-names -and sha256-names. The lookup proceeds similarly to ordinary object -lookups. For example, to convert a sha1-name to a sha256-name: - - 1. Look for the object in idx files. If a match is present in the - idx's sorted list of truncated sha1-names, then: - a. Read the corresponding entry in the sha1-name order to pack - name order mapping. - b. Read the corresponding entry in the full sha1-name table to - verify we found the right object. If it is, then - c. Read the corresponding entry in the full sha256-name table. - That is the object's sha256-name. - 2. Check for a loose object. Read lines from loose-object-idx until - we find a match. - -Step (1) takes the same amount of time as an ordinary object lookup: -O(number of packs * log(objects per pack)). Step (2) takes O(number of -loose objects) time. To maintain good performance it will be necessary -to keep the number of loose objects low. See the "Loose objects and -unreachable objects" section below for more details. - -Since all operations that make new objects (e.g., "git commit") add -the new objects to the corresponding index, this mapping is possible -for all objects in the object store. - -Reading an object's sha1-content -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The sha1-content of an object can be read by converting all sha256-names -its sha256-content references to sha1-names using the translation table. - -Fetch -~~~~~ -Fetching from a SHA-1 based server requires translating between SHA-1 -and SHA-256 based representations on the fly. - -SHA-1s named in the ref advertisement that are present on the client -can be translated to SHA-256 and looked up as local objects using the -translation table. - -Negotiation proceeds as today. Any "have"s generated locally are -converted to SHA-1 before being sent to the server, and SHA-1s -mentioned by the server are converted to SHA-256 when looking them up -locally. - -After negotiation, the server sends a packfile containing the -requested objects. We convert the packfile to SHA-256 format using -the following steps: - -1. index-pack: inflate each object in the packfile and compute its - SHA-1. Objects can contain deltas in OBJ_REF_DELTA format against - objects the client has locally. These objects can be looked up - using the translation table and their sha1-content read as - described above to resolve the deltas. -2. topological sort: starting at the "want"s from the negotiation - phase, walk through objects in the pack and emit a list of them, - excluding blobs, in reverse topologically sorted order, with each - object coming later in the list than all objects it references. - (This list only contains objects reachable from the "wants". If the - pack from the server contained additional extraneous objects, then - they will be discarded.) -3. convert to sha256: open a new (sha256) packfile. Read the topologically - sorted list just generated. For each object, inflate its - sha1-content, convert to sha256-content, and write it to the sha256 - pack. Record the new sha1<->sha256 mapping entry for use in the idx. -4. sort: reorder entries in the new pack to match the order of objects - in the pack the server generated and include blobs. Write a sha256 idx - file -5. clean up: remove the SHA-1 based pack file, index, and - topologically sorted list obtained from the server in steps 1 - and 2. - -Step 3 requires every object referenced by the new object to be in the -translation table. This is why the topological sort step is necessary. - -As an optimization, step 1 could write a file describing what non-blob -objects each object it has inflated from the packfile references. This -makes the topological sort in step 2 possible without inflating the -objects in the packfile for a second time. The objects need to be -inflated again in step 3, for a total of two inflations. - -Step 4 is probably necessary for good read-time performance. "git -pack-objects" on the server optimizes the pack file for good data -locality (see Documentation/technical/pack-heuristics.txt). - -Details of this process are likely to change. It will take some -experimenting to get this to perform well. - -Push -~~~~ -Push is simpler than fetch because the objects referenced by the -pushed objects are already in the translation table. The sha1-content -of each object being pushed can be read as described in the "Reading -an object's sha1-content" section to generate the pack written by git -send-pack. - -Signed Commits -~~~~~~~~~~~~~~ -We add a new field "gpgsig-sha256" to the commit object format to allow -signing commits without relying on SHA-1. It is similar to the -existing "gpgsig" field. Its signed payload is the sha256-content of the -commit object with any "gpgsig" and "gpgsig-sha256" fields removed. - -This means commits can be signed -1. using SHA-1 only, as in existing signed commit objects -2. using both SHA-1 and SHA-256, by using both gpgsig-sha256 and gpgsig - fields. -3. using only SHA-256, by only using the gpgsig-sha256 field. - -Old versions of "git verify-commit" can verify the gpgsig signature in -cases (1) and (2) without modifications and view case (3) as an -ordinary unsigned commit. - -Signed Tags -~~~~~~~~~~~ -We add a new field "gpgsig-sha256" to the tag object format to allow -signing tags without relying on SHA-1. Its signed payload is the -sha256-content of the tag with its gpgsig-sha256 field and "-----BEGIN PGP -SIGNATURE-----" delimited in-body signature removed. - -This means tags can be signed -1. using SHA-1 only, as in existing signed tag objects -2. using both SHA-1 and SHA-256, by using gpgsig-sha256 and an in-body - signature. -3. using only SHA-256, by only using the gpgsig-sha256 field. - -Mergetag embedding -~~~~~~~~~~~~~~~~~~ -The mergetag field in the sha1-content of a commit contains the -sha1-content of a tag that was merged by that commit. - -The mergetag field in the sha256-content of the same commit contains the -sha256-content of the same tag. - -Submodules -~~~~~~~~~~ -To convert recorded submodule pointers, you need to have the converted -submodule repository in place. The translation table of the submodule -can be used to look up the new hash. - -Loose objects and unreachable objects -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Fast lookups in the loose-object-idx require that the number of loose -objects not grow too high. - -"git gc --auto" currently waits for there to be 6700 loose objects -present before consolidating them into a packfile. We will need to -measure to find a more appropriate threshold for it to use. - -"git gc --auto" currently waits for there to be 50 packs present -before combining packfiles. Packing loose objects more aggressively -may cause the number of pack files to grow too quickly. This can be -mitigated by using a strategy similar to Martin Fick's exponential -rolling garbage collection script: -https://gerrit-review.googlesource.com/c/gerrit/+/35215 - -"git gc" currently expels any unreachable objects it encounters in -pack files to loose objects in an attempt to prevent a race when -pruning them (in case another process is simultaneously writing a new -object that refers to the about-to-be-deleted object). This leads to -an explosion in the number of loose objects present and disk space -usage due to the objects in delta form being replaced with independent -loose objects. Worse, the race is still present for loose objects. - -Instead, "git gc" will need to move unreachable objects to a new -packfile marked as UNREACHABLE_GARBAGE (using the PSRC field; see -below). To avoid the race when writing new objects referring to an -about-to-be-deleted object, code paths that write new objects will -need to copy any objects from UNREACHABLE_GARBAGE packs that they -refer to new, non-UNREACHABLE_GARBAGE packs (or loose objects). -UNREACHABLE_GARBAGE are then safe to delete if their creation time (as -indicated by the file's mtime) is long enough ago. - -To avoid a proliferation of UNREACHABLE_GARBAGE packs, they can be -combined under certain circumstances. If "gc.garbageTtl" is set to -greater than one day, then packs created within a single calendar day, -UTC, can be coalesced together. The resulting packfile would have an -mtime before midnight on that day, so this makes the effective maximum -ttl the garbageTtl + 1 day. If "gc.garbageTtl" is less than one day, -then we divide the calendar day into intervals one-third of that ttl -in duration. Packs created within the same interval can be coalesced -together. The resulting packfile would have an mtime before the end of -the interval, so this makes the effective maximum ttl equal to the -garbageTtl * 4/3. - -This rule comes from Thirumala Reddy Mutchukota's JGit change -https://git.eclipse.org/r/90465. - -The UNREACHABLE_GARBAGE setting goes in the PSRC field of the pack -index. More generally, that field indicates where a pack came from: - - - 1 (PACK_SOURCE_RECEIVE) for a pack received over the network - - 2 (PACK_SOURCE_AUTO) for a pack created by a lightweight - "gc --auto" operation - - 3 (PACK_SOURCE_GC) for a pack created by a full gc - - 4 (PACK_SOURCE_UNREACHABLE_GARBAGE) for potential garbage - discovered by gc - - 5 (PACK_SOURCE_INSERT) for locally created objects that were - written directly to a pack file, e.g. from "git add ." - -This information can be useful for debugging and for "gc --auto" to -make appropriate choices about which packs to coalesce. - -Caveats -------- -Invalid objects -~~~~~~~~~~~~~~~ -The conversion from sha1-content to sha256-content retains any -brokenness in the original object (e.g., tree entry modes encoded with -leading 0, tree objects whose paths are not sorted correctly, and -commit objects without an author or committer). This is a deliberate -feature of the design to allow the conversion to round-trip. - -More profoundly broken objects (e.g., a commit with a truncated "tree" -header line) cannot be converted but were not usable by current Git -anyway. - -Shallow clone and submodules -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Because it requires all referenced objects to be available in the -locally generated translation table, this design does not support -shallow clone or unfetched submodules. Protocol improvements might -allow lifting this restriction. - -Alternates -~~~~~~~~~~ -For the same reason, a sha256 repository cannot borrow objects from a -sha1 repository using objects/info/alternates or -$GIT_ALTERNATE_OBJECT_REPOSITORIES. - -git notes -~~~~~~~~~ -The "git notes" tool annotates objects using their sha1-name as key. -This design does not describe a way to migrate notes trees to use -sha256-names. That migration is expected to happen separately (for -example using a file at the root of the notes tree to describe which -hash it uses). - -Server-side cost -~~~~~~~~~~~~~~~~ -Until Git protocol gains SHA-256 support, using SHA-256 based storage -on public-facing Git servers is strongly discouraged. Once Git -protocol gains SHA-256 support, SHA-256 based servers are likely not -to support SHA-1 compatibility, to avoid what may be a very expensive -hash reencode during clone and to encourage peers to modernize. - -The design described here allows fetches by SHA-1 clients of a -personal SHA-256 repository because it's not much more difficult than -allowing pushes from that repository. This support needs to be guarded -by a configuration option --- servers like git.kernel.org that serve a -large number of clients would not be expected to bear that cost. - -Meaning of signatures -~~~~~~~~~~~~~~~~~~~~~ -The signed payload for signed commits and tags does not explicitly -name the hash used to identify objects. If some day Git adopts a new -hash function with the same length as the current SHA-1 (40 -hexadecimal digit) or SHA-256 (64 hexadecimal digit) objects then the -intent behind the PGP signed payload in an object signature is -unclear: - - object e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7 - type commit - tag v2.12.0 - tagger Junio C Hamano <gitster@pobox.com> 1487962205 -0800 - - Git 2.12 - -Does this mean Git v2.12.0 is the commit with sha1-name -e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7 or the commit with -new-40-digit-hash-name e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7? - -Fortunately SHA-256 and SHA-1 have different lengths. If Git starts -using another hash with the same length to name objects, then it will -need to change the format of signed payloads using that hash to -address this issue. - -Object names on the command line -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -To support the transition (see Transition plan below), this design -supports four different modes of operation: - - 1. ("dark launch") Treat object names input by the user as SHA-1 and - convert any object names written to output to SHA-1, but store - objects using SHA-256. This allows users to test the code with no - visible behavior change except for performance. This allows - allows running even tests that assume the SHA-1 hash function, to - sanity-check the behavior of the new mode. - - 2. ("early transition") Allow both SHA-1 and SHA-256 object names in - input. Any object names written to output use SHA-1. This allows - users to continue to make use of SHA-1 to communicate with peers - (e.g. by email) that have not migrated yet and prepares for mode 3. - - 3. ("late transition") Allow both SHA-1 and SHA-256 object names in - input. Any object names written to output use SHA-256. In this - mode, users are using a more secure object naming method by - default. The disruption is minimal as long as most of their peers - are in mode 2 or mode 3. - - 4. ("post-transition") Treat object names input by the user as - SHA-256 and write output using SHA-256. This is safer than mode 3 - because there is less risk that input is incorrectly interpreted - using the wrong hash function. - -The mode is specified in configuration. - -The user can also explicitly specify which format to use for a -particular revision specifier and for output, overriding the mode. For -example: - -git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256} - -Choice of Hash --------------- -In early 2005, around the time that Git was written, Xiaoyun Wang, -Yiqun Lisa Yin, and Hongbo Yu announced an attack finding SHA-1 -collisions in 2^69 operations. In August they published details. -Luckily, no practical demonstrations of a collision in full SHA-1 were -published until 10 years later, in 2017. - -Git v2.13.0 and later subsequently moved to a hardened SHA-1 -implementation by default that mitigates the SHAttered attack, but -SHA-1 is still believed to be weak. - -The hash to replace this hardened SHA-1 should be stronger than SHA-1 -was: we would like it to be trustworthy and useful in practice for at -least 10 years. - -Some other relevant properties: - -1. A 256-bit hash (long enough to match common security practice; not - excessively long to hurt performance and disk usage). - -2. High quality implementations should be widely available (e.g., in - OpenSSL and Apple CommonCrypto). - -3. The hash function's properties should match Git's needs (e.g. Git - requires collision and 2nd preimage resistance and does not require - length extension resistance). - -4. As a tiebreaker, the hash should be fast to compute (fortunately - many contenders are faster than SHA-1). - -We choose SHA-256. - -Transition plan ---------------- -Some initial steps can be implemented independently of one another: -- adding a hash function API (vtable) -- teaching fsck to tolerate the gpgsig-sha256 field -- excluding gpgsig-* from the fields copied by "git commit --amend" -- annotating tests that depend on SHA-1 values with a SHA1 test - prerequisite -- using "struct object_id", GIT_MAX_RAWSZ, and GIT_MAX_HEXSZ - consistently instead of "unsigned char *" and the hardcoded - constants 20 and 40. -- introducing index v3 -- adding support for the PSRC field and safer object pruning - - -The first user-visible change is the introduction of the objectFormat -extension (without compatObjectFormat). This requires: -- implementing the loose-object-idx -- teaching fsck about this mode of operation -- using the hash function API (vtable) when computing object names -- signing objects and verifying signatures -- rejecting attempts to fetch from or push to an incompatible - repository - -Next comes introduction of compatObjectFormat: -- translating object names between object formats -- translating object content between object formats -- generating and verifying signatures in the compat format -- adding appropriate index entries when adding a new object to the - object store -- --output-format option -- ^{sha1} and ^{sha256} revision notation -- configuration to specify default input and output format (see - "Object names on the command line" above) - -The next step is supporting fetches and pushes to SHA-1 repositories: -- allow pushes to a repository using the compat format -- generate a topologically sorted list of the SHA-1 names of fetched - objects -- convert the fetched packfile to sha256 format and generate an idx - file -- re-sort to match the order of objects in the fetched packfile - -The infrastructure supporting fetch also allows converting an existing -repository. In converted repositories and new clones, end users can -gain support for the new hash function without any visible change in -behavior (see "dark launch" in the "Object names on the command line" -section). In particular this allows users to verify SHA-256 signatures -on objects in the repository, and it should ensure the transition code -is stable in production in preparation for using it more widely. - -Over time projects would encourage their users to adopt the "early -transition" and then "late transition" modes to take advantage of the -new, more futureproof SHA-256 object names. - -When objectFormat and compatObjectFormat are both set, commands -generating signatures would generate both SHA-1 and SHA-256 signatures -by default to support both new and old users. - -In projects using SHA-256 heavily, users could be encouraged to adopt -the "post-transition" mode to avoid accidentally making implicit use -of SHA-1 object names. - -Once a critical mass of users have upgraded to a version of Git that -can verify SHA-256 signatures and have converted their existing -repositories to support verifying them, we can add support for a -setting to generate only SHA-256 signatures. This is expected to be at -least a year later. - -That is also a good moment to advertise the ability to convert -repositories to use SHA-256 only, stripping out all SHA-1 related -metadata. This improves performance by eliminating translation -overhead and security by avoiding the possibility of accidentally -relying on the safety of SHA-1. - -Updating Git's protocols to allow a server to specify which hash -functions it supports is also an important part of this transition. It -is not discussed in detail in this document but this transition plan -assumes it happens. :) - -Alternatives considered ------------------------ -Upgrading everyone working on a particular project on a flag day -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Projects like the Linux kernel are large and complex enough that -flipping the switch for all projects based on the repository at once -is infeasible. - -Not only would all developers and server operators supporting -developers have to switch on the same flag day, but supporting tooling -(continuous integration, code review, bug trackers, etc) would have to -be adapted as well. This also makes it difficult to get early feedback -from some project participants testing before it is time for mass -adoption. - -Using hash functions in parallel -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -(e.g. https://public-inbox.org/git/22708.8913.864049.452252@chiark.greenend.org.uk/ ) -Objects newly created would be addressed by the new hash, but inside -such an object (e.g. commit) it is still possible to address objects -using the old hash function. -* You cannot trust its history (needed for bisectability) in the - future without further work -* Maintenance burden as the number of supported hash functions grows - (they will never go away, so they accumulate). In this proposal, by - comparison, converted objects lose all references to SHA-1. - -Signed objects with multiple hashes -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Instead of introducing the gpgsig-sha256 field in commit and tag objects -for sha256-content based signatures, an earlier version of this design -added "hash sha256 <sha256-name>" fields to strengthen the existing -sha1-content based signatures. - -In other words, a single signature was used to attest to the object -content using both hash functions. This had some advantages: -* Using one signature instead of two speeds up the signing process. -* Having one signed payload with both hashes allows the signer to - attest to the sha1-name and sha256-name referring to the same object. -* All users consume the same signature. Broken signatures are likely - to be detected quickly using current versions of git. - -However, it also came with disadvantages: -* Verifying a signed object requires access to the sha1-names of all - objects it references, even after the transition is complete and - translation table is no longer needed for anything else. To support - this, the design added fields such as "hash sha1 tree <sha1-name>" - and "hash sha1 parent <sha1-name>" to the sha256-content of a signed - commit, complicating the conversion process. -* Allowing signed objects without a sha1 (for after the transition is - complete) complicated the design further, requiring a "nohash sha1" - field to suppress including "hash sha1" fields in the sha256-content - and signed payload. - -Lazily populated translation table -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Some of the work of building the translation table could be deferred to -push time, but that would significantly complicate and slow down pushes. -Calculating the sha1-name at object creation time at the same time it is -being streamed to disk and having its sha256-name calculated should be -an acceptable cost. - -Document History ----------------- - -2017-03-03 -bmwill@google.com, jonathantanmy@google.com, jrnieder@gmail.com, -sbeller@google.com - -Initial version sent to -http://public-inbox.org/git/20170304011251.GA26789@aiede.mtv.corp.google.com - -2017-03-03 jrnieder@gmail.com -Incorporated suggestions from jonathantanmy and sbeller: -* describe purpose of signed objects with each hash type -* redefine signed object verification using object content under the - first hash function - -2017-03-06 jrnieder@gmail.com -* Use SHA3-256 instead of SHA2 (thanks, Linus and brian m. carlson).[1][2] -* Make sha3-based signatures a separate field, avoiding the need for - "hash" and "nohash" fields (thanks to peff[3]). -* Add a sorting phase to fetch (thanks to Junio for noticing the need - for this). -* Omit blobs from the topological sort during fetch (thanks to peff). -* Discuss alternates, git notes, and git servers in the caveats - section (thanks to Junio Hamano, brian m. carlson[4], and Shawn - Pearce). -* Clarify language throughout (thanks to various commenters, - especially Junio). - -2017-09-27 jrnieder@gmail.com, sbeller@google.com -* use placeholder NewHash instead of SHA3-256 -* describe criteria for picking a hash function. -* include a transition plan (thanks especially to Brandon Williams - for fleshing these ideas out) -* define the translation table (thanks, Shawn Pearce[5], Jonathan - Tan, and Masaya Suzuki) -* avoid loose object overhead by packing more aggressively in - "git gc --auto" - -Later history: - - See the history of this file in git.git for the history of subsequent - edits. This document history is no longer being maintained as it - would now be superfluous to the commit log - -[1] http://public-inbox.org/git/CA+55aFzJtejiCjV0e43+9oR3QuJK2PiFiLQemytoLpyJWe6P9w@mail.gmail.com/ -[2] http://public-inbox.org/git/CA+55aFz+gkAsDZ24zmePQuEs1XPS9BP_s8O7Q4wQ7LV7X5-oDA@mail.gmail.com/ -[3] http://public-inbox.org/git/20170306084353.nrns455dvkdsfgo5@sigill.intra.peff.net/ -[4] http://public-inbox.org/git/20170304224936.rqqtkdvfjgyezsht@genre.crustytoothpaste.net -[5] https://public-inbox.org/git/CAJo=hJtoX9=AyLHHpUJS7fueV9ciZ_MNpnEPHUz8Whui6g9F0A@mail.gmail.com/ diff --git a/third_party/git/Documentation/technical/http-protocol.txt b/third_party/git/Documentation/technical/http-protocol.txt deleted file mode 100644 index 9c5b6f0fac..0000000000 --- a/third_party/git/Documentation/technical/http-protocol.txt +++ /dev/null @@ -1,518 +0,0 @@ -HTTP transfer protocols -======================= - -Git supports two HTTP based transfer protocols. A "dumb" protocol -which requires only a standard HTTP server on the server end of the -connection, and a "smart" protocol which requires a Git aware CGI -(or server module). This document describes both protocols. - -As a design feature smart clients can automatically upgrade "dumb" -protocol URLs to smart URLs. This permits all users to have the -same published URL, and the peers automatically select the most -efficient transport available to them. - - -URL Format ----------- - -URLs for Git repositories accessed by HTTP use the standard HTTP -URL syntax documented by RFC 1738, so they are of the form: - - http://<host>:<port>/<path>?<searchpart> - -Within this documentation the placeholder `$GIT_URL` will stand for -the http:// repository URL entered by the end-user. - -Servers SHOULD handle all requests to locations matching `$GIT_URL`, as -both the "smart" and "dumb" HTTP protocols used by Git operate -by appending additional path components onto the end of the user -supplied `$GIT_URL` string. - -An example of a dumb client requesting for a loose object: - - $GIT_URL: http://example.com:8080/git/repo.git - URL request: http://example.com:8080/git/repo.git/objects/d0/49f6c27a2244e12041955e262a404c7faba355 - -An example of a smart request to a catch-all gateway: - - $GIT_URL: http://example.com/daemon.cgi?svc=git&q= - URL request: http://example.com/daemon.cgi?svc=git&q=/info/refs&service=git-receive-pack - -An example of a request to a submodule: - - $GIT_URL: http://example.com/git/repo.git/path/submodule.git - URL request: http://example.com/git/repo.git/path/submodule.git/info/refs - -Clients MUST strip a trailing `/`, if present, from the user supplied -`$GIT_URL` string to prevent empty path tokens (`//`) from appearing -in any URL sent to a server. Compatible clients MUST expand -`$GIT_URL/info/refs` as `foo/info/refs` and not `foo//info/refs`. - - -Authentication --------------- - -Standard HTTP authentication is used if authentication is required -to access a repository, and MAY be configured and enforced by the -HTTP server software. - -Because Git repositories are accessed by standard path components -server administrators MAY use directory based permissions within -their HTTP server to control repository access. - -Clients SHOULD support Basic authentication as described by RFC 2617. -Servers SHOULD support Basic authentication by relying upon the -HTTP server placed in front of the Git server software. - -Servers SHOULD NOT require HTTP cookies for the purposes of -authentication or access control. - -Clients and servers MAY support other common forms of HTTP based -authentication, such as Digest authentication. - - -SSL ---- - -Clients and servers SHOULD support SSL, particularly to protect -passwords when relying on Basic HTTP authentication. - - -Session State -------------- - -The Git over HTTP protocol (much like HTTP itself) is stateless -from the perspective of the HTTP server side. All state MUST be -retained and managed by the client process. This permits simple -round-robin load-balancing on the server side, without needing to -worry about state management. - -Clients MUST NOT require state management on the server side in -order to function correctly. - -Servers MUST NOT require HTTP cookies in order to function correctly. -Clients MAY store and forward HTTP cookies during request processing -as described by RFC 2616 (HTTP/1.1). Servers SHOULD ignore any -cookies sent by a client. - - -General Request Processing --------------------------- - -Except where noted, all standard HTTP behavior SHOULD be assumed -by both client and server. This includes (but is not necessarily -limited to): - -If there is no repository at `$GIT_URL`, or the resource pointed to by a -location matching `$GIT_URL` does not exist, the server MUST NOT respond -with `200 OK` response. A server SHOULD respond with -`404 Not Found`, `410 Gone`, or any other suitable HTTP status code -which does not imply the resource exists as requested. - -If there is a repository at `$GIT_URL`, but access is not currently -permitted, the server MUST respond with the `403 Forbidden` HTTP -status code. - -Servers SHOULD support both HTTP 1.0 and HTTP 1.1. -Servers SHOULD support chunked encoding for both request and response -bodies. - -Clients SHOULD support both HTTP 1.0 and HTTP 1.1. -Clients SHOULD support chunked encoding for both request and response -bodies. - -Servers MAY return ETag and/or Last-Modified headers. - -Clients MAY revalidate cached entities by including If-Modified-Since -and/or If-None-Match request headers. - -Servers MAY return `304 Not Modified` if the relevant headers appear -in the request and the entity has not changed. Clients MUST treat -`304 Not Modified` identical to `200 OK` by reusing the cached entity. - -Clients MAY reuse a cached entity without revalidation if the -Cache-Control and/or Expires header permits caching. Clients and -servers MUST follow RFC 2616 for cache controls. - - -Discovering References ----------------------- - -All HTTP clients MUST begin either a fetch or a push exchange by -discovering the references available on the remote repository. - -Dumb Clients -~~~~~~~~~~~~ - -HTTP clients that only support the "dumb" protocol MUST discover -references by making a request for the special info/refs file of -the repository. - -Dumb HTTP clients MUST make a `GET` request to `$GIT_URL/info/refs`, -without any search/query parameters. - - C: GET $GIT_URL/info/refs HTTP/1.0 - - S: 200 OK - S: - S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint - S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master - S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0 - S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{} - -The Content-Type of the returned info/refs entity SHOULD be -`text/plain; charset=utf-8`, but MAY be any content type. -Clients MUST NOT attempt to validate the returned Content-Type. -Dumb servers MUST NOT return a return type starting with -`application/x-git-`. - -Cache-Control headers MAY be returned to disable caching of the -returned entity. - -When examining the response clients SHOULD only examine the HTTP -status code. Valid responses are `200 OK`, or `304 Not Modified`. - -The returned content is a UNIX formatted text file describing -each ref and its known value. The file SHOULD be sorted by name -according to the C locale ordering. The file SHOULD NOT include -the default ref named `HEAD`. - - info_refs = *( ref_record ) - ref_record = any_ref / peeled_ref - - any_ref = obj-id HTAB refname LF - peeled_ref = obj-id HTAB refname LF - obj-id HTAB refname "^{}" LF - -Smart Clients -~~~~~~~~~~~~~ - -HTTP clients that support the "smart" protocol (or both the -"smart" and "dumb" protocols) MUST discover references by making -a parameterized request for the info/refs file of the repository. - -The request MUST contain exactly one query parameter, -`service=$servicename`, where `$servicename` MUST be the service -name the client wishes to contact to complete the operation. -The request MUST NOT contain additional query parameters. - - C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0 - -dumb server reply: - - S: 200 OK - S: - S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint - S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master - S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0 - S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{} - -smart server reply: - - S: 200 OK - S: Content-Type: application/x-git-upload-pack-advertisement - S: Cache-Control: no-cache - S: - S: 001e# service=git-upload-pack\n - S: 0000 - S: 004895dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\0multi_ack\n - S: 0042d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\n - S: 003c2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0\n - S: 003fa3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}\n - S: 0000 - -The client may send Extra Parameters (see -Documentation/technical/pack-protocol.txt) as a colon-separated string -in the Git-Protocol HTTP header. - -Dumb Server Response -^^^^^^^^^^^^^^^^^^^^ -Dumb servers MUST respond with the dumb server reply format. - -See the prior section under dumb clients for a more detailed -description of the dumb server response. - -Smart Server Response -^^^^^^^^^^^^^^^^^^^^^ -If the server does not recognize the requested service name, or the -requested service name has been disabled by the server administrator, -the server MUST respond with the `403 Forbidden` HTTP status code. - -Otherwise, smart servers MUST respond with the smart server reply -format for the requested service name. - -Cache-Control headers SHOULD be used to disable caching of the -returned entity. - -The Content-Type MUST be `application/x-$servicename-advertisement`. -Clients SHOULD fall back to the dumb protocol if another content -type is returned. When falling back to the dumb protocol clients -SHOULD NOT make an additional request to `$GIT_URL/info/refs`, but -instead SHOULD use the response already in hand. Clients MUST NOT -continue if they do not support the dumb protocol. - -Clients MUST validate the status code is either `200 OK` or -`304 Not Modified`. - -Clients MUST validate the first five bytes of the response entity -matches the regex `^[0-9a-f]{4}#`. If this test fails, clients -MUST NOT continue. - -Clients MUST parse the entire response as a sequence of pkt-line -records. - -Clients MUST verify the first pkt-line is `# service=$servicename`. -Servers MUST set $servicename to be the request parameter value. -Servers SHOULD include an LF at the end of this line. -Clients MUST ignore an LF at the end of the line. - -Servers MUST terminate the response with the magic `0000` end -pkt-line marker. - -The returned response is a pkt-line stream describing each ref and -its known value. The stream SHOULD be sorted by name according to -the C locale ordering. The stream SHOULD include the default ref -named `HEAD` as the first ref. The stream MUST include capability -declarations behind a NUL on the first ref. - -The returned response contains "version 1" if "version=1" was sent as an -Extra Parameter. - - smart_reply = PKT-LINE("# service=$servicename" LF) - "0000" - *1("version 1") - ref_list - "0000" - ref_list = empty_list / non_empty_list - - empty_list = PKT-LINE(zero-id SP "capabilities^{}" NUL cap-list LF) - - non_empty_list = PKT-LINE(obj-id SP name NUL cap_list LF) - *ref_record - - cap-list = capability *(SP capability) - capability = 1*(LC_ALPHA / DIGIT / "-" / "_") - LC_ALPHA = %x61-7A - - ref_record = any_ref / peeled_ref - any_ref = PKT-LINE(obj-id SP name LF) - peeled_ref = PKT-LINE(obj-id SP name LF) - PKT-LINE(obj-id SP name "^{}" LF - - -Smart Service git-upload-pack ------------------------------- -This service reads from the repository pointed to by `$GIT_URL`. - -Clients MUST first perform ref discovery with -`$GIT_URL/info/refs?service=git-upload-pack`. - - C: POST $GIT_URL/git-upload-pack HTTP/1.0 - C: Content-Type: application/x-git-upload-pack-request - C: - C: 0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7\n - C: 0032have 441b40d833fdfa93eb2908e52742248faf0ee993\n - C: 0000 - - S: 200 OK - S: Content-Type: application/x-git-upload-pack-result - S: Cache-Control: no-cache - S: - S: ....ACK %s, continue - S: ....NAK - -Clients MUST NOT reuse or revalidate a cached response. -Servers MUST include sufficient Cache-Control headers -to prevent caching of the response. - -Servers SHOULD support all capabilities defined here. - -Clients MUST send at least one "want" command in the request body. -Clients MUST NOT reference an id in a "want" command which did not -appear in the response obtained through ref discovery unless the -server advertises capability `allow-tip-sha1-in-want` or -`allow-reachable-sha1-in-want`. - - compute_request = want_list - have_list - request_end - request_end = "0000" / "done" - - want_list = PKT-LINE(want SP cap_list LF) - *(want_pkt) - want_pkt = PKT-LINE(want LF) - want = "want" SP id - cap_list = capability *(SP capability) - - have_list = *PKT-LINE("have" SP id LF) - -TODO: Document this further. - -The Negotiation Algorithm -~~~~~~~~~~~~~~~~~~~~~~~~~ -The computation to select the minimal pack proceeds as follows -(C = client, S = server): - -'init step:' - -C: Use ref discovery to obtain the advertised refs. - -C: Place any object seen into set `advertised`. - -C: Build an empty set, `common`, to hold the objects that are later - determined to be on both ends. - -C: Build a set, `want`, of the objects from `advertised` the client - wants to fetch, based on what it saw during ref discovery. - -C: Start a queue, `c_pending`, ordered by commit time (popping newest - first). Add all client refs. When a commit is popped from - the queue its parents SHOULD be automatically inserted back. - Commits MUST only enter the queue once. - -'one compute step:' - -C: Send one `$GIT_URL/git-upload-pack` request: - - C: 0032want <want #1>............................... - C: 0032want <want #2>............................... - .... - C: 0032have <common #1>............................. - C: 0032have <common #2>............................. - .... - C: 0032have <have #1>............................... - C: 0032have <have #2>............................... - .... - C: 0000 - -The stream is organized into "commands", with each command -appearing by itself in a pkt-line. Within a command line, -the text leading up to the first space is the command name, -and the remainder of the line to the first LF is the value. -Command lines are terminated with an LF as the last byte of -the pkt-line value. - -Commands MUST appear in the following order, if they appear -at all in the request stream: - -* "want" -* "have" - -The stream is terminated by a pkt-line flush (`0000`). - -A single "want" or "have" command MUST have one hex formatted -SHA-1 as its value. Multiple SHA-1s MUST be sent by sending -multiple commands. - -The `have` list is created by popping the first 32 commits -from `c_pending`. Less can be supplied if `c_pending` empties. - -If the client has sent 256 "have" commits and has not yet -received one of those back from `s_common`, or the client has -emptied `c_pending` it SHOULD include a "done" command to let -the server know it won't proceed: - - C: 0009done - -S: Parse the git-upload-pack request: - -Verify all objects in `want` are directly reachable from refs. - -The server MAY walk backwards through history or through -the reflog to permit slightly stale requests. - -If no "want" objects are received, send an error: -TODO: Define error if no "want" lines are requested. - -If any "want" object is not reachable, send an error: -TODO: Define error if an invalid "want" is requested. - -Create an empty list, `s_common`. - -If "have" was sent: - -Loop through the objects in the order supplied by the client. - -For each object, if the server has the object reachable from -a ref, add it to `s_common`. If a commit is added to `s_common`, -do not add any ancestors, even if they also appear in `have`. - -S: Send the git-upload-pack response: - -If the server has found a closed set of objects to pack or the -request ends with "done", it replies with the pack. -TODO: Document the pack based response - - S: PACK... - -The returned stream is the side-band-64k protocol supported -by the git-upload-pack service, and the pack is embedded into -stream 1. Progress messages from the server side MAY appear -in stream 2. - -Here a "closed set of objects" is defined to have at least -one path from every "want" to at least one "common" object. - -If the server needs more information, it replies with a -status continue response: -TODO: Document the non-pack response - -C: Parse the upload-pack response: - TODO: Document parsing response - -'Do another compute step.' - - -Smart Service git-receive-pack ------------------------------- -This service reads from the repository pointed to by `$GIT_URL`. - -Clients MUST first perform ref discovery with -`$GIT_URL/info/refs?service=git-receive-pack`. - - C: POST $GIT_URL/git-receive-pack HTTP/1.0 - C: Content-Type: application/x-git-receive-pack-request - C: - C: ....0a53e9ddeaddad63ad106860237bbf53411d11a7 441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint\0 report-status - C: 0000 - C: PACK.... - - S: 200 OK - S: Content-Type: application/x-git-receive-pack-result - S: Cache-Control: no-cache - S: - S: .... - -Clients MUST NOT reuse or revalidate a cached response. -Servers MUST include sufficient Cache-Control headers -to prevent caching of the response. - -Servers SHOULD support all capabilities defined here. - -Clients MUST send at least one command in the request body. -Within the command portion of the request body clients SHOULD send -the id obtained through ref discovery as old_id. - - update_request = command_list - "PACK" <binary data> - - command_list = PKT-LINE(command NUL cap_list LF) - *(command_pkt) - command_pkt = PKT-LINE(command LF) - cap_list = *(SP capability) SP - - command = create / delete / update - create = zero-id SP new_id SP name - delete = old_id SP zero-id SP name - update = old_id SP new_id SP name - -TODO: Document this further. - - -References ----------- - -http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)] -http://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1] -link:technical/pack-protocol.html -link:technical/protocol-capabilities.html diff --git a/third_party/git/Documentation/technical/index-format.txt b/third_party/git/Documentation/technical/index-format.txt deleted file mode 100644 index 7c4d67aa6a..0000000000 --- a/third_party/git/Documentation/technical/index-format.txt +++ /dev/null @@ -1,357 +0,0 @@ -Git index format -================ - -== The Git index file has the following format - - All binary numbers are in network byte order. Version 2 is described - here unless stated otherwise. - - - A 12-byte header consisting of - - 4-byte signature: - The signature is { 'D', 'I', 'R', 'C' } (stands for "dircache") - - 4-byte version number: - The current supported versions are 2, 3 and 4. - - 32-bit number of index entries. - - - A number of sorted index entries (see below). - - - Extensions - - Extensions are identified by signature. Optional extensions can - be ignored if Git does not understand them. - - Git currently supports cached tree and resolve undo extensions. - - 4-byte extension signature. If the first byte is 'A'..'Z' the - extension is optional and can be ignored. - - 32-bit size of the extension - - Extension data - - - 160-bit SHA-1 over the content of the index file before this - checksum. - -== Index entry - - Index entries are sorted in ascending order on the name field, - interpreted as a string of unsigned bytes (i.e. memcmp() order, no - localization, no special casing of directory separator '/'). Entries - with the same name are sorted by their stage field. - - 32-bit ctime seconds, the last time a file's metadata changed - this is stat(2) data - - 32-bit ctime nanosecond fractions - this is stat(2) data - - 32-bit mtime seconds, the last time a file's data changed - this is stat(2) data - - 32-bit mtime nanosecond fractions - this is stat(2) data - - 32-bit dev - this is stat(2) data - - 32-bit ino - this is stat(2) data - - 32-bit mode, split into (high to low bits) - - 4-bit object type - valid values in binary are 1000 (regular file), 1010 (symbolic link) - and 1110 (gitlink) - - 3-bit unused - - 9-bit unix permission. Only 0755 and 0644 are valid for regular files. - Symbolic links and gitlinks have value 0 in this field. - - 32-bit uid - this is stat(2) data - - 32-bit gid - this is stat(2) data - - 32-bit file size - This is the on-disk size from stat(2), truncated to 32-bit. - - 160-bit SHA-1 for the represented object - - A 16-bit 'flags' field split into (high to low bits) - - 1-bit assume-valid flag - - 1-bit extended flag (must be zero in version 2) - - 2-bit stage (during merge) - - 12-bit name length if the length is less than 0xFFF; otherwise 0xFFF - is stored in this field. - - (Version 3 or later) A 16-bit field, only applicable if the - "extended flag" above is 1, split into (high to low bits). - - 1-bit reserved for future - - 1-bit skip-worktree flag (used by sparse checkout) - - 1-bit intent-to-add flag (used by "git add -N") - - 13-bit unused, must be zero - - Entry path name (variable length) relative to top level directory - (without leading slash). '/' is used as path separator. The special - path components ".", ".." and ".git" (without quotes) are disallowed. - Trailing slash is also disallowed. - - The exact encoding is undefined, but the '.' and '/' characters - are encoded in 7-bit ASCII and the encoding cannot contain a NUL - byte (iow, this is a UNIX pathname). - - (Version 4) In version 4, the entry path name is prefix-compressed - relative to the path name for the previous entry (the very first - entry is encoded as if the path name for the previous entry is an - empty string). At the beginning of an entry, an integer N in the - variable width encoding (the same encoding as the offset is encoded - for OFS_DELTA pack entries; see pack-format.txt) is stored, followed - by a NUL-terminated string S. Removing N bytes from the end of the - path name for the previous entry, and replacing it with the string S - yields the path name for this entry. - - 1-8 nul bytes as necessary to pad the entry to a multiple of eight bytes - while keeping the name NUL-terminated. - - (Version 4) In version 4, the padding after the pathname does not - exist. - - Interpretation of index entries in split index mode is completely - different. See below for details. - -== Extensions - -=== Cached tree - - Cached tree extension contains pre-computed hashes for trees that can - be derived from the index. It helps speed up tree object generation - from index for a new commit. - - When a path is updated in index, the path must be invalidated and - removed from tree cache. - - The signature for this extension is { 'T', 'R', 'E', 'E' }. - - A series of entries fill the entire extension; each of which - consists of: - - - NUL-terminated path component (relative to its parent directory); - - - ASCII decimal number of entries in the index that is covered by the - tree this entry represents (entry_count); - - - A space (ASCII 32); - - - ASCII decimal number that represents the number of subtrees this - tree has; - - - A newline (ASCII 10); and - - - 160-bit object name for the object that would result from writing - this span of index as a tree. - - An entry can be in an invalidated state and is represented by having - a negative number in the entry_count field. In this case, there is no - object name and the next entry starts immediately after the newline. - When writing an invalid entry, -1 should always be used as entry_count. - - The entries are written out in the top-down, depth-first order. The - first entry represents the root level of the repository, followed by the - first subtree--let's call this A--of the root level (with its name - relative to the root level), followed by the first subtree of A (with - its name relative to A), ... - -=== Resolve undo - - A conflict is represented in the index as a set of higher stage entries. - When a conflict is resolved (e.g. with "git add path"), these higher - stage entries will be removed and a stage-0 entry with proper resolution - is added. - - When these higher stage entries are removed, they are saved in the - resolve undo extension, so that conflicts can be recreated (e.g. with - "git checkout -m"), in case users want to redo a conflict resolution - from scratch. - - The signature for this extension is { 'R', 'E', 'U', 'C' }. - - A series of entries fill the entire extension; each of which - consists of: - - - NUL-terminated pathname the entry describes (relative to the root of - the repository, i.e. full pathname); - - - Three NUL-terminated ASCII octal numbers, entry mode of entries in - stage 1 to 3 (a missing stage is represented by "0" in this field); - and - - - At most three 160-bit object names of the entry in stages from 1 to 3 - (nothing is written for a missing stage). - -=== Split index - - In split index mode, the majority of index entries could be stored - in a separate file. This extension records the changes to be made on - top of that to produce the final index. - - The signature for this extension is { 'l', 'i', 'n', 'k' }. - - The extension consists of: - - - 160-bit SHA-1 of the shared index file. The shared index file path - is $GIT_DIR/sharedindex.<SHA-1>. If all 160 bits are zero, the - index does not require a shared index file. - - - An ewah-encoded delete bitmap, each bit represents an entry in the - shared index. If a bit is set, its corresponding entry in the - shared index will be removed from the final index. Note, because - a delete operation changes index entry positions, but we do need - original positions in replace phase, it's best to just mark - entries for removal, then do a mass deletion after replacement. - - - An ewah-encoded replace bitmap, each bit represents an entry in - the shared index. If a bit is set, its corresponding entry in the - shared index will be replaced with an entry in this index - file. All replaced entries are stored in sorted order in this - index. The first "1" bit in the replace bitmap corresponds to the - first index entry, the second "1" bit to the second entry and so - on. Replaced entries may have empty path names to save space. - - The remaining index entries after replaced ones will be added to the - final index. These added entries are also sorted by entry name then - stage. - -== Untracked cache - - Untracked cache saves the untracked file list and necessary data to - verify the cache. The signature for this extension is { 'U', 'N', - 'T', 'R' }. - - The extension starts with - - - A sequence of NUL-terminated strings, preceded by the size of the - sequence in variable width encoding. Each string describes the - environment where the cache can be used. - - - Stat data of $GIT_DIR/info/exclude. See "Index entry" section from - ctime field until "file size". - - - Stat data of core.excludesfile - - - 32-bit dir_flags (see struct dir_struct) - - - 160-bit SHA-1 of $GIT_DIR/info/exclude. Null SHA-1 means the file - does not exist. - - - 160-bit SHA-1 of core.excludesfile. Null SHA-1 means the file does - not exist. - - - NUL-terminated string of per-dir exclude file name. This usually - is ".gitignore". - - - The number of following directory blocks, variable width - encoding. If this number is zero, the extension ends here with a - following NUL. - - - A number of directory blocks in depth-first-search order, each - consists of - - - The number of untracked entries, variable width encoding. - - - The number of sub-directory blocks, variable width encoding. - - - The directory name terminated by NUL. - - - A number of untracked file/dir names terminated by NUL. - -The remaining data of each directory block is grouped by type: - - - An ewah bitmap, the n-th bit marks whether the n-th directory has - valid untracked cache entries. - - - An ewah bitmap, the n-th bit records "check-only" bit of - read_directory_recursive() for the n-th directory. - - - An ewah bitmap, the n-th bit indicates whether SHA-1 and stat data - is valid for the n-th directory and exists in the next data. - - - An array of stat data. The n-th data corresponds with the n-th - "one" bit in the previous ewah bitmap. - - - An array of SHA-1. The n-th SHA-1 corresponds with the n-th "one" bit - in the previous ewah bitmap. - - - One NUL. - -== File System Monitor cache - - The file system monitor cache tracks files for which the core.fsmonitor - hook has told us about changes. The signature for this extension is - { 'F', 'S', 'M', 'N' }. - - The extension starts with - - - 32-bit version number: the current supported version is 1. - - - 64-bit time: the extension data reflects all changes through the given - time which is stored as the nanoseconds elapsed since midnight, - January 1, 1970. - - - 32-bit bitmap size: the size of the CE_FSMONITOR_VALID bitmap. - - - An ewah bitmap, the n-th bit indicates whether the n-th index entry - is not CE_FSMONITOR_VALID. - -== End of Index Entry - - The End of Index Entry (EOIE) is used to locate the end of the variable - length index entries and the begining of the extensions. Code can take - advantage of this to quickly locate the index extensions without having - to parse through all of the index entries. - - Because it must be able to be loaded before the variable length cache - entries and other index extensions, this extension must be written last. - The signature for this extension is { 'E', 'O', 'I', 'E' }. - - The extension consists of: - - - 32-bit offset to the end of the index entries - - - 160-bit SHA-1 over the extension types and their sizes (but not - their contents). E.g. if we have "TREE" extension that is N-bytes - long, "REUC" extension that is M-bytes long, followed by "EOIE", - then the hash would be: - - SHA-1("TREE" + <binary representation of N> + - "REUC" + <binary representation of M>) - -== Index Entry Offset Table - - The Index Entry Offset Table (IEOT) is used to help address the CPU - cost of loading the index by enabling multi-threading the process of - converting cache entries from the on-disk format to the in-memory format. - The signature for this extension is { 'I', 'E', 'O', 'T' }. - - The extension consists of: - - - 32-bit version (currently 1) - - - A number of index offset entries each consisting of: - - - 32-bit offset from the begining of the file to the first cache entry - in this block of entries. - - - 32-bit count of cache entries in this block diff --git a/third_party/git/Documentation/technical/long-running-process-protocol.txt b/third_party/git/Documentation/technical/long-running-process-protocol.txt deleted file mode 100644 index aa0aa9af1c..0000000000 --- a/third_party/git/Documentation/technical/long-running-process-protocol.txt +++ /dev/null @@ -1,50 +0,0 @@ -Long-running process protocol -============================= - -This protocol is used when Git needs to communicate with an external -process throughout the entire life of a single Git command. All -communication is in pkt-line format (see technical/protocol-common.txt) -over standard input and standard output. - -Handshake ---------- - -Git starts by sending a welcome message (for example, -"git-filter-client"), a list of supported protocol version numbers, and -a flush packet. Git expects to read the welcome message with "server" -instead of "client" (for example, "git-filter-server"), exactly one -protocol version number from the previously sent list, and a flush -packet. All further communication will be based on the selected version. -The remaining protocol description below documents "version=2". Please -note that "version=42" in the example below does not exist and is only -there to illustrate how the protocol would look like with more than one -version. - -After the version negotiation Git sends a list of all capabilities that -it supports and a flush packet. Git expects to read a list of desired -capabilities, which must be a subset of the supported capabilities list, -and a flush packet as response: ------------------------- -packet: git> git-filter-client -packet: git> version=2 -packet: git> version=42 -packet: git> 0000 -packet: git< git-filter-server -packet: git< version=2 -packet: git< 0000 -packet: git> capability=clean -packet: git> capability=smudge -packet: git> capability=not-yet-invented -packet: git> 0000 -packet: git< capability=clean -packet: git< capability=smudge -packet: git< 0000 ------------------------- - -Shutdown --------- - -Git will close -the command pipe on exit. The filter is expected to detect EOF -and exit gracefully on its own. Git will wait until the filter -process has stopped. diff --git a/third_party/git/Documentation/technical/multi-pack-index.txt b/third_party/git/Documentation/technical/multi-pack-index.txt deleted file mode 100644 index d7e57639f7..0000000000 --- a/third_party/git/Documentation/technical/multi-pack-index.txt +++ /dev/null @@ -1,109 +0,0 @@ -Multi-Pack-Index (MIDX) Design Notes -==================================== - -The Git object directory contains a 'pack' directory containing -packfiles (with suffix ".pack") and pack-indexes (with suffix -".idx"). The pack-indexes provide a way to lookup objects and -navigate to their offset within the pack, but these must come -in pairs with the packfiles. This pairing depends on the file -names, as the pack-index differs only in suffix with its pack- -file. While the pack-indexes provide fast lookup per packfile, -this performance degrades as the number of packfiles increases, -because abbreviations need to inspect every packfile and we are -more likely to have a miss on our most-recently-used packfile. -For some large repositories, repacking into a single packfile -is not feasible due to storage space or excessive repack times. - -The multi-pack-index (MIDX for short) stores a list of objects -and their offsets into multiple packfiles. It contains: - -- A list of packfile names. -- A sorted list of object IDs. -- A list of metadata for the ith object ID including: - - A value j referring to the jth packfile. - - An offset within the jth packfile for the object. -- If large offsets are required, we use another list of large - offsets similar to version 2 pack-indexes. - -Thus, we can provide O(log N) lookup time for any number -of packfiles. - -Design Details --------------- - -- The MIDX is stored in a file named 'multi-pack-index' in the - .git/objects/pack directory. This could be stored in the pack - directory of an alternate. It refers only to packfiles in that - same directory. - -- The pack.multiIndex config setting must be on to consume MIDX files. - -- The file format includes parameters for the object ID hash - function, so a future change of hash algorithm does not require - a change in format. - -- The MIDX keeps only one record per object ID. If an object appears - in multiple packfiles, then the MIDX selects the copy in the most- - recently modified packfile. - -- If there exist packfiles in the pack directory not registered in - the MIDX, then those packfiles are loaded into the `packed_git` - list and `packed_git_mru` cache. - -- The pack-indexes (.idx files) remain in the pack directory so we - can delete the MIDX file, set core.midx to false, or downgrade - without any loss of information. - -- The MIDX file format uses a chunk-based approach (similar to the - commit-graph file) that allows optional data to be added. - -Future Work ------------ - -- Add a 'verify' subcommand to the 'git midx' builtin to verify the - contents of the multi-pack-index file match the offsets listed in - the corresponding pack-indexes. - -- The multi-pack-index allows many packfiles, especially in a context - where repacking is expensive (such as a very large repo), or - unexpected maintenance time is unacceptable (such as a high-demand - build machine). However, the multi-pack-index needs to be rewritten - in full every time. We can extend the format to be incremental, so - writes are fast. By storing a small "tip" multi-pack-index that - points to large "base" MIDX files, we can keep writes fast while - still reducing the number of binary searches required for object - lookups. - -- The reachability bitmap is currently paired directly with a single - packfile, using the pack-order as the object order to hopefully - compress the bitmaps well using run-length encoding. This could be - extended to pair a reachability bitmap with a multi-pack-index. If - the multi-pack-index is extended to store a "stable object order" - (a function Order(hash) = integer that is constant for a given hash, - even as the multi-pack-index is updated) then a reachability bitmap - could point to a multi-pack-index and be updated independently. - -- Packfiles can be marked as "special" using empty files that share - the initial name but replace ".pack" with ".keep" or ".promisor". - We can add an optional chunk of data to the multi-pack-index that - records flags of information about the packfiles. This allows new - states, such as 'repacked' or 'redeltified', that can help with - pack maintenance in a multi-pack environment. It may also be - helpful to organize packfiles by object type (commit, tree, blob, - etc.) and use this metadata to help that maintenance. - -- The partial clone feature records special "promisor" packs that - may point to objects that are not stored locally, but available - on request to a server. The multi-pack-index does not currently - track these promisor packs. - -Related Links -------------- -[0] https://bugs.chromium.org/p/git/issues/detail?id=6 - Chromium work item for: Multi-Pack Index (MIDX) - -[1] https://public-inbox.org/git/20180107181459.222909-1-dstolee@microsoft.com/ - An earlier RFC for the multi-pack-index feature - -[2] https://public-inbox.org/git/alpine.DEB.2.20.1803091557510.23109@alexmv-linux/ - Git Merge 2018 Contributor's summit notes (includes discussion of MIDX) diff --git a/third_party/git/Documentation/technical/pack-format.txt b/third_party/git/Documentation/technical/pack-format.txt deleted file mode 100644 index cab5bdd2ff..0000000000 --- a/third_party/git/Documentation/technical/pack-format.txt +++ /dev/null @@ -1,331 +0,0 @@ -Git pack format -=============== - -== pack-*.pack files have the following format: - - - A header appears at the beginning and consists of the following: - - 4-byte signature: - The signature is: {'P', 'A', 'C', 'K'} - - 4-byte version number (network byte order): - Git currently accepts version number 2 or 3 but - generates version 2 only. - - 4-byte number of objects contained in the pack (network byte order) - - Observation: we cannot have more than 4G versions ;-) and - more than 4G objects in a pack. - - - The header is followed by number of object entries, each of - which looks like this: - - (undeltified representation) - n-byte type and length (3-bit type, (n-1)*7+4-bit length) - compressed data - - (deltified representation) - n-byte type and length (3-bit type, (n-1)*7+4-bit length) - 20-byte base object name if OBJ_REF_DELTA or a negative relative - offset from the delta object's position in the pack if this - is an OBJ_OFS_DELTA object - compressed delta data - - Observation: length of each object is encoded in a variable - length format and is not constrained to 32-bit or anything. - - - The trailer records 20-byte SHA-1 checksum of all of the above. - -=== Object types - -Valid object types are: - -- OBJ_COMMIT (1) -- OBJ_TREE (2) -- OBJ_BLOB (3) -- OBJ_TAG (4) -- OBJ_OFS_DELTA (6) -- OBJ_REF_DELTA (7) - -Type 5 is reserved for future expansion. Type 0 is invalid. - -=== Deltified representation - -Conceptually there are only four object types: commit, tree, tag and -blob. However to save space, an object could be stored as a "delta" of -another "base" object. These representations are assigned new types -ofs-delta and ref-delta, which is only valid in a pack file. - -Both ofs-delta and ref-delta store the "delta" to be applied to -another object (called 'base object') to reconstruct the object. The -difference between them is, ref-delta directly encodes 20-byte base -object name. If the base object is in the same pack, ofs-delta encodes -the offset of the base object in the pack instead. - -The base object could also be deltified if it's in the same pack. -Ref-delta can also refer to an object outside the pack (i.e. the -so-called "thin pack"). When stored on disk however, the pack should -be self contained to avoid cyclic dependency. - -The delta data is a sequence of instructions to reconstruct an object -from the base object. If the base object is deltified, it must be -converted to canonical form first. Each instruction appends more and -more data to the target object until it's complete. There are two -supported instructions so far: one for copy a byte range from the -source object and one for inserting new data embedded in the -instruction itself. - -Each instruction has variable length. Instruction type is determined -by the seventh bit of the first octet. The following diagrams follow -the convention in RFC 1951 (Deflate compressed data format). - -==== Instruction to copy from base object - - +----------+---------+---------+---------+---------+-------+-------+-------+ - | 1xxxxxxx | offset1 | offset2 | offset3 | offset4 | size1 | size2 | size3 | - +----------+---------+---------+---------+---------+-------+-------+-------+ - -This is the instruction format to copy a byte range from the source -object. It encodes the offset to copy from and the number of bytes to -copy. Offset and size are in little-endian order. - -All offset and size bytes are optional. This is to reduce the -instruction size when encoding small offsets or sizes. The first seven -bits in the first octet determines which of the next seven octets is -present. If bit zero is set, offset1 is present. If bit one is set -offset2 is present and so on. - -Note that a more compact instruction does not change offset and size -encoding. For example, if only offset2 is omitted like below, offset3 -still contains bits 16-23. It does not become offset2 and contains -bits 8-15 even if it's right next to offset1. - - +----------+---------+---------+ - | 10000101 | offset1 | offset3 | - +----------+---------+---------+ - -In its most compact form, this instruction only takes up one byte -(0x80) with both offset and size omitted, which will have default -values zero. There is another exception: size zero is automatically -converted to 0x10000. - -==== Instruction to add new data - - +----------+============+ - | 0xxxxxxx | data | - +----------+============+ - -This is the instruction to construct target object without the base -object. The following data is appended to the target object. The first -seven bits of the first octet determines the size of data in -bytes. The size must be non-zero. - -==== Reserved instruction - - +----------+============ - | 00000000 | - +----------+============ - -This is the instruction reserved for future expansion. - -== Original (version 1) pack-*.idx files have the following format: - - - The header consists of 256 4-byte network byte order - integers. N-th entry of this table records the number of - objects in the corresponding pack, the first byte of whose - object name is less than or equal to N. This is called the - 'first-level fan-out' table. - - - The header is followed by sorted 24-byte entries, one entry - per object in the pack. Each entry is: - - 4-byte network byte order integer, recording where the - object is stored in the packfile as the offset from the - beginning. - - 20-byte object name. - - - The file is concluded with a trailer: - - A copy of the 20-byte SHA-1 checksum at the end of - corresponding packfile. - - 20-byte SHA-1-checksum of all of the above. - -Pack Idx file: - - -- +--------------------------------+ -fanout | fanout[0] = 2 (for example) |-. -table +--------------------------------+ | - | fanout[1] | | - +--------------------------------+ | - | fanout[2] | | - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | - | fanout[255] = total objects |---. - -- +--------------------------------+ | | -main | offset | | | -index | object name 00XXXXXXXXXXXXXXXX | | | -table +--------------------------------+ | | - | offset | | | - | object name 00XXXXXXXXXXXXXXXX | | | - +--------------------------------+<+ | - .-| offset | | - | | object name 01XXXXXXXXXXXXXXXX | | - | +--------------------------------+ | - | | offset | | - | | object name 01XXXXXXXXXXXXXXXX | | - | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | - | | offset | | - | | object name FFXXXXXXXXXXXXXXXX | | - --| +--------------------------------+<--+ -trailer | | packfile checksum | - | +--------------------------------+ - | | idxfile checksum | - | +--------------------------------+ - .-------. - | -Pack file entry: <+ - - packed object header: - 1-byte size extension bit (MSB) - type (next 3 bit) - size0 (lower 4-bit) - n-byte sizeN (as long as MSB is set, each 7-bit) - size0..sizeN form 4+7+7+..+7 bit integer, size0 - is the least significant part, and sizeN is the - most significant part. - packed object data: - If it is not DELTA, then deflated bytes (the size above - is the size before compression). - If it is REF_DELTA, then - 20-byte base object name SHA-1 (the size above is the - size of the delta data that follows). - delta data, deflated. - If it is OFS_DELTA, then - n-byte offset (see below) interpreted as a negative - offset from the type-byte of the header of the - ofs-delta entry (the size above is the size of - the delta data that follows). - delta data, deflated. - - offset encoding: - n bytes with MSB set in all but the last one. - The offset is then the number constructed by - concatenating the lower 7 bit of each byte, and - for n >= 2 adding 2^7 + 2^14 + ... + 2^(7*(n-1)) - to the result. - - - -== Version 2 pack-*.idx files support packs larger than 4 GiB, and - have some other reorganizations. They have the format: - - - A 4-byte magic number '\377tOc' which is an unreasonable - fanout[0] value. - - - A 4-byte version number (= 2) - - - A 256-entry fan-out table just like v1. - - - A table of sorted 20-byte SHA-1 object names. These are - packed together without offset values to reduce the cache - footprint of the binary search for a specific object name. - - - A table of 4-byte CRC32 values of the packed object data. - This is new in v2 so compressed data can be copied directly - from pack to pack during repacking without undetected - data corruption. - - - A table of 4-byte offset values (in network byte order). - These are usually 31-bit pack file offsets, but large - offsets are encoded as an index into the next table with - the msbit set. - - - A table of 8-byte offset entries (empty for pack files less - than 2 GiB). Pack files are organized with heavily used - objects toward the front, so most object references should - not need to refer to this table. - - - The same trailer as a v1 pack file: - - A copy of the 20-byte SHA-1 checksum at the end of - corresponding packfile. - - 20-byte SHA-1-checksum of all of the above. - -== multi-pack-index (MIDX) files have the following format: - -The multi-pack-index files refer to multiple pack-files and loose objects. - -In order to allow extensions that add extra data to the MIDX, we organize -the body into "chunks" and provide a lookup table at the beginning of the -body. The header includes certain length values, such as the number of packs, -the number of base MIDX files, hash lengths and types. - -All 4-byte numbers are in network order. - -HEADER: - - 4-byte signature: - The signature is: {'M', 'I', 'D', 'X'} - - 1-byte version number: - Git only writes or recognizes version 1. - - 1-byte Object Id Version - Git only writes or recognizes version 1 (SHA1). - - 1-byte number of "chunks" - - 1-byte number of base multi-pack-index files: - This value is currently always zero. - - 4-byte number of pack files - -CHUNK LOOKUP: - - (C + 1) * 12 bytes providing the chunk offsets: - First 4 bytes describe chunk id. Value 0 is a terminating label. - Other 8 bytes provide offset in current file for chunk to start. - (Chunks are provided in file-order, so you can infer the length - using the next chunk position if necessary.) - - The remaining data in the body is described one chunk at a time, and - these chunks may be given in any order. Chunks are required unless - otherwise specified. - -CHUNK DATA: - - Packfile Names (ID: {'P', 'N', 'A', 'M'}) - Stores the packfile names as concatenated, null-terminated strings. - Packfiles must be listed in lexicographic order for fast lookups by - name. This is the only chunk not guaranteed to be a multiple of four - bytes in length, so should be the last chunk for alignment reasons. - - OID Fanout (ID: {'O', 'I', 'D', 'F'}) - The ith entry, F[i], stores the number of OIDs with first - byte at most i. Thus F[255] stores the total - number of objects. - - OID Lookup (ID: {'O', 'I', 'D', 'L'}) - The OIDs for all objects in the MIDX are stored in lexicographic - order in this chunk. - - Object Offsets (ID: {'O', 'O', 'F', 'F'}) - Stores two 4-byte values for every object. - 1: The pack-int-id for the pack storing this object. - 2: The offset within the pack. - If all offsets are less than 2^31, then the large offset chunk - will not exist and offsets are stored as in IDX v1. - If there is at least one offset value larger than 2^32-1, then - the large offset chunk must exist. If the large offset chunk - exists and the 31st bit is on, then removing that bit reveals - the row in the large offsets containing the 8-byte offset of - this object. - - [Optional] Object Large Offsets (ID: {'L', 'O', 'F', 'F'}) - 8-byte offsets into large packfiles. - -TRAILER: - - 20-byte SHA1-checksum of the above contents. diff --git a/third_party/git/Documentation/technical/pack-heuristics.txt b/third_party/git/Documentation/technical/pack-heuristics.txt deleted file mode 100644 index 95a07db6e8..0000000000 --- a/third_party/git/Documentation/technical/pack-heuristics.txt +++ /dev/null @@ -1,460 +0,0 @@ -Concerning Git's Packing Heuristics -=================================== - - Oh, here's a really stupid question: - - Where do I go - to learn the details - of Git's packing heuristics? - -Be careful what you ask! - -Followers of the Git, please open the Git IRC Log and turn to -February 10, 2006. - -It's a rare occasion, and we are joined by the King Git Himself, -Linus Torvalds (linus). Nathaniel Smith, (njs`), has the floor -and seeks enlightenment. Others are present, but silent. - -Let's listen in! - - <njs`> Oh, here's a really stupid question -- where do I go to - learn the details of Git's packing heuristics? google avails - me not, reading the source didn't help a lot, and wading - through the whole mailing list seems less efficient than any - of that. - -It is a bold start! A plea for help combined with a simultaneous -tri-part attack on some of the tried and true mainstays in the quest -for enlightenment. Brash accusations of google being useless. Hubris! -Maligning the source. Heresy! Disdain for the mailing list archives. -Woe. - - <pasky> yes, the packing-related delta stuff is somewhat - mysterious even for me ;) - -Ah! Modesty after all. - - <linus> njs, I don't think the docs exist. That's something where - I don't think anybody else than me even really got involved. - Most of the rest of Git others have been busy with (especially - Junio), but packing nobody touched after I did it. - -It's cryptic, yet vague. Linus in style for sure. Wise men -interpret this as an apology. A few argue it is merely a -statement of fact. - - <njs`> I guess the next step is "read the source again", but I - have to build up a certain level of gumption first :-) - -Indeed! On both points. - - <linus> The packing heuristic is actually really really simple. - -Bait... - - <linus> But strange. - -And switch. That ought to do it! - - <linus> Remember: Git really doesn't follow files. So what it does is - - generate a list of all objects - - sort the list according to magic heuristics - - walk the list, using a sliding window, seeing if an object - can be diffed against another object in the window - - write out the list in recency order - -The traditional understatement: - - <njs`> I suspect that what I'm missing is the precise definition of - the word "magic" - -The traditional insight: - - <pasky> yes - -And Babel-like confusion flowed. - - <njs`> oh, hmm, and I'm not sure what this sliding window means either - - <pasky> iirc, it appeared to me to be just the sha1 of the object - when reading the code casually ... - - ... which simply doesn't sound as a very good heuristics, though ;) - - <njs`> .....and recency order. okay, I think it's clear I didn't - even realize how much I wasn't realizing :-) - -Ah, grasshopper! And thus the enlightenment begins anew. - - <linus> The "magic" is actually in theory totally arbitrary. - ANY order will give you a working pack, but no, it's not - ordered by SHA-1. - - Before talking about the ordering for the sliding delta - window, let's talk about the recency order. That's more - important in one way. - - <njs`> Right, but if all you want is a working way to pack things - together, you could just use cat and save yourself some - trouble... - -Waaait for it.... - - <linus> The recency ordering (which is basically: put objects - _physically_ into the pack in the order that they are - "reachable" from the head) is important. - - <njs`> okay - - <linus> It's important because that's the thing that gives packs - good locality. It keeps the objects close to the head (whether - they are old or new, but they are _reachable_ from the head) - at the head of the pack. So packs actually have absolutely - _wonderful_ IO patterns. - -Read that again, because it is important. - - <linus> But recency ordering is totally useless for deciding how - to actually generate the deltas, so the delta ordering is - something else. - - The delta ordering is (wait for it): - - first sort by the "basename" of the object, as defined by - the name the object was _first_ reached through when - generating the object list - - within the same basename, sort by size of the object - - but always sort different types separately (commits first). - - That's not exactly it, but it's very close. - - <njs`> The "_first_ reached" thing is not too important, just you - need some way to break ties since the same objects may be - reachable many ways, yes? - -And as if to clarify: - - <linus> The point is that it's all really just any random - heuristic, and the ordering is totally unimportant for - correctness, but it helps a lot if the heuristic gives - "clumping" for things that are likely to delta well against - each other. - -It is an important point, so secretly, I did my own research and have -included my results below. To be fair, it has changed some over time. -And through the magic of Revisionistic History, I draw upon this entry -from The Git IRC Logs on my father's birthday, March 1: - - <gitster> The quote from the above linus should be rewritten a - bit (wait for it): - - first sort by type. Different objects never delta with - each other. - - then sort by filename/dirname. hash of the basename - occupies the top BITS_PER_INT-DIR_BITS bits, and bottom - DIR_BITS are for the hash of leading path elements. - - then if we are doing "thin" pack, the objects we are _not_ - going to pack but we know about are sorted earlier than - other objects. - - and finally sort by size, larger to smaller. - -In one swell-foop, clarification and obscurification! Nonetheless, -authoritative. Cryptic, yet concise. It even solicits notions of -quotes from The Source Code. Clearly, more study is needed. - - <gitster> That's the sort order. What this means is: - - we do not delta different object types. - - we prefer to delta the objects with the same full path, but - allow files with the same name from different directories. - - we always prefer to delta against objects we are not going - to send, if there are some. - - we prefer to delta against larger objects, so that we have - lots of removals. - - The penultimate rule is for "thin" packs. It is used when - the other side is known to have such objects. - -There it is again. "Thin" packs. I'm thinking to myself, "What -is a 'thin' pack?" So I ask: - - <jdl> What is a "thin" pack? - - <gitster> Use of --objects-edge to rev-list as the upstream of - pack-objects. The pack transfer protocol negotiates that. - -Woo hoo! Cleared that _right_ up! - - <gitster> There are two directions - push and fetch. - -There! Did you see it? It is not '"push" and "pull"'! How often the -confusion has started here. So casually mentioned, too! - - <gitster> For push, git-send-pack invokes git-receive-pack on the - other end. The receive-pack says "I have up to these commits". - send-pack looks at them, and computes what are missing from - the other end. So "thin" could be the default there. - - In the other direction, fetch, git-fetch-pack and - git-clone-pack invokes git-upload-pack on the other end - (via ssh or by talking to the daemon). - - There are two cases: fetch-pack with -k and clone-pack is one, - fetch-pack without -k is the other. clone-pack and fetch-pack - with -k will keep the downloaded packfile without expanded, so - we do not use thin pack transfer. Otherwise, the generated - pack will have delta without base object in the same pack. - - But fetch-pack without -k will explode the received pack into - individual objects, so we automatically ask upload-pack to - give us a thin pack if upload-pack supports it. - -OK then. - -Uh. - -Let's return to the previous conversation still in progress. - - <njs`> and "basename" means something like "the tail of end of - path of file objects and dir objects, as per basename(3), and - we just declare all commit and tag objects to have the same - basename" or something? - -Luckily, that too is a point that gitster clarified for us! - -If I might add, the trick is to make files that _might_ be similar be -located close to each other in the hash buckets based on their file -names. It used to be that "foo/Makefile", "bar/baz/quux/Makefile" and -"Makefile" all landed in the same bucket due to their common basename, -"Makefile". However, now they land in "close" buckets. - -The algorithm allows not just for the _same_ bucket, but for _close_ -buckets to be considered delta candidates. The rationale is -essentially that files, like Makefiles, often have very similar -content no matter what directory they live in. - - <linus> I played around with different delta algorithms, and with - making the "delta window" bigger, but having too big of a - sliding window makes it very expensive to generate the pack: - you need to compare every object with a _ton_ of other objects. - - There are a number of other trivial heuristics too, which - basically boil down to "don't bother even trying to delta this - pair" if we can tell before-hand that the delta isn't worth it - (due to size differences, where we can take a previous delta - result into account to decide that "ok, no point in trying - that one, it will be worse"). - - End result: packing is actually very size efficient. It's - somewhat CPU-wasteful, but on the other hand, since you're - really only supposed to do it maybe once a month (and you can - do it during the night), nobody really seems to care. - -Nice Engineering Touch, there. Find when it doesn't matter, and -proclaim it a non-issue. Good style too! - - <njs`> So, just to repeat to see if I'm following, we start by - getting a list of the objects we want to pack, we sort it by - this heuristic (basically lexicographically on the tuple - (type, basename, size)). - - Then we walk through this list, and calculate a delta of - each object against the last n (tunable parameter) objects, - and pick the smallest of these deltas. - -Vastly simplified, but the essence is there! - - <linus> Correct. - - <njs`> And then once we have picked a delta or fulltext to - represent each object, we re-sort by recency, and write them - out in that order. - - <linus> Yup. Some other small details: - -And of course there is the "Other Shoe" Factor too. - - <linus> - We limit the delta depth to another magic value (right - now both the window and delta depth magic values are just "10") - - <njs`> Hrm, my intuition is that you'd end up with really _bad_ IO - patterns, because the things you want are near by, but to - actually reconstruct them you may have to jump all over in - random ways. - - <linus> - When we write out a delta, and we haven't yet written - out the object it is a delta against, we write out the base - object first. And no, when we reconstruct them, we actually - get nice IO patterns, because: - - larger objects tend to be "more recent" (Linus' law: files grow) - - we actively try to generate deltas from a larger object to a - smaller one - - this means that the top-of-tree very seldom has deltas - (i.e. deltas in _practice_ are "backwards deltas") - -Again, we should reread that whole paragraph. Not just because -Linus has slipped Linus's Law in there on us, but because it is -important. Let's make sure we clarify some of the points here: - - <njs`> So the point is just that in practice, delta order and - recency order match each other quite well. - - <linus> Yes. There's another nice side to this (and yes, it was - designed that way ;): - - the reason we generate deltas against the larger object is - actually a big space saver too! - - <njs`> Hmm, but your last comment (if "we haven't yet written out - the object it is a delta against, we write out the base object - first"), seems like it would make these facts mostly - irrelevant because even if in practice you would not have to - wander around much, in fact you just brute-force say that in - the cases where you might have to wander, don't do that :-) - - <linus> Yes and no. Notice the rule: we only write out the base - object first if the delta against it was more recent. That - means that you can actually have deltas that refer to a base - object that is _not_ close to the delta object, but that only - happens when the delta is needed to generate an _old_ object. - - <linus> See? - -Yeah, no. I missed that on the first two or three readings myself. - - <linus> This keeps the front of the pack dense. The front of the - pack never contains data that isn't relevant to a "recent" - object. The size optimization comes from our use of xdelta - (but is true for many other delta algorithms): removing data - is cheaper (in size) than adding data. - - When you remove data, you only need to say "copy bytes n--m". - In contrast, in a delta that _adds_ data, you have to say "add - these bytes: 'actual data goes here'" - - *** njs` has quit: Read error: 104 (Connection reset by peer) - - <linus> Uhhuh. I hope I didn't blow njs` mind. - - *** njs` has joined channel #git - - <pasky> :) - -The silent observers are amused. Of course. - -And as if njs` was expected to be omniscient: - - <linus> njs - did you miss anything? - -OK, I'll spell it out. That's Geek Humor. If njs` was not actually -connected for a little bit there, how would he know if missed anything -while he was disconnected? He's a benevolent dictator with a sense of -humor! Well noted! - - <njs`> Stupid router. Or gremlins, or whatever. - -It's a cheap shot at Cisco. Take 'em when you can. - - <njs`> Yes and no. Notice the rule: we only write out the base - object first if the delta against it was more recent. - - I'm getting lost in all these orders, let me re-read :-) - So the write-out order is from most recent to least recent? - (Conceivably it could be the opposite way too, I'm not sure if - we've said) though my connection back at home is logging, so I - can just read what you said there :-) - -And for those of you paying attention, the Omniscient Trick has just -been detailed! - - <linus> Yes, we always write out most recent first - - <njs`> And, yeah, I got the part about deeper-in-history stuff - having worse IO characteristics, one sort of doesn't care. - - <linus> With the caveat that if the "most recent" needs an older - object to delta against (hey, shrinking sometimes does - happen), we write out the old object with the delta. - - <njs`> (if only it happened more...) - - <linus> Anyway, the pack-file could easily be denser still, but - because it's used both for streaming (the Git protocol) and - for on-disk, it has a few pessimizations. - -Actually, it is a made-up word. But it is a made-up word being -used as setup for a later optimization, which is a real word: - - <linus> In particular, while the pack-file is then compressed, - it's compressed just one object at a time, so the actual - compression factor is less than it could be in theory. But it - means that it's all nice random-access with a simple index to - do "object name->location in packfile" translation. - - <njs`> I'm assuming the real win for delta-ing large->small is - more homogeneous statistics for gzip to run over? - - (You have to put the bytes in one place or another, but - putting them in a larger blob wins on compression) - - Actually, what is the compression strategy -- each delta - individually gzipped, the whole file gzipped, somewhere in - between, no compression at all, ....? - - Right. - -Reality IRC sets in. For example: - - <pasky> I'll read the rest in the morning, I really have to go - sleep or there's no hope whatsoever for me at the today's - exam... g'nite all. - -Heh. - - <linus> pasky: g'nite - - <njs`> pasky: 'luck - - <linus> Right: large->small matters exactly because of compression - behaviour. If it was non-compressed, it probably wouldn't make - any difference. - - <njs`> yeah - - <linus> Anyway: I'm not even trying to claim that the pack-files - are perfect, but they do tend to have a nice balance of - density vs ease-of use. - -Gasp! OK, saved. That's a fair Engineering trade off. Close call! -In fact, Linus reflects on some Basic Engineering Fundamentals, -design options, etc. - - <linus> More importantly, they allow Git to still _conceptually_ - never deal with deltas at all, and be a "whole object" store. - - Which has some problems (we discussed bad huge-file - behaviour on the Git lists the other day), but it does mean - that the basic Git concepts are really really simple and - straightforward. - - It's all been quite stable. - - Which I think is very much a result of having very simple - basic ideas, so that there's never any confusion about what's - going on. - - Bugs happen, but they are "simple" bugs. And bugs that - actually get some object store detail wrong are almost always - so obvious that they never go anywhere. - - <njs`> Yeah. - -Nuff said. - - <linus> Anyway. I'm off for bed. It's not 6AM here, but I've got - three kids, and have to get up early in the morning to send - them off. I need my beauty sleep. - - <njs`> :-) - - <njs`> appreciate the infodump, I really was failing to find the - details on Git packs :-) - -And now you know the rest of the story. diff --git a/third_party/git/Documentation/technical/pack-protocol.txt b/third_party/git/Documentation/technical/pack-protocol.txt deleted file mode 100644 index c73e72de0e..0000000000 --- a/third_party/git/Documentation/technical/pack-protocol.txt +++ /dev/null @@ -1,674 +0,0 @@ -Packfile transfer protocols -=========================== - -Git supports transferring data in packfiles over the ssh://, git://, http:// and -file:// transports. There exist two sets of protocols, one for pushing -data from a client to a server and another for fetching data from a -server to a client. The three transports (ssh, git, file) use the same -protocol to transfer data. http is documented in http-protocol.txt. - -The processes invoked in the canonical Git implementation are 'upload-pack' -on the server side and 'fetch-pack' on the client side for fetching data; -then 'receive-pack' on the server and 'send-pack' on the client for pushing -data. The protocol functions to have a server tell a client what is -currently on the server, then for the two to negotiate the smallest amount -of data to send in order to fully update one or the other. - -pkt-line Format ---------------- - -The descriptions below build on the pkt-line format described in -protocol-common.txt. When the grammar indicate `PKT-LINE(...)`, unless -otherwise noted the usual pkt-line LF rules apply: the sender SHOULD -include a LF, but the receiver MUST NOT complain if it is not present. - -An error packet is a special pkt-line that contains an error string. - ----- - error-line = PKT-LINE("ERR" SP explanation-text) ----- - -Throughout the protocol, where `PKT-LINE(...)` is expected, an error packet MAY -be sent. Once this packet is sent by a client or a server, the data transfer -process defined in this protocol is terminated. - -Transports ----------- -There are three transports over which the packfile protocol is -initiated. The Git transport is a simple, unauthenticated server that -takes the command (almost always 'upload-pack', though Git -servers can be configured to be globally writable, in which 'receive- -pack' initiation is also allowed) with which the client wishes to -communicate and executes it and connects it to the requesting -process. - -In the SSH transport, the client just runs the 'upload-pack' -or 'receive-pack' process on the server over the SSH protocol and then -communicates with that invoked process over the SSH connection. - -The file:// transport runs the 'upload-pack' or 'receive-pack' -process locally and communicates with it over a pipe. - -Extra Parameters ----------------- - -The protocol provides a mechanism in which clients can send additional -information in its first message to the server. These are called "Extra -Parameters", and are supported by the Git, SSH, and HTTP protocols. - -Each Extra Parameter takes the form of `<key>=<value>` or `<key>`. - -Servers that receive any such Extra Parameters MUST ignore all -unrecognized keys. Currently, the only Extra Parameter recognized is -"version" with a value of '1' or '2'. See protocol-v2.txt for more -information on protocol version 2. - -Git Transport -------------- - -The Git transport starts off by sending the command and repository -on the wire using the pkt-line format, followed by a NUL byte and a -hostname parameter, terminated by a NUL byte. - - 0033git-upload-pack /project.git\0host=myserver.com\0 - -The transport may send Extra Parameters by adding an additional NUL -byte, and then adding one or more NUL-terminated strings: - - 003egit-upload-pack /project.git\0host=myserver.com\0\0version=1\0 - --- - git-proto-request = request-command SP pathname NUL - [ host-parameter NUL ] [ NUL extra-parameters ] - request-command = "git-upload-pack" / "git-receive-pack" / - "git-upload-archive" ; case sensitive - pathname = *( %x01-ff ) ; exclude NUL - host-parameter = "host=" hostname [ ":" port ] - extra-parameters = 1*extra-parameter - extra-parameter = 1*( %x01-ff ) NUL --- - -host-parameter is used for the -git-daemon name based virtual hosting. See --interpolated-path -option to git daemon, with the %H/%CH format characters. - -Basically what the Git client is doing to connect to an 'upload-pack' -process on the server side over the Git protocol is this: - - $ echo -e -n \ - "0039git-upload-pack /schacon/gitbook.git\0host=example.com\0" | - nc -v example.com 9418 - - -SSH Transport -------------- - -Initiating the upload-pack or receive-pack processes over SSH is -executing the binary on the server via SSH remote execution. -It is basically equivalent to running this: - - $ ssh git.example.com "git-upload-pack '/project.git'" - -For a server to support Git pushing and pulling for a given user over -SSH, that user needs to be able to execute one or both of those -commands via the SSH shell that they are provided on login. On some -systems, that shell access is limited to only being able to run those -two commands, or even just one of them. - -In an ssh:// format URI, it's absolute in the URI, so the '/' after -the host name (or port number) is sent as an argument, which is then -read by the remote git-upload-pack exactly as is, so it's effectively -an absolute path in the remote filesystem. - - git clone ssh://user@example.com/project.git - | - v - ssh user@example.com "git-upload-pack '/project.git'" - -In a "user@host:path" format URI, its relative to the user's home -directory, because the Git client will run: - - git clone user@example.com:project.git - | - v - ssh user@example.com "git-upload-pack 'project.git'" - -The exception is if a '~' is used, in which case -we execute it without the leading '/'. - - ssh://user@example.com/~alice/project.git, - | - v - ssh user@example.com "git-upload-pack '~alice/project.git'" - -Depending on the value of the `protocol.version` configuration variable, -Git may attempt to send Extra Parameters as a colon-separated string in -the GIT_PROTOCOL environment variable. This is done only if -the `ssh.variant` configuration variable indicates that the ssh command -supports passing environment variables as an argument. - -A few things to remember here: - -- The "command name" is spelled with dash (e.g. git-upload-pack), but - this can be overridden by the client; - -- The repository path is always quoted with single quotes. - -Fetching Data From a Server ---------------------------- - -When one Git repository wants to get data that a second repository -has, the first can 'fetch' from the second. This operation determines -what data the server has that the client does not then streams that -data down to the client in packfile format. - - -Reference Discovery -------------------- - -When the client initially connects the server will immediately respond -with a version number (if "version=1" is sent as an Extra Parameter), -and a listing of each reference it has (all branches and tags) along -with the object name that each reference currently points to. - - $ echo -e -n "0044git-upload-pack /schacon/gitbook.git\0host=example.com\0\0version=1\0" | - nc -v example.com 9418 - 000aversion 1 - 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack - side-band side-band-64k ofs-delta shallow no-progress include-tag - 00441d3fcd5ced445d1abc402225c0b8a1299641f497 refs/heads/integration - 003f7217a7c7e582c46cec22a130adf4b9d7d950fba0 refs/heads/master - 003cb88d2441cac0977faf98efc80305012112238d9d refs/tags/v0.9 - 003c525128480b96c89e6418b1e40909bf6c5b2d580f refs/tags/v1.0 - 003fe92df48743b7bc7d26bcaabfddde0a1e20cae47c refs/tags/v1.0^{} - 0000 - -The returned response is a pkt-line stream describing each ref and -its current value. The stream MUST be sorted by name according to -the C locale ordering. - -If HEAD is a valid ref, HEAD MUST appear as the first advertised -ref. If HEAD is not a valid ref, HEAD MUST NOT appear in the -advertisement list at all, but other refs may still appear. - -The stream MUST include capability declarations behind a NUL on the -first ref. The peeled value of a ref (that is "ref^{}") MUST be -immediately after the ref itself, if presented. A conforming server -MUST peel the ref if it's an annotated tag. - ----- - advertised-refs = *1("version 1") - (no-refs / list-of-refs) - *shallow - flush-pkt - - no-refs = PKT-LINE(zero-id SP "capabilities^{}" - NUL capability-list) - - list-of-refs = first-ref *other-ref - first-ref = PKT-LINE(obj-id SP refname - NUL capability-list) - - other-ref = PKT-LINE(other-tip / other-peeled) - other-tip = obj-id SP refname - other-peeled = obj-id SP refname "^{}" - - shallow = PKT-LINE("shallow" SP obj-id) - - capability-list = capability *(SP capability) - capability = 1*(LC_ALPHA / DIGIT / "-" / "_") - LC_ALPHA = %x61-7A ----- - -Server and client MUST use lowercase for obj-id, both MUST treat obj-id -as case-insensitive. - -See protocol-capabilities.txt for a list of allowed server capabilities -and descriptions. - -Packfile Negotiation --------------------- -After reference and capabilities discovery, the client can decide to -terminate the connection by sending a flush-pkt, telling the server it can -now gracefully terminate, and disconnect, when it does not need any pack -data. This can happen with the ls-remote command, and also can happen when -the client already is up to date. - -Otherwise, it enters the negotiation phase, where the client and -server determine what the minimal packfile necessary for transport is, -by telling the server what objects it wants, its shallow objects -(if any), and the maximum commit depth it wants (if any). The client -will also send a list of the capabilities it wants to be in effect, -out of what the server said it could do with the first 'want' line. - ----- - upload-request = want-list - *shallow-line - *1depth-request - [filter-request] - flush-pkt - - want-list = first-want - *additional-want - - shallow-line = PKT-LINE("shallow" SP obj-id) - - 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) - - depth = 1*DIGIT - - filter-request = PKT-LINE("filter" SP filter-spec) ----- - -Clients MUST send all the obj-ids it wants from the reference -discovery phase as 'want' lines. Clients MUST send at least one -'want' command in the request body. Clients MUST NOT mention an -obj-id in a 'want' command which did not appear in the response -obtained through ref discovery. - -The client MUST write all obj-ids which it only has shallow copies -of (meaning that it does not have the parents of a commit) as -'shallow' lines so that the server is aware of the limitations of -the client's history. - -The client now sends the maximum commit history depth it wants for -this transaction, which is the number of commits it wants from the -tip of the history, if any, as a 'deepen' line. A depth of 0 is the -same as not making a depth request. The client does not want to receive -any commits beyond this depth, nor does it want objects needed only to -complete those commits. Commits whose parents are not received as a -result are defined as shallow and marked as such in the server. This -information is sent back to the client in the next step. - -The client can optionally request that pack-objects omit various -objects from the packfile using one of several filtering techniques. -These are intended for use with partial clone and partial fetch -operations. An object that does not meet a filter-spec value is -omitted unless explicitly requested in a 'want' line. See `rev-list` -for possible filter-spec values. - -Once all the 'want's and 'shallow's (and optional 'deepen') are -transferred, clients MUST send a flush-pkt, to tell the server side -that it is done sending the list. - -Otherwise, if the client sent a positive depth request, the server -will determine which commits will and will not be shallow and -send this information to the client. If the client did not request -a positive depth, this step is skipped. - ----- - shallow-update = *shallow-line - *unshallow-line - flush-pkt - - shallow-line = PKT-LINE("shallow" SP obj-id) - - unshallow-line = PKT-LINE("unshallow" SP obj-id) ----- - -If the client has requested a positive depth, the server will compute -the set of commits which are no deeper than the desired depth. The set -of commits start at the client's wants. - -The server writes 'shallow' lines for each -commit whose parents will not be sent as a result. The server writes -an 'unshallow' line for each commit which the client has indicated is -shallow, but is no longer shallow at the currently requested depth -(that is, its parents will now be sent). The server MUST NOT mark -as unshallow anything which the client has not indicated was shallow. - -Now the client will send a list of the obj-ids it has using 'have' -lines, so the server can make a packfile that only contains the objects -that the client needs. In multi_ack mode, the canonical implementation -will send up to 32 of these at a time, then will send a flush-pkt. The -canonical implementation will skip ahead and send the next 32 immediately, -so that there is always a block of 32 "in-flight on the wire" at a time. - ----- - upload-haves = have-list - compute-end - - have-list = *have-line - have-line = PKT-LINE("have" SP obj-id) - compute-end = flush-pkt / PKT-LINE("done") ----- - -If the server reads 'have' lines, it then will respond by ACKing any -of the obj-ids the client said it had that the server also has. The -server will ACK obj-ids differently depending on which ack mode is -chosen by the client. - -In multi_ack mode: - - * the server will respond with 'ACK obj-id continue' for any common - commits. - - * once the server has found an acceptable common base commit and is - ready to make a packfile, it will blindly ACK all 'have' obj-ids - back to the client. - - * the server will then send a 'NAK' and then wait for another response - from the client - either a 'done' or another list of 'have' lines. - -In multi_ack_detailed mode: - - * the server will differentiate the ACKs where it is signaling - that it is ready to send data with 'ACK obj-id ready' lines, and - signals the identified common commits with 'ACK obj-id common' lines. - -Without either multi_ack or multi_ack_detailed: - - * upload-pack sends "ACK obj-id" on the first common object it finds. - After that it says nothing until the client gives it a "done". - - * upload-pack sends "NAK" on a flush-pkt if no common object - has been found yet. If one has been found, and thus an ACK - was already sent, it's silent on the flush-pkt. - -After the client has gotten enough ACK responses that it can determine -that the server has enough information to send an efficient packfile -(in the canonical implementation, this is determined when it has received -enough ACKs that it can color everything left in the --date-order queue -as common with the server, or the --date-order queue is empty), or the -client determines that it wants to give up (in the canonical implementation, -this is determined when the client sends 256 'have' lines without getting -any of them ACKed by the server - meaning there is nothing in common and -the server should just send all of its objects), then the client will send -a 'done' command. The 'done' command signals to the server that the client -is ready to receive its packfile data. - -However, the 256 limit *only* turns on in the canonical client -implementation if we have received at least one "ACK %s continue" -during a prior round. This helps to ensure that at least one common -ancestor is found before we give up entirely. - -Once the 'done' line is read from the client, the server will either -send a final 'ACK obj-id' or it will send a 'NAK'. 'obj-id' is the object -name of the last commit determined to be common. The server only sends -ACK after 'done' if there is at least one common base and multi_ack or -multi_ack_detailed is enabled. The server always sends NAK after 'done' -if there is no common base found. - -Instead of 'ACK' or 'NAK', the server may send an error message (for -example, if it does not recognize an object in a 'want' line received -from the client). - -Then the server will start sending its packfile data. - ----- - server-response = *ack_multi ack / nak - ack_multi = PKT-LINE("ACK" SP obj-id ack_status) - ack_status = "continue" / "common" / "ready" - ack = PKT-LINE("ACK" SP obj-id) - nak = PKT-LINE("NAK") ----- - -A simple clone may look like this (with no 'have' lines): - ----- - C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d multi_ack \ - side-band-64k ofs-delta\n - C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n - C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n - C: 0032want 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01\n - C: 0032want 74730d410fcb6603ace96f1dc55ea6196122532d\n - C: 0000 - C: 0009done\n - - S: 0008NAK\n - S: [PACKFILE] ----- - -An incremental update (fetch) response might look like this: - ----- - C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d multi_ack \ - side-band-64k ofs-delta\n - C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n - C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n - C: 0000 - C: 0032have 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01\n - C: [30 more have lines] - C: 0032have 74730d410fcb6603ace96f1dc55ea6196122532d\n - C: 0000 - - S: 003aACK 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01 continue\n - S: 003aACK 74730d410fcb6603ace96f1dc55ea6196122532d continue\n - S: 0008NAK\n - - C: 0009done\n - - S: 0031ACK 74730d410fcb6603ace96f1dc55ea6196122532d\n - S: [PACKFILE] ----- - - -Packfile Data -------------- - -Now that the client and server have finished negotiation about what -the minimal amount of data that needs to be sent to the client is, the server -will construct and send the required data in packfile format. - -See pack-format.txt for what the packfile itself actually looks like. - -If 'side-band' or 'side-band-64k' capabilities have been specified by -the client, the server will send the packfile data multiplexed. - -Each packet starting with the packet-line length of the amount of data -that follows, followed by a single byte specifying the sideband the -following data is coming in on. - -In 'side-band' mode, it will send up to 999 data bytes plus 1 control -code, for a total of up to 1000 bytes in a pkt-line. In 'side-band-64k' -mode it will send up to 65519 data bytes plus 1 control code, for a -total of up to 65520 bytes in a pkt-line. - -The sideband byte will be a '1', '2' or a '3'. Sideband '1' will contain -packfile data, sideband '2' will be used for progress information that the -client will generally print to stderr and sideband '3' is used for error -information. - -If no 'side-band' capability was specified, the server will stream the -entire packfile without multiplexing. - - -Pushing Data To a Server ------------------------- - -Pushing data to a server will invoke the 'receive-pack' process on the -server, which will allow the client to tell it which references it should -update and then send all the data the server will need for those new -references to be complete. Once all the data is received and validated, -the server will then update its references to what the client specified. - -Authentication --------------- - -The protocol itself contains no authentication mechanisms. That is to be -handled by the transport, such as SSH, before the 'receive-pack' process is -invoked. If 'receive-pack' is configured over the Git transport, those -repositories will be writable by anyone who can access that port (9418) as -that transport is unauthenticated. - -Reference Discovery -------------------- - -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', 'ofs-delta' and -'push-options'. - -Reference Update Request and Packfile Transfer ----------------------------------------------- - -Once the client knows what references the server is at, it can send a -list of reference update requests. For each reference on the server -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. - ----- - update-requests = *shallow ( command-list | push-cert ) - - shallow = PKT-LINE("shallow" SP obj-id) - - command-list = PKT-LINE(command NUL capability-list) - *PKT-LINE(command) - flush-pkt - - command = create / delete / update - create = zero-id SP new-id SP name - delete = old-id SP zero-id SP name - update = old-id SP new-id SP name - - old-id = obj-id - new-id = obj-id - - push-cert = PKT-LINE("push-cert" NUL capability-list LF) - PKT-LINE("certificate version 0.1" LF) - PKT-LINE("pusher" SP ident LF) - PKT-LINE("pushee" SP url LF) - PKT-LINE("nonce" SP nonce LF) - *PKT-LINE("push-option" SP push-option LF) - PKT-LINE(LF) - *PKT-LINE(command LF) - *PKT-LINE(gpg-signature-lines LF) - PKT-LINE("push-cert-end" LF) - - push-option = 1*( VCHAR | SP ) ----- - -If the server has advertised the 'push-options' capability and the client has -specified 'push-options' as part of the capability list above, the client then -sends its push options followed by a flush-pkt. - ----- - push-options = *PKT-LINE(push-option) flush-pkt ----- - -For backwards compatibility with older Git servers, if the client sends a push -cert and push options, it MUST send its push options both embedded within the -push cert and after the push cert. (Note that the push options within the cert -are prefixed, but the push options after the cert are not.) Both these lists -MUST be the same, modulo the prefix. - -After that the packfile that -should contain all the objects that the server will need to complete the new -references will be sent. - ----- - packfile = "PACK" 28*(OCTET) ----- - -If the receiving end does not support delete-refs, the sending end MUST -NOT ask for delete command. - -If the receiving end does not support push-cert, the sending end -MUST NOT send a push-cert command. When a push-cert command is -sent, command-list MUST NOT be sent; the commands recorded in the -push certificate is used instead. - -The packfile MUST NOT be sent if the only command used is 'delete'. - -A packfile MUST be sent if either create or update command is used, -even if the server already has all the necessary objects. In this -case the client MUST send an empty packfile. The only time this -is likely to happen is if the client is creating -a new branch or a tag that points to an existing obj-id. - -The server will receive the packfile, unpack it, then validate each -reference that is being updated that it hasn't changed while the request -was being processed (the obj-id is still the same as the old-id), and -it will run any update hooks to make sure that the update is acceptable. -If all of that is fine, the server will then update the references. - -Push Certificate ----------------- - -A push certificate begins with a set of header lines. After the -header and an empty line, the protocol commands follow, one per -line. Note that the trailing LF in push-cert PKT-LINEs is _not_ -optional; it must be present. - -Currently, the following header fields are defined: - -`pusher` ident:: - Identify the GPG key in "Human Readable Name <email@address>" - format. - -`pushee` url:: - The repository URL (anonymized, if the URL contains - authentication material) the user who ran `git push` - intended to push into. - -`nonce` nonce:: - The 'nonce' string the receiving repository asked the - pushing user to include in the certificate, to prevent - replay attacks. - -The GPG signature lines are a detached signature for the contents -recorded in the push certificate before the signature block begins. -The detached signature is used to certify that the commands were -given by the pusher, who must be the signer. - -Report Status -------------- - -After receiving the pack data from the sender, the receiver sends a -report if 'report-status' capability is in effect. -It is a short listing of what happened in that update. It will first -list the status of the packfile unpacking as either 'unpack ok' or -'unpack [error]'. Then it will list the status for each of the references -that it tried to update. Each line is either 'ok [refname]' if the -update was successful, or 'ng [refname] [error]' if the update was not. - ----- - report-status = unpack-status - 1*(command-status) - flush-pkt - - unpack-status = PKT-LINE("unpack" SP unpack-result) - unpack-result = "ok" / error-msg - - command-status = command-ok / command-fail - command-ok = PKT-LINE("ok" SP refname) - command-fail = PKT-LINE("ng" SP refname SP error-msg) - - error-msg = 1*(OCTECT) ; where not "ok" ----- - -Updates can be unsuccessful for a number of reasons. The reference can have -changed since the reference discovery phase was originally sent, meaning -someone pushed in the meantime. The reference being pushed could be a -non-fast-forward reference and the update hooks or configuration could be -set to not allow that, etc. Also, some references can be updated while others -can be rejected. - -An example client/server communication might look like this: - ----- - S: 006274730d410fcb6603ace96f1dc55ea6196122532d refs/heads/local\0report-status delete-refs ofs-delta\n - S: 003e7d1665144a3a975c05f1f43902ddaf084e784dbe refs/heads/debug\n - S: 003f74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/master\n - S: 003d74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/team\n - S: 0000 - - C: 00677d1665144a3a975c05f1f43902ddaf084e784dbe 74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/debug\n - C: 006874730d410fcb6603ace96f1dc55ea6196122532d 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a refs/heads/master\n - C: 0000 - C: [PACKDATA] - - S: 000eunpack ok\n - S: 0018ok refs/heads/debug\n - S: 002ang refs/heads/master non-fast-forward\n ----- diff --git a/third_party/git/Documentation/technical/partial-clone.txt b/third_party/git/Documentation/technical/partial-clone.txt deleted file mode 100644 index 896c7b3878..0000000000 --- a/third_party/git/Documentation/technical/partial-clone.txt +++ /dev/null @@ -1,324 +0,0 @@ -Partial Clone Design Notes -========================== - -The "Partial Clone" feature is a performance optimization for Git that -allows Git to function without having a complete copy of the repository. -The goal of this work is to allow Git better handle extremely large -repositories. - -During clone and fetch operations, Git downloads the complete contents -and history of the repository. This includes all commits, trees, and -blobs for the complete life of the repository. For extremely large -repositories, clones can take hours (or days) and consume 100+GiB of disk -space. - -Often in these repositories there are many blobs and trees that the user -does not need such as: - - 1. files outside of the user's work area in the tree. For example, in - a repository with 500K directories and 3.5M files in every commit, - we can avoid downloading many objects if the user only needs a - narrow "cone" of the source tree. - - 2. large binary assets. For example, in a repository where large build - artifacts are checked into the tree, we can avoid downloading all - previous versions of these non-mergeable binary assets and only - download versions that are actually referenced. - -Partial clone allows us to avoid downloading such unneeded objects *in -advance* during clone and fetch operations and thereby reduce download -times and disk usage. Missing objects can later be "demand fetched" -if/when needed. - -Use of partial clone requires that the user be online and the origin -remote be available for on-demand fetching of missing objects. This may -or may not be problematic for the user. For example, if the user can -stay within the pre-selected subset of the source tree, they may not -encounter any missing objects. Alternatively, the user could try to -pre-fetch various objects if they know that they are going offline. - - -Non-Goals ---------- - -Partial clone is a mechanism to limit the number of blobs and trees downloaded -*within* a given range of commits -- and is therefore independent of and not -intended to conflict with existing DAG-level mechanisms to limit the set of -requested commits (i.e. shallow clone, single branch, or fetch '<refspec>'). - - -Design Overview ---------------- - -Partial clone logically consists of the following parts: - -- A mechanism for the client to describe unneeded or unwanted objects to - the server. - -- A mechanism for the server to omit such unwanted objects from packfiles - sent to the client. - -- A mechanism for the client to gracefully handle missing objects (that - were previously omitted by the server). - -- A mechanism for the client to backfill missing objects as needed. - - -Design Details --------------- - -- A new pack-protocol capability "filter" is added to the fetch-pack and - upload-pack negotiation. -+ -This uses the existing capability discovery mechanism. -See "filter" in Documentation/technical/pack-protocol.txt. - -- Clients pass a "filter-spec" to clone and fetch which is passed to the - server to request filtering during packfile construction. -+ -There are various filters available to accommodate different situations. -See "--filter=<filter-spec>" in Documentation/rev-list-options.txt. - -- On the server pack-objects applies the requested filter-spec as it - creates "filtered" packfiles for the client. -+ -These filtered packfiles are *incomplete* in the traditional sense because -they may contain objects that reference objects not contained in the -packfile and that the client doesn't already have. For example, the -filtered packfile may contain trees or tags that reference missing blobs -or commits that reference missing trees. - -- On the client these incomplete packfiles are marked as "promisor packfiles" - and treated differently by various commands. - -- On the client a repository extension is added to the local config to - prevent older versions of git from failing mid-operation because of - missing objects that they cannot handle. - See "extensions.partialClone" in Documentation/technical/repository-version.txt" - - -Handling Missing Objects ------------------------- - -- An object may be missing due to a partial clone or fetch, or missing due - to repository corruption. To differentiate these cases, the local - repository specially indicates such filtered packfiles obtained from the - promisor remote as "promisor packfiles". -+ -These promisor packfiles consist of a "<name>.promisor" file with -arbitrary contents (like the "<name>.keep" files), in addition to -their "<name>.pack" and "<name>.idx" files. - -- The local repository considers a "promisor object" to be an object that - it knows (to the best of its ability) that the promisor remote has promised - that it has, either because the local repository has that object in one of - its promisor packfiles, or because another promisor object refers to it. -+ -When Git encounters a missing object, Git can see if it is a promisor object -and handle it appropriately. If not, Git can report a corruption. -+ -This means that there is no need for the client to explicitly maintain an -expensive-to-modify list of missing objects.[a] - -- Since almost all Git code currently expects any referenced object to be - present locally and because we do not want to force every command to do - a dry-run first, a fallback mechanism is added to allow Git to attempt - to dynamically fetch missing objects from the promisor remote. -+ -When the normal object lookup fails to find an object, Git invokes -fetch-object to try to get the object from the server and then retry -the object lookup. This allows objects to be "faulted in" without -complicated prediction algorithms. -+ -For efficiency reasons, no check as to whether the missing object is -actually a promisor object is performed. -+ -Dynamic object fetching tends to be slow as objects are fetched one at -a time. - -- `checkout` (and any other command using `unpack-trees`) has been taught - to bulk pre-fetch all required missing blobs in a single batch. - -- `rev-list` has been taught to print missing objects. -+ -This can be used by other commands to bulk prefetch objects. -For example, a "git log -p A..B" may internally want to first do -something like "git rev-list --objects --quiet --missing=print A..B" -and prefetch those objects in bulk. - -- `fsck` has been updated to be fully aware of promisor objects. - -- `repack` in GC has been updated to not touch promisor packfiles at all, - and to only repack other objects. - -- The global variable "fetch_if_missing" is used to control whether an - object lookup will attempt to dynamically fetch a missing object or - report an error. -+ -We are not happy with this global variable and would like to remove it, -but that requires significant refactoring of the object code to pass an -additional flag. We hope that concurrent efforts to add an ODB API can -encompass this. - - -Fetching Missing Objects ------------------------- - -- Fetching of objects is done using the existing transport mechanism using - transport_fetch_refs(), setting a new transport option - TRANS_OPT_NO_DEPENDENTS to indicate that only the objects themselves are - desired, not any object that they refer to. -+ -Because some transports invoke fetch_pack() in the same process, fetch_pack() -has been updated to not use any object flags when the corresponding argument -(no_dependents) is set. - -- The local repository sends a request with the hashes of all requested - objects as "want" lines, and does not perform any packfile negotiation. - It then receives a packfile. - -- Because we are reusing the existing fetch-pack mechanism, fetching - currently fetches all objects referred to by the requested objects, even - though they are not necessary. - - -Current Limitations -------------------- - -- The remote used for a partial clone (or the first partial fetch - following a regular clone) is marked as the "promisor remote". -+ -We are currently limited to a single promisor remote and only that -remote may be used for subsequent partial fetches. -+ -We accept this limitation because we believe initial users of this -feature will be using it on repositories with a strong single central -server. - -- Dynamic object fetching will only ask the promisor remote for missing - objects. We assume that the promisor remote has a complete view of the - repository and can satisfy all such requests. - -- Repack essentially treats promisor and non-promisor packfiles as 2 - distinct partitions and does not mix them. Repack currently only works - on non-promisor packfiles and loose objects. - -- Dynamic object fetching invokes fetch-pack once *for each item* - because most algorithms stumble upon a missing object and need to have - it resolved before continuing their work. This may incur significant - overhead -- and multiple authentication requests -- if many objects are - needed. - -- Dynamic object fetching currently uses the existing pack protocol V0 - which means that each object is requested via fetch-pack. The server - will send a full set of info/refs when the connection is established. - If there are large number of refs, this may incur significant overhead. - - -Future Work ------------ - -- Allow more than one promisor remote and define a strategy for fetching - missing objects from specific promisor remotes or of iterating over the - set of promisor remotes until a missing object is found. -+ -A user might want to have multiple geographically-close cache servers -for fetching missing blobs while continuing to do filtered `git-fetch` -commands from the central server, for example. -+ -Or the user might want to work in a triangular work flow with multiple -promisor remotes that each have an incomplete view of the repository. - -- Allow repack to work on promisor packfiles (while keeping them distinct - from non-promisor packfiles). - -- Allow non-pathname-based filters to make use of packfile bitmaps (when - present). This was just an omission during the initial implementation. - -- Investigate use of a long-running process to dynamically fetch a series - of objects, such as proposed in [5,6] to reduce process startup and - overhead costs. -+ -It would be nice if pack protocol V2 could allow that long-running -process to make a series of requests over a single long-running -connection. - -- Investigate pack protocol V2 to avoid the info/refs broadcast on - each connection with the server to dynamically fetch missing objects. - -- Investigate the need to handle loose promisor objects. -+ -Objects in promisor packfiles are allowed to reference missing objects -that can be dynamically fetched from the server. An assumption was -made that loose objects are only created locally and therefore should -not reference a missing object. We may need to revisit that assumption -if, for example, we dynamically fetch a missing tree and store it as a -loose object rather than a single object packfile. -+ -This does not necessarily mean we need to mark loose objects as promisor; -it may be sufficient to relax the object lookup or is-promisor functions. - - -Non-Tasks ---------- - -- Every time the subject of "demand loading blobs" comes up it seems - that someone suggests that the server be allowed to "guess" and send - additional objects that may be related to the requested objects. -+ -No work has gone into actually doing that; we're just documenting that -it is a common suggestion. We're not sure how it would work and have -no plans to work on it. -+ -It is valid for the server to send more objects than requested (even -for a dynamic object fetch), but we are not building on that. - - -Footnotes ---------- - -[a] expensive-to-modify list of missing objects: Earlier in the design of - partial clone we discussed the need for a single list of missing objects. - This would essentially be a sorted linear list of OIDs that the were - omitted by the server during a clone or subsequent fetches. - -This file would need to be loaded into memory on every object lookup. -It would need to be read, updated, and re-written (like the .git/index) -on every explicit "git fetch" command *and* on any dynamic object fetch. - -The cost to read, update, and write this file could add significant -overhead to every command if there are many missing objects. For example, -if there are 100M missing blobs, this file would be at least 2GiB on disk. - -With the "promisor" concept, we *infer* a missing object based upon the -type of packfile that references it. - - -Related Links -------------- -[0] https://crbug.com/git/2 - Bug#2: Partial Clone - -[1] https://public-inbox.org/git/20170113155253.1644-1-benpeart@microsoft.com/ + - Subject: [RFC] Add support for downloading blobs on demand + - Date: Fri, 13 Jan 2017 10:52:53 -0500 - -[2] https://public-inbox.org/git/cover.1506714999.git.jonathantanmy@google.com/ + - Subject: [PATCH 00/18] Partial clone (from clone to lazy fetch in 18 patches) + - Date: Fri, 29 Sep 2017 13:11:36 -0700 - -[3] https://public-inbox.org/git/20170426221346.25337-1-jonathantanmy@google.com/ + - Subject: Proposal for missing blob support in Git repos + - Date: Wed, 26 Apr 2017 15:13:46 -0700 - -[4] https://public-inbox.org/git/1488999039-37631-1-git-send-email-git@jeffhostetler.com/ + - Subject: [PATCH 00/10] RFC Partial Clone and Fetch + - Date: Wed, 8 Mar 2017 18:50:29 +0000 - -[5] https://public-inbox.org/git/20170505152802.6724-1-benpeart@microsoft.com/ + - Subject: [PATCH v7 00/10] refactor the filter process code into a reusable module + - Date: Fri, 5 May 2017 11:27:52 -0400 - -[6] https://public-inbox.org/git/20170714132651.170708-1-benpeart@microsoft.com/ + - Subject: [RFC/PATCH v2 0/1] Add support for downloading blobs on demand + - Date: Fri, 14 Jul 2017 09:26:50 -0400 diff --git a/third_party/git/Documentation/technical/protocol-capabilities.txt b/third_party/git/Documentation/technical/protocol-capabilities.txt deleted file mode 100644 index 2b267c0da6..0000000000 --- a/third_party/git/Documentation/technical/protocol-capabilities.txt +++ /dev/null @@ -1,337 +0,0 @@ -Git Protocol Capabilities -========================= - -NOTE: this document describes capabilities for versions 0 and 1 of the pack -protocol. For version 2, please refer to the link:protocol-v2.html[protocol-v2] -doc. - -Servers SHOULD support all capabilities defined in this document. - -On the very first line of the initial server response of either -receive-pack and upload-pack the first reference is followed by -a NUL byte and then a list of space delimited server capabilities. -These allow the server to declare what it can and cannot support -to the client. - -Client will then send a space separated list of capabilities it wants -to be in effect. The client MUST NOT ask for capabilities the server -did not say it supports. - -Server MUST diagnose and abort if capabilities it does not understand -was sent. Server MUST NOT ignore capabilities that client requested -and server advertised. As a consequence of these rules, server MUST -NOT advertise capabilities it does not understand. - -The 'atomic', 'report-status', 'delete-refs', 'quiet', and 'push-cert' -capabilities are sent and recognized by the receive-pack (push to server) -process. - -The 'ofs-delta' and 'side-band-64k' capabilities are sent and recognized -by both upload-pack and receive-pack protocols. The 'agent' capability -may optionally be sent in both protocols. - -All other capabilities are only recognized by the upload-pack (fetch -from server) process. - -multi_ack ---------- - -The 'multi_ack' capability allows the server to return "ACK obj-id -continue" as soon as it finds a commit that it can use as a common -base, between the client's wants and the client's have set. - -By sending this early, the server can potentially head off the client -from walking any further down that particular branch of the client's -repository history. The client may still need to walk down other -branches, sending have lines for those, until the server has a -complete cut across the DAG, or the client has said "done". - -Without multi_ack, a client sends have lines in --date-order until -the server has found a common base. That means the client will send -have lines that are already known by the server to be common, because -they overlap in time with another branch that the server hasn't found -a common base on yet. - -For example suppose the client has commits in caps that the server -doesn't and the server has commits in lower case that the client -doesn't, as in the following diagram: - - +---- u ---------------------- x - / +----- y - / / - a -- b -- c -- d -- E -- F - \ - +--- Q -- R -- S - -If the client wants x,y and starts out by saying have F,S, the server -doesn't know what F,S is. Eventually the client says "have d" and -the server sends "ACK d continue" to let the client know to stop -walking down that line (so don't send c-b-a), but it's not done yet, -it needs a base for x. The client keeps going with S-R-Q, until a -gets reached, at which point the server has a clear base and it all -ends. - -Without multi_ack the client would have sent that c-b-a chain anyway, -interleaved with S-R-Q. - -multi_ack_detailed ------------------- -This is an extension of multi_ack that permits client to better -understand the server's in-memory state. See pack-protocol.txt, -section "Packfile Negotiation" for more information. - -no-done -------- -This capability should only be used with the smart HTTP protocol. If -multi_ack_detailed and no-done are both present, then the sender is -free to immediately send a pack following its first "ACK obj-id ready" -message. - -Without no-done in the smart HTTP protocol, the server session would -end and the client has to make another trip to send "done" before -the server can send the pack. no-done removes the last round and -thus slightly reduces latency. - -thin-pack ---------- - -A thin pack is one with deltas which reference base objects not -contained within the pack (but are known to exist at the receiving -end). This can reduce the network traffic significantly, but it -requires the receiving end to know how to "thicken" these packs by -adding the missing bases to the pack. - -The upload-pack server advertises 'thin-pack' when it can generate -and send a thin pack. A client requests the 'thin-pack' capability -when it understands how to "thicken" it, notifying the server that -it can receive such a pack. A client MUST NOT request the -'thin-pack' capability if it cannot turn a thin pack into a -self-contained pack. - -Receive-pack, on the other hand, is assumed by default to be able to -handle thin packs, but can ask the client not to use the feature by -advertising the 'no-thin' capability. A client MUST NOT send a thin -pack if the server advertises the 'no-thin' capability. - -The reasons for this asymmetry are historical. The receive-pack -program did not exist until after the invention of thin packs, so -historically the reference implementation of receive-pack always -understood thin packs. Adding 'no-thin' later allowed receive-pack -to disable the feature in a backwards-compatible manner. - - -side-band, side-band-64k ------------------------- - -This capability means that server can send, and client understand multiplexed -progress reports and error info interleaved with the packfile itself. - -These two options are mutually exclusive. A modern client always -favors 'side-band-64k'. - -Either mode indicates that the packfile data will be streamed broken -up into packets of up to either 1000 bytes in the case of 'side_band', -or 65520 bytes in the case of 'side_band_64k'. Each packet is made up -of a leading 4-byte pkt-line length of how much data is in the packet, -followed by a 1-byte stream code, followed by the actual data. - -The stream code can be one of: - - 1 - pack data - 2 - progress messages - 3 - fatal error message just before stream aborts - -The "side-band-64k" capability came about as a way for newer clients -that can handle much larger packets to request packets that are -actually crammed nearly full, while maintaining backward compatibility -for the older clients. - -Further, with side-band and its up to 1000-byte messages, it's actually -999 bytes of payload and 1 byte for the stream code. With side-band-64k, -same deal, you have up to 65519 bytes of data and 1 byte for the stream -code. - -The client MUST send only maximum of one of "side-band" and "side- -band-64k". Server MUST diagnose it as an error if client requests -both. - -ofs-delta ---------- - -Server can send, and client understand PACKv2 with delta referring to -its base by position in pack rather than by an obj-id. That is, they can -send/read OBJ_OFS_DELTA (aka type 6) in a packfile. - -agent ------ - -The server may optionally send a capability of the form `agent=X` to -notify the client that the server is running version `X`. The client may -optionally return its own agent string by responding with an `agent=Y` -capability (but it MUST NOT do so if the server did not mention the -agent capability). The `X` and `Y` strings may contain any printable -ASCII characters except space (i.e., the byte range 32 < x < 127), and -are typically of the form "package/version" (e.g., "git/1.8.3.1"). The -agent strings are purely informative for statistics and debugging -purposes, and MUST NOT be used to programmatically assume the presence -or absence of particular features. - -symref ------- - -This parameterized capability is used to inform the receiver which symbolic ref -points to which ref; for example, "symref=HEAD:refs/heads/master" tells the -receiver that HEAD points to master. This capability can be repeated to -represent multiple symrefs. - -Servers SHOULD include this capability for the HEAD symref if it is one of the -refs being sent. - -Clients MAY use the parameters from this capability to select the proper initial -branch when cloning a repository. - -shallow -------- - -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 ------------ - -The client was started with "git clone -q" or something, and doesn't -want that side band 2. Basically the client just says "I do not -wish to receive stream 2 on sideband, so do not send it to me, and if -you did, I will drop it on the floor anyway". However, the sideband -channel 3 is still used for error responses. - -include-tag ------------ - -The 'include-tag' capability is about sending annotated tags if we are -sending objects they point to. If we pack an object to the client, and -a tag object points exactly at that object, we pack the tag object too. -In general this allows a client to get all new annotated tags when it -fetches a branch, in a single network connection. - -Clients MAY always send include-tag, hardcoding it into a request when -the server advertises this capability. The decision for a client to -request include-tag only has to do with the client's desires for tag -data, whether or not a server had advertised objects in the -refs/tags/* namespace. - -Servers MUST pack the tags if their referrant is packed and the client -has requested include-tags. - -Clients MUST be prepared for the case where a server has ignored -include-tag and has not actually sent tags in the pack. In such -cases the client SHOULD issue a subsequent fetch to acquire the tags -that include-tag would have otherwise given the client. - -The server SHOULD send include-tag, if it supports it, regardless -of whether or not there are tags available. - -report-status -------------- - -The receive-pack process can receive a 'report-status' capability, -which tells it that the client wants a report of what happened after -a packfile upload and reference update. If the pushing client requests -this capability, after unpacking and updating references the server -will respond with whether the packfile unpacked successfully and if -each reference was updated successfully. If any of those were not -successful, it will send back an error message. See pack-protocol.txt -for example messages. - -delete-refs ------------ - -If the server sends back the 'delete-refs' capability, it means that -it is capable of accepting a zero-id value as the target -value of a reference update. It is not sent back by the client, it -simply informs the client that it can be sent zero-id values -to delete references. - -quiet ------ - -If the receive-pack server advertises the 'quiet' capability, it is -capable of silencing human-readable progress output which otherwise may -be shown when processing the received pack. A send-pack client should -respond with the 'quiet' capability to suppress server-side progress -reporting if the local progress reporting is also being suppressed -(e.g., via `push -q`, or if stderr does not go to a tty). - -atomic ------- - -If the server sends the 'atomic' capability it is capable of accepting -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 ----------------------- - -If the upload-pack server advertises this capability, fetch-pack may -send "want" lines with SHA-1s that exist at the server but are not -advertised by upload-pack. - -allow-reachable-sha1-in-want ----------------------------- - -If the upload-pack server advertises this capability, fetch-pack may -send "want" lines with SHA-1s that exist at the server but are not -advertised by upload-pack. - -push-cert=<nonce> ------------------ - -The receive-pack server that advertises this capability is willing -to accept a signed push certificate, and asks the <nonce> to be -included in the push certificate. A send-pack client MUST NOT -send a push-cert packet unless the receive-pack server advertises -this capability. - -filter ------- - -If the upload-pack server advertises the 'filter' capability, -fetch-pack may send "filter" commands to request a partial clone -or partial fetch and request that the server omit various objects -from the packfile. diff --git a/third_party/git/Documentation/technical/protocol-common.txt b/third_party/git/Documentation/technical/protocol-common.txt deleted file mode 100644 index ecedb34bba..0000000000 --- a/third_party/git/Documentation/technical/protocol-common.txt +++ /dev/null @@ -1,99 +0,0 @@ -Documentation Common to Pack and Http Protocols -=============================================== - -ABNF Notation -------------- - -ABNF notation as described by RFC 5234 is used within the protocol documents, -except the following replacement core rules are used: ----- - HEXDIG = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" ----- - -We also define the following common rules: ----- - NUL = %x00 - zero-id = 40*"0" - obj-id = 40*(HEXDIGIT) - - refname = "HEAD" - refname /= "refs/" <see discussion below> ----- - -A refname is a hierarchical octet string beginning with "refs/" and -not violating the 'git-check-ref-format' command's validation rules. -More specifically, they: - -. They can include slash `/` for hierarchical (directory) - grouping, but no slash-separated component can begin with a - dot `.`. - -. They must contain at least one `/`. This enforces the presence of a - category like `heads/`, `tags/` etc. but the actual names are not - restricted. - -. They cannot have two consecutive dots `..` anywhere. - -. They cannot have ASCII control characters (i.e. bytes whose - values are lower than \040, or \177 `DEL`), space, tilde `~`, - caret `^`, colon `:`, question-mark `?`, asterisk `*`, - or open bracket `[` anywhere. - -. They cannot end with a slash `/` or a dot `.`. - -. They cannot end with the sequence `.lock`. - -. They cannot contain a sequence `@{`. - -. They cannot contain a `\\`. - - -pkt-line Format ---------------- - -Much (but not all) of the payload is described around pkt-lines. - -A pkt-line is a variable length binary string. The first four bytes -of the line, the pkt-len, indicates the total length of the line, -in hexadecimal. The pkt-len includes the 4 bytes used to contain -the length's hexadecimal representation. - -A pkt-line MAY contain binary data, so implementors MUST ensure -pkt-line parsing/formatting routines are 8-bit clean. - -A non-binary line SHOULD BE terminated by an LF, which if present -MUST be included in the total length. Receivers MUST treat pkt-lines -with non-binary data the same whether or not they contain the trailing -LF (stripping the LF if present, and not complaining when it is -missing). - -The maximum length of a pkt-line's data component is 65516 bytes. -Implementations MUST NOT send pkt-line whose length exceeds 65520 -(65516 bytes of payload + 4 bytes of length data). - -Implementations SHOULD NOT send an empty pkt-line ("0004"). - -A pkt-line with a length field of 0 ("0000"), called a flush-pkt, -is a special case and MUST be handled differently than an empty -pkt-line ("0004"). - ----- - pkt-line = data-pkt / flush-pkt - - data-pkt = pkt-len pkt-payload - pkt-len = 4*(HEXDIG) - pkt-payload = (pkt-len - 4)*(OCTET) - - flush-pkt = "0000" ----- - -Examples (as C-style strings): - ----- - pkt-line actual value - --------------------------------- - "0006a\n" "a\n" - "0005a" "a" - "000bfoobar\n" "foobar\n" - "0004" "" ----- diff --git a/third_party/git/Documentation/technical/protocol-v2.txt b/third_party/git/Documentation/technical/protocol-v2.txt deleted file mode 100644 index 40f91f6b1e..0000000000 --- a/third_party/git/Documentation/technical/protocol-v2.txt +++ /dev/null @@ -1,455 +0,0 @@ -Git Wire Protocol, Version 2 -============================ - -This document presents a specification for a version 2 of Git's wire -protocol. Protocol v2 will improve upon v1 in the following ways: - - * Instead of multiple service names, multiple commands will be - supported by a single service - * Easily extendable as capabilities are moved into their own section - of the protocol, no longer being hidden behind a NUL byte and - limited by the size of a pkt-line - * Separate out other information hidden behind NUL bytes (e.g. agent - string as a capability and symrefs can be requested using 'ls-refs') - * Reference advertisement will be omitted unless explicitly requested - * ls-refs command to explicitly request some refs - * Designed with http and stateless-rpc in mind. With clear flush - semantics the http remote helper can simply act as a proxy - -In protocol v2 communication is command oriented. When first contacting a -server a list of capabilities will advertised. Some of these capabilities -will be commands which a client can request be executed. Once a command -has completed, a client can reuse the connection and request that other -commands be executed. - -Packet-Line Framing -------------------- - -All communication is done using packet-line framing, just as in v1. See -`Documentation/technical/pack-protocol.txt` and -`Documentation/technical/protocol-common.txt` for more information. - -In protocol v2 these special packets will have the following semantics: - - * '0000' Flush Packet (flush-pkt) - indicates the end of a message - * '0001' Delimiter Packet (delim-pkt) - separates sections of a message - -Initial Client Request ----------------------- - -In general a client can request to speak protocol v2 by sending -`version=2` through the respective side-channel for the transport being -used which inevitably sets `GIT_PROTOCOL`. More information can be -found in `pack-protocol.txt` and `http-protocol.txt`. In all cases the -response from the server is the capability advertisement. - -Git Transport -~~~~~~~~~~~~~ - -When using the git:// transport, you can request to use protocol v2 by -sending "version=2" as an extra parameter: - - 003egit-upload-pack /project.git\0host=myserver.com\0\0version=2\0 - -SSH and File Transport -~~~~~~~~~~~~~~~~~~~~~~ - -When using either the ssh:// or file:// transport, the GIT_PROTOCOL -environment variable must be set explicitly to include "version=2". - -HTTP Transport -~~~~~~~~~~~~~~ - -When using the http:// or https:// transport a client makes a "smart" -info/refs request as described in `http-protocol.txt` and requests that -v2 be used by supplying "version=2" in the `Git-Protocol` header. - - C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0 - C: Git-Protocol: version=2 - -A v2 server would reply: - - S: 200 OK - S: <Some headers> - S: ... - S: - S: 000eversion 2\n - S: <capability-advertisement> - -Subsequent requests are then made directly to the service -`$GIT_URL/git-upload-pack`. (This works the same for git-receive-pack). - -Capability Advertisement ------------------------- - -A server which decides to communicate (based on a request from a client) -using protocol version 2, notifies the client by sending a version string -in its initial response followed by an advertisement of its capabilities. -Each capability is a key with an optional value. Clients must ignore all -unknown keys. Semantics of unknown values are left to the definition of -each key. Some capabilities will describe commands which can be requested -to be executed by the client. - - capability-advertisement = protocol-version - capability-list - flush-pkt - - protocol-version = PKT-LINE("version 2" LF) - capability-list = *capability - capability = PKT-LINE(key[=value] LF) - - key = 1*(ALPHA | DIGIT | "-_") - value = 1*(ALPHA | DIGIT | " -_.,?\/{}[]()<>!@#$%^&*+=:;") - -Command Request ---------------- - -After receiving the capability advertisement, a client can then issue a -request to select the command it wants with any particular capabilities -or arguments. There is then an optional section where the client can -provide any command specific parameters or queries. Only a single -command can be requested at a time. - - request = empty-request | command-request - empty-request = flush-pkt - command-request = command - capability-list - [command-args] - flush-pkt - command = PKT-LINE("command=" key LF) - command-args = delim-pkt - *command-specific-arg - - command-specific-args are packet line framed arguments defined by - each individual command. - -The server will then check to ensure that the client's request is -comprised of a valid command as well as valid capabilities which were -advertised. If the request is valid the server will then execute the -command. A server MUST wait till it has received the client's entire -request before issuing a response. The format of the response is -determined by the command being executed, but in all cases a flush-pkt -indicates the end of the response. - -When a command has finished, and the client has received the entire -response from the server, a client can either request that another -command be executed or can terminate the connection. A client may -optionally send an empty request consisting of just a flush-pkt to -indicate that no more requests will be made. - -Capabilities ------------- - -There are two different types of capabilities: normal capabilities, -which can be used to convey information or alter the behavior of a -request, and commands, which are the core actions that a client wants to -perform (fetch, push, etc). - -Protocol version 2 is stateless by default. This means that all commands -must only last a single round and be stateless from the perspective of the -server side, unless the client has requested a capability indicating that -state should be maintained by the server. Clients MUST NOT require state -management on the server side in order to function correctly. This -permits simple round-robin load-balancing on the server side, without -needing to worry about state management. - -agent -~~~~~ - -The server can advertise the `agent` capability with a value `X` (in the -form `agent=X`) to notify the client that the server is running version -`X`. The client may optionally send its own agent string by including -the `agent` capability with a value `Y` (in the form `agent=Y`) in its -request to the server (but it MUST NOT do so if the server did not -advertise the agent capability). The `X` and `Y` strings may contain any -printable ASCII characters except space (i.e., the byte range 32 < x < -127), and are typically of the form "package/version" (e.g., -"git/1.8.3.1"). The agent strings are purely informative for statistics -and debugging purposes, and MUST NOT be used to programmatically assume -the presence or absence of particular features. - -ls-refs -~~~~~~~ - -`ls-refs` is the command used to request a reference advertisement in v2. -Unlike the current reference advertisement, ls-refs takes in arguments -which can be used to limit the refs sent from the server. - -Additional features not supported in the base command will be advertised -as the value of the command in the capability advertisement in the form -of a space separated list of features: "<command>=<feature 1> <feature 2>" - -ls-refs takes in the following arguments: - - symrefs - In addition to the object pointed by it, show the underlying ref - pointed by it when showing a symbolic ref. - peel - Show peeled tags. - ref-prefix <prefix> - When specified, only references having a prefix matching one of - the provided prefixes are displayed. - -The output of ls-refs is as follows: - - output = *ref - flush-pkt - ref = PKT-LINE(obj-id SP refname *(SP ref-attribute) LF) - ref-attribute = (symref | peeled) - symref = "symref-target:" symref-target - peeled = "peeled:" obj-id - -fetch -~~~~~ - -`fetch` is the command used to fetch a packfile in v2. It can be looked -at as a modified version of the v1 fetch where the ref-advertisement is -stripped out (since the `ls-refs` command fills that role) and the -message format is tweaked to eliminate redundancies and permit easy -addition of future extensions. - -Additional features not supported in the base command will be advertised -as the value of the command in the capability advertisement in the form -of a space separated list of features: "<command>=<feature 1> <feature 2>" - -A `fetch` request can take the following arguments: - - want <oid> - Indicates to the server an object which the client wants to - retrieve. Wants can be anything and are not limited to - advertised objects. - - have <oid> - Indicates to the server an object which the client has locally. - This allows the server to make a packfile which only contains - the objects that the client needs. Multiple 'have' lines can be - supplied. - - done - Indicates to the server that negotiation should terminate (or - not even begin if performing a clone) and that the server should - use the information supplied in the request to construct the - packfile. - - thin-pack - Request that a thin pack be sent, which is a pack with deltas - which reference base objects not contained within the pack (but - are known to exist at the receiving end). This can reduce the - network traffic significantly, but it requires the receiving end - to know how to "thicken" these packs by adding the missing bases - to the pack. - - no-progress - Request that progress information that would normally be sent on - side-band channel 2, during the packfile transfer, should not be - sent. However, the side-band channel 3 is still used for error - responses. - - include-tag - Request that annotated tags should be sent if the objects they - point to are being sent. - - ofs-delta - Indicate that the client understands PACKv2 with delta referring - to its base by position in pack rather than by an oid. That is, - they can read OBJ_OFS_DELTA (ake type 6) in a packfile. - -If the 'shallow' feature is advertised the following arguments can be -included in the clients request as well as the potential addition of the -'shallow-info' section in the server's response as explained below. - - shallow <oid> - A client must notify the server of all commits for which it only - has shallow copies (meaning that it doesn't have the parents of - a commit) by supplying a 'shallow <oid>' line for each such - object so that the server is aware of the limitations of the - client's history. This is so that the server is aware that the - client may not have all objects reachable from such commits. - - deepen <depth> - Requests that the fetch/clone should be shallow having a commit - depth of <depth> relative to the remote side. - - deepen-relative - Requests that the semantics of the "deepen" command be changed - to indicate that the depth requested is relative to the client's - current shallow boundary, instead of relative to the requested - commits. - - deepen-since <timestamp> - Requests that the shallow clone/fetch should be cut at a - specific time, instead of depth. Internally it's equivalent to - doing "git rev-list --max-age=<timestamp>". Cannot be used with - "deepen". - - deepen-not <rev> - Requests that the shallow clone/fetch should be cut at a - specific revision specified by '<rev>', instead of a depth. - Internally it's equivalent of doing "git rev-list --not <rev>". - Cannot be used with "deepen", but can be used with - "deepen-since". - -If the 'filter' feature is advertised, the following argument can be -included in the client's request: - - filter <filter-spec> - Request that various objects from the packfile be omitted - using one of several filtering techniques. These are intended - for use with partial clone and partial fetch operations. See - `rev-list` for possible "filter-spec" values. When communicating - with other processes, senders SHOULD translate scaled integers - (e.g. "1k") into a fully-expanded form (e.g. "1024") to aid - interoperability with older receivers that may not understand - newly-invented scaling suffixes. However, receivers SHOULD - accept the following suffixes: 'k', 'm', and 'g' for 1024, - 1048576, and 1073741824, respectively. - -If the 'ref-in-want' feature is advertised, the following argument can -be included in the client's request as well as the potential addition of -the 'wanted-refs' section in the server's response as explained below. - - want-ref <ref> - Indicates to the server that the client wants to retrieve a - particular ref, where <ref> is the full name of a ref on the - server. - -If the 'sideband-all' feature is advertised, the following argument can be -included in the client's request: - - sideband-all - Instruct the server to send the whole response multiplexed, not just - the packfile section. All non-flush and non-delim PKT-LINE in the - response (not only in the packfile section) will then start with a byte - indicating its sideband (1, 2, or 3), and the server may send "0005\2" - (a PKT-LINE of sideband 2 with no payload) as a keepalive packet. - -The response of `fetch` is broken into a number of sections separated by -delimiter packets (0001), with each section beginning with its section -header. - - output = *section - section = (acknowledgments | shallow-info | wanted-refs | packfile) - (flush-pkt | delim-pkt) - - acknowledgments = PKT-LINE("acknowledgments" LF) - (nak | *ack) - (ready) - ready = PKT-LINE("ready" LF) - nak = PKT-LINE("NAK" LF) - ack = PKT-LINE("ACK" SP obj-id LF) - - shallow-info = PKT-LINE("shallow-info" LF) - *PKT-LINE((shallow | unshallow) LF) - shallow = "shallow" SP obj-id - unshallow = "unshallow" SP obj-id - - wanted-refs = PKT-LINE("wanted-refs" LF) - *PKT-LINE(wanted-ref LF) - wanted-ref = obj-id SP refname - - packfile = PKT-LINE("packfile" LF) - *PKT-LINE(%x01-03 *%x00-ff) - - acknowledgments section - * If the client determines that it is finished with negotiations - by sending a "done" line, the acknowledgments sections MUST be - omitted from the server's response. - - * Always begins with the section header "acknowledgments" - - * The server will respond with "NAK" if none of the object ids sent - as have lines were common. - - * The server will respond with "ACK obj-id" for all of the - object ids sent as have lines which are common. - - * A response cannot have both "ACK" lines as well as a "NAK" - line. - - * The server will respond with a "ready" line indicating that - the server has found an acceptable common base and is ready to - make and send a packfile (which will be found in the packfile - section of the same response) - - * If the server has found a suitable cut point and has decided - to send a "ready" line, then the server can decide to (as an - optimization) omit any "ACK" lines it would have sent during - its response. This is because the server will have already - determined the objects it plans to send to the client and no - further negotiation is needed. - - shallow-info section - * If the client has requested a shallow fetch/clone, a shallow - client requests a fetch or the server is shallow then the - server's response may include a shallow-info section. The - shallow-info section will be included if (due to one of the - above conditions) the server needs to inform the client of any - shallow boundaries or adjustments to the clients already - existing shallow boundaries. - - * Always begins with the section header "shallow-info" - - * If a positive depth is requested, the server will compute the - set of commits which are no deeper than the desired depth. - - * The server sends a "shallow obj-id" line for each commit whose - parents will not be sent in the following packfile. - - * The server sends an "unshallow obj-id" line for each commit - which the client has indicated is shallow, but is no longer - shallow as a result of the fetch (due to its parents being - sent in the following packfile). - - * The server MUST NOT send any "unshallow" lines for anything - which the client has not indicated was shallow as a part of - its request. - - * This section is only included if a packfile section is also - included in the response. - - wanted-refs section - * This section is only included if the client has requested a - ref using a 'want-ref' line and if a packfile section is also - included in the response. - - * Always begins with the section header "wanted-refs". - - * The server will send a ref listing ("<oid> <refname>") for - each reference requested using 'want-ref' lines. - - * The server MUST NOT send any refs which were not requested - using 'want-ref' lines. - - packfile section - * This section is only included if the client has sent 'want' - lines in its request and either requested that no more - negotiation be done by sending 'done' or if the server has - decided it has found a sufficient cut point to produce a - packfile. - - * Always begins with the section header "packfile" - - * The transmission of the packfile begins immediately after the - section header - - * The data transfer of the packfile is always multiplexed, using - the same semantics of the 'side-band-64k' capability from - protocol version 1. This means that each packet, during the - packfile data stream, is made up of a leading 4-byte pkt-line - length (typical of the pkt-line format), followed by a 1-byte - stream code, followed by the actual data. - - The stream code can be one of: - 1 - pack data - 2 - progress messages - 3 - fatal error message just before stream aborts - -server-option -~~~~~~~~~~~~~ - -If advertised, indicates that any number of server specific options can be -included in a request. This is done by sending each option as a -"server-option=<option>" capability line in the capability-list section of -a request. - -The provided options must not contain a NUL or LF character. diff --git a/third_party/git/Documentation/technical/racy-git.txt b/third_party/git/Documentation/technical/racy-git.txt deleted file mode 100644 index 4a8be4d144..0000000000 --- a/third_party/git/Documentation/technical/racy-git.txt +++ /dev/null @@ -1,201 +0,0 @@ -Use of index and Racy Git problem -================================= - -Background ----------- - -The index is one of the most important data structures in Git. -It represents a virtual working tree state by recording list of -paths and their object names and serves as a staging area to -write out the next tree object to be committed. The state is -"virtual" in the sense that it does not necessarily have to, and -often does not, match the files in the working tree. - -There are cases Git needs to examine the differences between the -virtual working tree state in the index and the files in the -working tree. The most obvious case is when the user asks `git -diff` (or its low level implementation, `git diff-files`) or -`git-ls-files --modified`. In addition, Git internally checks -if the files in the working tree are different from what are -recorded in the index to avoid stomping on local changes in them -during patch application, switching branches, and merging. - -In order to speed up this comparison between the files in the -working tree and the index entries, the index entries record the -information obtained from the filesystem via `lstat(2)` system -call when they were last updated. When checking if they differ, -Git first runs `lstat(2)` on the files and compares the result -with this information (this is what was originally done by the -`ce_match_stat()` function, but the current code does it in -`ce_match_stat_basic()` function). If some of these "cached -stat information" fields do not match, Git can tell that the -files are modified without even looking at their contents. - -Note: not all members in `struct stat` obtained via `lstat(2)` -are used for this comparison. For example, `st_atime` obviously -is not useful. Currently, Git compares the file type (regular -files vs symbolic links) and executable bits (only for regular -files) from `st_mode` member, `st_mtime` and `st_ctime` -timestamps, `st_uid`, `st_gid`, `st_ino`, and `st_size` members. -With a `USE_STDEV` compile-time option, `st_dev` is also -compared, but this is not enabled by default because this member -is not stable on network filesystems. With `USE_NSEC` -compile-time option, `st_mtim.tv_nsec` and `st_ctim.tv_nsec` -members are also compared. On Linux, this is not enabled by default -because in-core timestamps can have finer granularity than -on-disk timestamps, resulting in meaningless changes when an -inode is evicted from the inode cache. See commit 8ce13b0 -of git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git -([PATCH] Sync in core time granularity with filesystems, -2005-01-04). This patch is included in kernel 2.6.11 and newer, but -only fixes the issue for file systems with exactly 1 ns or 1 s -resolution. Other file systems are still broken in current Linux -kernels (e.g. CEPH, CIFS, NTFS, UDF), see -https://lkml.org/lkml/2015/6/9/714 - -Racy Git --------- - -There is one slight problem with the optimization based on the -cached stat information. Consider this sequence: - - : modify 'foo' - $ git update-index 'foo' - : modify 'foo' again, in-place, without changing its size - -The first `update-index` computes the object name of the -contents of file `foo` and updates the index entry for `foo` -along with the `struct stat` information. If the modification -that follows it happens very fast so that the file's `st_mtime` -timestamp does not change, after this sequence, the cached stat -information the index entry records still exactly match what you -would see in the filesystem, even though the file `foo` is now -different. -This way, Git can incorrectly think files in the working tree -are unmodified even though they actually are. This is called -the "racy Git" problem (discovered by Pasky), and the entries -that appear clean when they may not be because of this problem -are called "racily clean". - -To avoid this problem, Git does two things: - -. When the cached stat information says the file has not been - modified, and the `st_mtime` is the same as (or newer than) - the timestamp of the index file itself (which is the time `git - update-index foo` finished running in the above example), it - also compares the contents with the object registered in the - index entry to make sure they match. - -. When the index file is updated that contains racily clean - entries, cached `st_size` information is truncated to zero - before writing a new version of the index file. - -Because the index file itself is written after collecting all -the stat information from updated paths, `st_mtime` timestamp of -it is usually the same as or newer than any of the paths the -index contains. And no matter how quick the modification that -follows `git update-index foo` finishes, the resulting -`st_mtime` timestamp on `foo` cannot get a value earlier -than the index file. Therefore, index entries that can be -racily clean are limited to the ones that have the same -timestamp as the index file itself. - -The callers that want to check if an index entry matches the -corresponding file in the working tree continue to call -`ce_match_stat()`, but with this change, `ce_match_stat()` uses -`ce_modified_check_fs()` to see if racily clean ones are -actually clean after comparing the cached stat information using -`ce_match_stat_basic()`. - -The problem the latter solves is this sequence: - - $ git update-index 'foo' - : modify 'foo' in-place without changing its size - : wait for enough time - $ git update-index 'bar' - -Without the latter, the timestamp of the index file gets a newer -value, and falsely clean entry `foo` would not be caught by the -timestamp comparison check done with the former logic anymore. -The latter makes sure that the cached stat information for `foo` -would never match with the file in the working tree, so later -checks by `ce_match_stat_basic()` would report that the index entry -does not match the file and Git does not have to fall back on more -expensive `ce_modified_check_fs()`. - - -Runtime penalty ---------------- - -The runtime penalty of falling back to `ce_modified_check_fs()` -from `ce_match_stat()` can be very expensive when there are many -racily clean entries. An obvious way to artificially create -this situation is to give the same timestamp to all the files in -the working tree in a large project, run `git update-index` on -them, and give the same timestamp to the index file: - - $ date >.datestamp - $ git ls-files | xargs touch -r .datestamp - $ git ls-files | git update-index --stdin - $ touch -r .datestamp .git/index - -This will make all index entries racily clean. The linux project, for -example, there are over 20,000 files in the working tree. On my -Athlon 64 X2 3800+, after the above: - - $ /usr/bin/time git diff-files - 1.68user 0.54system 0:02.22elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k - 0inputs+0outputs (0major+67111minor)pagefaults 0swaps - $ git update-index MAINTAINERS - $ /usr/bin/time git diff-files - 0.02user 0.12system 0:00.14elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k - 0inputs+0outputs (0major+935minor)pagefaults 0swaps - -Running `git update-index` in the middle checked the racily -clean entries, and left the cached `st_mtime` for all the paths -intact because they were actually clean (so this step took about -the same amount of time as the first `git diff-files`). After -that, they are not racily clean anymore but are truly clean, so -the second invocation of `git diff-files` fully took advantage -of the cached stat information. - - -Avoiding runtime penalty ------------------------- - -In order to avoid the above runtime penalty, post 1.4.2 Git used -to have a code that made sure the index file -got timestamp newer than the youngest files in the index when -there are many young files with the same timestamp as the -resulting index file would otherwise would have by waiting -before finishing writing the index file out. - -I suspected that in practice the situation where many paths in the -index are all racily clean was quite rare. The only code paths -that can record recent timestamp for large number of paths are: - -. Initial `git add .` of a large project. - -. `git checkout` of a large project from an empty index into an - unpopulated working tree. - -Note: switching branches with `git checkout` keeps the cached -stat information of existing working tree files that are the -same between the current branch and the new branch, which are -all older than the resulting index file, and they will not -become racily clean. Only the files that are actually checked -out can become racily clean. - -In a large project where raciness avoidance cost really matters, -however, the initial computation of all object names in the -index takes more than one second, and the index file is written -out after all that happens. Therefore the timestamp of the -index file will be more than one seconds later than the -youngest file in the working tree. This means that in these -cases there actually will not be any racily clean entry in -the resulting index. - -Based on this discussion, the current code does not use the -"workaround" to avoid the runtime penalty that does not exist in -practice anymore. This was done with commit 0fc82cff on Aug 15, -2006. diff --git a/third_party/git/Documentation/technical/repository-version.txt b/third_party/git/Documentation/technical/repository-version.txt deleted file mode 100644 index 7844ef30ff..0000000000 --- a/third_party/git/Documentation/technical/repository-version.txt +++ /dev/null @@ -1,102 +0,0 @@ -== Git Repository Format Versions - -Every git repository is marked with a numeric version in the -`core.repositoryformatversion` key of its `config` file. This version -specifies the rules for operating on the on-disk repository data. An -implementation of git which does not understand a particular version -advertised by an on-disk repository MUST NOT operate on that repository; -doing so risks not only producing wrong results, but actually losing -data. - -Because of this rule, version bumps should be kept to an absolute -minimum. Instead, we generally prefer these strategies: - - - bumping format version numbers of individual data files (e.g., - index, packfiles, etc). This restricts the incompatibilities only to - those files. - - - introducing new data that gracefully degrades when used by older - clients (e.g., pack bitmap files are ignored by older clients, which - simply do not take advantage of the optimization they provide). - -A whole-repository format version bump should only be part of a change -that cannot be independently versioned. For instance, if one were to -change the reachability rules for objects, or the rules for locking -refs, that would require a bump of the repository format version. - -Note that this applies only to accessing the repository's disk contents -directly. An older client which understands only format `0` may still -connect via `git://` to a repository using format `1`, as long as the -server process understands format `1`. - -The preferred strategy for rolling out a version bump (whether whole -repository or for a single file) is to teach git to read the new format, -and allow writing the new format with a config switch or command line -option (for experimentation or for those who do not care about backwards -compatibility with older gits). Then after a long period to allow the -reading capability to become common, we may switch to writing the new -format by default. - -The currently defined format versions are: - -=== Version `0` - -This is the format defined by the initial version of git, including but -not limited to the format of the repository directory, the repository -configuration file, and the object and ref storage. Specifying the -complete behavior of git is beyond the scope of this document. - -=== Version `1` - -This format is identical to version `0`, with the following exceptions: - - 1. When reading the `core.repositoryformatversion` variable, a git - implementation which supports version 1 MUST also read any - configuration keys found in the `extensions` section of the - configuration file. - - 2. If a version-1 repository specifies any `extensions.*` keys that - the running git has not implemented, the operation MUST NOT - proceed. Similarly, if the value of any known key is not understood - by the implementation, the operation MUST NOT proceed. - -Note that if no extensions are specified in the config file, then -`core.repositoryformatversion` SHOULD be set to `0` (setting it to `1` -provides no benefit, and makes the repository incompatible with older -implementations of git). - -This document will serve as the master list for extensions. Any -implementation wishing to define a new extension should make a note of -it here, in order to claim the name. - -The defined extensions are: - -==== `noop` - -This extension does not change git's behavior at all. It is useful only -for testing format-1 compatibility. - -==== `preciousObjects` - -When the config key `extensions.preciousObjects` is set to `true`, -objects in the repository MUST NOT be deleted (e.g., by `git-prune` or -`git repack -d`). - -==== `partialclone` - -When the config key `extensions.partialclone` is set, it indicates -that the repo was created with a partial clone (or later performed -a partial fetch) and that the remote may have omitted sending -certain unwanted objects. Such a remote is called a "promisor remote" -and it promises that all such omitted objects can be fetched from it -in the future. - -The value of this key is the name of the promisor remote. - -==== `worktreeConfig` - -If set, by default "git config" reads from both "config" and -"config.worktree" file from GIT_DIR in that order. In -multiple working directory mode, "config" file is shared while -"config.worktree" is per-working directory (i.e., it's in -GIT_COMMON_DIR/worktrees/<id>/config.worktree) diff --git a/third_party/git/Documentation/technical/rerere.txt b/third_party/git/Documentation/technical/rerere.txt deleted file mode 100644 index aa22d7ace8..0000000000 --- a/third_party/git/Documentation/technical/rerere.txt +++ /dev/null @@ -1,186 +0,0 @@ -Rerere -====== - -This document describes the rerere logic. - -Conflict normalization ----------------------- - -To ensure recorded conflict resolutions can be looked up in the rerere -database, even when branches are merged in a different order, -different branches are merged that result in the same conflict, or -when different conflict style settings are used, rerere normalizes the -conflicts before writing them to the rerere database. - -Different conflict styles and branch names are normalized by stripping -the labels from the conflict markers, and removing the common ancestor -version from the `diff3` conflict style. Branches that are merged -in different order are normalized by sorting the conflict hunks. More -on each of those steps in the following sections. - -Once these two normalization operations are applied, a conflict ID is -calculated based on the normalized conflict, which is later used by -rerere to look up the conflict in the rerere database. - -Removing the common ancestor version -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Say we have three branches AB, AC and AC2. The common ancestor of -these branches has a file with a line containing the string "A" (for -brevity this is called "line A" in the rest of the document). In -branch AB this line is changed to "B", in AC, this line is changed to -"C", and branch AC2 is forked off of AC, after the line was changed to -"C". - -Forking a branch ABAC off of branch AB and then merging AC into it, we -get a conflict like the following: - - <<<<<<< HEAD - B - ======= - C - >>>>>>> AC - -Doing the analogous with AC2 (forking a branch ABAC2 off of branch AB -and then merging branch AC2 into it), using the diff3 conflict style, -we get a conflict like the following: - - <<<<<<< HEAD - B - ||||||| merged common ancestors - A - ======= - C - >>>>>>> AC2 - -By resolving this conflict, to leave line D, the user declares: - - After examining what branches AB and AC did, I believe that making - line A into line D is the best thing to do that is compatible with - what AB and AC wanted to do. - -As branch AC2 refers to the same commit as AC, the above implies that -this is also compatible what AB and AC2 wanted to do. - -By extension, this means that rerere should recognize that the above -conflicts are the same. To do this, the labels on the conflict -markers are stripped, and the common ancestor version is removed. The above -examples would both result in the following normalized conflict: - - <<<<<<< - B - ======= - C - >>>>>>> - -Sorting hunks -~~~~~~~~~~~~~ - -As before, lets imagine that a common ancestor had a file with line A -its early part, and line X in its late part. And then four branches -are forked that do these things: - - - AB: changes A to B - - AC: changes A to C - - XY: changes X to Y - - XZ: changes X to Z - -Now, forking a branch ABAC off of branch AB and then merging AC into -it, and forking a branch ACAB off of branch AC and then merging AB -into it, would yield the conflict in a different order. The former -would say "A became B or C, what now?" while the latter would say "A -became C or B, what now?" - -As a reminder, the act of merging AC into ABAC and resolving the -conflict to leave line D means that the user declares: - - After examining what branches AB and AC did, I believe that - making line A into line D is the best thing to do that is - compatible with what AB and AC wanted to do. - -So the conflict we would see when merging AB into ACAB should be -resolved the same way---it is the resolution that is in line with that -declaration. - -Imagine that similarly previously a branch XYXZ was forked from XY, -and XZ was merged into it, and resolved "X became Y or Z" into "X -became W". - -Now, if a branch ABXY was forked from AB and then merged XY, then ABXY -would have line B in its early part and line Y in its later part. -Such a merge would be quite clean. We can construct 4 combinations -using these four branches ((AB, AC) x (XY, XZ)). - -Merging ABXY and ACXZ would make "an early A became B or C, a late X -became Y or Z" conflict, while merging ACXY and ABXZ would make "an -early A became C or B, a late X became Y or Z". We can see there are -4 combinations of ("B or C", "C or B") x ("X or Y", "Y or X"). - -By sorting, the conflict is given its canonical name, namely, "an -early part became B or C, a late part becames X or Y", and whenever -any of these four patterns appear, and we can get to the same conflict -and resolution that we saw earlier. - -Without the sorting, we'd have to somehow find a previous resolution -from combinatorial explosion. - -Conflict ID calculation -~~~~~~~~~~~~~~~~~~~~~~~ - -Once the conflict normalization is done, the conflict ID is calculated -as the sha1 hash of the conflict hunks appended to each other, -separated by <NUL> characters. The conflict markers are stripped out -before the sha1 is calculated. So in the example above, where we -merge branch AC which changes line A to line C, into branch AB, which -changes line A to line C, the conflict ID would be -SHA1('B<NUL>C<NUL>'). - -If there are multiple conflicts in one file, the sha1 is calculated -the same way with all hunks appended to each other, in the order in -which they appear in the file, separated by a <NUL> character. - -Nested conflicts -~~~~~~~~~~~~~~~~ - -Nested conflicts are handled very similarly to "simple" conflicts. -Similar to simple conflicts, the conflict is first normalized by -stripping the labels from conflict markers, stripping the common ancestor -version, and the sorting the conflict hunks, both for the outer and the -inner conflict. This is done recursively, so any number of nested -conflicts can be handled. - -Note that this only works for conflict markers that "cleanly nest". If -there are any unmatched conflict markers, rerere will fail to handle -the conflict and record a conflict resolution. - -The only difference is in how the conflict ID is calculated. For the -inner conflict, the conflict markers themselves are not stripped out -before calculating the sha1. - -Say we have the following conflict for example: - - <<<<<<< HEAD - 1 - ======= - <<<<<<< HEAD - 3 - ======= - 2 - >>>>>>> branch-2 - >>>>>>> branch-3~ - -After stripping out the labels of the conflict markers, and sorting -the hunks, the conflict would look as follows: - - <<<<<<< - 1 - ======= - <<<<<<< - 2 - ======= - 3 - >>>>>>> - >>>>>>> - -and finally the conflict ID would be calculated as: -`sha1('1<NUL><<<<<<<\n3\n=======\n2\n>>>>>>><NUL>')` diff --git a/third_party/git/Documentation/technical/send-pack-pipeline.txt b/third_party/git/Documentation/technical/send-pack-pipeline.txt deleted file mode 100644 index 9b5a0bc186..0000000000 --- a/third_party/git/Documentation/technical/send-pack-pipeline.txt +++ /dev/null @@ -1,63 +0,0 @@ -Git-send-pack internals -======================= - -Overall operation ------------------ - -. Connects to the remote side and invokes git-receive-pack. - -. Learns what refs the remote has and what commit they point at. - Matches them to the refspecs we are pushing. - -. Checks if there are non-fast-forwards. Unlike fetch-pack, - the repository send-pack runs in is supposed to be a superset - of the recipient in fast-forward cases, so there is no need - for want/have exchanges, and fast-forward check can be done - locally. Tell the result to the other end. - -. Calls pack_objects() which generates a packfile and sends it - over to the other end. - -. If the remote side is new enough (v1.1.0 or later), wait for - the unpack and hook status from the other end. - -. Exit with appropriate error codes. - - -Pack_objects pipeline ---------------------- - -This function gets one file descriptor (`fd`) which is either a -socket (over the network) or a pipe (local). What's written to -this fd goes to git-receive-pack to be unpacked. - - send-pack ---> fd ---> receive-pack - -The function pack_objects creates a pipe and then forks. The -forked child execs pack-objects with --revs to receive revision -parameters from its standard input. This process will write the -packfile to the other end. - - send-pack - | - pack_objects() ---> fd ---> receive-pack - | ^ (pipe) - v | - (child) - -The child dup2's to arrange its standard output to go back to -the other end, and read its standard input to come from the -pipe. After that it exec's pack-objects. On the other hand, -the parent process, before starting to feed the child pipeline, -closes the reading side of the pipe and fd to receive-pack. - - send-pack - | - pack_objects(parent) - | - v [0] - pack-objects [0] ---> receive-pack - - -[jc: the pipeline was much more complex and needed documentation before - I understood an earlier bug, but now it is trivial and straightforward.] diff --git a/third_party/git/Documentation/technical/shallow.txt b/third_party/git/Documentation/technical/shallow.txt deleted file mode 100644 index 01dedfe9ff..0000000000 --- a/third_party/git/Documentation/technical/shallow.txt +++ /dev/null @@ -1,60 +0,0 @@ -Shallow commits -=============== - -.Definition -********************************************************* -Shallow commits do have parents, but not in the shallow -repo, and therefore grafts are introduced pretending that -these commits have no parents. -********************************************************* - -$GIT_DIR/shallow lists commit object names and tells Git to -pretend as if they are root commits (e.g. "git log" traversal -stops after showing them; "git fsck" does not complain saying -the commits listed on their "parent" lines do not exist). - -Each line contains exactly one SHA-1. When read, a commit_graft -will be constructed, which has nr_parent < 0 to make it easier -to discern from user provided grafts. - -Note that the shallow feature could not be changed easily to -use replace refs: a commit containing a `mergetag` is not allowed -to be replaced, not even by a root commit. Such a commit can be -made shallow, though. Also, having a `shallow` file explicitly -listing all the commits made shallow makes it a *lot* easier to -do shallow-specific things such as to deepen the history. - -Since fsck-objects relies on the library to read the objects, -it honours shallow commits automatically. - -There are some unfinished ends of the whole shallow business: - -- maybe we have to force non-thin packs when fetching into a - shallow repo (ATM they are forced non-thin). - -- A special handling of a shallow upstream is needed. At some - stage, upload-pack has to check if it sends a shallow commit, - and it should send that information early (or fail, if the - client does not support shallow repositories). There is no - support at all for this in this patch series. - -- Instead of locking $GIT_DIR/shallow at the start, just - the timestamp of it is noted, and when it comes to writing it, - a check is performed if the mtime is still the same, dying if - it is not. - -- It is unclear how "push into/from a shallow repo" should behave. - -- If you deepen a history, you'd want to get the tags of the - newly stored (but older!) commits. This does not work right now. - -To make a shallow clone, you can call "git-clone --depth 20 repo". -The result contains only commit chains with a length of at most 20. -It also writes an appropriate $GIT_DIR/shallow. - -You can deepen a shallow repository with "git-fetch --depth 20 -repo branch", which will fetch branch from repo, but stop at depth -20, updating $GIT_DIR/shallow. - -The special depth 2147483647 (or 0x7fffffff, the largest positive -number a signed 32-bit integer can contain) means infinite depth. diff --git a/third_party/git/Documentation/technical/signature-format.txt b/third_party/git/Documentation/technical/signature-format.txt deleted file mode 100644 index 2c9406a56a..0000000000 --- a/third_party/git/Documentation/technical/signature-format.txt +++ /dev/null @@ -1,186 +0,0 @@ -Git signature format -==================== - -== Overview - -Git uses cryptographic signatures in various places, currently objects (tags, -commits, mergetags) and transactions (pushes). In every case, the command which -is about to create an object or transaction determines a payload from that, -calls gpg to obtain a detached signature for the payload (`gpg -bsa`) and -embeds the signature into the object or transaction. - -Signatures always begin with `-----BEGIN PGP SIGNATURE-----` -and end with `-----END PGP SIGNATURE-----`, unless gpg is told to -produce RFC1991 signatures which use `MESSAGE` instead of `SIGNATURE`. - -The signed payload and the way the signature is embedded depends -on the type of the object resp. transaction. - -== Tag signatures - -- created by: `git tag -s` -- payload: annotated tag object -- embedding: append the signature to the unsigned tag object -- example: tag `signedtag` with subject `signed tag` - ----- -object 04b871796dc0420f8e7561a895b52484b701d51a -type commit -tag signedtag -tagger C O Mitter <committer@example.com> 1465981006 +0000 - -signed tag - -signed tag message body ------BEGIN PGP SIGNATURE----- -Version: GnuPG v1 - -iQEcBAABAgAGBQJXYRhOAAoJEGEJLoW3InGJklkIAIcnhL7RwEb/+QeX9enkXhxn -rxfdqrvWd1K80sl2TOt8Bg/NYwrUBw/RWJ+sg/hhHp4WtvE1HDGHlkEz3y11Lkuh -8tSxS3qKTxXUGozyPGuE90sJfExhZlW4knIQ1wt/yWqM+33E9pN4hzPqLwyrdods -q8FWEqPPUbSJXoMbRPw04S5jrLtZSsUWbRYjmJCHzlhSfFWW4eFd37uquIaLUBS0 -rkC3Jrx7420jkIpgFcTI2s60uhSQLzgcCwdA2ukSYIRnjg/zDkj8+3h/GaROJ72x -lZyI6HWixKJkWw8lE9aAOD9TmTW9sFJwcVAzmAuFX2kUreDUKMZduGcoRYGpD7E= -=jpXa ------END PGP SIGNATURE----- ----- - -- verify with: `git verify-tag [-v]` or `git tag -v` - ----- -gpg: Signature made Wed Jun 15 10:56:46 2016 CEST using RSA key ID B7227189 -gpg: Good signature from "Eris Discordia <discord@example.net>" -gpg: WARNING: This key is not certified with a trusted signature! -gpg: There is no indication that the signature belongs to the owner. -Primary key fingerprint: D4BE 2231 1AD3 131E 5EDA 29A4 6109 2E85 B722 7189 -object 04b871796dc0420f8e7561a895b52484b701d51a -type commit -tag signedtag -tagger C O Mitter <committer@example.com> 1465981006 +0000 - -signed tag - -signed tag message body ----- - -== Commit signatures - -- created by: `git commit -S` -- payload: commit object -- embedding: header entry `gpgsig` - (content is preceded by a space) -- example: commit with subject `signed commit` - ----- -tree eebfed94e75e7760540d1485c740902590a00332 -parent 04b871796dc0420f8e7561a895b52484b701d51a -author A U Thor <author@example.com> 1465981137 +0000 -committer C O Mitter <committer@example.com> 1465981137 +0000 -gpgsig -----BEGIN PGP SIGNATURE----- - Version: GnuPG v1 - - iQEcBAABAgAGBQJXYRjRAAoJEGEJLoW3InGJ3IwIAIY4SA6GxY3BjL60YyvsJPh/ - HRCJwH+w7wt3Yc/9/bW2F+gF72kdHOOs2jfv+OZhq0q4OAN6fvVSczISY/82LpS7 - DVdMQj2/YcHDT4xrDNBnXnviDO9G7am/9OE77kEbXrp7QPxvhjkicHNwy2rEflAA - zn075rtEERDHr8nRYiDh8eVrefSO7D+bdQ7gv+7GsYMsd2auJWi1dHOSfTr9HIF4 - HJhWXT9d2f8W+diRYXGh4X0wYiGg6na/soXc+vdtDYBzIxanRqjg8jCAeo1eOTk1 - EdTwhcTZlI0x5pvJ3H0+4hA2jtldVtmPM4OTB0cTrEWBad7XV6YgiyuII73Ve3I= - =jKHM - -----END PGP SIGNATURE----- - -signed commit - -signed commit message body ----- - -- verify with: `git verify-commit [-v]` (or `git show --show-signature`) - ----- -gpg: Signature made Wed Jun 15 10:58:57 2016 CEST using RSA key ID B7227189 -gpg: Good signature from "Eris Discordia <discord@example.net>" -gpg: WARNING: This key is not certified with a trusted signature! -gpg: There is no indication that the signature belongs to the owner. -Primary key fingerprint: D4BE 2231 1AD3 131E 5EDA 29A4 6109 2E85 B722 7189 -tree eebfed94e75e7760540d1485c740902590a00332 -parent 04b871796dc0420f8e7561a895b52484b701d51a -author A U Thor <author@example.com> 1465981137 +0000 -committer C O Mitter <committer@example.com> 1465981137 +0000 - -signed commit - -signed commit message body ----- - -== Mergetag signatures - -- created by: `git merge` on signed tag -- payload/embedding: the whole signed tag object is embedded into - the (merge) commit object as header entry `mergetag` -- example: merge of the signed tag `signedtag` as above - ----- -tree c7b1cff039a93f3600a1d18b82d26688668c7dea -parent c33429be94b5f2d3ee9b0adad223f877f174b05d -parent 04b871796dc0420f8e7561a895b52484b701d51a -author A U Thor <author@example.com> 1465982009 +0000 -committer C O Mitter <committer@example.com> 1465982009 +0000 -mergetag object 04b871796dc0420f8e7561a895b52484b701d51a - type commit - tag signedtag - tagger C O Mitter <committer@example.com> 1465981006 +0000 - - signed tag - - signed tag message body - -----BEGIN PGP SIGNATURE----- - Version: GnuPG v1 - - iQEcBAABAgAGBQJXYRhOAAoJEGEJLoW3InGJklkIAIcnhL7RwEb/+QeX9enkXhxn - rxfdqrvWd1K80sl2TOt8Bg/NYwrUBw/RWJ+sg/hhHp4WtvE1HDGHlkEz3y11Lkuh - 8tSxS3qKTxXUGozyPGuE90sJfExhZlW4knIQ1wt/yWqM+33E9pN4hzPqLwyrdods - q8FWEqPPUbSJXoMbRPw04S5jrLtZSsUWbRYjmJCHzlhSfFWW4eFd37uquIaLUBS0 - rkC3Jrx7420jkIpgFcTI2s60uhSQLzgcCwdA2ukSYIRnjg/zDkj8+3h/GaROJ72x - lZyI6HWixKJkWw8lE9aAOD9TmTW9sFJwcVAzmAuFX2kUreDUKMZduGcoRYGpD7E= - =jpXa - -----END PGP SIGNATURE----- - -Merge tag 'signedtag' into downstream - -signed tag - -signed tag message body - -# gpg: Signature made Wed Jun 15 08:56:46 2016 UTC using RSA key ID B7227189 -# gpg: Good signature from "Eris Discordia <discord@example.net>" -# gpg: WARNING: This key is not certified with a trusted signature! -# gpg: There is no indication that the signature belongs to the owner. -# Primary key fingerprint: D4BE 2231 1AD3 131E 5EDA 29A4 6109 2E85 B722 7189 ----- - -- verify with: verification is embedded in merge commit message by default, - alternatively with `git show --show-signature`: - ----- -commit 9863f0c76ff78712b6800e199a46aa56afbcbd49 -merged tag 'signedtag' -gpg: Signature made Wed Jun 15 10:56:46 2016 CEST using RSA key ID B7227189 -gpg: Good signature from "Eris Discordia <discord@example.net>" -gpg: WARNING: This key is not certified with a trusted signature! -gpg: There is no indication that the signature belongs to the owner. -Primary key fingerprint: D4BE 2231 1AD3 131E 5EDA 29A4 6109 2E85 B722 7189 -Merge: c33429b 04b8717 -Author: A U Thor <author@example.com> -Date: Wed Jun 15 09:13:29 2016 +0000 - - Merge tag 'signedtag' into downstream - - signed tag - - signed tag message body - - # gpg: Signature made Wed Jun 15 08:56:46 2016 UTC using RSA key ID B7227189 - # gpg: Good signature from "Eris Discordia <discord@example.net>" - # gpg: WARNING: This key is not certified with a trusted signature! - # gpg: There is no indication that the signature belongs to the owner. - # Primary key fingerprint: D4BE 2231 1AD3 131E 5EDA 29A4 6109 2E85 B722 7189 ----- diff --git a/third_party/git/Documentation/technical/trivial-merge.txt b/third_party/git/Documentation/technical/trivial-merge.txt deleted file mode 100644 index 1f1c33d0da..0000000000 --- a/third_party/git/Documentation/technical/trivial-merge.txt +++ /dev/null @@ -1,121 +0,0 @@ -Trivial merge rules -=================== - -This document describes the outcomes of the trivial merge logic in read-tree. - -One-way merge -------------- - -This replaces the index with a different tree, keeping the stat info -for entries that don't change, and allowing -u to make the minimum -required changes to the working tree to have it match. - -Entries marked '+' have stat information. Spaces marked '*' don't -affect the result. - - index tree result - ----------------------- - * (empty) (empty) - (empty) tree tree - index+ tree tree - index+ index index+ - -Two-way merge -------------- - -It is permitted for the index to lack an entry; this does not prevent -any case from applying. - -If the index exists, it is an error for it not to match either the old -or the result. - -If multiple cases apply, the one used is listed first. - -A result which changes the index is an error if the index is not empty -and not up to date. - -Entries marked '+' have stat information. Spaces marked '*' don't -affect the result. - - case index old new result - ------------------------------------- - 0/2 (empty) * (empty) (empty) - 1/3 (empty) * new new - 4/5 index+ (empty) (empty) index+ - 6/7 index+ (empty) index index+ - 10 index+ index (empty) (empty) - 14/15 index+ old old index+ - 18/19 index+ old index index+ - 20 index+ index new new - -Three-way merge ---------------- - -It is permitted for the index to lack an entry; this does not prevent -any case from applying. - -If the index exists, it is an error for it not to match either the -head or (if the merge is trivial) the result. - -If multiple cases apply, the one used is listed first. - -A result of "no merge" means that index is left in stage 0, ancest in -stage 1, head in stage 2, and remote in stage 3 (if any of these are -empty, no entry is left for that stage). Otherwise, the given entry is -left in stage 0, and there are no other entries. - -A result of "no merge" is an error if the index is not empty and not -up to date. - -*empty* means that the tree must not have a directory-file conflict - with the entry. - -For multiple ancestors, a '+' means that this case applies even if -only one ancestor or remote fits; a '^' means all of the ancestors -must be the same. - - case ancest head remote result - ---------------------------------------- - 1 (empty)+ (empty) (empty) (empty) - 2ALT (empty)+ *empty* remote remote - 2 (empty)^ (empty) remote no merge - 3ALT (empty)+ head *empty* head - 3 (empty)^ head (empty) no merge - 4 (empty)^ head remote no merge - 5ALT * head head head - 6 ancest+ (empty) (empty) no merge - 8 ancest^ (empty) ancest no merge - 7 ancest+ (empty) remote no merge - 10 ancest^ ancest (empty) no merge - 9 ancest+ head (empty) no merge - 16 anc1/anc2 anc1 anc2 no merge - 13 ancest+ head ancest head - 14 ancest+ ancest remote remote - 11 ancest+ head remote no merge - -Only #2ALT and #3ALT use *empty*, because these are the only cases -where there can be conflicts that didn't exist before. Note that we -allow directory-file conflicts between things in different stages -after the trivial merge. - -A possible alternative for #6 is (empty), which would make it like -#1. This is not used, due to the likelihood that it arises due to -moving the file to multiple different locations or moving and deleting -it in different branches. - -Case #1 is included for completeness, and also in case we decide to -put on '+' markings; any path that is never mentioned at all isn't -handled. - -Note that #16 is when both #13 and #14 apply; in this case, we refuse -the trivial merge, because we can't tell from this data which is -right. This is a case of a reverted patch (in some direction, maybe -multiple times), and the right answer depends on looking at crossings -of history or common ancestors of the ancestors. - -Note that, between #6, #7, #9, and #11, all cases not otherwise -covered are handled in this table. - -For #8 and #10, there is alternative behavior, not currently -implemented, where the result is (empty). As currently implemented, -the automatic merge will generally give this effect. diff --git a/third_party/git/Documentation/texi.xsl b/third_party/git/Documentation/texi.xsl deleted file mode 100644 index 0f8ff07eca..0000000000 --- a/third_party/git/Documentation/texi.xsl +++ /dev/null @@ -1,26 +0,0 @@ -<!-- texi.xsl: - convert refsection elements into refsect elements that docbook2texi can - understand --> -<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" - version="1.0"> - -<xsl:output method="xml" - encoding="UTF-8" - doctype-public="-//OASIS//DTD DocBook XML V4.5//EN" - doctype-system="http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" /> - -<xsl:template match="//refsection"> - <xsl:variable name="element">refsect<xsl:value-of select="count(ancestor-or-self::refsection)" /></xsl:variable> - <xsl:element name="{$element}"> - <xsl:apply-templates select="@*|node()" /> - </xsl:element> -</xsl:template> - -<!-- Copy all other nodes through. --> -<xsl:template match="node()|@*"> - <xsl:copy> - <xsl:apply-templates select="@*|node()" /> - </xsl:copy> -</xsl:template> - -</xsl:stylesheet> diff --git a/third_party/git/Documentation/trace2-target-values.txt b/third_party/git/Documentation/trace2-target-values.txt deleted file mode 100644 index 27d3c64e66..0000000000 --- a/third_party/git/Documentation/trace2-target-values.txt +++ /dev/null @@ -1,10 +0,0 @@ --- -* `0` or `false` - Disables the target. -* `1` or `true` - Writes to `STDERR`. -* `[2-9]` - Writes to the already opened file descriptor. -* `<absolute-pathname>` - Writes to the file in append mode. -* `af_unix:[<socket_type>:]<absolute-pathname>` - Write to a -Unix DomainSocket (on platforms that support them). Socket -type can be either `stream` or `dgram`; if omitted Git will -try both. --- diff --git a/third_party/git/Documentation/transfer-data-leaks.txt b/third_party/git/Documentation/transfer-data-leaks.txt deleted file mode 100644 index 914bacc39e..0000000000 --- a/third_party/git/Documentation/transfer-data-leaks.txt +++ /dev/null @@ -1,30 +0,0 @@ -SECURITY --------- -The fetch and push protocols are not designed to prevent one side from -stealing data from the other repository that was not intended to be -shared. If you have private data that you need to protect from a malicious -peer, your best option is to store it in another repository. This applies -to both clients and servers. In particular, namespaces on a server are not -effective for read access control; you should only grant read access to a -namespace to clients that you would trust with read access to the entire -repository. - -The known attack vectors are as follows: - -. The victim sends "have" lines advertising the IDs of objects it has that - are not explicitly intended to be shared but can be used to optimize the - transfer if the peer also has them. The attacker chooses an object ID X - to steal and sends a ref to X, but isn't required to send the content of - X because the victim already has it. Now the victim believes that the - attacker has X, and it sends the content of X back to the attacker - later. (This attack is most straightforward for a client to perform on a - server, by creating a ref to X in the namespace the client has access - to and then fetching it. The most likely way for a server to perform it - on a client is to "merge" X into a public branch and hope that the user - does additional work on this branch and pushes it back to the server - without noticing the merge.) - -. As in #1, the attacker chooses an object ID X to steal. The victim sends - an object Y that the attacker already has, and the attacker falsely - claims to have X and not Y, so the victim sends Y as a delta against X. - The delta reveals regions of X that are similar to Y to the attacker. diff --git a/third_party/git/Documentation/urls-remotes.txt b/third_party/git/Documentation/urls-remotes.txt deleted file mode 100644 index bd184cd653..0000000000 --- a/third_party/git/Documentation/urls-remotes.txt +++ /dev/null @@ -1,94 +0,0 @@ -include::urls.txt[] - -REMOTES[[REMOTES]] ------------------- - -The name of one of the following can be used instead -of a URL as `<repository>` argument: - -* a remote in the Git configuration file: `$GIT_DIR/config`, -* a file in the `$GIT_DIR/remotes` directory, or -* a file in the `$GIT_DIR/branches` directory. - -All of these also allow you to omit the refspec from the command line -because they each contain a refspec which git will use by default. - -Named remote in configuration file -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You can choose to provide the name of a remote which you had previously -configured using linkgit:git-remote[1], linkgit:git-config[1] -or even by a manual edit to the `$GIT_DIR/config` file. The URL of -this remote will be used to access the repository. The refspec -of this remote will be used by default when you do -not provide a refspec on the command line. The entry in the -config file would appear like this: - ------------- - [remote "<name>"] - url = <url> - pushurl = <pushurl> - push = <refspec> - fetch = <refspec> ------------- - -The `<pushurl>` is used for pushes only. It is optional and defaults -to `<url>`. - -Named file in `$GIT_DIR/remotes` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You can choose to provide the name of a -file in `$GIT_DIR/remotes`. The URL -in this file will be used to access the repository. The refspec -in this file will be used as default when you do not -provide a refspec on the command line. This file should have the -following format: - ------------- - URL: one of the above URL format - Push: <refspec> - Pull: <refspec> - ------------- - -`Push:` lines are used by 'git push' and -`Pull:` lines are used by 'git pull' and 'git fetch'. -Multiple `Push:` and `Pull:` lines may -be specified for additional branch mappings. - -Named file in `$GIT_DIR/branches` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You can choose to provide the name of a -file in `$GIT_DIR/branches`. -The URL in this file will be used to access the repository. -This file should have the following format: - - ------------- - <url>#<head> ------------- - -`<url>` is required; `#<head>` is optional. - -Depending on the operation, git will use one of the following -refspecs, if you don't provide one on the command line. -`<branch>` is the name of this file in `$GIT_DIR/branches` and -`<head>` defaults to `master`. - -git fetch uses: - ------------- - refs/heads/<head>:refs/heads/<branch> ------------- - -git push uses: - ------------- - HEAD:refs/heads/<head> ------------- - - - - diff --git a/third_party/git/Documentation/urls.txt b/third_party/git/Documentation/urls.txt deleted file mode 100644 index bc354fe2dc..0000000000 --- a/third_party/git/Documentation/urls.txt +++ /dev/null @@ -1,105 +0,0 @@ -GIT URLS[[URLS]] ----------------- - -In general, URLs contain information about the transport protocol, the -address of the remote server, and the path to the repository. -Depending on the transport protocol, some of this information may be -absent. - -Git supports ssh, git, http, and https protocols (in addition, ftp, -and ftps can be used for fetching, but this is inefficient and -deprecated; do not use it). - -The native transport (i.e. git:// URL) does no authentication and -should be used with caution on unsecured networks. - -The following syntaxes may be used with them: - -- ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/path/to/repo.git/ -- git://host.xz{startsb}:port{endsb}/path/to/repo.git/ -- http{startsb}s{endsb}://host.xz{startsb}:port{endsb}/path/to/repo.git/ -- ftp{startsb}s{endsb}://host.xz{startsb}:port{endsb}/path/to/repo.git/ - -An alternative scp-like syntax may also be used with the ssh protocol: - -- {startsb}user@{endsb}host.xz:path/to/repo.git/ - -This syntax is only recognized if there are no slashes before the -first colon. This helps differentiate a local path that contains a -colon. For example the local path `foo:bar` could be specified as an -absolute path or `./foo:bar` to avoid being misinterpreted as an ssh -url. - -The ssh and git protocols additionally support ~username expansion: - -- ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/~{startsb}user{endsb}/path/to/repo.git/ -- git://host.xz{startsb}:port{endsb}/~{startsb}user{endsb}/path/to/repo.git/ -- {startsb}user@{endsb}host.xz:/~{startsb}user{endsb}/path/to/repo.git/ - -For local repositories, also supported by Git natively, the following -syntaxes may be used: - -- /path/to/repo.git/ -- \file:///path/to/repo.git/ - -ifndef::git-clone[] -These two syntaxes are mostly equivalent, except when cloning, when -the former implies --local option. See linkgit:git-clone[1] for -details. -endif::git-clone[] - -ifdef::git-clone[] -These two syntaxes are mostly equivalent, except the former implies ---local option. -endif::git-clone[] - -When Git doesn't know how to handle a certain transport protocol, it -attempts to use the 'remote-<transport>' remote helper, if one -exists. To explicitly request a remote helper, the following syntax -may be used: - -- <transport>::<address> - -where <address> may be a path, a server and path, or an arbitrary -URL-like string recognized by the specific remote helper being -invoked. See linkgit:gitremote-helpers[7] for details. - -If there are a large number of similarly-named remote repositories and -you want to use a different format for them (such that the URLs you -use will be rewritten into URLs that work), you can create a -configuration section of the form: - ------------- - [url "<actual url base>"] - insteadOf = <other url base> ------------- - -For example, with this: - ------------- - [url "git://git.host.xz/"] - insteadOf = host.xz:/path/to/ - insteadOf = work: ------------- - -a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be -rewritten in any context that takes a URL to be "git://git.host.xz/repo.git". - -If you want to rewrite URLs for push only, you can create a -configuration section of the form: - ------------- - [url "<actual url base>"] - pushInsteadOf = <other url base> ------------- - -For example, with this: - ------------- - [url "ssh://example.org/"] - pushInsteadOf = git://example.org/ ------------- - -a URL like "git://example.org/path/to/repo.git" will be rewritten to -"ssh://example.org/path/to/repo.git" for pushes, but pulls will still -use the original URL. diff --git a/third_party/git/Documentation/user-manual.conf b/third_party/git/Documentation/user-manual.conf deleted file mode 100644 index d87294de2f..0000000000 --- a/third_party/git/Documentation/user-manual.conf +++ /dev/null @@ -1,21 +0,0 @@ -[titles] - underlines="__","==","--","~~","^^" - -[attributes] -caret=^ -startsb=[ -endsb=] -tilde=~ - -[linkgit-inlinemacro] -<ulink url="{target}.html">{target}{0?({0})}</ulink> - -ifdef::backend-docbook[] -# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this. -[listingblock] -<example><title>{title}</title> -<literallayout class="monospaced"> -| -</literallayout> -{title#}</example> -endif::backend-docbook[] diff --git a/third_party/git/Documentation/user-manual.txt b/third_party/git/Documentation/user-manual.txt deleted file mode 100644 index 8bce75b2cf..0000000000 --- a/third_party/git/Documentation/user-manual.txt +++ /dev/null @@ -1,4691 +0,0 @@ -Git User Manual -=============== - -Git is a fast distributed revision control system. - -This manual is designed to be readable by someone with basic UNIX -command-line skills, but no previous knowledge of Git. - -<<repositories-and-branches>> and <<exploring-git-history>> explain how -to fetch and study a project using git--read these chapters to learn how -to build and test a particular version of a software project, search for -regressions, and so on. - -People needing to do actual development will also want to read -<<Developing-With-git>> and <<sharing-development>>. - -Further chapters cover more specialized topics. - -Comprehensive reference documentation is available through the man -pages, or linkgit:git-help[1] command. For example, for the command -`git clone <repo>`, you can either use: - ------------------------------------------------- -$ man git-clone ------------------------------------------------- - -or: - ------------------------------------------------- -$ git help clone ------------------------------------------------- - -With the latter, you can use the manual viewer of your choice; see -linkgit:git-help[1] for more information. - -See also <<git-quick-start>> for a brief overview of Git commands, -without any explanation. - -Finally, see <<todo>> for ways that you can help make this manual more -complete. - - -[[repositories-and-branches]] -Repositories and Branches -========================= - -[[how-to-get-a-git-repository]] -How to get a Git repository ---------------------------- - -It will be useful to have a Git repository to experiment with as you -read this manual. - -The best way to get one is by using the linkgit:git-clone[1] command to -download a copy of an existing repository. If you don't already have a -project in mind, here are some interesting examples: - ------------------------------------------------- - # Git itself (approx. 40MB download): -$ git clone git://git.kernel.org/pub/scm/git/git.git - # the Linux kernel (approx. 640MB download): -$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ------------------------------------------------- - -The initial clone may be time-consuming for a large project, but you -will only need to clone once. - -The clone command creates a new directory named after the project -(`git` or `linux` in the examples above). After you cd into this -directory, you will see that it contains a copy of the project files, -called the <<def_working_tree,working tree>>, together with a special -top-level directory named `.git`, which contains all the information -about the history of the project. - -[[how-to-check-out]] -How to check out a different version of a project -------------------------------------------------- - -Git is best thought of as a tool for storing the history of a collection -of files. It stores the history as a compressed collection of -interrelated snapshots of the project's contents. In Git each such -version is called a <<def_commit,commit>>. - -Those snapshots aren't necessarily all arranged in a single line from -oldest to newest; instead, work may simultaneously proceed along -parallel lines of development, called <<def_branch,branches>>, which may -merge and diverge. - -A single Git repository can track development on multiple branches. It -does this by keeping a list of <<def_head,heads>> which reference the -latest commit on each branch; the linkgit:git-branch[1] command shows -you the list of branch heads: - ------------------------------------------------- -$ git branch -* master ------------------------------------------------- - -A freshly cloned repository contains a single branch head, by default -named "master", with the working directory initialized to the state of -the project referred to by that branch head. - -Most projects also use <<def_tag,tags>>. Tags, like heads, are -references into the project's history, and can be listed using the -linkgit:git-tag[1] command: - ------------------------------------------------- -$ git tag -l -v2.6.11 -v2.6.11-tree -v2.6.12 -v2.6.12-rc2 -v2.6.12-rc3 -v2.6.12-rc4 -v2.6.12-rc5 -v2.6.12-rc6 -v2.6.13 -... ------------------------------------------------- - -Tags are expected to always point at the same version of a project, -while heads are expected to advance as development progresses. - -Create a new branch head pointing to one of these versions and check it -out using linkgit:git-switch[1]: - ------------------------------------------------- -$ git switch -c new v2.6.13 ------------------------------------------------- - -The working directory then reflects the contents that the project had -when it was tagged v2.6.13, and linkgit:git-branch[1] shows two -branches, with an asterisk marking the currently checked-out branch: - ------------------------------------------------- -$ git branch - master -* new ------------------------------------------------- - -If you decide that you'd rather see version 2.6.17, you can modify -the current branch to point at v2.6.17 instead, with - ------------------------------------------------- -$ git reset --hard v2.6.17 ------------------------------------------------- - -Note that if the current branch head was your only reference to a -particular point in history, then resetting that branch may leave you -with no way to find the history it used to point to; so use this command -carefully. - -[[understanding-commits]] -Understanding History: Commits ------------------------------- - -Every change in the history of a project is represented by a commit. -The linkgit:git-show[1] command shows the most recent commit on the -current branch: - ------------------------------------------------- -$ git show -commit 17cf781661e6d38f737f15f53ab552f1e95960d7 -Author: Linus Torvalds <torvalds@ppc970.osdl.org.(none)> -Date: Tue Apr 19 14:11:06 2005 -0700 - - Remove duplicate getenv(DB_ENVIRONMENT) call - - Noted by Tony Luck. - -diff --git a/init-db.c b/init-db.c -index 65898fa..b002dc6 100644 ---- a/init-db.c -+++ b/init-db.c -@@ -7,7 +7,7 @@ - - int main(int argc, char **argv) - { -- char *sha1_dir = getenv(DB_ENVIRONMENT), *path; -+ char *sha1_dir, *path; - int len, i; - - if (mkdir(".git", 0755) < 0) { ------------------------------------------------- - -As you can see, a commit shows who made the latest change, what they -did, and why. - -Every commit has a 40-hexdigit id, sometimes called the "object name" or the -"SHA-1 id", shown on the first line of the `git show` output. You can usually -refer to a commit by a shorter name, such as a tag or a branch name, but this -longer name can also be useful. Most importantly, it is a globally unique -name for this commit: so if you tell somebody else the object name (for -example in email), then you are guaranteed that name will refer to the same -commit in their repository that it does in yours (assuming their repository -has that commit at all). Since the object name is computed as a hash over the -contents of the commit, you are guaranteed that the commit can never change -without its name also changing. - -In fact, in <<git-concepts>> we shall see that everything stored in Git -history, including file data and directory contents, is stored in an object -with a name that is a hash of its contents. - -[[understanding-reachability]] -Understanding history: commits, parents, and reachability -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Every commit (except the very first commit in a project) also has a -parent commit which shows what happened before this commit. -Following the chain of parents will eventually take you back to the -beginning of the project. - -However, the commits do not form a simple list; Git allows lines of -development to diverge and then reconverge, and the point where two -lines of development reconverge is called a "merge". The commit -representing a merge can therefore have more than one parent, with -each parent representing the most recent commit on one of the lines -of development leading to that point. - -The best way to see how this works is using the linkgit:gitk[1] -command; running gitk now on a Git repository and looking for merge -commits will help understand how Git organizes history. - -In the following, we say that commit X is "reachable" from commit Y -if commit X is an ancestor of commit Y. Equivalently, you could say -that Y is a descendant of X, or that there is a chain of parents -leading from commit Y to commit X. - -[[history-diagrams]] -Understanding history: History diagrams -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -We will sometimes represent Git history using diagrams like the one -below. Commits are shown as "o", and the links between them with -lines drawn with - / and \. Time goes left to right: - - -................................................ - o--o--o <-- Branch A - / - o--o--o <-- master - \ - o--o--o <-- Branch B -................................................ - -If we need to talk about a particular commit, the character "o" may -be replaced with another letter or number. - -[[what-is-a-branch]] -Understanding history: What is a branch? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -When we need to be precise, we will use the word "branch" to mean a line -of development, and "branch head" (or just "head") to mean a reference -to the most recent commit on a branch. In the example above, the branch -head named "A" is a pointer to one particular commit, but we refer to -the line of three commits leading up to that point as all being part of -"branch A". - -However, when no confusion will result, we often just use the term -"branch" both for branches and for branch heads. - -[[manipulating-branches]] -Manipulating branches ---------------------- - -Creating, deleting, and modifying branches is quick and easy; here's -a summary of the commands: - -`git branch`:: - list all branches. -`git branch <branch>`:: - create a new branch named `<branch>`, referencing the same - point in history as the current branch. -`git branch <branch> <start-point>`:: - create a new branch named `<branch>`, referencing - `<start-point>`, which may be specified any way you like, - including using a branch name or a tag name. -`git branch -d <branch>`:: - delete the branch `<branch>`; if the branch is not fully - merged in its upstream branch or contained in the current branch, - this command will fail with a warning. -`git branch -D <branch>`:: - delete the branch `<branch>` irrespective of its merged status. -`git switch <branch>`:: - make the current branch `<branch>`, updating the working - directory to reflect the version referenced by `<branch>`. -`git switch -c <new> <start-point>`:: - create a new branch `<new>` referencing `<start-point>`, and - check it out. - -The special symbol "HEAD" can always be used to refer to the current -branch. In fact, Git uses a file named `HEAD` in the `.git` directory -to remember which branch is current: - ------------------------------------------------- -$ cat .git/HEAD -ref: refs/heads/master ------------------------------------------------- - -[[detached-head]] -Examining an old version without creating a new branch ------------------------------------------------------- - -The `git switch` command normally expects a branch head, but will also -accept an arbitrary commit when invoked with --detach; for example, -you can check out the commit referenced by a tag: - ------------------------------------------------- -$ git switch --detach v2.6.17 -Note: checking out 'v2.6.17'. - -You are in 'detached HEAD' state. You can look around, make experimental -changes and commit them, and you can discard any commits you make in this -state without impacting any branches by performing another switch. - -If you want to create a new branch to retain commits you create, you may -do so (now or later) by using -c with the switch command again. Example: - - git switch -c new_branch_name - -HEAD is now at 427abfa Linux v2.6.17 ------------------------------------------------- - -The HEAD then refers to the SHA-1 of the commit instead of to a branch, -and git branch shows that you are no longer on a branch: - ------------------------------------------------- -$ cat .git/HEAD -427abfa28afedffadfca9dd8b067eb6d36bac53f -$ git branch -* (detached from v2.6.17) - master ------------------------------------------------- - -In this case we say that the HEAD is "detached". - -This is an easy way to check out a particular version without having to -make up a name for the new branch. You can still create a new branch -(or tag) for this version later if you decide to. - -[[examining-remote-branches]] -Examining branches from a remote repository -------------------------------------------- - -The "master" branch that was created at the time you cloned is a copy -of the HEAD in the repository that you cloned from. That repository -may also have had other branches, though, and your local repository -keeps branches which track each of those remote branches, called -remote-tracking branches, which you -can view using the `-r` option to linkgit:git-branch[1]: - ------------------------------------------------- -$ git branch -r - origin/HEAD - origin/html - origin/maint - origin/man - origin/master - origin/next - origin/pu - origin/todo ------------------------------------------------- - -In this example, "origin" is called a remote repository, or "remote" -for short. The branches of this repository are called "remote -branches" from our point of view. The remote-tracking branches listed -above were created based on the remote branches at clone time and will -be updated by `git fetch` (hence `git pull`) and `git push`. See -<<Updating-a-repository-With-git-fetch>> for details. - -You might want to build on one of these remote-tracking branches -on a branch of your own, just as you would for a tag: - ------------------------------------------------- -$ git switch -c my-todo-copy origin/todo ------------------------------------------------- - -You can also check out `origin/todo` directly to examine it or -write a one-off patch. See <<detached-head,detached head>>. - -Note that the name "origin" is just the name that Git uses by default -to refer to the repository that you cloned from. - -[[how-git-stores-references]] -Naming branches, tags, and other references -------------------------------------------- - -Branches, remote-tracking branches, and tags are all references to -commits. All references are named with a slash-separated path name -starting with `refs`; the names we've been using so far are actually -shorthand: - - - The branch `test` is short for `refs/heads/test`. - - The tag `v2.6.18` is short for `refs/tags/v2.6.18`. - - `origin/master` is short for `refs/remotes/origin/master`. - -The full name is occasionally useful if, for example, there ever -exists a tag and a branch with the same name. - -(Newly created refs are actually stored in the `.git/refs` directory, -under the path given by their name. However, for efficiency reasons -they may also be packed together in a single file; see -linkgit:git-pack-refs[1]). - -As another useful shortcut, the "HEAD" of a repository can be referred -to just using the name of that repository. So, for example, "origin" -is usually a shortcut for the HEAD branch in the repository "origin". - -For the complete list of paths which Git checks for references, and -the order it uses to decide which to choose when there are multiple -references with the same shorthand name, see the "SPECIFYING -REVISIONS" section of linkgit:gitrevisions[7]. - -[[Updating-a-repository-With-git-fetch]] -Updating a repository with git fetch ------------------------------------- - -After you clone a repository and commit a few changes of your own, you -may wish to check the original repository for updates. - -The `git-fetch` command, with no arguments, will update all of the -remote-tracking branches to the latest version found in the original -repository. It will not touch any of your own branches--not even the -"master" branch that was created for you on clone. - -[[fetching-branches]] -Fetching branches from other repositories ------------------------------------------ - -You can also track branches from repositories other than the one you -cloned from, using linkgit:git-remote[1]: - -------------------------------------------------- -$ git remote add staging git://git.kernel.org/.../gregkh/staging.git -$ git fetch staging -... -From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging - * [new branch] master -> staging/master - * [new branch] staging-linus -> staging/staging-linus - * [new branch] staging-next -> staging/staging-next -------------------------------------------------- - -New remote-tracking branches will be stored under the shorthand name -that you gave `git remote add`, in this case `staging`: - -------------------------------------------------- -$ git branch -r - origin/HEAD -> origin/master - origin/master - staging/master - staging/staging-linus - staging/staging-next -------------------------------------------------- - -If you run `git fetch <remote>` later, the remote-tracking branches -for the named `<remote>` will be updated. - -If you examine the file `.git/config`, you will see that Git has added -a new stanza: - -------------------------------------------------- -$ cat .git/config -... -[remote "staging"] - url = git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git - fetch = +refs/heads/*:refs/remotes/staging/* -... -------------------------------------------------- - -This is what causes Git to track the remote's branches; you may modify -or delete these configuration options by editing `.git/config` with a -text editor. (See the "CONFIGURATION FILE" section of -linkgit:git-config[1] for details.) - -[[exploring-git-history]] -Exploring Git history -===================== - -Git is best thought of as a tool for storing the history of a -collection of files. It does this by storing compressed snapshots of -the contents of a file hierarchy, together with "commits" which show -the relationships between these snapshots. - -Git provides extremely flexible and fast tools for exploring the -history of a project. - -We start with one specialized tool that is useful for finding the -commit that introduced a bug into a project. - -[[using-bisect]] -How to use bisect to find a regression --------------------------------------- - -Suppose version 2.6.18 of your project worked, but the version at -"master" crashes. Sometimes the best way to find the cause of such a -regression is to perform a brute-force search through the project's -history to find the particular commit that caused the problem. The -linkgit:git-bisect[1] command can help you do this: - -------------------------------------------------- -$ git bisect start -$ git bisect good v2.6.18 -$ git bisect bad master -Bisecting: 3537 revisions left to test after this -[65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6] -------------------------------------------------- - -If you run `git branch` at this point, you'll see that Git has -temporarily moved you in "(no branch)". HEAD is now detached from any -branch and points directly to a commit (with commit id 65934) that -is reachable from "master" but not from v2.6.18. Compile and test it, -and see whether it crashes. Assume it does crash. Then: - -------------------------------------------------- -$ git bisect bad -Bisecting: 1769 revisions left to test after this -[7eff82c8b1511017ae605f0c99ac275a7e21b867] i2c-core: Drop useless bitmaskings -------------------------------------------------- - -checks out an older version. Continue like this, telling Git at each -stage whether the version it gives you is good or bad, and notice -that the number of revisions left to test is cut approximately in -half each time. - -After about 13 tests (in this case), it will output the commit id of -the guilty commit. You can then examine the commit with -linkgit:git-show[1], find out who wrote it, and mail them your bug -report with the commit id. Finally, run - -------------------------------------------------- -$ git bisect reset -------------------------------------------------- - -to return you to the branch you were on before. - -Note that the version which `git bisect` checks out for you at each -point is just a suggestion, and you're free to try a different -version if you think it would be a good idea. For example, -occasionally you may land on a commit that broke something unrelated; -run - -------------------------------------------------- -$ git bisect visualize -------------------------------------------------- - -which will run gitk and label the commit it chose with a marker that -says "bisect". Choose a safe-looking commit nearby, note its commit -id, and check it out with: - -------------------------------------------------- -$ git reset --hard fb47ddb2db -------------------------------------------------- - -then test, run `bisect good` or `bisect bad` as appropriate, and -continue. - -Instead of `git bisect visualize` and then `git reset --hard -fb47ddb2db`, you might just want to tell Git that you want to skip -the current commit: - -------------------------------------------------- -$ git bisect skip -------------------------------------------------- - -In this case, though, Git may not eventually be able to tell the first -bad one between some first skipped commits and a later bad commit. - -There are also ways to automate the bisecting process if you have a -test script that can tell a good from a bad commit. See -linkgit:git-bisect[1] for more information about this and other `git -bisect` features. - -[[naming-commits]] -Naming commits --------------- - -We have seen several ways of naming commits already: - - - 40-hexdigit object name - - branch name: refers to the commit at the head of the given - branch - - tag name: refers to the commit pointed to by the given tag - (we've seen branches and tags are special cases of - <<how-git-stores-references,references>>). - - HEAD: refers to the head of the current branch - -There are many more; see the "SPECIFYING REVISIONS" section of the -linkgit:gitrevisions[7] man page for the complete list of ways to -name revisions. Some examples: - -------------------------------------------------- -$ git show fb47ddb2 # the first few characters of the object name - # are usually enough to specify it uniquely -$ git show HEAD^ # the parent of the HEAD commit -$ git show HEAD^^ # the grandparent -$ git show HEAD~4 # the great-great-grandparent -------------------------------------------------- - -Recall that merge commits may have more than one parent; by default, -`^` and `~` follow the first parent listed in the commit, but you can -also choose: - -------------------------------------------------- -$ git show HEAD^1 # show the first parent of HEAD -$ git show HEAD^2 # show the second parent of HEAD -------------------------------------------------- - -In addition to HEAD, there are several other special names for -commits: - -Merges (to be discussed later), as well as operations such as -`git reset`, which change the currently checked-out commit, generally -set ORIG_HEAD to the value HEAD had before the current operation. - -The `git fetch` operation always stores the head of the last fetched -branch in FETCH_HEAD. For example, if you run `git fetch` without -specifying a local branch as the target of the operation - -------------------------------------------------- -$ git fetch git://example.com/proj.git theirbranch -------------------------------------------------- - -the fetched commits will still be available from FETCH_HEAD. - -When we discuss merges we'll also see the special name MERGE_HEAD, -which refers to the other branch that we're merging in to the current -branch. - -The linkgit:git-rev-parse[1] command is a low-level command that is -occasionally useful for translating some name for a commit to the object -name for that commit: - -------------------------------------------------- -$ git rev-parse origin -e05db0fd4f31dde7005f075a84f96b360d05984b -------------------------------------------------- - -[[creating-tags]] -Creating tags -------------- - -We can also create a tag to refer to a particular commit; after -running - -------------------------------------------------- -$ git tag stable-1 1b2e1d63ff -------------------------------------------------- - -You can use `stable-1` to refer to the commit 1b2e1d63ff. - -This creates a "lightweight" tag. If you would also like to include a -comment with the tag, and possibly sign it cryptographically, then you -should create a tag object instead; see the linkgit:git-tag[1] man page -for details. - -[[browsing-revisions]] -Browsing revisions ------------------- - -The linkgit:git-log[1] command can show lists of commits. On its -own, it shows all commits reachable from the parent commit; but you -can also make more specific requests: - -------------------------------------------------- -$ git log v2.5.. # commits since (not reachable from) v2.5 -$ git log test..master # commits reachable from master but not test -$ git log master..test # ...reachable from test but not master -$ git log master...test # ...reachable from either test or master, - # but not both -$ git log --since="2 weeks ago" # commits from the last 2 weeks -$ git log Makefile # commits which modify Makefile -$ git log fs/ # ... which modify any file under fs/ -$ git log -S'foo()' # commits which add or remove any file data - # matching the string 'foo()' -------------------------------------------------- - -And of course you can combine all of these; the following finds -commits since v2.5 which touch the `Makefile` or any file under `fs`: - -------------------------------------------------- -$ git log v2.5.. Makefile fs/ -------------------------------------------------- - -You can also ask git log to show patches: - -------------------------------------------------- -$ git log -p -------------------------------------------------- - -See the `--pretty` option in the linkgit:git-log[1] man page for more -display options. - -Note that git log starts with the most recent commit and works -backwards through the parents; however, since Git history can contain -multiple independent lines of development, the particular order that -commits are listed in may be somewhat arbitrary. - -[[generating-diffs]] -Generating diffs ----------------- - -You can generate diffs between any two versions using -linkgit:git-diff[1]: - -------------------------------------------------- -$ git diff master..test -------------------------------------------------- - -That will produce the diff between the tips of the two branches. If -you'd prefer to find the diff from their common ancestor to test, you -can use three dots instead of two: - -------------------------------------------------- -$ git diff master...test -------------------------------------------------- - -Sometimes what you want instead is a set of patches; for this you can -use linkgit:git-format-patch[1]: - -------------------------------------------------- -$ git format-patch master..test -------------------------------------------------- - -will generate a file with a patch for each commit reachable from test -but not from master. - -[[viewing-old-file-versions]] -Viewing old file versions -------------------------- - -You can always view an old version of a file by just checking out the -correct revision first. But sometimes it is more convenient to be -able to view an old version of a single file without checking -anything out; this command does that: - -------------------------------------------------- -$ git show v2.5:fs/locks.c -------------------------------------------------- - -Before the colon may be anything that names a commit, and after it -may be any path to a file tracked by Git. - -[[history-examples]] -Examples --------- - -[[counting-commits-on-a-branch]] -Counting the number of commits on a branch -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Suppose you want to know how many commits you've made on `mybranch` -since it diverged from `origin`: - -------------------------------------------------- -$ git log --pretty=oneline origin..mybranch | wc -l -------------------------------------------------- - -Alternatively, you may often see this sort of thing done with the -lower-level command linkgit:git-rev-list[1], which just lists the SHA-1's -of all the given commits: - -------------------------------------------------- -$ git rev-list origin..mybranch | wc -l -------------------------------------------------- - -[[checking-for-equal-branches]] -Check whether two branches point at the same history -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Suppose you want to check whether two branches point at the same point -in history. - -------------------------------------------------- -$ git diff origin..master -------------------------------------------------- - -will tell you whether the contents of the project are the same at the -two branches; in theory, however, it's possible that the same project -contents could have been arrived at by two different historical -routes. You could compare the object names: - -------------------------------------------------- -$ git rev-list origin -e05db0fd4f31dde7005f075a84f96b360d05984b -$ git rev-list master -e05db0fd4f31dde7005f075a84f96b360d05984b -------------------------------------------------- - -Or you could recall that the `...` operator selects all commits -reachable from either one reference or the other but not -both; so - -------------------------------------------------- -$ git log origin...master -------------------------------------------------- - -will return no commits when the two branches are equal. - -[[finding-tagged-descendants]] -Find first tagged version including a given fix -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Suppose you know that the commit e05db0fd fixed a certain problem. -You'd like to find the earliest tagged release that contains that -fix. - -Of course, there may be more than one answer--if the history branched -after commit e05db0fd, then there could be multiple "earliest" tagged -releases. - -You could just visually inspect the commits since e05db0fd: - -------------------------------------------------- -$ gitk e05db0fd.. -------------------------------------------------- - -or you can use linkgit:git-name-rev[1], which will give the commit a -name based on any tag it finds pointing to one of the commit's -descendants: - -------------------------------------------------- -$ git name-rev --tags e05db0fd -e05db0fd tags/v1.5.0-rc1^0~23 -------------------------------------------------- - -The linkgit:git-describe[1] command does the opposite, naming the -revision using a tag on which the given commit is based: - -------------------------------------------------- -$ git describe e05db0fd -v1.5.0-rc0-260-ge05db0f -------------------------------------------------- - -but that may sometimes help you guess which tags might come after the -given commit. - -If you just want to verify whether a given tagged version contains a -given commit, you could use linkgit:git-merge-base[1]: - -------------------------------------------------- -$ git merge-base e05db0fd v1.5.0-rc1 -e05db0fd4f31dde7005f075a84f96b360d05984b -------------------------------------------------- - -The merge-base command finds a common ancestor of the given commits, -and always returns one or the other in the case where one is a -descendant of the other; so the above output shows that e05db0fd -actually is an ancestor of v1.5.0-rc1. - -Alternatively, note that - -------------------------------------------------- -$ git log v1.5.0-rc1..e05db0fd -------------------------------------------------- - -will produce empty output if and only if v1.5.0-rc1 includes e05db0fd, -because it outputs only commits that are not reachable from v1.5.0-rc1. - -As yet another alternative, the linkgit:git-show-branch[1] command lists -the commits reachable from its arguments with a display on the left-hand -side that indicates which arguments that commit is reachable from. -So, if you run something like - -------------------------------------------------- -$ git show-branch e05db0fd v1.5.0-rc0 v1.5.0-rc1 v1.5.0-rc2 -! [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if -available - ! [v1.5.0-rc0] GIT v1.5.0 preview - ! [v1.5.0-rc1] GIT v1.5.0-rc1 - ! [v1.5.0-rc2] GIT v1.5.0-rc2 -... -------------------------------------------------- - -then a line like - -------------------------------------------------- -+ ++ [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if -available -------------------------------------------------- - -shows that e05db0fd is reachable from itself, from v1.5.0-rc1, -and from v1.5.0-rc2, and not from v1.5.0-rc0. - -[[showing-commits-unique-to-a-branch]] -Showing commits unique to a given branch -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Suppose you would like to see all the commits reachable from the branch -head named `master` but not from any other head in your repository. - -We can list all the heads in this repository with -linkgit:git-show-ref[1]: - -------------------------------------------------- -$ git show-ref --heads -bf62196b5e363d73353a9dcf094c59595f3153b7 refs/heads/core-tutorial -db768d5504c1bb46f63ee9d6e1772bd047e05bf9 refs/heads/maint -a07157ac624b2524a059a3414e99f6f44bebc1e7 refs/heads/master -24dbc180ea14dc1aebe09f14c8ecf32010690627 refs/heads/tutorial-2 -1e87486ae06626c2f31eaa63d26fc0fd646c8af2 refs/heads/tutorial-fixes -------------------------------------------------- - -We can get just the branch-head names, and remove `master`, with -the help of the standard utilities cut and grep: - -------------------------------------------------- -$ git show-ref --heads | cut -d' ' -f2 | grep -v '^refs/heads/master' -refs/heads/core-tutorial -refs/heads/maint -refs/heads/tutorial-2 -refs/heads/tutorial-fixes -------------------------------------------------- - -And then we can ask to see all the commits reachable from master -but not from these other heads: - -------------------------------------------------- -$ gitk master --not $( git show-ref --heads | cut -d' ' -f2 | - grep -v '^refs/heads/master' ) -------------------------------------------------- - -Obviously, endless variations are possible; for example, to see all -commits reachable from some head but not from any tag in the repository: - -------------------------------------------------- -$ gitk $( git show-ref --heads ) --not $( git show-ref --tags ) -------------------------------------------------- - -(See linkgit:gitrevisions[7] for explanations of commit-selecting -syntax such as `--not`.) - -[[making-a-release]] -Creating a changelog and tarball for a software release -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The linkgit:git-archive[1] command can create a tar or zip archive from -any version of a project; for example: - -------------------------------------------------- -$ git archive -o latest.tar.gz --prefix=project/ HEAD -------------------------------------------------- - -will use HEAD to produce a gzipped tar archive in which each filename -is preceded by `project/`. The output file format is inferred from -the output file extension if possible, see linkgit:git-archive[1] for -details. - -Versions of Git older than 1.7.7 don't know about the `tar.gz` format, -you'll need to use gzip explicitly: - -------------------------------------------------- -$ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz -------------------------------------------------- - -If you're releasing a new version of a software project, you may want -to simultaneously make a changelog to include in the release -announcement. - -Linus Torvalds, for example, makes new kernel releases by tagging them, -then running: - -------------------------------------------------- -$ release-script 2.6.12 2.6.13-rc6 2.6.13-rc7 -------------------------------------------------- - -where release-script is a shell script that looks like: - -------------------------------------------------- -#!/bin/sh -stable="$1" -last="$2" -new="$3" -echo "# git tag v$new" -echo "git archive --prefix=linux-$new/ v$new | gzip -9 > ../linux-$new.tar.gz" -echo "git diff v$stable v$new | gzip -9 > ../patch-$new.gz" -echo "git log --no-merges v$new ^v$last > ../ChangeLog-$new" -echo "git shortlog --no-merges v$new ^v$last > ../ShortLog" -echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new" -------------------------------------------------- - -and then he just cut-and-pastes the output commands after verifying that -they look OK. - -[[Finding-commits-With-given-Content]] -Finding commits referencing a file with given content -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Somebody hands you a copy of a file, and asks which commits modified a -file such that it contained the given content either before or after the -commit. You can find out with this: - -------------------------------------------------- -$ git log --raw --abbrev=40 --pretty=oneline | - grep -B 1 `git hash-object filename` -------------------------------------------------- - -Figuring out why this works is left as an exercise to the (advanced) -student. The linkgit:git-log[1], linkgit:git-diff-tree[1], and -linkgit:git-hash-object[1] man pages may prove helpful. - -[[Developing-With-git]] -Developing with Git -=================== - -[[telling-git-your-name]] -Telling Git your name ---------------------- - -Before creating any commits, you should introduce yourself to Git. -The easiest way to do so is to use linkgit:git-config[1]: - ------------------------------------------------- -$ git config --global user.name 'Your Name Comes Here' -$ git config --global user.email 'you@yourdomain.example.com' ------------------------------------------------- - -Which will add the following to a file named `.gitconfig` in your -home directory: - ------------------------------------------------- -[user] - name = Your Name Comes Here - email = you@yourdomain.example.com ------------------------------------------------- - -See the "CONFIGURATION FILE" section of linkgit:git-config[1] for -details on the configuration file. The file is plain text, so you can -also edit it with your favorite editor. - - -[[creating-a-new-repository]] -Creating a new repository -------------------------- - -Creating a new repository from scratch is very easy: - -------------------------------------------------- -$ mkdir project -$ cd project -$ git init -------------------------------------------------- - -If you have some initial content (say, a tarball): - -------------------------------------------------- -$ tar xzvf project.tar.gz -$ cd project -$ git init -$ git add . # include everything below ./ in the first commit: -$ git commit -------------------------------------------------- - -[[how-to-make-a-commit]] -How to make a commit --------------------- - -Creating a new commit takes three steps: - - 1. Making some changes to the working directory using your - favorite editor. - 2. Telling Git about your changes. - 3. Creating the commit using the content you told Git about - in step 2. - -In practice, you can interleave and repeat steps 1 and 2 as many -times as you want: in order to keep track of what you want committed -at step 3, Git maintains a snapshot of the tree's contents in a -special staging area called "the index." - -At the beginning, the content of the index will be identical to -that of the HEAD. The command `git diff --cached`, which shows -the difference between the HEAD and the index, should therefore -produce no output at that point. - -Modifying the index is easy: - -To update the index with the contents of a new or modified file, use - -------------------------------------------------- -$ git add path/to/file -------------------------------------------------- - -To remove a file from the index and from the working tree, use - -------------------------------------------------- -$ git rm path/to/file -------------------------------------------------- - -After each step you can verify that - -------------------------------------------------- -$ git diff --cached -------------------------------------------------- - -always shows the difference between the HEAD and the index file--this -is what you'd commit if you created the commit now--and that - -------------------------------------------------- -$ git diff -------------------------------------------------- - -shows the difference between the working tree and the index file. - -Note that `git add` always adds just the current contents of a file -to the index; further changes to the same file will be ignored unless -you run `git add` on the file again. - -When you're ready, just run - -------------------------------------------------- -$ git commit -------------------------------------------------- - -and Git will prompt you for a commit message and then create the new -commit. Check to make sure it looks like what you expected with - -------------------------------------------------- -$ git show -------------------------------------------------- - -As a special shortcut, - -------------------------------------------------- -$ git commit -a -------------------------------------------------- - -will update the index with any files that you've modified or removed -and create a commit, all in one step. - -A number of commands are useful for keeping track of what you're -about to commit: - -------------------------------------------------- -$ git diff --cached # difference between HEAD and the index; what - # would be committed if you ran "commit" now. -$ git diff # difference between the index file and your - # working directory; changes that would not - # be included if you ran "commit" now. -$ git diff HEAD # difference between HEAD and working tree; what - # would be committed if you ran "commit -a" now. -$ git status # a brief per-file summary of the above. -------------------------------------------------- - -You can also use linkgit:git-gui[1] to create commits, view changes in -the index and the working tree files, and individually select diff hunks -for inclusion in the index (by right-clicking on the diff hunk and -choosing "Stage Hunk For Commit"). - -[[creating-good-commit-messages]] -Creating good commit messages ------------------------------ - -Though not required, it's a good idea to begin the commit message -with a single short (less than 50 character) line summarizing the -change, followed by a blank line and then a more thorough -description. The text up to the first blank line in a commit -message is treated as the commit title, and that title is used -throughout Git. For example, linkgit:git-format-patch[1] turns a -commit into email, and it uses the title on the Subject line and the -rest of the commit in the body. - - -[[ignoring-files]] -Ignoring files --------------- - -A project will often generate files that you do 'not' want to track with Git. -This typically includes files generated by a build process or temporary -backup files made by your editor. Of course, 'not' tracking files with Git -is just a matter of 'not' calling `git add` on them. But it quickly becomes -annoying to have these untracked files lying around; e.g. they make -`git add .` practically useless, and they keep showing up in the output of -`git status`. - -You can tell Git to ignore certain files by creating a file called -`.gitignore` in the top level of your working directory, with contents -such as: - -------------------------------------------------- -# Lines starting with '#' are considered comments. -# Ignore any file named foo.txt. -foo.txt -# Ignore (generated) html files, -*.html -# except foo.html which is maintained by hand. -!foo.html -# Ignore objects and archives. -*.[oa] -------------------------------------------------- - -See linkgit:gitignore[5] for a detailed explanation of the syntax. You can -also place .gitignore files in other directories in your working tree, and they -will apply to those directories and their subdirectories. The `.gitignore` -files can be added to your repository like any other files (just run `git add -.gitignore` and `git commit`, as usual), which is convenient when the exclude -patterns (such as patterns matching build output files) would also make sense -for other users who clone your repository. - -If you wish the exclude patterns to affect only certain repositories -(instead of every repository for a given project), you may instead put -them in a file in your repository named `.git/info/exclude`, or in any -file specified by the `core.excludesFile` configuration variable. -Some Git commands can also take exclude patterns directly on the -command line. See linkgit:gitignore[5] for the details. - -[[how-to-merge]] -How to merge ------------- - -You can rejoin two diverging branches of development using -linkgit:git-merge[1]: - -------------------------------------------------- -$ git merge branchname -------------------------------------------------- - -merges the development in the branch `branchname` into the current -branch. - -A merge is made by combining the changes made in `branchname` and the -changes made up to the latest commit in your current branch since -their histories forked. The work tree is overwritten by the result of -the merge when this combining is done cleanly, or overwritten by a -half-merged results when this combining results in conflicts. -Therefore, if you have uncommitted changes touching the same files as -the ones impacted by the merge, Git will refuse to proceed. Most of -the time, you will want to commit your changes before you can merge, -and if you don't, then linkgit:git-stash[1] can take these changes -away while you're doing the merge, and reapply them afterwards. - -If the changes are independent enough, Git will automatically complete -the merge and commit the result (or reuse an existing commit in case -of <<fast-forwards,fast-forward>>, see below). On the other hand, -if there are conflicts--for example, if the same file is -modified in two different ways in the remote branch and the local -branch--then you are warned; the output may look something like this: - -------------------------------------------------- -$ git merge next - 100% (4/4) done -Auto-merged file.txt -CONFLICT (content): Merge conflict in file.txt -Automatic merge failed; fix conflicts and then commit the result. -------------------------------------------------- - -Conflict markers are left in the problematic files, and after -you resolve the conflicts manually, you can update the index -with the contents and run Git commit, as you normally would when -creating a new file. - -If you examine the resulting commit using gitk, you will see that it -has two parents, one pointing to the top of the current branch, and -one to the top of the other branch. - -[[resolving-a-merge]] -Resolving a merge ------------------ - -When a merge isn't resolved automatically, Git leaves the index and -the working tree in a special state that gives you all the -information you need to help resolve the merge. - -Files with conflicts are marked specially in the index, so until you -resolve the problem and update the index, linkgit:git-commit[1] will -fail: - -------------------------------------------------- -$ git commit -file.txt: needs merge -------------------------------------------------- - -Also, linkgit:git-status[1] will list those files as "unmerged", and the -files with conflicts will have conflict markers added, like this: - -------------------------------------------------- -<<<<<<< HEAD:file.txt -Hello world -======= -Goodbye ->>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt -------------------------------------------------- - -All you need to do is edit the files to resolve the conflicts, and then - -------------------------------------------------- -$ git add file.txt -$ git commit -------------------------------------------------- - -Note that the commit message will already be filled in for you with -some information about the merge. Normally you can just use this -default message unchanged, but you may add additional commentary of -your own if desired. - -The above is all you need to know to resolve a simple merge. But Git -also provides more information to help resolve conflicts: - -[[conflict-resolution]] -Getting conflict-resolution help during a merge -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -All of the changes that Git was able to merge automatically are -already added to the index file, so linkgit:git-diff[1] shows only -the conflicts. It uses an unusual syntax: - -------------------------------------------------- -$ git diff -diff --cc file.txt -index 802992c,2b60207..0000000 ---- a/file.txt -+++ b/file.txt -@@@ -1,1 -1,1 +1,5 @@@ -++<<<<<<< HEAD:file.txt - +Hello world -++======= -+ Goodbye -++>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt -------------------------------------------------- - -Recall that the commit which will be committed after we resolve this -conflict will have two parents instead of the usual one: one parent -will be HEAD, the tip of the current branch; the other will be the -tip of the other branch, which is stored temporarily in MERGE_HEAD. - -During the merge, the index holds three versions of each file. Each of -these three "file stages" represents a different version of the file: - -------------------------------------------------- -$ git show :1:file.txt # the file in a common ancestor of both branches -$ git show :2:file.txt # the version from HEAD. -$ git show :3:file.txt # the version from MERGE_HEAD. -------------------------------------------------- - -When you ask linkgit:git-diff[1] to show the conflicts, it runs a -three-way diff between the conflicted merge results in the work tree with -stages 2 and 3 to show only hunks whose contents come from both sides, -mixed (in other words, when a hunk's merge results come only from stage 2, -that part is not conflicting and is not shown. Same for stage 3). - -The diff above shows the differences between the working-tree version of -file.txt and the stage 2 and stage 3 versions. So instead of preceding -each line by a single `+` or `-`, it now uses two columns: the first -column is used for differences between the first parent and the working -directory copy, and the second for differences between the second parent -and the working directory copy. (See the "COMBINED DIFF FORMAT" section -of linkgit:git-diff-files[1] for a details of the format.) - -After resolving the conflict in the obvious way (but before updating the -index), the diff will look like: - -------------------------------------------------- -$ git diff -diff --cc file.txt -index 802992c,2b60207..0000000 ---- a/file.txt -+++ b/file.txt -@@@ -1,1 -1,1 +1,1 @@@ -- Hello world - -Goodbye -++Goodbye world -------------------------------------------------- - -This shows that our resolved version deleted "Hello world" from the -first parent, deleted "Goodbye" from the second parent, and added -"Goodbye world", which was previously absent from both. - -Some special diff options allow diffing the working directory against -any of these stages: - -------------------------------------------------- -$ git diff -1 file.txt # diff against stage 1 -$ git diff --base file.txt # same as the above -$ git diff -2 file.txt # diff against stage 2 -$ git diff --ours file.txt # same as the above -$ git diff -3 file.txt # diff against stage 3 -$ git diff --theirs file.txt # same as the above. -------------------------------------------------- - -The linkgit:git-log[1] and linkgit:gitk[1] commands also provide special help -for merges: - -------------------------------------------------- -$ git log --merge -$ gitk --merge -------------------------------------------------- - -These will display all commits which exist only on HEAD or on -MERGE_HEAD, and which touch an unmerged file. - -You may also use linkgit:git-mergetool[1], which lets you merge the -unmerged files using external tools such as Emacs or kdiff3. - -Each time you resolve the conflicts in a file and update the index: - -------------------------------------------------- -$ git add file.txt -------------------------------------------------- - -the different stages of that file will be "collapsed", after which -`git diff` will (by default) no longer show diffs for that file. - -[[undoing-a-merge]] -Undoing a merge ---------------- - -If you get stuck and decide to just give up and throw the whole mess -away, you can always return to the pre-merge state with - -------------------------------------------------- -$ git merge --abort -------------------------------------------------- - -Or, if you've already committed the merge that you want to throw away, - -------------------------------------------------- -$ git reset --hard ORIG_HEAD -------------------------------------------------- - -However, this last command can be dangerous in some cases--never -throw away a commit you have already committed if that commit may -itself have been merged into another branch, as doing so may confuse -further merges. - -[[fast-forwards]] -Fast-forward merges -------------------- - -There is one special case not mentioned above, which is treated -differently. Normally, a merge results in a merge commit, with two -parents, one pointing at each of the two lines of development that -were merged. - -However, if the current branch is an ancestor of the other--so every commit -present in the current branch is already contained in the other branch--then Git -just performs a "fast-forward"; the head of the current branch is moved forward -to point at the head of the merged-in branch, without any new commits being -created. - -[[fixing-mistakes]] -Fixing mistakes ---------------- - -If you've messed up the working tree, but haven't yet committed your -mistake, you can return the entire working tree to the last committed -state with - -------------------------------------------------- -$ git restore --staged --worktree :/ -------------------------------------------------- - -If you make a commit that you later wish you hadn't, there are two -fundamentally different ways to fix the problem: - - 1. You can create a new commit that undoes whatever was done - by the old commit. This is the correct thing if your - mistake has already been made public. - - 2. You can go back and modify the old commit. You should - never do this if you have already made the history public; - Git does not normally expect the "history" of a project to - change, and cannot correctly perform repeated merges from - a branch that has had its history changed. - -[[reverting-a-commit]] -Fixing a mistake with a new commit -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Creating a new commit that reverts an earlier change is very easy; -just pass the linkgit:git-revert[1] command a reference to the bad -commit; for example, to revert the most recent commit: - -------------------------------------------------- -$ git revert HEAD -------------------------------------------------- - -This will create a new commit which undoes the change in HEAD. You -will be given a chance to edit the commit message for the new commit. - -You can also revert an earlier change, for example, the next-to-last: - -------------------------------------------------- -$ git revert HEAD^ -------------------------------------------------- - -In this case Git will attempt to undo the old change while leaving -intact any changes made since then. If more recent changes overlap -with the changes to be reverted, then you will be asked to fix -conflicts manually, just as in the case of <<resolving-a-merge, -resolving a merge>>. - -[[fixing-a-mistake-by-rewriting-history]] -Fixing a mistake by rewriting history -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -If the problematic commit is the most recent commit, and you have not -yet made that commit public, then you may just -<<undoing-a-merge,destroy it using `git reset`>>. - -Alternatively, you -can edit the working directory and update the index to fix your -mistake, just as if you were going to <<how-to-make-a-commit,create a -new commit>>, then run - -------------------------------------------------- -$ git commit --amend -------------------------------------------------- - -which will replace the old commit by a new commit incorporating your -changes, giving you a chance to edit the old commit message first. - -Again, you should never do this to a commit that may already have -been merged into another branch; use linkgit:git-revert[1] instead in -that case. - -It is also possible to replace commits further back in the history, but -this is an advanced topic to be left for -<<cleaning-up-history,another chapter>>. - -[[checkout-of-path]] -Checking out an old version of a file -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In the process of undoing a previous bad change, you may find it -useful to check out an older version of a particular file using -linkgit:git-restore[1]. The command - -------------------------------------------------- -$ git restore --source=HEAD^ path/to/file -------------------------------------------------- - -replaces path/to/file by the contents it had in the commit HEAD^, and -also updates the index to match. It does not change branches. - -If you just want to look at an old version of the file, without -modifying the working directory, you can do that with -linkgit:git-show[1]: - -------------------------------------------------- -$ git show HEAD^:path/to/file -------------------------------------------------- - -which will display the given version of the file. - -[[interrupted-work]] -Temporarily setting aside work in progress -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -While you are in the middle of working on something complicated, you -find an unrelated but obvious and trivial bug. You would like to fix it -before continuing. You can use linkgit:git-stash[1] to save the current -state of your work, and after fixing the bug (or, optionally after doing -so on a different branch and then coming back), unstash the -work-in-progress changes. - ------------------------------------------------- -$ git stash push -m "work in progress for foo feature" ------------------------------------------------- - -This command will save your changes away to the `stash`, and -reset your working tree and the index to match the tip of your -current branch. Then you can make your fix as usual. - ------------------------------------------------- -... edit and test ... -$ git commit -a -m "blorpl: typofix" ------------------------------------------------- - -After that, you can go back to what you were working on with -`git stash pop`: - ------------------------------------------------- -$ git stash pop ------------------------------------------------- - - -[[ensuring-good-performance]] -Ensuring good performance -------------------------- - -On large repositories, Git depends on compression to keep the history -information from taking up too much space on disk or in memory. Some -Git commands may automatically run linkgit:git-gc[1], so you don't -have to worry about running it manually. However, compressing a large -repository may take a while, so you may want to call `gc` explicitly -to avoid automatic compression kicking in when it is not convenient. - - -[[ensuring-reliability]] -Ensuring reliability --------------------- - -[[checking-for-corruption]] -Checking the repository for corruption -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The linkgit:git-fsck[1] command runs a number of self-consistency checks -on the repository, and reports on any problems. This may take some -time. - -------------------------------------------------- -$ git fsck -dangling commit 7281251ddd2a61e38657c827739c57015671a6b3 -dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63 -dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5 -dangling blob 218761f9d90712d37a9c5e36f406f92202db07eb -dangling commit bf093535a34a4d35731aa2bd90fe6b176302f14f -dangling commit 8e4bec7f2ddaa268bef999853c25755452100f8e -dangling tree d50bb86186bf27b681d25af89d3b5b68382e4085 -dangling tree b24c2473f1fd3d91352a624795be026d64c8841f -... -------------------------------------------------- - -You will see informational messages on dangling objects. They are objects -that still exist in the repository but are no longer referenced by any of -your branches, and can (and will) be removed after a while with `gc`. -You can run `git fsck --no-dangling` to suppress these messages, and still -view real errors. - -[[recovering-lost-changes]] -Recovering lost changes -~~~~~~~~~~~~~~~~~~~~~~~ - -[[reflogs]] -Reflogs -^^^^^^^ - -Say you modify a branch with <<fixing-mistakes,`git reset --hard`>>, -and then realize that the branch was the only reference you had to -that point in history. - -Fortunately, Git also keeps a log, called a "reflog", of all the -previous values of each branch. So in this case you can still find the -old history using, for example, - -------------------------------------------------- -$ git log master@{1} -------------------------------------------------- - -This lists the commits reachable from the previous version of the -`master` branch head. This syntax can be used with any Git command -that accepts a commit, not just with `git log`. Some other examples: - -------------------------------------------------- -$ git show master@{2} # See where the branch pointed 2, -$ git show master@{3} # 3, ... changes ago. -$ gitk master@{yesterday} # See where it pointed yesterday, -$ gitk master@{"1 week ago"} # ... or last week -$ git log --walk-reflogs master # show reflog entries for master -------------------------------------------------- - -A separate reflog is kept for the HEAD, so - -------------------------------------------------- -$ git show HEAD@{"1 week ago"} -------------------------------------------------- - -will show what HEAD pointed to one week ago, not what the current branch -pointed to one week ago. This allows you to see the history of what -you've checked out. - -The reflogs are kept by default for 30 days, after which they may be -pruned. See linkgit:git-reflog[1] and linkgit:git-gc[1] to learn -how to control this pruning, and see the "SPECIFYING REVISIONS" -section of linkgit:gitrevisions[7] for details. - -Note that the reflog history is very different from normal Git history. -While normal history is shared by every repository that works on the -same project, the reflog history is not shared: it tells you only about -how the branches in your local repository have changed over time. - -[[dangling-object-recovery]] -Examining dangling objects -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In some situations the reflog may not be able to save you. For example, -suppose you delete a branch, then realize you need the history it -contained. The reflog is also deleted; however, if you have not yet -pruned the repository, then you may still be able to find the lost -commits in the dangling objects that `git fsck` reports. See -<<dangling-objects>> for the details. - -------------------------------------------------- -$ git fsck -dangling commit 7281251ddd2a61e38657c827739c57015671a6b3 -dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63 -dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5 -... -------------------------------------------------- - -You can examine -one of those dangling commits with, for example, - ------------------------------------------------- -$ gitk 7281251ddd --not --all ------------------------------------------------- - -which does what it sounds like: it says that you want to see the commit -history that is described by the dangling commit(s), but not the -history that is described by all your existing branches and tags. Thus -you get exactly the history reachable from that commit that is lost. -(And notice that it might not be just one commit: we only report the -"tip of the line" as being dangling, but there might be a whole deep -and complex commit history that was dropped.) - -If you decide you want the history back, you can always create a new -reference pointing to it, for example, a new branch: - ------------------------------------------------- -$ git branch recovered-branch 7281251ddd ------------------------------------------------- - -Other types of dangling objects (blobs and trees) are also possible, and -dangling objects can arise in other situations. - - -[[sharing-development]] -Sharing development with others -=============================== - -[[getting-updates-With-git-pull]] -Getting updates with git pull ------------------------------ - -After you clone a repository and commit a few changes of your own, you -may wish to check the original repository for updates and merge them -into your own work. - -We have already seen <<Updating-a-repository-With-git-fetch,how to -keep remote-tracking branches up to date>> with linkgit:git-fetch[1], -and how to merge two branches. So you can merge in changes from the -original repository's master branch with: - -------------------------------------------------- -$ git fetch -$ git merge origin/master -------------------------------------------------- - -However, the linkgit:git-pull[1] command provides a way to do this in -one step: - -------------------------------------------------- -$ git pull origin master -------------------------------------------------- - -In fact, if you have `master` checked out, then this branch has been -configured by `git clone` to get changes from the HEAD branch of the -origin repository. So often you can -accomplish the above with just a simple - -------------------------------------------------- -$ git pull -------------------------------------------------- - -This command will fetch changes from the remote branches to your -remote-tracking branches `origin/*`, and merge the default branch into -the current branch. - -More generally, a branch that is created from a remote-tracking branch -will pull -by default from that branch. See the descriptions of the -`branch.<name>.remote` and `branch.<name>.merge` options in -linkgit:git-config[1], and the discussion of the `--track` option in -linkgit:git-checkout[1], to learn how to control these defaults. - -In addition to saving you keystrokes, `git pull` also helps you by -producing a default commit message documenting the branch and -repository that you pulled from. - -(But note that no such commit will be created in the case of a -<<fast-forwards,fast-forward>>; instead, your branch will just be -updated to point to the latest commit from the upstream branch.) - -The `git pull` command can also be given `.` as the "remote" repository, -in which case it just merges in a branch from the current repository; so -the commands - -------------------------------------------------- -$ git pull . branch -$ git merge branch -------------------------------------------------- - -are roughly equivalent. - -[[submitting-patches]] -Submitting patches to a project -------------------------------- - -If you just have a few changes, the simplest way to submit them may -just be to send them as patches in email: - -First, use linkgit:git-format-patch[1]; for example: - -------------------------------------------------- -$ git format-patch origin -------------------------------------------------- - -will produce a numbered series of files in the current directory, one -for each patch in the current branch but not in `origin/HEAD`. - -`git format-patch` can include an initial "cover letter". You can insert -commentary on individual patches after the three dash line which -`format-patch` places after the commit message but before the patch -itself. If you use `git notes` to track your cover letter material, -`git format-patch --notes` will include the commit's notes in a similar -manner. - -You can then import these into your mail client and send them by -hand. However, if you have a lot to send at once, you may prefer to -use the linkgit:git-send-email[1] script to automate the process. -Consult the mailing list for your project first to determine -their requirements for submitting patches. - -[[importing-patches]] -Importing patches to a project ------------------------------- - -Git also provides a tool called linkgit:git-am[1] (am stands for -"apply mailbox"), for importing such an emailed series of patches. -Just save all of the patch-containing messages, in order, into a -single mailbox file, say `patches.mbox`, then run - -------------------------------------------------- -$ git am -3 patches.mbox -------------------------------------------------- - -Git will apply each patch in order; if any conflicts are found, it -will stop, and you can fix the conflicts as described in -"<<resolving-a-merge,Resolving a merge>>". (The `-3` option tells -Git to perform a merge; if you would prefer it just to abort and -leave your tree and index untouched, you may omit that option.) - -Once the index is updated with the results of the conflict -resolution, instead of creating a new commit, just run - -------------------------------------------------- -$ git am --continue -------------------------------------------------- - -and Git will create the commit for you and continue applying the -remaining patches from the mailbox. - -The final result will be a series of commits, one for each patch in -the original mailbox, with authorship and commit log message each -taken from the message containing each patch. - -[[public-repositories]] -Public Git repositories ------------------------ - -Another way to submit changes to a project is to tell the maintainer -of that project to pull the changes from your repository using -linkgit:git-pull[1]. In the section "<<getting-updates-With-git-pull, -Getting updates with `git pull`>>" we described this as a way to get -updates from the "main" repository, but it works just as well in the -other direction. - -If you and the maintainer both have accounts on the same machine, then -you can just pull changes from each other's repositories directly; -commands that accept repository URLs as arguments will also accept a -local directory name: - -------------------------------------------------- -$ git clone /path/to/repository -$ git pull /path/to/other/repository -------------------------------------------------- - -or an ssh URL: - -------------------------------------------------- -$ git clone ssh://yourhost/~you/repository -------------------------------------------------- - -For projects with few developers, or for synchronizing a few private -repositories, this may be all you need. - -However, the more common way to do this is to maintain a separate public -repository (usually on a different host) for others to pull changes -from. This is usually more convenient, and allows you to cleanly -separate private work in progress from publicly visible work. - -You will continue to do your day-to-day work in your personal -repository, but periodically "push" changes from your personal -repository into your public repository, allowing other developers to -pull from that repository. So the flow of changes, in a situation -where there is one other developer with a public repository, looks -like this: - - you push - your personal repo ------------------> your public repo - ^ | - | | - | you pull | they pull - | | - | | - | they push V - their public repo <------------------- their repo - -We explain how to do this in the following sections. - -[[setting-up-a-public-repository]] -Setting up a public repository -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Assume your personal repository is in the directory `~/proj`. We -first create a new clone of the repository and tell `git daemon` that it -is meant to be public: - -------------------------------------------------- -$ git clone --bare ~/proj proj.git -$ touch proj.git/git-daemon-export-ok -------------------------------------------------- - -The resulting directory proj.git contains a "bare" git repository--it is -just the contents of the `.git` directory, without any files checked out -around it. - -Next, copy `proj.git` to the server where you plan to host the -public repository. You can use scp, rsync, or whatever is most -convenient. - -[[exporting-via-git]] -Exporting a Git repository via the Git protocol -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -This is the preferred method. - -If someone else administers the server, they should tell you what -directory to put the repository in, and what `git://` URL it will -appear at. You can then skip to the section -"<<pushing-changes-to-a-public-repository,Pushing changes to a public -repository>>", below. - -Otherwise, all you need to do is start linkgit:git-daemon[1]; it will -listen on port 9418. By default, it will allow access to any directory -that looks like a Git directory and contains the magic file -git-daemon-export-ok. Passing some directory paths as `git daemon` -arguments will further restrict the exports to those paths. - -You can also run `git daemon` as an inetd service; see the -linkgit:git-daemon[1] man page for details. (See especially the -examples section.) - -[[exporting-via-http]] -Exporting a git repository via HTTP -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The Git protocol gives better performance and reliability, but on a -host with a web server set up, HTTP exports may be simpler to set up. - -All you need to do is place the newly created bare Git repository in -a directory that is exported by the web server, and make some -adjustments to give web clients some extra information they need: - -------------------------------------------------- -$ mv proj.git /home/you/public_html/proj.git -$ cd proj.git -$ git --bare update-server-info -$ mv hooks/post-update.sample hooks/post-update -------------------------------------------------- - -(For an explanation of the last two lines, see -linkgit:git-update-server-info[1] and linkgit:githooks[5].) - -Advertise the URL of `proj.git`. Anybody else should then be able to -clone or pull from that URL, for example with a command line like: - -------------------------------------------------- -$ git clone http://yourserver.com/~you/proj.git -------------------------------------------------- - -(See also -link:howto/setup-git-server-over-http.html[setup-git-server-over-http] -for a slightly more sophisticated setup using WebDAV which also -allows pushing over HTTP.) - -[[pushing-changes-to-a-public-repository]] -Pushing changes to a public repository -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Note that the two techniques outlined above (exporting via -<<exporting-via-http,http>> or <<exporting-via-git,git>>) allow other -maintainers to fetch your latest changes, but they do not allow write -access, which you will need to update the public repository with the -latest changes created in your private repository. - -The simplest way to do this is using linkgit:git-push[1] and ssh; to -update the remote branch named `master` with the latest state of your -branch named `master`, run - -------------------------------------------------- -$ git push ssh://yourserver.com/~you/proj.git master:master -------------------------------------------------- - -or just - -------------------------------------------------- -$ git push ssh://yourserver.com/~you/proj.git master -------------------------------------------------- - -As with `git fetch`, `git push` will complain if this does not result in a -<<fast-forwards,fast-forward>>; see the following section for details on -handling this case. - -Note that the target of a `push` is normally a -<<def_bare_repository,bare>> repository. You can also push to a -repository that has a checked-out working tree, but a push to update the -currently checked-out branch is denied by default to prevent confusion. -See the description of the receive.denyCurrentBranch option -in linkgit:git-config[1] for details. - -As with `git fetch`, you may also set up configuration options to -save typing; so, for example: - -------------------------------------------------- -$ git remote add public-repo ssh://yourserver.com/~you/proj.git -------------------------------------------------- - -adds the following to `.git/config`: - -------------------------------------------------- -[remote "public-repo"] - url = yourserver.com:proj.git - fetch = +refs/heads/*:refs/remotes/example/* -------------------------------------------------- - -which lets you do the same push with just - -------------------------------------------------- -$ git push public-repo master -------------------------------------------------- - -See the explanations of the `remote.<name>.url`, -`branch.<name>.remote`, and `remote.<name>.push` options in -linkgit:git-config[1] for details. - -[[forcing-push]] -What to do when a push fails -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -If a push would not result in a <<fast-forwards,fast-forward>> of the -remote branch, then it will fail with an error like: - -------------------------------------------------- - ! [rejected] master -> master (non-fast-forward) -error: failed to push some refs to '...' -hint: Updates were rejected because the tip of your current branch is behind -hint: its remote counterpart. Integrate the remote changes (e.g. -hint: 'git pull ...') before pushing again. -hint: See the 'Note about fast-forwards' in 'git push --help' for details. -------------------------------------------------- - -This can happen, for example, if you: - - - use `git reset --hard` to remove already-published commits, or - - use `git commit --amend` to replace already-published commits - (as in <<fixing-a-mistake-by-rewriting-history>>), or - - use `git rebase` to rebase any already-published commits (as - in <<using-git-rebase>>). - -You may force `git push` to perform the update anyway by preceding the -branch name with a plus sign: - -------------------------------------------------- -$ git push ssh://yourserver.com/~you/proj.git +master -------------------------------------------------- - -Note the addition of the `+` sign. Alternatively, you can use the -`-f` flag to force the remote update, as in: - -------------------------------------------------- -$ git push -f ssh://yourserver.com/~you/proj.git master -------------------------------------------------- - -Normally whenever a branch head in a public repository is modified, it -is modified to point to a descendant of the commit that it pointed to -before. By forcing a push in this situation, you break that convention. -(See <<problems-With-rewriting-history>>.) - -Nevertheless, this is a common practice for people that need a simple -way to publish a work-in-progress patch series, and it is an acceptable -compromise as long as you warn other developers that this is how you -intend to manage the branch. - -It's also possible for a push to fail in this way when other people have -the right to push to the same repository. In that case, the correct -solution is to retry the push after first updating your work: either by a -pull, or by a fetch followed by a rebase; see the -<<setting-up-a-shared-repository,next section>> and -linkgit:gitcvs-migration[7] for more. - -[[setting-up-a-shared-repository]] -Setting up a shared repository -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Another way to collaborate is by using a model similar to that -commonly used in CVS, where several developers with special rights -all push to and pull from a single shared repository. See -linkgit:gitcvs-migration[7] for instructions on how to -set this up. - -However, while there is nothing wrong with Git's support for shared -repositories, this mode of operation is not generally recommended, -simply because the mode of collaboration that Git supports--by -exchanging patches and pulling from public repositories--has so many -advantages over the central shared repository: - - - Git's ability to quickly import and merge patches allows a - single maintainer to process incoming changes even at very - high rates. And when that becomes too much, `git pull` provides - an easy way for that maintainer to delegate this job to other - maintainers while still allowing optional review of incoming - changes. - - Since every developer's repository has the same complete copy - of the project history, no repository is special, and it is - trivial for another developer to take over maintenance of a - project, either by mutual agreement, or because a maintainer - becomes unresponsive or difficult to work with. - - The lack of a central group of "committers" means there is - less need for formal decisions about who is "in" and who is - "out". - -[[setting-up-gitweb]] -Allowing web browsing of a repository -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The gitweb cgi script provides users an easy way to browse your -project's revisions, file contents and logs without having to install -Git. Features like RSS/Atom feeds and blame/annotation details may -optionally be enabled. - -The linkgit:git-instaweb[1] command provides a simple way to start -browsing the repository using gitweb. The default server when using -instaweb is lighttpd. - -See the file gitweb/INSTALL in the Git source tree and -linkgit:gitweb[1] for instructions on details setting up a permanent -installation with a CGI or Perl capable server. - -[[how-to-get-a-git-repository-with-minimal-history]] -How to get a Git repository with minimal history ------------------------------------------------- - -A <<def_shallow_clone,shallow clone>>, with its truncated -history, is useful when one is interested only in recent history -of a project and getting full history from the upstream is -expensive. - -A <<def_shallow_clone,shallow clone>> is created by specifying -the linkgit:git-clone[1] `--depth` switch. The depth can later be -changed with the linkgit:git-fetch[1] `--depth` switch, or full -history restored with `--unshallow`. - -Merging inside a <<def_shallow_clone,shallow clone>> will work as long -as a merge base is in the recent history. -Otherwise, it will be like merging unrelated histories and may -have to result in huge conflicts. This limitation may make such -a repository unsuitable to be used in merge based workflows. - -[[sharing-development-examples]] -Examples --------- - -[[maintaining-topic-branches]] -Maintaining topic branches for a Linux subsystem maintainer -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -This describes how Tony Luck uses Git in his role as maintainer of the -IA64 architecture for the Linux kernel. - -He uses two public branches: - - - A "test" tree into which patches are initially placed so that they - can get some exposure when integrated with other ongoing development. - This tree is available to Andrew for pulling into -mm whenever he - wants. - - - A "release" tree into which tested patches are moved for final sanity - checking, and as a vehicle to send them upstream to Linus (by sending - him a "please pull" request.) - -He also uses a set of temporary branches ("topic branches"), each -containing a logical grouping of patches. - -To set this up, first create your work tree by cloning Linus's public -tree: - -------------------------------------------------- -$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git work -$ cd work -------------------------------------------------- - -Linus's tree will be stored in the remote-tracking branch named origin/master, -and can be updated using linkgit:git-fetch[1]; you can track other -public trees using linkgit:git-remote[1] to set up a "remote" and -linkgit:git-fetch[1] to keep them up to date; see -<<repositories-and-branches>>. - -Now create the branches in which you are going to work; these start out -at the current tip of origin/master branch, and should be set up (using -the `--track` option to linkgit:git-branch[1]) to merge changes in from -Linus by default. - -------------------------------------------------- -$ git branch --track test origin/master -$ git branch --track release origin/master -------------------------------------------------- - -These can be easily kept up to date using linkgit:git-pull[1]. - -------------------------------------------------- -$ git switch test && git pull -$ git switch release && git pull -------------------------------------------------- - -Important note! If you have any local changes in these branches, then -this merge will create a commit object in the history (with no local -changes Git will simply do a "fast-forward" merge). Many people dislike -the "noise" that this creates in the Linux history, so you should avoid -doing this capriciously in the `release` branch, as these noisy commits -will become part of the permanent history when you ask Linus to pull -from the release branch. - -A few configuration variables (see linkgit:git-config[1]) can -make it easy to push both branches to your public tree. (See -<<setting-up-a-public-repository>>.) - -------------------------------------------------- -$ cat >> .git/config <<EOF -[remote "mytree"] - url = master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux.git - push = release - push = test -EOF -------------------------------------------------- - -Then you can push both the test and release trees using -linkgit:git-push[1]: - -------------------------------------------------- -$ git push mytree -------------------------------------------------- - -or push just one of the test and release branches using: - -------------------------------------------------- -$ git push mytree test -------------------------------------------------- - -or - -------------------------------------------------- -$ git push mytree release -------------------------------------------------- - -Now to apply some patches from the community. Think of a short -snappy name for a branch to hold this patch (or related group of -patches), and create a new branch from a recent stable tag of -Linus's branch. Picking a stable base for your branch will: -1) help you: by avoiding inclusion of unrelated and perhaps lightly -tested changes -2) help future bug hunters that use `git bisect` to find problems - -------------------------------------------------- -$ git switch -c speed-up-spinlocks v2.6.35 -------------------------------------------------- - -Now you apply the patch(es), run some tests, and commit the change(s). If -the patch is a multi-part series, then you should apply each as a separate -commit to this branch. - -------------------------------------------------- -$ ... patch ... test ... commit [ ... patch ... test ... commit ]* -------------------------------------------------- - -When you are happy with the state of this change, you can merge it into the -"test" branch in preparation to make it public: - -------------------------------------------------- -$ git switch test && git merge speed-up-spinlocks -------------------------------------------------- - -It is unlikely that you would have any conflicts here ... but you might if you -spent a while on this step and had also pulled new versions from upstream. - -Sometime later when enough time has passed and testing done, you can pull the -same branch into the `release` tree ready to go upstream. This is where you -see the value of keeping each patch (or patch series) in its own branch. It -means that the patches can be moved into the `release` tree in any order. - -------------------------------------------------- -$ git switch release && git merge speed-up-spinlocks -------------------------------------------------- - -After a while, you will have a number of branches, and despite the -well chosen names you picked for each of them, you may forget what -they are for, or what status they are in. To get a reminder of what -changes are in a specific branch, use: - -------------------------------------------------- -$ git log linux..branchname | git shortlog -------------------------------------------------- - -To see whether it has already been merged into the test or release branches, -use: - -------------------------------------------------- -$ git log test..branchname -------------------------------------------------- - -or - -------------------------------------------------- -$ git log release..branchname -------------------------------------------------- - -(If this branch has not yet been merged, you will see some log entries. -If it has been merged, then there will be no output.) - -Once a patch completes the great cycle (moving from test to release, -then pulled by Linus, and finally coming back into your local -`origin/master` branch), the branch for this change is no longer needed. -You detect this when the output from: - -------------------------------------------------- -$ git log origin..branchname -------------------------------------------------- - -is empty. At this point the branch can be deleted: - -------------------------------------------------- -$ git branch -d branchname -------------------------------------------------- - -Some changes are so trivial that it is not necessary to create a separate -branch and then merge into each of the test and release branches. For -these changes, just apply directly to the `release` branch, and then -merge that into the `test` branch. - -After pushing your work to `mytree`, you can use -linkgit:git-request-pull[1] to prepare a "please pull" request message -to send to Linus: - -------------------------------------------------- -$ git push mytree -$ git request-pull origin mytree release -------------------------------------------------- - -Here are some of the scripts that simplify all this even further. - -------------------------------------------------- -==== update script ==== -# Update a branch in my Git tree. If the branch to be updated -# is origin, then pull from kernel.org. Otherwise merge -# origin/master branch into test|release branch - -case "$1" in -test|release) - git checkout $1 && git pull . origin - ;; -origin) - before=$(git rev-parse refs/remotes/origin/master) - git fetch origin - after=$(git rev-parse refs/remotes/origin/master) - if [ $before != $after ] - then - git log $before..$after | git shortlog - fi - ;; -*) - echo "usage: $0 origin|test|release" 1>&2 - exit 1 - ;; -esac -------------------------------------------------- - -------------------------------------------------- -==== merge script ==== -# Merge a branch into either the test or release branch - -pname=$0 - -usage() -{ - echo "usage: $pname branch test|release" 1>&2 - exit 1 -} - -git show-ref -q --verify -- refs/heads/"$1" || { - echo "Can't see branch <$1>" 1>&2 - usage -} - -case "$2" in -test|release) - if [ $(git log $2..$1 | wc -c) -eq 0 ] - then - echo $1 already merged into $2 1>&2 - exit 1 - fi - git checkout $2 && git pull . $1 - ;; -*) - usage - ;; -esac -------------------------------------------------- - -------------------------------------------------- -==== status script ==== -# report on status of my ia64 Git tree - -gb=$(tput setab 2) -rb=$(tput setab 1) -restore=$(tput setab 9) - -if [ `git rev-list test..release | wc -c` -gt 0 ] -then - echo $rb Warning: commits in release that are not in test $restore - git log test..release -fi - -for branch in `git show-ref --heads | sed 's|^.*/||'` -do - if [ $branch = test -o $branch = release ] - then - continue - fi - - echo -n $gb ======= $branch ====== $restore " " - status= - for ref in test release origin/master - do - if [ `git rev-list $ref..$branch | wc -c` -gt 0 ] - then - status=$status${ref:0:1} - fi - done - case $status in - trl) - echo $rb Need to pull into test $restore - ;; - rl) - echo "In test" - ;; - l) - echo "Waiting for linus" - ;; - "") - echo $rb All done $restore - ;; - *) - echo $rb "<$status>" $restore - ;; - esac - git log origin/master..$branch | git shortlog -done -------------------------------------------------- - - -[[cleaning-up-history]] -Rewriting history and maintaining patch series -============================================== - -Normally commits are only added to a project, never taken away or -replaced. Git is designed with this assumption, and violating it will -cause Git's merge machinery (for example) to do the wrong thing. - -However, there is a situation in which it can be useful to violate this -assumption. - -[[patch-series]] -Creating the perfect patch series ---------------------------------- - -Suppose you are a contributor to a large project, and you want to add a -complicated feature, and to present it to the other developers in a way -that makes it easy for them to read your changes, verify that they are -correct, and understand why you made each change. - -If you present all of your changes as a single patch (or commit), they -may find that it is too much to digest all at once. - -If you present them with the entire history of your work, complete with -mistakes, corrections, and dead ends, they may be overwhelmed. - -So the ideal is usually to produce a series of patches such that: - - 1. Each patch can be applied in order. - - 2. Each patch includes a single logical change, together with a - message explaining the change. - - 3. No patch introduces a regression: after applying any initial - part of the series, the resulting project still compiles and - works, and has no bugs that it didn't have before. - - 4. The complete series produces the same end result as your own - (probably much messier!) development process did. - -We will introduce some tools that can help you do this, explain how to -use them, and then explain some of the problems that can arise because -you are rewriting history. - -[[using-git-rebase]] -Keeping a patch series up to date using git rebase --------------------------------------------------- - -Suppose that you create a branch `mywork` on a remote-tracking branch -`origin`, and create some commits on top of it: - -------------------------------------------------- -$ git switch -c mywork origin -$ vi file.txt -$ git commit -$ vi otherfile.txt -$ git commit -... -------------------------------------------------- - -You have performed no merges into mywork, so it is just a simple linear -sequence of patches on top of `origin`: - -................................................ - o--o--O <-- origin - \ - a--b--c <-- mywork -................................................ - -Some more interesting work has been done in the upstream project, and -`origin` has advanced: - -................................................ - o--o--O--o--o--o <-- origin - \ - a--b--c <-- mywork -................................................ - -At this point, you could use `pull` to merge your changes back in; -the result would create a new merge commit, like this: - -................................................ - o--o--O--o--o--o <-- origin - \ \ - a--b--c--m <-- mywork -................................................ - -However, if you prefer to keep the history in mywork a simple series of -commits without any merges, you may instead choose to use -linkgit:git-rebase[1]: - -------------------------------------------------- -$ git switch mywork -$ git rebase origin -------------------------------------------------- - -This will remove each of your commits from mywork, temporarily saving -them as patches (in a directory named `.git/rebase-apply`), update mywork to -point at the latest version of origin, then apply each of the saved -patches to the new mywork. The result will look like: - - -................................................ - o--o--O--o--o--o <-- origin - \ - a'--b'--c' <-- mywork -................................................ - -In the process, it may discover conflicts. In that case it will stop -and allow you to fix the conflicts; after fixing conflicts, use `git add` -to update the index with those contents, and then, instead of -running `git commit`, just run - -------------------------------------------------- -$ git rebase --continue -------------------------------------------------- - -and Git will continue applying the rest of the patches. - -At any point you may use the `--abort` option to abort this process and -return mywork to the state it had before you started the rebase: - -------------------------------------------------- -$ git rebase --abort -------------------------------------------------- - -If you need to reorder or edit a number of commits in a branch, it may -be easier to use `git rebase -i`, which allows you to reorder and -squash commits, as well as marking them for individual editing during -the rebase. See <<interactive-rebase>> for details, and -<<reordering-patch-series>> for alternatives. - -[[rewriting-one-commit]] -Rewriting a single commit -------------------------- - -We saw in <<fixing-a-mistake-by-rewriting-history>> that you can replace the -most recent commit using - -------------------------------------------------- -$ git commit --amend -------------------------------------------------- - -which will replace the old commit by a new commit incorporating your -changes, giving you a chance to edit the old commit message first. -This is useful for fixing typos in your last commit, or for adjusting -the patch contents of a poorly staged commit. - -If you need to amend commits from deeper in your history, you can -use <<interactive-rebase,interactive rebase's `edit` instruction>>. - -[[reordering-patch-series]] -Reordering or selecting from a patch series -------------------------------------------- - -Sometimes you want to edit a commit deeper in your history. One -approach is to use `git format-patch` to create a series of patches -and then reset the state to before the patches: - -------------------------------------------------- -$ git format-patch origin -$ git reset --hard origin -------------------------------------------------- - -Then modify, reorder, or eliminate patches as needed before applying -them again with linkgit:git-am[1]: - -------------------------------------------------- -$ git am *.patch -------------------------------------------------- - -[[interactive-rebase]] -Using interactive rebases -------------------------- - -You can also edit a patch series with an interactive rebase. This is -the same as <<reordering-patch-series,reordering a patch series using -`format-patch`>>, so use whichever interface you like best. - -Rebase your current HEAD on the last commit you want to retain as-is. -For example, if you want to reorder the last 5 commits, use: - -------------------------------------------------- -$ git rebase -i HEAD~5 -------------------------------------------------- - -This will open your editor with a list of steps to be taken to perform -your rebase. - -------------------------------------------------- -pick deadbee The oneline of this commit -pick fa1afe1 The oneline of the next commit -... - -# Rebase c0ffeee..deadbee onto c0ffeee -# -# Commands: -# p, pick = use commit -# r, reword = use commit, but edit the commit message -# e, edit = use commit, but stop for amending -# s, squash = use commit, but meld into previous commit -# f, fixup = like "squash", but discard this commit's log message -# x, exec = run command (the rest of the line) using shell -# -# These lines can be re-ordered; they are executed from top to bottom. -# -# If you remove a line here THAT COMMIT WILL BE LOST. -# -# However, if you remove everything, the rebase will be aborted. -# -# Note that empty commits are commented out -------------------------------------------------- - -As explained in the comments, you can reorder commits, squash them -together, edit commit messages, etc. by editing the list. Once you -are satisfied, save the list and close your editor, and the rebase -will begin. - -The rebase will stop where `pick` has been replaced with `edit` or -when a step in the list fails to mechanically resolve conflicts and -needs your help. When you are done editing and/or resolving conflicts -you can continue with `git rebase --continue`. If you decide that -things are getting too hairy, you can always bail out with `git rebase ---abort`. Even after the rebase is complete, you can still recover -the original branch by using the <<reflogs,reflog>>. - -For a more detailed discussion of the procedure and additional tips, -see the "INTERACTIVE MODE" section of linkgit:git-rebase[1]. - -[[patch-series-tools]] -Other tools ------------ - -There are numerous other tools, such as StGit, which exist for the -purpose of maintaining a patch series. These are outside of the scope of -this manual. - -[[problems-With-rewriting-history]] -Problems with rewriting history -------------------------------- - -The primary problem with rewriting the history of a branch has to do -with merging. Suppose somebody fetches your branch and merges it into -their branch, with a result something like this: - -................................................ - o--o--O--o--o--o <-- origin - \ \ - t--t--t--m <-- their branch: -................................................ - -Then suppose you modify the last three commits: - -................................................ - o--o--o <-- new head of origin - / - o--o--O--o--o--o <-- old head of origin -................................................ - -If we examined all this history together in one repository, it will -look like: - -................................................ - o--o--o <-- new head of origin - / - o--o--O--o--o--o <-- old head of origin - \ \ - t--t--t--m <-- their branch: -................................................ - -Git has no way of knowing that the new head is an updated version of -the old head; it treats this situation exactly the same as it would if -two developers had independently done the work on the old and new heads -in parallel. At this point, if someone attempts to merge the new head -in to their branch, Git will attempt to merge together the two (old and -new) lines of development, instead of trying to replace the old by the -new. The results are likely to be unexpected. - -You may still choose to publish branches whose history is rewritten, -and it may be useful for others to be able to fetch those branches in -order to examine or test them, but they should not attempt to pull such -branches into their own work. - -For true distributed development that supports proper merging, -published branches should never be rewritten. - -[[bisect-merges]] -Why bisecting merge commits can be harder than bisecting linear history ------------------------------------------------------------------------ - -The linkgit:git-bisect[1] command correctly handles history that -includes merge commits. However, when the commit that it finds is a -merge commit, the user may need to work harder than usual to figure out -why that commit introduced a problem. - -Imagine this history: - -................................................ - ---Z---o---X---...---o---A---C---D - \ / - o---o---Y---...---o---B -................................................ - -Suppose that on the upper line of development, the meaning of one -of the functions that exists at Z is changed at commit X. The -commits from Z leading to A change both the function's -implementation and all calling sites that exist at Z, as well -as new calling sites they add, to be consistent. There is no -bug at A. - -Suppose that in the meantime on the lower line of development somebody -adds a new calling site for that function at commit Y. The -commits from Z leading to B all assume the old semantics of that -function and the callers and the callee are consistent with each -other. There is no bug at B, either. - -Suppose further that the two development lines merge cleanly at C, -so no conflict resolution is required. - -Nevertheless, the code at C is broken, because the callers added -on the lower line of development have not been converted to the new -semantics introduced on the upper line of development. So if all -you know is that D is bad, that Z is good, and that -linkgit:git-bisect[1] identifies C as the culprit, how will you -figure out that the problem is due to this change in semantics? - -When the result of a `git bisect` is a non-merge commit, you should -normally be able to discover the problem by examining just that commit. -Developers can make this easy by breaking their changes into small -self-contained commits. That won't help in the case above, however, -because the problem isn't obvious from examination of any single -commit; instead, a global view of the development is required. To -make matters worse, the change in semantics in the problematic -function may be just one small part of the changes in the upper -line of development. - -On the other hand, if instead of merging at C you had rebased the -history between Z to B on top of A, you would have gotten this -linear history: - -................................................................ - ---Z---o---X--...---o---A---o---o---Y*--...---o---B*--D* -................................................................ - -Bisecting between Z and D* would hit a single culprit commit Y*, -and understanding why Y* was broken would probably be easier. - -Partly for this reason, many experienced Git users, even when -working on an otherwise merge-heavy project, keep the history -linear by rebasing against the latest upstream version before -publishing. - -[[advanced-branch-management]] -Advanced branch management -========================== - -[[fetching-individual-branches]] -Fetching individual branches ----------------------------- - -Instead of using linkgit:git-remote[1], you can also choose just -to update one branch at a time, and to store it locally under an -arbitrary name: - -------------------------------------------------- -$ git fetch origin todo:my-todo-work -------------------------------------------------- - -The first argument, `origin`, just tells Git to fetch from the -repository you originally cloned from. The second argument tells Git -to fetch the branch named `todo` from the remote repository, and to -store it locally under the name `refs/heads/my-todo-work`. - -You can also fetch branches from other repositories; so - -------------------------------------------------- -$ git fetch git://example.com/proj.git master:example-master -------------------------------------------------- - -will create a new branch named `example-master` and store in it the -branch named `master` from the repository at the given URL. If you -already have a branch named example-master, it will attempt to -<<fast-forwards,fast-forward>> to the commit given by example.com's -master branch. In more detail: - -[[fetch-fast-forwards]] -git fetch and fast-forwards ---------------------------- - -In the previous example, when updating an existing branch, `git fetch` -checks to make sure that the most recent commit on the remote -branch is a descendant of the most recent commit on your copy of the -branch before updating your copy of the branch to point at the new -commit. Git calls this process a <<fast-forwards,fast-forward>>. - -A fast-forward looks something like this: - -................................................ - o--o--o--o <-- old head of the branch - \ - o--o--o <-- new head of the branch -................................................ - - -In some cases it is possible that the new head will *not* actually be -a descendant of the old head. For example, the developer may have -realized she made a serious mistake, and decided to backtrack, -resulting in a situation like: - -................................................ - o--o--o--o--a--b <-- old head of the branch - \ - o--o--o <-- new head of the branch -................................................ - -In this case, `git fetch` will fail, and print out a warning. - -In that case, you can still force Git to update to the new head, as -described in the following section. However, note that in the -situation above this may mean losing the commits labeled `a` and `b`, -unless you've already created a reference of your own pointing to -them. - -[[forcing-fetch]] -Forcing git fetch to do non-fast-forward updates ------------------------------------------------- - -If git fetch fails because the new head of a branch is not a -descendant of the old head, you may force the update with: - -------------------------------------------------- -$ git fetch git://example.com/proj.git +master:refs/remotes/example/master -------------------------------------------------- - -Note the addition of the `+` sign. Alternatively, you can use the `-f` -flag to force updates of all the fetched branches, as in: - -------------------------------------------------- -$ git fetch -f origin -------------------------------------------------- - -Be aware that commits that the old version of example/master pointed at -may be lost, as we saw in the previous section. - -[[remote-branch-configuration]] -Configuring remote-tracking branches ------------------------------------- - -We saw above that `origin` is just a shortcut to refer to the -repository that you originally cloned from. This information is -stored in Git configuration variables, which you can see using -linkgit:git-config[1]: - -------------------------------------------------- -$ git config -l -core.repositoryformatversion=0 -core.filemode=true -core.logallrefupdates=true -remote.origin.url=git://git.kernel.org/pub/scm/git/git.git -remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* -branch.master.remote=origin -branch.master.merge=refs/heads/master -------------------------------------------------- - -If there are other repositories that you also use frequently, you can -create similar configuration options to save typing; for example, - -------------------------------------------------- -$ git remote add example git://example.com/proj.git -------------------------------------------------- - -adds the following to `.git/config`: - -------------------------------------------------- -[remote "example"] - url = git://example.com/proj.git - fetch = +refs/heads/*:refs/remotes/example/* -------------------------------------------------- - -Also note that the above configuration can be performed by directly -editing the file `.git/config` instead of using linkgit:git-remote[1]. - -After configuring the remote, the following three commands will do the -same thing: - -------------------------------------------------- -$ git fetch git://example.com/proj.git +refs/heads/*:refs/remotes/example/* -$ git fetch example +refs/heads/*:refs/remotes/example/* -$ git fetch example -------------------------------------------------- - -See linkgit:git-config[1] for more details on the configuration -options mentioned above and linkgit:git-fetch[1] for more details on -the refspec syntax. - - -[[git-concepts]] -Git concepts -============ - -Git is built on a small number of simple but powerful ideas. While it -is possible to get things done without understanding them, you will find -Git much more intuitive if you do. - -We start with the most important, the <<def_object_database,object -database>> and the <<def_index,index>>. - -[[the-object-database]] -The Object Database -------------------- - - -We already saw in <<understanding-commits>> that all commits are stored -under a 40-digit "object name". In fact, all the information needed to -represent the history of a project is stored in objects with such names. -In each case the name is calculated by taking the SHA-1 hash of the -contents of the object. The SHA-1 hash is a cryptographic hash function. -What that means to us is that it is impossible to find two different -objects with the same name. This has a number of advantages; among -others: - -- Git can quickly determine whether two objects are identical or not, - just by comparing names. -- Since object names are computed the same way in every repository, the - same content stored in two repositories will always be stored under - the same name. -- Git can detect errors when it reads an object, by checking that the - object's name is still the SHA-1 hash of its contents. - -(See <<object-details>> for the details of the object formatting and -SHA-1 calculation.) - -There are four different types of objects: "blob", "tree", "commit", and -"tag". - -- A <<def_blob_object,"blob" object>> is used to store file data. -- A <<def_tree_object,"tree" object>> ties one or more - "blob" objects into a directory structure. In addition, a tree object - can refer to other tree objects, thus creating a directory hierarchy. -- A <<def_commit_object,"commit" object>> ties such directory hierarchies - together into a <<def_DAG,directed acyclic graph>> of revisions--each - commit contains the object name of exactly one tree designating the - directory hierarchy at the time of the commit. In addition, a commit - refers to "parent" commit objects that describe the history of how we - arrived at that directory hierarchy. -- A <<def_tag_object,"tag" object>> symbolically identifies and can be - used to sign other objects. It contains the object name and type of - another object, a symbolic name (of course!) and, optionally, a - signature. - -The object types in some more detail: - -[[commit-object]] -Commit Object -~~~~~~~~~~~~~ - -The "commit" object links a physical state of a tree with a description -of how we got there and why. Use the `--pretty=raw` option to -linkgit:git-show[1] or linkgit:git-log[1] to examine your favorite -commit: - ------------------------------------------------- -$ git show -s --pretty=raw 2be7fcb476 -commit 2be7fcb4764f2dbcee52635b91fedb1b3dcf7ab4 -tree fb3a8bdd0ceddd019615af4d57a53f43d8cee2bf -parent 257a84d9d02e90447b149af58b271c19405edb6a -author Dave Watson <dwatson@mimvista.com> 1187576872 -0400 -committer Junio C Hamano <gitster@pobox.com> 1187591163 -0700 - - Fix misspelling of 'suppress' in docs - - Signed-off-by: Junio C Hamano <gitster@pobox.com> ------------------------------------------------- - -As you can see, a commit is defined by: - -- a tree: The SHA-1 name of a tree object (as defined below), representing - the contents of a directory at a certain point in time. -- parent(s): The SHA-1 name(s) of some number of commits which represent the - immediately previous step(s) in the history of the project. The - example above has one parent; merge commits may have more than - one. A commit with no parents is called a "root" commit, and - represents the initial revision of a project. Each project must have - at least one root. A project can also have multiple roots, though - that isn't common (or necessarily a good idea). -- an author: The name of the person responsible for this change, together - with its date. -- a committer: The name of the person who actually created the commit, - with the date it was done. This may be different from the author, for - example, if the author was someone who wrote a patch and emailed it - to the person who used it to create the commit. -- a comment describing this commit. - -Note that a commit does not itself contain any information about what -actually changed; all changes are calculated by comparing the contents -of the tree referred to by this commit with the trees associated with -its parents. In particular, Git does not attempt to record file renames -explicitly, though it can identify cases where the existence of the same -file data at changing paths suggests a rename. (See, for example, the -`-M` option to linkgit:git-diff[1]). - -A commit is usually created by linkgit:git-commit[1], which creates a -commit whose parent is normally the current HEAD, and whose tree is -taken from the content currently stored in the index. - -[[tree-object]] -Tree Object -~~~~~~~~~~~ - -The ever-versatile linkgit:git-show[1] command can also be used to -examine tree objects, but linkgit:git-ls-tree[1] will give you more -details: - ------------------------------------------------- -$ git ls-tree fb3a8bdd0ce -100644 blob 63c918c667fa005ff12ad89437f2fdc80926e21c .gitignore -100644 blob 5529b198e8d14decbe4ad99db3f7fb632de0439d .mailmap -100644 blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3 COPYING -040000 tree 2fb783e477100ce076f6bf57e4a6f026013dc745 Documentation -100755 blob 3c0032cec592a765692234f1cba47dfdcc3a9200 GIT-VERSION-GEN -100644 blob 289b046a443c0647624607d471289b2c7dcd470b INSTALL -100644 blob 4eb463797adc693dc168b926b6932ff53f17d0b1 Makefile -100644 blob 548142c327a6790ff8821d67c2ee1eff7a656b52 README -... ------------------------------------------------- - -As you can see, a tree object contains a list of entries, each with a -mode, object type, SHA-1 name, and name, sorted by name. It represents -the contents of a single directory tree. - -The object type may be a blob, representing the contents of a file, or -another tree, representing the contents of a subdirectory. Since trees -and blobs, like all other objects, are named by the SHA-1 hash of their -contents, two trees have the same SHA-1 name if and only if their -contents (including, recursively, the contents of all subdirectories) -are identical. This allows Git to quickly determine the differences -between two related tree objects, since it can ignore any entries with -identical object names. - -(Note: in the presence of submodules, trees may also have commits as -entries. See <<submodules>> for documentation.) - -Note that the files all have mode 644 or 755: Git actually only pays -attention to the executable bit. - -[[blob-object]] -Blob Object -~~~~~~~~~~~ - -You can use linkgit:git-show[1] to examine the contents of a blob; take, -for example, the blob in the entry for `COPYING` from the tree above: - ------------------------------------------------- -$ git show 6ff87c4664 - - Note that the only valid version of the GPL as far as this project - is concerned is _this_ particular version of the license (ie v2, not - v2.2 or v3.x or whatever), unless explicitly otherwise stated. -... ------------------------------------------------- - -A "blob" object is nothing but a binary blob of data. It doesn't refer -to anything else or have attributes of any kind. - -Since the blob is entirely defined by its data, if two files in a -directory tree (or in multiple different versions of the repository) -have the same contents, they will share the same blob object. The object -is totally independent of its location in the directory tree, and -renaming a file does not change the object that file is associated with. - -Note that any tree or blob object can be examined using -linkgit:git-show[1] with the <revision>:<path> syntax. This can -sometimes be useful for browsing the contents of a tree that is not -currently checked out. - -[[trust]] -Trust -~~~~~ - -If you receive the SHA-1 name of a blob from one source, and its contents -from another (possibly untrusted) source, you can still trust that those -contents are correct as long as the SHA-1 name agrees. This is because -the SHA-1 is designed so that it is infeasible to find different contents -that produce the same hash. - -Similarly, you need only trust the SHA-1 name of a top-level tree object -to trust the contents of the entire directory that it refers to, and if -you receive the SHA-1 name of a commit from a trusted source, then you -can easily verify the entire history of commits reachable through -parents of that commit, and all of those contents of the trees referred -to by those commits. - -So to introduce some real trust in the system, the only thing you need -to do is to digitally sign just 'one' special note, which includes the -name of a top-level commit. Your digital signature shows others -that you trust that commit, and the immutability of the history of -commits tells others that they can trust the whole history. - -In other words, you can easily validate a whole archive by just -sending out a single email that tells the people the name (SHA-1 hash) -of the top commit, and digitally sign that email using something -like GPG/PGP. - -To assist in this, Git also provides the tag object... - -[[tag-object]] -Tag Object -~~~~~~~~~~ - -A tag object contains an object, object type, tag name, the name of the -person ("tagger") who created the tag, and a message, which may contain -a signature, as can be seen using linkgit:git-cat-file[1]: - ------------------------------------------------- -$ git cat-file tag v1.5.0 -object 437b1b20df4b356c9342dac8d38849f24ef44f27 -type commit -tag v1.5.0 -tagger Junio C Hamano <junkio@cox.net> 1171411200 +0000 - -GIT 1.5.0 ------BEGIN PGP SIGNATURE----- -Version: GnuPG v1.4.6 (GNU/Linux) - -iD8DBQBF0lGqwMbZpPMRm5oRAuRiAJ9ohBLd7s2kqjkKlq1qqC57SbnmzQCdG4ui -nLE/L9aUXdWeTFPron96DLA= -=2E+0 ------END PGP SIGNATURE----- ------------------------------------------------- - -See the linkgit:git-tag[1] command to learn how to create and verify tag -objects. (Note that linkgit:git-tag[1] can also be used to create -"lightweight tags", which are not tag objects at all, but just simple -references whose names begin with `refs/tags/`). - -[[pack-files]] -How Git stores objects efficiently: pack files -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Newly created objects are initially created in a file named after the -object's SHA-1 hash (stored in `.git/objects`). - -Unfortunately this system becomes inefficient once a project has a -lot of objects. Try this on an old project: - ------------------------------------------------- -$ git count-objects -6930 objects, 47620 kilobytes ------------------------------------------------- - -The first number is the number of objects which are kept in -individual files. The second is the amount of space taken up by -those "loose" objects. - -You can save space and make Git faster by moving these loose objects in -to a "pack file", which stores a group of objects in an efficient -compressed format; the details of how pack files are formatted can be -found in link:technical/pack-format.html[pack format]. - -To put the loose objects into a pack, just run git repack: - ------------------------------------------------- -$ git repack -Counting objects: 6020, done. -Delta compression using up to 4 threads. -Compressing objects: 100% (6020/6020), done. -Writing objects: 100% (6020/6020), done. -Total 6020 (delta 4070), reused 0 (delta 0) ------------------------------------------------- - -This creates a single "pack file" in .git/objects/pack/ -containing all currently unpacked objects. You can then run - ------------------------------------------------- -$ git prune ------------------------------------------------- - -to remove any of the "loose" objects that are now contained in the -pack. This will also remove any unreferenced objects (which may be -created when, for example, you use `git reset` to remove a commit). -You can verify that the loose objects are gone by looking at the -`.git/objects` directory or by running - ------------------------------------------------- -$ git count-objects -0 objects, 0 kilobytes ------------------------------------------------- - -Although the object files are gone, any commands that refer to those -objects will work exactly as they did before. - -The linkgit:git-gc[1] command performs packing, pruning, and more for -you, so is normally the only high-level command you need. - -[[dangling-objects]] -Dangling objects -~~~~~~~~~~~~~~~~ - -The linkgit:git-fsck[1] command will sometimes complain about dangling -objects. They are not a problem. - -The most common cause of dangling objects is that you've rebased a -branch, or you have pulled from somebody else who rebased a branch--see -<<cleaning-up-history>>. In that case, the old head of the original -branch still exists, as does everything it pointed to. The branch -pointer itself just doesn't, since you replaced it with another one. - -There are also other situations that cause dangling objects. For -example, a "dangling blob" may arise because you did a `git add` of a -file, but then, before you actually committed it and made it part of the -bigger picture, you changed something else in that file and committed -that *updated* thing--the old state that you added originally ends up -not being pointed to by any commit or tree, so it's now a dangling blob -object. - -Similarly, when the "recursive" merge strategy runs, and finds that -there are criss-cross merges and thus more than one merge base (which is -fairly unusual, but it does happen), it will generate one temporary -midway tree (or possibly even more, if you had lots of criss-crossing -merges and more than two merge bases) as a temporary internal merge -base, and again, those are real objects, but the end result will not end -up pointing to them, so they end up "dangling" in your repository. - -Generally, dangling objects aren't anything to worry about. They can -even be very useful: if you screw something up, the dangling objects can -be how you recover your old tree (say, you did a rebase, and realized -that you really didn't want to--you can look at what dangling objects -you have, and decide to reset your head to some old dangling state). - -For commits, you can just use: - ------------------------------------------------- -$ gitk <dangling-commit-sha-goes-here> --not --all ------------------------------------------------- - -This asks for all the history reachable from the given commit but not -from any branch, tag, or other reference. If you decide it's something -you want, you can always create a new reference to it, e.g., - ------------------------------------------------- -$ git branch recovered-branch <dangling-commit-sha-goes-here> ------------------------------------------------- - -For blobs and trees, you can't do the same, but you can still examine -them. You can just do - ------------------------------------------------- -$ git show <dangling-blob/tree-sha-goes-here> ------------------------------------------------- - -to show what the contents of the blob were (or, for a tree, basically -what the `ls` for that directory was), and that may give you some idea -of what the operation was that left that dangling object. - -Usually, dangling blobs and trees aren't very interesting. They're -almost always the result of either being a half-way mergebase (the blob -will often even have the conflict markers from a merge in it, if you -have had conflicting merges that you fixed up by hand), or simply -because you interrupted a `git fetch` with ^C or something like that, -leaving _some_ of the new objects in the object database, but just -dangling and useless. - -Anyway, once you are sure that you're not interested in any dangling -state, you can just prune all unreachable objects: - ------------------------------------------------- -$ git prune ------------------------------------------------- - -and they'll be gone. (You should only run `git prune` on a quiescent -repository--it's kind of like doing a filesystem fsck recovery: you -don't want to do that while the filesystem is mounted. -`git prune` is designed not to cause any harm in such cases of concurrent -accesses to a repository but you might receive confusing or scary messages.) - -[[recovering-from-repository-corruption]] -Recovering from repository corruption -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -By design, Git treats data trusted to it with caution. However, even in -the absence of bugs in Git itself, it is still possible that hardware or -operating system errors could corrupt data. - -The first defense against such problems is backups. You can back up a -Git directory using clone, or just using cp, tar, or any other backup -mechanism. - -As a last resort, you can search for the corrupted objects and attempt -to replace them by hand. Back up your repository before attempting this -in case you corrupt things even more in the process. - -We'll assume that the problem is a single missing or corrupted blob, -which is sometimes a solvable problem. (Recovering missing trees and -especially commits is *much* harder). - -Before starting, verify that there is corruption, and figure out where -it is with linkgit:git-fsck[1]; this may be time-consuming. - -Assume the output looks like this: - ------------------------------------------------- -$ git fsck --full --no-dangling -broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8 - to blob 4b9458b3786228369c63936db65827de3cc06200 -missing blob 4b9458b3786228369c63936db65827de3cc06200 ------------------------------------------------- - -Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6 -points to it. If you could find just one copy of that missing blob -object, possibly in some other repository, you could move it into -`.git/objects/4b/9458b3...` and be done. Suppose you can't. You can -still examine the tree that pointed to it with linkgit:git-ls-tree[1], -which might output something like: - ------------------------------------------------- -$ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8 -100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8 .gitignore -100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883 .mailmap -100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c COPYING -... -100644 blob 4b9458b3786228369c63936db65827de3cc06200 myfile -... ------------------------------------------------- - -So now you know that the missing blob was the data for a file named -`myfile`. And chances are you can also identify the directory--let's -say it's in `somedirectory`. If you're lucky the missing copy might be -the same as the copy you have checked out in your working tree at -`somedirectory/myfile`; you can test whether that's right with -linkgit:git-hash-object[1]: - ------------------------------------------------- -$ git hash-object -w somedirectory/myfile ------------------------------------------------- - -which will create and store a blob object with the contents of -somedirectory/myfile, and output the SHA-1 of that object. if you're -extremely lucky it might be 4b9458b3786228369c63936db65827de3cc06200, in -which case you've guessed right, and the corruption is fixed! - -Otherwise, you need more information. How do you tell which version of -the file has been lost? - -The easiest way to do this is with: - ------------------------------------------------- -$ git log --raw --all --full-history -- somedirectory/myfile ------------------------------------------------- - -Because you're asking for raw output, you'll now get something like - ------------------------------------------------- -commit abc -Author: -Date: -... -:100644 100644 4b9458b newsha M somedirectory/myfile - - -commit xyz -Author: -Date: - -... -:100644 100644 oldsha 4b9458b M somedirectory/myfile ------------------------------------------------- - -This tells you that the immediately following version of the file was -"newsha", and that the immediately preceding version was "oldsha". -You also know the commit messages that went with the change from oldsha -to 4b9458b and with the change from 4b9458b to newsha. - -If you've been committing small enough changes, you may now have a good -shot at reconstructing the contents of the in-between state 4b9458b. - -If you can do that, you can now recreate the missing object with - ------------------------------------------------- -$ git hash-object -w <recreated-file> ------------------------------------------------- - -and your repository is good again! - -(Btw, you could have ignored the `fsck`, and started with doing a - ------------------------------------------------- -$ git log --raw --all ------------------------------------------------- - -and just looked for the sha of the missing object (4b9458b) in that -whole thing. It's up to you--Git does *have* a lot of information, it is -just missing one particular blob version. - -[[the-index]] -The index ---------- - -The index is a binary file (generally kept in `.git/index`) containing a -sorted list of path names, each with permissions and the SHA-1 of a blob -object; linkgit:git-ls-files[1] can show you the contents of the index: - -------------------------------------------------- -$ git ls-files --stage -100644 63c918c667fa005ff12ad89437f2fdc80926e21c 0 .gitignore -100644 5529b198e8d14decbe4ad99db3f7fb632de0439d 0 .mailmap -100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0 COPYING -100644 a37b2152bd26be2c2289e1f57a292534a51a93c7 0 Documentation/.gitignore -100644 fbefe9a45b00a54b58d94d06eca48b03d40a50e0 0 Documentation/Makefile -... -100644 2511aef8d89ab52be5ec6a5e46236b4b6bcd07ea 0 xdiff/xtypes.h -100644 2ade97b2574a9f77e7ae4002a4e07a6a38e46d07 0 xdiff/xutils.c -100644 d5de8292e05e7c36c4b68857c1cf9855e3d2f70a 0 xdiff/xutils.h -------------------------------------------------- - -Note that in older documentation you may see the index called the -"current directory cache" or just the "cache". It has three important -properties: - -1. The index contains all the information necessary to generate a single -(uniquely determined) tree object. -+ -For example, running linkgit:git-commit[1] generates this tree object -from the index, stores it in the object database, and uses it as the -tree object associated with the new commit. - -2. The index enables fast comparisons between the tree object it defines -and the working tree. -+ -It does this by storing some additional data for each entry (such as -the last modified time). This data is not displayed above, and is not -stored in the created tree object, but it can be used to determine -quickly which files in the working directory differ from what was -stored in the index, and thus save Git from having to read all of the -data from such files to look for changes. - -3. It can efficiently represent information about merge conflicts -between different tree objects, allowing each pathname to be -associated with sufficient information about the trees involved that -you can create a three-way merge between them. -+ -We saw in <<conflict-resolution>> that during a merge the index can -store multiple versions of a single file (called "stages"). The third -column in the linkgit:git-ls-files[1] output above is the stage -number, and will take on values other than 0 for files with merge -conflicts. - -The index is thus a sort of temporary staging area, which is filled with -a tree which you are in the process of working on. - -If you blow the index away entirely, you generally haven't lost any -information as long as you have the name of the tree that it described. - -[[submodules]] -Submodules -========== - -Large projects are often composed of smaller, self-contained modules. For -example, an embedded Linux distribution's source tree would include every -piece of software in the distribution with some local modifications; a movie -player might need to build against a specific, known-working version of a -decompression library; several independent programs might all share the same -build scripts. - -With centralized revision control systems this is often accomplished by -including every module in one single repository. Developers can check out -all modules or only the modules they need to work with. They can even modify -files across several modules in a single commit while moving things around -or updating APIs and translations. - -Git does not allow partial checkouts, so duplicating this approach in Git -would force developers to keep a local copy of modules they are not -interested in touching. Commits in an enormous checkout would be slower -than you'd expect as Git would have to scan every directory for changes. -If modules have a lot of local history, clones would take forever. - -On the plus side, distributed revision control systems can much better -integrate with external sources. In a centralized model, a single arbitrary -snapshot of the external project is exported from its own revision control -and then imported into the local revision control on a vendor branch. All -the history is hidden. With distributed revision control you can clone the -entire external history and much more easily follow development and re-merge -local changes. - -Git's submodule support allows a repository to contain, as a subdirectory, a -checkout of an external project. Submodules maintain their own identity; -the submodule support just stores the submodule repository location and -commit ID, so other developers who clone the containing project -("superproject") can easily clone all the submodules at the same revision. -Partial checkouts of the superproject are possible: you can tell Git to -clone none, some or all of the submodules. - -The linkgit:git-submodule[1] command is available since Git 1.5.3. Users -with Git 1.5.2 can look up the submodule commits in the repository and -manually check them out; earlier versions won't recognize the submodules at -all. - -To see how submodule support works, create four example -repositories that can be used later as a submodule: - -------------------------------------------------- -$ mkdir ~/git -$ cd ~/git -$ for i in a b c d -do - mkdir $i - cd $i - git init - echo "module $i" > $i.txt - git add $i.txt - git commit -m "Initial commit, submodule $i" - cd .. -done -------------------------------------------------- - -Now create the superproject and add all the submodules: - -------------------------------------------------- -$ mkdir super -$ cd super -$ git init -$ for i in a b c d -do - git submodule add ~/git/$i $i -done -------------------------------------------------- - -NOTE: Do not use local URLs here if you plan to publish your superproject! - -See what files `git submodule` created: - -------------------------------------------------- -$ ls -a -. .. .git .gitmodules a b c d -------------------------------------------------- - -The `git submodule add <repo> <path>` command does a couple of things: - -- It clones the submodule from `<repo>` to the given `<path>` under the - current directory and by default checks out the master branch. -- It adds the submodule's clone path to the linkgit:gitmodules[5] file and - adds this file to the index, ready to be committed. -- It adds the submodule's current commit ID to the index, ready to be - committed. - -Commit the superproject: - -------------------------------------------------- -$ git commit -m "Add submodules a, b, c and d." -------------------------------------------------- - -Now clone the superproject: - -------------------------------------------------- -$ cd .. -$ git clone super cloned -$ cd cloned -------------------------------------------------- - -The submodule directories are there, but they're empty: - -------------------------------------------------- -$ ls -a a -. .. -$ git submodule status --d266b9873ad50488163457f025db7cdd9683d88b a --e81d457da15309b4fef4249aba9b50187999670d b --c1536a972b9affea0f16e0680ba87332dc059146 c --d96249ff5d57de5de093e6baff9e0aafa5276a74 d -------------------------------------------------- - -NOTE: The commit object names shown above would be different for you, but they -should match the HEAD commit object names of your repositories. You can check -it by running `git ls-remote ../a`. - -Pulling down the submodules is a two-step process. First run `git submodule -init` to add the submodule repository URLs to `.git/config`: - -------------------------------------------------- -$ git submodule init -------------------------------------------------- - -Now use `git submodule update` to clone the repositories and check out the -commits specified in the superproject: - -------------------------------------------------- -$ git submodule update -$ cd a -$ ls -a -. .. .git a.txt -------------------------------------------------- - -One major difference between `git submodule update` and `git submodule add` is -that `git submodule update` checks out a specific commit, rather than the tip -of a branch. It's like checking out a tag: the head is detached, so you're not -working on a branch. - -------------------------------------------------- -$ git branch -* (detached from d266b98) - master -------------------------------------------------- - -If you want to make a change within a submodule and you have a detached head, -then you should create or checkout a branch, make your changes, publish the -change within the submodule, and then update the superproject to reference the -new commit: - -------------------------------------------------- -$ git switch master -------------------------------------------------- - -or - -------------------------------------------------- -$ git switch -c fix-up -------------------------------------------------- - -then - -------------------------------------------------- -$ echo "adding a line again" >> a.txt -$ git commit -a -m "Updated the submodule from within the superproject." -$ git push -$ cd .. -$ git diff -diff --git a/a b/a -index d266b98..261dfac 160000 ---- a/a -+++ b/a -@@ -1 +1 @@ --Subproject commit d266b9873ad50488163457f025db7cdd9683d88b -+Subproject commit 261dfac35cb99d380eb966e102c1197139f7fa24 -$ git add a -$ git commit -m "Updated submodule a." -$ git push -------------------------------------------------- - -You have to run `git submodule update` after `git pull` if you want to update -submodules, too. - -Pitfalls with submodules ------------------------- - -Always publish the submodule change before publishing the change to the -superproject that references it. If you forget to publish the submodule change, -others won't be able to clone the repository: - -------------------------------------------------- -$ cd ~/git/super/a -$ echo i added another line to this file >> a.txt -$ git commit -a -m "doing it wrong this time" -$ cd .. -$ git add a -$ git commit -m "Updated submodule a again." -$ git push -$ cd ~/git/cloned -$ git pull -$ git submodule update -error: pathspec '261dfac35cb99d380eb966e102c1197139f7fa24' did not match any file(s) known to git. -Did you forget to 'git add'? -Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path 'a' -------------------------------------------------- - -In older Git versions it could be easily forgotten to commit new or modified -files in a submodule, which silently leads to similar problems as not pushing -the submodule changes. Starting with Git 1.7.0 both `git status` and `git diff` -in the superproject show submodules as modified when they contain new or -modified files to protect against accidentally committing such a state. `git -diff` will also add a `-dirty` to the work tree side when generating patch -output or used with the `--submodule` option: - -------------------------------------------------- -$ git diff -diff --git a/sub b/sub ---- a/sub -+++ b/sub -@@ -1 +1 @@ --Subproject commit 3f356705649b5d566d97ff843cf193359229a453 -+Subproject commit 3f356705649b5d566d97ff843cf193359229a453-dirty -$ git diff --submodule -Submodule sub 3f35670..3f35670-dirty: -------------------------------------------------- - -You also should not rewind branches in a submodule beyond commits that were -ever recorded in any superproject. - -It's not safe to run `git submodule update` if you've made and committed -changes within a submodule without checking out a branch first. They will be -silently overwritten: - -------------------------------------------------- -$ cat a.txt -module a -$ echo line added from private2 >> a.txt -$ git commit -a -m "line added inside private2" -$ cd .. -$ git submodule update -Submodule path 'a': checked out 'd266b9873ad50488163457f025db7cdd9683d88b' -$ cd a -$ cat a.txt -module a -------------------------------------------------- - -NOTE: The changes are still visible in the submodule's reflog. - -If you have uncommitted changes in your submodule working tree, `git -submodule update` will not overwrite them. Instead, you get the usual -warning about not being able switch from a dirty branch. - -[[low-level-operations]] -Low-level Git operations -======================== - -Many of the higher-level commands were originally implemented as shell -scripts using a smaller core of low-level Git commands. These can still -be useful when doing unusual things with Git, or just as a way to -understand its inner workings. - -[[object-manipulation]] -Object access and manipulation ------------------------------- - -The linkgit:git-cat-file[1] command can show the contents of any object, -though the higher-level linkgit:git-show[1] is usually more useful. - -The linkgit:git-commit-tree[1] command allows constructing commits with -arbitrary parents and trees. - -A tree can be created with linkgit:git-write-tree[1] and its data can be -accessed by linkgit:git-ls-tree[1]. Two trees can be compared with -linkgit:git-diff-tree[1]. - -A tag is created with linkgit:git-mktag[1], and the signature can be -verified by linkgit:git-verify-tag[1], though it is normally simpler to -use linkgit:git-tag[1] for both. - -[[the-workflow]] -The Workflow ------------- - -High-level operations such as linkgit:git-commit[1] and -linkgit:git-restore[1] work by moving data -between the working tree, the index, and the object database. Git -provides low-level operations which perform each of these steps -individually. - -Generally, all Git operations work on the index file. Some operations -work *purely* on the index file (showing the current state of the -index), but most operations move data between the index file and either -the database or the working directory. Thus there are four main -combinations: - -[[working-directory-to-index]] -working directory -> index -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The linkgit:git-update-index[1] command updates the index with -information from the working directory. You generally update the -index information by just specifying the filename you want to update, -like so: - -------------------------------------------------- -$ git update-index filename -------------------------------------------------- - -but to avoid common mistakes with filename globbing etc., the command -will not normally add totally new entries or remove old entries, -i.e. it will normally just update existing cache entries. - -To tell Git that yes, you really do realize that certain files no -longer exist, or that new files should be added, you -should use the `--remove` and `--add` flags respectively. - -NOTE! A `--remove` flag does 'not' mean that subsequent filenames will -necessarily be removed: if the files still exist in your directory -structure, the index will be updated with their new status, not -removed. The only thing `--remove` means is that update-index will be -considering a removed file to be a valid thing, and if the file really -does not exist any more, it will update the index accordingly. - -As a special case, you can also do `git update-index --refresh`, which -will refresh the "stat" information of each index to match the current -stat information. It will 'not' update the object status itself, and -it will only update the fields that are used to quickly test whether -an object still matches its old backing store object. - -The previously introduced linkgit:git-add[1] is just a wrapper for -linkgit:git-update-index[1]. - -[[index-to-object-database]] -index -> object database -~~~~~~~~~~~~~~~~~~~~~~~~ - -You write your current index file to a "tree" object with the program - -------------------------------------------------- -$ git write-tree -------------------------------------------------- - -that doesn't come with any options--it will just write out the -current index into the set of tree objects that describe that state, -and it will return the name of the resulting top-level tree. You can -use that tree to re-generate the index at any time by going in the -other direction: - -[[object-database-to-index]] -object database -> index -~~~~~~~~~~~~~~~~~~~~~~~~ - -You read a "tree" file from the object database, and use that to -populate (and overwrite--don't do this if your index contains any -unsaved state that you might want to restore later!) your current -index. Normal operation is just - -------------------------------------------------- -$ git read-tree <SHA-1 of tree> -------------------------------------------------- - -and your index file will now be equivalent to the tree that you saved -earlier. However, that is only your 'index' file: your working -directory contents have not been modified. - -[[index-to-working-directory]] -index -> working directory -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You update your working directory from the index by "checking out" -files. This is not a very common operation, since normally you'd just -keep your files updated, and rather than write to your working -directory, you'd tell the index files about the changes in your -working directory (i.e. `git update-index`). - -However, if you decide to jump to a new version, or check out somebody -else's version, or just restore a previous tree, you'd populate your -index file with read-tree, and then you need to check out the result -with - -------------------------------------------------- -$ git checkout-index filename -------------------------------------------------- - -or, if you want to check out all of the index, use `-a`. - -NOTE! `git checkout-index` normally refuses to overwrite old files, so -if you have an old version of the tree already checked out, you will -need to use the `-f` flag ('before' the `-a` flag or the filename) to -'force' the checkout. - - -Finally, there are a few odds and ends which are not purely moving -from one representation to the other: - -[[tying-it-all-together]] -Tying it all together -~~~~~~~~~~~~~~~~~~~~~ - -To commit a tree you have instantiated with `git write-tree`, you'd -create a "commit" object that refers to that tree and the history -behind it--most notably the "parent" commits that preceded it in -history. - -Normally a "commit" has one parent: the previous state of the tree -before a certain change was made. However, sometimes it can have two -or more parent commits, in which case we call it a "merge", due to the -fact that such a commit brings together ("merges") two or more -previous states represented by other commits. - -In other words, while a "tree" represents a particular directory state -of a working directory, a "commit" represents that state in time, -and explains how we got there. - -You create a commit object by giving it the tree that describes the -state at the time of the commit, and a list of parents: - -------------------------------------------------- -$ git commit-tree <tree> -p <parent> [(-p <parent2>)...] -------------------------------------------------- - -and then giving the reason for the commit on stdin (either through -redirection from a pipe or file, or by just typing it at the tty). - -`git commit-tree` will return the name of the object that represents -that commit, and you should save it away for later use. Normally, -you'd commit a new `HEAD` state, and while Git doesn't care where you -save the note about that state, in practice we tend to just write the -result to the file pointed at by `.git/HEAD`, so that we can always see -what the last committed state was. - -Here is a picture that illustrates how various pieces fit together: - ------------- - - commit-tree - commit obj - +----+ - | | - | | - V V - +-----------+ - | Object DB | - | Backing | - | Store | - +-----------+ - ^ - write-tree | | - tree obj | | - | | read-tree - | | tree obj - V - +-----------+ - | Index | - | "cache" | - +-----------+ - update-index ^ - blob obj | | - | | - checkout-index -u | | checkout-index - stat | | blob obj - V - +-----------+ - | Working | - | Directory | - +-----------+ - ------------- - - -[[examining-the-data]] -Examining the data ------------------- - -You can examine the data represented in the object database and the -index with various helper tools. For every object, you can use -linkgit:git-cat-file[1] to examine details about the -object: - -------------------------------------------------- -$ git cat-file -t <objectname> -------------------------------------------------- - -shows the type of the object, and once you have the type (which is -usually implicit in where you find the object), you can use - -------------------------------------------------- -$ git cat-file blob|tree|commit|tag <objectname> -------------------------------------------------- - -to show its contents. NOTE! Trees have binary content, and as a result -there is a special helper for showing that content, called -`git ls-tree`, which turns the binary content into a more easily -readable form. - -It's especially instructive to look at "commit" objects, since those -tend to be small and fairly self-explanatory. In particular, if you -follow the convention of having the top commit name in `.git/HEAD`, -you can do - -------------------------------------------------- -$ git cat-file commit HEAD -------------------------------------------------- - -to see what the top commit was. - -[[merging-multiple-trees]] -Merging multiple trees ----------------------- - -Git can help you perform a three-way merge, which can in turn be -used for a many-way merge by repeating the merge procedure several -times. The usual situation is that you only do one three-way merge -(reconciling two lines of history) and commit the result, but if -you like to, you can merge several branches in one go. - -To perform a three-way merge, you start with the two commits you -want to merge, find their closest common parent (a third commit), -and compare the trees corresponding to these three commits. - -To get the "base" for the merge, look up the common parent of two -commits: - -------------------------------------------------- -$ git merge-base <commit1> <commit2> -------------------------------------------------- - -This prints the name of a commit they are both based on. You should -now look up the tree objects of those commits, which you can easily -do with - -------------------------------------------------- -$ git cat-file commit <commitname> | head -1 -------------------------------------------------- - -since the tree object information is always the first line in a commit -object. - -Once you know the three trees you are going to merge (the one "original" -tree, aka the common tree, and the two "result" trees, aka the branches -you want to merge), you do a "merge" read into the index. This will -complain if it has to throw away your old index contents, so you should -make sure that you've committed those--in fact you would normally -always do a merge against your last commit (which should thus match what -you have in your current index anyway). - -To do the merge, do - -------------------------------------------------- -$ git read-tree -m -u <origtree> <yourtree> <targettree> -------------------------------------------------- - -which will do all trivial merge operations for you directly in the -index file, and you can just write the result out with -`git write-tree`. - - -[[merging-multiple-trees-2]] -Merging multiple trees, continued ---------------------------------- - -Sadly, many merges aren't trivial. If there are files that have -been added, moved or removed, or if both branches have modified the -same file, you will be left with an index tree that contains "merge -entries" in it. Such an index tree can 'NOT' be written out to a tree -object, and you will have to resolve any such merge clashes using -other tools before you can write out the result. - -You can examine such index state with `git ls-files --unmerged` -command. An example: - ------------------------------------------------- -$ git read-tree -m $orig HEAD $target -$ git ls-files --unmerged -100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello.c -100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello.c -100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c ------------------------------------------------- - -Each line of the `git ls-files --unmerged` output begins with -the blob mode bits, blob SHA-1, 'stage number', and the -filename. The 'stage number' is Git's way to say which tree it -came from: stage 1 corresponds to the `$orig` tree, stage 2 to -the `HEAD` tree, and stage 3 to the `$target` tree. - -Earlier we said that trivial merges are done inside -`git read-tree -m`. For example, if the file did not change -from `$orig` to `HEAD` or `$target`, or if the file changed -from `$orig` to `HEAD` and `$orig` to `$target` the same way, -obviously the final outcome is what is in `HEAD`. What the -above example shows is that file `hello.c` was changed from -`$orig` to `HEAD` and `$orig` to `$target` in a different way. -You could resolve this by running your favorite 3-way merge -program, e.g. `diff3`, `merge`, or Git's own merge-file, on -the blob objects from these three stages yourself, like this: - ------------------------------------------------- -$ git cat-file blob 263414f >hello.c~1 -$ git cat-file blob 06fa6a2 >hello.c~2 -$ git cat-file blob cc44c73 >hello.c~3 -$ git merge-file hello.c~2 hello.c~1 hello.c~3 ------------------------------------------------- - -This would leave the merge result in `hello.c~2` file, along -with conflict markers if there are conflicts. After verifying -the merge result makes sense, you can tell Git what the final -merge result for this file is by: - -------------------------------------------------- -$ mv -f hello.c~2 hello.c -$ git update-index hello.c -------------------------------------------------- - -When a path is in the "unmerged" state, running `git update-index` for -that path tells Git to mark the path resolved. - -The above is the description of a Git merge at the lowest level, -to help you understand what conceptually happens under the hood. -In practice, nobody, not even Git itself, runs `git cat-file` three times -for this. There is a `git merge-index` program that extracts the -stages to temporary files and calls a "merge" script on it: - -------------------------------------------------- -$ git merge-index git-merge-one-file hello.c -------------------------------------------------- - -and that is what higher level `git merge -s resolve` is implemented with. - -[[hacking-git]] -Hacking Git -=========== - -This chapter covers internal details of the Git implementation which -probably only Git developers need to understand. - -[[object-details]] -Object storage format ---------------------- - -All objects have a statically determined "type" which identifies the -format of the object (i.e. how it is used, and how it can refer to other -objects). There are currently four different object types: "blob", -"tree", "commit", and "tag". - -Regardless of object type, all objects share the following -characteristics: they are all deflated with zlib, and have a header -that not only specifies their type, but also provides size information -about the data in the object. It's worth noting that the SHA-1 hash -that is used to name the object is the hash of the original data -plus this header, so `sha1sum` 'file' does not match the object name -for 'file'. - -As a result, the general consistency of an object can always be tested -independently of the contents or the type of the object: all objects can -be validated by verifying that (a) their hashes match the content of the -file and (b) the object successfully inflates to a stream of bytes that -forms a sequence of -`<ascii type without space> + <space> + <ascii decimal size> + -<byte\0> + <binary object data>`. - -The structured objects can further have their structure and -connectivity to other objects verified. This is generally done with -the `git fsck` program, which generates a full dependency graph -of all objects, and verifies their internal consistency (in addition -to just verifying their superficial consistency through the hash). - -[[birdview-on-the-source-code]] -A birds-eye view of Git's source code -------------------------------------- - -It is not always easy for new developers to find their way through Git's -source code. This section gives you a little guidance to show where to -start. - -A good place to start is with the contents of the initial commit, with: - ----------------------------------------------------- -$ git switch --detach e83c5163 ----------------------------------------------------- - -The initial revision lays the foundation for almost everything Git has -today, but is small enough to read in one sitting. - -Note that terminology has changed since that revision. For example, the -README in that revision uses the word "changeset" to describe what we -now call a <<def_commit_object,commit>>. - -Also, we do not call it "cache" any more, but rather "index"; however, the -file is still called `cache.h`. Remark: Not much reason to change it now, -especially since there is no good single name for it anyway, because it is -basically _the_ header file which is included by _all_ of Git's C sources. - -If you grasp the ideas in that initial commit, you should check out a -more recent version and skim `cache.h`, `object.h` and `commit.h`. - -In the early days, Git (in the tradition of UNIX) was a bunch of programs -which were extremely simple, and which you used in scripts, piping the -output of one into another. This turned out to be good for initial -development, since it was easier to test new things. However, recently -many of these parts have become builtins, and some of the core has been -"libified", i.e. put into libgit.a for performance, portability reasons, -and to avoid code duplication. - -By now, you know what the index is (and find the corresponding data -structures in `cache.h`), and that there are just a couple of object types -(blobs, trees, commits and tags) which inherit their common structure from -`struct object`, which is their first member (and thus, you can cast e.g. -`(struct object *)commit` to achieve the _same_ as `&commit->object`, i.e. -get at the object name and flags). - -Now is a good point to take a break to let this information sink in. - -Next step: get familiar with the object naming. Read <<naming-commits>>. -There are quite a few ways to name an object (and not only revisions!). -All of these are handled in `sha1_name.c`. Just have a quick look at -the function `get_sha1()`. A lot of the special handling is done by -functions like `get_sha1_basic()` or the likes. - -This is just to get you into the groove for the most libified part of Git: -the revision walker. - -Basically, the initial version of `git log` was a shell script: - ----------------------------------------------------------------- -$ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \ - LESS=-S ${PAGER:-less} ----------------------------------------------------------------- - -What does this mean? - -`git rev-list` is the original version of the revision walker, which -_always_ printed a list of revisions to stdout. It is still functional, -and needs to, since most new Git commands start out as scripts using -`git rev-list`. - -`git rev-parse` is not as important any more; it was only used to filter out -options that were relevant for the different plumbing commands that were -called by the script. - -Most of what `git rev-list` did is contained in `revision.c` and -`revision.h`. It wraps the options in a struct named `rev_info`, which -controls how and what revisions are walked, and more. - -The original job of `git rev-parse` is now taken by the function -`setup_revisions()`, which parses the revisions and the common command-line -options for the revision walker. This information is stored in the struct -`rev_info` for later consumption. You can do your own command-line option -parsing after calling `setup_revisions()`. After that, you have to call -`prepare_revision_walk()` for initialization, and then you can get the -commits one by one with the function `get_revision()`. - -If you are interested in more details of the revision walking process, -just have a look at the first implementation of `cmd_log()`; call -`git show v1.3.0~155^2~4` and scroll down to that function (note that you -no longer need to call `setup_pager()` directly). - -Nowadays, `git log` is a builtin, which means that it is _contained_ in the -command `git`. The source side of a builtin is - -- a function called `cmd_<bla>`, typically defined in `builtin/<bla.c>` - (note that older versions of Git used to have it in `builtin-<bla>.c` - instead), and declared in `builtin.h`. - -- an entry in the `commands[]` array in `git.c`, and - -- an entry in `BUILTIN_OBJECTS` in the `Makefile`. - -Sometimes, more than one builtin is contained in one source file. For -example, `cmd_whatchanged()` and `cmd_log()` both reside in `builtin/log.c`, -since they share quite a bit of code. In that case, the commands which are -_not_ named like the `.c` file in which they live have to be listed in -`BUILT_INS` in the `Makefile`. - -`git log` looks more complicated in C than it does in the original script, -but that allows for a much greater flexibility and performance. - -Here again it is a good point to take a pause. - -Lesson three is: study the code. Really, it is the best way to learn about -the organization of Git (after you know the basic concepts). - -So, think about something which you are interested in, say, "how can I -access a blob just knowing the object name of it?". The first step is to -find a Git command with which you can do it. In this example, it is either -`git show` or `git cat-file`. - -For the sake of clarity, let's stay with `git cat-file`, because it - -- is plumbing, and - -- was around even in the initial commit (it literally went only through - some 20 revisions as `cat-file.c`, was renamed to `builtin/cat-file.c` - when made a builtin, and then saw less than 10 versions). - -So, look into `builtin/cat-file.c`, search for `cmd_cat_file()` and look what -it does. - ------------------------------------------------------------------- - git_config(git_default_config); - if (argc != 3) - usage("git cat-file [-t|-s|-e|-p|<type>] <sha1>"); - if (get_sha1(argv[2], sha1)) - die("Not a valid object name %s", argv[2]); ------------------------------------------------------------------- - -Let's skip over the obvious details; the only really interesting part -here is the call to `get_sha1()`. It tries to interpret `argv[2]` as an -object name, and if it refers to an object which is present in the current -repository, it writes the resulting SHA-1 into the variable `sha1`. - -Two things are interesting here: - -- `get_sha1()` returns 0 on _success_. This might surprise some new - Git hackers, but there is a long tradition in UNIX to return different - negative numbers in case of different errors--and 0 on success. - -- the variable `sha1` in the function signature of `get_sha1()` is `unsigned - char *`, but is actually expected to be a pointer to `unsigned - char[20]`. This variable will contain the 160-bit SHA-1 of the given - commit. Note that whenever a SHA-1 is passed as `unsigned char *`, it - is the binary representation, as opposed to the ASCII representation in - hex characters, which is passed as `char *`. - -You will see both of these things throughout the code. - -Now, for the meat: - ------------------------------------------------------------------------------ - case 0: - buf = read_object_with_reference(sha1, argv[1], &size, NULL); ------------------------------------------------------------------------------ - -This is how you read a blob (actually, not only a blob, but any type of -object). To know how the function `read_object_with_reference()` actually -works, find the source code for it (something like `git grep -read_object_with | grep ":[a-z]"` in the Git repository), and read -the source. - -To find out how the result can be used, just read on in `cmd_cat_file()`: - ------------------------------------ - write_or_die(1, buf, size); ------------------------------------ - -Sometimes, you do not know where to look for a feature. In many such cases, -it helps to search through the output of `git log`, and then `git show` the -corresponding commit. - -Example: If you know that there was some test case for `git bundle`, but -do not remember where it was (yes, you _could_ `git grep bundle t/`, but that -does not illustrate the point!): - ------------------------- -$ git log --no-merges t/ ------------------------- - -In the pager (`less`), just search for "bundle", go a few lines back, -and see that it is in commit 18449ab0. Now just copy this object name, -and paste it into the command line - -------------------- -$ git show 18449ab0 -------------------- - -Voila. - -Another example: Find out what to do in order to make some script a -builtin: - -------------------------------------------------- -$ git log --no-merges --diff-filter=A builtin/*.c -------------------------------------------------- - -You see, Git is actually the best tool to find out about the source of Git -itself! - -[[glossary]] -Git Glossary -============ - -[[git-explained]] -Git explained -------------- - -include::glossary-content.txt[] - -[[git-quick-start]] -Appendix A: Git Quick Reference -=============================== - -This is a quick summary of the major commands; the previous chapters -explain how these work in more detail. - -[[quick-creating-a-new-repository]] -Creating a new repository -------------------------- - -From a tarball: - ------------------------------------------------ -$ tar xzf project.tar.gz -$ cd project -$ git init -Initialized empty Git repository in .git/ -$ git add . -$ git commit ------------------------------------------------ - -From a remote repository: - ------------------------------------------------ -$ git clone git://example.com/pub/project.git -$ cd project ------------------------------------------------ - -[[managing-branches]] -Managing branches ------------------ - ------------------------------------------------ -$ git branch # list all local branches in this repo -$ git switch test # switch working directory to branch "test" -$ git branch new # create branch "new" starting at current HEAD -$ git branch -d new # delete branch "new" ------------------------------------------------ - -Instead of basing a new branch on current HEAD (the default), use: - ------------------------------------------------ -$ git branch new test # branch named "test" -$ git branch new v2.6.15 # tag named v2.6.15 -$ git branch new HEAD^ # commit before the most recent -$ git branch new HEAD^^ # commit before that -$ git branch new test~10 # ten commits before tip of branch "test" ------------------------------------------------ - -Create and switch to a new branch at the same time: - ------------------------------------------------ -$ git switch -c new v2.6.15 ------------------------------------------------ - -Update and examine branches from the repository you cloned from: - ------------------------------------------------ -$ git fetch # update -$ git branch -r # list - origin/master - origin/next - ... -$ git switch -c masterwork origin/master ------------------------------------------------ - -Fetch a branch from a different repository, and give it a new -name in your repository: - ------------------------------------------------ -$ git fetch git://example.com/project.git theirbranch:mybranch -$ git fetch git://example.com/project.git v2.6.15:mybranch ------------------------------------------------ - -Keep a list of repositories you work with regularly: - ------------------------------------------------ -$ git remote add example git://example.com/project.git -$ git remote # list remote repositories -example -origin -$ git remote show example # get details -* remote example - URL: git://example.com/project.git - Tracked remote branches - master - next - ... -$ git fetch example # update branches from example -$ git branch -r # list all remote branches ------------------------------------------------ - - -[[exploring-history]] -Exploring history ------------------ - ------------------------------------------------ -$ gitk # visualize and browse history -$ git log # list all commits -$ git log src/ # ...modifying src/ -$ git log v2.6.15..v2.6.16 # ...in v2.6.16, not in v2.6.15 -$ git log master..test # ...in branch test, not in branch master -$ git log test..master # ...in branch master, but not in test -$ git log test...master # ...in one branch, not in both -$ git log -S'foo()' # ...where difference contain "foo()" -$ git log --since="2 weeks ago" -$ git log -p # show patches as well -$ git show # most recent commit -$ git diff v2.6.15..v2.6.16 # diff between two tagged versions -$ git diff v2.6.15..HEAD # diff with current head -$ git grep "foo()" # search working directory for "foo()" -$ git grep v2.6.15 "foo()" # search old tree for "foo()" -$ git show v2.6.15:a.txt # look at old version of a.txt ------------------------------------------------ - -Search for regressions: - ------------------------------------------------ -$ git bisect start -$ git bisect bad # current version is bad -$ git bisect good v2.6.13-rc2 # last known good revision -Bisecting: 675 revisions left to test after this - # test here, then: -$ git bisect good # if this revision is good, or -$ git bisect bad # if this revision is bad. - # repeat until done. ------------------------------------------------ - -[[making-changes]] -Making changes --------------- - -Make sure Git knows who to blame: - ------------------------------------------------- -$ cat >>~/.gitconfig <<\EOF -[user] - name = Your Name Comes Here - email = you@yourdomain.example.com -EOF ------------------------------------------------- - -Select file contents to include in the next commit, then make the -commit: - ------------------------------------------------ -$ git add a.txt # updated file -$ git add b.txt # new file -$ git rm c.txt # old file -$ git commit ------------------------------------------------ - -Or, prepare and create the commit in one step: - ------------------------------------------------ -$ git commit d.txt # use latest content only of d.txt -$ git commit -a # use latest content of all tracked files ------------------------------------------------ - -[[merging]] -Merging -------- - ------------------------------------------------ -$ git merge test # merge branch "test" into the current branch -$ git pull git://example.com/project.git master - # fetch and merge in remote branch -$ git pull . test # equivalent to git merge test ------------------------------------------------ - -[[sharing-your-changes]] -Sharing your changes --------------------- - -Importing or exporting patches: - ------------------------------------------------ -$ git format-patch origin..HEAD # format a patch for each commit - # in HEAD but not in origin -$ git am mbox # import patches from the mailbox "mbox" ------------------------------------------------ - -Fetch a branch in a different Git repository, then merge into the -current branch: - ------------------------------------------------ -$ git pull git://example.com/project.git theirbranch ------------------------------------------------ - -Store the fetched branch into a local branch before merging into the -current branch: - ------------------------------------------------ -$ git pull git://example.com/project.git theirbranch:mybranch ------------------------------------------------ - -After creating commits on a local branch, update the remote -branch with your commits: - ------------------------------------------------ -$ git push ssh://example.com/project.git mybranch:theirbranch ------------------------------------------------ - -When remote and local branch are both named "test": - ------------------------------------------------ -$ git push ssh://example.com/project.git test ------------------------------------------------ - -Shortcut version for a frequently used remote repository: - ------------------------------------------------ -$ git remote add example ssh://example.com/project.git -$ git push example test ------------------------------------------------ - -[[repository-maintenance]] -Repository maintenance ----------------------- - -Check for corruption: - ------------------------------------------------ -$ git fsck ------------------------------------------------ - -Recompress, remove unused cruft: - ------------------------------------------------ -$ git gc ------------------------------------------------ - - -[[todo]] -Appendix B: Notes and todo list for this manual -=============================================== - -[[todo-list]] -Todo list ---------- - -This is a work in progress. - -The basic requirements: - -- It must be readable in order, from beginning to end, by someone - intelligent with a basic grasp of the UNIX command line, but without - any special knowledge of Git. If necessary, any other prerequisites - should be specifically mentioned as they arise. -- Whenever possible, section headings should clearly describe the task - they explain how to do, in language that requires no more knowledge - than necessary: for example, "importing patches into a project" rather - than "the `git am` command" - -Think about how to create a clear chapter dependency graph that will -allow people to get to important topics without necessarily reading -everything in between. - -Scan `Documentation/` for other stuff left out; in particular: - -- howto's -- some of `technical/`? -- hooks -- list of commands in linkgit:git[1] - -Scan email archives for other stuff left out - -Scan man pages to see if any assume more background than this manual -provides. - -Add more good examples. Entire sections of just cookbook examples -might be a good idea; maybe make an "advanced examples" section a -standard end-of-chapter section? - -Include cross-references to the glossary, where appropriate. - -Add a section on working with other version control systems, including -CVS, Subversion, and just imports of series of release tarballs. - -Write a chapter on using plumbing and writing scripts. - -Alternates, clone -reference, etc. - -More on recovery from repository corruption. See: - http://marc.info/?l=git&m=117263864820799&w=2 - http://marc.info/?l=git&m=117147855503798&w=2 |